UI는 모든 제품이 이미 출시한 API이다

얼마 전 나는 에이전트(Agent)에게 내가 가진 가장 지루한 작업을 시켰다. Framer에 들어가서 일련의 블로그 포스트들에 걸쳐 작성자 상세 정보를 입력하는 일이었다. 이름, 역할, 링크 같은 것들 말이다. 인간에게는 생각할 필요도 없이 20분 정도 걸리는 그런 작업이다.

에이전트는 그것을 할 수 없었다.

작업이 어려워서가 아니었다. 에이전트가 행동할 수 있는 곳이 없었기 때문이다. Framer에는 에이전트가 접근할 수 있는 MCP, CLI, 또는 API가 없었다. 에이전트는 전체 작업을 계획할 만큼 충분히 똑똑했지만, 건드릴 수 있는 표면(Surface)이 없어 그저 앉아 있을 뿐이었다. 그래서 나는 언제나 그랬듯 직접 손으로 그 일을 했다.

그 이후 Framer는 자체적인 MCP를 출시했고, 그들에게는 좋은 일이다. 하지만 그것이 바로 내가 말하고자 하는 핵심이다.

도구 하나가 API를 출시한다고 해서 모든 것이 해결되지는 않기 때문이다. 나는 Framer를 기다리고, 그다음 도구를 기다리고, 또 그다음 도구를 기다리며 내 업무를 구축할 생각은 전혀 없었다. 인터넷이 MCP로 넘어오고 있는 것이 아니다. 대부분은 결코 그렇게 되지 않을 것이며, 그래야만 하는 것도 아니다.

당신이 실제로 하루 동안 하는 업무를 살펴보라. 특정 인물을 찾고 그가 누구를 아는지 확인하기 위해 LinkedIn을 연다. 세 개의 채널을 확인하기 위해 Slack을 훑어본다. 똑같은 신청 양식을 다섯 번째 작성한다. 분석 데이터를 읽기 위해 제품에 로그인한다. 이 중 그 어떤 것도 깔끔한 API를 가지고 있지 않다. 어떤 것들은 시도하려는 모든 이들에게 적극적으로 저항한다. 그리고 그것이 업무의 대부분이다.

그래서 나는 모든 것이 언제 API를 출시할지 묻는 것을 그만두었다. 대신 이 모든 것에 대해 이미 존재하는 표면(Surface)이 무엇인지 묻기 시작했다.

하나가 있다. 모든 도구는, 심지어 최악의 내부 대시보드라 할지라도, 이미 하나의 인터페이스를 출시했다. 인간을 위해 구축되어 브라우저에서 실행되는 UI 말이다. UI는 모든 제품이 이미 출시한 API이다. API는 인터페이스가 이미 할 수 있는 기능 중 더 작고 깔끔하게 잘라낸 조각이다. 인터페이스는 완전한 표면(Surface)이며, API는 벤더(Vendor)가 노출하기로 결정한 부분이다.

모두가 잘못된 두 계층을 바라보고 있다.

현재 에이전트(Agents)를 구축하고 있다면, 아마도 에이전트가 작업을 수행할 두 가지 장소인 MCP와 CLI를 바라보고 있을 것입니다. 모델에게 도구(Tools)를 주고, 터미널(Terminal)을 제공하여 자유롭게 풀어주는 방식이죠. 둘 다 실재하며 유용합니다. 하지만 거의 아무도 사람이 하루 중 대부분을 사용하는 세 번째 표면(Surface)인 브라우저(Browser)를 바라보고 있지 않습니다.

저는 이를 두 개의 스택(Stacks)으로 생각합니다. 모델과 그 추론(Reasoning)이 담당하는 결정 계층(Decision layer)이 있는데, 이 계층은 이미 포화 상태이며 매달 비용이 저렴해지고 있습니다. 그다음은 의도(Intent)가 실제 작업으로 전환되는 실행 계층(Execution layer)입니다. 이 계층은 완전히 열려 있으며, 브라우저는 인간이 작업하는 모든 곳에 이미 존재하고 있는 유일한 후보입니다.

브라우저는 또한 MCP와 CLI가 보통 갖지 못한 것, 즉 컨텍스트(Context)를 지니고 있습니다. 에이전트가 로그인된 브라우저 내부에서 작동할 때, 에이전트는 나의 실제 상태(State)를 갖게 됩니다. 나의 데이터, 나의 권한, 나의 계정, 그리고 샌드박스(Sandbox) 복사본이 아닌 실제 앱을 갖게 됩니다. 에이전트는 작업의 표면(Surface)과 작업의 컨텍스트(Context)를 동시에 알게 됩니다. 이 결합이 핵심입니다.

