서론

최근 AI Coding Agent의 진화는 눈부시다. 하지만 실제 개발 현장에서 이것들을 본격적으로 활용하려고 하면, 일종의 「답답함」에 직면하는 경우가 많았을 것이다.

조금 규모가 큰 리팩터링(Refactoring)이나 신규 기능의 기반 구현을 Agent에게 의뢰했을 때의 일을 떠올려 보길 바란다. 우리는 「다음에는 이 파일을 수정해줘」, 「그 테스트가 통과되면 다음에는 라우팅을 작성해줘」라고, 마치 신입 엔지니어 옆에 붙어서 마이크로매니지먼트(Micromanagement)를 하는 것처럼 세세하게 프롬프트(Prompt)를 계속 입력해야만 했다.

이 「Agent에게 계속 매달려야 하는 문제」에 대해 하나의 명확한 해답을 제시한 것이 바로 Claude Code에 구현된 /goal 커맨드이다.

/goal은 단순한 편리한 커맨드가 아니다. Agent를 「프롬프트에 대한 응답 머신」에서 「목표 구동형 자율 실행체」로 끌어올리는 워크플로(Workflow)의 패러다임 전환이다. 하지만 Agent가 자율적으로 계속 움직일 수 있게 되었기에, **아키텍처 레벨에서의 새로운 병목 현상(Bottleneck)**이 드러나기 시작했다.

본 기사에서는 /goal이 가져온 개발 경험의 변화를 정리하면서, Agent가 장기 태스크(Long-running tasks)나 멀티 세션(Multi-session)을 가로질러 가동될 때 직면하는 「기억과 상태 관리」의 벽에 대해 고찰한다. 그리고 그 과제를 해결하기 위한 인프라로서의 「Memory Layer(기억층)」의 필요성과, 그 구체적인 예시로서 Memorylake의 아키텍처상 위치에 대해 파헤쳐 보고자 한다.

/goal이 해결하기 시작한 것

지금까지의 Agent(예를 들어 CLI 기반 도구나 IDE 통합형 도구)는 기본적으로 「1턴의 지시에 대해 1개의 액션(코드 생성이나 커맨드 실행)을 반환한다」는 설계였다.

태스크가 길어지면 길어질수록 인간이 「현재 상태를 파악하고, 다음 단계를 정의하고, 다시 Agent를 푸시(Push)하는」 루프를 돌려야 했으며, 결과적으로 인간의 인지 부하가 전혀 줄어들지 않는다는 딜레마를 안고 있었다.

Claude Code의 /goal은 이 루프를 근본적으로 바꾼다. 「사용자 인증 기반을 Next.js와 Supabase로 구현하고 테스트를 통과할 것」과 같이 추상도가 높은 목표를 전달하면, Agent는 스스로 태스크를 분할하고, 파일을 탐색하고, 코드를 작성하며, 에러가 발생하면 자기 수정(Self-correction)을 수행하여 목표를 달성할 때까지 루프를 계속 돌린다.

이는 개발자에게 「Agent의 실행을 계속 감시하는」 저가치 작업으로부터의 해방을 의미한다. Agent는 드디어 잠시 눈을 떼어도 알아서 일을 진행해 주는 동료에 가까워졌다고 할 수 있다.

긴 태스크는 왜 지금까지 힘들었는가

그렇다면 /goal과 같은 자율 실행 기능이 있다면 Agent의 과제는 모두 해결되는 것일까? 결론부터 말하자면 그렇지 않다. 오히려 「Agent가 길게 자율적으로 움직일 수 있게 됨」으로써 새로운 통증이 현상화된다.

긴 태스크(Long-running tasks)를 Agent에게 맡길 때 우리가 직면하는 본질적인 과제는 다음과 같다.

• 컨텍스트 표류 (Context Drift)
  자율 실행 단계가 깊어질수록 Agent의 컨텍스트 윈도우(Context Window)는 「시행착오의 이력(에러 로그, 일시적인 수정 등)」으로 가득 차게 된다. 결과적으로 태스크 초기에 인간이 부여한 「중요한 아키텍처상의 제약」이나 「코딩 규약」이 노이즈에 밀려나, 후반 단계에서 무시되는 현상이 발생한다.

