오늘의 AI 글: 코딩 에이전트는 왜 긴 대화에서 길을 잃는가

왜 이 글인가

코딩 에이전트를 오래 써본 사람이라면 묘하게 익숙한 순간이 있다. 처음에는 요구사항을 잘 이해하고, 파일도 정확히 읽고, 테스트도 돌리던 에이전트가 어느 순간부터 이미 확인한 내용을 다시 묻거나, 원래 목표와 살짝 다른 문제를 풀기 시작한다. 모델이 갑자기 멍청해진 것처럼 보이지만, 실제로는 더 구조적인 문제가 숨어 있다. 대화가 길어질수록 모델에게 매번 다시 보내야 하는 입력이 커지고, 그 안에서 중요한 신호가 로그·파일 내용·중간 대화에 묻힌다. 오늘 고른 Medium 글은 바로 이 “컨텍스트가 세션을 잡아먹는 문제”를 코딩 에이전트 구현자의 시선으로 차분하게 해부한다.

이 글이 오늘 특히 읽을 가치가 큰 이유는, 2026년의 AI 코딩 도구 경쟁이 단순히 “누가 더 좋은 모델을 쓰는가”에서 “누가 더 오래 안정적으로 일하게 만드는가”로 옮겨가고 있기 때문이다. Claude Code, Codex, OpenCode, OpenClaw 같은 도구는 이미 파일을 읽고, 명령을 실행하고, 코드를 고칠 수 있다. 이제 차이는 긴 작업에서 드러난다. 10분짜리 버그 수정은 대부분 잘한다. 하지만 2시간짜리 리팩터링, 여러 파일을 오가는 기능 구현, 테스트 실패를 반복적으로 좁혀가는 디버깅에서는 컨텍스트 관리가 품질과 비용을 좌우한다.

원문은 Claude-Code 스타일의 에이전트를 직접 만드는 연재의 네 번째 글로, 앞선 글에서 루프, 도구, 권한 시스템을 만들었다는 전제 위에서 “대화가 컨텍스트 윈도우보다 커지면 어떻게 할 것인가”를 다룬다. 이 주제는 도구 제작자에게만 중요한 것이 아니다. 실제 사용자인 개발자에게도 중요하다. 에이전트가 긴 세션에서 왜 산만해지는지 이해하면, 프롬프트를 더 길게 쓰는 대신 파일 읽기 범위, 로그 출력, 작업 요약, 체크리스트, 세션 재개 방식을 더 똑똑하게 설계할 수 있다.

또 하나 중요한 점은 원문이 “더 큰 컨텍스트 윈도우를 쓰면 된다”는 단순한 답을 거부한다는 것이다. 큰 윈도우는 시간을 벌어줄 뿐, 비용·지연·주의력 저하라는 문제를 없애지 않는다. 백만 토큰을 넣을 수 있어도 모델이 그 모든 내용을 같은 비중으로 다루는 것은 아니다. 오히려 긴 입력은 원래 목표를 중간 어딘가에 파묻고, 최근의 도구 출력이나 로그에 과도하게 끌려가게 만들 수 있다. 코딩 에이전트의 안정성은 모델 크기만이 아니라 컨텍스트를 어떻게 다이어트하고, 무엇을 앵커로 남기고, 무엇을 버릴지에 달려 있다.

핵심 요약

• 원문의 핵심 문제의식은 간단하다. 에이전트는 매 API 호출 때마다 시스템 프롬프트, 도구 정의, 사용자·어시스턴트 대화, 도구 결과를 다시 모델에게 보내야 한다. 세션이 길어질수록 이 입력은 계속 커지고, 특히 파일 읽기와 로그 출력 같은 도구 결과가 토큰 대부분을 차지한다.

