Coding Agent에서 디지털 직원으로: AI 애플리케이션이 동일한 시스템 아키텍처로 수렴하고 있다

云栖大会의 Agent 제품 부스를 연속으로 살펴보면, 가장 반직관적인 발견은 이들이 전혀 다른 산업에 속해 보이는 반면, 만들어진 결과물은 동일한 OS라는 점이다.

Qoder는软件开发를, QwenWork는 지식 업무를, TinyFish는 Web Browser Agent를, WonderClip은 영상 제작을, OpenSearch는 검색과 Research를 수행하고 있다.

구체적인 산업分野를 제거하면, 이들 하층 구조는高度的로 유사해진다:

Context → Planning → Skill → Execution → Verification → Memory → Business Outcome

이것이 Agent 제품이 수렴하고 있는 동일한 시스템 아키텍처다.

⚠ 本文以阿里云生态(Qoder/QwenWork/TinyFish/WonderClip/OpenSearch)为现场样本。但下面这些架构判断,对自建场景、华为云、AWS、Azure、GCP 的 Agent 平台同样适用——七层栈是工程结构的收敛,不是某一朵云的私有结论。

一、Agent의 핵심은 “대답하는 것”에서 “지속적으로 실행하는 것”으로 전환되었다

Chatbot 시대에는 시스템의 기본 순환이 단순했다: 사용자 입력 → 모델 출력.

Agent 시대에는 태스크가 몇 분, 몇 시간, 심지어 더 오래 지속될 수 있다. 파일을 읽고, 브라우저를 사용하며, API를 호출하고, 코드를 실행하고, 비동기 태스크를 기다리며, 결과를 확인하고, 실패 시 재시도하고, 상태를 저장해야 한다.

하나의 Prompt와 하나의 모델로는 이것들을 감당할 수 없다.

시스템은 반드시 Runtime을 갖추어야 한다.

QwenWork의 Legal Document Fill Out 작업 시연

QwenWork 현장에서 시연된 Legal Document Fill Out 작업은 매우 대표적이다. 독립적인 Sandbox Container에서 실행되며, Agent는 가상 데스크톱을 보유하고 문서 처리 도구를 호출할 수 있다. Marketing Content Generation은 PPT, 이미지, Lip Sync, Python, Pillow, FFmpeg 등 다양한 도구를 추가로 조합한다.

Agent의 실행 환경은 점점 프로그래밍 가능한 컴퓨터에 가까워지고 있다——샌드박스로 보호받고, 다양한 런타임과 도구를 호출하며, 작업 중단 없이 지속적인 작업을 수행할 수 있는 작업 유닛이다. Sandbox Container는 격리를 제공하고, 가상 데스크톱은 그래픽 인터페이스의 시각적 조작 능력을 제공하며, 도구 호출은 모델이 “말하기”에서 “실행하기”로 나아갈 수 있게 한다. 이러한 조합이 안정화되면, Agent는 비로소 인간의 사고 측면이 아닌 조작 측면을 실제로 대체하기 시작한다.

이원: Qoder의 “One Foundation”은 구호가 아닌 제품 신호

Qoder의 전시 패널에는 다음과 같은 문구가 적혀 있다:

One workbench. Four entries. One foundation.

上位에는 Workbench, CLI, IDE, JetBrains Plugin을 탑재하며, Cloud Agents, Agent SDK 등으로 확장 가능하다.

하지만 진정으로 주목해야 할 것은 하단의 공유 Foundation이다.

각入口마다 Agent를 따로 구현하면 시스템이 빠르게失控한다. 더 합리적인 접근은 태스크调度, 권한, 도구, Sandbox, Memory, Model Router, Verification 등의 역량을 공용 Harness로 구성하는 것이다.

入口는 서로 다른 사용자와 시나리오에 대한 어댑터 역할만 담당한다. CLI는 프로그래머를, IDE는 개발자를, Workbench는 비기술 직군을, JetBrains는 레거시 코드 이전 시나리오를, Cloud Agents는 비동기 트리거를, Agent SDK는 서드파티 통합을 대상으로 한다. 하단의调度, 기억, 도구 게이트웨이, 검증, 보안 모델은 동일하게 공유된다.

이러한 재활용의 가치는 표면적으로 보이는 것보다 훨씬 큽니다. 조직 내에서 Coding Agent의 Sandbox 설계 경험, Permission 설계 경험, Recovery 경험은 Browser Agent, Content Agent, Ops Agent로 직접 이전할 수 있습니다. 반복적인 재발명에서 가장 비용이 큰 것은 개발 비용이 아니라, 문제 발생 시 서로 다른 Agent 간의表現 불일치로 인한 거버넌스 재앙입니다. 동일한 코드도 IDE Agent에서는 수정할 수 있고 CLI Agent에서도 수정할 수 있지만, Permission Model이 다르고 감사 로그(审计日志) 형식이 다르다면, 사고 발생 시 추적이 불가능해집니다.

삼, 범용 Agent Stack은 최소 7개 계층으로 구성되며—각 계층별 “자체 구축 / 공유 / 미검증” 투자 로드맵

