외주 개발사에 넘기기 전에 채워야 할 4가지 — 견적이 안 나오는 진짜 이유

기획서를 보냈는데 견적이 안 옵니다. 오더라도 "확인할 게 많다"는 말이 붙습니다.

어렵게 계약하고 나면 이번엔 다른 일이 생깁니다. 만들어진 화면을 보니 내가 생각한 것과 다릅니다. 고쳐달라고 하면 "그건 처음에 없던 내용"이라는 답이 옵니다.

양쪽 다 잘못한 게 아닙니다. 판단할 근거가 문서에 없었을 뿐입니다.

개발자는 이런 걸 묻습니다

요구사항 문서를 받아 든 사람이 되묻는 질문은 대체로 정해져 있습니다. 외주 개발사가 견적을 내기 전에 묻는 것도 거의 같습니다.

• "이 화면은 언제 뜨나요?"
• "연동이 진행 중일 때는 어디에 있나요?"
• "거절되면 화면이 어떻게 되나요?"
• "이건 숫자인가요, 날짜인가요? 직접 입력할 수 있나요?"
• "이 데이터는 어디서 오나요? API 하나면 되나요?"
• "이 버튼을 누르면 무엇이 추가되고, 어디로 이동하나요?"
• "로그인에 실패하면요?"
• "종료일이 시작일보다 앞서면 어떻게 되나요?"

질문이 까다로워서가 아닙니다. 이 답이 없으면 코드를 쓸 수 없기 때문입니다. 그래서 견적도 못 냅니다. 견적을 내려면 만들 것의 개수와 경우의 수를 세야 하는데, 경우의 수가 문서에 없으니까요.

문서에 빠져 있는 건 대개 같은 4가지입니다

화면은 그려져 있습니다. 기능도 적혀 있습니다. 빠지는 건 늘 이 네 가지입니다.

1. 상태 — 이 화면이 지금 어떤 상태인가

같은 화면도 상태에 따라 다르게 보입니다. 비어 있을 때, 불러오는 중일 때, 다 불러왔을 때, 실패했을 때. 보통은 다 불러온 상태 하나만 그려져 있습니다.

• 이렇게 적으면 부족합니다 — 연동된 계좌 목록이 보인다
• 이렇게 적어야 합니다 — 연동 전 / 연동 중 / 연동 완료 / 연동 실패 — 네 가지 화면

2. 조건 — 언제 이게 나타나는가

버튼이나 안내 문구가 항상 보이는지, 특정 조건에서만 보이는지가 안 적혀 있으면 개발자는 물어보거나 임의로 정합니다.

• 이렇게 적으면 부족합니다 — 재신청 버튼
• 이렇게 적어야 합니다 — 직전 신청이 거절된 경우에만 재신청 버튼 노출

3. 결과 — 누르면 무슨 일이 일어나는가

버튼 이름만 있고 그다음이 없는 경우가 많습니다. 무엇이 저장되고, 어디로 이동하고, 사용자에게 무엇이 보이는지까지가 한 세트입니다.

• 이렇게 적으면 부족합니다 — 확인 버튼
• 이렇게 적어야 합니다 — 확인 → 신청 저장 → 완료 화면으로 이동 → 접수번호 표시

4. 실패 — 안 될 때는 어떻게 되는가

특히 자주 빠지는 항목입니다. 잘 되는 흐름만 그려놓고 끝냅니다. 그런데 실제 서비스에서 시간을 잡아먹는 건 대부분 안 될 때의 처리입니다.

• 이렇게 적으면 부족합니다 — (아무것도 안 적혀 있음)
• 이렇게 적어야 합니다 — 네트워크 실패 시 재시도 안내 / 중복 신청 시 기존 건 안내 / 입력값 오류 시 해당 칸 표시

왜 4번이 제일 중요한가

기능은 상상하면 나옵니다. 실패는 겪어봐야 나옵니다.

그래서 실패 항목이 비어 있는 문서는 흔히 아직 한 번도 안 굴려본 서비스입니다. 개발사도 그걸 알아봅니다. 그 상태에서 나온 견적은 나중에 늘어나는 경우가 많습니다. 안 적힌 경우의 수가 개발 중에 하나씩 나타나기 때문입니다.

