에이전트에 대한 최근 생각: OS와 에이전트 네이티브 애플리케이션

1. 에이전트는 OS다; 수직 OS를 구축하는 것은 막다른 길이다#

1/ 에이전트는 상호작용 패러다임이다. 스마트폰이 상호작용 패러다임인 것과 같다. 당신은 휴대폰으로 쇼핑하고, 소셜 활동을 하며, 재정을 관리하지만, 쇼핑만을 위해 휴대폰을 사지는 않는다. 에이전트도 마찬가지다. 수직 도메인은 에이전트(휴대폰)를 만들려고 해서는 안 된다. 에이전트 위에서 동작하는 애플리케이션을 구축해야 한다.

2/ 그 이유는 전장이 완전히 다르기 때문이다. 에이전트의 전장은 추론 능력, 오케스트레이션 효율성, 상호작용 경험이다. 수직 도메인의 강점은 도메인 깊이, 비즈니스 이해도, 산업 데이터다. 이러한 장점은 OS 전장에서는 쓸모가 없다. 도메인 지식을 가지고 OpenAI나 Anthropic과 추론 능력으로 경쟁하는 것은 칼로 탱크와 싸우는 것과 같다.

3/ 게다가 OS 계층의 시장 구조는 자연스럽게 수렴한다. PC 시대에는 Windows와 Mac이 살아남았고, 모바일 시대에는 iOS와 Android가 살아남았다. 에이전트 OS 공간에서도 수십 개의 승자가 나오지 않을 것이다. 3년 동안 수직 에이전트를 구축하여 정면승부를 벌이는 것은, 그 3년 동안 자신의 도메인에 난공불락의 요새를 쌓는 데 사용할 수 있었던 시간을 낭비하는 것이다.

2. 스킬도 답이 아니다—한계는 복사본 판매다#

4/ 에이전트를 만들지 않는다면, 스킬을 만드는 것은 어떨까? 스킬에는 프롬프트와 스크립트라는 두 가지 측면이 있다.

5/ 프롬프트는 에이전트에게 "아, 이렇게 할 수도 있구나"라는 방향을 제시하는 일련의 지침이다. 가치가 있으며, 에이전트에게 방향을 제시한다. 하지만 추론 작업은 여전히 에이전트가 수행하며, 용량과 대역폭은 에이전트가 소비한다. 당신은 부담을 줄여주지 않았다. 그리고 프롬프트는 텍스트이므로 복사가 가능하다.

6/ 스크립트는 캡슐화된 외부 로직이다. 스크립트, 바이너리 프로그램, API 등 어떤 형태든 가능하다. 로직이 외부에서 실행되므로 에이전트가 이 도메인 문제를 스스로 추론할 필요가 없다. 이 작업을 처리하는 데 소비되는 주의 대역폭이 줄어든다. 이는 프롬프트보다 한 단계 나은 것으로, "방향 제시"에서 "일을 대신 처리"로 발전한 것이다.

7/ 하지만 스크립트에 외부 상태(데이터베이스, 누적된 사용자 데이터 등 입력과 출력 이후에 남는 것)가 없다면 로직은 재현 가능하다. 다른 사람이 당신의 접근 방식을 이해하고 다시 작성하여 정확히 동일한 기능을 구현할 수 있다.

8/ 따라서 스킬의 한계는 복사본을 판매하는 것이다. Notion 템플릿이나 GPTs를 판매하는 것과 같다. 더 잘 만들수록 복사하기 쉬워지고, 더 성공할수록 수요가 존재한다는 것을 증명하여 더 많은 사람들이 같은 일을 하려고 달려든다. 스킬은 인터페이스이며, 인터페이스 뒤에 아무것도 없다면 당신은 벌거벗고 달리는 것이다.

3. 에이전트의 두 가지 물리적 제약#

9/ 에이전트에는 두 가지 물리적 제약이 있다. 이는 버그가 아니며, 다음 세대 모델로 해결할 수 없다. 빛의 속도와 같아서, 없애려고 해도 없어지지 않으며, 공학적으로 우회할 수밖에 없다.

10/ 첫째: 컨텍스트 용량. 컨텍스트는 유한한 용기이며, 더 많이 채울수록 성능이 저하된다. 이해하기 쉽다.

11/ 둘째: 주의 대역폭. 이는 덜 직관적이다. 김용 소설에서 주백통은 "좌우호박"이라는 기술을 사용한다. 왼손으로 원을 그리고 오른손으로 사각형을 그리는 것이다. 원만 그리는 것은 쉽다. 사각형만 그리는 것도 쉽다. 하지만 동시에 하면 둘 다 왜곡된다. 손이 부족해서가 아니라, 주의가 두 작업 사이에서 분산되기 때문이다. 에이전트가 하나의 컨텍스트 내에서 법적 추론, 사용자 의도 추적, 다음 행동 계획을 동시에 수행하면 각 작업의 품질이 저하된다. 어떤 단일 작업이 능력을 초과해서가 아니라, 동일한 주의를 두고 경쟁하기 때문이다. 주의는 제로섬이다.

