개요
지난 글에서 이런 다짐을 적었다. 다음에는 AI에게 완성 코드를 먼저 요청하지 말고, 구현 방법과 그 이유, 다른 방법과의 trade-off를 먼저 물어보겠다고.
말은 쉽다. 그래서 진짜로 해봤다.
새 Unity 프로젝트를 시작하면서 AI의 역할을 아예 둘로 쪼갰다. 하나는 프로젝트 설계를 도와주는 기획 AI, 다른 하나는 코드를 절대 주지 않고 조언만 하는 멘토 AI다.
그리고 첫날, 코드는 한 줄도 안 썼다. 대신 기획서(spec)를 내 손으로 처음부터 썼다.
이번 글이 답할 질문은 하나다. 코드를 주지 않는 AI는 과연 쓸모가 있었을까?
1. 역할을 둘로 나눴다 — 기획 AI와 멘토 AI
지난 프로젝트를 돌아보면 사람이 아이디어를 내고, 기획 AI가 RAG를 통해 세부 spec을 쓰고, AI가 구현하고, 사람이 QA를 진행했다. 문제가 터지면 AI에게 디버깅을 요청하고, 해결이 안되면 나도 같이 확인을 하며 수정을 진행했다.
무엇을 어떻게 만들지조차 내 손을 거치지 않았다. 그래서 마지막에 트라우마가 하늘로 날아갔을 때, 나는 내가 쓰지도 않은 명세서로 만들어진 내가 쓰지도 않은 코드를 거꾸로 공부해야 했다..
이번엔 순서를 바꿨다.
바뀐 건 두 가지다. spec을 내가 쓴 것, 그리고 멘토 AI에게 코드 생성 권한을 주지 않은 것. 두 번째는 프롬프트 수준의 부탁이 아니라 아예 그런 규칙을 가진 별도 모드로 만들어뒀다. 힌트는 주되 답은 주지 않고, 내가 시도한 결과를 보고해야만 한 단계 더 알려주는 방식이다.
처음엔 이게 답답하고 느릴 것 같았다. 실제로는 답답하기보단 이해를 하는 과정이 좋았다. 코드를 못 주니까 AI가 할 수 있는 게 질문하는 것뿐이었고, 그 질문들이 전부 내 기획서를 향했다.
내가 쓴 문서가 생기니까 그제서야 AI가 반박할 대상이 생겼다!
2. 첫 반박은 내 문서 안에서 나왔다 — “안 만들 것” 목록의 힘
spec을 쓸 때 항목을 네 개 두라는 조언을 받았다. 코어 루프 / 플레이어의 행동 목록 / 승리·패배 조건 / 안 만들 것 목록.
앞의 셋은 어느 기획서에나 있다. 네 번째가 낯설었는데, 이유가 명확했다. 앞의 셋은 계획이지만 네 번째는 계약이라는 것이다. 지금 “안 만든다”고 못 박지 않으면 마감 사흘 전에 반드시 만들고 있을 것들 — 상점, 스킬트리, 세이브, 튜토리얼 같은 것들 말이다.
그리고 이 목록이 바로 첫 번째 오해를 잡아냈다.
| 내가 쓴 곳 | 내가 쓴 내용 |
|---|---|
| 안 만들 것 | 상점 — 다회차 기획은 스케일이 커져서 제외한다 |
| 코어 루프 | 생존자와 교환을 통해 무기를 얻을 수 있다 |
같은 문서 안에서 헷갈릴 만하게 내가 작성을 했던 것이다.. 재화를 내고 아이템을 받는 구조는 얼핏보면 이름만 다를 뿐인 상점으로 보이지만, 나는 세계관에 맞도록 컨셉을 작성해둔 것이었다.
( 뱀서류에 있는 선택증강 중 능력치, 무기를 고를 때 어떻게 무기 선택지가 가능한가에 대한 핍진성 )
단순 구현 기획에 컨셉 사항을 작성해 소통의 오류가 날 만한 지점을 검토를 통해 잡아낼 수 있었던 거다. 재밌는 건 이게 AI가 외부 지식으로 잡아낸 게 아니라는 점이다. 내 문서의 A항목과 B항목을 나란히 놓고 읽었을 뿐이다. 그런데 내가 쓴 나는 그걸 찾아내지 못했다.
기획서는 내가 쓴 걸 내가 못 읽는다. 두 항목을 나란히 읽고 객관적으로 봐줄 사람(또는 AI)이 필요하다.
3. 규칙 세 개가 합쳐져 구멍이 됐다 — 도망만 쳐도 이기는 게임
두 번째 사고는 훨씬 골치 아팠다. 하나하나는 전부 멀쩡한 규칙이었기 때문이다.
내 게임은 5분을 버티는 좀비 서바이버다. 중간에 보스가 나오고, 보스전 동안에는 메인 타이머가 멈춘다. 제한시간 안에 못 잡으면 보스가 광폭화하면서 멈췄던 타이머가 다시 돈다. 그리고 플레이어에게는 무적 시간이 붙은 대시가 있다.
각각은 아무 문제가 없다. 그런데 셋을 합치면 이렇게 된다.
보스를 안 잡아도 된다. 광폭화하게 내버려 두고 대시로 도망만 다니면 타이머는 흐르고, 5분이 되면 게임을 이긴다. 코어 루프 첫 줄에 “좀비를 물리칠 수 있다”고 써놓고, 정작 안 싸우는 쪽이 정답이 되는 게임을 만들고 있었던 것이다.
이건 밸런싱으로 못 고친다. 숫자를 어떻게 만져도 도망 경로 자체가 사라지지 않는다. 규칙의 구멍이라 규칙으로 막아야 했고, 결국 승리 조건을 “5분 버티기”에서 “최종 보스 격파”로 바꿨다.
여기서 제일 중요한 건 이걸 코드 없이 잡았다는 점이다. 만약 그냥 만들었으면 어떻게 됐을까. 아마 D9쯤 테스트 플레이하다가 “어? 안 싸워도 이기네” 하고 알게 됐을 거고, 그때는 이미 보스 FSM과 타이머 로직이 다 짜여 있었을 거다.
지난번엔 만들고 나서 디버깅했다. 이번엔 만들기 전에 디버깅했다.
4. 숫자가 없는 문장은 사양이 아니다
세 번째로 자주 지적받은 건 문장의 종류였다. 나는 이렇게 썼다.
보스는 엄청난 속도로 플레이어를 따라다니기에
사실상 게임 오버에 비슷하게 유도됨
읽으면 무슨 말인지 알겠다. 그런데 이걸로는 내일 뭘 만들어야 하는지 알 수 없다. “엄청난”은 숫자가 아니고 “사실상 게임 오버”는 상태가 아니다. 이동속도 배수가 1.2인지 2인지에 따라 도망칠 수 있는 게임과 절대 못 도망치는 게임으로 완전히 갈리는데, 그 결정이 문서에 없으니 결국 코딩하다가 즉흥적으로 정하게 된다.
고친 뒤는 이렇다.
| 고치기 전 | 고친 뒤 |
|---|---|
| 엄청난 속도로 따라다닌다 | 이동속도 배수 2로 증가한다 |
| 사실상 게임 오버 | HP는 그대로 깎이며 죽일 수 있다 |
| 좀비가 많이 나온다 | 동시 존재 최대 300마리 |
| 대시로 피할 수 있다 | 거리 3~5배 / 쿨다운 1~2초 / 무적 0.2~0.3초 |
마지막 줄은 일부러 범위로 남겼다. 직접 움직여보기 전엔 확정할 수 없는 값이라, “테스트로 확정한다”는 것까지가 결정이다. 모르는 걸 아는 척 숫자로 박는 것보다 이게 정직하다.
사양서의 문장은 읽는 사람이 이해하는 게 아니라, 내일의 내가 그걸로 뭘 만들지 알 수 있어야 한다.
5. 아직 코드는 한 줄도 없다 — 이게 손해인가
하루를 통째로 문서에 썼다. 마감이 정해진 상황에서 이게 맞나 싶은 생각이 당연히 들었다..
일단 세어보면 이렇다. 코드 없이 잡은 것이 자기모순 1건, 규칙 구멍 1건, 정의되지 않은 숫자 4건, 조용히 늘어난 기능 1건이다. 특히 무기는 처음에 “2종 택 1”이라고 써놓고 목록을 적을 때 슬그머니 3종이 되어 있었다. 이런 건 만들다 보면 그냥 넘어간다. 넘어가서 마지막에 시간이 없어진다.
물론 이 방식이 더 낫다고 말하기엔 아직 이르다. 코드를 한 줄도 안 써봤으니 검증된 게 없다. 문서만 예쁘고 정작 구현에서 다 무너질 수도 있다. 그건 다음 편에서 알게 될 것 같다.
다만 하나는 확실해졌다. 지난 글에서 “AI가 아는 만큼이 아니라 내가 아는 만큼 AI를 쓸 수 있었다”고 썼는데, 이번에 그 문장의 뒷면을 봤다. AI에게 코드를 못 만들게 하면, AI는 내가 얼마나 모르는지를 계속 알려주는 도구가 된다.
코드를 받는 AI는 결과를 주고, 코드를 안 주는 AI는 질문을 준다.
정리
- 역할 분리: 설계를 돕는 기획 AI와, 코드를 주지 않고 조언만 하는 멘토 AI로 나눴다.
-
순서 변경:
아이디어 → AI가 spec → AI가 구현 → 내가 디버깅에서아이디어 → 내가 spec → AI가 반박 → 내가 수정으로 바꿨다. - 안 만들 것 목록이 제일 크게 작동했다. 코어 루프와 나란히 놓자 내 문서 안의 자기모순이 드러났다.
- 규칙의 구멍은 각 규칙이 멀쩡해도 생긴다. 도망만 쳐도 이기는 경로가 있어서 승리 조건을 바꿨다.
- 숫자 없는 문장은 사양이 아니다. “엄청난 속도”를 “이동속도 배수 2”로 바꾸는 게 기획서의 일이다.
- 아직 검증 안 됨: 코드를 안 썼으니 이 방식이 더 나은지는 모른다. 다음 편에서 확인한다.
참고 자료
한줄 평
- 하루 정돈 기획에 투자해도 괜찮죠 아무래도 ㅎㅎ;