AI 품질이 뭉개지는 진짜 원인은 프롬프트가 아니라 맥락 설계였습니다

AI에게 다 맡겼더니, 길어질수록 결과가 흐려졌습니다

한 번쯤 이런 경험 있으실 거예요. AI에게 긴 작업을 통째로 맡깁니다. 앞부분 몇 문단은 내가 시킨 톤 그대로 완벽하게 나와서 "이거 되는데?" 싶어집니다. 그런데 중반을 넘어가면 톤이 미묘하게 달라지고, 분명히 "이건 하지 마"라고 했던 걸 아무렇지 않게 하고, 처음 정해준 규칙을 하나씩 놓치기 시작해요. 앞은 완벽했는데 왜 뒤로 갈수록 무너질까요.

이때 대부분은 "내 프롬프트가 부족했구나" 하고 지시문을 더 정교하게, 더 길게 다듬습니다. 그런데 프롬프트는 길어지는데 품질은 안 좋아지고, 오히려 새로운 곳에서 무너져요. 저도 한동안 이 자리에 갇혀 있었습니다. 그리고 이 편에서 그 믿음을 정면으로 뒤집습니다. 문제는 프롬프트를 얼마나 잘 쓰느냐가 아니라, 맥락을 어떻게 나눠 담느냐라는 설계의 문제였습니다.

이 편은 그 뒤집기를 설계로 옮기는 편입니다.

지난 편에서 저는 개발자가 SNS와 뉴스레터를 공장처럼 찍어내는 시스템의 전체 구조를 보여드렸습니다. Obsidian에 지식을 쌓고, 로컬 AI가 그걸 읽어 채널별 글을 뽑고, 자동화가 발행까지 잇는다는 큰 그림이요. 그런데 거기서 저는 스택 이름만 나열하고 멈췄어요. "그래서 그 안이 실제로 어떻게 생겼는데?"는 통째로 다음 편, 그러니까 이 편으로 넘겼습니다.

이번 편은 그때 예고만 하고 넘겼던 그 벽, AI에게 긴 맥락을 넘기면 품질이 뭉개지는 문제를 정면으로 다룹니다. 그리고 벽을 넘는 방법에서 그치지 않고, 제가 실제로 돌리는 콘텐츠 공장의 내부 도면 전체를 원문 그대로 엽니다.

이 편에서 당신이 가져가는 것 (실물 파일은 잘라내지 않고 전문으로 엽니다):

이 파일들이 어디에 있는 것들인지 먼저 못박고 갈게요. 이 공장은 Claude Code 위에 올린 harness입니다. 제 Obsidian vault 안에 .claude/ 폴더가 있고, 그 안에 규칙(.claude/rules/)·역할(.claude/agents/)·명령(.claude/skills/)이 각각 마크다운 파일로 들어 있어요. AI 채팅창에 프롬프트를 매번 붙여넣는 방식이 아니라, 프로젝트 폴더 자체가 AI의 작업 환경이 되는 구조입니다. 이 편에서 "규칙 파일", "역할", "명령"이라고 부르는 것들은 전부 그 폴더 안의 실제 파일이고, 경로까지 그대로 공개합니다.

Claude Code를 안 쓰셔도 괜찮습니다. 네 원칙은 도구에 종속되지 않아요 — 각 원칙 끝에 "다른 도구라면 이 자리에 무엇이 오는가"를 한 줄씩 달아두겠습니다. Cursor를 쓰든 API로 직접 조립하든 대응되는 자리가 있습니다.

지난 편이 "이런 공장이 있다"였다면, 이 편은 "그 공장의 설계도를 통째로 가져가 당신 것을 짓는 법"입니다. 자, 그 벽의 정체부터 뜯어보죠.

문제는 프롬프트가 아니라 '한 번에 너무 많이 시킨 것'이었어요

방향을 바꾸게 된 계기는 아주 단순한 장면이었습니다.

AI가 쓴 글이 기준 분량을 넘겼는지 확인하려고, 다 쓴 뒤에 그냥 물어봤어요. "이거 몇 자야?" 돌아온 답은 "약 5,200~5,500자입니다". 기준을 넘겼다니 통과시켰죠.

그런데 나중에 코드로 직접 세어보니 실제로는 4,600자였습니다. 기준 미달인 글을, AI도 저도 "통과"로 알고 넘긴 겁니다. 틀린 것보다 무서운 건 말투였어요. "잘 모르겠습니다"가 아니라 "약 5,200~5,500자입니다"라고, 소수점 자리까지 있을 법한 확신으로 답했습니다. 그러니 저도 의심할 이유가 없었죠.

이게 핵심입니다. 긴 텍스트가 눈앞에 통째로 주어지면, AI는 글자 수처럼 세기만 하면 되는 것조차 눈대중으로 틀립니다. 그리고 틀렸다는 사실 자체를 모릅니다 — 그래서 자신 있게 답하고, 검수가 통째로 무력화돼요. 맥락이 길어질수록 주의가 분산돼서, 앞부분에 준 지시와 뒷부분의 실제 처리 사이가 벌어지는 겁니다. 우리가 "뒤로 갈수록 품질이 무너진다"고 느낀 그 현상의 정체가 바로 이것이었습니다. 프롬프트가 부족해서가 아니라, 한 번에 너무 많은 맥락을 떠안겨서 생긴 과부하였습니다.

여기에 하나 더 겹칩니다. 지시가 길어지면 어느 순간 앞부분 지침 자체가 슬그머니 사라지기도 합니다. 하나의 지침에 이것저것 계속 얹다 보면, 병합된 맥락이 일정 분량을 넘어서는 순간 앞에서 정해둔 규칙이 유실됩니다. 저는 이걸 실제로 겪었어요. 한 지침 파일에 규칙을 계속 얹다가 그게 어느 선을 넘자, AI가 파일 앞쪽에 적어둔 "이건 절대 하지 마"를 태연히 어기기 시작했습니다. 규칙을 지웠느냐면 아닙니다. 분명히 파일 안에 그대로 있었죠. 그런데 맥락이 그 분량을 넘어서면 앞쪽이 실질적으로 "안 읽힌 것"이 됩니다. 규칙이 사라진 게 아니라 긴 맥락 속에 묻힌 겁니다.

그러니 해법의 방향이 완전히 바뀝니다. 프롬프트를 더 길게 튜닝하는 건 오히려 문제를 키우는 일이에요. 맥락이 이미 과부하인데 거기에 글자를 더 얹는 셈이니까요. 진짜 해법은 반대쪽에 있습니다. 긴 맥락 하나를 짧은 맥락 여러 개로 쪼개는 것. 튜닝이 아니라 분할 설계입니다. 이 관점 하나만 바꿔도 지금까지 안 풀리던 문제의 절반이 풀립니다.