L1 백엔드 & API 입구

분류: Layer 1 - 백엔드 & API

핵심 질문

클라이언트와 서버는 네트워크 너머에서 요청의 의도, 신원과 권한, 실패의 의미, 통신 방식을 어떻게 합의하는가?

3줄 요약

L1을 읽으면 API 장애를 상태 코드 하나로 뭉개지 않고, 계약·인증·권한·보안·연결 문제로 나누어 볼 수 있다.
브라우저나 모바일 앱에서 API 요청과 응답을 본 경험이 있다면 그것이 출발점이다. 이제 서버가 그 호출의 의미와 비용, 신뢰 경계, 연결 수명을 책임지는 관점으로 전환한다.
첫 회독의 목표는 모든 프로토콜 세부를 외우는 것이 아니라 요청/응답 → 계약 → 신원과 권한 → 신뢰 경계 → 통신 방식 선택 지도를 만드는 것이다.

1. 선행 단계의 한계 → L1의 등장 이유 → 해결 관점

앞 단계에서 서버 코드를 실행하고 클라이언트가 요청을 보낼 수 있어도, 개별 호출만으로는 서로 다른 배포 주기를 가진 주체가 같은 의미를 유지하기 어렵다. 누가 요청했는지, 허용된 행동인지, 외부 입력을 어디까지 믿을지, 요청-응답이 아닌 통신이 필요한지도 아직 답하지 못한다.

이 한계에서 L1이 등장한다. L1은 HTTP로 요청과 응답의 공통 언어를 잡고, API 설계로 변경 가능한 계약을 만들며, 이후 보안 경계와 통신 방식 선택으로 판단 범위를 넓힌다.

해결 관점은 하나다. 서버 내부 구현부터 보는 대신 네트워크 경계에 드러난 의미, 신원과 권한, 신뢰, 통신 방향을 차례로 확인한다.

2. 이미 알고 있는 것에서 출발하기

Network 탭에서 본 URL, 메서드, 상태 코드, 헤더, JSON 응답은 L1의 공통 언어다. 다만 L1에서는 이를 호출 방법이 아니라 서로 독립적으로 변경되는 주체 사이의 계약으로 본다.

계약만으로는 충분하지 않다. 서버는 요청자를 확인하고, 행동을 허용할지 판단하고, 외부 입력이 데이터인지 명령인지 구분하며, 요청량과 열린 연결이 자원을 얼마나 쓰는지도 책임져야 한다. 이때부터 API는 단순한 데이터 통로가 아니라 의미·신뢰·비용을 함께 관리하는 경계가 된다.

3. 새로 배워야 하는 사고 모델

L1에서는 아래 네 질문을 반복해서 던지면 된다.

의미는 어디에 적혀 있는가? URL, 메서드, 상태 코드, 헤더, 스키마가 요청과 응답의 의미를 나누어 표현한다.
판단 주체는 누구인가? 인증은 요청자가 누구인지 확인하고, 인가는 그 주체가 특정 리소스에 특정 행동을 해도 되는지 결정한다.
어느 경계에서 믿을 수 있는가? 입력 검증과 출력 인코딩은 애플리케이션이 다루는 값의 경계를 지킨다. TLS(Transport Layer Security)에서 서버 인증서는 서버 신원을 검증하고, TLS record protection은 전송 데이터의 기밀성과 무결성을 제공한다. WAF(Web Application Firewall)는 HTTP 요청을 검사해 애플리케이션에 도달하는 악성 패턴과 비정상 트래픽을 줄이는 방어 계층이다. 애플리케이션 정책은 인증된 주체가 허용된 행동만 수행하게 한다.
요청-응답을 벗어날 이유가 충분한가? 실시간성이라는 이름만으로 기술을 고르지 않고, 통신 방향·호출 주체·계약 강도·연결 운영 비용을 함께 본다.

이 네 질문은 순서대로 쌓인다. HTTP의 의미를 모르면 API 계약을 설명하기 어렵고, 계약과 인증·인가를 모르면 보안 경계를 잘못 놓치기 쉽다. WebSocket과 gRPC도 이 기반을 버리는 기술이 아니라, HTTP 요청-응답만으로 부족한 구간을 다른 통신 모델로 확장하는 선택이다.

4. 들어가기 전 최소 선수지식

L1 입구에 필수로 끝내야 할 내부 선수 토픽은 없다. 아래 감각만 있으면 첫 문서를 시작할 수 있다.

