http://osdi.insightbook.co.kr/2013/10/24/05-joone.html
널리 알려지지는 않았지만 그 전설 같던 시절이 지나고 이제는 누구나 오픈 소스라는 말을 어디선가 들어봤음직한 시대가 됐다. 오픈 소스로 뭔가를 할 수 있으리라 별로 기대하지도 않았고 리누스 토발즈 자서전 제목처럼 ‘그냥 재미로’ 오픈 소스를 다뤄온 사람들은 지금 무엇을 하고 있을까? 어떤 사람은 오픈 소스 개발이 생업이 되어 즐겁게 일하고 있고, 또 어떤 사람은 여전히 취미로 오픈 소스를 즐기며 산다. 이 인터뷰집은 그 사람들의 이야기 ‘일부’를 다룬 것이다.
--
학교에 딱 한 대 있던 컴퓨터로 컴퓨터를 배우기 시작했다고 했는데 컴퓨터의 어떤 점에 끌렸나요?
어렸을 때부터 과학에 관심이 많아서 이런저런 경진 대회에 나갔고 게임을 좋아해서 컴퓨터에 관심이 생긴 것 같습니다. 컴퓨터에서 게임이 됐으니까요. 당시에는 게임 팩 같은 게 없어서 게임을 하려면 게임을 일일이 입력, 그러니까 코딩을 해야 했습니다. 게임 책을 가져다 베이직 코드나 어셈블리 코드를 다 입력해서 게임을 하고 또 다른 게 하고 싶으면 또 입력하고 하는 식이었습니다(웃음).
코드를 짜기 시작한 이후로 겪은 어려움 중 기억나는 것이 있다면?
처음 제대로 만든 소프트웨어가 중학교 때 만든 게임이었는데 옛날 게임기에 있던 게임을 본떠서 만들었습니다. 사과나무에서 사과가 떨어지면 로봇이 왔다 갔다 하면서 받는 게임인데요. 당시에 가장 어려웠던 부분이 게임에 난이도를 주는 것이었습니다. 사과가 떨어지고 받고 하는 것은 만들 수 있었죠. 시간이 지나면 게임이 어려워져야 하는데 그걸 코드로 짜기가 난감했던 것 같습니다. 그런 걸 고민하다가 레벨 2 정도만 만들고 그 이상은 못 갔던 것이 기억이 나네요.
학부에서 물리를 전공했다가 대학원에 가서 전산으로 전공을 바꾼 이유는 무엇인가요?
물리학을 공부하고 있었지만 프로그래밍에 여전히 관심이 많았습니다. 물리가 어렵기도 했죠(웃음). 전산과 수업도 들었고 전산과에 친구도 있었고 전산과로 대학원에 진학한 선배들의 영향을 받아서 자연스럽게 대학원에 가서 전공을 바꾸게 됐습니다.
어떤 계기로 오픈 소스에 관심이 생겼나요?
자발적이라기보다는 외부 환경의 영향을 많이 받았습니다. 윈도 환경에서 오랫동안 개발하다가 2004년 삼성전자에 들어간 후부터는 리눅스 기반 프로젝트를 많이 하게 됐습니다. 주로 임베디드 환경에서 개발을 했는데요. 그러면서 운이 좋게도, 회사에서 오픈 소스를 기반으로 한 프로젝트를 많이 했습니다. 자연스럽게 오픈 소스 일을 하게 됐고 당시 KLDP 운영자 권순선 씨도 같은 회사에서 일하고 있어서 자주 만나면서 영향을 많이 받았습니다. 그 이후 모질라 쪽 작업을 하면서 윤석찬 씨도 만나고 모질라 커뮤니티에서 활동하면서 오픈 소스 프로젝트를 더 많이 이해하게 되었습니다.
현재 어떤 프로젝트에 참여하는 중인가요?
모질라, 웹킷, 그놈에 참여하고 있습니다. 웹킷의 경우 포트(port) 레이어 중 리눅스용 GTK+ 포트와 타이젠에서 쓰는 EFL(Enlightenment Foundation Libraries) 포트 작업을 주로 많이 해왔습니다. 또 오픈GL(OpenGL) 기반의 애니메이션이나 사용자 인터페이스를 만들 수 있는 클러터라는 툴킷용 포트 작업도 했었습니다. 웹코어(WebCore) 렌더링 엔진에도 관심이 있어서 렌더링과 관련된 패치를 제출하고 있습니다.
웹킷에 특히 더 관심을 둔 이유는 무엇인가요?
DTV에서 오픈 소스 브라우저를 포팅할 일이 생겼습니다. 그때 포팅이 쉽고 가벼운 Qt 기반의 웹킷을 처음 접하게 되었습니다. 이후 모질라 기반으로 모바일 브라우저를 개발하게 되었는데, 모질라는 그때만 해도 모바일 환경에서 무겁고 적절하지 않아서 자연스럽게 웹킷 엔진으로 넘어가게 됐습니다.
웹 브라우저 개발에 관심 있는 사람들이 공부를 시작할 때 가장 큰 진입 장벽은 무엇일까요?
웹 브라우저 렌더링 엔진들이 대부분 C++로 개발되어 있는데 요즘 전산학이나 소프트웨어 개발 공부를 시작한 사람들은 대체로 자바에 더 친숙하고 C++에 익숙하지 않다는 점이 진입 장벽이 아닐까 생각합니다. 그다음으로는 리눅스 개발 환경에 익숙해져야 하는데요. 물론 윈도나 맥에서 개발할 수도 있겠지만 어차피 빌드할 때는 리눅스 기반 도구를 많이 사용합니다. 그래서 리눅스 환경이나 깃 같은 형상 관리 도구에 익숙해지는 것이 약간의 진입 장벽이 될 수 있습니다.
서로 다른 플랫폼에 이식하는 작업에서 어려움은 무엇인가요?
포트 레이어에서 윈도 시스템과 연동하는 부분은 어렵지 않고 참고할 코드가 많지만, GPU를 이용한 하드웨어 가속 부분은 좀 까다롭습니다. 그동안 하드웨어 가속 부분을 많이 작업했는데요. 비디오나 CSS3를 가속하는 부분은 하드웨어에 의존적이고 포트마다 구현이 조금씩 다릅니다. 하드웨어 가속이 중요한 이유는 성능에 절대적인 영향을 미치기 때문입니다. 예를 들어, CSS 3D 트랜스폼을 이용해 애니메이션을 만들 때 하드웨어 가속이 되지 않으면 화면이 제대로 나오지 않거든요. 비디오 가속도 마찬가지인데 임베디드 환경에서 비디오 가속이 되지 않으면 전체 화면으로 HD 영상을 재생할 수 없습니다.
하드웨어 가속 관련 기능 구현을 위해 제공되는 프로그래밍환경에는 만족하시나요?
데스크톱 쪽은 그나마 나은데 임베디드에서는 GPU 같은 칩셋이 다양해서 좀 어렵습니다. 오픈 GL ES 같은 표준 API가 있지만 확장을 많이 쓰기 때문에 그런 게 잘 구현되어 있지 않으면 제대로 동작하지 않을 수도 있고 하드웨어마다 약간의 차이점이 있어서 그에 맞춰 구현해야 합니다.
오늘날 웹 브라우저 개발사들 간의 경쟁은 여전한 것 같습니다.
과거와 다른 점이 있다면 바로 오픈 소스라는 점입니다. 과거 ‘인터넷 익스플로러 대 넷스케이프’ 구도는 오픈 소스가 아니었고 회사 차원의 경쟁이었다면 요즘은 양상이 다른 것 같습니다. 블링크가 웹킷에서 떨어져 나오면서 커뮤니티가 나뉘었는데 서로 달라지기 시작했지만 그래도 양쪽이 서로 맞춰가려는 노력이 있습니다. 블링크에 올라간 패치가 웹킷으로, 웹킷에 올라간 패치가 블링크로 다시 들어가기도 합니다. 예전 같으면 그렇게 작업하지 않겠지만 지금은 웹 개발자들에게 가능하면 똑같이 렌더링되는 엔진을 제공하는 게 목적이라서 서로 맞춰나가려고 하는 편입니다. 서로 조금씩 경쟁하고 있지만 기본적인 웹 표준은 가능한 한 맞춰가고 버그 수정도 같이 하려고 하고 있습니다. 현재는 엔진이 비슷해서 이 작업이 쉽긴 한데, 시간이 갈수록 소스 코드 차이가 커져서 어려워질 것 같습니다.
렌더링 방식은 비슷하게 유지된다고 하지만 렌더링 엔진마다 멀티프로세스 처리 방식 같은 것이 달라지는 점은 개발자에게 부담이 될 수도 있을 것 같습니다.
‘애플 웹킷2 대 구글 블링크’의 예를 보면 서로 방향이 달라서 완전히 다르게 구현되어 있습니다. 일단은 IPC 메커니즘이 다른데 애플 웹킷2의 경우 웹코어 안에 IPC가 구현되어 있습니다. 그래서 이식할 때 그 IPC 모델만 포팅하면 다른 포트(GTK+, Qt, EFL)에서 쓰기 쉽습니다. 또 API 레벨은 건드리지 않고 웹코어 안에 구현되어 있어서 기존 앱 변경을 최소화할 수 있습니다. 반면 블링크는 IPC 모델이 브라우저에 구현되어 있어서 이식할 때 가져다 쓰기 어렵습니다.
최근 몇 년간 웹이나 모바일 분야에서 수많은 오픈 소스 기술이 흥망성쇠를 겪었는데 그중에서 주목했던 기술은 무엇이었나요?
오랫동안 웹 브라우저 관련 업무를 해왔고 여전히 이쪽 분야에 할 일이 많다고 생각합니다. GPU를 이용한 하드웨어 가속이나 웹OS(WebOS) 같은 웹 런타임 환경에도 관심이 있습니다. 또한 웹 브라우저에서 도입하고 있는 멀티프로세스 모델도 중요한 기술입니다. 얼마 전만 해도 웹 브라우저는 프로세스가 하나였는데, 지금은 크롬을 시작으로 멀티프로세스 모델로 바뀌고 있습니다. HTML5 파서에 멀티스레드 모델이 도입되는가 하면, 네트워크 프로세스를 분리하는 작업도 진행 중입니다.
반대로 아쉬웠던 기술은 무엇이었나요?
(오픈 소스는 아니지만) 비주얼 베이직이 잊혀서 아쉽습니다(웃음). 최초로 상용 컴포넌트 시장을 개척하고 비주얼 프로그래밍을 선보였는데, 더는 업데이트되고 있지 않습니다. 오픈 소스 세계의 좋은 점은 오래된 기술이라도 지속적으로 계승된다는 점 같습니다. 구식이라고 이야기할 수도 있겠지만 폐기되지 않고 명맥을 유지한다는 측면에서 좋은 것 같다는 생각이 듭니다.
웹 분야에서 일하는 개발자들은 자신의 기술 포트폴리오를 어떻게 구축하는 게 좋을까요?
브라우저 개발자 입장에서 웹 개발자에게 조언을 한다는 게 쉽지 않지만, 장기적으로 봤을 때는 웹 개발에만 국한되지 않고 인접 분야 기술들을 함께 공부하는 것이 좋을 것 같습니다. 예를 들어 웹GL, 웹RTC 같은 경우 말이 웹이지, 어떻게 보면 웹과는 전혀 상관이 없는 기술입니다. 이런 특수한 웹 기술에 대해 경험을 쌓고 현업에 적용하는 것도 중요합니다. 또한 웹 기술을 이용한 브라우저 확장 기능, 웹 앱 개발에 대한 노하우를 쌓는 것도 필요합니다.
오픈 소스를 사용할 때 로컬 패치는 어떤 방식으로 사용하는 것이 좋을까요?
임베디드 시스템에서는 특정 칩셋이나 하드웨어에 맞게 최적화하는 경우가 있는데 그런 패치들은 업스트림에 받아들여지지 않을 게 거의 확실해서 로컬 패치를 해야 합니다. 그 외에도 업스트림에 당장 반영되기 어려운 기능이나 실험적인 시도가 있을 수 있습니다. 그런 경우에 관련 패치를 업스트림 메인테이너 설득용으로 깃허브(Github) 등에 올려 공개하기도 하는데 그마저도 여의치 않으면 그냥 로컬 패치를 갖고 있게 됩니다. 큰 기업의 경우, 특허와 관련되어 코드를 검토하기도 합니다. 이때 특허 보호를 위해 로컬 패치로 남기기도 합니다. 마지막으로 굉장히 중요한 기능을 만들어서 전략적으로 공개할 수 없는 상황이라면 관련 코드를 내부적으로 보관할 수도 있습니다. 오픈 소스 코드와 분리해서 잘 관리할 자신이 있다면 따로 관리할 수도 있겠죠. 많은 경우, 시간과 인력 부족으로 로컬 패치를 방치하고 라이선스에 따라 소스 공개의 의무가 있다면, 나중에 타볼(tarball)로 공개하는데, 이런 코드는 아무도 보지 않습니다.
코드를 기여하기 전에 해당 오픈 소스 프로젝트의 문화나목표 등을 이해하는 것이 중요하다고 하는데 어떤 식으로 접근하는 것이 좋을까요?
큰 프로젝트, 예를 들어 리눅스 커널이나 웹킷, 모질라 등의 경우 가이드라인이 있습니다. 그런데 처음에는 시행착오를 겪을 수밖에 없으니 걱정부터 할 필요는 없습니다. 사람들이 잘못된 점을 알려주거든요. 거기에 맞춰서 도구를 사용하고 코드를 작성하면 되겠죠.
참여하고 싶은 프로젝트의 스타일이나 운영 방식이 자신과맞지 않을 때는 어떻게 적응하면 될까요?
사람이 하는 일이다 보니 서로 맞지 않을 수도 있습니다. 회사들이 많이 참여하는 프로젝트는 이해관계도 걸려 있고요. 예를 들어 아무리 코드를 잘 만들어도 프로젝트 운영 회사의 전략과 맞지 않으면 받아주지 않기도 하죠. 아니면 모듈 소유자마다 성격이나 취향이 달라서 그 사람 기호에 맞지 않게 작성하면 코드가 들어가지 않기도 합니다. 일단은 사람을 이해하는 게 중요한 것 같습니다. 오픈 소스가 재미있는 점이 꼭 논리적으로만 일이 풀리는 게 아니라 그 사람을 만나서 좋은 관계를 맺으면 일하기가 편하다는 점입니다. 미리 코드나 패치 제출 같은 작업을 해서 자신을 좀 알리고 콘퍼런스에서 메인테이너를 만나서 친분을 쌓아나가면 서로 좀 더 이해하면서 작업을 할 수 있게 되는데 그런 점도 중요한 것 같습니다.
코드나 패치를 제출했을 때 되돌아오는 비평을 부담스러워 하는 경우도 많은데….
아무래도 메인테이너 개인 업무가 있는 상태에서 코드 리뷰를 하려면 시간이 많이 드니 불친절하게 대응한다고 느껴질 수도 있습니다. 또 패치가 들어가려면 메인테이너들이 패치를 이해해야 하는데 그러려면 메인테이너들을 이해시키려는 노력이 끊임없이 필요합니다. 시간이 많이 걸리는 일이죠. 메인테이너를 설득해서 패치 하나 반영하는 데 3년 걸렸던 경험을 한 적도 있습니다(웃음). 쉽지 않은 일인데 그런 경우들이 있고 끈기 있게 임하는 게 중요합니다.
그동안 본 오픈 소스 코드 중에서 가장 읽기 좋았던 것은 무엇인가요?
글쎄요. 제가 참여했던 프로젝트는 큰 프로젝트라서 읽기 쉬운 코드는 없었던 것 같습니다. 그나마 코딩 스타일이 저와 잘 맞는 웹킷 코드가 읽기가 쉽지 않았나 생각합니다. 지금은 좀 복잡해졌는데 초기에는 규모가 작아서 이해하는 데 큰 어려움이 없었습니다. 물론 지금은 아닙니다.
읽기 좋다는 기준은 어떻게 잡을 수 있을까요?
일단은 복잡도인데요. 물론 웹킷 코드 중에서도 파서처럼 복잡한 부분이 있습니다. 그 외에는 전반적으로 봤을 때 구조화가 잘되어 있고 기능적으로 잘 분리되어 있습니다. 웹킷이나 모질라 게코(Gecko) 같은 웹 렌더링 엔진이 어려운 이유가 C++ 코드로 구현되어 있는데, 객체 지향 프로그래밍 코드란 것이 잘 디자인하면 굉장히 읽기 쉽지만 잘못 디자인하면 오히려 더 어려워지는 코드가 많아서입니다. 웹킷은 비교적 잘 디자인되어 있고 특히 개발자들이 지속적으로 리팩터링을 많이 하고 있어서 포트단에서 기능을 추가하는 코드들이 기능이 잘 구현되어 있습니다. 웹킷 코드를 다 보지는 않았지만 제가 본 코드 내에서는 이해하기가 쉬웠던 것 같습니다.
당시에 어느 정도 수준까지 리팩터링이 되어 있었나요?
그 이전 코드를 보지 않아서 정확히 비교하기는 어렵지만 예전 코드는 포트 레이어가 잘되어 있지 않았을 것 같습니다. 그러다가 웹킷을 여러 플랫폼에 이식하기 쉽도록 웹킷 코어 안에 있는 브라우저 엔진 기능과 웹킷에서 제공하는 API 및 포트가 분리되었습니다.
코드 읽기 연습은 어떻게 하면 좋을까요?
늘 고민하는 문제인데 어떤 경우에는 시간이 많이 걸리기도 하고요. 경험이나 해당 프로젝트에 대한 기반 지식에 따라 코드를 이해하는 속도가 차이가 많이 나는데 경험이 없을수록 공부할 게 많아지니 시간이 많이 걸리겠죠. 무모한 방법 같기도 하지만 코드를 다 출력해서 봤다는 사람도 있는데 코드를 한 줄 한 줄 이해해 보는 방법도 도움이 많이 됩니다. 다만 시간이 굉장히 많이 걸리죠. C++를 쓴 프로젝트라면 각 클래스가 어떤 기능을 하는지 이해하는 게 중요하다고 봅니다. 간단하게 몇 가지 다이어그램을 그려볼 수도 있겠죠. 또는 gdb를 이용해 주요 기능에 대해 호출 스택(call stack)을 확인하는 것도 프로그램의 동작을 이해하는 데 도움이 됩니다.
그놈 한국 사용자 모임에서는 어떤 일을 하시는지 소개 부탁드립니다.
현재는 미국에 있어서 큰 역할을 하고 있지는 않습니다. 그놈 사용자 모임에 관심이 생긴 이유는 그놈과 KDE 커뮤니티가 2년에 한 번씩 공동 주최하는 데스크톱 서밋이라는 콘퍼런스에 참석하면서부터입니다. 지난 1회, 2회에 다 참석했는데 그때 그놈 커뮤니티의 분위기나 해커들의 문화에서 강한 인상을 받았습니다. 그 후 우연한 기회에 웹킷GTK+의 한글 입력 버그를 패치하다가 그쪽 메인테이너들과 친분을 쌓게 됐고 그러면서 그놈 사용자 모임에 관심이 생겼습니다. 그런데 그놈 한국 사용자 모임은 역사가 오래되기는 했는데 제가 처음 관심을 가졌던 당시에는 홈페이지가 닫혀 있던 상태였습니다. 그래서 제가 홈페이지를 다시 살리는 작업을 했었습니다. 그리고 그놈 아시아 서밋 관계자들로부터 한국에서 그놈 아시아 행사를 열 생각이 없느냐는 질문을 받았습니다. 사실, 하고 싶은데 어떤 분들이 그놈 모임에서 활동하는지 잘 몰라서 오프라인 모임이 자주 있으면 좋겠다는 생각이 들어, 다음 데브온(DevOn) 행사에 커뮤니티로 참가하고 2012년 1월부터 한 달에 한 번씩 기술 세미나를 개최했습니다. 지금은 다른 분이 계속하고 있고요. 그 일을 하면서 사람들을 많이 만나게 되었고, 홍영기 씨를 주축으로 2013년 그놈 아시아 서밋을 5월 서울에서 열게 됐습니다.
2013년 서밋에서는 주로 어떤 내용이 다뤄졌나요?
새로 나온 그놈 3.8 기능을 비롯해 웹킷GTK+, GStreamer, 웨이랜드 등에 관해 발표됐고 나라별 커뮤니티 활동이 소개됐습니다.
2012년에 ‘A bright future for GNOME’이라는 슬라이드가 발표된 적이 있습니다. 역설적이지만 오픈 소스 데스크톱 환경의 미래가 밝지만은 않다는 느낌도 듭니다.
이 발표를 한 잔 로페즈(Xan Lopez) 씨는 저를 웹킷GTK+로 이끌어준 개발자이기도 한데요. 그놈 커뮤니티에서 많이 고민하는 문제입니다. 스마트폰이나 태블릿으로 흐름이 바뀌면서 데스크톱에 대한 관심이 줄어들고 있는데 그놈은 그에 대한 대응이 느린 상태였다고 볼 수 있습니다. 어떻게 해야 태블릿이나 스마트폰 환경에 대응할 수 있을지 대해 그놈 커뮤니티 내부적으로 고민하는 사람들이 있습니다. 이 발표 역시 그와 관련된 내용이고요.
그놈 3, KDE 4 등 오픈 소스 데스크톱 환경의 최근 버전들은 평이 대체로 좋지 않은데 원인이 무엇일까요?
사람들의 눈이 높아져서 그런 게 아닌가 하는 생각이 듭니다. 예전에는 그냥 리눅스에서 윈도 데스크톱과 비슷하기만 해도 만족했던 것 같은데, 지금은 사용자들이 다양한 운영 체제와 모바일 기기를 사용하면서 기호가 다양해져서, 그런 기준을 다 만족시키기가 어려워졌습니다. 또 해커들과 사용자들은 시각이 다른데 주로 일반 사용자에 맞춰 개발하다 보니 기존 해커들은 불만이 많아진 거죠. 그런 요인들 때문에 불만이 많아진 것 같습니다.
‘개발자들을 위한 데스크톱 환경은 아직 없다’는 의견도 있는데 앞으로 오픈 소스 데스크톱 환경이 개발자와 일반 사용자 중 어느 쪽에 비중을 더 두는 것이 나을까요?
결국은 일반 사용자에 중점을 두는 것이 맞을 것 같습니다. 개인적인 의견으로는 오픈 소스 데스크톱 진영이 힘을 합쳐서 가능한 한 비슷한 방향으로 나가는 것이 좋다고 봅니다. 혁신도 중요하지만 사용자에게 일관된 환경을 제공하는 것이 더 중요하다고 생각합니다. 데스크톱용 오픈 소스 애플리케이션이 그 수가 적지는 않지만 ‘킬러’라고 할 정도 수준인 것은 많지 않은 것 같습니다. 가짓수도 많고 웬만한 건 다 있긴 있는데 그중에는 업데이트 잘 안 되거나 기능이 미약한 경우가 많습니다. 사실 회사에서 개발하기보다는 개인들의 자발적인 참여로 개발이 진행되는 경우가 많아서 아무래도 부족한 부분이 있을 수밖에 없지만 오히려 기회일 수도 있습니다. 안 되는 기능이 있으면 직접 구현해 패치를 올릴 수도 있고, 부족한 부분들을 채워나갈 수가 있으니까요. 사용자 입장에서는 불편하겠지만 개발자 입장에서는 자신이 기여할 수 있는 기회일 것 같습니다.
GTK+ 관련 프로젝트에 많이 참여 중이신데 쓰면서 아쉬운 부분이 있다면 무엇인가요?
GTK+가 많이 사용되고 있지만 처음 쓰려는 사람들에게 는 여전히 진입 장벽이 있는 것 같습니다. C로 개발되어 있고 GObject 등에 익숙해져야 하는데 그런 것들을 이해하려면 객체 지향 프로그래밍 개념도 잡혀 있어야 합니다. 가장 큰 문제는 개발 도구가 부족한 부분입니다. 글레이드 같은 몇 가지 도구가 있지만, 엑스코드(Xcode)나 비주얼 스튜디오보다는 부족한 상태입니다.
현재 미국에서 직장 생활 중인데 어떤 과정을 거쳐 나가시게 된 건가요?
2010년에 제대로 오픈 소스 활동을 해보자는 생각에 삼성전자를 그만두고 웹킷 프로젝트에 6개월 정도 기여를 했습니다. 그러다가 콜라보라라는 회사에서 일을 하게 됐습니다. 영국에 본사가 있는 회사인데 오픈 소스 개발자 100여 명을 고용하고 있고, 다른 회사를 위해 오픈 소스 관련 업무를 대신해 주고 컨설팅·교육·개발도 맡습니다. 그 후 웹킷 커미터가 되었는데, 오픈 소스 커미터나 메인테이너가 되면 채용 제안을 많이 받습니다. 웹킷 커미터가 된 이후에 웹킷 커미터 명단에 있는 이메일 주소로 여러 회사에서 메일이 왔습니다. 그 메일들 중에서 인텔에서 채용을 한다는 메일을 보고 여러 면접을 거쳐서 미국에서 일을 시작하게 되었습니다.
콜라보라로 이직을 하게 된 계기는 무엇이었나요?
회사를 다니면서 오픈 소스 개발자가 되고 싶다는 생각이 들었습니다. 제 나이가 개발자로서 많은 편인데, 주변에서 전업으로 하지 않으면 시간도 많이 걸리고 오픈 소스 개발을 따라가기 어렵다고 조언을 해주더군요. 당시 회사는 전업으로 오픈 소스를 개발할 수 있는 환경이 아니었고, 잠시 이런 경험을 하면 좋을 것 같아서 회사를 그만두게 됐습니다. 그리고 오픈 소스를 열심히 하다 보면 좋은 기회가 올 것이라고 생각했습니다. 콜라보라는 오픈 소스 개발자에게 널리 알려진 회사입니다. 아마 개발자에게 가장 자유로운 개발 환경을 제공하는 회사가 아닐까 생각합니다. 1년에 두 번 오픈 소스 콘퍼런스 참여 기회를 제공하고 영국, 캐나다에 있는 사무실에서 방문하여 일할 기회도 제공합니다. 제 경우, 작업하던 패치가 이 회사에서도 관심 있던 내용이라서, 이 회사에서 채용 제안까지 받게 되었습니다. 구루(guru) 수준의 오픈 소스 개발자와 함께 개발하는 경험은 무엇과 비교하기 어려운 값진 경험이었습니다.
취미와 직업으로서 오픈 소스 개발 사이의 일장일단은 무엇인가요?
회사에서 하는 오픈 소스 개발은 아무래도 개인의 관심사보다는 회사 방향에 맞춰 일을 많이 하게 됩니다. 개인적으로 는 제가 쓰면서 불편한 부분이나 한국인이라서 한국어 지원의 부족한 부분에 관심이 많은데 그런 부분들에 대해서는 등한시하게 됩니다. 그래서 개인 시간에는 한국어 지원 등에 관심을 두고 작업하려고 합니다.
피터 노빅이 「Teach Yourself Programming in 10 Years」란 글을 발표한 적이 있습니다. 숙련된 오픈 소스 개발자가 되는 데 시간이 어느 정도 걸린다고 보시나요?
전산을 공부하고 어느 정도 개발 경험이 있으면 최소한 2년 정도는 그 프로젝트에 투자해야 오픈 소스 메인테이너나 커미터가 될 수준에 이를 수 있을 것 같습니다. 물론 프로젝트에 따라 다르겠지만 그 프로젝트를 이해하고 어느 정도 경험을 쌓으려면 그 정도 시간을 투자해야 하지 않을까 생각합니다. 전업으로 한다면 기간이 줄어들 수도 있겠고요.
현재 사용하는 개발 환경이나 도구는 무엇인가요?
개발 언어는 C++이고 편집기는 vim을 주로 쓰고 IDE는 이클립스도 가끔 씁니다. 웹킷의 경우 맥에서도 디버깅이나 테스팅을 할 필요가 있어서 엑스코드를 쓸 때가 있습니다. 디버거는 cgdb를 쓰고요.
C++ 새 표준이 웹킷 개발에 미치는 영향은 어느 정도인가요?
C++11의 기능을 웹코어 개발에 쓰겠다고 애플이 발표하고, 이제 웹킷을 빌드하는 모든 컴파일러가 C++11을 지원합니다. 그리고 실제로 C++11 기능이 적용되고 있습니다. C++11에 익숙하다면 웹킷 프로젝트에 참여해 코드를 살펴보고 리팩터링해 볼 수 있는 좋은 기회일 수도 있습니다.
러스트라는 언어로 개발하는 서보(Servo) 엔진의 경우처럼 언어의 변화가 웹 브라우저 렌더링 엔진에는 어떤 영향을 미칠까요?
블링크의 경우는 성능을 높이려고 파서를 멀티스레드로 돌린다든지, 이미지 압축을 풀 때도 멀티코어를 이용해 빠르게 해보자는 시도가 있습니다. 이렇게 하면 성능은 좋아지는데 코드 복잡도는 높아집니다. 그래서 그런 것들을 프로그래밍 언어로 해결해 보려는 시도가 러스트라고 볼 수 있는데요. 이런 시도는 반가운 면이 있습니다. 현재 언어들이 멀티코어를 보고 디자인된 것들이 아니라서 복잡도 문제를 쉽게 해결할 수 있다면 새로운 언어가 나오는 것도 좋은 접근 방법이라 봅니다.
현재 사용 중인 개발 언어나 도구에서 불만족스러운 부분은 무엇인가요?
아무래도 단축키를 많이 외워야 하고, 아는 만큼 품이 덜 들게 되고 익숙해지는 데 시간이 많이 걸리죠. vim에는 제가 모르는 확장 기능도 많아서 하나하나 노하우를 알아가야 하는데, 결국은 주변에 잘 쓰는 사람이 있어서 어깨 너머로 보고 배우는 데 시간이 많이 걸립니다. 확장 기능을 알아서 설치해야 한다는 점도 좀 번거롭죠.
개발을 하면서 겪은 최악의 버그는 무엇이었나요?
예전에 한 벤처 회사에서 일할 때 브라우저를 개발한 적이 있었습니다. 스마트폰이 대중화되기 전, 윈도 포켓PC 기반으로 웹 브라우저를 만들던 시기였는데 아마 2004년이었을 겁니다. 당시에 브라우저에서 만화 보는 프로그램을 띄우는 게 있습니다. 만화 보기 프로그램을 띄우면 브라우저가 죽는 버그가 있었는데 그걸 고치는 데 한 달 가량 걸렸습니다. 결국은 다른 개발자가 버그를 잡긴 했는데 그만큼 프로젝트 기간이 연기됐던 적이 있었습니다. 그런데 버그의 정확한 원인은 못 찾았습니다. 오픈 소스가 아니고 윈도CE 환경이었는데 도큐먼트 뷰 구조에서 다이얼로그 구조로 바꾸니 실행이 되더군요. 이유는 알 수 없었고요. 그래서 프로그램의 틀을 다시 작성했습니다. 버그를 잡으려고 프로그램을 가장 단순하게 만들어서 거기에다 기능을 하나하나 추가하고 디버깅을 하면서 해결은 했지만 윈도이나 맥처럼 소스를 볼 수 없는 환경에서는 디버깅하는 데 제약이 굉장히 많다는 사실을 다시 한 번 깨달았습니다. 오픈 소스가 좋은 점은 제가 디버깅하는 환경에서는 제 프로그램만 디버깅하는 것이 아니라 그 밑단에 의존성이 있는 라이브러리까지 같이 디버깅할 수 있어서 코드를 이해하기가 더 쉽고 문제가 생겼을 때 자신이 해결할 수 있는 범위가 훨씬 넓어진다는 것입니다.
오늘날 웹 개발 세계에서 기술적 빚이 있다면 무엇일까요?
http를 표현하는 URI 스펙 같은 경우는 팀 버너스 리(Tim Berners-Lee) 스스로도 실수라고 말했다고 합니다. 지금에 와서 보니 일반인들이 이해하기 어려운 방식을 쓴 건 잘못한 일 같다고 했다는데요. 당시에는 웹이 대중화되리라 생각하지 못하고 일부 과학자들이 쓰려고 만든 것이었으니까요. 그 외에 또 꼽자면 플러그인 구조입니다. 현재 플러그인 구조는 보안에 취약한데요. 플러그인으로 다양한 확장 기능을 구현할 수 있지만 로컬 어디에나 접근할 수 있게 된다든지 하는 보안적인 측면에서 구멍이 많이 있습니다. 플러그인이 죽으면 브라우저도 죽을 수 있는 안정성 문제도 있고요.
‘빈둥거릴 여유’에 대해 글을 쓰신 적이 있는데 미국으로 옮긴 후 여유는 찾으셨나요?
글쎄요. 제 딸이 아직 어려서요(웃음). 빈둥거릴 시간이 생기지는 않았습니다. 그런데 이곳 근무 문화가 한국보다 여유가 있는 건 사실입니다. 회의도 확실히 적고, 보고나 근태도 단순합니다. 오랫동안 한 가지 일을 해온 전문가가 많아서 그런지, 문제가 생겼을 때 모든 사람이 회사에 남거나 야근을 강요하는 것은 좀처럼 찾아보기 어렵습니다. 사람들과 이야기해 보면 자기 일 외에도 다른 일을 많이 하는데 라즈베리 파이로 개인 창작 활동을 한다든지, 차에 태양광 전지와 태블릿을 단다든지 하는 걸 보면 삶의 여유가 더 있는 것 같습니다.
결혼 후 주의력이 분산되는 경험을 하는 개발자들이 적지 않다고 하는데 실제로 어떤가요?
실제로 오픈 소스 활동을 열심히 하다가 결혼 후 아이가 생기고 은퇴(?)하는 개발자들이 꽤 있는 것 같습니다. 본업만 하고 오픈 소스 활동은 잘 못하게 되는 거죠. 아니면 아이를 다 키우고 늦게 시작하는 경우도 있긴 합니다. 앤드류 모튼(Andrew Morton)이라는 리눅스 커널 개발자는 마흔 살에 커널 개발을 시작했다고 하더군요. 그런 사람들은 아이가 다 크고 나서 시간이 난 거겠죠. 저도 집에서는 아이를 재우고 밤늦게 잠깐 보거나 아이와 일찍 자고 새벽에 작업을 합니다. 주말 낮에 뭔가를 한다는 건 상당히 어려운 일입니다. 사실 20대가 시작한 유명한 오픈 소스 프로젝트가 많습니다. 리누스 토발즈도 결혼 전 학부·대학원 시절에 리눅스 커널을 만들었고, 파이어폭스(Firefox)도 대학생이 시작했습니다. 아무래도 소프트웨어 개발에 전성기는 있는 것 같습니다. 그때 뭔가 크게 일을 하고 그 이후에는 여유 시간에 그 일을 유지하는 것이 부러워 보입니다.
한국의 경우 요즘은 그런 10대~20대가 많지 않고 개발자 사회가 노령화한다는 의견이 있습니다.
서구에서는 어릴 때부터 소프트웨어 개발을 시작하는 경우가 많습니다. 웹킷GTK+ 개발자들을 만났는데, 대부분 저보다 나이가 어린 걸 보고 놀랐습니다. 처음 만났을 때, 개발자들 나이가 대부분 20대 후반이었는데 현재 메인테이너로 활동하고 있습니다. 그렇다고 개발 경험이 짧은 게 아니라 고등학교 때부터 오픈 소스 경험을 시작했더군요. 20대 후반인데 10년 정도 오픈 소스 개발 경험이 있는 거죠. 저는 개발자로서 경험은 많지만 오픈 소스를 시작한 지는 오래되지 않아서 그 개발자들에게 많은 도움을 받으며 작업을 했습니다. 한국은 대학교 때부터 ‘스펙’이란 걸 쌓아야 해서 뭔가 여유 있게 다른 일을 할 수 있는 기회가 점점 줄어드는 것 같습니다. 그래서 한국 개발자 사회가 고령화하고 있고 새로운 개발자를 찾기가 어려워 보입니다.
아이가 프로그래밍에 관심을 보인다면 적극 후원해 주실 의향이 있나요?
물론이죠. 딸아이가 소프트웨어 개발에 관심을 갖게 될지는 모르겠지만, 어쨌든 본인이 원한다면 프로그래밍을 가르쳐주고 싶은 생각이 있습니다. 아마 중학생이 되었을 때 간단한 것들을 가르쳐주면 좋을 것 같습니다. 프로그래밍은 자연 언어처럼 일찍 배우는 게 좋다고 봅니다. 저도 초등학교 때 프로그래밍을 배웠고, 중학교 때 혼자 코딩을 했으니까, 나중에 어떤 언어를 배우는 데 큰 무리가 없었습니다. 배워두면 논리적인 사고라든지, 문제 해결 능력 등에 도움이 되겠죠. 개발을 잘하면 앞으로는 어느 분야에서도 잘 쓸 수 있을 테니 좋지 않을까 생각하고 있습니다. 참고로 아내가 사회학 전공이고 학교에서 비주얼 베이직을 배웠다고 하는데요. 그래서 좋은 점이 하나 있습니다. 프로그래밍이 얼마나 어려운지 잘 알고 있더군요(웃음).
지금보다 충분한 여유 시간이 주어진다면 해결하고 싶은 일은 무엇인가요?
한글 관련 문제가 여전히 큰 문제인 것 같습니다. 사용하면서 느끼는 것이지만 여전히 문제가 많은데 그런 부분들은 기업이 나서서 하지 않거든요. 그런 문제들은 기업에서 느끼기에 사업을 하는 데 큰 도움이 되지 않고 개발자들도 별로 관심이 없고요. 그런 문제들을 해결하는 데 충분한 여유가 있다면 시간을 더 써보고 싶습니다. 입력기 쪽이 여전히 문제가 많은데요. 특히 리눅스 쪽은 더 그렇고요. 입력기는 아무래도 플랫폼마다 다 달라서 맞추기가 상당히 어려운 것 같습니다. 중국은 인구가 워낙 많아서 여러 사람이 참여하는데 한국은 딱 한 명 있죠. 그분이 많은 일을 했지만 모든 부분을 다 맡을 수는 없는 상황인데요. 응용 프로그램, 예를 들어 웹 브라우저와 관련된 입력기 문제를 풀어보고 싶습니다. 그 외에 나만의 브라우저도 만들어 보고 싶습니다.
퇴근 후 시간은 어떻게 보내나요?
주로 가족과 시간을 보냅니다. 아이와 같이 산책도 하고요. 처음 미국에 왔을 때 잠깐 혼자 있었는데 그때는 만화를 그렸습니다. 시간이 생겼을 때 여유롭게 하는 일 한 가지가 그림 그리는 것입니다.
만화는 언제부터 그리기 시작했나요?
원래 그림 그리는 걸 좋아했고 대학교 만화 동아리 시절부터 그리기 시작했습니다.
국내 개발자 커뮤니티에서 소프트웨어 개발을 소재로 한 카툰을 그리면서 알려지셨는데 다른 소재가 아닌 소프트웨어 개발을 소재로 택한 계기는 무엇인가요?
외국에는 IT나 엔지니어에 관련된 만화가 많은데 소프트웨어 개발자를 위한 만화는 당시에는 별로 없었던 것 같습니다. 꾸준히 그리지는 못했는데 시간이 나거나 아이디어가 생길 때마다 조금씩 그렸습니다.
선호하는 만화 작업 방식은 무엇인가요?
여러 방식이 있는데 예전에는 종이와 펜으로만 그리기도 했고, 밑그림만 종이에 그리고 스캔해서 색칠은 포토샵에서 하는 경우도 있습니다. 요즘은 아이패드에서 그리고 색칠도 합니다. 시간이 많지 않으니 그렇게 하는 편이 더 빠르더군요. 최근에 그린 그림은 아이패드에서 다 그렸습니다. 그렇게 작업한 후 인터넷에 올립니다.
Image of Joone
아날로그 방식과 디지털 방식 어느 쪽이 더 편한가요?
손으로 그리는 게 가장 좋긴 한데 손으로 그리다가 중간에 실수를 하는 경우 고치는 데 시간이 많이 걸려서 주로 마지막은 디지털 형태로 나가니 디지털 방식으로 그리는 게 편할 때가 있습니다.
카툰과 코딩 작업을 비교했을 때 비슷한 부분이 있다면.
시간 싸움인 것 같습니다. 카툰을 그리는 데도 시간이 많이 필요한데요. 모든 일이 비슷할 텐데 대충 하는 건 금방 할 수 있어도 완벽하게 하려면 시간이 많이 걸리더군요. 그림이 단순해 보여도 한 컷 그리는 데 시간이 많이 걸립니다. 자주 그리는 편이 아니라서 매일 그린다면 빨리 그릴 수 있을지도 모를 텐데 가끔 그리다 보니 코딩이나 그림이나 하다 안 하다 하면 감을 잃으니까요. 두 작업을 오가는 게 쉬운 것 같지는 않습니다. 감이 떨어지면 아무리 그려도 원하는 캐릭터가 나오지 않는 경우도 있습니다. 사람 하나 그리는데, 수십 번 그려서 결과가 나오면 스캔해서 채색에 들어가게 됩니다. 코딩도 비슷한 면이 있는 것 같습니다.
카툰 작업을 하면서 얻는 것이 있다면 무엇인가요?
제가 하고 싶은 이야기를 쉽게 전달할 수 있다는 것입니다. 글로 전달하는 것보다 그림이 강력할 때가 있습니다. 어떤 주제를 전달할 때, 예를 들어 블로그에 글을 쓸 때 그림을 하나 더 넣으면 사람들이 더 관심 있게 보고 이해도 쉬워서 그런 면에서는 의사 전달에 더 강력한 것 같습니다. 캐릭터가 제 얼굴과 비슷해서 가끔씩 주변 사람들이 절 알아보는 경우도 있는데 그런 경우가 재미있기도 합니다.
앞으로 어떤 카툰을 그려보고 싶은가요?
오픈 소스와 관련된 만화를 그려보고 싶습니다. 10여 년 전에 오픈 소스를 알리는 책이 몇 권 나왔었는데 국내에는 아직 오픈 소스라는 개념이 일반인에게까지 알려진 것은 아닌데다 많은 개발자가 이해하고 있는 것도 아니어서 오픈 소스가 무엇인지 쉽게 잘 알릴 수 있는 만화를 그려보고 싶습니다. 그런데 당장은 시간이 허락되지 않아서 계획만 해둔 상태입니다.
자신만의 재충전 방법이 있다면.
장소를 바꿔가면서 일을 하면 좋습니다. 카페나 야외에 가서 코딩을 하기도 합니다. 그리고 SNS에서 글도 읽고 쓰면서 시간 보내는 것도 즐깁니다. 무엇보다 짧은 산책이 제일 것 같습니다.
개발자로서 긱(geek)적인 흥미를 불러일으키는 것을 꼽는다면 무엇인가요?
저는 만화를 봅니다. 일반 만화가 아니라 사회 비판적이거나 역사를 소재로 한 만화를 보는 편입니다. 예를 들면 『쥐』나 최근에는 『굿모닝 예루살렘』 같은 작품을 봤습니다. 전기나 재즈 역사를 다룬 만화도 좋아하고요. 미국에서는 미국 만화를 관심 있게 보고 있습니다.
이방인으로서 삶은 어떤가요?
소프트웨어 개발자라는 직업은 문화적 차이가 크지 않은 것 같습니다. 개발자들 사이에서는 개발자 문화라는 게 있고 오픈 소스 커뮤니티에서 오랫동안 경험을 해서 적응하는 데 어려움은 별로 없었습니다. 매일 테이블 축구도 하고 함께 카페테리아에 가서 음료수도 마십니다. 점심도 자주 밖에 나가서 먹고요. 오픈 소스 개발자라는 동질감이 있어서 일하는 데는 더 편한 것 같습니다. 물론 아직까지는 그 사람들의 농담을 다 이해하기가 쉽지 않습니다.
큰 영향을 받은 개발자는 누구인가요?
2004년 삼성전자에 입사했을 때 플래시 메모리 기반의 파일 시스템을 개발하는 팀에 들어갔는데 당시 팀을 이끌던 권문상 책임님이 개발한 파일 시스템을 팀원들과 유지 보수하였습니다. 특히 파일 시스템은 신뢰도 높게 만들어야 했기 때문에 코드 리뷰를 꼼꼼하게 진행했는데 그때 좋은 개발 문화를 배웠습니다. 개발을 하다 보면 혼자서 서너 명 몫을 하는 ‘슈퍼’ 개발자를 만나게 되는데 그런 개발자와 일하게 되는 건 어떻게 보면 행운인 것 같습니다. 오픈 소스 세계에 들어와서는 마틴 로빈슨(Martin Robinson)이란 개발자를 만났는데 일을 굉장히 많이 하고 잘하는 개발자입니다. 20대 중반이지만, 오픈 소스 일을 많이 해서 그런지 경험이 많습니다. 리뷰도 꼼꼼하게 해줘서 많이 배웠습니다.
그런 ‘슈퍼’ 개발자의 기여량은 어느 정도인가요?
프로젝트마다 성격도 다르고 코드 크기를 정확히 재보지는 못했지만 한두 명이 전체 프로젝트의 80% 이상을 담당하는 경우도 봤습니다. 특히 오픈 소스 쪽은 모듈 담당자들이 일을 많이 합니다.
흔히 오픈 소스라고 하면 여러 명이 골고루 일을 할 것 같은데 예상과는 반대로군요.
소수가 기본 프레임워크를 만들면 나머지 사람들은 기능 추가나 버그 수정을 합니다.
그런 개발자들의 어떤 측면을 주로 눈여겨보시나요?
문제 해결 능력을 많이 봅니다. 버그가 있을 때 어떻게 문제를 해결하는지, 코드를 짤 때 디자인을 어떻게 하는지, 테스트를 어떻게 하는지 등을 주로 눈여겨봅니다. 보통 개발자라면 대충 구현하고 동작만 하면 넘어가는 게 일반적인데, 뛰어난 오픈 소스 개발자들은 가능하면 단순하게 코드를 작성하기 위해 노력하고 가능하면 기존 코드 디자인과 잘 조화를 이루도록 개발하는 모습을 봅니다.
프로젝트와 조화를 이루도록 코드를 짜는 감각은 어떻게 키울 수 있을까요?
시간이 필요한 것 같습니다. 코드를 올리다 보면 리뷰를 많이 받게 되는데 그 과정에서 새로운 언어를 배우듯이 동화되어서 프로젝트에 맞게 코딩을 하게 됩니다. 그렇게 해야 리뷰도 잘 되고요. 자기 개성보다는 조화가 중요하다고 볼 수 있습니다.
어떤 모습의 개발자로 늙고 싶으신가요?
오랜 경험이 쌓이다 보면 시어머니 같은 개발자가 될 것 같습니다. 여기 저기 참견하고 다른 개발자에게 이래라저래라 말이 많아지겠죠. 이런 참견과 말이 모두 도움이 될 수 있는 고참 개발자가 되고 싶습니다.
소프트웨어 개발자의 의의는 무엇이라 보시나요?
그냥 직업이라기보다는 독특한 집단인 것 같습니다. 소명 의식도 약간 있고요. 특히 오픈 소스 개발자들 중에는 그런 사람들이 있습니다. 세상 사람들이 소프트웨어를 자유롭게 쓸 수 있게 하는 것이 세상에 유익이 된다고 생각하는 거죠. 물론 자신의 기술적 우월함만 드러내려는 사람도 있고 다양하긴 한데 어쨌든 뭔가 다른 것 같습니다. 그래서 회사에서 일뿐 아니라 밖에서도 자발적으로 모이기도 합니다. 저도 가끔 소프트웨어 개발로 세상을 좀 더 진보적인 방향으로 바꾸어 나간다고 생각하고 있습니다.
시작하는 개발자에게 해주고 싶은 조언이 있다면.
사람마다 개발을 시작하는 계기가 다른데요. 전공이라서 시작하기도 하고 재미있어서 시작하기도 하고요. 자기가 왜 이 일을 하는지, 세상에 무슨 도움이 되고 있는지, 어떤 의미가 있는지 계속 고민을 해봐야 할 것 같습니다. 소프트웨어가 미치는 영향이 크기 때문입니다. 이제는 윤리적으로도, 사회적으로도 그렇고요. 그런 점에 대해 고민을 많이 해볼 필요가 있을 것 같습니다. 모질라의 미셸 베이커(Mitchell Baker)의 경우 웹이 항상 개방적이어야 하고 누군가에 의해 소유되지 않고 누구나 참가할 수 있어야 한다는 가치를 계속 강조하는데요. 기술을 다루는 책은 많지만, 그런 어떤 가치를 고민하는 것은 또 다른 문제라고 봅니다. 그리고 어떤 플랫폼이든지 오픈 소스 개발 경험을 하는 것은 소중한 것 같습니다. 자기가 프로젝트를 시작해도 좋고, 기존 프로젝트에 참여해도 좋습니다. 출발점으로 깃허브 같은 곳에 계정을 만들고 자기 코드를 공개한다거나 다른 코드에 기여하는 경험을 해보는 것이 개발자에게 꼭 필요한 경험이라는 생각이 듭니다.
앞으로 계획이 있다면.
미국에 온 지 얼마 되지 않아서 적응을 잘하고 회사에 업무로 기여도 많이 하는 것이 1차 목표입니다. 지금까지 주로 기여만 하고 자신만의 프로젝트를 만들어본 경험이 없어서 어느 정도 적응이 되고 시간이 되면 저만의 프로젝트를 만들어보고 싶습니다. 그 외에 타이젠의 그놈 지원에 기여를 해보고 싶습니다. 그놈 개발자들이 타이젠 플랫폼에서 그놈 응용 프로그램을 잘 사용할 수 있게 해보고 싶습니다. 또 블링크가 나오면서 파편화가 심해졌는데 시간이 나면 그런 부분의 차이를 줄여나가는 일, 예를 들어 블로그에서 알려서 이슈를 제기한다든지, 한쪽에서 구현된 것을 미구현된 쪽에도 구현한다든지 하는 일도 해보고 싶습니다. 실제로 진행한 것도 있고요.
나에게 프로그래밍이란.
처음에는 레고 블록으로 뭔가를 만드는 것과 똑같다고 생각했습니다. 지금에 와서 생각해 보면 프로그래밍은 ‘세상과 소통하는 수단’ 같습니다. 내가 만든 코드를 통해 세상을 조금씩 개선시켜 나간다면, 이보다 값진 일은 없을 것 같습니다.
인터뷰이 소개: 허준회
8비트 시절, MSX2로 프로그래밍을 시작했고 경희대학교에서 물리학과 전산학을 공부했다. KLDP, 한국 모질라 커뮤니티, 그놈 코리아에서 활동했다. 삼성전자에서 모질라 및 웹킷 관련 프로젝트를 수행했고, 이후 콜라보라(Collabora)에서 웹킷 클러터 포트 개발 후, 현재는 인텔 오픈 소스 기술 센터(Intel Open Source Technology Center)에서 웹킷 개발자로 근무하고 있다. 블로그로 http://opensoftware.kr을 운영한다.
최준호 - 프로그래밍의 깊은 세계로 들어가는 길
류창우 - 그냥 부담 없이 취미로
