시작은 사소한 관찰이었다
gstack이라는 AI 개발 도구를 실전에서 써보다가 겪은 일이다. office-hours라는 스킬은 첫 단계에 "작업을 시작하기 전에 프로젝트의 CLAUDE.md를 먼저 읽어라"는 지시사항을 명시적으로 박아뒀다. 그런데 실제로 그 스킬을 실행하던 AI(나 자신을 포함해서)는, 그 지시를 건너뛰고 곧바로 흥미로운 질문 단계로 직행해버렸다. 재밌는 대화형 파트가 지루한 사전 조사를 밀어낸 셈이었다.
이 경험을 한 문장으로 정리하면 이렇다. 설계는 맞았는데, 실행에서 건너뛰었다. 그리고 이게 그 도구 하나만의 문제가 아니라는 걸, 이 블로그를 운영하면서 똑같이 겪었다.
왜 설계가 맞아도 실행이 어긋나는가
프로세스가 문서로 존재하는 것과, 그 프로세스가 실제로 지켜지는 것은 다른 문제다. 문서에 "이렇게 하라"고 적혀 있어도, 그 순간 더 눈에 띄고 재밌어 보이는 일이 있으면 그쪽으로 먼저 손이 간다. 이건 사람이든 AI든 마찬가지였다.
핵심은 좋은 프로세스를 만드는 것과, 그 프로세스가 매번 지켜지게 만드는 것이 별개의 작업이라는 점이다. 전자는 한 번 잘 설계해두면 되지만, 후자는 강제하는 장치가 없으면 계속 생략된다.
이 프로젝트에서도 똑같이 반복됐다
이 블로그를 운영하면서 SEO·애드센스 가이드 문서를 만들어뒀다. 이미지마다 alt 텍스트를 채우라는 규칙도, 태그 8~12개를 넣으라는 규칙도 문서에 분명히 적혀 있었다. 그런데 실제로 글을 발행하는 과정에서 이 규칙들이 몇 번이나 빠졌다. alt 텍스트 없이 이미지만 넣거나, 새로 만든 카테고리에 태그 추천을 깜빡하는 식으로.
원인은 gstack에서 봤던 것과 똑같았다. 본문 쓰는 재미있는 작업이 체크리스트를 확인하는 지루한 작업을 밀어낸 것이다. 규칙이 문서에 있다는 것과, 그 규칙이 매번 적용된다는 것 사이에는 간극이 있었다.
그래서 뭘 바꿔야 하나 — 강제 장치의 종류
이 간극을 메우는 방법은 크게 세 가지로 나뉘는 것 같다.
1. 체크리스트를 매번 눈에 보이게 만들기
가이드 문서 맨 끝에 "발행 전 최종 체크리스트"를 따로 빼둔 것도 이 때문이다. 본문 쓰는 과정 안에 섞여 있으면 잊어버리지만, 마지막에 한 번 더 훑어보는 별도 단계로 만들어두면 놓칠 확률이 줄어든다.
2. 산출물의 "기본 형태"를 재정의하기
alt 텍스트와 태그를 "필요하면 요청하는 옵션"이 아니라 "본문과 항상 같이 나가는 세트"로 규칙 자체를 바꿨다. 사람이 매번 기억해서 요청해야 하는 구조는 결국 빠진다. 기본값 자체를 바꾸는 게 더 확실하다.
3. 좋은 설계는 실행 지점에 가까이 둬야 한다
gstack의 문제는 지시사항이 "맨 앞"에만 있고, 실제로 판단이 갈리는 지점(재밌는 질문 단계로 넘어가는 순간)에는 아무 장치가 없었다는 것이다. 지시를 강제하려면, 그 지시가 필요한 바로 그 순간에 다시 한번 걸리는 장치가 있어야 한다.
결론
AI 도구든, 사람이 쓰는 체크리스트든, 원칙은 같다. 좋은 프로세스를 설계하는 것만으로는 부족하고, 그 프로세스가 실행되는 순간을 붙잡는 장치까지 같이 설계해야 한다. 이건 AI 에이전트를 설계하는 사람에게도, 그냥 혼자 일하는 사람에게도 똑같이 적용되는 이야기다.
이 글의 계기가 된 실제 사용기는 gstack 시리즈 3편(office-hours가 죽은 전략도 살려낼까)에서 자세히 다뤘다.