이러한 내용을 추상화한 결과, Agent Stack을 7개 계층으로 분리했습니다. 아래 표는 조직이 직면한 가장 실질적인 질문에 대한 답을 동시에 제공합니다: 어떤 계층은 자체 구축해야 하고, 어떤 계층은 오픈소스를 공유하거나 구매할 수 있으며, 무엇이 아직 불확실한지.

표:

계층	역할	자체 구축 vs 공유 vs 미검증	비고
1. Planning/Reasoning	CoT, Tool Selection, 코드 생성 등 고급 추론 능력	?	최근 Claude Code, GPT-4o 등 강력한 내장 reasoning 능력 확인 필요
2. Tool Integration	브라우저, 파일 시스템, CLI 등 도구 호출 인터페이스	?
3. Security & Permission	Sandbox, Permission Model, 감사 로그 등 보안 메커니즘	?
4. Memory & Context	대화 기록, 문서 기억, 상식 저장소	?
5. Multi-Agent Collaboration	Agent 간 협업 프로토콜, 롤 분배, 충돌 해결	?
6. Observability	로그, 모니터링, 디버깅 추적 체계	?
7. Policy & Compliance	감사 정책, 규제 준수, 접근 제어 정책	?

핵심 교훈: 1~~3 계층은 조직의 핵심 역량으로 자체 구축해야 하고, 4~~5 계층은 초기에는 공유 솔루션 활용 가능하지만 장기적으로 차별화 요소가 될 수 있으며, 6~7 계층은 대부분의 조직에서 공유/구매가 적합합니다.

层	내용	투자 판단 (2026 현장 관찰)
1. Entry 진입	Web / CLI / IDE / IM / API / GitHub Issue / 기업 워크스페이스	어댑터 계층, 자체 구축 불필요——사용자에게 가장 적합한 진입 형태를 선택
2. Task 태스크	Goal / Spec / Context / Acceptance / Priority / Budget	자체 구축하되, 최소화——Task 계약은 작성 품질이 하류 전체에 영향
3. Context & Memory 컨텍스트 및 메모리	기업 지식, 코드 지식, 이력 작업, 의사결정, 사용자 선호도, 현재 상태	반드시 자체 구축——Context는 조직 자산으로 구매 불가
4. Planning & Skill 계획 및 스킬	작업 분할, Skill 선택, 모델 선택, 병렬화 전략	Skill은 자체 구축, Planning은 외부 활용 가능——Skill은 핵심 경쟁력

| 5. Runtime & Tools 런타임 및 도구 | Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / 기업 API | 반 자체 구축——범용 런타임은 Browser Use, Anthropic Agent SDK 등 오픈소스 스택을 활용하되, 기업용 API 게이트웨이는 반드시 자체 구축 |
| 6. Verification & Recovery 검증 및 복구 | 테스트, 규칙 검증, 결과 평가, 실패 복구, 재시도 및 롤백 | 자체 구축——검증 규칙은 업무와 밀접하게 연관되어 있어, 외부 솔루션으로는 원활하게 작동하기 어려움 |
| 7. Governance 거버넌스 | 권한, Secrets, 감사, 비용, 정책, 승인 절차 | 필수 자체 구축——合规이 아닌 工程 관점에서 설계해야 함 |

첫 번째 계층: Entry

웹, CLI, IDE, 메신저, API, GitHub 이슈, 기업 워크벤치 등은 모두 작업의 진입점에 해당하며, 그 자체로는 업무 가치를 창출하지 않는다.

AI 에이전트 시스템의 다층 아키텍처

제2층 Task

Goal, Spec, Context, Acceptance Criteria, Priority, Budget는 모두 Task에 속해야 한다. 적합한 Task 설명은 명확히 다음을 정의해야 한다: 목표, 수행 이유, 완료 기준, 우선순위, 예산. 만약 Agent 시스템이 이 여섯 가지 필드조차 갖추고 있지 않다면, 태스크는 시스템 내에서 떠다니기 시작한다.

제3층 Context & Memory

기업 지식, 코드 지식, 이력 작업, 의사결정, 사용자 선호도, 현재 상태가 모두 여기에 포함된다. Qoder가 현장에서 강조한 Repo Wiki, Knowledge Graph, Knowledge Cards는 모두 이 층의 구체적 형태——“분산된 사실”을 “머신이 호출 가능한 자산”으로 전환하는 것이다.

제4층 Planning & Skill

시스템이 작업을 분할하는 방법, 어느 재사용 가능한 Skill을 선택할지, 어떤 단계에서 강력한 모델이 필요한지, 어떤 작업을 병렬 처리할 수 있는지를 판단한다. 이 층은 Agent가 비로소 “생각”을 시작하는 곳이며, 모델 역량이 집중적으로 호출되는 곳이다.

5단계 런타임 & 도구. Shell, Browser, Computer Use, Filesystem, Git, Database, MCP, Enterprise API 등이 이 층에 해당한다. 이것이 Agent가 외부 세계와 실제로 접촉하는 접합부다.

6단계 검증 & 복구. 테스트, 규칙 검사, 결과 평가, 실패 복구, 재시도 및 롤백을 포함한다.

