에이전트 시대에 CI 대신 병합 큐를 사용해야 하는 이유와 이를 도입하는 방법을 설명합니다.
오늘날 CI의 표준은 커밋이 병합된 뒤 클라우드에서 테스트를 실행하는 것입니다. 이는 엔지니어를 위한 이중 점검 역할을 합니다. 변경한 코드의 어떤 부분을 테스트하지 않은 채 잊어버렸는가?
CI는 인간에게는 작동합니다. 그 이유는 코드베이스와 그 진화에 대한 장기적인 이해가 있기 때문입니다. 코드베이스에 새로 온 엔지니어는 자신이 새롭다는 것을 알고 더 주의합니다(혹은 CI를 망가뜨렸다는 자동 이메일을 받습니다). 코드베이스에 익숙한 인간은 작업하면서 무엇을 테스트해야 하는지 암묵적으로 알고 있습니다.
CI의 자동 이메일이 작동하는 이유는 그것이 드물고, 우리 모두 인간의 속도로 개발하며, 잠시 동안 HEAD가 망가져도 괜찮기 때문입니다. 일부 팀은 CI 실패 시 자동 되돌리기를 시도합니다. 이것도 작동하지만, 지속적인 재시도 속에서 사후 테스트가 제공하는 가치의 상당 부분을 잃게 됩니다. 그래도 작동합니다. 야간 빌드와 원인을 찾기 위한 이진 탐색보다는 낫습니다.
에이전트에게는 작동하지 않습니다. 적어도 2026년 6월 기준으로는 그렇습니다.
여기에는 두 가지 문제가 있습니다. 첫 번째는 에이전트가 언제나 코드베이스에 새로 온 존재라는 점입니다. 이들은 코드베이스 전문가가 가진 모든 암묵적 지식을 갖고 있지 않으므로, 주의를 기울이지 않은 프로젝트 부분을 항상 회귀시킵니다. 에이전트와 CI를 함께 사용해 개발하는 일은 몹시 고통스럽습니다. 에이전트가 환경을 이해하고 있는지 확인하려면 개발하는 동안 모든 테스트를 실행해야 합니다.
두 번째 문제는, 안타까운 인간 조작자가 CI를 망가뜨렸다는 자동 이메일을 받게 될 때쯤이면 에이전트의 컨텍스트 윈도우는 이미 끝나 사라졌다는 점입니다. 에이전트는 그 문제를 다른 사람의 문제로 만들기 전에 조용히 해결했어야 합니다. 누구의 길도 막지 않는 한, 에이전트에게는 얼마든지 시간이 있습니다. 컴퓨터가 컴퓨터를 운전하게 하세요.
따라서 조직을 에이전트가 항상 모든 테스트를 실행할 수 있는 상태로 만들어야 합니다. 이를 위한 쉬운 방법이 있습니다. CI를 병합 큐로 대체하세요.
병합 큐는 origin/main에 푸시하기 위해 실행하는 스크립트입니다(예전 GitHub의 모든 사람이 인간이던 시절처럼 PR UI를 사용하는 대신에 말입니다).
병합 큐에서는 모든 테스트를 실행하는 것이 매우 중요합니다. 매일 실행하는 "느린" 테스트를 두지 마세요. 에이전트 시대에는 그런 테스트가 매일 망가질 것입니다. 누군가는 매일 몇 시간씩 다른 사람의 에이전트를 뒤쫓게 됩니다. 이는 팀의 누구도 원하지 않는 역할입니다. 다른 사람 뒤를 정리하는 것보다 더 나쁜 유일한 일은 다른 사람의 로봇 뒤를 정리하는 일이라는 사실이 드러났습니다.
작동하는 병합 큐를 만든 뒤에는 실제 병합을 제외한 병합 큐를 실행하는 두 번째 명령을 만드세요. 그것을 에이전트에게 제공하세요.
이렇게 하면 다음이 보장됩니다:
우리 모두가 인간이었고 CI가 느리던 시절에는 병합 큐 대신 CI를 써야 한다는 주장을 할 수 있었습니다. 그런 주장은 테스트가 병합 경로에 넣기에는 너무 느리다는 전제에 의존했고, 2026년에는 성립하지 않을 것입니다. 에이전트를 사용하려면 테스트가 빨라야 합니다. 이제는 불가능합니다. 에이전트와 함께라면 CI는 쓸모없고, 병합 큐가 압도적으로 우수합니다.
병합 큐를 구동하려면 비싼 컴퓨터가 필요할 것입니다. 그만한 가치가 있습니다.
