3장. 프론트엔드와 백엔드는 무엇이 다른가

웹 서비스를 처음 만들 때 많은 초보자가 가장 헷갈려하는 말이 있다. 바로 프론트엔드와 백엔드다. 둘 다 개발이라고 하니 비슷해 보이지만, 실제로는 맡은 역할이 꽤 다르다.

아주 짧게 말하면 이렇다. 프론트엔드는 사용자가 보고 만지는 쪽이고, 백엔드는 보이지 않는 곳에서 처리하고 판단하는 쪽이다. 하나는 무대 앞이고, 다른 하나는 무대 뒤다. 하나는 손님이 만나는 공간이고, 다른 하나는 서비스가 제대로 돌아가게 만드는 운영실이다.

이 둘을 구분할 수 있어야 웹 서비스를 한 덩어리로 보지 않고, 역할별로 나눠서 이해할 수 있다. 그래야 AI가 만든 코드도 덜 막연하게 느껴진다. "이건 화면 문제네", "이건 서버 규칙 문제네" 하고 방향을 잡을 수 있기 때문이다.

먼저, 이름부터 가볍게 이해하자

프론트엔드의 front는 앞이라는 뜻이다. 말 그대로 사용자의 눈앞에 있는 부분이다. 버튼, 입력창, 글 목록, 상세 페이지, 색상, 간격, 메뉴 이동 같은 것들이 여기에 들어간다.

백엔드의 back은 뒤라는 뜻이다. 사용자가 직접 보진 않지만, 서비스가 실제로 일을 처리하는 부분이다. 로그인 확인, 글 저장, 수정 권한 검사, 검색 결과 정리, 데이터 읽기와 저장 같은 일이 여기서 일어난다.

쉽게 말해 사용자는 프론트엔드를 통해 서비스를 만난다. 하지만 서비스가 진짜로 움직이게 만드는 힘은 백엔드에 있다.

카페로 비유하면 금방 이해된다

웹 서비스를 카페라고 생각해 보자.

손님은 메뉴판을 보고, 주문 버튼을 누르고, 결제 화면을 본다. 이처럼 손님이 직접 접하는 공간이 프론트엔드다. 메뉴판 디자인이 어수선하거나 버튼이 잘 안 눌리면 손님은 바로 불편함을 느낀다.

반면 주방에서는 주문을 받고, 재료를 확인하고, 음료를 만들고, 품절 여부를 판단한다. 손님 눈에는 직접 보이지 않지만 카페 운영의 핵심은 여기 있다. 이것이 백엔드다.

손님이 "아이스 아메리카노 한 잔 주세요"라고 말했을 때, 카운터 화면은 주문을 받는 프론트엔드이고, 실제로 주문을 처리해 제조 가능한지 판단하는 쪽은 백엔드다.

웹 서비스도 똑같다. 사용자는 화면에서 행동하고, 뒤에서는 그 행동이 가능한지 검사하고 결과를 만든다.

프론트엔드는 무엇을 할까

프론트엔드는 단순히 예쁘게 꾸미는 일만 하지 않는다. 물론 색상, 글꼴, 여백, 버튼 모양도 중요하다. 하지만 그것만이 전부는 아니다. 프론트엔드는 사용자가 쉽게 이해하고, 실수 없이 행동하도록 돕는 인터페이스를 만든다.

예를 들어 회원가입 화면을 떠올려 보자. 이름 입력칸, 이메일 입력칸, 비밀번호 입력칸, 가입 버튼이 보인다. 입력 중에 "이메일 형식이 이상해요" 같은 안내를 보여 줄 수도 있다. 가입이 끝나면 "가입이 완료되었습니다"라는 메시지를 띄우고 로그인 화면으로 이동시킬 수도 있다.

이 모든 것은 사용자의 경험과 직접 맞닿아 있다. 그래서 프론트엔드는 "보이는 것"이면서 동시에 "사용하게 만드는 것"이다.

프론트엔드가 자주 맡는 일은 보통 이런 것들이다.

• 화면 보여 주기

• 버튼, 입력창, 메뉴 같은 요소 배치하기

• 사용자의 클릭과 입력 받기

• 로딩 중, 성공, 실패 상태를 화면에 표시하기

