Anthropic 자체 에이전트가 테스트 선택 서비스를 과부하시켰다 — 재구축 논의는 수개월간의 단일 세션에서 진행되었다 (2026)

상황은 명확하게 기록되어 있습니다. Anthropic 엔지니어들은 "2021~2025년에 비해 분기당 8배 많은 코드를 배포"하고 있으며, "코드를 작성하는 것은 더 이상 제약 사항이 아니며, PR 리뷰가 빨라지자 CI가 압박을 받기 시작했습니다." 한편 "코드베이스 전체의 테스트 양은 10배 증가한 반면 엔지니어 수는 아주 소폭 증가했습니다." 그 결과 "우리의 CI 작업량은 6개월 동안 25배 증가했습니다."

모든 변경 사항에 대해 모든 테스트를 실행하는 대신, Anthropic은 블로그 글에서 "과거 성능과 패키지 관련성을 기반으로 각 변경 사항에 대해 어떤 테스트를 실행할지 결정하는 결정론적 테스트 영향 분석 또는 테스트 선택 서비스"라고 부르는 것을 구축했습니다. 이 서비스는 두 부분으로 나뉩니다. 하나는 "모든 CI 실행의 테스트 결과를 기록하는 '리스너(listener)'"이고, 다른 하나는 "테스트 결과 이력을 읽고 열려 있는 PR에 어떤 테스트를 실행할지 결정하는 '셀렉터(selector)'"입니다.

이 두 부분으로 구성된 디자인이 이야기의 전부입니다. 한 컴포넌트는 일어난 일을 기록합니다. 다른 컴포넌트는 기록된 내용을 읽고 결정을 내립니다. 기록하는 쪽이 현실의 속도를 따라가는 동안에는 읽는 쪽의 결정이 현실에 기반합니다. 하지만 기록하는 쪽이 뒤처지더라도 아무것도 고장 나지 않습니다. 읽는 쪽은 그저 더 이상 세상과 일치하지 않는 기록을 바탕으로 자신 있게 결정을 내릴 뿐입니다.

그리고 실제로 뒤처졌습니다. "리스너가 PR 대기열보다 점점 더 뒤처지기 시작했습니다." 그 규모는 구체적입니다. "리스너의 20분 지연은 수만 개의 테스트 업데이트가 셀렉터에 적용되지 않는 결과를 초래할 수 있습니다." 원인 또한 구체적입니다. "테스트별 실행 이력을 유지하려면 단일 라이터(writer)가 결과를 적용해야 했기 때문에 이 모든 것이 단일 프로세스로 실행되었습니다." 이로 인해 "수평적 샤딩(horizontal sharding)을 할 수 없었습니다."

그 다음 문제의 단락이 나옵니다. 장기적인 해결책을 어떻게 추진했는지 설명하며 Malhotra는 다음과 같이 씁니다. "나는 서비스 모니터링 전용으로 사용되는 Claude Tag의 내부 버전에서 장기 실행 세션을 시작했습니다." 이는 이벤트 기반이었습니다. "리스너 지연이 50,000개 이상의 작업으로 벌어질 때마다 Claude가 나에게 알림을 보내고 다음 단계에 대한 대화를 재개했습니다." 그리고 중요한 구절이 등장합니다. "이 과정은 수개월 동안 계속되었으며, 과거의 노력이나 컨텍스트를 끊임없이 상기시킬 필요가 없어서 유용했습니다."

그는 곱씹어볼 만한 문장을 하나 더 덧붙입니다. "Claude는 종종 전면적인 개편을 주장했지만, 우리는 대개 또 다른 임시 패치로 타협했습니다."

주장의 내용을 정확히 짚고 넘어갑시다. 과장하기 쉽기 때문입니다.

