Max Kanat-Alexander 강연 분석: AI 코딩 시대, 코드 품질이 중요한 기준은 '소프트웨어의 내구성'

"상황에 따라 다르다"를 넘어선 코드 품질의 판단 기준

AI 코딩 에이전트가 몇 초 만에 수백 줄의 애플리케이션을 생성하는 시대가 되면서, 개발 현장에서는 "언제든 다시 생성하면 되는데 굳이 시간을 들여 코드 구조를 다듬고 엄격한 리뷰를 거쳐야 하는가"라는 논쟁이 이어지고 있습니다. 시니어 엔지니어들은 흔히 "상황에 따라 다르다(It depends)"라고 답하지만, 정작 그 기준이 무엇인지 명확히 정의하지 못하면 팀은 불필요한 검증에 시간을 낭비하거나 반대로 핵심 시스템에 치명적인 기술 부채를 쌓게 됩니다.

2026년 10월 21일 AI Engineer 공식 채널을 통해 공개된 강연(Does Code Quality Still Matter? It Depends on This)에서, Capital One의 Executive Distinguished Engineer이자 전 Google 코드 헬스(Code Health) 총괄, 『Code Simplicity』의 저자인 맥스 카낫-알렉산더(Max Kanat-Alexander)는 이 질문에 명확한 공학적 판단 기준을 제시했습니다.

코드 품질이 존재해 온 유일한 이유: 이해와 안전한 변경

카낫-알렉산더는 소프트웨어로 달성하고자 하는 모든 성과(모델 정렬, 시스템 확장, 사용자 도입 등)가 결국 **이해(Understanding)**와 **그 이해에 기반한 실행(Execution)**이라는 두 가지 요소로 귀결된다고 설명합니다. 디버거, 관측성(Observability) 도구, 평가(Evals), 자동화 테스트 등 소프트웨어 공학이 발전시켜 온 모든 도구는 단지 "기분이 좋아지기 위해서"가 아니라 이 두 가지를 돕기 위해 존재합니다.

특히 소프트웨어 엔지니어에게 가장 중요한 두 가지 이해는 다음과 같습니다.

1. 시스템의 실제 동작은 무엇인가?: 설계 문서에 적힌 선언적 설명이 아니라, 실제 프로덕션에서 시스템이 구체적으로 어떻게 동작하는가에 대한 파악입니다.
2. 그 동작을 어떻게 안전하고 정확하게 변경할 것인가?: 크로미움(Chromium)처럼 수많은 컴포넌트가 얽혀 무한에 가까운 상호작용을 만드는 실제 시스템에서는 전체 동작을 한 문장으로 요약할 수 없습니다. 대신 URL 파서처럼 인식 가능한 구조(Structure)와 컴포넌트 경계가 있어야만 엔지니어(또는 에이전트)가 시스템을 부분별로 이해하고 수정할 수 있습니다.

시스템 변경이 수반하는 2가지 위험과 비선형 복리 누적

강연은 시스템을 수정할 때 발생하는 위험을 두 가지로 분류합니다.

• 현재의 문제 유발: 단순한 버그뿐 아니라 일정 지연, 예산 초과, 사용자 의도와 다른 동작 등 변경 과정에서 발생하는 모든 부정적 결과입니다. 이는 기존 시스템을 이해하기 어려울 때 발생합니다.
• 미래의 변경 난이도 상승: 이번 변경으로 인해 시스템 구조가 더 복잡해져, 다음번 수정 때 문제가 발생할 확률을 높이는 것입니다.

핵심은 두 번째 위험이 첫 번째 위험으로 되먹임되면서 이해의 난이도가 선형(Linear)이 아니라 비선형 복리(Non-linear Compounding)로 증가한다는 점입니다. 실제로 수많은 장애 사후 분석서(Postmortem)를 추적해 보면 결국 "프로덕션 설정이나 창발적 동작을 이해하기 불가능했다"는 원인으로 수렴하며, 수억 줄 규모의 노후화된 메인프레임처럼 어느 순간 모든 작은 수정이 장애와 조직적 마찰을 일으키는 상태에 도달하게 됩니다.

일회용 소프트웨어(Disposable) vs 지속형 소프트웨어(Durable)

카낫-알렉산더는 AI 코딩 모델이 가져온 가장 흥미로운 변화로 **일회용 소프트웨어(Disposable Software)**의 폭발적 증가를 꼽았습니다. 과거에도 일회성 스크립트는 존재했지만, AI 에이전트로 인해 이러한 범주의 소프트웨어가 기존보다 10만 배 이상 흔해지고 있다는 분석입니다.

그는 어떤 소프트웨어가 일회용인지, 아니면 전통적인 **지속형 소프트웨어(Durable Software)**인지를 판별하는 4가지 기준을 제시했습니다.

판별 기준	일회용 소프트웨어 (Disposable)	지속형 소프트웨어 (Durable)
1. 장애의 파급력 (Consequences)	실패하거나 멈춰도 비즈니스·안전에 미치는 피해가 거의 없음	장애 발생 시 심각한 금전적 손실이나 서비스 중단 초래
2. 교체 비용 (Cost of Replacement)	문제가 생기면 몇 시간~며칠 안에 에이전트로 전체를 새로 짜서 대체 가능	축적된 도메인 규칙과 상태 때문에 밑바닥부터 재작성하기 어려움
3. 의존성 규모 (Dependencies)	소수의 개인만 사용하며 다른 프로덕션 시스템이 이 코드에 의존하지 않음	수천~수백만 명의 사용자 또는 다수의 하위 시스템이 결합되어 있음
4. 유지보수 및 변경 관리 (Maintenance)	한 번 쓰고 버리거나(예: 1회성 행사 기획 앱) 유지보수 비용이 0에 수렴함	수년간 운영되며 지속적인 스키마 마이그레이션과 변경 관리가 필요함

