고객이 SW를 망친다

우리나라는 고객이 소프트웨어와 개발사를 망치는 경우가 많다. 외국 소프트웨어 회사와는 다른 잣대로 우리 소프트웨어 회사를 대하는 이중성 때문에 우리나라 소프트웨어 회사는 더욱 어려움을 겪는다. 물론 이런 현상이 꼭 고객 탓만은 아니다. 

우리나라 소프트웨어 회사들이 미래는 생각하지 않고 당장 눈앞의 이익만 쫓다 보니 고객들은 여기에 길들여진 측면도 있다.

이렇게 고객이 소프트웨어 환경을 망치고 있는 실제 사례들을 알아보자. 

A사 고객들은 참을성이 없다. 

소프트웨어에 버그가 발견되면 당장 고쳐달라고 막무가내 식으로 요구한다. A사는 팩키지 소프트웨어를 만들기 때문에 개별 고객의 요구사항을 다 들어주지는 않는다. 하지만 이렇게 무리한 요구를 하는 고객이 많기 때문에 당장 고쳐주지 않을 수 없다. 

이렇게 계획되지 않는 급한 수정을 핫픽스(Hotfix)라고 한다. A사는 특정 몇몇 고객 때문에 핫픽스를 과도하게 많이 만드느라 계획된 개발 일정에 지장이 생겼고 소스코드도 지저분해졌다. 

하지만 A사 고객들도 외국 소프트웨어를 사용하면서는 그런 무리한 요구를 하지 않는다. 외국 소프트웨어 회사들은 대부분 그런 요구는 들어주지도 않기 때문이다. 

B사는 소프트웨어 버그로 인해서 개발자가 고객사에 방문 사과를 한적이 있다. 

B사 고객들은 소프트웨어 버그가 발견되면 개발자를 죄인 취급한다. 가끔은 심각한 버그가 발생하면 개발자의 방문사과를 요구한다. 이런 말도 안되는 요구에 B사는 상황을 쉽게 모면해 보려고 개발자에게 고객을 방문해서 사과할 것을 지시했다. 

개발자는 어쩔 수 없이 사과 방문을 했고 개발자로서 회의를 느꼈다. 사실 버그 없는 소프트웨어는 없고 버그가 개발자만의 책임도 아니다. 개발에 참여한 모든 사람의 공동 책임인데 아직도 버그의 모든 책임은 개발자에게 있다고 생각을 하는 경향이 있다. 

자동차를 타면서 문제가 발생하면 자동차 만든 사람이 와서 사과를 하라고 하는 경우는 없다. 개발자에게 버그에 대한 사과를 요구하는 일은 대한민국에서만 벌어지는 현상이 아닐까? 

C사는 개발자들이 고객 옆에서 개발을 해야 한다. 

C사는 솔루션 회사다. 자사 솔루션을 이용해서 고객 요구대로 커스트마이징해서 개발을 해준다. 그런데 주로 고객들은 자사 담당자 옆자리에서 개발을 할 것을 요구한다. 사실 개발자들은 다니는 회사에서 개발하는 것이 훨씬 더 효율적이다. 여러 동료의 도움을 받을 수도 있고 환경도 더 좋다. 

그런데 고객이 방문해서 개발을 할 것을 강력하게 요청하기 때문에 어쩔 수가 없다. 스펙도 정하지 않고 옆에 앉혀 놓고 이러쿵저러쿵내키는대로 요구사항을 말하면서 소프트웨어를 개발한다. 요구사항이 많이 바뀌어서 지우고 다시 만들기를 수없이 반복했다. 

물론 외국 경쟁회사는 이런 요구에 콧방귀도 안뀌기 때문에 C사는 이런 방문 개발 방식을 강점으로 내세워서 국내 시장에서 상당한 성공을 이뤄냈다. 하지만 성장은 한계에 다다랐고 과거의 방식을 버려야 더 점프를 할 수 있다는 것을 알아도 방식을 바꾸기에는 너무 늦어버렸다. 고객보다도 개발자들이 이 방식에 익숙해져서 내부 개발문화를 바꾸지 못하는 것이 더 큰 걸림돌이 되고 있다. 

D사도 고객사에 방문해서 개발을 해야 한다. 

하지만 이유가 약간 다르다. 고객이 보안을 너무 강조하다 보니까 고객사에 방문해서 개발할 수 밖에 없다. 고객사에서 아무것도 가지고 나올 수 없다. 개발은 모두 고객사에서 해야 하고 고객사를 나올 때는 몸밖에 빠져나올 수 밖에 없다. 사실 이 회사도 외국 소프트웨어 회사와는 이렇게 일하지 않는다. 고객의 이중성은 여기서도 드러난다. 

E사는 유지보수 비용을 제대로 받지 못했다. 

E사는 솔루션 회사인데 납품 후에도 지속적인 유지보수 비용이 들어간다. 버그 수정 및 기능 개선이 꾸준히 이루어진다. 하지만 고객은 무상 유지보수를 요구해서 유지보수 비용을 제대로 받지 못한다. 심지어는 버그를 고치는데 왜 돈을 받냐는 주장을 하기도 한다. 

E사의 고객들도 외국의 소프트웨어를 쓸 때는 군말 없이 유지보수 비용을 지불한다. 외국 소프트웨어를 쓸 때는 패키지 소프트웨어라 하더라도 워런티 계약을 따로 한다. 워런티 비용은 소프트웨어마다 다르지만 매년 소프트웨어 구매 비용의 10%~50%를 지불한다. 

1년간 아무런 요청을 하지 않아도 비용은 지불해야 한다. 3년간 워런티 계약을 하지 않다가 4년째 문제가 발생해서 지원을 요청하려면 4년치 워런티 비용을 모두 지불해야 한다. 이렇게 외국의 소프트웨어 회사에는 유지보수 비용을 지불하지만 대한민국의 소프트웨어 회사에는 매우 인색한 것이 현실이다. 

F사 고객이 말도 안되는 문서를 수십 종 요구한다. 

F사는 SI회사다. 대부분은 실제 소프트웨어 개발에 꼭 필요한 문서는 아니다. 단지 고객이 제시하는 방법론에서 필요한 문서일 뿐이다. F사는 실제로는 고객 프로세스대로 소프트웨어를 개발하지도 않는다. 그런 식으로는 소프트웨어를 주어진 시간에 개발할 수 없기 때문이다. 

개발은 그냥 평소대로 하면서 문서만 추가로 따로 만든다. 문서를 반복적으로 만들어내다보니 너무 번거로워서 나중에는 문서를 자동으로 생성하는 프로그램을 만들기도 했다. 이렇게 만들어진 문서는 프로젝트 도중에도 프로젝트 후에도 아무도 보지 않는다. 

그냥 검수를 통과하기 위한 조건일 뿐이고 검수 시에도 소프트웨어와 문서가 일치하는지 확인할 방법도 없다. F사는 고객의 이러한 과도한 문서 요구에 프로젝트 비용이 훨씬 많이 들어가고 정작 개발할 시간이 줄어 들고 있다고 하소연을 하고 있다. 

G사는 패키지를 수정해달라는 고객의 요구로 인해서 회사가 어려워졌다. 

