1장. LLM에서 Agentic AI로: “말 잘하는 애”를 넘어, “일을 끝내는 애”로

1장. LLM에서 Agentic AI로: “말 잘하는 애”를 넘어, “일을 끝내는 애”로

챗GPT, Claude 같은 LLM이 처음 나왔을 때 사람들은 주로 이렇게 썼습니다.

질문 던지고, 답변 받고, 코드 한두 함수 뽑아 쓰고, 글 뼈대 잡게 하고.

그런데 실제로 일하는 현장에 이 모델들을 꽤 오래 붙여본 사람일수록 비슷한 느낌을 받게 됩니다.

“생각은 잘하는데, 끝까지 일을 해주지는 않는다.”

답을 설명하는 것과,

“그 답을 바탕으로 실제로 일을 끝내는 것” 사이에는 꽤 큰 간극이 있습니다.

예를 들어 개발 환경을 떠올려 보면:

• 로그를 요약해 주고, 버그 원인을 추측해 주는 것까지는 잘합니다.

• 하지만 실제로:

  • 관련 코드를 찾아가고,

  • 수정하고,

  • 테스트를 돌리고,

  • CI 상태를 확인하고,

  • 이슈 트래커에 정리하는 것까지

    자동으로 끝내주는 경우는 거의 없습니다.

이 간극 때문에 생기는 패턴이 있습니다.

“모델이 아이디어를 주고, 사람은 그걸 들고 각종 툴과 시스템 사이를 뛰어다니며 마무리한다.”

뇌와 입은 모델이 맡고, 손발은 여전히 사람이 다 쓰는 구조죠.

Agentic AI라는 흐름은 이 간극에서 출발합니다.

단순히 “더 똑똑한 LLM”이 아니라, 아예 기본 목표를 다르게 잡습니다.

질문에 잘 답하는 도우미가 아니라,

목표를 받고 스스로 일을 끝까지 밀어붙이는 실행자.

그래서 여기서 중요한 건 “얼마나 말을 잘하느냐”가 아니라,

“얼마나 일을 자율적으로 끝까지 가져가느냐”입니다.

---

AI Agent와 Agentic AI, 같은 말 같지만 다른 초점

Agent라는 말은 꽤 오래 쓰였기 때문에,

AI Agent와 Agentic AI가 뒤섞여서 쓰이는 경우가 많습니다.

하지만 요즘 논의에서 보통 이렇게 구분하는 편이 이해하기 편합니다.

• AI Agent

  • 특정 입력에 대해 미리 짜둔 정책이나 규칙으로 반응하는 모든 시스템을 넓게 포함하는 말입니다.
  • 챗봇, 간단한 자동화 스크립트, 추천 시스템까지 다 들어갈 수 있습니다.

• Agentic AI

  • LLM처럼 범용적인 추론 능력을 가진 모델을 기반으로 합니다.
  • 목표를 받으면,
    • 해야 할 일을 스스로 쪼개고,
    • 순서를 계획하고,
    • 외부 도구와 시스템을 호출하며,
    • 중간 결과를 보면서 전략을 수정하고,
    • 최종적으로 “완료된 결과물”을 만들어내려는 방향으로 설계된 시스템을 가리킵니다.

여기서 핵심은 자율성입니다.

프롬프트 한 번 → 답변 한 번의 왕복이 아니라,

“목표 달성까지 여러 번 왕복하면서 알아서 버티는 능력”에 가까운 개념입니다.

조금 더 현실적인 관점에서 보면, Agentic AI는 이런 질문들에 직접 답을 내리는 시도입니다.

• 이 시스템은 단순히 답변만 주는가, 아니면 실제 시스템 상태를 바꾸는가?

  (예: 코드 커밋, 이슈 생성, 배포, 알림 발송, DB 업데이트 등)

• 이 시스템은 매 요청을 항상 새로 시작하는가, 아니면 프로젝트·사용자·조직의 맥락을 기억하고 발전시키는가?

• 한 에이전트가 다 하려 드는 구조인가, 아니면 역할이 다른 여러 에이전트를 조율하는 구조인가?

결국 Agentic AI라는 말은

“에이전트처럼 생긴 인터페이스”를 말하는 게 아니라,

“목표를 끝까지 밀어붙이는 방식”을 말하는 쪽에 가깝습니다.

---

이 글이 보려는 관점: 기술 스택이 아니라 “풀스택 작동 방식”

Agentic AI 이야기를 들여다보면,

한쪽 극단은 모델 성능 이야기에만 빠지고,

다른 극단은 마케팅 용어 나열에만 시간을 쓰는 경우가 많습니다.

여기서 다루려는 관점은 조금 다릅니다.

어떤 한 기술만 확대해서 보지 않고, 실제로 의미 있게 작동하는 “풀스택 구조”를 한 번에 묶어서 보려는 관점입니다.

이때 자연스럽게 등장하는 키워드가 몇 가지 있습니다.

• MCP(Model Context Protocol)

  • LLM이 외부 시스템과 정돈된 방식으로 통신하기 위한 프로토콜입니다.
  • 일종의 “에이전트 시대의 표준 인터페이스 후보”라고 볼 수 있습니다.

• Bun

  • JS/TS 기반 에이전트와 웹·서버 애플리케이션을 빠르게 돌리기 위한 런타임·툴체인입니다.
  • Agentic 워크로드를 실제로 받쳐주는 실행 인프라에 가깝습니다.

• Claude Code

  • 개발자가 매일 쓰는 IDE 경험 속에 들어와 있는 에이전틱 환경의 대표 사례입니다.
  • 단순 코드 자동완성을 넘어서, 리포지토리 단위로 일을 받아 처리하는 쪽으로 움직이고 있습니다.

• 그리고 “사람들이 실제로 에이전트를 어떻게 쓰고 있는지”에 대한 관찰

  • 어떤 업무부터 에이전트에게 넘기는지,
  • 어디에서 불편함과 불안을 느끼는지,
  • 조직 구조와 역할이 어떻게 변하는지.

이 글의 목표는 이 요소들을 각각 분리해서 설명하는 데서 끝내지 않습니다.

대신 이런 질문에 답을 내리려 합니다.

• 이 스택이 실제로 사람의 일을 어떻게 바꾸는가?

• 어떤 패턴에서 처음으로 “Agentic AI가 없으면 안 되는 상태”가 생기는가?

• 이걸 도입하는 조직 입장에서, 기술·운영·거버넌스는 어떻게 재구성해야 하는가?

그래서 뒤의 장들은 대략 이런 흐름으로 이어집니다.

• 2장에서는 Agentic AI 전체 스택의 지도를 한 번에 그려보고,

• 3장에서는 MCP와 Agentic AI Foundation을 통해 “표준·프로토콜·생태계”를,

• 4장에서는 Bun을 통해 “AI 네이티브 런타임”이라는 개념을,

• 5장에서는 Claude Code를 통해 실제 Dev 환경에서 돌아가는 Agentic 사례를,

• 6장에서는 사람들이/조직이 에이전트를 어떻게 쓰고 있는지 패턴을,

• 7장에서는 AgentOps와 거버넌스, 그리고 앞으로의 과제를 정리합니다.

1장은 그 전체 여정의 프롤로그입니다.

“왜 이제 LLM을 넘어 Agentic AI를 이야기해야 하는가?”를 정리하고,

이후에 나올 기술·사례·운영 이야기를 받아들이기 위한 좌표를 맞추는 단계라고 보면 됩니다.

2장. Agentic AI 기술 스택: 머릿속에 한 장짜리 지도를 먼저 그리기

2장. Agentic AI 기술 스택: 머릿속에 한 장짜리 지도를 먼저 그리기

Agentic AI 이야기를 조금만 깊게 들어가면 금방 복잡해집니다.

모델 이름, 프롬프트 엔지니어링, 에이전트 프레임워크, 오케스트레이션 엔진, 각종 툴과 API…

이럴 때 제일 먼저 하는 게 좋다고 생각하는 작업은 단순합니다.

“화이트보드에다 한 장짜리 스택 그림을 그려놓고 시작하기.”

어떤 회사든, 어떤 제품이든, 어떤 도메인이든

결국 이 한 장짜리 스택 그림 위에 올라가는 모양만 조금씩 다를 뿐입니다.

이 장에서는 그 “기본 지도”를 먼저 그려보려고 합니다.

---

2.1 다섯 개의 레이어로 보는 Agentic 풀스택

Agentic AI를 실무 관점에서 보면, 대체로 다음 다섯 레이어로 정리할 수 있습니다.

• 모델 레이어

• 도구·프로토콜 레이어

• 에이전트·오케스트레이션 레이어

• 애플리케이션 레이어

• 운영·거버넌스 레이어

이 다섯 개를 하나씩 아래에서 풀어보겠습니다.

나중에 MCP, Bun, Claude Code를 이야기할 때도 계속 이 구조 위에 얹어서 볼 수 있습니다.

---

1) 모델 레이어: 뇌에 해당하는 부분

가장 아래에는 결국 모델이 있습니다.

Claude, GPT, 기타 특화 모델들이 이 레이어에 해당합니다.

여기서 중요한 질문은 “누가 더 똑똑한가?” 보다는 “어떤 역할 분담을 할 것인가?”에 가깝습니다.

