샌프란시스코 공무원의 Multi-Agent AI 시스템 실전 개발기 | 생생한 경험담과 시행 착오 공유 | 이어진 토론 - 이것을 해킹에 이용하면???

샌프란시스코에서 공무원으로 일하는 회원분이 Builders Lounge 5차 모임에서 발표한 내용을 정리한다. 시스템을 모니터링하다 서버에 장애가 생기면 AI 에이전트들이 원인을 분석하고 조치를 제안하는 Multi-Agent 시스템을 만든 과정이다.

https://youtu.be/nypuwYuyMJQ

 

시작은 새벽 3시였다

장애가 나서 팀 전체가 깨어났는데 원인은 로그인 서버의 사소한 이슈였다. "이 정도는 AI가 알아서 하면 되지 않나?" 여기서 프로젝트가 시작됐다.

왜 단일 LLM이 아니라 Multi-Agent인가

단일 LLM으로 가면 상황을 전부 모아 한 번에 보내야 해서 컨텍스트가 터진다. 툴도 한 에이전트가 전부 들고 있어야 한다. 역할을 쪼개면 각 에이전트가 훨씬 적은 컨텍스트를 보내고, 자기에게 필요한 툴만 쓴다.

구조는 이렇다.

• Brain — 오케스트레이터. 시스템 전반을 본다
• Judge — 진짜 문제인지 판단하고 심각도(info/warning/critical)를 정하며 알림 발송 여부를 결정한다
• Investigation — 조사한다. 병원으로 치면 인턴·레지던트
• Specialist — 전문의. 조사 결과를 다시 보고 진단한다
• Airman — 사용자 인터페이스
• Agent Bus — 에이전트 간 통신 채널

ReAct 루프 — 증거를 쌓아 Confidence를 올린다

Thought → Action → Observation → Loop 를 돈다.

메모리가 95%다 → 어떤 프로세스가 원인일까 → 툴을 골라 실행 → Java가 8.2GB를 먹고 있다 → 여기서 끝이 아니라 다시 묻는다 → 최근 배포가 있었나 → GitHub 툴 → 2시간 전에 누가 바꿨다. 증거가 둘이 됐다. Confidence가 0에서 0.92까지 올라가면 조사를 완료하고 최종 가설을 낸다.

툴은 하드코딩하지 않는다 — 동적 디스커버리

사용 가능한 에이전트를 등록해 두고, LLM에게 capabilities를 넘겨 AI가 직접 어떤 툴을 쓸지 고르게 한다. switch문 하드코딩이 사라지므로 에이전트를 추가해도 Judge 코드를 고칠 필요가 없다.

하루에 토큰 100만 개를 태웠다

시뮬레이션으로 같은 장애를 반복시키자 에이전트들이 매번 LLM을 때렸다. 이미 조사 중인 인시던트인데도. 회사 토큰이 바닥나고 개인 토큰까지 날아갔다.

해결은 두 겹이다.

1. 시그니처 기반 중복 제거 — 네임스페이스·문제 유형·발생 시각으로 같은 인시던트인지 판별하고, 조사 중이면 스킵한다. 이것만으로 토큰 사용량이 20배 이상 감소했다
2. AI Gateway — AI 모델을 게이트웨이로 감싸 모든 에이전트가 이 관문을 통과해야만 LLM을 쓸 수 있게 했다. Rate Limit, CoolDown, Kill Switch가 여기 붙는다

Stateful / Stateless 분리 — 200개를 107개로

타겟이 100개면 에이전트도 100개. 각 타겟마다 고유한 모니터링을 하려면 그래야 할 것 같지만, 그렇게 하니 응답이 느려졌다. 에이전트들이 AI를 너무 많이 썼다.

AI와 대화하며 나온 답은 에이전트에도 종류가 있다는 것이었다.

 

OLD: 100개 서버/NS → 200개 LLM Agent 객체
NEW: 100 TargetAgents (가벼운 상태 객체)

• 7 LLM Workers (공유 compute)
  = 107개 객체

핵심 원칙은 이 한 줄이다. "LLM을 application object에서 compute resource로 격하시킨다." 타겟이 1,000개로 늘어도 Pool은 안 늘어난다.

Harness Engineering

