AI 글이 유독 안 읽히는 이유

AI 에이전트 컨텍스트 엔지니어링을 표현한 녹색 개발자 테마 일러스트
AI 에이전트 컨텍스트 엔지니어링을 표현한 녹색 개발자 테마 일러스트
DIGEST
  • 컨텍스트 엔지니어링의 현주소: 긴 컨텍스트의 네 가지 실패와 ‘전략적 망각’
  • AI가 쓴 글이 어려운 이유: 정보 밀도를 좇는 학습 목표가 문장 구조를 바꿨다
  • 더 큰 야심을 가져라: 몇 시간이면 만들 수 있게 된 프로젝트들과 검증 장치

에이전트를 쓰는 팀이라면 한 번쯤 겪었을 일입니다. 대화가 길어질수록 모델이 같은 실수를 반복하고, 분명 맞는 답을 내놓던 도구가 어느 순간 엉뚱해집니다. 오늘 GeekNews에서는 그 원인을 정리한 글, AI 문장이 왜 읽기 힘든지 분석한 논문, 그리고 AI로 무엇까지 만들어 볼 수 있는지 보여주는 글이 나란히 올라왔습니다. 세 글을 한 줄로 묶으면 ‘모델은 강해졌지만 쓰는 방식이 결과를 가른다’입니다.

컨텍스트 엔지니어링의 현주소

긴 컨텍스트가 만든 네 가지 실패

Drew Breunig는 2024년 말에 기대했던 것처럼 백만 토큰 컨텍스트가 검색이나 에이전트 설계를 대체하지 못했다고 짚습니다. 오히려 네 가지 실패가 나타났습니다. 잘못된 사실이 계속 남는 컨텍스트 오염(context poisoning), 긴 기록이 모델의 기본 지식을 덮는 컨텍스트 분산(distraction), 관련 없는 정보가 답을 흐리는 혼동(confusion), 도구와 정보가 서로 충돌하는 충돌(clash)입니다. 글에 인용된 실험에서는 Gemini 2.5 에이전트가 컨텍스트가 대략 10만 토큰을 넘기자 과거 행동을 반복하기 시작했습니다.

여섯 가지 대응책과 새로운 문제

대응책은 컨텍스트 보강, 도구 선별(tool loadout), 하위 에이전트로 격리하는 quarantine, 가지치기, 외부 저장소로 내보내는 offloading, 요약(compaction)입니다. 한 기업이 엔지니어 1인당 스킬 600개를 올렸다가 성능이 떨어진 사례도 소개됩니다. 모델이 한 번에 12시간짜리 과제를 수행하는 시대에는 새로운 문제도 생깁니다. 모델이 가중치에 박힌 습관과 싸우는 현상, 그리고 한 가설에 매달리는 컨텍스트 관성(inertia)입니다. 그래서 일정 주기로 컨텍스트를 비우고 노트만 남기는 ‘전략적 망각’이 해법으로 거론되고, 글에 따르면 망각을 쓴 에이전트 4개가 병렬 에이전트 4개보다 높은 점수를 냈습니다.

Tech Insight — 프롬프트에서 컨텍스트로, 다시 하네스로 용어가 바뀌어도 핵심은 같습니다. 무엇을 코드로 고정하고 무엇을 모델에 맡길지 정하는 일입니다. 에이전트를 도입했다면 모델 교체를 검토하기 전에 도구 목록, 기록 길이, 요약 규칙부터 점검하는 편이 비용이 적게 듭니다.


AI가 쓴 글은 왜 이해하기 어려울까

아홉 개 모델이 공통으로 보인 패턴

Clark, Martin, Mahowald의 논문은 사람이 처리하기 어려운 언어 특징을 측정했습니다. 목적격 관계절, 긴 의존 거리, 드문 단어 연쇄 같은 것들입니다. 분석 대상인 최신 모델과 준최신 모델 아홉 개 모두가 사람보다 무생물 주어에 동작 동사를 붙이는 문장과 낮은 빈도의 n-gram을 더 많이 썼습니다. 대부분은 의존 거리가 더 길고 명사를 겹겹이 쌓는 경향도 보였고, 정도는 모델 계열마다 달랐습니다. 왕복 번역으로 만든 바꿔쓰기보다도 어려운 특징이 자주 나타났습니다.

정보 밀도 가설

저자들은 사람의 언어가 ‘전달 성공’을 목표로 다듬어진 반면, AI의 글은 수학, 코드, 추론처럼 정보 밀도를 보상하는 목표의 영향을 받는다고 해석합니다. 길이에 페널티를 주고 미세조정하자 출력이 사람다운 패턴에서 멀어졌다는 실험이 이 가설을 뒷받침하는 개념 증명으로 제시됩니다. 논문은 효과 크기 같은 세부 수치를 초록에서 밝히지 않으므로, 결론은 방향성으로 읽는 것이 안전합니다.

Tech Insight — 고객 안내문, 제안서, 문서 초안을 AI에 맡기는 팀이라면 ‘맞는 내용’과 ‘읽히는 내용’을 따로 검수해야 합니다. 문장 길이 제한, 독자 수준 지정, 사람의 최종 윤문 단계를 워크플로에 넣는 것이 현실적인 대응입니다.


우리가 만드는 소프트웨어에 더 큰 야심을

몇 시간이면 되는 일이 된 이유

Dan Luu는 AI 덕분에 예전에는 비용 때문에 시도하지 못한 프로젝트가 가능해졌다고 주장합니다. 본인이 만든 정규식 엔진과 ripgrep 포크, Rust 빌드 가속은 각각 몇 시간 만에 끝났고, 예전 같으면 1년 이상 걸렸을 거라고 추정합니다. Postgres를 다시 구현한 pgrust 프로젝트는 AI 생성물이라는 의심에도 실제 Postgres 버그를 찾아냈다고 소개합니다. 사례 중에는 GPT-6 Astra로 zstd를 구현해 등록된 테스트의 99% 이상을 약 1달러에 통과시킨 것도 있습니다.

반론과 안전장치

Yossi Kreinin은 합격과 불합격 기준이 분명하지 않은 에이전트 루프는 대부분 실패하고, 최적화가 과적합된 유지보수 불가능한 코드를 낳을 수 있다고 경고합니다. Luu는 퍼징과 속성 기반 테스트처럼 스스로 검증하는 장치가 있으면 야심찬 프로젝트도 운영할 수 있다고 답합니다. 다만 어려운 과제에서는 모델이 여전히 한계를 보이고, 개인용 도구는 연구소의 개선으로 금방 쓸모가 사라질 수 있다는 점도 인정합니다.

Tech Insight — 첫 번째 글의 ‘컨텍스트 관리’와 세 번째 글의 ‘자동 검증’은 같은 이야기입니다. 큰 프로젝트를 에이전트에 맡길수록 테스트와 합격 기준이라는 결정론적 틀이 먼저 필요합니다. 사내 도구 하나를 골라 테스트부터 작성한 뒤 에이전트에 맡겨 보는 실험을 권합니다.


관련 글

출처

  1. Drew Breunig, The State of Context Engineering (2026.10.24)
  2. Clark, Martin, Mahowald, Why is AI-generated language so hard to understand? (arXiv 2610.29162)
  3. Dan Luu, We should be more ambitious about the software we build
  4. GeekNews 토픽 36019, 35947, 35950

AI Biz Insider · Tech Digest · aibizinsider.com


AI Biz Insider에서 더 알아보기

구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.

코멘트

답글 남기기