Skip to content

Archive

Altos x OpenAI 멀티에이전트 구축 워크샵 참석 후기

알토스벤처스와 OpenAI가 함께 진행한 멀티에이전트 구축 워크샵 참석 후기입니다. Agent 구성 공식, 멀티에이전트 실패 사례, Eval의 중요성을 중심으로 정리했습니다.

2026년 3월 7일Published
OpenAIWorkshopLearning

지난 주 좋은 기회로 알토스벤처스와 OpenAI가 함께 하는 워크샵에 다녀왔습니다.

알토스는 한국 스타트업들이 가장 투자받고 싶어하는 벤처캐피탈로 잘 알려져 있는 VC인데 저희 회사도 포트폴리오사 중 한 곳이라 기회가 닿았습니다.

알토스 오피스는 한남동에 있는데 마땅한 교통편이 여의치 않기도 하고 한강변이라 그날도 자전거를 타고 출근을 했습니다. ㅎㅎ

날씨도 괜찮은 편이었고 한강변이라 자전거 타기에 좋았습니다. 한남동이 꽤나 언덕이라 막판엔 조금 힘들긴 했지만요. 😅

알토스 오피스는 여느 회사들과는 달리 사무실 위치도 독특했지만 멋진 주택을 개조해서 레스토랑이나 전시회를 하는 곳 같은 인테리어도 인상적이었습니다. 마치 인테리어 잡지에 나올 것 같은 분위기였습니다. 😊

사무실을 구경하러 간 것은 아니었기에 사진을 많이 찍지는 않았는데 블로그에 쓰려니 아쉽네요.

알토스 오피스

워크샵은 대략 20명 정도 참석하신 것 같았는데 제가 가장 먼저 왔습니다. 꽤나 언덕이라 다들 쉽진 않으셨을 듯합니다. ㅎㅎ

워크샵장 도착

들어오니 아메리카노도 챙겨주시고 너무 좋았습니다. 끝나고 네트워킹 세션에서는 샌드위치도 주셨습니다!

워크샵은 오전 10시부터 12시를 약간 넘겨서까지 진행되었습니다.

워크샵 진행 모습
워크샵 내용

워크샵 구성

워크샵은 OpenAI의 스타트업팀에서 주도하는 것 같았습니다. 처음은 스타트업팀 소개와 OpenAI의 비전, 경쟁력 등에 대한 소개로 시작되었습니다. 스타트업팀은 한국지사 소속이 아니라 글로벌 원팀인데 한국에 있어서 많은 지원을 해주실 수 있다는 점을 강조해주셨던 게 인상적이었습니다.

메인 주제는 멀티에이전트 구현이었는데 RAG로 박사를 하신 OpenAI 담당자분이 발표해주셨습니다. 에이전트가 무엇인지부터 싱글 에이전트와 멀티 에이전트의 차이는 무엇인지, 어떤 요소들이 있고 개발 프로세스는 어떻게 되는지 등 개략적인 내용도 알려주시고, 직접 만든 간단한 에이전트 데모 소개와 코덱스를 활용한 라이브 시연 및 실습까지 진행되었습니다.

전반적으로 에이전트 제품을 만드는 테크리더들을 위한 세션이었기에 제가 소화하기에는 버거웠지만 인상적이었던 메모들만 정리해봅니다.

에이전트 구성 공식

특정 목적을 달성하기 위해 설계된 시스템이 에이전트입니다.

Agent = Model + Routine + Tools

  • Model: 두뇌 역할을 하는 LLM
  • Routine (가장 중요): 시스템 프롬프트
    • 단계별(Step) 구분과 # 등 기호를 사용해 구간을 명확히 나누는 것이 핵심
  • Tools: 이미지 생성(MCP 등)이나 외부 API 호출처럼 모델의 능력을 확장하는 기술적 도구 (루틴을 보조하는 역할)

멀티에이전트의 실패 사례

  • 컨택스트가 잘려있거나, 에이전트 간에 잘 연결이 안됨
  • 토큰이나 비용이 폭발적으로 증가
  • 에이전트들끼리 정보 전달이 제대로 되지 않는 경우 (weak handoffs)
  • 롤이 오버랩되거나, 코디네이션이 모호한 경우 (에이전트 간 역할이 명확해야 함)

Evals(평가)의 중요성

에이전트 빌드 시 가장 중요한 것이 평가입니다. 타겟 달성 여부를 확인할 수 있는 프레임워크가 필요합니다.

  • 루틴과 툴은 우리가 직접 만들고, 모델은 알아서 만들어질 것입니다. 평가 프레임워크가 잘 구축되어 있다면 어느 모델이 나은지 확인도 쉬워집니다.
  • 트레이싱 — 추적이 가장 중요: 그래야 뭐가 문제일지 알 수 있습니다.
  • 성능 평가: 보통 LLM 판단을 고려합니다. 휴먼이 판단하면 좋지만 리소스가 많이 들고 확장성이 부족합니다.
  • 성능평가를 할 때는 낮은 모델을 쓰는 게 나을 수 있습니다. 전문가보다 대중이 평가하는 것이 나은 경우가 있기 때문입니다.
  • 프로바이더를 여러 개 두는 것도 좋습니다(다양한 그레이더 모델 활용).
  • 휴먼 평가를 최대한 모사합니다.
  • 테스트를 만들어서 평가를 무한 반복시키는 프레임워크를 구축합니다.
  • 평가가 주관적이면 어쩌지 싶을 때는 메타 평가를 합니다(사람의 평가와 유사한 모델을 고름).
  • 평가 프레임워크의 변수를 여러 가지로 바꿔보며 최적화합니다.

Q&A에서 인상 깊었던 내용

Q. 간단한 보험 상담 에이전트 개발 데모 — 평가(eval) 설계는 어떻게?

  • 상담사의 예상 답변이나 과거 답변 기록 데이터 세트를 준비하고 제공
  • 작게 해보고 성공하면 점점 범위를 늘려간다

Q. 간단한 보험 상담 에이전트 개발 — 코덱스로 얼마나 걸렸나?

  • 코덱스에게 시키기만 4시간 걸림. 그러나 UI 고치는 시간이 오래 걸림

Q. 멀티에이전트는 언제 효과적인가?

  • 예를 들어 CX 봇 — 다양한 상담 분야, 다양한 유저의 성향에 맞게 각각을 담당하는 에이전트 구성하면 좋음

Q. 비개발자가 에이전트 만들기 같은 것을 사내에서 더 잘하게 하는 법?

  • 내 업무에 필요한 것들부터 적용해보기

마무리

황새의 보폭을 따라가려는 뱁새마냥 힘겨운 워크샵이었지만 일단 주워담고 실행해보며 10%라도 제 것으로 만들어야겠다 싶었습니다.

그래도 워크샵을 듣고 성과가 두 가지는 있었습니다.

  1. 노정석님 유튜브에서 자주 나오는 단어 'Eval'의 정체에 대해 좀 더 친숙해지게 되었습니다.
  2. 에이전트를 만들어 보고 싶다는 생각이 들었고 실제로 새로운 시도들을 해보게 되었습니다.

역시 이 시대에 가장 필요한 것은 의지와 실행입니다.


원문 블로그 포스트 보기


이 글은 LinkedIn에 처음 공개한 글입니다.