웹사이트 기획 가이드: 서버가 필요한 기능과 필요 없는 기능 구분하기

웹사이트를 기획하다 보면 처음에는 간단해 보였던 기능이 개발 과정에서 예상보다 큰 구조를 필요로 하는 경우가 있습니다.

화면을 구성하고 사용자의 입력에 따라 결과를 보여주는 기능은 웹 브라우저 안에서 자체적으로 처리할 수 있는 경우가 많습니다. 반면 로그인, 댓글, 결제, 랭킹처럼 '나 외에 다른 사람'과 데이터를 주고받아야 하는 기능은 별도의 서버와 데이터베이스가 필요해집니다.

문제는 기획을 고도화하다 보면 어디까지 서버 없이 처리할 수 있고, 어느 순간부터 서버를 설계해야 하는지 그 경계가 모호해진다는 것입니다.

저도 웹게임 🔗RageTap을 개발하면서 이런 차이를 직접 경험했습니다. 처음에는 게임을 실행하고 결과를 보여주는 것에 집중했지만, 이후 플레이 기록을 저장하고 다른 사용자와 비교할 수 있는 랭킹을 추가하면서 서버가 필요한 영역이 생겼습니다.

이번 글에서는 웹사이트를 기획할 때 서버가 필요한 기능과 필요하지 않은 기능을 구분하는 기준을 정리해보겠습니다.

🖥️ 서버 없이 처리할 수 있는 기능

서버 없이 처리할 수 있는 기능의 가장 큰 특징은 사용자의 작업이 현재 서비스 안에서 끝난다는 것입니다.

사용자가 값을 입력하고 결과를 확인하거나, 파일을 편집한 뒤 다운로드하는 것처럼 해당 작업을 현재 사용자의 환경에서 처리할 수 있다면 별도의 서버가 필요하지 않을 수 있습니다.

여기서 중요한 것은 복잡한 기능이라고 해서 반드시 서버가 필요한 것은 아닙니다.

복잡한 계산이나 다양한 인터랙션이 들어간 기능이라도 결과가 현재 사용자에게만 필요하고 작업이 끝난다면 서버 없이 처리할 수 있습니다. 반대로 아주 단순한 기능이라도 결과를 저장해 다른 사용자와 공유해야 한다면 서버가 필요해집니다.

예를 들어 게임에서 플레이 시간을 측정하고 현재 점수를 보여주는 것은 해당 사용자의 플레이를 처리하는 기능입니다. 하지만 그 기록을 저장해 다른 사용자의 기록과 비교하려면 필요한 구조가 달라집니다.

즉, 기능의 복잡함보다 그 기능에서 만들어진 데이터가 현재 사용자한테만 보여지는지가 핵심입니다.

🌐 서버가 필요한 기능

반대로 서버가 필요한 기능은 사용자가 인터넷 창을 닫아도 데이터가 유지되어야 하는 경우입니다.

페이지를 닫은 뒤에도 데이터가 남아 있어야 하거나, 다른 사용자가 같은 데이터를 확인해야 한다면 데이터를 지속적으로 저장하고 관리할 수 있는 구조가 필요합니다.

대표적인 차이를 정리하면 다음과 같습니다.

회원가입을 생각하면 이해하기 쉽습니다. 사용자가 입력한 계정 정보가 현재 페이지에서만 존재한다면 로그인 기능으로 사용할 수 없습니다. 페이지를 나간 뒤에도 계정 정보가 남아 있어야 하고, 다음에 다시 접속했을 때 해당 사용자를 식별할 수 있어야 합니다.

댓글이나 게시글도 마찬가지입니다. 작성자의 화면에만 내용이 남아 있는 것으로는 의미가 없고, 다른 사용자가 같은 페이지에 들어왔을 때도 해당 내용을 볼 수 있어야 합니다.

결국 서버가 필요한 핵심적인 이유는 웹페이지를 동작시키기 위해서가 아니라 여러 사용자가 사용하는 데이터를 지속적으로 관리하기 위해서입니다.

🧭 애매한 기능은 데이터의 사용 범위로 판단한다

실제 기획에서는 서버가 필요한지 한 번에 결정하기 어려운 기능도 있습니다.

이럴 때는 기능의 겉모습보다 그 기능에서 만들어지는 데이터가 어디까지 사용되는지를 확인하면 됩니다.

예를 들어 이미지 편집 결과를 만들어 바로 다운로드하는 기능이라면 작업이 끝난 뒤 해당 데이터가 서비스에 계속 남아 있을 필요가 없습니다. 이와 관련하여 🔗웹사이트에 사진을 올리면 무조건 서버로 전송될까? 게시글을 확인해보면 관련 내용을 자세히 이해할 수 있습니다.

반면 사용자가 만든 이미지를 계정에 저장해두고 다른 기기에서도 다시 불러오게 하려면 상황이 달라집니다. 이제 데이터가 현재 작업에서 끝나는 것이 아니라 서비스에 계속 남아 있어야 하기 때문입니다.

