계획

여러 사람들과 이런저런 이야기를 했던 것을 조금 길게 정리해 둔다. 소규모의 소프트웨어 개발 집단이 개발 계획을 어떻게 짜고 관리할 것에 대한 경험에 따른 몇 가지 이야기이다.

계획을 짜고 실행하는 것은 사실 복잡하지 않다. 구체적인 계획을 짜고 일정한 주기에 따라서 확인하며 실행하면 된다. 마치 어린 시절 방학 시간표를 짜듯이. 그리고 실패한다. 어린시절 방학 계획표처럼. 아래의 이야기들은 덜 실패하기 위한 이야기이다.

1. Plan A - 실행 가능한 계획을 짠다.

계획은 현재 수행 가능해야 한다. 계획에는 기간뿐 아니라 구성원의 역량이나 비용 등이 포함되어야 한다. 구성원의 역량을 넘어선 무리한 일정이나 미래에 합류할 사람처럼 확정되지 않은 자원이나 혹은 막 들어온 인턴처럼 일감 단위의 업무를 진행할 수 없는 인원을 계획에 포함해서는 안된다.

계획에는 목표와 기간이 있어야 한다. 계획을 짜는 데 있어 흔한 실수는 추상적이거나 실행할 수 없는 목표를 잡는 것이다. 목표는 객관적인 지표로 평가되어야 한다. 제품 출시라면 제품이 가져야 할 구체적인 기능들이 명세되어 있어야 하고, 출시일이 설정되어야 한다.

큰 계획은 관리하기 쉬운 단위로 쪼개서 관리한다. 세부일정을 한꺼번에 작성하지 않는다. 마일스톤을 주기적으로 설정하고 계획을 주기적으로 수정한다. 이슈트레커를 사용한다면 한 일감은 일정 단위로 쪼개고 이를 묶어서 관리한다. 팀에 알맞는 단위를 찾는 것도 중요하다.

비밀의 상자는 없어야 한다. 계획이 망쳐지는 흔히 상황은 해결될 것으로 예상했던 문제가 해결할 방법이 없는 경우이다. 예를 들면, 제품의 일부가 특허로 묶여 있거나, 최적화가 불가능해서 성능에 치명적인 문제가 있거나 하는 부분들이다. 물리적으로 논리적으로 불가능한 경우도 있다. 새로운 제품을 만드는 경우라면 계획을 수립하기 전에 세부적인 구현을 일정에 포함하지 않더라도 우회가 불가능한 부분들에 대해서 개념 증명(proof-of-concept)이 끝나 있어야 한다. 이런 개념 증명은 계획 단위를 벗어나더라도 우선적으로 수행되어야 한다. 제품이 카피캣인 경우의 몇 안 되는 장점은 개념 증명을 대신할 수 있다는 것이다. 만일, 비밀의 상자가 있다면 가장 우선 정리되어야 하고 계획 수립은 그 이후로 미루어져야 한다.

2. Plan B - 모든 계획은 실패한다.

계획은 실패 가능해야 한다. 작은 계획들이 계속 실패하고 수정되는 것이 당연해야 한다. 그러나 실패의 흔적이 남고 그 흔적들이 모여 도미노처럼 모든 계획을 무너트리지 않도록 하는 것이 중요하다. 실패를 시스템의 일부로 만들어야 한다. 일정과 일정 사이의 여유는 가장 기본이고, 대체 투입 가능한 자원이나, 추가 투입 가능한 자본이나, 계획의 수정까지 모든 계획의 수행에는 실패 시의 대안이 있어야 한다.

낙관하지 않는다. 외부요인에 의한 실패는 예측하기 쉽지 않다. 특정 게임의 성공으로 인한 클라우드 서비스의 자원 포화, 특정 보안 문제로 인한 클라우드의 전체 시스템 성능 하락 같은 것들을 예측하는 것은 불가능하다. 태풍으로 인한 하드디스크 가격의 급등이나 암호화폐의 부흥으로 인한 그래픽 카드의 품절현상도 생길수 있다. 최근 모두 있었던 일이다.

Bus Factor는 2 혹은 그 이상으로 한다. 개개인의 능력에 의지하는 시스템은 무조건 붕괴한다. 하나의 작업에 대해서 대체 가능하고 대체하는 인원도 자신의 일을 대체할 수 있도록 그물처럼 연결되어야 한다. 팀 단위 업무처리나 코드리뷰와 이슈트레커 같은 시스템을 잘 사용한다면 쉽게 이러한 시스템을 구축할 수 있다.

작업자는 실패를 선언할 수 있어야 한다. 즉, 작업이 주워질 때는 작업을 언제 멈출 것인지에 대한 기준이 제공되어야 한다. 이미 실패가 예상된 상황에서 판단을 보류하거나 외면하는 것은 일을 악화시킬 뿐이다. 진행 불가능한 상황에서는 멈추도록 그리고 이를 주변에 알리도록 해야 한다. 작업의 명세가 잘못된 경우에는 수정하고, 다른 작업자가 작업하거나, 작업을 취소할 수 있어야 한다.

미리미리 점검한다. 다시 말하면 미리 실패시킨다. 초보는 자신이 모르는 것을 모르기에 상황을 알리지 않는다. 어떤 이들은 결과물이나 목표를 오독한다. 그리고 어떤 이들은 자신의 이익을 위해 목표를 수정하거나 문제를 은폐한다. 시간이 무작정 늘어나는 것을 방지하기 위해서는 Issue tracker를 기본으로 지표들을 주기적으로 점검하고 지속적인 대화를 통해 상황을 판단해야 한다. small talk을 이용한 over communication을 활용할 수 있다.

