[네트워크] 서버3계층(3-Tier) 면접질문

최근 CS 기술 면접 대비에 시간을 많이 쓰고 있다.
여러 자료 + 이전 강의에서 본 내용을 보면서 GPT와 모의면접을 하고 있는데, 생각보다 시간이 엄청 쓰인다.

이렇게 시간을 많이 쓰는데 면접이 끝나고, 붙으면 좋겠지만 혹여 떨어지면 지금 준비하는 이 시간이 아무것도 안한 시간이 될까봐. 
그리고 분명히 작년 11월 즈음 면접 준비를 하긴 했는데, 기억에서 날라가버렸다..
뭐라도 남겨보자는 심정과 노션에 흩어진 글을 조금이라도 정제해보자는 마음으로 이 포스팅을 시작하였다.

주로 GPT + VSFe 님의 기술면접 질문 모음집을 참고하였다.
질문과 답변 모두 신입 개발자의 입장에서 쓰여진 것이니 오류나 말이 안 맞는 것이 있을 수 있다. 혹은 더 좋은 답변이 있을 수 있다.
이를 발견하여 제게 알려주신다면 커피..라도 한잔 사드리고 싶을 것 같다. 🙇🏻‍♂️

 

• Presentation 계층 (Web Server)
• Application 계층 (Application Server)
• Database 계층 (Database Server)

- Web Server

사용자가 보려고 하는 GUI, 웹화면을 제공해주는 서버다.

 

- AP 계층

WAS라고 하며, 상품 주문, 결제, 검색 등 다양한 기능을 사용한다.

뒷단의 데이터 계층에서 데이터 조회를 한다

 

- Database Server

데이터 기입, 변경 등이 필요할 때, 작업하고 데이터들을 보관하는 계층이다.

WAS에서 쿼리를 통해 필요한 데이터를 확인한다. SQL

프론트엔드 개발자로서 3-Tier 아키텍처가 실제 개발 업무에 어떻게 영향을 미칠까요? 예를 들어 메인 페이지나, 뉴스처럼 사용자 요청이 많은 서비스는 이 구조가 어떻게 도움이 되는지, 또는 이 구조 안에서 프론트엔드가 어떤 계층과 어떻게 주로 통신하는지 중심으로 말씀해주세요.

프론트엔드 개발자인 저는 주로 사용자와 직접 맞닿아 있는 프레젠테이션 계층을 담당하고 있으며,

이 계층은 사용자 요청을 받아 애플리케이션 계층(API 서버)으로 전달하는 역할을 합니다.

예를 들어, 사용자가 네이버 뉴스에서 기사를 클릭하면, 프론트엔드는 해당 기사 ID로 API 요청을 보내고,

애플리케이션 계층은 이를 처리해 데이터 계층(DB)에서 정보를 조회한 뒤 다시 프론트엔드로 응답을 반환합니다.

 

3-Tier 구조는 이런 분리를 통해 각 계층의 책임을 명확히 하고, 한 계층의 장애가 전체 서비스로 확산되는 것을 방지할 수 있습니다.

~~처럼 트래픽이 많은 서비스에서는 특히 중요합니다. 또한, 프론트엔드는 REST API나 GraphQL을 통해

애플리케이션 계층과 효율적으로 통신하고, 그 결과를 UI에 빠르게 반영할 수 있어야 합니다.

 

프론트엔드는 사용자와 직접 맞닿은 프레젠테이션 계층이고, 주로 애플리케이션 계층의 API 서버와 통신하게 됩니다. 예를 들어, 네이버 뉴스에서 사용자가 기사를 클릭하면 프론트에서 기사 ID로 API 요청을 보내고, 애플리케이션 계층이 이 요청을 받아 DB에서 데이터를 조회한 뒤 응답을 주는 식입니다.

이렇게 계층을 분리하면 각 계층이 맡는 역할이 명확해지고, 한쪽에 문제가 생겨도 전체 서비스가 마비되는 걸 막을 수 있어요. 프론트엔드 개발자로서는 REST API나 GraphQL 같은 방식으로 애플리케이션 계층과 안정적으로 통신하는 게 중요하다고 생각합니다.

 

한 계층에 문제가 생기면 서비스에 장애가 나는건 똑같지 않나요?

전체 서비스가 아닌 해당 계층만 영향을 받도록 격리시키는 것에서 의미가 있다고 생각합니다.

예를 들어, Application 계층에서 문제가 생기면 프론트엔드는 보이지만 api 안 올 수 있겠죠. 즉 화면은 보이지만 동적 기능만 안되는 식으로 피해를 제한합니다.

Database 계층이 장애라면, Application 계층이 문제라도, 기본 에러 핸들링이나 캐시, 대체 메시지를 활용합니다.

Presentation이 문제라면 프론트만 빠르게 롤백하면 될 것입니다 ㅎㅎ

결국 장애 범위를 줄이고 빠르게 진단해서 해결을 할 수 있겠지요.

그래서 ~~처럼 대규모 트래픽이 있는 서비스에서는 이런 구조 분리가 꼭 필요하다고 생각합니다.

 

최근에는 프론트엔드에서도 사용자 경험을 위해 데이터를 캐싱하거나 prefetching하는 방식이 많이 사용되고 있는데요, 3-Tier 구조에서 데이터 계층의 응답 속도나 안정성이 프론트엔드에 미치는 영향을 설명해 주시고, 프론트엔드에서 이를 개선하거나 보완하기 위한 전략이 있다면 말해 주세요.