7단계 거버넌스. 권한, Secrets, 감사(Audit), 비용(Cost), 정책(Policy), 인간 승인(Human Approval)이 이에 해당한다. 또한 더 세분화된 항목들—알고리즘 등록备案(알고리즘 신고 제도), 모델 설명 가능성, 오류 귀책, 서드파티 의존성 관리, 데이터 국외 이전管控—이 포함되는데, 이러한 것들은 국내 고강도 규제 업계(의료, 금융, 교통, 미디어, 공공안전)에서 Agent를 출시할 때 피할 수 없는 엄격한 제약 조건들이다.

모델은 이 모든 것을 관통하지만, 모델이 곧 전체 Agent 플랫폼인 것은 아니다. 이는 지난 2년간 가장 과소평가된 인식 전환이다. 많은 팀이 모델 비교에 너무 많은 시간을 낭비했지만, 시스템의 프로덕션 환경 출시 여부를 실제로 결정하는 것은 나머지 6개 층이다.

4. Browser Agent는 Agent와 현실 세계 사이의 인터페이스를 보완한다

TinyFish 같은 제품들이 이领域的 대표적인 예다.

很多 실제 업무 시스템에는 사용하기 좋은 API가 없거나, 사용자가 웹사이트에 로그인하거나, 동적 페이지를 조작하거나, 양식을 작성하거나, 페이지를 전환하거나, 파일을 다운로드해야 하는 경우가 있습니다. 기존 자동화 방식은 Playwright나 Puppeteer 스크립트에 의존하는데, 페이지가 조금만 바뀌면 바로 작동이 멈춥니다. Browser Agent는 모델이 웹페이지를 직접 이해하고 동작을 실행할 수 있게 해줍니다.

이런 역량은 Agent Runtime의 중요한缺口를 메워줍니다: 실제 웹 환경입니다.

외부 링크 제출 Agent, 운영 Agent, 조달 Agent, 리서치 Agent 등 다양한 Agent가 웹사이트 내에서 작업을 완료해야 하는 상황이 있을 수 있습니다.

하지만 여기서 진정으로 어려운 것은 “버튼을 클릭할 수 있느냐”가 아닙니다. 프로덕션 시스템에서는 로그인 상태 관리—Cookie / Token을 어떻게 다루고, 만료되면 어떻게 할지—, 동시성—한 작업 내에서 여러 탭이 동시에 조작될 때 어떻게 동기화할지—, 실패 복구—페이지가 크래시되거나 네트워크가 끊어졌을 때 어떻게 이어서 실행할지—, 중복 제출 방지—네트워크 떨림으로 인해 클릭 동작이 반복 실행되는 것을 어떻게 막을지—, 프록시—지역/IP 제한을 어떻게 우회할지—, 캡차—봇 탐지를 어떻게 통과할지—, 권한—여러 계정을 어떻게 격리할지—, 그리고 마지막으로 “작업이 정말 완료되었음을 증명”—동작이 실제로 적용되었는지 어떻게 검증할 것인지—等问题을 해결해야 합니다.

한 단계 더 나아가면, 간접 프롬프트 인젝션(Indirect Prompt Injection) 은 2026년 Browser Agent가 직면한 가장 현실적인 보안 위협이다. OWASP는 2026 AI 위협 순위에서 프롬프트 인젝션을 1위에 선정했으며, 페이지에 숨겨진 텍스트를 삽입하는 것만으로 Agent를 속여 사용자의 Cookie를 외부로 전송하게 만들 수 있다. 아키텍처 수준에서 이를 완전히 해결하는 방법은 없으며, Sandbox, 동작 화이트리스트, Ambient Credential 제어 등에서 엔지니어링적 타협점을 찾아야 한다.

Browser Use 역시 반드시 Harness 내에 포함되어야 한다. Demo 수준의 능력만으로는 충분하지 않다. 만약 어떤 조직이 Browser Agent를 실제 프로덕션 환경에 적용하려면, 이 계층을 구축하는 비용만으로 RPA 시스템을 새로 만드는 것과 거의 맞먹을 것이다.

따라서 Browser Agent는 겉으로는 애플리케이션처럼 보이지만, 실체는 Runtime의 일부다.

5. Verification는 Agent가 더 높은 권한을 얻을 수 있는지를 결정한다

Agent 시스템에는 매우 직관적인 법칙이 있다. 자율성이 높을수록, 검증과 거버넌스도 반드시 강화되어야 한다.

이메일 초안 작성만 수행하는 Agent는 실수 시 비용이 제한적이다.

생산 환경 데이터베이스를 수정하고, 코드를 제출하며, 광고 예산을 집행하고, 기업 백엔드를 조작할 수 있는 Agent의 위험성은 완전히 다릅니다.

진정한 성숙한 Agent 플랫폼은 “무엇을 할 수 있는지”만 답하는 데 그치지 않고, 다음과 같은 사항들을 명확히 표현해야 합니다:

어떤 접근이 허용되는지;
어떤 수정 사항이 허용되는지;
어떤 동작에 승인이 필요한지;
각 단계에서 어떤 감사 기록이 남겨지는지;
실패 시 어떻게 복구하는지;
시스템이 작업 완료 사실을 어떻게 입증하는지.

