Web Basics

이 주제의 항목 · 20

• 2단계 인증: TOTP와 패스키인증기 앱의 6자리 코드(TOTP)는 등록 때 공유한 비밀 키와 현재 시각으로 서버와 앱이 같은 숫자를 각자 계산하는 방식이다. 패스키는 비밀을 공유하지 않는다: 기기가 사이트마다 키 쌍을 만들고 공개키만 서버에 주며, 로그인 때 서버의 챌린지에 개인키로 서명한다. 도메인에 묶여 있어 피싱에 강하다.
• 비밀번호 저장과 비밀번호 관리자서버는 비밀번호를 평문·암호문·단순 해시로 두지 않고, 사용자마다 다른 솔트를 섞어 Argon2id·bcrypt 같은 느린 해시로 저장한다. 비밀번호 관리자는 반대 방향의 문제를 푼다: 마스터 비밀번호에서 키를 유도해 금고를 기기에서 암호화하므로 서버는 내용을 볼 수 없다.
• 세션 기반 인증과 토큰 기반 인증로그인 상태를 서버 저장소에 두는 세션 방식과, 서명된 토큰(JWT)에 담아 클라이언트가 들고 다니는 토큰 방식의 흐름·장단점을 비교하고, 토큰 탈취 대책(짧은 만료, 슬라이딩 세션, 리프레시 토큰 회전)과 선택 기준을 정리한다.
• 스프링 애플리케이션 설계: DI, 프록시 트랜잭션, 멀티모듈, WebFlux스프링으로 서버를 만들 때 반복해서 부딪히는 설계 문제를 정리한다. IoC·DI와 생성자 주입, Service/ServiceImpl 관행과 SOLID, Lombok 사용 기준, 프록시 기반 @Transactional의 자기 호출 함정, 멀티모듈의 계층과 의존 규칙, 사용하지 않는 API 찾기, Spring MVC와 WebFlux의 차이를 다룬다.
• 스프링의 싱글톤 빈과 요청 스레드스프링 빈은 하나뿐인데 동시에 들어온 수많은 요청을 어떻게 처리하는가. 내장 Tomcat의 스레드 풀이 요청마다 스레드를 배정하고, 모든 스레드가 같은 싱글톤 빈을 공유하므로 빈은 상태 없이(stateless) 짜야 한다. NIO 커넥터, 스레드 풀 설정, 가상 스레드까지 정리한다.
• 웹 서버, WAS, 그리고 Nginx정적 자원을 내주는 웹 서버(Apache·Nginx)와 동적 처리를 맡는 WAS(Tomcat 등)의 역할 분담, 리버스 프록시·로드밸런싱, Nginx의 마스터-워커 구조와 겸하는 역할(웹 서버·프록시·캐시·TLS 종료), 그리고 Nginx의 location·rewrite·proxy_pass로 404를 다른 서버로 넘기는 설정.
• 웹 앱의 요청·응답 구조브라우저·프론트엔드 서버·백엔드(API) 서버·데이터베이스가 요청과 응답을 주고받는 웹 애플리케이션의 기본 흐름과, 한 컴퓨터 안에서 프로세스를 구분하는 포트의 역할.
• 웹훅과 폴링다른 서비스의 변화를 알아내는 두 방법. 폴링은 내가 주기적으로 묻고, 웹훅은 상대가 이벤트가 생길 때 내 엔드포인트를 호출한다. 동작 흐름과 장단점, 고르는 기준, 웹훅을 받는 쪽이 갖춰야 할 서명 검증·빠른 응답·멱등 처리·재시도 대비를 정리했다.
• 인코딩·암호화·해시·토큰화와 디지털 서명데이터를 바꾸는 네 가지 방법은 목적이 다르다. 인코딩은 형식 변환(키 없음, 보안 아님), 암호화는 키로 기밀성 확보(대칭·비대칭), 해시는 되돌릴 수 없는 지문, 토큰화는 원본을 금고에 두고 의미 없는 대체값을 쓰는 것이다. 해시와 개인키를 엮은 디지털 서명이 위변조와 서명자를 함께 증명한다. 용도별로 쓸 알고리즘(AEAD, HMAC, Argon2id, Ed25519, X25519·ML-KEM)과 nonce 재사용·변조·재전송·타이밍 같은 조합의 함정도 정리한다.
• 텔레그램 미니앱 인증 흐름텔레그램이 서명한 initData를 클라이언트가 서버로 보내고, 서버가 봇 토큰 기반 HMAC-SHA256으로 위변조와 만료를 검증한 뒤 자체 세션·JWT를 발급하는 미니앱 인증 패턴.
• API 보안 체크리스트API를 공개하기 전에 점검할 보안 항목을 전송·입력·인증과 인가·노출 범위·운영 단계로 묶었다. 한 가지 방어에 기대지 말고 여러 겹을 쌓는 게 핵심이다.
• API 아키텍처 스타일: SOAP·REST·GraphQL·gRPC·WebSocket·WebhookAPI는 시스템끼리 기능과 데이터를 주고받는 약속이다. 대표적인 여섯 가지 스타일(SOAP, REST, GraphQL, gRPC, WebSocket, Webhook)을 통신 방향·데이터 형식·잘 맞는 곳으로 비교하고, REST·GraphQL·gRPC를 계약·응답 모양·전송·스트리밍·오류 처리·캐시·브라우저 지원·버전 관리 등 축별로 나란히 놓았다. API와 SDK의 차이, 공개 범위에 따른 API 종류, API를 배울 때 거치는 주제 지도도 정리했다.
• API 키와 HMAC 요청 서명서버끼리 호출하는 API에서 요청마다 '누가 보냈고 중간에 바뀌지 않았나'를 증명하는 HMAC 요청 서명. 앱 ID·액세스 키·시크릿 키의 역할, 서명할 문자열을 만드는 법, 타임스탬프와 논스로 재전송을 막는 법, 서버의 검증 순서, 토큰 방식과의 비교를 정리했다.
• API 테스트의 종류API를 검증하는 아홉 가지 테스트(스모크, 기능, 통합, 회귀, 부하, 스트레스, 보안, UI, 퍼즈)가 각각 어떤 질문에 답하는지, 개발에서 배포까지 어느 단계에서 돌리는지, 부하와 스트레스의 차이와 퍼즈 테스트가 찾는 것을 정리했다.
• API 페이지네이션큰 목록을 나눠 내려 주는 API 페이지네이션의 여섯 가지 방식(오프셋, 페이지 번호, 커서, 키셋, 시간 기반, 혼합)을 요청 모양·DB 쿼리·장단점으로 비교한다. 깊은 페이지에서 오프셋이 느려지는 이유, 데이터가 바뀔 때 생기는 중복·누락, 정렬 키에 동점 깨기를 넣는 규칙, 응답에 다음 페이지 정보를 싣는 법까지.
• Base64 인코딩바이너리 데이터를 ASCII 문자 64개만으로 바꿔 텍스트용 채널로 안전하게 보내는 인코딩. 6비트씩 끊어 변환하는 원리, 패딩, 약 33% 커지는 비용, 이미지를 API에 보내는 예를 정리한다.
• CORS다른 출처(origin)의 프론트엔드가 API를 호출할 수 있도록 서버가 허용 범위를 알려 주는 브라우저 보안 정책.
• GraphQLGraphQL은 타입 스키마 위에서 클라이언트가 필요한 필드를 골라 질의하는 API 질의 언어이자 런타임이다. 쿼리·뮤테이션·구독, REST 대신 고를 때의 기준, N+1·캐시·악성 쿼리 같은 약점과 대책, 클라이언트 래핑·BFF·모놀리식·페더레이션 네 가지 도입 패턴, 등록된 쿼리로 운영하는 방식을 정리했다.
• gRPC: Protocol Buffers로 정의하는 RPCgRPC는 .proto 파일로 서비스 계약을 정의하고, 생성된 스텁으로 원격 메서드를 로컬 함수처럼 부르는 HTTP/2 기반 이진 RPC 프레임워크다. Protocol Buffers의 태그·varint 직렬화와 JSON 비교, 네 가지 호출 방식, Node.js 예제, 브라우저 제약과 도입 판단 기준을 정리했다.
• REST API 설계자원을 URI로 표현하고 HTTP 메서드로 행위를 나타내는 API 설계 방식과 그 규칙. REST의 여섯 제약과 균일한 인터페이스(자기 서술적 메시지·HATEOAS), PUT·PATCH·POST 고르기, URI 규칙과 자원 원형, 상태 코드 선택과 오류 응답(RFC 9457), 멱등 키·버전 관리 방식·비동기 요청·조건부 요청·응답 모양 같은 실무 설계 팁까지.