만약 우리가 소프트웨어 개발에서 발생하는 낭비의 근본 원인을 찾는다고 하면, 복잡도가 정말 좋은 후보가 될 것이다. 복잡도는 우리의 코드를 경화시켜서 깨지기 쉽게 만든다. 『Conquering Complexity in Your Business』에서 마이클 조지^{Michael George}는 복잡성이 콜레스테롤과 같다고 이야기한다. 다시 말해서 복잡성이 조직의 동맥을 막히게 하는 “이윤과 성장에 대한 침묵의 살인자”라는 것이다.[^1] 소프트웨어 개발에서 복잡도에 대한 처방은 단순하다. 코드를 더 적게 짜라!

이제 수십만 유로 규모의 유럽 회사가 어떻게 그것을 실행했는지 살펴보자.

자라^zara

마돈나가 최근에 스페인에서 콘서트를 열었는데, 첫 콘서트에서 마돈나가 입었던 의상을 걸친 10대 청중들을 마지막 콘서트에서 발견할 수 있었다. 마돈나가 입은 것과 꼭 같아 보이는 이런 의상은 급격하게 성장하고 있던 패션 의류 업체 체인인 자라^Zara에서 구입한 것이었다. 시장에 새로운 디자인을 내놓는 것보다 고객이 요구하는 패션을 바로바로 만들어내는 것이 더 수익성에 좋다고 생각한 자라의 전략은, 다름 아닌 재빨리 모방하는 것이다. 아주 빠르게 변화하는 패션 업계에서, 재빨리 모방하려면 정말 빨라야 한다. 자라는 컨셉에서 현금까지 단 2주가 소요된다. 심지어 완전히 새로운 종류의 제품이라도 1달이면 충분하다.

스페인 서부에 위치한 연 매출 50억 유로 이상의 의류 회사인 인디텍스^Inditex 그룹의 자회사인 자라는, 인디텍스 매출의 약 70%를 차지하고 있다. 자라는 스톨홀름에 위치한 H&M, 베니스에 위치한 베네통, 샌프란시스코에 위치한 갭^Gap과 치열하게 경쟁하고 있으며, 업계에서 가장 건실한 수익을 공시하는 회사 중 하나이다. 이 글을 쓰고 있는 시점에, 자라는 900개에 육박하는 매장을 가지고 있는데, 그 중의 4분의 3이 유럽에 있으며 그 수가 급격하게 늘어나고 있다.

판매 시즌마다 새로운 제품을 만들기 위해 유명 디자이너를 고용하는 대신, 자라는 디자인 학교의 최고 졸업생들을 선발하고, 매장 관리자들과 일하면서 고객이 원하는 의류를 만들게 하였다. 경쟁사들이 매년 2,000~4,000개의 새로운 아이템을 출시하는데 비해 자라는 매년 11,000개를 출시한다[^2]. 자라의 매장은 재고가 적다. 주문은 매주 2번 본사에 전달되며, 의상은 2~3일 후에 가격표가 붙은 채로 옷걸이에 걸려 바로 팔 수 있는 형태로 도착한다. 자라는 규모의 경제를 거부하고 주로 스페인 서부에 위치한 협동조합의 작은 공장에서 의류를 제조한다. 제작 요청이 최대로 치솟을 때에도 매주 2번의 주문을 소화할 수 있도록, 그들의 생산 능력보다 훨씬 낮은 수준으로 공장을 가동한다.[^3]

자라는 경쟁사와 비교해 보았을 때 노력대비 더 많은 수익을 거둔다. 자라는 제품의 85%를 할인되지 않은 가격에 판매하는데, 업계 평균은 60~70% 수준이 고작이다. 또한 재고가 매출의 10% 정도인 반면 업계 평균은 17~20%에 이른다.[^4] 그리고 자라는 더 적은 비용을 쓴다. 자라의 모기업인 인디텍스는 매출의 0.3%를 광고에 쓰는 반면, 업계에서는 평균적으로 3~4%를 투자한다. 또한 인디텍스가 IT에 약 0.5%를 쓰는데 반해 업계 평균은 2~5%에 이른다.[^5]

여기서 잠깐! 내용을 다시 한번 살펴 보자. 연 매출 50억 유로인 회사가 매출액의 겨우 0.5%만을 IT에 지출한다? 실제로 인디텍스의 IT 부서 인원 50명이 필요한 프로그램을 전부 개발한다. 매장에서는 PDA와 모뎀을 이용하여 매출 총액과 새로운 주문을 본사로 송부한다. 디자이너들은 CRM 시스템 대신 매장 관리자들과 이야기 한다. 재고가 그렇게 적은 상황에서 ERP는 과분한 시스템일 것이다. 재미있게도, 이 최소한의 시스템을 기획한 CEO는 전직 IT 관리자였다.[^6]

