http://osdi.insightbook.co.kr/2013/10/24/06-cjh.html
널리 알려지지는 않았지만 그 전설 같던 시절이 지나고 이제는 누구나 오픈 소스라는 말을 어디선가 들어봤음직한 시대가 됐다. 오픈 소스로 뭔가를 할 수 있으리라 별로 기대하지도 않았고 리누스 토발즈 자서전 제목처럼 ‘그냥 재미로’ 오픈 소스를 다뤄온 사람들은 지금 무엇을 하고 있을까? 어떤 사람은 오픈 소스 개발이 생업이 되어 즐겁게 일하고 있고, 또 어떤 사람은 여전히 취미로 오픈 소스를 즐기며 산다. 이 인터뷰집은 그 사람들의 이야기 ‘일부’를 다룬 것이다.
--
src : https://wiki.kldp.org/wiki.php/KLDPInterview/%C3%D6%C1%D8%C8%A3?action=download&value=cjh.jpg
프로그래밍은 언제 어떻게 시작하셨나요?
거슬러 올라가면 초등학교 4학년 때 집에 8비트 컴퓨터가 생겼습니다. 당시 금성전자(현 LG전자)에서 나온 FC-150이란 모델이었습니다. 옛날 8비트 컴퓨터들은 대부분 베이직(BASIC) 언어가 돌아가서 베이직부터 시작한 거죠. 그런데 FC-150이란 게 당시 한국에서 굉장히 비주류여서 자료가 별로 없었습니다. 그러다 보니 그러다 보니 일정 시점 이후에는 베이직 언어에도 한계를 많이 느끼게 되었고 점점 기계어에도 손을 대는 방향으로 가지 않았나 합니다.
초등학교 때 이미 어셈블리를 쓰셨던 건가요?
예. 공부하는 게 만만치 않았는데 제 입장에서는 자료가 없으니까 조금 더 뭔가를 하고 싶으면 어셈블리를 쓸 수밖에 없을 것 같다는 느낌이 들었습니다. 1983년인가 84년인가 마이크로소프트웨어라는 잡지에 Z80 어셈블리를 지면에다 실은 적이 있었습니다. 그걸 가져다 놓고 열심히 봤었죠. 그런데 문제는 어셈블러가 없었다는 것이었는데요. 잡지를 보면 명령어가 있고 그 옆에 해당하는 16진수(hex) 코드가 적혀 있었습니다. 그때는 손으로 어셈블러를 대신했었죠.
그 시절을 겪어보지 않은 개발자들에게는 잘 상상이 가지 않는 장면 같습니다.
솔직히 당시에는 아무 생각이 없었습니다(웃음). 그러다가 6학년 때 MSX2가 생겼고 두 대를 병행해 쓰다가 나중에 XT가 생기고 대학 들어갈 때 486 한 대 구입하고 하는 식으로 컴퓨터가 바뀌었습니다.
당시에 같은 반에 컴퓨터를 쓰는 학생은 몇 명 정도였나요?
있어봐야 두세 명? 당시에는 워낙 비쌌으니까요. 굳이 컴퓨터를 배워야 할 이유도 없었고요. 같은 반에는 몇 명 없었던 것 같습니다.
베이직 쓰다가 할 게 없어서 어셈블리를 손대는 친구들이 또 있었나요?
보지 못했습니다. 대부분 컴퓨터가 있으면 보통 게임을 했으니까요. 게임을 하거나 베이직을 쓰거나 하는 정도밖에 못 본 것 같습니다. 제 경우는 FC-150이라는 기종이 한계가 많아서, 그러니까 자료가 많지 않았거든요. 예를 들면 시스템 내부에 대한 책을 구하기가 쉽지 않았습니다. 운 좋게 손에 넣은 책이 몇 권 있었는데 그걸 보면서 쓰다 보니 베이직에 없는 기능을 쓰는 방법을 생각하면서 어셈블리를 시작했던 거죠. 나중에 MSX로 넘어가면서도 비슷했죠. MSX에도 베이직과 어셈블리가 있었는데 그때는 MAD-80이라는 어셈블러가 있었습니다. 그걸 사용하니 훨씬 편했죠. 그전에는 공책에다 어셈블리를 쓰고 마이크로소프트웨어 잡지를 보면서 16진수 코드로 변환해 직접 입력했었거든요.
8비트 시절을 경험한 사람들 중에는 MSX에 대한 추억이 있는 사람들이 제법 있는데 어떤 점이 특별했나요?
1980년대 초중반에는 8비트 컴퓨터가 세 가지 분파, 애플 Ⅱ·MSX·삼성 SPC-1000이 있었습니다. 3파전 구도였는데 집에 8비트 컴퓨터가 있는 사람은 대략 셋 중 하나였으니까요. 저는 FC-150을 쓰다가 6학년 때 MSX2가 생겼는데 사실 그쪽은 상대적으로 자료가 많았습니다. 애플은 보통 아이들이 게임을 하니까 미국 게임들이 유명한 게 많았습니다. MSX는 일본 게임들이 유명한 게 많았죠. 게임으로 컴퓨터를 시작했다가 컴퓨터 내부에 슬슬 관심이 생기면 베이직으로 프로그램도 짜면서 게임도 만들어보고 싶은 생각이 계속 생기니까 그런 쪽으로 가는 거죠. 저는 MSX2를 6학년 때 받아서 거의 대학교 들어갈 때까지 썼습니다. 중 3 때 집에 XT가 생겼는데 당시에 MSX2와 XT를 비교하면 MSX가 더 나았습니다. MSX는 컬러에, FM 사운드도 되고, 게임 품질도 높았는데 XT는 흑백에, 사운드 카드가 없는 상태에서는 삑삑거리는 사운드여서 당시 제 입장에서는 콘텐츠가 MSX가 훨씬 나아서 대학 들어갈 때까지는 그걸 주로 썼던 것 같습니다. 거의 10년 쓰면서 이것저것 다 해봐서 추억이 굉장히 많습니다.
결국 당시에는 대체로 게임 내부가 궁금해 프로그래밍에 빠져들었던 셈인가요?
제 경우에는 어셈블리를 배워서 주로 했던 일이 게임을 해킹(?)해서 플레이어를 무적을 만든다거나 에너지나 남은 대수를 최대로 채운다거나 하는 것이었습니다. 그런 걸 하려면 일단 어셈블리에 대한 지식이 필요하고 게임이 돌아가는 순서를 따라가야 해서 당시에는 그것 때문에 공부를 많이 했던 것 같습니다.
어렸을 때 게임 이외의 프로그램을 짜기도 했나요?
제일 기억에 남는 건, 중학교 때 당시 물상 선생님이 석사 논문을 쓰시는데 컴퓨터를 이용한 교육이 주제였습니다. 선생님이 교육용 프로그램 계획을 짜시고 제가 MSX 베이직으로 몇 달간 구현을 했습니다. 프로그램을 띄우면 제목이 나오고 물상 문제가 나오면 학생들이 그걸 맞히고 나중에 정리해서 성적이 나오는 것이었는데요. 논문이 출간됐는데 제 이름도 들어갔고 논문에 제가 만든 프로그램의 스크린샷도 실렸습니다. 당시에 게임이 아닌 것 중에서는 가장 보람을 느꼈던 일이었습니다.
그 프로그램을 만들면서 어려웠던 점은 무엇이었나요?
프로그램 자체는 퀴즈, 즉 데이터, 보기, 답으로 구성된 것을 재생하는 거라서 어려운 프로그램은 아니었습니다. 타이틀 화면이 필요했는데 제목을 커다랗게 화면에 써야 했습니다. 옛날에는 글꼴 크기가 8 × 8로 정해져 있으니까 오늘날처럼 글꼴 크기를 키우기만 하면 되는 문제가 아니었습니다. 결국 타이틀을 그렸는데, 어떻게 했냐면 모니터 크기에 맞춰 원하는 글자를 셀로판지에 쓰고 셀로판지를 다시 모니터에 붙인 후 해당 위치로 커서를 움직이면 현재 좌표가 나오는 프로그램을 짰습니다. 그걸 그대로 트레이스해서 선으로 이은 다음, 안을 페인트로 칠하게 했습니다. 그렇게 하면 타이틀이 그려지죠. 프로그램 본체보다 좌표 계산해서 입력하는 게 시간이 더 걸렸습니다(웃음). 그래픽 도구가 있었으면 그리면 됐을 텐데 그런 도구가 없던 시절이었으니까요. 있었다고 해도 이미지 크기가 커서 베이직 프로그램 안에는 집어넣을 수가 없었죠.
필요한 걸 직접 만들어 써야 했던 시절의 개발자들과 굳이 그럴 필요가 없는 요즘 개발자들의 차이를 느끼시나요?
있다고 봅니다. 지금은 뭔가를 공부하려고 하면 책을 사지 않아도 자료가 인터넷에 기본적으로 넘쳐나죠. 또 커뮤니티에 가서 물어봐도 되고요. 옛날에는 그런 게 없었죠. 1980년대 초반이면 인터넷도, PC 통신도, 아무것도 없던 시절이니까 사용하는 컴퓨터 기종에 대한 책을 한두 권 손에 넣어서 그걸 닳도록 보는 수밖에 없었습니다. 어셈블러가 없으니 잡지에 실린 걸 보고 거꾸로 바이너리를 입력해야 했고 그러면서도 무슨 의미인지 모르는 것도 많았지만 할 수 있는 한 예제를 보고 따라해야 했습니다. 요즘은 자료 한 번 쓱 읽고 돌려보고 넘어가는데 그 전에는 그런 자료 자체가 제한이 있으니 닳도록 보는 거죠. 그러면서 더 깊이 이해할 수밖에 없는 환경이지 않았을까 하는 생각이 듭니다. 요즘은 프로그램 저장 공간이 넘치지만 8비트 PC는 보통 램이 8k, 많아 봐야 32k였으니까 저장하려면 다 테이프에 했어야 했는데 테이프는 체계적으로 자료를 정리할 수 있는 도구도 아니었고 어떤 프로그램은 몇 분 몇 초부터 몇 분 몇 초 사이에 기록되어 있다는 식으로 쓰는 게 디렉터리 대신이었으니 자료 정리도 잘 안 됐죠. 무슨 프로그램인지 공책에 써서 정리했으니 시행착오를 많이 할 수밖에 없었습니다. 어제 프로그램 작성하다가 정전돼서 날아가면 그 다음날 처음부터 다시 입력하고 하는 걸 겪으면서 훈련은 많이 된 것 같습니다. 인터넷만 되면 앉은 자리에서 자료를 대부분 얻을 수 있는 상황이면 시행착오를 훨씬 덜 하게 되는데 과연 그게 좋기만 한 것인지는 잘 모르겠습니다.
‘이 세계’에는 어떻게 들어오신 건가요?
사실 오픈 소스란 말은 1998년 즈음에 만들어진 말입니다. 옛날 컴퓨터 잡지에는 베이직으로 짠 프로그램 소스를 다 그대로 게재하곤 했는데요, 잡지 부록으로 프로그램이 들어 있는 테이프를 사지 않는 이상 사람들은 대부분 소스를 보고 쳤을 겁니다. 전 그랬거든요(웃음). 몇 십 쪽 분량으로 실려 있던 베이직 소스든 기계어 덤프든 몇 시간 또는 며칠이 걸려 그걸 입력했습니다. 그런 것도 따지고 보면 오픈 소스였죠. 그런 것들을 본격적으로 접한 건 대학교 들어가서부터였습니다. 느렸지만 학교에 인터넷이 있었고 전산원에 가면 인터넷을 쓸 수 있는 터미널이 있었습니다. 그 터미널들은 유닉스 장비에 접속하기 위한 더미 터미널일 뿐이고 실제로 유닉스에 로그인해서 FTP 서버에 가서 파일을 받은 후 집에 가져가 PC에서 돌리려면 플로피 디스크 같은 데 전송해야 했습니다. 더미 터미널에는 그런 기능이 없었고 전산원 상담실에 가서 커밋(kermit)이라는 전송 프로그램이 설치된 PC로 파일을 플로피 디스크에 복사해 가져갔었습니다. 당시에 인터넷 사용 가이드라는 소책자가 있었는데 거기에 보면 ‘인터넷, 이메일, 유즈넷(USENET), FTP란 무엇인가’, ‘FTP 콘텐츠를 검색하는 아키(archie) 또는 고퍼(gopher) 사용법’ 같은 내용이 있었습니다. 처음에는 FTP 서버에서 이미지나 공개 게임을 받는 용도로 인터넷을 쓰다가 당시에 이미 소스가 공개되어 있던 프로그램들의 저작권 표시를 보고 자유 소프트웨어(free software)라는 개념을 알게 됐습니다. 본격적으로 GNU라든지, 리처드 스톨만(Richard Stallman) 등을 알게 된 건 리눅스를 쓰면서부터였습니다. 당시에 집 컴퓨터에 리눅스를 설치하려면 상담실에 가서 SLS(Softlanding Linux System)나 슬랙웨어 같은 리눅스 배포판을 플로피 디스크 60여 장에 옮겨 담아서 집에 가서 설치하는 식이었습니다. 리눅스 공부하고 싶은 친구들끼리 모여서 플로피 디스크 계도 했었죠. 당시에 플로피 디스크 10장 들이 한 상자에 1만 원 정도로 꽤 비쌌던 것 같습니다. 각자 한 상자씩 사서 여섯 상자가 모이면 거기에 리눅스를 다 복사해 돌아가며 설치했습니다. 그렇게 해서 SLS 배포본을 설치해서 리눅스를 처음 써봤습니다. 그때 리눅스 커널이 0.99였던 것으로 기억하고요. 리눅스 배포판에 들어 있는 소프트웨어들, 예를 들어 C 컴파일러, make 등이 기본적으로 GNU 소프트웨어들이었죠. 그러면서 ‘리눅스라는 x86용 유닉스는 리누스가 만든 커널 빼고 나머지는 대부분 GNU 소프트웨어들이고, GNU 프로젝트는 MIT 출신 리처드 스톨만이 시작했고…’ 같은 역사적 내용을 알게 됐는데 당시에는 자유 소프트웨어라고 불렀지, 오픈 소스라고 하지는 않았습니다. 오픈 소스란 말이 나오기 전에 자유 소프트웨어와 상용 소프트웨어의 차이라든지, 자유 소프트웨어 운동을 지지해야 하는 이유라든지 하는 내용은 알고 있었죠.
자유 소프트웨어의 어떤 면에 끌리셨나요?
일단 학생 입장에서 ‘리눅스’라고 하면 무료로 받을 수 있어서 유닉스로 해야 하는 프로그래밍 숙제를 집에 가져가서 하고 싶은데 집에는 DOS밖에 없을 때 리눅스를 설치해서 컴파일이 잘되고 유닉스로 다시 가져가서 돌려서 문제가 없으면 숙제를 끝낼 수 있다는 점에 끌렸습니다. 실용적인 면이었죠. 상용 소프트웨어를 사지 않아도, 불법 복제를 하지 않아도 리눅스를 쓰면 필요한 게 다 들어 있다는 점이 좋았습니다.
그동안 참여한 프로젝트나 커뮤니티 등에 간단히 소개 부탁드립니다.
가장 큰 건 FreeBSD 한국 사용자 모임입니다. 원래 제가 시작한 것은 아니고 1996~7년쯤 kr.freebsd.org 도메인을 위임받아 FTP 서버 미러를 만든 류현석 씨가 있었고 그분이 활동이 뜸해지면서 1997~8년쯤 제가 이어받은 거죠. 당시에는 홈페이지와 FTP 미러 정도만 있었는데 1999년에 다른 사람들의 도움을 받아서 메일링 리스트도 만들고 홈페이지나 잡지에 기사도 연재하는 활동을 좀 했습니다. 그렇게 사용자 커뮤니티가 만들어졌고 나중에 오픈 소스 운영 체제의 축이 리눅스로 쏠리면서 한국의 경우 2000년대 중반 이후로는 커뮤니티 활동이 많이 줄었습니다. 그 전에 했던 것은 GNU 프로그램들의 메시지나 메뉴를 번역하는 프로젝트였습니다. gettext라는 프로그램으로 번역할 수 있는 메시지나 메뉴 파일들을 *.po라는 파일로 따로 분리해 놓고 해당 언어를 잘 아는 사람이 번역하게 하자는 작업이었습니다. 그렇게 GNU 한국어 번역 프로젝트를 몇 년 했었습니다. 마찬가지로 먼저 하던 분이 있었고 제가 이어받아서 했습니다. 커뮤니티라기보다는 메일링 리스트 하나 있는 느슨한 형태의 작업이었습니다. 나중에 애매해진 면이 있지만 처음에는 GNU 프로그램, 즉 ftp.gnu.org에 있던 공인 프로그램 번역은 번역 프로젝트에서 해야 한다는 암묵적 규칙이 있었습니다. 가장 큰 이유는 지금은 느슨해졌지만 예전에는 번역하겠다는 의사를 자유 소프트웨어 재단(이하 FSF)에 전달해서 승인을 받아야 공식 번역자가 되는 절차가 있었습니다. 좀 더 자세히 설명하면 GNU 프로그램들은 라이선스를 중시하므로 자신이 번역 결과물을 프로그램 원저자한테 위임하고 권리를 주장하지 않는다는 내용을 출력해서 서명을 한 후 FSF에 실제 우편으로 보내면 몇 주 후 공식 번역자가 됐다는 연락이 오는 거죠. 그렇게 해야 그 사람이 올린 번역 파일이 GNU 프로그램 안에 공식적으로 포함되도록 되어 있었습니다. 보통 사람이 가볍게 프로그램 텍스트만 번역하겠다는 식으로 접근할 수 없었던 때였죠. 그래서 그 과정을 모르고 번역 파일을 올렸다가 퇴짜 맞은 사람에게는 공식 번역자가 되는 절차를 알려주거나 제 이름으로 대신 올리거나 했었습니다. 지금도 류창우 씨와 몇몇 분들은 번역을 계속하고 있죠. 지금은 그런 엄격한 제약 사항은 많이 없어진 것 같습니다. 그 외에 초창기에 넷스케이프(오픈 소스는 아니지만)·모질라 번역에도 참여했었고 1990년대 중후반에는 한글 처리와 관련된 유즈넷 뉴스그룹인 han.comp.hangul이나 관련 메일링 리스트에서 활동도 하고 제가 운영하던 kr.freebsd.org 서버에서 몇몇 메일링 리스트 호스팅도 제공하고 하는 일들을 했습니다.
그중에서 가장 애착이 가는 것을 꼽는다면.
아무래도 가장 오래된 FreeBSD입니다. 지금도 ftp.kr.freebsd.org 등을 관리하고 있고요.
아쉬웠던 점은 무엇인가요?
FreeBSD의 경우 FreeBSD의 패키징 시스템인 포트(ports) 작업을 할 때 신규 포트를 만들어 등록하거나 기존 포트를 업그레이드하거나 하는 일도 있지만 포트 인프라스트럭처 자체를 운영하거나 포트 규칙이나 뼈대를 만드는 사람들이 따로 있습니다. 나머지 개발자들은 그 안에서 움직이고요. 예를 들어 제가 능력을 키워서 그런 일에도 참여했다면 훨씬 더 많은 일을 할 수 있었겠다는 생각이 듭니다.
FreeBSD 프로젝트에는 어떻게 참여해서 포트 커미터(ports committer)가 되셨나요?
거슬러 올라가 보면 1995년에 FreeBSD를 처음 쓰게 됐는데요. 그 전에 리눅스를 쓰던 시절에 슬랙웨어 배포 사이트인 ftp.cdrom.com에 로그인해 보면 ‘이 사이트는 FreeBSD로 운영됩니다’라는 문구가 나왔습니다. 리눅스를 배포하는 사이트가 왜 FreeBSD로 운영되나 하는 호기심에 FreeBSD가 무엇인지 찾아봤습니다. x86에 설치된다고 해서 한 번 써보자는 생각에 다운로드해서 써봤는데 저한테는 쓸 만했습니다. 당시에는 리눅스와 큰 차이도 없었고 프로그램도 웬만한 건 다 돌아갔고요. FreeBSD도 X11 환경에서 한글을 쓰려면 패키지를 설치해야 하는데 처음에는 개인적으로 소스를 받아서 컴파일해 쓰다가 아예 포트에 추가하면 되지 않을까 하는 생각이 들어서 hanterm 등을 포트로 만들어서 혼자서 쓰다가 프로젝트에 제출해서 반영하려면 어떻게 해야 하는지 내용을 찾아보기 시작했습니다. 당시에 FreeBSD는 GNATS라는 버그 추적 시스템이 있었는데 거기에 요청을 올리고 반응을 기다렸습니다. 올려놓으면 포트 커미터 중 한 명이 가져가서 커밋을 했습니다. 처음에는 그렇게 시작했고 한두 번 해보니 제가 올리는 걸 잘 받아줘서 신이 났습니다. 그 다음부터는 한글과 관련된 프로그램은 다 패치를 만들고 FreeBSD에서 컴파일한 다음 포트를 만들어 1년 정도 계속 올렸습니다. 오픈 소스 커미터 커뮤니티란 게 다 그렇지만 아무나 시켜주지는 않죠. 열정이 있고 그에 맞는 성과가 있어야 하니까요. FreeBSD도 마찬가지고요. 당시에 커미터가 되려면 원래는 기존 커미터 한 사람이 신입 커미터를 책임지는 구조였습니다. 일종의 도제 시스템으로 기존 멤버가 초대를 해야 하는 방식이었습니다. 커미터가 아닌 사람은 기여자(contributor)라고 하는데 기여자 위치에서 계속 한글 관련 프로그램의 포트를 제출하다가 2000년에 커미터가 됐습니다. 당시 FreeBSD 프로젝트 리더였던 조던 허버드(Jordan Hubbard)가 방한했을 때 만나서 커미터가 되고 싶다는 이야기를 했고 조던이 그날 저녁 계정을 만들어 주었고 조던이 멘토(mentor)가 됐습니다. 처음 커미터가 되면 해야 할 일이 있었는데 FreeBSD 핸드북의 커미터 목록에 자기 이름을 올리고 그걸 CVS로 커밋하는 것과 포트의 xearth라는 지구본 프로그램 플러그인 중 커미터 위치를 알려주는 파일에 자기 좌표(위도와 경도)를 입력하는 등이었습니다. 그걸 멘토가 확인하고 지도해 주었고요. 그런 통과의례를 거친 후에는 예전처럼 패치를 만들어 GNATS에 올리는 대신 제가 직접 커밋을 하게 됐습니다. 저는 주로 korean 카테고리의 포트를 맡았습니다만 다른 카테고리도 일부 작업 했었죠. 오래 할 수 있었던 비결이 딱히 있었던 것 같지는 않고 그 일에 얼마나 관심이 있고 한 번 시작한 일에 대해 일종의 책임감을 얼마나 느끼는지에 달려 있다고 봅니다. 물론 오픈 소스 프로젝트라는 게 하든 말든 개인의 자유이기는 한데 그럼에도 업무 시간이나 다른 시간말고 개인 시간을 쪼개 이 일을 할 수 있다는 것은 제가 볼 때는 자신이 어떤 열정을 스스로 가지지 않으면 애초에 불가능한 이야기 같습니다. 어느 오픈 소스 커뮤니티든 마찬가지이지만 기본적인 장벽이 있는 게, 프로젝트의 일부분을 맡아서 할 수 있는 자격이 있는지 어떤 형태로든 시험을 받게 되어 있고 그걸 통과해야 하는 거니까 일단 커미터가 되는 벽을 통과하려면 그 사람은 이미 그 프로젝트에 대해 굉장히 많은 시간을 쏟았다는 이야기죠. 이미 내용을 다 들여다봤고 자신이 주로 고치던 부분은 정말 잘 알고 있을 테고요. 그 정도 열정이 있고 그만한 성과를 냈음을 증명해야지만 커미터 그룹에 들어가는 것이기 때문에 일단 거기에서 장벽이 있는 셈이죠. 일단 커미터가 되고 나서의 장벽은 특정한 컴포넌트를 자신이 완전히 리드하는 위치에 오를 수 있느냐는 것입니다. 커널의 특정 드라이버는 자신이 메인이라서 다른 사람이 패치를 올려도 자신이 직접 보고 자신이 생각하는 구조에 맞는 건지 판단할 수 있고 관리할 수 있는 게 그다음 단계인 것 같습니다. 그러고 나서 프로젝트의 최상위 그룹 또는 프로젝트의 방향을 결정하는 코어 팀 수준까지 갈 수 있는지는 또 다른 이야기일 겁니다. 그런 장벽들을 하나씩 넘어서면서 그 위로 올라가려면 그만한 노력을 쏟아야 하니까 그건 누가 시킨다고 되는 것이 아니라 자신이 그만한 열정을 쏟을 수 있어야 가능한 것 같습니다.
FreeBSD 프로젝트에 커미터로 참여했거나 참여 중인 한국인 개발자들은 얼마나 되나요?
장혜식(perky@), 정원교(weongyo@), 편용헌(yongari@), 김정욱(jkim@) 씨가 있습니다. 사실 리눅스처럼 FreeBSD 커널을 해설한 책도 거의 없고 볼 수 있는 자료라고는 BSD 관련 서적 몇 권과 소스뿐이라서 자기가 열심히 코드를 보고 이해해야 하니까 정말 쉬운 일이 아닌데 FreeBSD 커널 프로그래밍을 하는 사람들이 있더군요. 그걸 이해해서 코드를 고친다거나 커미터까지 된 사람들은 정말 실력이 대단하거나 정성이 지극하다고 생각할 수밖에 없을 것 같습니다.
포트 커미터 활동을 지금은 중단하셨다고 하던데….
FreeBSD에서는 1년간 커밋을 하지 않으면 자동으로 계정이 정지됩니다. 예전에는 그런 규칙이 없었고 탈퇴 의사를 명시적으로 밝히는 방식이었는데 커미터 수가 늘어나니까 그렇게 해서는 관리가 되지 않아서 1년간 커밋이 없으면 일단 정지 상태가 되고 다시 커밋 권한을 얻으려면 멘토 한 명을 다시 찾아야 하도록 바뀌었습니다. 그만두게 된 건 여러 가지 이유가 있는데, 시간도 없고 처음에 활동 시작했을 때와 달리 결혼도 했고(웃음) 회사 일도 바쁘고 FreeBSD를 날마다 쓰는 환경이 아니기도 하고요. 예전에는 회사 서버도 FreeBSD였고 데스크톱·노트북에 다 FreeBSD를 설치해 사용했는데, 지금은 회사 서버는 리눅스이고 노트북은 맥북이고 하다 보니 FreeBSD를 별도로 설치해 쓰지 않으면 신경을 쓰기 어려운 환경이 됐습니다. 그러면서 멀어진 것 같습니다.
커밋 권한 정지 후 아쉽지는 않았나요?
커밋을 하지 않았으니 불만은 없었고요(웃음). 정지되기 몇 달 전부터 ‘활동을 재개하지 않으면 정지된다’는 메시지가 오는데 활동을 못했으니까요. 누구한테 탓을 할 수 없죠. 이른바 활발한 커미터와 그렇지 않은 커미터들이 있는데요. 시간에 따라 바뀌기는 하지만 늘 활발한 커미터들은 제가 보기에는 전체 중 20% 정도인 것 같습니다. 나머지는 한 달에 한 번씩 커밋하는 사람도 있고요. 개인 사정이든 뭐든 간에 활동을 쉬었다가 재개하려면 그만한 열정이 필요한 일들이니까 그렇지 않으면 서서히 밀려나게 되어 있습니다. 그런 규칙이 도입된 데에 큰 불만은 없습니다.
그동안 기여하셨던 한글 관련 포트의 업스트림 프로그램 자체도 최근 몇 년간 변화가 없는 것 같습니다.
1990년대 후반에서 2000년대 초반에는 유닉스에서 한글 처리가 큰 이슈여서 관련 프로그램이 많이 나왔고 적극적으로 관리됐습니다. 그 이후로는 리눅스나 BSD 운영 체제에 국제화 기능이 다 들어가서 한글 관련 프로그램 숫자가 굉장히 줄었고 기존 프로그램들도 버전이 올라가지 않는 상황입니다. 시대 흐름에 따라 자연스럽게 밀려나는 경우도 있을 것이고 개발자가 손을 뗐다거나 하는 이유로 잊히는 경우도 있는 것 같습니다. 또 한 가지 이유로는 당시에는 리눅스를 데스크톱으로 써보려고 했던 사람들이 많았는데, 요즘에는 리눅스나 BSD로 데스크톱을 쓰는 것보다는 맥 OS를 쓰죠(웃음). 맥 OS의 유닉스 부분은 FreeBSD를 기반으로 하고 있어서 터미널을 띄우면 쓸 수 있는 명령어가 익숙하기도 하고요. 그리고 서버 사이드에서도 한국어를 지원하는 프로그램이 그렇게 필요하지는 않거든요. 그러다 보니 데스크톱으로는 쓰지 않고 서버로만 쓴다고 하면 한글 관련 프로그램으로는 할 일이 별로 없는 거죠.
나름 전통과 역사가 있는 운영 체제나 언어들이 점점 주목을 잃어가는 경향도 있는 것 같습니다. 그냥 자연스러운 현상일까요?
결국은 엔지니어들이 어떤 플랫폼을 주로 쓰게 되는지에 따라서 결정되는데 1990년대 후반~2000년대 초반만 해도 굳이 리눅스가 아니어도 상용 유닉스 같은 선택지가 많았습니다. 요즘에는 돈이 많은 회사가 아니면 서버 운영 체제로 리눅스를 쓰게 되면서 엔지니어들이 그쪽으로 점점 몰리는 탓도 있는 것 같습니다. 그리고 에반젤리스트 역할을 할 사람이 나서서 커뮤니티도 만들고, 좋다고 이야기도 하고, 의도적이든 아니든 마케팅을 할 수 있는 그룹이 필요한데, 리눅스는 이미 그런 임계점은 넘어서 다들 자연스럽게 리눅스를 쓰게 됩니다. BSD 같으면 누가 나서서 이야기해 주지 않으니 엔지니어들이 한쪽으로 쏠리는 거죠. 어떤 운영 체제를 공부할지 고민할 필요 없이 그냥 리눅스를 배우면 취직도 되고 별 문제가 없으니까요. BSD를 선택하면 굉장히 고난(?)의 길을 가거나 배워도 쓸 데가 없는 문제가 생기는 거죠. 국내에서 파이썬 대 펄의 관계도 비슷합니다. 해외에서는 펄을 아직도 많이 쓰는데요. 국내에서는 왠지 모르게 스크립트 언어 하면 당연히 파이썬을 배워야 하는 분위기가 형성되어 있는 건 방금 이야기했듯이 의도적이든, 의도적이지 않든 계속 써온 사람들이 마케팅을 잘해서 사람들한테 알리고 커뮤니티를 조직하고 거기에 대한 책을 쓰고 인터넷에 유용한 정보를 많이 올리고 하는 활동이 파이썬의 경우 한국에서는 잘 조직되어 있어서인 것 같습니다. 그래서 스크립트 언어를 새로 배우고 싶은 사람에게 추천해 줄 게 뭐냐고 하면 대부분 파이썬을 이야기하게 되죠. 리눅스나 파이썬은 그런 측면에서 임계점을 넘은 것으로 보입니다. 전 펄을 많이 쓰는데요. 버전도 올라가고 있고 프로젝트 정체기에서도 벗어나고 있는데 한국에는 그런 내용이 잘 전달되지 않더군요. 펄 하면 옛날 CGI 짜는 데나 쓰는 것 같은 인식이 아직도 남아 있죠.
상업적인 마케팅을 별로 하지 않는 오픈 소스 세계에서 주목을 얻어내는 요소는 무엇일까요?
대부분은 커뮤니티 활동이라 생각합니다. 특정한 주제에 대해 커뮤니티가 활성화되면 자료가 모이기 시작하고 자료가 모이다 보면 책으로 나오기도 하고 그래서 기존에 모르던 사람들도 끌어들이고 그렇게 커뮤니티 사람들이 많아지면 커뮤니티뿐 아니라 다른 데에 가서도 전파를 시작하죠. 그렇게 확산되는 효과의 시발점은 역시 커뮤니티인 것 같습니다. 그게 지속적으로 운영되고 운영자들이 거기에 시간을 들여서 자료를 충실하게 만든다거나 번역을 해놓는다거나 하는 노력이 많이 되어야 하겠죠.
오픈 소스란 말이 고안되기 전부터 이 세계에서 활동해 오셨고 그동안 세기가 바뀌었는데 어떤 점들이 달라졌나요?
제가 대학에 들어갔을 시기에는 리눅스 같은 것들은 제한적으로 사용하고 주로 솔라리스 같은 상용 유닉스를 많이 썼습니다. 그러다가 2000년대 들어와서 가장 큰 변화는 리눅스가 주류가 됐다는 것인데요. 예전에는 리눅스는 굉장히 특이한 것이었고 상용 유닉스가 더 좋다고 생각하기도 했고요. 요즘은 오픈 소스나 리눅스 같은 말이 굉장히 일반화돼서 다들 쉽게 접하게 됐고 그러다 보니 그걸 기반으로 또 다른 오픈 소스 프로젝트가 많이 나오고 있죠. 클라우드 컴퓨팅이나 빅 데이터 관련 기술이 대부분 오픈 소스이니까요. 이런 기술들이 1990년대에 나타났다면 다 상용 소프트웨어 형태로 나왔을 겁니다. 지금은 그런 걸 만들어도 오픈 소스로 만드는 게 일반화될 만큼 사람들 인식이 많이 바뀌었습니다. 1990년대 말만 해도 오픈 소스 관련 글이 나오면 항상 나오는 문제가 ‘그걸로 먹고살 수 있느냐’는 것이었죠. 그런데 그 후로 레드햇 같은 리눅스 배포판을 보면 컨설팅이나 기술 지원 등으로 사업 모델을 구성해 자리 잡았고 그렇게도 먹고살 수 있다는 걸 보여주니까 최근에 나오는 스타트업들, 예를 들어 하둡 기반 스타트업이라면 하둡 자체는 오픈 소스지만 자사 제품의 상용 버전을 따로 판다거나 기술 지원을 제공한다거나 해서 회사의 사업 모델을 세우고 있죠. 그런 사례들이 10여 년간 정착되어 오다 보니 사람들이 이제는 굳이 그런 것들을 상용 소프트웨어로 만들려고 하지 않습니다. 옛날에는 특별한 걸 만들면 당연히 소스를 공개하지 않으려고 했는데 지금은 그렇지 않게 됐습니다. 또 상업적으로 판매하는 소프트웨어를 만드는 게 아니라 어떤 서비스를 제공하기 위해 거대한 인프라를 운영하는 경우 옛날에는 공짜여서 리눅스를 썼다고 한다면, 지금은 상용 소프트웨어를 쓰지 않아도 그 이상의 성능을 기존 오픈 소스를 잘 조합해서 낼 수 있을 만큼 오픈 소스 품질이 올라간 덕분에 오픈 소스가 자연스럽게 받아들여지고 있습니다. 예전에는 마이크로소프트 IIS보다 아파치 웹 서버가 나은 게 뭐냐는 질문을 받았지만 지금은 그런 의문을 품는 사람이 별로 없다고 생각합니다. 고성능이 필요하면 nginx를 써도 되고요. 그 점이 과거에 비하면 가장 다른 것 같습니다. 2000년대 들어서면 크게 고민하지 않고 상용 대신 오픈 소스를 선택해도 충분한 결과를 얻을 수 있는 수준이 된 거죠. 또 한 가지는 최근에 IT 업계에 새로 들어와서 일하는 사람들 중에는 오픈 소스를 업무상 필요해서 배워야 하는 지식 중 하나로 받아들이는 사람이 많습니다. 달리 말하면 오픈 소스를 사용한다는 자부심 또는 뭔가 기여해 보고 싶다는 생각은 잘 안 드는 거죠.
현재 일하는 분야에서 오픈 소스가 차지하는 비중은 어느 정도인가요?
지금은 90% 이상 리눅스 서버를 쓰고 있습니다. 윈도 미디어 스트리밍 서비스나 백엔드 데이터베이스가 MS SQL로 되어 있는 서비스 등에는 윈도 서버를 쓰고 있는데 신규는 리눅스 기반에 MySQL, 웹 개발 프레임워크에는 장고 등을 쓰고 있습니다. 플래시 스트리밍 같은 경우도 어도비의 플래시 미디어 서버 등 선택권이 거의 상용 소프트웨어밖에 없습니다. 그런 분야는 오픈 소스의 품질이 상용에 미치지 못하는 사례라 할 수 있습니다. 있다면 오픈 소스를 쓰겠죠.
오픈 소스를 사용하면서 생기는 문제들은 자체적으로 해결하나요, 아니면 유료 기술 지원을 받나요?
기술 지원 패키지를 사기도 하는데 항상 기술 지원을 받지는 않습니다. 공개된 정보로 처리되기도 하니까요. 또는 하드웨어를 업그레이드하는데 기존 리눅스 배포판이 설치되지 않을 경우 일단은 최대한 자체 해결을 시도합니다. 드라이버가 없어서 설치되지 않는다면 드라이버를 넣어서 커널을 다시 빌드하면 되니까요. 그런 정도로 끝나면 자체적으로 해결하는 거고 그렇게 되지 않으면 하드웨어 판매사에 지원을 요청할 수도 있죠.
상용 제품의 기술 지원을 사는 것과 자체 해결을 하는 것을 비용 대비 효율 면에서 비교한다면 어떤가요?
비용 측면보다는 회사의 방침에 달린 문제 같습니다. SaaS(Software as a Service) 같은 서비스 회사들이 늘고 있습니다. 그런 회사들은 점점 클라우드 위에서 뭔가를 만들고 있는데 그렇게 되면 될수록 자체적으로 엔지니어를 보유해야지 원하는 문제를 빨리 해결할 수 있습니다. 솔루션 또는 하드웨어 회사들은 문제가 생기면 해당 회사에 요청해 엔지니어를 불러서 해결한다거나 하지요. 예를 들어 어떤 사람이 모바일 앱을 하나 만들고 백엔드를 아마존에서 돌리고 있는데 문제가 생기면 물어볼 사람이 없습니다. AWS(Amazon Web Services) 문제라면 아마존에 연락하면 되지만 리눅스 가상 머신 위에서 MySQL 등을 설치해서 뭔가를 하고 있다면 대부분의 문제는 스스로 해결할 수밖에 없습니다. 그렇게 하지 않으면 일 처리가 굉장히 느려지고요. 한국에서는 직접 하기보다는 업체를 불러서 일을 시키는 경우가 많은데 요즘은 인터넷을 조금만 뒤지면 상용 벤더의 사용자 포럼이나 KB(knowledge base) 등 정보가 많이 축적되어 있습니다. 영어라서 찾아보지 않아서 그렇죠. 서비스를 운영하는 엔지니어라면 그런 것에 대한 거부감이 없어야 하고 그러면서 문제를 하나둘씩 해결해 나가면 그게 개인의 자산이자 회사의 자산이기도 한 거죠. 오픈 소스를 많이 쓰면 쓸수록 그런 문제에 직면할 수밖에 없으니까요. 하둡을 돌리다가 문제에 부딪히면 소스도 열어보고 커뮤니티에 질문도 해보고 하는 것이 장기적으로는 그 회사 또는 개인의 경험치에 훨씬 도움이 되는 일인 거죠. 그래서 서비스 회사라고 한다면 자기네 서비스를 최대한 커버할 수 있는 엔지니어를 보유해야 한다고 봅니다.
보통 회사들은 직원이 지식을 쌓기 위해 들이는 노력이나 시간을 아까워하는데….
저희 회사의 경우는 엔지니어들이 서비스를 운용하고 개발할 수밖에 없습니다. 예를 들어 예전에는 상용 캐시 서버를 썼었는데 지금은 자체 캐시 서버를 직접 개발, 업데이트하고 있습니다. 당연히 인력이 더 들겠지만 고객 요청에 대한 대응이라든지, 신규 기능 추가라든지, 갑자기 생긴 버그 수정이라든지 하는 일에 예전에는 판매사에서 수정할 때까지 기다릴 수밖에 없었고 문제를 우회해야 했지만 지금은 그런 간격이 훨씬 줄어든 거죠. 좀 더 근본적인 개선에 대한 문제를 생각해 볼 수도 있고요. 그런 측면에서는 자체 능력을 보유하는 게 나은데 다른 회사들은 그 점에 대해 어떻게 대응하는지는 잘 모르겠습니다. 포털이나 기술 기반 스타트업들은 이런 문제를 많이 생각하는 것 같은데 아직 일반적이라 보기는 어려운 것 같습니다.
상용 지원 대 자체 해결 비율은 어떻게 조정하는 게 좋을까요?
회사 사정에 따라 달라서 정하기는 어려운 것 같습니다. 지원을 받을 수 있다고 해도 꼭 필요한 것인지 검토해야 하고, 국내에서 지원받을 수 있는지도 고려해야 하고요.
DevOps라는 흐름도 넓게 보면 오픈 소스 기반 서비스 개발이 보편화하는 것과 연관이 큰 것 같습니다.
개인적으로는 관심이 있는데 이미 조직 규모가 커진 회사에는 바로 도입하기는 쉽지 않을 것 같습니다. 아무것도 없이 새로 시작한다면 처음부터 그런 모델로 가는 게 요즘에는 더 적합하다는 생각이 듭니다. 그런데 이미 몇 년간 많은 사람이 운영하고 있는 조직에서 바꾸려고 하면 프로세스나 프로그램을 바라보는 관점을 많이 바꿔야 합니다. 자동화를 위한 투자도 들어가야 하고요. 클라우드 기반으로 가면서 랙당 스위치 또는 네트워크 포트 수 결정 등 데이터센터 플래닝 같은 하드웨어 인프라를 관리하는 부담이 줄고 소프트웨어 업데이트가 더 중요해지는 측면에서 DevOps로 많이 이동했다고 보는데요. 하드웨어 인프라와 그 위에서 돌아가는 운영 체제, 애플리케이션이 같이 맞물려 운영되는 경우 갑자기 DevOps를 하자고 해서 뭔가 쉽게 바뀔 것 같지는 않고 점진적으로 개선해 나가는 게 적절하다고 생각합니다.
어떤 면에서 관심이 생기셨나요?
DevOps가 성공하려면 자동화가 열쇠라고 생각하는데요. 적용도 빨리 할 수 있지만 문제가 있을 때 롤백도 빨리 할 수 있는 시스템을 만들려면 자동화가 꼭 필요하죠. 그런 시스템을 만들지 않으면 개발과 운영의 융합이라든지, 빨리 개발해서 빨리 적용하는 게 되지 않거든요. 개발은 짧게 했는데 배치할 때 시간이 오래 걸리고 문제가 생겨서 롤백하는 데 굉장히 어렵고 하면 당연히 그 방법을 채택할 이유가 없으니 자동화를 얼마나 높은 수준에서 달성했느냐가 핵심이라고 봅니다.
오픈 소스 소프트웨어들이 대체로 업그레이드 주기가 빨라지고 있는데 인프라 운영 측면에서 어떻게 대처하나요?
운영하는 입장에서는 굉장히 보수적일 수밖에 없습니다. 돌아간다는 게 확인되면 굳이 바꾸지는 않는 게 정답이죠(웃음). 새 버전을 써야 한다면 성능이 크게 향상됐다거나 새로운 하드웨어를 지원해야 하는 경우입니다. 기본적으로 그런 변화들은 느리게 일어나게 되어 있고 대표적인 예가 레드햇 엔터프라이즈 리눅스입니다. 커널 버전이 아직도 2.6.x 기반이니까 굉장히 보수적인 거죠. 자바도 비슷해서 새 버전이 나왔다고 해서 바로 바꾸지는 않는데 운영 환경을 깨지 않는 게 중요해서 JDK 버전 업그레이드도 보수적일 수밖에 없습니다.
다양한 오픈 소스 소프트웨어가 경쟁 중인데 CTO로서 시스템을 기획할 때 어떤 기준으로 구성하시나요?
제가 일하는 회사에서는 기술이나 시스템 구성 요소가 아주 최신 경향을 따라가지는 않습니다. 말씀드린 것처럼 커널 업그레이드도 보수적이고 다른 것들도 마찬가지입니다. 안정성이나 엔지니어들에게 익숙한 것 위주로 갑니다. 예전에는 상용 솔루션을 사서 썼는데 지금은 자체 구현하는 편인데요. 결국은 원하는 걸 자유롭게 하기 위해서는 사내에서 직접 개발할 수 있는 역량이 있는 것이 중요합니다. 요구 사항을 빨리 수용한다거나 버그에 빨리 대처해야 한다거나 할 때는 자체 엔지니어 역량이 없으면 그런 일을 할 수 없으니까요. 굳이 자체 개발할 필요가 없는 것들은 오픈 소스를 사용합니다. 새로 뜨고 있는 오픈 소스 기술들의 경우는 도입했을 때 얻을 수 있는 혜택이 무엇인지 확실해야 시도하게 되는데요. 사람이 하는 일이니 개발자들이 확신이 섰을 때나 기존 솔루션에 한계가 있어서 도입하지 않으면 안 될 때가 그런 상황인 것 같습니다. 예를 들어 고객에게 과금이나 통계 데이터를 제공하려면 로그 처리를 해야 하는데 그 로그량이 굉장히 커서 하둡을 도입하는 작업을 하고 있는데요. 그런 걸 선도적으로 하는 회사들도 있는데 그런 추세를 그냥 바로 따라 하기보다는 ‘내부적으로 로그 처리 시스템을 몇 년간 운영해 봤는데 확장성이나 에러 복구 또는 운영 편리성을 감안했을 때 하둡을 도입해야겠다’는 식으로 기술이 성숙해졌다고 판단될 때 그때 도입하는 거죠. 기술 회사들은 대개 최신 소프트웨어 스택을 쓰고 있다는 걸 홍보하는 스타트업 같은 경우와 약간 보수적이지만 최대한 안정적으로 가려고 하는 두 분류로 나뉘는 것 같습니다.
비용 절감과 관련해 소프트웨어 최적화에 대한 압박은 없나요?
하드웨어 추가 투입은 최후의 수단인 것 같습니다. 그 전에 소프트웨어를 먼저 최적화하는 게 맞는 것 같습니다. 일하는 사람 입장에서는 돈으로 해결하는 게 최고일 수도 있겠지만 소프트웨어 개선으로 해결하면 비용적인 측면에서 도움이 되는 면이 많다고 할 수 있습니다.
지금도 업무로 개발을 직접 하시나요?
제가 필요하거나 팀 내 업무와 관련된 개발은 직접 합니다.
어떤 개발 도구들을 쓰시나요?
요즘에는 주로 데이터 처리하는 일이 많습니다. API로 뭔가를 가져와서 그걸 가공해야 하는 일이 많아서 제 경우 최근에 하는 일은 대부분 펄을 쓰고 있습니다. 데이터 처리하는 프로그램도 짜고 간단하게 CGI 기반으로 짜기도 하고요.
개발하면서 현재 사용하는 도구에서 불만족스러운 부분이 있다면.
불만족스러운 부분은 별로 없습니다. 펄의 경우 CPAN(Comprehensive Perl Archive Network)에 원하는 게 웬만하면 다 있고요. 그리고 최근에 펄 자체도 많이 업그레이드돼서 모듈을 편리하게 이용할 수 있는 도구가 많이 나왔습니다. 그런 것들을 잘 선택해서 쓰면 생산성 면에서는 큰 불만은 없습니다. 사실 모듈을 많이 쓰지는 않습니다. 텍스트 처리가 많아서 텍스트 파일에 저장된 데이터를 읽어와 쪼개서 처리하는 작업이라서요. 최근에는 통계 관련 모듈, 예를 들어 평균값이나 표준 편차 같은 것을 좀 쓰고 YAML 같은 마크업 언어도 데이터 저장 용도로 쓰고 있습니다.
굉장히 많은 로그가 쌓인다고 하셨는데 그런 데이터 중에서 가장 우선순위가 높은 것은 무엇인가요?
일단 장애를 방지하는 것입니다. 장애라고 하면 특정 URL에 접속되지 않는 것이 가장 심각한 것입니다. 그 외에 갑작스러운 성능 저하도 기존 서비스 품질이 떨어지는 것이라서 그런 것들도 찾아내야 합니다. 데이터를 오랫동안 관찰하다 보면 몇 가지 카테고리화가 되는데 예를 들어 서버 문제, 네트워크 문제, 로드 밸런서 문제로 나뉩니다. 이런 현상이 평소에 생기지 않다가 나타나면 왜 그러는지 알아내야 합니다. 접속이 안 되는 장애는 바로 알 수 있지만 성능 저하 문제는 수치를 정의해서 그 수치를 넘어서는지 모니터링을 해서 주기적으로 보고하는 거죠.
1990년대 중반만 해도 오픈 소스는 설치부터 이른바 ‘삽질’을 겪는 경우가 제법 있었는데 요즘 실무에서 상황은 어떤가요?
예전보다 덜한 것 같습니다. 대부분 패키지로 설치하고 소스에서 직접 빌드하는 경우는 없으니까요. 소프트웨어도 발전해서 웬만한 건 설정 파일에서 파라미터로 변경할 수 있고 명령행 옵션으로 조정할 수 있어서 굳이 소스를 빌드해 설치할 필요가 없어진 거죠. 리눅스 배포판 자체가 발전해서 좋은 점이 바로 그런 면이라고 생각합니다. 패키징이 잘되어 있어서 사람이 그런 스트레스에 덜 시달리는 거죠. 옛날에 솔라리스를 쓸 때는 솔라리스를 설치하면 유닉스 기본 유틸리티밖에 없어서 상용 C 컴파일러를 구매하지 않았다면 맨 처음 하는 일이 썬에서 운영하는 솔라리스용 패키지 사이트(SunSITE)에 가서 GCC(GNU Compiler Collection)를 받아와 설치하고 다시 GNU 사이트에 가서 GCC 최신판 소스를 받아서 빌드해 GCC를 최신판으로 업그레이드한 후에 추가로 필요한 유틸리티를 설치했었습니다. 그런 과정을 계속 되풀이해야 했는데 서버를 재설치할 때마다 그걸 해야 하니까요. 그런 ‘중노동’ 같은 반복 연습을 해도 얻을 수 있는 게 많았습니다. 일단 처음 써보는 거니까 명령도 반복해서 쳐보고 시행착오를 겪으면서 어떤 옵션을 줘야 빌드를 제대로 할 수 있을지 생각해 보게 되고…. 사실 그것만으로 도 많은 공부가 됐다고 생각합니다. 요즘은 그런 일은 덜 하는 거죠. 패키징이 워낙 잘되어 있으니까요. 자기가 실제로 해야 하는 일에 더 신경을 써야죠. 뭔가 일을 하고 싶을 때 그것에 대한 효율은 올라갔을 수 있는데 달리 생각하면 빌드나 설치 같은 기본 과정은 모를 수 있죠. 내부에 대한 이해가 부족해지는 경향도 있는 것 같습니다.
오늘날 오픈 소스 소프트웨어의 복잡성은 어느 정도라고 보시나요?
저도 요즘 그런 생각을 하는데 뭔가를 하려면 배울 게 너무 많습니다. 예를 들어 10여 년 전 같으면 리눅스 설치, 기본 설정하고 아파치나 PHP, MySQL을 설치, 운영할 줄 알고 이메일 서버를 돌릴 수 있으면 전문가라고 할 수 있었던 것 같은데 이제는 그런 건 너무나 기본적이거나 이미 잘 만들어진 서비스를 사서 쓰는 게 낫습니다. 요즘은 하둡 기반으로 빅 데이터를 처리한다거나 오픈스택으로 뭔가를 구축한다거나 하는 정도의 일은 하지만 하둡 자체를 개선한다거나 오픈스택 커미터가 된다거나 하는 것은 또 다른 일이 됐다고 생각합니다. 제가 처음 FreeBSD를 배울 때만 해도 최소 운영 체제 설치 용량이 200MB 정도였고 릴리스 노트 정도만 알아도 대략 이해할 수 있는 환경이었는데, 요즘은 그것 말고도 운영 체제에서 필요한 구성 요소나 여러 가지 더 복잡한 기술들이 나오면서 한 사람이 어느 정도 이해할 수 있는 수준을 넘어선 것 같습니다. 정말 방향을 하나 정해서 그것만 깊숙하게 파지 않으면 수박 겉핥기식으로 돌다가만 그치지 않을까 하는 걱정이 됩니다.
흔히 오픈 소스 하면 누구나 소스를 보고 공부할 수 있다고 생각해 왔는데 소스를 봐도 이해할 수 없는 수준이 된다면 아이러니할 것 같습니다.
맞는 말씀인데 옛날에 비해서는 소스 코드 크기가 크죠. 1990년대 초중반에 GNU 사이트에서 애플리케이션을 받아서 소스를 풀면 파일이 그렇게 많지 않았습니다. 정말 원하면 소스를 읽어봐서 필요한 기능이 있으면 고친다거나 할 수 있었는데 요즘에 나오는 것들은 양이 방대해져서 소스 코드를 풀면 내용이 너무 많은 거죠. 리눅스 커널의 경우도 20년 전 커널 소스와 지금 커널 소스를 비교하면 굉장히 큰 차이가 날 텐데 그만큼 진입 장벽이 높아졌다는 이야기입니다. 이해하는 데 시간도 훨씬 오래 걸릴 테고요. 그래서 제가 지금 뭔가 새로 배우겠다고 해도 굉장히 알아야 할 게 많을 것 같은데, 갓 대학을 졸업했거나 컴퓨터를 배우면서 오픈 소스에 관심이 생겨서 열어보면 그 방대함에 처음부터 기가 죽을 수도 있죠. 어디를 봐야 할지도 모르겠고…. 그런 측면에서 진입 장벽이 더 높아졌다고 봅니다. 예전에 유닉스 커널 소스 코드를 다 실어 놓은 『Lions’ Commentary on Unix』라는 책이 있었습니다. 유닉스 처음 배우는 사람들에게 가장 좋은 교재라고 했었는데 그때는 주요 소스 코드를 다 인쇄해도 책으로 출판할 수 있는 크기였지만 요즘은 책으로 해결할 수 있는 분량이 아닙니다. 그 정도면 일단 좋은 가이드가 없이는 접한다는 것 자체가 굉장히 어려운 일입니다. 그나마 할 수 있는 방법은 내가 보고 싶은 걸 딱 정해서, 예를 들어 파일 시스템 드라이버를 보고 싶다면 거기서부터 시작해 위로 거슬러 올라가는 것 정도가 좋은 접근 방식 같고요. 그러다 보니까 전체를 이해하기는 굉장히 어려워지는 상황 같습니다.
피터 노빅이 「Teach Yourself Programming in 10 Years」란 글을 발표한 적이 있습니다. 숙련된 오픈 소스 개발자가 되는 데 시간이 어느 정도 걸릴까요?
컴퓨터나 프로그래밍에 대한 기본 지식이 있다고 하면 익혀야 할 오픈 소스가 얼마나 거대한 프로젝트냐에 따라 다를 겁니다. 갑자기 리눅스 커널 개발자가 되겠다고 하면 3~4년 정도 굉장한 학습 곡선이 요구될 수도 있겠지만 그게 아니라 간단한 유틸리티 정도라면 진입 장벽이 훨씬 더 낮겠죠. 커널 개발자는 훌륭한 사람이고 웹 프레임워크 개발자는 그보다 못한 사람이라는 생각은 들지 않거든요. 해당 분야에서 얼마나 잘할 수 있느냐가 중요하지, 프로젝트 규모가 중요하지는 않습니다. 소스포지가 나온 이후로는 오픈 소스를 관리할 수 있는 서비스가 많이 생겼잖아요. 요즘은 깃허브가 가장 유명한데요. 제가 볼 때 가장 중요한 것은 단순히 남이 만들어 놓은 소스 받아서 빌드해보고 사용해보는 데서 끝내는 게 아니라, 자기가 필요에 의해 쓰는 프로그램이라면 분명히 궁금한 게 생각나거든요. 그러면 메일링 리스트나 포럼 게시판에 들어가서 질문도 하고, 물론 답변을 못 받아서 좌절할 수도 있지만, 더 관심이 생기면 소스도 열어보고 더 궁금한 점이 생기고 그러다 보면 자신이 고치고 싶거나 보완하고 싶은 기능이 생각날 거고 실제로 그걸 고쳐서 개발자한테 보내서 피드백을 받고 자기가 올렸던 패치가 받아들여지는 식으로 한 단계씩 밟아 올라가는 게 실질적인 활동으로 이어지죠. 오픈 소스라고 해서 완성된 걸 사용한다는 개념이 아니라 자신도 쓰면서 만든 사람과 교류를 시작하지 않으면 아무리 좋은 걸 가지고 있어도 단순히 사용자에 그칠 뿐이죠. 오픈 소스는 결국 참여해야 의미가 생기니까요. 저는 프로젝트 크기가 중요한 게 아니라 거기에 자신이 얼마나 능동적으로 참여하느냐가 더 중요하다고 봅니다.
예전에는 흥미로운 오픈 소스 유틸리티가 많았던 것 같은데 요즘은 오픈 소스 하면 큰 프레임워크를 주로 떠올리는 것 같습니다. 거대한 프로그램으로 유명세가 몰리는 이유는 무엇일까요?
이른바 틈새시장이란 게 줄어든 건 맞는 것 같습니다. 오픈 소스를 바라보는 관점 자체가 일을 하는 데 필요한 도구로 보는 방향으로 바뀐 것 같고요. 앞서 말한 것처럼 패키징이 잘되어 있는 탓도 있을 텐데 그냥 바이너리로 설치하다 보니까 이게 오픈 소스인지, 상용 프로그램인지 그다지 중요하지 않죠. 어차피 바이너리니까요. 그걸 오픈 소스로 받아들이는 사람은 소스가 있고 원하면 볼 수도 있다는 사실을 알지만 대부분의 사람들은 그냥 사용만 하니까 그냥 편하게 비용 없이 받아서 쓸 수 있는 프로그램일 뿐이고 그러다 보니 그 위에서 자신이 원하는 일만 할 수 있으면 그걸로 충분한 거지, 거기에서 틈새를 찾아 보완할 수 있는 뭔가를 만들지 않고, 예전만큼 그런 틈새도 없고 그걸 찾아내야 하는데 별로 그런 데 관심을 두지 않는 것 같습니다.
개발자들이 실력을 키우는 방법 중 하나가 필요한 작은 도구들을 직접 만들어 쓰기라고 하는데 그런 도전 정신이 많이 보이지 않는 것 같습니다.
그렇죠. 어쨌든 뭔가를 열심히 하다 보면 자기가 필요한 건 생겨나게 마련입니다. 제 경우, 앞서 말씀드린 성능 모니터링을 하려면 회사 시스템에서 데이터를 가져와서 적당한 형태로 가공해서 문제가 될 것만 추려서 보여주는 프로그램이 있어야 하는데, 그런 건 누가 해줄 수 있는 게 아니니까 자기가 만들어 쓰는 수밖에 없거든요. 누가 개발자의 덕목은 게으름이라고 이야기했는데 다시 말하면 자동화를 하라는 이야기입니다. 사람이 했던 반복 작업을 대신할 프로그램을 짜는 게 개발자니까요. 자신이 원하는 걸 자동화해줄 수 있는 프로그램을 만드는 게 첫 번째인 것 같고, 두 번째는 만들었으면 공개할 마음이 들어야 하는데요. 혼자서 쓰고 말면 오픈 소스가 아니니까요. 공개할 때는 예전보다 장벽이 줄었습니다. 예전에는 소스를 공개하고 싶어도 어디에 올려야 할지도 막막했었는데 요즘은 깃허브 등 개발자들이 손쉽게 쓸 수 있는 도구나 서비스가 정말 많거든요. 그런데 뭘 올려야 할까 고민하는 사람들은 상대적으로 많지 않은 것 같습니다.
지금보다 열악했던 PC 통신 시절에도 자작 프로그램을 공개, 공유하는 일이 활발했던 것 같은데요.
PC 통신 시절만 해도 오픈 소스란 말도 없었고 저작권 개념도 희미해서 아무도 신경 쓰지 않으니까 그냥 만들어서 올리고 서로 나눠 쓰면 됐죠. 오히려 사람들 입장에서는 훨씬 더 편하게 프로그램을 올리고 주고받았던 것 같습니다. 요즘에는 오픈 소스 프로그램 하나 올리려면 라이선스도 하나 정해야 할 것 같고 기존에 생각하지 않았던 것을 고려해야죠. 그리고 옛날에는 *.c로 된 파일 하나만 만들어서 올려도 사람들이 알아서 가져다 썼는데 요즘은 제대로 된 오픈 소스 소프트웨어를 하나 만들려고 하면 설정 스크립트도 짜야 하고 Makefile 같은 것도 autotools/cmake 같은 걸로 자동화해야 하니 프로그램만 잘 짠다고 되는 게 아니라 빌드 환경이나 배포 환경을 고민해야 합니다. 그런 작업을 해서 올려야지 전문적으로 보이는데 그냥 Makefile 하나, *.c 파일 몇 개 올리면 허술하게 보인다는 생각 때문에 못하기도 하는 것 같습니다.
한국과 미국 업계 모두 경험해 보셨는데 오픈 소스 개발자가 나오는 데 사회적 환경은 어느 정도 영향을 미칠까요?
미국에서도 개발자들을 보면 오픈 소스에 크게 관심 없는 사람도 많습니다. 그런데 일단 여유가 있는데 여유는 개인이 만든다기보다는 사회적인 분위기에 많이 좌우된다고 봅니다. 미국 개발자들은 한국 사람들 관점에서는 너무 자유로워 보이죠. 가끔씩 그냥 집에서 일하겠다고 출근하지 않는 사람들도 있고요. 그러다 보니 회사 일을 하고 나서 근무 외 시간에 투자할 여유가 있는 거죠. 그 시간에 운동하는 사람도 있을 테고 다른 활동을 하는 사람도 있을 테고, 그러다 보면 개중에는 또 프로그래밍을 하는 사람도 있는 거고요. 그러다가 오픈 소스 쪽에 참여한다거나 자기가 뭔가를 만들어서 올리거나 하는 사람도 나오는 거죠. 그런 식으로 되는 것 같습니다. 미국에서는 오픈 소스 사용을 자유롭게 선택하는 사람도 많고 서비스 회사의 경우 인프라는 당연히 오픈 소스로 구성해야 하는 것 아니냐고 생각하는 사람도 많습니다. 더 많이 쓰이고 발전할 수 있는 분위기인 거죠. 그다음에 오픈 소스만 전업으로 하는 사람들이 많습니다. 큰 회사 같으면 자기가 하고 있는 프로젝트를 그냥 회사에서 후원받아서 하는 사람들도 있습니다. 한국도 몇몇 회사에서 리눅스 커널 개발자를 고용하기도 하지만 미국은 한국보다 그 수가 훨씬 많습니다. 허태준 씨도 미국에서 전업으로 일하는 경우고요. 당연히 생산되는 코드량이나 품질이 더 좋겠죠. 실리콘 밸리에서는 몇 다리 건너면 서로서로 알 정도로 좁아서 주위에서 오픈 소스 활동을 하는 사람들도 상대적으로 많이 볼 수 있다 보니까 영향을 더 받습니다.
개발자 사회가 노령화한다는 말이 있는데 실감하시나요?
미국은 원래 나이 든 개발자가 많습니다. 반면에 학교 졸업해서 신입으로 뛰어드는 사람도 있죠. 미국의 경우 나이가 들어도 관리자를 하지 않고, 물론 실력이 있어야겠지만, 자기 분야에서 계속 개발하는 사람이 많습니다. 뉴스에서 많이 봤는데 한국의 경우 유입되는 인력 수가 줄다 보니 예전에 비해서 떨어지는 경향도 있는 것 같습니다. 또 다른 변화로는 ‘30세가 넘어가면 개발하기 어렵다’는 인식이 바뀌고 있는 것 같습니다. 2000년대 초 IT 호황일 때부터 일하던 사람들이 이미 15년 가까이 됐고 그 사람들이 이제 30대 중반~40대인데 어쨌든 한국에서도 예전에 비해 좋은 소프트웨어 회사들이 많이 생기다 보니 그 사람들이 굳이 관리직으로 가지 않아도 자기 특기를 살려서 더 오래 개발할 수 있게 되는 환경이 점점 조성되는 것 같습니다. 그래서 개발자들이 노령화하는 건 좋은 현상이라고 보는데 그 이야기는 자신이 원하는 것이 개발자로 남는 것이라면 은퇴할 때까지 개발을 할 수 있는 환경이 조성된다는 이야기거든요. 물론 신입 개발자가 들어와서 개발을 해서 장래가 어떻게 될 것인지 고민할 때 ‘나이 몇 살이 넘으면 기회가 없다’가 아니라 ‘정말 원하면 개발을 계속할 수 있다’나 ‘선배들이 이미 그 길을 가고 있다’는 걸 보여줘야 하는데 과거에 비해서는 그런 문제에 대해 인식을 하고 개발자 경력을 조성해 주는 회사가 예전보다 더 늘었다고 봅니다. 개발자가 꼭 젊어야 할 필요는 없거든요. 물론 나이가 들면 그만큼 고집도 생기고 최신 기술에 해박하지 않을 수는 있지만 훨씬 더 경험이 많으니까 훨씬 더 안정적인 코드를 시행착오를 덜 되풀이하면서 만들 수 있다는 장점이 있거든요. 그걸 최대한 살려주는 게 옳다고 봅니다.
개발자로서 장수하는 데 필요한 자질은 무엇일까요?
앞서 DevOps 이야기도 했지만 개발자가 단순히 프로그램만 작성하는 게 아니라 빌드, 테스트, 배치까지 고려해야 하는 시대가 왔다고 봅니다. 그다음으로는, 그런 경우를 가끔씩 봤는데, 가령 네트워크 서버 프로그램이라면 프로그램 자체를 잘 짜는 것도 중요하지만 커널 파라미터 한 줄 바꿔서 프로그램 성능이 확 올라가는 경우도 있거든요. 개발자가 운영 체제의 그런 특성을 모르면 자기 프로그램의 성능 한계가 그것밖에 안 된다고 생각하는 거죠. 프로그램 한 줄 고치지 않고 운영 체제 커널 파라미터 한 줄만 고쳐도 성능이 네다섯 배 증가할 수 있는데 말이죠. 개발자라면 자신이 주로 쓰는 운영 체제, 데이터베이스에 대해 어느 정도 자세한 내용까지 알아야 한다고 생각하고요. 특히 성능 측면에 대해서는 프로그램뿐 아니라 프로그램 외적으로 손대서 좋아질 수 있는 게 뭐가 있는지 공부해 나가면 전문성이 점점 올라가잖아요. 단순히 프로그램 코딩이 중요한 게 아니라 자기가 만든 프로그램을 돌릴 운영 체제나 JVM 같은 각종 환경에 대해서는 잘 알아야지 더 빨리 성장해 나갈 수 있는 거죠. 특히 저는 운영 체제 자체를 아는 게 굉장히 중요하다고 보는데요. 리눅스나 BSD는 어쨌든 오픈 소스이니 내용이 궁금하면 소스를 열어볼 수 있고 그런 걸 해보면서 얻는 지식이 훨씬 많으니까 단순히 프로그램만 작성해서는 한계가 금방 오지 않을까 하는 생각이 듭니다.
아이가 나중에 프로그래밍을 배우고 싶다고 하면 지원해 주실 의향이 있나요?
아이가 아직 없습니다(웃음). 프로그래밍 지식은 앞으로 점점 더 필수적이 된다고 봅니다. 굳이 학교에서 가르치지 않는다고 해도 당연히 알아야 하지 않을까 하는 생각이 듭니다. 모든 게 IT화, 소프트웨어화할 텐데요. 아이가 자라서 IT 일을 하지 않아도 자신이 원하는 프로그래밍을 할 수 있는 프로그래밍 언어 한두 개는 알아야 한다고 봅니다. 그게 뭔지는 별로 중요하지 않을 것 같습니다. 자바스크립트만 해도 충분할 것 같고 펄이나 파이썬을 쓸 줄 알면 더 좋을 것 같고요.
가장 큰 영향을 받은 개발자는 누구인가요?
누구라고 딱 집어서 이야기는 못하겠지만 FreeBSD 개발자들을 보면, 이미 주류가 된 리눅스와 달리 FreeBSD는 상대적으로 비주류고 FreeBSD 프로젝트에서 뭘 한다고 해도 다른 사람이 알아주는 게 덜한데요. 그런데도 FreeBSD의 이상에 동의해서 프로젝트를 발전시키기 위해 계속 일하는 사람들이 훌륭하다고 생각합니다. 남들 다 아는 프로젝트에서 일하면 티가 잘 나잖아요. 유명해지기도 쉽고요. 그런데 비주류 프로젝트에서 묵묵히 일하는 사람들을 보면 정말 대단하다는 생각이 듭니다.
자신만의 재충전 방법은 무엇인가요?
멍하게 있는 걸 좋아합니다. 피곤하면 잠도 많이 자고요. 요즘에는 많이 하지 못하는데 게임, 주로 휴대용 콘솔 게임을 많이 했습니다. IT 엔지니어들이 많이 그러는데 뭔가 하다가 막히면 그 자리에서 계속 고민하는 건 별로 도움이 안 되고 일단 손을 떼고 어디 가서 음료수를 마시고 오든지, 시선을 다른 데로 돌리는 것이 중요하다고 보는데요. 그랬다가 다시 오면 아까 하고 있던 고민이 확 사라질 때도 있고, 뭔가 다른 형태로 문제를 해결할 방법이 머릿속에 떠오를 수도 있고요. 저는 중간 중간에 뭔가 막힐 때 기분 전환을 하는 게 개인마다 다를 수는 있겠지만 중요하다고 봅니다.
개발자들은 저마다 관심 있는 서브컬처가 있던데 개발자의 창의력과 서브컬처는 상관관계가 있을까요?
상관관계라기보다는 접하기 쉬운 환경에 있는 것 같습니다. 저도 초등학생 때 8비트 컴퓨터에서 게임이 주 콘텐츠여서 그걸 하면서 자연스럽게 접했고 앞서 말씀드린 것처럼 애플이냐 MSX냐에 따라 미국 게임이냐, 일본 게임이냐 갈라졌고요. 그렇게 일본 문화를 접하다 보면 자연스럽게 애니메이션도 보게 되고 만화책도 보게 되는 쪽으로 가게 되죠. 그런 측면에서 컴퓨터를 시작하게 되면 그런 걸 접하기가 쉬운 환경인 것 같습니다. 요즘에는 대부분 스마트폰을 가지고 다니니 진입 장벽이 없다고 생각하는데 옛날에는 컴퓨터를 갖고 있다는 것 자체가 흔한 일이 아니니까 그런 사람들이 어떤 콘텐츠를 처음 접하느냐가 굉장히 많이 좌우했었습니다.
개발자로서 어떤 모습으로 늙어가고 싶으신가요?
돈이 많아서 느긋하게 오픈 소스 개발을 하면서 살면 좋겠다는 생각도 드는데 쉽지는 않을 것 같네요(웃음). 어쨌든 저는 운이 좋아서 회사에서 남들보다 일찍 임원이 되는 위치에 왔는데 사실 관리자 경력으로 빠지기 시작하면 현업으로 돌아오기 굉장히 어렵습니다. 관리자는 그 나름의 일이 있고 그 일을 하다 보면 직접 뭔가를 하고 싶어도 시간도 부족하고, 코딩도 지속적으로 해야 감이 유지되는데 한 번 흐름을 놓쳐버리면 다시는 손에 잡기가 힘든 때가 오거든요. 저는 그게 싫어서 직책이 뭐든 간에 필요한 도구는 직접 만들 수 있어야 하고, 필요한 데이터 분석은 남들 시키는 게 아니라 직접 할 수 있어야 한다는 마음이어서 조금씩 개발을 하고 있습니다. 그렇다고 제가 회사에 있는 다른 개발자들을 능가할 수는 없으니까, 예를 들면 실제 서비스에 쓰는 것은 만들지 않고요. 그걸 붙잡고 있을 시간도 없고요. 그게 아니라 제가 원하는 데이터를 수집하는 데 필요한 것들은 직접 만들자는 생각으로 조금씩 개발을 하고 있습니다. 그래서 그런 감각을 잃지 않고 계속 유지했으면 좋겠습니다. 한국은 IT 산업이 활성화된 게 오래되지 않아서 정말 나이 많은 개발자들은 거의 없다고 생각합니다. 1990년대 이후로 IT에 뛰어든 사람들이 그대로 늙어가는 상황인데 그 사람들이 5, 6, 70대가 돼서도 프로그래밍을 작든 크든 계속할 수 있을까 걱정이 되기도 하는데 개발을 놓고 싶지는 않은 거죠. 제가 필요할 때 바로 개발할 수 있는 수준이면 충분하다고 생각합니다. 거창한 프로그램일 필요도 없고 간단한 스크립트 언어 한두 개만 쓸 수 있어도 되니까요. 나이가 들어도 그런 감은 잊어버리고 싶지 않다는 생각은 항상 하고 있습니다.
시작하는 개발자들에게 조언 한 말씀 부탁드립니다.
앞서 했던 이야기와 비슷한데 자신이 작성하고자 하는 애플리케이션이 돌아가는 환경을 많이 알아야 합니다. 원하는 로직을 짜는 것도 중요하지만 그게 어떤 환경에서 다른 어떤 애플리케이션과 얽혀 돌아가는지 알아야 하고요. 기본적으로 운영 체제, 프로그래밍 언어에 대해서는 일정 부분의 지식은 항상 지녔으면 좋겠습니다. 저는 그게 항상 첫걸음이라고 봅니다. 리눅스라고 하면 프로그램이 어떻게 구성되어 있고 부팅되면 어떤 과정으로 돌아가고 파일 시스템을 뭘 쓰고 있고 한계점은 뭐가 있고 하는 것들을 어느 정도 이해해야지, 그 위에서 더 좋은 프로그램을 짤 수 있다고 생각하고 또 하드웨어 성능을 최대한 이끌어낼 수 있도록 운영 체제 언저리의 공부를 많이 했으면 합니다. 그런 것들은 한 번 잘 익혀두면 두고두고 쓸 수 있는 지식이니까요. 리눅스라고 해도 본질적으로는 예전 상용 유닉스들과 크게 다를 건 없다고 보거든요. 일단 그런 것을 이해하는 것부터 시작하면 그 후에는 운영 체제의 추가적인 특성을 이해할 때 큰 도움이 되고 그런 내용을 알면 자신이 작성하는 프로그램을 어떻게 하면 더 좋게 만들 수 있을지 방법을 찾아내는 게 가능하다고 봅니다.
나에게 프로그래밍이란?
“삶의 양념이다.” 개발을 해서 먹고살지는 않지만 개발 능력이 있어서 제가 하는 일에 굉장히 많은 도움이 되거든요. 그런 측면에서 그렇게 말씀드릴 수 있겠습니다.
인터뷰이 소개: 최준호
웹데이터뱅크를 거쳐 현재 CDNetworks CTO 겸 퍼포먼스 팀장으로 재직 중이다. 대학 때 리눅스와 FreeBSD를 접한 이래 넷스케이프 브라우저 한글화, GNU 번역 프로젝트 및 관련 유틸리티(nh2ps, nhppf)를 오픈 소스로 만든 바 있으며, 2000년에서 2010년까지 FreeBSD의 포트 커미터(cjh@)를 맡아서 korean 카테고리의 한글 관련 프로그램의 패키징을 주로 진행하였다. 현재 회사에서는 운영과 개발 부서를 각각 번갈아 담당했으며 요즘은 CDN과 애플리케이션 딜리버리 네트워크의 성능 향상을 위한 데이터 모니터링 및 분석 작업을 진행하고 있다.
허준회 - 더 나은 세상을 위한 소통
