요약: OpenAI가 GPT-5.5를 API에 공개하면서 “더 똑똑한 모델을 쓰면 된다”보다 중요한 질문이 생겼습니다. 1M 토큰 컨텍스트, 구조화 출력, 함수 호출, MCP, 웹 검색, 컴퓨터 사용, hosted shell 같은 기능을 한 요청 안에 넣을 수 있게 됐지만, 운영팀 입장에서는 비용·권한·캐시·평가 기준을 먼저 정해야 합니다. 이 글은 GPT-5.5 전환을 검토하는 개발팀이 바로 점검할 항목을 정리합니다.
OpenAI API changelog 기준 GPT-5.5는 Chat Completions와 Responses API에서 사용할 수 있는 frontier model입니다. 핵심은 단순 성능 향상이 아니라 “긴 컨텍스트와 도구 사용을 기본 전제로 한 모델”이라는 점입니다. 문서에는 1M token context window, image input, structured outputs, function calling, prompt caching, Batch, tool search, built-in computer use, hosted shell, apply patch, Skills, MCP, web search 지원이 명시돼 있습니다.
개발자에게 중요한 변화는 세 가지입니다. 첫째, 긴 문서나 코드베이스를 통째로 넣는 실험이 현실적인 선택지가 됐습니다. 둘째, 모델이 외부 도구를 호출하는 범위가 넓어져서 권한 설계가 제품 설계의 일부가 됐습니다. 셋째, 캐시 방식이 달라졌습니다. GPT-5.5는 extended prompt caching만 지원하고 in-memory prompt caching은 지원하지 않는다고 공지돼 있습니다. 기존에 짧은 프롬프트 반복 호출 중심으로 비용을 잡던 팀은 캐시 전략을 다시 봐야 합니다.
모델 전환은 SDK 버전만 올리는 작업이 아닙니다. 특히 에이전트형 서비스라면 같은 프롬프트라도 도구 선택, 추론 길이, 출력 포맷이 달라질 수 있습니다. OpenAI 문서에서도 reasoning effort 기본값이 medium으로 바뀌었다고 설명합니다. 이 값 하나만으로도 응답 지연시간과 비용, 답변 스타일이 바뀝니다.
예를 들어 고객지원 자동화에서 기존 모델이 FAQ 검색 도구만 호출했다면, 새 모델은 웹 검색이나 내부 도구 호출까지 시도할 수 있습니다. 권한 범위를 느슨하게 열어둔 상태라면 “정확한 답변”보다 “예상하지 못한 행동”이 먼저 문제가 됩니다. 코딩 에이전트에서는 apply patch나 hosted shell을 잘 쓰면 생산성이 올라가지만, 승인 정책 없이 붙이면 잘못된 파일 수정이나 의도치 않은 명령 실행 리스크가 생깁니다.
첫 번째 기준은 요청 유형 분리입니다. 모든 트래픽을 GPT-5.5로 보내지 말고 복잡도 기준을 먼저 나누는 편이 안전합니다. 긴 리서치, 복합 도구 호출, 멀티파일 코드 수정, 이미지가 섞인 분석은 GPT-5.5 후보입니다. 반대로 분류, 짧은 요약, 정형 추출은 더 작은 모델이 비용 대비 낫습니다.
두 번째 기준은 컨텍스트 예산입니다. 1M 토큰을 넣을 수 있다는 말은 1M 토큰을 매번 넣어도 된다는 뜻이 아닙니다. 긴 컨텍스트는 디버깅을 어렵게 만들고, 검색 결과와 원본 문서가 섞이면 근거 추적이 흐려집니다. 운영에서는 “항상 전체 문서”보다 “검색으로 후보 20개 선별 후 원문 일부 투입”이 더 안정적입니다.
세 번째 기준은 도구 권한입니다. 함수 호출, MCP, 컴퓨터 사용, shell 계열 기능은 권한 등급을 나눠야 합니다. 읽기 전용 도구, 쓰기 가능 도구, 외부 전송 도구, 결제·삭제·배포 같은 고위험 도구를 같은 레벨로 두면 안 됩니다. 최소한 사용자 승인, 샌드박스, 로그 저장, 재현 가능한 요청 ID가 필요합니다.
네 번째 기준은 출력 계약입니다. GPT-5.5가 구조화 출력을 지원하더라도 스키마 검증은 애플리케이션에서 해야 합니다. JSON이 파싱된다는 것과 업무적으로 유효하다는 것은 다릅니다. 필수 필드 누락, enum 범위 이탈, 근거 없는 URL, 날짜 형식 오류는 별도 검증으로 막아야 합니다.
다섯 번째 기준은 평가 세트입니다. 모델 교체 전후로 같은 입력 100~300개를 비교해야 합니다. 단순 win-rate보다 실패 유형을 봐야 합니다. 지연시간 증가, 환각, 도구 과다 호출, 비용 상승, 민감정보 노출 가능성, 사용자 의도 오해를 따로 기록하면 롤백 기준이 분명해집니다.
긴 시스템 프롬프트, 정책 문서, 제품 매뉴얼을 계속 넣는 서비스라면 extended prompt caching이 비용 절감의 핵심입니다. 캐시가 잘 먹는 구간과 매번 바뀌는 구간을 분리해야 합니다. 예를 들어 시스템 정책, 도구 설명, 제품 카탈로그 요약은 고정 영역으로 두고, 사용자 질문과 최근 대화만 동적 영역으로 둡니다.
반대로 매 요청마다 컨텍스트가 크게 달라지는 리서치형 서비스는 캐시 기대치를 낮춰야 합니다. 이 경우 비용 최적화는 캐시보다 라우팅이 우선입니다. 먼저 작은 모델이 “이 요청이 고급 모델을 필요로 하는가”를 판단하고, 필요한 경우에만 GPT-5.5로 넘깁니다. 실패 시 재시도도 전체 재실행이 아니라 실패한 도구 호출 이후부터 이어갈 수 있어야 합니다.
추천 순서는 shadow test, limited beta, traffic ramp-up입니다. shadow test에서는 실제 사용자 응답에는 기존 모델을 쓰고, 백그라운드에서 GPT-5.5 결과만 저장합니다. limited beta에서는 내부 사용자나 일부 고객에게만 새 모델을 적용합니다. ramp-up에서는 5%, 20%, 50%, 100%처럼 단계적으로 늘리고 각 단계마다 비용과 실패율을 확인합니다.
각 단계의 로그에는 최소한 model, reasoning effort, input token, output token, tool call list, tool latency, cache hit 여부, validation result, user-visible error를 남겨야 합니다. “모델이 이상했다”는 보고는 쓸모가 없습니다. 어느 요청에서 어떤 도구를 왜 호출했고 어디서 실패했는지 보여야 수정할 수 있습니다.
출처: OpenAI API changelog, OpenAI Codex models 문서.
