서비스기획을 AI 에게 맡기면 먼저 속도에 놀랍니다. 아이디어 한 단락을 주면 기획서가 나옵니다. 이어서 요구사항, 사용자 스토리와 인수기준, 화면 설계 골격까지 나옵니다. 문서끼리 번호로 연결까지 되어 있습니다.
용어를 잠깐 풀겠습니다. 요구사항은 서비스가 해야 할 일의 목록입니다. 사용자 스토리는 그것을 사용자 입장에서 한 문장으로 쓴 것입니다. 인수기준은 이것이 되면 완성으로 쳐 준다는 합격 조건입니다. PO(프로덕트 오너)나 서비스기획자가 개발에 넘기기 전에 만드는 문서들입니다.
저도 처음에는 이제 기획의 병목은 문서 작성이 아니겠구나 생각했습니다. 반은 맞았습니다. 병목은 다른 자리로 옮겨 갔고, 저는 검사 결과를 받고서야 그 자리를 봤습니다. 문장이 아니라 문장 옆에 붙는 칸이었습니다. 이 요구의 근거가 무엇인지 적는 칸, 그리고 어떻게 확인할지 적는 검증 방법 칸입니다. 하나는 비어 있었고, 하나는 같은 값으로 채워져 있었습니다.
연습 기획 한 벌과 제 도구 기획 한 벌을 AI 로 만들었습니다
하나는 채용관리 세트입니다. 공고부터 지원, 심사, 면접, 결과 통보까지를 한 곳에서 관리하는 서비스를 연습 삼아 기획했습니다. 목표는 개발에 넘겼을 때 질문이 하나도 돌아오지 않는 수준이었습니다.
다른 하나는 작업 도구 세트입니다. 아이디어를 넣으면 기획 문서를 차례로 만들고 단계마다 사람이 승인하는 도구를 제가 만들려고 하는데, 그 도구 자체의 기획을 AI 에게 맡겼습니다. 제 문제라서 무엇이 맞고 틀렸는지 제가 판단할 수 있는 소재였습니다.
두 세트 모두 AI 가 만들고, 검사는 따로 띄운 검사용 AI 가 맡았습니다. 연결을 자동으로 세는 도구도 함께 썼습니다. 같은 회사 모델이긴 합니다. 대신 만든 쪽의 자기 점검 결과는 보여 주지 않고, 문서를 처음부터 다시 대조하게 했습니다.
작업 도구 세트는 연결이 하나도 빠지지 않았습니다
문서끼리 번호가 어긋나거나, 인수기준이 없는 스토리가 섞이는 일은 없었습니다. 연결을 챙기는 일은 AI 가 잘했습니다. 그런데 같은 검사에서 인수기준 표에 대한 지적이 함께 나왔습니다.
인수기준 36건의 검증 방법이 전부 ‘시연’으로 시작했습니다
인수기준마다 통과 여부를 어떻게 확인할지 적는 검증 방법 칸이 있습니다. 36건 모두 그 칸이 ‘시연’으로 시작했습니다. 직접 실행해 보고 결과를 눈으로 확인한다는 뜻입니다.
대충 쓴 것은 아니었습니다. 줄마다 무엇을 볼지가 붙어 있었습니다. 빈 입력과 한 단어 입력을 넣어 본다거나, 오류를 일부러 일으킨 뒤 상태를 본다는 식이었습니다.
그래도 검사용 AI 는 11건이 시연만으로는 확인이 부족하다고 짚었고, 나머지 25건은 시연으로 두어도 된다고 봤습니다. 지적을 받아 다시 고치게 하고 보니 그 11건은 이런 기준이었습니다. 승인 뒤 저장된 상태 값이 정말 바뀌었는지, 같은 요청이 두 번 와도 한 번만 처리되는지, 화면의 건수가 실제 집계와 맞는지. 눈으로만 봐서는 판정이 나지 않는 것들이라 테스트나 값 대조로 바뀌었습니다.
AI 는 검증 방법 칸을 비우지 않았습니다. 가장 무난한 값 하나로 전부 채웠습니다. 25건에는 맞는 값이었고 11건에는 모자란 값이었습니다. 이 요구는 무엇으로 확인해야 하느냐는 판단을 줄마다 하지 않고 한 값으로 모은 셈입니다.
같은 세트에 두 가지가 더 있었습니다. 측정할 수 없게 적힌 스토리가 2건 있었습니다. 그리고 할지 말지 정하지 않은 요구의 화면이 그 결정보다 먼저 설계돼 있었습니다. 그대로 개발에 넘어갔다면 만들지 않을 수도 있는 화면부터 만들었을 겁니다.
채용관리 세트는 더 앞쪽 칸이 비어 있었습니다
채용관리 세트는 제가 순서를 거꾸로 밟았습니다. 기획서부터 시키고, 요구사항과 화면 설계까지 만든 다음에야 문제 정의서를 제대로 세웠습니다. 이 서비스가 풀려는 문제가 정말 있는지를 적는 문서입니다.
문제 진술 자체는 그럴듯했습니다. 지원자 상태를 스프레드시트와 메일로 나눠 관리하다 보니 누락과 지연이 생긴다는 내용입니다. 누구나 고개를 끄덕일 문장이죠. 그런데 받쳐 줄 근거는 채용 업계에서 흔히 하는 말과 AI 의 추론뿐이었습니다. 담당자가 문의 응대에 시간을 얼마나 쓰는지는 아무도 재지 않았습니다.
반대로 틀렸을 수 있는 이유를 적어 보니 더 선명해졌습니다. 채용 규모가 작으면 스프레드시트로 충분할 수 있습니다. 누락이 도구 문제가 아니라 담당자 겸직 문제일 수도 있습니다. 둘 중 하나만 맞아도 이 서비스를 만들 이유가 흔들립니다.
여기서 AI 는 근거를 지어내지 않았습니다. 문제 정의서에 근거가 없다고 스스로 적었습니다. 문제는 그 칸이 비어 있어도 기획서와 요구사항, 화면 설계가 완성된 모양으로 나온다는 점이었습니다. 빈칸이 문서 한 벌의 완성도를 조금도 깎지 않았습니다.
그럼 비어 있는 근거 칸을 리서치로 채우면 될까요. 채우기 전에 그 리서치가 믿을 만한지부터 궁금했습니다. 마침 다른 주제로 써 둔 제 리서치 한 편이 있어서 시험해 봤습니다. AI 에이전트에게 주는 지시문을 어떻게 써야 잘 따르는지 조사한 글입니다. 주장마다 출처를 붙이고 확인된 정도를 매기게 했습니다.
표본이 한 편뿐이라 일반화할 수는 없습니다. 다만 기획 문서의 근거 칸을 무엇으로 채우든, 그 재료부터 따로 확인해야 한다는 쪽에 가깝습니다.
요구공학 표준은 요구를 문장이 아니라 여러 칸을 가진 기록으로 봅니다
요구공학은 무엇을 만들지 정확히 적는 방법을 다루는 분야입니다. 그 국제 표준인 ISO/IEC/IEEE 29148 은 스스로의 범위를 이렇게 적습니다. 좋은 요구가 어떻게 구성되는지 정의하고, 요구가 가져야 할 속성과 특성을 제시한다고요.
이 표준을 따르는 요구 명세 템플릿을 열면 그 칸이 보입니다. 요구 본문 옆에 출처, 근거, 담당자, 우선순위, 상태가 있습니다. 검증 방법 칸에서는 시험, 시연, 검사, 분석 네 가지 중 하나를 고릅니다. 이해관계자의 요구를 적는 문서와 소프트웨어 요구를 적는 문서도 따로 둡니다.
사람끼리 일할 때는 이 칸이 비어도 대화가 메우기도 했습니다. 기획 문서를 받은 개발자는 읽다가 이상하면 물어볼 수 있습니다. “이거 누가 원한 건가요, 이건 어떻게 확인하나요.” 그 질문이 출처 칸과 검증 방법 칸을 대신 채웠습니다.
AI 는 그 질문을 하지 않습니다. 대신 문서를 완성합니다. 출처 칸은 정직하게 비워 두기도 하지만, 비어 있어도 문서 전체는 완성된 모양으로 나옵니다. 검증 방법 칸에는 가장 무난한 값 하나가 들어갑니다. 표준이 틀린 것이 아닙니다. 대화가 메우던 칸을 이제 AI 문서를 받는 PO 가 직접 봐야 합니다.
대화가 메우던 칸을 이제 AI 문서를 받는 PO 가 직접 봐야 합니다.
| 사람에게 넘길 때 | AI 에게 넘길 때 | |
|---|---|---|
| 출처 칸 | 비어 있으면 누군가 물어봤습니다 | 비어 있어도 문서는 완성돼 보입니다. 빈칸을 세야 보입니다 |
| 검증 방법 칸 | 애매하면 개발자가 되물었습니다 | 무난한 값 하나로 전부 채워집니다. 줄마다 다시 골라야 합니다 |
| 문제 근거 | 회의에서 그게 정말 문제냐고 물었습니다 | 근거 없는 문장이 맨 앞에 선 채로 다음 문서가 나옵니다 |
채용관리 세트에서는 모르는 값을 지우지 않고 ‘확인 필요’로 표시하고, 확정할 사람을 함께 적게 했습니다. ‘확인 필요’로 표시한 자리는 18곳이었습니다. 개발에 넘기면 질문으로 돌아왔을 자리가 문서 안에서 미리 보인 셈입니다. 작업 도구 세트의 성공 기준 목표치가 전부 ‘확인 필요’로 남은 것도 같은 표시였습니다.
개인정보 보관 기간에는 임시값을 일부러 넣지 않았습니다
‘확인 필요’ 자리마다 확정 전까지 쓸 임시값도 같이 적었습니다. 확정할 사람이 바꾸라는 표시를 붙인 값입니다. 그런데 개인정보 보관 기간만은 일부러 임시값을 뺐습니다. 법과 규정을 확인해야 하는 값입니다. 확인 전 숫자가 한 번 들어가면 그 숫자가 그대로 운영까지 흘러갈 것 같았습니다.
막힌 곳: 검사 도구가 빠진 것이 없다고 했습니다
채용관리 세트를 검사할 때 한 번 크게 속을 뻔했습니다. 요구와 인수기준의 연결을 자동으로 세는 도구가 빠진 연결 0건을 냈습니다. 알고 보니 그 도구는 제 요구 번호 형식을 아예 읽지 못하고 있었습니다. 아무것도 보지 못했으니 아무것도 빠지지 않은 것이었죠.
그래서 그 결과는 통과가 아니라 ‘측정 못 함’으로 적고, 연결은 검사용 AI 가 하나씩 다시 대조했습니다. 실제로 빠진 것은 없었지만, 그것은 도구가 알려 준 것이 아니었습니다. 앞에서 본 작업 도구 세트의 0건은 이 도구가 아니라 검사용 AI 가 직접 대조한 값입니다.
AI 기획에서 이 형태가 제일 위험하다고 느꼈습니다. 문서도 빠짐없어 보이고 검사도 빠짐없다고 말하는데, 둘 다 속이 비어 있을 수 있습니다.
아직 남은 문제: 검사자도 같은 회사 모델이고, 근거 칸은 여전히 비어 있습니다
만든 쪽과 검사한 쪽이 같은 회사의 AI 모델입니다. 다른 회사 모델로 교차 검사는 아직 해 보지 않았습니다.
검사는 문서끼리의 연결과 형식을 볼 수 있지만, 채용 실무에서 정말 그렇게 일하는지는 보지 못합니다. 비어 있던 근거 칸도 그대로입니다. 담당자 인터뷰도 문의 기록도 AI 가 만들어 줄 수 없기 때문입니다. 작업 도구 세트에서도 교육 현장에 이런 도구 수요가 있다는 문제는 근거를 구하지 못해 ‘확인 필요’로 남아 있습니다.
마치며: ‘연결됐나’가 아니라 ‘옆 칸이 채워졌나’
AI 로 기획하면 PO 의 일은 줄지 않고 옮겨 갑니다. 쓰는 일에서 칸을 보는 일로 갑니다.
그래서 AI 가 만든 기획 문서를 받으면, 요구 문장은 잠시 접어 두고 검증 방법 칸만 세로로 읽어 보시길 권합니다. 모든 줄이 같은 단어로 시작한다면 저장된 값이나 중복 처리, 건수 집계처럼 눈으로는 판정이 나지 않는 줄부터 고르면 됩니다. 그 줄이 아직 확인 방법이 정해지지 않은 요구입니다. 문제 정의서가 있다면 근거 칸이 몇 개 비었는지도 함께 세면 됩니다. 개발 쪽에서 문서를 받는 입장이라면, 그 줄들을 착수 전에 되돌려 달라고 요청할 근거가 됩니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- ISO/IEC/IEEE 29148:2018: https://standards.ieee.org/ieee/29148/6937/
- ISO/IEC/IEEE 29148 요구 명세 템플릿 (ReqView): https://www.reqview.com/doc/iso-iec-ieee-29148-templates/
자체 작업 기준입니다. 2026-09-01~02 연습용 채용관리 기획 세트, 자체 플랫폼 기획 세트, 리서치 근거 정리 1회를 AI 로 만들고 따로 검사한 관측이고, 도메인과 도구가 다르면 비는 칸도 달라집니다.