에이전트 엔지니어링의 8가지 단계 [번역]

작성자: Bassim Eledath 원문: The 8 Levels of Agentic Engineering — Bassim Eledath

AI의 프로그래밍 능력은 우리가 그것을 활용할 수 있는 능력을 앞지르고 있습니다. 이것이 바로 SWE-bench 점수를 높이기 위한 그 모든 분주한 노력이 엔지니어링 리더십이 실제로 신경 쓰는 생산성 지표로 이어지지 못한 이유입니다. Anthropic 팀은 Cowork을 10일 만에 출시했지만, 동일한 모델을 사용하는 다른 팀은 개념 증명(POC)조차 시작하지 못합니다. 그 차이는 한 팀은 능력과 실천 사이의 격차를 메웠고, 다른 팀은 그렇지 못했다는 점입니다.

이 격차는 하룻밤 사이에 사라지지 않습니다. 단계적으로 좁혀집니다. 정확히 말하면 여덟 단계입니다. 이 글을 읽는 대부분의 사람들은 아마 처음 몇 단계는 통과했을 것이며, 다음 단계에 도달하려고 열망해야 합니다. 왜냐하면 각 단계를 올라갈 때마다 출력이 크게 도약하며, 모델 능력이 조금씩 향상될 때마다 그 이득이 더욱 증폭되기 때문입니다.

또 다른 이유는 멀티플레이어 효과입니다. 여러분의 출력은 생각보다 팀원들의 수준에 더 많이 의존합니다. 여러분이 Level 7의 마법사라서, 여러분이 자는 동안 배경 에이전트들이 여러 개의 PR을 제출한다고 가정해 보겠습니다. 하지만 여러분의 저장소가 병합을 위해 동료의 승인이 필요하고, 그 동료가 Level 2에 머물러 수동으로 PR을 검토한다면, 여러분의 처리량은 병목 현상에 걸립니다. 따라서 팀원들의 수준을 높이는 것은 여러분에게도 이익이 됩니다.

많은 팀과 개인들이 AI 지원 프로그래밍 관행에 대해 이야기한 내용을 바탕으로, 제가 관찰한 진행 경로는 다음과 같습니다(순서는 엄격하게 고정된 것은 아닙니다).

에이전트 엔지니어링의 8가지 단계

단계 1 & 2: 탭 완성 및 에이전트 IDE#

이 두 단계는 주로 완전성을 위해 빠르게 살펴보겠습니다. 대충 훑어보셔도 좋습니다.

탭 완성은 모든 것이 시작된 곳입니다. GitHub Copilot이 이 움직임을 시작했습니다. Tab 키를 누르면 코드가 나옵니다. 많은 사람들이 아마 이 단계를 잊어버렸을 것이고, 새로 온 사람들은 아예 건너뛰었을 수도 있습니다. 이는 코드의 뼈대를 스케치하고 AI가 세부 사항을 채우도록 할 수 있는 경험 많은 개발자에게 더 적합합니다.

Cursor가 주도하는 AI 네이티브 IDE는 채팅을 코드베이스에 연결하여 게임을 바꾸었고, 크로스 파일 편집을 훨씬 쉽게 만들었습니다. 하지만 항상 한계는 컨텍스트였습니다. 모델은 볼 수 있는 것만 도울 수 있으며, 좌절감은 적절한 컨텍스트를 보지 못하거나 너무 많은 관련 없는 컨텍스트를 보는 데서 비롯되었습니다.

이 수준의 대부분의 사람들은 또한 선택한 프로그래밍 에이전트의 계획(Plan) 모드를 실험하고 있습니다. 대략적인 아이디어를 LLM을 위한 구조화된 단계별 계획으로 바꾸고, 그 계획을 반복하며, 실행을 트리거하는 것입니다. 이 단계에서는 잘 작동하며 통제를 유지하는 합리적인 방법입니다. 그러나 나중 단계에서 보게 될 것처럼, 계획 모드에 대한 의존도는 줄어듭니다.

단계 3: 컨텍스트 엔지니어링#

이제 흥미로운 부분에 도달했습니다. 컨텍스트 엔지니어링은 2025년의 유행어였습니다. 이는 모델이 마침내 적절한 컨텍스트만으로 합리적인 수의 지시를 안정적으로 따를 수 있게 되었기 때문에 생겨난 것입니다. 잡음이 많은 컨텍스트는 부족한 컨텍스트만큼 나쁘므로, 핵심 작업은 토큰당 정보 밀도를 높이는 것입니다. "모든 토큰은 프롬프트에서 자신의 자리를 위해 싸워야 한다"는 것이 만트라였습니다.

