소프트웨어 회사에 산업 스파이가 존재하는가?

최근에 블로그에 올린 글들의 댓글을 보면 소프트웨어를 잘 개발하는 것이 어떤 것인지 바라보는 시각이 무척 다릅니다. 필자는 주장하는 바가 있어서 소프트웨어 개발에 대한 생각을 꾸준히 공유하고자 합니다. 제 블로그의 미션은 어떻게 하면 소프트웨어를 효과적으로 잘~~ 개발하느냐를 공유하는 겁니다. 대상은 학생 개인부터 대기업에 이르기까지 모두 포함합니다. 하지만 이를 효과적으로 전달하는 것은 쉽지 않습니다. 또한 블로그 글 몇 건으로 생각을 바꾸게하는 것은 더욱더 어렵습니다. 그래서 다양한 측면에서 조명을 해봅니다. 

오늘은 소프트웨어가 하드웨어와 얼마나 다른지 하나의 예를 보여주겠습니다.

예나 지금이나 산업 스파이에 관련된 뉴스들은 종종 나옵니다.

수백억, 수천억을 투자한 기술을 1,2명이서 빼돌려서 해외에 팔아 넘기곤 합니다. 이런 일이 발생하면 회사에 치명적인 손실을 가져오게 합니다. 

자동차ㆍ전자ㆍ조선…끊임없는 기술유출 사건[조선일보]

위 기사만 봐도 얼마나 많은 기술 유출이 발생하고 있는지 알 수 있습니다. 

하지만 소프트웨어 분야에서 이런 일이 일어난 것을 본 적이 있나요? 소프트웨어 분야에서는 Open Source 정책을 통해서 심지어는 소스코드를 모두 공개하기도 합니다. 구글을 비롯해서 실리콘밸리의 대부분의 소프트웨어 회사들은 개발자가 입사를 하면 바로 회사의 거의 모든 소스코드를 바로 볼 수 있습니다. "개발자가 이 소스코드를 유출하면 어떻게 하나"하는 걱정은 하지 않습니다.

여기서 알 수 있는 것은 소프트웨어 회사의 핵심 기술이 무엇인가 하는 것입니다. 소프트웨어 회사의 핵심 기술을 설계 도면도 아니고 소스코드도 아니고 "사람과 개발 문화"입니다. 아무리 똑같은 소스코드를 가지고 있어도 그대로 따라 할 수가 없습니다. 당연히 그대로 팔아 먹을 수는 없겠죠? 또 유지보수는 어떻게 할까요? 소스코드를 열심히 연구해서 더 좋은 것을 만들려고 해도 만들 수가 없습니다. 

이런 소프트웨어 회사를 다니다가 본인에게 기회가 생기면 회사를 나와서 창업을 하기도 합니다. 이 때 소스코드 다 들고나가도 별로 신경을 쓰지 않습니다. 소스코드를 그대로 사용할 수도 없습니다. 개발자가 들고 나가는 것 중에서 가장 가치 있는 것은 "개발문화와 좋은 동료들"입니다. 이렇게 새로운 Start up이 탄생을 하고 성장하기도 하고 망하기도 하고 이런 시도가 계속 되면서 좋은 소프트웨어 토양을 이룹니다. 이 과정에서 기술과 문화가 계속 섞이면서 발전해나갑니다.

우리나라에서는 많은 소프트웨어 회사들은 소스코드를 신주단지 모시듯하고 심지어는 개발자들에게 공개하지 않고 소수의 개발자들만 볼 수 있게 하기도 합니다. (물론 우리나라에서는 꼭 이래야 하는 극소수의 예외는 있습니다.) 그 이유는 "사람과 개발 문화"가 변변치 않기 때문입니다. 개발자 한두명이 퇴사를 하여 경쟁업체를 만들거나 경쟁업체에 입사를 하면 치명적인 타격을 입기도 합니다. 참으로 척박한 환경입니다. 

소프트웨어 회사에서는 훔칠게 별로 없어야 합니다. 회사가 개발자들을 제대로 Retain하지 못해서 몽땅 나가버리는 경우라면 어쩔 수 없겠지만, 자연적인 개발자 순환을 거치면서도 소프트웨어 회사는 지속적인 기술 발전을 시킬 수 있어야 합니다. 소스코드를 모두 공개해도 좋은 개발팀을 유지하고 있으면 어느 누구도 우리보다 잘 할 수 없어야 합니다. 한두명 개발자가 퇴사를 해도 치명적인 타격을 입지 않아야 합니다. (아주 작은 회사는 예외) 소프트웨어 회사의 재산은 "좋은 개발자들과 개발 문화"여야 합니다. 

적당히 뽑은 공대생들 잔뜩 모아 놓고 프로그래밍 가르쳐서 회사에서 정해 놓은 프로세스대로 개발하고 지정한 문서 만들게 해서 좋은 개발팀이라고 착각하면 안됩니다. 세계 유수의 개발방법론 도입하고 CMMI Level5라고 해서 좋은 소프트웨어 개발 문화와 프로세스를 가지고 있다고 착각하면 안됩니다. 지금까지 나열한 것들은 오히려 방해요소가 될 수도 있습니다. 

물론 하드웨어도 소프트웨어와 공통점이 있겠죠. 좋은 인재가 필요하고 문화도 필요하겠죠. 하지만 저는 하드웨어 전문가는 아니니 이것은 언급하지 않겠습니다. 소프트웨어가 얼마나 다른지를 강조하고자 합니다. 이글을 자신의 회사에 적용해보고 우리 회사의 "개발문화"를 한번씩 가늠해보도록 합시다.

SW 산업의 부실한 계약문화(개발문화 시리즈9)

이번 개발문화 이야기는 '계약 문화'다. 

나는 개발자지만 여러 차례 계약의 경험이 있다. 특히 한국, 일본, 미국의 계약 문화를 두루 경험해봤다. 회사 설립 관련된 계약도 해보고 프로젝트 계약도 많이 해봤다. 그러면서 나라별로 계약 문화에 많은 차이가 있음을 알게 되었다. 어찌 보면 계약만의 문제는 아닌 것 같다. 일상의 약속, 구두 계약에서도 비슷한 현상이 벌어진다. 

한국에서는 선비정신과 의리문화 영향인지 몰라도 돈에 관해서 직접적으로 말하기를 꺼려하는 경향이 있다. “좋은 게 좋은 것”이라는 말이 있듯 서로 좋은 얘기만 하려고 한다. 계약 조건에 대해서 꼼꼼하게 점검하고 따지면 너무 깐깐하다는 얘기를 듣기도 한다. 

하지만 미국의 개발문화는 좀 달랐다. 나도 처음에는 이질감을 많이 느꼈다. 개인적으로 친한 관계라 하더라도 계약을 할 때는 냉정할 정도로 철저했다. 어색할 정도로 금액에 대한 얘기도 까다롭고 꼼꼼했다. 잘못될 경우에 대한 얘기도 철저히 언급을 해서 친분에 금이 갈 것 같은 생각이 들었다. 

내가 경험한 미국인과의 계약이 그랬던 것이지 전체를 대표하는 것은 아니다. 어쨌든 결과적으로 그런 철저한 계약은 일이 잘되든 잘못되든 문제의 소지가 별로 없었고 인간관계도 해치지 않았다. 한국에서 약속이나 계약이 틀어지면 인간관계까지 깨지는 경험을 해봤는데 그와는 사뭇 달랐다. 

그 뒤로도 한국에서 계약을 여러 번 했지만 한국 문화를 거스르기는 어려웠다. 하지만 나름대로 정확하게 하고 문제의 소지를 없애기 위해서 노력을 하고 있다. 

