MemoryLake
모든 글로 돌아가기
News2026년 9월 7일·13 분 소요

수십 개의 Claude 에이전트가 이미 참인 내용을 기록함으로써 페르마의 마지막 정리를 증명하다 (2026)

2026년 9월 4일, Anthropic은 컴퓨터로 검증된 최초의 완전한 페르마의 마지막 정리 증명을 발표했습니다. Claude는 "Lean 프로그래밍 언어로 증명을 작성하기 위해 11일 동안 주로 자율적으로 작동"하며, 최종 결과에 사용된 13 million 줄의 Lean과 29,500개의 중간 정리를 생성했습니다.

이 소식을 다룬 거의 모든 기사가 이 수치들을 전면에 내세웠고, 그럴 만한 가치가 있었습니다. 수학계가 수년이 걸릴 것으로 예상했던 공식화 작업이 2주도 채 걸리지 않아 끝났기 때문입니다. 하지만 Anthropic의 자체 게시물 중간에 묻혀 있는 한 문장은 수학과는 아무런 관련이 없으며, 장기 프로젝트에서 에이전트를 어떻게 운영해야 하는지와 깊은 관련이 있습니다:

"Claude의 초기 시도 중 다수는 실패했습니다. 에이전트들이 초반에는 어느 정도 성공을 거두었지만, 곧 프로젝트의 상태를 놓치고 효과적인 협업을 중단했기 때문입니다."

첫 번째 시도들은 난이도 때문에 실패한 것이 아닙니다. 기록 관리(bookkeeping) 때문에 실패했습니다. 공유된 목표를 향해 병렬로 작업하던 수십 개의 유능한 에이전트들이 이미 확립된 내용의 맥락을 놓치고 작업을 중복하거나 서로 다른 방향으로 나아가기 시작한 것입니다.

문제를 해결한 방법이야말로 연구해 볼 가치가 있습니다. 이 부분을 언급한 보도들은 이를 "에이전트 중 누구도 감당할 수 없었던 메모리를 대신하는 공유 할 일 목록" 정도로 압축하여 설명했습니다. 하지만 이는 Anthropic이 설명한 것과는 다릅니다. 그들이 전환한 스캐폴드(scaffold)는 세 가지 구체적인 작업을 수행했으며, 그중 하나만이 할 일 목록이었습니다. 나머지 두 가지는 대수적 수론(algebraic number theory)과는 거의 확실히 거리가 먼 여러분의 프로젝트를 포함하여, 장기 실행되는 모든 멀티 에이전트 작업에 직접적으로 일반화할 수 있습니다.

이 글은 바로 그 세 가지 속성에 관한 것입니다. 에이전트가 장기 프로젝트를 수행할 수 없다는 주장을 하려는 것이 아닙니다. "단지 Lean의 세 가지 표준 공리"만을 사용하여 Lean에 의해 검증된 증명이 바로 그 증거입니다. 이 글은 장기 프로젝트가 작동하기 위해 에이전트 외부에 무엇이 존재해야 했는지에 대한 것입니다. 이 문제의 일반적인 버전은 멀티 에이전트 시스템을 위한 공유 메모리 솔루션에서 다루고 있으며, 여기서는 구체적으로 Anthropic의 실행에 필요했던 부분에 초점을 맞춥니다.

Anthropic이 실제로 발표한 내용

설정: "수십 개의 Claude 에이전트가 협업하여 개념을 정의하고, 중간 정리를 증명하고, 이 정리들을 사용하여 점점 더 어려운 명제를 증명했습니다." 하네스(harness)는 Claude Code 기반이었으며, 실행 과정에서 "Claude Fable 5.1과 대략 비교할 수 있는 범용 내부 연구 모델로부터 약 six billion 개의 출력 토큰"을 소비했습니다. 인간 수학자의 개입은 최소한이었습니다. Anthropic은 다음과 같은 지시가 전부였다고 언급합니다. "Jacobian을 스키마로 다루는 것이 우선순위가 높아 보입니다", "Mazur [정리]가 곧 완료되도록 추진해 주세요."

그다음 실패와 해결책이 이어집니다. "Tianyi Peng과 Columbia University의 공동 연구자들이 설계한 수학 공식화용 개방형 협업 플랫폼인 Prove2Me를 사용하도록 전환하면서 이 작업은 성공했습니다." Anthropic은 Prove2Me가 기여한 바를 정확히 세 가지 항목으로 나열합니다:

