AI 에이전트 시대, 왜 Intent(의도)가 중요해지는가

최근 AI 코딩 에이전트 업계에서 「Intent-Driven Development」나 「Intent-First Development」와 같은 용어를 접하게 되었습니다.

Claude Code나 Codex와 같은 AI 에이전트가 확산되면서, "사양이 아니라 의도를 전달하자", "태스크(Task)가 아니라 Intent로 팀을 움직이자"와 같은 이야기가 늘어나고 있다고 느껴집니다.

다만, Intent-Driven Development는 Scrum이나 LeSS와 같이 확립된 방법론은 아닙니다. 어느 쪽인가 하면, AI 에이전트 시대의 개발 방향성을 나타내는 개념에 가깝다고 생각합니다.

그래서 궁금해진 것이 "왜 지금에 와서 Intent가 주목받고 있는가" 하는 점이었습니다.

이 기사에서는 Intent라는 말을 새로운 개발 기법으로 소개하기보다는, 지금까지 애자일(Agile)이나 요구 공학(Requirements Engineering) 안에 있었던 사고방식이 AI 에이전트에 의해 왜 다시금 중요해지고 있는지를 정리해 보겠습니다.

상당히 제 이해를 정리하기 위한 기사입니다.

Intent는 일본어로 하면 "의도", "목표"와 같은 의미입니다.

소프트웨어 개발 문맥에서는 대체로 다음과 같은 것들을 나타내는 용어로 사용됩니다.

• 왜 만드는가
• 무엇을 달성하고 싶은가
• 어떤 제약이 있는가

예를 들어, 다음과 같은 표현은 요구사항이나 사양(Specification)에 가깝습니다.

• 주문 내역 화면을 만든다
• 검색 기능을 추가한다

반면, 다음과 같은 표현은 Intent에 가깝습니다.

• 재구매율을 향상시키고 싶다
• 문의 건수를 줄이고 싶다

즉, Intent는 What보다 Why에 가까운 개념이라고 할 수 있습니다.

궁금했던 점은 Intent가 새로운 개념인가 하는 부분이었는데, 예전부터 있던 개념의 스코프(Scope)를 AI 에이전트 시대에 맞춰 다시 설정한 느낌이 들었습니다.

예를 들어, 애자일 개발에서 자주 사용되는 유저 스토리(User Story)는 다음과 같은 형식으로 작성됩니다.

As a ...
I want ...
So that ...

예를 들어, 다음과 같은 유저 스토리가 있다고 가정해 봅시다.

고객으로서 주문 내역을 확인하고 싶다.
왜냐하면 재구매를 하고 싶기 때문이다.

이때, 전반부와 후반부는 성질이 조금 다릅니다.

• 주문 내역을 확인하고 싶다: What
• 재구매를 하고 싶다: Why

Intent에 가까운 것은 후자입니다.

즉, Intent는 사실 유저 스토리 안에 예전부터 존재하고 있었습니다.

또한, 요구 공학의 세계에는 Goal-Oriented Requirements Engineering (GORE)라는 분야가 있습니다. Goal(목표)로부터 Requirement(요구사항)로 떨어뜨려 가는 사고방식입니다.

시스템 개발이나 MBSE 분야에서도 Mission이나 Capability와 같은 개념을 사용하면서, "왜 만드는가"와 "무엇을 만드는가"를 연결하려고 노력해 왔습니다.

그렇게 생각하면, Intent는 신발명이라기보다 예전부터 있던 사고방식을 AI 시대에 재해석한 것으로 보입니다.

작은 애자일 팀에서는 Intent가 명문화되어 있지 않더라도 공유되고 있었습니다.

예를 들어,

문의를 줄이고 싶다

라거나,

재구매율을 높이고 싶다

와 같은 배경을 PO와 개발자가 일상적인 대화 속에서 공유할 수 있었기 때문입니다.

하지만 조직이 커지면 Jira에 남는 것은 Story나 Task뿐이 되기 쉽습니다.

그러면,

이 기능은 무엇을 위해 만드는 거지?

라는 상태가 발생합니다.

Intent는 존재하고 있었지만, 수많은 유저 스토리나 대화 속에 파묻혀 있었다고도 할 수 있습니다.

AI 에이전트가 구현 속도를 격하게 높였기 때문입니다.

기존의 AI 코딩 지원은 주로 구현 공정을 대상으로 했습니다.

Requirement
↓
Design
...

그 결과, 병목(Bottleneck)이 상류로 이동해 왔습니다. 그래서 요구 분석이나 설계까지 AI에게 맡기고 싶다는 기대가 높아지고 있습니다.

Intent
↓
Requirement ← AI
...

그렇게 되면 AI에게 무엇을 전달할지가 중요해집니다.

예를 들어,

주문 내역 화면을 만든다

라는 요구를 전달하면, AI는 그대로 구현합니다.

하지만,

재구매율을 향상시키고 싶다

라는 Intent를 전달한 경우에는 여러 가지 해결책을 검토할 수 있습니다.

• 주문 내역
• 즐겨찾기
• 원탭 재주문
• 추천(Recommend)

즉, Intent의 가치는 Solution Space(해결 공간)를 넓히는 데 있습니다.