한국의 계약 문화가 계약 자체만의 문제라기 보다는 사회 전체적인 여러 관습들의 복합체라서 혼자서 바꾸기는 어렵다. 칼럼에서 이를 한방에 해결할 수 있는 기가 막힌 방법을 제시해 줄 것으로 생각하면 기대가 너무 큰 것 같다. 그래도 문제의 인식이 문제 해결의 출발이다. 무엇이 문제인지 같이 생각해보자. 

첫째, 계약 전에 일 시작하기 
계약을 하기도 전에 일을 시작하는 것은 비일비재하다. 이유는 여러가지가 있다. 계약 절차가 복잡해서 늦어진다고 핑계를 대기도 하고 담당자가 미리 꼼꼼하게 챙기지 않아서 늦어지기도 한다. 그래도 빨리빨리 문화는 여전해서 일단 일을 먼저 시작하자고 한다. 

가끔은 일부러 계약을 늦추기도 한다. 어차피 계약은 될 것이라고 하지만 계약이 늦어지면 불리한 쪽은 외주사이고 나중에는 계약 조건을 꼼꼼히 따지기도 어려워진다. 계약금도 제때 받지 못하기도 하고 프로젝트가 아예 취소되기도 한다. 지급을 늦출수록 이자만큼 이익이기 때문에 일부러 늦추는 회사도 있지만 신뢰관계의 손실과 이자만큼의 이익중 어느 것이 진짜 회사에 이익인지는 생각해볼 필요가 있다. 

이런 현상은 프로젝트 뿐만 아니라 스타트업들에서도 벌어진다. 의리로 애매하게 시작해서 회사가 잘되면 서로 생각이 달라져서 문제가 되기도 한다. 이때 보통 손해를 보는 쪽은 개발자들이다. 화장실 들어갈 때와 나올 때 달라지는 것이기 때문에 화장실 들어가기 전에 확실히 정해야 한다. 

둘째, 범위를 정하기 않고 계약하기 

얼마 전 미국의 한 개발자가 자신의 일을 외국 개발자에게 적은 금액에 외주를 주고 자신은 취미생활을 한 사례가 화제가 되었다. 이런 일이 우리나라에서 가능할까? 쉽지 않을 것이다. 이런 일이 가능 하려면 내부 개발이라도 스펙이 명확하고 투명하게 개발이 되어야 한다. 

이런 에피소드를 그냥 우습게만 생각할 것은 아니다. 한명의 개발자도 외주를 제대로 줄 수 있는데, 우리나라에서는 수백억짜리 프로젝트가 스펙도 제대로 정하지 않고 진행되는 경우가 있다. 일정과 금액이 이미 정해진 상태에서 소프트웨어 개발 프로젝트를 진행하면서 스펙을 정하게 되면 초기 예상보다 범위와 비용이 훨씬 늘기도 한다. 1천억원짜리 프로젝트에 3천억원이 투입되었다는 한 SI회사의 하소연을 들은 적도 있다. 
과거에 같이 일했었던 실리콘밸리의 개발자에게 들은 얘기다. 과거에 국내 대기업의 외주 프로젝트를 진행한적이 있는데 스펙도 없이 대충 프로젝트를 시작해서 자신이 스펙을 자세히 적어서 보여줬다고 한다. 그런데 담당자는 스펙을 보지도 않고 진행과정에서 공유를 해도 관심을 갖고 확인도 하지 않았다고 한다. 

그러다가 소프트웨어 완성 후에 원하는 것이 아니라고 기능변경을 계속 요청했다고 한다. 어이가 없어서 그뒤로 한국과는 프로젝트를 안한다고 한다. 한국에서는 비일비재한 일이지만 미국인에게는 납득이 안되는 상황이다.

이것은 이미 사회적으로도 큰 문제라서 스펙을 정하는 프로젝트와 구현하는 프로젝트를 나눠서 발주하는 '분할발주'를 추진하고 있다. 분명히 필요한 제도지만 이것이 법률화 된다고 하더라도 공공분야에 국한된 것이고 스펙을 제대로 정하는 것도 쉽지 않아서 잘 정착될지는 미지수다. 

고객이 전문성이 떨어지고 의무를 다하지 않고 우월적인 지위를 남용하는 문화가 팽배해서는 법률로 문제를 해결하기는 쉽지 않다. 

셋째, 모호하게 계약하기 
수많은 중소기업과 외주 개발사를 괴롭히는 문제다. 계약서에 제대로 된 스펙을 포함하지 않고 계약을 하는 경우가 매우 흔하다. 이런 현상은 내부개발을 할 때도 발생한다. 하지만 내부개발 시에는 서로 얘기를 하면서 조정해 나가고 점진적으로 개발을 잘 해내기도 한다.

하지만 외주 프로젝트는 같은 방식으로 진행하면 내부 개발보다 문제가 몇 배 더 커진다. 모호한 스펙은 서로 다르게 생각하게 하고 개발한 결과가 예상과 다르면 소송으로 이어지기도 한다. 

스펙을 대충 정하고 개발을 시작한 후 발주사가 원하는대로 언제든지 기능 변경을 요구하면서 개발하는 방식도 이와 비슷하다. 발주사는 아무 때나 기능 변경을 강요하고 외주사는 어쩔 수 없이 들어줘야 하는 경우가 많다. 

원래는 계약을 한 줄만 바꿔도 재계약을 해야 하지만 우리나라에서는 상상하기 쉽지 않은 일이다. 프로젝트 완료 후 검수조건이 모호한 것도 마찬가지다. 명확한 조건에 의해서 검수를 하는 것이 아니라 담당자 개인 취향에 맞지 않으면 검수에 실패하기도 한다. 

모호한 스펙은 여러가지 패턴이 있지만 보통 유저인터페이스나 기능 보다 기능이 아닌 요구사항에서 더 큰 문제가 발생한다.

비기능은 일반적으로 자세히 언급하지 않기 때문에 누락되기 쉽고 문제가 되면 시스템을 다 버리고 다시 만들어야 할 정도로 큰 이슈들이 발생하기도 한다. 비기능 요구사항에는 성능, 보안성, 안정성, 가용성, 이식성, 유지보수성, 확장성, 표준, 제약사항 등 셀 수 없을 정도로 많고 프로젝트마다 중요한 부분이 다르다. 

표현방법이 문제가 되기도 한다. ~을 지원한다, 효율적이어야 한다, 편리해야 한다 등과 같이 측정이 불가능한 문구들은 언제든 문제가 된다. 보는 사람에 따라 다르게 해석되는 문구들은 없어야 한다. 스펙을 명확하게 적는 주제는 너무 방대해서 여기서 다 설명하기는 어렵다. 

넷째, 계약은 서류일뿐 

이런 환경이라면 수많은 프로젝트가 소송에 휩쓸리고 일을 할 수 없어야 한다. 물론 분쟁에 휩싸여서 문닫은 회사도 많지만 모든 문제가 소송으로 이어지지는 않는다. 프로젝트 결과에 대해서 발주사와 외주사가 서로 다르게 생각하거나 계약 내용을 제대로 이행하지 않은 경우에도 소송대신 다른 방법으로 해결하기도 한다. 

접대로 풀기도 하고 인간관계를 이용해서 해결하기도 한다. 프로젝트의 실패가 발주사 담당자의 피해로 이어질 수 있기 때문에 유야무야 성공한 프로젝트로 탈바꿈하기도 한다. 이러다보니 계약에 문제가 있어도 나중에 풀면 된다는 생각으로 계약을 대충 진행하기도 한다. 

이러한 문화적인 문제들이 계속 이어지는 것은 소프트웨어 개발 문화뿐만 아니라 역량 향상에도 문제가 된다. 수많은 중소기업과 외주사를 괴롭히는 요인이다. 이런 문화를 빠르게 개선하는 뾰족한 방법은 없는 것 같다. 

