AI demands more engineering discipline. Not less

Charity Majors의 Substack 글 분석. Charity Majors는 Datadog 공동 창업자이자 관측성(observability) 분야의 선구자다.

1. 원문 핵심 내용

코드 경제의 근본적 전환

2025년 말~2026년 초, AI 생성 코드의 질이 "중위 소프트웨어 엔지니어 수준"에 도달했다는 것이 업계의 합의로 자리 잡았다. Opus 4.5가 전환점으로 꼽히지만, 실제로는 2025년 내내 성숙한 에이전트 하니스(agentic harnesses — LLM을 도구와 루프에 감싼 시스템)가 축적 효과를 냈다.

결과는 간단하다. 코드 생산이 "효과적으로 무료"가 되면서, 코드의 성질이 완전히 바뀌었다. 과거엔 코드는 귀중했다 — 만들기도 어렵고 비쌌으니 재사용하고 다듬었다. 지금은 코드는 일회성(disposable)이고 재생성 가능(regenerable)하다. Charity의 표현을 빌리면 "코드는 자산이 아니라 캐시가 되었다 — 현재는 유용하지만, 낡으면 버려지는 materialized view(물리화된 뷰)"다.

Phoenix 아키텍처: 고치는 게 아니라 교체하기

Chad Fowler의 Phoenix 아키텍처 개념을 차용한다. 핵심 전제는 "동작하는 것을 고치지 마라, 교체하라"다. 코드 수정은 엔트로피(이동, 드리프트)를 축적하지만, 재생성은 초기 상태로 리셋한다.

여기서 삭제 테스트가 나온다. 구현 전체를 지운다고 상상했을 때 "존재론적 공포"를 느낀다면, 지식이 명세서나 테스트에 있는 게 아니라 코드 안에 갇혀 있다는 뜻이다. 지울 수 없다면 다음을 모른다는 것이다:

• 어떤 동작이 필요한지
• 어떤 실패가 용납되지 않는지
• 어떤 불변 조건(invariant)이 지켜져야 하는지
• 새 버전이 올바른지 어떻게 검증할지

"코드는 지식이 살 수 있는 유일한 장소일 때 귀중해진다."

진정한 산출물: 공유된 이해 vs 프로덕션

소프트웨어 팀의 "제품"이 무엇인지에 대한 철학적 분기점이다.

• 전통적 관점: 제품은 인간의 뇌에 저장된 "공유된 이해"다. 소프트웨어 개발을 고도로 집단주의적인 활동으로 만든다.
• SRE/신뢰성 관점: 제품은 "프로덕션"이다. "프로덕션만이 프로덕션이다. 프로덕션에서 테스트하지 않으면 거짓말을 사는 것이다." 인간의 기억은 시스템 상태를 담는 그릇으로 부적합하다 — 까먹고, 산만해지고, 드리프트한다. AI는 이 이해를 시스템 자체로 외부화할 것을 강요한다.

새로운 엔지니어링 학문들

검증(validation) vs 확인(verification)

• 인간은 검증(꼼꼼한 반복 확인)에 약하다. 기계가 검증에 뛰어나다.
• 인간 코드 리뷰를 정확성 게이트로 의지하는 것을 멈추고, 자동화된 평가와 관측성으로 전환하라.

프로덕션을 개발 단계로

• 프로덕션은 개발이 끝난 후의 것이 아니라 "개발의 한 단계"다.
• 필요한 실천: 트레이스 인스트루멘테이션, 프로덕션 내 테스트/평가, 행동 테스트(characterization tests), 캡처/재생, 트래픽 스플리터.

학문(discipline)의 귀환

• 2025년은 "바이브 코딩"의 해였다 — 불안정하고 광범위한 미래.
• 2026년은 학문의 귀환이다. 인간의 머릿속에 있는 지식은 시스템에 인코딩되지 않으면 AI에게 쓸 수 없다. 이 인코딩에 투자한 수익은 거대하고 비선형적이다.

결정론(determinism)의 중요성

