OpenAI API 프로덕션 배포 가이드: 모더레이션·입력 검증·함수 호출·구조화 출력

핵심 메시지

• 데모에서 완벽하게 동작하던 AI 앱도 실제 사용자를 만나면 시스템 프롬프트 유출, 유해 콘텐츠 생성, JSON 파싱 실패라는 문제에 곧바로 부딪힌다.
• OpenAI가 무료로 제공하는 모더레이션 API는 100밀리초 안에 혐오·괴롭힘·자해·성적·폭력 범주를 분류해, 완성 토큰을 한 개도 쓰기 전에 요청을 되돌려 보낸다.
• 함수 호출은 모델에게 권한이 아니라 요청 창구만 내주는 구조다. 모델은 어떤 도구를 쓸지 '요청'할 뿐이고, 실행 여부는 내 코드가 결정한다.
• 구조화 출력은 제약 디코딩으로 스키마에 맞는 JSON을 보장하지만 값의 타당성까지 책임지지는 않아, 스키마 검증 위에 업무 규칙 검증을 한 겹 더 얹어야 한다.
• 지수 백오프 재시도, 사용자별 토큰 상한, 속성 기반 평가 하니스까지 갖춰야 실제 사용자 앞에 내놓을 수 있는 시스템이 된다.

쉽게 이해하기

AI 기능을 붙인 서비스가 개발 환경에서 잘 돌아간다고 해서 배포 준비가 끝난 것은 아니다. 영상은 실제 배포 직후 벌어지는 세 가지 장면부터 보여준다. 한 사용자는 교묘한 입력으로 시스템 프롬프트를 그대로 뽑아내고, 다른 사용자는 서비스가 만들어서는 안 될 콘텐츠를 생성하게 만들며, 또 다른 요청에서는 모델이 순수 JSON 대신 마크다운을 섞어 내놓는 바람에 파서가 그대로 멈춘다. 운이 나빠서 생긴 사고가 아니라 프로덕션에 올라간 AI 시스템이면 모두 겪는 일이라는 것이 이 영상의 출발점이다.

해법으로 제시되는 구조는 사용자 메시지가 모델에 닿기 전에 통과해야 하는 세 개의 층이다. 첫 번째는 모더레이션 층으로, 유해 의도를 가진 입력을 분류기가 먼저 걸러낸다. 두 번째는 입력 검증 층으로, 길이 제한을 걸고 인젝션 패턴을 찾아내며 모델의 문맥을 흐트러뜨릴 수 있는 마크다운·HTML·제어 문자를 제거한다. 세 번째는 함수 호출과 구조화 출력 층으로, 모델이 호출할 수 있는 도구를 명시적으로 등록한 것만 허용하고 응답 형식을 타입이 정해진 JSON으로 강제한다.

특히 형식 문제를 다루는 방식이 인상적이다. 영상은 모델의 가장 큰 신뢰성 문제가 '틀린 답'이 아니라 '일정하지 않은 형식'이라고 짚는다. JSON을 달라고 해도 마크다운이 오고, 목록을 달라고 해도 산문이 온다. 구조화 출력은 응답 형식과 JSON 스키마를 지정해 모델의 토큰 샘플링 자체를 스키마에 맞는 출력만 나오도록 제약하는 방식으로 이 문제를 없앤다. 파이썬이라면 Pydantic과 묶어 검증된 객체로 바로 받을 수 있다.

다만 형식이 맞다고 값까지 맞는 것은 아니다. 점수 필드에 0~100 범위를 벗어난 150이 들어오거나, 정해둔 세 가지 값이 아닌 엉뚱한 감성 레이블이 들어오거나, 요약문에 존재하지 않는 제품 이름이 섞여 들어올 수 있다. 그래서 스키마 검증을 통과한 뒤에도 범위·열거값·일관성을 확인하는 도메인 검증을 돌리고, 실패하면 오류 메시지를 덧붙여 다시 호출하거나 안전한 대체 응답을 반환해야 한다. 잘못된 출력을 조용히 다음 단계로 흘려보내는 선택지는 없다.

마지막은 운영 문제다. API 호출은 속도 제한과 네트워크 타임아웃, 서버 오류로 실패한다. 429가 오면 시도 횟수에 따라 대기 시간을 늘리고 무작위 지연을 더해 재시도하고, 500번대 오류도 같은 방식으로 처리하되 나머지 오류는 빨리 실패시키라는 것이 권장 패턴이다. 비용 쪽에서는 사용자별 호출 제한, 하루 토큰 예산, 응답 길이 상한이라는 세 겹이 필요하고, 모든 요청의 토큰 수를 기록해 두어야 기능별 실제 비용을 계산할 수 있다.

주요 인사이트

• 모더레이션을 맨 앞에 두는 이유는 안전만이 아니라 비용이다. 분류기가 무료이고 100밀리초 안에 끝나므로, 어차피 거절할 요청에 완성 토큰을 쓰지 않게 된다.
• 프롬프트 인젝션 방어는 거창한 기술이 아니라 길이 제한, 정규식 기반 인젝션 패턴 탐지, 문자 정규화라는 세 가지 검사를 호출 전에 넣는 작은 클래스에서 시작한다.
• 함수 호출의 핵심은 모델이 데이터베이스나 자격 증명에 직접 닿지 않는다는 점이다. 모델은 도구 이름과 인자를 제안할 뿐이고, 실행 권한은 끝까지 애플리케이션이 쥔다.
• LLM 응답 자체는 단위 테스트가 어렵지만 그 주변은 모두 테스트할 수 있다. CI에서는 클라이언트를 목으로 대체하고, 실제 호출이 들어가는 통합 테스트는 배포 전에 따로 돌린다.
• 출력 품질 검증은 정답 문자열 비교가 아니라 속성 검사로 하는 편이 낫다. 감성 값이 정해진 세 가지 안에 있는지, 요약 길이가 범위 안인지, 호출된 도구가 등록된 것뿐인지를 확인하는 방식이다.

자주 묻는 질문

관련 AI 소식