• 범용 LLM

  • 자연어 이해, 코드 이해, 추론, 요약 등 대부분의 인지 작업을 담당합니다.

• 도메인 특화 모델

  • 예를 들어 차량 로그, 의료 데이터, 보안 이벤트 로그 등 특정 포맷에 강한 모델이 따로 있을 수 있습니다.

• 멀티모달 모델

  • 텍스트, 이미지, 코드, 테이블 등을 같이 다루면서 복합적인 판단을 내립니다.

Agentic 관점에서 모델 레이어는 “생각하고 판단하는 부분”입니다.

하지만 이 레이어만 가지고는 아무 것도 바뀌지 않습니다.

머리를 하나 올려야, 비로소 바깥 세상과 연결됩니다.

---

2) 도구·프로토콜 레이어: 팔·다리가 연결되는 부분

모델이 아무리 똑똑해도,

도구와 시스템에 접근할 방법이 없으면 할 수 있는 일이 제한적입니다.

그래서 두 번째 레이어에는 다음과 같은 요소들이 자리합니다.

• 내부·외부 API

  • 사내 시스템, DB, 로그 스토어, CI/CD, 티켓 시스템, CRM, ERP 등

• SaaS 및 개발자 도구

  • GitHub, Jira, Slack, Notion, Google Drive 같은 것들

• 프로토콜·표준

  • MCP 같은 “모델이 도구·리소스를 발견하고 호출하기 위한 공통 인터페이스”

여기서 핵심은 “모델이 도구에 접근하는 방식”을 정리하는 것입니다.

• 각 에이전트마다 제각각 플러그인을 붙이는 방식으로 갈 것인지

• 아니면 MCP처럼 비교적 표준화된 인터페이스를 통해

  툴과 리소스를 주입할 것인지

도구 레이어는 결국 이렇게 요약할 수 있습니다.

“모델이 바깥세상의 버튼·레버·센서를 만지는 방식.”

Agentic AI가 실전에서 의미를 가지려면

이 레이어가 단단하게 설계되어 있어야 합니다.

---

3) 에이전트·오케스트레이션 레이어: 생각과 행동을 묶는 두뇌

세 번째 레이어가 사실 Agentic AI를 Agentic하게 만드는 핵심입니다.

이 레이어는 대체로 이런 역할들을 포함합니다.

• 목표를 이해하고 작업을 쪼개는 플래너

• 어떤 도구를 언제 쓸지 결정하는 정책

• 중간 결과를 보고 다음 스텝을 선택하는 루프

• 여러 에이전트 간의 역할 분담과 메시지 전달

• 메모리·상태 관리 (프로젝트 단위, 세션 단위, 사용자 단위)

여기서 중요한 포인트는 두 가지입니다.

첫째, “에이전트 = 모델”이 아니라는 점입니다.

에이전트는 보통:

• 하나 이상의 모델 호출,

• 도구 호출,

• 상태 업데이트,

• 제어 로직

이 섞여 있는 구조입니다. LLM은 그 안에서 추론·생성 역할을 맡을 뿐입니다.

둘째, 이 레이어가 설계되는 방식에 따라

시스템이 얼마나 “자율적으로 버티는지”가 결정됩니다.

• 단순한 에이전트

  • “사용자가 부탁할 때마다 툴 한 번 호출해주는 수준”

• Agentic 에이전트

  • “목표를 전달하면 필요한 단계를 스스로 만들어서,

    도구와 상호작용을 반복하면서 완료 상태까지 끌고 가는 수준”

이 차이가 바로 Agentic AI의 진폭을 좌우합니다.

---

4) 애플리케이션 레이어: 사람이 실제로 만나는 얼굴

네 번째 레이어는 사람이 실제로 사용하는 제품·서비스입니다.

• 개발자에게는 IDE 안의 Claude Code 같은 환경

• 지식노동자에게는 리서치·정리·레포트 에이전트

• 운영·보안 팀에게는 알람 triage, 로그 분석 에이전트

• 현장 작업자에게는 모바일/웹 기반 업무 보조 에이전트

여기서부터는 기술만으로 설명이 되지 않습니다.

• UX:

  • 채팅 UI가 맞는지,
  • 워크플로 빌더가 맞는지,
  • IDE/툴 내부에 자연스럽게 녹이는 게 맞는지.

• 온보딩:

  • 사용자가 에이전트를 어떻게 이해하고 신뢰하게 되는지.

• 유즈케이스:

  • 어떤 업무부터 에이전트에 넘기는 게 가장 효율적인지.

같은 에이전트라도 UI와 컨텍스트에 따라 “전혀 다른 제품처럼” 느껴집니다.

그래서 애플리케이션 레이어는 기술 스택과 별개로,

도메인 이해와 프로덕트 감각이 매우 크게 작동하는 영역입니다.

Claude Code 같은 사례는 이 레이어에서의 Agentic 적용 예시를 보여주는 좋은 샘플 중 하나입니다.

---

5) 운영·거버넌스 레이어: AgentOps의 세계

마지막 레이어는 종종 간과되지만,

실제로 엔터프라이즈 도입 단계에서 가장 많은 질문이 쏟아지는 부분입니다.

• 이 에이전트가 지금 어떤 행동을 하고 있는지 어떻게 모니터링할 것인가?

• 잘못된 행동을 했을 때 어떻게 막고, 되돌리고, 수정할 것인가?

• 어떤 데이터·시스템에 어디까지 접근하게 할 것인가?

• 로그와 감사 기록을 어떻게 남기고 관리할 것인가?

• 규제·컴플라이언스 이슈는 어떻게 대응할 것인가?

이 레이어는 보통 세 가지를 동시에 다룹니다.

• 관찰(Observability)

• 제어(Control)

• 책임(Accountability)

Agentic AI가 실제 조직에 들어가면

“이 에이전트를 누가 책임질 것인가?”라는 질문을 피할 수 없습니다.

그래서 AgentOps라는 개념이 등장합니다.

모델을 운영하는 MLOps에서 한 단계 올라가,

“에이전트의 행동 자체를 운영·관찰·통제하는 프레임”입니다.

---

2.2 이 스택으로 생각하면 좋은 점

이 다섯 개 레이어를 한 번 머릿속에 박아두면,

이후의 모든 논의를 꽤 정리된 상태에서 볼 수 있습니다.

• 어떤 논의는 모델 레벨 얘기인지,

• MCP 같은 프로토콜 레벨 얘기인지,

• 에이전트 설계 얘기인지,

• 제품 UX 얘기인지,

• 거버넌스·조직 얘기인지

레이어를 구분해놓으면,

각 레벨에서 해야 할 질문과 설계 포인트가 자연스럽게 나옵니다.

예를 들어 “Bun 인수” 이야기를 들을 때도,

“아, 이건 실행 인프라 레이어에 대한 전략적 선택이구나.”라고 바로 위치를 잡을 수 있습니다.

MCP와 Agentic AI Foundation 이야기를 읽을 때는,

“이건 도구·프로토콜 레이어와 생태계·거버넌스 레이어에 걸친 움직임이구나.”라고 볼 수 있습니다.

그리고 무엇보다,

어떤 PoC를 설계하든, 어떤 제품을 기획하든, 어떤 교육·커뮤니티를 만들든

결국 다음 질문으로 정리할 수 있습니다.

• 이 시도는 이 다섯 레이어 중 어디를 건드리는가?

• 지금 부족한 레이어는 어디고,

• 당장 손댈 수 있는 레이어는 어디인가?

---

2.3 다음 장으로 넘어가기 전에

2장은 “지도 그리기”에 가까운 챕터입니다.

세부 기술이나 사례보다는,

Agentic AI를 바라볼 때 기본이 되는 스택 프레임을 세팅하는 단계입니다.

이제 이 지도를 들고,

다음 장에서는 프로토콜 레이어 쪽 —

특히 MCP와 Agentic AI Foundation이 어떤 역할을 하는지,

왜 굳이 오픈 프로토콜과 재단까지 만들어서 여기에 힘을 싣고 있는지 — 를 살펴보겠습니다.

3장. MCP와 Agentic AI Foundation: 에이전트 시대의 “USB-C 포트”를 만든다는 것

3. 프로토콜 레이어: MCP와 Agentic AI Foundation

앞 장에서 Agentic AI 스택을 다섯 개 레이어로 나누어 보았습니다.

그중 프로토콜 레이어는 에이전트가 외부 세계와 실제로 “손발을 맞추는” 구간입니다.

이 레이어를 설명할 때 빼놓을 수 없는 키워드가 바로 **MCP(Model Context Protocol)**이고,

이 MCP를 중심으로 만들어진 **Agentic AI Foundation(AAIF)**입니다.

3장은 이 두 가지를 통해 “에이전틱 시대의 표준 통신 계층”을 정리하는 장이라고 보면 됩니다.

---

3.1 MCP(Model Context Protocol)의 역할

MCP는 한 문장으로 정리하면 다음과 같은 역할을 합니다.

LLM 기반 애플리케이션이 외부 시스템(코드 저장소, 데이터베이스, SaaS, 사내 서비스 등)에

표준화된 방식으로 접근하도록 만들어 주는 도구/리소스 디스커버리 & 호출 프로토콜입니다.

기존에는 “툴 호출”이라고 하면 대부분 다음과 같은 모습이었습니다.

