모니터링과 자동화를 통한 서비스 개선 사례 정리

1. 모니터링과 자동화가 중요한 이유

서비스를 운영하고 있으신가요? 그렇다면 어떻게 서비스를 모니터링 하고 있으신가요?

서비스 초기에 저는 수동적인 모니터링을 했었습니다.

문제가 발생하면 서비스의 자원 사용량, 로그를 확인하고 원인을 파악하는 방식이었습니다.

서비스가 간단하고 규모가 작을 때에는 이런 방식이 효율적이라 느꼈습니다.

문제 발생 빈도가 낮고, 원인 분석도 제가 직접하는 편이 비교적 빨랐기 때문입니다.  

 

하지만 서비스가 복잡해지고 규모가 커질수록 문제 발생 빈도는 증가하고, 원인 분석에 걸리는 시간도 늘어나게 되더라고요.

문제가 발생할 때마다 원인 분석과 조치에 시간을 쏟아야 한다면, 개발 속도는 자연히 느려질 수밖에 없습니다.

저는 (1)보다 능동적인 모니터링과 (2) 업무 자동화를 통해 개발 생산성을 높일 뿐만 아니라 고객의 불만이 커지기 전에 선제적으로 문제를 파악하여 효율적인 개선 방안을 마련할 수 있을 거라 생각했습니다.  

그리고 나름 주장을 뒷받침하기 위한 근거로 사례들을 준비해봤습니다.
실제로 운영하는 서비스에 도입한 능동적인 모니터링과 자동화 사례들을 살펴보면서 모니터링과 자동화가 서비스 개선에 얼마나 도움을 줬는지 알아보시죠!

 

2. 사례

2.1. 로봇 주행 이슈 자동 리포트

로봇 서비스를 운영하다 보면 '로봇이 안 움직여요' 라는 고객 문의를 정말 많이 전달 받게 됩니다.
서비스 버그 때문에 로봇이 안 움직이는 것이면 버그를 고치기만 하면 문제가 재발하지 않습니다.

 

하지만 현장의 장애물, 로봇 이슈 등으로 안 움직이는 경우도 상당히 많은데
이런 경우에는 서비스 로그를 모두 분석하고 이상이 없는 것을 확인하고, 로봇 데이터 로그까지 분석한 이후에야 현장 문제라는 것을 파악할 수 있습니다.

• 특히 문제 시점을 정확히 전달 받지 못하면 막대한 양의 로그를 분석해야 하기 때문에 시간도 많이 소요됩니다.

고객에게 불편함을 주면서 제품 개발의 속도를 깎아 먹는 현장 문제를 어떻게 해소할 수 있을까요?

첫번째 방법: 버그 예방하기
실패...

로봇이 안 움직이는 문제의 원인은 시스템 전반적으로 퍼져 있기 때문에 버그를 완벽히 예방하는 것은 불가능합니다.

두번째 방법: 문제 대응 가능 인원 늘리기
실패...

문제 분석 방법을 정리하여 가이드를 만든다면 대응 가능한 인원을 늘릴 수 있습니다. 하지만 여러 부서가 서로 다른 기술을 이용하여 로봇과 서비스를 개발하고 있는데 이를 공통된 언어로 정리하는 것은 비용이 너무나 크기에 시작하지도 못했습니다.

이제 어떡하죠? 개개인의 문제 대응 속도가 빨라지기만을 기다려야 할까요? ㅜㅠ

 

천 리 길도 한 걸음부터

저희는 '문제 발생 시점이라도 정확히, 자동으로 수집하자' 를 목표로 잡았습니다.
문제 발생 시점을 정확히 알 수 있다면 분석해야 하는 로그의 양을 좁힐 수 있어서 대응 속도를 개선할 수 있습니다.
또한, 고객이 인지하지 못한 문제도 분석하고 개선하여 만족도를 높일 수 있습니다.

로봇의 좌표가 정해진 시간동안 변화가 없을 시 사내 메신저로 알림을 보내도록 기능을 개발했습니다.

그리고 이 기능을 통해서 현장의 네트워크 지연 문제, 로봇 SW 문제를 신속하게 발견하고 공유하여 빠른 대응을 할 수 있었습니다.

2.2. 오전, 오후 서비스 상태 자동 리포트

트위니 서비스의 경우, 고객은 로봇의 작업 시작 버튼을 누르면 로봇이 주행을 시작해서 작업이 진행되기를 원합니다.
버튼을 눌러도 로봇이 움직이지 않고 작업이 진행되지 않는다면 큰 불만으로 이어집니다.

트위니 직원이 실수했건 고객이 실수했건 누구의 잘못인지는 크게 중요하지 않습니다...!

이런 문제를 해소하기 위해서 저희들은 서비스 운영 모니터링을 시작했습니다.
매일 오전 8시 30분, 오후 6시 30분에 로봇이 사용되고 있는 각 현장에 문제가 없는지 로봇 상태는 괜찮은지 확인하는 것입니다.

봐야 할 내용들은 정해져 있어서 그렇게 어려운 작업은 아닙니다.
하지만 로봇이 사용되고 있는 현장이 여럿 있어서 생각보다 시간이 오래 걸린다는 문제가 있었습니다.

단순한 반복 작업으로 판단했고, crontab과 서비스들의 API를 이용하여 오전, 오후 모니터링을 슬랙에서 한번에 할 수 있도록 만들었습니다.

이를 통해서 반복적이고 한눈에 확인하기 어려운 서비스 모니터링을 일부 개선할 수 있었습니다.

 