사용자는 매일 버튼을 찾아다닐 준비가 되어 있지 않다. 금융 거래가 "대부분" 작동하는 것을 원하지도 않는다. 결정론은 어디에도 사라지지 않는다.

asbestos(석면) 비유

AI가 생성한 코드의 장기적 위험은 석면이나 납과 같다 — 당장은 무해해 보이지만, 나중에 제거하는 비용이 초기 건설 비용보다 훨씬 크다.

2. 커뮤니티 반응 (HN 192개 댓글 분석)

HN 토론은 크게 7가지 주제로 나뉜다.

(1) "더 많은 학문"의 의미 논쟁 (가장 뜨거운 쟁점)

kazinator: "더 많은 학문"이라는 말은 "더 높은 엄격성"을 의미해야 하는데, 실제로는 "동일한 엄격성으로 더 많은 시간"을 의미할 뿐이다.

nullorempty: Claude 세션에서 Claude가 "잠시만요, 프롬프트를 더 학문적으로 만드세요"라고 한 적이 없다. AI는 더 많은 학문을 요구하지 않는다. 다만 더 좋은 명세에서 더 잘 작동할 뿐이다.

deaton: AI는 더 많은 학문을 요구하면서도, 더 적은 학문으로 충분하게 만들어준다. 여기서 승자는 누구인가?

이들은 공통적으로 "학문(discipline)"이라는 단어의 모호함을 지적한다. 원문의 "학문"이 실제로 의미하는 것은 "명세화 작업의 증가"일 뿐, 기존 의미의 "엄격한 공학 관행"과는 다를 수 있다는 것이다.

(2) 코드 줄 수(LoC) 논쟁 — 가장 길고 격렬한 서브스레드

strix_varius가 "가장 효과적인 기여자는 추가하는 코드보다 제거하는 코드가 더 많다"고 주장하자, 4lx87가 "그건 구덩이를 파고 메우는 것이다"라고 반박했다.

gitremote가 실제 사례로 반박:

if (a || b) return true;
if (c) return true;
if (d) return true;
return false;

를 return a || b || c || d;로 정리한 것이 "구덩이 파기"가 아니라 "sidewalk 청소"라고 주장.

saltcured가 반박: 원래 코드가 각 조건에 도메인 시나리오 설명 주석이 달려있다면, 압축하는 것이 도메인 맥락을 파괴한다.

이 논쟁의 핵심은 "코드 줄 수 = 생산성"이라는 지표가 AI 시대에 더 무의미해졌다는 점에 대해서는 공감하지만, "코드를 줄이는 게 항상 좋은가"에 대해서는 의견이 갈린다.

(3) AI 코드의 품질과 리뷰 문제

ncruces: 경력이 긴 사용자가 LLM로 만든 ~200줄 PR을 일주일 동안 4가지 방식으로 리뷰했지만, 여전히 "어딘가 이상하다"는 느낌에서 벗어나지 못했다.

trjordan: "AI 코드를 하루 종일 읽는 것은 고통스럽다(agonizing)". 수동 프로그래밍의 "읽기→쓰기→수정" 피드백 루프가 AI 코딩에서 끊어지고, 뇌가 녹는다.

ryandvm: AI 시대에 "시스템을 이해하는 사람"과 "LLM copypasta를 뿌리는 사람"을 구분하기가 훨씬 어려워졌다. 모든 엔지니어가 완벽한 포맷팅과 표면적 타당성을 갖춘 PR을 제출한다.

cadamsdotcom: 인간을 품질 게이트에서 완전히 배제하는 것이 아니라 점근적(asymptotic) 접근이 필요하다. 자동화된 검증으로 1% → 0.1% → 0.01%로 줄여가되, 인간은 항상 루프 안에 있어야 한다.

(4) "코드는 명세가 아니다" vs "코드가 곧 명세"

