DBMS 개발자

오랜만에 쓰는 <고수를 찾아서> 일곱번째 인물은 김성진 알티베이스 팀장이다. 그는 데이터베이스관리시스템(DBMS) 개발자다. 잘 모르는 이들은 “우리나라에도 DB개발자가 있었느냐?”고 물을 수 있겠지만 그는 10년전에도 DB개발자였고 지금 또한 마찬가지다.

DBMS는 오라클과 마이크로소프트로 대표되는 다국적 SW기업들이 사실상 독과점하는 분야다. 기술적 진입장벽이 매우 높을 뿐더러 선도업체와 후발주자들을 바라보는 외부의 시선도 큰 차이가 한다. 오라클이나 마이크로소프트 그리고 IBM 등 이른바 DBMS 업계 ‘빅3’는 그래서 이름값만으로도 ‘반은 먹고’ 들어간다.

그래서 국내 업체들이 DBMS 한다고 하면 ‘오라클이 있는데, 과연 되겠어!’란 불신이 꼬리표처럼 붙어다닌다. DBMS가 갖는 기술적인 난이도를 고려하면 당연한 반응이다. 그러나 이런 가운데서도 DBMS 한번 만들어보겠다고 뛰어든 무모한(?) 국내 업체들이 있다. 큐브리드와 티맥스소프트가 그렇고, 김 팀장이 몸담고 있는 알티베이스도 대표적이다.

알티베이스는 지금부터 10년전 메인메모리 DBMS(MMDBMS)로 데뷔했고 얼마전부터는 오라클이 주도하는 디스크 기반 관계형 DBMS(RDBMS)로도 영토를 확장했다. 메모리 DB시장은 선도 업체로 올라섰고 RDBMS쪽에선 ‘오라클의 대안’임을 부르짖고 있다.

메모리DB란?
메모리DB는 관계형 DBMS(RDBMS)에 비해 대용량 데이터 저장 능력은 떨어지지만 디스크가 아닌 메모리에 데이터를 저장, 데이터를 빠르게 처리를 할 수 있다. 때문에 실시간으로 데이터를 소화해야하는 증권사 시세조회 서비스나 통신 서비스 분야 등에서 쓰이고 있다.

김성진 팀장은 알티베이스 창업 멤버중 한명으로 결코 쉽지 않았던 DBMS 시장에서 파란만장했던 회사의 고군분투를 직접 보고 경험해왔다. 그런만큼, 지난 과거에 대해 할말이 많다. ‘맨땅에 헤딩’하는 심정으로 시작해 자리를 잡기까지 개발자로서 별의별 고생은 다해봤다. “그 고생 다시하라면 돈을  뭉터기로 안겨준대도 절대로 못할 것”이라며 손사래를 친다.

김 팀장과 진행했던 인터뷰 내용을 풀어놓으려 한다. 그와 나눈 대화의 절반 가까이는 알티베이스가 치른 ‘말로는 다할 수 없는’ 고생담이다. 백문이 불여일견. 바로 본론으로 들어간다. 깜냥이 부족해 기술적으로 잘 이해가 되지 않았던 부분은 제외했음을 밝혀둔다. 배경 지식이 좀 더 있었다면 김 팀장이 겪었던 시행착오를 좀 더 실감나게 풀어쓸 수 있었을텐데…

10년이 넘게 DBMS 개발에 몸담고 있는데, DB 개발자로 나선 계기는 무엇인가요? 우리나라에서 DB개발자는 흔치 않은 직종으로 분류되는 편인데요.

대학때 전공은 생명공학이었습니다. 그런데 전공보다는 컴퓨터가 좋았어요. 학과공부보다는 컴퓨터 동아리에서 살았습니다. 당시만 해도 프로그래밍은 많이 해봤지만 DB와는 인연이 없었어요. DB를 접하게된 것은 대학원에 진학하면서부터였습니다. 컴퓨터과학으로 석사 과정을 밟게 됐는데, 지도 교수님이 90년대 중반 국가에서 추진하는 ‘바다’라는 DBMS 개발 프로젝트에 참여하고 있었습니다. 이 분이 제 프로필을 보더니만 ‘DB 하자’고 하더라고요. DB를 다루게된 건 그때부터입니다. ‘바다2’를 쓰레드(thread)화하는 작업을 담당했고, 졸업 논문도 이걸로 썼어요. DB를 쓰레드화하면 자원을 적게 쓰면서도 속도는 빠르게 할 수 있습니다.

