의도 연속성: 코딩 에이전트의 긴 이력 문제에 대한 새로운 해결책
장기 프로젝트의 코딩 에이전트는 초기 규칙을 자주 잊어버려 내부 데이터베이스 ID 유출과 같은 문제를 일으킵니다. 기존 솔루션은 더 큰 컨텍스트 윈도우나 RAG 검색에 의존하지만, 모델이 모든 텍스트를 '기억'할 수 있더라도 오래된 규칙이 현재 작업에 관련이 있는지 자동으로 판단할 수 없습니다. 이 글은 '의도 연속성(Intent Continuity)' 개념을 소개하고 가벼운 순수 Python 구현을 제공합니다. 기본 검색에 검증 레이어를 추가하여 요구사항 커버리지를 57%에서 100%로 높였으며, 8개 테스트 작업 모두 정확했습니다. 벡터 데이터베이스, 임베딩, LLM 호출을 전혀 사용하지 않아 배포가 매우 쉽습니다. 저자는 또한 원래 실험의 버그를 정직하게 인정하여 엄격한 엔지니어링 태도를 보여줍니다.
배경 및 해결 과제
장기간 운영되는 코딩 에이전트 프로젝트에서 자주 마주치는 좌절스러운 현상이 있다: 초기 단계에서 설정한 핵심 규칙이 "공중으로 사라지는" 듯한 느낌이다. 아무도 그 규칙을 삭제하지 않았고, 컨텍스트 윈도우가 가득 찬 것도 아니며, 채팅 로그에는 여전히 존재하지만 새로운 요청이 들어올 때 에이전트가 더 이상 해당 규칙을 확인하지 않는다. 예를 들어, 프로젝트 첫날 개발자가 "API 응답에 절대 내부 데이터베이스 ID를 노출하지 마십시오"라고 명확히 지시했는데, 60회의 대화가 진행된 후 새로운 인증 흐름을 구축하라는 요청을 받았을 때 에이전트는 ID 노출 금지 규칙을 완전히 무시하고 내부 ID를 드러내는 엔드포인트를 반환한다. 이는 가상 시나리오가 아니라 저자가 실제 검증에 사용한 테스트 케이스이다.
기존 기술적 접근 방식은 이 문제를 진정으로 해결하지 못한다. 더 큰 컨텍스트 윈도우(GPT-4-32k, Claude 100k 등)는 단지 모델이 더 많은 텍스트를 담을 수 있게 해줄 뿐이며, Liu et al.(2023)의 연구는 모델이 긴 프롬프트 중간 위치의 세부 사항을 무시하는 경향이 있음을 보여준다. RAG(검색 증강 생성)는 히스토리에서 관련 정보를 찾으려 시도하지만, "현재 쿼리와 관련 있을 법한 정보는 무엇인가?"만 질문할 뿐, "이 정보가 여전히 유효한가?" 또는 "어떤 과거 의도가 현재 작업에 영향을 미쳐야 하는가?"는 묻지 않는다. 결과적으로 에이전트는 모든 규칙을 기억할 수 있지만, 어떤 규칙이 현재 시점에 여전히 적용되어야 하는지 판단할 수 없다. 실패의 핵심은 기억 용량이 아니라, 무엇이 중요한지 결정하는 능력의 결여이다.
저자는 이 문제를 해결하기 위해 "의도 연속성"(Intent Continuity) 개념을 제안하며, 이는 단순한 검색(Retrieval)이나 검증(Verification)과는 다른 차원의 능력이다. 검색은 "어떤 과거 정보가 관련 있을까?"를 묻고, 검증은 "해당 정보가 여전히 유효한가?"를 묻는 반면, 의도 연속성은 더 나아가 "어떤 과거 의도가 현재 작업에 영향을 주어야 하며, 새로운 규칙이 이를 대체할 때까지 지속적으로 적용되어야 하는가?"를 질문한다. 이 세 가지 계층은 피라미드를 형성하며, 현재 대부분의 에이전트 메모리 솔루션은 가장 아래 계층에만 머물러 있다.
아키텍처 및 구현 메커니즘
의도 연속성을 실제로 구현하기 위해 저자는 순수 Python(Python 3.12)으로 완전히 동작 가능한 시스템을 구축했다. 이 시스템은 벡터 데이터베이스, 임베딩 모델, LLM 호출을 전혀 사용하지 않는다. 핵심 아이디어는 의미적 유사성에 의존하지 않고, 가벼운 "요구사항 등록 및 검증" 파이프라인을 구축하는 것이다. 시스템은 요구사항 목록을 유지 관리하며, 새로운 작업이 들어올 때 먼저 기본 검색(키워드 매칭 또는 직접 관련 문장 검색)을 수행하여 초기 요구사항 후보 집합을 얻는다. 이 기본 검색만으로는 약 57%의 커버리지를 제공한다. 그런 다음 독립적인 검증 계층을 추가하여 각 후보 요구사항이 현재 컨텍스트에서 여전히 유효한지(예: 더 최신 규칙이 이를 대체했는지)를 확인하고, 최종적으로 실제로 준수해야 할 요구사항 목록을 선별한다. 이 검증 계층이 커버리지를 57%에서 100%로 끌어올리는 핵심이다.
구체적인 구현을 간단한 파이썬 스타일로 살펴보면 다음과 같다. 시스템은 `RequirementRegistry`라는 클래스를 중심으로 동작한다. 각 요구사항은 고유 ID, 설명 텍스트, 생성 시점, 그리고 선택적으로 대체하는 이전 요구사항의 ID를 가진다. 검색 단계에서는 간단한 키워드 기반 매칭(예: `"database ID"`라는 단어가 포함된 요구사항을 찾음)을 사용한다. 검증 단계에서는 현재 작업의 컨텍스트(예: 작업 설명, 현재 모듈 이름)를 확인하고, 요구사항에 연결된 대체 정보가 있으면 해당 요구사항이 여전히 유효한지 판단한다. 예를 들어, `"API 응답에 내부 ID를 노출하지 마십시오"`라는 규칙이 있고 이후에 `"인증 엔드포인트에서만 내부 ID를 사용할 수 있음"`이라는 새 규칙이 등록되면, 검증 계층은 인증 관련 작업이 아닌 경우 첫 번째 규칙이 여전히 유효하다고 판단한다. 이처럼 검증 계층은 규칙 간의 우선순위와 대체 관계를 관리함으로써 단순 검색보다 훨씬 정확한 결과를 제공한다.
저자는 초기 실험 설계에 버그가 있었음을 솔직하게 고백한다. 초기 버전에서는 검증 계층과 검색 계층이 부적절하게 결합되어 있어, 어떤 규칙이 이미 대체되었음에도 불구하고 잘못 유지되는 경우가 발생했다. 이로 인해 결과가 실제보다 좋아 보이는 착시가 있었다. 수정된 데이터는 더 현실적이었지만, 오히려 검증 계층의 핵심 역할을 입증해 주었다. 검증 계층이 없다면 시스템은 "과도하게 규칙을 준수"하여 불필요한 제약을 도입하게 된다. 이는 단순히 기억을 늘리는 것보다 "무엇을 기억할지"를 결정하는 메커니즘이 훨씬 중요하다는 점을 보여준다.
실측 벤치마크 및 엔지니어링 가치
저자는 8개의 대표적인 작업에 대해 대조 실험을 수행했다. 베이스라인(어떠한 히스토리 검색도 없이 현재 요청만 사용)은 정답 0개, 기본 검색만 추가했을 때 정답 4개, 그리고 완전한 의도 인식 방식(검색+검증)은 8개 작업 모두 정답을 맞췄다. 모든 데이터는 Python 3.12 환경에서 외부 의존성 없이 실제 실행을 통해 얻어졌으며, 코드는 GitHub(Emmimal/intent-continuity)에 공개되어 `run_experiment.py`로 재현 가능하다. 이 결과는 단순히 정확도 향상뿐만 아니라, 실패 모드의 성격이 달라졌다는 점에서 주목할 만하다. 기본 검색만 사용했을 때는 규칙이 전혀 적용되지 않거나(누락) 과도하게 적용되는(불필요한 제약) 두 가지 극단적인 실패가 발생했지만, 검증 계층을 추가한 후에는 규칙 적용이 컨텍스트에 적절하게 제한되어 실패가 거의 발생하지 않았다.
이 결과의 엔지니어링 가치는 극히 낮은 인프라 비용에 있다. 벡터 데이터베이스를 구축하거나, 비싼 LLM 임베딩 계산을 호출하거나, 인덱스 서비스를 유지할 필요가 전혀 없다. 순수 Python으로 작성된 가벼운 라이브러리 하나만 있으면 장기 코딩 에이전트에 규칙 연속성을 제공할 수 있다. 특히 수주에 걸친 리팩토링, 대규모 코드베이스의 히스토리 제약 추적, 팀원이 교체되면서 프롬프트가 축적되는 시나리오에서 이 접근 방식은 최소한의 비용으로 에이전트 동작의 안정성과 안전성을 크게 향상시킨다. 예를 들어, 기존 RAG 기반 솔루션을 도입하려면 임베딩 서버, 벡터 DB 클러스터, 인덱스 관리 등이 필요하지만, 이 방식은 단순한 텍스트 파일과 몇 줄의 Python 코드로 대체 가능하다. 또한 LLM 호출이 전혀 없으므로 토큰 비용이 발생하지 않으며, 지연 시간도 거의 없다.
실험에서 사용된 8개 작업은 API 설계, 데이터베이스 스키마 변경, 인증 흐름 추가, 로깅 정책 변경 등 실제 장기 프로젝트에서 자주 발생하는 시나리오를 대표한다. 각 작업에는 5~15개의 히스토리 규칙이 포함되어 있으며, 일부 규칙은 서로 충돌하거나 대체 관계에 있다. 완전한 의도 인식 방식이 모든 작업에서 100%의 정확도를 달성한 것은 단순한 실험실 환경이 아니라, 현실적인 복잡성을 반영한 테스트에서도 효과가 있음을 시사한다.
향후 전망 및 시사점
현재 업계에서 에이전트 메모리에 대한 논의는 거의 전적으로 "더 많은 히스토리를 어떻게 저장할 것인가"와 "더 빠르게 검색할 것인가"에 집중되어 있다. 이 연구는 다른 방향을 제시한다: 기억 용량을 무한히 늘리는 대신, 에이전트가 "어떤 기억이 현재 시점에 여전히 중요한지"를 판단하도록 가르치는 것이다. 의도 연속성은 본질적으로 메타인지 능력을 에이전트 아키텍처에 도입하는 것이다. 즉, 수동적으로 "모든 것을 기억"하는 것이 아니라, 능동적으로 "잊거나 상속할 것을 결정"하는 것이다.
앞으로 이 아이디어는 더욱 발전할 수 있다. 명시적인 규칙 의존성 그래프를 도입하여 규칙의 버전 관리와 자동 만료를 구현할 수 있다. 예를 들어, "2025-01-01 이후에는 이전 인증 방식 규칙을 더 이상 적용하지 않음"과 같은 시간 기반 만료 조건을 규칙에 포함시킬 수 있다. 또한 경량 검증 모델(예: 작은 규칙 기반 엔진 또는 미세 조정된 소형 언어 모델)과 통합하여 규칙 충돌 시 자동으로 우선순위를 협상하게 할 수도 있다. 이러한 진화는 대규모 LLM에 의존하지 않고도 에이전트의 의사 결정을 더욱 정교하게 만들 것이다.
장기 유지보수가 필요한 코딩 에이전트에게 의도 연속성은 어떤 거대한 컨텍스트 윈도우보다 실용적일 가능성이 높다. 이는 우리가 에이전트에 대해 다시 생각하게 만든다: 에이전트에게 필요한 것은 더 긴 히스토리가 아니라, 더 지능적인 의도 상속이다. 특히 규칙이 지속적으로 추가되고 변경되는 실제 프로젝트에서는, 단순히 모든 대화 내용을 기억하는 것보다 "언제 어떤 규칙을 적용해야 하는지"를 결정하는 능력이 훨씬 더 중요하다. 이 연구는 코딩 에이전트의 신뢰성을 한 단계 끌어올릴 수 있는 실용적이고 비용 효율적인 방향을 제시한다.
Sources
FAQ
코딩 에이전트가 장기 프로젝트에서 직면하는 핵심 문제는 무엇인가요?
장기 프로젝트에서 초기 규칙을 자주 잊어버려 데이터베이스 ID 유출 같은 심각한 문제를 일으키며, 일관성과 보안성을 해칩니다.
전통적인 해결책(큰 컨텍스트 윈도우, RAG)이 망각 문제를 완전히 해결하지 못하는 이유는?
모델이 모든 텍스트를 기억하더라도 오래된 규칙이 현재 작업에 중요한지 자동 판단하지 못합니다. 전통적 방식은 기억 용량만 확장할 뿐 능동적 검증이나 우선순위 판단이 부족합니다.
'의도 연속성(Intent Continuity)' 접근법의 핵심 아이디어와 구현 특징은?
기본 검색 + 검증 계층을 사용하며, 제로 벡터 DB, 제로 임베딩, 제로 LLM 호출로 요구사항 커버리지를 57%에서 100%로 향상시키고 8개 테스트 작업을 모두 통과했으며, 원본 실험의 버그도 투명하게 공개합니다.