최근에 저는 제가 매일 사용하는 AI 코딩 도구인 OpenCode의 로컬 세션 로그가 담긴 SQLite 파일을 열어보았습니다. 192개의 세션, 8,471개의 메시지, 8,900만 개의 입력 토큰(input tokens). 총비용은 518달러였습니다.

하지만 토큰당 비용은 잘못된 지표입니다. 저는 다음과 같은 점이 궁금했습니다: 내가 말한 것 중 얼마나 많은 부분이 낭비되었는가?

그래서 몇 가지 쿼리(query)를 작성했습니다. 저는 "不对(아니야)", "不行(안 돼)", "不是(그게 아니야)", "不不(아니, 아니)"라고 말한 모든 메시지를 집계했습니다. 이는 "no, wrong, not that, stop"에 해당하는 중국어 표현들입니다. 또한 동일한 대화를 포크(fork)하여 처음부터 다시 시작한 세션들을 집계했습니다. 10자 미만인 메시지가 얼마나 되는지도 살펴보았습니다. 저는 6개의 서브 에이전트(sub-agents)를 활용하여 가장 긴 6개의 세션을 독립적으로 분석하게 했고, 제가 AI를 교정하거나, 말을 반복하거나, 혹은 AI가 추측해야 할 정도로 너무 모호한 지시를 보낸 모든 사례를 추출했습니다.

저를 멈춰 세운 수치는 다음과 같습니다: 제 세션의 60%가 이전 세션에서 포크되었습니다. 저는 대화를 마무리하는 것보다 더 자주 대화를 새로 시작하고 있었습니다. 최악의 세션에서는 사용자 메시지 두 개가 전달될 때마다 새로운 세션을 시작했습니다.

이 글의 나머지 내용은 제가 발견한 것들입니다. 여섯 가지 패턴, 여섯 가지 해결책. 모두 측정 가능합니다.

데이터 스냅샷

지표 (Metric)	값 (Value)
총 세션 수 (Total sessions)	192
...

네 개의 세션이 세 자릿수의 메시지 수를 기록했습니다. 가장 길었던 세션(새 서버로의 배포 마이그레이션)은 164개의 메시지로 진행되었습니다. 그 세션 하나에서만 저는 "내 승인을 먼저 받아라"라고 네 번 말했습니다. "수동 명령이 아니라 GitHub Actions를 사용해라"라고는 다섯 번 말했습니다. 방 안에는 아무도 없었습니다. 저는 기계에게 말을 반복하고 있었습니다.

하지만 그 60%의 포크(fork) 비율은 양방향으로 작용하며, 저는 그 이면의 모습에 대해서도 솔직해져야 합니다. 제 안의 인간적인 면은 게으릅니다. 저는 새로운 세션(session)을 시작하는 것을 싫어합니다. 새로운 세션이 시작된다는 것은 프로젝트를 다시 설명하고, 규칙을 다시 설정하고, 멘탈 모델(mental model)을 다시 로드해야 함을 의미합니다. 그래서 저는 그렇게 하지 않습니다. 저는 관련 없는 작업들을 하나의 세션에 쑤셔 넣어 결국 그것을 잡동사니 서랍으로 만들어 버립니다. 배포 설정(Deployment config), CSS 리팩토링(refactoring), 데이터베이스 스키마(database schema) 변경, 그리고 React 컴포넌트가 모두 하나의 스레드(thread) 안에 들어갑니다. 메시지 80번째에 도달하면, AI는 우리가 무엇을 작업하고 있는지 더 이상 알지 못하며, 저 또한 마찬가지입니다. 컨텍스트 윈도우(context window)가 기술적으로는 200K 토큰을 수용할 수 있을지 모르지만, 주의력(attention)은 버퍼(buffer)가 아니라 스포트라이트(spotlight)와 같습니다. 그리고 저의 스포트라이트는 한 번에 여섯 개의 벽을 동시에 비추고 있습니다.

60%의 포크 비율은 절제된 관행이 아닙니다. 그것은 증상입니다. 저는 좌절할 때는 포크를 하고, 포크를 해야 할 때는 하지 않습니다. 이 두 가지 모두 컨텍스트 규율(context discipline)의 실패입니다.