법적인 뒷받침도 필요하고 다 같이 문화를 바꾸려는 노력이 필요하다. 다같이 공멸하느냐 토양을 개선해서 같이 상생하느냐의 중요한 문제다. 자칫 하소연으로만 들릴 수도 있지만 이런 불합리를 바꾸려고 노력하는 사람도 많다. 그런 노력에 조금이라고 힘이 보태지기를 바란다.

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

서열문화가 SW산업 망친다. (개발문화 시리즈5)

이번 개발문화 이야기는 '서열이 지배하는 조직문화'다. 

우리나라는 옛날부터 서열을 매우 중요시 한다. 사람들이 모이면 서로 나이를 비교하고 서열을 정한다. 회사에서도 대리, 과장, 부장이 되려고 열심히 일한다. 직급에 따라 업무가 달라지고 급여도 서열에 비례한다. 물론 많은 변화가 있어 왔지만 뿌리깊게 자리 잡은 서열문화의 뿌리는 여전히 튼튼하다.

소프트웨어 산업에서도 서열 문화는 조직 문화에 많은 영향을 주었고 그로 인해서 많은 문제와 생산성 저하를 불러일으켰다. 소프트웨어 개발자도 직급에 따라 서열화 되며 주로 윗사람이 일을 시키고 아랫사람은 시키는 대로 일하는 형태가 많다.

이러한 수직적인 조직문화는 수평적인 조직 문화에 비하여 소프트웨어 개발에는 적합하지 않다. 자율성과 창의성이 강조되는 소프트웨어 개발 현장에서 수직적인 조직문화는 자칫 창의력을 저해하고 수동적인 마인드를 형성할 수 있다. 

내 경험에 의하면 소프트웨어 개발에 적합한 효율적인 조직은 수평적인 조직이다. 각자 역할을 나눠서 일을 하지만 상하관계는 아니다. 업무도 그렇게 수평적으로 전문화된다. 역할은 프로젝트 규모에 따라 세분화되기도 하고 크게 몇 개로 나뉘기도 한다. 

큰 프로젝트에서는 아주 많은 역할로 나뉜다. 소프트웨어 아키텍트, 프로그래머, 프로젝트 매니저, 프로덕트 매니저, 리스크 매니저, 빌드 엔지니어, 테크니컬 라이터 등 여러 역할이 있지만 이들은 상하 관계가 아니다. 전문화된 일을 하는 것이다.

그런데 수직적인 조직문화를 가진 소프트웨어 회사에서는 이들 역할과 비슷한 이름을 사용한다고 하더라도 수직적인 관계는 그대로 유지가 된다. 윗사람이 시키고 아랫사람은 지시에 따르는 스타일로 일을 한다. 그리고 전문적인 역할 구분 없이 윗사람이 모든 것을 결정할 권한을 갖는 경우가 많다.

개발자는 신참이나 고참이나 모두 소프트웨어 엔지니어다. 고참이 되면 그냥 시니어 엔지니어가 되는 것이다. 과장, 부장이나 연차에 따라 책임, 수석이 되는 것은 서열 중심의 조직에서 나타나는 현상이다. 물론 회사 대표 개발자에게는 수석 사이언티스트(Chief Scientist), 펠로우 엔지니어(Fellow Engineer) 등 특별한 타이틀이 있을 수 있지만 모두 소프트웨어 엔지니어다.

그 외에도 태크니컬 스티어링 커미티(Technical Steering Committee)나 아키텍트 그룹(Architect Group) 등의 조직이 있을 수 있지만 능력과 경험에 따른 역할의 구분이지 이들을 윗사람으로 생각하지는 않는다. 

부서간 커뮤니케이션에서도 서열은 많은 영향을 미친다. 합리적인 결정보다 서열에 의한 결정이 종종 발생한다. 대리급 개발자가 영업부서의 부장에게 직급으로 눌려서 합리적인 결정을 못하기도 한다. 이렇게 서열문화는 생산성을 떨어뜨리고 개발자의 전문성 향상을 저해한다. 

최근에 몇몇 젊은 회사에서 서열 파괴 시도를 하고 있다. 직원들간 직급을 모두 없애고 서로 이름을 부르며 나이와 상관없이 모두에게 존칭을 사용하는 것이다. 이러한 시도는 상당히 긍정적으로 평가한다. 물론 부작용이 없는 것은 아니다. 연공서열을 파괴 했을 뿐이지 나이 어린 사람이 또 윗사람이 되어서 서열화가 되는 경우도 발생한다.

결국 서열을 없애고 조직을 수평화시키는건 제도만으로 완성되는 것이 아니다. 조직이 전문화되고 전문가를 우대하는 문화도 정착이 되어야 한다. 각자 역할에서 전문가로 성장할 수 있고 관리자를 넘보지 않아도 대우를 받으며 일할 수 있어야 한다. 

소프트웨어 산업은 특수성이 강하다. 엄청나게 복잡한 지식산업이면서 예술성이 강하다. 서열에 의한 역할분담이나 지시에 의한 업무 진행은 소프트웨어 개발에 적합하지 않다. 서열보다는 각자의 특성, 실력에 따라서 수평적으로 일을 나눠서 하는 수평적인 조직문화가 필요하다. 

수평적인 조직이라도 다 같이 똑 같은 일을 하는 것은 아니다. 일반적으로 고참은 더 어려운 일을 하고 리뷰도 많이 한다. 대우도 서열보다는 실력에 의해서 차별화 되어야 한다. 그러려면 모든 개발이 투명화 되어 모든 개발자의 실력과 성과가 만천하에 드러나야 한다. 

결국 서열을 없애고 수평적인 조직을 만들기 위해서는 개발 방식 자체도 바뀌어야 한다. 조직뿐만 아니라 프로세스, 시스템도 모두 바뀌어야 한다. 제도만 바꿔서는 실패할 가능성이 크다. 모든 문화는 서로 얽혀 있어서 하나만 바꾼다고 될 일은 아니다. 연관된 모든 문화를 같이 바꿔야 하고 꾸준히 투자해야 한다. 

가장 중요한 것은 경영진의 마인드이다. 그래야 꾸준히 변화의 추진력을 얻을 수 있다. 변화는 1,2년에 마무리되는 것이 아니고 회사가 지속되는 한 끊임없이 투자를 해야 하는 것이다. 

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

SW회사에는 왜 수평적인 조직문화가 필요한가?

한국 소프트웨어 개발 환경이 이렇게 열악하고 기업의 소프트웨어 경쟁력이 미천한 이유의 핵심은 글로벌 소프트웨어 회사와는 엄청나게 다른 개발문화, 기업문화 때문이라고 생각한다. 그래서 필자는 지속적으로 글로벌 개발 문화를 소개해 왔고 이제는 실제 한국의 소프트웨어 회사에 적용된 사례도 공유하고 있다.

​

이번에는 소프트웨어 회사에 왜 수평적인 조직문화가 꼭 필요한지 설명하려고 한다.

​

한국 대기업을 다니는 외국인 직원이나 외국에 있는 한국 회사에 다니는 외국인들의 한국 회사에 대한 평가는 인터넷에 많이 올라온다. '글래스도어'도 그 중에 하나고 필자는 대기업에서 일하고 있는 외국인 개발자들을 인터뷰하기도 했었다.

​

좋은 얘기도 많지만, 문제를 찾아야 하는 입장에서 문제점으로 지적된 것을 봐야 한다. 그 중에 대표적인 것은 한국 기업은 '군대'와 비슷하다는 것이다. 군대식 상하 조직이 한국 사람들에게는 상당히 자연스러운데 이런 조직 문화는 소프트웨어를 개발하는데 있어서는 심각한 걸림돌이 된다. '까라면 까라'로 대표되는 군대식 상명하복 문화를 가지고는 글로벌 회사들과 경쟁하기 어렵다. 어렵사리 글로벌 시장에 진출하여 세계 상위권에 올라섰다고 하더라도 곪은 문제는 언젠간 터지게 마련이고 나락으로 떨어지는 것은 한 순간이다.

