2013년 12월 29일 일요일

제대로 된 코드리뷰가 힘든 이유(개발문화 시리즈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에 기고한 칼럼입니다.

2013년 12월 20일 금요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

넷째, 계약은 서류일뿐 

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

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

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

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

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

2013년 12월 12일 목요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

2013년 12월 4일 수요일

회의 많았던 SW 개발 회사의 비극(개발문화 시리즈7)

이번 개발문화 이야기는 '회의 문화'다. 

회의 문화는 IT 분야에만 국한된 얘기가 아니다. 이미 많은 논의가 있었고, 회의 문화가 개선된 회사들도 많다. 그러나 변화가 필요한 회사들도 아직 많다. 

회의가 많은 회사는 망한다는 속설도 있는데, 하루종일 회의하느라 정작 일은 퇴근 시간 지나서야 할 수 있다고 하소연하는 고참 개발자나 팀장들을 많이 봤다. 회의를 많이 하는 증상이 있는 회사는 회의 자체의 문제보다 근본적으로 해결해야 할 문제들이 따로 있을 가능성이 높다. 

회의를 하는 방식 자체보다는 근본적인 원인에 대해서 얘기를 해보고자 한다. 

첫째, 우리나라 회사들은 재택근무가 쉽지 않다. 이것은 여러 문화의 결과이기도 하다. 업무지시를 서로 만나서 해야 하고 얼굴을 봐야만 얘기가 되는 상황이라면 재택근무로 일하기 어렵다. 

지금 같이 일하고 있는 동료들이 모두 집에서 일한다고 생각하면 어떻게 될지 상상을 해보자. 전혀 일이 진행되지 않거나 효율이 너무 떨어진다면 다시 한번 생각해봐야 한다. 

회의를 통해서 해결하는 안건의 상당수는 만나지 않고 시스템을 통해서 온라인으로 충분히 의논할 수 있는 것들이다. 물론 회의를 통해서 해결하는 것이 효율적인 안건들도 있다. 이런 안건도 만나서 난상토론을 하기 보다는 이슈를 다 정리한 후에 공유하고 몇가지 핵심 결정사항만 회의를 통해서 해결하면 된다. 

굳이 만나서 해결할 필요도 없고 전화나 화상회의로도 충분히 가능하다. 내용은 이미 공유되어 있고 핵심 사항만 의논하고 결정하면 되기 때문에 시간도 얼마 걸리지 않는다. 그리고 일하는 과정이 시스템을 통해서 투명하게 공유가 되면 굳이 만나서 회의를 해야 할 일은 대폭 줄어들게 된다. 

SI 프로젝트를 진행하다 보면 고객이 개발자의 출석체크를 한다는 얘기도 있다. 모아 놓고 일을 하지 않으면 일이 제대로 진행 되지 않는다고 생각하고 안보이면 제대로 일을 하고 있다고 믿지도 못하는 것이다. 이 또한 투명하게 일이 진행되지 않는 것이 주요 원인 중 하나다. 

재택근무 대신 모여서 일을 한다고 해도 재택근무가 가능한 형태로 일을 해야 더 효율적이다. 현재 재택근무가 불가능하다면 근본 원인을 생각해보자. 

둘째, 경영진에 보고하는 회의가 비효율적이다. 

주간회의와 같은 형태로 주기적으로 정리를 해서 한주간의 업무를 부서별로 취합, 정리해서 보고를 하는 형태의 회의는 우리나라에서 아주 흔하게 볼 수 있다. 다른 분야에서는 어떨지 모르겠지만 소프트웨어 분야에서 이런 형태의 보고회의는 많은 문제를 유발한다. 이런 회의가 없어야 한다는 것은 아니다. 

그러나 이런 회의는 준비과정에 많은 시간이 걸리고 대부분의 회사에서 개발자를 겸하고 있는 개발팀장들의 시간을 많이 소모한다. 그리고 취합되고 정리되는 과정에서 많은 핵심정보는 사라지고 예쁘게 꾸며진다. 경영진은 적나라한 개발현황은 보고 받지 못하고 화장이 잘 된 보고를 받게 된다. 

앞에서도 얘기했지만 모든 개발과정은 시스템을 통해서 투명하게 공유되어야 하고 경영진은 이 시스템들을 통해서 개발 진행상황을 직접 볼 수 있어야 한다. 경영진이 약간의 노력을 보여주는 것도 필요하지만 시스템이 경영진이 필요한 보고서를 실시간으로 만들어 낼 수 있어야 하고 우선적으로 개발문화가 투명하게 바뀌어야 한다.

경영진은 실시간으로 모든 개발상황을 파악할 수 있어야 하고 시스템을 통해 이슈 관련 논의에 직접 참여해야 한다. 앉아서 보고를 받고 구도로 지시하는 방식으로는 너무 비효율적이고 느리다. 회의시간에는 중요한 이슈 몇가지만 논의하면 된다. 시스템에 있는 정보를 굳이 다시 보고를 받을 필요는 없다. 

회의에 관련해서 몇가지 이슈를 섞어서 얘기를 했지만 이 또한 여러 개발 문화와 얽혀있다. 공유가 부족하면 수시로 만나서 물어봐야 하기 때문에 회의가 많아진다. 문서화를 싫어하니 정리한 후에 간단히 결정만 해도 될 회의를 만나서 얘기로 다 풀어야 한다. 

시스템을 통해서 논의를 했으면 자동으로 공유가 되는데 만나서 논의한 내용은 기록에도 남지 않는다. 나중에 딴 소리를 하기도 하고 다른 사람들이 내용을 모르니 똑같은 사안을 또 물어본다. 시스템에 개발 현황이 투명하게 공개가 안되니 일일이 만나서 공유해야 한다. 

뭐든 빨리 빨리 해결하려고 하니 일단 이슈가 생기면 시간이 약간 더 걸리더라도 효율적인 시스템을 이용하지 않고 즉시 만나서 해결하려고 한다. 문서를 작성하고 공유하는 것에 습관이 안돼 있으면 회의를 하면서도 기록을 하지 않고, 그렇다보니 결정사항을 추적하는 것도 쉽지 않다.

이처럼 이제부터 회의문화를 개선해보자고 회의 방법만 고쳐본들 별로 나아지는 것을 없을 것이다. 재택근무가 마치 옆에서 일하는 것처럼 효율적으로 가능할 정도로 근본 원인을 하나씩 개선해야 한다. 그러려면 프로세스, 기반시스템도 바뀌어야 하지만 무엇보다 전반적인 개발문화가 바뀌어 나가야 한다. 

그래야 회의 문화도 조금씩 개선이 되고 회의 횟수와 시간도 줄며 좀더 효율적인 회의문화가 정착 될 것이다.

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