에이전트 시대의 앱: 에이전트 준비가 된 오픈 앱 (The Agent-Ready Open App)

에이전트(Agents)와 에이전트 기반 코딩 도구(Agentic coding tools)가 보편화됨에 따라 애플리케이션의 역할이 어떻게 변화하는지, 그리고 그러한 세상을 위해 앱을 어떻게 설계해야 하는지에 대한 노트.

배경: 목적지로서의 앱

오랫동안 대부분의 앱은 작업을 수행하기 위해 사용자가 직접 들어가는 장소로 구축되었습니다. CRM은 CRM 내부에서 작동했고, ERP는 ERP 내부에서, 문서 도구는 문서 도구 내부에서 작동했습니다. 앱은 정보 자체를 내부에 저장하고, 자신의 화면 뒤에 기능을 숨기며, 자신의 울타리 안에서 작업 흐름을 제어했습니다.

이 모델에서 사용자는 많은 앱 사이를 이동합니다. 한 곳에서 데이터를 복사하고, 화면을 전환하고, 데이터를 재구성하여 다른 곳에 입력합니다. 앱의 수는 늘어났지만 작업이 더 단순해지지는 않았습니다. 정보는 흩어지고, 맥락(Context)은 끊겼으며, 결국 사람들은 시스템 사이를 연결하는 결합 조직(Connective tissue) 역할을 하게 되었습니다.

폐쇄형 앱 뒤에 숨겨진 가정들

폐쇄형 앱은 대략 네 가지 가정에 기반합니다:

• 데이터가 앱 내부에 존재한다. 작업 기록, 고객 정보, 문서, 처리 이력, 결정 기준 등이 각 앱의 데이터베이스에 자리 잡고 있습니다. 외부 접근은 제한된 API나 맞춤형 통합(Custom integration)을 통해서만 가능합니다.
• 기능이 UI에 종속되어 있다. 사람들은 버튼을 클릭하고, 메뉴를 선택하고, 화면 사이를 이동함으로써 기능을 사용합니다. 기능은 존재하지만, 에이전트가 이를 자유롭게 호출하거나 조합할 수는 없습니다.
• 앱은 자신의 데이터만 본다. 사용자가 어떤 프로젝트를 작업 중인지, 어떤 문서에 근거하여 결정이 내려져야 하는지, 어떤 내부 규칙이 적용되는지 등은 모두 앱 외부에 존재합니다.
• AI가 부가 기능(Add-on)으로 덧붙여진다. 많은 앱이 현재 "AI 기능"을 추가하고 있지만, 대부분은 앱 자체의 LLM(대규모 언어 모델)을 사용하여 내부 기능을 약간 더 편리하게 만드는 것 이상의 역할은 하지 못합니다.

이 네 가지 가정은 한 가지 공통점을 공유합니다. 앱이 여전히 사용자를 자신의 내부로 끌어들이려 한다는 점입니다.

무엇이 변하는가

에이전트 시대의 핵심적인 변화는 작업의 중심이 앱의 화면에서 사용자의 맥락(Context)으로 이동한다는 것입니다.

이전에는 사용자가 앱을 직접 조작했으며, 앱이 작업의 목적지였습니다. 이제 에이전트(Agent)는 사용자의 목표를 이해하고, 여러 앱에 걸쳐 필요한 기능들을 호출하며, 데이터를 가져오고, 중간 결과물을 정리하여 최종 결과물을 생성합니다. 앱은 더 이상 목적지가 아닙니다. 에이전트가 활용하는 기능(Capability)의 제공자가 됩니다. 각 앱이 가졌던 개별적인 화면과 워크플로(Workflow)는 에이전트가 여러 앱의 기능들을 연결하여 구성하는 하나의 통합된 흐름으로 흡수됩니다.

한 문장으로 요약하자면: 사용자가 앱으로 들어가는 것이 아니라, 앱이 사용자의 에이전트 중심 워크플로(Agentic workflow) 안으로 들어가는 것입니다. 이는 단순히 앱에 AI 기능을 추가하는 문제가 아닙니다. 앱의 근본적인 정의를 바꾸는 것입니다.

에이전트 준비가 된 오픈 앱 (The Agent-Ready Open App)

이러한 변화를 위해 구축된 앱을 **에이전트 준비가 된 오픈 앱 (Agent-Ready Open App)**이라고 합니다. 즉, 사람이 화면에서 직접 조작할 수 있으면서도, 동시에 에이전트가 이해하고 사용할 수 있도록 데이터, 기능, 상태(State), 그리고 출력물을 충분히 개방적으로 노출하는 앱을 의미합니다.