여기에는 하나의 엔지니어링 판단이 있습니다: Agent가 각 동작 단계마다 검증 가능한 증거를 제공할 수 없다면, 그 Agent의 자율성은 “조언자” 위치에 머물러야 합니다. 다시 말해, 자율성은 기능 목록에 의해 해제되는 것이 아니라, 컴플라이언스 프레임워크 내에서 검증된 역량에 의해 점진적으로 확대되는 것입니다. Agent가 기능적으로 100개의 API를 호출할 수 있다 하더라도, 매 호출이 예상된 결과를 달성했음을 증명할 수 없다면, 금융, 의료,跨境 데이터와 같은 엄격히 규제되는 시나리오에서는 “조언자” 역할에 머물러야 합니다.

이것이 기업 환경에서 Governance가 점점 중요해지는 이유이기도 합니다—컴플라이언스 부서의 문제가 아니라, 엔지니어링 부서가 처음부터 Runtime과 함께 설계해야 하는 역량입니다.

Model Router가 기본 스케줄러가 되는 시대——단, 모든 계층에서 가장 강력한 모델이 필요한 것은 아닙니다

멀티 모델이 점차 보편화되고 있습니다.

진정한 가치가 있는 멀티 모델 시스템은 단순히 사용자에게 GPT, Qwen, Claude 등 모델을 드롭다운으로 선택하게 만드는 것이 아닙니다.

더 합리적인 접근법은 시스템이 작업 특성에 따라 자동으로 라우팅하는 것입니다.

복잡한 기획과 아키텍처 판단에는 강력한 모델을 사용하고, 일반적인 코드 구현과 텍스트 정리에는 비용 효율적인 모델을 활용하며, 시각 작업에는 멀티모달 모델을, 대량 분류에는 빠른 모델을, 중요한 리뷰 시에는 다시 강력한 모델로 전환합니다.

이 모든 배경에는 명확한 엔지니어링 판단이 있습니다. 각 작업은 모델에 요구되는 “능력-비용” 곡선이 완전히 다릅니다. 강력한 모델로 대량 분류를 처리하는 것은 낭비이고, 빠른 모델로 아키텍처 결정을 내리면 반복적인 재작업이 발생합니다. Requesty가 2026년에 공개한 경험적 수치에 따르면, 일반 작업의 70%를 nano 모델로, 20%를 mid-tier 모델로, 10%를 frontier 모델로 라우팅하면, 평균 查询당 비용을 60~80% 절감하면서 품질 저하는 거의 없다는 결과가 나왔습니다——이는 방향성 참고 수치이며, 실제 수치는 작업 유형과 라우팅 전략에 따라 달라질 수 있습니다.

모델은 점차 디스패치 가능한 컴퓨팅 자원으로 변해가고 있습니다. Agent Platform은 품질, 속도, 비용, 리스크 사이에서 동적 균형을 유지하며 선택을 수행합니다.

계단식 라우팅의 실전 예시

하나의 Agent가 “경쟁사 가격 전략을 분석하고 제안서를 작성하라”는 지시를 받으면, ‘과제 이해, 단계 분리, 우선순위 판단’ 단계에서는 고성능 모델을 사용한다. ‘100개 SKU를 가격 구간별로 분류’ 단계에서는 빠른 모델로 전환하고, 분류 결과가 나오면 종합 판단 단계에서 다시 고성능 모델로 전환한다.

모든 과제에 가장 비싼 모델을 적용하면 시스템 비용이 과도하게 높아진다. 반대로 모든 과제에 싼 모델을 적용하면 복잡한 노드에서 지속적으로 실패하게 된다. 실제 엔지니어링 가치는 특정 모델을 선택하는 것에서 나오는 것이 아니라, 스케줄링 전략에서 나온다.

7. Skill은 범용 Runtime과 수직 비즈니스를 연결하는 핵심 레이어——그리고 미래의 방어막

범용 Agent Runtime 자체에는 비즈니스 가치가 없다.

실제 시나리오에 진입하려면 Skill을 통해 연결되어야 한다.

Coding Skill은 Repo 읽기, Spec 작성, Test 실행, PR 생성을 수행하는 방법을 알고 있다. 단위 테스트를 먼저 실행해야 하는 시점, 건너뛸 수 있는 시점, PR 설명에 포함되어야 할 필드, 인간 리뷰가 필요한 변경 사항 등을 규정한다.

SEO Research Skill은 키워드 찾기, 검색 의도 분석, 경쟁 강도 검증, 콘텐츠 개요 생성, 페이지 인덱싱 확인을 수행하는 방법을 알고 있다. ‘키워드 리서처 수행’이라는 몇 글자가 아니라, 완전한 프로세스 그 자체다.

E-commerce Creative Skill은 브랜드, SKU, 플랫폼 형식, 규제 및 심사를 파악하고 있어야 합니다. 각 플랫폼의 이미지 크기 제한, 금지어, 카테고리 자격 요건, 게시 전 최종 심사 프로세스를 명확히 알고 있어야 합니다.

Ops Skill은 모니터링, 로그, 컨테이너, 데이터베이스, 롤백을 확인하는 방법을 알고 있습니다. 어떤 경고는 자동 대응이 가능하고, 어떤 것은 반드시 사람 개입이 필요하며, 안전한 롤백 포인트는 무엇인지를 구분할 수 있어야 합니다.

