수 많은 엔지니어와 과학자들이 NI LabVIEW 소프트웨어를 사용해 뛰어난 성능의 측정 및 제어 어플리케이션을 신속하게 개발해 왔지만, LabVIEW를 처음 사용하는 사용자들의 경우에는 어려움이 있을 수 있다. LabVIEW 그래픽 기반 프로그래밍의 특징은 권장하는 코딩 방법을 사용하지 않는 경우 어플리케이션에서 금세 문제점이 드라난다는 점이다. 이러한 실수는 LabVIEW 다이어그램의 데이터 흐름의 배경에 있는 규칙을 잘 이해하기 못한 경우나, LabVIEW 프로그램의 설계된 기능에 익숙하지 않아서 발생하는 경우가 있다. 본 기술 백서에서는 초보 LabVIEW 프로그래머들이 가장 자주 하는 프로그래밍 실수와 올바른 LabVIEW 프로그래밍을 위해 권장하는 방법을 살펴본다.

1. 플랫 시퀀스 구조의 과도한 사용

대다수의 LabVIEW 초보 프로그래머가 LabVIEW 프로그래밍의 근간인 “데이터 흐름” 실행이라는 개념을 제대로 이해하지 못하고 있습니다. 이를 잘 보여주는 현상 하나가 블록다이어그램에 플랫 시퀀스 구조를 지나치게 많이 사용하는 것입니다. 노드 사이의 와이어를 통해 데이터 흐름을 제어하는 것이 아니라 플랫 시퀀스 구조를 사용하여 블록다이어그램에서 강제로 코드의 실행을 구현하는 초보자가 많습니다.

“데이터 흐름” 프로그래밍에서는 필요한 데이터 입력이 모두 들어오기 전까지 블록다이어그램의 노드(subVI, 프리미티브, 구조 등)가 실행되지 않습니다. 이렇게 되면 독립된 프로세스는 기본적으로 병렬로 실행되도록 설정되어 있기 때문에 LabVIEW 프로그래머에게 편리합니다. 반면에 명령형 언어에서 병렬 실행을 하려면 추가적인 설정이 필요하기 마련입니다. 컴퓨터에 점점 많은 CPU가 추가되면 LabVIEW가 자동으로 병렬 프로세스를 오프로드할 수 있게 되므로 사용자가 추가적인 코딩 작업을 하지 않아도 코드 성능이 향상됩니다. 플랫 시퀀스 구조를 지나치게 많이 사용하여 강제로 블록다이어그램의 실행을 구현하면 병렬화에 한계가 발생하여 이와 같은 장점이 사라지게 됩니다. 블록다이어그램에서 불필요한 구조의 사용을 자제하면 전반적인 가독성이 향상되고 다이어그램의 크기도 작게 유지할 수 있습니다.

플랫 시퀀스 구조보다 에러 와이어를 사용하면, 블록다이어그램에서 손쉽게 데이터 흐름을 조절할 수 있으며, 에러 핸들링 전략에도 도움이 됩니다.

그렇다면, 언제 플랫 시퀀스 구조를 사용해야 하는가?

플랫 시퀀스 구조로 실행을 강제 구현하는 것은 코드 성능을 벤치마킹할 때 유용합니다. 프레임 안에 틱 카운트가 들어있는 플랫 시퀀스 구조를 사용하면 코드를 실행하는데 소요되는 시간을 두 개의 틱 카운트 사이에서 결정할 수 있습니다. 일반적인 데이터 흐름 실행을 통해서는 이런 설정을 구현할 수 없습니다.

2. 로컬 변수의 잘못된 사용

LabVIEW 프로그램에서 자주 볼 수 있는 또 하나의 실수는 로컬 변수의 잘못된 사용입니다. 로컬 변수는 컴퓨터 프로그램의 서로 다른 영역 사이에 데이터를 전달하는데 사용되는 공유 메모리 조각입니다. 텍스트 기반 언어에서 널리 사용되는 이 변수는 매우 강력한 기능을 자랑하지만, 경합 조건이 생기면 문제가 발생할 수 있습니다.