동일한 정보, 더 적은 토큰 — 정보 밀도가 왕입니다 (출처: humanlayer/12-factor-agents)

실제로 컨텍스트 엔지니어링은 대부분이 생각하는 것보다 더 넓습니다. 여기에는 시스템 프롬프트와 규칙 파일(.cursorrules, CLAUDE.md)이 포함됩니다. 여기에는 도구를 어떻게 설명하는지도 포함됩니다. 왜냐하면 모델은 어떤 도구를 호출할지 결정하기 위해 그 설명을 읽기 때문입니다. 또한 대화 기록을 관리하여 장기 실행 에이전트가 열 번째 턴 이후에 길을 잃지 않도록 하는 것도 포함됩니다. 또한 매 턴마다 어떤 도구를 노출할지 결정하는 것도 포함됩니다. 너무 많은 옵션은 모델을 압도하기 때문입니다. 사람과 마찬가지로요.

요즘에는 컨텍스트 엔지니어링에 대해 그렇게 많이 듣지 못합니다. 저울은 더 시끄러운 컨텍스트를 견디고 더 지저분한 시나리오에서 추론할 수 있는 모델 쪽으로 기울었습니다(더 큰 컨텍스트 창도 도움이 됩니다). 하지만 컨텍스트 소비에 주의하는 것은 여전히 중요합니다. 몇 가지 시나리오에서 병목 현상이 됩니다.

더 작은 모델은 컨텍스트에 더 민감합니다. 음성 애플리케이션은 종종 더 작은 모델을 사용하며, 컨텍스트 크기는 첫 번째 토큰 지연 시간과도 상관관계가 있어 응답 속도에 영향을 미칩니다.
토큰 소모자. Playwright 및 이미지 입력과 같은 MCP(Model Context Protocol)는 토큰을 빠르게 소모하여 예상보다 빨리 Claude Code의 "압축 세션"으로 밀어넣습니다.
수십 개의 도구를 가진 에이전트, 모델이 실제 작업을 하는 것보다 도구 정의를 구문 분석하는 데 더 많은 토큰을 소비하는 경우.

더 넓은 시사점: 컨텍스트 엔지니어링은 사라지지 않았습니다. 진화하고 있습니다. 초점은 나쁜 컨텍스트를 걸러내는 것에서 적절한 컨텍스트가 적절한 시간에 나타나도록 보장하는 것으로 이동했습니다. 그리고 바로 이 변화가 단계 4로 가는 길을 닦습니다.

단계 4: 복리 엔지니어링#

컨텍스트 엔지니어링은 이번 세션을 개선합니다. 복리 엔지니어링(Kieran Klaassen가 만든 용어)은 이후의 모든 세션을 개선합니다. 이 개념은 저와 많은 다른 사람들에게 전환점이었습니다. 이것은 "느낌으로 프로그래밍하기"가 단순한 프로토타이핑을 훨씬 넘어선다는 것을 깨닫게 해주었습니다.

이는 "계획, 위임, 평가, 복리" 루프입니다. 작업을 계획하고, LLM이 성공할 수 있을 만큼 충분한 컨텍스트를 제공합니다. 위임합니다. 출력을 평가합니다. 그런 다음 결정적인 단계인 배운 것을 복리로 쌓습니다: 무엇이 효과가 있었는지, 무엇이 잘못되었는지, 다음에 따라야 할 패턴은 무엇인지.

복리 루프: 계획, 위임, 평가, 복리 — 각 라운드는 다음 라운드를 더 좋게 만듭니다

마법은 "복리" 단계에 있습니다. LLM은 상태가 없습니다. 만약 어제 명시적으로 제거한 종속성을 다시 도입했다면, 내일도 다시 할 것입니다. 여러분이 그렇게 하지 말라고 말하지 않는 한 말이죠. 가장 일반적인 해결책은 CLAUDE.md(또는 동등한 규칙 파일)를 업데이트하여 교훈을 향후 모든 세션에 구워 넣는 것입니다. 하지만 조심하세요: 모든 것을 규칙 파일에 덤프하려는 충동은 역효과를 낼 수 있습니다(지시가 너무 많으면 지시가 없는 것과 같습니다). 더 나은 접근 방식은 LLM이 유용한 컨텍스트를 쉽게 발견할 수 있는 환경을 만드는 것입니다. 예를 들어 최신 상태의 docs/ 폴더를 유지하는 것처럼요(이에 대해서는 단계 7에서 더 자세히 설명합니다).

