AI에게 업무 지침을 더 많이 줬더니 평균 성적은 올랐습니다. 그런데 같은 일을 네 번 모두 성공하는 비율은 오히려 낮아졌습니다. IBM Research가 공개한 항공 고객상담 실험의 한 장면입니다. 무엇을 기억하게 할지에 따라, 더 자주 맞히는 AI와 더 꾸준히 맞히는 AI가 갈렸습니다. IBM Research 실험
이번 10호에서는 경험을 지침으로 바꾸는 연구부터 새 공개 모델, 패키지 설치를 막는 방화벽, 캐시·음성·실시간 통신의 변화까지 살펴봅니다. 10월 16~21일 공개 자료 중 기존 호에서 다루지 않은 소식과 새로 달라진 내용을 골랐습니다.
아래 소식은 모두 03 · 공식 확인입니다. 발표 주체의 자료와 문서를 확인했다는 뜻이며, 성능 수치나 제품 동작을 직접 재현한 것은 아닙니다. 마지막의 ‘L-Proof의 해석’은 이 자료를 바탕으로 한 별도의 판단입니다.
IBM Research — 지난 실수를 다음 상담의 지침으로
10월 20일 공개된 ALTK-Evolve의 고객상담 실험은 모델을 다시 훈련하는 대신, 이전 시도의 성공과 실패에서 짧은 지침을 뽑아 다음 대화에 넣었습니다. 고객 확인, 거래 전 동의, 반품 처리 같은 행동을 정리해 시스템 프롬프트에 붙이는 방식입니다. 프로젝트는 이런 기록을 저장하고 작업에 맞는 지침을 불러오는 도구를 공개하고 있습니다. 프로젝트와 동작 구조
GPT-4.1을 쓰는 에이전트를 τ²-bench의 별도 시험 과제로 평가했을 때, 소매 상담 40개에서 네 번 모두 성공한 과제의 비율인 Pass⁴가 57.5%에서 67.5%로 올랐습니다. 학습용 과제에서 지침을 만들고, 시험 때는 그대로 적용한 결과입니다.
항공 상담 20개에서는 다른 모습이 나왔습니다. 지침 101개를 넣으면 평균 성공률은 65%로, 14개만 넣었을 때의 60%보다 높았습니다. 하지만 Pass⁴는 각각 40%와 45%였습니다. 지침이 많은 쪽이 평균으로는 더 잘하면서도, 네 번을 빠짐없이 성공하는 과제는 적었습니다. 왜 이런 차이가 났는지까지 이 수치만으로 확정할 수는 없습니다. 평가 구성과 결과 표
비용도 늘었습니다. 학습용과 시험용 과제를 합쳐 계산한 소매 상담 한 건의 비용은, 지침을 모두 넣었을 때 약 65% 늘었습니다. 에이전트뿐 아니라 고객 역할의 시뮬레이터 비용도 포함한 값입니다. 실제 고객 운영 결과나 다른 업무의 개선율로 옮겨 읽기에는 시험 범위가 작습니다.
Reflection Beam — 모델과 함께 실행·수정 방법도 공개한다
Reflection의 Beam은 10월 16일 공개된 코딩·에이전트용 모델입니다. 총 5,010억 파라미터 중 토큰마다 약 230억을 사용하는 MoE 구조이며, 텍스트 입출력과 100만 토큰 문맥을 지원합니다. Apache 2.0 라이선스로 가중치를 공개했고, 주로 영어를 대상으로 개발됐습니다. 공식 모델 카드
모델과 함께 공개된 도구들도 눈여겨볼 만합니다. Transformers·vLLM·SGLang 실행 지원과 함께 지도 미세조정, 강화학습 예제, 전용 Rust 기반 에이전트 실행 도구도 나왔습니다. 직접 운영하거나 특정 업무에 맞게 바꾸려는 팀이 시작할 재료를 함께 내놓았습니다. Hugging Face의 공개·통합 안내
다만 ‘활성 230억’은 노트북에서 돌릴 수 있다는 뜻이 아닙니다. Hugging Face 안내에 따르면 BF16 가중치는 약 1TB이고, Blackwell GPU용 NVFP4 형식도 약 280GB입니다. 문맥과 동시 요청을 처리할 메모리까지 고려해, Hugging Face는 B200 네 장 구성을 권합니다. 이는 모든 환경의 최소 사양을 확정한 숫자가 아닙니다.
8호에서 다룬 Liquid AI가 기기 안에서 반복 작업을 맡길 선택지였다면, Beam은 자체 인프라에서 큰 모델을 운영하고 수정하려는 팀에 더 가까운 소식입니다. 공개됐다는 사실과 가볍게 운영할 수 있다는 사실은 따로 봐야 합니다.
GitHub — 코드를 검토하기 전에, 설치부터 막는다
코딩 에이전트가 라이브러리를 설치하고 테스트를 시작한다고 해봅시다. 사람이 완성된 변경 사항을 읽기 전에도 설치 스크립트는 이미 실행될 수 있습니다. 지난 호의 보안 검사와 수정 PR보다 앞선 단계의 문제입니다.
GitHub는 10월 20일 package firewall을 공개 프리뷰로 내놓았습니다. 개발자 PC·CI 러너·코딩 에이전트와 패키지 저장소 사이에서 패키지 목록 요청과 다운로드를 검사합니다. Enterprise Cloud 고객용이며 데이터 레지던시 환경도 포함합니다. 현재는 npm만 지원하고, 프리뷰 동안 무료이며 정식 제공 때는 사용량 기반 과금으로 바뀔 예정입니다. 공식 발표
정책에는 알려진 악성 패키지 차단, 취약점 심각도 기준, 새 버전의 대기 기간 등이 있습니다. 이전 버전에는 있던 공급망 증명이 사라졌는지, 설치 때 실행되는 스크립트가 새로 추가됐는지도 살핍니다. 새 버전의 기본 대기 기간은 하루입니다. 정책별 동작
관리자가 정책을 켜는 것만으로 모든 설치가 보호되지는 않습니다. 각 실행 환경의 패키지 요청이 방화벽 주소를 거치도록 설정해야 합니다. 또 보안 수정이 들어간 새 버전도 대기 기간에 걸릴 수 있어 예외 요청 절차가 있습니다. 설치를 막는 기준과 필요한 업데이트를 통과시킬 절차를 함께 운영하는 기능입니다.
OpenAI — 아침에 읽힌 문맥을 오후에도 재사용하려면
매번 같은 제품 설명서와 도구 정의를 보내지만, 요청은 몇 시간 간격으로 들어오는 서비스가 있다고 해봅시다. 짧은 대화 안에서는 캐시를 잘 쓰더라도, 다음 요청까지 그 캐시가 유지되는지는 다른 문제입니다.
OpenAI는 10월 20일 Responses API에 12시간 프롬프트 캐시 옵션을 추가했습니다. GPT-5.6 이상 모델에서 선택하는 최소 유지 시간으로, 기본값은 30분입니다. 지난 호의 Vercel 기사가 캐시를 이용한 요청 경로를 들여다보는 화면이었다면, 이번에는 재사용할 문맥을 얼마나 오래 유지할지 정하는 옵션입니다. API 변경 기록
오래 보관하는 쪽의 쓰기 비용이 더 높습니다. 일반 입력 토큰 가격을 기준으로 30분 캐시 쓰기는 1.25배, 12시간은 2.5배이며, 일반 입력 비용에 덧붙는 할증이 아니라 해당 토큰에 적용되는 총 쓰기 요율입니다. 캐시 읽기 요율은 두 유지 시간에 동일합니다. 같은 문맥을 얼마나 자주 다시 쓰는지에 따라 긴 유지 시간이 이득일 수도, 불필요한 비용일 수도 있습니다. 유지 시간과 과금 문서
문서에서는 하루 동안 반복해서 쓸 공통 자료와 자주 달라지는 대화 문맥에 서로 다른 유지 시간을 설정하는 방법도 안내합니다. 단, 12시간은 삭제 시한이 아니고 매번 응답이 빨라진다는 보장도 아닙니다. AI가 새 경험을 배우는 기억 기능과도 다릅니다. 같은 입력의 처리 결과를 재사용하는 기능입니다.
OpenAI GPT-Live — 목소리를 고르는 대신 설명한다
“차분하고 따뜻한 성인 목소리, 일정한 대화 속도.” 이런 설명으로 앱의 음성을 만들 수 있게 됐습니다. OpenAI는 10월 16일 prompt-to-voice를 모든 API 고객에게 정식 제공했습니다. API나 음성 Playground에서 만든 목소리를 저장하고, GPT-Live 세션에서 다시 사용합니다. 생성 자체는 무료이고, 그 목소리로 말을 만드는 세션에는 기존 요금이 적용됩니다. 공식 릴리스 노트
녹음을 본떠 만드는 커스텀 음성과는 이용 범위가 다릅니다. 설명으로 생성한 목소리는 GPT-Live용이며, Text to Speech·Realtime·오디오 출력 Chat Completions API에서는 지원하지 않습니다. 기존 음성 API에 새 목소리의 ID만 넣어 쓸 수는 없습니다. 음성 생성·사용 범위
같은 목소리를 다음 세션에서도 쓰려면 생성된 ID를 보관해 재사용합니다. 매번 같은 설명을 보내 새로 만드는 것과는 다릅니다. 조직당 생성 가능한 목소리는 최대 100개이고, 다른 사용자가 비슷한 목소리를 만들 수 있어 고유한 음색이 보장되지는 않습니다.
함께 추가된 기본 음성 아홉 개에는 한국어 Noeul도 있습니다. 목소리를 직접 설계할지, 제공되는 음성으로 시작할지 선택지가 늘었습니다. 다만 이번 원고에서는 한국어 자연스러움이나 긴 대화에서의 음색 유지까지 직접 들어보고 평가하지는 않았습니다.
Vercel — 실시간 연결도 Functions에서 정식 지원
10월 20일 Vercel Functions의 WebSocket 지원이 정식 제공으로 전환됐습니다. 6월 말 공개 베타 이후의 변화입니다. 클라이언트와 서버가 연결을 열어둔 채 양방향으로 메시지를 주고받을 수 있어, 실시간 AI 대화나 공동 작업 화면을 만들 때 사용할 수 있습니다. 정식 제공 발표
모든 플랜에서 사용할 수 있으며, 하나의 연결은 유지되는 동안 같은 함수 인스턴스에 붙습니다. 하지만 함수의 최대 실행 시간에 도달하면 연결은 닫힙니다. 클라이언트가 다시 연결했을 때는 다른 인스턴스에 도착할 수도 있습니다. 연결 수명과 재연결 문서
가령 함께 편집하는 화면의 참여자 목록과 작업 상태를 함수 메모리에만 두면, 재연결 뒤 같은 상태를 이어받는다고 기대할 수 없습니다. 문서도 영속 상태와 인스턴스 사이의 메시지 조율은 외부 저장소에 두라고 안내합니다. 연결을 다시 여는 코드와 사용자가 하던 일을 복원하는 코드는 별도로 필요합니다.
요금과 제한은 다른 Functions 호출의 기준을 따릅니다. Active CPU 요금은 메시지를 처리하는 CPU 시간에 붙습니다. 그렇다고 연결을 유지하는 동안 다른 비용까지 모두 무료인 것은 아닙니다. 지난 호의 Daemons가 큐에서 일을 가져오는 프로세스였다면, 이번 소식은 사용자와 서버 사이의 실시간 연결을 다룹니다.
L-Proof의 해석
성공한 경험에도 적용 범위가 필요하다
8호에서는 사람이 제안을 거절한 이유가 다음 작업에 남는지 물었습니다. 이번 IBM 실험은 그 질문을 조금 더 구체적으로 만듭니다. 경험을 남긴 다음에는 어떤 상황에서 다시 꺼낼지를 정해야 합니다.
L-Proof는 기억이 쌓이는 에이전트에서 ‘지침을 추가했다’보다 ‘지침의 적용 범위를 정했다’는 변화가 더 중요해질 수 있다고 봅니다. 예를 들어 특정 고객에게만 허용한 환불 예외가 있다고 해봅시다. 그 기록을 다음 상담의 일반 규칙으로 줄여버리면, 지난번 성공이 이번에는 잘못된 처리의 근거가 됩니다. 이번 실험에서 관찰된 사고가 아니라, 경험을 재사용할 때 따져볼 실패입니다.
ALTK-Evolve 저장소에는 지침을 만든 원래 작업과 생성 방식을 기록하고, 충돌하는 새 정보가 들어오면 기존 지침을 갱신하는 기능이 설명돼 있습니다. 이런 기록은 기억을 늘리는 것만큼, 잘못된 기억을 찾아 고칠 때 쓸모가 있습니다. 지침의 출처와 갱신
그렇다고 규칙을 적게 남기는 것이 답도 아닙니다. 드문 상황에만 필요한 지침은 반복해서 등장하지 않았다는 이유로 빠질 수 있습니다. 더 짧은 지침이 안정적이었던 한 실험을 보고 모든 에이전트의 기억을 줄이면, 이번에는 다른 종류의 실패를 만들 수 있습니다.
지침을 잘 따르는 것과 실행을 막는 것은 다르다
GitHub의 패키지 방화벽은 다른 위치에 있습니다. 모델에게 설치 규칙을 기억시키는 대신, 다운로드가 지나가는 경로에서 조건을 검사합니다. L-Proof가 이 차이에 주목하는 이유는, 일을 잘하는 방법과 해서는 안 되는 일을 같은 지침 목록에만 넣어두기 어렵기 때문입니다.
가령 예전에는 설치됐던 패키지에 오늘 악성 경고가 붙었다면, 과거의 성공 기록은 지금 설치해도 된다는 근거가 될 수 없습니다. 이런 조건은 에이전트의 기억과 별개로 실행 시점에 확인할 필요가 있습니다. 반대로 방화벽이 막았다는 사실만으로 패키지 자체가 악성이라고 확정할 수도 없습니다. 새 보안 패치가 대기 기간에 걸리는 경우처럼, 차단 이유를 사람이 다시 판단해야 할 때도 있습니다.
L-Proof는 다음 실험에서 평균 성공률뿐 아니라 업무 규칙이 바뀐 뒤에도 옛 지침을 계속 따르는지를 보고 싶습니다. 오래 일한 AI가 더 유능해졌다는 말에는, 이제 쓸모없어진 경험을 내려놓을 수 있는지도 포함돼야 하지 않을까요.