법칙 1: 아는 것과 쓰는 것 사이의 간격이 전체 비용이다.

모두가 AI가 잊어버린다는 사실을 알고 있습니다. 흥미로운 질문은 'AI가 잊어버리는가'가 아니라, '그것을 수정하기 전까지 얼마나 오래 기다리는가'입니다.

여섯 번의 세션 동안, 저는 설정 파일(config file)에 단 한 줄을 쓰기 전까지 동일한 규칙 위반에 대해 AI를 27번이나 수정해 주었습니다. 몇 달에 걸쳐 27번이 아닙니다. 이미 패턴을 알고 있고, 이미 머릿속에 해결책이 있음에도 불구하고, 단지 멈춰서 그것을 적어두지 않았던 27번의 순간들입니다.

규칙	채팅 내 수정 횟수	첫 수정과 AGENTS.md 작성 사이의 메시지 수
"행동하기 전에 내 승인을 받아라"	4회	43
...

서버 마이그레이션(migration) 세션이 가장 깔끔한 사례입니다. 저는 첫 번째 메시지에서 AI에게 "행동하기 전에 내 승인을 받아라"라고 말했습니다. 메시지 48번째에 이르러 AI는 이를 잊었습니다. 저는 다시 말했습니다. 메시지 62번째에 AI는 확인 없이 코드를 푸시(push)했고, 저는 욕설과 함께 세 번째로 말했습니다. 10분 뒤인 메시지 63번째에 똑같은 일이 또 발생했습니다. 저는 마침내 메시지 80번째쯤 되어 해당 규칙을 AGENTS.md에 작성했습니다.

낭비된 것은 4번의 수정이 아니었습니다. 낭비된 것은 "이것이 규칙이 되어야 한다는 것을 안다"라고 말한 시점부터 "이것은 이제 규칙이다"라고 말한 시점 사이의 79개 메시지였습니다.

AI 코딩 도구를 사용하는 사람이라면 누구나 규칙을 작성하는 것이 문제를 해결한다는 사실을 알고 있습니다. 제가 숫자를 세어보기 전까지 몰랐던 사실은 다음과 같습니다: 저는 인지한 시점과 작성한 시점 사이에 평균 36개의 메시지를 보냅니다. 저에게는 지식의 문제가 있는 것이 아닙니다. 실행 지연 (execution latency) 문제가 있는 것입니다.

해결책: 단 하나의 수정 사항이라도 발생할 때마다 스스로에게 물으세요: '이 규칙이 향후 세션에도 적용되는가?' 만약 그렇다면, 지금 바로 작성하세요. 이 작업이 끝난 후가 아닙니다. 이번 세션이 끝난 후도 아닙니다. 바로 지금입니다. 작성하는 데 드는 비용은 10초입니다. 작성하지 않음으로써 발생하는 비용은 남은 세션 전체입니다.

법칙 2: 영향 범위 (blast radius)를 평가하라. 매번.

여섯 번의 세션, 네 번의 분노. 모든 상황은 동일한 시나리오로 흘러갔습니다: 제가 수정이나 삭제를 포함한 지시를 내립니다. 그러면 AI는 무엇을 바꾸는지 말도 없이 파일을 변경하기 시작합니다. 예상치 못한 무언가가 망가집니다. 저는 피해를 발견하고 화를 냅니다.

구체적인 사례들: 웹사이트 푸터 (footer)를 재작성하다가 그 안의 소셜 링크를 삭제함. 오래된 기사를 필터링해달라고 요청했을 뿐인데 RSS 피드 전체를 삭제함. 운영 서버 (production server)에서 명령어를 수동으로 실행함. 파일이 존재하지 않는데 존재한다고 주장함.

제 AGENTS.md 파일에는 이미 push와 deploy를 위해서는 사용자의 명시적인 확인이 필요하다고 명시되어 있습니다. 서버 이전 참사 이후에 작성한 내용입니다. 하지만 이 규칙은 너무 좁습니다. 오직 git에 대해서만 다루고 있습니다. 재작성 (rewrites), 대량 교체 (bulk replacements), 폴더 구조 재편 (folder restructures), 또는 운영 명령 (production commands) 등은 다루지 않습니다. 이 모든 것들은 동일한 비대칭성을 공유합니다: 망가뜨리는 데는 3초가 걸리지만, 복구하는 데는 30분이 걸립니다.