G사 고객들은 패키지 소프트웨어를 바꿔달라는 요구가 많다. G사도 이런 고객의 요구사항에 빠르게 대응하다 보니 소스코드가 여러 벌이 생겼다. 소스코드도 그냥 복사를 해서 고객별로 관리를 해서 시간이 흐를수록 개발 속도는 점점 늦어졌다. 기능 하나를 수정해도 여러 벌의 소스코드에 적용을 해야 했다. 

이렇게 소스코드를 통합(Merge)하는 시간이 점점 길어졌고 나중에는 개발하는 시간보다 소스코드 통합에 더 많은 시간이 소요되었다. 결국 G사는 문을 닫았다. 이는 고객 탓만은 아니고 눈앞의 이익만 쫓는 G사의 무분별한 단기 대응도 문제였다. 

요즘 정부도 민간도 소프트웨어 환경을 개선해보고자 많은 노력을 기울이고 있지만 정작 돈을 내고 있는 고객들은 바뀌지 않고 있다. 물론 고객만의 탓은 아니다. 수십 년간 우리나라 개발회사들에 길들여진 것뿐이다. 

이렇게 소프트웨어 환경이 망가지면 결국 고객들도 손해를 본다. 우리나라 소프트웨어 회사들이 많이 망가지고 나면 제대로 쓸만한 국산 소프트웨어가 줄어들고 울며 겨자먹기 식으로 비싸고 문화도 잘 맞지 않는 외국의 소프트웨어를 써야 한다. 

법으로 바꿀 수 있는 것은 바꿔야 한다. 사실 별 뾰족한 답도 없는 문제지만 결국 고객을 바꾸는 것은 개발사들이다. 계획적인 개발을 하려고 해도 경쟁사에서 고객 밀착형 서비스를 한다고 하면 경쟁에서 밀리고 만다. 

결국 이런 소프트웨어 품질보다 노예식 개발을 장점으로 내세우는 전략은 모두를 다 망치는 일이라는 것을 인식하자. 특히 시장을 주도하는 선두 주자들부터 소프트웨어 환경을 건전하게 바꾸어 나가면 고객의 우리나라 소프트웨어에 대한 이중적인 인식을 바꾸는 것이 불가능하지는 않을 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

자신의 코드에 발목 잡힌 개발자들

필자는 국내외 다양한 소프트웨어 회사에 다니는 여러 개발자를 만날 기회가 자주 있고 각 회사의 개발 이야기를 종종 듣는다. 

그 중에서 3가지를 소개할까 한다. 우리나라 개발자들이 다양한 일을 하지 못하고 하던 일만 계속하게 되는 현상에 관한 것으로, 이것이 왜 문제가 되는지 생각해 볼 수 있는 사례이지 싶다.
 
국내 A사는 소프트웨어 개발자만 100명이 넘는 업계 1위 중견기업이다. 이 회사 개발자들은 철저히 자신의 소스코드가 있어서 몇 개 프로젝트를 제외하고는 서로 공동으로 개발하는 경우가 거의 없다. 프로젝트도 거의 혼자서 담당하며 한 사람이 여러 프로젝트를 맡는 경우도 있다. 

이러다 보니 다른 사람의 소스코드를 볼 일이 거의 없다. 소스코드 뿐만 아니라 프로젝트간 정보 교류도 매우 적다. 이슈관리시스템을 사용하지 않고 공유 문화도 매우 취약한 회사다. 

그래서 개발자가 한 명만 아파서 못나와도 프로젝트에 큰 타격이 생기며 다른 개발자가 도와주기도 쉽지 않다. 개발 일이 한쪽으로 몰려도 어차피 소스코드별로 개발자가 정해져 있어 놀고 있는 개발자가 있어도 도와주지 못한다. 

부서마다 조금씩 다르지만 신입 개발자가 입사해 제대로 일하려면 수개월 정도는 공부를 해야 한다고 한다. 기존의 소스코드를 익히고 기반 지식을 공부하는데 수개월이 걸린다. 개발자가 퇴사할 때마다 개발팀은 큰 곤욕을 치르지만 경영진은 개발자를 아끼지 않는 것 같다는 하소연을 한다. 잦은 릴리즈와 고객 밀착형 유지보수 서비스로 개발자들은 이미 지쳐있다. 

우리는 이런 현상을 속된말로 '몸빵'이라고 한다. 개발사가 개발을 주도를 하지 못하고 고객에 끌려 다니면서 그때 그때 대응에 집중하는 것이다. 이런 환경에서는 계획으로 개발을 하지 못하고 격무를 피하기 어렵다. 아키텍처도 깔끔하게 유지하기 쉽지 않다. 

한편으로는 '컴포넌트 오너'라고 하는 현상인데 컴포넌트(Component)별로 주인이 정해져 있어서 다른 사람은 못 건드는 것이다. 이것은 비단 A사만의 얘기가 아니다. 국내 많은 개발자들이 자신이 작성한 소스코드에서 벗어나지 못하고 한 분야에서 계속 땅굴을 파 내려가 경험의 폭이 좁아지고 고급 개발자로 성장하기 어려운 환경에 처해 있다. 한쪽 분야의 숙련공이 될 수 있어도 고급 개발자가 되기는 쉽지 않다. 

국내 B사는 개발자만 수백명에 달하는 누구나 아는 회사다. B사는 이미 이런 문제를 겪었고 이를 타개하고자 개발자풀 제도를 시도했다. 과거에는 개발자를 팀별로 나눠서 팀내에서 주어진 일을 했는데 개발자 풀 제도를 통해 비효율적인 인력운영을 효율적인 체계로 바꾸고자 했다.

팀구분 없이 개발자를 한군데 모아 놓고 프로젝트 관리자가 프로젝트마다 필요한 개발자를 선별해서 개발을 진행하고 프로젝트가 끝나면 개발자는 다시 개발자풀로 돌아가는 방식이다. 잘 활용하면 팀의 구분 없이 최적의 개발자를 투입할 수 있고 한쪽 프로젝트에 일이 쏠려도 개발자들이 도와주기 용이하다. 개발자들은 회사의 여러 프로젝트에 투입되기 때문에 자연스럽게 지식을 공유하게 된다. 

취지는 좋으나 철저한 준비과정 없이 조직만 그렇게 바꿔 놓으니 일이 제대로 진행되지 않았다. 각자 전문분야가 다르니 다른 개발자를 투입해서는 일이 안됐고 결국 해당 일을 하던 개발자를 투입해야 했다. 매트릭스 조직이라 프로젝트 관리자와는 별도로 팀장이 따로 있으니 프로젝트에 특정 개발자가 필요해도 팀에서 개발자를 내놓지 않으면 프로젝트는 진행하기가 어려웠다. 

사람을 아무리 많이 투입해도 원래 개발자의 직접적인 도움 없이는 프로젝트를 수행할 수 없었다. 계속되는 혼란을 한참 겪은 B사는 결국 개발자 풀 제도를 포기하고 말았다. 

조직이나 프로세스만 바꿔서 역량을 향상하거나 효율적인 개발을 기대하기는 어렵다는 것을 경영진이 이해하지 못한 사례라고 할 수 있다. 

미국 F사의 경우는 개발자가 수천명에 달하는 글로벌회사다. 개발자가 새로 입사를 하면 오리엔테이션 기간에 실제 서비스가 되고 있는 시스템 버그를 고쳐야 한다. 입사 첫날부터 개발에 직접 투입되는 것이다. 신규 입사자 중에는 해당 개발언어로 개발을 해본 적이 없는 사람도 있다. 

