서버 오류 기록을 '요청 한 건' 단위로 세는 일일 분석 기준 정리

아래 사례는 실제 참가자의 업무를 적용한 프로젝트 결과를 바탕으로 합니다.
단, 업무 데이터 등의 보안을 위하여 이미지는 AI를 활용하여 제작하였습니다.

오류 줄만 골라내면 될 줄 알았다

전산팀은 사내 업무시스템을 돌리는 서버 두 대를 관리합니다.

두 서버는 하루 동안 일어난 일을 한 줄씩 기록 파일(로그)로 남깁니다.

지금은 사용자가 전화나 메일로 "오류가 났다"고 알려 올 때만 그 시각 근처의 기록을 찾아봅니다.

사전 설문에 적힌 어려움은 이랬습니다.

"하루 74만 줄이라 사람이 눈으로 훑는 것이 불가능합니다. 파일 하나가 100MB여서 편집기로 여는 데도 시간이 걸립니다."

저희도 처음엔 간단하게 봤습니다.

기록 가운데 'ERROR(오류)' 표시가 붙은 줄만 뽑아, 업무 안내 문구와 진짜 고장으로 나누면 된다고 생각했습니다.

그런데 8월 25일 하루치 기록 두 파일을 처음부터 끝까지 맞대 보니, 나누기 전에 세는 단위부터 정해야 했습니다.

고장 하나가 두 줄로 남는다

프로그램이 멈추면 기록에는 먼저 '예외 기록'이 남습니다.

예외 기록은 어느 코드에서 무엇 때문에 멈췄는지 수십 줄에 걸쳐 적은 묶음입니다.

그리고 바로 뒤에, 사용자 화면에 돌려준 응답이 한 줄 더 남습니다.

두 줄 모두 오류 표시가 붙어 있습니다.

83건의 예외 가운데 80건은 사용자에게 "시스템 오류입니다"라고 응답했습니다.

나머지 3건은 "중복 오류입니다"라고 응답했습니다.

문구만 보면 '이미 있는 자료입니다'라는 업무 안내 같지만, 실제로는 데이터베이스 저장이 막혀 멈춘 고장이었습니다.

문구로 줄을 나누면 고장 83건이 업무 안내 쪽에 한 번 더 섞여 들어갑니다.

설문에는 "ERROR 606건 중 513건은 업무 규칙이 정상 작동한 기록"이라고 적혀 있었습니다.

그 513줄을 다시 열어 보니, 83줄은 고장 난 요청이 사용자에게 돌려준 응답이었습니다.

한 건 안에서 같은 원인 코드가 다섯 번

예외 기록 한 묶음 안에는 같은 데이터베이스 오류 번호가 여러 번 되풀이됩니다.

살펴본 묶음에서는 같은 번호가 다섯 번씩 나왔습니다.

번호로 검색한 건수를 그대로 쓰면 고장 규모가 몇 배로 부풀려집니다.

그래서 세는 단위를 '줄'이 아니라 '요청 한 건'으로 바꿨습니다.

예외 기록 한 묶음과 그 뒤의 응답 한 줄을 1건으로 묶고, 묶음 맨 끝에 적힌 진짜 원인 한 줄만 원인으로 셉니다.

저희가 하루치 기록으로 돌려 본 순서

1. 넣은 것 — 서버 두 대의 8월 25일 기록 파일을 그대로 넣었습니다. 편집기로 열지 않고 파일째 읽게 했습니다.

2. 요청 — "오류 표시 줄을 요청 한 건 단위로 묶어 줘. 예외 기록과 바로 뒤의 응답 줄은 1건으로 세고, 분류 합계가 원본 오류 줄 수와 맞는지 확인해 줘."

3. 나온 것 — 606줄이 업무 안내 430줄, 고장 83건(예외 기록 83줄과 응답 83줄), 오류 화면 넘김처럼 프로그램 틀이 남긴 부가 기록 10줄로 나뉜 분류표. 고장 83건은 원인 8종, 발생 위치 17곳으로 다시 묶였습니다.

4. 확인 — 세 칸의 합이 606줄과 맞는지 저희가 다시 셌습니다. "중복 오류입니다"처럼 문구와 실제가 다른 줄은 원본을 열어 사람이 판단할 목록으로 따로 뺐습니다.

원인을 묶어 보니 가장 많은 것은 비어 있는 값을 그대로 비교하다 멈춘 경우(32건)였습니다.

다음은 입력값이 저장 칸 길이보다 길어 저장이 막힌 경우(26건)였습니다.

한 기능의 같은 코드 줄에서만 15건이 났습니다.

메일 주소 여러 개를 쌍반점(;)으로 이어 넣어 발송이 멈춘 기록도 있었습니다.

이런 실패는 받는 사람도 보낸 사람도 모른 채 지나갑니다.

Claude에게 맡기기 전에 정한 네 가지

1. 세는 단위는 요청 한 건 — 예외 기록과 그 뒤 응답 줄은 묶어서 1건입니다.

2. 문구가 아니라 예외 기록 유무로 분류 — 응답 문구는 참고만 합니다.

3. 합계는 늘 원본과 대조 — 분류 합계가 원본 오류 줄 수와 다르면 결과를 쓰지 않습니다.

4. 외부로 보내는 사본은 가림 처리 — 메일 주소, 데이터베이스의 표·칸 이름은 바꾼 사본만 외주 업체에 넘깁니다.

다음 날 아침 기록 파일이 쌓이면

매일 오는 보고서는 결국 읽히지 않는다

매일 아침 같은 모양의 보고서가 쌓이면, 사람은 어느 날부터 열어 보지 않게 됩니다.

그래서 매일 분석의 마지막 칸은 '전날에 없던 원인'과 '갑자기 늘어난 원인'만 알려 주는 일입니다.

신고 전화가 오기 전에, 어제 새로 생긴 고장 하나를 먼저 아는 아침. 하루치 기록 파일을 가져오시면 세는 단위부터 저희와 함께 정합니다.

본 프로젝트는 솔트룩스x헬로월드랩스의 공동 개발 및 운영 교육 과정을 통해 진행되었습니다.