• 컨텍스트가 커질 때 생기는 문제는 두 가지다. 하나는 하드 리밋이다. 입력이 모델의 최대 컨텍스트를 넘으면 호출 자체가 실패한다. 더 위험한 것은 소프트 리밋이다. 아직 창 안에 들어가더라도 원래 목표와 핵심 제약이 대량의 중간 상태 속에 묻히면서 모델의 판단이 흐려진다.

• 큰 컨텍스트 윈도우는 만능 해결책이 아니다. 입력 길이가 늘면 비용이 증가하고, 첫 토큰이 나오기까지의 지연도 커진다. 무엇보다 모델은 긴 입력 전체에 균일하게 주의를 기울이지 않는다. 원문은 “창이 크면 된다”가 아니라 “창 안에 무엇을 남길지 설계해야 한다”고 말한다.

• 컨텍스트에는 수명이 다른 정보가 섞여 있다. 시스템 프롬프트와 도구 카탈로그는 거의 고정 비용이고, 대화 기록과 도구 출력은 계속 커지는 가변 비용이다. 원문은 특히 도구 출력이 전체 토큰의 70~90%를 차지할 수 있다고 지적한다. 따라서 압축의 우선순위는 모델의 답변보다 도구 결과에 있다.

• 글은 컨텍스트 관리의 세 가지 기본 전략으로 truncation, summarisation, eviction을 제시한다. 일부만 남기는 절단, 작은 의미 표현으로 바꾸는 요약, 아예 제거하는 퇴거다. 세 방법은 서로 대체재가 아니라 함께 쓰는 레이어다.

• 가장 싼 압축은 애초에 큰 출력이 대화로 들어오지 않게 하는 것이다. 예를 들어 10MB 로그를 전부 반환하지 말고 앞부분, 뒷부분, 또는 검색 결과 일부만 반환하게 도구 계약을 설계한다. 중요한 것은 “잘렸음”만 알리는 것이 아니라, 더 좁게 읽을 수 있는 다음 행동 힌트까지 제공하는 것이다.

• 오래된 대화는 요약으로 대체할 수 있다. 다만 원래 사용자 목표는 절대 요약하거나 제거하지 않는 편이 안전하다. 원문은 중간 작업을 요약하되, 최초 요청은 영구 앵커처럼 남겨야 한다고 본다. 에이전트가 목표를 잃으면 최근 로그가 새로운 목표처럼 보이기 때문이다.

• 요약은 가짜 assistant 메시지보다 user 역할의 요약 메시지로 넣는 편이 더 안전하다는 주장도 흥미롭다. assistant 역할로 넣으면 모델이 그것을 자기 자신의 이전 추론처럼 이어받아 혼동할 수 있다. user 역할의 요약은 외부에서 제공된 상태 업데이트처럼 작동한다.

• 스킬 시스템에 대한 설명도 실무적으로 중요하다. 모든 도구 정의와 절차를 항상 컨텍스트에 넣는 대신, 스킬 이름과 짧은 설명만 기본으로 노출하고 실제 절차는 필요할 때 로드하면 고정 비용을 크게 줄일 수 있다. 기능을 늘리면서도 기본 컨텍스트를 가볍게 유지하는 방법이다.

• 이 글의 결론은 개발자에게도 곧장 적용된다. 에이전트가 긴 작업을 안정적으로 수행하게 하려면 파일·로그·검색 결과를 필요한 만큼만 읽히고, 작업 상태를 주기적으로 요약하며, 원래 목표와 완료 조건을 계속 앵커로 남기고, 오래된 임시 출력은 과감히 버려야 한다.

원문의 논지를 단계별로 풀어보기

첫 번째 단계는 “대화는 공짜 기억이 아니다”라는 사실을 인정하는 것이다. 사람 입장에서는 채팅창에 이전 대화가 남아 있으니 에이전트가 자연스럽게 계속 기억한다고 느낀다. 하지만 모델 호출의 관점에서는 매번 그 대화를 다시 입력으로 보내야 한다. 시스템 프롬프트, 도구 설명, 사용자 메시지, assistant 답변, 파일 읽기 결과, 명령 출력이 모두 누적된다. 한 번 읽은 50KB 파일은 그 순간만 비용이 드는 것이 아니라, 정리하지 않으면 이후 모든 턴의 입력 비용으로 계속 반복된다. 에이전트 세션이 길어질수록 느려지고 비싸지는 이유가 여기에 있다.

