AI는 엔지니어링 규율을 덜이 아니라 더 요구함
AI는 엔지니어링 규율을 덜이 아니라 더 요구함
한 줄 요약
AI가 코드 생성 비용을 0에 가깝게 만들면서, 소프트웨어 개발의 핵심 가치는 '코드의 작성'에서 '행동의 검증과 시스템 이해의 규율'로 이동하며, 이는 의료 분야에서 진단보다 치료 계획의 검증과 재현성이 더 중요해지는 것과 유사한 패러다임 전환을 의미한다.
원문 핵심 내용
코드 생산 경제성의 역전: 자산에서 캐시로
2025년 말 Opus 4.5 및 에이전틱 하네스(Agentic Harnesses)의 등장으로 코드 생성의 경제성이 완전히 뒤집혔다. 과거에는 코드를 작성하는 노동이 병목이었기 때문에 코드 줄(Line of Code)은 소중히 보존하고 재사용해야 할 '자산(Asset)'이었다. 하지만 이제는 코드가 사실상 무료이고 즉각적으로 생성되므로, 코드는 더 이상 영구적인 자산이 아니라 '현재의 이해를 물질화한 재생성 가능한 캐시(Regenerable Cache)'가 되었다. 코드가 낡거나 불필요해지면 버리고 다시 생성하는 것이 비용 효율적이게 된 것이다. 이는 소프트웨어 개발이 '가산적(Additive, 3D 프린팅 비유)'에서 '감산적(Subtractive, CNC 밀링 비유)' 프로세스로 전환되었음을 의미한다. 형태(요구사항)는 동일하지만, 불필요한 부분을 제거하고 검증하는 과정이 핵심이 되었다.
불변 인프라(Immutable Infrastructure)의 애플리케이션 코드 확장
저자는 2013년 제시된 '불변 인프라' 개념을 애플리케이션 코드로 확장한다. 불변 인프라의 핵심 전제는 "실행 중인 것을 고치지 말고 교체하라(Never fix a running thing, replace it)"이다. 실행 중인 서버를 직접 수정(Mutation)하면 상태의 일관성이 깨지고(Drift), 유지보수가 불가능해진다. 따라서 서버는 컨테이너화하여 필요시 전체를 교체하는 '가축(Cattle)'으로 다룬다. AI 시대에는 이 논리가 코드 자체에도 적용된다. 코드를 제자리에서 수정하는 것은 엔트로피를 쌓지만, 전체를 재생성하여 교체하면 엔트로피가 리셋된다. Honeycomb에서는 매주 화요일 가장 오래된 Kafka 노드를 자동으로 죽이고 재생성하여 부트스트랩과 밸런싱 프로세스의 반복 가능성을 확보한다. 코드를 같은 방식으로 재생성할 수 없다면, 그 코드를 충분히 이해하지 못한다는 신호이다.
삭제 테스트(The Deletion Test)와 평가 문제
어떤 소프트웨어 시스템에 대해 "구현 전체를 삭제한다고 상상해 보세요"라는 테스트를 적용한다. 대부분의 엔지니어는 코드를 잃는 것을 실존적 공포로 느낀다. 하지만 이는 코드 자체를 두려워하는 것이 아니라, 다음 사항들을 모른다는 두려움이다:
- 요구되는 정확한 동작이 무엇인지
- 허용할 수 없는 실패 조건이 무엇인지
- 항상 지켜야 할 불변조건(Invariants)이 무엇인지
- 새 버전이 정확한지 판단하는 기준
- 잊힌 엣지 케이스를 고친 버그가 무엇인지
이것들은 코드의 문제가 아니라 '평가(Evaluation)의 문제'이다. 과거에는 코드가 이 모든 지식을 담고 있는 유일한 장소였기 때문에 귀중했다. 하지만 AI 시대에는 코드를 재생성할 수 있으므로, 지식은 코드 외부의 명세(Spec), 테스트, 관측 가능성(Observability) 도구들에 인코딩되어야 한다.
인간 뇌의 검증 한계와 규율의 복귀
인간의 뇌는 창의성과 논리적 도약에는 뛰어나지만, 반복적이고 사소한 차이를 확인하는 '검증(Validation)'에는 기계보다 약하다. AI가 생성한 비결정적(Nondeterministic) 코드를 프로덕션에 배포한다면, 인간이 코드 리뷰를 통해 품질 게이트를 지키는 방식은 더 이상 유효하지 않다. 대신, 트레이스 계측(Trace Instrumentation), 프로덕션에서의 테스트 및 평가(Production Evals), 캡처/재생(Capture/Replay) 등 '엔지니어링 규율(Engineering Discipline)'이 필수적이다. 2025년이 '바이브 코딩(Vibe Coding, 느낌에 의존한 코딩)'의 해였다면, 2026년은 규율로의 복귀의 해이다. 빠른 피드백 루프와 자동화된 검증이 없는 상태에서 AI만으로는 지속 가능한 가치를 만들 수 없다.
Hacker News 커뮤니티 반응
코드 리뷰의 본질적 변화: 코드 줄에서 설계로
많은 사용자가 AI 생성 코드를 리뷰하는 것이 고통스럽다고 공감했다. 과거에는 코드를 작성하는 과정 자체가 시스템 이해를 돕는 학습 과정이었지만, AI가 코드를 생성하면 개발자는 결과물만 읽게 되어 시스템의 정신 모델(Mental Model) 형성이 어렵다. 이에 대한 해결책으로 '설계 주도 개발(Design-Driven Development)'이 제안되었다. 즉, 코드 자체가 아닌 아키텍처 다이어그램, 요구사항 명세, 테스트 케이스 등을 리뷰하고, AI가 이를 기반으로 코드를 생성하는 방식으로 전환해야 한다는 것이다. 코드는 더 이상 리뷰의 주요 대상이 아니며, 검증의 대상은 시스템의 속성(Properties)과 행동(Behavior)이어야 한다.
기술 부채의 새로운 형태: AI 슬롭(AI Slop)과 검증의 부재
AI를 사용하여 대량의 코드를 빠르게 생성하면, 표면적으로는 완벽해 보이지만 내부적으로 일관성이 없는 '슬롭'이 생성될 위험이 있다. 특히 초보 개발자가 AI를 사용하면, 실수를 수정하는 과정에서 학습이 일어나지 않고 단순히 코드가 교정되므로 근본적인 이해가 부족해진다. 이는 장기적으로 치명적인 기술 부채를 축적할 수 있다. 일부 사용자는 AI가 생성한 코드가 인간이 작성한 스파게티 코드와 달리 'cthulhu의 알이 부화하는 듯한' 낯설고 복잡한 구조를 가진다고 표현하며, 이를 이해하고 유지보수하는 데 필요한 인지 부하가 오히려 증가할 수 있다고 경고했다.
엔지니어링의 재정의: 규율 vs. 노력
AI 시대에 필요한 '규율'이 단순히 더 많은 노력을 의미하는 것이 아님을 지적하는 의견이 있었다. 과거에는 복잡한 도구(GDB, Sanitizers 등)를 직접 다루는 능력이 중요했지만, 이제는 AI가 이러한 도구를 자동으로 활용하도록 지시하고, 그 결과를 검증하는 능력이 중요해졌다. 즉, 규율은 '수동적인 코딩'에서 '능동적인 검증과 설계'로 이동한다. 또한, AI가 코드를 생성하더라도 인간은 최종적인 책임과 판단을 내려야 하므로, '게으름(Laziness)'의 미덕이 오히려 강화되어야 한다는 의견도 있었다. 즉, 불필요한 에너지를 절약하기 위해 더 나은 자동화와 문서를 작성하는 것이 진정한 게으름이며, 이는 AI 시대에도 유효하다.
프로덕션에서의 검증: 테스트를 넘어 관측 가능성
단순히 유닛 테스트를 통과하는 것을 넘어, 프로덕션 환경에서의 실제 행동을 관측하고 검증하는 것이 중요해졌다. AI가 생성한 코드는 테스트 환경에서는 정상 작동하더라도, 프로덕션의 복잡한 조건(경쟁 조건, 네트워크 지연 등)에서 예기치 않게 실패할 수 있다. 따라서 트레이스, 로그, 메트릭 등 관측 가능성(Observability) 도구를 활용하여 프로덕션에서의 실제 동작을 지속적으로 모니터링하고, 이상이 발생하면 자동으로 코드를 재생성하거나 롤백하는 피드백 루프가 필수적이다. 이는 '프로덕션이 개발의 마지막 단계가 아니라 개발의 한 단계'라는 SRE(Service Reliability Engineering)의 철학과 일치한다.
새로운 시각
소프트웨어 공학에서 '진단(Diagnosis)'과 '치료 계획(Treatment Plan)'의 분리
의료 분야에서 의사는 환자의 증상(데이터)을 분석하여 진단(명세/Spec)을 내리고, 이에 기반하여 치료 계획(코드/Implementation)을 수립한다. 과거 소프트웨어 개발에서는 개발자가 직접 진단과 치료를 동시에 수행했다. 하지만 AI 시대에는 AI가 '치료 계획(코드)'을 작성하는 역할을 맡게 되고, 인간 엔지니어는 '진단(명세 정의)'과 '치료 효과 검증(테스트/관측)'에 집중해야 한다. 이는 의료에서 의사가 직접 수술(코드 작성)을 하는 것이 아니라, 로봇 수술 시스템(AI)이 정밀하게 수술하도록 하고, 의사는 수술 전 계획과 수술 중 모니터링(검증)에 집중하는 것과 유사하다. 따라서 소프트웨어 엔지니어의 핵심 역량은 코드를 작성하는 기술에서, 시스템의 상태를 정확히 진단하고 검증 가능한 명세를 작성하는 능력으로 이동한다.
'재생성 가능한 이해(Regenerable Understanding)'로서의 코드
과거 코드는 개발자의 의도와 지식이 응집된 '화석(Fossil)'이었다. 하지만 AI 시대에는 코드는 '일시적인 표현(Temporal Expression)'이 된다. 중요한 것은 코드 자체의 형태가 아니라, 코드가 생성된 배경인 '명세(Spec)'와 '검증 기준(Test/Invariant)'이다. 이는 의료 기록에서 환자의 현재 상태(코드)보다, 환자의 병력, 진단 기준, 치료 반응 데이터(명세/검증)가 더 중요해지는 것과 같다. 코드는 언제든지 재생성 가능하므로, 코드를 유지보수하는 비용보다 명세와 검증 체계를 유지보수하는 비용이 더 중요해진다. 따라서 조직은 코드 저장소보다 명세와 테스트 데이터를 더 엄격하게 관리해야 한다.
엔지니어링 규율의 민주화와 책임의 분산
AI가 코드 생성을 담당하면서, 코드 작성의 문턱이 낮아졌다. 하지만 이는 오히려 '검증의 문턱'을 높인다. 누구나 코드를 만들 수 있지만, 그 코드가 시스템의 불변조건을 위반하지 않는지 검증할 수 있는 사람은 여전히 한정적이다. 따라서 검증 능력(테스트 설계, 관측 가능성 분석, 아키텍처 이해)을 가진 엔지니어의 가치가 상대적으로 상승한다. 이는 의료에서 누구나 진단 기기(AI)를 사용할 수 있지만, 그 결과를 해석하고 임상적 판단을 내릴 수 있는 의사(엔지니어)의 역할이 더 중요해지는 것과 유사하다. 조직은 코드 작성 능력보다 검증 능력을 평가하는 지표로 전환해야 한다.
자녀와 미래에 대한 시사점
① 다음세대를 위한 교육: 코드 작성에서 시스템 사고로
미래의 교육은 프로그래밍 언어 구문(Syntax) 암기보다는 '시스템 사고(System Thinking)'와 '문제 정의(Problem Formulation)'에 집중해야 한다. AI가 코드를 작성해 주므로, 중요한 것은 '무엇을' 만들어야 하는지 명확히 정의하고, 그 결과가 '정확한지' 검증할 수 있는 능력이다. 자녀들에게 코딩을 가르칠 때, 단순히 프로그램이 돌아가는지 보는 것이 아니라, 왜 그 방식으로 설계했는지, 어떤 경우에 실패할 수 있는지, 어떻게 검증할 것인지에 대한 논리적 사고를 훈련시켜야 한다. 이는 의료 교육에서 단순한 수술 기술보다 임상 판단력과 진단 논리를 중요시하는 방향과 일맥상통한다.
② 준비해야 할 역량: 검증과 관측의 언어
자녀들이 미래에 직면할 세상은 '검증(Verification)'과 '관측(Observability)'이 핵심인 세상이다. 따라서 데이터 분석, 통계적 추론, 논리적 검증 능력을 키우는 것이 중요하다. AI가 생성한 정보나 코드를 맹목적으로 신뢰하지 않고, 비판적으로 검증할 수 있는 소양이 필요하다. 또한, 복잡한 시스템을 이해하기 위해 시각화 도구와 다이어그램을 활용하는 능력도 중요하다. 코드가 아닌 '설계도'와 '테스트 결과'를 통해 시스템을 이해하는 습관을 길러야 한다.
③ 의료 분야 함의: 진단 AI와 치료 검증의 분리
의료 분야에서도 AI가 진단(이미지 판독 등)을 지원하지만, 최종적인 치료 계획과 환자 관리의 검증은 인간 의사의 몫이다. AI가 생성한 치료 제안이나 약물 상호작용 분석 결과는 항상 임상적 맥락에서 검증되어야 한다. 의료 기록과 치료 계획은 '재생성 가능한 캐시'가 아니라, 환자의 생명과 직결된 '불변의 진실'에 가깝다. 따라서 의료 분야에서는 AI의 활용이 증가할수록, 오히려 진단의 정확성을 검증하고 치료의 안전성을 보장하는 프로토콜(규율)이 더 강화되어야 한다. 의사는 AI를 도구로 활용하되, 최종적인 책임과 검증의 주체로서 자신의 임상적 판단력을 유지해야 한다.