2.3. OpenSearch를 이용한 서비스 패닉 자동 리포트

로봇 관제 서비스는 무중단배포와 서비스 패닉이 발생하더라도 빠른 자동 복구를 지원합니다.

그런데 서비스 패닉 자동 복구 기능에 버그가 발생해서 개발자가 조치하기 전까지는 서비스가 그대로 멈춰버리는 문제가 발생했습니다.

패닉이 발생하면 개발자가 조치하기 전까지는 서버에 등록된 모든 로봇이 움직이지 않게 되는 것입니다.

당시에는 패닉의 원인을 정확히 찾지 못했기에 저희가 취할 수 있는 선택은 2가지로 보였습니다.
1. 일단 무시한다
2. 개발자 1명이 패닉 발생 여부를 계속해서 확인한다

1번을 선택할 시 패닉이 발생했을 때 서비스 다운 타임이 길어진다는 단점이 있고,
2번을 선택할 시 개발자 1명을 온전히 할당해야 하기에 작업이 지연될 수 있다는 단점이 있습니다.

2가지 방법 모두 치명적인 단점을 가지고 있지만 서비스 다운 타임이 보다 치명적이라고 판단했습니다.
저라도 패닉 발생 여부를 계속해서 봐야 하나 고민을 하다가 OpenSearch를 이용해서 문제를 해소하는 방법을 찾았습니다.

OpenSearch의 Alerting 플러그인을 이용하면 서비스 패닉이 발생했을 때 슬랙에 메시지를 보내도록 구성할 수 있는 것이었습니다!

 

추가 개발, 추가 리소스 투입 없이 클릭 몇번의 간단한 설정만으로 패닉 이슈를 대응할 수 있었습니다.
+++지금은 패닉 자동 복구 기능의 버그가 수정되었습니다! ㅎㅎ

 

2.4. 시각화를 통한 로봇 주행 지연 사례 모니터링

트위니 오더피킹 솔루션의 경우, 로봇들의 경로를 효율적으로 계획해주는 관제 알고리즘도 중요하지만 로봇 자체의 주행 퀄리티도 매우 중요합니다.

만약 특정 로봇의 주행이 예상한 시간보다 오래 걸리거나 문제가 발생할 경우

경로가 비슷한 다른 로봇들에게도 영향을 주기 때문에 선제적인 주행 지연 사례 분석이 필요하죠.

다행인 것은 로봇들의 주행 데이터는 서버 상에 보관되고 있기 때문에
로봇들의 명령 수행 기록을 담고 있는 데이터를 분석하는 것으로 주행이 오래 걸렸던 지점을 찾을 수 있다는 것이죠.

하지만 단순 데이터 분석은 전달력이 너무 부족합니다.
"A, B, C 지점에서 로봇이 많이 버벅였어요!" 라고 내용을 공유하면 과연 잘 전달될까요?
전달된다고 하더라도 각각의 좌표를 환경지도에서 찾아가는 번거로운 과정을 거쳐야 합니다 ㅜ

저희는 로봇의 주행 지연을 시각화 시켜서 전달력을 높여봤습니다.

이를 통해서 제품 개발 부서와 자율주행 개발 부서 간의 협업도 어느 정도 끌어올릴 수 있었습니다.

 

2.5. LLM을 이용한 현장 이슈 자동 정리

현장에서 발생하는 이슈들을 대응하면서 인지했던 문제가 하나 있습니다.
바로 현장이 어떻게 운영되고 있는지 알기 어렵다는 것입니다.

 

현장이 어떻게 운영되고 있는지 추적하는 방법은 쉽습니다.
현장 별로 담당자를 정해서 현장 별로 어떤 작업이 진행되었고, 어떤 이슈가 있었는지 정리하는 것입니다.

사실 방법은 명확하고 쉽지만 리소스가 부족한 것이 스타트업의 공통적인 문제겠죠...
다들 업무도 많은데 누가 이 작업을 진행해야 하죠...?

저는 LLM에서 가능성을 찾았습니다. 메신저를 통해 주고 받은 내용들을 분석해서 이슈를 정리하는 것이죠!

• 처음 이 업무를 시작했을 때 엄청 간단할줄 알았지만 프롬프트 엔지니어링의 어려움을 알 수 있었습니다ㅋㅋㅋ...

 

3. 이 글을 읽고 여러분이 얻어가셨으면 하는 것들

회사에서 일하다 보면, 종종 자신이 맡은 역할과 권한을 스스로 제한하게 되는 경우가 있습니다.
"이건 내 일이 아닌데?" "이건 다른 팀에서 해야 하는 일 아닌가?" 같은 생각들 말이죠.

저는 이런 생각이 오히려 우리의 성장을 방해할 수도 있다고 생각합니다.

서비스가 가진 문제나 고객이 겪는 불편함, 그리고 우리가 마주하는 어려움에 더 관심을 가져보는 건 어떨까요? 관심을 가지다 보면, 이전에는 보이지 않던 새로운 시각과 기회가 열릴 것입니다.

그리고 나서, 더 나아갈 방법을 고민해보세요. 자신의 업무 범위를 넘어서도 해결책을 찾아보려는 자세로요.
그러면 서비스에 대한 시각이 달라지고, 일의 재미도 자연스럽게 따라오게 된다고 생각합니다.

 

보안 상의 이유로 실제 사례들을 보여드리지 못해서 아쉽습니다.

그럼에도 불구하고 긴 글 읽어주셔서 감사합니다!