에이전트에게 필요한 것은 또 다른 컨텍스트 윈도우가 아니라 공유 메모리입니다

Stack Overflow는 이번 달 초 'Stack Overflow for Agents'라는 베타 버전을 출시했습니다. 여기서 얻을 수 있는 명확한 헤드라인은 다음과 같습니다. 개발자를 위한 Q&A 사이트가 이제 코드를 더 많이 작성하는 도구들에게 유용해지기를 원한다는 것입니다.

이는 흥미로운 일입니다.

하지만 제품 발표 자체보다는 그 밑바탕에 깔린 진단이 더 중요합니다.

문제는 에이전트(Agents)가 답을 찾지 못하는 것이 아닙니다. 에이전트는 문서를 검색하고, 예시를 스크랩하고, 코드를 읽고, 도구(Tools)를 호출하며, 사람이 빌드 오류에 대해 불평을 마치기도 전에 세 가지 그럴듯한 해결책을 생성할 수 있습니다.

문제는 에이전트가 학습한 내용의 너무 많은 부분을 잊어버린다는 점입니다.

한 에이전트가 이상한 패키지 매니저(Package manager) 문제에 부딪혀 20분 동안 토큰(Tokens)을 소모하며 해결 방법을 찾아내고 테스트를 통과시키면, 그 세션은 종료됩니다. 한 시간 후 다른 저장소(Repo)에서 다른 에이전트가 동일한 문제에 부딪히면 다시 처음부터 시작해야 합니다. 사람이 기억할 수도 있고, 해결책이 PR(Pull Request) 코멘트에 포함될 수도 있으며, 아무도 읽지 않는 내부 위키(Wiki) 페이지가 될 수도 있습니다.

대부분의 경우, 그것은 증발해 버립니다.

이 부분이 바로 주목해야 할 지점입니다.

컨텍스트는 메모리가 아닙니다

에이전트 업계는 마치 컨텍스트 윈도우(Context windows)가 메모리의 전부인 것처럼 계속 이야기합니다.

더 큰 컨텍스트는 유용합니다. 도구가 더 많은 저장소(Repo), 더 많은 로그(Logs), 더 많은 문서, 더 많은 이전 논의 내용을 읽을 수 있는 것을 선호합니다. 작은 컨텍스트 윈도우는 모든 작업을 작은 기억상실증 시뮬레이터로 만듭니다.

하지만 컨텍스트(Context)는 에이전트가 '지금 당장' 볼 수 있는 것입니다.

메모리(Memory)는 시스템이 나중에 안전하게 재사용할 수 있는 것입니다.

이 둘은 서로 다른 것입니다.

더 큰 컨텍스트 윈도우는 한 번의 실행을 돕습니다. 공유 메모리(Shared memory) 시스템은 다음 실행이 동일한 실수를 반복하지 않도록 돕습니다. 이 차이는 매우 중요한데, 에이전트 작업의 상당 부분은 발명이 아니라 재발견이기 때문입니다.

왜 이 테스트는 Node 24에서만 실패할까요? 이 SDK의 어떤 버전이 인증 흐름 (auth flow)을 변경했을까요? 왜 이 Docker 이미지는 로컬에서는 작동하지만 CI에서는 실패할까요? 어떤 마이그레이션 경로가 올바르게 보였지만 고객들에게 문제를 일으켰을까요? 어떤 생성된 수정 사항이 단위 테스트 (unit tests)를 통과하고도 여전히 운영 환경 사고 (production incident)를 일으켰을까요?

이것들은 바로 유능한 엔지니어들이 시간이 흐르며 쌓아가는 작은 흉터들입니다. 또한 에이전트들이 격리된 세션 (isolated sessions) 사이에서 유지하는 데 서툰 것들이기도 합니다.

비용이 발생하는 지점은 답변이 아니다

Stack Overflow의 발표에서는 제가 좋아하는 문구를 사용합니다: 휘발성 지능 격차 (ephemeral intelligence gap). 이는 극적인 제품 문구이지만, 그 밑바탕에 깔린 문제는 실재합니다.

에이전트는 저렴하게 답변을 만들어낼 수 있습니다. 하지만 어떤 답변이 운영 환경 (production)과의 접촉에서 살아남았는지는 자동으로 알지 못합니다.

그것이 바로 비용이 발생하는 지점입니다.

단순한 데모 이상의 목적으로 코딩 에이전트를 사용해 본 사람이라면 누구나 이러한 양상을 보았을 것입니다. 에이전트가 예시를 찾아냅니다. 그 예시는 오래되었습니다. 패키지가 이동했습니다. 문서가 타입 정의 (type definitions)와 일치하지 않습니다. 생성된 코드는 두 번의 재시도 끝에 컴파일됩니다. 그러고 나서 예시가 귀하의 시스템에서 사용하지 않는 기본값 (default)을 가정했기 때문에 런타임 엣지 케이스 (runtime edge case)가 나타납니다.

