코딩 에이전트가 버그를 고치고 테스트를 돌린 뒤 커밋하는 동안 어떻게 통제권을 유지하나요?

Question

IT Interview Practice · Accepted Answer

코딩 **에이전트**는 버그 수정을 처음부터 끝까지 — 재현, 위치 파악, 수정, 검증, 커밋 — 주도할 수 있지만, **범위가 제한된 권한, 사람의 승인, 작고 되돌릴 수 있는 단계**로 루프를 통제하면 당신이 주도권을 유지합니다. 타이핑은 에이전트가 하고, 실제로 반영되는 것은 당신이 결정합니다.

## 루프

```text
1. REPRODUCE  → 버그를 보여주는 실패하는 테스트를 작성/실행(red)
2. LOCATE     → 코드베이스를 검색하고 관련 파일을 읽어 가설을 세움
3. PROPOSE    → 최소한의 수정을 초안 작성(편집 전에 계획을 검토 가능)
4. VERIFY     → 테스트 + lint/typecheck 실행 → 테스트가 green이 되어 수정이 입증됨
5. REVIEW     → 승인을 위해 DIFF를 표시(아직 아무것도 커밋되지 않음)
6. COMMIT     → 승인 후에만, branch에서, 명확한 메시지로
```

핵심 아이디어는 **테스트 기반 검증**입니다. 에이전트는 "고쳤다"고 주장하지 않고 — 실패하던 테스트를 통과시켜 입증합니다. 1단계의 실패하는 테스트가 변경이 효과가 있었다는 객관적 신호입니다.

## 통제 메커니즘

```text
- SCOPED PERMISSIONS → 안전한 명령(test, lint)은 allowlist; 나머지는 확인 요청
- APPROVAL GATES     → 파괴적/되돌릴 수 없는 행동과 최종 커밋은 사람이 확인
- SMALL STEPS        → 한 번에 하나의 집중된 변경 → 검토와 되돌리기가 쉬움
- BRANCH / WORKTREE   → main과 격리된 작업; 잘못되면 버림
- DIFF REVIEW        → 에이전트 요약이 아니라 실제 diff를 커밋 전에 읽음
```

```bash
# 에이전트가 직접 테스트 스위트를 돌리고 커밋을 제안하기 전에 결과를 보고함
npm test -- --runInBand   # 수정 전 red, 수정 후 green → 객관적 검증
git diff                  # 커밋될 모든 줄을 당신이 검토
```

**branch나 git worktree**에서 작업한다는 것은 최악의 경우가 `git checkout main`뿐이라는 뜻입니다 — 실험이 작업 상태를 건드린 적이 없습니다. 작고 되돌릴 수 있는 커밋은 개별 단계를 검사하고 취소하기 쉽게 만듭니다.

## 왜 중요한가

에이전트 기반 코딩은 모든 줄을 타이핑하는 것에서 **검토하고 방향을 잡는 것**으로 당신의 역할을 바꿉니다. 레버리지는 실재하지만, 에이전트가 자신 있게 잘못되거나 파괴적인 변경을 내보낼 위험도 실재합니다. 커밋 전에 사람의 승인 게이트를 두고, 문장을 믿는 대신 테스트로 검증하며, 작업을 branch에 격리하면 자동화의 속도를 취하면서도 무엇이 `main`에 도달할지 결정하는 사람으로 남을 수 있습니다.

루프

통제 메커니즘

왜 중요한가

관련 질문