이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프론트엔드 서버 개발에서 가장 중요하게 생각하는 설계 원칙은 클라이언트와 백엔드의 결합을 최소화하는 것입니다. 클라이언트가 여러 API를 직접 호출하면 화면 변경이 백엔드 의존성에 묶이게 됩니다. BFF(Backend for Frontend) 패턴을 학습하면서, 클라이언트에 최적화된 응답을 만드는 중간 레이어가 화면 요구사항과 데이터 소스를 분리해준다는 것을 이해했습니다.
캐싱 전략도 프론트엔드 서버에서 중요한데, 자주 바뀌지 않는 데이터는 서버에서 캐싱해 백엔드 부하를 줄이고 응답 속도를 높였습니다. 에러 처리 일관성도 중요하게 생각하는데, 백엔드 에러를 클라이언트가 그대로 받으면 사용자에게 노출되는 메시지가 예측 불가능해집니다. 이 경험에서 프론트엔드 서버는 UI 로직의 연장이면서 동시에 보안과 캐싱을 담당하는 레이어라는 결을 얻었습니다.
프론트엔드 서버 BFF 레이어를 도입하기 전과 후를 비교할 수 있는 지표를 처음부터 정해두지 않아서 효과를 설명하기 어려웠습니다. 이후로는 변경 전에 측정할 것을 먼저 정하는 습관이 생겼습니다.
BFF를 도입하면서 클라이언트가 필요로 하는 데이터만 조합해 응답하는 방식으로 바꾸자, 여러 개의 API를 순차 호출하던 화면에서 응답 수신 완료까지 걸리는 시간이 줄었습니다. 네트워크 왕복 횟수가 3번에서 1번으로 줄어든 것이 직접적인 원인이었습니다.
에러 처리 일관성도 개선됐습니다. 이전에는 각 API의 에러 구조가 달라서 클라이언트가 경우마다 다르게 처리해야 했는데, BFF에서 에러를 단일 구조로 변환하고 나서 클라이언트 에러 처리 코드가 단순해졌고, 에러 상황에서 예상치 못한 화면 동작이 줄었습니다. 설계 결정의 효과를 수치나 동작 변화로 확인하는 것이 다음 결정을 더 근거 있게 만든다는 생각이 이 경험에서 남아 있습니다.
프론트엔드 서버에서 캐싱을 처음 적용한 경험이 있습니다. 메인 화면에 표시되는 추천 콘텐츠 목록이 요청마다 백엔드 API를 호출하고 있었는데, 추천 데이터가 1시간 단위로 갱신되는 구조라 매 요청마다 동일한 응답이 내려오는 상황이었습니다.
1시간 TTL로 응답을 캐싱하도록 했더니 백엔드 호출 횟수가 눈에 띄게 줄었습니다. 단, 캐시 무효화 타이밍이 실제 데이터 갱신 시점과 일치하지 않아 최대 1시간 오래된 데이터가 노출될 수 있다는 트레이드오프가 있었습니다. 이 정도 지연은 서비스 특성상 허용 가능하다는 것을 확인한 뒤 적용했습니다.
캐싱은 단순히 속도를 높이는 도구가 아니라 데이터 신선도와 성능 사이의 균형을 결정하는 자리라는 것을 이 경험에서 처음 실감했습니다. 어느 데이터에 어떤 TTL을 주는지, 무효화는 어떻게 하는지를 명시적으로 설계하지 않으면 나중에 설명하기 어려운 데이터 불일치 문제가 생길 수 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 라인 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.