인원 늘면 꼬이는 SW개발문화의 현주소

꽤 오래 전 TV에서 혼자서 무인 자동차를 개발하고 있는 한 대학 교수의 이야기를 본 적이 있다. 20년째 혼자서 연구를 하고 있었고 조금씩 개량해서 그 당시 한적한 국도를 혼자서 달릴 수 있는 수준이었지만 복잡한 도로에서는 제대로 달릴 수 없었다. 

어린 마음에 참 대단하다는 생각을 했고 운전자 없이 도로를 달리는 차들을 상상해 보기도 했다. 그러나 그 뒤에 어떻게 되었는지는 알 수가 없다. 

하지만 현재 구글은 이미 실용적인 수준의 무인 자동차를 개발했다. 시중에 운전자가 없는 자동차가 굴러다니는 것을 볼수 있기 일보직전이다.  둘의 차이는 무엇일까? 

20년전 필자가 다니던 H사는 전국적으로 뛰어나다는 소프트웨어 개발자들이 모여들었다. 필자가 참여했던 프로젝트 중 하나는 팀원이 4명이었다. 그런데 같은 종류의 제품을 만드는 미국의 경쟁회사인 C사는 프로젝트 팀원이 400명이었다. 4대400으로 경쟁하는 것이었다. 그때는 내심 부러워했지만 그때 만약 400명의 개발자가 있었다면 미국 회사 정도 제품을 만들어 낼 수 있었을까? 나는 프로젝트 팀원이었는데 스펙을 본 적도 없다. 스펙이 없기 때문이었다. 나는 팀장이 구두로 설명하면 일을 하곤 했는데 400명의 개발자가 추가 됐어도 크게 다르지 않았을 것이다.

그 당시 H사를 다니던 뛰어난 개발자들은 전국 각지의 회사들로 흩어져서 일당백의 개발자로 일하고 있고, 들으면 알만한 수많은 소프트웨어를 개발했다. 하지만 안타깝게도 글로벌 시장에서 성공한 소프트웨어를 개발한 사례는 내 기억에는 없다. 돈을 많이 번 사례로는 게임회사를 운영한 경우가 있지만 게임의 핵심 경쟁력이 소프트웨어는 아니기 때문에 예외로 해야 할 것이다. 작은 회사를 유지하면서 건실하게 유지하고 있는 회사도 있지만 큰 회사로 성장한 경우 소프트웨어 역량은 형편없어지는 사례를 자주 보았다. 

한국에서 개인 또는 소수 개발팀이 소프트웨어를 알차게 만들어서 꽤 인기를 끄는 경우를 종종 보게 된다. 규모가 꽤 큰 외국 개발팀에서 생산하는 소프트웨어보다 괜찮은 경우도 있다. 이런 굉장한 효율을 보여주는개발팀은 대부분 10명이하의 소규모팀이다. 

하지만 개발팀이 수십, 수백명이 넘어가면 효율은 점점 떨어진다. 개발자가 1000명이 넘는 회사를 가보면 거대한 개발조직이 가지고 있는 장점을 별로 찾아볼 수가 없다. 개발자는 1000명이지만 개발자 10명짜리 회사가 100개 모여있는 것처럼 느껴진다. 팀간에 지식은 공유가 잘 안되고 협조하기도 쉽지 않다. 하나의 거대한 지식 공동체라기보다는 조직적으로 잘나눠지고 관리되는 팀일 뿐이다. 

이런 현상은 현재 일하고 있는 개발자들 탓은 아니다. 한국 개발자들도 지식 공동체가 잘 구축되어있는 회사에서 처음부터 개발을 시작했다면 어떻게 서로 지식을 공유하고 협업하는지 자연스럽게 몸에 익혔을 것이다. 그런 문화속에서 대규모 프로젝트를 이끌 수 있는 아키텍트가 탄생하기 마련이다. 하지만 그런 문화가없는 조직에서는 기업의 문화를 그대로 배울 수 밖에 없다. 

비싼 툴을 쓴다고 프로세스를 강화한다고 해서 지식공동체가 만들어지는 것은 아니고 오히려 점점 멀어지게 된다. 

지식을 공유한다고 이슈관리시스템을 쓰고 위키, KMS를 도입하지만 골프채를 바꾼다고 골프를 잘치게 되는 것은 아니다. 툴은 필요하지만 먼저 문화를 익혀야 한다. 문화는 사회에 나와서 갑자기 익히기도 어렵다. 학교에서부터 공유, 토론, 협업문화를 익힐 수 있는 수업을 위주로 문화를 구축해 나가야 한다. 

