“블랙박스 탐험과 다양한 공부 엮어내기”

서광열 | 노매드커넥션 CTO
skyul@nomadconnection.com

프로그래밍 언어나 컴파일러 연구 분야를 '천재들의 무덤'이라 부르기도 하는데 관심을 갖게 된 계기가 있나요.
다른 사람들이 잘 모르기 때문에 더 공부하고 싶다는 청개구리(?) 심리가 약간 있었고 깊이 있게 접한 것은 교환 학생 시절 메릴랜드에서 'Programming Language Technology & Paradigm'이란 수업을 들으면서입니다. 학부에서 배우는 프로그래밍 언어와는 좀 다른 과목인데 이 수업에서 프로그래밍 언어의 속성을 분석하는 정적 분석(static analysis)에 대해 배우면서 재미를 느꼈습니다. 정적 분석이란 프로그램을 실행하기 전에 프로그램에 어떤 종류의 오류가 있는지 알아내는 방법을 연구하는 것입니다. 모든 분야가 깊게 들어가면 어렵기는 마찬가지긴 한데, 이쪽 분야는 특히 연구 결과를 실전에 활용하기가 쉽지 않습니다. 국내에는 이 분야 연구자들이 많지 않은 것으로 알고 있습니다.

구체적으로 어떤 면에서 매력을 느끼시나요.
보통 C, C++로 프로그래밍 언어를 시작하는데 이 언어들은 형식적 의미론(formal semantics)이 정의된 언어로 볼 수 없습니다. 물론 언어 명세(specification)는 있지만 컴파일러 개발자에 따라 구현이 다르게 나와 여러 운영체제와 환경에서 동일하게 동작한다고 보장할 수 없습니다. 반면 함수형 언어는 설계 자체가 람다 계산(lambda calculus) 이론 위에서 세워졌기 때문에 의미가 동일합니다.
다시 말하면 기존 언어는 '이 경우에는 이렇게 동작한다'하는 식으로 정의되어 있는 데 반해 함수형 언어는 의미가 논리(logic)에 기반을 두고 있어 해석 차이로 인한 불일치가 없다는 점이 매력입니다. 그런데 아직은 이 분야 커뮤니티에서 눈에 띄게 활동을 하는 건 아니고 개인적인 관심사입니다. 업무에 적용해 보려고 생각은 하는데 현실적으로는 함수형 언어로만 짤 수도 없고 함수형 언어로 짰을 때 더 효용을 얻을 수 있는 경우를 아직 찾지 못했습니다. 함수형 언어가 현재는 컴파일러 구현이나 심볼릭 컴퓨팅에서 논리 기반 추론(inference) 등에 많이 쓰이는데 응용 프로그램 쪽은 눈에 띄는 사례가 아직 없습니다. 펄 6 명세를 해스켈로 구현한 pugs 사례를 보면 함수형 언어가 컴파일러 구현에는 괜찮지 않나 하는 생각이 듭니다.

함수형 언어를 실제 업무에는 직접 쓰지는 못하지만 그 아이디어에서 도움을 얻은 적이 있나요.
상당히 많습니다. 함수형 언어가 기존 언어와 다르다고 막연히 생각하는 경우가 많은데 최근에 나온 언어들을 보면 함수형 언어에서 아이디어를 가져온 것이 많습니다. 특히 1990년대에 나온 언어들 중 루비나 파이썬을 보면 함수형 언어의 구조를 차용한 부분이 많습니다. 예를 들어 파이썬의 경우 함수형 언어의 특징이 반영된 map, reduce, filter 같은 하이오더(high order) 함수들을 기본으로 제공합니다.
저도 회사에서 파이썬으로 코드를 짤 때 그런 아이디어를 사용하구요. 물론 파이썬을 객체지향적으로 쓰는 부분도 있지만 함수형 언어의 아이디어를 이용해 짜는 부분이 상당히 많습니다. 함수형 언어를 비실용적이라고만 볼 수 없는 것이 그 자체를 직접 쓰지 않아도 거기에서 많은 개념을 빌려와 쓸 수 있으므로 한 번쯤 공부해둘 필요가 있다고 봅니다. 기존 언어로 개발을 할 때도 많은 도움이 되구요.