반대로 실패 처리가 적혀 있으면 견적이 빨리 나옵니다. 셀 수 있으니까요.

핀테크 서비스를 만들 때 오픈뱅킹 연동을 총괄한 적이 있습니다. 금융권 심사를 통과하려면 기능이 되는 것만으로는 부족했습니다. 기능성 테스트와 보안 문서까지 갖춰야 했습니다. 어떤 조건에서 어떻게 실패하고, 그때 무엇을 보여주고, 무엇을 기록하는지까지요.

그 과정이 번거로웠지만, 그 문서가 있어서 소규모 팀으로도 심사를 통과할 수 있었습니다. 채워야 통과하는 문서를 한 번 써보면, 그다음부터는 그게 기본값이 됩니다.

넘기기 전 체크리스트

화면 하나마다 아래 네 줄을 채워보세요. 네 줄이 안 채워지는 화면이 있다면, 거기가 나중에 견적이 늘어날 지점입니다.

화면 이름: ____________
1. 상태 — 이 화면이 가질 수 있는 상태는? (비어있음 / 불러오는 중 / 완료 / 실패)
2. 조건 — 언제 나타나는가?
3. 결과 — 사용자가 행동하면 무엇이 저장되고 어디로 가는가?
4. 실패 — 안 될 때 무엇을 보여주고 무엇을 기록하는가?

여기에 하나만 더 붙이면 좋습니다. 이 데이터는 어디서 오는가. 화면에 보이는 숫자가 어느 시스템에서 오는지 안 적혀 있으면, 개발이 시작된 뒤에 "그 값은 없습니다"라는 답을 듣게 됩니다.

AI에게 시킬 때도 같습니다

요즘은 요구사항 초안을 AI로 쓰는 경우가 많습니다. 이때도 조건은 같습니다.

"화면설계서 써줘"라고 하면 잘 되는 흐름만 나옵니다. AI도 실패를 상상하지는 못하기 때문입니다. 대신 이렇게 요청하면 달라집니다.

"이 화면의 상태를 네 가지로 나누고, 각 상태에서 사용자에게 보이는 것과 실패했을 때의 처리를 함께 적어줘."

AI가 잘 만드는 건 빠진 칸을 채우는 일입니다. 무엇을 채워야 하는지는 사람이 알려줘야 합니다.

오늘 한 가지만 한다면

지금 만들고 있는 화면 중 하나만 골라, 위 네 줄을 채워보세요.

가장 빨리 드러나는 건 4번입니다. 실패 항목이 비어 있다면, 그 화면은 아직 넘길 준비가 안 된 것입니다.

---

우리 문서가 넘길 수 있는 상태인지 모르겠다면
2분 진단으로 지금 먼저 손댈 과제 하나와 2주 파일럿 시작안, 사람이 꼭 확인해야 할 리스크를 정리해서 보실 수 있습니다. 편하신 만큼만 답하셔도 괜찮습니다.

STAR-T AI 사업 운영 진단 →

---

각주

① 참고자료·확인일
이 글은 외부 통계·연구를 인용하지 않습니다. 근거는 강의·컨설팅 현장에서 요구사항 문서를 검토하며 반복 확인한 질문 패턴입니다(예비 창업자 1:1 컨설팅 500건 이상 누적 · 이력 SSOT 기준). 본문의 오픈뱅킹 사례는 2021년 핀테크 서비스(2019.09~2022.06 재직)에서 연동을 총괄한 경험입니다. 확인일 2026-08-04.

② 안 쓴 수치
개발 기간 단축률·견적 절감률 같은 수치는 쓰지 않았습니다. 저희가 측정한 값이 아니고, 프로젝트마다 편차가 커서 일반화할 수 없기 때문입니다. 사내 설문·CS 응답의 수치도 사용하지 않았습니다.

③ 만든 방식
AI로 초안을 만들고 사람이 검증·편집했습니다. 발행 전 사실·톤·법무 3개 검수를 거쳤습니다.