명백한 반론

사람들이 제기하는 첫 번째 우려는 보안(Security)이며, 그들의 지적은 옳습니다. 에이전트에게 로그인된 브라우저를 넘겨주는 것은 무모하게 들리며, 잘못 다뤄질 경우 실제로 그렇습니다. 당신이 로그인한 모든 것에 대한 가공되지 않은 접근 권한(Raw access)은 재앙이 되기 위해 기다리고 있는 것과 같습니다.

그것이 바로 BrowserOps가 존재하는 이유입니다. 적절한 가드레일(Guardrails)을 갖춘 로그인된 브라우저는 에이전트와 실제 인터넷 사이의 가교 역할을 합니다. 어렵고 가치 있는 부분은 모델을 탭(Tab)에 연결하는 것이 아닙니다. 그 주변의 가드레일입니다. 무엇을 건드릴 수 있는지, 무엇을 당신에게 확인받아야 하는지, 무엇을 스스로 절대 해서는 안 되는지 말입니다. 이것을 제대로 구현한다면, 로그인된 브라우저는 더 이상 부채(Liability)가 아니라 에이전트가 가질 수 있는 가장 유능한 표면(Surface)이 됩니다.

사람들은 또한 컴퓨터 사용(computer-use) 기능이 이 모든 것을 스스로 처리할 것이라고 말합니다. 아마도 그중 일부는 그럴 수 있겠죠. 하지만 갓 설치한 기기에서 클릭하며 돌아다니는 데모는, 에이전트가 당신의 실제 데이터와 함께 당신의 실제 계정을 매일 안전하게 운영하는 것과는 매우 다른 문제입니다. 데모는 쉬운 80%에 불과합니다. 가드레일(Guardrails)과 실제 로그인된 컨텍스트(Context)가 실제로 중요한 나머지 20%입니다.

왜 이 격차가 좁혀지지 않는가

이것은 세상이 따라잡아 모든 곳에 API를 출시할 때까지 기다리는 임시방편이 아닙니다. 소프트웨어의 롱테일(Long tail), 내부 도구, 레거시 시스템(Legacy systems), 당신의 팀이 사용하는 니치(Niche) SaaS 등은 결코 API를 우선순위에 두지 않을 것입니다. 그럴 비즈니스 케이스(Business case)가 없기 때문입니다. 따라서 브라우저가 채우는 격차는 시간이 지나도 줄어들지 않습니다. 그것은 구조적입니다. 바로 이 점이 이것을 다음 분기가 아닌 향후 10년 동안 구축할 가치가 있게 만듭니다.

이것이 나아갈 방향

내가 구축하고자 하는 것은 모든 에이전트 아래에 위치하며, 사람들이 사용하는 표면(Surfaces)을 어떻게 운영하는지 이미 알고 있는 실행 계층(Execution layer)입니다. 에이전트가 결정하면, 계층이 실행하며, 이는 누군가가 무언가를 통합(Integrate)하기를 기다릴 필요 없이 로그인된 상태에서 컨텍스트와 함께 모든 도구에 걸쳐 이루어집니다. 작업은 더 빠르고 훨씬 더 효율적으로 수행됩니다. 당신은 한 번에 하나씩 취약한 통합(Integration)을 연결하는 것을 멈추고, 이미 가지고 있는 소프트웨어를 운영하기 시작할 것입니다.

우리는 작은 것들을 자동화하는 BrowserOps로 시작했습니다. 나의 Slack을 훑어보는 것, 양식을 채우는 것 같은 일들 말이죠. 몇 주 전에는 에이전트가 내 라우터에 로그인하여 설정을 정리하게 함으로써 와이파이 문제를 해결했습니다. 아무도 그것을 위해 설계하지 않았습니다. 하지만 라우터가 다른 거의 모든 것과 마찬가지로 UI와 로그인 기능을 가지고 있었기에, 그냥 작동했습니다.

처음에 실패했던 그 Framer 작업은 이제 브라우저에서 내가 직접 하는 것과 똑같은 방식으로 실행됩니다. Framer가 API를 출시했기 때문이 아닙니다. 에이전트가 마침내 내내 그 자리에 있었던 단 하나의 표면(Surface)을 갖게 되었기 때문입니다.