“직접 만들 것인가, 아니면 구매할 것인가”: 첫 번째 장애가 발생한 후 답변이 바뀌는 질문입니다. 데모(Demo) 상에서 모든 벤더(Vendor)의 기성 봇은 똑같이 설득력 있게 보입니다. 빠르게 응답하고, 언어를 이해하며, 문맥(Context)을 파악합니다. 모든 것이 제대로 작동하는 동안에는 두 옵션 사이의 차이가 거의 없습니다.

차이는 봇이 중요한 대화 도중에 침묵하거나 사용자에게 잘못된 답변을 확신을 가지고 내뱉는 순간 나타납니다. 그때 데모가 답해주지 못하는 단 하나의 질문이 떠오릅니다: 과연 누가 대화를 복구하고 오류를 설명할 것인가?

이 글은 “직접 개발하기”와 “기성 제품 사용하기” 사이의 선택에 관한 것이 아닙니다. 하나의 간단한 연습, 즉 두 가지 장애에 대한 테이블탑 분석(Tabletop exercise)을 통해 출시 전 기성 봇을 검증하는 방법에 관한 것입니다. 이어지는 내용에서 저는 “장애—소유자—데이터—복구” 지도를 제안하고, 이 지도가 어디에서 가장 자주 끊어지는지 보여줄 것입니다. 미리 범위를 명시하자면: 테이블탑 분석은 서비스의 실제 가용성을 확인하거나 답변의 품질을 보장하지 않으며, 단지 장애 발생 시 설명 가능한 복구 경로가 있는지만을 보여줍니다.

빠른 시작이 아무것도 보장하지 않는 이유

시작 속도는 운영(Exploitation)이 아닌 데모(Demo)가 측정하는 것입니다. 기성 봇은 본질적으로 타사 벤더의 인프라(Infrastructure) 위에 구축된 하나의 모델 경로(Model route)에 불과합니다. 자체적인 복구 루프(Recovery loop)는 단일 벤더가 아니라, 최소한 모델에 대한 예비 경로를 가지고 있는 지점부터 시작됩니다. 이 예시에 대해서는 나중에 다시 다루겠습니다.

첫 번째 장애가 발생한 후, 제품 관리자(Product Manager)는 보통 다시 검색창을 열고 “chatgpt 유사 서비스”, “chatgpt 대안”, “chatgpt 대체제”, “chatgpt 인공지능 유사 서비스”와 같은 검색어를 입력합니다. 이는 같은 과정을 반복하는 두 번째 시도이며, 도움이 되는 경우는 드뭅니다. 새로운 벤더 역시 장애 대응 규정(Reglament)이 아닌 데모(Demo)만을 다시 보여주기 때문입니다.

«기성품을 선택하기»의 대안은 직접 «ChatGPT 봇 만들기»를 시도하고, «나만의 ChatGPT 봇»을 구축하며, 엔지니어링 작업이라는 비용을 치르는 대신 완전한 통제권을 얻는 것입니다. 저는 어느 한쪽 편을 드는 것이 아닙니다. 제가 주장하는 바는 더 구체적입니다. 기성 봇(ready-made bot)은 기능 목록이나 얼마나 빨리 구동되는지가 아니라, 인시던트(incident)를 견뎌낼 수 있는 능력으로 검증해야 한다는 것입니다.

출시 전 분석해야 할 두 가지 장애

가용성 불능(Unavailability)과 잘못된 응답(Erroneous response)은 구조가 다르며, 하나의 체크리스트로 분석할 수 없습니다. 첫 번째는 즉각적으로 드러납니다. 즉, 봇이 응답하지 않는 것입니다. 두 번째는 더 위험합니다. 외관상으로는 모든 것이 정상 작동하는 것처럼 보이기 때문입니다. 사용자는 일관성 있는 문장을 받지만 그것이 틀린 내용일 수 있으며, 이를 사실로 받아들여 그대로 전달하게 됩니다.

모델 레이어(Model layer)에서 이 두 가지 클래스는 공개된 기록에서도 서로 다르게 나타납니다. 2026년 7월 18일 기준 OpenAI 인시던트 기록을 보면, 2026년에는 «대화 오류율 상승»(elevated conversation error rate)과 같은 짧은 인시던트가 반복되고 있음을 알 수 있습니다. 예를 들어 7월 15일, 6월 3일과 2일, 4월 22일과 20일 등이 그러합니다. 이는 정확히 «잘못된 응답»의 운영적 형태입니다. 서비스 전체는 살아있지만, 일부 대화가 깨지는 현상입니다.

