내가 Google.com에 접속했을 때 - API Network

Elena·2026년 1월 22일

google.com 같은 사이트에 접속할 때 실제로 무슨 일이 벌어지는지를 이해하기 위한 오늘의 주제. API 네트워크 단계를 정리해보았다.

[네트워크]
DNS → TCP → HTTPS → index.html 다운로드
↓
[브라우저]
HTML 파싱 → JS 번들 다운로드
↓
[자바스크립트]
React/Vue 앱 실행
↓
[API 네트워크]
백엔드 API 호출
↓
[렌더링]
DOM 생성 → 화면에 UI 표시

1. [API 네트워크] 백엔드 API 호출

사용자가 화면의 버튼을 누르거나 페이지가 로드되면, 프론트엔드 코드(React/Vue)는 fetch나 Axios 같은 라이브러리를 사용하여 백엔드 서버에 HTTP 요청

1) AJAX와 비동기 통신

특징: 페이지 전체를 새로고침하지 않고, 필요한 데이터만 백엔드에서 받아옴
데이터 포맷: 과거에는 XML을 썼으나, 현재는 거의 100% JSON(JavaScript Object Notation) 형식을 사용.

2) 인증과 인가 (Auth)

Header 정보: 요청을 보낼 때 Authorization 헤더에 JWT(JSON Web Token)나 세션 ID를 담아 "내가 누구인지"를 증명. 백엔드는 이 토큰을 검증하여 데이터를 줄지 말지 결정.

2. 백엔드 개발자의 첫 번째 관문: CORS

이 단계에서 가장 많이 마주치는 에러가 바로 CORS(Cross-Origin Resource Sharing) 에러

원인: 브라우저는 보안상의 이유로 내 도메인(google.com)이 아닌 다른 도메인(https://www.google.com/search?q=api.google.com)으로 요청을 보내는 것을 기본적으로 차단한다.
해결: 백엔드 서버(Spring Boot 등)에서 이 도메인의 요청을 허락하는 설정을 따로 해야 함.

1) CORS 설정의 3요소

백엔드에서 다음 세 가지를 허용해줘야 브라우저가 안심하고 데이터를 가져감

Allow Origin: 허용할 도메인 (예: https://my-frontend.com)

Allow Methods: 허용할 HTTP 메서드 (GET, POST, PUT, DELETE 등)

Allow Headers: 허용할 헤더 (인증을 위한 Authorization, Content-Type 등)

2) Spring Boot에서의 설정 방법

1) 어노테이션 방식 (특정 컨트롤러만 허용)
특정 API만 외부에서 접근하게 하고 싶을 때 사용합니다.

Java

@RestController
@RequestMapping("/api")
@CrossOrigin(origins = "http://localhost:3000") // 특정 도메인만 허용
public class ApiController {
    // ...
}

2) 전역 설정 방식 (가장 권장됨)
프로젝트 전체에 일관된 규칙을 적용할 때 사용. WebMvcConfigurer를 구현.

Java

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**") // 모든 경로에 대해
                .allowedOrigins("https://my-frontend.com", "http://localhost:3000") // 허용 도메인
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") // 허용 메서드
                .allowedHeaders("*") // 모든 헤더 허용
                .allowCredentials(true) // 쿠키/인증 정보를 포함할지 여부
                .maxAge(3600); // Preflight 요청을 캐싱할 시간 (초 단위)
    }
}

3) Preflight(OPTIONS) 요청과 성능 -> prefilght에 대한 설명은 다음 3번에서 설명

Preflight는 매번 발생하면 네트워크 비용이 듦

maxAge 설정: 백엔드에서 maxAge를 설정해주면 브라우저가 일정 시간 동안 OPTIONS 요청 결과를 캐싱하고 그 덕분에 실제 데이터 요청 속도가 빨라진다.

4) 실무 주의사항

