<div id="readability-page-1" class="page"><div>
    <article>
        

        <div>
            <h2 id="원문-정보">원문 정보</h2>

<blockquote>
  <ul>
    <li><strong>제목</strong>: The Intent Debt</li>
    <li><strong>출처</strong>: Addy Osmani (<a href="https://addyosmani.com/blog/intent-debt/">addyosmani.com</a>, Substack <em>Elevate</em>에도 게재)</li>
    <li><strong>발행</strong>: 분량 표기 없음 · 약 8~10분 분량</li>
    <li><strong>원문 링크</strong>: <a href="https://addyosmani.com/blog/intent-debt/">https://addyosmani.com/blog/intent-debt/</a></li>
  </ul>
</blockquote>

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

<h2 id="한-줄-요약-tldr">한 줄 요약 (TL;DR)</h2>

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

<h2 id="왜-이-글을-골랐나">왜 이 글을 골랐나</h2>

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

<h2 id="핵심-내용">핵심 내용</h2>

<h3 id="triple-debt-모델-세-가지-부채">Triple Debt 모델: 세 가지 부채</h3>

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

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

<h3 id="핵심-주장-에이전트가-갚을-수-없는-부채">핵심 주장: 에이전트가 갚을 수 없는 부채</h3>

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

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

<h3 id="왜-지금-갑자기-비싸지는가-복리로-불어나는-이자">왜 지금 갑자기 비싸지는가: 복리로 불어나는 이자</h3>

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

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

<h3 id="의도-부채를-갚는-법">의도 부채를 갚는 법</h3>

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

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

<h2 id="분석과-인사이트">분석과 인사이트</h2>

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

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

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

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

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

<h2 id="적용-포인트">적용 포인트</h2>

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

<h2 id="마무리">마무리</h2>

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

<h3 id="더-읽어보기">더 읽어보기</h3>

<ul>
  <li><a href="https://addyosmani.com/blog/intent-debt/">원문 — The Intent Debt (Addy Osmani)</a></li>
  <li><a href="https://arxiv.org/abs/2603.22106">Triple Debt 논문 — From Technical Debt to Cognitive and Intent Debt (Storey et al.)</a> — ACM Queue 게재본: <a href="https://queue.acm.org/detail.cfm?id=3807966">https://queue.acm.org/detail.cfm?id=3807966</a></li>
  <li><a href="/2026/06/19/loop-engineering.html">Loop Engineering (Addy Osmani) 정리</a> — 같은 저자가 말한 “에이전트를 둘러싼 루프 설계”, 그 루프에 의도를 먹이는 이야기</li>
  <li><a href="/2026/06/19/ai-engineer-taste.html">AI 엔지니어의 ‘취향(taste)’ 정리</a> — 의도를 판단하는 사람의 내부 평가 함수</li>
  <li><a href="/2026/06/19/ai-hasnt-replaced-engineers.html">AI가 엔지니어를 대체하지 못하는 이유 정리</a> — decide(의도)는 사람에게 남는다는 프레임</li>
  <li><a href="/2026/06/19/martin-fowler-fragments-llm-era.html">Martin Fowler의 Fragments로 읽는 LLM 시대</a> — LLM 시대 프로그래밍에 대한 균형 감각</li>
</ul>

        </div>

        
    </article>

    
</div></div>

Orc’s WIKI

Orc Hwang

원문 정보
제목: The Intent Debt
출처: Addy Osmani (addyosmani.com, Substack Elevate에도 게재)
발행: 분량 표기 없음 · 약 8~10분 분량
원문 링크: https://addyosmani.com/blog/intent-debt/
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가 던지는 메시지는 단순하다 — 에이전트 시대에 사람이 해야 할 가장 값진 일은 더 많은 코드를 만드는 것이 아니라, 의도를 바깥에 적어 두는 것이다. 그 이자는 이제 복리로 불어나기 때문이다.
더 읽어보기
원문 — The Intent Debt (Addy Osmani)
Triple Debt 논문 — From Technical Debt to Cognitive and Intent Debt (Storey et al.) — ACM Queue 게재본: https://queue.acm.org/detail.cfm?id=3807966
Loop Engineering (Addy Osmani) 정리 — 같은 저자가 말한 “에이전트를 둘러싼 루프 설계”, 그 루프에 의도를 먹이는 이야기
AI 엔지니어의 ‘취향(taste)’ 정리 — 의도를 판단하는 사람의 내부 평가 함수
AI가 엔지니어를 대체하지 못하는 이유 정리 — decide(의도)는 사람에게 남는다는 프레임
Martin Fowler의 Fragments로 읽는 LLM 시대 — LLM 시대 프로그래밍에 대한 균형 감각

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

댓글