업무 시스템 견적을 받아 보면 개발 기간 앞에 "분석설계"라는 칸이 따로 잡혀 있는 경우가 있습니다. 이 칸을 보면 솔직한 마음은 이렇습니다. 우리가 원하는 것은 이미 다 말했는데, 그냥 바로 만들면 안 되나. 그 기간 동안 개발사는 무엇을 하고, 우리는 무엇을 하게 되는 걸까.
설계 연재는 6편에서 결론을 냈습니다. 결론을 내고 보니 앞에서 풀어 쓰지 않은 질문이 하나 남아 있었습니다. 분석설계가 정확히 무엇이고 맡기는 쪽은 그 기간에 무엇을 하게 되느냐는 것입니다. 연재의 마지막 7편으로, 결론 뒤에 이 질문의 답을 붙입니다.
2편에서는 어느 개발사에든 받아 봐야 할 문서 일곱 가지와 문서마다 던질 질문을 정리했습니다. 이 글은 문서가 아니라 기간을 다룹니다. 분석설계가 왜 개발보다 먼저인지, 그리고 저희가 쓰는 7단계에서 단계마다 무엇이 정해지고 건너뛰면 무엇이 생기는지, 그 사이 맡긴 분은 무엇을 하게 되는지를 적습니다.
분석설계가 개발보다 먼저인 이유
이노자일 대표는 약 20년 동안 요구분석과 분석설계 문서를 직접 쓰며 프로젝트를 해 왔습니다. 그동안 겪은 문제는 대부분 코드에서 생기지 않았습니다. "무엇을 만들어야 하는지"를 맡긴 쪽과 만든 쪽이 서로 다르게 이해한 데서 생겼습니다. 코드는 그 이해를 그대로 옮길 뿐이라 이해가 어긋나 있으면 잘 만든 코드도 다른 것을 만듭니다.
2026년 3월부터 AI를 업무 시스템 개발에 쓰면서 이 사실을 다시 확인했습니다. 처음 AI에게 맡긴 사용 장면 명세는 14개 업무 영역, 800장이 넘는 문서로 나왔습니다. 사람이 읽고 확인할 수 없는 분량이었습니다. 확인하지 못한 문서는 아무리 많아도 합의된 요구가 아닙니다. 그래서 문서를 더 잘 만드는 대신, 단계마다 사람이 확인하는 7단계 절차를 세웠습니다. 홈페이지에 적어 둔 일하는 순서가 요구사항 분석, 설계, 개발, 운영·확장인데, 앞의 두 칸을 잘게 나눈 것이 이 7단계입니다.
먼저 하는 이유는 사례 두 개로 줄여 말할 수 있습니다. 실무 담당자의 피드백이 "17항목"으로 왔는데 요구 목록과 화면 목록이 있어서 "17이 무엇의 개수인가"를 물을 수 있었고 세어 보니 세부 요구는 42건이었습니다. 장비 배정의 시작 기준이 도중에 "계약 확정"에서 "설치 요청"으로 바뀌었을 때는 문서와 결정 기록이 있어서 영향받는 화면과 규칙만 바꿨습니다. 둘 다 코드가 아니라 "무엇을"이 적혀 있었기에 가능했습니다. 분석설계 기간은 그 "무엇을"을 적는 기간입니다.
1~3단계에서는 무엇을 만들지 정합니다
7단계를 세 덩어리로 나누면 보기 쉽습니다. 첫 덩어리는 무엇을 만들지 정하는 세 단계입니다. 단계마다 정하는 것과 건너뛰면 생기는 일을 적겠습니다. AI는 앞 단계에서 끝난 설계 문서를 이어받아 작업하므로 앞 단계가 비어 있으면 뒤 단계도 그만큼 비게 됩니다.
1단계, 요구 식별. 들어온 요구를 한 건씩 "누가, 무엇을 계기로, 어느 업무 영역에서"로 적습니다. 이 단계의 결과는 아직 가설입니다. 그래서 확신이 낮은 항목에는 실무 담당자에게 확인할 항목이라는 뜻으로 "현업 확인 필요" 표시를 반드시 남깁니다. 이 표시가 붙은 항목은 확인 질문으로 모아 맡긴 분께 여쭙습니다. 이 단계가 없으면 "요구가 몇 건인가"부터 서로 다르게 셉니다. 17항목과 42건의 차이가 여기서 생깁니다.
2단계, 기존 기능과의 통합·영향 점검. 새 요구가 이미 있는 기능과 어떤 관계인지 넷 중 하나로 판정합니다. 기존 묶음에 편입하거나, 새 묶음을 만들거나, 독립으로 두거나, 중복이라 기각합니다. 업무 목적이 같고 조건만 다르면 합칠지 반드시 검토합니다. 역할은 달라도 같은 자료를 다루는 요구는 합칠 후보입니다. 어느 화면과 흐름에 영향이 가는지는 표로 남깁니다. 다만 "어느 업무 영역에 둘지"처럼 범위를 바꾸는 결정은 저희가 정하지 않고 경영진과 실무 담당자께 여쭙니다. 이 점검을 건너뛰면 같은 일을 하는 화면이 두 개 생기거나 고친 곳 옆의 화면이 조용히 어긋납니다.
3단계, 사용 장면 명세. 요구 하나에 문서 하나를 씁니다. 누가 쓰는지, 시작 신호가 무엇인지, 기본 흐름, 예외 흐름, 특별 요구, 미결 이슈까지 18개 항목이고 담당자별로 칸을 나눈 흐름도를 붙입니다. 항목을 "이하 생략"처럼 줄이지 않는 것이 원칙입니다. 미결 이슈 칸에 남은 것은 다음 확인 질문지에 들어갑니다. 명세 없이 만들면 정상 흐름만 있는 프로그램이 나와서 취소나 담당자 교체 같은 상황에서 멈춥니다.
이어지는 곳과 빠진 곳을 찾는 4~5단계
둘째 덩어리는 장면들을 업무 전체에 놓고 보는 두 단계입니다.
4단계, 업무 흐름 연결. 새 기능의 앞과 뒤가 기존 업무와 이어져야 합니다. 앞에서 오는 것도 없고 뒤로 가는 것도 없는 기능은 쓰이지 않거나 다른 곳에서 손으로 다시 입력하게 됩니다. 다른 시스템과 주고받으면 보내는 쪽과 받는 쪽을 모두 적습니다. 앞뒤가 문서만으로 확인되지 않으면 실무 담당자께 확인 질문으로 여쭙습니다. 연결을 확인하지 않으면 화면 하나하나는 전부 정상인데 업무가 중간에 끊기는 시스템이 됩니다.
5단계, 빠진 것 찾기와 화면 목록·메뉴 구조. 현재 방식과 목표 방식의 차이를 다섯 종류로 나눠 찾습니다. 기능이 없음, 일하는 순서가 다름, 자료가 없음, 다른 시스템과 연결이 없음, 권한 체계가 다름. 그리고 모든 요구에 우선순위 1~4 중 하나를 반드시 매깁니다. "미정"은 허용하지 않습니다. 화면은 최소로 잡습니다. 탭이나 조건 검색으로 되면 새 화면을 만들지 않습니다. 다만 너무 복잡해지면 나눕니다. 자료마다 만들기, 목록, 상세, 고치기, 지우기가 어느 화면에서 되는지 표로 대조하고 빈 칸은 화면을 더하거나 이유를 적어야 다음으로 넘어갑니다. 여기를 건너뛰면 화면이 늘어난 만큼 만들 것과 확인할 것이 늘고 우선순위도 없어 무엇부터 만들지가 정해지지 않은 채 개발이 시작됩니다.
6~7단계에서 화면과 규칙으로 못박습니다
셋째 덩어리에서는 앞에서 정한 것을 개발이 그대로 받을 수 있는 형태로 고정합니다.
6단계, 화면정의서. 화면마다 배치, 입력 항목, 버튼, 메시지, 권한, 업무 규칙을 적습니다. 화면 유형마다 꼭 있어야 할 버튼이 정해져 있고 빠지면 이유를 적어야 통과합니다. 화면 정의는 한 곳에만 두고 만든 화면이 정의와 맞는지를 프로그램으로 자동 대조합니다. 화면정의서가 없으면 "이 버튼은 왜 없나요"라는 말이 개발이 끝난 뒤에 나옵니다.
7단계, 업무 규칙과 요구사항 추적표. 앞 단계에 흩어져 있던 업무 규칙을 번호를 붙여 한 곳에 모읍니다. 그리고 요구마다 화면 번호, 업무 규칙 번호, 시험 항목 번호를 모두 갖는지 표로 확인합니다. 목적은 하나입니다. 어떤 요구도 구현에서 빠지지 않게 하는 것입니다. 빠진 것이 0건이어야 "개발 준비 완료"이고 하나라도 남으면 앞 단계로 되돌아갑니다. 이 대조가 없으면 요구가 빠졌다는 사실을 운영을 시작한 뒤에 알게 됩니다.
단계마다 저희가 멈춰서 확인합니다
7단계에서 가장 중요한 것은 단계의 내용이 아니라 단계 사이의 멈춤입니다. 단계마다 결과가 나오면 사람이 셋 중 하나로 답해야 다음으로 넘어갑니다. 예는 진행, 수정은 고친 내용이 우선, 아니오는 그 자리에서 중지입니다. 그리고 단계마다 넘어가기 위한 점검 조건이 따로 있습니다. 5단계의 "빈 칸에 이유", 6단계의 "빠진 버튼에 이유", 7단계의 "빠진 것 0건"이 그 조건입니다.
이 멈춤은 저희가 맡습니다. AI가 낸 결과를 단계마다 사람이 읽고 확인한 뒤에 다음 단계로 넘깁니다. 800장을 받고 읽지 못했던 경험에서 나온 방식이라 한 번에 읽을 수 있는 분량으로 끊어서 확인합니다. 맡긴 분이 일곱 단계의 문서를 모두 읽을 필요는 없습니다.
되돌아가기도 절차의 일부입니다. 7단계 추적표에서 빈 칸이 나오면 앞 단계로 돌아가 채웁니다. 저희 프로젝트에서는 실무 담당자에게 보내는 확인 질문지가 11차까지 이어졌습니다. 1단계에서 "현업 확인 필요"로 표시해 둔 항목을 하나씩 확인하다 보니 그렇게 됐습니다. 답은 결정 기록에 남기고 모호하면 다시 물었습니다.
맡긴 분은 마지막에 시제품 화면을 보고 결정합니다
분석설계 기간에 맡긴 분이 하시는 일은 세 가지입니다. 처음에 가진 자료를 주시고, 중간에 확인 질문에 답하시고, 마지막에 시제품 화면을 보고 선택하고 결정하십니다.
설계 문서는 개발을 위한 문서라 분량이 많고 표가 빽빽합니다. 그것을 단계마다 읽고 판정하시게 하는 대신, 일곱 단계를 거쳐 나온 결과를 실제로 눌러 볼 수 있는 화면으로 보여 드립니다. 화면을 보면서 "이 칸은 필요 없다", "이 순서가 맞다"를 고르시면 그 결정이 다시 설계 문서에 반영됩니다. 문서는 저희가 지키고 결정은 맡긴 분이 화면 위에서 하시는 방식입니다.
시작 방식 세 가지 중 내 상황은 어디인가
같은 7단계라도 시작하는 자리는 세 가지입니다.
- 운영 중 요구 1건 추가 — 기존 문서에 덧붙이며 영향을 점검합니다. 기존 문서를 다시 만들지 않습니다. 이미 시스템이 있고 설계 문서도 있는 분은 여기입니다.
- 전체 재분석 — 처음부터 다시 진행합니다. 요구 하나를 덧붙이는 것으로는 부족하고 전체를 새로 분석해야 할 때입니다.
- 산출물이 없는 새 프로젝트 — 인터뷰부터 시작합니다. 아직 아무것도 없는 분은 여기입니다.
견적 상담에서 "분석설계 기간"이 잡혔다면 그 기간이 셋 중 어느 방식인지 물어보시면 됩니다. 요구 1건 추가인데 전체 재분석 기간이 잡혀 있거나 새 프로젝트인데 인터뷰가 없다면 그 자체가 확인할 점입니다.
분석설계 시작 전에 준비해 두면 좋은 것
저희 구매·자산 관리 프로젝트에서 실무 담당자가 처음 준 것은 사용 장면 명세 33건과 업무 요청 캡처 같은 실무 자료 40건이었습니다. 이것을 7단계를 거쳐 요구 목록부터 추적표까지 만들었고 2026년 8월 21일 개발을 시작해 10월 1일 기준 213번째 작업 묶음까지 마쳤습니다. 작업 묶음은 점검을 통과해야 닫힙니다. 화면 82개가 구현돼 있으며 업무 규칙 402개와 안내 문구 500개를 문서와 코드에서 같은 번호로 관리합니다.
이 기록에서 맡긴 분이 한 일을 뽑으면 준비물이 나옵니다.
- 가진 자료의 목록 — 완성된 기획서가 아니어도 됩니다. 업무 요청을 주고받은 캡처나 이미 적어 둔 사용 장면이 있으면 그대로 1단계의 재료가 됩니다.
- 질문에 답할 담당자 — "현업 확인 필요" 항목은 실무 담당자만 답할 수 있습니다. 질문지가 여러 차례 올 수 있으니 누가 답할지 미리 정해 둡니다.
- 범위를 결정할 사람 — 어느 업무 영역에 둘지 같은 범위 결정은 경영진과 실무 담당자가 내립니다. 시제품 화면을 볼 때 결정권자가 함께 보시면 결정이 빨라집니다.
- 시제품 화면을 볼 시간 — 마지막에 화면을 눌러 보며 선택하고 결정하는 자리입니다. 실제로 그 화면을 쓸 담당자가 함께하면 좋습니다.
- 기존 시스템과 문서의 유무 — 세 가지 시작 방식 중 어디인지가 여기서 정해집니다.
문서마다 무엇을 물어볼지는 2편에 정리해 두었습니다. 이 글에는 그 문서들이 나오는 기간에 맡긴 분이 어디에 서 있게 되는지를 적었습니다.