에이전트가 생성한 코드를 책임감 있게 다루기: Vercel의 프레임워크

3 hours ago 1

코딩 에이전트는 전례 없는 속도로 코드를 생성하지만, 엄격한 판단 없이 사용하면 잘못된 가정을 그대로 프로덕션에 배포하는 효율적인 경로가 됨
에이전트가 생성한 코드는 PR 설명, 정적 분석 통과, 테스트 커버리지까지 갖춰 경험 많은 엔지니어가 작성한 것처럼 보이지만, 실제 프로덕션 환경의 트래픽 패턴·장애 모드·인프라 제약은 전혀 반영하지 못함
AI를 활용(leveraging) 하는 것과 의존(relying) 하는 것은 근본적으로 다르며, 진정한 활용이란 에이전트 출력물의 동작 방식과 위험을 완전히 이해하고 소유하는 것을 의미함
자기 구동 배포, 지속적 검증, 실행 가능한 가드레일이라는 세 가지 원칙으로 에이전트가 높은 자율성으로 행동하면서도 안전한 환경을 구축할 수 있음
코드를 가장 많이 생성하는 엔지니어가 아니라, 무엇을 배포할지에 대한 냉철한 판단력을 유지하는 엔지니어가 살아남는 시대가 되었음

문제: Green CI는 더 이상 안전의 증거가 아님

CI 통과는 단지 에이전트가 파이프라인을 설득하는 능력을 반영할 뿐, 실제 인프라 안전성과는 무관
- 테스트를 통과하지만 프로덕션에서 전체 행을 스캔하는 쿼리 배포 가능
- 정상적으로 보이는 재시도 로직이 다운스트림 서비스에 Thundering Herd 유발 가능
- TTL 없는 캐시가 Redis를 조용히 죽음에 이르게 할 수 있음
에이전트는 Redis 인스턴스 용량 상태, DB의 특정 리전 하드코딩 여부, 피처 플래그 롤아웃이 다운스트림 시스템 부하 프로파일을 변경한다는 사실 등을 알지 못함
"이 PR이 올바르게 보인다"와 "이 PR을 안전하게 배포할 수 있다" 사이의 간극은 항상 존재했으며, 에이전트는 이 간극을 더 벌려놓음

의존(Relying): 에이전트가 작성하고 테스트가 통과하면 배포 준비가 됐다고 가정하는 방식
- 작성자가 변경 사항에 대한 멘탈 모델을 구축하지 않음
- 작성자도, 리뷰어도 코드가 실제로 무엇을 하는지 파악하지 못한 채 숨겨진 가정으로 가득 찬 거대한 PR이 생성됨
활용(Leveraging): 에이전트를 빠른 반복에 활용하면서 출력물에 대한 완전한 소유권을 유지하는 방식
- 코드가 부하 하에서 어떻게 동작하는지 정확히 파악
- 관련 위험을 이해하고 감수할 의지가 있음
PR에 이름을 올린다는 것은 "읽었고 무엇을 하는지 이해한다"는 의미이며, 이것이 엔지니어링 프로세스의 기준점

단순 테스트: "이 PR과 연결된 프로덕션 인시던트를 소유하는 것이 편안한가?"
PR을 올리기 전에 스스로에게 질문해야 할 세 가지
- 이 코드가 무엇을 하는가? 롤아웃 후 어떻게 동작하는가?
- 프로덕션이나 고객에게 어떤 부정적 영향을 미칠 수 있는가?
- 이 코드와 연결된 인시던트를 소유하는 것이 편안한가?
"예스"라면 AI를 활용한 것이므로 배포, "노"라면 아직 더 해야 할 작업이 있음

자기 구동 배포(Self-driving deployments): 모든 변경 사항은 게이티드 파이프라인을 통해 점진적으로 롤아웃되며, 카나리 배포가 성능 저하 시 자동 롤백
- 엔지니어가 대시보드를 감시하는 방식에 의존하지 않음
- 문제 발생 시 전체가 아닌 트래픽 일부에서만 격리되어 처리됨
지속적 검증(Continuous validation): 배포 시점만이 아니라 상시 인프라 자체 테스트 수행
- 부하 테스트, 카오스 실험, 재해 복구 훈련이 지속적으로 실행됨
- Vercel이 지난 여름 프로덕션에서 리허설한 데이터베이스 페일오버가, 실제 Azure 장애 발생 시 고객에게 아무 영향이 없었던 이유
실행 가능한 가드레일(Executable guardrails): 운영 지식을 문서가 아닌 실행 가능한 도구로 인코딩
- safe-rollout 스킬은 피처 플래그 작동 방식을 설명하는 Notion 페이지가 아니라, 플래그를 연결하고 롤백 조건이 있는 롤아웃 플랜을 생성하며 예상 동작 검증 방법을 명시하는 도구
- 가드레일이 실행 가능할 때, 에이전트는 자율적으로 이를 따르고 사람은 이를 암기할 필요가 없음