학교에서 DB공부를 했더라도 당시 우리나라 상황이 DB 전문 개발자들을 흡수할만한 상황은 아니었을 것 같은데요. 국산 DBMS 기업들도 없었고요.

졸업하고 지금의 KT가 투자한 벤처기업에 입사했어요. 그런데 제가 생각했던 벤처기업과는 회사 문화가 많이 다르더라고요. 벤처라고 하면 리스크는 물론 성과도 공유하는 것이라고 생각했는데, 첫 직장이 그렇지는 않았습니다. 그러고 있는데 ‘바다’ 프로젝트를 함께 했던 한국전자통신연구원(ETRI)에서 아는 분으로부터 연락이왔어요. 아는 사람이 메모리 DB 사업을 하려고 하는데, 한번 같이 해보지 않겠느냐는 것이었죠. 바로 알티베이스였죠. 처음에는 망설였어요. 직장 옮기는 게 쉽지는 않잖아요? 그런데 김동일 이사(현 알티베이스 전무)로부터 메모리DB에 대한 설명과 회사 성장 모델을 들어보니 마음에 들었습니다. 입사했죠. 그게 99년인데, 그때부터 지금까지 쭉 DB만 해오고 있습니다.

입사하고 나니 회사가 본인이 생각한대로 움직였나요? DB라는 특성을 감안하면, 적지않은 시행착오를 겪었을것 같은데요.

그랬습니다. 진입장벽이 생각한 것보다 높았어요. 미리 알았다면 시작도 안했을 겁니다. 직접 개발하려고 하니 장난이 아니었어요. 입사전에는 “ETRI에서 개발한 ‘메모리알티’란 프로젝트가 있으니, 안정화만 하면 바로 상용화할 수 있다”고 들었거든요. 그래서 금방 될 줄 알았습니다. 그런데 들어와서 소스코드를 보니 2만5천~3만라인이나 되는거에요. 통신 모듈이나 쿼리 프로세스도 없었어요. 제품이라고 할 수 있는 상황이 아니었습니다. 그래도 나이가 젊어서인지 ‘패기로 개발하면 되겠지’했어요.

의욕만 갖고 후배들 꼬드겨(?) 회사에 입사시킨 뒤 그때부터 함께 개발에 들어갔습니다. 그렇게 해서 2000년 9월께 메모리 DB 첫 제품인 ‘스피너1.0’을 내놨어요. 자랑스러웠습니다. 삼성전자에 제품을 공급까지 하고나니 될 것 같다는 생각도 들었습니다. 그런데 제품 공급하고 몇시간뒤에 고객으로부터 급하게 연락이 왔어요. ‘시스템이 죽어버렸다’는 겁니다. 당시만 해도 지원팀 같은게 있었겠어요? 제가 달려가 고쳐야 했죠. 그런데 고쳐놔도 죽는다는 거에요. 클라이언트가 하나, 둘일 때는 속도가 빨랐습니다. 그런데 50개 정도 붙이니 하나일때 성능의 100분의 1도 안나왔어요. 지금이야 잘 아는 사안이지만 당시만 해도 우리가 초보이다보니 모르는 것 투성이였습니다. 하나씩 하나씩 배워갈수 밖에 없었습니다. DB는 시스템SW입니다. 응용 프로그램 짜는 것과는 패러다임이 완전히 달라요. 그때 느꼈던 게 ‘테스트를 제대로 해야 한다’는 것이었습니다. 알티베이스 DB에 테스트 프레임워크나 버그 관리할 수 있는 인프라를 구축한 것도 그때 경험으로 얻은 거에요.

시스템SW였기에 시행착오가 상대적으로 많았다는 생각도 듭니다. DB와 응용 애플리케이션 개발의 차이는 무엇이라고 보는지요?

DB는 ‘종합예술’이라고 부릅니다. 구문을 날리고 쿼리를 다루는 프로세스는 알고리즘 수학의 집합이에요. 엄청나게 공부를 해야 합니다. 어떤 전문가는 지구상에서 쿼리 프로세스를 모두 이해하는 사람은 아무도 없을 것이라고 말할 정도입니다. DB는 또 복구가 가능해야 하는데, 이 부분이 매우 복잡합니다. 차원이 매우 높다고나 할까요? 이런 기술은 절대 공개들 안하죠. 그런 점에서 오라클이 대단하다고 느낄 때가 많습니다. 알티베이스도 알아서 배운 거에요. 초창기 시행착오를 많이 겪었던 것도 바로 이 때문입니다. 참고할 만한 게 전무한 상황이었습니다.

