AI는 엔지니어링 규율을 덜이 아니라 더 요구함

• AI 코드 생성 품질이 높아진 것은 코드 리뷰를 버리라는 신호가 아니라, 코드가 싸고 빠르게 재생성되는 환경에서 검증과 운영 규율을 더 강하게 요구함
• 2025년 말 Opus 4.5 이후 AI는 흔한 패턴에서 중간 수준 소프트웨어 엔지니어에 가까운 코드를 더 빠르고 저렴하게 만들 수 있게 되었고, agentic harness·도구 사용·function calling·MCP가 이 전환을 뒷받침함
• 코드 생산 비용이 거의 0에 가까워지면서 코드 줄은 귀중하게 보존할 자산이 아니라, 현재의 이해를 물질화한 재생성 가능한 캐시에 가까워짐
• immutable infrastructure가 실행 중인 서버를 고치지 않고 교체하게 만든 것처럼, AI 시대의 애플리케이션 코드도 변경 자체보다 행동 검증, characterization test, capture/replay, 트래픽 분할, 관측 가능성이 중요해짐
• 비결정적 시스템은 인간이 품질 게이트로 버티는 방식보다 trace, production eval, 빠른 피드백 루프 같은 엔지니어링 규율을 요구하며, AI는 소프트웨어가 여전히 기술자와 규율을 필요로 한다는 사실을 없애지 않음

2025년에 뒤집힌 코드 생산의 경제성

• 2025년 대부분 동안 AI 생성 코드는 “slop”이며 계속 그럴 수 있다는 입장이 합리적이고 주류적인 판단이었음
• 2025년 11월 Opus 4.5 이후, AI는 적어도 흔한 패턴에서는 중간 수준 소프트웨어 엔지니어와 비슷한 품질의 코드를 훨씬 빠르고 싸게 생성할 수 있게 됨
• Opus 4.5는 단일 원인이라기보다 티핑 포인트에 가까움
  • agentic harness는 LLM을 도구와 함께 루프에 넣는 코드 구조임
  • 이런 하네스는 2025년 중반 현실적인 형태가 되었고, 전조는 2024년 말까지 거슬러 올라감
  • tool use, function calling, MCP가 2025년 동안 쌓이며 연말에 범용 사용성으로 이어짐
• 첫 번째 변화에서 “보면 믿겠다”는 회의는 용인될 수 있었지만, 같은 속도의 변화가 다시 나타나는 상황에서는 같은 태도를 유지하기 어려움

코드가 귀한 자산에서 재생성 가능한 산출물로 바뀜

• 2025년에 일어난 핵심 변화는 코드 생산의 경제성이 뒤집힌 것임
  • 코드를 생성하는 일이 어렵고 오래 걸리고 비싸던 상태에서, 사실상 즉시 가능하고 저렴한 상태로 바뀜
  • 코드 줄은 재사용하고 보살피는 대상에서 버릴 수 있고 다시 만들 수 있는 대상으로 이동함
• 소프트웨어 엔지니어링 팀의 진짜 산출물을 공유된 이해로 보는 관점도 있음
  • 그 이해는 사람들의 머릿속에 캐시처럼 저장되고, GitHub 커밋과 프로덕션 배포로 디스크에 내려감
  • 하지만 사람의 기억은 잊기 쉽고, 반복에 무뎌지며, 작은 세부사항을 놓치기 쉬움
  • 머릿속 모델은 사용자가 실제로 만나는 세계와 계속 어긋남
• SRE 관점에서는 좋은 소프트웨어 팀의 진짜 산출물이 프로덕션에 있음
  • “Only prod is prod”
  • 프로덕션은 개발 이후의 장소가 아니라 개발의 한 단계로 다뤄져야 함

Phoenix Architecture와 immutable infrastructure의 유사성

• Honeycomb은 2025년 8월 AI mandate를 냈고, devtools 회사로서 최신 기술의 어려운 문제를 다뤄야 한다고 판단함
• Chad Fowler의 Phoenix Architectures는 AI 코드 시대를 immutable infrastructure와 연결함
  • Chad Fowler는 2013년에 “immutable infrastructure”라는 말을 만든 인물임
  • Relocating Rigor는 Martin Fowler가 Thoughtworks meetup 요약에서 언급한 글임
• The Death and Rebirth of Programming의 핵심은 실행 중인 것을 고치지 말고 교체하라는 원칙임
  • immutable infrastructure, stateless services, containers, blue-green deployments, infrastructure as code는 모두 같은 전제를 공유함
  • AI는 이 전제를 인프라에서 애플리케이션 코드로 확장함
  • 재작성 비용이 낮아지면 제자리 수정은 위험해지고, mutation은 엔트로피를 쌓으며, replacement는 그것을 리셋함
• The Deletion Test는 구현 전체를 삭제한다고 상상하게 함
  • 삭제가 두려운 이유는 코드 자체보다 필요한 동작, 허용할 수 없는 실패, 항상 지켜야 할 불변조건, 새 버전의 정확성 판단 기준을 모르기 때문임
  • 잊힌 엣지 케이스를 고친 버그가 무엇인지 모르는 것도 같은 문제임
  • 이는 코드 문제가 아니라 평가 문제임
• 코드가 지식이 사는 유일한 장소일 때 코드는 귀중해짐
  • 과거에는 코드를 만드는 노동이 병목이었기 때문에 코드를 영속적 자산처럼 다루는 것이 합리적이었음
  • 재생성이 쉬워지면 코드는 현재 유용하지만 낡으면 버릴 수 있는 이해의 물질화된 뷰처럼 작동함