• 특정 모델 전용 플러그인 포맷을 따르고,

• 각 SaaS·각 사내 시스템마다 별도의 어댑터를 만들고,

• 모델이나 제품을 바꾸면 통합 코드를 상당 부분 다시 손봐야 하는 구조였습니다.

이 방식은 PoC 수준에서는 작동하지만,

스케일이 커질수록 다음과 같은 문제를 드러냅니다.

• 동일한 기능을 하는 통합 코드가

  모델·제품별로 중복 구현되는 현상

• 에이전트 로직과 통합 코드가 뒤섞이면서

  유지보수·테스트·교체가 어려워지는 문제

• 특정 벤더 생태계에 깊게 종속되는 구조

MCP는 이 지점을 정면으로 건드리는 프로토콜입니다.

핵심 아이디어는 단순합니다.

• “툴·리소스 제공자”는 MCP 서버로 자신을 노출합니다.

  어떤 리소스를 제공하고, 어떤 명령을 지원하는지 MCP 스키마로 선언합니다.

• “에이전트·AI 앱 쪽”은 MCP 호스트로서

  이 서버들을 공통된 방식으로 발견하고, 호출합니다.

이렇게 되면, 에이전트 입장에서는 다음과 같은 일이 가능해집니다.

• Git, DB, 사내 API, 외부 SaaS를 개별 플러그인이 아니라

  하나의 MCP 생태계로 바라볼 수 있습니다.

• “이 MCP 서버는 이런 리소스와 이런 툴을 제공한다”는 메타 정보를

  통일된 형식으로 받아들일 수 있습니다.

• 동일한 에이전트 로직을, MCP를 지원하는 여러 환경에서

  비교적 쉽게 재사용할 수 있습니다.

결국 MCP는 기존 ad-hoc 툴 호출 방식을,

• 벤더별 플러그인 → 공용 프로토콜

• 제품별 어댑터 → MCP 서버/호스트 구조

로 끌어올리는 시도라고 정리할 수 있습니다.

Agentic AI 스택에서 보면,

“에이전트가 바깥세상과 대화하는 기본 언어를 맞추는 계층”이라고 이해하면 자연스럽습니다.

---

3.2 Agentic AI Foundation(AAIF)의 의미

MCP 자체도 중요하지만,

이 프로토콜을 어디에 소속시키느냐 역시 생태계 관점에서는 매우 큰 결정입니다.

Agentic AI Foundation(AAIF)은 바로 이 지점에서 등장합니다.

구조는 다음과 같습니다.

• MCP를 포함한 몇몇 핵심 프로젝트를

  Linux Foundation 산하의 별도 재단으로 이관하는 형태입니다.

• 설립과 참여에는 Anthropic, OpenAI, Block 등이 중심적으로 관여합니다.

• 스폰서·회원으로는 Google, Microsoft, AWS 같은 메이저 클라우드 사업자들이 참여합니다.

이 조합이 의미하는 바는 곧바로 드러납니다.

“Agentic AI의 핵심 인프라는

특정 기업 하나의 폐쇄 생태계가 아니라,

인터넷 인프라급 공공재로 운영하겠다.”

즉, MCP와 유사한 프로젝트들을

• 한 회사의 제품 전략 변화에 휘둘리지 않는 곳에 두고,

• 여러 벤더와 오픈소스 커뮤니티가 함께 기여할 수 있는 구조로 만들며,

• 장기적으로는 HTTP, TCP/IP 같은 다른 인터넷 기반 기술들처럼

  “인프라 레벨의 표준”에 가깝게 가져가려는 방향성입니다.

Agentic AI 스택 관점에서 보면,

AAIF는 단순히 코드 저장소를 관리하는 수준을 넘어 다음을 의미합니다.

• 프로토콜 레벨의 설계와 진화를

  벤더 뉴트럴하게 조정하는 거버넌스 레이어

• 도구·서비스·플랫폼들이

  “우리는 이 공용 프로토콜을 따른다”라는 형태로

  상호운용성을 약속하는 장

결국 AAIF는 “프로토콜 레이어”를 기술적인 계층에만 가두지 않고,

생태계와 거버넌스 차원에서 함께 다루려는 시도라고 볼 수 있습니다.

---

3.3 연구 포인트

프로토콜 레벨의 표준화와 재단 설립은,

기술적 선택을 넘어서 다양한 연구·분석 포인트를 만들어냅니다.

실무와 연구 관점에서 특히 집중해서 볼 만한 지점은 다음과 같습니다.

• 도구/서비스 생태계에 미치는 영향

  • MCP를 중심으로 플러그인·커넥터 생태계가 어떻게 재편되는지 살펴볼 수 있습니다.

  • 개별 벤더 전용 플러그인에서, MCP 서버 기반의 “공용 커넥터”로 이동할 경우

    어떤 비즈니스 모델과 오픈소스 프로젝트가 등장하는지 분석할 수 있습니다.

• 에이전트 포터빌리티(Agent Portability)

  • 동일한 에이전트 로직이

    한 모델·한 제품 환경에 잠기지 않고

    다른 모델·다른 플랫폼으로 얼마나 쉽게 이동할 수 있는지 연구할 수 있습니다.

  • MCP와 같은 프로토콜이 도입되었을 때,

    에이전트 정의·워크플로 정의의 이식성이 실제로 얼마나 개선되는지

    사례·벤치마크 관점에서 측정할 수 있습니다.

• 엔터프라이즈 도입 속도와 방식

  • 표준화된 프로토콜이 있을 때와 없을 때,

    기업 내부에서 에이전틱 워크플로를 PoC → 파일럿 → 본격 도입으로

    가져가는 속도와 비용이 어떻게 달라지는지 분석할 수 있습니다.

  • 보안·컴플라이언스·거버넌스 측면에서

    MCP/AAIF 기반 접근이 얼마나 “설명 가능하고 감사 가능한 구조”를 제공하는지도

    중요한 연구 대상이 됩니다.

정리하면,

3장은 Agentic AI 스택에서 “프로토콜 레이어”를 담당하는 MCP와 AAIF를 통해

• 에이전트가 세상과 대화하는 방법을 어떻게 표준화할 것인지,

• 그 표준을 어떤 방식의 거버넌스 아래 둘 것인지,

• 그 결과로 생기는 생태계·이식성·도입 속도 변화는 무엇인지

라는 질문을 설정하는 챕터라고 볼 수 있습니다.

다음 장에서는 이 프로토콜 위에서 실제 코드를 실행하고 워크로드를 처리하는

실행 인프라 레이어, 특히 Bun과 같은 런타임이 어떤 의미를 가지는지 이어서 살펴보겠습니다.

4장. 실행 인프라 레이어: Bun 인수와 AI 네이티브 런타임

4. 실행 인프라 레이어: Bun 인수와 AI 네이티브 런타임

여기까지는 주로 “생각하는 쪽(모델·에이전트·프로토콜)”을 봤습니다.

이제 시야를 한 단계 아래로 내려가서, **“그 생각을 실제로 어디에서 어떻게 실행시키는지”**를 보려고 합니다.

Agentic AI를 진짜 서비스로 만들려면,

모델만큼이나 중요한 것이 바로 런타임과 실행 인프라입니다.

이 지점에서 최근 가장 상징적인 사건이

Anthropic의 Bun 인수와, 이를 둘러싼 “AI 네이티브 런타임” 논의입니다.(Anthropic)

---

4.1 Bun의 기술적 포지셔닝

Bun은 겉으로 보기에는 “Node.js 대체 런타임”처럼 보이지만,

조금만 뜯어보면 포지셔닝이 꽤 다릅니다.

가장 큰 특징은 올인원 웹/서버 런타임이라는 점입니다.

• JavaScript / TypeScript 런타임

• 번들러

• 패키지 매니저 (bun install)

• 테스트 러너 (bun test)

이 네 가지를 단일 바이너리 안에 통합한 툴킷입니다.(bun.com)

기술적으로는 다음과 같은 지점을 강하게 밀고 있습니다.

• Zig로 구현된 런타임 + WebKit의 JavaScriptCore 엔진 기반

  • Node.js의 V8 기반 구조 대비,

    시작 속도와 메모리 사용량을 크게 줄이는 것을 목표로 합니다.(GitHub)

• 런타임 + 번들러 + 테스트 러너 + 패키지 매니저를 통합

  • 별도 도구(Jest, Webpack, npm 등)를 조합하는 대신

    “처음부터 함께 설계된 툴체인”으로 가는 구조입니다.(Strapi)

• 높은 HTTP 처리량, 빠른 cold start, 빠른 테스트 실행

  • 벤치마크에서는 Node.js 대비 수 배 수준의 처리량과

    테스트 실행 속도 향상을 강조합니다.(Strapi)

이 특성들을 Agentic 워크로드 관점에서 보면 의미가 더 뚜렷해집니다.

에이전트 워크로드는 보통 이런 패턴을 가집니다.

• 짧은 작업을 매우 자주 호출합니다.

• 다양한 I/O(파일, 네트워크, DB, 도구 실행)를 섞어서 사용합니다.

• 테스트·검증·툴 호출을 반복적으로 수행합니다.

이런 워크로드에서는

• 시작이 빠른 런타임(cold start latency),

• 비동기 I/O에 최적화된 이벤트 루프,

