코드 땜장이

CORS를 제대로 이해하기: 브라우저가 막는 것과 서버가 허용하는 것 빠른 답 CORS 오류는 서버 요청 자체가 실패했다기보다, 브라우저가 응답을 JavaScript에 노출하지 않았다는 뜻인 경우가 많습니다. Access-Control-Allow-Origin 은 클라이언트가 요청에 붙여 해결하는 헤더가 아니라 서버가 응답으로 내려줘야 하는 헤더입니다. 쿠키나 인증 정보를 포함하는 요청은 Access-Control-Allow-Origin: * 와 함께 쓸 수 없고, 클라이언트와 서버의 credentials 설정이 함께 맞아야 합니다. 디버깅할 때는 콘솔 메시지뿐 아니라 OPTIONS preflight 응답과 실제 요청의 응답 헤더를 나눠서 확인해야 합니다. 목차 흐름으로 보기 CORS가 필요한 배경 실제로 막히는 지점 서버 CORS 기준선 요청 코드에서 확인할 부분 디버깅과 운영 검증 품질 기준으로 보는 점검 순서 CORS와 CSRF의 차이 흐름으로 보기 흐름 다이어그램 브라우저에서 요청이 발생하면, 브라우저는 현재 페이지의 출처와 요청 대상의 출처를 비교합니다. 출처는 프로토콜, 호스트, 포트의 조합입니다. https://app.example.com 과 https://api.example.com 은 호스트가 다르므로 다른 출처이고, http://localhost:3000 과 http://localhost:8080 은 포트가 다르므로 다른 출처입니다. 출처가 다르면 브라우저는 동일 출처 정책을 기준으로 응답을 JavaScript에 보여줘도 되는지 판단합니다. 요청 자체가 서버까지 도달할 수는 있지만, 서버 응답에 올바른 CORS 헤더가 없으면 브라우저가 응답 본문과 일부 헤더를 코드에 숨깁니다. 요청 메서드나 헤더가 단순 요청 범위를 벗어나면 실제 요청 전에 OPTIONS preflight 요청이 먼저 나갑니다. 예를 들어 Content-Type: application/json 으로 POST 를 보내거나 Authorization 헤더를...

TCP 3-Way Handshake는 어떻게 연결을 만드는가 빠른 답 3-way handshake는 양쪽이 서로 송수신 가능하다는 사실과 초기 순서 번호를 확인하는 연결 설정 절차입니다. SYN은 연결 요청, SYN-ACK은 요청 수락과 서버의 초기 번호 전달, ACK는 클라이언트의 최종 확인입니다. 연결이 안 될 때는 애플리케이션 코드보다 먼저 포트 리슨 상태, 방화벽, 라우팅, SYN 재전송 여부를 확인해야 합니다. tcpdump나 Wireshark 출력에서 SYN만 반복되면 서버 응답이 없거나 중간 네트워크에서 막힌 상황일 가능성이 큽니다. 목차 시간 흐름으로 이해하기 흐름으로 보기 TCP 연결 설정이 필요한 이유 Sequence Number와 ACK Number 서버 포트와 배포 구성 연결 확인을 위한 최소 예시 패킷 캡처로 보는 정상 handshake 장애 징후와 점검 순서 흔한 오해 시간 흐름으로 이해하기 연결 요청 전 DNS 조회나 설정을 통해 대상 IP와 포트가 정해집니다. → 첫 번째 왕복 전 클라이언트가 SYN 으로 연결 의사와 초기 순서 번호를 보냅니다. → 서버 응답 시점 서버가 포트를 열고 있다면 SYN-ACK 로 요청 수락과 서버의 초기 순서 번호를 돌려줍니다. → 최종 확인 시점 클라이언트가 ACK 를 보내면 양쪽 TCP 상태가 ESTABLISHED 로 바뀝니다. → 데이터 전송 이후 HTTP, 데이터베이스, gRPC 같은 애플리케이션 프로토콜 데이터가 TCP 연결 위에서 오갑니다. 흐름으로 보기 흐름 다이어그램 이 흐름은 브라우저, API 클라이언트, 백엔드 서비스, 데이터베이스 클라이언트 모두에서 같은 구조로 나타납니다. 차이가 있다면 80, 443, 5432, 6379처럼 대상 포트와 그 위에서 동작하는 애플리케이션 프로토콜이 달라진다는 점입니다. ESTABLISHED 상태가 되었다는 말은 TCP 연결이 만들어졌다는 뜻입니다. TLS 인증서 검증, HTTP 라우팅, 데이터베이스 인증, 애플리케이션 권한 ...

