http://osdi.insightbook.co.kr/2013/10/24/03-trustin.html
널리 알려지지는 않았지만 그 전설 같던 시절이 지나고 이제는 누구나 오픈 소스라는 말을 어디선가 들어봤음직한 시대가 됐다. 오픈 소스로 뭔가를 할 수 있으리라 별로 기대하지도 않았고 리누스 토발즈 자서전 제목처럼 ‘그냥 재미로’ 오픈 소스를 다뤄온 사람들은 지금 무엇을 하고 있을까? 어떤 사람은 오픈 소스 개발이 생업이 되어 즐겁게 일하고 있고, 또 어떤 사람은 여전히 취미로 오픈 소스를 즐기며 산다. 이 인터뷰집은 그 사람들의 이야기 ‘일부’를 다룬 것이다.
--
src : http://www.ddaily.co.kr/data/photos/20121128/20121128005656__EN1T4.JPG
부모님을 졸라서 컴퓨터를 사셨다고 하던데 컴퓨터의 어떤 점에 끌렸나요?
일단은 재미있어 보였습니다. 당시에 아는 형이 윗집에 살았는데 그 집에 컴퓨터가 있었습니다. 그 집에 있는 컴퓨터를 보고 컴퓨터를 갖고 싶다는 마음이 생겼죠. 그렇게 해서 집에 컴퓨터가 생긴 후 컴퓨터 학원에 다니게 됐는지, 학원에 다니다가 집에도 컴퓨터를 둘 수 있다는 걸 알고 사달라고 했는지는 전후 관계가 잘 기억나지 않습니다.
첫 컴퓨터 기종은 뭐였죠?
처음 본 컴퓨터는 윗집에서 본 XT였던 것 같습니다. 실제로 만지고 프로그램을 짰던 컴퓨터는 학원에서 쓰던 MSX 시리즈였고요.
초등학교 2학년 때부터 프로그래밍을 했다고 하던데 처음 만든 프로그램은 무엇이었나요?
학원에서 프로그래밍을 배웠는데 그때는 교재에 있는 프로그램을 그대로 따라 치면서 프로그램을 배우는 방식이었습니다. 첫날은 책에 적혀 있는 그대로 프로그램 하나 치고 끝났던 것 같습니다. 베이직 언어로 ‘Hello, World’를 쳤었죠.
1980년대 컴퓨터 학원 분위기는 어땠나요?
학원에 있던 컴퓨터는 대부분 MSX였는데 막 XT로 넘어가던 시기였습니다. 제가 XT를 사고 나서 얼마 안 돼서 학원 컴퓨터들도 XT로 바뀌기 시작했던 것 같습니다. 어쨌든 컴퓨터를 막 샀을 당시에는 집에 있는 컴퓨터와 학원 컴퓨터가 달라서 약간 적응이 안 됐었죠. 선생님이 수업을 하고 책에 적혀 있는 대로 쳐보고 나중에는 선생님이 가르쳐주는 식이었습니다. 기억을 돌이켜보면 선생님도 컴퓨터를 잘하는 분은 아니었던 것 같습니다. 수업이 끝나고 아이들이 돌아갈 때쯤 남아서 공부를 하시더군요. 반복문 같은 걸 공부하고 있었던 것 같은데 그때는 그런 걸 몰랐죠. 일요일이 되면 학원에 수업은 없는데 학생들이 와서 게임을 할 수 있었습니다. MSX는 카트리지 슬롯에 게임을 넣으면 오락기처럼 게임이 됐죠. 게임도 좀 했는데 부모님이 별로 좋아하지 않으셔서 많이 하지는 못했습니다.
그 당시에는 공부라기보다는 놀이에 가까웠겠군요.
예. 그렇죠.
어렸을 때 하루에 몇 시간 정도 컴퓨터를 쓰셨나요?
보통 밖에 나가 노는 시간 빼고는 컴퓨터를 썼던 것 같습니다. 집에 컴퓨터가 없었을 때는 학원에서 쓰는 게 다였는데 컴퓨터가 생긴 후로는 친구들과 한두 시간 놀 때 빼고는 쭉 컴퓨터를 썼습니다.
당시 배웠던 것들이 지금까지 도움이 된 건가요?
그런 시간이 다 합쳐져서 프로그래밍을 배워온 거니까 도움이 됐다고 할 수 있겠죠. 뭐든지 장시간에 걸쳐 계속하다 보면 향상되기 마련이니 특별한 건 아니라고 생각합니다.
스스로 ‘재능이 있다’고 느꼈던 적이 있었나요?
그런 생각은 별로 안 해본 것 같습니다. 어느 정도 공부한 후에는 새로운 것을 익히기가 어렵지 않다든가 하는 건 느꼈습니다. 어렸을 때 배운 것이 많은 도움이 됐다고 생각합니다. 컴퓨터가 어떻게 동작하는지에 관한 이해 자체가 체득되어 있는 상태가 돼서 다른 사람은 이해하는 데 어려움이 있더라도 제 자신은 당연하게 받아들일 수 있는 그런 이점이 있었던 것 같습니다.
PC 통신 동호회에서 활동하셨다고 하던데 당시 동호회 분위기는 어땠나요?
게임 제작 동호회(GMA)에서 활동했었고요. 당시 학생이어서 오프 모임은 잘 나가지 않았고 게시판과 대화방 활동을 많이 했습니다. 당시 동호회에는 소스 코드, 그리고 번역을 하거나 직접 쓴 글들로 된 강좌가 많았습니다. 자기가 만든 게임, 라이브러리, 편집기, 도구 등을 소스까지 공개하는 경우도 많았죠. 많은 도움이 됐습니다. 또 제가 코드를 공개해서 리뷰를 받는다든지 해서 기술을 향상시키는 데도 도움이 됐습니다.
오늘날 인터넷 환경의 개발자 커뮤니티와 비교해 본다면 어떨까요?
PC 통신 시절이 결속감이 약간 더 있었던 것 같아서 그때를 나름 추억하게 되긴 하는데 어느 때가 더 좋은지는 말하기 어려운 것 같습니다.
네티가 공개되던 당시 ‘거의 최초로 쓸 만한 자바 기반 네트워크 프레임워크’로 알려졌는데 맨 처음 개발을 시작했을 때 부딪혔던 어려움은 무엇이었나요?
당시에는 자바 자체에 논블로킹 I/O라는 게 없어서 논블로킹 I/O인 것처럼 에뮬레이션을 해야 했습니다. 소켓에서 데이터를 읽을 경우 데이터가 이미 들어와 있을 때만 읽고 그 외에는 다른 작업을 해야 하는데, 데이터가 들어와 있는지 아닌지 정확히 알려면 소켓에서 직접 데이터를 읽어봐야 합니다. 그런데 자바에는 논블로킹 I/O 자체가 없었고, 물론 운영 체제에서 지원은 했지만, 자바 API에서 빠져 있었죠. 실제로 읽는 순간 블로킹이 됐고 시간이 가버려서 그걸 해결하려고 약간의 꼼수 같은 걸 썼습니다. 그런 게 약간 불편한 점이긴 했는데, API 자체 설계는 내부적으로 구현이 어떻게 되어 있든지 간에 개발자가 API를 어떤 모습으로 노출하기 원하느냐의 문제라서 그 문제를 어느 정도 해결하고 난 후에는 그다지 어렵지는 않았습니다. 다만 현업에서 쓰려고 네티를 개발한 것이어서 제가 작업하는 프로젝트에서 이런저런 부분이 필요하다고 판단했을 때 지속적으로 바꿔나가고 하는 일들이 힘들다면 힘들고, 재미있다면 재미있었습니다.
자바에 논블로킹 I/O가 정식 도입되기 전부터 그 필요를 느끼셨던 건가요?
정확히는 블로킹이든 논블로킹이든 관계없이 이벤트 주도 방식으로, 즉 어떤 메시지가 왔을 때 메시지가 왔다고 콜백을 호출해 주는 GUI 프로그래밍을 하듯이 네트워크 애플리케이션을 개발하고 싶다는 의도였습니다. 그게 내부적으로 블로킹이든 논블로킹이든 크게 중요하지 않았는데, 그런 이벤트 주도 방식과 논블로킹 모델이 합쳐졌을 때 더 큰 효과를 발휘할 수 있어서 적극적으로 도입하게 됐습니다. 처음에는 논블로킹도 중요했지만 일단은 이벤트 주도 방식에 집중했었습니다.
자바는 인터넷 시대를 위한 언어로 마케팅되기도 했는데 쓸 만한 네트워크 프레임워크가 없었다는 건 좀 의외인 것 같습니다.
어떻게 보면 논블로킹의 이득이 한 스레드로 여러 연결(connection)을 처리한다든지 하는 부분인데요. 논블로킹을 쓰지 않아서 생기는 제약은 당시의 부하 수준을 생각해 봤을 때 좋은 하드웨어만 있으면 감당되지 않았나 싶습니다. 당시에도 논블로킹이나 비동기 I/O로 처리를 극대화할 수 있다는 걸 알았지만 그 정도까지 하지 않아도 어느 정도는 서비스가 됐었죠. 병목이라는 게 네트워크 I/O에도 있지만 궁극적으로는 백엔드 데이터베이스 같은 쪽에 더 좌우됐기 때문에 크게 중요하게 여겨지지는 않았던 게 아닌가 싶습니다. 그런데 요즘은 스케일이 워낙 커져서 그런 수준으로는 감당할 수 없는 경우가 생깁니다. 클라우드를 이용해 유연하게 장비를 늘릴 수도 있지만 장비 효율성을 따졌을 때는 효율성이 높으면 높을수록 장비 대수가 줄어들기 때문에 결국 그 문제는 해결하고 넘어가야 하는 거죠. 그래서 최근 들어 논블로킹이나 비동기 방식이 더 많이 쓰이는 것 같습니다.
회사에서 쓰기 위해 개발했다고 하셨는데 선례가 많지 않았던 당시에 과감히 시도해야겠다고 결심한 동기는 무엇인가요?
당시에는 자바로 서버를 짜는 것 자체도 전례에 없던 일이긴 했습니다. 당시에 제가 개발한 게 SMS 게이트웨이였는데, SMS 전송 요청이 들어오면 그걸 이동통신사와 통신을 해서 실질적으로 SMS가 전송되도록 하고 그 결과를 보고하는 형태의 게이트웨이 또는 리버스 프록시라고 할 수도 있는 시스템이었습니다. 그때까지는 그런 종류의 소프트웨어는 거의 C나 C++로 개발되어 있었죠. 그런데 당시에 자바로 개발했던 건 아무래도 제가 자바에 익숙했기 때문이 아닌가 싶습니다. 그 전까지 사실 C, C++를 오랫동안 써오기는 했는데 실제 직업으로 개발할 때 C, C++를 쓴 적은 거의 없었던 것 같습니다. 자바로 처음 시작했죠. 그냥 자바가 편했고 할 수 있을 것 같았습니다. 결과적으로 봤을 때도 빠른 시일 내에 이동통신사와 연동을 성공적으로 마칠 수 있었고, 분산 처리 같은 것도 쉽게 추상화 계층을 만들 수 있다는 자바의 특징 때문에 좀 더 쉽게 개발할 수 있었습니다. 도움이 많이 됐죠.
당시에 회사 지원은 어땠나요?
처음부터 오픈 소스를 개발하겠다고 이야기하지는 않았습니다. 주말에 생각이 나서 프레임워크처럼 만들고 나서 회사에서 그걸 써보고 고치고 하는 식으로 뼈대를 맞췄다고 할 수 있습니다. 회사에서는 SMS 게이트웨이를 얼마나 빨리 고성능으로 개발할 수 있느냐가 관심사였기 때문에 오픈 소스 여부는 특별히 신경 쓰지는 않았던 것 같습니다.
당시 어느 정도 성능이 향상됐었나요?
성능 향상이라고 하기는 어려웠습니다. SMS는 특성상, 오늘날에도 트래픽이 줄어들고 있기는 하지만, 당시에 무선 사용자가 많기는 해도 지금만큼은 아니어서 메시지 유입 속도가 빠르지는 않았습니다. 그래서 개발의 속도 자체가 중요했죠. 당시 이동통신사가 다섯 곳이었고 프로토콜이 다 달랐습니다. 그런데 기본적인 로직 자체는 비슷해서 SMS 요청을 받고 요청에 대한 응답을 주고 나중에 결과를 주고 하는 기본적인 흐름은 이동통신사 프로토콜들이 비슷했습니다. 다만 약간의 차이는 있었는데 그런 걸 고려했을 때 공통화된 메시지 모델을 정립한 다음에 프로토콜 부분만 다르게 가져가고 그 메시지 모델에 따라 메시지를 주고받았을 때 어떻게 동작할지에 대한 비즈니스 로직만 구현하면 이동통신사와 관계없이 통신이 되니까요. 간단히 말하면 관심사의 분리(separation of concerns)를 서버 개발에 도입해서 잘됐고 그걸 바탕으로 패턴화해 프레임워크에 녹인 거죠.
말씀하신 그런 패턴들이 프레임워크에 어느 정도 완비되기까지 기간이 얼마나 걸렸나요?
기본적인 원리 같은 경우는 초반 4~5년쯤에 정립되지 않았나 싶습니다. 모든 프레임워크나 라이브러리 등 기술은 단순히 아이디어가 정립됐다고 해서 성공하는 게 아니라 구체적인 구현 레벨에서 완성도를 달성한다든지 세부적인 부분에서 디자인 기준이 잘 정해져야 하는데 그런 걸 하나하나 이뤄나가고 피드백이 왔을 때 바꿔나가는 과정을 점진적으로 밟아오다 보니 시간이 그렇게 걸린 것 같습니다.
처음부터 모든 계획이 세워져 있던 건 아니었군요.
예. 어떤 기능이 필요하다고 요청이 많이 올 경우에 그 기능에 대해 좀 더 생각하고, 어떤 문제점이 드러났을 때 그 문제점을 해결할 수 있는 걸 디자인에 우선 반영해 바꿔나가는 식으로 작업했습니다. 애초에 모든 걸 완벽하게 디자인할 수는 없으니까요. 그런 면에서 오픈 소스 방식으로 개발하면 다양한 창구를 통해 피드백을 받을 수 있죠. 오픈 소스로 작업하지 않았으면 결국에는 제가 일하는 회사나 속한 조직의 피드백만 받았을 텐데 그러면 한계가 있습니다. 네티를 쓰는 산업군 자체가 다양해져 예를 들어 SMS, 물류, 웹 서버 등 여러 분야에서 피드백이 온 덕분에, 좀 더 많은 사람이 쓸 수 있게 일반화되면서도 특정 분야에 적합하게 응용될 수 있도록 디자인이 바뀌어 나간 거죠. 오픈 소스가 좋은 접근 방법이었습니다.
그동안 개발해 오면서 잘했던 결정이었던 것을 꼽자면.
기술적인 변화가 많아서 구체적으로 나열하기 쉽지 않지만 기억나는 기술적인 변화로는 JDK에서 제공하는 버퍼 API가 불편해서 처음부터 새로 구현한 것입니다. 그러고 나서는 그걸로 JDK에서 제공하는 버퍼 API를 래핑해서 쓸 수 있게 한다든지, 아니면 아예 새로 구현해 쓸 수 있게 한다든지 하는 형태로 해왔습니다. 좋은 결정이었던 것 같습니다. 아무리 표준 API라 하더라도 사용자가 쓰기 불편하고 느리면 그다지 효용이 없는데요. 제일 좋은 예는 JDK의 로깅 API입니다. 표준화가 되긴 했는데 많은 사람들이 JDK의 API는 잘 쓰지 않고 Log4j 같은 걸 쓰죠. 그런 걸 보면 너무 한쪽 표준에 치우치지 않았던 게 도움이 됐던 것 같습니다. 대부분은 점진적으로 발전해 와서 결정적으로 중요했다고 할 만한 것은 없는 것 같습니다. 다만 도움이 많이 됐던 것 한 가지는 아파치 소프트웨어 재단에 참여하면서 인지도가 높아져서 많은 피드백을 받고 많은 사람들이 참여할 수 있게 되어 프로젝트가 발전한 계기가 된 것을 들 수 있겠습니다. 프로젝트가 어느 정도 성장하고 나서는 아파치 소프트웨어 재단에서 나와서 좀 더 자유롭게 개발하기로 한 것이 오히려 또 도움이 됐고요. 재단에서 나오기는 했지만 프로젝트 자체의 가치와 성장 동력을 잃지 않고 프로젝트를 진행할 수 있었던 것 같습니다.
지난 10여년 중에서 아이디어 구상이나 코딩 등 작업 능률이 가장 좋았던 시기는 언제였나요?
네티가 점진적으로 개발되어 오기는 했지만 API 하위 호환성을 깬 주요 리비전이 여러 번 있었습니다. 네티 1, 2, 3, 4 이렇게 넘어오면서요. 중간에 아파치 미나로 개발하던 때도 있었고요. 네티 1은 거의 개인적인 용도로 썼다면 그다음 2로 갈 때 그걸 바탕으로 다시 한 번 만들었습니다. 미나로 넘어갈 때 네티란 이름을 그대로 쓰면 어떨까 싶었는데 지적재산권 등 처리 절차가 복잡해서 미나로 이름을 바꾸고 처음부터 다시 작성했습니다. 아파치 소프트웨어 재단을 나온 후에는 재단과 독립적으로 포크도 하지 않고 아예 새로 작성해 개발했습니다. 그러면서 기존 문제점 중 점진적으로 해결하는 것만으로는 불가능했던 부분들을 단번에 해결할 수 있었습니다. 다만 문서 작성이 부족해서 신경을 쓰고는 있는데 오픈 소스 자체가 항상 변화하는 것이다 보니 어려움이 있습니다.
API를 만들 때 지키는 원칙이 있다면.
사용자 입장에서 작성하는 것입니다. API를 처음에 설계할 때 ‘내부 구조를 이렇게 저렇게 해서 어떤 모습으로 만든다’가 아니라 ‘API가 어떤 모습이면 좋겠다’에서 시작해 내부 구현을 하는 방식으로 대부분 진행합니다. 그런 식으로 작성하는 편이 사용자가 실제로 쓰기에도 편리하고요. 또 어느 정도 기본적인 편의성을 갖춰 놓고 난 후 사용자들이 쓰다 보면 불편한 부분이 드러나게 마련인데 그런 부분이 근본적인 문제라면 사용자들이 쉽게 짚어내지 못하지만 사소한 문제, 예를 들어 어떤 함수의 반환 타입이 어땠으면 좋겠다는 것은 개발하면서 쉽게 제안할 수 있는데요. 그런 사소한 부분을 사용자들의 피드백을 받아서 개선해 나가면서 최종적으로 어떤 그림이 될지에 대해 계속 스스로 예제를 만들듯이 프로토타이핑을 계속해 가면서 만들죠. 그렇게 하는 게 API의 디자인에 상당히 중요한 역할을 하고요. 그 외에 하위 호환성도 중요하지만 논리적인 이유가 있을 경우에는 적극적으로 변화를 추구하는 것도 괜찮다고 생각합니다.
회사에 소속되어 네티를 개발하면서 얻는 긍정적인 점은 무엇인가요?
회사에 네티 기반으로 개발된 소프트웨어들이 있고 그 소프트웨어들이 처리하는 트래픽량이 어마어마해서 중간 규모에서 발견하지 못하는 문제들에 대해 피드백을 받을 수 있습니다. 예를 들어 네티 3의 경우에는 이벤트가 발생했을 때 이벤트 객체를 그냥 만들어 뿌렸는데 이벤트 객체의 메모리 풋프린트가 크지 않기는 했지만 규모가 커지다 보면 가랑비에 옷 젖듯이 가비지 컬렉터에 부하를 줄 수 있습니다. 대형 서비스에서는 가비지 컬렉터를 제어하는 게 가장 중요한 문제가 되는데요. 그래서 가비지 컬렉션의 빈도를 줄이고 가비지 컬렉션이 일어나더라도 그것 때문에 멈추는 시간을 최소화하도록 하는 게 중요합니다. 가비지 컬렉션이 덜 일어나게 하려면 네티 쪽에서 어떻게 해야 하는지가 문제입니다. 기존에는 자바 가상 머신이 짧은 시간 동안 만들어졌다가 사라지는 객체는 처리를 잘해서 풀링 같은 걸 할 필요가 없다고 했는데 실제로는 필요했던 거죠. 네티 4에서는 그런 것까지 다 고려해 디자인을 새로 해서 메모리 대역폭 사용이라든지, 가비지 컬렉션 빈도를 많이 줄였습니다.
그런 피드백을 받기 전에는 네티가 어느 정도 규모에서 쓰이리라 예상하셨나요?
특별히 규모를 예상하지는 않았습니다. 제가 그런 규모에서 직접 돌려본 적이 없었으니까요. 어떻게 보면 이론적인 생각으로 만들어서 그게 실질적으로 동작한다는 것을 사용자들이 증명해 준 거죠. 저는 기껏해야 1~3만 개 연결밖에 테스트해 보지 못했습니다. 그 이상 테스트하려면 장비 등 여러 문제가 있었고 모든 시나리오를 테스트하는 것도 불가능했으니까요. 그래서 그 정도면 되지 않을까 하고 생각했는데 그 정도도 되고 더 많이 할 수도 있다는 것은 오히려 외부에서 알려준 적이 많았습니다.
앞서 말씀하신 가비지 컬렉션 문제 같이 언어적인 부분의 향방이 네티 개발에 영향을 적지 않게 미칠 것 같습니다.
JDK 소스 중 동시성 처리 부분이나 저수준 코드를 보면 내부에 숨겨진 API가 있는데요. 이른바 안전하지 않은(unsafe) API라는 것인데 보통 이런 API를 쓰게 되면 가상 머신 구현에 따라 다르지만 그런 호출이 일어나는 부분을 자바 가상 머신이 컴파일할 때 기계어로 1대1 치환을 한다든지 해서 속도를 높이게 되어 있습니다. 문제는 그런 저수준 기능들이 자바 가상 머신을 멈추게 할 수도 있지만 숙련된 사용자가 이용해서 개발할 경우에는 상당히 고성능 애플리케이션을 개발할 수 있는데도 아직까지는 표준 API의 일부가 아닙니다. 그래서 그런 API들은 오라클 JDK나 오픈JDK에서만 쓸 수 있습니다. 그걸 표준 API화한다면 자바 가상 머신 기반 애플리케이션들이 성능 면에서 한 단계 도약할 수 있지 않을까 생각합니다.
향후 JDK 8 이후도 다 대응할 계획인가요?
그래야겠죠. 한편으로는 자바 자체의 한계가 있는 것도 사실이라서 언어 측면에서 변화를 주지 않는 이상 처리가 어려운 부분은 어떻게 하면 좋을까, 과연 자바 가상 머신 기반으로 하는 것이 맞을까 같은 생각도 하고 있습니다.
네티 기반으로 만들어진 소프트웨어 중에서 인상 깊었던 것을 꼽는다면.
지금은 네티를 쓰지 않는 걸로 아는데요. 현재 타입세이프(Typesafe)라는 회사에서 관리하는 아카(Akka)가 처음 개발될 당시에 네트워킹 스택을 네티를 이용해 구현했었습니다. 쉽게 분산 액터를 구현했었죠. 아카가 성장하면서 서로 홍보도 잘됐고요. 요즘은 자체적으로 개발해 쓰고 있는 것 같습니다. 또 vert.x도 재미있는 것 같습니다. 공식 마인크래프트 서버는 대용량 처리가 어려워서 수정해 네티 기반으로 바꾼 게 있습니다. 마인크래프트처럼 잘 알려진 소프트웨어에서도 네티를 쓸 수 있다는 점이 흥미로웠습니다. 항만 물류 시스템 통신에서도 쓰인다는 이야기를 들은 적이 있고 페이스북에서 만든 니프티(Nifty)라는 것이 네티 기반인 것으로 알고 있습니다. 신기하기도 하고 뿌듯하기도 했습니다.
12년째 됐는데 네티의 장수를 위해 구상 중인 것이 있다면 무엇인가요.
버전 4의 API가 완성되면 당분간은 기능 추가 형태로 지속될 것 같습니다. 그러다가 버전 4의 API로 처리되지 않는 장벽이 나오면 버전 5가 나올 테고, 그런 식으로 진행될 것 같습니다. 그런데 과연 영원히 네티만 하고 살 것인가에 대해서는 잘 모르겠고요. 다른 분야도 계속 탐구해야 하지 않을까 생각은 하고 있으나 일이 많아서 그것만 해도 시간이 빠듯할 것 같습니다(웃음).
눈여겨보는 다른 분야가 있다면.
네티 자체는 한 노드에서 얼마나 성능을 끌어올리느냐의 문제지만 분산 시스템에서는 어떻게 처리할 것이냐는 또 배울 필요가 있는 것 같습니다. 회사에 그런 것들이 잘되어 있어서 앞으로 회사의 앞선 기술력을 배우고 똑똑한 동료들을 만나서 스스로 성장하는 게 좋겠다고 생각합니다.
프로젝트 리더로서 방임형과 카리스마형 중 어느 쪽에 속한다고 생각하나요?
팀 자체가 크지 않아서 대단한 카리스마는 필요하지 않았던 것 같습니다. 아무래도 제가 시작해서 코드 대부분을 작성했기 때문에 기여하는 사람들이 다행스럽게도 저를 많이 존중해 주어서 프로젝트를 이끄는 데 큰 어려움은 없었습니다. 다만 커밋 권한을 준 사람이 마음에 들지 않는 코드를 커밋했을 때 스트레스를 받기는 합니다. 제가 기분이 좋지 않다고 해서 그 사람을 내쫓을 수도 없고 잘 짤 때도 있지만 항상 믿을 수만은 없어서 역시 코드 리뷰를 세심하게 하면서 피드백을 주고 코드 수준에서 검토를 확실히 해두는 게 좋지 않나 하는 생각을 하고 있습니다.
다 같이 의사 결정을 해야 했을 때 어려웠던 경험은 없었나요?
아파치 소프트웨어 재단에 속해서 개발할 때 그런 경험을 좀 했습니다. 별다른 진척은 없는데 말만 오간다고 할까요? 그런 경우가 피곤했습니다. 그게 장점이 될 때도 있지만 제가 원하는 속도대로 진행할 수 없을 때 답답함이 있었습니다. 그럴 때는 제가 이끌어서 최종 결정을 하고 그걸 이해하는 사람들이 함께하면 크게 문제가 되지 않는데요. 이도저도 아닌 경우에는 오히려 좋지 않게 흘러가죠.
재단에서 독립한 이후에는 그런 문제가 없어진 건가요?
예. 한동안은 혼자서 작업을 많이 했고 기여하는 사람들이 적극적으로 다 참여한다기보다는 큰 부분의 일부라든지, 특정 부분을 담당해서 수정하거나 기여하는 형태여서 전체적으로 참여하는 사람은 거의 없었습니다. 요즘에는 좀 생기고 있고요. 그래도 최종 권한이 저한테 있다는 걸 다 인식하고 있어서 큰 어려움 없이 개발하고 있습니다.
위원회가 있는 프로젝트와 지금처럼 자유롭게 운영되는 프로젝트 각각의 일장일단이 있다면.
위원회가 있으면 좀 더 안정적으로 프로젝트에 대한 피드백을 받을 수 있고 의결 절차를 거쳐서 프로젝트가 진행되기 때문에 좀 더 공평하다는 느낌을 받을 수 있습니다. 재단 밑에 소속되기 때문에 법적인 문제에 대해 좀 더 안전합니다. 그런 면에서는 장점이 있습니다. 또 재단이 정한 규칙에 따라 공평하게 프로젝트에 기여할 수 있는 기회가 주어지는데 그런 점 때문에 기업들이 어떤 오픈 소스 프로젝트를 이용해 개발할 것인지를 결정할 때 중립 지대 역할을 해줄 수 있는 재단의 프로젝트를 선호하는 경향이 있었습니다. 요즘은 어떤지 잘 모르겠습니다. 개인으로 할 때는 좀 더 빠르게 움직일 수 있고 의사 결정을 하는 데 너무 불필요하게 오래 시간을 끈다거나 기술적으로 잘 모르는 사람이 위원회에 있을 때 설득하는 데 시간을 많이 할애하지 않아도 된다는 장점이 있습니다. 다만 법적 문제가 생겼을 때 알아서 해결해야 하는 문제가 있습니다. 그런데 오픈 소스 프로젝트 때문에 소송에 휩싸이거나 하는 문제는 근래에 거의 없어서 크게 위험한 것 같지는 않습니다.
의사 결정이 지체되지 않고 프로젝트가 기민하게 움직일 수 있는 적정 참여자 규모는 어느 정도가 좋을까요?
제가 해본 규모가 네다섯 명이라서 그 정도까지는 별 문제없이 잘 가지 않나 생각합니다. 프로젝트 규모가 커지면 한 사람이 감당할 수 있는 한계가 있기 때문에 분업도 필요하고 의사소통 비용이 생기게 마련인데 그게 발생하지 않을 수준의 작은 프로젝트들로 쪼개서 그 프로젝트들을 조합해 더 큰 프로젝트가 되는 형태, 즉 유닉스적 철학으로 접근하는 것도 좋지 않을까 하는 생각이 듭니다.
여러 가지 최종 결정 중 가장 어려웠던 것은 무엇이었나요?
4 버전 출시 후보(release candidate) 상태에서 최종판이 나오기까지 얼마 남지 않은 상황이었는데 API 디자인의 중대한 결함이 발견돼서 상당 부분을 수정해야 했습니다. 일정상 차질도 생겼고요. 결정을 과연 어떻게 할 것인지가 문제였습니다. 어쨌든 많이 바꿨는데 최대한 유지하면서 되게 만들지, 근본적으로 수정해서 내놓을지가 고민이었죠. 출시 후보 상태인데 또 API 호환성을 깨면 사람들이 황당해 할 테니까요. 다행히 많은 사람들이 아직 최종판이 아니고 변화를 꼭 주어야 하는 상황이라면 지금 하는 게 늦는 것보다는 낫지 않겠냐고 북돋아줘서 변경을 성공적으로 마무리해서 잘 진행했습니다. 서로 간에 신뢰 같은 것이 중요하지 않나 생각합니다.
프로젝트 인기가 프로젝트에 어떤 영향을 준다고 생각하시나요?
인기가 없었다면 그만큼 피드백도 덜 받았을 테니 어느 정도 선에서 충분히 완성됐다고 생각했을 수도 있겠죠. 그렇게 되지 않은 게 전체적으로는 좋았다고 할 수 있습니다.
직접 쓰려고 만든 오픈 소스 소프트웨어들이 성공 확률이 비교적 높은 것은 어떤 이유 때문일까요?
일단은 API 설계 자체가 정해진 사용 예를 위해 설계되고 그걸 위해 구현된 경우가 많고, 구현하고자 한 기능이 한정적이면서도 기존 오픈 소스 프로젝트들과 맞물려 돌아가기 쉽게 개발돼서인 것 같습니다. 오픈 소스로 개발되기 때문에 다른 오픈 소스들과도 잘 맞물려야 잘 쓸 수 있으니까요. 개발자가 사용자이기도 해서 두 가지 입장을 다 고려해 개발하기 때문에 API 설계 측면에서 사용자 친화적으로 개발될 가능성이 높다고 할 수 있습니다.
사용자의 요구와 개발자의 계획이 서로 맞지 않을 때는 어떻게 절충하시나요?
사업을 어떻게 이끄느냐와 비슷한 것 같습니다. 고객이 요구하는 바가 과연 해당 제품에 맞는 것이냐 아니면 다른 제품이 있어야 하는 것이냐에 대한 결정을 어떻게 할지는 엔지니어링 측면에서 생각해 봐야 할 겁니다. 모든 요구를 만족시킬 수는 없기 때문에 그 선을 어디에서 긋느냐는 정해진 바가 없는 것 같습니다. 딱 선을 긋기보다는 새로운 기능 추가 같은 변화를 제공했을 때 트레이드오프에 대해 따져 보고 조정하는 게 좋겠죠. 상황에 따라 다 다르므로 이럴 때 이렇게 해야 한다는 공식 같은 건 없는 것 같습니다.
회사에서 오픈 소스를 처음 활용할 때 흔히 내부 포크를 많이 하는데 어느 정도까지 포크가 적당할까요?
기본적으로는 가능한 한 내부 포크를 하지 않되, 어떤 경쟁 대상과 비교 우위에 설 수 있게 하는 기술에는 내부 포크를 하는 게 맞을 겁니다. 그 외의 경우에는 웬만하면 업스트림에 계속 반영할 수 있도록 하는 게 장기적으로는 유지 관리하는 데 도움이 되겠죠. 그리고 내부 포크를 한다 하더라도 관리하기 나름인데, 예를 들어 RPM 패키지를 보면 원(vanilla) 코드가 있고 거기에 패치를 해서 쓰는데요. 그렇게 하면 편리한 게 패치 목록이 있으니 어느 부분이 어떻게 수정됐고 왜 필요한지 명확히 할 수 있는데, 그냥 소스 코드 저장소를 그대로 가져와서 바뀐 내용을 계속 병합하고 덧씌우고 하다 보면 나중에는 어느 부분을 어떻게 변경했는지 뽑아내기 어려워집니다. 그렇게 되지 않도록 바뀐 부분이 뭔지 확실히 해서 패키징 하듯히 관리하는 게 낫지 않을까 생각합니다. 굳이 한다면 브랜치를 여러 개 두어서 바뀐 부분만 담고 있는 브랜치를 만든 다음, 최종적으로 빌드할 때는 병합하는 브랜치를 따로 두는 편이 낫겠죠.
회사 안에서 쓰려고 개발했던 것을 오픈 소스로 발표하려고 할 때 고려해야 할 점은 무엇일까요?
공개 후 유지 보수할 수 있는지 검토해 봐야 합니다. 그냥 소스만 공개해 놓고 내버려두면 추진력을 얻기가 쉽지 않거든요. 소스를 공개해서 회사도, 자신도 이득을 얻고 사용자도 혜택을 받으려면 최소한 프로젝트가 특정 궤도에 오르기까지 잘 관리해야 하고 또 크게 발전할 수 있도록 회사 외부 사람이 기여하더라도 차별 같은 게 없어야 합니다. 프로젝트가 쉽게 추진력을 얻으려면 중립 기구에서 시작하는 것도 좋다고 할 수 있습니다. 그렇게 하면 회사에서 코드를 많이 작성했다고 하더라도 회사가 항상 주도권을 쥐지는 않으니까요. 공정한 규칙 아래 프로젝트에 참여할 수 있게 되는 기틀을 제공하기 때문에 활용해 보는 것도 괜찮습니다. 중립 기구 없이도 잘할 수 있다면 그냥 해도 되겠지만 장기적인 발전을 위해 외부 참여를 자연스럽게 받아들이고 나아가 소유권을 외부에 이전할 정도의 의지가 있는지도 생각해 볼 필요가 있습니다. 그렇게 하지 않고 소스만 공개하고 말면 이미지만 나빠질 수도 있습니다.
오픈 소스 프로젝트를 시작하면 반드시 성공할 수 있다고 환상을 품는 경우도 있는데 자기 객관화를 할 수 있는 요령이 있다면 무엇일까요?
자기가 만든 게 잘됐으면 하는 바람은 누구나 있고 그런 기대가 있어서 열심히 하는 것이고 너무 없으면 시들하게 마련이죠. 다만 프로젝트의 가치에 대한 믿음이 있을 때 끈기 있게 할 수 있는 각오나 열정 같은 것이 있는지 여부가, 당장 프로젝트가 유명해지지 않았다고 하더라도 나중에 그 프로젝트가 주목을 받고 난 후 성공으로 이어지느냐 아니냐에 영향을 미치는 것 같습니다. PyPy란 프로젝트를 보면 실제로 프로젝트가 빛을 보기까지 상당한 기간이 걸렸다고 하죠. PyPy가 C로 구현된 파이썬보다 빨라지기 전까지는 많은 사람들이 ‘저걸 왜 하나’ 했겠지만 결국 구성원들의 믿음이 있었기 때문에 끝까지 해서 목표를 이뤄낸 거죠.
직접 주도하는 것 외에 참여해 보고 싶은 다른 프로젝트가 있다면.
제가 직접 언어를 만들지 않는다면 언어 프로젝트에 참여해 보고 싶습니다. 자바 가상 머신 기반이든 아니든 상관없이 참여해서 제가 부족하다고 느꼈던 것들을 해당 언어에 녹여낼 수 있으면 좋겠다는 생각을 하는데요. 언어 자체는 다양한 구현 방법이 있고 언어의 어떤 특성을 어떻게 가져올 것인지에 따라서 언어가 만들어지다 보니 취향을 많이 타게 되는데 제가 참여한다고 해서 제 취향이 받아들여질지는 잘 모르겠습니다(웃음). 그 외에 좀 더 로우레벨 프로그래밍을 해보고 싶다는 생각도 하고 있습니다. 지금은 자바 가상 머신이라는 추상화 계층과 자바의 네트워크 API를 통해 운영 체제의 네트워크 API에 접근하는 것이라서 추상화 계층이 제법 많습니다. 그런 것들을 간소화할 겸 이해도 높일 겸 좀 더 로우레벨 프로그래밍을 해보면 재미있지 않을까 싶습니다.
예전 인터뷰에서 “커뮤니티 성장은 마법과 같다”라고 하셨는데 아무나 할 수 없는 노하우란 의미인가요?
그렇다기보다는 일종의 1인 기업을 운영하는 것과 같다고 보면 될 것 같습니다. 어떤 프로젝트를 세팅해서 홍보도 하고 사람을 끌어 모으고 사람들이 다시 그 프로젝트를 찾게 하려면 다양한 노력이 필요한데요. 그런 다양한 노력도 필요하지만 한편으로는 운 같은 것도 작용하겠죠. 여러 요소가 복합적으로 작용하기 때문에 어떻게 보면 겉으로 보기에는 이른바 “대단히 복잡한 과학은 마법처럼 보인다”라는 것과 비슷한 것 같습니다.
현재 혼자서 코드를 어느 정도 커밋하시나요?
처음에는 90% 이상이었고 지금은 70~80%인 것 같습니다. 점진적으로 다른 개발자들의 참여를 늘려나가고 싶죠. 그러면서도 코드 품질을 유지해야 해서 그걸 어떻게 해야 할까 가끔 고민이 됩니다.
참여를 늘리기 위해 시도하는 전략이 있나요?
일단은 참여자 스스로 동기 부여가 되는 경우가 많은 것 같습니다. 또 가장 중요한 건 기여를 했을 때 피드백인데요. 너무 늦거나 겉핥기식 응답을 주면 기여자가 좋아하지 않고 흥미를 잃게 되죠. 그래서 적절한 시점에 유의미한 피드백을 주고 결과적으로 그 코드가 업스트림에 병합돼 발표까지 가는 경험을 할 수 있도록 적절히 빠른 시간 내에 해주면 알아서 잘 따라오는 것 같습니다. 일단 한 번 하게 되면 그다음부터는 자주 하는 사람도, 자주 하지 않는 사람도 있지만 어쨌든 하기 시작한 사람은 자주 기여를 하는 편 같습니다. 꼭 날마다 기여를 하지 않는다 하더라도 최소한 자기가 쓰고 있는 부분에 대한 문제가 생겼을 때 기여를 바로 해서 도움이 되도록 하는 게 좋습니다.
70~80% 정도를 맡아 한다고 하셨는데 그런 기여량의 차이는 어디에서 비롯될까요?
오픈 소스 자체의 어떤 매력에 기대고 있다고도 볼 수 있는데요. 오픈 소스 프로젝트를 시작해서 프로젝트가 어느 정도 궤도에 오르면 피드백이 오게 되는데 그 피드백이라는 것이 자신이 생각하지 못했으면서도 좋은 아이디어가 꽤 많아서 그 프로젝트에 대한 열정만 어느 정도 있다면 프로젝트가 알아서 술술 잘 굴러가게 되는 것 같습니다. 그러다 보니 제가 많은 부분을 작성하게 되는 거죠. 재미도 있고요.
피터 노빅이 「Teach Yourself Programming in 10 Years」란 글을 발표한 적이 있습니다. 숙련된 오픈 소스 개발자가 되는 데 시간이 어느 정도 걸릴까요?
이른바 1만 시간의 법칙이라고 하듯이 어느 정도 절대적으로 시간을 많이 할애할 필요는 있는 것 같습니다. 그런데 단순히 오픈 소스에만 시간을 할애할 필요는 없고 다른 프로그래밍이나 기술적인 것들을 다 포함해서가 아닐까 생각합니다. 오픈 소스 커뮤니티가 어떻게 돌아가는지에 대해서도 배워야 할 필요가 있겠지만 기본적으로는 기술적인 게 먼저이기 때문에 그 부분이 어느 정도 갖춰져야 그다음에 프로젝트에 참여하든, 프로젝트를 시작해서 사람을 끌어들이든 할 수 있는 거죠. 그런 준비가 되지 않은 상태에서 프로젝트를 하면 프로젝트가 운이 좋게 뜨더라도 코드에 기술적 빚이 많아서 잘되지 않을 수도 있기 때문에 어느 정도 기술적인 바탕이 된 다음에 오히려 오픈 소스가 더 빛을 발하지 않을까 생각합니다. 그렇다고 해서 ‘나는 수준이 안 돼서 오픈 소스 프로젝트를 할 수 없어’하고 그만둘 수는 없으니 어느 정도 성장해 나가면서 오픈 소스를 접하는 게 대단히 중요하다고 봅니다.
기술적 빚을 자주 보시나요?
오픈 소스 세계에서는 좋지 않은 프로그램은 그냥 도태되어 버립니다. 비슷한 종류의 프로그램이 많아서 무한 경쟁이니 잘못 만든 건 소리 없이 사라지는 거죠. 오히려 기술적 빚이 많은 코드를 자주 볼 기회는 없습니다. 그런 프로젝트에는 접근할 기회가 없으니까요(웃음).
오픈 소스 프로젝트에 참여해 보려다 코드 리뷰나 비평 같은 과정을 견디지 못하는 개발자들이 적지 않은 것 같습니다. 담력(?)을 키우는 비결이 있다면.
코드 리뷰를 하는 사람이 얼마나 바쁜지, 프로젝트가 얼마나 사람을 끌어 모으고 싶어 하는지에 따라 다른 것 같습니다. 이미 확립된 프로젝트는 사실 그렇게 할 필요도 없고 그렇게 하다가는 본인이 일할 시간이 없어지기 때문에 그렇게 할 수도 없고, 안 하게 되거든요. 그런 프로젝트에서는 오히려 냉담한 반응을 받을 수밖에 없기도 하죠. 그래서 시작하는 단계, 아니면 규모를 확충하려고 노력 중인 커뮤니티에서 활동하는 게 좀 더 재미있지 않을까 생각합니다. 하지만 고품질 코드를 계속 기여한다면 그 커뮤니티 분위기와 관계없이 잘될 수도 있을 겁니다. 하지만 배워나가는 입장이라면 작은 프로젝트부터 시작하는 게 도움이 될 겁니다.
현재 사용 중인 개발 도구 또는 환경은 무엇인가요?
회사에서 지급한 랩톱에, 운영 체제는 아치 리눅스, 데스크톱 환경은 LXDE, 언어는 자바, 개발 환경은 인텔리제이, 프로파일러는 유어킷, 그 외에 약간의 셸 스크립트를 씁니다.
개발 언어나 도구에서 불만족스러운 부분이 있다면.
자바 쪽에서 유명한 개발 도구로는 이클립스와 인텔리제이가 있는데요. 둘 다 장단점이 있어서 그런 점들을 합친 더 나은 게 나오면 좋지 않을까 생각도 합니다(웃음). 그다음에 언어 같은 경우는 제가 비동기 이벤트 기반 프로그래밍을 많이 하는데 언어 자체에서 네이티브로 지원하지 않아서 코드가 깔끔하게 나오지 않고요. 또 가비지 컬렉션에만 의존할 수 없는 버퍼 오브젝트 같은 경우에는 레퍼런스 카운트를 하게 되는데요. 언어 문법상에서 스코프를 벗어날 경우 레퍼런스 카운트가 자동으로 가감된다든지 하는 기능이 있으면 좋을 텐데 언어 자체에 그런 기능이 아예 없어서, 즉 객체 자체를 스택 할당할 수 없어서 답답할 때가 있습니다.
성능 최적화 작업은 어느 수준에서 절충하게 되나요?
일단 프로파일링을 기본적으로 하고요. 프로파일러에서 나오는 병목 위주로 해결하는데 어느 정도 해결하고 난 후에는 운영 체제 시스템 호출이나 JDK API 병목이 문제입니다. 그런 것들은 최적화가 어려워서 디자인에서 변화를 생각해 보거나 프로파일러를 다른 것으로 바꿔보기도 합니다. 유어킷 프로파일러가 정확하긴 하지만 다른 프로파일러로 봤을 때 또 다른 정보가 나올 수 있으니까요. 그 외에 자체적으로 벤치마크를 시행할 수 있는 도구를 만듭니다. 성능을 테스트하고 통계적으로 의미가 있는지 파악해서 점진적으로 바꿔나갑니다.
현존하는 프로파일러들은 만족스러운 수준인가요?
옛날보다 상당히 좋은 상황이라고 할 수 있습니다. 오버헤드 거의 없이 병목을 대부분 찾아낼 수 있으니까요. 특히 리눅스에서는 perf 라는 커널 레벨 성능 분석 도구가 있어서 오버헤드 거의 없이 병목이 어떤 부분이 될지 어느 정도 예측할 수 있죠. 하지만 메모리 사용량의 경우, 메모리가 새서 생긴 문제인지, 메모리 사용량이 많아서 생긴 문제인지 파악하기 어려울 때가 있습니다. 재현하기 어려워서, 어떻게 보면, 프로그램이 실행돼서 메모리가 꽉 차서 종료될 때까지 상황을 기록해서 되돌려본다든지 할 수 있는 것이 있으면 좋은데 그렇게 되면 느려지기 때문에 아직까지는 현실성이 없는 것 같습니다.
재택근무를 갓 시작했을 때 소감은 어땠나요?
당시에는 같이 일하는 사람들도 재택근무를 하고 있어서 저만 따로 떨어져 있다는 생각은 들지 않았습니다. 특별히 일한다는 것 자체가 힘들지는 않았는데 집중이 될 때는 아주 잘되다가 안 될 때는 너무 안 되는 게 문제였죠. 회사에 있으면 어쨌든 앉아서 일을 하게 되는데 집에서 일할 때는 집중이 안 되면 일을 잘 못하니까 좀 쉬게 되고 아무래도 효율이 떨어진다는 느낌이 들었습니다. 집중이 잘될 때는 방해하는 사람이 없어서 더 잘되기도 했고요. 능률의 저점을 더 높이면 좋은 성과가 나오지 않을까 하는 생각을 했었습니다.
외국에 나가서 근무해 보고 싶지는 않은가요?
해본 적은 있는데 지금도 본사에 한 번 가면 몇 주 정도 있다가 오니까요. 나가서 일하는 것과 비슷한 것 같습니다.
개발자들은 결혼 후 주의력이 분산되는 경험을 한다는데 결혼 전과 달라진 점이 있나요?
결혼 전에는 주말 시간을 더 많이 할애할 수 있었는데 결혼하고 나서는 잘 시간에는 자야 하고 주말에는 아기와 같이 놀아주기도 해야 하고, 어떻게 보면 업무 외 시간에 제가 원하는 걸 모두 할 수 없는 상황이 된 게 맞는 것 같습니다. 그런데 단기적으로는 시간을 할애하지 못하지만 장기적으로는 큰 문제는 없는 것 같습니다.
자신만의 재충전 방법이 있다면.
뇌는 계속 새로운 것을 원하기 때문에 쉰다는 것은 사실 뇌의 다른 영역을 사용하는 것이죠. 개발하다 쉬고 싶으면 다른 책을 봐도 되고 잠을 자도 되고 나가 놀아도 되고 드라마·만화를 봐도 되고 게임을 해도 되고…. 특별한 비결은 없는 것 같고 그때그때 하고 싶은 걸 합니다.
만약 서버 프로그래밍이 아니라 데스크톱 애플리케이션을했다면 개발해 보고 싶은 것이 있나요?
오디오 플레이어입니다. 제 취향에 맞는 건 아직 없는 것 같아서 그런 걸 한 번 만들어보고 싶습니다. 또 리눅스 환경에서는 국내 음원 스트리밍 서비스가 네이티브하게 지원되지 않아서 웹 플레이어를 쓰는데 캐싱이 잘 안 돼서 트래픽이 많거나 할 때는 노래가 끊기기도 해서 사용하기가 대단히 불편합니다. 윈도나 모바일 환경에 준하는 리눅스용 플레이어가 있으면 좋겠다는 생각이 듭니다. 그 외에 제 음악 컬렉션을 완벽하게 관리하고 재생할 수 있는 프로그램이 있으면 좋겠다는 생각을 하고 있습니다.
코세라에서 암호학을 공부했다고 하던데 그 이후에도 다른 과목을 들으셨나요?
관심 있는 과목은 계속 수강 신청을 해두고 있는데 요즘은 워낙 바빠서 못 듣고 있습니다. 수강 신청을 하고 수업에 들어가면 자막이 있는 동영상을 다 볼 수 있어서 영상을 미리 다운로드했다가 나중에 시간 날 때 보려고 합니다. 컴파일러나 프로그래밍 언어, 알고리즘 등을 다시 들어보고 싶습니다.
개발자로서 긱(geek)적인 흥미를 불러일으키는 일을 꼽는다면 무엇인가요?
저는 음악 관리를 열심히 하는 편인데요. 무손실 음원을 추출을 하기 위해 CD 리핑을 어떻게 할지, CD 리핑을 하고 나서 과연 제대로 리핑됐는지 어떻게 판단할지, 수많은 음반을 어떻게 관리할지 등에 시간을 좀 쓰는 편입니다.
시작하는 개발자들에게 해주고 싶은 조언이 있다면.
뭐든지 간에 자신이 좋아하는 걸 처음부터 끝까지 한 번 스스로 만들어보는 게 중요한 것 같습니다. 또 그걸 다른 사람과 나누는 게 도움이 되고요. 실행하지 않는 아이디어는 없는 것과 마찬가지이니 잘 실행하면 발전하리라 봅니다.
어느 정도 규모의 프로그램을 처음부터 끝까지 만들어보는게 좋을까요?
계산기 하나를 만드는 것도 생각보다 어렵죠. 그런 수준이더라도 계산기 컴포넌트를 갖다 붙여서 만드는 것보다는 처음부터 쭉 해보는 것이 많은 도움이 될 겁니다.
어떤 모습의 개발자로 늙고 싶으신가요?
해결하고 싶은 문제가 있을 때까지는 계속 개발을 하고 싶습니다. 나이가 들어도 계속 변화를 받아들여 나아갈 수 있는 모습이면 좋겠습니다.
앞으로 계획이 있다면.
단기적으로는 올해 안에 네티 차기 버전을 잘 내놓고 그걸 바탕으로 좀 더 성능을 높여서 HTTP 2.0까지 잘 대응해 프로젝트의 추진력을 계속 살려가는 것이고, 장기적으로는 단순히 한 애플리케이션의 확장성을 높이는 것(스케일업)을 넘어서 스케일아웃하는 기법에 대해서도 익혀나가려고 합니다. 그 두 가지를 잘 합쳐서 재미있는 것을 만들어보고 싶습니다.
인터뷰이 소개: 이희승
자바 가상 머신 기반의 대표적 네트워크 애플리케이션 프레임워크인 네티 프로젝트와 아파치 미나 프로젝트를 창시한 소프트웨어 엔지니어다. 연세대학교 1학년에 재학 중이던 1999년 말, 아레오 커뮤니케이션즈(현 스탠다드 네트웍스)에서 자바 프로그래밍 언어를 이용해 5개 이동통신사와의 단문 메시지 전송을 국내 최초로 상용화한 이래, 분산화된 대용량 단문 메시지 전송 게이트웨이, RPC 서버 같은 고성능 네트워크 애플리케이션을 꾸준히 개발해 왔다. 아레오 커뮤니케이션즈, 첫눈, nhn, 레드햇을 거쳐 현재는 트위터에서 근무하며 네티 프로젝트의 성능과 편의성을 한 단계 끌어올리기 위해 팀원들과 함께 노력하고 있다. 일상과 업무, 가족과 나 사이에 끝없이 번뇌하며 가족의 소중함을 절감하는 자택 근무 7년차다
류창우 - 그냥 부담 없이 취미로
김정균 - 자신을 발전시키는 소중한 공부
