기술 부채, 인지 부채, 의도 부채

3 days ago 6

LLM이 코드를 대량 생산하는 환경에서는 코드 자체의 문제만이 아니라 팀의 공유 이해와 시스템 목표 기록까지 함께 약해지며, 이를 기술 부채·인지 부채·의도 부채의 세 층으로 나눠 다룰 필요가 커짐
Technical debt는 미래 변경 가능성을 제한하고, Cognitive debt는 팀이 시스템 변경을 추론하는 능력을 약화시키며, Intent debt는 목표와 제약의 기록이 흐려져 인간과 AI 에이전트의 지속적 진화를 가로막음
AI를 System 3로 놓는 Tri-System 이론은 외부 인공 추론을 비판 없이 신뢰해 숙고를 건너뛰는 cognitive surrender를 구분하며, 전략적으로 인지를 위임하는 cognitive offloading과는 다르게 봄
코딩 비용이 낮아질수록 비싸지는 것은 verification이며, 정확성과 성공의 기준은 교통 ETA, 기사 배차, 수백 개 마이크로서비스 운영처럼 맥락마다 달라져 인간의 판단과 검증 체계 설계가 더 중요해짐
엔지니어링의 중심축은 구현량보다 검증으로 이동하고, 앞으로도 인간은 유용한 추상화와 이름 짓기, acceptance criteria와 test harness 설계처럼 시스템의 의미를 붙잡는 역할을 계속 맡게 됨

세 가지 부채와 시스템 건강

LLM이 대량의 코드를 만들어내는 환경에서는 팀이 시스템이 무엇을 하는지에 대한 이해를 잃기 쉬우며, 이를 Cognitive Debt로 보는 관점이 커지고 있음
세 가지 시스템 건강 계층은 부채를 코드, 사람, 아티팩트 차원으로 나눔
- Technical debt는 코드에 존재하며, 구현 결정이 미래 변경 가능성을 해칠 때 쌓이고 시스템이 어떻게 바뀔 수 있는지를 제한함
- Cognitive debt는 사람에게 존재하며, 시스템에 대한 공유 이해가 보충되는 속도보다 더 빨리 약해질 때 쌓이고 팀이 변경을 추론하는 능력을 제한함
- Intent debt는 아티팩트에 존재하며, 시스템을 이끌어야 할 목표와 제약이 제대로 기록되거나 유지되지 않을 때 쌓이고 원래 만들고자 했던 바를 계속 반영하는지, 또 인간과 AI 에이전트가 시스템을 효과적으로 계속 진화시킬 수 있는지를 제한함
이 관점은 각 부채를 진단하고 완화하는 섹션까지 포함하며, 세 부채가 서로 상호작용한다는 점도 함께 다룸
팀은 이 세 부채를 통제하기 위한 일반 활동을 함께 수행해야 함

Tri-System 이론과 인지적 항복

LLM을 Kahneman의 두 시스템 사고모델에 추가하는 논문은 AI를 System 3로 놓고 사고 체계를 확장함
System 1은 직관으로 빠르게 결정을 내리고, System 2는 문제를 의도적으로 사고하는 단계로 구분됨
- 에너지를 아끼기 위해 인간은 기본적으로 직관에 의존하는 경향이 있으며, 그 결과 숙고했다면 발견했을 요소를 놓칠 수 있음
System 3의 결과로 cognitive surrender가 등장하며, 이는 외부에서 생성된 인공 추론을 비판 없이 신뢰해 System 2를 우회하는 상태로 규정됨
- 논문은 이를 cognitive offloading과 구별함
- cognitive offloading은 숙고 과정에서 인지를 전략적으로 위임하는 행위로 다뤄짐
이 논문은 Tri-System theory of cognition을 자세히 전개하고, 최소한 실험실 환경에서는 이 이론이 행동 예측에 얼마나 유효한지도 여러 실험으로 검증함

코드 아이콘으로서의 <> 표기

최근 몇몇 일러스트는 코드 아이콘으로 “<>” 기호를 사용하지만, 이 표기는 프로그래밍 언어 요소를 감싸는 표기로는 낯설게 보임
“{ }” 같은 다른 기호가 아니라 “<>”가 쓰이는 이유는 HTML 또는 XML을 떠올리기 때문으로 읽힘
“</>” 형태까지 쓰는 경우에는 HTML을 더 직접적으로 연상시키지만, HTML은 프로그래머가 프로그램을 작성하는 언어로 다뤄지지 않음

