우선순위 기반 아키텍처 판단 확인
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
처리량 증가 요구가 오면 저는 캐시부터 확인하는 편입니다. 대부분의 트래픽 급증은 같은 데이터를 반복적으로 조회하는 패턴에서 오는 경우가 많아서, 캐싱만으로도 DB 부하를 크게 줄일 수 있습니다.
팀 프로젝트에서 조회 응답이 느려지는 문제가 발생했을 때, 처음에는 서버 스케일업을 고려했습니다. 로그를 보니 같은 데이터를 수백 번 반복 조회하고 있었습니다. 인메모리 캐시를 적용했더니 응답 시간이 70% 줄어들었습니다.
캐시를 먼저 보는 이유는 변경 비용이 상대적으로 낮고 효과가 빠르기 때문입니다. 비동기나 샤딩은 아키텍처를 바꿔야 하는 경우가 많아서 리스크가 크기 때문입니다. 물론 캐시 무효화 전략을 제대로 설계하지 않으면 오히려 데이터 정합성 문제가 발생할 수 있는데, 그 부분은 처음에 꼼꼼히 설계해야 한다는 것을 경험으로 배웠습니다.
캐시·비동기·샤딩 중 무엇을 먼저 쓸지는 어디서 병목이 발생하는지에 따라 달라져요. 처리량 문제라고 해도 원인이 DB 쿼리인지, 외부 API 호출인지, 데이터 양인지에 따라 적합한 해법이 다르거든요.
프로젝트에서 응답 속도 문제를 겪었을 때, 처음엔 캐시를 적용했는데 효과가 별로 없었어요. 나중에 보니 외부 API 응답을 기다리는 시간이 병목이었고, 비동기 처리로 전환하니 전체 처리량이 올라갔습니다.
그 경험 이후로 증상을 보고 바로 해결책을 적용하기보다, 먼저 어디서 시간이 소모되는지 측정하는 단계를 넣게 됐어요. 툴 없이 감으로만 접근하면 잘못된 곳을 최적화하는 실수를 하게 되거든요. 측정이 먼저, 적용은 그 다음이라는 게 제 기준이에요.
외부 API 의존이 많은 시스템에서는 비동기 처리를 먼저 고려하는 게 효과적이에요. 동기 방식으로 외부 호출을 기다리면 그 시간만큼 스레드가 묶이고 전체 처리량이 떨어지거든요.
백엔드 수업 프로젝트에서 이메일 발송 API를 동기로 구현했다가 응답이 느려지는 문제가 생겼어요. 메일 서버 응답을 기다리는 동안 다른 요청들이 쌓이더라고요. 비동기 큐로 분리하니 요청 처리 속도가 확연히 달라졌습니다.
비동기의 단점은 실패 처리가 복잡해진다는 거예요. 큐에서 실패했을 때 재시도 로직을 잘못 설계하면 중복 처리가 생길 수 있어서, 그 부분을 처음부터 신경 써야 해요. 성능 이점은 빠르게 얻을 수 있지만 안정성을 함께 챙기지 않으면 다른 문제가 생긴다는 걸 그 경험이 가르쳐줬습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 채널톡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.