Balanced shipping is a feature

조엘 온 소프트웨어의 블로그에는 The Duct Tape Programmer라는 제목으로 쓴 글에서 "shipping is a feature"라는 내용이 나온다. Duct Tape은 짐을 쌀때 주로 사용되는 강력한 테이프로 한번 물건을 접착시키면 완전히 고정시키는 테이프이다. Duct Tape 프로그래머는 이와 같이 특정 기능을 구현할 때 실질적으로 필요한 내용만을 빠르고 정확하게 구현하는 사람을 말한다. 즉, overengineering과 같은 불필요한 작업을 최소화시키고, 현실적으로 사용자에게 필요한 기능만을 제한 기간 내에 구현하는 사람을 뜻한다.

Day 121 :: i will no longer censor myself for the sake of your comfort by Meredith_Farmer

 
사용자 입장에서는 사용하는데 필요한 기능을 제때에 인도받으면 되기 때문에 미래 시점에 필요할지도 모르는 정의되지 않은 비즈니스를 고민하면서 어떻게 더 확장성 있거나 유연한 설계를 통해 구현할지를 이리 저리 고민하다가 정작 필요한 중요한 기능의 지연으로 전반적인 프로젝트의 기간을 넘어서서 결국 이도 저도 아닌 어정쩡한 기능을 탑재한 SW를 만든 경험은 한번쯤은 해본 사람은 이러한 이야기가 상당히 공감이 되리라고 생각한다.

때로는 과도하게 확장성이나 유연성 등을 고민하여 설계할 필요도 분명 있다. 하지만, 이러한 고민이 정작 사용자에게는 그리 크게 이점을 주지 못하는 경우도 있다는 것이다. 해당 기능을 너무나도 유연하고 확장성 있게 만들어놓았는데 정작 사용자는 이러한 기능을 한달에 한두번 사용하거나 한가지 경우로만 사용한다고 본다면 내부의 설계가 아무리 훌륭하고 좋다고 하더라도 결국 시간만 허비한 셈이 된 것이다. 물론, 이를 개발했던 사람에게는 자신의 능력을 최대한 활용하고 그로 인해서 얻은 것은 지식으로 체화될 수는 있겠지만, 비용을 제공하는 고객의 측면에서는 슈퍼컴퓨터를 사놓고 워드프로세스만을 사용하는 겪과 다를 바 없을 것이다.

이 블로그의 글은 overengineering에 대한 경각심을 말하고는 있지만, shipping에 있어서 중요한 것은 결국 균형(balance)이다. 필요한 기능들을 적시에 제공하도록 구현을 했다고 하더라도 이들 기능간의 균형을 이루지 못하다면 결국 구현된 SW는 침몰하거나 좌초될 수 밖에 없다.

컨테이너를 선박에 옮겨실을 때에는 무엇보다 균형이 중요하다. 각 컨테이너들이 가지는 속성과 무게, 그리고 각 도착지에서 하적할 순서를 고려해야 한다. 시스템에서는 이러한 컨테이너들이 해당 기능이라고 보면, 사용자의 사용 패턴이나 기능의 우선 순위, 예상 공수/일정 등이 고려되어야 할 것이다.

주요 기능에 대한 구현

시스템을 만드는 가장 근본적인 목적을 먼저 파악을 하는게 우선이며, 이는 핵심 업무를 가장 우선 순위를 매겨서 여기에 초반부터 집중하려는 노력이 있어야 한다. 대부분의 핵심 업무는 전체 개발에 있어서 주요 경로(critical path)에 해당되며, 이를 개발 초반에 다루지 않고 주변 기능만 다룬다면 결국 선박에 가운데를 비어놓고 양쪽에만 컨테이너를 쌓게 되어서 전체적은 균형이 이루지지 않을 수 있다.

주요 기능이 고객이 중요하게 생각하는 기능일 수도 있지만, 기술적으로는 전체적은 뼈대를 이루는 아키텍처일 수도 있다. 때로는 데이터 값에 대한 정의가 될 수도 있고, 엔티티에 대한 설계일 수도 있다. 혹은, 인터페이스 명세에 대한 정의가 될 수도 있으며, 화면에 대한 레이아웃이나 사용자가 사용하는 미디어에 대한 정의일 수도 있다. 어떤 형태가 되든 주요 기능이 완전하지는 않더라도 탑재되어야 그 주변에 부가적으로 쌓을 수 있는 공간에 대해서 고려해볼 수 있다. 만일 주요 기능이 선박에 좌측에 위치한다면 그 균형을 맞추기 위해서 우측에 유사하거나 그에 버금가는 부가 기능들을 탑재시켜야 한다.

예를 들어, 전체 비즈니스를 관통하는 LoB(Line of Business) 상에 있는 어느 주요 기능의 처리를 위해서 이후 프로세스를 진행시키기 위한 부가 기능을 필요로 할 수도 있는데, 이러한 부가 기능은 주요 기능이 구현되기까지 상당한 지연이 발생될 수가 있다. 이후의 프로세스들 역시 이러한 주요 기능의 지연으로 인해서 전혀 진행하지 못하는 경우가 있다. 최소한 그에 상응되는 무게의 임시 컨테이너라도 선적을 해야 이후 선적되는 부가 컨테이너에 대한 선적을 고려해볼 수 있다. 통상 컨테이너는 육로를 통해서 항만에 도착을 해서 이를 배에 선적하게 되는데 육로의 교통상황이 좋지 않아서 주요 컨테이너를 싣지 못하고 대기하는 경우도 있다. 컨테이너를 배에 실을 때까지에는 다양한 경로들이 있고, 경로 상의 여러 장애물들을 해결해야 한다. 마찬가지로 주요 기능에 대한 지연이 발생하지 않도록 발생되는 장애물(이슈)를 최대한 해결하도록 많은 역량을 투입해야 한다. 이는 어느 한두사람에게만 맡겨두어서는 안되면 팀의 가능한 모든 역량을 투입해서 빠른 해결책을 내놓아야 한다.