코딩이 싸지면 비싸지는 것은 검증

if coding agents make coding free, what becomes the expensive thing는 코딩 에이전트가 코딩 비용을 낮출수록 비싸지는 요소는 verification이라고 봄
정확성의 기준은 맥락마다 계속 달라짐
- Jakarta 교통에서의 ETA 알고리듬과 Ho Chi Minh City 교통에서의 ETA 알고리듬은 “correct”의 의미가 다를 수 있음
- 기사 배차에서는 수익의 공정성, 고객 대기 시간, 차량 활용률을 동시에 맞춰야 하므로 “successful”의 정의가 하나가 아니라 여러 개가 됨
- 수백 명의 엔지니어가 약 900개의 마이크로서비스에 계속 배포하는 환경에서는 “correct”가 하나의 정의가 아니라 수천 개의 정의로 분화되며, 모두 계속 바뀌고 맥락 의존적임
이런 판단은 에이전트가 대신할 수 없는 작업으로 놓임
에이전트는 작업 결과에 대해 좋고 가능하면 자동화된 검증이 있을 때 특히 잘 작동하는 흐름이 커지고 있음
- 이런 흐름은 Test Driven Development를 장려함
- 여전히 해야 할 검증량은 많으므로, 사람이 더 넓은 테스트 범위를 쉽게 이해할 수 있도록 돕는 방법에 더 많은 노력이 필요함
레거시 현대화에 대해서는 일부 이견도 함께 제시됨
- agentic coding이 레거시 현대화를 최종적으로 해결할 것이라는 기대는 과대평가되어 있음
- 다만 understanding what legacy code is doing 측면에서는 LLM이 큰 도움을 준다는 강한 근거가 있음

검증 중심 조직으로의 재편

에이전트가 실행을 맡으면 인간의 일은 verification system 설계, quality 정의, 그리고 에이전트가 해결하지 못하는 모호한 경우를 처리하는 쪽으로 이동함
조직 구조도 이 변화에 맞춰 바뀌어야 함
- 월요일 아침 스탠드업의 질문은 “무엇을 배포했는가”보다 “무엇을 검증했는가”가 중심이 됨
- 출력량 추적보다 결과가 정확했는지를 추적하게 됨
기능을 만들던 10명의 엔지니어 팀은 3명의 엔지니어와, acceptance criteria 정의, test harness 설계, outcome 모니터링을 맡는 7명으로 재구성될 수 있음
이런 재편은 만드는 행위의 위상을 낮추고 판단하는 행위의 위상을 높이기 때문에 불편하게 느껴질 수 있음
이런 변화를 거부하지 않는 엔지니어링 문화가 더 잘해낼 가능성이 큼

소스 코드의 미래와 LLM 친화적 언어

LLM을 프로그래머처럼 다루는 흐름 속에서 소스 코드의 미래 자체가 질문으로 떠오름
several views of the future of code는 코드의 미래를 둘러싼 여러 관점을 모아 다룸
- 일부는 LLM을 염두에 두고 설계한 완전히 새로운 언어를 실험 중임
- 다른 쪽은 기존 언어, 특히 TypeScript와 Rust 같은 엄격한 타입 언어가 LLM에 더 잘 맞을 수 있다고 봄
이 글은 인용이 많고 자체 분석은 많지 않지만, 논의 전반을 훑는 개관 자료로 읽을 만함

인간이 맡는 추상화와 이름 짓기

LLM과 함께 소프트웨어를 만드는 과정에서도 인간은 코드가 무엇을 하는지 이야기할 수 있는 유용한 추상화를 만드는 역할을 계속 맡게 됨
이는 DDD의 Ubiquitous Language와 연결됨
growing a language는 LLM과 함께 언어를 키워가는 방식을 다룸
프로그래밍은 컴퓨터가 이해하고 실행할 수 있는 코딩 문법을 입력하는 일만이 아니라 해결책을 형태화하는 작업이기도 함
- 문제를 집중된 조각으로 나누고, 관련 데이터와 동작을 함께 묶으며, 의도를 드러내는 이름을 선택하게 됨
- 좋은 이름은 복잡성을 가르고 모두가 따라갈 수 있는 도식으로 코드를 바꾸며, 문제 구조와 해결 구조를 선명하게 연결해 줌