#바이브 워킹 #오피스 스킬 #AgentPuter #생산성 #AI 에이전트

바이브 워킹: '에이전트에게 그냥 말해'가 실제로 효과가 있을 때

기업용 AI는 분석가의 하루 업무 시간을 1.5시간 절약해 주지만, 최고의 에이전트도 여러 앱을 사용하는 사무 작업의 53%는 실패합니다. 단일 앱에서의 시간 절약과 완전한 자동화 사이의 격차에 진정한 기회가 있습니다.

@ AgentPuter Lab
$
~ 읽는 시간 12분

지난 세 개의 포스트에 걸쳐 저희는 OpenClaw라는 제품에서 시작해 → Brain-Body-Soul 아키텍처 → 그리고 그 기반을 이루는 Skills + Gateway + MCP 기능 스택으로 이어지는 하나의 흐름을 살펴보았습니다.

저희는 “Skills가 일상 업무를 혁신할 것”이라고 계속해서 강조해왔습니다. 이제 실제로 어떤 모습일지 보여드리겠습니다.

I. Microsoft가 “Vibe Working”이라 명명하다

2025년 9월 29일, Microsoft는 Microsoft 365 Copilot에 두 가지 기능을 출시하고 Vibe Working이라는 이름을 붙였습니다.

Agent Mode는 Excel과 Word에 탑재되었습니다. “월별 상환 내역이 포함된 대출 상환 계산기를 만들어 줘”와 같은 프롬프트를 입력하면, 에이전트는 단순히 수식 하나만 내놓지 않습니다. 시트를 만들고, 수식을 작성하고, 차트를 생성하고, 결과를 검증하고, 오류를 찾아 수정하며, 결과물이 확인될 때까지 반복 작업을 수행합니다. 다단계. 자가 수정.

Office Agent는 Copilot 채팅 사이드바에 도입되었습니다. “이 분기별 데이터로 이사회 보고용 프레젠테이션을 만들어 줘”라고 말하면, 세련된 PowerPoint 파일을 생성해 줍니다. 자리 표시자 텍스트만 채워진 템플릿이 아니라, 실제 데이터를 담아 서식까지 완벽하게 갖춰 바로 발표할 수 있는 슬라이드 자료를 만들어 줍니다.

이 이름의 유래는 Andrej Karpathy까지 거슬러 올라갑니다. 2025년 2월 2일, OpenAI 창립 멤버인 그는 트위터에 이렇게 남겼습니다. “저는 ‘vibe coding’이라 부르는 새로운 종류의 코딩이 있다고 생각합니다. 분위기(vibe)에 완전히 몸을 맡기고, 기하급수적인 가능성을 받아들이며, 코드가 존재한다는 사실조차 잊어버리는 것이죠.” 7개월 후, Microsoft는 이 아이디어를 코드에서 가져와 스프레드시트, 문서, 슬라이드에 적용했습니다. 바로 사용자가 의도를 제공하면, 에이전트가 결과물을 전달하는 방식입니다.

더 이상 VLOOKUP 구문과 씨름할 필요가 없습니다. 47장의 슬라이드 서식을 일일이 지정할 필요도 없습니다. 세 개의 스프레드시트와 Word 문서 사이에서 숫자를 복사하고 붙여넣을 필요도 없습니다.

적어도 Microsoft가 내세운 약속은 그렇습니다. Microsoft의 자체 SpreadsheetBench에 따르면, Excel의 Agent Mode는 복잡한 작업에서 57.2%의 정확도를 기록했습니다. 일부 사용자에게는 직접 작업하는 것보다 나을 수 있지만, 신뢰할 수 있는 수준과는 아직 거리가 멉니다.

II. 기대와 현실

실제 연구 결과는 이렇습니다.

SpreadsheetBench와 같은 사무 자동화 벤치마크는 최고 성능의 모델들을 대상으로 실제 워크플로우를 테스트했습니다. 데이터셋 필터링, 표 교차 참조, 요약 분석 생성 등, 유능한 직장인이라면 매일 고민 없이 처리하는 작업들이었죠.

최고 성능의 시스템조차 거의 절반의 경우 실패합니다. 연구진의 결론은 단호합니다. 성능이 여전히 “실제 사무 환경에서 요구되는 인간 수준의 정확도에 한참 미치지 못한다”는 것이죠.

