거대 언어 모델(LLM)이 기억하는 것처럼 보이는 순간이 있다.

아까 말한 파일을 알고 있고, 방금 실패한 테스트를 이어서 보고, 내 프로젝트 규칙까지 계속 따라오는 것처럼 보인다.

이 연속성을 사람의 기억처럼 믿으면 긴 작업이 흔들린다.

세션, 메모리, 컨텍스트 창, 인수인계를 구분하고 다음 작업에 넣을 맥락을 남겨 보자.

독자는 긴 에이전트 작업을 새 대화로 넘길 때 빠뜨리면 안 되는 최소 항목을 가져가면 된다.

프롬프트가 컨텍스트 창과 세션, 요약, 검증 흐름으로 이어지는 구조.

먼저 네 단어를 이렇게 나눈다.

  • 세션(session): 이어지는 대화 단위다. 기억 자체가 아니라는 점을 조심해야 한다.
  • 메모리(memory): 따로 저장해 다시 불러오는 정보다. 모든 대화가 자동 저장되지는 않는다.
  • 컨텍스트 창(context window): 이번 답이 볼 수 있는 입력 한도다. 길면 선택과 요약이 필요하다.
  • 인수인계(handoff): 다음 작업자가 볼 현재 상태다. 전체 대화 복사가 아니다.

세션은 마법 같은 기억 상자가 아니다. 프롬프트와 이전 대화, 파일, 실행 결과, 요약이 다시 들어오고, 그 안에서 모델이 다음 답을 만든다.

LLM은 한 번에 보이는 것 안에서 답한다

대화형 AI를 처음 쓰면 이런 느낌을 받기 쉽다.

아까 말한 걸 기억하네.
이 저장소 규칙도 계속 알고 있네.
내 말투도 어느 정도 따라오네.

느낌 자체는 틀리지 않다. 사용자는 연속된 대화를 보고 있고, 제품도 그렇게 보이게 만든다. 하지만 AI는 지금 보이는 입력을 기준으로 다음 답을 만든다.

AI가 계속 기억하는 것처럼 보여도, 실제 작업에서는 매번 필요한 재료를 다시 보여줘야 한다고 보는 편이 안전하다. 이전 대화, 실행 결과, 파일 내용이 다음 판단에 들어가지 않으면 AI는 그것을 기준으로 삼을 수 없다.

프로그램 연결 방식(API)에서도 대화를 이어가려면 이전 메시지나 도구 실행 결과를 다시 포함하거나, 별도의 상태 관리 방식을 써야 한다.

그래서 “기억한다”는 말은 작업 설명으로는 조금 위험하다. 실제로는 세션이 이전 내용을 다시 보여준다.

이 차이는 작아 보이지만, 긴 작업에서는 크다. 이전에 말한 조건이 다음 요청에 들어오지 않으면 모델은 그것을 볼 수 없다. 들어오더라도 너무 많은 내용에 묻히면 중요도가 떨어진다. 요약 과정에서 빠지면 다시 사라진다.

컨텍스트 창은 작업대 크기다

컨텍스트 창은 모델이 한 번에 펼쳐두는 작업대 크기다. 토큰은 한 글자 단위가 아니라 모델이 텍스트를 나눠 읽는 조각이다.

쉽게 말하면 “모델이 이번 답을 만들 때 책상 위에 펼쳐두는 총량”이다.

작업대가 크면 긴 문서, 긴 대화, 여러 파일을 더 많이 올린다. 하지만 무한하지는 않다.

예를 들어 로그인 버그 하나를 고친다고 해보자.

사용자 요청
저장소 규칙
관련 파일
실패한 테스트 로그
원인 후보
수정한 코드
리뷰 코멘트
수정 로그
테스트 결과
배포 전 확인

이 모든 것이 대화에 계속 쌓이면 처음에는 든든하다. 그런데 어느 순간부터는 오히려 방해가 된다. 중요한 결정과 오래된 로그가 섞이고, 이미 해결한 오류가 계속 보이며, 새로 바뀐 기준보다 예전 기준이 더 크게 남기도 한다.

이걸 나는 세션이 길어질 때 생기는 피로로 본다. 모델의 피로가 아니라 사용자가 보여주는 작업대의 혼잡함이다.

세션은 이어진 작업처럼 보이게 하는 껍질이다

세션은 사용자가 느끼는 연속성의 단위다.

코딩 에이전트도 긴 작업을 할 때는 지금까지의 대화, 실행 결과, 바뀐 파일, 남은 일을 계속 정리해 가며 다음 답을 만든다.

하지만 이 정리는 완벽한 기억이 아니다. 중요한 조건이 빠지고, 오래된 판단이 남고, 이미 해결한 오류가 계속 눈에 띄기도 한다.

이 설명을 작업 기준으로 풀면 이렇다.

모델은 매번 현재 보이는 재료로 답한다.
세션은 그 재료를 모으고, 줄이고, 다시 넣어주는 운영 층이다.

그래서 세션은 메모리처럼 느껴지지만, 실제로는 선택과 요약의 결과다.

