“클라우드 시스템 모니터링으로 다시 날고 싶다”

[김성조 와탭랩스 CTO] ‘성장’을 기준으로 나의 길 정해 … IT 발전할수록 기본이 중요

시스템 모니터링 솔루션 분야의 국내 최고 전문가 가운데 한 명으로 인정받고 있는 김성조 씨. 그가 와탭랩스(whatap.io)라는 클라우드 기반의 시스템 모니터링 서비스 업체의 CTO로 갔다는 뉴스가 나왔다. 김 CTO 덕분인지 와탭랩스는 2016년 한국데이터진흥원이 주관했던 DB-STARS 프로그램에서 클라우드 시스템 모니터링 서비스로 1등을 차지하면서 주목을 받고 있다. “잘한다고 자신에게 격려하고 IT를 좋아하려고 노력했다”는 김 CTO를 만나 데이터 관리 영역에서 개발자로 걸어온 길과 최근 국내에서도 본격적으로 도입되고 있는 클라우드 시스템에 대하여 이야기를 나눴다.

▲ 김성조: 와탭랩스 CTO

어떤 계기로 모니터링 솔루션과 인연을 맺었나.

첫 직장이었던 LG-CNS에 입사해 ‘파워빌더’라는 도구로 시스템 통합 프로젝트에 참여했던 것이 계기가 됐다. 부산 동서대 학사행정 시스템 구축 프로젝트였다. 신입사원이라서 프로젝트 룸 세팅부터 시작했는데 소위 ‘나이스하게 시작하여 나이스하게’ 끝난 프로젝트였다. 6개월 정도 이 프로젝트에서 하루에 18개의 화면까지 만들어 낼 정도로 일을 해냈다. 심지어 라벨 프로그램은 30분 만에 만들어 내기까지도 했다.

프로그램 실력을 인정받은 상태에서 입사했었나.

아니다. 당시 개발자나 학생들 사이에 유행했던 [마소]라는 개발자 잡지를 보면서 좌절을 하곤 했던 그저 그런 실력이었다. 컴퓨터 공학도인 내가 상상할 수 없던 수준의 코드를 생물학도 등 비전공자들이 해내는 것을 많이 봤다. 나중에는 내 자신이 너무 위축되는 거 같아서 ‘내가 좋아서 하는 거다!’라고 자신을 세뇌시키곤 했다. 첫 직장에서 일을 시작했을 때인 2000년대 초, 자바가 한창 뜨고 있었다. (자바를) 처음 받아들였던 사람들보다는 3~4년 늦은 상태였다. 당시 주택은행(국민은행에 통합됨) 자바 파일럿 프로젝트에 참여할 수 있었던 게 행운이었다. 70여 명이 2년 동안 참여했다. 그 프로젝트를 진행하면서 디자인패턴, 개발 프레임워크, 소프트웨어 아키텍처 등을 체계적으로 연구하여 그 이후로 몸담고 있던 SI 업체는 엄청난 힘을 발휘하게 되었다. 이게 밑거름이 되어 생산성과 성능을 체계적으로 접근하는 SI 프로젝트들이 이뤄졌다. 당시, 개발 업계에서 자바로 전환하기에는 시기상조라는 의견이 많았다. 하지만 지금 와서 보면 당시 주택은행의 과감한 결정이 금융계 전산화에는 막대한 영향을 미쳤다고 본다.

일반인들에게 알려질 정도로 유명한 시스템 모니터링 솔루션 공급사의 창업 주역이었는데 다시 친정 회사로 돌아갔던 이유가 있었나.

