SSR과 CSR의 차이 그리고 프론트엔드와 백엔드 간 소통 시 API를 사용하는 이유

지난 3일간 어떻게 지냈나요?

[훌륭한 디자인 툴: Vercel v0 dev를 발견하고 마주치게 된 고난과 역경]

 

클라이언트 계층 부분 구현을 하고자, 프롬프트에 명령어만 입력하면 자동으로 웹 페이지 디자인을 제안하고 코드도 알려주는 훌륭한 Vercel v0 dev 툴을 알아냈습니다.

 

실제로 프롬프트에 "로그인 페이지 만들어줘" 등 많은 명령어를 입력해보며 시도했지만, 난관에 부딪혔습니다.

 

그에 대해서 소개해보겠습니다.

 

v0에서는 React 버전 코드와 html 버전 코드 둘 다 제공합니다.

 

저는 과거 프로젝트 진행할 때 프론트엔드와 백엔드를 폼 기반 요청으로 상호작용 했었습니다.

<form action='<c:url value="/main/signon.do"/>' method="POST">

 

이와 같은 방식으로 HTML 파일에서 서버에 HTTP 요청을 보냈습니다.

 

여담이 길어졌네요. 결론은 "그래서 저는 React보다 HTML 코드가 더 익숙합니다. 그리고 더 선호합니다." 입니다.

 

그런데 v0에서 제공하는 HTML 코드를 이클립스에서 실행시켜보니 v0 캔버스에서 확인한 디자인과 전혀 다른 UI가 나타나는 겁니다.

 

알아보니 캔버스에서 확인한 UI와 동일한 UI를 HTML 코드로 구현하기 위해선, 수동으로 라이브러리를 import 해야 한다는 것입니다.

 

React 코드를 사용하면, 이런 저런 라이브러리들을 수동으로 import 하지 않아도 된다고 하네요.

 

"그래. 그럼 React를 직접 다뤄보자" 마음을 먹었습니다.

 

유튜브 동영상을 보고 npm 명령어를 학습하는데 양이 굉장히 방대하고 배울 것도 많아 보였습니다. 이런식으로 클라이언트 계층에 너무 많은 시간을 할애하다간 서버계층 구현은 접근조차 못할 것 같았습니다. 😥

 

결국 클라이언트 계층은 같이 프로젝트를 함께 할 팀원을 구하거나, 크몽에서 외주를 구해 작업을 하기로 결정하였답니다.

 

그래서 이번 포스트는 클라이언트 계층 구현 부분은 건너뛰고 API 게이트웨이 구현으로 게시글을 작성하겠습니다.

 

[ API 게이트웨이를 사용하기 위한 명분을 찾아서]

 

대다수의 많은 개발자들은 프론트엔드와 백엔드 간 상호작용을 폼 요청 방식으로 구현하지 않습니다.

 

대신 프론트엔드와 백엔드 간 상호작용을 API 방식으로 구현합니다.

 

그래서 저도 WorkSphere 360 을 API 방식을 사용해서 프론트엔드와 백엔드를 상호작용하고 싶었습니다.

 

그런데 말입니다. 뭔가 기술을 사용하려면 그에 맞는 명분이랄까요. 폼 요청 방식보다 API 방식이 훨씬 더 성능이 뛰어난다던가 하는 이유가 필요하지 않겠습니까. 그걸 못찾았습니다. 사실 정확히는 대강 무슨 말인지 알겠지만 피부로 못 느꼈습니다. 여기저기 찾아봐도 추상적인 내용들로 가득해서 왜 사람들이 API를 사용하는지 체감이 잘 안됐습니다. 그래서 API를 사용하는 것이 폼 태그 방식보다 훨씬 좋은 이유를 체감하기 위해 이 이유를 찾느라 하루를 통으로 보냈답니다 하하.

 

[갑자기 SSR, CSR에 빠지게 된 계기]

 

그래서 폼 요청 방식에 비해 API 방식이 훨씬 더 우수한 점을 알고 싶었습니다.

 

그런데 말이죠. 저는 지금 이 요청 방식을 "폼 요청 방식" 으로 지칭하고 있지 않습니까?

 

사실 이 포스트를 작성하기 이전에는 이 방식을 무슨 방식으로 명명해야 하는지 몰랐습니다. 그래서 이 요청 방식을 뭐라고 불러야 할지 궁금해서 구글링을 했지만, 원하는 답변이 없었습니다.

 

폼 요청 방식에 비해 API 방식이 훨씬 더 우수한 점을 알고 싶다면, 이 "폼 요청 방식" 이라는 명칭? 지칭?부터 알아내야 했던거죠.

 

구글에 저의 코드와 함께 "해당 방법보다 API 방식이 우수한 이유" 라고 검색할 수도 없는 노릇이었구요. 

 