하지만 버그를 고치는데 문제가 없다. 어차피 경험한 개발언어를 보고 개발자를 뽑은 것이 아니고 기초가 튼튼하고 문제 해결 능력이 뛰어난 개발자들을 채용했기 때문이다. 멘토가 있기는 하지만 옆에 끼고 계속 가르쳐 주는 것은 아니다. 

F사 신규 입사자에게는 소스코드가 저장된 SVN(Subversion) 주소와 버그관리시스템인 Bugzilla 주소를 통해  처리할 버그가 할당된다.  아무도 버그를 고치는 방법과 알아야 할 지식을 가르쳐 주지 않는다. 하지만 시스템 스펙과 설계문서에 접근할 수 있고, Bugzilla를 통해서 기존 개발자에게 도움도 받을 수 있다. 

신규 입사자는 소스코드를 분석해 버그 원인을 찾을 수 있다. 소스코드의 각 라인 별로 언제 누가 수정을 한 코드인줄 즉시 알 수 있고 소스코드를 수정할 당시의 관련된 이슈도 확인이 가능하다.

이후 신규 입사자는 SVN에 고친 소스코드를 등록하기 전에 코드리뷰시스템에 등록을 해서 리뷰를 받아야 한다. 간단한 버그 수정은 아무 문제 없이 코드리뷰를 통과하겠지만 몇몇 이슈는 온라인으로 진행된 코드리뷰의 도움을 받아 수정하기도 한다.

이렇게 버그를 고치거나 작은 기능을 구현하는 일은 신규 개발자들이 처리한다. 실력을 인정 받으면 점점 어려운 일을 할당 받는다. 고참 개발자들은 어려운 일이나 스펙과 설계 작업을 주로 진행한다. 개발자는 언제든지 새로운 프로젝트에 투입되고 물론 자신이 관심 있는 프로젝트에 지원할 수도 있다. 많은 개발자가 퇴사해도 서비스에 별 문제가 없고 대부분 즐겁게 일한다. 

우리가 가야 할 길은 명확하다. 구멍가게를 할 것이 아니라면 컴포넌트 오너식 개발은 금방 한계에 다다른다. 혼자서 시작하는 스타트업도 F사처럼 개발을 하는 것이 더 빠르고 효율적이다. 과거의 나와 현재의 나도 공유를 해야 할 필요가 있다. 

혼자 개발해도 적절한 공유와 문서화를 했을 때 개발이 더 빠른 이유다. 어찌 보면 한 우물을 파는 것이 전문성 향상에 도움이 될 것 같지만 다양한 경험 없이 한 우물만 파내려가면 우물 속 개구리가 되고 말 것이다. 

소프트웨어 회사 개발팀의 꽃은 아키텍트다. 개발자들이 다같이 각자의 우물을 파내려 가는 환경에서는 뛰어난 아키텍트가 나오기 어렵다. 뛰어난 아키텍트가 없는 회사의 미래는 뻔하다. 2층짜리 집은 근근히 만들 수 있어도 100층짜리 빌딩을 어찌 아키텍트 없이 만들 수 있을까? 

그래서 국내 1등은 가능해도 딱 거기까지가 한계다. 더 심각한 문제는 이런 식의 개발 환경에서는 개발자가 행복하지 않다는 것이다. 야근을 반복해야 하며 고참이 되도 계속 과거의 코드에 발목을 잡혀서 앞으로 나아가기가 어렵다. 

고참이 더 바쁜 회사는 이런 함정에 빠진 경우다. 이직을 하면 고리가 끊어지지만 새로운 회사에서 똑 같은 일이 반복된다. 

이를 해결하는 기가 막힌 한가지 묘수가 있는 것은 아니다. 가장 중요한 공유문화를 비롯해서 성숙된 개발문화가 정착되면 자연스럽게 해결 된다. 개발문화를 소홀히 생각하고 프로세스만 강화해서는 절대로 F사와 같은 상황이 벌어지지 않는다. 이것이 다같이 성숙한 개발문화에 정착에 힘을 써야 하는 이유다. 

CMMI는 회사를 망칠 수도 있다

필자는 최근 소프트웨어와 시스템 공학 역량의 성숙도를 평가하는 CMMI(Capability Maturity Model Integration)를 적용하여 오히려 어려워진 H사 직원 S씨를 만났다. 

그동안 SI회사 등 여러 곳에서 CMMI를 적용하였던 회사의 직원들을 많이 만나봤지만 SI회사도 아닌 이 회사의 사례는 독특해 칼럼에서 소개할까 한다. 

CMMI를 폄훼하려는 의도가 있는 것은 전혀 아니니 오해는 하지 말아주기 바란다. CMMI에 대한 오해와 서투른 기대를 경계하자는 것이다. 이는 CMMI 뿐만 아니라 수많은 방법론에도 똑같이 해당한다. 

H사는 최근 촉망받는 분야의 서비스를 하는 회사다. 직원이 100명 가까이 되는 작지 않는 회사지만 개발에 관련된 변변한 문서가 하나도 없다. 스펙, 설계서 뿐만 아니라 문서는 전무하다 시피하다. 개발 프로세스라고 할 만한 것도 없다보니, 주먹구구식으로 개발을 하고 있었다. 

고참 개발자라고 하는 사람들도 코딩만 꽤 할 줄 알았지 개발 프로세스가 뭔지도 모르고 협업에는 별로 관심도 없는 상태였다고 한다. 

이에 H사 대표는 이대로는 안되겠으니 컨설팅을 받아봐야겠다고 생각 했다. 그래서 선택한 컨설팅 회사가 CMMI를 전문적으로 컨설팅하는 국내 회사인 P사였다. 

P사는 CMMI 레벨3를 적용하자고 제안했고 직원들은 회사 내부에서 관련 교육을 받았다. 외부에 나가서도 수차례 교육을 받았다. P사는 회사의 기존 프로세스와 그나마 있었던 문서를 분석해서 CMMI 레벨3 기준으로 개발 프로세스를 만들고 수십가지의 문서 탬플릿을 만들어서 제안했다. 

실제 프로젝트에 이 프로세스와 문서 탬플릿을 적용하기 시작했는데 교육을 받기는 했지만 요구하는 수많은 문서를 만들어내기는 보통 어려운 일이 아니었다. 또 촉박한 프로젝트 일정에 문서까지 추가로 만드는 것은 죽을 맛이었다고 한다. 이에 개발자 및 사업부에서는 반발이 매우 심했고, CMMI를 적용하느라 몇개 프로젝트는 포기를 해야 하는 상황까지 발생했다고 한다. 

이런 상황에서 개발자들이 선택한 방법은 어처구니는 없는 것이었다. 문서에 적어야 하는 기능의 개수를 줄이기 시작한 것이다. 

기능하나에 서로 연결해서 작성해야 하는 문서가 많아서 전체 문서 양이 매우 많았다. 예를 들어 실제로는 500개 기능인 프로젝트에서 문서에는 100개만 적으면 문서 개수가 많아도 전체 작성해야 하는 문서의 양은 줄어들게 된다. 그렇게 해서 요구하는 문서와 프로세스를 따랐다고 한다. 정해진 일정에 요구하는 문서를 만들어 내려면 어쩔 수 없다고 한다. 