3. Plan C - 망했어요.

완전히 망할 수도 있다. 망하면 이제 전체 팀은 무엇을 할 것인가에 대한 계획도 필요하다. 누군가 책임을 지거나 조직을 해체하거나 사업을 접거나 결과물의 일부를 이용해서 다른 일을 계획하거나 하는 다양한 선택지들이 있다. 회고와 평가가 이어져야 한다.

계획은 지속적으로 평가되어야 한다. 그런데 기준은 무엇인가? 계획이 실패했다는 것은 무엇인가? 제품은 검증하고자 하는 가설을 기반으로 한다. 가설은 보통 고객의 문제를 제품으로 해결할 수 있을 것이라는 형태를 지닌다. 그리고 가설 검증은 가설을 한정된 자원으로 주어진 기간 동안에 검증할 수 있을 것이라는 기대를 기반으로 한다. 즉, 제품을 만든다는 것은 문제, 가설, 자원, 기간이라는 특징점 들을 갖는다. 누군가는 제품을 완성한다는 계획과 독립적으로 가설 검증이라는 기준과 함께 평가해야 한다. 그리고 평가의 결과에 따른 판단을 해야 한다.

4. Revised Plan A - 모든 계획은 목표부터.

모든 계획은 가설 검증 단 하나를 향해야 한다. 수많은 기법들, 시스템, 최신의 기술이나 도구들을 사용하는 데 있어서 기준은 언제나 가설 검증을 빠르게 하는데 도움이 되는지 여부이다. 언제나 기준이 분명하면 선택은 쉽다. 단 두 명이 일하는 상황에서 수많은 문서를 남기는 것보다 몇 줄의 낙서가 효과적이다. 각종 시스템과 기법을 고민하기에 앞서서 문제에 집중해야 한다.

기간을 설정할 때는 순수하게 계산되는 일정의 1.5~2배를 기준으로 잡는다. 일과 일 사이에 필요한 휴식 시간을 포함하여 미리 여유를 둔다.

일감에는 기간과 이유 우선순위가 있어야 한다. 이유와 기간 없는 ASAP는 하지 않아도 되는 일과 동의어이다. 각 작업별로 이유를 기록하고 가설 검증에 도움이 되지 않는다면 폐기한다. 할 수 없는 일은 하지 않는 편이 이익이다.

마무리

위의 이야기는 계획을 잘 짜야한다는 이야기를 하는 것은 아니다. 회사가 푸는 문제가 명확하지 않으면 아무 계획도 쓸모없다는 이야기다. 다시 말하면, 회사의 정체성 혹은 정의가 분명하지 않으면 아무리 제품을 잘 설계하고 계획을 아무리 잘 만들어도 실패한다. 처음 한두 번은 그냥 흘러가지만, 계획의 실패가 반복되면 아무리 둔한 사람이라도 이유 모를 불편함을 느끼기 마련이다. 패배의식이 가득한 회사에서 개개인이 개인의 이익을 움직이기 시작하면 무기력함이 전염병처럼 퍼지고 회사는 끝도 없이 무너진다. 생각을 하나로 모으는 것이 제품을 만드는 팀(개발, 디자인, 기획, 등등)을 돕는 가장 쉬운 방법이다.

또, 아무리 목적이 분명해도 실행하는 이의 능력과 의지에 따라서 엉망이 될 수도 있다. 외연을 만드는 것은 쉽다. 인터뷰를 하고 최신 기술을 도입하고 컨퍼런스에 발표를 하고 블로그를 쓰고 뉴스레터를 만들고 숫자를 예쁘게 만든다. 매주 회의에 유저의 숫자의 증가와 완벽한 테스트 커버리지, 이슈 마감률을 통한 진행을 말하는 것은 쉽다. 그러나 그런 외연이 제품을 만들고 문제를 해결해 주는 것은 아니다. 외연이 앞서고 문제 해결이 따라올 수도 있지만, 문제 해결이 되지 않으면 아무 일도 일어나지 않는다는 것을 기억해야 한다.리더가 문제를 포괄적으로 계획할 수 없다면, 여러 명이 같이 계획할 수 있도록 시스템을 구성하거나, 내부 역량을 키워야 한다.

다시 말하지만 문제가 정의되지 않은 상태에서의 제품 계획은 무의미하다. 계획이 없는 시간들도 중요하다. 중간중간 쉬는 시간과 반복되는 일들을 수행하면서, 기술 부채를 줄이고 내부 역량을 올리는 시간은 계획과 계획 사이에 꼭 필요하다. 하지만, 이런 시간이 의미 있게 되려면, 팀이 목표를 앞으로 갈 것이라는 강한 믿음이 있어야 한다. 이 것을 팀워크라고 한다.

Plan A는 모두를 위해서 Plan B는 계획을 관리하는 사람을 위해서 Plan C 는 의사결정권자를 위한 이야기이다. 작은 팀에서 일정은 지연되고, 통장에 돈은 없고 사람은 늘 모자라다. 팀이 커지면 커뮤니케이션이 복잡하고 팀 간 이해관계가 복잡해진다. 수많은 숫자로 자기를 만족시키고 서로를 속이기 전에 계속 질문해야 한다. 그래서 지금 만들고 있는 것이 무엇인가. 왜 만드는가? 모두가 다 목표에 대해서 이해하고 동의하고 있는가?