7.1 생성형 AI 패러다임 전환

개요 및 동기

소프트웨어 엔지니어링 역사의 대부분 동안, 코드를 작성하는 것은 충분히 느리고 노력이 들었기 때문에 원시 산출량, 작성된 줄 수, 이루어진 커밋, 배포된 기능이 적어도 느슨하게나마 실제 노력과, 불완전하게나마 실제 가치와 상관관계가 있었다. 그 상관관계는 결코 완벽하지 않았다. 주제 3.4는 활동 메트릭이 AI 이전 세계에서조차 왜 오도하는지에 전체 주제를 할애했다. 하지만 그것은 많은 조직이 더 많은 코드가 일반적으로 더 많은 작업이 이루어졌음을 의미한다는 암묵적인 가정 위에 메트릭 프로그램을 구축할 만큼 충분히 강했다. 생성형 AI 코딩 보조 도구는 그 가정을 결정적으로 깨뜨렸다: 이제 도구는 몇 초 만에, 이전 비용의 극히 일부로 크고 그럴듯해 보이는 양의 코드를 만들어 낼 수 있으며, 그 양은 결과 코드가 작동하는지, 유지보수 가능한지, 혹은 어떤 실제 목적에 기여하는지에 대해 그 자체로는 거의 아무것도 말해 주지 않는다.

이 주제의 핵심 주장은 이것이 점진적인 도구 변화가 아니라 패러다임 전환이라는 것이다. 패러다임 전환은 기존 계측기가 보고하는 값만이 아니라 그것들이 실제로 측정하는 것을 바꾼다. 속도계는 자동차 엔진을 바꾼 후에도 여전히 속도를 측정하지만, 이 책의 여러 메트릭은 이 전환을 그렇게 깔끔하게 견뎌 내지 못한다. 배포 빈도(주제 2.10)는 AI가 진정으로 가치 있는 작업을 가속했기 때문에 상승할 수도 있고, AI가 많은 작고 낮은 가치의 변경을 생성하는 것을 사소하게 쉽게 만들었기 때문에 상승할 수도 있다. 이제 그 숫자만으로는 둘을 구별할 수 없는데, 이는 적절한 주의를 가지고 전에는 대체로 가능했던 방식과 다르다. 같은 논리가 원시 커밋 수, 코드 줄 수, 풀 리퀘스트 양에 훨씬 더 강한 힘으로 적용된다. 이 모두에 대해 주제 3.4는 이미 개별 메트릭으로서 경고했으며, 이제 팀과 조직 수준에서도 관련된 위험으로 증폭되었다.

대규모 팀에게 이 전환은 대부분의 조직의 측정 관행이 적응할 수 있었던 것보다 더 빨리 도착했으며, 채택 속도와 측정 적응 사이의 간극이 바로 이 부의 진짜 위험이 사는 곳이다. 조정 없이 AI 이전 시대의 활동 메트릭을 계속 보고하는 엔터프라이즈 조직은 조용히 가치와의 상관관계를 멈춘 메트릭을 축하할 위험이 있다. AI 도구 투자를 평가하는 정부 조직은 구식 측정 가정 위에 구축된 조달이나 정책 결정에 전념하기 전에 정확히 어떤 메트릭이 여전히 신뢰할 수 있고 어떤 것이 더 이상 그렇지 않은지에 대한 명확한 이해가 필요하다.

핵심 원칙

이것은 메트릭이 측정하는 것에 대한 패러다임 전환이지, 점진적인 변화가 아니다. 일부 기존 메트릭은 조용히 전에 의미하던 것을 의미하지 않게 되었다.
산출량은 결코 가치의 신뢰할 수 있는 대용물이었던 적이 없으며, 이제 적극적으로 신뢰할 수 없게 되었다. 주제 3.4의 경고는 항상 옳았다. 이 전환은 그것을 무시하는 것을 훨씬 더 비용이 들게 만든다.
AI 채택 속도와 측정 적응 속도 사이의 간극이 진짜 위험이다. 조직은 메트릭을 재고하는 것보다 더 빨리 도구를 채택한다.
이 책의 모든 메트릭이 동등하게 영향받는 것은 아니다. 결과 메트릭(5부)은 활동 및 원시 산출 메트릭보다 이 전환에 훨씬 더 회복력이 있다.
이 전환은 업계 전반에 걸친 지속적인 것이지, 일회성 조정이 아니다. 도구와 그 채택 패턴이 계속 진화함에 따라 지속적인 변화를 예상하라.

