코딩 에이전트를 켭니다. 필요한 걸 말해줍니다. 에이전트는 리포를 검색하고, 파일 몇 개를 읽고, 잠시 생각하더니 코드를 고칩니다.

잘 됩니다.

다음 날 비슷한 걸 시킵니다. 그러면 같은 파일을 또 검색합니다. 같은 코드를 또 읽습니다. 어제 이미 대답해준 질문을 또 물어봅니다.

이게 슬슬 거슬리기 시작합니다.

여기서 메모리가 등장합니다. 다만 “그냥 메모리 붙이면 되지"로 건너뛰기 전에, 메모리가 코딩 에이전트에게 실제로 뭘 해주는지 — 그리고 언제 실제로 유용한지 — 짚어볼 가치가 있습니다.

코딩 에이전트가 하는 일

코딩 에이전트가 하는 일은 하나가 아닙니다. 새 코드를 쓰고, 기존 코드를 고치고, 테스트를 만들고, 모듈을 리팩터링하고, 버그·이슈·PR을 처리합니다. 2분짜리 작업도 있고 반나절짜리 작업도 있습니다. 범위는 제각각입니다.

하지만 일의 모양은 꽤 일정합니다.

어떻게 하는가

코딩 에이전트는 대략 이런 흐름으로 일합니다:

  • 관련 코드 검색
  • 해당 코드 읽기
  • 주변 파일과 의존성 확인
  • 코드가 하는 일 분석
  • 변경 계획
  • 변경 실행
  • 결과 검토와 검증

이게 루프입니다. 대부분의 에이전트는 턴 단위로 움직이지만, 메모리를 생각할 때 유용한 단위는 태스크입니다. 이해가 쌓이고, 쓰이고, 다음으로 이어지거나 사라지는 단위가 태스크이기 때문입니다.

메모리가 끼어드는 자리

루프의 앞쪽 절반 — 검색, 읽기, 확인, 분석 — 이 에이전트가 시간 대부분을 쓰는 ‘이해’ 구간입니다. 파일을 읽고, 의존성을 따라가고, 패턴을 파악하면서 지금 상황에 대한 내부 그림을 만듭니다.

메모리는 그 이해와 다음 태스크 사이에 있습니다.

채팅의 일부가 아닙니다. 컨텍스트 윈도우 안에 있는 것도 아닙니다. 코드와 에이전트의 작업 컨텍스트 사이에 살면서, 태스크가 끝난 뒤에도 유용한 것들을 남겨둡니다.

남겨둘 만한 것들:

  • 코드베이스에 대한 사실
  • 사용자 선호와 컨벤션
  • 이미 내려진 결정
  • 알려진 이슈와 실패 패턴
  • 유용한 절차와 워크플로

하나하나는 작지만, 태스크가 쌓이면 무시 못 할 양이 됩니다.

당연한 질문: 마크다운 문서로 하면 안 되나?

대부분의 프로젝트에는 이미 README.md, CONTRIBUTING.md, 아키텍처 문서, 컨벤션 가이드가 있습니다. 프로젝트의 안정적인 규칙은 이 파일들에 담깁니다. 사람이 읽고 관리하기 쉽고, 리포에 살면서 Git으로 버전 관리되고, 모두가 같은 버전을 봅니다.

문서가 이미 있는데 왜 굳이 메모리가 필요할까요?

문서와 메모리는 하는 일이 다르기 때문입니다.

문서는 사람 중심입니다. 팀이 합의한 사실 — 아키텍처, 컨벤션, 공용 정의 — 을 담습니다. 오래가도록 만든 것들입니다. 대신 작업 중에 바로바로 갱신하기엔 느립니다. “헬퍼 찾을 땐 src/utils/부터 봐라” 같은 걸 기록하자고 PR을 열고 싶은 사람은 없습니다.

메모리는 에이전트 중심입니다. 일하다가 발견한 태스크 수준의 작은 것들을 담습니다. 통했던 검색 경로. 지난번에 발목을 잡았던 파일 구조의 함정. 방금 배운 버그 패턴. 문서에 넣을 정도는 아니지만 다음 태스크를 위해 남겨둘 가치는 있는 것들입니다.

규칙은 문서가 들고, 일하면서 남는 쓸 만한 부산물은 메모리가 듭니다.

메모리가 없으면 잃는 것

