IT 기술 따라잡기

샌프란시스코에서 공무원으로 일하는 회원분이 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 없이 동시에 돌린다.

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

겪은 문제 나온 해법

그렇게 하나씩 고쳐 놓고 보니 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

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

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

지난 7월, 시애틀에서 열린 AI 행사들을 카메라 들고 찾아다녔습니다. Seattle Tech Week 2026 주간(7/27~31)의 여섯 개 행사, 그리고 그 직전 주에 열린 AI 밋업 하나. 전부 현장에서 직접 녹화했습니다.

그렇게 담은 영상이 31편입니다. 9월 18일부터 하나씩 공개되고 있고, 마지막 편이 열리는 날짜는 2027년 1월 1일입니다.

왜 한 번에 올리지 않는가

31편을 한꺼번에 올리면 아무도 다 보지 않습니다. 재생목록에 31개가 쌓이는 순간 그건 아카이브지 콘텐츠가 아닙니다.

그래서 화요일과 금요일, 주 2편씩 공개합니다. 한 편이 열릴 때마다 그 발표 하나에 집중할 수 있고, 3개월 반 동안 시애틀 AI 생태계를 한 조각씩 따라가는 형태가 됩니다.

각 영상은 먼저 Members Only 로 올라간 뒤 예정일에 Public 으로 전환됩니다. 기다리지 않고 보고 싶으면 멤버십이 지름길이고, 기다리면 전부 무료로 열립니다.

전부 한국어 자막을 달았습니다

원본은 전부 영어 발표입니다. 31편 모두 전사 → 번역 → 자막 작업을 거쳤습니다.

시애틀 AI 세미나 영상에 자막을 제대로 붙이기 시작한 게 이 묶음부터입니다. 그 전에도 시험 삼아 몇 편 달아 본 적은 있지만, 행사 전체를 자막까지 붙여 내보내는 건 이번이 처음입니다.

영어라서 그냥 지나쳤던 현장 발표를, 이제 한국어로 편하게 보실 수 있습니다.

Seattle Spark + AI — Databricks Bellevue, 7월 22일

먼저 사실관계 하나. 이 행사는 Seattle Tech Week 이 아닙니다. 주간(7/27~31) 직전 주에 열린 별도의 AI 밋업입니다. PyLadies Seattle, Seattle WiMLDS 가 함께 준비했고, Databricks 벨뷰 사무실에서 열린 덕분에 발표자가 전부 그 제품을 직접 만드는 엔지니어와 PM 이었습니다.

Omnigent: An Open-Source Meta Harness for AI Agents — Denny Lee (20:42)

여러 LLM 과 코딩 에이전트를 오가며 매번 맥락을 복사해 붙여넣는 문제에서 출발합니다. 여러 모델에 한 번에 질의하고, 모델끼리 토론시키고, 추론 경로를 분기해서 비교하는 오픈소스 하네스를 시연합니다.

https://youtu.be/uACNZTN6doU

Testing PySpark Transformations Before Bad Data Reaches Production — Kunal Jain, Adobe (28:49)

파이프라인은 성공했는데 데이터가 틀린 상황을 다룹니다. "행이 있다"와 "행이 맞다"는 전혀 다른 주장이라는 것. 스키마 검사가 못 잡는 결함을 파이프라인 어느 지점에서 걸러낼 것인가, 그리고 조용히 사라지고 있던 데이터를 뒤늦게 발견한 실제 사례가 나옵니다.

https://youtu.be/v73ucqAIDEk

Apache Spark Structured Streaming: Simpler, More Reliable, Easier to Recover — B. Micheal Okutubo, Databricks (38:08)

스트리밍 엔진 팀이 직접 설명하는 마이크로배치, 체크포인트, State Store. 새로 들어온 API 와 테스트 프레임워크, 그리고 비용과 성능 사이의 선을 어디에 긋는지까지 다룹니다.

https://youtu.be/TInzom7heAs

[Keynote] Spark Structured Streaming Real-Time Mode — Sudhanva Huruli, Databricks (11:08)

마이크로배치는 '초 단위'를 위해 설계된 구조인데 고객은 이제 '밀리초'를 요구합니다. 실시간 카드 결제 분석을 사례로, 그 요구를 맞추기 위해 내부 구조를 어떻게 바꿨는지를 11분에 압축했습니다.

https://youtu.be/ZtlmOOHJdZ0

AI Startup Secret Sauce — Bellevue City Hall, 7월 27일

Seattle Tech Week 첫날 행사입니다. Future Force 의 Level UP 프로그램과 Startup425 가 함께 열었고, 구글·세일즈포스·JP모건 현직자가 창업의 세 단계를 하나씩 맡았습니다. 아이디어를 찾고 → 검증하고 → 키우는 순서 그대로입니다.

Clara: Giving Surgical Services a Sixth Sense — Melinda Yormick (2:41)

미국 병원에 숨어 있는 460억 달러 규모의 문제. 연 9,200만 건의 수술마다 5~10분이 버려지고, 수술실 1분의 값이 약 100달러입니다. 2분 41초짜리 피치인데 문제 정의가 아주 선명합니다.

https://youtu.be/1sv-rS6XjwU

Which AI Ideas Are Worth Building? — Eden Cohen, Google Gen AI 제품 리드 (15:10)

