지금은 분업이 많이 이뤄졌지만 유닉스 초창기에는 뛰어난 개발자는 뛰어난 관리자일 정도로 개발과 시스템 엔지니어링은 밀접한 분야였습니다. 이번 인터뷰에서는 시스템 엔지니어로서 개발에 깊은 관심을 갖고 실제로 여러 오픈 소스 개발을 하는 김정균 님을 만나보았습니다.
김정균 | 네오위즈 게임즈 시스템팀 시스템 엔지니어
oops.org에 올라가 있는 프로필에서 '인터넷 몰라도 사는 데 지장이 없다고 생각하던 아이가 인터넷으로 먹고 살고 있다'는 내용을 보았는데 어떤 계기로 이 일을 시작하셨나요. 원래는 3D 디자인을 했습니다. 회사도 만들었는데 IMF를 맞는 바람에 잘 되지 않았습니다. 렌더링용으로 당시로서는 슈퍼컴퓨터라 부를 만한 사양의 PC가 대여섯 대 있었는데 그 장비로 할 일이 없어져 버렸습니다. 마침 천리안 네트워크 동호회에서 활동하던 시절이라 그 장비들을 P2P 연결도 해보고 윈도 서버 구축•공유 같은 작업도 해보다가 사설 BBS를 만들고 MUD 게임을 돌려보려고 리눅스를 공부하게 됐고 여기까지 오게 됐습니다. 엄밀히 말하면 우연찮게 발을 들여놓은 것이 직업이 된 셈입니다. oops.org도 원래 하던 일이 그래픽 쪽이니 2D도 할 수 있겠다 싶어 홈페이지를 만들게 된 것이고요.
홈페이지에 올리신 이력을 보면 ‘궂은 일’도 상당히 많이 하셨는데 자신에게 어떤 도움이 됐다고 보시나요. 이런 저런 경험을 많이 한 것은 사실입니다. 갖가지 트러블슈팅을 해봤습니다. 1990년대 말 프리랜서 시절 60여 대 서버를 혼자 관리, 운영해 보기도 했죠. 그런 경험이 어느 정도 도움이 되기는 했는데 그게 다는 아닌 것 같습니다. 그냥 경험으로 끝나는 게 아니라 호기심을 갖고 탐구하고 노력하는 게 더 크지 않았나 합니다. ‘왜’라는 질문을 항상 하면서 이유를 알기 위해 파고들었으니까요. 단순히 열심히 하는 것만으로는 어느 순간 막힐 때가 있는데 그걸 넘어서는 데 호기심이 많은 도움이 됐습니다.
우연히 발을 들여 놓은 게 벌써 10년째인데 지난 시간을 돌아볼 때 이 일을 하기로 한 결정에 대해 어떻게 생각하시나요. 나쁜 결정은 아니었습니다. 시스템 엔지니어가 상대적으로 덜 인정 받고 중요성이 제대로 인식되지 않는 일이기는 하지만 오히려 그로 인해 지금 위치까지 올 수 있지 않았나 합니다. 재미도 있고 적성에도 맞는 것 같습니다.
개발은 어떻게 시작하셨나요. 솔직히 말하면 시스템 엔지니어가 된 것은 개발을 잘 못해서였습니다. 늘 C의 포인터를 벗어나지 못했습니다. (웃음) ‘난 자질이 없나 보다’라고 생각했죠. 당시에는 시스템 엔지니어라는 직군이 명확하게 있지 않았고 개발자들이 모든 걸 다 하는 경우가 많았는데 가만히 보니 이 일이 틈새 시장이라는 생각이 들어 더 파고들게 된 것입니다. 그러다 연차가 차고 나서 엔지니어에게도 개발 능력이 필요하다는 걸 절실히 깨닫고 뒤늦게 개발 공부를 다시 시작하게 됐습니다. 정말 죽으라 공부하니 되더군요. (웃음)
oops.org의 대표작 중 하나가 안녕 리눅스입니다. 안녕 리눅스를 처음부터 다시 만든다면 어떻게 개발하시고 싶은가요. 1.x 때 시행착오가 많았습니다. 리비전 업그레이드하면서 여기 저기 잔뜩 뜯어고치기도 했고요. 지금에 비하면 당시에는 시야가 좁았던 것 같습니다. 다시 만들더라도 방향성은 바뀌지 않겠지만 몇 가지 개선하고 싶은 부분이 있습니다. 커널이 그 예인데요. 현재 안녕 리눅스 커널은 안녕 리눅스의 기반이 된 레드햇 커널과 많이 달라 관리하기가 좀 힘듭니다. 전업으로 안녕 리눅스 개발만 한다고 해도 커널 개발자가 함께 해야 하고요. 가장 좋은 방법은 레드햇 커널을 따라가는 것이었는데 그 때는 그렇게 하지 못하고 리눅스 커널 2.6의 기능을 2.4로 백포팅하는 등 중노동(?)을 해야 했습니다. 약간 후회되는 부분입니다.
안녕 리눅스 구 버전도 오래 지원하시는 걸로 알고 있습니다. 전업이 아닌 이상 배포판 개발만도 빡빡할 것 같은데 구 버전 지원이란 부담은 어떤 식으로 해결하시나요. 크게 어렵지는 않습니다. 어차피 제가 관리하는 서버들을 업데이트하는 차원에서 하는 일이라서요. 제가 개발하는 JS보드도 비슷한 경우인데 10년 가까이 잘 개발됐던 건 제가 쓰기 때문입니다. 요즘은 좀 뜸하지만 한창 때는 거의 매달 리비전이 올라갔으니까요. 다만 제가 잘 쓰지 않게 되면 업데이트가 뜸해진다는 게 단점입니다. (웃음)
안녕 리눅스의 로드맵은 어떻게 되나요. 배포판 개발에 필요한 개발 서버를 구하기 쉽지 않아 계속 미뤄지다가 어렵사리 서버를 한 대 지원 받았는데 지금은 시간을 내질 못해 작업을 하지 못하고 있습니다. 현재 센트OS 5 기반으로 안녕 리눅스 2.x에 들어갈 요소와 패키지 구성에 대한 구상은 끝난 상태입니다. 빌드하는 데 몇 달 걸릴 것 같고 인스톨러 고치는 데는 시간이 더 필요합니다. 안녕 리눅스 2.x는 방화벽이나 VPN 장비로 간단하게 쓸 수 있게 하는 것이 목표입니다. 설치 용량은 100MB 정도, 설치를 끝내자마자 방화벽이나 VPN이 동작하게 하는 것이죠. 안녕 리눅스 1.x에서도 가능하지만 따로 설치, 세팅해야 합니다. 2.x에서는 인스톨러에서 기본으로 해당 기능이 설치되고 방화벽 모드 또는 VPN 모드 선택으로 바로 쓸 수 있게 하려 합니다.
안녕 리눅스 외에도 여러 가지 오픈 소스 소프트웨어의 패치를 유지 보수하시는데 어찌 보면 지겨운 작업을 꾸준히 하시는 동기는 무엇인가요. 자기 계발과 제가 하는 일을 알리고 싶어서입니다. 이 분야에서 일하다 보면 ‘천재’들을 보게 되는데 저는 그런 천재는 아니라서 천재를 따라가려면 열심히 노력하는 수밖에 없습니다. 그래서 재미있어서 ‘삽질’을 한다는 사람들을 보면 가끔 부러울 때가 있습니다. (웃음) 일하면서 두 가지 철칙을 지키려 하는데 하나는 책임입니다. 다른 사람이 제게 일을 맡길 때 신뢰를 주는 것이고 두 번째는 제 스스로에게 부끄럽지 않아야 한다는 것입니다. 제가 뭔가를 일을 벌이고 도망가 버린다든지 하면 안 되겠죠. 안녕 리눅스는 한국 내에서도 사용자 층이 전체 1%도 되지 않을 겁니다. 그렇지만 그런 배포판을 쓰는 사용자들이 있고 그 사용자들의 기대를 저버리지 않아야 한다고 생각합니다. 이런 점이 제가 맡은 소프트웨어를 꾸준히 유지 보수하는 원동력이 아닐까 합니다.
시스템 엔지니어링 업무는 시기별로 어떻게 변화해 왔나요. 제 경우에는 초창기에는 세팅 레벨 수준 트러블슈팅이 많았고 좀 지나고 나서는 ‘이럴 때는 저런 제 좋더라’라는 걸 파악하기 시작했습니다. 당시에는 이론에 대해 잘 알지 못해서 경험으로 익혔던 것 같습니다. 예를 들어 서비스 별로 적합한 API를 써서 리스너를 구현해야 하는데 그러한 이론을 잘 모를 때는 무턱대고 해보고 ‘왜 안 될까’하며 고민하던 때가 있었습니다. 개발을 하면서부터는 커널이나 API의 특성을 이해하게 됐고 좀 더 다양한 상황의 트러블슈팅이나 시스템 구축을 할 수 있게 됐습니다. 그러다 시스템 한 대를 넘어 네트워크 레벨을 다루게 됐습니다. 요즘은 시스템 간 통신이 많다 보니 네트워크 단에서 생기는 문제를 빨리 찾아내는 게 중요해졌기 때문입니다. 성능 조율의 경우 하드웨어 성능과 기본 커널 설정이 좋아져 예전보다 작업 거리가 줄어든 것 같습니다.
시스템 운영 관리에서 사람의 개입을 최소화하는 자동화는 어디까지가 적당할까요. 단순 반복 작업을 자동화하는 것은 중요하지만 장애가 났을 때 문제를 찾을 수 없을 정도로 지나치게 자동화해 버리는 것은 좋지 않다고 봅니다. 사람이 판단을 해야 하는 요소는 보기 쉽게끔 만들어야지, 보지 않도록 만드는 것은 부적절하다고 생각합니다. 즉 번잡한 작업은 최소화하되 사람이 관여하는 부분은 일정 정도 필요하다는 의견입니다. 또 장애가 났을 때도 “그냥 자동으로 복구하면 되지”보다는 “다음에는 장애가 나지 않도록 해야지”하는 태도가 좋겠고요.
대규모 마이그레이션을 하시기도 했죠. 그 일을 하고 나서 달라진 게 있다면… 새로운 영역에 눈을 뜨게 됐습니다. 당시 인력이 많이 바뀌면서 혼자서 많은 서버를 관리해야 했습니다. 문서에 이력이 잘 정리되어 있었지만 너무 자세하게 되어 있다 보니 현재 상태를 파악하기 힘든 역설적인 상황이 됐습니다. 작업을 효율적으로 하기 위해 문서를 현재 상태 위주로 기록하도록 바꾸고 운영체제 배포판을 통일하고 중앙 저장소를 두고 바이너리 패키지를 쓰도록 바꾸었습니다. 그 전까지는 주로 트러블슈팅에 자신 있었고 재미를 느꼈는데 마이그레이션 작업 과정에서 ‘어떻게 관리할 것인가’와 아키텍처적인 부분으로 관심이 바뀌었습니다. 시스템 엔지니어의 기본기 중 하나가 아키텍처임을 깨달았습니다. 특히 LISA라는 컨퍼런스에 참석하고 나서 그에 대해 더 확신이 생겼고 제대로 된 시스템 엔지니어가 되려면 여기서 안주하면 안 되겠다는 생각이 들었고 요즘에는 학문적이고 이론적인 부분에도 관심을 좀 더 두고 있습니다.
그 동안 해온 작업 중 기억에 남는 것들은 무엇인가요. 우선 안녕 리눅스입니다. 가장 짧은 기간에 가장 많은 노력을 쏟아 부었습니다. 즉흥적인 스타일이라 일하면서 고민을 거의 하지 않는데 안녕 리눅스를 만들면서는 고민도 많이 했습니다. 제가 만든 것 중 개인적으로 유용하게 잘 쓰는 건 oops firewall입니다. 회사에서 했던 일 중에서는 보름 만에 다운로드 서버 개선, 배포 시스템 신규 개발을 했던 것이 기억에 남습니다.
자신이 생각하는 시스템 엔지니어의 표상은 어떤 모습인가요. 커널 개발자 앨런 콕스입니다. 앨런 콕스의 커널을 보면 시스템 엔지니어로서 ‘이런 게 있으면 좋겠다’하는 것들이 잘 반영되어 있습니다. 사실 리눅스 배포판의 패키지들 중에는 시스템 엔지니어가 개발한 것들이 더러 있거든요. 그런 측면에서 보면 시스템 엔지니어링의 영역에 시스템 운영에 필요한 개발 작업이 들어갈 수밖에 없다고 봅니다. 결국 개발 능력이 있는 사람이 자신의 적성이나 관심에 따라 소프트웨어 개발 또는 시스템 엔지니어링으로 나뉘는 것도 좋다고 봅니다. LISA에서 논문을 발표하던 엔지니어 중에는 개발을 하다 시스템 엔지니어링으로 옮긴 사람들이 있었는데 매우 인상적이었습니다. 미국의 경우 그런 노력들이 쌓여 시스템 엔지니어링이 학문으로 형성되는 과정에 있는 게 아닐까 생각합니다.
개발을 할 줄 아는 게 실제 소프트웨어 개발부서와 함께 일할 때 어느 정도 도움이 되나요. 개발자들을 설득해야 할 때 개발 지식이 있는 게 도움이 많이 됩니다. 예를 들어 다운로드 서비스용 데몬을 만들 때 보통 개발팀에서 멀티쓰레드 기반으로 개발하려고 하는데 실제 시스템에서는 CPU를 많이 쓰는 작업이 아니라면 싱글쓰레드 기반 데몬이 서버를 더 효율적으로 사용합니다. 이 내용을 개발자들에게 납득시키려면 시스템 엔지니어가 해당 지식을 잘 알아야 하고 그에 따른 벤치마크 결과 같은 자료를 제시할 수 있어야 하니까요.
마지막으로 가벼운 질문 하나 드리겠습니다. 체력 관리는 어떻게 하시나요. 하려고 합니다. (웃음) 10년 가까이 운동을 하지 못했더니 체력이 많이 떨어졌습니다. 전날 늦게까지 일하면 그 다음날 아침에 일어나는 것이 너무 힘들더군요. 이러다 쓰러질지도 모른다는 경각심이 느껴져 운동을 시작하려고 합니다.
[김정균 소개] "인터넷 몰라도 사는 데 지장이 없어" 하고는 절대로 인터넷을 배우려 하지 않던 아이가 이제 인터넷 업계에서 일하고 있다. 세상엔 그만큼 희한한 일이 많다.
oops.org에 올라가 있는 프로필에서 '인터넷 몰라도 사는 데 지장이 없다고 생각하던 아이가 인터넷으로 먹고 살고 있다'는 내용을 보았는데 어떤 계기로 이 일을 시작하셨나요.
원래는 3D 디자인을 했습니다. 회사도 만들었는데 IMF를 맞는 바람에 잘 되지 않았습니다. 렌더링용으로 당시로서는 슈퍼컴퓨터라 부를 만한 사양의 PC가 대여섯 대 있었는데 그 장비로 할 일이 없어져 버렸습니다. 마침 천리안 네트워크 동호회에서 활동하던 시절이라 그 장비들을 P2P 연결도 해보고 윈도 서버 구축•공유 같은 작업도 해보다가 사설 BBS를 만들고 MUD 게임을 돌려보려고 리눅스를 공부하게 됐고 여기까지 오게 됐습니다. 엄밀히 말하면 우연찮게 발을 들여놓은 것이 직업이 된 셈입니다. oops.org도 원래 하던 일이 그래픽 쪽이니 2D도 할 수 있겠다 싶어 홈페이지를 만들게 된 것이고요. 
