HTTPS를 처음 켜본 사람이라면 한 번쯤 같은 장면을 거칩니다. 인증서를 사려고 검색하다 보니 1년에 몇 만 원짜리부터 수십만 원짜리까지 등급이 나뉘어 있고, 어떤 걸 골라야 할지부터 막막한데요. 사이드 프로젝트 하나 띄워보자고 비싼 인증서를 사기는 부담스럽지만, HTTP로 두자니 브라우저가 "안전하지 않음"이라고 경고를 띄웁니다. 이 진입 장벽을 거의 무너뜨린 것이 Let's Encrypt입니다. ISRG(Internet Security Research Group)라는 비영리 단체가 운영하는 무료 인증 기관인데, 발급 절차를 자
집에 있는 NAS에 저장해둔 파일이 급하게 필요한데 밖에서 접속할 방법이 없었던 적 있으신가요? 회사 내부 서버에 집에서 작업해야 하는데 VPN 설정이 너무 복잡해서 포기한 적은요? 기존 VPN은 설정이 번거롭고, 포트 포워딩은 보안상 위험하고, ngrok으로 터널링하는 방법은 일시적인 용도에 가깝습니다. 이런 고민을 깔끔하게 해결해주는 도구가 바로 Tailscale인데요. Tailscale은 WireGuard 프로토콜 위에 구축된 메시(mesh) VPN입니다. 복잡한 네트워크 설정 없이 내 기기들을 하나의 사설 네트워크로 묶어주죠
로컬에서 개발 중인 웹 서버를 외부에 공개해야 할 때 어떤 방법을 쓰시나요? ngrok같은 터널링 도구를 많이 사용하는데, 무료 플랜에서는 임시 URL이 매번 바뀌고 커스텀 도메인도 쓸 수 없어서 불편할 때가 있습니다. Cloudflare Tunnel은 Cloudflare에서 제공하는 무료 터널링 서비스입니다. 내 컴퓨터에서 Cloudflare 네트워크까지 암호화된 아웃바운드 터널을 만들어주기 때문에 방화벽 포트를 열거나 공유기 설정을 건드릴 필요가 없어요. 게다가 자기 소유의 도메인을 연결할 수 있고, Cloudflare의 DDo
나만의 도메인을 가지고 있다면 한 번쯤 hello@mydomain.com 같은 이메일 주소를 만들어보고 싶지 않으셨나요? 브랜드 이메일 주소가 있으면 신뢰감을 줄 수 있고, 용도별로 주소를 나눠서 쓸 수도 있어서 여러모로 유용하거든요. 그런데 이메일 서비스를 직접 운영하는 건 서버 관리부터 보안까지 신경 쓸 게 너무 많습니다. Google Workspace 같은 유료 서비스를 쓰자니 개인 프로젝트나 소규모 사이트에는 부담이 되고요. Cloudflare Email Routing은 이런 고민을 깔끔하게 해결해줍니다. 도메인에 커스텀 이
웹 애플리케이션을 개발하다 보면 로컬에서 실행 중인 서버를 외부에서 접속할 수 있게 해야 할 때가 있습니다. 예를 들어, 작업 중인 결과물을 클라이언트나 동료에게 시연해야 하거나, 외부 서비스(예: GitHub, Stripe, Slack)의 웹훅(Webhook)을 테스트해야 하는 경우가 그렇죠. 매번 클라우드 서버에 배포하는 것은 번거롭고 시간도 오래 걸립니다. 공유기 설정을 건드려서 포트 포워딩을 하는 것도 보안상 위험할 수 있고요. 이럴 때 가장 간편하게 사용할 수 있는 도구가 바로 ngrok입니다. ngrok은 로컬 컴퓨터의
GitHub Pages에 웹사이트를 배포하면 기본적으로 github.io 서브 도메인을 무료로 제공해주는데요. 대부분의 개인 프로젝트에서는 GitHub Pages의 기본 도메인을 사용해도 큰 지장이 없을 것입니다. 하지만 비즈니스를 위한 웹사이트를 호스팅할 때는 브랜딩이나 SEO(검색 엔진 최적화) 차원에서 커스텀 도메인을 원하게 되죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 배포한 웹사이트에 커스텀 도메인을 연결하는 방법을 알려드리겠습니다. 커스텀 도메인 구매 GitHub Pages에 커스텀 도메인을 연결
도메인을 구매한 후에 DNS 설정을 했는데 브라우저에서 해당 웹사이트에 접속이 안되면 어디서부터 디버깅을 해야 할지 상당히 난감할 수 있는데요. 이번 포스팅에서는 DNS 설정에 문제가 발생했을 때 정말로 유용하게 사용할 수 있는 도구인 dig 명령어에 대해서 알아보겠습니다. 명령어 소개 dig는 Domain Information Groper의 약자로, DNS 정보를 조회하고 진단하기 위한 커맨드 라인 도구인데요. dig라는 영단어가 "파다", "파헤치다", "파서 찾아내다" 라는 뜻이 있어서, 도구의 목적을 생각해보면 굉장히 쉽게
Netlify에 웹사이트를 배포하면 기본적으로 <웹사이트명>.netlify.app이라는 무료 도메인 네임(domain name)을 주는데요. 취미 프로젝트라면 이 기본 무료 도메인만 사용해도 큰 지장이 없겠지만 대부분의 실제로 운영되는 웹사이트는 유료로 구매한 도메인 이름을 사용해야 할 것입니다. 이렇게 Netlify 사용자가 별도로 구매해서 Netlify에서 주는 도메임 대신에 사용하는 도메인 네임을 소위 커스텀(custom) 도메인 네임이라고 하는데요. 이번 포스팅에서는 Netlify에 배포한 웹사이트에 커스텀(custom) 도
웹사이트에 연결하고 싶은 커스텀(custom) 도메인 네임을 구매해놓고 DNS 설정이 생각처럼 잘 안되서 당혹스러우셨던 경험이 있으신가요? 아무래도 DNS 레코드에 대한 아무런 사전 지식이 없이 호스팅 서비스에서 시키는데로 따라하기가 쉽지 않은 것 같습니다. 그래서 이번 포스팅에서는 커스텀(custom) 도메인을 웹사이트에 연결할 때 알아두면 큰 도움이 되는 DNS 레코드의 기초적인 부분에 대해서 다뤄보려고 합니다. DNS 레코드란? 커스텀 도메인 추가하려고 웹사이트 호스팅 서비스가 제공하는 문서 페이지를 열어 보면 대게 A 레코드
Docker Compose는 여러 개의 컨테이너(container)로 구성된 애플리케이션을 관리하기 위한 간단한 오케스트레이션(Orchestration) 도구입니다. 여러 개의 컨테이너로 구성된 Docker Compose 애플리케이션 내에서 컨테이너 간의 통신은 어떻게 이루어질까요? Docker 네트워크에 대해서 생소하신 분들은 관련 포스팅를 통해 먼저 기본 개념을 파악하시기를 권장드립니다. Docker Compose 설정법이나 커맨드가 생소하신 분들은 아래 포스팅를 먼저 읽고 돌아오시기를 추천드립니다. Docker Compose
Docker 컨테이너(container)는 격리된 환경에서 돌아가기 때문에 기본적으로 다른 컨테이너와의 통신이 불가능합니다. 하지만 여러 개의 컨테이너를 하나의 Docker 네트워크(network)에 연결시키면 서로 통신이 가능해집니다. 이번 포스팅에서는 컨테이너 간 네트워킹이 가능하도록 도와주는 Docker 네트워크에 대해서 알아보도록 하겠습니다. 네트워크 조회 Docker 네트워크의 기본은 내 컴퓨터에서 어떤 네트워크가 생성되어 있는지를 아는 것일 겁니다. docker network ls 커맨드를 사용하면 현재 생성되어 있는 D
웹 페이지를 두 번째 열 때 첫 번째보다 훨씬 빨리 그려지는 경험을 한 번쯤 해보셨을 겁니다. 어딘가에서 그 자원을 미리 들고 있다가 다시 꺼내준 결과인데, 이 "미리 들고 있다"가 곧 캐시이고요. 브라우저, 회사 프록시, CDN, 원본 서버 앞 모두 캐시가 자리할 수 있어 한 자원이 여러 곳에 사본을 가질 수 있는 셈입니다. 문제는 이렇게 흩어진 캐시들이 서로 다른 규칙으로 동작하면 곤란하다는 점입니다. 한 캐시는 1시간을 보관하고 다른 캐시는 영원히 보관하는 식이면 운영자가 원하는 정책을 만들 수가 없죠. 그래서 HTTP는 모든
브라우저 주소창에 daleseo.com을 치고 엔터를 누르면 1초도 안 되어 페이지가 뜨는데요. 이 짧은 순간에 사실은 인터넷 곳곳에 있는 여러 대의 서버가 서로 묻고 답하면서 이 도메인이 어떤 IP 주소를 가리키는지 알아내는 작업이 벌어지고 있습니다. 이 일을 책임지는 시스템이 바로 DNS(Domain Name System)이고, 실제로 작업을 수행하는 주체가 DNS 서버입니다. 예전에 DNS 레코드 유형이나 dig 명령어를 다루면서 표면만 살짝 짚었었는데요. 이번에는 한 걸음 더 들어가서 도메인 이름이 IP 주소로 바뀌기까지 어
처음 웹 서버를 돌릴 때는 한 대만 잘 띄워 두면 충분합니다. 그런데 사용자가 늘고 트래픽이 점점 무거워지면, 어느 순간 한 대로는 감당이 안 되는 시점이 옵니다. 사양을 키우는 방법(스케일 업)도 있지만, 한 대를 더 띄워서 일을 나누어 시키는 방법(스케일 아웃)이 더 자연스러운 선택일 때가 많은데요. 이 분산을 책임지는 도구가 로드 밸런서입니다. 이름 그대로 트래픽이라는 부하를 여러 서버에 나눠 주는 장치인데, 막상 들여다보면 "어떤 기준으로 나누느냐", "어느 계층에서 동작하느냐", "한 대가 죽으면 어떻게 알아채느냐"처럼 결
브라우저 주소창에 작은 자물쇠 아이콘이 켜져 있으면 우리는 별다른 의심 없이 정보를 입력합니다. 비밀번호를 치고, 카드 번호를 넣고, 메시지를 보내는데요. 이 자물쇠 한 칸이 사실은 HTTP 위에 한 겹의 보호막을 덧씌운 결과인 셈입니다. HTTPS는 이름에서도 짐작되듯 HTTP에 보안(Secure)을 보탠 형태입니다. 정확히 말하면 HTTP를 TLS라는 암호 통신 위에서 흘려보내는 구조인데요. 이번 글에서는 평문 HTTP가 왜 위험한지, TLS가 그 위에 무엇을 더하는지, 그리고 우리가 평소에 보는 인증서와 자물쇠가 어떻게 신뢰를
웹 페이지 하나를 여는 일을 한 줄로 요약하면 "브라우저가 서버한테 뭔가 달라고 부탁하고, 서버가 그걸 보내준다"입니다. 이 단순한 부탁을 둘 사이에서 약속된 모양으로 주고받게 만든 것이 HTTP입니다. 이름이 길어 보이지만 풀어보면 HyperText Transfer Protocol, "문서를 주고받기 위한 약속" 정도로 옮길 수 있죠. 그런데 한 가지 호기심이 생깁니다. 이렇게 단순한 약속이 오랫동안 살아남으면서, 뒷자리 숫자만 1.0에서 1.1, 2, 3까지 바뀌어 왔다는 점이죠. 같은 이름을 달고도 토대를 TCP에서 UDP로
웹 서비스를 만들거나 게임 서버를 짜다 보면 "통신은 그냥 되는 거지" 정도로 넘어가게 되는 부분이 있습니다. 정작 소켓을 직접 열어 데이터를 주고받아야 할 때면, 만들 수 있는 소켓이 한 종류가 아니라는 사실과 마주치게 됩니다. 하나는 SOCK_STREAM, 다른 하나는 SOCK_DGRAM이라고 부르는데, 이 두 가지가 각각 TCP와 UDP에 해당합니다. 왜 굳이 두 종류로 나뉘어 있을까요? 🤔 같은 인터넷 위에서 데이터를 주고받는 일인데도, TCP와 UDP는 만들어진 목적이 꽤 다릅니다. 이번 글에서는 두 프로토콜이 어떤 점에
본 포스팅는 오라클 자바 튜토리얼의 What Is a Socket?를 번역하였습니다. 소켓 통신 일반적으로 서버는 특정 포트가 바인딩된 소켓를 가지고 특정 컴퓨터 위에서 돌아갑니다. 해당 서버는 클라이언트의 연결 요청을 소켓을 통해 리스닝하면서 그냥 기다릴 뿐이죠. 클라이언트는 서버가 떠 있는 머신의 호스트네임과 서버가 리스닝하고 있는 포트 번호를 알고 있습니다. 따라서 클라이언트는 이 호스트 네임과 포트를 통해서 서버와 연결을 시도하게 됩니다. 또한 클라이언트는 서버 상대로 자신을 식별시켜주기 위해서 연결동안 사용될 로컬 포트에