에이전트, 책임 있게

이 글은 Vercel 내부 발표를 바탕으로 작성되었다. 여기서 다루는 문제가 Vercel만의 이야기가 아니며, 이 프레임워크가 에이전트와 함께 배포하는 모든 팀에 유용하다고 판단해 공개한다.

코딩 에이전트는 전례 없는 속도로 코드를 만들어낸다. 규율 있는 엔지니어의 손에서는 생산성을 몇 배로 높여주는 도구가 된다. 하지만 엄격한 판단 없이 사용하면, 잘못된 가정을 프로덕션에 곧장 배포하는 데 최적화된 수단으로 전락한다.

에이전트가 생성한 코드를 검토 없이 배포했을 때의 결과는 즉각적이고 치명적일 수 있다. 완벽해 보이는 풀 리퀘스트가 테스트는 통과하지만 프로덕션에서 전체 행을 스캔하는 쿼리를 심어놓을 수 있다. 올바르게 보이는 재시도 로직이 하위 서비스에 대규모 요청 폭주를 일으킬 수 있다. TTL 없는 캐시는 조용히 불어나다가 결국 Redis를 죽일 수 있다.

CI 통과는 더 이상 안전의 증거가 아니다. 에이전트 중심의 세계에서 CI를 통과했다는 것은, 에이전트가 파이프라인을 설득하는 데 성공했다는 뜻일 뿐이다. 실제로는 배포 즉시 인프라를 무너뜨릴 변경사항이라도 말이다.

근거 없는 자신감

에이전트가 생성한 코드는 위험할 만큼 설득력이 있다. 잘 다듬어진 PR 설명과 함께 제출되고, 정적 분석을 통과하며, 저장소 컨벤션을 따르고, 적절한 테스트 커버리지까지 갖추고 있다. 겉으로 보면 숙련된 엔지니어가 작성한 코드와 다를 바 없다.

하지만 에이전트는 실제 프로덕션 환경을 이해하지 못한다. 트래픽 패턴도, 장애 양상도, 공유 인프라의 암묵적인 제약도 알지 못한다. Redis 인스턴스가 한계치에 가까워지고 있다는 사실도, 데이터베이스가 특정 리전에 고정되어 있다는 사실도, 피처 플래그(feature flag) 롤아웃이 하위 시스템의 부하 패턴을 근본적으로 바꿔놓을 수 있다는 사실도 모른다.

"이 PR은 올바르다"와 "이 PR은 배포해도 안전하다" 사이의 간극은 언제나 존재했다. 에이전트는 그 어느 때보다 흠잡을 데 없어 보이는 코드를 만들어내면서도 프로덕션 현실에는 철저히 무지하다. 그 간극이 지금 더욱 넓어지고 있다.

활용과 의존

AI를 활용하는 것과 의존하는 것은 근본적으로 다르다.

• 의존은 에이전트가 코드를 작성하고 테스트가 통과했으면 배포할 준비가 됐다고 간주하는 것이다. 작성자는 변경사항에 대한 멘탈 모델을 끝내 형성하지 못한다. 그 결과는 숨겨진 가정으로 가득 찬 거대한 PR이다. 작성자도 리뷰어도 코드가 실제로 무엇을 하는지 파악하지 못한 채, 리뷰 자체가 불가능한 상황이 된다.

• 활용은 결과물에 대한 완전한 오너십을 유지하면서 빠르게 반복하는 데 에이전트를 쓰는 것이다. 코드가 부하 상황에서 어떻게 동작하는지 정확히 파악하고, 관련 리스크를 이해하며, 그 책임을 기꺼이 진다.

풀 리퀘스트에 이름을 올린다는 것은 "나는 이 코드를 읽었고 무엇을 하는지 이해한다"는 선언이다. 자신이 열었던 PR을 다시 읽어봐야만 프로덕션 영향을 설명할 수 있다면, 이미 엔지니어링 프로세스가 실패한 것이다.

판단 기준은 간단하다. 이 풀 리퀘스트와 연결된 프로덕션 장애를 책임지는 데 거리낌이 없는가?

프로덕션을 지키는 법

답은 에이전트 사용을 중단하는 것이 아니다. 생산성 향상 효과는 부정할 수 없고, 모델은 계속 발전할 것이다. AI 기반 코드 리뷰와 분석은 인간이 놓치는 버그를 잡아내고 리스크를 드러내는 강력한 도구다.

하지만 리뷰에만 의존하는 것, 사람이든 AI든, 은 폭증하는 에이전트 생성 코드 앞에서 결국 지는 싸움이다. 우리는 이미 구현이 넘쳐나는 변곡점을 지나고 있다. 이제 희소한 자원은 코드를 작성하는 능력이 아니라, 무엇을 배포해도 안전한지 판단하는 능력이다. 모든 인프라는 이 새로운 현실에 맞게 변해야 한다.