그래서 chat GPT에게 물어봤습니다. 

 

이렇게 답변하더군요.

당신이 사용한 코드를 분석해보면, <form> 태그를 통해 데이터를 서버에 요청하고 있습니다. 이 방법은 전통적인 웹 애플리케이션에서 사용되며, 흔히 "서버 렌더링(Server-side Rendering)" 또는 "폼 기반 요청(Form-based Request)" 방식으로 불립니다.

 

아하! 그래요! 제가 사용한 방법은 "폼 요청 방식" 이군요. 근데 잠깐... 서버 사이드 렌더링은 뭐죠? (지금 생각하니 부끄럽네요)

 

이러한 계기로 저는 서버 사이드 렌더링과 클라이언트 사이드 렌더링에 빠지게 되었습니다.

 

여러분.. 지식이 넓고 깊지 않으면 저처럼 본질에 집중하지 못하고 산으로 빠지게 됩니다. 다들 CS 지식 열심히 챙깁시다.

 

아무튼 그렇게 저는 클라이언트 사이드 렌더링과 서버 사이드 렌더링에 대해서 공부했습니다. ㅋㅋㅋ

 

부끄럽지만 제가 정리하고 알게 된 내용을 아래 사진으로 첨부하겠습니다.

 

 

---

 

 

그리고 여기서 한마디 더 덧붙이자면, SSR 방식은 클라이언트에서 새로운 동작을 서버에게 요청할 때마다 서버는 내용물이 채워진 HTML을 새로 만들고 보내줘야 하기 때문에 (클라이언트 입장에서는) 화면을 새로고침 하듯이, 요청하기 이전 브라우저 환경과 요청하기 이후 브라우저 환경이 연속적이지 않는다는 점이 있구요.

 

CSR 방식은 클라이언트에서 새로운 동작을 서버에게 요청할 때마다 서버는 해당 데이터만 보내주고 클라이언트에서 알아서 해당 부분만 조립해주기 때문에 클라이언트 입장에서 화면을 새로고침하는 듯한 느낌도 주지 않고 요청 이전 브라우저 환경과 요청 이후 브라우저 환경이 연속적이라는 특징이 있죠.

 

호기심에 못이겨 (호기심도 있긴한데, 사실은 이해하지 못해서 마구마구 알아봤습니다. 아래 적힌 일련의 과정들을 학습하면 깨우침이 있을까 하고요. 적다보니 이게 호기심인걸까요? 후후)

 

1. SSR 방식과 CSR 방식의 장단점

2. CSR과 SEO 문제

3. API를 사용한 SSR 방식의 코드 및 동작 과정

4. API를 사용한 CSR 방식의 코드 및 동작 과정

 

등을 알아봤지만... 이 포스트는 API 게이트웨이 글을 적는 포스트니까.. 너무 글 내용이 산으로 가는 느낌이라 여기까지만 설명드리겠습니다.

 

이걸 공부하고 나니 알았습니다. 아! 내가 이전까지 작업했던 프로젝트는 전부 서버 사이드 렌더링 방식이었구나.

 

자. 이제 서버 사이드 렌더링과 클라이언트 사이드 렌더링에 대해서 알아보았으니. 원래 본질적으로 궁금해했던

 

"폼 요청 방식보다 API 방식이 더 우수한 점"에 대해서 알아가면 되겠죠?

 

[API 방식이 왜 폼 요청 방식보다 우수한지 찾는 여정]

 

그런데 제가 찾는 API 방식으로 코드를 구현하는 예제마다, 전부 다 CSR 예제밖에 없는겁니다.

 

물론 큰 상관은 없지만, 저는 SSR 경우에서 API를 구현하는 경우와 폼 요청 방식을 동일 선상에 두고 코드를 보고 싶었거든요.

 

왜냐하면 폼 요청 방식도 SSR 이니까, 다른 외부 조건을 동일시하고 싶었습니다. 그래야 성능적인 측면에서 비교가 수월해서요.

 

그래서 SSR에서 API를 구현하는 경우 동작 과정을 알아왔습니다.

 

1. 클라이언트에서 서버로 API 요청을 보냅니다.

2. 서버는 그 요청을 처리하기 위해 또 따른 API를 사용하거나 아니면 자체적으로 처리합니다.

3. 서버는 (필요할 경우)요청에 걸맞는 데이터를 가지고와서 새로운 HTML 페이지를 렌더링합니다. (여기서 렌더링은 HTML 내 Contents를 채우는 행위를 의미합니다.)

4. 서버는 클라이언트에게 이 HTML 페이지를 전송합니다.

