AI 시대, 현업의 기획과 요구사항정의서 그리고 개발의 기획은 어떻게 다른가

요구사항정의서는 "무엇이 참이어야 하는가"에 답하는 문서입니다. 현업의 기획서는 "왜 하는가"에 답하고, 개발팀의 기획은 "어떻게 만들 것인가"에 답합니다. 셋은 쓰는 사람도 수명도 다른데, 많은 팀이 이걸 한 덩어리로 주고받습니다.

여기에 최근 변수가 하나 붙었습니다. AI 덕분에 현업도 HTML 목업을 반나절이면 만듭니다. 좋은 변화인데, 그만큼 두 팀의 체감이 벌어집니다. 화면이 도니까 현업은 거의 다 됐다고 보고, 개발팀은 거기서부터 다시 시작합니다. 둘 다 틀리지 않았습니다. 중간에 통째로 들어가는 공정 하나가 한쪽 눈에만 안 보일 뿐입니다.

이 글은 규모가 작은 신규 개발 건을 전제로 합니다. 문구 수정이나 값 변경 같은 단순 운영 건은 아래 단계를 그대로 적용할 필요가 없습니다.

요구사항정의서, 현업 기획서, 개발 기획 — 문서는 셋이다

"기획서 대 요구사항정의서"로 놓으면 그림이 반쪽입니다. 실무에서 움직이는 문서는 셋입니다.

	현업 기획서	요구사항정의서	개발 기획
답하는 질문	왜 하는가, 누구를 위한 것인가	무엇이 참이어야 하는가	어떻게 만들 것인가
쓰는 사람	현업(마케팅·영업·사업)	현업과 개발이 함께	개발팀 기획자·리드
핵심 내용	배경, 대상, 성공 기준, 우선순위	기능 동작, 데이터, 화면 상태, 예외, 권한	구조, 레거시 연동, 데이터 모델, 영향 범위, 순서
주로 읽는 사람	의사결정자, 유관 부서	개발, QA, 운영	개발, QA
바뀌는 시점	전략이 바뀔 때	구현하면서 계속	기술 전제가 바뀔 때
분쟁이 날 때 기준	이 일을 왜 했는지	이 동작이 맞는지 틀린지	왜 이 방식으로 만들었는지

현업의 기획은 마케팅과 영업을 위한 기획입니다. 시장에서 무엇을 얻을지, 누구에게 무엇을 약속할지를 정합니다. 개발팀의 기획은 개발을 위한 기획입니다. 같은 목표를 코드로 세우려면 무엇을 어디에 붙이고 어떤 순서로 가야 하는지를 정합니다. 둘 다 기획이고, 어느 쪽도 다른 쪽의 축약본이 아닙니다.

가운데 있는 요구사항정의서가 두 기획을 잇습니다. 현업 기획서는 승인을 받으면 조용해지지만, 요구사항정의서는 구현 끝까지 살아 움직입니다. 개발자가 바로 작업에 들어가는 기획서에서 다룬 체크리스트도 결국 "현업 기획서 안에 요구사항정의서가 들어 있어야 한다"는 이야기였습니다.

파일을 꼭 세 개로 나눠야 한다는 뜻은 아닙니다. 요즘은 HTML 목업 안에 각 화면의 목적과 요구사항을 같이 적어 한 덩어리로 넘기는 경우가 많고, 작은 건이라면 그게 더 빠릅니다. 나눠야 하는 것은 파일이 아니라 질문입니다. 한 파일에 담더라도 "왜 하는가"를 읽는 사람이 "무엇이 참인가"를 건너뛸 수 있게, 절이 갈려 있으면 됩니다. 섞여서 곤란해지는 쪽은 분량이 커질 때고, 그때는 자연스럽게 파일이 갈립니다.

개발 기획은 무엇을 하나

목업과 요구사항만 받아서 바로 코드로 들어가는 일은, 적어도 신규 개발에서는 거의 없습니다. 그 사이에 개발팀이 다시 한 번 기획을 합니다. 받은 문서를 읽고 "이대로 만들면 무엇이 깨지는가"를 먼저 보는 일입니다.

레거시와 어떻게 붙일지 정한다