알티베이스는 지금 메모리DB와 디스크 기반 DB를 모두 제공하고 있습니다. 기술만 놓고 볼 때 오라클 대비 경쟁력은 어느 정도라고 평가하나요?

메모리DB는 우리가 2~3년 정도 앞서 있다고 자신합니다. 오라클의 ‘타임스텐’보다 성능도 빠르고 안정적입니다. 쓰기도 편하고요. 타임스텐은 지금 국내 시장에서 범용적으로 쓰인다기보다는 한정된 분야에서만 사용되고 있어요. 디스크DB는 ‘오라클7’과 ‘오라클8’ 중간 정도로 보고 있습니다.(오라클은 11g까지 나와 있다.) 디스크 기반 RDBMS는 개발자나 관리자들이 많이 쓰는 기능을 오라클보다 더 좋게 만들자는 데 집중하고 있습니다. 사용 빈도가 높은 기능은 오라클에 준하거나 뛰어넘자는거죠. 최신 버전 ‘알티베이스5’에는 이런 개념이 담겨 있습니다. 그래서 ‘오라클의 대안이 되자’는 슬로건도 내걸었죠.

경쟁력을 좀 더 강화하기 위해 풀어야 할 과제는 어떤 것들이 있습니까?

물론 개발자로서 아쉬운 점이 있습니다. 오라클이나 IBM에도 시스템 SW를 제대로 할 줄아는 한국 개발자들이 있을거에요. 이런 분들이 한국에 와서 컨설팅도 하고 분위기도 이끌어주면 좋을 것 같다는 생각을 하곤합니다. 이런게 프로세스이자 문화거든요. 미국에 가보면 개발자들 나름의 문화가 있어요. 개발 프로세스, 자질, 경력, 이런 것들에 어떤 ‘문화’가 있는데 우리는 그런게 너무 없습니다. 사람은 우수한데, 뭘 제대로 하려고 하니 방법론이나 경험이 너무 부족한 거에요. 알티베이스도 7~8년 시행착오 겪으면서 만든 나름대로의 문화가 있습니다. 코딩 가이드나 버그 DB는 이런 문화의 결과물입니다. 우리 회사 개발자들은 회사를 나가도 이런 문화를 사용할 수 있습니다. 알티베이스가 아직 크게 드러나지는 않았지만 국내 시스템SW 분야에서 씨앗 역할을 할 수 있지 않을까 싶어요.

국내 DBMS 개발자 현황은 어떻습니까? 인력 수급이 만만치 않을 것 같다는 생각이 드는데요.

정확히는 모르겠어요. 석사 논문쓰는 사람까지 합치면 몇백명 될 것 같다는 생각은 듭니다.

한떄 관심을 모았던 ‘바다’ 프로젝트가 성과를 못낸 이유는 무엇이라고 보나요?

바다 프로젝트에 참여했던 사람들은 당시만 해도 다들 수재들이었어요. 인력도 적지 않았습니다. 모두가 머리좋고 논문도 잘 이해했어요. 그러나 아는 것과 제품을 만드는 것은 차원이 다른 문제입니다. ‘바다’의 문제도 이론은 잘 알았지만 경험이 너무 부족했던 것 같아요. 소스를 보고 있으면 시스템 소프트웨어에 맞도록 구조화돼 있다거나 하는 생각은 들지 않았거든요.

DB개발자로서의 전망은 어떻게 보나요? 또 후배 개발자들 만나면 주로 어떤 얘기들을 하는 편입니까?

사람들이 알티베이스를 잘 모르고 시스템SW를 개발한다는게 어떤 의미인지 정확하게 모른다는 느낌을 받을 때가 많습니다. 우리의 IT역사와도 연관성이 있겠죠. 미국의 경우 웹관련 기업부터 시스템SW업체들까지 아주 많습니다. 선택의 폭이 넓은거죠. 그러나 우리는 대학 졸업하면 선택의 여지가 거의 없습니다. SI가 대부분이에요. SW 개발업체들도 당장 돈을 벌어야하니 모바일이나 웹으로 갑니다. 이런 와중에도 알티베이스나 티맥스같은 회사가 있다니까 이런게 있구나 하는 생각들은 좀 하는것 같아요. 모든 개발자들이 웹을 하고 싶어하는 것은 아니에요. 시스템SW를 하고 싶은 사람들도 있습니다. 있는데, 기회가 별로 없는거에요. 그러다보니 웹과 ‘자바’쪽에 너무 치우치는거죠. 후배들 보면 ‘자바’를 하는 것은 좋은데, ‘자바버추얼머신(JVM)’ 분석같은 것도 해야 한다고 말해요. 기반 기술에 대한 이해는 많이 하는게 좋거든요.

