나는 외주 개발도 해보고, 개발사 소속으로도 일해봤다.
그리고 그 둘 사이에서 창업자들과 부딪히는 순간들을 수도 없이 겪었다.
가장 많은 실패 패턴은 이거다.
"믿을만한 개발사에 맡겼는데, 원하는 게 안 나왔다."
처음엔 분위기가 좋다.
기획이 다 준비돼 있다고 하고, 개발사도 “이 정도면 가능합니다”라고 답한다.
견적이 나오고 계약이 진행된다.
그리고 세 달쯤 뒤, 둘 중 하나는 사라지거나 서로를 탓하고 있다.
개발자가 게을러서도 아니고, 대표가 무능해서도 아니다.
문제는 개발사와 스타트업 사이의 ‘구조’ 자체가 잘못 설계되어 있다는 것이다.
개발사는 기본적으로 ‘외주 회사’고, 스타트업은 ‘아이디어에 목숨 건 사람들’이다.
이 둘은 같은 언어를 쓰지 않고, 같은 목표를 향해 달리지도 않는다.
그걸 잊고 시작하는 순간, 프로젝트는 서서히 무너지기 시작한다.
처음부터 망한다고 느껴지는 건 아니다.
오히려 초반에는 다들 흥분되어 있다.
기획자 쪽에서는 “기대 이상으로 잘 나온다”는 얘기가 오가고,
개발사는 “클라이언트가 유능해서 일하기 편하다”고 생각한다.
그런데 2주가 지나고, 3주가 지나고 나면
피그마에서 바뀌는 화면이 생기기 시작하고,
요구사항이 조금씩 늘어나고,
“이건 당연히 들어가는 거 아닌가요?”라는 말이 등장한다.
이때부터 관계는 서서히 변질된다.
| 계약 직후 | “좋은 파트너를 만난 것 같아요” (상호 신뢰) |
| 1~2주차 | “피드백은 빠르지만 정리가 덜 됐다” (개발사 시선) |
| 3~4주차 | “이게 왜 안 돼요?” (기획자 시선) |
| 5~6주차 | “이건 원래 안 하기로 했던 건데요” (개발사 시선) |
| 6주 이후 | “그냥 이대로라도 마무리해주세요” (혼란 or 포기) |
이건 실제로 수많은 프로젝트에서 거의 똑같이 반복된다.
바뀌는 건 사람 이름과 서비스 이름뿐이다.
이런 구조가 만들어지는 이유는 간단하다.
스타트업은 비전을 가지고 움직이고, 개발사는 계약서를 기준으로 움직인다.
기획자 입장에서 “이건 너무 당연한 기능”이 개발자에겐
**“계약서에 없으니 무상으로 할 수 없는 추가 요청”**이다.
반대로, 개발자가 “이 기능은 구현이 어렵습니다”라고 말할 때,
기획자는 “그럼 처음에 왜 된다고 했어요?”라고 되묻는다.
하지만 처음 견적을 뽑을 때는 대부분
“이 기능은 대충 이런 거겠지”라는 전제와 추정 위에 계산이 된다.
그 ‘추정’이 엇갈리면 그때부터 문제가 발생한다.
개발사는 책임질 수 있는 범위 안에서만 움직이려고 한다.
그건 맞는 방향이다.
왜냐하면 그 범위 밖은 예측할 수 없는 리스크의 영역이기 때문이다.
반면 창업자는 아직 모든 게 유동적이다.
고객 반응에 따라 기능이 바뀌고, 시장 상황에 따라 방향이 전환된다.
그런데 그 유동성을 개발사에게 강요하면
개발사는 프로젝트가 아니라 손실을 막는 게임에 들어간다.
이걸 방지하려면 애초에 역할과 기대치를 명확히 해야 한다.
다음 표처럼.
| 목표 | 시장에 통하는 제품 만들기 | 계약된 기능을 문제없이 납품하기 |
| 일정 | 상황에 따라 유동적 | 계약된 기간을 최대한 준수 |
| 요구사항 | 고객 피드백 따라 계속 바뀜 | 고정된 명세 기준으로 개발 |
| 커뮤니케이션 | 수시로 피드백 주고 받고 싶음 | 확인된 내용만 반영하고 싶음 |
| 책임 기준 | 기대에 못 미치면 실패 | 계약대로 납품하면 완료 |
이게 맞고 틀리고의 문제가 아니라,
구조가 다르다는 걸 인정하지 않으면 결국 둘 다 상처받는다.
개발사와 손잡고 망하는 스타트업의 대부분은
“우리가 원하는 걸 잘 말했는데, 왜 그들은 그대로 안 했지?”라고 생각한다.
개발사는 “말한 것만 했는데 왜 자꾸 변하죠?”라고 생각한다.
그래서 나는 이런 말을 자주 한다.
개발사와의 협업은 ‘사람’을 보는 게 아니라 ‘구조’를 설계해야 한다.
계약 전에 이런 준비가 안 되어 있다면, 협업은 실패한다.
| ① 핵심 기능을 5개 이내로 요약했는가 | ✅ / ❌ |
| ② 수정 가능성과 방향 전환 가능성을 계약에 포함했는가 | ✅ / ❌ |
| ③ 커뮤니케이션 주기와 도구를 정했는가 | ✅ / ❌ |
| ④ 피드백 반영 범위(횟수/형태)를 명확히 했는가 | ✅ / ❌ |
| ⑤ '완성'의 기준을 정하고 문서화했는가 | ✅ / ❌ |
이 5개 중 3개라도 빠져 있다면,
그 프로젝트는 개발자나 개발사 탓으로 끝나기 쉽다.
사실은 구조가 틀렸던 건데.
나는 개발자고, 지금도 스타트업과 일한다.
내가 원하는 건 멋진 파트너가 아니라
명확하게 정리된 목표와 역할 분배다.
그리고 그것만 있으면
개발사와 손잡아도, 절대 망하지 않는다.
문제는 사람이 아니라, 구조다.
'개발자 일기 > 좌충우돌 주니어 개발자 도전기' 카테고리의 다른 글
| Chapter 3. 기획서는 있는데 왜 계속 오해가 생길까 (0) | 2025.05.12 |
|---|---|
| The Ways To Wealth (1) | 2025.05.12 |
| Chapter 1. 개발은 의외로 제일 마지막에 해야 할 일이다 (0) | 2025.05.10 |
| S교육원(가칭) 타겟 프로모션 플랫폼 별 특징 정리 (2) | 2025.05.10 |
| 포트폴리오 (0) | 2025.05.02 |