[Spring Boot] 웹 아키텍처 설계의 여정 (3): 주소창에 URL을 치면 일어나는 일 (Network & Controller)

1. 서론: 코드가 세상과 연결되는 방식

이전 글에서 SSR과 CSR의 렌더링 차이를 이해하고, 하이브리드 아키텍처를 설계했다. 이제 시야를 넓혀 네트워크 레벨에서의 데이터 흐름을 파악해본다.

사용자가 브라우저 주소창에 www.virtual-exchange.com을 입력했을 때, 이 문자열은 어떻게 해석되며 어떤 과정을 거쳐 내 로컬 환경의 Spring Boot 컨트롤러에 도달하는가? 이번 글에서는 네트워크의 연결 흐름과 Spring MVC 내부의 요청 처리 과정을 해부한다.

2. URL 해부학: 리소스 식별을 위한 규약

우리가 흔히 사용하는 URL(Uniform Resource Locator)은 단순한 주소가 아니라, 서버 자원에 접근하기 위한 구체적인 프로토콜 명세다. http://www.virtual-exchange.com:80/stocks라는 URL을 기술적으로 분해해보자.

• Protocol (Scheme): 통신 규약을 정의한다. http 혹은 보안 계층(SSL/TLS)이 적용된 https를 사용하여 브라우저와 서버가 서로 알아들을 수 있는 방식으로 데이터를 주고받음을 명시한다.
• Domain (Host): 사람이 식별하기 쉬운 문자열 형태의 호스트명이다. 컴퓨터는 이를 이해할 수 없으므로 실제 통신을 위해서는 IP 주소로 변환하는 과정(DNS Lookup)이 선행되어야 한다.
• Port: 서버 컴퓨터 내에서 실행 중인 특정 프로세스(애플리케이션)를 식별하는 논리적 주소다.
  • 웹 통신 표준인 80(HTTP), 443(HTTPS)은 생략 가능하며(Well-known Port), 개발 환경의 Tomcat은 주로 8080을 사용한다.
• Path: 서버 내에 존재하는 구체적인 자원(Resource)의 위치 혹은 식별자다. Spring Boot의 RequestMapping URI와 매핑되는 부분이다.

3. 네트워크의 여행: 패킷의 전달과 소켓 연결

엔터 키를 입력하는 순간, OS의 네트워크 스택에서는 다음과 같은 일이 발생한다.

Step 1: DNS Lookup (IP 주소 획득) 브라우저는 호스트명(virtual-exchange.com)만으로는 통신할 수 없다. OS는 설정된 DNS 서버에 쿼리를 전송하여 도메인에 매핑된 **A Record(IPv4 주소)**를 조회한다. (예: www.virtual-exchange.com → 223.130.195.200)

Step 2: Socket Binding & Port 식별 서버 측(Spring Boot)은 이미 실행 시점에 OS에게 특정 포트(예: 8080) 사용을 요청하고, 해당 포트를 점유한 채 LISTEN 상태로 대기 중이다. 이를 **포트 바인딩(Port Binding)**이라 한다. 클라이언트의 요청 패킷에는 목적지 IP뿐만 아니라 목적지 포트가 포함되어 있다. 서버 OS는 패킷을 수신하면 포트 번호를 확인하고, 해당 포트를 리스닝 중인 Spring Boot(Tomcat) 프로세스로 데이터를 전달한다.

Step 3: TCP 3-Way Handshake 데이터를 주고받기 전, 신뢰성 있는 연결을 위해 TCP 핸드셰이크가 수행된다.

1. SYN: 클라이언트가 서버에 연결 요청
2. SYN-ACK: 서버가 요청을 수락하고 응답
3. ACK: 클라이언트가 수락 확인 후 연결 수립 (Established)

4. 스프링 부트 내부: DispatcherServlet의 분기 처리

요청이 서블릿 컨테이너(Tomcat)를 통과해 Spring 애플리케이션에 도달하면, DispatcherServlet이 모든 요청을 가장 먼저 받아 적절한 핸들러(Controller)로 라우팅한다. 이때 개발자가 가장 혼동하기 쉬운 @Controller와 @RestController의 차이는 응답 본문(Body)의 처리 방식에 있다.

(1) @Controller (View 반환)

• 동작 원리: 메서드가 반환하는 문자열(String)을 View Name으로 인식한다.
• 처리 과정: ViewResolver가 동작하여 templates/ 폴더 하위의 HTML 파일(Thymeleaf 등)을 찾고, 모델 데이터를 바인딩하여 렌더링 된 HTML(View)을 응답한다.
• 용도: SSR(Server Side Rendering)이 필요한 페이지 반환.

(2) @RestController (Data 반환)

• 동작 원리: @Controller에 @ResponseBody가 결합된 형태다. 리턴 값을 View로 찾지 않고, HTTP Response Body에 직접 쓴다.
• 처리 과정: HttpMessageConverter(주로 Jackson 라이브러리)가 동작하여, 자바 객체(Object)를 JSON 포맷의 텍스트로 직렬화(Serialization)하여 응답한다.
• 용도: CSR, 모바일 앱, 외부 API 연동 등 데이터 중심 통신.

5. 결론: 전체 아키텍처를 관통하는 시야

단순히 코드를 작성하는 것을 넘어, **"URL 입력 → DNS 해석 → IP/Port를 통한 프로세스 식별 → DispatcherServlet의 라우팅 → ViewResolver 혹은 MessageConverter의 동작"**으로 이어지는 전체 파이프라인을 이해했다.