컨텍스트 엔지니어링과 작업 기억 관리

컨텍스트는 기억이 아니라 작업대다

AI 에이전트를 처음 다룰 때 흔히 하는 오해가 있다. 컨텍스트 창에 많은 정보를 넣을수록 에이전트가 더 똑똑해질 것이라고 믿는 것이다. 하지만 실제로는 반대인 경우가 많다. 너무 많은 정보는 판단을 돕기보다 판단을 흐린다.

컨텍스트 창은 무한한 기억이 아니다. 지금 작업에 필요한 재료를 잠시 올려두는 작업대에 가깝다. 작업대 위에 현재 고쳐야 할 파일, 실패한 테스트, 요구사항, 다음 행동만 놓여 있으면 일은 빠르게 진행된다. 반대로 오래된 문서, 과거 논의, 중복 설명, 이미 폐기된 설계가 함께 쌓이면 에이전트는 무엇이 최신 사실인지 구분하지 못한다.

하네스 엔지니어링에서 컨텍스트 관리는 모델에게 정보를 많이 주는 기술이 아니다. 필요한 정보를 남기고, 위험한 정보를 빼고, 작업 상태를 재개 가능한 형태로 정리하는 기술이다. 에이전트의 실패 상당수는 모델의 지능 부족이 아니라 오염된 컨텍스트와 잘못된 기억에서 시작된다.

컨텍스트 창을 예산으로 보기

컨텍스트 창은 비용이 있는 자원이다. 토큰 비용만 말하는 것이 아니다. 주의력의 비용, 충돌하는 정보의 비용, 잘못된 결정을 내릴 위험의 비용이 함께 생긴다. 그래서 좋은 하네스는 컨텍스트를 저장 공간이 아니라 예산으로 다룬다.

컨텍스트 예산을 세울 때는 먼저 무엇을 남길지 정해야 한다. 장시간 작업에서 에이전트에게 계속 제공해야 할 정보는 대체로 다음 다섯 가지다.

• 목표: 지금 해결해야 하는 문제와 완료 조건

• 진행 상황: 이미 끝낸 일과 아직 남은 일

• 핵심 파일: 실제로 읽거나 수정해야 하는 파일

• 실패한 테스트: 현재 막고 있는 검증 결과와 에러

• 다음 행동: 에이전트가 바로 실행해야 할 한두 개의 단계

이 다섯 가지에 들어가지 않는 정보는 의심해야 한다. 배경 설명은 처음에는 유용하지만, 작업 중반 이후에는 잡음이 될 수 있다. 긴 설계 철학보다 현재 실패하는 테스트 하나가 더 중요하다. 프로젝트 전체 구조보다 이번 변경에 영향을 받는 파일 목록이 더 중요하다.

컨텍스트 압축 기준은 단순해야 한다. 에이전트가 다음 행동을 결정하는 데 직접 쓰이지 않는 정보는 줄인다. 반복된 설명은 하나로 합친다. 이미 해결된 실패는 결과만 남기고 로그 전문은 제거한다. 추측은 사실과 분리한다. 이렇게 해야 컨텍스트가 길어져도 에이전트가 목표를 잃지 않는다.

낡은 정보는 최신 정보처럼 보인다

에이전트에게 컨텍스트 안의 문장은 모두 비슷한 무게로 보인다. 사람은 문서의 작성일, 팀의 분위기, 최근 회의 내용을 통해 낡은 정보를 감지한다. 하지만 에이전트는 그런 주변 감각이 약하다. 오래된 설계 메모가 컨텍스트에 들어오면, 그것을 현재 정책처럼 받아들일 수 있다.

예를 들어 저장소에 1년 전 작성된 아키텍처 문서가 있고, 실제 코드는 이미 다른 방식으로 바뀌었다고 하자. 사람이 보면 문서가 낡았다는 것을 눈치챌 수 있다. 하지만 에이전트는 문서가 자세하고 단정적으로 쓰여 있으면 그것을 강한 근거로 삼을 수 있다. 결과적으로 현재 코드와 맞지 않는 방향으로 수정하거나, 이미 제거된 API를 다시 사용하려 한다.

중복 설명도 문제다. 같은 규칙이 여러 문서에 조금씩 다르게 적혀 있으면 에이전트는 어느 쪽을 따라야 할지 흔들린다. 더 나쁜 경우, 여러 설명을 억지로 합쳐 존재하지 않는 규칙을 만들어낸다. 이것은 환각처럼 보이지만, 실제 원인은 불안정한 컨텍스트일 수 있다.