클라이언트가 서버에 요청을 보내고 응답을 받는다는 그림, JSON 객체의 기본 형태를 안다.
상태 코드와 응답 본문이 서로 다른 정보라는 점을 받아들일 수 있다. 구체적인 코드와 헤더는 content/topics/L1/http-basics.mdx에서 배운다.
비동기 서버와 동시 요청의 비용이 낯설어도 첫 세 문서를 읽는 데 문제는 없다. 요청이 많을 때 Node.js가 어디에서 막히는지가 궁금해지면 content/topics/L0/nodejs-event-loop.mdx로 내려간다.
암호화와 인코딩의 차이, SQL의 SELECT·WHERE와 parameter 개념, 브라우저 쿠키 동작은 처음부터 모두 요구하지 않는다. 각각 인증/인가와 웹 보안 문서에 들어갈 때 필요한 최소 외부 전제다.

5. 이 레이어를 듣는 순서

L1 추천 학습 순서

1. HTTP Basics
요청과 응답을 메서드, 상태 코드, 헤더, 캐시라는 공통 언어로 읽는다. 이후 모든 토픽의 기준점이다.
2. API Design Basics
HTTP 요소를 엔드포인트 목록이 아니라 변경 가능한 클라이언트와 서버 사이의 계약으로 묶는다.
3. Authentication vs Authorization
계약을 호출하는 주체의 신원 확인과 행동 허용 판단을 분리해 401과 403, 토큰과 정책을 다른 문제로 본다.
4. Web Security basics
앞의 계약과 권한이 공격 입력·자동 자격·비용 비대칭 앞에서 어떻게 깨지는지 신뢰 경계와 다층 방어로 본다.
5. WebSocket & gRPC basics
HTTP 기반을 유지한 채 지속 양방향 연결과 typed RPC로 확장하고, REST·SSE·WebSocket·gRPC의 선택 기준을 세운다.

HTTP Basics → API Design Basics는 모든 경로의 공통 축이다. 그다음에는 실제 prerequisite에 따라 두 방향으로 갈라진다.

Security 경로: Authentication vs Authorization → Web Security basics로 이어서 신원·권한과 신뢰 경계를 배운다.
WebSocket/gRPC 경로: HTTP와 API 계약을 바탕으로 바로 통신 모델 선택을 배울 수 있다. 웹 보안은 더 이상 이 문서의 hard prerequisite가 아니다.

learning_order는 다섯 문서를 위 순서로 읽는 추천값이므로 처음이라면 Timeline 순서가 가장 매끄럽다. 다만 통신 방식 판단이 당장 필요하면 공통 축 뒤에 WebSocket/gRPC를 먼저 읽고, 이후 Security 경로로 돌아와도 prerequisite를 어기지 않는다.

JWT(JSON Web Token)는 검증 가능한 claim을 전달하는 서명 토큰 형식이며, 서명은 위조 여부를 확인하지만 내용을 숨기지는 않는다. DDoS(Distributed Denial-of-Service)는 분산된 다수의 요청으로 네트워크·연결·애플리케이션의 한정된 자원을 고갈시켜 정상 사용을 막는 공격이다. Protobuf(Protocol Buffers)는 메시지의 필드와 타입을 스키마로 정의해 양쪽의 데이터 계약으로 사용하는 이진 직렬화 형식이다.

경로	첫 회독에서 잡을 것	선택 심화로 미룰 것
공통 핵심	HTTP 의미, API 계약	Keep-Alive·HTTP/2/3 튜닝, API 운영 수치
Security	인증과 인가의 분리, 신뢰 경계, 데이터와 명령의 분리, 다층 방어	JWT 키 로테이션, 공격별 긴 구현, 패스워드 비용 튜닝, 공급망 운영 절차
DDoS/WAF	어느 계층의 어떤 자원이 고갈되는지, WAF와 애플리케이션 제한의 책임 차이	SYN 동작 세부, 임계값 산정·Count/Block 전환·인프라별 운영 값
WebSocket	요청-응답과 지속 양방향 연결의 차이, 연결을 열어두는 대가	heartbeat 수치, backpressure 정책, 재연결·fan-out 운영 설계
gRPC	Protobuf가 타입 계약이라는 점, unary와 streaming의 방향 차이	필드 번호 호환성 운영, 네 가지 streaming 종료 규칙, deadline·status·retry 세부

