서버와 클라이언트 구조 이해법(웹개발, API통신, 면접기초)

한 신입 개발자의 포트폴리오를 검토하면서 로그인 버튼을 누른 뒤 어떤 과정이 진행되는지 설명해 달라고 요청한 적이 있습니다. 학생은 프런트엔드에서 백엔드 API를 호출하고 데이터베이스에서 사용자를 확인한다고 답했습니다. 전체적인 방향은 알고 있었지만 요청에 어떤 값이 들어가는지, 서버는 무엇을 검사하는지, 로그인 결과가 화면에 어떻게 전달되는지는 설명하지 못했습니다.

프로젝트 기록을 다시 확인하니 학생은 로그인 화면과 API 연결을 직접 담당했습니다. 개발 중 로그인 요청이 계속 실패했지만 서버 문제라고 생각해 백엔드 담당자에게 수정을 요청했습니다. 브라우저의 네트워크 기록을 확인해 보니 화면에서 이메일을 userEmail이라는 이름으로 전달했고 서버에서는 email이라는 이름으로 값을 찾고 있었습니다. 서버에 요청은 도착했지만 필요한 값이 비어 있어 인증이 실패한 것입니다.

학생은 프런트엔드와 백엔드를 사용했다는 사실은 알고 있었지만 클라이언트가 어떤 요청을 만들고 서버가 어떻게 처리하는지는 정확히 이해하지 못했습니다. 기능을 연결하는 과정에서 문제가 발생했을 때도 요청이 시작되는 화면, 서버의 처리, 데이터베이스 조회를 구분하지 못해 원인을 찾는 데 시간이 오래 걸렸습니다.

기능만 말한 설명: 로그인 화면을 구현하고 백엔드 API와 연결했습니다.
구조 이해가 보이는 설명: 사용자가 입력한 이메일과 비밀번호를 클라이언트에서 로그인 API로 전달했습니다. 서버는 회원정보를 조회하고 비밀번호를 확인한 뒤 인증 결과를 응답했습니다. 요청값의 필드 이름이 서버 명세와 달라 인증이 실패한 문제를 브라우저 기록과 서버 로그를 비교해 수정했습니다.

두 번째 문장에서는 화면을 만들었다는 결과보다 데이터가 이동하는 과정과 오류를 확인한 순서가 보입니다. 서버와 클라이언트 구조를 이해해야 하는 이유도 여기에 있습니다. 프레임워크 사용법을 외우기 위해서가 아니라 사용자의 행동이 요청으로 바뀌고 서버의 처리 결과가 다시 화면에 나타나는 전체 흐름을 이해하기 위해서입니다.

이 구조를 이해하면 프로젝트 오류가 화면에서 발생했는지, 요청 과정에서 발생했는지, 서버와 데이터베이스에서 발생했는지 구분할 수 있습니다. 기술면접에서도 API를 사용했다는 설명을 넘어 자신이 구현한 기능의 동작 원리와 문제해결 과정을 구체적으로 전달할 수 있습니다.

웹개발은 화면과 데이터 처리의 역할을 나누는 것에서 시작됩니다

클라이언트는 사용자 행동을 요청으로 바꿉니다

클라이언트를 단순히 사용자가 보는 화면이라고 이해하면 실제 역할을 충분히 설명하기 어렵습니다. 웹 브라우저에서 실행되는 클라이언트는 사용자에게 정보를 보여주는 동시에 입력값을 받고, 필요한 데이터를 서버에 요청하며, 전달받은 결과에 따라 화면 상태를 변경합니다.

게시글 작성 기능을 예로 들어보겠습니다. 사용자가 제목과 내용을 입력한 뒤 등록 버튼을 누르면 클라이언트는 입력값이 비어 있는지 확인하고 서버에서 요구하는 형태로 데이터를 구성합니다. 이후 정해진 주소로 요청을 보내고 성공 여부에 따라 게시글 목록으로 이동하거나 오류를 안내합니다.

화면 중심 설명: 게시글 작성 페이지와 등록 버튼을 구현했습니다.
클라이언트 역할이 보이는 설명: 제목과 내용을 입력받아 필수값을 확인하고 게시글 등록 API에 전달했습니다. 서버가 성공을 반환하면 상세 화면으로 이동하고 입력 오류가 발생하면 작성 내용을 유지한 상태로 안내를 표시했습니다.