• 실행 중단과 재개 비용
  수 시간에 걸친 태스크 도중에 PC를 닫거나, 다른 긴급 태스크(장애 대응 등)로 브랜치를 전환해야 할 상황이 생기면 Agent의 「현재 컨텍스트」는 리셋된다. 재개 시점에 「어디까지 끝났고 다음에는 무엇을 할 예정이었는지」를 다시 입력하는 것은 인간에게 매우 고된 작업이다.

「프롬프트의 기교」로 이것들을 해결하려는 시도는 많지만, 그것은 본질적인 해결책이 되지 않는다. 왜냐하면 이것은 LLM의 이해력 문제가 아니라, 상태 관리 (State Management)의 결여라는 시스템 설계상의 문제이기 때문이다.

멀티 세션·병렬 실행에서 보이는 「다음 벽」

나아가 개발 현장을 리얼하게 상상해 보자. 우리가 소프트웨어를 만들 때, 하나의 세션(하나의 터미널 창, 혹은 하나의 채팅 스레드)에서 모든 작업이 완결되는 일은 있을 수 없다.

• 세션 A에서 데이터베이스 스키마 변경과 마이그레이션(Migration)을 수행한다.
• 세션 B에서 프론트엔드 컴포넌트를 구현한다.
• 내일은 다른 도구를 사용하여 문서를 생성한다.

인간이라면 세션 A에서 결정한 '컬럼명 변경'이라는 기억을 세션 B의 프론트엔드 구현으로 자연스럽게 이어갈 수 있다. 하지만 현재의 Agent는 기본적으로 **스테이트리스 (Stateless)**다.

여러 세션이 병렬로 실행되는 환경이나, 여러 Agent(혹은 서로 다른 도구)가 협업하는 워크플로(Workflow)에서 '실행 (Execution)'만 강화되는 것은 의미가 없다. Agent는 세션을 넘나들 때마다 기억 상실 상태가 되며, 인간은 매번 context.md와 같은 파일을 유지보수하며 계속 읽히게 만드는 수고를 해야 한다.

'자율적으로 움직일 수 있는 것'과 '지속적으로 기억을 축적·참조할 수 있는 것'은 전혀 다른 차원의 기능이다.

여기서 「Memory Layer」가 필요해진다

이 아키텍처상의 결손을 메우는 것이 바로 전용 **Memory Layer (장기 기억 인프라)**이다.

'컨텍스트 윈도우 (Context Window)를 크게 만들면 되지 않을까?'라고 생각할 수도 있지만, 그것은 RAM (메모리)을 증설하는 것과 마찬가지로 일시적인 작업 공간이 넓어질 뿐이다. 우리에게 필요한 것은 세션이 종료되어도 휘발되지 않고, 필요할 때 꺼내 쓸 수 있는 HDD/SSD와 같은 영속층(Persistence Layer)이다.

Memory Layer에 요구되는 요건은 다음과 같다.

• Persistent (영속적): 세션이나 채팅 이력이 사라져도 획득한 지식이나 제약 사항이 계속 남을 것.
• Portable (포터블): CLI, IDE 확장, 혹은 CI/CD 상의 Agent 등 서로 다른 도구 간에 기억을 공유할 수 있을 것.
• Cross-session / Cross-agent: 어제 다른 태스크에서 얻은 배움을 오늘의 태스크에 활용할 수 있을 것.

/goal에 의해 Agent의 '손과 발'이 멈추지 않게 되었기에, 이 '외부화된 뇌 (기억)'가 없다면 Agent는 그저 끊임없이 같은 실수를 반복하고, 같은 배경 정보를 요구하기만 하는 폭주 기관차가 되어버릴 것이다.

MemoryLake를 어떻게 위치시켜야 하는가

이 'Agent를 위한 기억 인프라'라는 맥락에서, 단순한 개념이 아니라 실제 아키텍처에組み込める(組み込める, 포함할 수 있는) 솔루션으로서 주목해야 할 것이 바로 MemoryLake와 같은 플랫폼이다.

MemoryLake를 단순한 '과거 채팅 로그의 저장소'나 '벡터 DB (Vector DB)의 래퍼 (Wrapper)'로 취급하는 것은 아까운 일이다. 기술적인 위치 선정으로는, **Agent Workflow에서의 크로스 세션 · 크로스 툴 컨텍스트 허브 (Context Hub)**라고 표현하는 것이 옳을 것이다.

MemoryLake를 아키텍처에 통합함으로써 다음과 같은 워크플로 개선을 기대할 수 있다.