3~4년간 시스템 모니터링 솔루션 개발 일만 하다 보니까 개발자로서 정체되는 느낌이 들었다. 전 직장이었던 SI 업체에서 일할 때는 3년마다 크게 성장하는 느낌이었는데 그런 경험을 할 수 없어서 이직을 결정했다. 얘기나 나온 김에 ‘성장’에 대한 나름의 경험 얘기를 하고 싶다. 앞서 소개했던 주택은행 파일럿 프로젝트가 끝나자 2004~2005년 사이에 LG-CNS에서는 성능 최적화팀이 발족됐다. 자바 개발자, 시스템 OS 담당자, 네트워크 담당자, DB 담당자, 애플리케이션 담당자 이렇게 5명으로 구성된 팀이었다. 성능이 제대로 나오지 않는 사이트의 튜닝에 투입되면, ‘해결 못 하는 건 아닐까’ 하는 두려움이 몰려오곤 했다. 3개월 정도 지나니까 실력이 느는 느낌이 들었고, 6개월이 지나니까 날아다닐 수 있겠다는 자신감이 붙었다. 각 분야의 전문가들을 한 팀으로 묶어 놓으니까 시너지가 나왔다. ‘공동 목표를 향해 5명이 한데 모이니까 이렇게 큰 힘을 발휘할 수 있구나’ 하고 실감했다. 당시만 해도 아침이면 ‘어느 사이트가 다운됐다’는 뉴스가 빈번하게 나오곤 했다. 내가 소속된 회사에서 했던 사이트가 (뉴스에) 나오면 이 다섯 명이 ‘소방수’로 출동했던 기억이 너무나 새롭다. 그때부터 모니터링 프로그램을 만들기 시작했다. 유틸리티 수준이었지만 나만의 모니터링 개념을 표현하는 기회가 되었다.

어떤 계기로 시스템 모니터링 도구를 개발하게 됐나.

모니터링 솔루션은 어느 누가 그런 소프트웨어를 만들어 달라고 해서 만들 수 있는 게 아니라고 본다. 일반적으로 어떤 소프트웨어를 만들려면 벤치마크를 하여 차별점을 도출한다. 그 차별점을 다시 강조하여 에지를 세워서 프로그램을 완성-출시한다. 모니터링 솔루션에서는 이 점이 통하지 않는다. ‘이걸 확인해 봐야 문제를 해결할 수 있겠다’는 정말 내게 절실했던 기능으로 채워가니까 다른 사람들도 공감했다.

자신을 슈퍼 개발자로 생각하나.

그렇지 않다. 운이 좋았을 뿐이다. 최적화팀에서 하루 지체 위약금 수천만 원짜리 프로젝트에 투입돼 식은땀 흘리며 문제를 해결했던 경험이 자신감을 줬다. 포기하지 않고 매달리면 해결할 수 있다는 경험을 했다. 남들이 짜 놓은 소스코드를 보고 바로 이해하기 어려워 좌절하기도 했다. 하지만 프로그램을 잘 짜지는 못해도 좋아할 수는 있다. 다시 한번 말하지만, 스스로 잘한다고 격려하면서 나아갈 필요가 있다.

끝까지 달려들면 해결된다는 경험이 재도전의 계기가 됐나.

그렇다고 볼 수 있다. 2010년에 모바일, 빅데이터, 클라우드라는 IT 업계의 키워드가 있었다. 모바일 패러다임을 놓쳤다는 생각이 들면서 매우 불안했다. 이때. 운영 시스템의 성능 관리라면 클라우드가 내게 더 낫겠다는 생각이 들었다. 친정인 LG-CNS로 다시 들어갔다. 그곳 클라우드팀에서 일했는데 내가 너무 모른다는 생각이 들었다. 단순 응용 소프트웨어 기술로는 안 되겠구나 하는 생각이 들었다. 클라우드 환경에서 데이터센터는 어떻게 운영될까? 하고 알아보게 되었다. 하지만 내가 관심을 두는 프로그램은 대기업에서 시작하기에는 너무 작았고 다른 여건들도 적합하지 않았다.

그래서 다시 벤처기업으로 돌아온 것인가.

미리 작정하고 그런 것은 아니다. 당시에 와탭랩스의 이동인 대표를 만났는데 ‘SaaS형 시스템 모니터링 서비스를 하고 있다’는 말을 듣고 놀랐다. 클라우드 환경을 고려하면 SaaS형, 즉 서비스로서의 모니터링 도구가 필요하겠다고 개인적으로 고민하고 있을 때였기 때문이다. 그로부터 1년 후, 이곳 와탭의 CTO로 오게 됐다. 그래서 더 조심스러운 측면이 많다. 설치형 시스템 모니터링 솔루션과 클라우드 모니터링 서비스와는 분명히 다르다. 그런데도 J사에서 해봤던 경험에 사로잡혀 마치 그게 정답인 것처럼 나도 모르게 따르게 될지도 모르기 때문이다. 좌충우돌하는 상황을 겪더라도 변한 환경에 맞는 길을 찾아야 하기에 매우 조심하고 있다.