12/ 에이전트가 무한한 용량과 완벽한 주의를 가졌다면 모든 것을 스스로 처리할 수 있고 아무도 필요하지 않을 것이다. 하지만 현실은 용량이 제한적이고 대역폭이 제한적이다. 에이전트 네이티브 애플리케이션이 존재하는 근본적인 이유는 바로 이 두 가지 물리적 제약 때문이다.

4. 에이전트 네이티브 애플리케이션#

13/ 장벽 문제로 돌아가자. 스킬이 재현 가능한 근본 원인은 "외부 상태가 없기 때문"이다. 해결책은 인터페이스 뒤에 복제할 수 없는 무언가를 성장시키는 것이다. 세 가지가 있다:

14/ 도메인 상태—서비스 내 사용자의 비즈니스 컨텍스트로, 상호작용할 때마다 성장한다. 법률 서비스는 사건 진행 상황과 판례 인용을 기억하고, 투자 서비스는 포트폴리오 논리와 리밸런싱 이유를 기억한다. 사용할수록 두꺼워지며, 다른 사람이 처음부터 따라잡을 수 없다.

15/ 인프라 비용—도메인에 미세 조정된 소형 모델, 특화된 지식 베이스, 실시간 데이터 파이프라인. 실제 돈이 지속적으로 투자되어야 하며, 코드 한 줄 복사한다고 얻을 수 있는 것이 아니다.

16/ 규모의 경제로 인한 비용 우위—10만 명의 사용자를 동시에 서비스할 때, 인프라의 단위 비용은 자체 구축하는 모든 사람을 압도한다. 지능과 무관한 수학적 이점이다.

17/ 스킬 뒤에 이 세 가지가 있으면 더 이상 스킬이 아니라 에이전트 네이티브 애플리케이션이다.

18/ 애플리케이션은 에이전트에 두 가지 유형의 가치를 제공하며, 이는 두 가지 물리적 제약에 대응한다:

기능 잠금 해제: 이전에는 할 수 없었던 일을 할 수 있게 됨—컨텍스트 용량 돌파. 컨텍스트에 담을 수 없는 도메인 지식과 사용자 기록을 애플리케이션이 외부에서 관리하여 필요할 때 호출할 수 있게 한다.

인지 부하 경감: 이전에는 많은 노력이 필요했던 일을 쉽게 처리할 수 있게 됨—주의 대역폭 확보. 도메인 추론이 외부로 이동되어 다른 작업과 더 이상 경쟁하지 않는다. 더 빨라진 것이 아니라, 간섭이 사라져 다른 모든 작업이 더 정확해진다.

19/ 여기서 흔한 오해를 바로잡아야 한다: 도메인 상태는 메모리가 아니다. 메모리는 일반적인 메모리 관리(무엇을 기억하고 무엇을 잊을지)를 의미한다. 이는 에이전트 OS 계층의 주제다. 도메인 상태는 특정 수직 분야 내 사용자의 비즈니스 컨텍스트로, 명확히 경계가 정해진 비즈니스 상태 머신이다. 그 상업적 속성은 자산 축적이다. 사용할수록 두꺼워지고, 마이그레이션이 어려워진다. 이것이 당신의 요새다. 다른 사람이 당신의 스킬을 복사할 수는 있지만, 당신의 요새를 복사할 수는 없다.

5. OS와 애플리케이션#

20/ 각 측면은 고유한 명제를 가진다. OS의 명제는 '무엇(WHAT)'—제한된 용량과 대역폭 내에서 사용자가 가능한 한 많고 좋은 일을 수행하도록 돕는 것이다. 애플리케이션의 명제는 '어떻게(HOW)'—호출될 때마다 최대의 도메인 가치를 제공하는 것이다. OS는 무엇을 할지 결정하고, 애플리케이션은 어떻게 할지 결정한다. 상태(State)도 이 선을 따라 나뉜다. OS는 사용자 의도와 교차 도메인 컨텍스트를 보유하고, 애플리케이션은 도메인 상태와 비즈니스 이력을 보유한다. 각자는 자신의 영역을 관리하며, 월권하지 않는다.

