백엔드 동작 원리

브라우저 주소창에 URL을 입력하고 엔터를 누르는 순간부터 화면에 응답이 그려지기까지, 요청은 여러 단계를 거친다. 백엔드를 이해한다는 건 이 흐름의 ‘서버 쪽 절반’을 그릴 수 있다는 뜻이다.

• 주소 변환(DNS): 도메인 이름을 실제 서버 IP로 바꾼다.
• 연결 수립(TCP/TLS): 서버와 연결을 맺고, HTTPS면 암호화 핸드셰이크를 추가로 한다.
• HTTP 요청 전송: 메서드·경로·헤더·본문이 담긴 요청 메시지를 보낸다.
• 서버 처리: 라우팅 → 검증 → 비즈니스 로직 → 데이터 접근을 거쳐 응답을 만든다.
• HTTP 응답 반환: 상태 코드와 본문을 돌려준다. 연결은 재사용되거나 닫힌다.

요청이 서버에 도착하면 가장 먼저 만나는 건 보통 웹서버다. 정적인 파일은 웹서버가 직접 내려주고, 로직이 필요한 요청만 뒤쪽의 애플리케이션 서버(WAS)로 넘긴다. 이 역할 분담을 이해하면 배포 구조가 한결 선명해진다.

WAS 안으로 들어온 요청은 보통 컨트롤러 → 서비스 → 리포지토리 순으로 흐른다. 각 계층은 자기 책임만 지고 아래 계층에만 의존한다. 이 단방향 흐름이 변경의 파급을 가두고, 테스트와 유지보수를 쉽게 만든다.

// 1) 컨트롤러: HTTP를 다루는 얇은 어댑터
POST /orders → OrderController.create(req)
   ↓ 입력 검증 후 도메인 입력으로 변환
// 2) 서비스: 비즈니스 규칙과 트랜잭션 경계
   OrderService.place(command)
   ↓ 재고 확인·금액 계산 등 '진짜 로직'
// 3) 리포지토리: 데이터 저장소 접근
   OrderRepository.save(order)
   ↓
[ Database ]

이 계층 패턴을 Spring으로 구현한 구체적인 모습(애너테이션·DI·트랜잭션)은 Spring Boot 실무 패턴 글에서 이어서 본다.

트래픽이 늘면 서버를 더 강하게(수직) 만들기보다, 같은 서버를 여러 대 띄워(수평) 나눠 받는 편이 보통 낫다. 그런데 수평 확장이 가능하려면 서버가 ‘무상태(stateless)’ 여야 한다.

서버는 동시에 들어오는 여러 요청을 어떻게 처리할까? 전통적인 모델은 요청마다 스레드를 하나씩 배정하는 방식이다. 이때 ‘스레드’와 ‘DB 커넥션’은 무한하지 않은 자원이라는 점이 성능의 핵심이 된다.