⏱️광고 수정 개선 (10초 > 1초)

수정 플로우 추상화

개요

초기에 동기로 구성된 작업을 메세지 큐로 리펙토링

• 기간: 2024.10.24 - 2024.10.26

• 소속: 아임웹 / AD Squad

• 기술 스택: Typescript, NodeJS 18, NestJS, MySQL, Redis, BullJS, Docker compose

• 인원: 1인

• 성과: 고객 대기 시간 1/10, 광고 수정 관련 CS 인입 1/7

상세 설명

프로젝트 설명

광고 수정 작업은 입사 이틀째부터 바로 투입된, 광고 캠페인 전체 수정 작업의 두 번째 단계였습니다. 당시 데드라인이 명확하고 촉박했기 때문에, 최대한 빠르게 개발할 수 있는 방향으로 설계를 진행했습니다. 결과적으로 광고를 수정하면 메타(Meta)와 구글(Google)에 반영되는 동안 유저가 대기하도록 처리하는 방식으로 구현했습니다.

그러나 배포 후 사용성을 점검하는 과정에서 두 가지 문제가 발견되었습니다.

첫째, 속도가 느리다는 점이었습니다. 유저는 구글과 메타에 변경 사항이 반영될 때까지 약 10초 동안 대기해야 했습니다. 이는 명확한 개선 포인트였으며, 작업 개선을 제안하게 된 주요 배경이 되었습니다.

둘째, 광고 수정 필요 상태를 나타내는 플로우가 이중으로 존재하는 문제였습니다. 원래 의도는 유저가 이미 구글과 메타에 등록된 광고를 수정할 때, 즉시 반영 여부를 보여주는 것이었으나, 실제로는 광고 생성이 실패한 경우까지 동일하게 "수정 필요" 상태로 표시되고 있었습니다. 이로 인해 유저 입장에서는 광고 생성 실패와 수정 필요 상태가 구분되지 않아 혼란이 발생했고, 추가 개선이 필요한 상황임이 명확해졌습니다.

이러한 문제들을 기반으로 개선 작업의 필요성을 설득할 수 있었고, 이후 개선 작업을 진행할 수 있었습니다.

아키텍처 설명

광고 생성 과정은 캠페인 → 광고 그룹 → 광고 순서로 진행됩니다. 수정 작업 역시 이 순서를 따라야 했으며, 각 단계를 메시지 큐를 활용해 독립적인 작업으로 분리하는 방식으로 리팩토링했습니다.

여기서 핵심은, 이전에 실패한 단계가 있을 경우 해당 단계를 다시 생성하는 흐름으로 전환해야 한다는 점이었습니다. 이를 위해 처리 로직을 생성과 수정으로 명확히 분리하고, 상황에 따라 분기하여 동작하도록 설계했습니다.

결과적으로, 실패 이력이 있는 경우에는 생성 플로우로, 그렇지 않은 경우에는 수정 플로우로 자연스럽게 이어지도록 개선할 수 있었습니다.

문제

기존 자료구조를 사용할 수 없다.

이전에 메시지 큐를 활용한 작업들은 큐로 분리되어 있긴 했지만, 복잡한 자료구조로 인해 각 단계별로 분리하기가 어려운 상태였습니다. 그래서 기존 자료구조를 그대로 사용할지, 아니면 새롭게 설계할지를 결정해야 했습니다.

저는 새롭게 자료구조를 설계하는 방향을 선택했습니다. 기존 작업에 테스트가 부족했고, 각 단계별로 검증이 필요하다는 점을 고려한 결정이었습니다.

다행히도, 기존에 작성해 둔 함수들을 재사용할 수 있었기 때문에 작업을 빠르게 진행할 수 있었습니다. 또한, 개발 단계에서 충분히 테스트를 통해 검증한 후 QA 를 거칠 수 있어 안정적으로 작업을 마칠 수 있었습니다.

성과

1. 고객의 대기시간이 10초에서 1초로 감소하였습니다. 실패할 경우, 해당 단계에서 상태를 변경하고 알림을 줘 고객이 빠르게 대응할 수 있도록 처리했습니다.

2. 광고 수정 실패로 인한 CS인입이 이전 일평균 7건에서 0 - 1건으로 줄어 들었습니다.

배운점

1. 복잡한 자료구조가 필요하다면 문서화를 꼭 남길 것

   1. 느낀점

      1. 자료구조의 구조, 초기화 단계 등이 너무 산재되어 파악하기가 어려웠습니다.

      2. 문서가 있었다면, 초기화만이라도 모았다면 어땠을까 하는 아쉬움이 들었습니다.

   2. action item

      1. 복잡한 자료구조를 도입해야 한다면 작업 문서에 기록합니다.

      2. 초기화는 가능한 선언과 인접한 곳에서 하자는 것을 코딩 가이드에 추가했습니다.