Skill은 단순한 SOP가 아니라 버전 관리, 의존성 관리, 반복 관리, 실패 안전장치를 갖춘 실행 가능한 자산입니다. Anthropic이 2025년 10월에 공개한 Skills 프로토콜을 참고하여, 각 분야의 경험을 SKILL.md 폴더에 패키징하고, 다양한 Agent 플랫폼에서 필요할 때 로드해 매번 처음부터 새로 작성하지 않도록 할 수 있습니다.

Skill은 범용 실행 능력과 도메인 지식을 연결합니다.

따라서 향후 많은 AI 애플리케이션의 경쟁력은 대규모 실제 태스크로 검증된 Domain Skills에 달려 있을 것입니다. 이러한 Skills는 “이 분야에서 일이 어떻게 진행되어야 하는지”를 축적하며, 새로운 모델로 쉽게 덮어씌워지지 않고, 새로운 플랫폼으로도 쉽게 대체되지 않으며, 오히려 시간이 지남에 따라 복리로 쌓이게 됩니다.

조직이 지속적으로 Skill을 축적하고, 모든 새로운 작업을 Skill의 점진적 업데이트로 전환할 수 있다면, 해당 조직의 AI 역량은 구매한 것이 아니라 스스로 성장시킨 것이다.

8. 산업 렌즈: 4가지 유형의 조직이 AI를落地하는 구체적 형태

다음 네 단락은 서사가 아니라 추상적인 ‘7단계 Stack’을 구체적인 산업에 매핑한 것이다. 각 산업이 어디서 벽에 부딪히는지를 살펴본다.

통신/통신사업자: 요금제 변경, 기업 전용 회선 개통, 도메인 간 장애 위치 파악 등은 모두 BSS/OSS/CRM/결제 등 여러 도메인을 넘나들어야 한다. Agent 적용에서 가장 큰 병목은 도메인 간 정산이다. 한 Agent가 CRM에서 사용자 요금제를 변경하면, 이를 결제 시스템과 OSS에 동기화해야 한다. 그렇지 않으면 결제 주기에 불일치가 발생한다. Stack에서 가장 가치가 높은 계층은 다중 도메인 인터페이스를 연결하는 5단계 Runtime & Tools와 결제 감사를 담당하는 7단계 Governance이다.

금융/은행: 리스크 관리, 자금세탁방지, 정산, 규제 보고 등 모든 영역에서 설명 가능성, 감사 가능성, 추적 가능성을 요구한다. 자금세탁방지 Agent가 “승인” 또는 “차단”을 결정할 때마다 어떤 규칙, 어떤 거래 이력, 어떤 고객 정보를 근거로 했는지를 명확히 설명할 수 있어야 한다. Stack에서 가장 핵심적인 것은 제6층 Verification(설명 가능한 증거 사슬)과 제7층 Governance(알고리즘 등록 + 데이터 해외 전송 관리)이다. 이 두 층은 국내 금융 규제 프레임워크에서 출시의 필수 조건이며, 단순한 “가산점”이 아니다.

제조업: MES, ERP, QMS, SRM은 장기간 서로 단절된 상태로 있어, 교차 도메인 의사결정(예: “생산능력이 부족할 때 자재 추가 구매 여부”)을 내려려면 네 시스템 사이를 오가며 확인해야 한다. 제조업에서 Agent의 실제 형태는 단일 시스템을 대체하는 것이 아니라 시스템 간 오케스트레이션 계층이다. ERP의 자재 정보, QMS의 불량률, MES의 생산능력 가동률, SRM의 공급업체 성과 데이터를 동시에 읽어들여 종합적 판단을 내린다. Stack에서 가장 가치가 있는 것은 제5층 Runtime(기업 API 게이트웨이)과 제3층 Context(공정 지식, 역사적 고장, 현장 경험의 축적)이다.

이커머스: 대규모 할인 행사 시 도메인 간 상호 운영(주문, 결제, 재고, 물류, 고객 서비스), 부하 테스트 / 재고 일관성 유지 / 반복 적립금 부정 사용 방지 / 크로스 플랫폼 정산. 이커머스 분야에서 Agent가 가장 먼저 정착한 영역은 크리에이티브 운영(상품 이미지 교체, 배경 변경, 다국어 소재 제작)과 고객 서비스 좌석 지원이다. Stack에서 가장 가치가 높은 것은 4단계 Skill(각 플랫폼 SKU / 채널별合规 및 심사 프로세스)과 6단계 Verification(플랫폼 규범 충족 여부 자동 검증)이다.

네 가지 유형의 조직 공통점: Stack은 아래로 갈수록 공유 가치가 높아지고, 위로 갈수록 자체 구축 가치가 높아진다. Runtime, Model Router, Tool Gateway 같은 기반 능력은 여러 기업이 함께 구축하거나 성숙한 오픈소스 스택을 도입하는 것이 더 경제적이다; Skill, Context, Governance는 반드시 자체 구축해야 하는데, 이는 업무 프로세스, 규제 준수, 조직 자산과紧密结合되기 때문이다.

9. 최종 제품은 다르게 보일 수 있지만, 기반에는 동일한 OS가 공존한다

Coding Agent와 비디오 Agent는 UI, 사용자 경험, 비즈니스 모델이 완전히 다르다.

그러나 기반에서는 모두 필요로 하는 요소들이 있다: Context, Task, Skill, Tools, Runtime, Verification, Memory, Governance. 결국 모두 업무 성과로 귀결되어야 한다.

