귀하의 시스템은 이미 사각지대가 있습니다. AI가 그것을 더 악화시킬 뿐입니다.

2022년에, 생성 코딩 도구가 일상적인 엔지니어링 작업에 포함되기 전, 나는 도구 선택에 대한 나의 철학에 관해. 예상보다 더 오래 지속되었습니다. 그때 나는 실제로 해결하고 있던 문제부터 시작하고, 자신의 약점을 파악하며, 도구를 사용하는 방식을 우선시해야 한다고 주장했습니다. 단지 가장 멋져 보이는 도구에 뛰어들어 작동하기를 기대하는 것이 아니라 말이죠. 자신과 목표를 알면 도구에 대한 적절한 기대치를 설정할 수 있습니다.

당시 나는 AI가 생성한 코드가 아니라 SaaS 확산에 대해 생각하고 있었습니다. 하지만 오늘날 나의 철학은 더욱 시급하고, 더욱 고수해야 할 중요성을 갖습니다.

우리 중 많은 사람들이 2025 DORA 보고서를 읽었으며, 이 보고서는 전년과 달리 AI 도입이 이제 전달량과 긍정적인 상관관계가 있음을 발견했습니다. 그 이면의 발견은 전달 불안정성이 계속 상승하고 있었으며, 속도 향상이 이를 보완하는지 테스트했지만 그렇지 않다는 것이었습니다. 이는 우리의 경험과 일치합니다. 우리 팀은 에이전시 소프트웨어 개발을 도입했고, 두 분기 동안 처리량이 48% 증가했으며, 이어서 안정성 문제가 16% 증가했습니다. 10명은 작은 표본이지만, 전체 그림을 볼 수 있는 표본이기도 하며, 패턴은 유지되었습니다. 

AI 도입은 이제 더 이상 질문이 아닙니다. 여러분은 이제 막 시작했거나 이미 깊이 참여하고 있습니다. 이제 달라진 점은 엔지니어링 리더들이 AI를 도입하고 그 효과를 입증해야 한다는 기대가 있다는 것입니다. CEO, 이사회, 재무팀 모두 AI 투자 최적화 방법을 알고 싶어합니다. 그들은 여러분이 선택한 도구가 실제 문제를 효율적으로 해결하고 있는지를 묻고 있습니다. 

격차는 언제나 존재했습니다. AI가 그것을 더 넓혔을 뿐입니다.

CTO로서 저는 고객, 잠재 고객, 동료 엔지니어링 리더들과 대화를 나누며 AI와 관련된 경험과 성과, 불만을 비교하는 데 많은 시간을 할애합니다. 충분히 대화를 나눈 뒤, AI 도입과 결과에 대한 패턴을 보기 시작했습니다.

주요 관찰은 제 것이 아닙니다. DORA는 지난 2년간 이를 강조해 왔습니다: AI는 조직 내에서 이미 일어나고 있는 일, 강점과 약점을 모두 증폭시킵니다. 깔끔한 아키텍처와 건전한 리뷰 습관을 가진 팀은 더 빨라집니다. 코드를 배포할 만큼 기술 부채를 겨우 정리한 팀은 이제 그 부채가 주요 장애물로 성장하고 있음을 발견합니다. 그러나 이러한 프레이밍이 놓치는 점은 왜 많은 팀이 이 상황에 당황하게 되는가입니다. AI가 약점을 숨긴 것이 아니라, 우리가 의존해 온 시스템이 그 약점을 드러내지 않았을 뿐입니다.

대부분의 엔지니어링 조직이 사용하는 티켓 및 보고 스택은 인간이 가진 질문에 인간 속도로, 해당 작업이 “완료”라는 의미를 대략 이해하는 사람들에 의해 답하도록 설계되었습니다. 이것은 완벽한 기록이 아니었습니다. 항상 근사치였으며, 아래의 더 복잡한 내용을 요약한 사람이 채워 넣었습니다. 이제 AI는 양을 늘리고 새로운 입력을 추가해 새로운 활동을 생성합니다. 전통적인 비AI 개발 방식에 사용되는 시스템(또는 도구)은 이러한 상황을 위해 설계된 적이 없습니다. 

