웹사이트에 백엔드가 필요할까요?

이 질문 하나로 결정됩니다

'백엔드'라는 말은 데이터베이스부터 결제 웹훅까지 모든 것을 포함하기 때문에, 추상적으로는 답하기 어려운 질문입니다. 하지만 실제 사례 거의 전부를 결정하는 더 짧은 질문이 있습니다. 이 페이지에 방문자 자신의 브라우저가 아닌 다른 곳에 기억해 둬야 하는 것이 있는가? 답이 '아니요'라면 여러분은 정적 사이트를 만드는 것이고, 그것은 타협이 아니라 싸고 빠르고 믿을 수 있는 선택입니다. 답이 '예'라면 프런트엔드를 아무리 영리하게 짜도 대신할 수 없고, 그 사실을 출시 후에야 알게 되는 것이 바로 돈이 드는 실수입니다.

정적 사이트가 합리적인 기본값인 데는 이유가 있습니다. 패치할 서버도, 부하에 쓰러질 것도 없고, 사이트 전체를 방문자 가까이의 캐시에서 제공할 수 있으며, 호스팅은 무료인 경우도 많습니다. 회사 소개 사이트, 포트폴리오, 메뉴판, 출시 페이지, 문서 사이트는 백엔드 없이도 온전히 완성됩니다. 공통점은 모든 방문자에게 같은 것을 보여 줘도 되고, 방문자가 한 일이 내일도 유효할 필요가 없다는 점입니다.

서버가 정말 필요한 것

백엔드가 필요하다고 여겨지는 기능 대부분은 서버 부분을 다른 회사가 운영하는 호스팅 서비스로 구할 수 있습니다. 작은 팀에게는 대개 그쪽이 맞는 선택입니다. 아래 표는 각 기능이 선의 어느 쪽에 있는지를 보여 줄 뿐, 직접 만들라는 이야기가 아닙니다.

표 밑에 깔린 패턴은 이렇습니다. 방문자 한 명이 한 번의 방문 안에서 혼자 하는 일은 브라우저에 두어도 안전합니다. 무엇이 사실인지를 두고 두 사람의 생각이 엇갈릴 수 있는 일, 즉 누가 로그인했는지, 누가 마지막 하나를 샀는지, 이것이 결제되었는지는 중립적인 곳에서 결정해야 합니다. 백엔드는 그걸 위해 존재하고, 엄밀히 필요한 것도 그것뿐입니다.

성공과 똑같아 보이는 실패

브라우저는 데이터를 로컬에 저장할 수 있고, 그 저장소를 쓰는 페이지는 나를 기억하는 것처럼 느껴집니다. 비밀번호를 넣으면 관리자 화면이 보입니다. 장바구니에 담고 탭을 닫았다가 돌아와도 장바구니가 그대로 있습니다. 만든 컴퓨터에서는 모든 것이 작동하고, 그래서 이 버전이 그대로 공개됩니다. 이 저장소에 기대기 전에 알아 둘 만한 네 가지 성질이 있습니다.

• 사람이 아니라 브라우저 하나에 속합니다. 휴대폰과 노트북은 절대 만나지 않는 별개의 저장소입니다. 같은 컴퓨터의 Chrome과 Safari도 서로 다르고, 시크릿 창도 따로입니다.
• 웹 주소 하나에 속합니다. 두 주소에 게시된 두 페이지는 서로의 저장소를 읽을 수 없습니다. 여러 사이트를 한꺼번에 관리하는 관리 패널 하나는, 페이지 레이아웃이 아무리 그럴듯해도 이 방식으로는 만들 수 없습니다.
• 방문자가 읽고 바꿀 수 있습니다. 접근을 결정하는 것, 예컨대 비밀번호, 결제 완료 표시, 관리자 권한을 거기에 저장하면 브라우저 개발자 도구를 여는 누구나 수정할 수 있습니다. 그것은 자물쇠가 아니라 들어오지 말아 달라고 부탁하는 쪽지입니다.
• 예고 없이 사라집니다. 사이트 데이터 삭제, 시크릿 창 닫기, 브라우저가 알아서 오래된 저장 데이터를 정리하는 것 모두 이를 지우며, 지워졌다는 사실은 아무도 알려 주지 않습니다.

