Breeze 운영에서 먼저 파악한 시스템 구성과 연결 관계

Breeze 운영을 맡고 처음 확인한 것은 각 컴포넌트가 어떤 데이터를 읽고 변경하는지였습니다. 사용자 웹과 관리자 도구, 배치, 고객센터 기능이 연결되어 있어서 한 화면의 문제를 그 화면의 코드만 보고 판단하기 어려웠습니다.

기능별로 나뉜 부분이 있었지만 데이터베이스를 공유하는 구조였습니다. 컴포넌트가 분리돼 있다는 이유만으로 독립된 마이크로서비스처럼 변경할 수는 없었습니다. 로컬 플랫폼을 MSA로 다시 구성하는 방향도 검토됐지만, 이후에는 글로벌 플랫폼으로 옮기는 쪽으로 정해졌습니다.

공유 데이터와 변경 영향

같은 주문을 사용자 화면과 고객센터 도구, 배치가 각자의 목적으로 사용했습니다. 어느 곳에서 값을 바꾸는지와 다른 곳이 언제 그 값을 읽는지 알아야 변경의 영향을 볼 수 있었습니다.

DB를 공유하면 배치의 큰 조회나 갱신이 온라인 요청과 자원을 두고 경합할 수도 있습니다. 특정 API가 느려졌을 때 그 API의 변경 내역 외에 같은 시간에 실행된 작업도 확인할 필요가 있었습니다.

상품 데이터와 검색 반영

상품 정보가 저장됐다는 것과 사용자의 목록에 표시되는 것은 같은 시점이 아닐 수 있었습니다. 관리자에서 변경한 데이터가 검색 인덱스와 캐시를 거쳐 화면에 노출되는 과정을 함께 봐야 했습니다.

예를 들어 상품이 안 보인다는 문의가 오면 원본 데이터가 있는지, 인덱스에 반영됐는지, 실제 조회가 어느 쪽으로 들어가는지 나눠 확인할 수 있습니다. 원본이 정상인데 화면이 다르다고 해서 바로 웹 코드의 문제로 판단하지 않는 이유였습니다.

검색 쪽에서 경험한 문제는 Solr 이중화와 장애 전환에서 따로 설명했습니다.

배치와 외부 연동

주문 뒤의 처리는 요청 한 번으로 모두 끝나지 않았습니다. 배치가 결과를 반영하거나 외부 시스템의 응답을 받아 다음 상태로 넘어가는 흐름이 있었습니다. 데이터가 아직 안 들어온 것인지, 들어온 뒤 내부 처리가 멈춘 것인지 구분해야 했습니다.

외부 호출이 실패한 경우에도 상대 시스템의 장애인지, 네트워크나 우리 쪽 설정 문제인지부터 확인해야 합니다. 요청과 응답, 내부 반영 기록을 이어서 봐야 어느 구간에서 막혔는지 알 수 있었습니다.

운영 확인 순서

문제가 생겼을 때는 증상이 나타난 시각과 기능에서 시작해 관련 데이터와 처리 경로를 확인했습니다. 화면을 먼저 보지 않는다는 규칙을 정하기보다, 화면에서 확인한 증상과 서버·DB 등의 기록을 함께 보는 방식이었습니다.

이렇게 연결 관계를 파악해 둔 내용은 배포와 전환 준비에도 사용했습니다. 어느 컴포넌트를 바꾸면 함께 확인해야 하는지, 중단할 배치와 남길 조회 경로가 무엇인지 판단할 때 필요한 정보였습니다.