Anthropic은 여기서 메모리 제품을 발표하는 것이 아닙니다. 이 글은 테스트 선택에 관한 엔지니어링 회고록이며, 언급된 세션은 내부 도구의 내부 빌드에서 실행되었습니다. 다른 사람들도 이렇게 일해야 한다고 말하는 내용도 없고, 바로 켜서 사용할 수 있는 기능을 설명하는 것도 아닙니다.

Anthropic은 또한 피해를 과장하지 않도록 주의를 기울이고 있습니다. 서비스가 심하게 뒤처졌을 때, 본문은 다음과 같이 말합니다. "명확히 하자면, 이것이 해당 PR에 대해 CI가 전혀 실행되지 않았거나 테스트되지 않은 코드가 프로덕션에 배포되었다는 의미는 아닙니다." 일어난 일은 더 제한적이었습니다. 셀렉터가 "PR에서 무엇을 실행하고 무엇을 실행하지 않을지 결정하기 위해 오래된 데이터를 사용하고 있었던 것"입니다. 이는 실패에 대한 솔직하고 제한적인 설명이며, 극적으로 꾸며내기보다는 그대로 인용할 가치가 있습니다.

이 글이 확실히 보여주는 것은 직접 경험한 두 가지 사실입니다.

첫 번째는 결정을 내리는 데 수개월이 걸린 과정이 끊기지 않고 이어진 대화 덕분에 유지되었다는 점입니다. 여기서 언급된 가치는 지능이나 속도가 아닙니다. "과거의 노력이나 컨텍스트를 끊임없이 상기시킬 필요가 없었다"는 점, 즉 이미 도달했던 지점을 다시 재구성하는 비용을 줄인 것입니다. 6주 전의 스레드를 다시 열고, 왜 2주 차에 그 뻔한 답변이 거부되었는지 재구성하는 데 20분을 허비해 본 사람이라면 누구나 그 비용이 얼마나 큰지 잘 알고 있을 것입니다.

두 번째는 동일한 글에서 완전히 독립적으로, 기록된 데이터가 그 데이터를 바탕으로 내리는 결정보다 뒤처질 때 어떤 문제가 발생하는지 설명하고 있다는 점입니다. 그 지연은 눈에 보이지 않았습니다. 아무런 에러도 발생시키지 않았습니다. 그저 오래된 상태를 바탕으로 자신 있는 결정을 내렸을 뿐입니다.

이 두 가지 관찰은 서로 반대 방향을 가리키는 동일한 관찰입니다. 기록이 최신 상태를 유지하면 수개월간의 논쟁이 일관되게 유지됩니다. 기록이 뒤처지면 하위의 모든 결정이 조용히 저하되며, 아무도 그 사실을 알려주지 않습니다.

"긴 컨텍스트가 이를 해결한다." 그렇지 않으며, 이 글은 의도치 않게 그 이유를 보여줍니다. 알 수 없는 횟수의 알림을 받으며 수개월 동안 실행되는 세션은 컨텍스트 창(context window)의 문제가 아닙니다. 이는 활성화(activation) 사이에 무엇이 살아남는가의 문제입니다. 저희는 이 차이점을 긴 컨텍스트 창이 메모리가 아닌 이유에서 별도로 다루었습니다.

"그렇다면 채팅 로그에 대한 검색(retrieval)으로 해결되었을 것이다." 검색은 쿼리와 유사한 텍스트를 찾을 뿐입니다. 이 논쟁을 앞으로 나아가게 한 것은 합의된 입장(settled position)이었습니다. 즉, 전면 개편이 필요하다는 것, 세 번의 패치를 시도했다는 것, 각 패치가 벌어준 시간이 이전보다 짧았다는 사실입니다. 이는 텍스트의 한 구절이 아니라 결론이며, 대화 기록에서 이를 검색하는 것은 이를 기억하고 유지하는 것과는 완전히 다른 작업입니다. 저희는 이 경계선을 RAG가 메모리가 아닌 이유에서 설명했습니다.