두 번째 단계는 컨텍스트 안의 성분을 분리해서 보는 것이다. 시스템 프롬프트는 에이전트의 규칙과 정체성을 정의하므로 쉽게 줄일 수 없다. 도구 카탈로그도 기본적으로 고정 비용이다. 반면 메시지 기록과 도구 출력은 계속 커진다. 특히 위험한 것은 도구 출력이다. 개발자는 “파일을 읽었다”, “테스트를 돌렸다”고만 기억하지만, 모델 입력에는 파일 전체나 로그 전체가 남을 수 있다. 원문이 말하듯 많은 에이전트에서 토큰 사용량의 대부분은 모델이 한 말이 아니라 도구가 반환한 원시 데이터다.

세 번째 단계는 더 큰 창으로 문제를 미루지 않는 것이다. 최신 모델의 컨텍스트 윈도우가 커지면서 “그냥 다 넣으면 되지 않나”라는 유혹이 생긴다. 하지만 긴 입력은 비용과 지연을 증가시킨다. 더 중요한 문제는 주의력이다. 모델은 긴 문서를 읽을 수 있지만, 모든 부분을 같은 신뢰도로 반영하지는 않는다. 원래 사용자가 말한 목표가 수십 턴 전 중간 어딘가에 있고, 바로 직전 도구 출력이 수천 줄의 에러 로그라면 모델은 최근 로그의 국소 문제에 끌려갈 가능성이 커진다. 큰 창은 저장 공간이지 좋은 작업 기억이 아니다.

네 번째 단계는 세 가지 압축 방법을 상황에 맞게 쓰는 것이다. 절단은 가장 싸지만 손실이 크다. 로그의 마지막 200줄, 파일의 앞부분과 뒷부분, 검색 결과 상위 몇 개만 남기는 식이다. 요약은 의미를 더 잘 보존하지만 추가 모델 호출이 필요하다. 오래된 대화나 긴 분석 결과처럼 의미가 중요할 때 적합하다. 퇴거는 가장 과감하다. 한 번 확인했고 더 이상 필요 없는 디렉터리 목록, 실패한 명령의 긴 출력, 이미 반영된 파일 내용은 아예 제거하는 편이 낫다. 좋은 에이전트는 모든 정보를 영원히 들고 있지 않고, 정보마다 반감기를 둔다.

다섯 번째 단계는 도구 계층에서 먼저 줄이는 것이다. 원문이 특히 강조하는 부분이다. 10MB 로그가 이미 대화 기록에 들어온 뒤에는 그것을 줄이기 위해 다시 요약 비용을 써야 한다. 반대로 도구가 처음부터 “최대 200KB만 반환하고, 더 필요하면 grep이나 범위 읽기를 쓰라”고 알려주면 훨씬 싸다. 이 원칙은 사용자에게도 적용된다. 에이전트에게 “전체 로그 다 읽어봐”라고 하기보다 “최근 실패 구간 주변 100줄만 보고, 필요하면 특정 에러 문자열로 검색해”라고 지시하는 편이 세션 품질을 지킨다.

여섯 번째 단계는 오래된 턴을 요약하되, 목표는 앵커로 남기는 것이다. 요약은 단순히 “대화가 길어졌으니 줄이자”가 아니다. 무엇을 했고, 어떤 파일을 읽었고, 어떤 결정을 내렸고, 어떤 테스트가 통과하거나 실패했는지 보존해야 한다. 그러나 최초 사용자 메시지, 핵심 제약, 완료 조건은 요약으로 뭉개면 안 된다. 원문은 원래 목표를 절대 요약하거나 퇴거하지 말라고 본다. 이 조언은 실제 사용에도 유용하다. 긴 세션을 재개할 때는 “처음 목표는 이것이고, 지금까지 한 일은 이것이며, 남은 일은 이것”이라는 구조로 다시 앵커를 세우는 편이 좋다.

