빈 줄도 지워서는 안된다.

SVN을 쓸까? Git를 쓸까? 주제로 얘기를 하면 논쟁이 심하다. 하지만 이보다 더 중요한 것은 SVN이나Git와 상관없이 어떻게 하면 여러 개발자들과 협업이 잘 되도록 코딩을 하느냐다.

많은 개발자들은 혼자서 또는 소수의 인원과 개발을 한다. 또는 여러 명이 개발을 하더라도 자신의 소스코드가 딱 정해져 있어서 혼자 개발하는 경우가 많다. 이러다 보니 협업을 위한 개발에는 별로 관심이 없다. 하지만 협업은 혼자서 할 때도 필요한 것이고 여러 명이 개발할 때는 더욱더 필요하다. 방법을 모르거나 문제를 피해 다니면 개발 효율이 떨어지고 한계를 넘지 못한다.

혼자서 개발을 하더라도 수많은 브랜치가 발생할 수 있고 한두 명끼리는 그럭저럭 개발을 하더라도개발팀이 조금만 커져서 뒤죽박죽이 되곤 한다.

그럼 어떻게 코딩을 하는 것이 좋을까?

첫째, 빈 줄도 고쳐서는 안 된다.

내가 고치고 있는 모든 소스코드는 다른 개발자들도 지금 고치고 있다고 생각해야 한다. 설사 혼자서고치는 소스코드라고 하더라도 습관이 된다. 협업을 하고 있다는 마인드는 꾸준히 유지를 해야 한다. 

빈 줄 뿐만 아니다. Indentation이 맞지 않는다고 고치는 것도 좋지 않다. 괜히 연산자 사이에 보기 좋으라고 빈칸을 추가하는 것도 나쁘다. 무조건 처음에 잘해야 하고 나중에는 그냥 놔두는 것이 낫다.

둘째, 파일 이름을 바꾸지 말아야 한다.

처음에 대충 파일을 만들다 보면 파일이름이 마음에 안 드는 경우가 있다. 그렇다고 파일을 이름 바꾸면 수많은 사람들에게 영향을 준다. Git에서는 파일을 이름 변경을 추적해주는 기능이 있지만 혼란을피할 길을 없다. 처음에 잘 정해야 한다. 

셋째, 함수 이름과 정의를 바꾸지 않아야 한다.

대충 만들어 놓고 자꾸 바꾸는 것은 협업 습관이 없기 때문이다. 그리고 대충 만들고 나중에 수정하는것은 비용이 더 많이 든다. 아주 작은 시스템만 경험해 본 개발자는 이런 방법이 더 빠르다고 주장할지몰라도 큰 시스템에 개발자가 수십 명이라면 얘기가 달라진다. 대충하고 바꾸는 습관이 들어서는 안된다.

넷째, 소스코드를 재배치하지 말아야 한다.

파일의 아래쪽에 있는 함수를 위로 올리고 정리를 하면 소스코드 Merge가 어려워진다. 처음에 잘 생각해서 정하고 나중에는 고치지 말아야 한다. 여러 사람이 동시 소스코드를 정리하면 소스트리는 완전히 뒤죽박죽이 된다.

이미 문제가 발생한 경우 리팩토링이 필요하게 되고 계획을 잘 세워서 시행해야 하고 상당한 비용을 치뤄야 하는 경우도 있다. 이런 경우는 최소화하고 처음부터 제대로 하는 것이 훨씬 낫다.

이 외에도 변수를 어떻게 선언하느냐는 등 협업을 위한 수많은 코딩 노하우들이 있다. 항상 개발은혼자 하는 것이 아니다라는 것을 염두해 두고 개발하는 자세가 필요하다.

물론 위 내용들은 개발자 본인이 처한 환경에 따라서 천차만별로 생각할 수 있다. 혼자 개발하는 사람도 있고 수백명이 개발을 해도 혼자 일하는 것처럼 개발하는 경우도 많다. 수천명이 동시에 개발하는 환경에 있는 개발자도 있다. 

필자는 원칙과 원리에 대해서 얘기를 하는 것이니 원리에 대해서 이해를 해보는 노력을 해보자. 일하는 환경은 언제든지 바뀔 수 있지만 습관은 쉽게 바뀌지 않는다. 좋은 습관을 만들어가는 것은 본인의 몫이다.

55세 개발자가 막내인 개발팀

얼마전 미국 소프트웨어 회사인 P사의 호주 지사에서 일하고 있는 엔지니어를 만나서 얘기를 나눴다. P사는 본사가 캘리포니아에 있고 전체 개발자 수는100여명이다. 그리 크지 않은 회사지만 20년동안 꾸준히 성장을 해왔고, 소프트웨어 개발자라면 알만한 시스템을 개발하는 회사다. 
 
