1. 한 장의 그림

웹 서비스 구조는 워낙 복잡하고, 다양하기 때문에 한 장의 그림으로 정리되지 않습니다. 다만 대부분의 서비스를 간소화해서 표현하면 다음과 같은 그림이 됩니다. 이 그림은 책 전체에서 계속 나올 것이며, 웹 서비스 구조의 큰 그림을 잡는 데 도움이 될 것입니다.

각 용어를 한 줄로 정리하고 가겠습니다. 자세한 설명은 다음 장부터 이어집니다.

• Web Server (프론트엔드 소스코드): 사용자가 보는 화면과 인터페이스를 '서빙'하는 역할
• App Server (백엔드 소스코드): 사용자 요청을 처리하는 역할 (회원가입, 로그인, 게시물 작성 등)
• DB Server (데이터): 오래 보관하는 자료 창고
• AI 모델 API / 지도 API 등: 외부에서 빌려 쓰는 기능 (외부 App Server)
• 인프라: 모든 것이 돌아가는 밑바닥 환경(실 구매 / 클라우드 - 빌려쓰기)

이 그림이 곧 '무엇을 만들지'의 지도입니다. 만들고 싶은 서비스가 어느 정도가 필요한지, 어디까지 필요한지 선을 그을 수 있다면 이 수업의 목표를 달성한 것입니다. 다만 이러한 지도는 획일적이지 않기 때문에 좀 더 다양한 시나리오 살펴보도록 하겠습니다.

1.1 프론트엔드만 개발

브라우저만 있으면 실행되는 서비스입니다. HTML 파일, CSS 파일, JavaScript 파일만 있으면 동작합니다. 여러분의 컴퓨터에서는 대부분 HTML 파일을 더블 클릭하기만 하면 되고, 만약 인터넷에 올리고 싶다면 GitHub 같은 곳에 파일을 올리는 것만으로도 누구나 접속할 수 있는 서비스가 됩니다. 데스크톱 앱을 만들고 싶다면 Electron 같은 기술로 감싸주기만 하면 브라우저 없이도 동작하는 앱이 됩니다. 디스코드라는 채팅 서비스도 이렇게 만들어져 있어요.

회사 소개 페이지나 행사 페이지가 대표적입니다. 단위 변환기, 대출 이자 계산기, D-Day 계산기, 이미지 압축이나 모자이크 등 입력값을 받아 즉시 결과를 보여주는 도구도 여기에 들어갑니다. 틱택토 같은 단순 게임도 이 범주입니다. 의외로 일상에서 보는 화면 중 상당수가 이 구조로 충분합니다.

AI에게 부탁할 때는 "HTML/CSS/JS만으로 우리 회사 소개 페이지를 만들어줘." 정도로 말하면 깔끔하게 결과가 나옵니다.

1.2 프론트엔드와 백엔드를 한 묶음으로 개발

한 프로젝트 안에 화면과 처리 로직이 모두 들어있는 구조입니다. 주로 '풀스택 프레임워크' 같은 기술을 사용하게 되면 이와 같이 개발합니다. 풀스택 프레임워크는 비유를 하자면 건축을 하는데 건축 자재와 공구가 모두 포함된 도구라고 생각하시면 됩니다. 대부분의 웹 서비스를 만들 수 있고, 배포하고 유지보수하기도 쉽습니다.

아래 예시는 Django라는 풀스택 프레임워크로 개발한 서비스의 구조입니다. 프론트엔드와 백엔드가 한 몸이 되어 있습니다. 프론트엔드에서 페이지 요청이 들어오면, 백엔드가 데이터베이스에서 데이터를 조회해서 완성된 HTML을 만들어서 보내주는 구조입니다.

한 사람이 처음부터 끝까지 만들 수 있어 1인 개발이나 작은 팀에 잘 어울립니다. AI와 함께 개발하며 MVP, 일 이용자 10,000명 정도의 중규모 서비스까지 개발하기 좋습니다.

AI에게는 "Django로 회원가입과 글쓰기가 되는 게시판을 만들어줘. 한 프로젝트 안에서 다 끝나면 좋겠어."처럼 아래와 같은 구조로도 개발이 가능합니다. 유지보수하기는 더 편해집니다.

어떤 것을 선택하시든 백엔드를 선택하는 순간 '배포'의 난이도가 올라갑니다. 단지 파일만 업로드하면 전 세계 사람들이 접속했던 1.1과 달리, 이 소스코드가 항상 '실행'이 되고 있어야 하기 때문입니다.

