3편짜리 시리즈의 마지막이다. 1편은 장벽 지도를 그렸고, 2편은 그 중 가장 되돌리기 어려운 DB 변경 문제와 해법을 짚었다. 이번 편은 손을 움직이는 단계다. 4주 안에 Agentic SDLC를 안전하게 시작하는 로드맵이다.
"20년 묵은 도구"의 뜻
제목이 조금 역설적으로 들릴 수 있다. "낡았다"는 뜻이 아니다. 20년간 쓰인 도구에는 20년치 버그 리포트와 20년치 코너케이스가 쌓여 있다. 그게 신뢰의 근거다.
- Git: 2005년 (20년)
- DB 마이그레이션 패턴: 2003년 마틴 파울러
- CI/CD 파이프라인: 2000년대 초 ThoughtWorks CruiseControl
- 코드 리뷰/PR 게이트: 2000년대 중반 이후
Agentic SDLC를 안전하게 만드는 요소들이 이미 그 자리에 있다. 새 도구를 구입할 필요가 없다. 연결이 안 돼 있을 뿐이다.

4주 로드맵
Week 1 — 기반 점검
에이전트에게 첫 태스크를 던지기 전에, 세 가지를 먼저 정비한다.
AGENTS.md 또는 CLAUDE.md 작성. 프로젝트의 디렉토리 구조, 금지 명령(프로덕션 DB 직접 접근 불가, 인프라 삭제 명령 불가), 마이그레이션 파일 생성 규칙을 문서화한다. 이 파일이 에이전트의 행동 규칙서다 (AGENTS.md 표준, CLAUDE.md 문서).
CI/CD 파이프라인 점검. PR 게이트(lint, 타입 체크, 테스트)가 자동화돼 있는지 확인한다. 없다면 이번 주에 만든다. 에이전트가 만든 코드를 사람이 매번 수동으로 검증하는 건 지속되지 않는다.
권한 감사. 에이전트가 실행할 수 있는 명령 범위를 명시한다. 개발/스테이징 환경 자격증명과 프로덕션 자격증명을 분리하고, 에이전트가 접근하는 환경을 명확히 한다.
Week 2 — Schema-as-Code 구축
2편에서 다룬 DB 마이그레이션 도구를 실제로 도입하는 주다.
도구 선택 및 설치. 언어 생태계를 따라가면 된다. Python이면 Alembic, Go면 golang-migrate나 Goose, Node.js면 Prisma Migrate, 언어 무관이면 Flyway.
기준점(baseline) 설정. 기존 스키마를 V001__baseline.sql로 만들어 둔다. 이 시점부터 모든 스키마 변경은 번호 붙은 파일로 관리된다.
규칙 AGENTS.md 반영. "ORM 모델이나 스키마 참조 코드를 수정할 때 마이그레이션 파일을 함께 생성한다", "컬럼 삭제/타입 변경은 Expand-Contract 두 단계로 나눈다"를 문서에 추가한다.
CI 게이트 추가. 스키마 변경 코드가 포함된 PR에 마이그레이션 파일이 없으면 빌드를 실패시킨다.
Week 3 — 승인 게이트 구축
에이전트가 만든 것을 구조적으로 검수하는 장치를 만든다.
pre-commit hooks. 코드 스타일, 비밀 키 노출, SQL DDL 직접 포함 여부를 커밋 전에 잡는다.
마이그레이션 파일 검수 레이블. 마이그레이션 파일이 변경된 PR에 자동으로 "DB-review-required" 레이블을 붙이는 GitHub Actions(또는 동등한 CI 액션)를 추가한다. 이 레이블이 붙은 PR은 사람 승인 없이 머지되지 않는다.
환경별 자격증명 검증. 개발 환경에서 돌리던 코드가 프로덕션 자격증명을 참조할 수 없도록 점검한다.
Week 4 — 첫 위임
이제 실제로 에이전트에게 태스크를 던질 준비가 됐다.
장벽 지수 낮은 영역부터. 1편 장벽 지도 기준으로 FE 개발(25점)이나 MVP 프로토타입(28점) 영역부터 시작한다. 작게 시작해서 검수 루프가 실제로 돌아가는지 확인한다.
단위를 작게 유지한다. 단일 PR, 단일 마이그레이션. 에이전트가 한 번에 너무 많은 걸 바꾸면 검수 비용이 급격히 올라간다.
루프 1회 통과 후 범위 확장. 첫 태스크가 "에이전트 생성 → CI 통과 → 사람 검수 → 머지" 루프를 완주했으면, 그 다음 태스크의 범위를 조금 넓힌다. 신뢰는 통과한 루프의 누적이다.

무엇을 포기해야 하는가
속도다. 승인 게이트는 에이전트의 속도를 늦춘다. 이게 불편하게 느껴질 수 있다. 하지만 1편의 세 사고를 다시 떠올려 보면, 모두 "빠르게 처리하려고 게이트를 건너뛴" 결과였다. Replit, DataTalks, Anthropic 내부 인시던트. 93퍼센트의 권한 프롬프트를 자동 승인했다는 수치가 말해주는 게 있다.
에이전트를 더 빠르게 만드는 게 먼저가 아니다. 에이전트가 만든 것을 안전하게 검수하는 구조를 먼저 만드는 게 순서다. 그 구조가 자리를 잡고 나면, 점검 비용이 낮아지면서 자연스럽게 빠르게 진행하는 영역이 생긴다.
시리즈를 닫으며
"에이전트에게 위임하되, 되돌릴 수 없는 변경은 사람이 서명한다." 이 원칙 하나가 3편 시리즈의 공통분모였다. 코드는 Git, DB는 마이그레이션, 결정적 변경은 사람 검수. 생태계를 가리지 않는 세 원칙이다.
로드맵은 처방전이 아니라 출발점이다. 팀마다 기술 스택이 다르고 위험 허용 범위가 다르다. 4주 안에 완성되지 않아도 괜찮다. 중요한 건 방향이다. 장벽이 높은 곳에서 멈추고 있다면, 그 장벽이 "도구가 없어서"인지 "연결이 안 돼서"인지를 먼저 가려내는 것. 대부분은 후자다.