"에이전트들이 다음에 어떤 증명을 시도해야 할지 결정하는 데 사용한 정리 명제의 방향성 비순환 그래프(DAG)를 유지했습니다. 이는 특히 메모리 저하(memory degradation)를 완화하고 여러 에이전트가 병렬로 작업할 수 있도록 하는 데 도움이 되었습니다."

"정리 명제와 증명을 서로 다른 파일로 분리하고 그 사이의 링크를 독립적으로 유지함으로써, Lean 컴파일 속도를 높이고 리소스 소비를 최소화했습니다."

"각 정리 명제에 대한 자연어 설명을 유지하여 검색 및 재사용을 가능하게 함으로써 더 단순한 증명 경로를 이끌어냈습니다."

이것들을 수학 도구의 세 가지 기능이 아니라, 저장소(store)의 세 가지 속성으로 읽어보십시오.

첫 번째는 의존성 구조를 가진 외부화(externalization with dependency structure)입니다. 무엇이 증명되었는지, 그리고 각 결과가 무엇에 의존하는지에 대한 기록이 모든 에이전트의 외부에 존재합니다. 이 방법이 해결한 문제에 대한 Anthropic의 표현은 기억해 둘 가치가 있습니다. 바로 "메모리 저하 완화(mitigating memory degradation)"입니다. "작업 조정"이 아니라, 에이전트들이 보유하고 있던 기억의 저하를 완화한 것입니다.

두 번째는 주장과 증거의 분리(separating the claim from the evidence)입니다. 명제는 한 곳에, 증명은 다른 곳에 저장되며, "그 사이의 링크는 독립적으로 유지"됩니다. Anthropic은 이로 인한 이점을 컴파일 속도와 리소스 소비 측면으로 설명하며, 이는 사실입니다. 에이전트 입장에서의 결과는 증명의 본문을 끌고 다니지 않고도 확립된 전체 명제 세트를 읽을 수 있다는 것입니다. 코퍼스가 thirteen million 줄을 넘어가더라도 인덱스를 참조하는 비용은 저렴하게 유지됩니다.

세 번째는 검색을 위한 쉬운 언어 설명(plain-language descriptions for retrieval)입니다. 모든 정리 명제에는 자연어 설명이 포함되어 있으며, 그 목적은 "검색 및 재사용 가능"입니다. 공식적인 명제는 정확하지만 검색하기에는 끔찍합니다. 반면 설명은 부정확할 수 있지만 찾기 쉽습니다. 이것이 없다면, 이미 존재하는 결과가 필요한 에이전트가 이를 찾지 못해 다시 증명하게 됩니다.

그리고 이 중 어떤 것이 가장 중요했는지를 가장 잘 보여주는 세부 정보가 있습니다. Anthropic은 전체 과정의 축소 버전을 실행했습니다. "Anthropic 연구원들은 세 개의 개인용 Claude Max 요금제를 사용하여 Hardy-Littlewood Circle Method의 적용을 공식화하는 소규모 실험을 진행했습니다. 에이전트들은 전적으로 Prove2Me를 통해 협업하여 단 3일 만에 Vinogradov's Three Primes Theorem의 공식화를 공동으로 완료했습니다." 그들의 결론은 다음과 같습니다. "우리는 적절한 스캐폴드가 있다면 개인용 AI 구독을 통한 주요 결과의 협업 공식화가 가능하다고 생각합니다."

세 개의 개인용 구독과 동일한 스캐폴드가 단 3일 만에 유명 정리를 만들어냈습니다. 스캐폴드가 많은 역할을 하고 있었던 것입니다.

이것이 바꾸는 것과 바꾸지 않는 것

이것이 에이전트가 능력을 갖추기 위해 외부 메모리가 필요하다는 것을 보여주는 것은 아닙니다. 에이전트들은 실패한 시도에서도 매우 유능했습니다. Anthropic은 그들의 실패한 작업조차도 최종 증명에서 상용구(boilerplate)가 아닌 실제 코드 라인의 상당 부분을 차지했다고 언급했습니다. 능력은 결코 병목 현상이 아니었습니다.

