비전공자를 위한 AI Agent 9편

비전공자를 위한 AI Agent 9편

“AI Agent 서비스 아키텍처 A to Z – 스크립트가 ‘제품’이 되는 순간”

여기까지 따라왔다면
이제 이 질문이 자연스럽게 떠오를 거예요.

“이 에이전트…
혼자 쓰기엔 충분한데
사람들이 쓰는 서비스로 만들려면
뭐가 더 필요하지?”

이 지점이 가장 많이 망하는 구간입니다.

• 코드 잘 짰는데 서비스는 안 됨
• 데모는 되는데 운영이 안 됨
• 비용이 갑자기 튀어 오름
• 책임 소재가 애매해짐

그래서 오늘 글은
**‘에이전트를 서비스로 만드는 최소 아키텍처’**를 다룹니다.

---

1️⃣ 먼저 결론부터: 에이전트는 절대 혼자 살지 않는다

스크립트 단계에서는 이게 가능했죠.

user → agent.py → 결과

서비스 단계에서는 무조건 분리됩니다.

[사용자]
   ↓
[API 서버]
   ↓
[Agent Orchestrator]
   ↓
[LLM / Tools / RAG]
   ↓
[로그 / 저장소]

👉 에이전트는 시스템의 한 구성요소일 뿐입니다.

---

2️⃣ 실무형 AI Agent 서비스의 최소 구성 6요소

비전공자 기준으로
이 6개가 빠지면 서비스가 아닙니다.

---

① 사용자 인터페이스 (UI)

• 웹
• 관리자 페이지
• 슬랙 봇
• 사내 툴

중요한 포인트:

❌ “AI가 알아서 다 한다” UI
✅ “AI가 무엇을 할지 보여주는 UI”

👉 사용자는 결과 + 과정 일부를 보고 싶어 합니다.

---

② API 서버 (Agent를 직접 노출하지 마라)

반응형

절대 하지 말 것:

Frontend → OpenAI API

반드시 이렇게:

Frontend → 우리 API → Agent

이유는 간단합니다.

• API Key 보호
• 로깅
• 비용 통제
• 권한 분리

👉 Agent는 항상 서버 뒤에 숨긴다

---

③ Agent Orchestrator (두뇌 아님, 지휘자)

여기가 핵심입니다.

Agent Orchestrator는:

• 언제 에이전트를 실행할지
• 어떤 Tool을 허용할지
• 루프를 돌릴지 말지
• 실패 시 어떻게 처리할지

를 관리합니다.

👉 LLM은 판단자
👉 Orchestrator는 통제자

이걸 섞으면 운영 지옥 옵니다.

---

④ Tool Layer (권한의 경계선)

Tool은 기능이 아니라 권한이라고 했죠.

그래서 서비스에서는 보통 이렇게 나눕니다.

• Read Tools
• Write Tools
• Risky Tools (승인 필요)

Agent는:

• “이 Tool 써도 될까?” 요청
• Orchestrator가 허용 여부 판단

👉 Agent가 직접 권한을 가지면 안 됩니다

---

⑤ 상태 저장소 (State & Memory)

서비스 단계에서는
“한 번 실행”이 아니라 “진행 중 상태”가 필요합니다.

저장해야 할 것들:

• 요청 ID
• 현재 단계
• 중간 결과
• 재시도 횟수

이게 없으면:

“어디까지 했지?”
→ 아무도 모름

---

⑥ 로그 & 비용 모니터링

이건 선택이 아닙니다. 필수입니다.

• 요청당 토큰 사용량
• 에이전트 실행 시간
• Tool 호출 횟수
• 실패율

이걸 안 보면
👉 비용 폭탄
👉 원인 모를 장애

---

3️⃣ 에이전트 서비스의 표준 흐름 (실제 운영 기준)

1. 사용자 요청
2. 요청 검증 (권한 / 형식)
3. Agent 실행 요청 생성
4. Orchestrator 판단
5. Agent 실행 (LLM + Tools)
6. 중간 로그 저장
7. 결과 생성
8. 사용자에게 전달

중요한 점:

👉 에이전트는 동기 처리일 필요 없음
👉 대부분은 비동기 작업이 안전합니다.

---

4️⃣ 비용 통제를 안 하면 무조건 망한다

비전공자분들이 제일 놀라는 지점이 여기예요.

“어…
테스트 몇 번 했는데
비용이 왜 이렇게 나왔지?”

그래서 서비스 단계에서는 무조건 이걸 둡니다.

비용 통제 가드레일

• 사용자별 토큰 한도
• 요청당 최대 실행 시간
• 하루 실행 횟수 제한
• Tool 호출 제한

👉 “똑똑한 AI”보다
👉 “안 새는 AI”가 먼저입니다.

---

5️⃣ 에이전트 서비스에서 자주 터지는 사고 TOP 5

1️⃣ 무한 루프
2️⃣ 로그 없음
3️⃣ 권한 과다
4️⃣ 비용 통제 없음
5️⃣ 실패 시 복구 불가

이 중 하나라도 있으면
언젠가는 사고 납니다.

---

6️⃣ 비전공자에게 추천하는 현실적인 시작 방식

처음부터 거창하게 하지 마세요.

추천 순서

1. 단일 Agent
2. 제한된 Tool
3. 관리자 전용 UI
4. 로그 먼저
5. 사용자 확장

👉 “잘 되는지”보다
👉 “망가져도 복구 가능한지”가 먼저입니다.

---

7️⃣ 이 시리즈의 진짜 메시지

이 시리즈를 관통하는 메시지는 하나예요.

AI Agent는
모델 문제가 아니라
시스템 문제다

• 구조
• 통제
• 경계
• 로그
• 책임

이게 없으면
아무리 똑똑한 모델도
사고 치는 신입 사원일 뿐입니다.

---

다음 글 예고 (마지막)

10편 – AI Agent, 어디까지 맡기고 어디서 멈춰야 할까?

• 인간 vs 에이전트 역할 분리
• AI에게 절대 맡기면 안 되는 것
• “좋은 에이전트”의 기준

👉 이 글로
A to Z 시리즈를 마무리합니다.

---

오늘 요약 (이 문장 하나면 충분)

AI Agent를 서비스로 만든다는 건
AI를 통제 가능한 시스템 안에 넣는 일이다

이걸 이해하면
당신은 이미
**에이전트 ‘사용자’가 아니라
에이전트 ‘설계자’**입니다.

---

 

AI Agent 아키텍처,AI 에이전트 서비스,비전공자 AI 제품화,AI 시스템 설계,LLM 서비스 구조,AI Agent 운영,AI 비용 통제,AI 자동화 서비스,AI Agent API,생성형 AI 실무