AI 코딩 도우미가 같은 컨텍스트를 반복 읽는 이유와 중복 줄이기

AI 프로그래밍 어시스턴트를 사용하다 보면 자주 이런 상황을 마주한다:

방금 어떤 파일을 읽었는데 잠시 후 다시 열고, 이미 프로젝트 구조를 분석했는데 코드를 수정하기 전에 다시 검색하고, 작업이 오래 지속될수록 반복 읽기가 더 뚜렷해 보인다.

이는 대기 시간을 늘릴 뿐만 아니라, 작업이 줄곧 "계속 분석 중"에 머물러 구현 단계로 좀처럼 들어가지 못하게 할 수도 있다.

하지만 해결 방법은 단순히 "같은 파일은 한 번만 읽어야 한다"고 요구하는 것이 아니다. 어떤 재읽기는 필요한 검증이고, 어떤 것은 작업 상태 관리가 불명확해서 생긴다. 진정으로 줄여야 하는 것은 새로운 정보를 얻지 못하고 작업도 진전시키지 못하는 반복 읽기다.

一. 먼저 구분하라: 반복 읽기가 필요한가?

겉으로는 같은 읽기 동작이라도 목적은 완전히 다를 수 있다.

상황 | 합리적인가 | 이유 파일이 방금 수정되어 관련 메서드를 다시 확인 | 합리적 | 최신 상태를 확인해야 함 이전 출력이 잘려 누락된 부분을 보충해서 읽음 | 합리적 | 정보가 아직 불완전함 수정 전에 구체적인 코드 위치를 대조 | 대체로 합리적 | 오래된 내용을 기반으로 편집하는 것을 방지 진입점을 이미 확인했는데도 계속 전체 프로젝트를 스캔 | 대체로 불필요 | 새로 답해야 할 질문이 없음 완전한 결론을 이미 저장했는데도 전체 원문을 다시 읽음 | 대체로 피할 수 있음 | 기존 요약을 먼저 사용할 수 있음 여러 에이전트가 같은 공통 정보를 각각 반복 분석 | 최적화할 수 있음 | 공통 결론을 공유할 수 있음

판단 기준은 간단하다:

이번 읽기로 해결하려는 아직 해결되지 않은 문제는 무엇인가?

구체적인 답을 줄 수 없다면, 작업이 순환에 빠졌는지 점검할 가치가 있다.

二. 왜 같은 컨텍스트를 반복해서 보는가?

1. 채팅 기록은 신뢰할 수 있는 작업 상태표가 아니다

어떤 정보가 한때 대화에 등장했다고 해서 이후 모든 단계에서 안정적이고 정확하게 사용할 수 있는 것은 아니다.

긴 작업에는 요구사항, 로그, 코드, 오류, 도구 출력, 여러 차례의 수정이 포함된다. 중요한 결론은 방대한 정보에 묻힐 수도 있고, 컨텍스트 압축 후 일부 요약만 남을 수도 있다.

예를 들어 앞에서 이미 이렇게 확인했다:

사용자 조회 진입점은 UserController#getUser 에 있다.

하지만 이후에 "이미 사용자 모듈을 분석했다"만 남았다면, 에이전트는 진입점을 다시 검색할 수 있다.

문제는 단지 "기억하지 못하는 것"이 아니라, 남아 있는 정보가 작업을 직접 이어가기에 충분하지 않다는 것일 수도 있다.

2. 과정은 저장했지만 결론은 저장하지 않았다

다음과 같은 기록은 가치가 제한적이다:

이미 Controller, Service, Mapper를 읽었다.

그것은 무엇을 읽었는지 설명하지 않고, 다음에 무엇을 해야 하는지도 알려주지 않는다.

더 유용한 기록은 이렇다:

진입점: UserController #getUser 비즈니스 로직: UserService #getUser 조회 위치: UserMapper #selectById 확인됨: 사용자가 존재하지 않으면 조회 결과가 비어 있을 수 있다. 현재 비즈니스 로직은 이 상황을 처리하지 않는다. 다음 단계: 프로젝트에 이미 있는 "사용자 없음" 예외 규범을 대조한다.

"어떤 파일을 읽었는가"는 이력 기록이고, "무엇을 확인했고 무엇이 아직 부족한가"가 바로 계속 실행할 수 있는 작업 상태다.

3. 파일이 변경되었는지 불확실하다

코드는 작업 중에 수정될 수 있고, 사용자나 포매팅 도구, 혹은 다른 에이전트에 의해 업데이트될 수도 있다.

버전 정보가 없으면 에이전트는 이전 분석이 여전히 성립하는지 판단하기 어려워, 어쩔 수 없이 다시 읽게 된다.

따라서 무효한 재읽기를 방지하려면 두 가지 문제를 해결해야 한다:

- 이미 무엇을 알고 있는가?

- 이 정보가 지금도 여전히 유효한가?

4. 검색에 명확한 정지 조건이 없다

"프로젝트를 전면적으로 분석해 봐"에는 명확한 종점이 없다.

에이전트는 관련 파일을 계속 발견하고 더 많은 파일을 읽으며, 이어서 전체 이해를 다시 세우기 위해 이전에 읽은 내용을 되돌아가 읽을 수 있다.

이에 비해 이런 작업은 끝내기가 더 쉽다:

주문 생성 인터페이스, 트랜잭션 경계, 주문 쓰기 위치를 찾아낸다. 해당 코드 증거를 찾으면 탐색을 멈추고 결론을 출력한다.

정지 조건이 없으면, 컨텍스트를 늘리는 것이 실제 진전을 대체하기 쉽다.

三. 핵심 방법: 짧은 작업 체크포인트를 유지하라

긴 작업의 경우 프로젝트가 허용하는 위치에 작업 체크포인트, 예를 들어 TASK_STATE.md 를 유지할 수 있다.

그것은 전체 대화를 저장할 필요 없이, 작업을 이어가기 위해 반드시 필요한 정보만 남기면 된다:

현재 작업 사용자 조회 인터페이스에서 사용자가 존재하지 않을 때의 예외를 수정한다. # 확인된 사실 - 진입점: UserController#getUser - 비즈니스 메서드: UserService#getUser - 조회 메서드: UserMapper#selectById - 조회 결과가 비어 있을 수 있으며, 현재 코드는 변환 메서드를 직접 호출한다. # 근거와 유효성 - 위 파일들의 관련 메서드를 확인했다. - 분석 후 이 파일들은 아직 수정되지 않았다. - 관련 파일이 변경되면 영향을 받는 메서드를 다시 대조한다. # 완료됨 - 호출 체인을 파악했다. - 예외를 촉발하는 분기를 확인했다. # 미해결 문제 - 프로젝트에 재사용할 수 있는 사용자 없음 예외가 이미 있는가? # 다음 단계 기존 예외 정의를 검색하여 최소 수정 방안을 정한다. # 검증 상태 아직 코드를 수정하지 않았고, 아직 테스트를 실행하지 않았다.

체크포인트의 가장 중요한 역할은, 에이전트가 작업을 재개할 때 다음과 같이 답할 수 있게 하는 것이다:

나는 어느 단계에 있고, 어떤 결론을 신뢰할 수 있으며, 다음 단계로 구체적으로 무엇을 하는가?

매번 도구 호출 후에 그것을 업데이트할 필요는 없다. 한 단계를 완료했거나, 방안을 바꿨거나, 핵심 파일을 수정했거나, 인계를 준비할 때 업데이트하면 되며, 기록 유지 자체가 새로운 부담이 되는 것을 피해야 한다.

四. "요약 우선, 원문은 필요에 따라" 읽기 방식을 채택하라

반복 읽기를 줄인다고 해서 에이전트가 요약만 믿게 하라는 것은 아니다.

더 합리적인 순서는 이렇다:

- 먼저 작업 체크포인트를 본다.

- 현재 부족한 정보를 명확히 한다.

- 해당 파일과 메서드를 찾는다.

- 이 문제를 해결하는 데 필요한 조각만 읽는다.

예를 들어 문제가 UserService#getUser 에 있다는 것을 알고 있다면, 전체 Service 디렉터리를 다시 읽을 필요가 없다.

구현 세부 사항을 확인해야 할 때 그 메서드와 그에 필요한 의존성을 읽으면 된다. 출력이 불완전할 때 범위를 넓히면 된다.

요약은 내비게이션에 쓰고, 원문은 검증에 쓴다. 둘은 각자 역할이 있어 비용과 오판을 동시에 줄일 수 있다.

五. 재읽기에 이유를 부여하라, 일률적으로 금지하지 말라

반복 읽기는 적어도 다음 중 한 가지 상황에 해당해야 한다고 약정할 수 있다:

재읽기 이유 | 처리 방식 파일이 이미 변경됨 | 영향받은 영역을 다시 읽음 이전 출력이 불완전함 | 누락된 내용을 보충해서 읽음 새로운 구체적 문제가 발생함 | 문제와 관련된 부분을 읽음 곧 수정을 시행할 예정 | 대상 코드의 최신 상태를 대조 기존 결론이 서로 모순됨 | 원래 증거로 돌아가 검증

에이전트 워크플로를 제어할 수 있는 개발자라면 다음과 같은 것도 기록할 수 있다:

파일 경로 + 파일 버전 또는 콘텐츠 해시 + 읽은 범위 + 읽기 목적

