개발자의 마지막 보루: 네트워크 지옥에서 빛나는 로깅 이야기

자율주행 로봇이 활약하는 물류 현장. 이곳은 겉으로는 첨단을 달리는 듯 보이지만, 개발자에게는 예측 불가능한 네트워크 환경과 싸워야 하는 전쟁터입니다. "로봇은 잘 움직였다고 하는데, 왜 우리는 문제를 재현할 수 없을까?" 이 질문은 현장에서 흔히 마주하는 답답함이자, '재현 안 되는 버그'의 시작점입니다. 로그는 부족하고, 고객의 이야기를 들어도 핵심 맥락을 놓치기 일쑤죠. 이 글은 이런 현장 속에서 저희가 어떻게 문제의 실마리를 찾아내고, 운영의 안정성을 확보했는지에 대한 이야기입니다.

---

1. 답답한 현실: "무엇이 문제인지 아무도 모른다"

서비스 초반, 몇 대 안 되는 로봇을 운영할 때도 문제가 생기면 그야말로 '맨땅에 헤딩'이었습니다. 현장에서 "로봇이 이상했어요"라는 제보가 들어와도, 그게 시스템 문제인지, 로봇이 의도대로 움직인 것인지, 아니면 사람이 실수한 것인지 파악하기가 너무 어려웠습니다.

가장 흔한 시나리오는 이런 식입니다.
"로봇이 작업을 끝냈는데 엉뚱한 곳으로 갔어요!"

이런 제보를 받으면, 개발자는 고객에게 끝없이 질문을 던질 수밖에 없습니다. "어떤 작업을 했나요? 로봇은 어디에 있었죠? 어디로 가야 했는데 어디로 갔다는 건가요? 언제 그랬나요?" 질문은 꼬리에 꼬리를 물고, 고객은 반복되는 질문에 지쳐갑니다. 이 과정 자체가 서비스 신뢰도를 갉아먹는다는 사실을 깨달았습니다.

그래서 저희는 생각했습니다. "우리에게 정말 필요한 정보는 우리가 직접 챙기자." 그리고 로봇 클라이언트에 로그 시스템을 직접 구축하기로 결정했습니다.

물론 Sentry 같은 훌륭한 에러 수집 서비스들이 있습니다. 하지만 특정 서비스에 얽매이지 않고, 우리가 원하는 모든 데이터를 자유롭게 수집하고 싶었습니다. 특히, 데이터 전송량이 많아질 때 발생하는 비용 문제도 무시할 수 없었기에, 처음부터 우리 환경에 최적화된 시스템을 만드는 것이 중요하다고 판단했습니다.

---

2. 해결책: 네트워크 걱정 없이 '모든 것'을 기록하다

가장 큰 난관은 불안정한 네트워크에서도 로그를 놓치지 않고 수집하는 것이었습니다. 웹 환경에서 로그는 양이 방대할 수 있기에, 단순한 localStorage로는 한계가 명확했습니다. 저희의 선택은 IndexedDB였습니다. 브라우저 내에서 대용량 데이터를 저장할 수 있는 강력한 기능이죠. 복잡한 IndexedDB를 좀 더 쉽게 다루기 위해 localForage 라이브러리를 사용했습니다. localStorage처럼 쓰기 쉽지만, 비동기 방식으로 동작해 앱 성능에 영향을 주지 않는다는 점이 아주 매력적이었습니다.

① 로그를 '똑똑하게' 담는 그릇 만들기

로그 데이터를 어떻게 저장할지가 첫 번째 고민이었습니다. 저희는 UTC 기준으로 하루에 하나씩 테이블을 만들고, 해당 날짜의 모든 로그를 여기에 쌓는 방식을 택했습니다. 각 로그는 발생 시각(timestamp)을 키로 삼아 저장했고, 어떤 로봇이, 어떤 작업을, 언제, 어디서 했는지 등 현장 상황을 파악하는 데 필요한 모든 맥락 정보를 담았습니다.

② 디스크 공간은 소중하니까: 로그 수명 주기 관리