이것은 규모가 커질 때 가장 먼저 깨지는 것이 무엇인지를 보여주며, 그것은 추론 능력이 아닙니다. 바로 '이미 참인 것이 무엇인지 아는 것'입니다. Prove2Me의 세 가지 속성은 모두 이 질문과 관련이 있습니다. 무엇이 확립되었는가, 그것은 무엇에 의존하는가, 그리고 내가 그것을 찾을 수 있는가. 실행에 수십 명의 참여자와 thirty thousand 개의 확립된 결과가 있을 때, "우리가 이미 알고 있는 것은 무엇인가"가 지배적인 비용이 되며, 어떤 참여자도 그 답을 모두 보유할 수 없습니다.

이것이 컨텍스트 창(context window)이 무의미하다는 뜻은 아닙니다. 더 큰 창은 개별 에이전트가 세션당 더 많은 작업을 수행하는 데 도움이 됩니다. 또한 이것은 다음과 같은 규모로 확장되지 않습니다. thirteen million 줄의 Lean과 30,300개의 증명된 정리는 그 어떤 그럴듯한 크기의 컨텍스트 창 문제도 아니며, 더 중요한 것은 그것이 검색(retrieval) 솔루션이 아니라는 점입니다. 창 안에 자료가 있는 것과 그 중 어느 부분이 현재 질문을 해결하는지 아는 것은 다릅니다. 이 차이가 바로 긴 컨텍스트가 메모리가 아닌 이유에서 다루는 핵심 논쟁입니다.

그리고 이것이 모든 에이전트 메모리에 대한 주장으로 일반화된다는 의미는 아닙니다. 형식 수학(formal mathematics)은 공유 기록에 유난히 친화적인 도메인입니다. 명제는 모호하지 않고, 의존성은 명시적이며, 검증기가 참을 결정합니다. 여러분의 코드베이스에는 이러한 속성이 하나도 없습니다. 전이되는 것은 DAG가 아니라, 어디서나 유효한 세 가지 속성입니다.

사람들이 이로부터 얻을 수 있는 오해와 피해야 할 생각들

"이것은 할 일 목록이다." DAG는 "다음은 무엇인가"에 답하는 부분이며, 세 가지 중 가장 전이하기 어려운 부분입니다. 여러분의 작업은 증명 가능한 명제들의 의존성 그래프로 분해되지 않습니다. 전이 가능한 부분은 주장과 증거의 분리, 그리고 쉬운 언어 설명이며, 이 두 가지는 작업을 할당하는 것이 아니라 해결된 내용을 찾는 것에 관한 것입니다.

"그러니 우리는 그래프 데이터베이스가 필요하다." 아닙니다. 그래프가 존재하는 이유는 정리의 의존성이 실제로 그래프이기 때문입니다. 여러분에게 필요한 것은 참조 비용이 저렴하고 검색이 가능한 확립된 결론의 기록입니다. 데이터 구조는 여러분의 도메인에 따라 결정됩니다.

"이제 개인용 요금제만으로도 충분하다." Anthropic은 더 좁은 범위에서 신중하게 말했습니다. 적절한 스캐폴드가 있다면 협업 공식화가 "가능하다"는 것입니다. 이 주장은 요금제 등급이 서로 대체 가능하다는 것이 아니라, 스캐폴드가 주는 레버리지에 관한 것입니다.

"Claude에 메모리 문제가 있다." 자체 실패 사례를 발표한 기업에 대한 잘못된 해석입니다. Anthropic은 자사 제품 전반에 걸쳐 메모리 기능을 문서화하고 있으며, 이번 실행은 맞춤형 하네스 내의 내부 연구 모델을 사용했습니다. 정확한 진단은 아키텍처적인 것이며 모든 공급업체에 적용됩니다. 하나의 결과물을 두고 11일 동안 일하는 수십 개의 병렬 에이전트는 확립된 내용에 대한 공유되고 성장하는 기록을 보유할 수 없으며, 해결책은 그 기록을 모두의 외부에 두는 것입니다. Anthropic이 기꺼이 실패를 공개한 덕분에 이 발견을 활용할 수 있게 되었습니다.

해결책: 그래프가 아닌 세 가지 속성을 가진 기록 구축하기

1단계: 결론을 기록하고, 이를 도출한 작업과 분리하여 유지하기

일반적인 프로젝트에서 가장 중요한 Prove2Me의 조치는 명제와 증명을 분리하고 "그 사이의 링크를 독립적으로 유지"하는 것입니다. 엔지니어링 관점에서의 상응 조치는 결론은 한 곳에 두고, 증거는 이미 존재하는 곳에 그대로 두는 것입니다.

