내 AI가 컨테이너를 탈출해 모든 일을 해냈지만 — 자신의 코드는 검토하지 않았다

I’m happy to translate the article for you, but I’ll need the full text of the post (the content after the source line) in order to do so. Could you please paste the article’s body here? Once I have the text, I’ll provide a Korean translation while preserving the original formatting, markdown, and any code blocks.

이전: 완전한 개발 사이클

In Part 4 of this series, my AI assistant achieved something remarkable. Running inside a secure Docker container, it could now execute the entire development cycle:

Code → Test → Build → Deploy → Commit

I called it the finale. The trilogy was complete. The AI could write code, run tests, build artifacts, deploy to containers, and commit changes — all while keeping secrets safely hidden.

I was wrong. Something was missing.

빠진 조각

그 사이클을 다시 한 번 보세요. 이제 실제 개발 팀이 어떻게 작동하는지 생각해 보세요.

Code → Test → Build → Deploy → Commit → PR → …

리뷰는 어디에 있나요?

전문 팀에서는 코드가 작성에서 배포까지 단순히 흐르는 것이 아닙니다. 누군가가 코드를 읽고, 누군가가 버그, 보안 문제, 아키텍처 문제를 확인합니다. 누군가가 “이 엣지 케이스를 고려했나요?”라고 묻습니다.

내 AI는 모든 일을 할 수 있지만 — 제외하고 자신의 작업을 검토하는 것은 할 수 없습니다.

공식 플러그인

Claude Code는 공식 /code‑review 플러그인을 가지고 있습니다. 이를 발견했을 때, 그 디자인에 감탄했습니다:

이것은 진지한 엔지니어링입니다: “AI에게 코드를 검토해 달라”는 것이 아니라 고신호 결과를 생성하도록 설계된 구조화된 다단계 파이프라인입니다.

즉시 설치했지만… 작동하지 않았습니다.

왜 접근할 수 없었는가

공식 플러그인은 표준 GitHub 워크플로우를 위해 구축되었습니다. 다음을 기대합니다:

• gh CLI – GitHub에서 PR 세부 정보를 가져오기 위해
• GitHub PR – 검토 대상은 풀 리퀘스트입니다
• 단일 저장소 – 하나의 프로젝트 내에서 동작합니다

내 AI 샌드박스 환경에는 이 중 어느 것도 없습니다:

• gh CLI 없음 (컨테이너에 GitHub 인증이 없습니다)
• 아직 PR이 없음 (푸시 전에 검토를 원하고, 푸시 후는 원하지 않음)
• 하나의 워크스페이스에 여러 독립적인 저장소가 있음 (API, Web, iOS — 각각 자체 Git 히스토리를 가짐)

플러그인은 내 코드를 접근할 수 없었습니다. 설계가 부실해서가 아니라 — 실제로는 훌륭합니다. 하지만 다른 개발 사이클 시점, 즉 푸시 후에 맞춰 만들어졌습니다. 나는 푸시 전에 필요한 것이었습니다.

디자인에서 배우기

플러그인을 직접 사용할 수는 없었지만, 배울 수는 있었습니다.

플러그인 문서는 Claude Code의 사용자 정의 명령이 단순히 Markdown 파일이며—구조화된 지시문이 슬래시 명령으로 변환된다는 것을 보여줍니다. 공식 /code‑review는 잘 설계된 리뷰 파이프라인이 어떤 모습인지, 즉 병렬 분석, 점수 매기기, 검증을 시연했습니다.

그래서 저는 AI에게 물었습니다:

코드‑리뷰 플러그인을 분석하고 로컬에서 작동하는 사용자 정의 명령을 만들어 주세요. 검토할 프로젝트를 선택할 수 있게 하고, 대상 브랜치를 사용자에게 확인하도록 하세요. GitHub 접근 없이 동일한 종류의 리뷰를 수행하도록 합니다.

AI는 공식 플러그인을 읽고 그 구조를 이해한 뒤 로컬 버전을 만들어냈습니다. gh 의존성이 없고, 다중 프로젝트 지원, Git 모드와 비‑Git 모드 모두 포함됩니다. 작동했습니다.

하나에서 아홉까지

로컬 리뷰 명령이 실행된 후, 다음 생각은 명백했습니다.

일반 코드 리뷰어가 있을 수 있다면, 보안 리뷰어는 어떨까요? 성능 리뷰어? 아키텍처 리뷰어?

각 리뷰 유형마다 필요한 전문성이 다릅니다:

아홉 가지 모두 공식 플러그인에서 영감을 받은 동일한 파이프라인 구조를 공유합니다:

Parallel Analysis → Scoring → Verification → Report
(4‑5 Sonnet agents)   (Haiku)      (Sonnet)

각 특화된 명령은 서로 다른 리뷰 관점을 가진 병렬 에이전트를 보냅니다. 스코어링 에이전트가 신뢰도를 평가하고, 검증 에이전트가 오탐을 제거합니다. 높은 신뢰도와 검증을 거친 결과만 최종 보고서에 포함됩니다.