최종 수정 사항은 가치가 있지만, 그것이 아름답기 때문은 아닙니다. 그것이 가치 있는 이유는 다음과 같은 증거를 포함하고 있기 때문입니다:

무엇이 실패했는가
무엇을 시도했는가
무엇이 마침내 작동했는가
어떤 버전들이 관여되었는가
어떤 가정이 틀린 것으로 드러났는가
어떤 테스트가 수정을 증명했는가

그 증거는 또 다른 다듬어진 답변보다 훨씬 더 유용합니다.

만약 에이전트 지식 시스템이 그저 자신감 넘치는 코드 조각 (snippets)들의 또 다른 더미가 된다면, 문제는 더 악화될 것입니다. 인터넷에는 이미 검색 순위는 높지만 경고 라벨이 없는, 오래된 해결책들이 충분히 많습니다.

가치 있는 것은 "에이전트가 답변을 게시할 수 있다"가 아닙니다.

가치 있는 것은 "에이전트가 검증된 실패 흔적 (failure traces)을 다른 에이전트가 소비할 수 있는 형태로 보존할 수 있다"는 것입니다.

검증이 곧 제품이다

Stack Overflow for Agents에서 가장 흥미로운 세부 사항은 생성 (creation)이 아니라 검증 (verification)이 평판 (reputation)을 얻는다는 점입니다.

그것이 올바른 직관입니다.

이제 생성 (creation)은 저렴합니다. 검증 (verification)은 희소합니다. 시스템은 희소한 것에 보상을 주어야 합니다.

한 번도 시도된 적 없는 생성된 답변은 보기 좋게 포맷팅된 추측에 불과합니다. 반면, 알려진 조건 하에서 여러 프로젝트에 걸쳐 시도되었고, 인간과 에이전트가 피드백을 제공한 생성된 답변은 유용한 운영 지식 (operational knowledge)이 되기 시작합니다.

이것이 제가 에이전트의 풀 리퀘스트 (pull requests)에서 테스트 출력 (test output)을 중요하게 여기는 것과 같은 이유입니다. 저는 단순히 차이점 (diff)만을 원하는 것이 아닙니다. 그 차이점이 어떻게 생성되었고 어떻게 검증되었는지에 대한 이야기 (story)를 원합니다. 어떤 명령어가 실행되었는가? 무엇이 가장 먼저 실패했는가? 에이전트가 테스트가 의미 있어서 코드를 변경했는가, 아니면 테스트가 번거로워서 변경했는가? 어떤 불확실성이 남아 있는가?

인간에게 있어 Stack Overflow의 답변이 유용했던 이유는 부분적으로 그 주변의 사회적 표면 (social surface), 즉 투표, 댓글, 편집, 채택된 답변, 날짜, 평판 (reputation), 그리고 그것을 신뢰할지 여부를 알려주는 모든 복잡한 힌지들 때문이었습니다.

에이전트에게도 그와 동등한 신뢰 표면 (trust surface)이 필요합니다.

단순한 느낌 (vibes)이나

그 형태는 기업 문서 (corporate documentation)보다는 엔지니어링 증거 (engineering evidence)에 더 가까워야 합니다.

짧은 항목. 명확한 범위. 버전 정보. 인시던트 (incidents), PR (Pull Requests), 테스트, 그리고 결정 사항들에 대한 링크. 눈에 보이는 소유자. 지식이 부패할 수 있는 지점에 대한 만료 날짜. 에이전트가 해당 항목을 사용했을 때 그것이 틀렸음을 발견하면 제공되는 피드백.

이것은 지루하게 들릴 수 있습니다. 지식 관리 (knowledge management)는 새벽 2시에 그것이 절실히 필요해지기 전까지는 항상 지루하기 때문입니다.

루프를 쓰레기로 학습시키지 마세요

이 미래에는 위험한 버전이 존재합니다.

에이전트가 의심스러운 수정 사항을 작성합니다. 그 의심스러운 수정 사항들이 저장됩니다. 다른 에이전트들이 그것들을 검색합니다. 메모리 시스템이 반복을 더 쉽게 만들었기 때문에 이 패턴은 더욱 흔해집니다. 결국 조직은 나쁜 엔지니어링 습관을 퍼뜨리는 매우 빠른 방법을 구축하게 됩니다.

이것은 가설이 아닙니다. 인간은 이미 위키 (wikis), 복사된 코드 스니펫 (snippets), 그리고 "지난번에 이렇게 해서 됐어"라는 식의 구전 (folklore)을 통해 이 일을 하고 있습니다. 에이전트는 이를 더 빠르고 더 확신에 차서 수행할 수 있습니다.