클라이언트에서 주로 담당하는 흐름:

화면 표시: 서버에서 받은 데이터를 사용자가 이해할 수 있는 형태로 보여줍니다.
입력 처리: 텍스트, 선택값, 파일 등 사용자가 입력한 내용을 받습니다.
기본 검증: 빈 값과 형식처럼 화면에서 바로 확인할 수 있는 조건을 검사합니다.
요청 생성: 필요한 주소와 메서드, 데이터, 인증 정보를 구성합니다.
상태 변경: 로딩, 성공, 실패 결과에 따라 화면을 바꿉니다.
사용자 안내: 오류가 발생한 이유와 다음 행동을 전달합니다.

클라이언트에서 입력값을 확인했다고 해서 서버의 검증이 필요 없는 것은 아닙니다. 화면의 검사는 사용자가 잘못된 값을 빠르게 수정하도록 돕는 역할이고, 서버의 검사는 직접 요청과 변조된 값을 포함해 데이터의 안전성을 지키는 역할입니다.

서버는 요청을 검증하고 업무 규칙을 처리합니다

서버를 데이터베이스에서 값을 가져오는 영역으로만 이해하면 인증과 권한, 업무 규칙, 오류 처리의 역할을 놓치기 쉽습니다. 서버는 클라이언트의 요청을 받은 뒤 필요한 값이 있는지 확인하고, 요청한 사용자가 해당 기능을 사용할 권한이 있는지 검사하며, 서비스의 규칙에 따라 데이터를 처리합니다.

상품 주문 기능을 예로 들어보겠습니다. 클라이언트가 상품 번호와 수량을 전달했다고 해서 서버가 그대로 주문을 저장해서는 안 됩니다. 상품이 실제로 존재하는지, 재고가 충분한지, 현재 가격은 얼마인지, 로그인한 사용자가 누구인지 확인해야 합니다.

단순한 서버 설명: 주문 요청을 받아 데이터베이스에 저장했습니다.
업무 규칙이 보이는 설명: 상품 번호와 수량을 받은 뒤 상품 존재 여부와 재고를 확인했습니다. 화면에서 전달한 가격을 그대로 사용하지 않고 서버에 저장된 현재 가격으로 주문 금액을 계산했습니다. 재고가 부족하면 주문을 저장하지 않고 실패 원인을 응답했습니다.

서버에서 확인할 내용:

요청에 필요한 값이 포함되어 있는지 검사합니다.
입력 형식과 허용 범위를 확인합니다.
로그인 상태와 사용자 권한을 점검합니다.
데이터베이스에서 필요한 정보를 조회합니다.
서비스의 업무 규칙에 따라 결과를 처리합니다.
성공 또는 실패 내용을 클라이언트에 응답합니다.

한 프로젝트에서는 관리자가 아닌 일반 사용자도 주소를 직접 입력하면 회원 목록을 조회할 수 있었습니다. 화면에서는 관리자에게만 메뉴를 보여줬지만 서버에는 권한 검사가 없었기 때문입니다. 클라이언트에서 버튼을 숨기는 것과 서버에서 접근을 거부하는 것은 서로 다른 역할이라는 점을 보여주는 사례입니다.

데이터베이스는 서버의 요청에 따라 정보를 보관합니다

웹개발을 처음 배우는 학생은 클라이언트가 데이터베이스에 직접 값을 저장한다고 설명하기도 합니다. 일반적인 웹서비스에서는 클라이언트가 서버에 요청하고 서버가 검증과 업무 처리를 거친 뒤 데이터베이스를 조회하거나 변경합니다.

클라이언트가 데이터베이스에 직접 접근하면 접속 정보가 노출될 수 있고 어떤 사용자가 어느 데이터에 접근할 수 있는지 통제하기 어려워집니다. 서버가 중간에서 요청을 확인해야 인증과 권한, 데이터 규칙을 적용할 수 있습니다.

