블로그 목록으로
개발

AI 테스트 생성 가이드 만들기: 문서화가 왜 인프라인지 깨달은 과정

2025년 12월 6일·8 분 소요

이전 편에서 이야기했지만, AI로 심리테스트를 만들다 보면 퀄리티가 들쭉날쭉합니다. 처음에는 그게 AI의 한계인 줄 알았습니다. 그런데 테스트를 여러 개 만들면서 보니, AI가 못 만드는 게 아니었습니다. 내가 제대로 된 기준을 안 줬던 겁니다. 매번 새로 요청하면서 어떤 날은 선택지 3개, 어떤 날은 2개, 어떤 날은 5개가 나왔습니다. 결과 유형도 어떤 테스트는 4개, 어떤 테스트는 6개였습니다. 기준이 없으니 일관성이 없을 수밖에 없었습니다.

가이드를 만들기로 했다

나중에 걷잡을 수 없어질 것 같다는 느낌이 들었습니다. 테스트가 10개, 20개가 되면 나중에 하나씩 손보는 게 더 힘들 것이 뻔했습니다. 처음부터 일정한 기준으로 만들어지면, 나중에 고칠 것도 줄어든다고 생각했습니다. 그래서 테스트 생성 가이드를 만들기로 했습니다. 이 가이드를 AI에게 먼저 줘두면, 매번 새로 설명할 필요 없이 일관된 기준으로 테스트를 만들 수 있을 거라고 봤습니다.

AI에게 가이드 만드는 법을 물어봤더니, AI가 질문을 쏟아냈다

가이드 자체도 AI에게 어떻게 만들면 좋을지 물어봤습니다. 그러자 AI가 역으로 여러 질문을 쏟아냈습니다. 문항이 몇 개여야 하는지, 선택지는 최소 몇 개인지, 테스트 컨셉은 어떻게 잡는지, 사용자가 감정이입할 포인트를 어떻게 설계하는지, 파일 구조는 어떻게 되어 있는지, 참고해야 할 기존 문서가 있는지. 막상 답변하려니 정해지지 않은 게 꽤 많았습니다. 가이드를 만든다고 하면서, 기준을 스스로도 제대로 정리하지 못했던 겁니다.

정해야 할 게 생각보다 많았다. 가이드를 만들려면 먼저 기준이 있어야 하는데, 기준이 없으니 AI에게 가이드를 짜달라는 것 자체가 말이 안 됐던 거다.

그래서 순서를 바꿨습니다. 먼저 기준을 제가 직접 정했습니다. 문항 수는 최소 12개, 선택지는 최소 3개 이상 권장 4개, 결과 유형은 최소 5가지 이상. 그리고 AI에게 기준을 넘겨줬더니 그제야 제대로 된 가이드를 잡아줬습니다. 좋은 케이스와 안 좋은 케이스 예시도 함께 넣어줬고, 마지막에는 체크리스트도 만들어줬습니다. 결과적으로 가이드 문서가 꽤 두툼해졌습니다.

가이드를 줬더니 퀄리티가 올라갔다 — 단, 선택지 개수만 빼고

가이드를 넘겨주고 나서 느낌이 달라졌습니다. 이전보다 테스트 결과 유형이 고르게 나왔고, 문체도 어느 정도 일관성을 유지했습니다. 퀄리티가 단번에 올라간다기보다는, 바닥이 높아진다는 느낌이었습니다. 가장 안 좋은 케이스가 줄어들었습니다.

개선이 필요한 부분이 보이면 AI에게 "이 항목이 잘 안 지켜지고 있다"고 이야기하면서 문서를 조금씩 다듬어 나갔습니다. 그런데 수십 번 고친 항목이 있었습니다. 바로 선택지 개수입니다. 가이드에 "최소 3개 이상, 권장 4개"라고 명시해뒀는데도, 선택지가 2개짜리 테스트가 계속 나왔습니다. 항목을 좀 더 강조하거나, 예시를 추가하거나, 틀린 케이스를 명시하거나 해봤지만 완전히 해결되지 않았습니다. 어떤 날은 잘 따르다가, 어떤 날은 또 2개만 나왔습니다. 가이드가 있어도 안 듣는 항목은 결국 안 듣는다는 걸 그때 처음 실감했습니다.

모델을 바꿨더니 문서가 갑자기 먹혔다

Antigravity에서 작업하다가 어떤 이유로 모델을 바꿔봤습니다. Gemini 2.5 Flash였습니다. 그랬더니 이상한 일이 생겼습니다. 그동안 안 듣던 항목들이 갑자기 잘 지켜지는 겁니다. 선택지 개수도 안정적으로 4개가 나왔고, 결과 유형 구조도 가이드에 맞게 나왔습니다. 처음엔 우연이려니 했는데, 몇 번 해봐도 마찬가지였습니다.