이 문제는 다른 무언가가 페이지를 대신 만들어 줬을 때 특히 중요합니다. 생성된 페이지는 그럴듯하게 작동하는 데모가 되기 때문에 로그인 화면을 거리낌 없이 이런 식으로 구현합니다. 그것을 만든 도구에 던질 질문은 직설적이고 구체적입니다. 이건 어디에 저장되며, 다른 휴대폰으로 보는 고객에게는 무엇이 보이는가? 답이 브라우저라면, 그 기능은 아직 존재하지 않는 것입니다.

사이트를 만든 고객들이 그다음에 요청한 것

이 부분은 문서가 아니라 운영에서 나온 이야기입니다. AgentCeres(agentceres.com의 AI Growth Officer)는 에이전트가 고객을 위해 만든 페이지를 호스팅하는데, 2026년 9월의 한 주 동안 고객들이 작업한 모든 사이트를 살펴봤습니다. 고객 50명의 사이트 61개였고, 그중 37개는 그 주에 처음 게시된 것이었습니다. 고객들은 채팅으로 에이전트와 이야기하기 때문에, 그다음에 무엇을 요청했는지도 읽을 수 있었습니다. 이는 어떤 설문보다 분명한 신호입니다. 아무도 질문에 답하고 있던 것이 아니라, 무언가를 끝내려 하고 있었으니까요.

가장 먼저는 주문과 장바구니였고, 그 주에 에이전트와 대화하던 고객 30명 중 14명이 요청했습니다. 다음은 자동 확인을 포함한 결제로 8명, 이어서 로그인이나 관리자 영역이 5명이었습니다. 자체 도메인이 3명, 기기 간 실시간 동기화가 또 다른 3명이었습니다. 한 가지 예외를 빼면 이 목록의 모든 항목은 백엔드 요청입니다. 이 점이 유용합니다. 사람들은 데이터베이스를 달라고 하지 않고 주문을 받고 싶다고 말하는데, 알고 보면 둘은 같은 요청입니다.

그 뒤에 벌어진 일은 뚜렷하게 갈렸고, 그 갈림은 기능의 난이도를 따르지 않았습니다. 에이전트가 결제 게이트웨이나 진짜 백엔드가 필요하다고 분명히 말한 경우에는, 약속한 것이 없으니 나중에 망가진 것도 없었습니다. 반대로 브라우저만으로 그럴듯한 버전을 만든 경우에는 사이트가 공개된 뒤에 문제가 드러났습니다. 한 쇼핑몰은 관리자 비밀번호가 페이지 HTML에 적혀 있었고 직원들과 공유되고 있었습니다. 다른 고객은 따로 게시된 세 사이트를 실시간으로 동기화하는 마스터 패널을 약속받았는데, 이는 브라우저 저장소로는 전혀 할 수 없는 일이었고, 운영자는 작동하지 않는다고 다시 알려 왔습니다. 그러는 동안 그 페이지들이 가진 유일하게 진짜 서버에 기반한 기능인 문의 양식은 그 주에 받은 문의 12건을 모두 전달했습니다.

그러니 실용적인 조언은 이것을 만들고 나서가 아니라 만들기 전에 정하라는 것입니다. 방문자가 반드시 할 수 있어야 하는 일 두세 가지를 적고, 그중 두 사람의 생각이 엇갈릴 수 있는 것에 표시한 뒤, 그것들에는 호스팅 서비스를 쓰세요. 나머지는 정적으로 두어도 됩니다. 페이지가 새것이라면 다음 질문은 대개 누가 보기나 할지입니다. 그건 AI로 만든 웹사이트에 방문자를 모으는 법에서 다루고, 게시 전에 확인할 것은 웹사이트를 AI로 만들어도 될까에서 다룹니다.