​

소프트웨어는 인류가 만들어 낸 가장 복잡한 지식 산업이다. 물론 상명하복식 조직 문화가 매우 효과적인 산업 분야도 있다. 하지만 창의적인 지식 산업인 소프트웨어 분야에서는 상명하복식으로 성장할 수 있는 데는 한계가 있다.

​

상급자가 모든 것을 알 수는 없다. 경영자도 소프트웨어 개발에 대한 모든 것을 알 수가 없다. 그런데도 경영이나 영업 관점으로 목표를 제시하고 '까라면 까라는 식'으로 일을 추진하면 시한폭탄을 계속 심는 것과 다를 바가 없다. 개발에 1년이 걸릴 프로젝트를 시장 상황 때문에 6개월안에 개발을 하려면 전문가들이 머리를 맞대고 합리적인 단축 방법을 찾을 수도 있다. 하지만 합리적인 해결책은 무시하고 명령식으로 압박을 하면 프로젝트는 어찌어찌 진행이 되지만 중요한 핵심 프로세스들이 생략될 수밖에 없다.

​

코딩은 빼먹을 수가 없으니, 스펙을 대충 정하거나 분석도 하지 않고 코딩을 시작해야 하며, 설계도 없거나 부실하고, QA도 대충할 수 밖에 없다. 어떻게든 결과가 나왔다고 하더라도 출시 후에 더 큰 비용을 치르거나 또 하나의 시한폭탄을 심어 놓은 상황이 된다.

​

이런 일이 벌어지는 이유는 상하관계가 확실하고 윗사람이 거의 생사여탈권에 가까운 평가권과 인사권을 가지고 있고 아랫사람은 윗사람과 특히 최고 경영자의 눈치를 심하게 봐야 하는 기업 문화 때문이다. 이런 조직에서 성장해온 관리자들은 어렵게 획득한 막강한 권한을 내려 놓기는 쉽지 않다. 자신 혼자 내려 놓을 수 있는 것도 아니다. 그래서 기존 조직, 특히 대기업이나 중견기업이 수평적인 조직으로 바뀌는 것은 거의 불가능하다.

​

수평적인 조직이란 모든 직원이 평등하다는 것을 말하는 것이 아니다. 각자 전문가로서 역할을 할 수 있어야 하며, 전문가로서 목소리를 낼 수 있어야 하며, 전문가로서 제시한 의견을 존중 받아야 한다는 의미다. 이때 직급, 나이, 경력은 의미가 없다. 상하 관계가 아닌 전문가로서의 의견이 잘 조율돼서 조직이 할 수 있는 최선의 결정을 내릴 수 있어야 경쟁력을 갖출 수 있다.

​

그럼 필자가 CEO로 있는 이우소프트의 수평적인 조직문화에 대해서 소개를 하겠다.

​

수평적인 조직문화는 다른 모든 조직 문화를 떠받치는 기초와 같다. 자율, 토론, 차근차근, 전문가 존중 등 이우소프트가 지향하는 기업 문화는 상명하복 문화가 철저한 조직에서는 잘 작동하지 않는다. 그래서 수평적인 조직 문화를 정착하기 위해서 많은 노력을 했다.

​

첫째, 모두 영어 이름을 부른다.

​

영어 이름을 부르는 것은 단순히 유행을 따르는 것은 아니다. 호칭은 사람의 생각을 지배하고 존칭과 하대가 섞인 대화에서는 상하 관계가 떠오를 수밖에 없다. 그래서 많은 회사들이 호칭 개혁을 하려고 '~님', '~프로' 등 다양한 시도를 하지만 제대로 정착된 곳이 많지는 않다. 하지만 영어 이름을 부르는 것은 이미 검증된 방법이다. 영어이름을 부르면 직급을 부르지 않아도 되고, 제3자가 보더라도 상하 관계를 읽을 수가 없다.

​

그래서 이우소프트에서는 서로 영어 이름을 부르고 있고 영어 이름을 부를 때 존칭을 사용하는 것은 금지되어 있다. 모든 사람이 서로 존대를 하되 '~께서'라고 부르는 것도 금지되어 있다. 내 영어 이름은 레이몬드(Raymond)인데, "레이몬드께서 그렇게 말씀 하셨습니다."는 금지된 표현이고 "레이몬드가 그렇게 말했습니다."가 허용된 표현이다.

​

직책을 부르는 것도 금지되어 있다. 팀장님, 대표님과 같은 호칭도 부르지 못하도록 되어 있다. 적응하는데 시간이 꽤 걸렸고, 한국 이름을 부르거나 직책을 부르면 1,000원씩 벌금을 내야 하고, 이제는 완전히 정착이 되었다. 그렇게 모인 벌금은 연말에 불우이웃 돕기를 하기로 되어 있다.

​

특히, 신입 사원들은 가장 빨리 적응을 했다. 각자 직급은 나눠져 있기는 하지만 부르지 않기 때문에 서로의 그레이드(Grade)를 잘 모르고 있다. 회사에 외국인 개발자는 점점 늘고 있고, 영어 사용이 늘고 있어서 영어 호칭이 도움이 되고 있다.

​

둘째, 상하 관계로 의사 결정을 하지 않는다.

​

즉, 전문가를 존중한다. 수평적으로 나뉜 역할에 의해서 대부분의 결정을 한다. 소프트웨어 회사에는 수많은 전문 역할이 있다. 소프트웨어 엔지니어(Software Engineer), 소프트웨어 아키텍트(Software Architect), CTO, 프로젝트 매니저(Project Manager), 프로덕트 매니저(Product Manager), 리스크 매니저(Risk Manager), 빌드 엔지니어(Build Engineer), 테크니컬 라이터(Technical writer), 마케터(Marketer), UI 디자이너, QA 엔지니어, 형상 관리자(Configuration Manager) 등 여러 역할이 있다.

​

물론 작은 회사는 한 사람이 여러 역할을 하며 이 모두를 다하기도 한다. 하지만, 회사가 조금만 커져도 역할을 나누며 각각 전문성을 높여 나간다. 그리고 전문가의 의견을 최대한 존중하고 상하 관계로 의사결정의 뒤엎지 않는다. 자신의 전문 역할이 아니라도 의견을 제시할 수는 있고 토론을 할 수는 있지만 무리하게 남의 전문영역에 침범을 하면 안 된다.

​

"전권을 주면 내가 프로젝트를 성공시켜보겠다"라고 말하는 사람들이 있다. 이우소프트에서는 이런 말은 통하지 않는다.

​

제품의 기능을 결정할 때는 세일즈, 마케팅, 개발팀, 경영진의 의견은 대부분 상충된다. 이때 직급의 힘으로 의사 결정을 하지 않는다. 각자 전문가로 역할을 수행하며 논쟁을 하고 경영진은 회사의 비전과 프로젝트의 목표에 알맞게 균형을 맞추고 조율하는 일을 주로 한다. 직원을 채용할 때도 신입이나 주니어 급 직원은 상관없지만 경험이 많은 직원을 채용할 때는 권위의식이 있는지 상명하복에 익숙한지 잘 살핀다.

​

셋째, 허락 받고 일하기 보다는 자율적으로 일한다.

​