주요 기능의 탑재를 위해서는 균형잡힌 계획이 필요하며, 이는 시시 때때로 급한 변경을 필요로 한다. 현장에서 그리고, 현실에서의 문제는 늘 예기치 못하게 발생되며 이러한 문제는 계획에 전혀 나타나지 않기 때문이다. 요즘의 SW는 기능이 단순하지도 않고 비즈니스의 복잡도로 인해서 한두 사람의 Duct Tape Programmer가 아닌 Duct Tape Team을 필요로 한다.

빠른 선적을 위한 자동화 

컨테이너 선적에서는 야드(컨테이너를 선적하기 위해 넓은 장소에 쌓아둔 장소)에 있는 컨테이너를 배에 올려서 쌓는 시간을 어떻게 최소화시켜서 단위 시간당 얼마나 배에 싣는지를 성능의 평가로 삼는다. 통상 시간당 40 ~ 50개 정도를 배에 싣게 되면 빠른 성능으로 여기며, 평균적으로 20 ~ 30개의 컨테이너를 싣게 된다. 이러한 선적 시간은 배가 항만에 정착하는 시간이며, 배가 정착하는 시간이 예정된 시간보다 지연되면 이후의 일정도 연착이 되어서 전반적으로 비용이 증가할 수 밖에 없다. 물론, 사전에 선적하는 순서를 계획해서 그 순서대로 배에 선적하는데, 선적을 담당하는 사람에 따라서 다소 성능의 차이가 발생하기도 한다.

마찬가지로, SW에서의 선적은 시스템으로의 빌드 및 배포와도 깊은 관계가 있다. 자그마한 시스템이나 단일 시스템은 빌드나 배포가 그리 복잡하지 않을 수 있으며, 개발 인원이 얼마되지 않아서 그리 심각하게 고민할 필요까지는 없을 수도 있겠지만, 많은 개발 인원과 다양한 시스템이 존재하는 경우에는 통합, 빌드 및 배포에 대한 시간은 상대적으로 크게 증가한다. 즉, 통합, 빌드 및 배포는 최대한 자동화되어 있어야 이러한 시간을 최소화시킬 수 있다. 빌드 및 배포 자동화는 전반적인 SW 아키텍처에도 영향을 미쳐서 이를 위해서 사전에 개발시점에도 적절하게 구획화시키고 통합과 빌드를 위한 준비를 코드 작성과 동시에 수행해야 한다.

잘 포장된 기능이 탑재되어서 사용자의 손에 넘어가기까지의 과정은 시스템이 복잡해질수록 상당한 노력을 요한다. 이 또한 기능이 점점 세분화되고 구체화되면서 통합, 빌드, 배포의 과정이 점점 더 확장/변형될 필요가 있다.

전반적인 기능 탑재에 대한 모니터링

컨테이너가 배에 선적되는 과정은 그 수가 많아질수록 복잡해지며, 선적을 위해 유입되는 컨테이너와 배에 선적되어서 유출되는 컨테이너들의 상태를 모니터링해야 한다. 즉, 야드의 상황을 모니터링해서 컨테이너의 이동 경로를 최적화시켜야 한다.

SW 기능이 탑재되면서 (혹은 초반에 기획/설계되었던 기능이 변형되어 탑재되면서) 이후에 탑재되어야 할 SW 기능의 내용을 변형하거나 아예 삭제 혹은 추가할 필요가 발생한다. 즉, 탑재되는 SW는 서로 연관이 되어 있는 기능들의 묶음들이 있기 때문에 먼저 탑재된 기능이 이후 탑재할 기능에 영향을 미쳐서 서로 모순이 되지 않게 모니터링을 해야 한다.

만일, 이러한 기능을 서로 다른 팀이나 서로 다른 담당자가 SW 개발을 하다가 통합테스트나 오픈이 얼마남지 않은 시점에 발견했다고 하면, 심각한 경우 해당 기능의 충돌로 전반적인 프로젝트 분위기에 악영향을 미치는 경우가 많다. 서로 변경하라고 하지만, 이미 사용한 시간이 남아있는 시간 보다도 현저히 없어서 어느 누구도 양보하기 힘든 상황이 되어버려 결국 SW 탑재된 시스템은 사용자에게 불편을 초래하는 기능을 유발시키기도 한다. 이러한 불편을 어떻게 감쇄시키기 위해서 여러가지 편법과 꼼수를 사용하지만 이는 궁극적으로 시스템에 악영향을 미친다.

초반부터 탑재되는 기능의 모니터링을 하지 않고 있다면, 이러한 모순을 해결할 수 있는 시간이 점점 더 사라지게 되며, 어느 한편으로 치우친 상태로 시스템을 만들게 된다. 결국 통합테스트라는 관점은 이러한 모순을 해결하기 위해서 해당 기능이 탑재될 때마다 수행해야 하면 항상 반복적으로 수행되어야 한다.


SW의 탑재는 궁극적으로 해당 시스템이 제공하는 기능을 의미하며, 이는 전체적인 균형이 이루어진 상태로 관리되어야 한다. 이와 같은 균형을 이룬 탑재는 탑재에 대한 계획과 실행, 그리고 모니터링이 뒷받침되어야 가능하며, 칼로 자르듯이 팀이나 개인별로 할당된 작업을 단순히 진행한다고 해서 이루어지는 것은 아니다. 이는 개인과 팀을 가로질러서 프로젝트 팀 모두의 공감대와 협업을 이루어야 하며, 다소 겹치는 역할을 담당할 수 있어야 한다.