우문현답
愚 問 賢 答
회사별 면접직군별진행 방식
    홈›회사별›라인›프론트엔드›질문 상세
    問
    라라인프론트엔드직무 역량2026년 출제

    프론트엔드 서버 개발에서의 설계 원칙이나 패턴 중, 본인이 중요하게 생각하는 부분은 무엇인지 설명해 주세요.

    답변 미리보기

    프론트엔드 서버 개발에서 가장 중요하게 생각하는 설계 원칙은 클라이언트와 백엔드의 결합을 최소화하는 것입니다. 클라이언트가 여러 API를 직접 호출하면 화면…

    예상 답변 시간
    60~90초
    예상 꼬리질문
    3회
    난이도
    난이도 중상
    출제 빈도
    높음
    INTERVIEWER'S INTENT · 면접관의 의도

    이 질문, 네 갈래로 뜯어봅니다.

    면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

    問
    01
    본인 시각이 또렷한가?
    분리·재사용·일관 결 중 본인이 의식한 결이 답에 보입니다. 일반론으로만 답하면 깊이가 옅은 자리입니다.
    骨
    02
    원칙 결을 또렷이 짚는가?
    컴포넌트·상태·합의 결로 본인이 가른 흔적이 답에서 드러나는 결이 통합니다. 매끈하게만 끝나는 답은 외워 온 결로 들립니다.
    語
    03
    본인 사례로 닫는가?
    추상 다짐이 아니라 본인이 실제로 한 결을 짚는 답이 자주 등장합니다. 매끈하게만 끝나는 답은 외워 온 결로 들립니다.
    本
    04
    측정 가능한 결과로 닫는가?
    결함·재작업·시간 결로 본인이 결과를 본 흔적이 답에 보입니다. 수치 없이 좋아진다는 답은 검증이 옅은 결입니다.
    말로 해봐야 는다
    읽는 것과 말하는 건 다릅니다.
    이 질문, 소리 내어 답해 볼까요?
    라인 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.
    음성으로 답해보기
    프론트엔드 서버 BFF 패턴 설계 결약 90초사전 지표 정의와 네트워크·에러 일관화로 효과 검증 결TTL 기반 캐싱으로 호출 감소와 데이터 신선도 트레이드오프 균형 설계 결
    예시 답변 1
    약 90초

    프론트엔드 서버 BFF 패턴 설계 결

    프론트엔드 서버 개발에서 가장 중요하게 생각하는 설계 원칙은 클라이언트와 백엔드의 결합을 최소화하는 것입니다. 클라이언트가 여러 API를 직접 호출하면 화면 변경이 백엔드 의존성에 묶이게 됩니다. BFF(Backend for Frontend) 패턴을 학습하면서, 클라이언트에 최적화된 응답을 만드는 중간 레이어가 화면 요구사항과 데이터 소스를 분리해준다는 것을 이해했습니다.

    캐싱 전략도 프론트엔드 서버에서 중요한데, 자주 바뀌지 않는 데이터는 서버에서 캐싱해 백엔드 부하를 줄이고 응답 속도를 높였습니다. 에러 처리 일관성도 중요하게 생각하는데, 백엔드 에러를 클라이언트가 그대로 받으면 사용자에게 노출되는 메시지가 예측 불가능해집니다. 이 경험에서 프론트엔드 서버는 UI 로직의 연장이면서 동시에 보안과 캐싱을 담당하는 레이어라는 결을 얻었습니다.

    이 결의 특징
    BFF(Backend for Frontend) 패턴을 학습하면서, 클라이언트에 최적화된 응답을 만드는 중간 레이어가 화면 요구사항과 데이터 소스를 분리해준다는 것을 이해했습니다
    이 결이 통하는 자리
    프론트엔드 서버 BFF 패턴 설계 결이 있습니다
    예시 답변 2

    사전 지표 정의와 네트워크·에러 일관화로 효과 검증 결

    프론트엔드 서버 BFF 레이어를 도입하기 전과 후를 비교할 수 있는 지표를 처음부터 정해두지 않아서 효과를 설명하기 어려웠습니다. 이후로는 변경 전에 측정할 것을 먼저 정하는 습관이 생겼습니다.

    BFF를 도입하면서 클라이언트가 필요로 하는 데이터만 조합해 응답하는 방식으로 바꾸자, 여러 개의 API를 순차 호출하던 화면에서 응답 수신 완료까지 걸리는 시간이 줄었습니다. 네트워크 왕복 횟수가 3번에서 1번으로 줄어든 것이 직접적인 원인이었습니다.

    에러 처리 일관성도 개선됐습니다. 이전에는 각 API의 에러 구조가 달라서 클라이언트가 경우마다 다르게 처리해야 했는데, BFF에서 에러를 단일 구조로 변환하고 나서 클라이언트 에러 처리 코드가 단순해졌고, 에러 상황에서 예상치 못한 화면 동작이 줄었습니다. 설계 결정의 효과를 수치나 동작 변화로 확인하는 것이 다음 결정을 더 근거 있게 만든다는 생각이 이 경험에서 남아 있습니다.

    이 결의 특징
    BFF를 도입하면서 클라이언트가 필요로 하는 데이터만 조합해 응답하는 방식으로 바꾸자, 여러 개의 API를 순차 호출하던 화면에서 응답 수신 완료까지 걸리는 시간이 줄었습니다
    이 결이 통하는 자리
    사전 지표 정의와 네트워크·에러 일관화로 효과 검증 결이 있습니다
    예시 답변 3

    TTL 기반 캐싱으로 호출 감소와 데이터 신선도 트레이드오프 균형 설계 결

    프론트엔드 서버에서 캐싱을 처음 적용한 경험이 있습니다. 메인 화면에 표시되는 추천 콘텐츠 목록이 요청마다 백엔드 API를 호출하고 있었는데, 추천 데이터가 1시간 단위로 갱신되는 구조라 매 요청마다 동일한 응답이 내려오는 상황이었습니다.

    1시간 TTL로 응답을 캐싱하도록 했더니 백엔드 호출 횟수가 눈에 띄게 줄었습니다. 단, 캐시 무효화 타이밍이 실제 데이터 갱신 시점과 일치하지 않아 최대 1시간 오래된 데이터가 노출될 수 있다는 트레이드오프가 있었습니다. 이 정도 지연은 서비스 특성상 허용 가능하다는 것을 확인한 뒤 적용했습니다.

    캐싱은 단순히 속도를 높이는 도구가 아니라 데이터 신선도와 성능 사이의 균형을 결정하는 자리라는 것을 이 경험에서 처음 실감했습니다. 어느 데이터에 어떤 TTL을 주는지, 무효화는 어떻게 하는지를 명시적으로 설계하지 않으면 나중에 설명하기 어려운 데이터 불일치 문제가 생길 수 있습니다.

    이 결의 특징
    메인 화면에 표시되는 추천 콘텐츠 목록이 요청마다 백엔드 API를 호출하고 있었는데, 추천 데이터가 1시간 단위로 갱신되는 구조라 매 요청마다 동일한 응답이 내려오는 상황이었습니다
    이 결이 통하는 자리
    TTL 기반 캐싱으로 호출 감소와 데이터 신선도 트레이드오프 균형 설계 결이 있습니다
    !
    위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.
    ✕자주 빠지는 자리

    같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

    • ✕떨어뜨린 옵션이 1개라도 있는가? "이게 답이었어요"만으로는 의사결정이 아니라 그냥 선택입니다.
    • ✕선택 기준이 그 프로젝트에 한정되는가? "성능이 좋아서"는 일반론, "우리 트래픽이 X 패턴이라서"가 본인의 답입니다.
    • ✕결과 숫자 1개를 정확히 말할 수 있는가? P95·QPS·적중률 — 무엇이든 1개. 숫자가 없으면 직감으로 한 일처럼 들리기 쉽습니다.
    • ✕지금 다시 한다면 어떻게 할지 답할 수 있는가? "잘했다"보다 "이건 다르게 했을 것 같다"가 더 깊은 인상을 남깁니다.
    ▶이어질 꼬리질문

    진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

    壹본인이 가장 무게 두는 결은 어디인가요?
    貳원칙 결을 어떻게 잡으시나요?
    參결과를 어떤 결로 측정하시나요?
    이제, 직접 답해볼 차례예요.
    눈으로 읽은 답은 면접장에서 나오지 않아요. 라인 면접관과 이 질문으로 한 번 대화해 보세요.
    이 질문으로 모의면접 해보기
    또는, 다음 질문으로

    같은 흐름에서 자주 이어지는 질문들이에요.

    토스 · 프론트엔드
    사일로 구조에서 Product Owner, Designer, Server Developer와 협업할 때 프론트엔드 개발자로서 본인이 가장 중요하게 생각하는 역할은 무엇인가요?
    이 질문 보기
    쿠팡 · 백엔드
    시스템 아키텍처를 설계할 때 어떤 원칙이나 디자인 패턴을 가장 중요하게 생각하나요?
    이 질문 보기
    CJ올리브영 · 프론트엔드
    프론트엔드 아키텍처 설계 경험이 있다면, 어떤 아키텍처를 사용했고 그 이유는 무엇인지 설명해 주세요.
    이 질문 보기
    토스 · 프론트엔드
    프론트엔드 웹 서비스의 성숙한 성장에 기여하기 위해 어떤 접근 방식을 취할 것인지 설명해 주세요.
    이 질문 보기
    안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히
    개인정보처리방침이용약관문의
    © 2026 우문현답. All rights reserved.
    이 페이지 목차
    01면접관의 의도02답변의 결03실수·꼬리질문04관련 질문
    말로 해봐야 는다
    이 질문, 라인 면접관과
    음성으로 답해볼까요?
    모의면접 해보기
    첫 회 무료 · 종료 즉시 음성 폐기