운영팀의 15초를 줄이는 개발이 가장 어려웠다: 운영 자동화 회고
들어가기
운영팀은 매일 관리자 페이지를 통해 거래 내역 확인, 정산 상태 점검, 리포트 생성 등 반복적인 업무를 수행하고 있었어요.
문제는 시스템이 기능적으로는 동작하지만, 운영 관점에서는 전혀 최적화되어 있지 않았다는 점이었죠.
- 자주 사용하는 조회 페이지 로딩 시간 15초 이상
- 단순 상태 변경, 정산 확인 작업을 매번 수동 처리
- 장애 알림이 하나의 채널로 몰려 중요한 신호를 놓침
이로 인해 운영팀은 "일을 판단하는 시간"보다 "시스템을 기다리는 시간"에 더 많은 에너지를 쓰고 있었어요.
단순한 UI 불편이 아니라, 시스템이 운영 업무의 흐름을 전혀 고려하지 않고 설계되었다는 신호라고 느꼈죠.
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. 다음에 다시 한다면
초기에는 운영 업무를 더 세밀하게 관찰하지 못한 아쉬움이 있어요.
다음에는 운영팀의 하루를 처음부터 끝까지 따라가며 시스템이 방해하는 지점을 먼저 정의하고 싶어요.
운영 자동화는 개발자의 편의가 아니라 현장의 시간을 존중하는 설계라는 걸 다시 느꼈죠.