잘못 이해한 흐름: 로그인 화면에서 데이터베이스로 이메일과 비밀번호를 보내 사용자를 확인합니다.
구조에 맞는 흐름: 로그인 화면이 서버에 이메일과 비밀번호를 전달합니다. 서버는 데이터베이스에서 해당 이메일의 회원정보를 조회하고 비밀번호를 확인한 뒤 인증 결과를 클라이언트에 응답합니다.

게시글 수정에서도 같은 구조가 적용됩니다. 클라이언트는 수정할 게시글 번호와 내용을 서버에 전달합니다. 서버는 게시글이 존재하는지, 요청한 사용자가 작성자인지, 수정할 내용이 유효한지 확인합니다. 모든 조건을 통과하면 데이터베이스의 값을 변경하고 처리 결과를 반환합니다.

이러한 역할을 구분하면 특정 기술이 어느 영역에서 사용되는지도 이해하기 쉬워집니다.

React와 Vue: 브라우저 화면과 사용자 상태를 구성합니다.
Spring과 NestJS: 요청을 받고 업무 규칙과 응답을 처리합니다.
MySQL과 PostgreSQL: 회원과 게시글, 주문 등의 정보를 저장합니다.
Redis: 반복 조회되는 값이나 짧게 유지할 상태를 목적에 맞게 관리합니다.

기술 이름을 나열하기보다 프로젝트에서 해당 기술이 어느 영역을 담당했고 다른 영역과 어떻게 연결되었는지 설명해야 합니다.

API통신은 요청과 응답의 약속을 맞추는 과정입니다

URL과 메서드는 요청의 대상과 행동을 구분합니다

API를 서버와 데이터를 주고받는 기능이라고만 외우면 실제 요청이 어떻게 구분되는지 설명하기 어렵습니다. URL은 어떤 자원을 대상으로 하는지 나타내고 HTTP 메서드는 해당 자원에 어떤 행동을 요청하는지 표현합니다.

게시글 기능에서는 같은 게시글 자원을 대상으로 조회, 등록, 수정, 삭제 요청을 나눌 수 있습니다. 프로젝트마다 설계 방식은 달라질 수 있지만 팀 안에서 일관된 기준을 유지하는 것이 중요합니다.

요청 예시:

게시글 목록 조회: GET /posts
게시글 상세 조회: GET /posts/15
새로운 게시글 등록: POST /posts
기존 게시글 수정: PATCH /posts/15
게시글 삭제: DELETE /posts/15

한 학생은 게시글 삭제 요청을 보낼 때 게시글 번호를 주소가 아니라 요청 본문에 넣었습니다. 서버에서는 주소에서 번호를 찾도록 구현되어 있어 삭제할 게시글을 확인하지 못했습니다. 두 담당자가 같은 기능을 만들었지만 데이터가 전달되는 위치를 다르게 이해한 것입니다.

기능 연결만 말한 설명: 게시글 삭제 API를 프런트엔드와 연결했습니다.
통신 기준이 보이는 설명: 삭제할 게시글 번호를 URL 경로에 포함해 DELETE 요청을 보냈습니다. 서버는 주소의 번호로 게시글을 조회하고 작성자 권한을 확인한 뒤 삭제 결과를 응답했습니다.

API를 정리할 때는 주소와 메서드만 적지 말고 다음 내용을 함께 확인해야 합니다.

요청에 필요한 경로와 메서드
주소, 쿼리, 본문에 들어가는 값
인증 정보의 필요 여부
성공했을 때 전달되는 데이터
실패했을 때의 상태 코드와 오류 내용

이러한 약속이 있어야 클라이언트와 서버 담당자가 같은 기준으로 기능을 구현할 수 있습니다.

요청값과 응답값이 일치해야 화면이 정상적으로 동작합니다

프런트엔드와 백엔드가 각각 정상적으로 구현되어 있어도 주고받는 데이터의 이름과 형태가 다르면 기능은 실패할 수 있습니다. 이메일을 email로 보내기로 했는데 클라이언트에서 userEmail로 전달하거나, 서버는 객체를 반환했지만 클라이언트가 배열로 예상하면 문제가 발생합니다.

한 팀 프로젝트에서는 상품 목록 API가 정상적으로 200 응답을 반환했지만 화면에는 아무것도 표시되지 않았습니다. 백엔드 담당자는 데이터를 정상적으로 보냈기 때문에 프런트엔드 문제라고 판단했고, 프런트엔드 담당자는 성공 응답을 받았기 때문에 서버 데이터에 문제가 있다고 생각했습니다.