완전한 가용성 불능은 스펙트럼의 반대편에 있습니다. 기록된 2026년 4월 29일 인시던트 («ChatGPT 사용자가 대화 중 문제를 겪을 수 있음»)는 약 9분 동안 지속되었으며, 대화 기능의 부분적 장애로 분류되었습니다. 이 건은 원인에 대한 공개적인 분석 없이 «모든 영향을 받은 서비스가 현재 완전히 복구되었습니다»라는 문구와 함께 종료되었습니다. 이러한 유형의 짧은 장애에 대해 근본 원인(root cause)이 공개적으로 밝혀지는 경우는 거의 없으며, 이는 데스크톱 리뷰어가 타사의 공개 기록을 통해 알아낼 수 있는 실제적인 한계이기도 합니다.

Сравнение двух классов сбоя готового GPT-бота по публичной хронике OpenAI

«장애—소유자—데이터—복구» 지도

분석이 단순한 비공식 메모로 전락하지 않으려면, 실제 포스트모템 (Postmortem)과 같은 구조를 갖추어야 합니다. 저는 정석적인 Google SRE 포스트모템 템플릿을 기준으로 삼겠습니다. 이 템플릿은 지정된 단일 소유자, 타임라인 (Timeline), 문서화된 근본 원인 (Root cause) 및 트리거 (Trigger), 탐지 방법, 복구 설명, 그리고 소유자와 상태가 포함된 조치 목록을 요구합니다. 이것은 관료주의가 아니라, 이 필드들이 없다면 '분석'이 아무런 해결책도 제시하지 못한다는 것을 의미하는 최소한의 필수 요소입니다.

저의 작업용 템플릿은 이를 제품 관리자 (Product Manager)의 과업에 맞춰 네 가지 열로 압축합니다: 장애 (Failure), 소유자 (Owner), 데이터 (Data), 복구 (Recovery). 두 가지 시나리오 각각에 대해 행을 채워 넣습니다. 만약 단 하나의 셀이라도 비어 있다면, 그 지도는 사용할 수 없습니다. 하지만 이것만으로도 이미 성과입니다. 사용자의 불만이 접수된 후가 아니라, 출시 전에 운영상의 공백을 찾아냈기 때문입니다.

주의할 점은, '소유자' 열이 벤더 팀의 이름이 아니라 권한을 가진 구체적인 개인을 의미한다는 것입니다. 모델 라우팅 (Model routing)이 다음 장애의 소유자를 자동으로 지정해주지는 않습니다. 바로 이 지점에서 지도가 끊어지는 경우가 가장 많습니다. 벤더는 모델의 작동은 책임지지만, 당신의 구체적인 대화 내용을 복구하는 것까지 책임지지는 않기 때문입니다.

Диагностический маршрут карты восстановления по шаблону постмортема Google SRE

업타임 (Uptime)이 약속하는 것과 약속하지 않는 것

보기 좋은 업타임 퍼센트는 연속성을 보장하는 것처럼 착각하기 쉽습니다. 이는 오류입니다. 2026년 7월 18일 기준 OpenAI 상태 페이지 (Status page)에 따르면, 2026년 4월~7월 동안의 집계된 업타임은 API의 경우 99.96%, ChatGPT는 99.85%, Codex는 99.98%입니다. 그리고 바로 이어서 OpenAI 스스로 다음과 같이 경고합니다: "individual customer availability may vary depending on their subscription tier as well as the specific model and API features in use" (개별 고객의 가용성은 구독 티어뿐만 아니라 사용 중인 특정 모델 및 API 기능에 따라 달라질 수 있습니다).