결론은 한 문장입니다. "조정(reconciliation) 작업은 배치 엔드포인트를 사용해서는 안 됩니다." 증거는 장애 티켓, 풀 리퀘스트, 문제를 해결한 스레드입니다. 증거를 기록에 복사하지 말고 링크로 연결하십시오. 제약 조건을 알아야 하는 에이전트는 한 문장만 읽으면 됩니다. 이유를 알아야 하는 에이전트는 한 문장을 읽은 다음 링크 하나를 따라가면 됩니다.

이것이 기록이 늘어나도 계속 사용할 수 있도록 유지하는 규율입니다. 흔히 발생하는 실패는 그 반대입니다. 저장소가 대화록과 긴 문서로 가득 차서, 해결된 답을 찾으려면 전체 논쟁을 다시 읽어야 하는 경우입니다. 그것은 아카이브일 뿐이며, 모든 것을 담은 아카이브는 아무것도 해결하지 못합니다.

2단계: 실제로 실행할 검색에 맞춰 작성된 쉬운 언어 설명을 모든 항목에 제공하기

Prove2Me는 특히 "검색 및 재사용"을 가능하게 하기 위해 각 정리 명제에 자연어 설명을 첨부했습니다. 공식 명제는 이미 존재했지만, 찾을 수 없었습니다.

여러분의 상황은 더 심각합니다. 결론이 이미 산문으로 작성되어 있어 검색이 가능할 것이라고 가정하기 때문입니다. 하지만 작성한 당일의 어휘를 사용한 산문이라면 검색되지 않습니다. "스트리밍 파서 결정"이라는 제목의 기록 항목은 6개월 후 수집 경로(ingest path)의 메모리 회귀(memory regression) 문제를 해결하려는 에이전트에 의해 검색되지 않을 것입니다.

장애 증상을 포함하여 누군가 그것을 찾기 위해 사용할 단어로 설명을 작성하십시오. "수집 경로는 배치 로더가 아닌 스트리밍 파서를 사용합니다. 배치 로더는 메모리에 전체 페이로드를 보유하여 대용량 업로드 시 OOM 재시작을 유발했기 때문입니다." 이 문장은 중복되어 보이지만, 바로 그렇기 때문에 검색이 가능해집니다.

3단계: 모든 참여자가 동일한 사본을 읽을 수 있는 곳에 두기

실패한 시도들은 각 에이전트가 자신만의 그림을 유지하고 있었기 때문에 실패했습니다. 하나의 공유된 외부 기록이 해결책이었으며, "공유"에는 나중에 추가되는 참여자와 인간도 포함되어야 합니다.

실질적으로 이는 하나의 도구에 내장된 것이 아니라 프로토콜을 통해 접근할 수 있는 하나의 저장소를 의미합니다. 기록이 한 리포지토리의 폴더에 있으면 다음 서비스의 에이전트는 이를 볼 수 없습니다. 한 에디터의 로컬 저장소에 있으면 팀원이 볼 수 없습니다. 이 두 가지 모두 좋은 기록이 조용히 개인용 기록으로 변하는 방식이며, 이는 Claude Code 에이전트 팀과 컨텍스트에서 살펴본 실패 모드입니다.

MemoryLake에서 설정하기

MemoryLake는 이 세 가지 속성을 중심으로 구축된 저장소입니다. 즉, 결론을 그 배경 자료와 분리하여 보관하고, 분류가 아닌 검색을 위해 설명하며, 프로젝트의 모든 에이전트와 사람이 하나의 인터페이스를 통해 읽을 수 있습니다. 이것은 증명 보조 도구가 아니며 형식 검증을 수행하지도 않습니다. 이는 Anthropic의 실행에 필수적이었던 레이어의 일반 작업용 버전입니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보내보십시오. 하나의 키야말로 "모든 참여자가 동일한 사본을 읽는다"는 말을 희망 사항이 아닌 현실로 만드는 열쇠입니다.

프로젝트의 모든 에이전트가 동일한 기록을 읽을 수 있도록 MemoryLake API 키 생성하기
프로젝트의 모든 에이전트가 동일한 기록을 읽을 수 있도록 MemoryLake API 키 생성하기

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

