AI Agent가 쓴 100번째 글

이 글은 이 블로그의 100번째 글이에요. 그런데 본문을 제가 한 줄도 직접 타이핑하지 않았어요. 자료 수집부터 초안, 정합성 검증까지 Claude Code 파이프라인이 돌렸거든요. 비결은 똑똑한 프롬프트 한 방이 아니라, 글쓰기와 검증을 단계로 쪼갠 뒤 규칙을 한 파일에 모은 구조였어요.

460줄짜리 커맨드가 후반부를 잊어버렸다

처음엔 슬래시 커맨드 하나에 다 맡겼어요. /write-post 주제 를 부르면 460줄짜리 지침이 글을 끝까지 뽑아냈죠. 처음 몇 편은 그럴듯했어요.

근데 금방 이상한 게 보였어요. 파일 앞쪽 규칙은 잘 지키는데, 뒤쪽 규칙은 슬그머니 흐려지더라고요. em-dash 쓰지 말라는 문장이 200번째 줄쯤에 있으면, 정작 글에는 em-dash가 섞여 들어왔어요.

중간에 멈출 수도 없었어요. 자료만 다시 모으고 싶어도, 검증만 따로 돌리고 싶어도 방법이 없었죠. 460줄이 처음부터 끝까지 한 덩어리라 부분 실행이라는 개념 자체가 없었거든요.

처음엔 '지침을 더 세게 쓰면 되겠지' 했는데 아니었어요. 문제는 문장이 약해서가 아니라, 그 460줄이 한 순간에 통째로 올라와 있다는 것 자체였어요.

쪼갰더니 이번엔 규칙이 흩어졌다

그래서 일을 쪼갰어요. 글 한 편을 만드는 과정을 자료 검토, 집필, 정합성 검증, 표현 다듬기, 이렇게 네 개의 서브에이전트로 나눴죠. 서브에이전트는 각자 맡은 일만 처리하는 작은 에이전트예요. 책임이 흩어지니 한 에이전트가 후반부를 잊는 문제는 줄었어요.

근데 새 문제가 생겼어요. 'em-dash 금지' 같은 규칙을 네 파일에 다 적어둬야 했거든요. 규칙 하나를 고치면 네 군데를 똑같이 고쳐야 했고, 한 곳을 빼먹으면 에이전트마다 다르게 행동했어요. 규칙의 단일 출처, 그러니까 SSOT(Single Source of Truth)가 무너진 거예요.

집필 에이전트가 잡아둔 뉘앙스가 검증 에이전트로 넘어가며 조금씩 닳기도 했고요. 쪼개는 건 맞는 방향이었는데, 쪼갠 조각들을 묶어줄 중심이 없었어요.

규칙은 한 파일에, 일은 단계로

지금 구조는 규칙과 일을 분리해요. 규칙은 SHARED.md 한 파일에 전부 모아두고, 각 스킬은 자기한테 필요한 섹션만 그때그때 읽어가요. 'em-dash 금지'를 고칠 일이 생기면 이제 한 곳만 손대면 돼요. SSOT가 돌아온 거죠.

스킬은 SKILL.md 파일 하나가 입구인 작은 기능 묶음이에요. 디렉토리 이름이 그대로 /명령어가 되고요. 재밌는 건, 제가 커맨드에서 스킬로 옮겨온 이 길이 공식 문서가 가리키는 방향과 같았다는 거예요.

일하는 순서는 단계(Phase)로 나뉘어요. 그런데 사용자가 꼭 개입해야 하는 관문, GATE는 딱 한 곳이에요. 기획안을 승인하는 자리죠. 그 앞뒤는 자동으로 흐르고, 문제가 생길 때만 다시 물어봐요.

진짜 문제는 파일 크기가 아니었어요

여기까지 오면서 제일 크게 바뀐 생각이 하나 있어요. 460줄이 터진 게 파일이 길어서가 아니었다는 거예요. 진짜 변수는 '그 순간 컨텍스트에 실제로 올라와 있는 토큰'이었어요.

스킬 본문은 호출될 때만 컨텍스트에 들어와요. 평소엔 한 줄 설명만 떠 있다가, 그 스킬을 실제로 쓸 때 전체가 로드되죠. 그래서 SHARED.md가 1600줄이 넘어도 한 번에 다 올라오지 않아요. 필요한 섹션만 그때그때 주입되니까요.

서브에이전트도 같은 원리예요. 자료 수집처럼 원문이 수만 토큰씩 쏟아지는 일은 서브에이전트한테 맡겨요. 서브에이전트는 자기만의 컨텍스트 윈도우에서 돌고, 메인 대화엔 요약만 돌려주거든요.

이번 글의 자료 수집도 그렇게 처리됐어요. 서브에이전트가 공식 문서 세 곳을 다 읽었지만, 제 메인 컨텍스트엔 짧은 요약만 들어왔어요.

그래서 컨텍스트 관리는 파일을 얼마나 짧게 쓰느냐가 아니라, 어느 시점에 무엇을 올릴지를 설계하는 문제에 가까웠어요.

검증도 한 단계로는 안 되더라고요

쪼개진 건 글쓰기만이 아니에요. 검증도 셋으로 갈렸어요. 처음엔 '맞춤법 검사기 하나면 되겠지' 했는데, 잡아야 할 것들의 결이 다 달랐거든요.

첫 단계는 정합성 검사예요. em-dash가 섞였는지, 콜론으로 제목을 단 건 아닌지, 본문에 건 내부 링크가 실제로 존재하는지 같은, 답이 딱 떨어지는 것만 봐요. 기계적으로 확정되니까 대부분 그 자리에서 자동으로 고쳐요.

두 번째는 표현 검토예요. 여기서부터는 사람 판단이 필요해요. '빠르고, 안전하고, 편합니다' 같은 3단 나열이 반복되는지, 과장된 형용사로 분량을 채우는지, 문장이 죄다 비슷한 길이라 단조로운지. 정답이 하나가 아니라서 고치기 전에 저한테 한 번 물어봐요.

세 번째는 논리 검토고요. 도입에서 던진 질문에 마무리가 답하는지, 섹션끼리 자연스럽게 이어지는지, 근거 없이 단정한 문장은 없는지를 글 전체를 통독하면서 봐요. 표면 규칙으로는 절대 못 잡는 자리죠.

재밌는 건 이 검증이 고정돼 있지 않다는 거예요. 지금도 글을 쓰다 어색한 표현이나 새로운 AI 티가 보일 때마다 그걸 SHARED.md에 규칙으로 박아둬요. 한 번 걸린 패턴이 다음 글부터 자동으로 걸러지게요. 무엇을 왜 바꿨는지는 CHANGELOG에 남겨두고요. 덕분에 나중에 '이 규칙이 왜 생겼더라' 싶을 때 그 자리에서 되짚을 수 있어요. 그래서 100편을 쓰는 동안 규칙 파일도 그 기록과 함께 같이 자랐어요. 지금 이 글도 그 세 단계를 차례로 통과하는 중이고요. 앞으로도 이 과정을 계속 다듬으면서, 더 나은 글로 찾아올게요.