『Do You Have Too Much IT?』[^7]에서 앤드류 맥아피^{Andrew McAfee}는 인디텍스의 기술활용 5대 원칙을 나열하였다.

1. IT는 의사결정에 도움을 주는 수단일 뿐 의사결정 자체를 대신할 수 없다. 정보 시스템은 의사결정에 필요한 데이터를 정리하는 것을 도와주지만, 그것이 사람을 대신하여 결정을 내려주지 않을 뿐더러, 의사결정에 대한 제안을 해주지도 못한다.
2. 컴퓨터 처리는 표준화되어 있고 대상이 정해져 있다. 매장과 지점은 회사의 단일 IT 솔루션만 이용해야 하고, 개발자들은 시스템의 기능을 최대화하는 것이 아니라 ‘최소화’해야 한다.
3. 기술 도입은 내부에서부터 시작된다. 사업 목표가 회사의 필요한 기술을 규정하는 것이지, 그 반대는 있을 수 없다. IT 부서는 현장 관리자들과 함께 일하며 그들의 요구를 이해할 수 있도록 노력하고, 그런 뒤에야 비로소 해결안을 찾기 위해 기술들을 들여다 본다.
4. 프로세스에 중점을 둔다. 매장의 PDA는 ‘개인의 생산성을 위한 장치’가 아니라, 일일 매출 보고서와 주 2회 주문하고 발송하는 리듬을 보조하는 장치다. 그들은 모든 매장에서 일관된 프로세스를 따르게 한다.
5. 부문간 제휴가 널리 퍼진다. 이것은 CEO가 한때 IT 관리자였기에 수월했겠지만, 비즈니스와 IT의 제휴는 훨씬 많을 것을 얻게 한다. 사업가와 기술자가 서로의 세계를 진실로 이해하게 됨으로써 서로를 구분하지 않고, 벽을 사이에 두고 소프트웨어를 개발하는 일도 없어지게 된다.

복잡도

한 개의 소프트웨어 제품만 개발하는 거의 모든 신생기업은 민첩하기 때문에, 고객 요구에 신속하게 대응할 수 있고 변화에도 재빨리 적응할 수 있다. 그러나 1, 2년 가량의 성공을 경험한 후에는, 점점 느려지기 시작하고 변화에도 둔감해진다. 결국 복잡한 코드베이스, 복잡한 제품군, 복잡한 조직구조를 만들어 낸다. 이 시점에서 그들이 복잡도를 신속하게 통제하지 못하면, 초창기 회사에 경쟁 우위를 제공하던 그 민첩함을 점차 잃게 될 것이다.

복잡도에 따른 비용은 선형적이 아니라 지수적으로 증가하여, 결국에는 대부분의 소프트웨어 시스템에서 다른 모든 비용을 압도하게 된다(그림 4.1참조). 복잡한 코드는 깨지기 쉽고 안전하게 변경하는 것을 거의 불가능하게 한다. 현명한 소프트웨어 개발 조직은 코드베이스를 단순하고, 깨끗하고, 작게 유지하는 것을 최우선으로 하고 있다.

모든 기능은 명분을 가져야 한다

복잡도를 통제하기 위한 첫 단계는 먼저 코드베이스에 들어가는 기능들을 과감하게 제한하는 것이다. 개발할 모든 기능들은 그 기능이 수명주기 동안 발생시키는 전체 비용보다 더 많은 경제적 가치를 제공한다는 것을 증명해야만 한다. 소프트웨어에 온갖 기능 목록을 탑재하는 것은 게으른 마케팅 방법이다. 즉, 고객이 어떤 것에 가치를 둘지 모르기 때문에, 고객이 좋아할 만한 기능들을 이것저것 쑤셔 넣는 것이다. 하지만 이런 식으로 소프트웨어에 기능을 추가하는 것은 게으른 정도를 넘어 죄악에 가깝다. 이것은 재앙을 일으키는 처방전이다. 소프트웨어는 본질적으로 복잡하기 때문에 만약 복잡도를 주의깊게 관리하지 않는다면, 급속히 통제 불가능한 상태가 되어 버린다.

개발할 기능을 제한하는 것은 용기가 필요하지만 두고두고 보답을 한다. 제품의 관점에서 말하면, 더도 덜도 아닌 딱 필요한 만큼의 기능을 가진 제품을 출시한다는 것은, 그 회사가 고객이 원하는 것이 무엇인지 제대로 이해했다는 것을 입증하는 것이다. 이것은 인튜이트^Intuit社가 QuickBook을 출시할 때 사용한 전략이다. 인튜이트는 소규모 업체들이 회계사가 쓸 정 도의 복잡한 소프트웨어를 원하지 않는다는 것을 간파하고, 경쟁사들이 필수적이라고 생각했던 복식 부기 기능마저도 포함하지 않은 제품을 개발했다. 인튜이트는 그들의 고객이 누구이며, 무엇을 하려 하는지를 잘 이해했고, 그래서 고객이 찾고있던 기능만 제공했던 것이다.