DB라는 말 대신 데이터라는 말을 주로 쓰는 환경을 보면서 드는 느낌은.

서비스형 계열의 소프트웨어를 만들 때 핵심 3요소를 시각화-네트워킹-저장이라고 하자. ‘저장’을 DB나 NoSQL로만 할 수 있는 건 아니다. RDB는 ERP 같은 엔터프라이즈 비즈니스 프로그램의 데이터 관리에는 맞다. 하지만 시스템 모니터링 솔루션에서도 그럴까? 이때는 로그 데이터를 파일로 처리하는 게 더 유리할 수 있다. 통상적으로 모니터링 데이터는 저장 후 수정이 없고 쌓아 놓고 사용하는 구조다. 그런 환경에서는 RDB나 NoSQL 등 남이 만들어 놓은 일반적인 저장 솔루션은 최적의 대안이 될 가능성이 그리 높지 않다. 모니터링 솔루션 등 전문적인 분야의 솔루션을 만들려면 개발자 자신이 잘 핸들링할 수 있는 자기만의 저장기술이 필요하다. 모니터링 데이터는 일자별로 쌓아 놓고 지우면서 사용하면서, 중간에 수정할 일도 없다. 데이터별로 인덱스 파일형태로 저장하면 쉽게 지우고 관리할 수 있다. 실시간 처리라는 측면에서 보면 빅데이터의 특성이 있다. 다량의 문서 처리와 로그 데이터를 정제하여 실시간 서비스하려면 자기 자신만의 데이터 저장-처리 기술이 필요하다. 요즘 학생들과 얘기할 기회가 있어서 물어보면 파일처리에 대해서는 공부를 하지 않는 것 같았다. 나만의 기술 1~2개 정도를 개발하고 적용해야 더 효율적인 아키텍처의 경쟁력 있는 제품을 만들 수 있다.

개발자와 데이터 전문가가 부족하다는 말이 끊임없이 나온다.

이거저거 할 수 있는 만능 개발자보다는 파일을 읽고 저장하는 공부만 3년을 했거나 소켓 프로그래밍을 3년 정도 해봤다는 게 더 신뢰를 주지 않을까 한다. 응용기술은 나중에 배워도 된다. 시각화 측면에서는 인터넷에 공개된 차트가 무척 많다. 그렇더라도 나만의 생각을 담은 차트를 만들어 볼 필요가 있다. 그렇지 않으면 나만의 생각을 담을 수 없다. 어떤 데이터를 표현하기 위하여 자바스크립트로 자기만의 차트를 만들어 봤다면, 매우 공감을 살 수 있을 것이다. ‘많은 것이 있으므로 다 알아야 한다’는 부담을 갖거나 현혹될 필요도 없다. IT는 영역이 정말로 넓어졌다. 누가 만들어 놓은 기반 기술을 가져와서 비즈니스적 요소를 올리는 것에서 벗어나 볼 필요가 있다. 개발자로서 자신만의 뭔가를 만들어보고 싶다면, 특정 영역에 대해 자신만의 라이브러리를 만들 수 있을 정도로 파고 들어가는 게 좋다고 본다. 데이터를 포함한 저장, 통신, OS 커널 영역 등에서 어느 하나를 잡아서 파고 들어가야 뭔가를 찾을 수 있을 것이다.

몇 년 전부터 데이터 분석이 화두가 되고 있다.

각종 미디어에서 소개하는 슈퍼맨급 빅데이터 분석 전문가의 역량은 엄두도 못 낸다(^^). 그래서 과거 시스템 모니터링에서 좀 더 나은 분석을 위해 노력하는 중이다.

시스템 모니터링 솔루션 영역에서도 변화가 많았을 텐데.

