TOC(전체최적화이론)를 Application 개발에?

The Goal 을 읽고 나서

개인의 효율화가 아닌 전체의 효율을 위한 병목을 제거하라

경영학 특히 공장이나 프로세최적화 부분에서 혁신이었다던 서적 The Goal과 거기에서 말하는 TOC (전체최적화이론)에서 제시하는 방법은 어찌보면 복잡한듯 하지만 원리는 간단하다.

가장 문제되는 부분이 전체의 발목을 잡으니 그것을 찾아내고 개선하는 방법의 이터레이션을 돌아야 한다는 것이다. 과정은 아래와 같다.  

제약요인을 찾기

제약요인을 활용할 방법을 분석후 결정

다른 모든 프로세스도 2번기준으로 맞춤

제약요인의 향상

해당 제약요인이 해결되면 다시 1번으로 시작

겉으로 간단한듯 보이지만 실상 잘 적용하기 어려운 이 과정을, 한 번 제조도 아니고 매출도 없는 우리 서비스 개발쪽에 적용해보았다. (단, 어떤 기능 어떤 서비스를 만들지 판단하고 결정하는 과정은 제외한다. 이미 이것은 그 전의 프로세스에서 올바르게 결정되었다는 가정 하에 진행)

먼저, 공장에서의 중요3요소를 개발 프로세스에 적절히 대입해 보았다.      

현금창출 : 특정기능의 릴리즈
재고 :  기획만 되고 만들어지지 못한 서비스들  
운영비 : 릴리즈까지 걸리는 시간 

결국 우리의 목표는 정해진 기능들의 릴리즈를 빠른 시간내에 해당함으로써, 기획된 채 방치되는 것들을 줄여야 하는 것일 것이다.

지금까지의 개발 프로세스의 문제점

기획 - 디자인 - 설계 - 개발 - 테스트 - 릴리즈 의 과정을 거쳐 왔었고 대부분의 제약요인(병목)은 개발쪽에 있었다. 가장 시간이 오래 걸릴 수 밖에 없는 일이면서도 담당자가 1명 이었기에 좀 처럼 성능을 향상 시키기 어려웠다. 이것은 마치 더골에 나오는 공장내의 열처리 시설과 같은 케이스였다.

하지만 처음엔 이미 정해진 퍼포먼스를 늘리는게 불가능해 보였던 과정도 자세히 해당 작업을 지켜보니 크게 2가지 문제가 느껴졌다.  

개발자가 해당 작업을 진행 중인데 , 급하게 끼어드는 다른 작업(인터럽트)이 기존 작업을 멈추게 한다. 여기서 병목이 늘어남.

개발자가 개발을 진행하다가 기존에 기획 및 설계가 제대로 안된 부분들이 발견된다. 그래서 다시 논의가 필요하게 되고, 기획과 디자인이 수정되는 때 까지 개발은 중지되거나 재작업하게된다.

이를 해결하기 위한 2가지 해결책이 필요했다.

1. 인터럽트의 최소화

1번째는 중간 중간 인터럽트를 바로 발생시키지 않고, 몰아서 처리 하는것. 특정 업무를 진행하다가 방해받고, bug 를 고치기 위한 업무를 하는 시간을 계산해보면      

1개 버그에 소요시간 버그에 대해 이해하는 시간 : 5분
버그를 고치기 위해 결정을 기다려야 하는 시간:10분
버그를 잡기위해 필요한 시간 : 30분
컨텍스트를 전환 (기존 작업하다 버그 고치고, 다시 버그 고치고 돌아오는 시간) : 15분 

도합 1시간 가량이 소모된다고 할때, 만약 5일 중 4일이 버그가 나오면 4시간 가량이 소요된다. 이것을 한번에 몰아서 처리하는 방식 (현재 개발챕터의 BugFix monday) 으로 바꿔보면      