실패 유형은 시사하는 바가 큽니다.

  • 작업 중복(Operation redundancy) — 에이전트가 동일한 작업을 세 번 연속 반복하며 토큰을 낭비하고, 때로는 자신의 결과물을 손상시킵니다.
  • 환각 참조(Hallucinated references) — 총 10행밖에 없는 스프레드시트에서 자신 있게 B14 셀을 수정합니다.
  • 앱 전환 실패(App-switching failures) — Excel에서 Word로, 다시 Email로 데이터를 옮기는 과정에서 맥락을 잃는 경우가 허다합니다.
  • 장기 목표 이탈(Long-horizon drift) — 10단계 이상으로 구성된 작업에서 에이전트가 원래 달성하려던 목표를 점차 잊어버립니다.

하지만 대부분의 사람들이 이러한 실패에서 놓치는 점이 있습니다. Microsoft의 AI 레드팀(Red Team)이 에이전트 시스템의 실패 유형 분류 체계를 발표했는데, 가장 무서운 발견은 환각(hallucination)이 아니라 바로 **인간의 감독 능력 저하(erosion of human oversight)**였습니다.

에이전트가 그럴듯해 보이는 스프레드시트를 만들면 사용자는 수식을 확인하지 않습니다. 그럴듯하게 들리는 이메일 초안을 작성하면 읽어보지도 않고 전송 버튼을 누르죠. 진정한 위험은 에이전트가 틀린다는 사실이 아닙니다. 인간이 그 실수를 더 이상 알아채지 못하게 된다는 점입니다.

이것이 바로 Vibe Working의 핵심적인 딜레마입니다. 에이전트의 능력이 향상될수록, 안전장치(guardrails) 없이 신뢰하는 것은 더욱 위험해진다는 것이죠.

III. 네 가지 시나리오: 이전과 이후

본격적인 저희의 작업에 대해 설명하기 전에, 이미 현장에서 측정된 내용에 대한 배경 지식을 먼저 살펴보겠습니다.

NBER 현장 연구(American Economic Review: Insights에 조건부 승인됨)는 6개월 동안 66개 기업의 7,137명의 지식 근로자를 추적했습니다. 통합 AI 도구를 사용하는 근로자들은 이메일 업무에 25~31% 더 적은 시간을 보냈는데, 이는 주당 약 2~3시간 단축된 수치입니다.

  • Morgan Stanley의 재무 분석가들은 연구 및 보고서 준비에 **매일

IV. 성공 요인과 한계점

네 가지 시나리오 모두 공통된 패턴을 보입니다. 자세히 살펴보겠습니다.

성공 요인:

  1. 도메인 지식을 인코딩하는 Skill. 단순한 프롬프트가 아니라, 회사의 보고서 형식, 팀의 회의록 스타일, 법무팀의 리스크 평가 척도 등을 알고 있는 구조화된 명령어 세트입니다. 이것이 바로 Skill 기반 접근 방식이 단순 프롬프트 방식보다 뛰어난 이유입니다.
  2. 실질적인 작업을 처리하는 MCP 도구. Agent는 CRM에 연결하거나 PDF를 파싱하는 방법을 ‘알아낼’ 필요가 없습니다. MCP가 미리 빌드되고 테스트된 통합 기능을 제공하기 때문입니다. Skill은 그저 ‘이 도구를 사용해’라고 말하기만 하면, MCP가 프로토콜을 처리합니다.
  3. 모든 것을 안정적으로 실행하는 Gateway. 작업 중간에 세션 상태가 사라지지 않습니다. 특정 단계에서 실패하면 Gateway가 재시도하거나 롤백합니다. 권한이 강제됩니다. 예를 들어, 계약 검토 Skill은 이메일에 접근할 수 없고, 이메일 Skill은 계약서에 접근할 수 없습니다.

