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

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

다른 산업 분야에서는 외국에서 몇백년동안 쌓아온 것을 우리는 몇십년만에 따라 잡은 분야가 꽤 있다. 하지만 소프트웨어는 기껏해야 60년 역사인데 따라잡기가 훨씬 어렵다. 개별 개발자들의 프로그래밍 실력은 결코 뒤진다고 볼 수는 없다. 하지만 전반적인 개발문화의 차이가 격차를 좁히지 못하는 원인 중 하나다. 

소프트웨어 분야에 대한 투자는 개발자 인원수 늘리기와 프로세스 강화에 많이 치우친 경향이 있다. 소프트웨어도 시그마6 등과 같은 기법을 따와서 프로세스를 강화하면 좋은 성과를 낼 수 있을 것으로 착각했기 때문이다.

이렇게 프로세스에 집중하면 '파킨슨의 법칙'처럼 프로세스 관료화의 함정에 빠지기 쉽다. 프로세스는 회사의 변화에 따라 끊임없이 효율적으로 개선이 되어야 하는데 관료화된 조직은 프로세스가 점점 복잡해지지 단순해지지는 않는다. 프로세스가 단순해지고 효율적으로 바뀌면 일이 없어지는 사람이 있기 때문에 점점 복잡하게 만들려는 경향이 있다. 

물론 모든 기업이 그런 것은 아니다. 이런 함정에 빠지지 않은 기업도 있고, 이 단계를 극복해 나가는 기업이 있다는 것을 알고 있다. 하지만 많은 기업들이 이미 프로세스 관료화의 함정에 빠져서 허우적대거나 관료화의 길로 달려가고 있다. 이를 경계하자는 것이다.

그럼 개발 프로세스가 빠지기 쉬운 함정에는 어떤 것이 있는지 알아보자. 

첫째, 현실성이 부족한 프로세스다. 

실제 개발 현장에서는 벌어지지 않는 교과서에나 나오는 것을 실제 개발에 적용하려는 것이다. 가장 광범위하게 벌어지고 있는 현상 중 하나다. 인터넷에서 돌아다니는 지식이나 책을 보고 따라 하거나 소프트웨어 공학을 전공했지만 실전 경험이 부족한 경우 자주 벌어진다. 개발 단계별로 너무 많은 문서를 요구하거나 승인을 필요로 하는 프로세스가 있다. 

원자력 발전소를 만들 때나 필요함직한 문서들을 일반 소프트웨어에서 요구하기도 한다. 이런 문서는 개발할 때도 도움이 안되고 개발 후 유지보수 때도 별로 쓸모가 없게 된다. 마켓요구사항과 기능, 모듈을 추적하기 위해서 추적 매트릭스를 의무적으로 요구하는 프로세스도 있다. 

교과서에서 본적이 있을지는 몰라도 대부분의 소프트웨어에서는 필요도 없고 오히려 방해만 되는 프로세스다. 이렇듯 현실성이 부족한 프로세스는 너무나 흔하다. 개발자들은 어쩔 수 없이 따르는 척은 하지만 대부분 피해가는 요령만 늘게 되고 개발 경험이 쌓이면서 자연스럽게 역량이 성장하는 것을 방해하게 된다. 

개발 프로세스는 성숙된 개발환경에서 수십년 실전 경험이 풍부한 CTO급 개발자가 이끌어야 현실성 있고 효율적으로 만들 수 있다. 

둘째, 너무 상세하고 획일화된 프로세스다. 

프로세스팀이 너무 일을 열심히 하려고 할 때 발생한다. 프로세스는 모든 개발절차를 상세히 정의하기 보다 문제가 될 수 있는 핵심적인 요소를 잘 집어내는 것이 중요하다. 법률에도 비슷한 현상이 있다. 할 수 있는 것을 정의해서 법에 정한 것만 할 수 있게 하거나 하면 안되는 것을 정의해서 그 외에는 모두 할 수 있게 하는 방법이 있다.

모든 절차를 너무 상세하게 정의하면 개발자의 창의성을 저해하고 비효율적으로 흐를 수 있다. 오타 하나를 수정한 경우에도 작성해야 할 문서가 몇 개나 되고 절차도 일주일 이상 걸린다는 하소연을 들은 적이 있다. 개발자에게 자유도가 없이 몇 가지 경우로 획일화된 프로세스에서는 효율적으로 개발을 하기가 어렵다. 

개발자를 믿지 못하기 때문에 개발자에게 자유도를 주지 않는 경우이다. 

최근에 한 기업의 프로세스팀 리더를 만난 적이 있는데 설계문서를 매우 상세하게 작성을 해야 하며 꼭 UML로 작성을 해야 한다고 했다. UML을 이용하지 않고 개발자가 제각각 작성하면 서로 의미가 통하지 않을 수 있다고 한다. 나는 그럴 필요가 없고 개발자가 가장 편하게 작성할 수 있는 방법이면 되고 꼭 UML을 쓸 필요도 없다고 했다. 

화이트보드나 종이에 끄적거리고 토론하다가 사진을 찍어서 문서에 첨부해도 된다고 했다. 물론 이 부분은 논란이 있을 수 있다. 스펙과 설계의 경계에 대한 생각이 다르고 설계를 상세하게 작성해야 개발자들이 코딩을 잘 할 수 있다고 획일적으로 생각하는 것도 문제다. 

설계란 상황에 따라서 필요한 만큼 자유롭게 적절히 하는 것이 중요하고 형식보다는 창의력이 더 필요하다. 
셋째, 잘못된 관행을 그대로 담은 프로세스다.

프로세스팀의 힘이 약한 경우에 발생한다. 개발 프로세스를 정의할 때는 현재의 문제점을 고치고 개발역량을 미래지향적으로 향상시킬 수 있는 방법을 녹여내야 한다. 하지만 현재의 관행적인 절차를 체계화하고 문서화해서 기존의 문제점을 그대로 유지한다면 그야말로 최악이다. 

절차화 되면서 기존에 개발자들이 자유도를 가지고 적절하게 판단하던 효율성도 사라졌고, 미래지향적이지도 않다. 기존의 문제가 점점 고착화 되어 갈 뿐이다. 

개발자들의 의견을 너무 존중해서 민주적인 다수결로 프로세스를 결정하는 것도 문제다. 변화를 싫어하는 것은 동서고금 똑같아서 대중의 의견을 따르면 프로세스는 대부분 실패한다. 

넷째, 벌칙만 잔뜩 담은 프로세스다.

프로세스는 잘못하면 벌을 주려는 형법과는 다른 것이다. 목적 자체가 다르다. 프로세스는 효율적인 개발을 하기 위한 최소한의 절차다. 그리고 프로세스를 따라서 꾸준히 개발을 하면 개발팀의 역량도 향상 되어야 한다. 따라서 적절한 독려와 벌칙이 있을 수는 있다. 하지만 벌칙만 잔뜩 존재한다면 벌칙을 피해 다니는데 집중하게 된다. 물론 치명적인 잘못에 대해서는 벌칙이 있을 수 있다. 치명적인 잘못에는 다음과 같은 것들이 있다. 

