실리콘밸리를 그리다 팀이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다
19세기 산업혁명 이후로 제품 생산의 표준으로 자리 잡은 워터폴(Waterfall) 방식의 공정은 자동차, 선박 등등 기존 굴뚝 산업에 최적화된 생산 방식으로, 선형적인 작업 순서와 분업으로 시간과 비용의 효율성을 추구하는 것이 관건이다. 고정된 요구사항에 맞추기 위해 적절한 시간과 돈을 투입하여 프로젝트를 진행한다.
반면 소프트웨어를 개발하는 스타트업들이 이러한 Waterfall 방식으로 개발을 진행하기에는 우선 시간과 돈이 촉박하고, 낮은 진입 장벽으로 인한 공급 과잉으로 시장의 변화가 너무 빠르다. 즉 시간과 돈에 제한이 명확하다. 그래서 일단 소프트웨어가 어느 정도 사용할만하다 싶으면 빠르게 출시한 다음에 사용자들의 의견과 통계를 수집해서 이를 바탕으로 업데이트를 배포하고 이 과정을 반복하는 순환식 개발 방식인 애자일(Agile) 이 널리 정착하게 되었다. 워터폴 방식과 반대로 적은 돈과 시간에 맞추기 위해 요구사항을 끊임없이 수정하는 방식이다.
Waterfall
한국항공우주산업(구:삼성항공)에서 미국 록히드마틴사와 공동 설계한 T-50은 오랜 기간의 설계와 시제품 테스트를 거쳐 2005년 최초 양산에 들어갔다. 탐색 개발 기간을 제외하더라도 1997년에 시작된 체계개발로부터 8년이 지난 시점에서야 양산이 가능해진 것이다. 최고 속도, 작전 거리, 최고 운용 고도, 회전 반경 등의 주요 요구사항 외에도 각 온도와 고도에 따른 엔진 스타트업 시간, 엔진이 꺼진 후에도 비상 운용을 통해 가까운 활주로에 착륙이 가능할 것, 각 부품은 전자파 교란을 받지 않을 것, 등의 세세한 요구사항까지 모두 만족하게 하는 설계를 마치고 시제품의 초도비행에 들어가는 데에만 4년 이상이 걸렸다.
이와 같은 큰 프로젝트를 진행할 때에 우리는 다음과 같은 Waterfall 모델을 사용한다.
1. Requirements: 요구사항을 분석하고 타당성을 검토한다.
2. Design: 요구사항을 만족하게 할 수 있는 제품을 설계한다.
3. Implementation: 시뮬레이션과 mock-up test, 각종 부품의 테스트를 거쳐 시제품을 만든다.
4. Verification: 시제품의 시험과 재설계를 반복하여 설계가 완성된다.
5. Maintenance: 제품을 대량 생산할 수 있는 공장을 짓고 제품의 유지관리(Maintenance)를 도울 수 있는 서비스 체계를 완성한다.
산업 시스템을 정보화하는 과정에서 우리는 이와 같은 모델을 빌려서 사용했다. 소프트웨어 개발에도 설계가 필요하고 검증이 필요하며 완성된 제품을 운용하는 과정에서 유지관리를 위한 팀이 따로 배정된다. 소프트웨어를 개발하는 과정이 전투기나 전자제품을 만드는 과정과 크게 다를 이유는 없다. 고객이 원하는 것이 있고, 누군가 그것을 만들어가는 과정은 비슷하다.
이 모델의 장점은 고객이 원한 제품을 인도(Delivery)하는 시점이 명확하다는 데 있다. 기능/품질/운영관리에 관한 요구조건이 분명하므로 가능한 일이다. 어떤 자료를 입력하면 어떤 동작을 하는지와 같은 기능 요구조건이나 최대 몇 명의 동시 사용자가 접속할 수 있어야 한다는 등의 운영 요구조건에 관한 내용은 비교적 분명하다.
Waterfall과 시장의 변화
시작과 끝이 분명한 순수한 의미의 Waterfall에는 지속적인 변화의 요소가 없다. 즉, 순수한 의미의 Waterfall에는 요구사항이나 시장의 변화에 적응하는 메커니즘이 존재하지 않는다.
제품의 품질을 시장의 요구에 따라 지속해서 개선하는 것이 생산과정 일부가 되어야 한다는 것은 소프트웨어의 문제를 풀기 훨씬 이전부터 존재한 개념이다. 1920년대 Bell Telephone Laboratories에서 체계적으로 품질을 개선하기 위한 학문적 접근을 시도한 Walter Shewhart와 Edward Deming을 시작으로, 일본은 1950년대에 그 지속적 품질개선(Continuous Improvement)의 아이디어를 산업 전반에 걸쳐 받아들여 일본산 제품에 대한 세계인의 인식을 바꾸었다. 1970년에는 TQM(Total Quality Management)이, 1990년대에는 Six Sigma가 산업계를 휩쓸었다.
소프트웨어 개발 프로젝트를 관리하는 데 대해서는 품질관리를 위한 ISO 9001, 프로세스 관리를 위한 CMMI-DEV, 그밖에 프로젝트 관리를 위한 PMP라는 자격증까지 생겼다. 이와 같은 규격(standard)들을 만족하게 하는 시스템을 갖춘 회사들은 고객이 원하는 제품을 원하는 시간에 만족스러운 품질로 만들 수 있는 능력이 있다고 받아들여졌고, 회사들은 성숙한 프로세스를 갖추기 위해 힘을 기울여왔다.
이와 같은 노력의 공통분모를 찾아보면 ‘지속적인 개선`이라는 말이 그 중심에 있는 것을 찾을 수 있다. Continuous Improvement 뒤에는 자주 Cycle이라는 단어가 붙는다.
Waterfall 방식과 지속적인 개선을 접목한 방식. 제품을 큰 버전으로 나누어 완성과 개선을 반복한다.
하지만 높은 품질의 제품을 고객에게 인도했더라도, 기능을 변경하거나 새로운 기능을 추가할 때마다 높은 품질을 유지하는 것은 쉬운 일이 아니어서, 복잡한 승인 절차를 요구했고 시간이 지날수록 고객이 만족하는 제품을 얻기 위한 비용이 높아지는 경향을 보였다.
Agile
애자일(Agile)로 대표되는 점진적 개발 방법은 2001년에 와서야 애자일 선언문(Manifesto for Agile Software Development)이 발표되면서 제대로 모습을 갖추기 시작했다. 실제로 회사들에서 Scrum과 같은 Agile 프로세스가 널리 쓰이기 시작한 것은 개인적인 경험에 의하면 2005년 정도였던 것 같고 Kanban은 그리고도 몇 년 후의 일인 것 같다.
애자일 선언문
우리는 스스로 행하고 다른 이들도 이를 행할 수 있도록 도움을 줌으로써 소프트웨어 개발의 더 나은 방법을 전파한다. 이러한 작업을 통해 우리는 아래와 같은 가치에 도달하게 되었다.
– 절차와 도구를 넘어선 개성과 화합
– 종합적인 문서화를 넘어선 동작하는 소프트웨어
– 계약과 협상을 넘어선 고객과의 협력
– 계획 준수를 넘어선 변화에의 대응
이들의 앞선 가치들을 인정하면서도 뒤에 오는 가치들에 더 큰 무게를 둔다.
Waterfall에서 강조하는 프로세스와 문서에 관한 규정이 오히려 고객이 원하는 것을 시간 안에 이루어내는 프로젝트를 진행할 때 방해가 될 수도 있다는 입장이다.
애자일 방식은 프로젝트 사이클을 1~2주의 작은 스프린트로 나누어 끊임없이 변화에 대처한다.
고객이 원하는 내용이 변화할 때 계약을 재협상하여 변화에 대한 비용을 고객에게 떠넘기기보다 변화 그 자체가 프로젝트의 속성인 것으로 받아들인다. 고객이 원하는 내용을 만들어주기로 한 약속을 표면적으로 지키는 것보다 고객이 만족할 수 있는 동작하는 소프트웨어를 전달하는 것이 더 중요하다. 애자일을 사용하는 기업들은 이러한 가치를 만족하기 위해서 자주 점진적으로 동작하는 소프트웨어를 고객에게 전달하는 방법을 사용한다. 이러한 incremental, iterative delivery를 통해 애자일이 추구하는 가치를 더 쉽게 성취할 수 있다.
Agile과 아이폰
실리콘 밸리의 기업들이 만들어낸 대표적인 작품인 아이폰의 예를 들어보자. 아이폰은 고객의 잠재적인 요구사항을 끌어내고 그것을 점진적으로 혁신해낸 제품이다. 2007년에 출시된 아이폰은 출시와 동시에 모든 사람에게 신선한 제품으로 다가왔다. 얼리어답터뿐 아니라 많은 대중이 받아들인 아이폰은 고객들조차 잘 인지하고 있지 못했던 핵심적 요구사항을 잡아내었다.
2007년 전자제품의 시장에는 아이폰이 제공하는 기능들을 아이폰보다 더 잘해낼 기기들이 이미 넘쳐나고 있었다. iPod으로 대표되는 음악을 듣는 소형 미디어 플레이어는 많은 한국의 중소기업까지 시장을 다분화하고 있었다. 휴대전화 품질의 최고는 삼성과 노키아가 인정받고 있었고, 휴대전화에서 회사 이메일을 확인하고 답장까지 할 수 있는 BlackBerry는 번듯한 직장을 다니는 사람들의 포켓의 필수품이었다. Palm Pilot과 같은 PDA는 게임, 사전, 전자책, 미디어 플레이어 등의 성숙한 애플리케이션 생태계를 자랑하고 있었다. 마이크로소프트의 모바일 윈도 제품의 Office에서 파일을 저장하면 PC에서 읽는 것이 가능했다. 하지만 이러한 기기들이 대중화되기엔 부족한 점이 많았다.
스티브 잡스의 전기에 소개된 일화가 재미있다. 스티브 잡스의 지인이 마이크로소프트 임원으로 일하고 있었는데 하도 시답지 않은 마이크로소프트의 태블릿 프로젝트에 대해 자랑질하는 것이 못마땅했다고 한다. ‘어떻게 하는 건지 보여주마`라는 식으로 아이패드를 개발을 시작했다가 아이폰을 먼저 내놓았다고 하는데, 이 말의 반을 농담으로 받아들인다 하더라도 잡스는 기존 gadget들이 대중의 사랑을 받지 못하는 이유를 이해하고 있었던 것이 아닌가 생각한다. 아이폰은 사용자가 손에 쥐는 순간 본능적으로 거의 모든 기능을 사용할 수 있도록 디자인되어 있었고 스마트 기기라고 하는 것이 일부 얼리어답터 층이 아닌 대중에게 받아들여지는 시작점이 되었다.
기능만 보자면 이미 얼리어답터들이 사용하던 몇몇 기기들이 더 훌륭하다고 볼 수 있었지만, 아이폰이 대중의 사랑을 받은 이유는 대부분의 잠재적 고객들이 원하는 가장 중요한 기능을 먼저 담아내었기 때문이다. 아이폰은 정전식 터치 기술을 화면에 적용한 최초의 완성품이었다. 아이폰 10주년을 기념한 iPhone X에 비하면 최초의 iPhone이 기능과 성능 면에서 초라해 보일지 모른다. 하지만 손가락의 가벼운 터치로 부드럽게 움직이는 기술만큼은 초기 제품부터 완성도를 보여주었다. 아이폰에 제공된 모든 기능은 사용자가 쉽게 배우고 쓸 수 있으며, 쓰는 경험 자체의 만족도가 높았다. 이후 많은 제품이나 소프트웨어의 디자인에 사용성(usability)이라는 요구사항이 추가되었다.
하지만 아이폰에 탑재된 첫 iOS에는 썩 중요한 기능이 많이 빠져있었다. 그러한 기능들은 해를 걸친 업데이트를 통해 제공되었다. 요즘 당연하게 생각하는 복사 붙이기(Copy & Paste) 기능은 출시 후 2년이 지난 2009년도에서야 보완된 기능이었다. 멀티태스킹은 2010년, 아이폰으로 찍은 사진을 iMessage를 통해 보낼 수 있는 기능은 2011년에서야 추가되었다. 나중에서야 완성된 이러한 기능들을 완벽하게 설계하고 처음부터 구현하고자 노력했다면 과연 대중의 사랑을 받을 수 있는 완성도로 2007년에 출시할 수 있었을까?
아이폰에서 사용자의 만족을 위해 일부러 뺀 기능도 있었는데 가장 유명한 것이 어도비 플래시를 지원하지 않는 것이었다. Adobe Air를 통해 플랫폼의 제한이 없는 앱을 파는 것이 애플의 소프트웨어 플랫폼 전략과 충돌하기 때문이었을 수도 있지만 (애플은 보안의 취약점이라고 변명했다), 당시 모바일 프로세서 성능이 플래시를 통해 제공되는 멀티미디어 콘텐츠를 재생하기에 부담스러웠고, 배터리 소모가 큰 점 등 역시 중요 이유였다. 한 가지 기능을 위해 전체적인 사용자의 경험이 만족스럽지 않다면 차라리 제공하지 않겠다는 것이다. 이후 조금 더 멀티미디어의 프로세싱 코스트가 낮은 HTML5 기술이 보편적인 기술로 받아들여지게 되었지만, 초기에는 애플의 이러한 선택을 불만스럽게 생각하는 사람들이 많았다. 때로는 사용자의 만족을 위해 사용자가 원하는 것을 제공하지 않는 고집스러운 선택이 필요하다.
플래시는 보여주지 않는 iOS
작은 delivery를 자주 하는 방법으로 설명되는 애자일 방법론은 애자일 선언문에서 볼 수 있듯이 고객이 중요하다고 느끼는 가치를 효과적으로 만들어내는 방법일 뿐이다. 고객에게 가장 중요한 것을 먼저 전달하고 나면 고객의 생각이 바뀔 수도 있고, 그러는 사이에 기업이 처한 시장의 상황이 바뀔 수도, 같은 일을 더 쉽게 할 수 있게 하는 기술이 생겨날 수도 있다. 하지만 고객이 원하는 것이 분명하고 써야 할 기술도, 시장도 크게 변화하지 않는 상황이라면 애자일 방법론을 사용해야 이유를 다시 한 번 생각해볼 필요가 있다.
애자일은 값싸고 빠른 프로세스가 아니다
아이폰을 예로 애자일의 기본 정신을 설명하기는 했지만, 고객이 새 기능을 제공받기 위해 1년씩이나 기다려야 하는 프로세스라면 애자일의 반대편에 서 있을 확률이 높다. 요즘 애자일의 delivery cycle은 1주~2주를 사용하며 빠른 경우는 매일 이루어지는 경우도 있다. 이와 같은 빠른 delivery cycle을 고객이 요청한 사항을 다음 주에 만들어 준다고 이해하기 쉬운데 이것은 큰 잘못이다. 고객과의 대화가 자주 일어나는 것은 사실이지만 원하는 기능을 최종적으로 전달하는데 Waterfall 모델보다 더 오래 걸릴 수도 있다. 다음 그림을 보면서 생각해보자.
Image Credit그림 윗줄에서처럼 최종 제품인 자동차를 만들기 위해 자동차 부품들을 차례대로 만들어 인도하고 마지막에 조립을 통해 완성품을 인도했다면 이것은 애자일 프로세스가 아니다. 어쨌든 이렇게 만든 자동차를 자동차 A라고 하자. 아래의 스케이트보드는 자동차와 어찌 보면 무관하지만, 고객이 타고 이동할 수 있는 최소 기능 제품 (MVP: Minimum Viable Product)이다. 이처럼 고객에게 점차로 발전된 제품을 제공하는 것이 애자일 프로세스에 가깝다. 이렇게 전달된 자동차를 자동차 B라고 하자. MVP의 전달이라는 면에서 자동차 A의 인도는 마지막 1번 이루어졌지만 자동차 B는 4차례에 걸쳐 이루어졌다.
고객이 쓸 수 있는 최소한의 제품을 먼저 출시하고 점차로 제품을 발전시켜나간다는 점에서 애자일은 비효율적인 방법으로 보일 수 있다. 만약 고객이 구체적으로 원한 기능과 디자인만을 만족하게 하는 자동차를 만드는 일이었다면, 스케이트보드와 자전거 그리고 모터사이클을 제공한 회사보다 처음부터 자동차를 조립하기 시작한 회사가 먼저 제품을 인도했을 수도 있기 때문이다.
그렇다면 왜 애자일 방법론이 좋다고 하는 것일까. 100년이 넘는 역사를 자랑하는 자동차의 경우 정말 많은 시행착오를 통해 오늘날의 자동차 모습을 가지게 되었다. 하지만 지구와 동떨어진 어떤 행성에서 어떤 고객이 아무도 본 적이 없는 자동차를 요구했다고 하자. 자동차를 써본 적이 없는 고객이 주문을 넣고 2년을 기다려 인도받아 처음 운전해본 고객의 경험은 어떤 것일까. 반면 첫 delivery로 복잡하지 않은 스케이트보드를 사용해본 고객은 필요할 때 빠르게 정지할 수 있어야 한다는 기능을 필수 기능으로 인지했을 것이다. 자전거를 사용해본 고객은 속도가 빨라질수록 조향 안정성이 중요하다는 점을 인지했을 것이다. 모터사이클을 사용해본 고객은 엔진의 신뢰도가 높고 관리가 편해야 한다는 점을 인지했을 것이다. 이와 같은 과정을 통해 만들어진 자동차 B는 고객으로부터 주어진 ‘A에서 B로 갈 수 있다’는 요구사항을 만족하게 하는 자동차 A에 비해 더 안전할 뿐 아니라 운전하기 즐겁고 운영 비용도 적게 들 가능성이 크다.
애자일 프로세스는 값싸고 빠른 프로세스가 아니다. 최종 제품만 비교한다면 오히려 비싸고 느린 프로세스가 될 수도 있다. 하지만 추가된 비용이나 시간은 고객을 만족하게 하지 못할 가능성에 대한 리스크를 줄이는 것으로 얻는 가치에 비해 상대적으로 적은 지출일 수 있다.
조직 문화와 개발 프로세스
이전 글 “갑이 없는 조직“에서 Role-driven 기업문화와 Rank-driven 기업문화의 차이점을 다루었다. 또한 “대기업 Aaron과 실리콘밸리 Bryan”에서 각 조직문화에 필요한 인재상을 살펴보았다. Waterfall과 Agile 프로세스는 각각 어떤 조직문화에 더 적합한 것일까?
Waterfall 모델이 적용되는 프로젝트를 먼저 보면, 요구사항이 분명하므로 고객이 같은 요구사항을 만족하게 하는 경쟁사간의 입찰을 통해 프로젝트의 주간사가 결정된다. 이렇다 보니 요구사항, 가격, 기한이 정해져 있기 마련이고 이제 남은 변수는 품질이 된다.
Quality Triangle
요구사항을 만족하게 하는 제품을 기한 내에 납품해야 하는데 비용을 더 들이지 않고 품질을 높이려면 체계적인 관리 기법이 적용되어야 하고 조금이라도 예상에 어긋나는 일이 생길 때마다 그 손실을 보상하기 위한 추가적인 노력을 들여야 한다. 관리자는 각 직원이 중복된 작업을 하지 않도록 효율적인 업무 분배를 하며 필요한 만큼의 정보를 나누어 주는 일을 해야 한다. 아무래도 이러한 프로세스를 수행하기 위해서는 모든 직원이 회사의 미션을 이해하고 고객에게 가치를 전달하기 위한 결정들을 각 직원이 내리는 role-driven조직보다는 체계적으로 일을 분배하고 관리하는 데에 적합한 rank-driven 조직이 적합할 것이다.
애자일 프로세스는 고객이 만족하는 데 필요한 것을 탐색하는 과정을 포함하는 과정이기 때문에 비용과 시간 그리고 요구사항이 묶여있으면 쓰기 어렵다. 비용과 시간이 묶여 있는 경우라고 하더라도 고객이 만족할 수 있는 MVP가 인도되도록 최선을 다한다는 데에는 변함이 없다. 정해진 기한 내에 자동차 B를 만들어 인도하는 데에 실패하더라도 고객은 이미 조향 성능이 훌륭하고 신뢰도가 높은 모터사이클 B를 만족스럽게 운용하고 있을 것이기 때문이다. 애자일 프로세스를 통해 프로젝트를 진행하는 팀은 고객 만족을 위한 가치를 만들어 내기 위해 다양한 전문성을 가진 팀원들이 협업과 잦은 iteration을 통해 제품을 개발하고 있을 것이다. 명령체계가 분명하지만, 방향을 유연하게 바꾸기 어려운 rank-driven 조직보다는 각 팀원이 전체의 방향을 이해하고 자신이 해야 할 일에 대한 해결책을 끊임없이 모색하는 role-driven 조직이 적합하다.
고객이 요구사항을 구체적으로 계약 조건에 문서로 만들고 싶어 한다면 어떨까. 모터사이클 B를 받고 난 뒤, 자동차 B를 제때 받지 못했다고 해서 고객사가 프로젝트 대금을 지불하지 않겠다고 한다면 애자일 방법론을 사용하는 데 문제가 있을 것이다. 애자일 방법론을 사용하기 위해서는 제품을 만들어 제공하는 회사뿐 아니라 고객사가 같이 참여하는 기업 문화가 우선되어야 한다.
앨리스는 고양이에게 다가가 물었다. “여기서 나가는 길을 알려주지 않을래?”
“네가 어디로 가고 싶은 지에 달렸지.” 체셔 고양이가 대답했다.
-루이스 캐럴, 이상한 나라의 앨리스
* Waterfall이나 Agile과 같은 관점의 차이와 관계없이 프로젝트 관리에 유용한 도구들을 배우기 위해서는 Goldratt의 The Goal이라는 책을 추천한다.
글: Aiden. 엔지니어링 매니저. 데이터 수집을 통한 프로세스 개선에 관심이 많음.
그림: Chili. 디자이너. 생각을 그림으로 요약하는데 관심이 많음.
Project Group 실리콘밸리를 그리다 / 페이스북