그 회사의 제품군을 알고 있는 사람들은 100여명 밖에 안되는 개발자들이 일하고 있다는 것에 놀랄것이다. 우리나라 소프트웨어 회사라면 20년간 커왔고 전 세계 많은 나라 기업들에서 사용하고 있는 시스템을 만든다면 개발자가 수백명에 육박할 것이다. 하지만 매우 적은 인원으로 효율적으로 개발하고 있다는 것은 놀라운일이다. 그런데 이렇게 효율적인 소프트웨어 회사가 우리나라 밖에는 엄청나게 많다. 
 
P사 제품의 코어엔진을 만드는 팀에는 7명의 개발자가 일하고 있다. 그중 제일 고참이 60세라고 한다. 막내는 55세다. 또 관리자의 나이가 가장 어리다. 60세 개발자는 회사 초창기부터 20년간 근무했다. 대충 짐작해도 35년은 엔지니어로 일하고 있는 것으로 보인다. 비단이 회사에만 이런 할아버지 개발자들이 있는 것은아니다. 개발자 본인이 원하고 실력이 된다면 20년, 30년 원하는 만큼 개발자로 일을할 수 있다. 
 
우리나라에서는 한 분야에서 오랫동안 한가지 제품만 개발하고 있는 개발자들의 걱정이 있다. 다양한 분야를 접하지 못하다 보니 경험이 제한되고 시야가 좁아지고 엔지니어로서의 가치가 떨어지는 것이 아닌가 하는 우려를 한다. 실제로 금융분야에서 10여년 일한 개발자를 보면 사용하고 있는 프레임워크만 알고 기계적인 코딩밖에 하지 못하는 경우를 종종 본다. 다른 분야도 마찬가지다. 그럼 한 분야에서만 일한 미국의 30년차 개발자도 그럴까? 물론 개인차가 있겠지만 개발하는 문화나 방식이 좀 다르기 때문에 상황은 다르다.
 
P사에서 개발하는 방식을 보자. 눈에 띄는 것은 개발 방법론이 어찌됐건간에 제품을 꾸준히 업그레이드하면서 코딩을 하기 전에 스펙 문서를 자세히 작성해서 전세계 많은 관련자와 세밀하게 리뷰를 한다. 스펙에는 아키텍처도 포함되어있다.  스펙은 개발자끼리만 리뷰를 하는 것이 아니다. 애플리케이션 개발자와 리뷰도하지만 QA엔지어와도 리뷰를하고 기술 지원 엔지니어 등 거의 모든 분야 관련자들과 리뷰를한다. 
 
리뷰는 그냥 훑어보는 것이 아니다. 자신이 담당하거나 전문인 분야의 지식을 총동원한 후 검토를 해서 향후 발생할 문제 등을 면밀히 분석하는 것이다. 이 과정에서 아주 기술적인 세밀한 부분까지 토론하고 논쟁한다.
 
이런 과정을 거치면 제품의 완성도는 훨씬 올라가고 아키텍트는 튼튼해진다. 이런 얘기를 들으면 우리도 시간이 충분하면 이렇게할 수 있다고 한다. 하지만 이런 생각은 착각이다. 이렇게 개발을 하기 때문에 적은 인원으로 더 빨리 개발을 하는 것이다. 논어에는 세명이 길을가면 그중에는 반드시 내 스승이 있다고 했다. 철저한 리뷰는 더 좋은 제품을 만들기도 하지만 리뷰를 통해서 많은것을 배운다. 개발자는 본인의 직접적인 경험과 책만으로 배우는 것은 한계가 있다. 여러 개발자와 또 개발자가 아니라도 여러분야의 전문가와 토론하면서 많은것을 배우게 된다.
 
우리나라 개발자들은 흔히 토론, 리뷰에 약하다. 토론의 경험도 적고 막상 토론을 하면 직급으로 누르거나상대방을 공격해서 상처를 주거나 논리적으로 진행되지 않는 경우가 많다. 한두번 이런 일을 겪고 나면 이런 자리는 자연스럽게 피하게 된다. 결국 혼자서 땅굴을 파는 것에 편하게 되고 그렇게 오랜시간 개발을 하다 보면 한 분야의 전문가는 될 수 있어도 다양한 경험과 통찰력을 가진 개발자로 발전하기는 힘들게 된다.
 