중요한 말이 대화에 한 번 나왔다고 해서 영원히 안전하지 않다. 다음 답에서 다시 보이거나 요약되거나, 너무 오래되어 밀려난다. 반대로 중요하지 않은 로그가 계속 남으면 모델이 그쪽을 더 크게 보기도 한다.

긴 에이전트 작업에서 인수인계가 중요한 이유가 여기 있다. 인수인계는 “지금까지 있었던 모든 말”을 보존하는 문서가 아니다. 다음 판단에 꼭 필요한 사실, 결정, 남은 일, 검증 결과만 남기는 짧은 약속이다.

기억처럼 믿을 때 생기는 실패

세션이 기억처럼 느껴지는 이유는 있다. 이전 대화가 다음 요청에 다시 들어오고, 제품이나 API가 상태를 이어주고, 긴 대화는 요약으로 압축된다.

흔들림은 이 연속성을 사람의 기억처럼 믿을 때 생긴다.

첫째, 중요한 조건을 채팅에만 둔다.

예를 들어 이런 조건이 있다.

  • 삭제 명령은 실행 전에 한 번 더 확인한다.
  • 배포는 테스트가 통과한 뒤에만 한다.
  • 고객 문서 요약에서는 이름, 이메일, 내부 링크를 그대로 공개하지 않는다.
  • 새 글이나 문서는 처음에는 비공개 초안으로 둔다.

이런 조건을 매번 대화에만 쓰면 어느 순간 빠진다. 반복 조건은 규칙 파일이나 프로젝트 문서로 옮기는 편이 낫다.

둘째, 오래된 판단이 계속 살아남는다.

처음에는 “이미지는 나중에”라고 했지만, 나중에는 공개 발행으로 바뀌기도 한다. 초반의 판단이 계속 대화 안에 남아 있으면 모델이 최신 목표와 예전 제약을 섞는다. 이때 메인 대화에서 “현재 승인된 목표”를 다시 고정해야 한다.

셋째, 로그가 근거처럼 보인다.

명령 출력, 실패 로그, 중간 추측이 길게 남아 있으면 나중에 사실처럼 읽힌다. 하지만 로그는 판단의 재료이지 결론이 아니다. 검증을 통과했는지, 어떤 수정이 실제로 반영됐는지, 무엇은 아직 확인하지 않았는지 따로 정리해야 한다.

넷째, 긴 대화 요약을 백업으로 착각한다.

긴 대화 요약은 계속 일하도록 내용을 줄여 다시 넣는 과정이다. 하지만 사람이 의도한 모든 세부사항을 영구 보존하는 백업은 아니다. 중요한 상태는 작업 기록, 인수인계, 이슈(issue), 커밋 메시지(commit message), 문서처럼 나중에도 다시 보는 기록으로 남겨야 한다.

긴 작업에서는 현재 상태를 다시 넣는다

나는 긴 에이전트 작업을 할 때 목표를 먼저 짧게 둔다.

실패한 로그인 버그를 다시 잡는다. 지금까지 확인한 원인 후보, 수정한 파일, 남은 로그, 재현 명령을 기준으로 이어서 본다.

이 정도면 모델이 끝났는지 판단할 수 있다. “좋게 써줘”보다 훨씬 낫다.

그다음에는 보조 에이전트나 긴 검수 결과를 원문보다 인수인계로 남긴다. 인수인계는 다음 사람이 바로 이어받도록 남기는 짧은 기록이다.

좋은 인수인계는 길지 않다.

완료: 무엇을 확인했는가
변경: 무엇이 바뀌었는가
위험: 무엇이 아직 위험한가
다음: 다음에 할 가장 작은 행동은 무엇인가
증거: 어떤 명령이나 파일이 증거인가

이 정도면 다음 에이전트나 미래의 내가 다시 시작하기 쉽다. 모든 생각 과정을 붙여넣는 것보다 낫다.

세션이 길어졌다고 느끼면 새 세션을 피하지 않는다.

새 세션은 실패가 아니다. 목표, 현재 상태, 변경 파일, 검증 결과, 남은 일을 잘 적은 인수인계가 있으면 새 세션이 오히려 더 정확할 때가 있다. 반대로 인수인계 없이 긴 세션을 계속 밀면 오래된 맥락과 새 목표가 섞인다.

핵심은 세션을 아끼는 것이 아니다. 다음 판단에 필요한 맥락만 보이게 하는 것이다.

다음 세션이 읽을 수 있게 남긴다

다음 세션을 열 때 내가 보고 싶은 것은 대화 전체가 아니다.

현재 목표, 결정한 내용, 바꾼 파일, 실패한 명령, 다시 확인해야 할 증거가 먼저 보여야 한다.

그 정도만 정확히 남아 있으면 긴 대화를 붙잡지 않아도 된다. 다음 답변에 필요한 맥락은 작고 분명한 쪽이 낫다.

내가 마지막에 남기는 최소 템플릿은 이 정도다.

목표:
현재 결정:
변경 또는 확인:
남은 위험:
다음 행동:
증거:

각 칸은 한 줄이면 충분하다. 길게 설명하기보다 다음 세션이 바로 판단할 사실만 남긴다.

시리즈 연결

참고한 문서