• 툴체인 통합으로 인한 오버헤드 감소

같은 요소가 꽤 직접적인 성능·비용 차이로 이어집니다.(Strapi)

정리하면, Bun은 단순히 “Node.js를 대체할 수 있는 또 하나의 JS 런타임”이 아니라,

“에이전트가 자주 호출하는 종류의 작업들을

한 번에 다루기 좋은, 고성능 올인원 JS/TS 실행 환경”

으로 포지셔닝된 런타임이라고 볼 수 있습니다.

---

4.2 Anthropic의 Bun 인수 의미

이제 질문은 자연스럽게 이렇게 이어집니다.

“왜 모델 회사가 굳이 일반 목적 JS 런타임을 인수했을까?”

Anthropic의 공식 발표를 보면, 그림이 분명해집니다.

• Claude Code는 출시 6개월 만에

  연 10억 달러(run-rate) 매출을 돌파했다고 밝힙니다.(Anthropic)

• 동시에, 이 Claude Code와 앞으로의 AI 코딩 제품들의 성능을 더 끌어올리기 위해

  Bun을 인수했다고 명시합니다.(Anthropic)

Bun 쪽 블로그에서도 같은 방향성을 강조합니다.

• Bun은 앞으로

  • Claude Code,
  • Claude Agent SDK,
  • 향후 AI 코딩 제품들의 핵심 인프라가 된다고 선언합니다.(bun.com)

• 동시에, 런타임 자체는 MIT 라이선스 오픈소스로 유지하겠다고 밝혀

  커뮤니티·생태계를 계속 유지하겠다는 메시지를 줍니다.(bun.com)

이 조합이 의미하는 바는 꽤 전략적입니다.

첫째, 실행 기반의 수직 통합입니다.

• 모델 회사가 단순히 “API + UX 레이어”만 담당하는 것이 아니라,

  그 아래에서 코드를 실제로 실행하는 런타임까지

  직접 소유·최적화하는 구조로 가고 있습니다.(Jimmy Song)

• 이 말은 곧,

  • 모델 호출,

  • 코드 실행,

  • 테스트,

  • 툴 호출을 하나의 통합된 실행 경로에서

    최적화할 수 있다는 뜻이기도 합니다.

둘째, 오픈소스와 제품의 이중 트랙입니다.

• Bun은 계속해서 오픈소스로 공개되고,

  일반적인 JS/TS 런타임·툴체인으로 널리 쓰이는 생태계를 유지합니다.(bun.com)

• 동시에 Anthropic 내부에서는

  Claude Code와 에이전트 제품의 필요에 맞추어

  성능·안정성·관측성(Observability)을 깊이 있게 튜닝할 수 있습니다.

셋째, AI 제품이 런타임 선택을 주도하는 구조입니다.

• 지금까지는 JS 런타임 선택이

  웹·서버 애플리케이션 중심의 논리로 결정되는 경우가 많았습니다.

• Bun 인수는 “AI 코딩·에이전트 제품이 런타임 생태계의 방향을 좌우하기 시작했다”는

  구조적 신호로도 읽힙니다.(Jimmy Song)

정리하면, 이 인수는 단순히 “괜찮은 오픈소스 프로젝트를 사들였다” 수준이 아니라,

“에이전트·코딩 제품의 경쟁력을 위해

실행 인프라까지 통째로 끌어안고 최적화하겠다”는 선언에 가깝습니다.

---

4.3 연구 포인트: “AI 네이티브 런타임”이라는 개념

이제 남는 질문은 이것입니다.

“전통적인 애플리케이션 런타임과

에이전트/AI 시대의 ‘AI 네이티브 런타임’은 무엇이 다른가?”

이 장에서 던져볼 연구·분석 포인트를 정리하면 대략 다음과 같습니다.

1) AI 네이티브 런타임의 요구사항 정리

전통적인 웹/서버 런타임은 대체로 이런 것에 최적화되어 있습니다.

• 장시간 살아 있는 프로세스

• 비교적 예측 가능한 요청 패턴(웹 요청, API 호출)

• 주류는 “HTTP 처리량·지연 시간·스케일아웃” 중심의 튜닝

반면 Agentic/AI 워크로드는 요구사항이 조금 다르게 보입니다.

• 짧고 자주 호출되는 코드 조각

  • 프롬프트 한 번 → 코드 생성 → 실행 → 결과 확인
  • 이런 루프가 수없이 반복됩니다.

• 매우 다양한 I/O 패턴

  • 파일, Git, DB, SaaS API, CLI, MCP 서버 호출까지

    종류가 훨씬 다양합니다.

• 에이전트 중심의 관측·로깅

  • “이 코드가 얼마나 빨랐나”보다

    “이 에이전트가 어떤 결정·행동 경로를 밟았나”를 추적해야 합니다.

이런 환경에서 AI 네이티브 런타임이라면 적어도 다음을 고민해야 합니다.

• cold start와 짧은 수명의 작업에 대한 최적화

  • 함수/스크립트 단위 실행이 아주 빈번하게 일어납니다.(Strapi)

• 비동기 I/O와 이벤트 루프의 효율

  • 여러 외부 시스템과의 통신을 병렬적으로 처리해야 합니다.(LinkedIn)

• 테스트·검증 루프의 비용

  • 에이전트가 제안한 코드를 테스트·롤백·재시도하는 비용을

    최소화하는 방향의 튜닝이 요구됩니다.(Medium)

• 관측성과 보안

  • 어떤 코드가 어떤 맥락에서 실행되었는지,

    어떤 리소스에 접근했는지 추적 가능한 구조가 중요해집니다.

이런 요구사항을 염두에 두고 Bun의 설계를 보면,

“AI 네이티브 런타임”이라는 표현이 단순 수사가 아니라

실제 설계 방향과 맞물린다는 점을 확인할 수 있습니다.(Jimmy Song)

2) IDE/에이전트 서비스의 성능·비용 구조에 미치는 영향

Claude Code, GitHub Copilot 류의 코딩 어시스턴트와

각종 에이전트 서비스의 내부를 떠올리면, 다음과 같은 경로가 있습니다.

• 모델이 코드를 생성하거나 수정합니다.

• 런타임이 그 코드를 실행합니다.

• 테스트·툴 호출·파일 조작 등이 연속적으로 일어납니다.

• 결과가 다시 모델에게 피드백으로 들어갑니다.

이 경로에서 런타임 선택은 직접적으로 다음에 영향을 줍니다.

• 지연 시간

  • 코드 실행 및 검증 루프가 짧아질수록

    사용자는 “실시간에 가깝게” 에이전트와 상호작용하는 경험을 합니다.

• 비용·리소스 사용량

  • 동일한 작업을 처리하는 데 필요한 CPU·메모리·인프라 비용이

    런타임에 따라 큰 차이를 보일 수 있습니다.(Strapi)

• 제품 설계의 자유도

  • 성능과 비용 여유가 생기면

    더 잦은 재시도, 더 풍부한 검증, 더 세밀한 에이전트 플로우를 설계할 수 있습니다.

따라서 Bun 인수는 단순히 “라이브러리를 바꿨다”가 아니라,

“에이전트·코딩 제품의 내부 실행 경로를

AI 워크로드에 맞게 아래에서부터 다시 짜겠다는 선택”

으로 해석할 수 있습니다.

---

4장은 이렇게 정리할 수 있습니다.

• Bun은 JS/TS 생태계에서

  고성능 올인원 런타임으로 자리 잡고 있는 도구입니다.

• Anthropic은 이 런타임을 인수함으로써

  Claude Code와 에이전트 제품의 실행 기반을 직접 소유·최적화하는 길을 택했습니다.

• 이 흐름은 “AI 네이티브 런타임”이라는 개념을 전면으로 끌어올리며,

  IDE/에이전트 서비스의 성능·비용·설계 방식에 구조적인 변화를 예고합니다.

다음 5장에서는 실행 인프라 위에서 돌아가는 애플리케이션 레이어,

특히 Claude Code를 사례로 삼아

“Agentic 코딩 환경이 실제로 어떻게 작동하는지”를 이어서 살펴보겠습니다.

5장. 애플리케이션 레이어: Claude Code와 에이전틱 코딩

5. 애플리케이션 레이어: Claude Code와 에이전틱 코딩

지금까지는 프로토콜, 런타임, 인프라 같은 “보이지 않는 층”을 살펴봤습니다.

5장은 그 위에서 실제로 돌아가는 애플리케이션 레이어, 그중에서도 상징적인 사례인 Claude Code를 중심으로 정리합니다.

Claude Code는 겉으로 보면 “코딩 어시스턴트”입니다.

하지만 내부에서 일어나는 일을 뜯어보면, 이미 상당히 Agentic한 개발 환경에 가까운 모습을 보입니다.

그리고 이 제품이 출시 6개월 만에 **연간 매출 런레이트 10억 달러(1B ARR)**를 넘겼다는 사실은,

이 방향성이 단순 기술 데모가 아니라 강한 비즈니스 시그널이라는 점을 보여줍니다. (Anthropic)

---

5.1 Claude Code의 특징

Claude Code를 “에이전틱 코딩 환경”이라는 관점에서 보면, 세 가지 축이 두드러집니다.