따라서 컨텍스트에는 정보의 신선도를 함께 표시해야 한다. 최신 진실은 어디에 있는지, 참고용 기록은 무엇인지, 폐기된 문서는 무엇인지 구분해야 한다. 간단한 라벨만으로도 효과가 크다.

• 현재 기준: 반드시 따라야 하는 최신 정책 또는 코드

• 참고 기록: 배경 이해에는 유용하지만 그대로 따르면 안 되는 정보

• 폐기됨: 과거 결정이며 현재 작업에는 사용하지 말아야 하는 정보

• 확인 필요: 맞을 수 있지만 실행 전에 검증해야 하는 정보

좋은 하네스는 오래된 정보를 완전히 없애는 것만 목표로 하지 않는다. 오래된 정보가 현재 사실처럼 사용되지 않도록 경계를 세운다.

압축, 리셋, 핸드오프의 차이

컨텍스트가 커졌을 때 사용할 수 있는 대표적인 방법은 세 가지다. 압축, 리셋, 구조화된 핸드오프다. 세 방법은 비슷해 보이지만 목적이 다르다.

압축은 작업 흐름이 정상이고 정보만 길어진 경우에 적합하다. 예를 들어 여러 번 테스트를 실행했고, 실패가 세 번에서 한 번으로 줄었다면 모든 로그를 보존할 필요는 없다. 현재 남은 실패와 해결된 변경만 남기면 된다.

리셋은 컨텍스트가 오염되었을 때 필요하다. 에이전트가 낡은 지시를 계속 따르거나, 이미 폐기한 접근을 반복하거나, 목표와 다른 방향으로 고집스럽게 움직이면 압축만으로는 부족하다. 이때는 이전 대화를 버리고 최신 목표, 현재 파일 상태, 검증 결과만 넣어 새로 시작하는 편이 안전하다.

핸드오프는 작업이 길어질 때 필요하다. 에이전트가 한 번에 끝내지 못하는 작업은 반드시 재개 지점이 있어야 한다. 사람 개발자가 퇴근 전에 작업 메모를 남기듯, 에이전트도 다음 실행을 위한 상태 문서를 남겨야 한다. 핸드오프는 단순 요약이 아니라 작업 재개 설명서다.

좋은 핸드오프 아티팩트에는 다음 내용이 들어간다.

• 작업 목표와 완료 조건

• 현재까지 변경한 파일

• 아직 수정하지 않은 파일

• 통과한 테스트와 실패한 테스트

• 시도했지만 버린 접근

• 다음에 해야 할 가장 작은 행동

• 주의해야 할 제약과 금지 사항

핵심은 감상이 아니라 재개 가능성이다. 다음 에이전트가 이 문서만 보고도 어디서부터 시작할지 알아야 한다.

장시간 작업에서 목표를 잃지 않게 하기

에이전트는 긴 작업에서 자주 불안정해진다. 처음에는 큰 목표를 이해하지만, 여러 파일을 읽고 테스트를 반복하면서 점점 지역적인 문제에 갇힌다. 그러다 사소한 리팩터링에 빠지거나, 아직 검증하지 않았는데 작업이 끝났다고 선언하거나, 원래 목표와 다른 문제를 해결하기 시작한다.

이 현상을 줄이려면 상태 관리가 필요하다. 상태 관리는 에이전트에게 지금 어디에 있는지 계속 알려주는 장치다. 사람에게는 체크리스트, 지도, 작업 티켓이 하는 역할이다.

가장 간단한 방법은 작업 루프마다 상태 카드를 갱신하게 하는 것이다. 상태 카드는 길 필요가 없다. 다음 항목이면 충분하다.

• 목표: 무엇을 끝내야 하는가

• 현재 단계: 조사, 수정, 테스트, 정리 중 어디인가

• 근거: 지금 판단의 근거가 되는 파일과 테스트는 무엇인가

• 막힘: 실패 또는 불확실성은 무엇인가

• 다음 행동: 바로 할 일은 무엇인가

이 상태 카드는 에이전트의 조기 마무리를 막는다. 완료 조건이 명시되어 있으면, 테스트를 실행하지 않고 끝났다고 말하기 어렵다. 남은 실패가 적혀 있으면, 실패를 무시하고 요약으로 넘어가기 어렵다.

또 하나 중요한 전략은 작업을 작은 체크포인트로 나누는 것이다. 장시간 작업을 하나의 거대한 지시로 맡기면 에이전트는 중간에 방향을 잃는다. 대신 조사 완료, 수정안 작성, 첫 테스트 실행, 실패 수정, 최종 검증처럼 단계별 관문을 둔다. 각 관문에서는 하네스가 상태를 확인하고 다음 권한을 열어준다. 이것이 컨텍스트 관리와 권한 관리가 만나는 지점이다.

