서버-클라이언트 질문이 있습니다.

Question

[글을 읽으시기 전에]저는 Spring framework 사용해서 프로젝트 하나 수행하는 중입니다.다만 선생님들에 비해서 초보 수준이라 질문 수준이 다소 낮을 수 있다는 점 알아주셨으면 좋겠습니다 ㅠㅠ개발 관련 지식이 얕아서 설명드리는 것에 부정확한 정보가 있을수도 있다는 점. 미리 양해 부탁드립니다. (__)그리고, 여기 OKKY를 오늘 알게 되어서 커뮤니티 문화나 기류를 잘 모릅니다. 그 문화에 저해되는 글이면 삭제하도록 할테니 알려주시면 감사하겠습니다.제 질문이 많기도 하고 이해하시기 어려우실 수 있습니다. ㅠㅠ 답변하기 곤란하시다면 관련 책을 추천해주시면 감사하겠습니다.[과거 프로젝트 진행했던 방식]제가 이전에 한 번 Spring framework 사용해서 프로젝트를 진행했을 때는 html 파일(프론트엔드)에서 아래와 같은 방식으로 백엔드 컨트롤러에 요청을 했습니다.

' method="POST">해당 요청은 다음과 같은 방식으로 컨트롤러에 mapping하고, 요청을 처리했습니다.@RequestMapping("/main/a.do")public ModelAndView handleRequest( 매개변수들 ) throws Exception {// 요청사항 처리하는 부분 구현return ModelAndView 객체}즉, 프론트엔드에서 백엔드로 무언가를 요청할 때 폼 태그 방식으로 요청하고 해당 uri를 담당하는 controller에서 기능을 구현하여 동작 결과를 return 하는 방식이었는데요.[궁금한 점 1: API를 사용하는 이유]어느 날 개발 관련 유튜브를 보다가, 클라이언트(프론트)와 서버(백엔드) 간 소통을 API를 사용해서 한다고 합니다.과거 제가 진행한 프로젝트는 API를 사용하지 않는 서버사이드렌더링 방식이더군요. 서버에서 HTML, JSP 페이지를 만들어서 클라이언트에게 보내주었기 때문입니다.아무튼, 저도 이번에 한 번 API를 사용해서 프론트와 백엔드의 요청과 응답을 진행하고 싶은데,명분이 없달까요? chat GPT 한테 "폼 태그 방식"으로 백엔드에게 무언가를 요청하는 대신 "API 방식"으로 백엔드에게 무언가를 요청하는게 무엇이 더 좋은지 물어보니클라이언트와 서버가 명확하게 분리되어 있다. -> 폼 태그 방식도 명확하게 분리된거 아닌가요?비동기 데이터 처리와 UI 업데이트가 가능하다 -> 그건 클라이언트 사이드 렌더링의 장점 아닌가요? ( 제가 궁금한건 서버 사이드 렌더링 시 API를 사용하여 클라이언트와 백엔드의 소통을 구현하고자 하는건데... 이 답변은 API의 장점은 아닌 것 같습니다.)모바일 및 외부 클라이언트 지원이 가능하다 -> 이건 폼 태그 방식으로도 가능하지 않나요.. 뭔가 피부에 와닿게 얘기해주지 않아서 ( 제가 개발 지식이 얕아서 ) 체감이 되지 않습니다. ㅠㅠ질문 1. 혹시 API를 사용해서 클라이언트와 백엔드 소통을 구현하신 선생님들은 왜 폼태그 방식을 사용하지 않는지 구체적인 이유가 있으실까요? (+혹시.. 가능하시다면... CSR과 SSR 사례도 분류해서 알려주실 수 있나요...) [궁금한 점 2: SSR에서 API 방식으로 프론트엔드와 백엔드가 소통할 때 동작 흐름]질문 1을 해결하려고 chat GPT한테 이것 저것 물어보니, 대강 제가 이해한 흐름은 다음과 같습니다.다음은 API를 활용한 서버사이드 렌더링 동작 과정입니다.상황: 사용자가 댓글을 작성하고 "게시" 버튼을 눌렀을 때클라이언트 - SSR 서버에 사용자가 작성한 댓글 데이터를 포함한 HTTP 요청을 보냅니다.SSR 서버 - API 서버의 엔드포인트에 HTTP 요청을 보냅니다.API 서버 - 요청받은 데이터를 처리 한 후 JSON 등의 포맷으로 반환합니다. - 근데 왜 여기서 GPT가 API 서버라고 명칭했는지 모르겠네요. API는 규약같은거지 서버는 아니지 않나요? 그냥 메인 서버를 대체해서 한 말일까요..SSR 서버 - API 서버로부터 받은 데이터를 바탕으로 HTML 페이지를 렌더링합니다. 그 후 클라이언트에게 반환합니다.클라이언트 - SSR 서버로부터 반환된 HTML을 브라우저에 렌더링하여 사용자에게 보여줍니다.여기까지 들으니까, 더 이해가 안돼서요. chat GPT 한테 더 구체적으로 설명해달라고 할 때마다 저 동작과정이 미세하게 자꾸 바뀝니다. ㅋㅋㅋ ㅠㅠ질문 2. 서버사이드렌더링 방식에서 API로 프론트엔드와 백엔드가 호출했을 때 이 동작 과정이 맞나요?질문 3. 다른 분들 Spring 으로 개발하실 때 원래 저렇게 SSR 서버, API 서버 두 개의 서버를 두나요?[마무리]쓰다보니 글이 길어졌습니다. 제가 GPT를 너무 의존한 것 같아요 ㅠㅠ 차라리 책으로 공부하는게 훨씬 도움이 될 것 같습니다.답변 남겨주시면 감사한 마음으로 꼼꼼히 읽겠습니다. (+ 책 추천해주시면 감사하겠습니다!)긴 글 읽어주셔서 감사합니다!