예를 들어, DB 응답이 지연되면 API 응답도 느려지고, 결국 프론트엔드에서 페이지 로딩이나 컴포넌트 렌더링이 느려지게 됩니다. 이런 상황이 반복되면 사용자 이탈률도 높아질 수 있기 때문에, 프론트엔드 단에서도 몇 가지 대응 전략을 고려할 수 있습니다.

 

첫 번째는 캐싱(caching) 전략입니다. 예를 들어, React Query나 SWR 같은 라이브러리를 활용해 API 응답을 일정 시간 동안 캐싱하고, 동일한 요청에 대해 서버를 다시 호출하지 않도록 할 수 있습니다. 이전 데이터를 보여주고 있기도 하구요.

두 번째는 prefetching입니다. 사용자가 마우스를 올려놓거나 특정 동작을 하기 전 미리 데이터를 받아오면,실제로 페이지 전환이나 액션이 일어났을 때 더 빠른 사용자 경험을 제공할 수 있습니다.

세 번째는 로딩 상태에 대한 graceful degradation입니다. 데이터가 늦게 오더라도 사용자에게 로딩 스켈레톤이나 캐싱된 이전 데이터를 먼저 보여줘서 사용자 입장에서 서비스가 느려졌다는 인식을 줄일 수 있습니다.

 

이처럼 3-Tier 구조에서 데이터 계층이 느리거나 불안정할 경우에도, 프론트엔드 단에서는 다양한 전략을 통해 UX를 지킬 수 있다고 생각합니다.

 

3-Tier 구조가 사용자 경험(UX)에 어떤 영향을 주는지 설명해보세요.

예를 들어, API 서버에 문제가 생겨도 Presentation 레이어 자체는 정상적으로 작동할 수 있기에, 사용자는 최소한의 정보를 받거나, 로딩 상태/에러 메시지를 확인할 수 있습니다.

또 성능 최적화가 계층별로 독립적으로 가능하기 때문에 UX 향상에 유리합니다.

프론트엔드에서는 CDN, 캐싱, prefetch 등을 통해 사용자에게 빨리 응답할 수 있습니다.

 

Presentation 계층(프론트엔드)에 캐시된 데이터가 백엔드와 불일치할 경우, 어떻게 동기화할 수 있을까요?

첫째는 캐시 만료 시간(TTL, Time To Live)을 짧게 설정하거나, 조건부 요청(Cached with validation)을 사용하는 방법입니다. 예를 들어 ETag나 Last-Modified 헤더를 활용해 서버가 변경 여부만 알려주고, 변경되었을 경우에만 새로운 데이터를 가져오는 방식입니다.

둘째는 사용자 행동 기반으로 캐시를 무효화하는 방법입니다. 예를 들어 사용자가 글을 수정하거나 삭제한 경우, 해당 항목에 대한 캐시를 직접 비워서 다시 fetch하게 하는 식입니다. React Query나 SWR 같은 라이브러리에서는 invalidateQueries나 mutate 등을 통해 쉽게 처리할 수 있어요.

셋째는 백그라운드 리패칭(Background Refetch)니다. 페이지에 진입하거나 focus 되었을 때, 자동으로 데이터를 다시 가져와서 캐시를 최신 상태로 유지하는 전략입니다. 사용자는 빠르게 캐시된 데이터를 보지만, 그 와중에 백그라운드에서 최신 데이터로 자동 동기화가 이루어집니다.

 

최근 BFF(Backend for Frontend)라는 개념이 자주 언급되는데, 3-Tier 구조와 어떤 차이가 있을까요?

BFF는 보통 3-Tier 구조의 Application Layer에 해당하는 백엔드 서버의 앞단 또는 별도로 구성되며,

실제로는 3-Tier 구조 위에 BFF 전략이 추가되는 형태라고 생각합니다.

프론트엔드 관점에서는 BFF가 있으면 서버 쪽 로직을 더 유연하게 조정할 수 있고,

API 요청 수를 줄이거나 병합하는 등의 최적화도 가능하기 때문에 사용자 경험(UX) 개선에 큰 도움이 됩니다.

실제로 BFF 내부에서는 여러 WAS 또는 마이크로서비스로 분기 요청이 발생할 수 있습니다.

이 구조는 프론트 입장에서는 API 호출을 단순화하고 성능을 높이는 장점이 있지만,

BFF 자체가 데이터를 어떻게 병합하고 에러를 핸들링할지에 대한 로직을 잘 설계해야 안정적인 UX가 유지된다고 생각합니다.

클라이언트의 요청을 최소화하는 이유는, 네트워크 성능을 높이고, 프론트 코드의 복잡도를 줄이며, UX 향상과 보안, 권한 관리 측면에서도 더 유연한 대응이 가능하기 때문입니다.

Microservices 구조와 3-Tier 아키텍처는 어떻게 다른가요? 프론트 개발자가 알아야 할 점은?

프론트엔드 개발자 입장에서 중요한 차이점은, 3-Tier 구조에서는 하나의 백엔드(WAS)만 통신 대상이 되지만,

MSA에서는 여러 백엔드 서비스를 조합해야 할 수 있다는 점입니다. 그래서 프론트에서는 BFF를 두어 서비스 간 API를 통합하거나, 각 서비스별 API 응답 구조나 호출 타이밍을 조정해야 할 필요가 생깁니다.

또, 마이크로서비스 환경에선 서로 다른 팀이 만든 API를 동시에 다루는 경우도 많기 때문에,

API 명세 관리(OpenAPI, Swagger)나 에러 표준화, 버전 관리 등도 프론트에서 고려해야 합니다.