제가 놓친 점은 이것입니다: 이것은 특별한 AI 규칙이 아닙니다. 이것은 단 하나의 파일보다 큰 영향 범위 (blast radius)를 가진 운영 환경의 변경을 수행하기 전에 적용하는 것과 동일한 원칙입니다.

우리는 팀원이 diff 없이 운영 환경에 push 하는 것을 허용하지 않습니다. 우리는 어떤 테이블을 건드리는지 검토하지 않고 데이터베이스 마이그레이션 (database migration)을 승인하지 않습니다. 우리는 plan을 먼저 읽지 않고 terraform apply를 실행하지 않습니다. AI도 다를 바 없습니다. 다만 더 빠르고 판단력이 부족할 뿐입니다. 분당 10,000단어를 타이핑할 수 있는 인턴과 같습니다. 운영 환경을 안전하게 유지하는 엔지니어링 규율 (engineering discipline)은 AI 세션이 걷잡을 수 없이 악화되는 것을 막아주는 규율과 동일합니다.

숫자를 세기 시작하기 전까지, 저는 "AI에게 확인을 요청하는 것"이 신뢰에 관한 문제라고 생각했습니다. 그렇지 않습니다. 그것은 폭발 반경 (blast radius)에 관한 문제입니다. AI가 제 웹사이트 푸터 (footer)의 변경을 제안했습니다. 파일 하나였습니다. 최악의 상황이 무엇일까요? 푸터는 모든 페이지에 나타납니다. 즉, 사이트의 100%입니다. 파일 하나가 전체 폭발 반경을 갖게 된 것입니다. AI는 이를 이해하지 못합니다. 당신은 이해합니다.

해결책: 하나 이상의 파일에 영향을 미치거나, 여러 영역에 걸친 발자국 (cross-cutting footprint)을 남기는 파일을 건드리는 모든 작업 이전에, AI는 자신이 건드릴 모든 파일과 수행할 모든 변경 사항을 목록으로 작성해야 합니다. 그런 다음 확인을 기다려야 합니다. 이것은 동료와의 협상이 아닙니다. 이는 사전 비행 점검표 (pre-flight checklist)입니다. terraform plan 출력을 읽게 만드는 것과 동일한 본능이 AI의 변경 목록을 읽게 만들어야 합니다. 동일한 규율 (discipline)이며, 동일한 근육입니다.

법칙 3: 한 문장씩이 아니라, 전체 명세 (spec)를 보내세요.

제 최악의 세션들은 모두 공통된 형태를 띱니다. 대략적인 아이디어로 시작해서, 17개의 메시지를 거치며 이를 다듬어 나갑니다. AI는 각 미세 조정 (micro-adjustment)을 따르지만, 각 왕복 (round trip) 과정에서 발생하는 오버헤드 (overhead)는 빠르게 누적됩니다.

익명 처리된 실제 사례는 다음과 같습니다:

"검색 기능이 필요해요."
"이름으로 필터링해야 합니다."
"이메일도 포함해서요."
...

일곱 개의 메시지입니다. 다음은 동일한 명세를 하나의 메시지로 작성한 것입니다:

검색 기능: 타입어드롭다운 (typeahead dropdown). 이름과 이메일로 필터링, 부분 일치 (partial match).
입력 디바운스 (Debounce)를 300ms로 설정. 검색창 아래에 결과 표시.

두 개의 메시지면 충분했을 것입니다. 저는 타이핑하기 전에 제 머릿속에서 명세를 완성하지 않았기 때문에, 명세를 하나하나 잡아주는 데 다섯 개의 메시지를 추가로 낭비했습니다.