RWB · Answer

답변드리기 이전에, 문제를 해결하고자 노력한 과정에 찬사를 보냅니다.질문 1. 혹시 API를 사용해서 클라이언트와 백엔드 소통을 구현하신 선생님들은 왜 폼태그 방식을 사용하지 않는지 구체적인 이유가 있으실까요? (&#43;혹시.. 가능하시다면... CSR과 SSR 사례도 분류해서 알려주실 수 있나요...)우선 현 개발 트렌드는 프론트엔드 / 백엔드를 분리하는 방향으로 가고 있습니다.각 영역별로 구분을 두고, 책임소재를 분리, 명확하게 나눔으로써 유지보수성은 물론, 체계적인 서비스를 구축하는 밑바탕이 됩니다.아마 읽으시면사 &#34;구분하면 관리포인트가 늘어나는 데, 굳이 나눠야 하나요?&#34; 라는 생각이 드실 수도 있겠습니다.각 모듈의 응집도가 높을 수록, 코드의 영향도 관리 및 재사용성이 높아집니다.서로의 코드가 깊게 엮여있을 수록, 한 쪽을 바꿨을 때, 다른 한 쪽도 영향을 받기 쉬우며, 다른 페이지에 비슷한 요구사항이 있음에도 별도의 로직을 다시 작성(소위 복붙)할 확률이 높습니다.이러한응집도가 높아 모듈화가 잘 된 구조는 자연스레 백엔드에서 API를 제공하고, 독립된 프론트엔드에서 이를 호출해 사용하는 형태로 사용하기 용이합니다.또한, API의 구현 수준에 따라, 여러 서비스에서 API를 재사용하기도 좋다는 장점이 있습니다. (웹, 모바일, 인증 서버 등)즉, API 서버를 하나만 두고, 플랫폼에 따라 UI만 다르고 동일한 서비스를 제공하는 서비스에 일괄적으로 적용할 수 있다는 의미입니다.말씀하신 폼태그를 구현하지 않는 이유는, 1차적으로 페이지 이동이 강제된다는 문제가 있습니다.폼에 대상 URL, 메서드를 지정하고, 값을 입력하여 submit 수행입력한 파라미터를 담아, 대상 URL로 이동해당 페이지에서 로직 수행수행 결과를 파라미터로 담아, 뷰 모델을 통해 이동페이지 이동이라는 특징으로 인해, 반드시 동기적으로 동작하게 됩니다. 이 때, 사용자의 데이터 흐름을 유지하도록 부가적인 로직을 구현해보셨을 겁니다.API를 활용한다면, 서비스의 흐름에 영향을 주지 않고, 비동기로 동작하여, 데이터를 받아, 페이지의 값을 적절히 교체해줄 수 있다는 장점이 있습니다.새로고침이나 깜빡임 없이 데이터가 주기적으로 변하는 기초적인 원리입니다.CSR과 SSR의 사례는 크게 의미가 없습니다. 영역만 다를 뿐, 각 영역의 언어 방식대로 API를 호출하고, 받은 데이터를 활용합니다. JAVA라면 Jsoup을 쓸 것이고, 웹이라면 fetch나 axios 같은 걸 쓰는 식이죠.질문 2. 서버사이드렌더링 방식에서 API로 프론트엔드와 백엔드가 호출했을 때 이 동작 과정이 맞나요?클라이언트를 넓게 보면 CSR, SSR로 나눌 수 있습니다. CSR은 브라우저의 영역. SSR은 뷰를 렌더링하는 서버의 영역입니다. React는 Node.js를 갖고, JSP는 JAVA라는 렌더링 서버를 갖는 것이 그 예입니다.API 서버는, HTTP 요청을 받아 데이터(JSON 등)을 반환해주는 API를 제공해주는 주체 서버를 의미합니다. 그냥 뭉뚱그려 백엔드라고 하면 얼추 일맥상통합니다.질문 1의 후미를 다시 한 번 언급해드립니다.CSR과 SSR의 사례는 크게 의미가 없습니다. 영역만 다를 뿐, 각 영역의 언어 방식대로 API를 호출하고, 받은 데이터를 활용합니다. JAVA라면 Jsoup을 쓸 것이고, 웹이라면 fetch나 axios 같은 걸 쓰는 식이죠.클라이언트(CSR / SSR)에서 API 호출API 서버에서 HTTP 요청 수신지정된 로직 수행 및 데이터 반환클라이언트가 응답을 받아, 데이터를 가공함뷰에 표시함전체적인 플로우는 위와 같습니다. 깊게 들어가면 SSR 서버로 프록시를 태워 날린다던가 하는 개념도 있는데, 지금은 신경쓰지 않으셔도 괜찮습니다.질문 3. 다른 분들 Spring 으로 개발하실 때 원래 저렇게 SSR 서버, API 서버 두 개의 서버를 두나요?회사 따라 다르고, 상황 따라 다릅니다.누군가는 Spring에 View 모델까지 지정해서 .do 같은 페이지를 만들어서 하나로 만들거고, 누군가는 프론트 / 백 분리해서 관리하겠죠.API 서버는 정의된 절차에 따라 HTTP 요청만 받으면, 응답해줄 뿐입니다.요청지가 브라우저든 SSR 서버든, 응용프로그램이든 상관없습니다.프론트에 SSR 프레임워크(Next.js 등)을 쓴다면 SSR 서버도 필요할 것이고, 그게 아니라 전통적인 HTML, JS 활용한다면 SSR 서버는 필요 없을겁니다.사용하려는 스택과 아키텍쳐에 따라 달라질 수 있습니다.서두에 언급했다시피, 일반적으론 프론트엔드 / 백엔드를 분리하는 쪽이 트렌트입니다.

Henry7 · Answer

spa 의 탄생과 유행 이후 시작된 이야기입니다. 클라이언트가 분리되어 있단 것은 심지어 별개의 소스 저장소로 분리되어 별개의 프로젝트가 되어 별개의 장비에서 돌아간단 의미이기도 합니다. 서버의 ip와 도메인명도 달라요. 합칠 수도 있지만요.이러한 spa 시대를 지나며 spa 와 csr의 단점을 해결하고자 나온 것이 spa 와 유사한 기술과 구조를 가지면서 ssr 이 되게 만드는 기술이며, 대표적인 것이 next.js 입니다.답글만 보고 다 이해하기는 힘듭니다. 직접 개발해봐야 이해가 갈 수도 있고요.구글 검색을 더 해보시거나, 유튜브 등 동영상을 보시거나 서점에서 프런트엔드 관련 서적 관련 부분만 후딱 보시면 도움이 되실 수도 있습니다.

서버-클라이언트 질문이 있습니다.

2개의 답변

기술 목록