정보를 내부에 가두는 대신, 이러한 앱은 에이전트가 사용할 수 있는 명확한 데이터 구조, API, 이벤트(Events), 권한 모델(Permission model), 작업 단위(Units of work), 그리고 출력 형식(Output formats)을 제공합니다. 또한 자체적인 LLM(대규모 언어 모델)으로 모든 것을 처리하려 하지 않습니다. 대신, 고객이 이미 실행 중인 에이전트, LLM, 작업 시스템 및 보안 환경 내에서 앱의 기능과 출력물이 사용되도록 설계됩니다. 이 앱의 목표는 사용자를 화면에 최대한 오래 머물게 하는 것이 아니라, 사용자의 맥락(Context) 안에서 최대한 잘 호출되고, 구성되고, 재사용되는 것입니다.

따라서 에이전트 준비가 된 오픈 앱은 AI 기능이 덧붙여진 앱이 아닙니다. 그것은 에이전트에 의해 사용되도록 설계된 앱입니다.

AOA: 에이전트 위의 앱 (Apps over Agents)

에이전트 위에서 실행되는 이러한 앱 계층을 **AOA — 에이전트 위의 앱 (Apps over Agents)**라고 부를 수 있습니다.

에이전트는 코드를 작성하고, 파일을 읽고, 명령을 실행하며, 문서를 생성하고, 외부 도구 (external tools)를 호출합니다. 하지만 에이전트 단독으로는 완전한 작업 시스템을 만들 수 없습니다. 남은 과제는 에이전트가 수행하는 작업을 사람이 따라갈 수 있는 흐름(flow)으로 전환하는 것입니다. 즉, 이를 검증하고, 기록하고, 권한을 관리하며, 재사용 가능한 자산 (reusable assets)으로 형성하는 과정이 필요합니다. AOA는 바로 이 과정을 처리하는 계층입니다.

AOA 계층의 앱은 에이전트가 호출할 수 있는 명확한 역량 단위 (units of capability)를 제공하고, 에이전트의 결과물을 사람이 작업할 수 있는 워크플로 (workflows)로 변환하며, 고객의 컨텍스트 (context) 내에서 작동하며 출력을 구조화하고 검증하여 재사용 가능한 자산으로 만듭니다. 요컨대, AOA는 기술이라기보다 제품 구조 (product structure)에 가깝습니다. 이는 에이전트 시대의 앱이 무엇을 생산해야 하는지를 설명합니다.

스킬 (Skills), MCP, 그리고 A2A와의 관계

AOA의 위치를 정확히 파악하기 위해서는 몇 가지 인접한 개념들과 분리하여 생각하는 것이 도움이 됩니다.

• 스킬 (Skills) — 에이전트가 수행하는 개별적인 역량 단위입니다. 문서를 요약하거나 데이터를 변환하는 것과 같은 작업으로, 대개 함수 호출 (function call) 또는 도구 호출 (tool invocation) 형태로 제공됩니다. 스킬은 단일 기능에 집중합니다.
• MCP (Model Context Protocol) — 에이전트가 파일 시스템, 데이터베이스, API와 같은 외부 리소스와 데이터 및 컨텍스트를 교환하기 위한 프로토콜입니다. 이는 에이전트가 무엇을 볼 수 있는지를 확장합니다.
• A2A (Agent-to-Agent) — 에이전트 간의 통신, 위임 및 협업을 위한 구조입니다. 여러 에이전트가 복잡한 작업을 나누어 수행할 수 있게 하며, 누가 작업을 수행하는지를 정의합니다.

이 세 가지 모두 작업이 어떻게 실행되는가에 관한 것입니다. AOA는 이들 위에 위치하며 무엇이 생산되는가에 관한 것입니다. AOA는 이들과 경쟁하는 것이 아니라, 이들을 사용하여 실제 작업 결과물을 조립합니다. 여러 에이전트가 A2A를 통해 협업하고, MCP를 통해 데이터를 가져오며, 스킬로서 기능을 실행하더라도, 그 결과를 구조화하고 자산으로 만드는 것은 바로 AOA 계층의 앱입니다.

설계 방향

에이전트 준비가 된 오픈 앱 (Agent-Ready Open App)은 네 가지 방향을 따라 설계됩니다.

데이터 (Data): 속성에서 컨텍스트 리소스 (context resource)로. 데이터를 내부 자산으로만 유지하는 대신, 에이전트가 다시 읽고 그 위에 구축할 수 있는 구조화된 컨텍스트 (context)로 제공합니다. 단순한 내보내기 (export)가 아니라, 작업의 단계와 흐름, 관련 문서로의 링크, 변경 이력, 그리고 에이전트가 이해할 수 있는 메타데이터 (metadata)를 포함하는 프로젝트 수준의 자산입니다.

