### 1. 문제 상황
관리자 페이지에서 특정 사용자 목록을 조회하는 기능을 구현하면서, 조건이 많고 정렬 기준이 복잡한 조회 로직을 사용하고 있었습니다.
조회 과정에서는 단순히 데이터를 가져오는 것뿐만 아니라 대상 조건 계산, 상태 판별, 정렬 처리 등이 함께 수행되고 있었고, 요청이 들어올 때마다 동일한 연산이 반복되는 구조였습니다.
처음에는 단순 조회 기능이라고 생각했지만, 실제로는 요청 시마다 같은 데이터를 계속 다시 계산하고 있다는 점이 눈에 들어오기 시작했습니다.
특히 데이터 특성상 실시간으로 계속 변경되는 데이터가 아니었음에도 매 요청마다 전체 데이터를 새로 구성하는 방식은 운영 효율 측면에서 비효율적이라고 느껴졌습니다.
이러한 구조는 다음과 같은 문제를 가지고 있었습니다.
- 동일한 데이터 반복 계산
- 불필요한 DB 조회 증가
- 복잡한 정렬 및 필터 로직 반복 수행
- 데이터 규모 증가 시 성능 저하 가능성
단순히 쿼리 최적화만으로 접근하기보다는, 데이터를 생성하고 사용하는 흐름 자체를 다시 고민할 필요가 있었습니다.
### 2. 접근 방식
해당 데이터는 하루 동안 큰 변화가 발생하지 않는다는 특징이 있었습니다.
이 점에 착안해 매 요청마다 데이터를 계산하는 대신, **하루 단위로 데이터를 생성하고 이후에는 재사용하는 구조**를 적용했습니다.
즉, 조회 시점마다 데이터를 계산하는 구조가 아니라 필요한 시점에만 데이터를 생성하고, 이미 생성된 데이터는 다시 활용할 수 있도록 방향을 변경했습니다.
이 과정에서 가장 중요하게 생각한 부분은 “언제 데이터를 새로 생성할 것인가”였습니다.
단순 캐싱처럼 메모리에 임시 저장하는 방식보다는 생성 시점을 명확하게 관리할 수 있는 구조가 필요하다고 판단했습니다.
### 3. 구현 방식
#### 3.1 데이터 구조 분리
하루 단위 재사용 구조를 적용하기 위해 데이터를 두 가지로 나누어 관리했다.
| 구분 | 역할 |
|------|------|
| 기준일 데이터 | 당일 데이터 생성 여부 판단 |
| 조회 대상 데이터 | 실제 조회 시 사용하는 데이터 저장 |
기준일 데이터는 현재 날짜 기준으로 데이터 생성이 이미 수행되었는지를 판단하는 역할을 합니다.
반면 조회 대상 데이터는 실제 조회 시 재사용되는 데이터를 저장합니다.
이처럼 생성 여부를 관리하는 데이터와 실제 조회 데이터를 분리함으로써 데이터 흐름을 단순하게 유지하려고 했습니다.
또한 운영 환경에서는 애플리케이션 재시작이나 다중 요청 상황 등이 발생할 수 있기 때문에 메모리 기반 관리보다는 DB 기준으로 관리하는 방식이 더 적절하다고 판단했습니다.
#### 3.2 데이터 생성 및 재사용 흐름
요청이 들어오면 먼저 현재 날짜 기준 데이터가 이미 존재하는지 확인합니다.
만약 해당 날짜의 데이터가 존재하지 않는 경우에는 최초 요청 시 전체 데이터를 생성합니다.
이후에는 이미 생성된 데이터를 그대로 조회에 사용하도록 구성했습니다.
처리 흐름은 다음과 같습니다.
1. 현재 날짜 기준 데이터 존재 여부 확인
2. 데이터가 없으면 전체 데이터 생성 수행
3. 데이터가 존재하면 생성 과정 없이 조회 수행
4. 조회 결과 반환
이 구조를 통해 최초 1회만 데이터 생성이 수행되고, 이후에는 재사용 흐름을 따르도록 했습니다.
#### 3.3 데이터 생성 로직
데이터 생성 시에는 단순히 기존 데이터를 모두 삭제하고 새로 만드는 것이 아니라 기존 상태를 일부 유지하면서 최신 데이터 기준으로 재구성하도록 설계했습니다.
생성 과정에서는 다음과 같은 작업이 수행됩니다.
- 더 이상 유효하지 않은 기존 데이터 제거
- 최신 기준으로 대상 데이터 재구성
- 기존 상태 값 일부 유지
- 기준일 데이터 등록
특히 기존 상태 값을 유지하는 부분을 중요하게 생각했습니다.
매번 데이터를 완전히 초기화하게 되면 운영 과정에서 관리자가 수정한 정보까지 사라질 수 있기 때문입니다.
따라서 기존 데이터를 확인한 뒤 필요한 값만 유지하도록 구성했습니다.
### 4. 설계 의도 및 효과
기존 방식과 개선된 구조를 비교하면 다음과 같습니다.
| 구분 | 기존 방식 | 개선 방식 |
|------|----------|----------|
| 데이터 처리 방식 | 요청마다 계산 | 최초 1회 생성 후 재사용 |
| DB 조회 | 반복 조회 발생 | 생성 이후 조회만 수행 |
| 응답 흐름 | 요청마다 변동 가능 | 일정하게 유지 |
| 연산 비용 | 반복 계산 발생 | 최초 생성 시에만 수행 |
| 데이터 관리 방식 | 조회 시점 중심 | 생성 시점 중심 |
이 구조를 통해 단순히 조회 횟수를 줄이는 것뿐만 아니라 데이터 생성 시점과 조회 시점을 분리할 수 있었습니다.
특히 이번 구조는 실시간성이 크게 중요하지 않은 데이터 특성을 고려해 계산 비용보다 재사용 효율을 우선하도록 설계했습니다.
또한 생성 시점을 기준으로 데이터를 관리함으로써 조회 흐름 자체를 단순하게 유지할 수 있었습니다.
### 5. 회고
처음에는 단순 조회 기능이라고 생각했지만, 구현 과정에서는 “왜 동일한 데이터를 계속 다시 계산하고 있는가”라는 질문을 마주하게 되었습니다.
그리고 그 질문을 따라가다 보니 단순 쿼리 최적화보다 더 중요한 것은 “데이터를 언제 생성하고 어떻게 관리할 것인가”라는 점이라는 것을 느낄 수 있었습니다.
이번 작업을 통해 성능 개선은 단순히 조회 속도를 빠르게 만드는 것이 아니라 데이터 흐름 자체를 다시 설계하는 과정이라는 점을 배울 수 있었습니다.
또한 조회 로직뿐 아니라 데이터 생성 시점, 상태 유지 방식, 재사용 구조까지 함께 고려해야 안정적인 운영 구조를 만들 수 있다는 점도 경험할 수 있었습니다.
zero