[스크랩] Qt 소개

아래 내용은 링크의 내용입니다. 더 많은 자료가 있으니 필요하신 분은 들어가서 보세요.

---

링크 : http://xylosper.net/106?category=13

블로그에 좀 알찬 내용이 없는 듯하여 Qt를 소개하는 글을 좀 적어볼려고 합니다.
사실 Qt 강좌 라는 이름으로 시작할까도 생각해봤지만, 저도 잘 모르고 강좌라고 시작해놓고 제대로 마무리도 못하면 하느니 못하단 생각에 그냥 'Qt에 대하여'라는 제목으로 글 몇개 쓸려고 합니다.
그럼 시작합니다.

0. Qt 소개

직업으로 프로그래밍 하시는 분들이 아닌, 그냥 공부하는 학생이나 취미로 프로그래밍하는 분들에게는 아마 Qt라는 이름조차도 생소한 분들이 많을 것이라고 생각합니다.

구글에서 Qt로 검색해보면 나오는 것들은 크게 세가지가 있습니다.

1. QuickTime Player
2. Quiet Time
3. Qt

바로 3번이 제가 소개할 Qt입니다.

Qt의 이름에 대한 자세한 소개

위에서 적은 세가지 Qt(QT)를 보면, 1, 2번은 풀어쓴 말이 있는데, 3번은 그냥 Qt라고만 적었습니다.

사실 Qt는 LG나 GS처럼 '제작자쪽이 정한 공식적인 약어'가 없습니다.

다만, LG가 럭키금성의 줄임말이라고도 알려진 것처럼, 일반적으로 Qt는 Q-Toolkit의 약자로 알려져있습니다.

그럼 Q는 무엇인가하면, 처음 Qt가 만들어질 당시, 제작자가 사용하던 Emacs(편집기)의 폰트에서 Q라는 글자가 굉장히 맘에 들어서 Q를 가져다 붙였다는 이야기가 있습니다.

하지만 이제는 Qt자체를 하나의 고유명사로서 생각하는게 좋다고 생각합니다.

실제로 Qt의 제작사를 가봐도 Qt toolkit이라고 소개되었기 때문에, Qt를 Q-Toolkit으로 생각하면 Q-Toolkit toolkit이라는 말도안되는 단어가 되버립니다.

앞으로 글을 적을때는 매번 한영 전환해서 Qt라고 적기가 불편하므로 Qt와 '큐티'를 병용하겠습니다.

큐티는 노르웨이의 트롤테크라는 회사에서 만든 크로스플랫폼을 위한 C++라이브러리입니다.

크로스플랫폼이란?

크로스플랫폼이란 말을, 프로그래밍을 하시는 분이라면 한번쯤은 들어보셨을 것 같습니다.

사실 저도 그냥 느낌상으로만 알고 있고 정확한 정의는 잘 모르므로, 그냥 제가 아는대로만 적어보겠습니다.

'프로그램이 실행되는 환경'을 플랫폼이라고 합니다.

이는 비단 아키텍쳐(인텔/AMD의 x86등)뿐만 아니라, OS도 해당됩니다.

맥북같은 경우 윈도우와 같은 x86 32bit환경이지만 OSX라는 운영체제가 탑재되어있고, 이경우 윈도우와 OS는 서로 다른 플랫폼입니다.

또, 같은 윈도우위에서도 Java로 짜인 프로그램은 자바런타임환경(JRE)의 가상머신에서 돌아가고, 닷넷프로그램은 닷넷프레임워크위에서 돌아가므로 이들도 또한 다른 플랫폼이라 할 수 있습니다.

하지만, JRE와 닷넷프레임워크는 언어자체가 다르므로 한 언어의 라이브러리가 크로스플랫폼을 지원한다고하면, 보통 OS수준의 플랫폼이라고 생각하면 됩니다.

그럼 크로스플랫폼이 무엇인가하면, 간단하게 말하자면, 복수의 플랫폼을 지원한다는 뜻입니다.

