1. 공수 산정의 어려움
3개월 동안 프론트엔드 1명, 백엔드 2명. 이렇게 하면 내가 원하는 앱이 나오겠지? 프리랜싱 플랫폼에서는 1천만 원이면 만들던데, 직접 팀을 꾸리려니 돈이 더 들겠네. 내가 잘 계산하고 있는 게 맞나?
개발을 직접 해보지 않은 이상, 프로젝트에 투입되는 정확한 개발 공수를 따지는 것은 무척 어려운 일입니다. 심지어 개발을 하는 개발자 본인도 제대로 측정하지 못하는 경우가 부지기수입니다.
즉 적정한 공수 산정은 원래 어렵습니다. 1그램 단위로 측정하는 정밀한 저울에, 한 발로 균형을 잡고 있다고 생각해보세요. 몸이 조금만 흔들려도 저울의 바늘이 휘청거릴 겁니다.
프로젝트의 난이도, 복잡도, 범위, 확장성은 이 바늘처럼 움직입니다. 그러면 무엇이 이 바늘을 왔다갔다 하도록 만드는 걸까요? 조금 따갑게 얘기하자면, 원인은 다름 아닌 경영자(또는 기획자)의 변덕입니다.
‘그렇게 심하게 변덕부리는 것도 아니고, 간단한 기능 추가나 수정 요청을 하는 것뿐인데 너무 방어적인 것 아니야? 일이 되게 만들 생각을 해야지, 안 되는 이유부터 찾으면 어떻게 일을 벌리나?’
위와 같이 생각했다면 이제 태도를 바꿔야 합니다. 위의 생각은 자세히 알지 못해서 생기는 착각인데, 개발의 세계에서는 이를 ‘해상도가 낮다'라고 표현합니다.
지구를 낮은 해상도로 보면 바다와 땅으로 나뉘어 있습니다. 아래 그림처럼 말이죠.
(출처: Freepik)
하지만 실제 지구는 위 그림과 전혀 다릅니다. 육지에 가까이 갈수록 바다는 심해와 연안해 등으로 나뉘고, 육지는 산과 사막, 도시와 도로와 경작지로 나뉘죠 :)
단순한 프로젝트에, 간단한 수정 요청 몇 가지가 더해지면 프로젝트가 얼마나 복잡해지는지 보여주는 사례를 들겠습니다.
운영중인 서비스에 커뮤니티를 추가하고 싶은 상황을 가정해봅시다. 커뮤니티를 “회원들이 자유롭게 글을 쓸 수 있는 게시판"으로 정의하면, 한 명의 주니어 개발자가 2주 안에 만들어낼 수 있습니다. 그런데 커뮤니티를 만들다 보면 다음 질문들이 생기기 마련입니다.
(1) 탈퇴한 회원의 글은 삭제할 건지 남길 건지, (1-1) 남긴다면 글쓴이를 “탈퇴한 회원”으로 표시할 건지 이름을 남겨둘 건지, (2) 신고 기능이 없어도 괜찮은지, (2-1) 신고 기능이 있어야 한다면 몇 번 이상 신고 받으면 글을 숨김 처리할 건지, (3) 비밀글 기능이 필요하진 않은지, (4) 인기 게시글이나 공지사항도 필요한지, (5) 관리자 계정을 따로 두고 글을 삭제할 수 있도록 할 것인지…
이런 해상도 높은 질문에 어떻게 답하느냐에 따라 프로젝트가 많이 복잡해질 수 있습니다. 가령, 위 기능을 모두 포함하는 것으로 요구사항이 커진다면, 두 명의 주니어 개발자가 4주 동안 만들어야 합니다. 즉 공수가 4배 커진 것이죠. 더욱이 처음부터 요구사항을 정해놓지 않고 중간중간 “아 맞다, 신고 기능도 넣어주세요.”라는 식으로 요청한다면… 두 명의 주니어 개발자가 6주 동안 만들어야 할 겁니다.
비용으로 따지면 250만 원 짜리 프로젝트가 1,500만 원 짜리 프로젝트가 된 것입니다. 작은 결정으로 6배나 비싸졌다는 뜻이죠.
물론 위 예시와 정반대로 예상과 달리 프로젝트가 예상보다 쉽고 간단한 경우도 많습니다. 그런 방식을 agile하다 또는 lean하다고 표현합니다.
이렇듯 공수는 섬세하게 변동하기 때문에, 쉽게 예상하기 어렵습니다. 특히 외부 개발사와 협업할 때 이런 문제가 불거지기 십상이죠.
2. 그렇다면 어떻게 해야 할까?
우선 그럴싸하지만 잘 통하지 않는 방법부터 말씀드리겠습니다. 그 방법이란, 업무 계획을 초반에 구체적으로 짜는 것입니다. 작업을 대분류, 중분류, 세분류 등 여러 계위로 쪼갠 후 1주차, 2주차, 3주차, … 이런 식으로 기간별 작업을 사전에 정해두는 경우가 더러 있습니다. 이를 Gantt chart 또는 WBS(Work Breakdown Structure)라고 부르기도 합니다.
(출처: Freepik)
그런데, 이대로 진행되는 경우는 극히 드뭅니다. 사전에 모든 경우의 수를 예상할 수 있는 사람은 아무도 없기 때문이죠. 중간에 발생하는 예상치 못한 변수들을 반영하다 보면, 처음에 공들여 만든 계획표는 의미가 없어집니다.
개발팀과 경영진이 모두 만족할 수 있는 방법은 두 가지입니다.
첫째, 극도로 lean하게 계획해야 합니다. 위 커뮤니티를 예로 들면, “회원 탈퇴 기능 없고, 글 수정/삭제 안 되고, 신고 기능 없고, 비밀글 기능 없고, 인기 게시글/공지사항 없고, 관리자 계정 따로 없다!”라고 명시하는 것입니다. 새로운 기능은 2주 뒤 완성되는 제품을 보고 상황 봐서 결정하는 것입니다. 이렇게 하면 계획이 변경될 확률이 많이 줄어듭니다. 크게 변경되기에는 2주 짜리 계획이 무척 작은 단위이기 때문이죠.
둘째, 시간을 넉넉하게 잡아야 합니다. 노벨 경제학상을 받은 다니엘 카네만은 저서 생각에 관한 생각에서 “통상 계획을 시작할 때보다, 그 계획을 실행할 때 전체 기간이 3배 이상 늘어난다”라고 설명합니다. 개발 프로젝트도 비슷합니다. 제가 체감하기로는, 처음 예상보다 기간이 2배 이상 늘어나는 경우가 절반 이상입니다. 따라서 프로젝트를 시작할 때, 예상되는 마감일보다 한두 달 더 뒤로 마감일을 설정해놓는 것이 바람직합니다. 특히 제품이 사업 계획과 맞닿아 있는 경우에는 더 신중해야 합니다.
위 두 방법에 더해, 기획 단계부터 실제 구현을 맡은 개발자들과 소통하는 것도 좋은 방법입니다. 그 과정에서 보안, 서버 비용, 데이터베이스 구조의 한계 등 생각지 못한 변수들을 미리 파악할 수 있을 테니까요.
위에 제시한 방법들은 형식이 짜여진 틀이라기보단, 사고방식에 가깝습니다. 실제로 경영진과 개발팀의 갈등은 ‘방법론의 부재'에서 발생하지 않습니다. 경영진과 개발팀의 사고방식이 크게 다른 게 위험한 것입니다.
3. 마치며
다빈치는 고객과 프로젝트를 진행할 때 소통을 최대한 자주 합니다. 고객과 1~2주에 한 번 대면으로 회의를 하고, 가급적이면 제품을 직접 시연하는 데모 자리를 갖습니다. 그리고 다음 데모까지 어떤 것을 어떻게 개발할지 문서로 정리해서 고객사 및 다빈치 프로젝트 팀 전원에게 공유합니다.
이렇게 공유되는 회의록은 구글 드라이브에 날짜와 함께 누적되어, “이것 어떻게 하기로 했더라?”라는 질문이 생길 때마다 상기할 수 있도록 합니다.
다빈치 팀은 컨설팅의 핵심이 ‘소통'이라고 믿습니다. 말 한 마디로 천 냥 빚을 갚을 수도 있고, 고객의 천 냥을 아껴줄 수도 있습니다.