그럼에도 우리는 여전히 동일한 목표에 책임이 있습니다. 속도, 품질, 비용, 그리고 팀의 실제 성과를 여전히 관리합니다. 이제는 작년 대시보드를 맹목적으로 신뢰할 수 없습니다. 

여기에 타당한 반론이 있습니다. 2026 ROI 보고서는 채택 직후 생산성이 떨어지는 J-곡선을 설명합니다. 이는 학습 곡선, AI가 생성한 코드를 검증하는 비용, 그리고 따라잡지 못한 하위 프로세스에 의해 발생합니다. 그들은 이를 변혁의 “수업료 비용”이라고 부르며, 리더들에게 이를 실패로 오해하지 말라고 경고합니다. 충분히 타당합니다. 하지만 티켓 기반 대시보드에서는 수업료와 실제 문제를 구분하기 어렵습니다. 어느 상황에 있는지 알 수 없으면 인내하지 못하고 추측하게 됩니다.

우리는 기본으로 돌아가야 합니다. 자신을 알라. 팀을 알라. 당신이 해결하고 있는 문제를 알라. 

AI와 함께 ‘자신을 알다’는 어떻게 할까요?

대화들을 통해, 인간이 만든 작업과 인간이 보고한 작업을 위해 구축된 기존 시스템이 사각지대가 되는 다섯 가지 주요 영역을 확인했습니다. 이를 무시하면 AI 도입을 지속하면서 약점을 증폭시킬 위험이 있습니다.

사각지대 1: 속도 연극

더 많은 커밋과 PR은 진행처럼 보일 수 있으며, 실제로도 그렇습니다. AI는 두 수치를 자동으로 증가시킵니다. A Stanford 사례 연구는 AI 도입이 PR 수를 14% 증가시켰음을 보여주었습니다. 그러나 놓치고 있는 것은 그 활동 중 실제 배포되는 기능 작업 비율과 유지보수, 재작업, 혹은 지속되지 않은 리팩터링으로 인한 churn 비율입니다.

이를 해결하려면 기능 작업과 유지보수의 비율을 살펴보고, 배포 빈도와 리드 타임을 업계 평균이 아닌 자체 과거 기준과 비교하십시오. 그 구분 없이 보고하는 진행은 실제로 입증할 수 없습니다.

사각지대 2: 리뷰 부채

리뷰 용량은 출력에 비례해 자동으로 확대되지 않는다. 검증 비용은 지나가야 할 단계가 아니라, 에이전트형 개발을 위한 지속적인 비용의 일부이다. A 최근 엔지니어링 리더들을 대상으로 한 설문조사 80%의 팀이 리뷰에 최소 10% 이상의 시간을 할애하고, 대략 10팀 중 1팀은 40% 이상을 할애한다는 결과가 나왔다. 이러한 부담 하에서 팀은 늘어나는 백로그와 형식적인 승인 사이를 오가게 되며, 어느 쪽도 실질적인 해결책이 아니다.

출시 제약은 더 이상 코드가 얼마나 빨리 작성되는가가 아니다. 그것은 인간이 실제로 변경이 올바른지 확신할 수 있는 속도, 결함을 얼마나 빠르고 정확하게 감지하고 해결할 수 있는지. 리뷰 부하가 팀 전체에 어떻게 실제로 분배되는지 살펴보라; 그렇지 않으면 시니어 엔지니어에게 과부하가 걸리고, 릴리즈가 지연되며, 주요 운영 문제를 초래할 위험이 있다.

Blind Spot 3: 숨겨진 작업

리팩터와 아키텍처 전환은 다른 티켓 안에 숨는 습관이 있으며, 티켓 시스템에 나타나지 않을 경우도 있다. AI는 이러한 종류의 작업을 더 많이 생성한다, 적게가 아니다. 에이전트는 하나의 버그를 수정하기 위해 열두 개의 파일을 건드리는 것을 주저하지 않지만, 인간은 멈춰서 재고할 수 있다. 기록 시스템을 건너뛰는 작업은 계획도 건너뛰게 하며, 이는 용량 모델이 잘못되었고, 그 위에 구축된 모든 예측도 잘못되었다는 뜻이다. 

