gRPC · GraphQL · WebSocket 정리

이 글 본문에 나온 용어만 한 줄씩 정리했습니다.

• TCP: 연결을 맺은 뒤 순서 확인과 재전송으로 데이터를 빠짐없이 전달하는 신뢰성 있는 전송 프로토콜입니다.
• HTTP: 웹에서 요청과 응답을 주고받는 프로토콜입니다.
• 방화벽(Firewall): 정해진 규칙에 따라 들어오고 나가는 트래픽을 허용하거나 차단하는 보안 장치입니다.
• 프록시(Proxy): 클라이언트와 서버 사이에서 요청을 대신 전달하는 중계 서버로, 캐싱, 필터링, 주소 숨김에 쓰입니다.
• 로드밸런서(Load Balancer): 들어오는 요청을 여러 서버에 나눠 보내서 부하를 분산하고 장애를 줄이는 장치입니다.
• 핸드셰이크(Handshake): 본격적인 통신을 시작하기 전에 양쪽이 연결 조건을 확인하고 합의하는 절차입니다.
• 양방향(전이중, Full-duplex): 양쪽이 동시에 자유롭게 주고받을 수 있는 방식입니다(예: 전화).
• 요청/응답(Request/Response): 클라이언트가 요청하면 서버가 응답하는, 항상 클라이언트가 먼저 시작하는 방식입니다.
• 푸시(Push): 서버가 요청을 받지 않고도 먼저 클라이언트에게 데이터를 보내는 것입니다.
• 엔드포인트(Endpoint): API가 요청을 받는 주소(URL)입니다.
• 오버헤드(Overhead): 실제 데이터 전달 외에 추가로 드는 비용(헤더, 연결 설정 등)입니다.
• RFC: 인터넷 프로토콜의 표준을 정리한 공식 문서입니다(WebSocket은 RFC 6455).
• 캐시(Cache): 한 번 받은 결과를 저장해 두었다가 다시 요청이 오면 재사용해서 속도를 높이는 것입니다.
• HTTP 캐싱: 브라우저나 프록시가 Cache-Control 같은 헤더에 따라 응답을 저장하고 재사용하는 방식입니다.
• curl: 터미널에서 URL로 HTTP 요청을 보내고 응답을 확인하는 명령줄 도구입니다.
• L4 로드밸런서: IP와 포트 같은 전송 계층 정보만 보고 서버에 트래픽을 나누는 로드밸런서입니다.
• L7 프록시: HTTP 경로나 헤더 같은 응용 계층 내용을 보고 요청 단위로 나눠 전달하는 프록시(로드밸런서)입니다.
• 마이크로서비스: 하나의 큰 앱을 작고 독립적인 여러 서비스로 쪼개서 만드는 구조입니다.
• 디버깅: 프로그램의 오류 원인을 찾아 고치는 작업입니다.
• 직렬화(Serialization): 메모리 안의 데이터를 전송하거나 저장할 수 있는 바이트나 문자열로 바꾸는 것입니다(반대는 역직렬화).
• JSON: 사람이 읽을 수 있는 키-값 형태의 텍스트 데이터 형식입니다.
• 바이너리(Binary) 포맷: 데이터를 사람이 읽을 수 없는 바이트 그대로 인코딩해 작고 빠르지만 눈으로 확인하기는 어려운 형식입니다.
• Protocol Buffers(Protobuf): Google이 만든 바이너리 직렬화 형식으로, .proto 파일에 구조를 정의합니다.
• .proto 파일: gRPC의 서비스와 메시지 타입을 정의하는 파일이자 클라이언트와 서버의 약속(계약)입니다.
• RPC(Remote Procedure Call): 다른 서버에 있는 함수를 내 로컬 함수처럼 호출하는 방식입니다.
• stub: 원격 함수를 로컬 함수처럼 부를 수 있게 자동 생성되는 클라이언트 쪽 코드입니다.
• 코드 생성(codegen): 정의 파일(.proto)에서 클라이언트와 서버 코드를 자동으로 만들어 내는 것입니다.
• HTTP/2: HTTP/1.1을 개선해 한 연결에서 여러 요청을 동시에 처리하고 헤더를 압축하는 프로토콜입니다.
• 멀티플렉싱(Multiplexing): 하나의 연결로 여러 요청과 응답을 섞어서 동시에 주고받는 기술입니다.
• 스트리밍(Streaming): 데이터를 한 번에 다 보내지 않고 계속 이어서 흘려보내는 방식입니다.
• Unary: 요청 하나에 응답 하나를 주고받는 가장 기본적인 gRPC 호출 방식입니다.
• Deadline: 호출이 이 시간 안에 끝나야 한다는 제한 시간으로, 넘기면 호출이 실패합니다.
• gRPC-Web: 브라우저에서 gRPC 서버를 호출할 수 있게 해 주는 변형 프로토콜로, 프록시가 필요합니다.
• 쿼리 언어: 원하는 데이터를 요청하기 위한 전용 문법입니다.
• Schema / SDL: GraphQL의 타입과 필드를 정의하는 계약이고, SDL(Schema Definition Language)은 이를 쓰는 문법입니다.
• Query: 데이터를 조회하는 GraphQL 연산입니다.
• Mutation: 데이터를 생성, 수정, 삭제하는 GraphQL 연산입니다.
• Subscription: 서버의 변경을 실시간으로 받아 보는 GraphQL 연산으로, 보통 WebSocket 위에서 동작합니다.
• Resolver: 스키마의 각 필드 값을 실제로 가져오는 서버 쪽 함수입니다.
• Introspection: 클라이언트가 서버에 스키마 자체를 물어볼 수 있게 하는 기능으로, 도구의 자동 완성에 쓰입니다.
• Over-fetching: 필요하지 않은 필드까지 받아 오는 문제입니다.
• Under-fetching: 필요한 데이터가 한 번에 오지 않아 요청을 여러 번 보내야 하는 문제입니다.
• N+1 문제: 목록을 1번 조회한 뒤 항목마다 추가 쿼리를 N번 날려서 총 N+1번의 조회가 일어나는 비효율입니다.
• DataLoader: 같은 종류의 조회를 모아 한 번에 처리하고 캐시해서 N+1 문제를 줄이는 도구입니다.
• depth/complexity 제한: 쿼리의 깊이나 계산 비용에 상한을 두어 지나치게 무거운 쿼리를 막는 방어 장치입니다.
• Upgrade 핸드셰이크: HTTP 요청으로 시작해서 “프로토콜을 WebSocket으로 바꾸자”고 합의하는 절차입니다.
• 101 Switching Protocols: 서버가 프로토콜 전환을 승인한다는 HTTP 응답 코드입니다.
• ws:// / wss://: WebSocket 주소 형식이고, wss는 TLS로 암호화된 연결입니다.
• stateful: 서버가 이전 연결이나 요청의 상태를 기억하고 있는 방식입니다(반대는 stateless).
• sticky session: 같은 클라이언트의 요청을 계속 같은 서버로 보내도록 고정하는 설정입니다.
• 메시지 브로커: 서버들 사이에서 메시지를 중계해 주는 시스템입니다.
• Redis: 메모리 기반 데이터 저장소로, 발행/구독(pub/sub) 기능을 메시지 브로커처럼 써서 서버들 사이에 메시지를 전달할 수 있습니다.
• 하트비트(ping/pong): 연결이 아직 살아 있는지 확인하려고 주기적으로 주고받는 신호입니다.