Orc Hwang's Wiki

개발 학습 기록과 기술 지식을 체계적으로 관리하는 개인 위키입니다.

Intent Debt: 에이전트가 대신 갚아줄 수 없는 단 하나의 부채 (Addy Osmani)

articles ai technical-debt agentic-engineering documentation

원문 정보

Addy Osmani가 Margaret-Anne Storey 등의 “Triple Debt” 연구를 받아, 에이전트 시대에 가장 비싸지는 부채가 무엇인지 짚은 글이다. agentic engineering이 실무로 들어온 지금 가장 현실적인 경고라 Articles에 담는다.

한 줄 요약 (TL;DR)

소프트웨어 건강을 갉아먹는 부채는 코드에 쌓이는 기술 부채(technical debt), 사람에게 쌓이는 인지 부채(cognitive debt), 그리고 산출물에 쌓이는 의도 부채(intent debt) 세 가지인데, 이 중 에이전트가 대신 갚아줄 수 없는 단 하나가 의도 부채이며 agentic engineering은 그 부채를 가장 비싸게 만든다.

왜 이 글을 골랐나

에이전트가 코드를 쏟아내기 시작하면서 우리는 “AI가 기술 부채까지 정리해 줄 것”이라는 막연한 기대를 품게 됐다. 이 글은 그 기대에 정확한 경계선을 긋는다. 부채를 세 종류로 나누고, 그중 사람만이 공급할 수 있는 입력(why)이 따로 있음을 보여준다. 같은 저자의 Loop Engineering이 “에이전트를 둘러싼 시스템(루프)을 설계하라”였다면, 이 글은 그 루프에 무엇을 먹여야 하는지에 대한 답이다. 코드가 commodity가 된 시대에 무엇이 사람의 몫으로 남는가라는, 이 위키가 반복해서 다뤄 온 질문과 정확히 맞닿는다.

핵심 내용

Triple Debt 모델: 세 가지 부채

이 글은 Margaret-Anne Storey 등의 논문 “From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI”를 토대로, 소프트웨어 부채를 사는 곳(어디에 쌓이는가)에 따라 셋으로 구분한다.

  • 기술 부채(technical debt) — 코드에 산다. 마감에 쫓겨 택한 지름길, 엉켜버린 모듈, 새는 추상화처럼, 나중에 시스템을 바꾸기 어렵게 만드는 구현 선택들의 누적이다.
  • 인지 부채(cognitive debt) — 사람에게 산다. 공유된 이해가 침식되는 것. 존재하는 코드의 양과 사람이 실제로 이해하는 양 사이의 간극이며, 팀·프로젝트 수준의 속성이다. 시스템을 안전하게 추론하고 바꾸기 위한 공유 멘탈 모델이 점점 부실해지는 상태다.
  • 의도 부채(intent debt) — 산출물에 산다(흔히 당신이 아예 쓴 적 없는 산출물에). 시스템이 왜 지금의 모습이 되었는지를 설명하는 외부화된 근거·목표·제약이 없거나 침식된 상태다.

핵심 주장: 에이전트가 갚을 수 없는 부채

세 부채 중 의도 부채는 에이전트가 당신 대신 갚아줄 수 없는 유일한 종류라는 것이 글의 핵심이다.

  • 에이전트는 의도를 생성할 수 없다. 의도는 반드시 사람에게서 와야 하는 단 하나의 입력이기 때문이다. 에이전트는 많은 것을 추론하지만 왜는 추론하지 못한다 — 그리고 그 왜를 가장 필요로 한다.
  • 에이전트는 분명히 추론을 한다. 그러나 그 추론은 보통 코드에 붙지 않고 버려진다. 그래서 리뷰어는 diff에 끝내 담기지 않은 근거를 처음부터 재구성해야 한다.
  • 외부화된 의도가 없으면 에이전트는 엉뚱한 목표를 최적화한다. 시스템이 현재 무엇을 하는지는 이해하지만, 무엇을 위한 것인지는 모른 채 움직인다.

왜 지금 갑자기 비싸지는가: 복리로 불어나는 이자

팀들은 오랫동안 높은 의도 부채를 안고도 무사했다. 그 부채를 머릿속과 낡은 문서에 담아 다녔기 때문이다.

  • 사실상 가장 오래 근속한 엔지니어가 “의도 문서” 그 자체였다. 비싸고 손실이 큰 방식이지만 어쨌든 작동했다. 새 사람이 들어오면 복도 대화와 코드 리뷰를 통해 사람에서 사람으로 지식이 넘어갔다.
  • 외부화되지 않은 의도는 예전엔 가끔만 비용을 청구했다. 온보딩 때, 혹은 누군가 떠난 뒤에만. 그런데 에이전트와 함께라면 그 비용을 세션마다, 돌리는 에이전트 수만큼 곱해서 매번 치르게 된다. 이자가 복리로 불어난다.

의도 부채를 갚는 법