로봇의 디스크 공간은 무한하지 않습니다. 오래된 로그를 효과적으로 관리하는 정책이 필요했죠. IndexedDB는 꽤 많은 공간을 사용할 수 있지만(Chrome 기준 디스크의 최대 80%), 무한정 쌓아둘 수는 없습니다. 저희는 테스트를 통해 하루에 생성되는 로그량을 추정했고, 최대 3일치 로그를 보관하기로 결정했습니다. 3일이 지난 로그 테이블은 자동으로 삭제되고, 만약 3일치 로그의 총량이 특정 기준을 넘어서면 가장 오래된 로그부터 지워지도록 하여 디스크 공간을 효율적으로 사용했습니다.

③ 현장으로 가지 않고도 로그를 확인하다: 원격 모니터링

로그는 잘 쌓였지만, 문제가 생길 때마다 현장에 가서 로그를 직접 뽑아올 수는 없는 노릇이었습니다. 그래서 원격에서 로그를 확인하고 관리할 방법을 고안했습니다. 초기에는 Slack을 통해 사용자가 로그 보내기 버튼을 누르면 로봇이 스스로 로그를 전송해주는 기능을 구현했습니다. 현장 담당자가 문제가 발생했을 때 즉시 로그를 받아볼 수 있게 된 거죠. 이후 서버팀과 협력하여, OpenSearch를 통해 모든 로봇의 로그 데이터를 주기적으로 백업하고 중앙에서 모니터링하고 분석할 수 있는 시스템을 구축했습니다. 이제는 사무실에서도 현장의 상황을 상세히 파악할 수 있게 되었습니다.

④ 무엇을 기록할 것인가: 로그 수집 전략의 진화

어떤 로그를 수집할지도 중요한 부분이었습니다. 처음에는 가장 문제가 많았던 네트워크 API 호출과 관련된 데이터(request, response)를 중점적으로 수집했습니다. API 통신 과정에서 어떤 문제가 발생했는지 파악하는 것이 중요했기 때문입니다. 이 부분만 잘 봐도 사용자의 행동 흐름과 서버와의 통신 문제를 상당 부분 파악할 수 있었습니다.

점차적으로 앱에서 발생하는 에러 로그, 사용자가 어떤 순서로 작업을 진행했는지 알려주는 맥락적 이벤트 로그, 그리고 다양한 통신부의 상태 정보 등으로 수집 범위를 확장했습니다. 이렇게 함으로써 현장의 상황을 더욱 포괄적이고 입체적으로 이해할 수 있게 되었습니다.

---

3. 얻게 된 인사이트: "이젠 문제가 두렵지 않다"

이러한 로컬 로깅 시스템을 구축하고 나니, 현장 운영에 있어 놀라운 변화가 찾아왔습니다.

• 문제 해결의 속도 향상: 고객에게 일일이 물어볼 필요 없이, OpenSearch에서 로그만 확인해도 문제의 원인을 파악할 수 있게 되었습니다. "아, 사용자가 이렇게 사용하셨구나!" 혹은 "이 통신 부분에서 잘못된 데이터가 들어왔네!"와 같이 명확한 분석이 가능해졌습니다.
• 휴먼 에러의 명확한 증명: 때로는 시스템 문제가 아닌, 사용자의 조작 미숙으로 발생하는 문제들도 있습니다. 로그는 이런 경우에도 객관적인 증거를 제공하여, 불필요한 논쟁 없이 문제 해결에 집중할 수 있게 했습니다.
• 운영 안정성의 기반 마련: 네트워크 환경에 관계없이 중요한 데이터를 놓치지 않고 기록할 수 있게 되면서, 서비스 운영 전반의 안정성이 크게 향상되었습니다.

운영 환경에서 로그는 단순한 기록을 넘어, 문제를 진단하고 해결하는 데 필수적인 '생명줄'과 같습니다. 앞으로는 이렇게 쌓인 방대한 로그 데이터를 AI에게 분석을 맡겨보면 어떨까 하는 새로운 도전을 고민하고 있습니다. AI의 도움을 받아 문제 상황을 더욱 빠르게 파악하고 대응하여, 로봇과 사람이 함께하는 현장이 더욱 매끄럽게 돌아갈 수 있도록 기여하고 싶습니다.