권장 사항

AI 시대의 유효성에 대해 기존 메트릭 집합을 명시적으로 감사하라

현재 대시보드를 살펴보고 각 메트릭에 대해 직접 물어라: AI 지원을 많이 사용하지만 전보다 더 많은 실제 가치를 만들어 내지 않는 팀이 이 메트릭에서 개선된 수치를 보일 것인가. 활동 수, 커밋 빈도, (안정성 가드레일과 짝을 이루지 않은, 주제 2.10) 원시 배포 빈도가 가장 노출되어 있다. 5부의 결과 메트릭, 즉 누락된 결함율, 기능 채택, 비즈니스 결과는 비교적 회복력이 있는데, 그것들이 활동이 만들어 낸 양이 아니라 실제 결과를 측정하기 때문이다.

배포 빈도와 리드 타임을 특히 높아진 가드레일 주의로 재검토하라

주제 2.10은 이미 대체 게임화, 즉 숫자를 부풀리기 위해 의미 있는 작업을 사소한 배포로 분할하는 것에 대해 경고했다. 생성형 AI는 이 특정한 게임화 패턴을 극적으로 더 저렴하고 더 쉽게 만들어 낼 수 있게 하며, 심지어 의도치 않게도 그렇다. AI 지원 사소한 변경이 이제 거의 공짜로 생성되기 때문이다. 팀이 AI 지원 개발을 얼마나 많이 채택했는지에 비례하여 변경 실패율 가드레일(주제 2.10)을 특별히 조이고, 전보다 배포 크기 추세를 더욱 면밀하게 지켜보라.

코드 리뷰 역량을 새롭고 중요한 병목 현상으로 취급하라

AI 지원이 검토를 위해 제안되는 코드의 양을 극적으로 증가시키면, 흔히 이미 전달 파이프라인에서 가장 큰 대기 시간 기여자인 리뷰 단계(주제 2.9)는 훨씬 더 날카로운 제약이 된다. 전과 같은 속도로 훨씬 더 많은 양의 AI 생성 코드를 평가하도록 요청받은 리뷰어는 필연적으로 파이프라인을 늦추거나 리뷰 깊이를 줄일 것이다. 이것은 주제 2.9가 이미 경고했던 바로 그 고무 도장 위험이며, 이제 상당히 더 큰 압박 아래 있다. AI 생성 코드 양이 증가함에 따라 리뷰 깊이와 품질 가드레일을 더 높아진 주의로 모니터링하라.

AI 생성 코드가 사람이 작성한 코드와 같은 결함 프로필을 지닌다고 가정하지 마라

초기 증거와 실무자 경험은 AI 생성 코드가 사람이 작성한 코드와 다른 결함 프로필을 가질 수 있음을 시사한다: 그럴듯해 보이지만 미묘하게 잘못된 로직, 자신 있게 생성되었지만 부정확한 엣지 케이스 처리, 혹은 관용적이고 합리적으로 보이기 때문에 표면적인 리뷰를 통과하지만 시스템의 특정 맥락에 대한 진정한 이해로 실제로 추론되지 않은 코드다. 조직이 품질 관행을 그 주위에 구축해 온 과거의 결함율 관계가 여전히 변함없이 유지된다고 가정하는 대신, 이것을 당신 자신의 누락된 결함 데이터(주제 5.1)에 맞서 적극적으로 테스트할 가치가 있는 가설로 취급하여, 원래의 코드가 상당히 AI 생성되었는지 여부로 결함에 태그를 붙여라.

이 전환에 대해 메트릭 헌장과 거버넌스 절차를 명시적으로 업데이트하라

주제 1.4의 거버넌스 규율을 따라, 이 전환이 당신의 메트릭 프로그램에 수동적으로 일어나도록 두지 마라. 메트릭 헌장을 명시적으로 재검토하여, 어떤 메트릭이 새로운 가드레일이 필요한지, 어떤 것이 퇴역이 필요한지, 어떤 것이 여전히 신뢰할 수 있는지를 검토되지 않은 표류가 아니라 의도적인 거버넌스 결정으로 명명하라. 그 근거를 문서화하라. 이것은 정확히 주제 1.4가 그렇지 않으면 조용히 일어나 훨씬 나중에야 발견될 수 있다고 경고하는 종류의 정의적이고 맥락적인 전환이기 때문이다.

트레이드오프: 장단점