상사가 일을 시키고 하급자는 시키는 일을 하는 구조가 아니다. 대부분은 스스로 일을 찾고, 스스로 할 일을 정해서 한다. 물론 시켜서 하는 일도 있다. 하지만 능동적으로 스스로 일을 찾아서 하는 것을 권장하고 있고, 하는 일은 모두 시스템에 등록을 하기 때문에 팀장이나 동료들이 모두 모니터링을 할 수 있다. 가끔 일이 잘못 진행되거나 우선순위 조절에 문제가 생기기도 하지만 모니터링을 하다가 바로 잡아주면 된다.

​

업무의 자율성을 높이기 위해서는 뭔가 잘못되었을 때 처벌을 강조하면 안 된다. 처벌이 강할수록 수동적으로 바뀐다. 그리고 문제가 생겼을 때는 여러 사람의 공동책임이다. 시스템에 일을 너무 늦게 공유를 했거나, 모니터링을 소홀히 했을 수가 있다. 프로세스를 잘못 이해하고 있을 수도 있다. 처벌보다는 원인을 찾아서 개선을 해야 한다. 고의로 잘못을 한 것이 아니라면 직원의 일방적인 책임은 아니다.

​

이런 방식이 허락 받고 일하거나 시키는 것 위주로 일하는 것보다는 훨씬 생산성이 높다. 기본적으로 시키는 일보다는 자신이 선택한 일이 더 재미있고 집중도도 높다. 또한 자율성, 창의성이 향상되므로 업무 효율성은 훨씬 높아진다. 물론 모든 직원이 다 적극적이고 능동적인 것은 아니다. 여러 성격의 직원들이 섞여 있지만, 능동적인 직원들의 발전이 더 빠르다. 시키는 일만을 위주로 회사가 돌아간다면 창의적인 지식산업이 소프트웨어가 노동 산업으로 전락할 수가 있다.

​

이우소프트가 이렇게 수평적인 조직문화를 잘 정착한 데는 이유가 있다. 실리콘밸리에서 20년동안 개발을 한 CTO와 수평적인 문화를 당연하게 받아들이는 경영진이 있어서 가능했다. 오히려 직원들이 수평적인 조직문화에 적응하는데 시간이 걸렸다. 한국 대기업들이 수평적이고 자율적인 문화로 조직문화를 탈바꿈하는 것이 쉽지 않은 이유다. 마음만 먹는다고 바뀌는 것도 아니고 경영진은 여전히 무소불위의 권력을 행사하면서 직원들끼리 수평적인 조직문화를 만들 수는 없다. 문화란 대물림이 되고 바뀌기 매우 어렵기 때문에 외국인을 채용하거나 외국 회사를 흡수 합병해도 그들의 문화는 사라지고 기존의 상명하복 문화에 억지로 적응해야 하는 상황이 벌어진다.

​

수평적인 조직문화는 다른 문화의 기반이 되기 때문에 특히 더 중요하다. 수평적인 조직문화 하에서 공유와 협업이 더 잘되며 전문가로서 캐리어를 꾸준히 유지하기도 쉽다. 사규를 만든다고 되는 것도 아니다. 모두의 생각이 바뀌어야 한다. 경영진들이 먼저 수평적인 조직문화에 완전히 적응을 해야 직원들이 따라 올 수 있다.

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

SW개발의 8:2 법칙, 그리고 불편한 진실 (개발문화 시리즈4)

이번 개발문화 이야기는 '가내 수공업식 개발문화'다. 즉, 8:2 법칙에 관한 이야기다.  소프트웨어 개발에 있어 시스템과 개발자에 의존하는 비율이 8:2정도가 되어야 한다는 것이다. 

그럼 다른 분야는 어떨까? 예술적일수록 시스템에 의존하는 비율이 낮고, 체계화되고 규모가 클수록 시스템 비율이 높아져서 인력에 대한 유연성은 증가한다. 

소프트웨어 개발에 있어 가장 중요한 요소는 사람이다. 즉, 개발자이다. 그런데 전적으로 개발자에게 의존하는 개발방식은 효율도 떨어지고 리스크도 높다. 특히 소수 인력에 의존하는 방식은 가내수공업 형태를 벗어나지 못한다.

비단 소프트웨어 분야 뿐만이 아니다. 전통 도자기 등 시스템화로 인해 산업화를 못 이루고 맥이 끊겨 사라져버린 분야가 얼마나 많은가? 임진왜란 때 수많은 도공을 납치해간 일본은 도자기 생산을 체계화해서 산업화에 성공했다. 유럽 수출을 시작으로 부를 쌓아서 선진국이 되는 발판을 마련했다. 

회사 규모가 크나 작으나 회사 시스템에 대한 의존도가 매우 낮고 개별 개발자에 의존하는 회사는 개발자들을 효율적으로 활용하지도 못한다. 개발자들이 퇴사하면 큰 타격을 입고 새로운 개발자가 들어와도 효율적으로 일하는데 많은 노력과 시간이 필요하다. 

개발자들이 실력에 맞는 일을 적절하게 골고루 나눠 하지 못하고 한쪽으로 치우치기 일쑤고 고급 개발자들이 소방수역할을 하는 경우가 많다. 회사 규모는 큰데 여전히 가내수공업 형태를 못 벗어난 결과다. 

이런 현상은 회사가 시스템을 효율적으로 갖추지 못해서 벌어진다. 회사 시스템이란 개별 직원과 대비되는 회사의 전반적인 체계를 말한다.소프트웨어 회사 또는 소프트웨어를 개발하고 있는 모든 회사라면 갖춰야 할 시스템은 다음의 4가지가 있다. 

조직, 프로세스, 문화, 기반시스템이다. 

4가지를 잘 갖추고 있다면 특정 개발자에게 의존하는 리스크는 줄고, 개발자들도 더 효율적으로 일할 수 있다. 개발자가 이직을 해도 빠른 시간 안에 적응이 가능한다. 이것은 개발자와 회사 모두에게 이익이 된다. 

이렇게 되려면 소프트웨어 개발이 시스템에 의존하는 비율이 80%정도는 되어야 한다. 나머지 20%는 도저히 시스템으로 커버가 어려운 부분이다. 하지만 대부분의 회사는 8:2가 아니라 2:8 또는 1:9이기 때문에 문제다.

개인 회사이거나 아주 작은 회사도 지속적으로 성장하려면 시스템에 의존하는 비율을 0%에서 시작하여 20%, 50%, 80%로 차츰 높여가야 한다. 

특정 개발자가 빠져 나가면 대부분의 개발 경험과 지식도 함께 빠져나가게 되는 경우 회사는 매우 불안한 상황에 놓인다. 이런 상황을 개발자가 의도적으로 만든 것은 아니다. 회사의 시스템이 워낙 부실하기 때문이다. 

이런 상황이라면 개발자도 워낙 바빠서 그런 상황에 신경 쓸 겨를이 없다보니, 상황은 더욱 악화된다. 단기적으로는 개발자 가치가 올라가서 더 좋을 것 같다. 하지만 장기적으로 보면 이런 환경에서 개발자는 적절한 성장 기회를 얻지 못한다. 아키텍처는 신경 쓰지도 못하고 여기저기 불려다니면서 재미없고 힘든 문제 해결에 주로 투입된다. 개발자 본인에게도 장기적으로는 손해다. 

여기에는 몇 가지 논란이 있을 수 있다. 

첫째, 그럼 개발자는 교체 가능해야 하는 부품인가? 

회사가 시스템을 갖춰야 하는 이유는 개발자를 교체 가능하도록 하기 위한 것이 아니다. 리스크를 줄이고 좀더 효율적으로 개발하기 위해서이다. 개발 중에는 교체가 쉽게 되는 일이 있고, 어려운 일이 있다. 교체가 쉽게 되는 일까지 회사 핵심개발자들의 시간을 많이 빼앗으면 안된다. 회사 핵심 개발자들은 좀더 중요한 일을 해야 한다. 