페이션트키퍼^{PatientKeeper} 社의 CTO 제프 서더랜드^{Jeff Sutherland}는, 잘 정의된 시장 요구가 있을 때까지 개발자들은 어떤 기능도 구현해서는 안된다는 것을 강조한다. 그는 다음과 같이 말했다.

이제 할 일은 고객의 요구를 더 잘 만족할 수 있도록 코드베이스를 다듬는 것입니다. 코드베이스가 깨끗하지 않다면, 단 한 줄의 코드라도 작성해서는 안됩니다. 코드 한 줄 작성할 때마다 비용이 들고, 유지보수에는 더 많은 비용이 들기 마련입니다. 개발자들이 필요하지도 않는 코드를 작성하는 것보다는, 차라리 인터넷 서핑을 하는 편이 낫습니다. 사용되지도 않을 코드를 작성하게 되면 시스템이 살아있는 동안 비용을 지불하게 됩니다. 그 기간은 일반적으로 제 경력보다도 깁니다. 차라리 인터넷 서핑을 한다면 개발자들은 재미 있는 시간을 보내서 좋고, 저는 덜 비싼 시스템을 갖게 되어 유지보수에 신경을 덜 쓸 수 있어 좋습니다.[^8]

최소한의 유용한 기능집합

고객 주문 소프트웨어를 개발하거나 일반적인 제품 소프트웨어를 개발하거나, 이상적인 방법은 소프트웨어를 ‘최소한의 유용한 기능집합’ 단위로 나누고, 한 번에 하나씩 우선순위가 제일 높거나 자금 회수가 가장 빠른 것부터 구현하는 것이다. 최소한의 유용한 기능집합이란 고객의 작업 중 유용한 작업을 더 잘 할 수 있도록 해주는 기능집합을 말한다. 소프트웨어의 모든 기능을 전부 구현하지 않으면 안 되는 상황도 있겠지만, 기술적으로나 고객의 업무 관점으로나 그런 경우는 거의 없다.[^9] 우리는 그동안 좋은 소프트웨어 개발을 위해 대규모 일괄처리나, 모 아니면 도 식의 접근 방법^{all-or-nothing approach}이 좋은 것이라고 훈련받아 왔다. 이제 이러한 방법이 좋은 소프트웨어 개발에 있어서 최악의 방법이라는 사실을 재인식해야 할 때다.

커스텀 소프트웨어 개발 프로젝트에서는, 작고 유용한 기능집합을 배포하면 고객이 훨씬 빨리 소프트웨어 활용을 시작할 수 있다. 이러한 기능집합이 조기에 투자수익ROI을 발생하기 시작하면, 회사는 적은 돈을 투자하면서도 빨리 투자 금액을 회수할 수 있어서 시스템의 수명주기 동안 더 많은 수익을 낼 수 있다. 기술적인 측면에서 최소한의 유용한 기능집합을 구현하는 것은, 실용적일 뿐만 아니라 올바르게 실행하면 새로운 기능집합이 더해질 때마다, 코드 구조를 개선하고 단순화시킬 수 있다. 이것은 코드베이스의 복잡도는 물론 수명주기 동안의 비용을 최소화한다. 고객의 입장에서 유용한 최소 기능집합을 전달받는 것은, 일을 더 빨리 수행할 수 있고 변경을 요청할 수 있는 시간을 충분히 가지면서, ‘정말로’ 소프트웨어가 어떻게 동작하기를 바라는지 알 수 있게 된다는데 큰 의미가 있다. 그리고 지속 가능성 관점에서 보면, 수명주기 동안 시스템을 점진적으로 확장할 수 있기 때문에, 최소한의 유용한 기능집합 단위로 점진적 구현이 되는 시스템은 유지보수 하기가 더 쉽다. 최소한의 유용한 기능집합으로 소프트웨어를 구현하지 않을 이유가 없는 것이다.

복잡한 것을 자동화하지 마라

