🧩백오피스 대체 (40만 MAU)

전체 로직 추상화

개요

백오피스 V1 및 관련 API를 대체하는 프로젝트

• 기간: 2023.12 - 2024.02

• 소속: 노써치 / 개발

• 기술 스택: Typescript, NodeJS 18, NestJS, PostgreSQL, GCP, JMeter

• 참여인력: 백오피스 3인(본인, CTO, 개발 리더), 백오피스 API 3인 (본인, FE 팀원 2인)

• 성과: 운영 비용 1/4, 백오피스 사용성 개선, 코드 복잡성 감소

상세 설명

프로젝트 설명

기존 백오피스 V1은 2020년에 개발된 대규모 모놀리식 애플리케이션이었습니다. 내부에는 이를 기반으로 한 API도 함께 포함되어 있었습니다. 시간이 지나면서 요구사항이 점점 늘어났고, 이에 따라 코드의 복잡도도 증가하게 되었습니다. 그 결과, 점차 코드 수정이 어려워지는 상황에 직면했습니다. 당시의 구조로는 계속해서 늘어나는 요구사항을 충족하기 어렵다고 판단하여, 이번 프로젝트를 시작하게 되었습니다.

문제

설계를 괄시했다.

백오피스의 주요 기능 중 하나는 복잡한 입력을 받아 계산하는 기능이었습니다. 이 기능은 사용자 입력의 자유도가 매우 높아서, 구현 난이도 또한 상당히 높았습니다.

당시 저는 과거에 프로토타입으로 유사한 기능을 개발했던 경험과, 빠른 개발을 우선시해야 한다는 판단에 따라 충분한 준비 없이 개발부터 시작하는 실수를 범했습니다. 하지만 개발을 진행하는 과정에서 문제점이 드러났습니다. 요구사항을 충족하지 못했을 뿐 아니라, 코드가 지나치게 복잡해져 유지보수와 이해가 어려운 상태가 된 것입니다.

결국 리뷰 과정에서도 많은 시간을 소비해야 했고, 불필요하게 인적 자원이 낭비되는 결과로 이어졌습니다.

이러한 시행착오를 겪은 뒤, 상세한 설계 문서를 작성하고 이를 기반으로 개발을 다시 진행했습니다. 설계 문서를 토대로 리뷰를 먼저 받으면서 개발을 진행하자, 리뷰 속도도 빨라지고 방향성에 대한 합의도 원활하게 이루어졌습니다. 결과적으로 해당 기능은 만족스러운 성능과 사용성을 갖춘 상태로 구현할 수 있었습니다.

READ 요청이 중심인 설계가 필요했다.

노써치 제품은 READ 요청이 중심인 서비스로, 설계 단계에서 READ 성능을 최우선 과제로 삼아야 했습니다.

당시 가장 큰 문제는, 백오피스에서 생성된 데이터를 고객에게 제공하기 위해 여러 테이블 간 JOIN이 필요했다는 점이었습니다. 실제로 EXPLAIN으로 실행 계획을 분석해 보니 다수의 Nested Loop Join이 사용되고 있었고, 여러 최적화 시도를 했음에도 성능이 크게 개선되지는 않았습니다.

데이터의 변경 주기가 길다는 점을 근거로, 고객 제공용 데이터를 별도의 테이블에 미리 저장하거나 Materialized View를 사용하는 방법을 검토했습니다. CTO님과의 논의 끝에, 개별 데이터 갱신이 필요한 요구사항이 있다는 점을 고려하여 Materialized View 대신 조회 전용 테이블을 구축하는 방식으로 결정했고, 이에 맞춰 구조를 설계하고 개발했습니다.

다음 과제는 데이터 생성을 어떤 주기와 트리거로 할 것인가였습니다. 초기 MVP에서는 배치 작업을 통해 매일 1회 전체 데이터를 생성하는 방식으로 출발했습니다. 이후 개선 단계에서는 문서(데이터)가 수정될 때마다 즉시 갱신이 이루어지도록 트리거를 추가해, 콘텐츠 매니저(Content Manager, CM)가 반영 여부를 결정할 수 있도록 보완했습니다.

결과적으로, 원하는 수준의 응답 속도를 달성했으며, 데이터베이스의 메모리와 CPU 사용량이 안정적인 상태임을 검증할 수 있었습니다.

대체를 위한 JMeter테스트

API 대체를 기획하면서 가장 먼저 고민한 것은 기존 요청량을 충분히 처리할 수 있는지 여부였습니다. 이를 검증하기 위해 CTO님의 추천으로 JMeter를 활용한 스트레스 테스트를 진행했습니다.

테스트 기준은, 과거 서비스 장애가 발생했던 최대 트래픽이 10분간 지속되는 상황으로 설정했습니다. 테스트 결과, 요청에 대한 응답 자체는 문제없이 이루어졌지만 시간이 지날수록 응답 속도가 점점 느려지는 현상이 확인되었습니다.

이에 대한 대응책으로, Redis 캐시를 활용하여 가장 빈번하게 호출되는 엔드포인트의 응답을 캐싱하는 전략을 선택했습니다. 그 결과, 테스트 환경에서도 10분 동안 초기 응답 속도와 유사한 수준을 안정적으로 유지할 수 있었고, 이를 바탕으로 API 대체를 위한 다음 단계로 나아갈 수 있었습니다.

성과

1. 기존 과하게 사용되던 환경에 비해 비용을 1/4로 감축하였습니다.

2. 백오피스 자체의 사용성을 개선하여 CM 분들이 더 일을 빠르고 효율적으로 할 수 있는 환경을 구성하였습니다.

3. 코드 복잡성이 감소하여 요구사항 변화를 기민하게 대응할 수 있었습니다.

배운점

1. 설계를 철저히하자.

   1. 느낀점

      1. 잘안다는 착각을 주의해야 합니다.

      2. 문서화부터 리뷰를 받아야 추후 개발까지 목적에 맞게 구현이 가능하다는 것을 너무 늦게 깨달았습니다.

   2. action item

      1. 작업 전에 항상 설계 문서를 작성합니다.

      2. 간단하다는 생각이 들면 메신저에라도 정리해서 정말 잘 검토한 것인지 검증합니다.