이번 주 두 개의 신호가 같은 방향을 가리켰습니다.

하나는 마이크로소프트의 ‘프로젝트 솔라라(Project Solara)‘입니다. 모바일 앱을 대체하는 에이전트 전용 플랫폼 — 사용자가 앱을 열지 않아도 에이전트가 항상 실행되는 환경을 만들겠다는 선언입니다. 같은 날 빌드(Build 2026)에서 자체 모델 7종도 함께 공개했습니다.

다른 하나는 젠슨 황(Jensen Huang)의 말입니다. “PC는 AI 에이전트 컴퓨터다(PC = AI agent computer).” NVIDIA의 Computex 발표에서 나온 이 한 줄이 시사하는 바는 분명합니다. PC의 목적이 바뀐다는 것입니다. 연산 기기가 아니라 개인 에이전트를 항상 작동시키는 기기로. 그는 이것을 “unmetered intelligence”라고 불렀습니다.

겉으로 보면 하드웨어 뉴스처럼 들립니다. 저는 다르게 읽었습니다.

에이전트의 전선이 앱에서 런타임으로 이동합니다

지금까지 에이전트를 설계할 때 우리가 암묵적으로 가정했던 것이 있습니다. “사용자가 열면 시작하고, 닫으면 멈춘다.”

앱이라는 패러다임 그대로입니다. 에이전트가 하는 일이 바뀌어도 에이전트를 담는 그릇은 앱이었습니다.

MS 솔라라와 젠슨 황의 메시지는 그 그릇 자체를 바꾸겠다는 신호입니다.

이번 주만의 이야기가 아닙니다. 6월 2일 Anthropic은 ‘콘웨이(Conway)‘와 ‘오빗(Orbit)‘이라는 코드명으로 상시 실행·능동 트리거형 에이전트 플랫폼을 준비 중이라는 신호를 냈습니다. 6월 4일에는 MS ‘스카우트(Scout)‘가 이메일과 일정을 사용자 개입 없이 처리하는 always-on 에이전트를 발표했습니다. 같은 날 Google은 분산 에이전트 런타임 ‘Agent Executor’를 오픈소스로 공개했습니다.

한 주 안에 빅테크 세 곳이 같은 방향을 가리켰습니다. 에이전트의 다음 경쟁은 “더 똑똑한 모델”이 아니라 “항상 도는 런타임과 그 런타임을 품은 기기”입니다.

왜 지금 이 전환이 일어나는가

PM으로 20년 일하면서 이런 패턴을 반복해서 봐왔습니다. 제품의 기능이 성숙해지면 경쟁은 기능에서 인프라로 이동합니다.

검색이 그랬습니다. 처음엔 누가 더 정확한 결과를 내느냐였지만, 결국 경쟁은 더 빠르고 더 자주 쓰이는 진입점으로 이동했습니다.

에이전트도 지금 그 전환점에 와 있습니다.

모델 성능의 격차는 좁혀지고 있습니다. Claude, GPT-5.5, Gemini — 어느 것을 써도 기본 작업은 됩니다. 그렇다면 다음 차별화는 어디서 납니까.

항상 켜져 있느냐(always-on), 사용자가 신경 쓰지 않아도 알아서 작동하느냐(ambient), 그리고 그 실행을 감사하고 복구할 수 있는 런타임을 갖추고 있느냐(durable execution)입니다.

한국IBM도 같은 주에 기획부터 배포, 보안까지 엔드투엔드로 처리하는 에이전트 ‘밥(Bob)‘을 공개했습니다. 에이전트가 단일 도구가 아니라 조직의 업무 표준을 내장한 워크플로 단위가 되는 방향입니다. 글로벌과 국내 신호가 같은 시점에 같은 결론을 가리키고 있습니다.

PM이 지금 바꿔야 할 사고

에이전트를 “앱처럼” 설계하면 세 가지 함정에 빠집니다.

첫째, 세션 단위로 생각합니다. 에이전트가 세션이 끊기면 컨텍스트를 잃습니다. 항상-도는 런타임에서는 메모리와 상태가 지속돼야 합니다. 이건 기능이 아니라 설계 기반입니다.

둘째, 사용자가 먼저 요청해야 한다고 가정합니다. always-on 에이전트는 조건이 충족되면 먼저 행동합니다. “이 이메일을 보내주세요”가 아니라 “이 조건이 생기면 이 이메일을 보내라”입니다. 트리거 설계가 기능 설계보다 먼저 와야 합니다.

셋째, 실패를 예외로 취급합니다. 앱은 실패하면 다시 열면 됩니다. 항상-도는 에이전트가 실패하면 작업이 이어져야 합니다. Google Agent Executor, DBOS의 durable execution 같은 도구가 이 문제를 직접 겨냥하고 있는 이유입니다.

100 Agents를 운영하면서 배운 것이 있습니다. 에이전트 설계에서 가장 자주 빠지는 포인트가 바로 이 세 가지입니다. 에이전트가 멈추거나 잘못 동작할 때, 대부분의 원인은 모델이 아니라 런타임 설계의 공백이었습니다.

에이전트를 앱으로 보는 PM, 런타임으로 보는 PM

MS 솔라라와 젠슨 황의 “PC=에이전트 컴퓨터” 선언은 에이전트 설계의 기준점을 바꿉니다.

기능을 잘 만들 것인가 — 그건 이제 기본입니다. 더 중요한 질문은, 당신이 만든 에이전트가 사용자가 앱을 열지 않아도 작동하는 런타임을 갖추고 있는가입니다.

에이전트를 앱으로 생각하는 PM과 런타임으로 생각하는 PM은 지금 다른 제품을 만들고 있습니다.

당신의 에이전트 설계에서 “항상-도는 런타임”은 어디까지 설계되어 있습니까?