AI 코드의 숨은 비용: 생산 단계에서 품질 유지

출처: DevOps.com

AI 성숙도는 근본적으로 위임 범위를 확장하는 것과 같습니다. 처음에는 AI가 코드 완성을 도와주게 하고, 다음에는 기능 구현까지 맡깁니다. 궁극적으로는 에이전트가 최소한의 인간 개입만으로 요구사항에서 풀 리퀘스트를 작성하게 됩니다. 단계가 거듭될수록 더 많은 책임이 기계에 넘어갑니다.

하지만 사람들이 간과하는 부분이 있습니다: 테스트는 그 위임을 안전하게 만드는 핵심 메커니즘입니다. 결과물을 검증할 수 없으면 에이전트를 자율적으로 운영하게 할 수 없습니다. 낮은 테스트 커버리지는 AI 성숙도 곡선을 따라 나아가는 데 가장 큰 장벽이며, 대부분의 조직은 이 문제를 인식하지 못하고 있습니다. 조직은 AI 생산성 향상을 원하지만, 그 향상을 신뢰할 수 있게 만들 테스트 인프라를 구축하는 불쾌한 작업은 꺼려합니다.

Coding assistants make delivery so fast 때문에 대부분의 QA 조직은 물에 빠진 듯합니다. 팀은 아무도 원하지 않는 선택에 직면합니다: 테스트 작업을 열 배 늘 하거나, 선택적으로 테스트하고 실행 중인 것이 안전한지에 대한 확신을 낮추는 것입니다. 어느 쪽도 지속 가능하지 않습니다.

이제 대화를 전환할 때입니다. 질문은 팀이 얼마나 빠르게 배포할 수 있느냐가 아니라, 배포한 것이 실제로 작동한다는 증거를 제시할 수 있느냐입니다.

변경 사항

AI가 코드 전달 속도를 가속화했지만, 더 큰 변화는 누가 소프트웨어를 만들고, 얼마나 많이 만들며, 그것을 신뢰하기 위해 무엇이 필요한가에 있습니다.

아키텍처, API, 보안 등에 대한 교육이 없는 사람도 이제는 동작하는 애플리케이션을 생성할 수 있습니다. 이는 큰 기회이자 위험 배가 요인입니다. 과거에는 주니어 개발자가 평문 자격 증명을 하드코딩하면 코드 리뷰에서 잡히는 일회성 사건이었습니다. 이제 AI 도우미가 프로덕션 급 도구를 모든 사람에게 제공하면서, 그런 초보 실수가 수십 개의 레포지토리에 퍼질 수 있습니다.

문제에 더 많은 인력을 투입하는 것은 현실적이지 않습니다. 기업은 팀 규모를 축소했으며, 설사 인력이 충분하더라도 QA는 코드 수준의 검사와 자동화로 정의되었습니다. 검사는 사전 정의된 조건 하에서 기능·통합·출력을 확인하는 체크리스트이며, 자동화는 그 검사를 기계화합니다. 어느 쪽도 현재와 같은 대량의 AI 생성 코드를 따라잡도록 설계되지 않았습니다.

다른 대응책은 AI가 만든 코드를 AI가 만든 테스트로 맞서는 것입니다. 논리적으로는 타당해 보이지만, 실제로는 어떤 테스트가 중요한지, 중복되는지는 무엇인지, 무엇이 빠졌는지 알 수 없게 됩니다. 생각 없이 생성된 AI 테스트는 단지 소음에 불과합니다.

따라서 인력을 늘릴 수도, 자동으로 생성할 수도 없는 상황이라면 남는 것은 거버넌스와 인텔리전스 문제입니다. 에이전트가 로그인 테스트 50가지 변형을 생성했을 때, 누가 그것이 유용한지 아니면 잡무인지를 판단합니까? AI가 테스트 스위트를 만들면, 누가 그것이 요구사항에 추적되는지를 보장합니까? 엔터프라이즈 팀은 답을 요구하고 있습니다. 이들은 이슈 트래커에서 생성된 테스트 케이스가 원본 요구사항과 연결되고, 조직화·추적 가능하며, 기존 워크플로우 내에서 트리거되길 원합니다.

이 신뢰 레이어를 구축하는 조직만이 AI 기반 개발을 확장할 수 있습니다. 나머지는 증거 없이 빠르게 배포했을 때 어떤 일이 일어나는지 뼈아프게 체험하게 될 것입니다.