실제로 수행되는 작업량을 이해하려면 코드베이스와 풀 리퀘스트 기록에서 실제로 얼마나 변화하고 있는지를 살펴봐야 한다. 그렇지 않으면 용량 계획은 사람들이 기록해 두었던 것에 기반하게 되며, 실제 수행한 내용에 기반하지 않는다. 

Blind Spot 4: 품질 드리프트

같은 설문조사에 따르면 거의 절반에 가까운 엔지니어링 리더들이 주간 보안 이슈를 감지하는 데 어려움을 겪는다. 복잡성, 중복성, 그리고 완전히 맞지 않는 의존성이 많은 작은, 각각은 합리적인 변경들에 걸쳐 쌓인다. 이들 각각은 스스로는 경고를 주지 않는다. 같은 스탠포드 사례 연구에서 코드 품질이 9% 하락하고 변동성이 세 배 이상 증가했다. 평균은 약간 변했지만, 분산(눈에 띄는 부분)은 크게 변했다. AI 규모에서는 대부분의 리뷰 프로세스가 포착하기 전에 더 빠르게 복합화된다. 드리프트는 누군가가 검토한 기억이 없는 의존성으로 거슬러 올라가는 온콜 알림으로 표면화되는 경향이 있다. 이때가 되면 고객이 먼저 눈치챌 가능성이 상당히 높다.

보안 발견, 의존성, 실패 및 복구에 대한 추세선을 살펴보라—개별 커밋이 아니라. 몇 주에 걸친 복잡성과 중복이 리뷰에서 표시된 개별 변경보다 더 중요하다. 그렇지 않으면 대부분의 팀이 여전히 하는 방식대로 드리프트를 포착하게 된다: 이미 사고를 일으킨 뒤에.

Blind Spot 5: 입증되지 않은 지출

AI 도입이 논쟁거리가 아니라면, AI 지출과 ROI가 모두가 집중하는 질문이 된다. 재무팀은 무엇이 자본화 가능한지, 무엇이 운영 비용인지 알고 싶어한다. 리더십은 투자가 어떤 결과를 낳았는지 알고 싶어한다. 대부분의 팀은 여전히 직관에 의존해 도구, 좌석, 인력 결정을 내리고 있으며, 비용과 전달된 작업 사이의 연관성을 입증하지 못한다.

엔지니어링 노력이 실제로 코드베이스 자체에서 분기별로 어떻게 흐르는지 살펴보라—로드맵이 말하는 흐름이 아니라. 그 연결 고리가 없으면, 다음 해 예산을 일화로 방어하게 되고, 일화는 CFO와의 강경한 대화에서 살아남지 못한다.

보이지 않는 것부터 시작하라

재무팀의 자본화된 지출에 대한 질문과 새벽 2시 온콜 페이지는 관련 없어 보이지만, 그렇지 않다. 두 경우 모두 활동으로부터 ‘추정’할 수 있다. 하지만 두 경우 모두 실제로는 코드 자체에서 증거를 통해 답을 찾을 수 있다.

DORA가 이 모든 것에 대한 답을 제시하는 것은 바로 엔지니어링 시스템 자체이다: 플랫폼 품질, 워크플로우 명확성, 팀 정렬. 맞다, 그리고 이것이 첫 단계는 아니다. 볼 수 없는 시스템을 고칠 수는 없다. 그 다섯 영역 각각은 관찰할 수 있어야 투자에 대해 논의할 수 있다.

첫 번째 유용한 단계는 새로운 도구나 새로운 프로세스가 아니다. 자신을 솔직히 파악하고, 이 다섯 영역 중 어느 것이 실제 증거가 부족한 블라인드 스팟인지 결정하는 것이다. 대부분의 리더는 즉시 (그리고 주의를 기울이며) 이 영역 중 하나에서 문제를 식별할 수 있다. 그러나 가장 적은 정보를 가진 영역이 AI 도입을 계속하면서 가장 크게 나타나고 문제를 일으킬 가능성이 가장 높다.