서론

지난 몇 달에 걸쳐 당사의 개발 체제는 '인간이 쓰고 AI가 돕는' 방식에서 'AI가 자율적으로 움직이고, 인간이 방침 판단과 리뷰를 담당하는' 방식으로 단계적으로 이행해 왔습니다. 멀티 세션 운영·릴리스 절차·QA·운영 모니터링까지 AI가 일관되게 수행하는, 이른바 AI 네이티브 (AI-native) 개발의 기반이 최근 드디어 갖춰졌습니다 (기반의 전체 모습은 'AI 네이티브 개발의 기반이 만들어지기까지'에 정리해 두었습니다).

기반이 갖춰진 지금부터는 서비스 향상 그 자체를 가속화해 나가는 페이즈입니다. 그 입구로서 본 기사에서는, 인간 중심이었던 시대와 비교했을 때, AI 네이티브화로 인해 QCD(품질·비용·납기)가 어떻게 변화했는지를 최근 2주간의 실측 데이터에 기반하여 평가해 보겠습니다.

이러한 이야기는 "엄청나게 빨라졌다"라는 의기양양한 이야기거나, "AI는 버그투성이다"라는 불안한 이야기 중 어느 한쪽으로 치우치기 쉽습니다. 본 기사는 그 어느 쪽도 아닌, 릴리스 기록과 문의 기록을 대조한 현시점의 실태 평가입니다. 먼저, 이 기사를 통해 전달하고 싶은 핵심을 한 문장으로 적어둡니다.

AI로 개발량이 한 자릿수 증가하면 "결함이 빈번하게 발생하고 있다"라고 보일 수 있다. 하지만 데이터로 분해해 보면, 주된 원인은 발생률의 악화가 아니라

검출률의 향상과 분모의 증가였다. 그리고 품질은 자동으로 지켜지는 것이 아니라, 릴리스마다의 검증과 계측의 축적으로 지켜지고 있다.

1. 양(量) — 1주일에 약 80인일

먼저 양(QCD의 D)입니다. 최근 1주간의 릴리스 기록을 정리해 보면 다음과 같은 내역이 되었습니다.

기능 개발 5건— 프론트엔드의 체감 속도를 측정하는 텔레메트리 (Telemetry) 기반 신설, 외부 브라우저 이용자를 위한 동선 추가, 집계 배치 (Batch) 확장, 장애 복구용 데이터 재취득 커맨드 신설 등 -
결함 대응 12건— 이중 조작 방지 락 (Lock) 재설계, 결제 관련 환경 설정 불일치 해소, 메일 문구와 실제 청구 금액의 정합성, 화면 크래시(Crash) 수 건의 근본 해결, 무거운 화면의 고속화(45초→2.7초, 7초→0.5초 등) -
인프라 개선 다수— 구 환경으로부터의 이행 마무리, DB 인덱스(Index) 추가, 리소스 적정 사이즈화 등의 비용 절감 대책

이것들을 "인간 팀이 통상적인 플로우(조사→구현→리뷰→QA→릴리스→모니터링)로 수행했을 때 몇 인일(man-day)인가"로 쌓아서 추정하면, 약 65~95인일, 중앙값으로 약 80인일이 되었습니다. 실제로 소화한 기간은 약 5.5 영업일이므로, 동일한 처리량(Throughput)을 인간만으로 내려면 12~15명의 엔지니어 팀 상당이라는 계산이 나옵니다.

여기서 강조하고 싶은 점은, 속도를 위해 검증을 생략한 것이 아니라는 점입니다. 오히려 반대로, 각 릴리스에는 "수정 전에 실패를 재현(RED)→수정 후에 성공을 확인(GREEN)"하는 실증, 리팩터링 (Refactoring) 시에는 출력의 등가성 대조, 릴리스 후에는 정량적 모니터링 (Monitoring, 에러 건수·응답 시간 실측)이 매번 포함되어 있습니다. 인간 시대에 이 정도 두께의 검증을 모든 릴리스에 의무화했다면, 그 자체로 공수의 벽이 되었을 것입니다.

장 끝의 증류: AI 네이티브화의 본질은 "빨리 쓸 수 있다"가 아니라, "검증과 모니터링을 풀 세트로 갖추고도 여전히 빠르다"는 것. 양의 증가는 품질 프로세스의 생략이 아니라, 품질 프로세스 자체를 자동화한 결과이다.

2. 질(質) — "결함이 빈번하게 발생하고 있지 않은가?"를 데이터로 검증하기

다음은 품질(QCD의 Q)입니다. 이 부분은 양처럼 경기가 좋은 이야기가 아니라, 진지한 우려에 대한 검증부터 시작되었습니다.

2.1 위화감과 편향(Bias)의 자각

활동량이 늘어난 결과, 고객으로부터의 문의를 통해 문제가 발견되는 케이스가 눈에 띄기 시작했습니다. 여기서 솔직하게 도출되는 것은 다음과 같은 부정적인 가설입니다.