CMMI를 적용한 프로젝트에 참여했던 S씨는 해당 프로젝트에서 20여가지 문서를 만들었지만 실제 프로젝트에 쓰인것은 SRS와 WBS 문서 2개 밖에 없다고 했다. 나머지 20여가지 문서는 컨설팅 회사에서 요구하기 때문에 만들었을 뿐이라고 한다. 프로젝트 중간이나 프로젝트가 끝난 후에도 나머지 문서들은 볼일이 없을 것이라고 한다. 

H사는 그 뒤로 개발역량 향상은 커녕 CMMI의 직접적인 영향을 아니겠지만 매우 어려운 상태에 놓이게 되었다. 

이론적으로 CMMI를 통해 SW공학의 성숙도를 측정하고 역량을 향상할 수 있다. 하지만 오해와 잘못된 적용 방식이 국내에서는 큰 문제가 되고 있다. 역량 수준이 한참 못미치는데 억지로 요구하는 수준에 맞추기 위해서 문서를 만들어내고 프로세스를 따르는 것이다. 그렇게 해서는 역량이 향상될리 없다. 이런 일이 빈번하여 한국이 블랙리스트에 올랐다는 소문도 파다하다. 

CMMI가 필요한 분야도 있다. 대표적인 분야가 국방일 것이다. 국방 프로젝트는 1달러짜리 나사를 사기 위해서 프로세스와 문서를 적용하여 50달러를 투입해야 할 때도 있는 프로젝트다. 민간 프로젝트와는 성격이 다른 중요도가 있는 프로젝트이다. 

그 외에도 CMMI 인증이 필요한 프로젝트가 있다. 역량이 안되더라도 비즈니스 목적으로 CMMI를 적용하는 것은 그럴 수도 있다고 생각한다. 개발에는 별로 도움이 안되고 영업에는 도움이 될 것이다. 

하지만 순수하게 소프트웨어 개발 역량을 높이기 위해서 단기간에 CMMI를 적용하는 것은 별로 좋은 방법이 아니다. 실전적인 방법으로 내실을 다지는 것이 더 낫다. 

적당할 예 일지는 모르겠지만 타이거 우즈가 CMMI 레벨5 수준으로 골프를 친다고 가정하자. 타이거 우즈는 CMMI 레벨5로 골프를 치기 위해서 골프 스윙시 25가지의 절차와 고려사항을 눈깜짝할 사이에 적용해서 공을 친다. CMMI 레벨5에서는 그 25가지의 절차를 잘 분석해 놨다. 

나는 주말골퍼인데 코치가 그 25가지 절차를 따르면 타이거우즈처럼 골프를 칠수 있다고 한다. 1년을 그렇게 연습한다고 타이거 우즈처럼 골프를 칠 수 있을까? 타이거 우즈는 이미 성숙도가 높고 몸에 완전히 베어 있어서 25가지의 절차를 아무렇지도 않게 수행할 수 있지만 나는 그렇게 할 수가 없다. 

그것을 따라하다가는 오히려 골프를 더 못치게 된다. 현재 상황에서 필요한 것을 하나씩 배우는 것이 훨씬 낫다. 또한 대부분의 실용적인 소프트웨어 개발 현장에서는 그 수준까지는 필요하지도 않다. 

사대주의도 아니고 바다건너의 멋진 모델에 현혹되는 사례가 유난히 우리나라에는 많은 것 같다. 실리콘밸리에서 오래 개발한 개발자들에게 물어봐도 CMMI는 관심도 없고 주변에 적용한 회사는 본적도 없다고 한다. 그만큼 실전적이고 실용주의적인 개발을 지향하는 곳이라면 성숙된 개발 문화와 개발 본연의 역량 향상에 힘을 쓴다. 뛰어난 아키텍트 발굴도 그 일환이다. 

이는 비단 CMMI만의 이야기가 아니다. 수많은 방법론도 마찬가지다. 그자체로는 훌륭할지는 몰라도 적절한 곳에 적용을 해야 하며 우리 회사에서 필요한 것인지는 잘 생각해봐야 한다. 

필자는 좀더 효율적으로 개발을 하기 위해서는 성숙된 개발문화를 정착하기 위해 노력해야 한다고 생각한다. 실용적이고 실전적이지 않은 모든 절차와 프로세스는 짐이 될 뿐이다.

이글은  ZDNet Korea에 기고한 칼럼입니다.

실리콘밸리 개발자 눈에 비친 한국 SW회사

얼마 전 실리콘밸리의 한 개발자 B씨를 만나서 소프트웨어 개발에 대해 많은 얘기를 나눴다. 과거에 같이 일했던 친구인데 미국에서 태어난 중국인으로 미국 대학을 나와 실리콘밸리에서 20여년간 개발자로 일을 했으며 10여년간은 몇몇 회사에서 CTO로 있었던 친구다. 

B씨는 최근에 한국 소프트웨어 회사(가칭 A사)와 많은 교류를 한 모양이다. 한국 회사에 자사 기술을 전수하기 위해서 실리콘밸리와 한국을 오가며 수개월간 한국 개발자들과 같이 개발을 해왔다고 한다. 그 과정에서 A사에 대해서 느낀 점을 필자에게 얘기를 해줬는데 A사 뿐만 아니라 우리나라 여러 회사에 공통적으로 해당하는 내용이 있어 소개할까 한다. 

B씨는 일단 처음에 A사가 어떻게 돌아가는지 파악했다.  그런데 이상한 생각이 들었다고 한다. 규모가 꽤 큰 서비스인데 시스템에 버그가 너무 많고 문제가 자주 발생한 것이다.

직원들의 야근도 너무 잦았다. 또 스크럼을 도입해 개발한다고 하는데 제대로 효과를 보는 것 같지는 않아 보였다. 그런만큼 B씨는 A사가 스크럼이든 설계든 개발 절차에 담긴 진의를 파악하지 못하고 형식만 흉내를 내는 것이 아닌가 생각이 들었다고 한다. 

이에 나는 B씨에게 “설계에서 제일 중요한 것이 무엇인가?”라고 질문했다. B씨는 “설계에서 제일 중요한 것은 콤포넌트를 잘 나누는 것”이라는 당연한 얘기를 했다.

B씨는 계속 얘기를 했다. 설계에 UML을 사용했는데 보통 UML은 필요가 없다. 우리는 대부분 칠판에 설계를 하다가 고치기를 반복한 후 사진을 찍어서 문서에 포함한다. 툴을 이용해서 다시 그리는 것은 시간 낭비다. 마지막 버전을 툴로 그리기도 하는데 정해진 툴도 없다. UML을 이용해서 쓸모도 없는 다이어그램을 잔뜩 만든 문서는 개발에 도움이 안되고 오히려 방해가 된다. 툴을 이용하면 칠판보다 고치기가 어렵고 다이어그램을 많이 그릴수록 고치는데 시간이 많이 들어가 바로 고칠 수가 없다. 또 A사 설계는 콤포넌트가 명확히 구분되어 있지 않아서 나눠서 협업하기 어려웠고 반대로 설계 내용은 너무 상세해서 오히려 비효율적이었다. 

