레거시 개선 방법론 확인
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기존 단일 구조로 된 서비스에서 특정 기능의 부하가 몰릴 때 전체가 느려지는 문제를 코드 리뷰에서 발견했습니다. 리뷰에서 병목 지점을 분석하고, 그 기능만 분리해서 독립적으로 스케일할 수 있는 구조로 전환하는 방향을 제안했습니다. 변경 범위를 최소화하기 위해 인터페이스를 유지하면서 구현체만 교체하는 방식을 선택했습니다.
서비스 분리 후 해당 기능에 트래픽이 집중되어도 다른 서비스에 영향이 없어졌습니다. 변경 과정에서 기존 테스트를 유지하면서 새 구조에서도 동일하게 통과하는지 확인했습니다. 범위를 좁게 잡고 검증을 촘촘하게 하는 것이 리뷰 기반 개선의 핵심입니다. 작은 변경이 시스템 안정성을 바꿔주었습니다.
코드 리뷰에서 동일한 데이터를 반복해서 `DB`에 조회하는 패턴을 발견했습니다. 읽기 부하가 집중되면 DB 연결이 포화되는 구조였어요. 캐시 레이어를 중간에 추가해서 반복 조회를 줄이는 방향으로 개선을 제안했고, 적용 후 DB 조회 빈도가 크게 줄었습니다. 변경 범위는 조회 로직이 있는 서비스 계층에 캐시 조회를 먼저 확인하는 로직을 추가하는 수준으로 제한했어요.
기존 인터페이스를 바꾸지 않아서 다른 모듈에 영향이 없었습니다. 캐시 무효화 타이밍을 잘못 설정하면 오래된 데이터가 남는 문제가 생길 수 있어서, 만료 정책을 데이터 특성에 맞게 설정하는 것도 함께 설계했어요. 개선은 범위를 좁게, 검증은 촘촘하게가 원칙이에요.
리뷰에서 오래 걸리는 작업을 동기로 처리해서 응답이 블로킹되는 패턴을 발견했습니다. 요청이 몰리면 처리 대기열이 쌓이면서 전체 응답이 느려지는 구조였어요. 비동기 처리로 전환하고 메시지 큐를 통해 작업을 분리하는 방향으로 리팩터링을 제안했습니다. 변경 범위는 해당 엔드포인트의 처리 로직과 큐 발행 코드에 집중했고, 기존 응답 형태는 유지했어요.
비동기로 바뀌면 클라이언트 쪽에서 처리 완료를 폴링하거나 알림받는 방식이 추가되어야 해서 그 부분도 함께 설계했습니다. 시스템 하나를 바꾸면 연결된 부분도 함께 봐야 한다는 걸 배웠어요. 개선 범위를 좁혀도 영향 범위는 넓게 파악해야 나중에 놀라는 일이 없어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 채널톡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.