AI 코딩으로 병목이 된 CI, 개발 속도에 맞춰 재설계함

다들 너무 빠르게 달리다가 코드 검토, CI, 제품 요구사항 같은 벽에 계속 부딪히는데, 정작 제품은 왜 나아지지 않는지 늘 궁금함.
글과 토론만 보면 1990년대 월스트리트 사무실처럼 정신없이 돌아가지만, 새 Android와 iPhone에는 평소보다 새 기능이 적고, 개인 개발자가 Linux급 대안 운영체제를 내놓지도 않으며, Switch 2는 여전히 뚫리지 않았고, Windows는 우클릭 메뉴 하나 띄우는 데 3초가 걸림. 다들 제자리에서 전력 질주하는 건가?

우리 회사에서는 AI로 그동안 손대지 못했던 기술 부채와 손쉬운 개선 과제를 처리하고, 내부 절차를 개선·자동화하는 데 상당한 시간을 쓰고 있음. 서비스 품질과 가용성에도 직접적인 효과가 나타남.
출시를 자주 막던 QA는 이제 더 깊이 검토하고 더 일찍 결함을 잡으며, 일정이 밀리는 작업을 먼저 찾아 나설 정도로 여유가 생김. 보안 경보와 운영 로그를 정비하고 테넌트 격리를 개선해 고객 감사와 공식 감사도 훨씬 수월해짐.
사람이 어려운 개발에 집중할 기반을 마련하는 과정임. 개발 환경과 인프라가 빨라지고 깔끔해졌으며, 감사가 쉬워지고 운영비도 내려감. 이런 변화는 대부분 변경 이력이나 새 기능으로 드러나지 않지만, 내부 생산성과 고객 만족도는 올라가고 운영 장애는 줄어듦. 다만 지금까지의 비용 절감액이 AI 지출을 상쇄할 정도는 아님.

PS5 에뮬레이션은 거의 작동하지 않던 수준에서, 그래픽 오류가 사실상 없이 Dark Souls를 10 FPS 이상으로 돌리는 수준까지 6주 만에 발전함. 일반적인 에뮬레이터 개발 속도를 생각하면 놀라운 진전이며, 디컴파일을 비롯한 관련 분야에서도 엄청난 발전이 있었음.
모두 이 속도를 대규모 제품 기능 개발로 연결하는 방법을 찾는 중이지만, 대기업은 힘은 세도 방향 전환이 느린 컨테이너선과 같음. 작은 회사는 이를 활용해 더 좋은 제품을 훨씬 빨리 만들 수 있음. 단기적으로는 너무 많이, 장기적으로는 너무 적게 기대하는 듯함. AI 중심 기업이 안정적으로 실행하는 방법을 찾으면 기존 기업의 시장을 가져갈 것임.

작년에는 “AI가 그렇게 좋다면 새 앱은 어디 있느냐”고 했는데, 2026년 자료를 보니 iOS App Store 신규 앱 제출이 전년 대비 84% 증가함.
대안 운영체제도 내가 본 사례가 하나 있고, 아마 더 있을 것임. 우클릭 메뉴 같은 대기업 프로젝트는 여러 겹의 조직적 비효율 때문에 개선이 아주 느릴 수밖에 없으며, 코딩 속도만 높여서는 해결되지 않음.
AI로 새 기능을 만드는 일보다 기존 프로젝트를 개선하는 일이 더 어려움. 후자도 점차 방법을 찾겠지만 시간이 더 필요함.

실리콘밸리 기업들이 개발자를 수천 명 고용하고도 소수가 만든 초기 제품을 크게 개선하지 못했던 것과 같은 이유일 듯함. 인원 확대는 투자 유치 수단이었고, 이후에는 모두에게 시킬 일을 찾아야 했음.
그러다 보니 HTML과 스타일시트면 될 일을, 1995년부터 있던 버튼을 만들겠다고 실행 시점에 JSON으로 정의한 CSS 렌더링 엔진까지 만들게 됨. AI의 코드 생산 속도도 쓸모는 있겠지만, 과잉 설계와 불필요한 토큰 소비에 빠지기 쉬움. 그런 코드를 보고 배웠으니 당연할지도 모름.
작업량은 많아도 주력 제품에 미치는 영향은 크지 않을 것 같음. 이전에는 불가능했을 개인의 열정 어린 프로젝트가 늘어나는 건 멋지지만, 실리콘밸리 기술 기업들이 갑자기 실용적이고 효율적으로 변하리라 기대하지는 않음.

