Augment의 Cosmos Experts가 사용자의 피드백으로부터 학습하는 방식을 제어하는 방법 (2026 가이드)

기본적으로 켜져 있으며, 다른 사람이 선택한 스코프로 설정되어 있습니다

메모리는 "Expert가 세션 간에 유용한 컨텍스트를 유지할 수 있도록" 하며, "공유 가상 파일 시스템(VFS)에 스코프가 지정된 지식을 저장하므로, 향후 세션에서 현재 대화에 의존하지 않고도 기존에 확립된 선호도, 컨벤션 및 교훈을 적용할 수 있습니다."

첫 번째 불일치는 바로 '스코프(Scope)'에서 발생합니다. "Expert의 메모리는 해당 팀에 속하며 워크플로우에 적합한 스코프로 분리됩니다. 리포지토리 기반 Expert는 일반적으로 리포지토리당 하나의 스코프를 사용하는 반면, 다른 Expert는 글로벌, 채널, 프로젝트 또는 사용자별 스코프를 사용할 수 있습니다."

다섯 가지 가능한 스코프가 있으며, 기본값은 템플릿에 맞는 것으로 설정됩니다. 리포지토리별로 설정되어야 할 Expert가 글로벌로 설정되면, 한 팀의 컨벤션을 학습하여 모든 곳에 적용해 버립니다. 반대로 글로벌이어야 할 Expert가 리포지토리별로 설정되면 모든 리포지토리에서 동일한 내용을 매번 다시 학습해야 합니다.

두 가지 쓰기 경로, 그리고 오직 하나만 기다립니다

이 메커니즘은 제대로 이해할 가치가 있습니다. 왜냐하면 무심코 던진 한마디가 이후의 모든 것에 어떻게 영향을 미치는지 결정하기 때문입니다.

"Simple memory가 기본값입니다. 이는 명시적이고 고품질인 인간의 피드백을 큐레이션된 지식 파일에 직접 기록합니다. 이는 그 자체로 권위가 있는 선호도나 고정된 규칙에 잘 맞습니다."

"Noisy memory는 증거 로그와 큐레이션된 지식 파일을 함께 사용합니다. 시간이 지나면서 약한 신호들을 결합하고, 증거가 충분히 강력해진 후에만 학습 내용을 반영합니다."

그리고 외부에서는 이 둘을 구분할 수 없는 이유를 설명하는 대목이 있습니다. "두 모델 모두 독자에게 동일한 큐레이션된 지식 뷰를 노출합니다. 차이점은 그 뷰가 생성되는 방식입니다. Simple memory는 신뢰할 수 있는 사실을 직접 기록하는 반면, Noisy memory는 향후 세션에 제시하기 전에 반복된 증거를 정제합니다."

따라서 겉보기에 똑같아 보이는 지식 파일이라도, 어떤 것은 단 하나의 댓글에 기반한 것일 수 있고, 어떤 것은 12개의 뒷받침하는 증거에 기반한 것일 수 있습니다. Expert가 왜 특정 사실을 믿고 있는지 디버깅할 때 가장 먼저 확인해야 할 부분입니다.

사용자의 모든 행동이 동일한 강도의 신호는 아닙니다

Code Review Memory는 Noisy 모델을 실행하며, 그 문서에서는 가중치에 대해 이례적으로 구체적으로 설명합니다. "명시적인 인간의 피드백은 반응(reaction)이나 추론된 결과보다 더 큰 가중치를 가지므로, 강력한 피드백은 즉시 유용한 메모리가 될 수 있는 반면, 약한 신호는 반복되어야 합니다."

사실상 세 가지 단계가 있는 셈입니다. 작성된 댓글은 즉시 반영될 수 있습니다. 에이전트의 발견 사항에 대한 반응이나 변경 사항이 머지되었다는 사실은 반복이 필요합니다. 시스템은 또한 필터링을 수행합니다. "일상적인 감사 인사, 봇 업데이트, 프로세스 전용 댓글은 필터링되어 제외됩니다."

이는 합리적인 설계입니다. 하지만 동시에 무심코 던진 "네, 좋아요" 같은 말이 중립적이지 않다는 뜻이기도 합니다. 이는 약한 신호로 기록되며, 이러한 신호가 쌓이면 결국 반영됩니다.

사용자에게 알려주지만, 대부분은 보지 않습니다

거부(veto) 단계가 있지만 놓치기 쉽습니다. "대화형 세션에서는 무언가를 기억할 때 사용자에게 알려주어 수정하거나 거부할 수 있도록 합니다."