만약 우리가 복잡하고 다루기 힘든 프로세스를 단지 자동화하기만 한다면, 그것은 고객을 돕는 것이 아니다. 그것은 낭비로 가득 찬 프로세스를 우겨넣어, 소프트웨어의 복잡도를 높이는 결과를 초래할 뿐이다. 어떠한 프로세스도 자동화하기 전에는, 반드시 해당 프로세스를 명확하고 단순하게 만드는 작업을 해야 한다. 경우에 따라 기존에 자동화된 것을 제거할 수도 있다. 그러고 나서야 비로소 프로세스에 대한 명확한 이해를 바탕으로, 효과적으로 자동화하기 위한 핵심 포인트가 무엇인지 식별해 낼 수 있다.

Story “저희 회사는 복잡 투성이예요!”

최근의 세미나에서 어떤 가치흐름도(이 장의 후반에 설명됨)가 소프트웨어 개발 프로세스가 아닌, 소프트웨어 주문 프로세스를 기술하고 있었다. 그 그림을 분석해보니, 힘겹게 거친 고객 승인 절차 이후에도 모든 주문의 약 절반 정도가 수정되는 것을 알 수 있었다. 오류를 저지르기 쉬운 프로세스에 의해 발생되는 지연과 변경은, 고객을 불행하게 하고 납기를 지연시 키고 있었다.

“왜 이런 문제를 더 일찍 찾아보지 않죠? 왜 그렇게 오래 기다리나요?” 나는 물었다.

“많은 이유가 있습니다.” 그 가치흐름도를 발표하던 사람이 설명했다. “주로 그 문제들은 시간과 관련이 있어요. 주문이 접수되었을 때에는 문제가 없었지만, 시간이 지나면 계약이 만료되어 가격이나 계약 조항이 바뀌거든요.”

더 깊이 들여다보니, 주문을 처리하는 그룹은 주문이 무효화되지 않도록 엄청난 노력을 쏟고 있었지만, 가격 구조가 너무 복잡하여 곤경에 빠져 있음을 알 수 있었다.

“아마도 당신 회사의 가격 구조를 살펴봐야 겠네요.” 나는 제안했다. “제가 보기엔 너무 복잡합니다.”

“맞아요! 저희 회사는 복잡 투성이예요!” 즉각적인 대답이 왔다.

“최근에 가격 구조를 개정했는데, 그 목적이 구조를 단순화시키는 것이 아니었어요. 모든 고객으로부터 벌어들이는 수익을 최적화하는 것이 목적이었거든요.”

나는 가치흐름도에 나타난 모든 문제를 종합해 볼 때, 그렇게 벌어들인 추가 수익은 그 복잡도로 인해 몇 배의 손실을 가져올 것이라고 지적했다.

“그 뿐만이 아니예요” 어떤 사람이 내 말에 동의하면서 설명을 덧붙였다. “그 새로운 가격 구조는 아무도 좋아하지 않는 타협안입니다. 어떤 고객도, 주문처리 그룹도, 심지어 판매 부서조차 말이죠.”

주문 처리 문제는 그 자체로 엄청나게 크고 두드러져 있었음에도 불구하고 그 때까지 아무도 복잡도가 나쁜 것이라는 교육을 받지 않았기 때문에, 그 문제의 근본 원인까지 추적한 사람이 없었다. 사실 그 회사가 당시에 고려하고 있던 해결책은, 복잡도를 처리할 컴퓨터 시스템을 구축하는 것이었다.

나는 그 프로세스에 필요한 것이 자동화가 아니라 단순화라고 제안했다. 그것도 당장 필요해 보였다. 만약 그들이 현재의 복잡한 프로세스를 있는 그대로 자동화한다면, 오히려 그 복잡한 프로세스를 콘크리트 주물에 넣어 더 견고하게 만드는 셈이 된다. 따라서 단순화 과정을 생략하고 컴퓨터 시스템을 도입한다면, 주문 프로세스를 단순화할 기회를 영영 잃어버릴지도 모른다.

-- 메리 이야기

[^1]: Michael George and Stephen Wilson, 『Conquering Complexity in Your Business: How Wal-Mart, Toyota, and Other Top Companies Are Breaking Through the Ceiling on Profits and Growth』, McGraw-Hill, 2004. [^2]: 자료는 The Economist 誌, 2005년 6월 18일자에 실린 "Inditex: The Future of Fast Fashion" 를 참조함. [^3]: Kasra Ferdow, Michael A. Lewis, Jose A.D. Machuca, 『Rapid-Fire Fulfillment』, Harvard Business Review, November 2004. [^4]: 3)번 각주와 동일한 문헌 [^5]: Andrew McAfee, 『Do You Have Too Much IT?』, MIT-Sloan Management Review, Spring 2004. [^6]: 5)번 각주 문헌과 동일함 [^7]: 5)번 각주 문헌과 동일함 [^8]: 2003년 3월 11일, object-technology@yahoogroups.com 에 게시된 121번 글을 허가 받아 인용함. [^9]: 게임은 두드러진 예외 케이스다.