한국에서 미국에 이민을간 중학생이 미술 수업시간에 그림을 그리는데 반에서 가장 잘그렸다. 하지만 B 학점을 받았다. A 학점을 받은 학생은 자신보다 그림을 못그렸지만 그림에 대해서 설명을 훨씬 잘했다고 한다. 

미국에서는 대학수업 대부분의 과목에 토론수업이 병행되고 있다. 강의를 받고 끝나는것이 아니라 그만큼의 토론수업이 또 진행된다. 토론이 항상 몸에 베이게 되는 것이다. “토론, 까짓별거야? 우리도하면되지”라고 생각하면 오산이다. 

십여년을 토론수업을 하면서 배워온 사람들과는 문화적인 차이는 명백히 드러난다. 토론을 몸으로 익혀온사람들은 소프트웨어를 개발할 때도 적절한 커뮤니케이션과 공유, 협업이 자연스럽게 이루어진다. 

대규모 프로젝트의 성공은 뛰어난 아키텍트에 달려있다. 한국에 뛰어난 프로그래머는 많지만 뛰어난 아키텍트는 절대적으로 부족한 이유가 이런 환경에 기인한 것이라고 생각한다. 개발자 10만 양병설, 초등학생 SW 교육을 외치기 전에 문화를 바꾸는데 더 노력을 해야 한다. 

우리나라 소프트웨어 회사에는 ???이 없다.

우리나라 소프트웨어 회사에는 없는 것이 참 많다.

물론 있는 것도 많다. 머리 좋고 충성심 높은 개발자도 있고, 기반시스템도 갖추고 있는 경우도 종종 있다. 또한 뛰어난 요소기술을 갖추고 있는 경우도 많다.

프로세스와 시스템은 갖추려고 상당히 노력을 하고 있어서 효과를 보는 경우도 간혹 있지만 이 또한 거의 대부분 수박 겉핧기 식에 머무른다. 아주 초보적인 기능만 쓰거나 잘못 사용하는 경우가 많다. 

하지만 대부분의 회사가 거의 갖추고 있지 못한 것들이 있다. 이런 것들을 넘지 못하면 글로벌 소프트웨어 회사로 가는 길은 멀게만 느껴진다.

1. 개발문화가 없다.

소프트웨어 개발을 정해진 프로세스대로 딱딱 진행해서 잘되면 참 좋겠다. 하지만 절대로 그렇게 되지 않는다. 물론 프로세스를 따르지만 프로세스에 모든 것을 다 담을 수는 없다. 모든 절차를 프로세스화 하면 오히려 효율이 떨어진다. 아니 개발을 거의 못할 것이다. 

프로세스는 최소화하고 나머지는 개발 문화로 커버를 하는 것이다. 

개발문화 중에서 가장 중요한 것은 공유와 협업의 문화이다. 물론 많은 개발자들이 공유와 협업을 하고 있다고 생각할지도 모르겠다. 하지만 그 수준에서는 정말 많은 차이가 난다. 

또한 회사내에서 정말 자리잡기 어려운 문화이다. 개발자들 하나하나가 습관을 바꿔야 하는 어려운 난관이 가로막고 있다. 처음에는 강제화를 해야 하는데 무엇을 강제화 해야 하는 지가 문제이다.

공유와 협업 관련된 키워드를 몇가지를 들면 다음과 같은 것들이 있다.

SRS review, SRS sign, Architecture review, Code review, Coding convension, Doxygen, Component, Interface, Wiki, Bug track, Engineering Onepager, Broken tree, Common library

공유와 협업의 문화가 자리를 잡으면 위에 언급한 모든 것들이 확연하게 바뀌게 된다. 하나하나가 엄청난 항목이므로 자세한 설명은 생략한다.

2. 개발자들의 롤모델이 없다.

 

소프트웨어 개발자들은 3,4년만 지나도 위가 잘 안 보인다. 개발자로서 계속 일을 할 수 있을지 확신이 안 선다. 개발을 계속 하고 싶기는 한데 20년이 지나도 개발을 계속 하고 있는 고참을 본 적이 없어서 그 모습이 잘 그려지지 않는다. 사실 아주 드물게 관리직을 포기하고 개발직에 머물고 있는 고참들이 있지만 그 모습이 그렇게 우러러 보이지 않는다.

그래서 개발자 10년에 관리는 전혀 안하고 개발에만 매진하는 개발자를 찾기는 매우 어렵다. 그렇게 관리와 개발 양다리에서 헤매다가 대부분은 관리로 넘어가던가 업계를 떠나게 된다.

