클라이언트도, 개발팀도 열심히 했는데 왜 프로젝트는 망했을까

한줄 요약

모두가 제 역할을 다했는데도 프로젝트가 실패하는 건, 각자의 합리가 사용자의 감정과 어긋나는 방향으로 정렬됐기 때문이다.

외주 개발을 진행하다 보면 이상한 실패를 자주 마주친다. 클라이언트는 충분히 준비했고, 개발팀은 스펙대로 구현했으며, 일정도 대략 지켜졌다. 그런데 출시한 제품은 아무도 쓰지 않는다. 범인을 찾으려 해도 딱히 손가락 하나를 지목하기가 어렵다. 그 불편한 이유를 이 글에서 풀어본다.

검증된 레퍼런스가 오히려 함정이 되는 이유

외주 개발 의뢰가 시작될 때 가장 자주 나오는 말이 있다. "저쪽 서비스 보셨죠? 그거랑 비슷하게 만들어 주세요." 잘 만들어진 서비스를 참고하겠다는 건 당연한 접근처럼 보인다. 문제는 레퍼런스로 가져오는 게 대부분 그 서비스의 '화면'이라는 점이다.

그 서비스가 왜 사용자를 붙들었는지, 어떤 감정적 연결고리를 만들었는지는 화면 캡처 어디에도 담겨 있지 않다. 기능 목록은 복제할 수 있지만, 사람이 그 서비스를 열게 만드는 이유는 복제되지 않는다. 결과만 보고 원인을 건너뛴 채 만들면, 겉모양은 닮았지만 아무도 쓰지 않는 제품이 나온다.

개발 외주를 받는 입장에서도 이 지점을 제대로 짚지 못하면 공범이 된다. "요구사항 그대로 다 만들었습니다"는 납품의 근거가 될 수 있어도, 프로젝트 성공의 근거는 되지 않는다.

각자의 합리가 모이면 왜 어긋나는가

외주 개발 프로젝트에는 보통 여러 명의 판단이 층층이 쌓인다. 클라이언트 측 의사결정자는 시장 트렌드와 경쟁사 동향을 보고 방향을 잡는다. 실무 담당자는 그 방향 안에서 자사 강점을 접목할 방법을 찾는다. 개발팀은 그 내용을 받아 가장 효율적인 구현 경로를 짠다.

각 단계에서 내려진 판단은 개별적으로 보면 전부 합리적이다. 그런데 그 합리들이 연결되는 과정에서 한 가지가 빠진다. '이 서비스를 실제로 쓸 사람이 어떤 맥락에서, 어떤 감정으로 이걸 열게 될까'라는 질문이다.

이 질문은 회의 테이블에서 잘 등장하지 않는다. 숫자로 표현하기 어렵고, 검증하는 데 시간이 걸리며, 일정표에 항목으로 잡히지도 않기 때문이다. 그 빈자리를 기능 명세와 WBS가 채운다. 그렇게 문서는 두꺼워지는데 정작 핵심은 비어 있는 채로 개발이 시작된다.

"착실하게 일하고 있다"는 감각이 경고를 가린다

외주 개발 과정에서 가장 조심해야 할 순간은 '우리 잘 가고 있는 것 같은데'라는 감각이 팀 전체를 감쌀 때다.

스프린트마다 기능이 완성되고, 체크리스트 항목이 지워지고, 중간 보고 자료가 깔끔하게 정리된다. 이 모든 절차가 "제대로 진행되고 있다"는 느낌을 만들어 낸다. 그런데 그 느낌이 가장 중요한 질문을 덮어버린다. 우리가 지금 만들고 있는 것이 실제 사용자의 상황과 맞닿아 있는가.

기능을 더하는 일에도 같은 함정이 있다. 하나씩 얹을 때마다 '진척'이라는 감각이 생긴다. 그런데 막상 출시하면 기능은 많은데 쓰는 사람이 없고, 그 많은 기능은 고스란히 유지보수 부담으로 남는다. 절차가 통찰의 자리를 대신 차지한 결과다.

---

개발 외주에서 이 문제가 특히 자주 터지는 이유가 있다. 클라이언트와 개발팀 사이에 거리가 있기 때문이다. 사용자에 대한 이해가 클라이언트 쪽에 있고, 구현 역량은 개발팀 쪽에 있는데, 둘을 연결하는 언어가 주로 '기능 목록'이다. 기능 목록은 무엇을 만들지는 말해줘도 왜 그게 사용자에게 의미 있는지는 말해주지 않는다.

빠르게 만들어 검증한다는 방식의 맹점

요즘은 빠르게 시제품을 만들어 시장에 던지고 반응을 보며 고쳐나가는 방식이 거의 공식처럼 통한다. 툴도 좋아졌고 속도도 빨라졌다. 개발 외주 비용도 예전보다 낮아졌으니, 일단 만들어 보고 반응에 따라 방향을 잡으면 된다는 논리는 얼핏 타당하다.

그런데 이 방식에는 잘 이야기되지 않는 전제가 하나 있다. 쳐내려면 기준이 있어야 한다는 것이다. 시제품 열 개를 만들어 던지면 지표 열 개가 나온다. 그중 어떤 게 진짜 신호이고 어떤 게 그냥 초기 호기심인지, 이 반응이 진짜 원해서인지 새로워서인지 판단하는 눈이 없으면 숫자는 그냥 숫자로 쌓일 뿐이다.

그 눈은 어디서 오는가. 결국 사용자를 직접 겪어본 데서 온다. 실제로 쓰는 사람이 어떤 흐름 속에서 이 서비스를 접하는지, 어느 지점에서 이탈하고 어느 순간에 만족하는지를 몸으로 아는 것. 이게 없으면 빠른 빌드는 빈 가정을 더 빠르게 찍어내는 도구가 될 뿐이다.

외주 개발에서 이 문제를 실제로 줄이는 방법

완벽한 해법은 없다. 그러나 반복되는 실패 패턴에서 공통적으로 빠져 있는 것은 분명하다.

첫째, 기획 단계에서 '사용자가 이걸 어떤 상황에서 열까'를 명세서 항목이 아닌 실제 시나리오로 써보는 일이다. 어떤 감정 상태에서, 어떤 대안을 놔두고 이 서비스를 선택하는가를 구체적으로 그려봐야 한다.

둘째, 클라이언트와 개발팀이 함께 실제 사용자 인터뷰나 테스트를 최소 한 번은 같이 보는 것이다. 문서로 전달된 사용자 피드백과 직접 들은 피드백은 전혀 다른 정보다.

셋째, 개발팀이 납품 전에 "이 기능이 어떤 맥락에서 어떤 감정을 만들어야 하는가"를 클라이언트에게 되묻는 것을 당연한 프로세스로 넣는 것이다. 이 질문 하나가 방향이 어긋나기 직전에 팀을 멈추게 만든다.

논리로 결정을 내리더라도 그 결정의 끝에서 반응하는 건 사람의 감정이다. 외주 개발이 성공하려면 기능 명세와 일정만큼이나 이 감정의 회로를 이해하는 과정이 프로젝트 안에 들어와 있어야 한다.