• 모바일과 PC에서 모두 읽기 좋게 다듬기

즉, 프론트엔드는 서비스를 사용할 수 있는 형태로 번역하는 일이라고 생각하면 좋다.

백엔드는 무엇을 할까

백엔드는 화면 뒤에서 실제 업무를 처리한다. 사용자가 어떤 요청을 보냈을 때, 그 요청이 가능한지 판단하고 필요한 데이터를 읽거나 저장하는 역할이다.

예를 들어 사용자가 로그인을 시도하면, 백엔드는 입력된 정보가 맞는지 확인한다. 글을 작성하면 그 글을 저장한다. 수정 버튼을 눌렀을 때는 "이 사람이 정말 이 글의 작성자인가?"를 따진다. 검색을 요청하면 조건에 맞는 데이터만 골라서 돌려준다.

여기서 중요한 점은 백엔드가 단순 배달부가 아니라는 것이다. 백엔드는 규칙을 지키게 만드는 심판에 가깝다.

예를 들어 누군가 남의 글을 수정하려고 하면 프론트엔드에서 버튼을 숨길 수는 있다. 하지만 그것만으로는 충분하지 않다. 누군가는 직접 요청을 조작해서 수정 시도를 할 수 있기 때문이다. 그래서 최종 판단은 백엔드에서 해야 한다.

백엔드가 자주 맡는 일은 대체로 이렇다.

• 로그인과 인증 처리하기

• 데이터를 읽고 저장하고 수정하고 삭제하기

• 권한 확인하기

• 잘못된 요청 막기

• 필요한 결과를 정리해 프론트엔드에 보내기

그래서 백엔드는 서비스의 질서와 안전을 지키는 곳이라고 이해하면 훨씬 쉽다.

같은 기능도 앞과 뒤로 나뉜다

초보자에게 가장 중요한 감각은 이것이다. 하나의 기능도 프론트엔드와 백엔드가 나눠서 맡는 경우가 많다.

예를 들어 "글 작성"은 한 덩어리처럼 보이지만 실제로는 둘로 나뉜다.

프론트엔드는 제목 입력칸과 내용 입력칸을 보여 주고, 저장 버튼을 만든다. 사용자가 내용을 적으면 그것을 모아 전송한다.

백엔드는 전달받은 제목과 내용을 검사한다. 제목이 비어 있지는 않은지, 로그인한 사용자인지, 저장 가능한 형식인지 확인한 뒤 데이터베이스에 기록한다. 그리고 저장 결과를 다시 보내 준다.

사용자 입장에서는 그냥 "글을 썼다"로 끝나지만, 개발자의 눈에는 앞과 뒤의 역할이 분명히 나뉜다.

이 감각이 생기면 기능을 볼 때마다 이런 질문을 하게 된다.

"지금 사용자가 보는 것은 무엇인가?"

"뒤에서 실제 판단하는 것은 무엇인가?"

바로 이 두 질문이 서비스 구조를 이해하는 열쇠다.

예시로 보면 더 또렷해진다

우리가 이 책에서 만들 서비스는 회원가입, 로그인, 글 작성, 수정, 삭제, 목록, 상세, 검색까지 들어가는 작은 풀스택 웹 서비스다. 이 안에서 프론트엔드와 백엔드가 어떻게 나뉘는지 몇 가지 장면으로 살펴보자.

예시 1: 로그인 화면

로그인 페이지에서 사용자는 이메일과 비밀번호를 입력한다. 입력칸이 잘 보이게 배치되어 있고, 버튼을 누르면 로딩 표시가 뜨고, 실패하면 에러 메시지가 보인다. 이 부분은 프론트엔드다.

하지만 진짜 로그인 성공 여부를 결정하는 것은 백엔드다. 백엔드는 전달받은 정보를 확인하고, 맞으면 로그인 상태를 만들어 준다. 틀리면 실패 응답을 보낸다.

여기서 중요한 포인트는 하나다. "로그인된 것처럼 보이게 하는 것"과 "실제로 로그인된 상태를 인정하는 것"은 다르다.

앞의 것은 프론트엔드가 할 수 있다. 뒤의 것은 백엔드가 해야 한다.

예시 2: 글 목록 화면

