AI에게 기획 문서를 맡기고 마지막에 한 줄을 붙이는 분이 많습니다. “다 쓰고 나면 스스로 점검해 줘.” 그러면 AI는 체크리스트를 채워서 돌려줍니다. 항목마다 ‘지킴’이 적혀 있습니다.
저도 그랬습니다. 그리고 그 ‘지킴’을 믿었습니다.
이 글은 서비스기획의 첫 단계인 요구사항 도출을 AI에게 넘겨 본 기록입니다. 방법은 비즈니스 분석 표준인 BABOK의 기법을 빌렸습니다. 같은 산출물을 세 번 검사했는데, 만든 쪽이 스스로 한 점검에서는 걸린 게 0건이었습니다. 따로 세운 검사자는 같은 산출물에서 조항 판단이 흔들린 자리를 찾아냈습니다.
기획자가 손으로 하던 문서 분석을 AI에게 넘겼습니다
서비스기획을 시작하면 먼저 현장 문서를 봅니다. 담당자가 쓰는 엑셀, 사내 규정, 양식 같은 것들입니다. 사람이 인터뷰에서 말하지 않은 요구가 거기에 남아 있기 때문입니다. 엑셀의 열 이름과 빈칸, 메모 칸에 적힌 “확인 필요” 같은 글자가 곧 요구입니다.
BABOK v3(비즈니스 분석 지식 체계, 국제 비즈니스 분석 협회 IIBA가 펴낸 표준)는 이 일을 Document Analysis(문서 분석, §10.18)라는 기법으로 정리해 둡니다. 저는 BABOK의 기법들을 AI가 따를 수 있는 판정 규칙 카드로 옮겼습니다. 카드는 기법마다 한 장씩, 결과가 지켜야 할 규칙 몇 줄과 흔한 실수 예시 몇 개를 적은 짧은 문서입니다. 기법 설명을 옮겨 적은 게 아니라, 이 기법을 쓰면 어떤 결과가 나와야 하고 어떤 실수가 흔한지를 제 말로 적었습니다.
시험 자료는 가상의 채용 회사를 만들어 준비했습니다. 지원자 현황을 관리하는 엑셀 한 벌과 인사 규정 발췌 한 벌입니다. 실제 회사 자료는 쓰지 않았습니다.
AI는 문서 분석을 끝까지 해냈습니다. 엑셀의 열 16개를 빠짐없이 옮겼고, 규정과 엑셀이 어긋나는 자리를 표로 정리했고, 요구사항 후보 10건을 뽑았습니다. 자료만으로 판단할 수 없는 것은 9건을 ‘확인 필요’로 따로 모았습니다. 겉보기에는 흠잡을 데가 없었습니다.
만든 쪽의 점검은 0건이었습니다
AI는 산출물 끝에 자가 점검표도 붙였습니다. 카드의 규칙 다섯 개마다 지켰는지를 스스로 적은 표입니다. 다섯 칸 모두 ‘지킴’이었습니다.
이어서 같은 작업 흐름에서, 만든 맥락을 그대로 가진 채로 검토를 시켰습니다. BABOK의 Reviews(검토, §10.37) 기법을 옮긴 카드를 주고, 방금 만든 산출물을 카드에 적힌 흔한 실수 예시(당시 3개)에 하나씩 대 보게 했습니다. 걸린 예시는 0개였습니다.
0건이 나오면 검토가 실제로 대상을 봤는지 한 번 더 확인하라는 규칙도 카드에 넣어 두었습니다. AI는 그 규칙도 따랐습니다. 원천 엑셀의 열을 다시 세어 산출물과 하나씩 맞춰 봤고, 16개 모두 맞는다고 적었습니다.
여기까지는 저도 안심했습니다. 세는 일은 AI가 맞게 했으니까요. 저는 그 세는 절차 자체가 결함을 잡을 수 있는지도 따로 확인했습니다. 산출물에서 열 하나를 지운 사본을 만들고, 원천 열 수와 산출물 행 수를 제 스크립트로 세어 맞춰 봤더니 16이 15로 줄어든 것이 바로 걸렸습니다. AI의 점검이 아니라 제가 돌린 확인이었지만, 적어도 세는 방식의 점검은 결함을 잡을 수 있다는 건 알 수 있었습니다.
문제는 같은 날 같은 산출물을 다른 검사자에게 보였을 때 드러났습니다. 다른 모델도 사람도 아닌, 같은 AI를 새 대화에서 부른 검사자입니다. 달라진 것은 산출물을 만든 대화의 맥락을 전혀 모른다는 점 하나였습니다. 이 검사자에게는 기법 카드와 산출물, 원천 자료만 줬고, 앞선 검사 결과는 보여 주지 않았습니다. 이틀 뒤에는 같은 검사자 지시문을 저장해 두고 불러 써서 한 번 더 봤습니다.
비교의 기준은 세 검사 모두에 똑같이 준 규칙 다섯 개입니다. 도식의 ①은 앞에서 말한 자가 점검표와, 같은 흐름에서 이어서 시킨 검토를 한 줄로 묶은 것입니다.
예시가 하나 늘어난 경위가 이 글에서 가장 이상한 대목입니다. 만든 쪽은 작업을 마치고 남긴 소감에 ‘규정 조항을, 현장에서 실제로 그렇게 하고 있는지 기록으로 확인하지 않은 채 요구로 바로 올리는 실수’를 조심해야 할 예시 후보로 직접 적었습니다. 두 조항을 보류하면서 그 유혹을 느꼈다고요. 그 예시를 카드에 더했고, 따로 세운 검사자에게 걸린 것이 바로 그 예시였습니다. 만든 쪽은 위험을 알아채 이름까지 붙여 놓고도, 자기 산출물의 기록 보존 기간 조항에서는 같은 실수를 했습니다(바로 아래에서 자세히 봅니다). 자가 점검표에는 ‘지킴’이라고 적었고요.
따로 세운 검사자는 조항마다 다른 잣대를 찾았습니다
따로 세운 검사자가 가장 먼저 짚은 것은 규정 조항을 다루는 기준이었습니다. 인사 규정에는 요구사항으로 올릴 만한 조항이 여럿 있었습니다. AI는 그중 두 조항을 “엑셀만으로는 지켜지는지 판정할 수 없다”며 보류했습니다. 그런데 기록 보존 기간을 정한 다른 조항은 요구사항 후보로 올렸습니다. 보존 대장이 있는지 모른다고 스스로 ‘확인 필요’에 적어 두고서였습니다.
자가 점검표의 해당 규칙 칸에는 ‘지킴’이 적혀 있었습니다. 검사자들이 못 지켰다고 본 규칙은 이렇게 판정을 보류하는 기준, 그리고 자료에 없는 내용을 더하지 않는다는 기준에 관한 것이었습니다.
나머지 발견도 성격이 비슷했습니다.
- 규정의 “파악하여 전형에 반영할 수 있다”를 요구사항에서는 “파악한다”로 옮겼습니다. 할 수 있다는 재량이 해야 한다는 의무가 됐습니다.
- 자료가 이름만 언급한 붙임 문서의 내용을 산출물이 채워 넣었습니다. 그 내용은 자료 어디에도 없었습니다.
- 규정은 지원서류를 채용 확정일부터 180일 보존한 뒤 파기하라고 정합니다. AI는 숨김 시트에 남은 날짜 붙은 사본을 파기하지 않은 증거로 썼습니다. 그런데 180일을 세는 기준은 채용 확정일이고, 사본에 붙은 날짜는 사본을 만든 날입니다. 자료 어디에도 채용 확정일이 없으니, 이 사본이 파기했어야 할 서류인지부터 판정할 수 없었습니다.
하나하나는 작아 보여도 그대로 넘어가면 비용이 됩니다. 재량이 의무로 바뀌면 개발 범위가 늘어나고, 판정할 수 없는 사본을 위반 증거로 쓰면 없는 문제를 보고하게 됩니다.
반대로 틀리지 않은 것도 있었습니다. 검사자가 대조해 보고한 수치 14건은 전부 원문과 맞았습니다. 열 개수, 행 개수, 건수처럼 세면 확인되는 것은 만든 쪽도 정확했습니다.
자가 점검이 놓친 결함은 전부 판단의 일관성에 관한 것이었습니다. 제가 일부러 넣어 시험한 결함은 열 하나가 빠진, 세면 드러나는 결함이었습니다. 세는 검사가 작동한다는 확인이 판단까지 본다는 보증은 아니었습니다.
세는 검사가 작동한다는 확인이 판단까지 본다는 보증은 아니었습니다.
사람 팀에서 검토는 대개 다른 눈이 했습니다
BABOK v3는 요구사항이 잘 쓰였는지 확인하는 과업을 Verify Requirements(요구사항 검증, §7.2)로, 맞는 것을 썼는지 확인하는 과업을 Validate Requirements(요구사항 타당성 확인, §7.3)로 나눕니다. 검증 과업에서 쓸 기법으로 드는 것 가운데 하나가 Reviews입니다. 앞에서 제가 카드로 옮긴 바로 그 기법입니다. 사실 저는 그 카드에 ‘산출물을 만든 사람이 아닌 눈으로 결함을 찾을 때 쓴다’고 적어 두었습니다. 규칙은 써 놓고, 구조는 같은 작업 흐름 안에 둔 겁니다.
제 경험으로는 사람 팀에서 검토는 대개 다른 사람이 했습니다. 동료 기획자가 보거나 현업 담당자가 보거나, 적어도 쓴 사람이 하루 자고 난 뒤에 봤습니다. 누가 보라고 따로 정하지 않아도 조직이 자연스럽게 그 칸을 채웠습니다. 쓴 사람과 보는 사람의 머릿속이 달랐으니까요.
AI에게 “스스로 점검해 줘”라고 하면 그 칸이 비어 버립니다. 같은 대화 안의 AI는 방금 한 판단의 이유를 그대로 기억하고 있습니다. 두 조항을 보류하고 한 조항을 올린 그 판단이, 점검할 때도 똑같이 그럴듯해 보입니다. 쓴 사람이 잠도 안 자고 바로 자기 글을 다시 읽는 셈입니다.
그래서 검토를 AI에게 넘길 때 옮겨야 하는 것은 체크리스트가 아니라 거리였습니다. 사람 팀에서 조직이 공짜로 만들어 주던 그 거리입니다.
되돌린 결정: 검토를 만드는 쪽 안에 두지 않기로 했습니다
처음 설계에서는 검토가 만드는 흐름의 마지막 단계였습니다. 산출물을 만들고, 같은 흐름 안에서 검토 카드를 꺼내 스스로 보게 했습니다. 편했고, 결과도 한 번에 나왔습니다.
이 결정을 되돌렸습니다. 이제 만든 대화의 맥락을 받지 않는 검사자를 따로 두고, 고칠지 말지는 제가 정합니다.
세 번째 검사가 끝난 뒤, 검사자가 찾은 결함을 기법 카드의 흔한 실수 예시로 4개 더 넣어 8개가 됐습니다. 앞에서 본 실제 사례들입니다. 다음 번 만드는 쪽은 이 예시를 보고 시작합니다.
PMBOK 프로세스로 넓혀도 같은 일이 되풀이됐습니다
같은 기간에 같은 방식을 프로젝트 관리 표준인 PMBOK의 프로세스들에도 적용하고 있었습니다. 이해관계자 식별, 리스크 분석, 일정 도출 같은 일을 가상 자료로 돌린 일곱 번 가운데 여섯 번은 자가 점검이 스스로 찾은 불일치가 0건이었고, 따로 세운 검사자는 매번 무언가를 찾았습니다. 다만 세는 것과 판단을 가른 이야기는 BABOK 문서 분석 한 건에 한정합니다.
아직 남은 문제: 검사자도 매번 같은 것을 보지는 않습니다
따로 세운 검사자를 두 번 돌렸는데, 부차적인 판정은 회차마다 달랐습니다. 한쪽이 짚은 것을 다른 쪽은 짚지 않았습니다. 첫 번째는 새 대화에 검사자 역할 지시문을 붙여 넣었고, 두 번째는 같은 지시문을 미리 저장해 두고 불러 썼습니다. 조항마다 잣대가 다르다는 핵심 결함은 두 번 모두 잡았으니, 새 대화 하나로도 핵심은 잡힌다는 뜻이기도 합니다.
그래서 검사 건수를 품질 점수로 쓰지 않기로 했습니다. 같은 산출물인데 못 지킨 규칙이 한 번은 1개, 한 번은 2개로 나왔으니까요. 두 번 돌려 겹친 결함은 고치고, 한 번만 나온 결함은 제가 원문을 열어 직접 봅니다.
더 큰 빈칸도 있습니다. 여기까지 전부 제가 만든 가상 자료였습니다. 실제 현장 문서는 더 지저분하고, 사람이 이 카드로 직접 끝까지 돌려 본 적은 아직 없습니다. 가상 자료에서 잡힌 결함 유형이 실제 문서에서도 같은 비율로 나올지는 모릅니다.
마치며: ‘스스로 점검했나’가 아니라 ‘누가 다른 눈으로 봤나’
이번 문서 분석에서 AI가 채운 자가 점검표는 세는 일에서는 믿을 만했습니다. 조항마다 같은 잣대를 댔는지, 원문보다 세게 옮기지 않았는지 같은 판단에서는 스스로 걸리지 않았습니다. 제게는 검토를 쓰기와 다른 기법으로 떼어 두는 뜻이, 수행자가 AI로 바뀌자 오히려 선명해졌습니다.
AI에게 기획 문서를 맡기고 있다면, 다음 번에는 “스스로 점검해 줘” 대신 새 대화를 하나 열어 보시길 권합니다. 산출물과 원천 자료, 점검 기준만 붙여 넣고, 앞 대화에서 무슨 판단을 했는지는 알려 주지 마세요. 점검 기준은 거창하지 않아도 됩니다. ‘같은 처지의 항목에 같은 기준을 댔나’, ‘원문의 할 수 있다를 해야 한다로 바꾸지 않았나’ 같은 문장 몇 줄이면 시작할 수 있습니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
- PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide): https://www.pmi.org/standards/pmbok