5. 클라이언트는 이 HTML 페이지를 렌더링합니다. (여기서 렌더링은 HTML 마크업 언어를 사람이 보기 쉽게 버튼이나 체크박스 등으로 바꾸는 행위를 의미합니다.)

 

근데 있잖아요. 오히려 폼 요청 방식보다 API 방식이 더 복잡한 것 같지 않습니까? 제가 SSR에서 폼 요청 방식으로 구현하는 경우 동작 과정을 아래에 적어보겠습니다.

 

1. 클라이언트에서 HTML 폼에 있는 URL 요청을 서버에게 보냅니다.

2. 서버는 이 요청을 처리합니다.

3. 서버는 (필요할 경우)새 HTML 페이지를 렌더링합니다. (여기서 렌더링은..? HTML 내에 Contents를 채우는 행위를 의미합니다.)

4. 서버는 클라이언트에게 이 HTML 페이지를 전송합니다.

5. 클라이언트는 이 HTML 페이지를 렌더링합니다. (여기서 렌더링은..? HTML 마크업 언어를 사람이 보기 쉽게 버튼이나 체크박스 등으로 바꾸는 행위를 의미합니다.)

 

그리고 회사마다 다르겠지만, SSR을 구현하는 회사에서는

 

- SSR 서버: 백엔드에서 처리한 결과물을 바탕으로 HTML의 내용물을 채우는 서버

- API 서버: 프론트엔드와 백엔드가 상호작용할 때 API 말고, SSR/CSR에서 보낸 HTTP 요청을 수신하고 요청을 처리한 후 다시 JSON과 같은 데이터로 반환해주는 API를 제공해주는 주체 서버 입니다. 

 

이렇게 총 두 개의 서버를 운영하는 회사도 있다고 합니다. 이거는 회사 바이 회사니깐 참고만 해주십쇼. 그리고 저 두 서버가 소통할때는 또 다른 소통 API를 둔다고 합니다. 

 

딱 봐도 폼 요청 방식이 더 간단해 보이지 않나요? 왜 API 방식이 더 좋은거죠? 막상 적어놓고 보니까 더 API 방식을 쓰는 이유를 모르겠습니다 ㅠㅠ

 

근데 아마 여러분들.. 이쯤되면 아마 궁금하실 것 같습니다.

 

"그래서 당신이 알아본 API 방식이 폼 요청 보다 좋은 이유가 뭐야? 얼마나 추상적이길래 그래? 들어나 보자." 아마 이렇게 생각하시는 분들도 계실 것 같습니다.

 

제가 찾아본 (제 피셜) 추상적인 이유는 다음과 같습니다.

 

• 유연성과 재사용성 -> 이건 폼 요청 방식도 유연성과 재사용성이 있지 않나요?
• 클라이언트와 서버의 분리 -> 폼 요청 방식과 API 요청 방식을 위에서 알아봤는데, 둘의 동작 과정이 같은 것 같습니다..(딱히 분리되는지 모..르..겠..)
• 사용자 경험 개선 -> 이것도... 왜 API 요청이 폼 태그에 비해 사용자 경험이 개선되는지 체감되지 않습니다.
• 모바일 및 외부 시스템과의 연동 -> 이것도...

ㅋㅋㅋ 너무 제가 부정적인걸까요. 너무 보수적인걸까요... 개발은 열려있는 마음으로 해야하는 것 같은데.. 이쯤되니 훌륭한 개발자가 어떤 개발자인지 의문을 갖게 됩니다.

 

좋은 기술이 있다면 "뭐 좋은 이유가 있겠지" 하고 바로 도입하는 개발자.

 

좋은 기술이 있다면 "왜 좋은거지? 이전과 다른게 없는거 같은데. 대체 이유가 뭐야!" 하고 고민하다 남들보다 늦게 도입하는 개발자. 연차가 쌓이면 왜 좋은지 이유를 찾는 과정이 빨라질까요?

 

뭐가 훌륭한 개발자일까요..

 

아무튼, 이러한 궁금증이 해소가 여전히 되지 않았고, 구글링을 해도 저와 같은 의문을 갖는 사람이 많지 않아 자료가 없었습니다.

 

그래서 국내 최대 개발자 커뮤니티인 OKKY 에 질문글을 올렸습니다.

 

링크를 첨부하겠습니다.

 

https://okky.kr/questions/1510705?topic=questions&page=1

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

 

개발 선생님 두 분께서 답변을 달아주셨습니다.

 

답변해주신 바를 정리하면 다음과 같습니다.

 

아래는 첫 번째 선생님의 답변입니다. 제 식대로 글을 다시 작성했습니다. ( 말씀하신 바를 제가 직접 작성함으로써 그 의미에 대한 이해를 깊게 하기 위함입니다.)

 