같은 파일, 같은 버전, 같은 범위이고 새로운 읽기 목적도 없다면, 기존 결과를 우선 재사용할 수 있다.

여기 쉽게 간과하는 세부 사항이 하나 있다: Git 커밋 번호는 작업 영역 파일의 최신 상태를 나타내기에 충분하지 않다. 파일에 아직 커밋되지 않은 수정이 포함되어 있을 수 있기 때문이다. 실제 파일 변화와 결합해 판단해야 한다.

六. 다중 에이전트 작업에서는 결론과 의존성을 공유하라

다자 협업식 AI 워크플로 역시 반복 읽기를 증폭시킬 수 있다.

세 에이전트가 각각 구현, 테스트, 검토를 맡는다고 가정하면, 모두가 처음부터 프로젝트 구조를 분석한다면 시간을 중복 소모하게 된다.

더 나은 인계 내용은 다음과 같다:

공유 배경: 사용자 조회 인터페이스의 진입점, 호출 체인, 비즈니스 약정. 구현 작업: 확인된 널(null) 처리 분기를 수정한다. 테스트 작업: 약정에 따라 정상 조회와 사용자 없음 테스트를 보충한다. 검토 작업: 최종 변경이 약정을 충족하는지, 그리고 호출자에 영향을 주는지 확인한다.

공유 정보는 대응하는 버전도 명시해야 한다. 구현 에이전트가 코드를 수정한 후에는 그 결론에 의존하는 작업에 다시 대조하도록 알려야 한다.

다만 코드 검토가 독립적 확인을 유지하는 것은 가치가 있다. 반복 분석을 줄인다고 해서 검토자가 구현자의 모든 판단을 그대로 받아들이게 하라는 것은 아니다.

七. 바로 사용할 수 있는 한 단락의 프롬프트

다음 제약은 긴 작업의 서두에 넣기에 적합하다:

새로운 정보가 없는 반복 읽기를 줄이고, 다음 규칙을 준수하라: 1. 먼저 이번 단계에서 답해야 할 질문과 정지 조건을 정의하라. 2. 짧은 체크포인트를 유지하여 확인된 사실, 근거, 미해결 문제, 다음 단계, 검증 상태를 기록하라. 3. 이미 읽었고 변경되지 않은 내용은 기존 결론을 우선 재사용하라. 4. 재읽기가 필요하면 이유를 간략히 설명하라: 파일 변경, 출력 잘림, 새 문제, 또는 수정 전 대조. 5. 대상 메서드나 필요한 조각을 우선 읽고, 전체 프로젝트를 반복 스캔하지 말라. 6. 연속 검색에서 새로운 정보를 얻지 못하면 검색 확장을 멈추고, 알고 있는 사실을 요약하고 구체적인 공백을 지적하라. 7. 요약은 필요한 검증을 대체할 수 없으며, 읽기를 줄이기 위해 코드를 추측해서는 안 된다.

이 프롬프트의 핵심은 "도구를 몇 번 덜 호출하는 것"이 아니라, 매번 읽기에 목적을 부여하고 각 단계가 끝날 수 있게 하는 데 있다.

八. 최적화가 효과적인지 어떻게 판단하는가?

읽기 횟수만 비교해서는 안 된다. 읽기는 줄었지만 핵심 제약을 놓치면 결과가 더 나쁠 수 있다.

다음 지표를 함께 관찰할 수 있다:

지표 | 관찰 중점 무효 반복 읽기 | 같은 내용이 이유 없이 반복해서 읽히는가 작업 완료 시간 | 구현과 검증으로 더 빨리 들어가는가 인간의 수정 횟수 | 요약 누락이나 노후화로 오류가 발생하는가 인수 결과 | 기존 비즈니스와 테스트 요구사항을 충족하는가

기반 프롬프트 캐시의 경우, 시스템이 지원하더라도 작업 상태 관리를 대체할 수 없다. 캐시는 일부 반복 입력의 처리 비용을 줄일 수 있지만, 에이전트에게 "이 문제는 이미 해결되었으니 다음 단계로 넘어가도 된다"고 자동으로 알려주지는 않는다.

맺음말

모델이 같은 컨텍스트를 반복해서 읽는 것은, 흔히 작업 상태가 불명확하다는 것을 드러낸다: 결론이 저장되지 않았거나, 유효성을 판단할 수 없거나, 탐색에 종점이 없거나.

이를 해결하려면 세 가지를 명확히 적어야 한다:

무엇을 이미 확인했는지, 어떤 경우에 다시 검증해야 하는지, 그리고 다음에 무엇을 하는지.

이 정보들이 명확해지면, 에이전트는 반복 탐색에서 실제 전달로 더 쉽게 나아갈 수 있다.