한줄 요약
서버 에러는 누구나 겪는다. 문제는 에러가 났을 때 클라이언트가 아무것도 모른 채 개발사만 기다리는 구조다.
본문
서버 에러란 사용자가 앱이나 웹서비스에 접근하지 못하는 상태를 말한다. 원인은 트래픽 폭주, 설정 오류, 인프라 문제 등 다양하지만, 클라이언트 입장에서 공통적으로 겪는 문제가 하나 있다. 에러가 터졌을 때 "지금 뭐가 문제예요?"라는 질문조차 제대로 못 한다는 것이다.
개발을 외주로 맡긴 스타트업 대표라면, 이 글을 읽고 나서 최소한 대화가 되는 수준은 돼야 한다.
왜 서버 에러가 났을 때 클라이언트가 당황하는가?
외주 개발을 맡기면 결과물(앱, 웹)만 받고 인프라 구조는 넘겨받지 못하는 경우가 많다. 어떤 서버를 쓰는지, CDN이 붙어 있는지, 로드밸런서는 있는지 모른다. 그러니 에러가 나면 개발사에 전화해서 "안 돼요"라는 말밖에 못 한다.
문제는 그 순간 개발사가 즉각 대응하지 못하거나, 심하면 연락이 닿지 않는 경우다. 에이전시를 운영하면서 느낀 건, 이런 상황에서 손해를 보는 건 항상 클라이언트 쪽이었다. 서비스가 멈추면 매출이 멈춘다.
서버 에러의 원인, 세 가지로만 기억해라
복잡하게 생각할 필요 없다. 서버 에러의 원인은 크게 세 가지다.
첫째, 트래픽 초과. 서버가 감당할 수 있는 요청 수를 넘어서면 응답을 거부한다. 이벤트나 바이럴이 터졌을 때 가장 흔하게 발생한다.
둘째, 설정 오류. 배포 과정에서 환경변수나 네트워크 설정이 잘못 반영되면 정상적으로 뜨던 서비스가 갑자기 막힌다. 주로 업데이트 직후에 발생한다.
셋째, 외부 서비스 장애. CDN, DNS, 클라우드 제공사 자체의 문제일 수 있다. 이 경우는 개발사가 고칠 수 있는 영역이 아니다. 기다리거나 우회 방법을 써야 한다.
이 세 가지를 알면 개발사에 "배포 직후에 생긴 건지, 트래픽이 몰렸는지, 클라우드 쪽 공지는 확인했는지"를 물어볼 수 있다.
외주 개발사에 계약 전에 반드시 확인해야 할 것들
에러가 터진 후에 확인하면 늦다. 계약 단계에서 아래 항목을 짚어야 한다.
모니터링 도구가 있는가? 서버 상태를 실시간으로 보는 도구가 있어야 에러 발생 시 즉각 감지된다. 없으면 사용자 신고가 들어와야 알게 되는 구조다.
장애 대응 SLA가 있는가? 에러 발생 후 몇 분 안에 확인하고, 몇 시간 안에 복구한다는 기준이 계약서에 명시돼 있어야 한다. "최대한 빠르게"는 기준이 아니다.
인프라 접근 권한이 클라이언트에게도 있는가? 개발사가 바뀌거나 관계가 틀어졌을 때를 대비해서, 서버 콘솔이나 클라우드 계정에 클라이언트도 접근할 수 있어야 한다. 이걸 거부하는 개발사라면 다시 생각해봐야 한다.