새 기능은 늘 이미 돌아가는 것 위에 올라갑니다. 회원 정보를 어디서 가져올지, 기존 권한 체계를 그대로 쓸지 새로 만들지, 기존 데이터를 어떻게 이관할지, 지금 그 테이블을 쓰는 다른 화면 열두 개가 어떻게 되는지. 현업 문서에는 이 질문들이 없습니다. 있을 이유도 없습니다. 보이지 않는 영역이기 때문입니다.

영향 범위와 순서를 정한다

같은 요구사항도 "어디를 고쳐서 만드느냐"에 따라 일의 크기가 달라집니다. 화면 하나만 늘리면 되는 경우와, 공통 모듈을 손대야 해서 다른 기능 회귀 테스트까지 필요한 경우는 전혀 다른 일입니다. 어느 쪽을 택할지, 한 번에 갈지 두 번에 나눠 갈지를 정하는 것이 개발 기획입니다. 일정이 여기서 나옵니다.

이 단계의 산출물은 요구사항정의서를 다시 쓴 것이 아니라 그 위에 얹는 것입니다. 요구사항정의서가 "완료 건은 기본 필터에서 빠진다"라고 쓰면, 개발 기획은 "그 필터를 조회 단계에서 거를지 색인을 추가할지, 기존 통계 배치가 같은 쿼리를 쓰고 있으니 거기도 함께 본다"를 정합니다.

이메일로만 정리하면 아귀가 안 맞는다

많은 팀이 세 문서를 이메일 한 통으로 압축합니다. 짧을 때는 그게 가장 빠르고, 실제로 대부분의 요청은 그래도 됩니다. 문제는 분량이 늘어날 때입니다.

• 소구가 안 됩니다. 40줄을 넘어가면 받는 사람은 전부 읽지 않고 자기에게 걸리는 줄만 찾습니다. 순서를 어떻게 잡아야 하는지는 업무 이메일 에티켓 쪽에 정리해 뒀습니다.
• 앞뒤가 어긋나도 아무도 못 봅니다. 12번 줄의 "관리자만 수정 가능"과 31번 줄의 "작성자는 24시간 내 수정 가능"이 충돌해도, 글은 그 충돌을 보여주지 않습니다. 화면이라면 버튼 하나가 두 번 나와 바로 눈에 띕니다.
• 문장이 모호함을 덮습니다. "목록에서 바로 수정할 수 있게"라는 한 줄은, 인라인 편집인지 모달인지 상세 화면 이동인지를 가르지 않습니다. 쓴 사람 머릿속에는 하나만 있었고, 읽은 사람은 다른 하나를 떠올립니다. 그리고 그 차이는 구현이 끝난 뒤에 발견됩니다.

한 줄이 세 번 바뀌는 과정

실제로는 이런 식으로 움직입니다.

처음 이메일 — "담당자가 목록에서 바로 상태를 바꿀 수 있게 해주세요."

목업을 띄운 뒤 — "아, 드롭다운이군요. 그럼 완료로 바꾼 건도 목록에 계속 남나요? 두 사람이 같은 건을 동시에 바꾸면요? 담당자가 아닌 사람한테는 이 칸이 아예 안 보이나요, 눌러도 안 되나요?"

요구사항정의서 — "목록에서 상태 변경은 드롭다운. 담당자와 관리자만 보이고, 그 외에는 칸 자체가 안 보인다. 완료 건은 기본 필터에서 빠지되 '전체 보기'로 확인 가능. 동시 수정 시 나중 저장이 거절되고 최신 값을 다시 불러온다."

개발 기획 — "상태 변경은 기존 주문 API 에 필드를 더하지 않고 별도 엔드포인트로 뺀다. 동시 수정 거절은 기존에 쓰던 버전 칼럼을 그대로 쓴다. 완료 건 제외 필터가 월말 통계 배치와 같은 뷰를 보므로 그쪽 회귀 테스트를 범위에 넣는다."

첫 줄과 마지막 줄은 같은 요구사항입니다. 다만 마지막 줄만 일정을 뽑을 수 있습니다. 가운데를 건너뛰면 그 질문들은 사라지는 게 아니라 구현이 끝난 뒤에 돌아옵니다.

목업은 문장이 못 하는 말을 한다

그래서 목업이 들어갈 자리가 생깁니다. 예전에는 디자이너나 개발자의 시간을 빌려야 했지만, 지금은 현업이 직접 만듭니다. 화면을 띄워 놓고 이야기하면 질문의 해상도가 달라집니다. "이 버튼 누르면 어디로 가요?"는 글로 받으면 안 나오는 질문입니다.

