담당자 대신 로그에게 묻기 시작한 이유

안녕하세요. 펠즈 Product Engineer 구안득입니다.

저희 차량 시스템은 오프라인 기반입니다. 수의사가 진료를 진행하면 사진을 포함한 데이터가 기기에 먼저 저장되고, 진료가 끝나고 앱을 닫는 시점에 (또는 수동으로) 서버로 전송됩니다. 이 동기화가 실패하면 원인 파악은 항상 사후에 이루어질 수밖에 없었습니다. 매니저에게 전화해 "그때 무슨 작업을 하고 계셨나요?"라고 물어봐야 했죠. 문제는, 대부분의 경우 매니저 본인도 원인을 모른다는 점이었습니다.

여기서 일반적인 로깅은 두 가지 이유로 무력합니다. 첫째, 로그는 장애가 발생한 바로 그 기기에만 남아 있는데, 정작 그 순간엔 전송할 네트워크가 없습니다. 둘째, 로그가 서버까지 도달하더라도 그건 서로 연결되지 않은 개별 error/warning 문자열일 뿐, 특정 진료 건 하나의 처음부터 끝까지를 하나의 이야기로 엮어주지 않습니다. 저희가 항상 알고 싶었던 질문은 하나였습니다. "해당 반려동물의, 해당 진료 건에서, 정확히 어떤 순서로 무슨 일이 일어났는가?"

필요했던 건 더 많은 로그가 아닌 것

이 질문에 답하려면 로그를 메시지의 나열이 아니라 다르게 봐야 했습니다. 하나의 진료 건을, 시작부터 끝까지 이어지는 하나의 흐름으로요.

사진 촬영 → 압축 → 서버 상태 확인 → 업로드 요청 → 전송 → 완료 확인.

이 흐름 어딘가에서 끊기면, 정확히 어느 단계에서 그리고 그 직전에 무슨 일이 있었는지를 볼 수 있어야 했습니다.

나중에 알게 된 사실인데, 이 접근 방식은 이미 이름이 있었습니다. 프로세스 마이닝(process mining). 로그를 개별 이벤트가 아니라 케이스(case) 단위의 이벤트 시퀀스로 보고, 그 시퀀스들을 모아 실제 프로세스를 재구성하는 방법론입니다. 저희가 하려던 건 정확히 이거였습니다 - 다만 처음엔 그렇게 부를 줄 몰랐을 뿐입니다.

무엇을 바꿨는가

가장 먼저 바꾼 건 로그의 형식이었습니다. 기존의 자연어 로그 위에 event=이벤트명 key=value 형태의 구조를 얹었습니다. 사람이 문장을 읽고 해석하는 대신, 이벤트 체인을 자동으로 재구성할 수 있게 하기 위해서였습니다.

두 번째로 필요했던 건 식별자였습니다. 앱 실행마다 세션 ID를, 동기화 시도마다 별도의 ID를 부여하고, 이 ID가 파이프라인의 모든 단계를 관통하며 특정 진료 건과 연결되도록 했습니다. 이게 없으면 흩어진 로그 줄들을 하나의 케이스로 묶을 방법이 없었습니다.

가장 오래 고민한 문제는 세 번째였습니다. 로그를 서버까지 어떻게 가져올 것인가. 네트워크가 없는 것 자체가 문제의 원인인데, 로그를 별도로 전송하는 방식은 애초에 통하지 않았습니다. 그래서 로그를 진료 데이터와 다른 경로로 보내지 않기로 했습니다. 최근 며칠치 로그를 데이터와 같은 압축 파일에 담아, 데이터가 도착하면 로그도 함께 도착하도록 만들었습니다. 네트워크가 없던 순간의 기록까지 포함해서요.

마지막으로, "인터넷이 있다"는 것도 하나가 아니라 두 개로 나눠 기록하기 시작했습니다. OS가 네트워크 인터페이스를 인식하는지, 그리고 실제로 저희 서버가 응답하는지. 이 둘을 따로 보지 않으면 "테더링 문제였는지 서버가 죽어 있었는지"를 구분할 방법이 없었습니다.