Python으로 공부하는 OpenAI 31편 — FastAPI + OpenAI B2B SaaS, 기업 고객이 물어보는 보안·보존·감사 항목은 어디까지 준비해야 할까?

Python으로 공부하는 OpenAI 31편 — FastAPI + OpenAI B2B SaaS, 기업 고객이 물어보는 보안·보존·감사 항목은 어디까지 준비해야 할까?

한 줄 요약

FastAPI + OpenAI 서비스를 기업 고객에게 판매하려면, 기능 데모보다 먼저 데이터 보존 정책, 프로젝트/서비스 계정 분리, API 키 권한, 고객별 문서 경계, 감사용 로그, 저장 여부(store) 정책, background mode 사용 범위를 설명할 수 있어야 합니다. OpenAI는 API 플랫폼에서 프로젝트 단위 데이터 보존 제어, 서비스 계정, 키 권한, Responses 저장 동작, Zero Data Retention, 데이터 레지던시 옵션을 문서화하고 있습니다. (OpenAI Developers)

---

왜 이 글이 중요한가?

멀티테넌트 구조를 만든 뒤 실제 기업 고객이 붙기 시작하면 질문이 바뀝니다.

이제는 “RAG가 되나요?”보다 이런 질문이 더 자주 나옵니다.

• 우리 데이터는 얼마나 저장되나요?
• 고객별로 완전히 분리되나요?
• 운영자는 누가 접근할 수 있나요?
• 키는 사람 키인가요, 서비스 계정인가요?
• 감사할 수 있는 로그가 남나요?
• ZDR이나 데이터 레지던시가 필요한데 가능한가요?

이 질문에 답을 못 하면, 기능이 좋아도 도입이 멈춥니다. OpenAI는 business data/privacy 페이지에서 기업 고객을 위한 데이터 보존 제어, Enterprise Key Management, 보안·컴플라이언스 정보를 별도로 안내하고 있고, security and privacy 페이지에서는 SOC 2 Type 2와 ISO 27001/27017/27018/27701 인증을 명시합니다. (OpenAI)

---

먼저 결론부터: B2B 고객 대응에서 꼭 준비해야 할 6가지

제가 추천하는 우선순위는 이렇습니다.

1. 고객별 데이터 경계 설명
2. Responses 저장 정책과 store 사용 기준
3. 서비스 계정과 키 권한 분리
4. 문서/벡터 스토어 삭제·만료 정책
5. 감사 가능한 운영 로그
6. 고객 요구 시 ZDR / data residency / 계약 문서 대응 흐름

이 여섯 가지가 정리되면, 기술 데모가 아니라 도입 가능한 서비스로 보이기 시작합니다. OpenAI 문서도 데이터 보존 제어, 서비스 계정, API 키 권한, spend alerts, rate limits, roles 등을 프로젝트/관리 API 수준에서 다루고 있습니다. (OpenAI Developers)

---

1. 제일 먼저 준비해야 할 것: 고객별 데이터 경계

B2B SaaS에서 가장 먼저 설명해야 하는 건 “우리는 고객 데이터를 어디서 어떻게 나누는가”입니다.

OpenAI 프로젝트 관리 문서에 따르면 서비스 계정은 project scope를 가지며, 프로젝트 범위 안에서만 리소스에 접근합니다. 또 data retention controls는 조직 수준뿐 아니라 project level로도 설정할 수 있습니다. (OpenAI Developers)

그래서 현실적인 설계는 보통 이 둘 중 하나입니다.

1) 고객군 단위 프로젝트 분리

• enterprise 고객마다 OpenAI 프로젝트를 분리
• 고객별 service account 발급
• 고객별 vector store / files / usage 추적

2) 단일 프로젝트 + 앱 레벨 강한 격리

• 고객 수가 적고
• 보존 정책이 유사하고
• 문서/검색 경계를 앱이 확실히 강제할 수 있을 때

기업 고객이 보안·감사 질문을 많이 하는 단계라면, 고객군별 또는 중요 고객별 프로젝트 분리를 검토할 가치가 큽니다. 프로젝트 단위 사용량, 서비스 계정, 데이터 보존 제어를 설명하기도 더 쉬워집니다. (OpenAI Developers)

---

2. Responses 저장 정책은 반드시 설명 가능해야 합니다

이건 진짜 자주 나오는 질문입니다.

OpenAI data controls 문서에 따르면 /v1/responses는 기본적으로, 또는 store=true일 때 30일 application state retention이 있고, abuse monitoring logs는 최대 30일 유지될 수 있습니다. ZDR가 승인된 조직/프로젝트에서는 Responses의 store가 항상 false로 처리됩니다. 또한 stateful Responses를 쓸 수 없는 조직을 위해 store: false와 reasoning.encrypted_content를 함께 쓰는 stateless 패턴도 안내합니다. (OpenAI Developers)