예를 들어, 유명한 MS의 MFC같은 경우는 윈도우에서만 컴파일되고 실행될 수 있습니다.

이런 경우 MFC는 단일 플랫폼 라이브러리인 것입니다.

Qt의 경우는 윈도우뿐만아니라 맥, 리눅스와 각종 메이저한 유닉스에서 컴파일되고 실행될 수 있고, 이것을 크로스플랫폼이라고 합니다.

Java의 경우도 적절하게 구현된 JVM만 있다면 어떤 OS에서든지 실행되므로 크로스플랫폼이라고 할수 있습니다.

단, Java의 경우는 컴파일된 결과가 기계어가 아닌 바이트코드이기 때문에, 컴파일된 결과물을 가지고도 다른 플랫폼에서 실행하는 것이 가능하지만, Qt의 경우는 C++을 이용하고 있고, 네이티브하게 컴파일되기 때문에, 컴파일된 결과물은 다른 플랫폼에서 실행할 수 없고, 소스차원에서의 크로스플랫폼을 지원합니다.

직업으로 프로그래밍하는 분이 아닌, 취미로하거나 공부/연구에 필요해서 프로그래밍을 하시는 분중에, C++을 이용하여 GUI프로그램을 만든다고 하면, 대부분이 Visual C++의 MFC를 이용해서 프로그래밍을 하고 있지 않나, 라고 생각합니다.

그런데, 정품이용자분들께는 죄송하지만, 이런 분들중에 정말로 Visual C++을 구입해서 사용하시는 분들이 몇이나 되실지 궁금합니다.

Visual C++자체는 익스프레스버젼도 있고해서 정품윈도우를 이용하시는 분은 공짜로 이용가능하지만, MFC는 그렇지가 않습니다.

MFC는 상용 Visual Studio를 구입해야 이용할수 있으며, 절대로 공짜도 아니고 그냥 쉽게 프로그래밍 공부하기위해서 사볼만한 가격도 아닙니다.

하지만 Qt는 듀얼라이센스를 적용하여, 일반 사용자들은 공짜로 이용할 수가 있습니다.(자세한건 글 마지막에 라이센스에 대한 부분에 적겠습니다.)

사실 저도 처음엔 MFC로 프로그램을 만들었었고, C++로 윈도우에서 뭐만들려면 Win32API직접 쓰는거 빼곤 그거밖에 없는 줄 알았습니다.

하지만 큐티를 알게 된 후에는 왜 처음부터 이걸 안썼을까, 라는 후회가 들정도로 잘 짜여진 라이브러리입니다.

그럼 큐티로 뭘 할수 있냐? 고 물어보시면, 대답은 '다'입니다.

처음에도 적었듯이 저도 전문가가 아니기 때문에 확답은 하기 힘들지만, MFC로 할수 있는건 당연히 다 할수 있고, 그이상의 것도 훨씬 쉽게 할수 있다고 생각합니다.

게다가, 예를 들어 윈도우에서 프로그램을 만드는데, 이부분은 정말 Win32API를 쓰지 않으면 구현이 불가능한 부분이라고 생각되면, 그부분은 그냥 직접 windows.h를 인클루드하고 가져다 쓰면되기 때문에, 딱히 제한될만한 것도 없다고 생각됩니다.

다만 이런경우는 이식성이 없는 코드가 되겠지요.

그럼, 큐티의 장점을 몇가지 적어보면...

1) 크로스 플랫폼

일부 플랫폼 의존적인 함수를 쓰지 않는다면, 정말 윈도우에서 짠 소스 그대로 리눅스로 가져가서 컴파일해도 똑같은 결과가 나옵니다.

덕분에 예를 들어, 리눅스 어플을 만들어야 하는데, 리눅스에선 익숙한 편집기도 없다, 이럴땐 그냥 윈도우에서 쓰던 편집기로 작성하고, 디버깅도 다 윈도우에서 한다음에, 리눅스에선 컴파일만 하고 간단히 테스트만 해보는 식으로도 어플리케이션을 만드는게 가능합니다.

