백엔드 개발자란?
백엔드 개발자는 사용자의 요청을 받아서, 필요한 데이터를 찾고 처리한 뒤, 다시 사용할 수 있는 응답으로 돌려주는 서버 쪽 흐름을 만드는 사람이다.
다른 사람들은 어떻게 말할까?
MDN의 HTTP 개요를 보면 웹은 기본적으로 클라이언트와 서버가 요청과 응답을 주고받는 구조로 설명된다.
브라우저 같은 클라이언트가 서버에 HTTP 요청을 보내고, 서버는 그 요청을 처리한 뒤 HTTP 응답을 돌려준다.
또 MDN의 서버 사이드 프로그래밍 소개에서는 서버 쪽 코드가 주로 다음 일을 한다고 설명한다.
- 요청받은 데이터를 검증한다
- 데이터베이스에서 데이터를 저장하거나 조회한다
- 사용자에게 필요한 정보를 응답으로 보낸다
- 로그인한 사용자처럼 상황에 따라 다른 내용을 보여준다
Spring 공식 가이드에서도 RESTful Web Service 예제에서 HTTP 요청이 Controller에 의해 처리되고, 객체가 JSON 응답으로 변환되는 흐름을 보여준다.
그냥 API 만드는 사람아닌가?
처음 백엔드를 공부하면 이런 생각이 들 수 있다.
"백엔드는 그냥 API 만드는 사람 아닌가?"
틀린 말은 아니지만, 조금 부족하다.
API는 백엔드가 바깥과 대화하기 위해 열어둔 창구에 가깝다. 실제 백엔드 개발자는 그 창구 뒤에서 다음 일을 함께 고민한다.
- 이 요청이 올바른 요청인지
- 이 사용자가 이 기능을 써도 되는지
- 어떤 데이터를 조회해야 하는지
- 데이터를 어떻게 바꿔야 하는지
- 실패하면 어떤 응답을 줘야 하는지
- 운영 중 문제가 생겼을 때 어떻게 추적할지
즉, 백엔드는 단순히 URL 하나를 만드는 일이 아니라 요청이 들어온 뒤 서버 안에서 일어나는 흐름을 설계하고 구현하는 일에 가깝다.
백엔드를 비유하자면?
백엔드를 식당에 비유해보면 이해하기 쉽다.
사용자가 브라우저나 앱에서 버튼을 누르는 것은 손님이 주문서를 내는 것과 비슷하다.
손님: 김치찌개 하나 주세요.
직원: 주문을 확인한다.
주방: 재료를 확인하고 음식을 만든다.
직원: 완성된 음식을 손님에게 전달한다.웹에서는 이 흐름이 이렇게 바뀐다.
사용자: 회원 정보를 보여주세요.
브라우저: GET /users/1 요청을 보낸다.
서버: 요청을 확인한다.
서버: DB에서 회원 정보를 찾는다.
서버: JSON 형태로 응답한다.
브라우저: 화면에 회원 정보를 보여준다.여기서 백엔드 개발자가 만드는 것은 단순히 GET /users/1이라는 주소 하나가 아니다.
그 요청을 받았을 때 서버가 어떤 순서로 판단하고, 어떤 데이터를 가져오고, 어떤 모양으로 응답할지 정하는 전체 흐름이다.
코드로 알아보자
Spring Boot에서는 이런 식으로 아주 작은 API를 만들 수 있다.
@RestController
public class UserController {
@GetMapping("/users/{id}")
public UserResponse getUser(@PathVariable Long id) {
return new UserResponse(id, "junior-backend");
}
}이 코드는 간단하지만, 백엔드의 기본 흐름이 들어 있다.
1. 클라이언트가 /users/1 로 요청한다.
2. 서버는 /users/{id}에 해당하는 메서드를 찾는다.
3. id 값으로 1을 받는다.
4. UserResponse 객체를 만든다.
5. JSON 응답으로 돌려준다.응답은 대략 이렇게 보일 수 있다.
{
"id": 1,
"name": "junior-backend"
}실제 프로젝트에서는 여기에 더 많은 일이 붙는다.
그래서 백엔드 개발은 "API 만들기"에서 끝나지 않는다. 요청이 들어와서 응답이 나가기까지의 길을 안정적으로 만드는 일이다.
코드를 만들 때 조심할 점
백엔드를 처음 만들 때 가장 조심해야 할 점은 일단 동작하는 코드와 좋은 서버 코드를 같은 것으로 착각하는 것이다.
예를 들어 Controller 안에 모든 코드를 넣어도 처음에는 동작할 수 있다.
@GetMapping("/users/{id}")
public UserResponse getUser(@PathVariable Long id) {
// DB 조회
// 권한 체크
// 예외 처리
// 응답 변환
// 전부 여기서 처리
}하지만 기능이 많아지면 금방 읽기 어려워진다. 그래서 보통은 역할을 나눈다.
| 구성 요소 | 역할 | 식당 비유 |
|---|---|---|
| Controller | 요청을 받고 응답을 돌려주는 입구 | 주문 접수대 |
| Service | 실제 비즈니스 규칙을 처리하는 곳 | 요리 계획을 세우는 셰프 |
| Repository | 데이터베이스와 대화하는 곳 | 재료를 가져오는 직원 |
| Database | 데이터 저장소 | 식재료 창고 |
| DTO | 요청과 응답 데이터를 담는 그릇 | 주문서 / 완성된 음식 포장 |
처음부터 완벽한 구조를 만들 필요는 없다. 다만 "지금 이 코드는 어떤 역할을 하고 있지?"를 계속 물어보는 습관은 중요하다.
정리
백엔드 개발자는 서버에서 실행되는 코드를 작성한다.
조금 더 구체적으로 말하면, 백엔드 개발자는 다음 흐름을 만든다.
요청을 받는다
-> 요청을 이해한다
-> 필요한 검증을 한다
-> 데이터를 조회하거나 변경한다
-> 비즈니스 규칙을 적용한다
-> 응답을 만든다
-> 문제가 생기면 추적할 수 있게 한다처음에는 백엔드가 API를 만드는 일처럼 보였다. 그런데 공식문서를 보고 HTTP 요청과 응답 구조를 다시 보면, 백엔드는 결국 사용자의 요청을 서버가 이해하고 처리할 수 있는 흐름으로 바꾸는 일이라는 생각이 든다.
앞으로 백엔드를 공부할 때는 새로운 기술을 배울 때마다 이렇게 고민하면 좋다.
이 기술은 요청과 응답 사이의 어느 부분을 더 편하게, 더 안전하게, 더 명확하게 만들어주는 걸까?
이 질문을 기준으로 보면 Controller, Service, Repository, DTO, Transaction, Security 같은 개념들이 조금씩 연결되기 시작한다.