메인 화면에서 여러 글이 카드 형태로 보인다고 해보자. 카드 모양, 제목 크기, 작성일 위치, 검색창의 배치 같은 것은 프론트엔드의 일이다.

하지만 어떤 글을 보여 줄지 고르고, 최신순으로 정렬하고, 검색어에 맞는 결과를 추리는 일은 대개 백엔드의 일이다. 프론트엔드는 그 결과를 받아 보기 좋게 보여 준다.

즉, 프론트엔드는 "어떻게 보이게 할까"를 고민하고, 백엔드는 "무엇을 보여 줄까"를 결정하는 경우가 많다.

물론 실제 개발에서는 경계가 조금 섞일 때도 있다. 간단한 정렬을 화면 쪽에서 처리하기도 한다. 하지만 입문 단계에서는 먼저 큰 원칙을 잡는 것이 중요하다. 보여 주는 쪽과 판단하는 쪽이 다르다는 점 말이다.

예시 3: 글 수정 기능

수정 페이지에 들어가서 기존 제목과 내용을 입력창에 보여 주는 일은 프론트엔드다. 저장 버튼을 누르게 만들고, 수정 완료 메시지를 보여 주는 것도 프론트엔드다.

하지만 정말 이 사용자가 수정할 수 있는 사람인지 확인하는 것은 백엔드의 책임이다. 남의 글을 수정하려는 요청이면 백엔드는 거절해야 한다.

여기서 초보자가 자주 하는 오해가 있다. "수정 버튼을 안 보이게 했으니 안전한 거 아닌가요?"

아니다. 버튼을 숨기는 것은 사용자 편의를 위한 화면 처리일 뿐이다. 보안과 권한은 백엔드에서 확인해야 한다. 백엔드는 서비스의 문지기이기 때문이다.

둘의 차이를 한 번에 보는 표

아래 표는 프론트엔드와 백엔드의 차이를 빠르게 잡는 데 도움이 된다.

이 표를 완벽히 외울 필요는 없다. 다만 기능을 볼 때 "이건 어느 쪽 문제일까?"를 떠올릴 수 있으면 충분하다.

왜 초보자일수록 이 구분이 중요할까

처음 개발을 접하면 모든 것이 한꺼번에 엉켜 보인다. 버튼이 안 눌리면 무조건 코드 전체가 문제처럼 느껴지고, 로그인 실패가 나면 어디서부터 봐야 할지 막막해진다.

하지만 프론트엔드와 백엔드를 나눠 생각하면 문제를 훨씬 침착하게 좁힐 수 있다.

예를 들어 저장 버튼을 눌렀는데 아무 일도 안 일어난다고 해보자. 이때 이렇게 생각할 수 있다.

• 버튼 클릭 자체가 안 되는가

• 클릭은 되는데 요청이 안 보내지는가

• 요청은 갔는데 서버에서 에러가 나는가

• 서버는 정상인데 화면에 결과를 안 보여 주는가

이 질문은 문제를 둘로, 셋으로, 점점 작게 나눠 준다. 초보자에게 이것은 엄청난 힘이다. 막연한 공포가 구체적인 점검으로 바뀌기 때문이다.

AI와 협업할 때도 이 구분이 아주 중요하다

이 책의 핵심은 AI와 함께 실제 서비스를 완성하는 것이다. 그런데 AI에게 잘 요청하려면 문제를 잘 나눌 수 있어야 한다. 프론트엔드와 백엔드 구분은 바로 그 나누기의 출발점이다.

예를 들어 이렇게 말하는 것보다,

"검색이 이상해요. 고쳐 주세요."

이렇게 말하는 편이 훨씬 좋다.

"검색 입력창은 잘 보이는데, 검색 버튼을 눌러도 결과가 바뀌지 않아요. 프론트엔드에서 요청이 안 나가는 건지, 백엔드에서 검색 조건 처리가 안 되는 건지 확인해 주세요."

또는 이런 식으로도 말할 수 있다.

"UI는 괜찮은데, 로그인하지 않은 사용자도 글 수정 요청이 통과합니다. 백엔드 권한 검사 쪽을 봐 주세요."

이렇게 요청하면 AI는 훨씬 정확한 방향으로 도와줄 수 있다. 결국 구조를 이해하는 사람이 AI도 더 잘 다룬다.