2) 잘 짜여진 객체지향 라이브러리

사실 전 그냥 취미로 하기 때문에 어째서 Qt가 MFC보다 더 객체지향적인지는 딱 꼬집어 설명할 실력이 못됩니다만, 그냥 써봐도 MFC에서는 난해했던것이 Qt에서는 간단하고 명료한 느낌이 많이 들며, 일반적으로도 Qt가 MFC보다 잘 짜여져있다고 많이들 하시더군요.
Qt와 MFC를 비교한(비교라기보다는 MFC에 비해 Qt가 뛰어난 것들을 적어놓은) 글을 한번 읽어보시면 도움이 될지도 모르겠습니다.

3) 보다 직관적인 GUI 디자인

처음엔 MFC에서 다이얼로그 만들고 거기에 콤보박스나 라디오버튼 같은거 메뉴에서 끌어다가 붙이기만 해도 창이 완성되는 걸 보고 참 MFC는 대단하구나...라고 생각하곤 했습니다.

하지만 Qt로 그런 창을 디자인해보면 MFC의 디자인방식은 정말이지 못해먹을 짓입니다.

Qt에서도 Qt Designer 라는 프로그램을 이용하여 쉽게 창을 디자인 할수 있습니다.

MFC처럼 각종 컨트롤(위젯)들을 끌어다 놓기만 해도 되는건 물론이거니와, 레이아웃시스템 덕분에 일일이 줄맞추거나 창이 리사이즈될때마다 크기나 위치를 일일이 지정해줄 필요가 없습니다.

게다가 간단한 시그널/슬롯(Qt의 이벤트 처리 방식중 하나입니다. 이번 글은 아니지만, 나중에 자세히 적을 것입니다.)지정도 가능합니다.

물론 디자이너를 쓰지 않고 직접 코드로 짜는 것도 가능하며, 사실 디자이너로 디자인된 파일도 변환기를 거쳐서 최종적으로는 C++코드로 변환되어서 컴파일됩니다.

그렇기 때문에, 디자이너로 생성된 컨트롤들도, MFC에서는 리소스로 관리하여 변수와 연결해줘야 하는 반면에, 그대로 하나의 객체로서 다룰수 있어 더 직관적입니다.

4) 간편한 리소스관리

프로그램에서 아이콘을 가져다 써야하거나, 소리를 내야하는 경우, 외부파일을 가져다 쓰는 경우도 있지만, 이런 경우는 매번 배포할때마다 같이 챙겨서 배포해야 하기때문에, 실행파일 자체에 집어넣고 가져다 쓰는 경우가 많습니다.

큐티에서는 간단하게 리소스로 가져다쓸 파일 목록만 작성해주면, 알아서 컴파일시에 포함시켜주며, 프로그램내에서 그 파일들을 가져다 쓸 땐, 로컬파일과 거의 동일하게 이용가능합니다.

5) 다국어지원 및 국제화에 강하다

Qt는 QString이라는 자체적으로 구현한 문자열 클래스를 이용합니다.

이 QString은 내부적으로 유니코드로 문자열을 처리하기 때문에 예를들어 일본어와 한국어를 동시에 다루어야 하는 프로그램등을 인코딩문제때문에 골머리 썩힐 필요도 없습니다.

게다가 프로그램을 다른 언어로 번역해야 할 경우, 소스코드에 적힌 문자열들 중에 번역이 필요한 문자열들만 골라서 따로 표시해주고, 이것들을 번역하여 프로그램 실행시에 번역된 파일을 선택함으로서 쉽게 여러 언어를 지원하는게 가능합니다.

6) 풍부한 문서와 예제

MFC를 이용함에 있어서 MSDN만큼이나 큰 조력자도 없을 것입니다.

Qt에는 Qt Assistant 라는 도움말이 있습니다.

이것은 Qt의 모든 클래스와 각종 모듈 및 기능, 예제에 대한 설명이 포함되어있으며, 사실 웹상에서 질문되는 Qt에 대한 질문중 반이상은 Assistant를 찾아보면 이미 답이나 해결책이 나와있는 것들입니다.