인간이 처음부터 해결책을 결정하는 것이 아니라, 달성하고자 하는 목적이나 제약 사항을 공유하고, 그 위에서 AI와 함께 해결책을 탐색한다. 이러한 방식의 활용이 AI 에이전트에게 기대되어 오고 있습니다.

AI 코딩 에이전트가 보급되기 전이지만, 통신 업계의 Ericsson의 해설 기사에서도 AI가 Intent(의도)를 해석하여 오케스트레이션(Orchestration)이나 어슈어런스(Assurance)에 활용해 나가는 방향성이 설명되어 있습니다.

Intent라는 사고방식 그 자체가 AI와 상성이 좋은 추상화 레이어(Abstraction Layer)일지도 모른다는 생각이 들었습니다.

Intent-Driven이라는 용어가 등장했을 때,

Spec-Driven Development와 무엇이 다른 걸까?

라고 생각하는 분도 계실지 모릅니다.

제 이해로는, Spec-Driven Development는 다음과 같은 사고방식입니다.

Human
↓
Spec
...

인간이 AI와 함께 사양(Spec)을 명확히 하고, AI는 그 사양에 따라 구현합니다.

반면, Intent-Driven Development는 다음과 같은 이미지입니다.

Human
↓
Intent
...

차이는 AI에게 어디까지 맡길 것인가에 있습니다.

Intent-Driven Development는 Spec-Driven Development를 대체하는 것이라기보다, 그 상류 단계, 즉 '왜 만드는가'까지 포함한 사고방식으로 파악하는 것이 자연스럽다고 생각합니다.

Intent에서 갑자기 Code(코드)로 뛰어넘는 것이 아니라, Intent를 바탕으로 AI와 Requirement(요구사항)나 Spec(사양)을 만들고, 그 후에 구현하는 것입니다. 그렇게 생각하면 Spec-Driven한 진행 방식과도 모순되지 않습니다.

조사하는 과정에서 제가 흥미를 느낀 것은 Intent-Driven Development 그 자체보다, Intent-Driven Team이라는 개념이었습니다.

애자일(Agile) 개발은 원래 '올바르게 만드는 것'보다 '올바른 것을 만드는 것'을 중시해 왔습니다.

이를 위해 다음과 같은 개념들이 있습니다.

• Product Goal (제품 목표)
• Outcome (결과)
• Customer Value (고객 가치)

예를 들어 Scrum(스크럼)에서는 Product Goal이 정의되어 있고, LeSS에서도 '1 Product, 1 Product Goal'이라는 사고방식이 중시됩니다.

• Scrum Guide: https://scrumguides.org/
• LeSS: https://less.works/

반면 현실에서는 다음과 같은 것들이 중심이 되기 쉽습니다.

• Story (스토리)
• Task (태스크)
• Velocity (속도)
• Sprint (스프린트)

어느샌가 '무엇을 달성하고 싶은가'보다 '얼마나 소화했는가'에 의식이 향하게 됩니다.

이는 이전부터 애자일이나 대규모 애자일(Scaled Agile)에서 지적되어 온 과제라고 생각합니다.

팀이나 조직이 커질수록 국소적인 최적화에 빠지기 쉽습니다.

• Story 최적화
• Feature(기능) 최적화
• 팀 최적화

반면, 다음과 같은 최적화는 어려워집니다.

• Product(제품) 최적화
• Customer Value(고객 가치) 최적화

그렇기에 LeSS나 SAFe에서는 Story보다 상위 단계인 Product Goal, Outcome, Capability(역량)와 같은 개념이 중시되어 온 것이라고 생각합니다.

AI 에이전트가 늘어나면 이 문제는 더욱 커질 것 같습니다.

예를 들어, 다음과 같은 에이전트들이 동시에 움직이는 세상을 가정해 봅시다.

• Planner Agent (플래너 에이전트)
• Architect Agent (아키텍트 에이전트)
• Coding Agent (코딩 에이전트)
• Test Agent (테스트 에이전트)

각자가 Task(태스크)만을 보고 최적화한다면, 효율적으로 잘못된 것을 양산하게 됩니다.

이는 인간만으로 구성된 조직에서도 일어나던 문제였지만, AI에 의해 실행 속도가 빨라짐으로써 그 중요성이 다시금 커지고 있는 것으로 보입니다.

여기서 중요해지는 것은 Task Alignment(태스크 정렬)가 아니라, Intent Alignment(의도 정렬)입니다.

인간도 AI도 '무엇을 만드는가'뿐만 아니라 '왜 만드는가'를 공유해야 합니다.

Intent는 새로운 개념이 아닙니다.

User Story(사용자 스토리)에도, 요구공학(Requirements Engineering)에도, 시스템 개발에도 예전부터 존재해 왔습니다.

하지만 AI 에이전트에 의해 구현의 제약은 작아지고, '어떻게 만드는가'보다 '왜 만드는가'의 중요성이 커지고 있습니다.

Intent-Driven Development라는 용어가 주목받는 배경에는, AI를 활용하여 더욱 가치 있는 것을 만들고 싶다는 기대가 있다고 생각합니다.

그리고 변화해야 하는 것은 개발 프로세스뿐만 아니라, 조직 그 자체라고 생각합니다. 그리고 AI 에이전트 시대의 경쟁력은 인간과 AI가 동일한 Intent(의도)를 공유할 수 있는지 여부에 따라 결정될 것이라고 생각합니다.