한 엔지니어링 팀은 2021~2025년 평균 대비 분기당 8배 많은 코드를 출하하고 있다고 자랑스럽게 발표한다. 동시에 다른 곳에서는, 어떤 고성능 AI 모델이 “너무 철저하다”는 이유로 실무에서 오히려 불편하다는 이야기가 나온다. 속도는 폭발적으로 올랐는데, 안심할 수 있는 신뢰는 그 속도를 따라가지 못하고 있다. 이게 지금 AI 소프트웨어 개발의 핵심 긴장이다.
속도가 빨라졌다는 건 무엇을 의미하는가
8배라는 숫자 자체보다 그 숫자가 어떻게 만들어졌는지가 더 흥미롭다. 단순히 더 많은 코드를 AI가 대신 작성해준 게 아니다. 조직이 AI를 쓰는 방식 자체가 바뀌었다. 매니저는 “Claude 루틴”이라고 부르는 방식으로 맥락을 관리하고, 엔지니어들은 에이전트에게 서브태스크를 분산시킨다. 이건 도구가 바뀐 게 아니라 일하는 단위 자체가 바뀐 거다.
여기서 나오는 한 가지 재밌는 질문이 있다. 인간이 동시에 집중할 수 있는 에이전트의 수는 몇 개일까? 한 실무자는 포그라운드 에이전트 4~6개 동시 운영이 현실적인 한계라고 말한다. 그 이상은 컨텍스트 스위칭 비용이 너무 커진다. 결국 AI가 병렬로 달릴 수 있는 속도는, 인간이 조율할 수 있는 폭에 묶인다. 병목이 옮겨간 것이지, 사라진 게 아니다.
동시에 배포 측면에서도 비슷한 패턴이 보인다. 최근 들어 소프트웨어 팀들 사이에서 “롤백보다 롤포워드”라는 원칙이 빠르게 퍼지고 있다. 뭔가 깨지면 이전 버전으로 되돌리는 대신, 수정을 담은 다음 버전을 즉시 올리는 방식이다. 이건 속도를 전제한 설계다. 되돌아갈 여유보다 빨리 고칠 능력이 더 중요해진 세계다.
더 똑똑한 모델이, 꼭 더 유용한 모델은 아니다
이 부분이 꽤 비직관적이다.
최근 출시된 고성능 모델 하나가 벤치마크에서 압도적인 성능을 보였음에도 실무 리뷰에서 혹독한 평가를 받았다. 문제는 능력이 아니었다. 너무 꼼꼼하다는 거였다. 스펙 문서를 쓰면 조밀한 단락이 쏟아져 나와 읽기 힘들고, MVP를 만들어달라고 하면 “최소”라는 말을 너무 문자 그대로 해석해서 실제 고객 가치와 동떨어진 결과를 낸다. 시니어 엔지니어처럼 모든 코너를 조사하고 120% 확신한 뒤에야 뭔가를 내놓으려는 성향이, 오히려 제품 작업의 리듬을 깬다.
이건 꽤 중요한 통찰이다. 지능이 높다는 것과 현재 맥락에 맞는 출력을 낸다는 건 다른 문제다. 실무에서는 “조금 덜 똑똑한 모델이 더 쓸 만한 경우”가 분명히 존재한다. 태스크 복잡도에 모델 지능을 맞추는 것, 즉 작업 유형에 따라 더 싸고 더 빠른 모델을 의도적으로 선택하는 전략이 이제 실질적인 엔지니어링 판단의 영역으로 들어오고 있다.
여기서 비용 문제도 빼놓을 수 없다. 고성능 모델은 입력 토큰당 $10, 출력 토큰당 $50 수준으로 기존 모델의 완전히 다른 가격 구간에 위치하고, 토큰 소비량도 두 배 가까이 많다. 그러니까 “어느 모델을 쓸 것인가”는 이제 기술 선택이자 경제 선택이다.
빠르게 가려면, 먼저 멈춰야 한다는 역설
재밌는 건 가장 빠르게 움직이는 팀들이 공통적으로 하는 말이 있다는 거다. “먼저 멈추고 CI를 고쳤다”는 것.
에이전트가 코드를 쏟아낼수록, 그 코드가 실제로 괜찮은지 확인하는 파이프라인이 더 중요해진다. 한 관점에 따르면, AI 시대에 CI/CD의 핵심은 빌드 시간을 줄이는 것에서 배포 리스크를 줄이는 것으로 이동한다. 인간 개발자가 느린 파이프라인 앞에서 블로킹되는 건 문제지만, AI 에이전트는 느린 파이프라인 옆에서 그냥 기다린다. 컨텍스트 스위칭 비용이 없으니까. 오히려 그 시간 동안 더 촘촘한 테스트를 돌리는 게 맞다.
비슷한 논리가 AI 제품팀에도 적용된다. 에이전트가 코드를 더 많이 생산할수록, 그 품질을 자동으로 측정하는 eval 파이프라인이 팀의 핵심 자산이 된다. 흥미로운 비유가 있다. “eval은 현대판 PRD다.” 기존 PRD가 무엇을 만들어야 하는지를 서술했다면, eval은 성공이 무엇인지를 수치로 정의한다. 구현 방법은 에이전트가 알아서 찾는다. 이게 요즘 잘 굴러가는 AI 팀의 실제 분업 방식이다.
그리고 에이전트가 막히거나 이상한 결과를 낼 때, 가장 효과적인 대응은 세션을 닫고 eval을 개선하는 것이라는 얘기도 나온다. 프롬프트를 더 길게 쓰거나 달래는 게 아니라. 이건 꽤 반직관적인 규율이다.
안전이라는 카드는 누가 어떻게 쥐고 있는가
모든 게 빨라지는 이 흐름 속에서, “안전”이라는 단어가 어떻게 기능하는지도 짚고 넘어갈 필요가 있다.
최근 특정 AI 모델이 수출 규제를 받아 갑작스럽게 서비스가 제한되는 일이 있었다. 흥미로운 점은, 이 사건에 대한 해석이 완전히 갈린다는 거다. “AI가 실제로 어떻게 작동하는지 사람들이 여전히 모른다”는 기술적 무지의 문제로 보는 시각이 있는가 하면, 안전을 강조하는 기업이 내리는 모든 결정이 겉으로는 자기이익으로 읽힌다는 구조적 아이러니를 지적하는 시각도 있다. 더 조심스럽게 움직일수록, 역설적으로 더 많은 의심을 받는다.
소프트웨어 배포 레이어에서도 비슷한 패턴이 나타난다. 고성능 모델이 사이버보안이나 특정 민감 영역의 요청을 감지하면 더 보수적인 모델로 자동 전환하는 “폴백” 메커니즘이 이제 제품 수준에서 내장되고 있다. 90% 이상의 세션에서는 이 폴백이 발동되지 않는다고 한다. 하지만 그 5~10%의 경계를 어디에 그을 것인가, 누가 그을 것인가가 점점 중요한 질문이 되고 있다.
더 많은 자동화, 더 많은 판단
여기서 하나의 공통된 흐름이 보인다.
AI가 더 많은 것을 자동화할수록, 인간이 내려야 하는 판단의 밀도는 오히려 올라간다. 어떤 모델을 어떤 태스크에 쓸 것인가. 어떤 작업을 에이전트 라인 아래로 내릴 것인가. 언제 eval을 개선하고 언제 프롬프트를 고칠 것인가. 피처 플래그를 언제 켜고 끌 것인가. 안전 폴백의 경계를 어디에 그을 것인가.
이것들은 기술적 질문이지만, 동시에 조직적이고 윤리적인 질문이기도 하다. 그리고 이 판단들이 쌓여서 팀의 실제 속도와 신뢰성을 결정한다.
“AI-native 팀”이 단순히 AI를 많이 쓰는 팀이 아닌 이유가 여기에 있다. 자동화를 더 많이 쓸수록 더 날카로운 판단을 더 빠르게 내릴 능력을 키워야 한다. 속도와 신뢰는 트레이드오프가 아니라, 서로를 요구하는 관계다. 8배의 코드를 출하하는 팀이 동시에 더 촘촘한 eval 파이프라인과 더 정교한 배포 전략을 갖추는 것, 그게 우연이 아닌 이유다.
Source: https://www.lennysnewsletter.com/p/building-the-most-ai-pilled-engineering, https://stratechery.com/2026/the-stuff-of-mythos/, https://newsletter.pragmaticengineer.com/p/cicd-with-robert-erez, https://www.lennysnewsletter.com/p/how-i-ai-claude-fable-5-review-and