4개버그 소요시간 버그에 대해 이해하는 시간 : 15분 (담당자 혹은 PO 들이 이미 어느정도 어떤 버그인지 이해했거나, 버그가 아니라는 것으로 판명 될때도 있기에 줄어듬)
버그를 고치기위한 결정 대기 시간 : 5분 (이미 결정되었거나, 결정권자도 해당일에 버그픽스를 염두해두었기에 결정이 빠르다) 
버그를 잡기 위해 필요한 시간 : 2시간 (30*4) 
컨텍스트 전환 시간 : 1분*4 = 5분 (집중하고 있는 작업 1개를 도중에 끊지 않고 하나씩 처리하기에 거의 없음) 

결과적으로 버그처리시간은 당연히 동일하겠지만, 다른 부분들이 줄어들면서 4개버그 처리 하는데 2시간 반으로 줄어들었다. 버그가 많아지고 인터럽트가 많을 수록 해당 부분의 손실이 클 것이니 초긴급 버그가 아닌 이상 하루에 모아서 처리하는 방향으로 결정했다.

2. 기획 및 디자인의 재수정

2번째 문제는 바로 기획과정의 부실이다. 현재는 기획자가 없는 상황에서 PO 와 디자이너가 이야기하고, 몇몇 요구사항과 해당 서비스의 목표정도가 정해진 뒤에 현재는 바로 디자인에 들어간다. 그리고 나서 나온 프로토타입을 보면서 담당 개발자와 디자이너들이 대화해서 디자인시안이 확정되고, 해당 디자인이 제플린을 통해 나오게 된다. 그리고 비슷한 시점에 기획문서가 텍스트 형태로 나오게 된다. 어느정도 필요한 과정을 거치긴 하지만 그럼에도 붉어져 나오는 문제들이 있었다.  

문서와 이미지가 따로 존재해서 클라이언트 개발자들이 정확히 이해하기 어렵거나 질문이 필요.

기획문서가 먼저 나오고, 해당 문서에서 해결해야 하는 요구사항과 그것들의 구현이 완전히 정해지지 않은 상황에서 먼저 나온 디자인은 추후의 수정될 가능성이 높다. 실제로 매번 그런 경우가 존재.

개발 도중, 의견이나 문제가 발견되면 스몰토크를 통해 빠르게 해결. 하지만, 이런 경우 문서의 수정이나 공유가 잘 안되어 개발자들 간의 싱크가 맞지 않아 재작업 하는 경우가 발생.

특히나 1인 디자이너와 1인 api, 1인 app 개발자였던 시절이라면 3명이 모여서 결정하면 끝이었지만, 점점 사람이 늘어나는 상황에서는 확실하고 즉각적인 공유문서의 필요가 대두되었다.

그리고 한가지 더 기존에 몰랐던 문제도 새롭게 문제라고 인식하게 된 것이 하나 있었다.  

디자인이 상대적으로 빠른 속도로 처리되기 때문에, 너무 미리 디자인해놓고 개발되지 못해 쌓여있는 시안들이 많아졌다. 이는 결국 막상 개발할 수 있게 되었을때는 기획자부터 다시 이해해야하거나 , 지금 시점에 맞게 다시 기획&디자인 해야하는 경우가 많았기에 개발로 바로 이어지지 못함.

이것들을 `개발재고` 라고 불렀는데 이 또한 이번에 고민하면서 굉장히 무서웠던 부분이었다. 사실 디자인이 한참 미리 되고 개발에 들어가지 못하는 서비스들은 공통적으로 우선순위가 낮았고, 바뀔 가능성이 많은 것들이었다. 그러다보니 시간을 들여 기획 디자인은 했지만 개발되지 못하고 밀렸고, 나중에 개발할 수 있을 때 쯤이면 시간이 너무 지나서 기획자도 다시 이해하고 설명하는데 시간이 걸리거나, 혹은 이미 변화된 UX 나 시점때문에 재기획하거나 재디자인 해야 하는 경우가 많았다. 결국 몇 주 이내에 개발되지 않을 디자인을 미리 미리 처리해두는것은 공장에서의 재고와 같이 우리에게 비용처럼 남아버리는 현상을 발견할 수 있었다.

