"이게 제가 말씀드린 것과 다른데요."
납품받은 결과물 앞에서 이 말을 해본 적이 있다면, 이 글이 도움이 될 것입니다.
분명히 설명했습니다. 화면을 보여주며 이야기했고, 경쟁사 링크도 전달했고, 카카오톡으로 주고받은 대화만 해도 수십 개가 넘습니다. 그런데 결과물은 머릿속에 그린 것과 전혀 다른 방향으로 만들어져 있습니다. 답답함을 넘어 황당한 기분마저 듭니다.
더 이상한 건 그다음입니다. 설명을 추가할수록 상황이 나아지기는커녕 더 엉켜갑니다. "이렇게 바꿔달라"고 했더니 저쪽을 고치고, "아 그게 아니라 이쪽도요"라고 하면 처음 버전으로 돌아가고. 어느 순간부터는 무엇이 원래 요청이었는지조차 흐려집니다.
이 상황에서 많은 발주자들이 자책합니다. "내가 설명을 못하는 건가?", "개발 용어를 알아야 제대로 전달할 수 있는 건가?" 하지만 이건 소통 능력 문제가 아닙니다.
이전 글 왜 '알아서 해주세요'는 외주 프로젝트를 망치는 주문일까?에서 "알아서 해주세요"가 왜 위험한지 다뤘습니다. 이 글은 그 다음 단계입니다. 구체적으로 설명하려 했는데도 왜 어긋나는지, 그리고 그 간극을 어떻게 줄일 수 있는지를 정리합니다.
왜 추가 설명할수록 꼬일까
말로 하는 전달에는 구조적 한계가 있습니다.
발주자가 머릿속에 그린 그림은 꽤 구체적입니다. 화면의 레이아웃, 버튼을 눌렀을 때 어떤 흐름으로 이어지는지, 특정 상황에서 어떤 메시지가 떠야 하는지까지. 하지만 그 그림을 말로 꺼내는 순간, 상당 부분이 증발합니다.
개발사 담당자는 그 불완전한 말을 듣고 다시 자기 방식으로 그림을 만듭니다. 그 그림은 발주자의 것과 다릅니다. 문제는 양쪽 모두 이 사실을 모른다는 점입니다. 발주자는 "충분히 설명했다"고 생각하고, 개발사는 "이해했다"고 생각합니다.
추가 설명을 할 때 상황이 더 꼬이는 이유도 같습니다. 이미 개발사 머릿속에 만들어진 그림 위에 새 조각을 붙이려다 보니, 어느 시점부터는 맞지 않는 퍼즐 조각들이 쌓입니다. 처음부터 같은 그림을 보고 있지 않으면, 말로 그 간격을 메우는 데는 한계가 있습니다.
카카오톡 대화 100개가 문서 1페이지를 이기지 못하는 이유입니다.
이건 소통 능력 문제가 아니다
"설명을 잘 못해서 이렇게 됐다"고 생각하기 쉽지만, 그렇지 않습니다. 설명 능력이 뛰어난 사람도 같은 상황에 빠집니다. 문제는 프로세스 부재입니다.
요구사항이 어떤 형식으로든 명문화되어 있어야 하고, 그 내용을 개발사가 자체적으로 해석해서 구조화한 뒤, 발주자에게 다시 확인받는 루프가 있어야 합니다. 이 과정 없이 진행되면, 아무리 충분히 설명해도 중간에 어긋날 수밖에 없습니다.
대부분의 문제는 계약 전이나 킥오프 직후에 이 확인 루프가 빠진 채 개발이 시작될 때 발생합니다. 그리고 그게 잘못되었다는 사실은 결과물이 나왔을 때야 비로소 드러납니다.
좋은 외주 파트너는 발주자가 모호하게 전달해도 그걸 구조화해서 되묻습니다. "이렇게 이해했는데 맞나요?"라는 단계가 있어야 합니다. 이 단계가 없다면, 개발이 시작되기 전에 이미 어긋나기 시작한 겁니다.
발주자가 할 수 있는 최소한의 정리법
개발 용어를 몰라도 됩니다. 요구사항을 정리하는 데 기술 지식은 생각보다 많이 필요하지 않습니다.
가장 실용적인 방법 두 가지를 소개합니다.
첫 번째: 사용자 이야기 방식
"누가, 무엇을, 왜" 형식으로 기능을 한 줄씩 적는 방법입니다. 예를 들면 이런 식입니다.
- 구매자가 결제를 완료하면, 주문 내역을 이메일로 받을 수 있다
- 관리자가 주문 상태를 변경하면, 구매자에게 알림이 간다
- 판매자가 재고를 0으로 설정하면, 해당 상품은 품절로 표시된다
완벽하지 않아도 됩니다. 중요한 건 기능 하나하나를 사람의 행동 단위로 쪼개는 것입니다. 이렇게 정리하면 빠진 케이스나 모순이 눈에 보입니다. 개발사 입장에서도 무엇을 만들어야 하는지가 명확해집니다.
두 번째: 화면 흐름 방식
화면 단위로 흐름을 그리는 방법입니다. 복잡한 다이어그램 도구 없이도 충분합니다. 종이에 직접 박스를 그리거나, 피그마 같은 도구를 써도 좋지만, 스마트폰으로 화이트보드를 찍어서 전달하는 것도 생각보다 효과적입니다.
"로그인 → 대시보드 → 주문 목록 클릭 → 주문 상세 → 취소 버튼 클릭 → 확인 팝업 → 취소 완료 페이지"
이런 흐름을 화면별로 정리하면, 놓친 분기나 예외 상황이 드러납니다. "취소했을 때 이미 배송이 시작된 경우는?"처럼요. 이런 질문이 개발 중간에 나오는 게 아니라 시작 전에 나와야 합니다.
두 방법 중 어느 것이든, 작성하면서 "이건 어떻게 되지?"라는 질문이 자꾸 나온다면 잘 하고 있는 겁니다. 그 질문들이 바로 개발사와 합의해야 할 지점들입니다.
개발사가 구조적으로 받아줘야 하는 이유
요구사항 정리가 전적으로 발주자 몫일 수는 없습니다.
비개발자가 정리한 내용은 필연적으로 모호한 부분이 있고, 기술적으로 불가능하거나 다른 방식이 더 나은 경우도 있습니다. 좋은 개발사는 그걸 받아서 구조화하고, 다시 발주자가 이해할 수 있는 형태로 돌려줍니다.
구체적으로는 이런 식입니다. 발주자가 대략의 기능 목록을 전달하면, 개발사가 그걸 기능 단위로 쪼갠 명세서 형태로 재정리합니다. "이렇게 이해했습니다. 이 부분은 이렇게 구현할 예정이고, 이 부분은 두 가지 방식 중 하나를 선택해야 합니다"처럼요.
이 과정에서 발주자가 미처 생각하지 못한 케이스들이 나옵니다. 개발사 입장에서는 나중에 재작업을 줄이기 위해서라도 이 단계를 거치는 게 유리합니다. 사실 좋은 개발사는 이 단계를 건너뛰지 않습니다.
만약 요구사항을 그냥 받아서 바로 개발을 시작하는 곳이라면, 그게 오히려 주의 신호입니다.
인테그래빗이 이 문제를 다루는 방식
코키의 인테그래빗은 이 간극을 견적 단계에서부터 구조적으로 접근합니다.
견적을 내기 위해 기능 목록을 가져오면, 그 자리에서 기능 단위로 분해합니다. "회원가입"이라고 하면 이메일 인증 방식인지, 소셜 로그인 포함인지, 중복 이메일 처리는 어떻게 할지, 비밀번호 재설정 흐름은 어디서 시작하는지까지 쪼갭니다. 그리고 그 각각에 대해 발주자와 합의합니다.
이 합의가 견적서에 반영됩니다. 추후 "이건 포함된 거 아닌가요?"라는 논쟁이 생기지 않도록, 무엇이 포함이고 무엇이 제외인지를 기능 단위로 명확히 합니다.
개발이 시작된 이후에는 인테그래빗 Insight 포털을 통해 각 기능이 현재 어떤 상태인지를 실시간으로 확인할 수 있습니다. "로그인 기능 — 구현 완료", "결제 연동 — 진행 중", "주문 관리 — 미시작" 같은 식으로, 발주자가 개발사에 일일이 물어보지 않아도 현황을 파악할 수 있습니다.
"말로 전달"이 아니라 "시스템으로 합의"하는 방식입니다. 이렇게 하면 결과물이 나왔을 때 "제가 말씀드린 것과 다른데요"라는 상황 자체가 줄어듭니다.
외주 결과물이 기대와 자꾸 어긋난다면 — 30분 무료 상담에서 요구사항 정리를 함께 시작해 보세요.