코딩 에이전트에게 플랫폼 승인 없이 스케일링 블록(scaling block)을 건드리지 말라고 한 번 말하면, 해당 세션 내에서는 제대로 수행할 것입니다. 하지만 다음 주에 새로운 세션을 열어보면, 컨텍스트(context)가 다음 세션으로 이어지지 않았기 때문에 에이전트가 이를 "망각"한 것을 보게 될 것입니다.

이러한 망각 패턴은 Slack에서 비용이 많이 드는 문제가 될 수 있습니다. Slack에서는 오래된 정보가 드러나거나, 장애 대응(incident) 도중 또는 스탠드업(standup) 스레드 도중에 가드레일(guardrails)을 잊어버리는 상황이 발생하기 때문입니다. 예를 들어, "maxInstances를 롤백하고, 스키마 마이그레이션(schema migration)은 그대로 두라"고 한 번 입력한 규칙은 스크롤백(scrollback) 기록에는 남아 있지만, 새로운 엔지니어들은 이를 보지 못하며, 봇은 해당 규칙 없이 매번 새로운 @mention을 시작합니다. 스크롤백이 명령어를 검색 가능하게 유지해주기는 하지만, 다음에 필요한 사람에게 적절한 컨텍스트를 올바르게 가져와 보여주지는 못합니다.

CodeRabbit Agent for Slack은 다른 종류의 기본 설정을 위해 구축되었습니다. 이 에이전트는 팀이 이미 협업하고 있는 채널에서 작동하므로, 그곳에서 문제를 조사하고, 풀 리퀘스트(pull requests)를 생성하며, 예정된 요약(digests)을 실행할 수 있습니다. 또한 사용자와 함께 작업하며 학습한 지속적인 사실들을 저장하는 지식 베이스 (knowledge base)를 유지합니다. 이러한 사실들은 Slack이 공개 채널, 비공개 채널, DM(Direct Messages)에 걸쳐 이미 구축해 놓은 신뢰 분할 방식을 존중합니다. 의도적으로 사용한다면, 이 메모리는 팀이 신뢰할 수 있는 인프라가 됩니다.

이 글은 이를 의도적으로 사용하고자 하는 엔지니어를 위한 실무 가이드입니다. 마치 #eng-incidents 채널에서 처음으로 @coderabbit을 호출하려는 팀원에게 설명해 주는 것과 같은 내용을 담고 있습니다. 우리는 무엇이 지식 베이스에 속해야 하는지, 그리고 무엇이 리포지토리(repository)나 Linear에 속해야 하는지, 개인정보 보호 경계(privacy boundaries)가 실제로 어떻게 작동하는지, 그리고 메모리가 부패하지 않도록 유지하는 습관은 무엇인지에 대해 살펴볼 것입니다.

CodeRabbit이 지식을 범위 지정하는 방식 (당신의 위협 모델)

CodeRabbit이 지식을 범위 지정하는 방식 (당신의 위협 모델)

CodeRabbit Slack Agent의 지식 베이스 (knowledge base)는 Slack의 개인 정보 보호 모델을 세 가지 수준에 걸쳐 따릅니다. 워크스페이스 전체에서 공유되는 팀 지식, 특정 팀에 특화된 패턴을 담고 있는 채널 메모리, 그리고 현재 작업을 전달하는 스레드 메모리가 있습니다. 공개 채널과 공유 표면(shared surfaces)에서 학습된 사실들은 글로벌 워크스페이스 지식 베이스를 공급하며, 개인 채널, DM, 그룹 DM은 격리된 개인 대화 지식 베이스를 유지합니다.

이러한 분할 구조가 바로 조직 메모리에 대한 당신의 위협 모델입니다. 왜냐하면 어떤 사실이 포착되는 곳에 따라 누가 그것을 사용할 수 있게 되는지를 결정하기 때문입니다. #eng-incidents나 #eng-backend 같은 공개 채널에서 포착된 프로덕션 가드레일(production guardrail)은 팀 전체가 공유하는 메모리가 되며, 다음 @coderabbit 호출에서도 활용될 수 있습니다. 반면, DM에 기록된 동일한 규칙은 오직 당신에게만 머무르기 때문에, 나머지 팀원들은 그것을 학습하지 못한 에이전트를 운영하게 됩니다.