동기 외부 API 호출이 느려질 때 서버 장애로 번지지 않게 막는 방법 빠른 답 동기 외부 호출은 connection timeout , read timeout , connection pool wait timeout 을 나눠 설정해야 합니다. 외부 서비스 여러 개가 같은 HTTP 커넥션 풀을 공유하면, 한 서비스의 지연이 다른 연동까지 막을 수 있습니다. 서비스별 커넥션 풀, 동시 실행량 제한, 서킷 브레이커를 함께 두면 장애 전파 범위를 줄일 수 있습니다. fallback은 실패를 숨기는 장치가 아니라, 실패를 기록하면서 사용자 흐름을 어디까지 유지할지 정하는 정책입니다. 목차 시간 흐름으로 이해하기 선택 기준 매트릭스 외부 API 지연이 내부 장애로 번지는 이유 동기 호출 흐름과 대기 지점 타임아웃 3가지를 나눠 설정하기 커넥션 풀 분리와 벌크헤드 서킷 브레이커와 fallback 설계 동시 실행량 제한 예시 디버깅과 운영 점검 순서 배포와 운영 체크리스트 흔한 오해와 주의할 점 시간 흐름으로 이해하기 장애 시작 외부 API A의 응답 시간이 길어지고, 내부 요청 스레드가 응답을 기다립니다. → 호출 누적 사용자 요청은 계속 들어오고, A를 호출하는 요청이 커넥션과 스레드를 오래 점유합니다. → 대기 확산 커넥션 풀의 사용 가능한 연결이 줄어들고, 새 요청은 외부 API로 나가기 전부터 풀 앞에서 기다립니다. → 내부 영향 timeout, 벌크헤드, 서킷 브레이커가 없으면 A의 지연이 내부 API 전체 응답 시간과 실패율로 번집니다. → 보호 동작 실패율이나 느린 호출 비율이 기준을 넘으면 서킷 브레이커가 호출을 잠시 막고 빠른 실패나 fallback으로 전환합니다. 선택 기준 매트릭스 외부 API가 가끔 느려지는 상황 타임아웃을 먼저 설정합니다. 요청이 끝없이 대기하지 않도록 서버 자원 점유 시간을 제한할 수 있습니다. 특정 외부 서비스 장애가 다른 연동까지 밀어내는 상황: 외부 서비스별 커넥션 풀을 분리합니다. 한 풀의 고갈이 전체 외부...

브라우저 주소창에 URL을 입력하면 화면이 뜨기까지: DNS부터 렌더링까지 빠른 답 주소 입력 뒤 바로 화면이 뜨는 것이 아니라 DNS 조회, 연결 수립, TLS 협상, HTTP 요청, 렌더링이 순서대로 진행됩니다. 첫 화면 속도는 서버 응답 시간만이 아니라 CSS 다운로드, JavaScript 실행, 레이아웃·페인트 비용에도 크게 영향을 받습니다. HTTPS 사이트는 요청 전에 인증서 검증과 키 협상이 들어가므로 TLS 단계가 별도 병목이 될 수 있습니다. 병목은 Chrome DevTools의 Network와 Performance 탭으로 네트워크 지연과 렌더링 비용을 나눠 확인하는 것이 가장 빠릅니다. 목차 흐름으로 보기 왜 이 과정을 같이 봐야 하나 연결이 열리기 전: DNS, TCP, TLS, HTTP 응답이 화면이 되는 핵심: DOM, CSSOM, 렌더 트리 레이아웃, 페인트, 컴포지팅은 각각 무엇을 하나 첫 화면을 늦추는 흔한 비용 DevTools로 병목을 어떻게 찾나 구성과 설정으로 줄일 수 있는 비용 면접과 실무에서 자주 틀리는 설명 흐름으로 보기 1 DNS 조회 ↓ 2 TCP 연결 ↓ 3 TLS 협상 ↓ 4 HTTP 요청/응답 ↓ 5 DOM·CSSOM 생성 ↓ 6 레이아웃·페인트·컴포지팅 이 여섯 단계는 웹 페이지 로딩의 가장 큰 뼈대입니다. 앞쪽은 리소스를 받아오는 네트워크 흐름이고, 뒤쪽은 받은 데이터를 실제 화면으로 바꾸는 브라우저 렌더링 흐름입니다. 페이지가 느릴 때 원인을 정확히 찾으려면 이 둘을 섞지 말고 끊어서 봐야 합니다. 왜 이 과정을 같이 봐야 하나 브라우저 주소창에 https://www.google.com 을 입력하는 행동은 단순히 “서버에 요청한다”로 끝나지 않습니다. 브라우저는 먼저 어디로 연결할지 찾아야 하고, 안전한 연결을 만들어야 하며, HTML과 정적 자원을 받아온 뒤 그것을 다시 화면용 구조로 바꿔야 합니다. 사용자가 보는 첫 화면은 서버 응답 그 자체가 아니라, 브라우저가 수행한 렌더링 파이...