또, 주목할만한 것은  소프트웨어 선진국에서는 아주 흔한 근무형태지만 재택근무가 아주흔하다는 것이다. 위에 언급한 모든것의 진행이 온라인 시스템과 화상회의로 이루어진다. 장소에 구애 받지 않고 일하고 회의도 화상회의 시스템을 많이 이용하고 꼭 필요할 때만 회사에 나가도 된다. 이런 재택근무 문화는 개발자에게 일할 기회를 제공한다기보다는 장소에 구애받지 않고 회사가 뛰어난 엔지니어의 도움을 받을 수 있다고해석하는 것이 좋겠다. 
 
리뷰도 어차피 대양을 건너 세계 각국 많은전문가와 진행하는 것이기 때문에 한자리에서 같이 일할 필요는없다. 이렇게 뛰어난 엔지니어들이 모이면 서로의 성장에 도움이 된다. 온라인이 아니면 이런 엔지니어들이이렇게 같이 일을할 수 있겠는가?
 
이글을 읽는개발자라면 우리도 환경이 되면 이렇게할 수 있다고 생각할 수 있겠지만 막상 쉽지는 않다. 대부분의 엔지니어가 문서 작성을 코딩하는 것처럼 익숙해져 있고 잘 작성해야 한다. 이런 온라인 협업은 시스템과 문서로 진행이 되기 때문에 문서작성역량은 매우 중요하다. 많이 자세히 작성하는 것이 잘하는 것은아니다. 효율적으로 필요한 핵심 내용을 적절히 작성해야 한다. 고참 엔지니어가 될수록 문서작성능력은 더욱더 중요하다. 나뿐만 아니라 내 주변의 수많은 개발자들 이렇게 일을 할때 30년 이상 개발자로 즐겁게 일할 수 있을 것이다.

개발자간 공유 문화 정착이 힘든 이유

소프트웨어를 개발하는데 있어서 가장 중요한 문화 중 하나는 '공유’ 문화라고 할 수 있다. 소프트웨어개발 속도를 향상하고 비용을 절감하며 프로젝트 성공 확률을 높이는 중요 요소다. 뿐만 아니라 개발자들의 실력을 향상하고 개발자가 20년, 30년 계속 개발자로 일할 수 있도록 하는 기초 체력이기도 하다. 

하지만 우리나라에서 공유 문화를 제대로 갖추고 있는 회사를 찾아보기란 그리 쉽지 않다. 내 주변에는 소프트웨어 개발 문화에 관심을 가지고 있는 개발자가 많다. 특히 공유문화에 관심이 많아서 실천을 하려고 노력하는 경우도 많다. 하지만 그런 노력의 결과로 성공적으로 개발문화를 정착했다고 하는 소식은 잘 들려오지 않는다. 그 이유는 무엇일까?

여러 가지 이유가 있겠지만 그 첫 번째는 아직 공유에 노력을 하는 개발자들이 소수이기 때문이다. 

‘죄수 딜레마’라고 들어본 적이 있는가? 

상황은 다음과 같다. 두 명의 사건 용의자가 체포되어 서로 다른 취조실에서 격리되어 심문을 받고 있다. 이들에게 자백여부에 따라 다음의 선택이 가능하다.

•    둘 중 하나가 배신하여 죄를 자백하면 자백한 사람은 즉시 풀어주고 나머지 한 명이 10년을 복역해야 한다.

•    둘 모두 서로를 배신하여 죄를 자백하면 둘 모두 5년을 복역한다.

•    둘 모두 죄를 자백하지 않으면 둘 모두 6개월을 복역한다.

죄수A는 죄수B가 침묵할 것으로 생각되는 경우 자백을 하는 것이 유리하다. 죄수B가 자백할 것으로 되는 경우 자백이 유리하다. 따라서 죄수A는 죄수B가 어떤 선택을 하든지 자백을 선택한다.

죄수B도 죄수A와 동일한 상황이므로, 마찬가지로 죄수A가 어떤 선택을 하든지 자백이 유리하다.

따라서 둘 모두 자백을 하지 않는 것이 최선의 결과이지만 죄수 A, B 는 모두 자백을 선택하고 각각 5년씩 복역한다는 것이다.

이런 죄수딜레마를 게임으로 시뮬레이션을 해보면 죄수 둘이 서로 의논을 하게 하건, 죄수가 2명이 아니라 여러 명이건 상관없이 비슷한 결과가 나온다고 한다.

도로로 나가보자. 조금 막히는 교차로에서는 교차로 꼬리 물기가 아주 흔하다. 아무리 막히는 교차로라고 하더라도 꼬리물기를 하지 않으면 다같이 평균적으로 더 빨리 교차로를 빠져나갈 수 있다. 하지만 대중은 그런 선택을 하지 않는다. 다들 꼬리 물기를 하는 상황에서 나만 교통법규를 지키고 가만히있으면 교차로를 가장 늦게 통과하게 될 것이다. 심지어는 주변의 차들에게 욕먹을 각오도 해야 한다.꼬리 물기를 하는 차가 다수인 상황에서는 교통법규를 지키는 소수가 몇 배 더 손해를 보게 되어 있다. 그래서 어쩔 수 없이 다같이 손해를 보는 경우를 선택하게 된다.