기업 지식 에이전트와 브라우저 에이전트는 표면적으로는 큰 차이가 있어 보이지만, 결국에는 동일한 과제를 해결해야 한다. 바로 권한 관리, 상태 처리, 장애 복구, 감사이다.

따라서 여러 AI 제품을 개발할 때는 두 가지 층으로 구분하는 것이 중요하다.

상위 층은 각 분야에 특화해야 한다. 각 제품은 고유한 Job을 중심으로 설계되며, 독자적인 사용자 경험, 데이터 객체, 업무 지표를 가진다. 예컨대 Coding Agent는 Repo와 Code Review를, 영상 Agent는 Script와 Asset을, 리서치 Agent는 Source와 Citation을 다룬다. 각 제품의 전문 깊이는 범용 능력으로 대체할 수 없다.

하위 층은 최대한 공유해야 한다. Agent Runtime, Model Router, Tool Gateway, Memory, Audit, Secrets, Evaluation 등은 범용 인프라로 구축할 수 있다.

이런 접근법은 각 제품마다 바퀴를 다시 발명하는 것을 막아줄 뿐 아니라, 처음부터 거대하고 사용자가 없는 “범용 Agent 플랫폼”을 만드는 것도 예방해 준다. 후자는 지난 2년간 수많은 팀이 밟았던 함정이다. 모든 시나리오를 한 번에 처리하려다 결국 어느 시나리오도 사용 가능한 수준까지 파고들지 못했다.

더 안정적인 경로는 먼저 구체적인 작업에서 가치를 검증한 다음, 반복적으로 나타나는底层能力를 추출하는 것이다. 핵심 판단: 通用层은 구체적인场景에서만 성장할 수 있으며, 아키텍처図에서 성장할 수 없다. 처음부터 “모든场景을 지원”하는 런타임을 설계하면, 대개 어떤场景도 제대로处理하지 못한다는 것을 의미한다.

역방향 자체 检查 3가지 질문(작성 후 스스로 대조):

우리가抽象한 런타임이 최소 두 개의 구체적인场景에서 범용성이 검증되었는가?
각 계층의 설계가 실제 오류가 발생했던 구체적인业务 문제와 대응되는가?
오늘 예산의 절반이 사라진다면, 어떤 계층을 남길 것인가? 답이 “context와 skill”이라면 방향이 맞다; “runtime과 网关”라면 다시 만들어야 할 수 있다.

이는 이번 클라우드 컴퓨팅开发者大会上 남겨진 장기적 판단이기도 하다: 모델 위에 새로운 시스템 계층이 성장하고 있는데, 이는 특정 제품 전용이 아니라 Agent 시대의 OS로 점차 변하고 있다. 이 OS 계층을 먼저 확실히 구축한 기업이 다음 제품迭代에서 더 큰 혜택을 누릴 가능성이 높다.

의사결정자를 위한 시사점

연간 매출 50억 위안 이상의 기업 AI 책임자(CDO/CIO/CTO)라면, 지금 바로 시작할 수 있는 세 가지가 있다:

조직의 현재 Agent Stack 7단계 스냅샷 그리기

조직의 현재 Agent Stack 7단계 스냅샷을 그려라 — 제품을 구입하느라 서두르지 말고, 각 단계가 현재 비어 있는지, 외부 솔루션을 활용하고 있는지, 아니면 반제품 상태인지 먼저 파악해야 한다. 이 그림 자체가 진정한 병목 현상을 드러낼 것이다.
높은 ROI 시나리오 1개를 선택하여 완전한 수직 폐쇄 루프를 먼저 완료하라 — Runtime을 먼저 구축하지 말 것. Coding Agent, 고객 지원 보조, 연구 개발 어시스턴트 중 하나를 선택하여 Context, Task, Skill, Verification의 4개 단계를 완전히 돌려본 후, “플랫폼 구축”에 대해 논의할 것.
거버넌스를 컴플라이언스 수준이 아닌 엔지니어링 수준으로 끌어올려라 — 권한, 감사, 설명 가능성, 오류 귀인, 서드파티 의존성 관리 등을 처음부터 비즈니스 Agent와 함께 설계해야 하며, 나중에 보강하지 않을 것.

궁금해하실 점

Q1: 이 7단계 Stack과 Gartner, IDC가 제시한 다중 Agent 오케스트레이션 프레임워크는 어떤 차이가 있나요?

Gartner/IDC는 조직 차원에서 다중 Agent 간의 협업과 거버넌스에 관심을 둔다. 본문의 7단계는 단일 Agent 내부의 엔지니어링 구조다. 한 조직은 두 가지를 동시에 논할 수 있다 — 단일 Agent는 7단계를 따르고, 다중 Agent 간에는 오케스트레이션을 수행한다. Stack은 미시적 관점이며, 오케스트레이션은 거시적 관점이다.

Q2: 왜 모델那一层没有单独占一层?

모델은 Agent 시스템에서 독점적인 계층이 아니라横向贯穿的资源이다. Model Router는 서로 다른 모델을 다양한 컴퓨팅 자원의 하나의 수준으로 처리하며, Runtime의 Shell이나 Browser와 동일한 위치에 있는 “도구”다. 물론 모델은 중요하지만, Agent의 복잡성을 독점할 수는 없다.