우리도 LLM 덕분에 시스템을 크게 개선함. 데이터 추출·PDF 경계 상자 알고리즘을 다시 작성하면서 결과를 시각화하고 적절한 규칙을 찾는 도구를 만들었고, GPU가 필요하던 6GB짜리 SciBERT Docker 컨테이너를 CPU에서 실행되는 약 900MB ONNX 추론 컨테이너로 전환함. Nomad를 대체할 K3S 클러스터를 구축했으며, SQLite 인덱스와 쿼리를 개선해 관련 알고리즘 성능도 60~80% 높임.
특정 영역의 자원 사용량이 크게 줄었음. 원래도 가능한 작업이었지만, LLM이 반복 개선에 필요한 도구를 제공하면서 예전에는 엄두를 내기 어려웠던 시간과 비용 안에 완수할 수 있게 됨.
그렇다고 사용자가 혜택을 체감하고 제품이 마법처럼 좋아지는 건 아님. 그쪽 업무에 관여하지 않아 모른다는 답도 가능하지만, 더 현실적으로는 사용자 경험과 제품 적합성이 LLM만으로 풀 수 있는 영역이 아니기 때문임. 그건 여전히 사람이 찾아야 하며, “아무것도 나아지지 않았다”는 느낌도 거기서 비롯되는 듯함.

연초 이후 테스트 묶음이 거의 네 배가 됐다는데, 테스트가 만든 가치도 네 배가 됐는가?

알 수 없음. 테스트가 잡아서 운영 환경에 나가지 않은 버그가 회사에 얼마를 아껴줬을까? 그런 버그가 많았다면, 혹은 하나도 없었다면 어떨까? 개발자가 테스트 실행을 기다리느라 잃은 시간도 계산해야 함.

내 경우 병목은 CI가 아니라 사람이 하는 검증임. 작동은 하더라도 정말 우리가 원하는 일을 하는지, 더 중요하게는 고객이 이해하고 좋아할 방식으로 동작하는지 확인해야 함.

너무 뻔한데도 아무도 이 부분을 이야기하지 않는 듯함. 올바른 문제를 풀고 있는지에는 관심이 없고, 코드만 밀어 넣어 수치를 높이려 함.

LLM이 코딩과 소프트웨어 개발을 일단 최대한 던져 보고 되는 것만 남기는 방식으로 바꿔놓은 듯함. 특히 인류가 에너지 생산과 소비를 개선해야 한다는 점을 생각하면 근시안적이고 낭비가 심해 보여 씁쓸함.

계층별 문제로 보면 됨. 하위 계층인 CI가 에이전트의 산출량을 따라가지 못하면, 사용자 경험 검증 같은 상위 계층의 문제 해결은 기하급수적으로 느려지고 신뢰성도 낮아짐. 자주 실행되는 내부 반복문을 최적화하면 전체 프로그램이 빨라지는 것과 비슷함.

고객이 이해하고 좋아하는지가 가장 중요함. 제품 관리는 전혀 자동화되지 않았고, 오히려 어느 때보다 중요해짐. 기능만 계속 추가한다고 좋은 제품이 되지는 않음.

그 논리라면 낡은 인간 테스터를 에이전트형 AI 테스터로 바꾸면 되겠음. 그러다 변화와 새 기능을 배우는 속도가 따라가지 못하는 인간 사용자까지 병목이 되면, 사용자도 에이전트형 AI로 교체하면 되겠네.

더 빠른 CPU와 스토리지, 나은 캐시 인프라를 갖춘 외부 실행기로 옮겼더니 빨라졌다는 대목은 놀랍지 않음. GitHub Actions는 GitHub를 이미 쓴다면 편리하지만 꽤 느리기도 함. 요즘 GitHub의 안정성도 큰 문제라, 다른 파이프라인으로 옮기는 조직이 늘 것 같음.

Azure에서 실행하지 않았다면 GitHub Actions가 얼마나 빨라졌을지 궁금함. Azure는 느리거나 아주 비싸기 때문임.

Actions 작업을 blacksmith.sh로 옮겼는데 속도와 저렴한 비용 모두 꽤 만족스러움. 해당 업체와 이해관계는 없으며, 이런 흐름은 계속될 듯함.

Linear는 진작 완성돼 더할 기능도 없으니 AI 코딩이 느려도 되겠다고 생각했는데, 지금은 다음 Jira가 되느라 바쁜 모양임.

Linear의 변화에는 마음이 복잡함. 싫은 기능도 있지만 전반적으로 쓰기 좋은 상태를 유지하고 있고, Jira처럼 변한다고 느끼지는 않음. 다만 코드 생성이 저렴해지면서 세심한 제품 설계가 사라지는 느낌임. Jira가 될까 걱정되기보다는 고유한 정신을 잃은 듯하며, 그래도 여전히 훌륭한 제품임.

소프트웨어는 낡고 거대한 기존 제품과 달리 새롭고 빠르고 단순해서 인기를 얻음. 그러다 계속 커져 자신이 새로운 거대 제품이 되고, 같은 순환이 다시 시작됨.