• 리포지토리 전체 문맥 이해

  Claude Code는 개별 파일 단위가 아니라,

  리포지토리 전체 구조와 히스토리를 맥락으로 사용하려는 방향으로 설계되어 있습니다.

  단일 파일의 코드 조각을 수정하는 수준을 넘어,

  • 어느 모듈이 어디에 쓰이는지

  • 어떤 테스트가 어떤 기능을 검증하는지

  • 어떤 구성 파일이 빌드·배포에 연결되는지

    같은 정보를 함께 바라보면서 제안을 합니다. (위키백과)

• 파일 편집 + 테스트·빌드 오케스트레이션

  전통적인 코드 어시스트가 “코드 한 덩어리를 제안하는 도우미”였다면,

  Claude Code는 점점 **“작업 플로우를 관리하는 실행자”**에 가까워지고 있습니다.

  • 코드 변경 제안

  • 관련 테스트 실행 제안

  • 빌드/실행 명령 오케스트레이션

  • 에러가 났을 때 원인 분석 및 수정 제안

    이런 것들이 하나의 대화 맥락 안에서 연결됩니다. (Anthropic)

• 비즈니스적 시그널 – 6개월 만의 10억 달러 런레이트

  Anthropic 공식 발표와 여러 보도에 따르면,

  Claude Code는 출시 약 6개월 만에 **연 10억 달러 수준의 런레이트(Annualized Run Rate)**를 달성했습니다. (Anthropic)

  이 수치는 단순히 “코더들이 좋아한다”는 차원을 넘어서,

  • 기업들이 실제 개발 워크플로의 핵심에

    이런 에이전틱 코딩 도구를 빠르게 끌어들이고 있다는 신호로 해석할 수 있습니다.

  • Netflix, Spotify, Salesforce 등 대형 기업들이 이미 주요 개발 도구로 채택했다는 보도도 같은 방향을 뒷받침합니다. (news.aibase.com)

요약하면, Claude Code는

“프롬프트 → 코드 한 번 생성” 도구가 아니라,

“리포지토리 단위의 개발 작업을 함께 수행하는 에이전트”

쪽에 점점 더 가까워지고 있습니다.

---

5.2 Dev 워크플로에서 나타나는 Agentic 패턴

이제 시선을 “제품 설명”에서 “패턴”으로 옮겨 보겠습니다.

에이전틱 코딩 환경이 실제 Dev 워크플로에 들어갔을 때 어떤 패턴이 나타나는지입니다.

1) 반복 작업의 자동화: 리팩토링, 테스트 코드, 로그 분석

실제 현장에서 가장 먼저 넘어가는 일들은 대체로 다음과 같습니다.

• 리팩토링

  • 네이밍 통일, 인터페이스 정리, 공통 코드 추출, 레거시 API 교체 등
  • 사람 입장에서는 지루하고, 실수하기 쉽지만, 룰이 비교적 명확한 작업입니다.

• 테스트 코드 생성·보완

  • 기존 코드에 대한 유닛 테스트 뼈대 생성
  • 회귀 버그를 재현하는 테스트 케이스 자동 제안

• 로그·트레이스 분석

  • 에러 로그, 스택 트레이스, 메트릭을 모아서

    “어디서부터 봐야 하는지”를 제안하는 역할

이 영역은 “정답이 하나로 고정되어 있지 않아도 되고,

사람이 마지막에 검수만 하면 되는” 성격이라 Agentic 패턴과 잘 맞습니다.

2) 멀티툴 환경과의 결합

현대 Dev 워크플로는 이미 멀티툴 환경입니다.

• Git / GitHub / GitLab

• CI/CD 시스템 (GitHub Actions, Jenkins, GitLab CI, CircleCI 등)

• 이슈 트래커 (Jira, Linear, YouTrack 등)

• 컨테이너 빌드/배포 시스템, Helm, K8s, 내부 배포 파이프라인

에이전틱 코딩 환경이 성숙해질수록,

이 도구들을 “사람이 직접 옮겨 다니며 조작하는” 것이 아니라

에이전트가 “Git diff → 테스트 → 빌드 → 배포 전 검증까지”

하나의 플로우로 묶어 주고,

사람은 승인·조정에 집중하는 구조

로 움직입니다.

여기서 앞 장에서 다룬 MCP, Bun 같은 요소들이 자연스럽게 의미를 갖습니다.

• MCP는 Git, CI/CD, 이슈 트래커, 빌드 시스템 등을

  에이전트 입장에서 호출 가능한 표준화된 리소스/툴셋으로 노출하는 역할을 합니다. (Anthropic)

• Bun과 같은 런타임은 에이전트가 이들 도구와 상호작용하는

  짧고 잦은 실행을 빠르게 처리하는 실행 기반이 됩니다. (LinkedIn)

3) “개발자 1명 + 에이전트 1~N” 협업 모드

에이전틱 코딩 환경에서 자연스럽게 등장하는 그림은

“개발자 1명 + 에이전트 여러 개가 한 팀처럼 움직이는 구조”입니다.

단일 거대한 에이전트가 모든 걸 다 하기보다는,

역할을 나눈 여러 에이전트가 서로 다른 부분을 맡는 패턴이 점점 선호됩니다.

예를 들어,

• 플래닝 단계

  • 이슈나 요구사항을 입력하면

    변경이 필요한 모듈, 예상 영향 범위, 대략적인 변경 계획을

    “작업 단위”로 쪼개 줍니다.

• 실행 단계

  • 코드 수정 에이전트가 실제 패치를 제안하고
  • 테스트/빌드 에이전트가 관련 테스트 실행, 빌드 상태 체크를 담당합니다.

• 검증 단계

  • 리뷰 에이전트가 코드 스타일, 설계, 보안 관점에서 1차 리뷰를 수행하고
  • 롤백 플랜/실패 시 대응 방안을 함께 제안합니다.

사람은 이 전체 흐름에서

• 최종 의사 결정

• 리스크가 큰 변경에 대한 직감적 판단

• 이해관계자 조율

같이 “기계가 대체하기 어려운 고레벨 역할”에 더 집중하게 됩니다.

---

5.3 연구 포인트: 에이전틱 코딩 환경이 바꾸는 것들

마지막으로, “에이전틱 코딩 환경”이 무엇을 어떻게 바꾸는지에 대해

연구·분석 관점에서 잡아볼 만한 포인트를 정리합니다.

1) 생산성·품질·온보딩 속도

정량적으로 측정하고 싶은 지점은 크게 세 가지입니다.

• 생산성

  • 기능 단위 개발 리드타임 변화
  • 이슈당 처리 시간, PR당 코드 라인 수, 리뷰 회차 수
  • 반복적인 작업에 쓰이던 시간을 에이전트가 얼마나 줄여주는지

• 품질

  • 배포 후 발견되는 버그 수
  • 롤백 빈도
  • 테스트 커버리지 변화
  • 보안 취약점·정적 분석 이슈의 사전 발견 비율

• 온보딩 속도

  • 신규 팀원이 리포지토리 구조를 이해하고,

    실제 생산적인 커밋을 올리기까지 걸리는 시간

  • 에이전트가 “해설자 + 가이드” 역할을 할 때

    이 기간이 얼마나 단축되는지

Claude Code가 대규모로 채택되는 과정에서,

이런 지표들을 체계적으로 수집·비교하는 연구는

“에이전틱 코딩이 hype를 넘어서 실제로 무엇을 바꾸는가”를 보여 줄 수 있는 핵심 자료가 됩니다. (news.aibase.com)

2) 팀 구조·역할 재편

에이전틱 코딩은 사람의 역할에도 변화를 만듭니다.

• 시니어 vs 주니어 개발자

  • 주니어는 에이전트를 통해

    코딩·테스트·디버깅의 “기본기”를 더 빠르게 몸에 익힐 수 있습니다.

  • 시니어는

    • 설계·아키텍처

    • 품질 기준 설정

    • 에이전트 워크플로 설계

      쪽으로 역할이 이동하는 경향이 생깁니다.

• Dev / QA / Ops 경계

  • 테스트 작성·실행, 배포 전 검증, 로그/알람 1차 triage를

    에이전트가 상당 부분 담당하게 되면,

    Dev–QA–Ops 간의 구분은 “역할”보다는 “책임 범위·정책” 중심으로 재편될 가능성이 높습니다.

• Tech Lead / Staff Engineer 역할

  • 코드 직접 작성보다

    • 에이전트가 잘 동작할 수 있는 코드베이스·프로세스 설계,

    • AgentOps 정책·지표 설계

      같은 메타 레벨의 작업이 중요해집니다.

이 변화는 조직마다 다르게 나타나겠지만,

공통적으로는 “사람이 하는 일의 초점이 위로 이동한다”는 방향성으로 정리할 수 있습니다.

3) Dev 환경에서의 AgentOps

마지막으로, 개발 환경에서의 AgentOps를 생각해볼 수 있습니다.

단순히 “에이전트가 코드를 잘 짜는가?”를 넘어서,

“이 에이전트가 어떻게 행동하고 있는가?”를 운영하는 레이어입니다.

여기서 다뤄야 할 요소는 크게 두 줄기입니다.