일곱 번째 단계는 슬라이딩 윈도우와 앵커를 함께 쓰는 것이다. 최근 몇 턴은 원문 그대로 유지해야 한다. 지금 수정 중인 파일 내용, 방금 실패한 테스트 로그, 사용자의 최신 지시는 요약보다 원본이 중요하다. 반면 중간의 오래된 작업은 요약으로 대체해도 된다. 여기에 영구 앵커를 둔다. 원래 목표, 중요한 사용자 제약, 현재 작업 파일, 완료 조건 같은 정보는 창이 미끄러져도 남겨야 한다. 이 구조가 있으면 에이전트는 최신 상태를 보면서도 처음 목적에서 멀어지지 않는다.

여덟 번째 단계는 스킬을 컨텍스트 경제의 관점에서 보는 것이다. 스킬은 단순한 편의 기능이 아니라, 항상 필요한 것과 필요할 때만 불러올 것을 분리하는 장치다. 모든 절차와 예시, 체크리스트를 시스템 프롬프트에 박아두면 에이전트는 아무 작업도 하지 않아도 무거워진다. 반대로 스킬 목록에는 이름과 짧은 설명만 두고, 실제 SKILL.md와 보조 파일은 필요할 때 읽게 하면 기본 상태가 가벼워진다. 개발팀이 사내 에이전트 규칙을 만들 때도 이 원칙은 중요하다. 모든 규칙을 한 파일에 몰아넣는 대신, 작업별로 불러올 수 있는 작고 명확한 절차로 나누는 편이 낫다.

마지막 단계는 컨텍스트 관리를 제품 기능이 아니라 운영 습관으로 받아들이는 것이다. 많은 사용자는 에이전트가 길을 잃으면 “모델이 별로다”라고 생각한다. 물론 모델 성능도 중요하다. 하지만 컨텍스트에 너무 많은 잡음을 넣고, 원래 목표를 갱신하지 않고, 로그를 통째로 먹이고, 오래된 상태를 정리하지 않으면 어떤 모델도 안정적으로 일하기 어렵다. 좋은 에이전트 사용법은 좋은 작업 관리와 닮아 있다. 필요한 자료만 전달하고, 결정사항을 요약하고, 기준점을 반복 확인하고, 오래된 임시 정보는 버린다.

일반 독자에게 중요한 포인트

• AI의 “기억”은 사람의 기억과 다르다. 대화창에 남아 있다고 해서 모델이 안정적으로 기억하는 것이 아니다. 매번 다시 읽는 입력이며, 길어질수록 중요한 내용이 잡음 속에 묻힐 수 있다.

• 더 큰 모델이나 더 큰 컨텍스트 창은 문제를 완전히 해결하지 않는다. 많은 정보가 들어간다는 것과 좋은 판단을 한다는 것은 다르다. 정리되지 않은 회의록 500쪽보다 잘 정리된 한 장의 결정 기록이 더 쓸모 있는 것과 같다.

• 코딩 에이전트의 실수는 종종 코드 작성 능력보다 정보 관리 실패에서 온다. 너무 큰 로그, 불필요한 파일 전체, 오래된 대화, 사라진 완료 조건이 섞이면 에이전트는 당연히 산만해진다.

• 좋은 AI 활용자는 질문을 잘하는 사람을 넘어, AI에게 들어가는 정보를 잘 다이어트하는 사람이다. 무엇을 읽힐지, 어느 정도만 보여줄지, 어떤 요약을 남길지 정하는 능력이 생산성 차이를 만든다.