사후 분석(postmortem), 아키텍처 결정 기록(ADR), 모두가 인용하는 디자인 리뷰 등 이미 확립된 결론이 담긴 문서, 이미지, 파일을 업로드하십시오. 그런 다음 해당 문서들이 실제로 확립한 한 줄짜리 결론을 추가하여, 긴 문서를 읽지 않고도 짧은 버전을 검색할 수 있도록 하십시오.

실제로 실행할 검색에 맞춰 작성된 쉬운 언어 설명과 함께 MemoryLake에 결론 업로드하기
실제로 실행할 검색에 맞춰 작성된 쉬운 언어 설명과 함께 MemoryLake에 결론 업로드하기

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

Claude, Codex, OpenClaw 및 기타 에이전트에게 MCP 또는 API를 통해 액세스 권한을 부여하십시오. 작업 시작 시 읽고, 결정이 내려지면 결론을 다시 기록함으로써, 누구도 문서화의 날을 따로 잡지 않고도 기록을 최신 상태로 유지할 수 있습니다.

MCP 및 API를 통해 Claude Code 및 나머지 에이전트들을 MemoryLake에 연결하기
MCP 및 API를 통해 Claude Code 및 나머지 에이전트들을 MemoryLake에 연결하기

실제 업무에서 이것이 바꾸는 것

병렬 에이전트들이 작업을 중복해서 수행하지 않게 됩니다. 이는 Anthropic이 보고한 정확한 이점(DAG가 "여러 에이전트가 병렬로 작업할 수 있도록 허용함")이며, 그래프가 필요하지 않습니다. 필요한 것은 무언가를 해결하려는 에이전트가 그것이 이미 해결되었는지 확인할 수 있는 환경입니다.

장기 프로젝트의 품질 저하가 멈춥니다. "메모리 저하"는 에이전트가 많이 투입된 프로젝트의 3주 차에 일어나는 현상을 잘 설명하는 이름입니다. 공유된 이해가 희박해지고, 더 나쁜 정보를 가지고 동일한 질문이 다시 논쟁의 대상이 됩니다. 외부 기록이 모든 것을 해결해 주지는 않지만, 무엇이 결정되었는지 아무도 말할 수 없는 종류의 문제를 제거해 줍니다.

모델 변경이 리셋을 의미하지 않게 됩니다. FLT 실행은 맞춤형 하네스 내의 하나의 내부 모델을 사용했지만, 여러분의 프로젝트는 일 년에 여러 번 모델을 변경할 것입니다. 기록이 외부에 있으면 모델 변경은 축적된 지식이 아니라 속도와 비용에만 영향을 미칩니다.

그리고 참여자를 추가하는 비용이 줄어듭니다. Anthropic의 세 가지 구독 실험은 이 글에서 이를 보여주는 가장 강력한 증거입니다. 스캐폴드가 소규모 설정을 심각한 문제에서 생산적으로 만들었습니다. 실제 기록이 있는 프로젝트에 합류하는 신입 엔지니어 또는 새로운 에이전트는 한 달 동안 컨텍스트를 파악하는 대신 첫날부터 실제 업무를 수행할 수 있습니다.

장기 에이전트 프로젝트에서 공유 기록을 위한 모범 사례

결론당 한 문장. 단락이 필요하다면 그 단락은 증거이며 링크 뒤에 위치해야 합니다.

항상 이유를 첨부하십시오. 이유가 없는 결론은 규칙에 불과하며, 규칙은 무시되기 마련입니다. Anthropic의 에이전트들에게 의존성이 필요했던 이유도 마찬가지입니다. 정당화할 수 없는 결과는 안전하게 기반으로 삼을 수 없는 결과입니다.

나중에 실행할 검색에 맞춰 설명하십시오. 문제를 해결한 당일의 어휘가 아니라, 장애 증상과 문제의 어휘를 포함하십시오.

대체(supersession) 사항을 명시적으로 기록하십시오. 결정이 번복되면 그 사실과 시점을 기록하십시오. 이전 버전을 소리 없이 삭제하는 기록은 새 버전을 설명할 수 없습니다.

단일 리포지토리나 에디터 외부에 두십시오. 어느 한 곳에 로컬로 종속되는 순간 공유는 중단되며, 공유야말로 문제의 유일한 해결책이었습니다.

결론

주요 결과는 수학적인 것이며 주목받을 가치가 있습니다. 11일 만에 도출되고 Mathlib 자체의 정리 명제에 대해 Lean에 의해 검증된, 컴퓨터로 검증된 최초의 완전한 페르마의 마지막 정리 증명입니다. 성공한 순간 Claude의 생각을 발췌한 Anthropic의 기록("prove2me에서 FLT 루트가 PROVED로 표시됨")은 읽어볼 만한 놀라운 대목입니다.

