미디어, 포털, 금융, 항공, 커머스, 유통, VR·AR 분야를 모두 거친 만능 개발자가 있다. 주인공은 공간 데이터 플랫폼 어반베이스(Urbanbase)의 방현우 CTO. 그는 17년간 다양한 분야에 도전하며 내공을 쌓았다.
개발자는 어떤 궤도를 따라 성장해나갈 수 있을까? 그리고 개발 조직을 이끄는 리더로서, CTO는 무엇을 결정할 줄 알아야 할까. 그의 개발 철학과 노하우에 대해 직접 만나 물었다.
어반베이스 방현우 CTO
■ 17년의 개발 인생, 단 한 번도 안주하지 않았다
– 같은 업으로는 움직이지 말자는 철칙
– 어반베이스는 낯선 3D 영역에 대한 또 한 번의 도전
비전공자였다고 들었다. 어떻게 개발자가 된 건가.
전공은 의료 공학이었다. 공군 시절, 전투기 정비병을 맡으며 내가 하드웨어와 안 맞는다는 걸 깨닫고, 소프트웨어 쪽으로 방향을 틀었다. 마침 2천 년 대 닷컴 버블이 한창이었다. 현재의 아내가 당시 공무원 준비를 하고 있었는데, 주말마다 도서관에 따라가서 책으로 개발 지식을 익혔다. 그렇게 얻은 첫 직장이 중앙일보 뉴미디어 개발실이다. 기자들이 사용하는 콘텐츠관리시스템(CMS) 개발부터 시작해서 총 10개의 사이트를 관리했다. 4년 간 사람 사는 게 아니었지만, 돌이켜보면 그 당시 일을 정말 빨리 배울 수 있었다.
4년간의 첫 직장을 그만두고 이직할 때에는 어떤 결심이 있었나.
‘새로운 것을 해보자’는 생각이었다. 그 이후로 넥슨(게임), SK컴즈(포털), 비씨카드(금융), CJ오쇼핑(커머스), 더존비즈온(ICT) 등 계속해서 새로운 분야에 도전했다. 어반베이스 입사 전에는 29CM(커머스)의 CTO로 재직했다.
계속된 도전의 이유는 무엇이었나.
예전엔 개발자들을 소위 ‘전산쟁이’라고 불렀다. 어떤 분야, 어떤 기업을 가도 개발자의 기본 업무는 같다. 그 결과물을 어떤 비즈니스에 녹이느냐의 차이다. 내가 중앙일보에 있다가 다른 언론사로 이직하면 얼마나 재미가 없겠나. 아예 내가 모르는 분야에 가면, 연차가 쌓인 시점에서도 긴장하게 되고 새로운 걸 배우게 된다. 개발하려면 기본적으로 해당 산업 종사자들의 생태를 알아야 한다. 언론사에서는 기자들의 생활, 업무 패턴을 이해하고 개발을 했다. 게임 쪽은 또 완전히 다르다. 글로벌 시장에서 활동하는 게임사에서 개발을 하다 보면, 해외 법률에 대해서도 알게 된다. 이직할 때에는 똑같은 업으로는 움직이지 말자는 철칙을 세웠다.
어반베이스는 방 CTO 가 처음으로 선택한 스타트업이다. 과거 직장은 모두 대기업이었다. 어떤 점에서 매력을 느꼈나.
첫 번째 이유는 어반베이스가 가진 데이터다. 현재 어반베이스는 2D 도면을 3D로 변환하는 특허 기술을 세계적으로 출원한 상태다. 여기에 전국 70%의 아파트 도면을 가지고 있다. 약 350만 가구 분량이다. 앞으로 조금 더 노력하면 국내 아파트 도면은 100% 확보할 수 있다. 현재 해외 도면 역시 수집 중이다. 이 작업이 진전되면 미국, 일본, 중국, 홍콩, 말레이시아를 비롯한 유럽 전 세계 주요 도시들의 아파트, 상가 도면을 보유하게 된다. 여기에 소방재청과 같은 기관들과 협업하면 구글이 그렇게도 갖고 싶어 하는 인도어 디비(Indoor DB)를 구축하게 되는 것이다. 보통 로봇을 만들어 실내를 스캐닝할 경우, 건물 한 층을 스캔하는 데 일주일이 걸린다고 한다. 어반베이스는 2초 만에 2D 도면을 3D로 구현할 수 있다. 기술은 흉내 낼 수 있어도, 데이터는 못 따라잡는다. 이게 결정의 큰 이유였다.
두 번째로는 플랫폼을 만들고 싶은 욕구가 있었다. 국내에서 성공한 플랫폼은 많다. 하지만 글로벌 플랫폼으로 성장한 사례는 없다. 2006년 구글이 유튜브를 인수했을 때만 해도, 웬 엉뚱한 회사를 사냐고 하는 사람이 많았다. 하지만 지금의 유튜브는 갓튜브라고 불릴 만큼 새로운 세대의 플랫폼으로 성장했다. 유튜브의 성장 동력은 첫째가 데이터, 둘째가 플랫폼화 전략이다. 이들은 플랫폼이 되고 나서도 거기서 멈추지 않고 계속해서 서비스 품질을 높여 나갔다. 처음엔 HD 화질에도 놀랐었는데, 이제는 8K, 360도 영상까지 지원한다. 스마트폰 하나만 있으면 유튜브에서 실시간 방송이 가능한 시대다. 경쟁자인 비메오가 뒤처진 것을 보면, 이 데이터와 플랫폼의 힘이 얼마나 놀라운지 알 수 있다. 어반베이스 역시 현실 세계의 모든 공간을 가상 세계로 옮기는 공간 데이터 플랫폼으로 거듭날 수 있다고 확신했다.
■ 슬럼프 빠진 개발자라면 낯선 곳으로 가라
– 10년은 무조건 개발만 해라
– 다양한 개발 언어를 다룰 줄 아는 것이 개발자로서의 경쟁력
– 각기 다른 분야에서 쌓은 경험이 문제 해결의 힌트가 되기도
어떤 직무에 있는 사람이건 연차가 쌓이면 슬럼프를 겪게 된다. 더 발전이 어렵다는 생각이 들면, 조직과 시장에서의 본인의 가치 문제도 고민해보게 된다. 후배 개발자들에게는 어떤 조언을 해주고 싶은가.
정답은 없다. 하지만 후배들이 면담 요청을 하거나, 술 사달라고 할 때 해주는 말이 있다. ‘무조건 8~10년은 코딩을 하라’는 것이다. 만약 운전이 업인 사람이라면 자가용, 1톤 트럭, 12인승을 다 다룰 줄 알아야 나중에 더 많은 선택권을 갖게 된다. 그래서 2, 3년 차 후배가 진로 걱정을 하면, 개발부터 열심히 하라고 조언한다. 특히 다양한 개발 언어를 다룰 줄 아는 게 중요하다. 특정 언어만 고집하는 개발자들이 있다. 개인 취향이기 때문에 뭐라고 할 순 없지만, 언어는 도구에 불과하다. 자바를 깊게 파서 국내 일인자가 된다고 해도, 10년 뒤 자바가 없어지면 무슨 소용이 있나. 적어도 8~10년간은 다른 생각하지 말고 다양한 언어를 익히라고 조언하고 싶다.
10년 차 이상의 개발자들에게는 어떤 준비가 필요한가.
내 경험을 기반으로 말해준다. 앞서 말했듯 ‘개발업을 버릴 게 아니라면, 전혀 모르는 분야에 가서 일해보라’는 것이다. 특히 슬럼프에 빠진 상태라면, 이것이 엄청난 자극이 된다. 다양한 산업 분야에 대한 지식을 쌓다 보면, 나중엔 A 분야에서 배운 기술을 B 분야에 적용해 볼 기회가 생긴다. 일례로 비씨카드에서 그룹웨어 속도 개선 업무를 맡은 적이 있다. 공지사항 하나를 여는 데 20초가 걸릴 정도로 느렸다. 이를 개선하기 위해 그룹웨어에 언론사가 사용하는 캐시 방식을 적용해봤다. 뉴스 쪽에서는 캐시가 생명이다. 99%의 트래픽이 단 하나의 뉴스에 꽂히기 때문에, DB 호출 방식이 아니라 기사의 결괏값을 메모리에 올려놓고 부르는 방법을 이용한다. 이를 통해 업무 효율을 엄청나게 올릴 수 있었다. 어디서든 성공하려면 기본기가 탄탄해야 한다. 개발을 못 하면 업종을 바꿔봤자다. 그렇기 때문에 어느 정도 ‘내가 하수는 아니다’라는 감이 올 때쯤 이직을 하라고 조언한다. 그전에는 다양한 언어 배우고, 세미나 같은 게 있으면 어떤 식으로든 도움이 될테니까 빠지지 말고 가서 들으라고 하고.
개발 하수는 언제쯤이면 벗어났다고 자평할 수 있을까.
사람마다 다르겠지만, 5년 차쯤 되면 감이 온다고 생각한다. 업무를 받았을 때, 3주면 될 것 같아도 외부에는 2달 정도 걸린다고 얘기할 때쯤이면 중수 이상은 되는 거다. 게으름이나 요령 피우는 게 아니다. 그때까지 여러 번의 시행착오를 통해 학습을 한 거다. 일정에 딱 맞춰 결과물을 냈는데 버그가 발생하면 큰일이다. 본인이 3주 동안 빨리 만들어서 테스트해본 후, 데드라인 1, 2주가 남았을 때 완성했다고 보고하면 안전하기도 하고 사내 평가도 후해진다. 노하우라면 노하우다. 물론 프로젝트의 중요도에 따라 긴급히 처리해야 할 일도 분명히 있지만 말이다.
■ CTO는 각 개발자에 걸맞은 전술을 짜주는 사람
– 개발 거버넌스의 성격을 결정짓는 것은 CTO의 성격
– 문서화 작업은 개발 조직의 지적 재산을 쌓아가는 과정
– 같이 밥 먹으며 개발자 개개인의 성향 파악하는 것이 중요
일반적인 개발자 업무에서 더 나아가, 관리 업무를 맡게 된 시점은 언제였나.
CJ오쇼핑 개발 팀장으로 일하게 됐을 때다. 이때부터 경영에 대한 고민을 시작했다. 다양한 시행착오를 겪었다. 구글을 벤치마킹해 업무 시간의 20%를 개인 프로젝트에 쓸 수 있게 했더니 아르바이트를 하는 팀원도 있었다. 그때를 기점으로 총 3번의 개발 거버넌스를 이끌며, 나름의 방법론을 정립하게 됐다.
개발 거버넌스란 무엇인가.
개발 조직 또는 개발 서비스를 운영하는 방식을 통칭하는 것이다. 개발 거버넌스라는 개념이 지금은 보편적이지만, 몇 년 전까지만 해도 생소했다. ‘우리 개발팀은 분위기가 왜 이래?’ 정도로만 다뤄졌다. 개발 거버넌스는 조직을 총괄하는 리더의 생각, 태도, 경험에 따라 그 성격이 완전히 달라진다. 예를 들어 보수적인 개발 방법론을 선호하는 CTO 아래에는 보수적인 개발자들이 모이게 되어 있다.
어떤 개발 거버넌스를 만들려고 애썼나.
먼저 개발 방식에 변화를 줬다. 작은 장난감 성을 하나 짓는다고 가정해보자. 찰흙을 반죽해 성 하나를 통째로 지을 수도 있고, 블록을 조립해 쌓아 올릴 수도 있다. 찰흙은 한 번 굳으면 수정할 수 없지만, 블록은 작은 조각들을 조립하면서 자유롭게 구조를 변형할 수 있다. 모듈화의 특징이다. 개발 방법론 내에서는 전자를 서비스 단위를 크게 묶어 서버 단위로 배포하는 모놀리틱 방식, 후자를 모든 서비스 단위를 독립 실행 가능하도록 분리해서 개발하는 마이크로 소프트 아키텍처(이하 MSA) 방식이라고 부른다. MSA는 지금은 보편화한 개발 방법론인데, 5년 전 국내에서는 일부 에반젤리스트들의 입에만 오르내렸다.
개발 방식을 바꾼 후 실제 어떤 효과가 있었나.
당시 CJ오쇼핑에서는 PC, 모바일 웹, 앱 개발 소스가 각각 따로 세 벌이 있었다. 이 경우 한 부분을 고치려면 총 3번 일을 해야 한다. MSA 방식으로 개발을 하면 한 번의 수정으로 세 채널 모두 관리가 된다. 문제는 당시 개발을 대부분 위탁 업체에 맡기고 있었는데, 설득해야 할 회사 외부 사람만 무려 60명이었다. 개발 방식을 바꾸면 ‘결국 내 밥그릇 뺏기는 것 아니냐’는 반발이 심했다. 설득 과정만 6개월이 걸렸다.
회사 내부 사람도 아니고 외부 사람에게 업무수행 방식의 변화를 납득시키는 것은 어려운 일이었을 텐데.
일하는 입장에서는 매우 번거로운 일이다. 하지만 ‘업무 영역을 제대로 분장해주겠다’고 약속했다. 과거에는 개발자가 디자이너에게 디자인 시안을 받으면 HTML에 자바스크립트 짜고, CSS 수정하고, DB 연동하는 모든 과정을 혼자서 다 했다. 게다가 이전에는 익스플로러 대응만 하면 됐는데, 요즘에는 모바일 웹, 크롬 등 브라우저마다 렌더링하는 엔진이 틀리기 때문에 손 가는 일이 많아졌다. 나는 외부 개발자들에게 전문 퍼블리셔와 스크립터를 뽑을 테니, 앞으로는 API만 개발하고 다른 건 신경 쓰지 않아도 된다고 말했다. 처음엔 좀 의심을 하더니, 얼마 지나지 않아 ‘일하기 편하다’고 하더라. 가끔 협력사 회식에도 따라가서 친분도 쌓곤 했었는데, 나중엔 불편해하실 것 같아서 회식비만 지원했다.
개발 조직의 성격 변화는, 다른 팀과의 협업에도 영향을 미칠 것 같다.
맞다. 아무리 개발 조직의 업무 효율을 높여놔도, 다른 팀과의 협업이 막히면 소용이 없다. 재직했던 더존비즈온은 팩스, 그룹웨어, 메신저, PG사 등 국내 구글이라고 불러도 될 정도로 다양한 서비스를 운영하는 회사다. 그런데 문제는 이 각각의 서비스가 모놀리틱 방식으로 개발되어 모두 분리되어 있다는 점이었다. 이 모든 서비스를 모아 하나의 업무 포털로 만들어달라는 것이 회사의 주문이었다. 하지만 실상은 다른 팀과 회의 한 번을 잡는 것도 어려웠다. 또 20년이 넘은 회사라면, 이미 어마어마한 산출물이 보존되어 있어야 한다. 하지만 이 결과물들이 각 개인의 PC와 머릿속에만 들어있다는 것도 문제였다. 개발팀뿐 아니라 전사 차원의 조치가 필요했다.
개발 조직의 리더가 전사 차원의 변화를 이끌어나간 과정이 궁금하다.
당시 나는 협업 프로세스를 강조하며 지라와 위키라는 협업툴의 사용을 전사로 확대해달라고 요구했다. 업무 과정에서 산출된 지식을 담아낼 하나의 그릇이 있어야 회사가 살아남을 수 있다는 주장이었다. 회사 측에서는 결정이 쉽지 않은 사안이었다. 개발자만 수백 명이 넘는 회사인 데다가, 이미 자체적으로 개발해 사용하고 있는 협업툴이 있었다. 새로 도입할 협업툴의 가격이 절대 저렴하지 않았다. 하지만 결국 회장님을 설득해 개발팀과 긴밀하게 협력하는 몇 개 팀이 새 협업툴을 함께 사용하게 되었고, 타 사업부에서도 효율적이라는 평이 나오기 시작했다. 위키가 다운될 정도로 접속량이 늘기도 했다. 내가 퇴사하고 나서는 전사가 같은 협업툴을 사용하게 됐다고 들었다. 이처럼 좋은 개발 거버넌스의 속성을 단 하나로 정의할 순 없다. 각 조직이 가진 문제가 다르고, 이를 파악해 업무 효율을 높일 방법을 찾아내야 하기 때문이다.
온라인 커머스샵인 29CM의 CTO로 일하면서는 어떤 해답을 찾았나.
당시엔 문서화 작업에 중점을 뒀다. ‘산출을 명확히 하자’는 기조였다. CJ오쇼핑 때부터 나와 함께 움직인 동료들은 대체로 문서화 작업에 익숙했는데, 그렇지 않은 분들은 ‘문서 작성에 시간을 쏟으면 개발은 언제 하냐’는 반응이었다.
실제 개발자들이 문서화 작업이 오래 걸리기 때문에 아주 싫어한다고 들었다.
싫을 순 있다. 하지만 문서 작업을 한 번 하면 개발자 본인도 머리에 정리가 된다. 이 문서를 API 명세서라고 하는데 개발자 본인이 어떤 요청 사항에 의해 개발을 했는지, 어떤 파라미터가 들어가면 어떤 결과물이 나오는지를 정리해 적어두는 것이다. 일종의 공식집이라고 보면 된다. MSA 방식 하에서는 이 명세서를 기반으로 웹, 모바일 웹, 앱 개발이 함께 이루어진다. 예를 들어 쿠폰 조회 기능을 PC에서 개발했는데 앱에도 적용해야 한다면, 앱 개발자가 여기저기 물어볼 필요 없이 이 문서를 보고 같은 API를 불러와 넣으면 된다.
문서화 작업은 현재 대부분의 개발 조직 내에서 이루어지고 있나.
아직도 이 작업을 싫어하는 조직이 전체의 절반은 넘는다고 본다. 결국 개발 매니저 혹은 CTO가 문서화에 대한 필요성을 느끼지 못한다면 안 만드는 것이다. 개발 초기부터 문서를 체계적으로 작성해두면, 이게 나중에는 해당 개발 조직의 엄청난 지적 재산, 집단 지성이 된다.
문서 작업이 필요 없다고 생각하는 개발 조직 리더들의 논리는 무엇인가.
여전히 모놀리틱 방식으로 개발하고 있는 집단의 경우, 명세서의 필요성을 못 느낀다. 모듈 방식이 아닌 통으로 개발을 하므로 API 명세서보다는 UML 클래스다이어그램이라는 것이 더 필요하다. 공장 등에서 사용되는 프로그램이 보통 모놀리틱 방식으로 개발된다.
개발직을 맡을 때와 관리직을 맡을 때의 가장 큰 차이점은 무엇이었나.
가장 큰 차이는 자기 만족감이 다소 낮아진다는 것이었다. 개발자로 있을 땐, 시키는 것 다해서 보여주면 성취감도 있고 잘되면 칭찬도 받을 수 있다. 하지만 관리자는 좀처럼 칭찬받을 일이 없다. 개발 조직 관리는 물론, 타 부서와 협력할 때 중간 커뮤니케이션 채널이 되어야 하기 때문에 다양한 사람으로부터의 불편사항을 다 들어줘야 한다.
기계가 아닌 사람에 관한 일을 하게 되는 셈이다. 훨씬 더 변수가 많은 대상인데, 어떤 방식으로 소통하고 있나.
같이 밥 많이 먹고, 술도 자주 마신다. CTO는 좋은 개발 거버넌스가 되기 위한 프로세스를 잡아놓고, 정확한 전략을 짜고, 비전을 명확히 제시해주는 역할을 할 줄 알아야 한다. 하지만 실제 전쟁에 나가서 전투를 벌이는 것은 개개인의 개발자다. 목표가 같아도 방법은 각자 다를 수 있다. 누구는 달려가고, 누구는 걸어가고, 누구는 지하도를 통해 간다. 개발자 각각에 알맞는 최적의 전투 전술을 짜주기 위해서는 그 사람에 대해 잘 알고 있어야 한다. 자주 만나서 얘기를 들어주는 게 제일 좋다.
밥 먹으면서는 주로 어떤 이야기를 나누나.
이야기를 나누다 보면 어떤 성향의 사람인지, 어떤 개발자인지, 오타쿠인지 시니컬한 사람인지 다 파악할 수 있다. 이 정보를 모아 그 사람만을 위한 전술을 짠다. 단순히 과제의 완수 여부를 두고 그 사람의 실력을 평가하지 않는다. 한 개발자는 지나치게 꼼꼼한 성향 때문에 개발 속도가 더뎌지곤 했다. 다들 ‘저 사람은 왜 이렇게 성과가 안 나냐’고 했지만, 내가 옆자리에 앉아서 지켜보고 함께 차 마시며 이야기를 나누다 보니 무능해서 그런 게 아니었다. 사실 대충 만들어서 주면 되는 프로젝트인데도, 지나치게 꼼꼼해서 일주일 동안 개발해야 할 것에 대한 정보를 모으고 있었던 거다.
개인의 성향과 조직의 목표가 충돌할 때는 어떻게 중재하나.
그게 바로 그 사람에게 맞는 전술을 짜주는 과정이다. 설명을 해주면 된다. 우리가 이 프로젝트를 하는 이유가 무엇인지, 왜 이 시간 내에 해내야 하는지 최대한 자세히 이야기해준다. 어려운 인문학적 용어로 말하면 이해가 늦다. 개발 쪽에서만 사용하는 용어들이 있다. ‘이건 선입선출이야’, ‘이건 큐야’, ‘이건 스탠이야’, ‘그니까 우리는 일을 이런 방식으로 해야 해’라고 말하면 정확하게 알아듣는다. 친근한 용어로 설명해주는 것이다.
반쯤은 농담이겠지만, 디자이너나 마케터 등 타 부서 사람들이 개발자와의 의사소통을 어려워한다는 이야기를 몇 번 들은 적 있다. 개발자와 잘 소통하기 위한 팁이 있다면.
개발자들은 개성이 정말 강하다. 심지어 iOS, 안드로이드, 서버, 프런트UI 등 어떤 분야를 다루는지에 따라서도 성향이 또 다르다. 어떤 개발자는 자기는 노트북을 꼭 삐딱하게 둬야만 개발이 잘된다고 말하기도 한다. 그런 개성을 존중하되, ‘우리는 협업을 해야 하니까 최소한의 기준을 맞추려고 노력하자’는 식으로 설득하는 과정이 필요하다. 또 모르는 영역에 대해서는 모른다고 솔직하게 말하는 것이 좋다. ‘당신이 이 분야의 전문가이니까 의견을 피력해달라. 책임은 내가 진다.’고 말한다면 개발자와의 협업이 한층 쉬워질 것이다.
관리자 역할을 열심히 할수록 개발자로서의 역량이 떨어지기도 하나.
그럴 수 있다. 그걸 방지하려고 CJ오쇼핑 때부터 개발을 놓지는 않았다. 하지만 장단이 있다. 내가 개발자 모드에 돌입하면 확실히 관리자로서 놓치는 것이 생긴다. 양쪽의 기량을 동시에 유지하는 것은 어려운 일이다.
어반베이스에서는 향후 어떤 일을 만들어나갈 예정인가.
현재 어반베이스는 2D 도면 데이터를 웹 VR, AR 형태로 만들고 있다. 그런데 한 개발자가 공간인지 머신러닝을 개인적으로 개발하고 있었다. 이것을 주 제품군의 하나로 만들 예정이다. 스마트폰 카메라를 대면, 그곳이 부엌인지, 방인지, 사무실인지를 85%의 정확도로 인지해내는 시스템이다. 현재까지 4만5천 장의 사진을 학습시킨 상태다. 이것이 발전되면 장소 주인의 성별과 연령대까지 추정해낼 수 있다. 이걸 커머스와 연계시키면, 공간 성격에 따른 상품을 추천해주는 식의 비즈니스가 가능해질 것이다.
마지막으로 방현우 CTO의 개발자로서의 목표에 대해 말씀해달라.
전 세계 사람들에게 영향을 미치는 글로벌 플랫폼을 만들고 싶다. 단순히 부를 위한 수단이 아닌, 인류에게 도움이 될 수 있는 플랫폼을 탄생시키는데 기여할 수 있으면 좋겠다. ‘세상은 저지르는 자의 것이다. 그리고 인생은 바라는 대로 노력한 만큼 이루어진다’는 말을 좋아한다. 후배 개발자들에게도 해주고 싶은 말이다. 어떤 것을 선택하든, 선택하지 않든 후회는 하게 되어 있다. 그러니 무엇이든 원하는 것을 행동으로 먼저 옮기자. 이를 위해 간절하게 노력한다면 상상보다 훨씬 더 많은 것을 성취할 수 있을 것이다.
관련 기사