여기서 핵심 단어는 대화형(interactive)입니다. 백그라운드 Expert(그리고 Code Review Memory는 명시적으로 "백그라운드 Template Expert"입니다)는 풀 리퀘스트가 머지될 때 캡처를 수행하므로, 그 과정에서 이의를 제기할 사람이 아무도 없습니다.

갈등을 해결하기보다 표면화합니다

읽기 경로에서: "관련 작업이 시작될 때, Expert는 현재 스코프에 대한 메모리를 로드합니다. 일치하는 가이드를 적용하고, 현재 증거가 기억된 규칙과 충돌할 때 불일치를 표시합니다."

오래된 규칙을 묵묵히 적용하는 것보다 불일치를 표시하는 것이 낫지만, 그것이 문제를 해결하는 것과 같지는 않습니다. 누군가 편집할 때까지 오래된 항목은 그대로 유지되며, 이는 detecting conflicts in AI memory에서 다루는 일반적인 문제입니다.

메모리 끄기. 가능합니다. Advisor에게 메모리를 연결하지 않도록 지시할 수 있습니다. 하지만 이는 노이즈가 있는 부분과 함께 유용한 부분까지 모두 버리는 결과를 낳습니다. 진행 중인 작업에서 얻는 학습은 지침(instructions)만으로는 결코 담아낼 수 없는 영역입니다.

대신 모든 것을 Expert의 지침에 넣기. Augment는 이에 대해 직접적으로 언급합니다. "명시적인 워크플로우에는 스킬이나 Expert 지침을 사용하고, 진행 중인 작업을 통해 학습된 컨텍스트에는 메모리를 사용하십시오." 또한 리뷰 측면에서는 다음과 같이 설명합니다. "Code Review Memory는 모든 리포지토리에 대해 스킬을 생성하는 것과 다릅니다. 스킬은 명시적이고 재사용 가능한 지침과 워크플로우를 제공합니다. 메모리는 리뷰 Expert가 리뷰 중인 리포지토리에 대해 자동으로 로드하는, 진화하고 증거에 기반한 컨텍스트입니다." 이 두 가지는 서로 다른 작업이며, 하나의 메커니즘으로 두 가지를 모두 강제하려고 하면 둘 다 제대로 작동하지 않게 됩니다.

모든 곳에서 사용할 수 있도록 가장 넓은 스코프 사용하기. 공식 가이드는 정반대입니다. "코드 리뷰를 위한 리포지토리나 피드백 분류를 위한 채널과 같이 워크플로우와 일치하는 가장 좁고 안정적인 스코프를 사용하십시오." 스코프가 넓다고 해서 Expert가 더 많은 정보를 얻는 것은 아닙니다. 오히려 검색(retrieval) 시 노이즈만 늘어날 뿐입니다.

더 엄격해 보인다는 이유로 모든 것을 Noisy memory로 전환하기. 이 역시 문서 내용과 상반됩니다. "워크플로우에 반복적이고 가중치가 부여된 증거가 진정으로 필요한 경우가 아니라면 Simple memory를 선호하십시오." Noisy memory는 설계상 학습을 지연시킵니다. 사용자의 피드백이 절대적인 워크플로우에서 이러한 지연은 순전한 손실일 뿐입니다.

기억된 내용을 확정된 것으로 취급하기. "메모리를 의심할 여지 없는 규칙이 아니라 진화하는 컨텍스트로 취급하십시오. Expert는 현재 증거를 무시하기보다 모순을 표면화해야 합니다." 메모리는 이력이 있는 주장일 뿐 결정이 아닙니다. 이것이 바로 memory provenance의 핵심 차이점입니다.

다른 팀의 Expert가 이를 알아서 학습할 것이라고 가정하기. 그렇지 않습니다. "각 Expert 팀은 다른 팀의 큐레이션된 지식을 수정하는 대신 자체 메모리를 소유하고 유지 관리합니다." 소유권은 우회해야 할 불편함이 아니라 명확한 경계입니다.

1단계: 각 Expert에 대해 가장 좁고 안정적인 스코프 선택하기

보유하고 있는 Expert들을 살펴보고, 각 Expert의 작업을 여전히 커버할 수 있는 가장 작은 스코프가 무엇인지 적어보세요. Augment의 표현에서 안정적인(stable)이라는 단어는 매우 중요한 역할을 합니다. 목표는 상상할 수 있는 가장 좁은 스코프가 아니라, 다음 달에 다시 넓힐 필요가 없는 가장 좁은 스코프를 찾는 것입니다.

공식 문서의 예시가 가장 좋은 직관을 제공합니다. "코드 리뷰를 위한 리포지토리나 피드백 분류를 위한 채널." 하나의 리포지토리에서 작업하는 리뷰 Expert는 글로벌 스코프가 필요하지 않습니다. 하나의 채널을 모니터링하는 분류 Expert는 프로젝트 스코프가 필요하지 않습니다.