즉, B2B 고객 대응에서는 최소한 아래를 설명할 수 있어야 합니다.

• 기본적으로 어떤 데이터가 얼마나 남는지
• store=false를 언제 쓰는지
• 어떤 기능은 stateful Responses를 쓰고, 어떤 기능은 stateless로 제한하는지
• ZDR 요구가 있는 고객에게 어떤 제약이 생기는지

이걸 모르면 “저장 안 합니다” 같은 위험한 답을 하게 됩니다.
실제로는 기능별로 저장 동작이 다를 수 있으니까요. (OpenAI Developers)

---

3. Background mode는 기업 고객에게 더 조심해서 써야 합니다

긴 작업을 처리할 때 Background mode는 정말 편합니다.
그런데 모든 고객에게 무조건 켜두면 안 될 수 있습니다.

OpenAI background 관련 설명에 따르면 Background mode는 polling을 위해 응답 데이터를 일정 시간 저장하며, deep research 가이드도 store=true인 Responses는 30일 로그가 남을 수 있고 로그 검토를 권장합니다. business data/privacy와 data controls 문서는 보존 제어와 ZDR를 함께 설명합니다. (OpenAI Developers)

그래서 기업 고객용 정책은 보통 이렇게 나뉩니다.

• 일반 고객: 긴 리포트/대용량 분석에 background 허용
• 민감 고객: background 사용 제한 또는 별도 승인
• ZDR 요구 고객: stateless 경로 우선 검토

즉, Background mode는 “기술적으로 가능하다”보다 보존 정책상 허용되는가를 먼저 봐야 합니다. (OpenAI Developers)

---

4. 서비스 계정과 키 권한은 사람 기준이 아니라 시스템 기준으로 정리해야 합니다

OpenAI 프로젝트 문서에 따르면 service account는 시스템용 pseudo-user이며 project scope에 묶입니다. API 키 권한은 All, Restricted, Read Only로 조정할 수 있습니다. (OpenAI Developers)

기업 고객 대응에서는 이 두 가지를 분리해서 설명하는 편이 좋습니다.

서비스 계정

• API 서버용
• worker용
• batch/job용
• 운영 자동화용

키 권한

• 일반 요청 서버: Responses 중심 권한
• 문서 처리 워커: files / vector stores 관련 권한
• 읽기 전용 모니터링: read-only
• 관리자 자동화: 별도 restricted 키

이렇게 말하면 고객도 이해하기 쉽습니다.

“운영 서버가 사람 개인 키를 쓰지 않고, 기능별 서비스 계정과 제한된 키 권한으로 동작합니다.”

이 한 문장이 신뢰를 꽤 올려줍니다. (OpenAI Developers)

---

5. 문서와 벡터 스토어는 삭제 정책까지 설명해야 합니다

반응형

RAG가 있는 B2B SaaS라면 이 부분은 거의 필수입니다.

OpenAI data controls 문서에 따르면 /v1/files와 /v1/vector_stores는 application state를 보존합니다. files는 수동 삭제 또는 expires_after 설정으로 만료를 둘 수 있습니다. 삭제하지 않으면 관련 객체가 계속 남을 수 있습니다. (OpenAI Developers)

그래서 고객 대응에서는 최소한 아래를 정리해야 합니다.

• 고객별 vector store 분리 여부
• 문서 업로드 후 retention 정책
• 삭제 요청 시 OpenAI files / vector stores도 함께 정리되는지
• 만료(expires_after)를 어디에 쓰는지
• source/citation 노출이 고객 경계를 넘지 않는지

이건 기능 설명이 아니라 데이터 생명주기 설명입니다.
기업 고객은 이걸 묻습니다.

---

6. 감사 로그는 “무엇을 남기나”와 “무엇을 남기지 않나”를 같이 정해야 합니다

OpenAI API overview는 request IDs, authentication, errors, rate limits 같은 공통 동작을 문서화하고 있고, deep research 가이드는 요청과 외부 MCP 서버 전송 데이터를 로깅하고 주기적으로 검토하라고 권장합니다. 또 business/privacy와 security/privacy 페이지는 기업 데이터 보호와 보안 인증을 설명합니다. (OpenAI Developers)

그래서 운영 로그는 보통 이런 식으로 가는 편이 좋습니다.

남겨야 하는 것