-소스코드를 빌드가안되는브로큰 트리(Broken tree)를 만든 경우 
-백업 담당자가 백업을 소홀히 한 경우 
-소스코드를 소스코드관리시스템에 등록하지 않은 경우 
-핵심 프로세스를 따르지 않아서 큰 장애를 만들어 낸 경우 

여기서 버그를 만든 경우는 벌을 받아야 할 만큼 큰 잘못은 아니다. 그런데 버그를 카운트해서 불이익을 주거나 프로세스의 모든 사소한 사항까지 벌칙과 연계를 하면 숨막혀서 개발하기가 쉽지 않다. 

다섯째, 점점 복잡해지는 프로세스다. 

회사는 계속 바뀌고 제품 및 개발팀도 계속 성장한다. 그러면서 프로세스도 계속 진화를 한다. 그런데 매번 프로세스가 점점 복잡해지는 회사들이 많다. 무슨 문제가 있을 때마다 원인을 분석하고 대책을 수립한다고 하면서 확인 절차를 더 추가하고 문서를 더 만들어 내는 것이다. 

이렇게 문제가 있을 때마다 대책을 수립한다고 하면 초 단기적인 대책밖에는 만들어 낼 수 없다. 예를 들어서 근본 원인이 '공유의 문화'가 부족해서라고 해도 수년 걸리는 '공유의 문화' 개선보다는 당장 눈에 보이는 형식적인 절차를 끼워 넣을 수 밖에 없다. 

냄비 안의 개구리는 점점 따뜻해져 오는 물을 느끼지 못하지만 나중에 밖에서 프로세스를 보게 되면 괴상망측하게 변화된 것을 알 수 있다. 프로세스는 역량과 문화 수준이 향상됨에 따라서 점차 간소하게 바뀌어야 한다. 기존에는 프로세스로 강제화하던 것이 몸에 베이게 되면 간단하게 바꿔야 더 효율적이다. 

여섯째, 관료화된 프로세스다.

관료화된 조직에서 흔히 벌어지는 일이다. 개발 문제를 해결하기 위해서 프로세스를 강조하다 보면 프로세스 자체가 목적이 되기도 한다. 효율적인 방법이 눈에 뻔히 보이는 경우에도 프로세스가 그러하니 따라야 한다고 하게 된다. 개발 생산성 향상이라는 목표는 저 멀리 떠나 보내고 각자 팀의 이익을 쫓다 보면 프로세스가 점점 관료화로 치닫게 된다. 

가끔은 없어도 되는 절차를 일부러 만들기도 한다. 개발자들은 이를 피해가는 요령만 늘게 된다. 

물론 열심히 노력하고 잘하는 프로세스팀이 더 많지만 그 중에는 개발 효율성보다는 스스로의 일거리를 늘리고 힘을 키우기 위해서 프로세스를 더 복잡하게 만들고 개발에 끼어드는 경우가 있다. 프로세스팀이 모든 개발 절차를 감시하고 산출물을 검토하고 승인에 끼어드는 경우 관료화게 빠지기 쉽다. 도와주는 역할을 넘어서 스스로 권력화가 되는 것이다. 

결론은 개발 프로세스는 현실적이며 자율적이어야 하고 개발 문화와 균형을 이뤄야 한다. 아직 자율에 맡기기에는 불안하다고 하면 프로세스를 너무 복잡하게 하지 말고 핵심적인 것부터 조금씩 적용하는 것이 좋다. 
개발자가 즐겁게 일할 수 있는 환경이 가장 생산성이 높은 환경이다. 개발 프로세스를 엄격하게 강화하여 소프트웨어 개발 문제를 해결 할 수 있다는 생각부터 잘못된 것이다. 적절한 개발 문화가 뒷받침되지 않는 프로세스는 오히려 짐이 될 뿐이다. 

눈에 보이는 프로세스에는 투자를 하기가 쉬워도 눈에 잘 안 보이는 개발문화는 어떻게 투자를 해야 할지 막막하다. 자칫 잘못하면 사무실 환경이나 슬로건만 흉내를 내는 꼴이 될 수도 있다. 

문화가 바뀌려면 생각이 먼저 바뀌어야 행동이 바뀐다. 하지만 생각은 그렇게 쉽게 바뀌지 않는다. 힘이 있는 선구자가 끊임없이 생각의 변화를 이끌어야 한다. 프로세스가 관료화에 빠지지 않으려면 CTO급의 특급 개발자가 실전 개발 기법을 프로세스에 적용하고 개발문화 향상을 꾸준히 이끌 수 있도록 해야 한다. 

미신과 같은 이론 전문가들의 말과 인터넷에 떠도는 소문에 현혹되지 말고 진짜 전문가인 개발 전문가들을 보호하고 힘을 실어줄 때가 변화의 시작 시점일 것이다.

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

프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 글로벌 수준의 소프트웨어 개발 역량 확보에 실패했다. 10년 전쯤부터는 막대한 자본을 투입해서 개발자 확보 및 소프트웨어 개발에 투자를 하더니 이제는 소프트웨어는 실패했다는 자성을 하고 있다. 돈과 사람을 아무리 투자해도 10년이라는 단기간(?) 내에는 글로벌 수준의 소프트웨어 개발 역량 확보는 쉽지 않다.

많은 기업들이 소프트웨어 개발 역량 확보를 위해서 주로 선택한 방법은 세계적인 방법론과 프로세스의 도입, 직원들에 대한 교육이다. 글로벌 소프트웨어 회사들이 하는 방식과 비슷하게 프로세스를 따르고 문서를 만들고 개발 환경도 비슷하게 갖추었다. 카페 같은 환경도 만들어서 자유롭게 일할 수 있도록 한 회사도 있다. 하지만 그 결과 그럭저럭 소프트웨어 프로젝트의 결과는 나왔으나 소프트웨어 개발은 더 비효율적으로 바뀌었다. 이유는 무엇일까?

감당할 수 없는 수준의 프로세스는 오히려 독이 된다. 10년이라는 짧은 시간에 아직 역량이나 문화가 성숙되지 않은 상황에서 도입한 과도한 프로세스는 소프트웨어를 효율적으로 개발하게 하기 보다는 프로세스가 주인이 되어서 효율성은 되려 떨어지게 되었다. 이런 과정에서 문제가 생기면 이를 해결하기 위해서 프로세스는 더욱 복잡해져만 갔다. 모든 회사가 그런 것은 아니지만 많은 회사가 걸어온 길이다.

소프트웨어를 가장 효율적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 그냥 개발하는 것이다. 그 적절한 과정이라는 것은 성숙된 개발 문화 속에서는 자연스럽게 선택이 된다. 하지만 회사들은 이런 애매모호한 방법을 선택할 수는 없다.  이런 방법은 이미 개발자들의 역량이 충분히 확보가 되고 성숙된 개발 문화를 갖췄을 때만 가능하다. 그래서 많은 회사들은 이런 애매하고 어려운 개발 문화 발전 보다는 명백하고 따라하기 쉬워 보이는 개발 프로세스 정교화에 집중해왔다. 그결과 큰 사고는 줄어들었지만 과거에 주먹구구식으로 개발을 할 때보다 오히려 개발 효율성은 훨씬 떨어졌다. 가끔은 프로세스의 구멍 때문에 큰 사고가 나기도 한다.