• 모니터링 지표

  • 에이전트가 제안한 코드의 머지 비율

  • 에이전트 제안으로 도입된 변경에서 발생한 버그/롤백 비율

  • 에이전트 개입으로 절약된 테스트·빌드·리팩토링 시간 추정치

  • 위험도가 높은 변경(보안, 데이터 손실 가능성 등)에 대한

    에이전트 제안 빈도와 그 결과

• 정책/권한 설계 프레임워크

  • 에이전트가 직접 커밋·머지까지 할 수 있는지,

    아니면 항상 PR 상태에서 사람의 승인이 필요한지

  • 어느 리포지토리·어느 브랜치·어떤 종류의 작업에

    어떤 수준의 권한을 줄지에 대한 정책

  • 로그와 감사 기록을 어떻게 남기고,

    문제가 생겼을 때 어떻게 원인과 책임을 추적할지에 대한 기준

에이전틱 코딩 환경이 널리 퍼질수록,

“코드를 누가 썼는가?”라는 질문은 점점

“어떤 사람–에이전트 조합이 어떤 정책 아래에서 코드를 바꿨는가?”라는 질문으로 바뀝니다.

이 지점을 체계적으로 다루는 것이

Dev 환경에서의 AgentOps 연구·실무의 핵심 축이라고 할 수 있습니다.

---

5장은 이렇게 정리할 수 있습니다.

• Claude Code는 이미 리포지토리 단위로 일하는 에이전틱 코딩 환경에 가깝게 진화하고 있습니다.

• Dev 워크플로에서는 반복 작업 자동화, 멀티툴 결합, “개발자 + 에이전트” 협업 모드라는 새로운 패턴이 나타납니다.

• 이 변화는 생산성·품질·온보딩·팀 구조·AgentOps에 걸쳐

  여러 가지 연구·실무 과제를 동시에 던져 줍니다.

다음 6장에서는 애플리케이션 레이어를 Dev 도메인을 넘어 확장해서,

실제 사람들이 다양한 업무에서 에이전트를 어떻게 쓰고 있는지,

어떤 사용 패턴과 저항·마찰이 나타나는지로 시야를 넓혀보겠습니다.

6장. 사용자·조직 레벨: How People Use AI Agents

6. 사용자·조직 레벨: How People Use AI Agents

여기까지는 스택과 제품 중심의 이야기를 했습니다.

이제 시선을 완전히 바꿔서, **“사람과 조직이 실제로 에이전트를 어떻게 쓰고 있는가”**를 보려고 합니다.

같은 기술이라도,

어떤 사람 손에 들어가느냐, 어떤 조직 구조 안에 들어가느냐에 따라 완전히 다른 결과를 만듭니다.

6장은 그래서 기술보다 “사용 패턴”과 “심리·조직 구조”에 초점을 두는 장입니다.

---

6.1 실제 사용 패턴 관찰

먼저, 개별 사용자와 팀/조직 수준에서 나타나는 “전형적인 에이전트 사용 패턴”을 나누어 볼 수 있습니다.

1) 개인 단위: 작업 단위의 작은 에이전트들

개인 사용자 수준에서는 에이전트가 보통 “작고 분명한 목적”을 가진 도구로 등장합니다.

• 리서치 에이전트

  • 여러 자료를 모아 정리하고, 차이점과 공통점을 뽑아주며,

    최종적으로 의사결정용 요약본을 만들어 주는 역할을 합니다.

• 요약·문서 작성 에이전트

  • 회의록, 기사, 리포트를 받아서 요약하고

    보고서·슬라이드·메일 초안 같은 형태로 재구성하는 데 자주 쓰입니다.

• 일정·작업 관리 에이전트

  • 캘린더, 할 일 관리, 메신저를 묶어서

    “오늘/이번 주에 실제로 뭘 해야 하는지”를 정리해 주는 패턴이 늘어납니다.

• 개인 자동화 스크립트형 에이전트

  • 파일 정리, 템플릿 문서 생성, 간단한 데이터 정리처럼

    원래는 스크립트나 매크로로 만들던 것들을 에이전트에게 넘기는 식입니다.

개인 레벨에서는 “전략을 맡기는 것”보다는

**“반복적이고 맥락은 있지만 규칙이 비교적 명확한 일”**이 먼저 에이전트에게 넘어가는 경향이 강합니다.

2) 팀·조직 단위: 여러 시스템을 이어붙인 에이전트형 워크플로

조직 단위에서는 에이전트가 **“특정 도메인 워크플로 전체를 흐르는 존재”**로 나타납니다.

• 데이터 파이프라인

  • 여러 소스에서 데이터를 수집·정제·요약하고,

    대시보드나 리포트용 데이터 뷰를 만드는 역할을 합니다.

  • 예를 들어, 로그·제품 이벤트·CRM 데이터를 모아

    “이번 주 사용자 행동 변화 요약” 같은 산출물을 주기적으로 생성합니다.

• 운영 모니터링

  • 알람·로그·메트릭을 모아서

    “어떤 문제가 진짜 중요한지, 어디부터 봐야 하는지”를 정리해 줍니다.

  • 사람이 일일이 모니터링 화면을 돌면서 확인하던 일을

    에이전트가 1차 필터링·요약하는 구조로 바뀝니다.

• 고객지원

  • 티켓·챗 기록·헬프센터 문서를 기반으로

    1차 답변, 라우팅, 우선순위 추천을 수행합니다.

  • 사람이 처리해야 할 티켓과 에이전트가 끝까지 처리해도 되는 티켓을 구분하는 패턴이 생깁니다.

• 보안 분석

  • 경보·로그·위협 인텔리전스 피드를 모아서

    “실제로 조사해야 할 인시던트 후보”를 추려주거나,

    조사 과정에서 필요한 증거·맥락을 정리해 주는 데 사용됩니다.

이때 특징적인 것은,

조직 수준의 에이전트는 거의 항상 **여러 SaaS와 내부 시스템을 동시에 건드리는 “에이전트형 워크플로”**라는 점입니다.

• 에이전트는 한 시스템에서 데이터를 읽고,

  다른 시스템에 티켓을 만들거나,

  어디에선 알람을 남기거나,

  또 다른 곳에 요약 리포트를 저장하는 식으로 동작합니다.

• 사람은 이 워크플로의 “설계자이자 최종 승인자” 역할을 맡습니다.

결국 개인 단위에서는 “도구처럼 쓰는 에이전트”가 먼저 나타나고,

팀·조직 단위에서는 “워크플로를 흐르는 에이전트”가 서서히 자리 잡는 패턴이 보입니다.

---

6.2 마찰 지점과 설계 원칙

에이전트 도입은 항상 마찰을 동반합니다.

흥미로운 점은, 이 마찰이 대부분 기술이 아니라 사람의 인지·문화·업무 습관에서 나온다는 점입니다.

대표적인 세 가지 지점을 정리해 볼 수 있습니다.

1) 신뢰 문제: 에이전트가 내린 결정을 어떻게 믿을 것인가

가장 많이 나오는 질문입니다.

“이 에이전트가 이렇게 하라고 하는데,

이걸 어느 정도까지 믿어도 될까?”

마찰은 주로 다음 상황에서 생깁니다.

• 에이전트가 복잡한 의사결정을 대신 내릴 때

• 결과가 눈에 바로 드러나지 않을 때

• 실수했을 때 비용이 크게 보이는 영역일 때

이때 필요한 설계 원칙은 다음과 같은 방향으로 정리할 수 있습니다.

• 에이전트가 무엇을 근거로 그런 행동·결정을 했는지

  사람이 이해할 수 있게 설명해 주어야 합니다.

• “에이전트가 대신 결정하는 범위”와

  “무조건 사람 승인을 거치는 범위”를

  정책 차원에서 분명하게 나누어야 합니다.

• 롤백·취소·재시도의 경로를 항상 열어 두어

  “틀리더라도 회복 가능하다”는 느낌을 주는 것이 중요합니다.

즉, 신뢰는 정확도만으로 만들어지지 않습니다.

**“설명 가능성 + 정책 + 회복 가능성”**이 함께 설계되어야 합니다.

2) 인터페이스 문제: 채팅, 워크플로 빌더, IDE 인라인

에이전트 인터페이스는 크게 세 가지 축에서 갈립니다.

• 채팅 UI

  • 가장 접근성이 좋고, 많은 도입이 이쪽에서 시작합니다.

  • 하지만 업무가 복잡해질수록

    “대화 기록 속에서 중요한 상태를 찾기 힘들다”는 문제가 나타납니다.

• 워크플로 빌더형 UI

  • 노코드 툴처럼, 에이전트가 밟을 단계들을

    블록·노드·다이어그램 형태로 구성하는 인터페이스입니다.

  • 구조는 명확해지지만

    진입 장벽이 올라가고, 유지보수 책임이 생깁니다.

• IDE·도메인 툴 내 인라인 인터랙션

  • 개발자에게는 IDE, 디자이너에게는 디자인 툴,

    문서 작성자에게는 에디터처럼

    이미 쓰고 있는 도구 안으로 에이전트를 끌어들이는 방식입니다.

  • 맥락이 가장 잘 유지되지만,

    각 도메인 별로 별도의 통합 작업이 필요합니다.

현실에서는 이 세 가지가 혼합되는 경우가 많습니다.

디자인 원칙은 대체로 다음과 같이 정리됩니다.

• “처음에는 채팅”으로 시작합니다.