변수를 통해 데이터를 전달하는 것이 필수적인 다른 프로그래밍 언어와는 달리 LabVIEW에서는 프로그램의 한 영역에서 다른 영역으로 데이터를 전달할 때 데이터 흐름 방법을 사용할 수 있습니다. LabVIEW에 내재되어 있는 병렬성 때문에 변수를 과도하게 사용하면 문제가 발생합니다. 서로 다른 코드가 동시에 공유 메모리에 접근하게 되는 경우가 많기 때문입니다. 이런 상황이 발생하면 하나의 읽기/쓰기 작업이 “경합”에서 이기며 나머지 작업은 경합에서 지게 됩니다. 경합에서 진 작업은 잊혀지므로 LabVIEW에서 변수를 과도하게 사용하면 결국 데이터 유실이라는 결과로 이어질 수 있습니다.

와이어, 큐, 이벤트, 알림자, 기능적인 글로벌 변수 등의 다양한 방법을 사용하여 LabVIEW 프로그램의 한 영역에서 다른 영역으로 안전하게 데이터를 전달할 수 있습니다. 이러한 매커니즘은 각각 특정한 사용 예를 위해 설계되었지만, 모두 경합 조건을 제거한다는 장점을 가지고 있습니다.

3. 코드의 모듈성 무시

LabVIEW 초보 사용자는 단순한 작업을 하기 위해 “일회성” 어플리케이션을 생성한 다음 그 코드를 향후에 어떻게 활용할 수 있을지에 대해 생각하지 않는 경우가 많습니다. 프로그램을 자주 만들게 되면 똑같은 코드를 여러 차례 반복해서 작성하게 되기 마련입니다. 코드 중 일부를 모듈형 SubVI로 만들어서 다른 어플리케이션에서 재활용할 수 있도록 하면 상당한 개발 시간을 절약할 수 있습니다.

코드의 특정 부분을 같은 어플리케이션 내에서 재활용할 예정이거나 향후의 어플리케이션에서 재활용할 수 있을 것 같은 생각이 드는 경우 약간의 시간을 투자하여 그 부분을 SubVI로 만드십시오. 코드의 일부를 SubVI로 만들기 위해서는 설명을 추가하고, 커넥터 팬을 사용하고, VI 프로퍼티의 일부를 비활성화 해야 합니다. SubVI를 생성하는 가장 손쉬운 방법 중 하나는 블록다이어그램 코드의 일부를 하이라이트 한 후 메뉴 모음에서 편집≫SubVI 생성을 선택하는 것입니다. 이렇게 하면 코드의 해당 부분을 별도의 VI로 만들고 커넥터 팬을 사용하는 프로세스가 시작됩니다. 그 다음에도 아이콘을 알아보기 쉽도록 편집하고 블록다이어그램과 VI 프로퍼티에 설명을 추가하며 일부 VI 셋팅을 비활성화하는 작업은 남아있지만, 편집≫SubVI 생성은 코드 모듈화의 좋은 출발점 역할을 합니다.

코드를 재활용하려 할 때 반드시 비활성화 해야 하는 VI 셋팅은 디버깅 허용입니다. 이 옵션은 VI 프로퍼티(파일≫VI 프로퍼티) 내의 실행 항목에서 찾을 수 있습니다. 코드가 완전히 작동하기 시작하여 더 이상 실행 하이라이트와 같은 디버깅 기능이 필요하지 않은 경우 실행 셋팅에서 디버깅 허용을 비활성화 하고 VI를 다시 실행합니다. 이렇게 하면 디버깅을 위한 추가적인 코드가 제외되어 컴파일 과정 중에 보다 효율적인 최적화가 일어나므로 어플리케이션의 실행 속도가 빨라지고 VI가 디스크에서 차지하는 물리적 크기가 다소 작아진다는 장점이 있습니다.

4. 지나치게 큰 블록다이어그램 생성

LabVIEW 초보 사용자들이 블록다이어그램을 작성하다 보면 지나치게 커지는 경우가 많습니다. 물론 어플리케이션이 복잡하여 어쩔 수 없이 다이어그램의 크기가 커지는 경우도 있지만, 프로그래밍 아키텍처가 제대로 갖춰져 있지 않은 것도 하나의 원인입니다. 바탕이 되는 아키텍처가 없으면 시간이 지남에 따라 프로그램을 관리하기 어려워지며 향후에 새로운 기능을 추가할 때에도 많은 비용이 듭니다. 올바른 토대가 있어야 튼튼한 집을 지을 수 있듯이, 좋은 프로그래밍 아키텍처는 어플리케이션의 안전하고 든든한 프레임워크가 되어 줍니다.

