외주 개발을 맡기면 보통 "화면 시안"과 "완성된 프로그램" 두 가지를 받게 됩니다. 그 사이에 무엇이 오갔는지는 잘 보이지 않습니다. 그래서 개발이 끝난 뒤에야 "이 기능은 왜 없나요", "이 화면은 우리 업무 순서와 다른데요" 같은 대화가 시작되곤 합니다.
저희가 최근 겪은 일입니다. 실무 담당자들의 피드백이 "17항목"으로 정리되어 왔습니다. 17건만 처리하면 끝나는 것처럼 보였습니다. 그런데 원문과 한 줄씩 대조해 보니 17은 화면 묶음의 수였고 그 안의 세부 요구는 42건이었습니다. "17항목 완료"라고 보고했다면 요청한 쪽은 25건이 빠졌다고 느꼈을 것이고, 만든 쪽은 다 했다고 생각했을 겁니다. 이 차이를 잡을 수 있었던 것은 요구 목록과 화면 목록이 이미 문서로 있어서 "17이 무엇의 개수인가"를 물을 수 있었기 때문입니다.
저희는 개발에 들어가기 전에 일곱 단계의 설계 절차를 거치고 단계마다 사람이 "예, 수정, 아니오" 가운데 하나로 확인한 뒤에만 다음으로 넘어갑니다. 이 글은 그 절차를 바탕으로, 외주를 맡기는 분이 개발 전에 받아 봐야 할 문서 일곱 가지와 각 문서에 던질 질문을 정리한 것입니다. 앞 글에서는 이 절차를 만들게 된 이야기를 했습니다.
문서 1·2 — 요구 목록과 영향 점검표: "누가, 왜, 어디서"부터
첫 번째 문서는 요구 목록입니다. 기능 이름을 나열한 목록이 아닙니다. 새 요구 하나하나를 "누가(어떤 사용자가), 무엇을 계기로, 어떤 업무 영역에서" 하는지로 적은 가설입니다. "발주 화면"이 아니라 "구매 담당자가 업무 요청을 받으면 발주를 낸다"처럼 적습니다.
여기서 볼 것은 개발사가 확신이 낮은 항목에 표시를 남기는지입니다. 저희는 그런 항목에 실무 담당자에게 확인할 것이라는 뜻으로 [현업 확인 필요]라는 꼬리표를 붙입니다. 이 표시가 하나도 없는 요구 목록은 오히려 한 번 더 들여다볼 만합니다. 처음 듣는 업무를 한 번에 다 이해했다는 뜻이기 때문입니다.
두 번째 문서는 영향 점검표입니다. 새 요구가 기존 기능과 겹치는지를 넷 중 하나로 판정합니다. 기존 묶음에 넣을지, 새 묶음을 만들지, 독립된 기능으로 둘지, 이미 있는 것이라 기각할지. 그리고 어느 화면과 흐름에 영향이 가는지를 표로 적습니다.
확인할 질문은 이렇습니다.
- 요구마다 "누가, 무엇을 계기로, 어디서"가 적혀 있는가
- 확신이 낮다고 표시된 항목이 있는가, 있다면 누구에게 무엇을 물을 것인가
- 이번 요구가 기존 화면 가운데 어디에 영향을 주는지 표가 있는가
문서 3·4 — 사용 장면 명세와 업무 흐름 연결도: 고립된 기능이 없는지
세 번째 문서는 사용 장면 명세입니다. 요구 하나에 문서 하나를 씁니다. 누가 쓰는지, 시작 전에 무엇이 갖춰져 있어야 하는지, 잘 됐을 때의 흐름, 잘 안 됐을 때의 흐름, 아직 정하지 못한 것까지 18개 항목으로 적고 담당자별로 칸을 나눈 흐름도를 붙입니다.
이 문서에서 눈여겨볼 곳은 "잘 안 됐을 때"와 "아직 정하지 못한 것" 칸입니다. 정상 흐름만 적힌 명세로 만든 프로그램은 예외 상황에서 막힙니다. 취소하면 어떻게 되는지, 중간에 담당자가 바뀌면 어떻게 되는지가 여기에 적혀 있어야 합니다.
네 번째 문서는 업무 흐름 연결도입니다. 새 기능의 앞과 뒤가 기존 업무와 반드시 이어져야 한다는 원칙으로 그립니다. 앞에서 오는 것도 없고 뒤로 가는 것도 없는 기능이 있으면, 그 기능은 실제로 쓰이지 않거나 다른 곳에서 손으로 다시 입력하게 됩니다. 두 시스템을 오가는 기능이면 보내는 쪽과 받는 쪽을 모두 적습니다.
이 연결도가 잡아 준 일이 있습니다. 처음에는 "창고에 입고된 물건이 서비스 자산이 된다"고 가정하고 흐름을 그렸습니다. 실제 코드와 흐름을 한 줄씩 대조해 보니 그런 연결은 없었습니다. 서비스 자산은 입고가 아니라 약정(계약)이 승인될 때 생기는 것이었습니다. 흐름도에 없는 연결을 그대로 두었다면, 개발자는 존재하지 않는 경로를 찾느라 시간을 썼을 것입니다.
확인할 질문은 이렇습니다.
- 요구마다 사용 장면 명세가 한 건씩 있는가, 예외 흐름과 미결 사항 칸이 비어 있지 않은가
- 흐름도에서 앞뒤가 끊긴 기능이 있는가
- 다른 시스템과 주고받는 기능이면 양쪽이 모두 적혀 있는가
문서 5·6 — 화면 목록과 화면정의서: 화면이 줄어드는지
다섯 번째 문서는 빠진 것 찾기와 화면 목록·메뉴 구조입니다. 앞 단계까지 적은 요구와 흐름을 놓고 아직 다뤄지지 않은 것이 무엇인지 찾은 다음, 화면 목록을 만듭니다.
저희가 지키는 원칙은 화면 수를 최소로 하는 것입니다. 탭이나 조건 검색으로 되는 것이면 새 화면을 만들지 않습니다. 화면이 하나 늘 때마다 만들 것, 확인할 것, 나중에 고칠 것이 함께 늘기 때문입니다. 화면마다 등록, 목록 보기, 상세 보기, 수정, 삭제 다섯 칸을 모두 채우는 점검표를 씁니다. 칸이 비어 있으면 왜 비었는지 이유를 적거나 기능을 채웁니다. "삭제는 없음"이라면 그 이유가 적혀 있어야 합니다.
여섯 번째 문서는 화면정의서입니다. 화면 하나에 문서 하나를 씁니다. 화면 배치, 입력 항목, 버튼, 그 화면에 걸리는 업무 규칙, 누가 볼 수 있고 누가 고칠 수 있는지의 권한까지 적습니다.
저희는 화면정의를 한 곳에만 두고 만든 화면이 그 정의와 맞는지를 사람이 아니라 프로그램으로 자동 대조합니다. 정의서 따로, 화면 따로가 되는 순간 정의서는 아무도 읽지 않는 문서가 되기 때문입니다. 외주를 맡기는 입장에서는 "화면정의서와 실제 화면이 다르면 어느 쪽을 고치나요"라고 물어보면, 그 개발사가 정의서를 계속 쓰는 문서로 다루는지 알 수 있습니다.
확인할 질문은 이렇습니다.
- 화면 수를 줄이려 한 흔적이 있는가, 탭이나 조건 검색으로 합친 화면이 있는가
- 화면마다 등록·목록·상세·수정·삭제 점검표가 있고 빈 칸에 이유가 적혀 있는가
- 화면정의서에 입력 항목과 버튼뿐 아니라 업무 규칙과 권한이 적혀 있는가
- 정의서와 화면이 달라지면 어떻게 잡아내는가
문서 7 — 업무 규칙 목록과 요구사항 추적표: 빠진 것이 0건인지
일곱 번째 문서는 업무 규칙 목록과 요구사항 추적표입니다. 앞의 문서들에 흩어져 있던 업무 규칙(예를 들어 "해지된 계약에는 새 장비를 배정하지 않는다" 같은 것)을 번호를 붙여 한 곳에 모읍니다. 그리고 요구 하나하나가 화면 번호, 업무 규칙 번호, 시험 항목 번호를 모두 갖는지 표로 확인합니다.
이 표에서 빠진 것이 0건이어야 "개발 준비 완료"입니다. 하나라도 비어 있으면 다섯 번째나 여섯 번째 단계로 되돌아갑니다. 되돌아가는 것도 절차의 일부입니다.
이 표가 있으면 개발 도중 기준이 바뀌어도 감당할 수 있습니다. "장비 배정이 어디서 시작되는가"라는 기준이 실무 담당자의 재정의로 바뀐 적이 있습니다. 처음에는 계약이 확정될 때 시작한다고 정했는데, 실제로는 설치 요청이 들어올 때 시작해야 했습니다. 설계 문서와 결정 기록이 있었기 때문에 어느 화면과 어느 규칙이 영향을 받는지 짚을 수 있었고, 전부 다시 만드는 대신 영향을 받는 부분만 바꿨습니다.
확인할 질문은 이렇습니다.
- 업무 규칙마다 번호가 있고 그 번호가 화면정의서에서도 같은 번호로 쓰이는가
- 요구, 화면, 규칙, 시험 항목이 한 표에서 서로 이어지는가
- 빈 칸이 있으면 무엇을 채운 뒤 개발을 시작할 것인가
이 절차를 그대로 적용한 프로젝트
통신 서비스 회사의 구매·자산 관리 시스템입니다. 2026년 8월 21일에 개발을 시작해, 이 글을 쓰는 10월 1일 기준으로 213번째 작업 묶음을 마쳤습니다. 작업 묶음 하나는 점검을 통과해야만 닫힙니다. 화면 82개가 모두 구현되어 있고, 업무 규칙 402개와 사용자에게 보이는 안내 문구 500개가 문서와 코드에서 같은 번호로 관리됩니다.
실무 담당자가 처음 준 것은 사용 장면 명세 33건과 업무 요청 캡처 같은 실무 자료 40건이었습니다. 이것을 일곱 단계를 거쳐 요구 목록부터 추적표까지 만들었습니다.
실무 담당자에게 보내는 확인 질문지는 11차까지 이어졌습니다. 답을 받으면 결정 기록에 남기고 답이 모호하면 다시 물었습니다. 질문이 11차까지 간 것은 절차가 느려서가 아니라, 첫 단계에서 [현업 확인 필요]로 표시해 둔 것들을 하나씩 확인한 과정이 그대로 남았기 때문입니다.
이 절차는 세 가지 방식으로 씁니다. 이미 만들어진 시스템에 요구 1건을 더할 때는 기존 문서에 덧붙이고, 전체를 새로 분석해야 할 때는 처음부터 다시 돌리고, 산출물이 전혀 없는 새 프로젝트는 인터뷰부터 시작합니다. 맡기는 분의 상황이 셋 가운데 어디인지에 따라 받아야 할 문서의 두께도 달라집니다.
개발 전에 이렇게 물어보시면 됩니다
일곱 문서를 모두 같은 두께로 받아야 한다는 뜻은 아닙니다. 작은 사이트라면 요구 목록과 화면정의서가 중심이 될 수 있습니다. 다만 개발사가 어느 문서를 만들고 어느 문서를 생략하는지, 생략하면 그 확인을 어디서 대신하는지는 개발 전에 물어볼 수 있습니다.
| 문서 | 이 질문 하나만은 |
|---|---|
| 요구 목록 | 확신이 낮다고 표시한 항목이 있나요 |
| 영향 점검표 | 이번 요구가 기존 화면 어디에 영향을 주나요 |
| 사용 장면 명세 | 잘 안 됐을 때의 흐름이 적혀 있나요 |
| 업무 흐름 연결도 | 앞뒤가 끊긴 기능이 있나요 |
| 화면 목록 | 화면을 줄인 흔적이 있나요 |
| 화면정의서 | 정의서와 화면이 달라지면 어떻게 잡나요 |
| 요구사항 추적표 | 빈 칸이 0건인가요 |
하나 더 물어보실 것은 단계마다 "예, 수정, 아니오"로 확인을 받는지입니다. 확인 없이 다음 단계로 넘어가면 문서가 있어도 그 문서가 일을 하지 않습니다.