Docker 로그나 서버 시작 메시지에서 0.0.0.0을 본 적 있으시죠? 127.0.0.1은 "내 컴퓨터"라는 게 떠올라도, 0.0.0.0은 정확히 무슨 의미인지 한 번에 답하기가 의외로 어렵습니다. 사실 이 주소는 맥락에 따라 의미가 꽤 다른데요. 서버 바인딩에서는 "모든 인터페이스", 라우팅 테이블에서는 "기본 게이트웨이로 가는 모든 트래픽", DHCP에서는 "아직 IP가 없다"는 의미로 해석됩니다. 이번 포스팅에서는 0.0.0.0이라는 주소가 어떤 정체이고, 각 맥락에서 어떤 약속으로 쓰이는지 정리해보겠습니다. 0.0.0.0
Docker Compose는 여러 개의 컨테이너(container)로 구성된 애플리케이션을 관리하기 위한 간단한 오케스트레이션(Orchestration) 도구입니다. 여러 개의 컨테이너로 구성된 Docker Compose 애플리케이션 내에서 컨테이너 간의 통신은 어떻게 이루어질까요? Docker 네트워크에 대해서 생소하신 분들은 관련 포스팅를 통해 먼저 기본 개념을 파악하시기를 권장드립니다. Docker Compose 설정법이나 커맨드가 생소하신 분들은 아래 포스팅를 먼저 읽고 돌아오시기를 추천드립니다. Docker Compose
Docker 컨테이너(container)는 격리된 환경에서 돌아가기 때문에 기본적으로 다른 컨테이너와의 통신이 불가능합니다. 하지만 여러 개의 컨테이너를 하나의 Docker 네트워크(network)에 연결시키면 서로 통신이 가능해집니다. 이번 포스팅에서는 컨테이너 간 네트워킹이 가능하도록 도와주는 Docker 네트워크에 대해서 알아보도록 하겠습니다. 네트워크 조회 Docker 네트워크의 기본은 내 컴퓨터에서 어떤 네트워크가 생성되어 있는지를 아는 것일 겁니다. docker network ls 커맨드를 사용하면 현재 생성되어 있는 D
웹 페이지를 두 번째 열 때 첫 번째보다 훨씬 빨리 그려지는 경험을 한 번쯤 해보셨을 겁니다. 어딘가에서 그 자원을 미리 들고 있다가 다시 꺼내준 결과인데, 이 "미리 들고 있다"가 곧 캐시이고요. 브라우저, 회사 프록시, CDN, 원본 서버 앞 모두 캐시가 자리할 수 있어 한 자원이 여러 곳에 사본을 가질 수 있는 셈입니다. 문제는 이렇게 흩어진 캐시들이 서로 다른 규칙으로 동작하면 곤란하다는 점입니다. 한 캐시는 1시간을 보관하고 다른 캐시는 영원히 보관하는 식이면 운영자가 원하는 정책을 만들 수가 없죠. 그래서 HTTP는 모든
대칭키 암호화는 빠르지만 비밀 키를 안전하게 나누기 어렵습니다. 비대칭키 암호화는 처음 만난 상대와 비밀을 합의하고 신원을 증명할 수 있지만, 큰 데이터를 처리하기에는 무겁죠. 암호학적 해시 함수는 메시지가 달라졌는지를 짧은 값으로 드러내고 키를 여러 용도로 나누는 재료가 됩니다. 따로 배운 세 도구가 실제 인터넷에서는 어떻게 한자리에 모일까요? 가장 친숙한 답이 전송 계층 보안(Transport Layer Security, TLS)입니다. HTTPS로 웹사이트에 접속하면 브라우저와 서버는 TLS 핸드셰이크를 거쳐 서로를 확인하고,
운영체제 이미지나 개발 도구를 내려받다 보면 파일 옆에 길고 낯선 문자열이 붙어 있는 경우가 있습니다. SHA-256이나 checksum이라는 이름 아래 16진수 숫자가 빼곡하게 적혀 있죠. 내려받기가 끝났으니 파일을 바로 실행해도 될 것 같은데, 왜 굳이 이 값을 함께 제공할까요? 전송 도중 일부가 깨졌거나 저장 장치에서 데이터가 손상돼도 파일명과 용량만으로는 알아채기 어려울 수 있기 때문입니다. 이때 원본과 내려받은 파일이 같은지 확인하는 짧은 값이 체크섬(checksum)입니다. 이번 글에서는 체크섬이 오류를 어떻게 찾아내는지
요즘 쓰는 서비스들의 주소를 보면 끝이 .com이 아닌 경우가 많지 않나요? Claude는 claude.ai, 게임 전적 사이트 OP.GG는 op.gg를 쓰고, 텔레그램 초대 링크는 t.me로 시작합니다. 구글의 웹 개발 가이드도 web.dev에 있고요. 심지어 .pizza나 .ninja로 끝나는 주소도 있습니다. 처음 보면 "이런 것도 주소가 돼?" 하고 고개를 갸웃하게 되죠. 🤔 모두 정식 주소입니다. 인터넷 주소록을 관리하는 IANA(Internet Assigned Numbers Authority)의 공식 목록을 2026년
브라우저 주소창에 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로
개발 서버를 띄우면 터미널에 항상 비슷한 메시지가 뜨죠. 별생각 없이 클릭해서 들어가지만, 막상 localhost가 정확히 무엇인지, 127.0.0.1과 어떻게 다른지, 그리고 0.0.0.0은 또 뭔지 물으면 순간 헷갈리는 분이 의외로 많습니다. 이번 포스팅에서는 매일 쓰는 localhost를 둘러싼 이름, 주소, 바인딩의 관계를 정리하고, 자주 만나는 함정 몇 가지도 함께 짚어보겠습니다. localhost는 이름, 127.0.0.1은 주소 먼저 가장 기본적인 구분부터 짚고 가요. localhost는 이름이고 127.0.0.1은 주
웹 서비스를 만들거나 게임 서버를 짜다 보면 "통신은 그냥 되는 거지" 정도로 넘어가게 되는 부분이 있습니다. 정작 소켓을 직접 열어 데이터를 주고받아야 할 때면, 만들 수 있는 소켓이 한 종류가 아니라는 사실과 마주치게 됩니다. 하나는 SOCK_STREAM, 다른 하나는 SOCK_DGRAM이라고 부르는데, 이 두 가지가 각각 TCP와 UDP에 해당합니다. 왜 굳이 두 종류로 나뉘어 있을까요? 🤔 같은 인터넷 위에서 데이터를 주고받는 일인데도, TCP와 UDP는 만들어진 목적이 꽤 다릅니다. 이번 글에서는 두 프로토콜이 어떤 점에
집에서 공유기 관리자 페이지에 들어가려고 IP를 쳐본 적 있으시죠? 대부분 192.168.0.1이나 192.168.1.1 같은 주소일 겁니다. 회사 사내망에 들어가 보면 10.0.0.5 같은 주소를 받고요. 그런데 인터넷의 평범한 사이트들 IP는 또 52.x.x.x나 203.0.113.x처럼 전혀 다른 모양이에요. 왜 어떤 IP는 집 안에서만 보이고, 어떤 IP는 전 세계에서 보일까요? 이 구분을 만들어 준 게 바로 RFC 1918이라는 표준 문서입니다. 이번 포스팅에서는 사설 IP 주소가 왜 필요했는지, 어떤 대역이 정해져 있는지
UDP를 설명하는 문장은 대개 비슷하게 시작합니다. "TCP에서 신뢰성을 뺀 프로토콜"이라는 식이죠. 틀린 말은 아닙니다. 그런데 이 설명만 들고 있으면 막상 UDP로 뭔가를 만들어야 할 때 손이 잘 안 떨어집니다. 무엇이 빠졌는지는 알겠는데, 그래서 무엇을 직접 챙겨야 하는지는 여전히 흐릿하거든요. 🤔 TCP와 UDP의 차이는 예전에 나란히 놓고 비교한 적이 있는데요. 이번에는 비교를 잠시 접어두고 UDP 하나만 들여다보려고 합니다. 헤더 8바이트 안에 무엇이 들어 있는지, 왜 데이터그램에는 경계가 있는지, 한 번에 얼마나 보낼
TCP를 한 단어로 요약하라면 대개 "신뢰성"이 나옵니다. 보낸 데이터가 순서대로, 빠짐없이 도착한다는 뜻이죠. 그런데 인터넷의 아래층인 IP는 아무것도 보장하지 않습니다. 패킷을 버려도 되고, 순서를 바꿔도 되고, 같은 것을 두 번 보내도 규칙 위반이 아닙니다. 그 위에서 TCP는 어떻게 "빠짐없이 순서대로"를 만들어낼까요? 🤔 TCP와 UDP의 차이에서 두 프로토콜의 성격을 견줘봤고, UDP는 따로 파고들었으니 이번에는 TCP 차례입니다. 신뢰성이라는 결과가 아니라 그것을 만드는 장치를 하나씩 뜯어보겠습니다. 스트림에는 경계가
본 포스팅는 오라클 자바 튜토리얼의 What Is a Socket?를 번역하였습니다. 소켓 통신 일반적으로 서버는 특정 포트가 바인딩된 소켓를 가지고 특정 컴퓨터 위에서 돌아갑니다. 해당 서버는 클라이언트의 연결 요청을 소켓을 통해 리스닝하면서 그냥 기다릴 뿐이죠. 클라이언트는 서버가 떠 있는 머신의 호스트네임과 서버가 리스닝하고 있는 포트 번호를 알고 있습니다. 따라서 클라이언트는 이 호스트 네임과 포트를 통해서 서버와 연결을 시도하게 됩니다. 또한 클라이언트는 서버 상대로 자신을 식별시켜주기 위해서 연결동안 사용될 로컬 포트에