“마감까지 30분. 그런데 AI가 응답하지 않는다면?”
실제 장애 상황이 아니라, 오늘 자신의 업무에 대입해 볼 질문이다. 보고서 초안을 쓰지 못하는 정도에 그칠까. 아니면 자료 검토와 고객 답변, 최종 승인까지 줄줄이 멈출까.
생성형 AI는 글쓰기와 요약, 자료 분류, 고객 응대 등 다양한 업무에 쓰인다. 편리함이 커질수록 함께 살펴야 할 문제도 있다. 특정 서비스에 접속하지 못했을 때, 일을 계속할 수 있느냐는 것이다.
핵심은 AI 사용을 줄이자는 데 있지 않다. 도구가 멈춰도 업무의 통제권은 사람에게 남아 있어야 한다는 데 있다.
서비스의 복구와 내 업무의 정상화는 다르다
AI 서비스의 운영 상태를 확인하는 가장 직접적인 경로는 운영사의 공식 상태 페이지다. OpenAI는 이곳에서 서비스별 운영 현황과 장애 이력, 대응 상황을 안내한다.
다만 상태 페이지의 지표와 개별 사용자의 경험은 구분해야 한다. OpenAI도 가용성 지표가 여러 요금제와 모델, 오류 유형을 합산한 수치이며, 이용 조건에 따라 개별 고객의 가용성은 달라질 수 있다고 설명한다.
이 차이는 업무 현장에서 중요하다. 서비스가 정상화되더라도 작성하지 못한 보고서와 답변을 기다리는 고객, 지연된 승인 절차까지 저절로 해결되는 것은 아니기 때문이다.
같은 30분의 중단도 누군가에게는 잠깐의 불편이지만, 납품 직전인 프리랜서에게는 일정 차질이 될 수 있다. 고객 응대를 자동화한 소규모 사업자라면 밀린 문의를 처리하는 추가 노동이 생길 수 있다. 이는 특정 장애의 피해 통계가 아니라, 업무 구조에 따라 발생할 수 있는 영향이다.
따라서 따져야 할 것은 단순한 접속 중단 시간만이 아니다. 어느 단계가 멈추고, 그 지연이 어디까지 번지는지가 더 실질적인 점검 대상이다.
효율을 얻는 동안 새로운 병목을 만들지는 않았나
AI 도입의 경제적 효과를 볼 때는 작업 속도뿐 아니라 중단과 복구에 필요한 비용도 함께 살펴야 한다.
예를 들어 초안 작성은 빨라졌지만, 자료와 수정 지시가 특정 대화창에만 쌓인다면 어떨까. 서비스에 접근하지 못하거나 담당자가 자리를 비웠을 때, 다른 사람이 작업을 이어받기 어려워질 수 있다. 도구가 시간을 아껴주는 동시에 새로운 병목을 만드는 셈이다.
특히 한 사람이 기획과 작성, 고객 응대까지 맡는 조직에서는 이런 부담이 개인에게 집중되기 쉽다. 여기서 필요한 것은 담당자의 순발력에 기대는 방식이 아니라, 누구나 따라갈 수 있는 최소한의 업무 절차다.
관리자는 생산성과 납기를, 실무자는 업무 연속성과 추가 노동을, 고객은 응답의 정확성과 일관성을 중요하게 볼 수 있다. 이 관점들을 함께 놓고 보면 AI 활용 능력의 기준도 달라진다. 결과물을 빨리 만드는 능력에 더해, 오류를 검토하고 중단에 대응하며 사람이 업무를 이어받게 하는 능력까지 포함해야 한다.
첫째, 중요한 중간 결과를 대화창 밖에 남겨라
가장 먼저 확인할 것은 자료의 위치다. 핵심 초안과 사실 확인 내용, 수정 이유, 최종 판단 기준이 AI 대화창에만 남아 있지는 않은가.
업무를 이어가는 데 필요한 내용은 조직이 승인한 문서 저장소에 정리하는 편이 좋다. 완성본만 저장하기보다 다음 담당자가 이해할 수 있는 맥락도 함께 남겨야 한다.
- 어떤 자료를 근거로 작성했는가.
- 아직 확인하지 못한 내용은 무엇인가.
- 누가 어떤 기준으로 최종 승인하는가.
대화 기록 내보내기는 보조 수단이 될 수 있지만, 장애가 발생한 뒤에야 자료를 꺼내려 해서는 대응이 늦을 수 있다. 중요한 작업은 평소 별도 문서로 관리하는 것이 안전하다.
단, 백업을 이유로 민감한 정보를 개인 계정이나 승인받지 않은 저장소에 옮겨서는 안 된다. 업무 연속성과 정보보호는 함께 설계해야 한다.
둘째, 모든 기능이 아니라 ‘최소 업무’를 지켜라
AI가 멈췄을 때 평소와 같은 속도와 품질을 모두 유지하려 하면 대응이 복잡해진다. 먼저 구분할 것은 반드시 계속해야 하는 일과 잠시 미뤄도 되는 일이다.
고객 응대라면 접수 확인과 긴급 문의 분류를 우선할 수 있다. 보고서 작성이라면 정해진 기본 틀에 확인된 사실부터 기록할 수 있다. 중요한 판단은 AI의 답변을 기다리기보다 책임자에게 넘기는 절차가 필요하다.
실행 방법은 간단하다. 업무 하나를 골라 30분 동안 AI 없이 진행해 보는 것이다. 이때 막힌 이유를 기록하면 된다. 자료가 없어서인지, 양식이 없어서인지, 판단 권한이 불분명해서인지 구분해 보자.
이 점검의 목적은 사람과 AI의 속도를 겨루는 데 있지 않다. 중단 상황에서 필요한 자료와 권한, 연락 체계가 갖춰져 있는지 확인하는 데 있다.
셋째, 대체 AI의 이름보다 의존 구조를 확인하라
다른 AI 서비스를 준비하는 것도 대응 방법이다. 다만 앱이나 브랜드가 다르다는 이유만으로 독립적인 대안이라고 단정할 수는 없다.
기반 모델이나 외부 서비스, 인증 체계를 공유한다면 같은 문제의 영향을 받을 가능성이 있다. 업무상 필요한 경우에는 대체 서비스의 기술적 의존 관계와 계약 조건까지 확인해야 한다.
보안도 별개의 점검 항목이다. OpenAI의 기업용 데이터 안내처럼 사업자가 공개한 자료를 확인하되, 실제 적용 조건은 이용 제품과 계약, 조직의 내부 규정에 맞춰 살펴야 한다. 다른 서비스로 옮길 때도 입력 정보의 보관·활용 조건을 새로 확인해야 한다.
결국 대체 수단은 ‘다른 AI 하나’보다 넓어야 한다. 승인된 문서 도구, 기본 서식, 수동 처리 절차, 담당자 연락망을 함께 준비하는 편이 현실적이다.
좋은 백업은 사람이 이어받을 수 있는 업무다
특정 장애의 발생일과 지속 시간, 피해 규모가 확인되지 않았다면 이를 근거로 AI 서비스 전반의 신뢰성이 무너졌다고 말할 수는 없다. 그러나 중단에 대비하는 데 대규모 피해 사례가 먼저 필요한 것도 아니다.
자동화가 잘될수록 사람은 과정을 덜 들여다보기 쉽다. 그래서 더 중요해지는 것이 판단 기준과 기록이다. 무엇을 근거로 결정했고, 어디까지 확인했으며, 다음에는 누가 책임지는지가 남아 있어야 도구를 바꿔도 일을 이어갈 수 있다.
좋은 도구는 일을 빠르게 만들고, 좋은 업무 설계는 멈춘 뒤에도 다시 움직이게 한다. 오늘 반복 업무 하나를 골라 ‘AI 없이 30분 이어가기’를 시험해 보자. 다음 장애 앞에서 우리를 지켜줄 것은 새로고침 버튼일까, 이미 준비해 둔 다음 절차일까.
){kind=small}
){kind=small}
){kind=small}
){kind=small}