• AI의 컨텍스트 (Context) 부족으로 인한 고려 누락으로 사양 결함이 늘어나고 있는 것이 아닌가
• 실제 사용자 조작에 가까운 E2E 테스트가 부족하여, UX의 위화감이나 "막다른 길"이 시장으로 유출되고 있는 것이 아닌가
• 즉, 품질에 문제가 있는 상태로 릴리스가 쌓이고 있는 것이 아닌가

한편으로 "AI 개발은 결함 발생 빈도를 높인다"라는 취지의 기사를 접했었기에, 그 정보에 편향되어 나쁜 해석으로 기울어져 있을 가능성도 자각하고 있었습니다. 그래서 그에 대응하는 긍정적인 가설도 동시에 세웠습니다.

• 발생 율은 변하지 않았고, 활동량의 증가로 단위 기간당 발생 수가 늘어나 보이는 것뿐이지 않을까
• 모니터링 강화로 인해, 지금까지 관측되지 않았던 문제의 검출률이 높아진 것이 아닐까
• AI가 놓치는 버그가 있다 하더라도, 그 이상으로 인간 시대에 심어져 있었으나 간과되어 왔던 버그를 AI가 발견·수정하고 있는 것이 아닐까

체감이나 편향(Bias)으로 논쟁해도 결론이 나지 않기에, 최근 2주간의 릴리스 공지(약 50건)와 문의를 기점으로 한 보고를 전수 대조하여, 결함(Bug)별로 근본 원인의 유래를 분류했습니다.

2.2 결함의 기원 분류

문의를 통해 발각된 결함 13건을 근본 원인 분석(Root Cause Analysis) 결과에 따라 3가지로 분류했습니다.

릴리스 기록 측의 근본 원인 분석에서도 "수년 전부터 코드에 잠재해 있던 에러의 영구 수정", "과거의 변경에서 유래한 기지(Known)의 결함에 대한 가드 추가"와 같은 기술이 이어집니다. 기간 내에 영향이 컸던 문제는 모두 인간 시대에 심어져 있던 것들이었습니다.

이 분류를 가설에 대입하면:

가설 1 (분모의 증가) → 지지. 2주간 릴리스 약 35건·결함 수정 40건 이상에 대해, AI 기인 리그레션은 23건입니다. 변경 실패율(릴리스 중 몇 %가 문제를 일으켰는가)로 환산하면 **약 69%**로, DevOps 조사(DORA)에서 알려진 업계 중앙값~15%를 밑돕니다. 동일한 비율을 인간 시대의 릴리스 빈도에 대입하면 "수개월에 1건"이 되며, 당시의 체감과도 일치합니다. 즉, 비율은 악화되지 않았으며, 분모가 한 자릿수 늘어난 결과로서 절대수가 증가한 것이었습니다.

가설 3 (인간의 버그를 AI가 발견) → 강력 지지. 기간 내에 수정한 "인간 시대부터의 기존 결함"은 약 25건으로, AI 기인 리그레션의 약 10배입니다. 상징적이었던 것은 외부 서비스 연동의 인증 정보가 만료되어, 알림 메일이 1개월 이상 조용히 전송되지 않았던 문제입니다. 에러가 누구의 화면에도 나타나지 않는 종류의 실패였기에 기존의 탐지 경로로는 관측할 방법이 없었으나, AI에 의한 능동적인 로그 조사로 처음 시각화되어 당일 복구되었습니다.

2.3 체감의 정체 — 탐지율의 구조적 변화

남은 가설 2(탐지율의 향상)가 사실 "빈번하게 발생하고 있다"는 체감의 최대 설명 변수였습니다.

인간 중심의 시대에는 운영 환경의 애플리케이션 로그를 상시 모니터링하는 메커니즘이 없었으며, 고객으로부터의 문의가 사실상 유일한 탐지 경로였습니다. 문제는 존재하더라도 문의로 이어지지 않으면 관측되지 않습니다. 고요한 바다처럼 보였던 것은 수중을 볼 수 있는 수단이 없었기 때문입니다.

현재는 탐지 경로가 삼중으로 구성되어 있습니다.

• 능동적인 로그 스캔 — 운영 로그를 AI가 정기적으로 순회하며, 실제로 발생하고 있는 에러를 포착하여 수정까지 가져옵니다. 이 기간에만 9건을 문의 제로 상태로 근치(Root cause fix)했습니다.
• 프론트엔드 텔레메트리 (Telemetry) — 브라우저 측의 크래시를 서버로 보내 시각화하는 메커니즘을 신설하여, 화면 계통의 결함 4건을 실탐지 후 수정했습니다 (이 메커니즘은 이전 기사에서 소개했습니다).
• 릴리스 후 정량 모니터링 — 릴리스마다 에러 건수·응답 시간을 실측하여 이상이 있으면 즉시 대처합니다.