이런 일은 모든 긴 세션에서 발생했습니다. 유료 결제 (paywall) 논의는 18개의 메시지가 소요되었습니다 (취소 → 아니요, 제한 → 잠시만요, AI도 유료입니다 → 보류). 서버 마이그레이션 (migration) 계획은 세 번이나 방향이 바뀌었습니다 (전체 마이그레이션 → 부분 마이그레이션 → 대신 새로운 VM 열기). 이 결정들 중 나쁜 것은 없었습니다. 하지만 비행 중 발생하는 각 방향 전환은 AI가 이미 결정된 컨텍스트 (context)를 다시 계산하도록 강요했고, 이는 AI가 이전에 논의된 내용을 잊어버린다는 것을 의미했습니다. 즉, 제가 그것들을 다시 설명해야 했다는 뜻입니다.

해결책 (The fix): 기능 요청 (feature request)을 보내기 전에, 텍스트 에디터에 전체 사양 (spec)을 작성하세요. 필드 (Fields), 제약 조건 (Constraints), 예외 케이스 (Edge cases), 상호작용 (Interactions) 등을 포함해야 합니다. 그런 다음 한 번에 보내세요. 스스로 타이핑하는 데 쓰는 30초가 AI와 다섯 차례 대화를 주고받는 것보다 훨씬 가치 있습니다.

법칙 4: 10자 미만의 지시어는 수수께끼다.

규칙 확인 도구 (rules-checking tool)를 구축하던 저의 가장 긴 기술 세션에서, 메시지의 72%가 50자 미만이었습니다. 19%는 5자 미만이었습니다.

제가 실제로 보낸 내용은 다음과 같습니다:

내가 입력한 것
change
AI가 추측해야 했던 것
무엇을 변경할까요? 코드? 계획? 명명 규칙 (Naming)?
...

두 단어로 된 지시어 하나당 13회의 명확화 단계 (clarification rounds)가 소요되었습니다. AI는 옵션을 제안했고, 저는 그중 하나를 선택했습니다. 사례당 총 낭비된 메시지는 24개였습니다. 74개의 메시지로 구성된 세션에서, 저는 이 과정에 약 15회의 대화 단계가 소요되었다고 추정합니다.

흥미로운 점은 제가 "change"라고 입력했을 때 제가 무엇을 의미하는지 정확히 알고 있었다는 것입니다. 저에게는 문맥 (context)이 명확했습니다. 문제는 문맥이 채팅창이 아닌 제 머릿속에 존재한다는 점입니다. AI는 오직 텍스트에 있는 내용에 따라서만 행동할 수 있습니다.

해결책 (The fix): 전송하기 전에 스스로 물어보세요. '만약 사전 문맥이 전혀 없는 누군가가 이 지시어를 읽는다면, 이를 실행할 수 있을까?' 만약 대답이 '아니오'라면, 문장을 하나 추가하세요. "change"는 "폼 제출 핸들러 (form submission handler)에 입력값 정제 (input sanitization) 기능을 추가해줘." 가 됩니다. 같은 아이디어지만, 단어 7개가 더 추가되었고, 추측을 위한 대화 단계는 0이 됩니다.

법칙 5: 파일 A의 버그는 파일 B부터 Z까지의 버그다.

여러 서비스 (services)를 배포하던 세션에서 저는 이 점을 배웠습니다. 각 서비스는 고유한 CI 설정 파일 (config file)을 가지고 있었습니다. 서비스 A의 배포가 네트워크 설정 누락으로 실패했습니다. 저는 에러 로그 (error log)를 붙여넣었습니다. AI는 서비스 A를 수정했습니다.

서비스 B의 배포가 실패했습니다. 동일한 에러였습니다. 파일은 달랐습니다. 저는 로그를 붙여넣었습니다. AI는 서비스 B를 수정했습니다.

서비스 C의 배포가 실패했습니다. 동일한 에러였습니다. 저는 인내심을 잃었습니다. "내 말을 듣지 않았군요."라고 제가 말했습니다. "이걸 고치라고 말했잖아요."

AI는 모든 설정 파일을 고치라는 말을 들은 적이 없었습니다. AI는 제가 붙여넣은 파일 하나를 두 번 고치라는 말을 들었을 뿐입니다. 저는 제가 요청한 대로 정확히 수행한 AI에게 화를 내고 있었습니다.

다른 프로젝트에서도 비슷한 일이 발생했습니다. 프론트엔드 (frontend)와 백엔드 (backend) 모두에 검증 버그 (validation bug)가 존재했습니다. 저는 백엔드를 수정하고 배포했지만, 오류는 다시 나타났습니다. 프론트엔드에도 수정되지 않은 동일한 로직이 있었기 때문입니다.