먼저 얘기했던 클라우드 기술이 화두로 등장했다. 더불어 실시간 분석을 위해 적용했던 데이터 인덱스를 과거 1계층에서 벗어나 2~3계층으로 확장이 필요해졌다. 축적해 놓은 데이터에서 특정 서비스를 호출하려면 수많은 데이터를 어떻게 처리-호출할지에 대한 자신만의 방식이 필요하다.

개발 언어는 어떤 것을 쓰나.

자바 위주로 쓴다. 자바 코드를 보면, 최적의 코드인지를 알 수 있기 때문이다. 다른 언어로 개발할 수 있지만, 최적의 코드인지를 잘 알지 못한다.

클라우드 기술이 국내 IT 환경에도 현실로 다가왔다고 하는데.

IT 인프라를 포함한 총운영비(TCO)를 낮추기 위한 다양한 시도가 이뤄지고 있다. 소프트웨어 라이선스 비용을 낮추려면 클라우드 인프라보다 기존 인프라를 그대로 사용하고 오픈소스 SW를 사용하는 것이 더 유리하다. 하지만 기업 IT 비용의 80%는 인건비이고 나머지 20%가 라이선스비와 장비 비용임을 생각해 보자. 20%를 차지하는 라이선스 비용을 절반으로 줄이더라도 전체 비용 10%가 줄어들 뿐이다. 결국 인건비를 줄여야 효과를 높일 수 있다는 말이 된다. 가장 쉬운 방법으로서 더 많은 일을 하면 되지 않을까? 이 방법은 장애가 더 늘어나 결국에는 비용이 상승하는 것으로 나타났다. 결론은 자동화가 아닐까 한다. 운영관리의 자동화가 되어야 TCO가 줄어들 수 있다. 자동화를 하려면 표준화가 따라야 한다. 자동화를 더 쉽게 하려면 OSS를 사용하는 것이 더 유리할 수 있다. 즉 리눅스 운영체제에 OSS 기반의 솔루션을 올리는 것이다. 국내 대기업이나 금융권, 정부, 공공기관에서는 근 10년 동안 웹 기반의 IT 환경 구축을 위해 천문학적인 비용을 투자했다. 이는 퍼블릭 클라우드 서비스로 가는 장벽이 되고 있다. 오픈스택 등 네트워크나 스토리지 장비의 클라우드화를 위한 다양한 시도가 이뤄지고 있지만, 지금까지는 서버 가상화나 데스크톱 가상화 등 유틸리티 컴퓨팅만 성공적으로 안착한 것으로 보인다. 오픈스택으로 네트워크나 스토리지를 가상화하려면 배보다 배꼽이 큰 상황이 발생할 수 있다. 기술적으로 해결하지 못하는 장벽에 부딪히거나 너무 비용이 올라가기 때문이다. 예를 들어, 프라이빗 클라우드 가상화 인프라를 구축한 환경의 특정 포인트에서 스토리지 가상화를 신청했다고 하자. 이때 네트워크 엔지니어는 케이블을 교체해 주려고 뛰어다녀야 하는 해프닝이 벌어지기도 한다. 궁극적으로 IT 인프라의 유연성을 높이고 인건비를 줄이려면 퍼블릭 클라우드 기술이 현실적인 대안으로 보인다. 그런데도 시장에서는 ‘클라우드 환경이 기존 자체 인프라 도입 환경보다 저렴하다’고 장비 측면으로 좁혀서 접근한다. 10년 이상 된 IT 인프라는 감가상각이 이미 끝났으므로 상면비와 전기요금을 빼면 더는 비용이 들어가지 않는다. 클라우드 환경보다 인프라 비용은 더 싸다는 말이다. 하지만 인건비 이슈와 규모의 문제는 거론하지 않는다. OSS와 클라우드로 가는 추세는 분명하지 싶다. 이때 관리 솔루션을 기존과 동일하게 회사 전용으로 도입해야 하느냐? 하는 질문을 하게 된다. 와탭랩스 같은 클라우드 시스템 모니터링 서비스는 시장 분업화에 적응하는 모습을 보여준다. A사는 시스템 모니터링, B사는 시스템 로깅, C사는 시스템 관리 솔루션 등으로 분업화가 예상된다. 물론 현재로써는 SaaS형 클라우드 기반의 서비스가 국내에서는 초기라서 단언하기는 어려운 게 사실이다. 기술의 문제는 아니다, 선택의 문제이지.