Q3: 소규모 팀은 이 계층을 건너뛰고 ChatGPT / Claude 같은 엔드투엔드 제품을 직접 사용해야 하는가?

그렇다. 연매출 1억 미만이고 조직 복잡도가 낮은 팀이라면, Browser Use, Manus,阿里云百炼 Agent 같은 기존 Agent 제품을 직접 사용하는 것이 더 효율적이다. 이 글에서 논의하는 일곱 계층은 “연매출 50억 이상의 조직에서 자체 Agent 플랫폼을 구축할 것인가”라는 문제에서 출발한 것이다. 소규모 팀이 플랫폼을 구축하는 것은 역효과를 야기하는 최적화다.

역방향 자기 점검(여러분을 위해서, 그리고 저 자신을 위해서)

다음 세 가지 문장 중 어느 하나라도 내심 고개를 끄덕인다면, 당신은 증거가 아닌 서사에 휘둘리고 있을 가능성이 있다.

AI를 천천히 배우기

“모델만 충분히 강력하면 Agent가 알아서 작동할 것이다.”(모델은 필요한 조건이지 충분한 조건은 아니다. 하위 여섯 단계가 프로덕션 적용 가능 여부를 결정한다.)
“만능 Agent 플랫폼이 필요하다.”(이러한想法는 6개월 이내에 창출할 수 있는 사업 가치보다 비용이大概率 높을 것이다.)
“Skill은 모델이 안정된 후에 쌓아도 된다.”(Skill은 조직 자산이다. 하루라도 늦게 축적하면, 하루라도 이자 효과를 놓친다.)

위의 세 가지에 공감하지 못한다면, 계속 읽어나가시기 바란다.

문末 인용 설명(출처 항목별 + 증거 수준 + 입장 표기)

“하나의 작업대. 네 가지 진입점. 하나의 기반.” ——Qoder 공식 전시 부스 및 블로그, 2026년 클라우드 컴퓨팅 컨퍼런스 현장 + Alibaba Cloud Community 2026-08-31 게재 Introducing Qoder 1.0 문서. 증거 수준:厂商주장(Alibaba 입장).
QwenWork Legal Document Fill Out: 샌드박스 컨테이너 + 가상 데스크톱 + 도구 호출 ——Alibaba Cloud QwenWork 현장 데모, Alibaba Cloud Community 2026-09-25 기사. 증거 수준:厂商주장(Alibaba 입장).
QoderWake “디지털 직원” 제품, 2026-04-30 Alibaba 출시 ——Baidu Encyclopedia Qoder 항목 + Alibaba 공식. 증거 수준:厂商주장(Alibaba 입장).
OWASP 2026 위협 목록에서 Prompt Injection이 1위에 꼽히다 — State of Browser Use, May 2026 종합(Michael Livs blog). 증거 레벨: 제3자 종합(OWASP 입장, 업계 합의).
Requesty: 단계적 라우팅 70/20/10 배분으로 비용 60~80% 절감 가능 — Requesty 공식 블로그, 2026. 증거 레벨:厂商 주장(모델 라우팅 서비스 제공자 입장, 수치는 낙관적, 방향성示意만 참고).
Microsoft Agent Governance Toolkit (AGT), 2026-04-02 MIT 오픈소스 — niteagent.com 보도. 증거 레벨: 제3자 종합(마이크로소프트 입장, AGT는 오픈소스 프로젝트로 수치 확인 가능).
Anthropic Skills 프로토콜: 2025-10-16 发布, 2025-12-18 오픈소스 공개 ——Anthropic Engineering 블로그 + Substack 종합 + Medium LM Po。증거层级:厂商 제공 자료 + 제3자 종합(Anthropic 입장)。
IDC 예측 2026년 제조업체의 40%가 AI 기반 스케줄링 도입 ——Groovy Web 2026 리뷰, IDC 보고서 인용。증거层级: 제3자 종합(IDC 입장, 수치 방향성 참고)。
Stripe “Minions” 주간 1,300+ PR 병합, 코드 작성 0명, 전원 수동 리뷰 ——Stripe 엔지니어링 팀 Steve Kaliski, How I AI 2026-03-25 방송 + ByteMonk 2026-02-14 전술。증거层级:厂商 제공 자료(Stripe 입장, 수치 참고 가능, 적용 범위는 Stripe 엔지니어링 내부로业界 평균으로 일반화 불가)。
BCG 2026 Applied AI Index: agentic AI가 AI 총 가치의 22%(2026)→ 39%(2030) 차지 예측 ——BCG 공개 보고서. 증거 수준: 제3자 종합(컨설팅 기관 관점, 수치 방향성 참고).
Gartner, 2026년 기업 애플리케이션 40%에 작업형 AI Agent 통합 전망: 2025년 <5% 대비 ——Paul Okhrem 2026 리뷰, Gartner 인용. 증거 수준: 제3자 종합(Gartner 관점, 방향성 참고).
중국 CAC/NDRC/MIIT 공동 발표 <스마트체 표준화 적용 및 혁신 발전 실시 의견>, 2026-07-15 시행 ——Rimon Law 2026년 7월 중국 AI 규제 브리프. 증거 수준: 제3자 종합(법률 기관 관점, 규제 문서 확인 가능).
TinyFish: 투자 $47M, 고객사 Google / DoorDash / Amazon 포함, browser 콜드스타트 <250ms ——SwitchTools 2026 리뷰. 증거 수준: 서드파티 종합(제품 리뷰 사이트 입장이며, 수치는 TinyFish 공식을 통해 확인 필요).