한계점:

  1. 여러 단계로 이루어진 교차 앱 워크플로우. 작업이 4개 이상의 애플리케이션에 걸쳐 진행되면 성공률이 크게 떨어집니다. 컨텍스트 파편화(Context fragmentation)가 가장 큰 미해결 과제입니다.
  2. 모호한 의도. ‘이 보고서를 더 좋게 만들어 줘’와 같은 요청은 충분하지 않습니다. Agent에게는 구체적인 의도가 필요합니다. ‘15% 이상 하락한 부분을 표시해 줘’는 실행 가능하지만, ‘보기 좋게 만들어 줘’는 그렇지 않습니다. Vibe Working을 위해서는 사용자가 ‘완료’된 상태가 어떤 모습인지 명확히 해야 합니다.
  3. 최초 설정. Skill이 회사의 관례를 복제하려면 먼저 이를 학습해야 합니다. 첫 분기 보고서는 설정하는 데 노력이 필요하지만, 스무 번째 보고서는 3분이면 충분합니다.

V. 현재 솔루션들이 부족한 이유

Microsoft의 Vibe Working 기능은 데모는 인상적이지만, 현재 접근 방식에는 구조적인 한계가 있습니다.

Copilot은 Microsoft 생태계에 종속되어 있습니다. Agent Mode는 Excel과 Word에서 작동합니다. 만약 데이터는 Google Sheets에, CRM은 Salesforce에, 회의록은 Otter.ai에 있다면 어떨까요? 하나의 공급업체 내에서가 아니라, 여러 공급업체를 아우르는 오케스트레이션이 필요합니다.

세션 간 영구적인 메모리가 없습니다. Copilot은 지난달 보고서에서 특정 차트 스타일을 사용했다거나, 법무팀이 3단계 위험 척도를 선호한다는 사실을 기억하지 못합니다. 모든 세션은 처음부터 다시 시작됩니다. Skill은 이 문제를 해결합니다. 지식이 세션이 아닌 Skill 파일에 저장되기 때문입니다.

보안 격리가 없습니다. Copilot이 공급업체 계약서를 처리할 때, 그 데이터는 어디로 갈까요? OpenAI의 API를 통할까요? 아니면 Anthropic의 API를 통할까요? Microsoft는 둘 다 사용합니다. 그리고 여기 Microsoft의 공식 문서에 숨겨진 세부 정보가 있습니다. Microsoft 365 Copilot 환경 내 Anthropic 모델은 EU 데이터 경계(EU Data Boundary) 적용 범위에서 명시적으로 제외됩니다. 만약 유럽 기업이 Agent Mode를 실행한다면, 데이터 일부가 EU 데이터센터 외부(특히 AWS US)에서 처리될 수 있습니다. 민감한 문서의 경우, 클라우드 API를 사용하는 채팅창이 아니라 샌드박싱 기능이 있고 데이터 경계가 명확한 Gateway 같은 런타임이 필요합니다.

정확도 수치는 처참한 수준입니다. Excel 전용 작업에 대한 SpreadsheetBench 테스트에서 57.2%를 기록했는데, 이는 Microsoft가 자체 벤치마크에서 자체 Agent Mode로 테스트한 결과입니다. 스프레드시트 추론에 관한 학술 연구(SheetBrain, SheetAgent 등)에 따르면, 데이터 손상을 방지하기 위해서는 특수 목적으로 제작된 뉴로-심볼릭 시스템조차도 명시적인 검증 모듈이 필요합니다. 아무리 인상적이더라도, 원시적인 모델의 지능만으로는 인프라 없이는 사무 자동화에 바로 투입될 수 없습니다.

VI. 우리가 채택한 접근 방식

AgentPuter의 Vibe Working 스택은 세 가지 계층으로 구성됩니다. 이전 게시물에서 설명했던 것과 동일한 세 가지입니다.

Skills는 각 시나리오에 대한 플레이북을 정의합니다. Sales Reporting Skill은 Meeting Notes Skill과 다르며, Contract Review Skill과도 다릅니다. 각 Skill은 특정 도메인 지식, 단계 시퀀스, 도구 요구 사항 및 출력 형식을 인코딩합니다.

Agent Gateway는 실행을 오케스트레이션합니다. 올바른 Skill을 로드하고, MCP tool 호출을 라우팅하며, 세션 상태를 관리하고, 권한을 적용하며, 오류를 처리합니다. Gateway는 12단계 워크플로우의 7단계에서 시스템이 무너지지 않도록 하는 핵심적인 역할을 합니다.