목업으로 합의되는 것

화면에 보이는 것들입니다. 정보 구조, 흐름의 순서, 화면 상태(목록이 비었을 때·로딩 중·오류), 분기, 용어. 특히 빈 상태는 글로 쓰면 거의 빠지는데 목업에서는 안 그릴 수가 없습니다.

목업으로 합의되지 않는 것

화면 뒤에 있는 것들입니다. 두 사람이 동시에 수정하면 누가 이기는지, 권한 없는 사람이 URL을 직접 치면 어떻게 되는지, 저장 중에 네트워크가 끊기면 어디까지 남는지, 기존 데이터 3년치를 어떻게 이관하는지, 목록이 10만 건일 때도 이 화면이 뜨는지.

	목업이 답해 주는 것	목업이 비워 두는 것
범위	보이는 것	보이지 않는 것
예	화면 흐름, 빈 상태, 버튼 위치, 용어	동시 수정, 권한, 실패 경로, 데이터 이관, 성능
확인 방법	눈으로 본다	개발에게 물어봐야 한다
정해지는 곳	1~2단계	개발 기획

목업이 만든 가장 큰 가치는 왼쪽 칸을 빠르게 끝내서 오른쪽 칸을 논의할 시간을 번 것입니다. 오른쪽 칸을 없앤 게 아닙니다.

"거의 다 된 것 같다"는 착각 — 공정 하나가 안 보여서다

여기서 양쪽의 체감이 갈립니다.

현업 쪽에서 보면 화면이 돌아가고, 버튼을 누르면 다음 화면이 나오고, 숫자도 찍힙니다. 눈에 보이는 것은 거의 완성입니다. 그래서 "이걸 왜 두 달이나 걸려서 다시 만드나" 싶어집니다.

개발 쪽에서 보면 그 화면은 가정이 전부 생략된 껍데기입니다. 데이터는 하드코딩이고, 로그인한 사람이 누구인지 모르고, 저장은 아무 데도 안 되고, 실패하는 경우가 없습니다. 그리고 코드를 치기 전에 개발 기획이 통째로 한 단계 들어갑니다. 레거시와 어디서 만날지, 무엇이 같이 깨지는지, 어떤 순서로 올릴지를 정하는 시간입니다.

문제는 이 단계가 현업 눈에는 산출물이 없다는 것입니다. 화면이 안 바뀌니까 아무 일도 안 일어난 것처럼 보입니다. 양쪽 다 정직하게 자기가 본 것을 말하고 있는데, 한쪽은 "보이는 완성도"를 세고 다른 쪽은 "보이지 않는 합의와 설계"를 셉니다. 이건 성의나 실력의 문제가 아니라 공정 하나를 말로 꺼내 놓지 않아서 생기는 충돌입니다.

R&R 을 다섯 단계로 나눈다

단계	현업이 하는 일	개발이 하는 일	끝났다고 보는 기준
1. 의도	기획서 + 목업 + 요구사항 초안	읽고 질문 목록을 낸다	질문 목록이 나왔다
2. 정의	질문에 답하고 우선순위를 정한다	제약·예외·대안을 올린다	요구사항정의서가 확정됐다
3. 개발 기획	범위 조정 제안을 검토·수락한다	구조·연동·영향 범위·순서를 정한다	개발 기획과 일정이 나왔다
4. 구현	질문에 하루 안에 답한다	만든다	수용 기준을 통과했다
5. 확인	수용 기준으로 검수한다	바뀐 전제를 설명한다	다음 버전 요구사항이 적혔다

3단계를 표에 적어 두는 것만으로 꽤 많은 오해가 사라집니다. 일정은 2단계가 아니라 3단계가 끝나야 나옵니다. 요구사항정의서를 받은 날 "그래서 언제 되냐"고 물으면, 개발팀은 아직 모릅니다.

표보다 중요한 건 시작 전에 말로 합의해 둘 네 가지입니다.

1. 목업은 요구사항의 그림이지 결과물의 초안이 아닙니다. 코드는 가져가지 않습니다. 이걸 미리 말해 두면 나중에 "만든 걸 왜 안 쓰냐"가 안 나옵니다.
2. 목업에 없는 것도 요구사항입니다. 실패 경로, 권한, 빈 데이터, 이관. 1단계 질문 목록이 이것을 꺼내는 자리입니다.
3. 목업과 요구사항정의서가 다르면 정의서가 정본입니다. 목업은 논의 중에 수십 번 바뀌는데, 그때마다 "어제 그 화면"을 근거로 삼으면 기준이 사라집니다.
4. 개발 기획은 요구사항을 다시 묻는 자리가 아니라 구현 방식을 정하는 자리입니다. 여기서 요구사항이 흔들리면 2단계로 돌아가야 하고, 그 왕복이 일정을 가장 많이 먹습니다.