• 반복적으로 쓰이는 플로우가 안정되면

  워크플로 빌더나 버튼/메뉴 형태로 승격합니다.

• 특정 직군이 하루 종일 쓰는 툴이 있다면

  그 안에 인라인 인터랙션을 심어 넣습니다.

3) 책임 문제: 잘못됐을 때 누가 책임지는가

에이전트가 실제 시스템을 변경하기 시작하면,

책임 문제는 피할 수 없습니다.

• 에이전트가 잘못된 코드를 머지해서 장애가 났을 때

• 잘못된 고객 응대를 자동으로 내보냈을 때

• 보안 인시던트 triage를 잘못해서 대응이 늦어졌을 때

이럴 때 조직 내부에서 나오는 질문은 단순합니다.

“이건 누가 책임지는가?”

이 문제를 다루려면 다음과 같은 원칙이 필요합니다.

• 에이전트의 행동은 항상

  “어떤 사람/역할의 권한 아래에서 일어난 것인지” 연결되어야 합니다.

• 사람의 책임 범위를 줄이는 것이 아니라,

  “어떤 일을 에이전트에게 위임했는지”를

  명시적으로 관리하는 쪽으로 가져가야 합니다.

• 중요한 변경에는

  에이전트가 아닌 사람의 최종 승인을 요구하는 단계가 있어야 합니다.

결국 책임 문제를 풀기 위한 핵심은

에이전트를 “독립된 존재”로 보지 않고,

사람과 팀의 역할 구조 안에 포함시키는 것입니다.

---

6.3 연구 포인트

마지막으로, 사용자·조직 레벨에서

에이전트 도입을 연구·분석할 때 볼 만한 포인트를 정리합니다.

1) 작업 구조 변화: 업무 단위·시간 분배·협업 방식

에이전트 도입 전후를 비교할 때 특히 중요한 축은 다음과 같습니다.

• 업무 단위가 어떻게 바뀌는지

  • 기존에는 “사람이 통째로 하던 일”이

    에이전트에게 넘길 수 있는 단위로 쪼개지는지

  • 에이전트 프렌들리한 작업 단위가 새로 정의되는지

• 시간 분배가 어떻게 변하는지

  • 정보 수집·정리·포맷팅에 쓰이는 시간이 줄어들고
  • 의사결정·조율·리뷰에 쓰이는 시간이 늘어나는지

• 협업 방식이 어떻게 바뀌는지

  • “사람 ↔ 사람” 커뮤니케이션에서

    “사람 ↔ 에이전트 ↔ 사람” 구조로 변하면서

    문서·이슈·로그의 흐름이 어떻게 재편되는지

이 변화는 조직 문화와도 연결되기 때문에,

단순한 생산성 측정 이상의 관찰이 필요합니다.

2) 심리적 요인: 신뢰, 통제감, 피로도

에이전트 도입은 사람의 심리에 직접적인 영향을 줍니다.

• 신뢰

  • 에이전트가 제안한 결과를 어느 정도까지 바로 수용하는지
  • 도메인·업무 유형별로 신뢰 수준이 어떻게 다른지

• 통제감

  • “내가 일을 하고 있다”는 느낌이 줄어드는지,

  • “일이 잘 관리되고 있다”는 느낌이 오히려 커지는지

  • 에이전트가 너무 많은 것을 자동으로 할 때

    불안감이 증가하는 지점은 어디인지

• 피로도

  • 반복 업무 피로가 줄어드는 대신

    검수·승인 피로가 늘어나는지

  • 에이전트와의 상호작용(프롬프트 작성, 결과 검토)이

    인지 피로를 어떻게 바꾸는지

이 부분은 숫자와 설문, 인터뷰를 함께 다루어야 하는 영역입니다.

3) 도메인별 “에이전트가 가장 먼저 먹는 일감”

각 도메인마다 **“가장 먼저 에이전트에게 넘어가는 일”**이 존재합니다.

예를 들어:

• 개발

  • 리팩토링, 테스트 코드, 로그 분석, 마이그레이션 스크립트 등

• 모빌리티/IoT

  • 로그 정리, 상태 요약, 간단한 시뮬레이션·시나리오 체크, 문서 정리 등

• 보안

  • 경보 클러스터링, 알람 우선순위 추천, 초기 triage 리포트 작성 등

• 교육

  • 학습자료 요약, 연습문제 생성, 개별 피드백 초안 작성 등

이 “첫 번째로 먹히는 일감”을 도메인별로 정리하는 것은,

에이전트 도입 전략을 세울 때 매우 실용적인 지도 역할을 합니다.

• 어떤 업무부터 시작해야 성공 가능성이 높은지

• 어떤 영역은 아직 에이전트에게 넘기기 이르며

  더 많은 실험·가이드라인이 필요한지

• 에이전트에게 넘긴 업무가

  이후 어떤 방향으로 확장되는 경향이 있는지

를 입체적으로 볼 수 있기 때문입니다.

---

6장은 요약하면 이렇게 정리할 수 있습니다.

• 개인 수준에서는 “작고 명확한 작업 단위 에이전트”가 먼저 등장합니다.

• 팀·조직 수준에서는 여러 시스템을 묶는 “에이전트형 워크플로”가 천천히 자리를 잡습니다.

• 이 과정에서 신뢰·인터페이스·책임 문제라는 마찰이 발생하고,

  이를 풀기 위한 설계 원칙과 AgentOps 관점의 프레임이 필요합니다.

• 도입 전후의 작업 구조, 심리적 요인, 도메인별 “첫 번째 일감”을 체계적으로 관찰하는 것이

  앞으로의 Agentic AI 연구와 실무 설계에서 중요한 축이 됩니다.

다음 7장에서는 이 사용자·조직 레벨의 관찰을 바탕으로,

거버넌스와 AgentOps, 그리고 향후 과제를 정리하면서

Agentic 풀스택 논의를 마무리해 보겠습니다.

7장. 거버넌스, AgentOps, 그리고 향후 과제

7. 거버넌스, AgentOps, 그리고 향후 과제

여기까지는 Agentic AI를 “만드는 입장”과 “쓰는 입장”에서 각각 살펴봤습니다.

이제 마지막으로 남는 질문은 이것입니다.

“이 모든 에이전트들이 실제 조직 안에서 안정적으로,

책임 있게, 오래 돌아가게 만들려면 무엇을 준비해야 하는가?”

이 질문이 곧 AgentOps와 거버넌스의 영역입니다.

7장은 이 부분을 하나의 프레임으로 묶고, 앞으로 어떤 실험과 연구가 필요할지까지 정리하는 마무리 장입니다.

---

7.1 AgentOps 프레임워크

AgentOps를 어렵게 볼 필요는 없습니다.

기존의 DevOps, MLOps에 “에이전트 특유의 요소”가 하나 더 들어갔다고 보면 됩니다.

실무 관점에서 AgentOps 라이프사이클은 다음 다섯 단계로 정리할 수 있습니다.

• 설계(Design)

• 구축(Build)

• 운영(Deploy & Observe)

• 개선(Improve)

• 거버넌스(Govern)

각 단계를 조금씩 풀어보면 다음과 같습니다.

1) 설계(Design): 목표·역할·툴·권한 설계

에이전트를 바로 만드는 것이 아니라, 먼저 아래를 명확히 하는 단계입니다.

• 이 에이전트는 어떤 목표를 위해 존재하는가

• 사람과 비교했을 때 어떤 역할을 대신하거나 보조하는가

• 어떤 데이터·툴·시스템에 어디까지 접근할 수 있어야 하는가

• 실패했을 때 감당 가능한 위험 한계선은 어디까지인가

여기서 중요한 포인트는 “에이전트를 사람 대신”이 아니라

**“사람 팀 안에 들어오는 하나의 역할”**로 설계하는 관점입니다.

2) 구축(Build): 프롬프트, 정책, 에이전트 그래프 구현·테스트

이 단계는 실제 구현과 실험을 포함합니다.

• 프롬프트와 시스템 메시지, 역할 정의를 설계합니다.

• MCP·API·툴·런타임(Bun 등)과의 연결을 구성합니다.

• 에이전트 간의 흐름(그래프, 워크플로)을 코드로 구현합니다.

• 샌드박스 환경에서 충분히 시뮬레이션하고,

  실패 케이스를 수집합니다.

여기서의 핵심은 “정답 찾기”가 아니라

**“에이전트가 어떤 식으로 실패하는지 패턴을 파악하는 것”**입니다.

3) 운영(Deploy & Observe): 실제 업무 플로우에 연결, 모니터링

에이전트가 실제 업무 플로우에 들어가는 순간부터는 “운영”의 문제입니다.

• 어떤 팀·업무·권한 범위에 먼저 도입할지 결정합니다.

• 에이전트가 하는 행동을 로깅하고,

  사람이 검수하는 과정의 패턴을 관찰합니다.

• 실패 사례, 롤백 사례, “사람이 개입한 순간”들을 기록합니다.

• Dash·Grafana·전용 대시보드 등을 활용해

  “에이전트 관측 지표”를 만듭니다.

이 단계에서 중요한 것은 **가시성(Observability)**입니다.

“지금 이 에이전트가 조직 안에서 무슨 일을 하고 있는지”를

언제든 확인할 수 있어야 합니다.

4) 개선(Improve): 로그·피드백 기반 튜닝

