98%로는 한참 모자랍니다 — 안정성 숫자에 속지 않는 법

"98%면 훌륭한 거 아냐?"라고 생각했다면

우리가 개발하다 보면 이런 숫자를 자주 만나요. "테스트 커버리지 98%", "가동률(uptime) 98%", "성공률 98%". 딱 들으면 "오 거의 완벽한데?" 싶잖아요. 그런데 이 98%라는 숫자가 생각보다 훨씬 초라하다는 이야기를 해볼게요.

핵심은 이거예요. 우리는 100%에 가까운 숫자를 보면 무의식적으로 "거의 다 됐다"고 느끼는데, 실제로 중요한 건 남은 2%가 무엇이냐거든요.

2%를 시간으로 환산해보면

가동률 얘기부터 해볼게요. 서버가 1년 내내 98% 켜져 있다는 건 멋져 보이지만, 뒤집어 계산해보면 2%는 꺼져 있다는 뜻이에요. 1년은 365일이니까 2%면 약 7.3일이에요. 서비스가 한 해에 일주일 넘게 죽어 있는 거죠. 하루로 치면 약 29분씩 매일 먹통인 셈이고요. 여러분이 쓰는 은행 앱이 매일 30분씩 안 열린다고 생각하면… 절대 "훌륭한 98%"가 아니죠?

그래서 업계에서 안정성을 말할 때 "나인(nine)이 몇 개냐"를 따지는 거예요. 99%는 나인 두 개, 99.9%는 세 개, 99.99%는 네 개. 나인 하나 늘 때마다 허용되는 다운타임(downtime, 서비스 중단 시간)이 10분의 1로 줄어요. 99.99%(포 나인)면 1년에 겨우 52분이에요. 이 차이가 그냥 소수점 장난 같지만 실제 운영에선 천지 차이예요.

곱해지면 더 무서워진다

더 무서운 건 이 확률들이 '곱해질' 때예요. 요즘 서비스는 마이크로서비스라고 해서, 작은 서비스 여러 개가 서로 호출하면서 하나의 기능을 완성하잖아요. 만약 서비스 A, B, C, D, E 다섯 개가 다 98% 성공률이라고 해봐요. 사용자 요청 하나가 이 다섯 개를 다 거쳐야 한다면 전체 성공률은 얼마일까요?

0.98을 다섯 번 곱하면 약 0.904, 즉 90%로 뚝 떨어져요. 각각은 98%인데 합치니까 10번 중 1번은 실패하는 거예요. 서비스가 열 개, 스무 개로 늘어나면 이 숫자는 더 처참해지고요. 그래서 개별 컴포넌트의 안정성이 "이 정도면 됐지"가 절대 아닌 거예요.

남은 2%가 사실 가장 어렵다

또 하나 중요한 통찰이 있어요. 보통 프로젝트에서 앞의 98%는 쉽게 채워지는데, 마지막 2%가 전체 노력의 절반을 잡아먹는다는 거예요. 정상적인 경우(happy path, 모든 게 예상대로 흘러가는 흐름)는 처리하기 쉽지만, 남은 2%는 온갖 예외 상황, 네트워크 끊김, 이상한 입력값, 동시성 문제 같은 진짜 어려운 것들이 몰려 있거든요. 그래서 "98% 완성"이라는 말은 사실 "제일 어려운 절반이 남았다"는 뜻일 때가 많아요.

한국 개발자에게

이건 SLA(서비스 수준 협약)를 협의하거나 모니터링 대시보드를 볼 때 바로 써먹을 수 있는 관점이에요. 숫자를 볼 때 "98%가 있다"가 아니라 "2%가 없다, 그 2%가 시간으로·건수로 얼마인가"를 먼저 계산해보는 습관을 들이세요. 특히 결제, 로그인처럼 실패가 곧 매출·신뢰 손실인 기능은 나인 하나가 아쉬워요.

그리고 팀에서 "거의 다 됐어요, 98%요"라는 진척 보고를 들으면, 남은 게 진짜 쉬운 2%인지 아니면 제일 어려운 2%인지 꼭 확인하세요. 일정 산정이 완전히 달라지거든요.

마무리

퍼센트 뒤에 숨은 절댓값을 계산하는 순간, 98%는 더 이상 안심할 숫자가 아니에요. 여러분 서비스의 핵심 기능은 지금 나인이 몇 개인가요? 그리고 하나 더 늘리려면 무엇이 필요할까요?