프롬프트 엔지니어링이 "무엇을 해라"였다면, 지금은 너무 강력해져서 "무엇을 할 수 있는지"를 제한해야 한다는 이야기다. 말을 그냥 풀어놓을 수 없으니 안장을 얹고 굴레를 채우듯이.

적용한 장치들 — State Machine(허용된 전이만), Timeout, Rate Limit, CoolDown, Kill Switch(이머전시 스톱), State History(모든 AI 호출 기록).

객체화 — "지금 에이전트가 몇 개 돌고 있나요?"

이 질문에 답하기가 의외로 어렵다. 에이전트를 객체로 만들고 Parent(서버/네임스페이스) 아래에 두면 정확한 개수를 셀 수 있고, 특정 서버의 에이전트만 골라서 끌 수 있다. 서버를 스케일 업할 때 에이전트 수가 어떻게 늘어나는지 보이므로 스케일 판단 근거도 된다.

왜 Python이 아니라 Go인가

에이전트가 100개, 1,000개, 10,000개로 가면 Python으로는 안 된다. 프로세스를 나누려면 Redis 같은 것이 필요해진다. Go는 Go 스케줄러가 OS 스레드를 계속 관리하면서 goroutine으로 수백 개를 Redis 없이 동시에 돌린다.

시행착오가 업계 표준으로 수렴했다

겪은 문제 나온 해법

중복 호출로 비용 폭발	AI Gateway
무한 반복	TimeoutWatcher
상태가 꼬임	State Machine
에이전트 간 책임 불분명	역할별 에이전트 분리
장애 시 복구 어려움	State History 기반 복구
위험한 행동	Human In The Loop
에이전트 추적 불가	객체화

그렇게 하나씩 고쳐 놓고 보니 Anthropic이 권하는 Agentic 아키텍처와 거의 같았다.

"결국 업계에서 말하는 것도 과학자가 딱 설계해서 나온 게 아니라, 다들 비슷하게 시행착오를 거치면서 필요한 걸 다 적용하다 보니 그렇게 되더라."

기술 스택

Go · WebSocket(백엔드가 UI로 푸시) · SSH · Kubernetes · Qdrant(벡터 DB) · Next.js · Zustand · Tailwind CSS. 모델은 ChatGPT Mini로 충분했다 — 고도의 추론이 아니라 오퍼레이션 추론이기 때문이다.

"구글 검색을 안 쓴 지 2년 됐습니다"

기술 선택을 어떻게 했냐는 질문에 나온 답이다. AI에게 물어보되 "검색을 하고 알려달라" 고 요구한다. 학습 시점이 과거여도 그렇게 물으면 현재 시점으로 검색해서 답한다. 그리고 KIRO·Claude·ChatGPT를 오가며 교차 검증한다.

Q&A — 이걸 Red Teaming에 쓰면?

발표 뒤 토론이 발표만큼 재미있었다. 같은 시스템을 공격 쪽으로 돌릴 수 있는가에서 시작해, 스트레스 테스트로 일부러 망가뜨리고 블루팀 에이전트가 잡아내는지 보는 방식, Chaos Monkey, 그리고 "AI를 막으려면 결국 AI를 써야 한다"는 전망까지 갔다.

마지막으로

"2026년 현재 AI들은 이런 아키텍처까지 결정할 정도로 똑똑하지는 않다. 사용자 수준에 맞춰 주는 것 같다. 사람이 계속 조율해야지 AI에게 모든 것을 맡겨 놓으면 절대 안 된다."

---

이 발표는 Builders Lounge 5차 모임에서 있었다. AI로 뭔가를 만드는 사람들이 서로의 작업을 소개하고 직접 써 보며 피드백을 주고받는 모임이다.

• Builders Lounge 영상 전체 → https://www.youtube.com/playlist?list=PLRQGNaa1hGF0_sFgsAFNzy-f1RjD-tgIT

Builders Lounge

 

• 온라인 모임 입장 안내 → https://claude.ai/artifact/Vs9GEkCtEXsyRdT5kvyF7s

Builders Lounge 입장 안내

 

• 발표 슬라이드 34장 → https://github.com/solkit70/builders-lounge-personal-notes/tree/main/assets/presentations

builders-lounge-personal-notes/assets/presentations at main · solkit70/builders-lounge-personal-notes