그러려면 쉬운 일들, 과거에 해놓은 일들을 다른 사람이 할 수 있는 시스템이 필요하다. 이런 상황에서는 핵심 개발자가 퇴사해도 유지보수에 큰 문제가 없다. 하지만 미래의 중요한 프로젝트에 타격을 입기 때문에 개발자들의 가치는 결국 커진다. 물론 아주 작은 회사는 상황이 다르다. 

둘째, 시스템을 아주 잘 갖추고 있는 대기업이 소프트웨어 개발을 더 잘해야 하는 것 아닌가? 

시스템은 회사의 상황과 역량에 알맞게 적절히 갖춰야 한다. 하지만 큰 회사들은 여기서 큰 불균형을 이루는 경우가 많다. 프로세스를 과도하게 복잡하게 하고 사용하기도 힘든 비싼 시스템들을 구축해 사용을 하기는 하지만 효율성 측면에서의 개발문화는 한참 뒤쳐져 있다. 

이런 상황에서 프로세스는 형식적으로 흐르고 비싼 시스템은 장식물에 그치는 경우가 많다. 개발효율로 따지만 주먹구구보다 더 못한 경우도 있지만, 보험의 성격이 있어서 쉽게 포기하지도 못한다. 

소프트웨어 회사가 갖추어야 할 시스템, 즉, 조직, 프로세스, 문화, 기반시스템은 교과서에 딱 정해져 있는 것은 아니다. 회사 규모, 성격 등에 따라서 계속 바뀌어 나가야 한다. 부족해도 문제고 과도해도 안된다. 

개발자 혼자 회사를 하면 혼자서 모든 것을 다해야 하지만, 10명, 30명, 100명으로 늘 때마다 조직 구성이 달라져야 한다. 하지만 많은 회사들이 큰 규모에 비해서 이런 구분 없이 개발자에게 너무 많은 일을 맡기고 있는 경우가 많다. 

보통은 회사가 커지면서, 테스트, 빌드, 시스템관리, 기술지원, 고객지원, 영업지원 등과 같은 일들은 전문조직으로 분리해야 한다. 어려운 점은 적절한 시점에 적절한 규모로 조직을 변화시켜야 한다는 것이다. 

그럼, 프로세스는 어떤가? 여기에도 극과 극이 있다. 명시적인 프로세스가 아예 없거나 너무 복잡한 경우도 많다. 프로세스는 최대한 단순하고 자유도를 높이면서도 핵심적인 요소들은 빠지지 않도록 해야 한다. 이 또한 회사의 역량이 높아감에 따라서 계속 바뀌게 된다. 

많은 회사들이 열악한 개발 문화와 낮은 역량을 비싼 기반시스템이 해결해 줄 것으로 착각한다. 꼭 필요한 기반시스템도 있지만 오히려 해가 되는 경우가 훨씬 더 많다. 소수의 필수 시스템을 제외하고는 적절한 시점에 필요하면 사용하면 된다. 꼭 비싼 시스템이 아니라도 상관없다. 개발자당 연 사용료가 수백, 수천만원하는 종합선물세트 시스템을 구축해 놓고 극히 일부 기능만 쓰는 경우도 많다. 툴로는 결코 문화나 역량을 극복할 수 없다. 

반대 경우도 문제인건  마찬가지다. 필수 기반시스템 하나 없이 주먹구구로 개발하는 회사라면 좋은 오픈소스 기반시스템들이 있으므로 잘 선택한뒤 제대로 가이드를 받아 사용하면 된다. 과도한 경우보다는 개선하기가 쉽다. 

회사 규모에 맞게 안정적이며 꾸준히 역량을 향상하면서 개발을 하려면 개발자에게만 책임을 지울 것이 아니라 회사가 더 많은 것을 갖추고 있어야 한다. 그러기 위해서 꾸준한 투자와 변화는 필수다. 작년과 올해 조직, 프로세스가 똑같고 변화를 위해 투자를 한 것이 하나도 없다면 회사는 책임을 회피하고 있는 것이다.

리스크를 줄이고 개발자가 보다 효율적으로 일할 수 있는 환경을 만들려면 회사가 80%를 갖출 수 있도록 노력해야 한다.

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

SW개발, 맥가이버식 전문가가 위험한 이유(개발문화 시리즈8)

이번 개발문화 이야기는 '전문가문화'다. 

어떤 개발자가 국내 유수의 소프트웨어 기업에 취업하려고 한다고 가정 해보자. 개발자가 수백명에 달하는 이 회사에 지원을 하면서 본인을 다음과 같이 소개한다고 보자. 

“저는 빌드 전문가입니다. 빌드 기술 연구와 실무 경험이 5년이나 됩니다.” 

그럼 이 개발자는 취업에 성공할 수 있을까? 모든 회사가 상황은 아니지만 이 개발자가 주장하는 “빌드 전문가”라는 것에 대해서 제대로 이해하고 그 가치를 높게 평가할 회사가 그렇게 많지는 않을 것이다. 오히려 이렇게 생각하는 개발자도 있을 수도 있다. 

“빌드 전문가? 그게 그렇게 어려운 건가? 나는 비주얼스튜디오나 이클립스에서 버튼하나 누르면 그냥 빌드가 다 되는데 전문가가 필요한가? 그냥 프로젝트에 투입할 수 있는 프로그래머나 뽑아주면 좋겠네” 

그럼 소프트웨어가 아닌 다른 분야는 어떨까? 

여기 집을 만들고 있다. 그런데 어떤 사람이 “저는 설계도 할 줄 알고 목수, 미장에 벽돌도 잘 쌓아요. 제게 맡겨주면 제가 다할 수 있습니다”고 얘기한다고 하자. 

어떤 생각이 드는가? “정글의 법칙”에서 집을 잘 지을 수는 있어도 내가 사는 집을 맡기기에는 불안하다. 하나 하나가 얼마나 전문성이 있고 어려운 일인지 일반인도 잘 알기 때문이다. 설령 다 할 줄 아는 사람이 있어도 설계를 잘하는 사람에게 벽돌도 쌓으라고 하면 비용도 더 많이 들고 비효율적이라는 것은 쉽게 이해한다. 

여기 운동선수를 뽑으려고 한다.

한 지원자가 “저는 농구, 축구, 야구 모두 잘합니다”고 주장한다. 프로선수를 뽑는데 이 선수를 채용하겠는가? 초등학교에는 이런 천재가 존재한다. 하지만 프로세계에서는 어림도 없다. '농구의 신' 마이클 조던도 야구선수로는 별볼일 없다는 것을 잘 알 것이다.

좀더 범위를 좁혀서 프로 축구선수를 뽑는다고 하자. 지원자가 공격, 수비, 골키퍼를 모두 잘한다고 주장하거나 프로 야구선수가 투수, 포수, 1루수, 유격수, 외야수, 지명타자까지 다할 수 있다고 하면 최고라고 생각하지는 않을 것이다.

그런데 소프트웨어 현장에서는 모든 것을 다 잘하는 만능선수를 선호하고 한 분야의 전문가에 대해서는 이해도 낮고 인기도 없다. 

소프트웨어는 앞에서 언급한 다른 분야에 비해서 덜 복잡하고 쉬운 분야가 아니다. 인류가 만든 가장 복잡한 지식산업이라고 하는 것이 소프트웨어다. 영화를 만들어도 카메라, 조명, 작가 등 전문가로 나뉘어져 있지만 소프트웨어는 이에 못지 않은 전문분야가 있다. 

다시 빌드로 돌아가보자. 빌드는 생각보다 전문성이 필요한 분야다. 빌드 전문가가 개발자가 아닌 것은 아니다. 보통 개발자로 성장하다가 빌드 분야에서 더욱 연구를 많이 하고 실무를 통해서 전문가가 된 개발자이다. 