메모리가 없으면 모든 태스크가 처음부터 시작합니다. 그 말은:

  • 같은 걸 또 설명하고, 또 설명하고
  • 이미 배운 프로젝트 규칙을 잊고
  • 예전에 말해준 선호를 놓치고
  • 이미 정리된 결정을 다시 묻고
  • 같은 코드를 읽고 또 읽고
  • 같은 통찰에 도달하려고 옛 실수를 반복하고

한 번의 태스크에서는 큰 비용이 아닙니다. 수십, 수백 태스크에 걸쳐 쌓이는 게 문제입니다. 다시 읽기, 반복된 실수, 이미 이해했던 것의 재발견 — 전부 아낄 수 있었던 시간과 컨텍스트입니다.

메모리가 돌려주는 것

메모리가 있으면 몇 가지가 달라집니다:

  • 컨텍스트와 시간이 절약됩니다. 매번 0에서 다시 시작하지 않습니다.
  • 다시 읽기와 재발견이 줄어듭니다. 어딜 봐야 하는지, 뭐가 나올지 이미 압니다.
  • 지난 통찰이 살아 있습니다. 지난주에 배운 게 오늘 쓸 수 있는 상태로 남습니다.
  • 반복 실수가 줄어듭니다. 알려진 실패 패턴이 기록되고 회수됩니다.
  • 헛걸음이 줄어듭니다. 어디를 검색하고 무엇을 고칠지, 첫 추측부터 좋아집니다.
  • 코드가 바뀌어도 전부 사라지지 않습니다. 코드가 변해도 옛 기억이 출발점이 됩니다.
  • 나중 실행이 이전 실행 위에 쌓입니다. 태스크마다 반복이 아니라 개선이 가능해집니다.

실무적으로는, 이해에 쓰는 시간이 줄고 실행에 쓰는 시간이 늘어난다는 뜻입니다. 비슷한 상황을 본 적이 있으니 첫 시도의 품질이 올라갑니다.

코드가 바뀌면 어떻게 되나

자연스러운 걱정 하나: 코드가 바뀌면 메모리가 틀린 게 되지 않나?

네, 가끔 그렇습니다. 오래된 메모리는 낡습니다.

하지만 낡은 메모리도 처음부터 시작하는 것보다는 대개 쌉니다. 에이전트가 “인증 로직은 src/auth/에 있고 JWT를 쓴다"라고 기억하는데 코드가 src/security/로 옮겨졌다면, 그 기억은 낡았습니다 — 그래도 리포 전체를 맨눈으로 뒤지는 것보다는 나은 출발점입니다.

에이전트는 코드를 다시 확인하고, 변화를 알아차리고, 메모리를 갱신해 교정본을 저장할 수 있습니다. 낡은 기억이 교정된 기억이 되는 겁니다. 다음 실행은 그 교정의 덕을 봅니다.

이게 실제 패턴입니다. 메모리는 완벽할 필요가 없습니다. 교정하는 비용이 처음부터 다시 하는 비용보다 싸기만 하면 됩니다.

팀으로 확장하면

이걸 에이전트 하나가 아니라 팀 전체로 상상해봅시다.

한 에이전트가 결제 모듈에서 버그 패턴을 발견합니다. 다른 태스크를 하던 다른 에이전트가 같은 패턴을 만납니다. 공유 메모리가 없는 세계에서는 두 번째 에이전트가 같은 디버깅을 반복합니다. 공유 메모리가 있으면 패턴을 보고, 알려진 해법을 확인하고, 하던 일로 돌아갑니다.

공유 메모리에 담길 수 있는 것:

  • 모든 에이전트가 따르는 팀 컨벤션
  • 다시 논쟁할 필요 없는 반복 결정
  • 태스크마다 반복되는 프로젝트 고유 패턴
  • 모든 에이전트가 피해야 할 알려진 함정

이쯤 되면 시스템이 챗봇 모음이 아니라 하나의 작동하는 시스템처럼 보이기 시작합니다. 에이전트들이 개별 태스크를 처리하는 데 그치지 않고, 집단으로서 유용한 지식을 쌓아갑니다.

이건 조금 먼 이야기입니다. 하지만 그 길은, 기억하는 에이전트 하나에서 시작합니다.

메모리는 에이전트를 똑똑하게 만들려고 덧붙이는 기능이 아닙니다. 같은 이해에 반복해서 돈을 내는 걸 멈추는 방법입니다.

진짜 질문은 “내 코딩 에이전트에게 메모리가 필요한가?“가 아닙니다. **“나는 지금 어떤 비용을 매번 비슷한 이해를 위해 지불하고 있는가?”**입니다.