운영 자동화로 반복 업무를 줄인 기록
들어가기
운영팀은 매일 관리자 페이지에서 거래 내역 조회, 정산 상태 점검, 리포트 생성 같은 반복 업무를 처리하고 있었다. 기능은 있었지만, 운영 비용을 기준으로 설계된 시스템은 아니었다.
- 자주 사용하는 조회 페이지 로딩 시간 15초 이상
- 단순 상태 변경과 정산 확인을 매번 수동 처리
- 장애 알림이 하나의 채널로 몰려 중요한 신호를 놓침
이 구조에서는 운영팀이 "무엇을 판단할지"보다 "시스템을 기다리는 시간"에 더 많은 에너지를 쓰게 된다. 이 글에서는 이 문제를 어떻게 정의했고, 어떤 선택이 운영팀의 시간을 실제로 줄였는지 순서대로 정리한다.
2. 문제를 어떻게 정의했는가
처음에는 요청 단위로 접근했다.
"이 페이지 좀 빠르게 해주세요." "이 버튼 하나만 추가해 주세요."
하지만 그렇게 대응할수록 비슷한 요청이 반복된다는 점이 더 분명하게 보였다.
구조적으로 보면 문제는 명확했다.
- 운영 업무는 대부분 루틴 작업
- 시스템은 이를 전혀 자동화하지 않음
- 성능 병목과 알림 설계가 운영 리듬을 방해
결국 운영팀의 시간을 시스템이 소비하고 있었다.
그래서 문제를 다음과 같이 재정의했다.
"사람이 매일 반복하는 판단과 클릭을, 시스템이 대신 책임질 수는 없을까?"
3. 선택 가능한 대안들은 무엇이었는가
문제를 정의한 뒤, 몇 가지 접근을 검토했다.
① 요청이 올 때마다 기능 추가
- 즉각적인 만족도는 높음
- 하지만 구조적 개선 없이 기능만 누적
- 운영 부담은 장기적으로 그대로
→ 문제를 '처리'하는 방식이지, 해결하는 방식은 아니라고 판단
② 화면 위주의 UI 개선
- 체감 속도는 일부 개선
- 하지만 데이터 조회 구조는 그대로
- 반복 업무 자체는 여전히 존재
→ 근본적인 변화는 어렵다는 결론
③ 운영 흐름 기준으로 시스템 재정의
- 운영 업무를 프로세스로 분해
- 자동화 가능한 지점 식별
- 성능, 알림, 배치를 함께 고려
→ 운영 효율을 시스템 책임으로 옮기는 선택
4. 그래서 어떤 선택을 했는가
결론적으로 운영 업무를 기준으로 시스템을 다시 바라보기로 했다.
핵심 선택은 다음과 같았다.
- 반복 업무는 자동화 대상
- 자주 조회되는 화면은 성능 최우선
- 장애 알림은 '중요도' 기준으로 분리
"운영팀이 시스템을 관리하는 시간이 아니라, 판단과 대응에 집중하게 만들자."
5. 구현에서 가장 중요했던 포인트
① 조회 성능 개선이 곧 운영 효율 개선
운영팀이 가장 자주 사용하는 거래 내역 조회 페이지의 로딩 시간이 약 15초에 달했다.
이를 해결하기 위해
- 실행 계획(EXPLAIN) 분석으로 Full Table Scan 구간 식별
- 날짜·상태 기준 복합 인덱스 적용
- 불필요한 조인 제거 및 N+1 문제 해소
- OFFSET 기반 페이지네이션 개선
그 결과 페이지 로딩 속도를 15,000ms → 2,000ms로 개선(약 75% 이상 단축).
② 반복 업무의 시스템 자동화
운영팀이 매일 수행하던 작업 중 명확한 규칙을 가진 업무를 자동화 대상으로 정의했다.
- 일일 정산 내역 자동 집계 및 알림
- 특정 조건 충족 시 거래 상태 자동 전환
- 주간·월간 리포트 자동 생성
이를 통해 주당 약 4시간 이상의 운영 업무 시간을 절감할 수 있었다.
③ 장애 알림의 의미를 되찾기
모든 알림이 하나의 채널로 쏟아지고 있었고, 중요한 장애 신호가 묻히고 있었다.
그래서 결제 실패·시스템 다운 등 긴급 알림과 정기 배치 완료·로그성 일반 알림을 분리하여 채널을 구분했다.
이후 장애 발생 시 5분 이내 인지 및 대응이 가능해졌다.
6. 결과는 무엇이 달라졌는가
개선 이후 변화는 명확했다.
- 운영팀 백오피스 기능 개선 50건 이상
- 주요 페이지 성능 75% 이상 개선
- 반복 업무 자동화로 주당 4시간 이상 절감
- 장애 대응 시간 단축 및 운영 만족도 향상
무엇보다 운영팀과의 커뮤니케이션 방식 자체가 바뀌었다. "이거 수동으로 해야 하나요?" 대신 "이건 자동화할 수 있을까요?"라는 질문이 나오기 시작했다.
7. 이 경험을 통해 얻은 판단 기준
이 경험을 통해 확실해진 기준은 아래와 같다.
- 운영 효율은 UI보다 데이터 흐름에서 나온다
- 자동화는 기능 추가가 아니라 책임 이동이다
- 시스템 품질은 운영팀의 체감 속도로 드러난다
운영을 고려하지 않은 시스템은 결국 사람의 시간으로 비용을 치르게 된다는 점을 체감했다.
8. 다음에 다시 한다면
초기에는 운영 업무를 더 세밀하게 관찰하지 못한 아쉬움이 있다.
다음에는 운영팀의 하루를 처음부터 끝까지 따라가며 시스템이 방해하는 지점을 먼저 정의하고 싶다.
운영 자동화는 개발자의 편의가 아니라 현장의 시간을 존중하는 설계라는 점을 다시 확인했다.