서버를 재생성하듯 코드를 재생성할 수 있어야 함

• handcrafted server pets에서 immutable infrastructure cattle로 이동한 경험은 mutability가 이해의 적이라는 교훈을 남김
  • 실행 중인 산출물을 제자리에서 고치면 drift가 생김
  • drift는 시스템 유지보수를 어렵게 만듦
• Honeycomb은 매주 화요일 cron으로 가장 오래된 Kafka 노드를 죽임
  • 이 방식 때문에 부트스트래핑과 밸런싱 프로세스가 반복 가능하다는 확신을 가질 수 있음
  • 데이터는 재생성 가능하고, 중요한 약속은 다른 곳에 있음
• 코드를 같은 방식으로 재생성할 수 없다면 그 코드를 충분히 이해하지 못하는 신호임
  • 어떤 약속을 했는지 모름
  • 어떤 의존성이 깨질지 모름
  • 대부분은 깨뜨려 보면서 발견함
• 오래 걸리고 고통스러운 migration, rewrite, legacy code 교체, strangler fig는 코드 줄이 너무 많은 책임을 떠안았던 사례임
  • 코드에는 개발자 의도, 사용자 기대, 암묵적·명시적 동작, 과거 버그의 흔적이 함께 묶여 있었음

리뷰 대상은 코드 줄만이 아님

• 코드 줄을 유지하고 변경하는 비용이 컸기 때문에 다른 산출물들이 충분히 발전하지 못했음
  • 아키텍처가 어떻게 변하는지 이해하고 토론할 산출물이 부족함
  • 아키텍처 자체도 코드에서 어렴풋이 추론되는 경우가 많음
• 이상적인 방향은 아키텍처 다이어그램을 토론하고 합의한 뒤, 그 변경에서 코드를 재생성하는 방식에 가까움
• 모든 코드가 인간 이해를 우회해 AI가 명세대로 생성하게 된다고 단정할 수는 없음
  • 전체 가능성은 spec이 무엇인지, 또는 무엇이 될 수 있는지에 달려 있음
  • 고통스러운 데이터베이스 migration을 겪어 본 사람이라면 사용자 기대를 재생 가능하고 자동화 가능한 형태로 추출·형식화하는 일이 어렵다는 점을 알아야 함
• 도구는 아직 없지만 관련 아이디어는 이미 있음
  • 운영과 QA에서 온 behavioral test, characterization test, capture/replay, traffic splitter가 해당됨
  • 이 기법들은 무엇이 옳아야 하는지보다 실제로 무엇이 일어나고 있는지를 관찰하고 인코딩하는 데 가깝음
  • 좋은 의미의 observability가 여기에 포함됨

인간은 검증용 품질 게이트에 적합하지 않음

• 프로덕션의 비결정적 코드는 이전부터 했어야 할 일을 강제로 하게 만듦
  • trace 계측
  • production에서의 test와 eval
  • 프로덕션을 개발 이후가 아니라 개발 단계로 다루는 방식
• 사람의 뇌는 검증에 적합하지 않음
  • 반복적이고 사소한 차이를 계속 확인하는 일에서 기계보다 약함
  • 인간의 역할을 품질 게이트 능력에만 두면 소프트웨어 품질은 취약해짐
• 인간은 창의성, 영감, 논리적 도약 등에서는 오래 역할을 유지할 수 있지만, validation에서 기계를 이기는 주체로 두기는 어려움

AI 시대의 결론은 규율의 복귀

• 지난 2년의 AI 담론이 많은 엔지니어에게 낯설고 두려웠던 이유는, 일부 AI 목소리가 소프트웨어가 더 이상 엔지니어링 문제가 아니라고 말하는 것처럼 보였기 때문임
  • “SaaS is dead”
  • “Making AI great at coding was the strategy that unlocks everything else”
  • Adam Jacob은 소프트웨어 일자리의 큰 변화를 예상하는 인물로 다뤄짐
• 2025년이 vibe coding의 해였다면, 2026년은 규율로의 복귀처럼 보임
  • AI가 중간 수준 소프트웨어 엔지니어만큼 코드 줄을 생성하게 되면서 가능한 미래의 범위가 불안정하게 넓어졌음
  • 머릿속 지식은 시스템에 인코딩되기 전까지 AI가 사용할 수 없음
• 빠르고 짧은 피드백 루프에서 일하는 소프트웨어 팀은 매우 적음
  • 비율은 5% 정도, 확실히 10% 미만으로 제시됨
  • AI 도구는 이 방식을 이전보다 더 가까이 가져올 수 있음
• 엔지니어링 규율 없이 AI만으로 거대한 투자수익이 생기는 상황은 가까운 시기에는 우려 대상이 아님
  • 많은 팀이 시도하겠지만, 가치가 있는 것은 disposability가 아니라 durability에 의해 뒷받침됨
• 사용자는 매일 Slack에 로그인할 때 버튼과 메뉴가 미묘하게 바뀌는 것을 원하지 않음
  • 금융 거래가 대부분의 경우에만 완료되는 것도 원하지 않음
  • determinism은 사라지지 않음
• AI는 마법이 아니며, 소프트웨어는 여전히 엔지니어링임
  • 기술은 technologist를 필요로 함
  • 앞으로 검토해야 할 산출물은 코드 줄만이 아니라 다른 종류의 엔지니어링 산출물로 넓어짐