운영상의 결과는 더 작고 이식성이 높습니다. 첫 번째 시도는 수십 개의 에이전트가 "프로젝트의 상태를 빠르게 놓쳤기" 때문에 실패했으며, 이를 해결한 것은 다음 세 가지 속성을 가진 외부 기록이었습니다. 결과가 결과를 바탕으로 구축될 수 있도록 하는 의존성 구조, 기록을 읽는 비용을 저렴하게 유지하기 위해 배경 증거와 분리하여 저장된 주장, 그리고 이미 확립된 내용을 다시 찾을 수 있도록 모든 항목에 제공된 쉬운 언어 설명입니다. 이후 동일한 스캐폴드를 세 개의 개인용 구독에서 실행하여 단 3일 만에 또 다른 유명 정리를 도출해 냈습니다.

이 중 어느 것도 수학에 관한 것이 아닙니다. 둘 이상의 참여자가 있는 모든 장기 프로젝트에서 제약 조건은 능력이 아니라 '이미 참인 것이 무엇인지 아는 것'이 된다는 사실에 관한 것입니다. Anthropic의 실행에는 이를 기록할 장소가 필요했습니다. 여러분의 프로젝트도 마찬가지입니다.

자주 묻는 질문

Claude가 스스로 페르마의 마지막 정리를 증명했나요?

Anthropic은 Claude가 수십 개의 에이전트와 협업하며 "11일 동안 주로 자율적으로 작동"했으며, 인간 수학자의 개입은 "가끔씩 내리는 고수준 지침으로 제한되었다"고 설명합니다. 이 증명은 Darmon, Diamond, Taylor의 Wiles 증명 단순화 버전을 따르며, Lean의 세 가지 표준 공리를 사용하여 검증되었습니다.

Prove2Me는 무엇이며 누가 만들었나요?

Anthropic은 이를 "Tianyi Peng과 Columbia University of의 공동 연구자들이 설계한 수학 공식화용 개방형 협업 플랫폼"으로 설명하며, Chen, Marwaha, Lu, Yuen, Peng의 학술 연구로 발표되었습니다. 이는 Anthropic의 제품이 아니며, 초기 시도가 실패한 후 실행 과정에서 도입되었습니다.

첫 번째 시도는 왜 실패했나요?

Anthropic의 설명에 따르면, "에이전트들이 초반에는 어느 정도 성공을 거두었지만, 곧 프로젝트의 상태를 놓치고 효과적인 협업을 중단했습니다." 실패 원인은 수학적 난이도가 아니라 조율과 공유 상태의 문제였으며, 실패한 작업 역시 최종 증명의 일부에 기여했습니다.

더 큰 컨텍스트 창이 있었다면 해결되었을까요?

본문에서는 그렇지 않음을 시사하며, 13 million 줄의 Lean과 30,000개 이상의 증명된 정리라는 규모가 이를 반증합니다. 더 중요한 것은, 컨텍스트 창은 자료를 보유할 뿐 에이전트에게 어떤 부분이 눈앞의 문제를 해결하는지 알려주지 않는다는 점입니다. 검색과 용량은 서로 다른 문제입니다.

멀티 에이전트 작업을 실행하려면 그래프가 필요하다는 뜻인가요?

아닙니다. 그래프 구조가 존재하는 이유는 정리의 의존성이 실제로 그래프이기 때문입니다. 전이되는 것은 결론과 증거의 분리, 그리고 결론을 찾을 수 있게 해주는 쉬운 언어 설명입니다. 에이전트 메모리가 실제로 효과가 있는지 여부는 타당한 선행 질문이며, 우리는 에이전트 메모리가 성능을 향상시키는가에서 그 증거를 살펴보았습니다.

세 개의 개인용 요금제 결과가 핵심 시사점인가요?

그것은 스캐폴드가 중요했다는 본문 속 가장 강력한 증거이지만, Anthropic의 주장은 신중합니다. 적절한 스캐폴드가 있다면 개인용 구독을 통한 주요 결과의 협업 공식화가 "가능하다"는 것입니다. 이는 구조가 주는 레버리지에 대한 설명이지, 요금제 등급이 동등하다는 의미가 아닙니다.