외주 개발이 실패하는 이유를 추적해 보면 놀라울 만큼 자주 "킥오프 미팅에서 합의가 안 됐다"는 공통점이 나와요. 계약서는 멀쩡해요. 개발사도 나쁘지 않아요. 그런데 프로젝트가 시작된 지 3~4주 만에 "생각했던 것과 다르다", "우선순위가 안 맞는다", "소통이 답답하다"는 소리가 나오기 시작하죠.
원인은 단순해요. 킥오프 미팅이 "일정 공유"로 끝나버렸기 때문이에요. 서로 인사하고, 개발 일정 쓱 훑고, Slack 채널 만들고 끝. 그 미팅에서 잡혀야 했던 10가지 합의가 전부 뒤로 밀렸고, 그 공백이 나중에 분쟁이 됩니다. 이 글은 포텐랩이 최근 2년간 성공·실패한 프로젝트 200여 개를 분석해 뽑은 킥오프 미팅 첫 주에 반드시 합의해야 할 10가지 체크리스트예요.
"잘 만들어주세요"는 기준이 아니에요. "월 1만 명 사용자를 수용하는 성능", "Lighthouse 모바일 점수 85점 이상", "결제 성공률 99.5% 이상" 같은 측정 가능한 지표 3~5개를 첫 주에 합의해야 해요. 이게 없으면 검수 단계에서 "이 정도면 된 거 아닌가요?"와 "부족하다"가 부딪힙니다.
발주사 쪽에서 "최종 승인은 누가 하는가"가 미팅에서 명시돼야 해요. 대표 혼자인지, CTO와 공동인지, 디자인은 디자이너가 별도로 승인하는지. 이걸 안 정하면 개발사는 "A님께 드렸는데 B님이 뒤집으셨다"는 상황에서 진퇴양난에 빠져요. 예: 기능 승인=대표, UI 승인=디자이너, 기술 설계 승인=CTO, 이런 식으로 영역별로 명확히.
IT 외주 커뮤니케이션 완전 가이드에 더 디테일한 패턴이 있어요.
"개발 중에 기능 추가하고 싶어질 때" 어떻게 처리할지가 체크리스트 4번이에요.
이걸 안 정하면 "작은 수정인데 왜 돈을 내야 해?" vs "이건 원래 범위 밖이에요"가 매주 반복됩니다.
킥오프 첫 주에 반드시 발주사 소유의 Git 저장소(GitHub/GitLab)에 개발사가 Push 권한을 받는 구조를 세팅하세요. 개발사의 저장소에 코드가 쌓이다가 검수 후 넘겨받는 방식은 위험해요. 중간에 분쟁이 생기면 코드를 볼모로 잡히거든요. 배포 환경(Vercel, AWS, Cloudflare)도 발주사 계정에 두고 개발사를 Collaborator로 추가하는 게 맞아요.
Supabase, Firebase, OpenAI API, 토스페이먼츠, Cloudflare 등 외부 서비스의 월 예상 비용 상한선을 미리 계약서 별첨에 넣어야 해요. 초과 예상 시 개발사가 최소 7일 전에 서면 고지하는 프로세스도 명시하세요. Firebase €54k 유출 사고나 LLM 토큰 폭탄 같은 일은 이 한 줄로 대부분 예방됩니다.
많은 분쟁이 "디자인이 포함되는 줄 알았는데 안 됐다"에서 시작해요. 첫 주에 다음을 합의하세요.
"테스트는 포함돼 있나요?"라는 질문의 답은 대부분 "어느 정도는요"예요. 이건 답이 아니죠. 첫 주에 구체적으로 합의하세요.
외주 개발 QA 완전 가이드에 체크리스트 템플릿이 있어요.
프로젝트 종료 시점에 발주사가 받아야 할 자료 목록을 첫 주에 못박아두세요.
이걸 안 정해두면 프로젝트 종료 후 "다큐멘테이션이 부족해서 다른 개발사가 인수 불가"라는 상황이 벌어져요.
많은 분쟁이 "하자 담보 기간 1개월 vs 요청 건 전부 유상"이라는 애매함에서 터져요. 킥오프에서 다음을 확정하세요.
이 부분은 개발 완료 후 유지보수 계약 가이드에서 심화 정리했어요.
1시간으론 턱없이 부족해요. 2~3시간짜리 워크숍 형태로 잡으세요. 중간에 식사 한 끼 같이 하면 이후 소통 퀄리티가 확 달라집니다.
자유 서술형 의사록은 나중에 해석이 갈려요. 위 10개 체크리스트를 표로 만들고, 각 항목의 합의 내용을 한 줄로 남기세요. 양쪽이 서명(혹은 Notion에서 승인 체크)한 뒤 계약서 부속 문서로 편철합니다.
킥오프에 대표가 빠지고 실무자만 참석하면, 합의한 내용이 나중에 뒤집힙니다. 대표·CTO·디자인 리드·개발사 PM·시니어 개발자 전원이 참석해야 해요. 일정 맞추기 어려우면 한 번 더 연기하는 게 낫습니다.
개발을 곧바로 시작하지 말고, 첫 5일은 소통 채널·Git 세팅·환경 구축·위 10개 체크리스트 확정에 쓰세요. 이 일주일이 프로젝트 성공률을 체감상 2배로 끌어올려요.
2025년 가을, 서울의 한 커머스 스타트업은 모바일 앱 외주를 발주했어요. 킥오프에서 "빠른 앱 만들어주세요"라고만 합의했고, 구체적인 숫자는 없었습니다. 런칭 후 LCP가 4.2초가 나왔고, 발주사는 "너무 느리다", 개발사는 "이게 일반적 수준이다"라고 다퉜어요. 결국 6주간 성능 재작업을 무상으로 진행했지만, 그 사이 마케팅 캠페인이 취소돼 기회비용 3천만 원이 날아갔습니다.
2026년 초, 한 핀테크 스타트업은 개발사가 자체 GitLab에서 코드를 관리하도록 했어요. 3개월 뒤 납품 시점에 개발사가 "잔금 미지급"을 이유로 코드 이관을 거부했고, 결국 잔금을 먼저 지급한 뒤에야 코드를 받았어요. 킥오프 첫 주에 발주사 GitHub에 Push 권한만 세팅했어도 예방 가능한 일이었죠.
포텐랩은 97% 수행완수율로 스타트업의 MVP·리뉴얼·AI 기능 통합 프로젝트를 진행해요. 그 높은 성공률의 비밀은 복잡한 개발 역량이 아니라 킥오프 첫 주 워크숍 · Notion 기반 투명한 진행 · 주간 진행률 공개 리포트에 있어요. 계약 전 무료 상담에서 위 10개 체크리스트 템플릿을 받아볼 수 있고, 진행 중인 프로젝트가 있다면 현재 상태를 위 기준으로 진단도 해드립니다.
외주 개발은 "돈을 주고 일을 맡기는 것"이 아니라 "3~6개월간 운명 공동체를 만드는 것"이에요. 그 운명은 첫 주에 결정됩니다. 포텐랩 무료 상담에서 2026년 버전 킥오프 체크리스트 템플릿을 받아 가세요. RFP 작성 가이드와 계약서 독소조항 가이드까지 같이 읽으시면 외주 개발의 전 주기가 한눈에 들어옵니다.
"잘 만들어주세요"는 기준이 아니에요. "월 1만 명 사용자를 수용하는 성능", "Lighthouse 모바일 점수 85점 이상", "결제 성공률 99.5% 이상"처럼 측정 가능한 지표 3~5개를 첫 주에 합의해야 해요. 이게 없으면 검수 단계에서 "이 정도면 된 거 아닌가요?"와 "부족하다"가 부딪힙니다.
변경 관리 프로세스를 킥오프에서 미리 정해두면 돼요. 변경 요청서(CR) 템플릿, CR 접수 후 견적 산출까지 걸리는 시간(예: 3영업일), 발주사 승인 후 반영까지의 기간(예: 다음 스프린트), 월 누적 몇 MD까지 무상으로 흡수할지(예: 2MD 이하 무상)를 합의하세요. 이걸 안 정하면 "작은 수정인데 왜 돈을 내야 해?"와 "이건 원래 범위 밖이에요"가 매주 반복됩니다.
킥오프 첫 주에 발주사 소유의 Git 저장소(GitHub/GitLab)에 개발사가 Push 권한을 받는 구조로 세팅하세요. 개발사의 저장소에 코드가 쌓이다가 검수 후 넘겨받는 방식은 중간에 분쟁이 생기면 코드를 볼모로 잡힐 수 있어 위험해요. 배포 환경(Vercel, AWS, Cloudflare)도 발주사 계정에 두고 개발사를 Collaborator로 추가하는 게 맞아요.
최종 소스코드(모든 브랜치)와 저작권 양도 각서, README 및 운영 매뉴얼, 아키텍처 다이어그램, API 명세서(Swagger/Postman 컬렉션), 데이터베이스 ERD와 마이그레이션 파일, 제3자 서비스 계정·API 키 인수 목록, 알려진 이슈와 기술 부채 목록이에요. 이 목록을 첫 주에 못박아두세요. 안 정해두면 종료 후 "다큐멘테이션이 부족해서 다른 개발사가 인수 불가"라는 상황이 벌어져요.
최소 6개월 이상을 권장하고, 12개월이 국제 표준이에요. 기간만 정하지 말고 하자 범위(기능 결함, 보안 취약점, 성능 저하)와 유상 유지보수 시 월 MD·응답시간 SLA·장애 대응 시간, 유지보수 종료 시 운영 이관 절차까지 킥오프에서 확정하세요. "하자 담보 기간 1개월 vs 요청 건 전부 유상" 같은 애매함이 분쟁으로 터지거든요.
1시간으론 턱없이 부족해요. 2~3시간짜리 워크숍 형태로 잡으세요. 대표·CTO·디자인 리드·개발사 PM·시니어 개발자가 전원 참석해야 하니, 일정 맞추기 어려우면 한 번 더 연기하는 게 낫습니다.