외주 개발 맡길 때 꼭 읽어보세요
많은 분들이 외주 기획과 개발을 맡기는 이유는 생각보다 단순합니다. 아이디어가 있으신데, 아이디어를 혼자 들고 계시기에는 현실이 벅차니까요. 당장 직원을 뽑을 만큼 확신이 있지 않고, 노코드 툴로 끝내기엔 한계가 보이기 때문이라고 생각합니다. 그렇다고 아무것도 안 하면 시간만 지나가고, 머릿속 아이디어는 더 막연해지죠. 그래서 일단 만들어보자는 결정을 하시게 되고, 가장 현실적인 선택지로 외주가 올라옵니다. 이렇게 결정하신 데에는 나름의 합리성이 있다고 생각합니다. 여러분의 시간을 모두 갈아넣기 전에, 돈으로 시간을 사서 빠르게 형태를 보고 싶다는 마음이실 거라고 생각합니다. 기획도, 개발도 마찬가지입니다.
제가 이걸 왜 알고 있을까요? 제가 그렇게 결정하신 분들을 많이 만나뵙는 외주 기획자거든요. 제가 외주 기획자로서 클라이언트 분을 옆에서 돕다 보면, 많은 분들이 비슷한 고민을 하고 계십니다. 저는 말로만 떠다니는 아이디어를 플로우와 요구사항으로 묶어서, 개발자나 외주사와 같은 그림을 보게 만드는 역할을 합니다. 그래서 외주 개발 프로젝트가 어디에서 흔들리는지, 어떤 지점에서 돈과 시간이 낭비되는지 자주 보게 됩니다. 어떻게 해야 개발을 잘 하는지는 사실 잘 모릅니다. 개발을 어떻게 잘 시키는가보다는, 외주를 맡기시려는 분들이 덜 손해보도록 처음에 합의하셔야 되는 기준에 대해 소개를 드려 보고자 합니다.
한 달 안에 가능할까요?
외주 개발을 맡기실 때 자주 하시는 질문입니다. 사실 저는 이 질문의 순서가 좀 이상하다고 생각합니다. 집을 고친다고 한번 생각해 보죠. 어딜 고칠지, 어느 정도로 바꿀지, 기존 구조는 어떤지에 따라 같은 집이라도 공사 기간은 며칠이 될 수도 있고 몇주가 될 수도 있습니다. 그래서 보통은 먼저 집을 둘러봅니다. 어디를 손볼지, 지금 상태가 어떤지, 예산이 어느 정도인지 살펴본 다음에야 공사가 며칠정도 걸리는지 알 수 있습니다.
외주 개발도 크게 다르지 않습니다. 일정은 가장 마지막에 잡히는 숫자입니다. 그전에 먼저 정해야 하는 것들이 있죠. 그걸 정하지 않고 일정만 먼저 정해버리면, 정해지지 않은 것들이 중간에 끼어들어서 결국 돈과 시간이 낭비되기 시작합니다. 그래서 외주 개발을 맡기실 때, 일정보다는 먼저 정해둬야 하는 것들을 한번 정리해보시길 권해드립니다. 제가 제안하는 것은 다섯 가지인데요, 한번 살펴보시죠.
1. 어디까지가 완료인지 정합니다.
개인적으로는 일을 할 때 싸우지 말자는 주의입니다. 좋게좋게 넘어가면 좋을 텐데, 클라이언트와 개발자 간에 가장 자주 싸우는 말은 사실 이런 것들입니다.
그건 당연히 포함되는 건줄 알았는데요.
이 글을 읽고 계신 구현자분들은 속이 터집니다. ㅠㅠ
이 말을 막으려면, 구현해야 하는 기능의 목록을 길게 늘어놓는 것보다는 완료의 기준을 먼저 정하셔야 합니다.
로그인이라는 기능을 예를 들어 생각해보면, 로그인이라는 단어 하나로 합의가 끝나지 않는 경우가 대부분입니다. 이메일 로그인만 하는지? 카카오/네이버 로그인같은 소셜 로그인도 포함인지, 비밀번호 찾기와 재설정까지 포함인지, 로그인 실패 메시지는 어떤 경우에 어떤 문구로 나가는지, 로그인이 필요한 행동은 어디서 로그인으로 유도하는지.. 제가 지금 머릿속에 떠오르는 것만 줄줄 적어도 끝이 없습니다. 이런 것들이 합의되지 않은 상태에서 '로그인 기능 개발해주세요' 라고 하시면, 각자 머릿속의 로그인이 다릅니다. 이런 것들이 쌓여서 일정이 무너지고, 비용도 늘고, 감정이 상해서 결국 끝이 안 좋아진다고 생각합니다.
여기서 가장 간단한 방법은 포함/불포함을 문장으로 적어보시는 겁니다. 예를 들면 이런 식으로 목록화해보실 수 있습니다.
- 이번 범위의 로그인은 이메일과 비밀번호만 포함하고, 소셜로그인은 제외한다.
- 비밀번호 재설정은 이메일 발송 및 재설정까지 포함한다.
- 로그인 실패 시에는 입력값 검증과 오류 문구 표기까지 포함한다.
- 게스트 이용이 가능하다. (또는 불가능하다)
이정도만 적어도 프로젝트 완료의 경계가 생기고, 이 기준이 여러분의 일정과 비용을 지켜줍니다.
2. 무엇을 이번에 할지, 무엇을 다음으로 미룰지 정합니다.
쓰다보니 외주 개발이 망하는 비법만 골라서 소개드리고 있는 것 같네요. 외주 개발이 망하는 방식 중 하나는, 초기에는 다들 가볍게 MVP만 만들자고 하셨다고, 중간부터 갑자기 '이것도 있어야 할 것 같아요' 가 계속 붙는 것입니다. 제발 욕심을 버려주세요.ㅠㅠ
이건 여러분이 나쁜 사람이라서가 아니라고 말씀드리고 싶습니다. 서비스를 생각하다 보면 욕심이 자연스럽게 붙습니다. 저도 외주 기획을 도와드리면서, 제 사업이 아닌데도, 계속 욕심이 생기거든요. 문제는 이 욕심을 받아줄 구조가 없는 상태에서 진행이 시작된다는 점입니다.
그래서 외주를 맡기시기 전에는 기능을 반드시 세 타입으로 나누어보시는 편이 좋습니다. 이번(MVP), 다음(차기), 나중(보류) 로요. 이렇게 세 타입으로만 나눠보셔도 프로젝트가 아주 건강해집니다.
예를 들어 결제 기능을 생각해보면, MVP에서 꼭 필요하신 건 아마 '결제가 된다' 라는 사실이실것 같습니다. 결제 화면이 예쁘고, 쿠폰이 있고, 영수증이 자동으로 발송되고, 구독 기간이 멋지게 표시되는 것은 아니실 수도 있어요.
- 이번(MVP): 결제 1회 성공/실패 처리 + 이용권 부여
- 다음(차기): 쿠폰/프로모션, 환불 정책 화면화
- 나중(보류): 고급 통계, 다양한 결제 수단 추가
이렇게 나눠두시면 중간에 기능이 추가되려 할 때 기준이 생깁니다. 이 기능이 정말 MVP에 필수적인지, 필수면 다른 어떤 것을 뺄 지 정할 수 있습니다. 정해진 일정에 할일을 무제한으로 추가할 수는 없습니다. 어떤 것을 추가하면, 다른 것을 반드시 빼셔야 합니다. 이 대화가 가능한 팀이면 무리한 일정에도 무너지지 않습니다.
3. 잘 된 거 맞아? '잘 됐다'의 판정 기준을 정합니다.
제가 본 프로젝트 중에서 가장 안타까운 경우 중에 하나인데요. 바로 끝나지 않는 프로젝트입니다. 이 경우는 개발이 덜 끝나서가 아니라 끝났다는 기준이 없는 경우입니다. 작동은 하는데 뭔가 이상하다, 원래 내가 생각한건 이런 느낌이 아니다(ㅜㅜ) 라는 대화가 시작되는 순간.. 아주 안타까운 일들이 벌어집니다.
이것을 방지하는 방법은 생각보다 간단합니다. 각 기능마다 '이렇게 되면 통과이다' 라고 말할 수 있는 기준을 짧게 적어보세요. 예를 들어 결제 기능이라면 이런 것들이 기준이 됩니다.
- 결제 성공 시: 결제 완료 화면 노출 + 이용권 활성화
- 결제 실패/취소 시: 실패 안내 화면 노출 + 재시도 버튼 제공
- 결제 완료 후 뒤로가기/새로고침 시: 실제 결제 상태 기준으로 화면이 일관되게 보임
- 결제 성공했는데 화면만 실패로 보이는 상황이 생기면: 결제 내역에서 최종 상태를 확인 가능
여기서 포인트는 그냥 기능이 된다는 사실이 아니라, 사용자가 실제로 겪는 흐름 기준으로 문장을 쓰는 것입니다. 로그인도 마찬가지입니다.
- 로그인 실패 시 어떤 문구가 뜨는지
- 입력값이 잘못됐을 때 어떤 강조가 되는지
- 로그인 후 원래 보던 화면으로 돌아가는지
이런 기준들이 있으시면, 장담하건대, 자리를 비우시고 다른 업무를 보셔도 개발이 알아서 잘 돌아갈 겁니다. 아주 편해지실 거에요.
4. 바뀌면 어떻게 처리될지 정합니다.
이 말을 어떻게 받아들이실지 모르겠습니다만, 저는 프로젝트를 시작할 때마다 디자이너와 개발자께 늘 양해를 구합니다. 뭐라고 말씀드리냐면요, 요구사항이 바뀔 수 있다고요. 그래서 거듭 수정 요청을 드릴 수 있다고요. 죄송합니다. 하지만 좀 세게 말씀드리면, 기획이 바뀌지 않는 프로젝트는 망한 프로젝트라고 생각합니다. 제품은 처음 생각한 대로 만들어지지 않습니다. 대규모 프로젝트는 중간에 더 나은 방법이 보여도 수정하기 어려운 구조이기 때문에 형식적으로 진행될 수도 있습니다. 하지만 프로젝트의 초기 단계일 수록, 검증은 꼭 필요합니다. 개발 과정에서 발견되는 문제도 있을 수 있고요, 실제 사용자 피드백이 예상과 다를 수 있습니다.
이렇게 요구사항이 바뀌는 것은 정상이고 건강한 상황이라고 생각합니다. 문제는 룰 없이 바뀌는 것입니다. 서비스를 생각하다 보면 더 좋은 흐름이 떠오르고, 사용자 관점에서 고쳐야 할 지점도 생깁니다. 그렇다면 그 변화가 비용과 일정에 어떤 영향을 주는지 합의할 수 있는 구조가 필요합니다. 여기서 두 갈래로 생각해보실 수 있습니다.
첫째, 변경 요청은 문서 또는 문장으로 남깁니다. 구두로만 오가면 기록이 남지 않고, 나중에는 '원래 그렇다' 라는 무책임한 상황이 되어버립니다. 둘째, 변경은 경미한 수정의 건과 재진행 건으로 구분합니다. 예를 들면,
- 경미한 수정: 문구 수정, 버튼명 변경, 화면 내 구성 일부 변경
- 재진행: 핵심 플로우 변경, 기능 추가로 화면/데이터 구조가 바뀌는 수준, 권한 체계 변경
이런 정도의 구분만 있어도 끝없는 수정 지옥으로 흐르는 것을 막을 수 있습니다. 그리고 변경이 발생하면 추가 비용과 일정을 재합의하는 것이 자연스러운 흐름입니다.
5. 출시 이후를 정합니다.
가장 현실적인 부분입니다. 고생고생~해서 제품을 다 만들고 출시했는데요. 지금부터가 시작입니다. 출시일부터 운영이 시작됩니다. 이때 인수인계가 없으면 서비스가 바로 멈춰버릴 가능성이 높습니다. 도메인, 서버, 배포, 환경변수, 관리자 계정, 결제 키 같은 운영에 필요한 정보들은 누군가 알아야 돌아갑니다. 그래서 처음부터 인수인계와 유지보수를 고려하시고 이런 것들을 합의해두시는 편이 좋습니다.
- 소스코드는 어디에 있는지, 접근 권한은 누구에게 있는지
- 배포는 어떻게 하는지(어떤 계정, 어떤 절차)
- 서버/DB/스토리지 계정은 누구 명의인지
- 운영 중 장애가 나면 어디를 먼저 확인해야 하는지
- 납품 후 버그 수정은 어디까지 무상인지, 어느 시점부터 유상인지
외주는 합의를 구매하시는 것입니다
외주 개발은 개발자만 구매하시는(?) 일이 아닙니다. 리스크를 줄이는 합의를 같이 구매하시는 일에 가깝습니다.
일정은 중요합니다. 하지만 일정은 앞의 합의가 만들어낸 결과입니다. 범위와 완료 정의가 되어 있고, 우선순위가 정리되어 있고, 판정 기준이 있고, 변경 룰이 있고, 인수인계와 운영이 정리되어 있으면 현실적으로 일정을 산정하실 수 있습니다. 반대로 이 다섯 가지가 없으면 프로젝트가 중간에 무너지기 쉽습니다.
개발 외주를 처음 맡기신다면, 도와줄 기획자가 없고 혼자 기획을 하셔야 한다면, 이 글에서 제안드리는 다섯 가지를 정리해보시는 것을 권장드립니다. 이 정도만 정리해서 외주사에게 전달해도 대화의 수준이 바뀌고, 질문의 종류가 달라지고, 불필요한 손실을 줄일 수 있습니다.