기업 내부 Agent 플랫폼 구축 방법, 어떤 역량을 자체 구축 / 구매 / 공유해야 하는지, 어떤 Agent Runtime의 재사용 가치가 가장 높은지를 평가 중이시라면, 언제든 논의해 보시기 바랍니다. 당사는 기업 AI 전환 전문 컨설팅을 제공합니다——Agent 아키텍처, Runtime 설계부터 Skill 축적에 이르기까지, ‘단일 Agent’를 ‘조직 차원의 Agent 플랫폼’으로 체계화해 드립니다.

기업 내부 교육: 임원진 및 핵심 실무진 대상, 3일 기초 과정 9만 위안/회, Agent Stack 7단계, Governance 엔지니어링 관점, Skill 축적 방법론을 팀에 맞춰 체계적으로 안내합니다.
맞춤형 자문: 90분 아키텍처 진단 3천 위안부터, 조직의 현재 7단계 스냅샷, 미충족 영역, 외부 구매 vs 자체 개발 판단에 대한 독립적 평가 제공; 심층 멘토링은 프로젝트 단위 견적제
임원 간담 및 업계 세션: 업계 컨퍼런스 / 폐쇄형 간담회 / 포럼 테마演讲, 상담 후 맞춤 아젠다 구성

연락처 이메일: [email protected]

추가 자료: 《AI 전환 7단계 프레임워크》, 기업 AI 도입의 전 과정을 체계적으로 설명합니다.

현지화 핵심 사항(다국어 번역 가이드, IAIUSE 다국어 전략·2026-08-09 협약)

19개 언어로 번역 시, 다음 내용을 대상 언어 시장에 맞게 현지화하되 구조/디자인은 유지합니다.

中文稿内容	英文版	日文版	独文版	アラビア語版
Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch(製品名を保持)	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch

중국은행 (금융 사례)	JPMorgan / Goldman Sachs	Mitsubishi UFJ / SMFG	Deutsche Bank / Commerzbank	Emirates NBD / QNB
샌드박스 컨테이너 / 가상 데스크톱 / 도구 호출	Sandbox Container / Virtual Desktop / Tool Calling	サンドボックス / 仮想デスクトップ / ツール呼び出し	Sandbox‑Container / Virtueller Desktop / Werkzeugaufruf	حاوية معزولة / سطح مكتب افتراضي / استدعاء الأدوات
One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness	One Foundation / Harness

| 도메인 스킬 / 코딩 스킬 / SEO 리서치 스킬 / 이커머스 창작 스킬 / 운영 스킬 | 도메인 스킬(보존) / 코딩 스킬 / SEO 리서치 스킬 / 이커머스 창작 스킬 / 운영 스킬 | 도메인 스킬 / 코딩 스킬 / SEO 리서치 스킬 / 이커머스 창작 스킬 / 운영 스킬 | 도메인-스킬 / 코딩-스킬 / SEO-리서치-스킬 / 이커머스-창작-스킬 / 운영-스킬 | 도메인 스킬 / 코딩 스킬 / SEO 리서치 스킬 / 이커머스 창작 스킬 / 운영 스킬 |

이 시리즈에 대하여

「云栖观察」는 IAIUSE가，推出하는 산업 현장 시리즈로, 2026 Yunqi Conference에서 출발하여, 연구자의 시각으로 AI 산업에서，正在发生하는 실제 변화를 분석한다——핫이슈를 추종하지 않고, 판단의 방향과 증거의 강도를 중시한다.

시리즈는 모델 상층의 시스템 레이어, Agent 구현, Context 자산, 기업 AI 조직 설계, AI 제품 경쟁 단위의 이동 등을 다루며, 총 약 10편으로 구성된다.

저자 소개

저는 약 8년간 대기업 컨설팅 및 비즈니스 분석 경험을 보유하고 있습니다. IBM에서 재직하며 통신, 금융, 보험, 제조업 관련 프로젝트에 참여했습니다. 이후 통신사 제품, 인터넷 제품, AI 애플리케이션 개발 현장에서 요구사항 분석, 제품 설계, 크로스 팀 구현 업무를 지속적으로 수행해 왔습니다.

이 블로그를 운영하는 것은 사실 작은 팀입니다—저와 장기적으로 협력하는 1~2명의 동료가 각각 AI 프로그래밍 도구 연구, 조직 거버넌스 사례 정리, 코칭 대화 영역을 담당하고 있습니다.文中 “우리가企业与共に見てきた”라는 표현은, 해당 프로젝트들이 우리 팀원들이 공동으로 수행한 것임을 의미합니다.

研究资料库는 200편 이상의 자료를 누적하고 있습니다.本 시리즈의 판단은 현장 관찰과 업계 교차 검증을 바탕으로 하며, 명확한 저자관을 제시합니다.이는 어떤厂商의 관점도 대변하지 않습니다.