몇 년 전 가족과 함께 괌의 한 리조트를 방문한 적이 있었다. 하지만 여기서 부끄러운 일을 목격했다. 수영장에는 충분한 선배드가 있는데 아침 9시쯤 수영장에 가보니 모든 선배드가 이미 임자가 있었다. 선배드에 타올을 하나씩 걸쳐 놓았지만 선배드에서 쉬고 있는 사람은 하나도 없었다. 몇 시간 후나타난 선배드의 주인을 보니 모두 한국사람들이었다. 아침 일찍 일어나서 일단 선배드를 찜 해놓고아침식사를 하러 간 것이었다. 사실 선배드는 모든 사람이 충분히 쉴 만큼 많았다. 하지만 이용도 하지않으면서 먼저 찜을 해놓으니 다른 사람들은 전혀 쉴 곳이 없게 된 것이었다. 한국에서는 이런 현상이후로 수영장의 선배드 이용이 유료로 바뀐 것으로 알고 있다. 외국에서는 이로 인해 어떻게 바뀔지,바뀌었는지 알 수 없다. 어쨌든 낯부끄러운 일이었지만 다음날 아침에는 아침식사를 하기 전에 선배드 몇 개를 찜 해 놓는 일에 동참하는 우리를 발견하게 되었다.

이렇듯 죄수딜레마는 어디에서나 나타난다. 약속을 지키면 다같이 이익이 되고 모두 약속을 지킨다는확신이 없다면 약속은 순식간에 무너진다.

그럼, 규칙을 엄하게 적용하면 해결될 수 있지 않을까? 공유를 하지 않으면 벌칙을 주고 필요한 문서를 모두 만들지 않으면 승인을 하지 않아서 프로젝트의 다음 단계로 넘어가지 못하게 하면 해결할 수있지 않을까? 이런 식으로 해결이 될 수 있었다면 우리나라의 대부분의 회사가 이미 공유문화가 잘 정착되었을 것이다. 안타깝게도 엄격한 규칙적용은 그렇게 효과적이지 못하다.

첫째 만들어 놓은 규칙이 엄격하기만 할 뿐 공유 문화 정착에 효과적인 경우가 별로 없다. 왜냐면 그엄격한 규칙을 만든 사람들이 대부분 공유문화를 체험해 본 적도 없는 사람들이기 때문이다. 대부분은 방법론에서 필요한 문서를 따와서 만들라고 하는데 대부분의 방법론은 공유문화와는 별로 상관이없다. 게다가 방법론을 오해해서 오히려 복잡하게 적용하는 경우도 허다하다.

둘째 아무리 복잡한 규칙을 만들어도 개발자들은 요령껏 적응하고 피해 다니게 된다. 문서를 만들라고 하면 형식 면에서는 규칙을 충족하게 만들 수 있지만 진짜 필요한 내용이 다 들어 있는지 확인할방법은 없다. 공유가 습관화되지 않은 대부분의 개발자들은 어쨌든 규칙만 준수하는 방법으로 진짜공유는 피해 다니게 되어 있다.

셋째 나만 공유를 제대로 하게 될 경우 나만 손해를 볼 수 있다는 생각을 의식적으로 또는 무의식적으로 하게 된다. 나중에 내가 없으면 유지보수가 어려워야 나의 가치가 올라간다고 생각한다. 전혀 틀린얘기도 아니지만 다들 이렇게 생각하니 다같이 손해를 보는 것이다.

규칙을 통해서 공유문화를 만들어가는 것에는 찬성한다. 하지만 오히려 공유문화에 역행하는 규칙을만드는 것이 일반적인 상황이라서 안타깝다. 개발자들이 공유에 익숙하지 않은 상황에서 너무 욕심을내는 것도 안 된다. 현재 상황을 잘 파악해서 공유문화를 만들어 갈 수 있는 단계적인 접근이 필요하다. 개발자들이 소화할 수 있는 만큼의 규칙을 만들고 이것이 익숙해지는 것이 공유문화 발전 방향과일치를 해야 한다. 이렇게 점점 규칙을 업그레이드 시켜나가면서 회사를 조금씩 바꿔나가야 한다. 물론 이런 과정을 통해서 다같이 이익이 될 것이라는 확신을 직원들에게 심어주어야 한다.

처음부터 과욕을 부리다가는 영원히 공유문화와는 멀어지게 된다. 그럼 비효율이 정착된 회사가 될것이다.

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