프로세스를 아무리 잘 정해도 효율적인 개발 과정을 정의하기 어려운 이유는 뭘까? 아래 대화를 보자. 수십년간 소프트웨어 실전적으로 개발을 해온 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.

Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?

A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?

A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?

A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?

A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?

A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?

A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?

A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.

A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발을 잘 모르는 사람들이 테일러링하기도 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?

A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

일반적으로 프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 개발 문화의 성숙도가 높을수록 프로세스는 간단하다. 

하지만 왜 이렇게 프로세스에 목을 맬까? 프로세스 도입은 쉽고, 개발문화 변화는 어렵기 때문이다. 골프채를 바꾸는 것은 쉬워도, 몸에 완전히 베어버린 골프 스윙을 바꾸는 것은 엄청나게 어렵다. 한사람의 생각과 행동을 바꾸기도 어려운데 전직원을 바꾸는 것은 정말 어렵다.

프로세스는 최소화로 정의하고 성숙된 개발문화를 만들어 가는데 집중하는 것이 좋다. 둘은 보완 관계이기도 하지만, 앙숙관계이기도 해서 프로세스를 너무 강조하는 환경에서는 개발문화를 발전시키기가 어렵다.

개발 문화에는 정보/지식 공유, 스펙 작성, 수평적인 조직, 전문가주의, 경력 보장, 상호 리뷰, 자율, 문서 작성 등 수많은 것들이 있다. 일일이 나열할 수는 없지만 일하는 속에서 이런 것들이 구성원들에게 자연스럽게 스며들도록 제도, 프로세스를 정의하고 독하게 추진을 해야 한다. 그래야 개발문화가 조금씩 바뀌어 나간다.

이렇게 개발문화와 프로세스가 잘 조화를 이룰 때 소프트웨어 개발 역량이 세계적인 수준이 될 수 있다. 개발에 문제가 있다고 복잡한 프로세스를 도입해서 단기적으로 해결해보려는 시도는 장기적으로는 대부분 실패할 것이다. 

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

개발 프로세스가 개발 문화를 이기기 어려운 이유

우리나라의 많은 기업들은 SW 개발에 실패를 했다.

그뒤 선진 소프트웨어 개발 방법을 배우고자 노력을 많이 했고, 그 결과 개발 방법론, 프로세스를 도입하였다.

하지만 그 결과 SW개발은 더욱 비효율적으로 바뀌게 되었다. 그 이유는 무엇일까?

SW 개발에 있어서 정교한 프로세스를 정하면 프로세스에 매몰되고 프로세스가 점점 복잡해져 간다.

완벽한 프로세스는 없는 것이 당연하고 문제는 계속 생긴다. 이때마다 이를 해결하기 위한 프로세스를 계속 만들어가면 괴물 프로세스가 탄생하게 된다.

SW를 가장 효과적으로 개발하는 방법은 프로세스에 상관없이 가장 적절한 과정으로 개발하는 것이다. 그 적절한 과정은 성숙한 개발 문화 속에 있다.

하지만 많은 회사들은 애매하고 어려운 개발 문화보다는 명백하고 따라하기 쉬운 개발 프로세스에 집중해왔다. 그 결과 주먹구구식을 개발할 때보다 개발 효율성은 더 떨어졌다.

프로세스를 통해서 효율적인 개발 과정을 제대로 정의하기 어려운 이유는 아래 대화를 보자. 최고의 소프트웨어 실전 전문가에게 질문을 하면 아래와 같이 답을 할 것이다.

 

Q. 모든 소스코드는 코드리뷰를 다 해야 하나요?

A. 아니요, 그때 그때 달라요.

Q. 코드리뷰에 꼭 포함해야 하는 필수 리뷰어는 누구 인가요?

A. 그때 그때 달라요.

Q. 스펙은 꼭 작성해야 합니까?

A. 그때 그때 달라요.

Q. 스펙을 작성할 때 가장 중요한 부분은 어디 인가요?

A. 그때 그때 달라요.

Q. 설계서는 꼭 작성해야 하나요?

A. 그때 그때 달라요.

Q. 효율적으로 설계서를 작성하는 방법은 무엇인가요?

A. 그때 그때 달라요?

Q. 매번 경우마다 다른데 개발 프로세스는 어떻게 정하죠?

A. 그래서 프로세스를 너무 자세히 정하면 안됩니다. 최소한으로 정하고 개발자들의 판단력을 믿어야 합니다.

Q. 대기업은 그래서 프로세스 테일러링을 통해서 프로젝트마다 적절히 프로세스를 간소화해서 산출물도 줄이는 등 개발 프로세스를 효율적으로 적용하려고 노력하고 있습니다.

A. 이 또한 하다하다 안되니까 형식적으로 진행하는 겁니다. 심지어는 개발도 잘 모르는 사람들이 테일러링을 합니다.

Q. 알아서 하라고 하면 과거처럼 스펙도 없고, 공유도 안하고 주먹구구식으로 하지 않을까요?

A. 그렇기 때문에 역량과 문화가 중요합니다. 문화가 아무리 좋아도 역량이 안되면 공염불입니다.

프로세스는 복잡할수록 손해다. 문제만 없다면 프로세스가 없는 것이 제일 좋다. 문제가 있기 때문에 최소한의 제약을 가하는 것이다. 프로세스가 간단할수록 성숙도가 높다. 물론 주먹구구라서 프로세스가 없거나 간단한 회사는 예외다.

하라고 해서 억지로 하는 상황이라면 효과를 기대하기는 어렵다.

문화라고 하는 것은 "왜"가 아니고 "그냥 그렇게" 하는 거다.

그냥 스펙을 적절히 작성하는 것이고, 그냥 필요한 만큼 설계를 하며, 그냥 코드 리뷰를 한다.

모든 직원이 그냥 그렇게 할 수 있을 때 문화로 정착되었다고 할 수 있다.

그렇게 되면 과거로 돌아가자고 해도 모두 반대한다.

프로세스는 절대로 문화를 이기기 어렵다. 효율성이 몇배 차이가 난다. 10배 이상 차이가 날 때도 있다.

프로세스 보다는 SW 개발의 원리를 깨우쳐야 한다. 각 분야에 전문가들이 최소의 프로세스 하에서 최선의 판단을 해서 진행하면 된다.

잘 안된다고 프로세스를 점점 복잡하게 하고 너무 과하게 적용한다면 문제는 점점 커질 것이다.

개발 문화가 점점 성숙해 질수록 프로세스는 만들었다가 간소화 시켰다가 없앴다가를 반복하게 될 것이다. 그래도 신입직원을 위해서 읽을만한 프로세스 문서는 존재하게 된다. 하지만 기존 직원들은 숨쉬는 것처럼 익숙해지고 원리를 깨우쳤기 때문에 프로세스 문서를 계속 보거나 프로세스를 따라하기 위해서 억지로 행하지는 않게 된다.

