매일 아침 깃허브(GitHub, 코드 저장소)에는 AI가 생성한 수천 줄의 코드가 쌓인다. 개발자는 코드가 돌아가는 것을 확인하지만, 정작 시스템이 왜 그렇게 설계되었는지, 변경 시 어떤 부작용이 있을지 설명하기 어려워한다. 구현 속도는 빨라졌지만, 시스템의 '의도'는 코드 밖으로 휘발되고 있다. LLM(대규모 언어 모델)이 코드를 대량 생산하는 환경에서 팀이 시스템의 본질을 잃어가는 현상은 단순한 기술적 문제를 넘어, 시스템 건강을 위협하는 구조적 부채로 관찰된다.

기술·인지·의도 부채와 Tri-System 이론

최근 연구는 LLM 환경에서 발생하는 문제를 세 가지 부채로 정의한다. 첫째, 기술 부채(Technical debt)는 코드 자체의 구현 결정이 미래의 변경 가능성을 제한하는 현상이다. 둘째, 인지 부채(Cognitive debt)는 시스템에 대한 팀의 공유 이해가 코드 생성 속도를 따라가지 못해 발생하는 추론 능력의 저하다. 셋째, 의도 부채(Intent debt)는 시스템의 목표와 제약 조건이 기록되지 않아 인간과 AI 에이전트(AI가 스스로 판단해 작업을 수행하는 시스템)가 시스템을 진화시키기 어렵게 만드는 상태를 뜻한다. 이 세 가지 부채는 각각 코드, 사람, 아티팩트(시스템의 목표와 제약이 담긴 기록물) 차원에서 시스템의 건강을 갉아먹는다.

이러한 현상을 설명하기 위해 Kahneman의 사고 모델에 AI를 System 3로 추가하는 Tri-System 이론이 등장했다. System 1(직관)과 System 2(의도적 사고)에 이어, 외부의 인공 추론을 비판 없이 수용하는 '인지적 항복(Cognitive surrender)' 상태를 System 3로 규정한다. 이는 숙고 과정을 전략적으로 위임하는 '인지적 오프로딩(Cognitive offloading)'과는 명확히 구분된다. 연구팀은 실험실 환경에서 이 이론이 행동 예측에 유효함을 검증했다. 인간은 에너지를 아끼기 위해 직관에 의존하는 경향이 있는데, AI가 생성한 결과물을 검증 없이 수용할 때 인지적 항복이 발생하며, 이는 시스템의 장기적인 진화를 가로막는 원인이 된다.

구현에서 검증으로: 엔지니어링 조직의 재편

예전에는 엔지니어링의 가치가 '구현량'에 있었다면, 이제는 '검증(Verification)'으로 무게중심이 이동하고 있다. 코딩 에이전트가 코딩 비용을 낮출수록, 역설적으로 정확성을 판단하는 비용은 비싸진다. 자카르타와 호치민의 교통 상황에 따라 ETA(도착 예정 시간) 알고리즘의 성공 기준이 다르듯, 마이크로서비스(Microservices, 거대한 앱을 작은 단위로 쪼개 운영하는 방식) 환경에서는 '정확함'의 정의가 수천 개로 분화된다. 에이전트는 작업 결과에 대해 자동화된 검증이 있을 때 특히 잘 작동하므로, TDD(테스트 주도 개발, 테스트 코드를 먼저 작성하고 기능을 구현하는 방식)의 중요성은 더욱 커진다. 앞으로 엔지니어는 더 넓은 테스트 범위를 쉽게 이해할 수 있도록 돕는 테스트 하네스(Test harness, 테스트를 수행하기 위한 환경) 설계에 집중해야 한다.

조직 구조도 이러한 변화에 맞춰 재편되고 있다. 10명의 개발자가 기능을 만들던 팀은, 3명의 엔지니어와 7명의 검증 설계자(Acceptance criteria 정의, 테스트 하네스 설계, 결과 모니터링 담당)로 재구성될 가능성이 크다. 월요일 아침 스탠드업 미팅의 질문은 "무엇을 배포했는가"에서 "무엇을 검증했는가"로 바뀐다. 레거시 현대화(오래된 시스템을 최신 기술로 교체하는 작업)에 대한 기대도 재조정된다. 에이전트가 레거시를 최종적으로 해결할 것이라는 기대는 과대평가된 측면이 있다. 다만, 복잡한 레거시 코드가 무엇을 하는지 이해하는 '코드 분석' 측면에서는 LLM이 강력한 도구로 자리 잡고 있다.

소스 코드의 미래에 대해서도 논의가 활발하다. 일부는 LLM을 염두에 둔 새로운 언어를 실험 중이며, 다른 쪽은 TypeScript나 Rust 같은 엄격한 타입 언어가 LLM의 추론에 더 유리하다고 주장한다. DDD(도메인 주도 설계, 비즈니스 맥락을 코드로 옮기는 설계 방법론)의 유비쿼터스 언어처럼, 인간은 여전히 시스템의 의미를 붙잡고 유용한 추상화를 만드는 역할을 맡는다. 프로그래밍은 단순히 문법을 입력하는 일이 아니라, 문제를 집중된 조각으로 나누고 의도를 드러내는 이름을 선택하여 해결책을 형태화하는 작업이기 때문이다.

이제 엔지니어링의 본질은 코드를 짜는 행위가 아니라, AI가 생성한 결과물이 의도대로 작동하는지 증명하는 '검증 시스템'을 설계하는 일이다.