작은 규모의 회사에서는 개발자가 짬짬히 해볼 수 있는 일이지만 규모가 커질수록 일은 점점 기하급수로 늘어가며 비용도 많이 들어가고 사고의 위험도 커진다. 

큰 회사에는 빌드팀이 별도로 있을 뿐만 아니라 여러 빌드 전문가들이 빌드 자동화와 효율을 높이기 위해서 노력한다. 빌드가 자동화되면 개발팀이 얻는 혜택은 대단히 크다. 빌드 전문가가 없다면 개발팀은 이런 혜택을 누릴 수 없고 비용은 더 많이 들어간다.

소프트웨어에서 이렇게 전문성이 필요한 분야가 매우 많다. 대부분 잘 알고 있는 QA분야를 비롯해서 테크니컬 라이팅, DB관리자, 데이터분석가, 테크니컬 마케팅, 국제화 전문가, UX전문가, 번역가, 아키텍트 등 다양하며 도메인 및 특정 기술 분야마다 매우 다양한 전문가가 있다. 회사마다 필요한 전문분야도 다르다. 

물론 뛰어난 소프트웨어 개발자는 여러 분야에 대해서 두루 잘 알지만 하나하나의 전문가가 되기는 어렵다. 그 중에서 한 두가지 분야의 전문가는 될 수가 있다. 

그럼 왜 이렇게 전문가에 대한 인식이 낮고 전문가가 제대로 대접을 받지 못할까? 

주된 이유는 우리나라에서는 프로젝트 규모가 크나 작으나 가내수공업식으로 개발을 하는 곳이 많기 때문이다. 물론 잘하고 있는 회사도 많으므로 모든 회사가 그렇다는 것은 아니다. 그런데 의외로 개발자는 수천명인데 속을 보면 수많은 가내수공업팀이 있는 경우도 있다.

장인정신하면 도자기가 떠오르기도 하지만 수백년전 우리나라 전통도자기는 전문가를 키우지 않아서 산업화에 실패했다. 한명의 도공이 도자기 생산 프로세스 모든 것을 담당했다. 예술성은 뛰었났을지언정 효율적인 생산은 하지 못했다. 

하지만 임진왜란때 수백명의 도공을 납치해간 일본은 도자기 생산과정을 수십가지로 나눠서 각각의 전문가를 키워서 산업화에 성공했다. 도자기 성형만 하는 사람, 유약만 만드는 사람, 색을 내는 염료만 연구하고 만드는 사람 등 수십가지의 전문가가 있다. 

현대의 도자기 산업과 별반 다를 것이 없다.

이렇게 전문가를 키우지 않는 문화는 현대까지 이어진 것일까? 회사가 작을 때는 한 개발자가 많은 일을 해야 하므로 만능 개발자를 선호하고 그런 개발자가 회사를 키우는데 원동력이 됐다. 

그런데 회사 규모가 엄청나게 커졌는데도 여전히 그런 만능 개발자만 선호하고 개발자가 똑같이 개발 과정의 모든 일을 해야 하는 경우가 많다. 

물론 개발자는 여러 분야의 일을 다 할 수는 있지만 전문가보다 잘할 수는 없다. 개발자는 자신이 전문가인 분야가 따로 있다. 대충 할 줄 아는 사람과 전문가는 하늘과 땅 차이다. 개발하는 제품의 품질에서도 차이가 발생한다. 

이런 일이 발생하는 이유는 소프트웨어 전 개발과정의 전문성을 제대로 이해하는 사람이 회사에 없기 때문이다. 그래서 전문가라고 하더라도 막상 취업을 해서는 자신의 전문성과는 전혀 관계가 없는 일을 하게 될 가능성이 매우 높다. 

주변에서 이런 경우는 매우 많이 본다. 이미지 프로세싱을 10년 가까이 해서 한국으로 채용되어 온 인도 개발자를 만난 적이 있다. 한국회사는 자신의 전문분야의 일을 할 수 있게 해주겠다고 약속을 했지만 현재 일반 UI개발을 몇 년째 하고 있다고 한다. 이번 계약이 끝나면 바로 인도로 돌아가고 싶다고 한다. 

만능개발자만 100명있는 개발조직보다는 개발자는 80명만 있고 20명은 각 분야의 전문가로 구성한 조직이 훨씬 개발 효율이 높고 제품의 품질도 올라갈 것이다. 

회사의 규모에 맞게 적절한 전문가를 채용하고 키워야 한다. 작은 규모에서 시작해서 성장하는 회사라면 회사가 커가는 적절한 시점에 전문분야로 분리해야 한다. 

우리가 흔히 알고 있는 전문분야도 있고 소프트웨어 전문가가 아니면 모르는 전문분야도 있다. 필요한 전문분야도 회사마다 다를 수도 있다. 영업만 이해하는 경영자가 개발팀을 구성하면 만능개발자가 바글바글한 조직이 될 가능성이 높다. 

조직을 전문화하고 효율적으로 만들려면 이를 이해하고 이끌 수 있는 CTO급의 개발자가 꼭 있어야 한다. 

여러 전문가가 효율적으로 협업하려면 프로세스도 중요하고 무엇보다 성숙한 개발문화가 필요하다. 성숙한 개발문화를 이 글에서 다 설명할 수는 없다.

현재 필자가 개발문화에 대해서 컬럼을 두달 넘게 쓰고 있지만 화두만 던지는 것이지 배울 수는 없다. 화두를 가지고 깨닫고 적용하여 경험을 통해서 전진해야 한다. 

CTO급 개발자가 필요하다고 했지만 가내수공업식 개발환경에서 성장한 개발자는 아무리 오래 개발을 했고 뛰어나다고 하더라도 소프트웨어 전문성에 대해서 다 알기는 어렵다. 성숙한 개발문화와 전문화된 조직에서 다양한 경험을 한 개발자가 도움이 될 것이다. 

당장은 개발자가 한 분야의 전문가가 되었다고 하더라도 회사에 어필하기 쉽지는 않을 수 있다. 소프트웨어 문화가 점점 성숙되고 전문가에 대한 이해도가 증가할수록 전문가에 대한 대우는 좋아질 것이고 맥가이버식 만능개발자보다 더 인기가 많아지는 때가 올 것으로 생각한다.

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

대한민국 개발자가 불행한 이유

미국에서 과거 10년 넘게 최고의 직업에 항상 소프트웨어 개발자와 아키텍트가 자리하고 있고 미래 성장 가능성도 상당히 높게 평가하고 있는 것을 보면 격세지감을 느낀다. 10개나 100개 직업 중에 1위가 아니고 몇 만개의 직업 중에 1위라는 것은 대단한 것이다. 그러나 우리나라에서 소프트웨어 개발자는 그렇게 인기가 있는 직종이 아니다. 의사, 변호사와 비교는 고사하고 3D 직업이라는 인식도 팽배하다.

이는 단순히 소득의 차이 때문은 아닌 것 같다.

우리나라에서 소프트웨어 개발자로 일하게 되면 10년, 20년 그리고 30년 이상 소프트웨어 개발자로 계속 일할 수 있다는 희망이 잘 보이지 않는다. 왜 그럴까? 이런 환경에서 태어난 대한민국의 소프트웨어 개발자는 불행하다고 할 수 있다. 미국이라고 무조건 개발자로서 성공적인 삶을 사는 것은 아니지만 같은 조건이라면 개발자로 잘 성장할 확률이 더 높고 여건도 좋다.

이런 차이가 발생하는 이유는 타고난 재능의 차이도 아니다. 개발자들의 기술력의 차이도 아니다. 바로 환경의 차이 때문이다. 소프트웨어 산업 생태계의 차이도 크지만 각 회사, 개발팀의 개발 문화 차이가 가장 크다. 이런 개발 환경을 만든 것은 개발자 여러분은 아니고 여러분의 선배들과 회사이다.