즉, 공개된 수치는 모든 요금제, 모델 및 오류 유형에 대한 평균을 의미하며, 귀하의 특정 봇에 대한 연속성을 보장하는 것이 아닙니다. 이를 사용자나 경영진에게 SLA (Service Level Agreement, 서비스 수준 협약)로 제시해서는 안 됩니다. 게다가 OpenAI의 표준 서비스 약관은 서비스가 "중단되지 않거나(uninterrupted), 정확하거나(accurate), 오류가 없을(error free)" 것이라는 보장을 명시적으로 제외하고 있습니다. 즉, 이 API를 사용하는 봇이 상속받게 될 기본적인 업타임(Uptime) 보장이나 오류율에 대한 보장은 표준 계약에 존재하지 않습니다.

원인에 대한 공개적인 분석도 드문 편입니다. OpenAI는 심각한 장애가 발생했을 때만 상세한 기술적 포스트모템 (Post-mortem)을 게시합니다. 예를 들어, 2023년 11월 8일에 발생한 대규모 장애 (ChatGPT 및 API 약 1시간 34분간 중단)는 라우팅 레이어 (Routing layer)의 메모리 할당 오류로 추적되었으며, 조치 사항과 후속 수정 사항 목록이 포함되었습니다. 2026년의 짧은 장애들에 대해서는 이러한 분석이 없습니다. 이는 모델의 경로를 중단 없는 서비스의 보장책으로 내세울 수 없음을 의미합니다. 만약 완성된 봇의 벤더가 바로 이 점을 보장으로 내세운다면, 그 체크리스트는 이미 실패한 것입니다.

Горизонтальные бары аптайма API, ChatGPT и Codex с дисклеймером о вариативности

대화 데이터는 어디에 있으며, 누가 이를 복구할 것인가

체크리스트의 "데이터" 열은 추상적인 개념이 아니라 소유권 및 추출에 관한 구체적인 문제입니다. OpenAI의 약관에 따르면 고객은 Input (입력값)과 모든 Output (출력값)에 대한 권리를 보유합니다. 즉, 모델과의 대화 내용은 OpenAI가 아닌 봇을 배포하는 회사에 귀속됩니다. 이는 복구 측면에서는 좋은 소식이지만, 귀하가 실제로 해당 데이터에 접근할 수 있을 때에만 해당되는 이야기입니다.

하지만 그것들이 물리적으로 어디에 위치하며 어떻게 추출할 수 있는지는 더 이상 기정사실이 아니라, 구성(Configuration)과 계약의 문제입니다. OpenAI의 공식 데이터 제어 문서 (OpenAI data control documentation)에 따르면, API의 입력(Input)과 출력(Output)은 기본적으로 오남용 모니터링 목적으로만 최대 30일 동안 저장되며, 제로 데이터 보관(Zero Data Retention, ZDR) 모드는 신청을 통해 승인을 받은 고객에게만 제공됩니다. 즉, "대화가 어디에 저장되며, 이를 복구하거나 추출할 수 있는가"라는 항목은 추측이 아닌 사실로 채워져야 합니다.

여기서 데이터 소스의 경계에 관한 중요한 주의 사항이 있습니다. 위에서 설명한 모든 내용은 OpenAI 자체의 인프라와 계약에 관한 것입니다. 만약 귀하의 완성된 봇이 API 상단에 구축된 제3자 플랫폼 빌더(Platform-builder)라면, 해당 플랫폼은 별도의 검증되지 않은 계층을 가집니다. 즉, 자체적인 사고 관리(Incident ownership), 자체적인 에스컬레이션(Escalation), 그리고 자체적인 대화 저장소를 가지고 있습니다. 이러한 조건들은 출시 전에 반드시 해당 벤더(Vendor)의 문서를 통해 재확인해야 합니다. OpenAI의 사실을 특정 리셀러(Reseller)에게 그대로 적용하는 것은 항상 귀하의 판단 사항일 뿐, 보장된 사실이 아닙니다.

봇의 이름은 바뀌어도, 사고 책임자는 바뀌지 않는다

제품명은 다양한 철자와 단어 순서로 수십 가지 방식으로 검색될 수 있지만, 복구 지도(Recovery map) 관점에서는 이것이 중요하지 않아야 합니다. 사용자가 "gpt 챗봇", "챗봇 gpt", "챗 gpt 봇" 또는 "gpt chat bot" 중 무엇을 입력하든, 이 모든 표기법 뒤에는 동일한 질문이 깔려 있습니다. "대화가 끊겼을 때 누가 책임을 지는가?"입니다. 철자와 단어 순서에 따라 검색어가 "chat gpt 챗봇", "챗봇 gpt" 또는 "gpt chat 봇"으로 변할 수는 있지만, 이러한 단어 순서가 사고 책임자(Incident owner)를 결정하지는 않습니다.