• 이 원칙은 개발 밖에서도 통한다. 긴 문서 요약, 리서치, 이메일 정리, 기획안 작성에서도 원본을 무작정 다 넣는 것보다 핵심 목표와 최신 상태, 필요한 근거만 구조화해서 제공하는 편이 결과가 좋다.

적용 아이디어

• 에이전트에게 큰 로그를 통째로 읽히지 않는다. 먼저 에러 키워드로 검색하고, 실패 지점 주변의 짧은 범위만 읽게 한다. 필요하면 “앞 100줄, 뒤 100줄, 생략 표시”처럼 제한을 명시한다.

• 긴 작업을 시작할 때 원래 목표와 완료 조건을 별도 파일이나 세션 상단 메시지로 고정한다. “무엇을 고치는가”, “무엇은 건드리지 않는가”, “어떤 테스트가 통과해야 하는가”를 앵커로 남긴다.

• 세션이 길어지면 중간에 에이전트에게 상태 요약을 만들게 한다. 요약에는 읽은 파일, 변경한 파일, 결정사항, 실패한 시도, 남은 작업, 다음 검증 명령을 포함한다. 단순 감상 요약은 도움이 적다.

• 최근 작업 원본과 오래된 작업 요약을 구분한다. 방금 실패한 테스트 로그나 현재 편집 중인 파일은 원본이 필요하지만, 30분 전의 디렉터리 목록은 대부분 요약이나 삭제로 충분하다.

• 저장소의 에이전트 지침을 하나의 거대한 문서로 키우지 않는다. 공통 원칙은 짧게 유지하고, 코드 리뷰·릴리스 노트·프론트엔드 수정·보안 점검 같은 절차는 필요할 때 불러오는 스킬 또는 별도 문서로 나눈다.

• 에이전트가 파일을 읽을 때도 목적을 붙인다. “이 파일 전체를 읽어”보다 “이 파일에서 인증 토큰 갱신과 관련된 함수, 타입, 에러 처리만 확인해”가 낫다. 목적이 좁을수록 불필요한 컨텍스트가 줄어든다.

• 작업 완료 전에는 “처음 목표와 비교해 빠진 것이 있는지”를 명시적으로 검사하게 한다. 최신 오류만 해결하다 보면 원래 요구사항 일부가 잊히기 쉽다. 마지막 리뷰는 항상 최초 목표와 완료 조건으로 되돌아가야 한다.

• 도구를 만들거나 팀 내부 자동화를 설계한다면 모든 대량 출력 도구에 기본 제한과 후속 힌트를 넣는다. 예를 들어 read_file은 크기 제한과 range 옵션을, run_tests는 전체 로그 대신 실패 요약과 원본 로그 경로를, search는 상위 결과와 재검색 힌트를 반환하게 한다.

읽기 우선순위

코딩 에이전트를 단순히 “코드 빨리 써주는 도구”로 쓰는 단계라면 이 글은 조금 구현자 취향으로 느껴질 수 있다. 하지만 Claude Code, Codex, OpenCode, OpenClaw 같은 도구를 매일 쓰고 있고, 긴 세션에서 품질이 흔들리는 문제를 겪었다면 우선순위가 높다. 원문은 에이전트가 왜 길을 잃는지 모델 탓으로만 돌리지 않고, 컨텍스트라는 운영 자원을 어떻게 관리해야 하는지 설명한다.

특히 에이전트 도구를 직접 만들거나, 사내 개발 워크플로에 AI를 깊게 넣으려는 팀이라면 원문을 읽어볼 만하다. 도구 출력 제한, 요약 메시지의 역할, 원래 목표 앵커링, 스킬 기반 지연 로딩 같은 아이디어는 구현 세부사항처럼 보이지만 실제 비용과 안정성에 직접 영향을 준다. 오늘의 결론은 간단하다. 코딩 에이전트의 다음 경쟁력은 더 많이 기억하는 것이 아니라, 무엇을 잊어도 되는지 아는 데서 나온다.