데모는 항상 동작한다

모든 AI coding 데모는 같은 흐름을 따릅니다. 누군가 모델에 프롬프트합니다. 동작하는 앱이 나타납니다. 청중은 감탄합니다.

감탄할 만합니다. 속도는 실제입니다. 능력도 실제입니다. 버전 1은 AI가 루프에 있을 때 진짜로 더 빠르게 배포됩니다.

문제는 버전 1이 결코 어려운 부분이 아니었다는 것입니다.

비용이 실제로 집중되는 곳

소프트웨어 엔지니어링 비용은 초기 생성에 집중되지 않습니다. 네 번째, 다섯 번째, 여섯 번째 반복에 집중됩니다:

  • 가격 체계가 바뀌어서 인증 제공자를 변경해야 합니다.
  • 벤더가 인수되어서 분석 도구를 이전해야 합니다.
  • 초기 생성에서 예상하지 못한 세 화면에 걸친 기능을 추가해야 합니다.
  • 디자이너가 방향을 바꾸어서 스타일링 시스템을 교체해야 합니다.
  • 제품이 새 시장으로 확장되어서 결제 연동을 바꿔야 합니다.

이 중 어느 것도 초기 생성의 실패가 아닙니다. 모두 정상적인 제품 개발입니다. 질문은 codebase가 이 변경들을 싸게 만드느냐 비싸게 만드느냐입니다.

변경 압력 하의 AI 생성 codebase

대부분의 AI 생성 codebase는 첫 번째 변경을 잘 처리합니다. 두 번째 변경은 불편합니다. 네 번째 변경쯤이면 팀들이 같은 증상을 보고하기 시작합니다:

  • “인증 제공자를 바꾸라고 AI에게 요청했는데 14개 파일을 건드렸습니다.”
  • “refactor가 관계없어야 할 module들의 테스트를 깨뜨렸습니다.”
  • “시스템의 어떤 부분이 분석 SDK에 의존하는지 알 수 없습니다.”
  • “모든 변경이 전체 codebase를 다시 이해해야 합니다.”

이 증상들은 모델의 실패가 아닙니다. 아키텍처의 실패입니다. 모델이 경계 없는 시스템을 생성했고, 이제 모든 변경의 blast radius가 예측 불가능합니다.

AI codebase가 더 빨리 악화되는 이유

전통적인 codebase도 악화됩니다. 하지만 AI 생성 codebase는 특정한 이유로 더 빨리 악화됩니다:

공유된 정신 모델이 없습니다. 인간 팀은 몇 달에 걸쳐 구조적 직관을 쌓습니다. AI는 이전 결정의 이유에 대한 기억 없이 코드를 생성합니다.

즉각적 프롬프트에 대한 최적화. 모델은 현재 요청을 해결합니다. 다음 다섯 개의 요청을 위해 최적화하지 않습니다. 모든 생성이 국소적으로는 올바르지만 전역적으로는 비일관적인 결정을 만듭니다.

볼륨이 결합을 증폭합니다. AI는 더 많은 코드를 더 빠르게 생성합니다. 약한 경계를 가진 더 많은 코드는 더 많은 결합을 더 빠르게 만듭니다. 속도 이점이 악화 가속기가 됩니다.

refactor에는 전역 컨텍스트가 필요합니다. 모델은 전체 codebase에 걸친 refactor에 어려움을 겪습니다. 컨텍스트 윈도우가 유한하고 아키텍처 의도가 암묵적이기 때문입니다.

진짜 엔지니어링 과제

AI-native 개발에서 진짜 엔지니어링 과제는 “어떻게 더 나은 코드를 생성하는가?”가 아닙니다.

“AI가 생성한 부분들을 독립적으로 변경할 수 있도록 시스템을 어떻게 구조화하는가?”입니다.

이것이 의미하는 바:

  • blast radius를 예측 가능하게 만드는 경계.
  • 변하는 것과 유지되는 것을 분리하는 interface.
  • 의존성 그래프를 명시적으로 만드는 composition root.
  • 전체 시스템 없이도 통합을 검증하는 contract tests.
  • 연쇄 장애 없이 어떤 module이든 삭제하고 재생성할 수 있는 능력.

장기 유지보수는 구조적 문제다

모든 module이 다른 모든 module의 내부에 접근하는 codebase에서는 아무리 좋은 프롬프트도 소용없습니다. 아키텍처 결합에서 프롬프트로 빠져나올 수는 없습니다.

장기적 AI codebase 유지보수는 항상 필요했던 것과 같은 규율을 요구합니다: 경계, contracts, 격리. 차이점은 AI 속도가 이 규율의 부재를 더 빨리 가시화한다는 것입니다. 유지보수 불가능한 모놀리스를 만드는 데 2년이 걸렸을 팀이 이제 2개월 만에 할 수 있습니다.

속도는 선물이자 함정입니다. 구조 없이는, 유지보수 위기에 더 일찍 도달하는 것에 불과합니다.

AI-Native 아키텍처와의 연결

이것이 Stanford CS146S는 AI coding을 제대로 보고 있다 — 빠진 과목은 아키텍처다에서 제가 펼친 핵심 주장입니다: 아키텍처 규율 없는 도구 숙련도는 만들기 빠르고 유지하기 비싼 codebase를 만듭니다.

현대 소프트웨어 개발자에게는 둘 다 필요합니다. 빠르게 배포하기 위한 AI 도구. 버전 1 이후에도 계속 빠르게 배포하기 위한 아키텍처 규율.

버전 1은 결코 문제가 아니었습니다. 문제는 버전 5가 여전히 싸냐는 것입니다.

FAQ

AI 생성 codebase는 왜 유지보수하기 어려워지나요?

AI 모델은 즉각적 프롬프트에 최적화하지 미래의 변경에 최적화하지 않습니다. 이는 동작하지만 독립적 수정에 필요한 경계가 부족한 코드를 만들어냅니다. 명시적 아키텍처 제약 없이는 결합이 수작업 codebase보다 빠르게 축적됩니다. AI가 더 많은 코드를 더 빠르게 생성하기 때문입니다.

AI codebase의 시간에 따른 악화를 어떻게 방지하나요?

세 가지 구조적 실천입니다: 애플리케이션이 소유하는 interface로 module 경계를 enforcement하고, composition root에 의존성 배선을 집중하고, 통합 지점을 독립적으로 검증하는 contract tests를 실행합니다. 이것들이 코드가 어떻게 생성되었든 변경 비용을 예측 가능하게 만듭니다.

AI 생성 코드가 사람이 작성한 코드보다 refactor하기 어려운가요?

본질적으로는 아닙니다. 하지만 AI 생성 코드는 refactor를 안전하게 만드는 구조적 경계가 부족할 가능성이 더 높습니다. 모델이 자발적으로 미래 변경을 위해 최적화하지 않기 때문입니다. 해결책은 생성 전에 그 경계를 부과하는 것이지, 모델이 알아서 만들기를 바라는 것이 아닙니다.

장기 프로젝트에서 AI coding의 가장 큰 위험은 무엇인가요?

가장 큰 위험은 속도 함정입니다: 초기 단계에서 너무 빠르게 배포하여 팀이 알아차리기 전에 아키텍처 부채가 축적됩니다. 유지보수가 비싸질 때쯤이면 codebase가 너무 결합되어 점진적으로 고칠 수 없게 됩니다.