GUI 개발에 대한 고민

happymovie222의 이미지

저는 어느 연구실 박사 과정으로 일을 하고 있습니다. 큰(?) 프로젝트 하나를 진행하고 있습니다. GUI를 포함하는 툴을 개발하는 일입니다. 한데 동료와 일의 분배에 관해 약간 트러블이 있습니다. 저도 제 입장이 있지만, 그것보단 객관적인 의견들을 듣고 싶어서 질문을 올리게 되었습니다.

질문의 핵심은 GUI 언어를 저의 상황에서 나머지 툴 전체와 다르게 할 이유가 있는가, 하는 것 입니다. 읽고 답을 주실 분들께 미리 깊이 감사드립니다.

간단하게 상황 설명을 드리겠습니다. Library라고 불릴 만한 게 있습니다. 이 라이브러리엔 컴포넌트가 들어 있습니다. 비유하자면, 자동차를 만드는 툴이고, 라이브러리엔 사용 가능한 모든 부품들과, 그 유효한 조합에 대한 규정이 들어 있습니다. 이를테면, 자동차 앞문 두 개는 서로 같아야 하며, 문은 2개 또는 4개만 쓸 수 있다, 같은 식의 제약입니다. 사용자는 GUI로 컴포넌트를 끄집어 내서 조합합니다. 툴은 사용자가 유효한 조합을 하도록 유도해줘야 합니다. 일단 유효한 조합이 결정나면, 이 툴이 매 단계마다 하나의 서브 툴(커맨드라인 툴)을 불러서 자동차를 제조해 나갑니다. 모든 서브 툴을 거치면, 자동차가 나오는 셈이고요. GUI는 사용자가 처음에 유효한 컴포넌트 조합을 하도록 돕고, 제조 공정의 매 단계마다 버튼을 클릭하면 거기 맞춰 서브 툴을 불러주는 역할을 합니다.

모든 라이브러리/서브 툴은 모두 C++로 작성되어 있습니다. 한데, GUI는 QT python으로 되어 있습니다. 이유는 저도 모르겠습니다. 이제 자동차 부품 및 그 유효한 조합에 대한 규정이 크게 변경될 예정입니다. 기존 GUI는 버그가 매우 많습니다. 제 동료는 아마도 과거의 코드를 재활용 할 수 있을 거라는 기대(저는 무리라고 봅니다), 그리고 가장 잘 할 수 있는 언어가 그거라는 이유 때문에 QT python을 선호하는 것 같습니다.

저는 GUI 전문가가 전혀 아닙니다만, 전에 얼핏 듣기로 C++ 라이브러리에 GUI를 다른 언어로 하는 상황이 바람직하지 않다고 했던 것 같습니다. 이쪽 일을 하시는 분이 계시면, 여기에 관해, 정말 바람직하지 않은지, 그렇다면 왜인지 조언을 조금 들을 수 있을지요?

저의 주된 업무 영역은 '서브 툴'로 지칭된 GUI를 뺀 나머지 영역입니다. 하지만 상황상 GUI 작업이 어떻게 진행되고 있는지에 대해 그 코드 작성자 수준의 이해가 필요하므로 이따금 질문을 올릴 수 있는-그런 것이 허용되는 관습을 지닌, 개발자가 많은-곳이 필요합니다. 그런 곳을 소개받을 수 있을지요?

감사합니다.

bootmeta의 이미지

qt 라이센스만 잘 지킨다면 특별한 문제가 있을 것 같지는 않군요.
특히 Pyqt처럼 공식적으로 Qt개발한 곳에서 python을 합쳐 놓은 라이브러리라면 interface면에서도 복잡할 것 같지 않습니다.

danskesb의 이미지

PyQt는 Qt 개발한 곳에서 개발한 라이브러리가 아닙니다. PySide가 거기 더 가깝습니다.

bootmeta의 이미지

그렇군요. 역시 어설프게 알면 독 :)

winner의 이미지

