Claude API로 서비스를 운영하는 회사라면 이런 상황을 생각해볼 수 있습니다. 고객이 1,000명인 서비스에서 단 한 명이 정책을 위반하거나 API를 악용했습니다. 이전에는 그 한 사람의 문제 때문에 서비스 전체가 영향을 받을 가능성도 있었습니다.
Anthropic이 새 API에 추가한 User Profiles는 이런 문제를 조금 더 세분화해 다룰 수 있게 하는 기능입니다. API를 호출하는 회사만 보는 것이 아니라, 그 회사의 서비스를 실제로 사용하는 최종 사용자를 구분할 수 있도록 한 것입니다.
기업 계정 하나로 묶여 있던 AI API 사용
기존 AI API 구조는 대체로 단순했습니다. 개발회사의 서버가 Claude API를 호출하고, API 제공사는 해당 기업의 계정과 사용량을 관리합니다.
이 방식에서는 서비스 안의 개별 고객이 무엇을 했는지 API 제공사 관점에서 구분하기 어렵습니다. 문제가 발생했을 때도 기업 단위의 조치가 먼저 떠오를 수밖에 없습니다. 정상적으로 서비스를 이용하던 다른 고객까지 함께 영향을 받을 수 있는 구조입니다.
문제를 일으킨 사용자만 구분해 처리하는 방식
User Profiles가 적용되면 흐름은 조금 달라집니다. 고객이 서비스를 이용하고, 개발회사는 그 고객을 식별한 정보와 함께 Claude를 사용하게 됩니다. 즉, ‘우리 서버에서 Claude를 호출했다’가 아니라 ‘우리 서비스의 어느 사용자가 이 요청을 발생시켰는지’까지 연결하는 방식입니다.
특정 사용자의 이용 방식에 문제가 있다면, 서비스 전체가 아니라 해당 사용자에게 제한을 적용하는 선택지가 생깁니다. Anthropic은 이와 관련된 Webhook도 추가했습니다. 개발회사가 사용자별 상태 변화나 필요한 조치를 서비스 운영 흐름 안에서 확인할 수 있도록 한 것으로 볼 수 있습니다.
SaaS 회사의 운영 구조가 달라질 수 있습니다
이 변화는 기능 하나가 추가된 정도로만 보기 어렵습니다. AI 기능을 제공하는 SaaS라면 이제 AI API 호출도 사용자 단위로 관리해야 할 필요가 커집니다.
구조로 보면 ‘우리 서버 → Claude’에서 ‘고객 → 우리 서비스 → 고객 식별 → Claude’로 한 단계가 더 생깁니다. 로그인 계정, 내부 사용자 ID, 이용 제한 정책, 문의 대응 과정이 AI 사용 기록과 연결될 수 있기 때문입니다.
이는 클라우드 서비스에서 사용자별 권한을 관리하는 IAM과 비슷한 방향입니다. 누가 어떤 기능을 쓰는지 구분하고, 문제가 생겼을 때 필요한 범위만 제어하는 방식입니다.
AI 기능을 붙일 때 함께 설계할 부분
개발회사는 API 키를 서버에 보관하는 수준에서 한 걸음 더 나아가야 합니다. 각 요청이 어떤 고객에게서 왔는지 안정적으로 연결하고, 서비스 내부의 이용 제한 기준과 AI 제공사의 정책 대응을 어떻게 맞출지 정할 필요가 있습니다.
중요한 것은 개별 사용자를 감시하는 데 있지 않습니다. 한 사용자의 문제로 전체 고객이 불편을 겪지 않도록 운영의 단위를 나누는 데 있습니다. AI가 서비스의 기본 기능으로 들어갈수록, API 연동 방식도 사용자 단위의 책임과 권한을 고려하는 구조로 바뀔 가능성이 큽니다.