네 가지 지표가 모두 낮다면 그 코드는 일회용 소프트웨어이며, 시간이 지나며 누적되는 복리 위험이 아예 존재하지 않으므로 코드 품질과 공학적 엄격성(Engineering Rigor)을 신경 쓸 필요가 없습니다. 반면 네 가지 지표가 높다면 지속형 소프트웨어이며, AI 시대에도 지난 수십 년간 축적한 소프트웨어 공학 원칙이 그 어느 때보다 중요해집니다. 숙련된 엔지니어라면 판단이 모호할 때 항상 지속형에 가깝다고 보수적으로 가정해야 합니다.

아키텍처 전략 1: 소프트웨어를 의도적으로 더 '일회용'으로 만들기

강연에서 주목할 만한 첫 번째 실무 해법은 모든 코드를 높은 품질로 만들려 애쓰는 대신, 시스템 구조를 설계해 일회용 소프트웨어의 허용 범위를 넓히는 것입니다.

• 격리된 실행 환경(Isolated Environments): 고객 데이터나 개인정보(PII)에 접근할 수 없고 본인 데이터만 다룰 수 있는 샌드박스 배포 환경을 제공합니다.
• 의존성 차단(Enforcing Independence): 다른 프로덕션 시스템이 해당 환경의 애플리케이션으로 인바운드 API 호출을 보내지 못하도록 네트워크·아키텍처 수준에서 차단합니다. 다른 시스템이 의존하지 못하게 막으면 그 코드는 언제든 안전하게 폐기할 수 있습니다.
• 신뢰할 수 있는 백업 계층(Redundancy): 다소 투박하더라도 견고하게 검증된 핵심 백엔드·백업 시스템을 유지하고, 그 위에서 현업 담당자들이 각자의 업무 효율을 위해 바이브 코딩(Vibe Coding)으로 맞춤형 프론트엔드를 만들어 쓰게 허용합니다. 임시 프론트엔드가 고장 나더라도 언제든 기본 시스템으로 돌아갈 수 있으면 실패 비용이 사라집니다.
• 범위 제한(Limiting Scope): 전사 공용 도구 대신 특정 팀이나 단일 이벤트를 위한 좁은 범위의 도구로 한정합니다.

아키텍처 전략 2: 엄격성의 비용(Cost of Rigor)을 낮추는 4가지 방법

처음에는 일회용 프로토타입으로 시작했으나 나중에 핵심 지속형 서비스로 전환해야 하는 경우가 많습니다. 이때 엔지니어링 엄격성을 확보하는 비용 자체가 낮다면, 스펙트럼상의 위치가 바뀌어도 손쉽게 내구성을 높일 수 있습니다. 카낫-알렉산더는 자신의 커리어에서 검증한 엄격성 비용 절감 전략 4가지를 공유했습니다.

1. 표준화를 통한 가능성 제거(Standardization): 사용하는 언어, 전후단 프레임워크, RPC 프로토콜의 가짓수를 제한합니다. 선택지를 줄이면 각 언어·프레임워크마다 별도의 린터, 보안 취약점 패치, 에이전트 도구를 중복 구축할 필요가 없어져 품질 유지 비용이 급감합니다.
2. 인워크플로 툴링(In-workflow Tooling): 개발자나 에이전트가 별도로 실행 방법을 고민하지 않아도 작업 흐름 안에서 자동으로 즉시 실행되는 도구입니다. 오탐(False Positive)이 적고 속도가 빨라 비용이 '0'처럼 느껴지면 일회용 코드에도 부담 없이 고품질 검증을 적용할 수 있습니다.
3. 누구나 쉽게 쓸 수 있는 테스트 인프라(Making Testing Easier): 개별 개발자가 테스트 전문가가 아니어도 빠르고 결정론적인(Deterministic) 테스트가 돌아가도록 기반을 닦는 일입니다. 특히 과거에는 각 서비스 팀이 테스트용 인메모리 페이크(In-memory Fake) 구현체를 함께 제공하는 것이 이상적인 꿈에 가까웠으나, 이제는 코딩 에이전트를 활용해 인메모리 페이크 서비스를 손쉽게 생성·유지할 수 있습니다.
4. 초기부터 최대 엄격성 적용(Maximum Strictness): 프로젝트 시작 시점부터 모든 린트(Lint)와 정적 검사 규칙을 최대 강도로 켜 두는 전략입니다. 100만 줄이 쌓인 뒤에 린터를 켜면 10만 줄의 수정 PR과 끝없는 논쟁이 발생하지만, 처음부터 최대 엄격성을 강제하면 불필요한 의사결정 비용과 미래의 잠재 결함을 동시에 제거할 수 있습니다.

강연은 세 가지 명쾌한 문답으로 마무리됩니다. "코드 품질은 여전히 중요한가? 일회용 소프트웨어에는 아니오(No), 지속형 소프트웨어에는 예(Yes). 그렇다면 코드 품질은 반드시 비싸야 하는가? 아니오(No)."

관련 자료

• AI Engineer 공식 YouTube — Does Code Quality Still Matter? It Depends on This (Max Kanat-Alexander)
• VIVO Wiki — Jev 에이전트 하네스: 구조화된 판단과 책임 분리
• VIVO Wiki — AI 에이전트 루프의 원리
• VIVO News — DHH가 밝히는 AI 에이전트 협업과 바이브 코딩, 소프트웨어 사업의 미래