🤿 딥다이브 - CSR vs SSR

🤔 클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)에 대한 고민

최근 프로젝트를 진행하면서 클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)에 대해 고민하고 학습했던 과정을 작성하려 합니다.

항상 리액트나 뷰로만 js를 사용해봤지, 템플릿 엔진을 사용한 바닐라 js로의 웹 페이지 구현은 처음이라 많이 낯설기도 하고, 어렵기도 한 것 같습니다.

먼저 처음에는 CSR과 SSR의 차이를 ‘페이지가 깜박이는지’ 여부로 단순하게 생각했었습니다.

하지만 실제로는 훨씬 더 깊고 복잡한 개념들이 존재하다는 것을 알게 되었습니다.

그래서 이번 글에서는 제가 직접 작성한 코드에서 고민했던 부분을 CSR과 SSR의 차이점을 중심으로 정리해보았습니다.

(이런 식으로 글을 써본 적이 없었는데, 앞으로는 제가 했던 고민들을 이렇게 매거진 형식(?)으로 포스팅 해보려고 합니다.ㅎㅎ)

---

😅 1. 처음에 가졌던 CSR과 SSR에 대한 이해

이번에 깊게 고민해보기 전까지만 해도 CSR과 SSR에 대해 아주 간단하게 이해하고 있었습니다.

(사실 벨로그에 CSR과 SSR에 대해서도 정리해둔 적이 있었고, 공부해본 적이 있었기에 다 알고 있다고 생각했습니다…)

물론 렌더링을 해주는 주체가 클라이언트/서버로 각각 다르다는 것은 알고 있었지만, 가장 큰 특징이 있기에 아래와 같이 생각하고 있었습니다.

• CSR (Client-Side Rendering): 웹 페이지가 새로고침 없이 동작하면 CSR이다.
• SSR (Server-Side Rendering): 웹 페이지가 새로고침이 발생하면 SSR이다.

이렇게 새로고침(깜박임) 유무를 기준으로 렌더링 방식을 판단하였습니다.

예를 들어, 사용자가 웹사이트에서 카드를 추가하거나 삭제할 때 페이지가 깜박이면 "아, 이건 SSR이구나"라고 단순히 판단했습니다.

🚧 2. 기존 코드와 고민

제가 구현한 카드를 추가하는 기능을 예로 들어보겠습니다.

아래는 클라이언트에서 카드를 추가하는 버튼을 클릭 했을 때의 코드입니다.

const addButtons = document.querySelectorAll('.add-todo');

addButtons.forEach(button => {
    const columnId = button.getAttribute('data-column-id');
    const cardContainer = button.closest('.column').querySelector('.column-card-container');

    button.addEventListener('click', function() {
        loadAppendCardTemplate(cardContainer, columnId);
    });
});

이 코드는 .add-todo 클래스를 가진 모든 버튼에 클릭 이벤트를 추가합니다.

각 버튼을 클릭할 때마다 loadAppendCardTemplate 함수를 호출하여 새로운 카드 템플릿(mustache 사용)을 불러와 해당 위치에 추가합니다.

만약 새로운 카드 템플릿에서 카드 추가를 완료하는 버튼을 누르면, 카드를 서버에 추가하는 API를 호출하고,

추가가 완료되면 클라이언트는 페이지를 새로고침하는 방식으로 구현했습니다.

(만약 새로고침을 하지 않으면, api 호출을 통해 db에 추가된 데이터를 가져오지 않기에 새로고침 하는 작업을 추가해주었습니다.)

// 카드를 추가하는 API 호출
fetch('/api/addCard', {
    method: 'POST',
    body: JSON.stringify(cardData),
    headers: {
        'Content-Type': 'application/json'
    }
})
.then(response => response.json())
.then(data => {
    if (data.success) {
        location.reload();  // 페이지 새로고침
    }
})
.catch(error => console.error('Error:', error));

그래서 이 코드에서 카드가 성공적으로 추가되면 location.reload()로 페이지를 새로고침하여 전체 UI를 업데이트해줍니다.

