출처 : http://osdi.insightbook.co.kr/2013/10/24/02-oops.html
널리 알려지지는 않았지만 그 전설 같던 시절이 지나고 이제는 누구나 오픈 소스라는 말을 어디선가 들어봤음직한 시대가 됐다. 오픈 소스로 뭔가를 할 수 있으리라 별로 기대하지도 않았고 리누스 토발즈 자서전 제목처럼 ‘그냥 재미로’ 오픈 소스를 다뤄온 사람들은 지금 무엇을 하고 있을까? 어떤 사람은 오픈 소스 개발이 생업이 되어 즐겁게 일하고 있고, 또 어떤 사람은 여전히 취미로 오픈 소스를 즐기며 산다. 이 인터뷰집은 그 사람들의 이야기 ‘일부’를 다룬 것이다.
--
src : https://www.hackerslab.org/wp-content/uploads/2016/04/oops1-620x466.jpg
5년 만에 뵙습니다. 그간 어떻게 지내셨나요?
일단은 다니던 직장을 그만두고 이직을 했습니다. 전 직장에서는 설계, 튜닝 등 기술적인 업무를 했는데 지금은 매니저 업무를 더 많이 하고 있고요. 회의에 치여 살고 있습니다(웃음).
이직 후 달라진 점이 있다면.
게임 회사에서 전자 상거래 업체로 이동하면서 시행착오를 겪었습니다. 특히나 갑자기 급성장하는 분야의 시스템 운영 방식은 많이 다릅니다. 게임 서비스에서 전자 상거래 특히, 경쟁이 치열한 상태의 소셜 커머스로 오니까 대부분의 요구 사항이 거의 실시간성으로 오게 되더군요. 예를 들어 부하를 낮추려고 가장 많이 쓰는 방법이 캐싱입니다. 데이터베이스에서 가져올 걸 메모리에 캐싱을 한다든지, 중간이나 앞단에 캐시 서버나 큐(queue) 서버 비슷한 역할을 하는 걸 두어서 처리한다든지 하는데 거의 전쟁과 비슷한 상태의 경쟁을 하는 현재의 소셜 커머스 상황에서는 캐싱이나 큐로 처리할 수 없는 것이 많더군요. 경쟁이 치열한 분야이다 보니 실시간성에 대한 요구가 강합니다. 이는 기술적인 문제가 아니라 사업을 진행하는 측의 요구 사항이 강하다는 것입니다. 그런 요구 사항이 잘못된 것은 아니고 거기에 적응하는 데 시간이 좀 걸린 것 같습니다. 그리고 한정된 자원 내에서 튜닝을 열심히 해야 했는데요(웃음). 그래서 전 직장에서 일할 때보다 많은 생각을 하게 됩니다. 시스템 설계적으로 뒷단은 바꿀 수 없고 앞단에서 뭔가 할 수 없을까 궁리하다 보니 나름대로 상상을 많이 하게 되고 그러면서 아이디어가 많이 떠오르기도 하고요. 일은 힘이 들기도 하지만 예전 왕성할 때의 느낌이 되살아나는 것 같습니다.
안녕 리눅스 2.0이 나오고 2013년 안녕 리눅스 10주년을 맞이했는데 소감이 어떠신가요?
10년 지난 걸 몰랐습니다. 시작한 날짜를 잊고 있었는데 위키백과의 안녕 리눅스 항목을 보니 10년이 지났더군요. 정말 정신없이 지나간 것 같고 어떻게 보면 2.0이 더 빨리 나왔어야 했는데 나오지 않았던 것은 먹고사는 데 치열했던 때문인 것 같습니다. 2.0이 많이 지연되기는 했지만 약속은 지켰구나 하는 성취감은 있습니다.
안녕 리눅스 홈페이지를 보면 현재 회사에서 사용 중인 것으로 나와 있는데 반대 같은 것은 없었나요?
예. 없었습니다. 대부분의 사람들이 안녕 리눅스가 하늘에서 뚝 떨어진 배포본이라고 보거나 센트OS와의 차이를 모르거나 하는 두 가지 시선이 있습니다. 안녕 1의 경우에는 레드햇 탈피라는 슬로건이 있어서 전자의 시선과 비슷하지만, 2.0의 경우에는 전후자 모두 틀리다고 보아야죠. 그냥 운영에 필요한 것들을 센트OS에 추가한 배포본이라고 생각하면 됩니다. 회사에서는 안녕 리눅스를 말할 때 센트OS 커스텀 배포판(customized distribution)이라고 설명을 합니다. 그게 가장 이해시키기 좋거든요. ‘센트OS 6에 운영에 필요한 것들을 패키지화해서 묶어놓은 것’이라고 말이죠. 실제로 안녕 2에서는 커널과 glibc와 주요 라이브러리는 건드리지 않기 때문에 센트OS 6라고 해도 무방하기는 합니다.
안녕 2.0을 준비할 당시 VPN 용도로 계획하셨다고 했는데 그 계획은 미뤄진 상태인가요?
그 계획도 없지는 않습니다. 일단 기본적으로 VPN 장비용으로 만들 계획은 있는데 안녕 1 때와 비슷하게 회사에서 사용하지 않는 영역은 조금 늦어지는 것 같습니다. 마일스톤이 없어지지는 않았습니다. 생각은 하고 있는데 안녕 리눅스를 회사 업무 쪽에서 쓰다 보니 업무와 관련된 것들이 좀 더 빨리 반영될 수밖에 없는 것이죠. VPN과 관련하여 준비하고 있는 것이 있긴 합니다. 보통 VPN 장비들이 서버-클라이언트 구조가 아니라 포인트 투 포인트(point-to-point) 구조로 연결하는 경우에는 IPsec을 주로 사용하게 되는데, 이 IPsec이 설정하기가 어렵고 복잡해서 일반인이 접근하기 쉽지 않습니다. 인증서도 만들고 용어도 알아야 하고요. 제가 생각하는 건 그런 것보다는 라우팅 데몬을 설정하기 편하게 만들어서 서버-클라이언트 구조의 오픈VPN을 양쪽으로 로그인시켜서 실질적으로 포인트 투 포인트 방식은 아니지만 라우터 데몬을 이용해 라우팅을 해서 양방향 통신이 가능하도록 하는 것입니다. 지사 같은 사무실을 그렇게 묶어보면 어떨까 구상 중인데 천천히 진행하려고 합니다.
2.0 개발 과정은 어땠나요?
전 직장에서 일할 당시 안녕 2.0이 출시되기 전이었는데 업무를 위해 수정해 사용하던 기능들이 이미 있었고 그것들이 안녕 2.0에 반영됐다고 볼 수 있습니다. 당시 안녕 1.x대에서 센트OS 5 기반으로 수정한 기능들을 반영해 운영했고 센트OS 6가 나온 다음에는 6에 맞춰 반영해 사용해 왔습니다. 실제로 내부적으로 업무에 활용하던 것은 리눅스 커널 2.6으로 바뀌는 등 발전이 있었는데 외부에 배포된 게 리눅스 커널 2.4 기반의 안녕 1.x에 머무르고 있었던 거죠. 다만 자체 빌드한 커널과 설치 프로그램을 제공할 것인지 결정하지 못해서 오랫동안 배포판으로 나오지 못하다가 그 부분을 과감히 포기하고 안녕 2.0을 낼 수 있게 됐습니다. 문서 작성이 부족해서 발표가 약간 더 늦어진 면도 있습니다.
설치 프로그램을 제공하지 않는 데 대한 반응은 어떤가요?
요즘 가장 많이 듣는 질문이 DAG나 RPM 포지, EPEL과 뭐가 다르냐는 것입니다. distrowatch.com 이란 사이트에서 안녕 2.0은 설치 프로그램이 제공되지 않아서 배포판에서 제외된 상태가 되었고요. DAG나 RPM 포지, EPEL 같은 외부 저장소는 배포판에서 지원하지 않는 패키지들을 관리하는 데 반해 안녕 리눅스는 배포판에 포함되어 있는 시스템 패키지들에 수정을 가했습니다. 그런 부분에서 다르고 그 외에 좀 더 사용하기 편한 부분을 반영했고요. 그래서 저는 아직도 배포판이라고 생각합니다(웃음).
커널 변경을 하지 않는 것과 설치 프로그램 제외가 큰 변화였군요.
예전에는 1인 배포판이다 보니 그 점이 가장 힘들었습니다. 커널 업데이트 같은 경우는 평균 한 달에 한 번, 많이 나올때는 2주에 한 번 정도 나오는데 그걸 일일이 컴파일해서 쫓아가기가 쉽지 않았습니다.
리눅스 기반 개발자들에게는 재앙과 같겠군요.
일단 요즘은 커널 업데이트가 메이저 버전 번호가 바뀌어도 메이저 업데이트는 아니어서 실제로 그렇게 빨리 쫓아갈 필요가 있을까 하는 생각도 하고 있습니다. 그래서 배포판에서 제공하는 대로 쫓아가도 크게 무리가 없으리라 봅니다. 또한, 레드햇의 커널을 풀어보면 최신판에서 백포팅된 기능이 많고, 또 바닐라 커널에 포함되지 않은 기능들도 추가되어 있습니다. 그러므로 배포본의 커널을 버전만 보고 구식 커널이라고 치부하는 것은 좋지 않다고 생각합니다. 그리고 최근에는 임베디드 쪽이 강화되고 있고 백엔드 서버 관련 기능 변화는 크게 느끼지 못하는 것 같습니다. 오히려 커널보다는 하드웨어적인 부분, 특히 디스크 쪽이 문제입니다. 예를 들어 퓨전IO 같은 PCI 익스프레스용 SSD 장치를 설치했는데도 불구하고 I/O 부하가 걸렸을 경우 어떻게 대처해야 할지 고민해야 하는 상황이 더 문제인 것 같습니다. 메모리나 CPU의 경우에는 충분히 빨라진 것 같은데, 저장 매체들은 메모리나 CPU의 발전에 비해 너무 차이가 많이 나고 있으니까요.
회사에서 도입된 이후에도 1인 프로젝트 상태인가요?
예. 1인 프로젝트입니다. 일단 회사에서 쓰고 있으니 회사의 비공식적 도움을 받고 있다고 볼 수 있습니다. 그래도 웬만해서는 안녕 리눅스 작업은 혹시나 회사와 충돌을 할까봐 근무 시간 외에 합니다(웃음). 다만 회사나 다른 개발자들로부터 뭔가 요청이 있을 때만 낮에 작업을 합니다. 회사에서 요청받은 걸 배포판에 반영을 해 주는 일이니까요. 그래서 실시간성 업데이트는 못하는 편이고 월 1~2회 정도 몰아서 작업하고 있습니다. 시스템 운영하는 데도 매번 재시동을 못하거든요. 매월 정기 점검하는 형태라서 그런 방식으로 일하고 있습니다.
개인 프로젝트가 회사와 비공식적으로 연결되었는데 달라진 점은 무엇인가요?
개인적인 관점에서는 크게 달라진 점은 없는 것 같습니다만, 아무래도 안녕 3은 안녕 2처럼 개발이 지체되지는 않을 것 같습니다. 아무래도 회사에서 사용하기 위해서라도 개발을 하게 될 테니까요(웃음). 다만, 외부적으로는 안녕 1.x~2.x 개발 기간이 느슨해지면서 사용자층이 많이 줄어든 것으로 보입니다. 오히려 안녕에 반영된 패치들, 예를 들어 PHP의 safe_mode_exec 패치나 GeoIP 커널 모듈 같은 것들을 다른 배포판에서 쓰고 싶은데 어떻게 하면 되느냐는 문의가 늘어났습니다. 그것도 나름 의미가 있다고 생각합니다. 안녕 리눅스에서 지원해서 사용자들이 찾게 된 것이니까요.
별다른 피드백이 없나요?
그런 편입니다. 저와 제 오픈 소스 작업을 긍정적으로 보는 분들은 안녕 리눅스에 대해 호의적인데, 나름대로 경력이나 실력이 단단하게 쌓인 분들은 안녕 리눅스에 큰 관심이 없는 것 같다는 느낌이 듭니다. 어찌 됐든 기술적으로 뛰어난 배포판이 아니라 사용하기 편리한 배포판을 목적으로 하고 있어서 제가 생각하는 대상 사용자층은 이미 잘하는 개발자들이라기보다는 그렇지 않은 사람들인 것 같습니다. 사실 안녕 리눅스를 처음 시작할 때도 많이 사용되기를 바라고 만들지는 않았거든요(웃음). 현재 상태에 만족하고요. 업무상 시스템을 구축할 때 안녕 리눅스에 필요한 것이 다 준비되어 있으니 일을 빠르게 진행할 수 있으니까요. 제 포트폴리오라고 생각합니다. 아마 제가 일을 계속하는 한 안녕 리눅스도 계속 업데이트될 것 같습니다. 앞으로 10년 더 일하면 20주년을 기념할 수 있지 않을까 생각합니다(웃음).
최근 몇 년간 인프라 부문에서 많은 변화가 있었는데요. 그런 변화들을 겪으면서 느끼신 것은 무엇인가요?
일단은, 경영진에서도 인프라에 대한 인식이 조금은 생긴 것 같습니다. 클라우드나 빅 데이터가 신문지면에 오르내리기 시작하면서 인프라나 개발이 아닌 경영진에서 우리도 이런 걸 해야 하지 않느냐는 문의를 받기 시작했으니까요(웃음). 하지만 그렇다고 해서 이것이 긍정적이지는 않습니다. 이에 대한 판단이 없이 유행처럼 남들 다 하니까 우리도 해야 한다는 식으로 지시가 내려오는 경우가 많습니다. 또한, 실무진에서도 성과를 위해서 맹목적으로 도입하려는 시도들을 주변에서 많이 볼 수 있었는데 이런 부분도 문제라고 봅니다. 예를 들어 클라우드와 빅 데이터가 가장 대표적인데요. 퍼블릭 클라우드의 경우에는, IDC나 호스팅으로 운영하던 서비스를 퍼블릭 클라우드로 이전하는 경우가 있는데, 일정 규모 이상의 서비스가 되거나 또는 소셜 커머스처럼 개인 정보가 이슈가 되는 서비스들은 퍼블릭 클라우드에서 서비스를 하다가는 망 관련 법 및 개인 정보 보호법과 관련하여 법적 문제와 함께 과징금 대상이 되기 십상입니다. 클라우드에 대해 굉장히 비관적으로 말을 했는데, 반대로 스타트업 회사에서 용도를 잘 판단해 사용하면 굉장히 합리적인 시스템이기는 합니다. 제가 하고픈 말은 클라우드나 빅 데이터 등의 기술이 좋다 나쁘다가 아니라 어떻게 사용할 것인지에 대한 고민이 없이 기술적 유행에 따라하려고 하는 문화는 경계해야 할 것으로 보입니다. 프라이빗 클라우드나 빅 데이터에 대해서도 하고 싶은 말은, 신기술들을 우리 서비스에 어떻게 적용할 것인지에 대한 고민과 판단을 잘 해야 한다는 것입니다.
손으로 일일이 시스템을 구축하던 시절은 오래 전에 지났는데 오늘날 시스템 구축, 운영에서 어려운 부분은 무엇인가요?
단순히 운영 체제를 설치하는 것은 이제 그리 어려운 일은 아닙니다. 오히려 설치를 한 후에 커스터마이즈한 환경을 어떻게 관리할 수 있게 하느냐가 더 관심이 가는 부분입니다. 요즘은 퍼핏이나 셰프 같은 인프라 자동화 도구들이 많이 나오기는 했는데, 저 같은 경우에는 이 도구들이 제 가려운 부분까지 커버하지 못해서 이런 도구들이 제대로 개발되기 전부터 개인적으로 만들어서 사용하고 있습니다. 또한 저는 완전 자동화보다는 사람이 확인하고 허가한 작업만 자동 처리되는 반자동화를 추구하는 입장이라서, 저와 다른 견해를 만날 경우 협의가 쉽지 않은 것 같습니다. 즉 기술적인 문제보다는 사람 간의 의사소통이 이제는 더 어려운 것 같습니다. 그 외에 기술적인 관점에서 호기심은 아마존 같은 퍼블릭 클라우드 서비스입니다. 스토리지를 어떻게 운영하는지, 네트워크에 문제가 생겼을 때 어떻게 우회하는지 이런 기술적인 부분들은 대부분 저도 아는 기술을 사용하겠지만, 운영적인 노하우는 기발한 것이 있지 않을까 기대되기도 합니다. 솔직히 이런 시스템은 만져볼 수 없으니까 알 수가 없는 것이죠. 다 없애버리고 새로 만들면 기회가 있을지도 모르는데 서비스가 이미 돌고 있는데 없애고 다시 할 수는 없거든요. 결국 일부만 손댈 수밖에 없는데 그렇게 되면 전체 설계를 다 바꿀 수는 없고 만들다 마는 시스템이 될 가능성이 있습니다. 그래서 아마존에서 처음 클라우드를 구축했을 때는 과연 어떤 이슈들이 발생했을지 상당히 궁금했습니다.
지금까지 언급하신 업계 변화와 더불어 오픈 소스 활용 방식에서 달라진 점이 있다면.
오픈 소스에 대한 관점이 약간 바뀐 것 같습니다. 예전에는 오픈 소스를 가져다 써서 비용이 들지 않는다고 생각했습니다. 그런데 오픈 소스를 가져다 쓰면서 겪게 되는 문제는 인프라적 측면에서 볼 때 관리가 어려워진다는 점입니다. 예를 들어 모니터링 솔루션을 쓰는데 어느 솔루션도 만족하지 못해서 필요한 기능이 있는 솔루션들을 다 설치하게 됩니다. 그러다 보니 솔루션을 열 개 쓰게 됐다면 서버 한 대가 들어올 때마다 모니터링 솔루션을 열 개씩 등록해야 하고 이런 식으로 점점 늘어나면 운영 부담이 됩니다. 서버 한 대가 들어올 때마다 ‘삽질’을 해야 하니까요. 개발도 마찬가지인데 코드를 얼마나 검증할 수 있느냐, 또는 코드를 커스터마이즈했을 경우 버전 업데이트를 얼마나 쫓아갈 수 있느냐 같은 문제가 있습니다. 결국 오픈 소스는 비용이 들지 않는 게 아니라 개발 기간을 줄인다거나 비용을 줄이는 방편으로 사용해야 합니다. 예를 들어 어떤 데몬을 만들어야 하는데 소켓부터 다 만드느니 소켓 부분은 nginx 같은 서버의 것을 그대로 이용하고 중간에서 훅을 한 후 필요한 코드를 보충하는 거죠. 그러면 별도의 데몬이 만들어집니다. 데몬을 바닥부터 만들어야 한다면 3~4개월이 걸릴 텐데 이렇게 하면 1주일 정도에 끝나겠죠. 이런 식으로 활용하는 게 맞지 않을까 생각합니다. 기존 개발자들과는 다른 접근 방식이긴 하지만요.
회사에 고용된 리눅스 커널 개발자들처럼 전업으로 배포판을 개발해 보고 싶지는 않나요?
그럴 생각은 없습니다(웃음). 그러니까 자기만족인 것 같습니다. 또 다른 동기는 앞서 말씀드린 것처럼 제 기술 포트폴리오를 알리는 것이고요. 예를 들어 개발자가 가만히 있으면 아무도 알아주지 않듯이 오픈 소스 활동을 통해 저와 제 활동을 알리는 것이죠. 그런데 그것에 대해 큰 책임을 지기에는 부담스럽기도 합니다. 안녕 리눅스의 장점은 운영 노하우가 녹아들어 있다는 것입니다. 즉, 제가 지금 운영을 하고 있기 때문에 가능한 것인데, 전업으로 배포본을 지원할 경우에는 아무래도 이 부분이 많이 떨어질 수밖에 없다고 봅니다. 그러므로 오히려 한계에 부딪힐 수도 있으리라 봅니다. 그것만 바라봐야 하니까요. 제 경우에는 업무를 하고 있어서 다양한 상황을 만나고 그 경험 덕분에 안녕 리눅스 개발에 대한 아이디어도 떠오르고 안녕 리눅스에서 실험했던 걸 업무에 적용해 볼 수도 있는데 배포판 개발만 하게 되면 다른 걸 못 보게 될 것 같더군요. 그렇게 되면 결국에는 느슨해질 수밖에 없고요. 제 경력에도 좋지 않을 테고요(웃음).
10년 넘게 1인 프로젝트를 해오셨는데 그 의의를 정리한다면.
누가 쓰느냐 쓰지 않느냐는 그다지 중요하지 않다고 생각합니다. 그런 작업을 해서 배포했다는 것은 개인의 포트폴리오가 될 수 있다고 생각합니다. 운이 좋아서 저처럼 알려지게 된다면 ‘마케팅’이란 용어도 쓸 수 있을 것 같습니다. 그런데 그런 일을 하는 것 자체가 자신을 발전시킬 수 있는 굉장히 좋은 교재라고 생각합니다. 대부분 책을 한 번 보고 좀 해보고 넘어가죠. 그러고 나서는 또 잊어버리고요. 그런데 직접 뭔가를 하면 그게 자기 것이 됩니다. 안녕 리눅스가 제 마케팅일 수도 있지만 실제로 안녕 리눅스 개발을 하면서 공부한 것들을 다 제 것으로 익힌 거죠. 그게 가장 큰 것 같습니다. 개발자들이 회사에서 주어진 업무만 하다 보면 그 일만 하는 사람이 되기 쉽습니다. 그런데 뛰어난 개발자들은 기초부터 충실히 공부한 사람들이죠. 그런 면에서 볼 때 대강 눈으로 보고 넘기는 수준이 아니라 계속 실습하면서 익혀나갈 수밖에 없는데 뛰어난 개발자들은 그런 수련을 많이 해온 사람들이라는 거죠. 오픈 소스를 한다는 것은 그런 부분에 의의를 두는 게 맞는 것 같습니다. 오픈 소스를 만들었는데 아무도 쓰질 않아서 공개해 놓고 관리하지 않는 경우가 있습니다. 그런데 그걸 지속적으로 관리하면서 발전시키다 보면 거기에서 얻는 것이 굉장히 많다는 거죠. 그런 사실을 대부분 잘 모르고는, 배포했는데 아무도 안 쓴다고 동기를 잃는 게 안타까울 때가 있습니다. 제 경우에는 개발자는 아니지만 직접 만들어서 코드를 공개한 것이 꽤 있습니다. 우선은 공부를 하기 위해 코드를 만드는 것이고 코드를 공개해서 필요한 사람은 가져다 쓸 수 있게 하죠. 남이 쓰든 말든 신경 쓰지 말고 자기한테 필요한 게 있으면 만들어서 써보고 공개하다 보면 코드를 기여받기도 합니다. 예전에 mod_korean이라는 PHP 확장을 만든 적이 있습니다. 당시에 iconv에 문제가 있어서 iconv 없이도 쓸 수 있는 모듈을 만들었는데 성능이 제대로 나오지 않았습니다. 어떤 분이 코드를 기여해 주셨는데 기존 코드는 iconv와 비교하여 100배 이상의 성능 차이가 났었는데, iconv를 쓰지 않아도 성능 차이가 1.5배 정도로 줄어들었습니다. 제가 짰던 코드와 기여 받은 코드를 비교 분석해 보면서 제가 부족한 부분을 발견했고 성장할 수 있었습니다. 이런 식으로 발전해 나가는 게 중요하다고 봅니다.
배포판 작업을 하면서 개발 도구나 환경면에서 불만족스러운 부분이 있다면.
32비트 CPU가 없어졌으면 좋겠습니다. 두 번 빌드하기가 너무 힘들거든요(웃음). 도구 면에서는 크게 불편한 점은 없습니다. 나름대로 11년 정도 해 와서 불편하지 않게 개발 시스템을 만든 것 같고요. 레드햇처럼 자동 빌드 시스템은 아니지만요. 가장 아쉬운 점은 시간입니다. 다른 업무를 해야 하니까요. 레드햇 정오표(errata)나 보안 메일링 리스트를 보고 즉시 업데이트할 수도 있지만, 볼 시간이 없어서 상용 배포판 수준으로 업데이트는 어렵죠.
국내 보안 인증 같은 특화 기능에 대한 아이디어는 어떻게 얻으시나요?
제가 당하면서(?) 얻습니다. 외국에서는 전혀 쓸모없는 기능인데요. 원래는 일정 규모가 되면 보안 인증 심사를 받았어야 했는데 그게 없어지면서 ISMS(Information Security Management System) 인증으로 대체됐습니다. 관련 기관에서 나와서 도구를 돌리면 지적 사항들이 나오는 게 있습니다. 그런 것들을 다 반영해 버리면 깔끔하게 해결되는데 문제는 운영 체제를 설치하고 직접 설정해야 한다는 것이죠. 그러면 귀찮거든요. 안녕 리눅스를 설치하면 그런 지적 사항들이 다 없어지는 거죠(웃음). 주로 제가 불편했던 것들을 많이 반영하는 편입니다. 예를 들어 콘솔에서 한글이 보이지 않는 것도, 안 보여도 솔직히 상관은 없지만 제가 불편해서 1.x에서는 커널에 패치를 했고 2.x에서는 jfbterm을 넣어서 한글을 쓸 수 있게 했습니다.
1인 프로젝트의 장단점을 꼽자면.
장점은 즉흥적으로 할 수 있다는 점입니다. 예를 들어 모든 걸 제가 컨트롤하고 있어서 고치고 싶은 게 있으면 바로 실행이 가능하다는 거죠. 협업을 하게 되면 서로 협의가 되어야 합니다. 제가 뭔가를 고쳤을 때 영향을 받는 부분이 있다면 다 같이 이야기하고 나서 확정한 다음 고치고 반영하는 과정이 필요하죠. 혼자서 하는 것의 단점은 역설적으로 모든 걸 다 할 수 없다는 점입니다. 예를 들어 위원회 같은 방식으로 지속적으로 할 수 있는 구조가 된다면 할 수 있는 일이 참 많습니다. 커널에서 고쳐보고 싶은 부분이나 기존 배포판에서 마음에 들지 않는 부분이 많은데 엄두가 나지 않는 일들은 못하는 거죠. 하고 싶은 게 있지만 포기하는 부분이 많습니다. 그게 1인 프로젝트의 단점입니다.
3.0에서 구상하는 것은 무엇인가요?
일단 크게 구상하는 것은 없습니다. VPN이나 방화벽 서버 전용 장비를 만들 수 있는 환경이 1차 마일스톤으로 잡혀 있습니다. 3.0이나 4.0은 2.x처럼 기반이 되는 배포판을 빨리 따라갈 수 있는 구조로 가려고 합니다. 지금 레드햇 엔터프라이즈 리눅스(이하 RHEL) 7이 어떻게 진행되고 있는지 동향을 보고 있다가 베타판이 나올 때쯤 작업에 들어가야겠죠. 출시되면 준비해 둔 것을 다 빌드해서 내놓을 수 있게 하려고 준비 중입니다. 그런데 결정하지 못한 게 하나 있습니다. 안녕 2.0은 RHEL 6.2이 나오기를 기다렸다가 내놓았습니다. 예전부터 레드햇은 x.0, x.1 버전은 쓰지 말라는 법칙(?)이 있었거든요. 그런데 요즘도 x.0, x.1이 쓰지 않는 게 좋은 버전인지는 확실히 모르겠습니다. 페도라라는 배포판 형태로 테스트를 거쳐 나오기 때문에 그 법칙이 아직도 유효한지는 판단을 다시 해봐야 할 것 같습니다. 3.0이 나온다면 RHEL 7.2에 맞출지, 7.0에 맞출지는 아직 고민하고 있습니다. 그리고 버전 번호를 3.0으로 할지, 7.0으로 할지도 생각 중입니다(웃음).
향후 배포판은 어떤 방향으로 발전해 가리라 보시나요?
리눅스 같은 경우에는 배포판이 산업별 또는 기기별로 나뉜 것 같습니다. 임베디드용, 서버용, 데스크톱용 배포판 판매사들로 나뉘는데 일단은 그 세 분야가 주가 되는 기조는 유지되리라고 보고 크게 변화가 있을 것 같지는 않습니다. 커널의 경우도 예전처럼 메이저 버전이 올라가면 확 바뀐다든지 하는 것도 없어져서 그런 걸 봐서는 급격한 변화는 단시일 내에 나타나지 않을 거라고 생각합니다. 예전에 안녕 리눅스를 방화벽 전용으로 구성해 놓고 싶다고 구상했던 게 틈새시장처럼 될 수는 있을 것 같습니다. 지금까지 제가 본 배포판들의 가장 큰 변화는 설치 프로그램의 발전인 것 같습니다. 좀 더 설치하기 쉽게 바뀐 것들이 가장 눈에 띕니다.
현재 업무와 관련해서 배포판 성능에는 만족하시나요?
일단은 하드웨어가 많이 발전했습니다. 예전에는 돈 있는 부서가 장비로 승부한다고 했는데 요즘은 튜닝을 통해 얻는 이득보다 실제로 여유가 된다면 장비 한 대를 추가해서 얻는 이득이 큰 것 같습니다. 그다음 서비스 수준에서는 커널이나 운영 체제 튜닝을 통해 얻는 이득보다 데이터베이스나 애플리케이션 로직 튜닝을 하는 게 효과가 훨씬 큽니다. 실제로 두세 배까지 효과를 볼 수 있거든요. 오히려 그쪽에 집중하는 게 더 이득이라고 봅니다. 물론 그걸 할 수 있는 엔지니어가 있을 때만요(웃음). 저도 시스템을 튜닝하기 이전에 애플리케이션을 튜닝하는 쪽을 더 고려합니다. 데이터베이스 질의 두 번 갈 걸 한 번만 가면 그만큼 데이터베이스 부하가 줄 테니까요. 물론 절대적이지는 않지만 대체로 시스템 튜닝보다 효과가 훨씬 큰 것 같습니다.
안녕 리눅스 외에 모질라 지역화 프로젝트에서도 활동하셨는데 지금도 참여 중인가요?
지금은 못하고 있습니다. 전 직장 다닐 때 참여하다가 회사의 어떤 프로젝트에 투입되면서 시간이 없었습니다.
어떤 계기로 참여하게 됐나요?
썬더버드를 이메일 프로그램으로 쓰다가 번역이 좋지 않았고 번역되어 있지 않은 부분도 많았습니다. 그래서 썬더버드 번역을 고쳐서 몇 번 제출했는데 직접 해야 하는 상황이 됐습니다. 윤석찬 씨가 저를 썬더버드 한국어 번역 담당자로 등록해 주셔서 CVS 권한을 받았는데 그 다음 버전에서 썬더버드와 파이어폭스 언어 팩이 통합됐습니다. 그러다 보니 양쪽을 다 같이 하게 됐습니다. 오래돼서 잘 기억나지는 않는데 2.0 아니면 3.0 번역 작업을 제가 약 70%를 한 것 같습니다.
국제화가 잘된 소프트웨어라고 해도 정작 번역 인프라는 부실한 경우가 있다고 하는데 당시 모질라는 어땠나요?
힘들었습니다. 특히 애플리케이션 같은 경우에는 문장이 완성되지 않는 경우가 많습니다. 그리고 인자(argument)가 들어가는 문장의 경우 사용자 인터페이스를 보고 번역해야 하고요. 언어 팩만 보고 번역하기는 어렵습니다. 번역 소프트웨어로 번역한 것 같은 문장이 나오죠. 한국어 조사 처리도 애매하죠. 처음에는 ‘은(는), 을(를)’ 식으로 처리했는데 지적이 들어오더군요. 가장 힘들었던 것은 번역에 대한 피드백은 좋지만 공격적으로 비판하는 경우였습니다. 번역을 아주 잘한 것은 아니었지만 나름대로 목표를 가지고 했다고 생각했으니까요. 소수의 악성 댓글 때문에 번역 전체가 문제가 있는 것으로 비쳐졌던 것 같습니다. 당시에는 악성 댓글에 익숙하지 않아서 ‘욱’하기도 했었죠. 지금은 그럴 것 같지는 않은데 이제는 번역 자체가 힘들더군요(웃음).
JS보드 개발은 어떻게 맡게 되셨나요?
원래는 메인테이너가 있지 않았습니다. 당시 linux.sarang.net 운영자였던 ‘적수’ 씨가 만들어서 공개한 게시판을 고쳐서 사용하던 사람들이 그 개선판을 다시 공개했습니다. 몇 번의 개선을 거쳐 방창현 씨가 0.5를 올리면서 ‘적수’ 씨로부터 라이선스를 양도받아서 오픈 소스 프로젝트로 개설했습니다. 그 후 저도 개선판을 보냈고 0.6이 나왔습니다. 그랬더니 방창현 씨가 저한테 프로젝트를 맡기고는 사라져 버리더군요(웃음). 저도 그 프로젝트를 이렇게 오래할 줄은 몰랐는데 JS보드를 제가 쓰다 보니까 계속 업데이트하고 그러면서 유지됐습니다. 초창기에는 제로보드와 사용률이 비슷했었던 것 같습니다. 그런데 결정적으로 차이가 나기 시작한 지점이 테마 또는 스킨을 제로보드는 지원했는데 JS보드는 제대로 지원하지 않으면서부터였습니다. JS보드 당시 방침 중 하나가 텍스트 브라우저에서도 보이게 하자는 것이었습니다. 그래서 스킨을 색만 변경할 수 있게 했습니다. 디자인이 들어가기 시작하면 텍스트 브라우저에서 제대로 보이지 않을 수 있으니까요. 그런 방침 때문에 스킨을 잘 지원하지 않았습니다. 또 다른 결정타(?)는 답글(reply)만 지원하고 코멘트 형식의 댓글을 지원하지 않은 것과 블로그가 나왔을 때 대응하지 않은 것이었습니다. 블로그로 변신할 필요는 없었는데 그즈음에 게시판들에 갤러리 같은 변신 모드 기능이 지원되기 시작했습니다. 그런 기능들을 지원하지 않으면서 인기를 잃었습니다. 2005년부터 저를 대신할 메인테이너를 찾았는데 권한을 주어도 실제로 하는 사람은 없더군요. 그래서 지금도 제가 보안 버그 패치 등 유지 보수를 계속하고 있습니다. 요즘 가끔씩 UTF-8 지원 문의가 들어오는데 그건 시간이 나면 하려고 생각 중입니다. 안녕 2.0을 내놓으면서 제 사이트는 UTF-8로 바꾸었는데 여유가 생기면 메인 소스 트리에도 반영하려고 합니다. 사실 올해 초 목표였는데 그동안 웹 공부를 너무 하지 않은 것 같아서 HTML5와 jQuery 등을 살펴보고 있습니다. 족보 시스템을 2000년 초에 JS보드의 1번 글의 답글 트리를 이용해 만들어서 쓰고 있었는데, 이번에 트리 구조를 제대로 만들고 사용자 인터페이스도 바꿔 보려고 하면서 다시 공부하고 있습니다. 제가 맡고 있는 것들에 대해서는 마일스톤은 조금씩 있는데 역량이 그것들을 다 해낼 정도가 되지 않아서 유지 상태로 가고 있는 것 같습니다.
질답 게시판을 15년 넘게 유지하시는데 스트레스는 없었나요?
‘HOWTO For Beginners’란 문서를 쓰기 전 시기가 스트레스의 절정기였던 것 같습니다(웃음). 이메일이나 게시판으로 욕을 하는 사용자도 있었죠. 그래서 질답을 운영하지 않을 때도 있었는데 그 문서를 쓰고 나중에 세 번째로 개정하고 나서는 질답에 대한 문제는 없었습니다. 그리고 안녕 리눅스에 치중하면서 홈페이지에 올린 강좌들이 오래된 문서가 됐는데요. 그런 다음부터는 홈페이지 방문 수가 줄기도 했고요. 요즘에는 60%는 검색 봇이 왔다 가는 느낌입니다. 질답이 자연스럽게 다른 사이트들로 간 것 같고 안녕 리눅스 관련 질문이 조금씩 올라옵니다. 그래서 그런지 요즘에는 거의 부담은 없습니다.
오늘날 오픈 소스 소프트웨어의 학습 장벽은 어느 정도라고 보시나요?
개인차가 있을 것 같습니다. 단순히 활용하는 거라면 설치·관리 프로그램이 워낙 잘되어 있는 것들이 많아서 프로그래밍을 못하는 사람도 설치해서 쓰죠. 관련 문서도 많아서 장벽은 예전보다 낮아졌다고 봅니다. 그런데 모니터링 도구라면 그 자체보다는 모니터링을 하기 위한 지식이 필요한데 그건 오픈 소스 문제라기보다는 그걸 사용하는 사람의 능력치 문제 같습니다. 반대로 오픈 소스를 개발하는 사람의 입장에서는 진입 장벽이 높아진 것 같습니다. 사용자들의 눈높이가 높아졌는데 개발하는 사람의 능력에 따라 품질이 달라지니까요.
피터 노빅이 「Teach Yourself Programming in 10 Years」란 글을 발표한 적이 있습니다. 숙련된 오픈 소스 엔지니어가 되는 데 시간이 어느 정도 걸릴까요?
제가 일하는 분야는 일정하지 않은 것 같습니다. 시스템 엔지니어링 쪽은 명확한 커리큘럼이 없습니다. 제 생각에는 한국의 경우 학문적으로 뭔가 이뤄지는 경우는 없는 것 같습니다. 저도 마찬가지지만 시스템 엔지니어링 일을 하면서 학문적으로 접근했다기보다는 경험을 바탕으로 접근한 세대죠. 저를 비롯해 대부분 그렇지 않을까 생각합니다. 그러다 보니 개인차가 큰 것 같습니다. 실력이 좋은 사람들은 정말 열심히 하고 관심도 많아서 3~4년 일하면 일정 수준에 올라섭니다. 그런데 그렇지 않은 사람들은 10~15년을 일해도 별 발전이 없죠. 지금까지는 커리큘럼을 따라오지 않았기 때문에 연차 같은 걸로 측정하기는 어려운 것 같습니다. 10년 경력이라도 자기가 볼 수 있는 시야가 한정되어 있으면 그 안에서만 10년이 지나가는 것이거든요. 누군가 옆에서 도와주는 사람이 있다면 10년이 안 되더라도 깊게 접근할 수 있는 거죠. 똑같은 10년차를 놓고 봤을 때 자신의 시야 바깥의 것을 경험해 볼 수 있었느냐 아니냐의 차이가 큰 것 같습니다. 그리고 본인이 스스로 찾아서 할 정도의 의지가 있느냐 없느냐의 차이도 큰 것 같고요. 그래서 인력 배양에 대한 생각을 해보고 있는데요. 사람이 너무 없습니다. 예전에는 리눅스 TCO 같은 걸로 시장성이 있느냐가 논쟁이었다면, 요즘은 사람을 못 구해서 시장이 없어질 것 같은 느낌이 들 때가 있습니다. 어찌 됐든 제가 살아남으려면 경쟁 상대가 너무 많아도 좋지 않겠지만 너무 없는 것도 문제가 되겠더군요. 사람이 어느 정도 있어야 유지되니까 요즘은 사람을 키워야겠다는 생각도 조금씩 하고 있습니다. 그룹을 만들어 보는 것도 시도해 보고 있습니다. 현재 생각하는 것 중 한 가지는, 짧게 보고 있지는 않고 10년 이상 보고 있는데, 비전공자 같은 생초보자를 데려다놓고 1년 정도 교육을 시켜서 업무에 투입해 최소한의 관리자 역할을 할 수 있는 수준으로 키우는 커리큘럼을 만들려고 하고 있습니다. 그걸 만들어서 잘 되면 그 다음 번에 그 사람들의 실력을 더 높일 수 있는 커리큘럼을 만들고요. 6개월 안에 초급부터 고급을 다 배우는 과정을 본 적이 있는데 과연 뭐가 될 수 있을까 하는 의문이 들었습니다. 생초보는 1년간 배워도 현업에 투입되기가 쉽지 않거든요. 그런 문제를 탈피할 수 있는 구조가 필요하지 않을까 생각합니다. 그게 우선인 것 같습니다. 뭐가 부족한지 알 수 있는 수준이 되면 물어볼 수 있는데 그게 되지 않으면 문제가 생겨도 멍하니 있게 됩니다. 그래서 인력 배양 쪽도 생각하고 있습니다.
엔지니어 노령화를 실감하시나요?
그렇죠. 구인을 해보면 이력서가 거의 들어오지 않습니다. 개발 쪽은 그나마 나은데 시스템 엔지니어링 쪽은 이력서가 잘 들어오지 않습니다. 전 직장에서도 그랬고요.
예전에는 시스템 엔지니어링 하면 상용 제품 운영 능력을 떠올리고는 했는데 요즘은 말씀하신 것처럼 오픈 소스 공부를 해서 더 나은 수준으로 올라갈 수도 있을 것 같습니다.
그런 측면에서 오픈 소스 예찬론자입니다. 제가 필요한 걸 오픈 소스로 만들어 놓으면 회사를 옮겨도 계속해서 활용하고 개선할 수 있습니다. 이런 식으로 오픈 소스 작업을 해서 얻는 혜택 중 제일 대표적인 것은 경력 관리를 할 수 있다는 점입니다. 이력서를 잘 꾸미는 건 별 필요가 없습니다. 개발해온 오픈 소스 소프트웨어가 있으면 경력 관리가 편합니다. 포트폴리오가 뭐가 있느냐는 질문을 받았을 때 그동안 개발해온 오픈 소스 소프트웨어를 보여주면 됩니다. 그냥 URL만 알려주면 코드를 다 볼 수 있는 거죠. 그러면 그 코드를 보고 판단할 수 있겠죠. 구인이 아니더라도 개발자가 뭔가를 검색하다 관심이 생겨 코드를 보고 괜찮다는 느낌을 받으면 잘한다는 평판이 생깁니다. 그것 자체가 경력 관 리라는 거죠. 그리고 그걸 잘 홍보하면 좋을 테고요. 그런데 코드 하나 공개하고 끝낸다면 오히려 역효과입니다. 시간이 갈수록 코드가 구식이 되거든요. 그러면 나중에 누군가 그 옛날 코드를 봤을 때 좋지 않은 평판이 쌓이겠죠. 그래서 오픈 소스 소프트웨어는 꾸준히 관리해야 합니다. 올려놓고 끝내려면 차라리 내려버리는 게 나을 겁니다. 제가 오픈 소스 작업을 하지 않고 회사 일만 했다면 실제 지금의 제 모습과는 많이 차이가 났으리라 생각합니다. 현재 수준의 3분의 1 정도밖에 되지 않았을 것 같습니다. 그런 면에서 저는 오픈 소스 개발 작업을 하는 것을 적극 권장합니다. 제 소스 코드 저장소에 3~40가지 소프트웨어가 공개되어 있는데요. 주로 저 혼자 쓰고 다른 사용자들은 많이 쓰지는 않지만 일단 제가 잘 사용하고 있고 필요한 사람들이 질문을 하면 답변을 하는 일들이 다 경력 관리가 될 수 있다고 봅니다. 많이 쓰이든 쓰이지 않든 상관은 없고 일단 공개되어 관리되는 코드가 있다면 그것 자체가 포트폴리오가 될 수 있습니다. 그것처럼 좋은 건 없다고 봅니다. 요즘에는 오픈 소스에 대한 인식이 좋아졌습니다. 예전에는 오픈 소스로 내놓으면 “그걸 팔지, 왜 오픈 소스로 내놓느냐”라고 하는 개발자들도 있었는데 요즘에는 오픈 소스로 내놓는 것이 당연한 것처럼 여겨지죠. 기업에서도 개발자들을 뽑을 때 오픈 소스 활동을 한 사람들에게 혜택을 줍니다. 일단 그 코드를 검증해 볼 수 있으니까요. 프로젝트 코드라고 포트폴리오를 제출했는데 실제로 그 사람이 짠 것인지, 아닌지 알 수가 없습니다. 그런데 오픈 소스는 간단합니다. 1인 오픈 소스면 그 사람이 다 짠 것일 테니 코드를 보면 그 사람 수준을 알 수 있죠. 제 생각에는 할 수 있으면 하는 게 좋다고 봅니다.
최근 관심을 끄는 DevOps라는 흐름을 넓게 보면 오픈 소스 기반 서비스 개발 및 운영이 보편화하는 것과 연관이 큰 것 같은데 국내 환경에는 어떤 시사점을 줄까요?
일단 오픈 소스 개발과 DevOps는 큰 상관관계는 없는 것 같습니다. 하지만 오픈 소스 활용률이 높아지다 보니, 해당 오픈 소스를 잘 활용할 수 있는 사람이 개발에 붙어 주었을 경우 효율을 높일 수 있을 것 같다는 생각은 합니다. 그리고 외국에서는 회사의 업무에 DevOps를 반영하는 시도가 보이는 것 같습니다. DevOps를 간단하게 정의해 보자면, 크게 개발·운영·기획·QA 등의 조직으로 나뉘어 있는 것을 서비스 단위로 쪼개어 각 단위에서 개발·운영·기획·QA를 다 가지고 있자는 의미 같습니다. 물론 제가 빙산의 일각만 봐서 그렇게 보일지는 모르겠지만요. 하지만 일단 제가 DevOps를 바라보고 제 주위에 적용하려고 하는 시선에서는 그렇게 보입니다. 예전에 넥슨의 게임들이 이런 구조였던 것으로 기억합니다. 이 시점으로 논의를 해 보자면, 스타트업이나 단일 서비스 구조로 된 회사들은 괜찮은 방법론이라고 생각합니다. 스타트업들은 대부분 운영자를 두지 않고 개발자가 운영까지 다 한다는 점에서 이미 DevOps를 수행하고 있다고 할 수 있을 것 같습니다. DevOps라는 용어가 없었지, 이미 예전부터 실행은 하고 있었다고 할 수 있는 것이죠. 하지만 국내의 경우에는 서비스가 커지거나 회사가 커져서 증원이 많이 되기 시작하면 비용 문제와 만나게 됩니다. 국내의 경우 CDN이나 캐시 서비스, IDC/네트워크 서비스, 문자 발송 서비스 같이 비용이 많이 발생하는 서비스 요금들은 외국과는 달리 정찰제가 아니라 사용량에 따른 가격 협상이 가능합니다. 즉, 이렇게 단위별로 쪼개어 각각 계약을 하는 것과 한 부서가 이를 관리하는 것은 엄청난 비용 차이가 발생하게 됩니다. 또한 맨/먼스(man/month)적으로도 단위별로 맨/먼스를 가지고 있으면 인력 낭비가 발생한다는 시각을 가지게 되는 경우가 많습니다. 그런 측면에서 스타트업이 아니거나 정말 비용을 따지지 않고 품질을 우선시하는 환경이 아니라면 DevOps는 실무자들을 더 괴롭게 할 수도 있다고 생각합니다. 오히려 국내 환경에서는 DevOps는 악용할 소지가 더 많을 것 같다는 판단이 들기는 합니다. 다만 아까 앞서 유행에 민감하다는 언급을 한 적이 있는데, 정말 비용을 들여서 더 많은 수익을 올릴 수 있는 구조라면 이런 구조가 오히려 효율적일 것이라는 것에 대해서는 동의할 수밖에 없습니다. 다만 이걸 누가 어떻게 설득을 해야 하는지가 문제인 것이죠.
충분한 여가 시간이 주어진다면 해결하고 싶은 프로젝트는 무엇인가요?
제 홈페이지 개편입니다(웃음). 안녕 리눅스 홈페이지 문서들도 아직 1.x로 되어 있어서 정말 시간이 있다면 오픈 소스 프로젝트를 더 한다기보다는 제가 만들어놓은 것들에 대한 문서 작업을 해야 할 필요성을 느낍니다. 심심해서가 아니라 업무에 쓰려고 만든 것들이라서 대중화할 수 있는 게 필요하지 않나 생각합니다. 이미 많이 만든 것 같고요. 요즘 iptables에 GeoIP를 연동해서 쓰는 편인데, 그걸 좀 더 확장해서 웹단에서 좀 더 편하게 쓸 수 있는 방법을 만들어 놓은 게 있습니다. 그런 것들에 대한 문서 작업이 좀 더 필요한 것 같습니다. 필요해서 만들어 업무에 쓰고 있기 때문에 장점이 있는데 잘 홍보하지 않아서 알려지지 않았죠. 문서 작업을 통해 알리는 게 필요하지 않나 싶은데, 굳이 더 알릴 필요가 있을까 하는 생각도 한편으로는 듭니다. 또 한 가지가 있다면 그동안 만든 패치들을 업스트림에 올리고 싶습니다. 지금까지 몇 번 시도해 봤는데 언어의 장벽에 부딪혀 잘 되지는 않았지만요. 그리고 여유가 생기면 아이와 함께 드럼을 배우고 싶다는 생각을 하기도 합니다.
비전공자로 시작하셨다고 했는데 이 일을 시작하는 사람들에게 해주고 싶은 조언이 있다면.
예전에는 비전공자는 IT 분야에 오지 않는 게 좋다고 이야기했는데요. 그때 생각이 크게 바뀌지는 않았지만 그래도 다른 분야에 비해 비전공자에게도 기회가 좀 더 있다고 봅니다. 물론 자신의 노력 여하에 달려 있겠지만요. 구인할 때 ‘전공/학위 우대’ 같은 문구가 들어가기는 하지만 앞서 말한 것처럼 경력이나 오픈 소스 개발 경험이 있으면 그런 게 큰 상관이 없습니다. 오히려 그런 부분에 대해서는 타 분야에 비해 이점이 있는 것 같습니다. 그리고 최소한 시스템 엔지니어링 분야에서는 전공 여부보다는 실무 가능 여부가 더 중요한 것 같습니다. 그래도 쉽지는 않은 것 같습니다. 대충 회사에 취직한다고 해서 업무를 할 수 있는 분야는 아니니까요. 접근이 쉬워 보일 수도 있지만 인력이 많지 않아서 일당백이 요구되고 잘하지 못하면 쉽게 도태되기도 하는 게 이 분야 같습니다. 그런 면에서는 장단점이 극명하죠. 대우를 못 받는 분야로 알려져 왔지만 그런 관행도 슬슬 깨지고 있는 것 같으니 정말 관심이 있다면 도전해 볼 만하다고 생각합니다.
노년에도 프로그래밍을 하는 모습을 상상해 보셨나요?
할 수 있을 때까지는 할 것 같습니다. 오픈 소스 개발이 이미 취미 생활화되어 있기도 하고요. 기력이 있을 때까지는 할 것 같습니다. 물론 은퇴하면 다른 취미 생활도 생길 테니 개발만 하지는 않겠지만 재미있으니까요(웃음).
인터뷰이 소개: 김정균
이직을 할 때, “인프라스트럭처 조직이 왜 필요해?”라는 말을 들은 적이 있다. 인프라 조직이 있는 회사들에서도 인프라 조직은 대부분 개발 조직에 종속적이거나 개발 조직을 지원하기 위한 조직이다. 이런 말을 듣고 오게 된 회사에서 이제는 “인프라 조직이 왜 필요한지 알겠습니다.”라는 말을 듣는다. 단순히 지원 조직이 아니라 비용과 기회를 창출하고 개발 조직에 기술을 제안하며 개발 조직과 동등한 위치로 올라서려면 아직도 갈 길이 멀다. 개발뿐 아니라 인프라에서도 재미있고 의미 있는 일을 할 수 있으며, 좋은 사람들과 훌륭한 인재들이 인프라를 지원하고 싶어 하고, 분야의 인재들이 충분히 대접을 받을 수 있는 세상을 만들고 싶다. 업무 외 시간에는 오픈 소스 프로젝트로 안녕 리눅스 배포판, JS보드 등을 개발하고 있고 모질라 지역화 프로젝트 등에 참여한 바 있다.
이희승 - 도전과 점진적 개선, 그리고 변화에 열린 마음
허태준 - 가장 의미 있고 즐거운 개발