접근법	장점	단점
AI 이전 메트릭을 변경 없이 계속 보고하기	혼란 없음, 친숙한 보고	조용히 실제 가치와의 상관관계를 멈춘 메트릭을 축하할 위험
전체 메트릭 집합 감사와 의도적인 수정	신뢰할 수 있는 측정을 복원함	실제 분석 노력과 조직적 변화 관리가 필요함
활동 및 산출 메트릭을 완전히 포기하기	가장 노출된 위험을 직접 제거함	정당하게 유용한 일부 맥락적 신호를 잃음(주제 3.4의 단서)
전체 감사 없이 가드레일만 조이기	구현하기 더 빠름	가장 명확한 사례보다 덜 분명한 노출을 가진 메트릭을 놓칠 수 있음

핵심 긴장은 측정 연속성 대 측정 유효성이다. 조직은 이해할 수 있게도 친숙한 방식으로 친숙한 메트릭을 계속 보고하는 것을 선호한다. 메트릭 프로그램을 바꾸는 것은 실제 조직적 비용과 혼란이 있기 때문이다. 하지만 조용히 전에 측정하던 것을 측정하는 것을 멈춘 메트릭을 계속 보고하는 것은 혼란보다 나쁘다. 그것은 적극적인 오도다. 이것을 주제 1.4가 기술하는 정확히 그런 종류의 의도적이고 문서화된 거버넌스 변화로 취급함으로써 긴장을 해결하라. 단기적으로는 혼란스럽지만 조직의 메트릭을 정직하게 유지하는 데 필요하다.

팀과 논의할 질문

우리 대시보드의 각 메트릭에 대해, AI 지원을 많이 사용하지만 더 많은 실제 가치를 만들어 내지 않는 팀이 개선된 수치를 보일 것인가? 이 테스트로 당신의 메트릭을 명시적으로 살펴보라. 그것을 통과하지 못하는 것들이 수정된 가드레일이나 퇴역의 최우선 후보다.
AI 코딩 지원을 채택한 이후 우리의 배포 빈도나 커밋 양이 상승했으며, 우리는 변경 실패율이나 결함율이 상응하게 움직였는지 확인했는가? 긍정적이거나 부정적인 결과를 가정하기보다 실제 짝지어진 데이터를 끌어오라.
우리의 코드 리뷰 역량은 AI 지원 코드 양의 증가에 보조를 맞추고 있는가, 아니면 리뷰 깊이가 증가한 압박 아래 조용히 침식되고 있는가? 고무 도장 위험이 심해지는 징후에 대해 특별히 리뷰 단계 메트릭(주제 2.9)을 확인하라.
우리는 원래의 코드가 상당히 AI 생성되었는지 여부로 결함에 태그를 붙이는가, 그렇다면 그 데이터는 지금까지 무엇을 보여 주는가? 현재 이것을 태그하지 않는다면, 시작하는 데 무엇이 필요할지 논의하라. 이 데이터는 당신의 과거 품질 가정이 여전히 유지되는지와 직접 관련이 있기 때문이다.
우리는 이 전환에 비추어 메트릭 헌장(주제 1.4)을 의도적으로 재검토했는가, 아니면 우리의 측정 관행이 단순히 변경 없이 계속되었는가? 정직한 답이 후자라면, 그 간극은 정확히 이 주제가 먼저 메우라고 권장하는 것이다.
우리 조직이 이 전환에 허를 찔려, 우리가 생각했던 것을 의미하는 것을 이미 멈춘 메트릭을 축하하는 것은 어떤 모습일까? 이 구체적이고 약간 불편한 사고 실험은 그 시나리오가 실제로 일어난 후가 아니라 전에 이 주제가 권장하는 감사에 동기를 부여하는 데 도움이 된다.

분야별 관점

스타트업. 빠른 AI 도구 채택은 흔하고 흔히 진정한 경쟁 우위이지만, 채택을 매력적으로 만드는 같은 속도가 검토되지 않은 메트릭 표류를 더 가능성 있게 만든다. 속도 개선만 보고하기보다 AI 채택으로부터 보고하는 모든 효율성 이득과 함께 결과 메트릭(5부)을 확인하는 습관을 구축하라.

중소기업. AI 코딩 지원은 소규모 팀의 역량을 의미 있게 확장할 수 있지만, 품질 가드레일을 확인하지 않고 원시 산출 증가를 명백한 성공으로 보고하려는 유혹을 물리쳐라. 소규모 팀은 더 많은 중복을 가진 더 큰 조직보다 감지되지 않은 품질 문제를 흡수할 역량이 적다.