새로고침이 발생하면서 페이지가 깜박였기 때문에 가장 처음에는, 저는 이 방식이 SSR이라고 생각했습니다.

새로고침을 하지 않으면 데이터가 반영되지 않기 때문에, 그러니까 새로고침을 꼭 해줘야 하기 때문에 SSR이라고 판단했던 것입니다.

✏️  3. SSR의 본질

하지만 SSR에 대해 더 깊이 공부하면서 제가 잘못 이해하고 있었다는 것을 알게 되었습니다.

SSR은 서버에서 완전히 렌더링된 HTML을 생성하여 클라이언트로 보내는 방식을 의미합니다.

이게 기본 정의인데, 저는 ‘페이지 깜박거림’에만 집중하여 본질적인 정의를 잊고 있었던 것이었습니다.

결국 SSR은, 서버에서 이미 모든 HTML을 구성한 후, 그 완성된 HTML을 클라이언트로 전송하는 것입니다.

클라이언트에서는 서버에서 받은 HTML을 어떠한 작업도 없이 그대로 브라우저에 렌더링해야 SSR입니다.

그래서 결론적으로 제가 짠 코드는 SSR은 아니겠다는 판단을 하게 되었습니다.

✒️ 4. 그럼 내 코드는 CSR?

위에서 SSR은 아니겠다는 판단을 한 뒤, 그럼 CSR인가? 하는 의문을 갖게 되었습니다.

제 코드에서 사용한 방식은 가장 먼저 클라이언트에서 main.html을 로드하고,

유저의 작업에 따라 Mustache 파일을 클라이언트에서 직접 렌더링하는 방식이었습니다.

카드 추가 버튼을 누르면 카드 추가 템플릿을 렌더링하고, 추가 확인 버튼을 누르면 서버로 POST 요청을 보낸 후 성공 시 데이터를 실시간으로 반영하기 위해 location.reload()를 통해 페이지를 새로고침했습니다.

물론 카드 추가 확인 버튼을 눌렀을 때 (api를 호출해서 데이터가 화면에서 변경되어야 할 때)는 새로고침을 하지만, 데이터 변경 없이 화면만 변경해도 되는 경우에는 아래와 같이 .innerHTML을 통해 화면에 mustache 파일의 내용을 추가해줍니다.

이 과정에서 클라이언트는 서버로부터 데이터를 받아오고 페이지 일부를 동적으로 변경해줍니다.

function fetchColumnsAndRender() {
    fetch('/api/columns')
        .then(response => response.json())
        .then(data => {
            fetch('../components/column.mustache')
                .then(response => response.text())
                .then(template => {
                    const renderedColumns = data.columns.map(column => {
                        return Mustache.render(template, column);
                    }).join('');
                    const contentSection = document.querySelector('.content');
                    
                    // innerHTML += 을 통해 화면에 추가
                    contentSection.innerHTML = renderedColumns;
                })
                .then(data => {
                    loadDeleteModal();
                })
                .then(data => {
                    registerCardEventListeners();
                    registerMoveCardEventListeners();
                })
                .catch(error => console.error('Error loading template:', error));
        })
        .catch(error => console.error('Error loading columns from API:', error));
}

즉, HTML의 일부를 클라이언트 측에서 JavaScript를 통해 변경하는 것입니다.

그래서 이 방식은 CSR에 가깝다는 결론을 내렸습니다.

(CSR : 클라이언트 측에서 JavaScript를 사용하여 필요한 데이터를 서버로부터 가져오고, HTML을 동적으로 렌더링하는 방식)

🗑️ 5. CSR도, SSR도 아닌가..?

그런데 아무리 생각해봐도 CSR의 가장 큰 특징이자 유일한(?) 장점이 새로고침을 하지 않아 화면이 깜박거리지 않는다는 것인데, 제 웹사이트는 깜박거리고 있다는 것이었습니다.

그래서, 물론 클라이언트가 페이지를 렌더링하는 것이 CSR이라는 정의는 알고 있지만,

