언젠가 인터넷에서 문명 2를 10년 동안 플레이하고 있다는 글을 본 적이 있습니다. 그런 노력에 비할 바는 아니지만 요 근래, 잠시 딴 생각 중에 제가 사이드 프로젝트를 시작한 지 햇수로 10년이 됐다는 걸 알게 됐습니다. 연말이면 한 해의 회고를 작성한 개발자 블로그를 읽으면서 ‘나도 한 번쯤 되돌아보는 삶을 살 때가 됐어’라는 다짐을 여러 번, 정작 실천은 한 번도 하지 못한 괴리에 스스로를 책망했는데, 어쩌면 10년 치 회고를 한 번에 하려는 큰 그림이었다고 자기 합리화를 해볼까 합니다.
첫 사이드 프로젝트는 사소한 동기로 시작을 했는데 10년을 되돌아보니 그 시간이 그렇게 사소하지는 않았습니다. 적어도 1년에 하나씩 만들기로 다짐한 것이 10년 동안 25개 정도의 사이드 프로젝트를 만들었습니다. 게다가 시간의 점처럼 하나하나의 프로젝트가 선명한 기억으로 남아있습니다. 회사를 다니면서 얻게 되는 직무 경험의 변화가 회사라는 제한된 공간 내에서 때로는 불가항력적이고 기회가 자주 없는 반면 사이드 프로젝트는 변화를 주도하고 언제든 통제할 수 있습니다. 이런 자유의지가 주는 해방감이 실로 큰 것이어서 오히려 멈추는 것이 쉽지 않은 것인지도 모르겠습니다.
이 글은 연도별 사이드 프로젝트에 대한 소개이고 당시 기억에 남는 일들에 대해 작성했습니다. 구글 코드, 깃헙에 소스 코드가 공개되어있는 경우에는 해당 글에 링크를 남겼습니다.
2009년
첫 가내수공업 프로젝트는 C++ 크로스 플랫폼 GUI 프레임워크인 Qt 기반의 핫키 프로그램이었습니다. 윈도우에서 자주 사용하는 메신저, 브라우저 같은 프로그램이나 자주 사용하는 폴더, 파일, 웹사이트를 키 조합만으로 실행하는 윈도우 앱입니다. 키 이벤트를 후킹 하는 부분은 Win32 API를 사용했고, 설치 스크립트인 NSIS를 이용해서 윈도우 인스톨러를 제공했는데 당시에는 무설치 버전이라는 것도 보편화되어 있어서 (어떻게 만들었는지 이제 기억은 나지 않지만) Portable 버전도 제공했습니다. 키보드 매크로 유틸리티로 알려진 Auto Hotkey에서 아이디어를 얻었습니다.
리눅스 버전(우분투)으로도 만들려는 시도를 했었는데 키 이벤트 후킹의 시련을 극복하지 못해, 크로스 플랫폼 앱의 꿈은 물거품이 됐습니다.
2010년
두 번째는 야후 날씨 API를 이용해서 만든 날씨 앱입니다. 위젯 느낌이 나도록 윈도우 프레임을 없애고 그 시절 많이 봤던 디자인을 참고했는데 배포할 수 있는 수준으로 완성하지 못한 습작 수준의 프로젝트였습니다. 첫 번째 프로젝트처럼 Qt4 기반의 윈도우 앱이었고 QHttp, QXmlStreamReader로 네트워크에서 Xml 데이터를 받아오는 부분을 공부했던 기억이 남습니다.
세 번째는 로그 파일 뷰어입니다. 그 무렵 회사에서 로그 파일을 분석하는 게 빈번한 일 중 하나였는데 괜찮은 툴이 없어서 직접 만들게 됐다는 어디선가 들어봤을 법한 스토리의 일례 되겠습니다. 앞의 두 프로젝트처럼 Qt 프레임워크 기반이었고 윈도우, 리눅스, OS/2에서 동작하는 크로스 플랫폼 앱이었습니다.
이 프로젝트는 몇 가지 기억에 남는 일이 있습니다. 당시 KDLP에 누군가 로그 파일 분석과 관련해 남긴 글에 댓글로 로그 뷰어를 수줍게 소개했는데 몇몇 분이 블로그로 찾아오셔서 응원해주셨던 일, OS/2에서 프로그램이 잘 동작한다며 외국 어디선가에서 스크린샷을 보내준 기억, linux-apps.com(당시에는 qt-apps.org)에 앱을 등록하기도 하고, QtonPi(Qt on Rasberry PI Device Program) 프로젝트에 선정되기도, Qt Ambassador가 되기도 했습니다. 무엇보다 2012년 공개 SW 개발자 대회에 지원했다가 덜컥 금상을 받아 소고기로 사치를 부렸던 날이 기억납니다.
2011년
2010년 Qt Conference Seoul 2010 중 HTML5와 Qt를 이용한 하이브리드 앱 개발을 소개하는 세션이 있었습니다. 발표자가 라이브 코딩으로 네이티브(C++)로 작성된 객체를 자바스크립트로 주입하는 장면을 보여줬는데 서로 다른 기술 스택을 하나로 연결하는 부분이 꽤 인상적이었습니다.
시간이 조금 흐른 뒤, 하이브리드 앱 개발로 만들어진 FunPlayer라는 mp3 프로젝트를 발견했고, LP 판이 돌아가는 사소한 애니메이션에 마음을 빼앗겨 이를 PySide로 재작성 하기 시작했습니다. PySide는 Python으로 Qt 프레임워크를 사용하기 위한 프로젝트였고, 마침 Python을 공부하고 있던 터라 이를 활용하기 좋은 시점이었습니다. PySide로 포팅을 하면서 HTML5/JS/CSS로 만들어진 UI와 네이티브 코드로 만들어진 음원 재생 로직이 서로 경계를 가지면서도 같이 동작하는 것이 인상적이었습니다.
이 네 번째 프로젝트를 시작으로 웹 프론트엔드 개발을 공부하기 시작했고, 이후에 만들어진 사이드 프로젝트에 웹 기술을 적극적으로 사용하기 시작했습니다.
다섯 번째 프로젝트는 2009년에 시작한 핫키 프로그램을 데스크톱용 하이브리드 앱으로 재작성하는 것이었습니다. 프로토타입을 Python(PySide)로 만든 후 실제 네이티브 구현은 C++로 재작업을 했습니다. UI 개발은 그때 유행했던 jQuery Mobile을 사용했다가 입맛에 맞게 디자인을 수정하는 게 예상보다 손이 많이 간다는 사실을 경험적으로 깨닫고, 다시 HTML5과 CSS3의 조합으로 만들었습니다. 윈도우 앱이지만 디자인이 모바일 앱스럽기도 한 이유가 초기에 전반적인 디자인 테마를 jQuery Mobile에서 참고했기 때문입니다.
당시 QtWebKit 엔진의 미지원으로 HTML5의 드래그 & 드롭 API가 제대로 동작하지 않았는데 (당시 브라우저들이 HTML5 API를 점진적으로 지원해나가던 시기) 사전에 http://html5test.com 같은 곳에서 사용하는 GUI 프레임워크의 WebKit이 필요한 API를 지원하는지 체크할 필요가 있었습니다. 이런 부분이 당시 하이브리드 앱 개발의 한계라고 느낄만한 요소였습니다.
주식 입문과 함께 여섯 번째 프로젝트를 시작했습니다. 그동안 틈틈이 공부한 웹 프론트엔드 개발과 구글 크롬 확장을 이용해 만들었고, 데이터는 Daum 증권 페이지에서 가져왔는데 Daum 증권 페이지가 개편이 되면서 프로젝트도 운명을 함께 했습니다. 당시에 큰돈은 아니었지만 1년 정도 마이너스에서 벗어나지 못하던 상황이 이 프로젝트를 진행하는 내적 동기를 잃게 하는데 한몫 하기도 했습니다.
2011년 연말에 구글 코리아의 해커톤 행사 소식을 듣고 얼마간의 고민 후 참가 신청을 했습니다. 그다지 행동파가 아닌 탓에 평소라면 그러지 않았을 텐데 어디서 그런 용기가 생긴 걸까? 지금도 아리송하지만 그때의 결정이 사이드 프로젝트에 대한 경험을 크게 확장하는 계기가 됐습니다. 해커톤에 참여하기 이전의 사이드 프로젝트는 시간과 정신의 방에 홀로 있는 기분이었다면 해커톤은 목적지까지 단숨에 달리는 단거리 계주의 느낌이었습니다. 구현에 대해 사전에 더 많이 생각하고, 어떤 문제가 있을지 미리 떠올려보고, 팀원과 어떤 식으로 작업할지 얘기한 끝에, 상상했던 결과가 눈앞에서 동작할 때의 흥분과 성취감은 며칠이나 잠을 뒤척일 정도로 기분이 좋은 것이었습니다.
그 무렵 저는 회사에서 브라우저의 NPAPI 플러그인 부분을 담당하고 있었는데, 이 기술을 사용하면 브라우저가 지원하지 못하는 영역의 것들을 보완해줄 수 있었습니다. 예를 들면 셋톱박스와 같은 제한된 환경에서 HTML5의 video 태그를 지원하지 않는 브라우저가 동영상을 재생해야 한다면 NPAPI 플러그인으로 비디오 플레이어 모듈을 로드해 웹페이지에서 동영상을 재생하는 형태입니다. 여기에서 힌트를 얻어 크롬 브라우저에서 SSH 터미널을 구현하면 재미있겠다는 생각이 들었습니다.
기술적으로 libssh를 사용해 NPAPI 플러그인을 만들고, 터미널 UI는 웹으로 구현한 뒤 크롬 확장 앱으로 패키징 하는 형태였습니다. 터미널 UI를 제대로 만들기 위해서는 VT100과 같은 터미널 제어 코드를 온전히 구현해야 하지만 제 역량 밖의 일이었기 때문에 특정 제어 코드만이 동작하게 만든 형태로 프로토타입을 완성했습니다.
이 일곱 번째 프로젝트는 해커톤에서 만난 임성국님과 함께 개발을 했고, 이때의 인연으로 다음 해 구글 HackFair 행사에서 같은 팀으로 작업을 하기도 했습니다. 이날 해커톤의 마지막 일정으로 행사에 참여한 개발자들이 1위에서 3위까지의 프로젝트를 선정했는데 이 프로젝트가 3위를 차지했습니다. 경진 대회가 아니어서 순위의 큰 의미가 없다는 부연 설명이 있었지만 성국님과 하이파이브로 소소하게 자축했던 장면이 아직도 기억에 남습니다.
2012년
2012년에는 Go 언어를 공부하고 있었습니다. https://play.golang.org/의 온라인 에디터에서 코드를 작성하고 실행 결과를 확인할 수 있었는데 여덟 번째 프로젝트는 여기에서 아이디어를 얻어 만들게 된 모바일 용 Go 언어 편집기였습니다. 이 프로젝트는 GDG 수원 안드로이드 해커톤에서 윤해빈, 박태규님과 함께 만들었습니다. 코드 에디터는 codemirror.js를 사용했고, 작성된 코드는 play.golang.org 서버를 잠시 빌려(?) 실행 결과를 얻은 뒤 디바이스에서 보여주는 방식이었습니다. 작성된 코드는 구글 드라이브와 드롭박스에 업로드할 수 있었습니다. 하지만 모바일에서 코드를 작성한다는 것은 웬만한 인내심으로도 쉽지 않은 것이어서 아이러니하게도 이렇게 폰에서 코딩할 일은 없어야 할 텐데라는 생각이 들기도 했습니다.
아홉 번째 프로젝트는 GDG Chrome의 개발자 행사인 HackTime을 준비하면서 만든 크롬 패키지드 앱입니다. 크롬에서 HTML5의 Web Audio API를 지원하기 시작했고, 마침 메트로 UI를 인상 깊게 봤던 터라 이를 이용해 메트로놈 앱을 만들었습니다. 당시 고민 중 하나가 프로토타입 수준의 프로젝트가 아닌 사용에게 배포할 수 있는 수준의 완성도로 앱을 만드는 것이었기 때문에 구현과는 별개로 크롬 웹 스토어에 배포하기가 또 하나의 목표이기도 했습니다.
2012년의 마지막 프로젝트이자 열 번째 프로젝트는 2011년 구글 해커톤에서 만들었던 Beagle Term의 시리얼 통신 버전이었습니다. 2011년에 만들었던 SSH 터미널과 달리 플러그인이 필요치 않았는데 이게 가능했던 이유는 당시 크롬 브라우저가 하드웨어에 직접 접근할 수 있는 API를 실험적으로 제공하고 있었기 때문입니다. 즉, chrome.serial API를 사용하면 브라우저에서 RS232 포트가 존재하는 장치에 접속할 수 있다는 이야기였고, 당시 많이 사용하던 시리얼 터미널인 minicom을 브라우저에서 구현할 수 있겠다는 생각이 들었습니다.
이 아이디어로 2011년 구글 해커톤에서 함께 했던 임성국님과 함께 팀을 만들어 구글 HackFair에 참여했습니다. 그 후로 완성도를 좀 더 높여 크롬 웹스토어에 배포했습니다. 2011년도에 만들었던 프로토타입인 SSH 버전의 Beagle Term보다 훨씬 완성도가 높았던 이유는 당시 구글 크롬 팀에서 NaCl 기술을 이용해 SSH 터미널인 Secure Shell 베타 버전을 배포했는데 여기에 자바스크립트 기반으로 작성된 터미널 에뮬레이터인 hterm 프로젝트가 포함되어 있었기 때문입니다. 터미널로 hterm 구현체를 사용하면서 예상보다 안정적이고 빠르게 프로젝트를 구현을 할 수 있었습니다.
2013년 1월에 chrominum-hterm 구글 그룹스에서 hterm 코드를 만든 Robert Ginda가 댓글로 Beagle Term을 짤막하게 언급했는데 사실 별 얘기가 아니었지만 당시 호들갑을 떨며 좋아했던 기억이 납니다.
이 시점에 저는 이직을 한 상태였고, 시리얼 통신을 통해 디바이스에 접속하는 일이 더 이상 업무의 한 부분이 아니었습니다. 그 이후로는 임성국님이 꾸준하게 Beagle Term 프로젝트를 관리했습니다.
1부를 마치며
이 글을 작성하려고 마음 먹었을 때는 10년 동안의 내용을 한번에 작성할 예정이었는데 작성하다보니 생각보다 쉬운 일이 아닌 것 같아 두편 혹은 세편으로 나눠서 작성해볼까 합니다. 2012년에는 첫 이직을 하면서 본격 안드로이드 개발자로 경험을 쌓았고 사이드 프로젝트도 적잖이 영향을 받았습니다. 다음 글에서는 주로 안드로이드와 관련된 프로젝트를 소개할 예정입니다.