• request_id
• tenant_id
• user_id 또는 actor_id
• endpoint
• model
• latency
• input/output token usage
• selected tool / selected workflow
• file_id / vector_store_id 매핑
• error type

남기면 안 되는 것

• API 키
• Authorization 헤더
• 원문 문서 전체
• 검색 chunk 전체
• 고객 민감 입력 전체 덤프

기업 고객은 “로그가 있나?”만 묻지 않습니다.
“민감 데이터가 로그에 남지 않게 했나?”도 같이 봅니다.

---

7. 데이터 레지던시와 계약 문서는 기술보다 먼저 요구될 수 있습니다

OpenAI는 business data/privacy 페이지에서 데이터 보존 제어, Enterprise Key Management, 규제 대응 정보를 설명하고, security/privacy 페이지에서 SOC 2 Type 2와 ISO 27001/27017/27018/27701을 명시합니다. 지역별 데이터 레지던시 소개 페이지와 help 문서는 DPA, GDPR/CCPA 지원 맥락도 안내합니다. (OpenAI)

즉, 기업 고객 대응에서 자주 필요한 건 이 세 가지입니다.

• DPA/보안 문서 요청 대응
• 데이터 보존 제어 설명
• 지역/규제 요구에 대한 현재 지원 범위 설명

여기서 중요한 건 과장하지 않는 겁니다.

• 가능한 것
• 조건부 가능한 것
• 아직 안 되는 것

이걸 분명히 말하는 편이 오히려 신뢰를 줍니다.

---

8. OpenAI 쪽 경계와 우리 서비스 쪽 경계를 분리해서 설명해야 합니다

이건 정말 중요합니다.

고객은 보통 “OpenAI가 뭘 보관하나요?”와 “당신들 서비스 DB에는 뭐가 남나요?”를 따로 묻지 않습니다.
그냥 “데이터가 어떻게 되나요?”라고 묻습니다.

그래서 답변은 두 층으로 분리해서 준비하는 게 좋습니다.

OpenAI 플랫폼 층

• Responses 저장 정책
• store 사용 여부
• ZDR / MAM / project-level controls
• files/vector stores 보존
• service accounts / key permissions

우리 서비스 층

• 고객 DB에 뭐가 남는지
• 로그에 뭐가 남는지
• source/citation이 어떻게 보이는지
• 삭제 요청 시 내부 DB와 OpenAI 객체를 어떻게 같이 지우는지
• tenant 경계를 어떻게 강제하는지

이 둘을 한 문장으로 섞어 말하면 거의 꼭 오해가 생깁니다.

---

지금 바로 써볼 수 있는 “B2B 고객 정책 요약” 코드 예제

아래 코드는 고객 정책에 따라

• 어떤 프로젝트를 쓰는지
• store를 어떻게 둘지
• background를 허용할지
• file search를 허용할지
  를 결정하는 아주 단순한 예제입니다.

from dataclasses import dataclass
from typing import Literal


RetentionMode = Literal["default", "store_false", "zdr_like"]
SecurityTier = Literal["standard", "enterprise"]


@dataclass
class CustomerProfile:
    customer_id: str
    security_tier: SecurityTier
    retention_mode: RetentionMode
    requires_data_residency: bool
    allow_long_running_jobs: bool
    allow_document_search: bool


def build_openai_policy(profile: CustomerProfile) -> dict:
    project_name = f"proj_{profile.customer_id}_{profile.security_tier}"

    if profile.retention_mode == "store_false":
        store = False
    elif profile.retention_mode == "zdr_like":
        store = False
    else:
        store = True

    background_allowed = profile.allow_long_running_jobs and profile.retention_mode == "default"

    return {
        "project": project_name,
        "store": store,
        "background_allowed": background_allowed,
        "file_search_allowed": profile.allow_document_search,
        "needs_residency_review": profile.requires_data_residency,
    }


if __name__ == "__main__":
    customer = CustomerProfile(
        customer_id="acme",
        security_tier="enterprise",
        retention_mode="store_false",
        requires_data_residency=True,
        allow_long_running_jobs=True,
        allow_document_search=True,
    )

    policy = build_openai_policy(customer)

    for key, value in policy.items():
        print(f"{key}: {value}")

실행 방법

python b2b_policy_profile.py

예상 결과

project: proj_acme_enterprise
store: False
background_allowed: False
file_search_allowed: True
needs_residency_review: True

이 코드는 단순하지만 좋습니다.
고객 정책을 감으로 처리하지 않고, profile 기반 정책으로 명시하게 해주니까요.

---

기업 고객 대응 체크리스트

보안 / 권한

