IT 기술 따라잡기

검색 AI가 좋은 답을 내놓는지 확인할 때, 답변의 정확도만 비교하면 충분할까요? 검색 서비스를 바꿨을 때 실제 사용자의 경험과 목표 달성에 어떤 차이가 생기는지도 살펴야 합니다.

Builders Lounge 5차 모임에서 김진영 네이버 검색 US 디렉터님은 이 문제를 다루기 위해 설계·구현한 멀티 에이전트 평가 시스템을 소개했습니다. 시스템은 검색을 실제 사용자처럼 수행하는 User Agent, 그 결과와 경험을 평가하는 Evaluator, 평가가 일관된 기준으로 이루어졌는지 살피는 Auditor로 구성됩니다.

사용자처럼 검색하는 에이전트

User Agent는 정해진 검색 태스크를 받아 검색 서비스를 이용합니다. 답변을 읽고 사용자의 목표가 달성됐는지, 어떤 경험을 했는지 평가할 수 있도록 대화와 행동 과정을 남깁니다. 검색 시스템마다 같은 태스크를 수행하게 해 결과를 비교하는 출발점입니다.

평가자와 검토자의 역할

Evaluator는 태스크에 적힌 성공 기준 (Success Criteria)을 바탕으로 답변과 검색 경험을 평가합니다. Auditor는 비교 대상별 평가가 같은 기준으로 진행됐는지 살핍니다. 평가 기준을 만들 때는 기대 답을 고정된 Ground Truth로 간주해도 되는지, 검색 지식이 질의와 시점에 따라 바뀌는 문제를 어떻게 다룰지 고민이 필요합니다.

발표에서 소개한 평가 결과가 외부 벤치마크나 NPS와 검증 완료됐다는 뜻은 아닙니다. 김진영님은 내부에서 사용하는 지표와 결과가 일치하는지 확인하려 한다고 설명했습니다.

실제 사용자 실험 전의 가상 사용자 평가

발표에서는 대표성 있는 여러 사용자 페르소나를 에이전트로 구성해 실제 사용자 대상 A/B 테스트 전에 서비스를 탐색해 보는 가능성도 다뤘습니다. 이 방식은 실제 사용자를 완전히 대체하는 것으로 소개된 것이 아닙니다. 페르소나를 어떻게 객관적으로 정의할지, 공개 자료와 서비스에서 얻은 실제 사용자 데이터를 어떻게 활용할지가 중요한 과제로 남습니다.

AI 개발에서 사람의 역할

질의응답과 토론에서는 프로토타입을 만드는 것과 다른 사람도 사용할 수 있는 제품으로 다듬는 일의 차이도 이야기했습니다. 큰 목표를 작은 하위 작업으로 나누고, 무엇을 만들지 정하고, 결과를 검토하는 사람의 역할은 여전히 필요하다는 경험을 나눴습니다.

AI 요약을 읽고 끝내면 여러 출처를 직접 비교하며 쌓던 맥락과 판단력이 줄어들 수 있다는 우려도 나왔습니다. 검색과 AI 요약에는 각기 다른 장단점이 있으며, AI가 만든 결과를 확인하고 이해하는 과정도 중요하다는 논의였습니다.

영상과 발표 자료

영상은 한국어 발표이며 영어 자막을 제공합니다. YouTube 자막(CC)에서 영어를 선택할 수 있습니다.

https://youtu.be/FdWigceb1pk

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