지시에서 결과로

QA는 전통적으로 애플리케이션 그 자체를 검증하는 것이었지, 무엇을 하는지를 검증하는 것이 아니었습니다. 인간이 코드를 작성하고 애플리케이션이 일정에 맞춰 변할 때는 이 접근법이 통했지만, AI가 지속적으로 코드베이스를 재생성하는 상황에서는 무너집니다.

소프트웨어가 수행하도록 의도된 바와 실제 동작 사이의 격차가 바로 릴리즈가 엉키는 지점이며, 그 격차는 점점 벌어지고 있습니다. 10명 중 7명의 소프트웨어 임원은 AI가 코드 개발 속도를 높이면서 애플리케이션 품질이 저하되고 있다고 우려하고 있으며, 최신 연구도 같은 결과를 보여줍니다.

따라서 품질에 대한 집중은 AI 개발 속도에 대한 집중을 따라잡아야 합니다. 제품 관리자와 엔지니어가 요구사항을 정의하고, QA는 그 요구사항이 충족됐는지를 검증해야 합니다. 하지만 대부분의 QA 관행은 여전히 코드 산출물을 검사하는 데 초점이 맞춰져 있어, 결과를 확인하는 데는 부족합니다. 전환은 “이 컴포넌트가 코드대로 동작하는가?”에서 “이 애플리케이션이 비즈니스가 기대하는 대로 동작하는가?”로 바뀌어야 합니다. 우리는 이를 **Application Integrity(애플리케이션 무결성)**이라 부릅니다. 이는 AI 속도와 규모에 맞춰 소프트웨어가 의도대로 동작한다는 지속적이고 측정 가능한 보증을 의미합니다.

QA 팀이 흔히 겪는 고충은 각 애플리케이션 변형마다 테스트를 수동으로 생성해야 한다는 점입니다. 여기서 에이전트가 무거운 작업을 담당해야 합니다. 하지만 AI 기반 QA는 신중하게 적용될 때만 도움이 됩니다. 사용자 행동을 기반으로 테스트하고, 인터페이스가 변할 때 적응하며, 가장 깨질 가능성이 높은 부분을 우선순위에 두는 에이전트가 필요합니다. 유용한 AI 테스트와 비용만 드는 잡음의 차이는 도구에 그런 판단 로직이 내재돼 있느냐, 단순히 빠르기만 하느냐에 달려 있습니다.

모든 것이 이렇게 빠르게 움직이는 상황에서 품질을 유지하려면 애플리케이션 무결성, 즉 소프트웨어가 의도대로 동작한다는 지속적인 증거가 필요합니다. 언제든지 “우리 소프트웨어가 말한 대로 동작하고 있나요?”를 보여줄 수 있어야 합니다. 이를 위해 팀은 측정 대상에 대해 훨씬 명확해져야 합니다. 현재 팀이 추적하는 일부 메트릭은 여전히 유효하지만, 추가해야 할 메트릭도 있습니다.

• 배포 빈도와 변경 리드 타임은 사라지지 않을 핵심 지표입니다. AI는 배포를 더 빠르게 하고 릴리즈 주기를 짧게 만들 것입니다. 품질 관행이 이를 늦춘다면 개선해야 합니다. 이 지표들은 생산성 지표이지만, 배포된 것이 실제로 동작하는지는 알려주지 않습니다.

• 여기서 변경 실패율이 중요해집니다. 이는 가장 중요한 메트릭이 되고 있습니다. 배포 중 사고, 롤백, 핫픽스가 발생한 비율은 얼마인가요? 코드 양이 늘어나도 검증이 따라가지 못하면 이 수치는 상승합니다. 이 비율을 낮추는 것이 품질 팀의 핵심 과제이며, 가장 직접적인 재무적 영향을 미칩니다.

• **평균 해결 시간(MTTR)**도 더 주목받아야 합니다. 배포가 두 배로 늘어나도 복구 시간이 개선되지 않으면 노출 기간이 두 배가 됩니다.

• 기능 커버리지에 투자하세요: 애플리케이션 기능 및 API 표면 중 테스트가 커버하는 비율은 얼마인가요? 그리고 추적 가능성 커버리지: 테스트와 API 계약이 요구사항이나 스펙에