글은 의도를 “바깥에 적어 두는” 구체적 처방을 제시한다.

  • AGENTS.md를 설정 파일이 아니라 ‘의도 원장(intent ledger)’으로 다뤄라. 의도 파일은 팀이 무엇을 의미하는지를 적는다 — 컨벤션, “우리는 이런 식으로 안 하는데 왜냐하면…”, 그리고 어느 한 파일에도 드러나지 않는 제약들.
  • 가벼운 ADR(Architecture Decision Record, 결정 로그)은 순수한 의도 부채 상환이다. 결정하는 그 순간 왜를 기록하는 비용은 거의 0에 가깝다. 에이전트에게 “무엇을 하려 했고 무엇을 배제했는지”를 진술하게 하고 그것을 PR의 결정 로그로 남기면, 재구성 비용의 상당 부분이 사라진다.
  • Skills: 의도를 “바깥에” 적어 둔 것. 컨벤션, 빌드 단계, “그때 그 사고 때문에 우리는 이렇게 안 한다” 같은 맥락을 한 번 적어 두면 에이전트가 매 실행마다 읽는다.
  • Spec-driven development. AI 코딩 품질은 보통 모델 계층에서 무너지기 전에 명세 계층에서 먼저 무너진다. 명세(spec)는 “how가 아니라 why”를 담는다.

분석과 인사이트

(여기부터는 원문 요약이 아니라 내 관점이다.)

이 글의 가장 큰 기여는 부채를 “사는 곳”으로 나눈 것이다. 우리는 그동안 모든 빚을 뭉뚱그려 “기술 부채”라 불렀다. 그런데 코드 부채는 에이전트가 리팩터링으로 줄여줄 여지가 크고, 인지 부채조차 에이전트가 코드를 설명·요약해 주며 일부 완화할 수 있다. 유일하게 남는 잔차(residual)가 의도 부채라는 분해는, 막연한 불안을 “그래서 사람이 정확히 무엇을 해야 하는가”라는 실행 가능한 질문으로 바꿔 놓는다.

특히 와닿는 건 “가장 오래 근속한 엔지니어 = 의도 문서”라는 진단이다. 많은 조직이 무의식적으로 이 사람-중심 의도 저장소에 의존해 왔고, 그래서 의도를 외부화할 동기가 없었다. 비용이 가끔만 청구됐으니까. 에이전트가 그 청구 주기를 “세션마다 × 에이전트 수”로 바꿨다는 통찰은 차갑지만 정확하다. 의도 외부화는 이제 “있으면 좋은 것”이 아니라 단위 경제(unit economics)가 강제하는 것이 됐다.

다만 한 가지 경계할 점. 처방 중 “에이전트에게 무엇을 배제했는지 진술하게 하라”는 부분은, 자칫 에이전트가 사후에 지어낸 합리화를 진짜 의도로 박제할 위험이 있다. 의도는 사람에게서 와야 한다는 글 자신의 전제와 긴장한다. 에이전트가 적는 것은 추론의 기록이고, 그것이 우리가 진짜 원했던 것과 일치하는지는 여전히 사람이 검증해야 한다. 즉 결정 로그는 의도의 대체물이 아니라, 사람이 검수해야 할 초안에 가깝다.

이 분해는 다른 글들과도 잘 들어맞는다. AI 엔지니어의 ‘취향(taste)’이 말한 “내부 평가 함수”란 결국 무엇을 위한 것인지에 대한 판단이고, 그게 바로 의도 부채를 갚는 사람의 능력이다. AI가 엔지니어를 대체하지 못하는 이유의 decide-execute-deliver 프레임에서 보면, 에이전트는 execute를 가져가지만 decide(=의도)는 사람에게 남는다 — 이 글은 그 “남는 부분”의 정체를 부채의 언어로 정밀하게 지목한 셈이다.

적용 포인트

  • AGENTS.md를 설정이 아닌 의도 원장으로 다시 써라. “어떻게 빌드하는가”뿐 아니라 “왜 이렇게 하는가”, “무엇을 안 하는가, 왜”를 담는다.
  • PR마다 결정 로그를 남겨라. 에이전트에게 “무엇을 하려 했고 무엇을 배제했는지”를 진술하게 하되, 사람이 그 의도가 맞는지 검수한 뒤 머지한다.
  • 결정 순간에 가벼운 ADR을 써라. 사후 정리가 아니라 결정하는 그 순간 한 줄 왜를 남기는 게 가장 싸다.
  • 반복되는 맥락은 Skills로 한 번만 외부화하라. “그때 그 사고 때문에 이렇게 안 한다” 류의 부족 지식(tribal knowledge)을 에이전트가 매 실행 읽도록 둔다.
  • spec부터 점검하라. 에이전트 결과물이 어긋날 때, 모델을 의심하기 전에 명세에 why가 빠지지 않았는지 먼저 본다.
  • “이 의도는 사람 머릿속에만 있는가?”를 위험 신호로 삼아라. 그렇다면 그것은 세션마다 청구될 부채다.

마무리

에이전트는 코드를 쓰고, 코드를 설명하고, 리팩터링으로 기술 부채와 인지 부채를 어느 정도 덜어줄 수 있다. 그러나 왜 이 시스템이 이런 모습이어야 하는가는 끝내 사람의 입력으로 남는다. Intent Debt가 던지는 메시지는 단순하다 — 에이전트 시대에 사람이 해야 할 가장 값진 일은 더 많은 코드를 만드는 것이 아니라, 의도를 바깥에 적어 두는 것이다. 그 이자는 이제 복리로 불어나기 때문이다.

더 읽어보기