AI 에이전트 아키텍처는, 백엔드 개발자 가 이미 아는 것 이다
AI 에이전트 를 공부 하다 보면 새 단어 가 쏟아진다 — Orchestrator, Guardrail, Memory, Tool, Human-in-the-loop… 처음 엔 완전히 새로운 세계 처럼 보인다. 그런데 하나씩 뜯어보면 백엔드 엔지니어 가 이미 10년 째 짓고 있던 것 들 이다. 이름 만 바뀌었을 뿐 이다.
나 는 정산(settlement) 시스템 에서 Saga · Outbox · 승인 플로우 를 굴리고, 홈랩 K3s 에서 오케스트레이션 을 운영 한다. 그 눈 으로 에이전트 7개 구성요소 를 내 가 아는 백엔드 개념 에 매핑 해 본다.
한 장 대응표
| 에이전트 용어 | 실체 (백엔드) | 내 가 이미 아는 그것 |
|---|---|---|
| LLM | 판단 엔진 | 규칙 엔진 / 정책 결정기 (단, 확률적) |
| Tool | 외부 API · DB · 브라우저 · 파일시스템 | 어댑터 · 리포지토리 · 외부 연동 |
| Agent | 특정 책임 을 가진 서비스 | 마이크로서비스 · 바운디드 컨텍스트 |
| Orchestrator | Saga · Workflow Engine · Coordinator | 분산 트랜잭션 조율자 |
| Memory | DB + Vector Store + Context | 영속 계층 + 캐시 + 세션 |
| Guardrail | Validation + 권한 + 정책 | 입력 검증 · 인가 · 레이트리밋 |
| Human Approval | 결재 · 승인 플로우 | 워크플로 상 의 휴먼 태스크 |
이 표 하나 가 오늘 글 의 전부 다. 아래 는 각 줄 을 왜 그렇게 매핑 되는지 풀어 쓴 것.
1. LLM = 판단 엔진 (단, 확률적)
전통 백엔드 에도 “판단” 은 있었다 — if/else, 규칙 엔진(Drools), 정책 결정기. 입력 을 받아 다음 행동 을 고르는 컴포넌트.
LLM 은 그 자리 를 대체 한다. 차이 는 딱 하나 — 결정 이 결정적(deterministic) 이 아니라 확률적 이라는 것. 같은 입력 에 늘 같은 출력 이 아니다. 이게 에이전트 설계 의 모든 어려움 의 근원 이다:
- 규칙 엔진 은 틀리면 버그 → 고치면 됨
- LLM 은 가끔 틀림 → 고칠 수 없고, 주변 을 감싸서 막아야 함
그래서 뒤 에 나올 Guardrail 과 Human Approval 이 옵션 이 아니라 필수 가 된다. 판단 엔진 이 확률적 이 된 순간, 그 판단 을 검증 하는 계층 이 시스템 의 절반 이 된다.
2. Tool = 어댑터 (헥사고날 그대로)
에이전트 가 “Tool 을 호출 한다” 는 건, 헥사고날 아키텍처 로 말하면 아웃바운드 포트 를 통해 어댑터 를 호출 하는 것 과 정확히 같다.
[ LLM = 애플리케이션 코어 ]
│ (port)
┌──────────────┼──────────────┐
[DB adapter] [HTTP adapter] [File adapter]
search_products(query)→ 리포지토리 어댑터call_payment_api(...)→ 외부 연동 어댑터read_file(path)→ 파일시스템 어댑터
MCP(Model Context Protocol) 가 요즘 뜨는 이유 도 여기 있다 — Tool 을 꽂는 표준 인터페이스, 즉 포트 규격 의 표준화 다. 헥사고날 에서 포트 인터페이스 를 통일 하면 어댑터 를 갈아끼울 수 있듯, MCP 는 에이전트 와 도구 사이 를 표준화 해서 어떤 LLM 이든 어떤 도구 든 조합 가능 하게 만든다.
3. Agent = 마이크로서비스 (단일 책임)
“멀티 에이전트” 라는 말 이 거창 하게 들리지만, 본질 은 단일 책임 원칙(SRP) 이다. 하나 의 거대 프롬프트 에 모든 걸 시키면 — 모놀리스 가 그렇듯 — 커질수록 무너진다.
research-agent— 자료 수집 만review-agent— 검증 만settlement-verify-agent— 정산 대사 만
각 에이전트 는 자기 책임 · 자기 도구 · 자기 컨텍스트 를 가진 바운디드 컨텍스트 다. 서비스 를 쪼개는 이유(격리 · 교체 가능성 · 병렬성) 가 에이전트 를 쪼개는 이유 와 똑같다. 그리고 쪼갠 순간 — 누가 이들 을 조율 하나? 라는 질문 이 따라온다. 다음 항목.
4. Orchestrator = Saga (내 가 매일 짜는 것)
이게 나 한테 가장 익숙한 부분 이다. 정산 시스템 에서 주문 → 결제 → 정산 → 환불 을 조율 하는 게 바로 Saga 다. 여러 서비스 에 걸친 작업 을, 중간 에 실패 하면 보상(compensation) 하며 끌고 가는 조율자.
멀티 에이전트 오케스트레이터 는 이걸 그대로 빌려온다:
| 정산 Saga | 에이전트 Orchestrator |
|---|---|
| 단계 = 서비스 호출 | 단계 = 에이전트 호출 |
| 실패 시 보상 트랜잭션 | 실패 시 재시도 / 대안 에이전트 |
| 상태 머신 (PENDING→…) | 태스크 큐 · 워크플로 상태 |
| 멱등성(idempotency) 보장 | 같은 스텝 재실행 안전 |
차이 는 스텝 의 결과 가 확률적 이라는 것 뿐. 그래서 에이전트 오케스트레이터 는 Saga 보다 재시도 · 검증 루프 가 더 두껍다. 하지만 뼈대 는 — 상태 머신 + 보상 + 멱등성 — 완전히 동일 하다. Temporal 같은 워크플로 엔진 이 에이전트 판 에서도 그대로 쓰이는 이유 다.
5. Memory = 영속 계층 + 벡터 + 세션
“에이전트 메모리” 는 신비한 게 아니라 세 종류 의 저장소 조합 이다:
- 단기 (chat history, 현재 상태) = 세션 / 요청 스코프 캐시. 웹 의 HttpSession 과 다르지 않다.
- 장기 (과거 사건, 학습된 패턴) = 영속 DB. 우리 가 늘 쓰는 그 RDB.
- 벡터 스토어 (의미 검색) = 인덱스. B-tree 가 정확 일치 를 빠르게 찾듯, 벡터 인덱스 는 의미 유사 를 빠르게 찾는다.
즉 벡터 스토어 는 “새로운 DB” 가 아니라 새로운 인덱스 타입 으로 보는 게 정확 하다. WHERE name = ? 대신 ORDER BY embedding <-> ? 를 쓸 뿐. 검색 대상 이 키워드 에서 의미 로 바뀐 것.
6. Guardrail = 검증 + 인가 + 레이트리밋
여기서 백엔드 경험 이 진짜 로 빛난다. Guardrail 이라는 새 단어 를 뜯으면:
- 입력 Validation — 컨트롤러 앞 단 의
@Valid, 그대로다 - 권한 / 인가 — 이 에이전트 가 이 도구 를 쓸 자격 이 있나? RBAC 그대로
- 정책 / 레이트리밋 — 분당 호출 제한, 비용 상한. API 게이트웨이 그대로
- 콘텐츠 체크 — 출력 필터링. XSS 방어 하던 그 감각
내 가 텔레그램 운영 봇 을 굴릴 때 지키는 3원칙 도 결국 Guardrail 이다 — 화이트리스트(인가) · 메시지=데이터(입력 불신) · 토큰 암호화(비밀 관리). 새 이론 이 아니라, 보안 을 아는 사람 이 늘 하던 것 을 에이전트 표면 에 다시 붙이는 것 이다.
한 가지 만 강조 — LLM 은 확률적 이라(§1), Guardrail 은 신뢰 경계 에 결정적 코드 로 놓아야 한다. “프롬프트 로 하지 마세요 라고 부탁” 하는 건 Guardrail 이 아니다. 실제 로 차단 하는 검증 코드 가 Guardrail 이다.
7. Human Approval = 결재 플로우
마지막. 이건 그냥 워크플로 안 의 휴먼 태스크 다. 전자결재, 주문 승인, 배포 승인 — 이미 수십 년 된 패턴.
에이전트 가 되돌릴 수 없는 행동(돈 이체, 파일 삭제, 외부 발송) 을 하기 전 에 사람 의 결재 를 받는다. BPM 엔진 의 approval task 와 구조 가 같다:
에이전트 판단 → [사람 결재 대기] → 승인 → 실행
└ 거부 → 중단 / 대안
핵심 은 어디 에 이 게이트 를 놓느냐 다. 모든 행동 에 결재 를 걸면 자동화 의 의미 가 없고, 아무 데도 안 걸면 사고 가 난다. 위험 도 에 따라 게이트 를 차등 — 조회 는 자동, 이체 는 결재. 이 판단 이 곧 시스템 설계 실력 이다.
그래서 — 백엔드 개발자 는 유리 하다
에이전트 를 처음 배우는 사람 은 7개 단어 를 새로 외운다. 백엔드 를 아는 사람 은 7개 를 이미 아는 것 에 연결 한다:
LLM=규칙엔진 · Tool=어댑터 · Agent=마이크로서비스 · Orchestrator=Saga · Memory=DB+인덱스+세션 · Guardrail=검증+인가 · Approval=결재
새로운 건 판단 엔진 이 확률적 이 됐다 는 한 가지 뿐 이다. 그리고 그 하나 때문 에 — Guardrail 과 Human Approval, 즉 검증 과 승인 의 무게 가 이전 보다 훨씬 커졌다. 확률적 두뇌 를 결정적 뼈대 로 감싸는 일. 그게 에이전트 아키텍처 의 본질 이고, 그 뼈대 는 우리 가 이미 짓던 것 이다.
에이전트 시대 에 백엔드 경험 은 낡은 자산 이 아니다. 그 자산 을 새 표면 에 어떻게 다시 붙이느냐 — 거기서 갈린다.