브랜드 명칭인 "chatgpt 챗봇" 또는 "챗봇 chatgpt", 그리고 더 일반적인 표현인 "chatgpt 기반 봇"은 내부에 어떤 모델이 탑재되어 있는지만을 나타냅니다. 마케팅용 포장 문구인 "chatgpt 신경망 봇" 또는 "신경망 봇 chat gpt", 그리고 "ai 챗봇 chatgpt"나 "ai 봇 chatgpt"와 같은 명칭들도 이러한 표현들 속에서 사고에 대한 책임은 여전히 모델 자체가 아니라 특정 회사의 특정 인물에게 있다는 사실을 바꾸지 않습니다.

chatgpt general bot, boot chat gpt bot 또는 chat al bot chat gpt 5와 같은 오타는 실제 입력에서 흔히 발생하는 일이지만, 그 이면에는 실질적인 질문이 자리 잡고 있습니다. 즉, 이러한 오타가 포함된 요청이 오타가 없는 요청과 동일한 지원 대기열(support queue)에 들어가는지, 아니면 채널 사이에서 유실되는지의 문제입니다.

사용자의 기대 측면에서의 표현들 — chat gpt를 사용하는 챗봇, chat gpt 같은 챗봇, 러시아어로 된 chatgpt 봇, 또는 chat gpt 온라인 챗봇 —은 보통 한 가지를 의미합니다. 답변이 러시아어로 제공되어야 하며 번역 오류가 없어야 한다는 것입니다. 이는 잘못된 답변 시나리오로 직결됩니다. 만약 봇이 언어를 혼동하거나 로컬라이제이션 (localization) 과정에서 의미를 왜곡한다면, 해당 답변을 검토하고 사용자에게 알리는 주체가 누구인지 명확하게 명시되어 있어야 합니다.

질의 내의 개별적인 수정어들은 검증 대상을 변화시킵니다. 예를 들어 'gpt 챗봇 18'은 연령 제한을 나타내며, 이 경우 복구 맵 (recovery map)에는 사용자를 모델의 무작위 답변에 방치하는 대신, 회사 내에서 해당 상황의 콘텐츠 정책을 담당하는 사람이 누구인지 명시되어 있어야 합니다.

하나의 시나리오, 다양한 채널 및 통합

동일한 임계 시나리오(critical scenario)가 서로 다른 채널에 존재할 수 있으며, 각 채널의 장애 책임자는 다를 수 있습니다. 가장 많은 변형이 나타나는 곳은 Telegram입니다. 질의 분석에 따르면 'chatgpt бот телеграм'과 'телеграм бот chatgpt', 'chat gpt телеграм бот'과 'gpt chat бот телеграм', 'чат gpt бот в телеграмме'와 'бот в телеграмме чат gpt' 사이의 의도 차이는 거의 없습니다. 이 모든 표현은 결국 동일한 제품인 메신저 Telegram의 봇으로 이어집니다. 이들은 단어의 순서나 자판 배열의 차이일 뿐 질의의 본질은 다르지 않으므로, 봇 토큰 (token)을 보유하고 웹훅 (webhook)을 설정하는 Telegram 채널 소유자는 사용자가 이름을 어떻게 입력했는지에 따라 바뀌어서는 안 됩니다.

chat gpt телеграм бот, телеграм бот chat gpt, chatgpt телеграм бот, gpt 챗봇 теле그램 및 chat gpt를 이용한 телеграм бот의 경우도 마찬가지입니다. 동일한 텔레그램 봇(Telegram bot)을 다르게 표기한다고 해서 새로운 장애 소유자(incident owner)가 생성되지는 않습니다. 반면, 텔레그램의 chat gpt бот, 텔레그램의 gpt 챗봇, 텔레그램의 chat gpt бот은 채널 연결 자체에 대한 요청이며, 이 경우에는 봇이 갑자기 채팅에서 응답을 중단할 경우 누가 토큰 (token)을 재발급할 것인지 미리 알고 있는 것이 중요합니다.