- 코딩 에이전트 설정 176개를 실측했더니, 컨텍스트 32k에서 관리 유무에 따른 성공률 차이가 35.7%p였다
- LLM은 대필 작가가 아니라 교정 편집자다. 모델이 제안한 표현은 한 단어도 쓰지 않는 것이 첫 번째 원칙
- Cloudflare는 항목당 8바이트를 6바이트로 줄이고 해시 수를 90% 감축해 전 세계 RAM 100TB를 절감했다
같은 모델을 써도 그것을 감싸는 층을 바꾸면 결과가 달라진다. 이번 주 GeekNews 상위권은 공교롭게도 전부 그 ‘바깥 설계’에 관한 이야기였다. 에이전트를 감싸는 하네스, 글을 감싸는 편집 과정, 요청을 감싸는 라우팅 계층. 세 글 모두 모델이나 알고리듬 자체가 아니라 그것을 둘러싼 구조를 숫자로 검증했다는 공통점이 있다.
설정 176개를 돌려보니 정답이 갈렸다
컨텍스트 관리는 똑똑하게 만드는 게 아니라 안 끊기게 만든다
연구진은 ReAct 실행 루프를 고정한 채 계획 수립, 도구 구성, 컨텍스트 관리 세 가지만 따로 바꿔가며 4개 모델과 2개 벤치마크에서 176개 설정을 비교했다. 평가 과제는 SWE-Bench Verified의 검증된 GitHub 이슈 500건과 Terminal-Bench 2.1의 명령줄 작업 89건이다. 가장 뚜렷한 결과는 컨텍스트 예산이 작을수록 관리 전략의 효과가 커진다는 점이었다. 32k에서는 관리 유무에 따른 평균 성공률 차이가 SWE-Bench 기준 35.7%p였지만, 128k에서는 2.7%p로 줄었다.
그런데 이 차이의 대부분은 모델이 더 똑똑해져서 생긴 것이 아니었다. 관리 없이 돌린 구성의 컨텍스트 초과 실패율은 32k에서 78.7%에 달했고, 관리 전략을 적용한 모든 구성에서는 초과 실패가 0건이었다. 관리는 에이전트의 판단을 바꾸는 장치가 아니라, 코드 수정과 검증까지 도달하도록 실행을 연장해 주는 장치에 가깝다는 뜻이다.
생략 먼저, 요약은 나중. 그리고 복구는 거의 쓰이지 않는다
비용 대비 성능이 가장 좋았던 전략은 오래된 도구 출력을 먼저 짧은 자리표시자로 생략하고, 그래도 한계를 넘으면 그때 요약으로 압축하는 단계형 방식이었다. 8개 모델·벤치마크 조합 가운데 7개에서 작업당 비용이 가장 낮았다. 반면 생략한 원문을 다시 불러오는 복구 기능은 기대에 한참 못 미쳤다. 해당 기능을 켠 64개 설정 중 56.3%가 단 한 번도 호출하지 않았고, 128k에서는 작업당 평균 0.007회에 그쳤다.
계획 기능도 만능이 아니었다. 30B 모델에서는 SWE-Bench 성공률이 13.6%에서 25.2%로 올랐지만, 550B급에서는 성공률이 2.0%p 낮아지는 대신 비용이 약 30% 줄었다. 강한 모델에서 줄어든 실행은 주로 코드 수정 후의 불필요한 재검증이었다. 전용 파일 도구 역시 셸이 서툰 모델에만 도움이 됐다. 550B 모델은 bash만 줬을 때 성공률이 65.8%에서 69.4%로 오르고 작업당 비용은 2.33달러에서 1.11달러로 떨어졌다.
Tech Insight — 하네스 설정을 남의 ‘모범 사례’에서 복사해 오면 손해 볼 가능성이 크다. 약한 모델에게 계획과 전용 도구는 보조 바퀴지만, 강한 모델에게는 같은 장치가 비용만 늘리는 족쇄가 된다. 사내 에이전트를 운영 중이라면 모델을 교체할 때마다 하네스 기본값도 함께 재측정하는 것이 맞다.
글은 직접 쓰고, 트집만 맡겨라
원칙 1. 모델이 제안한 표현은 한 단어도 쓰지 않는다
필자의 전제는 단순하다. 아무리 다듬어도 많은 독자는 LLM이 만든 문단을 글이 아니라 생성된 출력물로 받아들인다는 것이다. 그래서 순서를 뒤집는다. 먼저 직접 쓰고, 그다음 좋은 모델에게 결함을 찾게 한다. 최첨단 모델은 듣기 좋은 표현을 고르는 데 매우 능하지만, 그 문장들은 하나같이 잡지 헤드라인처럼 나온다. 헤드라인 하나는 좋아도 헤드라인 수십 개로 이어 붙인 글은 읽는 사람에게 이상하게 느껴진다.
그래서 마음에 들거나 기존 표현보다 낫다고 확신하더라도 예외를 두지 않는 것을 안전장치로 삼는다. 모델이 글을 획일적인 가공품으로 바꾸는 모든 경로를 사람이 빠짐없이 식별할 수 있다는 전제에 기대지 않겠다는 뜻이다.
원칙 2. 칭찬을 금지어로 설정한다
두 번째 원칙은 더 미묘하다. LLM은 문구뿐 아니라 칭찬으로도 글을 바꾼다. 초안에는 반드시 덜어낼 문단과 흐트러진 주제 흐름이 있는데, 모델은 구조부터 연결부, 비유, 인용까지 칭찬하기 쉽다. 그 격려가 초안의 선택을 고수하게 만들고, 다시 생각하고 고쳐 쓰는 과정을 건너뛰게 한다. 필자는 격려를 명시적으로 금지하고, 그래도 새어 나오는 칭찬을 계속 경계하라고 말한다.
모델에 맡길 일은 따로 있다. 수동태 남용, 동사의 명사화, 동작이 드러나지 않는 문장, 반복되는 표현, ‘매우’나 ‘실제로’ 같은 불필요한 수식어, 자리만 바꿔도 명료해지는 문단 후보를 찾는 일이다. 수정은 직접 하고, 원문과 수정본 비교는 편집 맥락을 모르는 별도의 모델에 맡긴다. 방금 고쳤다는 사실을 아는 모델은 사용자가 수정본을 고르길 원한다는 것까지 알아채기 때문이다.
Tech Insight — 이 원칙은 개발 문서와 커밋 메시지에 그대로 적용된다. 댓글에서 한 개발자는 커밋 메시지와 PR 설명을 다시 직접 쓰기 시작한 뒤 에이전트가 만든 코드를 훨씬 깊이 이해하게 됐다고 말한다. 생성 비용이 0에 가까워질수록, 직접 쓰는 행위 자체가 곧 리뷰 행위가 된다.
8바이트를 6바이트로 줄여 100TB를 아꼈다
해시를 많이 뿌릴수록 좋다는 상식이 무너졌다
Cloudflare는 캐시 요청을 서버로 분배하는 내부 라우터 PBR에서 예상보다 큰 메모리 사용량을 발견했다. 원인은 일관된 해싱 구현이었다. 서버 100대 기준으로 서버당 해시가 하나뿐이면 담당 구간의 변동계수가 약 99%에 달해, 어떤 서버는 목표의 두 배를 처리하고 어떤 서버는 거의 놀게 된다. 그래서 NGINX도 Pingora도 서버당 기본 160개를 쓴다. 여기에 디스크 용량 가중치가 곱해지고, 규정 준수와 캐시 기능 조합마다 별도의 링이 생기면서 해시 데이터만 일부 경우 6GB까지 불어났다.
성능 팀은 이 상수를 다시 계산했다. 서버당 해시가 k개일 때 변동계수는 √((N-1)/(Nk+1))로 줄어든다. 기본값 160에 가중치 625를 곱해 서버당 10만 개가 됐을 때, 마지막에 추가한 9만 개가 줄여주는 오차는 0.7%에 불과했다. 게다가 32비트 해시 공간에서는 생일 역설 때문에 충돌이 빠르게 늘어난다. 서버 2,048대 데이터센터 시뮬레이션에서는 해시를 1만 개에서 10만 개로 늘리는 구간에서 오차가 오히려 증가했다. 결론은 해시 수 90% 감축이었다.
Rust 정렬 규칙을 피해 항목당 2바이트를 벌었다
기존 Point 구조체는 hash를 u32, index를 u32로 담아 8바이트를 차지했다. PBR이 동시에 6만 5천 대를 넘는 서버를 조정할 일은 없으니 인덱스는 u16이면 충분한데, 막상 u16으로 바꿔도 4바이트 정렬 요구 때문에 구조체 크기는 그대로 8바이트였다. repr(packed)는 알려진 안전성 문제가 있어, 대신 [u8; 6] 배열과 접근자 메서드로 바꿨다. 가독성은 떨어지지만 두 방식은 같은 기계어로 컴파일된다. 항목당 8바이트를 6바이트로 줄여 해당 자료구조의 메모리를 25% 절감했다.
전환 과정도 참고할 만하다. 해시 링이 바뀌면 요청 목적지가 바뀌면서 전 세계 캐시가 사실상 무효화되고 원본 서버로 트래픽이 몰린다. 그래서 기존 링과 축소된 새 링을 동시에 메모리에 올려둔 채, 새 링으로 보낼 트래픽 비율과 적용 데이터센터 범위를 각각 따로 제어하며 단계적으로 옮겼다. 문제가 생기면 재배포 없이 기존 링으로 되돌릴 수 있었고, 전환율이 100%에 도달한 뒤 구형 경로를 제거하자 전 세계 메모리 사용량이 약 100TB 줄었다.
Tech Insight — 이 최적화의 본체는 Rust가 아니라 기본값을 의심한 행위다. 160이라는 숫자는 NGINX 시절부터 아무도 다시 계산하지 않은 상수였다. 규모가 커질수록 남이 정해 둔 기본값 하나가 그대로 예산이 된다. 세 번째 글도 결국 첫 번째 글과 같은 말을 하고 있는 셈이다.
관련 글
출처
- arXiv — 코딩 에이전트 하네스 설계에 관한 실증 연구
- GeekNews — 코딩 에이전트 하네스 설계에 관한 실증 연구
- sockpuppet.org — How to Write with an LLM (2026-09-17)
- GeekNews — LLM과 함께 글 쓰는 법
- Cloudflare Blog — Saving 100 TB of RAM with math
- GeekNews — Cloudflare, 수학과 Rust로 RAM 100TB 추가 절감
AI Biz Insider · Tech Digest · aibizinsider.com