개발 생명주기를 복잡한 절차로 옭아매자는 이야기가 아니다. 에이전트가 높은 자율성으로 행동할 수 있도록, 환경은 표준화되고 검증은 쉬우며 배포는 기본적으로 안전한 폐쇄 루프 시스템을 구축하자는 것이다.

핵심 원칙은 단순하다. 올바른 일을 하는 것이 쉬워야 한다.

자동화된 배포. 모든 변경사항은 단계별 게이트를 통과하며 점진적으로 롤아웃된다. 카나리(canary) 배포에서 성능 저하가 감지되면 롤아웃이 멈추고 자동으로 롤백된다. 엔지니어가 대시보드를 지켜볼 필요가 없다. 시스템이 문제를 포착하고, 전체 트래픽이 아닌 일부에만 영향을 가두고, 되돌린다. 무언가 잘못될 때는 전역이 아닌 격리된 범위에서 잘못된다.

지속적인 검증. 인프라는 배포 시점만이 아니라 상시 스스로를 테스트한다. 부하 테스트, 카오스 엔지니어링(chaos engineering) 실험, 재해 복구 훈련이 상시 운영된다. Vercel에서 지난 여름 프로덕션에서 반복적으로 훈련했던 데이터베이스 장애 전환 덕분에, 올해 실제 Azure 장애가 발생했을 때 고객들은 아무것도 체감하지 못했다. 압박 속에서도 버티는 시스템은 의도적으로 스트레스를 받아본 시스템이다.

실행 가능한 가드레일. Vercel에서는 운영 지식을 문서가 아닌 실행 가능한 도구로 만들고 있다. safe-rollout 스킬은 피처 플래그 작동 방식을 설명하는 Notion 페이지가 아니다. 플래그를 연결하고, 롤백 조건이 포함된 롤아웃 계획을 생성하고, 기대 동작을 검증하는 방법을 명시하는 도구다. 가드레일이 실행 가능한 형태일 때, 에이전트는 스스로 그것을 따르고 사람이 일일이 외울 필요도 없어진다.

최종 목표는 엔지니어가 모든 변경사항에 특별한 주의를 기울이는 세상이 아니다. 인프라 자체가 엄격한 세상이다. 시스템이 폭발 반경을 제한하고, 지속적으로 검증하며, 우아하게 성능을 저하시키고, 모범 사례를 실행 가능한 기본값으로 담아낼 때, 빠른 배포가 기본적으로 안전해지는 세상이다.

우리가 투자하고 있는 것

이론에서 그치지 않는다. 핵심 플랫폼 팀이 공유 인프라에 이 가드레일을 직접 구축하고 있다.

• 공유 인프라 전반에 걸쳐 강화된 가드레일, 그리고 배포 파이프라인의 모든 단계에서 런타임 검증 적용

• PR 단계에서 더 엄격한 정적 검사 적용, 특히 피처 플래그 관련 영역

• 스테이징 환경에서 프로덕션을 그대로 모방하는 엔드투엔드(end-to-end) 테스트

• 프로덕션에서 시스템 불변 조건을 상시 검증하는 읽기 전용 에이전트, 그리고 생성 에이전트의 가정을 감사하는 전문 에이전트 운영

• 결함-커밋 비율과 결함-이탈 비율 같은 지표를 통해 플랫폼 전반의 리스크 증가 여부를 파악

에이전트를 활용하되, 리스크는 직접 진다

우리의 기준은 명확하다. 에이전트를 활용하되, 의존하지 않는다.

예전에는 품질이 낮은 코드가 눈에 띄었다. 지금은 아니다. AI 도구는 앞으로도 계속 강력해질 것이다. 코드 변경의 규모는 커지고, 코드는 더 그럴듯해 보이며, 결과물을 맹목적으로 신뢰하고 싶은 유혹도 커질 것이다. 앞으로 살아남는 엔지니어는 가장 많은 코드를 만들어내는 사람이 아니다. 무엇을 배포할지에 대해 냉철한 판단력을 끝까지 유지하는 사람이다.

다음 PR을 열기 전에 스스로에게 물어보라.

• 이 코드는 무엇을 하는가? 롤아웃되면 어떻게 동작하는가?

• 프로덕션이나 고객에게 어떤 악영향을 줄 수 있는가?

• 이 코드와 연결된 장애를 내가 책임질 수 있는가?

세 질문에 모두 그렇다고 답할 수 있다면, 당신은 AI를 활용하고 있다. 배포하라.

아니라면, 아직 할 일이 남아 있다.