웹사이트 구조, 화면·처리·저장 3층으로 이해하기

웹사이트는 크게 세 층으로 이뤄진다. 사용자가 눈으로 보는 화면(프론트엔드), 그 뒤에서 요청을 처리하는 부분(백엔드), 데이터를 쌓아 두는 저장소(데이터베이스)로 나뉜다. 이 세 가지만 구분해도 개발사와 나누는 대화가 한결 또렷해진다.

핵심 요약

• 화면(프론트엔드)은 브라우저에 보이는 부분으로, 글자와 버튼과 색을 배치해 사용자가 직접 만지는 영역이다.
• 처리(백엔드)는 로그인·결제·검색처럼 눈에 보이지 않는 계산과 판단을 맡는다.
• 저장(데이터베이스)은 회원 정보나 주문 내역을 담아 두었다가 필요할 때 꺼내 준다.
• 문제가 생겼을 때 세 층 중 어디 이야기인지 짚으면, 개발사에 상황을 정확히 전달하기 쉬워진다.
• 발주자는 코드를 몰라도 이 세 층의 이름과 역할만 알면 견적과 일정 대화를 무리 없이 따라간다.

화면·처리·저장, 세 층은 각각 무슨 일을 하나

식당에 빗대면 이해가 빠르다. 손님이 앉는 홀과 메뉴판이 화면이고, 주문을 받아 요리하는 주방이 처리, 재료를 넣어 둔 창고가 저장이다. 손님은 주방과 창고를 직접 보지 않지만, 그 둘이 없으면 음식은 나오지 않는다.

화면은 우리가 브라우저에서 마주하는 모든 것이다. 상품 사진이 놓이는 위치, 버튼 색, 글자 크기가 여기서 정해진다. 예를 들어 "장바구니 담기"를 눌렀을 때 색이 살짝 바뀌는 반응까지가 화면의 몫이다.

처리는 그 버튼을 누른 다음 벌어지는 일을 담당한다. 재고가 남았는지 확인하고, 할인 금액을 계산하고, 로그인한 사람이 본인이 맞는지 판단하는 작업이 모두 여기 속한다. 화면이 아무리 보기 좋아도 처리가 없으면 결제나 검색은 동작하지 않는다.

저장은 그 계산에 쓰이는 데이터를 보관한다. 회원 아이디, 주문 날짜, 게시글 내용이 이곳에 줄과 칸으로 정리돼 들어간다. 처리가 "이 회원의 지난 주문을 보여 달라"고 요청하면 저장이 해당 기록을 찾아 돌려준다.

세 층을 한눈에 비교하면

세 층은 부르는 이름이 여러 개라 헷갈리기 쉽다. 각 층의 다른 이름과 맡는 일, 발주 대화에서 자주 나오는 표현을 아래 표에 정리했다.

층	흔히 부르는 다른 이름	맡는 일	이렇게 말하면 이 층 이야기
화면	프론트엔드, UI	보이고 만지는 부분을 그린다	"버튼이 안 눌려요", "글자가 깨져요"
처리	백엔드, 서버	계산하고 판단하고 연결한다	"결제가 안 돼요", "검색 결과가 이상해요"
저장	데이터베이스, DB	데이터를 보관하고 꺼내 온다	"가입한 회원이 안 보여요", "주문 내역이 사라졌어요"

표에서 보듯 같은 층을 두고도 개발사는 "프론트", 디자이너는 "화면", 발주자는 "보이는 부분"이라 부른다. 부르는 말이 달라도 가리키는 대상이 같다는 점만 알면 회의에서 길을 잃지 않는다. 모든 프로젝트가 세 층을 같은 무게로 쓰지는 않는다. 회사 소개용 홈페이지 제작이라면 화면 층 비중이 가장 크고 처리와 저장은 문의 폼을 받아 두는 정도로 가벼워진다.

발주와 견적 소통에서 구조를 써먹는 법

구조를 알면 요청을 구체적으로 적을 수 있고, 개발사도 견적을 빨리 낸다. 다음 순서로 정리해 두면 대화가 편해진다.

1. 바꾸고 싶은 것이 눈에 보이는 화면인지, 뒤에서 도는 처리인지부터 나눠 적는다.
2. 데이터를 새로 저장하거나 조회해야 하는 기능이라면, 저장 층 변경이 따른다고 미리 알린다.
3. 세 층 중 몇 곳을 건드리는 요청인지 헤아리면, 작업량과 견적 규모를 어림잡을 수 있다.
4. 버그를 신고할 때는 "어느 화면에서, 무엇을 눌렀더니, 어떻게 됐다"를 층 기준으로 적어 전달한다.
5. 받은 견적서에 프론트·백엔드·DB 항목이 나뉘어 있는지 확인하고, 빠진 층이 보이면 물어본다.

이렇게 층으로 끊어 말하면 "사이트가 이상해요" 한 문장보다 훨씬 빠르게 원인에 닿는다. 개발사도 어느 팀원이 손대야 할 일인지 바로 배정한다. 견적 문의를 받다 보면 요청을 층 단위로 나눠 보낸 발주자와는 첫 회의가 눈에 띄게 짧다. 외주 전반의 흐름이 궁금하다면 웹 외주가 무엇인지 정리한 글이 도움이 되고, 어떤 종류로 나뉘는지는 서비스 종류 안내에서 확인하면 된다.

가상 예시로 보는 세 층의 협업

다음은 이해를 돕기 위한 가상 예시다. 대구에서 꽃집을 운영하는 사장이 온라인 주문 페이지를 열었다고 하자. 손님이 꽃다발을 고르고 결제하는 흐름에서 세 층이 어떻게 나뉘어 일하는지 따라가 보자.

손님은 화면에서 꽃다발 사진을 보고 색과 수량을 고른다. "주문하기"를 누르면 처리 층이 재고를 확인하고 배송비를 더해 결제 금액을 계산한다. 결제가 끝나면 저장 층이 주문 번호와 배송지, 카드 승인 기록을 남긴다. 사장이 다음 날 관리자 화면에서 "오늘 주문"을 열면, 처리 층이 저장 층에서 그 기록을 불러와 목록으로 보여 준다.

만약 "결제 금액이 잘못 나온다"는 문의가 들어오면 처리 층을, "주문 목록이 안 뜬다"면 저장이나 조회 쪽을 먼저 살피면 된다. 층을 구분해 두었기에 사장은 개발사에 "화면은 멀쩡한데 계산이 틀립니다"라고 콕 집어 말한다. 구조까지 파악했다면 견적 문의에서 원하는 층을 지목해 요청해 보자.