Gemini 3.0 Pro가 더 강력한 모델인데, 왜 가이드 준수는 2.5 Flash가 낫게 느껴지는 걸까. 정확한 원인은 모르겠지만, 제 추측은 이렇습니다. 3.0 Pro는 출시된 지 얼마 안 된 모델이라 지금도 지속적인 패치가 이뤄지는 중입니다. 그 과정에서 동작이 조금씩 달라지고, 그게 가이드 준수에도 영향을 주는 게 아닐까 싶습니다. 실제로 3.0 Pro도 어떤 날은 가이드를 잘 따르고, 어떤 날은 또 안 따르는 식의 들쭉날쭉함이 있었거든요. 아직 안정화가 덜 된 모델이라 그런 게 아닐까 하는 생각입니다.

지금 방식: 모델 용도를 나누고, 매번 검수한다

그래서 지금은 모델을 용도에 따라 나눠서 씁니다. 기획이나 코드 작업처럼 복잡한 추론이 필요한 작업은 Gemini 3.0 Pro를 씁니다. 이 작업은 3.0 Pro가 확실히 더 잘합니다. 반면 테스트 데이터 생성처럼 가이드를 따라야 하는 반복 작업은 지금 시점에서는 2.5 Flash가 더 안정적이라고 느껴서, 그쪽으로 넘깁니다. 3.0 Pro가 더 안정화되면 달라질 수도 있지만, 일단 지금은 이 방식이 가장 무난합니다.

그리고 어떤 모델을 쓰든 결과물은 반드시 검수합니다. 가이드를 따르지 않은 항목이 보이면, 가이드 링크를 다시 걸면서 "이 부분이 처리가 안 됐다"고 짚어줍니다. 처음엔 이걸 귀찮다고 느꼈는데, 이게 사실 당연한 과정입니다. 사람이 작성한 결과물도 리뷰를 하는데, AI 결과물이라고 그냥 쓰면 당연히 문제가 생깁니다. 완전히 자동화하기보다 검수 흐름 안에 AI를 두는 게 맞다는 걸 받아들이게 됐습니다.

게임 가이드로도 확장했다

테스트 가이드를 만들고 나서 얼마 지나지 않아, 게임을 추가하기로 결정했습니다. 회사에서 반사신경 테스트나 사과게임 같은 간단한 게임류가 유행하는 걸 보고, 사이트에 사람을 더 끌어들이는 데 게임이 도움이 될 것 같다고 판단했습니다. 테스트와 심리 콘텐츠만으로는 유입 경로가 한정적이니까요.

그때 테스트 가이드를 만들면서 배운 게 있었기 때문에, 게임 가이드도 처음부터 제대로 만들자고 생각했습니다. 기준을 먼저 정하고, 그 기준을 바탕으로 가이드를 잡았습니다. 게임마다 공통 훅을 써야 한다든지, 결과 화면 컴포넌트를 통일해야 한다든지 하는 내용들이 들어갔습니다. 테스트 가이드를 만들 때와 같은 과정이었는데, 이번엔 처음부터 순서를 알고 있으니 훨씬 빠르게 정리됐습니다.

다음 편에서는 게임을 추가하면서 생긴 일들을 이야기할 예정입니다. 회사에서 유행하는 게임을 보며 "이거 만들어야겠다"고 생각한 것에서부터, 실제 게임을 구현하면서 맞닥뜨린 이야기들입니다.

문서화는 도구가 아니라 인프라다

이 과정을 거치면서 느낀 건 하나입니다. AI를 잘 쓰는 것과 문서화를 잘 하는 건 따로가 아닙니다. 같은 AI 모델을 써도 가이드가 있는 경우와 없는 경우의 결과물 차이는 꽤 큽니다. 그리고 가이드가 있더라도 어떻게 썼느냐에 따라 결과가 다릅니다. 결국 AI에게 잘 맡기는 것도, 내가 무엇을 원하는지 미리 구체적으로 정리해두는 것에서 시작합니다.

나중에 걷잡을 수 없어질 것 같아 미리 문서화를 진행한 것인데, 그게 맞는 판단이었습니다. 테스트가 늘어날수록, 게임이 늘어날수록, 가이드 없이 만든 것들을 나중에 수정하는 비용이 쌓입니다. 문서화는 효율을 높이는 도구가 아니라, 프로젝트가 지속될 수 있게 해주는 인프라입니다. 그걸 가이드 문서를 만들면서 몸으로 배웠습니다.

관련 콘텐츠

다른 글 더 보기