지능의 가격이 10배에서 1000배 떨어졌고, 그래서 '만드는 것'은 더 이상 병목이 아니라는 전제에서 시작합니다. 사람을 투입하기엔 너무 비쌌던 문제를 찾는 두 가지 방법 — 아무도 분석할 가치가 없다고 여겼던 데이터, 그리고 '한 사람을 위한 소프트웨어'가 될 때까지 좁히는 세분화.

https://youtu.be/yDVHzmAaGpA

A Founder's Field Guide: Opinions Are Free. The First Dollar Isn't — Amit Gupta, Salesforce (9:49)

하룻밤이면 그럴듯한 제품이 나오는 시대에 '만드는 능력'은 더 이상 해자가 아니라는 이야기. 유일하게 증거가 되는 것은 고객이 실제로 돈을 냈는가입니다. 25년 차 실무자의 단호한 15분.

https://youtu.be/Jgi5XUKPpL8

How Founders Should Scale with AI Agents — Sunny Kotwal, JPMorgan Chase (10:16)

직무 전체를 에이전트에게 넘기려 하지 말고, 작고 검증 가능하고 반복되는 일을 맡기라는 조언. 너무 빨리 간 사례로 Klarna 의 AI 고객센터 되돌리기를 짚습니다.

https://youtu.be/zmddOVaqgXU

Startup Q&A: First Dollar, CTOs, and AI Scaling — 패널 3인 (18:33)

객석 질문을 그대로 받은 시간입니다. "Claude Code 시대에 비개발자 창업자에게 CTO 가 여전히 필요한가"라는 질문이 특히 기억에 남습니다. 접거나 방향을 틀 때를 알려주는 신호에 대한 답도 나옵니다.

https://youtu.be/J3zub9RPol4

앞으로 열릴 영상들

나머지 22편은 이렇게 이어집니다.

행사 편수 기간

Demo Day 10편에는 8주짜리 액셀러레이터를 마친 창업자들의 라이브 데모가 들어 있습니다. 코딩을 직접 하지 않던 사람이 8주 만에 무엇을 만들어 왔는지 보실 수 있습니다.

전체 재생목록은 여기입니다.

https://www.youtube.com/playlist?list=PLRQGNaa1hGF2R3VRbp8nAcx4ORKxBRbam

행사를 준비할 때 프로그램, 홍보, 참가자 등록만큼 먼저 확인해야 할 것이 있습니다. 사람들이 안전하게 들어오고, 통로를 이용하고, 상황이 바뀌었을 때 필요한 안내를 받을 수 있도록 준비되어 있는지입니다.

시애틀의 한 비영리단체에서 자원봉사 활동을 하면서 받게 된 외부 전문 교육기관의 교육 경험을 바탕으로, 커뮤니티 행사 준비자·자원봉사자·참가자에게 도움이 될 수 있는 행사 안전 영상 두 편을 만들었습니다. 이 글과 영상은 일반적인 대비 교육 자료이며, 실제 행사에 필요한 교육·인력·허가·안전계획은 행사 규모와 장소, 주·시·지역 기관 및 행사장 요구사항에 따라 달라질 수 있습니다.

Crowd Management: 사람이 모이기 전 확인할 것

첫 번째 영상은 출입구와 피난 통로, 인원 흐름, 개장 전 점검, 현장 역할 분담을 다룹니다. Crowd Manager 역할은 단지 현장에서 사람을 안내하는 일이 아니라, 문제를 미리 발견하고 적절한 담당자에게 알리며 안전한 흐름을 유지하도록 돕는 일입니다.

Massachusetts Department of Fire Services(DFS)의 Crowd Manager Training을 중심으로 소개하지만, 다른 주에서 행사를 준비한다면 하나의 공통 자격 기준으로 받아들이면 안 됩니다. 실제 기준은 지역 소방·건축·허가 기관과 행사장의 현재 요구사항을 확인해야 합니다.

https://youtu.be/ytntz1bY0RI

Active Shooter Preparedness: 위협 상황에서 기억할 우선순위

두 번째 영상은 DHS·CISA의 공공 안전 자료를 바탕으로 Run · Hide · Fight, 911 신고 시 전달할 정보, 대응요원 도착 시 행동, 그리고 행사 전 비상행동계획(EAP)과 짧은 안전 브리핑을 정리합니다. 이 내용은 전술 교육이나 법률 자문을 대신하지 않으며, 실제 위협 상황에서는 즉시 911에 신고하고 현장 법집행기관의 지시에 따라야 합니다.

FEMA IS-907.A 등 영상에서 소개한 공식 교육은 준비를 시작할 수 있는 경로입니다. 수료 기록 또는 Certificate가 필요한 경우에는 등록 전 과정 제공기관의 최신 수료 조건과 행사장·지역 기관의 요구사항을 직접 확인해야 합니다.

https://youtu.be/-LPEgIwfjAs

다음 행사 전에 함께 확인할 질문

• 출입구와 통로, 비상 출구가 누구에게나 분명하고 막히지 않았는가?
• 현장에서 안전 관련 결정을 내리고 보고를 받을 담당자가 정해져 있는가?
• 자원봉사자와 운영진이 집결 장소, 연락 방법, 비상행동계획을 알고 있는가?
• 필요한 교육·인증·허가 기준을 공식 기관과 행사장에 최신 정보로 확인했는가?

영어 영상도 각각 공개되어 있다. Crowd Management: English video · Active Shooter Preparedness: English video