엔터프라이즈. 이 위험의 규모는 여기서 상당히 복합되는데, 수십 개 혹은 수백 개 팀 전반에 걸친 동시 AI 채택이 어떤 단일 팀이 로컬에서 그 패턴을 알아채기 전에 조직 전체의 메트릭 유효성을 바꿀 수 있기 때문이다. 팀별이 아니라 조직 수준에서 이 주제가 권장하는 메트릭 집합 감사를 수행하고, 중앙에서 명시적으로 거버넌스(주제 1.4)를 업데이트하라.

정부. 공공 부문 조직은 흔히 새로운 기술을 더 신중하게 채택하지만, 정부 기술 프로그램을 평가하는 데 사용되는 메트릭과 벤치마크는 흔히 같은 압력 아래서 스스로 변화하고 있는 민간 부문 업계 데이터로부터 끌어오거나 그것과 비교된다. 기대를 설정하거나 성과를 평가하는 데 사용하기 전에 당신이 비교하는 업계 벤치마크 중 어느 것이 이 전환에 영향을 받았는지 명시적으로 이해하라.

사례

엔터프라이즈. 한 금융 기술 회사의 엔지니어링 리더십은 광범위한 AI 코딩 보조 도구 채택 이후 두 분기 동안 배포 빈도가 거의 40% 상승한 것을 알아채고, 처음에는 이사회 발표에서 이것을 단순한 생산성 승리로 보고했다. 품질이 확인되었는지에 대한 회의적인 이사회 구성원의 질문에 촉발된 더 신중한 후속 분석은 변경 실패율이 배포 빈도와 거의 보조를 맞추어 상승했으며, 짝지어진 안정성 메트릭이 실제로 검토되자 명백한 이득을 완전히 상쇄했다는 것을 발견했다. 그 회사의 수정된 보고는 이제 AI 지원 생산성 주장이 제기될 때마다 배포 빈도와 변경 실패율을 명시적으로 함께 제시하여, 이전의 거의 공개적이었던 오도하는 주장을 피하고 있다.

정부. 한 주 정부 IT 부서는 엔지니어링 팀의 일부에 대해 AI 코딩 지원을 시범 운영하면서 엔지니어당 원시 코드 산출이 상당히 증가한 것을 발견했으며, 이 수치는 처음에는 내부 시범 검토에서 호의적으로 인용되었다. 이 책의 지침이 그 부서의 평가 프레임워크에 통합된 것에 촉발된 더 면밀한 분석은 AI 지원 작업과 비AI 지원 작업에 대해 누락된 결함율을 구체적으로 조사했으며, AI가 훈련 중 노출되지 않았던 특이한 시민 상황에 대한 엣지 케이스 처리에 집중된, AI 지원 코호트에서 다소 상승한 결함율을 발견했다. 이 발견은 시범 운영을 중단시키지는 않았지만, 원시 산출 메트릭만으로는 결코 드러내지 못했을 실제 위험을 다루면서, 자격 요건 엣지 케이스 로직을 다루는 AI 지원 변경에 대한 특정하고 표적화된 리뷰 엄격함 증가로 이어졌다.

비즈니스 사례: 동기, ROI, TCO

이 감사를 선제적으로 수행하는 수익은 정밀 조사 아래 실제로는 아무것도 측정하지 않은 것으로 드러나는 메트릭을 보고하는 것으로부터의 공개적이거나 이사회 수준의 당혹감을 피하는 것이며, 이는 정확히 위의 금융 기술 사례가 거의 만들어 낼 뻔한 시나리오다. 이 전환보다 앞서 가는 조직은 이해관계자와의 신뢰성을 유지하고, 공허한 메트릭을 보고하다가 걸린 조직은 실제이고 대부분 피할 수 있는 평판 비용을 치른다.

총 소유 비용은 기존 메트릭 집합을 감사하고, 가드레일을 조이고, 거버넌스 문서를 업데이트하는 분석 노력이며, 이는 그들이 측정한다고 주장하는 것을 측정하는 것을 조용히 멈춘 메트릭을 계속 보고하는 지속적인 위험에 비해 일회성이고 적당한 투자다. 이 비용은 또한 더 낮은 수준에서 반복된다. 이 전환은 일회성 사건이 아니라 지속적이기 때문이며, 도구와 채택 패턴이 계속 진화함에 따른 주기적인 재감사는 메트릭 거버넌스 주기에 대한 합리적이고 영구적인 추가다.