또한, Qt는 많은 예제를 포함하고 있습니다.

설명만으론 어떻게 써야할지 막막한 경우 대부분 예제를 통해서 사용법을 익히는게 가능하며, 예제에 대한 해설또한 assistant를 통해서 제공됩니다.

앞으로 종종 '자세한건 assistant를 참고하세요'라는 말을 하게될 것입니다.

7) 강력한 모듈들

Qt는 단순한 GUI용 라이브러리가 아닙니다.

어플리케이션을 개발하는데 필요한 컴포넌트들의 총체라고도 할 수 있을만큼 다양한 모듈들을 내장하고 있습니다.

간단히 이름만봐도 뭐하는 건지 알만 모듈 몇가지만 적어보면,

QtSql, QtXml, QtOpenGL, QtNetwork...

이외에도 2008년 2사분기 말에 릴리즈될 예정인 Qt4.4에는 멀티미디어를 위한 Phonon과 Webkit이 추가됩니다.

모듈들에 대해선 자세히 설명할 기회가 다음에 또 있을지도 모르겠습니다.

8) Generic Containers

C++을 유용성을 논할때 STL을 빼놓고는 이야기할 수 없을 것입니다.

이 STL에 대응하여, 종종 QTL(Qt Template Library)라고 불리는 Generic Container가 존재합니다.

물론 STL을 그대로 써도 좋습니다만, 예를 들어 STL에는 포함되어있지 않는 해쉬테이블등이 필요한 경우라면 Qt의 Generic Containers중 하나인 QHash를 이용하면 되겠지요.

또, 이것들은 STL스타일의 반복자나 함수들도 대부분 존재하기 때문에, STL에 익숙한 분도 쉽게 이용할 수 있으며, 특히나 편리한 것은 Java스타일의 반복자들입니다.

이또한 따로 자세히 설명할 기회가 있을 듯합니다.

이상 큐티의 장점으로서 8가지를 언급했습니디만, 사실 이건 당장에 생각나는 것들만 적은 것이므로, 앞으로 업데이트될 수도 있습니다.

그럼 무조건 큐티가 좋냐, 하면 단점도 있습니다.

1) 컴파일 시간이 길다

큐티는 이식성도 떨어지고 성능에도 문제가 있는 RTTI대신에 Meta-Object System을 이용합니다.

단순히 타입정보를 알기위한 것 뿐만 아니라 이벤트처리나 프로퍼티처리를 위해서도 이용되는 것입니다만, 이것을 이용하기 위해서 일단 소스파일을 moc(Meta-Object Compiler)에 통과시켜서 moc파일을 생성한후에 컴파일하기 때문에 일반적인 컴파일 시간보다 시간이 오래걸립니다.

2) 용량이 크다

라이브러리가 방대한 만큼 큐티자체의 용량도 크며 빌드된 바이너리의 용량도 MFC에 비해 약간 큽니다.

이정도의 단점이 생각납니다만, 혹시 경험자분들중에 다른 단점이라고 생각되는 것이 있으시면 알려주시기 바랍니다. 추가하도록 하겠습니다.

마지막으로 라이센스에 대한 이야기를 하려고합니다.

Qt는 4.4.x까지는 QPL/GPL의 듀얼 라이센스 정책으로, 소스비공개의 상용 프로그램을 개발하기위해서는 라이센스비용을지불하고 이용해야 했습니다.

하지만 Qt4.5부터는 LPGL이 추가되었기 때문에, Qt4.5이상을 이용할 경우 라이센스 비용을 지불하지 않더라도 소스를 공개할필요가 없어졌습니다.
물론 기존과 동일하게 GPL을 이용하는 것도 가능합니다.

4.4까지는 무료이용을 위해선 소스공개를 해야한다는 제약에 꺼려지는 경우도있었지만, 이제는 LGPL이 정한 내용에 따르기만 한다면(수정부분 소스공개) 정말 자유롭게 이용할 수있게 되었습니다