레거시는 점진적으로, 캐시는 운영까지 설계하라

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

서로 달라 보이는 두 기술 변경이 같은 방식으로 실패할 때가 있다. 팀이 경계와 운영 비용을 이해하기 전에 큰 결정을 내리는 경우다. 레거시 모놀리스를 나누면서 잘못된 서비스 지도를 굳힐 수 있다. 캐시는 데이터베이스 문제를 가린 뒤 팀이 겪어보지 못한 배포 장애를 추가할 수 있다.

둘 다 근거가 있는 가장 작은 단계에서 시작해야 한다.

레거시 개편은 첫 경계가 중요하다

모놀리스를 점진적으로 분리할 수 있지만 ‘점진적’이라는 말이 모든 분리를 안전하게 만들지는 않는다. 주문과 상품 중 무엇을 먼저 떼어낼지 같은 결정이 개편의 성패를 좌우할 수 있다. 경계가 틀리면 이후 서비스가 어색한 의존성을 물려받고 프로젝트는 분리 자체를 고치는 데 시간을 쓴다.

비즈니스를 명사 목록대로 나누지 않는다. 학교 시스템에 책상과 의자, 책과 사물함이 있다고 해서 각각 별도 서비스가 필요한 것은 아니다. 쓸 만한 경계는 엔티티 개수보다 비즈니스 책임과 변경 이유에서 나온다.

역할을 이해하고 상호작용을 관찰할 수 있는 영역부터 고른다. 리뷰 가능한 작은 단위로 옮기고 결과를 검증하며, 배운 내용으로 다음 경계를 수정한다. 큰 재작성은 모델이 틀렸다는 사실을 비용이 커지기 전에 발견할 지점을 줄인다.

느린 쿼리가 곧 캐시 요구사항은 아니다

데이터가 과도하게 많지 않은데 쿼리에 여러 초가 걸린다면 먼저 쿼리와 인덱스, 데이터 접근 설계를 의심한다. 캐시를 넣으면 겉으로 빨라질 수 있지만 아래의 결함은 그대로 남는다.

더 설득력 있는 캐시 조건은 다르다. 데이터베이스 조회 자체는 합리적인데 요청량이 높아 DB에 부담이 되고, 많은 요청이 적은 수의 값을 반복해서 읽어 높은 적중률을 기대할 수 있을 때다. 이 조건에서는 공유 캐시가 반복 조회를 줄일 수 있다.

설명에 쓰이는 처리량과 데이터 수는 기준선이 아니다. 데이터 모양과 쿼리 비용, 트래픽 패턴이 캐시의 가치를 결정한다.

캐시 스키마 변경도 배포다

공유 캐시에는 구버전과 신버전 애플리케이션이 동시에 읽을 수 있는 표현이 저장된다. 롤링이나 블루그린 배포 중에 같은 키 아래 필드나 의미를 바꾸면 두 버전이 호환되지 않을 수 있다. 키를 전부 지운다고 끝나지도 않는다. 살아 있는 구버전 인스턴스가 옛 모양을 다시 쓸 수 있고, 롤백한 버전이 신버전의 값을 읽지 못할 수도 있다.

전환 기간에 두 표현이 공존하도록 새 키나 명시적인 버전을 써야 할 수 있다. 정확한 전략은 캐시와 배포 방식에 따라 달라진다. 다만 모든 인스턴스가 동시에 바뀐다고 가정하지 말고 혼합 버전을 설계해야 한다.

운영 비용은 이것뿐이 아니다. 동기화와 무효화, 캐시 저장소 장애, 데이터베이스 폴백, 캐시를 다시 채우는 방법도 결정해야 한다. 로컬 캐시는 세부사항이 다르지만 역시 공짜는 아니다.

복잡성에는 측정된 이유가 필요하다

데이터베이스로 합리적으로 풀 수 있는 데까지 먼저 간다. 측정하거나 충분히 모델링한 부하가 새 실패 조건을 감수할 만큼 DB 작업 감소를 요구할 때 캐시를 추가한다. 레거시는 팀이 비즈니스 경계를 설명하고 이동을 검증할 수 있을 때 나눈다.

신중함은 ‘하지 말라’는 뜻이 아니다. 캐시가 정확한 답일 수도 있고 모놀리스를 반드시 나눠야 할 수도 있다. 시점이 중요하다. 현재 시스템을 이해하고 되돌릴 수 있는 변경 하나를 한 뒤, 운영에서 더 나은 근거가 생길 때까지 다음 선택을 열어 둔다.