하지만 어려운 점도 분명히 있습니다. 장단점은 잘 알고 계시니까 어느 쪽이 이익이 큰지 판단하하시기만 하면 되죠.
문제는 happymovie222님이 전체에 대한 책임이 큰 것 같은데 GUI쪽에서 관리가 어렵다는 것이 문제겠죠. 또한 GUI 하시는 분도 happymovie222님의 작업과의 경계영역에서 어려운 점이 있을테고요. C++와 Python 양쪽을 잘 할 수 있는 사람이 있으면 좋겠지만 그런 사람은 비싸겠죠... ^_^. 아니면 happymovie222님이 직접 C++로 GUI를 만드실 수 밖에 없고요.

익명 사용자의 이미지

다시 한 번 읽어봐도 장단점을 모르셔서 질문하신 것 같은데요.

happymovie222의 이미지

우선 답변 감사합니다.

혹, 제가 읽고 판단할 수 있을 만한 문서를 소개 부탁드릴 수 있을까요? 아니면, 짧게라도 장단점을 소개해 주실 수 있으신지요?

저는 CS 출신도, 응용 프로그래머도 아니어서 이런 이슈를 접할 기회가 드물었습니다.

익명 사용자의 이미지

Library는 c++로 되어 있고 GUI는 PyQT 라면, 실제로 해당 Library를 python module로 사용하게 해주는
wrapper는 누가 작성하는 것인가요 ?

A.

 + [py wrapper],  [PyQt GUI]
B. [cpp lib], [py wrapper] + [PyQt GUI]
 
일을 분배할 때 A,B를 명확히 하시는게 좋을 것 같습니다.
 
그리고 lib는 c++,  gui 는 python으로 나누는 것이 바람직하냐 안하냐는
해당 project의 Life Cycle을 어떻게 보느냐에 달려 있다고 생각 됩니다.
 
만약 대부분의 지적 재산이 c++ library안에 있고, 해당 library가 앞으로도 계속
발전되고, 키워질 거라면 서로 다른 language로 가는것이 그리 나쁘지는 않다고 봅니다.
(적어도 GUI코드와 섞어져서 나중에 분리작업을 또해야 하는 일은 안생깁니다.)
 
그렇지 않고 GUI가 포함된 전체가 하나의 project진행되고 종료될 꺼라면, 중간 wrapper작업을
하지않고 모두 c++로 하는 것이 바람직해 보입니다.
 
먼저 해당 project의 큰 그림에 대해서 서로 agree를 하시고 그 원칙하에서
서로 협의하여 선택하시면 좋을 듯 합니다.
happymovie222의 이미지

wrapper를 저더러 만들라고 하는 상황입니다. -_-; 제가 거의 몇 만 라인 단위를 추가해야 할 상황인데, 제가 wrapper 만들면, 자기는 그냥 call 하고 에러 메시지 받아 출력하겠다고 하고 있습니다. Java의 NetBeans 같은 툴이 QT에도 있을텐데, 그럼 도대체 뭐를 하겠다는 건지 저는 잘 모르겠어요.

프로젝트는 앞으로 아마도 장기간 유지될 것을 고려하여 만들어야 할 것 같습니다. 그 경우, GUI와 엔진 언어를 분리하는 게, 적어도 코드 관리 측면에서 장점은 있다고 이해해도 좋겠네요.

답변 감사드립니다.

winner의 이미지

아무리 생성도구를 쓴다고 해도 이건... GUI 개발자 쪽도 쉽지 않겠군요. 그정도 규모라면 새로 작성한다는 것도 현실적으로 어렵지 않나요?

happymovie222의 이미지

제가 추가할 전체 코드가 1.5년 내에 몇 만 줄 수준이라는 얘기였구요. 알고리즘이 있어 코딩만 하면 되는 게 아니라, 코딩은 전체 연구의 일부에요. wrapper는 그렇게까지 많진 않을 겁니다. 다만 제가 느끼기엔 제 일이 더 많은 것 같은데 wrapper조차 저더러 하라고 하는 게 좀 당황스러웠습니다. 그런 의미였는데 분명하게 쓰질 못한 것 같습니다.

winner의 이미지

