랩뷰의 디자인 패턴 : 상태머신

FA 분야에서는 디자인 패턴이라는 용어 자체가 다소 생소할 수 있습니다. 대체로 한 명의 엔지니어가 하나의 프로젝트를 끝까지 끌고 가는 경우가 많은데다가, CS 업무까지도 도맡아서 하는 경우가 많기 때문이기도 하고, 래더 다이어그램과 같은 시퀀스 전용 언어를 이용해서 순차적으로 기능을 처리하는 방식의 프로그램을 작성하기 때문에, PC를 베이스로 하는 프로그램과 비교했을 때 많이 단순한 구조를 가지기 때문이기도 합니다. 그렇다 하더라도, 어떤 개발자는 프로그램을 아주 쉽게쉽게 작성해 나가는 경우도 있고, 어떤 개발자는 프로그램을 아주 어렵게 작성하기도 하구요. 또, 어떤 프로그램은 나중에 다른 기능을 확장해서 덧붙이기 쉽도록 만들어져 있기도 하고, 어떤 프로그램은 새로운 기능을 추가할 때 엄청난 노가다를 불러오기도 합니다. 이런 현상을 두고 어떤 사람들은 경험이 축적된 차이라고도 말합니다. 그리고 저는 디자인 패턴의 차이라고 이야기 하지요.

다른 말처럼 보이지만, 사실은 같은 의미를 내포하고 있는 말입니다. 그냥 경험이라는 포괄적인 단어를 통해 추상적으로 표현하였느냐, 디자인 패턴이라는 특정된 단어를 사용했느냐의 차이일 뿐이구요. 한 명의 개발자가 현업에 종사하면서 얻게되는 경험을 통해, 체계적이고 효율적인 프로그램을 작성하는 하나의 패턴을 터득하는 것이구요. 이것이 곧 디자인 패턴이라는 의미입니다.

저도 뉴비 시절에 정말 많이 들었던 말이, '프로그램을 잘 짜려면 다른 사람이 만든 프로그램을 많이 보라.' 인데요. 어떤 문제를 해결하기 위해 다른 개발자들은 어떻게 생각하고 접근하는지가 프로그램의 구조에 녹아 있으므로, 다른 사람이 만든 프로그램을 분석하면서 그 사람만의 유용한 디자인 패턴을 습득하라는 의미라고 해석할 수 있습니다. 다시 말해, 실무에서 본인이 직접 부딪히고 깨지면서 디자인 패턴을 익힐 수도 있고, 다른 개발자들이 다듬고 정립해 놓은 디자인 패턴을 습득할 수도 있다는 말인데요. 이쯤에서 디자인 패턴이라는 것을 '이 바닥에서 비슷한 문제들을 먼저 경험했었던 개발자들이 어떻게 하면 체계적이고 효율적인 프로그램을 작성할 수 있을 것인지를 고민하고 연구한 끝에 만들어진 하나의 방법론' 정도로 정리할 수 있고, 다른 사람들의 디자인 패턴을 이해하고 받아들임으로써 본인의 프로그래밍에 대한 역량 또한 향상시킬 수 있습니다.

C#이나 Java, Python과 같이 여러 종류의 프로그래밍 언어가 있고, 프로그래밍 언어마다 가지고 있는 특징들이 다르듯이, 각 언어마다 디자인 패턴이라는 것도 제각각인 경우가 많습니다. 다시 말해서, 모든 언어를 아우르는 그런 마스터 키 같은 절대적인 디자인 패턴이 있고 그것을 자유롭게 사용할 수 있다면 정말 좋겠습니다만, 불행히도 각각의 언어마다 자신들의 특색을 살린 디자인 패턴들이 존재하기 때문에, 어떤 언어를 공부하느냐에 따라 유니크한 디자인 패턴을 접하실 수도 있구요. 지금은 랩뷰에 관한 내용을 포스팅하는 중이므로, 랩뷰에서 사용하는 몇 가지의 유용한 디자인 패턴을 지금부터 하나씩 정리해 볼까 합니다.