현실에서는 경계가 가끔 흐려진다

여기서 한 가지는 미리 알아 두면 좋다. 실제 프로젝트에서는 프론트엔드와 백엔드의 경계가 아주 칼같이 나뉘지 않을 때도 있다. 특히 Next.js 같은 도구를 쓰면 한 프로젝트 안에 화면 코드와 서버 코드가 함께 들어가기도 한다.

그래서 초보자는 종종 이런 생각을 한다.

"어? 파일은 같은 폴더에 있는데요?"

그럴 수 있다. 중요한 것은 파일 위치보다 역할이다. 같은 프로젝트 안에 있어도 사용자의 화면을 만들고 반응하는 코드는 프론트엔드 역할을 한다. 반대로 데이터를 처리하고 권한을 검사하고 저장하는 코드는 백엔드 역할을 한다.

즉, 겉모습이 아니라 무슨 일을 하는 코드인지가 더 중요하다.

이 원칙만 잡고 있으면 도구가 바뀌어도 덜 흔들린다.

무엇이 프론트엔드 문제이고, 무엇이 백엔드 문제일까

실전 감각을 위해 몇 가지 상황을 짚어 보자.

화면이 모바일에서 깨진다. 이건 대체로 프론트엔드 문제다.

저장 버튼을 눌렀는데 입력 내용이 서버로 전달되지 않는다. 시작은 프론트엔드 문제일 가능성이 크다.

저장은 되는 것 같은데 실제로 데이터가 남지 않는다. 백엔드나 데이터 저장 쪽을 봐야 한다.

로그인하지 않은 사용자가 보호된 기능을 써 버린다. 이건 백엔드 권한 처리 문제다.

에러 메시지가 너무 딱딱하거나 어디가 잘못됐는지 모르겠다. 사용자의 눈에 보이는 안내 방식이므로 프론트엔드 문제에 가깝다.

이렇게 완전히 나뉘지 않는 경우도 있지만, 대략적인 방향을 잡는 데는 큰 도움이 된다.

결국 둘은 경쟁자가 아니라 한 팀이다

프론트엔드와 백엔드를 따로 설명했지만, 둘은 서로 떨어져 존재하지 않는다. 오히려 둘이 잘 맞물려야 서비스가 자연스럽게 작동한다.

프론트엔드만 좋고 백엔드가 엉망이면 화면은 그럴듯한데 기능이 불안정하다. 반대로 백엔드만 탄탄하고 프론트엔드가 엉망이면 기능은 살아 있어도 사용자가 쓰기 어렵다.

좋은 웹 서비스는 앞과 뒤가 서로 신호를 잘 주고받는다. 프론트엔드는 필요한 정보를 정확히 보내고, 백엔드는 예측 가능한 결과를 돌려주며, 프론트엔드는 그 결과를 이해하기 쉬운 방식으로 보여 준다.

이 팀플레이를 이해하는 순간, 웹 서비스는 더 이상 수수께끼가 아니다. 단지 역할을 나눠 협업하는 구조로 보이기 시작한다.

이 장의 핵심 정리

프론트엔드는 사용자가 보고 만지는 영역이다. 화면을 보여 주고, 입력을 받고, 상태를 안내하고, 사용하기 편한 흐름을 만든다.

백엔드는 보이지 않는 곳에서 처리하는 영역이다. 요청을 받아 판단하고, 데이터를 읽고 저장하고, 권한을 확인하고, 서비스의 규칙을 지킨다.

하나의 기능도 대개 둘이 나눠서 맡는다. 글 작성, 로그인, 검색, 수정, 삭제 모두 그렇다. 그래서 앞과 뒤를 구분할 수 있어야 서비스 전체 구조가 보인다.

이 감각이 생기면 앞으로 무엇을 만들든 훨씬 덜 막막해진다. 화면 문제인지, 처리 문제인지, 저장 문제인지 생각할 수 있기 때문이다. 그리고 이것은 AI와 협업할 때도 매우 강력한 무기가 된다.

다음 장에서는 이 백엔드의 중요한 동료이자 서비스의 기억 창고인 데이터베이스가 왜 필요한지를 더 쉬운 말로 살펴보겠다.