에이전트 인프라와 새로운 백엔드

spinny:~/writing $ vim agentic-infrastructure-stack.md

1~
2우리는 에이전트 프레임워크에 대해 자주 이야기했습니다. LangGraph, CrewAI, AutoGen, 다양한 SDK, 루프, 도구 호출, 메모리, 플래너, 비평가, 감독자. 맙소사, 모든 유용한 단어. 하지만 실제로 사용되는 에이전트를 보면 볼수록 흥미로운 부분이 프레임워크 수준 아래로 이동한 것 같습니다.
3~
4문제는 더 이상 단순한 것이 아닙니다. 단계 모델이 생각하도록 하려면 어떤 라이브러리를 사용해야 합니까?
5~
6실제 질문은 이 에이전트가 데모 활동을 중단하면 어디에 거주하는가입니다.
7~
8진지한 에이전트는 모델을 호출하고 텍스트를 반환하는 함수가 아니기 때문입니다. 소규모 분산 시스템입니다. 컨텍스트를 읽고, 도구를 사용하고, 코드를 실행하고, 파일을 터치하고, 결정을 기억하고, 권한을 요청하고, 제대로 실패하고, 다시 시작하고, 로그를 남기고, 예산을 낭비하지 않고, 프로덕션 저장소 내부의 불도저로 변하지 않아야 합니다.
9~
10프레임워크는 스티어링 휠입니다. 인프라는 도로, 브레이크, 차고, 보험, 그리고 열쇠가 어디에 있는지 아는 사람입니다.
11~
12## 지금 얘기가 너무 많아서
13~
142023년과 2024년 대화는 매우 모델 중심이었습니다. 어느 LLM? 맥락은 어느 정도인가? 비용은 얼마입니까? 그는 프로그래밍을 얼마나 잘하나요?
15~
162025년과 2026년에는 대화가 바뀌었습니다. 모델은 실제 작업을 수행하기에 충분하지만 런타임, 보안, 커넥터, ID, 관찰 가능성, 코드 실행, 배포, 롤백과 같은 지루한 부분이 표시되는 이유입니다.
17~
18마술에서 공학으로의 자연스러운 전환입니다.
19~
20상담원이 응답을 생성해야 하는 경우에는 채팅만으로 충분합니다. 끌어오기 요청 열기, 데이터베이스 쿼리, CRM 호출, 작업 시작, 사이트 탐색, Slack 읽기, 코드 컴파일, 문서 업데이트 등의 작업을 수행하려면 운영 체제가 필요합니다.
21~
22문자 그대로의 의미는 아닙니다. 조직적인 의미에서.
23~
24## 첫 번째 부분: 에이전트가 지속될 수 있는 런타임
25~
26상담원은 종종 단계적으로 작업합니다. 상태를 보고, 작업을 선택하고, 도구를 사용하고, 결과를 관찰하고, 계획을 업데이트하고, 반복하세요.
27~
28이 루프가 단일 HTTP 요청 내에 있으면 즉시 문제가 발생합니다. 일부 작업이 느립니다. 일부는 사람의 입력을 기다립니다. 일부는 실패하여 다시 시도해야 합니다. 일부는 배포 또는 시간 초과 후에도 살아남아야 합니다.
29~
30내구성 있는 워크플로, 대기열, 작업 배경 및 상태 머신이 작동하는 곳입니다. 화려하지는 않지만 데모에서 똑똑해 보이는 상담원과 커피를 마시러 가는 동안 퇴근할 수 있는 상담원의 차이입니다.
31~
32나에게 있어서 에이전트 런타임은 매우 구체적인 질문에 대답해야 합니다.
33~
34- 한 단계와 다른 단계 사이의 상태를 어디에 저장합니까?
35- 프로세스가 도중에 종료되면 어떻게 되나요?
36- 잠시 멈추고 승인을 요청할 수 있나요?
37- 그가 왜 그런 선택을 했는지 이해하기 위해 다시 경기를 해볼 수 있나요?
38- 기간, 메모리, 도구 및 비용을 제한할 수 있나요?
39~
40Vercel은 웹 애플리케이션 내에서 에이전트를 구축하기 위한 AI SDK, 기능, 워크플로 및 도구를 통해 이 분야를 열심히 추진하고 있습니다. 그러나 요점은 Vercel에만 있는 것이 아닙니다. 요점은 에이전트에 단일 엔드포인트가 아닌 운영 홈이 필요하다는 것입니다.
41~
42## 두 번째 부분: 샌드박스, 에이전트가 깨지지 않고 더러워질 수 있어야 하기 때문입니다.
43~
44에이전트가 코드를 작성하거나 명령을 실행하자마자 샌드박스가 필요합니다.
45~
46기술적인 단어처럼 보이지만 아이디어는 가정적인 것입니다. 그에게 작업대를 제공하는 것입니다. 파일을 열고, 종속성을 설치하고, 테스트를 실행하고, 실험을 수행하고, 출력을 생성할 수 있습니다. 그가 틀렸다면 당신은 피해를 입은 것입니다. 효과가 있으면 결과를 홍보하세요.
47~
48에이전트 샌드박스에는 다음과 같은 몇 가지 속성이 있어야 합니다.
49~
50- 격리된 파일 시스템
51- CPU, 메모리 및 시간 제한;
52- 통제된 네트워크;
53- 비밀은 필요할 때만 마운트됩니다.
54- 완전한 로그;
55- 유물 수출 가능성;
56- 필요한 경우 실행 사이에 재설정을 수행합니다.
57~
58Vercel Sandbox는 정확히 이 방향으로 나아갑니다. 즉, 기본 애플리케이션 런타임에서 모든 것을 실행하지 않고도 코드를 실행하고, 종속성을 설치하고, 파일로 작업하고 아티팩트를 생성하는 격리된 환경입니다.
59~
60이 일은 생각보다 더 중요합니다. 많은 에이전트 프로토타입이 모델에서 실제 시스템으로 직접 이동합니다. 모델은 도구를 호출할 수 있습니다. 도구는 일을 할 수 있습니다. 첫 번째 잘못된 명령, 잘못된 위치에 설치된 첫 번째 종속성, 로그에 기록되는 첫 번째 토큰까지는 모든 것이 우아해 보입니다.
61~
62샌드박스는 성인이 말하는 방식입니다. 계속하세요. 하지만 여기로 들어가세요.
63~
64## 세 번째 부분: MCP와 커넥터 문제
65~
66모델 컨텍스트 프로토콜(Model Context Protocol)은 빠르게 관리할 수 없게 되는 것, 즉 모델이 외부 도구를 발견하고 사용하는 방법을 표준화하려고 시도하기 때문에 생태계에서 가장 흥미로운 부분 중 하나가 되었습니다.
67~
68표준이 없으면 각 통합은 작은 섬과 같습니다. GitHub용 커넥터는 한 가지 방식으로 수행되고, Slack용 커넥터는 다른 방식으로 수행되며, 다른 의미를 가진 데이터베이스용 커넥터, 아무것도 아닌 것처럼 보이는 브라우저 자동화용 커넥터입니다.
69~
70MCP는 도구, 리소스, 프롬프트, 권한 부여, 전송, 검색 등 클라이언트와 서버 간의 공통 언어를 제안합니다. 거버넌스와 보안을 마술처럼 해결하는 것이 아니라 문법을 제공합니다.
71~
72그리고 문법이 중요합니다. 상담원이 여러 도구에 연결할 수 있으면 단순히 "그가 그것을 할 수 있는가?"라는 질문이 아닙니다. 문제는 "그는 자신이 무엇을 할 수 있는지, 어떤 한계를 가지고, 누구를 대신하여, 어떤 흔적을 남기는지 이해하고 있는가?"이다.
73~
74나에게 MCP는 "도구 호출"을 수행하기 때문에 과장된 것이 아닙니다. 우리는 이미 그렇게 했습니다. 단일 통합에서 도구의 운영 카탈로그로 무게 중심을 이동시키기 때문에 과장된 것입니다.
75~
76좋은 에이전트 아키텍처에서 MCP는 일종의 패치 패널이 됩니다.
77~
78- 코드 및 문제에 대한 GitHub;
79- 대화 맥락을 위한 Slack
80- 계획된 작업을 위한 Linear 또는 Jira
81- 분석을 위한 읽기 전용 데이터베이스
82- 외부 사이트에 대해 제어되는 브라우저 또는 스크레이퍼
83- 문서 저장;
84- 격리된 실행 환경
85- 엄격한 권한으로 내부 시스템이 노출됩니다.
86~
87까다로운 부분은 정책이 없는 도구 카탈로그가 혼란을 야기하는 더 우아한 방법일 뿐이라는 것입니다.
88~
89## 네 번째 부분: ID 및 권한
90~
91이것은 많은 데모가 눈을 돌리는 영역입니다.
92~
93대리인은 누군가를 대신하여 행동합니다. 그러므로 행동의 주체가 누구인지 분명해야 합니다.
94~
95사용자 권한을 사용하고 있습니까? 서비스 계정인가요? 작업 공간? 임시 또는 영구 액세스 권한이 있습니까? 모든 내용을 읽을 수 있습니까, 아니면 일부 자료만 읽을 수 있습니까? 글을 쓸 수 있나요? 취소할 수 있나요? 그는 실제 사람들에게 문자를 보낼 수 있나요?
96~
97이러한 질문에 제대로 대답하지 못하면 조만간 집 열쇠를 누가 주었는지 기억하지 못하는 도우미를 만들게 될 것입니다.
98~
99제가 좋아하는 경험 법칙은 다음과 같습니다. 에이전트는 인간보다 적은 일을 할 수 있어야 하고, 인간보다 더 많은 일을 할 수 없어야 합니다. 그리고 더 위험한 일을 해야 할 때는 멈춰서 물어봐야 합니다.
100~
101이는 OAuth, 토큰 범위, 비밀 관리, 감사 로그, 도구 정책, 허용 목록, 승인 단계를 의미합니다. 그다지 로맨틱한 내용은 아닙니다. 필요한 것.
102~
103## 다섯 번째 부분: 메모리와 컨텍스트, 하지만 쓰레기가 쌓이지 않음
104~
105에이전트에게는 메모리가 필요하지만 메모리가 다락방이 되면 위험합니다.
106~
107메모리에는 최소한 세 가지 유형이 있습니다.
108~
109- 실행 메모리: 이 실행에서 무슨 일이 일어났는지;
110- 프로젝트 메모리: 관례, 결정, 제약;
111- 개인 또는 팀 기억: 선호도, 어조, 의식, 프로세스.
112~
113프롬프트에 모든 것을 넣는 것이 지름길입니다. 더 이상 작동하지 않을 때까지 작동합니다. 유용한 메모리는 색인화, 업데이트, 만료, 확인, 인용 가능하게 처리되어야 합니다.
114~
115나쁘게 기억하는 요원은 기억하지 못하는 요원보다 더 나쁘다. 왜냐하면 그는 자신감 있게 이야기하기 때문이다.
116~
117따라서 인프라에는 검색, 지침 파일, 지식 기반, 필요할 경우 삽입은 물론 정리도 포함되어야 합니다. 우리에게는 기억의 문화가 필요합니다. 무엇이 들어가고, 누가 승인하고, 언제 부패하는지, 어떻게 수정합니까?
118~
119## 여섯 번째 부분: 관찰 가능성, 평가 및 재생
120~
121에이전트가 실수를 한 경우 "모델 호출" 로그만으로는 충분하지 않습니다.
122~
123경로를 보고 싶습니다. 그는 어떤 맥락을 받았습니까? 어떤 도구를 사용할 수 있었나요? 어떤 도구를 선택하셨나요? 어떤 주장으로? 어떤 응답을 받았나요? 비용은 얼마였나요? 어디에서 막혔나요? 인간이 뭔가를 승인했습니까? 오류 모델, 도구, 프롬프트, 데이터 또는 권한 오류입니까?
124~
125여기서 에이전트는 챗봇이라기보다는 분산 시스템에 더 가깝습니다.
126~
127텍스트 로그뿐만 아니라 읽을 수 있는 추적도 필요합니다. 실행을 다시 재생할 수 있어야 합니다. 알려진 작업에 대해 동일한 에이전트의 두 버전을 비교해야 합니다. 회귀를 측정해야 합니다. "더 나은 응답"을 제공할 뿐만 아니라 "원치 않는 파일을 건드리지 않고 올바른 티켓을 닫습니다".
128~
129에이전트 평가는 작업을 포함하기 때문에 텍스트 평가보다 어렵습니다. 예상되는 문자열을 비교하는 것만으로는 충분하지 않습니다. 순서, 부작용, 인공물의 품질, 시간, 비용, 인간 개입 횟수를 살펴봐야 합니다.
130~
131재미있는 점은 우리가 항상 소프트웨어 엔지니어링이라는 곳으로 돌아온다는 것입니다. 테스트, 환경, 추적, 롤백. 이제 코드가 다음에 수행할 작업도 결정한다는 점만 빼면요.
132~
133## 일곱 번째 작품: 휴먼 인터페이스
134~
135상담원은 채팅에만 머물 필요가 없습니다.
136~
137일부 에이전트에는 보드가 필요합니다. 기타 상태 및 로그가 포함된 페이지입니다. 기타 "승인" 버튼. 더 많은 인라인 댓글. CLI의 또 다른 것.
138~
139UI가 동작을 변경합니다. 에이전트를 제어하는 유일한 방법이 긴 메시지를 작성하는 것이라면 사용자는 에이전트에게 모호한 지시를 내릴 것입니다. 그러나 계획, 차이점, 출처, 위험 및 다음 조치를 본다면 정확하게 개입할 수 있습니다.
140~
141적절한 에이전트 인프라에는 제어 표면이 포함됩니다.
142~
143- 현재 상태
144- 편집 가능한 계획;
145- 생산된 인공물;
146- 차이점;
147- 승인 요청
148- 연대기;
149- 정지 버튼;
150- 재시도 버튼;
151- 보이는 권한.
152~
153사소한 것 같지만 그렇지 않습니다. "소름 끼치는 AI"와 "신뢰할 수 있는 보조자"의 차이점은 종종 후자가 자신의 손이 있는 곳을 보여 준다는 것입니다.
154~
155## 정신 스택
156~
157오늘 그려본다면 최소 에이전트 스택은 다음과 같습니다.
158~
1591. 모델: 추론, 생성, 도구 호출, 필요한 경우 다중 모드.
1602. 오케스트레이션: 루프, 단계, 플래너, 정책, 인간 참여(Human-In-The-Loop).
1613. 내구성 있는 런타임: 워크플로, 대기열, 재시도, 일시 중지, 재개.
1624. 샌드박스: 코드 실행, 격리된 파일 시스템, 제한 사항, 아티팩트.
1635. 도구 계층: MCP, 내부 API, 브라우저, 데이터베이스, 저장소.
1646. ID 계층: OAuth, 범위, 비밀, 감사, 정책.
1657. 메모리 계층: 프로젝트 컨텍스트, 검색, 지침, 만료.
1668. 관찰 가능성: 추적, 재생, 평가, 비용 및 품질 지표.
1679. 제품 표면: 충분할 때는 채팅하고, 필요할 때는 대시보드를, 중요할 때는 검토합니다.
168~
169에이전트 프레임워크는 주로 포인트 2와 포인트 1의 일부를 다루고 있습니다. 나머지는 실제 작업입니다.
170~
171## 실제로 무엇을 할 것인가
172~
173팀에서 "프로덕션에 에이전트가 필요합니다"라고 말하면 저는 10명의 에이전트로 시작하지 않을 것입니다.
174~
175저는 작고 반복적이며 관찰 가능한 작업 흐름부터 시작하겠습니다. 예를 들어 유지 관리 PR 공개, 닫힌 문제의 문서 업데이트, 주간 검토 준비, 중복 버그 선별, 영향을 받는 파일에 대한 테스트 생성 등이 있습니다.
176~
177그런 다음 매우 명확한 한계를 설정합니다.
178~
179- 가지나 샌드박스 없이는 글을 쓸 수 없습니다.
180- 프롬프트에 비밀이 없습니다.
181- 허용 목록의 도구
182- 외부 활동에 대한 인간의 승인
183- 필수 로그 및 추적
184- 실행당 예산
185- 출력은 항상 검사 가능합니다.
186~
187그래야만 확장할 수 있습니다.
188~
189모델이 잘못되었다고 해서 에이전트가 실패하는 것은 아닙니다. 우리가 그들을 혼란스러운 허가와 연극적 기대와 함께 모호한 환경에 놓기 때문에 실패합니다.
190~
191## 내가 읽은 책
192~
193Agentic 인프라는 가장 좋은 방법으로 지루합니다.
194~
195데모에서 박수를 치게 만드는 부분은 아닙니다. 실제 사람, 실제 데이터, 실제 결과가 포함된 데모를 월요일 아침에 실제로 사용할 수 있게 해주는 부분입니다.
196~
197에이전트의 미래는 누가 최고의 롤모델을 갖고 있느냐에 따라 결정되지 않습니다. 실험할 때는 고립되고, 필요할 때는 연결되고, 항상 관찰 가능하며, 기준에 따라 승인을 받고, 모를 때는 멈출 수 있을 만큼 겸손한 장소를 만드는 사람이 이를 결정할 것입니다.
198~
199에이전트가 장난감이 아닌 인프라가 되는 곳이 바로 여기입니다.
200~
201## 소스
202~
203- [Vercel: Vercel과 AI SDK를 사용하여 AI 에이전트를 구축하는 방법](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)
204- [Vercel Docs: 샌드박스](https://vercel.com/docs/sandbox)
205- [Vercel Docs: 샌드박스 작업](https://vercel.com/docs/sandbox/working-with-sandbox)
206- [Vercel Docs: MCP](https://vercel.com/docs/mcp)
207- [모델 컨텍스트 프로토콜: 사양](https://modelcontextprotocol.io/specation)
208- [OpenAI: 에이전트 구축을 위한 새로운 도구](https://openai.com/index/new-tools-for-building-agents/)
209- [Cloudflare 블로그: Cloudflare의 에이전트](https://blog.cloudflare.com/agents-on-cloudflare/)
210~

NORMAL · agentic-infrastructure-stack.md [readonly]210 lines · :q to close

2우리는 에이전트 프레임워크에 대해 자주 이야기했습니다. LangGraph, CrewAI, AutoGen, 다양한 SDK, 루프, 도구 호출, 메모리, 플래너, 비평가, 감독자. 맙소사, 모든 유용한 단어. 하지만 실제로 사용되는 에이전트를 보면 볼수록 흥미로운 부분이 프레임워크 수준 아래로 이동한 것 같습니다.

4문제는 더 이상 단순한 것이 아닙니다. 단계 모델이 생각하도록 하려면 어떤 라이브러리를 사용해야 합니까?

6실제 질문은 이 에이전트가 데모 활동을 중단하면 어디에 거주하는가입니다.

8진지한 에이전트는 모델을 호출하고 텍스트를 반환하는 함수가 아니기 때문입니다. 소규모 분산 시스템입니다. 컨텍스트를 읽고, 도구를 사용하고, 코드를 실행하고, 파일을 터치하고, 결정을 기억하고, 권한을 요청하고, 제대로 실패하고, 다시 시작하고, 로그를 남기고, 예산을 낭비하지 않고, 프로덕션 저장소 내부의 불도저로 변하지 않아야 합니다.

10프레임워크는 스티어링 휠입니다. 인프라는 도로, 브레이크, 차고, 보험, 그리고 열쇠가 어디에 있는지 아는 사람입니다.

11~

12## 지금 얘기가 너무 많아서

13~

142023년과 2024년 대화는 매우 모델 중심이었습니다. 어느 LLM? 맥락은 어느 정도인가? 비용은 얼마입니까? 그는 프로그래밍을 얼마나 잘하나요?

15~

162025년과 2026년에는 대화가 바뀌었습니다. 모델은 실제 작업을 수행하기에 충분하지만 런타임, 보안, 커넥터, ID, 관찰 가능성, 코드 실행, 배포, 롤백과 같은 지루한 부분이 표시되는 이유입니다.

17~

18마술에서 공학으로의 자연스러운 전환입니다.

19~

20상담원이 응답을 생성해야 하는 경우에는 채팅만으로 충분합니다. 끌어오기 요청 열기, 데이터베이스 쿼리, CRM 호출, 작업 시작, 사이트 탐색, Slack 읽기, 코드 컴파일, 문서 업데이트 등의 작업을 수행하려면 운영 체제가 필요합니다.

21~

22문자 그대로의 의미는 아닙니다. 조직적인 의미에서.

23~

24## 첫 번째 부분: 에이전트가 지속될 수 있는 런타임

25~

26상담원은 종종 단계적으로 작업합니다. 상태를 보고, 작업을 선택하고, 도구를 사용하고, 결과를 관찰하고, 계획을 업데이트하고, 반복하세요.

27~

28이 루프가 단일 HTTP 요청 내에 있으면 즉시 문제가 발생합니다. 일부 작업이 느립니다. 일부는 사람의 입력을 기다립니다. 일부는 실패하여 다시 시도해야 합니다. 일부는 배포 또는 시간 초과 후에도 살아남아야 합니다.

29~

30내구성 있는 워크플로, 대기열, 작업 배경 및 상태 머신이 작동하는 곳입니다. 화려하지는 않지만 데모에서 똑똑해 보이는 상담원과 커피를 마시러 가는 동안 퇴근할 수 있는 상담원의 차이입니다.

31~

32나에게 있어서 에이전트 런타임은 매우 구체적인 질문에 대답해야 합니다.

33~

34- 한 단계와 다른 단계 사이의 상태를 어디에 저장합니까?

35- 프로세스가 도중에 종료되면 어떻게 되나요?

36- 잠시 멈추고 승인을 요청할 수 있나요?

37- 그가 왜 그런 선택을 했는지 이해하기 위해 다시 경기를 해볼 수 있나요?

38- 기간, 메모리, 도구 및 비용을 제한할 수 있나요?

39~

40Vercel은 웹 애플리케이션 내에서 에이전트를 구축하기 위한 AI SDK, 기능, 워크플로 및 도구를 통해 이 분야를 열심히 추진하고 있습니다. 그러나 요점은 Vercel에만 있는 것이 아닙니다. 요점은 에이전트에 단일 엔드포인트가 아닌 운영 홈이 필요하다는 것입니다.

41~

42## 두 번째 부분: 샌드박스, 에이전트가 깨지지 않고 더러워질 수 있어야 하기 때문입니다.

43~

44에이전트가 코드를 작성하거나 명령을 실행하자마자 샌드박스가 필요합니다.

45~

46기술적인 단어처럼 보이지만 아이디어는 가정적인 것입니다. 그에게 작업대를 제공하는 것입니다. 파일을 열고, 종속성을 설치하고, 테스트를 실행하고, 실험을 수행하고, 출력을 생성할 수 있습니다. 그가 틀렸다면 당신은 피해를 입은 것입니다. 효과가 있으면 결과를 홍보하세요.

47~

48에이전트 샌드박스에는 다음과 같은 몇 가지 속성이 있어야 합니다.

49~

50- 격리된 파일 시스템

51- CPU, 메모리 및 시간 제한;

52- 통제된 네트워크;

53- 비밀은 필요할 때만 마운트됩니다.

54- 완전한 로그;

55- 유물 수출 가능성;

56- 필요한 경우 실행 사이에 재설정을 수행합니다.

57~

58Vercel Sandbox는 정확히 이 방향으로 나아갑니다. 즉, 기본 애플리케이션 런타임에서 모든 것을 실행하지 않고도 코드를 실행하고, 종속성을 설치하고, 파일로 작업하고 아티팩트를 생성하는 격리된 환경입니다.

59~

60이 일은 생각보다 더 중요합니다. 많은 에이전트 프로토타입이 모델에서 실제 시스템으로 직접 이동합니다. 모델은 도구를 호출할 수 있습니다. 도구는 일을 할 수 있습니다. 첫 번째 잘못된 명령, 잘못된 위치에 설치된 첫 번째 종속성, 로그에 기록되는 첫 번째 토큰까지는 모든 것이 우아해 보입니다.

61~

62샌드박스는 성인이 말하는 방식입니다. 계속하세요. 하지만 여기로 들어가세요.

63~

64## 세 번째 부분: MCP와 커넥터 문제

65~

66모델 컨텍스트 프로토콜(Model Context Protocol)은 빠르게 관리할 수 없게 되는 것, 즉 모델이 외부 도구를 발견하고 사용하는 방법을 표준화하려고 시도하기 때문에 생태계에서 가장 흥미로운 부분 중 하나가 되었습니다.

67~

68표준이 없으면 각 통합은 작은 섬과 같습니다. GitHub용 커넥터는 한 가지 방식으로 수행되고, Slack용 커넥터는 다른 방식으로 수행되며, 다른 의미를 가진 데이터베이스용 커넥터, 아무것도 아닌 것처럼 보이는 브라우저 자동화용 커넥터입니다.

69~

70MCP는 도구, 리소스, 프롬프트, 권한 부여, 전송, 검색 등 클라이언트와 서버 간의 공통 언어를 제안합니다. 거버넌스와 보안을 마술처럼 해결하는 것이 아니라 문법을 제공합니다.

71~

72그리고 문법이 중요합니다. 상담원이 여러 도구에 연결할 수 있으면 단순히 "그가 그것을 할 수 있는가?"라는 질문이 아닙니다. 문제는 "그는 자신이 무엇을 할 수 있는지, 어떤 한계를 가지고, 누구를 대신하여, 어떤 흔적을 남기는지 이해하고 있는가?"이다.

73~

74나에게 MCP는 "도구 호출"을 수행하기 때문에 과장된 것이 아닙니다. 우리는 이미 그렇게 했습니다. 단일 통합에서 도구의 운영 카탈로그로 무게 중심을 이동시키기 때문에 과장된 것입니다.

75~

76좋은 에이전트 아키텍처에서 MCP는 일종의 패치 패널이 됩니다.

77~

78- 코드 및 문제에 대한 GitHub;

79- 대화 맥락을 위한 Slack

80- 계획된 작업을 위한 Linear 또는 Jira

81- 분석을 위한 읽기 전용 데이터베이스

82- 외부 사이트에 대해 제어되는 브라우저 또는 스크레이퍼

83- 문서 저장;

84- 격리된 실행 환경

85- 엄격한 권한으로 내부 시스템이 노출됩니다.

86~

87까다로운 부분은 정책이 없는 도구 카탈로그가 혼란을 야기하는 더 우아한 방법일 뿐이라는 것입니다.

88~

89## 네 번째 부분: ID 및 권한

90~

91이것은 많은 데모가 눈을 돌리는 영역입니다.

92~

93대리인은 누군가를 대신하여 행동합니다. 그러므로 행동의 주체가 누구인지 분명해야 합니다.

94~

95사용자 권한을 사용하고 있습니까? 서비스 계정인가요? 작업 공간? 임시 또는 영구 액세스 권한이 있습니까? 모든 내용을 읽을 수 있습니까, 아니면 일부 자료만 읽을 수 있습니까? 글을 쓸 수 있나요? 취소할 수 있나요? 그는 실제 사람들에게 문자를 보낼 수 있나요?

96~

97이러한 질문에 제대로 대답하지 못하면 조만간 집 열쇠를 누가 주었는지 기억하지 못하는 도우미를 만들게 될 것입니다.

98~

99제가 좋아하는 경험 법칙은 다음과 같습니다. 에이전트는 인간보다 적은 일을 할 수 있어야 하고, 인간보다 더 많은 일을 할 수 없어야 합니다. 그리고 더 위험한 일을 해야 할 때는 멈춰서 물어봐야 합니다.

100~

101이는 OAuth, 토큰 범위, 비밀 관리, 감사 로그, 도구 정책, 허용 목록, 승인 단계를 의미합니다. 그다지 로맨틱한 내용은 아닙니다. 필요한 것.

102~

103## 다섯 번째 부분: 메모리와 컨텍스트, 하지만 쓰레기가 쌓이지 않음

104~

105에이전트에게는 메모리가 필요하지만 메모리가 다락방이 되면 위험합니다.

106~

107메모리에는 최소한 세 가지 유형이 있습니다.

108~

109- 실행 메모리: 이 실행에서 무슨 일이 일어났는지;

110- 프로젝트 메모리: 관례, 결정, 제약;

111- 개인 또는 팀 기억: 선호도, 어조, 의식, 프로세스.

112~

113프롬프트에 모든 것을 넣는 것이 지름길입니다. 더 이상 작동하지 않을 때까지 작동합니다. 유용한 메모리는 색인화, 업데이트, 만료, 확인, 인용 가능하게 처리되어야 합니다.

114~

115나쁘게 기억하는 요원은 기억하지 못하는 요원보다 더 나쁘다. 왜냐하면 그는 자신감 있게 이야기하기 때문이다.

116~

117따라서 인프라에는 검색, 지침 파일, 지식 기반, 필요할 경우 삽입은 물론 정리도 포함되어야 합니다. 우리에게는 기억의 문화가 필요합니다. 무엇이 들어가고, 누가 승인하고, 언제 부패하는지, 어떻게 수정합니까?

118~

119## 여섯 번째 부분: 관찰 가능성, 평가 및 재생

120~

121에이전트가 실수를 한 경우 "모델 호출" 로그만으로는 충분하지 않습니다.

122~

123경로를 보고 싶습니다. 그는 어떤 맥락을 받았습니까? 어떤 도구를 사용할 수 있었나요? 어떤 도구를 선택하셨나요? 어떤 주장으로? 어떤 응답을 받았나요? 비용은 얼마였나요? 어디에서 막혔나요? 인간이 뭔가를 승인했습니까? 오류 모델, 도구, 프롬프트, 데이터 또는 권한 오류입니까?

124~

125여기서 에이전트는 챗봇이라기보다는 분산 시스템에 더 가깝습니다.

126~

127텍스트 로그뿐만 아니라 읽을 수 있는 추적도 필요합니다. 실행을 다시 재생할 수 있어야 합니다. 알려진 작업에 대해 동일한 에이전트의 두 버전을 비교해야 합니다. 회귀를 측정해야 합니다. "더 나은 응답"을 제공할 뿐만 아니라 "원치 않는 파일을 건드리지 않고 올바른 티켓을 닫습니다".

128~

129에이전트 평가는 작업을 포함하기 때문에 텍스트 평가보다 어렵습니다. 예상되는 문자열을 비교하는 것만으로는 충분하지 않습니다. 순서, 부작용, 인공물의 품질, 시간, 비용, 인간 개입 횟수를 살펴봐야 합니다.

130~

131재미있는 점은 우리가 항상 소프트웨어 엔지니어링이라는 곳으로 돌아온다는 것입니다. 테스트, 환경, 추적, 롤백. 이제 코드가 다음에 수행할 작업도 결정한다는 점만 빼면요.

132~

133## 일곱 번째 작품: 휴먼 인터페이스

134~

135상담원은 채팅에만 머물 필요가 없습니다.

136~

137일부 에이전트에는 보드가 필요합니다. 기타 상태 및 로그가 포함된 페이지입니다. 기타 "승인" 버튼. 더 많은 인라인 댓글. CLI의 또 다른 것.

138~

139UI가 동작을 변경합니다. 에이전트를 제어하는 유일한 방법이 긴 메시지를 작성하는 것이라면 사용자는 에이전트에게 모호한 지시를 내릴 것입니다. 그러나 계획, 차이점, 출처, 위험 및 다음 조치를 본다면 정확하게 개입할 수 있습니다.

140~

141적절한 에이전트 인프라에는 제어 표면이 포함됩니다.

142~

143- 현재 상태

144- 편집 가능한 계획;

145- 생산된 인공물;

146- 차이점;

147- 승인 요청

148- 연대기;

149- 정지 버튼;

150- 재시도 버튼;

151- 보이는 권한.

152~

153사소한 것 같지만 그렇지 않습니다. "소름 끼치는 AI"와 "신뢰할 수 있는 보조자"의 차이점은 종종 후자가 자신의 손이 있는 곳을 보여 준다는 것입니다.

154~

155## 정신 스택

156~

157오늘 그려본다면 최소 에이전트 스택은 다음과 같습니다.

158~

1591. 모델: 추론, 생성, 도구 호출, 필요한 경우 다중 모드.

1602. 오케스트레이션: 루프, 단계, 플래너, 정책, 인간 참여(Human-In-The-Loop).

1613. 내구성 있는 런타임: 워크플로, 대기열, 재시도, 일시 중지, 재개.

1624. 샌드박스: 코드 실행, 격리된 파일 시스템, 제한 사항, 아티팩트.

1635. 도구 계층: MCP, 내부 API, 브라우저, 데이터베이스, 저장소.

1646. ID 계층: OAuth, 범위, 비밀, 감사, 정책.

1657. 메모리 계층: 프로젝트 컨텍스트, 검색, 지침, 만료.

1668. 관찰 가능성: 추적, 재생, 평가, 비용 및 품질 지표.

1679. 제품 표면: 충분할 때는 채팅하고, 필요할 때는 대시보드를, 중요할 때는 검토합니다.

168~

169에이전트 프레임워크는 주로 포인트 2와 포인트 1의 일부를 다루고 있습니다. 나머지는 실제 작업입니다.

170~

171## 실제로 무엇을 할 것인가

172~

173팀에서 "프로덕션에 에이전트가 필요합니다"라고 말하면 저는 10명의 에이전트로 시작하지 않을 것입니다.

174~

175저는 작고 반복적이며 관찰 가능한 작업 흐름부터 시작하겠습니다. 예를 들어 유지 관리 PR 공개, 닫힌 문제의 문서 업데이트, 주간 검토 준비, 중복 버그 선별, 영향을 받는 파일에 대한 테스트 생성 등이 있습니다.

176~

177그런 다음 매우 명확한 한계를 설정합니다.

178~

179- 가지나 샌드박스 없이는 글을 쓸 수 없습니다.

180- 프롬프트에 비밀이 없습니다.

181- 허용 목록의 도구

182- 외부 활동에 대한 인간의 승인

183- 필수 로그 및 추적

184- 실행당 예산

185- 출력은 항상 검사 가능합니다.

186~

187그래야만 확장할 수 있습니다.

188~

189모델이 잘못되었다고 해서 에이전트가 실패하는 것은 아닙니다. 우리가 그들을 혼란스러운 허가와 연극적 기대와 함께 모호한 환경에 놓기 때문에 실패합니다.

190~

191## 내가 읽은 책

192~

193Agentic 인프라는 가장 좋은 방법으로 지루합니다.

194~

195데모에서 박수를 치게 만드는 부분은 아닙니다. 실제 사람, 실제 데이터, 실제 결과가 포함된 데모를 월요일 아침에 실제로 사용할 수 있게 해주는 부분입니다.

196~

197에이전트의 미래는 누가 최고의 롤모델을 갖고 있느냐에 따라 결정되지 않습니다. 실험할 때는 고립되고, 필요할 때는 연결되고, 항상 관찰 가능하며, 기준에 따라 승인을 받고, 모를 때는 멈출 수 있을 만큼 겸손한 장소를 만드는 사람이 이를 결정할 것입니다.

198~

199에이전트가 장난감이 아닌 인프라가 되는 곳이 바로 여기입니다.

200~

201## 소스

202~

203- [Vercel: Vercel과 AI SDK를 사용하여 AI 에이전트를 구축하는 방법](https://vercel.com/kb/guide/how-to-build-ai-agents-with-vercel-and-the-ai-sdk)

204- [Vercel Docs: 샌드박스](https://vercel.com/docs/sandbox)

205- [Vercel Docs: 샌드박스 작업](https://vercel.com/docs/sandbox/working-with-sandbox)

206- [Vercel Docs: MCP](https://vercel.com/docs/mcp)

207- [모델 컨텍스트 프로토콜: 사양](https://modelcontextprotocol.io/specation)

208- [OpenAI: 에이전트 구축을 위한 새로운 도구](https://openai.com/index/new-tools-for-building-agents/)

209- [Cloudflare 블로그: Cloudflare의 에이전트](https://blog.cloudflare.com/agents-on-cloudflare/)

210~