[

Memory는 scopes와 함께 작동하며, 이 scope는 주어진 대화에서 에이전트가 사용할 수 있는 저장소(repositories), 연결(connections), 그리고 비용 제한(spend limits)을 결정합니다. 모든 워크스페이스는 어디에서나 적용되는 Base Scope로 시작하며, 타겟팅된 scope는 특정 채널이나 DM에 대해 이를 재정의(override)합니다. 만약 두 개의 scope가 동일한 대화에 일치할 경우, 에이전트는 해당 일치를 모호한 것으로 간주하고 요청을 차단합니다. 이는 에이전트가 잘못된 저장소, 연결 또는 비용 제한으로 실행되는 것을 방지하기 위함입니다. Memory는 "팀이 무엇을 알고 있는가?"에 답하고, scope는 "에이전트가 무엇을 할 수 있도록 허용되었는가?"에 답하며, 당신은 이 두 가지 모두를 원할 것입니다. 당신의 되돌리기 정책(revert policy)을 기억하지만 여전히 잘못된 저장소나 조직(organization)에 대해 PR을 생성할 수 있는 에이전트는 거버넌스(governance)가 절반만 이루어진 상태입니다.

scoping과 가드레일(guardrails)이 명확해졌다면, 다음 질문은 팀이 애초에 어떻게 컨텍스트(context)를 잃어버리는가 하는 점입니다.

팀이 컨텍스트를 잃어버리는 세 가지 방식

Memory를 활성화하기 전에, 당신이 해결하고자 하는 실패 모드(failure modes)의 이름을 정의하는 것이 도움이 됩니다.

첫 번째는 인시던트 스레드(incident thread)를 진실의 원천(source of truth)으로 취급하는 것입니다. 누군가 "maxInstances를 롤백하고, 스키마 마이그레이션은 그대로 두세요"라고 작성하면, 에이전트는 깨끗한 PR을 생성하고 모두가 이를 머지(merge)합니다. 하지만 2주 후 다른 엔지니어가 유사한 리버트(revert)를 요청하면, 에이전트는 제약 조건이 스크롤백(scrollback)에서 사라지지 않았기 때문에 마이그레이션까지 함께 롤백해 버립니다. 만약 한 달 동안 Slack에서 동일한 규칙을 세 번이나 듣게 된다면, 이는 (기억력의 문제라기보다) 캡처(capture)의 문제입니다. 따라서 해당 규칙을 지식 베이스(knowledge base)로 격상시키거나 에이전트가 GitHub를 통해 읽을 수 있는 런북(runbook)으로 만드세요.

두 번째는 하나의 사실에 대해 상충하는 저장소(homes)를 유지하는 것입니다. Terraform은 maxInstances가 12라고 말하고, 2024년의 Notion 페이지는 8이라고 말하며, 당직(on call) 중인 시니어 엔지니어는 10이라고 말한다면, 불행히도 에이전트는 그중 하나를 자신 있게 선택할 것입니다. 정전(canonical) 소스를 선택하십시오. 이는 거의 항상 인프라를 위한 리포지토리(repository)입니다. 그리고 지식 베이스는 (진실의 복사본을 유지하기보다는) 포인터(pointer)로 사용하세요.

세 번째는 채팅 기록을 메모리(memory)로 취급하는 것입니다. 새로운 스레드에 50개의 메시지를 붙여넣는 것은 정제된 판단을 생성하지 못한 채 토큰(tokens)과 노이즈(noise)만 추가할 뿐입니다. 여러분의 지식 베이스는 Slack 기반 작업에 대한 명세 계층(spec layer)이므로, 의도적으로 편집하고 프로세스가 변경되면 규칙을 폐기하십시오. 그렇지 않으면 에이전트는 여러분의 팀이 2024년에 중단한 작업을 충실히 수행하게 됩니다.

이러한 실패 모드(failure modes)를 명명할 수 있게 되었다면, 실질적인 질문은 "무엇이 실제로 지식 베이스에 포함되어야 하는가"입니다.

KB에 넣어야 할 것 (그리고 제외해야 할 것)

유용한 경험칙(rule of thumb)은 지식 베이스가 팀의 정제된 판단을 담아야 하며, 전체 대화 스레드나 채팅 내보내기(export)를 담는 곳이 아니라는 점입니다.

좋은 지식 베이스 (Knowledge Base) 항목은 짧고 실행 가능해야 합니다. "플랫폼 팀의 검토 없이 Cloud Run 스케일링 변경 사항을 동일한 PR에 스키마 마이그레이션과 함께 묶지 마십시오"와 같은 거버넌스(Governance) 지침은 효과적입니다. 소유자와 대시보드를 명시하는 기본 설정, 사후 분석(Postmortem)을 제출하는 방법을 설명하는 컨벤션(Convention), 그리고 필요한 세부 정보가 있는 파일 위치를 가리키는 압축된 장애 사례(Incident lessons) 등도 마찬가지입니다. 지식 베이스의 북극성(North-star) 지표는 사용자가 더 많은 내용을 스크롤할 필요 없이 해당 라인을 보고 바로 행동에 옮길 수 있는지 여부입니다.

더 긴 자료는 에이전트가 통합(Integration)을 통해 접근할 수 있으므로 기존 위치에 그대로 두는 것이 좋습니다. 런북(Runbook)은 저장소(Repository)나 Notion에, 티켓 상태는 Linear나 Jira에, 코드 및 PR 이력은 GitHub에 남아 있습니다. 따라서 이 중 어느 것도 메모리에 중복해서 넣는 대신, 에이전트가 세부 정보가 필요할 때 외부 링크를 통해 원본을 읽을 수 있도록 합니다.

몇 가지 사항은 메모리에 절대 포함되어서는 안 됩니다. 우선 비밀 정보(Secrets), API 키, 고객 개인정보(PII)가 있으며, 이들은 공개적인 지식 베이스 경로에 포함될 이유가 없습니다. 인사(HR) 또는 법률 관련 서술형 데이터에도 동일한 주의가 적용됩니다.

무엇이 포함되어야 하는지 아는 것만으로는 부족하며, 이를 깔끔하게 입력할 수 있어야 하는데, 이는 결국 프롬프트(Prompt)를 어떻게 작성하느냐로 귀결됩니다.

메모리를 구축하는 프롬프트와 낭비하는 프롬프트

프롬프트(Prompt)를 구성하는 방식에 따라 에이전트가 유용한 정보를 저장할지 아니면 단순한 노이즈(Noise)를 더 쌓을지가 결정되므로, 몇 가지 패턴을 몸에 익혀두는 것이 좋습니다. @CodeRabbit Remember 명령어를 사용하거나 채널에서 /learn 슬래시 명령어(Slash command)를 사용하여 사실(Fact)을 가르칠 수 있으며, 에이전트는 실행 후 발견한 영구적인 사실을 저장하겠다고 제안하기도 합니다. 어떤 방식으로 규칙을 저장하든, 명시적이고(Explicit) 범위를 제한하며(Bounded), 실제로 무엇을 캡처했는지 확인할 수 있도록 재생(Playback)을 요청하세요.

단일하고 제한된 규칙 하나로 시작하세요:

프로세스가 변경되면, 메모리에는 오버라이드(Override, 덮어쓰기)가 필요하므로 기존 규칙을 명시적으로 폐기하세요:

장애 상황(Incident) 중에 해당 규칙에 의존하기 전에 규칙이 실제로 적용되었는지 확인하는 것이 중요합니다. 따라서 에이전트에게 수행할 작업을 설명해 달라고 요청하고, 그 계획(Plan)에 제약 사항(Constraint)이 나타나는지 확인하세요:

@CodeRabbit 다음 작업을 위해 취할 단계들을 나열해 줄래:

- inventory-service의 Cloud Run 스케일링(Scaling) 되돌리기
...