하지만 소프트웨어 개발자라는 자리는 코딩만 놓고 보면 5년짜리 개발자나 20년짜리 개발자나 타이핑 속도가 별반 차이가 나지 않는다. 하지만 아키텍처나 회사의 전략을 바라보는 시각은 엄청난 차이가 난다. 하지만 우리나라에서는 그런 개발자를 키워내지 못하기 때문에 롤모델도 없고 개발자는 방황하고 하는 악순환이 계속되고 있다.

3. CTO가 없다. 

소프트웨어 회사의 꽃은 CTO다. 하지만 거의 모은 우리나라 소프트웨어 회사에는 CTO가 없다. 가끔 직함이 CTO인 경우는 있지만 거의 대부분 진짜 CTO는 아니다. 다른 일을 하는데 직함만 CTO인 경우이다.

CTO가 없다면 회사의 중요한 기술적인 결정을 할 수 있는 최고 책임자가 없다는 뜻이다. 따라서 중요한 기술적인 결정이 영업적인 입장에서 결정되는 경우가 많아진다. 고참 개발자들이 가끔 저항을 해보기도 하지만 우리나라에서는 직급에서 눌리는 것을 극복하기는 쉽지 않다.

또한 CTO급이 아니라면 고참 개발자들의 시각도 최고 수준에는 못 미치기 때문에 제대로 결정을 못하고 설득력도 떨어지게 된다. 

소프트웨어 업계에서 20년 이상은 개발자로 꾸준히 제대로 성장해야 CTO급이라고 할 수 있는데 우리나라에는 그런 개발자가 거의 없는 것도 한 이유이다.

당분간은 좋은 CTO를 구하고 싶어도 쉽게 구하지 못할 것이다.

4. 마케팅이 없다.

 

대부분은 치밀한 계획보다는 번뜩이는 아이디어로 시작을 해서 초기에 성공을 거두었기 때문에 마케팅에 대해서는 거의 모르고 오로지 개발자들의 마법에 의존해서 소프트웨어를 개발하곤 한다. 

어느 정도 커지기 시작하면 마케팅에도 관심을 가져야 하는데 대부분의 소프트웨어 회사에는 개발과 영업만 존재하게 된다.

마케팅도 경험을 가진 마케팅 전문가가 부족하기 때문에 왠만한 대기업을 제외하고는 마케터를 구경하기 어렵다. 마케팅에 관심이 있는 회사 주먹구구 방법밖에 모르기 때문에 별효과를 못 보거나 개발자가 알아서 개발해 줄 때보다 못한 경우도 많다.

하나하나가 워낙 갈길이 멀고 무거운 주제들이라서 마음이 무겁지만 천천히 고쳐나가야 할 것들이다.

나쁜 습관

소프트웨어 회사가 프로세스를 제대로 정립하고 좋은 툴을 도입하고 개발문서도 잘 써보려고 노력하고 코딩 실력이 뛰어난 개발자들을 보유하고 있어도 넘기 힘든 벽이 있다.

우리나라 개발자들이 코딩 실력이 좋다는 것은 부정하고 싶지 않다. 처음에는 주먹구구식으로 시작을 했다가 회사가 커지고 고객이 많아지면서 문제가 있음을 깨닫고 프로세스도 만들고 기반시스템도 도입하지만 좋아지기는 하지만 기대만큼 큰 효과를 못보는 경우가 많다. 

그 이유는 개발자들의 몸에 베인 나쁜 습관들은 쉽게 고쳐지지 않기 때문이다. 나쁜 습관이 몸에 베인 개발자들도 교과서적으로는 그렇게 하면 안된다는 것을 알고 있어도 한번 몸에 베인 습관은 쉽게 고쳐지지 않는다.

나쁜 습관에 몸에 베인 것도 개발자들 탓은 아니다. 개발자들도 좋은 개발문화를 가진 회사에서 처음부터 일했다면 그런 나쁜 습관들은 경험해보지도 못했을 것이다. 

여기서 가장 중요한 개발문화는 바로 "협업"의 문화이다. "협업"을 생각하지 못하고 행동하는 하나하나가 모두 나쁜 습관들이다. 우리나라 개발자들은 협업을 해볼 기회가 별로 없다. 개발자들 스스로는 몇명씩 팀을 이뤄서 개발들을 해봤으니 "협업"을 해봤고 지금도 "협업"을 하고 있다고 말할 것이다. 하지만 그건 대부분 또하나의 주먹구구식의 일종일 뿐이다. 따라서 그런 팀은 4~5명이 한계이고 그보다 더 커지면 커지나 마나 하고 오히려 효율성이 더 떨어지는 경우도 많다.