지금 이 글을 읽고 있는 소프트웨어 개발자가 만약에 미국에서 태어나 소프트웨어 개발자로 일하고 있다면 상당히 다른 환경에서 다른 경험을 하면서 성장할 것이다.

물론 우리나라가 더 좋은 환경을 가지고 있는 것도 있고, 내세울 수 있는 것도 있지만 소프트웨어 환경에 대해서는 이 땅에서 태어나 영어 때문에 고생하는 것처럼 핸디캡이 되는 것은 사실이다.

소프트웨어 선진국은 개발 프로세스, 기반 시스템, 조직 문화, 개발 문화 측면에서 큰 차이가 있고 성장을 도와줄 선배 개발자들이 많고 롤모델(Role model)도  있다. 우리나라에도 선배 개발자들이 많이 있지만 경험의 전수가 잘 안되는 구조가 문제다. 여기서 선순환과 악순환의 차이가 발생한다.

소프트웨어 선진국에선 입사를 하면 대부분 바로  업무에 투입된다. 문서, 시스템이 잘 갖춰져 있어서 버그를 수정하는 일을 하는데 큰 어려움이 없다. 버그추적시스템을 통해서도 버그를 할당 받고, 많은 정보를 얻을 수 있다. 소스코드는 시스템을 통해서 바로 한줄 한줄의 수정된 역사를 볼 수 있고 내용을 물어보러 다니지 않아도 웬만한 버그는 수정이 가능하다. 빌드도 자동화 되어 있어서 내용을 몰라도 누구에게 물어보지 않고도 한번에 빌드가 된다. 또한 내가 고친 코드는 피어 리뷰(Peer review)를 통해서 코딩 컨벤션 준수 여부뿐만 아니라 더 좋은 기법 등을 배운다. 분석, 설계 등에도 참여하고 지속적인 피어 리뷰를 거치면서 경험이 점점 깊어지고 후배나 동료들에게 내 지식과 경험도 공유하게 된다.

이렇게 할 수 있는 핵심은 적절한 피어리뷰다. 피어리뷰가 가능한건 기반시스템이 잘 갖춰져 있기 때문이다. 또 개발에 집중할 수 있고 다른 일은 신경쓰지 않아도 되는 프로세스와 조직문화 때문이다. 10년, 20년이 되면 시니어 엔지니어가 되거나 아키텍트가 될 수 있다. 회사 내에서 다른 프로젝트로 옮겨 다니거나 이직을 해도 후배들이 이어 받아서 아무 문제없이 개발이 지속된다. 15년이 되었는데 연봉도 다른 직업의 친구들보다 훨씬 높고 만족감이 높다.  과거 같이 일하던 동료가 차린 유망한 스타트업에 스톡옵션을 받고 참여하는 기회도 잡을 수 있다.

그럼 우리나라에서 소프트웨어 개발을 시작한다면 어떨까? 좋은 회사, 나쁜 회사, 여러 가지 경우가 있지만, 그 중 일반적인 예를 하나 보자.

대학에서 소프트웨어 전공을 하고 입사를 했다. 회사에서 개발하고 있는 소프트웨어에 대한 도메인 지식이 없으면 개발에 참여 하기가 어렵다. 관련 서적을 받아서 몇 달간 공부를 하고 회사에 대한 여러 가지 교육을 받는다. 제대로 개발에 참여하려면 최소 6개월이 걸린다고 하니, 일단 바로 유지보수에 투입된다. 소프트웨어를 파악할 수 있는 자료는 소스코드 밖에 없다. 선배들에게 물어물어 소스코드를 내려 받았고 개발환경을 구축하는데도 하루가 걸렸다.

빌드가 쉽지 않아서 여러 번의 실패와 우여곡절 끝에 빌드에 성공했다. 소스코드를 보고 분석을 하다가 도저히 몰라서 선배에게 물어보려니 개발한 선배가 퇴사를 했단다. 밤을 세서 수정을 했는데 제대로 동작하고 부작용(Side effect)은  없는지 확신은 없다. 누구도 내가 작성한 코드를 리뷰해주지 않는다. 그러다가 개발한지 얼마 되지도 않았는데 실전 사이트에 투입됐다. 선배와 같이 고객을 만나서 요구사항을 듣고 커스트마이징 작업을 진행했다. 워낙 바빠서 문서작성은 꿈도 못 꾸고 코딩만 했다.

선배와 내가 아니면 회사의 누구도 우리가 한 작업의 내용을 모른다. 경험이 쌓이면서 좀더 어려운 일을 맡고 바쁜 개발일정을 소화한다. 문서도 없고, 시스템에도 정보도 없고, 피어 리뷰도 없는 것은 여전하다. 회사에서 강제로 문서를 만들라고 해서 만들기는 하지만 쓸모 없는 문서일 뿐이다.

7년쯤 일하니 회사에서 제일 개발을 잘하는 개발자가 되었다. 경영진이 능력을 인정해서 팀장도 되었다. 팀장이 되니 회의도 많고 보고서도 많이 써야 한다. 낮에는 일할 시간이 거의 없어서 직원들 퇴근 후에 개발을 하게 되었다. 그러나 보니 차츰 개발에서 손을 떼게 되었다. 다시 개발로 돌아 가려고 하지만 여건이 안 된다. 팀장을 몇 년 하다 보니 정체성이 없어지고 앞길이 막막해졌다. 이제 치킨집을 차릴 때가 되었나 보다.

이러한 선순환과 악순환의 차이를 극복하려면 개발 환경을 바꿔야 한다. 개발프로세스, 기반시스템, 개발문화, 조직문화가 바뀌어야 한다. 우리가 이를 바꿔나가지 않으면 우리 후배들도 10년, 20년 후에 똑같은 얘기를 하면서 한숨을 쉬고 있을 것이다. 이는 비단 후배들만을 위한 일은 아닐 것이다. 우리가 일할 10년, 20년 후의 소프트웨어 환경을 바꾸는 일이다.

환경을 바꾸려고 하니 무엇부터 바꾸어야 할지 막막한 경우가 많다. 물론 회사마다 다르기는 하지만 쉬운 것부터 하는 것이 좋겠다. 우선 효율적인 기반시스템을 갖추는 것이 좋다. 성숙도에는 차이가 크겠지만, 소스코드관리, 버그관리, 빌드 자동화를 갖추고 서로 연동을 시킨 뒤  소스코드를 보면 버그나 이슈가 연결되고 반대로 버그가 소스코드와도 쉽게 연결될 수 있는 환경을 만들어야 한다.  그리고 나면 피어 리뷰를 할 수 있는 환경이 조금씩 되어 간다.

거의 모든 것을 완벽하게 자동화하는 것이 바람직하다. 자질구레하게 중간중간 수동 작업이 많이 들어가면 회사가 커갈수록 비용은 점점 올라가고 비생산적인 일에 많은 노력을 들여야 한다. 또 완전 자동화된 시스템 환경이어야 공유와 효율적인 협업이 가능하다. 인터넷에서 정보를 얻어서 좋을 툴을 설치하는 것은 어렵지 않지만 제대로 구축해서 잘 사용하는 것은 몇 백배 더 어렵다. 경험을 많이 해본 선배들의 도움을 받는 것은 필수적이다.

이 정도 되어야 환경을 바꾸기 위한 마라톤의 한 발을 내디딘 것이라고 보면 된다. 그래도 시작이 반이다. 의미 있는 한발이 될 것이다.

이 글은 제가 CNet Korea에 기고한 칼럼입니다. (http://www.cnet.co.kr)