첫 회독의 종료점도 명확히 둔다. DDoS는 OSI 계층의 L3/L4/L7 이름을 외우는 것보다 네트워크·연결·애플리케이션 중 무엇이 먼저 고갈되는지 말할 수 있으면 충분하다. WAF는 모든 보안을 대신하는 장치가 아니라 HTTP 앞단에서 공격량을 줄이는 층이라고 이해하면 된다.

Protobuf는 이진 포맷 내부를 계산하기보다 스키마가 호출 양쪽의 타입 계약이 된다는 점을 잡는다. Streaming은 요청 하나/여러 개 × 응답 하나/여러 개로 네 패턴을 구분할 수 있으면 첫 회독을 마쳐도 된다. 실제 필드 번호 변경, half-close, deadline, 재시도 정책은 gRPC를 사용할 필요가 생겼을 때 다시 읽는다.

6. 어렵게 느껴지는 지점과 돌아갈 곳

막히는 느낌	보통 부족한 전제	돌아갈 실제 문서
메서드·상태 코드·헤더가 한꺼번에 섞인다	HTTP 요청과 응답의 구성요소	`content/topics/L1/http-basics.mdx`
URL과 응답 형태를 왜 계약이라고 하는지 모르겠다	독립 배포와 변경 호환성 관점	`content/topics/L1/api-design-basics.mdx`
401·403, Session·JWT, OAuth·OIDC가 같은 이야기처럼 들린다	신원 확인과 정책 판단의 분리	`content/topics/L1/auth-vs-authz.mdx`
보안 도구 이름만 많고 연결이 안 된다	신뢰 경계와 다층 방어 모델	`content/topics/L1/web-security-basics.mdx`의 1~2.5절
DDoS의 계층 이름과 WAF 위치가 헷갈린다	요청이 프록시와 앱까지 통과하는 계층 지도	`content/topics/L2/osi-web-server.mdx`
WebSocket과 gRPC가 단지 더 빠른 HTTP처럼 보인다	HTTP 요청-응답과 API 계약의 기준점	`content/topics/L1/http-basics.mdx`, `content/topics/L1/api-design-basics.mdx`
Protobuf와 stream 내부 때문에 첫 회독이 멈춘다	지금 필요한 범위보다 깊은 전송 세부	`content/topics/L1/websocket-grpc-basics.mdx` 2절 끝의 첫 회독 경로

후속 심화 경로

아래 문서는 막혔을 때 바로 뛰어가는 fallback이 아니다. L1 첫 회독을 마친 뒤 각 문서의 실제 prerequisite를 순서대로 통과하는 후속 경로다.

심화 목적	실제 prerequisite를 따르는 경로
WAF·Shield·네트워크 필터링	`L1 Web Security basics → L3 VPC / Subnet / Security Group → L3 Network Security`
HTTP/2·3 전송 내부	`L1 HTTP Basics + WebSocket & gRPC basics → L2 OSI 모델 & Web Server → L2 TCP/UDP Internals → L2 DNS basics → L7 TCP 흐름/혼잡 제어 + TLS & HTTPS → L7 HTTP/2 & HTTP/3`

두 번째 경로에서 TLS & HTTPS는 L1 Web Security basics도 prerequisite로 요구한다. 따라서 HTTP/2·3 심화에 들어갈 때는 Security 경로의 첫 회독도 먼저 마쳐야 한다.

7. 들을 준비가 된 상태

L1 Readiness check

브라우저나 앱이 서버에 요청을 보내고 응답을 받는다는 흐름을 본 적이 있다.
200, 404, 500처럼 세 자리 상태 코드가 요청 결과를 나타낸다는 정도를 안다. 각 코드의 정확한 의미는 아직 설명하지 못해도 된다.
JSON에서 객체와 배열을 보고 문자열·숫자·불리언 값을 대략 구분할 수 있다.
URL, 메서드, 헤더 같은 용어가 낯설면 `HTTP Basics`부터 천천히 익히면 된다는 것을 안다.
인증·인가, WAF, WebSocket, gRPC를 아직 설명하지 못해도 L1을 시작할 수 있다.

8. 이 레이어의 핵심 한 문장

L1은 HTTP 호출 방법을 모으는 레이어가 아니라, 네트워크 너머의 주체들이 의미와 권한을 합의하고 신뢰 경계를 지키며 필요한 통신 방식만 선택하게 만드는 판단의 기반이다.