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

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

다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에 따라 잡은 분야가 꽤 있다. 하지만 소프트웨어는 기껏해야 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에 기고한 칼럼입니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

넷째, 계약은 서류일뿐 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SW개발과 규칙의 두얼굴 (개발문화 시리즈6)

이번 개발문화 이야기는 '규칙 준수 문화'다. 

우리 주변에서 규칙을 무시하는 현상을 자주 볼 수 있듯 소프트웨어 개발에 있어서도 규칙을 준수하지 않는 일은 자주 벌어진다. 물론 규칙을 정말 상세히 정하고 모든 사람이 규칙에 따라 소프트웨어를 개발한다고 더 잘되는 것은 아니다. 

계속 강조하지만 규칙은 최소한으로 정해야 하고 성숙된 개발문화에 의한 개발이 더 효율적이다. 그래도 규칙은 지켜야 하며 지킬 수 있고 지켰을 때 개발 효율이 최대화 되는 규칙을 만들어야 한다. 그럼 규칙을 무시하는 현상이 자주 벌어지는 이유를 살펴보자. 

첫째, 규칙을 지키지 않는 개발자들이 있다. 

보통 회사의 최고 개발자들에게서 종종 벌어지는 현상이다. 소수의 개발자들에게 목을 메고 있는 회사들은 그런 개발자들이 어떤 방식으로 개발을 하던지 그냥 놔두는 경우가 많다. 물론 핑계는 있다. 규칙을 따르면 짧은 기간 안에 개발을 끝낼 수가 없고 자신들이 최고이기 때문에 누가 도와줄 수도 없다고 한다. 

그러면서 프로세스를 따르지도 않고 문서도 안 만들면서 내용을 공유하지도 않는 경우가 많다. 이런 회사에서 규칙은 평범한 개발자들만 따라야 하는 형식적인 것이 되기 쉽다. 이런 과정에서 특정 개발자에 대한 종속성은 계속 커지고 개발 문화는 후퇴하게 된다. 결국 규칙은 있지만 실상은 주먹구구식으로 개발을 하는 것과 비슷하게 된다. 

둘째, 규칙이 너무 복잡하고 많은 경우이다. 

큰 회사일수록 자주 벌어지는 현상이다. 규칙이 회사 역량에 비해서 너무 많고 자세한 경우다. 세계적인 방법론을 흉내낼 때 종종 나타나며, 문제가 벌어질 때마다 규칙을 계속 추가하다 보면 규칙이 너무 많아지게 된다. 이런 조직은 관료화되어 규칙자체가 목적으로 변질된다. 원래 목적인 '소프트웨어를 가장 빠르고 효율적으로 개발하자'는 원칙과 거리가 먼 규칙을 지키기 위해서 앞뒤 가리지 않게 된다. 

결국 개발자들은 이런 규칙을 다 따르고는 도저히 개발이 안되므로 형식적으로 흉내만 내고 피해 다니는 요령을 키우게 된다. 개발 효율성은 오히려 주먹구구식 개발보다 떨어지곤 한다. 규칙은 꼭 필요한 것으로 최소화하고 개발문화와 절묘한 조화를 이뤄야 한다. 

셋째, 경영자들이 규칙을 무시하는 현상이다. 

가장 큰 문제 중 하나는 규칙을 정해 놓고 경영자들이 무시하는 것이다. 경영자들은 프로세스를 무시하고 아무 때나 요구사항을 뒤집고 자신이 전문이 아닌 기술적인 결정에 관여하기도 한다. 우리나라에서는 제왕적인 경영자가 워낙 많아 법은 있지만 왕은 지키지 않아도 된다고 생각한다. 

작은 회사들은 이런 경영자의 통찰력과 빠른 판단이 회사를 성장시키는데 큰 도움이 된다. 하지만 회사가 커지고 전문화되면 얘기가 달라진다. 소프트웨어 개발 과정에서 벌어지는 전문적인 분야에 대해서 한 경영자가 전문가보다 잘 알 수는 없다. 자칫 개발 과정에서 경영자의 개인적인 취향을 강요하는 현상이 벌어질 수도 있다. 

우리나라에서는 규칙과 법을 초월해야 더 막강한 권한을 가졌다고 생각하는 경향이 있어서 이런 일들이 더 자주 벌어지는 것이 아닐까 생각한다. 

결론은 꼭 지킬 수 있는 최소한의 규칙을 만들고 따르는 것이 중요하다. 대부분의 회사에서 소프트웨어 개발 프로세스는 너무 복잡하다. 산출물도 너무 많고 경직되어 있다. 중간에 승인절차가 너무 많은 경우도 수두룩하다. 

회사 성격에 따라서 필요한 프로세스가 다르기 때문에 획일적으로 말하기는 어렵지만 프로세스가 좀더 효율적으로 간단해질 필요는 있다. 그러면서 꼭 필요한 규칙은 만들어야 한다. 

예를 들어 보자. 코딩 컨벤션이 정해져 있다면 자신의 코딩 스타일과 달라도 따라야 하는 것이다. 공유도 규칙으로 강제화하기는 매우 어렵다. 소스코드 커밋(Commit)시 메시지는 몇줄 이상 남기고 소스코드에 주석은 몇줄에 한번씩은 남겨야 한다는 식으로 규칙을 정하면 형식에 치우칠 우려도 있고 자칫 효율이 더 떨어질 수 있다. 

서로 리뷰를 하면서 자연스럽게 개선해나가면 되는데 리뷰를 안하는 것이 문제가 된다. 그래서 리뷰는 일주일에 두번씩 한다고 하거나 소스코드 커밋(Commit)시 70% 이상은 리뷰를 해야 한다는 구체적인 규칙을 정해 놓으면 또 효율성은 떨어진다. 

아주 단편적인 몇가지 예만 들었지만 뭔가 안된다고 자꾸 규칙을 늘리면 규칙을 피해가는 부작용이 또 발생하므로 적절하게 균형을 맞춰서 개발문화를 성숙시키는데 더 노력해야 한다. 자칫하면 말도 안되는 규칙만 점점 늘게 된다. 규칙에 의한 제한보다는 '권장', '독려', '포상' 등이 더 효율적이다. 

이렇게 원래 목적과 점점 거리가 먼 규칙이 자꾸 늘어가는 이유는 효율적인 개발문화 환경에서 개발을 해본 적이 없는 사람들이 자꾸 규칙을 만들기 때문이다. 아무리 소프트웨어 이론을 많이 안다고 해서 효율적인 개발 규칙을 만들 수는 없다. 

가장 좋은 방법은 그런 경험이 많은 개발자들은 회사에 합류시켜서 성숙된 문화를 받아들이는 것이다. 문화를 글로 배울 수 없듯이 경험자들의 도움을 받는 것이 좋다. 기억해야 할 것은 규칙으로 결코 소프트웨어 개발 문제를 해결할 수 없으며 성숙된 개발문화를 형성하는데 더 노력을 해야 한다는 것이다.

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