훨씬 작은 규모에서 GitLab 무료 요금제와 자체 호스팅 실행기를 최적화하는 1인 개발자로서 가장 크게 와닿은 건, 이 회사가 연간 반복 매출 1억 달러, 기업가치 10억 달러 이상에 이르기 전까지 이런 것들을 걱정하지 않았다는 점임.
근거는 Linear의 성장 공유 글에 있음.

초기 구축 비용을 감당할 수 있다면 Bazel로 대규모 프로젝트도 캐시가 채워진 상태에서 약 10초 빌드가 가능함.

몇 년 전, 5개 이상의 언어로 작성되고 주요 운영체제 3종에 네이티브 바이너리를 배포하는 복잡한 소프트웨어의 Bazel 전환을 이끌었는데 몇 년이 걸림.
이번에는 언어가 하나인 덜 복잡한 프로젝트였지만 역시 운영체제 3종을 지원했고, 내 지식과 에이전트를 활용해 2주 만에 전환함. Bazel의 초기 구축 비용은 크게 낮아졌는데, 업계 전반은 아직 이를 잘 모르는 듯함.

Bazel 자체는 모르지만 nx와 turbo를 써보니 병목은 연산보다 네트워크와 디스크 IOPS인 경우가 대부분이었음. 관리형 CI에서는 완전히 캐시된 결과도 원격 서버에서 가져와 읽어야 하고, 여러 언어의 프런트엔드·백엔드 조합에서는 앞 단계 결과를 디스크에 쓴 뒤 다음 단계에서 다시 읽어야 함.
Bazel이 흔한 Java/C++ 환경에서는 10초가 현실적일 수 있지만, TypeScript의 제법 큰 모노레포라면 1~2분만 돼도 크게 기뻐할 것임.
여기서 빌드가 변환·컴파일만 뜻하는지, Linear 글처럼 테스트까지 포함하는지 명확히 해야 함. 가상 DOM이나 실제 브라우저가 필요한 대규모 테스트 묶음은 일부만 실행해도 10초 안에 끝내기 어려워 보임.

Bazel에도 절충점이 많음. 작업마다 샌드박스를 준비하는 시간이 들고, 사용 편의성 때문에 기존의 일반적인 도구 체계도 병행 유지하게 됨.
“캐시가 채워진 상태”라는 조건도 큰 비중을 차지함. 일주일간 개발할 때 실제 캐시 적중률은 얼마인가? Bazel이든 다른 증분 빌드 도구든 캐시 없는 빌드와 자주 실행하는 작업을 개선하는 투자는 여전히 중요함.
실제 성능과 동작은 사용하는 규칙에 달려 있어 Bazel을 뭉뚱그려 이야기하기 어려움. turbo/nx처럼 package.json 모듈별로 tsc/vitest/eslint를 캐시하면 변경마다 무효화되는 큰 단위가 되고, gazelle로 파일별 작업을 구성하면 의존성이 바뀔 때만 무효화할 수 있음. 다만 후자는 워커를 쓰지 않으면 일괄 처리의 이점을 잃게 됨.

시스템은 더 작고, 더 격리되고, 계약 중심으로 바뀌어야 할 듯함. 오랫동안 모놀리스를 지지했지만, 에이전트에는 작고 독립적인 서비스가 더 잘 맞아 보임.
서비스 구성요소 사이에는 계약만 두고, 이를 만족하는 한 내부에서 계속 개선하도록 하면 됨. 필요하다면 계약에 버전을 붙여 계속 발전시킬 수 있음.

마이크로서비스는 여전히 좋지 않음. 원하는 건 모듈형 모놀리스, 또는 대부분의 처리를 도메인 라이브러리에 두는 FaaS임.

개발 속도와 커밋 빈도, 저장소에 추가되는 내용이 늘어나는 만큼, CI/CD 수요가 많은 기업은 사내 장비에서 CI/CD를 직접 운영하는 방안을 검토할 만함.
내 경험에서는 실행기를 자체 호스팅하는 것이 비용 절감에 가장 큰 효과가 있었고, 더 강력한 장비를 쓸 수 있어 실행 시간도 바로 줄어듦.

에이전트 기반 코딩이 CI에 큰 부담을 주고 있음. 빌드 시간을 줄이려고 Bazel을 사용했고, 결국 CI 개선을 위한 맞춤형 실행기까지 만들고 있음.

여전히 의외임. 코딩 에이전트가 등장하기 전후를 통틀어 내가 참여한 프로젝트 대부분은 로컬에서 테스트를 돌리면 CI/CD 검증의 최소 90% 는 끝나도록 나와 동료들이 충분히 준비했음.
다만 대체로 서비스 하나를 한 번에 한 사람이 맡아 변경이 덜 겹쳤고, 서비스 간 계약도 잘 잡혀 있었음. 로컬 장비가 CI 장비보다 훨씬 좋아서, 2~10배 오래 걸리는 CI를 기다리기보다는 로컬에서 실행할 유인도 컸음.