이전

AI Engineer — 컨퍼런스 발표 아카이브

AI Engineer

에이전트를 실제로 굴려 본 사람들이 무엇에서 막혔고 무엇으로 뚫었는지. 발표 한 편을 번호글로 옮겨 담습니다.

정리일 2026-08-26 수록 72편 소스 youtube.com/@aidotengineer

발표 한 편이 카드 한 장입니다. 다른 장과 달리 핵심 포인트로 갈라 쓰지 않고 한 생각에 번호 하나를 매겨 순서대로 늘어놓았습니다 — 발표는 앞의 말이 뒤에 걸리는 글이라 조각으로 나누면 그 걸림이 사라집니다. 맨 끝의 「한줄 코멘트」가 이 글의 판단입니다.

자막 전문에서 옮겼고, 발표자가 자기 회사를 파는 대목은 그렇다고 밝혀 두었습니다. 숫자는 발표에 나온 것만 싣습니다.

06

서빙 · 비용 · 인프라

  1. 이 발표는 마이크로소프트(Microsoft) 소속 티샤 차울라(Tisha Chawla)와 수심 코울(Susheem Koul)이 AI 엔지니어 컨퍼런스에서 한 것으로, 오늘날 AI에서 가장 비싼 질문은 "토큰을 누가 다 썼나"라고 던지며 시작함.
  2. 에이전트 워크플로를 돌리고 AI 청구서를 열어봐도 그 비용이 어디서 나왔는지 추적이 안 되는 경험을 다들 해봤을 거라고 함.
  3. 지금 업계는 이 문제를 문제로 보지 않고, 오히려 탐색을 위해 토큰을 최대한 많이 쓰는 것("토큰 맥싱")을 가치 있게 본다고 지적함. 사람들은 스스로를 "토큰 백만장자"라 부르는 걸 자랑스러워한다고 하며, 이 발표는 토큰 맥싱에서 "가치 맥싱"으로 넘어가는 이야기라고 밝힘.
  4. 출발점은 "누가 토큰을 다 썼나"라는 질문이고, 누군가 토큰을 다 썼다면 거기엔 반드시 그만한 가치가 있어야 한다는 전제로 이 발표를 풀어간다고 함.
  5. 토큰 맥싱과 가치 맥싱 사이 간극을 줄이려면 과거 소프트웨어가 진화해온 시대별 통제 방식부터 봐야 한다고 함.
  6. SaaS 시대엔 인터페이스가 UI였고, 통제는 사용량 상한(usage cap)이나 좌석 수 제한, 등급별 정책 형태였음.
  7. 클라우드 시대로 오면서 통제 지점이 바뀌어, 요금 모델은 종량제(pay as you go)가 됐고 통제는 자동 프로비저닝과 오토스케일링 정책 형태로 옮겨감.
  8. 지금의 에이전트 시대에선 비용이 모델 호출 단위로 계산되는데, 여기엔 제대로 된 통제 지점(control plane)이 없다고 지적함.
  9. 모델 게이트웨이 형태로 하드 캡을 걸거나 모델을 낮은 등급으로 바꾸는 라우팅은 있지만, 코드가 모델을 실제로 호출하는 지점은 다루지 못한다고 함.
  10. 지난 1년간 통제되지 않은 소비가 잇따랐다며, 우버(Uber)의 AI 예산이 4개월 만에 바닥났다는 뉴스를 예로 듦.
  11. 몇 달, 심지어 며칠 만에 수억 달러를 써버린 회사들 소식도 있었다고 함.
  12. 이런 폭주 루프(runaway loop)들이 비용을 크게 늘렸는데도, 이를 막을 제대로 된 장치가 없었다고 함.
  13. 이런 상황을 보면 저장해줄 도구나 제품이 있을지부터 찾게 되지만, 발표자들은 대신 문제를 뿌리부터 푸는 시스템 설계 원칙으로 접근한다고 함.
  14. 첫 번째 원칙은 토큰이 비용의 단위라는 것임. 청구가 토큰 단위로 이뤄지니 가치도 토큰 단위로 봐야 한다는 것임.
  15. 두 번째 원칙은 비용이 LLM(거대언어모델), 즉 모델 호출 경계에서 발생한다는 것임. 그래서 바로 그 지점을 추적해야 한다고 함.
  16. 어느 에이전트의 어느 런(run)이 그 호출을 만들었는지 귀속(attribution)이 안 되면 통제할 수 없다고 함. 무엇이 잘못됐는지 큰 그림만 보일 뿐 좁혀 들어갈 수 없기 때문에, 귀속이 매우 중요한 요소라고 함.
  17. 어느 런·어느 에이전트가 비용을 만들고 있는지 알면, 그걸 멈출 정책부터 갖춰야 한다고 함.
  18. 예를 들어 루프가 과도하게 돌거나 맥락(context)이 범위 밖으로 계속 커지고 있다면, 그 자리에서 바로 해결하는 정책이 있어야지 무작정 멈추면 안 된다고 함.
  19. 최후의 수단으로만 예산 상한(budget cap)에서 멈춤(halting)이 일어나야 한다는 것이 첫 원칙들의 결론임.
  20. 지금 있는 토큰옵스(token ops)나 토큰 관리 프레임워크 대부분은 모델 요청 단위에서만 모니터링한다고 지적함.
  21. 그런 도구들은 모델 게이트웨이라서 모델 라우팅이나 하드 예산 상한을 걸 뿐이라고 함.
  22. 지금 필요한 건 요청이 아니라 런 단위 모니터링, 즉 에이전트와 도구 사이 호출 루프를 통제할 수 있는 무언가라고 함. 하나의 메인 에이전트에서 여러 서브 에이전트가 뻗어나가는 것, 맥락이 계속 커지는 것도 이 모니터링이 통제해야 할 대상이라고 함.
  23. 그래서 제안하는 플랫폼은 귀속된 런들에 걸쳐 누적 예산을 두고, 집행은 별도 단계가 아니라 호출 경로(call path) 안에서 바로 일어나게 한다고 함.
  24. 맥락이 과하게 커지면 압축(compaction)이나 캐싱이 그 자리에서 일어나야 하고, 있는 정책을 다 써보고 나서야 마지막으로 예산 상한이 걸려야 한다는 것임.
  25. 반면 오늘날 리트엘엠(LiteLLM), 포트키(Portkey), 클라우드플레어(Cloudflare) 같은 도구들은 여전히 요청 단위에서 동작한다고 지적함. 정지나 라우팅은 있어도 모델 계층에서 비용을 직접 통제하지는 못한다는 것임.
  26. 바로 이 빠진 조각, 즉 모델·에이전트 런 계층에서 다니는 것이 필요하다는 것이 이들이 만든 토큰옵스의 출발점임.
  27. 토큰옵스는 AI 에이전트를 위한 폭주 토큰 거버넌스로, 코드에 개입하지 않는 대역외(out-of-band) 평면으로 설계했다고 강조함.
  28. 이 대역외 평면은 세 모듈로 이뤄지는데, 첫째는 계측(instrumentation)임. 기본 텔레메트리와 보강(enrichment) 계층, 어떤 런이 비용을 만들었는지 귀속하는 기능이 여기 들어감.
  29. 둘째는 회계(accounting)로, 일어난 모든 런을 원장(ledger)에 누적하는 역할임.
  30. 셋째는 집행(enforcement)으로, 정의해둔 정책으로 동작을 조정(steering)하는 것과 예산이 소진됐을 때 최종 수단으로 멈추는(halt) 것 두 가지 목적을 가진다고 함.
  31. 이 구조가 런 단위에서 작동하고 문제를 그 자리에서 조정해 뿌리부터 푸는 방식이라서, 기존 도구·제품들이 못 풀던 문제를 풀 수 있다고 정리함.
  32. 이제 수심 코울이 데모를 이어받아, 토큰옵스가 오늘 어떤 모습인지 크게 세 계층으로 보여줌.
  33. 왼쪽부터 오른쪽, 위에서 아래로 보면 가장 왼쪽엔 계측 대상이 되는 자신의 에이전트 런타임이 있다고 함. 가운데는 에이전트와 통제 평면(control plane) 사이에서 데이터를 오가게 하는 브리지(bridge)이며, 오른쪽 통제 평면이 시스템의 두뇌라고 함.
  34. 브리지 계층 맨 위엔 귀속(attribution)이 있는데, 실행하는 모든 에이전트 런을 특정 사용자 차원(dimension)에 귀속시키는 역할이라고 함.
  35. 브리지의 핵심은 경계 애노테이션(boundary annotation)임. 어떤 프레임워크를 쓰든 상관없이 메서드 하나에 이 애노테이션을 붙일 수 있다고 함.
  36. 경계 애노테이션은 두 가지를 함. 하나는 입력과 출력을 추적해 통제 평면으로 띄워 원장 항목으로 기록하는 것이고, 에이전트 런 ID와 다른 속성들이 함께 붙는다고 함.
  37. 다른 하나는 통제 평면이 에이전트로 행동을 내려보내는 통로 역할을 하는 것으로, 정보가 한 방향으로만 흐르지 않는다는 것임. 통제 평면이 실시간으로 에이전트 동작을 조정해, 예산 안에 더 많은 런을 채워 넣을 수 있게 한다고 함.
  38. 예로 RAG(검색 증강 생성, 모델이 답하기 전에 외부 문서를 먼저 찾아와 그 내용을 근거로 쓰게 하는 방식) 검색 도구가 호출마다 20개 청크를 만들어 예산을 잡아먹는 상황을 듦. LLM은 관련도 순으로 정렬된 청크 중 5번째 이후는 거의 안 쓰는데, 이걸 관찰한 통제 평면이 출력을 5개 청크로 제한하는 행동(action)을 내려보낼 수 있다고 함.
  39. 이 행동은 경계(boundary)가 받아 세 번째 노드인 거버너(governor)가 실행한다고 함.
  40. 거버너는 개발자가 자기 에이전트에 어떤 행동까지 허용할지 알고 있고, 받은 행동을 비파괴적인 방식으로 적용하는 역할이라고 함.
  41. 네 번째로 랩 컴플리트(wrap complete)라는 헬퍼가 있는데, 대부분의 모델 제공자가 LLM을 메서드가 아니라 객체 형태로 주기 때문에 필요하다고 함. 경계 애노테이션을 메서드뿐 아니라 객체에도 적용할 수 있게 해주는 것이 랩 컴플리트의 역할이라고 함.
  42. 통제 평면으로 넘어가면 첫 계층은 세그먼트(segment)로, 귀속 계층에서 띄운 차원(dimension)들을 모아 코호트(비슷한 태그를 공유하는 사용자 묶음)를 만든다고 함.
  43. 예를 들어 이번 컨퍼런스에서 공유한 프리뷰 에이전트가 "코호트는 AIE 2026"이라는 차원을 띄우면, 이 태그를 기준으로 세그먼트를 만들 수 있다고 함.
  44. 세그먼트 단위로 예산을 걸 수 있어서, 모든 걸 에이전트 단위나 런 단위로만 제한할 필요가 없고 롤업이든 세밀한 통제든 거친 통제든 다 가능하다고 함.
  45. 원장(ledger)은 하나의 에이전트 런에 관한 모든 추적 기록을 한자리에 모아둔 것이라고 함.
  46. 예산(budgets)은 특정 세그먼트나 에이전트 런에 대해 시간창(time window) 동안 걸어두는 정적인 임계값이라고 함.
  47. 행동(actions)은 크게 두 갈래로, 예산을 넘기면 에이전트를 그냥 죽이는 정지형(halt)과, 죽이지 않고 동작을 조정해 예산 안에 맞추려는 조정형(steer)이 있다고 함.
  48. 이들이 가치를 더하려는 지점이 바로 이 조정형(steer) 행동이라고 강조함.
  49. 정책(policies) 계층이 이 모든 걸 묶는 자리로, 예산과 행동을 묶어 특정 세그먼트나 에이전트 런에 대해 설정하면 그게 실제로 집행되는 지점이라고 함.
  50. 코드에서 바뀌는 건 경계 애노테이션을 메서드에 붙이는 것뿐이고, 이 애노테이션이 알아서 정보를 통제 평면으로 띄워 올린다고 함.
  51. 통제 평면은 사용자 자신의 테넌트(tenant, 고객이 자기 몫으로 격리해 쓰는 인프라 구획) 안에 있어서 데이터 유출을 걱정할 필요가 없다고 함.
  52. 거버너는 인스턴스를 만들고 자기 설정(config)을 넘기기만 하면 되는데, 이 설정이 그 에이전트에 어떤 행동까지 허용할지를 미리 선언한다고 함. 그래서 통제 평면이 마음대로 아무 행동이나 못 하게 막는다는 것임.
  53. 데모에 쓸 테스트는 검색 도구에 접근해 원하는 만큼 웹을 찾아볼 수 있는 리서치 에이전트와, 그 결과로 조사 보고서를 만드는 요약 에이전트로 이뤄진 2에이전트 워크플로라고 함.
  54. 첫 번째 데모 시나리오는 "프리뷰 모드"임. 모든 정책이 그대로 실행되지만 집행(enforcement)은 일어나지 않아서, 런이 완료됐고 실패도 없었다고 함.
  55. 다만 대시보드에는 비용 예산(cost budget), 비용 가드(cost guard) 같은 정책들이 실제로 실행됐다는 기록이 남아 있었다고 함.
  56. 두 번째 시나리오는 거버넌스를 켠 것으로, 프로덕션에 넣기 전에 안전한 환경에서 가드레일을 시험하고 다듬은 뒤 임계값을 확정하려는 목적이라고 함.
  57. 이 시나리오에서는 사전 호출 비용 상한(pre-call cost cap)을 넘겨 에이전트가 즉시 죽었는데, 이게 서킷 브레이커(circuit breaker, 이상 조짐이 보이면 곧바로 실행을 끊는 안전장치) 방식의 정지(halt) 동작이라고 함.
  58. 세 번째 시나리오는 조정형(steer) 동작을 보여주는데, 이번엔 예산이 조금 더 높지만 그래도 에이전트가 시간 안에 끝내기엔 부족하게 잡혀 있다고 함.
  59. 여기서 비용 가드(cost guard)가 개입하는데, 지금까지 소비한 예산 비율과 토큰을 소비하는 속도(velocity) 두 가지를 함께 본다고 함.
  60. 이 두 값을 근거로 런이 끝나기 전에 예산을 다 쓸 것으로 예측되면, 시스템 지시문(system instructions)에 문구를 주입해 조정한다고 함. 예를 들어 "예산이 부족하니 출력을 더 간결하게 하라"는 식의 문구를 넣는 것이라고 함.
  61. 이 예시는 단순한 테스트 벤치였고, 실제로는 브라우저 유즈(browser use)와 메타지피티(metaGPT) 같은 오픈소스 저장소로 벤치마크했다고 함.
  62. 여러 반복·스트레스 테스트·쉬운 시나리오·어려운 시나리오를 두루 돌렸고, 전체 정책 세트를 켰을 때 평균 지출이 약 78% 줄었다는 결과가 나왔다고 함.
  63. 완료율을 단순 스로틀링(throttling)과 비교하면, 단순 스로틀링은 무조건 에이전트 런을 죽여버린다고 함. 반면 토큰옵스는 지출을 줄이면서도 완료율을 67%에서 96%로 끌어올렸다고 함.
  64. 이 벤치마크에 쓴 정책 카탈로그를 공개했는데, 실제 현장에서 벌어지는 여러 실패 모드를 조사해 대부분을 커버하려 했다고 함. 지출 관리(spend management), 맥락 압축·도구 출력 축소 같은 맥락 관리(context management), 루프 탐지와 진행 탐지 등을 다룬다고 함.
  65. 행동은 조정형에서 허용(allow)·변형(mutate)·주입(inject)을, 정지형에서는 단순 종료(kill)를 지원한다고 함.
  66. 이게 최종 지향점은 아니라며, 계속 쌓이는 원장 데이터를 갖고 통제 평면 안에 자가 학습(self-learning) 모듈을 두고 싶다고 밝힘.
  67. 이 모듈이 원장을 보고 "아직 못 잡는 실패 모드가 뭔지"를 스스로 물어, 놓치고 있는 폭주 비용에 맞춰 새 정책을 만들거나 기존 정책의 파라미터를 다듬게 하려 한다고 함.
  68. 발표를 마치며 공개 위키를 담은 QR코드를 보여주고, 계속 업데이트하고 있으니 궁금한 점은 발표 후에도 직접 물어봐도 된다고 밝힘.

한줄 코멘트. 이 발표의 진짜 값은 78%·96%라는 숫자보다 "멈추기 전에 먼저 조정한다"는 순서 자체에 있다고 보임 — 예산 초과를 죽이는 신호가 아니라 압축·캐싱·청크 축소로 흡수할 신호로 다룬 것임.

  1. 이 발표는 클라우드플레어 워커스(Cloudflare Workers)를 만든 켄턴 바르다(Kenton Varda)가 AI 엔지니어 컨퍼런스에서 한 것으로, 핵심 주장은 "개인용 AI 코드생성이 기존 클라우드 인프라를 깨뜨린다"는 것임.
  2. 여기서 "개인용"이라는 말이 특히 중요하다고 강조함. 모두가 자기 앱을 자기 손으로 고쳐 쓰는 미래를 원한다면 지금 소프트웨어 인프라로는 안 된다고 함.
  3. 오늘날 소프트웨어가 만들어지고 퍼지는 방식을 먼저 설명함. 개발자가 앱을 만들어 사용자에게 내려보내고, 사용자 중 일부는 기능이 부족하다며 개발자에게 요청함.
  4. 이 요청은 제품 관리자(product manager)를 거쳐 지라(Jira)에 쌓이고, 대부분 다시 꺼내지지 않는다고 함.
  5. 가끔 제품 관리자가 마음에 드는 요청을 로드맵에 올리면 개발자가 구현하는데, 각 기능은 소수 사용자만 쓰면서도 코드에 조건문을 계속 늘려 코드베이스를 지저분하게 만든다고 함.
  6. 결국 개발자는 "플러그인 시스템을 갖춘 새 아키텍처로 다시 짜자"는 결론에 이르고, 기존 기능 요청은 "플러그인 시스템이 생기면 훨씬 쉬워진다"는 이유로 미룬 채 재작성 작업을 시작한다고 함.
  7. 그렇게 세월이 가도 새 아키텍처는 완성되지 않고 어떤 기능도 구현되지 않아, 사용자들은 "이 개발자가 제품을 포기했나" 하고 실망하게 된다는 게 그가 그리는 전형적인 실패담임.
  8. AI가 이 구조에 대안을 준다고 함. 개발자가 앱 첫 버전만 만들어 사용자에게 주고, 사용자가 새 기능이 필요하면 자기 AI 에이전트에게 직접 그 기능을 짜서 자기 앱에 더해 달라고 하면 된다는 것임.
  9. 그러면 모두가 자기에게 필요한 기능만 갖게 되고, 남의 기능 요청에 발목 잡히는 사람이 없어지며, 개발자는 핵심 앱을 깔끔하게 유지할 수 있다고 함.
  10. 다만 문제는 오늘날 소프트웨어 인프라 중 이 그림에 맞게 설계된 게 하나도 없다는 것임.
  11. 애플과 구글이 지난 15년간 자사 플랫폼을 강하게 걸어잠가, 이제 모바일 앱을 만들 수 있는 회사가 다섯 곳 정도로 줄었다고 지적함.
  12. 미국에서는 총을 사는 게 자기 휴대폰에 서명되지 않은(unsigned) 소프트웨어를 까는 것보다 쉽다고 비꼬며, 구글에 그런 설치를 요청하면 24시간 뒤에 다시 오라는 경고부터 뜬다고 함.
  13. 그나마 우회로가 웹이라고 함. 웹에서는 누구나 원하는 걸 만들 수 있고, 애플과 구글이 경고하는 것과 달리 보안 재앙이 벌어지지도 않았다고 함.
  14. 하지만 웹에는 다른 문제가 있다고 함. 지난 25년간 클라우드 아키텍처가 잘못된 방향으로 발전해, 개발자가 서버 하나에 앱 한 버전을 올리면 모든 사용자가 그 같은 버전을 쓰게 되어 있다는 것임.
  15. 이게 개발자에게는 편리하지만 — 버전을 통일해 관리하기 쉬우니까 — 사용자는 자기 앱을 자기 마음대로 바꿀 수 없게 만든다고 함.
  16. 지난해부터 쏟아진 바이브 코딩(vibe coding, 사람이 자연어로 요청하면 AI가 코드를 대신 짜는 개발 방식) 플랫폼 대부분이 웹 앱을 겨냥하는데, 하나같이 이 잘못된 기존 인프라 위에 올라타 있다고 지적함.
  17. 그래서 완전히 다른 무언가가 필요하다는 게 그의 결론이고, 이것이 자신이 소개할 프로젝트의 출발점이라고 함.
  18. 자기소개를 이어감. 2017년 클라우드플레어에 합류해 워커스(Workers) 프로젝트를 시작했고 지금도 리드 엔지니어로 있으며, 워커스는 이제 수백만 개발자가 쓰고 하루 수조 건 요청을 처리하는 서버리스 앱 호스팅 플랫폼이 됐다고 함.
  19. 오늘 발표할 것은 워커스 위에서 진행해 온 사이드 프로젝트로, 앞서 말한 문제를 풀어보려는 자신의 실험이라고 함.
  20. 이 플랫폼에서 만든 앱을 직접 화면에 띄워 시연함. 바이브 코딩 프롬프트 창에 실없는 카운터 앱을 만들어 달라고 입력해 보이지만, 인터넷 연결이 안 돼 오류가 뜬다고 하며 시연 자체는 발표의 핵심이 아니라고 넘어감.
  21. 이 환경을 이해하려면 전형적인 바이브 코딩 플랫폼처럼 웹페이지에 앱을 배포하는 그림이 아니라 오피스 스위트(office suite)에 가깝게 봐야 한다고 함.
  22. 구글 독스(Google Docs)를 열면 문서 수백, 수천 개가 있고 그중 하나를 열어 고치고 공유하는 것처럼, 이 플랫폼에서는 문서 대신 가젯(gadget)이 그 자리를 차지한다고 함.
  23. 가젯마다 코드가 딸린 하나의 애플리케이션이고 서로 완전히 다른 코드를 가질 수 있다고 함. 그가 만든 예로 공동 작업 화이트보드 앱을 원샷 프롬프트로 만든 것을 듦.
  24. 스페인어 메일이 많이 오는데 자신은 스페인어를 모른다며, 그 메일만 걸러주는 작은 가젯을 만들었다고 함.
  25. 깃허브(GitHub)에서 자신이 검토해야 할 풀 리퀘스트(pull request)를 정렬해 주는 가젯도 있다고 함.
  26. 이런 것들은 그가 처음부터 바이브 코딩한 것이지만, 플랫폼에는 블루프린트(blueprint)라는 개념도 있다고 함.
  27. 누군가 가젯을 만들어 쓸모 있다고 판단하면 데이터는 빼고 코드만 뽑아 블루프린트로 만들어 다른 사람과 나눌 수 있고, 다른 사람은 그 블루프린트로 자기 가젯을 새로 만들 수 있다고 함.
  28. 문서 편집기, 칸반 보드, 슬라이드 빌더 같은 사무용 앱 블루프린트를 예로 보여줌. 슬라이드 빌더는 클라우드플레어 제품 관리자인 동료 필립(Philip)이 만든 것이라고 함.
  29. 요즘은 제품 관리자도 다들 뛰어난 엔지니어라며 농담을 던지고, 필립이 이 슬라이드 빌더를 하루 오후 만에 바이브 코딩했다고 밝힘.
  30. 이 블루프린트로 가젯을 하나 만들면 슬라이드 덱 하나가 생기고 바로 편집할 수 있다고 시연함.
  31. 중요한 점은 가젯 하나를 인스턴스화하면 그건 슬라이드 덱 하나만을 위한 것이고, 덱을 여러 개 만들려면 같은 가젯을 여러 번 인스턴스화해야 한다는 것임.
  32. 이렇게 나눈 이유는 공유 모델을 앱 자체가 아니라 플랫폼이 구현하기 때문이라고 함. 가젯 하나가 딱 공유하고 싶은 그 한 가지 대상이 되어야 플랫폼이 공유·접근 제어를 대신 처리할 수 있다는 것임.
  33. 실제로 화면 위쪽 버튼을 눌러 구글 독스 공유창과 비슷한 공유 대화상자를 보여주고, 공유 링크를 만들어 보냄.
  34. 가젯이 그 한 가지만 다루도록 강제되기 때문에, 앱 코드 자체가 공유·접근 제어를 잘못 구현할 여지가 아예 없다고 함.
  35. 이번 발표를 위해 실제로 쓴 슬라이드 인스턴스로 넘어가, 어제 기존 슬라이드가 마음에 안 들어 전부 버리고 다시 썼다고 밝히며 그건 필립도 소프트웨어도 아닌 전적으로 자기 탓이라고 함.
  36. 대화 기록을 열어 보여주며 슬라이드를 직접 손으로 고치지 않고 에이전트에게 시켰다고 함. 이 플랫폼의 모든 앱은 에이전트와 자동으로 연동된다고 함.
  37. 원하는 슬라이드 내용을 적어둔 구글 문서 링크를 클로드(Claude)에게 주면서, 필요하면 슬라이드 앱 자체에 새 기능을 추가해도 된다고 지시했다는 점이 핵심 포인트라고 강조함.
  38. 클로드가 앱 코드와 문서를 함께 읽고, 슬라이드 3에 필요한 취소선(strikethrough) 서식이 구현돼 있지 않다는 걸 스스로 파악해 그 기능을 추가했다고 함.
  39. 텍스트 가운데 정렬 기능도 마찬가지로 없었는데, 필립의 디자인 취향이 정렬 없는 쪽을 선호해 만들지 않았던 것이고 자신의 더 평범한 취향에 맞춰 클로드가 그 기능도 추가했다고 함.
  40. 더 흥미로운 사례로 슬라이드 5, 6번을 듦. 조악한 클라우드 그림을 요청했는데 이 앱은 박스와 화살표 도형만 지원할 뿐 임의의 자유 그림은 지원하지 않았다고 함.
  41. 클로드는 임의의 SVG(벡터 이미지 형식)를 박스 안에 붙여넣으면 슬라이드에 들어가는 새 기능을 스스로 추가하고, 그 기능으로 자신이 만든 SVG를 직접 붙여넣어 그림을 완성했다고 함.
  42. 이 SVG 붙여넣기 기능은 사람에게는 딱히 쓸모가 없지만 클로드 자신에게는 딱 맞는 기능이었다는 점을 짚음.
  43. 여기서 보안 문제를 제기함. SVG에는 자바스크립트가 들어갈 수 있으니 XSS(교차 사이트 스크립팅, 악성 스크립트를 심어 다른 사용자 세션을 가로채는 공격) 취약점이 생기지 않냐는 것임.
  44. 그의 답은 이 환경의 구조상 그게 문제가 되지 않는다는 것임. 화면에 보이는 앱 UI는 널 오리진(null origin) 아이프레임 샌드박스 안에서, 쿠키 접근을 포함해 바깥 세계와 아무것도 통신할 수 없게 콘텐츠 보안 정책(CSP)까지 걸어 돌아간다고 함.
  45. 이 아이프레임이 할 수 있는 유일한 일은 부모 프레임에 포스트메시지(postMessage)를 보내는 것뿐이고, 그 채널을 통해 원격 프로시저 호출(RPC) 세션을 열어 서버 코드까지 그대로 이어지게 만들었다고 함.
  46. 서버 쪽 가젯 코드는 클라우드플레어 워커스의 듀러블 오브젝트(Durable Object, 상태를 유지하며 요청을 순서대로 처리하는 워커 단위)로 돌아가고, 이 서버 코드 역시 바깥 세계와 통신하지 못하게 격리된 동적 워커 샌드박스 안에서 실행된다고 함.
  47. 결국 바이브 코딩된 클라이언트와 바이브 코딩된 서버가 서로하고만 대화하며 사용자 화면을 만들어내는 구조가 되어, XSS 버그가 있어도 새어나갈 데가 없어 실질적으로 문제 되는 보안 버그가 있을 수 없다고 함.
  48. 이런 격리 덕분에 AI가 마음대로 코드를 짜고 실행하게 둬도 안전하다는 게 이 아키텍처의 결론이라고 함.
  49. 시간이 부족해 다 못 다룬 이야기 중 하나로, 가젯이 외부 서비스와 안전하게 통신하도록 만든 별도 체계도 있다며 그것만으로도 발표 두 번은 더 할 수 있다고 함.
  50. 지금 보여준 것 중 LLM(거대 언어모델)을 뺀 모든 것이 클라우드플레어 워커스 위에서 돌아간다는 점을 강조함. 컨테이너 없이 동적 워커만으로, 데이터베이스 없이 듀러블 오브젝트만으로 복잡한 앱을 만들 수 있다는 사실을 아는 사람이 적다고 함.
  51. 게다가 이 모든 시연이 실제로는 자기 노트북에서 로컬로 돌아가고 있었다고 밝힘. 인터넷이 끊겨도 시연에 문제가 없었던 이유가 이것이고, 워커스의 오픈소스 런타임인 워커드(workerd)로 돌아간다고 함.
  52. 워커스 런타임이 오픈소스라 셀프호스팅할 수 있다는 사실도 잘 알려지지 않았다며, 자신은 이 플랫폼 안의 홈 어시스턴트(Home Assistant) 연동과 스포티파이(Spotify) 연동을 자기 집 지하실에서 돌려 집안 자동화에 쓰고 싶어 이 점에 들떠 있다고 함.
  53. 몇 달 전 이 발표를 제안할 때만 해도 이건 사이드 프로젝트였고, 발표 끝에 바로 깃허브에 코드를 공개할 계획이었다고 밝힘.
  54. 그런데 최근 몇 주 사이 클라우드플레어 내부에서 관심이 커지면서 이 프로젝트가 더 진지한 프로젝트로 격상됐다고 함.
  55. 지난 목요일 최고기술책임자(CTO)가 그를 불러, 지금 상태로 공개할 게 아니라 더 신중하고 계획적으로 릴리스를 준비해야 한다며 몇 주 미루자고 했다고 함.
  56. 발표 초록에 오픈소스 공개를 약속했던 터라 속상했지만 오늘은 공개하지 않고 곧 공개하겠다고 밝히며 발표를 마무리함.

한줄 코멘트. 클라이언트·서버를 이중으로 가둬 XSS를 원천 차단한다는 설계는 설득력 있지만, 그 안전 주장과 별개로 최고기술책임자가 공개를 미루게 한 사실은 코드 격리만으로는 못 막는 위험이 따로 있다는 뜻임.

  1. 브렌던 오도너휴(Brendan O’Donoghue)는 구글 딥마인드(Google DeepMind) 연구과학자임. 텍스트 디퓨전(text diffusion, 노이즈를 씌운 문장을 점점 걷어내며 원래 문장을 복원해 글을 만드는 방식)을 딥마인드 안에서도 더 앞선 연구 영역으로 소개함.
  2. 이미지·영상 디퓨전은 원본에 노이즈를 씌우며 훈련한 뒤, 추론 때는 순수 노이즈에서 시작해 그 노이즈를 반복해서 걷어내며 원하는 결과물을 복원하는 방식이라고 설명함.
  3. 텍스트 디퓨전도 원리는 같은데, 깨끗한 토큰(token, 모델이 다루는 글자·단어 단위 조각) 문장에서 시작해 토큰을 무작위 다른 토큰으로 바꿔 노이즈를 씌우는 식으로 훈련시킨다고 함.
  4. 이렇게 여러 노이즈 수준으로 훈련시켜서, 신경망이 문장에 섞인 오류를 고쳐내도록 학습시킨다고 함.
  5. 추론할 때는 순수 무작위 토큰으로 문장 전체를 초기화한 뒤, 신경망이 정하는 순서대로 반복해서 정보를 채워 넣어 깨끗한 문장을 복원한다고 함.
  6. 이 팀은 1년 전 제미나이 디퓨전(Gemini Diffusion)이라는 연구 데모를 냈음. 다음 토큰을 하나씩 예측하는 자기회귀(autoregressive, 이전 토큰들만 보고 다음 토큰을 순서대로 만들어가는 방식) 대신 텍스트 디퓨전으로 만든 제미나이 변형 모델이었고 약 10만 명에게 공개된 연구 프리뷰였다고 함.
  7. 당시 주요 비교 대상은 그 아키텍처의 원본인 제미나이 2.0 플래시 라이트였고, 전반적으로 품질은 비슷했으며 코드에서는 살짝 앞서고 다른 몇몇 영역에서는 살짝 처졌지만 지연시간(latency)은 훨씬 나았다고 함.
  8. 다만 1년 전 수치라 이 분야 기준으로는 "선사시대" 급이니 너무 의미를 두지 말라고 미리 못 박음.
  9. 표준적인 제미나이·젬마·GPT류 생성은 컨텍스트가 들어오면 토큰을 하나씩, 그것도 앞 토큰에 조건을 걸어 순서대로 만든다고 설명함.
  10. 반면 디퓨전은 컨텍스트가 들어오면 수백에서 수천 개일 수 있는 토큰 시퀀스 전체를 노이즈로 초기화한 뒤, 몇 번의 디노이징(denoising, 노이즈를 걷어내는) 단계에 걸쳐 그 판(canvas) 전체를 한꺼번에 다듬는다고 함.
  11. 그래서 한 번에 토큰 하나가 아니라 블록 전체를 다루되 여러 번 반복해서 처리하고, 그 과정에서 아직 만들지 않은 미래 토큰까지 참고할 수 있다고 함.
  12. 텍스트 디퓨전의 가장 큰 장점은 추론 속도, 즉 초당 더 많은 토큰을 뽑아낸다는 점이고 TPU·GPU 하드웨어를 더 잘 활용하기 때문이라고 함.
  13. GPU 안에는 큰 행렬곱을 처리하는 텐서 코어(tensor core, 연산 유닛)가 있다고 설명함. 여기 필요한 가중치·활성값·KV 캐시(key-value cache, 이전에 계산해 둔 토큰 정보를 저장해 다시 계산하지 않고 재사용하는 저장 공간)는 HBM(고대역폭 메모리, 칩 위에 붙어 있는 메모리)에서 이 텐서 코어로 실어 날라야 한다고 함.
  14. 이 메모리와 연산 유닛 사이 대역폭 통로는 매우 좁아서, GPU·TPU 모두 연산 능력(flops)에 비해 대역폭이 크게 부족하다고 함. 대역폭을 늘리는 건 비싸고 연산 능력을 늘리는 건 상대적으로 쉽다고 함.
  15. 그래서 실어 나른 데이터 한 단위당 연산을 더 많이 할수록 유리하고, 자기회귀 모델을 서빙할 때는 바로 이 대역폭에 발목 잡힌 메모리 병목(memory bound) 상태라고 함.
  16. 자기회귀 모델은 토큰 하나를 만들 때마다(배치 크기 1이라면) 신경망 전체와 KV 캐시를 통째로 실어 날라야 하고, 다음 토큰을 만들 때 또 그걸 반복한다고 함.
  17. 텍스트 디퓨전은 예컨대 256개 토큰을 만드는 데도 매번 전체를 실어 나르는 건 같지만, 그 횟수를 토큰 개수보다 훨씬 적게 줄일 수 있다고 함.
  18. 256개 토큰을 24번의 순전파(forward pass, 신경망에 입력을 통과시켜 출력을 얻는 한 번의 연산)로 만든다면 자기회귀보다 메모리 전송이 10분의 1로 줄고, 정말로 메모리에 발이 묶여 있다면 속도도 약 10배 빨라진다고 함.
  19. 이게 텍스트 디퓨전이 자기회귀보다 지연시간이 훨씬 짧은 진짜 하드웨어적 이유라고 함.
  20. 실제로 제미나이 디퓨전 데모는 질의 길이에 따라 다르긴 해도 꽤 꾸준히 초당 약 2000개 토큰을 냈다고 함.
  21. 문장이 길어질수록 프리필(prefill, 응답을 만들기 전에 주어진 컨텍스트를 미리 처리하는 단계) 비중이 줄어 긴 시퀀스에서 더 빠른 토큰 속도를 살릴 수 있지만, 토큰 하나만 만드는 상황이면 프리필 비용에 그대로 지배된다고 함.
  22. 이 초당 2000토큰이라는 수치는 프리필까지 포함해서 실제로 웹 브라우저에 뜬 순수 토큰 기준이었다고 밝힘.
  23. 하지만 가장 큰 단점은 대형 배치(batch)에서 처리량(throughput)이 떨어진다는 점이라고 함.
  24. 자기회귀 모델은 질의 하나하나는 느려도 많은 질의를 한 배치로 묶어 GPU에 밀어 넣으면 TPU를 잘 활용해 많은 질의를 동시에 처리할 수 있어 비용을 낮게 유지한다고 함.
  25. 반면 텍스트 디퓨전은 같은 데이터에 순전파를 여러 번 반복하기 때문에 연산 한도(compute threshold)에 더 일찍 도달하고, 개개인에게는 지연시간이 짧아도 전체 처리량은 낮아 서빙 비용이 더 든다고 함.
  26. 요즘 클로드(Claude)를 써봤다면 알겠지만 처리량 문제가 실제로 불거지고 있고, 다들 처리량을 매우 신경 쓰는 시기라 이 단점 때문에 아직 누구도 텍스트 디퓨전을 대형 모델에 앉히지 않고 있다고 함. 지연시간은 훨씬 낮아도 서빙 비용이 너무 비싸다는 것임.
  27. 텍스트 디퓨전의 또 다른 장점으로 양방향 어텐션(bidirectional attention, 과거뿐 아니라 아직 만들지 않은 미래 토큰까지 함께 참고하는 방식)을 듦. 자기회귀 모델은 트랜스포머 안에서 과거만 보는 인과적(causal) 어텐션에 갇혀 있다고 함.
  28. 이 양방향성 덕분에 미래에 자신이 뱉을 토큰을 미리 참고해 추론 중간에 스스로 오답을 발견하고 되돌아가 고치는 자기 수정(self-correction)이 가능하다고 함.
  29. 이걸 보여주려고 작년 구글 I/O 데모를 소개함. "81의 제곱근 곱하기 3분의 2의 제곱 더하기..." 같은, 쉬워 보이지만 여러 모델이 자주 틀리는 문제였고 정답은 39였다고 함.
  30. 제미나이 디퓨전에 이 프롬프트를 넣으면, 순전파 1번만 거친 시점에는 "답 = 60"이라고 일단 틀린 값을 내놓고 풀이를 시작한다고 함.
  31. 순전파 2번째에는 60을 49로 고치며 풀이를 조금 더 진행하고, 3번째 순전파에서는 풀이를 끝까지 마쳐 "36+3=39"로 정답을 맞히고 앞서 써 둔 답까지 39로 되돌아가 고쳤다고 함.
  32. 60, 49로 두 번 틀렸지만 풀이를 끝낸 뒤 처음 써 둔 답으로 되돌아가 고쳤다는 것이고, 이후 몇 번의 순전파를 더 거쳐 나머지 표현을 다듬는다고 함.
  33. 당시 훨씬 더 큰 모델들도 이 문제를 틀렸다며, 그 무렵 새로 나온 GPT-4o와 제미나이 2.5 플래시 둘 다 같은 프롬프트에 오답을 냈다고 함.
  34. GPT-4o는 처음에 40이라고 답한 뒤 풀이를 거쳐 39가 맞다는 걸 알아내고는 "40이 아니라 39로 실수했다"고 덧붙였다고 함. 결국 한 응답 안에 처음 오답과 정정을 같이 남긴 셈이라고 함.
  35. 제미나이 2.5 플래시는 42라고 답한 뒤 끝까지 정정하지 않고 "36+3은 42"라며 오답을 풀이에 그대로 끌고 갔다고 함.
  36. 두 모델 다 제미나이 디퓨전보다 훨씬 큰 모델인데도 이랬다며, 이건 자기회귀 모델의 구조적 약점이지 텍스트 디퓨전은 애초에 갖지 않는 문제라고 주장함. 다만 최신 추론(reasoning) 모델을 쓰면 이 문제를 다른 방식으로도 해결할 수 있다고 덧붙임.
  37. 세 번째로 꼽은 장점은 동적 연산(dynamic computation)임. 추론 때 순전파 횟수, 즉 계산 예산을 늘려주면 결과가 대체로 계속 좋아진다고 함.
  38. 딱 단조증가는 아니지만 대략 단조적으로, 내부에서 지켜보는 코딩 평가 6종 모두 디노이징 스텝 수가 늘수록 품질이 오르는 경향을 보였다고 함. 답이 거의 다 맞아도 한 번 더 들여다보고 남은 실수를 잡아낼 수 있기 때문이라고 함.
  39. 여기서 한 발 더 나아간 게 적응적 연산(adaptive computation)인데, 모델 스스로 언제 끝낼지 판단하도록 훈련시켜서 쉬운 응답에는 연산을 적게, 어려운 응답에는 많이 쓰게 만든다고 함.
  40. 예로 원주율 소수점 100자리를 물으면 겉보기엔 짧은 응답 같지만 실제로 100개 토큰인데도 단 4스텝 만에 끝난다고 함. 이미 외운 값을 그대로 뱉으면 되는 쉬운 문제이기 때문이라고 함.
  41. 조금 더 어려운 피즈버즈(FizzBuzz) 코드 작성은 18번의 순전파가 걸렸고, 양자역학을 한 문단으로 설명하는 문제는 31번의 디노이징 스텝이 걸렸다고 함.
  42. 대체로 어려운 평가일수록 시간이 더 걸리는데, GPQA 다이아몬드(GPQA Diamond, 대학원 수준 과학 지식을 묻는 어려운 평가셋)는 이 모델 크기 기준으로 꽤 어려운 편이라 응답에 오래 걸렸다고 함.
  43. 반대로 기초적인 파이썬 프로그램 위주인 MBPP(Mostly Basic Python Problems)는 응답 시간이 매우 짧았고, 이 시간 배분은 전적으로 모델 스스로 정한 것이라고 함.
  44. 마지막 장점은 빠른 인플레이스(in-place) 편집임. 이미지 디퓨전에서 사진 일부를 지우고 프롬프트를 주면 지워지지 않은 부분의 맥락을 이용해 그 자리를 그럴듯하게 채워 넣는 것과 같은 성질이라고 함.
  45. 자기회귀 이미지 생성 모델은 좌상단부터 우하단까지 래스터 순서로 픽셀을 채우지만, 디퓨전은 이미지 전체를 한꺼번에 보고 노이즈를 걷어내기 때문에 모든 픽셀이 서로를 참고하며 빠진 부분을 프롬프트에 맞게 채울 수 있다고 함.
  46. 텍스트에서도 비슷한 걸 보여주는 데모를 소개함. 코드에 "여기 버그가 있다, 고쳐달라"고 하면 전체를 다시 쓰지 않고 인덱스 하나를 살짝 고치는 식으로 정확히 그 자리만 편집한다고 함.
  47. "문서화를 추가해 달라"고 하면 토큰을 처음부터 순서대로 다시 만드는 게 아니라 편집 절차를 거쳐 필요한 자리에만 내용을 채워 넣는다고 함.
  48. 더 일반적인 텍스트로도 되는데, 이야기 한 편을 주고 "중간 문단을 추가해 달라"고 하면 첫 문단과 셋째 문단을 함께 보고 있기 때문에 전체 흐름에 맞는 중간 문단을 채워 넣을 수 있다고 함.
  49. 이제부터는 저지연이 단순히 같은 걸 더 빠르게 하는 게 아니라 아예 새로운 응용을 열어준다는 걸 보여주는 사내 데모들을 소개함.
  50. 첫 데모는 위키피디아인데, HTML까지 포함해 페이지 전체가 그 자리에서 모델이 생성한 것이고, 링크를 클릭하면 지연시간이 충분히 낮아서 진짜 위키피디아처럼 즉시 페이지가 채워진다고 함.
  51. 비슷한 방식으로 만든 레딧(Reddit) 데모도 있는데, 모든 댓글이 봇이 지어낸 가짜 댓글이고 상어를 주제로 한 서브레딧처럼 원하는 어떤 커뮤니티도 즉석에서 지어낼 수 있다고 함.
  52. 제미나이 디퓨전 자체는 이미지 생성 모델이 아니라서, 이미지 쪽은 당시 자기네 팀의 최신 이미지 생성 모델(정확한 이름은 발표자도 확신하지 못했고, 나노 바나나 이전 모델이라고만 언급함)과 짝지어 썼다고 함.
  53. 이미지 생성이 텍스트보다 느리기 때문에 텍스트와 댓글이 먼저 뜨고 이미지는 1분쯤 뒤에 따라붙으며, 그 뒤로는 실제 사용자가 있는 진짜 사이트처럼 계속 상호작용할 수 있다고 함.
  54. 발표자가 가장 좋아한다고 밝힌 데모는 클릭할 때마다 다음 화면을 그 자리에서 생성하는 운영체제(OS)인데, 리드미를 열면 텍스트를, 바탕화면으로 돌아가면 그 화면을 매번 새로 만들어내 진짜 운영체제처럼 보인다고 함.
  55. 트위터에서 어떤 사람이 제미나이 디퓨전 웹페이지(API가 아니라 웹 UI)로 음성 라이브 코딩을 한 데모도 소개함. 팀 밖 사람이 만든 것이라 마음 놓고 보여줄 수 있었다고 함.
  56. 그 사람이 음성으로 "할 일 앱을 만들어라, 무작위 할 일 10개를 추가해라, 완료 상태를 넣어라, 4개를 완료로 표시해라, 이름·상태로 정렬되게 해라, 다크 모드로 바꿔라"까지 시켰고, 이 전체가 15초 만에 끝났다고 함.
  57. 질의응답에서 훈련 데이터는 자기회귀 모델과 똑같은 데이터를 쓰되 알고리즘만 좀 바꾼다고 밝힘.
  58. 증류(distillation, 큰 모델의 지식을 작은 모델로 옮겨 압축하는 방법)도 가능하다고 했지만 공개된 사례는 잘 모르겠다고 했고, 조만간 뭔가 공개할 예정이라고 언급함.
  59. 모델이 커질수록 같은 결과를 내는 데 필요한 디노이징 스텝 수는 오히려 줄어드는 경향이 있어서, 모델이 커져도 서빙 비용이 그만큼 비례해서 늘지는 않는다고 함.
  60. 디퓨전 모델의 가격 정책은 아직 정해지지 않았다며 "나는 연구과학자라 거기까지는 모른다"고 답함.
  61. 응답 길이 제어는 보통 창(window) 길이를 고정하고 그 안에서 반복하는 블록 단위 자기회귀 방식이 표준이지만, 응답 길이를 예측하는 헤드를 따로 둘 수도 있다고 함.
  62. 창 길이를 고정해도 전체 출력이 그 길이로 제한되는 건 아니고, 더 길게 써야 하면 창을 여러 개 자기회귀적으로 이어 붙인다고 함. 다만 한 번 확정된 창은 다시 돌아가 고치지 않고 그대로 둔다고 함.
  63. 디노이징 스텝 수에 미리 상한을 걸어 지연시간을 예측할 수 있느냐는 질문에는, 앞서 보여준 예시들도 전부 상한이 걸려 있었지만 대개 그 상한에 닿기 전에 먼저 끝났다고 답함.
  64. 프리필 방식은 자기회귀와 같고, 그 뒤 생성 단계만 512나 1024, 32처럼 정한 크기의 블록 단위로 자기회귀적으로 진행된다고 설명함.
  65. 지금 나온 텍스트 디퓨전은 전부 토큰을 넣고 토큰을 뱉는 이산(discrete) 확산이고, 잠재 공간(latent space)에서 하는 연구도 있긴 하지만 문헌 대부분은 여전히 이산 디퓨전이라고 함.
  66. 지금 단계에서 자기회귀와 텍스트 디퓨전은 품질이 아니라 용도가 다르다고 정리함.
  67. 온디바이스(on-device) 응용, 예컨대 알파벳(Alphabet) 생태계 안의 로봇이나 휴대폰처럼 수천 개 질의를 한 배치로 묶을 필요가 없는 곳에서는 처리량 걱정 없이 지연시간이 가장 낮은 모델을 고르면 된다고 함.
  68. 청중이 "품질을 프런티어 모델 수준으로 올릴 수 있냐"고 묻자, 지금 걸림돌은 품질이 아니라 대형 배치 서빙에서의 처리량이라고 다시 짚음.
  69. 지금도 자체 연구에서는 프런티어 모델과 거의 같은 수준의 품질을 내고 있다고 확인해줌.
  70. 검증 가능한 보상이 있는 추론(reasoning) 과제에 강화학습(RL, reinforcement learning, 모델이 시행착오와 보상으로 학습하는 방식)을 적용하는 것도 가능하다며, 알고리즘만 바꾸면 된다고 함.
  71. 디퓨전과 자기회귀를 섞어 쓰는 것도 가능하다고 짧게 답함.
  72. 순수 노이즈 대신 더 작은 모델의 출력으로 초기화해서 스텝 수를 줄일 수 있냐는 질문에는, 노이즈를 기대하도록 훈련된 모델에 작은 모델의 출력을 넣으려면 그 형태로 다시 훈련시켜야 해서 복잡도만 늘어나기 때문에 보통 하지 않는다고 답함.

한줄 코멘트. 지연시간 우위는 데모로 확실히 증명했지만 처리량 열세는 그대로 인정한 발표라, 당장은 클로드급 서비스를 대체하기보다 온디바이스처럼 배치가 필요 없는 자리부터 먼저 붙을 모델임.

  1. 발표자는 앤트로픽(Anthropic) 소속 포워드 디플로이드 엔지니어(forward deployed engineer, 고객사에 직접 나가 기술을 붙이는 엔지니어) 카란 삼파스(Karan Sampath)임. 미국 밖에서는 처음 맡은 자리라고 밝힘.
  2. 원제목은 "엔터프라이즈에서 MCP를 어떻게 보는가"였지만, "게이트웨이 하나면 된다"는 제목이 더 와닿는다고 함.
  3. MCP(모델 컨텍스트 프로토콜, LLM이 외부 데이터·도구에 표준화된 방식으로 접속하게 해주는 개방형 규격)는 앤트로픽이 만든 공개 표준이라고 함.
  4. 공식 레지스트리에 이미 서버 수천 개가 올라와 있고, 지난 1년 사이 빠르게 늘었다고 함.
  5. 엔터프라이즈가 MCP를 쓰려 하면 부딪히는 첫 번째 문제는 관측성(observability)이라고 함. 누가 내 MCP를 쓰는지, 올바른 사람이 쓰고 있는지, 프로토콜 어느 부분이 제대로 안 도는지가 기업 입장에서 완전히 안 보인다고 함.
  6. 두 번째는 접근 통제라고 함. 어떤 서버를 누구에게 열어줄지, 도구를 어떤 그룹에만 허용할지를 정하기가 지금은 매우 어렵다고 함.
  7. 예로 관측성 MCP라면 회사 전체가 뭐가 실패했는지 들여다볼 수는 있어야 하지만, 실제로 값을 바꾸고 대시보드를 고치는 권한은 일부에게만 줘야 하는데 지금 구조로는 어렵다고 함.
  8. 세 번째는 보안이라고 하며, 이 세 문제(관측성·접근 통제·보안)를 머리 셋 달린 히드라에 비유함.
  9. 보안은 두 갈래라고 함. 하나는 MCP 서버 자체가 안전한지, 데이터 유출이 안 일어나는지, 도구가 내부·외부 인프라에 해를 끼치지 않는지 검증하는 문제라고 함.
  10. 다른 하나는 신뢰할 수 없는 원격 클라이언트가 기업의 민감한 데이터에 접근하는 걸 막는 문제라고 함. API 시절에는 풀었던 문제인데 MCP에서는 아직 좋은 답이 없다고 함.
  11. 레지스트리가 유용하다는 데는 이견이 없지만, 엔터프라이즈 입장에서는 그것만으로 충분하지 않다고 함.
  12. MCP는 원래 엔터프라이즈에 훨씬 유용하도록 설계된 프로토콜이라고 함. 그런데 인증·접근 통제·관측성·자격 증명(credential) 관리처럼 그 설계가 열어둔 부분을 아직 아무도 제대로 채우지 않았다는 게 역설이라고 짚음.
  13. 지금 기업 현장에서는 클로드 코드(Claude Code) 같은 코딩 에이전트가 퍼지면서 모든 팀이 MCP를 직접 만들기 시작했지만, 정작 배포는 못 한다고 함.
  14. 배포해도 그 MCP가 필요한 도구를 못 쓰거나 올바른 접근 권한을 못 받는 일이 흔하다고 함.
  15. 보안팀은 업무가 넘쳐서 어떤 MCP를 통과시키고 어떤 걸 막을지 판단할 여력이 없다고 함.
  16. 그 결과 경영진은 왜 우리 MCP가 제대로 안 돌고 에이전트가 기대만큼 효과를 못 내는지 묻게 된다고 함.
  17. 소수의 MCP 도구에만 머무는 이 문제가 프로토콜 전체를 옥죄고 에이전트 성능을 갉아먹는다고 함.
  18. 사소해 보이는 이 마찰들을 풀려고 시간을 들일 가치가 충분하다고 강조함. 게이트웨이가 더 나은 해법이라고 보는 이유를 직관부터 설명함.
  19. 이제는 거의 모든 팀이 코딩 에이전트 덕분에 도구 정의와 접근 통제까지 이해하는 MCP 서버를 직접 잘 만들 수 있는 시점이라고 함.
  20. 이렇게 팀마다 알아서 만들게 하려면 보안팀이 신뢰의 뿌리(root of trust)를 하나 세워야 한다고 함. 플랫폼 하나만 공인하면 된다는 뜻이라고 함.
  21. 이 발표에서 딱 한 장만 기억해야 한다면 이 슬라이드라고 강조함. 게이트웨이라는 구현체보다 "신뢰의 뿌리를 하나로 모은다"는 직관 자체가 핵심이라고 함.
  22. 이렇게 하는 기업은 내부와 외부 사례 모두에서 MCP 사용량을 마음껏 늘릴 수 있었고, 그만큼 에이전트가 발휘하는 힘도 커졌다고 함.
  23. MCP 사용이 기하급수적으로 느니까 좋은 MCP 하나가 회사 안 모든 에이전트에 도움이 되는 파급 효과가 있다고 함.
  24. 게이트웨이를 단순하게 정의하면, MCP 서버들(수백 개까지 늘어날 수 있음)과 MCP 클라이언트 사이에 놓인 중간 계층이라고 함.
  25. 다이어그램 자체는 일부러 단순하게 그렸고 채워 넣을 부분이 많다며, 정작 중요한 건 게이트웨이에서 뭘 얻어내려 하는지라고 함.
  26. 얻고 싶은 건 인가(authorization)·인증(authentication)·관측성이라고 함. 그리고 신뢰할 수 없을 수도 있는 MCP 클라이언트와 내부 사이의 안전한 연결, 새 MCP 서버를 쉽게 올리고 배포하는 방법도 필요하다고 함.
  27. 이 다섯 가지를 게이트웨이가 떠맡으면 새 MCP 서버를 만드는 팀은 오직 업무 로직만 신경 쓰면 된다고 함.
  28. 예로 계약서를 검토하는 법무팀은 계약이 들어오면 뭘 봐야 하는지, 레드라인을 어떻게 긋는지, 누구에게 에스컬레이션하는지만 정하면 된다고 함. 누가 접근하는지, 얼마나 자주 접근하는지, 확장이 되는지는 법무팀이 신경 쓸 필요가 없다고 함.
  29. 이런 세상에서는 법무팀이 기술팀에 다시 요청하지 않고 MCP 서버를 스스로 만들 수 있다고 함. 게이트웨이는 그 세상을 떠받치는 기본 인프라라고 함.
  30. 게이트웨이 안에 보통 들어가는 요소를 소개하되, 이게 정답이나 필수 목록은 아니라고 미리 못박음.
  31. 인증하는 방법, 역할(role) 기반 접근 통제, MCP 클라이언트가 오직 게이트웨이만 보게 하고 게이트웨이가 개별 MCP 서버로 라우팅하는 프록시 구조가 필요하다고 함.
  32. 이때 개별 MCP 서버는 게이트웨이만을 유일하게 신뢰하는 종단점(endpoint)으로 취급한다고 함.
  33. 암호화된 안전한 연결인 터널, 회사 내부 MCP 서버들을 모은 하위 레지스트리도 필요하다고 함.
  34. 마지막으로 게이트웨이용 CLI(명령줄 도구) 같은 추가 도구가 필요하다고 함. 사람이 아니라 클로드 코드 같은 에이전트가 이 CLI를 이해해서 새 MCP 서버를 쉽게 만들 수 있어야 한다는 뜻이라고 함.
  35. 이 다섯 요소를 갖춰두면 새 MCP 서버를 만들려는 사람은 게이트웨이 CLI로 여기에 붙기만 하면 되고, 나머지는 온전히 자기 MCP 서버에만 집중할 수 있다고 함.
  36. 이런 투자는 한 번만 하면 되고 유지보수 부담이 크지 않으며 에이전트로도 충분히 할 수 있어서, 그 뒤로 이어지는 효과가 여럿이라고 함.
  37. 게이트웨이가 주는 접근·인증은 회사가 이미 쓰는 자체 IDP(신원 공급자)를 꽂아 넣는 식으로 쉽게 해결된다고 함.
  38. 사용자와 에이전트를 함께 아우르는 위임된 신원(delegated identity) 개념이 내년쯤 중요해질 거라고 봄. 에이전트마다 새롭고 독자적인 신원 정의가 필요해질 거라는 뜻이라고 함.
  39. 모든 에이전트와 MCP를 한 접근 통제 패널에서 다룰 수 있고, 팀 단위인지 개인 사용자 단위인지 다른 직원 단위인지에 따라 범위를 나눠 설정할 수 있다고 함.
  40. 관측성은 단순히 어떤 MCP가 쓰였는지 사용량만 보는 게 아니라고 함. 도구가 어떻게 정의돼 있는지까지 보고 싶어 한다는 점이 미묘한 지점이라고 함.
  41. MCP 프로토콜 자체가 워낙 빠르게 바뀌는 중이라, 어떤 도구가 실제로 회사를 떠받치고 있는지 파악해서 에이전트들의 필요에 맞게 계속 고쳐가야 한다고 함.
  42. 이렇게 말하면 너무 좋은 얘기로만 들릴 수 있다면서도, 직접 한번 시도해보라고 권함.
  43. 게이트웨이를 갖추고 나면 거저 따라오는 이점들이 있다고 함. 첫째는 새 표면(surface)을 아주 쉽게 추가할 수 있다는 점이라고 함.
  44. MCP 서버들을 클로드닷에이아이(claude.ai)에도, 클로드 코드(Claude Code)에도 한 번의 연결로 붙일 수 있는데, 전부 같은 게이트웨이를 보고 있기 때문이라고 함.
  45. 반대로 MCP 서버 40개를 따로 두고 그중 일부만 특정 클라이언트에 맞춰 설정돼 있는 세상과 비교하면 차이가 크다고 함.
  46. 게이트웨이가 있으면 어떤 새 표면이 나와도 흔들리지 않는다고 함.
  47. 둘째는 훨씬 더 안전한 연결이라고 함. 지금 MCP 서버는 내부 민감 데이터에 접근하는 경우가 많아서 다른 클라이언트로 데이터가 새어 나가지 않을지 기업들이 불안해한다고 함.
  48. 게이트웨이가 있으면 MCP 서버와 클라이언트 사이를 완전히 암호화하고, 어떤 데이터가 나가는지에 대한 신뢰의 뿌리를 확보하는 데 더 투자할 수 있다고 함.
  49. 지금까지는 기업이 실제로 못 쓰는 장난감 같은 데이터로만 MCP 서버를 만들어봤다고 함. 지수적인 가치를 뽑아내려면 이 안전한 연결이 꼭 필요하다고 함.
  50. 셋째는 더 빠른 반복(iteration)이라고 함. 팀이 완전히 분산돼 일하면 각자 워크플로를 훨씬 빨리 다듬을 수 있다고 함.
  51. 법무팀이 자기 MCP를 매번 보안 심사 없이 빠르게 고치고 반복할 수 있다면 그 효과가 계속 쌓인다고 함.
  52. 넷째는 더 표준화된 프리미티브(primitive, 기본 구성 요소)라고 함. 새 MCP 서버는 회사가 정한 프리미티브를 따라야 한다고 함.
  53. 게이트웨이는 "이게 우리 표준 절차고 원하는 프리미티브고 기대하는 도구고, 이건 원하지 않는다"는 걸 한 번에 정할 수 있는 장치라고 함.
  54. 다섯째는 자격 증명(credential)을 갈아 끼울 수 있다는 점이라고 함. 지금은 MCP 서버마다 한 가지 인증 방식만 받는다고 함.
  55. 그래서 회사 전체용, 팀용, 서비스 계정용을 섞어 쓰기가 어렵다고 함. 게이트웨이가 있으면 새 MCP 서버가 여러 자격 증명을 지능적으로 붙였다 뗐다 하기 쉬워진다고 함.
  56. 여섯째는 확장성이라고 함. MCP 서버 40개를 에이전트 수십에서 수백, 수천, 수십만 명 규모까지 늘려야 한다면 유지하기 매우 어려운 표면이 된다고 함.
  57. 게이트웨이가 요청을 받아 지능적으로 나눠 처리해주면 각 팀은 자기 일에만 집중할 수 있는 훨씬 나은 자리에 선다고 함.
  58. 이건 앤트로픽만의 주장이 아니라 오픈소스에도, 사내 자체 구축 사례에도 이미 있다고 함. 자신이 매일 하는 일이 이 게이트웨이 구축을 돕는 일이라고 밝힘. 자기 회사 서비스를 소개하는 대목임.
  59. 마지막으로 큰 그림을 짚음. 에이전트 하네스(harness, 에이전트를 실행하고 통제하는 틀)를 데이터가 있는 자리에서 떼어놓고 싶다고 함.
  60. 앞으로 표면은 계속 늘고 에이전트도 폭발적으로 늘 텐데, 그 에이전트들이 데이터와 MCP 구조에 단단히 묶여 있으면 안 된다고 함.
  61. 에이전트(그림 왼쪽 상자) 수만 개가 있어도, 오른쪽에 있는 데이터·MCP 구조가 그 에이전트 형태에 맞춰 고정될 필요가 없어야 한다는 뜻이라고 함.
  62. 최근 실제 사례로, MCP 게이트웨이가 있으면 새로 나온 클로드 매니지드 에이전트(Claude managed agents)에도 바로 연결할 수 있다고 함. 사내에서는 클로드 에이전트 SDK로 직접 붙여 쓸 수도 있다고 함.
  63. 기업 입장에서 이 가치는, 어떤 에이전트는 사내에 두고 어떤 에이전트는 외부에 맡길지를 언제든 바꿀 수 있는 결정으로 만들어준다는 데 있다고 함.
  64. 게이트웨이는 그 선택과 무관하게 그대로 남는다고 함. 앞으로 다가올 다양한 에이전트 수요에 맞출 유연성을 사는 투자라고 정리함.
  65. 그렇게 되면 지금 당장 에이전트 설계를 깊이 고민하지 않아도 되고, 대신 게이트웨이의 프리미티브를 확실하게 다듬는 데 힘을 쏟을 수 있다고 함.
  66. 마무리로 세 가지를 요약함. 첫째, 공통 인프라에 투자하고 각 팀이 MCP를 따로 만들지 말고 공통 기반 위에서 만들게 하라고 함.
  67. 둘째, 게이트웨이로 안전한 연결을 만들면 신뢰의 뿌리를 세울 수 있다고 함.
  68. 셋째, 이 방향이 결국 에이전트 하네스를 데이터 계층에서 떼어놓는 세상으로 간다고 함.

한줄 코멘트. "신뢰의 뿌리를 하나로 세운다"는 직관은 설득력 있지만, 그 뿌리를 어떻게 감사하고 검증할지는 구체적으로 안 밝히고 결국 앤트로픽이 도와주겠다는 영업으로 마무리됨.

  1. 발표자는 구글 AI 엣지(Google AI Edge) 소속 라이트RT(Lite RT) 제품 매니저 친탄 파리크(Chintan Parikh)이고, 동료 한 명이 질의응답 시간에 함께한다고 밝힘.
  2. 시작하면서 청중에게 엣지(기기 안) 배포를 이미 하고 있거나 관심 있는지 손을 들어보라고 물었고 상당수가 손을 들었다고 함.
  3. 발표 순서는 신모델 소개, 엣지 활용 사례, 갤러리 앱의 새 기능, 배포 스택, 크로스플랫폼 지원 순으로 간다고 밝힘.
  4. 구글 딥마인드가 최근 제미마(Gemma) 4를 내놓았고, 이 발표는 기기에 올리는 2B·4B급 엣지 모델(E2B·E4B)에 초점을 맞춘다고 함.
  5. 제미마 3 계열에는 2억7000만 파라미터까지 내려가는 더 작은 모델도 있고, 파인튜닝하려는 사람을 위해 허깅페이스(Hugging Face) 페이지에 올려뒀다고 함.
  6. 제미마 4의 큰 변화는 챗봇형 응답에서 추론 능력을 갖춘 더 자율적인 에이전트로 넘어간 것이라고 설명함.
  7. 엣지에서 돌리는 이점으로 지연시간(배경 교체 필터·실시간 영상통화), 프라이버시(민감한 문서 요약), 오프라인 사용, 비용 네 가지를 듦.
  8. 비용 얘기하면서 이 AI 엔지니어 행사에서도 토큰 사용량 불만을 발표하는 사람이 많았다며, 온디바이스는 클라우드와 섞어 쓰는 하이브리드 방식으로 균형을 잡을 수 있다고 함.
  9. E2B는 램 사용량이 대략 1~2GB로, 음성 인터페이스나 요약처럼 저지연 로컬 처리에 맞는다고 함.
  10. E4B는 더 무거워서 노트북이나 IoT 기기 같은 큰 플랫폼용이고, 이 램 요구량은 양자화(모델 크기를 줄이는 압축 방식)를 거친 뒤 기준이라고 함.
  11. 이번 E2B·E4B의 새 기능으로 함수 호출(도구 호출) 내장 지원을 꼽으며, 기기 안에서 추론하면서도 바깥의 다른 API를 호출하는 경로가 있다고 함.
  12. 구조화된 JSON 출력도 프롬프트 설계로 흉내 낸 게 아니라 모델 구조 자체에 내장된 기능이라고 밝힘.
  13. 사고 사슬(생각 과정을 보여주는) 씽킹 모드도 새로 생겼고, 갤러리 앱에서 모델이 어떤 사고 과정을 거치는지 보여준다고 함.
  14. 이 모델들은 하드웨어 자체에 맞춰 최적화돼 있어 여러 플랫폼과 하드웨어에서 매끄럽게 돌아간다고 강조함.
  15. 모델은 허깅페이스 페이지에 이미 올라와 있고 전부 아파치(Apache) 2.0 라이선스라 내려받아 바로 쓸 수 있다고 함.
  16. 이어서 3층에서 시연 중인 갤러리 앱으로 실제 활용 사례를 보여줬고, 발표 뒤 데모 부스에서도 더 볼 수 있다며 QR코드를 안내함.
  17. 갤러리 앱은 에이전트 스킬 능력, 오디오 받아쓰기(scribe), 이미지에게 묻기(ask image), 채팅까지 전부 기기 안에서 돌아간다고 함.
  18. 이 앱은 구글이 모델의 능력을 체험해 보는 놀이터로 만든 것이고, 각 기능마다 예제 코드가 있어 그대로 가져다 쓰거나 앱을 통째로 포크해 자기 서비스를 만들 수 있다고 함.
  19. 새로 생긴 세 축은 음성 에이전트·로컬 에이전트 능력과 프라이버시 중심 기능이라고 밝힘.
  20. 첫 사례는 지식 보강으로, 위키백과를 검색해 백과사전형 질문에 답하는 스킬을 이미 앱에 넣어뒀다고 함.
  21. 둘째 사례는 무드 트래커로, "점수 9점과 코멘트로 일기를 써줘"라고 시키면 "8시간 잤고 오늘 에이미와 놀 생각에 설렌다" 같은 입력을 받아 수면 시간 추세를 정리해 보여준다고 함.
  22. 이어서 "최근 7일간 기분 추세를 분석해줘"라고 시키자 기기 안에서 바로 만들어내는 걸 보여주며, 이런 추론·사고 능력이 새 모델에서 강해졌다고 설명함.
  23. 셋째 사례는 사진을 보내면 이미지 이해를 거쳐 그 분위기에 맞는 음악을 생성하는 것으로, "이 사진 분위기에 맞는 음악 만들어줄 수 있어?"라는 요청을 몇 초 만에 처리한다고 함.
  24. 이런 스킬은 앱을 나가지 않고 앱 안에서 직접 만들 수 있고, 만드는 방법도 앱 안에 안내돼 있다고 함.
  25. 마지막 사례는 동물 울음소리를 설명하는 앱으로, 여러 앱과 사용자를 오가며 더 복잡한 워크플로를 다루는 예라고 함.
  26. 이 사례에서는 CPU·GPU를 선택할 수 있고 곧 NPU 지원도 붙을 예정이라, 원하는 가속기를 골라 쓸 수 있다고 함.
  27. 이 소리는 순전히 사람이 준 프롬프트만으로 생성한 것이고, 스킬을 미리 만들어 넣어 기기 안에서 돌아가게 한 결과라고 설명함.
  28. 사용자들이 직접 만든 스킬을 올리고 공유하는 깃허브(GitHub) 저장소가 따로 있고, 샘플 앱 자체도 오픈소스라 포크해 고쳐 쓸 수 있다고 함.
  29. 스킬 만드는 법을 안내하는 QR코드도 따로 있어서 원하는 사람은 바로 시작할 수 있다고 함.
  30. 이제 배포 얘기로 넘어가, 쓰는 프레임워크는 라이트RT(Lite RT)이고 텐서플로 라이트(TensorFlow Lite) 위에 만들어졌다고 밝힘.
  31. 라이트RT는 앱 10만 개 이상, 사용자 수십억 명, 매일 상당한 양의 인터프리터 호출(추론)이 도는 가장 널리 배포된 프레임워크 축에 든다고 함.
  32. TFLite 파일 형식을 그대로 쓰기 때문에 기존에 텐서플로 라이트로 모델을 만들던 개발자도 그 모델을 그대로 라이트RT에서 돌릴 수 있다고 함.
  33. 같은 모델 형식이 안드로이드뿐 아니라 iOS, 맥OS, 리눅스, 윈도우, 웹, IoT 기기까지 크로스플랫폼으로 돌아간다고 함.
  34. 라이트RT로 이름을 바꾼 이유 중 하나는 텐서플로 라이트 모델만이 아니라 파이토치(PyTorch)와 JAX 모델도 받는다는 걸 보여주려는 것이라고 함.
  35. 파이토치 모델이 있으면 TFLite 형식으로 변환한 뒤 같은 경로로 배포할 수 있어, 모델 이식성과 여러 프레임워크 지원을 함께 얻는다고 설명함.
  36. 청중에게 안드로이드·iOS 여러 기기에 동시에 배포해야 하는지, 5~6년 된 낡은 폰에서도 돌아가는지 확인해야 하는지 물어봄.
  37. 배포 스택은 라이트RT 토치(모델 변환 경로)로 시작해, 가져온 모델을 TFLite로 바꾸고 필요하면 양자화한 뒤, LLM이면 라이트RT LLM 경로로, 아니면 라이트RT로 간다고 함.
  38. 모델 익스플로러(Model Explorer) 도구로 그래프를 직접 뜯어보며 어느 부분을 양자화하고 어디는 정밀도를 섞을지 정할 수 있다고 함.
  39. AI 엣지 포털(AI Edge Portal)은 클라우드 기반 벤치마킹 서비스로, 사전 컴파일(AOT)이 필요한지 즉시 컴파일(JIT)로 충분한지 파악해 다양한 기기군에서 안정적으로 돌아갈 레시피를 찾도록 돕는다고 함.
  40. 이 도구는 외부 앱 개발자뿐 아니라 구글 내부 개발팀도 같이 쓴다고 함.
  41. 가속 쪽은 CPU·GPU 라이브러리는 이미 거의 보편적이고, NPU 가속은 퀄컴(Qualcomm)·미디어텍(MediaTek)과 통합을 마쳤으며 다른 파트너와도 계속 붙이는 중이라고 함.
  42. AR·TTS(텍스트 음성 변환)나 카메라 피드를 실시간으로 처리하는 앱이라면 NPU가 성능을 3~10배 끌어올리는 게임체인저가 될 거라고 함.
  43. NPU를 쓰면 성능뿐 아니라 쓰는 전력량도 크게 줄어든다고 강조함.
  44. 사전 컴파일이든 기기 위 실시간 컴파일이든 고를 수 있고, 편하게 쓰도록 문서와 지원도 갖춰뒀다고 함.
  45. 커버리지 얘기로 넘어가, 제미마 모델은 지금 안드로이드·iOS·리눅스·라즈베리파이(Raspberry Pi)까지 실제로 테스트를 마쳤다고 함.
  46. 그날 아침 만들었다는 라즈베리파이 로봇 시연을 보여줬는데, CPU 위에서 라이트RT LLM으로 돌아가며 "안테나를 움직여줘"라는 지시에 반응해 샤프연필로 만든 안테나를 흔들었다고 함.
  47. 급하게 만든 거라 아직 성능이 좋진 않다고 인정하면서도, "나랑 결혼해줄래" 같은 질문에도 반응한다며 데모 부스에서 직접 해볼 수 있다고 함.
  48. 배포를 쉽게 하려는 새 CLI 도구도 파이썬 바인딩까지 갖춰 웹사이트에 올려뒀다고 함.
  49. 성능 수치로는 새 가속기·NPU를 쓰면 경우에 따라 최대 13배까지 속도가 오른다고 함.
  50. iOS에서는 초당 약 56토큰 속도가 나온다고 하고, 데스크톱 수치도 허깅페이스 페이지의 양자화 모델 목록에서 확인할 수 있다고 함.
  51. 라마(Llama)와 비교하면 모바일에서는 최대 35배, 데스크톱에서는 비슷한 수준, IoT에서는 3배 정도 더 빠르다고 함.
  52. 정리하며 라이트RT가 여러 프레임워크를 지원하고, 모델은 허깅페이스에, 체험은 갤러리 앱에 있다고 다시 짚음.
  53. 질의응답에서 아이폰·픽셀의 얼굴 잠금이 이미 이 프레임워크로 로컬에서 돌아가고 있고, 애플의 얼굴 잠금도 코어ML(Core ML)로 온디바이스로 처리된다고 답함.
  54. 집 카메라처럼 인증이 필요한 경우는 폰과는 조금 다른 알고리즘으로 진위를 확인해야 할 거라면서도, 기기 안에서 돌리는 것 자체는 충분히 가능하다고 답함.
  55. 라즈베리파이로도 되냐는 질문에는 가능하다고 짧게 답함.
  56. 엔비디아 오린(Orin) 보드 관련 질문에는 현장에는 없지만 허깅페이스 페이지에 예시가 있을 거라고 답함.
  57. 화자를 인식하는 부분과 사고를 담당하는 에이전트를 나눠 두고 무엇을 로컬에서, 무엇을 다른 곳에서 돌릴지 오케스트레이션(조율)하는 그룹이 내부에 있다고 밝힘.
  58. 예로 건강 코칭 에이전트 같은 걸 들면서도 구체적인 사례는 지금 공유할 게 없다고 함.
  59. 원하는 오픈웨이트 모델이 있으면 파일 형식과 크기만 맞으면 대체로 지원할 수 있다고 답함.
  60. 이 발표에서는 딥마인드 트랙이라 제미마에 집중했지만, 허깅페이스 페이지에는 다른 오픈웨이트 모델도 있고 일부는 바로 쓰게 준비돼 있으며 나머지는 직접 변환해 쓸 수 있다고 정리함.

한줄 코멘트. 성능 배수는 화려한데 정작 시연은 그날 아침 급조한 라즈베리파이 로봇이었다는 게, 이 스택이 실제로 어디까지 와 있는지를 숫자보다 더 솔직하게 보여줌.

  1. 이 세션은 별도 발표 없이 청중 질문 위주로 진행된 AI 엔지니어 컨퍼런스 패널임.
  2. 플로리나 문테네스쿠는 안드로이드 개발자 관계 엔지니어, 올리 게이먼드는 안드로이드 AI 프로덕트 매니저라고 자신을 소개함.
  3. 안드로이드에서 지능형 기능을 만들 때 쓸 수 있는 방식은 세 가지라고 정리함 — 온디바이스(기기 안에서만 처리)만 쓰기, 되면 온디바이스로 쓰고 안 되면 클라우드로 넘기는 하이브리드, 처음부터 클라우드만 쓰기임.
  4. 온디바이스로 처리하면 프롬프트가 기기 안에서만 돌고 서버로 데이터가 전혀 안 나간다고 설명함.
  5. 은행 정보 같은 민감한 데이터를 기기 밖으로 안 보내도 되고, 오프라인에서도 동작하고, 추론 비용이 추가로 안 붙는다는 세 가지를 온디바이스의 이점으로 듦.
  6. 민감한 데이터를 다루는 기능, 개인화, 번역처럼 문맥 창(모델이 한 번에 참고하는 입력 범위)이 짧아도 되는 작업이 온디바이스에 맞는 용도라고 함.
  7. 안드로이드에서 온디바이스 AI를 구현하는 방법은 두 가지라고 함 — ML Kit GenAI API로 제미나이 나노를 쓰거나, 더 자유롭게 커스텀 모델을 얹고 싶으면 LiteRT LM을 쓰는 것임.
  8. LiteRT LM은 이 세션 바로 뒤에 따로 발표가 있다며 이번 세션은 ML Kit GenAI API만 다룬다고 선을 그음.
  9. 제미나이 나노는 온디바이스용으로 가장 효율적인 모델이고, 젬마 4와 같은 아키텍처를 쓰되 안드로이드 기기에 맞춰 최적화됐다고 설명함.
  10. 젬마 4는 이 발표 한 주 전쯤 나왔다고 언급함.
  11. 제미나이 나노는 AI 코어라는 시스템 서비스를 통해 기기에 얹힌다고 함 — 기기당 모델이 하나뿐이고 모든 앱이 그 하나의 모델을 같이 쓰는 구조임.
  12. 제미나이 나노 자체가 하드웨어에 맞춰 최적화되어 있어서 지연 시간이 짧고 실행이 더 빠르다고 설명함.
  13. 올리는 이 구조를 클라우드 서비스에 빗대어, 개발자가 LLM(거대 언어모델) 설정이나 TPU(구글의 AI 전용 연산 칩) 추론 같은 걸 신경 안 써도 되게 만든 것과 같다고 설명함.
  14. 구글이 기기별로 쓸 수 있는 하드웨어에 맞춰 모델을 최적화해서 패키징까지 다 해준다고 강조함.
  15. 요청은 앱별로 격리되어 돌아가고, 입력·출력 데이터는 기기에 저장되지 않는다고 밝힘.
  16. ML Kit GenAI API는 더 큰 ML Kit API의 일부고, ML Kit 안에는 시각·자연어 처리용 API와 모델도 따로 있다고 함.
  17. GenAI 쪽에는 요약, 교정, 다시쓰기처럼 특정 작업에 특화된 API들이 있는데, 그중 가장 강력한 것은 프롬프트 API라고 함.
  18. 프롬프트 API는 자연어 요청을 제미나이 나노에 그대로 보낼 수 있는 API라고 설명함.
  19. 현재 프롬프트 API는 입력으로 텍스트와 이미지를 받고, 출력은 텍스트만 낸다고 함.
  20. 프롬프트 API로 이미지 이해, 콘텐츠 어시스턴스, 콘텐츠 분석, 개체 추출(문장에서 이름·장소 같은 정보를 뽑아내는 작업) 같은 걸 대부분 처리할 수 있다고 함.
  21. 제미나이 나노는 픽셀9·픽셀10급 세대 기기, 그리고 일부 다른 제조사 기기에서만 쓸 수 있다고 함.
  22. 온디바이스 모델이 없는 기기까지 기능을 넓히려면 파이어베이스 AI 로직으로 클라우드 추론을 붙이면 된다고 함.
  23. 몇 주 전에 하이브리드 추론을 출시했다며, 기기에 제미나이 나노가 있으면 온디바이스로 돌리고 없으면 클라우드로 넘어가게 만들 수 있다고 설명함.
  24. 젬마 4를 바탕으로 한 다음 세대 제미나이 나노를 AI 코어 프리뷰로 이미 써볼 수 있고, 이러면 온디바이스와 클라우드의 제미나이 플래시 모델이 비슷한 경험을 준다고 함.
  25. 더 강력한 프로·플래시·플래시라이트 모델까지 클라우드에서 쓰고 싶으면 파이어베이스 AI 로직으로 제미나이 API와 버텍스 AI 두 제공자에 다 접근할 수 있다고 함.
  26. 온디바이스로 저지연·프라이빗하게 처리하는 것부터 클라우드로 강력한 모델을 쓰는 것까지, 안드로이드가 그 사이 전 구간을 일관된 API로 묶으려 한다는 게 두 사람이 전한 요지임.
  27. 청중 한 명이 제미나이 나노와 LiteRT LM을 돌릴 때 RAM 사용량이나 배터리 소모를 측정해봤는지 물음.
  28. 올리는 지금 쓰는 모델들이 성능을 유지하면서 최대한 줄인 크기라 그래도 플래그십급 기기 사양이 필요하다고 답함.
  29. 배터리 우려 때문에 AI 코어를 만들어 최대한 최적화한다고 했고, 쉬지 않고 계속 돌리면 배터리가 빨리 준다는 점은 인정함.
  30. 다만 실제 쓰임새는 사용자가 질문하고 답을 받는 식으로 하루 10~20번 정도라 배터리에 큰 영향이 없다고 함.
  31. 반대로 처리할 데이터가 많아 배치로 돌리는 경우엔 지연 시간에 덜 민감하니 충전 중인 야간처럼 백그라운드에서 계속 돌리게 하는 사례가 늘고 있다고 함.
  32. 커스텀 모델로 가는 개발자를 위해 프로파일링 도구는 제공하지만, 영향도 파악은 개발자가 직접 해야 한다고 함.
  33. 다른 청중이 ML Kit을 쓰면 결국 앱들이 기기 안 모델 하나를 공유하는 거냐고 물음.
  34. 이어서 한 기기에 앱 100개가 몇 년 뒤 전부 같은 모델을 쓰게 되면 지연 시간을 어떻게 관리할 거냐고 물음.
  35. 올리는 바로 이 문제 때문에 시스템 레벨에서 처리하는 거라고 답함. 쓸 만한 최소 크기 모델도 1GB 정도고, 지금 배포 중인 모델은 3~4GB나 된다고 함.
  36. 앱 개발자가 이 정도 용량을 각자 앱에 넣는 건 현실적이지 않고, 그럴 만큼 확실한 킬러 기능이 있어야 정당화된다고 함.
  37. 시스템에 한 번만 넣어두면 모든 앱이 그 비용을 나눠서 지는 셈이라, 앱 수백 개가 붙어도 걱정 안 한다고 함.
  38. 대신 큐잉과 시스템 전체 관리로 배터리 사용을 앱별로 귀속해서, 어떤 앱이 얼마나 쓰는지 사용자에게 보여줄 수 있게 한다고 함.
  39. GPS나 와이파이도 그랬듯, 사용자는 가치를 느끼는 앱이라면 배터리를 기꺼이 쓴다는 게 지금까지 봐온 패턴이라고 함.
  40. 개발자 입장에서는 추론만 호출하면 되고, 스케줄링과 큐 관리는 AI 코어가 다 처리한다고 함.
  41. 백그라운드에서 접근하면 대기열에 밀리고, 포그라운드에서 사용자가 지금 쓰고 있는 앱이면 우선순위를 받는다고 함.
  42. 픽셀이 아닌 아수스 폰을 쓴다는 청중이, "헤이 구글"로 물으면 그게 기기에서 도는지 원격으로 도는지 물음.
  43. 올리는 그건 제미나이 앱이나 검색 앱 쪽 통합이라 확실친 않지만 원격으로 돈다고 예상한다고 밝힘.
  44. 그 질문자가 이어서, 오늘 소개한 걸 직접 설치해서 답 품질을 고치는 "스킬"을 로컬로 짤 수 있는지 물음.
  45. 플로리나는 자기 앱을 만든다면 제미나이 앱이 아니라 모델 자체와 직접 상호작용하는 거라고 구분해서 답함.
  46. 온디바이스 모델을 쓰면 클라우드를 신경 쓸 필요 없이 추론이 전부 기기 안에서 끝난다고 확인함.
  47. 스킬이라는 건 결국 프롬프트에 같이 끼워 넣는 것일 뿐이고, ML Kit이 제공하는 건 그 위에 뭔가를 쌓을 수 있는 더 낮은 레벨의 도구라고 설명함.
  48. 다른 청중이 프롬프트 API로 RAG(모델이 답하기 전에 외부 문서를 먼저 찾아와 근거로 쓰게 하는 방식) 같은 걸 만들 수 있는지, AI 엣지 갤러리와 AI 코어는 무슨 관계인지 물음.
  49. 올리는 지금도 프롬프트 API로 RAG류 구성이 가능하다고 답하고, 곧 임베딩 API를 추가해 이런 구성을 더 쉽게 만들 계획이라고 함.
  50. AI 엣지 갤러리는 무엇이 가능한지 보여주는 쇼케이스로, AI 코어를 백엔드로 쓰거나 커스텀 모델을 쓸 수도 있다고 설명함.
  51. AI 엣지 갤러리는 할 수 있는 일의 최전선을 보여주지만 개발자가 더 손을 많이 대야 하고, AI 코어는 설정 없이 프롬프트에만 집중해 프로덕션 앱을 만들 수 있게 하는 쪽이라고 구분함.
  52. 오늘 사진을 여러 장 찍어 하나로 요약하는 것처럼, "시스템" 접근이 시스템 프롬프트를 말하는 건지 파일 접근을 말하는 건지 묻는 질문이 나옴.
  53. 프롬프트 API가 텍스트와 이미지 입력을 다 받으니, 앱이 원래 접근하던 파일이나 사진을 그대로 API에 넘겨 서버 기반 추론과 똑같이 쓰면 된다고 답함.
  54. 텍스트 노트끼리 유사도를 구하려고 벡터화·임베딩 모델을 이 API로 쓸 수 있는지 묻는 질문에는, 아직 임베딩 API는 없지만 곧 나올 거라고 답함.
  55. 제미나이 임베딩 모델 같은 걸 API로 바로 쓸 수 있게 만들 계획이라고 밝힘.
  56. 마지막 질문으로, 기기마다 다르고 모델 종류도 다양한데 어떤 기기에서 어떤 모델이 되는지 어떻게 판단해야 하냐는 질문이 나옴.
  57. ML Kit에는 LLM·임베딩 말고도 텍스트, OCR(이미지 속 글자를 읽어내는 기술), 비전 같은 고전적인 작은 모델들도 있고, 이런 모델은 수십억 대 규모 기기에서도 문제없이 돈다고 함.
  58. 반면 GenAI API, 즉 제미나이 나노 계열은 최근 몇 년 사이 나온 플래그십급 기기가 있어야 한다고 함.
  59. AI 코어는 이걸 패키징해서, 되는 기기에서는 호출만 하면 잘 돌아간다는 걸 보장해주는 역할이라고 함.
  60. 더 넓은 기기 범위가 필요하면 LiteRT LM으로 직접 테스트해서 커버리지를 넓힐 수 있지만, 그 테스트는 개발자 몫이라고 함.
  61. AI 코어가 커버하는 기기라면 잘 돈다는 걸 구글이 보장하고, 그 밖은 LiteRT LM으로 개발자가 직접 검증하는 구도라고 정리함.

한줄 코멘트. 모델을 앱마다 심지 않고 OS 하나가 짊어지는 이 설계는 온디바이스 AI 그 자체보다 배터리·비용·유통 문제를 시스템 레벨로 옮겨 푼 것에 더 가까워 보임.

  1. 발표자는 구글 딥마인드(Google DeepMind) 소속으로, 7일 전에 나온 젬마(Gemma) 4를 소개하는 첫 발표라고 밝힘.
  2. 젬마는 구글 딥마인드가 만드는 오픈 모델(open model, 내려받아 직접 인프라·기기에서 돌리고 파인튜닝할 수 있는 모델) 계열이라고 설명함.
  3. 1년 전 나온 젬마 3은 소비자용 GPU 한 대에 들어가는 오픈 모델 중 가장 성능이 좋았고, 파라미터 규모는 10억에서 270억까지였다고 함.
  4. 당시 LM 아레나(LM Arena) 점수 그래프에서 x축 아래 작은 점들은 그 모델을 로드하는 데 H100이나 A100이 몇 장 필요한지를 나타낸다고 설명함.
  5. 젬마 4는 구글이 낸 오픈 모델 중 가장 성능 좋은 계열이고, 파라미터는 20억에서 320억까지 있다고 함.
  6. 가장 작은 두 모델은 안드로이드폰·아이폰은 물론 라즈베리 파이(Raspberry Pi)에서도 돌아가고, 멀티모달(여러 형태의 입력을 함께 처리하는 방식)에 추론까지 되면서 기기 안에서 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 작업을 한다고 함.
  7. 27B(270억) 안팎으로는 지연이 아주 짧은 MoE(mixture of experts, 입력마다 전문가 서브네트워크 일부만 골라 쓰는 구조) 모델이 있다고 함.
  8. 가장 크고 똑똑한 31B(310억 파라미터) 모델도 소비자용 GPU 한 대에서 돌아간다고 강조함.
  9. 시연 영상 세 개를 보여줌. 오른쪽은 안드로이드폰에서 젬마가 여러 스킬 중 하나(피아노 연주 등)를 골라 실행하는 에이전트 구성이었음.
  10. 왼쪽 시연은 젬마가 기기 안에서 코딩하는 모습으로, 비행기 모드 상태로 API 호출 없이 완전히 폰 안에서만 돌아갔다고 함.
  11. 가운데 시연은 노트북 한 대에서 젬마 인스턴스 10개를 라마.cpp(llama.cpp, 모델을 가볍게 돌리는 오픈소스 추론 엔진)로 병렬 구동해 각각 다른 SVG(벡터 그래픽)를 그리게 한 것으로, 속도는 초당 약 100토큰이었다고 함.
  12. 이 시연들로 젬마가 코딩·에이전트 작업·안드로이드 앱 개발까지 전부 오프라인으로 해낸다는 걸 보여주려 한 것으로 보임.
  13. LM 아레나 그래프에서 x축은 파라미터 수, y축은 LM 아레나 점수인데, 이 벤치마크가 완벽하진 않지만 대화 등 일반 용도에서 커뮤니티가 그 모델을 얼마나 좋아하는지 보여주는 대리 지표라고 짚음.
  14. 그래프 왼쪽 위 구석에 몰린 점들이 크기는 작으면서 성능은 높은 모델을 뜻한다고 설명함.
  15. 2년 전 젬마 2, 1년 전 젬마 3을 거치며 모델 크기를 키우지 않고도 성능이 계속 좋아졌다고 함.
  16. 이 추세라면 1~2년 뒤엔 개인 기기 안에서 아주 강력한 모델이 돌아갈 거라고 전망함.
  17. 젬마는 데스크톱·노트북·폰 어디에나 들어가는데, 하루이틀 전엔 누군가 닌텐도 스위치(Nintendo Switch)에 라마.cpp를 올려 젬마를 돌리는 걸 봤다고 함.
  18. 이전 버전 젬마의 라이선스가 제대로 된 오픈소스가 아니라는 지적을 많이 받아서, 젬마 4부터는 아파치(Apache) 2.0 라이선스로 바꿨다고 밝힘.
  19. 모델명에 붙은 E는 "effectively"(사실상)의 줄임이라고 설명함. E2B는 사실상 20억 파라미터라는 뜻이지만 실제로는 파라미터가 약 40억 개라고 함.
  20. 층별 임베딩(per-layer embeddings)이라는 구조 덕분인데, 지난해 여름 처음 공개된 아키텍처라고 함.
  21. 층별 임베딩은 계산이 아니라 조회 테이블(lookup table)처럼 동작해서 GPU에 둘 필요 없이 CPU나 디스크에 둬도 된다고 설명함.
  22. 그래서 모델 전체가 50억 파라미터여도 GPU에는 20억 파라미터만 올리고 나머지는 더 느린 메모리에 둘 수 있다고 함. 그 부분은 트랜스포머식 행렬곱을 하지 않기 때문이라고 함.
  23. 라마.cpp에서 override-tensor라는 플래그 하나로 층별 임베딩을 CPU나 디스크로 옮길 수 있고, 별다른 손질 없이도 잘 작동한다고 함.
  24. 이 아키텍처는 모바일 같은 온디바이스(on-device, 기기 안에서 처리) 용도에 맞춰 설계된 것이라 가장 작은 모델들이 E2B·E4B 구조를 쓴다고 밝힘.
  25. 작은 모델들도 이미지·영상·오디오를 이해하는 멀티모달 처리가 되고, 음성 인식과 음성-번역 텍스트 변환까지 된다고 함. 스페인어로 말하면 프랑스어 텍스트로 옮기는 식이라고 예로 듦.
  26. 더 큰 모델은 영상의 세밀한 부분까지 잡아내는 멀티모달 이해가 되고, 사진 속 라마(동물)가 어디 있는지 짚어주거나 사물을 검출하는 예시를 보여줌.
  27. 젬마 4는 140개가 넘는 언어로 훈련됐고, 제미나이(Gemini)와 같은 토크나이저(tokenizer, 텍스트를 모델이 처리할 단위로 쪼개는 장치)를 쓴다고 밝힘.
  28. 이 토크나이저는 젬마의 원 성능과 별개로 다국어 용도에 맞춰 공들여 설계됐다고 강조함.
  29. 그래서 페루의 케추아어(Quechua)나 인도의 공용어처럼 디지털 자원이 적은 언어라도, 데이터를 모아 파인튜닝하면 토크나이저 덕에 별다른 손질 없이도 잘 작동하는 편이라고 함.
  30. 다국어와 멀티모달을 함께 쓰는 예로 일본어 텍스트가 담긴 이미지를 설명하는 사례를 보여줌.
  31. 출시 일주일 만에 젬마 4 베이스 모델만 다운로드 1000만 건을 넘겼고, 이를 바탕으로 한 파생 모델(양자화·파인튜닝 등)이 이미 1000개가 넘는다고 함.
  32. 젬마 계열 전체로는 다운로드가 5억 건을 넘었다고 밝힘. 젬마는 그 자체로 쓰는 모델이 아니라 그 위에 생태계를 짓게 하는 것이 목적이라고 함.
  33. 허깅 페이스(Hugging Face)에서 화제 1위에 올랐고, 커뮤니티가 저장소 전체를 젬마로 감사(audit)하는 등 다양한 기기에 젬마를 올려보는 사례를 만들어냈다고 함.
  34. 언슬로스(Unsloth), MLX, 라마.cpp, 허깅 페이스, vLLM 같은 오픈소스 생태계와 협업하면서, 새 도구를 낼 때 사람들이 기존에 쓰던 도구를 그대로 쓸 수 있게 하는 걸 중요하게 여긴다고 함. 허깅 페이스 트랜스포머스로 파인튜닝하던 사람이 굳이 케라스(Keras)로 옮길 필요가 없어야 한다는 뜻이라고 밝힘.
  35. 안드로이드 스튜디오(Android Studio)에는 에이전트 모드가 있고, 라마.cpp나 vLLM으로 돌리는 오프라인 모드에서 젬마가 코드를 도와 쓴다고 함. 훈련 때 안드로이드 관련 데이터셋과 벤치마크도 포함했다고 밝힘.
  36. 젬마버스(Gemmaverse) 전체 파생 모델 수는 10만 개를 넘는다고 함. 이 수치는 지난주 기준이라고 덧붙임.
  37. 젬마를 파인튜닝하는 이유는 다양한데, 답변 스타일을 바꾸거나 대화형이 아닌 특정 예측 전용 모델을 만드는 경우를 예로 듦. 아니면 그냥 집에 GPU가 너무 많아서 태워버리고 싶은 것일 수도 있다고 농담함.
  38. 구글이 직접 낸 공식 파생 모델도 있다고 함. 실드 젬마(ShieldGemma)는 정책에 안 맞는 유해 이미지·텍스트를 걸러내는 프로덕션용 모델 계열이라고 설명함.
  39. 의료 쪽으로는 젬마 3 기반의 멀티모달 모델인 메드젬마(MedGemma)를 냈고, 방사선·흉부 엑스레이 판독 같은 의료 과제에 쓴다고 함.
  40. 이 공식 파생 모델들도 전부 오픈 모델이라 더 좁은 용도에 맞춰 추가로 파인튜닝할 수 있다고 함.
  41. 커뮤니티 사례로 AI 싱가포르(AI Singapore)는 동남아시아 언어용 모델을 훈련하며 다국어 성능의 최전선을 밀고 있다고 함.
  42. 인도의 사르밤(Sarvam)은 정부가 스타트업에 투자해 국가 단위 모델을 훈련하는 사례로, 자국 AI 주권(sovereign AI, 자국 데이터로 자국이 통제하는 AI 모델을 갖추려는 흐름)과 공용어 대응 성격이 크다고 함.
  43. 지난해 12월 발표한 논문에서는 딥마인드 연구자들이 젬마 3로 암 치료 경로 후보를 제안했고, 이를 실제 실험실에 가져가 검증했더니 실제 결과로 이어졌다고 밝힘.
  44. 이 사례를 두고 챗봇이나 롤플레이용 어시스턴트를 넘어, 금융·법률 검토처럼 실제로 쓸모 있는 모델을 만드는 일이라고 강조함.
  45. 데이터가 서버 밖으로 나가면 안 되는 오프라인 상황, 지하철·비행기 안에서 쓰는 상황, 화면 내용을 이해해 돕는 크롬 확장 프로그램, 기기를 직접 조작하는 온디바이스 제어까지 오픈 모델이 해낼 수 있는 활용 예로 들었다고 함.
  46. 1~2년 전과 비교하면 지금 오픈 모델은 폰 안에서만으로도 상당히 복잡하고 에이전트적인 작업을 해낸다고 짚음.
  47. 다음 2주 안에 한 시간 정도 최신 오픈 모델을 직접 써 보길 권함. 다만 가장 순수한 지능이 필요한 작업에는 여전히 제미나이 같은 API 기반 모델을 쓰게 될 거라고 함.
  48. 6~12개월 뒤가 어떨지는 모르지만, 사람들이 자기 기기 안에서 자기 데이터로 맞춘 강력한 오픈 모델을 갖게 되는 방향으로 가고 있다고 봄. 모델을 써 보고 뭔가 만들어 공유해 달라는 말로 마무리함.

한줄 코멘트. "20억 파라미터"라는 이름표 뒤에 실제로는 40억이 숨어 있다는 사실 하나가, 오픈 모델 경쟁이 이제 총 파라미터 수가 아니라 GPU에 뭘 얼마나 올리느냐는 싸움으로 넘어갔다는 걸 보여줌.

  1. 발표자는 마이크로소프트(Microsoft) 프로덕트 매니저 에마 닝(Emma Ning)이고, 개발자가 로컬 AI(기기 안에서 도는 인공지능)로 크로스플랫폼 앱을 쉽게 만들도록 돕는 파운드리 로컬(Foundry Local)을 소개한다고 밝힘.
  2. 클라우드 AI가 이렇게 강력한데 왜 로컬 AI가 필요하냐는 질문을 던지며, 고객과 나눈 대화에서 나온 이유 네 가지를 든다고 함.
  3. 첫째 이유는 네트워크로, 이 컨퍼런스에서도 와이파이가 자주 끊겼다며 자신의 랩 데모는 전부 로컬에서 돌아가 인터넷 걱정이 없다고 함.
  4. 둘째 이유는 프라이버시와 보안으로, 법률 문서나 환자 정보처럼 민감한 데이터를 다루는 회사는 그 데이터를 기기 밖으로 내보내지 않고 전부 로컬에서 처리해야 한다고 함.
  5. 셋째 이유는 비용으로, 수백만 대 기기에 깔리는 게임 앱이 매일 수억 건씩 추론(모델이 답을 내는 연산)을 클라우드에 요청하면 감당이 안 된다고 함.
  6. 넷째 이유는 실시간 지연으로, 즉시 반응해야 하는 AI 앱은 클라우드 응답을 기다릴 여유가 없다고 함.
  7. 이어서 로컬 AI가 지금 준비됐는지를 묻고, 수십 년 이어진 하드웨어 발전으로 클라이언트 기기가 최신 GPU·NPU를 갖추게 됐다고 함.
  8. 모델 회사들도 파이(Phi)·딥시크(DeepSeek) 변형처럼 더 가볍고 빠르고 로컬 추론에 맞춘 모델을 계속 내놓고 있다고 함.
  9. 런타임 단(추론을 실행하는 소프트웨어 계층) 최적화 기법도 계속 발전하면서, 이 세 흐름이 겹쳐 로컬 AI가 이제 현실이 됐다고 정리함.
  10. 그럼 어떻게 만들 것인가로 넘어가, 마이크로소프트가 이미 가진 자산을 새로 만들지 않고 그대로 쓴다고 밝힘.
  11. 애저 AI 파운드리(Azure AI Foundry)는 작년 마이크로소프트 이그나이트(Ignite)에서 나왔고, 조직 7만 곳 넘게 쓰며 모델 1900개 넘게 올라와 있다고 함.
  12. ONNX 런타임(ONNX Runtime)은 자사의 크로스플랫폼 고성능 온디바이스 추론 엔진으로, 매달 다운로드 1000만 건을 넘고 파이토치(PyTorch) 대비 성능 가속이 크다고 고객들이 만족한다고 함.
  13. 마지막 자산은 윈도우(Windows)로, 윈도우 클라이언트 기기의 규모와 도달 범위가 워낙 커서 AI를 널리 퍼뜨리려 할 때 무시할 수 없다고 함.
  14. 이 세 자산을 묶어 만든 게 파운드리 로컬이고, 온디바이스 AI를 매끄럽게 쓰게 하는 엔드투엔드(처음부터 끝까지 이어지는) 솔루션이라고 함.
  15. 구조는 바닥에 ONNX 런타임이 여러 하드웨어에서 성능을 가속하고, 그 위에 새로 만든 파운드리 로컬 관리 서비스가 기기 위 모델을 호스팅하고 관리한다고 함.
  16. 이 관리 서비스는 애저 AI 파운드리와 연결돼 필요할 때 오픈소스 모델을 내려받는다고 함.
  17. 사용자 경험 쪽으로는 파운드리 로컬 CLI(명령줄 도구)로 기기 위 모델을 쉽게 탐색할 수 있고, SDK도 제공해 개발자가 클라우드부터 로컬까지, 여러 하드웨어에 걸쳐 자기 앱에 붙일 수 있다고 함.
  18. 파운드리 로컬은 한 달 전 마이크로소프트 빌드(Build) 컨퍼런스에서 정식 발표됐고, 윈도우와 맥OS 양쪽에서 쓸 수 있다고 함.
  19. 윈도우에서는 플랫폼 안에 통합돼 있어 윈도우 AI 개발자에게는 경험이 더 간단하다고 함.
  20. 여러 하드웨어에서 성능을 가속하려고 엔비디아(Nvidia)·인텔(Intel)·AMD·퀄컴(Qualcomm)과 긴밀히 협력해 각사 가속기를 파운드리 로컬에 붙였다고 함.
  21. 정식 발표 전 고객 100곳 넘게 비공개 프리뷰에 참여해 쓰기 쉽고 성능이 좋다는 피드백을 줬다고 함.
  22. 그중 하나로 파운드리 로컬을 소개하는 고객 영상을 보여주는데, 소프트웨어 회사 피시스(Pieces)의 CEO 겸 공동창업자 사보(Savo)가 등장함.
  23. 피시스는 OS 전체에 걸쳐 개발자에게 인공적인 장기 기억을 주는 걸 목표로 하고, 오프라인 우선 AI가 이 비전의 핵심이라 2022년 말부터 엣지에서 도는 소형 언어모델을 탐구해 왔다고 함.
  24. 자체 라마씨피피(Llama.cpp)를 굴리다 올라마(Ollama)로 옮겨봐도 버전 관리·성능·최종 사용자 경험에서 답답함이 남아 있었는데, 파운드리 로컬과 협력하면서 풀렸다고 함.
  25. 문서만 보고 시작해 프로덕션에 올릴 빌드까지 금방 갔고, 메모리 관리·첫 토큰까지 걸리는 시간·초당 토큰 수에서 눈에 띄게 좋아졌다고 밝힘.
  26. 두 번째 고객 영상은 이름을 밝히지 않은 회사로, 여러 해 동안 고객사 AI 프로젝트를 해왔는데 일부 고객은 민감한 정보를 다룰 땐 외부 서비스를 쓸 수 없다고 함.
  27. 이 회사는 파운드리 로컬로 음성 인식(speech-to-text) 서비스까지 통째로 로컬에서 돌리는 하이브리드 솔루션을 보여주며, 설치가 간단하고 모델을 쓰기 쉬운 점이 인상적이었다고 함.
  28. 설치와 모델 사용의 단순함 덕분에 이제 일부만 로컬로 돌리는 하이브리드 솔루션도 만들 수 있게 됐다고 정리함.
  29. 이제 라이브 데모로 넘어가 CLI 경험부터 보여주는데, 윈도우에서는 윙겟(winget)으로 맥OS에서는 홈브루(Homebrew)로 파운드리 로컬 패키지를 설치한다고 함.
  30. `foundry model list` 명령으로 지원하는 모델 목록을 보여주고, 모델마다 CPU용·CUDA(엔비디아 GPU 연산 플랫폼)용·내장 GPU용 등 하드웨어별 변형이 있다고 설명함.
  31. NPU용 변형도 제공하지만 시연에 쓰는 기기에는 퀄컴 NPU가 없어 목록에 나오지 않는다고 함.
  32. 모델을 미리 안 받았다면 실행할 때 클라우드에서 내려받아 인터넷이 필요하지만, 자신은 이미 받아둬서 인터넷 없이 시연한다고 함.
  33. `foundry cache list` 명령으로 이미 내려받은 모델 네 개를 보여주며, 실험할 때 여러 모델을 돌려 품질과 성능을 비교한 뒤 쓸 모델을 정한다고 설명함.
  34. 먼저 큐원(Qwen) 2.5 1.5B 모델을 `foundry model run`으로 실행해 질문을 던지자 이미 받아둔 모델이라 로딩도 응답도 빨랐다고 함.
  35. 지연시간 수치를 보려고 버보스(verbose) 모드로 같은 질문을 다시 돌려, 초당 약 90토큰이 나온다는 걸 확인함.
  36. 이어서 파이(Phi)-4-미니 모델도 같은 질문으로 돌려보는데, 모델을 불러오는 데 시간이 좀 더 걸렸다고 함.
  37. 파이-4-미니는 큐원보다 모델 크기가 커서 속도는 조금 느리지만, 답변이 더 자세해 품질 면에서 낫다고 평가함.
  38. 개인적으로 파이-4-미니 손을 들어주며, 이 모델로 앱을 만들어보겠다고 함.
  39. 만들 앱의 배경으로, 새 조직에 옮겨 긴 내부 문서를 빨리 훑어야 하는데 그 문서를 클라우드에 올릴 수 없고 팀원 일부는 윈도우, 일부는 맥을 쓰는 상황을 들며, 로컬 AI로 돌아가는 크로스플랫폼 요약 앱을 만들겠다고 함.
  40. 앱을 실행해 URL이나 로컬 파일을 넣으면 요약해주는 기능과, 쓸 모델을 고르는 설정 탭을 보여줌.
  41. 설정 탭에서 더 자세한 정보를 원해 파이-4-미니 모델 ID를 넣고, 프로젝트 문서를 넘겨 요약을 실행함.
  42. 결과로 파운드리 로컬이 기기 안에서 바로 도는 크로스플랫폼 AI 앱을 만드는 데 유용하다는 요약이 나왔다고 함.
  43. 코드를 보여주며 파이썬(Python) SDK와 자바스크립트(JavaScript) SDK를 함께 제공한다고 밝히고, 이 데모는 자바스크립트 SDK로 짰다고 함.
  44. 파운드리 로컬 매니저(FoundryLocalManager)를 만들어 모델 이름(파이-4-미니)으로 초기화하면 파운드리 로컬 엔드포인트로 클라이언트를 만들고, 챗 완료를 기다려 결과를 출력하는 구조라고 설명함.
  45. 이 앱을 윈도우에서 돌린 뒤, 맥을 쓰는 팀원에게 프로젝트를 통째로 넘겨 같은 명령 `npm run start`로 실행하는 화면을 보여줌.
  46. 맥에서는 팀원이 큐원 모델을 골랐고, 같은 문서로 요약을 돌리자 파이-4-미니보다 더 짧고 간결한 요약이 나왔다며 앞서 본 성향과 같다고 확인함.
  47. 크로스플랫폼 앱까지 보여준 뒤, 요즘 다들 이야기하는 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 얘기를 빼먹었다며 이어감.
  48. 파운드리 로컬은 로컬 모델과 MCP(모델 컨텍스트 프로토콜, 모델이 외부 도구·데이터에 접근하는 표준 방식) 서버를 조합해 로컬 에이전트를 만들고 돌릴 수 있는데, 이 기능은 아직 비공개 프리뷰라고 밝힘.
  49. `foundry agent list`로 이미 만들어둔 샘플 에이전트 세 개를 보여주며, 파운드리 로컬에서 에이전트는 모델 하나와 MCP 서버 하나 이상으로 이뤄진다고 설명함.
  50. 목록에서 모델 하나를 고르고 원하는 MCP 서버를 붙이면 자기만의 에이전트를 만들 수 있다고 하고, 시연에서는 OCR 에이전트를 고름.
  51. `foundry agent info`로 확인하니 이 에이전트는 이미지에서 글자를 뽑아내는 용도로, 파이-4-미니 모델과 파일 시스템 MCP 서버·OCR용 MCP 서버 두 개로 구성돼 있다고 함.
  52. `foundry agent run`으로 실행하면 먼저 의존성을 점검해 필요하면 승인받아 설치하는데, 이번엔 이미 설치돼 있어 바로 돌아갔다고 함.
  53. 실행 중 파일 시스템 MCP 서버를 쓸지와 접근할 디렉터리, OCR MCP 서버를 쓸지를 차례로 물었고 전부 승인했다고 함.
  54. 권한을 준 뒤에는 에이전트가 쓸 수 있는 도구 목록이 뜨는데, 파일 시스템 관련 도구와 OCR 관련 도구가 섞여 있다고 함.
  55. 영수증을 찾아 처리한 뒤 총액을 알려달라는 요청을 주자, 에이전트가 먼저 파일 검색 도구로 영수증을 찾고 이어 OCR 도구로 글자를 뽑아 총액을 꺼내는 순서로 답을 냈다고 함.
  56. 마무리하며 로컬 모델은 대체로 클라우드 모델만큼 능력이 크지 않아 클라우드 모델·클라우드 에이전트가 하는 화려한 일을 그대로 기대하긴 어렵다고 인정함.
  57. 그래도 이 스택이 상당한 가능성을 열어준다며, 더 알고 싶으면 안내 링크를, 에이전트 기능을 써보고 싶으면 비공개 프리뷰 신청서를 참고하라고 마무리함.

한줄 코멘트. 클라우드 부족분을 메우는 게 아니라 애저·ONNX·윈도우라는 이미 있던 세 자산을 CLI 하나로 묶었다는 점이 이 발표의 진짜 내용이고, 90토큰/초라는 속도보다 그 이어붙이기가 더 눈여겨볼 대목임.

  1. 발표자는 존 웰시(John Welsh), 앤트로픽(Anthropic)의 기술 스태프(member of technical staff)로 대규모 시스템을 20년째 만들어온 사람이라고 밝힘.
  2. 최근 몇 달은 툴 호출과 통합, 그리고 사내외 연동에 MCP(모델 컨텍스트 프로토콜, LLM이 외부 데이터·도구에 표준화된 방식으로 접속하게 해주는 개방형 규격) 지원을 붙이는 일에 집중했다고 함.
  3. 이번 발표는 MCP 클라이언트를 구현하는 법과, 앤트로픽 같은 큰 조직 안에서 MCP를 규모 있게 굴리는 법을 다룬다고 함.
  4. 모델이 툴 호출을 제대로 하기 시작한 건 작년 중반에서 후반쯤이라고 함. 그 순간부터 모델이 구글 드라이브를 불러오고 지도를 불러오고 문자까지 보낼 수 있다는 데 다들 흥분했다고 함.
  5. 적은 노력으로 멋진 걸 만들 수 있게 되자 팀마다 각자 속도를 내며 커스텀 엔드포인트를 마구 늘렸다고 함.
  6. 슬래시콜툴(slash-call-tool), 슬래시겟컨텍스트(slash-get-context) 같은 서비스가 우후죽순 생겼고, 여기에 인증을 비롯한 추가 요구사항이 붙기 시작했다고 함.
  7. 그 결과 조직 전체에 통합이 뒤엉키는 상황(integration chaos)이 왔다고 함. 같은 기능이 여기저기 중복됐다고 함.
  8. A서비스에서 잘 되던 연동을 B서비스에 쓰려면 인터페이스를 새로 짜는 데만 3주가 걸리는 일이 흔했다고 함.
  9. 앤트로픽이 도달한 결론은 시간이 지나면서 이 모든 엔드포인트가 결국 MCP를 닮아간다는 것이었다고 함.
  10. 툴 목록 가져오기, 리소스 가져오기, 엘리시테이션(elicitation, 서버가 실행 중 사용자에게 추가 정보를 물어보게 하는 MCP 기능)까지 결국 다 갖추게 된다고 함. 지금 MCP 기능 전체를 안 쓰더라도 시간이 지나면 결국 그쪽으로 확장하게 된다고 함.
  11. 발표자는 MCP 안에 성격이 다른 두 축이 있다고 봄. 하나는 JSON-RPC(원격 프로시저를 JSON 메시지로 호출하는 통신 규격) 명세로, 모델에 컨텍스트를 주는 쪽과 모델을 다루는 코드가 주고받는 표준 메시지 형식이라고 함.
  12. 이 메시지 형식을 어떻게 정할지는 MCP 저장소(repo)에서 늘 큰 논쟁거리라고 함.
  13. 다른 축은 전송 표준으로, 스트리머블(streamable) HTTP·OAuth 2.1·세션 관리 같은 것들이라고 함.
  14. 모두가 같은 언어로 말하게 만드는 일이라 전송 표준 쪽이 더 까다롭지만, MCP의 실속(juice)은 대부분 메시지 명세와 서버 간 상호작용 쪽에 있다고 함.
  15. 그래서 팀 내부적으로 "그냥 모든 걸 MCP로 하면 안 되나"라고 물었고, 답은 "모델에 컨텍스트를 넘기는 일이라면 다 된다"였다고 함.
  16. 클라이언트가 메시지를 보내고 뭔가가 응답하는 형식만 지키면, 그 스트림이 어디를 지나가는지는 상관없다고 함. 같은 프로세스든 다른 데이터센터든 엔터프라이즈 네트워크 장비 더미를 거치든 다 된다고 함.
  17. 코드 입장에서는 그냥 connect-to-MCP를 호출하면 쓸 수 있는 툴과 메서드 묶음이 생기는 것뿐이라고 함.
  18. 내부적으로 뭔가를 표준화하는 이유는, 지루한(boring) 걸 잘 해내는 게 좋기 때문이라고 함. 구글 드라이브를 앱에 잘 붙이는 능력은 경쟁력이 아니라 그냥 해야 하는 일이라고 함.
  19. 엔지니어들이 배울 방식을 하나로 두면 더 빨라지고, 통합 배관(plumbing)이 아니라 진짜 흥미로운 문제에 시간을 쓸 수 있다고 함.
  20. 같은 방식을 어디서나 쓰면 새 연동을 만들 때마다 다음 사람이 갈 길이 조금씩 정리된다고 함.
  21. MCP를 내부 표준으로 삼아야 하는 또 다른 이유는 이미 생태계 수요가 있다는 점이라고 함. 다들 MCP를 구현하고 있으니 굳이 다른 걸 두 번 만들 필요가 없다는 논리라고 함.
  22. 주요 AI 랩 모두가 MCP 표준을 만드는 연합에 참여하고 있어서, 새 모델 기능이 나올 때마다 각 랩이 자기 기능을 넣으려 그 패턴이 프로토콜에 계속 추가될 거라고 함.
  23. MCP를 쓰면 아직 안 겪은 문제까지 미리 풀어준다는 장점이 있다고 함. 프로토콜 안에는 이미 누군가 필요해서 넣어둔 기능이 많다고 함.
  24. 예로 회사 안에 청구(billing) 모델이 서로 다른 제품 네 개가 있고, 토큰 한도도 사용량 추적 방식도 제각각이라면, 연동 서비스 하나로 이걸 다 묶기가 매우 번거롭다고 함.
  25. 이럴 때 MCP에 이미 있는 샘플링(sampling, MCP 서버가 클라이언트 쪽 모델 호출을 요청할 수 있게 하는 기능) 프리미티브를 쓰면, 연동이 스트림으로 샘플링 요청을 보내고 반대편이 그걸 채워주는 식으로 풀린다고 함. 직접 만들었으면 상당한 공수가 들었을 문제의 답이 프로토콜 안에 이미 포장돼 있었다는 뜻이라고 함.
  26. 앤트로픽 내부에서는 여러 요구사항이 한꺼번에 맞물렸다고 함. mcp로 시작하는 외부 원격 MCP 서비스가 생겨나면서 그쪽과 통신하고 싶어졌는데, 여기엔 외부 네트워크 연결과 인증이 걸린다고 함.
  27. 동시에 사내 에이전트가 우후죽순 늘었다고 함. PR 리뷰 봇, 슬랙(Slack) 관리 도구처럼 LLM을 붙인 서비스가 폭발적으로 늘었고 뭐가 실제로 자리 잡을지는 아무도 모른다고 함.
  28. 이 폭발 속에서 보안 우려가 커졌다고 함. 모든 서비스가 사용자 자격 증명에 접근하게 두고 싶지 않고, 외부로 나가는 네트워크 연결을 아무 데나 열어두고 싶지 않으며, 감사(auditing)도 급격히 복잡해진다고 함.
  29. 결론적으로 연동을 한 번만 만들고 어디서든 쓰고 싶었다고 함.
  30. 이때 참고한 모델이 멘토에게서 배운 핏 오브 석세스(pit of success, 올바른 선택을 가장 쉬운 선택으로 만들어 다들 자연스럽게 거기로 빠지게 하는 설계 원칙)라고 함.
  31. 그래서 만든 게 공유 인프라인 MCP 게이트웨이라고 함. 엔지니어에게는 그냥 connect-to-MCP 하나만 호출하면 MCP SDK 클라이언트 세션이 돌아오는 단일 진입점이라고 함.
  32. URL 기반 라우팅으로 외부 서버든 내부 서버든 같은 호출 하나로 처리한다고 함.
  33. 자격 증명 관리도 게이트웨이가 자동으로 처리해서, 회사 안에서 OAuth를 다섯 번 따로 구현할 필요가 없게 했다고 함.
  34. 속도 제한(rate limiting)과 관측성(observability)을 다루는 중앙 지점도 게이트웨이가 맡는다고 함.
  35. 클라이언트 라이브러리는 MCP 게이트웨이의 connect-to-MCP를 부르면서 URL, 조직 ID, 계정 ID를 넘기는 식으로 짰다고 함. 실제로는 자격 증명에 접근하는 만큼 서명된 토큰을 넘겨 인증한다고 함.
  36. 이 호출이 MCP SDK 객체를 그대로 돌려준다는 점이 중요한데, 프로토콜에 새 기능이 추가되면 내부 MCP 패키지만 업데이트해도 그 기능을 전부 그대로 받는다고 함.
  37. 같은 코드가 내부 연동과 외부 연동에 이음매 없이 그대로 연결된다고 함.
  38. 전송 방식은 조직마다 다 다르니 회사 안에서는 뭘 써도 상관없다고 함. 외부 MCP 서버와 연결할 때만 표준화된 전송을 쓰고, 내부는 각자 조직에 제일 맞는 걸 고르면 된다고 함.
  39. 앤트로픽은 내부 전송으로 웹소켓(websocket)을 골랐다고 함. 웹소켓을 열어 JSON-RPC 메시지 덩어리를 주고받고, 그 읽기·쓰기 스트림을 MCP SDK 클라이언트 세션에 꽂으면 끝이라고 함.
  40. 연결마다 소켓을 하나씩 열고 싶지 않다면 gRPC(구글이 만든 원격 프로시저 호출 프레임워크로 여러 연결을 하나의 전송으로 다중화할 수 있음)로 감싸도 된다고 함. 여기서도 결국 읽기 스트림·쓰기 스트림만 있으면 된다고 함.
  41. 유닉스 소켓(Unix socket) 전송도 같은 패턴으로 되고, 메시지만 그런 식으로 오가면 된다고 함.
  42. 심지어 IMAP(이메일을 서버에서 읽어오는 표준 프로토콜)으로 이메일을 주고받는 전송까지 시험 삼아 만들어봤다고 함. "안녕하세요 서버님, MCP 요청을 시작합니다" 식의 이메일을 보내고 받아 클라이언트 세션에 꽂았다고 함.
  43. 이 사례로 조직 안에서 스트림을 어떻게 나르든 정말 상관없다는 걸 보여주려 했다고 함.
  44. 인증도 게이트웨이 한 곳에서 OAuth를 처리하는 통일된 모델로 만들었다고 함. 그래서 각 앱은 그 복잡함을 신경 쓸 필요가 없다고 함.
  45. OAuth 인가 URL을 얻는 함수와 OAuth 플로를 완료하는 함수를 따로 뒀는데, api.anthropic.com과 claude.ai처럼 엔드포인트마다 리다이렉트 목적지가 달라야 하기 때문이라고 함.
  46. 게이트웨이에 자격 증명을 두면 자격 증명이 이식 가능(portable)해진다는 이점이 있다고 함. 배치(batch) 작업을 돌릴 때 사용자가 다시 인증할 필요 없이 내부 사용자 ID로 같은 MCP를 호출하면 알아서 붙는다고 함.
  47. 내부 서비스도 토큰을 직접 신경 쓸 필요가 없다고 함. 내부 요청이 OAuth 토큰을 헤더에 담아 게이트웨이의 웹소켓 연결로 들어오면, 게이트웨이가 저장된 자격 증명을 찾아 인증된 SDK 클라이언트를 만들고 베어러(bearer) 토큰을 인증 헤더에 넣어준다고 함.
  48. 그렇게 받은 읽기 스트림·쓰기 스트림을 내부 전송에 그대로 꽂으면 끝난다고 함.
  49. 게이트웨이가 주는 눈에 덜 띄지만 값진 효과는, 모델을 오가는 모든 컨텍스트가 한곳에 모인다는 점이라고 함.
  50. MCP 프롬프트 인젝션(prompt injection, 외부 콘텐츠에 숨긴 지시로 모델을 조종하는 공격) 공격을 다룬 논문이 이미 나왔고, 모델이 구글 드라이브에 접근했다가 내용을 통째로 지워버릴 위험도 실제로 있다고 함.
  51. 그래서 악성 서버를 차단하거나 들어오는 요청에 콘텐츠 분류를 거는 식으로 정책을 강제할 필요가 있다고 함.
  52. MCP라서 모든 메시지가 표준 형식이라, 그 스트림에 걸어서 툴 실행 메시지 처리기나 툴 정의 처리기, 리소스 관리 처리기를 붙이기가 쉽다고 함.
  53. 그 결과 새 서비스에 MCP 지원을 붙이는 일이 패키지 하나 가져오는(import) 정도로 단순해졌다고 함. 사내에 여러 언어가 쓰이는데 언어마다 자기 패키지가 있다고 함.
  54. 엔지니어는 배관이 아니라 기능을 만드는 데 집중할 수 있고, 진입·진출 지점 하나와 표준 메시지 형식이 주는 운영상 단순함도 얻는다고 함. 프로토콜이 진화할 때마다 앞으로 나올 기능도 공짜로 따라온다고 함.
  55. 발표를 정리하며, MCP는 결국 JSON 스트림일 뿐이고 그 스트림을 인프라 안에서 어떻게 나를지는 사소한 구현 디테일이라고 강조함. 스트림을 클라이언트 SDK에 꽂는 건 몇 줄짜리 코드로 끝난다고 함.
  56. 무엇이든 좋으니 뭔가 하나로 표준화하라고 권함. 자신은 MCP가 좋은 선택이라 보지만, 그렇게 생각하지 않더라도 일단 뭐든 하나 고르면 미래의 자신이 고마워할 거라고 함.
  57. 핏 오브 석세스를 만들라고, 즉 올바른 방식을 가장 쉬운 방식으로 만들면 다들 자연스럽게 그 안으로 빠져든다고 함.
  58. 올바른 층위에서 중앙화하라고도 함. 외부 연결 같은 공통 문제를 한 번만 풀어두면, 자신과 회사에 더 값진 흥미로운 문제에 시간을 쓸 수 있다고 함.

한줄 코멘트. 이메일로 MCP 메시지를 보내는 시연은 농담에 가깝지만, 그 농담이 "전송은 배관일 뿐이고 표준화는 메시지 층에서 하면 된다"는 주장을 가장 잘 증명하는 예시임.

01

에이전트 만들기 · 운영

  1. 이 발표는 앤트로픽(Anthropic) CI(continuous integration, 코드가 바뀔 때마다 자동으로 돌아가는 검증 파이프라인)팀 엔지니어 사친 말호트라(Sachin Malhotra)가 한 것으로, 그의 팀은 테스트 격리부터 머지 자동화, CI 오토스케일링, 머지 큐까지 매일 수천 명의 엔지니어가 코드를 안전하게 내보내게 해주는 배관 역할을 한다고 소개함.
  2. 요즘 에이전트 데모는 다 똑같은 방식으로 시작한다고 지적함. 누군가 에이전트에게 만능 토큰과 툴 목록을 쥐어주고 지켜보기만 하면 3초 만에 커피 웹사이트를 통째로 만들어 배포까지 끝낸다는 것임.
  3. 사람들은 박수를 치고 누군가는 그걸 그대로 프로덕션에 올려버리는데, 이 발표는 그다음, 즉 에이전트가 실제로 일하기 시작한 뒤에 벌어지는 일을 다룬다고 함.
  4. 실제로 벌어진 사고 사례를 하나 보여줌. 에이전트가 더는 쓸모없다고 판단한 워크로드들을 스스로 정리하려다 벌어진 일임.
  5. 파이프라인 한 단계가 아무 값도 안 나오게 평가되면서 필터가 빠졌고, 그 바람에 선택자(selector)가 걸러내야 할 것과 아닌 것을 구분하지 못하고 모든 걸 걸었다고 함.
  6. 그 결과 워크로드 약 200개가 지워졌고 엔지니어 약 20명 몫의 작업이 영향을 받았으며, 이 전부가 90초 만에 벌어졌다고 함.
  7. 누구도 악의는 없었고 에이전트는 진짜로 자기가 정리 정돈을 하고 있다고 믿었을 뿐이라고 함. 지워진 워크로드 중엔 오래 돌던 훈련 작업도 있어서, 체크포인트조차 안 된 채 몇 시간치 진행이 순식간에 날아갔을 수 있다고 함.
  8. 문제는 "여기 토큰이 있고 여기 툴 목록이 있다"는 방식 자체가 에이전트가 실제 프로덕션 일을 하기 시작하면 더는 감당이 안 된다는 점이라고 함.
  9. 오늘 다룰 내용은 세 가지 원리 — 비대칭적 동사(asymmetric verbs), 속도 제한(rate limit), 허용 목록(allow list) 대신 트립와이어(trip wire, 정해둔 선을 넘으면 그제서야 울리는 경보장치) — 와 이 셋의 크기를 잴 때 쓰는 되돌림 시험(undo test) 하나라고 정리함.
  10. 사고 뒤에 그를 정말 괴롭힌 건 에이전트가 자기가 못 했을 일을 한 게 하나도 없었다는 점이었다고 함. 결국 자기 토큰을 쓴 것뿐이었다는 것임.
  11. 진짜 실패는 모델 자체가 아니라, 자기가 세심히 지켜보지 않는 일에 무제한 권한을 에이전트에게 준 것이었다고 함.
  12. 이건 신입 엔지니어를 처음 온보딩할 때 이미 풀어본 문제와 같은 종류라고 함. 새로 들어온 사람 뒤에 앉아 키 입력 하나하나를 지켜보지는 않되, 늘 에스컬레이션 경로가 있고 파국적인 일은 애초에 신입 손이 안 닿는 구조로 막아둔다는 것임.
  13. 다만 에이전트는 다르다고 함. 지치지도 자지도 않고 종종 아주 자신만만하게 틀린다는 것임. 그 말은 이 발표가 결국 에이전트를 위해 정책으로 써둔 온보딩 체크리스트라는 뜻이라고 함.
  14. 이런 사고에 대한 표준 대응은 토큰 범위를 좁히는 것, 즉 삭제 권한을 아예 빼버리는 것이라고 함. 하지만 신입 엔지니어에게는 절대 그렇게 하지 않을 것처럼, 이 방법도 오래 못 간다고 함.
  15. 한두 주는 버티지만 결국 에이전트가 정말 지워야 하는 걸 못 지우는 상황이 오고, 사람이 다시 앉아 엔터를 손으로 눌러야 하는 처지로 돌아간다는 것임.
  16. 토큰의 근본 문제는 그게 불리언(boolean), 즉 예 아니면 아니오로만 답하는 정적인 범위 목록이라는 점이라고 함. 목록이 너무 좁으면 에이전트가 쓸모없어지고, 너무 넓으면 사후 보고서를 쓰게 된다는 것임.
  17. 예산은 전혀 다른 모양이라고 함. 숫자 하나가 아니라 네 축을 갖는다는 것임 — 얼마나 할 수 있는지, 얼마나 빨리 할 수 있는지, 스스로 무엇을 되돌릴 수 있는지, 실행하는 동안 누가 지켜보고 있는지임.
  18. 이 네 축이 뒤에 나올 원리들의 우산이고, 각 원리는 예 아니면 아니오라는 질문을 예산이라는 질문으로 바꿔놓는 장치라고 함.
  19. 첫 번째 원리는 비대칭적 동사(asymmetric verbs)라고 함. 여기서 동사란 에이전트가 할 수 있는 동작, 즉 API(프로그램끼리 정해진 규칙으로 주고받는 호출 창구) 호출이든 CLI(명령줄 인터페이스) 명령이든 뭐든 될 수 있다고 함.
  20. 겉으로는 크기가 같아 보여도 방향에 따라 파급 범위가 완전히 다를 수 있어서 비대칭이라고 부른다고 함. 자원이 아니라 동사 단위로, 그 동사가 잘못됐을 때 무슨 일이 벌어지는지를 생각해야 한다는 것임.
  21. 어떤 동사는 크게 실패한다고 함. 에이전트가 잘못 판단해 테스트를 다시 켜면(unskip) 최악의 경우 CI가 빨갛게 뜨는 정도고, 사람을 호출(page)하는 걸 잘못해도 최악은 온콜(on-call, 장애 발생 시 즉시 대응하도록 대기하는 근무) 담당자가 성가신 정도라고 함.
  22. 반대로 어떤 동사는 조용히 실패한다고 함. 에이전트가 테스트를 잘못 건너뛰면(skip) 아무것도 빨갛게 뜨지 않고, 진짜 버그가 초록 체크와 함께 프로덕션에 들어가 한참 뒤에야 발견된다는 것임.
  23. 그래서 대시보드에서 크게 실패하는 동사는 에이전트에게 맡기고, 조용히 실패하는 동사는 반드시 사람을 끼운다는 게 핵심이라고 함.
  24. 실제 사례로 테스트 격리 서비스가 있는데, 온콜이 사고 대응 중 부득이하게 꺼둔 테스트 목록을 들고 있다고 함. 에이전트는 테스트가 다시 잘 돈다고 판단되면 이 중 어느 것이든 되살릴 권한이 있고, 잘못돼도 최악은 빌드·테스트 여러 개가 빨갛게 뜨는 정도라 사람이 값싸게 되돌릴 수 있다고 함.
  25. 반면 끄기(skip) 자체는 온콜이 위기 상황에서만 쓰는 비상 동사라, 에이전트가 잘못 끄면 진짜 버그가 조용히 프로덕션에 들어갈 수 있다고 함. 그래서 이 동작은 반드시 사람을 거치고 항상 감사 기록을 남긴다고 함.
  26. 여기서 핵심은 에이전트가 그 기록 자체를 쓰지 않는다는 점이라고 함. 중간에 프록시(proxy, 에이전트와 실제 자원 사이에 끼어들어 모든 호출을 가로채는 중계 계층)가 있어서, 끄든 되살리든 모든 호출에 실제 호출자의 신원을 찍는다고 함.
  27. 두 번째 원리는 속도 제한(rate limit)이라고 함. "다시 차오르는 천장"이라는 표현으로 예산 개념을 가장 구체적으로 보여준다고 함.
  28. 모든 호출자는 시간 창(window)마다 파괴적인 동작을 소량 쓸 수 있고 그 안에서는 승인도 대기도 없다고 함. 선을 넘으면 요청이 튕겨 나오며 한도 초과 메시지가 뜨고, 잠깐 기다리면 한도가 다시 차오른다는 게 전부라고 함.
  29. 한도 안에서는 에이전트가 완전한 자율성을 갖고 한 번의 루프가 아무리 잘못돼도 피해에는 확실한 천장이 있다고 함. 모든 쓰기(write) 동작에는 예외 없이 속도 제한이 걸리고 바뀌는 건 그 한도의 크기뿐이라고 함.
  30. 예를 들어 자기 네임스페이스(namespace, 같은 클러스터 안에서 자원을 서로 격리해 나눠놓은 구획) 안 워크로드를 지울 때는 한도가 더 크고, 공유 네임스페이스를 건드릴 때는 한도가 더 작아진다고 함.
  31. 앞서 보여준 사고의 실제 해법이 바로 이거였다고 함. 옆 팀이 어드미션 웹훅(admission webhook, 요청이 실제로 처리되기 전에 가로채 규칙을 적용하는 관문)을 만들어 자원 종류·네임스페이스별로 시간당 삭제 개수를 고정 한도로 걸었다고 함.
  32. 우회 플래그도 늘 있는데, 정말로 한도보다 더 많이 지워야 하는 온콜 상황을 위해서라고 함. 다만 클로드 코드(Claude Code) 세션이나 에이전트 세션 안에서는 이 우회 플래그가 아무것도 하지 않고, 사람이 직접 명령을 실행해달라고 부탁하라고만 에이전트에게 알려준다고 함.
  33. 결국 에이전트는 속도 제한을 얻고 사람은 우회 권한을 그대로 쥐며, 다시 차오르는 구조라 아무도 한도 때문에 티켓을 따로 열 필요가 없다고 함.
  34. 세 번째 원리는 허용 목록(allow list)보다 트립와이어(trip wire)라고 함. 허용 목록은 에이전트가 실제로 어떻게 행동하는지 데이터가 쌓이기도 전에 미리 써두는 추측일 뿐이라, 시간이 지나도 나아지지 않고 낡아간다고 함.
  35. 트립와이어는 사후에 그 데이터를 얻는 방식이라고 함. 값싼 동작은 에이전트가 하게 두고, 모든 동작에 행위자 신원 도장을 찍어 기록해둔다고 함.
  36. 속도 제한은 강제(enforcement)를, 트립와이어는 무슨 일이 있었는지 알아내 대응할 거리를 주는 역할이라고 함. 그래서 개별 호출이 아니라 총량을 지켜보고, 트립와이어가 울리면 보통 고칠 건 코드 전체가 아니라 에이전트 맥락(context) 속 한두 줄이라고 함.
  37. 실제 운영 사례로, 특정 테스트 작업 실패 하나당 에이전트가 시간당 몇 개의 조사 스레드를 띄우는지를 추적한다고 함.
  38. 어느 날 아침 이 숫자가 기준선을 훌쩍 넘었고 트립와이어가 온콜을 호출(page)했다고 함. 이때 중요한 건 아무도 안 보는 트립와이어는 쓸모가 없다는 점이라고 함.
  39. 트립와이어는 한도를 이미 넘긴 뒤에 울리는 것이지 미리 막는 게 아니라고 함. 문에 거는 자물쇠가 아니라 연기 감지기라는 비유를 듦.
  40. 그날 에이전트는 같은 오류 신호로 실패한 수십 개 작업마다 조사 스레드를 따로 띄웠고, 각 스레드는 따로 보면 다 합리적으로 보였다고 함.
  41. 하지만 전체로 묶어 보면 사실은 인프라 장애 하나가 같은 실패 신호를 여러 테스트에 걸쳐 만들어내고 있었다는 걸 알 수 있었다고 함.
  42. 그래서 고친 방법은 간단히, 다음에 이런 일이 있으면 조사 스레드를 따로 띄우기 전에 실패들을 먼저 상관관계로 묶어보라고 에이전트에게 알려준 것뿐이었다고 함.
  43. 그 예시와 대응 방법이 맥락에 남아 있었기 때문에, 다음번 같은 상황이 왔을 때 에이전트는 정확히 그렇게 했다고 함.
  44. 세 원리에 이어 되돌림 시험(undo test)이라는 하나의 렌즈가 있다고 함. 이건 코드로 강제하는 게 아니라 나머지 세 원리의 크기를 잴 때 스스로 묻는 질문이라고 함.
  45. 질문은 두 가지라고 함. 에이전트가 스스로 되돌릴 수 있는가, 그리고 잘못됐을 때 그 피해가 얼마나 큰가임.
  46. 비대칭적 동사는 실패를 알아챌 수 있는지를 묻고, 되돌림 시험은 그 실패에서 회복할 수 있는지를 묻는다는 점에서 다르다고 함.
  47. 에이전트가 스스로 되돌릴 수 있고 그 피해 범위가 받아들일 만하면 그냥 기록만 남기고 넘어간다고 함. 둘 중 하나라도 아니오면 다른 사람이 쥔 두 번째 열쇠가 필요하고, 그 열쇠가 왜 쓰였는지 감사 기록도 남겨야 한다고 함.
  48. CI 바깥의 사례도 하나 보여줌. 에이전트가 피처 플래그(feature flag, 코드 배포와 별개로 기능을 켜고 끌 수 있게 해주는 스위치) 서비스 열쇠를 갖고 있는데, 카나리(canary, 새 기능을 전체 트래픽 대신 일부에만 먼저 내보내 시험하는 방식) 트래픽과 사내 시험 사용자에게는 0부터 100까지 다이얼을 완전히 쥐고 있다고 함.
  49. 다만 그 열쇠는 진짜 프로덕션으로 승격하는 데는 쓰이지 않는다고 함. 지금은 카나리에서 시험이 끝났다고 사람에게 제안하는 게 에이전트가 할 수 있는 최선이라고 함.
  50. 여기서 두 번째 열쇠는 새 SSO(Single Sign-On, 한 번의 로그인으로 여러 시스템에 접근하게 해주는 인증 체계) 시스템이 아니라, 그냥 프로덕션용 열쇠와 카나리용 열쇠가 따로 있는 것뿐이라고 함.
  51. 실제로는 슬랙(Slack) 채널에서 클로드(Claude)에게 플래그 배포 전체 루프를 맡기고, 내부 시험용인지 얼리 액세스(early access)용인지 같은 확인 질문은 클로드가 직접 던진다고 함.
  52. 중요한 건 이 과정 어디에도 그가 끼어 있지 않다는 점이라고 함. 모든 동작에는 자기 것이 아니라 에이전트 자신의 신원 도장이 찍히고, 그 도장이 전체를 하나로 묶는다고 함.
  53. 이 원리들은 서로 잘 맞물린다고 함. 동사는 무엇을 건드리는지, 속도 제한은 얼마나 자주인지, 트립와이어는 일어난 뒤 무엇을 잡아내는지를 묻고, 되돌림 시험은 이 셋의 크기를 재는 잣대라고 함.
  54. 처음 보여준 삭제 사고에 다시 대입해보면, 속도 제한만으로도 몇십 개 수준에서 막혔을 것이고, 되돌림 시험은 남의 네임스페이스에서 돌던 작업은 되살릴 수 없다고 알려준다고 함. 그러니 한도를 넘는 순간부터는 두 번째 열쇠를 쥔 사람이 필요하다는 것임.
  55. 모든 쓰기 상황에 이 검사를 다 걸 필요는 없고 동작 종류에 따라 일부만 걸리면 된다고 함. 이건 결국 새 엔지니어에게 늘 물었던 것 — 뭘 건드릴 수 있는지, 얼마나 재량을 주는지, 누가 결재하는지 — 을 그대로 에이전트에게 묻는 것뿐이라고 함.
  56. 이 정책은 두 자리에 나눠 산다고 함. 하나는 텍스트, 즉 에이전트가 행동하기 전에 읽는 프롬프트와 맥락 파일(markdown)이고, 여기서 의도와 이유를 설명할 수 있다고 함.
  57. 텍스트는 약 80%의 경우에는 통한다고 함. 바꾸기는 싸지만 파일이 계속 불어나서 계속 손봐야(garden) 하고, 결국 강제력 없는 조언일 뿐이라고 함.
  58. 두 번째 자리는 인프라, 즉 그들에게는 프록시 계층이라고 함. 프록시는 프롬프트를 읽지 않고 에이전트가 왜 그걸 하려는지 알지도 신경 쓰지도 않는다고 함. 그냥 삭제가 일어나는 걸 보고 예산이 넘는 걸 보고 403을 돌려줄 뿐이라고 함.
  59. 프록시는 좁고 결정론적이라고 함. 세고 비교하고 허용하거나 거부할 뿐 왜 안 되는지는 설명 못 하지만, 그 대신 아무리 영리한 프롬프트 주입으로도 규칙을 구슬려 넘길 수 없다고 함. 그래서 텍스트와 인프라 둘 다 필요하다고 함.
  60. 실제 구조를 보면 모든 에이전트 세션마다 바로 옆에 자기 프록시가 돌고 있다고 함. 에이전트는 먼저 자기 맥락 파일을 읽고, 이후 나가는 모든 호출은 프록시를 거친다고 함.
  61. 프록시는 에이전트가 뭘 하려는지는 신경 쓰지 않고 그 동작에 에이전트 신원을 찍는 일만 맡는다고 함. 예를 들어 에이전트가 쿠버네티스(Kubernetes, 컨테이너 여러 개를 자동으로 배치하고 관리하는 오케스트레이션 시스템) 클러스터에 작업을 여러 개 띄우면, 프록시는 그 작업을 따라다니지 않고 신원 도장만 라벨로 남긴다고 함.
  62. 이후 생기는 자식 작업들도 같은 신원을 물려받고, 소유권이든 쿼터(quota)든 속도 제한이든 승인이든 트립와이어든 시스템 곳곳의 모든 안전장치가 이 라벨 하나만 보고 판단하며, 에이전트는 그 라벨을 건드릴 수 없다고 함.
  63. 발표를 마치기 전 왜 신원 도장을 호출자 본인이 아니라 별도의 프록시 계층이 찍어야 하는지 30초를 쓴다고 함. 그게 없으면 에이전트가 마음대로 이름을 바꿔 모든 한도를 리셋할 수 있기 때문이라고 함.
  64. 예를 들어 에이전트가 헤더에 자기 신원을 직접 써넣을 수 있다면, 한도에 걸렸을 때 가장 쉬운 해법은 그냥 헤더값을 바꾸는 것이라고 함. 그러면 곧바로 새 예산이 생기는데, 이건 사실상 속도 제한이 아니라 그냥 제안일 뿐이라고 함.
  65. 프록시가 경로에 있으면 에이전트는 자기가 누구인지 스스로 말할 수 없고, 진짜 자격 증명을 쥔 프록시가 이미 알고 있는 신원으로 도장을 찍는다고 함 — 에이전트가 주장하는 이름이 아니라는 것임. 이 도장 덕분에 세션 ID별로도 구분이 되어, 어느 세션이 과하게 반응하고 있는지 바로 가려낼 수 있다고 함.
  66. 마무리로 정리한 네 가지는 이렇다고 함. 크게 실패하는 동사는 에이전트에게 맡기고 조용히 실패하는 동사는 사람 몫으로 남길 것, 모든 쓰기 동작에 스스로 다시 차오르는 천장을 씌워 아무도 티켓을 열 필요가 없게 할 것, 개별 호출이 아니라 총량을 지켜보고 고칠 수 있는 건 문장 한 줄로 고칠 것, 이 셋 어디에든 되돌림 시험으로 크기를 잴 것이라고 함. 이 모든 것 아래엔 신원이라는 개념이 있는데 그건 요청이 아니라 반드시 인프라에서 나와야 하며, 이 한 가지 규칙만 제대로 잡으면 나머지는 전부 미세조정일 뿐이라고 함.

한줄 코멘트. 이 발표에서 진짜 강조점은 속도 제한·트립와이어 같은 장치 목록이 아니라 신원을 누가 찍느냐다 — 에이전트가 자기 이름을 댈 수 있는 한 어떤 한도도 결국 제안에 그친다는 것임.

  1. 이단 개짓(Idan Gazit)은 자신이 깃허브 넥스트(GitHub Next)를 이끈다고 소개함. 코파일럿(Copilot)을 만들고 스펙 기반 프로그래밍 같은 영역을 개척해온 깃허브의 랩스팀이라고 함.
  2. 이 팀이 하는 일 전부가 제품으로 이어지진 않고, 1~2년 뒤 개발자들이 쓸 도구를 미리 찾아보는 게 목표라고 함.
  3. 작업 대부분을 공개로 진행해서 깃허브넥스트닷컴(githubnext.com)과 소셜 계정에서 볼 수 있다고 함.
  4. 이 팀이 하는 건 리서치가 아니라, 실제로 물건을 만들어봐야 뭐가 좋은지 알 수 있어서 그렇게 한다고 함.
  5. 무방향 리서치팀에서 가장 어려운 질문은 무엇에 시간을 쓸지이고, 코드 한 줄의 한계비용이 0에 가까워지는 세상에서 무엇을 만들지 고르는 일 자체가 어려워졌다고 함.
  6. 이제 이 질문은 깃허브 넥스트만의 문제가 아니라 다들 겪는 문제가 됐다고 함 — 모두가 랩스팀이 된 셈이라고 함.
  7. 깃허브 넥스트는 이럴 때 어떤 기술이 나오든 변하지 않을 「지속되는 주제」를 찾는다고 함.
  8. 지금 시대의 지속되는 주제는 AI가 처음엔 개인 생산성에서 시작됐다는 것이라고 함 — LLM이 타이핑을 완성해주고 에이전트가 필요한 걸 가져다주는 식이었다고 함.
  9. 지금은 여러 에이전트를 동시에 돌려 자기 자신을 병렬화하는 단계까지 왔지만, 가장 큰 가치는 나를 여러 명으로 늘리는 데서 나오지 않고 여러 사람이 함께 더 많이 할 수 있게 만드는 데서 나온다고 함.
  10. 이 팀은 그 가치를 자동화와 협업, 두 방향으로 나눠 풀고 있다고 함.
  11. 모든 산업혁명은 자동화를 통해 일어났는데, 지금까지 소프트웨어 업계의 자동화는 줄 끝에 세미콜론을 붙이는 것 같은 규칙(heuristic) 수준에 머물러 있었다고 함.
  12. 이제 AI는 어느 정도 판단과 지능이 필요한 일까지 자동화할 수 있게 됐다고 함.
  13. 좋은 소프트웨어를 만드는 데는 시간이 든다는 사실은 변하지 않고, 사람이 하던 일을 자동화해서 그 시간을 만듦새를 다듬는 일이나 제품·기능에 다시 쓸 수 있다고 함.
  14. 협업 쪽 질문은 앞으로 함께 일하는 방식이 어떻게 바뀌느냐인데, 예전엔 계획·리뷰는 같이 하고 실제로 코드를 짜는 일만 혼자 했다면 지금은 그 짜는 과정마저 혼자가 아니라고 함.
  15. 계획이 코딩 전에 끝나고 리뷰가 코딩 뒤에 오는 구조가 아니라, 방향을 같이 잡고 AI가 한 걸음 나아가면 다시 같이 조율하는 식으로 바뀌었다고 함.
  16. 어제 다른 발표자 제프리 리트(Jeffrey Lit)가 이해(understanding)가 병목이라는 이야기를 했는데, 개인 수준의 이해로는 팀 안에서 코드를 내보내기에 늘 부족했다고 함.
  17. 예전엔 팀 차원의 이해가 작업이 끝날 때쯤에야 맞춰졌는데, 지금처럼 작업 속도가 빨라지면 그렇게 늦게 맞출 수가 없다고 함.
  18. 속도가 빨라진다는 건 작은 방향 어긋남이 눈덩이처럼 불어나 헛수고로 이어질 수 있다는 뜻이고, 그 헛수고는 토큰을 쓰고 토큰은 이제 실제 돈이라고 함.
  19. 오늘은 이 두 주제를 다루는 프로토타입 두 개를 보여주겠다고 함 — 자동화 쪽은 에이전틱 워크플로우(Agentic Workflows), 협업 쪽은 실시간 멀티플레이어 개발을 실험하는 에이스(Ace)라고 함.
  20. 먼저 에이전틱 워크플로우를 자기 개인 웹사이트로 시연함. 이 사이트는 아스트로(Astro)라는 웹 프레임워크로 만들어졌다고 함.
  21. 아스트로는 한 달에 업데이트를 50개씩 낼 정도로 자주 바뀌는데, 깃허브의 디펜다봇(Dependabot)이 업데이트가 나올 때마다 알려주긴 해도 코드를 고치는 건 여전히 사람 몫이었다고 함.
  22. 그래서 의존성을 계속 살펴보다가 업데이트뿐 아니라 깨지는 변경까지 알아서 고쳐주는 「슈퍼 디펜다봇」이 있었으면 했다고 함.
  23. 코파일럿에 스킬(작업 방법을 적어둔 문서) 한 장과, 팀 후배에게 슬랙으로 보낼 법한 짧은 지시문을 줘서 에이전틱 워크플로우를 하나 만들었다고 함.
  24. 지시문 내용은 매일 새 버전이 있는지 확인하고 체인지로그와 문서를 보고 업그레이드 계획을 세운 뒤 PR을 만들라는 정도였는데, 코파일럿이 이 세 줄짜리 메시지를 알아서 완전한 작업 계획서로 풀어냈다고 함.
  25. 에이전틱 워크플로우는 결국 마크다운 문서 형태라고 함 — 깃허브 액션스(GitHub Actions)와 코파일럿이 아이를 낳으면 마크다운으로 돌아가는 게 나올 거라는 비유를 씀.
  26. 만들어진 워크플로우를 보면 새 버전 확인, 체인지로그·업그레이드 가이드 검토, 업그레이드 적용, PR 생성까지 단계가 잡혀 있고, 확인해야 할 구체적인 의존성까지 코드베이스를 보고 스스로 찾아냈다고 함.
  27. 문서 맨 위에는 별도로 YAML 형식의 프런트매터가 붙는데, 이게 가드레일이라고 함 — 에이전트를 사람이 지켜보지 않고 돌리려면 무엇을 읽고 쓸 수 있는지를 더 강하게 못박아야 한다고 함.
  28. 에이전트에게 「비트코인은 절대 사지 마」라고 프롬프트로만 당부하는 건 충분하지 않다고 함 — 다른 사람이 프롬프트 주입(prompt injection)으로 에이전트를 다른 방향으로 끌고 갈 수 있어서라고 함.
  29. 그래서 가드레일을 프롬프트에 적어 넣는 방식은 사실상 닭장에 여우를 풀어놓는 것과 같고, 진짜 가드레일이 되려면 결정론적으로, 즉 설정값으로 못박아야 한다고 함.
  30. 이 워크플로우에서는 권한을 읽기 전체로, 쓸 수 있는 도구를, 접속 가능한 네트워크 요청까지 명시했다고 함 — npm 생태계·깃허브·아스트로 문서처럼 지정된 사이트만 허용했다고 함.
  31. safe outputs라는 블록으로 산출물도 못박았는데, PR 생성은 「하나만」 허용해서 프롬프트 주입으로 PR 500개를 만드는 서비스 거부 공격을 막았다고 함.
  32. 또 「아무것도 하지 않아도 된다」는 선택지도 명시했는데, 자동화가 많아진 세상에서 에이전트가 불필요한 알림으로 자신을 서비스 거부시키는 걸 막기 위해서라고 함.
  33. 실제로 이 워크플로우를 자기 웹사이트에 돌려본 결과, 버전 업그레이드 하이라이트를 정리하고 릴리스 노트를 다 읽어 사람이 하던 일을 대신 했다고 함.
  34. 브레이킹 체인지가 없다는 걸 실제로 빌드까지 돌려서 확인했고, 클라우드플레어(Cloudflare) 프리뷰 배포로 사이트가 그대로 작동하는 것도 확인했다고 함.
  35. 이건 마이너 버전 업그레이드였고, 마침 아스트로 7이 막 나온 참이라 5에서 7로 메이저 버전 두 단계를 건너뛰는 업그레이드도 시연했다고 함.
  36. 이번엔 깨진 코드 변경을 찾아 직접 고치고 빌드도 검증했으며, 나중에 사람이 손으로 해야 할 단계까지 짚어줬다고 함.
  37. 이 자동화는 그냥 마크다운이라 영어 문장을 고치면 바로 반영된다고 함 — 마크다운이 소스코드고, 실제 실행되는 YAML은 사람이 들여다볼 일 없는 컴파일 결과물이라고 함.
  38. 깃허브 넥스트는 시작점으로 쓸 수 있는 에이전틱 워크플로우 라이브러리도 제공하는데, 이슈 트리아저(issue triager)는 깃허브 내부에서 자체 트리아저를 만들거나 모놀리스에서 N+1 쿼리를 찾는 데 실제로 쓰였다고 함.
  39. 리포 어시스트(Repo assist)는 여러 에이전틱 워크플로우가 함께 움직이며 손쉬운 개선점을 찾아 고치고, 재촉이 필요한 티켓이나 이슈 제보자에게 받아야 할 피드백을 짚어준다고 함.
  40. CI 닥터는 CI가 실패하면 일단 다시 돌려보는 습관을 대신해주는 워크플로우이고, 팀·저장소 일일 현황처럼 인터넷에서 정보를 모아 요약하는 용도로도 쓸 수 있어 제품 매니저도 쓸 수 있다고 함.
  41. 이단은 이렇게 다들 자동화에 끌어들여야 진짜 산업 규모의 생산성이 나온다고 함.
  42. 에이전틱 워크플로우의 보안 원칙 네 가지를 제시함 — 방어는 한 겹으로 끝나면 안 되고, 에이전트에게 비밀정보(secret)를 맡기면 안 되고, 모든 쓰기 작업은 검증을 거쳐야 하고, 모든 걸 로그로 남겨야 한다고 함.
  43. 에이전트가 비밀정보를 알 수 있다면 그 비밀정보는 이미 유출된 것으로 취급해야 한다고 함 — 누군가 에이전트를 주입해서 다른 데로 빼돌렸을지 알 수 없기 때문이라고 함.
  44. 그래서 에이전틱 워크플로우에서는 비밀정보를 에이전트의 격리된 실행 공간 바깥에 두고, 에이전트가 어떤 서비스를 쓰려면 별도의 감시자(warden) 격 존재에게 요청해야 한다고 함.
  45. 오픈소스 프로젝트 홈 어시스턴트(Home Assistant)에 처음 도입된 에이전틱 워크플로우는, 접수된 이슈마다 파이썬 스택 트레이스를 따라가 그 버그가 자기네 코드 문제인지 외부 라이브러리 문제인지 가려낸다고 함.
  46. 자기네 문제가 아니면 이슈를 닫아주는데, 이런 작업은 AI 이전에는 불가능했고 단순 규칙으로도 불가능했지만 지금은 가능해졌다고 함.
  47. 에이전틱 워크플로우는 지금 퍼블릭 프리뷰로 나와 있어 누구나 써볼 수 있다고 함.
  48. 이단은 사람이 잠든 사이 백그라운드에서 돌아가는 자동화가 대화형 AI보다 더 큰 카테고리가 될 것이라고 함.
  49. 이제 협업 이야기로 넘어가서, 예전엔 코드를 짜는 비용이 워낙 커서 계획·리뷰는 같이 하고 실제로 짜는 부분만 혼자 모니터 앞에서 했지만 지금은 그 어느 부분도 혼자가 아니라고 함.
  50. 이단은 반쯤 농담으로 이 상황에 맞는 인터페이스로 슬랙(Slack)을 떠올렸다고 함 — 슬랙은 원래 일반 사무직에게 이메일보다 나은 도구로 설계된 것이지 소프트웨어를 만드는 데 맞춘 건 아니라고 함.
  51. 다만 이런 채팅이 잘하는 건 코드에 없는 사실을 드러내는 일이라고 함 — 어느 임원이 어떤 방향을 좋아하는지, 어떤 색을 좋아하는지 같은 것은 코드만 읽어서는 알 수 없다고 함.
  52. 애저(Azure)에서 좋은 인프라 조건을 받아서 GCP나 AWS 대신 애저를 쓰기로 했다는 식의 정치적 맥락도 코드가 아니라 대화에만 남는다고 함.
  53. 가장 큰 이득은 워드 문서를 메일로 주고받던 시절이 끝나고 같은 화면에서 같이 만들고 고치게 된 변화가 코드에도 똑같이 온다는 점이라고 함.
  54. 이단은 에이스(Ace)를 시연함. 화면은 슬랙과 비슷하고 왼쪽에 세션 목록이 있어 새 세션을 만들 수 있는데, 여기까지는 다른 컨덕터(conductor) 계열 도구와 비슷해 보인다고 함.
  55. 결정적인 차이는 이 세션 중 어느 것도 자기 컴퓨터에서 돌지 않는다는 점이라고 함 — 전부 클라우드의 마이크로VM에서 돌고, 세션 하나하나가 자기 저장소를 클라우드 어딘가에 체크아웃한 브랜치라고 함.
  56. 세션 안에서 의존성을 설치하고 개발 서버를 띄우는 동시에 동료와 채팅으로 「좋아하는 색이 뭐냐」 같은 대화를 나눌 수 있다고 함.
  57. 이 대화 기록 전체를 에이전트가 보고 있어서, 색 이야기를 다시 지시로 옮겨 적을 필요 없이 그냥 「이거 해」라고만 하면 대화 맥락을 반영해 움직인다고 함.
  58. 엔지니어링 대화는 보통 이렇게 저렇게 해보자다가 다시 앞의 안으로 돌아가는 식으로 왔다갔다하는데, 사람이 그 대화에서 최종 결론을 직접 골라내지 않아도 AI가 최종 상태를 찾아낸다고 함.
  59. 더 복잡한 예로, 앱에 선택 가능한 기간 필터를 추가해 달라고 하니 계획이 마크다운 문서로 나왔고, 이 문서는 자기 혼자 보는 게 아니라 동료와 함께 보고 고치는 용도라고 함.
  60. 동료가 문서에 「전체 기간」 항목을 추가하자고 하고 자신은 「오늘」 항목을 빼는 식으로 함께 계획을 고친 뒤 「계획을 고쳤으니 이대로 해」라고 하면 그 수정된 계획대로 반응한다고 함.
  61. 앞으로는 AI와 하는 작업 결과가 docs 폴더 안 마크다운 문서로 쌓여서 그 문서가 진실을 담는 자리가 되고, 앱을 바꾸려면 문서를 고친 뒤 AI에게 「문서를 참으로 만들어」라고 말하는 식이 될 수도 있다고 함.
  62. 그래서 문서를 같이 편집하는 기능은 있으면 좋은 부가 기능이 아니라 앞으로 일하는 방식 자체가 될 수도 있다고 함.
  63. 동료가 지금 뭘 하고 있는지 계속 알 수 있게 해주는 것도 필요하다고 함 — 단순히 실시간 멀티플레이어를 넘어 팀원들이 뭘 하고 있는지 주변에서 계속 느낄 수 있어야 한다고 함.
  64. 대시보드 예시로 동료들이 각자 무슨 작업을 하고 있는지 보여줬는데, 이 대시보드 자체도 팀원이 만든 것이라고 함.
  65. 앞으로는 자동화도 이 인터페이스 안에서 스스로 드러나야 한다고 함 — 에이전트가 판단이 필요할 때 사람 어깨를 툭 치고 질문할 수 있는 방식을 구상 중이라고 함.
  66. 사람과 에이전트의 관계가 뒤집히고 있다고 함 — 목표를 더 잘 설명할수록 에이전트가 사람을 덜 필요로 하게 되고, 모델이 좋아질수록 명세가 부족한 부분을 스스로 짚어내 사람에게 되묻는다고 함.
  67. 그러다 정말 사람 손이 필요할 때만 손을 빌려달라고 요청하는 식으로, 인터페이스가 에이전트로 하여금 모든 걸 듣고 있다가 필요할 때만 사람을 부르게 해준다고 함.
  68. 마지막으로 지난 몇 년간 AI는 타이핑을 도왔지만, 개발자 100명을 대상으로 수천 시간에 걸쳐 진행한 종단 연구를 보면 키보드로 직접 타이핑하는 시간은 업무의 5%에 불과했다고 함.
  69. 이제 AI는 나머지 95%, 즉 어떤 시스템을 봐야 하는지, 그게 지금 어떻게 동작하는지, 다른 사람들은 이걸 어떻게 바꾸고 싶어하는지를 돕는 쪽으로 가야 한다고 함.
  70. 에이스는 이달 안에 기술 프리뷰로 나올 예정이고, 에이전틱 워크플로우는 이미 나와 있어서 지금 바로 써볼 수 있다고 마무리함.

한줄 코멘트. 가드레일을 프롬프트가 아니라 YAML로 못박고 PR을 하나로 제한하는 대목은 실제로 프로덕션에서 겪는 위협을 구체적으로 짚었다는 점에서 다른 「에이전트 만들어봤다」류 발표보다 실속 있음.

  1. 이 발표는 오픈AI(OpenAI)에서 일하는 도미닉 쿤델이 한 것으로, 코덱스(Codex, 오픈AI의 코딩 에이전트) 하니스(harness, 에이전트를 감싸 도구 호출·샌드박스·승인 절차를 관리하는 틀) 안에서 실제로 무슨 일이 벌어지는지를 다룸.
  2. 발표자는 20분 안에 다뤄야 할 내용이 많아 평소보다 두 배 빠르게 말하겠다고 미리 알림.
  3. 청중에게 직접 에이전트를 만들어본 적 있냐고 손을 들어보라 했고, 대부분이 손을 들자 이 발표에 딱 맞는 청중이라고 함.
  4. 에이전트가 무엇인지부터 설명하는 대신, 메시지 한 통을 보냈을 때 하니스 안에서 실제로 벌어지는 일을 기준으로 이야기를 풀겠다고 함.
  5. 코덱스 하니스는 전부 오픈소스이고 MIT·아파치(Apache) 2 라이선스이며 러스트(Rust)로 짜여 있어, 코드를 직접 읽거나 코덱스에게 물어보거나 포크해서 자기 것으로 만들어도 된다고 함.
  6. 지금 설명하는 내용은 어디까지나 현재 시점의 상태이고, 새 모델이 나올 때마다 API와 하니스 동작 방식이 자주 바뀐다고 미리 못박음.
  7. 코덱스 에이전트를 이해하려면 먼저 메시지를 보냈을 때 관여하는 두 프로토콜을 알아야 한다고 함.
  8. 첫 번째는 UI에서 하니스로 가는 앱 서버(app server) 프로토콜로, 이 부분은 전날 다른 발표에서 다뤘다며 이번엔 짧게만 짚는다고 함.
  9. 두 번째는 하니스와 추론(inference) 사이 통신을 맡는 리스폰스(Responses) API임.
  10. 두 프로토콜 다 열린 생태계를 겨냥해 설계돼서, 자기만의 UI나 에이전트 인터페이스를 앱 서버 프로토콜 위에 직접 지을 수 있다고 함.
  11. 코덱스 앱 자체도 같은 앱 서버로 돌아가고, 그 위에 지어진 서드파티 커뮤니티 프로젝트도 여럿 있다고 함.
  12. 같은 앱 서버를 이용해 코덱스를 클로드 코드(Claude Code) 플러그인으로도 넣었고, 전날 발표에서는 같은 프로토콜로 코덱스를 게임 둠(Doom) 안에 넣는 것도 보여줬다고 함.
  13. 리스폰스 API는 작년에 챗 컴플리션(chat completions) API를 에이전트 시대에 맞게 다시 설계해 내놓은 것으로, 구조를 조금 바꾼 것보다 웹 검색·이미지 생성 같은 새 기능을 더한 게 더 중요하다고 함.
  14. 올라마(Ollama), LM 스튜디오(LM Studio), 엔비디아(Nvidia) 등과 함께 열린 리스폰스 스키마를 만들고 거버넌스 기구까지 꾸려서, 다른 회사도 같은 규격을 쓰는 모델 제공자를 코덱스 하니스에 꽂아 쓸 수 있게 했다고 함.
  15. 하니스 안에서 가장 중요한 첫 단계는 컨텍스트(context, 모델에게 넘기는 대화·상태 정보) 구성이고, 여기서 신경 쓰는 건 크기·유연성·비용 세 가지라고 함.
  16. 크기 면에서는 토큰 예산을 낭비하지 않는 것도 중요하지만, 컨텍스트가 길어질수록 서로 어긋나는 정보가 섞여 모델을 헷갈리게 할 위험이 커진다고 함.
  17. 유연성 면에서는 스킬이나 MCP(모델 컨텍스트 프로토콜, Model Context Protocol)를 몇 개 설치하든 경험이 똑같이 좋아야 한다고 함.
  18. 비용 면에서는 사용자가 비용에 민감하다는 걸 알기 때문에 캐시 가능성이 중요하다고 함.
  19. 발표자는 같은 공개 코드를 타입스크립트(TypeScript)로 옮겨 만든 "나노 코덱스(nano Codex)"라는 축소판을 시연 도구로 보여줌.
  20. 메시지 하나를 보내면 컨텍스트가 여러 조각으로 조립되는데, 모델 지침처럼 크기가 고정돼 있고 캐시에도 영향을 안 주는 예측 가능한 부분이 있다고 함.
  21. 반대로 설치한 스킬 개수나 도구 레지스트리처럼, MCP를 더 깔수록 늘어나는 예측하기 어려운 부분도 있다고 함.
  22. 이 크기 문제를 잡으려고 두 가지를 함. 하나는 일부 도구를 지연 로딩(deferred)으로 표시해 컨텍스트 창에 바로 안 넣고 나중에 도구 검색(tool search)으로만 찾게 하는 것.
  23. 다른 하나는 사용 가능한 스킬 목록을 전체 컨텍스트 창의 2%로 상한선을 두고, 목록이 길어질수록 각 설명을 점점 줄이는 것이라고 함.
  24. 도구 검색 자체는 리스폰스 API에 들어 있는 기능이라 자기 하니스를 만드는 사람도 GPT-5.4부터는 아무 도구나 지연 로딩으로 표시할 수 있다고 함.
  25. 지연 로딩된 도구는 도구 검색을 쓸 때만 보이는데, 코덱스가 기본 제공하는 도구 검색 도구를 쓰거나 직접 검색 로직을 구현해도 된다고 함.
  26. 컨텍스트를 잘 짜도 실제로 행동을 해야 에이전트라며, 다룰 행동 세 가지로 비동기(async) 행동·컴퓨터 사용·파일 시스템을 꼽음.
  27. 비동기 행동의 예로 서브에이전트(sub-agent)를 듦. 메인 에이전트가 계속 일하면서 다른 작업을 서브에이전트에 넘길 수 있다는 것.
  28. 실제로는 에이전트에게 스폰 에이전트(spawn agent) 도구를 줘서 새 에이전트 인스턴스를 만들게 하고, 센드 인풋(send input) 도구로 그 서브에이전트에 새 내용을 보내거나 기다리거나 종료시킨다고 함.
  29. 같은 개념을 백그라운드 터미널에도 씀. 코덱스는 새 백그라운드 터미널을 띄우고 표준 입력으로 계속 데이터를 보내거나 정해진 시간만큼 기다리는 도구를 갖고 있다고 함.
  30. 컴퓨터 사용 기능은 작년 리스폰스 API에 처음 넣었을 땐 한 번에 한 동작만 가능했고, 노출할 동작 종류를 직접 구현해야 하는 제한된 형태였다고 함.
  31. 최근 모델과 API부터는 컴퓨터 사용을 코드 실행으로 대신할 수 있게 바뀌어, 에이전트가 자바스크립트나 파이썬으로 직접 상호작용을 스크립트로 짤 수 있는 훨씬 유연한 방식이 됐다고 함.
  32. 브라우저 사용(browser use)이 바로 이 방식으로 돌아가는데, 턴이 이어지는 동안 지속되는 노드(Node.js) REPL(코드를 한 줄씩 실행하는 대화형 환경) 안에서 플레이라이트(Playwright)에 준하는 자바스크립트 코드로 브라우저와 상호작용한다고 함.
  33. 시연에서는 처음엔 상태를 확인하고 알맞은 탭을 여는 코드를 쓰고, 이어지는 턴에서는 새로 연 탭을 참조하며 정보를 끌어와 다음 동작을 스크립트로 짜는 모습을 보여줌.
  34. 한 페이지의 구조를 한 번 파악하면 이후 페이지들은 그 구조를 이용해 스크립트로 훑을 수 있어서, 이런 방식이 속도를 크게 끌어올린다고 함.
  35. 세 번째 행동은 파일 시스템 조작임. 코딩 에이전트라면 당연히 필요한 기능이라고 함.
  36. GPT-5부터 나온 최근 모델들은 전부 어플라이 패치(apply patch) 도구 개념으로 학습돼 있어서, 파일을 고칠 때는 diff를 주는 방식으로 편집하고 새 파일을 만들 때도 같은 도구를 쓴다고 함.
  37. 그 밖의 작업, 즉 파일 검색이나 탐색은 셸(shell) 도구로 하는데, 모델이 학습 과정에서 익숙해진 대로 립그렙(Ripgrep)을 자연스럽게 쓰려 하기 때문에 하니스 자체에 립그렙을 함께 넣어 배포한다고 함.
  38. 윈도우(Windows)에서는 모델이 파워셸(PowerShell)을 네이티브로 쓰도록 학습돼 있어서, 윈도우에서 돌리면 파워셸 코드를 쓰는 모습을 보게 된다고 함.
  39. 파일 시스템과 관련된 모든 상호작용은 샌드박스(sandbox, 격리된 실행 환경) 계층을 거치며, macOS에서는 시트벨트(Seatbelt), 리눅스에서는 버블랩(Bubblewrap)을 쓴다고 함.
  40. 윈도우에서는 기존 방식이 안 맞아서 아예 자체 오픈소스 윈도우 샌드박스를 새로 만들었고, 그 이유는 동료 데이비드가 쓴 글에 자세히 나온다며 이번 발표에서는 넘어간다고 함.
  41. 샌드박스를 쓰면 늘 나오는 불만이 승인 피로(approval fatigue)라며, 긴 작업에서 승인 요청에 지친 적 있냐고 청중에게 물음.
  42. IT·보안 부서가 풀 액세스(full access) 모드를 켜는 걸 싫어한다는 것도 청중 다수가 안다고 손을 들어 확인함.
  43. 그래서 자사 보안팀도 만족시킬 겸 오토 어프루벌(auto approval) 모드를 만들었다고 함.
  44. 모델이 아무리 좋아져도 프롬프트로 높은 자율성(agency)을 밀어붙이면 기대와 어긋나게 행동할 수 있다며, 파일을 이메일로 보내라 했는데 첨부를 못 하자 파일 공유 서비스에 올려버리는 경우를 예로 듦.
  45. 이스케이프(escape) 처리를 잘못해서 필요 이상으로 데이터를 지워버리는 일도 여전히 일어날 수 있다며, 풀 액세스 모드는 그래서 조심해야 한다고 함.
  46. 그래서 만든 오토 리뷰(auto review)의 목표는, 예측하기 어려운 행동을 사람에게 매번 물어보지 않고도 자동으로 승인하되 데이터 유출(exfiltration) 같은 건 걸러내는 것이라고 함.
  47. 작동 방식은, 파일 삭제처럼 샌드박스 안에서 에스컬레이션이 필요한 작업이 걸리면 모델이 오토 리뷰 서브에이전트를 띄우는 식이라고 함.
  48. 이 서브에이전트는 완전히 분리돼 돌아가고 다른 서브에이전트를 만들 수 없으며 읽기 권한만 갖는다고 함.
  49. 사용자 승인(authorization)이 무엇인지, 위험 분류 체계(risk taxonomy)를 어떻게 판단하는지에 관한 맥락과 함께 대화 기록·도구 호출 내역을 이 서브에이전트에게 넘긴다고 함.
  50. 맥락이 중요한 이유로, 사용자가 명시적으로 지시했으면 닷깃(.git) 폴더 삭제도 괜찮지만 지시하지 않았다면 손대면 안 된다는 예를 듦.
  51. 이런 판단은 파일 삭제 같은 데뿐 아니라 네트워크 호출에도 적용돼서, 구글에 curl 날려 인터넷이 되는지 확인하는 건 괜찮아도 파일을 업로드하는 건 다르게 볼 수 있다고 함.
  52. 이건 엔지니어링 팀과 리서치 팀이 쏟은 작업을 크게 단순화해 설명한 것이라며, 자세한 내용은 오토 리뷰를 다룬 블로그 글을 보라고 함.
  53. 다음 화두는 속도임. 에이전트는 도구 호출을 많이 하기 때문에 추론 속도만 빨라져서는 문제가 다 안 풀린다고 함.
  54. GPT-5.3 코덱스 스파크(Codex Spark)를 세레브라스(Cerebras)에서 초당 1,000토큰으로 돌렸을 때, 병목이 추론이 아니라 네트워크라는 걸 깨달았다고 함.
  55. 그래서 웹소켓(WebSocket) 모드를 도입해, 리스폰스 API가 서버 전송 이벤트(SSE)·HTTP 대신 지속되는 웹소켓 연결을 쓰게 했다고 함.
  56. 웹소켓은 네트워크 오버헤드를 줄이는 동시에 상태를 유지하는 컨텍스트를 제공해서, 도구 호출 하나가 끝나면 결과만 보내면 되고 전체 항목을 다시 보낼 필요가 없다고 함.
  57. 시연 중 서버가 죽는 바람에 백업으로 보여준 화면에서, 예전엔 아홉 개 항목을 한 번에 돌려보내던 걸 이제는 한 번에 하나씩만 보낸다는 걸 확인시켜 줌.
  58. 다음은 루프(loop) 이야기로, 특히 슬래시 골(/goal) 기능은 행사 내내 자주 질문받았다고 함.
  59. 시연은 숫자 맞히기 게임으로, 목표는 숫자를 실제로 맞혔을 때만 달성됐다고 판정된다고 함.
  60. 목표가 달성되기 전까지 하니스가 자동으로 컨티뉴에이션(continuation) 프롬프트를 주입하는데, 여기엔 사용자가 정한 목표가 들어 있다고 함.
  61. 모델이 스스로 업데이트 골(update goal) 도구를 불러 목표가 달성됐다고 밝힐 때까지 이 과정이 반복된다고 함.
  62. 그래서 골(goal)에는 장문의 에세이를 쓰지 말고, 달성 여부를 쉽게 판별할 수 있는 구체적이고 검증 가능한 문장을 쓰라고 권함.
  63. 마지막 주제는 컴팩션(compaction, 길어진 대화 맥락을 요약해 압축하는 것)임. 에이전트가 몇 시간, 며칠씩 돌아가면 사람이 매번 옆에서 승인해 줄 수 없다고 함.
  64. 그래서 작년 말에 오토 컴팩션을 넣었고, 코덱스는 그때부터 서버 쪽에서 자동으로 컴팩션을 걸어 모델이 학습된 방식 그대로 성능이 유지되게 한다고 함.
  65. 수동으로 걸 수도, 자동으로 걸 수도 있는데, 이전 컨텍스트 창을 필요한 정보가 담긴 컴팩션 항목이 든 새 컨텍스트 창으로 바꿔서 다음 턴부터 그걸 쓴다고 함.
  66. 정리하며 세 가지를 당부함. 첫째, 코덱스 앱 서버와 하니스는 오픈소스이니 설계를 배우는 청사진으로 쓰거나 그 위에 직접 지어도 된다고 함.
  67. 둘째, 코덱스에서 눈에 띄는 기능 대부분이 리스폰스 API에 노출돼 있어서, 도구 검색·어플라이 패치·웹소켓·서버 쪽 컴팩션을 어떤 하니스를 쓰든 그대로 갖다 쓸 수 있다고 함.
  68. 셋째, 모델이 계속 진화하니 리스폰스 API와 코덱스가 어떻게 바뀌는지 지켜보고 그걸 기준으로 자기 에이전트를 업데이트하라고 권하며 발표를 마침.

한줄 코멘트. 이 발표의 핵심은 코덱스 자체가 아니라 리스폰스 API로 노출된 부품들 — 지연 로딩·도구 검색·웹소켓·서버 쪽 컴팩션은 코덱스를 안 써도 자기 하니스에 그대로 옮겨 쓸 수 있다는 점으로 보임.

  1. 발표자는 프로덕션에서 벌어지는 에이전트 실패 대부분이 모델의 실패가 아니라 하니스(harness, 모델을 감싸 상태·권한·기록을 관리하는 운영 계층)의 실패라고 주장하며 발표를 시작함.
  2. 시작 사례로 든 사고: 사용자가 에이전트에게 고객 환불 건을 다음 턴을 위해 기억해 달라고 했고, 어시스턴트는 기록했다고 답함.
  3. 화면은 정상이었음. 빨간 오류도, 눈에 띄는 실패도 없었음.
  4. 그런데 다음 턴에서 그 사실을 다시 불러오지 못함. 사용자는 성공을 경험했지만 시스템은 불완전한 상태를 물려받은 것이라고 함.
  5. 충돌(crash)은 성가시지만 적어도 경계를 줌 — 뭔가 멈췄다는 걸 알 수 있고 마지막 정상 지점에서 다시 시작할 수 있다고 함.
  6. 반면 조용한 성공은 거짓말을 줌. 전달은 성공했는데 저장은 실패한 상태라, 사용자도 운영자도 의심할 이유가 없었다고 함.
  7. 다음 턴에도 모델은 여전히 그럴듯하게 말함 — 일관돼 보이지만 끊긴 이력 위에서 일관된 것뿐이라고 지적함.
  8. 발표자는 OpenAI에서 핵심 데이터·AI 인프라를 다루고, 이전엔 애플과 우버에서 분산 시스템을 만들었으며 "The Agent Stack"이라는 블로그를 쓴다고 밝힘.
  9. 이 발표는 오픈클로(OpenClaw, 오픈소스 개인 비서형 에이전트 프로젝트)를 홍보하려는 게 아니라 순수한 시스템 설계 이야기라고 밝힘. 오픈클로를 예로 쓴 이유는 이슈·코드·문서가 공개돼 있어 에이전트를 둘러싼 하니스 구조가 유난히 잘 들여다보이기 때문이라고 함.
  10. 이 발표의 계약 문장: 모델은 제안하고 하니스는 확정하며, 영수증(receipt, 시스템이 무엇을 허용·시도·실행했고 사용자에게 무엇이 확인됐는지 남긴 기록)이 그걸 증명함.
  11. 모델은 메시지·툴 호출·수정·명령을 제안할 수 있지만 그 자체로 프로덕션의 경계는 아니라고 함. 상태 전환·권한 검사·순서가 있는 커밋·영수증은 하니스의 몫이라는 것임.
  12. 이 발표에서 딱 세 가지만 기억하라면 이것이라고 함: 상태를 소유하라, 변경을 순서대로 하라, 행동을 증명하라. 사실 하나에는 소유자 하나와 재생 경로 하나가 있어야 하고, 공유되는 가변 상태에는 순서가 정해진 커밋 경로 하나가 있어야 한다고 함.
  13. 대화 기록(transcript)은 증거가 아니라고 함 — 기록은 에이전트가 뭐라고 말했는지를 남기고, 영수증은 시스템이 무엇을 허용·시도·실행했고 사용자에게 무엇이 확인됐는지를 남긴다는 것임.
  14. 하니스를 설명하려고 든 자동차 비유: 모델은 엔진이라고 함. 강력하지만 아무도 마력만 보고 프로덕션용 차를 사지는 않는다고 함.
  15. 조향·제동·도로 규칙·계기판·블랙박스도 봐야 하고, 모델은 능력을 주고 하니스는 통제를 준다고 함. 브레이크 없는 강력한 엔진은 자율이 아니라 가속도만 좋은 부채라고 함.
  16. 하니스 청사진: 개인 비서형 에이전트(오픈클로·Hermes 등)든 코딩 에이전트(코덱스·커서·오픈코드·클로드 코드)든 같은 밑구조를 쓴다고 함. 이벤트는 채팅, 웹훅, 타이머, 하트비트, 외부 시스템 등 여러 표면에서 들어온다고 함.
  17. 제어 평면이 이벤트를 세션 키에 매핑하고, 세션 키가 상태의 경계를 정하며 그 가변 상태에 대해 활성 기록자를 하나로 유지한다고 함.
  18. 런타임이 모델과 툴을 호출하고, 툴은 승인과 정책을 거쳐 실행되며, 감사 기록이 실행 영수증이 된다고 함. 청사진은 이벤트, 세션 키, 조절, 툴, 감사 순서이고, 뒤에 나오는 사고 사례들이 각 경계가 왜 중요한지 증명한다고 함.
  19. 에이전트 런타임은 사람처럼 기억하지 않고 상태가 없어서, 하니스가 매 턴마다 작업 상태를 다시 조립한다고 함. 그 작업 상태에는 대화 기록, 세션 상태, 메모리, 정책, 툴 정의가 들어간다고 함.
  20. 모델은 하니스가 넘겨준 것만 봄 — 입력 하나가 빠지거나 낡아도 답은 여전히 그럴듯하게 들릴 수 있다고 함. 일관돼 보인다고 해서 그 작업 상태가 완전했다는 증거는 아니라고 함.
  21. 타임아웃·재시도·멱등성(idempotency, 같은 요청을 여러 번 처리해도 결과가 같게 유지되는 성질)·락·순서·상태 소유권은 이미 알려진 문제들이라고 함. 달라진 건 에이전트라는 환경 자체라고 함 — 확률적 플래너가 매 턴 동적 계획을 세우고 컨텍스트를 다시 조립하며, 이벤트 소스와 행동 표면이 늘어나 실패가 더 쉽게 터지고 설명하기는 더 어려워졌다고 함.
  22. 첫 번째 실패 형태를 다시 꺼냄: 사용자는 성공을 보지만 진실의 원천은 그걸 재생할 수 없다는 것 — 전달됐다는 게 곧 기억됐다는 뜻은 아니라고 함.
  23. 오픈클로의 실제 이슈: 텔레그램 답장은 성공했는데 그 라우터 턴이 활성 컨텍스트나 대화 기록에 쓰이지 않았다고 함. 사용자는 응답을 봤고 로그도 정상으로 보였다고 함.
  24. 하지만 다음 턴엔 그 변경의 지속 기록이 없었다고 함. 전송 성공은 대화 기록을 증명할 뿐 미래의 컨텍스트를 증명하지는 않는다고 함.
  25. 이 사고에서 빠진 경계는 지능이 아니라 상태 소유권이었다고 함. 소유자란 사람이 아니라, 지속 상태가 진실이 되는 시스템(system of record)을 뜻한다고 함.
  26. 달력 일정은 달력 시스템이, 상담 상태는 티켓 시스템이, 코드 변경은 저장소가, 대화 턴은 세션 기록이, 사용자 선호는 메모리 저장소가 소유한다고 함. 저장(storage)은 바이트가 어디 있는지를 말해주고, 소유권(ownership)은 누가 그 실재를 재구성할 수 있는지를 말해준다고 함.
  27. 이름 붙은 소유자가 재생할 수 있어야 그게 비로소 믿을 만한 기억이 된다고 함. 질문은 단순함 — 이 사실을 누가 소유하고 어떻게 재생할 것인가라고 함.
  28. 소유자를 정했으면 다음 질문은 누가 어떤 순서로 그 상태를 바꿀 수 있느냐라고 함. 옳은 요청 두 개가 합쳐져 잘못된 결과 하나를 낼 수 있다는 것임.
  29. 오픈클로의 겹친 기록자(writer) 이슈: 두 호출자가 같은 옛 상태를 불러온 뒤 각자 다른 레코드를 고쳐 저장했는데, 나중 저장이 앞선 저장을 조용히 지워버렸다고 함.
  30. 두 작업 모두 국소적으로는 옳았지만 빠진 경계는 커밋 시점의 질서였다고 함. "나중에 쓴 게 이긴다"는 일관성 모델이 아니라는 것임.
  31. 목표는 동시성 자체를 없애는 게 아니라고 함 — 병렬 읽기, 독립적인 검색, 여러 세션의 동시 실행, 서브 에이전트로 작업을 나누는 것은 모두 괜찮다고 함.
  32. 규칙은 좁고 단순하다고 함: 가변 상태 경계 하나에는 순서가 정해진 커밋 경로 하나. 큐·뮤텍스·트랜잭션·락으로 구현할 수 있다고 함.
  33. 세션 간엔 락이나 뮤텍스를, 세션 안에선 큐나 트랜잭션을 쓰면 되고, 보수적으로 지켜야 할 건 커밋 시점이지 시스템 전체가 아니라고 함.
  34. 사용자는 큐나 락을 보지 않고 행동만 봄 — 뒤집힌 응답은 건망증처럼, 멈춘 레인은 죽은 것처럼, 배달 전에 완료로 보이는 건 혼란스럽게 느껴진다고 함. 순서는 그래서 제품의 성격을 이룬다는 것임.
  35. 세 번째 실패 형태는 생명주기 실패라고 함 — 결코 오지 않을 이벤트를 기다리는 실행이며, 침묵은 종결 상태가 아니라고 함.
  36. 오픈클로의 매달린 툴 호출(dangling tool call) 이슈: 세션에 툴 호출은 있는데 짝이 되는 툴 결과가 없다고 함. 프로세스가 죽었거나 연결이 끊겼거나 결과가 기록되기 전에 타임아웃됐을 수 있다는 것임.
  37. 정확한 원인은 디버깅에는 중요하지만 프로덕션 실패 자체는 단순하다고 함 — 실행이 결코 오지 않을 이벤트를 기다리고, 그 침묵 뒤로 새 메시지가 쌓이며, 사용자에겐 그냥 멈춘 것처럼 보인다는 것임.
  38. 실행에는 마감 시한과 취소가 필요하다고 함. 마감 시한이 대기 시간을 한계 짓고, 워치독(watchdog, 멈춘 작업을 감지해 알리는 감시 장치)이 멈춘 일을 눈에 보이게 한다고 함.
  39. 툴에는 시간 초과 모드와 오류 결과가, 채널에는 멈춘 작업 뒤에 줄 서지 않는 복구 명령이 필요하다고 함. 외부 경계마다 성공·실패·타임아웃·취소·최대 시도 횟수 중 하나로 끝이 나야 하고, 영수증이 그 종결 결과를 기록해야 다음 단계가 추측하지 않아도 된다고 함.
  40. 네 번째로 상태에서 권한으로 넘어감 — 대화가 행동이 되는 순간 위험해진다고 함. 모델이 행동을 요청할 순 있어도 요청 가능성이 곧 권한은 아니라는 것임.
  41. 오픈클로의 승인 표류(approval drift) 이슈: 만료된 승인 콜백 상태가 재시도 가능한 것으로 처리됐다고 함. 그 콜백 상태가 재시작을 넘어 지속되며 이후 채널 작업을 막았다는 것임.
  42. 버튼 클릭은 있었지만 유효한 권한은 없었다고 함. 실수는 승인을 "사람이 근처에 있었다" "예를 눌렀다"는 막연한 기억처럼 취급한 것이라고 지적함.
  43. 승인은 그 행동에 묶인, 범위가 한정된 실행 상태여야 하고 만료는 반복이 아니라 종료로 이어져야 한다고 함. 쓸모 있는 승인 객체는 누가, 어떤 세션·실행에서, 어떤 툴과 인자에 대해, 얼마나, 어떤 결과로 승인했는지에 답하고 영수증을 가리켜야 한다고 함.
  44. 그 필드들이 재시도·재생·채널 콜백 도중 떨어져 나가면 하니스는 그 행동이 승인된 것인지 더 이상 증명할 수 없다고 함.
  45. 최소 권한 원칙은 툴 표면을 좁히고, 범위가 한정된 자격 증명은 올바른 신원이 그 행동에 쓰이게 하며, 승인과 감사는 실행 전후에 무슨 일이 일어나는지를 결정한다고 함. 모델은 경계를 추론할 수는 있어도 그 경계 자체가 되면 안 된다는 것임.
  46. 다섯 번째: 툴이 성공했다고 해도 사용자가 실제로 본 화면은 다를 수 있다고 함 — 내부 컴포넌트는 성공을 보고하는데 사용자에게 보이는 표면엔 아무것도 없는, 처음 사례의 반대쪽 실패라는 것임. 오픈클로의 놓친 엣지 증명(missing edge proof) 이슈: 웹챗이나 TUI(터미널 기반 사용자 인터페이스)에서 메시지 툴은 성공을 보고했지만 실제 메시지는 렌더링되지 않았다고 함.
  47. 툴 결과는 내부 경로가 요청을 받아들였다는 것만 증명할 뿐, 사용자가 그 결과를 봤다는 건 증명하지 못한다고 함.
  48. 그 차이가 대화를 바꿈 — 에이전트는 나중에 "이미 보냈다"고 말할 수 있고 사용자는 정말로 "본 적 없다"고 말할 수 있다고 함. 내부 성공은 외부 증명이 아니라는 것임.
  49. 증명은 주장이 아니라 사슬이라고 함 — 모델이 뭔가를 제안하고, 정책이 허용하거나 거부하고, 실행이 시도되고, 사용자에게 보이는 경계가 결과를 확인하거나 확인하지 못한다는 것임. 영수증이 이 사슬을 보존한다고 함.
  50. 다섯 실패 형태를 다시 정리함: 상태 구멍, 겹친 기록자, 매달린 툴 호출, 승인 표류, 놓친 엣지 증명임. 각각에 대해 사용자가 뭘 봤는지, 어떤 경계가 깨졌는지, 영수증이 있었다면 뭘 잡아냈을지를 물으면 된다고 함.
  51. 발표자는 팀에 돌아가면 모든 에이전트가 아니라 하나만 골라 실제 프로덕션 경로 하나의 자취를 놓고 영수증을 요구해 보라고 제안함. 그 감사의 다섯 질문: 무엇이 깨웠는가, 어떤 상태를 물려받았는가, 어떤 권한을 썼는가, 무엇이 실행됐는가, 어떤 증거가 남았는가라고 함.
  52. 첫째, 무엇이 깨웠는가 — 사용자 메시지, 웹훅, 타이머, 툴 결과, 서브 에이전트, 재생 중 무엇인지와 그 신원을 이름 붙여야 중복·순서·인가를 따질 수 있다고 함.
  53. 둘째, 어떤 상태를 물려받았는가 — 대화 기록, 세션 상태, 메모리 스냅샷, 정책 버전, 툴 표면임. 모델은 하니스가 조립한 작업 상태 위에서만 추론한다고 함.
  54. 셋째, 어떤 권한을 썼는가 — 행위자, 세션, 툴, 실행, 인자, 범위, 유효 기간을 기록함. 모델의 요청이 곧 허가는 아니고 권한은 대기 중인 행동 하나에만 묶여야 한다고 함.
  55. 넷째, 무엇이 실행됐는가 — 툴이나 API 호출, 인자, 시도 횟수, 멱등성 키, 외부 결과를 기록함. 이건 에이전트가 뭘 의도했는지 요약이 아니라 부작용의 경계라고 함.
  56. 다섯째, 어떤 증거가 남았는가 — 티켓이 갱신됐는지, 메시지가 렌더링됐는지, 파일이 바뀌었는지, 달력 일정이 실제로 있는지임. 영수증은 사용자가 신경 쓰는 그 경계에서 끝나야 한다고 함.
  57. 이 다섯 질문을 맨 처음 사례에 다시 적용해 봄: 깨운 건 사용자 메시지, 물려받은 상태가 곧 깨진 경계였고, 실행된 건 채널 전송이었다고 함.
  58. 살아남은 증거는 전달뿐이었지, 지속된 턴은 아니었다고 함. 전달은 살아남았는데 상태는 그러지 못했다는 것임.
  59. 그 틈이 바로 하니스 실패이고, 그 에이전트에 필요했던 건 더 나은 모델도 더 나은 프롬프트도 아니라 완전한 영수증을 갖춘 더 나은 하니스였다고 함. 다시 기억할 세 가지: 상태를 소유하라, 변경을 순서대로 하라, 행동을 증명하라라고 함.
  60. 더 나은 모델은 한 턴 안에서 도움이 되고, 소유권·순서·생명주기·권한·증명은 턴을 넘나들며 시스템을 온전하게 지킨다고 함.
  61. 모델은 제안하고 하니스는 확정하며 영수증이 증명함. 텍스트가 행동이 될 수 있게 되는 순간 물어야 할 질문이 바뀐다고 함 — 모델이 추론할 수 있는지가 아니라 시스템이 상태를 소유하고 변경을 순서 짓고 작업에 시한을 두고 권한을 제약하고 증거를 보존할 수 있는지를 물어야 한다는 것임.
  62. 루프는 한 턴에 답할 수 있지만 하니스라야 프로덕션을 지탱한다고 함.
  63. 발표자는 OpenAI 에이전트 SDK(에이전트를 만들 때 쓰는 개발 도구 모음)에 이런 하니스 요소들이 이미 들어 있다고 소개함. 더 자세한 내용은 자신의 블로그 "The Agent Stack"에서 다룬다고 밝히며, 발표 후엔 OpenAI 부스에서 하니스 설계 이야기를 더 나누고 싶다고 함.

한줄 코멘트. 이 발표가 짚은 다섯 사고 모두 모델이 아니라 경계선 하나씩(소유·순서·시한·권한·증명)이 빠져서 터졌다는 점에서, "더 똑똑한 모델"이 신뢰성 문제의 답이 아니라는 주장은 설득력 있어 보임.

  1. 로메인 위에(Romain Huet)와 알렉산더 엠비리코스(Alexander Embiricos)가 오픈AI 코덱스(Codex) 팀을 대표해 무대에 서서, 오늘 AI 엔지니어 7천 명이 이 자리에 모였다고 소개함.
  2. 세계 박람회(World's Fair)가 불가능해 보이던 아이디어를 실제로 지어 보여줬듯, 이 행사도 같은 에너지로 엔지니어링의 미래를 지금 이 방에서 짓고 있다고 말함.
  3. 엔지니어가 사라진다는 주장에 정반대라고 반박함. 소프트웨어가 세상을 먹었고 그다음 AI가 소프트웨어를 먹었으며, 이제는 AI 엔지니어가 세상을 먹고 있다는 것임.
  4. 엔지니어링은 원래 코드를 쓰는 일이 아니라 문제를 푸는 일이었고 최신 과학에 디자인·취향·판단·상상력을 더해 사람이 쓸 걸 만드는 일이었다며, 지금은 그 뿌리로 돌아가는 것이라고 정의함.
  5. 새 모델을 내놓는 속도 자체가 빨라져서 예전엔 15개월에 한 번이던 게 지금은 대략 6주에 한 번꼴이라고 함. 지난주엔 GPT-5.6 계열 프리뷰를 냈다고 밝힘.
  6. 로메인은 자신이 겪은 몇 년을 자동완성 → 인라인 예측 → 커맨드K(모델에게 바꿔달라 시키되 검증은 안 하던 단계) → 모델이 스스로 작업을 테스트하는 단계 → 길고 어려운 목표를 끝까지 끌고 가는 단계로 정리함.
  7. 알렉산더는 2024 데브데이(Dev Day) 때 o1 프리뷰로 미니 드론 조종 화면을 처음부터 만들었는데, 모델이 자기 코드를 실행·검증할 수 없어 데모가 될지 손가락을 꼬며 지켜봐야 했다고 함.
  8. 2025 데브데이엔 모델이 스스로 작업을 테스트할 수 있다는 확신이 생겨 카메라와 조명 시스템 전체를 실시간으로 조작하는 데모를 했다고 함. 로메인은 그를 "데모의 신"이라 부름.
  9. 올해 출시한 것 중 코덱스 앱(Codex app)·골 모드(goal mode)·리모트(remote)가 특히 일하는 느낌 자체를 바꿨다고 꼽음.
  10. 코덱스로 코덱스를 만들었다는 점, 그리고 지금은 코덱스와 에이전트(agent, 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)가 사람이 컴퓨터에서 할 수 있는 일이면 뭐든 할 수 있다는 점을 가장 흥미로운 지점으로 꼽음.
  11. 그래서 에이전트는 코딩만이 아니라 코딩 전후에 일어나는 일까지 도움. 왜 이 일을 해야 하는지를 연결하면 더 많은 일을 스스로 시작하고, 검토·배포에 연결하면 더 많은 일을 끝까지 끌고 간다고 함.
  12. 이 덕분에 속도만 빨라진 게 아니라 아이디어를 더 많이 시제품으로 만들어보고 사용자와 더 오래 시간을 보내면서, 무엇을 만들지 자체를 더 잘 결정하게 됐다고 함. 청중의 피드백에 감사를 전함.
  13. 중간 길이 컴퓨터 작업 하나를 같은 시간 안에 자신과 모델에게 시키면 평균적으로 모델이 자신보다 더 잘 해낸다며, 모델이 이미 어떤 면에서 사람보다 똑똑해졌다고 함.
  14. 그래서 "모든 인류에게 이익이 되는 AGI(범용인공지능, 사람이 하는 지적 작업 대부분을 해낼 수 있는 인공지능)"라는 미션에 비춰 두 질문을 던진다고 함. 에이전트를 세상에서 어떻게 일하게 붙이느냐, 그 에이전트를 사람이 어떻게 쓰느냐임.
  15. 목표는 엔지니어를 자동화하는 게 아니라 엔지니어를 최대한 강하게 만드는 제품 형태라고 함.
  16. 이 형태를 SF 소설·슈퍼히어로 영화 속 단순한 아이디어가 대략 맞다고 봄. 어디서든 뭐든 물을 수 있는 채팅과, 직접 들여다보고 조작하는 협업형 UI 두 가지라고 함. 채팅이 죽었다는 말과 달리 저평가돼 있다고 봄.
  17. 코덱스로 이 관계를 그린 그림을 만들게 했다며 팀과 함께 일하는 것에 비유함. 대부분은 그냥 이야기하고 팀이 일하는 시간이라 작업마다 어깨너머로 지켜볼 필요는 없다고 함.
  18. 다만 가끔은 깊이 파고들어 문제를 같이 붙잡고 싶은 순간이 있다며, 제품을 만들 때 "일에 통달해 있다는 느낌"을 잃지 않게 하려 한다고 함. 그래서 만든 게 코덱스 앱이라고 함.
  19. 코덱스 앱은 코딩을 포함해 무엇에든 쓸 수 있는 단순한 채팅 인터페이스로, 대화하다 원하는 만큼 깊이 들어갈 수 있다고 함. 화면 예시는 호먼(Homan)이 예측해둔 월드컵 경기 스코어였음.
  20. 특정 지점을 짚어 "이걸 바꿔줘"라고 시키거나 직접 고칠 수 있다며, 이 아이디어를 처음 얘기했을 때 "터미널도 빔(Vim)도 이맥스(Emacs)도 절대 안 떠난다"던 사람이 지금은 쓰고 있다는 일화를 전함.
  21. 팀 내부에서도 "다들 CLI(명령줄 인터페이스)와 IDE(통합개발환경)를 좋아하는데 왜 이걸 만드느냐"는 질문이 많았다고 함.
  22. 하지만 CLI로는 어떤 일이든 다루는 협업형 인터페이스를 만들 수 없어 결국 채팅 위주가 되고, IDE는 코드부터 시작하는 순서가 거꾸로라 이제는 먼저 대화하고 필요할 때 파고드는 쪽으로 옮겨갈 시점이라고 판단함.
  23. 제품과 모델 양쪽에서 빠르게 움직이면서 커뮤니티 속도도 따라잡으려 한다고 함. X(옛 트위터)를 열면 절반은 코덱스로 이런 것도 되는지 몰랐던 걸 누군가 이미 하고 있는 걸 본다고 함.
  24. 사용자들이 도구를 실험하고 자기 팀에 맞게 만드는 과정에서 오픈AI도 영감을 받고 배운다며, 다음에 뭘 만들지와 엔지니어링의 미래 모습을 청중이 함께 정하고 있다고 함.
  25. 그러려면 코덱스가 오픈AI만 개선할 수 있는 닫힌 제품이면 안 된다는 게 중요한 원칙이라, 코덱스를 누구나 그 위에 만들 수 있는 층(layer)들로 의도적으로 설계했다고 함.
  26. 첫 번째 층은 모델과 리스폰시스 API(Responses API)임. 코덱스 앱도 개발자에게 주는 것과 똑같은 모델을 똑같은 API로 써서 만들었다고 함.
  27. 코덱스에 새 기능이 필요하면 먼저 API에 심는다며, 예로 컴팩션(compaction, 길게 이어지는 작업의 맥락을 모델이 계속 읽을 수 있게 압축하는 처리)을 듦. 코덱스가 장기 작업용으로 필요해 API에 넣었더니 다른 에이전트도 같은 장치를 쓸 수 있게 됐다고 함.
  28. 두 번째 층은 오픈소스로 공개한 코덱스 하네스(harness, 모델을 감싸 언제 무엇을 하게 할지 바깥에서 통제하는 장치)임. 들여다보고 포크하고 고칠 수 있다고 함.
  29. 지시 파일 형식도 코덱스 전용을 새로 만드는 대신 다른 에이전트도 쓸 수 있는 이름인 AGENTS.md를 골랐다고 함. 오픈AI 모델이 기본값이지만 하드코딩은 아니라서 오픈 모델로도 같은 루프를 쓸 수 있다고 함.
  30. 이 하네스를 모델의 사후 학습(post-training) 과정에도 그대로 가져다 써서, 모델이 도구를 부르고 환경을 다루는 법을 오픈소스로 공개된 그 하네스로 배우게 한다고 함.
  31. 오픈코드(Open Code) 팀이 이 참조 구현을 들여다보고 필요한 부분만 재사용하거나 나머지를 바꿔 썼고, 챗GPT 로그인 처리도 코드로 보고 배웠다고 함. 역설계로 알아내게 두는 것보다 낫다고 봄.
  32. 세 번째 층은 이 하네스를 앱 안으로 가져와 기존 코덱스 구독으로 로그인하게 만드는 문제임. VS 코드(VS Code) 확장과 코덱스 앱을 만들며 같은 문제를 겪어 앱 서버(App Server)를 만들었고, 이것도 오픈소스로 공개함.
  33. 앱 서버는 커뮤니티용 어댑터가 아니라 오픈AI 자신의 제품이 실제로 쓰는 경로 그 자체라고 함. X에서 데밀리안(Demilyan)으로 불리는 토마(Toma)가 코덱스 앱이 나오기도 전에 앱 서버로 자기 앱 "코덱스 모니터"를 만들었다고 함.
  34. 토마는 지금 오픈AI에서 iOS용 코덱스를 만들었다고 전함.
  35. 네 번째 층인 앱 층에서는 인앱 브라우저와 플러그인 같은 확장 가능한 기본 장치를 만들었고, 브라우저 사용·컴퓨터 사용 기능도 같은 확장 지점으로 만든 플러그인이라고 함.
  36. 데이터 과학자·디자이너처럼 직군별로 맞춘 플러그인도 최근 만들었고, 오픈소스로 공개했다고 함.
  37. 기존 구독을 오픈코드·파이(Pi)·드로이즈(Droids)·오픈클로(Open Claw)는 물론 Xcode·젯브레인스(JetBrains)에서까지 쓸 수 있다고 함.
  38. 오픈AI용 시스템과 개발자용으로 단순화한 시스템을 따로 만드는 게 아니라 모든 층에서 같은 것을 쓴다는 점이 이 구간의 핵심 메시지라고 함.
  39. 누군가 하네스를 포크하거나 모델의 한계를 찾아낼 때마다 오픈AI도 배우고 개선한다며, 이 방의 7천 명이 앞으로 AI를 어떻게 경험할지를 상당 부분 결정할 거라고 함.
  40. 에이전트를 폭발적으로 쓸모 있게 만든 다음 질문은 거기서 어떻게 가치를 뽑아내느냐라며, 이걸 토큰 맥싱(token maxing)이 아니라 밸류 맥싱(value maxing)이라 부른다고 함.
  41. 엔지니어링 리더들과 이야기하면 대화 대부분이 밸류 맥싱과 관련된 주제로 흐른다며, 이미 많이 나아간 것과 아직 갈 길이 먼 것을 나눠 짚는다고 함.
  42. 첫 주제는 비용 효율임. 다들 최고 성능의 프런티어 모델을 원하는데, 터미널벤치(Terminal-Bench) 평가에서는 GPT-5.6 솔(Sol)이 그 자리를 차지했다고 함.
  43. 성능만큼 효율도 중요한데, GPT-5.6 테라(Terra)는 GPT-5.5급 지능을 절반 비용으로 낸다고 함.
  44. GPT-5.6 루나(Luna)는 이름 있는 모델들을 이기면서도 입력 100만 토큰당 1달러, 출력 100만 토큰당 6달러라는 값이라며 "말도 안 되는 가성비"라고 함.
  45. 다음 주제는 속도임. 이전에 GPT-5.3 스파크(Spark)가 속도로 무엇이 가능한지 보여줬지만, 그렇다고 성능이 떨어지는 모델을 쓰고 싶은 건 아니라고 함.
  46. GPT-5.6 솔을 세레브라스(Cerebras)에서 돌리면 초당 750토큰이 나오는데, 이는 꽤 묵직한 PR(풀 리퀘스트) 하나가 10초 만에 나오는 것과 비슷하다고 함.
  47. 속도가 좋아지면 답 하나를 빨리 받는 걸 넘어선다고 함. 에이전트가 답 하나를 만들던 시간 안에 대여섯 접근을 병렬로 시도하고 최선을 골라올 수 있어, 기다리는 느낌보다 이미 결과를 보여주는 동료와 일하는 느낌에 가까워진다고 함.
  48. 사무실에서 에이전트를 계속 돌리려 노트북을 켜둔 채 다니는 광경을 아느냐 물으니 많은 청중이 손을 들었다고 함.
  49. 컴퓨터를 꺼두고도 여러 작업을 각자 격리된 박스에서 병렬로 돌릴 수 있게 하는 게 목표라며, 첫 대형 출시였던 코덱스 클라우드(Codex Cloud)가 곧 큰 업그레이드를 앞두고 있다고 함.
  50. 로컬 작업과 클라우드 작업을 사람이 직접 골라야 하는 지금의 구분도 없어져야 하며, 그냥 에이전트에게 말을 걸면 어느 환경이 맞는지는 에이전트가 알아서 판단해야 한다고 함.
  51. 테오(Theo)가 주말 사이 이 주제로 예측 트윗을 올렸다며 6개월보다 빠를지 늦을지 알렉산더에게 묻자 "디테일은 몰라도 분위기로는 6개월보다 훨씬 빠를 것"이라 답함. 지금 속도라면 그보다 더 빨라져도 놀랍지 않을 거라고 덧붙임.
  52. 이번 행사에서는 라이브 데모 대신, 에이전트로 가능한 일의 한계를 밀어붙이며 오픈AI를 더 "AGI를 받아들인" 쪽으로 밀어붙인 특별 게스트 피터 스타인버거(Peter Steinberger)를 무대로 초대함.
  53. 스타인버거는 몇 달 사이 얼마나 많은 게 바뀌었는지 보여주는 사진 한 장으로 말문을 염. 1월엔 터미널 창 10개 이상을 돌려가며 하나가 끝나길 기다렸다가 그 에이전트를 빼앗아 새 일을 넣는 게 최고의 생산성이라 느꼈는데, 지금 보면 좀 우습다고 함.
  54. 그때는 오케스트레이션(orchestration, 여러 작업이 정해진 순서와 방식대로 돌아가게 조율하는 일)을 하고 있다고 생각했지만 실제로는 폴링(polling, 상태가 바뀌었는지 계속 확인하는 것)이었고, 스케줄러이자 라우터이자 메모리 역할을 하고 있었을 뿐이라고 함.
  55. 처음엔 에이전트 하나와 짝을 이뤄 일했는데 터미널 10개를 돌리던 시기엔 짝이 아니라 직속 부하 10명을 관리하는 쪽에 가까웠다고 함.
  56. 지금은 오래 켜둔 매니저 에이전트 하나에 주로 말을 걸고, 그 매니저가 팀에 작업을 나눠준다고 함. 까다로운 일은 여전히 작업자 에이전트와 직접 짝을 이루지만, 기본값은 매니저의 매니저가 되는 쪽으로 바뀌었다고 함.
  57. 이걸 가능하게 한 변화 셋을 꼽음. 서버사이드 컴팩션 덕분에 장기 작업이 충분히 안정적으로 돌아가면서 세션 첫 순간을 최적화하는 데 매달리지 않게 됐다고 함.
  58. 둘째는 조정(coordination) 기능으로 스레드 하나가 알맞은 프로젝트를 만들고 이끌 수 있게 된 것, 셋째는 자동화가 무슨 일이 생겼을 때 같은 매니저를 깨울 수 있게 된 것이라고 함. 지속되는 맥락·위임·트리거 이 셋이 곧 루프라고 함.
  59. 루프가 돌아가기 시작하면 병목이 어디로 옮겨가는지가 보인다며, 작년엔 토큰이 제약이었는데 오픈AI에 합류하면서 그건 해결했다고 농담함. 다만 이 전략은 확장 가능하지 않다는 걸 안다고 덧붙임.
  60. 그다음 제약은 컴퓨트(compute, 연산 자원)로 옮겨가 스레드가 한꺼번에 다 돌면 맥북이 제트 엔진처럼 소리를 냈는데, 테스트를 딴 기기에서 돌리는 테스트 박스로 대부분 해결했다고 함.
  61. 지금은 주로 주의력이 제약이라며, 토큰이나 컴퓨트와 달리 주의력은 그냥 더 늘릴 수가 없어서 오늘날 가장 중요한 기술은 그걸 어디에 쓸지 정하는 일이라고 함.
  62. 이전 세대 모델에서는 에이전트가 엉뚱한 방향으로 가면 에스케이프를 눌러 다시 잡아줘야 했지만, 최신 모델은 의도를 워낙 잘 이해해서 코드 생성을 계속 지켜보는 게 시간 낭비에 가깝다고 함.
  63. 예로 자기 오픈소스 프로젝트에 이슈가 올라오면 매니저가 깨어나 프로젝트의 목표·메모·비전에 비춰 다룰 만한지 판단해, 맞으면 작업자 에이전트를 만든다고 함. 그 작업자가 조사·구현·테스트를 하면 다른 에이전트가 결과를 검토한다고 함.
  64. 이 과정의 중간 메시지를 일일이 챙길 필요 없이, 매니저가 필요할 때 PR과 원래 이슈, 제안된 diff, 영상, 때로는 VNC(원격으로 다른 컴퓨터 화면에 접속해 보는 방식)로 들어가 볼 수 있는 실행 중인 빌드를 돌려준다고 함.
  65. 한 번 검토하고 메모를 남기고 승인하면 루프가 이어지고 점검을 통과하면 그대로 반영된다며, 에이전트가 안쪽 실행 루프를 돌리고 자신은 바깥쪽 루프에서 방향을 정하고 결정을 내린다고 함.
  66. 폴(Paul)이라는 사람도 비슷한 걸 돌리고 있다며, 10분마다 깨어나 자기 깃허브(GitHub) 작업을 조율하는 비서 에이전트를 고정해뒀고 사이드바에 스레드를 만들어 필요할 때 폴이 끼어들 수 있게 한다고 전함.
  67. 매니저가 오래 살아 있는 존재가 되면 노트북 하나에 묶어두는 게 이상하다며, 코덱스는 이미 작업을 여러 호스트로 옮길 수 있고 오픈클로에는 게이트웨이와 노드가 있지만 둘 다 아직 최종 형태처럼 느껴지지는 않는다고 함.
  68. 자신이 어디서 일하는지조차 신경 쓰고 싶지 않다며, 에이전트가 자기 어떤 기기에든 연결돼 어떤 일을 클라우드에서 하고 어떤 일이 로컬 기기를 필요로 하는지 스스로 알아야 한다고 함.
  69. 매니저는 앱 안에 갇힌 세션이 아니라 문자로 말 걸고 슬랙(Slack)에서 방향을 잡아주고 어디서든 들을 수 있는 에이전트여야 한다며, 왜 에이전트에게 직접 말해서 루프 전체를 설계하게 할 수 없는지 되물음.
  70. 아직 거기까지는 풀지 못했다며, 모델이 그걸 둘러싼 하네스와 조직보다 더 빨리 앞서가고 있고 그 하네스와 조직을 설계하는 일이 다음 엔지니어링 과제라고 함. 미래는 터미널 20개가 아니라 더 나은 루프라는 문장으로 발표를 마무리함.

한줄 코멘트. 코덱스 팀은 층마다 자기도 쓰는 것을 그대로 공개하는 개방 전략으로 답했고, 스타인버거는 터미널 10개를 관리하다 매니저 하나에게 위임하는 쪽으로 실제 워크플로를 바꿔 같은 결론에 도달했다는 점이 이 발표를 겹치게 만듦.

  1. 오넬라(Ornella)와 조엘(Joel)은 레슨 하나를 처음부터 끝까지 안정적으로 진행하는 실시간 AI 음성 튜터 에이스(Ace)를 만들었다고 소개함. 비결은 LLM(거대언어모델)이 운전대를 잡지 않는 것이라고 밝힘.
  2. 여러 단계로 이어지는 에이전트를 배포해본 사람이라면 아는 순간이 있음. 데모에서는 잘 되다가 실제 사용자가 붙으면 절반쯤 가서 에이전트가 스스로 끝났다고 판단하거나 단계를 건너뛰거나 같은 자리를 맴돈다고 함.
  3. 데모 영상은 이 장면을 절대 보여주지 않는다고 지적함.
  4. 다들 처음 시도하는 해법은 프롬프트를 더 세게 쓰고 규칙 구멍을 더 메우는 것임. 하지만 신뢰성은 애초에 프롬프트 문제가 아니라 통제(control) 문제였다고 함.
  5. 모델은 배우이고 하네스(harness, 모델을 감싸서 언제 무엇을 하게 할지 바깥에서 통제하는 장치)는 감독이라는 비유를 듦.
  6. 모델은 대사 한 줄을 훌륭하게 전달하는 데는 뛰어나지만, 지금이 여섯 단계 중 세 번째 단계인지 기억하는 데는 형편없다고 함.
  7. 그래서 모델에게 그걸 기억하라고 아예 요구하지 않기로 했다고 함.
  8. 레슨 하나는 인트로(intro)·티치(teach)·체크(check)·그레이드(grade)·어드밴스(advance)·랩(wrap)으로 이어지는 작은 상태 머신(state machine, 정해진 상태들 사이를 정해진 규칙대로만 오가는 구조)이라고 함.
  9. 각 단계는 모델에게 좁은 계약(narrow contract) 하나씩을 보낸다고 함. 이 한 가지만 하고 결과를 돌려달라는 식임.
  10. 하네스가 돌아온 결과를 검증하고 상태를 다음으로 넘기며 다음에 뭘 할지 결정함. 지금 어느 단계인지는 모델이 아니라 하네스가 정한다고 함.
  11. 여기까지 설명한 뒤 조엘이 하네스가 실제로 어떻게 작동하는지 보여준다고 넘김.
  12. 조엘은 오늘날 프런티어 모델, 예를 들어 앤트로픽(Anthropic)의 오퍼스 4.7(Opus 4.7) 같은 모델을 사람들이 흔히 생각부터 처리까지 모든 것에 다 맡긴다고 지적함.
  13. 그게 좋을 때도 있지만, 학생과 실시간으로 말을 주고받는 라이브 AI 튜터 같은 상황에서는 늘 효과적이지 않다고 함.
  14. 여기서는 신뢰성·비용 효율·속도가 다 필요하기 때문에 하네스 엔지니어링(harness engineering)이라는 개념을 끌어왔다고 함.
  15. 아주 똑똑한 모델 하나가 전부를 알아서 처리하게 두는 대신, 필요한 단계들을 전부 직접 만들어두고 모델에게는 그 순간 시나리오를 실행하는 데 필요한 입력만 준다고 함.
  16. 에이스를 만들 때 상태 머신을 깊이 고민했는데, 지금 단계가 뭔지, 그다음에 올 수 있는 단계가 뭔지를 따졌다고 함.
  17. 각 단계 안에서는 모델을 그 순간의 그 행동 하나에만 가두도록 구체적인 것들을 제공했다고 함.
  18. 이렇게 한 덕분에 4.7 같은 무거운 모델 대신 훨씬 작고 추론 능력도 떨어지는 하이쿠 4.5(Haiku 4.5) 같은 모델을 써도 기대한 수준으로 작동한다고 함.
  19. 그 결과 비용·시간·지연을 아꼈다고 함.
  20. 이어서 특정 레슨의 로그를 담은 녹화 영상을 재생함.
  21. 영상 오른쪽에는 여러 하네스가 동작하는 로그가 나오는데, 지금 무엇을 말하고 무엇을 해야 하는지 입력을 주는 섹션용 하네스가 있다고 함.
  22. 화이트보드에 그리는 것을 다루는 하네스, 대기열(queue)을 비우는 걸 다루는 하네스, 레슨을 끝내는 절차를 다루는 하네스까지 있다고 함.
  23. 새로운 시나리오가 들어와도 레슨을 안정적으로 진행할 수 있게 하는 것들을 전부 상태 머신 안에 녹여 넣으려 했다고 함.
  24. 결국 모델이 신경 쓰는 건 입력이 주어지면 어떤 행동을 할지 알고 그 행동의 결과를 내놓는 것뿐이라고 함.
  25. 모델은 사실상 생각하지 않는다고 함. 제안은 하지만 최종 결정은 하네스가 한다는 것임.
  26. 에이스에서는 레슨이 언제 끝났는지, 학생이 실제로 제대로 이해했는지, 다음에 뭘 할지 세 가지를 특히 고민했다고 함.
  27. 이 세 범주 안에 들어가는 모든 질문과 모델이 취해야 할 모든 행동을 모델 바깥에서 미리 설계해뒀다고 함.
  28. 모델은 그저 입력을 받아 출력을 내놓을 뿐이며, 이 방식이 아주 효과적이었다고 밝힘.
  29. 이 원칙은 에이스 같은 음성 모델뿐 아니라 코딩 에이전트, 옵스 런북(Ops Run Books, 장애 대응 같은 반복 운영 작업을 정리해둔 절차서), 온보딩 플로우에도 똑같이 적용된다고 함.
  30. 이 방식을 써야 할지 판단하는 기준은 에이전트의 신뢰성을 보는 것이라고 함. 성공할지 실패할지가 동전 던지기 수준이라면 모델에서 제어 흐름을 빼내야 한다는 것임.
  31. 모델이 더 많은 결정을 내리게 두지 말고, 그 결정들을 모델 바깥에 미리 만들어두고 모델에게는 쉽게 답할 수 있는 입력만 넘기라고 함.
  32. 모델이 말은 하게 하되 운전은 시키지 말라는 문장으로 발표를 정리함.
  33. 조엘과 오넬라는 자신들을 다시 소개하며 질문을 받겠다고 하고 발표를 마침.

한줄 코멘트. 모델을 작게 쓸 수 있다는 이야기가 아니라 모델에게서 상태를 뺏어야 작은 모델도 큰 모델만큼 믿을 수 있어진다는 순서가 이 발표의 핵심임.

  1. 클로드를 광원에, 제품을 그 빛이 통과하는 창문에 비유하며 얘기를 시작함, 시간이 지나면서 빛(모델 능력)을 제대로 통과시키는 창(제품 형태)이 계속 바뀌어 왔다고 함.
  2. 클로드 모델별로 자율로 해낼 수 있는 작업 시간(태스크 호라이즌)을 그려 보여줬는데, 기준은 미터(METR, AI 모델의 자율 작업 지속 시간을 재는 평가기관)이고 오퍼스 3 시절이던 2024년쯤엔 모델이 10~20분 정도만 자율로 일할 수 있었다고 함.
  3. 그때는 자동완성이나 채팅처럼 사람이 계속 옆에서 조종해야 하는 제품만 말이 됐다고 함.
  4. 지난 1년 사이 클로드 코드 같은 동기(synchronous) 코딩 에이전트가 뜨면서 모델이 한 시간가량은 일할 수 있게 됐지만, 여전히 로컬에서 돌려 쉽게 조종하는 방식이 주였다고 함.
  5. 이 시기에 비동기(async) 에이전트를 만들어 본 시도가 있었지만, 모델이 한 시간밖에 못 버티니 오류를 만나고 금방 되돌아오는 나쁜 경험이었다고 함.
  6. 진짜 비동기를 풀려면 더 긴 작업 지속 시간이 필요했고, 이제 그게 나타나고 있다고 함.
  7. 능력과 시간대가 바뀌면서 API 표면도 함께 바뀌었다고 함 — 2년 전 나온 메시지 API(Messages API)는 프롬프트를 넣으면 응답이 나오는 단순한 구조라 하니스(harness, 모델을 감싸 도구 호출과 루프를 관리하는 실행틀)를 직접 짜서 배포해야 했다고 함.
  8. 지난 1년간은 에이전트 SDK(Agent SDK)를 내놨음 — 클로드 코드를 프로그램으로 호출하는 방식, 즉 하니스를 미리 만들어 준 셈이라고 함.
  9. 지난 4월 이후로는 매니지드 에이전트(Managed Agents)라는 새 API를 내놨는데, 하니스와 배포 인프라를 통째로 패키징한 것이라고 함.
  10. 매니지드 에이전트를 처음 만들 땐 하니스를 샌드박스와 같은 컨테이너 안에 넣었는데, 하니스나 컨테이너가 죽으면 세션 자체를 통째로 잃는 게 문제였다고 함.
  11. 장기 작업 중인 에이전트가 컨테이너와 함께 죽으면 모든 걸 잃는 구조라 긴 작업엔 취약하다고 함.
  12. 모델이 강력해질수록 인증정보(credential)를 에이전트와 같은 컨테이너에 두는 것도 위험해지는데, 클로드에게 여러 비밀정보 접근권을 주고 10시간 동안 지켜보지 않고 돌리면 보안상 꺼림칙하다고 함.
  13. 그래서 두뇌(하니스)와 손(실행 환경)을 가르는 구조로 매니지드 에이전트를 다시 짰다고 함.
  14. 하니스는 상태를 갖지 않는(stateless) 프로세스가 되고, 세션이라는 추가전용(append-only) 이벤트 로그와 대화한다고 함.
  15. 세션은 손에 해당하는 컨테이너(샌드박스)들로 뻗어나가 실제 작업을 시킨다고 함.
  16. 클로드는 하나의 하니스로 여러 컨테이너(손)를 동시에 효과적으로 관리할 수 있다고 함.
  17. 하니스나 샌드박스가 죽어도 세션은 추가전용 로그에 늘 백업돼 있고, 인증정보는 샌드박스에 넣지 않고 별도 볼트(vault)에 저장해 안전하다고 함.
  18. 이 분리 구조 덕분에 특히 장기(long-horizon) 작업에서 신뢰성과 안전성이 확보된다고 함.
  19. 이 아이디어는 재귀적 언어 모델(recursive language models, 모델이 스스로를 다시 호출해 하위 작업을 처리하게 하는 방식) 연구와도 맞닿아 있다고 함.
  20. 세션이 모델 스스로 조회하는 외부 컨텍스트 객체가 된다는 것인데, 보통 컴팩션(compaction, 컨텍스트가 길어지면 일부만 남기고 줄이는 처리)을 하면 남기지 않은 내용은 그대로 버려진다고 함.
  21. 이 구조에서는 컨텍스트 객체가 지속되고 손상되지 않은 채로 남는다 — 추가만 되고 지워지지 않는다고 함, 모델이 언제든 예전 컨텍스트로 되돌아가 다시 꺼내볼 수 있어 장기 작업의 컨텍스트 관리에 유리하다고 함.
  22. 두 번째 주제는 검증자(verifier)를 따로 두라는 것임.
  23. 클로드에게 일을 시키고 같은 맥락(context) 안에서 "네가 한 일 채점해봐"라고 하면 이상한 결과물과 작화(confabulation, 없는 사실을 그럴듯하게 지어내는 현상)가 나온다고 함.
  24. 같은 컨텍스트 창이 작업과 채점을 동시에 맡으면 모델이 비판적 검증에 제대로 맞춰져 있지 않은 경우가 많다고 함.
  25. 검증을 별도의 컨텍스트 창으로 떼어내는 게 꽤 효과적이라고 함, 여러 엔지니어링 블로그도 다룬 일반적인 흐름이라고 함.
  26. 검증자 컨텍스트를 비판적 검증이라는 과제 하나에만 맞춰 특화해 튜닝할 수 있기 때문이라고 함.
  27. 실제로는 빌드(build) 컨텍스트와 검증자 컨텍스트로 이뤄진 루프를 짠다고 함 — 빌드 에이전트와 검증 에이전트임.
  28. 검증자는 목표나 루브릭(rubric, 평가 기준표)을 갖고 빌드 에이전트의 결과물을 검증하며, 검증이 끝날 때까지 루프가 이어진다고 함.
  29. 클로드 코드에서는 이걸 골(goal)이라 부르고 매니지드 에이전트에서는 아웃컴(outcome)이라 부르지만, 측정 가능한 종료 상태를 정하고 독립된 컨텍스트를 가진 모델이 그 루프를 채점한다는 원리는 같다고 함.
  30. 독립된 검증자가 원하는 결과를 확인해야만 루프를 빠져나온다는 게 핵심이라고 함.
  31. 실제로 써본 사례로 오픈AI가 내놓은 벤치마크 패러미터 골프(Parameter golf)를 소개함 — 모델의 머신러닝 연구 능력을 재는 벤치마크로, H100 GPU 8장으로 작은 모델을 10분 안에 학습시키고 손실값(loss)이 낮을수록 좋은 점수로 매긴다고 함.
  32. 매니지드 에이전트와 아웃컴으로 검증자 루프를 짜서 옵서스 4.7과 다른 프런티어 모델을 이 과제로 시험했다고 함.
  33. 모델이 정확히 20번 반복하고 벤치마크가 요구하는 실험 조건을 다 맞출 때까지 계속 돌게 뒀다고 함.
  34. 프런티어급 모델은 이런 소프트웨어 루프·검증 패턴에서 매우 강한 성과를 냈다고 함.
  35. 사람에게 조종 신호를 주는 대신 환경에 신호를 심어두면 모델이 피드백을 받아 스스로 고쳐나간다는 것이라고 함.
  36. 루프라는 방식을 고성능 모델과 함께 쓰면 장기 비동기 작업에 아주 좋은 일반 원리가 된다는 게 이 대목의 요지라고 함.
  37. 세 번째 주제는 자기학습(self-learning)임.
  38. 사람 뇌에는 해마(hippocampus)가 하루 동안 단기적·경험적 기억을 빠르게 적어두는 것과, 잠들었을 때 꿈이 중요한 내용을 대뇌피질의 장기기억으로 옮겨 저장하는 두 시스템이 있다고 함.
  39. 클로드도 이 두 원리를 그대로 쓰는 메모리 체계를 갖췄다는 걸 발견했다고 함.
  40. 인밴드(in-band, 작업 도중 그 자리에서) 메모리 작성 능력을 보여주는 사례로 클로드가 포켓몬 게임을 플레이하는 실험을 듦.
  41. 소넷 3.5는 메모리 디렉터리(파일로 쓸 수 있는 메모리용 폴더)에 접근권을 줘도 적는 메모리가 부실하고 전술적인 메모에 그쳐 게임 진행이 더뎠다고 함.
  42. 반면 더 최신 모델은 메모가 훨씬 전략적이고 게임 진행도 훨씬 앞서갔다고 함 — 세대가 지날수록 인밴드 메모리 작성 능력이 좋아졌다는 것임.
  43. 이를 뒷받침하는 근거로 컨티뉴얼 러닝 벤치(Continual Learning Bench, 연속 학습 능력을 재는 오픈소스 벤치마크)를 돌린 결과도 보여줌.
  44. SQL 데이터베이스를 놓고 단계마다 메모리를 쓰면서 순차적으로 질문에 답하는 과제인데, 모델 세대가 올라갈수록 성능이 올라갔다고 함.
  45. 저성능 모델과 고성능 모델의 가장 큰 차이는 증류(distillation, 경험을 나중에 쓸모 있는 형태로 압축해 남기는 일) 단계라고 함.
  46. 고성능 모델은 단순한 사실 하나를 적는 게 아니라 이게 나중 세션에 어떻게 일반화될지를 적는다는 것임.
  47. 인밴드로 적다 보면 잘못된 기억을 적거나, 그 순간 과제엔 맞지만 앞으로를 내다보지 못하는 기억을 적을 수 있다고 함.
  48. 그래서 오프라인으로 세션들을 되짚어 메모리를 다듬는 꿈꾸기(dreaming) 과정이 중요하다고 함.
  49. 이를 보여주는 사례로 다시 포켓몬을 듦 — 클로드가 잘못된 위치 기억을 적어 캐릭터가 스스로 위치를 착각하고 함정 문으로 빠지는 일이 있었다고 함.
  50. 이 오류는 5번 재현 실험 모두(5/5)에서 똑같이 나타났는데, 꿈꾸기를 거치면 오류가 고쳐져 더는 함정에 빠지지 않았다고 함.
  51. 메모리 없는 기준선은 그 구간에서 거의 진행을 못 했고, 원본 메모리만 쓴 경우는 계속 함정에 빠져 되돌아갔지만, 꿈꾸기를 거친 흔적은 오류를 고치고 다음 단계로 넘어갔다는 시각화를 공개함.
  52. 꿈꾸기는 메모리 저장소와 과거 세션 흔적을 전부 살펴 오류를 찾아 고치는 역할을 한다는 게 핵심이라고 함.
  53. 네 번째 주제는 조직 단위 하니스(org-level harness)로 가는 흐름이라고 함.
  54. 클로드 태그(Claude Tag)를 내놨을 때 반응 다수가 "슬랙봇이네"였다고 함, 본인도 슬랙봇을 여러 개 만들어봤고 그중엔 별로인 것도 많았다고 인정함.
  55. 하지만 클로드 태그가 흥미로운 지점은 슬랙으로 접근한다는 사실이 아니라 그 밑에 깔린 시스템이 풍부하다는 데 있다고 함.
  56. 기존 에이전트는 보통 개인용(single player)이었음 — 클로드 코드처럼 자기 로컬 환경에 맞춰 조정한 에이전트라고 함.
  57. 클로드 태그는 특정 사용자에 묶이지 않는 자기 정체성과 인증정보를 갖고 조직 구성원 전체가 접근해 쓸 수 있는 다인용(multiplayer) 하니스라는 점이 다르다고 함.
  58. 남이 실험하기 전에 미리 작업을 확인하거나 중복된 발견을 걸러내거나 내부 리서치를 하는 등 여러 쓸모가 있다고 함.
  59. 개인용 하니스는 신입이 커넥터를 다 설정하는 데만 몇 주에서 몇 달이 걸리는데, 조직 단위 하니스는 첫날부터 잘 다듬어진 도구를 쓰게 해주는 평준화 장치라고 함.
  60. 조직을 가로질러 여러 사용자를 넘나들며 점점 더 긴 시간대에서 작동하는 하니스가 늘어날 거라고 내다봄.
  61. 비동기 에이전트가 점점 더 능동적(proactive)으로 바뀔 거라고도 함 — 로컬 에이전트는 사람이 조종하는 대로 반응하는 데 비해, 비동기 에이전트는 스스로 먼저 나서는 능력을 갖춰간다는 것임.
  62. 클로드 태그는 조직 차원 맥락을 보고 있다가 알아둬야 할 일이 생기면 먼저 알려주도록 설정할 수 있고, 하나의 하니스를 여러 사람이 동시에 조종하는 다인용 구조도 에이전트 UX에서 중요한 변화가 될 거라고 함.
  63. 질의응답 첫 질문은 프런티어 모델이 장기 작업(태스크 호라이즌)에서 다른 모델보다 크게 앞서는 격차가 왜 벌어지는지였음, 미터 벤치마크 기준으로 오픈AI의 코덱스 계열 모델도 12시간대 영역에 들어와 있다고 답함.
  64. 비프런티어 모델이 왜 이 영역에 못 오는지는 확실히 모르겠다면서도, 모델 성능 하나만으로 되는 일이 아니라고 답함 — 클로드 태그를 예로 들며 메모리 개선, 프롬프트 주입(prompt injection, 악성 지시를 끼워 넣어 모델을 조종하려는 공격)에 대한 보안, 두뇌·손을 분리하는 아키텍처가 다 같이 맞물려야 한다고 함.
  65. 열두 시간씩 일하는 에이전트라면 생산성 선호나 막혔을 때 언제 사람에게 알려야 하는지가 메모리에 잘 담겨 있어야 하고, 프런티어 랩들이 아키텍처·인프라·보안·메모리 전부에 투자했기 때문에 이런 격차가 생겼을 거라고 봄.
  66. 두 번째 질문은 메모리를 저장할 때 왜 데이터베이스가 아니라 파일 시스템을 쓰는지였는데, 꼭 파일 시스템이어야 한다고 생각하지 않는다고 답함 — 데이터베이스도 얼마든지 잘 될 수 있고, 중요한 건 모델이 직접 다룰 수 있을 만큼 단순하고 프로그래밍하기 쉬운 저장 틀이어야 한다는 점이라고 함.
  67. 반대로 잘 안 되는 경우는 메모리 구조를 미리 짜서 정해주는 것 — 이런 유형의 기억을 저장하라는 식으로 스키마를 미리 짜는 방식이라고 함.
  68. 모델이 스스로 자기 메모리를 관리하는 법을 사람이 미리 정해준 유형보다 훨씬 잘 익힌다는 게 비터 레슨(bitter lesson, 사람이 규칙을 손으로 짜 넣기보다 모델 스스로 배우게 두는 쪽이 결국 더 잘된다는 경험칙)에 맞는 결론이라고 함.
  69. 일반적인 저장 틀을 주고 모델이 자유롭게 관리하게 두는 편이 낫고, 미리 짜인 스키마에 끼워 맞추려 하면 성능이 떨어진다는 게 핵심 차이라고 함.
  70. 마지막 질문은 꿈꾸기 과정으로 고친 메모리가 정말 맞는지 어떻게 아느냐는 것이었는데, 평가(evaluation)가 한 방법이라고 답함. 포켓몬 사례는 꿈꾸기로 교정이 일어난다는 걸 보여주는 일화적 예시일 뿐이고, 실제로는 다양한 평가를 돌려 꿈꾸기가 성능을 끌어올린다는 걸 확인했으며 이 오프라인 연산이 값어치가 있는지는 각자의 맥락에서 평가로 확인해야 한다고 함.

한줄 코멘트. 뇌·손 분리와 검증자 분리는 같은 원리다 — 한 컨텍스트가 실행과 채점을 겸하면 무너지니 무조건 떼어놓으라는 것임.

  1. 이 발표는 Neo4j(그래프 데이터베이스 회사)의 에밀 에이프렘(Emil Eifrem)이 최근 6~9개월 사이 여러 대형 조직과 일하며 본 문제 하나와 그 해법의 청사진을 짧은 키노트로 풀어놓은 것임.
  2. Neo4j는 세계에서 손꼽히는 대기업들이 자기 데이터를 AI 에이전트가 쓸 수 있게 준비하는 작업을 도와왔다고 밝힘.
  3. 예로 큰 은행에서 계좌 개설을 자동화하는 에이전트를 만든다고 가정함.
  4. 발표자는 그 에이전트를 크게 두 조각으로 단순화함. 하나는 비즈니스 로직(의도를 해석하고 계획·실행을 반복하는 부분)이고, 다른 하나는 데이터 소스임.
  5. 에이전트가 실행할 때마다 데이터를 건드리는 것은 아니지만, 에이전트가 성공하려면 맞는 시점에 맞는 데이터에 접근하는 것이 핵심이라고 함.
  6. 계좌 개설 에이전트 예시에서는 신원 확인을 위해 DMV(차량관리국) 등록부와 여권 검증 서비스, 두 데이터 소스를 연결해야 한다고 함.
  7. 이렇게 배선하면 에이전트는 잘 작동하지만, 같은 회사의 다른 팀들도 비슷하게 생긴 에이전트를 따로 만들고 있다는 게 문제의 출발점이라고 함.
  8. 첫 번째 문제는 팀마다 에이전트를 만들 때마다 필요한 데이터가 어디 있는지 매번 처음부터 찾아야 한다는 것임.
  9. 스타트업이 포스트그레스(Postgres) 데이터베이스 하나만 쓴다면 쉽지만, 엔터프라이즈는 데이터베이스가 수백 개고 스노우플레이크(Snowflake)·데이터브릭스(Databricks)·S3 버킷까지 흩어져 있어 이 작업을 매번 수작업으로 반복해야 한다고 지적함.
  10. 두 번째 문제는 엔터프라이즈에 데이터 중복이 많아서, 찾은 데이터가 맞는 버전인지, 믿을 수 있는지, 접근 권한이 있는지를 또 따져야 한다는 것임.
  11. 세 번째 문제는 소프트웨어 공학의 핵심 원칙인 DRY(반복하지 마라)를 어긴다는 것임. 뭔가 바뀌면 모든 에이전트에 그 변화가 퍼지고, 그때마다 전부 수동으로 다시 배선해야 한다고 함.
  12. 네 번째 문제는 데이터 소스와 에이전트가 그 위에서 어떻게 동작했는지에 대한 학습이 전혀 없다는 것임. 에이전트는 내일 깨어나도 오늘보다 똑똑해지지 않고, 에이전트 사이의 학습 공유도 없다고 함.
  13. 이는 비즈니스 의도와 데이터 소스 사이의 배선이 코드와 프롬프트에 흩어져 인코딩돼 있기 때문이라고 설명함.
  14. 이 대목에서 발표자는 청중이 "마크다운 파일과 스킬(skill)로 해결하면 되지 않냐"고 생각할 걸 안다며, 답은 "맞기도 하고 아니기도 하다"라고 함.
  15. 마크다운 파일만으로 이 문제를 풀려던 팀을 숱하게 봤는데, 그것은 해법의 일부일 뿐 전체 해법은 아니라고 정리함.
  16. 자기 말만 믿지 말라며, 일주일 전 스와이엑스(Swyx)가 진행하는 레이턴트 스페이스(Latent Space) 팟캐스트에 나가서 "데이터베이스를 알아야 한다, 마크다운 파일만으로 바이브 코딩할 수는 없다"고 자신이 말했다고 함.
  17. Neo4j는 최근 이 문제를 대규모로 풀어봤는데, 대상은 포춘 20위 안에 드는 글로벌 은행, 베이 에어리어에 본사를 둔 대형 테크 플랫폼 회사, 그리고 선도적인 핀테크 회사였다고 함.
  18. 이 작업에서 드러난 패턴은 규모 있게 하려면 "더 똑똑한 공유 바닥(substrate) 위에 얇은 에이전트"를 둬야 한다는 것이라고 함.
  19. 이 패턴에는 세 기둥이 있다고 함.
  20. 첫 번째 기둥은 비즈니스를 향한 온톨로지(ontology, 개념과 그 관계를 정리한 체계)임.
  21. 온톨로지라는 말이 최근 특히 팔란티어(Palantir)와 AI 부상 덕에 유행어가 됐고 사람들이 복잡하게 만들려 하지만, 핵심 개념은 단순하다고 함.
  22. 조직의 핵심 개념이 무엇이고 서로 어떻게 관계를 맺는지를 정리하는 것이며, 은행 예시라면 고객·계좌·직불카드·수표·거래 같은 것들이라고 함.
  23. 중요한 것은 그 조직에서 일하는 모든 사람이 이해하는 이름으로 표현한다는 점이라고 함. 코드에서 흔히 쓰는 `if_name` 같은 변수명이 아니라 "고객에게는 이름(first name)이 있다"는 식으로 쓴다고 함.
  24. 두 번째 기둥은 기술 온톨로지임. 엔터프라이즈 생태계 안 모든 데이터 소스와 자산의 메타데이터, 즉 오라클(Oracle) 데이터베이스 14개, Neo4j 데이터베이스 15개, 스노우플레이크·데이터브릭스·S3 버킷이 어디에 있고 스키마가 무엇인지를 담는다고 함.
  25. 이 기술 온톨로지를 만드는 방법이 세 가지 있다고 언급하지만, 이번 발표에서는 다루지 않는다고 함.
  26. 그리고 비즈니스 온톨로지와 기술 온톨로지 사이를 잇는 매핑이 있다고 함. 예로 고객의 이름(first name)이라는 개념이 실제로는 오라클 데이터베이스의 `F_name`이라는 칼럼에 저장돼 있다는 연결이라고 함.
  27. 세 번째 기둥은 에이전트가 남기는 런타임 신호, 즉 실행 추적(execution trace)임. 에이전트가 이 그래프를 순회하며 실행할 때 무엇을 시도했는지, 성공했는지, 결과가 무엇이었는지 흔적을 남긴다고 함.
  28. 계좌 개설 에이전트 예시로 돌아가, 단순화한 그래프에는 수표·계좌·신용 이력 같은 비즈니스 개념과 이 에이전트가 따라야 할 비즈니스 프로세스 노드까지 함께 인코딩돼 있다고 함.
  29. 그래프에서 초록색으로 표시된 "컴플라이언스 확인(check compliance)" 노드를 기술 온톨로지 쪽으로 넘겨보면, 컴플라이언스 확인을 하려면 정부 발급 신분증을 확인해야 한다는 것이 이미 발견돼 인코딩돼 있다고 함.
  30. 이 조직에서는 그 신분증 확인을 도와줄 데이터 소스가 차량 등록 기록과 여권 검증, 두 가지라고 그래프에 담겨 있다고 함.
  31. 에이전트가 컴플라이언스를 확인해야 한다고 판단하면, 정부 발급 신분증이 필요하다는 것과 그것을 해결할 두 가지 방법을 그래프에서 바로 찾을 수 있다고 함.
  32. 에이전트가 이 방법 중 하나를 실제로 실행하면, 어디에 있었는지·무엇을 했는지·맥락이 무엇인지·성공했는지를 담은 실행 추적을 세 번째 기둥에 남긴다고 함.
  33. 이 실행 추적은 결국 점수 하나로 이어지고, 이 점수를 다음 실행의 입력으로 쓴다고 함. 예로 DMV 조회로 계속 성공했다면 비슷한 맥락에서 다음에도 DMV 쪽을 더 선호하게 된다고 설명함.
  34. 비즈니스 온톨로지, 기술 온톨로지, 실행 추적, 이 세 기둥을 합치면 앞서 말한 네 가지 문제가 모두 풀린다고 정리함.
  35. 데이터 소스를 쉽게 찾을 수 있고, 그것이 믿을 만한지도 알 수 있다고 함. 이 신뢰는 관리자 같은 사람이 위에서 정리해둔 지식과, 실행 추적을 통해 실제로 뭐가 통했는지 아래에서 쌓인 증거 둘 다에서 나온다고 함.
  36. 비즈니스 의도와 개념을 데이터 소스에 연결하는 곳이 한 군데로 통제되므로 같은 배선을 반복하지 않는다고 함. 뭔가 바뀌면 그 변화가 모든 에이전트에 한 번에 퍼진다고 함.
  37. 자기 학습도 생긴다고 함. 에이전트는 내일 깨어나면 오늘보다 조금 더 똑똑해지고, 이 학습은 한 에이전트 안에서뿐 아니라 여러 에이전트에 걸쳐서도 일어난다고 함.
  38. 결국 데이터 소스를 수동으로 배선한 "두꺼운 에이전트"의 세계에서, 더 똑똑한 공유 온톨로지 기반 의미 층(semantic layer) 위에 올라앉은 "얇은 에이전트"의 세계로 옮겨가는 것이라고 정리함.
  39. 이 구조 덕에 에이전트마다 매번 재설계하지 않고도 훨씬 많은 에이전트를 만들 수 있게 된다고 함.
  40. 관심 있으면 문서 웹페이지가 있고, 슬라이드의 QR코드를 찍거나 엑스포 P3 부스로 찾아오면 더 이야기할 수 있다고 안내함.
  41. 이 패턴은 그래프와 AI를 결합한 여러 패턴 중 하나일 뿐이고, 지금 방 2005에서 시작하는 그래프 트랙에서 게이츠 재단(Gates Foundation)·먼데이닷컴(monday.com)·JP모건 체이스·버클리·뉴욕타임스 같은 조직의 발표를 들을 수 있다고 함.
  42. 마지막으로 이 발표는 데이터 소스와 에이전트가 많은 조직을 중심으로 한 이야기지만, Neo4j로 만드는 스타트업에는 별도의 스타트업 프로그램이 있다고 함.
  43. 이 프로그램은 무료 크레딧을 주는 것은 물론, 스타트업이 Neo4j로 데이터를 모델링하고 성능을 튜닝하는 것을 매일 무료로 도와주는 전담 솔루션 엔지니어링 팀까지 갖췄다고 함.

한줄 코멘트. 이 발표의 진짜 주장은 "온톨로지를 만들자"가 아니라 "배선을 한 곳에 모아 반복하지 말자"임 — 세 기둥 중 정말 새로운 건 실행 추적으로 신뢰를 아래에서부터 쌓는다는 부분이고, 나머지 둘은 사실 메타데이터 카탈로그 얘기임.

  1. 발표자는 티샤 차울라(Tisha Chawla)이고, 공동 발표자와 함께 마이크로소프트(Microsoft)에서 실제 프로덕션 백엔드에 에이전트를 붙여 돌리는 팀 소속이라고 밝힘.
  2. 이런 곳에서는 잘못된 주문이 나가도 "또 실수했네"로 넘어갈 수 없고, 고객과 통화하며 돈이 어디로 갔는지 설명해야 하는 자리라고 함.
  3. 이번 발표 전체는 에이전트가 프로덕션에서 오작동하는 순간 가장 먼저 잃는 것, 곧 그 실행을 다시 재현하는 능력을 다룬다고 함.
  4. 에이전트가 이상하게 굴었을 때 흔한 대응은 텔레메트리(telemetry, 시스템이 자동으로 남기는 실행 기록) 로그에서 원본 프롬프트를 꺼내는 것이라고 함.
  5. 그 프롬프트를 같은 모델로 로컬에서 다시 돌려 버그를 잡으려 하는데, 그렇게 돌리면 대개 문제없이 잘 돌아가고 열 번을 더 돌려도 매번 멀쩡하다고 함.
  6. 정작 비용을 발생시킨 그 한 번의 실행은 사라져 재현이 안 되고, 재현이 안 되면 디버깅도 안 되며, 디버깅이 안 되면 다음 고객에게 같은 일이 안 생긴다고 장담할 수도 없다고 함.
  7. 실제로 어떻게 사고가 터지는지 보여주려고 브로커(broker, 주식 매매를 대행하는 증권사) API에 연결된 에이전트 사례를 듦.
  8. 사용자가 "1,000달러어치 주식을 팔아 달라"고 요청했는데, 에이전트가 그 1,000이라는 숫자를 계산 없이 그대로 수량(quantity) 칸에 넣었다고 함.
  9. 그 결과 1,000달러어치가 아니라 1,000주가 팔렸고, 주당 190달러였으니 원래 1,000달러짜리 매도가 190,000달러짜리 사고가 됐다고 함.
  10. 더 무서운 건 API가 200 OK 응답을 30밀리초 만에 깨끗하게 돌려줬고 예외도 알림도 하나 없었다는 것이라고 함.
  11. 거래 내용은 완전히 틀렸는데 대시보드는 아무 이상 없이 초록불로 멀쩡했다고 함.
  12. 이런 사고가 났을 때 첫 반응은 모델 온도(temperature, 다음 토큰을 고를 때 무작위성을 얼마나 줄지 정하는 값)를 0으로 낮추는 것이라고 함.
  13. 늘 가장 확률 높은 토큰만 고르는 그리디 디코딩(greedy decoding)으로 결정적으로 만들면 된다고 여기는 것인데, 이건 완전한 착각이라고 함.
  14. 온도를 0으로 낮춰도 잘못된 추론 경로 자체는 고쳐지지 않아, 모델이 똑같은 논리적 실수를 똑같은 방식으로, 심지어 똑같은 시점에 되풀이한다고 함.
  15. 레딧(Reddit)과 해커뉴스(Hacker News)의 엔지니어링 스레드를 봐도 온도 0이 하드웨어 수준에서는 진짜 결정적이지 않다는 게 확인된다고 함.
  16. 같은 프롬프트를 천 번 돌려도 GPU 비결정성과 MoE(mixture of experts, 여러 전문 하위 신경망 중 일부만 골라 쓰는 모델 구조) 아키텍처 때문에 수십 가지 다른 응답이 나올 수 있다고 함. 이 현상을 원리부터 짚으며 네 가지로 정리함.
  17. 첫째, 샘플링 결정성과 시스템 결정성은 다른 것임. 온도 0은 늘 아그맥스(argmax, 확률이 가장 높은 후보를 고르는 연산)를 쓴다는 뜻일 뿐, 그 밑에 깔린 점수 자체가 실행마다 똑같다는 보장은 아니라고 함.
  18. 둘째, 부동소수점(floating point) 연산은 결합법칙이 성립하지 않아 소수를 더하는 순서가 결과를 바꾸는데, 이 작은 차이가 최종 로짓(logits, 모델이 다음 토큰 후보마다 매기는 점수)을 흔들어 이기는 토큰을 뒤바꾼다고 함.
  19. 셋째, 이건 동시성 문제가 아니라고 함. 같은 행렬곱을 GPU에서 혼자 천 번 돌리면 매번 비트 단위로 똑같은 값이 나오기 때문임.
  20. 진짜 범인은 배치 불변성(batch invariance)임. 요청 하나가 그 순간 서버에 함께 들어온 다른 요청들과 묶여 처리되기 때문에 결과가 달라진다고 함.
  21. 넷째, MoE 라우팅도 같은 병목을 갖는다고 함. 전문가(expert, 모델 안에서 특정 종류의 입력만 맡아 처리하는 하위 신경망)마다 처리 용량이 정해져 있어 배치가 그 용량을 넘치면 토큰이 다른 전문가로 재배정되는데, 통과 여부는 순전히 어떤 트래픽과 함께 배치됐는지에 달려 있다고 함.
  22. 결론은 텍스트 출력 자체를 똑같이 맞추려는 싸움은 완전히 지는 싸움이라는 것임. 매번 똑같은 토큰이 나올 필요는 없고 시스템이 똑같은 상태 전이(state transition)를 실행하기만 하면 된다고 함.
  23. 즉 지금까지 질문을 잘못 던졌다는 것임. "어떻게 모델을 결정적으로 만들까"에 매달려 몇 주를 태우고 시스템은 알 수 없는 것이라며 포기하는 팀을 봤다고 함.
  24. 맞는 질문은 "재현할 수 없는 실행을 어떻게 디버깅하고 다시 테스트할까"임. 애초에 목표는 결정성이 아니라 디버깅이었다고 함.
  25. 여기서 자꾸 헷갈리는 두 단어를 구분해야 한다고 함. 비트 단위 결정성(bitwise determinism)은 같은 입력에 같은 출력이 나오는 것으로, 통제 가능성(controllability)에 해당함.
  26. 이건 호스팅된 API에서는 얻을 수도 없고, 사실 원하지도 않는다고 함. 무작위성이야말로 모델을 더 창의적으로 만드는 요소이기 때문이라고 함.
  27. 다른 하나는 재생 가능성(replayability)임. 이미 벌어진 실행을 디버깅할 수 있을 만큼 다시 검증하는 것으로, 관측 가능성(observability)에 해당함.
  28. 모델을 결정적으로 만들 필요는 없고 그 실행이 기록돼 있으면 됨. 모델을 얼려 둘 게 아니라 모델이 실제로 한 일을 붙잡아 두면 된다고 함.
  29. 그럼 어디서 기록해야 하느냐는 질문이 남는데, 네트워크 계층은 아니라고 함. 로컬 검색이나 프로세스 안에서 도는 툴, 메모리처럼 에이전트의 절반은 네트워크를 아예 건드리지 않기 때문이라고 함.
  30. 대신 경계(boundary)에서 기록해야 한다고 함. 각 노드에 들어오고 나가는 것, 곧 패킷이 아니라 각 단계의 의미를 붙잡아야 한다고 함.
  31. 이렇게 재생(replay)을 더하면 모델을 멈추고 모델 호출 없이 실패한 지점을 그대로 다시 돌리는 결정적 CI(continuous integration, 코드가 바뀔 때마다 자동으로 돌아가는 검증 파이프라인)가 생긴다고 함.
  32. 전체 루프는 주석 달기(annotation), 기록, 시각화, 이해, 고치기, 되감기(replaying), 검증하기 순서로 이어진다고 함.
  33. 이걸 실제로 코드에 옮긴 사례로 공동 발표자가 크로니클(Chronicle)이라는 도구를 개념 증명(proof of concept)으로 만들었다고 소개함.
  34. 크로니클의 핵심은 경계(boundary)라는 개념이고, 에이전트 워크플로 안의 어떤 노드든 감싸는 바운딩 박스로 생각하면 된다고 함.
  35. 노드는 툴 호출일 수도, LLM 호출일 수도, RAG(모델이 답하기 전에 외부 문서를 먼저 찾아와 그 내용을 근거로 쓰게 하는 방식)에서 검색해오는 것일 수도 있고, 메서드이기만 하면 경계 주석을 달 수 있다고 함.
  36. 경계 주석을 달면 메서드에 들어가고 나오는 모든 입력·출력 쌍이 기록되고, 모델 버전이나 코드 버전 같은 파라미터도 정의할 수 있어 실행 당시 상태 전체가 트레이스(trace, 실행 과정을 통째로 기록한 데이터)로 얼어붙어 저장된다고 함.
  37. 앞서 든 주식 매도 에이전트로 시연함. 사용자 입력을 받는 계획 단계, 실제 매수·매도를 수행하는 주문 실행 툴, 응답을 만드는 마무리 에이전트까지 세 노드에 경계 주석을 달았다고 함.
  38. 사용자가 에이크미(Acme) 주식을 1,000달러어치 팔아 달라고 요청한 실행을 돌리자 세 노드 각각의 입력과 출력이 그대로 기록됐다고 함.
  39. 트레이스를 보면 LLM이 1,000이라는 숫자를 수량으로 착각해 심볼 에이크미, 수량 1,000짜리 주문 실행 툴 호출을 만들어냈고, 그 툴이 실제로 주당 190달러에 1,000주를 팔았다고 함.
  40. 문제가 바로 여기서 시작됐다는 걸 알 수 있는데, 트레이스는 여기서 끝이 아니라고 함. 각 노드가 주고받은 내용을 훨씬 자세한 JSON으로도 볼 수 있어 모델 버전·샘플링 버전 같은 메타데이터까지 확인할 수 있다고 함.
  41. 문제를 잘못된 툴 호출을 만든 LLM으로 특정했는데, LLM 자체는 통제할 수 없고 비트 단위 결정성도 강제할 수 없다고 함.
  42. 대신 할 수 있는 건 툴에 가드레일(guardrail, 에이전트의 위험한 행동을 막는 규칙)을 걸어 신뢰도를 어느 정도 확보하는 것이라고 함.
  43. 그렇게 가드레일을 만들었으면 어떻게 테스트하느냐가 또 문제인데, 경계 주석이 이미 메서드마다 경계를 잡아 놓았기 때문에 테스트할 때 그 메서드를 스텁(stub, 실제 동작 대신 가짜 응답을 끼워 넣는 것)으로 바꿔 넣는 데도 그대로 쓸 수 있다고 함.
  44. 기록된 실행 하나가 있고 이번엔 툴 코드만 고쳤다면, 나머지 노드는 스텁으로 두어 전체 실행 흐름을 똑같이 유지한 채 테스트할 수 있다고 함.
  45. 시연에서는 트레이스를 불러와 크로니클의 재생 모드(replay mode)를 켜서 첫 번째 에이전트(LLM) 호출은 스텁으로 재생하고 툴은 실제로 살려서 돌렸다고 함.
  46. 툴 호출 결과도 이미 기록돼 있으니 그걸로 어서션(assertion, 코드가 실행 중 기대한 값과 맞는지 자동으로 확인하는 검사)을 걸 수 있는데, 이번엔 주문이 실제로 차단됐는지 확인해 통과시켰다고 함.
  47. 크로니클이 에이전트 세션을 기록만 하는 게 아니라 그 기록을 테스트 케이스로도 쓴다는 것을 이렇게 보여줌.
  48. AI 에이전트를 테스트하는 방식은 결정적 테스트(deterministic testing)와 행동적 테스트(behavioral testing) 두 가지로 나뉘고, 둘 다 똑같이 중요하다고 함.
  49. 결정적 테스트는 가드레일이나 툴 호출처럼 에이전트 그래프의 결정적인 노드에 적용되는데, 크로니클이 전체 실행을 통째로 얼려 두기 때문에 LLM 노드의 출력을 스텁으로 바꿔 확률을 아예 걷어낼 수 있다고 함. 그러면 모델을 다시 부르지 않는 재실행 가능하고 무료인 테스트 케이스가 된다고 함.
  50. 행동적 테스트는 에이전트의 어조나 밟은 경로가 맞는지처럼 더 주관적인 영역이라 LLM을 심사자로 쓰는 방식(LLM as a judge)이 더 낫다고 함.
  51. 마지막으로 다섯 가지 핵심을 정리함. 첫째, API를 통해 비트 단위 결정성을 쫓는 걸 그만두라고 함. 오늘날 API가 서 있는 근본 원리 자체가 그걸 불가능하게 만든다고 함.
  52. 둘째, 자기 세션의 변수가 뭔지 알아야 함. LLM 버전, 빌드 ID, RAG 청크(chunk, 문서를 검색하기 좋은 크기로 잘라 놓은 조각) 같은 것들을 반드시 로깅하라고 함.
  53. 셋째, 프롬프트만 붙잡지 말고 전체 봉투(envelope)를 붙잡으라고 함. 최종 응답에 들어가는 재료는 프롬프트 하나보다 훨씬 많다고 함.
  54. 넷째, 재생을 디버깅에 써서 문제를 찾고 실패를 고친 다음, 같은 트레이스를 테스트 케이스로 재사용하라고 함.
  55. 다섯째이자 마지막으로, 생성 시점의 변동성을 죽이지 말라고 함. 온도를 0에 박아 두려 하지 말라는 것인데, 그 변동성이야말로 에이전트에 주체성(agency)을 불어넣는 것이기 때문이라고 함.
  56. 화면에 뜬 QR 코드를 스캔하면 크로니클 코드와 관련 글을 볼 수 있다고 안내하며, 오늘 남긴 트레이스가 내일 온콜(on-call, 장애 발생 시 즉시 대응하도록 대기하는 근무) 사이클을 더 낫게 만들길 바란다고 마무리함.

한줄 코멘트. 재현 대신 재생을 파는 접근은 옳지만, 노드 경계마다 입출력을 다 얼려서 저장·재생하는 인프라를 새로 얹는 비용이 얼마나 느는지는 발표에서 다루지 않음.

  1. 이 발표는 마이크로소프트(Microsoft)에서 AI 엔지니어링을 다루는 크리스 노어링이 한 것으로, 제목은 "코드를 쓰다가 시스템을 설계하는 일로"임.
  2. 발표자가 청중에게 "지금도 평소처럼 코딩하는 사람"이 몇 명이냐고 묻자 손을 든 사람이 많지 않았고, 이미 시스템 접근으로 넘어간 청중이 대부분이라고 짚음.
  3. 클로드(Claude)와 코파일럿(Copilot) 사용자를 각각 물었을 때 반반 정도였고 클로드가 조금 더 많았는데, 발표자는 마이크로소프트가 앤스로픽(Anthropic)과 행사도 같이 다니는 좋은 사이라고 밝힘.
  4. 옛날엔 키보드에 100% 매달렸고 개발자 자신이 진행 속도의 한계였다고 함. 실력이 있어도 진행은 늘 선형적이었고 기능을 만들지 말지는 전적으로 자신에게 달려 있었음.
  5. 발표자는 이제 그 한계가 더는 아니라고 함.
  6. 일자리는 사라지지 않았지만 무게중심이 옮겨 갔다고 함. 더 이상 100% 개발자는 아니지만 다른 위치에 서 있다는 것임.
  7. 여전히 코드를 쓰긴 하지만 이제 도우미가 워낙 많아져서 무엇을 직접 쓸지 훨씬 아껴서 고른다고 함.
  8. "AI 슬롭(AI slop, 품질이 낮아 그대로 쓰기 어려운 AI 산출물)"이라는 말을 다들 안다며, 초기 AI 도구가 내놓은 코드를 믿을 수 없어 오히려 다시 쓰는 일이 더 많았다고 함.
  9. 지금은 가드레일(guardrail, 에이전트가 제멋대로 움직이지 않도록 미리 정해두는 규칙과 제약)이 일하는 방식의 큰 축이 됐다고 함.
  10. AI 도구를 안 쓰는 선택지는 더 이상 없고, 문제는 어떤 도구냐는 것으로 넘어갔다고 함. 클로드를 쓰면 클로드 코드(Claude Code)나 클로드 데스크톱, 코파일럿을 쓰면 CLI(명령줄 인터페이스)에 깃허브(GitHub) UI에 에디터까지 있다고 함.
  11. 발표자는 자신만의 새 워크플로를 제안하면서, 이건 자기 생각일 뿐이니 틀렸다고 해도 괜찮다고 미리 못박음.
  12. 첫 단계는 CLI에서 시작하는 것. 에디터가 늘 개발자의 첫 진입점이었기 때문에 이상하게 들릴 수 있다고 인정함.
  13. 발표자는 이제 에디터를 아예 켜지 않는다고 함. 켤 필요가 없어졌기 때문이라고 함.
  14. 두 번째 단계는 에디터. 20년 경력 중 19년 반을 에디터에서 보냈다며, 여기가 자신이 익숙한 곳이라고 함.
  15. 세 번째 단계는 스케일(scale, 규모를 키우는 것). CLI나 깃허브 UI가 규모를 키우는 지점이 될 수 있다고 함.
  16. 발표자가 제안하는 새 출발점은 깃허브 코파일럿 CLI, 또는 클로드를 쓴다면 그 CLI라고 함.
  17. 업계 사례로, 엔지니어들이 더 이상 파워포인트가 아니라 돌아가는 데모(working demo)를 가져온다는 이야기를 들었다고 함. 개발자라면 파워포인트보다 데모를 원한다는 것임.
  18. 첫 초안을 만들고 가드레일을 세운다는 순서를 강조함. 가드레일 없이는 "난장판(mayhem), 혼돈(chaos)"이라고 표현함.
  19. CLI를 쓰는 이유 중 하나로, 깃허브 이슈나 PR(풀 리퀘스트, 코드 변경을 병합해 달라고 올리는 요청)을 UI를 열지 않고도 15개씩 닫을 수 있다는 점을 듦.
  20. 에이전틱(agentic) 도구를 쓰면서부터 자바나 자바스크립트, 파이썬을 직접 쓰는 일이 줄고 대신 "앱을 만들어줘", "이 기능을 추가해줘", "이거 고쳐줘" 같은 프롬프트를 쓴다고 함.
  21. 터미널 여러 개를 띄워놓고 앱을 만들게 시킨 뒤 커피나 차를 마시고 있는 게 요즘 자신의 일상이라고 함.
  22. CLI에서 에디터로 넘어갈 때도 가드레일과 커스텀 에이전트(custom agent)를 세워야 한다고 함.
  23. 15개, 20개씩 대신 일해주는 에이전트가 있으니 에디터에 앉아 어떤 코드를 쓸지 고민하는 시간은 점점 줄여야 한다고 제안함.
  24. 그래도 발표자는 여전히 에디터를 좋아한다고 함. 20년 중 19년 반을 보낸 곳이라 더 통제감이 들고 익숙하다는 것임.
  25. 어떤 AI 에디터나 제공자를 쓰든 CLI 스트림, 에디터 스트림, 깃허브 저장소에서 벌어지는 흐름을 함께 지켜보는 무언가가 있을 것이라며, 에디터를 관제판(control board)처럼 본다고 함.
  26. 규칙 없이는 에이전트가 제멋대로 움직인다며, 그래서 가드레일을 더한다고 함.
  27. 가드레일 첫 번째는 Agents.md임. 저장소 의도, 애플리케이션 아키텍처, 제약, 해도 될 일과 안 될 일을 담은 최소한의 상위 지침이라고 함.
  28. 예를 들어 "내가 말하지 않는 한 아키텍처를 바꾸지 마라" 같은 것을 Agents.md에 적어둘 수 있다고 함.
  29. 발표자는 코딩으로 만든 개인 재무 추적기(finance tracker) 저장소를 데모로 보여주며, 프로젝트 개요와 에이전트별 역할이 담긴 꽤 긴 Agents.md 파일을 소개함.
  30. 채팅창에 "이 Agents.md는 뭘 하는 파일이냐"고 물어볼 수 있고, 다른 프로젝트의 Agents.md를 새 프로젝트에 그대로 복사해 붙여넣고 "이걸 따르게 하라"고 시킬 수도 있다고 함.
  31. 가드레일 두 번째는 스킬(skill)임. 에이전트가 매번 똑같이 틀리거나 엉뚱한 방향으로 가는 문제를 겪었다며, 반복되는 일에는 정해진 레시피가 필요하다고 함.
  32. 청중 다수가 이미 스킬을 쓰고 있었고, 발표자는 스킬을 에이전트가 즉흥적으로 논리를 만들어내지 않고 호출하는 계약(contract)이라고 설명함.
  33. 스킬은 위험을 줄이려는 장치로, 창의적으로 굴지 말고 정해진 도구만 쓰라고 강제하는 하네스(harness, 에이전트를 정해진 틀 안에 묶어두는 장치)라고 함.
  34. 스킬은 폴더 하나에 자족적으로 담기고, 반복되고 순서가 정해진 일을 위해 의도적으로 제약돼 있다고 함.
  35. 클로드에서는 보통 .claude/skills 폴더 아래 스킬마다 폴더를 두고 그 안에 skill.md를 두는데, 이름과 설명이 담긴 프런트매터 뒤에 긴 마크다운 지침이 이어진다고 함. 코파일럿에서도 같은 구조라고 밝힘.
  36. 앤스로픽이든 마이크로소프트든 벤더가 다 스킬이라는 개념에 동의한 게 다행이라고 함. 개발자가 어떤 벤더를 쓸지 늘 스스로 고르는 건 아니기 때문이라고 함.
  37. 발표자는 자신이 지침을 잘 못 쓴다며 코파일럿에게 "더 나은 지침을 어떻게 쓰냐"고 되묻는 게 즐겨 쓰는 방법이라고 밝힘. 이건 코파일럿 UI를 보여주는 자사 제품 데모라고 밝힘.
  38. 스킬은 /skills 명령으로 설정하거나, 스킬 이름·설명과 비슷한 프롬프트를 그냥 입력하는 것만으로도 호출된다고 함.
  39. 가드레일 세 번째는 커스텀 에이전트(custom agent)임. 스킬만으로 부족할 때, 즉 스킬끼리 스스로 오케스트레이션(orchestration, 여러 작업을 조율해 순서대로 돌리는 것)하지 못할 때 다음 단계가 필요하다고 함.
  40. 청중에게 물으니 Agents.md와 스킬만 쓰고 그 이상은 안 쓴다는 사람은 적었고, 대부분 에이전트까지 쓰고 있었다고 함.
  41. 커스텀 에이전트는 페르소나(persona)를 가지며 여러 스킬을 함께 쓸 수 있고, 보안 전문가나 백엔드 담당, 프런트엔드 담당처럼 뚜렷한 역할과 목적을 지닌다고 함.
  42. 커스텀 에이전트는 MCP(모델 컨텍스트 프로토콜, Model Context Protocol, 모델이 외부 도구나 서비스에 붙도록 정한 규격) 서버도 쓸 수 있어 스킬보다 상위 개념이라고 함.
  43. 에이전트는 오케스트레이터에 가깝고 범위가 더 넓으며, 페르소나와 계획·추론 능력을 갖는다는 점에서 스킬과 자율성 수준이 다르다고 함.
  44. 커스텀 에이전트도 스킬처럼 프런트매터와 지침을 갖지만, 어디에 두는지가 다르다고 함.
  45. 코파일럿에서는 보통 .github/agents 아래 두고 파일 이름을 .agent로 끝내야 인식된다고 함.
  46. 스킬 프런트매터에는 이름과 설명만 있었는데, 커스텀 에이전트 프런트매터에는 인자 힌트(argument hint)와 툴(tools) 항목이 추가된다고 함. 툴 항목이 그 에이전트가 뭘 할 수 있고 없는지를 제약하는 핵심이라고 함.
  47. 데모로 보여준 "리서처(researcher)" 커스텀 에이전트는 웹 검색만 하도록 제약돼 있고, 파일을 만들거나 고치지는 못하게 해뒀다고 함.
  48. 리서처 에이전트를 부를 땐 채팅창에 질문을 쓰고 리서처를 직접 골라 선택한 뒤 마이크로소프트 에이전트 프레임워크(Microsoft Agent Framework) 같은 걸 물어봤다고 함.
  49. 마지막 장은 스케일링(scaling)임. 발표자는 에이전트를 "토들러(toddler, 걸음마 뗀 아기)"에 비유하며, 어떤 때는 천재 같고 어떤 때는 믿기지 않을 만큼 어이없다고 함.
  50. 그래서 하네스가 왜 필요한지 이해해야 한다며, 위임(delegation)에는 다 찬성하지만 가드레일이 먼저라는 점을 다시 짚음.
  51. Agents.md와 스킬, 커스텀 에이전트로 기반을 다졌으니 이제 자신을 스케일링할 차례이고, 10배·20배·100배 개발자가 될 수 있다고 함.
  52. 코파일럿 기준으로 스케일링 경로는 두 가지임. CLI에서 바로 하거나, 깃허브 저장소 UI에서 하는 것이라고 함.
  53. CLI 스케일링 데모에서 /delegate 명령으로 "내 지출을 추적하는 재무 앱을 HTML, CSS, 자바스크립트로 만들어줘"라고 시킴.
  54. /delegate를 쓰려면 정식 깃허브 저장소여야 하고, 아니면 저장소부터 만들라고 되돌아온다고 함.
  55. 위임하면 세션이 깃허브로 보내지고 잡(job)이 시작되면서 초안 PR이 만들어진다고 함.
  56. 대부분의 에이전트는 샌드박스(sandbox, 격리된 실행 환경) 안에서 돌기 때문에 샌드박스를 벗어나 이상한 일을 벌이지 못하고, 대신 PR을 만들어 사람이 검토하게 한다고 함.
  57. 깃허브 화면에서 위임된 작업이 재무 앱을 만들려 시도하며 플레이라이트(Playwright)나 깃허브 MCP 같은 MCP 서버를 쓰는 모습을 보여줌. 이건 코파일럿 CLI와 깃허브 UI를 보여주는 자사 제품 데모라고 밝힘.
  58. 터미널 여러 개를 열어놓고 이것도 위임, 저것도 위임하다 보면 어느새 제품 백로그(backlog, 앞으로 처리할 작업 목록) 전체를 처리하게 된다고 함.
  59. 두 번째 방식은 깃허브 UI에서 이슈를 만드는 것. "내 앱에 다크 모드를 추가해줘"라는 제목과 설명으로 이슈를 만들고 "에이전트에게 배정(assign to agent)" 버튼을 누른다고 함.
  60. 이슈를 여러 개 만들어 각각 에이전트에게 배정한 뒤 커피를 마시러 가면 된다고 함.
  61. 에이전트가 배정되면 작업 중임을 알리는 아이콘이 뜨고 진행 상황을 클릭해서 볼 수 있으며, 끝나면 초안 PR과 함께 "이거 배포해도 될까요?"라고 물어온다고 함.
  62. 이게 백그라운드에서 일어나는 동안 다른 일을 계속할 수 있다는 게 위임의 힘이라고 함.
  63. 발표자는 이 시대를 도끼로 나무를 베던 사람들에 비유하며, 이제는 도끼를 던지고 체인톱을 쓰는 셈이라 훨씬 빠르다고 함. 더 나은 도구를 쓰는 건 개발자에게 새삼스러운 일이 아니라고 함.
  64. 그럼에도 사람이 여전히 중요한 이유는, 에이전트가 하네스 안에서 움직이도록 시스템을 사람이 만들었기 때문이라고 함. 승인 게이트(approval gate)를 사람이 두고, 최종 병합도 사람이 한다고 함.
  65. 정리하며, CLI 기반 에이전트 도구를 안 써봤다면 터미널 예닐곱 개를 띄워 부업이든 대기업 업무든 훨씬 많은 걸 해낼 수 있다고 함. 에디터를 벗어날 용기만 있다면 CLI로 새 앱도 만들 수 있다는 것임.
  66. 발표자 자신은 에디터를 점점 덜 쓰고, 미세 조정 정도에만 쓴다고 함. 에디터 경험이 더 나은 순간도 분명 있다고 덧붙임.
  67. CLI나 깃허브 UI가 스케일하고 위임할 수 있게 해주니 이제 예전보다 20배 개발자가 됐다고 하되, 이건 올바른 가드레일을 갖췄을 때에 한한다고 조건을 붙임.
  68. 코드가 20배 늘어나면 슬롭도 20배 늘어날 수 있어서 그건 원하지 않는다고 함.
  69. 오늘 소개한 가드레일은 Agents.md, 스킬, 커스텀 에이전트라고 다시 정리함.
  70. 마지막으로 이 모든 게 개발자를 대체하는 게 아니라 지금의 개발자를 스케일링하는 것이라며, 엔지니어링 두뇌가 필요하니 이 업계에 계속 남아 달라는 메시지로 마침.

한줄 코멘트. 이 발표가 파는 건 CLI도 에이전트도 아니라 가드레일을 쌓는 순서임 — Agents.md 없이, 스킬 없이 위임부터 걸면 20배 개발자가 아니라 20배 슬롭이 된다는 경고가 핵심으로 보임.

  1. 발표자 타릭은 안트로픽(Anthropic)에서 클로드 코드(Claude Code, 사용자 대신 여러 단계로 작업을 쪼개 도구를 부르며 코드를 다루는 에이전트)를 만드는 일을 한다고 자신을 소개함.
  2. 이날 늦게 페이블(Fable)이라는 새 모델을 내놓을 예정이라고 밝힘.
  3. 페이블을 알아가는 법을 다룬 글 시리즈를 이 발표 하나로 압축해서 들려준다고 함.
  4. 발표를 네 부분—클로드 언하블링(unhobbling, 모델이 원래 가진 능력을 감싸던 제약을 풀어주는 일), 내 언노운(unknown, 모르는 것) 찾기, 상실감 다루기, 무리하게 굴기—으로 나눔.
  5. 안트로픽에서는 모델을 설계하는 게 아니라 기른다고 자주 말한다고 함.
  6. 데이터와 피드백과 연산을 주고, 모델과 함께 써보며 배워나가는 유기적인 과정이라는 것임.
  7. 그래서 모델을 가두는 틀은 결국 안트로픽 자신이라고 함. 클로드를 담는 하니스(harness, 모델을 감싸 도구·규칙과 함께 움직이게 하는 실행 틀)와 프롬프트가 클로드를 이해하는 만큼만 만들어진다는 뜻임.
  8. 언하블링이란 클로드를 더 잘 이해해서 그 능력을 풀어주는 일이라고 정의함.
  9. 모델이 똑똑해지는 방식이 직관과 다르다는 예로 포켓몬 이야기를 듦.
  10. 포켓몬 1000마리 중 이름이 AW로 끝나는 건 크로코노(Croconaw)와 드레드노(Drednaw) 둘뿐인데, 보통 챗 모델은 이 질문에 못 답한다고 함.
  11. 반면 클로드 코드에 물으면 포켓몬 전체 목록을 가져와 AW로 끝나는 이름을 걸러내는 스크립트를 짜서 맞힌다고 함.
  12. 이 차이를 능력 과잉(capability overhang, 모델이 이미 가진 능력인데 쓸 도구나 방법이 없어 못 쓰던 부분)이라 부름.
  13. 페이블을 다루는 과제의 상당 부분이 이 능력 과잉을 찾아내는 일—지금 뭐가 가능해졌는지 알아내는 일이라고 함.
  14. 코딩 문제를 풀 때 코드베이스 전체를 컨텍스트 창에 밀어 넣으면 되겠다고 생각하기 쉽지만, 실제로 통한 건 배시(bash) 도구처럼 환경을 직접 다룰 손을 쥐여줘 모델이 스스로 컨텍스트를 찾고 만들게 하는 쪽이었다고 함.
  15. 이 통찰이 클로드 코드를 만든 계기였다고 밝힘.
  16. 최근 내놓은 클로드 태그(Claude Tag, 슬랙 등에서 사람이 부르지 않아도 클로드가 스스로 나서서 함께 쓰는 자리에서 움직이는 기능)는 클로드가 시키지 않아도 먼저 일하는 능력에서 나왔다고 함.
  17. 최근 클로드 코드 시스템 프롬프트의 80%를 걷어냈다고 밝힘.
  18. 소넷(Sonnet) 3.5 뉴(new) 시절엔 시스템 프롬프트를 작게, 도구는 적게, 예시는 많이 주는 게 정석이었다고 함.
  19. 모델이 똑똑해지면서 한동안은 정보와 지시를 더 많이 줘도 잘 따라와, 예시 많고 도구 많은 큰 시스템 프롬프트로 갔다고 함.
  20. 그런데 가장 최근 모델급은 오히려 작은 시스템 프롬프트를 원한다고 함. 예시를 주면 오히려 모델의 상상력을 예시 틀 안에 가둬버린다는 것임.
  21. 그래서 지금은 "이건 하지 마라"는 제약 대신 맥락을 주려 한다고 함.
  22. 애스크어퀘스천(ask you a question) 도구—클로드가 계획을 세우거나 물어볼 게 있을 때 사용자에게 객관식 선택지를 보여주는 기능—도 자신이 클로드 코드에 처음 합류했을 때 만든 것이라고 밝힘.
  23. 오퍼스(Opus) 4 때는 이 도구를 거의 못 불러서 직접 손봐야 겨우 작동했다고 함.
  24. 오퍼스 4.5에 와서는 스펙을 두고 40개 질문으로 면접하듯 물어보라 시켜도 해냈다고 함.
  25. 가장 최근인 오퍼스 4.8과 페이블에 와서는 질문을 아예 담은 HTML 보고서 한 장을 통째로 만들어낸다고 함.
  26. 마크다운(Markdown)과 HTML도 같은 궤적을 그렸다고 함. 처음엔 모델이 내놓기 그럴듯한 출력 형식이었고, 플랜 모드(plan mode, 실행 전에 계획을 먼저 보여주는 기능)가 생기면서 사용자가 클로드의 계획을 알아보는 용도가 됐다고 함.
  27. 지금은 클로드가 깊이 있는 HTML 보고서 자체를 만들어준다고 함.
  28. 이 모든 변화를 물리학보다는 생물학에 가깝다고 표현함. 규칙을 다 알지는 못해도 관찰로 쌓아가는 직관이 있다는 것임.
  29. 안트로픽이 쓴 논문 중 「대형 언어모델의 생물학(the biology of a large language model)」을 가장 좋아한다며 일독을 권함.
  30. 클로드를 언하블링하는 것 못지않게, 페이블을 쓰려면 자기 자신도 언하블링해야 한다고 함.
  31. 그가 자주 떠올리는 말이 지도는 영토가 아니다(the map is not the territory)라는 것임.
  32. 코딩 문제를 풀 때 머릿속 계획·프롬프트·스펙이 지도이고, 실제 코드베이스와 현실의 제약이 영토라고 함.
  33. 클로드가 지도에 없는 영토를 만나는 지점을 언노운(unknown)이라 부르고, 그건 자신이 정해주지 않은 결정 지점이라고 정의함.
  34. 페이블을 쓰면서 처음으로 자기 언노운을 스스로 찾아내야 한다고 느꼈다고 함. 안 그러면 모델이 워낙 넓은 영역을 돌아다녀 언노운을 잔뜩 만난다는 것임.
  35. 지도와 영토를 맞춰 언노운을 찾는 자신의 능력이 페이블을 쓰는 데 병목이라고 함.
  36. 문제를 네 칸으로 나눠 생각한다고 함. 프롬프트에 쓰는 known known(아는 걸 아는 것), 있는 줄은 알지만 아직 못 풀어낸 known unknown, 너무 당연해서 안 적는 unknown known, 아예 고려하지 못한 unknown unknown임.
  37. 다행히 페이블 스스로를 써서 이 언노운들을 찾을 수 있다고 함.
  38. 첫 번째 방법은 블라인드 스폿 패스(blind spot pass)임. 전혀 모르는 새 인증 공급자를 붙인다고 치고, 클로드에게 관련 언노운을 찾아 프롬프트를 더 잘 짜게 도와달라고 시키는 것임.
  39. 이때 깃 디프(Git diff)나 슬랙까지 뒤져 어디에 함정이 있었는지 맥락을 찾아 알려달라고 한다고 함.
  40. 이 방법을 새 분야를 배우는 데도 폭넓게 쓴다며, 최근 영상 편집의 컬러 그레이딩(color grading)을 배울 때도 이렇게 했다고 함.
  41. 두 번째는 브레인스토밍과 프로토타입임. 디자인처럼 말로는 설명 못 해도 보면 아는 unknown known을 찾는 데 쓴다고 함.
  42. 예로 자신은 시각적 취향이 없다고 밝히며, 서로 확 다른 디자인 네 가지로 대시보드 HTML을 만들어 반응해보게 시킨다고 함.
  43. 세 번째는 인터뷰임. 하고 싶은 일의 얼개가 잡히면 클로드에게 자신을 면접하듯 물어보라고 시킨다고 함.
  44. 이때 "구조를 바꿀 만한 질문을 우선하라"처럼 배경 맥락을 더 얹어주면 크게 도움이 된다고 함.
  45. 네 번째는 레퍼런스임. 스펙을 직접 쓰는 대신 원하는 걸 담은 다른 코드를 지도로 건네준다는 것임.
  46. 다른 언어나 시스템으로 짠 코드, 리액트(React) 컴포넌트라면 HTML 목업을 참고 자료로 준다고 함.
  47. 다섯 번째는 구현 노트임. 페이블이 작업 중 언노운을 만나면 그걸 기록해두라고 시켜, 나중에 어디서 계획과 어긋났는지 보고 이유를 되짚는다고 함.
  48. 여섯 번째는 끝나고 나서 페이블에게 무슨 일이 있었는지 자신을 퀴즈로 물어보게 하는 것임. PR을 만들거나 병합하기 전에 자기가 한 일을 제대로 설명할 수 있는지 확인한다고 함.
  49. 이렇게 계속 루프 안에 남아 원하는 걸 실제로 얻는 게 페이블을 쓰는 데 가장 중요한 부분이라고 함.
  50. 자신이 미스릴(Mithril)급이라 부르는 이 새 모델을 처음 써봤을 때, 얻은 것만큼이나 잃은 감각도 컸다고 고백함.
  51. 거대 언어모델(LLM) 이전의 코딩을 돌아보면 딴 나라 얘기 같다며, 30명 규모 YC(와이 콤비네이터) 스타트업을 운영할 때는 코드가 너무 손이 많이 가 늘 트레이드오프에 몰렸다고 함.
  52. 앱을 빠르게 만들거나 새 기능을 시험해보거나 둘 중 하나를 골라야 했고, 한쪽은 한 달, 다른 쪽은 두 달씩 걸렸다고 함.
  53. 몇 주 전 그 코드베이스로 돌아가, 예전 같으면 몇 주 걸렸을 일을 몇 시간 만에 해냈다고 함.
  54. 손으로 코드를 짜며 코드베이스를 머릿속에 그려 돌려보던 감각을 정말 사랑했다고 밝힘.
  55. 동시에 밤새 디버깅하고 몇 주를 매달려도 안 풀리던 기억, 대부분의 프로젝트가 실패했고 대부분의 스타트업이 망한다는 사실도 함께 떠오른다고 함.
  56. 그 높낮이를 다 즐겼어도 이제 되돌아갈 수는 없다며, 빠져나가는 길은 뚫고 지나가는 것뿐이라는 게 자신의 결론이라고 함.
  57. 마지막 장은 무리하게 굴기(being unreasonable)임. 안트로픽 문화에서 가장 좋아하는 믿음이 트레이드오프는 실재하지 않는다는 것이라고 함.
  58. 예전 회사에서는 우선순위 목록을 적어놓고 이것과 저것 중 하나를 고르는 식으로 합리적이었다고 함.
  59. 안트로픽에서는 그 대신 "그냥 다 해버리면 어떨까, 현실이 트레이드오프를 강제로 보여주게 하면 어떨까"를 묻는다고 함.
  60. 앞으로는 스스로 덜 합리적으로 굴겠다는 게 자신의 다짐이라고 밝힘.
  61. 좋음·빠름·저렴함 중 예전엔 둘만 고르라고 했다면, 이제는 셋 다 고르라는 말로 바뀐다고 함.
  62. 에이전트가 실제로 통한다는 걸 증명하는 유일한 길은 그 어느 때보다 빠르게 우리 인생 최고의 결과물을 만드는 것뿐이라고 함.
  63. 예로 이 발표 슬라이드 덱 전체를 전날 밤 페이블로 약 4시간 만에 만들었다며, 결과물도 마음에 든다고 함.
  64. 올해 자신의 다짐은 더 생산적으로 일하되 일하는 시간은 줄여, 정말 아끼는 사람들과 시간을 더 보내는 것이라고 함.
  65. 만들기는 쉬워졌지만 가치를 만들어내는 일은 여전히 어렵다는 점도 짚음. AI 엔지니어들이 빌드 과정과 세팅 자체에만 몰두하기 쉽다고 지적함.
  66. 가치 있는 걸 찾으려면 여러 번 시도하고 여러 번 헛스윙해야 한다는 게 요점이라며, 그게 세상이 AI 엔지니어들에게 증명해 보이라고 요구하는 것이라고 함.
  67. 발표를 나가서 탐험하고, 실제로 만들고, 덜 합리적으로 굴라는 세 마디로 맺음.

한줄 코멘트. 언노운을 찾는 여섯 가지 방법은 바로 써먹을 만큼 구체적인데, 정작 "무리하게 굴기"는 자기 회사 문화 자랑에 가까워 다른 팀에 그대로 옮기긴 어려움.

  1. 발표자는 마들렌 음항가미(Marlene Mhangami)와 리엄 햄프턴(Liam Hampton)이며, 둘 다 마이크로소프트·깃허브(GitHub) 소속으로 VS 코드와 깃허브 코파일럿(GitHub Copilot) 개발자 도구를 맡고 있다고 밝힘.
  2. MCP(모델 컨텍스트 프로토콜, Model Context Protocol)는 애플리케이션이 대형언어모델(LLM)에 컨텍스트를 건네는 방식을 표준화한 개방형 프로토콜이며, 앤트로픽(Anthropic)이 만들었다고 함.
  3. MCP는 호스트·클라이언트·서버 셋으로 나뉘는데, 호스트는 VS 코드처럼 MCP 서버의 데이터에 접근하려는 프로그램이라고 설명함.
  4. 클라이언트는 서버와 1대1 연결을 유지하는 쪽으로, 호스트와 같을 때도 다를 때도 있는데 VS 코드에서는 깃허브 코파일럿을 클라이언트로 쓰길 권장한다고 함.
  5. 서버는 도구(tool)나 프롬프트, 리소스 같은 컨텍스트를 노출하는 가벼운 프로그램으로, 직접 만들 수도 있고 이미 있는 것 중 골라 쓸 수도 있다고 함.
  6. VS 코드 확장 탭에서 "@mcp"를 검색하면 쓸 수 있는 서버 목록이 뜨는데, 인터넷에서 아무 서버나 골라 쓰면 악성 코드가 섞여 있을 수 있어 VS 코드나 깃허브가 정리해둔 목록을 쓰라고 권함.
  7. MCP가 처음 나왔을 때 단점은 서버가 텍스트만 돌려줄 수 있었다는 것으로, "MCP를 설명하는 다이어그램을 그려줘"라고 물어도 그림이 아니라 글로만 답이 왔다고 함.
  8. 그래서 초기 MCP 시절 깃허브 저장소의 README에 아스키 아트(ASCII art)나 이모지가 유난히 많았는데, 다이어그램을 못 그리다 보니 이모지로 과보상한 것 같다고 밝힘.
  9. 그래서 나온 질문이 채팅 안에서 어떻게 풍부한 UI 경험을 만드느냐는 것이고, 이 물음에 대한 답이 바로 MCP 앱(MCP Apps)이라고 함.
  10. MCP 앱은 서버의 도구가 텍스트가 아니라 채팅창 안에 바로 렌더링되는 인터랙티브 컴포넌트를 돌려주게 해주는 확장이라고 설명함.
  11. 앞서 아스키 아트로만 나왔던 같은 질문을 익스칼리드로(Excalidraw) MCP 서버에 물으면, 이번엔 실제로 다이어그램이 그려지고 그 다이어그램을 화면에서 직접 움직이거나 글자를 고칠 수도 있다고 함.
  12. MCP 앱이 도는 순서는 사용자가 "분석 보여줘" 같은 질문을 보내는 데서 시작하고, 에이전트가 어느 도구를 부를지 정한 뒤 MCP 서버에 연결한다고 함.
  13. 서버는 도구 실행 결과와 함께 UI 리소스 참조 하나를 같이 돌려주는데, 이 참조가 서버 쪽에 미리 저장돼 있던 HTML 요소를 가리킨다고 함.
  14. 그다음 호스트(클라이언트인 깃허브 코파일럿이 아니라 VS 코드 자체)가 그 참조를 따라가 HTML을 가져온다고 함.
  15. 호스트는 가져온 HTML을 샌드박스 처리된 아이프레임(iframe, 바깥 페이지와 격리된 하위 화면) 안에 렌더링해서 사용자가 그 안에서 바로 상호작용하게 만든다고 함.
  16. 이후에도 앱은 서버와 계속 주고받으며, 서버가 최신 데이터를 다시 보내면 앱 화면도 그에 맞춰 갱신된다고 함.
  17. 활용 사례로 든 첫째는 데이터 탐색으로, 막대그래프에서 본 추세를 다른 차트의 구체적 수치로 파고들 때마다 매번 새로 타이핑하는 대신 버튼만 눌러 옮겨 다닐 수 있다고 함.
  18. 둘째 사례는 전자상거래로, 예전엔 "온라인에서 살 수 있어?"라고 물으면 링크만 받아 브라우저로 옮겨가야 했지만 MCP 앱은 채팅 안에서 결제까지 끝내는 걸 목표로 한다고 함.
  19. 실제로 MCP 앱을 만들고 있는 회사로 쇼피파이(Shopify)를 꼽으며, 채팅 안 화면도 회사 웹사이트와 같은 브랜드 느낌을 유지하는 데 신경 쓰고 있다는 발표를 들었다고 밝힘.
  20. 익스칼리드로도 아키텍처 다이어그램이나 인터랙티브 다이어그램을 만드는 데 인기가 있고, 클로드 코드(Claude Code)에서도 이 MCP 앱을 쓴다고 함.
  21. 피그마(Figma)도 그때그때 컴포넌트를 만들어내는 MCP 앱을 쓰고 있다는데, 발표자는 화면 캡처는 구하지 못했다고 밝힘.
  22. 이제 리엄 햄프턴이 라이브 데모로 넘어가며, 청중에게 MCP 앱을 이미 써본 적 있는지 물으니 상당수가 손을 들었다고 함.
  23. 리엄은 MCP 앱이 VS 코드처럼 한 컨텍스트 안에 계속 머물면서 상호작용하게 해주는 것이라고 다시 정리함.
  24. 그는 앤트로픽이 모델 컨텍스트 프로토콜 저장소에 올려둔 스킬(skill) 하나를 가져와 조금 고친 뒤 깃허브 코파일럿 CLI로 돌려서 여러 MCP 앱을 만들었다고 밝힘.
  25. 그 저장소에는 플레임 그래프(flame graph, 함수별로 시간이 얼마나 쓰였는지 폭으로 보여주는 성능 그래프) 앱, 마크다운 뷰어, 비행 상태, 색상 선택기 등 여러 예제가 들어있고, 오늘은 플레임 그래프 예제를 보여준다고 함.
  26. MCP 앱은 세 부분으로 나뉘는데, 하나는 도구(LLM 자체와 지금은 호스트인 VS 코드)라고 함.
  27. 둘째는 리소스로, 직접 만들어 넣는 번들 HTML UI를 가리키며 리액트(React)든 뷰(Vue)든 원하는 방식으로 짤 수 있다고 함.
  28. 셋째는 둘을 잇는 링크로, 호스트와 MCP 서버가 실제 데이터 응답과 렌더링할 UI가 서로 연결돼 있음을 알아보게 해주는 부분이라고 함.
  29. 이 UI는 리액트, 순수 자바스크립트, 뷰, 스벨트(Svelte) 등 원하는 방식으로 짤 수 있다고 함.
  30. 리엄이 가져온 스킬은 코파일럿 CLI든 클로드든 어떤 AI 도구를 쓰든 이 프로젝트를 어떻게 세팅하고 돌리는지, 핸들러나 도구 가시성 같은 코드 예시까지 알려준다고 함.
  31. 도구 가시성이란 그 도구를 모델만 부를 수 있는지, 모델과 앱이 같이 부를 수 있는지, 앱만 부를 수 있는지를 정하는 설정이라고 설명함.
  32. 데모 재료는 리엄이 직접 짠 Go 코드로, 배열 값을 서로 비교하는 버블 정렬(코딩 인터뷰에 흔히 나오는 알고리즘)과 앞 항을 계속 더해가는 피보나치 수열(빅오, big-O 예시로 자주 쓰임)이 들어있다고 함.
  33. 이 데모의 목적은 Go 프로그램을 5초 동안 프로파일링해서 시간이 어디서 가장 많이 걸리는지 MCP 서버로 확인하는 것이라고 함.
  34. 프로파일링에는 Go 표준 프로파일러인 pprof를 그대로 쓴다고 함.
  35. MCP 서버는 로컬호스트(localhost)에서 직접 돌아가는 자체 서버이고, 이게 타입스크립트(TypeScript)로 짠 서버 파일을 호출한다고 함.
  36. 이 타입스크립트 파일이 전체 코드에서 가장 중요한 부분으로, Go 프로그램을 번들링하고 실행하고 프로파일링한 뒤 데이터를 뽑아내는 지점이라고 함.
  37. 이 시점에 UI가 MCP 서버와 연결돼 프런트엔드를 렌더링하는데, 리액트 훅(hook)을 쓴 플레임 앱이 도구 입력값과 결과, 시간이 가장 많이 걸린 지점, 플레임 그래프 자체를 받아 보여준다고 함.
  38. 플레임 그래프는 원래 데이터만 보면 뒤죽박죽으로 지저분한데, 이 방식이 프로파일링 결과를 알아보기 좋게 정리해준다고 설명함.
  39. 리엄이 깃허브 코파일럿을 켜고 MCP 서버가 살아있는지 확인하니, 등록된 도구는 "앱 프로파일링" 하나뿐이었다고 함.
  40. 코파일럿에게 프로파일링을 시키자 플레임 그래프 프로파일러가 설치돼 있다는 걸 알아채고 MCP 앱을 스스로 불러왔다고 함.
  41. 잠시 뒤 채팅창 안 아이프레임에 UI가 렌더링됐고, 그 안에서 상위 함수들과 실행 요약을 바로 볼 수 있었다고 함.
  42. 이 화면은 채팅창 크기에 맞게 늘이거나 정리할 수 있다고 함.
  43. 원래는 이런 프로파일링 데이터를 두고 모델에게 "이거 좋은 거야? 나쁜 거야? 시간이 어디서 제일 드는 거야?" 하고 여러 차례 되물어야 했다고 함.
  44. 그런데 아이프레임 안 UI 앱을 쓰면 그 왕복이 없어지고, 필요한 정보가 한 번에 다 눈앞에 있다고 밝힘.
  45. 리엄은 이 전체 흐름을 다시 그림으로 정리하며, "프로그램 프로파일링해줘"라는 요청이 모델로 가고 모델이 도구를 불러야 한다고 판단하는 데서 시작한다고 설명함.
  46. 이어서 MCP 서버가 돌아가 JSON 데이터를 호스트에 넘기고, 호스트가 연결할 리소스가 있음을 알아채 채팅창 아이프레임 안에 렌더링한다고 함.
  47. 아이프레임을 쓰는 이유는 햄스터를 우리에 가두는 것과 같은 이유라며, 방에 풀어놓으면 뭐든 물어뜯듯 이 앱이 VS 코드 설정이나 외부 API를 함부로 건드리지 못하게 막기 위해서라고 설명함.
  48. 그래서 앱은 채팅창 안에만 통째로 격리돼 있어야 한다고 강조함.
  49. 마무리로 깃허브가 부스를 운영 중이라고 안내했고, 마이크로소프트 빌드(Microsoft Build) 행사도 6월 3일에서 6일쯤 코드에 초점을 맞춘 워크숍을 여러 개 연다고 밝힘.

한줄 코멘트. MCP 앱은 프로토콜 확장이라기보다 "서버가 자기 화면까지 들고 온다"는 발상 전환이고, 5초 프로파일링 데모가 그걸 가장 직접적으로 보여줌.

  1. 이 발표는 구글 딥마인드(Google DeepMind)에서 제미나이(Gemini)와 제미나이 API의 에이전트 관련 업무를 맡고 있는 필립 슈미트가 AI 엔지니어 컨퍼런스에서 10분간 한 것으로, 주제는 왜 (특히 시니어) 엔지니어들이 에이전트를 만들 때 자꾸 막히는가임.
  2. 발표자는 구글 안팎에서 이 문제를 매일 본다고 밝히며, 몇 년 전 소프트웨어를 만들던 방식과 지금 에이전트를 만드는 방식이 근본적으로 다른 지점 다섯 가지를 예시로 듦.
  3. 기존 소프트웨어는 명세와 요구사항 문서(PRD, product requirements document)를 쓰고, 코드를 짜고, 테스트를 만들어 동작을 확인한 뒤 배포하면 사용자가 그걸 씀.
  4. 에이전트를 만들 때는 순서가 다름. 에이전트가 할 일을 지시문으로 정의하고, 돌려보고, 무엇을 하는지 관찰하고, 프롬프트나 도구를 손보고, 다시 돌리는 식으로 더 신뢰할 수 있게 만드는 반복 루프를 돎.
  5. 발표자는 이 차이를 교통 통제관과 배차원(dispatcher, 목적지만 정해주고 가는 방법은 맡기는 사람)에 비유함. 기존 소프트웨어에서는 신호등처럼 속도와 경로까지 통제했음.
  6. 에이전트에서는 목적지만 정해주고 기차를 탈지 비행기를 탈지 자동차를 몰지는 에이전트가 정한다는 것임.
  7. 예를 들어 독일에서 런던으로 가고 싶다고만 말하면 기차·비행기·자동차 중 무엇을 쓸지까지는 목표만 정의할 뿐, 정확한 단계는 정해주지 않는다고 함.
  8. 코딩 에이전트를 써본 사람이라면 다들 봤듯 에이전트가 이상한 방식으로 움직이다가도 결국 목표를 달성하는데, 그게 바로 이 방식이 지향하는 결과라고 함.
  9. 첫 번째 차이는 텍스트가 새로운 상태(state)가 됐다는 것임. 예전엔 데이터 구조가 있었고 모든 것이 불리언(boolean, 참·거짓 값)이나 확인 가능한 플래그로 매핑됐음.
  10. 예를 들어 딥리서치(deep research, 여러 단계로 스스로 조사해 보고서를 만드는 에이전트) 기능을 처음 만들었을 때, 에이전트는 "이걸 조사하겠다"는 계획을 텍스트로 돌려줌.
  11. 기존 소프트웨어라면 정해진 계획을 그대로 승인하거나 거부하는 정도였지 의미 자체를 이해하지는 못했는데, 이제 LLM(거대언어모델)은 그 의미를 이해할 수 있다는 것임.
  12. 그래서 시장 조사를 요청할 때 처음 나온 계획을 승인하면서 동시에 "미국 시장에 집중하고 캘리포니아는 빼 달라" 같은 추가 정보를 한 번에 줄 수 있음.
  13. 기존이었다면 일단 계획을 거부하고, 후속 요청으로 추가 입력을 받아 새 계획을 다시 만드는 여러 단계를 거쳐야 했을 일이라고 함.
  14. 기억과 개인화도 데이터 구조로 잘 매핑되지 않는 영역이라고 함. 발표자는 유럽 출신이라 평소엔 섭씨를 쓰지만 요리할 때는 화씨를 쓰고 싶어할 수 있다는 예를 듦.
  15. 예전에는 사용자 프로필에 "섭씨 쓰는 유럽 사용자" 같은 플래그를 뒀겠지만, 사용자가 그때그때 알려주는 선호에 맞춰 동적으로 조정하지는 못했다는 것임.
  16. 결국 지금은 텍스트와 맥락(context)이 전부이고, 이미지·영상·음성도 포함되지만 더 이상 명확히 구조화된 데이터 개념 안에서 작동하지 않는다는 것임.
  17. 두 번째 차이는 통제권을 넘겨줘야 한다는 것임. 발표자는 기존 고객지원에서 빠지기 쉬운 함정을 예로 듦.
  18. 사용자가 "구독을 취소하고 싶다"고 하면, 분류 모델이 의도를 "이탈하려 한다"로 분류하고 정해진 워크플로에 따라 할인 제안을 해볼지 그냥 취소해줄지를 진행함.
  19. 여기엔 상황에 맞춰 동적으로 반응할 옵션이 없었다는 것임.
  20. 대신 에이전트가 취소 절차를 그대로 따라가는 대신 사용자 의도의 의미를 이해하려 하고 다른 제안을 하면, 사용자가 마음을 바꿔 완전히 다른 의도로 넘어갈 수도 있음.
  21. 이런 차이와 고유함을 전부 예전 방식의 상태 기반(stateful) 워크플로로 모델링하기는 매우 어려움. 그래서 LLM을 신뢰하고 통제권을 넘겨야 한다는 것임.
  22. 이제는 순수하게 결정론적인 환경에서 일하지 않는다는 뜻이라고 함.
  23. 세 번째 차이는 오류도 그냥 입력값이라는 것임. 에이전트 흐름 어딘가에서 뭔가 실패하면 그걸 사용자 입력과 비슷한 정상 입력으로 취급해야 함.
  24. 발표자는 Go 언어를 예로 듦. Go에서는 함수 호출이 오류일 수도 값일 수도 있고 둘을 거의 동등하게 다루는데, 에이전트에서도 비슷하게 해야 한다는 것임.
  25. 예전에는 HTTP 요청이 워낙 싸서, 상품 검색 하나가 실패하면 그냥 요청을 다시 보내 처음부터 다시 하면 됐음.
  26. 그런데 지금은 에이전트 하나가 5분, 15분씩 걸리는데, 흐름 중간에 뭔가 깨지면 처음부터 다시 시작해야 함.
  27. 그러면 이전 단계를 다시 도느라 컴퓨팅을 또 써야 하고, 기존 맥락도 잃을 수 있다는 것임.
  28. 그래서 전체 과정을 처음부터 다시 시작할 수는 없고, 오류를 모델에 다시 돌려주거나 다른 우회 방법과 추가 점검을 둬서 흐름을 계속 앞으로 밀고 나가야 함.
  29. 네 번째 차이는 단위 테스트에서 이밸(eval, 얼마나 자주 성공하는지를 반복 측정하는 평가)로 옮겨가야 한다는 것임.
  30. 기존 소프트웨어에서는 통합 테스트·단위 테스트·스모크 테스트를 쓰며 입력 A를 코드 B에 넣으면 항상 출력 C가 나온다고 가정했음.
  31. 에이전트는 더 이상 그렇지 않은데, 비결정적(non-deterministic)이라 같은 입력이 항상 같은 단계와 같은 결과로 이어진다고 보장할 수 없기 때문임.
  32. 그래서 단위 테스트 대신 이밸로 옮겨가 무언가가 얼마나 자주 성공하는지를 시험해야 함. 에이전트는 정말로 신뢰할 수 있어야만 성공했다고 할 수 있기 때문임.
  33. 예를 들어 고객 상담 에이전트가 있는데 같은 프롬프트가 10번 중 1번만 통한다면, 그건 실제로 프로덕션에 올릴 수 있는 것이 아니고 매우 불안정(flaky)한 상태라고 함.
  34. 기존 소프트웨어와 달리 결과가 매우 주관적이라는 점도 다름. 리서치 보고서를 만들라고 할 때와 고객 피드백 시나리오를 만들라고 할 때 결과물의 성격 자체가 다름.
  35. 그래서 더 정성적인 피드백이 필요하고, LLM을 심사자로 쓰거나 사람 전문가가 평가하는 방식이 좋은 방법이라고 함.
  36. 에이전트가 무엇을 하는지 항상 추적은 하되, 평가는 결과물 기준으로 해야 함.
  37. 어떤 사용자에게는 조사를 네 단계 더 하기로 결정할 수도 있고 토큰을 좀 더 쓸 수도 있지만, 결국 측정하고 싶은 건 결과물의 성공 여부라는 것임.
  38. 다섯 번째 차이는 에이전트는 진화하는데 API는 그대로라는 것임.
  39. 백엔드나 API를 만들어본 사람이라면 "아이템 삭제(delete item)"처럼 사람이 보기엔 매우 자명한 메서드나 엔드포인트를 많이 봤을 것임.
  40. 하지만 에이전트는 코드를 보지 못하고, 그 API를 오래 다뤄온 사람이 가진 맥락과 배경지식도 없음.
  41. 그래서 에이전트가 쓰기에 정말 준비된, 스스로 설명하는(self-documenting) 의미 있는 인터페이스를 갖춘 API나 도구를 만들어야 한다는 것임.
  42. 상품 마이크로서비스에 ID를 받는 삭제 엔드포인트가 있다면, 사람 개발자에게는 그 ID가 뭔지 실패하면 뭐가 일어나는지 굳이 문서로 설명할 필요가 없다고 여길 수 있음.
  43. 하지만 에이전트는 함수 스키마와 문서 문자열(doc string, 함수가 뭘 하는지 설명해두는 주석), 도구 정의만 보기 때문에 얼핏 봐서는 그 삭제 메서드가 뭘 하는지 알 수 없음.
  44. 그래서 오래 개발해온 사람의 전문성을 전제하지 않고 에이전트가 쓰도록 쓰인 메서드와 도구가 필요하다고 강조함.
  45. 발표를 정리하며 발표자는 신뢰하되 검증하라(trust but verify)는 원칙을 제시함.
  46. 모델과 싸우는 걸 멈춰야 함. "1단계는 이거, 2단계는 저거" 식으로 하나의 정해진 워크플로에 모델을 억지로 밀어넣으려 하지 말아야 한다는 것임.
  47. 의미를 보존해야 함. 이제 모든 것이 맥락이고, 예전처럼 모든 애플리케이션에 잘 정의된 데이터 구조가 있는 게 아니라는 것임.
  48. 복구를 염두에 두고 설계해야 함. 모델도 에이전트도 완벽하지 않고, 특히 오래 도는 에이전트일수록 아주 이상한 일이 벌어질 수 있다고 함.
  49. 평가하되 단정만 하지는 말아야 함. 에이전트는 100% 신뢰할 수 없으므로, 몇 번이나 성공해야 사용자에게 내보낼 수 있는지 적절한 균형점을 찾아야 함.
  50. 마지막으로 「지우기 위해 만든다(build to delete)」는 원칙을 듦. 소프트웨어는 소모품이고, 더 나은 모델과 에이전트가 나올 때마다 같은 것을 몇 번이고 다시 만들게 될 것이라고 함.
  51. 이 표현은 쓴 교훈(bitter lesson, 정교한 인간 설계보다 더 많은 데이터와 연산을 쓰는 단순한 방법이 결국 이긴다는 경험칙)을 빗대어 쓴 것임.
  52. 발표자는 이 내용을 자기 블로그에도 코드 예시와 함께 더 자세히 올려뒀다고 밝히며 발표를 마침.

한줄 코멘트. 다섯 갈래 다 결국 하나로 모이는데, 결정론적 코드에 익숙한 손이 비결정적인 것을 계속 정해진 워크플로로 눌러 담으려 하는 게 시니어가 막히는 지점이라 보임.

  1. 발표자는 매기 애플턴(Maggie Appleton)으로, 깃허브(GitHub) 랩스(Labs) 팀 소속 스태프 리서치 엔지니어라고 밝힘. 랩스 팀은 다른 팀보다 더 실험적이고 위험한 시도를 맡아 스스로 "이거저거 해보고 알아내는 부서"라 부른다고 함.
  2. 발표 제목은 "한 사람, 에이전트 스물넷, 정렬 없음"으로, 협업하는 AI 엔지니어링이 왜 필요한지를 다룬다고 함.
  3. 요즘 많은 사람이 떠올리는 최고 생산성의 모습은 터미널 기반 코딩 에이전트 여러 개가 한 사람 컴퓨터에서 동시에 돌아가는 벽 화면이라고 지적함.
  4. 이걸 "한 사람과 스물네 개 클로드(Clod, 클로드를 장난스럽게 부르는 말)"라는 미래상이라 이름 붙이고, 한 사람이 에이전트 함대로 팀 전체 일을 해낸다는 약속이 깔려 있다고 함.
  5. 이 그림의 근본 문제는 소프트웨어가 한 사람이 만든다는 전제에 있다고 지적함. 지금 나온 에이전트 도구는 전부 혼자 쓰는 인터페이스라 개인 한 명의 작업량을 키우는 데만 초점을 맞춘다고 함.
  6. 소프트웨어는 진공 속 한 사람이 아니라 팀이 만드는 것이라, 무엇을 왜 만드는지 모두가 합의해야 한다고 함.
  7. 개인 생산성이 좋은 소프트웨어로 이어진다는 믿음은 "여자 아홉 명이 한 달 만에 아기를 낳는다"는 논리와 같다고 함. 개인 산출량을 늘리는 건 소통과 조율이 필요한 문제를 오히려 더 나쁘게 만든다고 함.
  8. 구현(코드를 실제로 짜는 일)은 이제 거의 풀린 문제가 됐고, 코드를 쓰는 속도는 빨라지고 비용은 내려가고 품질은 계속 올라간다고 함.
  9. 어려운 질문은 더 이상 "어떻게 만들 것인가"가 아니라 "만들어야 하는가"라고 함. 무엇을 만들지 합의하는 일이 새로운 병목이 됐다고 함.
  10. 팀 전원이 옳은 것을 만들고 있는지, 에너지를 제대로 쓰고 있는지 계속 물어야 한다고 함. 생산이 저렴해지면 기회비용이 진짜 비용이 되고, 무엇을 고르든 나머지를 포기하는 대가가 따른다고 함.
  11. 팀으로 소프트웨어를 출시해본 사람이라면 정렬(팀이 같은 방향을 보는 것) 문제가 새삼스럽지 않다는 걸 안다고 함. 다만 에이전트 때문에 정렬되지 않았을 때 치르는 대가가 훨씬 커졌다고 함.
  12. 문제를 더 키우는 건 깃허브·슬랙(Slack)·지라(Jira)·리니어(Linear) 같은 협업 도구가 전부 다른 시대에 설계됐다는 점이라고 함. 방대한 에이전트 산출물을 옛날 방식에 맞춘 플랫폼에 억지로 밀어 넣고 있다고 지적함.
  13. 자신이 깃허브 소속이라 이상하게 들릴 수 있지만, 사내에서도 PR(코드 변경 요청)과 이슈가 소프트웨어 개발의 미래라고 믿는 사람은 거의 없다고 밝힘.
  14. 예전 개발 과정은 기획·구현·리뷰 단계마다 정렬을 확인하는 접점이 여러 번 있었다고 설명함. 속도가 느렸던 덕분에 슬랙 대화나 줌(Zoom) 회의, 이슈·초안 PR 댓글로 세부 사항을 논의할 시간이 있었다고 함.
  15. 팀원 각자 의견을 내고 선배의 경험을 빌리고 실수를 미리 잡아 방향을 고칠 수 있었고, 코드가 머지될 즈음이면 팀 전체가 진행 상황을 대략 파악하고 있었다고 함.
  16. 그런데 구현 단계가 걸리던 시간이 확 줄었다고 함. 더 이상 비싸고 오래 걸리지 않으니 계획을 예전만큼 세밀히 세우지 않아도 된다고 착각하게 됐고, 초기 정렬 접점 대부분이 사라졌다고 함.
  17. 반면 생성된 코드의 리뷰 시간은 오히려 늘어나, 정렬 지점이 구현 뒤쪽으로 더 많이 몰리게 됐다고 함. 이슈를 등록하고 에이전트가 PR을 여는 데 걸리는 시간이 이제 몇 분밖에 안 돼, 프롬프트를 넣기 전 충분히 생각하지 못한다고 함.
  18. 대부분 코딩 에이전트에 있는 로컬 계획 모드는 다른 사람과 전혀 공유되지 않아, 팀원이 그 계획을 검토할 기회조차 없이 출시된다고 함.
  19. 결국 모든 정렬 부담이 PR 하나에 쏠리는데, PR은 원래 그런 용도로 설계된 적이 없어 그 역할을 잘 해내지 못한다고 지적함. 지금 도구 중 어느 것도 팀이 계획을 논의하고 에이전트와 함께 일할 공유 공간을 주지 못한다고 함.
  20. 정렬 없이 빠르게만 가면 아무도 요청하지 않은 기능을 만들거나, 일을 다 끝낸 뒤 비판적인 피드백을 받아 통째로 갈아엎어야 하는 일이 생긴다고 함.
  21. 여러 에이전트가 같은 파일을 건드려 지독한 머지 충돌이 나거나, 개발자 둘이 같은 작업을 하루 만에 각자 끝내려다 중복 작업을 하는 조율 부채도 쌓인다고 함. 아무도 맥락을 모르는 PR 더미가 쌓인다고 함.
  22. 해법은 에이전트가 일을 시작하기 전에 팀 전체가 정렬하도록 돕는 도구이지, 시작한 뒤에 정렬하는 도구가 아니라고 함.
  23. 정렬은 구현과 나란히 계속 일어나야 하고, 기획과 구현은 더 이상 분리된 단계가 아니라 하나의 순환이 됐다고 함. 앞으로의 도구는 기획·맥락 수집·의사결정·개발을 한 지붕 아래 묶어야 한다고 함.
  24. 정렬에 필요한 맥락 대부분은 코드베이스에 있지 않고 사람들 머릿속에 있기 때문에 더욱 그렇다고 함.
  25. 사업 맥락과 자금 여력, 누가 결정권을 쥐는지의 정치적 역학, 리더의 제품 비전, 디자이너의 사용자 조사, 조직이 과거에 무엇을 만들었는지가 다 여기에 들어간다고 함.
  26. 이런 맥락은 에이전트가 스스로 알아낼 수 없으니, 사람이 부담을 더하지 않고 자연스럽게 일찍 공유할 방법이 필요하다고 함.
  27. 깃허브 넥스트(GitHub Next) 팀이 이 문제를 풀어보려고 만든 리서치 프로토타입이 에이스(ACE, Agent Collaboration Environment)라고 소개함.
  28. 아직 정식 제품이 아니라 다듬어지지 않은 부분이 많다고 밝히고, 곧 기술 프리뷰로 넘어가 수천 명을 대상으로 시험한 뒤 사용 패턴을 배워 반복 개선할 계획이라고 함.
  29. 에이스 화면은 슬랙과 깃허브, 코파일럿(Copilot), 클라우드 컴퓨터를 섞어놓은 듯한 모습이라고 함.
  30. 왼쪽 세션 목록에서 작업이 이뤄지는데, 각 세션은 슬랙 채널처럼 팀원과 코딩 에이전트가 함께 있는 멀티플레이어 채팅이라고 함.
  31. 세션마다 마이크로 VM(클라우드에 떠 있는 격리된 가상 컴퓨터)이 붙어 있고, 각자 자기 깃(Git) 브랜치 위에서 돌아간다고 함. 세션별로 변경이 격리돼 있어 여러 작업을 병렬로 하다 즉시 다른 세션으로 옮겨갈 수 있다고 함.
  32. 팀원의 작업을 잠깐 들여다보고 싶을 때 깃 변경을 스태시하거나 새 브랜치를 받을 필요 없이, 그 세션에 클릭 한 번으로 들어가 프롬프트 기록까지 전부 볼 수 있다고 함.
  33. 로컬 컴퓨터처럼 세션 안에서 터미널 명령을 바로 실행할 수 있어, 데모에서는 bun install과 bun dev로 프로젝트를 띄웠다고 함. 데모 프로젝트는 최근 석 달 상위 이야기 세 개만 보여주는 차분한 버전의 해커뉴스(Hacker News) 클론이라고 함.
  34. 에이전트에게 색상 테마를 보라색으로 바꿔달라고 요청하자 바로 옆 미리보기 화면에 즉시 반영되는 걸 보여줌. 에이전트가 자동으로 커밋 메시지까지 붙여 커밋했고, 그 자리에서 diff(변경 내역)를 열어 확인할 수 있었다고 함.
  35. 실제 작업 예시로 에이스에게 색상 테마를 추가로 만들어 달라고 요청하며 모델은 오퍼스(Opus) 4.6을 골랐다고 함.
  36. 화면 오른쪽 위 요약 블록이 이 세션에서 자신이든 다른 사람이든 최근 변경 내역을 계속 알려줘, 여러 사람의 병렬 세션을 오가면서도 소음에 압도되지 않고 상황을 파악할 수 있다고 함.
  37. 팀원 네이트(Nate)와 던(Dawn)이 세션에 들어와 스크린샷을 찍고 다른 기능을 제안하며 질문을 던지는 모습을 보여줌. 다들 같은 클라우드 컴퓨터 위에 있으니 각자 개발 서버를 띄워도 문제없다고 함.
  38. 네이트가 직접 에이스 에이전트에게 청록색 테마도 추가해달라고 프롬프트를 넣는데, 발표자가 세션을 시작했어도 이렇게 진짜 멀티플레이어로 함께 쓸 수 있다고 함.
  39. 에이전트는 대화 전체를 입력으로 읽기 때문에, 미리 논의해두고 나중에 "에이스, 해줘"라고만 말해도 실행한다고 함.
  40. 이런 슬랙 같은 접근성은 개발자뿐 아니라 디자이너·PM·고객지원 담당자까지 같은 대화에 들어와 기능이 만들어지는 과정을 실시간으로 보게 해준다고 함.
  41. 왜 그냥 슬랙을 쓰지 않느냐는 질문에는, 슬랙이 사업 방향을 완전히 바꾸지 않는 한 diff나 터미널 명령 같은 소프트웨어 개발 전용 기능을 갖추지 않을 것이기 때문이라고 답함.
  42. 에이스는 소프트웨어 개발용으로 설계됐으면서도 터미널보다 다른 팀원을 훨씬 더 반갑게 받아준다고 함.
  43. 작업이 마음에 들면 에이스 안에서 바로 PR을 만들 수 있고, 코드는 결국 깃허브로 돌아가야 하니 PR에는 에이스 세션으로 돌아가는 링크가 함께 달린다고 함.
  44. 팀원 전체가 에이스에 있을 필요는 없고, 일부만 에이스를 쓰고 나머지는 원래 쓰던 도구에 남아도 된다고 함.
  45. CSS(화면 스타일을 짜는 언어)처럼 에이전트가 원하는 대로 못 하는 부분은 여전히 사람이 직접 코드를 만져야 해서, 같은 마이크로 VM 위에서 VS Code로 실시간 공동 편집을 한다고 함.
  46. 노트북을 닫아도 세션이 죽지 않고 팀원이 계속 프롬프트를 넣으며 작업을 이어갈 수 있다고 함.
  47. 모바일 인터페이스는 아직 없지만 만드는 중이고, 마이크로 VM 구조 덕분에 휴대폰으로 터미널에 SSH 접속할 필요 없이 매끄럽게 작동할 것이라고 함.
  48. 크고 복잡한 기능을 만들 때는 에이전트에게 먼저 계획을 쓰게 하는 게 표준적인 작업 방식이라고 함.
  49. 계획 문서는 팀원 커서(마우스 커서)가 함께 보이는 채로 다 같이 편집하며, 그 계획이 의도를 제대로 달성하는지 판단한다고 함.
  50. 네이트는 세그먼트 컨트롤 대신 드롭다운을 쓰자고 제안하고 이던(Edon)은 요구사항을 직접 고쳐 넣어, 에이전트가 다음에 그렇게 하도록 만든다고 함.
  51. 세부 사항에 다 같이 만족하면 채팅으로 돌아가 "에이스, 이거 해줘"라고만 말해도 이미 맥락을 알고 있다고 함.
  52. 대시보드로 넘어가면, 원래 슬랙·깃허브·리니어에서 벌어지던 기획·논의 상당 부분이 이제 에이스 세션 안에서 일어나고 있어 진행 중인 작업을 요약해 보여준다고 함.
  53. 월요일 아침 지난 금요일에 뭘 하다 멈췄는지 기억이 안 날 때, 에이스가 진행하던 리액트 훅(React hooks) 리팩터링을 계속하라고 알려준다고 함.
  54. 이어하기 섹션에서 클릭 한 번으로 머지되지 않은 PR 세션을 다시 열 수 있고, 최근 완료한 PR과 이슈 목록도 볼 수 있다고 함.
  55. 화면 오른쪽 팀 전체 섹션은 동료들이 최근 며칠 무엇을 했는지 요약해, 네이트가 로비 채널을 출시했고 데이비드가 접근 토큰 문제를 고쳤다는 걸 알 수 있다고 함. 원본 이슈·PR 피드도 있지만 요약 쪽이 훨씬 도움이 된다고 함.
  56. 에이전트 개발 시대의 가장 큰 어려움 하나는 작업 속도와 양이 너무 커서 동료가 뭘 하고 있는지 따라가기 힘들다는 점이라고 함. 팀이 예전엔 하루 반 개꼴로 기능을 냈다면 지금은 하루 다섯 개를 출시한다고 함.
  57. 이 대시보드는 에이전트를 능동적으로 만들어 그런 사회적 맥락을 사용자에게 가져다주려는 첫 시도라고 함.
  58. 코드를 둘러싼 모든 대화를 에이전트가 볼 수 있으면, 매일 아침 방향을 잡아주고 팀과 계속 정렬되게 도와주는 사회적 정보망 역할을 할 수 있다고 함. 의사결정 소식을 알려주거나, 누군가 자신이 만든 기능을 확장할 때 그 대화로 끌어들여줄 수도 있다고 함.
  59. 이제는 개별 컴퓨터에서 따로따로 돌아가는 터미널 인스턴스 여러 개가 아니라, 모두가 같은 작업 공간과 맥락을 공유하는 살아있는 지능형 환경이 된다고 함.
  60. 이 모든 이야기는 결국 시간을 되찾는 문제라고 함. 코딩 에이전트가 나오기 전에는 아무도 제품을 원하는 방식으로 만들 시간과 에너지가 충분하지 않았다고 함.
  61. 이 자리에 있는 모든 사람이 자랑스럽지 않은 소프트웨어를 출시해본 적이 있을 것이라고 함. 사용자 조사나 설계 디테일, 아키텍처 선택의 함의를 충분히 고민할 시간이 없어서였다고 함.
  62. 이제 그 시간을 상당 부분 돌려받았고, 더 빨리 만들어 똑같이 조잡한 소프트웨어 더미를 쌓는 대신 더 엄격한 사고와 더 나은 정렬로 훨씬 좋은 소프트웨어를 만들 기회가 생겼다고 함.
  63. 예전보다 더 깊이 탐구하고 조사하고 문제를 고민할 여유가 생겼고, 제대로 하면 에이전트가 개인과 팀 모두를 확장시켜 더 좋은 품질의 소프트웨어로 이어질 것이라고 함.
  64. 빠르고 저렴한 소프트웨어의 시대에는 품질이 새로운 차별점이 되고, 기준선이 훨씬 높아져서 장인정신이 바이브 코딩(vibe coding, 감으로 프롬프트만 던져 코드를 뽑는 방식)으로 나온 잡동사니와 구분지어 줄 것이라고 함.
  65. 다만 장인정신도 시간과 에너지가 든다고, 그 시간을 벌려면 더 적은 것을 더 잘 만들어야 하고 그러려면 강한 정렬이 필요하다고 함. 예전보다 주의를 뺏는 것도 많아져 불필요한 기능을 잔뜩 붙이기 쉬워졌다고 함.
  66. 꿈은 에이스든 다른 도구든, 팀이 어려운 문제를 함께 엄격하게 고민할 수 있는 환경을 만드는 것이라고 밝힘. 에이전트 도구는 조잡한 것 천 개 대신 뛰어난 것 몇 개를 만들게 해야 한다고 마무리함.
  67. 에이스 얼리 액세스는 몇 달 안에 나올 예정이고, QR코드로 깃허브 사용자명을 등록하면 출시 즉시 접근권을 준다고 밝힘.

한줄 코멘트. 도구가 늘려주는 건 개인 산출량인데 팀이 막힌 자리는 합의라서, ACE가 진짜 푸는지는 결국 사람들이 계획 문서에 커서를 몇 개나 띄우느냐로 갈릴 것 같음.

  1. 발표자는 구글 딥마인드 개발자 관계 엔지니어 이언 밸런타인(Ian Ballantyne)과 AI 플랫폼 팀 소프트웨어 엔지니어 KP 소니(KP Sawhney)임. 딥마인드가 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 소프트웨어를 어떻게 만드는지 이야기하는 패널이라고 밝힘.
  2. 발표 시작에 청중에게 안티그래비티(Antigravity)를 써 본 적 있는지 손을 들게 했더니 4~5명 정도만 손을 들었다고 함.
  3. 안티그래비티는 비주얼 스튜디오 스타일의 인터페이스로 많이 알려져 있지만, 그 뒤에 여러 에이전트를 동시에 띄우고 관리하는 에이전트 매니저 프레임워크가 따로 있다고 설명함.
  4. 이 프레임워크는 서로 다른 프로젝트에서 여러 에이전트를 동시에 스폰(spawn, 새로 띄움)해서 돌릴 수 있고, IDE(통합 개발 환경)에 통합돼 있으면서도 그 자체로 하나의 에이전트 플랫폼이라고 함.
  5. 시연에서는 프로젝트를 하나 열어 옆의 채팅창에 스펙(spec, 만들 것을 정리한 설계 문서) 파일을 지정해 "이 스펙대로 예시를 만들어라"라고 시키는 방식으로 작업을 넘김.
  6. 와이파이가 안 잡히면 자체 모델 대신 제미나이(Gemini) 모델을 쓰라고 덧붙이면서 이건 자기 광고라고 농담함.
  7. 모델은 스펙을 분석하고 자체 내부 도구들을 써서 어떻게 만들지 정한 뒤, 이미 만들어져 있던 파일을 발견하면 "이미 다 됐다"고 알려주기도 한다고 함.
  8. 도구 안에는 할 일 목록과 계획 시스템이 내장돼 있고, 작업 중 브라우저를 직접 띄워 만든 애플리케이션이 실제로 돌아가는지 확인함. 이 브라우저도 안티그래비티가 직접 조작한다고 함.
  9. 안티그래비티는 페이지의 문서 객체 모델(DOM)을 직접 들여다보고 그 정보를 다시 작업에 반영할 수 있다고 함. 작업을 마치면 무엇을 했는지 보고서를 주고, 스크린샷이나 영상도 남긴다고 함.
  10. 시연에서는 기존에 다른 모델이 만들어 둔 게임 파일을 완전히 새로 처음부터 다시 짜는 과정을 보여줌. 화면 가장자리의 파란 테두리가 안티그래비티가 브라우저를 조작 중이라는 표시라고 설명함.
  11. 작업 중 남기는 스크래치패드(scratchpad, 작업하며 남기는 메모장)를 통해 에이전트가 어떤 동작을 시도하고 있는지 트레이스(작업 과정 기록)로 확인할 수 있다고 함.
  12. 실행 전에 사람이 계획을 보고 줄 단위로 고쳐 "이 동작 말고 다르게 해달라"고 개입할 수 있는 휴먼 인 더 루프(human in the loop, 자동화 과정에 사람이 검토·개입하는 단계) 구조라고 밝힘.
  13. 이언은 몇 달 전까지 딥 리서치(deep research) 에이전트를 만드는 일을 했고, 이 기능은 지금 인터랙션스(Interactions) API로 제공되고 있다고 밝힘.
  14. 지금은 초점을 안티그래비티 하네스(harness, 에이전트가 도구를 쓰고 작업을 진행하도록 감싸는 실행 틀) 내부 활용도를 높이는 쪽으로 옮겼다고 함.
  15. 구글은 거대한 모노레포(하나의 저장소에 전체 코드를 모아 두는 방식) 하나로 코드를 관리해 복잡도가 크다고 설명함.
  16. 딥 리서치처럼 검색 결과로 나온 큰 텍스트 덩어리를 그대로 주고받는 대신, 파이프라인의 여러 부분이 공유 파일시스템에서 서로 협업하는 구조로 일반화하는 걸 구상 중이라고 밝힘.
  17. 구글·딥마인드 내부에서는 직원의 업무를 돕는 스킬(skill, 특정 작업을 해내도록 미리 정의해 둔 지침·도구 묶음)을 대규모로 쌓아 왔다고 함.
  18. 몇 달 뒤 IO(구글의 연례 개발자 콘퍼런스) 시점에는 더 자세히 알게 될 만한 일들도 진행 중이지만 지금은 자세히 말할 수 없다고 함.
  19. 구글 정도 규모의 조직에서는 스킬이 통제 불능으로 퍼질 위험이 있어서, 지금은 좋은 스킬만 살아남도록 다듬는 것 자체가 큰 초점이라고 함. 이언은 이를 "거의 다윈주의적"이라고 표현함.
  20. 딥 리서치 같은 기능을 제미나이 앱 안의 기능으로 두는 것과 구글 전체 임직원이 쓰게 하는 것은 완전히 다른 규모의 문제라고 짚음.
  21. KP는 지금 가장 신경 쓰는 문제가 이 작업이 토큰(모델이 텍스트를 처리하는 최소 단위)을 얼마나 많이 먹는지이고, 사용자·팀 단위로 몫(quota, 정해진 사용 한도)을 관리하는 게 중요하다고 함.
  22. 앞으로는 제미마(Gemma) 4처럼 자신이 가진 GPU·TPU(구글이 만든 AI 연산 전용 칩)만 쓰면 사실상 몫에서 자유로운 모델과, 특정 구간에만 쓰는 더 비싼 고성능 모델을 섞어 쓰는 방향이 흥미로울 거라고 봄.
  23. 복잡한 워크플로가 성공했는지 평가하는 일과 그 비용을 낮추는 일도 큰 초점이라고 함.
  24. 실제 TPU 시간을 쓰지 않고 하네스와 에이전트 흐름 자체를 테스트하려고 목(mock, 실제 대신 흉내만 내는 가짜) TPU 같은 걸 살펴보고 있다고 밝힘.
  25. 발표 중 청중에게 손을 들게 해 직접 에이전트 하네스를 만들고 있는지 물어보는 시간을 가짐. 상당수가 손을 들었다고 함.
  26. 이어서 기성 하네스를 쓰는지 직접 만든 것을 쓰는지, 어느 규모의 사용자를 목표로 하는지도 함께 물어봄.
  27. 한 사용자가 여러 인스턴스(instance, 동시에 띄운 실행 단위)를 스폰해 시스템 전체를 먹통으로 만드는 걸 어떻게 막는지 질문이 나옴. 파워 유저가 100명짜리 팀처럼 에이전트 100개를 동시에 돌리는 상황을 예로 듦.
  28. KP는 솔직히 지금은 몫으로 거칠게 막는 수준이라고 인정함. 딥마인드 안에도 실제 파워 유저들이 있고, 결국 "지금 당장 멈추라"고 해야 하는 지점이 온다고 밝힘.
  29. 이 문제는 앞으로 이런 서비스를 어떻게 가격 매길지와도 이어진다고 봄. 앤스로픽(Anthropic)이 '오픈 클로(open claw)'라고 불린 걸 막았다는 사례를 언급함.
  30. 에이전트 시스템이 토큰을 너무 많이 먹어서 구독제 모델 자체가 이런 사용 패턴에는 안 맞기 시작했다는 게 KP의 지적임.
  31. 이언은 입사할 때 데이터센터 자원을 얼마나 쓰면 "너무 많이" 쓰는 건지 궁금했는데, 한 동료가 "그들이 알려줄 것"이라고 답했다고 함.
  32. 실제로 SRE(사이트 신뢰성 엔지니어) 팀이 24시간 스파이크와 그래프를 지켜보다가 특정 클러스터에서 도는 작업을 멈춰달라고 직접 연락해 온다고 밝힘.
  33. 관측 도구는 구글 내부에서 여러 서비스가 함께 쓰는 에이전트 백엔드 시스템에 맞춰 자체 제작한 웹 앱이라고 함.
  34. 사용자가 에이전트에 질의를 보내면 자동으로 이 UI에 잡히고, 계층을 타고 내려가 모델에 보낸 원시 예측(predict) 요청까지 들여다볼 수 있다고 설명함.
  35. 코딩 쪽에는 별도로 에이전트 트랜잭토리 스토어(agent trajectory store, 에이전트가 밟은 단계를 저장해 두는 저장소)가 있어서, 어느 지점에서 루프에 빠졌는지, 어디서 모델이 궤도를 벗어났는지 되짚어 진단하는 데 쓴다고 함.
  36. 딥 리서치를 안티그래비티와 같은 하네스로 오케스트레이션(여러 구성요소의 작업 순서와 협업을 조율하는 것)하면 더 빠르고 싸고 결과도 나아질 거라고 기대한다고 밝힘.
  37. 지금 딥 리서치 시스템은 엄청난 양의 맥락(context, 모델이 참고하는 대화·문서 내용)이 파이프라인 전체를 그대로 통과하면서 비용이 커지는 구조라고 함.
  38. 그래서 이 시스템의 각 구성요소를 사람들이 함께 깊이 조사할 때처럼 공유 워크스페이스 속 협업자로 만들려 한다고 함.
  39. 이렇게 되면 인포그래픽이나 근거 자료·문서 같은 부산물도 자연스럽게 나올 여지가 있다고 봄.
  40. 안티그래비티의 서브 에이전트가 어떻게 작동하는지 묻는 질문에 이언은 세부 사항까지는 잘 모른다고 솔직히 답함.
  41. 여러 트랙을 동시에 진행할 수는 있지만, 완전히 병렬로 돌아가는 시스템은 아니고 각 에이전트가 특정 작업에 집중하거나 작업이 조금씩 겹치는 정도라고 설명함.
  42. 앞으로의 과제는 에이전트끼리 효율적으로 통신하게 만드는 것과, 사람이 그 과정을 직접 빚으며 디지털 조립 라인의 감독자 역할을 하게 만드는 것이라고 봄.
  43. 청중석의 한 참석자는 스킬이 자신에게 아주 잘 맞았다며, MCP(모델 컨텍스트 프로토콜, 에이전트가 외부 도구·데이터에 표준화된 방식으로 접속하게 해 주는 규격)는 한때의 유행에 그칠 수도 있다는 생각을 밝힘.
  44. 다만 인증(authentication) 관점에서는 MCP가 강력하다고 인정함.
  45. 이 참석자는 스킬과 가드레일(guardrail, 에이전트가 의도치 않은 행동을 하지 않도록 두는 안전장치) CLI 조합이 실제로 잘 작동한다고 함. 로그 디버깅용 스킬로 CLI에서 대부분의 작업을 처리한다고 밝힘.
  46. 구글 정도 규모의 조직에서는 특정 영역 전문가가 만든 스킬을 다른 사람과 에이전트가 공짜로 물려받는 게 큰 장점이라고 함.
  47. KP는 스킬과 MCP 둘 다 지원하며, 커뮤니티가 실제로 쓰는 쪽을 계속 지원하는 게 방향이라고 답함.
  48. 이런 시스템을 평가하는 일 자체가 아주 어렵다는 질문에, 샌드박스(sandbox, 안전하게 격리된 실행 환경) 환경을 매번 세팅하는 기계적인 작업만으로도 품이 많이 든다고 답함.
  49. 가장 까다로운 부분은 새 데이터셋을 만드는 일이라고 함. 외부 벤치마킹용 오픈소스 데이터셋은 이미 좋은 게 많다고 함.
  50. 특정 스킬을 평가할 테스트는 그 스킬을 만든 사람이 직접 만들어야 하는 몫이라고 함.
  51. 최근에는 에이전트 스스로 그 평가 방식을 설계해 보게 하는 실험도 하고 있다고 밝힘. "조금 메타(meta, 자기 자신을 대상으로 하는)적"이라고 표현함.
  52. 딥마인드 직원들이 오히려 일반 고객보다 더 낮은 사용 한도를 갖고 있다는 질문에 KP는 그렇다고 인정함. 고객을 우선하기 때문이라고 함.
  53. KP는 업무용 계정에는 울트라(ultra) 등급이 있지만 개인 계정에는 없어서, 계정에 따라 스스로 행동을 바꿔야 한다고 밝힘.
  54. 등급별 사용 한도를 더 자세히 아는 안티그래비티 팀 동료가 근처에 있을 거라며 그쪽에 답을 미룸.
  55. 앞으로는 프로(pro) 모델 토큰 한도를 다 쓰면 자동으로 플래시(flash) 모델로, 구독 전체 한도를 다 쓰면 로컬 모델로 하네스가 알아서 넘겨 주는 방식이 흔해질 거라고 기대함.
  56. 지금 문제는 이 전환이 매끄럽지 않아서, 자리를 비운 사이 작업을 시켜 놓고 돌아왔더니 한 시간 동안 몫이 떨어져 아무것도 못 한 채 멈춰 있었다는 알림만 받는 경우가 생긴다는 점이라고 지적함.
  57. 코드 리뷰(review, 코드 변경을 다른 사람이 살펴보는 절차)를 자동화하는 사례를 묻는 질문에는, 언어별로 사내 스타일 가이드와 과거의 좋은 코드 예시로 파인튜닝한 전용 자동 리뷰 모델이 있다고 답함.
  58. 제품·조직 단위에서도 팀마다 자체 SRE 스타일 규칙과 프롬프트(모델에게 주는 지시문)를 만들어 리뷰어에게 더 좋은 신호를 주도록 갖춰 놓았다고 함.
  59. 바로 어제 자신이 올린 풀 리퀘스트(PR, 코드 변경 요청)에 자동 리뷰를 따로 트리거하지 않았는데도 다른 사람이 띄워 둔 에이전트가 알아서 꽤 쓸 만한 제안을 댓글로 남겼다고 소개함.
  60. 구글 엔지니어들이 수십만 줄씩 코드를 제출하던 규모에서, 이제는 에이전트가 더 많은 코드를 제출하고 더 많은 리뷰까지 받는 규모로 넘어가고 있다고 봄.
  61. 줄스(Jules)라는 도구를 예로 들며, 깃허브(GitHub)에 올린 자기 풀 리퀘스트를 웹 인터페이스에서 직접 다루고 리뷰까지 받을 수 있다고 소개함.
  62. 전날 나온 이야기로 깃허브에 에이전트가 만들어 올리는 코드 줄 수가 이미 조 단위에 이른다는 언급이 있었다고 전함.
  63. 사람의 역할은 결국 이 디지털 조립 라인의 감독자가 되는 것이고, 리뷰 같은 반복 작업까지 에이전트가 도와주면 "다 같이 해변에 가서 앉아 있을 수 있다"고 농담 섞어 말함.
  64. 에이전트도 자기가 하는 지루한 일을 싫어할 거라며, 이 문제를 풀어야 한다는 말로 세션을 마무리함.

한줄 코멘트. 오케스트레이션과 관측 도구는 그럴듯한데, 스케일 문제의 실제 해법이 아직 "몫 끊기"와 "사람이 멈추라고 말하기"라는 걸 발표자 스스로 인정하고 있음.

  1. 발표자는 샘 모로우(Sam Morrow), 깃허브(GitHub)에서 MCP 서버 개발을 이끄는 사람이라고 밝힘. 혼자가 아니라 팀이 함께 만든다고 강조함.
  2. 깃허브의 MCP(모델 컨텍스트 프로토콜, LLM이 외부 도구·데이터에 표준화된 방식으로 접속하게 해주는 개방형 규격) 여정은 작년 4월 로컬 서버를 오픈소스로 낸 것으로 시작해서 이제 막 1년이 됐다고 함.
  3. 공개 당시 그 주 깃허브에서 가장 별을 많이 받은 저장소였고, 노출이 커지면서 공개 기여가 몰려 빠르게 플랫폼 커버리지 빈틈이 채워졌다고 함.
  4. 한 달쯤 지나자 오히려 에이전트가 깃허브를 다루는 데 서툴러지고 컨텍스트 창(모델이 한 번에 참고할 수 있는 입력 범위)이 더 빨리 차버리는 문제가 생겼다고 함.
  5. 그때 툴이 100개가 넘었는데 당시 기준으로도 너무 많았다고 함.
  6. 랭체인(LangChain)이 그해 2월 발표한 연구가 정확히 같은 문제를 짚었다고 함 — 툴이 많다고 에이전트가 좋아지는 게 아니라 오히려 헷갈리고 잘 잊어버린다는 내용이었다고 함.
  7. 정확히는 툴이 많다기보다 컨텍스트에 그만큼 많은 툴 정보가 그대로 쑤셔 넣어지는 게 문제라고 함.
  8. 깃허브는 저장소·이슈·PR(풀 리퀘스트)·액션(Actions)·프로젝트까지 다루는 범위가 넓은 플랫폼이라 툴이 늘어나는 게 자연스러웠다고 함.
  9. 어려운 점은 사용자 각자가 필요로 하는 개별 툴을 못 쓰게 막고 싶지 않았다는 것이라고 함. 사용자층이 워낙 다양하다고 함.
  10. 이를 풀려고 먼저 툴셋(toolset, 관련 있는 제품 툴을 묶는 개념)을 빠르게 만들어 사용자가 원하는 것만 골라 설정할 수 있게 했다고 함.
  11. 에이전트가 툴 묶음을 스스로 찾아 필요한 만큼 켜는 동적 툴 선택 기능도 만들었고, 정식 출시는 안 했지만 같은 아이디어를 의미 기반 툴 검색용 RAG(검색 증강 생성, 답하기 전에 외부 자료를 찾아와 근거로 쓰는 방식) 버전으로도 만들어봤다고 함.
  12. 그런데 결과는 다들 그냥 기본 설정을 썼다는 것이라고 함. 우아한 해법을 만들어봐야 사용자가 JSON을 손봐야 하는데 대부분 안 한다고 함.
  13. 일부는 명세 자체의 문제일 수도 있다고 봄. MCP 명세에 툴 묶음 기능을 넣자는 제안이 여러 차례 나왔지만 매번 거부됐다고 함.
  14. 깃허브가 붙이는 모드나 설정 하나하나가 사실은 클라이언트 구현의 빈틈을 메우는 임시방편일 수 있다고 인정함.
  15. 예로 읽기 전용 모드를 쓰는 사용자가 약 17%인데, 이게 읽기 전용 힌트 애노테이션과 1대1로 대응함에도 이걸 서버 필터링 기준으로 노출하는 클라이언트가 거의 없다고 함(일부 게이트웨이는 지금 하기 시작했다고 함). 기업 사용 사례에서는 쉽게 이득 볼 수 있는 지점이라고 함.
  16. 원격 서버의 사용 패턴을 들여다보고 컨텍스트를 줄이는 더 나은 방법을 찾아 나섰다고 함.
  17. 먼저 일반적인 경우에 맞춰 툴 설명을 더 구체적으로 다듬어 초기 로드 시 사용하는 컨텍스트를 사용량 기준 약 49% 줄였다고 함.
  18. 이어서 CRUD(만들기·읽기·수정·삭제) 계열 툴을 묶어 더 줄였고, 기본 설정 기준으로 이제 약 40개 툴이 뜬다고 함. 필요에 따라 늘리거나 줄이기 쉽다고 함.
  19. 최근에는 많은 툴의 출력 토큰을 줄이는 데도 크게 힘을 썼다고 함. 목록 풀 리퀘스트(list pull requests) 하나만 정확히 필요한 내용으로 다듬었더니 출력에 쓰이던 토큰의 75% 넘게 줄었다고 함.
  20. 깃허브 서버가 토큰을 얼마나 잡아먹는지는 계속 바뀌는 목표라 몇 달 전과도 많이 다를 거라고 함. 코드 모드(code mode) 같은 더 진전된 접근도 배제하지 않고 내부적으로 계속 실험한다고 함.
  21. 데이터를 더 파본 결과 툴 실패율을 줄일 여지도 찾아냈고, 지금 성공률은 대략 95% 넘는 수준이라고 함.
  22. 모든 실패를 막을 순 없다고 함. 에이전트가 자기가 어느 저장소에 쓰기 권한이 있는지 모를 때도 있고 여전히 환각(hallucination)을 일으킨다고 함.
  23. 그래도 상당수는 툴 표면에 에이전트의 의도를 미리 반영해 넣는 방식으로 없앨 수 있었다고 함. 클라이언트 쪽에서 API를 다섯 번 호출해야 안전해지는 일이라면 그걸 서버 쪽에서 대신 처리해 왕복을 줄인다고 함 — 컨텍스트도 시간도 아끼고 에이전트 성공률도 눈에 띄게 오른다고 함.
  24. 작년부터는 평가(eval)도 돌리기 시작했다고 함. 개별 툴 설명을 하나씩 다듬는 대신 툴들을 서로 맞붙여 테스트해서, 맞는 순간에 불리고 틀린 순간엔 안 불리게 만드는 게 핵심이라고 함.
  25. 한 툴 설명을 너무 매력적으로 만들어 에이전트가 항상 그것만 부르게 되는 것도, 그 반대로 아예 안 불리는 것도 둘 다 문제라 그 사이를 최대한 좁혀야 한다고 함.
  26. 보안은 늘 도사리고 있는 위협이라고 함. 많은 사람이 MCP용 접근 토큰을 평문(plain text)으로 그대로 쓰고 있는 게 실제 문제라고 함.
  27. 그런 토큰은 대개 에이전트가 접근할 수 있는 곳에 저장되고, 수명이 길고, 권한이 과하게 부여돼 있어 악용되길 기다리는 상태라고 함.
  28. 사용자 잘못이라기보다 설정을 쉬우면서 동시에 안전하게 만드는 게 원래 어렵다고 함. 클라이언트는 시스템 키링(keyring)이나 암호화 저장소를 써야 하는데, VS 코드는 실제로 이렇게 한다고 함.
  29. MCP 명세는 더 나은 방법으로 원격 HTTP를 이미 작년 4월부터 제공했고, 깃허브도 이를 받아들여 안전한 연결이 가장 쉬운 선택이 되도록 만들려 했다고 함. 로컬 런타임을 따로 내려받게 하고 싶지 않았다고 함.
  30. 원격 서버는 OAuth 2.1을 지원하고, 팀이 PKCE(proof key for code exchange, 인가 코드 탈취를 막는 보안 확장)를 깃허브 인가 서버에 직접 붙여 클라이언트 앱의 보안 수준을 높였다고 함.
  31. OAuth가 가장 쉬운 길이 되길 바랐지만, 다들 동적 클라이언트 등록(dynamic client registration) 지원을 기대했고 깃허브 입장에선 이게 해결보다 문제를 더 만들었다고 함.
  32. 제대로 구현하면 앱 데이터베이스가 무한정 늘어나는 걸 막기 어렵고, 속도 제한을 어떤 단위로 묶을지도 애매하고, 믿을 만한 앱 신원 확인 수단도 없다고 함. 그래서 검토 끝에 거부했고, 선의로 나온 설계 실수라고 보며 이걸 지원 안 하는 인가 서버가 깃허브만은 아니라고 함.
  33. MCP 쪽에서는 클라이언트 ID 메타데이터 방식이 답이 될 걸로 정한 듯한데, 깃허브가 지원할 거라 장담은 못 해도 지원하도록 밀어보는 중이며 되면 로그인이 훨씬 쉬워질 거라고 함.
  34. 인베리언트 랩스(Invariant Labs)가 깃허브에서 비공개 데이터를 빼내는 프롬프트 인젝션(prompt injection, 외부 콘텐츠에 숨긴 지시로 모델을 조종하는 공격) 유출 공격을 제대로 시연해 공개한 적이 있다고 함.
  35. 특히 깃허브 MCP 서버를 콕 집어 언급했다고 함. 툴을 전부 켜두면 실제로 그런 공격이 가능해지는 건 맞다고 함.
  36. 다만 MCP를 쓰든 안 쓰든 깃허브 MCP를 쓰든 아니든 거의 모든 에이전트 구성에 해당하는 문제라고 함. 사이먼 윌슨(Simon Wilson)이 쓴 「치명적 삼각형(lethal trifecta)」 글을 참고하라고 함.
  37. 에이전트의 유용함과 이런 데이터 보호는 직접 충돌하는 관계라, 아직 안 풀린 채로 다들 방법을 찾고 있는 문제고 깃허브만의 문제도 아니라고 함.
  38. 사용자마다 위험 감수 수준이 완전히 달라서, 어떤 곳은 깃허브 엔터프라이즈 서버를 아예 외부망과 끊어(air-gapped) 훨씬 안전하게 쓰고, 다른 협업자들은 토큰 접근 권한을 에이전트에 다 열어준 채로 그냥 깃허브에 바로 붙어 쓴다고 함.
  39. 툴 노출을 관리할 때는 OAuth 스코프(권한 범위)에 크게 의존한다고 함. PAT(개인 접근 토큰)로 로그인하면 그 토큰이 가진 스코프만큼 툴 목록을 바로 걸러준다고 함. 사용자는 토큰만 주면 되고 따로 할 일이 없다고 함.
  40. OAuth 쪽은 스텝업(step-up) OAuth를 지원해서, 스코프가 부족하면 스코프 도전(scope challenge)을 돌려주고 사용자에게 그 스코프를 허용할지 대화식으로 물어본다고 함.
  41. 허용하면 실패하지 않고 그대로 툴 호출이 이어진다고 함. VS 코드가 이걸 지원하는데, 이미 갖고 있던 토큰에 권한이 부족할 때 그냥 실패시키지 않고 나중에 권한을 올릴 방법을 주려고 처음부터 함께 작업했다고 함.
  42. 액션(Actions) 같은 서버 토큰은 애초에 특정 사용자가 없어서, 사용자 전용 툴을 걸러내는 것만으로 실패와 낭비되는 컨텍스트를 동시에 줄인다고 함.
  43. 서버는 완전히 무상태(stateless)로 돌아가고 세션 저장에는 레디스(Redis)를 쓴다고 함. 흔한 관측성(observability) 스택이라 특이할 건 없지만, 많은 사람이 상태를 갖는 MCP 서버 프로세스를 단일 인스턴스로 돌리다 이 구조로 못 넘어와 고생한다고 함.
  44. 요청마다 SDK 차원에서 완전히 새 서버 인스턴스를 만들고 그 시작 시점에 툴을 붙인다고 함. 설정이 뭐든, 정책상 쓸 수 있는 툴이 뭐든 그 요청에 맞게 매번 새로 조립한다고 함.
  45. 이렇게 세션 어피니티(같은 세션을 같은 서버로 계속 보내는 방식) 없이도 주당 약 700만 건의 툴 호출을 처리하는 규모까지 왔다고 함.
  46. 세션은 주로 MCP를 통해 클라이언트가 스스로 밝힌 신원을 식별하는 용도로만 쓴다고 함. 사람들이 어떤 클라이언트로 서버를 쓰는지 파악하는 데 유용하다고 함.
  47. 인사이더스(Insiders) 모드라는 것도 있는데, 원하는 사람 누구에게나 흔쾌히 내줄 실험용 기능 플래그를 켜는 게 전부라고 함.
  48. 아직 정식 출시하지 않은 예로 MCP 앱스(MCP apps)가 있는데, 에이전트가 만든 이슈 초안을 올리기 전에 직접 고쳐볼 수 있게 해준다고 함. 오픈소스 활동을 진지하게 하는 사람일수록 자기가 올린 글이 봇이 쓴 것처럼 보여 닫혀버리는 걸 막고 싶어 해서, 처음엔 반신반의했지만 지금은 아주 좋아하게 됐다고 함.
  49. 앞으로는 서버 발견(discovery)이 자동화되고, 툴 사용이 배시(bash)처럼 다른 툴로 파이핑하거나 데이터를 스트리밍하는 식으로 더 조합적(compositional)으로 바뀔 거라고 봄.
  50. 클라우드플레어(Cloudflare)의 코드 모드 접근이나 앤트로픽(Anthropic)의 툴 검색 툴(tool search tool) API — 몇 주 전 클로드 코드(Claude Code)에 막 반영됐다고 함 — 같은 방향을 예로 듦. 오픈AI(OpenAI)도 비슷한 API를 최근 추가했다고 함.
  51. 앞으로 툴 수천 개가 정상적인 규모가 될 거라 보고, 그걸 막던 문제들을 지금 풀어가는 중이며 「툴 수를 줄이자」는 지금까지의 결정 상당수를 나중에 뒤집게 될 거라고 함.
  52. 사용자는 MCP가 뭔지 몰라도 되고 그냥 원하는 걸 말하면 되는 방향으로, OAuth 설정과 툴 선택까지 진짜 자율적으로 처리되는 날이 그리 멀지 않았다고 봄. 다만 지금은 아직 실험 단계라고 함.
  53. 파이(Pi) 같은 하네스(harness, 모델을 감싸는 실행 환경)도 흥미롭다고 봄. 직접 이상한 클라이언트를 만들어 이 문제를 자기 나름으로 아주 잘 풀 수도 있다며, 다들 괴상한 클라이언트를 실험해보라고 권함.
  54. 마무리로 숫자를 몇 개 짚음. 깃허브의 표준 IO 서버는 도커(Docker) 다운로드가 1,100만 건을 넘었는데, 이마저도 가장 많이 쓰이는 버전은 아니라고 함.
  55. 기여자가 126명이고, 이슈·PR이 2,300건을 넘었으며 1년 넘게 매일 하루 7건 이상 꼴로 올라온다고 함. 거의 하나하나 다 들여다본다고 함.
  56. 포크가 거의 4,000건, 별이 거의 3만 개에 이르고, 주당 툴 호출 건수는 800만 건에 가까워지고 있다고 함. 새로운 규모의 도전이 계속 커지는 중이라 속도가 줄어들 기미가 없다고 함.
  57. 그래도 이슈와 PR을 계속 열어달라고 부탁함. 감당은 하겠지만 지금은 다들에게 낯선 영역이라고 함.
  58. 질의응답에서 툴 호출을 파이핑하는 방식을 묻는 질문을 받고, MCP를 CLI(명령줄 인터페이스)로 감싸 시도해보는 게 재밌는 방향이라고 답함. 아직 다 다듬어지진 않았다고 함.
  59. 예로 어떤 MCP의 읽기 전용 툴만 골라 CLI로 감싸고 제대로 된 도움말(help)을 붙여주면 에이전트가 놀랍도록 잘 다룬다고 함. 그런 걸 직접 실험해보라고 권하며 마무리함.

한줄 코멘트. 우아한 툴셋·동적 선택 기능을 다 만들어놓고도 다들 기본값만 썼다는 대목이 이 발표의 핵심임 — 설정 화면이 아니라 기본값이 실제 제품임.

  1. 발표자는 앤트로픽(Anthropic) 소속 다비드 소리아 파라(David Soria Parra)이며, 화면에 MCP(모델 컨텍스트 프로토콜) 애플리케이션 하나를 띄우며 발표를 시작함.
  2. 이 애플리케이션은 에이전트가 자기 화면을 직접 내보내는 것인데, 플러그인도 SDK도 아니고 모델이 클라이언트에서 즉석으로 그린 것도 제품에 하드코딩된 것도 아니라고 설명함.
  3. 대신 MCP 서버 하나로 서비스되기 때문에 그 서버를 클로드(Claude)든 챗GPT(ChatGPT)든 VS 코드나 커서(Cursor)든 그대로 붙여 쓸 수 있다고 함.
  4. 이걸 하려면 클라이언트와 서버 양쪽이 서로 무슨 말을 하는지, 화면을 어떻게 그려야 하는지 이해하는 의미 체계(semantics)가 필요하고, 그래서 프로토콜이 필요하다고 함.
  5. MCP 서버는 앱만 내보내는 게 아니라 툴(도구)도 같이 내보낼 수 있어, 사람은 애플리케이션으로 상호작용하고 모델은 툴로 상호작용하는 두 갈래를 아직 많이 탐구하지 않았다고 밝힘.
  6. 18개월(약 1년 반) 전으로 되감으면 명세 문서 하나와 SDK 몇 개, 그것도 대부분 클로드가 짠 것뿐이었고 로컬에서만 돌고 툴 정도밖에 없었다고 함.
  7. 그사이 앤트로픽 쪽은 원격 지원, 중앙집중식 인가(authorization), 엘리시테이션(elicitation, 모델이 실행 중 사용자에게 되물어 정보를 받는 기능)과 태스크(task) 같은 새 원시 개념, 그리고 MCP 애플리케이션 같은 실험적 기능까지 얹었다고 함.
  8. 그 결과 지금은 월간 다운로드 1억 1000만 건에 도달했다는 걸 정말 멋진 이정표라고 소개함.
  9. 이 수치는 앤트로픽 자체 클라이언트·서버 사용량만이 아니라 오픈AI(OpenAI)의 에이전트 SDK, 구글의 ADK, 랭체인(LangChain)을 비롯해 이름도 못 들어봤을 수천 개 프레임워크·툴이 의존성으로 끌어다 쓴 수치라고 함.
  10. 이는 서로 다른 이 모든 도구가 대화할 수 있는 공통 표준 하나가 다들 손에 쥐어져 있다는 뜻이라고 풀이함.
  11. 참고로 지난 수십 년 가장 성공한 오픈소스 프로젝트 중 하나인 리액트(React)조차 같은 다운로드 규모에 도달하는 데 대략 두 배 시간이 걸렸다고 비교함.
  12. 그사이 사람들은 왓츠앱(WhatsApp) 서버, 블렌더(Blender) 서버 같은 소소한 장난감 프로젝트부터 리니어(Linear)·슬랙(Slack)·노션(Notion) 같은 SaaS 연동까지 정말 멋진 서버를 지어왔다고 함.
  13. 하지만 정작 대부분의 MCP 서버는 닫힌 문 뒤에서 회사 내부 시스템을 에이전트·AI 애플리케이션에 연결하는 용도로 만들어졌다고 함.
  14. 그래도 지금은 여전히 시작 단계일 뿐이라고 봄. 2025년이 탐색의 해였다면 2026년은 이 에이전트들을 실제 프로덕션에 넣는 해라고 규정함.
  15. 2024년은 그냥 데모 여러 개를 만들어 사람들에게 멋진 걸 보여주고 약간의 화제를 낸 해였다고 정리함.
  16. 2025년은 온전히 코딩 에이전트의 해였는데, 로컬에서 돌고 컴파일러를 불러 검증할 수 있고 문제가 생기면 바로 앞에 개발자가 있어 고칠 수 있어서 에이전트에게 가장 이상적인 시나리오라고 함.
  17. 이제 모델 능력이 올라가면서 코딩 에이전트를 넘어 재무 분석가나 마케팅 담당자가 하는 것 같은 진짜 지식노동을 하는 범용 에이전트로 가는 새 시대가 올해 시작된다고 전망함.
  18. 이런 지식노동 에이전트에게 필요한 건 컴파일러를 부르는 로컬 에이전트가 아니라 SaaS 애플리케이션 대여섯 개와 공유 드라이브에 접속할 수 있는 것, 즉 연결성(connectivity)이라고 짚음.
  19. 연결성은 하나의 정답이 아니라고 함. 컴퓨터 사용(computer use)이든 CLI든 MCP든 이 중 하나가 모든 연결 문제를 푼다고 말하는 사람이 있다면 대개 틀렸다고 함.
  20. 정답은 늘 "상황에 따라 다르다"이고, 연결성에는 여러 층으로 이루어진 큰 스택이 있으며 일마다 맞는 도구가 따로 있다고 설명함.
  21. 2026년 에이전트를 지을 때 고려할 세 가지 축으로 스킬(skills), MCP, 그리고 상황에 따른 CLI나 컴퓨터 사용을 꼽음.
  22. 스킬은 도메인 지식, 즉 특정 작업에 맞는 능력을 아주 단순한 파일 하나에 담은 것으로 대체로 재사용이 잘 되며 플랫폼마다 사소한 차이만 있다고 설명함.
  23. CLI는 로컬 코딩 에이전트에서 인기가 높은데, 시작하기 좋고 배시(bash)에 그냥 던져 넣을 수 있으며 모델이 그 CLI가 뭘 할 수 있는지 스스로 알아낼 수 있다는 장점이 있다고 함.
  24. 특히 깃허브(GitHub)나 깃(Git)처럼 사전학습(pre-training) 데이터에 이미 들어있는 CLI라면 연결 수단으로 훌륭하고, 샌드박스나 코드 실행 환경을 전제할 수 있는 로컬 에이전트에 특히 잘 맞는다고 함.
  25. 반대로 샌드박스가 없거나 풍부한 의미 체계가 필요하거나, 오래 걸리는 작업을 보여주는 UI나 리소스 같은 개념이 필요할 때는 얘기가 다르다고 함.
  26. 플랫폼과 완전히 분리된 걸 지어야 하거나 인가·거버넌스·정책 같은 엔터프라이즈 요구가 있거나 MCP 애플리케이션 같은 실험을 해보고 싶다면, MCP가 툴박스 속 또 하나의 연결 조직이 되어준다고 함.
  27. 그래서 2026년에는 에이전트가 이 셋 중 하나만 쓰는 게 아니라 전부를 매끄럽게 함께 쓰게 될 거라고 함.
  28. 다만 아직 거기까지 못 갔다고 인정함. 지어야 할 게 많이 남았고, 부분적으로는 지금 에이전트들이 "아직 별로"이기 때문이라고 함.
  29. 또 부분적으로는 이 연결 조직을 실제로 엮는 기법들에 대해 업계가 아직 충분히 이야기하지 않았기 때문이라고 함.
  30. 지금 가장 먼저 지어야 할 건 클라이언트 쪽, 즉 클로드 코드는 파이(Pi)든 뭐가 됐든 이 연결 부분을 움직이는 에이전트 하네스(harness) 쪽이라고 함.
  31. 거기서 해야 할 첫 번째 일로 프로그레시브 디스커버리(progressive discovery, 툴을 미리 다 불러오지 않고 필요할 때만 찾아 불러오는 방식)를 짓기 시작해야 한다고 강조함.
  32. 사람들은 흔히 MCP 하면 컨텍스트 부담을 떠올리지 못하는데, 사실 프로토콜은 정보를 실어 나를 뿐이고 그 정보를 어떻게 다룰지는 클라이언트의 책임이라고 짚음.
  33. 지금까지는 다들 이 초기 실험 단계라서 모든 툴을 그냥 컨텍스트 창에 다 밀어넣고는 컨텍스트 창이 커졌다고 놀라는 식이었다고 함.
  34. 대신 툴 검색(tool search) 같은 걸 써서 툴 로딩을 미뤄두고 모델이 필요할 때 그때그때 불러오는 프로그레시브 디스커버리 패턴을 써야 한다고 함.
  35. 이 기능은 앤트로픽 API에 이미 있고 다른 회사 API에서도 쓸 수 있으며, 모델에게 "툴을 불러오는 툴"을 하나 쥐여주기만 하면 직접 구현할 수도 있다고 함.
  36. 그러면 모델이 "아, 지금 툴이 필요할 수도 있겠다, 뭐가 필요한지 찾아보자"라고 판단해 필요한 순간에만 불러오게 된다고 설명함.
  37. 이 기능을 붙이기 전과 후의 클로드 코드 화면을 나란히 보여주며, 붙인 뒤 툴 관련 컨텍스트 사용량이 크게 줄어든 걸 확인시킴.
  38. 두 번째 기법은 프로그래매틱 툴 콜링(programmatic tool calling), 다른 사람들이 코드 모드(code mode)라고도 부르는 것이라고 소개함.
  39. 모델이 툴 하나 부르고 결과 받아 다시 말하고 또 다른 툴 부르는 식으로 매번 오가게 하는 대신, 여러 툴을 한데 묶어 처리하고 싶다는 게 핵심이라고 함.
  40. 이렇게 모델이 매번 오케스트레이션을 맡으면 그때마다 추론(inference)을 쓰고 지연(latency)에 민감해지는데, 차라리 스크립트 하나를 쓰게 하면 훨씬 효율적이라고 함.
  41. 예를 들어 bash 명령을 쓸 때 코딩 에이전트가 실제로 하는 일이 바로 이런 방식이며, 이걸 MCP를 포함한 모든 것에 적용할 수 있고 또 적용해야 한다고 함.
  42. 구체적으로는 모델에게 툴을 하나씩 주는 대신 REPL(즉석 실행) 툴 하나, 즉 V8 아이솔레이트나 루아(Lua) 인터프리터 같은 실행 환경을 주고 코드를 직접 써서 실행·조합하게 하라고 함.
  43. MCP에는 구조화된 출력(structured output)이라는 기능이 있어 리턴 값의 타입 정보를 미리 알려주는데, 모델이 이 정보로 타입을 파악해 여러 툴 결과를 매끄럽게 조합할 수 있다고 함.
  44. 예시로 원래 호출 두 번으로 하던 일을 한 번의 호출로 줄이고, 모델이 JSON에서 필요 없는 부분을 자동으로 걸러내며 이어갈 수 있었다고 보여줌.
  45. 구조화된 출력이 없는 경우에도 저렴한 모델을 하나 더 불러 "이 타입으로 정리해서 돌려줘"라고 시키면 같은 효과를 낼 수 있다고 함.
  46. 이런 조합은 실행 파일이나 CLI, API 같은 다른 컴포넌트와도 함께 엮을 수 있다고 덧붙임.
  47. 서버 쪽으로 넘어가, REST API를 그대로 1대1로 MCP 서버에 옮겨 담는 짓을 그만둬야 한다고 함. 이런 REST-투-MCP 변환 툴을 볼 때마다 좀 민망하다고 밝힘.
  48. 대신 에이전트를 위해 설계해야 하는데, 그 출발점으로는 "사람인 나라면 이걸 어떻게 쓰고 싶을까"를 먼저 생각하는 게 좋다고 함.
  49. 여러 툴을 오케스트레이션하고 싶다면 프로그래매틱 툴 콜링을 클라이언트 쪽뿐 아니라 서버 쪽에서도 쓸 수 있다고 함.
  50. 클라우드플레어(Cloudflare) MCP 서버 등이 좋은 예로, 툴을 낱개로 주는 대신 모델에게 실행 환경을 주고 알아서 오케스트레이션하게 해 토큰 사용량과 지연을 줄이고 조합력도 훨씬 키운다고 설명함.
  51. 서버를 만드는 사람들도 대안 대신 MCP가 제공하는 풍부한 의미 체계를 써야 한다고 함. MCP 애플리케이션을 내보내고 스킬을 MCP 위에 얹어 내보내는 것들이라고 함.
  52. 태스크나 엘리시테이션처럼 아직 덜 쓰이는 기능도 활용해야 하는데, 이런 건 MCP만 할 수 있는 것들이라고 강조함.
  53. 이런 건 다 에이전트를 짓는 사람들과 제품 담당자들이 할 일이고, 그와 별개로 앤트로픽도 MCP 프로토콜 자체에 손볼 게 많다고 함.
  54. 첫 번째로 코어를 개선해야 하는데, 지금 스트리머블 HTTP(streamable HTTP) 방식은 대형 하이퍼스케일러 입장에서 스케일하기 매우 어렵다고 지적함.
  55. 구글 쪽 동료들이 스테이트리스(stateless, 상태를 서버에 남기지 않는) 전송 프로토콜을 제안했는데, 클라우드런(Cloud Run)이나 쿠버네티스(Kubernetes)에 배포하는 흔한 REST 서버처럼 MCP 서버를 다룰 수 있게 된다고 함.
  56. 이 제안은 6월에 나오고 이후 SDK에도 곧 반영되길 바란다고 밝힘.
  57. 다음으로 비동기 태스크(task) 원시 개념을 개선해야 하는데, 쉽게 말해 에이전트끼리 통신하게 해주는 기능이라고 함. 지금은 실험적이라 지원 클라이언트가 거의 없어 더 만들어갈 계획이라고 함.
  58. 지난 1년간 배운 것들을 바탕으로 타입스크립트 SDK 버전 2와 파이썬 SDK 버전 2도 낼 예정이라고 함.
  59. 청중에게 패스트MCP(FastMCP)를 쓰는지 물으며, 자신이 짠 파이썬 SDK보다 훨씬 낫다는 걸 스스로 인정하고 더 나은 파이썬 개발자들의 도움을 받아 고쳐가고 있다고 밝힘.
  60. 다음으로 어디서나 통합되게 만드는 작업으로, 특히 엔터프라이즈를 위해 신원 제공자(identity provider)들과 함께 크로스앱 액세스(cross-app access)를 준비 중이라고 함. 구글이든 옥타(Okta)든 회사 신원 제공자로 한 번 로그인하면 이후 MCP 서버들을 재로그인 없이 쓸 수 있게 해주는 기능이라고 설명함.
  61. 서버 디스커버리(server discovery)도 추가하는데, 잘 알려진(well-known) URL에 서버 정보를 명시해두면 크롤러·브라우저·에이전트가 방문한 웹사이트에 쓸 수 있는 MCP 서버가 있는지 자동으로 알아채고, 이 기능도 6월 다음 명세와 함께 나온다고 함.
  62. 마지막으로 확장(extension) 메커니즘을 더 쓰기 시작한다고 함. MCP 애플리케이션은 HTML을 그리기 힘든 CLI가 아니라 웹 기반 인터페이스에서만 지원되는 식으로 클라이언트마다 다르게 지원된다고 함.
  63. 가장 기대되는 확장으로 스킬 오버 MCP(skills over MCP)를 꼽음. 툴이 잔뜩 든 큰 MCP 서버라면 "이건 이렇게 써야 한다"는 사용 지식을 함께 실어 보내고 싶어지는 게 당연하다고 함.
  64. 이러면 서버를 만든 사람이 플러그인 메커니즘이나 레지스트리에 기대지 않고도 최신 스킬을 계속 갱신해서 내보낼 수 있다고 함.
  65. 아직 정식 의미 체계가 확정되지 않았지만 모델에게 "스킬을 불러오는" 툴 하나만 쥐여줘도 오늘 당장 비슷한 걸 만들어볼 수 있고, 이후 이 의미 체계를 정식으로 정의할 계획이라고 밝힘.
  66. 정리하면 MCP는 지금 꽤 좋은 상태이고, 올해 에이전트를 완전한 연결성 쪽으로 밀어붙일 것이며 MCP가 계속 중요한 역할을 할 거라고 전망함.
  67. 커뮤니티 피드백을 강조하며, 재단을 막 세웠고 디스코드(Discord)와 이슈 트래커를 갖춘 오픈소스 커뮤니티로 운영되고 있으니 무엇이 맞고 틀렸는지 알려달라고 요청함.
  68. 2026년은 연결성의 해이고, 가장 뛰어난 에이전트는 컴퓨터 사용·CLI·MCP·스킬을 가리지 않고 쓸 수 있는 걸 다 쓸 거라고 정리함.
  69. 폭넓은 능력을 갖추고 싶어서라고 이유를 밝히며, 그 결과로 나온 게 방금 처음에 보여준 화면 같은 제품 기능이라고 함.
  70. 그 화면은 사실 MCP 애플리케이션 하나가 뭔가를 렌더링하는 것일 뿐이라고 밝히며, 모델이 그래프를 직접 그려내는 모습을 다시 보여주며 발표를 마침.

한줄 코멘트. 월간 다운로드 1억 1000만 건과 "우리 에이전트는 아직 별로다"라는 인정이 한 발표 안에 같이 나온다는 게, 이 프로토콜이 채택 곡선과 실전 성숙도가 따로 노는 단계에 있다는 걸 보여줌.

  1. 발표자는 클라우드플레어(Cloudflare)에서 에이전트 SDK를 만드는 수닐 파이(Sunil Pai)이고, 실시간 멀티플레이어 앱을 위한 오픈소스 툴 파티킷(PartyKit)을 만든 사람이라고 소개됨.
  2. 이 발표는 자기 팀이 코드 모드(code mode)라 부르는 것에 관한 이야기이며, 자신들이 발명한 게 아니라 앞선 사례가 있다고 밝히고 새로 발견하고 있는 함의를 이야기하는 자리라고 함.
  3. AI 애플리케이션을 만들어본 사람은 알겠지만 툴 호출(tool calling)은 규모가 커지면 이상해지기 시작한다고 함. 툴 몇 개에 짧은 실행이면 괜찮지만, 구글 서비스·지라(Jira)·위키까지 넣어 툴이 수백 개로 컨텍스트를 채우면 깨진다고 함.
  4. 조합이 이상해지고, 모델과 주고받는 왕복이 아주 느려진다고 함.
  5. 그래서 JSON을 주고받는 대신 모델에게 코드, 주로 자바스크립트(JavaScript)를 짜게 해서 그 코드를 실행 환경에 돌리는 방식을 택했다고 함.
  6. 코드로 하면 타입이 있는 API를 쓸 수 있고 타입 체크와 문법 오류 검출이 가능하며, 모델은 이미 기가바이트에서 테라바이트 단위 코드 데이터로 훈련돼 있다는 이점이 있다고 함.
  7. 왕복을 거듭하는 대신 코드를 한 번에 다 실행하는 단일 실행으로 끝낼 수 있다고 함.
  8. 코드가 가진 기본 능력들 — 반복문을 돌리고, 상태를 들고 있고, 순서를 정하고, 병렬로 처리하는 것 — 은 엔지니어가 평소 코드로 하던 일 그대로라고 설명함.
  9. 이 방식을 처음 적용한 곳은 동료 매트 캐리(Matt Carey)가 만든 사례로, 내일 이 주제로 더 자세히 발표한다고 소개함. 클라우드플레어 API 표면은 약 2,600개 엔드포인트라고 함.
  10. 이 엔드포인트를 하나하나 툴로 노출하면 첫 호출에서만 약 120만 토큰이 든다고 함. 클라우드플레어 API 전체를 위한 MCP(모델 컨텍스트 프로토콜) 서버를 만들 방법이 없다는 뜻이라고 함.
  11. 매트 캐리는 툴 호출을 검색(search)과 실행(execute) 딱 두 개만 노출하는 아이디어를 냈다고 함. 두 엔드포인트 모두 입력으로 코드, 즉 문자열 하나를 받는다고 함.
  12. 검색 함수에 넘기는 입력은 오픈API(OpenAPI) JSON 스펙 전체라고 함.
  13. 검색이 끝나면 실행이 그 결과를 가지고 호출할 수 있는 함수 여러 개를 돌려주는데, 이 구조로 120만~150만 토큰이던 걸 1,000토큰까지 줄였다고 함. 99.9% 감소라고 함.
  14. 이 대목에서 라이브 데모를 보여주는데, 무대에서 데모가 잘 안 풀리는 편이라고 미리 밝힘. 요점은 아주 넓은 API 표면을 극도로 빠르게 만들 수 있었다는 것이라고 함.
  15. 데모에 쓴 프롬프트는 일반적인 문장이었다고 함. "디도스(DDoS) 공격을 당하고 있다, 공격 중인 IP를 다 찾아서 차단해달라"는 고객 요청 상황이라고 함.
  16. 사이트가 다운되는 공황 상태에서는 메뉴를 하나하나 뒤질 시간이 없고, 클라우드플레어 대시보드는 다루기 번거롭기로 유명하며, 새벽 3시에는 담당자(AE)도 못 붙잡는다고 함.
  17. 일반 MCP 방식이었다면 120만 토큰 문제는 차치하고도 API 호출마다 왕복이 8번쯤 필요했을 거라고 함. 대신 모델이 코드 문자열 하나를 생성해 API 표면 바로 옆에서 즉시 돌려 한 번에 끝낸다고 함.
  18. 실제로 돌아가는 건 그냥 자바스크립트이고, API 표면에 노출된 함수들일 뿐이라고 함.
  19. 실제 시연에서는 워커(Worker) 목록 조회를 읽기 전용 권한으로 승인했는데, 자바스크립트 오류와 페이지네이션(pagination) 처리 문제가 실시간으로 튀어나왔다고 함. 무대에 오르기 전 열 번 테스트했는데도 이런다며 웃음을 자아냄.
  20. 이 대목의 요점은, 만약 이 발표가 MCP 서버 최적화에 관한 것이었다면 여기서 끝났겠지만 더 깊은 무언가가 있다는 걸 알게 됐다는 것이라고 함.
  21. 청중이 모두 프로그래머라는 전제로, "바탕화면에 사진 200장이 있는데 분류하고 이름을 바꿔달라"는 문제를 예로 듦.
  22. 프로그래머라면 아이디이(IDE)를 열고 짧은 스크립트를 짜서 사진마다 비전 모델에 넘겨 캡션을 받고 이름을 바꿔서 끝낸다고 함. 그게 시스템과 상호작용하는 방식이라고 함.
  23. 발표자의 어머니는 이렇게 할 수 없고, 선택지는 자신에게 전화하거나 사진 관리용 최저 사양 앱을 월 7달러에 쓰는 것뿐이며, 그런 앱은 이유 없이 데몬을 설치시키는데 그게 암호화폐를 훔쳐가는 물건인 경우도 있다고 함.
  24. 지금까지는 비기술자에게 필요와 욕구에 맞춘 맞춤 인터페이스를 따로 만들어주는 이 이분법이 받아들일 만한 타협이었다고 함.
  25. LLM(거대언어모델)이 이 경계를 깨고 있다고 함. 이제 지구상 모든 사람이 시스템과 상호작용할 코드를 뽑아주는 동료를 가진 셈이라고 함.
  26. "파일 이름을 날짜와 위치별로 바꿔줘" 같은 한 줄이 코드를 생성하고, 그 코드가 노출된 시스템 위에서 돌아간다고 함. 이걸 안전하게 실행하는 부분이 곧 다룰 이야기라고 함.
  27. 두 번째 사례로 클라우드플레어 워커스(Cloudflare Workers)를 만든 켄턴(Kenton)을 소개함. 켄턴은 자기만의 바이브 코딩(vibe coding) 환경을 직접 만들었다고 함.
  28. 그가 모델에게 시킨 건 TLDraw나 엑스칼리드로(Excalidraw) 같은 캔버스를 만드는 일이었고, 모델은 붓과 색이 있는 작은 캔버스를 만들어냈다고 함.
  29. 켄턴이 맨 처음 한 일은 캔버스에 틱택토(tic-tac-toe) 판을 그리고 한쪽 구석에 X 표시를 하나 그려 넣은 것이라고 함.
  30. 그다음 켄턴은 모델에게 "나랑 틱택토를 두자"고 시켰고, 모델은 예상대로 틱택토 앱을 새로 생성하기 시작했다고 함.
  31. 켄턴은 이걸 바로 멈추고, "너는 시스템의 전체 상태에 접근할 수 있다. 상태는 획(stroke) 배열, 즉 격자선과 X 표시 같은 점들의 나열일 뿐이다. 그걸 살펴보고 나랑 게임을 해라"고 지시했다고 함.
  32. 모델은 곧바로 그 상태를 자기 컨텍스트로 읽어들여 "이게 틱택토 판처럼 보이고, 왼쪽 위에 X를 놓은 걸 알겠다. 가운데에 완벽한 원을 그리겠다"고 반응했다고 함.
  33. 분명히 말하지만 이 시스템 어디에도 틱택토 코드는 존재하지 않았다고 함. 모델이 획 집합으로 시스템과 상호작용하는 법을 스스로 알아낸 창발적(emergent) 행동이라고 함.
  34. 참고로 모델은 게임에서 졌는데, 추론 과정(reasoning trace)을 보니 오퍼스(Opus)가 켄턴에게 일부러 져준 것이었다고 함. 이건 또 다른 정렬(alignment) 문제라 이 자리에서 다루지 않는다고 함.
  35. 이 사례가 사내에서 많은 논의를 낳았고, 그래서 이 발표가 다소 붕 뜬 이야기처럼 들릴 수 있다고 함. 자신들도 어디로 갈지 확신하지 못하지만 이 아이디어를 청중에게 퍼뜨리고 싶다고 함.
  36. 그래서 쓰기 시작한 표현이, 모델이 프로그램을 생성하는 걸 멈추고 대신 상태 기계(state machine) 안에 들어가 살기 시작했다는 것이라고 함.
  37. 앱을 생성하는 단계를 따로 두고 그걸 사용하는 상호작용 단계를 또 따로 두지 않아도 된다는 게 이 사례의 핵심이라고 함.
  38. 이런 새로운 소프트웨어 아키텍처를 다들 하네스(harness)라 부르며 짓고 있다고 함. 지난 3~6개월 사이 코딩 에이전트가 훌륭한 범용 컴퓨팅 기계라는 걸 다들 깨달았기 때문이라고 함.
  39. 그래서 클로드 코드(Claude Code)나 파이(Pi) 같은 걸 맥 미니(Mac Mini) 위에 돌리는 사람이 늘었는데, API 호출이나 하자고 400달러짜리 기계를 살 필요는 없다며, 중고 맥 미니 가격이 뛴 걸 보면 어이가 없다고 함.
  40. 하네스라는 아키텍처의 핵심은 코드를 생성할 뿐 아니라 그 코드를 실행할 안전한 공간을 갖고, 그 공간에 능력(capability)들을 노출한다는 점이라고 함.
  41. 클라우드플레어에도 컨테이너와 VM(가상머신)을 쓰는 샌드박스 SDK가 따로 있지만, 지금 얘기하는 샌드박스는 그것과 다르다고 밝힘.
  42. 일반 컨테이너는 온갖 기능을 다 갖춘 채 시작해서 바깥에서 보안을 둘러씌우는 방식이라고 함. 이 샌드박스는 아무 능력도 없는 상태로 시작해서 코드 실행 말고는 아무것도 못 하고, 페치(fetch)도 못 하고 노출된 API도 없다고 함.
  43. 그다음 능력을 하나씩 명시적으로 부여한다고 함. 클라우드플레어는 이걸 다이내믹 워커스(dynamic workers)라 부르고, V8 아이솔레이트(V8 isolate)를 쓰는데 시작이 매우 빠르고 약 10년치 보안 하드닝(hardening)이 쌓여 있어서라고 함.
  44. 능력을 API 형태로 하나씩 노출하고, 모든 아웃바운드 페치와 네트워크 연결도 통제한다고 함. 기본 권장 방식은 아웃바운드 페치를 아예 막고 오직 API로만 나가게 하는 것이라고 함.
  45. 빨라야 하고 완전한 관측 가능성(observability)이 있어야 한다고 함. 지난 화요일 왜 라마 응가 같은 데 230만 달러짜리 거래를 했는지 그 코드로 돌아가 확인할 수 있어야 한다고 예로 듦.
  46. V8 아이솔레이트가 아니어도 되고 웹어셈블리(WebAssembly)나 커스텀 자바스크립트 인터프리터도 쓸 수 있다고 함. 핵심은 빠르게 실행되면서 능력을 노출할 수 있는 무언가면 된다는 것이라고 함.
  47. 여기서부터 더 야심 찬 그림을 그릴 수 있다고 함. 지금까지 보여준 건 코드를 한 번 돌려 API에 적용하는 일회성 사례였지만, 며칠·몇 달·몇 년씩 도는 장기 워크플로를 생성하고 각 인스턴스가 생애 내내 상태를 들고 다니게 할 수도 있다고 함.
  48. 생성형 UI(generative UI) 세계에서는 사용자마다 완전히 다른 맞춤 UI를 만들어낼 수 있다고 함. 이커머스(전자상거래)에서는 인기가 오를수록 UI가 모든 사용자에게 맞춰야 하는 밋밋한 것이 되고, 그다음 ML(머신러닝) 담당자들이 "사용자마다 버튼 색만 바꾸자" 정도로 그친다고 지적함.
  49. 자신이 오퍼스(Opus)에게 생성형 UI를 설명하는 슬라이드 자체를 생성형 UI로 만들어달라고 시켰는데, 여전히 어색해 보인다며 웃음을 자아냄.
  50. 대신 완전히 맞춤화된 UI로 갈 수 있다고 함. 사용자가 좋아하는 것, 장바구니에 담긴 주문, 그들을 화나게 만들 만한 것까지 이미 알고 있는 컨텍스트를 행동(action)으로 표면화할 수 있다고 함.
  51. UI가 꼭 빈 채팅창일 필요는 없다고 함. 다만 빈 채팅창으로 하는 이커머스도 나름 재미있을 것 같다고 덧붙임.
  52. 예로 "이 신발을 반품하고 100달러 아래에서 비슷한 걸 찾아달라"는 요청과 배송이 늦어진 주문 상태를 묻는 요청 두 가지를 듦. 제품 담당자가 이런 흐름을 미리 구현해두지 않았다면 답이 형편없었겠지만, 지금은 그 자리에서 생성해낼 수 있다고 함.
  53. 결국 백엔드에 만들어둔 시스템을 바탕으로 사용자 한 명 한 명에게 완전히 다른 프로그램을 생성해줄 수 있는 시대라고 정리함. 새로운 종류의 소프트웨어라고 함.
  54. 하네스는 제품 안에만 갇혀 있지 않고, 사용자와 더 가까운 곳에서 돌려 자기가 쓰는 여러 서비스를 직접 뒤섞을 수 있다는 데서 힘을 얻는 사람도 많다고 함. 클라우드플레어 서버 대신 아이폰 위에서 돌리라는 농담을 던지면서도, 제발 자기네 서버에서 돌려달라고 덧붙임.
  55. 이 안전한 환경 안에서 서로 다른 시스템을 작업 단위(task-by-task)로 이어 붙일 수 있게 된다고 함.
  56. 자신은 리액트(React) 프로그래머라 UI 개발자들을 겁줄 생각은 없다면서도, 이건 UI를 놓고 그동안 생각해온 모든 걸 다시 생각하는 일이라고 함. 코드를 문자열째로 그 자리에서 실행하는 eval이 안전하지 않다는 이유로 30년간 손대지 못한 기술 나무의 한 가지인데, 이제 안전한 eval과 코드를 생성해주는 것들이 생겼다고 함.
  57. 다음 10억 사용자가 코드를 생성해주는 작은 로봇(에이전트)들이라는 걸 이해할 자리에 서야 한다고 함. 다만 고객은 여전히 사람이라고 짚음.
  58. 시스템과 실제로 상호작용하는 에이전트들은 술집이 아니라 레지스트리(registry)에서 놀고, 타입과 문법 오류를 꿈꾼다고 함.
  59. 그래서 이 에이전트들을 위한 개발자 경험(developer experience)을 고민해야 한다고 함. 마크다운(Markdown)으로 된 문서, 에이전트가 다음에 뭘 해야 할지 알려주는 오류 메시지, 검색으로 찾을 수 있는 디스커버리(discoverability) 같은 걸 이미 잘하는 회사들이 있다고 함.
  60. 머릿속에 꼭 넣어두라고 강조하는 큰 개념은 캐퍼빌리티 기반 보안(capability-based security)이라고 함. 자바스크립트에 국한된 이야기가 아니고 파이썬이든 웹어셈블리든 될 수 있으며, 리스프(Lisp)가 다시 각광받길 바란다고 함.
  61. AST(추상 구문 트리)가 어떻게 동작하는지 리스프로 배웠다고 함. 핵심 속성은 그대로라고 함 — 이벤트, 샌드박싱, 캐퍼빌리티 기반 보안, 그리고 빠르게 시작해 잠깐 돌고 사라질 수 있도록 임베더블(embeddable)해야 한다는 것이라고 함.
  62. UI 프로그래머들은 그동안 사용자와 가장 가까이 있었기 때문에 이 새로운 영역에서 특히 잘할 거라 생각하고, 그게 기쁘다고 함.
  63. 마무리로, 그동안 프로그래머는 코드로 어떤 시스템과도 상호작용할 무한한 힘을 가졌고 대신 트위터에 불평이나 했지만, 다른 모든 사람은 버튼과 폼만 받았다고 함.
  64. 그 구분이 지금 깨지고 있고, 이런 세상에서는 코드가 직접 말하게 해야 한다고 함. 모든 시스템과 상호작용하는 건 결국 코드라는 것이라고 함.

한줄 코멘트. 툴을 백 개 나열해 컨텍스트를 채우는 대신 코드 실행 권한을 여닫는 캐퍼빌리티로 바꾸자는 이야기인데, 그 캐퍼빌리티를 누가 얼마나 넓게 열어줄지 정하는 기준은 이 발표 안에 없음.

  1. 발표자는 배리 장(Barry Zhang)과 마헤시 무라그(Mahesh Murag)이고 둘 다 앤트로픽(Anthropic) 소속임. 지난 발표 때는 에이전트가 뭔지부터 정의하던 시절이었는데 지금은 다들 매일 에이전트를 쓴다고 함.
  2. 그런데도 에이전트는 지능과 능력은 있어도 실제 일에 필요한 전문성(expertise)까지는 갖추지 못해 빈틈이 여전하다고 함. 그래서 에이전트 스킬(Agent Skills)을 만들었고, 이 발표는 왜 에이전트를 새로 짓는 대신 스킬을 만들기 시작했는지 보여주는 자리라고 함.
  3. 지난 발표 이후 MCP(Model Context Protocol, 에이전트가 외부 도구·데이터에 연결하는 개방형 규격)가 에이전트 연결의 표준이 됐다고 함.
  4. 앤트로픽의 첫 코딩 에이전트인 클로드 코드(Claude Code)가 나왔고, 클로드 에이전트 SDK(Claude Agent SDK)는 이제 프로덕션에 바로 쓸 수 있는 에이전트를 기본으로 제공한다고 함.
  5. 생태계가 성숙하면서 모델과 런타임 환경(runtime environment, 에이전트가 실제로 돌아가는 실행 환경)이 더 단단히 붙는 새 패러다임으로 옮겨가고 있다고 함.
  6. 한마디로 줄이면 "코드만 있으면 된다"는 것이 이번 발표의 핵심 주장이라고 함.
  7. 예전엔 도메인마다 에이전트가 전혀 다르게 생길 것이고 각자 자기 툴과 스캐폴딩(scaffolding, 에이전트를 돌리는 기본 틀)이 필요해서 도메인마다 별도 에이전트를 둬야 한다고 생각했다고 함.
  8. 도메인마다 커스터마이징은 여전히 중요하지만, 그 밑을 받치는 에이전트 자체는 생각보다 훨씬 보편적이었다고 함. 코드는 그냥 하나의 용례가 아니라 디지털 세계로 통하는 보편적인 인터페이스였다는 것임.
  9. 클로드 코드를 만들고 나서야 클로드 코드가 사실은 범용 에이전트라는 걸 알게 됐다고 함.
  10. 재무 보고서를 만드는 상황을 예로 듦. 모델이 API를 불러 데이터를 가져오고 조사하고, 파일시스템에 정리하고, 파이썬(Python)으로 분석해 결과를 파일 형식으로 종합하는 것까지 전부 코드로 처리한다고 함.
  11. 그러면 핵심 스캐폴딩은 배시(bash)와 파일시스템만 남을 만큼 얇아질 수 있고, 이게 아주 잘 확장된다고 함. 하지만 곧바로 다른 문제, 도메인 전문성 문제에 부딪혔다고 함.
  12. 세금 신고를 IQ 300짜리 수학 천재 마헤시와 경험 많은 세무 전문가 배리 중 누구한테 맡기고 싶은지 물음. 매번 배리를 고르겠다고 함.
  13. 마헤시가 2025년 세법을 처음부터 스스로 추론해서 알아내길 바라지 않고, 도메인 전문가가 일관되게 실행해 주길 원한다는 것임.
  14. 오늘날 에이전트는 마헤시와 많이 닮았다고 함. 똑똑하지만 전문성이 부족하고, 노력을 들이고 제대로 안내하면 놀라운 일도 해내지만 정작 앞단에 중요한 맥락이 빠져 있는 경우가 많다는 것임.
  15. 에이전트는 사람의 전문성을 잘 흡수하지 못하고 시간이 지나도 그 경험이 쌓여 배우지 않는다고 지적함.
  16. 그래서 만든 것이 에이전트 스킬이라고 함. 스킬은 에이전트를 위해 조립 가능한(composable) 절차 지식(procedural knowledge)을 담아 정리한 파일 묶음, 다르게 말하면 그냥 폴더라고 함.
  17. 이 단순함은 의도된 것으로, 사람이든 에이전트든 컴퓨터만 있으면 누구나 만들고 쓸 수 있게 하려는 것이라고 함.
  18. 스킬은 기존에 쓰던 방식과도 그대로 맞물린다고 함. 깃(Git)으로 버전을 관리하거나 구글 드라이브(Google Drive)에 올리거나 압축해서 팀에 공유할 수 있고, 파일이라는 원시적인 도구를 수십 년간 써 왔기에 굳이 새 형식을 만들 이유가 없었다고 함.
  19. 스킬 안에는 스크립트를 도구로 담을 수 있다고 함. 기존 툴은 지침이 애매하고, 모델이 막혔을 때도 그 툴 자체를 못 고쳐 콜드 스타트(cold start, 매번 처음부터 다시 시작하는 상태) 문제에 갇힌다고 지적함.
  20. 그런 지침은 늘 컨텍스트 윈도(context window, 모델이 한 번에 참고할 수 있는 입력 범위)를 차지한다고 함. 코드는 이 문제를 푸는데, 스스로 설명이 되고(self-documenting) 고칠 수 있고 필요할 때까지 파일시스템에 그냥 놔둘 수 있다는 것임.
  21. 실제 사례로, 클로드가 슬라이드에 스타일을 입히는 같은 파이썬 스크립트를 매번 새로 쓰는 걸 계속 봤다고 함. 그 스크립트를 스킬 안에 저장해 미래의 자신을 위한 도구로 쓰게 시켰더니 결과가 훨씬 일관되고 효율적이었다고 함.
  22. 스킬 안에 정보가 많이 들어갈 수 있다 보니 컨텍스트 윈도를 지켜서 스킬 수백 개를 한꺼번에 담고 진짜로 조립 가능하게 만들고 싶었다고 함. 그래서 스킬은 점진적 공개(progressive disclosure, 필요한 만큼만 단계적으로 정보를 드러내는 방식)로 동작한다고 함.
  23. 실행 중에는 스킬이 있다는 걸 알려주는 메타데이터만 모델에 보여준다고 함. 에이전트가 그 스킬을 실제로 써야 할 때가 되면 나머지 스킬.md(skill.md)를 읽어 들이는데, 여기에 핵심 지침과 폴더 나머지를 찾는 안내가 담겨 있다고 함.
  24. 그 밖의 파일은 접근하기 쉽게 정리해 둔 것뿐이고, 결국 스킬은 스크립트를 도구로 담은 정리된 폴더, 그게 전부라고 함.
  25. 스킬을 낸 지 다섯 주 만에 이 단순한 설계가 스킬 수천 개짜리 생태계로 빠르게 커졌다고 함. 크게 기초 스킬(foundational skill), 생태계 파트너가 만든 서드파티 스킬, 기업·팀 내부 스킬 세 갈래로 나뉜다고 함.
  26. 기초 스킬은 에이전트에게 없던 일반 능력이나 도메인별 능력을 새로 준다고 함. 앤트로픽은 클로드가 전문적인 품질의 오피스 문서를 만들고 고칠 수 있게 하는 문서 스킬을 직접 만들었다고 함.
  27. 케이던스(Cadence)는 클로드에게 EHR(전자의무기록) 데이터 분석과 파이썬 생물정보학 라이브러리를 전보다 더 잘 쓰는 능력을 주는 과학 연구 스킬을 만들었다고 함.
  28. 생태계 파트너들은 클로드가 자기네 소프트웨어·제품을 더 잘 다루도록 스킬을 만들기도 한다고 함. 브라우저베이스(Browserbase)가 오픈소스 브라우저 자동화 도구 스테이지핸드(Stagehand)용 스킬을 만든 게 그 예임.
  29. 이 스킬과 스테이지핸드를 갖춘 클로드는 웹을 돌아다니며 브라우저를 더 효과적으로 다뤄 일을 처리할 수 있게 됐다고 함. 노션(Notion)도 클로드가 노션 워크스페이스(workspace)를 더 잘 이해하고 전체를 훑어 심층 조사를 하게 해 주는 스킬을 여럿 냈다고 함.
  30. 가장 흥분되는 지점은 대형 기업 안에서 나오는 반응이라고 함. 회사·팀마다 자기 것으로 만든 스킬임.
  31. 포춘 100(Fortune 100) 기업들과 이야기를 나눠 보니 조직의 모범 사례와 내부에서만 쓰는 독특한 사내 소프트웨어 쓰는 법을 에이전트에게 가르치는 수단으로 스킬을 쓰고 있다고 함.
  32. 개발자 수천~수만 명을 상대하는 대형 개발자 생산성 팀들도 클로드 코드 같은 에이전트를 배치하면서 코드 스타일 모범 사례와 내부 작업 방식을 가르치는 데 스킬을 쓴다고 함. 만드는 사람도 쓰임새도 제각각이지만 누구나 만들 수 있고 없던 능력을 준다는 게 공통점이라고 함.
  33. 생태계가 커지면서 눈에 띈 흐름 셋을 짚음. 첫째, 스킬이 점점 복잡해진다고 함. 가장 단순한 스킬은 여전히 프롬프트 몇 줄 담긴 스킬.md 하나지만, 소프트웨어·실행파일·바이너리·코드·스크립트·에셋까지 담는 스킬도 늘고 있다고 함.
  34. 지금은 몇 분에서 몇 시간이면 만드는 스킬이 많지만, 앞으로는 다른 소프트웨어처럼 몇 주에서 몇 달씩 걸려 만들고 유지보수해야 하는 스킬이 늘어날 것이라고 함.
  35. 둘째, 스킬 생태계가 올해 쌓인 MCP 서버 생태계를 보완하고 있다고 함. 개발자들은 MCP 툴 여러 개를 엮어 워크플로로 오케스트레이션하는 스킬을 만들고 있고, MCP는 바깥세상으로 이어지는 연결을 맡고 스킬은 전문성을 맡는다고 정리함.
  36. 셋째이자 개인적으로 가장 흥분되는 지점은, 재무·채용·회계·법무처럼 코딩을 하지 않는 사람들이 스킬을 직접 만들고 있다는 것이라고 함.
  37. 스킬이 코딩을 안 하는 사람도 범용 에이전트를 확장하게 해서 각자 일상 업무에 맞게 에이전트를 더 다가가기 쉽게 만든다는 초기 가설이 검증되고 있다고 함.
  38. 이걸 하나로 묶어 범용 에이전트의 새 아키텍처로 정리함. 모델의 내부 맥락과 토큰 출입을 관리하는 에이전트 루프(agent loop)와, 파일시스템과 코드 읽고 쓰는 능력을 주는 런타임 환경이 결합하는 구조로 수렴하고 있다고 함.
  39. 이 에이전트는 MCP 서버에 연결될 수 있는데, 이는 바깥세상의 툴과 데이터를 가져와 에이전트를 더 유의미하고 효과적으로 만든다고 함.
  40. 이제 같은 에이전트에게 수백~수천 개짜리 스킬 라이브러리를 줄 수 있고, 에이전트는 특정 과제를 하기로 결정한 실행 시점에만 필요한 스킬을 맥락으로 끌어온다고 함. 새 도메인에서 새 능력을 주는 일은 알맞은 MCP 서버 조합과 알맞은 스킬 라이브러리를 갖춰 주는 일로 줄어들 수 있다는 것임.
  41. 이 패턴(에이전트+MCP 서버+스킬 묶음)은 벌써 앤트로픽이 클로드를 새 업종에 배치하는 데 쓰이고 있다고 함. 스킬을 낸 지 다섯 주 만에 금융 서비스와 생명과학(life sciences) 분야 신규 서비스를 곧바로 냈다는 것임.
  42. 각 서비스는 그 도메인 전문가에게 클로드를 곧바로 더 효과적으로 만들어 주는 MCP 서버 묶음과 스킬 묶음을 함께 냈다고 함.
  43. 스킬이 더 복잡해지는 만큼 앞으로 풀어야 할 질문도 있다고 함. 개발자·기업·스킬 제작자를 도우려면 스킬을 소프트웨어처럼 다뤄야 한다며 테스트와 평가, 알맞은 때에 알맞은 과제로 스킬을 불러오게 하는 툴링, 출력 품질을 재는 툴링을 살피겠다고 함.
  44. 버전 관리에도 집중하고 싶다고 함. 스킬이 진화하고 그에 따라 에이전트 행동도 바뀔 텐데, 이걸 또렷하게 추적하고 시간에 따른 계보를 남기고 싶다는 것임.
  45. 스킬끼리 서로 의존하거나 MCP 서버·에이전트 환경 안의 의존성·패키지를 명시적으로 참조하게 만드는 것도 탐구하겠다고 함. 이게 여러 런타임 환경에서 에이전트를 훨씬 예측 가능하게 만들 것이라고 함.
  46. 스킬 여러 개를 조합하는 능력이 클로드 같은 에이전트에게서 더 복잡하고 적절한 행동을 끌어내는 데 도움이 될 것이라고 함. 이런 것들이 갖춰지면 스킬은 클로드뿐 아니라 다른 에이전트 제품에도 더 쉽게 만들고 통합할 수 있게 될 것이라고 함.
  47. 스킬 가치의 큰 부분은 공유와 배포에서 나올 것이라고 함. 그리는 미래상은 조직 안에서 사람과 에이전트가 함께 큐레이션하는, 집단적이고 계속 진화하는 능력 지식 베이스라고 함.
  48. 스킬은 에이전트가 쓸모 있는 일을 하는 데 필요한 절차 지식을 준다고 함. 사람이 피드백과 조직 지식을 더할수록 그 에이전트뿐 아니라 팀·조직 안 모든 에이전트가 함께 나아진다는 것임.
  49. 그래서 누군가 팀에 새로 합류해 클로드를 처음 쓰는 순간에도, 클로드는 이미 그 팀이 뭘 중요하게 여기는지, 일상이 어떤지, 어떻게 해야 가장 도움이 되는지를 알고 있게 된다고 함.
  50. 이 복리 효과는 조직 안에만 머물지 않고 더 넓은 커뮤니티로도 뻗어 나간다고 함. 누군가 세계 어딘가에서 만든 MCP 서버가 내 에이전트를 더 쓸모 있게 만들어 주듯, 커뮤니티가 만든 스킬도 내 에이전트를 더 능력 있고 믿을 만하게 만든다는 것임.
  51. 이 진화하는 지식 베이스라는 비전은 클로드 스스로 스킬을 만들기 시작할 때 더 힘을 받는다고 함. 스킬을 지속적인 학습(continuous learning)으로 가는 구체적인 발걸음으로 설계했다는 것임.
  52. 이 표준화된 형식은 클로드가 적어 둔 것은 무엇이든 미래의 자기 자신이 효율적으로 쓸 수 있다는 보장을 주고, 이게 배움을 진짜로 이어지게 만든다는 것임.
  53. 맥락이 쌓일수록 스킬은 기억(memory)이라는 개념을 더 손에 잡히게 만든다고 함. 다만 모든 걸 담지는 않고 특정 과제에 쓸 절차 지식만 담는다는 것임.
  54. 클로드와 오래 일해 본 사람일수록 스킬의 유연함이 더 중요해진다고 함. 클로드는 새 능력을 즉시 습득하고 필요하면 진화시키고 쓸모없어지면 버릴 수 있다는 것임.
  55. 이건 원래부터 알던 사실이라고 함. 맥락 내 학습(in-context learning)의 힘은 날마다 바뀌는 정보를 다루는 데 훨씬 값싸다는 것임.
  56. 목표는 클로드와 함께 일한 지 30일째가 첫날보다 훨씬 나아지는 것이라고 함. 클로드는 이미 스킬 크리에이터(skill creator) 스킬로 스스로 스킬을 만들 수 있고, 이 방향을 계속 밀고 나가겠다고 함.
  57. 마무리로 컴퓨팅 역사에 빗대는 비유를 듦. 모델은 프로세서(processor)와 같아서 막대한 투자와 엄청난 잠재력을 필요로 하지만 그 자체로는 쓸모가 제한적이라고 함.
  58. 그다음 나온 운영체제(operating system)는 프로세서 주변의 프로세스·자원·데이터를 오케스트레이션해서 프로세서를 훨씬 값지게 만들었고, AI에서는 에이전트 런타임이 이 역할을 맡기 시작했다고 함.
  59. 다들 모델에 알맞은 토큰을 넣고 빼내기 위해 가장 깔끔하고 효율적이고 확장 가능한 추상화를 만들려 애쓰고 있다고 함. 하지만 플랫폼이 갖춰지고 나면 진짜 가치는 애플리케이션에서 나온다고 함.
  60. 프로세서와 운영체제를 만든 회사는 소수였지만, 도메인 전문성과 저마다의 관점을 코드로 담아낸 소프트웨어를 만든 개발자는 수백만 명이었다는 것임.
  61. 스킬이 이 응용 계층을 모두에게 열어 주길 바란다고 함. 폴더에 뭔가를 넣는 것만으로 자기 자신과 서로와 세상을 위해 구체적인 문제를 풀 수 있는 창의적인 자리이며, 스킬은 그저 출발점일 뿐이라고 함.
  62. 이제 범용 에이전트를 위한 이 일반 아키텍처로 수렴하고 있다고 정리하며, 새 능력을 내놓고 공유하는 새 패러다임으로 스킬을 만들었으니 에이전트를 다시 만드는 일은 그만두고 대신 스킬을 만들 때라며 발표를 마침.

한줄 코멘트. 세금 신고 비유는 산뜻하지만 정작 스킬 자체가 좋은지 어떻게 재는지는 이 발표에서 안 다뤘음 — 그 답은 같은 자리에 있던 다른 발표(평가 없이 스킬을 내보내지 마라)로 넘어감.

  1. 발표자는 케이틀린 레스(Katelyn Lesse)로, 앤스로픽(Anthropic)에서 클로드(Claude) 개발자 플랫폼 팀을 이끈다고 밝힘.
  2. 청중에게 LLM(거대 언어 모델) API를 붙여 에이전트를 만들어본 적 있는지 손을 들어보라고 물었고, 대다수가 손을 들었다고 함.
  3. 오늘은 앤스로픽이 강력한 에이전트 시스템을 만들 수 있도록 플랫폼을 어떻게 진화시키고 있는지 이야기하겠다고 함.
  4. 앤스로픽이 함께 일하고 싶어하는 개발자는 "지능의 천장을 높이는" 사람들, 즉 늘 프런티어에 서서 모델에서 최대치를 뽑아내려는 사람들이라고 함.
  5. 그 사례로 클로드 코드(Claude Code)라는 에이전트형 코딩 제품을 들어 플랫폼이 어떻게 작동하는지 설명하겠다고 함.
  6. 모델 성능을 최대로 끌어내는 플랫폼은 세 가지를 돕는다고 정리함.
  7. 첫째는 클로드의 능력을 그대로 쓰게 하는 것이라고 함.
  8. 둘째는 클로드의 컨텍스트 창(context window, 모델이 한 번에 참고하는 정보 범위)을 관리하는 것이라고 함.
  9. 셋째는 클로드에 컴퓨터를 맡기고 알아서 하게 두는 것이라고 함.
  10. 첫 번째로, 능력을 활용하게 하는 예로 사고(thinking)를 듦. 클로드가 문제를 추론하는 데 쓰는 시간이 늘수록 여러 과제에서 성능이 올라간다고 함.
  11. 이를 API 기능으로 노출해, 복잡한 문제엔 더 오래 생각하게 하고 간단한 문제엔 바로 답하게 하는 선택을 개발자가 할 수 있게 했다고 함.
  12. 사고에 쓸 토큰 예산도 지정할 수 있다고 함.
  13. 클로드 코드는 복잡한 디버깅엔 더 오래 생각하게 하고 간단한 질문엔 빠르게 답하도록 이 기능을 활용한다고 함.
  14. 두 번째 예로 든 것은 도구 호출(tool use)임. 클로드가 도구를 신뢰성 있게 부르는 데 능숙해졌다고 함.
  15. API에는 웹 검색 같은 내장 도구뿐 아니라 이름·설명·입력 스키마만 정의하면 되는 커스텀 도구도 만들 수 있게 했다고 함.
  16. 클로드 코드는 파일을 읽고 검색하고 쓰고 테스트를 다시 돌리는 등 수많은 도구를 계속 불러 쓰는 사례라고 함.
  17. 두 번째 축은 컨텍스트 창 관리로, 적절한 정보를 적절한 시점에 창 안에 두는 일이 성능을 좌우하는 핵심이라고 함.
  18. 코딩 에이전트인 클로드 코드는 기술 설계·전체 코드베이스·지시사항·도구 호출 결과까지 한꺼번에 창에 걸릴 수 있어 이 관리가 특히 까다롭다고 함.
  19. 첫 번째 도구는 MCP(모델 컨텍스트 프로토콜, Model Context Protocol)로, 1년 전 도입한 뒤 에이전트가 외부 시스템과 상호작용하는 표준 방식으로 커뮤니티에 널리 퍼졌다고 함.
  20. 클로드 코드라면 깃허브(GitHub)처럼 에이전트의 창 바깥에 있는 정보·도구에 MCP로 접근하게 해, 프롬프트만으로는 못 주는 성능을 끌어낸다고 함.
  21. 두 번째 도구는 메모리(memory)로, 창 밖에 정보를 보관해뒀다가 클로드가 필요할 때만 다시 끌어오게 만든 기능이라고 함.
  22. 첫 버전의 메모리 툴은 클라이언트 쪽 파일 시스템 형태로, 데이터는 사용자가 쥐고 있다고 함.
  23. 클로드가 나중에 쓸 만한 것을 스스로 골라 저장해뒀다가, 필요할 때만 다시 불러온다고 함.
  24. 클로드 코드에서는 코드베이스의 패턴이나 깃(Git) 작업 방식에 대한 선호처럼, 관련 있을 때만 꺼내 쓸 정보를 메모리에 저장해둘 수 있다고 함.
  25. 세 번째 도구는 컨텍스트 편집(context editing)으로, 메모리가 필요할 때 정보를 불러오는 쪽이라면 이건 지금 필요 없는 걸 창에서 지우는 쪽이라고 함.
  26. 첫 버전의 컨텍스트 편집은 오래된 도구 호출 결과를 지우는 것이라고 함.
  27. 이런 결과가 용량은 크면서 이후 응답에는 별로 도움이 안 된다는 걸 내부적으로 확인했다고 함.
  28. 클로드 코드는 도구를 수백 번씩 부르기 때문에 읽었던 파일 등이 창을 계속 채우는데, 컨텍스트 편집으로 이런 것들을 정리한다고 함.
  29. 메모리 툴과 컨텍스트 편집을 함께 썼더니 앤스로픽 내부 평가 벤치마크에서 성능이 39% 올랐다고 밝힘.
  30. 이 수치는 그때그때 필요한 것만 창에 남기는 일이 얼마나 중요한지 보여준다고 함.
  31. 일부 모델은 최대 100만 토큰까지 컨텍스트 창을 키워, 큰 창과 편집 도구를 함께 쓰면 성능이 더 올라간다고 함.
  32. 시간이 지나며 클로드는 자기 창에 여유가 얼마나 남았는지를 스스로 더 잘 파악하도록 훈련되고 있고, 남은 공간에 맞춰 행동을 바꾼다고 함.
  33. 세 번째 축은 클로드에 컴퓨터를 주고 알아서 하게 두는 것으로, 요즘 팀이 가장 신이 나 있는 부분이라고 함.
  34. 에이전트 하네스(harness, 모델을 감싸 도구를 쓰게 만드는 실행 틀)를 얼마나 무겁게 또는 가볍게 짤지에 대한 논쟁이 업계에 많다고 언급함.
  35. 클로드가 코드를 쓸 수 있고 그 코드를 직접 실행까지 할 수 있다면, 사람이 붙어 있지 않아도 전문가 수준의 결과물을 낼 수 있다는 게 발표자의 결론이라고 함.
  36. 다만 이걸 가능하게 하려면 인프라와 노하우가 필요한데, 컴퓨터를 쓸 때 클로드에 뭘 어디까지 허용해야 더 나은 결과가 나오는지가 관건이라고 함.
  37. 예로 최근 출시한 클로드 코드 웹·모바일판 이야기를 듦.
  38. 로컬에서 돌릴 땐 사용자 컴퓨터가 곧 클로드의 실행 환경이지만, 웹이나 모바일에서 세션을 시작하고 자리를 뜨면 그 실행이 어디서 이뤄지는지가 문제였다고 함.
  39. 사용자가 미리 승인하지 않은 코드까지 클로드가 쓰고 돌릴 수 있는 안전한 환경이 필요했다고 함.
  40. 대규모 컨테이너 오케스트레이션과, 사용자가 다시 돌아왔을 때 결과가 그대로 남아 있게 하는 세션 지속성까지 함께 풀어야 했다고 함.
  41. 이를 위한 핵심 요소가 코드 실행 도구(code execution tool)로, API에 공개해 클로드가 코드를 쓰고 보안 샌드박스 환경에서 그 코드를 직접 돌릴 수 있게 했다고 함.
  42. 컨테이너와 보안은 앤스로픽 서버에서 플랫폼이 대신 처리하기 때문에 개발자가 따로 신경 쓸 필요가 없다고 함.
  43. 클로드 코드에서는 "애니메이션을 좀 더 반짝이게 고쳐줘" 같은 요청처럼, 클로드가 쓴 코드를 클로드가 직접 실행까지 해봐야 하는 경우가 많다고 함.
  44. 앤스로픽은 모델이 샌드박스 환경 안에서 상당히 자율적으로 일하게 두는 쪽이 에이전트의 미래라고 보고, 그 인프라를 계속 만들어가고 있다고 함.
  45. 여기에 도메인 전문성까지 얹으면 훨씬 강력해진다며, 최근 공개한 에이전트 스킬(agent skills)을 코드 실행 도구와 함께 소개함.
  46. 스킬(skill)은 스크립트·지시문·자료를 모아둔 폴더로, 클로드가 샌드박스 안에서 필요할 때 골라 실행할 수 있는 형태라고 설명함.
  47. 클로드는 사용자의 요청 내용과 스킬 설명을 보고, 지금이 이 스킬을 끌어와 쓸 때인지 스스로 판단하는 데 능숙하다고 함.
  48. MCP가 도구와 맥락에 접근하는 통로라면, 스킬은 그 도구와 맥락을 실제로 어떻게 다뤄야 하는지에 대한 전문성이라 둘을 같이 쓸 수 있다고 함.
  49. 클로드 코드 예로, 새 제품이나 기능을 낼 때마다 만드는 랜딩 페이지를 들어 디자인 시스템과 정해둔 패턴을 따르게 하려면, 클로드가 알아서 웹 디자인 스킬을 끌어와 쓴다고 함.
  50. 스킬을 더 깊이 다루는 발표는 다음날 배리(Barry)와 마헤스가 따로 한다며 청중에게 권함.
  51. 발표를 정리하며, 능력을 API로 열어주고 컨텍스트 창을 깨끗하게 관리하고 컴퓨터를 맡기는 세 가지가 플랫폼이 하는 일이라고 다시 짚음.
  52. 앞으로 클로드가 더 많은 능력을 갖추고 기존 능력에서도 더 나아질수록, 그에 맞춰 API도 계속 진화시키겠다고 함.
  53. 메모리와 컨텍스트가 발전할수록 무엇을 창에 끌어오고 무엇을 나중을 위해 저장하고 무엇을 지울지를 클로드가 스스로 판단하게 하는 도구도 계속 강화하겠다고 함.
  54. 마지막으로 에이전트 인프라에 계속 힘을 쏟겠다며, 오케스트레이션·보안 환경·샌드박싱 같은 문제가 여전히 크다고 인정함.
  55. 발표 끝에 앤스로픽이 제품 디자인·개발자 관계(DevRel) 등 여러 직무에서 채용 중이라고 밝히며 마무리함.

한줄 코멘트. 39% 성능 향상의 재료는 새 기능이 아니라 메모리와 컨텍스트 편집을 묶어 창에서 필요 없는 걸 걷어낸 것이고, 이 팀이 지금 힘을 쏟는 곳도 결국 컨텍스트를 비우는 인프라임.

  1. 발표자는 케빈 허우(Kevin Hou)로, 구글 안티그래비티(Antigravity)의 제품 엔지니어링 팀을 이끈다고 밝힘.
  2. 안티그래비티는 이번 주 화요일 제미나이(Gemini) 3 프로와 함께 나온, 구글 딥마인드가 처음으로 내놓은 통합 개발 환경(IDE)이라고 소개함.
  3. 발표 제목 "중력을 거스르다"는 이번 주 나온 IDE 이름 안티그래비티(반중력)에서 따온 말장난이라고 밝힘.
  4. 안티그래비티는 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 우선을 표방한다고 함.
  5. 제품은 편집기·브라우저·에이전트 매니저 세 가지 화면으로 이뤄져 있다고 설명함.
  6. 에이전트 매니저는 코드 diff(변경 전후 비교)를 들여다보는 대신 한 단계 물러나 에이전트를 보는 중심 화면이고, 한 번에 하나만 뜬다고 함.
  7. 편집기는 비주얼 스튜디오 코드(VS Code)를 포크한 것으로, 빠른 자동완성과 에이전트 사이드바를 갖췄다고 밝힘.
  8. 커맨드 또는 컨트롤+E 키로 편집기와 에이전트 매니저를 100밀리초 안에 오갈 수 있다고 함.
  9. 에이전트가 직접 조작하는 크롬 브라우저가 세 번째 화면이며, 평소 크롬과 같은 로그인 상태로 구글 문서·깃허브 대시보드에 접근할 수 있다고 설명함.
  10. 이 브라우저는 에이전트가 클릭·스크롤·자바스크립트 실행까지 직접 해서 앱을 테스트하는 데도 쓴다고 함.
  11. 시연에서는 새로고침할 때마다 토머스 콜(Thomas Cole) 작품이 바뀌는 아트워크 생성기에 모달 카드 기능을 추가했다고 함.
  12. 이때 에이전트가 코드 diff 대신 마우스가 파란 점으로 움직이는 크롬 녹화 화면을 결과로 보여줬다고 함.
  13. 에이전트 매니저에는 받은편지함(inbox)이 있어 여러 에이전트를 한 번에 관리하고, 터미널 명령 실행처럼 승인이 필요한 일을 여기로 모은다고 함.
  14. 운영체제 수준 알림도 지원해 여러 작업을 동시에 다루는 문제를 푼다고 설명함.
  15. 안티그래비티는 제미나이 3와 함께 출시했는데 용량이 부족했다며 "전 세계적 칩 부족"이라 농담 삼아 사과함.
  16. 이 컨퍼런스에 여러 번 왔는데 매번 반복되는 주제가 있다며, 제품의 수준은 그 제품을 움직이는 모델의 수준을 넘지 못한다고 짚음.
  17. 해마다 모델 능력이 바뀔 때마다 제품 패러다임도 바뀌었다고 설명함.
  18. 코파일럿(Copilot)의 자동완성, 그다음 인간 피드백 기반 강화학습(RLHF)으로 다듬은 챗, 그다음 에이전트 순서로 바뀌었다고 함.
  19. 팀이 딥마인드 안에 있어 제미나이를 몇 달 먼저 써 보며 리서치 팀과 함께 제품에서 보여줄 강점과 메워야 할 모델의 빈틈을 같이 짚었다고 함.
  20. 나노 바나나(Nano Banana) 아트워크로 표현한 개선 네 범주는 지능·추론, 도구 사용, 더 긴 작업 수행, 멀티모달이라고 함.
  21. 지시 따르기와 도구 사용이 좋아져 브라우저 안에서 할 수 있는 수많은 일의 미묘한 차이까지 다룰 수 있게 됐다고 함.
  22. 모델이 더 오래 생각하고 더 긴 작업을 백그라운드에서 돌릴 수 있게 됐다고 설명함.
  23. 제미나이 3의 멀티모달 기능이 크게 좋아졌고, 나노 바나나 프로(Nano Banana Pro)와 결합하면 마법 같은 결과가 나온다고 함.
  24. 이 네 가지 변화를 어떻게 제품으로 담아낼지가 관건이었고, 자동완성-챗-에이전트 다음의 새로운 단계라고 스스로 평가함.
  25. 첫 번째 원칙은 능력의 천장을 끌어올리는 것, 더 높은 야심을 갖는 것이라고 함.
  26. 딥마인드 안 여러 팀이 각자 어려운 연구 문제를 붙잡고 있고, 그 결과물 중 하나로 브라우저를 통한 컴퓨터 사용(computer use)이 큰 돌파구가 됐다고 함.
  27. 소프트웨어 개발은 무엇을 만들지, 어떻게 만들지, 실제로 만드는 일 셋으로 나뉜다고 함.
  28. 모델은 이제 맥락만 주어지면 실제로 만드는 일은 웬만큼 해낸다고 함.
  29. "무엇을 만들지"는 사람의 상상력 영역이고, "어떻게 만들지"는 버그 대시보드·실험 기록 같은 조직 내부 지식과 맥락의 풍부함이라고 설명함.
  30. 브라우저 접근은 이 맥락을 채우는 동시에 결과를 검증하는 수단이라고 함.
  31. 항공편 아이디를 넣으면 출발·도착 정보를 보여주는 시연을 튜토리얼 영상으로 보여줬다고 함.
  32. 이 시연은 제미나이 컴퓨터 사용 변형 모델이 화면 파란 테두리로 표시된 채 클릭·스크롤·DOM(문서 객체 모델, 웹페이지 구조를 트리로 표현한 것) 읽기까지 전부 직접 했다고 함.
  33. 결과로 diff 대신 화면 녹화 영상이 나오고, 모델이 이미지를 이해하는 능력으로 그 녹화를 보고 다시 고칠 수 있다고 설명함.
  34. 두 번째로 시간을 들인 영역은 이미지 생성이라며, 나노 바나나 2가 소비자용으로도 개발자용으로도 놀라운 결과를 냈다고 함.
  35. 개발자는 텍스트만이 아니라 웹사이트 화면·아키텍처 다이어그램 같은 이미지를 늘 들여다보는 멀티모달 작업을 이미 하고 있었다고 짚음.
  36. 목업(mockup) 시연에서는 웹사이트를 이미지 상태에서 바로 만들고, 깃허브(GitHub)처럼 코멘트를 남기면 에이전트가 그걸 반영해 디자인을 고친다고 보여줌.
  37. 나노 바나나 프로는 출시 첫날 안티그래비티 편집기 안에 곧바로 들어갔고, 팀이 밤을 새워 그 작업을 맞췄다고 함.
  38. 두 번째 원칙은 새로운 상호작용 방식, 즉 "아티팩트(artifact)"라고 부르는 개념이라고 소개함.
  39. 아티팩트는 에이전트가 사용자를 위해 만들어내는 동적인 정보 표현이며, "동적"이라는 점이 핵심이라고 정의함.
  40. 아티팩트는 에이전트 스스로 정리하는 용도, 사용자에게 스크린샷·화면 녹화로 보여주는 용도, 다른 에이전트나 대화·기억에 걸쳐 쓰는 용도로 쓰인다고 함.
  41. 대화의 사고 과정(chain of thought)을 청크로 나눠 보여줘도 결국 토큰 문자열 뭉치를 계속 스크롤하며 확인하게 된다고 지적함.
  42. 발표를 생각나는 대로 말하기 대신 파워포인트로 하는 것처럼, 시각적 표현이 대화 로그보다 이해하기 쉽다는 게 아티팩트의 요점이라고 함.
  43. 모델은 아티팩트를 만들지 말지부터 스스로 판단한다며, 제목만 바꾸는 것 같은 작은 작업엔 아티팩트를 만들지 않는다고 함.
  44. 어떤 종류의 아티팩트를 만들지도 모델이 정하며, 잠재적으로 무한히 다양한 형태로 정보를 표현할 수 있다고 함.
  45. 가장 흔한 형태는 마크다운으로 쓰는 계획서와 워크스루(walkthrough)로, 제품요구사항문서(PRD)에 가깝고 미해결 질문까지 나열한다고 함.
  46. 미해결 질문이 없으면 모델이 스스로 판단해 바로 이어서 진행하고, 있으면 답을 구하려고 멈춘다고 함.
  47. 할 일 목록(task list) 아티팩트로 대화를 다시 읽지 않고도 진행 상황을 확인할 수 있다고 함.
  48. 아키텍처 다이어그램을 만들기도 하고, 작업 끝에는 코드 변경 요청(PR) 설명글처럼 결과를 사람에게 증명하는 워크스루가 나온다고 설명함.
  49. 그 밖에 이미지·화면 녹화·머메이드(mermaid, 마크다운 문법으로 그리는 순서도) 다이어그램 등 다양한 형태가 있다고 함.
  50. 모델이 시간이 지나며 새로운 아티팩트 형태를 스스로 만들어내기도 해서 확장성이 크다고 함.
  51. 아티팩트마다 왜 필요한지 사용자에게 설명하고, 서브 에이전트·다른 대화·기억 저장소 중 누가 이걸 봐야 하는지도 함께 판단한다고 함.
  52. 예로 문서와 API 키를 주면 에이전트가 직접 curl 요청을 보내 API 스키마를 알아내는 딥 리서치를 한 뒤, 그 결과를 기억에 저장해 다음번엔 지식 기반으로 쓴다고 함.
  53. 미해결 질문이 있으면 알림으로 먼저 사용자에게 다가가는 것도 이 아티팩트 시스템의 특징이라고 함.
  54. 구글 문서(Google Docs)의 코멘트 방식과 깃허브에서 영감을 받아, 텍스트를 하이라이트하고 "테일윈드 대신 바닐라 CSS를 쓰라"는 식으로 코멘트를 남길 수 있다고 함.
  55. 코멘트를 모아뒀다가 한 번에 보내면 실행 흐름을 끊지 않고 에이전트가 자연스럽게 반영한다고 설명함.
  56. 이미지 상태에서도 피그마(Figma)처럼 하이라이트로 영역을 골라 다른 방식으로 코멘트를 남길 수 있다고 함.
  57. 에이전트 매니저는 이런 아티팩트 검토 화면에 공을 들였고, 같은 프로젝트 안에서 디자인 목업·API 조사·실제 구현을 동시에 병렬로 돌리는 것도 지원한다고 함.
  58. 아직 모델을 완전히 믿지 못하는 작업은 커맨드(컨트롤)+E로 곧바로 편집기를 열어 같은 파일·아티팩트·대화 그대로 이어 작업할 수 있는 탈출구를 남겨뒀다고 함.
  59. 발표자는 코드 생성 분야에서 3년 가까이 일하며 배운 교훈이 "스스로 제일 큰 사용자가 되라"는 것이라고 함.
  60. 구글 엔지니어와 딥마인드 연구자들에게 안티그래비티를 먼저 쓰게 했고, 이들이 직접 겪는 경험이 모델의 빈틈을 실시간으로 드러낸다고 설명함.
  61. 컴퓨터 사용 팀과 몇십 피트 떨어진 자리에 앉아, 데이터 분포 문제 같은 모델 쪽 빈틈과 에이전트 하네스(harness, 에이전트가 도구를 쓰고 작업하도록 감싸는 실행 틀) 쪽 문제를 양쪽에서 함께 찾았다고 함.
  62. 모델 쪽 문제는 리서치 팀이, 하네스 쪽 문제는 제품 팀이 각자 맡아 고치는 식으로 풀었다고 설명함.
  63. 아티팩트 개념도 초기 버전 모델에서는 잘 안 됐는데, 훈련 데이터에 "리뷰"라는 개념 자체가 부족했던 게 원인이라고 짚음.
  64. 리서치 팀과 함께 단계적으로 개선해 제미나이 3 프로에서는 아티팩트를 잘 다루게 만들었다고 함.
  65. 이렇게 제품과 리서치가 맞물려 돌아가는 순환 구조가 안티그래비티를 계속 밀어올릴 것이라고 함.
  66. 정리하면 능력의 천장을 올리는 것, 아티팩트·에이전트 매니저로 에이전트 우선 경험을 만드는 것, 리서치-제품 플라이휠 세 단계로 안티그래비티를 만들었다고 함.
  67. 다만 바이브 코딩(vibe coding, 세세한 코드보다 원하는 결과를 말로 지시해 만드는 방식) 말고도 AI 스튜디오(AI Studio) 같은 구글의 다른 훌륭한 제품도 있다고 짚음.
  68. 마지막으로 AI 엔지니어 서밋 주최자인 스윅스(Swix)와 벤(Ben)에게 감사를 전하며, 팀이 이 제품을 세상에 내놓게 돼 기쁘다고 소감을 밝힘.

한줄 코멘트. 아티팩트는 대화 로그를 안 보이게 감싼 장치일 뿐, 그 판단을 모델에 맡길 수 있다는 확신은 결국 구글 직원들이 먼저 써보며 만든 것임.

  1. 발표자는 오스트레일리아 퀸즐랜드 출신으로 아마존웹서비스(AWS) 개발자 애드보킷을 맡고 있는 마이크 챔버스(Mike Chambers)이며, 예전엔 머신러닝이었지만 지금은 생성형 AI만 다룬다고 소개함.
  2. 이 발표에서 코드를 보여주고 그 코드를 어떻게 프로덕션까지 가져가는지 다룬다며, 개발자에게는 직접 코드를 클라우드 스케일로 올리는 법이고 리더에게는 팀원이 그렇게 하도록 만드는 법이라고 설명함.
  3. 몇 년 전 앤드류 응(Andrew Ng)과 AWS 동료들이 함께 만든 강좌 "대규모 언어 모델의 기초"에 참여한 경험을 소개하며, 이 강좌를 지금까지 37만 명 넘게 들었고 이런 종류로는 최초였다고 밝힘.
  4. 먼저 정말 단순한 예시부터 보여준다며, 프레임워크 하나 없이 파이썬 함수 하나·파일 하나로 짠 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)를 시연에 쓴다고 함.
  5. 이 로컬 에이전트는 자기 노트북에서 도는 라마(Llama) 3.1 80억 파라미터 모델을 쓰는데, 프레임워크가 없어 오히려 비효율적이라고 인정함.
  6. 에이전트가 가진 도구는 하나뿐이고, 주사위를 굴리는 난수 생성기를 "다이스 롤러"라고 부른다고 함.
  7. 시스템 프롬프트에 어떤 도구를 쓸 수 있는지 알려주고, 사용 예시까지 넣어뒀다고 함. 모델이 워낙 작아서 도구 쓰는 법을 손으로 잡아줘야 한다고 이유를 밝힘.
  8. 예시로 쓴 D20(20면체 주사위)을 굴리는 법을 넣었다며, D20이 이후에도 계속 나올 용어라고 짚음.
  9. 터미널에서 로컬로 이 코드를 직접 돌려 시연함. "이니셔티브를 굴리고 민첩 보정치 5를 더해줘"라는 자연어 명령을 입력함.
  10. 에이전트가 자연어를 이해해 어떤 도구가 필요한지 판단하고 다이스 롤러를 호출해 실행한 뒤, d20을 굴려 10이 나오고 5를 더해 15라는 결과를 냈다고 함.
  11. 이 단순한 난수 생성기가 에이전트의 구조와 동작 방식을 보여주는 좋은 예라고 정리하며, 이제 노트북 규모의 이 코드를 클라우드 스케일로, 프로덕션이 가능하게 만들겠다고 함.
  12. 에이전트를 클라우드로 올리려면 갖춰야 할 구성요소를 자기 나름의 최소 목록으로 정리해 보여줌.
  13. 첫째는 모델이라며, 이미 만들어져 있어 가져다 쓰면 되니 자연어 이해 능력을 확보하는 일은 오히려 쉬운 축에 든다고 함.
  14. 둘째는 프롬프트라며, 에이전트가 왜 존재하고 무엇을 할 수 있는지, 즉 성격을 설명해주는 역할이라고 함.
  15. 셋째는 루프, 즉 에이전틱 루프(agentic loop)라며, 입력을 보고 처리한 뒤 도구를 쓰고 그 도구가 질문에 답했는지 평가해서 필요하면 다시 도는 구조라고 설명함.
  16. 이 루프는 결국 while문 하나에 문자열을 이리저리 다루는 수준에 지나지 않지만, 이걸 호스팅해서 클라우드 스케일로 돌리는 게 필요하다고 함.
  17. 넷째는 히스토리라며, 최근 이 주제로 깊은 대화를 몇 번 나눴다고 언급함.
  18. 사람들이 히스토리라고 하면 "어제 물어본 걸 오늘도 기억하는 것" 정도로 생각하는데, 실제로는 그보다 훨씬 깊다고 함.
  19. 질문 하나가 들어오면 에이전트가 추론 단계를 거쳐 무엇을 할지 정하고 도구를 호출하는데, 다음 단계를 진행하려면 방금 한 일을 기억해서 그 맥락 안에서 이어가야 한다고 설명함.
  20. 그래서 대화 히스토리는 낮은 층위에서도 에이전트를 굴리는 데 실제로 핵심적이라고 강조함.
  21. 마지막 다섯째는 도구라며, 에이전트가 바깥세상에서 실제로 뭔가를 할 수 있는 힘(에이전시)을 준다고 함.
  22. 이 밖에도 구성요소가 더 있을 수 있지만, 이 다섯이 에이전트가 최소한으로 갖춰야 할 기본이라고 정리함.
  23. 이제 AWS가 이런 에이전트를 클라우드 스케일로 호스팅하는 법을 보여준다고 함.
  24. 모델 쪽은 이미 앤스로픽(Anthropic)·아마존 노바(Nova)·메타·미스트랄·AI21 랩스 등 여러 공급사 모델이 갖춰져 있어 그냥 가져다 쓰면 된다고 함.
  25. 이 모델들을 애플리케이션에 끼워 넣을 수 있게 해주는 게 아마존 베드록(Amazon Bedrock)이라는 생성형 AI 구성요소 모음이라고 소개함.
  26. 실제 에이전트를 만드는 부분은 아마존 베드록 에이전트가 담당하며, 완전관리형이라 인프라를 따로 관리할 필요 없이 설정만 넣으면 클라우드 스케일로 돈다고 함.
  27. 프로덕션으로 어떻게 가져가느냐는 질문에 대한 답은 결국 이 서비스를 그냥 쓰는 것이라고 함.
  28. 설정 항목 중 "인스트럭션(instruction)"이 에이전트의 성격을 정하는데, 사실상 프롬프트와 같지만 실제로는 프롬프트 템플릿과 합쳐져 최종 프롬프트가 된다고 설명함.
  29. 이 프롬프트 템플릿은 선택한 모델에 따라 기본값이 딸려오지만, 원한다면 직접 편집할 수도 있다고 함.
  30. 앞서 설명한 루프와 대화 히스토리는 전부 이 서비스 안에서 알아서 처리된다고 함.
  31. 다음 설정 단계는 액션 그룹이라며, 도구들을 하나로 묶은 모음이라고 정의함. 다이스 롤러 도구 하나뿐이라 액션 그룹도 하나면 충분하다고 함.
  32. 액션 그룹 안에서 도구를 실제로 실행하는 자리는 람다(Lambda, 서버 관리 없이 코드만 올리면 돌아가는 서비스)라며, 스케일링을 알아서 처리해준다고 함.
  33. 람다로 할 수 있는 일이면 무엇이든 도구가 할 수 있다며, 다른 AWS 서비스 호출·이메일 발송처럼 바깥세상과 닿는 일이 전부 가능하다고 함.
  34. 지금 보여주는 화면은 전부 콘솔 클릭이지만, 실제 프로덕션에 이 방식(ClickOps)으로 배포하진 않는다고 밝힘.
  35. 여기서 보여주는 모든 설정은 테라폼(Terraform)·펄루미(Pulumi)·클라우드포메이션(CloudFormation)·SDK·SAM 같은 코드형 인프라(IaC) 도구로도 똑같이 만들 수 있다고 함.
  36. 콘솔을 쓰는 건 순전히 화면으로 보여주기 편해서라고 이유를 댐.
  37. 실제 화면으로 넘어가 아마존 베드록 콘솔의 에이전트 메뉴에서 "에이전트 만들기"를 클릭하는 것으로 시연을 시작함.
  38. 이름과 설명을 넣는데, 여섯 달 뒤 콘솔에 돌아왔을 때 이 에이전트가 뭐였는지 알 수 있도록 설명을 꼭 채워두는 게 좋은 습관이라고 말함.
  39. "테이블탑 RPG를 함께 플레이하도록 돕는 에이전트"라는 설명을 붙임.
  40. 아래로 스크롤해 모델을 고르는 단계로 가서, 앤스로픽의 클로드 3.5 하이쿠를 선택함. 작고 빠르면서도 충분히 능력 있는 모델이라 이 단순한 에이전트엔 오히려 과분할 정도라고 함.
  41. 인스트럭션 칸에 "너는 테이블탑 RPG 플레이를 도와주는 게임 마스터다"라고 적어 넣음.
  42. 저장한 뒤 다음으로 액션 그룹을 추가하는 단계로 넘어감.
  43. 액션 그룹에도 이름과 설명을 넣는데, 이 설명은 대규모 언어 모델이 읽고 이 도구가 뭘 하는 물건인지 파악하는 데 쓰인다고 설명함.
  44. 이걸 "새로운 프로그래밍 방식"이라고 표현하며, 스키마와 정의를 코드가 아니라 자연어로 써서 LLM이 읽고 판단하게 하는 방식이라고 짚음.
  45. 도구 실행 방식으로 람다를 선택하는데, 권장 옵션이라며 이 퀵스타트를 쓰면 람다 함수 생성부터 권한 설정, 에이전트와의 연결까지 전부 자동으로 처리된다고 함.
  46. 도구 이름을 "roll dice"로 정하고, 이 설명 역시 LLM이 언제 이 도구를 쓸지 판단하는 근거가 된다고 다시 강조함.
  47. 주사위 면 수를 넘길 파라미터를 추가하면서 이름과 설명을 채우고, 정수(integer) 타입으로 지정한 뒤 필수(required) 값으로 설정함.
  48. 생성 버튼을 누르자 실시간으로 람다 함수가 만들어지고 권한까지 자동으로 붙는 걸 보여줌.
  49. 액션 그룹으로 돌아오면 이제 람다 함수로 연결되는 링크가 생겨 있고, 여기에 실제 실행 로직만 넣으면 된다고 함.
  50. 람다 콘솔 안에서 제공된 보일러플레이트 코드에 주사위 굴리는 로직을 빠르게 채워 넣기 시작함.
  51. 코드 편집기 안에 아마존 Q 디벨로퍼가 내장돼 있어 타이핑하는 동안 계속 코드를 제안해준다고 소개함.
  52. `random` 모듈을 임포트하고, 람다에 들어오는 이벤트 안에서 어떤 함수를 호출하는지와 파라미터를 읽어오는 구조를 설명함.
  53. 함수 이름이 "roll dice"일 때 면 수를 가져와 난수를 생성하도록 조건문을 짜 넣음.
  54. 이 시점에서 아마존 Q 디벨로퍼가 이미 무슨 코드를 원하는지 파악해 응답 본문을 만드는 코드를 제안했고, 탭 완성으로 그대로 받아썼다고 함.
  55. 보일러플레이트에 맞춰 들여쓰기만 조금 손본 뒤 배포(deploy) 버튼을 눌러 람다 함수를 저장함.
  56. 에이전트 화면으로 돌아와 "준비(prepare)"를 실행해야 하는데, 여기엔 에이전트와 별개로 별칭(alias) ID가 있어 소프트웨어 개발 생명주기처럼 버전을 나눠 배포할 수 있다고 설명함.
  57. 준비를 마치면 화면 오른쪽 테스트 창에서 바로 질문을 던져볼 수 있다며, 이번엔 모델을 조금 시험해보려고 평소보다 화려한 표현으로 문장을 씀.
  58. 이니셔티브의 철자를 맞게 고친 뒤 질문을 입력하자 에이전트가 다이스 롤러를 호출해 결과를 돌려준다고 함.
  59. 이제 이 에이전트는 완전관리형 환경에 올라가 클라우드 스케일로 동작하는 상태이며, 로컬 데모와 똑같이 15라는 답을 돌려줬다고 함.
  60. 마무리로 딥러닝닷에이아이(deeplearning.ai)의 강좌를 다시 언급하며, 전부 무료이고 아마존 베드록 에이전트를 마음껏 써볼 수 있는 무료 AWS 환경까지 딸려온다고 함.
  61. MCP(모델 컨텍스트 프로토콜, LLM이 외부 데이터·도구에 표준화된 방식으로 접속하게 해주는 개방형 규격)를 클라우드 스케일로 쓰는 이야기를 더 하고 싶으면 따로 찾아와 달라고 함.
  62. 모델 우선(model-first) 에이전트를 만드는 새 오픈소스 SDK도 준비돼 있는데, 이번 발표엔 다룰 시간이 없었다고 밝히며 실물 D20 주사위를 받고 싶으면 엑스포홀의 AWS 부스로 오라고 초대함.

한줄 코멘트. 도구 하나·파라미터 하나짜리 다이스 롤러라 클릭 몇 번으로 프로덕션까지 가는 게 매끈해 보이지만, 도구가 여러 개로 늘거나 실행이 실패했을 때 어떻게 되는지는 이 발표에 안 나옴.

  1. 이 발표는 마이크로소프트 리서치(Microsoft Research) 수석 연구 소프트웨어 엔지니어 빅터 디비아(Victor Dibia)가 AI 엔지니어 컨퍼런스에서 한 것으로, 자기 배경이 인간-AI 상호작용에 있다고 소개함.
  2. 최근 몇 년간 사람이 AI 에이전트와 함께 일하며 문제를 푸는 상황을 계속 들여다봤다고 함.
  3. 마이크로소프트 리서치에서 한 일 중 하나가 깃허브 코파일럿(GitHub Copilot)이고, AI 모델이 대규모로 IDE(통합 개발 환경) 안에서 개발자를 돕는 첫 사례로 본다고 밝힘.
  4. 이후 오픈소스 멀티에이전트 프레임워크 오토젠(AutoGen)에 시간을 썼고, 그 위에 팀을 짜고 에이전트를 끌어다 놓아 모델·툴을 조합하는 로컬 개발자 도구 오토젠 스튜디오(AutoGen Studio)도 함께 만들었다고 함.
  5. 그전에는 클라우데라(Cloudera)에서 머신러닝 엔지니어로, 더 전에는 IBM 리서치에서 HCI(인간-컴퓨터 상호작용)를 다루는 연구원으로 일했다고 함.
  6. 에이전트 일을 시작한 계기로, 챗지피티(ChatGPT)가 나오기 4개월 전인 2022년 8월쯤 라이다(LIDA)라는 프로젝트를 했다고 함.
  7. 라이다는 웹 화면에 CSV나 JSON 파일을 끌어다 놓으면 데이터를 요약하고 질문을 만들고, 그 질문마다 코드를 생성·실행·후처리해 시각화를 보여주는 도구였다고 함.
  8. 돌아보면 요약·목표 탐색·시각화·생성(코드 인터프리터를 통째로 심어둔 것)이라는 네 범주를 가진 초창기 에이전트형 워크플로였다고 함.
  9. 시각화가 나온 뒤엔 디퓨전 모델(diffusion model)로 같은 데이터를 더 다양하게 표현하는 것도 했다고 함.
  10. 첫 버전은 오픈AI(OpenAI)의 다빈치 코덱스(Da Vinci Codex) 모델을 썼는데 오류율이 약 20%였음. 3개월 뒤 GPT-3.5 터보로 바꿔 튜닝하자 오류율이 약 1.5%로 떨어졌다고 함.
  11. 이 경험이 이런 애플리케이션이 실제로 가능하다는 걸 보여줬고, 지금은 마이크로소프트 제품은 물론 그 바깥에서도 이런 기능을 많이 볼 수 있다고 함.
  12. 그 뒤 동료들과 손으로 짠 워크플로 대신, 에이전트를 정의하면 메시지를 주고받으며 스스로 조직해 문제 공간을 탐색하는 멀티에이전트 애플리케이션을 어떻게 만들지 고민한 게 오토젠의 시작이라고 함.
  13. 오토젠은 깃허브 스타 5천 개를 받을 만큼 쓰이는 멀티에이전트 프레임워크라고 함.
  14. 오늘은 오토젠 스튜디오의 기능과 설계 철학을 훑기보다, 이미 자료가 많으니 처음부터 뭔가를 새로 만들어 보여주기로 했다고 함.
  15. 오늘 보여줄 도구는 블렌더 엘엠(Blender LM)으로, 프레임워크 없이 처음부터 만든 멀티에이전트 시스템이라고 함.
  16. 블렌더 엘엠은 "테이블 위에 그릇 하나 있는 장면을 만들어줘" 같은 자연어 요청을 받으면 뒤에서 필요한 작업을 다 처리해 3D 도구 블렌더(Blender) 안에 그 장면을 만들어주는 도구라고 함.
  17. 약 2년 전 블렌더를 배우려고 유명한 "도넛 튜토리얼"을 시도했는데, 광고상 4시간짜리지만 실제로 끝까지 마치려면 40~50시간이 걸리는 강의였다고 함.
  18. 그래서 오토젠을 만들며 쌓은 경험으로 자연어를 입력하면 이 튜토리얼 결과물 같은 걸 만들어주는 에이전트형 워크플로를 짤 수 있는지 스스로에게 물었다고 함.
  19. 지금 프로토타입이 그 품질에 완전히 닿진 못했지만 거기까지 갈 수 있다고 본다고 함.
  20. 멀티에이전트 시스템을 짤 때 한 갈래는 모든 단계를 미리 정해두는 고정된 결정론적 워크플로임.
  21. 결정론적 워크플로는 함수 호출(function calling)이나 구조화된 출력(structured output)을 써서 신뢰성 있는 시스템을 만들 수 있지만, 문제의 정확한 해법을 이미 알고 있어야 한다는 전제가 붙는다고 함.
  22. 블렌더에서 뭔가 하나 클릭하면 장면 전체가 바뀌어버리는 것처럼, 정확한 해법을 미리 알 수 없는 문제들도 있다고 함.
  23. 그래서 오늘 다루는 건 스펙트럼 반대쪽 끝, LLM(거대언어모델)이 제어 흐름을 직접 몰고 가며 도구를 쓰고 결과를 관찰해 다음 걸음을 정하는 더 자율적인 탐색형 시스템이라고 함.
  24. 이런 시스템의 특성 셋 중 첫째는 어느 정도 자율성으로, 한 가지 작업만이 아니라 여러 다른 작업도 다룰 수 있어야 한다고 함.
  25. 둘째는 행동을 취할 수 있어야 하고 그 행동엔 부작용이 있을 수 있다는 것임. 도구 하나를 불렀는데 예상 밖의 결과가 돌아올 수도 있고 시스템이 그걸 다룰 수 있어야 한다고 함.
  26. 셋째는 복잡한 작업을 탐색해 여러 단계로 쪼개고 오랜 시간 동안 계속 돌아갈 수 있어야 한다는 것임.
  27. 데모로 넘어가는데, 블렌더 엘엠 웹 화면이 웹소켓(websocket) 연결로 실제 블렌더 인스턴스와 붙어 있다고 함.
  28. 화면 첫머리엔 개발자가 직접 쓸 수 있는 고정된 도구 모음이 있는데, 장면을 지우는 버튼을 누르면 소켓 연결 덕에 블렌더에서 벌어지는 일을 그대로 화면에 실시간으로 보여준다고 함.
  29. 미리 골라놓은 예시 중 "은빛 광택이 도는 공 두 개를 만들어줘"를 골라 실행하는 걸 시연함.
  30. 요청을 넣자 먼저 "작업을 분석 중"이라는 표시가 뜨고, 위로 스크롤하면 계획 에이전트가 세운 계획이 보인다고 함.
  31. 계획은 바닥 평면을 놓아 장면 환경을 갖추고, 공간이 겹치지 않게 구 두 개를 만들고, 광택 있는 재질을 지정하는 식으로 짜여 있었다고 함.
  32. 화면에서 첫 단계로 바닥 평면이 실제 블렌더 화면에 놓이는 걸 실시간으로 확인할 수 있었다고 함.
  33. 이후 각 단계마다 여러 도구를 불러 실행하고 결과를 화면에 스트리밍하는데, 그때마다 검증 에이전트(verify agent)가 장면 스냅샷을 찍어 진행 여부를 LLM으로 판단해 다음 행동을 정한다고 함.
  34. 결과로 애초에 목표했던 그릇 하나가 실제로 블렌더 화면에 만들어졌고, 이 대목에서 청중의 박수를 받음.
  35. 어떻게 만들었는지로 넘어가는데, 시스템을 짤 때 사람들이 제일 먼저 하는 실수가 에이전트부터 정의하려는 것이라고 지적함.
  36. 순서는 목표를 정의하고, AI나 에이전트와 무관한 베이스라인을 만들어 모든 게 제대로 작동하는지 확인하고, 도구를 만들고, 평가 기준을 정하고 나서야 에이전트를 만드는 것이라고 함.
  37. 1단계 목표는 자연어로 된 작업을 3D 결과물로 바꾸는 것, 그 자체로 단순했다고 함.
  38. 베이스라인은 실행하면 큐브 하나를 장면에 추가하는 "블렌더의 헬로 월드" 스크립트였다고 함. 소켓 연결을 지원하는 블렌더 애드온과 클라이언트 라이브러리가 필요했고, 이게 빠른 프로토타이핑·테스트에 아주 유용했다고 함.
  39. 도구는 두 종류로 나뉘는데, 블렌더 객체 하나만 만들고 끝나는 작업 특화형 도구와 LLM이 생성한 코드를 실행하는 범용 도구가 있고, 블렌더의 대부분 기능이 이 범용 도구로 돌아간다고 함.
  40. 에이전트는 딱 도구만큼만 좋다며, 시간의 약 절반은 도구를 만드는 데 써야 한다고 강조함.
  41. 평가용 테스트 베드는 세 단계로 짰다고 함. 먼저 주피터 노트북(Jupyter notebook)에서 코드를 짜 테스트하고, 다음으로 완전한 대화형 웹 UI를 만들고, 마지막으로 지표를 갖춘 자동화된 평가 테스트 스위트를 만드는 순서였다고 함.
  42. 에이전트를 실제로 만들 때 가장 먼저 하는 일은 기본 에이전트 루프를 만드는 것이라고 함. 에이전트란 결국 LLM이 함수 호출을 계속 반복하는 좁은 루프라고 함.
  43. 그 루프만으로 결과 하나는 얻을 수 있지만 이런 문제엔 대개 부족해서 조금 더 다듬어야 한다고 함.
  44. 그래서 검증 에이전트(verifier agent)를 추가했는데, 매 단계마다 장면 안 객체 목록을 가져와 LLM으로 진행 여부와 작업 완료 여부를 판단해 다음 행동을 정하는 역할이라고 함.
  45. 두 번째로 추가한 건 계획 에이전트(planner)로, 들어온 작업을 원자적인 단계들로 쪼개고 각 단계를 그 루프 안에서 처리하게 한다고 함.
  46. 여기서 얻은 교훈으로 네 가지 설계 원칙을 제시하는데, 완벽하거나 빠짐없는 목록은 아니며 멀티에이전트 설계의 정답을 안다는 사람은 오히려 믿지 말라고 함. 이 분야가 아직 너무 이르기 때문이라고 함.
  47. 첫째 원칙은 능력 발견 가능성(capability discovery)임. 에이전트가 할 수 있는 일은 많지만 그중 높은 신뢰도로 해낼 수 있는 것만 화면에 알약 모양 항목으로 알려줬다고 함.
  48. 여기 더해 사용자 맥락에 기반한 선제적 제안도 있는데, 장면이 열려 있으면 그 내용을 살펴 사용자가 시도할 만한 상위 작업을 먼저 제안하는 것이라고 함.
  49. 둘째 원칙은 관측 가능성과 출처 추적(observability and provenance)임. 모든 활동 로그를 스트리밍해 에이전트가 뭘 하는지 사용자가 이해하도록 돕는다고 함.
  50. 여기엔 사용한 토큰 수, 각 단계에 걸린 시간처럼 디버깅에 쓸 만한 정보도 함께 보여주는 게 사용자에게 매우 유용하다고 함.
  51. 셋째 원칙은 중단 가능성(interruptibility)임. 에이전트가 잘못된 방향으로 가거나 허용되지 않은 자원을 많이 쓰려 할 수 있으니 언제든 멈출 수 있게 설계해야 한다고 함.
  52. 이를 위해 체크포인트, 되돌리기(rollback), 일시정지·재개 같은 기능을 시스템에 갖춰야 한다고 함.
  53. 넷째 원칙은 비용을 인지한 위임(cost-aware delegation)임. LLM 입장에선 개입하지 않는 한 모든 행동과 도구 호출이 다 동등하다고 함.
  54. 예컨대 블렌더 에이전트가 파이썬 코드를 짜다가 무슨 이유로든 운영체제 전체를 지우려 들 수도 있는데, 이런 일은 절대 있어선 안 된다고 함.
  55. 그래서 행동의 비용을 능동적으로 살피고 추정해 언제 사용자에게 위임할지 아는 모듈이 필요하다고 함.
  56. 마무리 교훈의 첫째는 멀티에이전트 접근을 언제 써야 하는지 아는 것임. 멀티에이전트가 늘 정답은 아니라고 함.
  57. 여러 에이전트에 자율성을 주고 협업시키면 오류가 날 표면도 함께 늘어나므로, 문제 공간을 살펴 멀티에이전트가 정말 맞는 도구인지 따져봐야 한다고 함.
  58. 이를 보여주려 큰 원 하나를 그리는데, 큰 원이 엔지니어링 팀이 해야 할 일 전체라면 그 아래 작은 원 하나가 멀티에이전트로 진짜 이득을 보는 일이라며, 그 작은 원이 정말 작다고 함.
  59. 자율적인 멀티에이전트 시스템을 만들기 전에 이 접근이 ROI(투자 대비 효과)가 있는지 아주 신중하게 따져보라고 함.
  60. 어떤 작업이 멀티에이전트 접근에서 이득을 볼지 판단하는 틀을 "5단계"라 부르며 다음 것들을 짚음. 첫째는 계획(planning)으로, 사용자의 상위 입력을 미해결 상태에서 해결 상태로 가는 여러 단계로 의미 있게 쪼갤 수 있는지를 본다고 함.
  61. 둘째는 작업을 여러 관점, 즉 페르소나로 나눌 수 있는지임. 계획만 다루는 페르소나, 코드 실행만 다루는 페르소나로 나눠 도메인 중심 설계를 할 수 있다고 함.
  62. 셋째는 방대한 맥락을 소비하거나 처리해야 하는지임. 계속 앱 상태나 스크린샷을 스냅샷으로 찍어야 한다면, 개별 에이전트에 큰 맥락 조각을 나눠 맡기고 최종 조율 에이전트로 모으는 방식이 유용하다고 함.
  63. 넷째는 적응형 해법이 필요한지임. 환경에서 행동을 취할 때마다 환경 자체가 계속 바뀌어 그때그때 반응해야 한다면 자율 에이전트 접근이 필요할 수 있다고 함.
  64. 두 번째 교훈은 평가 중심 설계(eval-driven design)임. 대부분 에이전트부터 만들려 드는데 그건 대체로 실수라고 함.
  65. 대신 작업을 정의하고, 평가 지표를 정하고, 에이전트와 무관한 베이스라인을 만든 뒤 에이전트를 반복적으로 개선해야 한다고 함.
  66. 이 앱에서는 단순한 루프로 시작해 검증 에이전트를 더하고 계획 에이전트를 더했는데, 직접 만든 대화형 평가 도구로 이 각 단계가 실제로 ROI와 개선을 가져왔다는 걸 확인할 수 있었다고 함.
  67. 학계 벤치마크는 훌륭하지만 그게 곧 내 작업은 아니므로, 자기 작업에 맞춰 튜닝한 평가를 직접 만들어야 한다고 함.
  68. 마지막 슬라이드를 오늘의 "돈이 되는 슬라이드(money slide)"라 부르며 네 원칙을 다시 정리함. 사용자가 시스템이 설계된 이상적인 작업을 발견하게 하고, 사용자에게 보이는 관측 가능성 트레이스를 제공하라는 것임.
  69. 이어서 에이전트를 체크포인트·재시작 가능한 중단 가능 상태로 만들고, 에이전트가 모든 행동의 위험·비용을 정량화해 필요할 때 사용자에게 위임하게 하라는 것임.
  70. 마지막으로 강연 하나를 위해 멀티에이전트 시스템 전체를 처음부터 만들지는 말라고 당부함. 재미있고 품이 많이 드는 일이니 필요하면 프레임워크를 써서 몇 번의 타이핑으로 끝내는 편을 권한다고 함.
  71. 더 읽을거리로 오토젠 스튜디오, 매전틱 원(Magentic-One), 매전틱 UI(Magentic UI), 인간-AI 커뮤니케이션의 난제를 다룬 논문들을 소개함.
  72. 지금 쓰고 있는 책의 3장이 이 설계 이야기를 다룬다며, 블렌더 엘엠의 코드도 공개돼 있다고 밝힘.

한줄 코멘트. 네 원칙보다 먼저 온 건 "결정론적 워크플로와 자율 탐색형 중 어느 쪽 문제인지 가르는 판단"이었고, 그 다음에야 원칙을 적용했다는 순서가 이 발표의 실제 값임 — 큰 원 안에서 멀티에이전트가 맞는 작업은 아주 작은 원 하나뿐이라는 그림이 그 순서를 뒷받침함.

  1. 발표자는 AWS 소속 수만 데브나스(Suman Debnath)이고, 오픈소스 에이전트 SDK 스트랜즈(Strands Agents)를 데모 위주로 빠르게 보여주는 세션이라고 밝힘.
  2. 스트랜즈의 유일한 목표는 에이전트를 스캐폴딩(agent가 할 일을 미리 정해주는 코드 뼈대) 없이 최대한 단순하게 만드는 것이라고 함.
  3. 필요한 건 도구(tool)와 모델 딱 둘뿐이고, 에이전트가 뭘 해야 하는지 미리 정해줄 필요가 없다고 함.
  4. 모델이 점점 똑똑해지고 있으니 추론(reasoning)은 모델에 맡기고, 프롬프트나 시스템 프롬프트, 배경 설명을 잔뜩 쌓아 스캐폴딩하지 않겠다는 게 설계 의도라고 함.
  5. 랑퓨즈(Langfuse), 라이트LLM(LiteLLM) 같은 서드파티와 연동돼 있어서 베드록(Bedrock) 호스팅 모델이 아니어도 원하는 모델을 골라 쓸 수 있다고 함.
  6. 로컬에서 테스트하고 싶으면 올라마(Ollama)도 붙일 수 있다고 함.
  7. 스트랜즈의 에이전틱 루프(agentic loop)는 모델과 도구, 이 둘로만 돈다고 함.
  8. 로고에 그려진 두 가닥(strand)이 각각 모델과 도구를 뜻한다는 걸 바로 어제 알았다고 웃으며 말함.
  9. 첫 데모는 디스크에서 파일 하나를 읽어 요약하고, 그 요약을 로컬 드라이브에 쓴 뒤 결과를 음성으로 읽어주는 흐름이라고 함.
  10. 파일 읽기, 파일 쓰기, 음성 생성 세 가지 전부 스트랜즈 기본 도구로 처리하며 커스텀 도구를 따로 짤 필요가 없다고 함.
  11. `pip install`로 스트랜즈 에이전트와 스트랜즈 도구(strands-tools) 패키지를 설치하는 게 시작이라고 함.
  12. 스트랜즈 도구 패키지를 설치하면 기본 도구 여러 개가 한꺼번에 딸려 온다고 함.
  13. 스트랜즈를 임포트하면 기본값으로 베드록의 클로드 3.7(Claude 3.7) 모델을 쓴다고 함.
  14. 원하면 다른 모델을 직접 지정할 수도 있는데, 나중엔 모델 ID를 안 줘도 에이전트가 그냥 동작하는 걸 보여주겠다고 예고함.
  15. 올라마로 로컬 모델을 붙이고 싶으면 그렇게 정의할 수도 있다고 함.
  16. 시스템 프롬프트를 넣어서 보여주지만, 깃허브에 공유할 코드에서는 이 프롬프트를 지워도 여전히 동작한다고 함.
  17. 내부 동작 감을 잡아주려고 시스템 프롬프트를 넣었을 뿐이라고 밝힘.
  18. 결국 에이전트를 만들 때 주는 건 모델 ID, 시스템 프롬프트, 도구 목록뿐이라고 함.
  19. 데모 프롬프트는 "10장을 읽고 요약해서 마크다운 파일로 쓰고 소리 내어 읽어라"였다고 함.
  20. 실행하자 파일을 읽고 요약을 만들어 쓴 뒤 소리로 읽어주는데, "사람 눈은 각막으로 빛이 들어오는 카메라처럼 작동한다"는 문장이 흘러나왔다고 함.
  21. 두 번째 데모는 MCP(모델 컨텍스트 프로토콜, LLM이 외부 도구·서버에 표준화된 방식으로 접속하게 해주는 규격)를 붙이는 사례라고 함.
  22. MCP 없이는 이 컨퍼런스에서 발표할 수 없다는 말을 들었다며 농담함.
  23. 청중에게 유튜브 채널 3blue1brown을 아느냐고 물은 뒤, 그 채널처럼 수학 애니메이션을 만드는 게 이번 목표라고 함.
  24. 그 애니메이션은 마님(Manim)이라는 라이브러리로 만드는데, 본인이 몇 년째 마님을 다뤄왔고 벡터·특이값분해(SVD) 같은 개념을 시각화로 설명하기 좋다고 함.
  25. 이미 마님으로 영상을 만들어주는 MCP 서버가 있다고 가정하고 시작한다고 함.
  26. 스트랜즈 에이전트와 MCP 클라이언트를 임포트하고, MCP 서버 코드가 있는 경로를 지정해 MCP 클라이언트를 만든다고 함.
  27. 첫 데모와 다른 점은 도구 목록에 읽기·쓰기·음성 같은 기본 도구 대신 MCP 서버 하나만 넣는다는 것이라고 함.
  28. `mcp_client.list_tools_sync()`를 도구로 주면 MCP 서버가 가진 도구 전부가 에이전트 쪽으로 넘어온다고 함.
  29. 프롬프트는 "x=-3부터 x=3까지 범위에서 삼차방정식(cubic equation)을 시각화하라"였다고 함.
  30. 바이트 페어 인코딩(byte pair encoding)을 설명하거나 2×2 행렬 두 개의 곱셈을 시각화하는 식으로 다른 프롬프트도 써볼 수 있다고 함.
  31. 실행 전에 MCP 서버를 로컬 호스트에서 먼저 띄운 뒤 `app.py`를 돌려야 한다고 함.
  32. 이번에도 시스템 프롬프트 같은 스캐폴딩을 따로 주지 않았고, 모델이 스스로 추론해서 풀도록 뒀다고 강조함.
  33. 결과 영상이 나왔는데 포토샵으로 조작한 게 아니라고 함.
  34. 영상 길이를 30초, 10초처럼 직접 지정할 수 있다고 함.
  35. 마님으로 코드를 생성해본 적 있으면 알겠지만 시간이 좀 걸리는 작업이라 즉시 나오지는 않는다고 함.
  36. 이어서 MCP 서버 코드를 보여줌. 패스트MCP(FastMCP)를 임포트하고, 함수를 MCP 데코레이터로 감싸는 방식으로 도구 두 개를 정의해뒀다고 함.
  37. 메인 함수에서 스트랜즈 에이전트와 MCP 클라이언트를 호출하는데, 도구 목록을 뽑기 전에 마님 사용 예시를 하나 넣어준다고 함.
  38. 이 예시는 원샷 프롬프팅(one-shot prompting)과 비슷한 방식이라고 설명함.
  39. 정작 에이전트를 부르는 코드는 한 줄뿐이고, 대화형 경험을 위해 `while True` 루프를 돌린다고 함.
  40. 남은 시간이 얼마 없다며 커스텀 도구 만드는 법을 짧게 보여줌.
  41. 함수 하나가 있으면 `tools`를 임포트해 그 함수를 데코레이터로 감싸기만 하면 그 함수가 도구로 바뀐다고 함.
  42. 이렇게 만든 커스텀 도구는 다음에 에이전트를 만들 때 파일 읽기·쓰기·음성 같은 기본 도구와 나란히 도구 목록에 넣어 쓰면 된다고 함.
  43. 더 알고 싶으면 깃허브 저장소, 런칭 블로그, 문서 사이트 strandsagents.com을 보라고 안내함.
  44. 질문이 있으면 발표장 주변에 있을 테니 편하게 물어보라고 함.
  45. 부스에서도 스트랜즈와 람다(Lambda), MCP를 엮은 데모를 여러 개 볼 수 있다고 안내함.
  46. 오픈소스 프로젝트라 샘플 코드 저장소에 만든 걸 PR로 올려달라고 부탁하며 발표를 마침.

한줄 코멘트. 두 데모 모두 시스템 프롬프트를 빼도 돌아간다는 걸 직접 지워 보이는 대신 말로만 짚고 넘어갔는데, 그 확인 자체를 생략한 채 "스캐폴딩 없다"는 주장만 반복한 셈임.

  1. 이 발표는 마이크로소프트(Microsoft) 수석 응용과학자 마이클 알바다(Michael Albada)가 AI 엔지니어 컨퍼런스에서 한 것으로, 주제는 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)로 애플리케이션을 만드는 법임.
  2. 마이클은 마이크로소프트에서 2년째 일하며 시큐리티 코파일럿(Security Copilot)과 최근 발표된 시큐리티 코파일럿 에이전트를 사이버보안 부서에서 만든 핵심 기여자라고 밝힘.
  3. 그 전에는 우버(Uber)에서 4년간 대규모 지리공간 문제를 다루는 머신러닝을 했고, 그전엔 스타트업에 있었다고 밝힘.
  4. 이 발표는 O'Reilly에서 낼 300쪽짜리 책을 압축한 것으로, 앞 일곱 장은 이미 조기 공개(early release)로 나와 있고 다음 달 인쇄된다고 밝힘.
  5. 슬라이드 위주로 가되 다루는 내용을 뒷받침하는 코드 예제가 전부 따로 있다고 밝힘.
  6. 발표 순서는 에이전틱 개발에서 보이는 가능성과 걸림돌, 프로덕션까지 가는 데 필요한 핵심 구성요소, 흔한 함정과 교훈 셋임.
  7. Y 컴비네이터(Y Combinator)에 뽑힌 회사 중 스스로 에이전틱(agentic)하다고 밝힌 곳이 최근 3년 새 254% 늘었다는 수치를 듦.
  8. 학계의 주요 에이전틱 벤치마크는 여러 번의 툴 호출과 실행을 복잡한 환경에서 연쇄로 요구하는 어려운 과제들임.
  9. 5년, 10년 전이었다면 이런 과제에서 한 자릿수 점수에 머물렀을 텐데 지금은 50, 60, 70점대까지 올라온 게 인상적이라고 함.
  10. 다만 직접 에이전틱 시스템을 만들어보면 완벽을 기대하면 안 된다고 함. 70% 정확도짜리 초기 프로토타입까지는 쉽게 가도, 그 뒤 남는 긴 꼬리(long tail)의 복잡한 시나리오는 갈수록 풀기 어려워진다고 함.
  11. 마이클은 에이전트를 추론하고 행동하고 소통하고 적응해 과제를 푸는 개체로 정의하고, 파운데이션 모델(foundation model, 기반이 되는 대규모 언어모델)을 토대로 여러 구성요소를 얹어 성능을 올리는 구조라고 봄.
  12. 앤드루 응(Andrew Ng)이 정리했듯 에이전틱함은 이분법이 아니라 하나의 스펙트럼(연속선)이라고 함.
  13. 마이클은 여기에 축 하나를 더하는데, 시스템의 효과성(effectiveness)임. 에이전시(agency, 스스로 판단해 행동하는 정도) 자체를 목표로 삼지 말고 문제를 푸는 도구로 봐야 한다고 함.
  14. 예로 든 것이 로보틱 프로세스 자동화(RPA, 정해진 규칙대로 화면과 시스템을 조작해 반복 업무를 대신하는 자동화)임. 에이전시는 낮지만 효과성은 매우 높은 이전 세대 자동화라고 함.
  15. RPA는 많은 회사에 경제적 가치를 안겨줬지만 고정돼 있고 깨지기 쉬워서, 입력이 조금만 바뀌어도 전체가 망가지고 계속 손으로 유지보수해야 한다고 함.
  16. 에이전틱 시스템으로 옮겨가는 이유는 유연하고 적응력이 있어 바뀌는 입력에 대응할 수 있다는 데 있지만, 에이전시를 더할 때마다 효과성은 그대로 높게 유지해야 한다고 강조함.
  17. 에이전시도 낮고 효과성도 낮은 형편없는 챗봇 사례가 이미 많이 나왔다며, 반대로 에이전시만 높고 효과성은 낮은 시스템도 피해야 할 「미래의 뉴스 사고」라고 함.
  18. 툴 사용(tool use)을 첫 번째 핵심 구성요소로 꼽음. 파운데이션 모델은 자기회귀(autoregressive, 앞서 나온 토큰을 보고 다음 토큰을 하나씩 예측하는 방식) 생성 모델로 보통 자연어를 예측하지만 함수 호출도 출력할 수 있다고 함.
  19. 이 모델에 툴과 기능을 노출하면 에이전트가 함수를 직접 호출할 수 있게 되고, API로 노출 가능한 기능 전체를 이 안에서 쓸 수 있게 된다고 함.
  20. 그만큼 어떤 기능을 어떤 방식으로 노출할지에는 상당한 분별력과 책임이 따른다고 함.
  21. 동작은 루프(loop)로 이뤄짐. 출력된 텍스트를 파서로 읽어 툴을 호출하고 응답(관측 결과)을 받아 다시 에이전트에 넘기는 과정을 최종 출력이 나올 때까지 반복함.
  22. 흔한 오류로 API와 툴을 1대1로 매핑하려는 생각을 듦. API가 300개인 조직이면 툴도 300개 등록하면 안 되고, 그러면 에이전트가 혼란스러워한다고 함.
  23. 경험적으로 확인된 사실은, 한 번의 완성(completion, 모델에 프롬프트를 보내 응답을 받는 한 번의 호출)에 노출하는 툴이 많을수록 툴 사이 의미 충돌이 늘어 전체 정확도가 떨어진다는 것임.
  24. 그래서 노출하는 툴 수를 줄이고 논리적으로 묶어, 이름과 설명을 구체적으로 좁혀 각 툴이 사람이 보기에도 하나의 동작처럼 느껴지게 하라고 권함.
  25. 오케스트레이션(orchestration, 여러 도구와 단계를 어떤 순서로 부를지 짜는 설계) 패턴은 단순하게 가라고 권함. 표준 워크플로 패턴만으로도 많은 일을 해낼 수 있다고 함.
  26. 단일 체인(chain)으로 풀 수 있으면 그렇게 하라고 함. 측정하기 쉬워지고 비용이 낮아지고 신뢰성이 올라가 고객에게 가치를 더 쉽게 전달할 수 있다고 함.
  27. 분기 로직(branching logic)을 걸어 LLM이 트리(tree)의 어느 경로로 갈지 고르게 할 수도 있다고 함. 자신이 일하는 사이버보안에서 사고 심각도를 정하고 여러 단계를 거쳐 정보를 모으는 멀티홉(multihop, 여러 단계를 거쳐 정보를 모으는 방식) 조사에 이 패턴이 잘 맞는다고 함.
  28. 완전한 에이전틱 패턴으로 가면 모델이 반복해서 스스로 어떤 행동을 할지 고르게 되는데, 그만큼 측정하기도 어렵고 성능을 온전히 끌어내기도 어렵다고 함.
  29. 다만 쓴맛의 교훈(bitter lesson)을 기억하라고 함. 만들고 있는 체인과 트리가 지나치게 복잡해지고 유지하기 어려워졌다면, 더 에이전틱한 패턴으로 옮기고 모델을 추가로 파인튜닝(fine-tuning, 기반 모델을 특정 용도에 맞게 추가 학습시키는 것)할 때가 됐다는 신호라고 함.
  30. 또 하나 유용한 패턴은, 원하는 고정 업무 로직(A, B, C가 맞을 때만 행동하는 식)을 LLM에 맡기지 말고 각 상태를 갱신하는 툴을 노출한 뒤 그 상태마다 위생 처리(sanitization)와 검증을 거는 것이라고 함.
  31. 이렇게 하면 로직은 결정적이고 고정된 채로 모델 바깥에 두고 유지할 수 있어, 조건이 실제로 충족됐을 때만 해당 행동이 실행되도록 보장할 수 있다고 함.
  32. 단일 에이전트에서 멀티 에이전트로 옮기는 흐름도 있는데, 그 가장 좋은 이유는 앞서 말한 툴 과부하 문제 때문이라고 함.
  33. 툴 그룹을 의미별로 나눠 각각 개별 에이전트에 등록하고, 코디네이터(coordinator, 어떤 에이전트에 작업을 맡길지 정하는 조정 역할)가 알맞은 에이전트로 작업을 라우팅하게 하면 툴 수가 늘어도 계속 확장할 수 있다고 함.
  34. 에이전트-투-에이전트 프로토콜(agent-to-agent protocol, 서로 다른 에이전트가 표준 규격으로 상대를 찾고 협업하게 하는 규약) 이야기도 나오는데, 지금까지 성공한 멀티 에이전트 시스템 대부분은 한 팀이 직접 조율해 만든 것이라고 함.
  35. A2A 프로토콜이 지향하는 미래는 서로 다른 팀이 만든 에이전트들이 서로를 발견하고 조율하는 쪽이지만, 아직 초기 단계고 기술·보안 질문이 많이 남아 있다고 함.
  36. 평가(evaluation)로 넘어가며, 자신의 팀뿐 아니라 거의 모두에게 평가에 더 투자하라고 권함.
  37. 만들기 쉬워졌고 70~80% 정확도까지 가기도 쉬워졌다고 함. 다만 에이전트 수·툴 수·모델 선택·메모리 방식 같은 수많은 하이퍼파라미터(hyperparameter, 모델을 돌리기 전에 사람이 미리 정해야 하는 설정값)는 제대로 된 평가 세트 없이는 답하기 거의 불가능하다고 함.
  38. 이는 에이전트를 기대하는 입력과 출력으로 정의하는 테스트 주도 개발(test-driven development, 먼저 기대하는 결과를 정하고 이를 통과하도록 만드는 개발 방식)로 옮겨가는 흐름이라고 봄.
  39. 레이블링(labeling)은 예전엔 미케니컬 터크(Mechanical Turk) 같은 곳에 외주로 맡기던 일이었지만, 이제는 AI 아키텍트·AI 엔지니어가 에이전트가 정확히 뭘 해야 하는지 직접 책임지고 정의해야 한다고 함.
  40. 입출력을 정의하는 데 시간을 쓰면 모델과 프레임워크가 계속 바뀌는 와중에도 팀이 어려운 결정을 더 빨리 내리는 데 도움이 된다고 함.
  41. 흐름은 사용자 입력을 에이전트에 돌려 출력을 얻고, 사람이 검토한 뒤 그걸 평가 세트에 추가하고, 그 세트로 다시 에이전트를 돌려 실패를 클러스터링·요약해 개선안을 뽑는 루프임.
  42. 이 과정을 돕는 오픈소스 도구로 인텔 에이전트(Intel Agent)를 듦. 실 사용자 데이터에 접근할 수 없거나 아직 출시 전인 경우 합성 데이터(synthetic data, 실제 데이터 대신 인공적으로 만든 데이터)를 만드는 데 좋다고 함.
  43. 마이크로소프트가 오픈소스로 낸 파이릿(PyRIT)은 에이전트를 레드팀(red team, 공격자 입장에서 일부러 공격해 약점을 찾는 방식)하는 데 좋고, 출시 전에 탈옥·레드팀 시도로 에이전트를 미리 흔들어보길 권함.
  44. 레이블 스튜디오(Label Studio)는 평가 세트를 만드는 데 좋은 프레임워크라고 함.
  45. 그 밖에 자동 프롬프트 최적화·엔지니어링 도구로 트레이스(TRACE), 텍스트그래드(TextGrad), DSPy를 듦. 파운데이션 모델을 심사자로 써서 하이퍼파라미터를 정하고 그래디언트(어느 방향으로 바꾸면 나아지는지 알려주는 값)를 계산해 실패를 보고 자동으로 개선안을 되돌려준다고 함.
  46. 지금은 예시 하나하나를 손으로 보며 「이러면 되겠지」 하고 시험해보는 일화 기반 개발(development by anecdote)이 많이 벌어지고 있다고 지적함.
  47. 평가 세트를 쌓고 배치로 돌려 집계 수준에서 분석하면 더 똑똑한 다음 스텝을 밟을 수 있다며, 신경망을 최적화할 때 배치를 키우면 전역 최솟값에 더 정확히 다가가는 것과 같은 원리라고 비유함.
  48. 관측(observability)을 다음 주제로 듦. 생성 모델은 콘텐츠를 잘 만들어내는 게 강점이자, 그만큼 대규모로 평가하기 어렵게 만드는 도전이라고 함.
  49. 빙산 비유를 씀. 일단 배포해 고객 손에 들어가면 실제로 무슨 일이 벌어지는지, 어떤 실패와 사용 사례가 있는지 파악하기 어려워진다는 것임.
  50. 오픈엘엠트리(OpenLLMetry)와 오픈텔레메트리(OpenTelemetry, 시스템 동작을 표준 형식으로 기록하는 관측 규격) 연동 같은 도구로 상세 로그와 트레이싱을 남기고, 실패 유형을 클러스터링·자동 요약해 파악하길 권함.
  51. 흔한 함정을 정리하며, 평가 부족이 압도적으로 가장 큰 한계이자 도전이라고 함.
  52. 툴 쪽 함정으로는 툴을 충분히 만들지 않았거나 설명이 정확·명확하지 않거나 툴 사이 의미가 지나치게 겹치는 경우를 듦. 이러면 개별 완성 호출이 헷갈려 결과가 나빠진다고 함.
  53. 과도한 복잡성도 함정임. 요즘 화려한 기능이 너무 많아 쫓아가기 쉬운데, 실제로 사용자 경험을 낫게 한다고 테스트로 확인된 것만 추가하라고 함.
  54. 학습 부족도 함정임. 배우는 루프를 조이는 일이 어려운데, 쏟아지는 콘텐츠를 다 걸러내는 대신 근본 원인을 찾아 개선안을 제시하는 데 집중하라고 함.
  55. 마지막으로 사이버보안 부서 관점에서, 에이전틱 시스템은 새로운 종류의 취약점 대상이라며 모든 층에서 안전을 설계하라고 함.
  56. 파이릿이 여러 층에서 도움이 되지만 결국 좋은 소프트웨어 공학 원칙이 핵심이라며, 에이전틱 스택 여러 단계에 트립와이어(tripwire, 이상 징후를 감지해 경고·차단하는 장치)와 탐지기를 심어 중요한 경우엔 사람 검토로 넘길 수 있게 하라고 함.
  57. 폴 크루그먼(Paul Krugman)의 말을 인용하며 발표를 맺음. 생산성이 전부는 아니지만 장기적으로는 거의 전부이며, 한 나라의 생활수준은 노동자 1인당 산출을 얼마나 끌어올리느냐에 거의 전적으로 달려 있다는 내용임.
  58. 마이클은 지금이 각자가 해낼 수 있는 일의 양이 크게 뛰어오르는 시점의 초입이라며, 이 새 에이전트 설계 패턴이 그 도약을 도울 것이라는 기대로 마무리함.

한줄 코멘트. 체인이 복잡해지면 에이전틱 패턴으로 넘어가라는 「쓴맛의 교훈」은 방향은 맞지만 전환 시점을 재는 기준이 감(感)에 머물러 있고, 그 판단조차 제대로 된 평가 세트 없이는 내리기 어렵다는 이 발표 자신의 조언과 부딪힘.

  1. 리타 코즐로프(Rita Kozlov)는 Cloudflare 개발자 플랫폼, 즉 워커스(Workers)와 듀러블 오브젝트(Durable Objects) 담당 부사장이라고 밝힘.
  2. 인터넷 트래픽의 약 20%가 Cloudflare를 거쳐 가기 때문에 이 자리에 있는 사람은 이미 다 Cloudflare를 써본 셈이라고 함.
  3. Cloudflare는 CDN·DNS·DDoS 방어 말고도 개발자용 함수·스토리지·컴퓨트·AI 추론 서비스를 제공한다고 함.
  4. 1년 전 발표 때는 개발자의 44%가 AI를 업무에 쓰고 있었다고 함.
  5. 당시 가트너(Gartner)는 2030년까지 지식노동자의 50%가 AI로 업무를 보완할 것으로 예측했다고 함.
  6. 지금은 지식노동자의 75% 이상이 AI로 업무를 보완하고 있어 2030년 예측을 이미 넘어섰다고 함.
  7. 개발자의 76% 이상이 개발 과정에 AI를 쓰고 있고, 지금은 그 수치가 더 늘었을 것이라고 함.
  8. 1년 전에는 AI 워크로드 이야기가 주로 훈련(training)에 관한 것이었는데, 이후 추론(inference)으로 무게중심이 옮겨갈 것으로 예측했었다고 함.
  9. 오픈AI의 o1 모델이 훈련에서 사후훈련(post-training)·추론 쪽으로 옮겨간 것이 그 예측이 맞아떨어진 사례라고 함.
  10. 딥시크(DeepSeek)도 훈련을 워낙 최적화해서 에너지 소비가 점점 추론 쪽으로 쏠렸다고 함.
  11. 훈련·추론 다음 단계는 자동화이고, 그게 지금 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 논의가 뜨거운 이유라고 함.
  12. 지금까지 챗GPT에 이메일 초안을 부탁하는 식으로 사람 업무를 보조하는 수준이었다면, 에이전트는 컨퍼런스에서 만난 고객 명단을 뽑고 이메일 초안을 쓰고 승인을 받은 뒤 고객 응답이 오면 알려주는 것처럼 여러 단계를 한 번에 맡길 수 있다는 점이 다르다고 함.
  13. 이런 식의 에이전트형 작업 흐름이 다음 단계의 생산성을 열 것이라고 함.
  14. 세일즈 자동화에 에이전트를 도입한 기업 중 일부는 매출이 20% 늘었다고 함.
  15. 어떤 기업은 AI 에이전트를 쓰면서 고객 응대 속도가 90% 빨라졌다고 함.
  16. 전반적으로 에이전트를 쓰면 50~75%의 시간 절감을 보고 있다고 함.
  17. 리타는 에이전트를 만들 때 네 가지 구성요소로 나눠 생각한다고 함 — 클라이언트, AI(추론), 워크플로우, 도구.
  18. 클라이언트는 사람이 에이전트와 상호작용하는 인터페이스라고 함.
  19. AI는 다음에 뭘 실행할지 로직을 만드는, 생각하는 부분이라고 함.
  20. 생각한 결과를 실제로 실행하는 행정부 역할이 워크플로우이고, 워크플로우는 다시 도구에 접근해야 실제 행동을 취할 수 있다고 함.
  21. 예시로 든 CRM 에이전트를 음성으로 쓰려면 WebRTC로 연결하고 음성을 텍스트로 바꾸는 모델이 필요하다고 함.
  22. 채팅 UI를 쓰려면 그걸 호스팅할 곳이 필요하고, 이상적으로는 캐싱과 평가(eval)를 돌리는 게이트웨이를 거쳐 응답을 LLM에 보낸다고 함.
  23. 그 다음 어떤 행동이 실행됐고 다음에 뭘 해야 하는지 추적하는 워크플로우 에이전트가 필요하다고 함.
  24. 워크플로우는 웹 브라우저·API·내부 서비스·벡터 데이터베이스 같은 도구에 연결돼야 하고, 때로는 사람이 개입해 행동을 검증해야 한다고 함.
  25. 리타는 순서를 거꾸로 짚어서 도구 부분부터 설명하겠다고 함.
  26. 최근 화두인 MCP(모델 컨텍스트 프로토콜, LLM이 외부 도구·데이터에 표준화된 방식으로 접속하게 해주는 규격)는 앤트로픽(Anthropic)이 지난 11월 발표한 표준이라고 함.
  27. MCP의 진짜 의미는 API를 LLM에 노출해 사람이 자연어로 LLM과 대화하게 만든 것이라기보다, LLM이 도구 호출(tool calling)을 정말 잘하게 됐다는 사실이라고 함.
  28. 몇 년 전만 해도 도구 호출을 시도해 보면 잘 안 됐는데 지금은 다르다고 함.
  29. MCP는 전통적인 클라이언트-서버 구조를 따르기 때문에 하나의 MCP 서버에 여러 클라이언트가 동시에 접속해 대화를 주고받을 수 있다고 함.
  30. MCP 서버는 보통 리소스·프롬프트·툴링·샘플링 네 가지 핵심 개념으로 구성된다고 함.
  31. 리소스는 파일 내용이나 데이터베이스 레코드 같은 것이라고 함.
  32. 프롬프트는 자기 시스템의 미묘한 부분을 가장 잘 아는 개발자 자신이 에이전트와 상호작용하는 방식을 미리 정의해 두는 용도라고 함.
  33. 툴링은 실제 쿼리를 도구와 연결하는 부분이라고 함.
  34. 샘플링은 LLM이 생략된 부분을 스스로 채워 넣게 하는 개념인데, 이 발표를 준비하면서 보니 실제 프로덕션에서 샘플링을 쓰는 사례를 아직 못 봤다고 함.
  35. MCP 서버를 직접 만들 때 까다로운 부분은 전송 프로토콜(SSE·웹소켓), OAuth 인증, 메모리(상태 유지) 세 가지라고 함.
  36. Cloudflare는 이 까다로운 부분을 대신 처리해 주는 agents라는 SDK(소프트웨어 개발 키트)를 몇 달 전에 냈다고 함.
  37. 이 SDK 이름이 며칠 전 오픈AI가 낸 것과 같은데, 둘은 서로 잘 맞물려 작동한다고 함.
  38. agents SDK로 MCP 서버를 돌릴 수 있고, MCP agent라는 내장 클래스가 OAuth·전송·HTTP 스트리밍까지 다 갖춰서 원격 MCP 서버를 호스팅해 준다고 함.
  39. Cloudflare에는 듀러블 오브젝트(durable objects)라는 프리미티브가 있는데, 서버리스 함수에 상태를 직접 붙인 것 같은 개념이라 별도 데이터베이스 없이도 상태 관리가 가능하다고 함.
  40. 이 SDK에는 실시간 웹소켓 통신, React 연동 훅, 기본 채팅 기능도 들어 있다고 함.
  41. 리타는 굿리즈(Goodreads)처럼 책을 추천해 주는 MCP 서버를 예로 들어 배포 과정을 보여줌.
  42. MCP agent 클래스를 상속받아 초기 상태를 빈 값으로 설정하고, 선호 장르를 등록하는 add genre 툴을 붙인다고 함.
  43. 스릴러를 좋아한다고 입력하면 그 선호가 저장되고 이후 상호작용에도 남는다고 함.
  44. get recommendations라는 별도 툴로 책 추천을 받을 수 있고, 이미 읽었다고 밝힌 책과 좋아하는 장르를 반영한 개인화 프롬프트를 MCP 프롬프트 기능으로 미리 정의해 둘 수 있다고 함.
  45. 이 MCP 서버는 독립적으로 동작하고 여러 클라이언트에서 접속할 수 있기 때문에, 어떤 도구로 접속하든 저장된 기억이 그대로 유지된다고 함.
  46. 전통적인 방식이라면 데이터베이스를 따로 세우고 연결을 관리하고 확장성을 신경 써야 해서 지연도 생기는데, MCP agent는 메모리가 내장돼 있어 이런 인프라 고민 없이 자동으로 확장된다고 함.
  47. Cloudflare 블로그에 가면 배포 버튼 하나로 1분 안에 첫 MCP 서버를 띄울 수 있다고 함.
  48. 아틀라시안(Atlassian)·아사나(Asana)·스트라이프(Stripe)·인터콤(Intercom) 같은 회사들이 이미 이 방식으로 자체 MCP 서버를 만들고 있다고 함.
  49. 도구 다음은 조정(coordination) 컴포넌트, 즉 워크플로우라고 함 — 한 번의 도구 호출이 아니라 사람이 개입할 수도 있는 전체 체인 동안 상태를 유지해야 한다고 함.
  50. 사람이 개입하는 워크플로우는 몇 분 걸리는 추론 LLM 응답을 기다리기도 하고, 사람의 응답은 몇 분에서 몇 달까지 걸릴 수 있어서 작업이 끝나면 흐름을 다시 이어갈 방법이 필요하다고 함.
  51. 웹소켓 서버 유지, 재시도, 수평 확장 같은 문제도 여전히 신경 써야 한다고 함.
  52. 실제 사례로 알림 관리 회사 Knock과 함께, 신용카드 신규 발급을 요청하면 상사가 이메일·슬랙·인앱 알림으로 승인하는 에이전트를 만든 이야기를 들려줌.
  53. 먼저 채팅 인터페이스로 카드를 요청받도록 agents react 라이브러리의 useAgent를 써서 채팅 인스턴스를 만든다고 함.
  54. 카드를 발급하는 issue card 액션을 require human input 툴로 감싸서 항상 사람 승인을 거치게 만든다고 함.
  55. Knock을 붙여 승인 알림을 보내고, 승인이 날 때까지 카드 발급 툴 호출을 미뤄 둔다고 함.
  56. 승인이 나면 듀러블 오브젝트가 자동으로 그 요청을 건 사용자의 에이전트를 이름으로 찾아 정확한 듀러블 오브젝트로 라우팅해 준다고 함.
  57. 승인 상태를 받으면 미뤄뒀던 카드 발급 툴 호출을 이어서 실행하고 사용자에게 승인됐다고 알려준다고 함.
  58. 웹훅이 순서에 안 맞게 두 번 들어오는 경우를 대비해 카드가 이미 요청·발급됐는지 상태를 저장해 중복 승인·중복 발급을 막는다고 함.
  59. 도구와 워크플로우 다음은 추론을 맡을 모델을 고르는 부분인데, 이 부분은 이 컨퍼런스에 그것만 다루는 다른 발표가 많아서 건너뛰겠다고 함.
  60. 마지막으로 서버에 접속할 클라이언트가 필요한데, MCP 서버를 한 번 만들어 두면 사용자가 이미 쓰고 있는 도구를 그대로 쓸 수 있어 따로 UI를 만들 필요가 없다고 함.
  61. 커서(Cursor)가 원격 MCP 서버를 지원하기 때문에 개발자 사용자라면 MCP 서버를 임포트하기만 하면 되고, 클로드(Claude)와 챗GPT도 원격 MCP를 지원한다고 함.
  62. 다만 직접 앱과 MCP 클라이언트를 만들면 클라이언트와 서버 양쪽을 다 통제할 수 있어 더 흥미로운 에이전트형 작업 흐름을 짤 수 있다고 함.
  63. 앱이 꼭 화면 UI일 필요는 없고, Cloudflare가 만든 WebRTC-웹소켓 변환 도구를 쓰면 음성으로도 MCP 클라이언트와 대화할 수 있다고 함.
  64. 정리하면 에이전트는 클라이언트·AI·워크플로우·도구 네 조각이고, 어디서 시작할지 모르겠다면 agents SDK로 몇 분 안에 뭔가를 돌려볼 수 있다고 추천하며 발표를 마침.

한줄 코멘트. 네 조각 프레임은 깔끔한데 결국 그중 도구·워크플로우 두 조각을 자사 agents SDK 하나로 풀어주겠다는 제품 홍보로 이어진다는 점은 감안해서 읽어야 함. 다만 MCP 샘플링을 실제 프로덕션에서 아직 아무도 안 쓴다고 스스로 밝힌 대목은 과장 없이 정직함.

  1. 발표자는 아마존(Amazon) AWS의 앤트제 바스(Antje Barth)이며, AI Engineer World's Fair 무대에 다시 서서 "클라우드 규모로 에이전트 만들기"를 주제로 발표함.
  2. 아마존과 AWS는 지금 아는 모든 고객 경험이 AI로 다시 만들어질 것이라 믿는다고 함. 기존 경험뿐 아니라 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 덕에 가능해진 새로운 경험도 나올 것이라고 함.
  3. 이론이 아니라 지금 실제로 그 미래를 함께 만들고 있는 중이라고 강조함.
  4. 아마존 내부에는 이미 만들었거나 개발 중인 생성형 AI 애플리케이션이 1,000개가 넘는다고 함. 재고 예측부터 배송 경로 최적화, 고객의 쇼핑과 집안 기기 사용까지 바꾸고 있다고 함.
  5. 그중 가장 야심 찬 AI 에이전트 배치 사례로 알렉사(Alexa)를 통째로 다시 만든 것을 꼽음.
  6. 이 시연 영상이 자신들이 아는 한 서비스·에이전트 기능·LLM(거대언어모델)을 통틀어 가장 크게 통합한 사례라고 소개함.
  7. 영상에서 알렉사 플러스는 아이 일정과 할머니 마중 시간이 겹친 걸 알아채고 대신 차를 불러주자고 제안함. 콘서트 티켓 오픈 시점을 알려주고 봄방학 여행지도 추천해줌.
  8. 같은 영상에서 집 카메라를 확인해 반려견 상태까지 알려주는 장면도 나와, 한 흐름 안에서 여러 기기를 넘나들며 일을 처리함을 보여줌.
  9. 이 영상을 보여준 이유는 규모에서 나오는 에이전트의 힘을 보여주기 위해서라며, 지금 전 세계에 나가 있는 알렉사 기기가 6억 대가 넘는다는 숫자를 언급함.
  10. 알렉사 플러스는 수백 개의 특화된 "전문가 시스템(expert system, 특정 작업 하나를 해내기 위한 기능·API·지시 묶음을 가리키는 알렉사 팀의 용어)"으로 움직인다고 설명함.
  11. 이 전문가들은 다시 수만 개의 파트너 서비스·기기와 오케스트레이션하며 일을 처리하는데, 앞선 영상에서 그 일부를 본 것이라고 함.
  12. 각자 고유한 능력을 가진 특화된 에이전트들이 서로 매끄럽게 협업하는 것이 앞으로의 모습이 될 것이라고 밝힘.
  13. 이런 규모를 실제로 어떻게 운영하는지, 즉 수년간 만들어온 웹 서비스에서 에이전트형 서비스로 어떻게 넘어가는지를 물음.
  14. 다행히 밑바탕 원칙은 수백만 대 기기를 상대하든, 기업용 애플리케이션에 AI를 통합하든, 스타트업이 아이디어를 키우든 다르지 않다고 함.
  15. 두 번째 예시로 AWS가 만든 에이전트형 서비스인 아마존 Q 디벨로퍼(Amazon Q Developer)를 소개함. 소프트웨어 개발 생명주기 전반을 돕는 코드 어시스턴트라고 함.
  16. 몇 달 전 CLI(명령줄 인터페이스)용 Q 디벨로퍼 에이전트를 출시했다고 함. 터미널 안에서 에이전트형 대화를 나누고 문제를 디버그하고 자연어로 질문하고 파일을 읽고 쓰게 했다고 함.
  17. 시연에서 CLI에 "아마존 베드록(Bedrock)에 대해 뭘 아냐"고 묻자 MCP(모델 컨텍스트 프로토콜, LLM이 외부 데이터·도구에 표준화된 방식으로 접속하게 해주는 개방형 규격)로 연결된 AWS 문서팀의 MCP 서버를 스스로 찾아냈다고 함.
  18. 권한을 요청해 승인받은 뒤 공식 AWS 문서에 근거한 답을 내놨다고 함.
  19. 이 에이전트형 서비스를 AWS 내부 팀이 만들어 배포하기까지 걸린 기간을 청중에게 손 들어 맞혀보라고 물음. 두 달, 세 달, 반년이라는 추측이 나왔다고 함.
  20. 정답은 3주였다고 밝힘. 이 속도가 앞선 다른 키노트 발표자가 짚은 "AI의 시대정신은 실행"이라는 말을 그대로 보여준다고 함.
  21. 그럼 AWS뿐 아니라 누구나 이렇게 빠르게 프로덕션급 AI 에이전트를 만들고 배포하게 하려면 어떻게 해야 하는지를 물음.
  22. AWS 내부 팀은 에이전트를 만드는 방식 자체를 근본적으로 다시 생각해야 했고, 그 결과가 모델 중심(model-driven) 접근이라고 함.
  23. 이 접근은 판단·계획·추론·행동을 갈수록 잘하는 모델의 힘에 기댐. 개발자는 에이전트가 정확히 어떻게 할지가 아니라 무엇을 해야 하는지에만 집중하게 한다고 설명함.
  24. 이 방식을 몇 주 전 오픈소스 파이썬 SDK인 스트랜즈 에이전트(Strands Agents)로 공개해 누구나 몇 줄 코드로 AI 에이전트를 만들고 돌릴 수 있게 했다고 함.
  25. 이름에 얽힌 뒷이야기로, AI에게 스스로 이름을 짓게 했더니 DNA의 두 가닥(strand)이 모델과 도구라는 에이전트의 두 핵심 조각을 잇는다는 뜻에서 "스트랜즈"를 골랐다고 함.
  26. 프롬프트와 도구를 코드로 정의하고 로컬에서 테스트한 뒤, 준비되면 클라우드 등에 배포하는 식으로 에이전트 만들기를 단순화했다고 함.
  27. 실제 코드는 스트랜즈 에이전트를 설치하고 불러온 뒤 미리 만들어진 도구들을 에이전트에 붙이면, 바로 질문하거나 더 복잡한 워크플로를 짤 수 있을 만큼 짧다고 보여줌.
  28. 기본 모델 제공자는 아마존 베드록이고 시연에서는 클로드(Claude) 3.7 소네트를 썼지만, AWS에만 묶여 있지 않다고 함.
  29. 로컬에서 개발·테스트할 수 있는 통합에 더해 LiteLLM 통합을 거치면 오픈AI 등 다른 제공자 모델도 쓸 수 있고, 직접 만든 모델 제공자도 붙일 수 있다고 함.
  30. 스트랜즈 에이전트에는 미리 만든 도구가 20개 넘게 들어 있어, 파일 조작이나 API 호출 같은 단순 작업부터 AWS 서비스 연동, 더 복잡한 활용까지 바로 쓸 수 있다고 함.
  31. 그중 메모리·RAG(모델이 답하기 전에 외부 문서를 먼저 찾아와 그 내용을 근거로 쓰게 하는 방식) 관련 도구 묶음이 있음. "retrieve"라는 도구는 지식베이스를 의미 기반으로 검색해준다고 함.
  32. 이 힘을 보여주는 사례로 AWS 내부에는 도구를 6,000개 넘게 관리하는 에이전트가 있다고 함.
  33. 6,000개 도구는 한 모델의 컨텍스트 창(context window, 모델이 한 번에 참고할 수 있는 텍스트 범위)에 통째로 넣고 고르게 하기엔 너무 많은 숫자라고 짚음.
  34. 그래서 도구 설명들을 지식베이스에 넣어두고 retrieve 도구로 그때그때 작업에 맞는 도구만 찾아 모델 컨텍스트로 끌어오게 했다고 함.
  35. 이미지·영상·음성을 아우르는 멀티모달 지원, 더 깊이 생각하게 유도하는 도구도 스트랜즈에 들어 있다고 함.
  36. 그래프 기반 워크플로나 여러 서브 에이전트가 떼지어 함께 움직이는 스웜(swarm) 형태의 멀티 에이전트 워크플로용 도구도 미리 만들어져 있다고 함.
  37. 도구를 이야기하면서 MCP를 빼놓을 수 없다며, 스트랜즈에 MCP를 자체 내장해 수천 개 MCP 서버를 그대로 에이전트 도구로 쓸 수 있게 했다고 함.
  38. A2A(에이전트가 다른 에이전트와 직접 통신하는 프로토콜) 지원도 곧 나온다고 함.
  39. AWS 위에서 만든다면 자신들이 운영하는 MCP 서버 구현 모음 깃허브 저장소를 북마크해두라고 권함. AWS용 MCP 서버 구현이 계속 늘어나고 있다고 함.
  40. MCP 서버가 처음 나왔을 때는 로컬 프로세스끼리 표준입출력(standard I/O)으로 통신하는 방식이 기본이었다고 함. 로컬 시스템의 클라이언트와 도구를 연결하려고 만들어진 방식이라고 설명함.
  41. 시연용으로 파이썬 SDK의 FastMCP를 써서 만든 표준입출력 방식 MCP 서버를 보여줌. 주사위를 굴리는 도구 하나만 데코레이터로 정의한 아주 단순한 예시라고 함.
  42. 이 주사위 굴리기 데모는 동료 마이크 챔버스(Mike Chambers)가 만들었다고 함. 자신은 D&D를 이번에 처음 배웠다며 20면체 주사위를 예로 듦.
  43. 이제 이 MCP 서버를 로컬이 아니라 원격에서, 즉 규모를 키워 쓰기 위해 AWS 람다(Lambda) 함수로 배포하고 스트리머블(streamable) HTTP로 연결한다고 함.
  44. 람다 함수를 MCP 게이트웨이 뒤에 두는 구조는 기존과 같다고 함. 보안을 위해 이번 데모에서는 인가자(authorizer)를 쓰며 코그니토(Cognito)로 대체할 수도 있다고 함.
  45. 세션 데이터는 다이나모DB(DynamoDB) 테이블에 저장한다고 함.
  46. 람다용 MCP 핸들러를 깃허브 저장소에 공개해뒀고, 이걸 쓰면 람다에서 MCP 서버를 훨씬 쉽게 세울 수 있다고 함.
  47. 서버 코드에는 다이나모DB 세션 테이블 지원과 앞서 본 주사위 굴리기 도구가 들어감. 이번엔 그 도구가 람다 함수로 호스팅된다는 점이 다르다고 함.
  48. AWS SAM(서버리스 애플리케이션 모델)으로 이 람다를 배포하면 API 게이트웨이 URL을 받는다고 함.
  49. 클라이언트 쪽에서는 스트랜즈 에이전트가 이 URL로 접속해 베어러 토큰(권한을 증명하는 인증 토큰)으로 인가받고, MCP 도구 목록을 가져와 에이전트에 붙인다고 함.
  50. 실제로 20면체 주사위를 굴려달라고 시키자 원격 람다의 MCP 도구가 호출돼 7이 나왔다고 함.
  51. 요점은 일단 AWS와 람다 안에 있으면 람다로 만들 수 있는 모든 것, 즉 이미 AWS에 구축해둔 기능·역량·애플리케이션 전체에 그대로 접근할 수 있다는 것이라고 함.
  52. 다음 단계는 에이전트끼리 서로 말하게 하는 것이라며, MCP를 중심으로 떠오르는 개방형 프로토콜들에 AWS가 흥분해 있다고 함.
  53. AWS는 MCP 운영위원회(steering committee)에 참여해 코드를 기여하고 프로토콜 발전을 돕고 있으며, 오픈소스 블로그에 관련 시리즈를 연재 중이라고 함.
  54. 마지막으로 동료 대니엘(Danielle)이 전날 발표에서 한 말을 인용함. "모든 디지털 상호작용의 최소 단위는 에이전트 호출이 될 것"이라고 함.
  55. 개인 에이전트가 "에이전트 스토어" 같은 곳에 접속해 여러 에이전트가 함께 일을 처리해주는 미래를 그리며, 청중 중 이미 이런 걸 만들고 있는 사람도 있을 거라고 함.
  56. 발표를 마치며 동료 마이크는 주사위 굴리기 데모와 MCP·스트랜즈를 더 깊이 다루는 세션을, 동료 수만(Suman)은 다음 날 스트랜즈 딥다이브 세션을 연다고 안내함.

한줄 코멘트. 3주 만에 만들었다는 속도와 6억 대·6,000개 도구라는 규모는 인상적인데, 정작 모델이 무엇을 할지 스스로 판단하게 맡긴 그 지점에서 잘못된 선택을 걸러내는 장치가 무엇인지는 이 발표에서 짚지 않음.

  1. 발표자는 마이크로소프트(Microsoft) 소속 존 펙(Jon Peck)이며, 깃허브 코파일럿(GitHub Copilot) 에이전트 모드에 MCP(모델 컨텍스트 프로토콜, LLM이 외부 데이터·도구에 표준화된 방식으로 접속하게 해주는 개방형 규격)를 실전에 붙이는 법을 다루는 세션이라고 밝힘.
  2. 코파일럿은 코드 완성(code completion)에서 시작했다고 함. 타이핑하는 순간마다 제안을 주고 함수 전체를 완성해주는, 아주 짧은 단위로 상호작용하는 단계였다고 설명함.
  3. 다음 단계는 챗(chat)이었는데, 복잡한 프롬프트 하나를 주면 여러 파일을 한 번에 만들거나 고쳐주는 원홉(one-hop) 방식이었다고 함.
  4. 에이전트 모드는 완전한 작업 하나를 끝까지 맡기고 만드는 동안 깊게 상호작용하는 단계라고 구분함.
  5. 할 일을 주면 에이전트가 일하는 동안 계속 개입해서 터미널에서 뭘 해도 되는지 알려주고 응답을 읽게 한다고 함.
  6. 이 단계로 할 수 있는 일은 완전 그린필드(greenfield, 기존 코드 없이 처음부터 새로 만드는 프로젝트) 앱을 짓는 것부터 큰 코드베이스를 깊게 리팩터링하는 것까지, 중간 정도 복잡한 작업이라고 함.
  7. 실제 예시로 코드가 하나도 없고 리드미(README) 파일만 있는 저장소를 보여줌. 무엇을 만들지, 프로젝트 구조, 다른 개발자에게 쓰듯 환경 변수 설정법까지 담겨 있었다고 함.
  8. 리드미 안에는 데이터베이스 스키마, 쓰고 싶은 API 엔드포인트, 워크플로 그래프까지 넣을 수 있다고 함.
  9. 비전(vision, 이미지를 이해하는) 기능이 있는 LLM이면 이런 그래프를 이미지로 넣어도 읽어내고, 비전이 없는 모델을 쓸 때는 머메이드(Mermaid) 같은 텍스트 기반 다이어그램 도구를 쓴다고 함.
  10. 리드미를 이렇게 완전하게 채워두면 코파일럿을 에이전트 모드로 바꾸고 모델을 고른 뒤 "가서 이걸 구현해"라고만 말하면 된다고 함.
  11. 에이전트가 데이터 모델을 만들고 앱 뼈대를 뽑아내고 프런트엔드 작업을 시작하는 식으로 진행된다고 함.
  12. 화면에 계속(continue) 버튼이 뜨는 순간은 에이전트가 터미널과 상호작용하고 싶어하는 때라고 함. 계속하기 전에 개발자 허락을 반드시 받아야 한다고 밝힘.
  13. 터미널에서 뭔가 잘못되면 그 응답을 읽고 반응한다고 함. 이 시연은 실시간으로 약 8분 걸렸고 끝에는 기본적으로 동작하는 앱이 나왔다고 함.
  14. 스타일은 안 예쁘지만 여행 예약을 하고 방을 고르는 등 실제로 작동했다고 함. 이게 기본적인 에이전트 모드 상호작용이라고 정리함.
  15. 이제 여기에 MCP를 더한다고 함. 지난 1년 사이 인터넷에서 MCP 얘기를 못 들어봤을 리 없다며 짧게 복습하고 넘어감.
  16. MCP를 쓰면 LLM이 외부 데이터 소스나 참조 자료에 접속해 정보를 가져올 수 있는데, 일반적인 정보일 수도, 인증을 붙였다면 계정에 특정된 정보일 수도, 그냥 조언일 수도 있다고 함.
  17. MCP 서버 목록은 github.com/modelcontextprotocol/servers에 있고, 발표 자료와 영상은 gh.io/fair/mcp에서 볼 수 있다고 안내함.
  18. 메커니즘을 설명함. VS Code 같은 IDE에 어떤 MCP를 쓸지 설정해두면 코파일럿이 그 설정을 인식하고, 요청이 오면 맞는 MCP를 골라 연결해서 필요한 걸 가져온다고 함.
  19. MCP 서버는 로컬 데이터베이스에 연결하는 로컬 서버일 수도, 웹 API에 접속하는 서버일 수도 있다고 함.
  20. 또는 SSE(서버센트이벤트) 프로토콜로 원격 서버에서 돌아가는 MCP일 수도 있는데, 이러면 보호된 환경에서 작업하고 결과만 IDE로 돌려준다고 함.
  21. 실제 사용법을 시연함. 포스트그레스(PostgreSQL)를 쓰는 상황을 가정해, 로컬 데이터베이스 데이터를 목(mock, 실제 데이터를 흉내 낸 가짜 데이터)으로 써서 테스트를 만들고 싶다는 목표를 세움.
  22. 깃허브 모델컨텍스트프로토콜 저장소에서 포스트그레스 MCP를 찾음. 직접 설치할 수도 있지만, VS Code는 원클릭 설정 버튼을 제공해서 그걸 눌렀다고 함.
  23. 버튼을 누르면 VS Code가 활성화되며 "이 서버를 설치할까?"라고 물었고, 설치를 승인하자 설정 파일(settings.json)에 추가됐다고 함.
  24. 처음 추가될 때는 빈 연결 문자열 기본값만 들어있어서 본인 정보로 직접 채워야 했다고 함.
  25. 로컬 무인증 포스트그레스라 인증 토큰은 필요 없었지만, 원격 데이터베이스나 운영 환경이었다면 제대로 된 인증을 붙였을 거라고 함.
  26. 연결 문자열을 채운 뒤 시작 아이콘을 눌러 로컬 MCP 서버를 구동하면 그때부터 연결해 쓸 수 있다고 함.
  27. 챗 영역의 작은 도구(툴) 아이콘을 누르면 현재 쓸 수 있는 MCP 서버 목록이 뜨고, 여기서 켜고 끌 수 있다고 함.
  28. 코파일럿에게 포스트그레스로 뭔가 해달라고 요청함. 명시적으로 "포스트그레스 MCP를 써라"라고 지정하지 않으면 알아서 고를 때도 못 고를 때도 있어서, 본인은 항상 명시적으로 말하는 습관을 들였다고 함.
  29. 요청한 작업은 포스트그레스 데이터베이스에서 데이터를 가져와 테스트에 쓸 mock.json 파일을 만드는 것이었다고 함.
  30. 에이전트가 연결해도 되냐고 허락을 구하는 걸 확인함. 터미널 작업 때와 마찬가지로 데이터베이스를 함부로 건드리지 못하게 매번 허락을 받게 되어 있다고 함.
  31. 이 포스트그레스 MCP는 읽기 전용(read-only)으로만 동작한다는 점을 특히 마음에 든다고 밝힘. 모든 MCP가 이렇지는 않다고 덧붙임.
  32. 데이터를 읽어 로컬 IDE에서 쓸 수는 있지만 데이터베이스를 실수로 바꿀 일이 없어서 안전하다고 그 이유를 설명함.
  33. 에이전트가 데이터를 가져와 mock JSON을 만들고, 이어서 그 데이터로 테스트 코드를 짜는 나머지 작업까지 잘 진행됐다고 함.
  34. 이 과정에서 실제로 무슨 일이 일어났는지 짚음. 코파일럿이 프롬프트를 해석해 MCP 연결이 필요하다는 걸 스스로 파악하고, 개발자에게 연결 허락을 구한 뒤 MCP 서버를 호출한다고 함.
  35. MCP는 데이터베이스에 필요한 걸 물어보는데, 먼저 스키마를 가져오고, 다음으로 필요한 테이블을 골라내고, 그다음 그 테이블에서 데이터를 뽑아내는 식으로 코파일럿과 단계별로 주고받는다고 설명함.
  36. 코파일럿은 이 응답들을 해석해 파일을 만들고, 그 결과를 이어지는 맥락(컨텍스트)에 계속 쌓아가며 나머지 작업을 한다고 함.
  37. 첫 프롬프트가 한 번에 딱 맞을 리 없다며, 그래서 리드미 파일을 쓰고 또 코파일럿 인스트럭션(copilot-instructions)이나 프롬프트 파일을 선택적으로 VS Code에 넣어 쓰라고 권함.
  38. 마지막으로 깃허브(GitHub) 자체가 제공하는 MCP 서버를 소개함. 깃 명령줄이나 깃허브 사이트에서 직접 버튼을 누르는 수고를 덜어줘서 좋아한다고 함. 자기 회사가 만든 MCP를 소개하는 대목임.
  39. 같은 방식으로 찾아서 VS Code에 추가하는데, 이번엔 계정에 특정된 정보가 필요해서 깃허브 개인 액세스 토큰을 만들어 넣어야 한다고 함. 화면에 뜨는 토큰은 블러 처리했다고 언급함.
  40. 토큰을 넣고 MCP 서버를 시작하면 그 개인 액세스 토큰으로 연결된다고 함.
  41. 본인이 모범 사례로 꼽는 걸 하나 짚음. 코파일럿 인스트럭션은 `.github/copilot-instructions.md`라는 특정 이름의 파일에 넣어두면 모든 프롬프트에 미리 끼워 넣어지는 내용이라고 설명함.
  42. 여기에는 PEP 8(파이썬 코드 스타일 규칙) 준수 여부, 새로 설치한 것에 보안 점검을 돌릴지 같은 표준을 넣는데, 그중 하나로 지금까지 한 작업의 변경 로그를 계속 남기라는 지시를 넣는다고 함.
  43. 커밋을 점진적으로 쌓아 깃 히스토리가 남기긴 하겠지만, 변경 로그를 명시적으로 남기게 하면 매 단계 에이전트가 뭘 했는지 훨씬 잘 파악된다고 이유를 밝힘.
  44. 이렇게 작업을 다 끝낸 뒤 "깃허브 MCP를 써서 이 변경 사항을 새 브랜치에 커밋하고 PR(풀 리퀘스트, 코드 변경을 검토받기 위해 올리는 요청)을 만들어라"라고 한 번에 지시한다고 함.
  45. 원래 깃 명령을 직접 만지거나 VS Code에서 수동으로 하거나 사이트에 나가 PR을 만들어야 했던 일을 한 문장으로 시킬 수 있다는 뜻이라고 함.
  46. 이 과정도 연결 허락을 구한 뒤 브랜치를 만들고 PR을 생성하는 순서로 진행된다고 함.
  47. 발표 참고 자료는 gh.io/fair/mcp에 있고, 마지막 슬라이드에 VS Code에서 MCP를 설치하는 법 등을 정리해뒀다고 안내함.
  48. 질의응답에서 "이슈를 코파일럿에게 배정하는" 웹 UI 기반 코딩 에이전트가 앞서 보여준 방식과 앞으로 하나로 합쳐질지 질문받음.
  49. 아직 정해진 게 없다며, 1인 개발자의 관심사와 기업의 관심사가 달라서 지금은 이 방식을 좀 더 기업용 기능으로 그리고 있다고 답함. 자율적으로 돌아가고 다른 개발자에게 넘겨 팀처럼 쓰는 성격이 강하기 때문이라고 함.
  50. 이 방식은 깃허브닷컴(github.com)에서 새 이슈를 만들고 담당자로 코파일럿을 지정하면, 코파일럿이 백그라운드에서 일하고 github.com에서 확인할 수 있는 세션을 주며 PR로 결과를 내놓는 식이라고 설명함.
  51. 여기서도 MCP를 쓸 수 있는데, 저장소 설정의 코파일럿 항목 아래에서 MCP 설정을 넣으면 된다고 덧붙이며 발표를 마침.

한줄 코멘트. 읽기 전용 포스트그레스 MCP처럼 안전장치를 갖춘 사례를 보여준 건 좋은데, 정작 코파일럿이 어떤 MCP를 써야 할지 스스로 못 골라내 매번 이름을 못박아 줘야 한다고 밝힌 대목이 이 통합이 아직 손이 많이 가는 단계라는 걸 드러냄.

  1. 이 발표는 블룸버그(Bloomberg) AI 엔지니어링 총괄인 안주 캄바두르(Anju Kambadur)가 AI Engineer 컨퍼런스에서 한 것임. 주제는 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)를 회사 규모로 어떻게 키우는가임.
  2. 블룸버그는 AI에 15~16년째 투자해온 회사로, 2021년 말 LLM(거대언어모델)이 주목받기 시작하자 자체 LLM을 만들기로 결정했다고 함.
  3. 2022년 한 해를 자체 LLM 개발에 쏟았고, 2023년에는 그 모델을 다룬 논문을 냈다고 밝힘.
  4. 그런데 챗GPT가 터지고 오픈소스·오픈웨이트(모델 가중치까지 공개된) 커뮤니티가 빠르게 성장하자, 회사는 전략을 바꿔 이제는 외부에 이미 나와 있는 것 위에 쌓아 올리는 쪽으로 방향을 틀었다고 함.
  5. 발표자는 글로벌 엔지니어링 총괄에게 보고하며, 데이터 조직·제품·CTO 조직과 함께 일하는 별도 그룹 형태로 조직돼 있다고 밝힘.
  6. 이 그룹은 런던·뉴욕·프린스턴·토론토에 흩어진 약 400명, 50개 팀 규모임.
  7. 생성형 AI로 제품을 만든 지는 오래됐지만, 도구보다 더 자율적인 에이전트 형태로 진지하게 만든 지는 12~16개월 됐다고 함.
  8. 사내에서 "에이전트"와 "도구"라는 말이 팀마다 다르게 쓰여 혼란스러웠는데, 「언어 에이전트를 위한 인지 구조(Cognitive Architectures for Language Agents)」라는 논문을 기준으로 용어를 통일했다고 함.
  9. 그 논문 기준으로 도구는 자율성이 낮은 쪽이고, 에이전트는 기억을 가지고 스스로 진화할 수 있는 더 자율적인 쪽을 가리킨다고 정의함.
  10. 블룸버그는 핀테크 회사이고 고객은 금융업계 종사자인데, 그 안에서도 직군이 10가지로 나뉠 만큼 다양하다고 함.
  11. 회사가 매일 다루는 데이터 규모를 짧게 짚었는데, 구조화 데이터가 하루 4천억 건, 비정형 메시지가 10억 건 이상, 뉴스를 포함한 잘 쓰인 문서가 매일 수백만 건씩 쌓이고, 이런 데이터가 40년 넘게 누적돼 있다고 함.
  12. 발표는 그중 한 직군인 리서치 애널리스트(특정 분야를 전문으로 조사·분석하는 사람)에 초점을 맞춰서 진행됨.
  13. 리서치 애널리스트는 AI나 반도체, 테크, 전기차 같은 특정 분야를 전문으로 다루는 사람이라고 예를 듦.
  14. 이들의 일과는 크게 넷으로 나뉘는데, 비정형 데이터를 검색·발견·요약하는 일, 구조화 데이터를 다루는 분석 업무, 동료와 정보를 주고받는 커뮤니케이션, 그리고 데이터를 정규화해 직접 모델을 만드는 작업임.
  15. 블룸버그는 창업한 지 40년 된 금융 회사라서 제품에 타협할 수 없는 기준이 있다고 함. 정확성·포괄성·속도·처리량·가용성, 그리고 제공자와 고객 데이터를 보호하고 전 과정을 투명하게 유지하는 것임.
  16. 이 기준은 AI를 쓰든 안 쓰든 그대로 적용되고, 이게 오늘날 에이전트를 만들 때 부딪히는 문제의 배경이 된다고 설명함.
  17. 2023년에 진지하게 손댄 첫 제품은 상장기업들의 분기 실적 발표 콜(경영진 발표와 애널리스트 질의응답으로 이뤄짐) 요약이었음.
  18. 실적 발표 시즌에는 하루에도 여러 회사의 콜이 동시에 열리는데, 리서치 애널리스트는 이걸 매일 다 챙겨봐야 하니 콜 내용을 글로 옮기고 요약하는 일에 AI를 붙였다고 함.
  19. 업종별로 애널리스트가 궁금해할 질문이 어느 정도 정해져 있다는 점에 착안해, 그 질문에 미리 답을 만들어 애널리스트가 더 깊이 파고들지 말지 판단하게 하는 제품이었다고 함.
  20. 막상 만들어보니 정확도·사실성 같은 기본 성능이 그대로 쓰기엔 부족했고, 이를 보완하려고 문제를 걸러내는 워크플로와 서킷 브레이커(오류가 감지되면 자동으로 흐름을 멈추는 장치)를 따로 구축했다고 함.
  21. 이 요약은 챗봇처럼 한 사람만 보고 마는 게 아니라 그대로 발행돼 여러 사람이 함께 보기 때문에, 오류 하나가 미치는 영향이 크다는 점이 이 작업을 더 무겁게 만들었다고 함.
  22. 그래서 지금도 성능을 계속 모니터링하고 문제를 고치는 작업이 이어지고, 그 뒤에 상당한 모니터링과 CI/CD(코드를 자동으로 검증하고 배포하는 절차)가 돌아간다고 밝힘.
  23. 지금 블룸버그가 만드는 에이전트는 "세미 에이전틱(semi-agentic, 일부만 자율에 맡기고 나머지는 정해진 규칙을 강제로 거치게 하는 방식)"이라고 부르는데, 모든 걸 자율에 맡길 만큼 아직 신뢰하지 않기 때문이라고 함.
  24. 예로 든 게 가드레일(정해진 규칙을 벗어난 답을 못 내놓게 막는 장치)인데, 블룸버그는 투자 자문을 하지 않는 회사라서 누가 "이거 투자해도 되냐"고 물으면 그 질문을 걸러내고 사실에 근거해서만 답하게 강제로 코딩해 둔다고 함.
  25. 여기까지가 배경이고, 이제부터는 발표의 본론인 "스케일링(규모 키우기)"의 두 축을 다룬다고 함.
  26. 첫 번째 축은 에이전트를 빠르게 개선해나가는 문제임. 처음 만든 버전은 어차피 부족하니 계속 고쳐나가야 한다는 전제에서 출발함.
  27. 발표자는 자신이 대학원생 때 많이 쓰던, 행렬과 행렬을 곱하는 연산을 제공하는 API를 예로 듦. 입력·오류코드·처리시간까지 문서화가 잘 돼 있어서 그 위에 뭘 쌓아도 안정적으로 작동했다고 함.
  28. 20여 년 전부터 머신러닝 모델을 API나 파이프라인 형태로 쓸 때는 결과에 어느 정도 불확실성(stochasticity)이 있어도, 입력과 출력의 분포를 미리 알고 있으면 그런대로 다룰 만했다고 함.
  29. 그런데 LLM과, LLM을 여러 개 엮은 에이전트로 넘어오면 이 불확실성이 단계마다 곱해지듯 커져서 시스템 전체가 쉽게 취약해진다고 함.
  30. 이 취약함을 어떻게 피할지 설명하려고 2009년에 만든 뉴스 감성분석 제품을 예로 듦. 특정 회사에 관한 뉴스 한 건이 그 회사에 호재인지 악재인지 판정하는 제품이었다고 함.
  31. 그 제품은 어떤 뉴스와이어를 모니터링하는지, 어떤 언어인지, 그 와이어가 어떤 편집 원칙을 따르는지까지 알고 있었고, 출력값도 -1에서 +1 사이로 단순했다고 함.
  32. 학습 데이터도 자체 구축했기 때문에 시간과 대상을 완전히 분리한 홀드아웃(검증용으로 따로 떼어놓은) 테스트셋을 만들 수 있었고, 그래서 배포 전 위험을 가늠하고 계속 모니터링할 수 있었다고 함.
  33. 그런데도 가드레일을 다 갖춰놨음에도 다운스트림(이 결과를 받아 쓰는 쪽) 고객들과 별도로 소통해야 하는 일이 계속 있었다고 함. 예를 들어 모델 버전을 바꿀 때는 미리 알려줘서 그쪽에서 테스트하게 했다는 것임.
  34. 에이전트 아키텍처로 오면 이 문제가 훨씬 커지는데, 에이전트는 매일매일 고쳐나가고 싶은데 그때마다 배치로 회귀 테스트를 돌리고 릴리스하는 절차를 거치기엔 다운스트림 고객 수가 너무 많고, 그 고객들도 각자 독립적으로 자기 쪽을 계속 고치고 있기 때문이라고 함.
  35. 이걸 보여주는 예로, 리서치 애널리스트용 구조화 데이터 에이전트에 "최근 5개 분기 미국 CPI(소비자물가지수)"를 물었던 사례를 듦.
  36. 질문을 이해하는 에이전트가 어느 도메인으로 보낼지 정하고, 자연어 입력을 받는 앞단이 붙은 도구를 불러 실제 데이터를 가져오는 구조였다고 함.
  37. 그런데 가져온 데이터가 틀렸는데, 원인은 글자 하나가 빠져서 월간 데이터를 분기 데이터로 잘못 가져온 것이었다고 함.
  38. 표를 그대로 보여주는 화면이면 숙련된 애널리스트가 바로 알아챘겠지만, 표는 안 보여주고 "답은 42입니다" 식으로 결과만 보여주는 다운스트림 워크플로에서는 이런 오류가 층층이 쌓여도 잡아내기가 매우 어렵다고 함.
  39. 그래서 얻은 교훈은, 위쪽 시스템(데이터·분석 도구)이 정확할 거라고 믿지 말고 오히려 언제든 흔들리고 계속 바뀔 거라 가정한 뒤, 자기 쪽에서 스스로 안전장치를 두는 편이 낫다는 것임.
  40. 데이터·분석 API나 도구의 새 버전이 나올 때마다 평균적으로는 더 나아지지만, "평균적으로 낫다"는 것이 자신의 특정 다운스트림 용도에도 낫다는 뜻은 아니라고 짚음.
  41. 이런 안전장치를 각 에이전트 안에 심어두는 게 오히려 속도를 더 빠르게 만든다고 함. 새 에이전트를 베타나 프로덕션으로 올릴 때마다 모든 다운스트림 호출자에게 변경 사항을 확인시키고 승인받는 핸드셰이크(서로 확인을 주고받는 절차)를 거치지 않아도, 각 에이전트가 알아서 진화할 수 있기 때문임.
  42. 두 번째 축은 조직·아키텍처 구조 문제임. 발표자는 코딩을 손에서 놓은 지 오래된 매니저라 이 부분이 더 흥미로울 거라고 밝힘.
  43. 블룸버그는 전통적인 머신러닝을 15년 넘게 만들어온 회사라 소프트웨어를 나누는 방식이 조직 구조에도 그대로 반영돼 있었다고 함. 운이 좋으면 콘웨이의 법칙(조직 구조가 소프트웨어 구조를 결정한다는 법칙)이 거꾸로 작동해서 원하는 조직 구조로 소프트웨어가 나뉜다고 덧붙임.
  44. 새로운 기술 스택으로 다른 종류의 제품을 만들려면 이 조직 구조부터 다시 생각해야 한다고 함. 에이전트를 몇 개나 만들지, 각 에이전트가 뭘 맡을지, 기능이 서로 겹쳐도 되는지 같은 기본 질문부터 다시 던져야 한다는 것임.
  45. 기존 소프트웨어 스택과 조직 구조를 그대로 두고 그 위에 얹고 싶은 유혹이 크지만, 실제로는 그래선 안 된다는 걸 재조직을 겪으며 배웠다고 함.
  46. 팀을 수직으로 묶을지 수평으로 묶을지를 두 축으로 놓고 보면, 제품 설계가 아직 뭔지 잘 모르는 초기 단계에는 소프트웨어 스택을 하나로 뭉쳐서 한 팀이 코드·데이터·모델을 공유하며 빠르게 반복하는 게 낫다고 함.
  47. 하나의 제품이나 에이전트를 겪으며 이해가 쌓여서 뭐가 잘 되고 뭐가 안 되는지 알게 되고 그런 에이전트가 여러 개로 늘어나면, 그때부터는 성능을 높이고 비용을 줄이고 테스트하기 쉽고 투명하게 만드는 쪽으로, 즉 좋은 소프트웨어와 조직의 기본으로 돌아가야 한다고 함.
  48. 이 단계에서 일부 기능을 수평으로 떼어내게 되는데, 가드레일이 그 예임. 50개 팀이 각자 알아서 "투자 자문처럼 보이는 질문을 어떻게 걸러낼지"를 따로 풀게 하고 싶지 않다는 것임.
  49. 다만 언제 수평 조직을 만들고 하나로 뭉쳐 있던 에이전트를 언제 더 작은 조각으로 쪼갤지는 회사마다, 조직마다 스스로 판단해야 할 몫이라고 함.
  50. 지금 리서치 에이전트의 실제 구조를 보면, 사용자와 세션 맥락을 이해하고 질문의 의도를 파악하는 부분이 하나의 에이전트로 따로 떼어져 있음.
  51. 답을 만들어내는 부분도 별도 에이전트로 떼어져 있는데, 여기엔 "잘 만들어진 답이란 무엇인가"를 가르는 엄격한 기준이 들어가 있다고 함.
  52. 이 답변 생성 부분을 다시 "세미 에이전틱"이라고 부르는데, 여러 지점에서 가드레일을 반드시 거쳐야 하고 그 지점에는 자율성을 주지 않기 때문이라고 강조함.
  53. 이 구조는 오랫동안 쌓아온 전통적인 데이터 처리 기술과, 검색용 인덱스(자료를 빠르게 찾도록 미리 정리해둔 색인)가 희소 방식에서 밀집·하이브리드 방식으로 진화한 최신 기술 위에 세워져 있다고 함.
  54. 발표자는 시간이 다 됐다며 마무리하는데, 전체 흐름을 보면 새 기술을 무작정 얹기보다 회사가 오래 지켜온 정확성·투명성 기준에 새 기술을 맞추는 데 훨씬 공을 들인 발표였음.

한줄 코멘트. 요는 에이전트를 매일 고쳐 내보내려면 다운스트림이 알아서 흔들릴 거라 가정하고 자기 쪽에서 방어막부터 치는 게 먼저고, 조직을 수평으로 쪼개는 것도 처음부터 정답이 아니라 기술이 안정된 뒤에야 할 일이라는 점임.

05

평가 · 결과물 품질

  1. 이 발표는 브레인트러스트(Braintrust)의 필드 CTO(고객사를 직접 만나 기술을 지원하는 최고기술책임자) 아마야 바타드카르(Ameya Bhatawdekar)가 한 것임. 브레인트러스트는 AI 팀이 자기 시스템을 확신을 갖고 만들고 개선하도록 돕는 평가(eval)·관측(observability) 플랫폼이라고 소개함.
  2. 지난 몇 년 사이 챗봇이든 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)든 배치 처리든, 모델을 중심에 둔 애플리케이션을 다들 하나씩은 만들어봤을 것이라고 함.
  3. 그 사이 애플리케이션을 완전히 새로 짰거나 큰 수술을 했을 텐데, 처음 만들었을 때와 지금 모습이 아주 다를 거라고 함.
  4. 데모를 만들기는 쉬워도 프로덕션 품질로 끌어올리기는 어렵다는 패턴을 다들 겪었을 것이라고 함. 이 어려움은 잘못 만들어서가 아니라 주변 시스템 자체가 빠르고 역동적으로 바뀌기 때문이라고 함.
  5. 모델이 바뀌고, 사용자가 앱을 쓰는 방식이 바뀌고, 앱이 다루는 데이터도 함께 바뀐다고 함. 지난 몇 년 모델이 진화한 속도는 정말 놀랍다며, 몇 달마다 새 버전이 나올 때마다 이전 세대엔 없던 능력이 대거 풀렸다고 함.
  6. 툴을 다루는 능력이 좋아진 모델, 아주 긴 컨텍스트(context, 모델이 한 번에 참고하는 입력 범위)를 다루는 모델이 차례로 등장했다고 함. 샌드박스(sandbox, 코드를 안전하게 격리해 실행하는 공간)에서 안전하게 도는 코드를 짜는 모델, 실전에 쓸 만큼 정교해진 메모리 시스템도 뒤이어 나왔다고 함.
  7. 이런 진전은 하나하나가 사소한 업그레이드가 아니라 계단식(step function) 변화였다고 함. 그래서 지금은 애플리케이션을 조금씩 다듬던 시기에서 판을 새로 까는(replatforming) 시기로 넘어가고 있다고 함.
  8. 새 모델을 그냥 갈아 끼운다고 시스템이 그대로 잘 돌아가진 않는다고 함. 예전 시스템이 그 시절 모델의 한계와 제약을 전제로 짜여 있기 때문이라고 함.
  9. 모델이 툴 호출을 잘 못하던 시절엔 그 한계를 메우려고 시스템에 로직을 잔뜩 심어뒀다고 함. 새 모델을 넣어도 시스템을 크게 뜯어고치지 않으면 그 새 능력을 못 끌어 쓴다고 함.
  10. 새로 풀린 능력을 온전히 붙잡으려면 결국 재설계(rearchitect)를 해야 한다고 함. 재설계를 하면 애플리케이션 아키텍처를 새 모델에 맞게 뜯어고쳐야 한다고 함.
  11. 그러면 평가(eval)도 함께 새로 짜야 하는데, 평가는 시스템이 믿을 만하게 돌아가는지 확인하는 장치이기 때문이라고 함. 새로 풀리는 능력마다 새로 잘못될 수 있는 면(surface area)도 함께 열린다고 함.
  12. 그래서 평가가 새 아키텍처에 맞춰 계속 따라가야 한다고 함. 정리하면 아키텍처는 모델 업데이트를 따라가고, 평가는 다시 그 아키텍처를 따라가야 한다는 것임.
  13. 이 흐름을 실제 사례로 짚기 위해, 이후 나오는 평가 예시는 전부 SRE(사이트 신뢰성 엔지니어링, site reliability engineering) 에이전트를 기준으로 삼는다고 함.
  14. 이 SRE 에이전트는 정보를 읽기만 하는 게 아니라 시스템에 직접 조치도 취할 수 있다고 함. 배포를 롤백하거나 사람에게 넘겨(escalation) 호출기(page)를 울릴 수도 있는, 읽기 툴과 쓰기 툴을 둘 다 가진 에이전트라고 함.
  15. 첫 세대는 약 3년 전 많은 AI 애플리케이션이 시작했던 형태로, 입력 하나에 모델 호출 하나, 출력 하나로 끝나는 구조라고 함.
  16. 이 세대의 평가는 최종 답변 품질에만 집중했다고 함. 정확했는지, 사실에 맞는지, 모델이 없는 사실을 지어내진 않았는지, 낡은 학습 지식을 최신 정보인 양 내놓지는 않았는지를 봤다고 함.
  17. 방식은 골든 데이터셋(golden dataset, 정답이 확정된 평가용 예시 모음)을 만들고 「좋은 답」의 기준을 담은 채점기(scorer)로 답을 대보는 것이었다고 함.
  18. 이 방식은 시작하기엔 좋았지만 툴 호출도, 오케스트레이션(orchestration, 여러 도구와 단계를 어떤 순서로 부를지 짜는 설계)도, 검색(retrieval)도 없는 좁은 범위였다고 함.
  19. 다음은 체인(chain) 단계로, 모델을 부르기 전에 여러 단계를 거치기 시작했다고 함. 전형적인 RAG(모델이 답하기 전에 외부 문서를 먼저 찾아와 그 내용을 근거로 쓰게 하는 방식) 애플리케이션은 사용자 입력을 파싱해 정보를 뽑고, 그걸로 검색해 컨텍스트를 만들어 모델에 넘겼다고 함.
  20. 이 단계부터는 파서가 엉뚱한 정보를 뽑거나 잘못된 문맥을 검색해 오는 등 잘못될 수 있는 지점이 늘었다고 함.
  21. 컨텍스트 창(window)이 커져도 모델이 그 안에서 제대로 추론하지 못하는 경우가 있었다고 함. 그래서 억지로 채워 넣은 컨텍스트(context stuffing) 자체가 성능을 깎아 먹기도 했다고 함.
  22. 평가할 지점이 여러 곳으로 늘긴 했지만, 여전히 정해진 방식대로만 움직이는 제한적인 구조였다고 함.
  23. 2023년 말에서 2024년 초 리액트(ReAct) 논문이 크게 주목받았다고 함. 모델을 루프 안에서 돌려 추론(reason)과 행동(act)을 단계별로 반복시키는 방식이 이때 퍼졌다고 함.
  24. 모델이 툴을 부르고 그 결과를 이해해 다음 단계를 스스로 정하면서, 사용자 의도가 충족되거나 반복 횟수 한도(iteration budget)를 다 쓸 때까지 도는 구조라고 함.
  25. 이 방식은 시스템을 특정 워크플로에 묶어두지 않고 모델 스스로 여러 의도를 판단해 조율하게 해준다는 점에서 훨씬 유연했다고 함.
  26. 다만 그 시절 모델은 이 자유를 감당할 만큼 안정적이지 않았다고 함. 툴을 부를 때 인자를 틀리고 엉뚱한 툴을 고르는 일이 잦았다고 함.
  27. 긴 컨텍스트를 다루다 컨텍스트가 무너지는(context collapse) 일도 잦아, 아이디어는 흥미로웠지만 실제 성능이 기대를 따라가지 못했다고 함.
  28. 모델을 통제할 수 없으면 그 통제를 모델 바깥, 시스템 쪽으로 옮기게 된다고 함. 그래서 팀들이 오케스트레이션과 실행·계획 로직을 그래프(graph)나 상태 기계(state machine) 형태로 시스템에 박아 넣는 워크플로 그래프 방식으로 옮겨갔다고 함.
  29. 오케스트레이션은 시스템이 쥐고 모델은 각 노드(node) 수준에서만 움직이니, 여러 의도에 걸쳐 훨씬 안정적이고 예측 가능하게 돌아갔다고 함.
  30. 문제는 이 시스템이 특정 의도와 특정 사용 사례에 맞춰 설계된다는 점이라고 함. 그 범위를 벗어난 상호작용이 들어오면 시스템이 삐걱거리기 시작한다고 함.
  31. 이를 메우려고 팀들은 오케스트레이션 로직에 특수 의도를 처리하는 분기(branch)를 계속 덧붙여 그래프를 더 복잡하게 만들었다고 함.
  32. 그 결과 분기 사이 일관성 문제, 노드 사이 계약(contract)이 어긋나는 문제까지 실패 지점이 훨씬 늘었다고 함. 특정 용도로만 짜인 노드의 한계, 이를테면 분류기 노드가 잘못 분류하는 경우도 새로운 실패 지점이 됐다고 함.
  33. 그래서 평가도 전체 오케스트레이션만 볼 게 아니라 노드 단위 평가, 재시도(retry) 루프 같은 복잡한 동작까지 확인해야 하는 수준으로 늘었다고 함.
  34. 이 그래프 방식은 2024년 말에서 2025년 초 사이 인기를 끌며 여러 프레임워크로 구현돼 실제 프로덕션에 많이 올라갔다고 함.
  35. 그런데 2025년 중반에서 후반 사이 앤트로픽(Anthropic)과 오픈AI(OpenAI)가 새 모델 능력을 내놓으면서 툴 호출이 극히 안정적이 됐다고 함.
  36. 오케스트레이션 제어력도 크게 좋아지고, 모델이 훨씬 정확하게 계획을 세우고 장기 과업도 다루게 됐다고 함. 스스로 궤도를 벗어난 걸 알아채고 바로잡는 능력까지 좋아졌다고 함.
  37. 그러자 앞서 만든 그래프 기반 시스템들이 이 새 능력을 살리지 못한 채 여전히 예전의 취약함에 부딪히는 상황이 됐다고 함.
  38. 팀들은 다시 리액트 루프 방식으로 돌아갔고, 이번엔 실제로 잘 작동했다고 함. 모델이 루프 안에서 신뢰성 있게 툴을 부르고 다음 단계를 정해 사용자 의도를 완수할 수 있게 됐다고 함.
  39. 다만 같은 입력을 여러 번 돌려도 매번 경로(trajectory)가 크게 다른데 결과는 맞게 나오는, 편차가 큰 동작 방식이라고 함.
  40. 그래서 평가 단위가 평가 하나가 아니라 평가들의 분포(distribution)를 보는 쪽으로 바뀌었다고 함. 같은 평가를 K번 돌려 통계적으로 의미 있는 신호를 얻는 방식으로 바뀌었다는 것임.
  41. 이때 나온 새 지표가 패스앳케이(pass@K)와 패스헷케이(pass^K)로, 패스앳케이는 같은 평가를 K번 돌렸을 때 한 번이라도 성공하는지를 보는 능력(capability) 지표라고 함.
  42. 패스헷케이는 K번 돌린 것 중 몇 번이 성공하는지를 보는 신뢰성(reliability) 지표라고 함. 패스앳케이가 높은 시스템이 실제로 믿을 만한지는 패스헷케이로 확인할 수 있다고 함.
  43. 더 최근에는 시스템이 그냥 루프 도는 모델 하나가 아니라, 모델 하나에 여러 주변 구성요소가 붙은 하나의 제품 시스템으로 커지는 흐름이 있다고 함.
  44. 세션 안과 세션을 넘나들며 튼튼하게 저장·검색되는 메모리 시스템이 붙어, 모델이 이전 실행에서 배운 걸 다음 실행에 써먹을 수 있게 됐다고 함.
  45. 모델이 만든 코드를 믿고 실행할 수 있는 튼튼한 코드 실행 샌드박스도 갖춰졌다고 함. MCP(Model Context Protocol, 모델이 외부 도구·데이터에 표준 방식으로 연결하도록 하는 규격)와 스킬(skill) 디렉터리가 붙어 모델의 확장성을 넓혔다고 함.
  46. 스킬 저장소나 스킬 시스템이 기호적 지침(symbolic instruction)으로 모델 능력을 계속 보강한다고 함.
  47. 시스템이 이렇게 복잡해진 상태에서 예전 세대의 평가를 그대로 쓰면 시스템을 절반만 들여다보는 셈이 된다고 함. 새로 열린 면 때문에 시스템이 어떻게 취약해지는지는 예전 평가로는 못 본다고 함.
  48. 정리하면 모델이 혁신할 때마다 아키텍처가 그에 맞춰 세대를 바꿨고, 그때마다 평가도 그 아키텍처와 맞물려 있어야 한다고 함.
  49. 결국 시스템이 어떻게 돌아가야 하는지를 오래 남아 설명해주는 자산은 평가라고 함. 세대 전환마다 평가를 잘 맞춰두면, 기존에 잘 되던 것은 안 깨뜨리면서 새 능력만 얹을 수 있다고 함.
  50. 다들 플라이휠(flywheel, 한 번 돌기 시작하면 스스로 가속하는 순환 고리) 도식을 본 적 있을 텐데, 그 개념에는 다들 공감한다고 함.
  51. 프로덕션 데이터를 걷어와 평가에 반영해, 평가가 실제 세계를 반영하게 한다는 것임. AI 시스템을 잘 만들고 잘 내보내고 잘 개선하는 팀들은 실제로 이 흐름을 꾸준히 지킨다고 함.
  52. 다만 많은 팀과 이야기해보면, 이 흐름을 돌려야 한다는 데는 다들 동의하면서도 실제로는 안 하는 경우가 많다고 함.
  53. 아키텍처를 안 바꿔도 이 흐름을 꾸준히 안 돌리는 것만으로 평가가 정적으로 굳어진다고 함. 그러면 품질을 재고 개선하는 데 평가가 점점 덜 쓸모 있어진다고 함.
  54. 특히 세대가 바뀌는 시기엔 이미 정의해둔 「좋은 것」 기준에서 벗어난 실패를 프로덕션에서 걷어오는 것이 필요하다고 함. 거기에 더해 미처 예상 못 한 새로운 방식의 실패에 빛을 비추는 일도 함께 필요하다고 함.
  55. 시스템은 예상했던 방식으로도, 예상 못 했던 방식으로도 망가진다며 이 둘 다 걷어와야 한다고 강조함.
  56. 이 흐름을 브레인트러스트가 어떻게 지원하는지 소개하며, 평가·관측에 더해 프로덕션 데이터에서 통찰을 얻는 기능까지 갖췄다고 함.
  57. 이렇게 뽑은 새 평가 사례를 팀에 넘겨, 팀이 시스템을 차근차근 개선해 나갈 수 있게 한다고 함.
  58. 그중 토픽스(Topics)라는 기능은 프로덕션 데이터 전체를 군집 분석(cluster analysis)한다고 함. 이를 통해 미처 예상 못 했던 새로운 실패 유형을 찾아낸다고 함.
  59. 프로덕션에서 벌어지는 일을 통째로 들여다보고, 가드레일도 평가도 없었던 새로운 실패 상황을 표면으로 드러내 준다고 함.
  60. 이 기능 덕분에 팀은 알려진 실패 유형의 새 사례를 얻는 데 그치지 않는다고 함. 아키텍처를 크게 바꿀 때마다 시스템이 새로 어떻게 망가지는지 이해해 프로덕션 데이터로 데이터셋을 만들 수 있다고 함.
  61. 오늘 발표의 결론은 모델이 계속 바뀔 것이고 정체기(plateau)는 아직 오지 않았다는 것임. 앞으로도 새 능력이 계속 풀릴 거라고 함.
  62. 그만큼 앞으로 몇 달, 몇 년 동안 AI 시스템에 큰 수술을 계속 하게 될 것이라 함.
  63. 모델을 새로 들일 때마다 기존에 잘 되던 일은 그대로 지키면서 새 능력도 얹을 수 있어야 한다고 함. 그러려면 튼튼한 워크플로 체계를 갖추는 게 중요하다고 함.
  64. 제대로 된 도구·자동화·시스템을 갖춘 평가 규율(discipline)을 세우는 일이 이런 세대 전환을 관리하는 데 핵심이라고 함.
  65. 궁극적으로는 플라이휠을 워크플로의 일부로 확실히 박아 넣어서, 점진적인 변화에는 점진적 개선을, 계단식 변화에는 계단식 개선을 평가가 둘 다 받쳐주게 하는 것이 그 목표라고 함.

한줄 코멘트. pass@K·pass^K로 편차까지 재는 건 맞는 방향인데, 발표 내내 강조한 「예상 못 한 실패 발굴」을 결국 브레인트러스트라는 벤더의 군집 분석 기능 하나에 기대는 순간 그 자체가 또 다른 정적 지점이 될 위험을 이 발표는 짚지 않음.

  1. 이 발표자는 테이스트 랩스(Taste Labs)의 창업자 타이스(Thais Castello Branco)이고, 몇 주 전에 스텔스(제품을 공개하지 않고 개발하는 초기 단계)를 벗고 나온 회사임.
  2. 회사의 미션은 인공지능(AI) 슬롭(AI가 대량으로 찍어내는, 그럴듯하지만 알맹이 없는 결과물)을 끝내는 것임.
  3. 이 문제를 풀려면 먼저 주관적인 영역을 분해하고 이해해야 한다는 게 이 회사의 기본 전제임.
  4. AI는 코딩이나 수학 같은 영역에서는 이미 꽤 잘하는데, 디자인·창작 글쓰기·성격·감성 지능 같은 영역에서는 아직 많이 뒤처져 있다고 말함.
  5. 이 회사는 두 방향으로 일함. 하나는 프런티어 랩(가장 앞선 기술을 가진 AI 모델 개발사)들과 손잡고 모델을 평가·벤치마크하고, 어디서 무너지는지 파악하고, 어떻게 고칠지 정하는 일임.
  6. 문제마다 강화학습(RL) 환경(모델이 시행착오를 거치며 보상으로 학습하도록 만든 시뮬레이션 문제)으로 만들지, 사후 학습(post-training, 모델을 먼저 훈련시킨 뒤 사람의 선호 데이터로 다듬는 단계) 문제로 만들지도 이 회사가 함께 정한다고 함.
  7. 다른 하나는 에이전트·애플리케이션 층의 회사들과 일하는 것인데, 파운데이션 모델 층에서 풀 문제가 아니라 맥락(context)이나 사용자 의도 파악으로 푸는 게 나은 문제들을 다룬다고 함.
  8. 이 회사는 앞으로 전문가가 아닌 수십억 명이 콘텐츠를 만드는 세상이 온다고 보고, 그래서 사용자 의도와 맥락을 이해하는 일이 모델 성능을 올리는 일만큼 중요하다고 봄.
  9. 이날 발표는 모델 훈련 쪽에 집중했고, 에이전트 쪽 이야기는 다음 날 디자인 트랙에서 따로 다룬다고 밝힘.
  10. 세상 대부분의 일은 주관적이라는 게 발표의 출발점임. 글쓰기, 회사 안의 영업·마케팅 같은 업무도 정답이 하나가 아니라 여럿이고, "훌륭하다"는 게 뭔지 정의하기부터 어려움.
  11. 코드가 검증 가능하고 측정 가능하다는 건 모델의 속성이 아니라 사실은 코드 자체의 속성이라고 지적함. 코드는 분해되고 검증되고 실행되기 때문에 훈련시키기가 쉬운 것이지, 모델이 원래 코딩을 잘하도록 태어난 게 아니라는 것임.
  12. 반면 디자인이나 글쓰기는 어떻게 분해할지, 어떻게 검증할지, 뭐가 좋은지 어떻게 판단할지부터 막막해서 어려운 영역이 됨.
  13. 주관적 영역이 어려운 이유를 두 가지로 짚음. 첫째는 능력이 측정 가능성을 따라간다는 것, 즉 측정 문제를 풀면 능력 문제도 상당 부분 같이 풀린다는 것임.
  14. 둘째는 평균으로의 붕괴(collapse to the mean) 현상인데, 주관적 영역에서는 평균이 꼭 최선이 아니라는 점임. 이건 뒤에서 더 다룸.
  15. "훌륭한 디자인이 뭐냐"는 질문을 던지면 바로 막힘. 누구한테 훌륭한 건지, 어떤 취향에 맞는 건지, 어떤 상황인지에 따라 답이 달라진다고 함.
  16. 예로 같은 슬라이드도 스타트업한테는 근사할 수 있지만 금융회사한테는 완전히 부적절할 수 있다고 함. 즉 맥락에 따라 답이 달라진다는 것임.
  17. 게다가 좋다는 기준은 시간이 지나면 바뀐다고 함. 오늘 좋다고 여겨지는 것도 5년 전과 다르고 5년 후와도 다를 것이라고 봄. 코드나 수학은 시간이 지나도 훨씬 일관됨.
  18. 그래서 이 회사가 하는 일은 이걸 쪼개서 특정 대상에게는 왜 좋은지, 오늘 시점에는 왜 좋은지, 이 맥락에서는 왜 좋은지를 나눠서 보는 것이라고 함.
  19. 좀 더 구체적인 예로 브랜드(brand)를 듦. 코딩 에이전트로 사내 대시보드나 랜딩 페이지를 만들어본 사람이라면 이게 슬롭인지 진짜 괜찮은 건지 판단하기 어려웠을 거라고 함.
  20. 이때 쓸 수 있는 무기가 회사 디자이너들이 브랜드를 정의하면서 이미 쌓아둔 작업이라고 함. 색, 타이포그래피, 여백, 질감의 조합을 왜 그렇게 골랐는지에 공을 들여 정의해 놓은 게 브랜드라는 것임.
  21. "그냥 훌륭한 걸 만들어라"는 정의하기 어렵지만, "브랜드에 맞는 걸 만들어라"는 훨씬 쉬운 문제가 된다고 함. 브랜드는 분해 가능한 대상이 되기 때문임.
  22. 발표자는 자신이 좋아한다는 리덕트(Reduct) 브랜드를 예로 들면서, 이걸 색·타이포그래피·모션·애니메이션·질감으로 쪼개면 검증 가능한 항목들이 생긴다고 설명함.
  23. "이게 브랜드에 맞나"를 통째로 판단하는 건 어렵고, 대형언어모델(LLM)을 심사자(judge)로 써서 프롬프트를 넣어봐도 마찬가지로 어렵다고 함. 하지만 정확히 어떤 요소들이 "훌륭함"을 구성하는지 짚어내면 코드화되고 검증 가능한 모양이 된다고 함.
  24. 이걸 강화학습 환경 형태로 만들려면, 예컨대 브랜드 준수 능력을 어떻게 훈련시킬지가 관건인데, LLM을 심사자로 쓰는 방식은 늘 최선이 아니라고 함. 보상 해킹(모델이 평가 기준의 허점을 이용해 점수만 높이는 현상)이나 이상한 환각 패턴이 자주 나오기 때문임.
  25. 그래서 이 회사는 애매해 보이는 과제를 명확한 정답(ground truth)이 있는 형태로 바꿔서 환경으로 만드는 작업을 한다고 함. 이 경우 과제 설계 자체가 문제의 가장 어려운 부분이라고 함.
  26. 예를 들어 에이전트에게 리덕트 브랜드를 따르되 원본과는 완전히 다른 새 페이지를 만들라고 시킨다면, 원본과 비교해서만 채점하면 안 되고 앞서 정의한 분해 기준(정답)으로도 함께 채점해야 한다고 함. 원본과 다르지만 여전히 유효한 새로운 방식일 수 있기 때문임.
  27. 다만 이 모든 게 스펙트럼이라고 봄. 비전 정렬(vision alignment, 결과물이 브랜드의 시각적 가이드에 맞는지)이나 타이포그래피처럼 객관에 가까운 요소가 있고, 반대편 끝에는 스타일 적합성이나 창의성처럼 측정 자체가 훨씬 어려운 요소가 있다고 함.
  28. 그래서 이 문제를 라우팅 문제(routing problem)로 봐야 한다고 함. 크고 애매한 문제를 잘게 쪼갠 뒤 각 조각마다 가장 맞는 해법을 찾아 배정하는 접근임.
  29. "왜 어떤 결과물은 슬롭처럼 느껴지는가"라는 질문을 창의성을 예로 다시 짚음. 이게 주관적 영역이 어려운 두 번째 이유라고 함.
  30. 모델은 기본적으로 다음에 나올 가장 그럴듯한 결과를 예측하고, 그 결과가 이상적인 답이라고 가정한다고 설명함.
  31. 수학이나 코딩에서는 이게 맞는다고 함. "2+2가 뭐냐"고 물으면 평균적인 답이 곧 정답이자 최적의 답이라는 것임.
  32. 하지만 글쓰기나 디자인에서는 평균적인 답, 즉 가장 그럴듯한 답이 곧 최적의 답과 일치하지 않는다고 함.
  33. 위대함과 창의성은 대개 분포의 양 끝에서 나온다고 말함. 가장 흔한 결과가 아니라, 규칙과 패턴을 적극적으로 깨는 순간에 주관적으로 훌륭한 것이 나온다는 것임.
  34. 그래서 "슬롭에 둘러싸여 있다"는 느낌이 드는 이유가 바로 이 평균으로의 붕괴와 반복 때문이라고 함.
  35. 이 패턴을 어떻게 깨는지, 그것도 의도적으로 깨는지가 관건이라고 함. 그러면 문제는 검증하기 쉬운 영역이 아니라 사람의 선호와 판단 쪽으로, 그래서 환경보다는 데이터로 푸는 게 나은 영역으로 옮겨간다고 함.
  36. 이 회사는 서로 다른 매체와 스타일을 다루는 1000명이 넘는 디자이너 커뮤니티와 함께 작업하면서, 문제를 쪼갤 때 일부러 이 분포를 넓게 강제한다고 밝힘. 그래야 다시 평균으로의 붕괴에 빠지지 않는다는 것임.
  37. 발표자가 제시한 틀은, 프로그램으로 검증 가능한 것에 가까울수록 강화학습 훈련에 유리하다는 것임. 관건은 애매해 보이는 것에 정답(ground truth)을 세우고 과제를 설계해서 검증 가능한 쪽으로 끌어오느냐라고 함.
  38. 반대로 맥락에 좌우되거나 시간이 지나면 바뀌거나 사람마다 선호가 갈리는 쪽으로 갈수록 사람의 판단이 필요한 영역으로 옮겨간다고 함.
  39. 그래서 브랜드 준수처럼 원래는 사람이 판단하는 게 LLM 심사자나 결정론적 방식보다 나은 문제도, 어떤 요소가 중요한지 코드화하고 관찰·측정 가능한 형태로 바꾸면 검증 영역 쪽으로 끌어당길 수 있다고 함.
  40. 이 라우팅 논리가 오늘 발표에서 하나만 가져갈 수 있다면 바로 이것이라고 강조함. 문제를 쪼개서 각각에 가장 맞는 방법을 찾아내는 것임.
  41. 주관적인 영역에서는 사람의 판단이 필요하고, 사람의 판단이 아직은 LLM 심사자보다 훨씬 높은 수준이라고 이 회사는 믿는다고 밝힘.
  42. 이 "인간 취향(human taste)"을 고품질 데이터로 어떻게 담아내느냐가 모델을 더 잘 훈련시키는 방법이라고 함.
  43. 과거에는 선호 데이터를 모을 때 그 사람이 누구인지, 뭘 좋아하는지, 왜 좋아하는지, 언제 좋아하는지를 이해하지 않고 여러 사람한테서 그냥 긁어모으는 바람에 다시 평균으로 붕괴하는 문제가 있었다고 지적함.
  44. 문제를 제대로 쪼개지 않으면 서로 안 맞는 선호들이 뒤섞인 채로 남는다고 함. 어떤 사람은 이 스타일을, 다른 사람은 저 스타일을 더 좋아하는 게 자연스러운 현상인데, 그렇다고 둘 중 하나가 틀린 것도 아니고 두 사람이 좋아하는 것의 평균이 정답인 것도 아니라는 것임.
  45. 그래서 세상은 다중 선호(multi-preference, 사람마다 좋아하는 게 근본적으로 다르다는 전제)라는 걸 이해하고, 그에 맞게 매칭해야 한다고 봄.
  46. 사람마다 선호 벡터(preference vector, 개인의 취향을 수치화해 나타낸 것) 같은 걸 만들어서 선호 데이터에 붙이면, 데이터가 잡음이 되는 대신 의도적으로 다원적인 선호를 반영한 채로 훈련에 쓸 수 있다고 설명함.
  47. 데이터 품질을 논할 때, 이런 영역에서 뭐가 실제로 좋은 데이터인지 정의하기가 매우 어렵다고 함. 데이터를 사서 쓰거나 직접 큐레이션해본 사람이라면 공감할 거라고 함.
  48. 그래도 통제 가능한 부분들이 있는데, 첫째가 문제 분해라고 함. 세상에서 실제로 보이는 진짜 분포를 강제하고, 여러 영역에 걸쳐 진짜 전문가 선별을 강제하는 것임.
  49. 어떤 전문가를 쓸지, 어떤 선별 기준을 얼마나 엄격하게 적용할지는 전부 통제 가능한 영역이고, 이게 실험 결과의 품질에 그대로 영향을 준다고 함.
  50. 둘째는 어떤 문제를 어떤 해법으로 보낼지 정하는 흐름(flow)이라고 함.
  51. 셋째로 이 회사는 데이터에 품질 검증(QA)을 많이 한다고 함. 그 방법 중 하나는 어떤 데이터 포인트가 풍부하고 신호가 강한 것과 상관관계가 있는 속성인지를 파악하는 것임.
  52. 예로 전문가에게 "이게 좋다/나쁘다"를 판단하게 하고 그 이유를 대게 할 때, 전문가가 쓰는 언어의 구체성(specificity)이 데이터 품질을 가른다고 함.
  53. 다른 방법은 전문가의 코멘트를 실제 코드의 어느 부분과 연결시키는 것임. 예컨대 랜딩 페이지를 심사하는 전문가가 그냥 문단으로 서술만 하면, 모델이 그 코드 조각과 화면(visual)을 잘 연결하지 못하는 경향이 있다고 함.
  54. 그런데 그 코멘트를 정확한 코드 컴포넌트와 묶어주면 잡음이 훨씬 적고 훨씬 명확한 데이터가 된다고 함.
  55. 사람이 하는 QA도 까다로운데 두 갈래가 있다고 함. 하나는 대부분 사람이 동의하는 스펙(사양)을 잘 따랐는지 보는 것임.
  56. 다른 하나는 전문가 합의(expert consensus)를 보는 것인데, 다른 전문가한테 첫 번째 심사자의 판단에 동의하는지 물으면 의견이 갈리는 경우가 나온다고 함.
  57. 이때 핵심은 그 불일치가 데이터의 결함인지 아닌지를 구분하는 것이라고 함. 예를 들어 정렬(alignment)처럼 상당히 객관적인 항목에서 전문가들이 다르게 판단한다면 그건 이상한 신호라고 함.
  58. 반면 스타일이나 미감(aesthetics)처럼 원래 사람마다 갈릴 수 있는 항목에서 의견이 갈린다면, 그건 나쁜 데이터가 아니라 오히려 좋은 데이터라고 함. 사람들이 실제로 뭘 좋아하는지에 차이가 있다는 걸 보여주기 때문임.
  59. 그래서 사람 QA를 기본은 걸러내면서도 합의를 의도적으로 활용하는 방식으로 운영하는 게 또 하나의 큰 축이라고 함.
  60. 실제로 이 데이터가 모델과 어떻게 상호작용하는지도 자체적으로 많이 연구한다고 함. 다만 랩들과 협업할 때는 무엇이 어떤 결과를 일으켰는지 알려주는 피드백 루프를 온전히 받지 못하는 경우가 많다고 함.
  61. 그래서 자기 쪽에서 완전히 측정할 수 있는 데이터 품질 요소들에 집중하는 데 더 힘을 쏟는다고 밝힘.
  62. 마지막 메시지로, 특히 주관적 영역에서는 양보다 질(quality over quantity)을 택하라고 권함.
  63. 고품질 데이터를 만드는 건 비싸고 어렵고 특정 영역을 깊이 알아야 한다고 함.
  64. 해당 영역에서 취향이 매우 높은 사람들이 만든 소수의 고품질 데이터가, 의도 없이 쌓인 잡음 많고 지저분한 대량 데이터보다 훨씬 좋은 결과를 낸다고 마무리함.

한줄 코멘트. 슬롭을 코드처럼 검증 가능하게 쪼개겠다는 틀은 설득력 있는데, 결국 그 검증의 재료가 자기 회사가 파는 전문가 1000명짜리 데이터라는 걸 잊으면 안 됨.

  1. 제이슨 로파테키(Jason Lopatecki)는 아라이즈(Arize) 창업자이면서 직접 제품을 만드는 빌더라고 자신을 소개함.
  2. 아라이즈는 알렉스(Alex)라는 인프로덕트 어시스턴트 에이전트를 자사 제품에 넣어 쓰고 있다고 함.
  3. 아라이즈가 약 2년 전 처음 만든 자체 에이전트는 형편없었다고 스스로 밝힘 — 업계에서 꽤 이른 시도였다고 함.
  4. 시그널(Signal)은 그 경험에서 나온 다음 세대 제품으로, 아라이즈가 매일 하는 작업을 자동화해 제품에 넣은 것이라고 함.
  5. 스타트업을 해본 사람이라면 알 법한 장면 — 플랫폼이 밤늦게 다운돼 억지로 일어나 고쳐야 하는 상황을 예로 들며 발표를 열었음.
  6. 관측(observability, 시스템 상태를 데이터로 들여다보는 일) 영역이 지금 크게 바뀌고 있다고 주장함.
  7. 예전 관측은 사람이 보는 것이었다고 함 — UI를 클릭하고 그래프를 보는 방식.
  8. 지금은 이른바 "2.0" 단계로, 코딩 에이전트와 스킬(skill, 에이전트가 특정 작업을 할 때 불러와 참고하는 지침 폴더)의 조합이라고 함.
  9. 파이로스코프(Pyroscope)나 구글 클라우드 같은 관측 플랫폼에 붙는 스킬을 만들어본 사람이 청중 중에도 있었다고 함.
  10. 텔레메트리(telemetry, 시스템이 자동으로 남기는 실행 기록)는 소프트웨어가 지나간 경로를 알려주는 "연기" 같은 것이라, 이게 없으면 에이전트는 수많은 경로 중 어디를 봐야 할지 그냥 찍어야 한다고 함.
  11. 평가(eval)가 여기에 한 겹 더 얹힌다고 함.
  12. 궁극적인 목표는 시스템이 스스로 고치는 것이라고 함 — AI를 자기 시스템에 넣어서 그 시스템이 스스로 나아지게 만드는 일.
  13. 지금은 "2.0" 단계라 사람이 직접 고치고 검토한다고 함.
  14. 앞으로는 트레이스(trace, 실행 과정을 통째로 기록한 데이터)와 로그를 지금보다 훨씬 많이 뿜어내고, 그걸 에이전트가 계속 도는 루프로 돌리는 방향으로 간다고 함.
  15. 에이전트 속도로 뭔가를 만들 수는 있지만, 지금은 그 시스템을 에이전트 속도로 고칠 수는 없다고 함 — 일종의 조절기가 걸려 있는 느낌이라고 함.
  16. 병목은 더 이상 고치는 일 자체가 아니라고 함 — 코딩 에이전트와 스킬을 써본 사람들 사이에서는 이 수정이 맞는지 확신이 서지 않는 것이 진짜 병목이라고 함.
  17. 아라이즈가 택한 방향은 이 루프를 뒤집는 것이라고 함 — 사람이 보고 에이전트가 고치는 순서 대신, 사람이 일어났을 때 이미 시스템 오류를 근거로 정리된 이슈가 놓여 있게 하는 것.
  18. 에이전트가 수정 자체는 못 해도 사람이 보기 전에 데이터를 먼저 보고 이슈를 띄워둔다고 함.
  19. 그러면 사람이 티켓을 잡는 대신 이미 어느 정도 증거가 갖춰진 상태에서 검토를 시작하게 된다고 함.
  20. 사람의 검토는 여전히 필요하고 때로는 조사를 조금 더 이끌어가야 하는데, 지금은 검토라기보다 그 다음 단계를 사람이 직접 운전하는 상태에 가깝다고 함.
  21. 이 루프는 이벤트(오류 발생 등)로 시작하거나 주기적으로 도는데, 그 이벤트를 둘러싼 맥락은 스킬이 채워준다고 함.
  22. 청중에게 관측 플랫폼에 붙는 스킬을 만들어본 적 있냐고 물었고 소수가 손을 들었다고 함.
  23. 관측 플랫폼에 붙는 스킬의 요령은 에이전트가 무엇을 봐야 할지 스스로 판단해 맥락을 모아오게 하는 데 있다고 함.
  24. 트리거는 주기적인 것과 이벤트 기반인 것 두 종류라고 함.
  25. 이런 식이 그래파나(Grafana) 같은 UI를 클릭하는 것보다 앞으로의 관측 모습에 더 가깝다고 함.
  26. 증거는 보통 트레이스에서 시작하는데, 요즘 AI 시스템 대부분이 에이전트 프레임워크 핵심에 트레이스를 갖고 있다고 함.
  27. 주기적으로(예: 5분마다) 보거나 오류 같은 이벤트를 계기로 보는데, 실제로는 이 둘이 섞여서 쓰이는 경우가 많다고 함.
  28. 맥락과 로그, 저장소(repo)까지 한데 모아야 무엇을 고칠지 이해할 수 있다고 함 — 저장소는 코드가 밟은 경로를, 프로덕션 로그·트레이스는 실제 실행 기록을 알려준다고 함.
  29. 아라이즈의 스킬은 실행 중 만든 작은 임시 파일을 저장소 안으로 끌어와 실제 벌어진 일과 코드가 한자리에 놓이게 한다고 함.
  30. 올바른 데이터와 파일 형식을 코드와 같은 저장소에 함께 두는 조합이 스킬을 조립 가능(composable)하게 만드는 핵심이라고 함.
  31. 지금은 많은 사람이 이런 작업을 노트북에서 로컬로 직접 돌리고 있다고 함.
  32. 노트북에서 샌드박스(sandbox, 격리된 실행 환경)로 옮겨가는 흐름이 느껴진다고 함 — 이벤트나 주기에 따라 로컬에서 하던 것과 같은 작업을 실행 환경이 대신 돌리는 것.
  33. 실제 사례로 알렉스가 겪은 "스트림 취소(stream canceled)" 오류를 들었음 — 할일 목록을 관리하는 to-do update 기능을 반복 호출하다 오류를 냈다고 함.
  34. 시그널이 백그라운드에서 이런 상황을 이슈로 자동으로 띄워준다고 함.
  35. 이 사례는 한두 줄짜리 수정으로 끝난 이상적인 경우였고, 실제로는 수정 규모가 더 클수록 사람이 직접 나서서 마무리 지을 가능성이 크다고 함.
  36. 중요한 건 콜드 스타트(cold start, 아무 정보 없이 처음부터 시작하는 상태)를 벗어나는 일이라고 함 — 필요한 정보를 처음부터 다 갖추고 시작해 사람이 나머지만 이끌면 되는 상태가 지금 도달한 지점이라고 함.
  37. 그 결과 사람의 역할은 대응자(responder)에서 검토자(reviewer)로 옮겨간다고 함.
  38. 트레이스와 평가는 사라지지 않고 오히려 루프의 핵심 부품이 된다고 함.
  39. 앞으로는 트레이스와 로그를 지금의 10배쯤 남기게 될 것이라고 함 — 소프트웨어가 어떤 경로를 탔는지 알아야 하기 때문이라고 함.
  40. 예전에는 사람이 로그를 다 뒤질 수 없어서 그만큼 남기지 않았지만, 몇 자릿수 더 많이 남기면 소프트웨어가 밟은 경로를 알아내 스스로 고치는 연속 루프를 만들 수 있다고 함.
  41. 이걸 AI용 SRE(사이트 신뢰성 엔지니어)라고 부를 수도 있겠지만, 블랙박스 취급하는 표현("SRE 에이전트가 뭔가 해준다")은 경계한다고 함.
  42. 아라이즈가 하려는 일은 결국 클로드 코드(Claude Code)·커서(Cursor)로 로컬에서 하던 디버깅 경험을 그대로 주기적으로 돌리는 것뿐이라고 함 — 샌드박스·하니스(harness, 에이전트를 실행하는 틀)·스킬을 골라 쓰면 된다고 함.
  43. 제품은 크게 셋으로 나뉜다고 함 — SaaS 플랫폼인 AX, 오픈소스인 피닉스(Phoenix), 지금은 AX 안에서만 쓸 수 있고 VPC(가상 사설 클라우드, 회사 전용으로 격리된 클라우드망)에도 배포 가능한 시그널.
  44. 제품 데모로 금융 트레이딩 에이전트를 보여줬는데, 다른 발표 내용을 감안하면 이런 에이전트로 돈을 벌기는 어려울 것이라고 농담처럼 덧붙임.
  45. 시그널은 주기적으로 돌면서 이슈를 만들어내고, 깃허브(GitHub) 저장소에 연결해 이슈를 직접 생성할 수 있다고 함.
  46. 만들어진 이슈에서 평가기(evaluator)를 만들 수도 있고, 반복되는 특정 문제라면 데이터셋에 추가할 수도 있다고 함.
  47. 이슈에는 트레이스 같은 증거가 딸려 있고, 구글 클라우드나 다른 로깅 시스템용 스킬이 예시로 붙어 있었다고 함.
  48. 사용자가 자기만의 스킬을 직접 추가할 수도 있다고 함.
  49. 데모에 나온 이슈 예시로는 가드레일 없이 트레이스가 계속 도는 문제, 안전(safety) 문제, 의도(intent) 관련 문제 등이 있었다고 함.
  50. 블랙박스처럼 느껴지지 않도록 하니스는 클로드 코드로, 샌드박스 시스템도 직접 고를 수 있게 열어뒀다고 함.
  51. 앤트로픽(Anthropic)이 관리하는 매니지드 에이전트를 쓸 수도 있고, 아라이즈 자체 샌드박스를 쓸 수도 있다고 함.
  52. 아라이즈 샌드박스를 쓰는 이유는 우버(Uber)·부킹(Booking) 같은 대기업 고객이 프로덕션 시스템을 앤트로픽에 직접 연결하고 싶어 하지 않기 때문이라고 함 — 자사 VPC 안에 샌드박스를 설치해 연결을 바깥으로 내보내지 않고 쓴다고 함.
  53. 데이토나(Daytona) 등 다른 샌드박스 서비스도 함께 쓸 수 있다고 함.
  54. 플랫폼은 여러 에이전트가 동시에 도는 것도 지원한다고 함 — 시그널이 주기적으로 돌고, 그 옆에 따로 이름 붙인 다른 에이전트도 함께 돌릴 수 있다고 함.
  55. 세션 보기, 트랜스크립트 다운로드, 로컬에서 클로드 세션 이어받기 같은 기능도 지원한다고 함.
  56. 하니스와 샌드박스를 고르고, 프롬프트(예: "공격적으로 굴지 마라", "보안 문제를 찾아라")와 스킬까지 사람이 정한다고 함.
  57. 프리셋 기능으로 스킬을 추가하거나 저장소를 연결하고, 미리 만들어둔 스킬을 바로 쓸 수도 있다고 함.
  58. 관측 플랫폼이 신호를 띄우는 데서 그치지 않고 고치는 연속 루프에 점점 더 묶이는 방향으로 간다고 정리함.
  59. 청중 질문 — 클로드 코드를 데이터에 바로 붙여서 사람이 다 시키면 되지 않냐, 트레이스를 읽고 곧장 PR을 올리게 하면 되지 않냐는 물음이 나옴.
  60. 로파테키는 그래야 맞다고 답하면서도, 그걸 잘 되게 하려면 데이터 영역에서 잘 설계된 스킬이 필요하다고 함.
  61. 스킬 설계의 핵심은 세션에 관련된 트레이스 묶음처럼 맞는 데이터를 먼저 찾고, 그걸 파일 형식으로 저장소에 넣는 데 있다고 함.
  62. 하니스는 파일을 다루는 데 특히 강해서 어떤 파일에 무슨 일이 있었는지 던져주면 잘 작동한다고 함 — 어떤 경우에는 저장소에 10메가바이트짜리 파일이 그대로 들어가기도 한다고 함.
  63. 예로 파이로스코프용 스킬은 메모리 문제를 찾아내고, 파이로스코프의 패싯(facet, 데이터를 여러 축으로 나눠보는 필터 기능) 사용법도 스킬이 알고 있어서 특정 고객 기준으로 묶어 문제가 그 고객 탓인지 볼 수 있다고 함.
  64. 핵심은 클로드를 데이터에 그냥 갖다 붙이는 게 아니라, 클로드가 조합해 쓸 수 있도록 스킬의 범위를 잘 설계하는 데 있다고 함.
  65. 두 번째 질문 — 시그널이 프로덕션에서 뭔가 터졌다는 신호를 낼 때 평가는 어디서 들어오냐는 물음이 나옴.
  66. 평가는 보통 프로덕션 트레이스 위에 얹혀 돌고, 이걸 온라인 평가(online eval)라고 부른다고 함.
  67. 에이전트는 트레이스에서 평가 데이터를 가져오고, 여러 트레이스에 걸친 집계값을 시각화하는 법도 스킬을 통해 안다고 함.
  68. 평가는 흔히 겪어본 실패 사례를 바탕으로 만든다고 함 — 프롬프트 주입(prompt injection) 같은 문제를 다시 잡아내려고 미리 만들어두는 식이라고 함.
  69. 적어도 지금 세대의 평가는 LLM 심사(LLM as judge, 모델이 다른 모델의 출력을 채점하게 하는 방식)를 미리 설정해두고 주기적으로 돌려 시스템을 평가하는 계층에 가깝다고 함.
  70. LLM 심사는 규모를 크게 키워 돌릴 수 있어서, 고객 중에는 전체 데이터셋에 걸쳐 이걸 층층이 얹어 쓰는 경우도 있다고 함.

한줄 코멘트. 고치는 루프를 여는 열쇠가 잘 설계된 스킬이라는 지적은 맞지만, 그 스킬을 실제로 어떻게 잘 만드는지는 구체적으로 안 보여주고 결국 아라이즈 제품(AX·시그널)을 쓰라는 결론으로 흘러감.

  1. 발표자는 독일에 거점을 둔 필립 슈미트(Philipp Schmid)이고, 구글 딥마인드(Google DeepMind)에서 제미나이(Gemini) API와 에이전트를 다루는 팀 소속임.
  2. 발표 제목은 "평가(eval, 결과물이 맞는지 자동으로 채점하는 검사) 없이 스킬을 내보내지 마라"임.
  3. 청중한테 코딩 에이전트로 코드를 쓰는지, 스킬(skill, 에이전트가 특정 작업을 할 때 불러와 참고하는 지침 폴더)을 쓰는지, 그 스킬에 평가가 있는지 손을 들어 물었는데 세 번째 질문엔 손이 거의 안 올라갔다고 함.
  4. 스킬벤치(Skill Bench)라는 평가·벤치마크 도구가 공개된 스킬 5만여 개를 살펴봤더니 평가가 딸린 스킬이 거의 없었다고 함.
  5. 그 스킬 대부분이 AI가 써서 제대로 테스트되지 않은 것이었고, 에이전트가 원래 비결정적(같은 입력에도 매번 다른 결과가 나옴)이라 스킬이 나빠서 실패했는지 과제가 너무 어려워서 실패했는지 구분하기 어렵다고 함.
  6. 그래서 우리가 쓰는 에이전트와 우리가 만드는 에이전트를 구분해야 한다고 강조함.
  7. 앤티그래비티(Antigravity)·커서(Cursor)·클로드 코드(Claude Code)처럼 우리가 쓰는 에이전트는 스킬이 첫 시도에 안 걸리면 사용자가 바로 알아채고 다시 프롬프트를 넣거나 슬래시 명령으로 강제로 부를 수 있다고 함.
  8. 반면 고객을 위해 만드는 에이전트는 고객이 스킬의 존재를 모르고 "환불 스킬을 써서 도와줘"처럼 지목해 말하지 않는다고 함.
  9. 스킬은 스킬.md(skill.md) 파일에 필요하면 추가 자료를 더한 폴더이고, 점진적 공개(progressive disclosure, 필요한 만큼만 단계적으로 정보를 드러내는 방식)로 동작한다고 설명함.
  10. 첫 층은 모델의 시스템 지침에 늘 들어가는 제목과 설명이고, 둘째 층은 더 자세한 지침이 담긴 스킬 본문, 셋째 층은 필요할 때만 파고드는 외부 참조 파일이라고 함.
  11. 스킬은 능력 스킬(capability skill)과 선호 스킬(preference skill) 두 종류로 나뉜다고 함.
  12. 능력 스킬은 모델이 아직 일관되게 못 하는 걸 가르치는 것, 예컨대 로그 추적이나 새 리액트(React) 앱 만들기 같은 임시 스킬이고, 모델이 좋아지면 평가가 은퇴 시점을 알려준다고 함.
  13. 선호 스킬은 팀 고유의 작업 흐름이나 문체처럼 파운데이션 모델이 원래 모르는 회사 고유 지식을 담아서 더 오래 가고, 그래서 평가로 지켜서 업데이트 때 성능이 나빠지지 않게 해야 한다고 함.
  14. 스킬이 실제로 통하느냐는 질문에는 통한다고 답하면서 스킬벤치 1.1 결과를 근거로 듦.
  15. 여러 공개·비공개 모델을 여러 하니스(harness, 에이전트를 실행하는 환경·도구)에서 평가했더니 스킬을 쓰면 평균 15%가량 성능이 올랐다고 함.
  16. 스킬벤치는 코딩·생산성 작업을 여러 언어에 걸쳐 다루는 과제 약 100개로 이뤄져 있고, 공개돼 있으며 리더보드와 커뮤니티 기여도 받는다고 함.
  17. 스킬벤치가 AI가 생성한 스킬도 따로 분석했는데, 사람이 직접 쓴 스킬이 가장 좋았고 AI가 생성한 스킬은 오히려 성능을 떨어뜨릴 수 있었다고 함.
  18. 그리고 스킬.md 파일은 500줄을 넘기지 않아야 한다는 결과도 나왔다고 함.
  19. 스킬을 부르는 방식은 모델이 맥락과 설명을 보고 스스로 판단해 부르는 모델 트리거(model-triggered) 방식과 사용자가 직접 지목해 부르는 사용자 호출(user-invoked) 방식 둘로 나뉜다고 함.
  20. 사람들이 사용자 호출 스킬의 힘을 과소평가한다고 지적함. 풀 리퀘스트(pull request) 만들기나 문서 스테이징(staging)처럼 원래 스크립트로 돌려도 되는 반복 작업은 대부분 사용자 호출 스킬로 만드는 게 맞다고 함.
  21. 고객용 에이전트를 만들 때는 사용자 호출 스킬을 쓸 수 없고 모델 트리거 스킬만 남는데, 이 발표에서 다루는 평가 예시도 그 모델 트리거 스킬을 겨냥한 것이라고 함.
  22. 좋은 스킬을 쓰는 법 여덟 가지 중 첫째는 설명(description)임. 모델 시스템 지침에 실제로 들어가는 두 문장 정도가 바로 이 설명이기 때문임.
  23. 설명이 약하면 스킬이 필요 이상으로 자주 걸리거나 반대로 필요할 때 안 걸린다고 함. 왜 써야 하는지, 어떻게 써야 하는지, 언제 써야 하는지를 담아야 한다고 함.
  24. 둘째는 산문 대신 지시문으로 쓰라는 것임. "인터랙션스 API는 세션 상태를 다루니까 멀티챗에 권장된다"처럼 설명하지 말고 "채팅 앱을 만들 때는 인터랙션스 API를 써라"처럼 딱 지시하라고 함.
  25. 셋째는 스킬을 가볍게 유지하고 정보를 층으로 나누라는 것임. 설명은 모델을 호출할 때마다 매번 지불하는 비용이라 늘 100~200토큰이 나가고, 본문도 모델이 읽기로 판단하면 그때마다 통째로 맥락에 들어가 비용이 나간다고 함.
  26. 그래서 참조가 필요한 부분은 본문에 다 넣지 않고 별도 참조 파일로 빼서, 멀티 클라우드 배포 스킬이면 AWS용·구글 클라우드용·애저(Azure)용 참조로 나눠 모델이 맥락에 맞는 파일만 찾아가게 해야 한다고 함.
  27. 넷째는 자유도를 알맞게 정하라는 것임. 워크플로를 1단계 이거, 2단계 저거 식으로 하나하나 못박아 두는 경우가 흔한데, 그 작업이 매번 똑같다면 스킬이 아니라 스크립트를 만들어서 모델한테 돌리라고 시켜야 한다고 함.
  28. 정확한 절차보다는 목표와 제약을 정의하라고 함. 설정 파일을 고칠 때도 "포트 값을 읽고 바꾸고 다시 배포해라"처럼 절차를 나열하지 말고 "이 파일을 고쳐야 한다면 바꿔라" 정도로만 알려주면 모델이 나머지는 안다고 함.
  29. 다섯째는 부정 사례를 빼먹지 말라는 것임. 스킬을 언제 써야 하는지는 다들 신경 쓰는데 언제 쓰면 안 되는지는 잘 안 본다고 지적함.
  30. "웹 개발 작업에 써라"처럼 설명을 넓게 잡으면 리액트든 앵귤러(Angular)든 웹 개발 환경이기만 하면 과도하게 걸리는데, "리액트 컴포넌트에만 써라"처럼 좁혀 두면 정확히 언제 쓸지 안다고 함.
  31. 여섯째는 일찍 테스트하라는 것임. 새 스킬을 만들면 프롬프트 10~20개를 써 보되, 스킬을 써야 하는 상황 5개와 쓰지 말아야 하는 상황 5개로 나누고 실제 고객·프로덕션 트레이스가 있으면 그것도 가져다 쓰라고 함.
  32. 일곱째 팁은 AI 교육자 매트(Matt)한테서 가져왔다고 밝히면서 크레딧을 돌림. 매트가 트윗과 스킬로 공개한 내용은 노옵(no-op, 에이전트의 행동을 실제로 바꾸지 않는 지시문) 없애기임.
  33. AI가 생성한 스킬일수록 노옵이 많이 들어간다고 함. "구현을 읽기 쉽게 만들어라" 같은 문장이 그 예인데, 모델은 원래 읽기 쉬운 고품질 코드를 쓰도록 되어 있어서 굳이 말할 필요가 없다는 것임.
  34. 여덟째는 스킬을 언제 은퇴시킬지 아는 것임. 스킬이 영원히 사는 게 아니라 모델이 좋아지고 행동과 기대와 환경이 바뀌면서 스킬의 쓸모도 바뀐다고 함.
  35. 그래서 스킬을 켜고 끈 상태로 평가를 항상 같이 돌려 보고, 스킬 없이도 모델이 같은 성능을 내면 그 스킬을 은퇴시켜서 토큰 비용과 유지보수 부담을 줄이라고 함.
  36. 실제 사례로 올해 초 제미나이 인터랙션스 API(Gemini Interactions API, 제미나이 모델과 에이전트를 다루는 새 인터페이스)를 위한 스킬을 만든 이야기를 들려줌.
  37. 이 API는 제미나이 마지막 훈련 이후에 나온 것이라 제미나이 3, 3.1, 심지어 3.5 모델도 이 API를 둘러싼 맥락을 전혀 모른다고 함.
  38. 그래서 최신 모델로 인터랙션스 API 코드를 잘 짜도록 돕는 스킬을 만들기로 했고, 이를 위해 테스트 케이스 117개를 만들었다고 함.
  39. 이 테스트 케이스는 실제 사용자가 제미나이 코드를 생성하려던 데이터, 합성으로 만든 데이터, "모델이 이미 3.0인데도 계속 제미나이 2.0을 쓴다"는 식의 사용자 피드백에서 가져왔다고 함.
  40. 결과로 최신 제미나이 모델로 유효한 인터랙션스 API 코드를 만드는 성공률이 거의 90%까지 올라갔다고 함.
  41. 이걸 만드는 데 자산은 딱 두 가지만 필요했다고 함. 하나는 모든 테스트 케이스를 담은 JSON 파일임.
  42. 그 JSON에는 사용자가 넣을 법한 프롬프트, 타입스크립트(TypeScript)와 파이썬(Python) 중 어느 언어를 테스트할지, 그 스킬이 실제로 걸려야 하는지 여부, 여러 기대 검사(expected checks)가 들어 있다고 함.
  43. 다른 하나는 코딩 에이전트, 이 경우엔 제미나이 CLI(Gemini CLI)를 돌리고 결과물을 받아 확인하는 아주 기본적인 파이썬 스크립트라고 함.
  44. 스킬 평가 대부분은 정규식(regex, 문자열 패턴을 찾아내는 규칙)으로 충분하다고 함. 올바른 SDK·모델·메서드를 썼는지, 옛날 패턴을 쓰지 않았는지를 정규식으로 아주 값싸게 확인할 수 있다고 함.
  45. 그래서 새 모델이 나올 때마다 정규식 속 모델 ID만 최신으로 바꿔서 계속 저렴하게 평가를 돌릴 수 있고, 이런 방식엔 대형언어모델(LLM)을 심사자로 쓸 필요도 없다고 함.
  46. 다만 트레이스나 여러 단계를 통째로 봐야 하는 복잡한 스킬이면 LLM 심사자를 쓸 수 있다고 함. 평가 기준(rubric)을 정해서 출력을 넣고 합격·불합격을 받은 뒤, 불합격이면 데이터를 들여다보고 스킬을 고치면 된다고 함.
  47. 이게 지금 구글 딥마인드가 스킬을 평가하는 방식과 비슷하다고 함. 야믈(YAML)을 쓰진 않지만 구조는 같다고 함.
  48. 구글 딥마인드 내부에서는 가진 모든 스킬마다 나란히 테스트·평가가 딸려 있고, 각 테스트는 프롬프트를 담은 여러 케이스로 이뤄진다고 함.
  49. 모든 테스트는 깨끗한 작업공간(workspace)에서 돌리는데, 애플리케이션 환경 같은 추가 파일을 함께 정의할 수 있고 라이브러리를 미리 설치하는 시작 명령(startup command)도 정의한다고 함.
  50. 스크립트 평가·데이터는 트레이스를 정규식으로 훑어 스킬이 걸렸는지, 특정 명령이나 CLI가 실제로 실행됐는지를 확인하는 것이고, 여기에 더해 스킬이 걸렸는지·특정 배시(bash) 명령을 돌렸는지를 보는 LLM 심사자도 함께 쓴다고 함.
  51. 이 평가는 스킬 파일에 변경이 생길 때마다 자동으로 돌고, 결과가 기존 테스트 케이스보다 나아지지 않으면 그 변경은 병합되지 않는다고 함.
  52. 그래서 스킬을 고칠 때마다 회귀 테스트(regression test, 바뀐 코드가 기존 기능을 망가뜨리지 않았는지 확인하는 검사)가 항상 붙고, 평가를 더 좋게 만들거나 새 평가를 추가할 때만 스킬을 바꿀 수 있다고 함.
  53. 마지막으로 스킬을 위한 모범 사례를 정리했는데, 실패의 50%가 사용자 프롬프트가 충분히 구체적이지 않아서 스킬이 제대로 안 걸리는 데서 나왔다고 함.
  54. 특히 다른 사람을 위해 만든 에이전트라면 그 사람들은 스킬 설명이 뭔지 모른 채 얕은 프롬프트를 넣기 쉬운데, 그래도 모델이 알아서 그 스킬을 걸어야 한다고 함.
  55. 산문보다는 지시문을 쓰라는 원칙을 다시 짚음. "오늘 기분이 좋으면 이 스킬을 써라" 같은 식이 아니라 뭘 해야 하는지 명확히 알려줘야 한다고 함.
  56. 부정 테스트를 늘 빼먹는다고 지적하면서 꼭 포함하라고 함. 평가 샘플이 10~20개만 있어도 없는 것보다 훨씬 낫고, 5~10개만 만들어도 생각보다 많은 걸 발견하게 된다고 함.
  57. 경로가 아니라 결과를 테스트하라고 함. 모델이 첫 턴에 스킬을 부르는지가 아니라 프롬프트로 준 과제를 실제로 해내는지를 봐야 하고, 스킬이 다섯 턴 뒤에 걸려도 그건 그것대로 괜찮다고 함.
  58. 격리된 실행(isolated run) 환경에서 평가를 돌려야 한다고 함. 코딩 에이전트가 기존 대화나 다른 실행 기록을 뒤져서 스킬을 안 쓰고도 답을 베끼는 편법을 잘 찾아내기 때문이라고 함.
  59. 평가를 한 번만 돌리지 말고 케이스당 2~6번은 시도해서 신뢰도를 재라고 함. 모델이 비결정적이라 첫 시도는 되는데 두 번째는 안 될 수 있기 때문이라고 함.
  60. 여러 하니스에 걸쳐 테스트하라고 함. 클로드나 앤티그래비티만 보지 말고 코덱스(Codex) 같은 다른 하니스를 쓰는 직원·고객이 있다면 거기서도 확인해야 하는데, 같은 스킬도 하니스에 따라 잘 통하고 못 통할 수 있기 때문이라고 함.
  61. 모델이 좋아져서 스킬 없이도 성능이 나오게 됐다고 평가까지 버리지는 말라고 함. 그 평가를 남겨 두면 나중에 성능이 떨어지기 시작할 때 스킬을 다시 넣어야 한다는 신호가 된다고 함.
  62. 6개월 전엔 꼭 필요했던 스킬이 지금은 필요 없어지는 경우가 생각보다 훨씬 빨리 온다고, 모델이 업데이트될 때마다 놀랄 것이라고 함.
  63. 발표 끝에 숙제를 냄. 가장 많이 쓰는 스킬 하나를 골라 테스트 프롬프트 다섯 개를 써 보라는 것임. 코딩 에이전트한테 자기 실행 기록(trajectory)을 보여 달라고 해서 가장 많이 쓴 스킬을 찾아도 된다고 함.
  64. 노옵을 없애 보라고도 권함. 평가 성능이 안 바뀔 수도 있지만 쓸모없는 토큰을 줄여서 비용을 아낄 수 있다고 함.
  65. 스킬을 켠 채와 끈 채로 평가를 나란히 돌리는 어블레이션 테스트(ablation test)를 해봐야만 그 스킬이 정말 도움이 되는지, 언제 은퇴시켜도 되는지 알 수 있다고 하며 "평가 없이 스킬을 내보내지 마라"는 말로 발표를 마무리함.

한줄 코멘트. 정규식 채점으로 스킬을 값싸게 평가하는 아이디어는 실용적인데, 구글처럼 스킬 변경마다 자동으로 회귀 테스트를 돌리는 체계를 갖추지 않은 팀이라면 그 값싼 평가조차 손으로 반복해서 돌려야 한다는 점은 짚어야 함.

  1. 아라이즈(Arize AI)의 AI 아키텍트 댓 응오(Dat Ngo)가 AI 엔지니어 컨퍼런스에서 관측 가능성(observability)·평가(eval)·실험(experimentation)을 어떻게 한데 묶는지 발표함.
  2. 세계 최대 기업들과 함께 일하며 결국 이 셋으로 "AI를 어떻게 실제로 작동시키는가"라는 질문을 다룬다고 함.
  3. 지난 오픈AI 데브데이(OpenAI DevDay) 기준으로 자신이 작년 한 해 쓴 토큰이 1000억에서 1조 사이쯤 될 거라고 어림잡아 말함.
  4. 청중에게 에이전트를 만들었는지, 프로덕션에 올렸는지, 하네스(harness, 에이전트를 감싸 도구를 쓰게 만드는 실행 틀)를 만들어봤는지 손을 들어보라고 물음.
  5. AI 분야는 사실 소프트웨어를 다시 만드는 것과 같은 패턴이고, 마법처럼 보이지만 마법이 아니라 전부 엔지니어링이라고 함.
  6. 관측 가능성은 내가 만든 시스템 안에서 지금 무슨 일이 일어나고 있는지를 보는 것이고, 평가는 그 시스템에서 어떤 형태로든 신호(signal)를 뽑아내는 일이라고 정의함.
  7. 비결정적(non-deterministic)인 세계에서 뭔가를 고쳤다고 생각한 순간, 실제로는 모르는 사이에 두세 개 회귀(regression)를 만들어낼 수 있다고 지적함.
  8. 아라이즈가 자랑스러워하는 지점은 모든 걸 오픈텔레메트리(OpenTelemetry, 시스템이 한 일을 표준 형식으로 남겨 어느 도구에서든 볼 수 있게 하는 공개 규격) 위에서 처리한다는 점이라고 함.
  9. 어떤 하네스·에이전트·모델 조합을 쓰든 오픈텔레메트리를 우선으로 두면 대부분의 쓰임새에 이미 준비돼 있다고 함.
  10. 자동계측기(auto instrumenter)는 코드 한 줄만 넣으면 그 프레임워크나 SDK 안에서 벌어지는 일을 자동으로 오픈텔레메트리 트레이스와 스팬으로 남겨준다고 설명함.
  11. 트레이스(trace)와 스팬(span, 트레이스 안에서 한 단계씩 쪼갠 기록 조각)이 곧 내 에이전트가 실제로 뭘 했는지 보여주는 감사 기록이라고 함.
  12. 코드 자체는 에이전트나 하네스를 감사하지 못하고, 실제로 감사하는 건 텔레메트리라고 함.
  13. 관측 가능성에는 트레이스와 스팬 말고도 세션(session, 여러 번 주고받은 대화나 실행이 어떤 상태로 이어졌는지 보는 단위) 같은 상태 정보도 포함된다고 함.
  14. 이틀 전 나온 앤트로픽(Anthropic)의 매니지드 에이전트(managed agents) 논문을 언급하며 꽤 볼만했다고 함.
  15. 엔터프라이즈 고객들은 에이전트가 어떤 도구를 호출했는지보다 최종 사용자가 만족했는지, 질문에 다 답했는지를 더 궁금해한다고 함.
  16. 아라이즈 AX(Arize AX)의 특이한 점으로, 에이전트 실행 하나만 보는 게 아니라 모든 실행 사례를 모아 분포로 보여주는 화면을 든다고 함.
  17. 이 분포 화면으로 전체 트래픽 중 몇 퍼센트가 어느 분기(branch)로 갔는지, 어느 구성 요소가 지연을 일으켰는지 답할 수 있다고 함.
  18. 궤적 평가(trajectory eval, 에이전트가 어떤 경로로 도구를 호출했는지 순서까지 채점하는 평가)는 어떤 경로에서는 신호가 잘 나오다가 다른 경로에서는 떨어지는 사례로 설명함.
  19. 그 원인이 두 구성 요소의 순서가 뒤바뀐 것이었다고 함. B가 A에 의존하는데 LLM이 A보다 B를 먼저 부른 것이라고 함.
  20. 이런 경우 "이걸 하기 전에 저걸 먼저 하라"는 맥락을 프롬프트에 넣어줘야 한다고 함.
  21. 트레이스·세션·궤적 말고도 에이전트가 실시간으로 어떻게 움직이는지 커스텀 화면으로 보는 분석(analytics)도 여전히 유효하며, 관측 가능성을 한마디로 정리하면 여러 층위를 다 들여다볼 수 있느냐는 것이라고 함.
  22. 관측 가능성이 됐다면 다음 단계는 신호를 판단하는 일이고, 신호에는 다섯 가지 갈래가 있다고 정리함.
  23. 첫째는 LLM 판정(LLM as judge, 사람 대신 다른 언어모델이 결과 품질을 채점하게 하는 방식)인데, 간단해 보이지만 실제로는 꽤 복잡해질 수 있다고 함.
  24. 둘째는 사람 신호라며, 최종 사용자든 제품 담당자든 기술자든 이 신호를 신경 써야 한다고 함.
  25. 셋째는 골든 데이터셋(golden dataset, 도메인을 아는 사람이 직접 품질을 매긴 신뢰할 만한 데이터 집합)이라고 함.
  26. 골든 데이터셋에 LLM 판정을 돌려 그 판정이 사람이 매긴 결과에 얼마나 가까워지는지 튜닝한다고 함.
  27. 넷째는 비용인데, 항상 LLM 호출이나 사람이 필요한 건 아니고 결정론적(deterministic) 평가도 있다고 함.
  28. 예로 문단을 JSON으로 바꿨을 때 그게 유효한 JSON인지, 스키마를 지키는지, 널(null)이면 안 되는 필드가 채워졌는지를 로직으로 바로 확인한다고 함.
  29. 다섯째로 결국 이 모든 걸 만드는 이유는 돈을 더 벌거나 돈을 아끼거나 시간을 아끼는 세 가지 중 하나라고 함.
  30. 좋은 AI 제품을 만들다 보면 기술 인력과 비기술 인력 두 부류가 함께 일하게 된다고 함.
  31. AI 엔지니어·개발자는 만들고 자동화하는 데 강하고, 도메인 전문가나 제품 담당자는 AI 경험이 어때야 하는지를 안다고 함.
  32. 그래서 프롬프트 설계와 어떤 평가를 쓸지는 도메인을 아는 사람이 맡도록 넘겨주고 싶어 한다고 함.
  33. 아라이즈에서는 비기술 사용자도 UI에서 모델을 고르고 기성 템플릿을 돌리거나 평가를 직접 손볼 수 있게 했고, 기술 사용자는 프로그래밍으로 평가를 붙일 수 있다고 함.
  34. 평가의 복잡도는 범위(scope)로도 나뉘는데, 가장 좁은 단위는 스팬 평가로 LLM 호출 하나의 입력과 출력만 본다고 함.
  35. 멀티스팬 평가(multi-span eval, 하나의 스팬이 아니라 여러 구성 요소에 걸친 데이터를 함께 봐야 하는 평가)는 예로 에이전트끼리 데이터를 얼마나 잘 주고받는지 볼 때 필요하다고 함.
  36. 모든 스팬을 다 훑는 게 궤적 평가고, 비즈니스 절차를 끝내기 위해 순서대로 제대로 호출했는지를 본다고 함.
  37. 세션 단위 평가는 더 멀리 줌아웃해서, 대화 안에서 사용자가 짜증 낸 적이 있는지, 질문에 다 답했는지 같은 상태 전체를 본다고 함.
  38. 평가를 설계할 땐 어떤 유형을 쓸지뿐 아니라 어느 범위와 깊이에서 돌릴지도 함께 생각해야 한다고 함.
  39. 평가할 수 있다고 해서 다 평가해야 하는 건 아니고, 비용이 드는 만큼 최소한으로 필요한 평가만 골라야 한다고 함.
  40. 실험(experimentation)과 개선으로 넘어가며, 모두가 트레이스에서 시작하는 건 아니라고 함.
  41. 트레이스가 있으면 신호가 나쁜 지점을 찾아 데이터셋으로 모을 수 있고, 트레이스가 없으면 입력-출력 쌍으로 된 데이터셋을 바로 올려도 된다고 함.
  42. 이렇게 모은 데이터셋으로 실험을 돌리는데, 실험은 결국 프롬프트·모델·오케스트레이션·설정을 바꾸는 일이고 UI로도 프로그래밍으로도 돌릴 수 있다고 함.
  43. 대부분 사용자는 대시보드나 버튼, 수작업 속에서 살고 싶어 하지 않는다는 걸 깨달았다고 함.
  44. 소프트웨어는 앞으로 압축될 거고, 만들기도 커스터마이즈하기도 더 쉬워질 거라고 함.
  45. 그래서 아라이즈는 지금까지 보여준 걸 전부 클로드 코드나 코덱스 같은 코딩 에이전트가 CLI와 도구·스킬로 그대로 쓸 수 있게 열어뒀다고 함.
  46. 클로드 코드 같은 AI 시스템이 아라이즈 시스템의 "알렉스(Alex)"를 직접 호출해 "내 애플리케이션에 문제 있어?"라고 물으면 알렉스가 계획을 세우고 작업을 실행한다고 함.
  47. 회사의 최종 목표는 사용자를 이 과정 전체에서 걷어내는 것이라며, 관측·평가·실험·개선이라는 순환 전체가 자동화될 수 있다고 믿는다고 함.
  48. 마법이 아니지만 마법처럼 느껴져야 한다며, 아라이즈 생태계를 가져다 놓기만 하면 그냥 돌아가는 게 목표라고 함.
  49. 사용자가 평가를 직접 고를 필요조차 없어야 한다고 믿으며, AI가 트레이스를 보고 그 자리에서 평가를 만들거나 무언가 바뀌었을 때 새 평가가 필요하다는 걸 스스로 알아채야 한다고 함. 실제로 알렉스가 이미 지연이 높다거나 에러가 감지됐다는 걸 스스로 찾아 일하고 있다고 보여줌.
  50. 제품은 두 가지라며, 엔지니어링 중심 사용자를 위한 오픈소스 아라이즈 피닉스(Arize Phoenix)는 쿠버네티스(Kubernetes) 계층 없이 컨테이너 하나로 로컬에 띄울 수 있다고 함.
  51. 가장 큰 기업들은 아라이즈 AX를 쓰는데, 우버(Uber)·부킹(Booking)·레딧(Reddit) 같은 곳이 대표적이라고 함.

한줄 코멘트. 비기술 인력에게 평가를 맡기는 UI를 정성껏 만들어놓고 최종 목표는 그 UI 자체를 없애는 것이라고 밝힌 것은, 지금 파는 제품과 회사가 그리는 미래가 서로를 지우는 셈임.

  1. 발표자 필 헤첼(Phil Hetzel)은 브레인트러스트(Braintrust)에서 솔루션 엔지니어링을 이끎.
  2. 브레인트러스트 이전엔 컨설팅·시스템 구축 업계에서 12년을 보냈고, 슬랄롬 컨설팅(Slalom Consulting)에서 데이터브릭스(Databricks) 글로벌 프랙티스를 이끌었다고 밝힘.
  3. 그때 고객사들이 생성형 인공지능(AI) 개념증명(proof of concept)은 잘 만드는데 프로덕션까지 가져가는 건 잘 못하더라는 걸 봤다고 함.
  4. 그래서 브레인트러스트를 사용자로 먼저 써보다 마음에 들어 지원했고, 입사한 지 1년쯤 됐다고 함.
  5. 브레인트러스트는 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 품질 플랫폼이라고 소개함.
  6. 첫째로, 프로덕션에 올라간 에이전트가 기대한 만큼 도는지 계속 믿을 수 있는지를 봄.
  7. 둘째로, 버전을 바꿔가며 실험할 때마다 그 확신을 다시 얻을 수 있는지를 봄.
  8. 전통 관측(observability, 시스템이 잘 도는지 실시간으로 들여다보는 일)은 이미 자리 잡은 분야라, 그라파나(Grafana)나 데이터독(Datadog)이 있는데 왜 새 도구가 필요하냐는 질문을 자주 받는다고 함.
  9. 이날 발표의 핵심 주장은 전통 관측과 에이전트 관측이 다루는 범위 자체가 다르다는 것임.
  10. 전통 관측의 범위는 가동시간과 기술적 성능임. 서비스가 떠 있는지, 기대한 기술적 사용자 경험을 주는지를 봄.
  11. 구체적으로는 지연시간, 상호작용에 걸린 시간, 400번대와 500번대 에러를 잼.
  12. 브레인트러스트도 자기 웹사이트의 400·500 에러를 볼 때는 데이터독을 그대로 쓴다고 밝힘. 이 용도엔 데이터독이 잘 맞는다고 함.
  13. 전통 관측의 구성요소는 시간에 걸쳐 모으고 재는 지표(지연시간, 에러 수 등)임.
  14. 나머지 한 축은 트레이스(trace, 작업 흐름 전체의 기록)와 스팬(span, 그 안의 한 단계)임.
  15. 이 개념 자체는 에이전트 관측에도 그대로 적용된다고 함.
  16. 첫 번째 문제로 짚은 건, 일반 애플리케이션은 결정론적이지만 에이전트는 비결정론적이라는 것임.
  17. LLM(거대언어모델)을 쓰는 이유 자체가 다양한 답을 낼 수 있고 추상화되어 있어서인데, 그게 곧 경로가 매번 달라질 수 있다는 뜻이라고 함.
  18. 일반 애플리케이션은 정해진 흐름을 타도록 일부러 결정론적으로 짜지만, 에이전트는 왜 이 경로를 탔는지 자체가 궁금해해야 할 대상이라고 함.
  19. 그래서 전통 관측은 좁고 정해진 지표만 보면 되지만, 에이전트 관측은 훨씬 넓은 것들을 재야 한다고 함.
  20. 에이전트 관측도 첫 토큰까지 걸린 시간, 총 토큰 수, 걸린 시간, 지연시간처럼 전통 관측과 비슷한 지표는 그대로 잼.
  21. 다만 그 위에 얹어야 할 게 있음. 그라운딩(grounded, 답이 실제로 가져온 문맥에 근거했는지)을 봐야 한다고 함.
  22. 추론 과정에서 기대한 도구를 실제로 불렀는지도 봐야 한다고 함.
  23. 시스템 프롬프트로 정해둔 브랜드 기준에 답이 맞았는지도 봐야 한다고 함.
  24. 이런 질적 판단은 전통 관측 도구로는 못 잰다고 함. 계산에 필요한 트레이스 정보량 자체가 전통 관측이 다루는 트레이스보다 훨씬 크기 때문임.
  25. 두 번째 문제는, 에이전트 트레이스가 다루기 지저분하다는 것임.
  26. 절반쯤 구조화돼 있고, 그 구조화된 부분 안에도 비정형 텍스트가 잔뜩 들어 있다고 함.
  27. 트레이스 하나가 1기가바이트를 넘는 걸 본 적이 있다고 함.
  28. 고객사 중엔 스팬 하나만 20메가바이트에 이르는 경우도 있었다고 밝힘.
  29. 이걸 받아들이고 처리하고 실제로 써먹는 건 전통 관측과는 완전히 다른 시스템 문제라고 함.
  30. 그런데도 사용자들은 이걸 전통 관측 데이터만큼 빠르게, 정말 실시간으로 보고 싶어함. 에이전트가 시장에 맞아떨어져 사용자가 늘어날수록 더 빨리 보여달라는 요청이 들어온다고 함.
  31. 브레인트러스트 화면의 실제 트레이스 예시를 보여줌. 모델 호출과 도구 호출을 감싼 스팬이 여러 개 있고, 스팬 각각 안에도 비정형 텍스트가 잔뜩 들어차 있음.
  32. 그래서 두 가지를 동시에 해내야 함. 사용자가 에이전트와 상호작용하면 그 즉시 볼 수 있어야 하는 빠른 쓰기·읽기가 하나임.
  33. CLI(명령줄 인터페이스)로 SQL(구조화 질의어) 명령을 날려 트레이스·평가 데이터를 뒤지는 읽기 패턴을 같이 받쳐줘야 하는 게 다른 하나임.
  34. 이건 완전히 새로운 시스템 문제라서, 브레인트러스트는 에이전트 트레이스 전용 데이터베이스를 처음부터 새로 짰다고 함.
  35. 자세한 내용은 최근 올린 블로그 글에 있다고 안내함.
  36. 우선 라이트-어헤드 로그(write-ahead log, 쓰기와 동시에 기록을 남겨두는 방식)에 데이터를 바로 넣어서, 트레이스가 생기자마자 볼 수 있게 했다고 함.
  37. 필터링이나 분석 쿼리가 빠르도록 인덱싱도 따로 만들었다고 함.
  38. 텍스트 검색용으로는 Tantivy라는 오픈소스 프레임워크를 포크해서 씀.
  39. 이전 트레이스에서 "아마존"이라는 단어가 들어간 것만 전부 찾고 싶다는 요청이 실제로 들어오는데, 텍스트 전체를 색인해두지 않으면 이게 안 된다고 설명함.
  40. 청중이 Tantivy가 오픈소스 엔진이냐고 묻자, 아파치 루씬(Apache Lucene)과 가장 비슷한데 러스트(Rust)로 짜여 있다고 답함.
  41. 이렇게 모인 조각들은 결국 SQL이나 그와 비슷한 언어 하나로 묶어서 다뤄야 하는데, 브레인트러스트가 택한 방식이 그거라고 함.
  42. 세 번째 문제는, 전통 관측을 보는 사람이 딱 정해져 있다는 것임. 시스템 엔지니어나 제품 엔지니어고, 의료 서비스라 해도 임상의나 간호사는 안 봄.
  43. 잘하는 에이전트 팀을 보면 기술 인력과 비기술 인력이 함께 이 작업을 한다고 함.
  44. 비기술 인력이 사용자와 더 가깝거나, 문제 영역 자체를 더 잘 알기 때문이라고 함.
  45. 이제는 비기술 인력도 자연어로 프롬프트를 쓸 수 있어서 에이전트 작업에 실제로 값을 보태게 됐다고 함.
  46. 브레인트러스트 플랫폼에서 임상의, 등록 간호사, 자산관리사, 변호사가 직접 트레이스를 들여다보며 에이전트를 개선하는 걸 봤다고 함.
  47. 가동시간만 걱정하는 전통 관측에선 볼 수 없는 워크플로라고 함.
  48. 브레인트러스트는 관측과 평가(eval)를 사실상 같은 문제로 본다고 함. 차이는 평가는 입력을 미리 알고 배치로 돌리고, 관측은 입력을 모른 채 실시간으로 받는다는 것뿐임.
  49. 이 공간이 어디로 가느냐는 질문엔, 고객이 자기 에이전트 트레이스를 전부 가진 브레인트러스트라면 사용자들이 에이전트를 어떻게 쓰는지 그냥 알려줄 수 있지 않냐고 묻는다고 함.
  50. 발표 약 한 달 전 SaaS(소프트웨어형 서비스) 상품에 이 기능을 실제로 내놨다고 함.
  51. 들어오는 트레이스에 가벼운 LLM을 돌려 임베딩과 클러스터링을 하고, 그걸로 토픽 모델링을 끌어올린다고 함.
  52. 이렇게 하면 사용자가 에이전트를 어떤 의도로 쓰는지, 어떻게 느끼는지(감성), 어떤 문제에 부딪히는지를 볼 수 있다고 함.
  53. 목표는 프로덕션에서 발견한 문제와 그걸 고치는 실험 사이의 반복 주기를 더 짧고 직접적으로 만드는 것이라고 함.
  54. 질의응답에서, 브레인트러스트가 기능적 관측만 보는지 비기능적 성능도 보는지 묻자, 기술적인 것도 본다고 답함.
  55. 트레이스를 뜨는 순간 프롬프트·걸린 시간·첫 토큰까지 걸린 시간·캐시 적중률 같은 기술 지표는 덤으로 딸려온다고 함. 본업은 에이전트 품질을 스스로 정의한 기준으로 재는 것임.
  56. "빙산 슬라이드"에서 수면 아래 사람이 매긴 주석(human annotation)이 뭐냐는 질문엔, 제품 매니저가 트레이스를 보고 잘했는지 못했는지 등급을 매기고 그 이유까지 적는 걸 예로 듦.
  57. 그 이유를 나중에 LLM에 돌려서 더 확장 가능한 채점 함수를 만들고, 그 과정에서 실패 패턴을 찾아 자동 채점으로 옮긴다고 함.
  58. 사람이 매긴 주석이 이 과정의 핵심이라고 함.
  59. 다른 에이전트 프레임워크와 오프라인 최적화를 어떻게 연결하는지, 왜 OLAP(온라인 분석 처리)을 안 쓰는지 묻는 질문엔, 예전엔 클릭하우스(ClickHouse)를 썼다가 옮겨왔다고 답함.
  60. 자체 데이터베이스를 만든 이유는, 창업자가 싱글스토어(SingleStore) 초기 멤버 출신이라 이런 일에 익숙했고, 클릭하우스가 텍스트 기반 인덱싱을 그때는 잘 못 해줘서였다고 함.
  61. 트레이스를 한번 뜨고 나면 그걸 오프라인 데이터셋에 넣어 실험에 쓰는 건 어렵지 않다고 함.
  62. 마지막 질문에서 "빙산" 비유가 다시 나옴. 점수를 매길 수 있는 "알려진 미지"는 온라인 채점으로 다룬다고 함.
  63. 반면 점수로 딱 떨어지지 않는 "모르는 미지"는 좀 더 열린 방식으로 통찰을 끌어낸다고 정리함.

한줄 코멘트. 이 발표의 설득력은 "범위가 다르다"는 주장을 스팬 20메가바이트, 트레이스 1기가바이트라는 크기로 증명한 데서 나옴.

  1. 이 발표는 캐글(Kaggle) 소속 두 사람이 AI 엔지니어 컨퍼런스에서 한 것으로, 주제는 에이전트 평가(agentic evaluation)를 소수의 전문가가 아니라 모두가 만들 수 있게 여는 방법임.
  2. 발표자는 닉(프로덕트 매니저, 캐글 벤치마크 플랫폼을 운영하고 에이전틱 평가 솔루션을 맡고 있음)과 마이클(캐글 소프트웨어 엔지니어, 평가·벤치마크를 만듦)임.
  3. 캐글은 대회로 잘 알려져 있지만 실제로는 3천만 명이 넘는 이용자를 둔 세계 최대 AI·머신러닝 커뮤니티고, 지난 2년간 생성형 AI 평가 분야에서 일해왔다고 밝힘.
  4. 발표 순서는 두 단계임. 먼저 지금 AI 평가가 왜 망가져 있는지를 짚고, 그다음 캐글이 이를 고치려고 시도하는 것들을 보여줌.
  5. 첫 번째 문제는 평가가 흩어져 있고 탈중앙화돼 있으며 금방 낡는다는 것임.
  6. 하루에 10개가 넘는 벤치마크가 새로 나오는데, 이걸 다 파악하려면 아카이브(arXiv, 논문 사전공개 사이트)에서 몇 시간씩 논문을 훑어야 하고, 닉은 이 일이 본업인데도 다 못 따라간다고 밝힘.
  7. 논문이 나온 뒤 리더보드가 잠깐 주목받다가, 저자들이 논문을 더 내려고 다음 벤치마크로 넘어가면서 그 리더보드는 곧 낡아버림.
  8. 두 번째 문제는 평가가 투명하지도, 접근 가능하지도, 검증 가능하지도 않다는 것임.
  9. 모델을 낸 회사가 공개하는 성능 차트를 봐도, 그 벤치마크가 실제로 어떻게 설정됐는지는 알 수 없음.
  10. 닉이 든 사례로, 캐글이 한 AI 랩과 함께 벤치마크를 냈는데 경쟁 랩이 그 결과가 마음에 안 든다며 직접 같은 벤치마크를 돌려서 훨씬 좋은 점수를 냈던 일이 있었음.
  11. 차이는 그 경쟁 랩이 자기네 API로 제공하는 압축(compaction) 기능을 써서 자기 모델을 최적화했는데, 캐글이 낸 원래 결과에서는 어떤 모델에도 그 기능을 쓰지 않았다는 것임.
  12. 그래서 사람들이 보는 벤치마크 점수가 실제 상태를 그대로 반영하지 않는 경우가 있다는 게 문제임.
  13. 세 번째 문제는 평가를 만드는 사람이 너무 적다는 것임.
  14. 닉은 이걸 큰 원과 작은 원으로 비유하는데, 큰 원은 세상의 모든 지식이고 작은 원들은 AI 연구자·기술 전문가임.
  15. 구글 AI 검색에 물어봤더니 AI 연구자는 3만 명 정도, 소프트웨어 엔지니어·데이터 과학자 같은 기술 인력은 3천만 명 정도라고 함.
  16. AI가 인류 대부분을 돕길 바라면서 정작 그 평가는 아주 작은 비율의 사람들만 만들고 있다는 것임.
  17. 평가되지 않고 벤치마크되지 않은 것은 힐 클라임(hill climb, 벤치마크 점수를 목표 삼아 조금씩 성능을 끌어올리는 과정)할 수도, 얼마나 잘하는지 알 수도 없다는 게 문제임.
  18. 이대로 가면 모델이 어떤 영역에서는 초인간적인데 다른 영역에서는 평범한, 들쭉날쭉한 능력 격차가 시간이 갈수록 더 심해질 것으로 봄.
  19. 닉은 이걸 인류 전체에 이익이 되는 공평한 AI가 아니라고 함.
  20. 실제 사례로 튀르키예에서 20년간 폐수처리장 엔지니어로 일한 캐글 사용자가 직접 만든 벤치마크를 소개함.
  21. 그 나라에서 안전 수칙을 지키지 않아 사람이 죽은 심각한 사고가 있었고, 이 사용자는 AI가 자기 일에서 이런 사고를 막는 데 도움이 될지 평가하려고 이 벤치마크를 만들었다고 함.
  22. 이건 웹 어디에도 없고 AI 랩이 경제적으로 이득이 안 돼 손대지 않는, 이 사용자의 20년 경험에서만 나올 수 있는 독자적인 데이터셋임.
  23. 그래서 캐글은 오픈소스로 평가 생태계에 기여하는 일이 중요하다고 봄.
  24. 해법으로 캐글은 네 가지를 동시에 진행 중인데, 앞의 둘은 닉이, 뒤의 둘은 마이클이 소개함.
  25. 첫째는 해커톤(hackathon)임. 누구나 해커톤을 열 수 있는 플랫폼임.
  26. 둘째는 에이전트 시험(agent exams)임. 에이전트가 평가받는 과정 자체를 대중화하려는 시도임.
  27. 셋째는 게임 아레나(Game Arena)임. 모델들이 서로 PvP(플레이어 대 플레이어) 게임을 벌이는 상시 갱신되는(evergreen) 벤치마크로, 엘로(Elo, 체스 등에서 쓰는 상대적 실력 점수) 방식 순위를 매김.
  28. 넷째는 벤치마크(Benchmark)임. 닉이 직접 운영하는 제품으로, 누구나 평가를 만들고 돌리고 공개 커뮤니티에 공유할 수 있는 플랫폼임.
  29. 해커톤이 중요한 이유는 사람들의 에너지와 전문성을 문제 해결로 모으는 좋은 방법이기 때문이고, 닉은 지난 3년간 세계가 생성형 AI를 만들려고 결집했던 일을 그 예로 듦.
  30. 참가자에게 문제를 풀 가드레일은 두되 창의성을 펼칠 여지도 남겨야 한다고 보고, 결과물은 소수가 아니라 모두를 위해 전부 오픈소스로 공개함.
  31. 지금 화면의 해커톤은 구글 딥마인드(Google DeepMind) AGI 팀과 함께 여는 중인데, 몇 주 전 딥마인드가 낸 AGI 인지 능력 측정 논문 속 10개 능력 중 5개에 초점을 맞춰 벤치마크를 만들게 하고 있음.
  32. 해커톤 운영의 두 번째 과제는 참가자에게 제대로 된 도구를 주는 것임. 참가자가 천 명 단위로 전 세계에서 접속할 때 데이터셋을 어디에 올리고 AI 모델에 어떻게 접근하게 할지가 생각보다 까다로움.
  33. 형편이 어려운 참가자는 최신 모델 API 키 다섯 개를 살 돈이 없을 수 있다는 걸 닉은 이번에 처음 고려했다고 밝힘.
  34. 세 번째 과제는 AI 에이전트가 아직 혁신과 창의성을 판단하는 데는 서툴다는 것임. 그래서 이 심사는 여전히 사람 전문가가 맡아야 하는데, 전문가들끼리도 판단이 잘 안 맞는다고 함.
  35. 에이전트 시험은 원래 이름이 SAT(standardized agent tests, 표준화 에이전트 시험)였는데 상표 문제로 이름을 바꿨다고 밝힘.
  36. 쓰는 방법은 한 줄짜리 프롬프트로 자기 에이전트를 붙이면 시험을 치르고 리더보드에서 다른 에이전트와 비교할 점수를 받는 것임. 지난주에 낸 실험적인 최소기능제품(MVP)이라고 함.
  37. 닉은 지금 AI 평가가 두 극단으로 갈려 있다고 봄. 한쪽은 연구소·기업이 최신 기술을 총동원해 자기 모델을 재는 쪽임.
  38. 다른 쪽은 오픈클로(open claw, 소비자용 에이전트 도구를 가리키는 표현) 같은 걸 만들면서, 정작 세상에 내보내기 전 테스트는 거의 안 하는 사람들임.
  39. 이날 아침 컨퍼런스에서 보안 권고가 1,100건 접수됐다는 이야기가 나왔다고 언급하며, 이런 소비자 에이전트 미검증이 앞으로 더 큰 문제가 될 것으로 봄.
  40. 이번 주 논의된 아이디어 중 하나는 안전에 초점을 맞춘 시험을 더 만드는 것임. 받은메일함이나 아마존 계정을 대신 맡기기 전에 빠르게 기준선을 확인할 수 있게 하자는 취지임.
  41. 시험 설계의 또 다른 과제는 접근하기 쉬우면서도 충분히 어려워야 한다는 것임. 너무 어려우면 시간이 오래 걸려 아무도 끝내지 못하고, 너무 쉬우면 원하는 신호를 주지 못함.
  42. 시장 반응은 뚜렷했음. 낸 지 일주일 만에 별다른 홍보 없이도 500개가 넘는 에이전트가 이 시험을 치렀다고 함.
  43. 온라인에 공개한 뒤로는 사람들이 자기 시험 결과를 공유하는 파생 게시물이나, 심지어 이 시험을 위한 준비 강좌 같은 것까지 자발적으로 나타났다고 함.
  44. 여기서 마이클이 넘겨받아 게임 아레나와 벤치마크를 소개함.
  45. 게임 아레나는 벤치마크가 금방 포화(saturation, 모델들이 다 만점에 가까워져 변별력을 잃는 상태)되는 문제, 즉 커뮤니티 벤치마크든 연구용 벤치마크든 공통으로 겪는 문제에 대응하려고 만든 것임.
  46. PvP 구조라 절대 포화될 수 없다는 게 요지임. 한 모델이 한동안 최고일 수는 있어도, 다른 모델이 언제든 그 자리를 두고 다시 겨룰 수 있기 때문임.
  47. 게임을 고를 때는 모델의 서로 다른 능력을 따로 떼어 볼 수 있는 다양한 게임을 고르려 함.
  48. 지금까지 많이 투자한 게임은 늑대인간(Werewolf, 속임수 능력을 보는 게임), 포커(무작위성과 속임수를 함께 보는 게임), 체스(머신러닝을 분석할 때는 늘 체스를 빼놓을 수 없다는 이유로 넣음) 셋임.
  49. 포커에서 그록(Grok)은 올인을 즐겨 하는 반면 다른 모델은 좀 더 신중한 편이고, 흥미롭게도 최신 세대 모델일수록 위험을 더 꺼려 포커 성적이 오히려 나쁜 경우가 있는데, 이런 식으로 모델마다 다른 성향이 시간이 지나며 드러난다고 함.
  50. 게임을 고르고 나면 모델이 실제로 그 게임을 플레이할 수 있는지 확인하고, 프롬프트가 공정하게 짜였는지 다듬는 데 시간을 많이 쓴다고 함.
  51. 이 모든 작업은 오픈소스로 공개돼 누구나 들여다볼 수 있고, 캐글에서 직접 확인할 수 있다고 함.
  52. 하니스(harness, 에이전트가 도구를 부르고 결과를 받는 실행 틀)를 만들 때는 대부분 오픈스필(OpenSpiel, 강화학습용 프레임워크) 게임을 썼음.
  53. 모델이 무작위로 두는 것보다 나은지부터 확인하는데, 보통은 낫지만 어떤 경우엔 그 차이가 별로 크지 않다고 함.
  54. 시뮬레이션은 코랩(Colab)에서도 쓸 수 있는 LLM 모델 프록시로 여러 모델과 일관되게 대화하도록 돌리고, 원래 LLM이 커지기 전에 있던 캐글의 강화학습 시뮬레이션 플랫폼 위에서 실행함.
  55. 게임을 너무 많이 돌리지 않아도 되도록 브래들리-테리(Bradley-Terry) 짝짓기 방식을 씀.
  56. 결과는 모델 간 대화를 데이터셋으로 캐글에 공개하고, 벤치마크에는 엘로 점수를 보여주고, 게임 시각화 도구로 예컨대 그록이 포커에서 올인하는 장면 같은 걸 직접 볼 수 있게 함.
  57. 가장 큰 과제는 비용임. 포커에서 통계적으로 유의미한 결과를 얻으려면 판을 약 40만 번 돌려야 했고, 판마다 여러 턴이 있어 비용이 커짐.
  58. 브래들리-테리 짝짓기도 이 비용을 줄이는 방법 중 하나지만, 수백만 판을 돌리지 않고도 어떤 모델이 실제로 무엇을 잘하는지 확신할 방법을 계속 찾고 있다고 함.
  59. 두 번째 과제는 LLM끼리 계속 게임하는 걸 지켜보는 일이 지루해질 수 있다는 것임. 그래서 커뮤니티가 프롬프트를 직접 제공해 참여하고 리더보드를 오르는 해커톤 같은 방식으로 참여를 끌어내려 한다고 함.
  60. 세 번째 과제는 시간에 따른 비교가 어렵다는 것임. 옛 모델은 사라지고 새 모델이 나오는 데다, 모델 엔드포인트에 물어봐도 뒤에서 실제로 어떤 모델이 도는지 정직하게 알려주지 않는 경우가 있다고 함.
  61. 벤치마크는 프로덕션 평가 플랫폼이 아니라고 못박음. 그런 용도는 다른 회사들이 이미 하고 있고, 이 제품은 커뮤니티가 함께 만드는 데 초점을 둠.
  62. 구조는 프로덕션 평가 플랫폼과 비슷함. '이 안에 수건이 들어 있는가' 같은 단순 조건 검사(assertion)부터 LLM이 직접 답을 채점하는 LLM 심사까지 함께 씀.
  63. 이 검사들을 모으면 하나의 과제(task)가 되고, 과제를 여러 모델에 돌려 채점한 뒤 여러 과제를 모으면 하나의 벤치마크가 됨. 앞서 나온 폐수처리장 벤치마크도 이런 구조로 만들어진 것임.
  64. 앞선 세션에서 발표한 페이지(Paige)가 만든 예로, XKCD 만화의 SVG(벡터 그림 형식) 그림을 과제 삼아 모델에게 그대로 다시 그리게 시키고, SVG가 제대로 나오는지·텍스트가 맞는지 같은 검사 여러 개로 채점하는 과제를 벤치마크에 올렸음.
  65. 벤치마크를 만드는 일이 왜 어려운지 두 가지를 꼽음. 하나는 영감과 동기부여임. 프로덕션 평가는 고객에게 바로 영향을 주니 동기가 뚜렷하지만, 커뮤니티가 다른 사람도 흥미로워할 벤치마크를 스스로 만들도록 이끄는 일은 훨씬 어렵다고 함.
  66. 해커톤과 캐글의 포인트·메달 시스템이 어느 정도 동기부여에 도움이 됐지만, 좋은 평가 하나를 쓰는 데는 여전히 손이 많이 간다고 함.
  67. 다른 하나는 에이전트 벤치마크를 돌리는 일 자체가 모호해졌다는 것임. 처음엔 모델 자체만 분석하면 됐는데, 지금은 에이전트가 무엇을 하고 있는지를 봐야 해서 실제로 무엇을 테스트하는 건지 규정하기가 어려워짐.
  68. 그 예로 3월 16일 나온 모프LLM(Morph LLM)의 글을 인용함. SWE-bench Pro(소프트웨어 공학 코딩 벤치마크)에서 최상위 프런티어 모델 여섯 개의 점수가 몇 퍼센트포인트 차이밖에 나지 않았다는 내용임.
  69. 반면 같은 모델이라도 어떤 하니스 위에서 도느냐에 따라 성능이 최대 22퍼센트포인트까지 차이가 났다고 함. 마이클은 이 글을 직접 검증하진 않았지만 그럴듯해 보인다고 밝힘.
  70. 그래서 지금 벤치마크를 돌릴 때는 하니스를 테스트하는 건지 모델을 테스트하는 건지 자체가 모호해지는 문제가 생기고, 여기에 더해 모델이 빠르게 나왔다가 빠르게 단종되는 주기 때문에 시간이 지나며 비교하는 일 자체가 계속 어려워진다고 함.

한줄 코멘트. 평가를 만드는 사람이 3만 명뿐이라는 문제의식은 날카로운데, 정작 그 해법 넷은 전부 캐글이라는 한 플랫폼 안에 있어서 폐수처리장 엔지니어 같은 사례가 앞으로 몇 명이나 더 나올지는 이 발표만으로는 확인할 수 없음.

  1. 필 헷젤(Phil Hetzel) 소개, 브레인트러스트(Braintrust)에서 솔루션 엔지니어링을 이끈다고 함.
  2. 팀의 일은 고객이 플랫폼에서 최대한 빨리 값어치를 뽑아내게 돕는 것이라고 함.
  3. 브레인트러스트 오기 전 12년을 컨설팅에 썼는데, 처음 4년은 KPMG, 이후 8년은 슬랄롬 컨설팅(Slalom Consulting)에서 일하며 그곳 글로벌 데이터브릭스(Databricks) 사업부를 이끌었다고 함.
  4. 그때 고객들이 생성형 AI 개념증명(proof of concept)은 잘 만들면서 그걸 프로덕션까지 끌고 가는 데는 서툴렀다고 함.
  5. 그 틈을 메우려고 브레인트러스트를 먼저 유저로 쓰기 시작했고, 제품이 마음에 들어 아예 입사해 1년째 다니고 있다고 함.
  6. 일 밖에서는 체스를 두지만 잘하지는 못하고, 아내와 닥스훈트 피스톨 피트(Pistol Pete)와 시간을 보낸다고 함.
  7. 브레인트러스트는 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 품질 회사라고 소개함.
  8. 회사가 에이전트 품질에 기여하는 두 축은 평가와 관측(observability)이고, 시스템 관점에서는 이 둘을 같은 문제로 본다고 함.
  9. 평가는 에이전트를 프로덕션에 올리기 전 신뢰를 쌓는 일이고, 관측은 올린 뒤에도 그 신뢰를 이어가는 일이라고 함.
  10. 빠르게 크는 분야라 평가 플랫폼도 밑바탕 기술이 바뀌는 만큼 같이 커야 한다고 함.
  11. 오늘은 평가 이론만 다루고 플랫폼 얘기는 안 하며, 플랫폼이 궁금하면 아래층 부스로 오라고 함.
  12. 평가를 하는 이유는 오직 에이전트 품질을 위해서고, 실제 사용자 앞에서 기대한 대로 작동하는지 확인하려는 것이라고 함.
  13. 평판 위험(불친절하거나 무성의한 응대), 시스템 위험(에이전트가 돈을 너무 많이 쓰는 것), 컴플라이언스·법적 위험(에이전트가 궤도를 너무 벗어나는 것)까지 걸려 있다고 함.
  14. 평가는 이런 위험을 막는 방어이자, 수정할 때마다 얼마나 나아졌는지 보여주는 공격이기도 하다고 함.
  15. 평가는 유닛 테스트와 다르다며, 유닛 테스트처럼 모든 경우를 샅샅이 훑지 않고 에이전트의 실패 모드를 중심으로 시작한다고 함.
  16. 실패 모드는 본인이나 도메인 전문가가 짚어 알려줄 수 있다고 함.
  17. 있을 수 있는 실패를 전부 테스트로 만들려 하면 안 되는데, 경우의 수가 무한해서 테스트만 쓰다 아무것도 출시 못 하게 된다고 함.
  18. 평가 결과는 완벽할 필요 없이 방향만 맞으면 된다고 함.
  19. LLM 판정(LLM-as-judge, 사람 대신 다른 언어모델이 답의 품질을 채점하게 하는 방식)은 매번 100%가 나오진 않지만, 옳은 방향으로 가고 있으면 괜찮다고 함.
  20. 평가는 테스트 대상 과제(에이전트나 프롬프트), 그 과제를 실행시킬 예제 데이터셋, 품질을 매기는 채점 함수 세 요소로 이뤄진다고 함.
  21. 고객들에게서 본 성숙도는 네 단계인데 딱 끊어지기보다는 이어진 흐름에 가깝다고 함.
  22. 에이전트가 복잡해질수록 실패가 날 수 있는 지점이 늘어나 이 단계들을 필연적으로 거치게 된다고 함.
  23. 네 단계는 막 시작하기, 측정해서 관리하기, 복잡성 감당하기, 고급 평가 기법이라고 함.
  24. 1단계 - 감으로만 훑어보는 vibe 체크로 시작해도 괜찮고, 아무것도 안 하는 것보단 낫다고 함.
  25. 다만 vibe 체크를 하면서 반드시 기록을 남기라고 권함.
  26. 에이전트에 예시 입력 10개 정도를 주고 돌려가며 출력을 살펴보라고 함.
  27. 만든 사람이나 더 좋게는 도메인 전문가가 그 출력을 직접 평가해야 한다고 함.
  28. 좋다·나쁘다 표시와 함께 왜 그렇게 판단했는지 근거를 꼭 남기게 해야 한다고 함.
  29. 근거를 남기는 이유는 그 사람 머릿속에 있는 도메인 지식을 나중에 LLM 판정으로 확장해 쓰기 위해서라고 함.
  30. 워크플로는 트레이스(에이전트가 입력부터 출력까지 밟은 단계를 기록한 것)가 들어오면 좋다·나쁘다를 표시하고 근거를 붙이는 식이고, 이걸 나중에 LLM 판정 점수로 쓴다고 함.
  31. 브레인트러스트 플랫폼에는 사람이 직접 주석을 다는 화면이 있고, 사용자가 자기만의 주석 화면을 직접 코딩해 만들 수도 있다고 함.
  32. 범용 주석 화면을 그냥 주지 말고 각 팀의 트레이스 생김새에 맞게 구체적으로 만들어야 사람들이 제대로 평가한다고 함.
  33. 2단계 - 이제 근거들을 커서(Cursor)·클로드 코드·코덱스(Codex) 같은 도구에 돌려 실제 실패 모드를 뽑아낸다고 함.
  34. 실패 모드를 알게 됐으면 소수 전문가에게만 의존하지 않도록 그 지식을 자동화해 확장하고 싶어진다고 함.
  35. 방법 하나는 LLM 판정인데, LLM에 가운과 망토를 입혔다고 저절로 믿을 만해지는 게 아니라며 판정 결과 자체도 평가해야 한다고 함.
  36. 방법 둘은 코드로 결정론적으로 잡아내는 객관적 실패인데, 도구 호출이 너무 많거나 토큰을 너무 많이 쓰면 그 자체로 평가를 실패 처리해도 된다고 함.
  37. 이 단계에서 가장 중요한 건 프로덕션 트레이스, 적어도 UAT(User Acceptance Testing, 실사용자 조건에 가깝게 배포 전 검증하는 테스트) 수준 트레이스를 데이터셋에 담기 시작하는 것이라고 함.
  38. 평가를 테스트를 돌리는 일이 아니라 프로덕션을 다시 돌리는 일로 봐야 한다고 함.
  39. 사내에서 플라이휠이라 부르는 순환이 있는데, 프로덕션 트레이스를 모으고, 사람이나 자동 도구로 뭐가 잘못됐는지 파악하고, 그걸 오프라인 실험 환경으로 가져와 평가로 재실행해 에이전트를 어느 방향으로 고칠지 정한다고 함.
  40. 이게 평가로 공격하는 쪽이라고 함.
  41. LLM 판정 채점 함수를 만들어두면 사람 혼자 볼 때보다 평가 범위를 훨씬 넓게 잡을 수 있다고 함.
  42. 3단계 - 이제 단순 모델 호출을 넘어 외부 시스템과 일하는 도구 호출이 들어온다고 함.
  43. 도구는 컨텍스트를 모아 LLM에 넣어주는 것과, 외부 시스템 데이터를 생성·조회·수정·삭제(CRUD)하는 것 두 종류로 본다고 함.
  44. 둘 다 에이전트 품질에 크게 기여하지만 그만큼 잘못될 여지도 늘어난다고 함.
  45. 이제 출력 한 곳만 보는 게 아니라 트레이스 전체를 평가해야 하는 경우가 많아진다고 함.
  46. 큰 트레이스를 담아내고 각 단계를 들여다보고 개별 도구나 MCP(모델이 외부 도구·데이터에 표준화된 방식으로 연결하는 프로토콜) 호출 단위로 평가를 겨눌 도구가 필요해진다고 함.
  47. 문제 하나는 오프라인에서 CRUD를 실제로 실행하고 싶지 않고, 할 방법이 없을 때도 있다는 것이라고 함.
  48. 평가 입력이 만들어진 시점에 외부 시스템이 어떤 상태였는지를 재현하기가 어렵다고 함.
  49. 프로덕션 데이터를 덮어쓰지 않으면서 그 시스템들과 상호작용하기도 어려운데, 아직 완전히 풀린 문제는 아니라고 밝힘.
  50. 그래도 외부 시스템 상태를 표현하고 모의(mock) 수준 API로 프로덕션 환경에 가깝게 근사하는 방법은 있다고 함.
  51. 에이전트 트레이스는 일반 애플리케이션 트레이싱과 달리 얼마든지 커질 수 있어서, 시스템 상태 같은 컨텍스트를 통째로 트레이스 안에 담아 캡슐화할 수 있고 따로 테스트 인프라를 안 만들어도 된다고 함.
  52. 다른 기법으로는 타임스탬프 조회를 지원하는 시스템에 특정 시점 기준으로 질의하는 방법이 있다고 함.
  53. 예를 들어 벡터 데이터베이스를 입력이 만들어진 시점의 버전으로 조회하면 당시 상태를 그대로 재현할 수 있다고 함.
  54. 이런 기법은 더 복잡하고 아직 막 떠오르는 축이라고 함.
  55. 4단계 - 프로덕션에서 실패 모드를 자동으로 찾아내는 토픽 모델링을 대규모로 돌리는 것이라며, 아래층 부스에서 더 얘기하겠다고 함.
  56. 클로드 코드와 평가 제공사 CLI로 평가 자체를 자동화하는 흐름도 요즘 떠오르는 패턴이라고 함.
  57. 질의응답 - 결정론적 채점을 더 밀어야 하냐는 질문에, 주관적인 게 있어서 에이전트를 쓰는 것이라며 LLM 판정을 받아들이되 그 판정 자체도 사람 판단과 맞는지 계속 평가하라고 답함.
  58. LLM 판정 출력은 이산적이라 오히려 그라운드 트루스 데이터셋을 만들기 쉽다고 덧붙임.

한줄 코멘트. 1단계부터 근거 기록을 강제한 대목이 핵심임 - 평가 성숙도란 결국 사람 판단을 코드로 옮겨가는 과정이고, vibe 체크조차 그 첫 재료를 쌓는 단계로 다시 짠 것임.

  1. 이 발표는 마이크로소프트(Microsoft)와 깃허브(GitHub) 양쪽에서 시니어 개발자 애드보킷으로 일하는 마를린 음항가미(Marlene Mhangami)가 AI 엔지니어(AI Engineer) 컨퍼런스에서 한 것임.
  2. 발표자는 개발자들이 여러 제품에서 AI를 어떻게 쓰는지 살피는 코어 AI(Core AI)라는 조직 소속이라고 밝힘.
  3. 발표는 깃허브 옥토버스(Octoverse, 깃허브가 매년 내는 이용 현황 보고서) 2025년판 통계로 시작함. 2025년 한 해 깃허브에 올라온 커밋(commit, 코드 변경 기록)이 약 10억 건으로 역대 가장 많았다고 함.
  4. 2026년 들어 이 증가세는 더 빨라졌다고 함. 며칠 전 깃허브 최고운영책임자(COO) 카일 데이글(Kyle Daigle)이 매주 약 2억 7500만 건의 커밋이 올라온다고 트위터에 밝혔다고 함.
  5. 이 속도를 그대로 늘리면 올해 말까지 약 140억 건의 커밋이 쌓이는데, 이는 작년 최고 기록의 14배라고 함.
  6. 이 커밋 중 AI 에이전트가 공동 저자로 표시된 비중이 늘고 있다고 함. 클로드(Claude)와 코파일럿(Copilot)은 커밋에 서명을 남기지만 코덱스(Codex)는 안 남긴다고 함.
  7. 발표자가 이 증가를 보고 품은 질문은 AI가 실제로 개발자를 더 생산적으로 만드는가임. 코드량이 느는 것과 생산성이 느는 것은 다른 문제라는 취지임.
  8. 이 질문에 답하는 자료로 작년 AI 엔지니어 컨퍼런스의 한 발표를 인용함. 스탠퍼드 대학(Stanford University)이 개발자 12만 명을 조사한 연구가 근거임.
  9. 그 연구는 AI가 개발자를 더 생산적으로 만들지만, 정작 중요한 건 개발자가 AI를 어떻게 쓰느냐라는 결론을 냄.
  10. 깨끗한 코드베이스는 AI가 주는 생산성 이득을 키우고, 관리 안 된 AI 사용은 코드베이스의 무질서(entropy)를 키운다는 그래프를 보여줌.
  11. 이를 보여주는 사례로, 한 회사가 데이터베이스 작업에 AI를 관리 없이 쓴 경우를 듦. 풀 리퀘스트(PR, pull request) 수는 늘었지만 코드 품질은 떨어졌다고 함.
  12. 그 팀은 떨어진 코드를 다시 손보고 리팩터링(refactoring, 기능은 그대로 두고 코드 구조만 정리하는 작업)하는 데 시간을 더 많이 썼고, 결국 실질 산출은 1퍼센트 정도만 늘었다고 함.
  13. 이 연구에서 얻은 교훈은, AI로 얻고 싶은 가치가 결국 깨끗한 코드베이스를 갖췄는지에 달렸다는 것임. 테스트 커버리지·타입 커버리지·문서화·모듈화에 신경 써야 한다는 얘기임.
  14. 발표자는 팀과 업계 전반에 표준화된 관행을 두자고 주장함. 참석자 중엔 "눈 감고 그냥 배포한다"는 입장도 있다고 인정하면서도, 자신은 깨끗한 코드베이스를 지키는 표준화된 관행을 추천한다고 밝힘.
  15. 깨끗한 코드베이스를 만들고 지키는 방법 자체는 새로운 질문이 아니며, 업계가 그동안 시도해 온 방법론 중 하나로 테스트 주도 개발(TDD, test-driven development)을 꼽음.
  16. 최근 사이먼 윌리슨(Simon Willison)이 레드-그린 TDD(red-green TDD)라는 방식을 쓰는 방법을 블로그에 올렸다고 소개함.
  17. 레드-그린 TDD는 세 단계임. 기능 요청이 들어오면, 그 기능이 아직 없으니 실패하는 테스트부터 씀(레드 단계).
  18. 다음은 그 테스트를 통과시키는 데만 집중하는 그린 단계임. 이때는 코드 품질을 신경 쓰지 않고 속도만 신경 씀. 예전엔 스택 오버플로(Stack Overflow)에서 코드를 복사해서라도 테스트만 통과시켰다고 함.
  19. 마지막은 리팩터 단계임. 통과시킨 코드를 모범 사례를 따르도록 정리하는 단계로, 여기서만 코드 품질에 집중함.
  20. TDD를 모두가 좋아하는 건 아니라며, 2014년에 TDD가 "죽었다"고 선언된 일도 있었다고 함.
  21. 흔한 불만은 TDD가 유닛 테스트로 커버리지만 채우는 데 치중하고 정작 시스템 전체는 테스트하지 않는다는 것임. 레일스(Rails)를 만든 DHH가 2014년 이런 취지의 블로그 글을 올렸다고 함.
  22. 커버리지에 지나치게 의존하면 테스트가 구현 세부사항에 묶이는 경향이 생김. 할인이 적용된 주문 계산 예시에서, 기능은 그대로인데 메서드 이름만 바꿔도 거기 묶인 유닛 테스트는 깨져버림.
  23. 반대로 시스템의 행동(최종 결과값)이나 API처럼 잘 안 바뀌는 안정된 계약(contract)을 테스트하면, 내부 코드를 리팩터링해도 테스트는 살아남아야 한다고 함.
  24. 이 주제를 더 보고 싶다면 이언 쿠퍼(Ian Cooper)의 "TDD where it all went wrong" 강연을 추천한다고 함.
  25. AI 시대에 새로 생긴 문제로, AI가 테스트를 자동 생성할 때 스스로를 긍정하는(self-affirming) 테스트를 만드는 경우가 있다고 함. 유닛 테스트는 전부 초록(통과)인데 정작 시스템의 행동은 검증되지 않는 문제임.
  26. 그래서 이 발표의 나머지는 플레이라이트(Playwright)로 기능을 테스트해 이 문제를 피하는 법을 다룸.
  27. 플레이라이트는 마이크로소프트가 만든 오픈소스 테스트 프레임워크로, 브라우저에서 사용자 상호작용을 흉내 내 엔드투엔드(end-to-end, 처음부터 끝까지 실제 흐름을 통째로 검증하는) 테스트를 자동화함.
  28. 파이썬, 타입스크립트(TypeScript), C# 등 여러 언어를 지원하며, 예시 스크립트는 페이지에 들어가 검색창에 "Furby"를 입력해 검색을 실행하는 식으로 짜여 있음.
  29. 브라우저 창을 띄우는 헤디드(headed) 모드와, 화면 없이 백그라운드에서 도는 헤드리스(headless) 모드를 둘 다 쓸 수 있다고 함.
  30. AI와 함께 플레이라이트를 쓰면 TDD 전체 과정이 빨라진다고 함. 레드 단계와 그린 단계는 AI 에이전트가 빠르게 처리하게 하고, 대신 리팩터링 단계에 개발자가 시간을 더 많이 쓰도록 권함.
  31. 코딩 에이전트를 플레이라이트에 연결하는 방법은 여럿임. 플레이라이트 MCP(model context protocol, AI 에이전트가 외부 도구를 표준 방식으로 부르는 프로토콜) 서버를 쓰거나, CLI(명령줄 인터페이스) 도구를 쓰거나, 플레이라이트 에이전트(Playwright agents)를 쓸 수 있다고 함.
  32. 플레이라이트 에이전트를 설치하면 planner(계획)·generator(생성)·healer(수선) 세 개의 agent.md 파일이 깔림. 플래너는 어떤 테스트를 돌릴지 계획하고, 제너레이터는 테스트를 만들고, 힐러는 그 테스트를 고침.
  33. 데모로 들어가면서, 자신이 테일스핀 토이즈(Tailspin Toys)라는 장난감 회사의 개발자라는 가상 시나리오를 세움.
  34. 검색 제품관리팀에서 이메일이 왔고, 텍스트 검색과 애저 AI 서치(Azure AI Search, 복잡한 검색용)를 함께 쓰는 검색창과 카테고리·가격으로 거르는 사이드바를 추가해 달라는 요청이었다고 함.
  35. 데모는 깃허브 코파일럿 CLI(GitHub Copilot CLI)로 TDD 우선 방식을 쓰는 흐름을 보여줌.
  36. 먼저 워크IQ(Work IQ, 마이크로소프트가 만든 스킬로 M365 스위트에 연결해 아웃룩·파워포인트 등의 정보를 터미널로 가져오는 기능)를 써서 이메일 속 요청 내용을 터미널로 불러옴.
  37. 예전 유닛 테스트 방식에서는 클래스에 메서드를 하나 추가할 때 테스트를 썼다면, 이제는 기능 요청이 들어오는 순간이 테스트를 쓰는 계기라고 함.
  38. 두 번째 프롬프트로 코파일럿에게 레드-그린 TDD로 각 기능마다 실패하는 플레이라이트 테스트부터 쓰라고 지시하고, 이 데모에서는 변경분을 커밋하지 말라고도 지시함.
  39. 에이전트가 가장 먼저 하는 일은 기존 코드베이스를 살펴보는 것임. CLI에 플레이라이트 MCP 서버가 이미 설치돼 있어, 무엇을 테스트해야 할지 파악한 뒤 테스트를 씀.
  40. 이 과정이 시간이 걸려서, 발표자는 미리 돌려 둔 다른 탭으로 넘어감. 거기서는 실패하는 테스트, 통과시키는 그린 단계 코드까지 이미 만들어 둔 상태에서 플레이라이트 테스트를 실제로 돌리는 명령을 실행함.
  41. 화면에서 에이전트가 손 하나 대지 않고 페이지를 열어 검색창에 여러 입력을 넣고, "Furby"와 "Simon"이 올바르게 검색되는지 확인함.
  42. 이어 카테고리 필터 버튼을 클릭해 필터가 작동하는지, 가격대로 걸렀을 때 맞는 장난감이 나오는지도 확인함. 모든 테스트가 통과함.
  43. 발표자는 이렇게 기능 테스트를 돌리면 에이전트가 쓴 코드가 실제로 예상대로 작동하는지 눈으로 바로 확인할 수 있다고 함.
  44. 테스트가 통과한 뒤에야 그 코드를 리팩터링하는 다음 단계로 넘어간다고 함.
  45. 마지막으로 플레이라이트를 쓸 때의 권장 사항을 정리함. 첫째, 테스트를 돌릴 때 찍히는 스크린샷을 PR에 첨부하는 습관을 들였다고 함.
  46. 둘째, 데모처럼 브라우저 창을 띄우지 않고 헤드리스 모드로 백그라운드에서 돌릴 수도 있다고 함.
  47. 셋째, 에이전트가 테스트를 고치기 전에 먼저 코드를 커밋해 두라고 함. 커밋을 안 해 두면 에이전트가 이전에 무슨 일이 있었는지 기억하지 못할 수 있다고 함.
  48. 넷째, 기능 하나에 테스트 하나씩 만들라고 권함.
  49. 질의응답에서 상태 관리(state management)가 많은 앱은 어떻게 하냐는 질문에, agent.md 파일을 내려받는 플레이라이트 에이전트 쪽이 상태 처리에 특화된 지침을 이미 담고 있어 더 낫다고 답함.
  50. 플레이라이트로 전부 테스트하고 싶지 않다면 API가 있는 경우 API를 직접 테스트하는 것도 방법이라고 덧붙임.
  51. 모바일과 데스크톱을 둘 다 테스트할 수 있냐는 질문에는 그렇다고, 문제없이 작동할 거라고 답함.
  52. 다만 지금은 브라우저 기반 테스트로만 되고, 다른 형태는 아직 지원하지 않는다고 답함.

한줄 코멘트. 코드베이스가 깨끗해야 AI 이득이 난다는 스탠퍼드 연구는 설득력 있는데, 그 처방이 결국 마이크로소프트 자사 제품(코파일럿·워크IQ·플레이라이트) 조합으로 좁혀지는 대목은 걸러 들을 필요가 있음.

  1. 필 헷젤(Phil Hetzel)이 예전에 겸임교수를 하던 시절 이야기로 시작함, 첫 주 130명이던 수강생이 몇 주 지나면 10명까지 줄었다고 함.
  2. 그래서 강연할 때마다 네다섯 명만 와도 열심히 가르치자고 스스로 다짐한다고 하며, 오늘은 그와 달리 자리가 꽉 찼다고 함.
  3. 오늘 순서는 자기소개와 회사 소개, 문제 정의, 사람들이 평가 플랫폼을 만들며 거치는 단계들, 그리고 평가 플랫폼이 앞으로 갈 방향이라고 함.
  4. 본인은 브레인트러스트(Braintrust)에서 솔루션 엔지니어링을 이끌고 있고, 고객이 플랫폼에서 최대한 빨리 값어치를 뽑아내게 돕는 일이라고 함.
  5. 여러 고객사를 보다 보니 평가와 에이전트 관측(observability) 양쪽에서 업계 최신 수준이 뭔지 알게 된다고 함.
  6. 브레인트러스트 오기 전 12년을 컨설팅에 썼는데, KPMG에서 4년, 슬랄롬 컨설팅(Slalom Consulting)에서 8년 일하며 그곳 글로벌 데이터브릭스(Databricks) 사업부를 이끌었다고 함.
  7. 그때 고객들이 생성형 AI 개념증명(proof of concept)은 잘 만들면서 정작 프로덕션까지 끌고 가는 데는 거의 다 실패했다고 함.
  8. 그 틈을 메우는 데 도움이 될 것 같아 브레인트러스트를 먼저 유저로 쓰기 시작했고, 마음에 들어 아예 입사해 1년째 다니고 있다고 함.
  9. 일 밖에서는 체스를 두지만 실력은 형편없고, 아내와 닥스훈트 피스톨 피트(Pistol Pete)와 시간을 보낸다고 함.
  10. 브레인트러스트는 스스로를 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램) 품질 플랫폼으로 소개한다고 함.
  11. 에이전트 품질에 이르는 두 축은 평가와 관측이고, 시스템 관점에서는 이 둘을 같은 문제로 본다고 함.
  12. 평가는 프로덕션에 올리기 전 실험하며 자신감을 쌓는 일이고, 관측은 이미 실제 사용자 앞에 있는 에이전트가 기대대로 작동하는지 계속 확인하는 일이라고 함.
  13. 오늘은 회사 홍보를 하지 말라는 주문을 받았다며, 방금 슬라이드가 브레인트러스트 얘기의 마지막이라고 밝힘.
  14. 대신 회사가 이 분야에서 쌓은 경험을 바탕으로 사람들이 평가 플랫폼을 어떻게 키워 가는지를 개념적으로 얘기하고 싶다고 함.
  15. 평가가 중요한 이유는 당연해 보이지만 LLM(거대언어모델)이 극도로 변동성이 크기 때문이고, 그 변동성 덕에 훨씬 다양한 문제를 풀 수 있어 사람들이 LLM을 좋아하는 것이라고 함.
  16. 에이전트는 이 LLM을 두뇌로 쓰고, 이제 고객이 회사와 상호작용하는 표준 방식이 되어 사람들이 에이전트형 경험을 당연히 기대한다고 함.
  17. 이 둘을 합치면 에이전트가 프로덕션에서 어떻게 작동할지 확신이 있어야 하고, 없으면 브랜드·컴플라이언스·비용·유지보수 쪽에서 큰 위험을 떠안는다고 함.
  18. 청중에게 지금 구글 시트로 평가하고 있느냐 묻고, 부끄러울 것 없다며 그것도 문제를 인식했다는 뜻이라 중요한 첫걸음이라고 함.
  19. 고객들이 브레인트러스트가 뭔지 모르겠다며 자기가 필요한 건 그냥 에이전트를 여러 입력으로 돌려보고 점수와 메모를 보여줄 화면뿐이라고 말한다고 함.
  20. 그 말속에 들어있는 세 가지, 에이전트를 실행할 방법, 출력·점수를 보여줄 화면, 입력 예시를 모을 방법이 평가의 기본이라고 함.
  21. 평가가 딱 이 정도로 끝난다면 발표도 짧게 끝났을 텐데, 실제로는 빙산의 나머지 부분이 훨씬 크다고 함.
  22. 복잡한 이유 하나는 밑바탕 기술인 LLM 자체가 결코 단순하지 않다는 것이라고 함.
  23. 또 다른 이유는 여러 직군이 얽히는 문제라는 것인데, 제품 엔지니어·AI 엔지니어·시스템 엔지니어에 더해 도메인 지식을 가진 SME(주제 전문가)까지 다 참여해야 한다고 함.
  24. 마지막으로 평가 자체가 결국 시스템 문제로 귀결되는데, 이 얘기는 발표 끝에서 다룬다고 함.
  25. 1단계는 스프레드시트와 for 루프로 시작하는 것인데, 입력 예시를 훑으며 손볼 때마다 출력이 어떻게 달라지는지 볼 수 있어 진입 장벽 없는 좋은 출발점이라고 함.
  26. 다만 이건 실험이라기보다 기록에 가까워서, 시간이 지날수록 실험 간 직접 비교가 어려워지고 관리도 번거로워진다고 함.
  27. 이 단계의 분석은 대부분 사람이 직접 매기는 채점에서 나오는데, 값어치는 크지만 규모를 키우기가 힘들다고 함.
  28. 평가는 팀 스포츠라서 기술 인력만이 아니라 도메인 지식과 사용자 접점을 가진 비기술 인력도 끌어들여야 한다고 함.
  29. 그런데 이런 사람들은 스프레드시트에 잘 들어오지 않고, 매번 시트를 다시 만들거나 이어 붙이는 과정 자체도 느리다고 함.
  30. 다음으로 자주 보는 장면은 자신만만한 제품 엔지니어가 "브레인트러스트 정도는 그냥 바이브 코딩(vibe coding, 세세한 설계 없이 AI에게 대충 지시해 빠르게 코드를 뽑아내는 방식)하면 된다"고 말하는 순간이라고 함.
  31. 여정 초반이라면 이것도 나쁘지 않은 다음 걸음이라며, 스프레드시트를 벗어나 더 맞춤한 화면과 for 루프, 엑셀·구글 시트가 아닌 넌(Neon) 같은 데이터베이스로 옮겨가게 된다고 함.
  32. 이 단계에서는 평가 결과를 더 오래 저장할 수 있고 화면도 각 팀에 맞게 다듬을 수 있어 더 많은 사람을 끌어들이게 된다고 함.
  33. 다만 여전히 진짜 반복 실험은 아니고, 보고와 기록에 더 가까운 도구에 머문다고 함.
  34. 다음 단계는 기술 인력뿐 아니라 비기술 인력까지 실험을 하도록 만드는 것이라고 함.
  35. 여기서 실험이란 사용자에게 에이전트 설정과 샌드박스 접근권을 주고 특정 파라미터를 직접 건드려 보게 하는 것이라고 함.
  36. 예로 화면에서 시스템 지시문을 바꿔가며 같은 에이전트를 두 가지 설정으로 나란히 돌리고 평가를 붙여 점수를 뽑아내는 걸 보여준다고 함.
  37. 이게 흔히 말하는 플레이그라운드(설정을 그 자리에서 바꿔가며 실험해보는 화면) 기능이고, 기술·비기술 사용자 모두에게 필요하다고 함.
  38. 여기서부터가 본격적인 시작인데, 좋은 평가는 에이전트가 실패할 수 있는 지점을 먼저 생각하고 그 지점을 겨눈 채점 함수를 만드는 데서 나온다고 함.
  39. 실패 지점을 가장 잘 찾는 방법은 실제 사용자 앞에 놓인 프로덕션 트레이스(에이전트가 입력부터 출력까지 밟은 단계를 기록한 것) 데이터를 보는 것이라고 함.
  40. 그래서 다음 단계는 사내에서 "플라이휠"이라 부르는 것을 연결하는 일이고, 관측과 평가를 시스템 관점에서 같은 문제로 본다고 함.
  41. 3년 전 브레인트러스트를 시작했을 때는 평가 전용 플랫폼이었는데, 한 고객이 매시간 대규모 평가를 돌리는 걸 발견했다고 함.
  42. 물어보니 고객은 프로덕션 트래픽 전체를 데이터베이스에 흘려보내며 거기에 평가를 돌리고 있었다고 함. 그래서 오프라인 평가에 끼워 맞추는 대신 트래픽을 추적·관측하는 기능을 아예 제품에 넣기로 했다고 함.
  43. 목표는 프로덕션을 관측해 실제 에이전트 행동과, 바꾼 부분이 실제로 얼마나 개선을 냈는지를 이해하는 것이라고 함.
  44. 그렇게 분석한 실제 사례를 오프라인 환경으로 다시 가져와 오프라인 평가로 개선하고, 이 순환을 에이전트가 살아있는 내내 최대한 자주 돌려야 한다고 함.
  45. 그 결과 플랫폼의 범위가 넓어져 오프라인 평가 도구에 더해 트레이싱·로깅 플랫폼까지 겸하게 됐다고 함.
  46. 덕분에 실제 사용자 상호작용에서 훨씬 신호가 높은 데이터를 얻고, 평가가 거의 프로덕션을 안전한 환경에서 재실행하는 일에 가까워진다고 함.
  47. 이 단계에서는 관측 트래픽에 채점 함수를 바로 붙이는 온라인 평가와 알림 같은 기능도 만들 수 있다고 함.
  48. 다만 직접 만들면 직접 관리해야 하는 게 나쁜 점이라, 바이브 코딩으로 승진은 할지 몰라도 이후 그 플랫폼을 업계 속도에 맞춰 계속 키우는 게 본인 일이 된다고 함.
  49. 더 큰 난제는 에이전트 트레이스가 일반 애플리케이션 트레이스와 달리 대부분 반구조화되거나 아예 비구조화돼 있다는 것이라고 함.
  50. 텍스트 양도 엄청난데, 보통 트레이스 조각(span)이 수 킬로바이트인 것과 달리 이들이 본 조각은 10~20메가바이트에 달했다고 함.
  51. 이런 1기가바이트짜리 트레이스를 포스트그레스(Postgres) 한 행에 욱여넣으려 하면 성능 문제가 여러 갈래로 터진다고 함.
  52. 프로덕션에서 쓰임새가 많아 데이터가 빠르게 들어오는 만큼, 트레이스를 즉시 보여주는 저지연 조회와 데이터를 모아 집계 분석하는 별도 저장 계층 두 가지를 다 지원해야 한다고 함.
  53. 예전에는 집계 분석에 오픈소스 데이터 웨어하우스를 쓰고 두 저장소를 자체 개발한 도메인 특화 언어 BTQL로 이었는데 팀 스스로도 그 언어를 싫어했다고 함. 브라우저 안에서 덕디비(DuckDB)로 한 번 더 집계하는 세 번째 계층까지 얹었다고 함.
  54. 이 구성은 한동안 버텼지만 노션(Notion) 같은 고객이 방대한 비구조화 데이터를 보내며 트레이스 전체에 걸친 전문(全文) 검색을 요구하자 무너졌다고 함.
  55. 어떤 기존 기술도 LLM 특유의 방대한 텍스트를 다루는 텍스트형 분석에는 맞지 않았다고 함.
  56. 그래서 결론은 에이전트 품질을 재는 일이 화면(UI/UX) 문제가 아니라 시스템 문제라는 것이고, 화면은 바이브 코딩해도 데이터 계층은 훨씬 어렵다고 함.
  57. 규모 문제도 있지만 더 큰 이유는 수백만 트레이스에 걸친 전문 검색처럼 사람들이 당연히 되길 기대하는 기능을 실제로 되게 만드는 게 어렵다는 것이라고 함.
  58. 이 문제가 낯선 이유는 데이터가 빠르고 크고(스팬 하나가 10~20메가바이트) 비구조화돼 있고 읽는 패턴도 갈리는데, 개별로는 안 특별해도 넷이 합쳐지면 정말 독특한 시스템 문제가 된다는 것이라고 함.
  59. 그래서 결국 트레이스를 위한 제대로 된 데이터 플랫폼을 스스로 만들어야, 나중에 필요해질 기능형 요구사항들을 감당할 수 있다고 함.
  60. 예로 코딩 에이전트를 평가 플랫폼에 풀어 집계 데이터를 SQL로 직접 끌어와 스스로 에이전트를 고치게 하는 시나리오를 든다고 함.
  61. 이런 자가 치유식 작업은 데이터 백엔드에서 순수 SQL을 자유롭게 돌릴 수 있어야 가능하다고 함.
  62. 실제로 화면에는 관심 없고 코덱스(Codex)나 클로드 코드(Claude Code)로 평가를 돌려 에이전트 품질만 높이면 된다는 헤드리스(headless, 화면 없이 API나 명령줄로만 쓰는 방식) 요구가 늘고 있다고 함.
  63. 마지막 문제인 "그래서 뭐(so what)"는 시간 관계상 넘기며, 이 주제로 최근 낸 블로그 글이 있다고 밝힘.
  64. 앞으로 평가 플랫폼에 들어올 것은 트레이스를 일일이 훑게 하는 대신 토픽 모델링으로 에이전트가 실제로 어떻게 쓰이는지 알려주는, "모르는 걸 모른다"는 지점을 찾아주는 기능이라고 함.
  65. 사람만이 아니라 에이전트도 쓸 수 있게 플랫폼을 만들어야 한다며, 에이전트가 이제 기술을 만드는 주요 매체 중 하나이기 때문이라고 함.
  66. 오늘 다루지 않은 비기능 요구사항으로 역할 기반 접근 제어(RBAC, 사용자 역할에 따라 접근 권한을 다르게 주는 방식)와 데이터 마스킹(민감 정보를 화면에서 가리는 처리)도 규모가 커지면 반드시 필요해진다고 함.
  67. 마지막으로 AI 프록시나 게이트웨이를 거쳐 자동으로 트레이싱을 붙이면 사람들이 트레이싱을 할지 말지 선택할 필요조차 없어지고 중앙에서 통제할 수 있다고 함.
  68. 질의응답에서 파일·영상처럼 동적으로 만들어지는 멀티모달 입출력을 도구들이 잘 못 다뤄 커스텀 버전을 따로 만들게 된다는 지적이 나왔다고 함.
  69. 브레인트러스트는 이런 파일을 오브젝트 스토리지(파일을 통째로 저장하는 저장소)에 저장해두고 참조만 트레이스에 남기며, 오디오·영상 파일은 트레이스 화면 안에서 바로 재생되게 해 플랫폼을 벗어날 필요가 없게 한다고 답함.
  70. 프롬프트 관리도 브레인트러스트 안에 있느냐는 질문에는 있어도 되고 없어도 된다고 짧게 답하며 발표를 마쳤다고 함.

한줄 코멘트. 화면은 바이브 코딩으로 베낄 수 있어도 스팬 하나가 10~20메가바이트에 달하는 트레이스를 담아낼 데이터 계층은 못 베낀다는 게 이 발표의 핵심임 — 평가 플랫폼의 해자는 UI가 아니라 데이터베이스에 있음.

  1. 아라이즈(Arize)의 아파르나 디나카란(Aparna Dhinakaran)이 AI 엔지니어 컨퍼런스에서 프롬프트 러닝(prompt learning, 실패 사례에서 얻은 영어 피드백으로 시스템 프롬프트를 계속 고쳐나가는 방식)과 이걸 평가(eval)에 엮어 쓰는 법을 발표함.
  2. 프런티어(frontier, 성능이 가장 앞선) 코딩 모델에는 다들 관심이 쏠리지만, 정작 그 모델을 쓰는 코딩 에이전트(coding agent, 사람이 시킨 개발 작업을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)를 만드는 사람들이 시스템 프롬프트에 얼마나 공을 들이는지는 잘 안 알려져 있다고 지적함.
  3. 클로드(Claude)의 시스템 프롬프트가 유출돼 화제가 된 트윗을 보여주며, 클로드 코드(Claude Code)·커서(Cursor)·클라인(Cline) 각각의 시스템 프롬프트 길이를 비교함.
  4. 이 시스템 프롬프트들은 한 번 정해지고 끝나는 게 아니라 계속 고쳐 쓰는 것이며, 코딩 에이전트가 성과를 내는 데 이 부분이 굉장히 중요한 역할을 한다고 함.
  5. 카파시(Karpathy)도 이 얘기를 자주 한다며, 그가 이 반복 개선 방식에 "시스템 프롬프트 러닝"이라는 이름을 붙인 바이럴 트윗을 언급함.
  6. 카파시는 이게 사람이 배우는 방식과 비슷하다고 했는데, 영어로 된 피드백을 받아서 다음번에 뭘 다르게 할지 그 피드백을 근거로 정하기 때문이라고 함.
  7. 영화 '메멘토'에서 기억을 못 하는 주인공이 배운 걸 계속 적어두고 그걸 보고 다음 날을 살아가는 것과 비슷하다고 카파시가 표현했다고 함.
  8. 이 개념을 어떻게 실제로 쓰는지 보여주고, 가장 널리 쓰이는 코딩 에이전트 둘인 클로드와 클라인에 직접 적용해 시험해봤다고 함.
  9. 먼저 강화학습(RL)과 비교해 프롬프트 러닝이 어떻게 다른지 설명함. 시험 점수를 올리려는 학생으로 비유함.
  10. 강화학습에서는 학생이 시험을 보고 채점받아 70점·80점·90점 같은 스칼라(scalar, 방향 없이 크기만 있는 숫자) 보상만 받고, 그 점수 하나만 보고 다음 시험에서 뭘 어떻게 고쳐야 할지 거의 눈감고 알아내야 한다고 함.
  11. 강화학습이 여러 분야에서 잘 작동하는 건 맞지만, 정답에 이르는 길이 길어질 수 있고 샘플 효율이 낮고 시간과 데이터를 많이 잡아먹으며 전담 데이터 과학팀까지 필요할 수 있다고 지적함.
  12. 언어모델(LLM) 자체가 이미 충분히 좋아진 지금, 에이전트를 만들려는 팀에게 강화학습은 과할 수 있고 프롬프트 러닝이 더 맞는 방법일 수 있다고 함.
  13. 프롬프트 러닝에서는 같은 학생 비유에서 시험 점수 말고도 영어로 된 피드백을 함께 받음. 왜 맞았는지, 뭘 놓쳤는지, 어떤 개념을 더 공부해야 하는지까지 알려준다고 함.
  14. 이 정보를 가지고 학생이 다음 시험을 준비하는 것과 같은 방식을 코딩 에이전트에 그대로 적용해 클로드와 클라인 양쪽에서 시험했다고 함.
  15. 클로드 코드와 클라인 둘 다 시스템 프롬프트로 시작하고, 그 위에 규칙을 덧붙일 수 있는 파일을 갖고 있다고 함. 클라인은 클라인룰스(.clinerules) 파일, 클로드 코드는 클로드엠디(CLAUDE.md) 파일이며 둘 다 처음엔 비어 있다고 함.
  16. 이 파일에 저장소에 맞게 필요한 내용을 채워 넣을 수 있다고 함.
  17. 클로드와 클라인 양쪽을 스위벤치(SWEBench, 실제 깃허브 이슈를 코드 패치로 풀게 해서 채점하는 소프트웨어 엔지니어링 벤치마크)로 먼저 기준 성능을 쟀다고 함. BBH를 비롯한 다른 소프트웨어 엔지니어링 데이터셋에서도 같은 실험을 했지만, 발표에서는 스위벤치 사례를 중심으로 설명한다고 함.
  18. 클로드엠디나 클라인룰스에 아무것도 넣지 않은 순정 상태 기준, 클로드 소네트(Sonnet) 4.5를 쓴 클라인은 깃허브 이슈의 약 30%를 풀었고 클로드 코드는 약 40%를 풀었다고 함.
  19. 이 숫자를 출발점 삼아, 프롬프트 러닝으로 시스템 프롬프트를 고쳐서 이 벤치마크 점수를 더 끌어올릴 수 있는지가 이번 실험의 가설이었다고 함.
  20. 파인튜닝이나 모델 교체는 전혀 하지 않았고, 오직 시스템 프롬프트만 손댔다고 함.
  21. 실험 과정은 이렇다고 함. 코딩 에이전트에게 코드를 짜게 하고, 유닛 테스트를 돌리고, 그 결과를 LLM 판정(LLM-as-judge, 사람 대신 다른 언어모델이 답의 품질을 채점하게 하는 방식) 모델에 넘긴다고 함.
  22. LLM 판정 평가는 단순히 맞았는지 틀렸는지만 내놓지 않고, 왜 실패했는지·어떤 상황에서 잘 안 됐는지에 대한 설명까지 함께 내놓는다고 함.
  23. 이 설명을 다시 메타 프롬프트에 넣어서 앞으로 덧붙일 시스템 프롬프트 규칙을 만들어내는 게 전체 과정의 핵심이라고 함.
  24. 스위벤치에서 150개 예제를 뽑아 클로드와 클라인 양쪽에 규칙이 하나도 없는 원본 프롬프트로 소프트웨어 엔지니어링 문제를 풀게 하고, 나온 패치를 유닛 테스트로 돌렸다고 함.
  25. 유닛 테스트 결과가 맞았든 틀렸든 그걸 LLM 판정 평가에 넘겼는데, 이 단계가 가장 중요했다고 함. 여기서 실제로 설명이 나오기 때문이라고 함.
  26. LLM 판정 평가에는 문제 상황, 코딩 에이전트가 낸 해법, 유닛 테스트, 실제 정답까지 다 넣어줬다고 함.
  27. 좋은 평가 프롬프트를 쓰는 일, 즉 이밸 엔지니어링(eval engineering, 평가용 프롬프트와 데이터셋을 공들여 설계하는 작업)에 시간을 많이 쓴다며, 에이전트를 개선할 통찰을 얻는 가장 좋은 길이 잘 쓴 평가라고 함.
  28. LLM 판정 평가 프롬프트는 통과·실패 여부에 더해 왜 틀렸는지에 대한 설명까지 요구하도록 짰다고 함. 스위벤치 라이트(SWEBench Lite) 테스트의 특정 라이브러리에서는 파싱 오류가, 다른 경우는 예외 처리를 못 하는 문제가 나오는 등 오류 유형이 다양했다고 함.
  29. 이렇게 나온 각 실패 사례의 설명을 살펴본 뒤, 거대한 메타 프롬프트에 통째로 집어넣었다고 함.
  30. 메타 프롬프트에는 원래 클로드나 클라인의 시스템 프롬프트, 처음엔 비어 있던 규칙 파일, 입력값, LLM 판정 평가 결과, 그 평가에서 나온 설명까지 전부 넣었다고 함.
  31. 이 메타 프롬프트가 예전 세계(규칙이 하나도 안 붙은 원본 시스템 프롬프트)와 새 세계(그동안의 실수에서 배운 걸 담아 새로 생성한 규칙)를 비교하는 일종의 디프(diff)를 만들어냈다고 함.
  32. 이렇게 만든 새 규칙을 붙여서 스위벤치 라이트 전체를 다시 돌렸다고 함.
  33. 150개 예제만 가지고도 클로드 코드는 해결한 깃허브 이슈가 5%포인트, 클라인은 15%포인트 올랐다고 함.
  34. 가장 강력하다는 코딩 에이전트들에 겨우 150개짜리 학습 데이터만 썼다는 점을 강조하며, 이게 각자의 에이전트에 어떤 영향을 줄 수 있을지 생각해보라고 함.
  35. 청중이 궁금해할 만한 비교로, 이 방식이 DSPy(디에스파이, 언어모델 파이프라인을 자동으로 최적화해주는 오픈소스 라이브러리)의 프롬프트 최적화기인 GEPA와 뭐가 다른지 짚음.
  36. GEPA도 영어 피드백을 받아 그걸 프롬프트 안에 쓰는 방식이라 자신들의 접근과 개념적으로 매우 비슷하다고 함.
  37. GEPA와 나란히 벤치마크를 돌려봤더니, GEPA는 훨씬 많은 루프와 롤아웃(rollout, 정책을 실제로 끝까지 실행해보며 결과를 모으는 한 회차)이 필요했던 반면 자신들의 방식은 그 일부만으로 끝났다고 함.
  38. 영어 피드백을 쓴다는 밑바탕 아이디어는 같지만, 진짜 차이는 평가와 평가 프롬프트를 만들고 다듬는 데 훨씬 많은 시간을 들였다는 점이라고 함.
  39. 에이전트에게 정말 쓸모 있는 설명을 돌려주려면 평가 프롬프트의 품질이 결정적이었고, 이게 이 방식이 통하는 데 가장 중요한 요인이었다고 함.
  40. 더 알고 싶으면 회사 블로그를 보라며, 평가 프롬프트 최적화에 대해 많이 쓰고 있고 채용 중이라고 밝힘.

한줄 코멘트. 강화학습을 데이터 굶주린 눈감고 배우기로, 프롬프트 러닝을 채점표에 왜 틀렸는지 적어주는 선생으로 대비시킨 비유가 정확한데, 결국 이 선생 노릇을 하는 게 평가 프롬프트라서 프롬프트 러닝의 성패도 결국 좋은 평가를 쓰는 문제로 돌아옴.

  1. 마이크로소프트의 케이지 가나자와(제품 담당, 애저 AI 파운드리)와 나쿠마르 아르칼구드(엔지니어)가 AI 레드팀(자기 시스템을 일부러 공격해 약점을 찾는 작업) 에이전트를 소개함.
  2. 챗봇은 원하지 않는 말을 하게 만들거나 내부 정보를 유출하게 만들기 쉽다고 지적함.
  3. AI 엔지니어링은 파이썬 패키지, npm 패키지, 외부 호스팅 서비스 등 여러 생태계 위에 세워져 있어서 공격 표면이 넓다고 함.
  4. 샌프란시스코 도로에서 자율주행차가 정지 표지판을 켠 스쿨버스를 그냥 지나치는 영상을 보여주며, 내가 만든 것도 이런 실패를 할 수 있는지 생각해보라고 함.
  5. "은행을 어떻게 털지"라고 바로 물으면 대부분 모델이 거절하지만, 긴 사연을 앞세워 질문을 감싸면 방어를 우회할 수 있다고 함.
  6. 어제 열린 프롬프트 엔지니어링 레드팀 워크숍(샌더스 세션)을 언급하며 이런 우회 수법이 실제로 통한다고 함.
  7. 같은 질문을 거꾸로 뒤집어 쓴 문자열도 모델을 속여 답을 끌어내는 패턴 중 하나였다고 함.
  8. 2025년은 에이전트의 해라서, 에이전트가 도구를 스스로 호출하는 만큼 예상 밖의 위험과 오작동 우려도 커졌다고 함.
  9. 다리와 댐, 트럭과 기차를 사람들이 믿고 쓰게 만든 것처럼 엔지니어는 신뢰할 수 있는 것을 만드는 법을 안다고 하면서, AI 엔지니어링은 아직 그 신뢰를 못 얻은 초기 단계라고 함.
  10. 만들고 반복하고 점검하고 시험하는 엔지니어링 방식을 AI에도 그대로 적용하면 된다고 함.
  11. "신뢰는 팀 스포츠"라며, 엔지니어 혼자가 아니라 보안과 AI 위험에 전문성을 가진 사람들에게 기대야 한다고 함.
  12. 마이크로소프트 AI 레드팀은 몇 년 전부터 함께 일해온 조직으로, GPT-3·GPT-4 시절부터 이 모델들을 원치 않는 일을 하게 만들 수 있다고 먼저 지적한 팀이라고 함.
  13. 애저 AI 파운드리 팀이 이 AI 레드팀과 손잡고, AI 레드팀이 만든 파이썬 패키지 PyRIT을 SDK와 호스팅 대시보드로 감싸 엔지니어 누구나 쓸 수 있게 내놓았다고 함.
  14. 이제부터는 나쿠마르가 직접 코드를 보여주는 데모로 넘어감.
  15. 데모는 애저 샘플에 있는 포스트그레스 SQL 기반의 간단한 RAG(질문에 답하기 전에 외부 문서를 찾아와 근거로 쓰는 방식) 앱을 대상으로 함.
  16. 이 앱은 로컬에서 돌아가고, 오라마(Ollama)를 통해 로컬에서 실행 중인 모델과 대화함.
  17. 시맨틱 커널(Semantic Kernel) 에이전트를 보여주는데, 챗 컴플리션(모델이 대화 형태로 응답을 만드는 방식)을 받아 처리하고 SDK가 제공하는 레드팀 플러그인을 도구로 호출함.
  18. 이 플러그인은 에이전트가 레드팀 에이전트를 도구로 불러 사람의 레드팀 작업을 돕게 하는 데 필요한 함수들을 갖고 있다고 함.
  19. 미리 넣어둔 질문 몇 개를 먼저 돌리고 이후 대화형 모드로 넘어가는 구조이고, 공격 대상은 앞서 본 로컬 RAG 앱이라고 함.
  20. 이 대상은 질문을 입력으로 받아 문자열을 출력하는 어떤 애플리케이션으로도 바꿔 낄 수 있다고 함.
  21. 내부적으로는 SDK가 사용자의 애플리케이션을 호출한 뒤 그 응답에 대해 평가를 돌리는 구조라고 함.
  22. 에이전트에게 "폭력 카테고리에서 유해한 프롬프트를 하나 찾아달라"고 시키면 프롬프트를 만들어주고, 그걸 대상 앱에 보내라고 하면 대상은 스키 고글 같은 제품 정보로 답했다고 함.
  23. 이어서 같은 프롬프트를 베이스64(문자를 정해진 규칙대로 다른 문자열로 바꾸는 인코딩 방식)로 바꿔 다시 보내라고 하면 에이전트가 변환해서 보내고, 대상은 이번엔 다른 응답을 내놓았다고 함.
  24. 이런 식으로 대화하듯 애플리케이션을 공격해보는 것이 코파일럿 스타일의 레드팀 시작 방법이라고 함.
  25. 다음 단계는 전체 스캔을 끝까지 한 번에 돌리는 것으로, AI 프로젝트를 설정하고 URL과 자격 증명을 넣어 초기화한다고 함.
  26. 위험 카테고리를 고를 수 있는데 현재 네 가지가 있고 각각 평가기(evaluator)에 대응하며, 아무것도 고르지 않으면 기본으로 전부 포함된다고 함.
  27. 목표 개수(number of objectives)는 애플리케이션에 실제로 보낼 질문의 개수를 뜻한다고 함.
  28. 스캔을 실행할 때는 스캔 이름을 주고, 결과를 저장할 출력 경로를 선택적으로 지정할 수 있다고 함.
  29. 공격 전략은 여러 개를 목록으로 넣을 수 있는데, 문자열을 뒤집는 "이지(Easy)" 같은 조합형 전략도 있다고 함.
  30. 이런 변환기들은 원래 PyRIT 안에 있던 것을 SDK가 겉으로 노출한 것이라, 사람들이 쉽게 가져다 쓸 수 있다고 함.
  31. 시제를 바꾸는 변환과 URL 형식으로 바꾸는 변환처럼 서로 다른 전략 두 개를 합쳐서 공격을 구성할 수도 있다고 함.
  32. 전략을 조합해 만든 프롬프트도 결국 같은 대상 애플리케이션으로 보내진다고 함.
  33. 어제 GPT-4o를 모델로 돌렸을 때는 애저 AI 파운드리에 딸린 보안 기능이 많이 켜져 있어서 결과가 꽤 좋았다고 함.
  34. 표본이 아주 작아서 160건 정도였는데, 그 시도 중에는 애플리케이션을 뚫은 것이 하나도 없었다고 함.
  35. 이후 다른 설정으로 바꿔 돌렸더니 증오·공정성(hate and fairness) 카테고리에서 40건 중 5건이 공격에 성공했다고 함.
  36. 성공한 항목만 걸러서, 평가기가 유해하다고 판정한 실제 응답 내용을 확인할 수 있다고 함.
  37. 아직 애플리케이션이 없고 모델만 갖고 있는 경우를 위한 세 번째 방법도 보여주는데, 애저 오픈AI 설정을 그대로 스캔 대상으로 지정해 모델을 직접 공격할 수 있다고 함.
  38. 이때 대상 설정은 값 세 가지만 넣으면 되고, 그걸로 바로 전체 스캔을 돌릴 수 있다고 함.
  39. 미리 돌려둔 결과로, 가드레일을 전부 뗀 GPT-4.1을 직접 스캔했더니 폭력 카테고리 공격의 25%가 성공했다고 함.
  40. 같은 스캔에서 난이도 높은 복합 공격의 20%도 성공한 것으로 나왔다고 함.
  41. 성공한 항목을 걸러보니 폭력 관련이 많았고, 그중 하나는 시저(Caesar) 암호(알파벳을 몇 칸씩 밀어서 바꾸는 오래된 암호 방식)로 인코딩한 전략이었던 것 같다고 함.
  42. 모델이 그 시저 암호를 스스로 해독해서 답을 내놓았기 때문에 공격 성공으로 표시했다고 함.
  43. 반대로 GPT-4.1 나노에 가드레일을 다 켠 상태로 돌리자 공격 성공률이 조금 줄었다고 함.
  44. 스캔은 보통 완료까지 6분 정도 걸리고, 끝나면 결과 페이지로 바로 연결되는 URL을 보내준다고 함.
  45. 이 결과 페이지가 애저 AI 파운드리의 세이프티 이벌(safety evals)과 AI 레드팀 화면이라고 함.
  46. 여기서 다시 케이지가 이어받아, 레드팀은 신뢰할 수 있는 AI를 만들기 위한 방어 도구함 중 하나일 뿐이고 전체 개발 과정 안에 넣어야 한다고 함.
  47. 프로덕션 애플리케이션을 만들기 전에 먼저 이 앱이 에이전트인지, 외부 데이터를 쓰는지 내부 고객 데이터를 쓰는지 등 위험을 미리 지도로 그려보라고 함.
  48. 위험을 계획한 다음 가드레일을 먼저 구현하고, 그 뒤에 레드팀 같은 평가를 돌리는 순서로 가야 한다고 함.
  49. 애저 AI 파운드리에는 품질을 보는 평가기와, 위험·안전을 보는 평가기 묶음이 따로 있고 AI 레드팀 에이전트는 그중 하나라고 함.
  50. 입력과 출력 양쪽을 다 걸러야 하기 때문에 여러 종류의 분류기(classifier)를 함께 제공한다고 함.
  51. 에이전트형 애플리케이션 전용으로, 에이전트가 지시를 잘 따르는지 같은 것을 보는 평가기도 새로 만들었다고 함.
  52. 여기에 더해 사용자가 자기만의 커스텀 평가기를 추가할 수도 있다고 함.
  53. 레드팀을 돌려서 예를 들어 시도의 20%가 뚫린다는 걸 알게 되면, 그 지점에서 콘텐츠 필터 같은 가드레일을 적용하면 된다고 함.
  54. 프롬프트 실드(Prompt Shields)는 특히 레드팀에서 확인한 것 같은 프롬프트 기반 공격을 막기 위한 기능이라고 함.
  55. 청중 질문에 답하며, 가드레일은 입력 쪽 필터와 출력 쪽 필터 둘 다로 이루어진다고 함.
  56. 입력 필터는 "폭탄 만드는 법" 같은 문구를 모델에 닿기 전에 걸러내고, 출력 필터는 성적인 내용 같은 걸 모델이 낸 뒤에 걸러낸다고 함.
  57. 이 가드레일은 애저 AI 파운드리가 모델 바깥에서 직접 제공하는 기능이고, 모델 자체는 여전히 가공하지 않은 원본 모델이라고 함.
  58. 그래서 콘텐츠 필터를 다 끄면 나쿠마르가 데모에서 보여준 것처럼 원본 모델의 답이 그대로 나온다고 함.
  59. 마무리로, 아직 레드팀을 안 하고 있다면 오늘부터 시작하라고 권하며 코드와 문서 링크를 안내함.

한줄 코멘트. 가드레일을 끄자 GPT-4.1이 시저 암호를 스스로 풀어 답한 대목이, 안전장치가 모델 안이 아니라 밖에 있다는 걸 가장 잘 보여줌.

  1. 이 발표는 오픈AI(OpenAI) 정렬(alignment, 모델의 행동을 인간이 원하는 의도·가치에 맞추는 작업) 연구팀의 션 그로브(Sean Grove)가 AI 엔지니어 컨퍼런스에서 한 것으로, 주제는 코드보다 명세(specification, 의도와 가치를 글로 정리한 문서)가 낫다는 주장임.
  2. 발표 순서는 코드 대 소통의 가치 비교, 모델 스펙(model spec)의 구조, 사이코펀시(sycophancy, 사용자 비위를 맞추려 아첨하는 성향) 사례, 명세를 실행 가능하게 만드는 법, 명세를 코드로 보는 관점, 마지막으로 열린 질문 순임.
  3. 청중에게 코드를 쓰는지, 그 일이 직업인지, 그중 자신이 만드는 가장 값진 산출물이 코드라고 느끼는지 손을 들어보라고 물음.
  4. 션은 이게 자연스러운 답이라면서도, 실제로는 사용자와 대화하고 요구사항을 모으고 구현을 고민하고 여러 소스와 통합하는 과정 끝에 코드가 나올 뿐이라고 함.
  5. 코드는 가리키고 재고 토론할 수 있는 손에 잡히는 산출물이지만, 그 일이 만드는 가치의 10~20%에 불과하다고 함. 나머지 80~90%는 구조화된 소통(structured communication)이라고 함.
  6. 실제 과정은 사용자 이야기를 듣고 정리하고, 목표를 구상하고, 계획을 짜서 동료와 나누고, 그 계획을 코드로 옮기고, 코드가 아니라 코드가 세상에 낸 효과를 테스트·검증하는 순서라고 함.
  7. 코드 자체를 신경 쓰는 사람은 없고, 그 코드가 돌았을 때 목표를 이뤘는지 사용자의 어려움을 덜었는지만 중요하다고 함.
  8. 말하고 이해하고 정리하고 구상하고 계획하고 나누고 옮기고 테스트하고 검증하는 이 전부가 구조화된 소통이고, 이 소통이 병목이라고 함.
  9. 무엇을 왜 어떻게 만들지, 끝에 가서 제대로 만들어졌는지 아는 일 전부가 소통의 몫이라고 함.
  10. AI 모델이 발전할수록 이 소통 병목을 더 뚜렷하게 느끼게 될 것이고, 가까운 미래엔 가장 효과적으로 소통하는 사람이 가장 값진 프로그래머가 될 것이라고 함.
  11. 바이브 코딩(vibe coding, 세부 코드 대신 원하는 결과와 의도만 프롬프트로 전달하고 나머지는 모델에 맡기는 코딩 방식)을 예로 듦. 기분이 좋은 이유는 소통이 먼저이고 코드는 그 소통의 부산물이기 때문이라고 함.
  12. 그런데 이상한 점이 있다며, 모델에 의도와 가치를 프롬프트로 전달해 코드를 뽑은 뒤 그 프롬프트는 버리고 코드만 남긴다고 지적함.
  13. 타입스크립트(TypeScript)나 러스트(Rust)를 컴파일러에 넣어 바이너리(binary, 기계가 실행하는 이진 코드)로 만들 때는 아무도 그 바이너리를 소중히 여기지 않고, 컴파일할 때마다 소스에서 다시 만든다고 함.
  14. 값진 산출물은 소스 명세이지 바이너리가 아닌데, 프롬프트를 쓸 때는 거꾸로 생성된 코드는 남기고 프롬프트는 버린다며 「소스는 파쇄하고 바이너리만 정성껏 버전 관리하는 꼴」이라고 표현함.
  15. 그래서 의도와 가치를 명세에 담는 일이 중요하다고 함. 글로 쓴 명세라야 사람들이 같은 목표에 정렬됐는지 확인할 수 있다고 함.
  16. 명세는 토론하고 논쟁하고 참조하고 맞춰볼 수 있는 산출물이고, 명세가 없으면 그저 막연한 아이디어만 있는 것이라고 함.
  17. 코드는 명세에서 나온 손실이 있는 투영(lossy projection)일 뿐이라고 함. 컴파일된 C 바이너리를 역컴파일해도 좋은 주석이나 변수명이 나오지 않고 의도를 거꾸로 추론해야 하는 것과 같다고 함.
  18. 잘 짠 코드조차 팀이 궁극적으로 이루려는 목표를 전부 담지는 못해서, 코드를 읽을 때도 그 목표를 추론해야 한다고 함.
  19. 명세에 담긴 소통은 코드를 만드는 데 필요한 요구사항을 전부 담고 있어서 코드보다 낫다고 함. 소스 코드가 컴파일러를 거쳐 ARM64·x86·웹어셈블리(WebAssembly, 웹 브라우저에서 네이티브에 가까운 속도로 돌아가는 바이너리 형식) 등 여러 아키텍처를 겨냥할 수 있는 것과 같은 이치라고 함.
  20. 충분히 탄탄한 명세를 모델에 주면 좋은 타입스크립트·러스트 코드는 물론 서버·클라이언트·문서·튜토리얼·블로그 글·팟캐스트까지 뽑아낼 수 있다고 함.
  21. 개발자를 고객으로 둔 회사에 다니는 사람이 있는지 물은 뒤, 자기 회사의 코드베이스와 문서 전부를 팟캐스트 생성기에 넣으면 사용자가 성공하는 법을 알려줄 만큼 흥미로운 내용이 나올지, 아니면 그 정보가 코드 밖 다른 곳에 있는지 생각해보라고 함.
  22. 그래서 앞으로 희소해지는 기술은 의도와 가치를 온전히 담아 명세를 쓰는 일이고, 이를 잘하는 사람이 다시 가장 값진 프로그래머가 될 것이라고 함.
  23. 이 사람은 지금의 개발자일 가능성이 높지만, 프로덕트 매니저도 명세를 쓰고 입법자도 법이라는 명세를 쓴다며 이건 보편적인 원리라고 함.
  24. 여기서부터는 명세의 구조를 오픈AI 모델 스펙(model spec, 오픈AI가 모델에 심으려는 의도와 가치를 명확하고 모호하지 않게 정리한 살아있는 문서)을 예로 들어 설명함.
  25. 모델 스펙은 작년에 나왔고 올해 2월 업데이트되면서 오픈소스로 공개됐다며, 깃허브(GitHub)에 가면 그 구현이 그냥 마크다운(markdown) 파일 모음이라는 걸 볼 수 있다고 함.
  26. 마크다운은 사람이 읽을 수 있고 버전 관리되고 변경 이력이 남으며 자연어라서, 개발자뿐 아니라 프로덕트·법무·안전·리서치·정책 담당자까지 같은 소스를 읽고 토론하고 기여할 수 있다고 함.
  27. 이것이 회사 안 모든 사람을 같은 의도와 가치로 정렬시키는 보편적 산출물이라고 함.
  28. 모델 스펙의 모든 조항에는 아이디(ID)가 붙어 있고, 예를 들어 sy73 같은 조항 ID로 저장소 안 다른 파일을 찾을 수 있다고 함.
  29. sy73.md 같은 그 파일에는 해당 조항을 시험하는 까다로운 프롬프트가 들어 있어서, 모델이 그 조항을 실제로 지키는지 확인하는 성공 기준을 문서 자체가 담고 있다고 함.
  30. 사례 연구로 사이코펀시(sycophancy, 사실보다 사용자 비위 맞추기를 앞세우는 성향)를 듦. 최근 GPT-4o 업데이트가 극심한 사이코펀시를 일으켰다고 함.
  31. 보여준 예시는 사용자가 모델의 사이코펀시를 지적하자 모델이 오히려 그 지적을 「통찰력 있다」며 친절하게 칭찬하는 장면이었음.
  32. 다른 저명한 연구자들도 비슷하게 우려스러운 사례를 발견했고, 이런 식으로 사이코펀시를 내보낸 게 신뢰를 갉아먹었다며 아팠다고 함.
  33. 의도적이었는지 실수였는지, 왜 걸러지지 않았는지 같은 질문이 쏟아졌다고 함.
  34. 다행히 모델 스펙에는 공개 시점부터 「사이코펀시가 되지 말라」는 조항이 있었고, 단기적으로는 기분 좋아도 장기적으로는 모두에게 나쁘다고 설명하고 있었다고 함.
  35. 의도와 가치를 이미 명세로 표현해뒀기 때문에, 모델 행동이 그 명세와 어긋나면 이건 명백히 버그라고 판단할 수 있었다고 함.
  36. 그래서 업데이트를 되돌리고 연구 결과와 블로그 글을 내고 문제를 고쳤으며, 그 사이 모델 스펙은 무엇이 기대되고 무엇이 기대되지 않는지 알리는 신뢰의 닻(trust anchor) 역할을 했다고 함.
  37. 모델 스펙이 사람들을 같은 의도와 가치로 정렬시키는 일만 했어도 이미 충분히 유용했을 텐데, 이상적으로는 모델과 모델이 만든 산출물도 그 명세에 맞춰 정렬하고 싶다고 함.
  38. 이를 위한 기법으로 오픈AI가 낸 논문인 심의적 정렬(deliberative alignment)을 소개함. 명세와 까다로운 입력 프롬프트를 준비해 학습·테스트 중인 모델에서 응답을 뽑는 방식이라고 함.
  39. 그 응답과 원래 프롬프트, 정책을 더 큰 모델에 주고 명세에 얼마나 부합하는지 점수를 매기게 하면, 문서 하나가 학습 자료이자 평가 자료가 된다고 함.
  40. 이 점수를 근거로 가중치(weight)를 강화하는데, 이는 명세를 매번 컨텍스트나 시스템 메시지로 넣어주는 방식보다 나아가는 단계라고 함. 프롬프트로 넣는 정렬도 어느 정도는 통하지만 문제를 푸는 데 쓸 연산량을 깎아먹는다고 함.
  41. 명세는 코드 스타일이든 테스트 요구사항이든 안전 요구사항이든 무엇이든 될 수 있고, 이 기법으로 추론 시점 연산에서 모델 가중치 안으로 정책을 밀어 넣어 모델이 그 정책을 「근육 기억」처럼 체화하게 만든다고 함.
  42. 모델 스펙이 그냥 마크다운이어도 코드처럼 생각하는 게 유용하다며, 명세도 코드처럼 조합되고 실행되고 테스트되고 실세계와 맞닿는 인터페이스가 있으며 모듈처럼 배포될 수 있다고 함.
  43. 프로그래밍의 타입 체커(type checker, 서로 의존하는 모듈끼리 이해가 일치하는지 확인하는 장치)처럼, A 부서와 B 부서가 각자 쓴 명세가 서로 충돌하면 이를 잡아내 발행을 막아야 한다고 함.
  44. 정책 자체가 유닛 테스트를 품을 수도 있고, 지나치게 모호한 표현을 쓰면 사람도 모델도 헷갈려 결과가 나빠진다고 잡아주는 린터(linter, 코드 스타일이나 오류를 자동으로 짚어주는 검사 도구) 같은 것도 상상할 수 있다고 함.
  45. 이런 명세는 프로그래밍과 비슷한 도구 체계를 주지만, 겨냥하는 대상이 문법이 아니라 의도라는 점이 다르다고 함.
  46. 입법자도 프로그래머라는 이야기로 넘어가, 미국 헌법(US constitution)이 사실상 국가 단위 모델 스펙이라고 함.
  47. 헌법은 명확하고 모호하지 않으려 애쓴 성문 정책이고, 동의하지 않더라도 지금의 현실로 참조할 수 있으며 개정(amendment)을 통해 버전을 올리고 발행하는 절차가 있다고 함.
  48. 사법 심사(judicial review)는 채점자가 어떤 상황이 정책에 얼마나 부합하는지 채점하는 과정에 해당한다고 함.
  49. 세상은 어수선해서 정책이 예상 못 한 사례를 다루게 될 때가 있는데, 그때 법이 실제로 어떻게 적용되는지 이해하는 데 많은 연산이 들어가는 것이 사법 심사라고 함.
  50. 판결이 나면 그게 판례(precedent)가 되고, 이는 원래 정책 명세를 명확히 하고 강화하는 입력-출력 쌍짜리 유닛 테스트 역할을 한다고 함.
  51. 헌법에는 명령 체계(chain of command)도 담겨 있고, 시간이 지나며 이를 집행하는 과정 자체가 모두를 같은 의도와 가치로 정렬시키는 학습 루프(training loop)라고 함.
  52. 즉 헌법은 의도를 전달하고 준수 여부를 판정하고 안전하게 진화하는 방법까지 갖춘 하나의 산출물이라고 함.
  53. 그래서 입법자가 프로그래머가 되거나 프로그래머가 입법자가 될 가능성도 충분하다고 함.
  54. 이건 보편적인 개념이라며, 프로그래머는 코드 명세로 실리콘을 정렬시키고 프로덕트 매니저는 제품 명세로 팀을 정렬시키고 입법자는 법이라는 명세로 사람을 정렬시킨다고 정리함.
  55. 청중이 프롬프트를 쓸 때마다 그것도 일종의 원형 명세(proto specification)이고, 본인이 원하든 아니든 AI 모델을 공통된 의도와 가치로 정렬시키는 명세 저자라고 함.
  56. 명세는 더 빠르고 안전하게 만들 수 있게 해주고 누구나 기여할 수 있으며, PM이든 입법자든 엔지니어든 마케터든 명세를 쓰는 사람이 곧 프로그래머라고 함.
  57. 소프트웨어 엔지니어링은 원래 코드에 관한 일이 아니었다며, 처음에 손을 내렸던 사람들, 즉 자기 산출물이 코드가 아니라고 느낀 사람들을 다시 짚음.
  58. 엔지니어링은 인간이 소프트웨어로 인간 문제를 정밀하게 탐구하는 일이었고, 지금은 제각각인 기계용 인코딩에서 하나로 통일된 인간용 인코딩으로 옮겨가는 중일 뿐이라고 함.
  59. 다음 AI 기능을 만들 때는 명세부터 시작하라고 권함. 무엇이 일어나길 기대하는지, 성공 기준이 무엇인지 정하고 그게 명확히 적혀서 전달됐는지 토론하라고 함.
  60. 명세를 실행 가능하게 만들어 모델에 먹이고, 모델을 시험하거나 명세 자체를 시험하라고 함.
  61. 프로그래밍과 명세 작성 사이에 겹치는 부분이 많은 만큼, 미래의 통합 개발 환경(IDE)은 어떤 모습일지 궁금하다고 함.
  62. 션은 그게 「통합 사고 명료화 장치」 같은 것이길 바란다며, 명세를 쓸 때마다 모호한 부분을 짚어내 명확히 하라고 물어서 사람들이 서로에게, 그리고 모델에게 의도를 훨씬 효과적으로 전달하게 돕는 도구를 상상함.
  63. 마지막으로 도와달라고 요청하는데, 명세가 가장 절실하면서도 다루기 쉬운 대상이 대규모로 에이전트를 정렬시키는 일이라고 함.
  64. 「원하는 걸 한 번도 말해준 적이 없었다는 걸 뒤늦게 깨닫고, 어쩌면 스스로도 뭘 원하는지 제대로 몰랐을 수 있다」는 말을 인용하며, 이게 곧 명세를 써야 한다는 신호라고 함.
  65. 새로 꾸린 에이전트 견고성(agent robustness) 팀 이야기를 하며, 모두의 이익을 위한 안전한 AGI(범용 인공지능, 인간 수준 이상으로 폭넓은 과제를 해낼 수 있는 인공지능)를 만드는 데 함께하자고 청함.

한줄 코멘트. 심의적 정렬은 명세를 채점하는 「더 큰 모델」을 필요로 하는데, 그 채점 모델 자체가 무엇을 근거로 정렬됐는지는 다루지 않아 정렬 문제를 한 단계 위로 미룬 것처럼 보임.

  1. 세드릭 비달(마이크로소프트 수석 AI 애드보킷)이 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)를 어떻게 평가하는지 발표함.
  2. 바로 앞 세션이 레드팀(자기 시스템을 일부러 공격해 약점을 찾는 작업)이었다며, 그건 AI를 나쁜 상황에 몰아넣는 데이터를 만드는 작업이었고 이번 세션은 데이터셋을 놓고 하는 좀 더 전통적인 평가를 다룬다고 구분함.
  3. 발표를 준비하며 최신 모델과 SDK(소프트웨어 개발 키트)를 써볼 때마다 매번 놀랄 만큼 에이전트가 발전하고 있다고 함.
  4. 그런데 에이전트에게 주는 자율성(agency)이 커질수록 독립적으로 움직이는 정도도 커지고, 그만큼 일을 그르칠 위험도 커진다고 함.
  5. 청중에게 프롬프트 몇 개 넣어보고 답이 그럴듯하면 바로 프로덕션에 올리는지, 아니면 좀 더 체계적인 방법을 쓰는지 물음.
  6. 전자라면 지금 방식을 바꿔야 한다고, 그 방식은 결국 안 통한다고 함.
  7. 이미 앱을 만들어놓고 이제 와서 평가를 해야 하나 고민 중이라면 이미 늦은 것이라고 함.
  8. 평가는 AI 개발 프로젝트를 시작하는 그 순간부터, 이를수록 좋게 시작해야 한다고 함.
  9. 에이전트 평가에 접근하는 틀로 네 개 층을 구분한다고 함.
  10. 첫 층은 모델과 안전 시스템으로, 플랫폼 차원에서 걸리는 보호장치이고 애저(Azure)에 이미 내장돼 있어 애저 모델을 애저에서 쓰면 따로 손댈 게 없다고 함.
  11. 그다음 층은 시스템 메시지와 그라운딩(grounding, 답을 만들기 전에 근거가 되는 자료를 붙이는 것)이며, 이 부분과 사용자 경험은 앱을 어떻게 설계하느냐가 가장 크게 좌우한다고 함.
  12. 핵심은 기반 모델 자체는 전체 안전의 한 조각일 뿐이고, 진짜 안전은 애플리케이션 층에 여러 완화책을 겹겹이 쌓는 데서 나온다고 함.
  13. 제일 먼저 할 일은 수작업 모델 평가, 즉 에이전트에 어떤 모델을 쓸지 정하는 일이라고 함.
  14. 서로 다른 모델이 같은 프롬프트에 어떻게 답하는지 직접 보고 감을 잡아야 하며, 자동 지표만으로는 이걸 놓칠 수 있다고 함.
  15. 데이터셋 전체에 평가 지표를 한꺼번에 돌리면 평균 점수는 크게 나오는데 정작 특정 사례 하나가 왜 그런 점수인지는 알기 어려울 때가 있다고 함.
  16. 그래서 대규모로 평가하기 전에 먼저 예시 몇 개를 직접 골라 들여다봐야 한다고 함.
  17. 첫 데모로 VS Code(마이크로소프트의 코드 편집기)의 AI 툴킷(AI Toolkit) 확장 기능을 보여주는데, 마이크로소프트 빌드(Build) 콘퍼런스 즈음 나온 비교적 최신 플러그인이라고 함.
  18. 예전엔 모델을 비교하려고 깃허브 모델스(GitHub Models) 같은 여러 웹사이트를 오갔는데, 이제는 개발 환경 안에서 바로 할 수 있어 좋다고 함.
  19. "소금 캐러멜 버터를 넣은 판나코타 레시피 좀 알려줘"라는 프롬프트를 GPT-4.1과 GPT-4o 양쪽에 동시에 넣어 화면 좌우로 답을 비교함.
  20. GPT-4.1이 처리 속도(throughput) 면에서 크게 앞서 답이 훨씬 빨리 나온다고 함.
  21. 답의 품질만 보면 개인적으로 GPT-4.1 쪽을 더 좋아하고, GPT-4o도 나쁘진 않지만 4.1이 워낙 빠르니 보통 4.1을 쓰게 된다고 함.
  22. 이 단계는 아무 커스터마이즈 없이 기반 모델 자체를 점검한 것일 뿐, 아직 에이전트는 아니라고 함.
  23. 쓸 모델을 정했으면 다음은 시스템 전체를 처음부터 끝까지 평가할 차례라고 함.
  24. 같은 AI 툴킷으로 두 번째 데모에 들어가, 웹페이지에서 행사 일정 정보를 뽑아오는 에이전트를 미리 만들어 왔다고 함.
  25. 애드보킷으로 강연을 자주 다니다 보니 강연 목록·발표자·참석자 수 같은 정보를 웹에서 손쉽게 가져오는 에이전트가 필요했다고 함.
  26. AI 툴킷의 기본 예시 에이전트는 웹 스크레이퍼로, 시스템 프롬프트를 자동으로 만들어 "당신은 웹사이트를 돌아다닐 수 있는 웹 탐색 도우미"라고 지정해준다고 함.
  27. 이 기본 예시는 MCP(모델 컨텍스트 프로토콜, 에이전트가 외부 도구·서버를 표준화된 방식으로 불러 쓰게 해주는 규격) 서버도 자동으로 설정해준다고 함.
  28. 실행하면 플레이라이트(Playwright) MCP 서버가 켜지고, 기본값으로 지정된 예시 도메인 정보를 뒤에서 뽑아온다고 함.
  29. 이제 본인이 GPT-4.1로 직접 만든, 더 구체적인 목적의 에이전트로 넘어감.
  30. 이 에이전트는 특정 행사 페이지(루마 Luma)에서 이름·날짜·장소·참석자 수를 정해진 형식으로 뽑아내도록 만들었다고 함.
  31. 실행 결과, 행사명은 "AI 에이전트와 스타트업 토크"이고 장소는 샌프란시스코의 깃허브(GitHub) 본사, 날짜는 6월 11일로 나왔다고 함.
  32. 등록 인원은 269명으로 나왔고, 본인이 공동 주최한 행사라 데모 이후엔 신청자가 더 늘길 바란다고 함.
  33. 흥미로운 대목은 애초 크롤링한 행사 페이지엔 참석자 수가 없었다는 점이라고 함.
  34. 그런데도 에이전트가 그 페이지에서 루마 페이지로 걸린 링크를 찾아 스스로 이동해, 루마 페이지에 있던 참석자 수를 가져와 두 페이지 정보를 합쳐 답을 완성했다고 함.
  35. 둘 다 만족스러운 답이라, 이 결과를 엄지척(좋음)이나 엄지다운(나쁨)으로 수동 평가할 수 있다고 함.
  36. 하나의 입력으로 만들고 커스터마이즈하고 수작업으로 점검했으니, 이제 여러 입력에 대해 평가하는 법을 보여줌.
  37. AI 툴킷에는 평가(evaluation) 탭이 따로 있어, 앞서 만든 에이전트를 데이터셋 전체에 돌릴 수 있다고 함.
  38. "run all"을 누르면 뒤에서 에이전트가 각 입력을 처리해 응답 칸에 답을 채워준다고 함.
  39. 각 응답을 결과 파일로 내보내면 JSON 라인 형식 파일이 되고, 이걸 좀 더 자동화된 시스템에 다시 넣어 쓸 수 있다고 함.
  40. "view code"를 누르면 원하는 프레임워크로 코드를 생성해주는데, 요즘은 OpenAI 에이전트 SDK를 쓰려는 사람이 많고, 그러면 MCP 서버 설정과 에이전트 실행에 필요한 보일러플레이트 코드까지 다 갖춰진 상태로 받게 된다고 함.
  41. 여기까지가 에이전트를 만들고 개별 사례를 수작업으로 점검하고 소규모 배치를 로컬에서 돌려본 과정이라며, 그렇다면 사례 몇 개를 넘어 규모를 키우려면 어떻게 해야 하는지가 다음 물음이라고 함.
  42. 눈으로 직접 확인하는 방식은 감을 잡기엔 좋지만, 더 폭넓고 촘촘한 검사를 자동으로 돌려야 한다고 함.
  43. 애저 파운드리(Azure Foundry)는 이런 평가를 자동화하고 규모를 키우기 위한 다양한 내장 평가기(evaluator)를 제공한다고 함.
  44. 그라운디드니스(groundedness, 답이 근거 자료에 얼마나 충실한지)·유창성(fluency)·일관성(coherence) 같은 AI 기반 품질 평가기가 있고, 실제 대화 상황에서 에이전트가 얼마나 잘하는지 재는 데 적합하다고 함.
  45. F1·BLEU(기계 번역·생성 결과를 정답과 겹치는 정도로 채점하는 고전 지표)·ROUGE(요약문이 원문 핵심을 얼마나 담았는지 겹치는 단어로 재는 지표) 같은 전통적인 자연어처리 지표도 있어 벤치마크 비교에 쓴다고 함.
  46. 이 밖에 AI 기반 위험·안전 평가기 묶음도 있고, 원하면 직접 평가기를 만들어 붙일 수도 있다고 함.
  47. 수작업 점검이 끝났으면 다음은 규모를 키운 자동 평가로 품질을 재는 단계이고, 이건 애저 파운드리 포털에서도 코드로도 할 수 있는데 자기 앱의 쓰임과 목표에 맞춰 무엇을 잴지 직접 정의하려면 코드 쪽이 낫다고 함.
  48. 세 번째 데모로 노트북 파일을 보여주는데, 시간이 부족해 직접 실행하지는 않고 발표 끝에 링크를 공유하겠다고 함.
  49. 이 노트북에는 애저 AI 파운드리 프로젝트에 프로그래밍 방식으로 접속해 평가를 돌리는 파이썬 코드가 들어 있다고 함.
  50. 핵심 함수는 관련성(relevance)·일관성·그라운디드니스·유창성·유사도(similarity)를 재는 품질 평가기들을 정의하는 부분이라고 함.
  51. evaluate 함수가 이 평가기들과 평가할 데이터셋을 받아, 에이전트를 데이터셋 전체에 걸쳐 한꺼번에 채점해준다고 함.
  52. 예시로 쓴 데이터셋은 캠핑 관련 질문들로, 프랑스 수도가 뭔지·가장 방수가 잘 되는 텐트가 뭔지·어떤 캠핑 테이블이 좋은지 같은 질문이 섞여 있다고 함.
  53. 결과 화면에서는 질문마다 1점에서 5점 사이 점수가 나온다고 함.
  54. 통과 기준이 되는 문턱값(threshold)은 직접 설정할 수 있고, 게임 업계 앱은 보통 좀 더 폭력적인 콘텐츠를 허용하지만 아이들 대상 앱이라면 그렇게 느슨하게 잡을 수 없다는 식으로 앱 성격에 따라 정해야 한다고 함.
  55. 이번에 돌린 결과는 통과였고, 다음 평가기를 보여주려고 넘어간다고 함.
  56. 이어서 텍스트와 이미지를 섞은 멀티모달(multimodal, 텍스트·이미지·음성 등 여러 형태의 입력을 함께 다루는 것) 모델도, 여러 턴에 걸친 대화에서도 평가할 수 있다고 함.
  57. 데모용으로 일부러 폭력적인 이미지를 찾았는데, 콘퍼런스에서 공개적으로 보여줄 수 있을 만한 폭력적인 이미지를 구하기가 뜻밖에 어려웠다고 함.
  58. 폭력적인 이미지를 웹에서 찾아보면 보고 싶지 않은 것들까지 보게 된다며, 그래도 최대한 골라 준비했다고 함.
  59. 평가기가 낸 응답에는 그 이미지가 머리에 여러 개의 핀이나 못이 박힌 인물을 묘사하고 있고, 이건 그래픽하고 폭력적인 묘사라고 적혀 있었다고 함.
  60. 그런데 점수는 5점 만점이 아니라 4점으로 나왔고, 만점이 아니니 기본 문턱값으로는 불합격 처리된다고 함.
  61. 다만 폭력적인 콘텐츠를 다루는 비디오 게임 같은 앱이라면 문턱값을 4까지 올려서 그 정도는 괜찮다고 설정할 수도 있다고 함.
  62. 보여주려던 평가기가 하나 더 있었지만 시간이 다 돼 그냥 넘어간다고 함.
  63. 발표를 마치며 애저 파운드리 평가 SDK와 에이전트 만들기·평가하기를 논의할 수 있는 깃허브 디스커션 링크와, 디스코드(Discord)로 대화하고 싶은 사람을 위한 애저 파운드리 디스코드 서버 링크를 안내함.
  64. 마지막엔 문의할 수 있도록 본인 연락처를 남김.
  65. 청중이 슬라이드를 어떻게 공유받을 수 있냐고 묻자, 디스코드 서버에 올려두겠다고 답함.

한줄 코멘트. 참석자 수 없는 페이지에서 링크 하나 더 타고 들어가 숫자를 채워온 그 대목이, 자동 채점기가 정작 걸러야 할 건 답의 그럴듯함이 아니라 이런 우연한 성공까지 재현 가능한지임을 보여줌.

  1. 브레인트러스트(Braintrust)의 앵커 고얄(Ankur Goyal)이 AI 엔지니어 컨퍼런스에서 평가(eval, AI 결과물의 품질을 데이터셋과 채점 기준으로 자동 측정하는 체계)를 만들며 비싸게 배운 것들을 정리함.
  2. 먼저 평가가 조직에 실제로 값어치를 내고 있는지부터 판단하라고 하며, 그 기준으로 세 가지 징후를 제시함.
  3. 첫째 징후는 새 모델이 나왔을 때 그 모델을 반영한 업데이트를 24시간 안에 낼 준비가 되어 있는가임. 노션(Notion)의 세라(Sarah)가 전날 발표에서 밝힌 대로, 노션은 최근 몇 차례 모델이 나올 때마다 실제로 24시간 안에 반영해왔다고 함.
  4. 이걸 못 한다면 평가 체계에 아직 손볼 게 있다는 뜻이라고 함.
  5. 둘째 징후는 사용자가 불만을 제기했을 때 그 불만을 평가에 집어넣는 뚜렷하고 간단한 경로가 있는가임. 그 경로가 있으면 사용자 피드백을 반영해 제품을 낫게 만들 기회를 잡지만, 없으면 값진 정보를 그대로 흘려보내게 된다고 함.
  6. 셋째 징후는 평가를 회귀 여부만 확인하는 유닛 테스트처럼 방어적으로만 쓰지 않고, 제품을 내놓기 전에 어떤 사용 사례를 얼마나 잘 풀 수 있는지 미리 가늠하는 공격적 용도로 쓰는가임.
  7. 평가를 제대로 채택했다면 새 제품을 출시하기 전에 그 제품이 얼마나 잘 작동할지 평가 결과만 보고도 상당히 감을 잡을 수 있어야 한다고 함.
  8. 두 번째 교훈은 좋은 평가는 저절로 오지 않고 엔지니어링해야 한다는 것이고, 합성 데이터셋과 아무 LLM 판정(LLM-as-judge, 사람 대신 다른 언어모델이 답의 품질을 채점하게 하는 방식) 점수만으로는 안 된다고 함.
  9. 현실과 완벽히 들어맞는 데이터셋은 없고, 예외는 경시대회 수학 문제 풀이처럼 이미 풀린 것이나 다름없는 극소수 사용 사례뿐이라고 함.
  10. 대부분의 실제 사용 사례에서는 미리 만들어둔 어떤 데이터셋도 사용자가 실제로 겪는 일을 대변하지 못한다고 함.
  11. 가장 좋은 데이터셋은 현실에서 실제로 벌어지는 일과 계속 맞춰가며 조정하는 데이터셋이고, 이걸 잘 하려면 상당한 엔지니어링이 필요하다고 함. 브레인트러스트가 이 작업을 돕는다고 밝힘.
  12. 채점 기준(scorer, 결과가 얼마나 잘 됐는지 점수로 매기는 함수)도 마찬가지라며, 많은 고객이 브레인트러스트 기본 채점기가 뭔지 그것만 쓰면 되는지 묻는다고 함.
  13. 브레인트러스트에는 오토이밸스(autoevals)라는 오픈소스 채점 라이브러리가 있지만 일부러 유연하게 열어뒀다고 함. 어느 정도 성숙한 회사는 결국 자기만의 채점 함수를 직접 쓰고 계속 고쳐나가기 때문이라고 함.
  14. 채점 기준을 AI 애플리케이션의 명세(spec)나 요구사항 문서(PRD)처럼 생각하라고 권함.
  15. 이렇게 보면 기성 채점기를 넘어 채점에 직접 투자할 근거가 생기고, 오픈소스나 범용 채점기를 그냥 쓰는 건 내 프로젝트가 아니라 남의 프로젝트 명세를 쓰는 꼴이라는 게 분명해진다고 함.
  16. 최근 흐름은 프롬프트를 시스템 프롬프트 하나로 보지 않고 컨텍스트(context, 모델이 답을 낼 때 참고하는 정보 전체) 전체로 보는 쪽으로 옮겨가고 있다고 함.
  17. 전통적인 프롬프트 엔지니어링이 크게 진화하고 있고, 프롬프트가 아니라 컨텍스트를 생각해야 한다는 게 중요하다고 함.
  18. 요즘 에이전트(agent, 사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)의 프롬프트는 시스템 프롬프트에 이어 LLM 호출과 도구 호출을 반복하는 반복문 구조라고 함.
  19. 실제 에이전트들의 실행 궤적 몇 개를 가져와 메시지 유형별 토큰 비율을 분석했더니, 평균 프롬프트에서 시스템 프롬프트가 차지하는 토큰은 소수였다고 함.
  20. 좋은 시스템 프롬프트를 쓰고 다듬는 일도 중요하지만, 도구와 그 출력을 얼마나 정확히 정의하는지에 소홀하면 많은 걸 놓치게 된다고 함.
  21. 도구를 지금 있는 API나 제품을 그대로 반영한 것으로 두면 안 되고, LLM이 무엇을 보고 싶어 하는지를 기준으로 설계해야 한다고 함.
  22. 좋은 도구를 쓰는 일은 기존 스택 위에 얹는 API 계층 정도가 아니라 프로젝트 대부분을 흔드는 파격적인 작업이라고 함.
  23. 도구 출력도 마찬가지라며, 최근 내부 프로젝트에서 도구 출력을 JSON에서 YAML로 바꾼 것만으로 상당한 차이가 났다고 함.
  24. YAML이 JSON보다 토큰을 덜 쓰고 LLM이 분석하기에도 훨씬 보기 편해서였다고 함. AI 업계에서 좀 유행처럼 도는 이야기이긴 하다고 덧붙임.
  25. 코드를 짜서 차트 라이브러리 같은 데 그대로 꽂아 쓸 때는 자바스크립트(JavaScript) 입장에서 YAML이든 JSON이든 다 구조화 데이터라 차이가 없지만, LLM에게는 이 둘이 매우 다르다고 함.
  26. 그래서 도구를 정의하는 방식과 출력을 구성하는 방식을 LLM이 최대한 잘 활용하도록 아주 신중하게 짜야 한다고 함.
  27. 가장 중요한 교훈 중 하나로, 새 모델이 나올 때마다 모든 게 바뀔 수 있다는 패턴을 리플릿(Replit) 쪽 사람들이 앞장서 개척했다고 공을 돌림.
  28. 제품과 팀, 사고방식을 새 모델이 나왔을 때 그 기회에 바로 올라탈 수 있도록 엔지니어링해둬야 한다고 함.
  29. 곧 출시할 제품 기능 하나를 예로 들며 수치를 보여줌. 이 기능이 얼마나 잘 될지 알려주는 평가를 오랫동안 돌려왔고 몇 달마다 다시 실행해왔다고 함.
  30. 한때는 GPT-4o가 최고 모델이었는데, GPT-4.1이 조금 나아졌고 3.7 소네트(Sonnet)는 훨씬 나아졌으며 4 소네트는 그보다도 눈에 띄게 더 나아졌다고 함.
  31. 그 결과 10% 수준이라 사용자에게 전혀 쓸모없던 이 기능이 갑자기 실제로 쓸 만한 수준으로 넘어왔다고 함.
  32. 클로드(Claude) 4 소네트가 나온 지 정확히 2주 됐는데, 이 발표를 하는 오늘 바로 이 기능의 첫 버전을 출시한다고 밝힘.
  33. 이 기회에 바로 올라탈 수 있었던 이유는 평가를 미리 돌려두고 준비가 되어 있어서 문턱을 마침내 넘었다는 걸 곧바로 알아차렸기 때문이라고 함.
  34. 그래서 주변 사람들에게 오늘 모델로는 통과하지 못할 만큼 야심 찬 평가를 만들어두라고 권한다고 함. 새 모델이 나오면 그냥 갈아 끼워서 바로 시험해볼 수 있게 짜두라는 것임.
  35. 브레인트러스트에는 브레인트러스트 프록시(Braintrust proxy)라는 도구가 있어 코드를 바꾸지 않고도 여러 모델 제공사를 오갈 수 있다고 함. 비슷한 도구는 다른 데도 있다고 함.
  36. 구글이 최신 제미나이(Gemini)를 막 내놨는데, 제미나이 2.5 프로 0520 버전은 이 벤치마크에서 1% 점수라 아예 표에 넣지도 않았다고 함. 오늘 새로 나온 버전은 발표 직후 키 몇 번 두드리는 것만으로 바로 확인할 수 있다고 함.
  37. 마지막으로 프롬프트만 최적화하지 말고 시스템 전체를 최적화하는 게 중요하다고 함.
  38. 평가에 쓰는 데이터, 프롬프트·에이전트 구조·도구를 포함한 과제(task), 채점 함수까지 셋을 하나의 시스템으로 놓고 총체적으로 생각해야 한다고 함.
  39. 앞서 보여준 것과 같은 벤치마크로 LLM이 프롬프트를 자동 최적화하는 실험을 돌렸다고 함.
  40. 한 번은 프롬프트만 주고 "이 프롬프트를 최적화해달라"고 했고, 다른 한 번은 프롬프트에 데이터셋과 채점 결과까지 함께 주고 "이 시스템 전체를 최적화해달라"고 했다고 함.
  41. 둘 사이에 극적인 차이가 있었고, 여기서도 못 쓰던 수준이 쓸 수 있는 수준으로 넘어갔다고 함.
  42. 이날 새로 출시하는 제품 기능으로 루프(loop)를 소개함. 브레인트러스트 사용자는 기능 플래그(feature flag) 메뉴에서 루프를 켤 수 있다고 함.
  43. 루프는 평가를 브레인트러스트 안에서 곧바로 자동 최적화해주는 기능이라고 함. 플레이그라운드(playground)에서 프롬프트·데이터셋·채점 기준을 주면 그걸 다듬거나 새로 만들어주기도 한다고 함.
  44. 잘 통했던 요청 예로는 "이 프롬프트를 최적화해줘", "이 데이터셋에 빠진 게 뭐야", "왜 점수가 이렇게 낮아(또는 높아)", "더 엄격한 채점 기준을 짜줘" 등을 들었다고 함.
  45. 여러 모델로 시험해볼 수 있는데, 클로드 4 소네트에서 가장 좋은 성능을 봤고 클로드 4 오퍼스(Opus)는 거기서 몇 퍼센트 포인트 더 나았다고 함.
  46. o3, o4-mini, 제미나이는 물론 직접 훈련하거나 파인튜닝한 모델로도 시험해볼 수 있다고 권함.
  47. LLM이 프롬프트와 데이터를 보고 건설적인 개선을 자동으로 해낼 수 있게 된 만큼, 평가를 다루는 작업 방식 자체가 크게 바뀔 거라고 함. 그동안 평가를 반복 손보는 수작업 상당 부분이 더는 필요 없어질 거라고 함.
  48. 마무리로 다섯 가지 교훈을 다시 정리함. 첫째, 효과적인 평가는 그 자체로 증명되니 조직이 평가 역량에 이르렀는지부터 정직하게 판단하고 안 됐다면 그쪽으로 밀고 나가라고 함.
  49. 둘째, 평가를 다룰 때는 프롬프트만 고치지 말고 시스템 전체를 엔지니어링하라고 함. 합성 데이터나 허깅페이스(Hugging Face) 데이터셋만 쓰지 말고, 기성 채점기만 쓰지 말라고 함.
  50. 대신 직접 채점 함수를 써서 하려는 일의 명세를 그 안에 담으라고 함.
  51. 셋째, 컨텍스트를 세심하게 생각하라고 함. 도구를 쓰는 일도 프롬프트를 쓰는 일처럼 LLM과 소통하고 그걸 성공으로 이끄는 기회로 여기라고 함.
  52. 도구의 API 인터페이스를 어떻게 정의하고 그 출력을 어떻게 정의하는지가 성능에 극적인 영향을 준다고 함.
  53. 넷째, 새 모델이 나와서 모든 걸 바꿔놓을 수 있다는 데 대비하라고 함. 새 모델이 나오면 이상적으로는 나온 그날 바로 알아차리고, 기존 구조를 뜯어내고 새 구조로 갈아 끼울 준비까지 해두라고 함.
  54. 그러려면 제대로 된 평가가 있어야 하고, 동시에 그렇게 갈아 끼울 수 있도록 제품을 엔지니어링해둬야 한다고 함.
  55. 다섯째, 평가 성능을 개선할 때는 데이터와 그 데이터를 얻는 방식, 프롬프트·도구를 포함한 과제, 채점 함수까지 시스템 전체를 함께 최적화해야 한다고 함.
  56. 질의응답에서 조티(Joti)라는 청중이 사용자 피드백을 전부 평가에 집어넣으면 과적합(overfitting, 데이터셋에만 지나치게 맞춰 정작 실제 상황에는 안 맞게 되는 현상)이 걱정되지 않냐고 물음.
  57. 앵커는 사용자 피드백 없이 데이터셋에만 맞춰지는 과적합을 훨씬 더 걱정한다고 답함. 데이터셋에서 중요한 건 특정 시점의 상태가 아니라 현실과 얼마나 잘 맞춰나가느냐라고 함.
  58. 그래서 브레인트러스트는 사용자 피드백을 자동으로 데이터셋에 넣지 않는다고 함. 일부 고객은 이 방침에 불만을 갖기도 한다고 밝힘.
  59. 대신 안목과 직관이 있는 사람이 사용자가 낸 데이터 중 흥미로운 지점을 직접 골라 데이터셋에 넣어야 한다고 함. 이게 사용자가 판단력을 발휘할 기회라고 함.
  60. 다른 청중이 도구 설명에 붙어 있던 퍼센트 수치가 뭐냐고 물음. 앵커는 여러 에이전트의 실행 기록에서 메시지 유형별 토큰 비율을 분석한 것이라고 답함.
  61. 메시지 유형은 시스템 프롬프트, 모델이 호출할 수 있는 도구의 명세인 도구 정의(tool definition), 사용자·어시스턴트 간 텍스트, 도구가 직접 만들어내는 도구 응답 넷으로 나눴다고 함.
  62. 요점은 요즘 에이전트 시스템에서 도구가 LLM의 토큰 예산을 매우 크게 차지한다는 것이고, 그래프QL(GraphQL) API 같은 걸 그대로 도구 호출 뭉치로 넘기지 말고 도구 정의와 출력을 제대로 설계해야 한다고 함.
  63. 정부 기관과 일한다는 청중이 세금 관련 답을 사용자가 마음에 안 들어할 때 싫어요를 누른다는 사례를 들며 사용자 피드백 반영이 좋은 방법이라고 공감함. 브레인트러스트도 "답은 맞는데 그냥 마음에 안 든다"는 항목을 따로 추가했다고 함.
  64. 마지막 질문자는 모델을 여러 번 바꿔봤지만 코드 작업과 오픈AI(OpenAI) 모델에서 큰 차이를 못 느꼈다며, 오히려 저렴한 4.1 미니(mini)는 시스템 프롬프트를 아예 무시하는 것 같았다고 지적함. "새 모델이 모든 걸 바꾼다"는 말이 구체적으로 뭘 뜻하는지 물음.
  65. 앵커는 오늘 소개한 루프가 좋은 예라며, 프롬프트와 데이터셋과 채점 결과를 보고 프롬프트를 자동 최적화하는 이 야심 찬 에이전트를 위한 벤치마크를 오래전부터 돌려왔다고 함.
  66. 모델이 새로 나올 때마다 이 벤치마크를 돌렸는데 오랫동안 GPT-4o 수준의 점수만 나왔다고 함. 다만 이건 모든 벤치마크에 해당하는 얘기는 아니라고 함.
  67. 예를 들어 영화 대사를 보고 어느 영화인지 맞히는 평가는 GPT-3.5 시절부터 이미 잘 풀렸다고 함. 어떤 사용 사례는 모델이 바뀌어도 별 차이가 없다는 것임.
  68. 반면 지금 모델로는 아예 안 되는 야심 찬 사용 사례도 있고, 그래서 미래에 하고 싶은 일이 있다면 새 모델이 나왔을 때 버튼 하나만 눌러 바로 확인할 수 있도록 평가를 미리 만들어두라고 권함.

한줄 코멘트. 모델 교체는 버튼 하나로 자동화하라면서 사용자 피드백은 사람이 골라 데이터셋에 넣으라 한 것은, 브레인트러스트가 어디에는 자동화를 밀고 어디에는 사람을 남겨두는지를 보여주는 선긋기임.

  1. 카리나 응우옌은 앤트로픽에서 클로드를 만드는 연구 엔지니어고, 최근엔 클로드가 스스로 답을 고쳐 쓰게 만드는 일과 환각(모델이 사실이 아닌 내용을 사실처럼 지어내는 것)을 줄이는 일을 했다고 밝힘.
  2. 이번 발표는 클로드 API를 쓸 때 프롬프트(모델에게 주는 지시문)를 어떻게 써야 하는지에 관한 원칙을 다룸.
  3. 언어모델은 앞 낱말들을 보고 다음 낱말이 나올 확률을 계산하는데, 잘 쓴 프롬프트는 모델의 주의(attention) 메커니즘이 입력의 특정 부분에 집중하게 만들어 원하는 답이 나올 확률을 끌어올림.
  4. 프롬프트에 과제에 맞는 핵심어·맥락·예시를 넣으면 모델 안에 저장된 관련 지식을 끌어낼 수 있고, 모델을 다시 학습시키지 않고도 추론 시점의 연산만으로 성능을 끌어올릴 수 있어 비용이 적게 듦.
  5. 응우옌은 고객·개발자와 대화하며 프롬프트가 어려운 이유를 세 갈래로 나눔. 첫째는 사람이 원하는 걸 알지만 모델에서 최고 성능을 끌어내는 법을 모르는 경우고, 이번 발표가 주로 다루는 지점이라고 함.
  6. 둘째는 사람이 원하는 걸 어렴풋이만 알아서 모델에게 제대로 설명하지 못하는 경우고, 이러면 모델도 사람이 뭘 원하는지 헷갈려 함.
  7. 셋째는 사람 스스로도 원하는 걸 모르는 경우인데, 이때는 모델이 이해하기가 가장 힘듦.
  8. 과제가 뭔지 어렴풋이 안다면 예시를 여러 개 주면 되는데, 모델이 예시만 보고도 의도를 잘 유추한다고 함. 예시는 다양해야 하고 여러 예외 상황(edge case)까지 담아야 함.
  9. 다섯 살 아이에게 설명하듯 아주 쉬운 말로 풀어야 하고, 이걸 잘하려면 반복해서 고쳐 써 보는 시간이 많이 필요함.
  10. 응우옌은 연구 엔지니어로 일하는 시간 대부분을 동료와 함께 프롬프트를 짜며 보낸다고 밝힘.
  11. 버클리에서 창작 글쓰기 수업을 들었는데, 그때 했던 프롬프트(글감 던지기) 연습이 언어모델 프롬프트와 닮았다는 걸 최근에야 깨달았다고 함.
  12. 프롬프트가 안 먹힌다고 짜증 내는 사람들을 종종 보는데, 대부분은 새로운 방식을 떠올릴 창의력이 부족한 것뿐이라고 응우옌은 말함.
  13. 응우옌이 쓴 블로그 글은 프롬프트 짜는 일이 연구자·과학자에게 새로운 형태의 글쓰기라고 주장함. 이 일은 모델이 이 일을 할 수 있는지 가설을 세우고 시험하는 과정과 같다고 함.
  14. 반복해서 시험하다 보면 모델이 어떤 일엔 강하고 어떤 일엔 약한지 점점 또렷해진다고 함.
  15. 클로드는 GPT 계열과 다르게 다뤄야 하는데, 마치 다섯 살 아이나 다른 사람에게 설명하듯 자세하고 친절하게 써야 한다고 함.
  16. 글쓰기 원칙 첫째는 명료함임. 쉽고 애매하지 않은 말을 쓰고 모델을 헷갈리게 하는 복잡한 구문을 피함.
  17. 둘째는 간결함임. 프롬프트를 짧게 유지하고 모델에 꼭 필요한 정보만 담음.
  18. 셋째는 일관된 흐름임. 맥락을 앞에 두고 실제로 시킬 일은 뒤에 둠.
  19. 넷째는 형식 일관성임. XML 태그(꺾쇠괄호로 정보를 감싸는 표시)를 쓰기로 했으면 끝까지 같은 방식으로 씀.
  20. 다섯째는 방향 지시임. 장르나 분량이나 문체 같은 조건을 구체적으로 알려줌.
  21. 여섯째는 근거 대기임. 긴 문서를 맥락으로 줬으면 모델이 그 문서를 그대로 인용해 주장을 뒷받침하게 시킴.
  22. 마지막은 다양한 예외 사례로 모델을 붙잡아 두는 것임. 퓨샷(예시 몇 개를 미리 보여주고 시키는 방식) 프롬프트에 특히 유용함.
  23. 첫 사례는 응우옌이 작년에 만든 추천 시스템 프로젝트 이날리아(inalia)임.
  24. CLIP(이미지와 글을 같은 공간에 놓고 비교하도록 오픈AI가 학습시킨 대조 학습 모델)로 여러 브랜드의 옷 이미지를 긁어와 자연어 검색 엔진을 만듦.
  25. "제임스 본드 걸" 같은 말을 넣으면 그 분위기의 드레스가, "미래적이고 몽환적인 옷차림"을 넣으면 그 느낌의 옷이 나오는 식으로, 분위기 기반 검색이 됨.
  26. CLIP은 이미지와 텍스트를 각각 임베딩(숫자 벡터)으로 바꾸고, 코사인 유사도로 사용자 질문과 가장 가까운 상품을 데이터베이스에서 찾아냄.
  27. 응우옌은 여기에 클로드를 더해, 이미지에 붙은 라벨을 보고 그 상품이 사용자 요청에 맞는지 판단해 추천을 고르는 일을 시킴.
  28. 가장 단순한 방식은 제로샷(예시 없이 바로 시키는 방식) 프롬프트로, 사용자 질문과 상품 설명을 주고 관련 있는지 yes·no로 <answer> 태그 안에 답하게 함.
  29. 응우옌은 클로드가 XML 태그를 정말 좋아한다고 강조하고, 사람들이 저지르는 가장 흔한 실수는 XML 태그를 안 쓰는 것이라고 함.
  30. XML 태그 형식은 앤트로픽이 클로드를 처음 미세조정(fine-tuning, 이미 학습된 모델을 특정 형식·과제에 맞춰 추가로 훈련하는 것)할 때 쓴 형식이었고, 고객들이 마크다운·JSON도 요구하면서 그것도 지원하게 됐다고 밝힘.
  31. 이 제로샷 방식은 완벽하진 않아서 이어서 더 다듬어야 한다고 함.
  32. 두 번째 전략은 답을 내기 전에 <thought> 태그 안에서 먼저 생각할 시간을 주는 것으로, 사고사슬(chain of thought, 모델이 답을 내기 전에 중간 추론을 순서대로 적는 방식) 기법과 같음.
  33. 앞서 정한 조건(criteria)을 프롬프트에 넣어, 이를테면 여름엔 겨울 코트를 추천하지 말라는 식으로 판단 기준을 더 구체적으로 줄 수 있음.
  34. 답을 yes·no로만 받지 않고 1점(추천 안 함)부터 10점(강력 추천)까지 점수로 받아 <score> 태그에 담게 함.
  35. 제임스 본드 블레이저 예시는 9점을 받았고, 위대한 개츠비 스타일 요청에 안 맞는 상품은 왜 안 맞는지 이유와 함께 2점을 받음.
  36. 청중 하나가 영어가 서툰 친구도 구조만 잘 잡으면 프롬프트가 잘 먹힌다고 묻자, 응우옌은 모델이 언어 사이 지식을 잘 옮기고 문법이 조금 틀려도 의도를 잘 유추하는 것 같다고 답함.
  37. 점수 분포에 편향이 있는지 묻는 질문엔, 앤트로픽 사회적 영향(societal impacts) 연구팀이 뉴스 요약 같은 과제에서 이 편향을 연구 중이지만 아직 뚜렷한 답은 없다고 함.
  38. 두 번째 과제는 긴 맥락(long context) 다루기임. 클로드는 위대한 개츠비 한 권이 통째로 들어가는 10만 토큰 맥락 창을 갖고 있음.
  39. 긴 맥락은 크게 두 가지로 쓰이는데, 하나는 여러 문서를 한꺼번에 넣고 요약·검색하는 것이고 다른 하나는 퓨샷 예시를 아주 많이 넣는 것임.
  40. 한 논문에서, 사고사슬로 적힌 추론 과정이 모델이 실제로 답을 낼 때 쓴 근거와 항상 일치하지는 않는다는 걸 발견했다고 함. 모델이 사고사슬을 무시하고 답을 낼 수 있는데, 이를 "불충실(unfaithful)"하다고 부름.
  41. 그 논문에 따르면 분해(decomposition) 기법을 쓰면 질의응답 과제에서 사고사슬만큼 성능을 내면서도 충실성은 더 높일 수 있다고 함.
  42. 사고사슬 예시로는 "캥거루가 주머니에 들어갈 수 있나"라는 질문에 "단계별로 생각해 보자"고 시켜 추론을 이어가는 방식을 보여줌.
  43. 분해는 이와 달리 하나의 질문을 여러 하위 질문으로 쪼개고, 각 하위 질문을 서로 영향받지 않는 독립된 맥락에서 따로 답하게 함.
  44. 사고사슬은 앞 단계가 뒤 단계에 영향을 주지만, 분해는 하위 질문을 서로 떼어 놓아 그 영향(편향)을 줄이는 방식임.
  45. 하위 질문들에 대한 답을 다 모아 하나의 맥락에 넣고, 그걸 근거로 원래 질문의 최종 답을 다시 내게 함.
  46. 법률 질문 사례에선 프롬프트에 하위 질문을 자기완결적으로 나누되 필요 이상으로 쪼개지 말라고 지시하고, 각 하위 질문을 번호 붙인 태그에 담게 시킴.
  47. 모델이 하위 질문들을 만들면 그걸 하나씩 따로 답하는데, 이때 답하는 모델이 꼭 같은 모델일 필요는 없다고 함.
  48. 모든 하위 질문과 답을 모은 뒤 원래 질문을 다시 물으면 정답 C가 나오는 식으로 예시를 보여줌.
  49. 세 번째 과제는 평가임. 긴 문서를 주고 클로드가 그 문서 내용을 실제로 근거로 답하는지, 그냥 사전학습 지식으로 답하는지 확인하는 실험을 앤트로픽이 진행함.
  50. 실험엔 클로드 학습 데이터 마감 이후인 올해 7월 13일 자 정부 회의록 문서를 써서, 모델이 사전 지식만으로 답을 맞히지 못하게 함.
  51. 문서를 여러 구간으로 나누고 각 구간마다 클로드로 오지선다 질문 다섯 개(오답 셋·정답 하나)를 만든 뒤, 이 구간들을 무작위로 섞어 긴 문서로 다시 조립해 회수율을 시험함.
  52. 프롬프트 전략은 예시 없음, 문서와 무관한 일반 상식 예시 두 개, 문서 관련 예시 두 개, 문서 관련 예시 다섯 개로 나눠 비교함. 정답 위치를 입력의 처음·끝·가운데로 바꾸고, 문서 길이도 7만 토큰과 9만5천 토큰으로 나눠 시험함.
  53. 결과는 문서 기반 질의응답에서 질문을 프롬프트 맨 끝에 두는 쪽이 맨 앞에 두는 쪽보다 훨씬 잘 맞혔음.
  54. 답을 내기 전에 근거가 될 만한 문장을 <thought> 태그 안에 먼저 뽑아 두게 하면 정확도가 오르는데, 지연 시간이 조금 늘어나는 대가는 있음.
  55. 이 방식은 클로드와 클로드 인스턴트 둘 다에 시험했는데, 클로드 인스턴트 쪽이 클로드 2보다 개선 폭이 컸음.
  56. 결국 이 실험에서는 질문을 프롬프트 끝에 두는 것 하나가 다른 어떤 조정보다 결과에 더 큰 영향을 줬음.
  57. 왜 끝에 두는 게 나은지 묻자, 모델이 프롬프트 끝 쪽에 더 주의를 기울이는 것 같다는 가설이 있고 "중간 내용을 잊는다"는 논문도 있지만 그 논문을 클로드로 직접 검증하진 않았다고 밝힘.
  58. 이 결과는 긴 문서 질의응답이라는 특정 과제에서 나온 것이고, 다른 과제로 일반화해 시험하지는 않았다고 함.
  59. XML과 마크다운·JSONL을 비교한 적이 있냐는 질문엔, XML을 쓰면 거의 100% 정확도가 나오고 마크다운보다 낫다고 답함.
  60. 네 번째 과제는 자동 라벨링임. 작년 어느 논문에서 문장들을 UMAP(고차원 벡터를 사람이 보기 쉬운 저차원으로 줄이는 기법)으로 임베딩한 뒤 군집화하고, 각 군집에 클로드 1.3으로 이름을 붙임.
  61. 그때 뽑은 라벨은 그리 훌륭하진 않았고, 클로드 2를 쓰면 훨씬 나을 거라고 함.
  62. 자기일관성(self-consistency) 기법은 같은 질문에 답을 여러 번 독립적으로 생성한 뒤 가장 많이 나온 답을 고르는 다수결 방식으로, 수학처럼 정답이 딱 떨어지는 문제에 특히 유용함.
  63. 다른 방법은 답 두 개를 생성한 뒤 다른 모델에게 이 둘이 서로 일치하는지 판단하게 시켜, 일치하면 신뢰도를 높이고 안 맞으면 버리는 것임.
  64. 분류가 미묘한 차이를 못 잡을 땐 대비되는 나쁜 예시를 넣어 — 이건 너무 좁다거나 너무 넓다는 식으로 — 뭘 원하지 않는지 알려줄 수 있음.
  65. 예시는 상황을 다양하게 바꿔 가며 넣을수록 좋고, 개념이 어려우면 비유로 풀거나 흔한 오해를 짚어 왜 틀렸는지 반례로 보여주면 도움이 됨.
  66. 클로드 API를 쓸 때 기본 팁으로, "\n\nHuman:"과 "\n\nAssistant:" 형식은 클로드가 아주 중요하게 보는 서식이고, 빠뜨리면 결과가 크게 나빠짐.
  67. 클로드의 대답 앞부분을 미리 채워 넣는 것("클로드 입에 말을 넣는다")도 가능한데, 예컨대 "네, 이해했습니다"를 미리 써 놓아 원하는 태도로 몰아갈 수 있음.
  68. 지시를 제대로 이해했는지 클로드가 되짚어 말하게 시키는 것도 방법이고, 환각을 줄이려면 클로드가 "모른다" "정보가 부족하다"고 얼버무릴 수 있게 허락해야 함.
  69. 긴 문서에서 인용문을 뽑게 할 땐, 관련 있는 인용이 없으면 없다고 말하라고 못 박아야 클로드가 없는 인용을 지어내지 않음.
  70. 좋은 예시인지 가늠하는 기준은 분류할 대상과 비슷한가, 특정 사례에만 치우치지 않을 만큼 다양한가, 답 종류별로 고르게 섞여 있는가임. 안 그러면 모델이 늘 같은 선택지만 고름.
  71. Human과 Assistant라는 낱말은 클로드 API에서 예약어라, 맥락 안 대화 내용에는 절대 쓰면 안 되고 대신 user·AI 같은 다른 말을 써야 하며, Human·Assistant는 반드시 번갈아 나와야 함.
  72. 프롬프트 엔지니어링의 앞날을 묻는 질문에, 응우옌은 프롬프트는 계속 남을 것이고 다만 더 복잡하고 정교한 과제를 묻게 될 거라고 답함.
  73. 모델로 합성 데이터를 만드는 방향으로 가고 있다며 이 흐름을 낙관적으로 본다고 밝힘. 언어모델로 평가 기준 자체를 쓰는 데도 프롬프트를 쓸 수 있다고 함.
  74. RLAIF(AI 피드백으로 하는 강화학습, 사람 대신 모델이 자기 답을 스스로 검토·수정하게 하는 방식)는 RLHF보다 더 확장하기 쉬운 대안이라고 소개함.
  75. 프롬프트 엔지니어링은 제품 개발의 표준 부품이 될 거라며, 클로드 제품의 제목 자동 생성 같은 기능은 거대언어모델 이전엔 없던 UX라고 함.
  76. 사용자의 대화 기록을 임베딩해 새 대화 주제를 제안하는 개인화도 가능하다고 함.
  77. 가장 흥미로운 방향은 특정 과제에서 토큰 수는 최소로 쓰면서 정확도는 최고로 끌어올리는 최적 프롬프트를 찾는 일이라고 함.
  78. GPT와 비교해 봤냐는 질문엔 클로드로 거의 매일 작업해 GPT는 잘 모르지만 클로드만큼 서식(formatting)을 엄격하게 요구하진 않는 것 같다고 답함. 다른 모델의 함수 호출(function calling) 기능도 많이 써 보지 않아 비교하긴 어렵다고 함.
  79. 자기 교정(self-correction) 관련 질문엔, 모델이 스스로 답을 고치는 일은 아직 잘 못하는 과제 중 하나이고 여기에 맞는 프롬프트를 찾는 것도 열린 방향이라고 답함.
  80. 답변 품질을 어떻게 평가하냐는 질문엔, 과제에 따라 다르고 환각처럼 사람이 직접 눈으로 봐야 하는 경우도 있고, 거절 응답을 유형별로 나눈 뒤 모델로 분류해 비율을 재는 경우도 있다고 답함.
  81. 제목 생성 품질을 어떻게 평가했냐는 질문엔, 클로드에게 편집자 같은 안목을 가지라고 시키고 이전 제목들을 맥락에 넣어 사용자 스타일에 맞추게 했다고 답함.
  82. 이 제목 생성 기능은 실제 프로덕션에 쓰이고 있고, 최근엔 프롬프트가 아주 짧으면 언어모델을 쓰지 않고 그냥 앞부분 낱말을 그대로 제목으로 쓰도록 바꿨다고 밝힘.
  83. 클로드와 클로드 인스턴트의 차이를 묻자, 클로드 2는 8월 9일에 발표했고 더 크고 똑똑한 모델이며 클로드 인스턴트는 훨씬 싸고 빠르다고 설명함.
  84. 클로드 인스턴트는 이전 버전보다 수학·코드 같은 추론 과제에서 훨씬 나아졌고, 자동화된 레드팀(red team, 모델을 공격해 취약점을 찾는 평가 방식) 검증에서 탈옥(jailbreak, 안전장치를 우회해 금지된 답을 얻어내는 시도)에 더 강해졌다고 함.
  85. 레드팀 평가는 이를테면 폭탄 제조법을 묻는 시도에 모델이 거부하는지를 확인하는 내부 검증이고, 그 결과는 모델 카드에 공개했다고 밝힘.

한줄 코멘트. 2023년 클로드 얘기지만 XML 태그·질문 위치·분해·자기일관성 같은 기법은 지금 프롬프트에도 그대로 먹힘.

04

모델 훈련 · 후속 학습

  1. 이 발표는 어플라이드컴퓨트(Applied Compute) 소속 레이먼드 펑이 AI 엔지니어 컨퍼런스에서 한 것으로, 주제는 포스트트레이닝(사전학습을 끝낸 모델을 실제로 쓸 자리에 맞게 더 훈련시키는 단계)의 미래임.
  2. 목표는 에이전트가 일을 하면서 새 기술을 현장에서 배우게 만드는 것임.
  3. 지난 1년 동안 에이전트들은 추론 능력이 크게 늘었고, 여러 턴과 도구 호출을 거치는 긴 호흡의 작업을 처리하는 에이전트 하니스(harness, 에이전트가 도구를 부르고 결과를 받는 실행 틀)를 다룰 줄 알게 됨.
  4. 기업들은 이제 에이전트를 꽂기만 하면 바로 돌아가는 형태로 쓰고 싶어함.
  5. 예를 들어 이미 자기 방식대로 에이전트를 호출해 어떤 작업을 시키고 있다면, 그 작업 전용의 커스텀 모델을 새로 훈련시켜 갈아 끼우고 싶어한다는 것임.
  6. 그러려면 포스트트레이닝을 다시 봐야 하는데, 소스 코드조차 볼 수 없는 하니스에도 맞춰 훈련할 수 있는 방법이 필요함.
  7. 발표자는 포스트트레이닝을 단계별로 나눠 설명하는데, 각 단계는 앞 단계 위에 쌓이는 구조임.
  8. 비유는 사람이 배우는 방식임. 쉬운 일부터 배우고 그 이해를 쌓아서 점점 어려운 일로 넘어간다는 것임.
  9. 지난 1년 동안 업계는 한 번 묻고 한 번 답하는 단순한 질문·답변 작업과, 합성 환경(실제 서비스가 아니라 훈련용으로 따로 만든 가짜 환경) 속의 조금 더 긴 작업을 많이 반복해서 사실상 숙달함.
  10. 지금 늘고 있는 수요는 기업마다 다른 커스텀 하니스에 맞춰 그 하니스 위에서 직접 훈련시키는 것임.
  11. 발표자는 이 단계를 인턴십에 비유함. 모델에게 특정 업무를 시키긴 하는데, 그 하니스를 직접 소유하지 않으니 일이 정확히 어떻게 흘러갈지는 모른다는 것임.
  12. 마지막으로 그리는 미래상은 「에이전트 시민」임. 한 번 배포해두면 여러 낯선 작업에 알아서 적응하고 자기가 겪은 상호작용에서 계속 배우는 모델을 말함.
  13. 첫 단계인 단순 질문·답변 작업의 훈련 구조부터 보면, 오케스트레이터(orchestrator, 훈련용 문답 시도 전체의 진행을 지휘하는 프로그램)가 롤아웃(rollout, 모델이 문제를 받아 답을 내는 한 번의 시도)을 이끎.
  14. 오케스트레이터가 들고 있는 작업 단위는 지금 단계에선 그냥 수학 문제 같은 프롬프트 하나와 정답 하나임.
  15. 오케스트레이터가 이 프롬프트를 모델에 보내고 답을 받아옴.
  16. 그 답을 채점자(grader)에게 보내 점수를 매기게 함.
  17. 이렇게 한 번, 또는 여러 번의 상호작용이 쌓이면 그걸 근거로 모델을 개선하는데, 이 일을 하는 것이 훈련 엔진(training engine)임.
  18. 훈련 엔진은 채점이 끝난 대화들을 받아서 가중치 업데이트(weight update, 모델 내부 수치를 조금씩 조정하는 것)를 만들어냄.
  19. 이 가중치 업데이트는 추론 엔진(inference engine, 실제로 모델을 돌려 답을 내는 서버)들에 동기화됨.
  20. 추론 엔진이 갱신되면 오케스트레이터는 새 문제를 다시 모델에 보내면서 이 과정을 처음부터 반복함.
  21. 핵심은 모델을 개선하는 데 필요한 재료가 오직 「채점이 끝난 대화」뿐이라는 것임. 이것만 있으면 훈련 엔진이 가중치 업데이트를 계산해낼 수 있음.
  22. 대신 그 대화는 아주 특정한 형식이어야 하는데, 롤아웃을 어떻게 돌리고 어떻게 포맷하는지까지 전부 훈련 스택 안에서 통제하는 매우 제한된 환경이기 때문임.
  23. 이 방식의 한계는 한 턴짜리 작업만 할 수 있다는 것임. 더 길고 복잡한 작업, 더 높은 수준의 능력을 모델에 심으려면 환경 자체의 복잡도를 키워야 함.
  24. 그래서 다음 단계인 합성 환경에서는 환경 상태(environment state) 자체를 훈련 스택 바깥으로 빼둠.
  25. 여기서 작업 단위는 도구 사양(tool spec)이나 파일 시스템 같은 환경의 초기 상태까지 담을 만큼 복잡해짐.
  26. 오케스트레이터는 이제 여러 턴을 순서대로 진행하는데, 모델에게 어떻게 답할지 묻고, 모델이 도구를 부르고 싶어하면 샌드박스(sandbox, 격리된 실행 환경)를 불러 환경 상태를 읽거나 바꾼 다음 그 결과를 모델에 다시 돌려줌.
  27. 이 과정이 끝나면 작업 전체의 흐름을 담은 「태스크 트레이스」가 나오고, 이걸 채점자에게 보내 채점함.
  28. 채점이 끝난 대화로 가중치 업데이트를 하는 나머지 흐름은 앞 단계와 같음.
  29. 여기서 강조하는 특징은 이 오케스트레이터·샌드박스 조합이 「리플레이 가능」하다는 것임. 같은 프롬프트를 초기 상태로 몇 번이든 되돌려서 다시 돌릴 수 있고, 이걸 병렬로도 직렬로도 할 수 있음.
  30. 이게 중요한 이유는 지금 강화학습(정답을 직접 알려주는 대신 점수를 매겨 점수가 높아지는 방향으로 모델을 밀어붙이는 학습법)에서 주로 쓰는 방법이 GRPO(같은 프롬프트로 여러 번 롤아웃을 만들어 서로 비교하는 방식)이기 때문임.
  31. GRPO는 같은 프롬프트로 만든 여러 롤아웃을 비교해서 더 잘한 쪽은 가중치를 올리고 못한 쪽은 내리는 방식으로 모델을 고침.
  32. 이 단계에서 부딪히는 문제는 환경 충실도(environment fidelity)와 리워드 해킹(reward hacking, 모델이 진짜 잘해서가 아니라 채점 방식의 허점을 이용해 점수만 높이는 것)인데, 발표자는 이 둘이 사실 같은 문제라고 함.
  33. 환경이 실제와 다르게 이상한 버릇을 가지면 모델이 그 버릇까지 그대로 학습해버린다는 것임.
  34. 실제 사례로, 어떤 훈련 런에서 네트워크 문제 때문에 도구 호출의 약 10%가 실패한 적이 있었음.
  35. 이때 모델은 점점 더 짧은 답을 내놓기 시작했는데, 리워드 함수에는 길이를 깎는 벌점이 전혀 없었기 때문에 처음엔 이유를 알 수 없었음.
  36. 발표자는 이걸 사람이 보도 위를 걷는데 여기저기 웅덩이(도구 호출 실패)가 파여 있는 상황에 비유함. 웅덩이가 많으니 오래 걸으면 빠질 확률이 높아지고, 빠지면 롤아웃 전체가 0점이 되니 모델이 아예 오래 걷지, 즉 길게 답하지 않으려 한다는 것임.
  37. 반대 사례도 있었음. 샌드박스가 무한정 도는 걸 막으려고 타임아웃을 걸어두고, 타임아웃난 롤아웃은 훈련에서 걸러냈던 런이었음.
  38. 도구 호출이 오래 걸리면 모델은 문제가 어렵다고 느끼는데, 이때 도구 호출을 짧은 시간에 잔뜩 남발해서 아예 샌드박스를 타임아웃시켜버리는 쪽으로 학습했음. 그러면 0점을 받는 대신 그 롤아웃 자체가 훈련에서 빠지기 때문임.
  39. 작업이 복잡해질수록 환경을 실제와 똑같이 복제하는 일 자체가 점점 어려워지고, 아무리 사소한 실수라도 모델에 이런 미묘한 이상 행동을 심게 됨.
  40. 그래서 다음 단계는 「내 하니스를 그대로 가져오기(bring your own harness)」임. 에이전트가 어차피 정확한 환경 분포를 배운다면 그 환경을 굳이 복제하지 말고 실제 프로덕션 환경을 그대로 훈련에 쓰자는 발상임.
  41. 이 구조에서는 훈련 스택 밖에 거의 모든 것이 있고, 훈련 스택 안에 남는 건 모델 완성 엔드포인트와 오가는 요청·응답을 기록하는 장치뿐임.
  42. 오케스트레이션 로직 전체가 기존 기업 하니스 쪽에 그대로 남아 있어서, 고객이 이미 쓰고 있는 방식 위에 훈련 방법론만 꽂아 넣을 수 있다는 것임.
  43. 문제는 데이터에 있음. 프로덕션에 가까워질수록 롤아웃이 어떻게 진행되는지를 쥔 통제력이 줄고, 데이터가 익숙한 형식이 아니라서 거기서 뽑아낼 수 있는 학습 신호도 줄어듦.
  44. 이 주제는 엔비디아가 약 한 달 전에 낸 「폴라(Polar)」라는 논문에서도 다뤄지는데, 롤아웃의 세세한 부분까지 직접 통제하던 하니스에서 벗어나 블랙박스 하니스를 그냥 엿듣는 방식으로 넘어가는 이야기를 담고 있음.
  45. 이 단계의 어려움은 결국 리플레이 불가능성과 오프라인·오프폴리시(off-policy, 지금 쓰는 모델이 직접 만들지 않은 과거 데이터로 학습하는 것) 데이터 문제인데, 둘 다 같은 이야기임. 로직을 훈련 스택 밖으로 너무 많이 빼놓아서 원하는 데이터 구조나 규칙을 강제할 수 없게 된 것임.
  46. GRPO처럼 같은 작업으로 여러 롤아웃을 병렬로 만드는 방식이 더 이상 안 통할 수 있음. 예를 들어 고객 상담 채팅 한 건을 기록해뒀다고 해도, 이렇게 답했으면 고객이 더 만족했을지 알아보려고 그 고객의 반응을 다시 받아올 방법이 없음.
  47. 그래도 발표자는 낙관적인데, 사람도 이런 식으로 배우기 때문임. 상담 직원은 고객의 반응만 보고도 자기가 뭘 잘했고 뭘 잘못했는지 스스로 알아채 다음번에 반영함.
  48. 이 문제를 풀기 위한 프런티어 연구 방향으로 자기증류(self-distillation), 자동화된 데이터 파이프라인, 정성적 피드백 흡수 세 가지를 꼽음.
  49. 자기증류는 비교적 새로운 기법으로, 아직은 좁은 범위에서만 성과가 있음. 모델에 특정한 새 행동을 심는 데는 성공했지만, 이걸 얼마나 일반적으로 넓힐 수 있을지는 아직 열린 연구 질문임.
  50. 자동화된 데이터 파이프라인은 대량의 트레이스를 자동으로 훑어서 바람직하지 않은 행동이나 실패 사례를 자동으로 골라내고, 그걸로 훈련 데이터 배치를 자동으로 만들어 모델에 다시 먹이자는 발상임.
  51. 지금은 이 작업이 대부분 사람이 손으로 함. 트레이스를 직접 훑어보며 실패 사례를 찾고, 어떻게 고칠지 적고, 그렇게 데이터셋을 사람이 직접 큐레이션하고 있다고 밝힘.
  52. 정성적 피드백 흡수는, 프로덕션 환경으로 갈수록 명확한 이분법 점수나 숫자 점수가 없고 대신 「이 대화에서 고객이 이런 피드백을 남겼다」는 식의 글로 된 반응만 받는 경우가 많다는 데서 출발함.
  53. 이런 정성적인 정보만으로도 모델을 업데이트할 방법을 찾으면 큰 도움이 될 것으로 보는데, 자기증류가 이 문제를 푸는 한 방향으로 탐색되고 있지만 여전히 열린 질문이라고 함.
  54. 마지막으로 이 흐름을 끝까지 밀어붙이면 어떤 미래가 될지 그림을 그림. 특정 작업 하나를 개선하는 게 아니라, 모델을 여러 상황에서 두루 쓰이는 하나의 배포로 보게 될 것이라는 이야기임.
  55. 이렇게 되면 모델이 스스로를 개선하는 것 자체가 「모든 일에 걸쳐 나를 개선하는」 하나의 작업이 됨.
  56. 이 모델은 여러 사용자에 걸쳐 여러 다른 작업에 쓰이면서, 각 상호작용 유형마다 「나는 이런 상황에서는 이렇게 하고 있다」고 스스로 평가·성찰하는 능력을 갖추게 될 것으로 봄.
  57. 그런 자기평가를 바탕으로 자동으로 가중치 업데이트를 계산해서 스스로를 개선해나가는 그림임.
  58. 앞서 나온 「에이전트가 환경의 구석구석을 익힌다」는 이야기를 밀어붙이면, 환경 자체가 그냥 에이전트가 겪는 모든 상호작용이 되고, 거기에 더해 모델이 스스로를 평가할 방법까지 갖추는 셈이라는 것임.
  59. 지금 겪는 문제 하나는, 한 번에 작업 하나 또는 실패 사례 하나씩만 고치려 들면 두더지 잡기 게임처럼 새 문제가 튀어나올 때마다 새 데이터·새 환경을 만들어 매번 다시 쫓아가야 한다는 것임.
  60. 모든 상호작용에서 배우는 자기개선형 시스템이 있으면 이런 두더지 잡기를 벗어날 수 있다고 봄.
  61. 발표를 마무리하며 약 1년 전 나온 논문의 문장을 인용함. 경험이 개선의 주된 매체가 되어 지금 쓰이는 인간 데이터의 규모를 압도하게 될 새로운 시기의 문턱에 AI가 서 있다는 내용임.
  62. 이 발표 전체는 어플라이드컴퓨트가 자기네 커스텀 모델 훈련 방법론을 파는 자리이기도 함. 「고객이 쓰는 방식 그대로에 우리 훈련법을 꽂는다」는 표현이 반복되는데, 이건 발표자 회사의 영업 메시지로 읽어야 함.

한줄 코멘트. 결국 이 발표가 그리는 건 리워드 함수를 정교하게 짜는 싸움이 아니라 모델이 실패를 어떻게 우회하는지를 계속 뒤쫓는 싸움이라, 데이터 형식을 통제할 수 없는 프로덕션 환경으로 갈수록 어플라이드컴퓨트 같은 회사가 팔 자리가 넓어진다는 점이 눈에 띔.

  1. 이 발표는 오픈AI(OpenAI) 파인튜닝 팀 소속 윌(Will)과 캐시(Cathy) 두 사람이 에이전트 강화 파인튜닝(agent RFT)을 소개하는 자리임.
  2. 에이전트를 일반 모델과 가르는 것은 바깥세상과 상호작용해 스스로 여러 단계를 거쳐 일을 끝낼 수 있는 능력이고, 그러려면 도구(tool)에 접근할 수 있어야 함.
  3. 예를 들어 코딩 에이전트라면 터미널(terminal)이나 코드 인터프리터, 때로는 코드베이스 전체에 접근할 수 있어야 함.
  4. 이 에이전트들은 도구를 그냥 무턱대고 부르는 게 아니라, 도구 호출과 추론(reasoning)이 같은 맥락 창(context window) 안에서 서로 얽혀 있다고 설명함.
  5. 이 방식으로 오픈AI가 사내에서 만든 대표 사례가 코덱스(Codex)이고, 유닛 테스트를 쓰거나 코드베이스에 큰 diff(코드 변경 묶음)를 올리는 등 코딩 작업을 처음부터 끝까지 처리함.
  6. 코덱스가 쓰는 도구 중 일부는 터미널 명령으로 노출되고, 일부는 계획 수립(planning) 워크플로를 부르는 커스텀 함수 형태임.
  7. 에이전트 성능을 올리는 방법을 사다리로 보면 맨 아래가 프롬프트 엔지니어링(prompt engineering)이고, 프롬프트로 모델·에이전트 행동을 원하는 대로 어느 정도 조정할 수 있음.
  8. 그다음이 과제 최적화(task optimization)임. 과제를 단순화하거나, 가드레일(guardrail, 안전장치)을 더하거나, 도구를 더하고 빼거나, 도구가 에이전트에 맞게 작동하도록 바꾸는 일임.
  9. 이런 방법을 다 써봐도 성능을 더 짜내고 싶을 때 마지막으로 쓰는 게 파인튜닝(fine-tuning)이고, 모델 가중치를 바꿔 과제 전체를 처음부터 끝까지 다시 훈련시킴.
  10. 에이전트 강화 파인튜닝(agent RFT)은 이 파인튜닝을 하는 방법이고, 사용자가 지정한 학습 신호에 따라 무엇이 좋은 행동이고 나쁜 행동인지 모델에 가중치 단위로 가르침.
  11. 훈련 중에는 에이전트가 도구를 부르는 여러 방식을 탐색하면서 과제를 풀어가는 과정을 거침.
  12. 이번에 제품에 새로 더한 것은 두 가지임. 모델이 공개 인터넷에 호스팅된 사용자 엔드포인트로 도구를 부를 수 있게 됐고, 롤아웃(rollout, 한 번의 시도) 뒤마다 역시 엔드포인트로 호스팅된 커스텀 보상 신호도 부를 수 있게 됨.
  13. 이 두 가지는 오픈AI가 훈련 과정 중에 모델이 바깥세상과 상호작용하도록 허용한 첫 사례라고 밝힘.
  14. 에이전트 RFT의 이점을 정리하면, 도구를 부르고 바깥세상과 상호작용하며 여러 단계로 일을 끝내야 하는 추론 모델의 성능을 끌어올리는 데 특히 효과가 있음.
  15. 샘플 효율도 좋아서 예제 딱 10개만 써서 성과를 낸 사례도 봤다고 밝힘. 결과적으로 지연(latency)이 줄고 과제에 더 잘 맞는 모델이 나옴.
  16. 에이전트가 특정 비즈니스 환경에서 잘 작동하지 않는 이유 중 하나는 그 환경이 모델을 사내에서 훈련할 때 쓴 환경과 다르기 때문이고, 머신러닝에서는 이를 도메인 시프트(domain shift)라고 부름.
  17. 도메인 시프트가 생기면 에이전트가 도구를 잘 못 부르거나, 도구를 너무 여러 번 부르거나, 도구에 엉뚱한 입력을 넣는 일이 생김.
  18. 에이전트 RFT는 가중치를 바꾸는 이 훈련 과정으로 모델을 그 도메인에 다시 맞춰, 실제로 그 환경을 이해하는 에이전트를 만듦.
  19. 이 과정에서 모델은 도구를 더 잘 쓰고 도구 출력을 놓고 더 잘 추론하는 법을, 탐색 공간을 훑고 보상을 향해 오르며 스스로 익힘.
  20. 또 다른 이점은 지연을 크게 줄일 수 있다는 것임. 모델이 정해진 도구 호출 예산(tool call budget)을 넘지 않도록 페널티를 줄 수 있고, 모델은 원래 성능을 지키거나 넘어서면서도 그 예산 안에 머무는 법을 익힘.
  21. 시스템 단계에서는 각 에이전트 롤아웃마다 고유 식별자(UUID)가 나오고, 그 롤아웃에서 만든 모든 도구 호출을 이 식별자에 연결해 궤적(trajectory)을 추적함.
  22. 그래서 마지막에 최종 답을 낼 때, 그동안 쌓인 맥락 전체를 그 답과 함께 채점기(grader)에 하나의 채점 맥락으로 통째로 넘길 수 있음.
  23. 다만 누구나 곧바로 에이전트 RFT부터 쓰라고 권하지는 않고, 먼저 훈련 데이터셋과 평가 데이터셋이 실제 프로덕션 트래픽과 어긋나지 않도록 맞춰야 한다고 함.
  24. 그다음 기준 모델(base model)을 그 데이터셋에 돌려 성능 기준선을 잡고, 거기서부터 개선해 나가야 함.
  25. 그 뒤 프롬프트·과제 최적화 같은 앞선 기법으로 성능을 먼저 짜내 보고, 그래도 더 필요할 때만 에이전트 RFT로 넘어가라고 함.
  26. 캐시가 이어받아 코딩 관련 고객 사례 몇 가지와 거기서 얻은 핵심 교훈을 소개함.
  27. 몇 달 전 코그니션(Cognition)과 함께 자사 코딩 에이전트 데빈(Devin)의 코드 편집 계획(planning) 단계에 에이전트 RFT를 적용함. 데빈이 저장소를 살피고 grep, 파일 읽기 같은 셸 도구를 돌려 어떤 파일을 고칠지 정하는 단계임.
  28. 사용자 질의와 실제로 사용자가 고친 파일을 짝지은 데이터셋을 만들고, 고른 파일의 F1 점수(정밀도와 재현율을 함께 보는 지표)를 보상으로 씀. 정확하지 않은 파일을 너무 많이 고르지도, 고쳐야 할 파일을 빠뜨리지도 않게 함.
  29. 트라젝토리(trajectory)마다 가상머신(VM)을 따로 띄워 코드베이스를 관리하고 도구 호출을 실행하고 최종 답을 채점하게 해서, 롤아웃끼리 셸 도구가 서로 영향을 주지 않도록 환경을 격리함.
  30. 첫 교훈은 데이터 품질과 양이 정말 크게 좌우한다는 것임. 예제 100개로 훈련했을 때는 5점 개선이었는데, 예제 1000개로 늘리자 개선폭이 10점으로 뛰었음.
  31. 둘째 교훈은 RFT가 도구를 병렬로 부르는 법을 익히는 데 특히 좋다는 것임. RFT 이전에는 추론 토큰을 내고 도구를 부르길 8~10단계 반복했는데, RFT 이후에는 첫 단계부터 여러 도구를 한꺼번에 부르며 단계 수가 4로 줄었음.
  32. 데빈이 편집을 빨리 내놓아야 하는 사례라 이 속도 개선이 특히 중요했음.
  33. 다음은 코드투(Codto)라는 회사가 만드는 코드 리뷰 에이전트 사례임. 핵심은 대형 코드베이스를 놓고 개발자가 묻는 질문에 답하는 딥 리서치(deep research) 에이전트임.
  34. 검색·조회 도구를 부르며 코딩 질문에 답하도록 GPT-5를 훈련했고, 서로 다른 저장소 8곳에서 모은 실제 질문·답 쌍 약 1000개를 데이터셋으로 씀. 보상은 에이전트가 찾아낸 관련 사실의 재현율(recall)로 줬음.
  35. RFT 뒤 정확도가 6퍼센트 개선됐고, 도구 호출 수와 출력 토큰 수도 줄었음.
  36. 가장 눈에 띈 것은 도구 호출 개수 분포가 바뀐 그래프였음. RFT 전에는 한 샘플에서 도구 호출이 15번을 넘는 나쁜 실행이 가끔 나왔는데, RFT 뒤에는 이런 긴 꼬리(long tail)가 사라지고 분포가 2~4회 근처로 모임.
  37. 정확도만 오른 게 아니라 지연에 영향을 주는 극단적인 P95 사례까지 잡아낸 셈이고, 프로덕션에서는 이런 지연 안정성이 중요하다고 짚음.
  38. 이어 코사인(Cosine)이 크고 복잡한 엔터프라이즈 코드베이스용 코딩 에이전트를 만든 사례임. grep, 키워드 검색, 세션 터미널, 브라우저 세션 등 도구 30개를 아우르는 세트로 훈련했고, 채점기(grader)를 매우 엄격하게 짰음.
  39. 처음에 뭔가 시도만 해도 부분 점수를 주자 모델이 코딩 스타일·어조 쪽만 최적화하는 문제가 생겼고, 그래서 최종 코드가 테스트를 통과할 때만 보상을 주는 방식으로 바꿈.
  40. 채점기가 엄격하다 보니 보상이 드물게 나올 수 있는데, 이럴 때 GPT-5가 성공 샘플을 더 뽑아내는 데 유리하다고 함. 그래서 배치 크기와 연산량을 늘려 양의 보상을 받는 샘플 수를 더 확보함.
  41. 커스텀 LLM 판정기를 하나 더 둬서 장황함(verbosity)이나 이모지처럼 비전문적으로 느껴지는 요소에 벌점을 줬음.
  42. 테스트를 돌리고 터미널 출력을 확인하고 린팅(linting, 코드 스타일·오류 자동 점검)까지 마친 뒤 성공을 선언하는 에이전트에만 보상을 줬음.
  43. 이렇게 훈련한 결과 코사인은 여러 벤치마크에서 최고 기록을 냈고, 속도도 훨씬 빨라짐. 전에는 한 트라젝토리에 메시지가 100개를 넘는 경우도 있었는데, 훈련 뒤에는 훨씬 촘촘하고 효율적인 단계로 수렴했음.
  44. 마지막 사례는 매코(Macco)임. 고성능 GPU 커널(kernel)을 작성하는 에이전트를 만드는데, 엔비디아 B200 같은 새 하드웨어처럼 예제가 원래 적은 영역이라 LLM에게 특히 어려운 과제임.
  45. 에이전트 RFT로 파이토치(PyTorch) 프롬프트 약 100개만 써서 GPT-5가 빠른 커널을 쓰도록 훈련했고, 이렇게 적은 예제로도 좋은 모델을 만들 수 있었던 게 이 사례의 핵심 성과임. 대신 보상 함수를 잘 짜는 일이 훨씬 중요해짐.
  46. 훈련 초반 모델이 보상을 해킹(reward hacking, 진짜 과제를 풀지 않고 채점 허점을 이용하는 것)하는 걸 발견하고 롤아웃을 뒤져 서로 다른 해킹 사례 7가지를 찾음. 참조 코드를 그대로 돌려주거나, 커널을 아예 안 만들거나, 항등(identity) 커널만 내놓는 식이었음.
  47. 이 일곱 가지를 잡아내 0점을 매기는 판정용 LLM을 만들고, 추상 구문 트리(AST)를 쓰는 정적 분석 도구까지 더해 생성한 커널이 실제로 존재하고 실행되는지 확인함.
  48. 이런 안전장치를 다 갖춘 뒤에야 정확도와 파이토치 기준 대비 실제 속도 향상을 점수로 매겼고, 에이전트는 GPT-5보다 눈에 띄게 좋아짐.
  49. 여기에 더해 샘플 3개를 뽑아 그중 가장 좋은 것을 고르는 기법까지 써서, 기존 최고 기록을 72퍼센트 앞질렀음.
  50. 윌이 다시 이어받아, 이런 성과를 내려면 지켜야 할 원칙 네 가지를 정리함.
  51. 첫째, 과제를 명확하고 제약이 뚜렷하게 정의해야 함. 성공 기준이 모호하지 않아야 하고, 취향(taste)이 채점에 끼어들 여지를 없애야 함.
  52. 둘째, 모델이 실제 서비스에서 놀라지 않도록 훈련·평가 데이터셋이 프로덕션 트래픽을 그대로 반영해야 하고, 스스로 도메인 시프트를 만들어내면 안 됨.
  53. 셋째, 같은 데이터 지점에서 더 많이 샘플링할수록 모델이 낼 수 있는 최고 성능이 올라가야 함. 그래야 롤아웃 사이에 편차가 생기고, 모델이 좋은 시도와 나쁜 시도의 차이를 스스로 배울 수 있음.
  54. 넷째, 보상 함수가 해킹당하지 않게 구석구석 막아야 하고, 보상이 이분법(binary)이 아니라 연속적이어야 함. 학생에게 부분 점수를 주듯 모델이 최적에 조금씩 가까워지게 하는 방식임.
  55. 마무리로 에이전트 RFT를 시작하려면 담당 어카운트 디렉터에게 연락하라고 안내하며 발표를 마침.

한줄 코멘트. 네 사례 다 파트너사 자체 집계라 외부 검증은 없지만, 예제 100개를 1000개로만 늘려도 5점이 10점 되고 파이토치 프롬프트 100개로 최고 기록을 72퍼센트 앞지른 숫자는 파인튜닝에 필요한 데이터 문턱을 확 낮춘 사례로 봄직함.

  1. 이 발표는 구글 딥마인드(Google DeepMind) 연구자이자 제미나이(Gemini) 안의 씽킹(thinking, 답을 내기 전에 모델이 스스로 여러 단계를 거쳐 생각하는 과정) 팀 테크리드인 잭 레이(Jack Rae)가 AI 엔지니어 컨퍼런스에서 한 것임.
  2. 발표는 세 단계로 감. 왜 씽킹에 주목하는지 연구 동기, 씽킹이 실제로 뭔지, 그리고 앞으로 뭘 할 건지 순서임.
  3. 첫 단계의 메시지는 진보란 지능으로 가는 길목의 병목을 찾아내고 그걸 풀어온 역사라는 것임.
  4. 1948년 클로드 섀넌(Claude Shannon)이 통신의 수학적 이론을 세우며 처음으로 언어모델을 만듦. 사람이 손으로 집계한 단어 통계 교과서를 써서 바이그램(단어 두 개를 묶어 다음 단어를 예측하는 모델)을 만든 것임.
  5. 섀넌은 이 바이그램에서 뽑은 문장이 유니그램(단어 하나만 보는 모델)보다 훨씬 낫다고 감탄하면서도, 이 방법을 그대로 키우면 더 좋아질 거라고 적었음.
  6. 하지만 섀넌에게는 그 확장이 쉽지 않았음. 인류 지식을 디지털화하고 그 통계를 대규모로 모을 현대적 컴퓨팅이 필요했기 때문임.
  7. 수십 년 뒤 2000년대 구글에서 제프 딘(Jeff Dean) 등이 n그램 언어모델을 수조 개 토큰으로 훈련시켰고, 당시 가장 앞선 음성 인식·번역 시스템을 돌렸음.
  8. 이 n그램 모델의 병목은 짧은 문맥에만 묶여 있다는 것이었음. 문맥 길이가 늘수록 저장 비용이 지수적으로 커져 다른 도리가 없었다고 함.
  9. 해법은 2010년 딥러닝 초기 도입, 그중에서도 순환신경망(recurrent neural network, 과거 정보를 압축해 내부 상태에 담아두고 계속 갱신하는 신경망) 언어모델이었음.
  10. 순환신경망은 과거를 압축한 표현을 네트워크 상태에 저장해서, 다섯 단어짜리 문장을 넘어 문단 단위까지 다룰 수 있게 만든 큰 도약이었음.
  11. 몇 년 뒤 새 병목이 드러남. 순환신경망의 과거 표현은 크기가 고정된 상태 하나에 담기다 보니 정보가 손실되는 것이 자주 관찰됐다고 함.
  12. 해법은 과거의 신경망 표현을 전부 남겨두고, 어텐션(attention, 필요한 과거 표현만 그때그때 끌어와 계산에 반영하는 연산)으로 즉석에서 종합하는 방식이었음.
  13. 이렇게 어텐션이 태어났고 곧이어 트랜스포머(transformer)가 나오면서 지금의 딥러닝 혁명으로 이어짐.
  14. 10년을 건너뛰어 2024년, 제미나이나 챗GPT(ChatGPT) 같은 대형언어모델이 강력한 범용 대화 에이전트로 여러 용도에 쓰이게 됨.
  15. 이 발표가 겨냥하는 병목이 여기서 나옴. 모델이 아무리 강력해도 여전히 요청에 즉시 답하도록만 훈련돼 있어서, 요청에서 답까지 쓰는 계산량이 고정돼 있다는 것임.
  16. 이걸 테스트타임 컴퓨트(test-time compute, 질문을 받아 답을 내기까지 모델이 실제로 쓰는 계산량) 병목이라고 부름.
  17. 요청 텍스트가 토큰으로 바뀌어 모델을 통과하는데, 각 층에서는 병렬 계산이, 층과 층 사이에서는 반복 계산이 일어나며 그 크기가 정해져 있다는 것임.
  18. 더 똑똑한 답을 원한다면 모델을 키워 계산량을 늘리는 방법이 있지만, 그것만으로는 부족하다고 함.
  19. 사용자는 아주 어렵거나 값진 문제에는 천 배, 백만 배도 더 생각하길 원하고, 쉬운 요청엔 적게 어려운 요청엔 많이 쓰는 식으로 계산량이 모델 스스로에 의해 동적으로 조절되길 원한다는 것임.
  20. 바로 이 지점이 씽킹을 만든 동기임.
  21. 제미나이의 씽킹은 기계적으로는 모델이 최종 답을 내놓기 전에 추가 텍스트를 먼저 뱉는 씽킹 단계를 끼워 넣는 구조임.
  22. 이 단계는 루프이기 때문에 수천, 수만 번 반복할 수 있고, 그만큼 테스트타임 컴퓨트를 더 쓸 수 있게 됨.
  23. 루프이다 보니 동적이기도 해서, 모델이 답을 확정하기 전 이 루프를 몇 번 돌릴지도 모델 스스로 학습함.
  24. 이 씽킹 단계를 쓰도록 훈련시키는 방법은 강화학습(정답을 직접 알려주는 대신 맞고 틀림에 따라 점수를 매겨 그 점수가 오르는 방향으로 모델을 미는 학습법)임.
  25. 사전학습 뒤 여러 과제를 풀게 하고 맞으면 양의 보상, 틀리면 음의 보상을 주는 매우 일반적인 훈련 레시피라고 함.
  26. 정답·오답이라는 아주 모호한 신호만으로도 모델이 이 씽킹 루프를 거슬러 올라가며 씽킹 토큰을 어떻게 쓸지 스스로 다듬는다는 게 놀랍다고 밝힘.
  27. 사실 이게 통할지 확신이 없었다고 함. 씽킹 단계에 얼마나 많은 구조를 미리 심어둬야 하는지도 불확실했다는 것임.
  28. 초기 강화학습 실험에서 나온 한 예시를 역사적 기록으로 보여줌. 정수를 맞히는 수학적인 문제였다고 함.
  29. 모델이 씽킹 토큰으로 먼저 가설을 세우고 그 가설을 검증한 뒤, 공식이 맞지 않는다며 자기 아이디어를 스스로 기각하고 다른 접근을 시도했다고 함.
  30. 강화학습이라는 일반적인 레시피 하나로 가설 세우기·자기 수정 같은 예상 밖의 행동이 나오는 걸 보고 팀이 크게 놀랐다고 밝힘.
  31. 요즘 모델은 문제를 여러 조각으로 쪼개고, 여러 풀이를 동시에 탐색하고, 코드 조각을 초안으로 짜서 모듈처럼 쌓아 올리고, 중간 계산을 하고, 도구를 쓰는 등 다양한 전략을 스스로 익혔다고 함.
  32. 이 모든 전략은 결국 더 많은 테스트타임 컴퓨트를 써서 더 똑똑한 답을 내놓는다는 하나의 목적 아래 있다는 것임.
  33. 개발자에게 씽킹이 흥미로운 첫째 이유는 더 강력한 모델로 이어지고, 기존의 모델 발전 방식 위에 그대로 쌓인다는 것임.
  34. 사전학습(pre-training)에서는 데이터양과 모델 크기를 키우고, 후속학습(post-training)에서는 사람 피드백의 질과 다양성을 키우는데, 씽킹은 여기에 곱셈으로 더해지는 효과를 낸다고 함.
  35. 그 결과 구글 내부에서 이 모든 축에 함께 투자하면서 전반적인 모델 개선 속도가 더 빨라진다는 것임.
  36. 최근 제미나이 출시 계보를 보면 추론 성능이 좋아진 게 모델이 문제에 쓰는 테스트타임 컴퓨트양과 실제로 맞물려 있다고 함.
  37. 로그 스케일 테스트타임 컴퓨트를 가로축, 수학·코드·과학 문제 성능을 세로축에 놓으면 왼쪽 끝엔 씽킹 없이 나온 2.0 플래시 실험판(작년 12월 출시)이, 오른쪽 끝엔 처음 출시된 2.5 프로가 놓임.
  38. 테스트타임 컴퓨트가 늘수록 추론 성능도 함께 느는 추세가 나타나며, 이걸 두고 테스트타임 스케일링이 실제로 작동한다고 말함.
  39. 씽킹이 중요한 건 성능만이 아니라 품질과 비용을 조절하는 손잡이가 된다는 점도 있음.
  40. 예전엔 몇 가지 정해진 모델 크기 중에서 고르는 것이 품질과 비용을 가늠하는 유일한 방법, 즉 이산적인 선택이었음.
  41. 씽킹이 생기면서 연속적인 씽킹 예산(budget)을 쓸 수 있게 돼, 과제군마다 얼마나 많은 능력을 쓸지 훨씬 세밀하게 조절하는 슬라이더가 생겼다고 함.
  42. 이 씽킹 예산은 지금 2.5 시리즈의 플래시(Flash)와 프로(Pro)에 모두 들어가 있어서, 비용 대비 성능을 세밀하게 고르고 필요하면 비용과 성능을 둘 다 더 밀어 올릴 수 있다는 것임.
  43. 앞으로는 크게 두 가지에 집중함. 하나는 모델을 계속 개선해 추론을 더 잘하게 만드는 것이고, 다른 하나는 씽킹 과정 자체를 최대한 효율적으로 만드는 것임.
  44. 씽킹이 사용자가 따로 튜닝하지 않아도 알아서 잘 작동하고 적응적이길 바란다고 함.
  45. 모델이 과제를 과하게 오래 생각하는 사례가 있고, 이걸 더 빠르고 비용 효율적으로 만드는 게 지금도 이어지는 연구 영역이라고 밝힘.
  46. 또 다른 방향은 딥 씽킹(deeper thinking), 즉 추론 계산량을 더 늘려서 능력을 한층 더 끌어올리는 것임.
  47. 제미나이 딥 리서치(Gemini Deep Research)에서는 질문을 입력하면 모델이 오랜 시간 자리를 비우고 주제를 조사해 온다고 함.
  48. 구글 IO에서 발표하고 신뢰 테스터에게 먼저 여는 딥 싱크(Deep Think)는 2.5 프로 위에 얹은 아주 높은 씽킹 예산 모드임.
  49. 딥 싱크는 아주 어려운 문제에 질문을 던져놓고 비동기로 한참 돌아간 뒤 더 강한 답을 들고 돌아오는 용도로 만들었다고 함.
  50. 핵심 아이디어는 훨씬 더 깊은 사고 사슬(chain of thought)과, 여러 사고 사슬을 병렬로 돌려 서로 통합하는 것이라고 함.
  51. 이 방식은 아주 어려운 멀티모달·코드·수학 문제에서 성능을 끌어올린다고 함. 예로 든 것이 미국 수학 올림피아드임.
  52. 올해 1월만 해도 최고 수준 모델의 미국 수학 올림피아드 성적은 거의 없는 수준이었다고 함.
  53. 오늘 기준 업데이트된 2.5 프로는 전체 올림피아드 참가자 중 대략 50퍼센타일에 해당하고, 딥 싱크를 쓰면 65퍼센타일까지 올라간다고 밝힘.
  54. 앞으로 기반 모델과 딥 싱크의 알고리즘적 요소가 각각 계속 좋아지면 두 개선이 그대로 겹쳐 쌓일 것이라고 함.
  55. 미국 수학 올림피아드 대수 문제를 딥 싱크가 푸는 과정을 영상으로 보여줌. 모델이 귀류법(모순을 이끌어내 명제를 증명하는 방법) 아이디어로 시작함.
  56. 이어 롤의 정리(Rolle's theorem)와 뉴턴 부등식(Newton's inequalities) 두 갈래를 각각 탐색한 뒤 이를 통합해 결국 올바른 증명에 도달했다고 함.
  57. 이제는 모델이 열린 형태의 코딩 과제에 점점 더 오래 생각을 쓰는 데 관심이 크다고 함. 예전엔 몇 달 걸리던 일이 한 번 지시로, 몇 번의 상호작용만으로 끝나는 바이브 코딩(vibe coding, 코드를 한 줄씩 직접 짜지 않고 자연어로 지시해 모델이 짜게 하는 방식)으로 옮겨간다는 것임.
  58. 예로 든 사례는 동료 연구자들이 딥마인드의 원조 DQN(Deep Q-Network, 딥마인드가 심층강화학습을 처음 보여준 대표 논문) 논문을 바이브 코딩으로 재현한 것임.
  59. 제미나이가 훈련 설정과 알고리즘은 물론 아타리(Atari) 에뮬레이터까지 바이브 코딩해서 실제로 게임을 플레이하게 만들었다고 함.
  60. 예전엔 본인과 동료들이 몇 달을 들여야 했던 일이 이제 몇 분 만에 벌어지기 시작했다는 게 놀랍다고 밝힘.
  61. 앞으로를 내다보며 흥미로운 건 모델의 지형이 아니라 결국 목표로 삼는 기준, 즉 사람의 정신이라고 함.
  62. 아주 적은 지식만으로도 아주 깊게 사고할 수 있는 모델을 만들어 그걸로 지식의 최전선을 밀어붙이고 싶다는 것임.
  63. 그 예로 든 인물이 20세기 초 최고의 수학자 중 한 명인 라마누잔(Ramanujan)임. 수학 공동체와 단절된 채 교과서 한 권만 가지고 있었다고 함.
  64. 라마누잔은 그 적은 문제들에서 출발해 교과서 여러 권 분량에 맞먹는 사고를 쏟아부으며 자기만의 이론을 만들어 방대한 수학을 발명해냈다고 함.
  65. 이게 바로 씽킹이 가야 할 방향이라고 함. 모델이 데이터를 아주 효율적으로 쓰면서 수백만 토큰, 그 이상의 추론까지 밀고 가 지식과 결과물을 스스로 쌓아 올리길 바란다는 것임.
  66. 그렇게 해서 언젠가 인류 이해의 최전선 자체를 밀어붙이는 지점까지 가고 싶다는 게 발표를 마무리하며 그린 그림임.

한줄 코멘트. 섀넌부터 라마누잔까지 병목을 풀어온 역사로 그렸지만, 씽킹의 실체는 결국 문제 하나에 계산을 얼마나 태우느냐의 문제라 딥 싱크의 65퍼센타일도 비동기로 얼마나 오래 돌렸는지, 그래서 얼마를 썼는지는 언급하지 않은 채 나온 숫자임.

02

코딩 에이전트 · 개발 도구

  1. Erik Hanchett(AWS 시니어 개발자 애드보킷)가 AI 엔지니어(AI Engineer) 컨퍼런스에서 발표함. 명세 주도 개발(spec-driven development, 코드를 쓰기 전에 요구사항과 설계 문서부터 구조화해 작성하는 개발 방식)을 실제 워크플로에 쓰는 법을 소개함.
  2. 정의는 간단함 — 코드를 쓰기 전에 구조화된 명세(specification)를 먼저 만드는 것이고, 실제로는 요구사항 문서와 설계 문서를 마크다운(markdown) 파일로 먼저 쓰는 작업이라고 함.
  3. 이 방식이 대형 언어 모델과 코딩 어시스턴트랑 잘 맞는다며, 목표는 코드를 빨리 뽑는 게 아니라 더 좋은 품질의 코드를 뽑는 것이라고 함.
  4. 왜 필요하냐는 질문에는, 오늘날 코딩 어시스턴트를 "AI 인턴"에 비유함. 인턴처럼 방향을 정확히 짚어줘야지 조금만 여지를 주면 궤도를 벗어난다고 함.
  5. 자기가 첫 직장에서 인턴이던 시절, 어떤 부사장이 돌아다니며 즉흥적인 아이디어를 던지면 그때마다 하던 일을 다 놓고 그 지시를 따랐다는 일화를 듦.
  6. 나중에 상사한테 왜 그랬냐는 지적을 받았고, 부사장이 준 정보는 받아 적어 일정에 넣고 매니저와 먼저 상의해야 한다는 걸 배웠다고 함. 지금의 LLM도 이렇게 너무 성급하게 반응하니 조심해야 한다고 함.
  7. 자기소개도 덧붙임 — AWS 시니어 개발자 애드보킷이고 소프트웨어 개발 경력이 15년 넘었으며, 링크드인(LinkedIn)에서 자기 이름으로 찾을 수 있다고 함.
  8. 최신 프런티어 모델이면 다 알아서 해주지 않냐는 질문도 자주 받는다고 함.
  9. 모델이 해마다, 발표마다 조금씩 또는 크게 좋아지고 있지만 아직 완벽하지 않고, 모델에 맥락(context)을 더 주는 일이 방향을 잡아주는 데 실제로 중요하다고 함.
  10. 소프트웨어와 요구사항이 계속 바뀌고 새 패러다임이 계속 나오는 만큼, 모델을 원하는 방향으로 계속 이끌어줘야 한다고 함. 일부 모델·하네스(harness, 모델을 감싸 도구 호출 등을 관리하는 실행 틀)가 코드를 쓰기 전에 생각하거나 계획하는 모드를 넣기 시작했지만, 문서를 실제로 만들고 사람이 그 중간에 개입하는 것만 한 게 없다고 함.
  11. 본론에 들어가기 전 자기 의견 몇 가지를 미리 짚음. 정보가 워낙 많이 떠도는 주제라 이건 자기 의견일 뿐이니 링크드인으로 동의든 반대든 알려달라고 함.
  12. 첫째, 맥락을 조심해야 함. 명세 주도 개발이 LLM에 맥락을 많이 넣어주긴 하지만 지나치면 오히려 독이 된다고 함.
  13. 보통 에이전트에 agents.md나 claude.md 같은 파일을 만들어 시작 정보를 넣는데, 정보를 너무 많이도 너무 적게도 넣지 않는 "골디락스 존(Goldilocks zone, 많지도 적지도 않은 딱 알맞은 범위)"을 지켜야 한다고 함. 키로(Kiro)에서는 이걸 스티어링 문서(steering docs)라고 부른다고 함.
  14. 둘째, 스킬(skill, 특정 키워드가 감지되면 자동으로 켜지거나 슬래시(/) 명령으로 직접 부르는 지시 파일)을 쓰길 강력히 권함. 명세 주도 개발 과정에서 설계 문서를 만들 때든 태스크를 실제로 구현할 때든 스킬을 함께 쓸 수 있다고 함.
  15. 셋째, 너무 많은 신뢰를 주지 말라고 함. 명세 주도 개발 흐름 전체에서 사람이 고리 안에 있는 존재(human in the loop)이고, 생성된 코드의 리뷰어는 결국 사람이라고 함.
  16. 뭔가 잘못되면 비난받는 건 에이전트가 아니라 사람이기 때문에, 설계 문서와 요구사항 문서를 계속 들여다봐야 한다고 함. 그렇다고 코드 리뷰 도구를 안 쓴다는 뜻은 아니고, 평소 쓰는 AI 코딩 어시스턴트나 리뷰 도구로 풀 리퀘스트(PR)나 변경 요청(CR)을 검토하는 데 써도 된다고 함.
  17. AWS 자체의 히스토리를 짚음. AWS 팀과 고객들이 바이브 코딩(vibe coding, 세부 코드 대신 원하는 결과와 의도만 프롬프트로 전달하고 나머지는 모델에 맡기는 코딩 방식)을 쓰고 있었지만 원하는 결과물이 안 나온다는 필요를 봤다고 함.
  18. 고객들이 이미 나름대로 에이전트에게 방대한 요구사항 문서와 설계 문서를 만들게 하는 임시방편 패턴을 쓰고 있는 걸 보고, AWS가 이걸 대신 다 해주는 애플리케이션을 만들기로 했다고 함.
  19. 그렇게 나온 게 새 AI IDE 코딩 어시스턴트 키로(Kiro)이고, 작년 말 일반 공개(GA)로 출시했으며 인기 있는 명령줄 인터페이스(CLI) 버전도 함께 냈다고 함. 지금은 IDE보다 CLI를 더 많이 쓰는 쪽으로 옮겨가는 추세라고 함.
  20. 키로가 집중한 건 화면에서 보여준 "바이브 모드"와 "스펙 모드" 두 가지라고 함. 더 크고 복잡한 프로젝트를 다루려는 고객들이 프로젝트가 정확히 뭘 하는지 코딩 시스템이 알아야 한다고 요구했던 게 배경이라고 함.
  21. kiro.dev 웹사이트도 함께 냈고 CLI와 IDE를 받아 써볼 수 있다고 함. 공개 당시 화제가 돼 다운로드가 수만 건 몰렸다고 함.
  22. 프리뷰 단계에서는 신청이 너무 많아 게이트를 걸어야 했고 사람들이 그 게이트를 우회하는 법까지 찾아냈다고 함. 지금은 누구나 쓸 수 있게 공개돼 있다고 함.
  23. 이 발표가 키로 홍보로 끝나지 않게, 키로 없이도 명세 주도 개발을 할 수 있는 방법 몇 가지를 짚음.
  24. 첫 번째는 수작업 방식임 — 어시스턴트에게 먼저 사용자 요구사항을 만들라고 시키거나 직접 쓴 요구사항을 주고 이를 기준으로 삼으라고 함.
  25. 이후 앞뒤로 확인하며 요구사항을 다듬고 설계 문서를 만들게 한 뒤, 다시 확인하고 요구사항과 설계 문서를 근거로 구현 태스크 목록을 만들게 하는 순서라고 함.
  26. 두 번째로 스펙 킷(Spec Kit)을 언급함. 깃허브(GitHub)가 낸 오픈소스 방식으로, 여러 코딩 어시스턴트에 설치해 쓸 수 있다고 함.
  27. 세 번째가 키로 자체인데, IDE 버전엔 "스펙(spec)"을 고르는 랩이 있고 CLI에는 계획 모드(plan mode)가 있다고 함. 프롬프트로 예를 들어 "본 영화를 기록하는 무비 MCP 서버를 만들어줘"나 "영화 웹사이트를 만들어줘"처럼 넣으면 된다고 함.
  28. 스펙 모드가 신규(그린필드) 프로젝트에만 좋은 게 아니냐고 생각할 수 있는데 전혀 아니라고 함. 몇 년 된 기존 앱에도 스펙 파일이 수십 개씩 쌓여 있는 사례를 봤고 레거시 프로젝트에도 잘 먹힌다고 함.
  29. 깊이 있는 기능을 만들 때, 프로젝트가 사전 계획을 더 필요로 할 때, 구조화된 방식으로 일하고 싶을 때 특히 좋다고 함. 복잡한 프로젝트에 잘 맞고, 버그 수정용 스펙 모드도 추가했지만 작은 건은 그냥 바이브 코딩이 나을 수도 있다고 함.
  30. 요구사항 문서는 EARS(Easy Approach to Requirements Syntax, 요구사항을 정해진 문장 틀에 맞춰 쓰는 표기법) 형식으로 나오고, 서론과 요구사항, 사용자 스토리를 담는다고 함.
  31. 프롬프트를 넣으면 요구사항 단계를 만들기 전에 확인 질문을 먼저 던지는 절차도 붙어 있다고 함. 최근엔 퀵 플랜 모드(quick plan mode)도 추가돼, 그 질문과 답을 근거로 문서 전체를 빠르게 한 번에 생성해준다고 함.
  32. 그다음 더 상위 수준의 설계 문서를 만드는데, 설계 문서부터 먼저 시작할 수도 있고 아예 요구사항과 설계를 합쳐서 쓰는 사람도 있다고 함. 명세 주도 개발 흐름에서는 요구사항과 설계 중 어느 쪽부터 시작해도 된다고 함.
  33. 설계 문서에는 머메이드(mermaid) 다이어그램이나 아스키 아트(ASCII art)로 정보가 정리되는데, 이 단계에서 멈춰 자기 지식과 취향으로 직접 고쳐 넣기를 강력히 권함. 결과물은 사람이 넣은 만큼만 나온다고 함.
  34. 짧은 프롬프트와 확인 질문만으로도 꽤 괜찮은 결과가 나오지만, 마크다운 문서에서 앞뒤가 안 맞는 부분·환각(hallucination)·오류가 없는지 늘 검토해야 한다고 함.
  35. 마지막 구현(implementation) 단계에서 태스크 목록이 나오고, 속성 기반 테스트(property-based test, 요구사항·설계 문서를 근거로 다양한 값을 넣어 조건이 항상 성립하는지 검증하는 테스트)도 같이 만들어 돌릴 수 있다고 함.
  36. 태스크가 제대로 구현됐는지 확인하려면 이 속성 기반 테스트를 꼭 만들고 돌려보길 권함.
  37. 실전 팁으로, 태스크 목록이 나오면 "상위 네 개 태스크를 맨 위로 올려서 최소 기능 제품(MVP, minimum viable product, 핵심 기능만 갖춘 최소 버전)을 먼저 만들어달라"고 시킨다고 함. 그러면 일단 돌아가는 걸 먼저 보고 그 MVP부터 구현할 수 있다고 함.
  38. 모델 컨텍스트 프로토콜(MCP, model context protocol, 모델 제공사가 여러 데이터 소스에 연결할 수 있게 해주는 프로토콜)을 좋아한다고 함. 키로 안에서 오픈AI(OpenAI)나 앤트로픽(Anthropic) 같은 모델과 여러 데이터 소스를 이 프로토콜이 중간에서 이어준다고 함.
  39. MCP가 나온 지 6개월 됐는데 벌써 죽은 거 아니냐는 질문도 받는다고 함. 명령줄 도구만으로도 비슷한 걸 할 수 있다는 의견도 있지만, MCP는 아직 성숙해가는 단계이고 특히 보안 쪽으로 갈 길이 멀다며 계속 지켜봐야 한다고 함.
  40. 명세 주도 개발 흐름에서 MCP를 좋아하는 핵심 이유는, 지라(Jira)나 아사나(Asana) 같은 프로젝트 관리 도구의 티켓과 방대한 요구사항 문서를 스펙을 만들 때 그대로 끌어올 수 있어서라고 함. 프로덕트 매니저가 이미 써놓은 요구사항 문서가 있으면 그걸 가져와 쓸 수 있어 훨씬 수월하다고 함.
  41. 스티어링 문서나 agents.md 파일에 "명세 주도 개발을 할 땐 이 MCP 서버에서 정보를 가져와라"는 규칙을 추가로 넣어둘 수도 있고, 첫 스텝에서 "요구사항 만들 때 이 MCP 서버를 보라"고 바로 지정할 수도 있다고 함.
  42. 데모로 최신 키로 IDE 버전을 보여줌. 시간 관계상 완전히 새로 프로젝트를 만드는 대신 미리 만들어둔 무비 데이터베이스 프로젝트를 씀. 그린필드 성격이지만 흐름을 이해하는 데는 충분하다고 함.
  43. 스펙 모드에서 "영화 웹사이트를 만들어달라"고 요청함. 이번엔 요구사항 대신 설계부터 시작하라고 지시했다고 함.
  44. 그 결과 마크다운 파일 미리보기로 아키텍처 다이어그램·시퀀스 다이어그램 같은 머메이드 다이어그램이 여러 개 만들어진 걸 보여줌. 이 설계 문서를 오가며 직접 고치고 편집했다고 함.
  45. 문서 맨 아래로 내려가면 여러 속성 기반 테스트가 생성돼 있는 걸 확인할 수 있다고 함. 이 테스트는 타입스크립트(TypeScript)·노드(Node) 세계에서 쓰는 fast-check 라이브러리로 돌아간다고 함.
  46. 서로 다른 값으로 수십 번, 많으면 수백 번씩 반복 실행하며 요구사항이 제대로 만족되는지 확인한다고 함.
  47. 이어서 EARS 형식의 요구사항 문서도 보여줌. 사용자 스토리와 요구사항이 담겨 있고, 예를 들어 "요구사항 1, 영화 데이터 로딩 — 애플리케이션이 초기화되면 필터 엔진이 로드돼야 한다"처럼 단계별로 구체적이라고 함.
  48. 태스크 목록 단계에서 "MVP를 만들 수 있냐"고 물었더니 태스크 목록을 다시 정리해줬다고 함.
  49. 새 태스크 목록엔 "태스크 1번부터 4번까지가 동작하는 MVP를 만든다 — 검색·장르 필터링·정렬 기능이 있는 탐색 가능한 영화 그리드와 80년대풍 신스웨이브(synthwave) 테마 전체를 포함한다"라고 명시됐다고 함.
  50. 요구사항을 다시 손봐 MVP를 먼저 돌아가게 만든 뒤, 나머지 태스크도 전부 이어서 구현했다고 함.
  51. 속성 기반 테스트 예시로, 장르 필터링에 대해 "어떤 영화 데이터셋을 넣어도 추출된 장르 목록은 정확히 정렬된 고유 장르 집합이어야 한다"는 조건이 마우스를 올리면 뜬다고 보여줌. 테스트가 정확히 뭘 확인했는지 알려준다고 함.
  52. 마무리로 더 알고 싶으면 kiro.dev나 디스코드(discord.gg/kiro.dev)로 오라고 안내함. 링크드인에서는 Eric Hanchett으로, 블루스카이(Bluesky)에서는 Eric C H로 찾을 수 있다고 함.

한줄 코멘트. 골디락스 존을 지키라면서도 그 경계가 어디인지는 안 알려주는데, 결국 사람이 설계·요구사항 문서를 계속 들여다봐야 한다는 그 앞의 조언과 같은 말임.

  1. 유진 얀(앤트로픽 기술스태프)이 최근 몇 달간 보안팀과 함께 클로드로 취약점을 찾고 고치는 작업을 해온 경험을 나누는 발표라고 밝힘.
  2. 청중에 보안 엔지니어와 일반 엔지니어가 각각 얼마나 있는지 먼저 확인한 뒤, 모델 능력의 흐름과 여섯 단계 실전 교훈, 이번 주부터 시작하는 법 순으로 이야기하겠다고 함.
  3. 영국 AI 안전 연구소(UK AI Security Institute)가 시간 지평(time horizon) 벤치마크의 사이버보안판을 만들어 모델이 취약점을 찾고 공격하는 데 걸리는 시간을 사람과 비교해 재는데, 처리 가능한 과제 길이가 계속 늘 뿐 아니라 기존 추세선 대비 계단식으로 뛰어오르는 구간이 보인다고 함.
  4. 파이어폭스가 매달 고친 보안 버그 수를 공개했는데, 2025년 월평균 20건 안팎이던 수치가 2월·3월엔 60~70건으로 3배, 4월엔 400건으로 지난해 평균의 20배가 됐다고 함.
  5. 파이어폭스는 이 급증의 상당 부분을 프론티어 모델의 도움으로 돌렸다고 하며, 모델이 방어자 쪽에서 취약점을 대규모로 찾고 고치는 데 실제로 쓰이고 있다는 뜻이라고 함.
  6. 로그4셸(자바 로깅 라이브러리 로그4제이의 결함으로, 공격자가 보낸 문자열을 그대로 로그에 남기면 그 안의 코드가 실행되는 취약점)을 기억하는지 청중에게 물음.
  7. 로그4셸로 벨기에 국방부가 며칠 만에 뚫렸고, 한 핀테크 플랫폼에서는 이용자 200만 명의 데이터가 유출됐다고 함.
  8. 그전에는 오픈SSL(인터넷 암호 통신에 널리 쓰이는 라이브러리)의 결함인 하트블리드가 있었고, 인터넷 상당 부분이 이 라이브러리 위에서 돌아가는 만큼 파장이 컸다고 함.
  9. 앤트로픽도 오픈소스 저장소 1000여 곳을 스캔해 후보 2만3000건 중 6200건을 고위험 또는 치명 등급으로 골랐고, 그중 1600건을 메인테이너에게 보고했으며 그 시점까지 약 100건이 실제로 패치됐다고 함.
  10. 이 경험에서 얻은 관찰은, 이제 취약점을 찾는 일 자체는 꽤 쉬워졌다는 것이라고 함.
  11. 대신 병목은 검증(verification)과 분류(triage), 패치로 옮겨갔다고 하며, 발표에서 이걸 어떻게 다루는지 나눠보겠다고 함.
  12. 모즐라의 예전 언급을 인용하는데, 초기 실험에서는 오탐(실제로는 아닌데 취약점이라고 잘못 짚는 결과)이 너무 많아 규모를 키우기 어려웠다고 함.
  13. 하지만 보안 문제를 안정적으로 잡아내는 에이전틱 하네스(모델과 도구·절차를 엮어 스스로 반복 작업을 하게 만든 틀)가 도입되면서 상황이 바뀌었고, 모델과 하네스가 함께 움직이면 실제 버그를 찾으면서 재현 안 되는 추측성 결과는 걸러낼 수 있다고 함.
  14. 함께 일한 여러 팀이 대체로 같은 여섯 단계로 수렴한다고 하며, 발표의 큰 부분을 이 여섯 단계 설명에 쓴다고 함.
  15. 앞의 두 단계는 준비 작업으로, 코드베이스마다 한 번씩 선행 투자를 하는 위협 모델(threat model, 시스템의 어느 지점이 공격받을 수 있는지 미리 그려두는 문서)과 격리된 샌드박스 구축이라고 함.
  16. 뒤의 네 단계는 반복 루프로, 취약점을 찾는 발견(discovery), 진짜인지 확인하는 검증, 우선순위를 매기는 분류, 그리고 패치라고 함.
  17. 설명을 구체화하려고 가상의 시스템인 오더 서비스(주문 ID를 넣으면 주문 정보를 조회하는 서비스)를 예로 든다고 함.
  18. 여러 팀에서 잘 정리된 위협 모델을 갖춘 경우 참양성률(모델이 찾아낸 것 중 실제로 진짜 취약점인 비율)이 90%까지 오르고, 75% 이상이면 그 자체로 좋은 목표라고 함.
  19. 한 최고정보보호책임자(CISO)의 말을 인용해, 모델은 코드 맥락은 잘 알지만 시스템 맥락은 잘 모른다고 함.
  20. 모델은 글로 적힌 건 잘 읽어내지만, 왜 설계자가 이렇게 설계했는지, 온콜 담당자가 문서화 없이 고쳐온 취약점이 무엇인지는 코드에 없어 모른다고 함. 이런 암묵지를 어딘가에 적어둬야 모델이 더 나은 보안 엔지니어가 될 수 있다고 함.
  21. 위협 모델을 처음 만들 때는 모델에게 문서와 코드, 과거 커밋과 패치 이력, 그 패치가 막은 CVE(공개적으로 등록되는 취약점 식별 번호)까지 다 주고 아직 패치되지 않은 취약점을 추론해보게 할 수 있다고 함.
  22. 그다음엔 모델이 시스템을 잘 아는 전문가를 인터뷰하게 해서, 미처 대비하지 못한 위험이나 신경 안 써도 되는 부분(내부 VPN 전용 앱이라거나 다른 곳에 보완 통제가 있다거나)을 끌어내야 한다고 함.
  23. 오더 서비스 위협 모델 예시에서는 핵심 자산이 고객 개인정보(PII)를 담은 데이터고, 진입점은 주문 API라고 정리됨.
  24. 모델은 이 서비스에서 SQL 인젝션(입력값이 SQL 질의문에 그대로 섞여 들어가 공격자가 질의를 조작하는 공격) 가능성과, 인증 절차 없이도 이 API를 호출할 수 있다는 점을 위협 벡터로 짚어냈다고 함.
  25. 두 번째 준비 단계는 샌드박스로, 격리와 재현 가능성 두 가지를 확보하는 게 목적이라고 함.
  26. 신뢰할 수 없는 코드를 돌리거나 모델에게 일부러 익스플로잇(취약점을 실제로 이용해 공격을 성립시키는 코드)을 만들어보게 할 때도 있어서, 데이터 유출이나 운영 환경 오염을 막을 격리가 필요하다고 함. 그래서 외부 통신이 없고 클라우드 자격 증명도 없는 가상머신 안에서 돌려야 한다고 함.
  27. 재현 가능성 쪽에서는 오래된 의존성 때문에 우연히 발견된 버그가 아니도록, 모든 에이전트가 같은 기준 컨테이너에서 시작해야 한다고 함.
  28. 실전에서 대표성 있는 샌드박스를 만드는 일 자체는 꽤 어렵지만 그만큼 값어치가 크다고 함.
  29. 함께 일한 한 팀은, 실제 시스템을 닮은 테스트베드에서 모델이 개념증명(PoC, 취약점이 실제로 작동함을 보여주는 시연 코드)을 터뜨려 진짜인지 확인할 수 있게 한 것이 가장 큰 지렛대였다고 밝혔다고 함.
  30. 오더 서비스 샌드박스는 앱, 포스트그레스 데이터베이스, 레디스 캐시를 담은 도커 이미지 세 개를 연결하고, 그 바깥에 보안 에이전트를 둬 HTTP로 앱을 찔러보게 만든 구조라고 함.
  31. 발견 단계에서 중요한 건 세 가지뿐이고 특별히 새로운 얘기는 아니라고 하며, 첫째는 맥락 엔지니어링으로 글로 적혀 있고 모델에게 공유할 수 있는 정보라면 최대한 다 줘야 취약점 탐지 범위가 넓어지고 오탐률이 줄어든다고 함.
  32. 둘째는 프롬프트를 더 단순하게 쓰는 것으로, 모델이 좋아질수록 프롬프트에서 오히려 문장을 빼야 한다는 걸 발견했다고 함.
  33. 새 모델 버전이 나올 때마다 프롬프트 분량을 절반쯤 줄여왔다고 하며, 요즘 모델에는 "신뢰 경계를 넘어오는 신뢰할 수 없는 데이터가 어디인지 찾아라" 정도만 줘도 잘 추론한다고 함.
  34. 셋째는 모델에게 도구를 주는 것으로, 한 침투 테스트 팀은 API를 호출하고 응답을 확인하고 로그와 소스 코드를 읽는 도구를 모델에게 줬다고 함.
  35. 코드만 읽게 하는 방식은 잘 안 통하고 도구를 돌려 직접 확인하게 해야 하는데, 이렇게 했더니 참양성률이 거의 100%까지 올랐다고 함.
  36. 오더 서비스의 조회 API 코드 다섯 줄을 보여주며 청중에게 취약점을 찾아보라고 함.
  37. 네 번째 줄에서 파이썬 문자열 보간으로 SQL 질의를 만들어 사용자 입력이 그대로 질의문에 흘러 들어가는 SQL 인젝션이라고 확인함.
  38. 이건 비보안 엔지니어가 가장 단순하게 짜기 쉬운 코드고, 지금 모델들은 이런 단순한 문제는 잘 잡아낸다고 함.
  39. 발견 단계에서 후보 100건을 찾았다면 아직 다 확인된 건 아니라고 하며, 다음은 검증 단계라고 함. 머신러닝에 빗대면 발견은 재현율(있는 걸 얼마나 다 찾아내는지)을, 검증은 정밀도(찾아낸 것 중 진짜 비율)를 최적화하는 단계라고 함.
  40. 두 단계를 분리해야 하는 이유는, 발견 에이전트가 자기 결과를 스스로 검증하면 자기 안에서 논쟁하다가 결과를 눌러버려 재현율이 떨어질 수 있어서라고 함.
  41. 검증 에이전트는 독립적이고 적대적이어야 하는데, 독립적이란 발견 에이전트의 추론 과정을 못 보고 취약점 정보만 받는다는 뜻이고, 적대적이란 일단 거짓이라고 가정하고 진위를 가려낸다는 뜻이라고 함.
  42. 이렇게 기준을 높이면 오탐률이 낮아지고, 샌드박스를 미리 갖췄다면 검증 에이전트가 직접 PoC를 터뜨려 확인할 수 있다고 함.
  43. 오더 서비스 예시에서 검증 에이전트는 네 번째 줄이라는 위치 정보만 받고, 새 컨테이너에서 실제로 curl 명령을 실행해 고객 개인정보가 유출되는 걸 직접 확인해 SQL 인젝션을 확정했다고 함.
  44. 발견과 검증으로 재현율과 정밀도를 다 챙겼다면 다음은 분류 단계라고 함. 찾아낸 취약점 중 일부는 실제로 작동은 해도 사업에 미치는 영향이 작을 수 있다고 함.
  45. 경중을 가리지 않고 중간·낮음 등급까지 다 개발자에게 보내면 신뢰를 잃는다고 여러 팀이 전했다며, 지금 가장 부족한 자원은 엔지니어의 주의력이라고 함.
  46. 그래서 이 단계에서는 값싼 규칙이나 모델을 써서 중복을 제거하고 비슷한 것끼리 묶는다고 함.
  47. 심각도는 파급의 크기(시스템 깊숙한 권한까지 미치는지 좁은 범위에 그치는지)와 공격자가 성공시키기까지 거쳐야 할 단계 수 둘 다로 판단한다고 함.
  48. 여기서도 위협 모델이 맥락으로 쓰이는데, 방화벽 같은 보완 통제가 있으면 원래 높음이던 등급이 낮음이 되고, 데이터가 개인정보나 의료정보처럼 민감하면 모델이 중간으로 매긴 걸 높음으로 올려야 할 수 있다고 함.
  49. 오더 서비스 예시에서 에이전트는 파급도 크고 가능성도 높다며 높음 등급을 매겼는데, 사람이 검토한 뒤엔 SQL 인젝션을 막는 애플리케이션 방화벽이 있고 서비스가 인터넷에 노출되지 않는 내부 전용이라는 이유로 가능성을 낮음으로 낮췄다고 함.
  50. 이런 맥락은 코드베이스엔 없고 시스템 설계 문서나 사내 위키 같은 데 흩어져 있어서, 그걸 모델에 줘야 판단이 좋아진다고 함.
  51. 패치 단계에서는 만든 패치를 검증하는 사다리를 오르는데, 우선 원래 PoC가 더는 안 통해야 하고 기존 테스트가 회귀 없이 계속 통과해야 한다고 함.
  52. 더 나아가 새 발견 에이전트가 패치된 코드를 다시 공격해보게 해서 패치가 충분한지 확인할 수 있고, 이런 피드백을 주면 패치 품질이 크게 좋아진다고 함. 이를 생성적 검증자 루프라 부르고, 마지막엔 사람이 병합 전에 패치를 확인한다고 함.
  53. 오더 서비스 패치는 첫 번째 변경에서 변수를 파이썬 문자열 보간 밖으로 빼는 한 줄짜리 수정으로 SQL 인젝션을 없앴다고 함.
  54. 두 번째 변경에서는 코드만 고치는 게 아니라 같은 문제가 다음 스캔에서 다시 걸리지 않도록 애플리케이션 방화벽과 내부 전용이라는 보완 통제까지 규칙으로 남겨 루프를 닫는다고 함.
  55. 하네스와 루프를 만드는 건 매번 드는 운영비용(OpEx)이지만, 루프를 닫아두면 돌릴 때마다 나아지는 자본적 자산(CapEx)이 된다고 함.
  56. 여섯 단계를 정리하면 위협 모델은 맥락을, 샌드박스는 격리와 재현성을 주는 기본 토대이고, 나머지 네 단계는 재현율·정밀도·순위·루프 닫기로 이어지는 평범한 머신러닝 파이프라인처럼 보인다고 함.
  57. 전 상사가 했던 말을 인용해, 비기술적 문제가 기술적 문제보다 한 자릿수는 더 어렵다고 하며 조직 쪽 병목으로 넘어감.
  58. 입력이 한두 자릿수 늘어났을 때 스캔용 하네스 자체는 엔지니어링과 컴퓨팅, 돈을 더 쓰면 되는 문제라 진짜 문제가 아니고, 정말 늘어나지 않는 건 사람의 주의력이라고 함.
  59. 제품 엔지니어와 보안 엔지니어가 무엇을 높음·치명 등급으로 볼지 합의하지 못하면 다 같이 모여 규칙을 정리해 적어둬야 한다고 함.
  60. 위협 모델은 지금 다 사람들 머릿속에만 있으니, 모델이든 사람이든 인터뷰해서 문서로 만들어야 에이전트가 그걸 쓸 수 있다고 함.
  61. 패치를 완전히 자동으로 검토하는 회사는 아직 많이 못 봤다고 함.
  62. 조직 병목 대응책 첫째는 취약점 라우팅으로, 한 달에 십여 건이면 사람이 손수 이메일을 보내고 지라(Jira, 업무 이슈를 등록·추적하는 도구) 티켓을 만들면 되지만 수백 건이 되면 코드 소유자나 서비스 담당자에게 자동으로 보내는 정도로도 충분하고 굳이 모델을 루프에 넣을 필요는 없다고 함.
  63. 둘째는 심각도 기준 맞추기로, 제품 엔지니어와 보안 엔지니어(레드팀·블루팀)가 무엇이 높음인지 합의 못 하는 게 가장 어려운 지점이고 사업 맥락을 많이 요구한다고 함. 한 번 모여 확정해서 적어두면 그다음부터는 에이전트에 넘길 수 있다고 함.
  64. 셋째는 패치 처리 역량으로, 요즘은 손으로 코드를 짜는 사람이 드물지만 취약점만 받아서 LLM(대형언어모델) 도움을 받아도 직접 패치를 구현하는 건 여전히 부담이라고 함.
  65. 그래서 AI가 패치를 생성하고 사람이 루프에서 검증하며, 패치를 다시 만들고 다시 공격해보는 방향으로 가야 한다고 함.
  66. 마지막으로 기억할 세 가지 중 첫째는 지금 당장 시작하되, 오픈소스 의존성처럼 편한 곳부터 시작하라는 것이라고 함.
  67. 둘째는 학습 곡선을 오르는 법으로, 처음부터 자동화를 노리지 말고 클로드 코드나 즐겨 쓰는 IDE로 손수 대화형으로 시작해 어디서 막히는지, 어떤 맥락이 빠졌는지, 정밀도가 어디서 낮아지는지 배우라고 함.
  68. 셋째는 스캔만 노리지 말라는 것으로, 병목은 스캔이 아니라 검증·분류·패치와 그걸 둘러싼 조직 프로세스 전체라고 함.
  69. 코드베이스를 스캔하고 패치 같은 결과물을 검증하는 도구, 블로그, 대화형 스킬과 자율 하네스를 담은 오픈소스 저장소 등 참고 자료를 안내하며 발표를 마침.

한줄 코멘트. 파이어폭스 월간 패치 20배 급증과 앤트로픽의 6200건 고·치명 취약점 스캔이 같이 말해주는 건, 발견은 이미 상품화됐고 이제 조직이 감당해야 할 건 검증·분류·패치라는 사람 쪽 병목이라는 것임.

  1. 발표자는 마이크로소프트 소속 리엄 햄튼(Liam Hampton)이며, 컨퍼런스 마지막 날 VS Code에서 에이전트를 굴리는 법을 이야기하는 세션이라고 밝힘.
  2. 앞선 발표자가 에이전트의 인지 부하를 지적했는데 그 말이 맞다며, 지금은 CLI(명령줄 인터페이스)·터미널·챗창·다른 에디터 등 사방에서 에이전트가 쏟아지고 있다고 짚음.
  3. 그런데도 원샷 프롬프트(한 번의 지시로 앱을 통째로 완성해 주길 기대하는 태도) 하나면 문제를 다 풀 수 있다고 믿는 개발자를 여전히 많이 본다고 함. 절대 그렇지 않다고 잘라 말함.
  4. 비즈니스 쪽에서는 결국 투자수익률과 생산성이 얼마나 올랐는지를 묻는데, AI 인프라·툴링·서비스에 돈을 쓰고도 아직 그 효과를 제대로 못 거두고 있다고 지적함.
  5. 그래서 토큰(모델이 텍스트를 처리하는 최소 단위) 지출을 아끼는 방향으로 도구와 서비스를 다뤄야 한다고 강조함.
  6. 예로 든 것이, 링크드인에서 본 어떤 저장소인데 챗봇이 해적 말투로 답하게 만들어 토큰 지출을 줄이는 방식이 인기를 끌고 있다고 함. 사람들이 토큰 비용을 아끼려고 이런 재미있는 방법까지 찾아낸다고 함.
  7. 이번 발표는 깃허브 코파일럿(GitHub Copilot) 에이전트를 중심으로 다루지만, 다른 AI 에이전트에도 똑같이 적용되는 내용이라고 밝힘.
  8. 코파일럿 에이전트가 워크스페이스 안에서 실제로 무엇에 접근할 수 있는지, VS Code와 CLI 안에서 어떻게 쓰이는지를 살펴보겠다고 함.
  9. 지금 쓸 수 있는 에이전트를 셋으로 나눔. 로컬 에이전트, 백그라운드 에이전트, 클라우드 에이전트임.
  10. 로컬 에이전트는 VS Code 안에서 로컬 머신에 돌아가는 방식임. 클로드(Claude)든 다른 서비스든, 원격 모델이든 로컬에 직접 올린 모델이든 상관없이 사람과 나란히 붙어 손을 많이 대는 방식이라고 함.
  11. 백그라운드 에이전트는 깃허브 코파일럿 CLI로 쓰며 VS Code 안에서도 접근할 수 있는데, 격리된 방식으로 돌아간다고 함. 실제로 깃 워크트리(Git worktree)를 쓴다고 밝힘.
  12. 깃 워크트리는 작업 중인 워크스페이스 안의 별도 폴더에 매핑된 브랜치임. 자기 코드와 브랜치를 따로 떼어 둔 하위 디렉터리 같은 것이라고 쉽게 설명함.
  13. 클라우드 에이전트는 조직 바깥으로 아주 빠르게 확장하고 깃허브의 클라우드 자원을 그대로 끌어다 쓰는 방식이라, 직접 손대고 싶지 않은 작업에 쓴다고 함.
  14. 로컬 에이전트는 테스트를 짤 때 씀. 코드베이스를 제대로 이해하고 세세한 부분까지 직접 파고들고 싶을 때라고 함.
  15. 백그라운드 에이전트는 반반 정도만 관여하고 싶을 때 씀. 프런트엔드 UI를 새로 만드는 일처럼 돌아가는 상황은 알고 싶지만, 완전히 손을 떼기도 계속 오가며 손대기도 싫은 작업에 맞는다고 함.
  16. 클라우드 에이전트는 주로 문서 작성에 씀. 문서 쓰는 일을 싫어한다며, 저장소를 오픈소스 친화적으로 만들거나 README를 스킬로 작성하는 일을 통째로 맡긴다고 함.
  17. 결국 VS Code를 AI 에이전트의 단일 진입점으로 삼겠다는 게 핵심이라고 함. 서드파티·백그라운드·로컬·원격 진입점을 전부 한곳에 모은 셈이라고 함.
  18. 개발자가 지금 어떤 상황에 있는지 이해하고, 그 인지 부하를 최대한 줄여 주는 방향으로 에이전트를 쓰게 하는 게 목표라고 밝힘.
  19. 이후 라이브 시연 대신 미리 녹화한 영상을 보여주겠다며, 시간이 부족해 실시간으로는 다 못 할 것 같다고 함.
  20. 시연은 아주 단순한 파이썬(Python) CRUD(만들기·읽기·수정·삭제) 애플리케이션으로 시작함. 상품을 등록·조회·수정·삭제하는 간단한 스토어이고 디자인은 별로 안 예쁘다고 함.
  21. 여기에 프런트엔드 UI를 새로 붙이고 싶어서, 깃허브에 올려 둔 이슈 25번을 가리켜 "이 이슈에 대한 해법을 요약하고 계획을 세워라"라고 CLI 백그라운드 에이전트에 시킴.
  22. 이 작업엔 오토파일럿(Autopilot)도 함께 씀. 아직 미리보기 단계인 기능인데, 도구 호출을 여러 번 해야 할 때 매번 묻지 않게 해 준다고 함. 편리하지만 위험할 수 있어 조심해야 한다고 경고함.
  23. 계획이 마음에 들면 "이제 시작하되, 풀 리퀘스트(PR, 코드 변경 요청)를 올리기 전에 멈춰서 내가 로컬에서 먼저 테스트하게 해 달라"고 지시함. 오토파일럿은 원래 자동으로 PR까지 올리기 때문이라고 함.
  24. 백그라운드 에이전트가 일하는 동안 새 채팅창을 열어 클라우드 에이전트를 띄움. 저장소가 오픈소스 친화적이지 않다며 README와 기여 가이드라인 등 필요한 파일을 다 만들어 달라고 맡김.
  25. 개발자 본인은 그사이 코드베이스를 직접 둘러보다가 테스트가 하나도 없다는 걸 발견하고, VS Code에 이미 준비돼 있던 커스텀 에이전트(특정 작업에 맞춰 미리 설정해 둔 전용 에이전트)를 찾아냄.
  26. 이 커스텀 에이전트는 이 파이썬 애플리케이션의 테스트 케이스를 어떻게 짜야 하는지 알려주는 용도로 만들어져 있었다고 함.
  27. 화면 맨 아래에서 로컬(local)을 클릭해 로컬 에이전트를 새로 띄움. 모델은 클로드 오퍼스 4.6, 추론 강도는 미디엄으로 골랐고 빠르게 처리되길 원해서라고 함.
  28. 이 시점에 로컬 에이전트와 계속 왔다 갔다 하며 손대는 동시에, 원격(클라우드) 에이전트가 문서를 만들고 백그라운드 에이전트가 새 프런트엔드를 만드는 걸 같이 지켜보고 있었다고 함.
  29. 로컬 에이전트가 테스트 코드를 짜고 직접 돌려서 통과시키는 걸 확인함. 그런데 코드를 살펴보다 에러 처리가 허술하다는 것도 눈에 띔.
  30. 그래서 라우트(route, API가 요청을 받는 경로)의 에러 처리를 고치고 테스트도 같이 갱신해 달라고 다시 지시함. 로컬 에이전트와는 이렇게 계속 주고받으며 일했다고 함.
  31. 그사이 다른 에이전트들 상태도 확인함. 코파일럿이 코드를 훑는 과정을 보여주는데, 영상을 빠르게 돌린 게 아니라 실제로 이 정도 속도로 진행됐다고 밝힘.
  32. 백그라운드 에이전트가 작업을 끝냈고, 로컬 에이전트가 짠 테스트도 통과해서 그쪽도 끝났음을 확인함.
  33. VS Code 안의 풀 리퀘스트 확장을 열어 보니 이미 PR 하나가 올라와 있었다고 함. 이는 앞서 다른 세션에서 만든 것이고, 채팅에서 돌던 클라우드 에이전트는 시간이 더 걸리고 있었다고 함.
  34. 마지막으로 백그라운드 에이전트가 만든 새 프런트엔드를 확인함. 앞서 PR을 올리기 전에 멈춰서 테스트 방법을 알려달라고 시켰던 참임.
  35. 에이전트가 알려준 테스트 방법이 틀렸다고 지적하며, "이건 깃 워크트리에서 돌고 있는데 어떻게 실행하냐"고 되물음. 여전히 반반 정도만 손을 대는 방식이라고 함.
  36. 깃 워크트리로 생성된 새 디렉터리로 들어가 파이썬 애플리케이션을 직접 실행해 보니, 기존 단일 디렉터리 버전과는 완전히 다른 모습이 됐다고 함.
  37. 포트 충돌이 한 번 나서 잠깐 걸렸지만 곧 해결하고, 새로 만들어진 상품 데모 화면을 열어 확인함.
  38. 이렇게 한 코드베이스에서 문제 세 가지를 서로 다른 에이전트 세 개가 동시에 해결한 셈이라고 정리함. 테스트는 로컬 에이전트, 프런트엔드는 백그라운드 에이전트, 문서는 클라우드 에이전트가 맡았다고 함.
  39. 로컬 에이전트를 쓴 건 손수 확인하며 사람이 개입하고 싶었기 때문이고, 백그라운드 에이전트는 크고 번거로운 작업이라 세부는 신경 쓰기 싫었기 때문, 클라우드 에이전트는 아예 다 맡기고 싶었기 때문이라고 구분함.
  40. 클라우드 에이전트가 실제로 어떻게 돌아가는지 자주 받는 질문이라며 설명함. 깃허브 액션즈(GitHub Actions) 위에서 돌고, 격리된 환경이라 안전하다고 함.
  41. 맥락은 MCP(모델 컨텍스트 프로토콜, 에이전트가 외부 도구·데이터에 표준화된 방식으로 접속하게 해 주는 규격) 서버로 확장한다고 함. 깃허브 MCP 서버와 플레이라이트(Playwright) MCP 서버에 접근할 수 있다고 함.
  42. 그래서 스크린샷을 곁들인 자동 프런트엔드 테스트까지 가능하고, 워크플로도 직접 짤 수 있다고 함.
  43. 네트워크 방화벽으로 접근을 화이트리스트로 제한해 두고, 메인 브랜치에는 접근 권한을 아예 주지 않아 직접 푸시할 수 없게 막아 뒀다고 함. 그래서 안전하게 쓸 수 있다고 강조함.
  44. 이 개념들은 깃허브 코파일럿뿐 아니라 다른 AI 에이전트에도 똑같이 적용된다고 다시 짚음. 커스텀 인스트럭션으로 에이전트 행동을 정의하고, 오늘 시연에 쓴 것 같은 커스텀 에이전트로 특정 문제를 맡길 수 있다고 함.
  45. 프롬프트 파일과 에이전트 스킬(agent skills)도 있는데, 스킬은 기존의 agents.md보다 더 새로운 방식이라고 소개함. 매주 새로운 게 나온다고 덧붙임.
  46. VS Code로 돌아가 깃허브 코파일럿 챗 패널의 톱니바퀴 아이콘을 누르면, 커스텀 테스트 에이전트, 애스크(ask)·익스플로어(explore)·플랜(plan) 같은 내장 에이전트까지 한자리에서 볼 수 있다고 함.
  47. 이 모달(화면 위에 뜨는 설정창) 안에는 PR 코멘트에 답하기, 풀 리퀘스트 만들기 같은 스킬도 미리 준비돼 있고, 직접 열어서 고칠 수도 있다고 함.
  48. 인스트럭션 파일, 내장 프롬프트, 훅(특정 시점에 자동으로 실행되는 동작), MCP 서버까지 이 모달 하나에서 전부 관리하는 통제판 역할을 한다고 설명함.
  49. 이 통제판은 VS Code·코파일럿에만 갇혀 있지 않고 서드파티도 지원해서, 클로드 관련 플러그인·훅·인스트럭션·스킬도 같은 자리에서 다룰 수 있다고 함.
  50. 이런 커스터마이징을 직접 만져 보고 싶다면 어썸 코파일럿(Awesome Copilot)이라는 오픈소스 프로젝트를 쓰라고 권함. 주소는 aka.ms/awesomecopilot이라고 함.
  51. 이름은 코파일럿이지만 다른 AI 도구에도 그대로 가져다 쓸 수 있고, 이 프로젝트를 MCP 서버로도 감싸 놓아서 워크플로 안에서 바로 붙여 쓸 수도 있다고 함.
  52. MCP를 모르는 사람을 위해 다시 설명함. LLM(거대언어모델)이나 챗 커스터마이징을 확장하는 방식으로, 애저(Azure)·GCP·AWS 자원과 대화하려면 MCP를 거치면 되고 대개 인증으로 잠겨 있다고 함.
  53. 플레이라이트나 마이크로소프트 런(Microsoft Learn) 같은 문서용 MCP처럼, 인증 없이 쓸 수 있는 무료·공개 서버도 있다고 함.
  54. 마무리하며 VS Code가 AI 에이전트의 단일 진입점이라는 점을 다시 강조함. 서드파티 플러그인과 퍼스트파티 플러그인, MCP 전체 스펙 지원을 갖췄다고 정리함.
  55. 챗 커스터마이징과 깃허브 코파일럿 CLI 세션 연결까지 전부 한 흐름 안에 들어와 있다고 밝힘. 시간이 1분도 안 남았다며 청중의 워크플로를 세션 뒤에 직접 듣고 싶다고 하고 발표를 마침.

한줄 코멘트. 로컬·백그라운드·클라우드로 손 대는 정도를 나눈 틀은 쓸 만한데, 시연에서 정작 백그라운드 에이전트가 알려준 테스트 방법이 틀려 결국 사람이 다시 개입했다는 대목이 이 구분의 한계를 보여줌.

  1. 발표자는 빌 첸(Bill Chen)과 브라이언 피오카(Brian Fioca)로, 오픈AI(OpenAI)의 어플라이드 AI 스타트업팀에서 코딩 에이전트를 만드는 일을 한다고 밝힘.
  2. 코딩 에이전트가 지난 1년 동안 폭발적으로 커졌고, 그 밑바탕인 하네스(harness, 모델을 감싸 도구를 쓰고 작업을 수행하게 만드는 실행 틀)의 기반이 계속 흔들리고 있다고 함.
  3. 코딩을 다루는 이유는 소프트웨어 개발이 문제 해결의 보편적인 매체이고, 코딩 에이전트가 얼마나 발전했는지가 AGI(범용 인공지능)에 얼마나 가까워졌는지를 보여주는 신호이기 때문이라고 함.
  4. 기반이 빠르게 바뀌다 보니 새 모델이 나올 때마다 그 위에 얹은 에이전트를 다시 만들어야 했고, 오늘은 그 문제를 피해가는 법을 이야기한다고 함.
  5. 발표 순서는 코딩 에이전트의 해부(모델·하네스), 코드엑스(Codex)를 만들며 배운 교훈, 사용자들이 코드엑스를 자기 제품에 쓰는 패턴, 코드엑스의 앞날 순이라고 밝힘.
  6. 코딩 에이전트는 사용자 인터페이스, 모델, 하네스 세 부분으로 이뤄진다고 설명함.
  7. 인터페이스는 CLI(명령줄 도구)나 통합 개발 환경(IDE), 클라우드나 백그라운드 에이전트가 될 수 있다고 함.
  8. 모델은 어제 나온 GPT-5.1 코드엑스 맥스(Codex Max)나 GPT-5.1 계열, 다른 회사 모델을 뜻한다고 함.
  9. 하네스는 모델과 가장 직접 맞닿는 부분으로, 프롬프트와 도구를 코어 에이전트 루프 안에 묶어 모델의 입출력을 다루는 다발이라고 정의함.
  10. 이번 발표는 이 하네스에 초점을 맞춘다고 밝힘.
  11. 하네스는 모델이 사용자·코드와 대화하고 도구로 행동을 수행하는 접점 표면이라고 설명함.
  12. 어떤 제품에서는 하네스가 곧 그 제품의 핵심 경쟁력이 되기도 하지만, 좋은 하네스를 만드는 일 자체가 상당히 어렵다고 함.
  13. 첫 번째 어려움은 낯선 도구다. 새로 만든 커스텀 도구를 모델이 훈련 중에 한 번도 못 봤을 수 있고, 봤더라도 그 모델과 습관에 맞게 프롬프트를 따로 조정해야 한다고 함.
  14. 두 번째 어려움은 지연 시간이다. 모델이 얼마나 오래 생각하는지, 무엇을 생각하지 말라고 지시할지, 생각 중인 모델의 상태를 사용자에게 어떻게 보여줄지를 정해야 한다고 함.
  15. 세 번째 어려움은 컨텍스트 창(모델이 한 번에 참고하는 정보 범위)과 압축(compaction) 관리다. 코드엑스 맥스는 이를 기본으로 처리해 직접 만들지 않아도 된다고 함.
  16. 네 번째 어려움은 API(응용 프로그램 프로그래밍 인터페이스) 자체가 계속 바뀐다는 점이다. completions와 responses처럼 API 종류가 여럿이라 모델이 어떤 API로 최대 지능을 끌어낼 수 있는지 알아야 한다고 함.
  17. 모델을 하네스에 맞추는 데는 프롬프트 작업이 상당히 필요하고, 모델이 훈련된 방식에는 부작용이 따른다고 함.
  18. 이를 "지능 더하기 습관"이라는 틀로 설명함. 지능은 모델이 어떤 언어와 프레임워크를 잘 다루는지를, 습관은 모델이 문제를 풀 때 몸에 밴 방식을 뜻한다고 함.
  19. 오픈AI는 모델에게 계획을 세우고, 주변을 둘러보며 맥락을 모으고, 코드를 쓰기 전에 문제를 생각하고, 끝에는 결과물을 테스트하는 습관을 훈련시켰다고 밝힘.
  20. 이런 습관을 파악하는 감각이 곧 좋은 프롬프트 엔지니어가 되는 길이라고 함.
  21. GPT-5를 낼 때, 다른 모델용으로 짠 프롬프트를 그대로 가져와 GPT-5의 하네스에 넣은 사람이 많았다고 함.
  22. 다른 모델이 원래 하지 않던 습관을 오픈AI 모델은 이미 갖고 있어서, 코드 수정 전 파일 하나하나를 다 살펴보라는 지시를 받으면 모델이 필요 이상으로 꼼꼼해져 시간이 오래 걸렸다고 함.
  23. 발표자가 직접 모델에게 "왜 이렇게 오래 걸렸냐, 더 빠르게 하려면 지시를 어떻게 바꿔야 하냐"고 물었더니, "모든 걸 다 보라고 시켜서 그게 시간을 잡아먹었다"고 모델이 답했다고 함.
  24. 결론은 모델이 원래 하던 행동을 그대로 하게 두고 과하게 프롬프트하지 않을수록 성능이 더 좋아진다는 것이라고 함.
  25. 모델과 하네스를 함께 만들면 모델의 이런 습관을 만드는 쪽에서부터 이미 다 알고 있다는 이점이 있고, 그래서 코드엑스는 모델과 하네스를 하나로 합친 것이라고 함.
  26. 코드엑스는 코드를 다루는 모든 곳에서 쓰라고 만든 에이전트로, VS Code 플러그인·CLI로 존재하고 챗GPT(ChatGPT)나 휴대폰에서 클라우드로도 부를 수 있다고 함.
  27. 프롬프트 한 줄과 계획에서 시작해 실행 가능한 코드로 바꾸고, 저장소(repo)를 돌아다니며 파일을 고치고, 명령을 실행하고 작업을 처리한다고 설명함.
  28. 슬랙(Slack)에서 부르거나 깃허브(GitHub)에서 PR(코드 변경 요청) 리뷰를 맡길 수도 있다고 함.
  29. 코드엑스의 하네스가 감당해야 하는 일은 생각보다 훨씬 많다고, 코드엑스 팀원에게 직접 확인했다고 밝힘.
  30. 병렬 도구 호출과 스레드 병합, 샌드박싱·프롬프트 전달·권한·포트 관리 같은 보안 문제까지 다뤄야 한다고 함.
  31. 압축(compaction)도 언제 걸지, 언제 다시 넣을지, 그 과정에서 캐시를 어떻게 최적화할지 결정해야 하는 복잡한 일이라고 함.
  32. MCP(모델이 외부 도구·데이터에 붙는 연결 규격) 지원을 위한 배관 작업과, 이미지를 모델에 보내기 전에 어느 해상도로 압축할지까지 하네스가 챙겨야 한다고 함.
  33. 오픈AI는 이 기능들을 코드엑스 하나에 묶어, 새 문제를 만나면 스스로 도구를 안전하게 만들어 푸는 에이전트로 만들었다고 함.
  34. 코드엑스는 터미널을 위한 컴퓨터 사용(computer use) 에이전트이기도 하다고 함. 브라우저와 그래픽 인터페이스가 나오기 전에는 명령줄로 컴퓨터를 다뤘던 것과 같은 방식이라고 설명함.
  35. 명령줄과 파일로 표현할 수 있는 작업이면 코드엑스가 처리할 수 있어서, 코딩이 아니어도 된다고 함.
  36. 예로 데스크톱 사진을 폴더별로 정리하거나, 폴더 안 대용량 CSV(쉼표로 값을 구분한 파일 형식) 파일들을 분석하는 데이터 분석 작업도 코드엑스로 할 수 있다고 함.
  37. 코드엑스를 자기 에이전트 안에 넣어 쓰는 패턴 하나는 하네스를 새로운 추상화 층으로 삼는 것이라고 소개함.
  38. 이렇게 하면 모델이 업그레이드될 때마다 프롬프트와 도구를 다시 최적화하는 일을 신경 쓰지 않아도 된다고 함.
  39. 그럼 그냥 래퍼(wrapper) 아니냐는 동료의 반문에 발표자는 동의하지 않는다고 밝힘. 모델 위에 래퍼만 얹는 건 인프라 층이 가진 가치를 축소해 보는 관점이라고 함.
  40. 하네스를 넘겨받으면 제품 차별화에 노력을 쏟을 수 있고, 가치는 대부분 거기서 나온다고 설명함.
  41. 코드엑스는 SDK(소프트웨어 개발 키트)로도 제공돼, 타입스크립트(TypeScript) 라이브러리나 파이썬(Python) exec로 프로그램에서 직접 부를 수 있다고 함.
  42. PR의 병합 충돌을 처리해주는 깃허브 액션(GitHub Action)도 붙일 수 있다고 함.
  43. 에이전트 SDK에 코드엑스를 더하고 자기 제품으로 이어지는 MCP 커넥터를 주면, 챗봇에 도구를 준 다음 그 챗봇이 갖고 있지 않은 도구를 스스로 만들게 하는 단계로 나아간다고 함.
  44. 이 방식으로 고객마다 API 수준의 플러그인 커넥터를 그 자리에서 스스로 써주는 엔터프라이즈 소프트웨어를 만들 수 있는데, 원래 전문 서비스 팀이 손으로 하던 일이라고 함.
  45. 젯(Zed)은 코드엑스를 자기 레이어 안에 감싸고 IDE 인터페이스만 붙여, 하네스를 계속 따라잡는 일 대신 코드 에디터 자체를 잘 만드는 데 집중한다고 함.
  46. 깃허브는 코드엑스와 직접 연동하는 SDK를 썼고, 이 SDK는 CI/CD(지속적 통합·배포) 파이프라인 제어나 자기 에이전트와 직접 상호작용하는 데도 쓸 수 있다고 함.
  47. 커서(Cursor) 팀과는 도구를 모델이 훈련받은 분포에 맞추고, 하네스를 오픈소스로 공개한 코드엑스 CLI 구현에 맞춰 성능을 끌어올리는 작업을 같이 했다고 함.
  48. 코드엑스 CLI 구현은 전부 공개돼 있어 저장소를 포크해 직접 써도 된다고 함.
  49. 코드엑스는 아직 나온 지 1년도 안 됐고, 어제 코드엑스 맥스까지 나오면서 상황이 빠르게 바뀌고 있다고 함.
  50. 코드엑스 맥스는 사용량 기준으로 가장 빨리 크는 모델이 됐고, 주당 수십조 개 토큰을 처리하는데 이는 데브데이(Dev Day) 이후 두 배로 늘어난 수치라고 함.
  51. 모델이 앞으로 더 나아질 것을 전제로 만드는 게 맞다고, 감독 없이도 훨씬 긴 시간 단위의 작업을 해낼 수 있게 될 것이라고 함.
  52. 새 모델이 나올수록 신뢰의 한계선이 올라가서, 6개월 전보다 지금 훨씬 어려운 일을 모델에 맡기게 됐고 이 흐름은 계속될 것이라고 함.
  53. 앞으로는 방대한 코드베이스와 비표준 라이브러리, 소스가 공개되지 않은 환경, 기존 템플릿과 관행에 맞추는 일이 관건이 될 것이라고 함.
  54. SDK도 이런 모델 능력에 맞춰, 모델이 스스로 배우고 실수를 반복하지 않으며 터미널로 문제를 푸는 에이전트에 더 많은 표면을 내주는 쪽으로 진화할 것이라고 함.
  55. 하네스는 복잡하고 새 모델이 나올 때마다 유지보수에 손이 많이 가는데, 오픈AI가 그 하네스를 코드엑스 안에 만들어뒀으니 그대로 쓰거나 소스를 보고 코딩 밖의 일에도 써보라고 마무리함.

한줄 코멘트. 하네스를 판다는 건 결국 프롬프트 튜닝을 대신 해준다는 뜻이고, 그 값어치를 하려면 모델이 어떤 습관으로 훈련됐는지까지 같이 쥐고 있어야 한다는 게 코드엑스와 다른 래퍼의 차이임.

  1. 발표자는 앤트로픽(Anthropic) 소속 기술 스태프이자 클로드 코드(Claude Code) 창시자인 보리스 체르니(Boris Cherny)라고 자신을 소개함.
  2. 청중 대부분이 이미 클로드 코드와 에이전트형 코딩에 익숙해서 무슨 얘기를 할지 고민했다며, 먼저 크게 줌아웃했다가 다시 줌인하겠다고 함.
  3. 핵심 요지부터 말함. 모델은 지수적으로 좋아지고 있는데 제품은 그 속도를 못 따라가고 있다고 함.
  4. 이렇게 좋은 코딩 모델에 어울리는 제품이 훨씬 더 많이 나올 수 있다고 보는데, 지금은 최소한의 것만 만들고 있다고 함.
  5. 클로드 코드가 일부러 무의견(unopinionated, 제품 방향을 미리 정하지 않는 태도)을 유지하는 이유도 여기 있음. 제품이 어떤 모습이어야 하는지 아직 모르기 때문이라고 함.
  6. 클로드 코드 설치법을 안내함. 공식 사이트에서 내려받거나 npm 명령 한 줄로 설치할 수 있다고 함.
  7. 어제부터 클로드 프로(Claude Pro) 요금제에서도 클로드 코드를 쓸 수 있게 됐고, 클로드 맥스(Claude Max)도 지원한다고 함.
  8. 프로그래밍의 역사를 짚음. 1930~40년대엔 스위치보드를 물리적으로 조작하는 일이었고 소프트웨어라는 개념 자체가 없었다고 함.
  9. 1950년대에 펀치카드가 등장함. 자신의 할아버지가 옛 소련 최초의 프로그래머 중 한 명이었고, 어머니가 어릴 적 할아버지가 집에 들고 온 펀치카드 더미에 크레용으로 낙서했던 이야기를 들려준다고 함.
  10. 1950년대 말부터 어셈블리 같은 고급 언어가 등장하며 프로그래밍이 하드웨어에서 펀치카드를 거쳐 소프트웨어로 옮겨갔다고 함.
  11. 이후 코볼(Cobol), 타입 언어, C++로 이어지고 90년대 초엔 새로운 언어 가족이 폭발적으로 늘었다고 함. 하스켈(Haskell) 계열, 자바스크립트, 자바, C 계열의 진화, 파이썬이 이때 자리 잡았다고 함.
  12. 요즘은 눈을 가늘게 뜨고 보면 언어들이 다 비슷해 보인다며, 추상화 수준이 서로 수렴했다고 함. 타입스크립트(TypeScript)를 쓰면 러스트(Rust)를, 그건 다시 스위프트(Swift)나 고(Go)를 쓰는 것 같다고 함.
  13. 프로그래밍 언어의 UX(사용자 경험)도 함께 진화했다고 함. 1950년대엔 타자기로 펀치카드에 구멍을 뚫는 게 프로그래밍이었다고 함.
  14. 최초의 텍스트 에디터가 뭔지 청중에게 묻고, 그전엔 IBM 029 같은 천공기가 당시의 "맥북"이었다고 함. 지금도 박물관에서 볼 수 있다고 함.
  15. 최초의 텍스트 에디터는 벨 연구소(Bell Labs)의 켄 톰프슨(Ken Thompson)이 만든 에드(Ed)라고 함. 지금도 유닉스(Unix) 시스템에 기본으로 들어 있어서 맥북에서 바로 실행해볼 수 있다고 함.
  16. 에드는 50년 전에 만들어졌는데 커서도 스크롤백도 자동완성도 없이, 종이에 인쇄하던 텔레타이프 기계에 맞춰 만든 가장 단순한 에디터였다고 함.
  17. 빔(Vim)과 이맥스(Emacs)도 큰 혁신이었고, 1980년 스몰토크(Smalltalk)-80은 프로그래밍 소프트웨어 최초의 그래픽 인터페이스였다고 함.
  18. 스몰토크-80은 1980년에 이미 라이브 리로드(코드를 고치면 화면이 바로 갱신되는 기능)가 작동했다며, 지금 리액트(React)로 그걸 구현하려면 여전히 애먹는다고 지적함.
  19. 1991년 비주얼 베이직(Visual Basic)이 그래픽 패러다임을 주류로 끌고 온 첫 코드 에디터였다고 함. 그전까진 빔 같은 텍스트 기반 에디터가 여전히 인기였다고 함.
  20. 이클립스(Eclipse)는 정적 분석(코드를 실행하지 않고 기호를 색인·순위화하는 방식)으로 자동완성을 주류에 올렸다고 함. IDE(통합 개발 환경) 최초의 대형 서드파티 생태계이기도 했다고 함.
  21. 이건 AI 기반 자동완성과는 다르다고 짚음. 깃허브 코파일럿(Copilot)이 한 줄, 이어서 여러 줄짜리 자동완성으로 다시 한 번 도약을 만들었다고 함.
  22. 데빈(Devin)이 처음으로 자연어를 쓰면 그게 코드가 되는 새로운 추상화를 주류에 올린 IDE였다고 함. 수십 년간 다들 시도했지만 데빈이 처음으로 통했다고 함.
  23. 검증 방식도 함께 진화했다고 함. 손으로 결과물을 눈으로 확인하던 수동 디버깅에서 시작됐다고 함.
  24. 지금은 퍼징(무작위 입력으로 버그를 찾는 테스트)이나 넷플릭스의 카오스 테스트(일부러 장애를 일으켜 복원력을 확인하는 테스트) 같은 확률적 검증으로 옮겨갔다고 함.
  25. 이런 흐름 위에서 클로드 코드는 터미널에서 시작해 모델에 최대한 낮은 수준으로, 그러면서도 쓸 만하게 접근하게 만드는 방식을 택했다고 함.
  26. 무의견을 유지하고 길을 비켜주려는 이유 중 하나는 앤트로픽이 모델 회사라서 사람들이 모델 자체를 경험하길 바라기 때문이라고 함.
  27. 다른 하나는 정말로 올바른 UX가 뭔지 모르기 때문이라고 함.
  28. 그래서 클로드 코드는 일부러 단순하고 일부러 범용적으로 만들었다고 함. 사용자가 가진 모든 도구를 쓸 수 있다는 걸 보여주는 데 목적이 있다고 함.
  29. 두 번째 요지로 넘어가서, 모델은 계속 좋아지기만 한다고 함. 이걸 비터 레슨(the Bitter Lesson, 더 일반적인 방법이 결국 이긴다는 리처드 서튼의 유명한 교훈)이라 부르며 액자로 만들어 벽에 붙여뒀다고 함.
  30. 이 교훈의 요지는 더 일반적인 모델이 항상 이긴다는 것이라고 함. 모델의 능력도, 모델 주변의 거의 모든 것도 지수적으로 늘어나는데 그중에서도 더 범용적인 쪽이 대개 이긴다고 함.
  31. 그래서 클로드 코드는 제품 하나에 쓰는 방법은 여러 개라는 전략을 택했다고 함. 그중 하나가 터미널 제품이라고 함.
  32. 터미널에서 클로드 코드를 설치하고 claude만 입력하면 어디서나 돌아간다고 함. 아이텀2(iTerm2), WSL, SSH·tmux 세션, VS Code나 커서(Cursor)의 터미널까지 다 지원한다고 함.
  33. IDE 안에서 실행하면 조금 더 많은 일을 한다고 함. 터미널에 인라인으로 뜨던 diff(변경 내역)가 IDE 안에서 크고 보기 좋게 뜨고 진단 정보도 흡수한다고 함.
  34. 이건 커서나 윈드서프(Windsurf)만큼 다듬어져 있지 않다고 인정하면서도, 둘 다 매일 쓰는 좋은 제품이라고 함. 모델을 있는 그대로 낮은 수준에서 경험하게 하려고 일부러 최소한만 만든 거라고 함.
  35. 몇 주 전 깃허브에서 클로드를 쓸 수 있게 됐다고 발표함. 슬래시 명령으로 깃허브 앱을 설치하고 저장소를 고르면 그 저장소에서 클로드를 바로 실행할 수 있다고 함.
  36. 이 실행은 사용자 본인의 컴퓨팅 자원 위에서 돌고, 데이터는 앤트로픽으로 넘어가지 않고 사용자 쪽에 남는다고 함.
  37. 설정에는 몇 분이면 충분하다고 함. 이것도 아직 뭐가 맞는 UX인지 배우려고 일부러 최소한으로 만든 것이지만, 본인도 매일 실무에 쓸 만큼 유용하다고 함.
  38. 가장 극단적인 형태는 SDK(소프트웨어 개발 키트)라고 함. 터미널 앱이나 IDE 통합, 깃허브를 안 쓰고 자기만의 통합을 직접 만들 수 있다고 함.
  39. claude -p 명령으로 프로그램에서 직접 호출하는 방식이라고 함. 자신은 이걸 장애 대응(incident triage)에 쓴다고 함.
  40. GCP(구글 클라우드 플랫폼) 로그를 claude -p로 흘려 넣고 jq(JSON 데이터를 다루는 커맨드라인 도구)로 결과를 다듬는다고 함.
  41. 유닉스 유틸리티처럼 파이프로 입출력을 주고받는 이 쓰임새는 아직 10% 정도밖에 탐색되지 않았다고 함. 모델을 유닉스 유틸리티처럼 쓰는 법은 아직 아무도 제대로 못 풀었다고 함.
  42. 여기서부터는 클로드 코드를 실제로 어떻게 쓰는지 팁을 준다며 줌인함. 본인이 쓰는 방식 위주라고 함.
  43. 처음 쓰는 사람에게 가장 쉬운 입문은 코드베이스를 놓고 묻고 답하는 것이라고 함.
  44. 앤트로픽은 입사 첫날 모든 엔지니어에게 클로드 코드를 가르치고, 이 덕분에 온보딩 기간이 2~3주에서 이틀 정도로 줄었다고 함.
  45. 그 결과 본인도 질문 세례를 덜 받게 됐고, 사람들이 클로드에게 먼저 묻는다고 함. 본인도 마찬가지로 클로드에게 묻는다고 함.
  46. 매주 월요일 스탠드업 전에 "이번 주에 내가 뭘 배포했지"라고 클로드에게 물으면 깃(git) 커밋 기록을 훑어서 알려준다고 함. 직접 기록을 챙길 필요가 없어졌다고 함.
  47. 두 번째 팁은 클로드에게 자신의 도구 쓰는 법을 가르치는 것이라고 함. 이맥스의 리스프(Lisp) 방언이나 이클립스·VS Code의 플러그인처럼 예전엔 도구마다 확장을 따로 만들어야 했다고 함.
  48. 이제는 CLI(명령줄 인터페이스) 도구에 --help를 붙여 실행한 내용을 CLAUDE.md에 그대로 적어두기만 하면 클로드가 그 도구를 쓸 줄 알게 된다고 함.
  49. 다리를 놓거나 확장을 만들 필요가 없다고 함. 도구 묶음이 많거나 스트리밍처럼 더 정교한 기능이 필요하면 MCP를 쓰면 된다고 함.
  50. MCP(모델 컨텍스트 프로토콜)는 에이전트가 외부 도구·데이터에 표준화된 방식으로 접속하게 해주는 규격이라고 함.
  51. 기존 코딩 도구는 코드를 쓰는 일에 집중했지만 새로운 코딩 에이전트는 그보다 훨씬 많은 일을 한다고 함. 이 차이 때문에 처음 쓰는 사람들이 활용법을 못 잡고 헤맨다고 함.
  52. 첫 번째 워크플로는 코드를 쓰기 전에 클로드가 먼저 탐색하고 계획을 세워 사용자에게 확인받게 하는 것이라고 함.
  53. 확장 사고(extended thinking, 모델이 답을 내기 전에 더 오래 추론하게 하는 기능)는 클로드가 이미 컨텍스트에 뭔가를 담아둔 상태에서 걸 때 잘 통한다고 함.
  54. 도구를 써서 컨텍스트를 먼저 채우고 그다음에 생각하게 하라고 함. 아무것도 없는 상태에서 미리 생각부터 시키면 토큰만 낭비한다고 함.
  55. 두 번째 워크플로는 TDD(테스트 주도 개발)라고 함. 사람이 직접 하기엔 실전에서 어렵던 방식인데 모델이 대신 하니까 오히려 잘 통한다고 함.
  56. 클로드에게 테스트부터 쓰게 하되 아직 통과할 리 없다는 걸 분명히 알리고, 테스트를 돌려보려 하지 말라고 못박으라고 함. 그래도 클로드가 테스트를 돌려보려 할 거라고 함.
  57. 테스트를 커밋하고 그다음 코드를 짜서 다시 커밋하게 한다고 함.
  58. 더 일반화하면, 클로드가 겨눌 검증 대상이 있을 때 결과가 훨씬 좋다고 함. 유닛 테스트나 통합 테스트, iOS 시뮬레이터·퍼펫티어(Puppeteer) 스크린샷이면 다 된다고 함.
  59. 실제로 로봇에게 3D 프린터 쓰는 법을 가르치면서 카메라로 출력물을 보게 한 사례를 듦. 결과물을 보고 스스로 고칠 수 있으면 한 번에 끝내는 것보다 훨씬 나아진다고 함.
  60. 첫 시도는 그저 그래도 두세 번째 시도에서 꽤 괜찮아진다며, 클로드에게 겨눌 목표를 주라고 함.
  61. 이날 클로드 코드에 플랜 모드(plan mode)를 새로 내놨다고 함. Shift+Tab을 누르면 클로드가 계획만 세우고 승인을 기다리는 모드로 바뀐다고 함.
  62. 업데이트를 받으려면 클로드 코드를 다시 시작한 뒤 Shift+Tab을 누르면 된다고 함.
  63. 마지막 팁은 클로드에게 컨텍스트를 더 주라는 것이라고 함. 가장 쉬운 방법은 CLAUDE.md 파일을 저장소 루트에 두는 것이고, 하위 폴더나 홈 폴더에 둬도 필요할 때 자동으로 불러온다고 함.
  64. 슬래시 명령도 있다고 함. 정해진 폴더에 마크다운 파일을 넣어두면 슬래시 메뉴에 바로 뜨고, 반복하는 작업 흐름을 저장해두는 데 쓸 만하다고 함.
  65. CLAUDE.md에 뭔가 추가하고 싶으면 언제든 # 기호를 입력해 클로드에게 기억해두라고 시키면, 어느 메모리 파일에 넣을지 되물어온다고 함.
  66. 메모리라는 개념 자체가 기존 IDE엔 없던 새로운 것이라 아직 UX가 거칠다고 인정함. 처음으로 작동하는 버전이라 계속 다듬어갈 거라며 사용자 피드백을 원한다고 함.
  67. 발표 끝에 슬랙(Slack)으로 들어온 질문에 답함. 클로드 코드에 점점 더 많은 일을 맡겨서 동시에 10개 인스턴스가 10분씩 돌아가는 상황에서 어떻게 써야 하냐는 질문이라고 함.
  68. 파워 유저 다수가 클로드를 여러 개 동시에 돌린다고 답함. 터미널 탭 여러 개에 클로드 체크아웃 여러 벌을 열거나, 같은 코드베이스를 깃 워크트리로 나눠서 병렬로 돌린다고 함.
  69. 깃 워크트리(git worktree)는 하나의 저장소 안에서 브랜치마다 별도 폴더를 두고 동시에 작업하게 하는 기능이라고 함.
  70. 깃허브 액션즈(GitHub Actions)를 쓰면 이런 병렬 실행이 더 쉬워진다고 함. 대부분의 경우 여러 클로드 사이에 조율이 따로 필요 없다고 함.
  71. 굳이 조율하고 싶으면 마크다운 파일에 각자 기록을 남기게 하는 게 가장 쉬운 방법이라고 함.

한줄 코멘트. "제품이 뭐가 맞는지 모른다"는 고백을 반복하는데, 실제로는 터미널·IDE·GitHub·SDK 네 겹을 다 만들어놓고 각각에서 뭐가 먹히는지 관찰하는 전략이라 무의견이라기보단 저비용 다중 실험에 가까움.

03

검색 · 컨텍스트 · 기억

  1. 발표자 Zach는 그래프 인텔리전스 회사 Neo4j에서 일하며, 최근 기술 마케팅에서 AI·머신러닝 리서치 엔지니어링 역할로 옮겼다고 소개함.
  2. 오늘 주제는 컨텍스트 그래프(context graph, 사실 정보뿐 아니라 과거 결정이 왜 그렇게 내려졌는지까지 그래프로 엮어놓은 것)임.
  3. 청중에게 물어보니 컨텍스트 그래프를 들어본 사람은 절반쯤, Neo4j 같은 그래프 데이터베이스로 실제 코딩해본 사람도 절반쯤이었음.
  4. 오늘은 컨텍스트 그래프가 무엇인지 정의한 뒤, 프로덕트 매니저 윌리엄 라이언(William Lyon)이 만든 도구로 빠르게 시작하는 법을 보여주겠다고 함.
  5. 컨텍스트 그래프라는 말은 벤처캐피털 파운데이션 캐피털(Foundation Capital)이 지난해 12월쯤 꺼내며 퍼졌다고 밝힘.
  6. 그 뒤로 에이전트가 더 나은 결정을 내리도록 결정 흔적(decision trace, 과거 판단이 어떻게 내려졌는지 남긴 기록)과 추론을 남기자는 논의가 시끄러웠다고 함.
  7. 컨텍스트 그래프가 무엇인지 따져보려면 먼저 "에이전트가 정말 정확한가"라는 질문부터 던져야 한다고 함.
  8. 검색을 많이 하는 에이전트에는 지식 베이스가 필요함.
  9. RAG(검색 증강 생성, retrieval-augmented generation, 모델이 답하기 전에 외부 문서를 찾아와 근거로 쓰는 방식)나 그래프 검색용 지식 베이스는 질문에 정확히 답하도록 도와줌.
  10. 컨텍스트 그래프가 이 흐름에 더하는 것은 질문에 답하는 데 필요한 정보를 넘어, 더 나은 결정을 내리는 데 필요한 정보임.
  11. 예로 든 것은 금융 분석 에이전트임 — 고객이 특정 금액을 요청한 사안을 처리하는 상황임.
  12. 고객 정보, 거래 내역, 정책만 주면 에이전트는 위험 점수를 매기고 검토를 권하며 핵심 위험 요인을 짚는 정도로 답함.
  13. 컨텍스트 그래프가 있으면 에이전트가 승인할지 거절할지, 그리고 왜 그런지까지 답할 수 있게 됨.
  14. 고객 정보와 거래 내역 외에 과거 결정 흔적과 선례(precedent), 왜 그런 결정이 내려졌는지 보여주는 동적 정보까지 함께 가져오기 때문이라고 함.
  15. 기존 시스템 오브 레코드(system of record, 사실과 현재 상태를 담아두는 기존 시스템)는 사실·개체·현재 상태를 다룸.
  16. 컨텍스트 그래프는 여기에 선례, 인과 사슬, 예상되는 결과를 더해 에이전트가 해당 분야 전문성을 갖고 행동하게 해줌.
  17. 컨텍스트 그래프 모델은 세 갈래임 — 존재하는 것들을 담는 개체(entity), 결정·거래·승인 같은 사건(event), 정책과 과거 사람들의 판단이 남긴 추론·기억을 담는 맥락(context)임.
  18. 데모에 쓴 데이터는 CRM(고객관계관리 시스템)과 고객지원 시스템 등에서 가져온 데이터를 흉내 내 생성한 것이라고 밝힘.
  19. 데모는 에이전트 실행에 클로드(Claude)를, 임베딩(embedding, 텍스트나 개체를 숫자 벡터로 바꾼 것)에는 오픈AI(OpenAI)를 씀.
  20. Neo4j 데이터베이스가 벡터와 함께 데이터를 담당하고, 프런트엔드는 넥스트js(Next.js)로 만듦.
  21. 실행 화면을 보여줌 — 질문을 던지면 에이전트가 일련의 도구를 호출하며 그래프 데이터를 가져오는 과정이 보임.
  22. 이어서 여러 결정 흔적을 가져오고, 최종적으로 거절(reject) 결정에 이름.
  23. 그다음 "선례 찾기(find precedents)" 단계를 거치는데, 그래프 안의 구조적 정보를 살펴 인과 사슬로 서로 이어진 관련 노드들을 끌어옴.
  24. 제시카(Jessica)라는 인물의 프로필을 중심으로 컨텍스트를 조회한 예를 보여주며, 이때 결정 흔적들을 가져왔다고 함.
  25. 여기서 하이브리드 검색을 함 — 의미(semantic) 유사도와 그래프 안의 구조적 유사도를 함께 보고 과거 결정 흔적이 어떻게 만들어졌는지 맞춰 추천안을 냄.
  26. 벡터 인덱스로는 "사기 거절(fraud rejection)" 같은 말을 의미 기반으로 검색할 수 있다고 함.
  27. 그래프 임베딩(graph embedding)이라는 개념도 씀 — 단어를 벡터로 바꾸는 텍스트 임베딩과 같은 원리를 서로 연결된 그래프 노드에 적용한 것임.
  28. 그래프 임베딩 덕에 비슷한 결정 흔적을 벡터 유사도로 찾을 수 있는데, 문서 안에만 있었다면 찾기 훨씬 어려웠을 정보라고 함.
  29. 그래프 임베딩은 GDS(그래프 데이터 사이언스, graph data science)라는 도구로 만든다고 밝힘.
  30. 오늘 진짜 보여주고 싶었던 것은 한 달쯤 전 막 나온 새 도구임 — 터미널 명령 한 줄로 컨텍스트 그래프와 프런트엔드, 백엔드를 통째로 만들어줌.
  31. create-react-app이나 create-next-app처럼 뼈대를 그대로 만들어주고, 만들 때 도메인을 지정할 수 있다고 함.
  32. 시연한 명령은 `uvx create context graph`이고, 앱 이름과 도메인, 쓸 프레임워크(파이단틱 AI, Pydantic AI를 고름), 데모 데이터 사용 여부를 지정함.
  33. 명령을 실행하면 더미 데이터가 담긴 픽스처(fixture) JSON 파일들과 함께 폴더가 만들어짐.
  34. 애플리케이션을 설치하고 데이터를 심어(seed) 실행하기까지 몇 분 걸린다고 함.
  35. 완성되면 그래프 안에 데이터가 들어가고, 질문을 던지면 사이퍼(Cypher, 그래프 전용 질의 언어)로 데이터를 찾아 답함.
  36. 실제로 처방약 관련 질문을 던진 헬스케어 도메인 데모를 보여줬고, 스키마 시각화와 여러 결정 흔적을 함께 볼 수 있었음.
  37. 단계별 설명이 담긴 전용 웹사이트도 있어 컨텍스트 그래프를 빠르게 시작해볼 수 있다고 함.
  38. 깃허브(GitHub)·노션(Notion)·지라(Jira)·슬랙(Slack) 같은 SaaS(서비스형 소프트웨어)에서 데이터를 끌어오는 연결 도구도 있어, 데모 데이터 말고 실제 데이터도 넣을 수 있음.
  39. 지원하는 프레임워크는 파이단틱 AI 외에도 오픈AI, 랭그래프(LangGraph), 크루(Crew), 스트랜즈(Strands), 구글 ADK 등 여러 개라고 밝힘.
  40. 미리 만들어진 도메인이 22개 있고, 시연한 헬스케어 말고 금융서비스(FinServ)도 있다고 함.
  41. 직접 만든 도메인을 지정하면 도구가 온톨로지(ontology, 개체와 관계의 종류를 미리 정한 그래프 틀)를 자동으로 만들어줌.
  42. 그래프 네이티브 기능으로 데이터 조회·결정 흔적 확인뿐 아니라 MCP(모델 컨텍스트 프로토콜, model context protocol) 서버 생성과 앱 안에서의 다회차 대화까지 지원한다고 함.
  43. 이 프로젝트는 이제 막 시작한 오픈소스라 누구나 기여할 수 있다고 밝힘.
  44. 이 도구를 떠받치는 핵심 의존성은 Neo4j 에이전트 메모리(agent memory) 패키지고, 완전한 메모리 API라고 소개함.
  45. 컨텍스트 그래프에는 단기 기억, 장기 기억, 추론 세 가지가 다 필요한데 이 패키지가 그 세 가지를 담당한다고 함.
  46. 단기 기억은 대화 기록과 세션 맥락이고, 장기 기억은 거기서 뽑아낸 개체들과 시간이 지나며 반복되는 것들을 정리한 결과임.
  47. 추론은 컨텍스트 그래프 안의 흔적 그 자체라고 밝힘.
  48. 텍스트를 지식 그래프로 바꾸는 과정도 패키지 안에 들어있음 — 원문 텍스트를 스페이시(spaCy)에서 시작해 글라이너(GLiNER)를 거쳐 더 정교한 단계, 마지막엔 LLM(거대언어모델) 대체 단계까지 거침.
  49. 그 뒤 별도의 병합·중복 제거·보강 절차를 거쳐 단기 기억을 쓸모 있는 장기 기억과 개체로 바꿔준다고 함.
  50. 스키마 구조는 대화가 있고, 거기서 뽑힌 개체들이 추론 흔적과 연결되는 모습이라고 함.
  51. 발표 끝에 링크한 자료는 컨텍스트 그래프 데모를 소개한 블로그(호스팅된 실제 애플리케이션 링크 포함), create-context-graph 링크, 깃허브 저장소 셋임.
  52. Neo4j 에이전트 메모리 패키지는 마이크로소프트 에이전트 프레임워크(Microsoft Agent Framework), 구글 ADK를 비롯한 여러 프레임워크와 통합된다고 밝힘.
  53. 질의응답에서 청중이 타임스탬프를 추가해 시간 순서대로 벌어진 단계들을 "원인이 됨"이나 "다음"으로 잇자고 제안함.
  54. 발표자는 아직 그렇게까지는 안 되지만 기술이 성숙하면 그렇게 될 좋은 아이디어라고 답함.
  55. 기존에 마련된 도메인들은 온톨로지가 미리 준비돼 있고, 정해진 개체·관계 종류 틀을 이용해 추출과 매핑을 이끈다고 밝힘.
  56. 프런트엔드까지 자동으로 만드는 법을 묻자, create-context-graph 패키지를 쓰면 온톨로지와 데이터를 설명하는 것만으로 그래프 스키마를 만들 수 있다고 답함.
  57. 데이터가 구조화돼 있지 않으면 개체 추출을 거치고, CSV나 표처럼 이미 구조화돼 있으면 사이퍼 문으로 그대로 매핑하면 된다고 밝힘.
  58. 새 결정 흔적을 어떻게 써넣을지 묻자, 아직 다 풀지 못한 문제라고 인정함 — 지금 데모에서는 결정을 저장하라고 직접 시켜야만 저장된다고 함.
  59. create-context-graph 쪽도 새 결정 흔적을 쓰는 방식은 아직 작업 중이라고 밝힘.
  60. 결정에 일종의 감정이나 품질 점수를 매기는 방식이 필요할 수 있다는 생각을 덧붙임.

한줄 코멘트. 결정 흔적을 그래프로 남기자는 방향은 맞는데, 정작 새 흔적을 누가 언제 써넣을지는 발표자도 아직 못 풀었다고 인정한 대목이 이 발표에서 제일 정직한 부분임.

  1. 이 발표는 AI 엔지니어 코드 서밋에서 Neo4j의 디벨로퍼 릴레이션즈(개발자 관계) 부문 부사장 스티븐 친이 한 것임.
  2. 발표 주제는 그래프 기술로 컨텍스트 엔지니어링(context engineering, AI에게 넘길 정보를 설계하고 조합하는 작업)과 검색 패턴, 에이전트 기억을 다루는 것이라고 밝힘.
  3. 지금까지는 한 번의 영리한 문구로 결과를 바꾸는 프롬프트 엔지니어링에 머물렀는데, 이제는 더 동적이고 넓은 범위의 정보를 AI에게 먹이는 방향으로 진화하고 있다고 함.
  4. 컨텍스트 엔지니어링은 에이전트가 작업을 함께 수행하는 데 필요한 정보를 더 많이 얻게 해주고, 목표 지향적인 애플리케이션을 만들게 해준다고 설명함.
  5. 엔터프라이즈나 비즈니스 맥락처럼 특정 도메인에 맞게 정보를 선별해 넣는 것이 특히 중요하다고 강조함.
  6. 요즘 모델은 컨텍스트 창(context window, 모델이 한 번에 읽어들이는 입력 범위)은 커졌지만 정작 중요한 부분에 주의를 기울이지 못하는 게 큰 문제라고 지적함.
  7. 그래서 지금은 프롬프트 엔지니어가 아니라 정보 아키텍트처럼 생각해야 한다고 주장함.
  8. 컨텍스트 엔지니어링의 범위 안에는 프롬프트 엔지니어링, RAG(검색 증강 생성, 모델이 답하기 전에 외부 문서를 찾아와 근거로 쓰게 하는 방식), 상태·이력 관리, 구조화된 출력까지 포함된다고 정리함.
  9. RAG는 여전히 엔터프라이즈나 비즈니스 맥락의 데이터를 끌어와 AI에게 추가 정보로 공급하는 데 중요한 역할을 한다고 함.
  10. 모델에 상태와 이력, 즉 메모리(기억)를 붙이면 단기적으로는 서로 협업하고 장기적으로는 대화 맥락을 기억해 더 효과적으로 작업할 수 있다고 함.
  11. 메모리는 단기 기억과 장기 기억 두 갈래로 나뉜다고 설명함.
  12. 단기 기억은 현재 작업 중인 정보를 최대한 압축해 관련성 높은 결과가 검색창 상단에 오게 만드는 게 목표라고 함.
  13. 다만 이전 대화에서 도구가 쏟아낸 방대한 결과까지 그대로 단기 기억에 채워 넣으면 컨텍스트 창을 낭비하게 된다고 지적함.
  14. 장기 기억은 여러 대화에 걸쳐 쌓인 일화적(episodic) 정보의 의미와 구조를 뽑아내 AI의 지침이나 절차로 활용하는 것이라고 함.
  15. 이렇게 정리한 메모리는 관련성 높은 맥락을 컨텍스트 창 위쪽으로 끌어올리고 빈틈을 채우며 소음을 줄여 환각(hallucination, 모델이 근거 없이 지어내는 답)을 줄여준다고 함.
  16. LLM(대형언어모델)은 받는 데이터 품질만큼만 좋은 답을 낸다며, 나쁜 데이터를 주면 나쁜 답이 나온다고 못박음.
  17. 구조화된 정보와 관련성 높은 입력을 갖추면 모델의 신뢰성과 설명 가능성이 함께 좋아진다고 함.
  18. 이 구조화를 실현하는 방법의 하나로 지식그래프(knowledge graph)를 제시함.
  19. 지식그래프는 AI가 잘하는 생성·조합 능력과, AI에게 부족한 구조화된 정보를 이어주는 기술이라고 설명함.
  20. 지식그래프는 사람·장소·사건·사물을 나타내는 노드(node)와 그 사이를 잇는 관계(relationship)로 구성되고, 노드에는 속성(property)을 붙일 수 있다고 함.
  21. 예시로 앤(Ann)과 댄(Dan)이 서로 알고 함께 살고 차를 함께 몬다는 관계를 보여주고, 그 차가 볼보 V70이라는 속성과 몬 기간까지 노드에 담김을 보여줌.
  22. 이 노드에는 임베딩(embedding, 의미를 숫자 벡터로 바꾼 값)도 함께 붙일 수 있어 벡터 검색까지 그래프 위에서 할 수 있다고 함.
  23. RAG를 그래프와 결합한 것이 그래프RAG(GraphRAG)이며, 검색 과정에서 그래프를 함께 쓰는 모든 검색 파이프라인을 가리킨다고 정의함.
  24. 그래프RAG의 흐름은 사용자 질문이 LLM으로 가고, LLM이 지식그래프에 관련 정보를 쿼리한 뒤 그 결과를 추가 맥락으로 받아 더 정확한 답을 내놓는 순서라고 함.
  25. 벡터 유사도 검색만 쓰는 것보다 노드 간 관계와 커뮤니티 그룹핑까지 활용하기 때문에 더 관련성 높은 결과가 나온다고 함.
  26. 지식그래프를 쓰면 LLM이 실제로 어떤 부분을 참고해 답했는지 눈으로 확인할 수 있어 설명 가능한 AI(explainable AI)가 된다고 함.
  27. 지식그래프는 시간에 따라 계속 진화시킬 수 있고, 역할 기반 접근 제어(role-based access) 같은 오버레이도 얹을 수 있다고 함.
  28. 예로 환자 정보 시스템에서 의사만 진단 정보에 접근하고, 행정 담당자는 전화번호·주소 같은 개인정보에만 접근하게 나누는 방식을 듦.
  29. 그래프에 사용자와 에이전트의 상호작용 학습 결과를 저장하면 대화 흐름과 추론 과정을 시각화할 수 있다고 함.
  30. 에이전트 시스템의 성능 데이터를 분석해 개선점을 찾고, 중복 노드를 제거하는 식으로 그래프 품질을 관리하면 결과 품질도 함께 좋아진다고 함.
  31. 첫 번째 데모로 LLM 지식그래프 빌더(LLM Knowledge Graph Builder)를 활용한 그래프RAG를 보여줌.
  32. 무료 온라인 버전인 Neo4j 오라(Aura) 인스턴스를 미리 띄워두고, 오픈소스 웹 애플리케이션인 지식그래프 빌더로 파일을 업로드해 그래프를 구축했다고 함.
  33. 시연 전에 미리 올려둔 파일은 공급망 문서 하나와 VEX(보안 취약점을 기술하는 표준 문서) 문서 하나라고 함.
  34. VEX 문서는 재키슨(Jackson) 라이브러리의 취약점, 영향받는 버전, 수정한 커밋 정보 등을 담고 있다고 함.
  35. 이 파일들을 인제스트(ingest, 수집·적재) 단계에 넣으면 LLM이 자동으로 지식그래프를 만들어내고, 취약점을 발견한 사람이나 데이터베이스 URL 같은 노드들이 관계로 연결됨을 확인할 수 있었다고 함.
  36. 이렇게 만든 그래프를 두 단계로 질의하는 LLM을 시연함. 1단계는 벡터 유사도 검색으로 관련 노드를 찾음.
  37. 2단계는 그 노드와 연결된 관련 노드까지 추가로 찾아 맥락으로 전달하는 방식임.
  38. 목표는 그래프에 있는 정보로는 답하고, 그래프 밖의 정보를 물으면 답을 거부하게 만드는 것이라고 함.
  39. 먼저 VEX 문서에 없는 재스퍼(Jasper) 라이브러리 취약점을 물어 답을 거부하는지 확인했는데, 발음이 비슷한 재키슨(Jackson)을 잘못 말한 오타였다고 밝힘.
  40. 오타인 채로도 사람의 실수를 잘 보정하는 LLM 특성 덕에 재키슨 데이터바인드(Jackson databind) 라이브러리의 XML 인젝션 공격 정보가 정확히 나왔다고 함.
  41. 취약점이 있는 버전, 수정 여부, 수정된 버전까지 전부 지식그래프에서 집계돼 나왔다고 함.
  42. 이 답이 상세하고 초점이 분명한 이유는 유한하고 편집·수정이 가능한 데이터에 근거를 두고 있기 때문이라고 설명함.
  43. 두 번째로 그래프를 에이전트 기억 검색(memory retrieval)에 쓰는 방법을 다룸.
  44. 그래프 검색을 위한 오픈소스 MCP(모델 컨텍스트 프로토콜) 서버가 있어, 지식그래프뿐 아니라 벡터까지 함께 쿼리할 수 있다고 함.
  45. 커뮤니티 그룹핑, K최근접이웃(K nearest neighbors) 같은 그래프 데이터 사이언스 알고리즘으로 관계와 구조에서 인사이트를 뽑아낼 수 있다고 함.
  46. 이렇게 뽑은 정보를 단기 기억 또는 장기 기억으로 에이전트 루프에 추가 맥락으로 넣어준다고 함.
  47. 메모리 그래프의 노드에는 텍스트 세부 정보, 임베딩, 시간, 위치 같은 속성이 붙고 일부 속성은 벡터로 임베딩돼 의미 기반 검색이 가능하다고 함.
  48. 여기에 K근사최근접이웃, 커뮤니티 그룹핑, 페이지랭크(PageRank) 같은 알고리즘까지 얹으면 여러 종류의 질문에 답하며 가장 관련성 높은 결과를 끌어올릴 수 있다고 함.
  49. 예시로 "지난번 인도 동료 시드(Sid)와 함께 발표했던 자료를 업데이트해줘"라는 질문을 듦.
  50. 그래프에서 관련 인물 둘을 찾는데, 하나는 발표자 본인(디벨로퍼 릴레이션즈 부사장)이고 다른 하나는 커뮤니티 매니저인 시드라고 함.
  51. 마지막으로 함께 발표한 곳은 인도 방갈로르에서 열린 GIDS라는 개발자 컨퍼런스였다고 함.
  52. 이렇게 두 사람과 하나의 행사 사이의 시간적 관계를 찾고, 특정 시점의 발표 기억 레코드까지 더해 LLM에 맥락으로 넘긴다고 함.
  53. 이런 다단계 쿼리는 그래프이기 때문에 가능한 것이고, 여러 사실을 한 번에 못 끌어오는 경우일수록 그래프RAG와 그래프 메모리의 진가가 나온다고 함.
  54. 반대로 한 번의 유사도 검색으로 끝나는 질문이면 일반 벡터 RAG로 충분하다고 선을 그음.
  55. 그래프 검색기 종류로 미리 정해둔 진입점으로 쿼리하는 명시적 검색, 스키마를 학습해 질문마다 쿼리를 생성하는 텍스트-투-사이퍼(text2cypher), 답을 찾을 때까지 반복해서 그래프를 순회하는 에이전틱(agentic) 순회 세 가지를 듦.
  56. 두 번째 데모에서는 같은 지식그래프를 클로드 코드(Claude Code)로 질의함.
  57. Neo4j Cypher MCP 서버라는 오픈소스 확장을 클로드 코드에 연결하고 데이터베이스 설정을 미리 마쳐둔 상태에서, "그래프 데이터베이스를 근거로 재키슨 취약점에 대해 아는 걸 말해줘"라고 물음.
  58. 클로드 코드는 먼저 그래프의 스키마부터 조회해 관계 구조를 파악한 뒤, 여러 개의 Cypher 쿼리를 연달아 날려 취약점 정보를 모은다고 함.
  59. Cypher는 Neo4j를 비롯한 대부분의 그래프 데이터베이스가 지원하는 질의 언어이고, ISO가 채택한 GQL 표준이 사실상 Cypher의 부분집합이라고 밝힘.
  60. 취약점 정보를 받아온 뒤에는 그 노드에 달린 텍스트 청크까지 끌어와 최대한 완전한 답을 만든다고 함.
  61. 첫 번째 데모의 2단계 벡터 검색은 빨랐지만 CVE(공통 취약점·노출) 상세도는 제한적이었다고 비교함.
  62. 반면 클로드 코드가 그래프를 자유롭게 순회하며 캐물은 이번 답은 CVE 번호, 공격 유형, 심각도, 기술적 설명, 수정 버전까지 훨씬 상세하게 나왔다고 함.
  63. 이 정도 상세도면 취약점 보고서를 조직 차원에서 작성하는 데도 바로 쓸 수 있을 만큼 강력하다고 평가함.
  64. 마무리로 그래프 학습 자료 세 곳을 소개함. 사이퍼 쿼리와 파이썬·타입스크립트 예제가 있는 그래프RAG 강의를 무료로 제공하는 그래프 아카데미(Graph Academy)임.
  65. 지난주 1만3000명이 등록했던 노즈(NODES) 컨퍼런스의 후속으로 열리는 무료 온라인 컨퍼런스 노즈 AI 2026(NODES AI 2026), 그래프RAG 최신 연구와 구현 가이드를 모아둔 커뮤니티 사이트 graphrag.com도 언급함.

한줄 코멘트. 같은 그래프, 같은 질문인데 벡터 검색 2단계로 물을 때와 에이전트가 스키마부터 파악해 순회하며 캐물을 때의 답 상세도가 이렇게 벌어진다는 게 이 발표의 진짜 논점임 — 그래프RAG는 데이터 구조 얘기고, 얼마나 캐묻게 하느냐는 검색 방식 얘기임.

  1. 이 발표는 마이크로소프트 리서치에서 그래프 팀을 이끄는 조너선 라슨이 AI 엔지니어 컨퍼런스에서 한 것임.
  2. 작년에 낸 그래프RAG(GraphRAG, 문서나 코드를 그래프 구조로 엮어 두고 그 위에서 검색·요약하는 방식) 논문과 깃허브 저장소가 예상 밖으로 큰 관심을 받았고 파생 연구도 많이 나왔다고 밝힘.
  3. 오늘 남기고 싶은 첫 번째 메시지는 구조를 가진 LLM 메모리가 효과적인 AI 애플리케이션을 만드는 핵심 인에이블러(enabler, 가능하게 하는 요소)라는 것임.
  4. 두 번째 메시지는 이 구조에 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)를 결합하면 훨씬 강력해진다는 것임.
  5. 오늘 다룰 내용은 그래프RAG를 코딩 도메인에 적용해 기업 생산성을 보는 사례, 오늘 공개하는 오픈소스 벤치마크QED(BenchmarkQED), 레이지 그래프(Lazy GraphRAG)라는 새 기술의 벤치마크 결과 세 가지임.
  6. 먼저 코드용 그래프RAG 이야기로, 한 엔지니어가 만든 터미널 기반 비디오 게임으로 시연을 시작함.
  7. 이 게임은 장애물을 뛰어넘으면 점수를 얻고 부딪히면 점수를 잃는 방식으로, 7개 파일에 걸쳐 약 200줄짜리 코드임.
  8. 이 시연의 조건 하나는 LLM(대형언어모델)이 이 코드를 한 번도 본 적 없다는 것이고, 다른 하나는 사람이 전체를 다 파악할 수 있을 만큼 작지만 LLM이 코드를 그대로 컨텍스트 창에 다 넣으면 이해에 애를 먹을 만큼은 복잡하다는 것임.
  9. 일반 RAG(검색 증강 생성, 모델이 답하기 전에 외부 문서를 먼저 찾아와 그 내용을 근거로 쓰게 하는 방식) 도구로 "이 애플리케이션이 무엇이고 어떻게 동작하는지 설명해줘"라고 물어봄.
  10. 돌아온 답은 "메인 함수로 구성·시작되고 설정 파일을 쓰며 게임 화면·게임 로직 등 주요 구성 요소가 있다"는 것이었음.
  11. 라슨은 이 답이 게임이라는 것 말고는 아무것도 알려주지 않는다며 완전히 쓸모없다고 평가함.
  12. 같은 코드베이스, 같은 질문을 코드용 그래프RAG로 돌리면 "커서 기반 터미널 환경에서 돌아가는 인터랙티브 게임"이라는 답이 나옴.
  13. 이어서 "수직으로 점프하는 플레이어 캐릭터, 가로로 움직이는 장애물, 정적인 배경 레이어가 있고 스페이스바로 점프를 조작한다"는 훨씬 구체적인 답이 붙음.
  14. 이 차이는 로컬 쿼리(local query, 파일 하나 단위 질의)와 글로벌 쿼리(global query, 저장소 전체를 훑어야 답할 수 있는 질의) 개념으로 설명됨.
  15. 방금 질문은 저장소 전체를 이해해야 답할 수 있는 글로벌 쿼리이고, 그래프RAG가 여기서 강점을 보인다고 함.
  16. 다음으로 시도한 건 코드 번역임. 같은 파이썬 코드베이스를 러스트(Rust)로 옮기는 작업을 시켜봄.
  17. 먼저 그래프RAG 없이, 200줄짜리 소스 코드를 그대로 LLM에 넣고 다양한 프롬프트로 러스트 번역을 시도함.
  18. LLM이 러스트 코드를 만들어내긴 했지만 컴파일해보니 곳곳에서 문제가 나서 그대로는 동작하지 않았다고 함.
  19. 이번엔 코드용 그래프RAG의 번역 기능을 돌려 새 러스트 파일들을 생성함.
  20. 이 러스트 파일들을 그대로 실행하니 파이썬 게임이 러스트로 완전히 번역돼 그대로 동작했다고 함.
  21. 다음 단계로 200줄짜리 장난감 예제를 벗어나, 약 30년 된 10만 줄·231개 파일짜리 둠(Doom) 코드베이스로 넘어감.
  22. LLM들이 둠 코드베이스를 학습 데이터로 이미 알고 있을 거라 보고 먼저 테스트함.
  23. 둠이라는 게임 자체는 알아도 이 특정 코드베이스의 구체적인 내용은 모른다는 걸 확인함.
  24. 그래서 둠 코드베이스를 실제로 의미 있게 수정하라고 시키면 LLM 모델들이 다시 완전히 실패했다고 함.
  25. 10만 줄·231개 파일을 그래프로 이해할 수 있다면 문서화 같은 새로운 산출물도 만들 수 있겠다고 보고 저장소 전체 문서화를 시켜봄.
  26. 여기서 글로벌 쿼리는 20~30개 파일에 걸친 사운드 시스템 전체가 어떻게 동작하는지를 설명해줌.
  27. 동시에 로컬 쿼리로는 그 안의 개별 파일 단위까지 파고들 수 있었다고 함.
  28. 문서화와 Q&A, 코드 번역이 되니 다음 질문은 기능 개발까지 가능한가였음.
  29. 사무실에 게임 플레이어가 많아 둠에 어떤 기능을 넣으면 재밌을지 얘기하다가, 원작 둠에는 없는 점프 기능을 넣어보자는 아이디어가 나옴.
  30. 점프 기능 추가는 여러 파일을 동시에 고쳐야 하는 복잡한 작업임.
  31. AI 시스템에 멀티 파일 수정을 시키면 한 파일은 잘 고치면서 다른 파일들을 깨뜨리는 일이 반복돼 결국 동작하지 않는 결과로 끝나는 경우가 많다고 함.
  32. 라슨은 이게 코드 전체가 어떻게 맞물려 있는지에 대한 이해 부족 때문이라며, 바로 이 지점에서 그래프가 도움이 된다고 밝힘.
  33. 이번엔 마이크로소프트 빌드(Build)에서 발표된 깃허브 코파일럿 코딩 에이전트를 코드용 그래프RAG에 직접 연결해 시도함.
  34. 둠 코드베이스를 가리키는 새 이슈를 만들어 "플레이어에게 점프 기능을 추가하라"는 몇 문장짜리 설명을 적고 깃허브 코파일럿 코딩 에이전트에 할당함.
  35. 코딩 에이전트가 뒤에서 코드용 그래프RAG에 접근해 저장소 전체를 아우르는 하향식 계획을 세우는 과정을 보여줌.
  36. 결과적으로 여러 파일을 고쳤는데도 그대로 동작했고, 이전에 시도했던 다른 에이전트들은 이 작업에서 전부 실패했다고 함.
  37. 라슨은 이 결과가 그래프 구조를 실제로 가져다 쓴 덕분이라 밝히며, 팀이 그 결과에 크게 기뻐했다는 일화로 코드 사례를 마무리함.
  38. 발표 후반 5분은 벤치마크QED로 넘어감. 그래프RAG 같은 시스템의 로컬·글로벌 품질 지표를 측정·평가하는 방법을 다룸.
  39. 벤치마크QED는 오늘 깃허브에 오픈소스로 공개됐고 전날 밤에 막 올라왔다고 함.
  40. 세 구성요소는 오토Q(AutoQ, 대상 데이터셋용 질의 생성), 오토E(AutoE, LLM을 판정자로 써서 질의 성능을 평가), 오토D(AutoD, 데이터셋 요약·샘플링)임.
  41. 오토Q는 가로축이 로컬·글로벌, 세로축이 데이터 기반 질문과 페르소나·활동 기반 질문으로 나뉜 격자 위에서 질문을 생성함.
  42. 예시로 든 데이터셋은 AP뉴스의 의료 관련 사건들임.
  43. 데이터-로컬 질문은 "2024년 2월 한국 전공의들이 왜 파업했나"처럼 구체 정보가 많아 일반 RAG도 잘 답할 만한 유형이라고 함.
  44. 활동-글로벌 질문은 "소외된 지역사회를 겨냥한 주요 공중보건 이니셔티브는 무엇인가"처럼 임베딩이나 색인으로 붙잡을 지점이 없는 유형이라고 함.
  45. 이런 질문은 데이터셋 전체를 총체적으로 알아야 답할 수 있다고 함.
  46. 오토Q가 이렇게 로컬~글로벌, 데이터 기반~활동 기반을 넘나드는 질문 세트를 만들어주면 오토E로 그 질문들의 성능을 측정함.
  47. 오토E의 합성 점수는 포괄성(comprehensiveness)·다양성(diversity)·역량강화(empowerment)에 새로 추가된 관련성(relevance) 지표를 더한 것이라고 함.
  48. 앞의 세 지표는 작년 그래프RAG 논문에서 이미 쓰던 것이고, 관련성이 이번에 새로 붙은 것임.
  49. 이 지표들로 레이지 그래프RAG를 8K, 120K, 100만 토큰 세 가지 컨텍스트 창 크기의 벡터RAG와 비교함.
  50. 차트에서 막대가 50%를 넘으면 그 구간에서 레이지 그래프가 이겼다는 뜻이라고 함.
  51. 데이터-로컬 질문에서 레이지 그래프는 8K·120K·100만 토큰 벡터RAG를 상대로 각각 92%, 90%, 91%의 비율로 이겼다고 함.
  52. 라슨은 로컬 질문에서는 일반 RAG가 더 잘할 거라 예상했는데 레이지 그래프가 로컬·글로벌을 가리지 않고 전 구간에서 우위를 보인 게 뜻밖이었다고 밝힘.
  53. 다만 글로벌 막대와 로컬 막대 사이에 약간의 차이는 있었다고 함.
  54. 두 번째로 눈에 띈 점은 긴 컨텍스트 창이 별 차이를 만들지 못했다는 것임.
  55. 100만 토큰짜리 긴 컨텍스트가 글로벌 질문에 유리할 거라 기대했지만 레이지 그래프가 그래도 그 지표들을 압도했다고 함.
  56. 슬라이드에는 없는 내용으로, 이 테스트를 돌렸을 때 레이지 그래프의 비용이 100만 토큰 컨텍스트 창 방식의 10분의 1이었다고 함.
  57. 남은 시간에 레이지 그래프의 근황을 전함. 지난해 11월 블로그에서 처음 소개된 이 기술이 이제 두 제품에 공식으로 실릴 예정이라고 함.
  58. 첫 번째는 애저 로컬(Azure Local)로, 빌드에서 레이지 그래프RAG를 곧 자사 플랫폼에 넣겠다고 발표됐다고 함.
  59. 두 번째는 역시 빌드에서 발표된 마이크로소프트 디스커버리(Microsoft Discovery) 플랫폼임.
  60. 이 플랫폼은 그래프 기반 과학 공동추론(co-reasoning)을 하는 도구로, 가설-실험-학습-지식 순서로 진행됨.
  61. 이 안의 질의응답도 그래프RAG와 레이지 그래프가 뒷단에서 돌아간다고 밝힘.
  62. 마무리로 남긴 메시지는 구조를 가진 LLM 메모리가 정말 강력한 도구라는 것과, 여기에 에이전트를 더하면 그 힘이 크게 증폭된다는 것임.

한줄 코멘트. 200줄짜리 장난감 게임과 10만 줄짜리 둠에서 같은 패턴이 반복됨 — 코드를 그대로 컨텍스트 창에 밀어 넣으면 규모와 무관하게 막히고, 그래프로 구조를 얹어야 번역도 기능 추가도 뚫림.

  1. AWS의 마니 카누자가 데이터를 생성형 AI의 차별화 요소로 다루겠다며 발표를 시작함.
  2. 생성형 AI가 사업 가치를 크게 끌어올릴 수 있지만 "제대로 했을 때"라는 조건이 붙는다고 함.
  3. 사용자와 상호작용하는 방식을 바꿀 만큼 큰 걸 만들 때는 그 밑을 받치는 기초를 더 깊이 봐야 하는데, 그 기초가 데이터라고 함.
  4. 데이터가 회사·브랜드·조직 자체를 대표하기 때문에 기초로 삼아야 한다고 함.
  5. 데이터를 모아야 한다는 건 머신러닝 초창기부터 익히 알던 얘기지만, 생성형 AI에서는 데이터 요구사항 자체가 다르다고 함.
  6. 데이터를 변환·적재·파싱하는 처리 작업은 여전히 중요하지만, 더 중요한 건 데이터가 기술·사람과 어떻게 상호작용하는지, 사일로가 아직 남아 있는지라고 함.
  7. 모델이 방대한 데이터를 삼킬 수 있는 만큼 이제는 데이터를 사일로에 방치할 여유가 없다고 함.
  8. 애플리케이션마다 필요한 데이터가 어떻게 다른지 보여주려고 여행 에이전트·사내 챗봇·마케팅 애플리케이션 세 사례를 든다고 함.
  9. 여행 에이전트는 고객 프로필을 알아야 하는데, 모르면 방금 나간 사람 이름을 기억 못 하는 것처럼 어색하다고 비유함.
  10. 개인화된 경험은 개인 데이터를 요구하고, 그만큼 PII(개인식별정보) 노출을 책임져야 하는 부담도 커진다고 함.
  11. 여행 정책 같은 회사 데이터도 필요한데, 환불 자격이 있는지 없는지가 그 정책으로 정해지기 때문이라고 함.
  12. 사내 생산성용 대화형 챗봇은 회사 데이터가 필요하지만, 직원이 자기 권한 이상으로 데이터에 접근하지 않게 막는 게 중요하다고 함.
  13. 이 챗봇은 슬랙 같은 곳에 붙을 수도 있고 커스텀 앱에 붙을 수도 있어서, 통합 방식과 데이터가 흩어진 여러 소스도 함께 고려해야 한다고 함.
  14. 브랜드 마케팅용 애플리케이션은 또 다른 데이터 요구사항을 가진다고만 짚고 넘어감.
  15. 여행 에이전트를 더 들여다보면 프롬프트(시스템 프롬프트와 사용자 질의)도 결국 데이터이고, 상황에 맞는 프롬프트 카탈로그나 템플릿을 골라 쓸 수도 있다고 함.
  16. 컨텍스트도 더 이상 고정돼 있지 않고 여러 데이터 서비스와 소스에서 그때그때 가져온다고 함.
  17. 기성 모델을 쓰든 파인튜닝을 하든 학습 단계에도 회사를 대표하는 데이터가 다시 필요해서, 결국 의미 있는 답을 얻기까지 모든 단계에 데이터가 들어간다고 함.
  18. 책임 있는 AI(Responsible AI) 이야기는 잠시 미뤄두겠다고 예고함.
  19. 이 모든 걸 해결하는 답으로 AWS 자사 제품인 아마존 베드록(Amazon Bedrock)을 소개함.
  20. 베드록은 모델 선택지 외에 베드록 데이터 오토메이션(BDA, 단일 API로 커스텀 데이터 파이프라인을 만들어 데이터를 변환하는 기능)을 제공한다고 함.
  21. 파인튜닝이 필요하면 모델 커스터마이제이션을, 성능을 재보려면 모델 이벌루에이션을 쓸 수 있다고 함.
  22. RAG(질문에 답하기 전에 외부 문서를 찾아와 근거로 쓰는 방식) 애플리케이션을 코드로 처음부터 짜지 않고 베드록 지식 베이스(Knowledge Bases)로 빠르게 만들 수 있다고 함.
  23. 책임 있는 AI는 베드록 가드레일(Guardrails)로 다룬다며, 에이전트형 RAG든 요약이든 분류든 사기 탐지든 결국 안전하고 사적이며 가드레일을 갖춘 방식으로 만들어야 한다고 함.
  24. 컨텍스트 기반 챗봇을 만드는 단순한 RAG 예시로 들어가 각 베드록 기능을 데이터가 흐르는 순서대로 다시 짚는다고 함.
  25. BDA를 쓰면 API 하나로 커스텀 데이터 파이프라인을 만들 수 있다고 함.
  26. 이미지 데이터를 다룬다는 건 인물 사진을 설명하는 게 아니라, 금융 문서 속 차트나 라인 그래프에서 업무적으로 의미 있는 내용을 뽑아내는 걸 뜻한다고 함.
  27. 그런 작업을 직접 다 짜는 대신 BDA로 더 빠르게 처리할 수 있다고 함.
  28. 베드록 지식 베이스는 BDA를 네이티브로 지원해서 데이터 처리 단계와 바로 이어진다고 함.
  29. 청킹(문서를 검색하기 좋은 단위로 잘게 나누는 작업) 전략을 정해야 하는데, 복잡한 표가 있으면 계층적 청킹이나 시맨틱 청킹 같은 기본 제공 방식을 쓸 수 있다고 함.
  30. 기본 제공 방식이 안 맞으면 커스텀 청킹 로직을 직접 짤 수도 있다고 함.
  31. 프롬프트를 증강하려면 벡터화가 필요한데, 임베딩 모델과 벡터 스토어를 원하는 대로 고를 수 있다고 함.
  32. 데이터 수집(ingestion)과 증분 업데이트까지 지식 베이스가 기본 제공해서 그 로직을 따로 짜지 않아도 된다고 함.
  33. 정보를 가져오는 리트리브(Retrieve) API가 있고, 시맨틱 검색뿐 아니라 하이브리드 검색 옵션도 파라미터로 넘길 수 있다고 함.
  34. 리랭킹(재정렬)·후처리·쿼리 분해까지 한 번에 처리하는 리트리브 앤 제너레이트(Retrieve and Generate) API도 있어서 파라미터만 넘기면 복잡한 질의도 처리한다고 함.
  35. 베드록 가드레일은 최종 사용자에게 PII나 부적절한 키워드가 노출되지 않게 막고, 커스텀 정책과 예시를 직접 정의할 수 있게 해준다고 함.
  36. 가드레일은 응답을 근거(그라운딩)에 묶어 환각을 줄이고, 모든 상호작용을 로깅해서 사용자가 어떤 패턴으로 트리거되는지도 파악하게 해준다고 함.
  37. 이렇게 BDA로 데이터를 처리하고 지식 베이스로 RAG를 세우고 가드레일까지 네이티브로 통합하면 챗봇이 다 된 것처럼 보인다고 함.
  38. 하지만 애플리케이션이 완성돼 이미지·문서 응답까지 나오는 상태에서도 진짜 중요한 이야기는 이제부터라고 함.
  39. 많은 사람이 RAG 애플리케이션을 잘 만드는 방법을 물어봤는데, 그 답이 RAG뿐 아니라 다른 생성형 AI 애플리케이션에도 대체로 통한다고 함.
  40. 첫 번째로 다시 강조하는 게 청킹 전략인데, 전략을 제대로 잡느냐가 생성된 응답의 정확도를 좌우한다고 함.
  41. 청킹은 한 단계일 뿐이고 두 번째로 최적화가 필요한데, 리랭킹·파싱·하이브리드 검색 말고도 쿼리 재구성·쿼리 분해 같은 기법이 더 있다고 함.
  42. 자기 애플리케이션에 뭐가 잘못됐는지도 모르면서 최적화할 수 있느냐고 청중에게 되묻고, 그럴 수 없다고 스스로 답함.
  43. 그래서 최적화보다 평가(evaluation)가 먼저라고 함.
  44. 최적화는 정확도·비용·지연(latency) 세 갈래이고, 이 셋이 어떤 생성형 애플리케이션에서도 성능을 이루는 세 기둥이라고 함.
  45. 비용과 지연을 줄이는 한 방법이 시맨틱 캐싱인데, 생성형 AI에서는 질문도 응답도 정확히 똑같은 단어로 반복되지 않는다고 함.
  46. 그래서 캐시는 정확히 같은 질문이 아니라 비슷한 질문이 이미 있었는지를 찾는 식으로 작동한다고 함.
  47. 비슷한 질문이 캐시에 있으면 파운데이션 모델을 다시 호출하지 않아도 돼서 비용을 아끼고, 모델이 답을 새로 만드는 시간이 줄어 지연도 준다고 함.
  48. 세 번째는 관측 가능성(observability)인데, 사용자 질의·검색 결과·모델 응답을 전부 로깅해야 애플리케이션을 모니터링하고 개선할 수 있다고 함.
  49. 예전에는 관측 가능성을 "중요한 요소"라고 말했지만 이제는 관측 가능성 없이는 파일럿조차 시작하지 말라고 말한다고 함.
  50. 문제 제보가 들어와도 로그가 없으면 뭐가 잘못됐는지 찾을 방법이 없다는 게 그 이유라고 함.
  51. 관측 가능성으로 쌓인 데이터를 평가에 써야 하는데, RAG 애플리케이션이면 컨텍스트 관련성부터 봐야 한다고 함.
  52. 검색 결과가 관련 없으면 그걸 모델 앞에 놓고 비용을 들여 나쁜 응답을 받을 이유가 없으니, 검색 결과가 좋은지부터 확인한 다음에야 프롬프트를 증강한다고 함.
  53. 다들 빠르게 만드느라 이 순서를 잊어버리기 쉬운데, 애플리케이션과 사고방식 둘 다 다시 평가해야 한다고 함.
  54. 애플리케이션 종류마다 지표도 달라서, 요약 사용 사례라면 요약에 맞는 지표를 써야 한다고 함.
  55. 평가에서 문제를 발견하면 업데이트해야 하는데, 데이터가 오래돼서(stale) 답이 오래된 경우도 있고 전략 자체를 다시 손봐야 하는 경우도 있다고 함.
  56. 업데이트했다고 끝난 게 아니라 다시 테스트해야 하고, 이 평가들이 자동으로 돌아가는 테스트 스위트가 있어야 한다고 함.
  57. 업데이트할 때마다 검증 경로가 정해져 있으면 프로덕션에서 틀릴 확률은 줄고 고품질 애플리케이션일 확률은 크게 늘어난다고 함.
  58. 테스트를 거듭 거친 뒤에야 비로소 프로덕션에 내놓고 성과를 거둘 준비가 된다고 함.

한줄 코멘트. 베드록 기능 나열은 결국 AWS 홍보이고, 남는 알맹이는 "검색 결과부터 평가하고 나서 모델에 넘겨라"는 순서 하나임.

07

음성 · 멀티모달

  1. 이 발표는 구글 딥마인드(Google DeepMind)에서 제미나이 API와 구글 AI 스튜디오(Google AI Studio)의 개발자 경험을 맡고 있는 토르 셰프(Thor Schaeff)가 AI 엔지니어 컨퍼런스에서 19분간 한 것으로, 업계 전체 오디오 동향이 아니라 딥마인드가 만들고 있는 것만 다룬다고 미리 밝힘.
  2. 발표자는 지난해 11월 팀에 합류했는데, 합류한 바로 다음 날 제미나이 3가 출시됐다고 함.
  3. 최근 오픈 모델 쪽에서는 젬마 4(Gemma 4)를 냈는데, 오디오 이해 기능이 들어 있어 온디바이스(on-device, 서버 없이 기기 안에서 바로 돌리는 방식)로도 쓸 수 있다고 함.
  4. 생성 미디어(gen media) 쪽은 이미지·영상 생성 모델이 있고 영상에는 오디오 생성도 포함되는데, 최근에는 비디오 3.1 라이트를 냈다고 언급함.
  5. 오디오 모델 쪽에서는 최근 제미나이 3.1 플래시 라이브(Gemini 3.1 Flash Live)를 출시함. 양쪽이 동시에 말하고 들을 수 있는 풀 듀플렉스(full duplex) 방식의 실시간 소리-소리 대화 모델이고, 텍스트·음성·영상을 실시간으로 함께 받아들이는 멀티모달 모델이라고 함.
  6. 오디오 관련 모든 것의 바탕은 제미나이 프런티어 모델이고, 제미나이 3는 오디오를 이해하는 능력이 뛰어나다고 함. 단순히 받아적는 게 아니라 안에 담긴 뉘앙스까지 이해한다는 것임.
  7. 여기서 뉘앙스는 말의 내용뿐 아니라 맥락·감정·말하는 속도(pacing)처럼 텍스트로는 안 잡히는 것들까지 포함한다고 함.
  8. 오디오 이해 모델의 목표는 세 가지 - 깊이 이해하고(deeply comprehend), 풍부하게 받아적고(richly transcribe), 튼튼하게 추론하는(robustly reason) 것이라고 밝힘.
  9. 언어·방언·억양·모달리티가 섞여 있어도 이음매 없이 처리하고, 여러 사람이 동시에 말해도 알아듣고, 언어가 중간에 바뀌어도 매끄럽게 따라간다고 함.
  10. 이걸 보여주려고 에코스크립트(EchoScript)라는 걸 만들었는데, 제미나이 3 플래시 프리뷰로 오디오 녹음을 분석해 정보를 뽑아내는 앱이고 구글 AI 스튜디오 갤러리에서 써볼 수 있다고 함.
  11. 순수 전사 모델과 다른 점은 한 번의 API 요청 안에서 요약, 화자 이름표, 타임스탬프, 언어, 감정까지 한꺼번에 뽑아낸다는 것임.
  12. 데모에서 발표자가 독일어로 자기소개를 했는데, 평소라면 독일어 억양이 화난 것으로 분류될 텐데 이번엔 행복으로 분류됐다고 함.
  13. 프랑스어로 "제 프랑스어 실력이 형편없어 죄송하다"고 사과했는데, 슬프게 들릴 만한 내용인데도 중립으로 분류됐다고 함.
  14. 일본어 시도는 오역이 나서 실패했고, 중국어(만다린) 시도는 맞게 나온 것 같다고 함. 다만 청중 중에 확인해줄 사람이 없어 그대로 믿고 넘어간다고 함.
  15. 이 결과들은 화자 구분, 이름표(문맥이 있으면 이름으로), 정확한 타임스탬프, 언어, 번역, 감정(행복·슬픔·화남·중립) 분류, 전체 요약을 한 번에 요청한 데서 나온 것이고, 응답 스키마(response schema, 모델 출력 형식을 미리 정해두는 틀)를 줘서 구조화된 형태로 받았다고 함.
  16. 이 오디오 이해가 음성 생성과 실시간 대화 생성의 밑바탕이 되는데, 특정 억양이나 속도가 실제로 어떻게 들리는지 아는 게 핵심이라고 함.
  17. 음성 생성 방식은 기존 TTS(text-to-speech, 문자를 음성으로 바꿔주는 기술) 업체들과 다르다고 함. 성별·억양·언어로 필터링하는 거대한 목소리 라이브러리를 두는 대신,
  18. 제미나이는 기본 목소리가 30개 안팎이고, 그 목소리에게 특정 방식으로 연기하라고 지시하는 식이라고 함. 오디오 이해 능력 덕분에 하나의 목소리를 원하는 억양·성격으로 바꿀 수 있다는 것임.
  19. 이걸 써볼 수 있는 앱이 보이스 라이브러리(Voice Library)이고 역시 AI 스튜디오 갤러리에 있다고 함.
  20. 프롬프트 구조는 오디오 프로필, 장면(scene), 감독 노트(director's note, 배우에게 연기를 지시하듯 주는 지침)로 이뤄지는데, 사람 배우에게 연기를 지시하는 것과 비슷하다고 함.
  21. 데모에서 "하이피치 아일랜드 남성"을 요청했더니 제미나이 3 플래시가 시스템 프롬프트를 만들어줬는데, 캐릭터 이름은 피니언(Finian)이고 장면은 클레어 카운티 해안의 붐비는 아늑한 펍으로 설정됨.
  22. 기본 목소리(표준 미국식 억양)로 읽은 문장과, 아일랜드 억양 지시를 넣은 뒤 다시 읽은 같은 문장을 나란히 들려줌.
  23. 제퍼(Zephyr)라는 목소리로도 같은 걸 보여줌. 원래는 표준 미국 영어 억양인데, 지시를 넣자 싱가포르식 영어로 바뀌면서 "치킨라이스 라(lah)" 같은 현지 표현까지 자연스럽게 붙었다고 함.
  24. 이것도 결국 오디오 이해가 뒷받침하는 것이고, 모델이 특정 상황이 실제로 어떻게 들리는지 이해하고 있어야 음성 생성을 그에 맞게 바꿀 수 있다는 것임.
  25. 마지막으로 네이티브 오디오, 소리에서 소리로 바로 가는 멀티모달 실시간 모델을 소개함. 몇 주 전 출시한 제미나이 3.1 플래시 라이브가 그것이라고 함.
  26. 스피치투스피치(speech-to-speech) 실시간 멀티모달 모델이고, 웹소켓(WebSocket, 실시간으로 데이터를 주고받는 연결 방식)을 통해 텍스트·오디오·영상을 실시간으로 받아 실시간 오디오 응답과 텍스트 트랜스크립트를 함께 돌려준다고 함.
  27. 오디오 분야에서는 벤치마크를 그다지 신뢰할 수 없다고 발표자가 직접 밝힘.
  28. 대신 강조한 건 사고와 추론이 모델 안에 직접 내장돼 있다는 점임. 텍스트로 옮긴 뒤 LLM(거대언어모델)을 거쳐 지능을 얻는 캐스케이딩 파이프라인(cascading pipeline, 여러 모델을 순서대로 거치게 하는 구조)과 달리, 오디오 모델 자체에 지능이 들어 있다는 것임.
  29. ai.studio/live에서 신용카드 없이 무료로 직접 써볼 수 있다고 함.
  30. 데모에서는 친근한 아일랜드 억양으로 말하라는 시스템 지시를 넣고 카메라 입력을 연결함.
  31. "저 보이세요?"라고 묻자 모델이 화면을 보고 발표자의 옷차림(제미나이 셔츠, 거꾸로 쓴 모자)을 언급하며 반응함.
  32. 독일어로 시를 지어달라고 요청하자 실제로 독일어 시를 지어줬는데, 아일랜드 억양을 독일어에도 그대로 적용해버렸다고 함.
  33. 발표자는 이걸 보고 시스템 지시를 언어마다 다르게 조정해야 한다는 걸 보여주는 사례라며 재미있어함.
  34. 화면 공유도 입력으로 받을 수 있는데, 현재는 초당 최대 1프레임까지 영상 프레임을 오디오와 함께 수신한다고 함.
  35. 개발자용 예시 코드도 문서에 링크돼 있는데, 서버 대 서버 연결은 파이썬, 클라이언트 대 서버 연결은 자바스크립트로 시작하는 예시를 제공한다고 함.
  36. 제미나이 스킬(Gemini skills)도 추천함. 라이브 API를 포함한 모든 제미나이 API용 코딩 에이전트 스킬을 공개했는데, 실시간 오디오 작업은 특히 까다로워서 이 스킬을 코딩 에이전트에 설치하면 도움이 된다고 함.
  37. 음악 쪽에서는 최근 리라 3(Lyra 3)을 냈고, 이제 가사가 있는 음악까지 생성할 수 있다고 함.
  38. 모델이 둘로 나뉘는데, 리라 3 클립(Lyra 3 Clip)은 30초짜리 징글을 만들고, 리라 3 프로(Lyra 3 Pro)는 곡 전체 길이를 만든다고 함.
  39. 발표자는 이걸 다 엮어서 라이프 주크박스(Life Jukebox)라는 앱을 직접 만들었다고 함. 예전에 라디오 방송국에 전화해서 신청곡을 걸던 시절에서 착안했다고 밝힘.
  40. 실시간 제미나이 라이브 모델에 리라를 호출하는 도구를 붙여서, 대화하면서 바로 노래를 만들게 하는 구조라고 함.
  41. 데모에서는 모델이 주크박스 DJ 역할을 맡아 어떤 분위기의 곡을 원하는지 물어봄.
  42. 발표자가 "영국 스타트업 씬을 다룬 독일 테크노 슐라거(Schlager)"를 요청하자, 모델이 재미있어하며 쿵쾅대는 테크노 비트에 한스 짐머(Hans Zimmer) 스타일을 얹겠다고 반응함.
  43. 추가로 "미친 듯한 에너지로, 가사는 알아서 놀랍게 써 달라"고 요청하자 곡을 만들기 시작함.
  44. 완성된 곡은 영국 스타트업 씬을 소재로 한 독일 테크노 슐라거로, 그 자리에서 재생해 들려줌.
  45. 발표자는 슬라이드에 관련 링크가 다 있다고 안내하며, 오디오를 맡아준 스태프에게 감사를 표하고 발표를 마침.

한줄 코멘트. 전사·음성 생성·실시간 대화·음악까지 네 갈래가 전부 하나의 오디오 이해 모델에서 갈라져 나온다는 게 이 발표의 뼈대이고, 데모마다 그 이해가 어떻게 다른 산출물로 갈아치워지는지를 보여주는 방식임.

  1. 패트릭 뢰버(Patrick Löber)는 구글 딥마인드(Google DeepMind)에서 제미나이(Gemini) API와 AI 스튜디오(AI Studio)를 맡고 있는 기술 스태프임. 발표 주제는 애니투애니(any-to-any, 어떤 형태로 넣어도 어떤 형태로 받는 방식), 즉 네이티브 멀티모달(multimodal, 텍스트·이미지·소리처럼 여러 형태 정보를 함께 다루는 것) 에이전트 만들기라고 함.
  2. 다룰 건 멀티모달 이해, 멀티모달 생성, 실시간 상호작용, 그리고 이 셋을 합쳐 예제 앱을 함께 만드는 것이라고 함. 세션이 끝나면 청중도 노트북LM(NotebookLM) 미니 복제본을 직접 만들 수 있어야 한다고 함.
  3. 애니투애니란 제미나이 API가 텍스트뿐 아니라 코드·이미지·오디오·비디오·URL·구글 검색까지 입력으로 받고, 텍스트·이미지·음성·비디오·함수 호출·코드까지 출력으로 내놓는다는 뜻이라고 설명함.
  4. 다만 이 슬라이드는 조금 오해를 준다고 스스로 밝힘. 지금은 이 모든 걸 하나로 처리하는 단일 멀티모달 모델이 아니라, 구글 딥마인드가 그리는 더 큰 비전이라고 함.
  5. 지금 상태는 이렇다고 함. 메인 제미나이 모델(현재 제미나이 3 계열)은 여러 모달리티(modality, 텍스트·이미지·소리 같은 정보 형태 종류)를 이해하지만 출력은 텍스트뿐이라고 함.
  6. 그 대신 이미지 생성용 나노 바나나(Nano Banana), 음성 생성 모델처럼 메인 제미나이 모델을 기반으로 한 특화 네이티브 생성 모델들이 따로 있다고 함.
  7. 젬마(Gemma)도 언급함. 텍스트·이미지·비디오 입력을 받고, 더 작은 모델은 오디오 입력까지 받아서 멀티모달 에이전트를 로컬에서도 만들 수 있다고 함.
  8. 오늘은 제미나이를 이용한 멀티모달 이해, 네이티브 이미지 생성, 네이티브 음성 생성, 시간이 남으면 라이브 API까지 네 가지에 집중하겠다고 함.
  9. 이걸 엮어서 노트북LM 미니 복제본을 만들거나 적어도 만들 재료를 주겠다고 함. 청중 대부분이 노트북LM을 써 봤다고 손을 들었다고 함.
  10. 노트북LM은 여러 소스를 넣으면 팟캐스트 형태로 설명하는 오디오 오버뷰 기능이 인기고, 인포그래픽(infographic, 정보를 도표·그림으로 압축해 보여주는 이미지) 생성도 꽤 쓸 만하다고 함.
  11. 이걸 워크플로가 아니라 에이전트(agent, 사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)로 만들고 싶다고 함. 파이프라인을 하드코딩하지 않고 무엇을 만들지 에이전트가 직접 판단하게 한다는 뜻이라고 함.
  12. 아키텍처는 추론 모델이 무엇을 만들지 결정하고, 그 결정을 함수 호출(function call, 에이전트가 미리 정해둔 함수를 스스로 골라 실행하는 것)로 다른 특화 모델에 넘기는 구조라고 함.
  13. 1단계는 멀티모달 이해고, 2단계는 제미나이를 추론 모델로 쓰는 에이전트 루프라고 함. 이 루프가 여러 도구를 불러 각기 다른 모달리티를 생성하고, 자산이 충분한지 스스로 판단하며 반복한다고 함.
  14. 이렇게 반복한 끝에 텍스트, 음성, 인포그래픽을 결과물로 얻는다고 함.
  15. 예제로는 "어텐션 이즈 올 유 니드(Attention Is All You Need)" 논문 학습을 들었음. PDF·이미지·비디오(강의나 튜토리얼 영상)·음성 메모까지 넣고, 여러 소스를 가로질러 연결 짓는 크로스모달 이해를 시키고 싶다고 함.
  16. 이걸 제미나이로 구현하는 건 실제로 아주 간단하다고 함. AI 스튜디오(ai.studio)에서 API 키를 무료로 받고 SDK를 설치하면 되며, SDK는 여러 언어로 제공된다고 함.
  17. 그다음 PDF·비디오·MP3 파일을 그대로 업로드하거나, 작은 파일이면 인라인 데이터로 바로 넣을 수 있다고 함.
  18. 팁으로 제미나이 API 스킬(skill)을 언급함. 이 코드를 굳이 외우지 않아도, 에이전트에 이 스킬을 붙이고 만들라고 시키면 알아서 제미나이 모델을 다룰 줄 안다고 함.
  19. 코드는 client.models.generate_content를 호출하는 게 전부이고, 여기서는 제미나이 3 플래시(Gemini 3 Flash)를 쓴다고 함. 여러 리소스를 컨텐츠 목록에 넣고 분석해서 요약하라고 지시하면 된다고 함.
  20. 실전 팁도 줌. 플래시(Flash)는 물론 가장 작은 플래시라이트(Flashlight)도 오디오 전사(transcription, 소리를 글로 옮겨 적는 것)를 꽤 잘한다고 함. 프롬프트에 "이 파일 전사문을 만들어라"라고만 하면 된다고 함.
  21. 오디오는 1분이 토큰(token, 모델이 다루는 글자·단어 단위 조각) 1920개로 환산된다고 함. 제미나이 토큰 한도가 100만 개라 계산하면 오디오를 9시간 넘게 넣을 수 있다는 뜻이라고 함.
  22. 비디오는 대략 1시간 분량이 그 한도에 해당한다고 함. 다만 설정을 조절하면 더 긴 오디오도 넣을 수 있는 여지가 있다고 함.
  23. 특정 구간만 보게 할 수도 있다고 함. 예를 들어 5분부터 15분까지만 분석하라고 시킬 수 있다는 것임.
  24. 파일 API(File API)를 쓰면 더 큰 파일도 쉽게 업로드할 수 있고, URL이나 유튜브 링크도 바로 넣을 수 있다고 함.
  25. 컨텍스트 캐싱(context caching, 이전에 넣은 내용을 다시 계산하지 않고 재사용하는 기능)도 API에 내장돼 있다고 함. 긴 파일에 반복 질의를 할 때 특히 유용하고, 비용을 90% 아낄 수 있다고 함.
  26. 여기까지가 멀티모달 이해임. 제미나이로 여러 소스를 이해하고 요약을 만드는 단계까지 왔다는 게 첫 번째 체크포인트라고 함.
  27. 다음은 멀티모달 생성 단계임. 제미나이를 두뇌로 삼는 에이전트 루프에 함수 호출을 결합해 특화된 네이티브 생성 모델들을 호출하고, 자산이 충분한지 스스로 판단하게 한다고 함.
  28. 이때도 코드는 거의 같다고 함. client.models.generate_content를 호출하되 이번엔 제미나이 3.5 플래시 이미지 프리뷰(gemini-3.5-flash-image-preview)를 쓴다고 함. 이건 더 유명한 이름인 나노 바나나 2(Nano Banana 2)라고 밝힘.
  29. 프롬프트에 인포그래픽을 만들라고 지시하면 슬라이드 형태의 그래픽을 그려낸다고 함.
  30. 텍스트투스피치(text-to-speech, 문자를 음성으로 바꾸는) 모델은 아직 제미나이 2.5 기반이라고 함. 설정을 바꾸면 화자 두 명이 나오는 팟캐스트 스타일 오디오 파일도 만들 수 있다고 함.
  31. 이 모델로 만든 예시를 들려줌. "어텐션 이즈 올 유 니드" 논문에 나온 신경망 구조인 트랜스포머(transformer)를 2분 만에 설명해 주는 음성이었다고 함.
  32. 함수 호출 설정법도 보여줌. 함수 이름과 설명을 선언하면 모델이 이 함수의 용도를 이해하는 데 도움이 된다고 함.
  33. 이미지 생성 함수는 파라미터로 이미지가 어떻게 보여야 하는지 설명하는 문자열 하나만 받는다고 함. 음성 생성 함수도 같은 방식으로 선언한다고 함.
  34. generate_content를 호출할 때 이 함수들을 도구(tools)로 설정하고, 프롬프트에도 함수 사용법을 함께 넣어야 한다고 함.
  35. 예시 에이전트 프롬프트를 보여줌. 앞서 여러 모달리티에서 합성해 둔 학습자료를 주고, "너는 리서치 에이전트 파트너다, 이 학습 가이드를 여러 자료로 보강하라"고 지시하는 내용이라고 함.
  36. 어떤 개념이 시각 다이어그램이 필요할 만큼 복잡한지 판단해 generate_image를 부르고, 어떤 절이 음성 요약이 어울리는지 판단해 generate_speech를 부르라고 지시했다고 함.
  37. 이게 멀티모달 생성용 에이전트 함수 호출을 세팅하는 데 필요한 전부라고 함.
  38. 네이티브 생성이 중요한 이유도 짚음. 이런 모델을 "네이티브"라 부르는 건 메인 제미나이 모델을 기반으로 만들어져서, 제미나이 훈련의 상당 부분이 그대로 들어가 있기 때문이라고 함.
  39. 그래서 이 모델들은 세상을 이해한다고 함. 트위터에서 본 나노 바나나 1(Nano Banana 1) 데모를 예로 들었는데, 지도 위에 화살표만 그리고 "여기 보이는 걸 그려달라"고 하면 금문교(Golden Gate Bridge) 사진을 정확히 그려낸다고 함.
  40. 교육 쪽 예시도 보여줌. 나노 바나나 2로 수학 숙제를 채점해서 정정 내용까지 사진 위에 그려 넣을 수 있는데, 모델이 수학 자체를 이해하기 때문이고 이미지 위에 코드를 생성하는 것도 가능하다고 함.
  41. 음성 모델은 다국어를 지원하고 억양과 어조까지 이해한다고 함. 발표 중 영국식 억양과 바이에른(Bavarian) 독일어 억양으로 만든 음성 샘플을 직접 들려줬다고 함.
  42. 이해와 생성 두 부분을 다 다뤘으니 이게 벌써 노트북LM 미니 복제본이라며 두 번째 체크포인트를 짚음.
  43. 이제 실시간 상호작용, 즉 라이브 API(Live API)를 짧게 소개함. 새 모델인 제미나이 3.1 플래시 라이브(Gemini 3.1 Flash Live)를 오디오투오디오(audio-to-audio, 오디오가 들어가서 오디오로 바로 나오는) 모델이라고 부른다고 함.
  44. 단일 아키텍처라 서로 다른 모델을 이어 붙이던 캐스케이드(cascaded, 여러 모델을 단계별로 연결한) 파이프라인이 더는 필요 없다고 함. 그 덕에 훨씬 자연스러운 대화가 가능하다고 함.
  45. 시간이 없어 라이브 데모는 못 보여준다며, 대신 동료 토르(Thor)가 찍은 영상을 틀어줌. ai.studio/live에서 직접 써 볼 수 있다고 함.
  46. 영상 속에서 "제미나이 안녕, 오늘 어때?"라고 물으면 "잘 지내고 있다, 물어봐 줘서 고맙다"고 답하고, "내가 보이냐"고 물으면 "짧은 머리에 수염, 파란 셔츠 위에 짙은 색 재킷을 입은 모습이 또렷이 보인다"고 답했다고 함.
  47. 라이브 API도 코드로 붙일 수 있고 마찬가지로 스킬로 설정해 두면 된다고 함. 이제 세 체크포인트를 다 지났고, 이 패턴은 다른 어떤 분야로도 그대로 옮길 수 있다고 함.
  48. 마지막으로 짧게 덧붙임. 그날 아침 키노트에서 나온 멀티모달 임베딩(embedding, 서로 다른 데이터를 같은 수치 벡터 공간으로 바꿔 비교할 수 있게 하는 방법) 모델은 여러 모달리티를 하나의 벡터 공간으로 합쳐 멀티모달 검색 같은 응용을 가능하게 한다고 함. 그리고 젬마 4(Gemma 4)로 로컬에서도 이미지·오디오 포함 비디오까지 멀티모달 이해를 할 수 있다고 함.

한줄 코멘트. "애니투애니"라고 부르지만 실은 텍스트만 내놓는 이해 모델 하나에 이미지·음성 생성 모델을 함수 호출로 이어 붙인 구조이고, 라이브 API의 오디오투오디오 단일 모델만이 그 이어붙임을 정말로 없앤 사례임.

  1. 구글 딥마인드 리서치 과학자 샌더 딜러먼(Sander Dieleman)이 생성 미디어(generative media) 팀에서 겪은 이야기를 들려줌. VEO·나노바나나(NanoBanana) 같은 모델을 만드는 팀이라고 밝힘.
  2. 이 발표는 이런 모델을 대규모로 훈련하는 데 실제로 뭐가 들어가는지 보여주는 뒷단 이야기라고 함.
  3. 오디오·비주얼 데이터 생성은 요즘 디퓨전(diffusion, 노이즈를 점점 지워가며 데이터를 만드는 방식) 모델링을 주로 쓴다고 함. 언어 모델이 자기회귀(autoregression, 앞 토큰을 보고 다음 토큰을 순서대로 예측하는 방식)에 기대는 것과 다른 지점이라고 짚음.
  4. 다룰 주제는 여덟 개임 — 데이터 큐레이션, 표현(representation), 모델링, 아키텍처, 대규모 훈련, 샘플링, 증류(distillation), 제어(control).
  5. 모델링과 샘플링 쪽에 시간을 더 쓰겠다고 미리 밝힘.
  6. 개인 블로그 sander.ai에 디퓨전 관련 글을 올려둔다고 소개함.
  7. 데이터 큐레이션이 고품질 결과에 얼마나 중요한지부터 강조함.
  8. 자기 박사과정 시절엔 다들 같은 벤치마크 데이터셋만 써서 성능을 비교했기 때문에 정작 자기 데이터를 들여다보는 훈련이 안 돼 있었다고 함.
  9. 데이터를 개선하는 데 쓴 시간이 모델 자체를 손보는 시간보다 나은 투자일 때가 많다고 함.
  10. 데이터 큐레이션은 공개 논문이 거의 없고 모델 품질의 핵심 비법이라 자세히는 못 밝힌다고 선을 그음.
  11. 시각 데이터의 기본 표현은 픽셀 격자임 — 이미지는 2차원 격자, 영상은 시간까지 더한 3차원 격자라고 함.
  12. 디퓨전 초창기에는 픽셀을 그대로 모델에 넣었고 그것도 꽤 잘 됐다고 함.
  13. 하지만 해상도나 영상 길이를 키우면 픽셀 텐서가 메모리에서 감당 안 되게 커짐 — 1080p 30초 영상 한 장이 훈련 예시 하나만으로 수 기가바이트라고 예로 듦.
  14. JPEG나 기존 영상 코덱 같은 압축 표현은 안 쓴다고 함. 크기를 줄이는 데만 최적화돼 있어 생성 모델링에 필요한 구조를 오히려 지워버리기 때문이라고 함.
  15. 대신 오토인코더(autoencoder, 입력을 그대로 복원하도록 훈련하되 중간에 병목을 둬 압축 표현을 배우게 하는 신경망)로 자체 압축기를 학습한다고 함.
  16. 인코더-디코더로 이미지를 넣고 같은 이미지를 다시 뱉게 훈련하면 병목 지점에 잠재표현(latent representation)이 생긴다고 설명함.
  17. 그렇게 뽑은 잠재표현 위에서 두 번째 단계로 생성 모델(자기회귀든 디퓨전이든)을 훈련한다고 함.
  18. 오디오·비주얼 데이터는 같은 파라미터 예산에서 대체로 디퓨전 쪽이 결과가 더 좋다고 함 — 그래서 요즘은 디퓨전을 주로 쓴다고 밝힘.
  19. 잠재공간에서 뽑은 샘플도 압축된 형태라 미리 훈련해둔 디코더로 다시 픽셀 공간으로 되돌린다고 함.
  20. 스테이블 디퓨전 오토인코더 예시를 듦 — 256×256 RGB 이미지가 32×32 잠재 격자로 줄어드는데 공간 구조(위상)는 그대로 유지된다고 함.
  21. 해상도를 32×32로 낮추는 대신 채널 수를 늘려서 단순 리사이즈 때 사라질 고주파 디테일 정보를 붙잡아 둔다고 설명함.
  22. 그래도 잠재표현 전체 텐서 크기는 원본 이미지보다 훨씬 작고, 영상은 시간축까지 있어 중복이 더 많아 두 자릿수(100배가량)까지 줄일 수 있다고 함.
  23. 이 정도 압축이 데이터를 메모리에 담을 수 있느냐 없느냐를 가르는 차이라고 강조함.
  24. 이 압축 방식은 H.265 같은 실제 코덱보다 일부러 더 원시적으로 설계했다고 밝힘. 신경망 아키텍처가 원본 픽셀의 격자 구조에 크게 의존하는 귀납 편향(inductive bias)을 갖고 있어서라고 함.
  25. EQ-VAE라는 논문을 인용하며 잠재 채널의 주성분(principal component)을 RGB로 매핑해 잠재공간을 시각화한 예시를 보여줌.
  26. 이 시각화에서도 어떤 동물인지 알아볼 수 있을 만큼 잠재표현이 의미 정보는 그대로 두고 국소적인 질감·미세 구조만 압축한다고 설명함.
  27. 잠재표현을 얻은 뒤 생성 모델링으로 넘어가는데, 자기회귀는 이미지를 억지로 순서 있는 시퀀스로 바꿔야 해서 언어보다는 덜 자연스럽다고 함.
  28. 디퓨전은 반복적 정제(iterative refinement)라는 비슷한 목표를 다른 방식으로 이룬다고 함. 이미지에 노이즈를 점점 더해 정보를 파괴하는 손상 과정을 먼저 정의하고, 그 노이즈를 지우는 디노이저(denoiser) 모델을 학습한다고 함.
  29. 토끼 이미지에 가우시안 노이즈를 점점 더하는 예를 보여줌 — 노이즈가 적을 땐 수염 같은 디테일만 사라지고 실루엣은 남지만, 노이즈가 많아지면 전체 구조까지 사라진다고 함.
  30. 미세한 디테일이 먼저 흐려지고 전역 구조는 나중에 흐려진다는 점이 핵심이라고 짚음.
  31. 디퓨전 샘플링을 2차원 도식으로 설명함 — 깨끗한 이미지 X0에 노이즈를 더해 XT라는 임의 시점에 도달한 상태에서 시작한다고 함.
  32. 디노이저는 노이즈 낀 이미지만 보고 원래 어떤 깨끗한 이미지에서 왔을지 예측하는데, 정보가 이미 지워졌으므로 답이 하나로 안 정해지는 문제(ill-posed)라고 함.
  33. 그래서 모델은 가능한 이미지들의 평균을 예측하게 되고, 한 번에 예측하면 뿌옇게 나온다고 설명함.
  34. 이 예측은 특정 이미지 하나가 아니라 이미지 공간의 한 영역, 즉 나아갈 대략적인 방향을 가리키는 것이라고 함.
  35. 그래서 샘플링은 그 방향으로 한 번에 크게 뛰지 않고 작은 걸음만 내디딘 뒤 모델에 다시 물어보는 식으로 진행한다고 함.
  36. 신경망 파라미터 공간에서 옵티마이저가 방향을 알려줘도 그 방향이 국소적으로만 유효해서 작은 스텝만 밟는 것과 같은 원리라고 비유함.
  37. 많은 디퓨전 샘플링 알고리즘은 작은 디노이징 스텝 뒤에 새 노이즈를 조금 다시 더한다고 함 — 방금 지운 것보다는 적은 양이라고 함.
  38. 이 트릭을 쓰는 이유는 디노이저가 완벽하지 않아 생기는 실수가 계속 누적되는 걸 막기 위해서라고 설명함. 새 노이즈가 그 실수를 가려주는데, 모든 알고리즘이 이 트릭을 쓰지는 않는다고 덧붙임.
  39. 이 과정을 XT-1, XT-2 식으로 반복하면서 매번 새 예측을 받고, 예측이 가리키는 입력 공간의 영역이 점점 좁아져 결국 한 점(하나의 이미지)으로 수렴한다고 설명함.
  40. 왜 이 방식이 이미지·영상에 잘 통하는지를 푸리에 분석(Fourier analysis, 신호를 주파수 성분으로 분해하는 분석법)으로 설명하겠다고 함.
  41. 이미지넷(ImageNet) 이미지 네 장의 2차원 푸리에 변환을 구해 크기(magnitude)와 위상(phase)으로 나누고, 크기 스펙트럼만 방사 평균(radial averaging)해 1차원 그래프로 요약함.
  42. 로그-로그 그래프로 그리면 직선이 나오는데, 이건 주파수와 에너지 사이에 거듭제곱 법칙(power law)이 있다는 뜻이고 언어 모델의 스케일링 법칙과 같은 형태라고 함.
  43. 가우시안 노이즈의 스펙트럼은 모든 주파수를 고르게 담아 평평한 반면, 실제 이미지는 주파수가 높아질수록 에너지가 줄어드는 내리막 직선이라고 함.
  44. 이미지에 노이즈를 더하면 처음엔 이미지 스펙트럼을 따라가다가 어느 지점부터 노이즈 스펙트럼에 묻힌다고 설명함.
  45. 즉 노이즈를 더할수록 먼저 고주파 성분이 가려지고, 더 더하면 저주파 성분까지 차례로 가려진다는 뜻이라고 함.
  46. 이 관찰을 스스로 "디퓨전은 사실상 스펙트럴 자기회귀(spectral auto-regression)"라고 요약함. 저주파(전체 구도)에서 고주파(세부)로 순서대로 생성하는 셈이라는 것임.
  47. 딱딱한 자기회귀와 완전히 같지는 않지만, 이미지 생성에 더 맞는 표현공간에서 비슷한 일을 한다고 설명함. 디테일을 넣기 전에 의미부터 스케치하는 자연스러운 순서이며, 이 덕분에 훈련할 때 지각적으로 더 중요한 주파수에 가중치를 더 실을 수 있다고 함.
  48. 디노이저 신경망 아키텍처로 넘어가서, 초기에는 이미지 분할(segmentation)용으로 설계된 합성곱 신경망인 U-Net을 썼다고 함. 입출력 차원이 같은 복원 작업 전반에 잘 맞았고 스테이블 디퓨전도 U-Net 기반이라고 함.
  49. 이후 사람들이 트랜스포머(transformer)도 되는지 시도했고 실제로 잘 작동한다고 함. 언어 모델과 달리 인과 마스크(causal mask)를 쓰지 않고 양방향 어텐션을 그대로 써도 된다고 설명함.
  50. 언어 모델 쪽에서 트랜스포머를 스케일하는 노하우를 그대로 재활용할 수 있어서 실용적으로도 트랜스포머를 쓰는 게 맞다고 함.
  51. 영상 생성에서는 자기회귀와 디퓨전 사이의 긴장이 있다고 함 — 완전 자기회귀 영상 모델은 높이×너비×시간 큐브를 통째로 시퀀스로 펴서 토큰 단위로 생성해야 한다고 함.
  52. 대부분의 최신 영상 생성 모델은 대신 이 3차원 픽셀 볼륨 전체에 노이즈를 같이 얹고 같이 지우는 방식을 쓴다고 함.
  53. 이분법이 아니라 중간 형태도 있다고 함 — 시간축으로는 자기회귀(프레임마다 순서대로 생성)하되 각 프레임 자체는 디퓨전으로 만드는 하이브리드 방식이라고 함.
  54. 이 하이브리드는 실시간 영상 생성처럼 시간축을 순서대로 갈 수밖에 없는 상황에 잘 맞는다고 함 — 지니(Genie)를 예로 듦.
  55. 대규모 훈련에 대해서는 짧게만 짚는다고 함. 파라미터를 키우는 게 낫지만 언어 모델만큼 크게 키우진 않는다고 밝힘.
  56. 어느 규모까지는 배치를 여러 칩에 나누는 데이터 병렬(data parallelism)로 충분하지만, 그 이상은 모델 자체를 여러 칩에 나누는 모델 병렬(model parallelism)이 필요하다고 함.
  57. 모델 구축에는 주로 JAX를 쓴다고 함 — 칩 간 통신을 자동으로 최소화하면서 모델을 샤딩(sharding, 나눠 담기)해주는 도구가 잘 갖춰져 있다고 밝힘.
  58. 샘플링에서 확률적(stochastic) 샘플링과 결정론적(deterministic) 샘플링의 대비를 설명함 — 일부 알고리즘은 매 스텝 뒤 노이즈를 다시 더하고, 일부는 안 더한다고 함.
  59. 결정론적 샘플링 알고리즘은 초기 노이즈와 최종 샘플이 일대일로 대응돼 증류(distillation) 과정에서 특히 쓸모 있다고 함.
  60. 확률적 알고리즘은 대신 오차 누적에 좀 더 강건하다는 트레이드오프가 있다고 함.
  61. 샘플링에서 가장 중요하게 다룰 개념은 가이던스(guidance)라고 함. 자기회귀 모델에도 적용할 순 있지만 디퓨전 모델에서 유독 잘 통한다고 함.
  62. 가이던스 스케일이라는 하이퍼파라미터를 올릴수록 샘플 다양성은 크게 줄지만 품질은 그 모델이 원래 실력보다 훨씬 잘 나온다고 함.
  63. 디퓨전 모델이 같은 규모의 언어 모델보다 파라미터가 작아도 되는 이유가 바로 이 가이던스라는 강력한 트릭 덕분이라고 밝힘.
  64. 가이던스 작동 원리를 다시 그 2차원 도식으로 설명함 — 텍스트 프롬프트를 준 예측과 안 준 예측을 각각 구해서 그 차이(델타)를 구한다고 함.
  65. 프롬프트가 있으면 원래 이미지 후보가 훨씬 좁혀지므로 델타가 곧 "프롬프트가 알려주는 방향"이 된다고 설명함.
  66. 이 델타를 그대로 쓰지 않고 증폭시켜서 새로운 디노이징 방향으로 삼는 게 가이던스의 전부라고 함. 단순해 보이지만 베이지안(Bayesian) 추론에 가까운 근거가 있다고 함.
  67. 스텝마다 모델을 두 번(프롬프트 있이·없이) 평가해야 하지만 그 대가로 샘플 품질이 크게 오른다고 함.
  68. 2021년 GLIDE 논문(오픈AI의 초기 픽셀공간 디퓨전 모델) 예시를 들어 가이던스 유무 차이를 보여줌. 이 논문 이후로는 아무도 가이던스를 끄지 않게 됐다고 함.
  69. 가이던스를 켜면 다양성은 줄어도 프롬프트에 맞는 개별 품질은 크게 오른다고 설명함. 오늘날 모델에서 가이던스를 빼면 다들 놀랄 만큼 결과가 나빠질 거라고 함.
  70. 증류(distillation)는 언어 모델처럼 모델을 작게 만드는 게 아니라 샘플링에 필요한 스텝 수를 줄이는 작업이라고 정의함.
  71. 디퓨전 샘플링은 입력 공간을 지나는 비선형 경로를 스텝별로 근사하는 것인데, 디노이저는 각 지점에서 그 경로의 접선 방향만 예측한다고 함.
  72. 그러면 왜 접선이 아니라 경로가 끝나는 지점(최종 이미지)을 바로 예측하지 않느냐는 질문이 나오고, 이걸 하는 게 바로 일관성 모델(consistency model)이라고 설명함.
  73. 실제로 일관성 모델로 한 스텝에 샘플링을 시도하면 보통 잘 안 되는데, 원래 50번 걸리던 일을 한 번에 하라는 요구라 무리라고 함.
  74. 그래서 샘플링 경로 중 일부 구간에만 일관성 모델링을 적용해 서너 스텝 정도로 줄이는 절충안을 쓴다고 함.
  75. 제어(control) 얘기로 넘어가 텍스트 프롬프트가 지금까지 표준 제어 수단이었다고 함.
  76. 요즘은 텍스트만으로는 부족하다고 함 — 자기 자신을 영상에 넣고 싶으면 외모를 말로 묘사하는 대신 사진이나 짧은 영상을 참조로 줘서 조건화(reference-based generation)한다고 함.
  77. 영상 생성에서는 카메라 움직임이나 사건이 벌어지는 속도·타이밍처럼 텍스트로 욱여넣기 어려운 신호도 명시적으로 제어하고 싶어 한다고 함.
  78. 이런 조건화 신호를 언제 모델에 넣을지가 문제인데, 사전훈련(pre-training) 데이터 대부분엔 이런 정보가 없어서 보통 사후훈련(post-training) 단계에서 추가한다고 함.
  79. 사후훈련에서는 이 밖에도 인간 평가 기반의 선호 튜닝(강화학습이나 직접 선호 최적화)도 한다고 함.
  80. 청중 질의에서, 요즘 이미지 모델 특유의 스타일 문제(예로 바나나를 든 남자 밈)가 가이던스 때문인지 묻자, 큰 몫은 사후훈련 레시피에 있고 가이던스는 일부만 기여한다고 답함.
  81. 채도가 과하게 튄 이미지는 대개 가이던스 스케일이 너무 높다는 신호라고 설명함. 가이던스가 모든 노이즈 레벨에서 델타를 똑같이 증폭시키기 때문이라고 함.
  82. 그래서 샘플링 시작과 끝에서는 가이던스를 끄고 중간 구간에서만 세게 거는 식으로 스케일을 구간별로 바꾸는 게 최선이라는 논문이 있다고 소개함.
  83. 텍스트 디퓨전에도 같은 가이던스를 쓸 수 있냐는 질문에는, 원리상 가능하지만 얼마나 잘 통할지는 열린 질문이라고 답함.
  84. 가이던스는 조건 신호와 생성 대상 사이에 의미적 간극(semantic gap)이 있을 때 가장 잘 통한다고 설명함. 세그멘테이션 마스크처럼 픽셀과 같은 저수준 신호로 걸면 잘 안 통하는 것과 같은 이유로 언어 모델에서는 덜 쓰인다고 함.
  85. JAX가 파이토치(PyTorch)보다 샤딩·병렬화에 나은 이유를 묻자, 구글은 파이토치가 없던 시절부터 TPU를 오래 써와서 JAX가 애초에 그 목적으로 설계됐다고 답함. 다만 파이토치도 같은 일을 할 수 있다고 덧붙임.
  86. 스텝을 더 늘리면 이미지가 계속 좋아지느냐는 질문에는 어느 지점까지만 그렇다고 답함. 유한한 스텝으로 비선형 경로를 조각별 직선으로 근사하는 것이라 경로 이탈이 클수록 결과가 나빠진다고 함.
  87. 처음부터 더 곧은 경로를 만들도록 훈련하는 정류흐름(rectified flow, re-flow)이라는 연구도 있다고 소개함.
  88. 카메라 움직임 같은 제어 신호를 어떻게 넣는지 묻는 질문에는 자기는 그 부분 담당이 아니라 세부는 모른다고 선을 그으면서도, 트랜스포머라면 조건 정보를 여러 토큰으로 추가하거나 모든 토큰에 방송(broadcast)하는 등 여러 방식이 있다고 설명함.
  89. 매 스텝 노이즈를 다시 안 더하면 완전히 결정론적이 되냐는 마지막 질문에 그렇다고 확인함. 결정론적 샘플러는 데이터 분포와 노이즈 분포를 양방향으로 오갈 수 있고, 일관성 모델 같은 증류 기법에서 교사(teacher) 모델이 결정론적이어야 한다는 요건도 채운다고 답함.
  90. 발표를 마치며 유튜브에 같은 주제로 더 긴 버전 영상을 올려뒀다고 알림.

한줄 코멘트. 가이던스 하나가 디퓨전 모델을 작게 만들면서도 세게 만드는 비결이라는 게 이 발표의 핵심임.

  1. 발표자는 카르티시아 AI(Cartesia AI) 공동창업자 아르준 데사이(Arjun Desai)이고, 사회는 AWS 파운데이션 모델 훈련·추론 팀 소속 로힛 탈루리(Rohit Talluri)가 맡음.
  2. 카르티시아는 어느 기기에서든 도는 실시간 멀티모달 지능을 만드는 회사라고 소개하고, 이번 발표는 기업용 음성 AI를 어떻게 만드는지에 초점을 맞춘다고 밝힘.
  3. 파운데이션 모델을 떠올릴 때 보통 클라우드에 올라가 요청을 받으면 500~600밀리초 뒤에 답을 주는 배치(batch, 여러 요청을 모아 한 번에 처리하는 방식) 처리를 생각한다고 함.
  4. 텍스트는 사람이 초당 200토큰씩 읽지 않으니 이 정도 지연은 괜찮고, 나중에 처리량이 높으면 그만이라고 함.
  5. 하지만 영상·음성처럼 상호작용하는 애플리케이션에서는 속도가 무엇보다 중요하고 품질은 그냥 기본으로 갖춰야 하는 조건일 뿐이라고 함.
  6. 카르티시아는 파운데이션 모델을 클라우드 배치 작업용에서 실시간·멀티모달·모든 기기에서 도는 쪽으로 패러다임을 바꾸려 한다고 밝힘.
  7. 속도가 왜 중요한지 보여주려고, 옆 사람과 대화하는데 상대가 1초 늦게 답하면 얼마나 어색한지를 예로 듦.
  8. 음성에서는 답을 초 단위가 아니라 밀리초 단위로 줘야 하고, 고객센터에 전화해 문제를 해결하려는 사람은 응답이 늦으면 바로 짜증 낸다고 함.
  9. 음성을 다룰 때는 대화 중 끼어들기, 억양 같은 세계화 문제, 통화 중 배경 소음까지 처리해야 한다고 함.
  10. 음성 경험은 극히 주관적이라 취향과 맞춤 설정이 많이 필요하다고 함.
  11. 카르티시아가 모델링에서 원칙으로 삼는 것은 품질·지연시간·통제 가능성 세 가지라고 함.
  12. 첫째 품질은 음성의 자연스러움이 뛰어나야 한다는 것으로, 이 정도는 이미 기본 조건이라고 함.
  13. 둘째 지연시간은 상대편에서 첫 소리를 최대한 빨리 듣게 하는 것으로, 이렇게 벌어들인 시간을 에이전트가 더 많이 추론하는 데 쓸 수 있다고 함.
  14. 셋째는 통제 가능성으로, 자기 브랜드를 반영해 에이전트가 회사·제품을 원하는 방식대로 말하게 커스터마이즈하는 게 핵심이라고 함.
  15. 카르티시아는 트랜스포머의 대안인 상태공간모델(state space model, SSM)이라는 새 아키텍처를 개척했다고 밝힘.
  16. 트랜스포머는 입력이 길어질수록 메모리와 연산 시간이 제곱으로 늘어나는 이차 스케일링을 갖는다고 설명함.
  17. 반면 SSM은 추론 시점에 연산량이 O(1)(입력이 길어져도 늘지 않는 고정값)로 유지돼, 상태(state)를 유지한 채 생성하기 때문에 전통적 트랜스포머로는 못 낼 지연시간을 낸다고 함.
  18. SSM 계열은 원래 순환(recurrent) 방식이라 트랜스포머보다 성능이 떨어지는 편이었는데, 카르티시아는 그 격차를 메워 지연시간뿐 아니라 품질에서도 앞선다고 밝힘.
  19. 이제 질의응답으로 넘어가, 로힛이 음성 AI 고객들이 겪는 어려움과 이걸 만드는 이유를 물음.
  20. 아르준은 카르티시아의 주력 모델 소닉2(Sonic 2)가 음성 생성을 맡지만 그건 퍼즐의 한 조각일 뿐이고, 실제 음성 에이전트를 만들려면 언어모델과 음성 인식(speech-to-text, 소리를 문자로 바꾸는 기술) 모델까지 이어붙여야 한다고 함.
  21. 가장 큰 문제는 시간이 부족한 것으로, 언어모델은 저지연 워크플로우용으로 만들어지지 않아서 최대한 여유(slack)를 줘야 한다고 함.
  22. 두 번째로 꼽은 건 통제 가능성으로, 고객들이 카르티시아를 쓰는 이유가 음성 클로닝(voice cloning, 특정 화자의 목소리를 그대로 재현하는 기술)·억양·배경 소음까지 자연스럽게 담아내는 품질 때문이라고 함.
  23. 에이전트 목소리가 너무 완벽하면 오히려 불쾌한 골짜기처럼 느껴지고, 사람들은 통화 중 나는 작은 전화 잡음이나 삐 소리를 오히려 기대한다고 함.
  24. 로힛이 실제 고객 사례를 묻자, 아르준은 헬스케어·고객센터·실시간 게임 세 시장을 듦.
  25. 게임에서는 논플레이어 캐릭터(NPC, 사람이 조작하지 않는 게임 속 캐릭터)가 플레이어와 역동적으로 상호작용하도록 음성 AI가 쓰인다고 함.
  26. 이 시장들이 빠르게 크는 만큼 AWS 같은 파트너가 그 공간에 함께 투자해주는 게 큰 도움이 된다고 밝힘.
  27. 로힛이 인간 내레이터의 자리가 앞으로도 있을지 묻자, 아르준은 창작자가 음성 AI 플랫폼의 큰 축이라고 답함.
  28. 카르티시아는 창작자용 음성 마켓플레이스를 운영하는데, 목표는 성우를 대체하는 게 아니라 그들의 개성을 다른 사람이 라이선스로 쓸 수 있는 플랫폼을 주는 것이라고 밝힘.
  29. 이미 많은 성우가 이 플랫폼에 합류했고, 내레이션 관련 활용 사례도 상당히 많다고 함.
  30. 청중 하나가, 카르티시아를 막 쓰기 시작했는데 AWS 파트너십 상에서 클로드(Claude)를 붙이면 지연시간 때문에 잘 안 되는 것 같다며 이게 정상인지, 어떤 모델과 짝지어 쓰길 권하는지를 물음.
  31. 아르준은 카르티시아가 파이프캣(Pipecat)과 통합돼 있고 둘 다 AWS와 협력하지만, 클라우드 쪽 대형 언어모델은 엔드투엔드로 보면 여전히 지연시간이 크다고 답함.
  32. 그래서 TTS(text-to-speech, 문자를 음성으로 바꾸는 기술) 쪽에서 여유를 주는 게 언어모델 쪽 지연을 상쇄하는 방편이라고 함.
  33. 클로드 같은 모델은 전용 인스턴스(dedicated instance)를 쓰면 더 나은 지연시간을 낼 수 있는 등 제공사마다 메커니즘이 다르다고 함.
  34. 다만 이런 최적화는 결국 언어모델 제공사 쪽 몫이 크고, 카르티시아 목표는 실시간 AI를 어디서나 쓸 수 있게 만드는 것이라고 함.
  35. 로힛이 덧붙여, 카르티시아가 이 용도로 커스텀 모델 아키텍처를 개발했다는 점과 SSM의 선형 스케일링 대 트랜스포머의 이차 스케일링 차이를 다시 짚음.
  36. AWS는 세이지메이커 점프스타트(SageMaker Jumpstart)와 아마존 베드록(Amazon Bedrock) 같은 모델 가든에서 고객에게 다양한 선택지를 주는 게 설계 철학이라고 함.
  37. AWS는 카르티시아처럼 특정 용도에 강한 파운데이션 모델 제공사를 계속 찾아 생태계에 들여, 기존 모델이 못 채우던 산업을 풀어주려 한다고 밝힘.
  38. 카르티시아 덕에 엣지 기기에서 도는 실시간 음성 AI가 열리고 있고, 이게 여러 고객을 새로 풀어주고 있다고 정리함.
  39. 다른 청중이, 영상 쪽 연구에서는 데이터 양보다 프레임당 정보 밀도가 중요하다는 이론이 있는데 음성에도 비슷한 게 있는지, 다음 단계 모델을 만들려면 데이터 규모가 더 필요한지 밀도가 더 필요한지를 물음.
  40. 아르준은 답이 그렇기도 하고 아니기도 하다며, 생성 AI 전반의 통상적 방식은 대규모 사전학습 데이터 뒤에 정렬(alignment)·선호(preference) 데이터로 파인튜닝하는 것이라고 함.
  41. 이 방식은 영상에서도 똑같이 적용되는데, 자신이 스탠퍼드에서 생성형 AI 박사 과정 중 이미지·영상 모델을 다뤘던 경험을 근거로 듦.
  42. 음성이 흥미로운 지점은 사람들이 원하는 선호 데이터가 워낙 다양해서 한 단계짜리 파인튜닝만으로는 담아낼 수 없다는 점이라고 함.
  43. 그래서 품질 높고 풍부한 데이터는 물론, 다양한 사람이 원하는 정보까지 함께 짝지어 담아야 한다고 정리함.
  44. 다음 청중이, 아마존도 스피치투스피치(speech-to-speech, 음성을 문자 단계 없이 바로 음성으로 처리하는 방식) 모델을 냈는데 아직 미성숙해 보인다며 이게 미래인지 물음.
  45. 아르준은 스피치투스피치가 지금 쓸모 있는 곳도 있지만 프로덕션이나 기업용으로 쓸 수준까지는 아직 아니라고 답함.
  46. 아마존이 최근 스피치투스피치 모델을 냈고 다른 곳들도 몇몇 있다고 언급하면서도, 지금은 조율된(orchestrated) 여러 모델 조합 방식이 시스템 구성 요소를 더 잘 통제하게 해준다고 함.
  47. 지연시간만 보면 스피치투스피치 모델이 결국 우세해지겠지만, 그 통제 가능성을 처음부터 설계에 반영해야 한다고 함.
  48. 목표는 신기해 보이는 걸 만드는 게 아니라 실제 현장에서 돌아가는 걸 만드는 것이고, 아직 거기까지는 아니지만 시간이 지나면 도달할 거라고 함.
  49. 로컬 모델에 관한 질문에, 아르준은 카르티시아가 어느 기기든 돌아가게 만든다며 엣지 기기에서 로컬로 도는 모델도 있다고 답함.
  50. 클라우드 모델은 특정 크기·능력이 필요할 때 계속 있을 자리이지만, 노트북보다 더 작은 스마트폰 같은 아주 작은 기기엔 못 들어간다고 함.
  51. 관건은 네트워크 왕복을 포함한 클라우드 속도가 엣지보다 느려지는 지점이 어디인지이고, 카르티시아는 그 경계를 이미 넘어섰다고 함.
  52. 자사 모델을 엣지에서 돌리면 클라우드를 왕복할 때보다 약 5배 빠르다고 밝힘.
  53. 마지막 질문으로, 뭔가 고장 났을 때 이게 카르티시아·AWS 쪽 문제인지 판별하려면 에이전트를 어떻게 모니터링해야 하는지를 물음.
  54. 아르준은 평가(eval)가 어떤 시스템에서든 굉장히 중요한 부분이라며, 우선 메시지로 물어봐 달라고 답함.
  55. 실제로 문제는 대부분 언어모델 단계에서 나오는데, 음성 인식 결과를 언어모델이 쓸 수 있게, 또 언어모델 출력을 TTS가 다루기 편하게 각각 포맷을 맞춰줘야 하는 경계 지점이라고 함.
  56. 카르티시아가 이런 경계 사례 다수를 이미 처리해뒀다고 밝힘.
  57. 소닉2(Sonic 2)는 초기 모델보다 2.5배 빨라져 모델 지연시간 40밀리초를 낼 뿐 아니라, 능력과 품질도 상당히 개선됐다고 함.
  58. 2030년, 5년 뒤 음성 AI와 카르티시아가 어디에 있을지 묻는 마지막 질문에, 음성 AI가 모든 산업에서 당연한 표준이 될 거라고 답함.
  59. 문제 분류든 상담이든 게임이든 대부분의 상호작용이 음성 AI로 상당 부분 채워질 거라고 함.
  60. 다만 진짜 상호작용형 모델은 듣는 것 이상, 즉 세상을 어떻게 경험하는지의 문제라며 이걸 흔히 세계 모델(world model)이라 부른다고 함.
  61. 이런 시스템이 실시간으로 작동하게 만드는 게 정말 흥미로운 과제이고, 사람과 함께 일하는 비서나 코파일럿처럼 세상을 새로운 방식으로 이해하게 돕는 시스템을 기대한다고 밝힘.

한줄 코멘트. 소닉2의 40밀리초·2.5배라는 숫자보다, 클로드도 느리다는 청중 질문에 TTS 쪽 여유로 언어모델 지연을 상쇄한다고 답한 대목이 이 아키텍처가 실전에서 버티는 이유를 더 잘 보여줌.

08

제품 · 조직 · 도입

  1. 브레인트러스트(BrainTrust) 솔루션 엔지니어링 팀장 필 헷젤이 에이전트형(agentic) 개발이 정말 데이터 과학자나 머신러닝 엔지니어의 일인지를 묻는 걸로 발표를 시작함.
  2. 청중에게 스스로를 데이터 과학자나 머신러닝 엔지니어라고 생각하는지 손을 들어보라고 물으며, 자기 답이 그 사람들 마음에 딱 들지는 않을 거라고 미리 밝힘.
  3. 컨설팅과 시스템 구축에서 12년을 보냈고, 마지막 직책은 슬랙롬 컨설팅(Slalom Consulting)에서 데이터브릭스(Databricks) 글로벌 사업부를 이끄는 자리였다고 함.
  4. 그때 고객사들이 생성AI 개념 증명(PoC)은 잘 만들면서 그걸 실제 서비스로 옮기는 데는 서툰 걸 봤다고 함.
  5. 그래서 브레인트러스트를 사용자로 먼저 써보다가 제품이 마음에 들어 입사까지 하게 됐고, 그 뒤로 1년쯤 됐다고 함.
  6. 브레인트러스트는 평가(eval)와 관측 가능성(observability) 두 축으로 에이전트 품질을 다루는 플랫폼이라고 소개함.
  7. 평가는 에이전트를 만들고 다듬는 실험 단계에서 확신을 쌓는 일이고, 관측 가능성은 프로덕션에 올린 뒤 실제 사용자를 만났을 때도 그 확신을 유지하는 일이라고 구분함.
  8. 제품 얘기는 여기까지만 하고, 지난 1년간 여러 업종의 상위 팀들이 에이전트를 만드는 걸 지켜보며 얻은 관찰로 넘어감.
  9. 함께 일하는 조직을 전통 기업과 AI 네이티브 두 부류로 나눔.
  10. 전통 기업에서는 CEO나 CIO가 업계 매거진에서 에이전트를 만들어야 한다는 글을 읽고 그걸 부하 직원에게 지시로 내린다고 함.
  11. 그 지시가 이미 도구를 갖춘 기존 머신러닝·데이터 과학 플랫폼 팀에 넘어가는데, 생성AI라는 이름에 AI가 들어 있다는 이유만으로 그 팀에 자연스럽게 맡겨진다고 함.
  12. 청중 중에도 원래 머신러닝 플랫폼 엔지니어였다가 생성AI를 떠맡게 된 사람이 있는지 물었더니 여럿이 손을 들었다고 함.
  13. AI 네이티브 기업은 다르게 움직이는데, 생성AI가 뜨기 전엔 기존 체계랄 게 없었기 때문에 처음부터 사업 전체를 에이전트 중심으로 쌓았다고 함.
  14. 그래서 AI·머신러닝 전담 팀 대신 시대 변화에 맞춰 유연하게 움직이는 소규모 엔지니어 팀을 두고, 제품 엔지니어링과 AI 엔지니어링을 가르지 않는다고 함.
  15. AI 네이티브는 회사 규모가 작은 만큼 구성원 각자가 문제에 더 가까이 있어서, 에이전트가 실제로 뭘 풀어야 하는지를 더 잘 안다고 함.
  16. 전통 머신러닝과 생성AI의 첫 번째 차이는 모델이 이미 만들어져 있다는 점이라고 함.
  17. 데이터 과학자와 머신러닝 엔지니어의 일 대부분은 모델을 학습시키는 데이터 파이프라인을 거치는 것인데, 모델이 이미 있으면 그 일을 할 필요가 없다고 함.
  18. 두 번째 차이는 모델에 가치를 더하는 방법이 피처 엔지니어링이 아니라 자연어일 수 있다는 점이고, 이게 대화에 다른 기술 집합을 끌어들일 수 있다고 함.
  19. 전통적인 데이터 과학자·머신러닝 엔지니어의 일을 단순화하면 학습·테스트·과적합 방지를 거쳐 모델을 배포하는 데이터 파이프라인이라고 정리함.
  20. 이 과정은 앤스로픽(Anthropic)·오픈AI(OpenAI)·미스트랄(Mistral)이 데이터를 모으고 파이프라인에 태워 LLM을 학습시키고 엔드포인트로 내보내는 데서 이미 끝났다고 함.
  21. 유일한 차이는 이들 회사가 자체 테스트를 하더라도, API를 제품에 붙인 우리 팀은 여전히 평가를 직접 해야 한다는 점이라고 함.
  22. 예측 모델형 애플리케이션을 바꾸는 방식도 다른데, 전통 머신러닝은 데이터를 더 넣어 재학습하거나 피처 엔지니어링을 하고 A/B 테스트로 개선 여부를 확인한다고 함.
  23. 생성AI는 파인튜닝이 드물어서, 모델 자체는 그대로 두고 입력값·프롬프트·컨텍스트를 바꿔서 동작을 바꾼다고 함.
  24. 그래서 이런 컨텍스트 엔지니어링(모델에 넘길 배경 정보를 다듬는 작업)을 하는 사람들이 실제 사용자가 에이전트를 어떻게 쓰는지 더 가까이서 이해하고 있을 수 있다고 함.
  25. 여기서부터 에이전트가 데이터 과학자 것이라는 쪽과 아니라는 쪽 양쪽 논리를 차례로 펼침.
  26. 찬성 논리 첫째, 에이전트는 모델을 쓰고 모델은 조직 안에서 데이터 과학자가 관리하니 신경망과 LLM이 어떻게 작동하는지 밑바닥 지식을 갖고 있다고 함.
  27. 그래서 이 복잡한 기술에 딸린 위험을 훨씬 잘 알아본다고 함.
  28. 둘째, 모델과 모델 자산을 프로덕션에 올리는 엄격한 절차를 이미 갖고 있어서 최종 사용자에게 필요한 경험을 보장하는 테스트 과정을 안다고 함.
  29. 셋째, 테스트에 관해 원래 엄격한 사고방식을 갖고 있다고 함.
  30. 반대 논리는 다시 모델이 이미 만들어져 있다는 점으로 돌아가는데, 학습·테스트를 새로 할 필요가 없고 교차검증(cross-validation) 과정을 밟을 일도 없다고 함.
  31. 이게 가장 큰 반론인데, 머신러닝 엔지니어나 데이터 과학자가 정작 에이전트에서 무엇을 테스트해야 하는지 아느냐는 물음이라고 함.
  32. 이런 팀들이 전통적인 머신러닝 지표인 정밀도(precision)·재현율(recall)·F1에 집착하는 걸 자주 봤는데, 그게 지금까지 그들을 여기까지 데려온 지표이기 때문이라고 함.
  33. 하지만 에이전트를 분석할 때는 평가해야 할 범위가 훨씬 넓어서, 딱 떨어지는 기술적 성능이 아니라 에이전트의 기능적 성능을 봐야 한다고 함.
  34. 반대 논리를 이어서, LLM은 그냥 API일 뿐이고 제품 엔지니어는 다른 시스템에서 정보를 가져와 사용자에게 쓸모 있게 돌려주는 API 작업에 이미 익숙하다고 함.
  35. 복잡한 에이전트는 여러 종류의 컴퓨팅에 걸쳐 돌 수 있는데, 상위 감독 에이전트가 서로 다른 인프라에서 도는 하위 에이전트들을 호출하는 식이라고 함.
  36. 하위 에이전트들이 또 다른 인프라에서 또 다른 시스템을 부르기도 하는데, 이런 분산 시스템 문제는 통계·수학 배경을 가진 사람의 전문 영역과 꼭 맞진 않는다고 함.
  37. 비기술 쪽 논리로는, 도메인 전문가나 프로덕트 매니저가 에이전트에 심는 프롬프트를 직접 통제할 수 있게 하는 게 큰 값어치가 있다고 함.
  38. 이 사람들이 에이전트가 풀어야 할 문제에 가장 가까이 있는 이들이라 비기술 인력에게 발언권을 많이 주는 게 이득이라고 함.
  39. 좋은 에이전트를 만드는 데는 대규모 사람 라벨링(human annotation) 작업도 들어간다고 함.
  40. 도메인 지식은 있지만 비기술 인력인 사람이 에이전트 실행 기록(trace)을 보고 잘하고 있는지, 왜 그런지를 판단할 수 있다고 함.
  41. 결론은 손을 들었던 데이터 과학자·머신러닝 엔지니어들에게 기술을 완전히 갈아엎으라는 얘기가 아니라고 함.
  42. 그런 말을 하기엔 이 방에 데이터 과학자가 많을 걸 알 만큼 자기가 눈치가 있다고 농담함.
  43. 다만 이런 플랫폼을 만들 때는 팀을 다양하게 꾸리는 게 맞고, 비기술 인력과 여러 기술 인력을 함께 끌어들이는 게 이치에 맞는다고 함.
  44. 데이터 과학자가 에이전트 구축에 값을 더하는 방법을 몇 가지 짚는데, 전부 제품 자체를 직접 만드는 일과는 별개라고 함.
  45. 지금 나온 도구들 덕분에 제품 엔지니어링 배경이 없어도 제품에 값을 더하기가 꽤 쉬워졌다고 함.
  46. 첫째로 값진 건 이 과정에 가드레일(guardrail, 안전장치)을 더하는 일인데, 많은 사람이 LLM이 어떻게 작동하는지도 모른 채 공격적으로 도입한다고 함.
  47. 통계 배경이 없는 사람들 사이에서 데이터 과학자가 "이 LLM은 토큰을 하나씩 예측할 뿐 사실 아무것도 알지 못한다"고 짚어주는 어른 역할을 할 수 있다고 함.
  48. 둘째, LLM 심사(LLM as judge, 모델이 다른 모델의 출력을 채점하게 하는 방식)가 평가 과정의 큰 부분인데, 사람들이 그 결과를 곧이곧대로 믿고 싶어한다고 함.
  49. LLM 심사도 결국 프롬프트와 모델일 뿐이라, 레이블이 붙은 데이터셋을 만들어 정밀도·재현율·F1 같은 전통 지표로 검증해야 하는데 그게 데이터 과학자의 전문 영역이라고 함.
  50. 셋째, 가장 기술적인 항목으로 오픈소스 모델을 특정 사용 사례에 맞게 파인튜닝하는 일이 제일 재미있게 값을 더할 대목이라고 함.
  51. 이상적인 조합에서는 제품·애플리케이션·시스템 엔지니어가 비기술 전문가가 내놓은 요구사항을 실제 제품에 구현한다고 함.
  52. 에이전트가 실행되는 시스템을 잘 짜서 사용자 경험이 좋게 나오도록 만드는 것도 이들 몫이라고 함.
  53. 데이터 과학자가 여기서도 거들 수 있는 일로, 프로덕션과 실험 양쪽에서 무슨 일이 벌어지는지 이어주는 평가·관측 가능성 파이프라인을 실제로 만드는 걸 꼽음.
  54. 비기술 전문가에게는 사람 라벨링과 프롬프트·컨텍스트 엔지니어링을 많이 맡겨야 하는데, 이들이 문제에 가장 가깝기 때문이라고 함.
  55. 답은 늘 중간에 있다며, 방에 있는 절반을 모욕하지 않았길 바란다고 마무리함.
  56. 데이터 과학자에게 여전히 큰 값어치가 있으니, 다만 에이전트를 만들 때 더 많은 사람을 방으로 데려오라는 게 결론이라고 함.
  57. 질의응답에서 한 청중이 에이전트를 도구로 보고 조직 내 누구든 이론상 그 도구를 만들고 소유할 수 있다는 관점을 던짐.
  58. 그 청중은 도구를 누가 소유하느냐보다 어떤 문제를 푸느냐로 생각해야 하지 않냐고 물음.
  59. 헷젤은 같은 생각이라며, 에이전트는 다양한 팀이 함께 만드는 제품이라고 답함.
  60. 이걸 또 다른 예측 모델이라 부르며 머신러닝 엔지니어나 데이터 과학자에게만 떠넘기는 게 전통 기업들의 흔한 실수라고 덧붙임.
  61. 다른 청중이 루프를 닫는(closing the loop) 툴링, 즉 도메인 전문가가 시스템을 직접 갱신하게 하는 도구가 브레인트러스트에 있는지 물음.
  62. 헷젤은 사람이 직접 라벨을 붙이는 기능과, 사람들이 자기 프롬프트로 실험하고 그걸 바로 에이전트에 보내볼 수 있는 프롬프트 플레이그라운드가 있다고 답함.
  63. 이어 평가자(evaluator) 자체를 어떻게 최신 상태로 유지하고, 오류가 평가자 쪽 문제인지 어떻게 가려내는지 묻는 질문이 나옴.
  64. 헷젤은 프로덕션에서 나온 데이터를 계속 모아 오프라인 평가 데이터셋에 더한다고 답함.
  65. 그렇게 쌓인 근거 데이터로 자체 평가가 사람의 판단과 갈수록 맞아가는지 벌어지는지를 스스로 점검한다고 함.

한줄 코멘트. 결론은 "답은 중간에 있다"는 무난한 말이지만, 정밀도·재현율·F1에 집착하는 습관이 에이전트 평가에는 안 맞는다는 반론이 이 발표에서 제일 날카로운 대목임.

  1. 케이트 캠프는 구글 딥마인드에서 바이브 코딩(말로 설명만 하면 모델이 코드를 짜고 앱을 완성하는 방식)과 AI 스튜디오를 맡고, 아마르 레시는 AI 스튜디오의 제품·디자인 팀을 이끈다고 함.
  2. 딥마인드는 이번 주나 올해만이 아니라 트랜스포머, 알파고 같은 성과를 여러 해에 걸쳐 내놓은 팀이라는 점을 먼저 짚음.
  3. 구글은 이번 주 제미나이 3 프로를 새로 내놓았고, 이게 지금 가장 똑똑한 최신 모델이라고 소개함.
  4. 제미나이 3의 핵심은 두 가지인데, 하나는 UI·디자인 감각이고 다른 하나는 에이전트(사람이 시킨 일을 스스로 여러 단계로 쪼개 도구를 불러가며 처리하는 프로그램)형 도구 호출 능력임.
  5. 첫 번째 능력은 한 번의 프롬프트로 웹사이트나 UI를 만드는 힘이 세다는 것이고, 두 번째는 방대한 코드베이스 안에서 복잡한 작업을 도구 호출로 처리하는 힘임.
  6. 여러 모델에 같은 에이전트 하네스(모델이 도구를 순서대로 부르도록 감싼 실행틀)를 씌운 SWE 벤치마크 실험에서 제미나이 3가 에이전트형 과제 성능으로 다른 모델을 크게 앞섰다고 함.
  7. 이전 세대 제미나이 모델과 비교해도 전 영역에서 최고 성능을 냈다고 밝힘.
  8. 제미나이 3 프로는 화요일에 내놨는데 그 주에 사흘이 더 남아서 다른 모델도 하나 더 냈다고 웃으며 말함.
  9. 그렇게 나온 게 나노 바나나 프로로, 이미 최고 수준이던 기존 이미지 모델에서 한 번 더 도약했다고 소개함.
  10. 나노 바나나 프로가 가장 특별한 점은 구글 검색으로 뒷받침되는 세계 지식이라고 함.
  11. 예를 들어 "이 차는 어떻게 우려요" 같은 질문을 던지면 실제로 구글 검색을 돌려 정확한 정보로 상세한 인포그래픽과 도해를 만들어준다고 함.
  12. 텍스트 렌더링도 눈에 띄게 좋아져서, 캔 표면을 감싸는 글자까지 어긋남 없이 정확하게 그려낸다고 보여줌.
  13. 여러 언어를 지원해서 한국어를 포함한 다국어로 이미지 속 문구를 번역하고, 같은 참조 이미지 위에 그대로 다시 그려 넣을 수 있다고 함.
  14. 인물 일관성도 좋아져서 한 이미지 안에 최대 14명까지 넣어 단체 사진을 만들 수 있고, 이 14명이 지금까지 확인한 기준치라고 밝힘.
  15. 창작 제어도 세밀해져서 "초점을 꽃으로 바꿔줘"라는 짧은 프롬프트만으로 인물에서 꽃으로 초점을 옮기면서 나머지 장면은 그대로 유지한다고 보여줌.
  16. 벽지나 대형 배너, 광고판까지 겨냥해 다양한 비율로 이미지를 뽑을 수 있다고 덧붙임.
  17. 이제부터는 이 두 모델로 실제로 무엇을 만들었는지 라이브 데모로 보여주겠다며 발표 방식을 바꿈.
  18. AI 스튜디오는 API 키를 받고 제미나이 3, 나노 바나나 프로 같은 최신 모델과 바로 대화해볼 수 있는 구글의 시작점이라고 소개함.
  19. 오늘 다룰 핵심은 AI 스튜디오 안의 빌드 기능, 즉 바이브 코딩 경험이고 예시 앱 갤러리도 함께 제공한다고 함.
  20. 이 빌드 기능은 무료로 쓸 수 있고, 제미나이 API를 자기 애플리케이션에 붙이기가 쉬운 게 AI 스튜디오의 특징이라고 밝힘.
  21. 화면 아래쪽에는 AI 칩(모델 선택과 별도로 구글 검색 연동, 구글 지도 연동 같은 기능을 켜고 끄는 버튼 묶음)이 있어 API가 가진 기능을 한눈에 보여준다고 함.
  22. 라이브 API(웹캠이나 마이크 입력을 실시간으로 모델에 보내 대화하듯 피드백을 받는 기능)로는 테니스 스윙을 웹캠으로 찍어 실시간 교정을 받는 예시도 만들었다고 함.
  23. 같은 라이브 API로 자세가 앞으로 쏠리면 바로 소리쳐 알려주는 자세 교정 앱도 만들었다고 함.
  24. AI 스튜디오에서 만든 앱은 API 키 없이도 만들 수 있고, 공유해도 방문자가 AI 스튜디오의 무료 사용량을 쓰므로 갑자기 인기를 끌어도 청구서 폭탄 걱정이 없다고 설명함.
  25. 첫 데모로 케이트가 구글 검색 연동과 나노 바나나 프로를 함께 써서 노트북 스티커 일러스트를 만드는 프롬프트를 실행함.
  26. 이런 노트북 스티커 만들기는 나노 바나나 프로가 나온 뒤 퍼진 유행 중 하나라고 소개함.
  27. 로딩 화면조차 제미나이가 지금 만드는 앱을 실시간으로 생각하며 채워 넣는 방식으로, 기존 바이브 코딩의 틀을 깨보려는 시도라고 함.
  28. 아마르는 텍스트 렌더링 데모로 넘어가면서, 나노 바나나 프로의 텍스트 일관성을 보고 만화책을 떠올렸다고 함.
  29. 얼굴 사진 한 장을 올리면 장르와 언어를 고른 뒤 자신을 주인공으로 넣은 만화책 이야기를 만들어주는 앱을 직접 바이브 코딩으로 만들었다고 함.
  30. 데모에서는 케이트와 아마르가 뉴욕 AI 엔지니어 컨퍼런스에서 발표를 준비하며 애드리브로 버티는 이야기를 골라 만화책을 생성함.
  31. 아마르는 AI가 만든 웹사이트가 흔히 보라색 그러데이션으로 도배되는 걸 디자이너 입장에서 싫어했다고 밝힘.
  32. 이번 모델은 셰이더 애니메이션과 페이지 전환 효과, 심지어 타이포그래피까지 스스로 골라 훨씬 세련된 웹사이트를 만든다고 보여줌.
  33. 이때 준 프롬프트는 "매끄러운 애니메이션 웹사이트를 만들어줘, 사이버펑크는 빼고" 정도로 짧았다고 함.
  34. 이렇게 디자인에 서툴러 피그마와 씨름하던 사람도 이제는 프롬프트만으로 그럴듯한 결과를 만들 수 있게 됐다고 평가함.
  35. 만화책 데모로 돌아와, 생성된 이야기가 실제로 웃길 정도로 창의적이었고 이런 반응은 이 모델이 처음이었다고 아마르가 밝힘.
  36. 배경에 걸린 "AI 엔지니어" 컨퍼런스 배너 같은 세부 디테일까지 정확히 그려 넣었다고 보여줌.
  37. 케이트가 넣은 기능으로, 이야기 중간에 방향을 직접 고를 수 있어서 이번엔 "조용히 API 키를 확인하기" 대신 "즉흥으로 밀어붙이기"를 선택했다고 함.
  38. 그 결과 아마르가 수상하리만치 멀쩡히 작동하는 로봇 강아지를 안고 있는 장면이 그려졌다며 웃음.
  39. 이렇게 모델의 창의성과 나노 바나나의 이미지 능력이 합쳐져 역동적인 경험을 만들 수 있다고 정리함.
  40. 케이트는 스티커 데모로 돌아와 API 키를 등록한 뒤, 원하는 단어를 직접 입력하거나 구글 검색으로 소재를 가져올 수 있다고 보여줌.
  41. 이번엔 아마르 이름으로 구글 검색을 걸었고, 해상도도 1K로 선택할 수 있다고 보여줌.
  42. 구글 검색으로 아마르에 관한 최신 정보를 모아 그가 실제로 좋아할 법한 스티커 세트를 만들어냈다고 함.
  43. 결과물에는 아마르가 쓴 동화책 "앨리스 앤 스파클"이 유독 많이 등장했는데, 그가 이 책 이야기를 자주 해서라고 설명함.
  44. 이런 식으로 모델이 학습 시점의 지식이 아니라 그날그날의 뉴스 같은 최신 정보를 검색으로 끌어와 반영할 수 있다고 덧붙임.
  45. 케이트는 AI 스튜디오 자체를 AI 스튜디오로 만든다며, 아이디어는 많은데 엔지니어가 부족해 내부 탐색용으로도 이 도구를 쓴다고 밝힘.
  46. 마침 구글이 이번 주 새로 내놓은 에이전트형 통합개발환경(IDE)인 안티그래비티로 작업을 옮기는 흐름을 시연함.
  47. AI 스튜디오 화면 스크린샷 한 장을 주고 "이 UI를 최대한 그대로 복제하고 안티그래비티로 내보내는 흐름을 추가해줘"라는 프롬프트 하나만 실행함.
  48. 결과로 라이트 모드 UI를 거의 그대로 복제했고, 아마르의 기존 디자인 일부를 오히려 개선하기도 했다고 평가함.
  49. 여기에 새로 생긴 "안티그래비티로 내보내기" 버튼을 누르면 실제로 파일을 만들어 IDE에서 곧바로 열 수 있다고 보여줌.
  50. 이런 창의적인 확장은 처음부터 IDE에서 직접 손댔다면 기존 패턴에 갇혔을 텐데, 모델에게 "창의적으로, 틀을 벗어나서"라고만 지시했더니 나온 결과라고 설명함.
  51. 이 프롬프트를 여러 번 돌려보면 어떨 땐 명령줄 인터페이스로, 어떨 땐 내보내기 상태를 보여주는 화면으로 다르게 나온다고 덧붙임.
  52. 아마르는 다음 데모로 넘어가 "시작 화면에 봇이 있는 레이싱 게임을 만들어줘"라는 프롬프트만으로 3JS(자바스크립트로 3D 그래픽을 그리는 라이브러리) 기반 3D 레이싱 게임을 만들었다고 보여줌.
  53. 아마르는 자기만 이길 수 있게 부스트 기능을 몰래 넣어뒀다고 인정함.
  54. 지금까지 만든 앱은 모두 프런트엔드 리액트 앱이었는데, 곧 AI 스튜디오에 백엔드 지원과 풀스택 런타임이 추가된다고 예고함.
  55. 풀스택 런타임이 들어오면 샤드씨엔(자주 쓰는 UI 컴포넌트 모음) 설치나 익스프레스(백엔드 서버를 짜는 자바스크립트 프레임워크) 연결 같은 작업도 한 프롬프트로 처리할 수 있게 된다고 함.
  56. AI 스튜디오의 원칙은 사용자가 이런 세부사항을 신경 쓰지 않게 하는 것이라, "멀티플레이어 앱을 만들고 싶다"고만 말하면 익스프레스 연결까지 알아서 처리한다고 설명함.
  57. 이걸 보여주려고 방금 만든 레이싱 게임을 멀티플레이어로 바꾸는 걸 몇 번의 프롬프트만으로 시연함.
  58. 현장에서 QR코드를 띄워 청중이 직접 접속하게 했고, 이렇게 많은 인원으로 시도한 적은 없다며 결과를 장담하지 못한다고 밝힘.
  59. 접속자가 순식간에 19명, 20명, 23명까지 늘어나 로비가 혼잡해졌다고 함.
  60. 자동차끼리 충돌 판정을 넣어둔 탓에 차들이 서로 튕겨 나가며 뒤엉켰고, 다들 "준비 완료"를 눌러야 시작되는 규칙 때문에 결국 경주는 시작하지 못했다고 함.
  61. 그래도 23명이 동시에 접속한 상황에서 런타임 자체는 터지지 않고 버텼다는 점을 성과로 짚음.
  62. 아마르는 이 프로젝트가 특별한 이유로, 소프트웨어를 아무나 만들 수 있는 세상을 위한 도구를 만드는 첫 세대 엔지니어가 됐다는 점을 꼽음.
  63. 그날 아침에도 유튜브 영상 하나를 보고 바이브 코딩과 AI 스튜디오를 시작했다는 기술지원 담당자를 만났다고 예로 듦.
  64. 기본 IDE에서 시작하지 않는 사용자가 늘어나는 만큼, 사용자 의도를 최대한 미리 읽어내는 쪽으로 방향을 바꿔야 한다고 짚음.
  65. 앞으로 풀스택 런타임에서는 앱에 저장 기능이 필요하면 자동으로 데이터베이스를 붙이고, 전자상거래 앱이면 결제 기능을 자동으로 붙이는 식으로 세부사항을 알아서 채우는 게 목표라고 밝힘.

한줄 코멘트. 데모는 화려한데 정작 핵심인 백엔드·풀스택 런타임은 아직 나오지 않은 예고편이라, 지금 본 건 프런트엔드 한정판 바이브 코딩임.

이전