---

서론이 꽤 길었는데, 본격적으로 디자인 패턴에 대해 알아보자면,

랩뷰를 통해 작성되는 프로그램은 대부분 위 그림과 같은 구조를 가지고 있습니다. 그래서 이러한 프로그램을 일반적인 VI의 디자인 패턴이라고도 부르는데요. WHILE 구조를 하나 적용함으로써 원하는만큼 반복해서 실행이 될 수 있도록 만들었다는 것이 특징이라면 특징이라고 말씀드릴 수 있습니다. 즉, 일반적인 VI의 디자인 패턴에서는 WHILE 구조가 핵심이기 때문에, 프로그램이 실행되는 과정에서 반복적으로 처리되어야 하는 작업들을 모두 WHILE 구조 안에 포함시키고, 초기화가 필요한 부분이나 프로그램이 종료되는 단계에서 정리가 필요한 부분들을 WHILE 구조의 왼쪽과 오른쪽에 작성하지요. 일반적인 랩뷰 프로그램의 디자인 패턴이면서, 앞으로 소개될 여러 디자인 패턴의 근간이라고 말씀드릴 수 있습니다.

이러한 일반적인 VI의 디자인 패턴에서는 방금 전에 말씀드렸듯이 핵심이 되는 프로그램들을 모두 WHILE 구조 안에 포함시킵니다. 이 과정에서 시퀀스 처리가 필요하다면 시퀀스 구조가 추가될 수 있구요. 프런트 패널의 조작 정보를 이벤트 구조에 연결해서 이벤트를 처리할 수도 있습니다. 하지만, 처리해야 하는 작업이 많아지게 되면 프로그램의 구성 자체가 상당히 복잡해지기 때문에, 아무리 Sub VI를 통해 작은 단위로 나눠서 프로그램을 작성한다 하더라도 가독성이 많이 떨어질 수 밖에 없습니다.

이런 부분을 보완하기 위해, 랩뷰에서는 위 그림과 같은 방식으로도 프로그램을 작성하는데요. WHILE 구조 내부에 CASE 구조를 하나 추가하고 프로그램의 실행 상태를 의미하는 변수를 연결함으로써, 상태에 따라 처리해야 하는 작업들을 서브 다이어그램에 구현하는 방식이고, 이것을 상태 머신이라고 부릅니다.

이런 상태 머신의 디자인 패턴은 꼭 랩뷰에서만 사용하는 것은 아닙니다. C나 Java와 같은 프로그래밍 언어에서도 Switch 문을 이용해서 상태별로 처리해야 하는 작업들을 나눠서 작성하구요. PLC의 ST 언어에서도 CASE문을 이용해서 상태별로 프로그램을 작성합니다. 즉, 여러 프로그래밍 언어에서 공통적으로 사용될 만큼 확실히 효율적인 프로그램의 작성을 약속할 수 있는 디자인 패턴인데요. 작성된 프로그램을 직관적으로 이해하기에는 효과가 좋은 디자인 패턴이라고 말씀드릴 수 있습니다.

상태 머신의 핵심은 당연히 CASE 구조와 상태 변수인데요. WHILE 구조가 반복되는 동안 프로그램의 상태가 계속 유지될 수 있도록 쉬프트 레지스터를 통해 다음 사이클로 전달한다는 점과 다음 상태로 넘어가는 부분이 프로그램 안에 포함되어 있어야 한다는 점입니다.

다시 말해서, 위 그림과 같이 각 상태마다 어떤 상태로 넘어갈 수 있는지를 설계 단계에서 규정하고, 각 상태별로 처리해야 하는 작업들과 함께 다른 상태로 넘어가는 부분을 프로그램으로 작성해야 한다는 말이구요.

위 영상과 같이 동작하는 것을 확인할 수 있습니다.