네이티브로 가자!

조용했던 그동안 많은 일이 있었습니다. 다니던 회사가 자금사정이 악화되어 한국지사가 폐쇄되었고, 여차저차해서 작은 회사의 모 제품 시스템 엔지니어 겸 개발자가 되었습니다. 그리고 원래대로라면 엔지니어링과 개발이 50:50이 되어야 하는데, 또 어쩌다보니 엔지니어링보다는 개발에 집중하고 있습니다. 뭐, 제 개발품으로 인해 그간 계속 부정적이기만 했던 고객사의 피드백이 최초로 긍정적으로 바뀌었다고 하니, 20년동안 취미로만 프로그래밍을 하던 사람의 실적치고는 꽤 괜찮은 출발인 것 같습니다.

그리고 그동안 제가 가져가야 할 개발환경에 대해 많이 생각했습니다. 비록 Qt가 데스크탑에서 모바일에 이르기까지 다양한 플랫폼을 지원하고 매우 강력한 기능들이 많다지만, 실제로 업무현장에 적용해보니 확실히 몇가지 문제들이 제 발목을 잡더군요. 몇가지를 예로 들자면......

1. 덩치가 큽니다. 기능이 많은건 좋은데, 그 반대급부로 라이브러리의 크기가 계속 커져가고 있습니다. 닭 잡는데 소 잡는 칼을 쓰는 듯한 느낌을 지울 수 없습니다.
2. 느립니다. 많은 사람들로부터 전면 개보수가 필요하다고 평가받는 Qt Model-View framework부터 시작해서, QList, QLinkedList 등 container class들은 아예 "STL이 속도라면 우린 편의성"이 모토고, 데이터베이스 처리도 썩 그렇게 좋은 성능을 보여주지 못하고 있습니다. DB는 Qt datbase framework보다는 QString을 std::string으로 변환한 뒤에 SOCI를 쓰는게 훨씬 빠르더군요.
3. 개발자가 Qt의 개발환경에 '갇힙니다.' Qt가 다방면으로 매우 많은 기능을 지원하고, 그로 인해 개발 편의성이 올라가는 것은 누구나 인정하는 바입니다만, 한번 Qt의 개발환경을 사용하고 나게 되면 다른 라이브러리나 환경을 접목시키기가 쉽지 않다는 느낌을 받습니다. 가끔씩은 매우 Java같은 느낌의 C++ 프레임워크라는 느낌이 들더군요. 구조만 그러면 모르겠는데, 프로그램의 수행속도도 C++보다는 Java에 더 가깝다는 느낌을 많이 받습니다(즉, C++답지 않게 느리게 느껴집니다). 개발을 하고 있다보면 내가 C++을 쓰는지 Java를 쓰는지 살짝 헷갈리기도 합니다(......). 아, 물론 signal-slot 매커니즘과 QString은 인정합니다.
4. 꼭 뭔가 하나씩 빵꾸가 납니다. 가장 대표적인게 Qt Quick입니다. 비록 Qt Quick은 기능과 접근방법 모두 훌륭하고, 대단한 기술적 성공이긴 합니다만, Windows/Intel 비디오카드 환경에서 화면 크기 변경시에 프레임이 깨져서 눈에 거슬린다던가, Android로 빌드할 경우 최초 실행시 boottime이 너무 길어진다던가 하는 등의 문제점이 있습니다(최소한 5.9까지 상존했던 문제입니다. 5.11에서는 bytecode compilation 덕에 많이 좋아졌다고는 들었습니다만, 테스트는 못해봤네요). 아니면 저의 경우 플랫폼간 컴파일러의 일관적 행태를 위해 MinGW를 쓰는데, Qt 5.11의 경우 현재 지원하는 MinGW 5.3에서 libclang이 빌드되지 않는다는 이유 하나만으로 qdoc을 빌드하지 않게 막았다던가(......) 하는 등의 자잘한 건들이 생깁니다. 아울러 Qt Creator의 autocompletion을 libclang 기반으로 바꾼다고 선언했는데, 너무 느리다고 말이 많기도 하고...... 
5. 가끔 뜬구름 잡는 듯한 느낌이 있습니다. Qt가 개발을 편하게 하게 하기 위하 많은 기능을 지원하긴 하는데, 이게 프로그램 동작의 많은 부분을 숨겨놓은 터라 가끔 문제가 생기면 어디서 뭘 봐야 할지 감이 안 잡히는 상황들이 발생합니다. 특히 그게 Qt의 특정 기능과 직접적으로 연관된 경우는 더 그렇습니다. 심지어 최근에는 QURL에서 퍼센트 인코딩을 강제하는(문제는 이게 특정 상황에서는 적용되기가 어렵다는) 특징때문에 그 편한 QNetworkAcccessManager을 쓰지 못하고 libcurl을 써야 했던(그리고 네트웍 코드의 3/4을 갈아엎어야 했던......-_-) 상황도 있었습니다.