기능 (Features): 버튼에서 호출 가능한 기능 (callable capabilities)으로. 기능을 UI 뒤에 숨겨두는 대신, 에이전트가 직접 호출할 수 있는 인터페이스를 통해 명확한 입력과 출력을 가진 실행 가능한 도구 (tools)로서 노출합니다. 예를 들어, 문서 생성 기능은 단순한 텍스트 출력으로 설계되는 것이 아니라 생성, 편집, 병합 및 형식 변환을 아우르는 기능 (capability)으로 설계됩니다.

출력 (Output): 일회성 결과물에서 재사용 가능한 자산으로. 출력물은 사람이 읽을 수 있는 문서인 동시에, 워크플로 (workflow) 정보와 재사용 가능한 기능 정의를 담고 있는 에이전트가 읽을 수 있는 JSON 구조입니다. 이러한 출력물은 고객의 에이전트 환경 내에서 다시 열고, 편집하고, 확장할 수 있습니다.

앱 (The app): 목적지에서 개방형 워크플로 노드 (open workflow node)로. 앱은 전체 워크플로를 독점하지 않습니다. 특정 작업 도메인에 특화된 기능을 제공하고 그 출력을 다른 시스템과 연결할 수 있게 함으로써, 더 큰 흐름 내의 하나의 노드 (node)로서 참여합니다.

설계 원칙 (Design principles)

위의 방향성을 원칙으로 정리하면 다음과 같습니다:

1. Context-first (컨텍스트 우선) — 고객의 전체 작업 컨텍스트 (work context) 내에서 데이터가 사용될 수 있도록 제공합니다.
2. Agent-callable (에이전트 호출 가능) — 에이전트가 직접 호출할 수 있는 형태로 기능을 노출합니다.
3. Human-readable and machine-usable (인간이 읽을 수 있고 기계가 사용 가능한) — 출력물은 사람과 에이전트 모두가 읽고 작업할 수 있어야 합니다.
4. Customer-owned context (고객 소유의 컨텍스트) — 컨텍스트의 소유권은 앱이 아닌 고객에게 있습니다.
5. Open workflow (개방형 워크플로) — 앱은 워크플로를 독점하는 대신 하나의 노드 (node)로서 참여합니다.
6. Composable capability (조합 가능한 기능) — 기능을 다른 기능들과 조합할 수 있는 단위로 설계합니다.
7. Traceable output (추적 가능한 출력) — 출력물은 추적 가능한 이력과 출처 (provenance)를 포함해야 합니다.

사례: 문서 자동화 앱 (a document-automation app)

문서 자동화 앱을 예로 들어보겠습니다. 에이전트 준비가 된 오픈 앱 (Agent-Ready Open App)으로 설계된 이 앱은 단순한 문서 편집기가 아닙니다.

이 앱은 JSON 구조, 문서, 메타데이터의 조합으로서 프로젝트 수준의 출력물을 제공하며, 문서의 생성, 편집, 병합 및 형식 변환을 에이전트가 호출할 수 있는 기능 (capabilities)으로 노출합니다. 에이전트는 문서를 생성하고, 편집하며, 다른 시스템과 연결하기 위해 이 앱을 호출합니다. 사람은 여전히 앱의 화면 내에서 직접 작업할 수 있지만, 더 중요한 점은 출력물이 앱을 벗어나 고객의 에이전트 환경 내에서 계속해서 열리고 확장된다는 것입니다.

요약

에이전트 시대에 앱은 더 이상 폐쇄된 작업 공간으로 남을 수 없습니다. 변화의 방향은 다음과 같이 요약할 수 있습니다:

• 폐쇄형 시스템 (closed system) → 개방형 기능 (open capability)
• UI 중심 도구 (UI-centric tool) → 에이전트 호출 가능 도구 (agent-callable tool)
• 내장형 AI 기능 (built-in AI features) → 고객의 컨텍스트에 기반한 확장성 (extensibility grounded in the customer's context)
• 데이터 락인 (data lock-in) → 컨텍스트 제공 (context provision)
• 앱 내부에 갇힌 출력물 (output trapped inside the app) → 재사용 가능한 작업 자산 (reusable work assets)

단일 계층으로 명명하자면, 이러한 변화는 AOA — Apps over Agents입니다. 에이전트가 작업을 수행하면, AOA 계층의 앱은 그 작업을 구조화하고, 검증하며, 재사용 가능한 자산으로 문서화합니다.

결국, 경쟁력은 어떤 앱이 자체적으로 가장 많은 기능을 보유하고 있느냐가 아니라, 고객의 에이전트 워크플로 (agentic workflow) 내에서 어떤 앱이 가장 잘 사용되느냐에 의해 결정될 것입니다.