소프트웨어 아키텍처는 거의 모든 프로그래머가 유용하게 사용하는 보편적인 프레임워크입니다. 생산자/소비자나 상태 머신과 같은 LabVIEW 내의 여러 아키텍처는 다른 프로그래밍 언어의 아키텍처와 유사합니다.

LabVIEW 아키텍처를 이해하면 개발 시간을 단축하고 어플리케이션의 확장성을 향상시킬 수 있습니다. LabVIEW 2012 및 이후 버전에는 템플릿과 샘플 프로젝트가 포함되어 있어 아키텍처를 더욱 쉽게 이해할 수 있게 되어 있습니다. 템플릿은 다양한 아키텍처를 설명하고 어떤 경우에 각 아키텍처를 사용해야 하는지 보여줍니다. 샘플 프로젝트는 템플릿을 기반으로 하여 작성한 보다 큰 어플리케이션으로, 실제 사례에서 템플릿을 어떻게 응용할 수 있는지 보여줍니다. 샘플 프로젝트에 하드웨어를 연결하여 턴키 어플리케이션으로 사용할 수도 있지만, 샘플 프로젝트는 기본적으로 열린 구조이며 상세한 설명이 달려있기 때문에 어플리케이션의 용도에 맞도록 맞춤 구성할 수도 있습니다.

5. 문서화의 중요성 간과

다른 사람이 작성한 프로그램이 어떤 기능을 하는지 파악하는 과정에서 코드에 적절한 설명이 달려 있으면 큰 도움이 됩니다. 그러나 안타깝게도 기능이 완성되어 개발 주기가 끝날 때까지 코드를 문서화하는 작업은 등한시되는 것이 보통입니다. 이렇게 되면 코드를 제대로 문서화할 시간이 부족하게 됩니다. 그보다는 개발 도중에 별도로 시간을 내서 문서화 작업을 시작하는 것이 좋습니다. 문서화가 잘 되어 있으면 해당 코드를 작성한 사람에게도 큰 도움이 됩니다. 나중에 코드를 다시 보면서 어떤 생각으로 특정 코드 영역을 선택했는지 기억하지 못할 때가 있기 때문입니다. 많은 프로그래머들이 그렇듯이, 늦은 밤에 커피를 마시며 프로그래밍을 하다 보면 잘 기억이 나지 않을 수도 있습니다. 그럴 경우 문서화를 잘 해놓으면 프로그래머들이 기억을 환기시키는데 도움이 됩니다.

일반적으로 LabVIEW는 그래픽을 기반으로 하고 있기 때문에 텍스트 기반 프로그램보다 코드를 파악하기 쉽지만, 문서화를 잘 해놓으면 프로그램을 “해독”하는데 필요한 시간을 더욱 단축할 수 있습니다. 블록다이어그램을 문서화하는 가장 쉬운 방법은 독립 라벨을 사용하는 것입니다. 블록다이어그램의 빈 공간에서 마우스 왼쪽 버튼을 더블 클릭한 후 텍스트를 입력하면 독립 라벨이 추가됩니다. 그 다음 화살표 장식을 사용하여 독립 라벨이 설명하고 있는 특정 코드 부분을 가리키면 됩니다. 그림을 추가하려면 클립보드에 복사하고 블록다이어그램에 붙여 넣기 합니다. 물리적 시스템이나 수학 공식의 이미지를 추가하면 사용자들이 블록다이어그램 내의 코드 내용을 구성하는데 도움이 됩니다.

코드를 문서화하는 작업은 단순히 재활용 라이브러리뿐만 아니라 모든 프로그램에 필요합니다. 타인에게 무언가를 가르쳐야 하는 입장이 되면 해당 주제에 대해 더 많은 것을 배우기 마련입니다. 문서화 작업을 하다 보면 사실상 가르치는 입장이 되므로 프로그래머들도 자신이 작성한 코드를 더욱 잘 이해하게 됩니다.

LabVIEW는 엔지니어와 과학자들이 세계에서 가장 까다로운 문제를 보다 성공적으로 해결할 수 있도록 지원하기 위해 개발되었습니다. 수많은 엔지니어와 과학자들로 구성된 커뮤니티를 통해 다른 개발자들의 노하우를 확인하십시오. 나누고 싶은 LabVIEW 초보 사용자의 실수가 있다면, bit.ly/lvrookiemistakes를 방문하여 여러분의 의견도 함께 공유해 주시기 바랍니다. [제공. NI코리아]