뭐, 프레임워크의 덩치가 워낙 크다보니 말이 많긴 하겠습니다만, 하여간 실무에 적용하다보니 이런저런 문제점들이 보이더군요. 그래서 여러가지 대안도 찾아보고, 주변 분들의 조언도 구한 끝에 Qt에 대한 의존성을 버리고, 네이티브에 가까운 개발환경을 가져가는게 좋겠다는 결론을 내렸습니다.

1. C++ / wxWidgets & more: C++은 제 메인 개발환경이니 필히 가져가야 하고, GUI는 네이티브 위젯의 thin wrapper인 wxWidgets를 쓰면 되겠다는 결론을 내렸습니다. 시간이 없어 급하게 개발하다보면 Qt Quick은 항상 그림의 떡이고, 맨날 Qt Widgets만 쓰던 입장에서는 차라리 네이티브라 RAM도 덜 먹고 bootstraping도 빠른 wxWidgets가 답이겠더군요.
2. 하는 김에 컴파일러도 MinGW에서 VC++로 변경했습니다. 그동안에는 Windows와 Linux 사이에서 컴파일러가 일관적으로 돌아가는걸 감안하느라 MinGW를 썼는데, 가끔 Windows API를 쓸 일이 생기면 꼭 MinGW에는 없는 헤더만 찾게 되더군요(-_-). VC++2017 자체도 많이 좋아진 듯 하고...... 컴파일러간 차이는 그냥 근성으로 극복해봐야 할 듯 합니다.
3. Javascript: Web은 역시 Javascript가 native입죠(......). 일단 현재 프로젝트가 어느정도 정리되면 vue.js와 node.js(Express.js)를 중심으로 천천히 실무에 적용해볼 계획입니다.
4. Kotlin: 맨날 desktop에서 놀다보니 모바일은 어떻게 가져가야 하는가 하는 문제가 남는데, Kotlin은 일단 Android에서는 native고(특히나 Google이 Oracle과의 소송에서 패한 뒤로는 더 화끈하게 밀어주고 있다는 느낌을 많이 받았습니다), Kotlin/Native가 완성되면 iOS도 네이티브로 개발이 가능해지는 만큼 꽤 괜찮겠다는 결론을 내렸습니다. 특히나 저처럼 앞으로 근 몇년간은 Apple쪽 생태계를 건드릴 일이 없지만 언제가 건드릴지도 모르는 경우에는 더 그렇고요.

원래는 여기에 Python과 Rust가 추가되어 있었습니다만, Python은 현재 엔지니어링을 진행중인 제품에서 쓰고 있긴 하지만 그렇게 깊게 들어갈 필요가 없고, Rust는 C++에서 약간만 조심하면 되는터라 당장 큰 문제는 되지 않겠다는 결론이 나서 일단은 버리기로 했습니다. 그 외에 Go도 후보선상에 살짝 올라와 있었지만 언어 구조가 영 제 취향이 아니라 포기했고......

오랜만에 잡생각을 정리할 겸 해서 올려봤습니다. 지금은 하던 일 잘 마무리하고 Javascript 공부에 할애할 시간을 확보했으면 좋겠네요.