[OpenAI][Realtime] WebRTC 세션에 tool 권한을 session.tools와 response.tools로 나눠 붙이는 순서

IT 리서치 노트

[OpenAI][Realtime] WebRTC 세션에 tool 권한을 session.tools와 response.tools로 나눠 붙이는 순서

Realtime 음성 에이전트에 도구를 붙일 때 가장 위험한 기본값은 '세션에 필요한 건 다 열어 둔다'는 생각이다. 2026년 6월 25일 기준 OpenAI 공식 문서는 Realtime 도구를 session.tools와 response.tools 두 군데에 나눠 붙일 수 있다고 설명한다. 이 글은 WebRTC 세션 기준으로 어떤 도구를 어디까지 열어야 운영과 보안이 덜 꼬이는지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 session.tools는 세션 전체에 계속 노출되어도 되는 read-only 도구용이고, response.tools는 특정 의도와 특정 턴에서만 필요한 민감 도구용이다. 여기에 WebRTC의 ephemeral key 구조를 같이 보면, 브라우저는 세션에 붙기만 하고 실제 도구 경계는 서버가 만든 세션 초기값과 응답 생성 시점에서 결정하는 편이 안전하다.

이미 remote MCP 연결 전 OAuth와 tool 권한을 정리한 글을 읽었다면, 이번 글은 그 원칙을 Realtime 세션에 맞춰 세분화한 내용이다. Responses API 쪽 allowed_tools 감각을 다시 보고 싶다면 Responses API에 remote MCP 서버를 붙일 때 allowed_tools를 줄이는 글과 같이 보면 흐름이 맞다.

2. 어디서 실제로 막히는가

실무에서 자주 생기는 실패는 음성 세션 전체에 write 계열 도구까지 다 열어 두는 것이다. 그렇게 하면 사용자가 일반 조회를 하다가도 같은 세션 안에서 상태 변경 도구가 상시 노출된다. 또 WebRTC는 브라우저가 직접 세션에 붙는 구조라서, 개발자가 브라우저 코드 안에서 도구 정책을 대충 합치면 세션 범위와 턴 범위가 섞이기 쉽다.

OpenAI Realtime 도구 문서는 session.tools와 response.tools를 아예 나눠 설명한다. 이 구분을 안 쓰고 한쪽에 몰아 넣으면 approval 정책을 붙일 때도 복잡해진다. 예를 들어 계정 조회는 세션 내내 열어 둬도 되지만 환불, 티켓 수정, 외부 전송 같은 action은 사용자가 동의한 특정 순간에만 노출하는 편이 합리적이다.

WebRTC 인증 흐름도 같이 봐야 한다. OpenAI 문서는 브라우저가 개발자 서버에서 ephemeral key를 받아 Realtime 세션에 연결한다고 적고 있다. 즉 세션 초깃값과 도구 허용 범위는 서버가 쥐고 있어야 한다. 브라우저 쪽에서만 처리하면 툴 정책과 승인 흐름을 재현하기 어렵다.

• 증상: 음성 세션 하나에 조회와 변경 도구가 모두 상시 노출된다.
• 실패: 특정 턴에만 필요한 write 도구를 session.tools에 넣는다.
• 막힘: WebRTC 브라우저 코드와 서버 정책이 서로 다른 tool 표를 쓴다.
• 누락: approval이 필요한 action class를 response 범위로 좁히지 않는다.

증상	먼저 볼 곳	판단 기준
도구 노출이 과하다	session.update의 tools 목록	세션 전체에 필요한 read-only만 남긴다
민감 action 승인 설계가 어렵다	response.create의 tools 목록	특정 의도에서만 필요한 write 도구를 분리한다
브라우저 코드와 서버 정책이 다르다	ephemeral key 발급 서버와 세션 초기화 코드	세션 정책은 서버가 기준을 잡는다

3. 실무에서 적용하는 순서

가장 실용적인 순서는 네 단계다. 먼저 서버가 WebRTC용 ephemeral key를 발급할 때 어떤 세션 정책을 기본값으로 줄지 정한다. 다음으로 session.update에 read-only 기본 도구만 넣는다. 세 번째로 사용자가 특정 action을 명시적으로 요청한 순간에만 response.create로 필요한 도구를 한 번 더 붙인다. 마지막으로 approval과 감사 로그를 action class 기준으로 묶는다.

1. 서버가 만든 세션 기본값에서 read-only 도구만 연다.
2. 세션 전체 도구는 session.tools에 최소한으로 넣는다.
3. 특정 턴의 write 도구만 response.tools로 추가한다.
4. 승인과 감사 로그를 response 수준 action에 묶는다.

이렇게 분리하면 세션 정책이 훨씬 읽기 쉬워진다. 예를 들어 계정 조회와 티켓 검색은 session.tools로 열어 두고, 환불이나 주소 변경처럼 외부 상태를 바꾸는 도구는 response.create에서만 추가한다. 사용자가 취소하거나 승인 조건이 바뀌면 그 턴만 닫으면 되므로 운영이 단순해진다.

운영 메모 예시

session_default:
  tools:
    - searchCustomer
    - getTicket
response_only:
  tools:
    - createRefund
    - updateShippingAddress
approval_required:
  - createRefund
  - updateShippingAddress

브라우저는 세션에 붙는 클라이언트일 뿐이고, 정책은 서버 기준으로 굳히는 편이 낫다. 그래야 WebRTC, WebSocket, MCP 조합이 달라져도 같은 규칙을 재사용할 수 있다.