• 서비스 계정을 쓰는가
• API 키 권한이 제한돼 있는가
• prod/staging 키가 분리돼 있는가

데이터 경계

• tenant_id 기준으로 문서/작업/로그가 분리되는가
• 고객별 vector store 분리가 필요한가
• source 노출이 고객 경계를 넘지 않는가

보존 / 삭제

• store 정책을 고객별로 설명 가능한가
• files / vector stores 삭제 흐름이 있는가
• background mode 저장 특성을 알고 쓰는가

계약 / 규제

• data residency 요청 시 검토 절차가 있는가
• DPA/보안 문서 요청 대응 자료가 있는가
• 보안 인증과 현재 지원 범위를 과장 없이 설명 가능한가

---

FAQ

Q. 기업 고객이면 무조건 고객별 OpenAI 프로젝트를 따로 써야 하나요?

무조건은 아닙니다. 하지만 프로젝트 단위 service account, usage 추적, data retention controls, residency 요구 대응을 생각하면 중요한 고객이나 요구사항이 다른 고객군은 분리할 가치가 큽니다. (OpenAI Developers)

Q. store=false만 켜면 기업 보안 요구에 충분한가요?

항상 그렇지는 않습니다. Responses 저장과 abuse monitoring, files/vector stores 보존, background mode 저장 특성, third-party 연동 여부까지 함께 봐야 합니다. ZDR 요구가 있으면 stateful Responses 사용 방식도 달라질 수 있습니다. (OpenAI Developers)

Q. service account가 왜 중요한가요?

사람 계정이 아니라 시스템용 pseudo-user이고 project scope에 묶여 있어서, 운영 서버·worker·batch 작업을 더 안전하게 분리할 수 있기 때문입니다. (OpenAI Developers)

Q. 기업 고객이 가장 먼저 신뢰하는 포인트는 뭔가요?

기능보다도 보통 이 순서입니다.

• 데이터가 어떻게 나뉘는지
• 누가 접근하는지
• 얼마나 저장되는지
• 삭제 요청 시 어떻게 지우는지
• 사고가 나면 무엇을 추적할 수 있는지

이 다섯 가지를 분명하게 설명할 수 있으면 도입 논의가 훨씬 빨라집니다.

---

핵심 요약

• 멀티테넌트 B2B SaaS에서는 기능보다 고객별 데이터 경계, 프로젝트 경계, 키 권한, 보존 정책이 먼저입니다. (OpenAI Developers)
• service account와 restricted key는 운영 서버와 worker를 더 안전하게 분리하는 데 유리합니다. (OpenAI Developers)
• Responses 저장 정책, store=false, ZDR, files/vector stores 보존, background mode 저장 특성을 함께 이해해야 합니다. (OpenAI Developers)
• data residency, DPA, SOC 2/ISO 계열 같은 문서 대응은 기술 도입 논의에서 실제로 자주 필요합니다. (OpenAI)
• 플랫폼은 실행과 권한 경계를 도와주고, 우리 서비스는 tenant policy와 삭제·감사·UX를 책임지는 구조가 가장 현실적입니다. (OpenAI Developers)

---

출처

• OpenAI Data controls in the API platform — 조직/프로젝트 수준 data retention controls, ZDR/MAM, files/vector stores/application state 보존 설명. (OpenAI Developers)
• OpenAI Business data privacy, security, and compliance — business data 보존 제어, EKM, 기업용 데이터 보호 설명. (OpenAI)
• OpenAI Security and privacy — SOC 2 Type 2, ISO 27001/27017/27018/27701 인증 설명. (OpenAI)
• OpenAI API Overview — authentication, request IDs, rate limits 등 공통 API 동작 설명. (OpenAI Developers)
• OpenAI Migrate to the Responses API — ZDR 요구 시 store:false와 reasoning.encrypted_content 기반 stateless 패턴 설명. (OpenAI Developers)
• OpenAI Deep Research guide — Responses store=true 사용 시 로그 보존과 로깅 검토 권장. (OpenAI Developers)
• OpenAI Help Center: Managing projects — service account는 pseudo-user이며 project scope, 프로젝트 리소스 관리 설명. (OpenAI Developers)
• OpenAI Help Center: Assign API Key Permissions — All, Restricted, Read Only 권한 설명. (OpenAI Developers)
• OpenAI data residency 안내 — DPA, GDPR/CCPA 지원, residency 맥락 설명. (OpenAI)

Python, OpenAI, FastAPI, B2B SaaS, 멀티테넌트, service account, API key permissions, Responses API, data retention, store false, Zero Data Retention, data residency, Vector Store, enterprise security, 주니어 개발자