두 가지 질문으로 대부분의 사례를 해결할 수 있습니다. 여기서 학습한 지식이 다른 곳에서는 틀린 내용이 될 수 있나요? 그렇다면 스코프를 좁히세요. 다른 세 곳에서 이와 동일한 내용을 다시 가르쳐야 하나요? 그렇다면 그 지식은 특정 Expert에 국한된 것이 아니라는 신호입니다. 이 생각은 3단계에서 다시 다루겠습니다.

스코프와 함께 이동하므로 이 단계에서 가시성(visibility)도 정리하세요. "메모리는 Expert의 가시성에 따라 조직과 공유되거나 사용자의 VFS 내에 유지될 수 있습니다."

2단계: 신호의 신뢰도에 맞게 메모리 모델 매칭하기

Expert당 하나의 질문을 던져보세요. 이 Expert가 받는 피드백은 그 자체로 권위가 있는가?

사람이 직접 수정을 입력하고 그 수정 사항이 명백히 맞다면, Simple memory를 사용하세요. 이미 결정된 선호도, 고정된 규칙, 컨벤션 등이 이에 해당합니다. 이는 "명시적이고 고품질인 인간의 피드백을 큐레이션된 지식 파일에 직접 기록"하며, 즉각성이 가장 큰 특징입니다.

만약 반응, 머지 결과, 추론, 다양한 진지함의 댓글 등 신호가 혼재되어 있다면, Noisy memory를 사용하고 증거 로그가 제 역할을 하도록 하세요. Code Review Memory가 대표적인 사례이며, 그 이유는 다음과 같이 명시되어 있습니다. "리뷰 댓글, 반응, 에이전트 관찰 및 변경 결과는 서로 다른 수준의 신뢰도를 가집니다."

그런 다음 메커니즘이 아닌 볼륨에 관한 두 번째 공식 필터를 적용하세요. "향후 결정이나 집중 분야를 바꿀 수 있는 정보만 저장하십시오." 모든 것을 기록하는 Expert는 아무도 읽지 않는 지식 파일을 만들어내고, 아무도 읽지 않는 지식 파일은 오래된 항목들이 방치되는 곳이 됩니다.

특히 리뷰 경로의 경우, 리뷰 시 의도적으로 대처할 수 있도록 무엇이 모니터링되는지 파악해 두세요. 이는 "유용한 인간의 댓글, 에이전트 발견 사항에 대한 반응, 해결된 변경 요청 및 변경 결과를 기록"합니다. 에이전트 발견 사항에 대한 사용자의 반응은 학습 데이터입니다. 그렇게 취급하십시오.

3단계: 지식 파일 읽기, 그리고 Expert 전용이 아닌 사실들 이동하기

두 가지 습관이 필요하며, 두 번째 습관이 구조적인 해결책입니다.

첫째, 실제로 읽어보세요. 메모리는 "자체 VFS 디렉토리 아래에 읽기 쉬운 Markdown으로 기록"되며, 리뷰 측면에서는 저장소 분리가 명확합니다. "원시 브레드크럼 로그(breadcrumb log)는 리뷰에서 수집된 증거를 보존하는 반면, 큐레이션된 지식 파일은 리뷰 Expert가 사용하는 간결한 가이드를 포함합니다." Expert가 무엇을 믿고 있는지 보려면 큐레이션된 파일을 읽고, 그 이유를 알고 싶다면 브레드크럼 로그를 읽으세요. 한 달에 한 번이면 충분하니 일정을 잡으세요. 백그라운드 Expert는 대화형 거부 단계 없이 캡처를 수행하므로, 이것이 유일한 검토 방법입니다.

둘째, 여러 Expert의 파일에 반복해서 나타나는 내용이 무엇인지 주목하세요. 아키텍처 결정 사항, 도메인 용어, 어떤 서비스가 무엇을 소유하는지, 더 이상 사용되지 않는(deprecated) 기능이 왜 여전히 존재하는지 등이 이에 해당합니다. 이러한 지식은 특정 역할이 자체 작업을 통해 학습한 것이 아니라 조직 전체가 알고 있는 지식입니다. Expert별로 스코프를 지정하면 모든 Expert가 이를 개별적으로 학습하거나 잘못 이해하게 됩니다.

Augment의 스코프 지정 권장 사항은 해당 지식에 대해서는 올바르지만, 진정으로 공유되는 지식에 대한 답은 제공하지 못합니다. 이는 어떤 Expert도 소유하지 않는 레이어에 속해야 합니다. MemoryLake는 세 단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인하고 대시보드에서 API 키를 생성합니다. 이는 특정 Expert, 팀 또는 리포지토리에 종속되지 않으므로, 어떤 Expert가 묻든 상관없이 참인 사실들을 다루기에 적합한 특성을 가집니다.

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