파이프라인 작동 예시

/ais-local-review를 실행하면 다음과 같이 진행됩니다:

1. 프로젝트와 브랜치 선택 (Git이 없을 경우 파일 선택).
2. 네 개의 Sonnet 에이전트가 병렬로 실행:
   • Agent #1: CLAUDE.md 준수 여부 — 코드가 프로젝트 규칙을 따르고 있는가?
   • Agent #2: 버그 스캔 — 명백한 논리 오류와 엣지 케이스.
   • Agent #3: 히스토리 분석 — 이전에 수정된 버그를 다시 도입하고 있는가?
   • Agent #4: 주석 검사 — 코드가 자체 문서와 일치하는가?
3. Haiku 에이전트가 모든 발견 항목에 점수 부여 (0‑100).
4. Sonnet 검증 에이전트가 점수 75 점 이상인 항목을 재검토.
5. 확인된 고신뢰도 이슈만 보고서에 포함.

그 결과는 방대한 잡담이 아닌, 실제로 중요한 항목만을 나열한 간결한 보고서가 됩니다.

두 개의 리뷰, 두 개의 순간

공식 플러그인과 로컬 명령은 경쟁 관계가 아니라, 개발 사이클의 서로 다른 순간을 담당합니다.

Code → Review → Test → Build → Deploy → Commit → PR → …

• 로컬 리뷰는 PR을 만들기 전에 진행되어 문제를 일찍 잡아냅니다.
• GitHub 기반 리뷰는 PR을 연 후 실행되어 두 번째 안전망을 제공합니다.

두 리뷰를 함께 사용하면 코드베이스가 첫 키 입력부터 프로덕션 배포까지 지속적으로, 다단계 품질 게이트를 통과하도록 만들어 줍니다.

개발 흐름

→ Build → Deploy → Commit → PR → Review
         ↑                                                ↑
    ais-* commands                              Official /code-review
    Before you push                              After you push
    Quality gate                                 Team review
    Local, private                               GitHub, collaborative

공식 /code-review는 팀이 코드를 검토할 준비가 되었을 때 사용합니다.
PR에 댓글을 달고, 변경을 제안하며, GitHub의 협업 기능과 통합됩니다.

ais-* 명령은 초기 단계—아직 개발 중이거나 커밋하기 전, 때로는 테스트 작성이 끝나기 전—에 사용됩니다.
이들은 사설 품질 게이트 역할을 하여, 수정 비용이 가장 낮은 시점에 문제를 잡아냅니다.

완성된 사이클

Part 4에서의 개발 사이클을 기억하시나요?

Code → Test → Build → Deploy → Commit

이제는 다음과 같이 보입니다:

Code → Review → Test → Build → Deploy → Commit
         ↑
    The missing piece

AI는 코드를 작성하고, 자체 작업을 (다양한 관점에서) 검토하며, 테스트를 실행하고, 빌드하고, 배포하고, 커밋할 수 있습니다. 누락되었던 품질 게이트가 이제 마련되었습니다.

내가 배운 것

이 프로젝트는 공식 플러그인이 내 코드를 접근할 수 없어서 시작되었습니다. 그 제한이 예상치 못한 방향으로 이어졌습니다.

공식 플러그인의 설계—병렬 에이전트, 신뢰도 점수, 오탐 제거—는 청사진 역할을 했습니다. 오픈 소스의 최고 모습: 어떻게 동작하는지 읽고, 원리를 이해하고, 이를 자신의 환경에 맞게 적용하는 것입니다.

나는 단순히 코드 리뷰어만 얻은 것이 아닙니다. 아홉 개의 특화된 리뷰 도구, 리팩터링 도우미, 자동 테스트 생성기를 얻었습니다. 모두 공식 플러그인이 잘 설계된 리뷰 파이프라인이 어떤 모습인지 보여주었고, 내 AI 샌드박스가 로컬에서 작동하는 파이프라인을 구축할 수 있는 장소를 제공했기 때문입니다.

지금까지의 시리즈

“내 AI가 내 API 키를 볼 수 있다”는 이야기에서 시작해 더 큰 프로젝트가 되었습니다:

• Secrets – Docker 볼륨 마운트를 사용해 AI로부터 민감한 파일을 숨깁니다
• Toolbox – AI가 SandboxMCP를 통해 도구를 자동으로 발견하고 사용합니다
• Host Access – AI가 제어된 호스트 OS 접근 권한으로 컨테이너를 탈출합니다
• Review (이 글) – AI가 자체 코드를 검토하여 개발 주기를 완성합니다

삼부작이 사중작이 되었습니다. 더 이상 완전하다고 약속하지는 않겠습니다.

AI Sandbox with DockMCP는 오픈 소스입니다: GitHub repository

AI 워크플로우를 위해 맞춤형 리뷰 명령을 만든 경우, 댓글로 알려 주세요.