국내 B2B Legal 스타트업인 '법틀'이 실재로 겪은 경험
스타트업 기업들의 프로세스 개발에 관한 생생한 이야기
스타트업엔은 실제 스타트업기업에서 프로세스 개발과정에서 일어난 생생한 이야기를 시리즈로 다루고자 한다.
법틀에서 현재 쓰고 있는 개발 프로세스는 무엇일까? Only 1 Week 프로세스이다.
Agile의 단위를 1 Week으로 끊고 극단적으로 장기 목표를 분해한다. 어찌 보면 하루살이 인생 같지만 이게 의외로 잘 통한다는 것을 경험을 통해서 익혔고 현재도 개선 중이기는 하지만 이전 프로세스보다는 더 잘 동작한다는 것을 확인했다.
◇Only 1 Week 프로세스가 무엇인가?
몇 가지 특징을 들자면 하기와 같다.
1. 한 주일을 단위로 모든 계약 / 실행 / 개발 / 검증의 절차를 모두 진행한다.
2. 자체적인 Deadline은 없다.
3. 큰일도 모두 1주일 단위로 재단한다.
모든 프로세스를 1주일 단위로 실행하고 1주일 이외의 Deadline은 없다. (이상적으로 그렇다는 것이다. 실제로 해보니 고객이 주는 Deadline은 어쩔 수 없었다. 하지만 법틀은 Cloud 업체라 고객의 Deadline보다는 자체적인 Deadline이 더 많았었다.) 이게 통할까? 혹은 이게 효율적일까?라는 의문을 우리도 가지고 시작했었다. 근데 통하고 최소한 지금까지는 효율적이었다.
이 방식이 정말 탁월하고 훌륭하며 잘 설계된 구조라고까지 생각하지는 않는다. 그러기에는 너무 간단하다. 하지만 언제나 간단한 것이 잘 팔리고 잘 먹힌다. 이 방법의 철학을 좀 그럴듯하게 표현하자면 "현재에 최선을 다하자. 내일을 내일의 해가 뜬다." 정도가 될지 모르겠다. 어떤 소프트웨어 제품 개발 이런 것에는 너무 변수가 많다. 시장의 변화, 기술의 변화, 인력의 변화 또 미처 예상하지 못했던 난점들 등 미리 어떤 계획을 세운다는 것 자체가 불가능하다는 점을 인정하고 들어가는 것이다. 장기적인 목표는 추상적으로 있어야 한다. 즉 Version3에서는 소통 기능을 크게 강화해보자. 정도는 있어야 할 것이다. 그다음에는 매주 단위로 그냥 최선을 다하는 것이다.
◇Only 1 Week 프로세스는 어떻게 운영하는가?
이게 무슨 개발 프로세스 Diagram이냐 하겠지만.... 이게 다다. 개발팀도 종종 간헐적인 Scrum 아닌 Scrum을 하긴 하지만 수요일 잠깐 회의 외에는 주간에 개발팀만이 하는 회의도 없다. 물론 내부적으로 이슈를 관리하기 위해 Jira를 사용하고 Jira 사용은 상당히 고도화되어 있다. Backlog와 Sprint 관리는 이 프로세스에는 중요한 파트 중에 하나지만 이 글을 심도 있게 읽고 있는 분들은 이 부분은 이미 잘 알고 있으리라 가정하고 중구 부언하지 않겠다.
월요일 [주간회의] Jira의 이번 주 Sprint를 보고 이번 주 계획에 대해서 논의한다. 여기서 중요한 점은 각 Task들이 1주일 단위로 명확히 구분되어 있어야 하고 금요일날 검증 가능한 형태로 잘라져 있어야 한다는 점이다. 예를 들어서 "유저 검색 기능 강화"라는 말을 쓰지 말고 "유저 검색 기능 중 그룹별 검색 조건 화면 추가 및 이에 따른 결과 화면 작성"과 같이 아 이번 주에 무엇이 나오겠구나 하는 점을 비록 작은 단위일지라도 (실재 "유저 검색 기능 강화"에는 엄청난 기능이 많이 더 있더라도) 명확하게 표현해서 기입해야 한다.
또한 검토나 기술 설계 등도 아이템인데 이런 경우에는 되도록 금요일 검증 이전에 논의 등을 잡는 것도 좋다. 예를 들어 어떤 Advanced&Difficult.js라는 라이브러리가 있다고 가정해서 이것을 쓸지 여부를 검토하는 것이 아이템이라고 했을 때는 1주일 단위로 자르기가 애매한 점이 있다. 참치가 큰지 작은 지를 알아야 자르지 참치를 모르는 상태에서 공부하는데 그 기간을 설정하기 애매한 점이 있는 것들이 있다. 이런 것들은 일단 주 중에 한 번 정도 논의를 통해 어떻게 진행되는지 또 이번 주에 어디까지 확인이 가능하지를 같이 확인하는 것도 좋다.
수요일 [개발팀 중간 회의]는 주로 진행 상황에서의 어려움, 변수 발생, 변경 사항들을 관리하는 회의이고 또 개발 중에 다른 개발자들과 같이 정해야 하는 공통적인 요소 등을 논의할 수 있는 자리이다. 운영이 되는 주도 있고 아닌 주도 있다. 각자 할 일이 너무 명확하고 그냥 진행하면 될 때는 쓸데없는 회의이기 때문에 진행하지 않는다. 이 부분은 개발 PM이 진행 여부를 잘 판단해야 한다.
목요일 [Task Planning 공유]는 차주에 대한 대략적인 그림을 개발 PM과 기획자/경영자 간에 나누는 일이다. 목요일 오후 정도가 되면 대략적으로 이번 주의 그림이 나오기 때문에 이를 바탕으로 (Jira Item은 아직 없지만) 차주 어떤 개발 항목들을 진행할지를 구두로 협의하는 과정이다. 월요일 논의할 Sprint의 뼈대를 세우는 일을 미리 하는 것이다.
금요일 [Test 진행]은 한주의 결과물을 검증/확인하는 자리이다. 이것은 절대 Full 검증이 아니다. Unit Test 정도의 개념인데 조금 더 Spot 성으로 생각해도 된다. 약간 복잡한 기능들은 미리 검증팀에서 Test 시나리오를 준비하기도 하고 또 아닌 간단한 기능들은 머릿속에 생각나는 시나리오 기반으로 기본 기능 + 복합 기능의 기본 시나리오를 테스트한다. 그리고 검증 결과를 금요일 오후에 게시한다.
릴리즈 모드는 조금 특별한 모드다. 일주일 일주일의 성과가 모여서 고객을 위한 새로운 릴리즈가 준비되면 그때는 전체가 릴리즈 모드로 바뀐다. Full 검증이 이루어지고 결과에 따라 개발자들은 검증 결과 해결에 전력으로 투입되기도 하고 또 아니기도 하다. 이때에는 금요일 Test 진행이나 수요일 개발자 회의나 차주 계획 등이 필요 없다. 검증팀 첫 주의 검증 결과에 따라 많은 것이 바뀌고 또 정해지는 유동성 있는 프로세스이다.
◇자체 Deadline이 진짜 없나?
없다.
우리의 일주일은 어떤 큰 부분의 한 작은 단위가 아니다. 일주일이 전부다. 매주 금요일날 모든 개발팀 업무는 종료되고 월요일에 다시 새로운 아이템들이 태어난다. 일이 너무 많다면 주간 업무를 줄인다. 일이 없다면 묵혀왔던 스토리나 기능을 다시 꺼내어 본다.
장기적인 Deadline이 있을 때는 한 주는 그 장기 Deadline의 부속품이 되어 버린다. 즉 "아, 아직 릴리즈가 3개월 남았는데 무슨 코딩이야" 이런 상태가 되거나 "이번 주 죽었다. 와 진짜 X되었네 차주 릴리즈 어떻게 하지" 상태가 된다. 이런 상태를 개발자도 행복하고 기획자도 행복하고 경영자도 만족할 수 있는 효율적인 상태로 바꾸어 줄 수 있는 것이 Only 1 Week 프로세스이다.
개발자들에게 자유를 주면 방종만 있을 것이라고 걱정하는 사람도 있을 것이다. 법틀이 그렇지 않다는 반증이다. 우리는 이 프로세스로 2.0 업데이트를 무사히 만들었으며 지금도 3.0 버전 개발을 초기 예상보다 빠르게 진행하고 있으면서도 많은 고객의 요구 사항들을 지체 없이 전달하였다. 물론 회사의 구조 자체가 약간 Old 하여서 절대적인 상명하복의 구조하에 돌아가는 회사를 갑자기 이렇게 바꾸기는 쉽지 않을 수 있다. 하지만 이 프로세스의 부가적인 장점 몇 가지를 더 설명해 보도록 하겠다.
1. 유연하게 변화에 대응이 가능하다.
개발을 하면서 아마 우르릉 꽈 꽝 하고 갑자기 천둥 치는 듯한 변경 사항이나 또는 환경 변화를 겪어 봤을 것이고 대부분의 소프트웨어 프로젝트는 이런 변화 관리를 잘 못해서 실패한다. 하지만 1주일 단위로 최선을 다하는 프로세스는 모든 변화를 가능하게 한다. 우리에게 다음 주는 없다. 이번 주만 있는 것이다. 새롭게 논의되는 모든 항목이 다 변화고 새로운 Task 이지 굳이 다를 것이 없다.
2. 한 가지 기능에 대해 깊이 생각하게 되고 실재 유저가 쓸 수 있는 기능을 만든다.
이렇게 한 주 한 주 단위로 일을 하다 보면 같은 기능에 대해서도 이리저리 생각해보고 검증 및 확인을 자주 겪게 된다. 또 이게 아니다 싶으면 다음 주에 확 뒤집는 일도 허다하다. 미켈란젤로가 조각을 하기 전에 돌을 거의 1년간 쳐다만 봤다고 한다. 조금 과장하자면 1주일 단위로 이것저것 시험을 해본다고 생각해도 무방하다.
3. 개발자의 스트레스가 적다.
이전처럼 MM로 소프트웨어를 계산하거나 야근을 안 하면 쓰레기 S/W 일정이라고 생각하고 있다면 지금 눈앞의 시계를 10년 전으로 감으면 약간은 통할 수 있다. 현재도 이런 로직은 통하지 않고 앞으로 올 10년에는 엄격한 통제하에 노동 생산성을 올려서 만들 수 있는 소프트웨어는 최소한 한국 시장에서는 사장될 것이라고 생각한다. 그런 저질의 소프트웨어가 기생할 수 있는 분야가 점점 좁아지고 있다. 만드는 사람도 좋은 환경에서 최선을 다해야 좋은 소프트웨어가 나온다. 굳이 필요하지 않은 곳에 스트레스 받게 하지 않아도 된다. 진짜 개발자의 어려움은 다른 곳에 있다.
◇Only 1 Week 프로세스에 조심할 점이 있나?
몇 가지가 있는데 생각나는 데로 적어보도록 하겠다. 우선 릴리즈 모드를 잘 활용해야 한다. 어느 시점에는 끊어줘야 할 시점이 있다. 1주일 단위로 모든 것을 관리하다 보니 예를 들어 이번에 3.4버전을 릴리즈해야 하는데도 그 범위가 명확지 않다 보니 작은 업데이트를 계속 무한 루프처럼 하게 되는 일이 있다. 조금 더 깎고 조금 더 깎고 하다 보면 한 세월일 때가 있다. 이럴 때는 과감히 선을 긋고 "여기까지가 3.4이다."라고 하고 릴리즈 모드로 넘어가야 한다.
또한 기획이 느슨해지지 않도록 잘 관리를 해야 한다. 이 프로세스를 실행하다 보면 처음 기획이나 계획이란 것은 실재 결과물과 거리가 있을 때가 많다. 1주일 단위로 확확 뒤집어지는 경우도 허다하기 때문에 초기 계획이란 것을 의심의 눈초리로 보는 경우도 많다. 이렇기에 초기 기획의 퀄러티가 떨어질 수 있다. 대충대충 설계도 하나 놓고 "자 이제 답을 찾아보자"라고 하는 경우가 생길 수 있는데 이걸 막아야 한다. 초기 기획에 구조가 없고 논리가 없고 답이 없으면 개발 기간이 곱절로 늘어나게 된다.
또한 이런 프로세스를 실행할 때에는 반드시 제품 기능/로드맵 등에 결정 권한이 있는 사람이 주간 활동에 참여해야 한다. 특히 검증을 도와주는 것도 좋다. 결정권자가 없는 상황에서 이런 루틴을 반복하는 것은 무의미하다. 쳇바퀴처럼 주어진 우리 안에서는 움직이는 결국은 무의미한 프로세스가 되어버린다. 결과에 따라서 어떤 기능을 이번 버전에 뺀다는 결정을 목요일 기획-개발 팀장 논의에서 결정할 수도 있어야 한다. 그런 유연성이 보장되고 개발자/기획자의 권한이 보장될 때 제대로 동작하는 프로세스이다. 대기업 임원이라고 꼭 결재만 해야 한다는 것은 누가 만든 프로세스인가? 목숨을 건 제품이라면 같이 만들도록 하자. 스티브 잡스같은 CEO도 i-tunes 개발실에서 살았다는 일화도 있다.
◇첨언
이 프로세스는 법틀에서 시행한지 1년이 되지 않았다. 하지만 될성부른 잎은 떡잎부터 알아본다고나 할까? 상당히 잘 정착되었고 또 효과를 보고 있다. 이제는 생활에 녹아들어서 프로세스라고 느껴지지 않을 정도가 되고 있으니 무언가 이전 개발 프로세스처럼 억지로 회의 소집하거나 억지로 무슨 일정을 강요하는 것이 현저히 줄었다.
물론 고객의 일정까지 이렇게 유연하게 하기는 힘들 수 있다. SI 회사들에게 이런 프로세스를 적용하기는 맞지 않다. 때로는 저가의 약간 질 낮은 제품을 대량 생산해야 할 때도 있다. 그럴 때는 맞지 않는 프로세스이다. 심혈을 기울여서 만들어야 하는 소프트웨어 제품이 있다면 이런 프로세스도 한 번 시험해 볼 만할 듯하다.
그리고 글 중간에 Jira에 대한 내용이 나오는데 꼭 Jira 사용만을 권장하는 것은 아니다. Clubhouse든 Asana든 회사에 맞고 본인에 맞는 툴이 있다면 티케팅 시스템으로 사용하면 된다.