안티패턴과 함정

AI 이전 시대의 활동 메트릭을 변경 없이 무비판적으로 계속 보고하기: 조용히 실제 가치와의 상관관계를 멈춘 메트릭을 축하할 위험이 있다.
짝지어진 안정성 가드레일 없이 배포 빈도나 산출량 증가를 보고하기: AI 지원 개발 아래서 상당히 더 높은 위험으로 주제 2.10의 경고를 반복한다.
확인 없이 AI 생성 코드가 사람이 작성한 코드와 같은 결함 프로필을 지닌다고 가정하기: 적극적으로 틀릴 수 있는 테스트되지 않은 가정이다.
증가하는 AI 생성 코드 양 아래서 리뷰 깊이가 조용히 침식되도록 두기: 주제 2.9의 고무 도장 위험이 심해진 것이다.
이 전환을 지속적인 관심사가 아니라 일회성 조정으로 취급하기: 도구와 채택 패턴이 계속 진화하며, 측정 관행이 보조를 맞출 필요가 있다.
업계 벤치마크 자체가 같은 압력 아래서 변화했는지 이해하지 않고 그것에 맞서 비교하기: 상대적 성과에 대한 거짓된 감각의 위험이 있다.

성숙도 모델

1단계, 시작: AI 이전 시대의 메트릭이 변경 없이 보고되며, AI 채택이 그 유효성에 영향을 미쳤을 수 있다는 인식이 없다.
2단계, 개발: 이 전환에 대한 일부 인식이 존재하지만, 기존 메트릭 집합에 대한 체계적인 감사가 수행되지 않았다.
3단계, 표준화: 전체 메트릭 집합 감사가 수행되었으며, 가드레일이 조여지고 메트릭이 영향받거나 회복력 있는 것으로 조직 전체에 문서화된다.
4단계, 관리: 결함과 품질 결과가 조직의 과거 품질 관계가 여전히 유지되는지를 가정하지 않고 테스트하기 위해 AI 지원 수준별로 적극적으로 태그되고 추적된다.
5단계, 조율: 조직은 AI 도구와 채택 패턴이 계속 진화함에 따라 메트릭을 재검토하는 성숙하고 지속적인 관행을 가지고 있으며, 문제가 표면화된 후 반응적으로가 아니라 이 전환에 대응해 선제적으로 내려진 특정한 거버넌스 결정을 지적할 수 있다.

논의를 위한 아이디어

우리의 현재 메트릭 중 AI 지원을 많이 사용하지만 더 많은 실제 가치를 만들어 내지 않는 팀을 가장 많이 추켜세울 것은 무엇인가?
AI 채택 이후 우리의 배포 빈도가 상승했으며, 변경 실패율이 그것과 함께 움직였는가?
우리는 AI 지원 수준별로 품질 결과에 태그를 붙이는가, 그 데이터는 무엇을 보여 줄 것인가?
우리의 리뷰 역량은 AI 생성 코드 양의 증가에 보조를 맞추고 있는가?
우리는 현재 어떤 업계 벤치마크에 맞서 스스로를 비교하는가, 그것 자체가 이 압력 아래서 변화했는가?

핵심 요약

생성형 AI는 여러 기존 메트릭이 측정하는 것에 대한 패러다임 전환이지, 점진적인 도구 변화가 아니다. 일부 메트릭은 조용히 전에 의미하던 것을 의미하지 않게 되었다.
활동 및 원시 산출 메트릭이 가장 노출되어 있다. 결과 메트릭(5부)은 비교적 회복력이 있다.
AI 지원 개발 채택에 비례하여 가드레일, 특히 변경 실패율을 조여라.
태그된 누락된 결함 데이터를 사용해 AI 생성 코드가 사람이 작성한 코드와 다른 결함 프로필을 지니는지 가정하지 말고 테스트하라.
도구와 그 채택 패턴이 계속 진화하기 때문에 이것을 일회성이 아니라 지속적인 거버넌스 관심사(주제 1.4)로 취급하라.

참고 문헌 및 추가 자료

Accelerate: The Science of Lean Software and DevOps, by Nicole Forsgren, Jez Humble, and Gene Kim.
GitHub’s research on AI pair programming and developer productivity.
Google Cloud’s DevOps Research and Assessment programme, dora.dev.
The Tyranny of Metrics, by Jerry Z. Muller.