팀장으로서 채용에도 관여하실텐데요, 개인적인 개발자 채용 기준은 무엇입니까?

그 전에는 면접볼 때 학교 보고 인성보고 그랬는데, 저는 시각이 달랐습니다. 시스템SW를 개발하려면 좀 더 깊게 알아야 한다고 생각하거든요. 어려운 주제를 주고 그것을 풀어내는 지를 봐야 한다고 생각하는 편입니다. 알티베이스 요즘 시험을 칩니다. 결과를 보면 이 사람이 아는지 모르는지 알 수 있어요. 모른다고 해도 문제를 해결하는 능력을 파악할 수 있습니다. 요즘들어 추세가 좀 더 이런 쪽으로 가는거 같아요. 미국이나 일본에선 이미 이렇게 하고 있습니다. 가혹하다는 생각이 들 정도에요. 머릿속까지 들어가서 파내려고 하는거죠.

명함을 보니 아키텍트라는 타이틀이 보이는데요. 아키텍트로서 내부에서 어떤 역할을 하고 있습니까?

아키텍트란 직함이 모호한 구석이 많습니다. 우리나라에서 애플리케이션 아키텍트를 활용하면서 거기에 대해 컨센선스를 이루는 조직이 거의 없어요. 그러나 애플리케이션 아키텍트는 매우 중요합니다. 개발자들은 고집이 있어요. 원하는 대로 가려고 합니다. 때문에 제품 전체를 보고 개발자들의 업무를 가이드해주는 아키텍트의 역할은 필수적입니다. 개인적으로 아키텍트가 훌륭하면 좋은 제품이 나온다고 생각하고 있습니다. 아키텍트는 일반적인 아키텍트와 마이크로 아키텍트로 구분하는데, 통상 아키텍트라고 하면 높은 수준에서 제품을 구상하는 것입니다. 중간에 과정이 변경되더라고 큰 구조는 변화가 없도록 설계하는게 아키텍트입니다. 마이크로 아키텍트는 개발자로 보시면 되요. 자기가 할당받은 부분을 자유의지를 갖고 만드는거죠.

우리나라에서 아키텍트가 부족한 이유는 무엇입니까?

우리나라는 개발자로서 라이프 사이클이 너무 짧습니다. 개발자들이 꽃을 피울 수 있는 나이가 30대 후반에서 40대 초반이에요. 전문가가 되려면 수많은 상황과 문제에 대해 나름의 도를 터득해야 하는데, 그러려면 이 정도 나이는 되어야 해요. 이게 보편적입니다. 그런데 우리나라는 이런 게 생기기도 전에 서른다섯살이면 개발자 경력이 끝날때가 많습니다. 왜 이렇게 됐을까요? 한국 회사들의 직무가 독특하기 때문 아닐까 싶어요. 개발자 아니면 관리자잖아요?

개발자로 시작해 이제 아키텍트 임무를 수행하고 있습니다. 경력 관리측면에서 앞으로의 계획은 무엇인지 궁금합니다.

하다보니 아쉬운 게 뭐냐면 고객들의 요구를 반영해서 제품을 만들어줄 수 있는 사람이 필요하다는 거에요. 이런 사람을 보통 프로덕트 매니저라고하는데 IT쪽 개발 경력이 5~10년 정도되고, MBA도 했던 사람들에게 어울리는 분야입니다. 개인적으로 갈 수 있는 커리어패스로 보고 있습니다. 이제 국내 기업들도 시장을 포착할 수 있는 개발자들을 양성해야 합니다. 한국과 이스라엘 회사와 차이가 뭐냐면 우리는 남들이 많이 하는 것을 하려는 반면 이스라엘은 남들이 안하는 것을 하려 한다는 점입니다. 이스라엘에서 이른바 ‘대박’을 터뜨리는 기업이 나오는 이유라고 생각합니다. 우리도 이렇게 되려면 프로덕트 매니저가 잘해줘야 할 것 같다는 생각을 하고 있습니다.

출처: http://www.bloter.net/archives/2732