특히 유용한 상황을 예로 든다면...
여러 가지 상황에 유용합니다. 눈에 띄는 것으로는 디자인 패턴과 관련된 예를 들 수 있습니다. 디자인 패턴이란 것이 어떻게 보면 복잡한 문제를 푸는 아이디어의 집합인데, 문제의 복잡함 자체가 특정 프로그래밍 언어의 한계에서 비롯된 경우가 종종 있습니다. 그런데 이런 경우 함수형 언어의 기능을 가져오면 몇몇 패턴이 없어지기도 합니다. 예를 들어 커맨드 패턴의 경우 함수형 언어의 특성을 이용해 좀더 간단하게 처리할 수 있습니다. 즉 기존 언어로 해결하기에는 어려웠던 문제가 좀더 쉽게 해결되는 것이죠.

함수형 언어의 아이디어가 말씀하신 것처럼 차용되는 데는 어떤 이유가 있을까요.
객체지향은 훌륭한 패러다임이고 현실 세계를 모델링한 요구사항을 반영한 문제를 푸는 데 유리하지만 이 패러다임에 맞아 떨어지지 않는 문제들도 있습니다. 이런 경우에 무리하게 객체지향을 이용해 풀려고 하면 추상적인 개념이 나옵니다. 앞서 이야기한 커맨드 패턴도 그에 해당합니다. 문제를 바라보는 관점이 다양해지면 상황에 맞는 문제 해결 방법을 찾을 수 있게 됩니다. 현재로서는 완전한 함수형 언어보다는 파이썬이나 루비처럼 하이브리드적인 접근 방식이 더 현실적인 선택일 겁니다.

당장 업무에 도움이 되지 않는 것들은 등한시하는 경우가 많은데 학문적 관심과 실무 사이에서 균형 감각은 어떻게 유지하시나요.
프로그래밍 언어 외에도 다양한 분야의 글을 읽는 것을 좋아합니다. 당장 실무에 필요 없어도 새로운 기술이나 이론이 나오면 깊이 있게 알 수는 없더라도 한 번씩 읽어봅니다. 나중에 업무에서 어떤 제품을 만들 때 전에 읽었던 내용과 관련이 있을 경우 한 번 더 찾아볼 수 있어 도움이 됩니다. 얇은 배경 지식을 만들어 놓고 필요할 때 판단 기준으로 쓸 수 있으면 되거든요. 그런 측면에서 두루두루 볼 필요가 있다고 생각합니다.

평소에 쓰는 글을 보면 기술의 내부 원리나 구조를 파헤치는 내용이 많던데...
국내 블로그를 보면 IT의 큰 흐름이나 경향에 대해 쓰는 분들은 많은데 기술을 코드 수준에서 구체적으로 다루는 내용이 많지 않아서 그와 관련된 내용을 많이 쓰려고 노력하고 있습니다. 잡지에 기고도 종종 하는데 주로 기술의 내부 구현이나 작동 방식에 대해 쓰고 있습니다. 예를 들면 디버거에 대해 쓴다면 디버거의 동작 원리를, 컴파일러라면 컴파일러 최적화 방법에 대해 구체적으로 쓰려고 합니다. 제가 쓰는 기술에 대해서는 어느 정도 수준까지 알아야 한다는 철학이 있기 때문입니다.
개발자들이 어떤 기술을 쓸 때 중요한 것 중 하나가 레이어를 나누고 추상화를 하는 것인데 어느 부분까지는 블랙박스로 생각하고 그 위에서 뭔가를 만드는 경우가 많습니다. 윈도우의 경우 닷넷을 블랙박스로 생각하고 애플리케이션을 잘 만들려고 하는 것이 그 예입니다. 제 경우에는 전문적으로 가려면 제가 쓰는 기술의 내부 구조를 어느 정도까지 알아야 한다고 생각해서 그 분야로 관심을 두고 있습니다. 개발을 할 때 오픈소스 소프트웨어를 많이 쓰는 편인데 오픈소스를 쓰더라도 해당 소프트웨어 소스코드를 읽을 때가 많습니다. 블랙박스로 생각하지 않는 범위를 좀더 넓히는 것이죠. 그런 경험을 글로 썼구요. 간단하게 말하면 두루두루 많이 알자는 '주의'입니다.

