백엔드 초보자 웹 서버 구조 질문드립니다.

Question

전반적인 웹 서비스의 구조에 대해서 이해가 되지 않는 부분이 있어서 질문드립니다. 우선 제가 이해한 RESTful한 웹 서비스의 경우를 '날짜별 체감온도 제공 사이트'라고 가정하면사용자가 홈페이지에서 날짜(2024-03-30)을 선택하고 '체감온도 보기'를 클릭한다A서버는 해당 날짜가 Request Parameter로 담긴 Get 요청을 받는다.A서버의 Servlet이 이것에 해당되는 Controller를 실행한다.A서버의 Controller는 B서버에 해당 날짜가 Request Parameter로 담긴 'Get 체감온도' 요청을 보낸다.B서버는 B서버에 해당 날짜가 Request Parameter로 담긴 'Get 체감온도' 요청을 받는다.B서버의 Servlet이 이것에 해당되는 Controller를 실행한다.B서버의 Controller가 해당되는 '체감온도 보기 Service'를 호출한다.B서버의 '체감온도 보기 Service'는 '날씨 Repository'에 날짜(2024-03-30)을 전달하여 호출한다.B서버의 '날씨 Repository'가 DB에서 해당 날짜에 해당되는 날씨 데이터를 질의를 통해 받아온다. 이후 8의 Service에게 반환한다.8의 Service가 Repository가 준 날씨 데이터의 온도, 습도, 풍속 등을 통하여 체감온도를 계산한다. 이후 6의 Controller에게 반환한다.6의 Controller는 Service가 계산한 체감온도를 json이나 xml 형태로 Servlet에게 반환한다.B의 서버의 Servlet이 A서버에게 json이나 xml 형태의 응답을 보낸다.A서버의 Controller가 B서버에서 JSON 또는 XML 형태로 받은 데이터를, 가지고 있는 HTML, CSS, JS를 통해 적절히 가공한다.A서버가 가공한 페이지를 사용자에게 전송하면 사용자는 해당날짜(2024-03-30)의 체감온도를 표시해주는 페이지를 보게 된다.저는 이렇게 DB를 액세스하고 서비스 로직을 수행하는 B서버와, 사용자에게 UI를 제공하는 A서버로 나뉘고 API를 통해 A서버가 B서버에서 데이터를 받아오는 것이 RESTful한 웹서비스의 구조라고 이해하였습니다.첫째는, 명확한 용어를 알고 싶습니다. 어느 블로그에서는 A를 프론트 서버, B를 백엔드서버 라고 부르는 것 같구요, 또 B를 API서버라고 부르는 것도 같습니다. 또 다른 곳에서는 A를 웹서버, B를 WAS라고 부르기도 하는 것 같구요...둘째는 이 경우 각 서버의 역할에 대하여 궁금합니다. A서버가 만일 페이지를 그려주는 역할만 하게 된다면, 로그인과 같은 기능은 B서버의 몫이 되는 걸까요? 만약 그렇다면, 토큰이나 세션도 A를 거쳐 B에서 담당하게 되는 것일까요?셋째는, 이 경우 그렇다면 흔히 말하는 '프론트엔드 개발자'와 '백엔드 개발자'의 업무 범위는 어떻게 되는 것일까요? 프론트엔드 개발자가 A서버의 전반적인 역할을 맡게 되는 것일까요 아니면 프론트엔드 개발자는 철저히 HTML, CSS, JS 파일의 작성만 맡고 A서버의 컨트롤러 같은 부분의 개발도 백엔드 개발자가 담당할까요?

AskeTeddy · Accepted Answer

A 를 SSR 프론트 서버라고 볼 수 있고, B 를 백엔드 API 서버라고 볼 수 있습니다.WAS 는 Web Application Server 의 약자입니다. 웹 서버에 어플리케이션을 결합한 형태입니다. (A, B 둘 다 WAS 에 해당합니다)A, B 를 나누는 이유는SEO(검색엔진 최적화): 구글이나 네이버 등에서 검색할 때의 API 캐싱 관련 정책의 유리함을 A 에게 주기 위함코어 도메인 분리: 비지니스 모델 중 리스크가 크거나, 매우 복잡한 서비스를 B에게 몰아주어 분리함등이 있습니다.프론트엔드의 고객은 사용자, 백엔드의 고객은 프론트엔드라고 생각하시면 좋을 듯합니다.A 는 렌더링, API 캐싱, SEO 전략 등을 가져갑니다. B 는 비지니스 모델 관련되어 복잡성 관리, 성능 최적화 등을 가져갑니다.A 는 프론트엔드 개발자가 SSR 을 하는 경우에 필요하며, 보통의 경우 CSR 를 통해서 js 모듈을 따로 만들어 관리합니다(상태 관리 방식: MVVM, Flux Pattern)토큰의 경우 state less 를 지켜야합니다. (아닌 경우도 있긴한데 논외, opaque token) 두 서버 모두 인가에 대한 책임을 가진 서버에게 사전 호출을 통해 인가 받습니다. AB 두 서버 모두 인증/인가의 책임을 가지지 않는 것이 원칙입니다.(IDP/Resource Server 사용 혹은 OAuth 방식 사용)물론 두 서버에서 받은 verified 된 토큰의 페이로드를 믿고 쓰기 때문에 토큰 라이브러리는 각자 가져도 됩니다.업무 범위는 상황에 따라서 달라질 수 있습니다.프론트엔드 개발자는 '실제 고객의 편리성'을 관점으로 개발합니다. 대략 UX 기반의 화면 구성, 화면 구성 로직 구성 및 최적화 등이 있습니다.백엔드 개발자는 '비지니스 이해관계자의 편리성'을 관점으로 개발합니다 업무 범위는 API 설계 및 개발, API 문서화 등이 있습니다백엔드 API 의 고객은 실질적으로 프론트엔드 개발자이기 때문에, 둘 간의 의사소통이 반드시 필요합니다.또한 프론트엔드 개발자의 고객은 '최종 소비자'이므로 이를 분석하며 대응하는 CX 분들이나 디자이너와의 의사소통이 중요합니다.아래는 개인적인 의견입니다만약 프론트엔드에서 해당 API 의 변경을 언급하면, 백엔드에서는 최대한 도와주는 것이 좋으며. 결과적으로 Graphql 같은 방식을 제공하는 것이 좋다고 생각되네요feat. AB 시스템을 분리하는 방식으로 BFF(BackEnd For FrontEnd) 라는 패턴도 있습니다

백엔드 초보자 웹 서버 구조 질문드립니다.

1개의 답변

Q&A 목록