[폼 태그 방식을 사용하지 않는 이유]
 
현 개발 트렌드는 프론트엔드와 백엔드를 분리하는 방향으로 가고 있습니다. 각 영역별로 구분을 두고, 책임 소재를 명확하게 분리함으로써 유지보수성은 물론 체계적인 서비스를 구축할 수 있기 때문입니다.

아마 "구분하면, 관리 포인트가 늘어나는 데 굳이 나눠야 하나요?" 라는 의문이 드실 수 있습니다.

서로의 코드가 깊게 엮여있을 수록 한 쪽을 바꿨을 때 다른 쪽도 영향을 받기 쉽습니다. 그리고 다른 페이지에 비슷한 요구 사항이 있음에도 별도의 로직을 다시 작성( 소위 복사 붙여넣기 )할 확률이 높습니다.

-> (다음은 블로그 주인의 생각입니다.) 프론트와 백엔드를 분리하지 않은 프로젝트의 경우, 페이지 A에서 (이름, 이메일)을 요구하고 이를 다루는 백엔드의 A' 클래스에서는 이름과 이메일을 반환합니다. 페이지 B에서 (이름, 이메일, 생년월일)을 요구하고 이를 다루는 백엔드의 B' 클래스에서는 이름과 이메일과 생년월일을 반환합니다. 프론트와 백엔드가 분리되지 않으니 중복된 코드를 작성하게 되는거죠. 반면, API를 작성하면 어떻게 될까요? 백엔드는 다음과 같습니다. 이름을 반환하는 NAME 클래스, 이메일을 반환하는 EMAIL 클래스, 생년월일을 반환하는 BIRTH 클래스로 구성되어 있습니다. 이 때 페이지 A는 'name API', 'email API'를 백엔드에게 요청해서 관련 정보를 받고 알아서 조립하면 됩니다. 페이지 B는 'name API', 'email API', 'birth API'를 백엔드에게 요청해서 관련 정보를 받고 알아서 조립하여 사용자에게 보여줍니다. 여기서 회사 사장님이 개발자에게 요구합니다. "사용자에게 이름을 보여줄 때 기존의 방식말고, 이러이러한 방식으로 변경해서 보여줘" 라구요. 프론트엔드와 백엔드가 분리되지 않는 경우에는, 수정할 파일이 두 개가 생기죠. 반면, 프론트엔드와 백엔드를 분리한 경우에는 NAME 클래스만 수정하면 됩니다.

그래서 이러한 구조에서 벗어나 자연스레 백엔드에서 API를 제공하고 독립된 프론트엔드 영역에서 이를 호출하는 것입니다.

또한, API 구현 수준에 따라 여러 서비스에서 이전에 구현한 API를 재사용하기도 좋다는 장점이 있습니다. (웹, 모바일, 인증 서버 등)

폼태그를 구현하지 않는 이유에 대해서 말해봅시다.

우선 1차적으로 페이지 이동이 강제됩니다. 이 특징으로 인해 반드시 동기적으로 동작하게 됩니다. 이 때 사용자의 데이터 흐름을 유지하기 위해 부가적인 로직을 구현해보셨을 것입니다. 

만약 API를 활용한다면 서비스의 흐름에 영향을 주지 않고, 비동기로 동작하며, 데이터를 받아 페이지의 값을 적절히 교체할 수 있다는 장점이 있습니다.

새로고침이나 깜빡임 없이 데이터가 주기적으로 변하는 기초적인 원리입니다.

 

다음은 두 번째 선생님의 답변입니다.

 

spa(single page application)의 탄생과 유행 이후 시작된 이야기입니다.

클라이언트가 분리되어 있다는 것은 별개의 소스 저장소로 분리되어 별개의 프로젝트가 되어 별개의 장비에서 돌아간다는 의미입니다.

서버의 ip와 도메인명도 다릅니다. 물론 합칠 수도 있지만요.

하지만 답글만 보고는 다 이해하기 힘듭니다. 직접 개발해보시면서 이해가 갈 수 있습니다.

 

이렇게 선생님들의 따뜻한 답변으로 저는 의문이 해소가 되었습니다.

그래서 왜 프론트엔드와 백엔드 소통 시 API를 사용하나요?

프론트엔드와 백엔드를 별개의 소스 저장소, 별개의 프로젝트, 별개의 장비에서 실행하는 등 분리하면 두 영역의 책임 소재가 나뉘어집니다. 분리된 두 영역은 API로 소통하는 것이죠. 그리고 이렇게 책임 소재를 분리시킴으로써 코드의 재사용성과 유지보수성을 높일 수 있습니다. 이러한 이유로 수많은 개발자들이 폼 태그 방식이 아닌 API를 사용하는 것이군요.