오늘의 발견

어떤 비효율을 발견했고, 어떻게 해결했는가?

오늘은 러너스 하이 첫날로 평소 업무 과정에서 무심코 지나가고 있던 비효율적인 업무들에 대해 돌아보는 시간을 가져봤다.

업무 비효율 브레인스토밍

1. 다소 주먹구구식으로 느껴지는 CS 처리과정

• 우리 팀에서 관리하고 있는 데이터의 정합성이 맞지 않아 CS가 들어오는 경우가 빈번하다.
• 최근에는 데이터 수집이 되지 않았음에도 인지하지 못한 경우도 있었다.
• 경험상 느껴지는 문제로는 이상치 탐지, 데이터 애그리거트 미지정, 데이터 통합 파이프라인의 부재가 생각났다.

2. 알림톡 발송 모니터링

• 발송되어야할 알림톡의 발송 현황을 체크해야한다.
• 급한대로 임의로 조치해둔 방식으로는 slack reminder로 조치해둔 상태.
• 1시간 단위 배치로 slack webhook을 쏘고 있긴 하지만 노이즈가 심해 정확히 파악이 어려운 상태.
• jenkins 스케줄링과 알림발송 시점 문서, batch 코드. 3개의 관리포인트가 있다. 발송 시점을 한군데로 모아 해당 알림톡이 정상적으로 발송되었는지 모니터링해야한다는 생각이 들었다.

3. 코드리뷰

• 급한 프로덕트 개발 환경에서 코드리뷰를 생략하는 경우가 많고, 테스트가 충분히 갖춰져있지 않은 상황임.
• 테스트를 잘 작성하면 좋겠지만 테스트 프레임워크를 구축하기에는 레거시를 보완하기 모호하다.
• 테스트를 잘 작성하려고 하면 좋은 구조는 가져갈 수 있겠지만 ROI가 명확하지 않다. (비즈니스 임팩트를 챙기기에는 아쉽게 여겨지는 부분)
• 하다못해 코드리뷰라도 빠르게 해보면 좋지 않을까? slack에 ai 코드리뷰 요청기능을 빠르게 구현하자.

4. 노이즈성 에러로그

• 에러로그가 뜨면 노이즈성 에러로그가 종종 보인다. Exception 핸들링이 잘 되지 않아 발생하는 간단한 에러 혹은 다른 사람의 작업내용으로 인한 노이즈성 에러가 등장하기도한다.
• 이에 명확한 에러 파악에 방해를 받고있다.
• 빠르게 해결하기 위해 비동기로 pull request 생성까지 초안을 만들어볼 수는 없을까?

가장 임팩트를 낼 수 있는 문제는?

위 4가지 모두 일하면서 불편함을 느낀 부분인건 맞지만 3, 4번은 4시간정도 투자하면 바이브코딩으로도 충분히 해결 가능해보인다. (슬랙 봇 간단히 개발) 해결했을 때 동료들의 만족도같은 정성적인 성과는 나올지언정 명확히 개선되는 지점은 잘 모르겠다.

1, 2번 문제를 해결했을때 다음과 같은 임팩트를 기대해볼 수 있을것으로 예상한다.

1. CS 업무 효율화 (ROI 관점)

• 운영 비용 절감: 매번 DB를 조회하며 소모되는 엔지니어링 리소스를 '0'에 가깝게 줄여, 본질적인 제품 개발에 집중할 수 있는 환경을 만든다.
• 선제적 대응 체계 구축: 고객이 문의를 넣어야만 문제를 인지하는 수동적(Reactive) 대응에서, 시스템이 먼저 이상을 감지하고 알리는 방식으로 대응한다.

2. 알림톡 시스템 안정성 (Stability 관점)

• Blind Time 제거: 1시간 단위 배치에 의존하던 모니터링 주기를 실시간(혹은 분 단위)으로 단축하여, 장애 인지 시간을 획기적으로 줄인다.
• 휴먼 에러 방지: 문서와 실제 설정의 불일치로 인한 배포 불안감을 해소하고, '코드'가 곧 '문서'가 되는 구조를 만들어 유지보수성을 높인다.

Root Cause 정의하기

1번 문제(CS 비효율)의 경우 다음과 같은 흐름으로 Root Cause를 정리했다.

1. 현상: 데이터 누락이나 정합성 오류 발생 시, 개발자가 직접 DB에 접속해 원천 데이터와 서비스 데이터를 일일이 대조해야 원인을 알 수 있다.
2. 직접 원인: 수집기(Collector)가 데이터를 적재하는 기능에만 집중되어 있고, 적재된 데이터가 '정상인지' 판단하는 검증 로직(Validation)과 이상 탐지(Anomaly Detection) 체계가 부재하다.
3. Root Cause: Observability) 확보를 위한 엔지니어링 부재
   • 시스템 설계 시 기능 구현(Feature)에만 초점을 맞추고, 운영 단계에서 필수적인 모니터링이나 어드민 도구(Internal Tool) 개발을 부채로 남겨두었다. 이로 인해 데이터의 건강 상태(Health check)를 확인하는 비용이 온전히 사람의 몫으로 전가되고 있다.

2번 문제(알림톡 발송)의 경우도 Observability와 직결되는것으로 보인다.

1. 현상: 알림톡 발송이 잘 되고 있는지 확인하려면 1시간 뒤에 오는 배치 알림을 기다려야 하고, 템플릿 변경 시마다 매번 테스트 코드를 수동으로 수정해서 검증하고 있다. 설정 정보(문서, 젠킨스, 코드)가 서로 달라 헷갈린다.
2. 직접 원인: 보안 제약(내부망 DB 외부 노출 불가)을 이유로 실시간 모니터링 시스템 구축을 미뤘고, 배포/검증 프로세스를 자동화된 파이프라인(CI/CD)으로 구축하지 않고 '사람의 수작업'에 의존하고 있다.
3. Root Cause: "운영 프로세스의 코드화(Everything as Code) 부재"
   • 반복되는 검증 작업과 인프라 설정(스케줄링)을 코드로 추상화하지 않아, 변경 사항이 생길 때마다 사람이 직접 개입해야 하는 구조다. 또한, 보안 제약 속에서도 가시성을 확보할 기술적 대안(블랙박스 모니터링 등)을 찾지 않고, 불편함을 감수하는 수동적 운영 환경이 고착화되었다고 생각한다.

측정 지표 (목표) 선정하기

1. CS 업무 효율화

• 장애 탐지 소요 시간 (MTTD): 고객 신고 접수 시점(수 시간~수 일) → 시스템 자동 알림 발송(10분 이내)
• 문제 원인 파악 시간 (MTTR): 건당 평균 30분(수동 쿼리 조회) → 건당 5분 이내(이상치 알림 메시지 확인)

2. 알림톡 모니터링

• 장애 인지 지연 시간 (Latency): 최대 60분(기존 배치 주기) → 5분 이내(블랙박스 모니터링 주기)
• 설정 불일치 건수 (Sync Error): 문서 vs Jenkins 설정 불일치 건수 0건 유지 (Config as Code 도입)