운영 로그와 사용자 피드백을 바탕으로 에이전트를 고쳐 나가는 단계입니다.

• 프롬프트, 정책, 워크플로를

  실제 사용 로그를 기준으로 조정합니다.

• “자주 틀리는 패턴”, “사람이 매번 다시 손대는 구간”을

  우선순위로 두고 개선합니다.

• 필요하다면 에이전트 역할을 쪼개거나,

  반대로 통합하기도 합니다.

핵심은 **“사람의 피드백을 구조화해서 에이전트 학습 루프로 연결하는 것”**입니다.

단순 “좋아요/별점”을 넘어서,

“어떤 상황에서 어떤 이유로 수정했는지”를 남기는 구조가 중요해집니다.

5) 거버넌스(Govern): 컴플라이언스·보안·감사·셧다운/롤백 전략

마지막 레이어는 거버넌스입니다.

여기서 다루는 질문들은 대략 다음과 같습니다.

• 이 에이전트는 어떤 규제·정책(내부·외부)에 영향을 받는가

• 어떤 데이터에 접근할 수 있고, 어떤 데이터에는 절대 접근하면 안 되는가

• 로그·감사 기록은 얼마나 오래, 어떤 형태로 보관해야 하는가

• 문제가 발생했을 때

  • 에이전트를 부분적으로 셧다운하거나
  • 특정 기능만 비활성화하거나
  • 특정 시점으로 롤백하는 전략은 어떻게 되는가

이 단계가 탄탄해야, 에이전트 도입이

“실험적으로 쓰다가 그만두는 장난감”이 아니라

조직의 장기 인프라로 자리 잡을 수 있습니다.

---

7.2 리스크와 규범

Agentic AI는 몇 가지 구조적인 리스크를 안고 있습니다.

이 리스크를 어떻게 다루느냐에 따라

“조직이 에이전트를 얼마나 깊게, 오래 쓰게 될지”가 결정됩니다.

대표적인 리스크를 세 가지로 묶어볼 수 있습니다.

1) 데이터 프라이버시

• 에이전트가 여러 시스템을 동시에 건드릴 수 있기 때문에

  한 번의 설정 실수로도

  민감한 데이터가 엉뚱한 곳으로 흘러갈 수 있습니다.

• 외부 모델/서비스를 사용할 경우

  어떤 데이터가 어떤 경로로 나가는지,

  어떤 계약·보호 장치가 있는지 명확히 해야 합니다.

프라이버시를 지키기 위해서는

“어떤 데이터를 사용하지 않을 것인가”에 대한 제한의 설계가

“어떤 데이터를 사용할 것인가”만큼 중요해집니다.

2) 모델·에이전트의 오판

• LLM 특성상 “그럴듯하지만 틀린 답”을 내놓을 수 있습니다.

• 에이전트는 여기에 한 단계 더해서

  틀린 판단을 기반으로 실제 행동까지 할 수 있습니다.

따라서 다음이 필요합니다.

• 높은 위험 영역(보안, 재무, 법률 등)에서는

  에이전트가 “직접 행동”하는 대신

  “초안·제안·요약” 역할에 머무르게 하는 정책

• 영향 범위가 큰 행동에는

  반드시 사람 승인을 요구하는 두 단계 구조

• 롤백이 가능한 설계(버전 관리, 변경 이력, 스냅샷 등)

3) 자동화에 따른 조직 내 역할 변화

에이전트 도입은 사람의 일을 바꿉니다.

• 일부 반복 작업은 사라지거나 크게 줄어듭니다.

• 대신 설계·검수·조율 같은 역할이 늘어납니다.

이 변화가 “위협”으로만 인식되면

에이전트 도입은 내부 저항에 부딪히기 쉽습니다.

그래서 다음과 같은 규범·커뮤니케이션이 필요합니다.

• 에이전트는 사람을 대체하는 것이 아니라

  **“팀의 작업 구조를 재구성하는 도구”**라는 프레임

• 사람에게 남는 역할과 새로운 성장 방향을

  함께 제시하는 HR·조직 설계

• 에이전트 도입 과정에

  실제 사용자(현장 인력)를 초기에 참여시키는 방식

4) MCP와 Bun이 거버넌스·감사 가능성에 미치는 영향

프로토콜(MCP)과 런타임(Bun)이 오픈 표준·오픈소스로 움직인다는 점은

거버넌스 관점에서 양면성을 가집니다.

긍정적인 면:

• 오픈 프로토콜과 오픈소스 런타임을 사용하면

  내부 감사·보안 팀이

  “에이전트가 어떤 경로로 어떤 시스템에 접근하는지”를

  더 투명하게 이해하고 검사할 수 있습니다.

• 특정 벤더 전용 블랙박스보다는

  코드·문서·커뮤니티를 통해

  리스크를 분석하고 도구를 보강하기가 수월합니다.

부정적·주의해야 할 면:

• 누구나 MCP 서버를 만들고 Bun 기반 코드를 배포할 수 있기 때문에,

  “관리되지 않은 에이전트/서버”가 조직 안에 늘어날 위험도 있습니다.

• 표준화된 프로토콜은 동시에

  “표준화된 공격 표면”이 될 수도 있습니다.

  예를 들어 MCP를 통해 여러 시스템에 접근하는 공격 벡터가 생길 수 있습니다.

그래서 MCP·Bun 같은 오픈 인프라를 쓸수록,

“무엇을 어떻게 쓰게 허용할지”에 대한 정책과 내부 가이드가

더 중요해지는 방향으로 간다고 보는 것이 자연스럽습니다.

---

7.3 향후 연구/실험 방향

마지막으로, 실제로 해 볼 만한 연구·실험 축을 정리합니다.

이 부분은 “어디서부터 PoC·파일럿을 설계할 것인가”와도 직결됩니다.

1) 도메인 특화 Agentic 스택에 대한 케이스 스터디

각 도메인마다 “Agentic 풀스택”을 실제로 어떻게 구성할지

케이스 스터디와 파일럿이 필요합니다.

예를 들어:

• 모빌리티/임베디드 도메인

  • 차량 로그·텔레메트리·OTA·컨테이너 오케스트레이션을

    에이전트가 어떻게 다룰 수 있을지

  • 어떤 작업을 가장 먼저 에이전트에게 넘길 수 있을지

  • 실차·안전 이슈와 어떻게 조화시킬지

• 보안 도메인

  • SIEM·SOAR·위협 인텔리전스와 결합한

    에이전틱 triage·조사·리포팅 플로우

  • 과도한 자동화로 인한 false positive/negative 리스크 관리

• 교육 도메인

  • 교사·학생·콘텐츠 제작자 각각에게

    어떤 에이전트 조합이 의미 있는지

  • 평가·피드백·개별 학습 경로 설계에

    에이전트를 어떻게 끼워 넣을지

이런 케이스 스터디는 “스택 구성표 + 실제 조직 이야기”가 함께 있어야 의미가 있습니다.

2) 에이전트 성능/안전성 평가 벤치마크 설계

현재 많은 벤치마크가 “모델 성능” 중심입니다.

Agentic 환경에서는 다음과 같은 벤치마크가 추가로 필요합니다.

• 멀티스텝 작업을 끝까지 수행하는 완료율

• 도구 호출·API 상호작용 과정에서의 오류율·회복력

• 사람의 개입이 필요한 경우

  언제, 어떤 패턴에서 도움을 요청하는지

• 안전성 관점에서

  정책 위반 시도를 얼마나 잘 감지·회피하는지

이런 지표는 단일 모델이 아니라

“모델 + 에이전트 로직 + 툴 + 정책”을 포함한

전체 시스템 수준에서 평가해야 합니다.

3) 오픈 생태계 속에서 개인·커뮤니티·스타트업의 역할

MCP, Agentic AI Foundation, Bun 등

오픈 표준·오픈소스 기반의 생태계에서는

개인·커뮤니티·스타트업이 할 수 있는 역할이 많습니다.

예를 들면:

• 특정 도메인에 특화된 MCP 서버/커넥터 개발

• AgentOps를 돕는 관측·대시보드·정책 관리 도구 제작

• 교육·커뮤니티 측면에서

  “Agentic 스택을 잘 쓰는 방법”에 대한 베스트 프랙티스 공유

• 도메인 특화 Agentic 템플릿,

  예: “보안 triage 에이전트 번들”, “모빌리티 로그 분석 에이전트 번들” 등

이 생태계는 “한두 개의 거대 플레이어가 모든 것을 제공하는 구조”보다는,

여러 층위에서 다양한 주체가 모듈을 만들어 올리는 구조로 갈 가능성이 높습니다.

---

7장은 결국 이런 메시지로 정리할 수 있습니다.

Agentic AI는 모델·프로토콜·런타임만으로 완성되지 않습니다.

**“어떻게 설계·운영·통제하고, 어떤 역할 구조 안에 넣을 것인가”**까지 포함해야 비로소 전체 그림이 완성됩니다.

앞 장들에서 다룬 기술 스택 위에

이 거버넌스·AgentOps·연구 방향을 함께 올려 놓으면,

Agentic AI를 “하나의 제품”이 아니라

**“장기적으로 운영되는 인프라 + 조직 변화의 프로젝트”**로 바라볼 수 있는 기반이 갖춰진다고 볼 수 있습니다.