병목은 코드 작성에서 검증으로 이동했다. CI도 이에 맞춰 에이전트가 실행하는 곳에서, 빠르게 돌아가야 한다.
URL: https://tuananh.net/2026/02/05/shifting-left-of-ci/
Title: CI의 시프트 레프트(Shifting Left)
병목은 코드 작성에서 검증으로 이동했다. CI도 그에 맞춰 이동해야 한다: 에이전트가 실행되는 곳에서 돌아가야 하고, 빠르게 돌아가야 한다.
어디서나 같은 패턴이 보인다. AI 코딩 에이전트가 효과적으로 일할 수 있도록, 우리는 시스템을 설계하는 방식과 CI를 운영하는 방식, 그리고 전반적인 빌드 방식까지 바꾸고 있다. 몇 주 전에 나는 그중 한 측면 (일회용 소프트웨어를 위한 아키텍처)에 대해 썼다. CI를 왼쪽으로 당기는(shifting left) 것도 또 다른 측면이다.
우리가 원하는 것은 촘촘한 피드백 루프다. 에이전트가 변경을 만들고, 로컬에서 CI를 실행해, 통과/실패 신호를 받고, 조정한다. 푸시도 없고, 원격 파이프라인을 기다릴 필요도 없다. 백 마디 말보다 그림 한 장이 낫다. 여기 하나.
예전에는 우리가 AI를 보조 도구로 썼다. 이제는 AI 에이전트가 더 효과적으로 일할 수 있도록 모든 것을 최적화하고 있으며, 병목이 이동했다.
이전에는 코드를 작성하고 Git(또는 어떤 소스 컨트롤이든)에 푸시한 뒤 CI가 돌기를 기다리는 것이 괜찮았다. 대부분의 시간은 여전히 코딩에 쓰였으니, 몇 분의 피드백 지연은 받아들일 만했다.
하지만 지금은 코딩이 가장 큰 문제가 아니다. 우리는 더 빠른 피드백을 원한다. 더 정확히는: 에이전트가 원격 파이프라인과의 왕복 때문에 컨텍스트와 시간을 태우지 않고 반복(iterate)할 수 있도록 더 빠른 피드백이 필요하다.
완전 자율 에이전트에게 CI가 중요하다는 데에는 모두 동의한다. 질문은 CI가 어디서 돌아야 하는지, 그리고 얼마나 빠르게 돌아야 하는지다.
1. 에이전트는 CI를 스스로 실행할 수 있어야 한다.
기존 CI(클라우드에서, 머지 시점에, 등)는 여전히 있어야 한다. 클라이언트 측 검증과 서버 측 검증으로 비유해보자. 클라이언트 측 체크를 추가했다고 해서 서버 측 검증을 없애지는 않는다. 로컬(또는 에이전트 실행) CI는 “클라이언트 측” 체크이고, 파이프라인 CI는 진실의 원천(source of truth)이자 최종 게이트로 남는다. 에이전트가 푸시 전에 로컬에서 동일한(또는 동등한) 체크를 실행할 수 있으면, 빌드를 망가뜨리는 횟수가 줄고 우리가 설정한 경계 안에서 작업할 수 있다.
2. 빠르게 돌아야 한다. 정말로 빠르게.
병목이 “코드 작성”에서 “코드 검증”으로 옮겨가면, 느린 CI는 에이전트 처리량(throughput)에 대한 단단한 상한이 된다. 에이전트는 같은 세션 안에서 상태를 잃지 않고 여러 시도를 하고, 빨강/초록 신호를 받고, 조정해야 한다. 몇 분짜리 파이프라인은 그 루프에서는 성립하지 않는다.
목표 1(에이전트가 파이프라인에서 보게 될 것과 동일하거나 동등한 체크로, 스스로 CI를 실행하는 것)은 Dagger가 정확히 겨냥하는 문제다. 어디서나 실행 가능한 코드로서의 CI(CI as code): 개발자 머신에서든, 에이전트 샌드박스에서든, 클라우드에서든. 같은 파이프라인 정의, 다른 실행 환경. 이렇게 하면 하나의 명세로 “클라이언트 측”과 “서버 측” 검증을 모두 갖출 수 있다.
목표 2(속도)는 Bazel과 그 주변 생태계가 빛나는 지점이다. 헤르메틱 빌드, 캐싱, 최소 재계산(minimal recomputation)은 바뀐 것만 돌리게 해준다. 작은 범위의 타깃 수정만 하는 에이전트라면, 10분짜리 빌드가 30초가 되기도 한다. 검증이 병목일 때 이런 도구는 선택 사항이 아니라 필수가 된다.
예를 들어 OpenAI의 Codex는 Bazel을 사용해 빌드 시간을 9분에서 1분 조금 넘는 수준으로 줄였다:
시프트 레프트는 원래 버그를 더 일찍 찾기 위한 방법으로 시작했다. AI 시대에는, 파이프라인이라는 안전망을 없애지 않으면서도 에이전트가 안전하고 빠르게 일하게 만드는 방법이기도 하다. 원리는 같고, 신경 써야 할 이유만 새로워졌다.