"Anthropic은 에이전트가 아키텍처를 결정해야 함을 증명했다." 이 글은 완곡하게 그 반대를 말하고 있습니다. Claude는 반복해서 개편을 주장했지만 다른 우선순위를 가진 인간들에 의해 번번이 묵살되었으며, 글에서는 결국 합의에 이른 것을 엔지니어 자신의 교훈("항상 기하급수적인 성장에 대비하라")으로 묘사합니다. 세션의 기여는 권한이 아니라 연속성이었습니다.

"이것은 코딩 에이전트에 관한 이야기다." 이 메커니즘은 코드와 아무런 관련이 없습니다. 기록 레이어가 결정 레이어보다 뒤처지는 현상은, 어시스턴트에 저장된 당신의 선호도 요약본이 6월에 작성되었는데 당신이 8월에 마음을 바꿨을 때 일어나는 일과 같습니다. 에러는 나타나지 않습니다. 그저 답변이 미묘하게 틀려질 뿐입니다.

수개월간의 세션이 효과적이었던 이유는 수많은 중단 속에서도 합의된 소수의 사실을 보존했기 때문입니다. 특정 벤더의 세션이 열려 있는 상태에 의존하지 않고도 이러한 특성을 의도적으로 확보할 수 있습니다.

1단계: 실행 로그와 합의된 입장을 분리하기

여러 차례에 걸쳐 진행된 논쟁이 끝나면 두 가지 결과물이 남습니다. 하나는 길고 대부분 거절된 옵션들로 가득 찬 대화 기록(transcript)입니다. 다른 하나는 짧은 입장(position)입니다. 즉, 무엇이 결정되었고, 무엇을 시도했으며, 비용은 얼마나 들었고, 무엇이 그 결정을 바꿀 수 있는지에 대한 내용입니다.

대화 기록과 분리하여 자신의 언어로 입장을 줄글로 작성하세요. 보통 서너 문장이면 충분합니다. "더 큰 장비를 시도해 보았으나 약 70일 동안만 버텨주었습니다. 패키지별 샤딩을 시도했으나 약 한 달 동안 유지되었습니다. 일일 재시작을 시도했으나 하루 만에 한계에 도달했습니다. 다음 단계는 네 번째 패치가 아니라 재설계입니다."

이 단락이 바로 수개월간의 세션이 실제로 담고 있었던 핵심입니다. 나머지는 모두 임시 비계(scaffolding)에 불과했습니다.

2단계: 입장에 날짜를 기록하고 그것이 대체한 내용을 기록하기

Anthropic 글에 나타난 실패 모드는 기록이 알림 없이 뒤처진 것입니다. 여러분의 개인 노트도 같은 방식으로 실패합니다. 노트는 낡아가는데 여러분의 생각은 새로워지며, 그 간극을 표시해 주는 것은 아무것도 없습니다.

따라서 입장이 바뀔 때 아무 소리 없이 덮어쓰지 마십시오. 새로운 입장을 작성하고, 날짜를 기록하고, 그것이 무엇을 대체하는지 한 줄로 남겨두세요. "3월 현재, 재시작은 더 이상 해결책으로 간주되지 않음." 자신이 무엇을 대체했는지 알고 있는 저장된 사실은 검증이 가능하지만, 그렇지 않은 사실은 그저 믿을 수밖에 없습니다. 여러분의 저장소 내에서 서로 모순되는 버전들이 어떻게 해결되는지 살펴본 적이 없다면, 메모리 충돌 감지를 먼저 이해하는 것이 좋습니다.

3단계: 다음 세션이 지시받지 않고도 읽을 수 있는 곳에 두기

마지막 특성은 지속성을 부여합니다. Anthropic 세션이 작동한 이유는 알림을 보낼 때 어시스턴트가 이미 컨텍스트를 가지고 있었기 때문입니다. 새벽 2시에 지연 알림이 울렸을 때 아무도 어시스턴트에게 상황을 다시 브리핑하지 않았습니다.