(Wildcard) 자제: 테스트 환경에서는 allowedOrigins("*")가 편하지만, 보안상 실제 서비스에서는 허용할 도메인을 명확히 적어주는 것이 바람직
Credentials 주의: allowCredentials(true)를 설정했다면, allowedOrigins에 *를 쓸 수 없다. 반드시 구체적인 도메인을 명시해야 함
Spring Security: 만약 프로젝트에 Spring Security를 사용 중이라면, WebMvc 설정 외에 Security 필터 체인에서도 CORS 설정을 별도로 해줘야 에러가 나지 않음

3. Preflight(예비 요청)의 등장

브라우저는 실제 데이터를 요청하기 전에, 안전한지 확인하기 위해 OPTIONS 메서드로 미리 한 번 확인.

Preflight: "나 이런 요청(POST, PUT 등) 보낼 건데 괜찮니?" (OPTIONS 요청)
Response: 백엔드가 "응, 우리 서버는 허용해!"라고 응답.
Actual Request: 그제야 브라우저가 진짜 데이터를 담은 요청을 보냄

4. 백엔드의 처리와 응답

Controller: 요청을 받아 파라미터를 검증

Service: 비즈니스 로직을 처리

Repository: DB에 접속하여 데이터를 조회하거나 수정

응답: 처리 결과를 200 OK 또는 404 Not Found 같은 상태 코드와 함께 JSON으로 프론트엔드에 반환

* API 성능 최적화(Caching)

백엔드 개발자에게 캐싱(Caching)은 시스템의 성능과 확장성을 결정짓는 핵심 무기. API 호출에서 백엔드가 매번 무거운 DB 조회를 하지 않고 데이터를 빠르게 돌려주는 전략은?

1) 캐싱의 기본 원리: 파레토 법칙

캐싱은 전체 요청의 80%는 20%의 데이터에 집중된다는 원리에 기반한다. 자주 찾는 데이터(Hot Data)를 느린 저장소(Disk/DB)가 아닌 빠른 저장소(Memory)에 미리 두는 것이 핵심

2) 위치에 따른 캐싱 전략

로컬 캐시 (Local Cache)

설명: 애플리케이션(Spring Boot 등) 내부 메모리에 데이터를 저장
장점: 네트워크 통신이 없어 속도가 극도로 빠르다.
단점: 서버가 여러 대일 경우 서버 간 데이터 불일치가 발생할 수 있다.
기술: Ehcache, Caffeine Cache

글로벌 캐시 (Distributed Cache)

설명: 별도의 캐시 서버(Redis 등)를 두고 여러 서버가 공유
장점: 서버가 늘어나도 데이터 일관성이 유지되며, 대용량 처리에 유리
단점: 네트워크를 한 번 거쳐야 하므로 로컬 캐시보다는 약간 느림
기술: Redis, Memcached

3) 읽기/쓰기 패턴에 따른 전략

읽기 전략 (Read Strategy)
Look Aside (가장 일반적):
- 앱이 먼저 캐시를 확인
- 데이터가 없으면(Cache Miss) DB에서 가져와 캐시에 저장하고 응답.
- 장점: 캐시 서버가 죽어도 DB를 통해 서비스가 유지됨
Read Through:
- 앱은 캐시 서버에서만 데이터를 읽는다.
- 캐시가 직접 DB에서 데이터를 채워준다.
쓰기 전략 (Write Strategy)
Write Around:
- 데이터를 DB에만 쓴다. 캐시는 읽기 요청이 올 때만 업데이트
- 단점: 캐시와 DB의 데이터가 다를 수 있는 기간이 생김
Write Back:
- 데이터를 캐시에 먼저 모아서 쓰고, 나중에 한꺼번에 DB에 반영
- 장점: 쓰기 작업이 많은 서비스(로그, 좋아요 수 등)에서 DB 부하를 획기적으로 줄인다.
- 단점: 캐시 서버가 장애 나면 데이터가 손실될 위험이 있다.