파일 시스템을 작업 기억으로 사용하기

컨텍스트 창 안에 모든 것을 들고 있을 필요는 없다. 오히려 그래서는 안 된다. 장시간 작업에서는 파일 시스템을 외부 기억으로 사용해야 한다. 여기서 말하는 파일 시스템 메모리는 모델이 임의로 기억한다고 믿는 것이 아니라, 사람이 읽을 수 있고 도구가 검증할 수 있는 명시적 기록이다.

대표적인 형태는 작업 로그, 체크포인트, TODO 목록이다.

작업 로그는 시간순 기록이다. 무엇을 읽었고, 무엇을 바꾸었고, 어떤 테스트가 실패했는지 남긴다. 단, 모든 출력을 붙여 넣으면 안 된다. 로그는 감사 가능한 기록이어야지 쓰레기장이 되어서는 안 된다. 실패 로그는 핵심 에러와 재현 명령만 남긴다.

체크포인트는 되돌아갈 수 있는 지점이다. 코드 변경 전후의 상태, 통과한 테스트, 남은 위험을 함께 기록한다. 체크포인트가 있으면 에이전트가 잘못된 방향으로 갔을 때 전체 작업을 버리지 않고 안전한 지점으로 돌아올 수 있다.

TODO 목록은 다음 행동의 계약이다. 좋은 TODO는 모호한 소망이 아니라 실행 가능한 단위다. '성능 개선'은 나쁜 TODO다. '검색 결과 캐시 만료 시간을 설정 파일에서 읽도록 변경'은 좋은 TODO다. 에이전트가 바로 파일을 열고 작업할 수 있기 때문이다.

재개 가능한 형태로 관리하려면 기록의 위치도 중요하다. 프로젝트마다 정해진 작업 메모 파일을 두거나, 이슈 번호별 작업 디렉터리를 둘 수 있다. 중요한 것은 에이전트가 매번 새로 추측하지 않게 하는 것이다. 어디에 최신 상태가 있는지 정해져 있으면, 컨텍스트를 매번 길게 주입하지 않아도 된다.

컨텍스트 위생을 위한 실무 규칙

컨텍스트 엔지니어링은 거창한 기술보다 작은 습관에서 효과가 난다. 다음 규칙은 대부분의 AI 하네스에 바로 적용할 수 있다.

첫째, 컨텍스트에 넣는 정보마다 용도를 정한다. 목표를 위한 정보인지, 검증을 위한 정보인지, 참고용인지 구분한다. 용도가 없으면 넣지 않는다.

둘째, 최신 진실의 위치를 하나로 만든다. 정책은 정책 파일에, 작업 상태는 상태 파일에, 테스트 결과는 로그에 둔다. 같은 내용을 여러 곳에 흩뿌리면 에이전트는 충돌을 만든다.

셋째, 긴 대화보다 짧은 상태를 신뢰한다. 대화에는 시행착오와 폐기된 판단이 섞인다. 반면 잘 관리된 상태 문서는 현재 기준만 담을 수 있다.

넷째, 실패한 시도를 기록한다. 실패를 지우면 에이전트는 같은 길을 다시 간다. 다만 실패의 모든 세부를 남길 필요는 없다. 왜 버렸는지와 다시 시도하지 말아야 할 조건만 남기면 된다.

다섯째, 완료 조건을 계속 보이게 한다. 에이전트는 작업이 길어질수록 '그럴듯한 진전'을 '완료'로 착각할 수 있다. 완료 조건은 이 착각을 막는 기준선이다.

좋은 기억은 많이 기억하는 것이 아니다

좋은 에이전트 시스템은 모든 것을 기억하지 않는다. 필요한 것을 정확히 기억하고, 낡은 것을 의심하며, 다음 행동에 불필요한 것을 과감히 버린다. 이것이 컨텍스트 엔지니어링의 핵심이다.

컨텍스트 창은 모델의 머릿속이 아니라 하네스가 관리하는 작업 기억이다. 작업 기억이 깨끗하면 작은 모델도 안정적으로 일한다. 작업 기억이 오염되면 큰 모델도 잘못된 확신을 갖고 실패한다.

따라서 하네스 엔지니어의 역할은 정보를 더 많이 밀어 넣는 사람이 아니다. 목표, 상태, 근거, 실패, 다음 행동을 선별해 에이전트가 지금 해야 할 일을 잃지 않게 만드는 사람이다. 컨텍스트를 예산으로 보고, 기억을 구조화하고, 재개 가능한 작업 상태를 남기는 순간 에이전트는 단순한 대화 상대에서 지속적으로 일할 수 있는 작업자로 바뀐다.