응답을 확인하니 서버에서는 products라는 항목 안에 상품 배열을 담아 반환했습니다. 클라이언트에서는 응답 전체가 배열이라고 생각하고 반복 처리를 시도했습니다.

예상한 응답: 상품 배열이 바로 전달됩니다.
실제 응답: 응답 객체 안의 products 항목에 상품 배열이 들어 있습니다.
수정한 내용: 클라이언트에서 products 항목을 사용하도록 변경하고 데이터가 없을 때는 빈 배열을 적용했습니다.
재검증 결과: 상품이 있는 경우와 없는 경우, 서버 요청에 실패한 경우를 각각 확인했습니다.
단순한 오류 설명: 상품 목록이 나오지 않아 응답 처리 코드를 수정했습니다.

데이터 구조가 보이는 설명: API는 성공했지만 화면이 비어 있어 네트워크 응답을 확인했습니다. 서버는 객체 안에 상품 배열을 반환했지만 클라이언트는 응답 전체를 배열로 처리하고 있었습니다. 실제 구조에 맞게 수정한 뒤 빈 목록과 실패 응답까지 다시 확인했습니다.

이러한 경험은 API를 연결했다는 문장보다 서버와 클라이언트 사이의 데이터 약속을 이해하고 있다는 근거가 됩니다.

상태 코드는 처리 결과를 구분하는 기준입니다

상태 코드를 숫자로만 외우면 실제 프로젝트에서 어떻게 활용해야 하는지 설명하기 어렵습니다. 클라이언트는 서버가 반환한 상태를 기준으로 성공 화면을 보여주거나 로그인 페이지로 이동하고, 입력 오류와 서버 오류를 서로 다르게 안내할 수 있습니다.

로그인 요청이 실패했다고 가정해 보겠습니다. 입력한 정보가 올바르지 않은 경우, 로그인이 필요한 페이지에 인증 없이 접근한 경우, 권한이 없는 사용자가 관리자 기능을 요청한 경우는 서로 다른 상황입니다.

구분해야 할 결과:

200대: 요청이 정상적으로 처리되었습니다.
400: 요청값의 형식이나 필수값에 문제가 있습니다.
401: 인증 정보가 없거나 유효하지 않습니다.
403: 로그인했지만 해당 기능을 사용할 권한이 없습니다.
404: 요청한 데이터나 주소를 찾을 수 없습니다.
500대: 서버 내부 처리 과정에서 문제가 발생했습니다.

한 프로젝트에서는 서버의 모든 실패를 500으로 반환했습니다. 클라이언트에서는 비밀번호가 틀린 경우와 서버 장애를 구분할 수 없어 모두 잠시 후 다시 시도하라는 문구를 표시했습니다. 사용자는 입력 정보를 고쳐야 하는지 기다려야 하는지 알 수 없었습니다.

상태 코드만 외운 설명: 200은 성공이고 404는 찾을 수 없음, 500은 서버 오류입니다.
프로젝트에 적용한 설명: 로그인 실패를 입력 오류와 인증 실패, 서버 처리 오류로 구분했습니다. 클라이언트는 응답 상태에 따라 입력값 확인, 로그인 이동, 재시도 안내를 다르게 표시했습니다.

상태 코드는 시험을 위한 숫자가 아니라 서버의 처리 결과를 클라이언트가 해석할 수 있게 만드는 약속입니다. 자신이 만든 기능에서 어떤 실패를 어떻게 구분했는지 설명할 수 있어야 합니다.

면접기초는 요청 흐름을 자신의 프로젝트로 설명하는 것입니다

사용자 행동부터 화면 변화까지 순서대로 설명해야 합니다

기술면접에서 서버와 클라이언트의 차이를 묻는 이유는 정의를 외웠는지만 확인하기 위해서가 아닙니다. 지원자가 자신이 구현한 기능의 전체 흐름을 이해하고 있는지 살펴보기 위해서입니다.

로그인 기능을 설명할 때 사용자가 이메일과 비밀번호를 입력한다는 시작점부터 인증 결과가 화면에 반영되는 과정까지 연결해야 합니다.