나도 동감을 했다. 개발자가 알아서 할 부분까지 설계를 할 필요는 없다. 겉보기에는 A사의 설계서가 실리콘밸리의 한 개발자가 칠판에 끄적거린 설계서보다 멋져 보이고 전문적인 것 같지만 실전에선 훨씬 비효율적이다.  

설계를 어떻게 해야 하는지는 소프트웨어 성격에 따라 다르지만 설계 원리와 진의를 모르고 많은 다이어그램과 상세한 설계서는 식제 개발을 할때는 별로 도움이 되지 않는다. 많은 회사들이 UML 등을 이용해 완벽한 설계서를 만들려고 하는 경우가  많은데 그런 시도가 성공적이었는지 생각해볼 필요가 있다. 

B씨가 A사에 대해 또 이상하게 생각한 것은 애자일(Agile)을 적용한 방식이다. 실리콘밸리 스타트업은 거의 대부분 애자일 개발 방법론을 적용하고 있다고 보면 된다. 애자일은 특별한 것이 아니다. 과거부터 해오던 방식과 비슷하다. XP를 도입한 회사도 있고 스크럼을 쓰는 회사도 있는데 회사마다 필요한 것을 활용하고 있다. B씨 회사는 XP의 페어 프로그래밍(Pair programming)과 TDD를 사용중이다. 

과거 프로젝트에서는SRS를 썼는데 지금은 TDD로 바꿨다. 테스트는 거의 자동화 되어 있고 별도 테스터가 없어도 시스템에 버그는 거의 없다. A사의 경우 컨설팅을 받아 애자일을 적용했는데 들어보면 별로 애자일스럽지 않아 보인다. 마케팅적으로 요구사항이 신속히 바뀔 뿐인 것 같다. 

시스템이 복잡하여 야근도 잦은 것 같다. 또 개발자의 자유도도 낮아 보인다. 쓸데없는 문서도 많이 만들어야 하고 테스트도 오래 걸린다. 그러다 보니 시스템에는 항상 버그가 잔뜩 있다. 

이상한 점은 또 있다. 비싼 툴을 너무 많이 쓴다는 것이다. 그 친구는 실리콘밸리에서 주로 스타트업 에 많이 다녔는데, 한국 회사처럼 툴을 그렇게 많이 사용하지는 않았다고 한다. 지금 다니는 회사는 서브버전(Subversion)과 트랙(Trac)만 쓰고 있는데 회사를 지금 시작했다면 Git를 선택했을 것이라고 한다. 그렇다고 굳이 지금 서브버전을 Git로 바꿀 생각은 없다. 

나머지 필요한 툴은 간단한 스크립트로 만들어서 쓰고 있다. 그에 비해 A사를 비롯해서 많은 한국 회사들은 일단 툴을 많이 사용한다.  비싼 툴을 사는 경우도 상당히 많다. 회사 역량에 비해서 툴을 과도하게 사용하는 것은 그렇게 효율적이지 않다. 툴은 하나를 쓰더라도 제대로 사용해야 한다. 

그리고 A사는 직원들에게 노트북을 지급했다고 하는데 직원들이 노트북을 집에 가져가서 일을 하지 않는 점이 이상하다. 실리콘밸리에서 스타트업에 다니는 개발자들은 거의 노트북을 집에 가져가서 장소를 구분하지 않고 일을 한다. 개발자마다 다르지만 그 친구는 늦게 출근하고 일찍 퇴근하지만 노트북을 가지고 다니면서 장소에 구애 받지 않고 하루에 10시간 이상 일을 한다고 한다. 

A사는 야근도 꽤 많이 하지만 집에 가서는 일을 하지 않는 것이 이상해 보였다. 한국의 모든 개발자가 그런 것은 아니지만 재택근무가 일상화된 실리콘밸리와 한국은 좀 다른 것 같다. 

물론 한 개인이 한 회사를 보고 느낀 점을 얘기한 것이기 때문에 우리나라의 모든 회사가 그렇다는 것은 아니다. 그렇지만 B씨와 나눈 얘기들에서 생각해 볼 요소는 많다. 국내 여러 기업이 실리콘밸리의 개발문화와 개발방식을 적용하려고 노력하고 있지만 대부분 원리와 의미는 파악하지 못하고 수박 겉핧기 식으로 형식만 흉내를 내고 있다. 

설계는 하지만 설계를 왜 하는지를 잘 모르고 애자일을 적용하면서 그 원리를 모르고 남들은 어떻게 하는지 보고 흉내를 내는 것이다. 원리는 같지만 회사마다 적용하는 방식이 다르기 때문에 남들을 보고 흉내 내거나 인터넷이나 책을 보고 적용하면 이런 현상이 벌어진다. 

단순 흉내에서 벗어나려면 무엇을 하나 하더라도 그 진의를 파악하는데 노력해야 한다. 주변에서 흔히 "남들은 어떻게 하나요?", "템플릿(Template)을 가져다 주면 해볼께요.", "샘플을 보여주세요."와 같은 얘기를 한다. 남들이 만들어 놓은 설계서 샘플을 가져다가 흉내를 내면 자칫 아니 한만 못한 경우도 많다. 샘플이 득보다는 독이 되는 경우가 많다. 

샘플보다는 이걸 왜 하는지 원리를 파악하려고 노력해야 한다. 스스로 진의를 파악하기 어렵다면 주변에 멘토가 될만한 사람에게 물어보고 도움을 받는 것이 좋다.

이글은 ZDNet에 기고한 칼럼입니다.

개발 프로세스 관료화의 함정

소프트웨어를 효율적으로 개발하는 비법 아닌 비법은 개발 프로세스와 개발 문화의 적절한 균형에 있다. 김치를 담그는 레시피처럼 확실한 비율을 정하기는 어렵다. 개발 프로세스는 양날의 칼이다. 적절히 사용하면 개발 효율은 올라가지만 조금만 잘못 써도 개발 생산성이 떨어질 뿐만 아니라 개발자 성장까지 저해하여 회사와 개발자 모두의 미래를 어둡게 만든다.

다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에 따라 잡은 분야가 꽤 있다. 하지만 소프트웨어는 기껏해야 60년 역사인데 따라잡기가 훨씬 어렵다. 개별 개발자들의 프로그래밍 실력은 결코 뒤진다고 볼 수는 없다. 하지만 전반적인 개발문화의 차이가 격차를 좁히지 못하는 원인 중 하나다. 

소프트웨어 분야에 대한 투자는 개발자 인원수 늘리기와 프로세스 강화에 많이 치우친 경향이 있다. 소프트웨어도 시그마6 등과 같은 기법을 따와서 프로세스를 강화하면 좋은 성과를 낼 수 있을 것으로 착각했기 때문이다.

이렇게 프로세스에 집중하면 '파킨슨의 법칙'처럼 프로세스 관료화의 함정에 빠지기 쉽다. 프로세스는 회사의 변화에 따라 끊임없이 효율적으로 개선이 되어야 하는데 관료화된 조직은 프로세스가 점점 복잡해지지 단순해지지는 않는다. 프로세스가 단순해지고 효율적으로 바뀌면 일이 없어지는 사람이 있기 때문에 점점 복잡하게 만들려는 경향이 있다. 

물론 모든 기업이 그런 것은 아니다. 이런 함정에 빠지지 않은 기업도 있고, 이 단계를 극복해 나가는 기업이 있다는 것을 알고 있다. 하지만 많은 기업들이 이미 프로세스 관료화의 함정에 빠져서 허우적대거나 관료화의 길로 달려가고 있다. 이를 경계하자는 것이다.