게임 점수도 같은 방식으로 볼 수 있습니다. 내 점수를 화면에 표시하는 것과 내 최고 기록을 저장하는 것, 모든 사용자의 기록을 모아 랭킹을 만드는 것은 겉보기에는 모두 ‘점수 기능’이지만 데이터의 사용 범위가 서로 다릅니다.

따라서 같은 기능이라도 데이터를 어디까지 활용할 것인지에 따라 서버의 필요 여부가 달라질 수 있습니다.

🎯 같은 점수 기능도 기획에 따라 달라진다

게임 점수를 예로 들면 이 차이가 더욱 명확합니다.

게임을 끝낸 뒤 현재 점수만 보여주는 경우에는 플레이 과정에서 점수를 계산하고 결과를 표시하면 됩니다.

내 최고 기록을 다음에 다시 확인할 수 있도록 만들고 싶다면 사용자의 기기에 기록을 저장하는 방법을 사용할 수 있습니다.

하지만 모든 사용자의 기록을 모아 랭킹을 보여주려면 여러 사람의 데이터를 한곳에서 관리해야 합니다.

여기에 점수에 따라 경품이나 보상을 지급한다면 단순히 점수를 저장하는 것만으로는 부족합니다. 사용자가 임의로 만든 점수가 등록되지 않도록 데이터를 검증하는 과정까지 고려해야 합니다.

이를 정리하면 다음과 같습니다.

이처럼 ‘점수’라는 하나의 데이터도 기획 범위가 넓어질수록 필요한 개발 구조가 달라집니다.

따라서 서버의 필요 여부를 결정할 때는 기능 이름만 보는 것보다 그 기능을 서비스에서 어디까지 활용할 것인지까지 함께 생각해야 합니다.

🎮 미니게임 개발에서 서버가 필요해진 이유

저 역시 🔗RageTap을 처음 기획했을 때는 게임을 실행하고 사용자의 행동을 처리한 뒤 결과를 보여주는 것에 집중했습니다. 게임 진행, 타이머, 클릭에 따른 판정과 점수 계산처럼 플레이 자체에 필요한 기능은 사용자의 환경에서 처리할 수 있었기 때문입니다.

그때까지는 게임을 플레이한 뒤 점수를 확인하는 것으로 기능이 끝났기 때문에, 여러 사용자의 데이터를 저장하거나 공유할 필요가 없었습니다.

하지만 개발 과정에서 플레이 기록을 저장하고 다른 사용자와 비교할 수 있는 랭킹 기능을 추가하면서 상황이 달라졌습니다. 내 화면에서 점수를 보여주는 것과 여러 사용자의 점수를 모아 비교하는 것은 필요한 데이터의 범위가 달랐기 때문입니다.

그래서 RageTap에서는 게임을 실행하는 부분은 사용자의 환경에서 처리하고, 점수를 저장하고 랭킹을 조회하는 부분만 서버와 데이터 저장소를 이용하는 방식으로 구조를 나누었습니다.

이 과정을 통해 하나의 게임 안에서도 서버가 필요한 기능과 그렇지 않은 기능을 분리해서 설계할 수 있다는 것을 실제 개발 과정에서 확인할 수 있었습니다.

⚖️ 서버를 처음부터 붙이지 않아도 되는 이유

서버가 필요하지 않은 기능까지 처음부터 서버에 의존하게 만들면 개발해야 할 구조가 불필요하게 늘어날 수 있습니다. 현재 사용자에게만 필요한 계산까지 서버에서 처리하게 되면 데이터를 주고받는 과정이 추가되고, 데이터를 관리해야 하는 영역이 늘어나기 때문입니다.

반대로 여러 사용자가 공유해야 하는 데이터를 서버 없이 처리하려고 하면, 나중에 기능을 확장하는 과정에서 구조를 크게 변경해야 할 수 있습니다.

그래서 웹사이트를 기획할 때는 ‘서버를 사용할 것인가’를 기술적으로 고민하기보다, 기능별로 데이터의 범위를 먼저 정리하는 것이 중요합니다.

현재 사용자에게만 필요한 데이터인지, 페이지를 닫은 뒤에도 남아야 하는 데이터인지, 다른 사용자가 함께 사용해야 하는 데이터인지부터 구분하면 서버가 필요한 영역도 자연스럽게 드러납니다.

서버가 필요한 기능이라고 해서 처음부터 복잡한 백엔드 구조를 만들 필요도 없습니다. 실제 서비스에서 공유하거나 보관해야 하는 데이터가 무엇인지 먼저 정한 뒤, 그 범위에 맞춰 필요한 서버 기능을 추가하면 됩니다.

웹사이트를 기획할 때 서버의 필요 여부를 기술의 문제로만 생각하지 않고 데이터의 문제로 바라보면, 불필요하게 구조를 복잡하게 만드는 것도 피하면서 나중에 확장해야 할 기능도 훨씬 명확하게 설계할 수 있습니다.