로그인 처리 흐름:

사용자가 클라이언트 화면에서 이메일과 비밀번호를 입력합니다.
클라이언트는 입력값의 기본 형식을 확인합니다.
로그인 API에 필요한 데이터를 담아 서버로 요청합니다.
서버는 이메일로 회원정보를 조회합니다.
입력한 비밀번호와 저장된 값을 비교합니다.
인증에 성공하면 이후 요청에 필요한 인증 정보를 반환합니다.
클라이언트는 인증 상태를 반영하고 사용자를 다음 화면으로 이동시킵니다.
정의만 말한 답변: 클라이언트가 요청하면 서버가 데이터를 처리해 응답합니다.

프로젝트 흐름이 보이는 답변: 로그인 버튼을 누르면 클라이언트가 이메일과 비밀번호를 로그인 API로 전달합니다. 서버는 회원정보를 조회해 비밀번호를 확인하고 인증 결과를 응답합니다. 클라이언트는 성공 여부에 따라 메인 화면으로 이동하거나 입력 정보를 다시 확인하도록 안내합니다.

기능 하나를 처음부터 끝까지 설명할 수 있다면 화면, 서버, 데이터베이스의 역할도 자연스럽게 구분할 수 있습니다.

오류가 발생한 구간을 좁힌 경험이 이해도를 보여줍니다

프로젝트에서 API 오류가 발생했다는 말만으로는 어느 영역에 문제가 있었는지 알 수 없습니다. 브라우저에서 요청이 만들어지지 않았는지, 서버에 도착하지 않았는지, 서버가 처리하다 실패했는지, 데이터베이스 조회 결과가 예상과 달랐는지 구분해야 합니다.

한 학생은 배포 후 로그인 요청이 실패하자 서버 코드부터 수정하려고 했습니다. 그러나 브라우저의 네트워크 기록에는 로그인 요청 자체가 없었습니다. 버튼 클릭 이벤트에서 입력값 검증을 통과하지 못해 요청이 생성되지 않은 것이 원인이었습니다.

다른 프로젝트에서는 요청이 서버까지 도착했고 서버도 200 응답을 반환했지만 화면이 바뀌지 않았습니다. 클라이언트가 응답 항목의 이름을 잘못 읽고 있어 로그인 상태가 반영되지 않았습니다.

오류 확인 순서:

클라이언트: 버튼 이벤트와 입력값, 요청 생성 여부를 확인합니다.
네트워크: 요청 주소와 메서드, 전달값, 응답 상태를 살펴봅니다.
서버: 요청이 도착했는지와 어느 처리 단계에서 실패했는지 확인합니다.
데이터베이스: 조회 조건과 실제 저장된 값을 비교합니다.
응답 처리: 서버 결과가 클라이언트 상태와 화면에 반영되는지 점검합니다.
결과만 말한 설명: 로그인 API 오류를 해결했습니다.
확인 순서가 보이는 설명: 브라우저 기록에서 요청이 서버에 도착한 것을 확인한 뒤 서버 로그와 회원정보 조회 결과를 비교했습니다. 이메일 필드 이름이 달라 조회값이 비어 있다는 원인을 찾았습니다.
수정 이후까지 포함한 설명: 요청값을 서버 명세와 맞춘 뒤 로그인 성공과 비밀번호 오류, 존재하지 않는 계정, 인증이 필요한 화면 접근을 다시 확인했습니다.

이러한 설명은 단순히 오류를 고쳤다는 결과보다 웹 구조를 이해하고 문제 범위를 좁힐 수 있다는 근거가 됩니다.

프레임워크 이름보다 각 영역의 판단을 설명해야 합니다

면접에서 React와 Spring을 사용했다고 답하면 왜 두 기술이 필요한지, 각각 무엇을 담당했는지 추가 질문이 이어질 수 있습니다. 이때 프런트엔드와 백엔드를 만들기 위해 사용했다는 설명만 반복하면 기술 사용 경험이 얕게 보일 수 있습니다.