• 배경 정보의 과도한 입력 제거
  '이 프로젝트에서는 Tailwind를 사용하지 않고 CSS Modules를 사용한다', 'DB 연결 문자열은 환경 변수에서 이렇게 가져온다'와 같은 도메인 지식이나 프로젝트 특유의 규칙을 MemoryLake에 유지시킨다. Agent는 태스크 시작 시 이곳에서 필요한 컨텍스트를 동적으로 끌어오기 때문에, 개발자가 매번 긴 프리픽스 프롬프트 (Prefix Prompt)를 작성할 필요가 없어진다.
• 크로스 세션에서의 상태 지속
  백엔드를 구축한 세션에서의 결정 사항(API 응답 형식 등)이 MemoryLake에 기록되면, 다음 날 프론트엔드를 구축하는 다른 Agent 세션이 이를 참조할 수 있다. 세션 경계를 넘는 연계가 가능해진다.
• 장문 컨텍스트로부터의 해방 (노이즈 감소)
  실행 이력 전부를 LLM의 컨텍스트에 밀어 넣는 것이 아니라, Agent가 '태스크의 페이즈(Phase)별로 얻은 중요한 결론'만을 MemoryLake에 기록하고 과거의 불필요한 로그는 폐기한다. 이를 통해 컨텍스트의 표류를 방지하고 추론 정밀도를 높게 유지할 수 있다.

즉, MemoryLake는 '일단 데이터를 던져 넣는 곳'이 아니라, Agent가 **'스스로 기억을 읽고 쓰며 다음 행동의 정밀도를 높이기 위한 기반 (Infrastructure)'**으로서 기능한다.

/goal 너머에 있는 것: 실행에서 「지속」으로

Claude Code의 /goal

Claude Code의 /goal 등장은 AI 개발에 있어 중요한 마일스톤(Milestone)이다. 이를 통해 우리는 "AI를 어떻게 움직일 것인가"라는 How의 부분으로부터 크게 해방되고 있다.

하지만 Agent의 진화는 여기서 멈추지 않는다. 앞으로의 Agent 아키텍처(Architecture) 트렌드는 틀림없이 "어떻게 잘 실행할 것인가(Execution)"에서, **"어떻게 상태와 문맥을 계속해서 유지할 것인가(Continuity / Statefulness)"**로 시프트(Shift)될 것이다.

/goal과 같은 강력한 오케스트레이션(Orchestration) 기능과 MemoryLake와 같은 견고한 Memory Layer. 이 두 가지가 결합됨으로써 비로소 AI Agent는 "단발적인 태스크를 수행하는 편리한 스크립트"에서, "프로젝트의 역사와 문맥을 이해하고 인간과 장기적으로 동행하는 소프트웨어 엔지니어"로 승화한다.

마치며

본 기사에서는 Claude Code의 신기능이 부각시킨 "장기 태스크에서의 Agent의 한계"와 이를 해결하기 위한 "기억의 아키텍처(Architecture)"에 대해 고찰하였다.

• /goal은 Agent에게 자율성을 부여하고, 개발자를 마이크로매니지먼트(Micromanagement)로부터 해방시켰다.
• 하지만 태스크가 장기화·멀티 세션화(Multi-session)되면, 이번에는 "컨텍스트(Context)의 휘발과 인계"라는 새로운 벽에 부딪힌다.
• 이를 해결하기 위해서는 프롬프트 엔지니어링(Prompt Engineering)이 아니라, 영속적이고 포터블(Portable)한 Memory Layer가 필수적이다.

만약 당신이 현재 장시간의 태스크를 수행하는 Agent 워크플로우(Workflow)를 구축하려 하거나, 여러 세션에 걸친 AI의 협업 동작에서 "AI가 금방 문맥을 잊어버린다", "매번 배경을 설명하는 것이 힘들다"와 같은 과제를 느끼고 있다면, Agent의 "실행력"뿐만 아니라 "기억의 기반"에도 눈을 돌려야 할 타이밍일지도 모른다.

그러한 차세대 아키텍처 설계에 있어, MemoryLake와 같은 기억 인프라의 도입을 평가하고 검증하는 것은 매우 이치에 맞고 가치 있는 기술적 투자가 될 것이다. AI는 이미 "자율"을 손에 넣었다. 다음에 우리가 주어야 할 것은 확실한 "기억"이다.