복리 엔지니어링을 실천하는 사람들은 일반적으로 LLM에 제공되는 컨텍스트에 대해 매우 민감합니다. LLM이 실수를 할 때, 그들의 본능은 먼저 컨텍스트에 무언가 빠졌는지 고려하는 것이지, 모델을 탓하는 것이 아닙니다. 바로 이 직관이 단계 5부터 8을 가능하게 만듭니다.

레벨 5: MCP와 스킬#

레벨 3과 4는 컨텍스트를 해결합니다. 레벨 5는 역량을 해결합니다. MCP와 커스텀 스킬은 LLM에게 데이터베이스, API, CI 파이프라인, 디자인 시스템, 브라우저 테스트를 위한 Playwright, 알림을 위한 Slack에 대한 접근 권한을 부여합니다. 이제 모델은 단순히 코드베이스에 대해 생각하는 것을 넘어서서 직접적으로 코드베이스를 조작할 수 있습니다.

MCP와 스킬이 무엇인지에 대한 좋은 자료는 많으므로, 여기서는 반복하지 않겠습니다. 하지만 제 사용 사례에서 몇 가지 예를 들자면: 우리 팀은 함께 반복 개선해 온 (그리고 여전히 개선 중인) PR 리뷰 스킬을 공유합니다. 이 스킬은 PR의 성격에 따라 조건부로 하위 에이전트를 생성합니다. 하나는 데이터베이스 통합의 보안을 확인하고, 하나는 중복성이나 과도한 설계를 표시하기 위한 복잡성 분석을 수행하며, 또 다른 하나는 프롬프트가 팀의 표준 형식을 따르는지 확인하기 위해 프롬프트 상태를 점검합니다. 또한 린터와 Ruff도 실행합니다.

왜 리뷰 스킬에 이렇게 많이 투자할까요? 에이전트가 대량으로 PR을 생성하기 시작하면, 품질 게이트가 아니라 인간의 리뷰가 병목 현상이 되기 때문입니다. Latent Space는 설득력 있는 주장을 했습니다: 우리가 알고 있는 코드 리뷰는 죽었습니다. 그 자리에는 자동화되고 일관적이며 스킬 기반의 리뷰가 있습니다.

MCP 측면에서는, Braintrust MCP를 사용하여 LLM이 평가 로그를 쿼리하고 직접 편집할 수 있게 합니다. DeepWiki MCP를 사용하여 에이전트가 오픈소스 리포지토리의 문서에 접근할 수 있게 하여, 수동으로 문서를 컨텍스트에 끌어오지 않아도 됩니다.

팀 내 여러 사람이 독립적으로 유사한 스킬을 작성하기 시작하면, 공유 레지스트리로 통합할 가치가 있습니다. Block (애도)은 훌륭한 글을 썼습니다: 그들은 100개 이상의 스킬을 가진 내부 스킬 마켓플레이스를 구축하고 특정 역할과 팀을 위한 큐레이션된 스킬 패키지를 만들었습니다. 스킬은 코드와 동일한 대우를 받습니다: 풀 리퀘스트, 리뷰, 버전 기록.

또 다른 주목할 트렌드는: LLM이 MCP보다 CLI 도구를 점점 더 많이 사용하고 있다는 것입니다 (그리고 모든 회사가 자체 CLI를 출시하는 것 같습니다: Google Workspace CLI, Braintrust도 곧 출시할 예정입니다). 그 이유는 토큰 효율성 때문입니다. MCP 서버는 에이전트가 사용하는지 여부와 관계없이 매 턴마다 전체 도구 정의를 컨텍스트에 주입합니다. CLI는 반대로 작동합니다: 에이전트가 대상 명령을 실행하면, 관련 출력만 컨텍스트 창에 들어갑니다. 저는 바로 이 이유로 Playwright MCP 대신 agent-browser를 많이 사용합니다.