과연 가장 큰 특징인 깜박거리지 않는다는 점을 만족하지 못하는데, 그걸 CSR이라고 할 수 있을까?

하는 딜레마에 빠지게 되었습니다.

이 딜레마 때문에 정말 한참을 고민했는데, 사실 완전한 답을 찾지는 못했습니다.

🔎 5. 또 다시 … 서버사이드 렌더링(SSR)인가? 새로운 관점에서의 고민

그러나 여기서 또 다른 새로운 생각이 들었습니다.

만약 클라이언트에서 JavaScript를 통해 템플릿을 렌더링하고 있다면, 이는 마치 클라이언트가 서버처럼 동작하고 있는 것 아닐까?

SSR은 서버 사이드 렌더링의 약자입니다.

그런데 저는 자연스럽게 서버라는 단어 때문에 SSR에서 의미하는 서버가 백엔드 서버라고 생각을 했는데,

SSR을 공부하다 보니, “그냥 단순한 서버”, “쉽게 말해 인터넷이 되는 컴퓨터”라고 생각해야 한다는 것을 알게 되었습니다.

즉 “서버 = 인터넷이 되는 컴퓨터”, “서버 ≠ 백엔드”인 것인데,

일반적으로 우리가 생각하는 SSR은 서버에서 HTML을 생성해 클라이언트로 전송하는 것을 의미하지만,

클라이언트에서 Javascript로 HTML을 조작하는 것도 일종의 서버 역할이 아닐까?

하는 생각이 들었습니다.

javascript가 html 돔에 접근해 조작하는 것도 서버로 볼 수 있지 않나?

라는 의문이 들었습니다.

다시 말하면 CSR은 브라우저 내에서 JavaScript가 HTML을 생성하는 것이므로,

"누가 HTML을 생성하는가"에 초점을 맞춘다면,

CSR 역시 "서버사이드 렌더링"의 넓은 범주에 속할 수 있지 않을까 하는 생각이 들었습니다.

그런데 이런 생각들을 계속 하다보니 너무 멀리까지 온 것 같다는 생각이 들었고,

CSR 역시 "서버사이드 렌더링"의 넓은 범주에 속한다고 하더라도 어차피 내 코드는 어디에 속하는지 이 논의로는 정의할 수 없겠다는 생각이 들어 생각을 멈추기로 했습니다…

6. 결론

결론적으로, 제가 짠 코드가 CSR인지 SSR인지 명확하게 하나로 구분할 수는 없었습니다.

SSR과 CSR을 혼합하여 사용한 것이라고 판단하였고,

다만 CSR을 사용한 부분 중에서도 (예를 들자면 카드 추가) 렌더링 정의로만 따지자면 CSR이 맞지만 깜박임이 없다는 CSR의 장점을 활용하지 못했다는 것을 알 수 있었습니다.

항상 리액트만 사용하다가 이렇게 바닐라 js로 구현해보니, 새삼 상태 관리의 중요성에 대해 다시금 깨닫게 되었고, 또 덕분에 깊이 있게 공부해볼 생각조차 하지 못했던 CSR과 SSR에 대해서도 학습해볼 수 있었습니다.

CSR과 SSR의 차이는 단순히 페이지의 깜박임 여부나 새로고침 유무로만 구분할 수 있는 것이 아니라

HTML을 생성하고 렌더링하는 주체가 어디에 있는지를 기준으로 판단해야 한다는 것,

서버와 클라이언트의 역할을 명확히 구분하고, 각 방식의 특성과 장점을 이해하는 것이 중요하다는 것,

그리고 SSR에서 지칭하는 서버는 백엔드 서버가 아니라는 것을 중요하게 기억해두어야겠다고 생각했습니다.

---

처음으로 제 고민 과정을 매거진 형식으로 작성해보았는데, 확실히 제 고민을 기억해둘 수 있어서 좋은 것 같습니다.

최대한 자주 이런 식으로 딥다이브 해보고, 그 경험과 고민을 작성할 수 있도록 해야겠습니다.