새 전송 프로토콜을 만든다는 건 웬만해선 벌이지 않는 일입니다. TCP는 40년 넘게 인터넷을 떠받쳐 왔고, 그동안 쌓인 개선안도 한둘이 아니거든요. 그런데도 구글은 2012년에 TCP를 고치는 대신 UDP 위에 새 프로토콜을 얹기 시작했고, 그게 지금의 QUIC가 되었습니다. HTTP 글에서 HTTP/3를 다루며 QUIC를 잠깐 언급했는데요. 이번에는 QUIC 자체를 놓고, 왜 굳이 바닥부터 새로 만들었는지 그리고 그래서 무엇이 달라졌는지를 짚어보겠습니다. 왜 TCP를 고치지 못했을까 TCP에 없는 기능을 넣자는 제안은 늘 있었습
소셜 서비스를 옮겨본 적 있으신가요? 계정을 새로 파고, 팔로워를 처음부터 다시 모으고, 그동안 쓴 글은 옛 서비스에 그대로 남겨두고 나오게 됩니다. 계정도 데이터도 인맥도 전부 그 회사 서버 안에 있으니 당연한 일이죠. 서비스가 마음에 안 들어도 쉽게 못 떠나는 이유이기도 하고요. 😅 AT Protocol(atproto)은 이 구조를 뒤집어보려는 시도입니다. Bluesky를 떠받치는 프로토콜로 알려져 있지만, 정확히 말하면 Bluesky는 이 프로토콜 위에 올라간 여러 앱 중 하나일 뿐입니다. 신원과 데이터를 앱 바깥으로 꺼내
카페에서 서버 작업을 하다가 노트북을 덮고 지하철을 탄 뒤 다시 열었을 때, 터미널이 그대로 멈춰 있는 걸 보신 적 있으신가요? 🤔 몇 초쯤 기다리다가 결국 Ctrl+C를 눌러보고, 그래도 반응이 없어서 창을 닫고 다시 접속합니다. 아까 어느 디렉터리에 있었는지 기억을 더듬어 다시 이동하고요. 와이파이에서 테더링으로 갈아탈 때도, 사무실에서 집으로 이동할 때도 똑같은 일이 반복됩니다. SSH는 TCP 위에서 동작하는데, TCP 연결은 클라이언트의 IP 주소에 묶여 있습니다. IP가 바뀌는 순간 그 연결은 되살릴 방법이 없어요. 서
집에서 와이파이에 연결된 기기를 한번 세어 볼까요? 노트북, 스마트폰, 태블릿, TV, 어쩌면 로봇청소기까지 십수 대는 우습게 넘어갑니다. 그런데 통신사가 우리 집에 내준 공인 IP 주소는 보통 딱 하나뿐인데요. 어떻게 그 많은 기기가 주소 하나로 동시에 인터넷을 쓰는 걸까요? 🤔 비밀은 집 공유기 안에서 조용히 돌아가는 NAT(Network Address Translation)에 있습니다. 우리말로 옮기면 "네트워크 주소 변환"인데, 이름 그대로 오가는 패킷의 주소를 바꿔치기하는 기술이에요. 이 글에서는 NAT가 무엇을 바꾸는지
요즘 웹 서비스에는 서버가 사용자 대신 외부 URL로 요청을 보내는 기능이 흔합니다. 링크를 붙여넣으면 미리보기 카드를 만들어 주고, 이미지 주소를 넣으면 썸네일을 대신 받아오고, 웹훅 주소를 등록해 두면 이벤트가 생길 때마다 서버가 그 주소로 알림을 쏴 줍니다. 편리하죠. 그런데 "사용자가 건넨 주소로 서버가 대신 요청을 보낸다"는 이 평범한 동작이, 잘못 다루면 서버를 통째로 공격자의 손발로 내주는 통로가 됩니다. 이번 글에서 다룰 SSRF(Server-Side Request Forgery) 이야기입니다. 이름부터 CSRF와 헷
로컬에서 개발하다 보면 http://localhost:3000, http://localhost:3001, http://localhost:8080 같은 주소를 하루에도 수십 번씩 입력하는데요. 프로젝트가 두세 개만 돼도 어느 포트가 어느 앱이었는지 헷갈리기 시작합니다. 프런트엔드는 3000번, API는 4000번, 스토리북은 6006번... 이걸 외우고 있다가 동료에게 "그거 몇 번 포트였죠?"라고 물어본 경험, 다들 한 번쯤 있으시죠. 😅 게다가 포트가 겹치면 EADDRINUSE 에러가 나면서 서버가 안 뜨고, HTTPS가 필요한
집에 있는 공유기 관리자 페이지(192.168.0.1)에 로그인해 본 적 있으시죠? 보통은 같은 와이파이에 연결된 기기에서만 접근할 수 있으니까 비밀번호를 admin/admin으로 그대로 두는 분들도 적지 않을 텐데요. 그런데 만약 인터넷 어딘가의 평범해 보이는 광고 배너 한 번 클릭한 것만으로 그 공유기에 누군가 마음대로 들어올 수 있다면 어떨까요? 😱 말도 안 되는 소리 같지만 실제로 이런 일을 가능하게 만드는 공격 기법이 있습니다. 바로 DNS 리바인딩(DNS Rebinding)인데요. 동일 출처 정책이 있으니까 외부 사이트
HTTPS를 처음 켜본 사람이라면 한 번쯤 같은 장면을 거칩니다. 인증서를 사려고 검색하다 보니 1년에 몇 만 원짜리부터 수십만 원짜리까지 등급이 나뉘어 있고, 어떤 걸 골라야 할지부터 막막한데요. 사이드 프로젝트 하나 띄워보자고 비싼 인증서를 사기는 부담스럽지만, HTTP로 두자니 브라우저가 "안전하지 않음"이라고 경고를 띄웁니다. TLS 인증서의 구조와 신뢰 체인이 궁금하다면 인증서 자체를 다룬 글에서 먼저 살펴볼 수 있습니다. 이 진입 장벽을 거의 무너뜨린 것이 Let's Encrypt입니다. ISRG(Internet Secu
요즘은 HTTPS를 켜는 일이 너무 쉬워졌습니다. Cloudflare 뒤에 사이트를 두거나 Caddy로 서버를 띄우면 인증서라는 단어를 한 번도 마주치지 않고 자물쇠가 켜지는데요. 그러다 회사 사내 서버나 공유 호스팅처럼 자동화가 없는 환경을 만나면 갑자기 낯선 단어들이 쏟아집니다. CSR을 만들라고 하고, 파일이 세 개 오고, 중간 인증서를 붙이라고 하고, 만료 30일 전부터만 갱신이 된다고 합니다. 이 낯섦은 능력의 문제가 아니라 세대 차이입니다. Let's Encrypt 이전 시대에는 인증서가 자동으로 흐르는 인프라가 아니라
집에 있는 NAS에 저장해둔 파일이 급하게 필요한데 밖에서 접속할 방법이 없었던 적 있으신가요? 회사 내부 서버에 집에서 작업해야 하는데 VPN 설정이 너무 복잡해서 포기한 적은요? 기존 VPN은 설정이 번거롭고, 포트 포워딩은 보안상 위험하고, ngrok으로 터널링하는 방법은 일시적인 용도에 가깝습니다. 이런 고민을 깔끔하게 해결해주는 도구가 바로 Tailscale인데요. Tailscale은 WireGuard 프로토콜 위에 구축된 메시(mesh) VPN입니다. 복잡한 네트워크 설정 없이 내 기기들을 하나의 사설 네트워크로 묶어주죠
로컬에서 개발 중인 웹 서버를 외부에 공개해야 할 때 어떤 방법을 쓰시나요? ngrok같은 터널링 도구를 많이 사용하는데, 무료 플랜에서는 임시 URL이 매번 바뀌고 커스텀 도메인도 쓸 수 없어서 불편할 때가 있습니다. Cloudflare Tunnel은 Cloudflare에서 제공하는 무료 터널링 서비스입니다. 내 컴퓨터에서 Cloudflare 네트워크까지 암호화된 아웃바운드 터널을 만들어주기 때문에 방화벽 포트를 열거나 공유기 설정을 건드릴 필요가 없어요. 게다가 자기 소유의 도메인을 연결할 수 있고, Cloudflare의 DDo
나만의 도메인을 가지고 있다면 한 번쯤 [email protected] 같은 이메일 주소를 만들어보고 싶지 않으셨나요? 브랜드 이메일 주소가 있으면 신뢰감을 줄 수 있고, 용도별로 주소를 나눠서 쓸 수도 있어서 여러모로 유용하거든요. 그런데 이메일 서비스를 직접 운영하는 건 서버 관리부터 보안까지 신경 쓸 게 너무 많습니다. Google Workspace 같은 유료 서비스를 쓰자니 개인 프로젝트나 소규모 사이트에는 부담이 되고요. Cloudflare Email Routing은 이런 고민을 깔끔하게 해결해줍니다. 도메인에 커스텀 이
웹 애플리케이션을 개발하다 보면 로컬에서 실행 중인 서버를 외부에서 접속할 수 있게 해야 할 때가 있습니다. 예를 들어, 작업 중인 결과물을 클라이언트나 동료에게 시연해야 하거나, 외부 서비스(예: GitHub, Stripe, Slack)의 웹훅(Webhook)을 테스트해야 하는 경우가 그렇죠. 매번 클라우드 서버에 배포하는 것은 번거롭고 시간도 오래 걸립니다. 공유기 설정을 건드려서 포트 포워딩을 하는 것도 보안상 위험할 수 있고요. 이럴 때 가장 간편하게 사용할 수 있는 도구가 바로 ngrok입니다. ngrok은 로컬 컴퓨터의
GitHub Pages로 웹사이트 무료 호스팅하기에서 살펴봤듯이, GitHub Pages에 웹사이트를 배포하면 기본적으로 github.io 서브 도메인을 무료로 제공해주는데요. 대부분의 개인 프로젝트에서는 GitHub Pages의 기본 도메인을 사용해도 큰 지장이 없을 것입니다. 하지만 비즈니스를 위한 웹사이트를 호스팅할 때는 브랜딩이나 SEO(검색 엔진 최적화) 차원에서 커스텀 도메인을 원하게 되죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 배포한 웹사이트에 커스텀 도메인을 연결하는 방법을 알려드리겠습니다.
브라우저 주소창이나 서버 로그에서 2001:db8::1 같은 알 수 없는 주소를 본 적 있으신가요? 점(.) 대신 콜론(:)이 줄줄이 박혀 있는 모양인데요. 이게 바로 IPv6 주소입니다. IPv4 주소 공간이 거의 바닥났다는 이야기는 이제 익숙하실 거예요. 그 문제에 대한 단기 처방이 사설 IP와 NAT였다면, 진짜 해법으로 마련된 게 IPv6입니다. 이번 포스팅에서는 IPv6가 어떤 주소 체계를 가지는지, 그 낯선 표기법을 어떻게 읽어야 하는지, IPv4와 비교해 무엇이 달라졌는지를 차근차근 살펴보겠습니다. 왜 IPv6가 필요했
도메인을 구매한 후에 DNS 설정을 했는데 브라우저에서 해당 웹사이트에 접속이 안되면 어디서부터 디버깅을 해야 할지 상당히 난감할 수 있는데요. 이번 포스팅에서는 DNS 설정에 문제가 발생했을 때 정말로 유용하게 사용할 수 있는 도구인 dig 명령어에 대해서 알아보겠습니다. 명령어 소개 dig는 Domain Information Groper의 약자로, DNS 정보를 조회하고 진단하기 위한 커맨드 라인 도구인데요. dig라는 영단어가 "파다", "파헤치다", "파서 찾아내다" 라는 뜻이 있어서, 도구의 목적을 생각해보면 굉장히 쉽게
Netlify에 웹사이트를 배포하면 기본적으로 <웹사이트명>.netlify.app이라는 무료 도메인 네임(domain name)을 주는데요. 취미 프로젝트라면 이 기본 무료 도메인만 사용해도 큰 지장이 없겠지만 대부분의 실제로 운영되는 웹사이트는 유료로 구매한 도메인 이름을 사용해야 할 것입니다. 이렇게 Netlify 사용자가 별도로 구매해서 Netlify에서 주는 도메임 대신에 사용하는 도메인 네임을 소위 커스텀(custom) 도메인 네임이라고 하는데요. 이번 포스팅에서는 Netlify에 배포한 웹사이트에 커스텀(custom) 도
클라우드에 서버를 하나 만들고 나면 대개 이런 명령어부터 입력하게 됩니다. 명령어 한 줄로 멀리 있는 서버의 터미널이 열리니 무척 간단해 보이는데요. 처음 접속할 때 나타나는 지문이 무엇인지, 비밀번호 없이 어떻게 로그인이 되는지, ~/.ssh에는 왜 여러 파일이 생기는지 파고들기 시작하면 이야기가 금세 복잡해집니다. SSH를 단순히 원격 접속 명령어로만 외우면 연결 오류가 났을 때 어디부터 확인해야 할지 막막합니다. 반대로 서버 확인과 사용자 인증을 구분해서 이해하면 키를 안전하게 관리하는 방법도 자연스럽게 보이죠. 이번 글에서는
웹사이트에 연결하고 싶은 커스텀(custom) 도메인 네임을 구매해놓고 DNS 설정이 생각처럼 잘 안되서 당혹스러우셨던 경험이 있으신가요? 아무래도 DNS 레코드에 대한 아무런 사전 지식이 없이 호스팅 서비스에서 시키는데로 따라하기가 쉽지 않은 것 같습니다. 그래서 이번 포스팅에서는 커스텀(custom) 도메인을 웹사이트에 연결할 때 알아두면 큰 도움이 되는 DNS 레코드의 기초적인 부분에 대해서 다뤄보려고 합니다. DNS 레코드란? 커스텀 도메인 추가하려고 웹사이트 호스팅 서비스가 제공하는 문서 페이지를 열어 보면 대게 A 레코드
Docker 로그나 서버 시작 메시지에서 0.0.0.0을 본 적 있으시죠? 127.0.0.1은 "내 컴퓨터"라는 게 떠올라도, 0.0.0.0은 정확히 무슨 의미인지 한 번에 답하기가 의외로 어렵습니다. 사실 이 주소는 맥락에 따라 의미가 꽤 다른데요. 서버 바인딩에서는 "모든 인터페이스", 라우팅 테이블에서는 "기본 게이트웨이로 가는 모든 트래픽", DHCP에서는 "아직 IP가 없다"는 의미로 해석됩니다. 이번 포스팅에서는 0.0.0.0이라는 주소가 어떤 정체이고, 각 맥락에서 어떤 약속으로 쓰이는지 정리해보겠습니다. 0.0.0.0