해결책: 한 파일에서 버그를 발견한 후, 다음 지시사항은 다음과 같아야 합니다: "이 카테고리의 모든 파일을 확인하여 동일한 문제가 있는지 점검하세요." "이것을 수정하세요"가 아닙니다. 단 한 문장으로 동일한 오류가 조금씩 계속 발생하는 것을 방지할 수 있습니다.

법칙 6: "이것 (This)"과 "모두 (all)"는 같은 것이 아닙니다. 명확히 말하세요.

저는 AI에게 한 모듈 (module)에 입력 검증 (input validation)을 추가하라고 요청했습니다. "이메일 필드를 검증하세요"라고 말했습니다. AI는 이메일을 검증했습니다 — 오직 이메일만 말이죠. 제 의도는 양식 (form)의 모든 필드를 검증하는 것이었습니다. 하지만 저는 "이 필드"라고 말했습니다. AI는 제 말을 문자 그대로 받아들였습니다.

오류 처리 (error handling)에서도 같은 일이 일어났습니다. "이 함수에 try-catch를 추가하세요"라고 했더니 함수 하나에만 적용되었습니다. 저는 모듈 전체에 적용되기를 원했습니다. 결과적으로 세 번의 대화를 거쳐서야 수렴되었습니다.

두 경우 모두 저는 "모듈의 모든 필드", "외부 API를 호출하는 모든 함수"를 의미하면서도 "이 필드", "이 함수"라고 "이것 (this)"이라고 말했습니다. AI는 제가 명시한 단 하나에만 제약 사항을 적용했습니다. 저는 문맥 (context)이 제 의도를 명확하게 해줄 것이라고 생각했습니다. 그렇지 않았습니다.

또 다른 사례: 저는 서비스 전체의 패턴으로 삼을 의도로 AI에게 하나의 API 엔드포인트 (endpoint)에 속도 제한 (rate limiting)을 추가하라고 말했습니다. AI는 하나의 엔드포인트에만 추가했습니다. 저는 "아니요, 전부 다요"라고 말했습니다. 두 번의 대화가 더 필요했습니다. 만약 처음부터 "모든 엔드포인트에 속도 제한을 추가하세요"라고 시작했다면 한 번에 끝났을 것입니다.

해결책: 제약 사항이 하나 이상의 출력물에 적용된다면, "모두 (all)"로 시작하세요. 하나에만 적용된다면, "이것 (this one)"으로 시작하세요. 명시적인 범위 (scope) 설정은 토큰 (token) 비용이 들지 않으면서 세 번의 수정 과정을 아껴줍니다.

복리 자산 (The Compounding Asset)

이 법칙들은 프롬프트 엔지니어링 (prompt engineering)에 관한 것이 아닙니다. 이것은 여러분 자신의 의사소통 패턴을 체계화하는 것에 관한 것입니다. 192번의 세션에서 얻은 진짜 통찰은 제가 더 나은 프롬프트가 필요했다는 것이 아닙니다. 제가 같은 말을 반복하지 않기 위한 프로세스 (process)가 필요했다는 것입니다.

AGENTS.md는 한 번 쓰고 마는 파일이 아닙니다. 그것은 매번 수정을 거친 후에 단련해야 하는 근육과 같습니다. AI와 백 번의 세션 동안 대화하면서 아무것도 기록하지 않는 엔지니어는 열 번째 세션과 동일한 정보만을 가지고 있습니다. 반면, 매번 수정을 거칠 때마다 규칙을 작성하는 엔지니어는 복리로 쌓이는 자산을 갖게 됩니다. 모든 새로운 세션은 이전의 모든 수정 사항에서 얻은 축적된 지혜와 함께 시작됩니다. AI는 당신의 의도를 더 빠르게 파악합니다. 당신은 같은 말을 덜 반복하게 됩니다. 세션은 짧아지고, 출력물의 품질은 높아지며, 욕설(four-letter words)은 제로에 수렴합니다.

그것이 바로 우리가 추구할 가치가 있는 점근선 (asymptote)입니다.