코드 품질 책을 쓴 캐피털 원 엔지니어의 16분 답 — AI가 짠 코드, 4가지만 보면 품질 챙길지 갈린다

한 줄 핵심

AI가 코드를 더 쉽게 만들수록 코드 품질은 여전히 중요하지만, 망가졌을 때의 대가·의존성·교체 비용·유지 비용이 낮은 일회용 소프트웨어와 높은 오래가는 소프트웨어를 구분해 엄밀함의 비용을 낮추는 방향으로 관리해야 한다.

시간별 요약

0:00
오프닝 — 코드 품질, 아직 중요할까 AI가 코드를 대신 짜는 시대에도 코드 품질이 여전히 필요한지에 대한 논쟁을 소개하고, 이 영상이 품질이 필요한 경우와 그렇지 않은 경우를 가르는 기준과 품질 비용을 낮추는 방법을 다룬다고 제시한다.
0:51
그때그때 달라요 — 그렇다면 무엇에 따라 달라지나 코드 품질이 중요하다는 답은 맥락 없이는 무의미하며, 판단은 결국 소프트웨어가 무엇을 해야 하는지와 어떻게 안전하게 바꿀 수 있는지에 따라 달라진다는 문제의식을 세운다.
1:57
품질 도구는 무엇을 위해 있나 — 이해와 안전한 변경 디버거, 관측성, eval, 테스트의 목적은 버그 자체보다 시스템을 더 잘 이해하고 그 이해를 바탕으로 안전하게 변경하는 데 있다. 소프트웨어 엔지니어에게 가장 중요한 것은 시스템의 실제 동작을 파악하는 능력과 그 동작을 안전하게 수정하는 능력이다.
3:48
크로미움 · URL 파서 · 어셈블리 — 구조가 중요한 이유 작은 프로그램은 단순히 설명할 수 있지만, Chromium처럼 거대한 코드베이스는 부분별 구조가 없으면 전체 동작을 설명할 수 없다. 코드의 핵심 가치는 명령의 나열이 아니라 사람이 이해할 수 있는 구조를 제공하는 데 있다.
6:16
변경의 두 위험 — 포스트모템과 메인프레임 대규모 시스템을 고칠 때의 위험은 변경 과정 자체의 문제와, 그 변경이 미래의 변경을 더 어렵게 만들어 후속 위험을 키우는 것이다. 포스트모템과 오래된 메인프레임 사례는 이해의 어려움이 시간이 갈수록 누적되어 수정 비용을 폭증시킨다는 점을 보여준다.
8:37
미래 모델이 해결할까 — 일회용 소프트웨어와 네 가지 기준 미래 모델이 복잡성을 해결할 수도 있지만, 지금 당장 더 중요한 것은 일회용 소프트웨어의 확산이다. 소프트웨어를 망가졌을 때의 대가, 의존성, 교체 비용, 유지 비용 네 가지 기준으로 보고, 이 값이 낮으면 품질 엄밀함이 거의 필요 없는 소프트웨어가 된다고 정리한다.
12:10
일회용성을 높이는 법 — 격리 · 독립 · 중복 · 범위 제한 폭발 반경을 줄이고, 특정 데이터에만 접근하게 격리하며, 다른 생산 시스템과의 의존성을 끊고, 대체 가능한 백업을 두고, 사용 범위를 좁히면 소프트웨어의 일회용성이 높아진다. 이렇게 하면 실패해도 큰 문제가 없는 시스템으로 만들 수 있다.
13:56
오래 쓰는 소프트웨어는 사라지지 않는다 — 엄밀함의 비용 AI가 쓴 코드도 수십억 명이 쓰는 오래가는 시스템에 들어가므로 durable software engineering은 사라지지 않는다. 중요한 것은 소프트웨어가 일회용인지 오래가는지의 이분법이 아니라, 엄밀함을 적용하는 비용을 얼마나 낮출 수 있는지다.
15:48
표준화와 작업 흐름 안의 도구 표준화는 선택지를 줄여 엄밀함의 비용을 낮추고, 작업 흐름 안의 도구는 개발자가 따로 의식하지 않아도 자동으로 실행되어 신뢰성과 속도를 높인다. 프레임워크, 프로토콜, 포맷터, 자동 검사 같은 장치는 반복적인 판단과 예외 처리를 줄이는 데 핵심적이다.
17:26
쉬운 테스트, 최대한 엄격한 규칙 — 그리고 맥스의 답 불안정한 테스트를 줄이려면 in-memory fake service처럼 빠르고 결정적인 테스트 인프라를 만들고, 린트 규칙은 최대한 엄격하게 적용해 초기부터 문제를 제거해야 한다. 이렇게 하면 테스트를 누구나 쉽게 하고, 이후의 대규모 수정 비용을 크게 줄일 수 있다.
20:02
마무리 — 네 가지 기준과 비용 낮추기 코드 품질이 필요한지 여부는 망가졌을 때의 대가, 의존성, 교체 비용, 유지 비용 네 가지로 판단할 수 있다. 처음엔 일회용으로 보인 코드도 팀이 쓰기 시작하면 오래가는 시스템이 될 수 있으므로, 표준·자동화·쉬운 테스트·엄격한 규칙으로 미리 엄밀함 비용을 낮춰야 한다.

실무 인사이트

AI 코드는 '잘 쓰는 것'보다 '나중에 오래 쓰게 될 가능성'을 기준으로 관리해야 하며, 처음부터 표준과 자동 검사를 넣어 전환 비용을 낮추는 것이 중요하다.
품질 논쟁은 추상적인 찬반보다 네 가지 기준으로 판단해야 실무에서 재현 가능한 의사결정이 된다.
테스트와 린트는 개발자에게 인내를 요구하는 도구가 아니라, 인프라와 규칙 설계로 '생각하지 않아도 되게' 만드는 방향으로 바꿀수록 효과가 커진다.