DEV
ORCH
AI 코딩 에이전트가 만든 변경을 바로 반영하지 않고, 위험도 분석 → 독립 리뷰 → 테스트 → 사람 승인을 통과한 diff만 새 브랜치에 커밋하는 MCP 서버를 만들었습니다.
AI 에이전트가 쓴 코드를, 사람이 승인하지 않으면 반영되지 않게 만들 수 있는가?
에이전트는 빠르지만, 잘못된 변경도 똑같이 빠르게 들어옵니다.
리뷰가 빠지거나, 테스트가 깨진 채 반영되거나, 에이전트가 승인 단계를 건너뛸 수 있습니다. 그래서 "코드를 잘 쓰게 하는 도구"가 아니라 잘못 동작할 때 멈추게 하는 도구를 목표로 했습니다.
단계를 건너뛸 수 없는 구조를 설계했습니다.
- 분석·리뷰·테스트·반영을 MCP 도구 8개로 분리. 리뷰가 없거나 NOT_READY면 테스트·반영 도구가 실행을 거부
- 리뷰·테스트·승인을 모두 diff의 SHA에 묶어, 이후 한 줄이라도 바뀌면 이전 결과를 무효화
- 승인 도구는 MCP에 두지 않고, 사람이 터미널에서 직접 승인. 승인·작업 기록은 프로젝트 밖의 키로 서명
- 예상 비용을 먼저 보여주고 실제 비용과 비교, 작업당 비용 상한, 자격증명이 든 diff는 LLM 호출 전에 거부
- 위험 등급에 따라 다른 모델(Anthropic·OpenAI·Gemini)의 독립 리뷰어를 병렬 배정
Analyze → Review → Test → Approve를 하나의 게이트로 연결했습니다.
[REFUSE] run_tests: review missing[INVALID] diff changed after review[STOP] approval_required: HIGH[OK] committed to devorch/<run> branch기능보다 "안 되어야 하는 경로"를 먼저 깨 봤습니다.
직접 재현 → 수정
승인 파일 하나를 직접 써서 커밋까지 가는 경로, 정책 파일을 몰래 고쳐 보호를 푸는 경로가 실제로 가능했습니다. 재현한 뒤 승인 기록 서명과 정책 승인 해시로 막았습니다.
안전장치를 일부러 망가뜨려 테스트가 잡는지 확인
최근 기능 5개에서만 33종의 변형을 시험했고, 처음엔 못 잡아 테스트 단언을 고친 경우 3번을 기록에 남겼습니다.
한계는 숨기지 않음
같은 OS 사용자로 실행되는 악의적인 테스트는 서명 키를 읽을 수 있습니다. 샌드박스 없이는 재현됐고, Docker 샌드박스에서는 막히는 것을 실제 Docker로 확인했습니다.
실제 저장소와 실제 에이전트로 확인했습니다.
AI 리뷰어가 버그를 얼마나 찾는지도 쟀습니다.
공개 저장소에서 나중에 고쳐진 실제 결함 12개로 리뷰어 구성을 비교했습니다. 판정 기준은 실행 전에 확정하고, 결과를 보고 고치지 않았습니다.
우회할 수 있다고 가정하고 직접 깨 보았습니다.
승인 기록 위조
증상 에이전트가 승인 파일 하나를 직접 써서 승인 대기에서 커밋까지 넘어갈 수 있었습니다(2026-10-14 재현). 해결 승인·작업 기록을 서명하고 서명 키를 프로젝트 밖에 두었습니다. Docker 샌드박스 없이는 악의적인 테스트가 키를 읽을 수 있다는 한계도 재현해 문서에 남겼습니다.
정책·설정 파일 변조
증상 보호 경로 삭제나 테스트 명령 교체로 안전장치를 풀 수 있었습니다(2026-10-20 재현). 해결 사람이 승인한 정책 해시를 프로젝트 밖에 서명해 저장하고(policy accept), 같은 재현 스크립트가 막히는 것을 확인했습니다.
위험도 분류 누락
증상 실제 Claude Code 작업 4건 중 1건, 발행 큐 가드 수정이 LOW·리뷰어 없음으로 커밋됐습니다. 원인 분류가 경로와 문장 키워드만 봤습니다. 해결 소유자가 민감 경로를 지정하는 보호 경로를 추가해(위험도는 올리기만 함) 같은 diff가 LOW에서 HIGH로, 사람 승인에서 멈추는 것을 확인했습니다.
에이전트의 신뢰성은 막을 수 있는 경로의 목록에서 나옵니다.
리뷰어를 늘리는 것만으로는 탐지율이 확인되지 않았고, 실제로 효과가 확인된 것은 "검토된 diff만 반영", "승인은 사람만", "실패는 통과가 아님" 같은 경계였습니다. 측정하지 않은 것(비용 절감, 다른 팀의 수요)은 미측정으로 남겨 두었습니다.