처음 시작하는 분들이 가장 어려워하는 부분입니다. 그래서 가장 권하는 배포는 Render와 같은 '간편 배포' 서비스입니다. AI에게 "Render에 배포할 수 있게 해줘"라고 말하면 Render용 설정 파일까지 만들어 줍니다.

이러한 개발 패턴을 '모놀리식(monolithic) 구조'라고도 합니다. 프론트엔드와 백엔드가 한 몸인 구조라는 뜻입니다.

1.3 프론트엔드와 백엔드를 별도 프로젝트로 개발

화면 따로, 처리(로그인, 게시물 삭제 등) 따로 개발하는 방식입니다. 프론트엔드는 OOO 기술로, 백엔드는 OOO 기술로 따로 만듭니다. 두 프로젝트는 API라는 약속된 형식으로만 데이터를 주고받습니다.

대규모 서비스에 적합합니다. '프론트엔드 팀', '백엔드 팀' 같이 역할이 나뉘어 있는 조직에서 흔히 선택하는 구조입니다. 프론트엔드와 백엔드가 서로 독립적으로 개발되고 배포될 수 있어, 팀 간 협업이 편해집니다.

아주 작은 서비스부터 이 구조를 가져가면 오히려 관리하기 복잡해집니다. 특히 SW 지식이 없는 상태에서 AI와 함께 개발했다면 이 구조를 가져가는 것을 권하지 않습니다.

이러한 개발 패턴을 '마이크로서비스(microservice) 구조'라고도 합니다. 프론트엔드와 백엔드가 서로 독립된 서비스로 존재하는 구조라는 뜻입니다.

1.4 프론트엔드 + 외부 API 활용

백엔드 자리를 다른 회사가 열어둔 API로 대체합니다. 회원이나 DB가 따로 필요 없는데, 외부의 데이터나 기능은 가져다 쓰고 싶을 때 좋은 선택입니다.

네이버·카카오 지도 API에 우리 가게 위치를 찍어주는 화면, ChatGPT API로 짧은 소설을 써주는 도우미, 공공데이터 포털의 미세먼지 API를 화면에 띄우는 알림 위젯, OpenWeather API로 만드는 날씨 위젯이 흔한 예시입니다. Google Sheets API를 호출해 시트를 가벼운 DB처럼 쓰는 방식도 이 범주에 들어갑니다.

백엔드를 만들 필요가 없어 빠르게 시제품을 띄울 수 있습니다. 다만 속도, 보안 등을 고려해보았을 때 실제 서비스를 할 때 맞는 구조인지는 AI에게 아이디어를 설명하고 상담을 받는 것이 좋습니다. 예를 들어, Google Sheets를 연결하여 '게스트하우스 예약 시스템'을 개발하면 간편하지만, 사용자가 조금만 많아져도 속도가 매우 느려집니다.

1.5 프론트엔드 + 백엔드를 통째로 빌리기

회원가입·로그인·DB·파일 저장소를 한 묶음으로 빌려주는 서비스를 BaaS(Backend as a Service) 라고 부릅니다. Firebase(구글), Supabase, Pocketbase 같은 이름이 대표적입니다. 백엔드 코드를 거의 짜지 않고도 회원제 서비스를 만들 수 있어, 1인 개발자나 빠르게 만들어 보고 싶은 팀이 자주 선택합니다.

모임 신청 사이트, 가벼운 SNS, 메모·일기 앱, 해커톤이나 MVP 단계 서비스에 잘 어울립니다. 1.4와 비슷해 보이지만, 1.4가 외부 기능을 부분적으로 빌리는 것이라면 1.5는 백엔드 자체를 통째로 빌리는 쪽입니다.

식당으로 치면 공유 주방을 빌려 쓰는 1인 식당입니다. 주방 시설은 이미 갖춰져 있고, 사장은 메뉴 기획과 손님 응대만 합니다. 주방 설계와 설비 구입은 공유 주방 회사의 몫입니다.

백엔드를 직접 짜지 않아도 1~2주 안에 회원제 서비스를 띄울 수 있다는 게 가장 큰 장점입니다. 단점은 BaaS 회사의 정책·가격 변화에 묶인다는 점입니다. 사용자 수가 많아지면 비용이 빠르게 올라갈 수 있고, 나중에 다른 시스템으로 옮기는 게 까다롭습니다.