기억해 내서 붙여넣어야 하는 문서가 아니라, 작업 시작 시 도구가 읽어오는 저장소에 입장을 보관함으로써 이를 재현해 보세요. 테스트는 간단합니다. 아무 어시스턴트에서나 완전히 새로운 대화를 열고 무엇이 결정되었는지 물어보세요. 먼저 설명해야 한다면 그 입장은 저장된 것이 아니라 그저 적혀 있는 것에 불과합니다. 이 차이점은 세션 간 컨텍스트 공유의 주제입니다.

MemoryLake는 다른 업체의 제품 내부로 침투하는 공간이 아니라, 모든 어시스턴트가 이미 알고 있기를 바라는 결정사항들을 위한 저장소로서 독립적이고 주소 지정이 가능한 레이어로 존재합니다. 여러분은 자신의 언어로 직접 항목을 작성합니다. Anthropic의 시스템, OpenAI의 시스템 또는 기타 다른 벤더의 저장소에서 아무것도 가져오지 않으며, 해당 벤더들이 보유한 정보를 읽거나 복원하거나 수정하지 않습니다.

1단계: API 키 생성하기

대시보드에 로그인하여 키를 생성합니다. 이 키를 통해 어시스턴트와 에이전트가 동일한 레이어에 도달할 수 있으므로, 모든 환경에서 개별 도구의 자체 이력 대신 단일화된 입장 세트를 읽을 수 있게 됩니다.

2단계: 첫 번째 메모리 업로드하기

대화 기록이 아니라 입장부터 시작하세요. 현재 업무에서 진행 중인 두세 가지 논쟁(아키텍처 관련, 프로세스 관련, 어떤 벤더로 표준화할 것인지 등)을 가져와 각각 시도한 내용과 비용을 포함하여 날짜가 적힌 짧은 단락으로 작성하십시오. 이것이 재구성하는 데 가장 오랜 시간이 걸리기 때문에 저장할 수 있는 가장 가치 있는 정보입니다.

3단계: AI 및 에이전트 연결하기

어시스턴트가 이 레이어를 가리키도록 설정하여 세션 시작 시 입장을 직접 붙여넣는 대신 자동으로 로드되도록 하십시오. 그런 다음 완전히 새로운 대화를 열고 현재 입장이 무엇인지 물어보아 검증하십시오. 답변을 제대로 읽어오는 것만이 연결이 작동한다는 유일한 증거입니다. 초록색 상태를 표시하는 패널은 증거가 될 수 없습니다.

실질적인 차이는 아무 일도 일어나지 않는 순간에 나타납니다.

수개월간의 논쟁은 수개월 동안 계속 대화하는 것을 의미하지 않습니다. 이는 100일 동안 약 15번의 실제 상호작용이 있었고, 그 사이에 몇 주간의 침묵이 있었음을 의미합니다. 이 침묵의 기간 동안 입장이 부식됩니다. 누군가 무언가를 시도했다가 실패하고 그냥 넘어가면, 지난 시도의 비용이 영구적인 곳에 기록되지 않았기 때문에 3주 후에 동일한 제안이 다시 나옵니다.

Anthropic의 글은 사람이 아닌 기계에 대해서도 동일한 점을 지적합니다. 기록이 한 시간 이상 지연되었을 때 "수많은 작업 결과가 리스너에 의해 기록되지 않았고", 셀렉터는 어쨌든 계속 결정을 내렸습니다. 아무런 경고도 울리지 않았습니다. 그저 결정의 품질이 나빠졌을 뿐입니다.