계속하기 전에 잠시 멈춰보세요. 레벨 3부터 5는 이후 모든 것의 기초입니다. LLM은 어떤 것에는 놀라울 정도로 뛰어나고, 다른 것에는 놀라울 정도로 형편없습니다. 더 많은 자동화를 그 위에 쌓기 전에 이러한 경계에 대한 직관을 개발해야 합니다. 컨텍스트가 지저분하고, 프롬프트가 부족하거나 부정확하며, 도구 설명이 모호하다면, 레벨 6부터 8은 그 문제들만 증폭시킬 것입니다.

레벨 6: 하네스 엔지니어링#

로켓이 본격적으로 날아오르기 시작하는 지점입니다.

컨텍스트 엔지니어링은 모델이 무엇을 보는지에 관한 것입니다. 하네스 엔지니어링은 에이전트가 당신의 개입 없이도 안정적으로 작업할 수 있도록 하는 전체 환경—도구, 인프라, 피드백 루프—을 구축하는 것입니다. 당신은 에이전트에게 단순한 편집기가 아니라 완전한 피드백 루프를 제공합니다.

OpenAI의 Codex 툴체인—에이전트가 자신의 출력을 쿼리하고, 상관 관계를 분석하며, 추론할 수 있게 하는 완전한 가시성 시스템 (출처: OpenAI)

OpenAI의 Codex 팀은 Chrome DevTools, 가시성 도구, 브라우저 네비게이션을 에이전트 런타임에 통합하여, 에이전트가 스크린샷을 찍고, UI 흐름을 제어하며, 로그를 쿼리하고, 자신의 수정 사항을 검증할 수 있게 했습니다. 프롬프트를 주면, 에이전트는 버그를 재현하고, 비디오를 녹화하며, 수정 사항을 구현할 수 있습니다. 그런 다음 앱을 조작하여 검증하고, PR을 제출하며, 리뷰 피드백에 응답하고, 머지합니다—판단이 필요한 경우에만 인간에게 에스컬레이션합니다. 에이전트는 단순히 코드를 작성하는 것이 아니라, 그 코드가 생성하는 결과를 보고 반복합니다—마치 인간처럼요.

제 팀은 기술적 문제 해결을 위한 음성 및 채팅 에이전트를 작업하므로, converse라는 CLI 도구를 구축했습니다. 이 도구는 모든 LLM이 턴바이턴 대화를 위해 우리의 백엔드 인터페이스와 채팅할 수 있게 합니다. LLM이 코드를 수정한 후, converse를 사용하여 라이브 시스템에서 대화를 테스트한 다음 반복합니다. 때로는 이 자기 개선 루프가 몇 시간 동안 실행되기도 합니다. 이는 결과를 검증할 수 있을 때 특히 강력합니다: 대화가 반드시 이 흐름을 따라야 하거나, 특정 상황(예: 인간에게 에스컬레이션)에서 이러한 도구를 호출해야 합니다.

이 모든 것을 뒷받침하는 핵심 개념은 백프레셔입니다—타입 시스템, 테스트, 린터, 프리커밋 훅과 같은 자동화된 피드백 메커니즘으로, 에이전트가 인간의 개입 없이 실수를 발견하고 수정할 수 있게 합니다. 자율성을 원한다면 반드시 백프레셔가 있어야 합니다; 그렇지 않으면 쓰레기 생성 기계를 얻게 됩니다. 이는 보안에도 확장됩니다. Vercel의 CTO가 지적했듯이, 에이전트, 그들이 생성한 코드, 그리고 당신의 키는 서로 다른 신뢰 도메인에 있어야 합니다. 왜냐하면 로그 파일에 숨겨진 프롬프트 인젝션 공격이 에이전트를 속여 당신의 자격 증명을 훔치게 할 수 있기 때문입니다—모든 것이 동일한 보안 컨텍스트를 공유한다면요. 보안 경계 는 백프레셔입니다: 그것들은 에이전트가 제멋대로 행동할 때 할 수 있는 일을 제한할 뿐만 아니라, 해야 할 일도 제한합니다.

이를 더 명확히 하기 위한 두 가지 원칙:

완벽함이 아니라 처리량을 위해 설계하라. 모든 커밋이 완벽해야 할 때, 에이전트는 같은 버그를 계속 반복하거나 서로의 수정 사항을 덮어쓰게 됩니다. 작은, 차단되지 않는 오류를 허용하고 출시 전에 최종 품질 점검을 하는 것이 더 낫습니다. 우리는 인간 동료와도 이렇게 합니다.
지시보다는 제약. 단계별 프롬프팅("A를 하고, B를 하고, C를 하라")은 점점 구식이 되어가고 있습니다. 제 경험상, 단계를 나열하는 것보다 경계를 정의하는 것이 더 효과적입니다. 왜냐하면 에이전트는 목록에 집착하여 그 외의 모든 것을 무시하기 때문입니다. 더 나은 프롬프트는 다음과 같습니다: "내가 원하는 결과는 이것입니다. 이 모든 테스트를 통과할 때까지 계속하세요."

하네스 엔지니어링의 다른 절반은 에이전트가 당신 없이도 코드베이스를 탐색할 수 있도록 보장하는 것입니다. OpenAI의 접근법: AGENTS.md를 약 100줄 정도로 유지하여 다른 구조화된 문서를 가리키는 목차 역할을 하게 하고, 문서 신선도를 CI 프로세스에 구워 넣어 빠르게 낡아버리는 임시 업데이트에 의존하지 않습니다.

이 모든 것을 구축하고 나면 자연스럽게 질문이 생깁니다: 에이전트가 자신의 작업을 검증하고, 리포지토리를 탐색하며, 당신 없이도 오류를 수정할 수 있다면—왜 당신이 자리에 있어야 할까요?

아직 이전 레벨에 있는 분들을 위한 참고사항: 다음 내용은 공상과학처럼 들릴 수 있습니다 (하지만 괜찮습니다, 북마크해두고 나중에 다시 오세요).

레벨 7: 백그라운드 에이전트#

핫 테이크: 플랜 모드는 사라지고 있습니다.

Claude Code의 창시자인 Boris Cherny는 여전히 작업의 80%를 플랜 모드로 시작합니다. 하지만 각각의 새로운 모델 세대가 출시될 때마다, 계획 후 원샷 성공률은 계속해서 상승하고 있습니다. 저는 플랜 모드가 별도의 수동 단계로서 사라지는 전환점에 다가가고 있다고 생각합니다. 계획 자체가 중요하지 않아서가 아니라, 모델들이 스스로 잘 계획할 수 있을 만큼 충분히 똑똑해지고 있기 때문입니다. 하지만 중요한 주의사항이 있습니다: 이는 오직 레벨 3부터 6까지의 작업을 완료했을 때만 성립합니다. 컨텍스트가 깨끗하고, 제약 조건이 명확하며, 도구 설명이 확실하고, 피드백 루프가 닫혀 있다면, 모델은 당신의 검토 없이도 신뢰성 있게 계획을 세울 수 있습니다. 그 작업이 완료되지 않았다면, 당신은 여전히 계획에 매달려 있을 것입니다.

명확히 하자면, 일반적인 실천으로서의 계획이 사라지는 것은 아닙니다; 단지 형태가 변하고 있을 뿐입니다. 초보자에게는 플랜 모드가 여전히 올바른 진입점입니다(레벨 1 & 2에서 설명한 대로). 하지만 레벨 7의 복잡한 기능에 대해서는, "계획"은 단계별 개요를 작성하는 것보다는 탐색처럼 보입니다: 코드베이스를 탐색하고, 워크트리에서 프로토타이핑하고, 솔루션 공간을 매핑하는 것. 그리고 점점 더, 그 탐색을 당신 대신 해주는 것은 백그라운드 에이전트입니다.

이것이 중요한 이유는, 바로 이것이 백그라운드 에이전트를 가능하게 하는 열쇠이기 때문입니다. 에이전트가 신뢰할 수 있는 계획을 생성하고 당신의 승인 없이 실행할 수 있다면, 그것은 당신이 다른 일을 하는 동안 비동기적으로 실행될 수 있습니다. 이것은 핵심적인 전환입니다—"탭 사이에서 컨텍스트를 전환한다"에서 "내가 없어도 작업이 진행된다"로.

Ralph 루프는 인기 있는 진입점입니다: PRD의 모든 항목이 완료될 때까지 프로그래밍 CLI를 반복적으로 실행하고, 각 반복마다 새로운 컨텍스트로 신선한 인스턴스를 생성하는 자율 에이전트 루프입니다. 제 경험상, Ralph 루프가 잘 작동하도록 만드는 것은 까다롭습니다; PRD의 어떤 부족함이나 부정확함도 결국 문제가 되어 돌아옵니다. 약간 너무 "발사 후 망각"입니다.