21/ 이전 컴퓨팅 패러다임에서는 앱과 OS의 관계가 일방향적이었다. Word가 Windows를 더 빠르게 만들지 않았고, Taobao가 iOS를 더 부드럽게 만들지 않았다. 에이전트 패러다임에서는 다르다. 좋은 애플리케이션은 에이전트 OS를 더 똑똑하게 만든다. 법률 애플리케이션은 법적 추론을 에이전트의 주의(attention) 밖으로 옮긴다. 주의가 더 이상 간섭받지 않고, 다른 작업이 더 정확하게 추론되며, 더 많은 애플리케이션을 더 정밀하게 호출하게 되고, 더 많은 데이터를 얻고, 더 나아져 더 많은 인지 부하를 덜어준다... 플라이휠이 돌아간다. 이것이 인지 공생(Cognitive Symbiosis)이다—일반 지능과 특수 지능이 인터페이스를 통해 결합되어, 각자 따로 운영될 때보다 함께 있을 때 더 강력해진다. 이전 컴퓨팅 패러다임에서는 이런 일이 일어나지 않았다.

22/ 가장 좋은 컨텍스트는 컨텍스트가 없는 것이다. 에이전트가 가벼울수록 성능이 더 좋다.

AI 요약#

다음은 위의 통찰을 바탕으로 한 구조화된 요약입니다.

인과 사슬 (Causal Chain)#

에이전트는 OS이다 → 수직적 도메인에서 OS를 구축하는 것은 막다른 길이다 (잘못된 전장, 잘못된 상대, 예정된 결과) → 스킬(Skill)의 한계는 복사본 판매이다 (프롬프트는 복사 가능하고, 외부 상태가 없는 스크립트는 재현 가능하다) → 근본 원인: 에이전트는 두 가지 물리적 제약을 가진다: 컨텍스트 용량(Context Capacity, 담을 수 없음)과 주의 대역폭(Attention Bandwidth, 담을 수는 있지만 잘 수행하지 못하며 작업 간 간섭이 발생함) → 해결책: 에이전트 네이티브 애플리케이션 (도메인 상태 + 인프라 + 규모의 경제) → 두 가지 가치: 역량 해제(Capability Unlock, 용량 돌파) + 인지 오프로드(Cognitive Offload, 대역폭 확보) → OS와 애플리케이션의 인지 공생 → 가장 좋은 컨텍스트는 컨텍스트가 없는 것이다.

3계층 스펙트럼 (Three-Layer Spectrum)#

명령어에서 도구, 서비스로 가는 것은 복잡성을 점진적으로 에이전트 외부로 옮기는 과정이다:

명령어 (Instruction / Prompt): 에이전트에 방향을 제시하지만, 에이전트가 여전히 작업을 수행하므로 대역폭이 줄어들지 않는다. 텍스트는 복사 가능하며 진입 장벽이 0이다.
도구 (Tool / Script): 외부 실행이 결과를 반환하므로 대역폭이 줄어든다. 그러나 외부 상태가 없고 로직이 재현 가능하여 진입 장벽이 낮다.
서비스 (Service / Application): 외부 실행 + 지속적 상태(Persistent State) + 인프라로, 대역폭과 용량이 크게 줄어든다. 재현이 불가능하며 진입 장벽이 높다.

명령어에서 도구로의 도약: "길을 알려주는 것"에서 "일을 수행하는 것"으로의 변화. 도구에서 서비스로의 도약: 도메인 상태, 인프라 비용, 규모의 경제로 인한 비용 이점이 추가됨.

3가지 복제 불가능 요소 (스킬에서 애플리케이션으로 도약하기 위한 조건)#

도메인 상태 (Domain State): 상호작용할 때마다 성장하며, 처음부터 따라잡을 수 없다.
인프라 비용 (Infrastructure Cost): 지속적인 실제 자금 투자가 필요하며, 코드 복사만으로는 얻을 수 없다.
규모의 경제로 인한 비용 이점 (Cost Advantage from Economies of Scale): 역량과 무관한 수학적 우위.

2가지 가치 × 2가지 제약#

**역량 해제 (Capability Unlock)**컨텍스트 용량 돌파 → 이전에는 할 수 없었던 일을 이제 할 수 있게 됨.
**인지 오프로드 (Cognitive Offload)**주의 대역폭 확보 → 노력이 필요했던 일을 이제 쉽게 할 수 있게 됨 (간섭 제거).

OS와 애플리케이션의 경계#

에이전트 OS의 명제는 '무엇(WHAT, 무엇을 할지)'이며, 사용자 의도와 교차 도메인 컨텍스트를 보유한다. 에이전트 애플리케이션의 명제는 '어떻게(HOW, 어떻게 할지)'이며, 도메인 상태와 비즈니스 이력을 보유한다. 이들의 독특한 관계는 인지 공생이다: 좋은 애플리케이션은 OS를 더 똑똑하게 만들고, 더 똑똑해진 OS는 애플리케이션을 더 정밀하게 호출한다.