younothing: "우리는 코드 생산의 노동이 병목이었기 때문에 코드를 영구적으로 취급했다"는 주장이 틀렸다. 코드를 영구적으로 취급한 이유는 "코드가 곧 진실의 원천(source of truth)"이기 때문이다. 컴퓨터는 문서가 아닌 코드를 실행한다. 요구사항 문서와 코드가 충돌하면 코드가 맞다고 가정한다. "코드를 명세와 분리할 수 없다. 코드가 곧 명세다."

이 주장에 대해 msteffen이 반박: 새 코드베이스에 진입할 때 "인간 문서"를 먼저 읽는 것이 훨씬 효율적이다. 시스템이 원래 무엇을 해결하려고 했는지, 원래 설계는 무엇이었는지 아는 것이 코드를 읽는 것을 훨씬 쉽게 만든다.

(5) AI 코딩의 실제 경험 — 양극화

긍정 측:

• K0balt: "문서 주도 개발(documentation driven development)"으로 전환. AI가 작성한 코드가 과거 시니어 리드였을 때보다 더 잘 쓰이고, 더 잘 문서화되고, 더 쉽게 추론 가능하다고 주장. 1/4 가격, 4배 속도.
• ManuelKiessling: AI가 문서/테스트/도구 작성을 도와주면서, "누군가(비록 영혼 없는 에이전트라도)이 내 문서를 실제로 읽고 따른다"는 느낌이 학문을 따르는 것을 더 보람 있게 만든다.

부정 측:

• workbox: 글 자체를 "길고 목적 없는(meandering and pointless)"라고 평가. "말은 많은데 실제로 말한 것은 거의 없다."
• stephbook: "AI slop 냄새가 난다."
• nielsbot: "말하기가 너무 어려워서 지쳤다. 글의 요점이 눈에 띄지 않았다."

(6) Anthropic의 AI 코딩 실험과 "Boris의 200 PR"

hintymad: Anthropic 엔지니어들이 더 이상 수동으로 코드를 작성하지 않으며, Boris(CTO)가 주로 휴대폰으로 일주일에 200개 이상의 PR을 머지한다.

romaniv: OpenAI의 "AI가 Erdős 추측을 반박했다"는 주장에 대해 "실제 인간 수학자들이(필즈 메달 수상자 포함) 결과를 검증하고 칭찬했다"는 반박에 대해, "OpenAI 웹사이트 자체의 설명이 인간 기여를 강조한다"며 논증의 신뢰성을 공격.

(7) 장기적 우려: 기술 부채와 "석면" 비유

protocolture: "불법이야? 당장 해. 그들이 퇴직하면 당신이 엉망을 정리하면 된다, AI가 있잖아." — 기술 부채를 갚지 못하면 "기술적 파산"으로 갈 수밖에 없다. 2030년에 그것이 어떤 모습일지 상상할 수 없다.

deadbabe: 결국 기술적 파산이 증가하면, "인간의 머리에 들어오는 코드베이스만"을 구축하는 새로운 운동이 생길 것이라고 예측.

aakresearch: 석면/납 비유에 동의. 하지만 AI의 유용성이 석면/화석연료보다 훨씬 낮았다는 슬픈 현실도 인정.

3. 새로운 시각

(1) "코드는 캐시" — AI 시대의 새로운 코드 메타포

Charity의 "코드는 캐시다"는 표현은 단순한 비유가 아니다. 데이터베이스에서 캐시는 "계산의 결과를 임시로 저장한 것"으로, 원본 데이터가 바뀌면 무효화된다. AI 시대에 코드도 마찬가지 — 명세서(원본 데이터)가 바뀌면 코드는 재생성(재계산)된다. 이 관점에서 "코드 리뷰"의 의미도 바뀐다. 캐시를 리뷰하는 것이 아니라, 원본 데이터(명세)와 캐시 검증(테스트)을 리뷰하는 것이 된다. 이는 cadamsdotcom의 "점근적 인간 검증" 접근과 자연스럽게 연결된다.

(2) "학문"의 재정의 — 명세화 능력이 새로운 해자