여러 Expert 파일에서 반복되는 내용을 입력하세요. 아키텍처 결정과 그 이유, 도메인 용어, 서비스 소유권, 고정 제약 조건, 리뷰에서 계속 반복하는 답변 등이 포함됩니다.

작업을 통해 학습된 자료는 그대로 두세요. 특정 리포지토리에서 더 이상 표시하지 않도록 설정한 오탐(false positive)에 대한 Expert의 기록은 해당 리포지토리 스코프에 그대로 유지되는 것이 맞습니다.

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

에이전트가 이 저장소를 바라보도록 설정하세요. 새로운 Expert는 제로 베이스가 아니라 조직의 공통 사실에서 시작하게 되며, 공유된 사실에 대한 수정은 Expert마다 한 번씩이 아니라 단 한 번만 반영하면 됩니다. 이것이 바로 팀을 위한 공유 AI 메모리 설정의 핵심입니다.

첫 번째 변화는 좁은 스코프를 지정하더라도 커버리지를 희생하지 않게 된다는 점입니다. 현재로서는 Expert의 스코프를 좁히면 조직에 대해 아는 것이 적어집니다. 하지만 공유된 사실이 다른 곳에서 제공되면, 좁은 스코프는 단지 더 깔끔한 이력을 의미할 뿐입니다.

두 번째는 모델 선택이 쉬워진다는 점입니다. 권위 있는 피드백에는 Simple을, 혼재된 신호에는 Noisy를 사용하면 됩니다. 두 모델 모두 배경 지식까지 짊어질 필요가 없으므로, 사람들이 넓은 스코프를 선택하고 과도하게 저장하게 만들었던 원인이 해결됩니다.

세 번째는 검토 습관을 실제로 실천할 수 있게 된다는 점입니다. Expert가 진정으로 학습한 내용으로만 제한된 큐레이션 파일은 매달 읽기에 충분히 짧습니다. 이는 AI가 기억하는 내용 감사하기를 실제로 실행하는 것과 마음만 먹는 것의 차이입니다.

• 이미 켜져 있다고 가정하십시오. 모든 Template Experts에 이 기능이 있으며, Advisor는 기본적으로 커스텀 Expert에 이를 추가합니다.
• 가장 좁고 안정적인 스코프를 사용하십시오. 코드 리뷰를 위한 리포지토리, 분류를 위한 채널 등 Augment의 자체 예시를 따르세요.
• Simple memory를 선호하십시오. 신뢰도가 진정으로 다양한 신호일 때만 Noisy로 전환하세요.
• 향후 결정을 바꿀 수 있는 내용만 저장하십시오. 공식적인 볼륨 필터이자 파일을 읽기 쉽게 유지하는 방법입니다.
• 리뷰 시 사용자의 반응을 주의 깊게 살피십시오. 댓글, 반응, 해결된 요청, 결과가 모두 서로 다른 가중치로 캡처됩니다.
• 백그라운드 작업에서 거부 단계를 기대하지 마십시오. 이는 대화형 세션에서만 나타나며, Code Review Memory는 백그라운드에서 실행됩니다.
• 큐레이션 파일은 매달 읽고, 의아한 점이 있을 때는 브레드크럼 로그를 읽으십시오. 하나는 결론을 보여주고, 다른 하나는 증거를 보여줍니다.
• 소유권 경계를 존중하십시오. 각 Expert 팀은 자체 메모리를 유지 관리하며 다른 팀의 메모리를 편집하지 않습니다.

Augment는 대부분의 도구가 노출하는 것보다 에이전트 메모리에 대해 훨씬 더 많은 제어권을 제공합니다. 다섯 가지 스코프, 완전히 다른 의미론을 가진 두 가지 쓰기 모델, 문서화된 신호 계층 구조, 그리고 직접 검사할 수 있는 읽기 쉬운 파일이 그것입니다.

문서에서 권장하는 방식대로 제어 기능을 사용해 보세요. 좁은 스코프, 기본적으로 Simple memory 사용, 저장할 내용 최소화 등을 적용한 다음, 스코프 지정이 해결할 수 없는 단 하나의 케이스인 '모든 Expert가 필요로 하는 사실'을 처리하세요. 이는 특정 역할의 학습 내용이 아니며, 이를 공유 레이어에 유지하는 것이야말로 Expert별 메모리를 원래 의도대로 긴밀하게 유지할 수 있는 방법입니다.