그럼 협업의 핵심은 무엇일까요?

첫째, 문서를 통한 협업이다.

우리는 대부분 여럿이 모여서 서로 의논하면서 개발을 하면 협업을 하는 줄 안다. 하지만 그렇게 해서는 커뮤니케이션 비용이 너무 많이 들어간다. 90%는 문서로 말하고 문서로 안되는 나머지 10% 정도만 말로 설명하면 된다. 하지만 대부분 그 반대다. 문서로 10%, 말로 90%를 커버한다. 
여기서 말하는 문서는 "SRS"(스펙문서), "설계문서", "코드"를 모두 포함한다. 또한 이슈관리시스템과 같은 시스템도 포함된다. 
스펙문서를 보고 문서 작성자 외에 다른 개발자들이 설계를 하고 구현을 할 수 없다면 아직 갈 길이 먼 것이다. 
설계문서를 보고 여러 개발자들이 일을 나줘서 흩어져서 일을 할 수 없다면 부족한 설계문서다.
코드에는 Doxygen등의 주석이 달려 있어서 해당 함수나 Class를 사용하는 동료들이 주석만 보고 사용할 수 있어야 한다. 또한 Doxygen등을 통해서 체계적으로 함수나 Class를 검색할 수 있어야 한다.
코드에 의미를 알 수 없는 숫자나 널려 있고 Public 함수들이 수시로 바뀐다면 협업을 제대로 하고 있다고 볼 수 없다. 
잘 설계가 되어서 Public interface들이 한번 정해지면 이에 대한 설명이 잘 달리고 끝까지 바뀌면 안된다.
이러한 것들이 남의 나라 얘기처럼 생각되면 아직 협업은 갈길이 멀다. 

둘째, Peer review이다.

 Peer review를 빼고는 소프트웨어 개발을 얘기할 수 없다. Peer review하면 흔히 코드리뷰를 떠올리는데 코드리뷰는 그 중 일부이다.
Peer review에서 가장 중요한 것은 SRS(스펙) 리뷰이다. 스펙이 있어야 설계가 있고 그래야 코드리뷰도 의미가 있다.
SRS(스펙)는 프로젝트 모든 관련자가 참여하고 리뷰를 하여 완성해 나간다. SRS에는 프로젝트에 관련된 모든 내용이 들어가기 때문에 혼자서는 완성할 수 없고 리뷰를 거쳐서 모든 관련자가 검토를 해야 한다. 그리고 나면 이렇게 잘 완성된 SRS를 가지고 각자 흩어져셔 일을 할 수 있게 된다.
설계는 혼자서 하는 것보다는 여러 개발자와 리뷰를 하면서 좀더 좋은 아키텍쳐를 찾아낼 수가 있다. 개발자 개인이 가지고 있는 지식은 한계가 있어서 여러 사람과 머리를 맞대야 한다. 
설계 시 다른 사람들의 다양한 의견을 받아들일 준비가 되어 있지 않다면 아직 리뷰 문화에 익숙하지 않은 것이다. SRS와 설계는 리뷰를 통해서만 완성도 있게 작성된다.
그리고 코드리뷰이다. 
이렇게 리뷰를 잘 해야만 제품의 버그나 재작업을 획기적으로 줄일 수 있다. 또한 리뷰를 통해서 서로의 지식과 경험이 공유가 되고 각 개발자들이 훨씬 빠르게 성장한다.

협업 문화가 잘 되어 있는 회사는 다른 분야의 개발자들이 입사를 해도 빠른 시간 안에 적응해서 같이 일할 수 있다.
또한 개발자 한두명이 퇴사를 해도 회사가 망할 정도로 휘청이지는 않는다. 
결정적으로 프로젝트를 더 빨리 끝낼 수 있다.

사실 문화라는 것을 말로 설명하는 것은 어렵다. 또한 말로는 다 알 것 같지만 몸에 베이지 않으면 아는 것도 아니요. 모르는 것도 아닌 어중간한 상태가 된다. 그럴 때는 회사에서 중요한 것들을 강제로 시행하는 제도도 필요하다. 물론 핵심을 모르고 무조건 강제로 하면 부작용이 더 클 수 있으므로 현재 가능하고 중요한 것부터 차근차근 해나가야 한다.

확실한 것은 이런 협업의 문화가 없이는 소프트웨어 회사가 즐겁게 일하면서 오래 살아남지 못한다는 것이다.