기획서를 쓸 때 늘 같은 자리에서 멈춥니다. 다 적자니 끝이 없고, 줄이자니 엉뚱한 게 돌아옵니다.
그래서 보통은 감으로 정합니다. 중요해 보이는 건 적고, 사소해 보이는 건 알아서 하겠거니 하고 넘어갑니다. 저도 오래 그렇게 했습니다. 그러다 결과물을 받아 보고 “이건 왜 이렇게 됐지”를 묻게 되고, 그다음 기획서부터는 조금씩 길어집니다.
문제는 더 길게 적는 게 답인지 확인할 방법이 없었다는 것입니다. 어느 칸을 적었을 때 결과가 달라지는지 재본 적이 없었습니다. 그래서 한 번 재봤습니다.
화면 하나를 네 번, 입력은 같게 만들었습니다
전월세 계약 위험 진단 화면 한 장을 만드는 일이었습니다. 첫 자취를 준비하는 사회초년생이 계약서에 서명하기 전에, 자기 계약의 위험 등급과 아직 확인하지 않은 항목을 스스로 보게 하는 화면입니다.
기획서에는 계약 전 확인 항목 18개가 들어 있습니다. 등기부상 소유자와 계약 상대가 같은지, 근저당이 얼마나 잡혀 있는지, 압류나 경매 개시 기입이 있는지, 전입신고를 했는지 같은 것들입니다. 사용자가 항목마다 확인 여부를 답하면 화면이 위험 등급을 매기고, 아직 확인 못 한 항목을 짚어 줍니다. 보증금이 걸린 화면이라 골랐습니다. 무엇이 갈리든 그 갈림이 뭘 뜻하는지가 분명한 소재이기 때문입니다.
기획서를 한 벌 쓰고, AI에게 그 문서만 줬습니다. 그리고 네 번 따로 만들게 했습니다. 넷은 서로의 결과를 모릅니다. 같은 입력, 다른 실행입니다. 궁금한 건 하나였습니다. 어디가 같고 어디가 갈릴까.
비교에는 화면 속 확인 항목 18개와는 다른 목록을 따로 썼습니다. 결과물을 채점하려고 만든 채점 기준 13개입니다. 기준마다 결과물을 브라우저에 띄워 자동으로 눌러 보고 재는 검사 장치로 확인했습니다. 이 검사 장치가 뒤에서 한 번 크게 틀립니다.
적어 둔 칸은 네 번 모두 같았습니다
먼저 기획서가 못 박아 둔 항목입니다.
경계값이 특히 인상적이었습니다. 위험 등급은 두 숫자로만 정해지게 기획서가 규칙을 적어 뒀습니다. 하나는 총부담률(집값 대비 보증금과 앞선 빚을 합한 비율)이고, 다른 하나는 확인 못 한 항목에 매긴 미확인 점수입니다. 두 숫자마다 등급이 바뀌는 경계를 둘씩 숫자로 박아 뒀는데, 네 실행이 전부 같은 지점에서 등급을 바꿨습니다. 화면 표시는 반올림돼서 경계에 걸린 것처럼 보이는데 등급은 안 바뀌어야 하는 까다로운 값도 넷 다 맞혔습니다.
여기까지는 예상하신 대로일 겁니다. 잘 적으면 잘 지킨다, 익숙한 이야기입니다.
안 적어 둔 칸에서는 넷이 각자 달랐습니다
같은 네 번의 실행에서, 기획서가 비워 둔 항목은 이렇게 갈렸습니다.
확인 항목 18개를 답하는 방식부터 보시면, 드롭다운으로 간 쪽은 화면에 선택 상자 18개를 놨고, 라디오 버튼으로 간 쪽은 버튼 72개를 늘어놨습니다. 사회초년생이 계약서 앞에서 채우는 화면인데, 한쪽은 접혀 있고 한쪽은 다 펼쳐져 있습니다.
링크를 감추는 방식 하나가 목적을 반쯤 지웠습니다
가장 크게 갈린 건 마지막 항목입니다. 아직 못 여는 링크를 어떻게 보여줄 것인가.
기획서에는 이렇게 적혀 있었습니다. 위험 등급이 높게 나오면, 그 판정의 근거가 된 항목을 사용자가 하나씩 체크해야 공식 확인 창구 링크가 열린다고요. 체크하기 전에는 링크가 비활성이어야 합니다. 인터넷등기소나 정부24 같은 곳으로 보내는 링크입니다. 넷 다 이 요구를 지켰습니다. 그런데 비활성을 화면에 어떻게 그릴지는 적혀 있지 않았습니다.
이 진단 화면의 목적은 사용자가 미확인 항목을 실제로 확인하러 가게 만드는 것입니다. 그런데 링크를 아예 안 보이게 만든 실행에서는, 사용자가 확인할 창구가 존재한다는 사실을 화면에서 배우지 못합니다. 눌러도 안 되게만 해 둔 실행은 클릭했을 때 반응이 없어 고장처럼 보일 수 있었습니다. 상태만 표시해 둔 실행은 지금은 안 되는 이유와 함께 근거 항목을 체크하면 열린다는 것도 알려 줘서 다음 행동으로 이어졌습니다. 요구는 지켰는데 목적이 반쯤 빠져나간 실행도 있었던 셈입니다. 이게 이 실험에서 제일 오래 들여다본 칸입니다.
넷 다 기획서를 어기지 않았고, 갈린 건 문서였습니다
이 문장을 먼저 놓고 다시 보면, 넷 중 누구도 규칙을 위반하지 않았습니다. 적힌 건 다 지켰고, 안 적힌 건 각자 정했습니다. 그게 전부입니다.
그러니까 결과가 갈린 이유는 실행의 품질 차이가 아니었습니다. 기획서가 그 칸을 안 정했기 때문입니다.
이 결과를 보고 나서 요구사항을 다르게 읽게 됐습니다. 기획서는 지시서가 아니라, 결과가 모일 ‘범위’를 정하는 장치입니다. 적어 둔 칸에서는 하나로 모이고, 비워 둔 칸에서는 실행마다 갈라집니다.
기획서는 지시서가 아니라, 결과가 모일 ‘범위’를 정하는 장치입니다.
네 실행이 기획서의 구멍 세 개도 전부 짚었습니다. 앞에서 본 빈칸 네 항목과는 다른 목록입니다. 첫째, 등급을 매기는 규칙이 아니라 그 다음 단계가 비어 있었습니다. 기획서는 높은 위험이 나오면 “근거가 된 항목”을 하나씩 체크해야 확인 창구 링크가 열리게 했는데, 총부담률만으로 높은 위험이 된 경우에는 근거가 비율이라 체크할 항목이 없습니다. 등급은 넷 다 같게 나왔지만, 그 뒤에 무엇을 체크하게 할지는 기획서가 정하지 않은 셈입니다. 둘째, 공식 확인 창구로 보내는 링크 주소가 정해지지 않았다는 것. 셋째, 계약 유형과 주택 유형을 고르는 칸의 오류 문구가 빠졌다는 것입니다. 기획서의 입력 검증표에는 숫자 입력 칸만 있었습니다.
넷 다 같은 세 곳에서 걸렸고, 각자 다르게 메웠습니다. 앞의 숫자 카드에서 지어낸 경우가 0건이라고 한 건, 근거에 없는 확인 항목이나 수치를 새로 만들어 넣은 경우만 센 값입니다. 빈 곳을 어떤 방식으로 처리할지 각자 정한 건 거기에 넣지 않았습니다. 여러 번 만들어 보면 그 자체가 구멍 탐지기가 되는 셈입니다.
빈칸을 표시하는 방법은 회의 탁자에서 먼저 나왔습니다
이 결론이 저 혼자 겪은 일이 아니라는 걸 나중에 알았습니다. 요구공학 표준(ISO/IEC/IEEE 29148)은 좋은 요구사항의 특성 중 하나로 완전성을 듭니다. 필요한 것이 빠짐없이 적혀 있어야 한다는 뜻입니다. 그런데 현장에서 이걸 지키기 어려운 이유는 명확합니다. 빠진 걸 세는 게 어렵기 때문입니다. 적어 둔 건 눈에 보이는데, 안 적어 둔 건 목록에 나타나지 않습니다.
이 문제를 다루는 방법은 새 도구에만 있는 게 아닙니다. 10년 전 회의 탁자에서 쓰던 방법이 요즘 도구 안으로 들어온 것입니다. Example Mapping은 2015년에 정리된 회의 방법입니다. 사용자 스토리 하나를 놓고 넷이 색이 다른 쪽지를 붙입니다. 노랑은 그 스토리, 파랑은 규칙, 초록은 구체적인 예, 그리고 빨강은 답이 안 나온 질문입니다. 25분쯤 짧게 하는 게 원칙입니다.
핵심은 빨강입니다. 회의에서 답이 안 나온 게 있으면 지우거나 대충 합의하지 않고, 빨강 쪽지로 남겨 둡니다. 빨강이 많으면 그 스토리는 아직 만들 준비가 안 된 것으로 봅니다. 모른다는 사실 자체를 산출물로 만드는 것입니다.
빨강 쪽지가 회의 탁자에서 작동한 이유는, 그 자리에 답을 아는 사람이 같이 있었기 때문입니다. 빨강이 붙으면 누군가 “그건 제가 확인해 올게요” 하고 가져갔습니다. 문서에 안 남아도 사람 사이에서 처리됐습니다.
AI에게 넘길 때는 그 탁자가 없습니다. 빨강 쪽지를 들고 갈 사람이 없으니, 빈칸은 회의로 해소되지 않고 그대로 결과물로 갑니다. 이 실험에서 네 개가 갈린 자리가 정확히 그 빨강들이었습니다.
그래서 순서가 바뀝니다. 회의 시대에는 빈칸을 회의 중에 사람이 가져갔지만, AI 시대에는 빈칸을 문서 안에 표시로 남겨서 결과물이 나온 뒤에도 어디가 추측이었는지 되짚을 수 있어야 합니다. 지우고 통과시키면 그 추측이 어디에 박혔는지 아무도 모릅니다.
2025년부터 나온 명세 주도 개발 도구들, 곧 요구를 정해진 문형으로 쓰게 하거나 모르는 것을 지우지 말고 “확인 필요”로 남기게 하는 도구들도 같은 자리를 건드립니다. 이 도구들을 써 보지는 않았으니 같다고는 못 하고, 같은 지점을 다르게 부르는 것 같다는 정도로 적겠습니다.
이 실험이 한 일도 결국 같습니다. 다르게 만든 게 아니라 여러 번 만들어서, 갈라진 자리를 빈칸 목록으로 바꾼 것입니다. 도구를 쓰면 그 목록을 기획 단계에서 얻고, 이렇게 하면 만든 뒤에 얻습니다. 순서가 다를 뿐 찾는 건 같은 것이었습니다.
막힌 곳: 재는 도구가 거꾸로 판정했습니다
이 실험은 순탄하지 않았습니다. 결과를 브라우저로 직접 재는 장치를 만들어 뒀는데, 그 장치가 여러 번 틀렸습니다.
가장 당황스러웠던 건 이겁니다. 네 실행 중 하나가 비활성 링크 검사에서 혼자 실패로 찍혔습니다. 확인해 보니 그 실행이 오히려 가장 잘 만든 쪽이었습니다. 화면 읽기 프로그램을 쓰는 사용자를 위해 지금 상태가 무엇인지 명시해 뒀는데, 검사기가 그 표시를 못 읽고 반대로 판정한 것이었습니다.
접근성을 신경 쓴 구현이 아무것도 안 쓴 구현보다 낮은 점수를 받은 셈입니다. 이걸 모르고 넘어갔으면 “네 번 중 한 번은 실패한다”는 결론을 냈을 겁니다. 그 결론은 틀린 것이었고, 원인은 실행이 아니라 검사 장치였습니다.
되돌린 결정: 자기 보고 점수를 채점에서 뺐습니다
처음에는 각 실행이 스스로 보고한 자기 점검 결과를 채점에 넣었습니다. 그런데 네 실행을 동시에 돌리는 동안, 화면을 띄워 확인하는 브라우저 도구를 넷이 함께 쓰고 있었습니다. 한 실행은 자기 화면을 점검하다가 다른 실행의 페이지에 잠깐 접속하기까지 했습니다. 만드는 일은 넷 다 각자 빈 폴더에서 따로 했지만, 스스로 매긴 점검 값은 어느 화면을 보고 매긴 것인지 믿고 쓸 수 없게 됐습니다. 그래서 자기 보고 값을 채점에서 빼고, 채점 기준을 하나씩 검사 장치로 다시 재기로 했습니다.
다만 끝까지 다 빼지는 못했습니다. 채점 기준 13개 중 12개는 그렇게 독립적으로 다시 쟀지만, 한 개는 못 쟀습니다. 마우스 없이 키보드만으로 화면을 끝까지 완주할 수 있는지를 보는 기준입니다. 검사 장치가 선택 상자를 키보드로 다루는 데 한계가 있어서, 그 항목만 실행이 스스로 보고한 값에 기대고 있습니다. 확인하지 못했다고 적어 둡니다.
마치며: ‘얼마나 적었나’가 아니라 ‘어디를 비웠나’
기획서를 다 적을 수는 없습니다. 대신 어디가 비었는지는 알 수 있습니다. 그러니 먼저 적을 곳은 갈라지면 곤란한 칸입니다.
실험 쪽 한계도 하나 적어 둡니다. 어떤 항목은 기획서가 너무 확실히 못 박아 둔 나머지 네 실행이 아무 차이도 만들지 못했습니다. 그 항목에서는 재려던 것이 재어지지 않은 셈입니다. 기획서를 덜 적으라는 뜻이 아니라, 하나로 모인 칸만 봐서는 빈칸을 찾을 수 없다는 뜻입니다.
오늘 해 보실 게 하나 있습니다. 다음에 요구사항을 넘기기 전에, 검수를 한 번 더 하는 대신 같은 문서로 두 번 만들어 보세요. 이 경우엔 AI로 두 번째 실행을 돌리는 쪽이 검수를 한 번 더 하는 것보다 쌌습니다. 두 결과가 갈라지는 지점이, 기획서가 비워 둔 칸입니다. 거기서 갈림폭이 큰 것부터 채우면 됩니다. 보증금 지키는 화면이라면 링크를 어떻게 보여줄지가 그 칸이었습니다.
두 번 만들어 보는 건 혼자서도 됩니다. 그런데 팀이 같은 문서를 놓고 하면 훨씬 빨리 보입니다. 사람 수만큼 독립 실행이 생기는 셈이기 때문입니다. 서로 다르게 읽은 자리가 그대로 드러나고, 그 자리가 대개 기획서가 비운 칸입니다.
이 글은 어디를 적나에 대한 이야기였습니다. 그런데 적고 나서도 남는 질문이 있습니다. 적었으면 그걸 지켰는지는 어떻게 확인할까요. 다른 실험에서 그 답을 찾다가 이상한 걸 봤습니다. 네 결과물이 테스트를 전부 통과했는데, 같은 잣대로 채점하니 만점과 최하점으로 갈렸습니다. 다음 편 테스트는 전부 녹색이었는데, AI가 최종 합격을 누를 수 있었습니다에서 그 이야기를 이어 갑니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- ISO/IEC/IEEE 29148:2018: https://standards.ieee.org/standard/29148-2018.html
- GitHub Spec Kit: https://github.com/github/spec-kit
- Example Mapping (Matt Wynne, 2015-12-08): https://cucumber.io/blog/bdd/example-mapping-introduction/
- 4회 실행 실측: 필자 자체 실험