기존 설치형 모니터링 업체도 클라우드로 이전해야 하는 거 아닌가.

유통채널과 기술지원 체제, 솔루션의 구조까지 모두 바꿔야 (이전) 가능하다고 본다. 코닥이 디지털 카메라 기술을 확보해 놓고도 시장을 선점하지 못했던 예가 좋은 본보기가 아닐까 한다. 자기 비즈니스 간에 충돌이 나기 때문에 움직이지를 못했던 것을 타산지석으로 여길 필요가 있다.

IT 전문가로서 가장 빛났던 순간은.

사람에게는 최근의 기억이 주로 떠오른다고 한다. 2002~2004년 사이 LG-CNS 최적화 팀에서 대리 직급으로 일했을 때가 떠오르곤 한다. 아침이고 저녁이고 전화 벨이 울리면 어떤 문제인지 따지지 않고 긴장하면서 현장 PM에게 ‘해결할 수 있다’고 호언장담했을 때다. 그 과정이 나 스스로에게 압박을 가했지만, 해결했을 때 성취감은 말 표현할 수 없을 정도였다. ‘너 뒤에 아무도 없다’는 말을 팀장에게서 들었을 때도 압박이라는 느낌이 들지 않았다. 이때 ‘내 삶 많은 부분의 판이 새로 짜이고 있다’는 느낌이 들었다. 하루 세 시간만 잤던 생활이었지만, 누구에게 끌려다니지 않고 자기주도적으로 살아갈 힘을 그때 얻었다고 본다.

그럼 가장 고마운 사람도 첫 직장에서 만났을 거 같다.

맞다. 첫번째 프로젝트에 들어갔을 때 만났던 현 LG-CNS의 원덕주 전무다. 최적화팀을 만든 주인공이자 고참 팀장이었다. ‘가서 해결해!’ 한마디가 나오면 어떤 사람은 너무나 힘들어했는데, 나는 그게 좋았다. 더 정확하게 말하면, 그 일이 내게 맞았고 상황이 그렇게 전개됐다.

여러 가지를 경험해 보고서 드는 느낌은.

회사 생활하면서 가장 중요한 것은 자신의 성장이라는 생각이 든다. 성장이 멈추면 직장에 대한 만족이나 연봉, 직장의 안정도 의미가 없어졌다. 반대로 지속적으로 성장하고 있다면 시차는 발생하겠지만 다른 것들은 따라 온다고 믿는다.

어떤 인연으로 프로그래머라는 일을 하게 됐나.

GW-Basic 언어를 대학 선배가 가르쳐 준 것이 계기가 됐다. 아직 DOS도 모르던 시절이었다. 책을 보면서 한줄 한줄 따라 해봤더니 너무나 재미있었다. 프로그래밍의 재미를 발견한 것이 내게는 행운이었다. 세상에는 프로그래밍을 엄청 잘하는 사람이 정말 많다. 그에 비하면 나는 매우 좁은 영역만 알고 있다. 빅데이터, 클라우드, 모바일 개발을 깊이 얘기하면 잘 모른다. 하지만 나는 내가 프로그래머라는 것이 좋다.

목표는 무엇인가.

개발자로 은퇴하고 싶다. 설계와 기획만 하는 게 아니라 은퇴할 때까지 코딩을 하고 싶다. 10년만 더 하면 그게 가능할 거 같다. 영어를 잘 못 하는 게 아쉽다. 그래서 영어권 국가로 유학도 가고 싶다. 지금 회사에서 하는 SaaS형 모니터링 서비스가 세계적으로 성공했으면 하는 바람이다. 출근했더니 지구 반대편의 어느 고객으로부터 도와 달라는 연락이 오는 꿈을 꾸고 있다. 기존 설치형 시스템 모니텅 솔루션보다 클라우드형 시스템 모니터링 서비스가 이 꿈의 실현 가능성을 높여줄 거라고 본다. (끝)

출처 : 한국데이터진흥원

제공 : 데이터 전문가 지식포털 DBguide.net