이 블로그는 글을 쓰는 곳이자 내가 정한 것을 다시 찾아 읽는 곳이다. 그런데 요즘은 나만 읽지 않는다. Claude Code, Copilot, Codex가 이 저장소를 뒤져서 “예전에 뭐라고 정했지?”에 답한다.
그러면서 문제가 하나 생겼다. 에이전트가 원칙 하나를 확인하려고 글 전체를 읽는다.
확인하려던 것 : 원칙 2 하나 389 토큰
실제로 읽은 것 : 그 글 전체 13,136 토큰
97%가 낭비다. 이걸 줄이려고 시작했는데, 처음 세운 방향이 틀렸다는 걸 세 번 발견했다. 이 글은 그 세 번의 방향 전환에 대한 기록이다.
처음 물은 것은 “글을 줄이자”였고, 그게 틀린 질문이었다
첫 아이디어는 이랬다 — 마크다운으로 된 글을 YAML 데이터로 바꾸면 토큰이 줄지 않을까.
정해야 했던 건 이거였다 — 에이전트가 쓰는 토큰을 어떻게 줄이는가.
안 A — 글을 데이터 형식으로 바꾼다.
# 글 대신 이런 게 저장소에 남는다
standard: repository-design
principles:
- id: 2
rule: "메서드 이름은 도메인 언어로 짓는다"
얻는 것은 파일 크기가 준다는 것이다. 마크다운의 산문이 사라지니 글자 수 자체가 줄어든다.
버린 이유는 사람이 읽을 블로그가 사라진다는 것이다. 이 저장소의 본질은 “왜 그렇게 정했는지”를 6개월 뒤의 내가 복원하는 것이다. 위 YAML을 읽고 복원되는 건 결론뿐이고, 버린 안도 그걸 버린 이유도 남지 않는다.
안 B — 글을 잘게 쪼갠다. 원칙 하나가 파일 하나가 된다.
얻는 것은 조회가 정확해진다는 것이다. 원칙 2를 확인하려면 원칙 2 파일만 읽으면 된다.
버린 이유는 같다. 이 블로그는 처음부터 끝까지 한 번에 읽히는 글을 쓰기로 정한 곳이다. 각 섹션이 앞 섹션의 결론 위에 서 있어야 한다. 쪼개는 순간 그 흐름이 끊긴다.
골랐다 — 안 C. 글은 그대로 두고, 읽는 쪽에 층을 하나 더 만든다. 안 A와 안 B는 둘 다 “글을 바꾼다”였고, 그러면 사람이 잃는다. 안 C는 글을 한 글자도 안 건드린다.
대신 층이 하나 늘어난다. 관리할 파일이 늘고, 글을 고칠 때마다 다시 뽑아야 한다. 이 대가는 뒤에서 생성기로 갚는다.
압축이 아니라 조준이다
방향을 바꾸면서 알게 된 게 있다. 압축은 조회 비용을 줄이지 못한다.
파일을 절반으로 줄여도 에이전트가 “그 안에서 필요한 부분”을 찾는 방식이 같으면, 결국 읽는 양은 필요한 만큼이다. 반대로 파일이 아무리 커도 정확히 필요한 줄만 집어올 수 있으면 비용은 그 줄만큼이다.
그래서 문제는 이렇게 다시 세워졌다.
파일을 작게 만드는 게 아니라, 어디를 읽어야 하는지 싸게 알아내는 것이다.
이 구분이 이후 모든 판단의 기준이 됐다. 뒤에서 나오는 결정들은 전부 “압축이냐 조준이냐”로 갈렸다.
트리로 내려가지 않고 평평한 한 줄에 grep한다
읽는 층을 어떤 모양으로 만들지가 다음 질문이었다.
정해야 했던 건 이거였다 — 에이전트가 목표를 찾아가는 경로를 어떻게 만드는가.
안 A — 트리 구조. 카테고리 → 글 → 섹션으로 단계마다 좁혀 내려간다.
coding-standard:
repository-design:
원칙2: [166, 183]
얻는 것은 직관이다. 사람이 폴더를 뒤지듯 단계별로 좁혀간다.
버린 이유는 grep이 트리를 타지 않는다는 것이다. 트리를 내려가려면 층마다 파일을 읽고, 다음에 어디로 갈지 판단하고, 또 읽어야 한다. 왕복이 층수만큼 늘고 각 층의 내용을 매번 읽어야 한다. 반면 평평한 파일에 grep 한 번이면 모든 층을 건너뛴다.
골랐다 — 안 B. 한 줄 = 한 레코드.
sections:
- ["_posts/coding-standard/2026-07-30-repository-design-standard.md",166,183,"원칙 2. 메서드 이름은 기술이 아니라 도메인 언어로 짓는다"]
안 A가 못 지켜주는 것을 안 B는 지켜준다 — grep 비용은 코퍼스가 커져도 늘지 않는다. 글이 100편이 되든 1,000편이 되든 나오는 건 걸린 줄뿐이다. 트리는 커질수록 층이 깊어진다.
대신 파일 자체는 커진다. 지금 1,076줄이다. 그래서 “통째로 읽지 않는다, grep 전용이다”를 규칙으로 못 박아야 했다.
목차는 “어느 글인가”까지만 답하고 색인이 “어디인가”를 답한다
한 파일로 할지 나눌지도 정해야 했다.
안 A — 한 파일에 다 넣는다. 경로·제목·요지·헤딩·줄 범위를 한 레코드에 담는다.
얻는 것은 파일이 하나라 단순하다는 것이다.
버린 이유는 두 용도가 서로를 망친다는 것이다. 찾을 말을 모를 때는 목록을 훑어야 하는데, 헤딩까지 들어 있으면 훑는 양이 몇 배가 된다. 반대로 grep할 때는 제목과 요지가 매 줄에 딸려 나와 결과가 부푼다. 둘 다 애매해진다.
골랐다 — 안 B. 두 파일로 분업한다.
_ai/index.yml 얇은 목차. [경로, 묶음, 제목, tagline]
어느 글인지 고르는 곳. 찾을 말을 모를 때만 통째로 읽는다
_ai/map.yml 섹션 색인. [경로, 시작줄, 끝줄, 헤딩]
그 글의 어디인지 찍는 곳. grep 전용이다
아는가"} G -->|안다| M["_ai/map.yml
grep"] G -->|모른다| I["_ai/index.yml
훑는다"] I --> M M --> R["그 줄의 범위만
Read"] style Q fill:#2d3748,stroke:#4299e1,stroke-width:2px,color:#e2e8f0 style G fill:#1a202c,stroke:#a0aec0,stroke-width:2px,color:#e2e8f0 style I fill:#2d3748,stroke:#68d391,stroke-width:2px,color:#e2e8f0 style M fill:#2d3748,stroke:#f6ad55,stroke-width:2px,color:#e2e8f0 style R fill:#2d3748,stroke:#4299e1,stroke-width:2px,color:#e2e8f0
index.yml은 “어느 글인가”까지만 답한다. 여기에 헤딩을 넣으면 색인의 열화판이 되면서 분업이 무너진다.
요지를 지어내느니 빈칸으로 둔다
목차의 요지는 front matter의 tagline에서 뽑기로 했다. 그런데 페이지 79장 중 tagline이 있는 건 0장이었다.
안 A — 본문 첫 문장에서 자동으로 뽑는다. 스크립트를 짜서 돌렸다.
글 제목 : "Tomcat 요청 처리 파이프라인 심층 분석"
뽑힌 요지 : "1. URL 패턴 필터 추가 먼저"
버린 이유는 지어낸 요지가 없는 요지보다 나쁘다는 것이다. 요지가 비어 있으면 훑는 쪽이 “열어봐야 알겠군” 하고 연다. 그런데 엉뚱한 요지가 적혀 있으면 그걸 믿고 글을 건너뛴다. 틀린 색인은 색인이 없는 것보다 나쁘다.
골랐다 — 안 B. tagline만 쓰고, 없으면 빈칸으로 둔다. 대신 생성기가 빠진 목록을 알려준다.
tagline 없음 79건 — 목차에서 요지가 빈칸으로 남는다. 채워야 한다.
_pages/deep-dive/java-web/1.md
...
대가는 사람이 손으로 채워야 한다는 것이다. 그래서 49장을 직접 채웠다. 자동화가 안 되는 게 아니라, 자동화하면 틀린다.
헤딩이 곧 과녁이다
색인을 만들고 나서 알게 된 것이 있다. map.yml에 grep이 걸리는 곳은 헤딩뿐이다. 그러면 헤딩이 검색어가 되어야 한다.
그런데 세어보니 전체 헤딩 1,091개 중 588개(54%)가 다른 글과 겹쳤다.
44 ## 설계 의도
44 ## 핵심 코드
44 ## 이번 단계의 역할
grep "설계 의도"가 44줄을 돌려준다. 색인으로 쓸 수 없는 상태다.
검문은 한 줄로 정리됐다 — 그 헤딩의 한 단어로 grep했을 때 이 글 하나로 좁혀지는가.
// 좁혀지지 않는다
## 설계 의도
// 좁혀진다
## 원칙 2. 메서드 이름은 기술이 아니라 도메인 언어로 짓는다
시리즈의 라벨을 버리지 않고 뒤에 문장을 붙였다
문제는 deep-dive 시리즈 44편이었다. 여섯 개 라벨이 44편에 그대로 반복된다.
안 A — 라벨을 버리고 전부 문장으로 갈아엎는다.
버린 이유는 시리즈 구조가 깨진다는 것이다. 44편이 같은 뼈대(역할 → 요약 → 다이어그램 → 코드 → 해설 → 연결)를 공유하는 게 이 시리즈의 값어치다. 한 편을 읽고 다음 편에서 같은 자리를 찾을 수 있어야 한다.
골랐다 — 안 B. 라벨을 남기고 뒤에 내용을 붙인다.
## 핵심 코드
→ ## 핵심 코드 — applyPreHandle()이 interceptorIndex를 남기며 정방향으로 순회한다
안 A가 못 지켜주는 것을 안 B는 지켜준다 — 구조도 살고 검색도 산다. grep "interceptorIndex"는 이제 그 글 하나로 좁혀지고, 사람은 여전히 “핵심 코드” 자리를 찾을 수 있다.
대가는 손이 많이 간다는 것이다. 259개 헤딩에 붙일 문장을 그 섹션 본문에서 하나씩 확인해서 뽑아야 했다. 지어내면 안 되기 때문이다(위의 요지 사건과 같은 이유다).
Poller 하나가 색인의 역효과를 드러냈다
헤딩 작업을 끝내고 확인차 몇 개를 재봤는데, 하나가 이상했다.
검색어 grep줄 섹션토큰 글전체 이득
애그리거트 5 4,895 27,809 5.7배
DTO 6 1,509 21,155 14.0배
Poller 5 2,502 3,169 1.3배 ← 이득이 없다
Poller가 걸리는 헤딩이 1개에서 5개로 늘었다. 내가 방금 붙인 문장들 때문이다. 그 글이 통째로 Connector 얘기라, 내용을 헤딩에 담을수록 같은 단어가 여러 헤딩에 들어갔다.
결과적으로 3,169 토큰짜리 글에서 2,502 토큰(79%)을 조각내서 가져온다. 그냥 통째로 읽는 게 낫다. 왕복만 하나 늘었다.
여기서 처음으로 색인이 손해가 되는 경우가 있다는 걸 알았다.
길이로 판별하려던 안을 측정이 무너뜨렸다
Poller를 보고 곧바로 결론을 냈다 — 짧은 글은 색인에서 빼자.
안 A — 8,000자 미만 글을 map.yml에서 뺀다. 근거는 저장소 규칙에 이미 있었다. “짧은 글은 그냥 통째로 읽는다. 8,000자 아래에서는 오히려 손해다.”
그런데 그 8,000자가 어디서 나온 숫자인지 확인한 적이 없었다. 재봤다.
8,000자 미만 92편 중
실제로 부분 읽기가 이득인 글 56편
안 A로 갔으면 15줄짜리 문제를 고치려고 531줄을 버릴 뻔했다. Poller 하나를 보고 “짧은 글은 색인이 손해”라고 일반화한 게 원인이었다. deep-dive는 평균 15%만 끌어오고 편당 1,528 토큰 이득이었다. Poller는 운 나쁜 검색어였지 구조적 문제가 아니었다.
저장소에 적혀 있던 규칙 자체가 틀렸다. 색인 파일이 아니라 지침이 문제였다.
판별자는 길이가 아니라 섹션 수다
그러면 무엇이 판별하는가. 섹션 수로 갈라 재봤다.
섹션 수 편수 평균토큰 평균 끌어옴 순이득/편 map 줄수
1 15 1,389 90% -324 15
2~3 3 4,380 51% +1,903 8
4~6 8 2,209 26% +1,289 42
7~9 61 2,280 15% +1,528 531
10~14 34 7,549 11% +6,320 381
15~ 6 7,856 7% +6,878 114
손해인 건 1섹션 글뿐이다. 당연하다 — 섹션이 하나면 그 섹션이 곧 글 전체다. 색인을 거쳐서 결국 전부 읽는다.
그리고 1섹션 글은 길이와 무관하다. graph.md는 15,001자인데 ## 헤딩이 하나도 없어서 1섹션이고, sitemap.md는 995자인데 마찬가지다.
그래서 규칙을 이렇게 바꿨다.
이전 "8,000자 아래면 통째로 읽는다" ← 측정과 어긋난다
지금 "섹션이 하나뿐인 글은 통째로 읽는다" ← map.yml이 아예 싣지 않는다
map.yml 레코드가 1,091 → 1,076이 됐다. 정확히 1섹션 글 15편이 빠졌다.
한 섹션에 얼마나 담아야 하는가
여기서 질문이 하나 더 나왔다. 조회 단위가 섹션이라면, 섹션을 얼마나 크게 쓰는 게 맞는가.
재봤더니 예상 밖의 결과가 나왔다.
섹션 크기 편수 걸린 섹션 수 끌어온 토큰
0~200 37 1.4 172
200~350 19 1.2 331
350~500 20 1.2 557
500~700 12 1.2 764
700~1000 13 1.2 1,027
1000~1500 8 1.2 1,359
걸린 섹션 수가 크기와 무관하게 늘 1.2개다. 잘게 쪼갠다고 검색이 여러 개를 물어오지 않는다.
그러면 조회 비용 = 섹션 크기 × 1.2다. 선형이다. 검색 효율만 보면 작을수록 무조건 좋다.
그러니 진짜 질문은 “얼마나 커야 하나”가 아니라 “얼마나 작아져도 답이 되나” 였다.
상한은 1,000 토큰이고 하한은 없다
하한이 어디인지는 두 종류를 비교해서 알았다. 둘 다 잘 돌고 있었다.
deep-dive 섹션 220 토큰 → 조회 307 토큰
코딩 스탠다드 원칙 섹션 791 토큰 → 조회 1,343 토큰 (6.8배 절감)
차이는 섹션 하나가 답해야 하는 질문의 무게다. deep-dive 섹션은 “이 단계가 무엇을 하는가” 하나만 답하면 되니 220으로 충분하다. 코딩 스탠다드 원칙은 안 A/B/C와 각각의 버린 이유, 고른 이유, 대가를 다 담아야 하니 800 아래로 못 내려간다.
그래서 규칙은 크기가 아니라 한 섹션 = 한 질문이 됐다. 크기는 그 규칙을 지킨 결과다.
상한 1,000 토큰. 넘으면 크기가 문제가 아니라 질문이 두 개 섞였다는 신호다. 넘은 것들을 열어보니 예외 없이 그랬다.
2,300 ## 원칙 4. 도메인끼리는 application에서만, 인터페이스로 만난다
→ "어디서 만나나" + "무엇으로 만나나" 두 질문이다
하한은 없다. 가장 작은 원칙 섹션은 197 토큰이고 그게 맞다.
197 ## 원칙 7. Error 계열은 잡지 않는다
Error 계열을 안 잡는 이유를 800 토큰으로 늘리면 물타기가 된다. 억지로 채우면 6개월 뒤에 핵심이 묻힌다.
색인을 손으로 고치지 않는다
여기까지 정한 것을 사람이 지키게 두면 반드시 어긋난다. 줄 번호는 문단 하나만 넣어도 밀린다.
그래서 색인은 생성물이다.
ruby tools/ai-map.rb # 다시 뽑는다
ruby tools/ai-map.rb --check # 최신인지 검사한다 (오래됐으면 exit 1)
생성기는 규칙 위반을 목록으로 알려준다.
1000 토큰 넘는 섹션 72건 — 한 섹션에 질문이 둘 이상 섞였는지 본다.
(크기 자체는 실패가 아니다. 정말 한 질문인데 긴 섹션도 있다. 목록을 보고 판단한다.)
5809 단계별 상세 분석 sql/2026-03-19-mariadb-query-execution-flow.md
5308 코드 구현 algorithm/2026-03-11-quick-sort.md
처음엔 98건이 나왔다. 그중 26건이 설계상 클 수밖에 없는 섹션이었다 — 「AI 코드 어시스턴트에 바로 적용하기」(어차피 읽지 않는 자리)와 「이 표준을 정하기까지」(시간 순 서사가 그 섹션의 정의다). 이 둘을 면제했다.
매번 울리는 경고는 아무도 읽지 않게 되고, 그러면 진짜 신호까지 같이 묻힌다.
정작 가장 큰 고정 비용은 지침 파일이었다
마지막으로 전체를 다시 쟀다. 그런데 예상과 다른 게 1등이었다.
CLAUDE.md 11,045 ← 세션마다 무조건 낸다
coding-standard 글 평균 9,409
_ai/index.yml 8,660
지침 파일 하나가 글 한 편보다 크다. 그리고 아무것도 안 물어봐도 세션 시작에 전부 들어간다.
"이 코드가 규칙에 맞나?" 물어본 세션
CLAUDE.md 11,045 ← 안 물어봐도 낸다
SKILL.md 읽기 1,750 ← 실제로 필요했던 것
──────────────────────
12,795 그중 86%가 입장료
그런데 이건 안 건드리기로 했다. 쪼개서 필요할 때만 부르게 하면 안 부르는 경우가 생기는데, 그러면 규칙 없이 글을 쓰게 되고 에러가 안 난다. 조용히 실패한다. 4~5K 아끼자고 걸기엔 잃는 게 크다. 게다가 이 파일은 프롬프트 캐시에 올라가서 두 번째 턴부터 비용은 1/10이다.
비용과 자리는 다른 문제다. 돈은 캐시가 해결하고, 남는 건 컨텍스트 창 자리뿐이다.
판단 기준 정리
| 질문 | 답 | 결론 |
|---|---|---|
| 토큰을 줄이려면 글을 줄여야 하나 | 아니다 | 압축이 아니라 조준이다. 어디를 읽을지 싸게 알아낸다 |
| 탐색 경로를 트리로 만들까 | 아니다 | grep이 트리를 안 탄다. 평평한 한 줄 = 한 레코드 |
| 목차와 색인을 한 파일로 할까 | 아니다 | 목차는 “어느 글인가”, 색인은 “어디인가”만 답한다 |
| 요지가 없으면 뽑아서 채울까 | 아니다 | 지어낸 요지는 없는 요지보다 나쁘다. 빈칸으로 두고 알린다 |
| 시리즈 라벨을 버릴까 | 아니다 | 라벨 뒤에 문장을 붙인다. 구조도 살고 검색도 산다 |
| 짧은 글을 색인에서 뺄까 | 아니다 | 판별자는 길이가 아니라 섹션 수다. 1섹션 글만 뺀다 |
| 섹션은 얼마나 커야 하나 | 크기가 목표가 아니다 | 한 섹션 = 한 질문. 상한 1,000 토큰, 하한 없음 |
| 지침 파일을 쪼개 아낄까 | 아니다 | 안 부르면 조용히 실패한다. 캐시가 비용은 해결한다 |
이 표준을 정하기까지
시작은 “토큰을 줄이자”였다. 마크다운을 YAML 데이터로 바꾸면 되지 않을까 생각했다. 그런데 그러면 사람이 읽을 블로그가 사라진다. 글을 쪼개는 안도 같은 이유로 버렸다. 이 저장소는 “왜 그렇게 정했는지”가 한 번에 읽히도록 쓰기로 이미 정해둔 곳이다.
방향이 처음 꺾인 건 “압축이 아니라 조준”을 알아차렸을 때다. 파일을 절반으로 줄여도 찾는 방식이 같으면 읽는 양은 그대로다. 반대로 파일이 커도 필요한 줄만 집으면 비용은 그 줄만큼이다. 그러면 글은 그대로 두고 읽는 쪽에 층을 만들면 된다. 여기서 _ai/가 나왔다.
트리로 가자는 생각이 있었는데 측정이 말렸다. 단계별로 좁혀가는 게 직관적이지만, grep은 트리를 타지 않는다. 층마다 읽고 판단하고 또 읽어야 한다. 평평한 파일에 grep 한 번이면 모든 층을 건너뛰고, 코퍼스가 커져도 비용이 안 는다. 대신 파일이 커지므로 “통째로 읽지 않는다”를 규칙으로 못 박았다.
요지를 자동으로 뽑으려다 되돌렸다. 스크립트가 “Tomcat 요청 처리 파이프라인 심층 분석”에서 “1. URL 패턴 필터 추가 먼저”를 뽑아냈다. 여기서 원칙 하나가 생겼다 — 지어낸 요지는 없는 요지보다 나쁘다. 없으면 열어보지만, 틀리면 믿고 건너뛴다. 그래서 49장을 손으로 채웠다.
헤딩이 색인이라는 걸 뒤늦게 알았다. grep이 걸리는 곳은 헤딩뿐인데, 1,091개 중 588개가 겹쳐 있었다. deep-dive 44편은 여섯 라벨이 그대로 반복됐다. 라벨을 버리자니 시리즈 구조가 깨져서, 라벨 뒤에 문장을 붙이는 쪽으로 갔다. 259개를 그 섹션 본문에서 확인해가며 붙였다.
그런데 그 작업이 역효과를 내는 걸 발견했다. Poller 하나가 3,169 토큰짜리 글에서 2,502 토큰을 끌어왔다. 헤딩에 내용을 담을수록 같은 단어가 여러 헤딩에 들어간 것이다. 여기서 “색인이 손해인 경우가 있다”를 처음 알았다.
그래서 짧은 글을 색인에서 빼자고 했는데, 그게 두 번째 방향 전환이었다. 근거로 삼은 “8,000자” 규칙이 어디서 나온 숫자인지 확인한 적이 없었다. 재보니 8,000자 미만 92편 중 56편은 부분 읽기가 이득이었다. 15줄 문제를 고치려고 531줄을 버릴 뻔했다. Poller 하나로 일반화한 게 원인이었다.
진짜 판별자는 섹션 수였다. 1섹션 글만 손해고, 2섹션부터는 전부 이득이다. 그리고 1섹션 글은 길이와 무관하다 — 15,001자짜리도 995자짜리도 있다. 저장소에 적혀 있던 규칙 자체를 고쳤다.
마지막에 섹션 크기를 물었더니 예상 밖의 답이 나왔다. 걸리는 섹션 수가 크기와 무관하게 늘 1.2개였다. 그러면 조회 비용이 섹션 크기에 선형이다. 검색만 보면 작을수록 좋고, 하한은 “답이 되는가”가 정한다. 그래서 크기가 아니라 한 섹션 = 한 질문을 규칙으로 삼았다. 1,000 토큰은 목표가 아니라 질문이 섞였다는 신호다.
전체를 다시 재고 나서 마지막 발견이 있었다. 가장 큰 고정 비용은 글이 아니라 CLAUDE.md(11,045 토큰)였다. 그런데 이건 안 건드리기로 했다. 쪼개면 안 부르는 경우가 생기고, 그때 조용히 실패한다. 줄일 수 있다고 다 줄이는 게 아니다.
정리
- 압축이 아니라 조준이다. 파일을 줄이는 게 아니라 어디를 읽을지 싸게 알아내는 문제다
- 글은 그대로 두고 읽는 층을 따로 만든다. 사람이 읽을 글과 AI가 도는 색인은 다른 물건이다
- 평평한 한 줄에 grep한다. 트리는 층마다 왕복이 필요하고, grep은 층을 전부 건너뛴다
- 지어낸 정보는 없는 정보보다 나쁘다. 없으면 확인하지만, 틀리면 믿고 건너뛴다
- 헤딩이 검색의 과녁이다. 라벨은 과녁이 못 된다. 시리즈면 라벨 뒤에 문장을 붙인다
- 조회 단위는 글이 아니라 섹션이다. 그래서 섹션을 어디서 끊었는지가 그대로 비용이 된다
- 한 섹션 = 한 질문. 1,000 토큰을 넘으면 크기가 아니라 질문이 섞였다는 신호다
- 색인은 생성물이다. 손으로 고치지 않는다. 틀린 색인은 색인이 없는 것보다 나쁘다
- 측정하지 않은 숫자를 근거로 쓰지 않는다. “8,000자”가 그랬고, 그것 때문에 531줄을 버릴 뻔했다
에이전트에게 주도권을 넘기지 않는 문제는 AI 에이전트에게 주도권을 뺏기지 않고 개발하는 방법론에서 따로 다뤘다. 이 글은 그 앞 단계 — 에이전트가 내 결정을 싸고 정확하게 찾아 읽게 만드는 것에 대한 기록이다.
자신만의 철학을 만들어가는 중입니다.
댓글남기기