즉, "문의로 발각된 수"가 눈에 띄는 이면에서, 문의가 도달하기 전에 해결한 수가 그 수를 상회하는 페이스로 쌓이고 있습니다. 후자는 인간 시대에는 애초에 관측되지 않았기 때문에 비교 시야에 들어오지 않습니다. 탐지율이 올라가면 단기적으로는 "문제가 늘어난" 것처럼 보입니다. 측정을 의사결정의 중심으로 두기로 결정한 이상, 이는 통과해야 할 단계라고 보고 있습니다.

2.4 그럼에도 적중했던 과제와 대책

지금까지는 긍정적 가설이 우세하지만, 공정성을 위해 당초의 부정적 가설 중 실례가 확인된 것도 적어둡니다.

첫 번째는, 지나치게 안전 위주로 치우친 설계로 인한 UX의 막다른 길(Dead end)입니다. AI는 에러 처리를 "의심스러우면 정지"하는 방식으로 작성하는 경향이 있으며, 그 자체는 장점이지만 정지한 지점에 복귀 경로가 없는 케이스가 있었습니다. 에러 표시에 고착되어 앞으로 나아갈 수 없는, 이른바 막다른 화면입니다. 로직의 정확성은 유닛 테스트(Unit Test)로 담보할 수 있어도, "이 화면에서 막힌 사용자는 어디로 가야 하는가"는 실제 사용자 조작에 가까운 E2E 테스트로만 포착할 수 있습니다. 이 부분은 당초의 우려대로 부족했습니다.

두 번째는 변경 사항의 동승(相乗り)입니다. 여러 변경 사항을 하나의 릴리스(Release)에 실었을 때, 본래 별도로 검증되어야 할 변경 사항들이 함께 실리면서 결제 관련 경로에서 결함이 발생한 사례가 1건 있었습니다. 개별 변경 사항은 올바르더라도, 하나로 묶이는 순간 검증의 그물망이 느슨해지는 것—이는 AI 고유의 문제가 아니라 고전적인 릴리스 관리의 문제이지만, 릴리스 빈도가 높아진 만큼 노출될 기회도 늘어납니다.

확인된 실패 모드(Failure mode) 두 가지는 모두 구조적인 대책으로 연결했습니다.

• 실기기에서의 E2E 확인을 릴리스 전 필수 게이트(Gate)로 설정한다 (막다른 길 유형은 여기서만 포착된다)
• 에러로 인해 정지할 경우, 반드시 복구 경로(새로고침, 재로그인 등)를 제공하는 것을 설계 기준으로 명문화한다
• 결제와 같이 영향도가 큰 경로의 변경은 다른 변경 사항과 동승시키지 않고 단독으로 릴리스한다

장 끝의 증류: "AI라서 품질이 떨어진다"는 말은 적어도 이번 데이터에서는 지지되지 않았습니다. 다만 그것은 자동으로 유지된 것이 아니라, 매 릴리스마다 검증·측정·모니터링을 쌓아 올린 결과이며, 실패 모드가 발견될 때마다 이를 구조적인 대책으로 계속 변환해 나가는 것이 전제 조건이 됩니다.

마치며

최근 2주간의 실측을 정리하면, 양은 인간 환산 시 주당 약 80인일(Man-day), 질은 변경 실패율 6~9%로 업계 수준 이하이며, "결함 빈발"을 체감하게 된 주된 원인은 검출률의 향상이었습니다. 품질을 희생하며 속도를 사는 것이 아니라, 검증과 모니터링까지 함께 자동화함으로써 양쪽을 모두 가져가고 있다—이것이 현시점의 평가입니다.

물론, 이것은 어디까지나 현시점의 스냅샷(Snapshot)입니다. 인간 시대의 문의 건수나 릴리스 횟수에 대한 엄격한 베이스라인(Baseline) 측정은 이제부터 시작이며, 검출률이 높아진 상태가 정착되면 다음은 발생률 자체를 낮추는 단계로 진입하게 됩니다. 앞으로도 측정과 개선의 피드백 루프(Feedback loop)를 계속 돌리며, 정기적으로 동일한 프레임워크 내에서 다시 평가할 계획입니다.

그리고 한 가지 더. 현재 수행하고 있는 것은 결함 대응이나 화면 속도 개선과 같이 비교적 소규모이고 독립성이 높은 태스크(Task)가 중심입니다. 이 체제가 대규모 기능 개발—여러 서비스를 가로지르는 신기능이나 수 주 규모의 설계가 필요한 개발—에서도 동일한 QCD를 낼 수 있을 것인가. 이 부분은 아직 미지수이며, 솔직히 말해 가장 기대하고 있는 대목입니다. 결과는 다시 이 자리에서 보고하겠습니다.

Discussion