바뀐 결정은 따로 남깁니다. 요구사항정의서도 개발 기획도 현재 상태만 보여주지 과거를 보여주지 않아서, 석 달 뒤에 "왜 이렇게 했지"가 반드시 나옵니다. 그건 의사결정 기록 쪽 일입니다.

AI를 쓰는 자리

• 현업이 AI에게: 목업을 만든 다음, 그 목업을 만든 AI에게 한 번 더 시킵니다. "이 화면에서 정의되지 않은 상태와 예외를 목록으로 뽑아 주세요. 구현하지는 마세요." 개발팀이 1단계에서 물어볼 것을 미리 받아 두는 셈입니다. 이렇게 뽑은 목록은 그대로 개발에 보내지 말고, 현업이 먼저 답할 수 있는 것과 개발에 물어야 할 것으로 갈라 둡니다.
• 개발이 AI에게: 현업에게서 받은 목업과 문서를 AI에게 넣고 "확정된 것 / 추정인 것 / 안 적힌 것" 세 묶음으로 나눠 달라고 합니다. 그 결과를 사람이 추려 1단계 질문 목록으로 만들어 현업에 보냅니다. AI가 만든 질문을 그대로 보내면 현업은 답할 수 없는 것까지 받게 됩니다.

한 가지 조심할 것이 있습니다. AI가 만든 목업은 그럴듯해서 더 완성처럼 보입니다. 손으로 그린 와이어프레임이라면 아무도 다 됐다고 생각하지 않는데, 색과 여백까지 맞은 화면은 다릅니다. 목업의 완성도가 올라갈수록 1번 합의를 더 일찍, 더 분명히 해 둬야 합니다.

첨부 — 현업용 작성 지침 (내려받기)

위 내용을 현업이 바로 쓸 수 있게 한 장으로 정리했습니다. 기획서·요구사항정의서·목업 각각의 지시문 예시, 빠지면 반드시 되돌아오는 여섯 가지(권한·빈 상태·실패·동시 수정·기존 데이터·양 끝), 수용 기준 쓰는 법, 보내기 전 점검 목록이 들어 있습니다.

현업을 위한 기획서·요구사항정의서·목업 작성 지침 내려받기 (.md)

마크다운 파일이라 AI 대화창에 통째로 붙여 넣고 "이 지침대로 쓰자"고 말하면 그대로 작동합니다. 사내 용어나 결재 단계에 맞춰 고쳐 쓰셔도 됩니다.

정리

• 기획은 어느 한쪽의 일이 아닙니다. 현업만의 일도, 개발팀만의 일도 아니고 양쪽 모두에게 각자의 기획이 있습니다. 현업의 기획은 마케팅과 영업을 위한 것이고, 개발팀의 기획은 구현을 위한 것입니다. 요구사항정의서는 그 사이에서 "무엇이 참이어야 하는가"를 맡습니다. 파일을 셋으로 나누라는 뜻이 아니라, 한 파일에 담더라도 세 질문이 서로 섞이지 않아야 한다는 뜻입니다.
• 목업 다음은 코드가 아니라 개발 기획입니다. 목업은 보이는 것 — 흐름, 빈 상태, 용어 — 을 빠르게 끝내 줍니다. 권한, 동시 수정, 실패 경로, 기존 데이터, 레거시 연동은 그대로 남아 있고, 그걸 정하는 단계가 따로 있습니다. 현업 눈에 산출물이 없는 단계라 자주 빠뜨립니다.
• 그래서 일정은 요구사항 확정이 아니라 개발 기획이 끝나야 나옵니다. 요구사항정의서를 받은 날 "언제 되냐"고 물으면 개발팀은 아직 모릅니다. 이 한 가지만 서로 알고 있어도 체감 차이의 대부분이 사라집니다.

시작 전에 한 줄만 합의해 두면 요구사항정의서도 개발 기획도 훨씬 수월해집니다 — 목업은 요구사항의 그림이지 결과물의 초안이 아니다.