2025년 초에 우리 플랫폼 팀이 모든 리포지토리에 AI 코딩 어시스턴트를 채택했을 때, 생산성 향상이 기대되었지만, 성공이 아닌 실패에서 가장 가치 있는 교훈을 얻게 될 줄은 예상하지 못했습니다. AI가 코드 작성에 중요한 역할을 했던 약 4,200개의 병합된 풀 리퀘스트를 검토한 후, 나타난 그림은 제가 읽었던 대부분의 마케팅 자료와 모순되었습니다. 이 기술 뒤에 있는 경제적 동력은 부정할 수 없으며,644억 달러의 AI 인프라에 대한 투자 실리콘 밸리와 그 이상으로 자본이 흐르는 방식을 변화시키고 있지만, 이러한 도구를 사용하여 생산 소프트웨어를 배송하는 일상적인 현실은 키노트 프레젠테이션에서 제시된 것보다 더 혼란스럽고, 더 상세하며, 결국 더 흥미롭습니다. 이것이 우리가 배운 것, 우리가 바꾼 것, 그리고 시작하기 전에 누군가가 알려줬으면 하는 것입니다.
생산성 숫자는 진실되지만 오해를 살짝 일으킵니다
내부적인 전파도에 따르면, 개별 개발자들이 AI 보조가 표준 관행이 되자 코드 라인 수로 26퍼센트에서 55퍼센트 더 많은 코드를 배포했습니다. 이것은 명백한 승리처럼 들리며, 좁은 맥락에서는 그렇습니다. 템플릿 생성, 테스트 자동화 도구, API 클라이언트 래퍼, 일상적인 리팩토링 모두 시간에서 분으로 축소되었습니다. 우리 팀의 초보 엔지니어가 이전 워크플로우에 따라 6주 걸리는 전통적인 ETL 파이프라인을 3일 안에 리팩토링했습니다.
하지만 코드 규모는 잘못된 지표였고, 우리는 거의 즉시 알았습니다. 네 번째 달까지 우리의 사건 발생률은 작년 대비 31% 증가했습니다. 롤백이 늘었고. 해결까지 걸리는 평균 시간이 길어졌습니다. 사후 분석을 더 깊이 파고들었을 때, 패턴이 나타났습니다: 회귀는 거의 AI가 생성한 코드 자체의 치명적인 버그가 아니었습니다. 그들은 미묘한 통합 실패, 모델이 알 수 없었던 경계 사례, 그리고 로컬에서 작동했지만 시스템의 다른 곳에서는 암묵적인 관례를 위반하는 제안을 수락하여 축적된 복잡성이었습니다.
METR에 의해 널리 유통된 연구에서 경험 많은 개발자들이 익숙한 코드베이스를 사용할 때 AI 보조 도구를 사용하면 실제로 19퍼센트 느렸다고 발견했습니다. 이는 그들이 20퍼센트 빠를 것이라고 믿었음에도 불구하고입니다. METR의 AI 개발자 생산성에 대한 무작위 대조 실험 결과는 녹색지역 작업을 성숙한 서비스의 유지보수에서 분리한 후 우리 자신의 데이터에서 관찰한 것과 일치합니다. 생산성 이야기는 전적으로 맥락에 따라 달라지며, AI가 빛나는 맥락은 대부분의 최고 엔지니어가 시간을 보내는 맥락이 아닙니다.
아무도 경고하지 않은 리뷰 병목 현상
AI 도입으로 강요된 단일 가장 큰 운영 변경 사항은 코드 리뷰의 완전한 재구조화였습니다. 개발자가 20분 안에 800줄의 합리적으로 보이는 코드를 작성할 수 있을 때, 병목 현상이 즉시 영구적으로 코드를 검토해야 하는 사람으로 이동합니다. 우리의 경험 많은 엔지니어들은 3개월 안에 피로 누적을 시작했습니다. 검토 대기열은 증가했고. PR은 며칠간 놓여 있었습니다. 사람들은 변화를 스탬프로 인정하기 시작했습니다. 부하가 신중한 검토를 불가능하게 만들었기 때문입니다.
우리는 결국 워크플로우를 반전시켜 이 문제를 해결했습니다. 지금부터 저자들은 AI 도움으로 이루어진 변경 사항을 5분 이하의 녹화 영상으로 리뷰어들에게 안내해야 하며, 코드가 무엇을 하는지, 왜 이 접근 방식을 선택했는지, 그리고 수동으로 어떤 것을 검증했는지 설명해야 합니다. 영상 요구 사항은 행정적인 것처럼 들리지만, 두 가지 일을 성취했습니다. 저자들에게 생성한 코드를 실제로 이해하게 만들었고, 위험한 지식 격차를 해소했습니다. 또한 리뷰어들에게 시간을 존중하는 출발점을 제공했습니다. 리뷰 속도는 6주 안에 회복했고, 병합된 코드의 품질은 측정 가능한 수준으로 향상되었습니다.
실제로 작동하는 것은 무엇인가
연구실 실험 한 해 후, 몇 가지 관행이 AI 도구의 혜택을 받는 팀과 그 출력에 빠져드는 팀을 분리했습니다. 이 중 하나도 혁신적인 것은 아니지만, 이를 일관되게 적용하는 데 필요한 규율이 결국 차별자가 되었습니다.
생성 전에 엄격한 사양이 더 중요하며 프롬프트 엔지니어링 기교보다. 도움말을 호출하기 전에 상세한 수용 기준, 타입 서명, 예제 입력을 작성한 엔지니어들은 자연어로 의도를 설명한 엔지니어들보다 훨씬 나은 결과를 얻었습니다. 모델은 직설적인 파트너입니다. 모호한 지시를 주면 모호한 코드를 생성하며, 종종 자신감 있게 말합니다.
단위 테스트를 먼저 작성하는 워크플로우는 중요하지 않은 변경 사항에 대해서는 필수적이 되었습니다. 구현을 생성하기 전에 테스트를 작성하는 것은 타입 시스템이 혼자 해낸 일을 이루었습니다: 탐색 공간을 제한하고 출력이 올바른지에 대한 객관적인 신호를 제공합니다. 이 단계를 건너뛴 팀들은 생산 환경에서 조용히 실패하는 가능성 있는 코드를 디버깅하게 되었습니다.
아키텍처 경계에서의 인공지능 보조와 의무적인 인간 검사를 연결하여 불일치하는 시스템 설계로의 느린 이동을 방지했습니다. 우리는 서비스 경계를 넘어가는 코드를 작성하거나 새로운 공개 API를 정의하거나 인증 또는 권한 부여 논리를 수정하는 경우에만 사람이 코드를 작성하도록 요구합니다. 이 지역에서는 모델이 제안할 수 있지만 작성할 수는 없습니다. 이 규칙만으로도 이것 없이 출시될 수 있었던 몇 가지 근접 사고를 방지했습니다.
관찰성 투자는 몇 번을 넘어서도 자신을 돌려받았다. 당신이 저장소의 모든 코드 라인의 출처를 완전히 신뢰할 수 없을 때, 생산 환경에서 문제를 빠르게 감지할 수 있어야 한다. 연도의 두 번째 절반 동안 추적, 구조화된 로깅, 알림에 대한 지출을 두 배로 늘렸다. 비용은 상당했다. 그렇지 않았을 경우 비용은 재앙이었을 것이다.
갑자기 더 가치 있는 기술들
한 해 동안 우리 팀이 적응하는 과정을 관찰하며 AI 지원 환경에서 어떤 공학 기술이 증폭되고 어떤 기술이 감소하는지 밝혀졌습니다. 이는 강력한 개발자가 되는 데 무엇이 중요한지에 대한 오랜 가설을 뒤집었습니다.
코드를 신중하고 빠르게 읽는 것이 팀에서 가장 가치 있는 기술이 되었습니다. 300줄의 차이를 스캔하고 의심스러운 블록을 두 개 식별할 수 있는 엔지니어들은 테스트에만 의존하여 문제를 포착하는 엔지니어들보다 10배 더 생산적이었습니다. 디버깅 기술도 가치를 얻었는데, AI가 생성한 버그는 표준 문제 해결 힌트에 저항하는 낯선 형태로 나타나기 때문입니다.
시스템 설계와 아키텍처 판단은 더욱 중요해졌습니다. 이 모델은 요청하는 개별 구성 요소를 생성할 수 있지만, 실제로 시스템에 필요한 구성 요소는 무엇인지, 어떻게 상호작용해야 하는지, 또 어떤 트레이드오프가 결정할 가치가 있는지 알 수 없습니다. 번성했던 공학자들은 시스템 전체를 머릿속에 들고 있을 수 있었던 사람들이었고, 이는 AI를 일관된 전체에 맞는 구현 방향으로 인도할 수 있었습니다.
반대로, API 문법을 기억하거나 프레임워크 식어들을 외우거나, 템플릿을 빠르게 입력하는 능력은 어제부턴 거의 가치 없게 되었습니다. 이러한 기술을 통해 자신의 정체성을 구축한 엔지니어들은 가장 어려운 적응을 해야 했습니다. 소프트웨어 구축의 실제 작업과는 별개로 이러한 것들을 여겼던 엔지니어들은 변화를 거의 느끼지 못했습니다.
내 과거의 나에게 말하곤 했을 일
만약 2025년 1월에 이러한 도구를 출시하고 있던 나의 버전에게 하나의 메시지를 보낼 수 있다면 그것은 이것이겠지: 기술은 어렵지 않다. 어려운 부분은 근본적으로 다른 생산 기능을 중심으로 팀의 검토 프로세스, 품질 기준, 기술 개발 경로를 재건하는 것이다. 이 전환에서 이긴 팀은 최고의 모델이나 가장 교활한 프롬프트를 가진 팀이 아니다. AI 보조를 진지한 조직적 변화로 취급하고 적절히 투자하는 팀이다. 다른 모든 사람들은 모두 완전히 이해하지 못하는 코드를 더 출시하고, 전통적인 리팩토링으로 갚을 수 없는 종류의 부채를 축적하며, 가장 나쁜 순간에 중요한 것이 깨졌을 때 비용을 발견한다.