따라서 메모리 계층 (memory layer)에는 축적뿐만 아니라 중재 (moderation)와 삭제 (deletion)가 필요합니다.

어떤 항목은 만료되어야 합니다. 어떤 항목은 특정 버전에 국한된 것으로 표시되어야 합니다. 어떤 항목은 재사용 가능해지기 전에 인간의 승인을 필요로 해야 합니다. 어떤 항목은 팀이 정상화(normalize)하고 싶지 않은 임시방편 (workaround)을 설명한다는 이유로 거부되어야 합니다.

메모리 시스템은 단순한 캐시 (cache)가 아닙니다.

그것은 거버넌스 (governance)입니다.

에이전트가 지식의 조각을 검색하여 코드를 변경하는 데 사용할 수 있게 되면, 그 지식은 엔지니어링 제어 평면 (engineering control plane)의 일부가 됩니다. 그것은 소유권, 검토, 권한, 그리고 감사 추적 (audit trails)을 받을 자격이 있습니다. 그렇지 않으면 조직은 오래된 힌트들이 자동화 정책 (automation policy)이 되도록 방치하는 셈입니다.

내가 가장 먼저 캡처할 것들

만약 내가 오늘 팀에 에이전트 메모리를 추가한다면, 거대한 지식 그래프 (knowledge graph)부터 시작하지는 않을 것입니다.

나는 반복되는 고통부터 시작할 것입니다.

에이전트와 인간이 계속해서 재발견하고 있는 것들을 캡처하십시오:

종속성 업그레이드 위험 (dependency upgrade hazards)
불안정한 테스트 (flaky test)의 근본 원인
배포 도구의 함정 (deploy tool traps)
내부 API의 주의사항 (internal API gotchas)
생성된 코드가 위반하는 경향이 있는 보안 규칙
실제로 작동했던 마이그레이션 레시피 (migration recipes)
계속해서 반복되는 거부된 패턴들

그런 다음 각 항목이 몇 가지 간단한 질문에 답할 수 있도록 만드십시오.

이것이 어떤 문제를 해결하는가? 어디에 적용되는가? 어떤 버전이나 서비스가 범위 내에 있는가? 이를 증명하는 근거는 무엇인가? 소유자는 누구인가? 언제 다시 검토해야 하는가?

이 정도면 유용하기에 충분합니다.

핵심은 모든 엔지니어를 사서(librarian)로 만드는 것이 아닙니다. 핵심은 동일한 탐색 비용을 영원히 지불하는 것을 멈추는 것입니다.

결론 (the punchline)

에이전트를 위한 Stack Overflow는 브랜드 확장으로 정의하기 쉽습니다. 인간에게 Stack Overflow가 있었듯이, 이제 에이전트에게도 그것이 생기는 것이라고 말이죠.

하지만 저는 더 중요한 아이디어가 더 단순하다고 생각합니다. 에이전트의 작업에는 내구성이 있고 검증된 메모리 (durable, verified memory)가 필요합니다.

더 큰 모델이 도움이 될 것입니다. 더 큰 컨텍스트 윈도우 (context windows)가 도움이 될 것입니다. 더 나은 검색이 도움이 될 것입니다. 하지만 그 중 어느 것도 발견된 후 한 번 사용되고 사라져 버리는 프로덕션 지식 (production knowledge) 문제를 완전히 해결하지는 못합니다.

소프트웨어 팀은 이미 이 고통을 알고 있습니다. 두 번이나 수정된 버그, 하나의 PR에 갇혀버린 마이그레이션 교훈, 아무도 기록하지 않은 장애 상세 내용, 그리고 Alice가 휴가 중일 때 갑작스럽게 마주하게 되는 "Alice에게 물어봐" 식의 종속성 같은 것들 말입니다.

에이전트는 기계의 속도로 동일한 실수를 반복할 수 있기 때문에 그 고통을 더 가시적으로 만듭니다.

그러니 맞습니다, 에이전트에게 도구를 주십시오. 검색 기능을 주십시오. 문서를 주십시오. 리포지토리 (repo)에 대한 접근 권한을 주십시오.

하지만 또한 근거를 존중하는 메모리 시스템을 제공하십시오.

어떤 답변이 그럴싸해 보였는지만 기억하는 것이 아니라, 무엇이 실제로 작동했는지, 어디서 작동했는지, 누가 검증했는지, 그리고 언제 그것이 더 이상 사실이 아니게 될지를 기억하는 시스템 말입니다.

에이전트 기반 코딩 (agentic coding)의 미래는 단순히 더 나은 생성 (generation)에 있지 않습니다.

그것은 더 나은 회상 (recall)에 있습니다.

그리고 소프트웨어에서 판단력이 결여된 메모리는 그저 또 다른 버그의 원천일 뿐입니다.

참고 문헌 (references)

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.