두 번째 차이는 주의력의 규모입니다. 본문은 "에이전트가 밤낮과 주말을 가리지 않고 푸시하지만, 인간 엔지니어가 여전히 상당한 양의 PR을 주도하고 승인하기 때문에 여전히 일시적으로 몰리는 경향이 있다"고 언급합니다. 활동의 하한선은 높아졌지만 인간의 시간은 늘어나지 않았습니다. 더 많은 영역에서 더 많은 작업을 감독해야 하는 경우, 재브리핑과 생각의 비율이 작업을 수행할 수 있는지 여부를 결정합니다. 이는 결국 에이전트에게 얼마나 많은 메모리를 제공해야 하는가에 대한 질문이기도 합니다.

세 번째는 감사 가능성(auditability)입니다. 재설계가 성공한 이유는 팀이 마침내 지연을 숫자로 볼 수 있었기 때문입니다. 여러분의 입장도 동일한 대우를 받아야 합니다. 처음부터 끝까지 읽으며 "이것은 최신이고, 이것은 오래되었으며, 이것은 저것과 모순된다"고 말할 수 있는 저장소가 필요합니다. 이러한 검토를 해본 적이 없다면, AI가 실제로 무엇을 기억하는지 감사하기부터 시작하는 것이 좋습니다.

다음 회의를 시작할 때가 아니라, 회의가 끝날 때 입장을 작성하세요. 옵션이 거부된 이유에 대한 컨텍스트는 거부한 직후 10분 동안이 가장 명확합니다.

줄글로 작성하세요. "샤딩 - 작동 안 함"이라는 글머리 기호는 8주만 지나도 쓸모가 없어집니다. "패키지별 샤딩을 통해 각 워커가 하나의 섹션을 소유하도록 했으나, 지연이 다시 발생하기 전까지 약 한 달 동안 유지됨"이라는 문장은 1년 후에도 여전히 유용합니다.

결과뿐만 아니라 비용도 저장하세요. Anthropic의 글이 기억에 남는 이유는 각 패치가 얼마나 오래 지속되었는지 밝히고 있기 때문입니다. "작동하지 않았다"는 재시도를 부추깁니다. "29일 동안 버텼다"는 논쟁을 종식시킵니다.

생각을 바꾸게 만들 요인을 명시하세요. 트리거가 명시된 입장은 유용한 방식으로 스스로를 무효화할 수 있습니다. 이것이 없다면 새로운 사람이 올 때마다 같은 문제를 다시 논쟁하게 됩니다.

대화 기록을 최종 기록으로 저장하지 마십시오. 대화 기록은 증거입니다. 입장이 기록입니다. 이 둘을 혼동하면 저장소는 비대해지면서 동시에 쓸모없어집니다.

정기적으로 입장을 다시 읽으십시오. Anthropic의 지연은 측정되기 전까지 보이지 않았습니다. 여러분의 지연도 마찬가지입니다.

주요 발견은 에이전트 기반 코딩이 반년 만에 Anthropic의 CI에 25배 더 많은 부하를 주었으며, 단일 라이터 서비스를 세 번 패치하는 것이 한 번 재구축하는 것보다 엔지니어링 시간을 더 비효율적으로 사용하는 일이었다는 점입니다. 참고로 그 재구축은 "단 한 명의 엔지니어가 3주 만에 완료"했습니다.

더 조용히 드러난 발견은 그 방식에 있습니다. 재구축에 대한 논쟁은 논쟁의 현 위치를 상기시킬 필요가 없는 어시스턴트와 계속해서 패치를 선택하려는 인간 사이에서 수개월에 걸쳐 진행되었습니다. 어시스턴트가 승리한 이유는 반대 의견보다 더 오랫동안 일관성을 유지했기 때문입니다.

이는 특정 도구의 기능이 아닙니다. 결론을 대화와 분리하고, 날짜를 기록하며, 다음에 여는 도구가 무엇이든 읽을 수 있도록 유지하는 특성에서 비롯됩니다. Anthropic은 우연히 종료되지 않은 세션 덕분에 이를 얻었습니다. 여러분은 이를 의도적으로 얻을 수 있습니다.