AI 기능의 신뢰성은 정확도가 아니라 실패 설계에서 나옵니다
AI 기능을 서비스에 붙이고 있는 백엔드 엔지니어나 프로덕트 오너를 위한 글입니다. 이 글을 읽고 나면 모델 정확도를 한 자릿수 더 끌어올리는 일보다, 모델이 틀렸거나 늦거나 아예 응답하지 못했을 때 사용자 화면에 무엇을 띄울지 먼저 결정하는 일이 왜 신뢰성의 핵심인지 납득하게 됩니다.
결론부터 말하겠습니다. AI 시스템의 신뢰성은 모델의 벤치마크 점수가 아니라 실패를 어떻게 처리하도록 설계했는지에서 나옵니다. 정확도를 높이는 작업은 끝이 없고, 아무리 높여도 프로덕션에서는 여전히 틀린 답이 나옵니다. 반면 실패했을 때 무엇을 보여줄지 미리 정해 두는 작업은 유한하고, 한 번 제대로 해 두면 모델이 어떤 이유로 무너지든 시스템 전체는 계속 서비스를 유지할 수 있습니다. 아래에서는 이 주장을 실패의 성격이 왜 다른지부터 시작해, 실제로 무엇을 만들어야 하는지까지 순서대로 논증합니다.
글의 핵심 개념을 형상화했습니다.
전통 소프트웨어의 실패는 이진적이지만 AI의 실패는 연속적입니다
일반 함수는 값을 반환하거나 예외를 던집니다. 둘 중 하나만 일어나므로 코드는 지금 상태가 성공인지 실패인지 정확히 압니다. 예외가 나면 스택 트레이스가 어디서 무엇이 잘못됐는지도 알려줍니다. 이 명확한 경계 위에서 지금까지의 소프트웨어 신뢰성 공학이 발전해 왔습니다.
모델을 호출하는 코드에서는 이 전제가 무너집니다. 모델은 예외를 던지지 않고도 완전히 틀린 답을 내놓을 수 있습니다. 응답 시간은 입력 길이와 서버 부하에 따라 몇 배씩 흔들리고, 같은 입력을 두 번 넣어도 다른 결과가 나옵니다. 응답이 왔다는 사실만으로는 그 응답이 쓸 만한지 전혀 보장되지 않습니다. 형식은 지켰지만 내용이 사실과 다를 수도 있고, 질문과 무관한 답을 그럴듯한 어조로 내놓을 수도 있습니다.
이 연속성 때문에 성공과 실패 사이에 넓은 회색지대가 생깁니다. 이 회색지대를 처리하지 못하는 시스템은 실패를 감춘 채 사용자에게 그럴듯하지만 틀린 결과를 그대로 넘깁니다. 사용자 입장에서는 시스템이 조용히 거짓말을 하는 셈입니다. 그래서 AI 기능을 만드는 엔지니어의 첫 번째 책임은 정답률을 높이는 것이 아니라, 답이 틀렸거나 늦거나 없을 때 시스템이 어떻게 움직일지를 미리 설계하는 것입니다.
“실패하면 사용자는 무엇을 보게 되는가”라는 질문에서 설계를 시작해야 합니다
이 질문을 설계의 출발점으로 삼으면 얻는 것이 큽니다. 먼저 실패를 사후에 처리할 대상이 아니라 정상 경로의 일부로 다루게 됩니다. 정상 응답을 만드는 코드를 짤 때부터 실패했을 때의 코드도 함께 짜야 한다는 규율이 생깁니다.
또한 이 질문은 팀 내부의 논의를 구체적으로 만듭니다. “모델이 실패하면 어떻게 하나요”라는 추상적인 질문에는 누구도 명확히 답하기 어렵지만, “요약이 실패하면 사용자는 빈 화면을 보나요, 아니면 원문의 첫 문장을 보나요”라는 질문에는 즉시 판단이 갑니다. 구체적인 화면 상태를 상상하게 만드는 질문이야말로 실제로 코드로 옮겨질 수 있는 설계를 이끌어냅니다.
마지막으로 이 질문은 우선순위를 정하는 데도 쓰입니다. 모든 AI 기능에 똑같이 정교한 실패 대응을 준비할 필요는 없습니다. 자원과 시간은 한정돼 있으니, 없으면 서비스의 핵심 가치 자체가 무너지는 기능과 없어도 크게 불편하지 않은 기능을 먼저 나누어야 합니다. 이 등급을 나누는 작업은 개발팀 판단만으로 끝내지 말고 실제 사용자 흐름을 아는 사람과 함께 검토하는 편이 안전합니다. 개발자에게는 사소해 보이는 기능이 실제로는 사용자의 핵심 작업에 깊이 얽혀 있는 경우가 드물지 않기 때문입니다.
표시와 동작과 정확성, 세 레벨을 단계적으로 낮추며 서비스를 지킵니다
그레이스풀 디그레이션은 기능 전체를 끄는 대신 품질을 단계적으로 낮추면서 서비스를 계속 제공하는 원칙입니다. 이 원칙을 표시 레벨, 동작 레벨, 정확성 레벨 세 가지로 나누어 적용하면 관리하기 쉬워집니다.
표시 레벨은 화면에 무엇을 보여줄지에 관한 것으로, 구현하기 가장 쉽고 가장 먼저 손대야 할 영역입니다. AI가 생성한 요약이 실패하면 요약란을 비워두는 대신 원문의 첫 몇 문장을 발췌해서 보여주거나, 최소한 요약 기능이 잠시 쉬고 있다는 상태를 명확히 알려주면 됩니다. 동작 레벨은 사용자가 할 수 있는 행동의 범위에 관한 것입니다. AI가 자동으로 채워주던 추천 입력값이 사라지더라도 사용자가 직접 입력하는 경로는 항상 열려 있어야 합니다. 정확성 레벨은 결과의 품질 자체를 낮추더라도 결과를 아예 없애지는 않는 선택입니다. 최신 모델 대신 더 단순한 모델이나 규칙 기반 로직으로 대체해서라도, 사용자가 완전히 빈손으로 돌아가지 않게 만듭니다.
세 레벨을 미리 나누어 두면 장애가 실제로 터졌을 때 팀이 즉흥적으로 판단할 필요가 없어집니다. 어느 레벨까지 낮출지는 이미 정해져 있고, 코드도 그 경로를 이미 갖추고 있기 때문입니다.
죽어가는 서버에 부하를 더 얹지 않는 법, 서킷 브레이커
모델 호출이 실패했을 때 가장 먼저 떠오르는 대응은 재시도입니다. 네트워크가 순간적으로 끊기거나 서버가 잠깐 바빴을 뿐이라면 재시도만으로 충분합니다. 문제는 모델 서버 자체가 과부하 상태이거나 완전히 죽어 있을 때 생깁니다. 이런 상황에서 재시도는 죽어가는 서버에 요청을 더 얹는 꼴이 되어 회복을 오히려 늦춥니다. 게다가 요청을 보낸 쪽도 응답을 기다리는 동안 자원을 붙잡고 있게 되므로, 모델 서버 하나의 장애가 그 서버를 호출하는 모든 서비스로 번져나갑니다.
서킷 브레이커는 이 확산을 끊는 장치입니다. 실패가 반복되면 아예 호출을 시도조차 하지 않고 즉시 대체 경로로 넘어가도록 만들어서, 죽어가는 서버에 더는 부하를 주지 않으면서 동시에 호출하는 쪽도 무한정 기다리지 않게 합니다. 이 장치는 닫힘, 열림, 반열림 세 가지 상태를 오가며 동작합니다.
| 상태 | 동작 | 전환 조건 |
|---|---|---|
| 닫힘 | 모든 호출이 정상적으로 모델 서버에 전달됩니다 | 실패율이 기준을 넘으면 열림으로 전환합니다 |
| 열림 | 호출을 시도하지 않고 즉시 대체 경로로 처리합니다 | 일정 시간이 지나면 반열림으로 전환합니다 |
| 반열림 | 소수의 요청만 시험 삼아 모델 서버로 보냅니다 | 성공하면 닫힘으로, 실패하면 다시 열림으로 돌아갑니다 |
이 순환 구조 덕분에 서킷 브레이커는 사람이 개입하지 않아도 장애가 발생했을 때 자동으로 격리하고, 회복되면 정상 경로를 스스로 되찾습니다. 다만 서킷을 열지 말지 판단할 때 오류율 하나만 보면 놓치는 장애 유형이 있습니다. 모델이 오류를 던지지는 않지만 응답이 평소보다 열 배 느려지는 경우입니다. 이런 상황은 오류율 지표만으로는 잡히지 않으므로, 지연 시간 분포도 함께 관찰 대상에 넣어야 합니다.
폴백은 하나가 아니라 사다리여야 합니다
폴백을 단 하나의 대체 수단으로만 준비하면 그 대체 수단마저 실패했을 때 다시 막다른 골목에 몰립니다. 그래서 사용자 영향이 큰 기능일수록 여러 단계로 이어지는 폴백 사다리를 준비하는 것이 안전합니다.
가장 먼저 시도할 것은 같은 모델에 더 짧은 시간제한을 두고 한 번 더 요청하는 방법입니다. 순간적인 지연이었다면 이 단계에서 대부분 해결됩니다. 그다음은 더 가볍고 빠른 대체 모델로 전환하는 방법입니다. 품질은 다소 낮아지지만 여전히 모델이 생성한 결과를 사용자에게 제공할 수 있습니다. 그마저도 실패하면 규칙 기반 로직으로 넘어갑니다. 미리 정의한 조건문이나 통계로 계산 가능한 결과를 대신 내놓는 방식입니다. 마지막 단계는 가장 최근에 성공했던 결과를 캐시에서 꺼내 보여주는 것입니다. 실시간성은 떨어지지만 사용자가 완전히 빈 화면을 마주하는 것보다는 낫습니다.
이 사다리의 핵심은 순서 그 자체가 아니라, 각 단계가 이전 단계보다 확실히 더 단순하고 더 실패하기 어려운 경로여야 한다는 점입니다. 규칙 기반 로직이나 캐시는 모델 서버가 완전히 죽어도 살아남습니다. 사다리의 맨 아래에는 반드시 모델에 의존하지 않는 경로가 있어야 하는 이유입니다.
배포 없이 즉시 되돌릴 수 있어야 합니다, 피처 플래그와 자동 롤백
일반적인 소프트웨어 기능은 문제가 생기면 코드를 고치고 다시 배포해서 해결합니다. AI 기능에서는 이 흐름이 너무 느립니다. 모델 서버에 이상이 생겼거나, 특정 프롬프트가 유해한 답을 유도하고 있거나, 새로 올린 모델 버전의 품질이 예상보다 낮다는 사실이 밝혀졌을 때, 코드를 고치고 빌드하고 배포하는 절차를 다 거치는 동안 사용자는 계속 나쁜 경험을 겪습니다.
피처 플래그는 이 절차를 건너뛰고 운영 중인 시스템의 동작을 즉시 바꾸는 장치입니다. 모델 버전, 프롬프트 내용, 호출 여부 자체를 코드 밖의 설정값으로 빼두면 그 값만 바꿔서 즉시 반영할 수 있습니다. 새 모델이나 새 프롬프트를 도입할 때는 전체 트래픽에 한 번에 적용하지 않고, 극소수의 비율로 시작해서 문제가 없다는 것이 확인되면 점차 비율을 늘려가는 방식이 표준입니다. 이때 같은 사용자는 관찰 기간 동안 계속 같은 버전을 받도록 고정해야 합니다. 매번 무작위로 다른 버전을 받으면 결과의 일관성이 깨지고 새 버전의 실제 효과도 측정하기 어려워집니다.
여기서 놓치기 쉬운 부분은 자동 롤백입니다. 서서히 트래픽 비율을 늘려가는 동안 사람이 매 순간 지표를 지켜보고 있을 수는 없습니다. 새 모델을 적용받은 그룹의 오류율이 기존 모델을 적용받은 그룹보다 뚜렷하게 높아지면, 사람이 알아채기 전에 시스템이 스스로 적용 비율을 0으로 되돌리고 담당자에게 알림을 보내야 합니다. 사람이 지켜보는 시간과 장애가 퍼지는 속도는 애초에 같은 단위가 아닙니다.
장애가 터지기 전에 각본을 미리 써 두어야 합니다
장애가 실제로 터진 순간에 등급을 처음 정하려고 하면 판단이 늦어지고 대응도 늦어집니다. 등급은 장애가 나기 전에 미리 정의해 두어야 합니다. 코어 기능이 완전히 멈추거나 잘못된 결과가 대량으로 노출되는 상황은 즉시 대응 인력을 소집해야 하는 최고 등급이고, 중요 기능이 저하됐지만 폴백으로 서비스가 유지되는 상황은 정해진 시간 안에 담당자가 확인하면 되는 중간 등급이며, 보조 기능에 문제가 있거나 폴백 호출 빈도가 평소보다 높아진 정도는 정기 점검 시점에 함께 검토해도 되는 낮은 등급입니다. 등급을 나누는 기준에는 오류율 수치 하나가 아니라 영향을 받는 사용자 규모와 노출되는 결과의 위험성, 지속 시간이 함께 들어가야 합니다.
장애 대응 자체는 감지, 격리, 완화, 복구, 사후 분석이라는 다섯 단계로 정리하면 놓치는 부분이 줄어듭니다. 감지는 지표나 알림으로 문제를 처음 인지하는 단계로, 앞서 다룬 서킷 브레이커와 자동 롤백이 이 단계의 상당 부분을 대신해 줍니다. 격리는 문제가 다른 정상 기능으로 번지지 않도록 경계를 긋는 단계로, 서킷을 강제로 열거나 특정 피처 플래그를 비활성화하는 조치가 여기 해당합니다. 완화는 사용자가 느끼는 피해를 줄이는 단계로, 폴백 사다리를 강제로 하위 단계로 내리거나 문제가 된 모델 버전을 이전 버전으로 되돌립니다. 복구는 트래픽을 단계적으로 원래 상태로 되돌리는 단계이고, 사후 분석은 무엇이 왜 일어났고 재발을 막으려면 무엇을 바꿔야 하는지 정리하는 단계입니다. 이 다섯 단계가 이미 문서로 정리돼 있으면, 장애가 터진 순간 팀은 무엇을 할지 새로 논의하는 대신 이미 정해진 각본을 따라가기만 하면 됩니다.
지금까지 살펴본 그레이스풀 디그레이션, 서킷 브레이커, 폴백 사다리, 피처 플래그, 장애 대응 등급은 서로 다른 다섯 가지 기법처럼 보이지만 사실은 하나의 질문에 대한 답입니다. 실패했을 때 사용자는 무엇을 보게 되는가. 이 질문에 미리 답해 둔 시스템만이 모델이 어떤 이유로 무너지든 사용자에게는 조용히 낮아진 품질을 보여줄 뿐, 무너진 화면을 보여주지 않습니다. 모델의 정확도는 계속 올라갈 것이고 그래야 마땅하지만, 그 정확도가 100퍼센트에 도달하는 날은 오지 않습니다. 신뢰할 수 있는 AI 시스템을 만드는 사람은 그 사실을 받아들이고, 정확도 대신 실패의 모양을 설계하는 사람입니다. 각 장의 나머지 실무 체크리스트와 코드 수준의 구현 예시는 전자책 전문에서 이어집니다.
챕터 삽화