HN 댓글들에서 "학문이 뭐냐"는 반문은 오히려 중요한 통찰을 제공한다. AI 시대의 "학문"은 과거의 "엄격한 코딩 스타일"이 아니라 "명세화(specification) 능력"이다. 즉, "무엇이 필요한지 명확하게 정의하는 능력"이 새로운 엔지니어링 해자가 된다. 이는 K0balt의 "문서 주도 개발"과 ManuelKiessling의 "AI가 내 문서를 따른다"는 경험과 일치한다. 코드를 잘 쓰는 게 아니라, "무엇을 만들어야 하는지"를 잘 정의하는 사람이 승리한다.

(3) "삭제 테스트" — 코드 소유권의 새로운 기준

"코드를 다 지워도 괜찮은가"라는 질문은 AI 시대의 코드 소유권을 재정의한다. 과거엔 "내가 쓴 코드를 내가 안다"가 소유권이었다. AI 시대엔 "시스템의 요구사항을 명세로 정의할 수 있고, 코드를 지우고 다시 생성해도 테스트가 통과하는가"가 소유권이다. 이는 younothing의 "코드가 곧 명세" 주장과 충돌하는 것처럼 보이지만, 실제로는 상호 보완적이다 — 코드는 실행 가능한 명세(executable spec)가 되어야 하고, 동시에 명세는 코드에서 독립적으로 존재해야 한다. 두 가지가 모두 충족될 때 비로소 "삭제 테스트"를 통과한다.

4. 자녀/미래 영향

아인, 석현, 은한에게

1. 명세화 능력 = 새로운 문해력: 코드를 직접 쓰는 능력보다 "무엇이 필요한지 명확하게 정의하는 능력"이 더 중요하다. 이는 프로그래밍이 아닌 다른 분야에서도 동일하게 적용된다. 문제를 명확하게 정의하는 사람은 AI든 인간이든 그 해결을 의뢰할 수 있다.

1. "지우고 다시 시작할 수 있는 자신감": 코드가 아닌 명세서와 테스트에 지식을 두는 습관은, 어떤 작업을 하든 "결과물 자체에 집착하기보다 과정과 기준에 집착하는" 태도로 이어진다. 이는 AI 시대의 회복 탄력성(resilience)이다.

1. 검증자의 역할: AI가 생성하는 것이 많아질수록, "이것이 올바른지 판단하는 사람"의 가치가 높아진다. 아인이 디자이너가 되든, 석현이 개발자가 되든, 은한이 과학자가 되든 — "생성된 결과물의 품질을 판단하는 안목(taste)"이 핵심 역량이다.

1. 실용적 조언: 아이들이 코딩을 배울 때, "코드 쓰기의 즐거움"만 강조하지 말고 "무엇을 만들지 결정하는 과정"과 "어떻게 검증할지 생각하는 과정"도 함께 훈련하라. TDD(Test-Driven Development) 철학이 여기에 잘 부합한다 — 테스트(검증 기준)를 먼저 쓰고, 그 다음에 구현(코드)을 쓴다.

관련 노트

• 바이브코딩 시대, 왜 다시 DDD, TDD, 애자일인가 — 타이핑 비용→설계/검증 비용 전환
• OpenAI 하네스 엔지니어링 — 관측성·지식 구조화·엔트로피 관리
• AI 록스타 개발자들의 뒷정리 — AI 코드의 파편화 문제
• AI가 마취시키는 건 한 사람이 아니라 조직 전체다 — 인지적 점유권 침식
• LLM 지향 엔지니어링 — Yair Weinberger — slop feeds slop, 모델링=인간영역
• AI가 소프트웨어 엔지니어를 대체하지 않은 이유 — decide-execute-deliver 샌드위치
• AI 에이전트 하니스 아키텍처 — Tomasz Tunguz — 하니스=가축화 메타포, 7가지 구성 요소
• 에이전틱 코드 리뷰: AI가 만든 코드를 어떻게 검토할 것인가 — 의도 부재와 의도 재구성 비용