여러 개의 Ralph 루프를 병렬로 실행할 수 있지만, 더 많은 에이전트를 가동할수록 당신의 시간은 다음과 같은 일에 소비될 것입니다: 그들을 조정하고, 작업 순서를 정하고, 출력을 확인하고, 진행 상황을 추진하는 일. 당신은 더 이상 코딩을 하지 않습니다—당신은 중간 관리자가 된 것입니다. 당신은 의도에 집중하고, 물류에는 집중하지 않도록 스케줄링을 처리할 오케스트레이터 에이전트가 필요합니다.

Dispatch는 3개의 모델에 걸쳐 5개의 작업자를 병렬로 가동합니다—당신의 세션은 가볍게 유지되고, 에이전트가 작업을 수행합니다.

최근 제가 많이 사용하고 있는 도구는 Dispatch입니다. 제가 만든 Claude Code 스킬로, 당신의 세션을 명령 센터로 바꿔줍니다. 당신은 깨끗한 세션에 머물고, 작업자들이 격리된 컨텍스트에서 힘든 작업을 수행합니다. 디스패처는 계획, 위임, 추적을 처리하여 오케스트레이션을 위한 메인 컨텍스트 창을 보존합니다. 작업자가 막히면, 조용히 실패하는 대신 명확화 질문을 던집니다.

Dispatch는 로컬에서 실행되며, 작업에 가까이 있고 싶은 신속한 개발에 완벽합니다: 더 빠른 피드백, 쉬운 디버깅, 인프라 오버헤드 없음. Ramp의 Inspect는 더 오래 실행되고 더 자율적인 작업을 위한 상호 보완적인 접근 방식입니다: 각 에이전트 세션은 전체 개발 환경을 갖춘 클라우드 샌드박스 VM에서 시작됩니다. PM이 UI 버그를 발견하고 Slack에서 태그를 달면, Inspect가 인계받아 당신의 노트북이 꺼져 있는 동안 처리합니다. 트레이드오프는 운영 복잡성(인프라, 스냅샷, 보안)이지만, 로컬 에이전트가 따라올 수 없는 규모와 재현성을 얻습니다. 저는 둘 다(로컬 및 클라우드 백그라운드 에이전트) 사용하는 것을 권장합니다.

이 레벨에서 예상치 못하게 강력한 패턴: 다른 작업에 다른 모델을 사용하기. 최고의 엔지니어링 팀은 복제품으로 이루어지지 않습니다. 팀원들은 다르게 생각하고, 다른 훈련을 받았으며, 다른 강점을 가지고 있습니다. 동일한 논리가 LLM에도 적용됩니다. 이 모델들은 서로 다른 사후 훈련을 거쳤고 독특한 성격을 가지고 있습니다. 저는 종종 구현 작업에는 Opus를, 탐색적 연구에는 Gemini를, 검토에는 Codex를 할당하여, 단일 모델이 혼자 작업하는 것보다 강력한 결합된 출력을 얻습니다. 코드를 위한 군집 지능을 생각해보세요.

결정적으로, 구현자와 검토자를 분리할 필요도 있습니다. 저는 이 교훈을 너무나도 여러 번 고통스럽게 배웠습니다: 동일한 모델 인스턴스가 자신의 작업을 구현하고 평가하는 경우, 그것은 편향됩니다. 문제를 간과하고, 모든 작업이 완료되었다고 말할 것입니다—실제로는 그렇지 않은데도요. 악의가 있는 것이 아닙니다; 당신이 자신의 시험지를 채점하지 않을 것과 같은 이유입니다. 다른 모델(또는 검토 특화 프롬프트가 있는 다른 인스턴스)이 검토를 수행하도록 하세요. 신호 품질이 극적으로 향상됩니다.

백그라운드 에이전트는 또한 CI + AI 통합의 물꼬를 엽니다. 에이전트가 조종자 없이 실행될 수 있게 되면, 기존 인프라에서 트리거될 수 있습니다. 문서 봇은 모든 병합 후 문서를 재생성하고 CLAUDE.md를 업데이트하는 PR을 제출합니다(저희가 사용 중이며, 많은 시간을 절약합니다). 보안 검토 봇은 PR을 스캔하고 수정 사항을 제출합니다. 종속성 관리 봇은 단순히 문제를 표시하는 것이 아니라, 실제로 패키지를 업그레이드하고 테스트를 실행합니다.