이쯤되면 SW를 좀 개발할 수 있게 됐다고 자신 있게 말할 수 있다.

왜 적은 인원으로 빨리 개발하나…개발문화의 비밀 (개발문화 시리즈 1)

우리나라에서 소프트웨어 개발이 3D 취급을 받는 이유는 여러가지다. 끝을 모를 야근과 낮은 대우 등도 포함되겠지만 좀더 근본적인 이유는 따로 있다.  낮은 생산성 때문이다. 소프트웨어를 개발해서 회사가 돈을 많이 벌고 세계적으로 성공하는 소프트웨어가 많이 나온다면 생산성의 핵심인 개발자에게 당연히 높은 대우를 해주게 마련이다.

하지만 우리나라에서는 크게 성공한 소프트웨어 회사가 많지 않다. 그리고 소프트웨어 회사의 수익률이 별로 높지 않기 때문에 소프트웨어 개발자에게 좋은 대우를 해줄 수 없다. 결국 이런 소프트웨어 개발에 대한 낮은 대우를 극복하기 위해서는 성공하는 소프트웨어, 성공하는 회사가 많이 나와야 한다.

 그럼 성공하는 소프트웨어 회사와 그렇지 못한 회사를 가르는 결정적인 차이는 무엇일까? 판단의 요소는 기술적인 것 외에도 많다. 좋은 아이디어, 적절한 타이밍, 경영, 마케팅 등이 더 중요하지만 이런 것들은 내가 논할 주제는 아니다. 나는 같은 조건에서도 성공하기도 하고 실패하기도 하는 차이가 무엇인지 알아보고자 한다. 성공하는 회사의 특징을 가진 회사가 많다면 성공하는 소프트웨어가 더 많이 나오고 우리나라에서도 소프트웨어 개발이 좀더 좋은 대우를 받을 수 있을 것이다.

 하지만 회사마다 제품이 다르고 환경이 달라서 직접적인 비교는 매우 어렵다. 같은 제품을 만드는 회사라도 다른 요소로 인해서 성공과 실패가 갈렸을 수도 있다. 그런데 필자가 알고 있는 비교하기 좋은 사례가 하나 있어 이를 소개한다.

미국의 유명한 글로벌 소프트웨어 업체가 하나 있다. 이 회사는 여러 나라에 지사를 설립했다. 물론 한국에도 지사를 설립해서 개발자를 채용했다. 한국에서 채용한 개발자들은 본사의 서비스를 지역화(Localization)하거나 한국에 특화된 서비스를 개발했다. 미국 본사에서는 한국에서도 소프트웨어를 개발할 때 본사의 프로세스를 따르도록 종용했으나 한국 개발자들은 이를 따르지 않았다. 한국의 개발자들이 보기에 본사 프로세스는 너무 복잡해 보였다.

이와 관련해 처음에는 본사와 한국 개발자들간 충돌이 있었으나 상황은 곧 바뀌었다고 한다. 본사에서 한국 개발자들의 놀라운 개발 속도에 깜짝 놀라서 더 이상 본사의 프로세스를 강요하지 않았다. 초기에는 척척 빠른 속도로 개발을 하다보니, 모든 상황이 좋았다고 한다. 그런데 몇 년이 지나자 완전히 상황이 또 바뀌었다고 한다. 개발이 너무 느려진 것이다. 그 당시 본사는 호주에도 지사가 있었는데, 한국 지사와 비슷한 일을 하고 있었다.

한국 지사는 호주 지사보다 10배 가까운 개발자를 보유하고 있었고, 개발자들이 야근을 거듭해도 호주지사의 개발속도를 따라가지 못했다고 한다. 자세히 파헤쳐보면 더 많은 사연들이 있겠지만 맥락만 봐도 우리나라에서 소프트웨어를 개발하는 방식의 낮은 생산성을 짐작하게 한다.

 물론 모든 회사가 문제가 있다는 것이 아니다. 우리나라에도 좋은 개발문화를 가진 회사가 많다. 상대적으로 그렇지 않은 회사가 많기 때문에 제기하는 문제로 이해해 줬으면 하는 바람이다.

나는 한국지사의 개발자들이 본사의 개발 프로세스를 따르지 않은 것이 문제의 주된 원인이라고 생각하지 않는다. 이렇게 대응한 한국의 개발자들을 비난하려는 것이 아니다. 한국 개발자들은 몸에 베어 있는 개발문화 때문에 본사 프로세스를 따르기도 쉽지 않다. 그런 개발문화와 습관을 익히게 된 우리의 개발 환경이 문제인 것이다.

한국에서 개발을 하다가 실리콘밸리 소프트웨어 회사에 취직을 한 개발자 중에는 개발 문화와 프로세스에 적응하는데 힘들어하는 사람들이 많다. 하지만 문화란 원래 작은 부분이 큰 부분에 흡수되듯이 한 개인은 모든 사람이 공통으로 행동하는 개발문화에 흡수되기 마련이다. 반대로 실리콘밸리의 아무리 뛰어난 개발자라도 우리나라에 오게 되면 꼼짝없이 한국식 개발문화에 적응해야 한다. 본인의 방법으로는 더 이상 어찌해볼 수 없는 상황이 된다.

필자는 한국적인 개발문화부터 실리콘밸리의 개발문화와 관료화된 거대 개발프로세스까지 직간접적으로 다양한 경험을 한 덕에 이를 서로 비교할 수 있다. 그래서 앞으로 효율적인 개발문화에 대해서 구체적으로 얘기를 해보고자 한다.

문화란 한 사회의 구성원들의 주요한 공통된 행동 양식이다. 개발문화는 소프트웨어를 개발하는 구성원들의 공통된 생각과 행동 양식이다. 프로세스처럼 명문화되어 있지는 않지만 대체로 그렇게 행동을 하는 것을 말한다. 우리나라의 개발문화는 형편없다고 주장하려는 것이 아니다. 우리나라의 문화가 더 훌륭한 부분도 있고 장점도 많다. 사실 문제가 되는 부분은 2%에 불과할 수도 있다.

이런 결정적인 결과의 차이를 만들어내는 주요 개발문화의 차이를 비교해보자.

개발 프로세스와 개발문화는 서로 보완적이며 개발문화 없이 효율적인 개발프로세스를 만들기 어렵다. 개발문화가 있다고 개발 프로세스가 필요 없는 것도 아니다. 반대로 아무리 정교한 개발 프로세스가 있어도 개발문화가 뒷받침되지 않으면 개발프로세스는 방해만 될 뿐이다. 그만큼 개발문화는 개발 프로세스보다 중요하다.

그럼 이런 차이를 만드는 개발 문화에는 어떤 것들이 있을까? 지금은 하나씩 나열만 해보고 다음 회부터 각각의 사항에 대해 좀더 자세히 풀어볼까 한다.

첫째, 공유 문화의 부족이다.

사실 우리나라에도 공유문화가 없는 것은 아니다. 하지만 결정적인 차이가 있다. 그 차이를 앞으로 얘기해보겠다.

둘째, 빨리빨리 문화다.

