개발사가 찾지 못한 원인을 찾았습니다

한 달에 다섯 번 멈추는데 원인이 특정되지 않던 서비스였습니다. 멈출 때마다 저희가 먼저 되살리고, 원인을 찾아 개발사에 넘겼습니다. 새벽 0시 7분에 시작된 중단도 20분 만에 복구했습니다.

이전월 5회

이후0회

5.6배 더 몰려도 버팁니다

장애 분석 · 부하 시험수정 전후 같은 조건으로 부하 시험 · 2026-01

비슷한 장애인지 물어보기 비슷한 상황인지 물어보기

같은 화면에 사람이 한꺼번에 몰리는 상황을 만들어 시험했습니다. 수정 전에는 요청 130건이 몰리자 서버가 내려갔고, 수정 후에는 724건이 몰려도 오류 없이 처리했습니다. 같은 조건으로 잰 값입니다.

01 멈추면 저희가 먼저 켭니다 새벽 0시 7분에 멈춘 서비스를 20분 만에 되살렸습니다.
02 개발사가 못 찾던 원인을 한 달에 다섯 번 멈추는 동안 원인이 특정되지 않았습니다.
03 찾은 것은 넘깁니다 분석 자료를 개발사에 전달했습니다. 고치는 일은 개발사 몫입니다.

THE PROBLEM

어떤 상황이었나

한 달 동안 다섯 번, 누적 78분이 멈췄습니다. 간격은 5일에서 2일로 좁혀지고 있었고, 개발사는 원인을 특정하지 못한 상태였습니다.

흔한 결론 데이터가 많아서

요청이 몰렸거나 데이터가 커서 터졌다고 보면 답은 증설입니다. 이번엔 그 답이 틀렸습니다.

실제 원인 처리 방식

두 번의 중단에서 데이터량이 52만 배 달랐는데 실패 지점은 같았습니다. 양이 아니라 처리 방식이 원인이라는 뜻입니다.

양이 원인이었다면 52만 배 차이에서 결과가 달랐어야 합니다. 같았다는 사실이 증설을 배제했습니다.

WHAT WE DID

무엇을 했나

1
멈추면 먼저 되살립니다
밤이든 새벽이든 저희가 복구합니다. 원인을 찾는 것은 그다음입니다 — 새벽 0시 7분 중단은 20분 만에 되살렸습니다.
2
가능성을 하나씩 지웁니다
데이터가 많아서인지, 접속이 몰려서인지, 외부 연동 탓인지 차례로 지웠습니다. 남은 것이 원인입니다.
3
찾은 것은 개발사에 넘깁니다
멈춘 시각·기록·분석을 정리해 전달했습니다. 고친 뒤에는 같은 조건으로 다시 재서 확인했습니다.

멈출 때마다 저희가 먼저 되살리고, 그다음 원인을 찾았습니다. 고객 시스템은 바꾸지 않았습니다.

중단 규모

한 달에 5번, 합쳐서 78분 멈췄습니다. 간격이 5일 → 2일 → 3일로 좁혀지던 중이었습니다

누가 무엇을 맡았나

멈춘 서비스를 되살리는 일은 저희가, 코드를 고치는 일은 고객사의 개발사가 맡았습니다. 문서로 미리 나눠 둔 역할입니다

새벽에도 대응했습니다

다섯 번 중 네 번이 업무시간 밖이었고, 자정을 넘긴 0시 7분 중단도 20분 만에 되살렸습니다. 그날 안에 같은 절차를 자동으로 돌리는 장치까지 만들었습니다

원인을 어떻게 좁혔나

두 번의 중단에서 오간 데이터 양이 157MB와 0.0003MB로 약 52만 배 달랐는데, 멈춘 지점은 똑같았습니다. 양이 원인이었다면 결과가 달랐어야 하므로 증설은 답이 아니었습니다

고친 뒤 확인

한꺼번에 몰리는 요청을 130건에서 724건까지 견디게 됐고, 1분에 처리하는 양은 15건에서 139건이 됐습니다. 서버 부담(최대 CPU)은 68.6%에서 12.28%로 내려갔습니다

남은 것

중단과는 무관하지만 프로그램이 남기는 경고 기록은 관찰 기간 내내 계속 쌓였습니다. 정리 대상으로 남겨 두었습니다

GOOD FIT

우리 회사도 해당될까요?

해당되는 항목을 눌러보세요. 많이 켜질수록 이 사례와 비슷한 상황입니다.

0/4 항목을 눌러 확인해 보세요.

선택한 내용 그대로 문의하기 →

비슷한 장애인지 물어보기 다른 사례 보기

맞지 않는 경우도 있습니다 — 먼저 말씀드립니다

효과가 제한적인 경우

원인 규명과 수정 주체가 다르면 반영까지 시간이 걸립니다 — 이번에도 수정은 개발사 일정에 달려 있었습니다
로그 보존 기간이 짧아 장애 시점 기록이 이미 지워진 환경에서는 같은 방식이 통하지 않습니다
재현이 되지 않고 기록도 없는 단발성 장애

이런 경우엔 권하지 않습니다

저희가 애플리케이션 코드를 고쳐 드리는 계약이 아닙니다 — 원인을 짚는 데까지가 이 사례의 범위입니다.
증설로 임시로 버티는 것이 목적이라면 이 방식은 오히려 느립니다.
장애 기록이 남아 있지 않으면 원인을 특정할 수 없습니다.

범위: 읽기 전용 분석. 고객 시스템에 변경을 가하지 않는 범위에서 수행했습니다.
고객사 공수: 애플리케이션 로그와 배포 이력은 개발사·고객사에서 받아야 했습니다. 저희만으로 끝나는 분석이 아닙니다.

이 사례가 실증하는 약속 — 읽기 전용 원칙

2026-07-20 게시 · 2026-07-20 검토 · 전 사례 익명(계약 조건) · 원인 규명에 걸리는 시간과 개선 폭은 남아 있는 기록의 양에 따라 크게 달라지며 같은 결과를 보장하지 않습니다. 수정은 고객사의 개발사가 수행했습니다.

한 팀에게, 끝까지 맡겨 보세요

개선하고 싶은 업무를 한 줄만 남겨주세요. 무엇을 어떻게 만들 수 있는지 먼저 정리해 알려드립니다.

상담 신청 카카오톡 채널 텔레그램 상담