그럼 개발 프로세스가 빠지기 쉬운 함정에는 어떤 것이 있는지 알아보자. 

첫째, 현실성이 부족한 프로세스다. 

실제 개발 현장에서는 벌어지지 않는 교과서에나 나오는 것을 실제 개발에 적용하려는 것이다. 가장 광범위하게 벌어지고 있는 현상 중 하나다. 인터넷에서 돌아다니는 지식이나 책을 보고 따라 하거나 소프트웨어 공학을 전공했지만 실전 경험이 부족한 경우 자주 벌어진다. 개발 단계별로 너무 많은 문서를 요구하거나 승인을 필요로 하는 프로세스가 있다. 

원자력 발전소를 만들 때나 필요함직한 문서들을 일반 소프트웨어에서 요구하기도 한다. 이런 문서는 개발할 때도 도움이 안되고 개발 후 유지보수 때도 별로 쓸모가 없게 된다. 마켓요구사항과 기능, 모듈을 추적하기 위해서 추적 매트릭스를 의무적으로 요구하는 프로세스도 있다. 

교과서에서 본적이 있을지는 몰라도 대부분의 소프트웨어에서는 필요도 없고 오히려 방해만 되는 프로세스다. 이렇듯 현실성이 부족한 프로세스는 너무나 흔하다. 개발자들은 어쩔 수 없이 따르는 척은 하지만 대부분 피해가는 요령만 늘게 되고 개발 경험이 쌓이면서 자연스럽게 역량이 성장하는 것을 방해하게 된다. 

개발 프로세스는 성숙된 개발환경에서 수십년 실전 경험이 풍부한 CTO급 개발자가 이끌어야 현실성 있고 효율적으로 만들 수 있다. 

둘째, 너무 상세하고 획일화된 프로세스다. 

프로세스팀이 너무 일을 열심히 하려고 할 때 발생한다. 프로세스는 모든 개발절차를 상세히 정의하기 보다 문제가 될 수 있는 핵심적인 요소를 잘 집어내는 것이 중요하다. 법률에도 비슷한 현상이 있다. 할 수 있는 것을 정의해서 법에 정한 것만 할 수 있게 하거나 하면 안되는 것을 정의해서 그 외에는 모두 할 수 있게 하는 방법이 있다.

모든 절차를 너무 상세하게 정의하면 개발자의 창의성을 저해하고 비효율적으로 흐를 수 있다. 오타 하나를 수정한 경우에도 작성해야 할 문서가 몇 개나 되고 절차도 일주일 이상 걸린다는 하소연을 들은 적이 있다. 개발자에게 자유도가 없이 몇 가지 경우로 획일화된 프로세스에서는 효율적으로 개발을 하기가 어렵다. 

개발자를 믿지 못하기 때문에 개발자에게 자유도를 주지 않는 경우이다. 

최근에 한 기업의 프로세스팀 리더를 만난 적이 있는데 설계문서를 매우 상세하게 작성을 해야 하며 꼭 UML로 작성을 해야 한다고 했다. UML을 이용하지 않고 개발자가 제각각 작성하면 서로 의미가 통하지 않을 수 있다고 한다. 나는 그럴 필요가 없고 개발자가 가장 편하게 작성할 수 있는 방법이면 되고 꼭 UML을 쓸 필요도 없다고 했다. 

화이트보드나 종이에 끄적거리고 토론하다가 사진을 찍어서 문서에 첨부해도 된다고 했다. 물론 이 부분은 논란이 있을 수 있다. 스펙과 설계의 경계에 대한 생각이 다르고 설계를 상세하게 작성해야 개발자들이 코딩을 잘 할 수 있다고 획일적으로 생각하는 것도 문제다. 

설계란 상황에 따라서 필요한 만큼 자유롭게 적절히 하는 것이 중요하고 형식보다는 창의력이 더 필요하다. 
셋째, 잘못된 관행을 그대로 담은 프로세스다.

프로세스팀의 힘이 약한 경우에 발생한다. 개발 프로세스를 정의할 때는 현재의 문제점을 고치고 개발역량을 미래지향적으로 향상시킬 수 있는 방법을 녹여내야 한다. 하지만 현재의 관행적인 절차를 체계화하고 문서화해서 기존의 문제점을 그대로 유지한다면 그야말로 최악이다. 

절차화 되면서 기존에 개발자들이 자유도를 가지고 적절하게 판단하던 효율성도 사라졌고, 미래지향적이지도 않다. 기존의 문제가 점점 고착화 되어 갈 뿐이다. 

개발자들의 의견을 너무 존중해서 민주적인 다수결로 프로세스를 결정하는 것도 문제다. 변화를 싫어하는 것은 동서고금 똑같아서 대중의 의견을 따르면 프로세스는 대부분 실패한다. 

넷째, 벌칙만 잔뜩 담은 프로세스다.

프로세스는 잘못하면 벌을 주려는 형법과는 다른 것이다. 목적 자체가 다르다. 프로세스는 효율적인 개발을 하기 위한 최소한의 절차다. 그리고 프로세스를 따라서 꾸준히 개발을 하면 개발팀의 역량도 향상 되어야 한다. 따라서 적절한 독려와 벌칙이 있을 수는 있다. 하지만 벌칙만 잔뜩 존재한다면 벌칙을 피해 다니는데 집중하게 된다. 물론 치명적인 잘못에 대해서는 벌칙이 있을 수 있다. 치명적인 잘못에는 다음과 같은 것들이 있다. 

-소스코드를 빌드가안되는브로큰 트리(Broken tree)를 만든 경우 
-백업 담당자가 백업을 소홀히 한 경우 
-소스코드를 소스코드관리시스템에 등록하지 않은 경우 
-핵심 프로세스를 따르지 않아서 큰 장애를 만들어 낸 경우 

여기서 버그를 만든 경우는 벌을 받아야 할 만큼 큰 잘못은 아니다. 그런데 버그를 카운트해서 불이익을 주거나 프로세스의 모든 사소한 사항까지 벌칙과 연계를 하면 숨막혀서 개발하기가 쉽지 않다. 

다섯째, 점점 복잡해지는 프로세스다. 

회사는 계속 바뀌고 제품 및 개발팀도 계속 성장한다. 그러면서 프로세스도 계속 진화를 한다. 그런데 매번 프로세스가 점점 복잡해지는 회사들이 많다. 무슨 문제가 있을 때마다 원인을 분석하고 대책을 수립한다고 하면서 확인 절차를 더 추가하고 문서를 더 만들어 내는 것이다. 

이렇게 문제가 있을 때마다 대책을 수립한다고 하면 초 단기적인 대책밖에는 만들어 낼 수 없다. 예를 들어서 근본 원인이 '공유의 문화'가 부족해서라고 해도 수년 걸리는 '공유의 문화' 개선보다는 당장 눈에 보이는 형식적인 절차를 끼워 넣을 수 밖에 없다. 

냄비 안의 개구리는 점점 따뜻해져 오는 물을 느끼지 못하지만 나중에 밖에서 프로세스를 보게 되면 괴상망측하게 변화된 것을 알 수 있다. 프로세스는 역량과 문화 수준이 향상됨에 따라서 점차 간소하게 바뀌어야 한다. 기존에는 프로세스로 강제화하던 것이 몸에 베이게 되면 간단하게 바꿔야 더 효율적이다. 

