1. OMS 시스템에서 처리하신 주문 데이터는 어떤 방식으로 안정성을 확보했나요?
OMS는 일 평균 3만 건 이상의 주문 데이터를 처리하는 핵심 시스템이라, 안정성을 위해 API 요청·응답 로깅과 예외 처리 로직을 전 구간에 적용했습니다.
또한 Service 계층에 트랜잭션과 예외 처리 로직을 적용해 데이터 정합성을 보장했고, 주요 쿼리는 인덱싱과 쿼리 최적화를 통해 병목을 최소화했습니다.
추가로 AWS CloudWatch와 Datadog 모니터링을 적용해 장애 조기 감지와 대응이 가능하게 했습니다.
꼬리질문:
→ API 요청·응답 로깅은 어떻게 설계했나요? 성능 저하는 없었나요?
API 요청/응답 로깅은 AOP 기반 Interceptor로 구현해 전 구간에 적용했습니다.
실제 응답 바디 전체를 저장하는 대신, 핵심 필드와 오류 메시지만 로그 테이블에 저장해서 저장 공간과 성능 부하를 최소화했습니다.
또한 로그 보존 기간 정책을 둬 운영 환경에 부담이 가지 않도록 설계했습니다.
2. 실서비스 운영 중 발생한 트러블 상황과 해결 경험이 있나요?
이커머스 플랫폼 연동 중 주문 데이터 필드에 이모티콘이 포함되어 파싱 과정에서 예외가 발생했고, 시스템이 멈춘 적이 있었습니다.
운영 모니터링 알람을 받고 즉시 로그를 분석해 원인을 확인했고, 해당 필드를 유니코드 호환 처리가 가능한 컬럼 타입으로 변경해 문제를 해결했습니다.
이후 사전 검증 로직을 Controller 레이어에서 추가해, 특수문자나 DB 호환 불가능한 문자가 들어오면 사전에 필터링했습니다.
추가로 DB 스키마 설계 시 utf8mb4를 적용해 유니코드 전체를 지원하도록 했고, API 연동 시에도 공통 Validation 모듈을 만들어 재사용성을 높였습니다.
3. 주문 목록 조회 속도를 0.002초로 개선했다고 했는데, 구체적으로 어떤 인덱스를 설정하셨나요?
기존 단일 인덱스로 주문일자로만 걸었었습니다. , 쿼리 실행 계획(EXPLAIN) 결과 full scan이 발생하던 걸 확인했습니다.
주문 목록 조회는 일자 + 상태 조건이 자주 사용됐기 때문에, created_at, status 컬럼에 복합 인덱스를 생성했습니다. 이후 인덱스 range scan으로 바뀐 걸 확인했고, 실제 응답 속도도 크게 개선됐습니다.
그 결과 주문 1건 당 응답속도를 기존 0.042초에서 0.002초로 단축했습니다.
꼬리질문:
→ 응답 속도 테스트는 배포 전에 어떻게 측정하셨나요?
응답 속도 테스트는 운영 환경과 최대한 동일한 조건에서 진행하기 위해 운영 DB 스키마와 동일하게 구성한 Stage 서버에서 진행했습니다.
운영 데이터를 그대로 가져오지는 않고, 주기적으로 익명화된 더미 데이터를 생성하거나, 운영 데이터에서 주요 패턴(주문 건수, 상태 분포, 기간 분포 등)을 반영한 샘플 데이터를 생성해습니다. 이후 브라우저 개발자 도구의 Network 탭을 활용해 응답 속도를 직접 측정했습니다.
특히 조회 API 호출 시 request start → response end까지 걸린 시간을 확인했고, 기존에는 평균 42ms 이상 소요되던 것이 인덱스 최적화 후 약 2ms 수준으로 단축된 것을 검증했습니다.
이후에는 동일 조건에서 여러 번 반복 호출해 평균 속도를 확인했고, 페이지네이션 조건(날짜, 상태 필터)을 바꿔도 일관된 성능 개선이 나타나는 것을 확인했습니다. 실제 운영 배포 후에도 성능 차이가 거의 없음을 확인했습니다.
→ 인덱스를 잘못 설정했을 때 생길 수 있는 문제는 무엇인가요?
불필요한 인덱스는 DML 성능을 저하시킬 수 있고, 옵티마이저가 잘못된 인덱스를 선택하면 오히려 Full Scan보다 느려질 수 있습니다.
그래서 인덱스 설계 후에는 항상 EXPLAIN으로 실행 계획을 확인했고, 주기적으로 Slow Query Log를 모니터링하며 실제 사용 빈도가 낮은 인덱스는 제거했습니다.
4. 대용량 엑셀 다운로드 구현 시 어떤 문제상황이 있었나요?
초기에 10만 건 이상 데이터를 한 번에 메모리에 로드하다 보니 OOM이 발생했습니다.
이를 해결하기 위해 JDBC Streaming을 적용해 데이터를 청크 단위로 불러오고, 65,000행 단위로 분할 생성 후 ZIP 압축해 제공했습니다.
또한 BlockingQueue 기반 생산자-소비자 패턴을 도입해 읽기와 쓰기 작업 속도를 균형 있게 맞춰 17만 건 데이터의 엑셀 다운로드 처리 시간을 3분 이내로 줄였습니다.
JDBC Streaming과 청크 단위 분할, BlockingQueue 기반 병렬 처리 덕분에 OOM 없이 안정적으로 동작하게 만들었습니다
꼬리질문:
→ 왜 65,000행 단위로 분할했나요?
기존 Excel 2003의 XLS 포맷은 65,536행 제한이 있었고, Apache POI 라이브러리에서도 이 제약이 남아 있었습니다.
그래서 65,000행 단위로 분할해 여러 개의 XLSX 파일을 생성하고, 이를 ZIP으로 묶어 제공했습니다.
이 방식 덕분에 사용자 측에서도 Excel에서 정상적으로 열 수 있는 구조를 유지할 수 있었습니다.
→ 3분이라는 처리 시간이 서비스 요구사항에 충분했나요? 더 최적화할 방법이 있을까요?
운영 부서와 협의했을 때 3분 내에 다운로드 가능하면 충분하다고 판단했습니다.
추가 최적화를 한다면 파일 자체를 Excel 대신 CSV로 제공해 속도를 더 줄일 수 있을 거라 생각합니다. 다만 사용자 편의성을 고려해 Excel 방식을 유지했습니다.