기술의 맥락은 어떻게 파악하시나요.
많은 사람들이 새로운 기술이 나오면 튜토리얼을 읽고 예제를 보고 나서 코드를 짭니다. 그렇게 되면 기술의 출발이나 의도는 잘 모른 채 예제와 비슷한 방식으로밖에 그 기술을 쓰지 못하게 됩니다. 그보다 더 깊이 알고 싶다면 해당 기술의 배경이 된 논문을 읽거나 표준 기술의 경우 명세를 읽어야 합니다. 명세라는 것이 두껍고 지겹기는 하지만 읽는 사람과 읽지 않는 사람은 차이가 있습니다. 표준 기술의 내부 구조를 알고 싶을 때는 소스 코드를 읽는 것만으로는 어렵습니다. 표준이라는 것 자체가 복잡하기 때문입니다. 명세를 읽고 이해한다면 전체적인 그림이 보일 때가 있고 그것을 바탕으로 필요한 부분의 소스 코드를 읽어나가는 거죠.

정확한 비유는 아니지만 “모두가 '예'라고 할 때 '아니오'라고 하는” 성격의 글을 종종 과감하게 쓰던데...
브루스 에켈의 'Strong Typing vs. Strong Testing'을 읽고 글을 쓴 적이 있습니다.(http://skyul.tistory.com/16) 학계에서 말하는 프로그래밍 언어와 요즘 각광 받는 스크립트 언어는 여러 가지 면에서 다릅니다. 스크립트 언어라는 것이 '이러저러한 면이 있으면 좋겠다'는 여러 아이디어를 잘 엮어 만든 것이라면 학문적 접근 방식에서는 프로그래밍 언어에 필요한 속성과 이론적 기반, 향후 비전 등을 더 중시한다는 차이가 있습니다. 파이썬이나 루비 등에서 강조되는 동적 타이핑 역시 분명히 장점은 있지만 그에 따르는 희생도 있죠. 정리하면 모두가 '예'라고 하는 것에 대해 무턱대고 나쁘다고 반대하는 건 아니고 한쪽 측면만 부각되는 것에 대해 제가 공부한 내용을 토대로 정리할 필요를 느껴 종종 그런 글을 씁니다.

학계에서 보는 프로그래밍 언어와 현실 세계에서 환영 받는 스크립트 언어 사이에 접근 방식 차이가 나는 이유는 무엇일까요.
학계에서 전에는 '프로그래밍 언어라는 것은 사람이 쓰는 것이고 한 번 정해지면 잘 바뀌지 않는다. 새롭고 좋은 게 나와도 잘 받아들여지지 않는다. 기반 구조 성격이 강하므로 대기업이 밀지 않는 이상 퍼지기 힘들다'고 설명했습니다. 그런데 루비와 파이썬이 보급되면서 이 설명이 설득력을 잃었고 학계의 프로그래밍 언어 연구나 이론을 중요하게 여기지 않게 됐습니다. 하지만 앞에서 이야기한 것처럼 함수형 언어의 기법들이 루비나 파이썬 등에 채택되어 쓰이고 있으므로 학계의 연구 성과가 아주 쓸모 없지는 않다고 봅니다.
단정할 수는 없지만 파이썬이나 루비가 인기를 얻는 것은 프로그래밍 언어가 아무리 좋아도 사람이 이해할 수 없으면 쓰이지 않게 되는데, 루비나 파이썬은 그런 면에서 진입 장벽이 낮았기 때문이 아닐까 합니다. 반면 학문적 영역의 프로그래밍 언어에서는 포멀리즘을 중시하고 수학, 논리도 알아야 하죠. 이런 지식 없이 언어를 전체적으로 이해하기 어렵구요. 전문가로서 좀더 깊이를 갖추려면 단지 쉬워서 쓴다기보다는 그 기술의 장단점에 대해 잘 알고 쓰는 것이 중요하다고 생각합니다.

가장 많이 성장했다고 느낀 시기는 언제인가요.
학교 공부도 있었지만 예전 직장에서 김도형 팀장님(편집자 주: 디벨로퍼웍스에 칼럼 기고중)과 함께 일하면서 가장 많이 배웠습니다. 그 전에는 일과 학문을 연관시키는 법을 잘 몰랐습니다. '일은 일대로, 공부는 공부대로' 하는 거였죠. 그런데 팀장님은 어떤 일을 하기 전에 관련 자료를 먼저 꼼꼼하게 조사하고 필요하면 논문을 읽거나 논문 내용을 구현하기도 하는 스타일이었습니다. 팀장님을 많이 보고 배우려고 했고 어떻게 보면 역할 모델이었습니다. 학교에서 똑똑한 학생이었어도 실제 업무는 성격이 다르기 때문에 사회에 나오면 체계적으로 가르쳐 줄 사람이 필요합니다. 대부분의 경우에는 좋은 조언자를 못 만나고 외곬수로 치닫는 경우가 많죠. 일을 하는 체계적인 방법을 배우는 데는 잘 하는 분들의 조언이 중요하다고 생각합니다.

가장 많은 영감을 받은 코드는 무엇인가요.
자바 가상 머신 코드를 가장 많이 봤고 일관성 있게 잘 짠 코드라고 생각합니다. 잘 짰다는 기준은 성능이나 기능성보다는 다른 개발자들이 쉽게 이해하고 참여할 수 있느냐입니다. 아키텍처가 잘 짜여져 있어 기능이나 모듈을 쉽게 추가할 수 있어야 하거든요. 최근에는 오픈소스 코드들을 많이 보는데 수준이 천차만별입니다. 몇 사람이 하는 작은 프로젝트인데 잘 짠 경우도 있고 역사가 오래됐고 참여하는 사람도 많은데 새로운 사람들이 거의 알아볼 수 없는 프로젝트도 있습니다. 문서는 많은데 유지보수를 제대로 못해 프로젝트에 새로 참여한 개발자들이 파악을 못하는 경우도 있구요. 오픈소스가 좀더 많이 쓰이려면 소스코드의 일관성이나 문서 유지보수가 중요할 것 같습니다. 특히 라이브러리의 경우 공개된 API라면 문서가 제대로 갖춰져 있어야 한다고 봅니다.

현재 개발중인 까멜레오(Chameleo) 프로젝트에 대해 소개해 주세요.
까멜레오 프로젝트는 미디어 플랫폼을 지향합니다. 미디어 플랫폼이라는 표현을 쓰는 이유는 이클립스처럼 플러그인 형식으로 기능을 확장할 수 있는 아키텍처를 만들고 싶기 때문입니다. 미디어 재생 프로그램의 기본 기능을 제공하는 것 외에 써드파티 개발자들이 원하는 기능을 확장할 수 있게 하는 것이죠. 요즘 동영상 서비스 사이트들을 보면 플레이어의 기능이 대부분 비슷한데 다 따로따로 만들고 있습니다. 까멜레오 프로젝트에서는 그런 공통 기능은 쉽게 만들고 추가 확장은 원하는 대로 할 수 있으며 플래시 수준에서 벗어나 데스크톱 애플리케이션에 가까운 형식으로 만들어 보려고 계획중입니다. 또 비디오 관련 부가 정보를 어떻게 다룰 것인지가 중요합니다. 대표적인 예가 자막인데 그 이상의 메타 정보를 저장, 처리할 수 있다면 다양한 서비스를 개발할 수 있으리라 봅니다. 현재 중요 모듈은 C•C++로, 나머지 부분은 모두 파이썬으로 작성되어 있습니다.

까멜레오 프로젝트를 오픈소스로 발표하기로 결정한 계기는 무엇인가요.
체계적인 투자라고 봅니다. 현재 회사 개발자가 많지 않아서 오픈소스를 쓰지 않을 경우 추가 개발 이슈가 늘어납니다. 반대로 오픈소스를 많이 가져다 쓸수록 직접 개발할 거리가 줄고 더 빨리 만들 수 있게 됩니다. 해외에서는 오픈소스를 최대한 가져와 그것들을 엮어 부가가치를 만들어내는 신생 기업들이 많습니다. 대표적인 예가 주스트인데 100개가 넘는 오픈소스 소프트웨어를 사용하고 있습니다. 사실 서로 다른 환경에서 만들어진 100여 개의 소프트웨어를 통합하려면 단순히 베끼는 게 아니라 상당한 기술력이 필요합니다. 대기업에 납품하는 것이 아니라면 소스코드 자체를 비밀로 지키는 것은 큰 의미가 없습니다. 오히려 그걸 공개하고 다른 개발자들의 도움을 최대한 받을 수 있는 환경을 만드는 게 더 유익하다고 봅니다. 코드를 공개하지 않아도 되는, 상대적으로 덜 엄격한 라이선스를 쓰는 오픈소스 소프트웨어를 쓸 수도 있겠지만 소스코드 공개 없이 '우리를 위해 플러그인을 만들어 주세요'라고 하는 건 상생 관계는 아닌 것 같습니다. 이 소프트웨어 자체를 돈으로 보기보다는 이 소프트웨어를 기반으로 한 생태계가 생기는 것이 더 중요하죠.

까멜레오 프로젝트를 오픈소스로 발표하기로 하면서 가장 많이 고려한 부분은 무엇인가요.
아키텍처라는 것이 구성요소를 어떻게 끼워넣을 것인지의 문제이므로 기존 소스코드를 다 알지 못해도 끼워넣는 인터페이스만 잘 파악해 자신의 구성요소를 추가할 수 있게 만드는 점이 핵심입니다. 그런데 '내가 이렇게 만들어 주면 남이 쉽게 쓸 수 있겠다'하고 생각해 만들면 다른 사람이 쓰기 어려운 경우가 많습니다. 제 경우에는 필요한 플러그인을 API가 없는 상태에서 두어 개 미리 만들어 보면 공통으로 많이 쓰이는 API들이 나옵니다. 그걸 바탕으로 API를 정의하고 모듈화하는 과정을 거칩니다.

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

마지막 질문입니다. '명품 개발자의 8대 조건'이란 글을 쓰셨는데 어느 정도 실천하시나요.
운동은 거의 못하고 있고(웃음) 확실히 하려고 하는 건 배경 지식을 많이 쌓자는 것입니다. 그리고 요즘에는 인간 관계에 대한 필요성을 절실하게 느낍니다. 훌륭한 개발자 분들과 좋은 인적 네트워크를 맺는 것이 중요한 것 같습니다. 혼자서 배경 지식을 아무리 많이 쌓아도 그 깊이에는 한계가 있거든요. 결국에는 전문가에게 물어봐야 하죠. 20대엔 뛰어난 개발자가 혼자 공부를 많이 한 사람이라면, 30대 이후의 뛰어난 개발자는 그런 인적 네트워크를 갖춘 사람일 겁니다. 무슨 일을 하나 하더라도 더 빨리 할 수 있다면 잘 하는 사람들을 알기 때문이기도 하구요. 앞으로는 개발자 모임에도 참여해 보려고 합니다.

[서광열 소개] 현재 노매드커넥션 CTO로 재직중이며, 오픈소스 동영상 미디어 플레이어인 까멜레오를 개발하고 있다.

*IBM developerWorks의 개발자 인터뷰는 릴레이 인터뷰 형식으로 다음 인터뷰 대상자는 권영길 님입니다. 다음 인터뷰도 많은 기대 바랍니다.

[지난 인터뷰 보기]