장기적인 고려 없이 무조건 빨리 하는 것은 단기적으로는 빠른 성과를 낼 수 있어도 장기적으로는 몇배 더 느려진다. 다른 산업분야에서는 톡톡히 효과를 봤어도 소프트웨어는 워낙 복잡한 지식 산업이라 빨리빨리 문화가 종종 큰 문제를 야기한다.

셋째, 전문가 vs. 만능 개발자이다.

소프트웨어 산업에서는 전문가에 대한 인식이 떨어진다. 뭐든지 잘하는 만능 개발자를 선호하며 그러다 보니 뛰어난 개발자도 본연의 업무인 개발에 집중하지 못하고 다른 일에 휘둘리다보니 회사는 효율이 떨어지고 개인의 캐리어는 발전하지 못한다.

넷째, 사람 중심 vs. 시스템 중심이다.

다른 분야도 마찬가지이지만 사람 중심의 개발은 리스크를 증가시키며 대체도 어렵게 만든다. 대체 못하는 개발자는 회사와 개발자 서로가 서로의 발목을 잡는 상황이 된다.

다섯째, 규칙 준수 문화 부족이다.

사회 전반의 문제지만 소프트웨어 회사에서는 규칙을 무시하는 사람들이 많다. 특히 조직의 윗선에서 이러한 현상이 더 심각해진다.

여섯째, 서열 중심 문화이다.

전통적으로 수직적인 조직문화가 소프트웨어 개발에는 문제가 된다. 어떻게 해야 이를 극복할 수 있을지 알아보겠다.

일곱째, 낙후된 토론 문화이다.

요즘은 토론 위주의 교육에 신경을 많이 쓰면서 개선되고 있지만 여전히 토론문화는 많이 부족하다.

우선 생각나는 것은 이 정도이며 앞으로 이것들을 포함하여 개선해야 할 여러 개발문화 대해서 하나하나 구체적으로 얘기를 해보고자 한다. 새로운 내용이 있으면 계속 추가해 나갈 계획이다.

그런데 이런 얘기를 시작하면 종종“우리도 해봤는데 안되더라는 얘기를 많이 듣는다. 우리도 공유해보려고 했는데 잘 안 안된다. 우리와는 안맞는다, 그렇게 피해의식을 가진 선배개발자들이 많아서 새로운 시도가 처음부터 막히는 경우가 많다. 대부분은 잘못 시도했거나 의지가 부족해서 실패한 경우가 많다. 이렇게 피해의식이 가득찬 회사는 바뀌기 어렵고 그 끝은 뻔하다. 그렇지 않고 개발문화를 조금씩 바꿔가고 싶은 사람들에게는 도움이 되길 바란다.

개발문화는 조직 전체를 바꿔야 하는 것이기 때문에 한명의 개발자가 몸부림친다고 쉽게 바뀌지는 않는다. 경영자나 중간관리자가 움직여줘야 한다. 회사를 움직일 수 있는 경험과 힘이 있어야 변화를 시켜 나갈 수 있다. 이런 분들에게도 많이 공유가 되면 좋겠다.

워낙 광범위한 주제이기 때문에 독자 여러분들과 많은 의견을 나누면서 얘기를 발전시켜나가면 좋겠다. 구체적인 얘기가 시작될 다음 칼럼에도 많은 관심 부탁드린다.