여섯째, 관료화된 프로세스다.

관료화된 조직에서 흔히 벌어지는 일이다. 개발 문제를 해결하기 위해서 프로세스를 강조하다 보면 프로세스 자체가 목적이 되기도 한다. 효율적인 방법이 눈에 뻔히 보이는 경우에도 프로세스가 그러하니 따라야 한다고 하게 된다. 개발 생산성 향상이라는 목표는 저 멀리 떠나 보내고 각자 팀의 이익을 쫓다 보면 프로세스가 점점 관료화로 치닫게 된다. 

가끔은 없어도 되는 절차를 일부러 만들기도 한다. 개발자들은 이를 피해가는 요령만 늘게 된다. 

물론 열심히 노력하고 잘하는 프로세스팀이 더 많지만 그 중에는 개발 효율성보다는 스스로의 일거리를 늘리고 힘을 키우기 위해서 프로세스를 더 복잡하게 만들고 개발에 끼어드는 경우가 있다. 프로세스팀이 모든 개발 절차를 감시하고 산출물을 검토하고 승인에 끼어드는 경우 관료화게 빠지기 쉽다. 도와주는 역할을 넘어서 스스로 권력화가 되는 것이다. 

결론은 개발 프로세스는 현실적이며 자율적이어야 하고 개발 문화와 균형을 이뤄야 한다. 아직 자율에 맡기기에는 불안하다고 하면 프로세스를 너무 복잡하게 하지 말고 핵심적인 것부터 조금씩 적용하는 것이 좋다. 
개발자가 즐겁게 일할 수 있는 환경이 가장 생산성이 높은 환경이다. 개발 프로세스를 엄격하게 강화하여 소프트웨어 개발 문제를 해결 할 수 있다는 생각부터 잘못된 것이다. 적절한 개발 문화가 뒷받침되지 않는 프로세스는 오히려 짐이 될 뿐이다. 

눈에 보이는 프로세스에는 투자를 하기가 쉬워도 눈에 잘 안 보이는 개발문화는 어떻게 투자를 해야 할지 막막하다. 자칫 잘못하면 사무실 환경이나 슬로건만 흉내를 내는 꼴이 될 수도 있다. 

문화가 바뀌려면 생각이 먼저 바뀌어야 행동이 바뀐다. 하지만 생각은 그렇게 쉽게 바뀌지 않는다. 힘이 있는 선구자가 끊임없이 생각의 변화를 이끌어야 한다. 프로세스가 관료화에 빠지지 않으려면 CTO급의 특급 개발자가 실전 개발 기법을 프로세스에 적용하고 개발문화 향상을 꾸준히 이끌 수 있도록 해야 한다. 

미신과 같은 이론 전문가들의 말과 인터넷에 떠도는 소문에 현혹되지 말고 진짜 전문가인 개발 전문가들을 보호하고 힘을 실어줄 때가 변화의 시작 시점일 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

제대로 된 코드리뷰가 힘든 이유(개발문화 시리즈10)

두달넘게 소프트웨어 개발문화에 관련된 칼럼을 쓰고 있다. 문화란 한쪽이 일방적으로 잘못되었다기 보다는 서로 다른 부분이 많은 것이다. 그러한 우리 문화 중 소프트웨어 개발에 불리한 부분을 짚어보고 같이 고민해보자는 의미로 칼럼을 쓰고 있다.

문화란 공동체의 비슷한 생각과 행동이다. 공동체에 속한 사람은 당연히 하는 행동도 다른 문화를 가진 사람들은 지식적으로는 알고 있어도 쉽게 따라하기 정말 어렵다. 개인의 습관은 개인의 의지로 고칠 수 있지만 집단의 문화는 바꾸기가 훨씬 어렵다. 

그래서 개발문화는 우리가 흔히 알고 있는 것도 제대로 정착시키기가 힘들다. 그중에서 대표적이고 중요한 것이 '리뷰 문화'다. 

소프트웨어 개발에 있어 가장 중요한 문화 중 하나인 “리뷰문화”가 제대로 정착된 회사를 우리나라에서 찾기란 그렇게 쉬운 일이 아니다. 다들 그 중요성은 알고 있지만 대부분은 시도해보고 포기하기를 반복하곤 한다. 

왜 그렇게 리뷰가 어려울까? 

가장 흔히 하는 얘기는 리뷰할 시간이 없다는 것이다. 물론 이것은 단기적으로는 오해지만 이해가 안가는 것은 아니다. 매일 일정에 쫓겨서 간신히 구현만 하기에도 허덕인다. 통계 상으로는 적절한 리뷰를 하는 것이 총 개발시간 및 비용을 절약해 준다고는 하지만 이것은 손에 잡히지 않는 이상의 세계와도 같다.

많은 회사들이 리뷰를 특히, 코드리뷰를 강제화하곤 하는데 그 결과 효율적인 리뷰가 되기보다는 의무적인 리뷰로 변질되면서 리뷰에 대한 나쁜 기억만 쌓이게 된다. 그러다보면 리뷰문화가 제대로 정착하지 못하고 포기하거나 강제화 덕에 비효율적이지만 명맥만 유지하게 된다. 

리뷰문화는 어렵다고 포기해도 될만큼 사소하지 않다. 

리뷰에는 여러가지 목적이 있다. 오류검출외에 공유, 교육의 목적도 있다. 품질 향상을 위해 리뷰를 하지만 리뷰를 통해서 지식 및 정보가 공유되고 노하우가 전달되며 개발자들이 서로 성장하게 된다. 지식공동체가 리뷰를 통해서 성장하게 되는 것이다. 사실 리뷰를 통하지 않고서는 개발자들의 핵심 역량이 성장하기는 어렵다.

리뷰가 활발하지 않다면 혼자서 책보고 인터넷보고 피아노를 배우는 것과 비슷하다. 더 많은 시행착오를 겪어야하며 느리게 성장하거나 좌절하게 된다. 자칫 우물안 개구리가 되거나 자아도취에 빠지기 쉽다. 이런 환경에서는 아마추어가 될 수는 있지만 프로가 되기는 어렵다. 

그럼 리뷰를 제대로 하려면 어떻게 해야 할까? 리뷰 문화가 잘 정착된 곳에서는 어떻게 리뷰를 하고 있을까? 

What, When, Who, How 4가 측면으로 살펴보자. 

What, 무엇을 리뷰하는가? 

'리뷰'하면 흔히 코드리뷰를 생각한다. 하지만 소스코드만 리뷰를 하는 것은 그렇게 효율적이지 못하다. 설계가 다 된 빌딩을 만들면서 벽돌 쌓는 것만 검토하는 것이다. 설계가 잘못되었다면 이미 되돌릴 수가 없다. 그리고 스펙과 설계가 공유가 안된 상태라면 소스코드를 봐도 리뷰할 것이 별로 없다. 기껏해야 코딩 규칙이나 문법 등 밖에 못본다. 

