[Archive] 강좌게시판
[myLV.net 집필진 강좌 – 웅킹킹킹]
안녕하세요. 웅킹킹킹입니다.
저도 LabVIEW를 열심히 공부할 때 마이랩뷰 파워유저로 활동할 때도 있었는데 어느새 벌써 시간이 흘러서 우연찮은 기회로 이렇게 필진으로 활동하게 되었네요. 아직 부족한 부분이 많이 있지만 제가 아는 바를 최대한 노력하여 효율적으로 전달하려고 노력할 테니 많은 마이랩뷰 유저분들께 도움이 되길 바랍니다.
저의 강좌 제목처럼 “Actor Framework”에 대해 강좌를 만들어 갈 예정입니다.
“Actor Framework”는 OOP(Object oriented Programming) 기반의 Structure 입니다. 기존에 많은 분들이 프로그래밍 하는 POP(Process Oriented Programming) 과는 전혀 다른 패러다임의 프로그래밍입니다. 그래서 중급이상 혹은 QDMH(생산자 소비자 패턴), FGV(Functional Global Variable), LabVIEW OOP에 대해서 능숙하신 분들에게 도움이 될 것 같습니다. LabVIEW에 관심을 가지는 단계나 혹은 입문하시는 분들에게는 추천하지 않습니다. 좀더 LabVIEW 기본기를 탄탄히 다지시는 것을 추천하며 여건이 된다면 NI 교육센터, 혹은 LabVIEW 기본서를 통해 공부하시길 바랍니다.
개인적으로 기본서를 추천하자면 LabVIEW의 정석 2권을 마스터하시는 것을 추천합니다.
그럼 이번 강좌는 Actor Framework에 대해 간단히 알아보는 시간을 가지겠습니다.
‘굳이 Actor Framework를 사용해야 돼?’
‘OOP? QDMH, FGV, 상태머신 등으로 프로그램 충분히 만들 수 있어.!’
‘OOP 조금 해봤는데 Debugging도 힘들고 별로 장점을 못느끼겠어.’
위와 같은 다양한 이유로 OOP로 프로젝트를 진행하는 것에 대한 반감을 가지시는 분들이나
‘이제 대세는 OOP라던데’
‘OOP는 코드의 재사용, 확장 등이 용이하다던데 해야 되지 않을까?’
라고 막연히 생각하시는 분들도 계십니다.
OOP, Actor Framework로 프로젝트를 진행해야 하는 이유를 알아봅시다.
프로그래밍의 역사를 되짚어보면 1960, 70년대 미국에서 프로그램이 굉장히 많이 필요한 시기가 옵니다. 이 때 프로그램의 수요를 맞추기 위해 개발공정이 뛰어난 POP(프로세스 지향적 프로그래밍) 가 발달하게 됩니다. 현업에서 활동하시는 분들 중 아래 그림 1과 같은 flow chart를 정확하게 그리고 프로젝트를 시작하시는 분들은 아마 거의 없을 것입니다.
대충 머릿속에서 구조를 그리고 프로젝트 진행 중 필요한 구조는 적재적소에 대충 끼워 넣어도 프로그램은 훌륭하게 완성됩니다. 매우 효율적인 방법입니다. 그래서 POP가 매우 널리 사용됩니다. 하지만 프로그램이란 것이 생명주기를 가지게 되는 데 오랫동안 사용되는 프로그램은 어쩔 수 없이 확장을 하게 됩니다. 확장 ㅡ> 확장 ㅡ> 확장 끝에 더 이상 확장이 어렵거나 사용하게 되지 않게 되는 프로그램은 소멸됩니다. POP는 이런 프로그램 확장, 유지보수에 치명적인 단점을 가집니다. 많은 프로젝트를 진행해보신 분들은 경험해보셨을 텐데 프로그램 요구사항이 처음과 달라지거나 더 추가될 때의 스트레스는 말로 표현하기가 힘들 때가 있습니다. 고객의 무리한 요구일 때도 있지만 납득이 가는 요구사항인데도 불구하고 작업할 생각을 하면 엄청난 스트레스를 받게 되죠.
위 그림2은 생산자 소비자 구조의 소비자 루프의 케이스구조 입니다. 간단히 케이스구조의 케이스들을 만들어 보았는데 간단한 예로 요구사항이 변경되거나 늘어날 때마다 늘어나는 케이스는 나중에는 감당하지 못하는 사태까지 가는 경우도 많이 생깁니다. 물론 이런 경우는 좀더 고민해서 효율적으로 케이스를 만들거나 FGV 사용으로 억제할 순 있습니다. 하지만 이외에도 중복된 코드에서 수정사항이 생기거나 새로운 구조흐름이 발생하는 등등 말로 상황을 설명치 못하는 경험을 많이 겪어 보셨을 것입니다.
즉, POP 프로세스 지향적 프로그래밍은 애초에 개발 공정에 치우쳐 있고 유지 보수에 소홀한 방식이기 때문에 OOP 객체 지향적 프로그래밍으로 현재 프로젝트 개발 방향이 많이 바뀌고 있습니다. 빠른 프로그램 개발에서 프로그램의 유지보수(확장, 적응, 수정)가 더 중요하게 된 것입니다.
그렇다면 OOP는 어떻게 유지보수가 더 뛰어난가?
이 부분은 이제 우리가 앞으로 배워나갈 부분입니다. 간단히 먼저 알려드리자면 OOP의 상속, Dynamic Dispatch, Overwrite등의 기술을 통해서 POP(프로세스 지향적 프로그래밍)보다 훨씬 더 뛰어난 유지보수 능력을 가지게 됩니다.
OOP를 해야 하는 또 다른 이유 중 하나인 OOP 기반인 Actor Framework는 매우 뛰어난 병렬성을 가지고 있습니다. 추후에 알게 되겠지만 Actor Framework에서 많이 생성하게 될 각각의 Actor는 자신의 행동(알고리즘, 메소드)을 하는 별도의 소비자루프(생산자 소비자 패턴의 소비자루프)를 가집니다. LabVIEW에서 많은 Loop를 Queue로 제어한다는 것은 엄청 고된 작업입니다. 다양한 이유 때문에 병렬루프처리를 해야 할 때가 있습니다. 데이터 연산 처리 속도, 통신 장비, 유저인터페이스 등등.
그림 3을 보시면 데이터 연산, TCP통신, 시리얼 통신 등과 같은 이유로 병렬루프제어를 하는 소스코드 입니다. 물론 각각의 Queue를 클러스터로 묶어서 FGV로 관리하면 훨씬 더 병렬루프제어가 용이하겠지만 그래도 각각의 루프를 제어를 할 때마다 프로그램 흐름 순서를 맞는 지 한번 더 고민해야 합니다. 고된 일입니다.
요즘 컴퓨터는 모두 멀티코어 CPU입니다. 컴퓨터의 리소스를 효율적으로 사용하기 위해선 LabVIEW에서는 멀티루프를 통해 각각의 코어의 리소스를 사용해야 합니다. LabVIEW에서는 각각의 루프를 자동으로 사용할 수 있는 CPU코어에 할당해 줍니다.
그리고 요즘 많은 개발자분들이 느끼고 계시겠지만 프로젝트 난이도가 상당히 올라갔습니다. 전 12년도부터 현업에서 활동했었는데 시간이 흐른 지금 주변에서 지인분들이 진행하는 프로젝트와 제가 최근까지 진행한 프로젝트를 살펴보면 확실히 난이도는 점점 올라가고 있습니다.
전기자동차, 스마트 폰, 인공지능, 로봇 등 요즘 IT 산업의 발전속도를 보면 당연한 이치입니다. 우리 LabVIEW 개발자도 이에 발맞추어 시스템 개발에 있어 발전을 해야 한다는 생각이 듭니다. 발전할 수 있는 방안 중 하나가 “Actor Framework”라고 생각합니다. 지극히 개인적인 견해이지만 평소 프로젝트를 진행하면서 어렵고 힘들었던 부분들을 OOP, Actor Framework가 해결해 줄 수 있을 거라는 확신을 합니다.
하지만 Actor Framework는 OOP 기반의 Structure이기 때문에 프로그램 개발방식이 기존의 POP와 완전히 다릅니다. 프로그램 개발의 패러다임이 전환되어야 합니다. 그래서 기존 POP 중심의 개발에 익숙하신 개발자분에게 진입장벽이 높습니다.
그림 4는 LabVIEW에서 유일하게 제공해주는 Actor Framework 예제 CoffeeShop의 시퀀스 다이어그램입니다. 사람모양은 객체이자 Actor 입니다. ㅡ>는 메시지(QDMH 관점에서 보면Queue에 추가하는 명령) 입니다. Customer, Cashier, Barista, Work Dispatcher 객체가 Actor(배우) 역할로 자기 역할을 수행할 차례를 메시지가 올 때까지 기다렸다가 메시지가 도착하면 자기 역할 수행합니다.
각각의 Actor는 독립적인 활동(병렬성)을 합니다.
그림 1의 Flow Chart와 같이 시스템의 흐름을 생각해서 프로그램을 개발하는 사고에서 Actor Framework는 시스템에서 각각의 역할 수행하는 Actor를 만들어 해당 역할이 필요한 시퀀스에서 Actor에게 역할을 수행하게 합니다.
이는 마치 개발자는 영화감독이 되어 각각의 역할을 필요한 배우를 섭외하여 액션 장면에선 액션배우를 로맨스 장면에선 로맨스 배우를 사용해 영화를 만드는 것과 같습니다. “Actor Framework”라는 이름이 매우 잘 어울린다고 할 수 있습니다.
좀더 쉽게 예를 들면 개발자는 요즘 인기 드라마 “태양의 후예” 드라마 연출자가 되어 송혜교, 송중기를 섭외해서 서로 트럭 위에 탔을 때 키스를 하게끔 역할 지시를 하는 거죠.!
이해가 되셨을 지는 잘 모르겠으나;; 앞으로 Actor Framework로 프로그램을 개발할 때에는 역할을 가진 배우를 잘 섭외해서 그 배우를 적재적소에 잘 써먹어야 한다고 생각하시면 됩니다.
지금까지의 내용을 요약하자면,
- 개발공정 중심의 POP(프로세스 지향적 프로그래밍)에서 유지보수 중심의 OOP(객체 지향 프로그래밍)으로 넘어가자.
- POP와OOP는 프로그램 개발의 패러다임(사고방식)이 바뀐다. 그래서 기존 POP 중심의 개발자의 OOP 진입장벽이 높다.
- 높아져 가는 프로젝트 난이도와 멀티코어 컴퓨터에 맞춰 병렬성이 매우 뛰어난 Actor Framework로 개발해야 한다.
- Actor Framework는 배우를 섭외하여 필요한 장면 하나하나를 만들어 좋은 영화나 드라마, 연극을 만드는 감독과 사고방식으로 프로그램을 개발하게 한다. (그래서 Actor Framework 라는 이름 사용하는 지도 모르겠다.)
지금까지 “Actor Framework”에 대해서 간단히 설명했습니다. 아직 저도 ”Actor Framework”를 공부하는 입장이지만 이렇게 “Actor Framework”, “OOP”를 소개함으로써 같이 알아나가는 기회가 됐으면 좋겠습니다.
앞으로 필진활동은 LabVIEW에서의 OOP (클래스 선언, 데이터 멤머, 메소드 등)를 먼저 소개한 뒤 Actor Framework의 구조설명과 예제를 통해서 공부해나가도록 하겠습니다.