결국 위와 같은 문제를 해결하기 위해 각각의 구간의 속도를 맞추면서, 가장 오래걸리는 개발속도를 촉진시키기위해 전체적인 프로세스를 개선하게 된다.

기획부분이 훨씬 구체적인 질문으로 바뀜. (저희는 기획서라 안부르고 Epic 공유문서라고 부릅니다)

기록에 남는 문서로 만들어지는 것이 핵심이다.

또한 처음부터 완벽하게 기획하는게 아니라 크고 러프하게 시작해서 매번 논의할때마다 세부사항을 채워나갈 수 있게 되었다.

디자인은 해당 문서를 기반으로 디벨롭되며 특히 프로토타이핑을 만드는것이 중요한 요소. 그리고 나서 모든 스쿼드원들에게 온라인으로 공유되고 피드백을 받으며 명확해진다.

그 후에 디자인 파일이 완성된다.

개발전 API 담당자와 화면명,도메인명,그리고 어떤 식으로 상호작용할지 논의하고 설계문서에 포함한다.

개발 도중 변경되는 부분이 생긴다 해도, 바로 문서를 업데이트하고 슬랙으로 공유한다.

얼핏 보며 과정이 복잡해지고 길어졌지만, 이는 위에서 재기된 한번에 이해 안되는 업무, 기획이 바뀌어 재작업할 가능성, 서로 다르게 만들어져서 추후에 수정해야할 요소들을 최대한 제거할 수 있게 해준다. 이를 통해 기존에 개발에 들어가는 시간과 바뀔 시간을 산정해본다면      

개발할 서비스를 이해하는 시간 : 20 -> 5
개발하는데 드는 시간 : 100 -> 100
개발 했는데 바뀌어서 다시 개발하는 시간 : 20 -> 5
플랫폼간 다르거나, 공유되지 못한 부분을 테스트때 발견해서 다시 하는 시간 : 20 -> 0 

위와 같이 기존에 150 이라는 시간단위정도 걸리던것을 110 으로 줄일 수 있을것이라 예상된다.

이는 기존의 비병목 자원이었던 기획과 디자인 ( 실제로 지켜보면 특정 서비스 개발시 기획회의+문서 작성이 10 , 디자인이 15 개발이 50 정도의 시간이 들어가는것으로 보임 ) 을 활용하여 병목자원인 개발에서 생길 문제들을 사전에 차단할 수 있는 방법이다. 더골에서 병목자원에 들어가는 불량품을 미리 제거하고, 병목자원이 처리가능할 만한 물건들을 보내줬던 것처럼 개발자체에서 불필요작업을 하는 시간도 줄이고, 디자인만 미리 되어서 개발안되고 쌓일 재고도 줄일 수 있다.

결론

위 과정을 잘 시행하면, 더 잘 기획된 서비스를 실수 없이 빠르게 만들어 릴리즈 할 수 있고, 디자인시점과 개발시점에 큰 차이가 없어짐으로써 모두가 같은 업무를 함께하고 있다는 생각도 들어 더 집중할 수 있을거라 생각된다. 더 나아가서는 스프린트 시간을 조절하거나, MVP 만을 빠르게 릴리즈 하기 위한 (공장 리드타임을 줄였듯이) 시도도 해볼 수 있을것으로 보이며, 또 개발 과정이 제약요인이 아니게 되면 새로운 제약요인이 보이게 될 것이라고 생각된다.

결과적으로 기존에도 고쳐야 한다고 생각했던 기획,디자인, 개발 프로세스를 더골에 대입해서 더 정확하게 진단할 수 있었고, 덕분에 Why 를 분명하게 인지한 뒤에 공정을 개선할 수 있는 적절한 도움이 된 책이자 이론이었다.