코드리뷰보다 더 중요한 것은 스펙과 설계 리뷰다. 스펙과 설계리뷰가 더 어려운 이유는 스펙과 설계를 제대로 작성하지 않기 때문이다. 아무리 스펙과 설계가 없어도 소스코드는 있기 때문에 코드리뷰는 항상 할 수 있다. 스펙과 설계를 제대로 작성하고 충분히 리뷰를 해야 한다. 코드리뷰 때보다 스펙과 설계 리뷰 시에 더 다양하고 중요한 것을 배우고 공유할 수 있다. 

When, 언제 리뷰하는가? 

코드리뷰를 포함해 리뷰의 실패로 이어지는 대표적인 방법은 나중에 몰아서 리뷰를 하는 것이다. 

피어데스크체크부터 인스펙션까지 코드리뷰의 종류도 여러가지가 있지만 별다른 전략없이 1주나 2주에 한번씩 개발자들이 모여서 지금까지 작성한 코드를 놓고 끝장 리뷰를 하곤 한다. 사전에 검토하지 않고 참석해서 내용을 파악하지도 못하고 장시간 모여 리뷰를 하게 되면 집중력이 떨어지고 형식적인 일이 되기 쉽다. 이렇게 잔뜩 개발을 해 놓고 검토를 한들 고치기도 어렵다.

성공적인 리뷰를 하려면 그때 그때 바로 해야 한다. 코드리뷰에서 가장 쉽게 성공할 수 있는 방법중 하나는 소스코드를 등록하기 전에 동료와 모니터를 보면서 5분~10분 정도 검토를 하는 것이다. 고칠 것이 있으면 바로 고칠 수 있다. 이것을피어데스크체크(Peer desk check)라고 하는데 가장 쉽게 적용할 수 있는 방법 중 하나다. 

이외에도 소스코드를 등록하고 나서 고친 내용을 이메일을 통해서 리뷰를 할 수도 있고 소스코드 리뷰시스템을 이용하면 좀더 수월하게 할 수 있다. 원격지에 있는 개발자와도 리뷰가 가능하다. 중요한 것인 코딩을 하고 즉시 리뷰를 하는 것이다. 물론 몇 시간의 시간 간격이 있지만 다시 고치기에 부담이 없는 시간이다. 

스펙을 작성하거나 설계를 할 때도 마찬가지다. 다 작성하고나서 한꺼번에 리뷰를 하는 것이 아니라 중간 중간 필요할 때마다 리뷰를 계속 하면서 작성해야 한다. 너무 자주는 아니지만 적절할 때 리뷰를 하는 것이 요령이다. 

Who, 누가 리뷰하는가? 

흔히 리뷰를 프로세스로 생각하고 승인을 받도록 한다. 그래서 팀장이나 고참 개발자들이 리뷰를 의무적으로 하도록 한다. 물론 내용적인 검토를 하기 위해서는 그렇게 해도 되지만 팀장이나 고참이 항상 리뷰를 할 수 없을 수도 있고 시간이 안될 수도 있다.

리뷰는 목적에 따라 다양한 사람들이 할 수 있다. 코드리뷰는 주로 고참개발자들이 진행하지만 개발자들끼리 서로 리뷰를 할 수도 있다. 내용에 따라서 어려운 것은 특별히 고참개발자를 지정해서 리뷰를 요청할 수도 있고 일반적인 것들은 동료와 같이 리뷰를 해도 공유의 목적을 달성하는 것이고 동료들끼리도 서로 배울 수 있는 것도 많다. 

스펙과 설계를 작성할 때는 각 분야의 전문가와 리뷰를 한다. 마케팅팀, 영업팀, QA팀 등과 해당 팀과 관련된 내용을 리뷰한다. 특히 설계를 할 때는 아키텍트들의 도움을 받고 특정 기술에 대해서는 해당 기술의 전문가의 리뷰를 받으면서 도움을 얻는다. 

따라서 리뷰자를 프로세스에 강제로 지정하면 비효율적인 리뷰가 될 수도 있다. 리뷰 내용과 목적에 따라서 적절한 사람이 리뷰를 할 수 있도록 해야 한다. 

How, 어떻게 리뷰하는가? 

리뷰는 감사(Audit)가 아니다. 리뷰를 하라고 하면 귀찮아하고 부담스러워하지만 리뷰는 누군가가 나를 도와준다고 생각하면 좋다. 또, 누군가가 나에게 리뷰를 부탁하면 나의 전문성을 가지고 누군가를 도와줘야 하는 일이므로 꼼꼼히 검토를 하고 최선을 다해야 한다.

고참이 될 수록 리뷰어(Reviewer)인 경우가 많다. 따라서 고참들은 리뷰를 할 수 있는 시간을 충분히 확보를 해야 한다. 이것을 일은 적게한다고 생각하면 안된다. 코딩 한줄 더 하는 것보다 리뷰를 해주는 것이 전체적으로 이익이기 때문에 그렇게 하는 것이다. 

리뷰를 하려면 우선 문서가 있어야 한다. 소스코드, 설계문서, 스펙문서가 있어야 한다. 바로 만나서 가볍게 하는 리뷰도 있지만 대부분은 미리 배포가 되고 검토를 한 후에 리뷰를 진행하는 것이 더 효율적이다. 또 항상 만나야 리뷰를 할 수 있는 것도 아니다. 온라인으로도 충분히 리뷰를 진행할 수 있다. 

가끔은 모여서 하는 리뷰가 훨씬 효율적일 때도 있다. 아키텍처 리뷰와 같은 회의가 그중 하나다. 하지만 많은 리뷰는 온라인으로도 충분히 진행할 수 있다. 

가끔은 체크리스트를 만들어서 리뷰를 하곤 하지만 체크리스트는 그렇게 효율적이지 못하다. 피아노를 잘 치는 방법 체크리스트 1천개가 있어도 별로 도움이 안된다. 전문가는 10초만 봐도 피아노 치는 방법을 어떻게 바꿔야 하는지 안다. 

대부분은 경험을 기반으로 리뷰를 하는 것이다. 자신의 경험과 전문적인 지식을 토대로 리뷰를 하고 도움을 주는 것이다. 체크리스트는 간접적인 도움이 될지는 몰라도 체크리스트를 잘 만든다고 해서 누가나 리뷰를 할 수 있도록 하게 할 수는 없다. 

만약에 리뷰를 잘하고 있는 회사에 개발자가 처음으로 입사를 했다면 자연스럽게 습관으로 익혔을 것이다. 그런데 그렇지 않은 회사에서 3,4년 일하다보면 리뷰를 안하는 것이 완전히 몸에 베이게 된다. 그리고 습관을 바꾸기가 정말 어렵다. 

세살버릇 여든간다고 하듯 개인적으로도 바꾸기 어렵지만 회사차원에서는 더욱 어렵다. 자율에 맡겨 놓으면 대부분 실패한다. 그렇다고 포기할 수는 없고 프로세스로 강제화하는 것이 시작하는 방법 중 하나다. 이미 리뷰 문화 정착에 실패한 경험이 있는 회사들은 실패의 원인을 잘 찾아야 한다. "이 산이 아닌가보다”가 반복되면 직원들의 거부감만 가득차게 된다.

리뷰를 강제화하되 벌칙보다는 포상으로 정착을 유도하는 것이 좋다. 제약사항을 너무 많이 만들어 놓는 것도 좋지 않다. 직원들의 적응 상태를 봐가면서 아주 천천히 한발씩 나가야 한다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.