4. 공식 문서와 예시 화면으로 확인하기

첫 화면은 Realtime with tools 문서의 핵심 구분이다. OpenAI는 툴을 session 수준과 response 수준 두 군데에 붙일 수 있다고 명시한다.

Realtime MCP 문서는 session.tools가 전체 세션 동안 노출되는 도구라는 점을 직접 보여 준다.

즉 session.tools는 편의 옵션이 아니라 노출 범위 결정값이다. 음성 세션 전체에서 늘 필요한 read-only 도구만 여기에 두는 편이 안전하다.

두 번째 화면은 같은 문서의 response.tools 구간이다. 한 턴에서만 필요한 민감 도구는 response.create에만 얹으라는 의미로 읽어야 한다.

response.tools는 특정 응답 한 번에만 필요한 도구를 붙이는 자리다.

이 구조가 있어야 같은 세션 안에서도 검색 도구는 계속 열어 두고, 상태 변경 도구는 특정 의도에서만 잠깐 열어 둘 수 있다. approval 정책 글과 바로 연결되는 지점이다.

세 번째 화면은 WebRTC 인증 흐름이다. 브라우저가 바로 표준 API key를 쓰는 것이 아니라, 개발자 서버가 ephemeral key를 발급해 주고 그 키로 Realtime 세션에 붙는 구조를 먼저 이해해야 한다.

WebRTC 가이드는 브라우저가 개발자 서버에서 ephemeral key를 받아 세션에 붙는 순서를 보여 준다.

즉 tool 범위도 브라우저 코드가 아니라 서버가 만든 세션 초기값에서 결정하는 편이 낫다. 브라우저에 도구 정책을 직접 넣으면 운영 경계가 느슨해지기 쉽다.

세션 초기화는 session.update에서 시작하는 편이 명확하다. read-only 도구와 기본 시스템 지시를 먼저 고정하면 이후 response.create에서 추가 권한을 열 때 비교 기준이 생긴다.

session.update 예시는 세션 전체에 남길 도구와 기본 지시를 어떻게 묶는지 보여 준다.

여기서는 도구 수를 넓히기보다 안정적인 기본값을 남기는 쪽이 중요하다. 이미 Responses API에 remote MCP 서버를 붙이는 글에서 강조한 좁은 surface 원칙을 그대로 가져오면 된다.

특정 턴에서만 민감한 action을 열 때는 response.create에 한 번 더 의도를 분리하는 편이 낫다. 사용자 확인이 끝난 뒤에만 상태 변경 도구를 잠깐 추가하는 구조가 대표적이다.

response.create 예시는 한 턴에서만 필요한 write 계열 도구를 어떻게 제한적으로 여는지 보여 준다.

이렇게 하면 세션 전체는 read-only로 유지하면서도 필요한 순간에만 write 도구를 열 수 있다. 승인 흐름과 감사 로그를 붙일 때도 이 경계가 있으면 정책 설계가 훨씬 단순해진다.

마지막 자료는 세션 레벨과 응답 레벨 분리 기준을 빠르게 점검하는 체크리스트다. 음성 에이전트 운영에서는 이 구분을 코드보다 먼저 팀 규칙으로 적어 두는 편이 유리하다.

도구를 session.tools와 response.tools 중 어디에 둘지 판단하는 빠른 체크리스트다.

이 기준을 문서화해 두면 새 도구를 붙일 때마다 논쟁을 줄일 수 있다. 특히 read-only 조회, 파일 업로드, 외부 전송, 상태 변경 같은 action class를 분리해서 적는 편이 좋다.

5. 주의사항과 리스크

첫 번째 리스크는 session.tools에 너무 많은 도구를 넣어 세션이 길어질수록 위험 표면이 커지는 것이다. 두 번째 리스크는 response.tools를 써도 approval이나 감사 로그를 안 붙여 실제 write action을 추적하지 못하는 것이다. 세 번째 리스크는 브라우저 세션을 믿고 서버가 세션 정책을 충분히 고정하지 않는 것이다.

배포 전에 확인할 때는 WebRTC ephemeral key 발급 서버, session.update payload, response.create payload, 승인 기록 저장 위치를 같이 점검하는 편이 좋다. 한쪽만 보고 나머지를 추정하면 곧바로 엇갈린다.

• session.tools는 read-only 최소 집합 위주로 유지한다.
• response.tools는 write 계열이나 외부 전송 계열에 우선 쓴다.
• 승인과 감사 로그는 response 수준 action과 같이 설계한다.

6. 결론

Realtime 음성 에이전트에서 툴 권한을 안정적으로 줄이려면 세션 전체 노출과 턴 단위 노출을 반드시 나눠야 한다. WebRTC의 ephemeral key 구조 위에 session.tools는 read-only 기본값으로, response.tools는 특정 action 한정값으로 쓰면 tool surface와 approval 경계가 함께 정리된다.

• 세션 전체 도구는 최소 read-only만 남긴다.
• 민감 action은 response.tools로 한 턴만 연다.
• 세션 정책의 기준점은 브라우저가 아니라 서버에 둔다.

7. 참고 링크

1. https://developers.openai.com/api/docs/guides/realtime-mcp
2. https://developers.openai.com/api/docs/guides/realtime-webrtc
3. https://developers.openai.com/api/reference/resources/realtime/client-events/