제가 생각하기에는 GUI 개발 framework은 Python과 Qt로 나두고 wrapper 생성은 GUI 개발자에게 넘기는 형태가 좋을 것 같습니다. 다만 어떤 것들을 접근하게 할지 그 interface를 명확히 정의해주는 것은 happymovie222 님이 잘 해주셔야 할 것 같고요. 몇만줄 수준의 code라면 작은 양이 아닌데 언어간 상호동작이 잘 이루어진다면 분리하고 다르게 가져가는 것은 전체 설계 관점에서 좋다고 봅니다.
설계관점에서 여러가지 더 생각해볼 수 있다면 좋을만한 수준의 규모입니다만 설계를 잘 이끄는 것이 어려운 현실인 것 같고, 또 그게 중요한 것 같지는 않네요.
협상이 잘 되지 않는 상황인 것 같은데 잘 끝났으면 좋겠네요.

happymovie222의 이미지

확인이 늦었지만 답변 감사드립니다.

kalevala의 이미지

pyQt 로 제작되었다면, LGPL적용이 되지 않습니다. 그렇다고 최근에 나온 Pyside로 제작된

것일 가능성은 적으리라 봅니다. 무엇보다 QT로 가닥을 잡으셨다면 python으로 하나 C++로

하나 매한가지라서 기존의 것이 아주 거대하지 않다면 c++로 포팅이 더 나을 수도 있겠습니다.

더군다나 버그가 많다고 하니 대대적으로 손을 보아야 하는 상황이 아닌지요.

개인적으로는 c++/python 각각으로 QT를 다룬 적이 있습니다만, pyQT 다룰 땐 swig를 통해

독립적으로 수행되는 c++ 모듈만 끼얹은 적은 있습니다. GUI 와 서브 툴(?) 간에 데이터 교류가 빈번하다면

이 부분이 매우 피곤하지 않겠나 싶군요.

happymovie222의 이미지

답글을 보고 라이센스 문제를 찾아 보니, QT 최신 버전과 달리 pyQT는 저희 툴을 완전 공개하거나 혹은 상용 라이센스를 구입해야 하는 것 같아 보였습니다. 이건 막연하게만 혹시 이런 거 아닌가 생각했는데 구체적으로 알게 되었습니다.

그리고 이 툴 내의 작은 커맨드라인 툴들과는 텍스트 형식으로 메시지를 주고 받지만, 라이브러리와는 교류가 빈번한데, 라이브러리 코드는 C++입니다. swig를 통해 wrapper를 만드는 과정이 매끄럽지 않다는 말씀이지요?

답변 감사드립니다.

klyx의 이미지

PyQt로 이미 짜여진 코드의 재활용에 대한 질문이므로 별로 도움이 안되는 정보이겠지만, 참고로 적자면...
말씀하신대로 PyQt는 LGPL이 적용되지 않습니다.
노키아에서 Qt를 인수하여 LGPL로 공개할때, PyQt의 제작사와도 협의를 해봤지만 결국 PyQt를 LGPL로 공개시킬수가 없어서,
노키아에서 직접 시작한 프로젝트가 PySide이고, 이쪽은 LGPL로 배포되는 Qt의 Python 바인딩입니다.
PySide와 PyQt의 차이점은 (혹시 궁금하시다면) 다음 페이지를 참고하시면 될 듯합니다.
http://developer.qt.nokia.com/wiki/Differences_Between_PySide_and_PyQt

익명 사용자의 이미지

wrapper를 툴이 자동으로 생성해 줄 수 있는 상황이 아니라면, [라이브러리]와 [GUI]라는 큰 덩어리의 일에 [wrapper]라는 큰 덩어리의 일이 하나 더 추가되어야 하는 것으로 보이고, 제가 관리자라면 라이브러리와 GUI를 맡은 개발자들이 [wrapper]를 서로에게 떠넘기려고 싸우게 두지 말고 그것을 전담할 사람을 한 명 더 배치하겠습니다. 그런 식으로는 둘 중 누가 맡더라도 만족스런 품질이 나올 것 같아보이질 않네요.

물론 그 전에 과연 한 사람을 더 배치할만큼, [wrapper]라는 덩어리의 일이 꼭 필요한 것인지부터 검토를 하겠습니다만. 전 좀 회의적이네요.

무엇보다 GUI 개발에 꼭 python이 사용되어야 할 이유가 별로 없어 보입니다. 이미 개발된 베이스가 방대하지 않다면, 빨리 C++로 옮기는 편이 앞으로 두고두고 편할 것으로 보이는데요.