MCP tools는 실제 연결을 처리합니다 — 데이터베이스 쿼리, 파일 I/O, 이메일 API, 캘린더 조회, PDF 파싱 등. 표준화되고, 테스트되었으며, 컨테이너화되어 있습니다.

이것이 Copilot과 다른 점은 무엇일까요? 세 가지가 있습니다:

  1. 벤더 중립적. 저희 Gateway는 Google Workspace, Microsoft 365, Salesforce, Slack, Notion 등 고객의 데이터가 실제로 존재하는 모든 곳에서 오케스트레이션합니다. 단일 생태계에 종속되지 않습니다.
  2. 영구적인 지식. Skills는 세션 전반에 걸쳐 고객의 규칙을 기억합니다. Skill이 고객의 형식, 지표, 대상을 이미 알고 있기 때문에 20번째 분기 보고서도 2번째 보고서만큼 빠르게 처리됩니다.
  3. 보안 우선 런타임. 모든 Skill은 샌드박스 환경에서 실행됩니다. 계약 데이터는 이메일 Skill의 컨텍스트에 접근하지 않습니다. 세션 데이터는 명시적으로 영구 저장되지 않는 한 일시적입니다. 모든 단계에 대한 감사 로그가 제공됩니다.

마무리하며

“Vibe Working”은 다가올 미래를 잘 표현하는 이름입니다. 원하는 것을 설명하면 Agent가 완성된 결과물을 제공하는 것, 이것이 바로 모두가 지향하는 최종 목표입니다.

하지만 솔직히 말해, 우리는 아직 그 단계에 도달하지 못했습니다. 데모 버전과 일상적으로 사용하는 버전 사이의 격차는 분명히 존재합니다. 오피스 워크플로우 성공률이 ~50%에 그친다는 점은 모델 본연의 지능만으로는 부족하다는 것을 말해줍니다.

이 격차를 메우는 것은 더 나은 모델이 아닙니다. 바로 모델을 둘러싼 인프라입니다:

  • Agent가 즉흥적으로 작동하는 대신, 검증된 워크플로우 내에서만 작동하도록 제약하는 Skills
  • 재시도, 롤백, 접근 제어 기능을 통해 여러 단계의 작업을 안정적으로 유지하는 Gateway
  • Agent가 스스로 API를 파악하도록 하는 대신, 테스트를 거친 신뢰할 수 있는 통합 기능을 제공하는 MCP tools

지난 네 개의 포스트를 통해, 우리는 하나의 바이럴 오픈소스 프로젝트를 분석하는 것에서 시작하여 Agent 인프라에 실제로 무엇이 필요한지에 대한 전체적인 그림을 그려보았습니다.

이 분야에서 개발하는 모든 사람이 고민해야 할 지점은 바로 이것입니다: Morgan Stanley의 애널리스트들은 AI로 하루 1.5시간을 절약하지만, 최고의 범용 Agent조차도 여러 앱을 오가는 오피스 작업의 절반은 실패합니다. ROI는 이미 현실화되었습니다. 단, 단일 앱 내에서, 인간의 감독 하에서만 그렇습니다. 인간의 개입이 사라지거나 여러 앱의 경계를 넘나드는 순간, 모든 것이 무너집니다.

핵심은 간단합니다. 여러분의 분기 보고서를 작성하는 Agent는 ChatGPT보다 똑똑하지 않습니다. 그저 더 나은 지침, 신뢰할 수 있는 런타임, 그리고 적절한 도구를 갖추고 있을 뿐입니다. 그 NBER 연구에 참여한 7,137명의 근로자에게 필요했던 것은 더 똑똑한 모델이 아니었습니다. 그들이 이미 가지고 있던 모델을 둘러싼 더 나은 인프라였습니다.

이것이 바로 Vibe Working입니다. 분위기가 아니라, 인프라입니다.

이 글은 Agent 인프라에 대한 저희 시리즈의 네 번째 포스트입니다. OpenClaw에서 시작해 아키텍처, Skills + Gateway + MCP 역량 스택을 거쳐 실제 적용 모습까지 살펴보았습니다. 다음 글에서는 비즈니스 모델, 즉 Agent 플랫폼으로 어떻게 수익을 창출할 수 있는지에 대해 다룰 예정입니다. AI로 자동화하려다 실패했던 오피스 워크플로우가 있다면, 저희에게 꼭 알려주세요.