쓰려던 AI 기능이 심사 대상이라면?
모델 기능이 승인 절차 뒤로 옮겨가는 흐름에서, 작은 팀이 거절을 장애로 만들지 않는 방법
9월 첫 주는 프런티어 모델이 한꺼번에 쏟아진 주였습니다.
Anthropic이 Claude Fable 5.1과 Mythos 5.1을, Google이 Gemini 3.8 Flash를, Meta가 Muse Spark 1.3을, 그리고 OpenAI가 9월 3일 GPT-6 Astra를 내놨습니다.
그런데 작은 팀이 진짜 눈여겨봐야 할 대목은 벤치마크 점수가 아니라 열리는 방식이었습니다.
Astra는 9월 3일 승인된 사용자에게 먼저 열렸고, 그다음 날 유료 사용자에게 일반 공개됐습니다.
다만 이때 공개된 것은 사이버보안 같은 특정 영역의 요청을 거부하는 제한 버전이었고, 민감한 사이버 관련 기능은 별도의 신뢰 접근(trusted access) 프로그램 뒤에 남았습니다.
Google 역시 Gemini 3.8 Flash와는 별도로 게이팅된 Gemini 3.8 Flash Cyber를 따로 뒀습니다.
요약하면, 결제만 하면 전부 쓰던 시대에서 일부 기능은 승인을 받아야 쓰는 시대로 한 칸 이동한 셈입니다.
여기에 하나 더 겹칩니다.
접근 등급만 나뉜 게 아니라 속도와 요금 옵션도 나뉩니다.
Astra에는 표준 요금의 두 배인 Fast 모드가 있고, 컨텍스트 창은 100만 토큰입니다.
즉 "이 모델을 쓴다"는 결정 하나에 승인 여부, 응답 범위, 속도 옵션, 단가가 전부 딸려 옵니다.
예전처럼 모델 이름 하나만 바꿔 끼우는 식으로는 관리가 안 됩니다.
왜 같은 모델인데 우리는 못 쓰는 기능이 생길까?
모델 하나가 여러 등급으로 쪼개져 배포되기 때문입니다.
같은 모델 이름이라도 계정 등급과 승인 여부에 따라 실제로 응답하는 범위가 다를 수 있고, 위험도가 높다고 판단된 영역은 아예 별도 트랙으로 분리됩니다.
OpenAI는 7월 허깅페이스 관련 사건 이후 안전장치를 더 넣기 위해 다음 모델 출시를 늦추기도 했는데, Astra의 단계적 공개는 그 연장선입니다.
작은 팀에게 이건 추상적인 이야기가 아닙니다.
예를 들어 2인 팀이 만든 코드 점검 SaaS가 "이 코드의 취약점을 실제로 공격하는 예시를 만들어 달라"는 사내 요청을 처리하고 있었다면, 모델을 최신 버전으로 올린 다음 날 그 기능만 조용히 거절되기 시작할 수 있습니다.
장애 알림도 안 뜨고, 500 에러도 없고, 고객은 그냥 "답이 이상해졌다"고 말합니다.
우리 제품에서 막힐 기능을 어떻게 미리 찾을까?
거절은 버그처럼 다뤄야 찾을 수 있습니다.
핵심은 우리 서비스의 요청 유형을 목록화하고, 그중 거절 위험이 있는 것만 따로 회귀 테스트로 묶어두는 것입니다.
배포 전에 한 번 돌려보면 "이 모델에서는 이 기능이 안 된다"를 고객보다 먼저 알게 됩니다.
- 거절 케이스 카드: 우리 서비스에서 실제로 들어오는 요청 10~20개를 뽑아 모델별로 통과/거절을 기록합니다.
- 거절 로그 분리: 에러 로그와 별도로 "정책상 거절" 응답을 태깅해 대시보드에 올립니다.
안 세면 안 보입니다. - 모델 ID 하드코딩 금지: gpt-6-astra 같은 모델 ID를 코드 곳곳에 박아두면 대체 경로를 만들 수 없습니다.
라우팅 한 곳에 모아둡니다. - 2군 모델 상시 준비: 같은 작업을 통과시켜 주는 다른 모델을 최소 하나 검증해 둡니다.
지난주만 해도 선택지는 넉넉했습니다. - 사람 경로 설계: 자동 처리가 막히는 요청은 담당자 확인 큐로 넘기고, 사용자에게는 "검토 후 회신"이라고 명확히 알립니다.
승인 신청도 하나의 업무입니다
신뢰 접근 프로그램 같은 심사 트랙은 신청 서류가 곧 통과율입니다.
회사 정보, 실제 용도, 데이터 취급 방식, 로그 보관과 오남용 차단 장치를 문장으로 설명할 수 있어야 합니다.
이건 승인 공지가 뜬 날 급하게 쓰는 문서가 아니라, 미리 한 페이지로 준비해 두는 자료입니다.
반대로 기회도 있습니다.
게이팅이 걸린 영역은 큰 기업도 똑같이 승인 절차를 거칩니다.
우리 팀이 특정 업종의 요청 유형과 거절 경계를 먼저 문서화해 두면, 그 자체가 고객에게 설명할 수 있는 자산이 됩니다.
실제로 "이 기능은 어떤 모델에서 되고 어떤 모델에서 막히는지" 표 한 장을 들고 가는 팀은 제안서에서 신뢰를 얻습니다.
그래서 이번 주에 뭘 하면 될까?
거창한 아키텍처 개편이 아니라, 반나절짜리 정리로 충분합니다.
접근 권한과 요금 조건을 한 표에 모아두는 것부터 시작하세요.
- 우리 서비스가 모델에 보내는 요청 유형을 5~10개로 정리합니다.
- 그중 거절 가능성이 있는 유형에 표시하고, 현재 모델과 대체 모델로 각각 테스트합니다.
- 라우팅 레이어를 만들어 모델 교체를 설정값 한 줄로 바꿀 수 있게 합니다.
- 요금 조건을 같이 적습니다.
Astra는 API 기준 입력 100만 토큰당 10달러, 출력 50달러이고 캐시된 입력은 1달러입니다.
Gemini 3.8 Flash의 도입가는 2026년 12월 31일까지이고, Grok 4.6은 200K 토큰을 넘는 프롬프트에서 요금 구간이 달라집니다. - 거절 시 사용자에게 보여줄 문구와 대체 흐름을 미리 작성해 둡니다.
정리하면, 모델 선택 기준에 성능과 가격 외에 접근 가능성이 추가됐습니다.
작은 팀의 강점은 이 변화를 하루 만에 흡수할 수 있다는 점입니다.
거절을 예상하고 설계한 서비스는 다음 모델이 나와도 흔들리지 않습니다.