기술 나열형 답변: React, Spring Boot, MySQL을 사용해 웹서비스를 개발했습니다.
역할이 구분된 답변: React에서는 사용자의 입력과 화면 상태, 서버 응답에 따른 화면 변화를 처리했습니다. Spring Boot에서는 요청 검증과 인증, 게시글 업무 규칙을 구현했고 MySQL에는 회원과 게시글 데이터를 저장했습니다.
연결 과정이 포함된 답변: React에서 작성한 게시글 등록 요청을 Spring Boot API로 전달했습니다. 서버에서는 로그인 사용자와 입력값을 확인한 뒤 MySQL에 저장하고 생성된 게시글 정보를 응답했습니다. 클라이언트는 응답을 받아 상세 화면으로 이동했습니다.

면접 전에는 자신의 프로젝트 기능별로 다음 내용을 정리하는 것이 좋습니다.

사용자에게 어떤 화면과 행동을 제공했는가
클라이언트는 어떤 요청을 만들었는가
서버는 어떤 검증과 규칙을 처리했는가
데이터베이스에는 어떤 정보가 저장되었는가
서버의 결과가 화면에 어떻게 반영되었는가
오류가 발생했을 때 어느 구간부터 확인했는가

이 질문에 답할 수 있다면 서버와 클라이언트의 정의를 외우는 수준을 넘어 실제 프로젝트 구조를 이해하고 있다는 사실을 보여줄 수 있습니다.

conclusion

서버와 클라이언트 구조를 이해해야 하는 이유는 웹개발 용어를 더 많이 외우기 위해서가 아닙니다. 사용자의 행동이 요청으로 만들어지고, 서버와 데이터베이스의 처리를 거쳐, 다시 화면의 변화로 이어지는 전체 흐름을 이해하기 위해서입니다.

클라이언트는 화면만 그리는 영역이 아닙니다. 사용자의 입력을 받고 기본적인 형식을 확인하며 서버에 필요한 요청을 만들고 응답 결과에 따라 화면 상태를 변경합니다. 서버는 요청을 단순히 데이터베이스로 전달하는 영역이 아닙니다. 입력값과 인증, 권한을 확인하고 서비스의 업무 규칙에 따라 데이터를 처리합니다.

API통신은 두 영역이 정한 약속을 기준으로 이루어집니다. 요청 주소와 HTTP 메서드, 전달값, 응답 구조, 상태 코드가 일치해야 기능이 정상적으로 연결됩니다. 한쪽의 코드가 올바르더라도 데이터 이름과 형태를 다르게 이해하면 화면에는 오류가 발생할 수 있습니다.

웹개발: 클라이언트와 서버, 데이터베이스의 역할을 구분합니다.
API통신: URL, 메서드, 요청값, 응답값, 상태 코드를 연결합니다.
오류 확인: 클라이언트 → 네트워크 → 서버 → 데이터베이스 → 응답 처리 순서로 살펴봅니다.
프로젝트 설명: 사용자 행동부터 화면 변화까지 기능의 전체 흐름을 작성합니다.
면접 준비: 사용한 기술 이름보다 각 영역에서 담당한 판단과 처리를 말합니다.

실제 포트폴리오를 검토하면 API를 구현하거나 연결했다는 문장은 많지만 요청에 어떤 값이 들어가고 서버가 무엇을 처리했는지는 빠진 경우가 있습니다. 화면 오류가 발생하면 무조건 백엔드 문제라고 판단하거나, 서버가 200을 반환했기 때문에 기능 전체가 정상이라고 생각하기도 합니다.

반대로 회원가입이나 게시글 작성 기능 하나라도 클라이언트의 입력 처리, 서버의 검증, 데이터베이스 저장, 응답 이후 화면 변화를 순서대로 설명할 수 있다면 프로젝트의 깊이가 달라집니다. 오류가 발생했을 때 브라우저 기록과 서버 로그, 저장된 데이터를 비교한 경험까지 있다면 문제해결 역량도 함께 보여줄 수 있습니다.

자신의 프로젝트에서 가장 익숙한 기능 하나를 선택해 보세요. 사용자가 처음 어떤 행동을 하는지, 클라이언트가 어떤 요청을 만들었는지, 서버가 무엇을 확인했는지, 데이터가 어떻게 바뀌었는지, 결과가 화면에 어떻게 나타났는지를 순서대로 작성해야 합니다.

이 내용은 다음 순서로 정리할 수 있습니다.