CNET 코리아에 기고한 칼럼입니다. (http://www.cnet.co.kr/view/25148)

소프트웨어 관료화

"공무원 수는 해야 할 일의 경중이나 업무 유무에 관계없이 일정한 비율로 증가한다", "공무원은 서로를 위하여 서로 일을 만들어 낸다", "유능하지 못한 사람은 공무원이 된다."

이는 그 유명한 파킨슨의 법칙입니다.

소프트웨어를 개발할 때도 이와 같은 함정이 도사리고 있습니다.

주먹구구식으로 소프트웨어를 개발하다가 체계적으로 개발하고 싶은 요구가 생길 때 프로세스팀을 구축하고 개발 프로세스를 정립하다 보면 파킨슨의 법칙에 빠지기 쉽습니다. 

프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드믑니다. 여기서 말하는 소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고 있는 사람입니다.

이런 비전문가로 구성된 프로세스 팀은 소프트웨어 개발의 내용을 속속들이 잘 모르고 너무 형식에 치우칠 수 있고, 끊임없이 프로세스팀이 할 일을 만들어 내기 위해서 프로세스를 점점 복잡하게 만들곤 합니다. 이들은 어떤 것이 정확하게 올바른 방법인지 잘 몰라서 그렇게 하기도 하고, 자신들의 밥줄을 견고하게 하기 위해서 여기저기 승인 절차를 많이 추가해서 프로세스팀이 소프트웨어 개발 프로세스의 중요한 역할을 하고자 한다.

프로세스팀은 소프트웨어를 효율적으로 개발하기 위한 방법들을 연구하지만 소프트웨어 개발 프로세스 중간에 직접 끼어들어서 간섭하는 프로세스를 만드는 것은 바람직하지 않다. 소프트웨어를 개발하는데 있어서 여기저기 승인 절차를 잔뜩 집어 넣어 놓는 것도 그리 좋지 않습니다. 승인 절차가 소프트웨어의 무결성을 보장해주진 않습니다. 오히려 관료화된 승인 절차는 아무런 도움이 되지 않는 경우가 많습니다. 소프트웨어는 각 분야의 전문가들이 자율적으로 효과적으로 움직였을 때 가장 효율적으로 개발됩니다. 명시적인 승인 절차가 없더라 승인절차를 거친 것과 같이 모두가 진행상황을 훤히 알 수 있게 됩니다. 이렇게 개발되는 방식이 오히려 소프트웨어 무결성에 더 도움이 됩니다. 승인 절차는 형식적인 승인이 되기 쉽지만, 각 단계의 전문가들이 리뷰를 하고 Unit 테스트를 하고 시스템 테스트를 하고 빌드전문가가 확인을 하고 이러한 전 과정을 통해서 문제가 되는 것들은 발견이 되고 개발도 효율적으로 진행됩니다.

소프트웨어 개발 경험이 부족한 프로세스 팀은 철저한 승인 절차가 아니면 안전한 소프트웨어를 개발하기 어려울 것 같이 생각되지만, 이는 경험 부족에서 오는 착각이거나 관료화의 조짐입니다.

또 소프트웨어 개발에 대한 이해가 부족한 경영자들은 이들이 주장하는 프로세스가 그럴듯해 보이지만 사실은 소프트웨어 개발에 상당부분 걸림돌이 되고 있다는 것을 눈치채기 어렵습니다.

진짜 소프트웨어 전문가로 프로세스팀을 만들 것이 아니면 내부에서 진행하는 여러 개선 시도들이 시간 낭비인 경우 많고, 시행착오 없이 6개월이면 갖출 수 있는 경쟁력을 먼 거리를 돌아서 수년이 걸리거나 영영 경쟁력을 갖추지 못하는 경우도 많습니다. 프로세스팀을 갖추려면 소프트웨어 전문가로 구성을 하거나 내부에 전문가가 없다면 외부에서 도움을 받는 것이 좋습니다.

회사 내에서 소프트웨어 개발을 잘 하는 개발자가 소프트웨어 전문가라고 생각하지는 마세요. 공을 잘 차는 축구 선수일 뿐입니다.  

프로세스가 창의성을 저해한다고?

개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다. 이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다.

이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다.

그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요?

개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구분 없이 만물박사 식으로 온갖 업무를 처리합니다. 이러다 보면 항상 바쁘고 새로운 기술을 조사한다거나 참신한 생각을 할 틈이 별로 없습니다. 또, 멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서 아이디어를 떠올린 개발자가 북치고 장구치고, 경영층도 설득하고, 프로토타입도 만들어보고 시장 조사도 해보고 해야 합니다. 안 그래도 바쁜 마당에서 짬을 내서 또 새로운 아이디어를 Follow up하기는 정말 어렵습니다. 누가 무슨 일을 얼마나 하고 있는지 잘 파악이 안되므로 또 이런 일을 벌여서 괜히 성과도 없이 평가만 안 좋아 질까봐 포기하기 십상입니다. 또 아이디어 낸 사람이 총대를 매야 하기 때문에 그렇다고 기존의 업무가 줄어들지 않기 때문에 공식적으로 이런 활동을 안하려고 합니다.

하지만, 개발 프로세스를 잘 갖추고 있는 회사는 아이디어를 내기만 하면 일단 회사의 System이 이를 Follow up합니다. 일단 아이디어는 수면 위로 떠올라서 여러 사람과의 Review를 통해서 더욱 Refine되고 정식 절차를 통해서 Prototype을 만들고 마케터는 시장 조사를 하고 영업은 고객들의 의견을 수집해 옵니다. 관리자는 해당 개발자가 아이디어를 발전시킬 수 있도록 정식으로 업무를 할당해서 시간을 빼줍니다. 한마디로 개발자는 기술적인 것만 Follow up해도 됩니다. 물론 모든 아이디어가 제품화 되는 것은 아니지만, 이런 아이디어들이 10개 100개 모여서 성공하는 제품이 나옵니다.

결국 프로세스가 창의성을 저해한다는 생각은 무지의 산물이거나 잘못된 경험의 결과입니다.

문제는 회사의 몸에 딱 맞는 개발프로세스를 갖추는 것이 어렵다는 것입니다. 현재 개발을 어떻게 하고 있는지 조사를 해보면 제각각 일겁니다. 이것부터 통일해 나가면서 조금씩 바꿔가는 것이 스스로 해볼 수 있는 최선의 방법입니다.

SW를 을로 취급하는 하드웨어의 무지

필자는 펌웨어를 개발하는 등 하드웨어 팀과 같이 일하는 소프트웨어 개발자를 자주 만난다. 그런데 많은 개발자들이 하드웨어 팀과 일하기 힘들다고 하소연한다. 

회사에서 하드웨어에 더 집중하고 투자하며 소프트웨어는 보조로 생각한다고 말한다. 그렇지 않은 회사도 있지만 많은 회사들이 하드웨어를 더 중요하게 생각하고 소프트웨어는 하드웨어의 부수적인 역할로 생각하곤 한다. 

'소프트웨어' 하면 흔히 데스크톱 소프트웨어나 게임, 모바일앱을 생각한다. 하지만 이런 순수 소프트웨어, 즉 하드웨어에 종속적이지 않은 소프트웨어 비중은 일반인이 생각하는 것만큼 크지 않다. 반대로 하드웨어와 밀접한 관련이 있는 소프트웨어 비중은 의외로 크다.

자동차의 예를 들면 현재 최고급 차량의 생산 원가에서 소프트웨어가 차지하는 비중은 50%에 육박하고 있다. 그리고 2020년이 되면 고가 차량을 넘어 전체 자동차 생산 원가에서 소프트웨어 비중이 50%가 될 것이란 전망도 있다.

과거에 하드웨어로 수행하던 기능이 점점 소프트웨어로 대체되고 있고 그러면서 과거에는 불가능했던 기능이 실현 가능해져서 하드웨어 발전에도 큰 도움이 되고 있다. 

이런 소프트웨어를 펌웨어, 임베디드 소프트웨어라고 한다. 하드웨어와 간접적으로 관련 있는 소프트웨어까지 합치면 그 비율은 어마어마하다. 

이렇게 하드웨어에서도 소프트웨어 비중이 점점 증가하고 있고 하드웨어 자체 성능에도 소프트웨어가 많은 기여를 하고 있는데 이를 다른 측면으로 보면 조만간 하드웨어 경쟁력도 소프트웨어 역량이 좌지우지 하게 될 것이라는 얘기다. 그렇게 될 날이 몇년 남지 않았다. 

즉, 간단하게 얘기해서 앞으로는 소프트웨어를 잘해야 자동차도 잘 만들 수 있다는 얘기다. 

우리나라는 선진국보다 늦게 산업화되었지만 몇몇 분야에서 선진국을 따라잡았거나 앞질렀다. 자동차, 반도체, 선박, 휴대전화, 가전, 디스플레이, 플랜트 등이 그것이다. 하지만 소프트웨어 분야는 소프트웨어 선진국과 비교하여 아직 멀었다고 많은 사람들이 평가하고 있다. 그런데 이제 몇 년 후가 되면 소프트웨어 역량이 하드웨어 경쟁력을 판가름한다니 발등에 떨어진 불이 아닐 수 없다. 

우리나라는 임베디드 소프트웨어 분야에선 선진국에 더욱 뒤졌다.  이런 상황이 지속되면 그나마 따라잡고 앞지른 분야까지 내놔야 할 상황이 될 것이다. 

실제 성공한 하드웨어 중심인 회사에서 소프트웨어를 개발하는 방식을 보면 문제가 많다. 하드웨어 개발팀이 우위를 가지고 소프트웨어 팀은 시키는 대로 개발하는 방식인 경우가 많은데 그런 사례를 한번 살펴보자. 

A사는 하드웨어가 이미 설계된 상태에서 소프트웨어는 거기에 맞춰서 개발해야 한다. 

소프트웨어 개발팀 관점으로 봤을 때 하드웨어 설계에 문제가 있어도 소프트웨어가 우회 방법을 찾든지 해서 재주껏 해결해야 한다. 하드웨어 설계에 소프트웨어 개발자가 제대로 참여를 못해 이런 비효율적인 상황이 벌어진다. 그러나 A사는 하드웨어는 변경이 어렵지만 소프트웨어는 얼마든지 마음대로 변경할 수 있으니 소프트웨어를 하드웨어에 맞춰 개발하고 문제를 해결해야 한다고 한다. 

버그가 발견되면 무조건 소프트웨어 개발팀에서 문제의 원인을 찾아야 하고 하드웨어 문제도 소프트웨어 개발팀에서 해결해야 한다. 그러다보니 문제가 발생하면 욕은 소프트웨어 개발자들이 먹는다. 

기획 단계부터 소프트웨어 개발팀의 의견을 들을 기회조차 없다. 서로 다른 생각을 가진 사람들의 의견이 잘 모아질 때 창의적인 아이디어가 나오는데 하드웨어 중심적인 개발에서는 획기적이고 창의적인 아이디어가 나오지도 않는다.

B사는 모든 개발 일정이 하드웨어에 맞춰져 있다. 하드웨어 개발팀은 소프트웨어 개발팀과 개발 일정을 논의하지도 않는다. 이미 단계 별로 하드웨어 개발 및 양산 일정이 정해져 있으니 소프트웨어는 각 단계 별로 어떤 것은 1주일 어떤 단계에선 3주 안에 하드웨어에 필요한 소프트웨어를 무조건 만들어내야 한다. 

소프트웨어 개발팀은 인터페이스를 맞추거나 에뮬레이터를 통해서 미리 개발을 하고 싶지만 미리 정보를 제공 받지 못해 하드웨어 일정에 맞추느라고 항상 야근에 시달린다. 하드웨어 부서 일정이 바뀌면 소프트웨어 개발 일정도 틀어져서 일정을 조율하기가 매우 어렵다. 

C사는 소프트웨어 개발 프로세스도 하드웨어 개발 프로세스에 맞춰져 있다. 

과거에는 하드웨어를 개발할 때 한 두명의 개발자가 밤세워가며 펌웨어를 만들어주는 방식이었다. 하지만 지금은 소프트웨어 개발자가 엄청나게 늘었다. 그런데도 하드웨어 개발 프로세스에 소프트웨어를 끼워 넣는 방식은 그대로다. 

하드웨어 개발 프로세스에는 있지만 소프트웨어에는 없는 것도 있고 물론 그 반대도 있다. 소프트웨어는 알파, 베타 단계가 있지만 하드웨어는 그렇게 고쳐 나가지 않는다. 하드웨어 개발 프로세스에 억지로 소프트웨어 개발을 끼워 맞추다 보니 매우 비효율적으로 되어 있다. 용어들도 상이해서 이해하기 어렵다. 

지금은 소프트웨어 개발자들도 적응해서 프로세스를 따르고 있지만 여전히 문제가 많은 프로세스임은 명백하다. 

D사의 경우 소프트웨어 기술 책임자가 하드웨어 출신이다. 

이같은 상황은 업계에 안고 있는 가장 큰 문제이기도 하다. 소프트웨어 분야는  전문가가 아니면 정말 이해하기 어렵다. 콜라를 팔던 경영자가 TV 파는 회사의 경영자가 될 수는 있다. 하지만 비즈니스를 아무리 잘 하던 사람도 소프트웨어 조직의 기술 책임자가 될 수는 없다. 불가능하다. 

그런데 많은 회사들의 소프트웨어 부문 CTO(Chief Technical Officer)가 소프트웨어 전문가가 아니거나 CTO가 아예 없는 경우도 많다. 하드웨어 출신이 소프트웨어를 맡기도 하고 소프트웨어 출신이라고 해도 중간에 관리자로 넘어가서 이제는 소프트웨어 엔지니어가 아닌 사람이 CTO를 맡기도 한다. 

경영자에게 불도저 같은 추진력을 요구하는 회사에서 소프트웨어 전문가인 경영자들은 추진력이 부족한 것처럼 보여 많이 밀려 났고 이제는 소프트웨어 조직도 전혀 다른 분야 출신의 불도저 같은 사람이 맡는 경우도 많다. 

그런 경영자들이 추진하는 정책이라고는 고작 끊임없는 야근이다. 단기적인 성과는 날 수 있지만 아키텍처는 엉망이고 개발자들은 지치고 개발 문화는 엉망이 되었다. 소프트웨어는 소프트웨어 전문가가 맡아야 한다. 

기적적인 하드웨어에서의 성공을 회상하며 소프트웨어도 거기에 끼워 맞추려고 하면 큰 착오다. 하드웨어에서 성공했다고 그 방식으로 소프트웨어를 조금만 더 잘하면 될 것 같은 착각에 빠지기도 한다. 소프트웨어는 스타트업을 제외하고는 한두명의 천재가 밤을 세워서 잘 할 수 있는 분야가 아니다. 소프트웨어가 하드웨어의 부속이라는 생각에서 벗어나야 한다. 오히려 소프트웨어가 중심이 되는 시대가 오고 있다. 

그나마 그 동안 이룩했던 우위를 잃지 않으려면 소프트웨어가 '을'의 자리에서 벗어나 하드웨어와 동등한 관계가 만들어져야 한다.

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

CMMI는 회사를 망칠 수도 있다

필자는 최근 소프트웨어와 시스템 공학 역량의 성숙도를 평가하는 CMMI(Capability Maturity Model Integration)를 적용하여 오히려 어려워진 H사 직원 S씨를 만났다. 

그동안 SI회사 등 여러 곳에서 CMMI를 적용하였던 회사의 직원들을 많이 만나봤지만 SI회사도 아닌 이 회사의 사례는 독특해 칼럼에서 소개할까 한다. 

CMMI를 폄훼하려는 의도가 있는 것은 전혀 아니니 오해는 하지 말아주기 바란다. CMMI에 대한 오해와 서투른 기대를 경계하자는 것이다. 이는 CMMI 뿐만 아니라 수많은 방법론에도 똑같이 해당한다. 

H사는 최근 촉망받는 분야의 서비스를 하는 회사다. 직원이 100명 가까이 되는 작지 않는 회사지만 개발에 관련된 변변한 문서가 하나도 없다. 스펙, 설계서 뿐만 아니라 문서는 전무하다 시피하다. 개발 프로세스라고 할 만한 것도 없다보니, 주먹구구식으로 개발을 하고 있었다. 

고참 개발자라고 하는 사람들도 코딩만 꽤 할 줄 알았지 개발 프로세스가 뭔지도 모르고 협업에는 별로 관심도 없는 상태였다고 한다. 

이에 H사 대표는 이대로는 안되겠으니 컨설팅을 받아봐야겠다고 생각 했다. 그래서 선택한 컨설팅 회사가 CMMI를 전문적으로 컨설팅하는 국내 회사인 P사였다. 

P사는 CMMI 레벨3를 적용하자고 제안했고 직원들은 회사 내부에서 관련 교육을 받았다. 외부에 나가서도 수차례 교육을 받았다. P사는 회사의 기존 프로세스와 그나마 있었던 문서를 분석해서 CMMI 레벨3 기준으로 개발 프로세스를 만들고 수십가지의 문서 탬플릿을 만들어서 제안했다. 

실제 프로젝트에 이 프로세스와 문서 탬플릿을 적용하기 시작했는데 교육을 받기는 했지만 요구하는 수많은 문서를 만들어내기는 보통 어려운 일이 아니었다. 또 촉박한 프로젝트 일정에 문서까지 추가로 만드는 것은 죽을 맛이었다고 한다. 이에 개발자 및 사업부에서는 반발이 매우 심했고, CMMI를 적용하느라 몇개 프로젝트는 포기를 해야 하는 상황까지 발생했다고 한다. 

이런 상황에서 개발자들이 선택한 방법은 어처구니는 없는 것이었다. 문서에 적어야 하는 기능의 개수를 줄이기 시작한 것이다. 

기능하나에 서로 연결해서 작성해야 하는 문서가 많아서 전체 문서 양이 매우 많았다. 예를 들어 실제로는 500개 기능인 프로젝트에서 문서에는 100개만 적으면 문서 개수가 많아도 전체 작성해야 하는 문서의 양은 줄어들게 된다. 그렇게 해서 요구하는 문서와 프로세스를 따랐다고 한다. 정해진 일정에 요구하는 문서를 만들어 내려면 어쩔 수 없다고 한다. 

CMMI를 적용한 프로젝트에 참여했던 S씨는 해당 프로젝트에서 20여가지 문서를 만들었지만 실제 프로젝트에 쓰인것은 SRS와 WBS 문서 2개 밖에 없다고 했다. 나머지 20여가지 문서는 컨설팅 회사에서 요구하기 때문에 만들었을 뿐이라고 한다. 프로젝트 중간이나 프로젝트가 끝난 후에도 나머지 문서들은 볼일이 없을 것이라고 한다. 

H사는 그 뒤로 개발역량 향상은 커녕 CMMI의 직접적인 영향을 아니겠지만 매우 어려운 상태에 놓이게 되었다. 

이론적으로 CMMI를 통해 SW공학의 성숙도를 측정하고 역량을 향상할 수 있다. 하지만 오해와 잘못된 적용 방식이 국내에서는 큰 문제가 되고 있다. 역량 수준이 한참 못미치는데 억지로 요구하는 수준에 맞추기 위해서 문서를 만들어내고 프로세스를 따르는 것이다. 그렇게 해서는 역량이 향상될리 없다. 이런 일이 빈번하여 한국이 블랙리스트에 올랐다는 소문도 파다하다. 

CMMI가 필요한 분야도 있다. 대표적인 분야가 국방일 것이다. 국방 프로젝트는 1달러짜리 나사를 사기 위해서 프로세스와 문서를 적용하여 50달러를 투입해야 할 때도 있는 프로젝트다. 민간 프로젝트와는 성격이 다른 중요도가 있는 프로젝트이다. 

그 외에도 CMMI 인증이 필요한 프로젝트가 있다. 역량이 안되더라도 비즈니스 목적으로 CMMI를 적용하는 것은 그럴 수도 있다고 생각한다. 개발에는 별로 도움이 안되고 영업에는 도움이 될 것이다. 

하지만 순수하게 소프트웨어 개발 역량을 높이기 위해서 단기간에 CMMI를 적용하는 것은 별로 좋은 방법이 아니다. 실전적인 방법으로 내실을 다지는 것이 더 낫다. 

적당할 예 일지는 모르겠지만 타이거 우즈가 CMMI 레벨5 수준으로 골프를 친다고 가정하자. 타이거 우즈는 CMMI 레벨5로 골프를 치기 위해서 골프 스윙시 25가지의 절차와 고려사항을 눈깜짝할 사이에 적용해서 공을 친다. CMMI 레벨5에서는 그 25가지의 절차를 잘 분석해 놨다. 

나는 주말골퍼인데 코치가 그 25가지 절차를 따르면 타이거우즈처럼 골프를 칠수 있다고 한다. 1년을 그렇게 연습한다고 타이거 우즈처럼 골프를 칠 수 있을까? 타이거 우즈는 이미 성숙도가 높고 몸에 완전히 베어 있어서 25가지의 절차를 아무렇지도 않게 수행할 수 있지만 나는 그렇게 할 수가 없다. 

그것을 따라하다가는 오히려 골프를 더 못치게 된다. 현재 상황에서 필요한 것을 하나씩 배우는 것이 훨씬 낫다. 또한 대부분의 실용적인 소프트웨어 개발 현장에서는 그 수준까지는 필요하지도 않다. 

사대주의도 아니고 바다건너의 멋진 모델에 현혹되는 사례가 유난히 우리나라에는 많은 것 같다. 실리콘밸리에서 오래 개발한 개발자들에게 물어봐도 CMMI는 관심도 없고 주변에 적용한 회사는 본적도 없다고 한다. 그만큼 실전적이고 실용주의적인 개발을 지향하는 곳이라면 성숙된 개발 문화와 개발 본연의 역량 향상에 힘을 쓴다. 뛰어난 아키텍트 발굴도 그 일환이다. 

이는 비단 CMMI만의 이야기가 아니다. 수많은 방법론도 마찬가지다. 그자체로는 훌륭할지는 몰라도 적절한 곳에 적용을 해야 하며 우리 회사에서 필요한 것인지는 잘 생각해봐야 한다. 

필자는 좀더 효율적으로 개발을 하기 위해서는 성숙된 개발문화를 정착하기 위해 노력해야 한다고 생각한다. 실용적이고 실전적이지 않은 모든 절차와 프로세스는 짐이 될 뿐이다.

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

7명이 할 수 있는 일을 70명이 하고 있는 이유

최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다.

비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다.

Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서 믿을 수 없는 속도로 해결을 해나가기 시작했고, 미국 본사는 이런 경이로운 결과를 보고는 한국식 개발을 묵인할 수 밖에 없었다.

그뒤 몇 년이 지난 지금은 어떻게 되었을까? 미국 본사의 개발 프로세스를 착실히 따른 호주 지사와 엄청난 차이를 보이고 있다고 한다. 똑같은 일을 호주 지사에서는 7명이 처리를 하고 있고 한국 지사에서는 70명이 야근까지 해야 간신히 처리를 하고 있다고 한다. 

그렇게 된 이유가 분석/설계도 없이 빨리빨리 개발을 하다보니 아키텍처가 엉망이고 개발자들이 많이 바뀌었는데 내용을 아는 사람도 별로 없다고 한다. 뭐 하나 고치려고 해도 보통 어려운 것이 아니라고 한다.

전해 들은 얘기라서 과장이 있다고 해도 문제가 심각하고 이미 많이 망쳐 놓은 것은 사실이다.

글로벌 소프트웨어 회사라고 하더라도 한국에 와서 착각하는 것들이 있다. 놀라운 속도를 보여주는 한국식 개발방식을 신기해 하지만 그 문제점을 피부로 심각하게 알지 못한다.  스펙도 제대로 작성하지 않고 분석/설계/구현을 섞어서 빠르게 개발하는 것이 신기해 하지만 얼마나 큰 문제가 있는지 실리콘밸리 회사들도 잘 모른다. 그런 식으로 개발해 본적이 없기 때문이다.

그렇다고 글로벌 소프트웨어 회사가 본사의 개발 프로세스를 강제화 한다고 잘 적용되는 것은 아니다. 한국에서 잔뼈가 굵은 개발자들은 몸에 밴 개발 방식 때문에 적응하기가 매우 어렵다. 차라리 신입사원들을 뽑아서 교육시키면서 개발을 하는 것이 더 빠를지도 모른다.

이는 한국의 소프트웨어 회사 내부에서도 그대로 적용된다. 글로벌 소프트웨어 회사의 개발 프로세스가 아무리 좋다고 하더라도 한국의 소프트웨어 회사에는 바로 적용이 안된다. 대부분은 무리한 시도이고 실패한다.

변화를 감당할 수 있을만큼씩 조금씩 바꿔나가야 한다.