최근 올라온 글
무스키마 - ALTER가 없어도 마이그레이션은 남는다
·Database · Backend
헐어버린 벽 - 되돌릴 수 있는 변경만 한다
·Database · Backend
마이그레이션 도구 - 공사 기록부가 하는 일
·Database · Backend
전체 글
Database · Backend
무스키마 - ALTER가 없어도 마이그레이션은 남는다
스키마 없는 저장소에서 구조를 바꾸면 잠금은 사라진다. 그런데 채우는 일과 옛 모양은 그대로 남는다.
멈추지 않고 스키마를 바꾼다 6편
Database · Backend
헐어버린 벽 - 되돌릴 수 있는 변경만 한다
롤백 버튼이 못 하는 일이 있다. 어떤 변경이 한 방향인지 가려내고, 그 지점을 어떻게 뒤로 미루나.
멈추지 않고 스키마를 바꾼다 5편
Database · Backend
마이그레이션 도구 - 공사 기록부가 하는 일
버전 표 하나로 무엇이 풀리고 무엇이 안 풀리나. 체크섬, 동시 실행, 반쪽 적용, 그리고 되돌리기 스크립트의 허상.
멈추지 않고 스키마를 바꾼다 4편
Database · Backend
백필 - 이미 쌓인 5천만 행을 채운다
새 컬럼을 만들면 기존 행은 전부 비어 있다. 한 번에 채우면 왜 안 되고, 끊어 채우면 무엇을 더 챙겨야 하나.
멈추지 않고 스키마를 바꾼다 3편
Database · Backend
ALTER TABLE - 컬럼 하나 더하는 데 테이블이 멈춘다
추가만 하는 변경이 왜 서비스를 세우는가. 앞사람을 기다리는 줄, 테이블 재작성, 그리고 온라인 DDL의 값.
멈추지 않고 스키마를 바꾼다 2편
Database · Backend
스키마 변경 - 코드는 되돌아가고 데이터는 안 돌아간다
배포는 한 번에 되돌아가는데 스키마는 왜 안 되는가. 이 시리즈가 무엇을 맡고 무엇을 맡지 않는지부터.
멈추지 않고 스키마를 바꾼다 1편
Performance · Scaling
부하 테스트를 통과하고도 터지는 이유
부하 테스트가 초록불을 줬는데 프로덕션이 터진다. 테스트가 틀린 게 아니라 볼 수 없는 것이 있다. 시간, 사용자의 쏠림, 데이터 크기, 목으로 세운 외부 의존이 그 자리다.
Performance · Scaling
부하 테스트 - 무너지는 지점을 미리 찾는다
부하 테스트를 돌리면 숫자가 잔뜩 나온다. 그런데 그 숫자가 진짜인지는 어떻게 거느냐가 정한다. 같은 데이터만 부르고, 차가운 채로 재고, 한꺼번에 때리면 시스템이 아니라 테스트 자신을 잰 것이 된다.
DevOps · Git
오래 사는 브랜치 - 미룬 만큼 한꺼번에 온다
합치기를 미루면 비용은 미룬 시간에 비례해서 늘지 않는다. 충돌 면적·리뷰 크기·늦게 오는 답이 어떻게 함께 자라는지, 그리고 짧게 유지하는 값은 무엇인지 본다.
갈래와 합류 4편
DevOps · Git
브랜치 전략 - 오래 가르거나 자주 합치거나
이름 붙은 브랜치 전략들은 결국 하나를 정한다. 지선을 얼마나 오래 두었다가 되돌리나. 배포 주기·롤백 비용·팀 크기가 그 답을 어떻게 정하는지 본다.
갈래와 합류 3편
DevOps · Git
합칠 때 - 역사를 남기나 정리하나
지선을 본선으로 되돌리는 방법은 하나가 아니다. 이어 붙이는 머지와 옮겨 놓는 리베이스가 각각 무엇을 남기고 무엇을 지우는지, 충돌은 어디서 생기는지 본다.
갈래와 합류 2편
DevOps · Git
브랜치 - 같은 파일을 여럿이 고칠 때
코드를 고치는 사람이 둘이 되면 미완성을 둘 자리가 필요해진다. 갈라놓는다는 발상이 무엇을 풀어주고, 그 대신 무엇을 시작시키는지 본다.
갈래와 합류 1편
CS · Regex
쓸 자리와 안 쓸 자리 - 정규식이 답이 아닐 때
HTML을 정규식으로 파싱하면 왜 반드시 깨지는지, 이메일 검증 패턴이 왜 길수록 나빠지는지를 본다. 정규식이 필요해 보이는 자리 중 상당수는 위층 설계가 실패한 자리다.
패턴 하나로 찾기 4편
CS · Regex
ReDoS - 정규식 한 줄이 서버를 세운다
요청은 한 건인데 CPU가 100%가 되고 응답이 끊긴다. 에러도 안 난다. 갈림길이 겹친 정규식 하나가 입력 한 글자마다 경우의 수를 두 배로 늘리고 있어서다.
패턴 하나로 찾기 3편
CS · Regex
엔진이 하는 일 - 해보고 안 되면 되돌아간다
정규식 엔진은 패턴을 한눈에 알아보지 않는다. 골목에 들어갔다 아니면 돌아 나오기를 반복할 뿐이다. 탐욕과 게으름이 왜 다른 답을 내는지도 그 절차 위에서만 설명된다.
패턴 하나로 찾기 2편
CS · Regex
정규식 - 찾을 것을 글자 대신 규칙으로 적는다
찾을 글자를 아는 날은 contains 하나로 끝난다. 문제는 무엇을 찾는지 정확히 모를 때다. 그때 이름 대신 인상착의를 적는 것이 정규식이고, 이 시리즈는 그 전단을 들고 뛰는 엔진을 따라간다.
패턴 하나로 찾기 1편
Backend · Search
검색엔진을 들일 때 - DB로 버틸 수 있는 선
검색이 느리다고 바로 엔진을 들이면 저장소가 둘이 되고 동기화라는 새 일이 생긴다. DB로 어디까지 버틸 수 있고, 무엇을 보고 넘어갈지 판단표로 닫는다.
검색이 빠른 이유 6편
Backend · Search
색인은 늦게 따라온다 - 방금 쓴 글이 안 보이는 이유
글을 저장하고 바로 검색했는데 안 나온다. 버그가 아니라 역색인이라는 구조가 원래 그렇게 생겼다. 왜 바로 못 넣는지, 그 지연을 어디까지 줄일 수 있는지 본다.
검색이 빠른 이유 5편
Backend · Search
랭킹 - 다 찾은 다음 무엇을 위에 둘까
조건에 맞는 문서가 5,000건 나왔다. 사용자는 위에서 세 개만 본다. 어떤 문서가 더 관련 있다고 판정하는지, 공식 없이 직관만으로 따라가 본다.
검색이 빠른 이유 4편
Backend · Search
토큰화 - 어디서 자르느냐가 검색되느냐를 정한다
역색인을 만들려면 본문을 낱말로 잘라야 한다. 그런데 한국어는 공백이 낱말 경계가 아니다. 검색이 안 된다는 신고의 대부분이 이 자르는 규칙에서 나온다.
검색이 빠른 이유 3편
Backend · Search
역색인 - 문서에서 낱말이 아니라 낱말에서 문서로
검색이 빠른 이유는 결국 아이디어 하나다. 문서를 열어 낱말을 찾는 대신, 낱말마다 그 낱말이 든 문서 번호를 미리 적어 둔다. 책 뒤의 찾아보기와 정확히 같은 구조다.
검색이 빠른 이유 2편
Backend · Search
LIKE '%검색어%' - 인덱스가 있어도 다 훑는다
검색창을 붙이고 LIKE로 막았다. 인덱스도 만들어뒀는데 데이터가 늘자 느려진다. 인덱스가 게을러서가 아니라, DB 인덱스와 본문 검색이 애초에 다른 일을 하기 때문이다.
검색이 빠른 이유 1편
CS · Memory
GC가 있어도 샌다 - 치워지지 않는 것들
회수기는 안 쓰는 것을 치우지 않는다. 안 닿는 것을 치운다. 이 한 마디 차이에서 자동 회수 언어의 메모리 누수가 통째로 나온다. 어떤 코드가 안 쓸 것을 붙들고 있는지, 그리고 새는 것과 그냥 많이 쓰는 것을 어떻게 가르는지 본다.
메모리의 수명 6편
CS · Memory
멈춤 시간 - 치우는 동안 프로그램은 선다
자동 회수는 공짜가 아니라 시간으로 값을 치른다. 왜 치우는 동안 프로그램을 세워야 하는지, 왜 대부분의 객체가 금방 죽는다는 관찰이 회수기의 설계를 통째로 바꿨는지, 그리고 무엇과 무엇을 맞바꾸는지 본다.
메모리의 수명 5편
CS · Memory
도달 가능성 - 닿을 수 있으면 살아 있다
세는 대신 따라가 본다. 정해진 출발점에서 참조를 타고 갈 수 있으면 살아 있고, 못 가면 버린다. 세는 방식이 못 풀던 고리가 왜 이 방식에서는 저절로 풀리는지, 그리고 그 대신 무엇을 잃는지 본다.
메모리의 수명 4편
CS · Memory
참조 세기 - 아무도 안 보면 버린다
가리키는 곳이 몇 개인지를 세다가 0이 되면 그 자리를 돌려준다. 가장 단순하고 가장 즉시적인 자동 회수 방식이다. 세는 값이 어디서 나가는지, 그리고 이 방식이 절대 못 푸는 한 가지가 무엇인지 본다.
메모리의 수명 3편
CS · Memory
손으로 돌려주기 - 두 번 놓거나 한 번도 안 놓거나
반납을 사람이 적으면 실패하는 방식이 셋이다. 안 놓거나, 두 번 놓거나, 놓고 나서 또 쓰거나. 이 단순해 보이는 일을 왜 사람이 자꾸 틀리는지, 그리고 왜 그 버그가 하필 엉뚱한 데서 터지는지를 본다.
메모리의 수명 2편
CS · Memory
메모리 회수 - 빌린 자리는 돌려줘야 한다
프로그램은 실행되는 내내 메모리를 얻는다. 얻는 건 한 줄인데 돌려주는 건 왜 어려운가. 스택은 저절로 치워지고 힙만 문제로 남는 이유부터, 안 돌려준 자리가 프로그램을 어떻게 죽이는지까지 본다.
메모리의 수명 1편
CS · Compile
빌드 - 그 한 줄이 실제로 하는 일들
빌드 명령 한 줄 뒤에는 여러 단계가 줄지어 있고, 단계마다 파일이 하나씩 남는다. 그 파일들이 남는다는 사실이 증분 빌드를 가능하게 하고, 동시에 가끔 clean을 해야 하는 이유도 만든다.
돌아가기 전에 벌어지는 일 6편
CS · Compile
링크 - 흩어진 조각을 하나로 묶는 일
프로그램은 한 파일로 만들어지지 않는다. 여러 조각이 따로 옮겨지고, 조각마다 '이 이름은 다른 데 있다'는 빈칸이 남는다. 그 빈칸을 채우는 일이 링크이고, '그 라이브러리를 못 찾겠다'는 에러가 여기서 나온다.
돌아가기 전에 벌어지는 일 5편
CS · Compile
JIT - 돌려 보고 나서 다시 옮긴다
미리 옮길 때는 알 수 없던 것이 있다. 어느 코드가 실제로 자주 도는지, 어떤 값이 실제로 들어오는지는 돌려 봐야 안다. JIT는 그 앎을 얻은 뒤에 다시 옮기는 방식이고, 우리가 '워밍업'이라 부르는 것이 그 대가다.
돌아가기 전에 벌어지는 일 4편
CS · Compile
바이트코드 - 한 번 더 접으면 무엇이 쉬워지나
소스와 기계어 사이에 한 겹을 끼워 넣으면 만들어야 할 번역기의 수가 곱셈에서 덧셈으로 바뀐다. '한 번 짜서 어디서나 돌린다'가 실제로 옮긴 것이 무엇인지, 그리고 그 대가로 무엇을 내주는지를 본다.
돌아가기 전에 벌어지는 일 3편
CS · Compile
컴파일과 인터프리터 - 미리 옮기나 그때그때 읽나
옮기는 일을 실행 전에 몰아서 하느냐, 실행하는 내내 조금씩 하느냐. 이 선택 하나가 시작 속도와 실행 속도, 그리고 오류를 언제 알게 되는지를 통째로 바꾼다. 그런데 실제 언어들은 둘 중 하나에 딱 서 있지 않다.
돌아가기 전에 벌어지는 일 2편
CS · Compile
기계어 - CPU가 아는 말은 따로 있다
우리가 쓴 코드는 CPU가 읽을 수 있는 글이 아니다. CPU가 아는 것은 수의 나열뿐이고, 그 수의 뜻마저 기계마다 다르다. 왜 소스가 그대로 돌지 못하는지, 그리고 왜 실행 파일이 아무 컴퓨터에서나 열리지 않는지가 여기서 갈린다.
돌아가기 전에 벌어지는 일 1편
CS · Compression
압축을 켤 자리와 끌 자리 - 한 장의 판단표로 접는다
압축은 늘 이득이 아니라 바이트와 CPU를 맞바꾸는 거래다. 그래서 병목이 어디냐에 따라 답이 뒤집힌다. 이 시리즈에서 본 원리를 켤지 끌지 고르는 표 한 장으로 접는다.
압축의 원리와 한계 7편
CS · Compression
안 줄어드는 것들 - 무엇이든 반으로 줄이는 프로그램은 왜 없나
압축률이 좋다는 프로그램은 많은데 '무엇이든' 줄여 준다는 것은 하나도 없다. 더 좋은 알고리즘이 아직 안 나온 게 아니라 그런 것이 있을 수 없다는 게 증명되어 있다. 그 이유가 압축의 한계를 전부 설명한다.
압축의 원리와 한계 6편
CS · Compression
손실 압축 - 되돌릴 수 없게 버린다
지금까지의 압축은 한 비트도 안 잃고 되돌렸다. 되돌리기를 포기하면 훨씬 많이 줄어든다. 사진과 음악과 영상이 그 길을 갔고, 그래서 다시 저장할 때마다 나빠진다.
압축의 원리와 한계 5편
CS · Compression
DEFLATE - 두 아이디어를 겹치면 gzip이 된다
반복 가리키기와 짧은 이름 주기는 서로 못 잡는 자리가 반대였다. 그래서 둘을 순서대로 겹친 것이 세상에서 가장 널리 쓰이는 압축이 됐다. gzip과 zip과 zlib이 서로 무엇이 다른지도 여기서 갈린다.
압축의 원리와 한계 4편
CS · Compression
허프만 코드 - 자주 나오는 것에 짧은 이름을 준다
반복이 하나도 없어도 아직 줄일 여지가 남아 있다. 모든 글자에 똑같은 길이를 주는 것이 낭비이기 때문이다. 짧은 이름을 나눠 주면서도 어디서 끊을지 헷갈리지 않게 만드는 방법을 본다.
압축의 원리와 한계 3편
CS · Compression
반복을 가리킨다 - 같은 말을 두 번 적지 않는 법
압축이 줄이는 첫째 낭비는 반복이다. 붙어 있는 반복을 개수로 접는 것에서 시작해, 아까 나온 것을 뒤돌아 가리키는 것까지 가면 zip과 gzip이 실제로 쓰는 방법이 나온다.
압축의 원리와 한계 2편
CS · Compression
압축 - 어떤 파일은 반으로 줄고 어떤 파일은 꿈쩍도 안 한다
같은 파일을 압축했는데 하나는 3분의 1이 되고 하나는 그대로다. 압축이 데이터를 마법으로 줄이는 게 아니라 원래 낭비되던 자리를 걷어내는 일이라서 그렇다. 무엇이 낭비인지부터 본다.
압축의 원리와 한계 1편
CS · Time
시각이 틀어졌을 때 - 밀린 폭만 보고 어디부터 볼지 고르기
9시간이 밀렸는지 1시간이 밀렸는지 하루가 밀렸는지는 아무렇게나 정해지지 않는다. 밀린 폭 자체가 어디가 어긋났다는 신호다. 이 시리즈를 한 장의 판단표로 접는다.
시간이라는 데이터 9편
CS · Time
시계는 흔들린다 - 경과 시간을 재는 다른 시계
컴퓨터 안에는 시계가 둘이다. 하나는 지금이 몇 시인지 말해 주지만 뒤로 갈 수 있고, 다른 하나는 몇 시인지 모르지만 절대 뒤로 안 간다. 둘을 바꿔 쓰면 걸린 시간이 음수로 나온다.
시간이라는 데이터 8편
CS · Time
ISO 8601 - 시각을 글자로 적는 법
03/04/2025가 3월 4일인지 4월 3일인지는 읽는 사람의 나라가 정한다. 그 다툼을 끝내려고 정한 꼴이 ISO 8601이고, 큰 단위부터 적는다는 규칙 하나에서 나머지 성질이 전부 따라 나온다.
시간이라는 데이터 7편
CS · Time
팻말 없는 시각 - 저장할 때 무엇이 빠지나
DB 컬럼 타입을 고르는 순간 이 값이 순간인지 달력 시각인지가 정해진다. 이름이 비슷해 헷갈리는데, 한쪽은 쓰고 읽는 사이에 값이 조용히 바뀌고 다른 쪽은 안 바뀐다.
시간이라는 데이터 6편
CS · Time
서머타임 - 없는 시각과 두 번 오는 시각
1년에 두 번, 달력에서 한 시간이 사라지고 한 시간이 두 번 온다. 존재하지 않는 시각을 저장하려 들고 같은 시각이 두 번 오는 걸 모르는 코드는 그날 새벽에만 조용히 틀린다.
시간이라는 데이터 5편
CS · Time
시간대 - 팻말은 나라가 고쳐 단다
시간대는 지도에서 잘라 낸 세로줄이 아니라 정부가 정하고 수시로 바꾸는 규칙이다. 그래서 컴퓨터는 그 규칙 목록을 따로 들고 다녀야 하고, 그 목록이 낡으면 조용히 한 시간이 어긋난다.
시간이라는 데이터 4편
CS · Time
UTC와 오프셋 - 기준선 하나와 팻말에 적힌 숫자
팻말에 적힌 +09:00은 시간대가 아니다. 그 순간의 차이만 적힌 숫자다. 둘을 같은 것으로 알고 저장했다가 반년 뒤에 한 시간이 밀리는 사고가 여기서 나온다.
시간이라는 데이터 3편
CS · Time
에폭 - 1970년부터 몇 초 흘렀나
큰 시계가 세는 수의 정체는 '정해진 어느 날부터 흐른 초'다. 왜 하필 1970년인지, 왜 2038년에 한 번 무너지는지, 그리고 같은 순간이 어떤 시스템에선 1000배 큰 수로 적히는지를 본다.
시간이라는 데이터 2편
CS · Time
시간 - 컴퓨터에 '지금'은 수 하나다
화면에 뜬 '2025년 9월 30일 오후 3시'를 컴퓨터는 그렇게 들고 있지 않다. 저장된 건 수 하나뿐이고, 날짜와 시각은 그 수에 규칙을 씌워 만든 것이다. 그 규칙이 어긋날 때 무슨 일이 벌어지는지부터 본다.
시간이라는 데이터 1편
CS · Encoding
글자가 깨졌을 때 - 증상만 보고 어디부터 볼지 고르기
깨진 글자의 생김새는 아무렇게나 정해지지 않는다. 물음표 마름모, 네모 상자, 엉뚱한 한자는 각각 다른 곳이 어긋났다는 신호다. 이 시리즈를 한 장의 판단표로 접는다.
비트에 담기는 것들 9편
CS · Encoding
Base64와 퍼센트 인코딩 - 바이트를 글자로 포장하기
글자만 지나갈 수 있는 길에 바이너리를 실어 보내야 할 때가 있다. 그럴 때 쓰는 포장이 Base64와 퍼센트 인코딩이다. 왜 크기가 늘어나는지, 그리고 왜 이걸 암호로 착각하면 안 되는지를 본다.
비트에 담기는 것들 8편
CS · Encoding
글자 수 세기 - 이모지 하나가 일곱 글자로 세지는 이유
입력창에 100자 제한을 걸었는데 사용자는 40자만 쓰고도 막힌다. 사람이 세는 글자와 컴퓨터가 세는 단위가 층마다 다르기 때문이다. 눈에 같아 보이는 두 글자가 서로 다른 데이터인 경우도 여기서 나온다.
비트에 담기는 것들 7편
CS · Encoding
UTF-8 - 상자 크기를 글자마다 다르게 고른 결과
15만 개가 넘는 번호를 바이트에 담는 방법은 여럿이었는데 UTF-8이 세상을 다 먹었다. 이긴 이유는 영리한 압축이 아니라 옛 파일을 하나도 안 건드렸다는 데 있다.
비트에 담기는 것들 6편
CS · Encoding
아스키에서 유니코드로 - 번호부를 하나로 합치기까지
처음엔 글자 128개면 충분했다. 나라마다 남은 자리를 제 맘대로 쓰면서 같은 번호가 서로 다른 글자를 가리키게 됐고, 문서는 국경을 넘을 때마다 깨졌다. 유니코드는 그 혼란을 어떻게 끝냈나.
비트에 담기는 것들 5편
CS · Encoding
부동소수점 - 0.1 더하기 0.2가 0.3이 아닌 이유
거의 모든 언어에서 0.1 + 0.2는 0.3이 아니다. 버그가 아니라 소수를 담는 방식이 그렇게 생겼다. 왜 못 맞추는지, 왜 큰 수일수록 더 성겨지는지, 그리고 돈을 여기에 담으면 안 되는 이유를 본다.
비트에 담기는 것들 4편
CS · Encoding
정수와 넘침 - 21억 다음에 오는 것
정수를 담는 칸은 자리 수가 정해져 있다. 그 칸을 넘어서면 프로그램은 멈추지 않고 조용히 이상한 값을 내놓는다. 왜 최대값 다음이 최소값인지, 왜 하필 한가운데서 터지는지를 본다.
비트에 담기는 것들 3편
CS · Encoding
비트와 바이트 - 자리가 하나 늘면 세상이 두 배가 된다
컴퓨터가 담는 칸은 켜짐과 꺼짐 둘뿐이다. 그 칸이 하나 늘 때마다 담을 수 있는 것이 두 배가 되고, 여덟 개를 묶은 바이트가 모든 이야기의 기본 단위가 된다. 16진수가 왜 굳이 끼어드는지도 여기서 풀린다.
비트에 담기는 것들 2편
CS · Encoding
인코딩 - 컴퓨터는 글자를 모른다
화면 가득한 글자를 컴퓨터는 하나도 모른다. 저장된 것은 숫자뿐이고, 그 숫자를 글자로 되돌리는 건 미리 나눠 가진 약속이다. 그 약속이 어긋날 때 무슨 일이 벌어지는지부터 본다.
비트에 담기는 것들 1편
CS · Algorithm
느릴 때 무엇부터 의심하나 - 길 고르기 한 장
이 시리즈에서 낸 길들을 한 장에 놓는다. 그리고 실제로 코드가 느릴 때 무엇부터 의심해야 하는지, 그 순서가 왜 알고리즘부터가 아닌지.
알고리즘의 갈림길 9편
CS · Algorithm
그리디 - 지금 제일 좋아 보이는 것
앞뒤 안 재고 매 순간 최선을 고르는 방법. 빠르고 코드도 짧은데, 언제 맞는지는 짐작이 아니라 증명으로만 알 수 있다.
알고리즘의 갈림길 8편
CS · Algorithm
동적 계획법 - 한 번 푼 것은 다시 안 푼다
이름이 어렵지 하는 일은 하나다. 계산한 값을 적어두고 다시 묻지 않는 것. 대신 적어둘 자리를 내줘야 하고, 진짜 어려운 건 무엇을 적을지 정하는 일이다.
알고리즘의 갈림길 7편
CS · Algorithm
분할 정복 - 쪼개서 풀고 합친다
쪼개면 왜 빨라지는가. 이득의 출처는 나누기가 아니라 합치기이고, 그 사실을 알면 n log n이 어디서 나오는지도 같이 보인다.
알고리즘의 갈림길 6편
CS · Algorithm
재귀 - 자기를 부르는 함수
재귀는 어려운 기교가 아니라 '같은 모양의 더 작은 문제'를 그대로 코드로 옮긴 것이다. 필요한 건 둘뿐이고, 무너지는 자리도 정해져 있다.
알고리즘의 갈림길 5편
CS · Algorithm
이진탐색 - 반을 버릴 수 있을 때
정렬해 두면 한 번 볼 때마다 절반을 통째로 버릴 수 있다. 그 조건이 무엇인지, 그리고 왜 이 짧은 코드가 그렇게 자주 틀리는지.
알고리즘의 갈림길 4편
CS · Algorithm
정렬 - 줄을 세우는 값과 그 대가
정렬은 그 자체로 답인 경우보다 다른 일을 싸게 만들려고 하는 경우가 많다. 방식이 갈리는 지점과, 실무에서 진짜로 물어야 하는 안정성 이야기.
알고리즘의 갈림길 3편
CS · Algorithm
완전탐색 - 다 해보는 것이 기준선이다
가장 먼저 떠올려야 할 방법은 전부 해보는 것이다. 무식해서가 아니라, 후보가 몇 개인지를 세어봐야 더 나은 방법이 필요한지 알 수 있어서다.
알고리즘의 갈림길 2편
CS · Algorithm
알고리즘 - 답이 아니라 답에 이르는 길
알고리즘은 어려운 수학 이름이 아니라 답에 이르는 절차다. 목적지가 같아도 길은 여럿이고, 무엇을 골랐느냐가 걸리는 시간을 정한다.
알고리즘의 갈림길 1편
CS · Data Structure
무엇을 언제 고르나 - 그릇 고르기 한 장
이 시리즈에서 연 그릇들을 한 장에 놓는다. 고르는 순서는 셋이고, 대부분의 문제는 그중 첫 질문에서 끝난다.
자료구조의 선택 9편
CS · Data Structure
그래프 - 관계 자체가 데이터다
노선도에서 값은 역이 아니라 역 사이의 선에 있다. 방향과 가중치와 순환이 갈리는 자리, 그리고 왜 순환을 그렇게 찾아다니는지까지.
자료구조의 선택 8편
CS · Data Structure
힙과 우선순위 큐 - 제일 급한 것만 위로
전부 줄 세우지 않고 꼭대기 하나만 약속한다. 덜 약속해서 싸지는 그릇이고, 이름이 같은 메모리의 힙과는 아무 관계가 없다.
자료구조의 선택 7편
CS · Data Structure
트리와 이진탐색트리 - 반씩 접어 들어간다
스무고개가 백만 개를 스무 번에 줄이는 원리 그대로다. 다만 질문을 잘못 고르면 스무고개가 하나씩 세는 일이 된다.
자료구조의 선택 6편
CS · Data Structure
해시테이블 - 계산해서 자리를 정한다
찾지 않고 계산한다는 발상 하나로 O(1)이 나온다. 그 대신 충돌을 떠안고, 순서를 잃고, 가끔은 O(1)이 깨진다.
자료구조의 선택 5편
CS · Data Structure
스택과 큐 - 어느 쪽에서 꺼내나
같은 더미인데 꺼내는 자리 하나만 바꿨다. 그 하나가 되돌리기와 작업 큐를 가르고, 스택 오버플로가 왜 나는지도 여기서 설명된다.
자료구조의 선택 4편
CS · Data Structure
배열과 연결리스트 - 자리를 미느냐 고리를 바꾸느냐
중간에 하나 끼워 넣을 때 한쪽은 뒤를 전부 밀고 한쪽은 고리 둘만 바꾼다. 그런데도 실무가 거의 배열을 쓰는 이유까지.
자료구조의 선택 3편
CS · Data Structure
빅오 - 몇 배로 늘어나나
빅오는 어려운 수학이 아니라 늘어나는 모양에 붙인 이름이다. 사람이 두 배로 오면 무엇이 두 배가 되고 무엇이 네 배가 되는지로 읽는다.
자료구조의 선택 2편
CS · Data Structure
자료구조 - 담는 그릇이 속도를 정한다
자료구조는 빠른 것과 느린 것으로 나뉘지 않는다. 무엇을 싸게 하고 무엇을 비싸게 할지를 고르는 일이다. 그릇을 가르는 네 가지 질문부터 본다.
자료구조의 선택 1편
Network · HTTP
주소창 한 줄의 여정 - 밑단을 잇는다
주소창에 한 줄 치고 엔터를 누르면, 이름을 주소로 바꾸고 기계를 찾고 문을 두드리고 자물쇠를 채운 뒤에야 HTTP가 오간다. 지금까지의 밑단을 통째로 이어 그 여정을 따라가며, 어디서 느려지는지까지 짚고 시리즈를 닫는다.
패킷은 어떻게 도착하나 8편
Network · NAT
내 컴퓨터는 왜 직접 안 닿나 - NAT
집 안 기기 수십 개가 공인 IP 하나를 나눠 쓴다. 공유기가 나갈 때 주소를 바꿔치기하고 돌아올 때 되돌리는 NAT 덕이다. 이게 IPv4 부족을 버티게 하는 동시에, 왜 밖에서 내 기계를 직접 못 부르는지도 설명한다.
패킷은 어떻게 도착하나 7편
Network · UDP
그냥 던진다 - UDP
TCP의 악수와 재전송은 신뢰성을 주지만 그만큼 느리다. UDP는 그 안전장치를 다 버리고 그냥 던진다. 도착 보장도 순서 보장도 없는 대신 빠르고 단순한 이 방식이, 왜 영상·게임·HTTP/3에 맞는지.
패킷은 어떻게 도착하나 6편
Network · TCP
안 끊기고 순서대로 오게 - TCP
인터넷은 패킷을 잃기도 뒤섞기도 한다. 그런데 웹페이지는 한 글자도 안 틀리고 순서대로 도착한다. 그 신뢰성을 맡는 TCP - 먼저 악수로 연결을 맺고, 조각마다 받았다는 확인을 주고받으며, 잃은 건 다시 보낸다.
패킷은 어떻게 도착하나 5편
Network · Port
한 기계 안에서 어느 프로세스로 - 포트
IP 주소는 기계까지만 데려다준다. 그 기계 안에는 웹 서버, DB, SSH가 함께 도는데, 도착한 패킷이 어느 프로세스로 가야 하나. 그걸 정하는 문 번호가 포트다. 소켓과 파일 디스크립터로 어떻게 프로세스에 이어지는지까지.
패킷은 어떻게 도착하나 4편
Network · DNS
이름을 주소로 바꾼다 - DNS
우리는 142.250.72.14가 아니라 google.com을 친다. 그 이름을 IP 주소로 바꿔주는 게 DNS다. 이름을 뒤에서부터 단계로 찾아 내려가는 조회, 그리고 캐싱과 TTL이 왜 DNS 변경을 늦게 퍼지게 하는지.
패킷은 어떻게 도착하나 3편
Network · IP
패킷은 어느 기계로 가나 - IP 주소
편지를 보내려면 주소가 필요하듯, 패킷도 목적지 기계의 주소가 필요하다. IP 주소가 무엇이고, 패킷이 어떻게 라우터를 하나씩 건너 목적지까지 가는지 - 라우터가 전체 길을 모르고도 배달이 되는 이유.
패킷은 어떻게 도착하나 2편
Network · Layers
HTTP 밑에 무엇이 있나 - 네트워크 계층
HTTP는 네트워크의 맨 위 한 겹일 뿐이다. 그 밑에 데이터를 실어 나르는 TCP가 있고, 또 그 밑에 기계를 찾아가는 IP가 있다. 봉투 안의 봉투처럼 층으로 쌓인 이 구조를 보면, 왜 각 층을 따로 갈아끼울 수 있는지가 풀린다.
패킷은 어떻게 도착하나 1편
OS · Blocking IO
스레드가 왜 멈춰 서 있나 - 블로킹 I/O
파일이나 네트워크를 기다리는 동안 스레드는 그 자리에 멈춰 선다. 이 블로킹이 왜 스레드 풀과 연결 풀의 크기를 정하고, 비동기가 왜 나왔는지 - 밑바닥의 OS를 다시 백엔드 개념으로 이으며 시리즈를 닫는다.
프로그램은 어떻게 도나 8편
OS · File Descriptor
파일·소켓·연결이 다 같은 번호다 - 파일 디스크립터
파일도, 네트워크 소켓도, DB 연결도 프로그램은 작은 정수 하나로 가리킨다. 파일 디스크립터라는 이 번호가 무엇이고, 왜 유한하며, 안 닫으면 왜 새는지 - 연결 풀이 반납에 그토록 예민한 이유가 여기 있다.
프로그램은 어떻게 도나 7편
OS · System Call
프로그램이 OS에 일을 시키는 법 - 시스템 콜
프로그램은 파일을 직접 읽거나 네트워크로 직접 보내지 못한다. OS에게 부탁해야 한다. 유저 모드와 커널 모드라는 두 세계, 그 경계를 넘는 창구인 시스템 콜, 그리고 그 넘나듦이 왜 공짜가 아닌지.
프로그램은 어떻게 도나 6편
OS · Context Switch
CPU 하나로 어떻게 동시에 도나 - 컨텍스트 스위치
CPU 코어는 몇 개뿐인데 스레드는 수천 개다. OS는 스레드를 아주 빠르게 번갈아 태워 동시에 도는 것처럼 보이게 한다. 그 바꿔 태우기에 드는 비용이, 왜 스레드가 많을수록 손해인지를 설명한다.
프로그램은 어떻게 도나 5편
OS · Thread
스레드는 프로세스와 뭐가 다른가 - 스레드
한 프로세스 안에서 여러 일을 동시에 하는 실행 흐름이 스레드다. 같은 주소공간을 공유하되 자기 스택만 따로 갖는다. 이 공유가 왜 스레드를 싸게 만들면서 동시에 공유 상태 문제를 낳는지.
프로그램은 어떻게 도나 4편
OS · Stack
지역변수와 new는 어디에 사나 - 스택과 힙
같은 주소공간 안에서도 지역변수와 직접 할당한 객체는 사는 곳이 다르다. 함수마다 쌓였다 자동으로 치워지는 스택, 직접 얻어 오래 두는 힙 - 스택 오버플로와 메모리 누수가 왜 생기는지가 여기서 갈린다.
프로그램은 어떻게 도나 3편
OS · Virtual Memory
왜 내 메모리를 남이 못 건드리나 - 가상 메모리
두 프로그램이 똑같은 메모리 주소를 써도 서로 안 부딪힌다. 각 프로세스가 보는 주소는 가짜고, OS가 진짜 물리 메모리로 몰래 바꿔치기하기 때문이다. 이 한 겹이 격리를 공짜로 만든다.
프로그램은 어떻게 도나 2편
OS · Process
프로그램이 실행되면 무엇이 되나 - 프로세스
디스크의 파일 하나가 실행되면 프로세스가 된다. 자기만의 메모리, 열어둔 자원 목록, 어디까지 실행했는지 - 프로세스가 받는 세 가지를 보면, 왜 프로그램끼리 서로의 메모리를 못 건드리는지가 풀린다.
프로그램은 어떻게 도나 1편
Event-Driven · DLQ
실무의 이벤트 - 언제 꺼내고 무엇을 조심하나
패턴을 안다고 다 써야 하는 건 아니다. 이벤트 스키마라는 계약, 순서와 독약 메시지, 배포 후 안 보이는 흐름을 트레이싱으로 잇기, 그리고 애초에 이벤트가 답이 아닌 자리까지 짚으며 시리즈를 닫는다.
느슨하게 잇는다 8편
Event-Driven · Event Sourcing
상태 대신 이벤트를 진실로 - 이벤트 소싱
보통 DB엔 지금 상태만 남고 어쩌다 그렇게 됐는지는 덮어써져 사라진다. 상태 대신 일어난 일의 목록을 저장하고 필요하면 재생해 상태를 얻는 이벤트 소싱, 감사와 되감기가 공짜로 딸려오는 대신 치르는 값.
느슨하게 잇는다 7편
Event-Driven · CQRS
쓰는 모델과 읽는 모델을 가른다 - CQRS
쓸 때 좋은 데이터 모양과 읽을 때 좋은 모양은 다르다. 한 모델로 둘 다 하려면 한쪽이 고생한다. 명령과 조회를 아예 갈라 각자 최적의 모양을 갖게 하는 CQRS, 그 대가인 동기화 지연까지.
느슨하게 잇는다 6편
Event-Driven · Saga
흐름을 한곳에서 - 사가: 오케스트레이션
코레오그래피는 흐름이 코드 어디에도 없어 커지면 안 보인다. 지휘자 하나를 두고 각 단계에 명령을 보내 흐름을 한곳에 쥐는 오케스트레이션, 그리고 둘을 언제 고르나.
느슨하게 잇는다 5편
Event-Driven · Saga
여럿에 걸친 일을 잇는다 - 사가: 코레오그래피
주문 하나가 결제·재고·배송을 건드리는데, 서비스가 갈려 한 트랜잭션으로 못 묶는다. 여러 로컬 트랜잭션을 이벤트로 잇고 실패하면 보상으로 되돌리는 사가, 그중 코디네이터 없이 서로 반응하는 코레오그래피.
느슨하게 잇는다 4편
Event-Driven · Outbox
저장과 발행을 한 묶음으로 - 아웃박스
DB에 저장하고 이벤트를 발행하는 사이에 프로세스가 죽으면, 저장은 됐는데 발행은 안 된 어중간한 상태가 남는다. 두 시스템을 한 트랜잭션으로 못 묶는 문제를, 발행을 DB에 먼저 적어 푼다.
느슨하게 잇는다 3편
Event-Driven · Idempotency
같은 메시지가 두 번 와도 - 멱등 소비자
메시지 시스템은 확실히 전달하려다 중복을 만든다. 받는 쪽이 두 번 처리하면 결제가 두 번 된다. 처리한 걸 기억하거나 연산 자체를 멱등하게 만들어, 두 번 받아도 한 번처럼 삼키는 법.
느슨하게 잇는다 2편
Event-Driven · Architecture
이으면 생기는 문제들 - 이벤트 패턴 지도
쪼개고 비동기로 이으면 편해지는 대신 새 문제가 생긴다. 중복·발행 누락·분산 트랜잭션·복잡한 조회 - 벽마다 정해진 패턴이 있다. 그 이름들의 지도를 먼저 편다.
느슨하게 잇는다 1편
Testing · CI
실무의 테스트 - 믿을 수 있는 테스트를 유지한다
테스트는 짜는 것보다 믿을 수 있게 유지하는 게 어렵다. 빠름·독립·결정적이라는 좋은 테스트의 성질, CI에서 자동으로 도는 이유, 무엇을 자동화하고 무엇은 사람이 하는지로 시리즈를 닫는다.
테스트가 지켜주는 것 7편
Testing · TDD
TDD - 실패하는 테스트부터 쓴다
테스트를 나중이 아니라 먼저 쓴다. 빨강-초록-리팩터 사이클, 왜 먼저 쓰면 요구가 고정되고 설계 압력이 생기는지, 그리고 TDD를 둘러싼 오해와 안 맞는 자리까지.
테스트가 지켜주는 것 6편
Testing · Integration Test
통합과 E2E - 진짜를 붙여 본다
단위가 다 초록인데 합치면 안 돈다. 이음매는 진짜를 붙여야 보인다. 통합 테스트와 계약 테스트, E2E가 왜 느리고 불안정한지, 플래키를 어떻게 다루는지까지.
테스트가 지켜주는 것 5편
Testing · Coverage
무엇을 테스트하고 무엇은 안 하나
다 테스트하려다 다 못 한다. 구현이 아니라 행동을, 정상 경로가 아니라 경계를 노린다. 커버리지 숫자의 함정과 깨지기 쉬운 테스트, 그리고 테스트하지 않아도 되는 것까지.
테스트가 지켜주는 것 4편
Testing · Test Double
테스트 더블 - 진짜 대신 가짜를 끼운다
단위 테스트를 빠르게 하려면 진짜 DB·외부 API를 떼고 가짜로 갈아끼워야 한다. dummy·stub·spy·mock·fake가 어떻게 다른지, 상태 검증과 행위 검증의 차이, 과한 목의 함정까지.
테스트가 지켜주는 것 3편
Testing · Test Pyramid
테스트 피라미드 - 무엇을 얼마나 짜나
테스트는 단위·통합·E2E 세 층으로 나뉜다. 아래로 갈수록 빠르고 싸서 많이, 위로 갈수록 느리고 불안정해서 적게. 뒤집히면 아이스크림콘 안티패턴이 되는 이유까지.
테스트가 지켜주는 것 2편
Testing · Unit Test
왜 테스트하나 - 확신이 변경을 두렵지 않게 한다
테스트를 귀찮은 숙제로 여기면 손해는 나중에 온다 - 고칠 때마다 무서워지는 코드로. 테스트가 회귀 안전망이자 실행되는 문서이자 설계 압력이 되는 이유를 본다.
테스트가 지켜주는 것 1편
Observability · OpenTelemetry
세 기둥을 하나로 - 실무의 관측가능성
로그·메트릭·트레이스가 따로 놀면 반쪽이다. trace ID가 셋을 하나로 잇고, OpenTelemetry가 한 규격으로 심게 한다. 무엇을 남길지의 비용 문제와 함께 시리즈를 닫는다.
장애를 어떻게 보나 6편
Observability · Alerting
헬스체크와 알림 - 터지기 전에, 터졌을 때
신호를 모았으면 언제 사람을 부를지 정해야 한다. 살아있음과 준비됨의 차이, 증상에 알리고 원인은 대시보드에 두는 원칙, SLO와 에러 예산, 그리고 알림 피로까지.
장애를 어떻게 보나 5편
Observability · Tracing
분산 트레이싱 - 요청 하나를 끝까지 따라간다
여러 서비스를 지나는 요청 하나가 어디서 느렸는지, 로그와 메트릭은 못 답한다. 스팬과 트레이스, 폭포수로 병목을 짚는 법, 서비스 경계를 넘는 상관ID까지.
장애를 어떻게 보나 4편
Observability · Metrics
메트릭 - 지금 시스템이 어떤가
메트릭은 시간에 따른 수다. 카운터·게이지·히스토그램 세 유형, 라벨이 비용이 되는 카디널리티 함정, 그리고 평균이 아니라 분포로 봐야 하는 이유까지.
장애를 어떻게 보나 3편
Observability · Logging
로그 - 무슨 일이 있었나
로그는 사건의 기록이다. 문자열로 찍으면 사람만 읽고 기계는 못 읽는다. 구조화 로깅으로 필드를 남기고, 상관ID로 흩어진 줄을 한 요청으로 꿰는 법까지.
장애를 어떻게 보나 2편
Observability · Monitoring
관측가능성이 푸는 문제 - 터졌는데 어디가 문제인지 모른다
서비스가 여러 조각으로 나뉘면 '느리다' 신고 하나에 범인 후보가 수십이다. 모니터링과 관측가능성이 어떻게 다른지, 세 기둥(로그·메트릭·트레이스)이 각자 어떤 질문에 답하는지 본다.
장애를 어떻게 보나 1편
DevOps · Deployment
무중단 배포 - 안 끄고 갈아끼운다
구버전을 끄고 신버전을 켜는 사이에는 공백이 생긴다. 그 공백을 없애는 전략들(롤링·블루그린·카나리)이 각각 무엇을 사고 무엇을 파는지 본다.
Scaling · Resilience
서킷 브레이커와 백프레셔 - 번지는 것을 끊는다
한 서비스의 장애는 그걸 부르는 쪽으로 번지고, 빠른 생산자는 느린 소비자를 무너뜨린다. 그 번짐을 반대 방향에서 끊는 두 장치를 본다.
Cryptography · Password
비밀번호는 암호화하지 않는다 - 되읽을 게 아니라 맞춰볼 것이다
서버는 비밀번호를 되읽을 필요가 없다. 그래서 암호화가 아니라 해시로 저장한다. 솔트를 섞고, 일부러 느린 해시를 쓰는 이유까지.
암호는 무엇을 지키나 6편
Cryptography · Digital Signature
디지털 서명과 인증서 - 이 공개키가 진짜 네 것인가
개인키로 서명하고 공개키로 검증한다. HMAC과 달리 부인을 못 한다. 그리고 그 공개키가 진짜 그 사람 것임은 인증서와 신뢰 사슬이 보증한다.
암호는 무엇을 지키나 5편
Cryptography · Hash
해시와 HMAC - 바뀌었는지를 안다
해시는 되돌릴 수 없는 지문이다. 충돌은 반드시 있지만 못 찾을 뿐. 그런데 해시만으론 위조를 못 막아서, 비밀키를 섞은 HMAC이 필요하다.
암호는 무엇을 지키나 4편
Cryptography · Public Key
공개키 암호와 하이브리드 - 열쇠를 둘로 나눈다
잠그는 열쇠는 공개하고 여는 열쇠만 감춘다. 그래서 키 분배 문제가 풀린다. 대신 느려서, 실제 통신은 공개키로 대칭키만 건네는 하이브리드로 간다.
암호는 무엇을 지키나 3편
Cryptography · AES
대칭키 암호 - 열쇠 하나로 잠그고 연다
AES는 블록 단위로 감춘다. 같은 블록이 같게 나오면 새는 이유, 열쇠 길이가 안전을 정하는 법, 그리고 남는 단 하나의 문제 - 열쇠를 어떻게 건네나.
암호는 무엇을 지키나 2편
Cryptography · Encryption
암호화가 푸는 문제 - 무엇을 감추고 무엇은 못 감추나
암호화·해싱·인코딩은 다른 일을 한다. 되돌릴 수 있느냐로 셋을 가르고, 암호가 지키는 세 가지와 못 지키는 것까지 본다.
암호는 무엇을 지키나 1편
DevOps · CI/CD
CI/CD - 사람이 안 하게 만든다
배포 절차를 사람이 기억하면 언젠가 한 단계를 빠뜨린다. 이 블로그를 실제로 배포하는 워크플로를 재료로 각 단계가 왜 있는지 본다.
빌드에서 배포까지 6편
DevOps · Nginx
리버스 프록시와 Nginx
앱 앞에 하나를 세우면 라우팅·TLS 종료·정적 서빙·버퍼링이 앱 밖으로 나간다. 로드 밸런서와 어떻게 다른지까지.
빌드에서 배포까지 5편
DevOps · Kubernetes
쿠버네티스 - 누가 돌보나
해야 할 일을 시키는 대신 원하는 상태를 적어둔다. 그 한 가지 발상이 자가 치유와 스케일링을 같이 만들어낸다.
빌드에서 배포까지 4편
DevOps · Docker
Docker - 이미지를 어떻게 만드나
Dockerfile 한 줄이 레이어 하나가 된다. 캐시가 어디서 깨지는지 알면 빌드 시간과 이미지 크기가 같이 잡힌다.
빌드에서 배포까지 3편
DevOps · Container
컨테이너 - 프로세스를 싸 들고 다닌다
OS를 통째로 복제하지 않고도 환경을 같이 옮기는 방법. 격리·이미지·레이어를 VM과 비교해서 잡는다.
빌드에서 배포까지 2편
DevOps · Container
내 컴퓨터에선 되는데
로컬에선 멀쩡한 코드가 서버에서만 죽는다. 그 차이가 어디서 오는지 보면 컨테이너가 왜 나왔는지가 보인다.
빌드에서 배포까지 1편
Architecture · Consistency
나누면 정합성을 잃는다
두 서비스의 숫자가 다르다. CAP는 셋 중 둘을 고르라는 말이 아니고, 실무의 선택은 이분법이 아니라 눈금이다.
시스템을 나누는 기준 6편
Architecture · Event-Driven
Pub/Sub과 이벤트 기반
일을 시키는 대신 일어난 일을 알린다. 듣는 쪽을 몰라도 되는 대신, 흐름이 코드에서 사라진다.
시스템을 나누는 기준 5편
Architecture · Message Queue
메시지 큐 - 기다리지 않게 만든다
지금 안 해도 되는 일을 쌓아두고 나중에 처리한다. 대신 실패가 나중에 오고, 중복이 오고, 순서가 흔들린다.
시스템을 나누는 기준 4편
Architecture · Microservices
서비스끼리 어떻게 부르나
동기 호출은 가장 단순한 답이지만, 한 곳의 느려짐이 전체로 번지는 통로이기도 하다. 타임아웃·재시도·차단기로 그 통로를 좁힌다.
시스템을 나누는 기준 3편
Architecture · Microservices
나누면 무엇이 달라지나
배포·장애·확장 단위를 갈라놓는 대신 네트워크가 끼어든다. 얻는 것과 새로 지는 비용을 나란히 놓는다.
시스템을 나누는 기준 2편
Architecture · Monolith
모놀리스가 먼저다
한 덩어리로 만드는 건 아직 못 나눈 상태가 아니라 정상적인 출발점이다. 무엇이 쉬워지고, 언제부터 아파지는가.
시스템을 나누는 기준 1편
Rate Limiting · Scaling
Rate Limiting - 넘치면 막는다
더 받는 법으로는 막을 수 없는 유입이 있다. 토큰 버킷 하나를 깊게 보고, 무엇을 기준으로 세고 서버가 여러 대일 때 카운터를 어디에 두는지까지 간다.
부하를 견디는 법 7편
CDN · Cache
CDN - 사용자 가까이 둔다
서버를 아무리 늘려도 거리는 안 줄어든다. 사본을 사용자 근처에 두는 층이 무엇을 해결하고, 공유 캐시라서 무엇이 위험한지 본다.
부하를 견디는 법 6편
Load Balancer · Scaling
로드 밸런서 - 앞에서 나눠준다
서버를 여러 대 두면 누가 어디로 보낼지 정해야 한다. 분배 알고리즘보다 중요한 건 어느 층에서 보는가, 죽은 서버를 어떻게 아는가, TLS를 어디서 푸는가다.
부하를 견디는 법 5편
Scaling · Architecture
수직이냐 수평이냐
서버를 키우는 것과 늘리는 것은 난이도가 다르다. 늘리는 쪽이 어려운 이유는 서버가 아니라 서버가 들고 있는 상태에 있다.
부하를 견디는 법 4편
Cache · Redis
캐시가 프로세스 밖으로 나가면
서버마다 캐시가 달라지는 문제를 공용 캐시로 푼다. 대신 네트워크·직렬화·단일 장애점·스탬피드라는 계산서가 새로 온다.
부하를 견디는 법 3편
Cache · Performance
캐시 - 같은 답을 두 번 만들지 않는다
한 번 만든 결과를 들고 있다가 다시 준다. 쉬운 이야기라서 위험한데, 진짜 알맹이는 무엇에는 캐시를 붙이면 안 되는가다.
부하를 견디는 법 2편
Performance · Scaling
무엇이 먼저 무너지나
부하가 늘면 전부가 고르게 느려지는 게 아니라 가장 좁은 한 곳이 먼저 막힌다. 도구를 고르기 전에 그 자리를 찾는 이야기.
부하를 견디는 법 1편
Security · Browser
CSRF - 브라우저가 쿠키를 알아서 보낸다
응답을 못 읽어도 요청은 나간다. 동일 출처 정책이 원래 막지 않던 틈에서 위조 요청이 성립하는 조건과, 토큰·SameSite로 그 조건을 깨는 방법.
브라우저는 무엇을 막나 4편
Security · Browser
XSS - 남의 스크립트가 내 페이지에서 돈다
데이터로 넣은 글자가 코드가 되는 순간 출처는 이미 같아져 있다. 동일 출처 정책이 왜 못 막는지, 방어가 왜 출력 자리에 있는지.
브라우저는 무엇을 막나 3편
Security · Browser
CORS - 막은 게 아니라 안 알려주는 것
서버 로그는 200인데 브라우저는 에러를 낸다. CORS는 동일 출처 정책을 뚫는 구멍이 아니라 서버가 예외를 승인하는 절차이고, 애초에 공격을 막는 물건이 아니다.
브라우저는 무엇을 막나 2편
Security · Browser
같은 출처만 믿는다
브라우저가 출처를 스킴·호스트·포트로 가르고, 다른 출처의 응답을 스크립트에 넘기지 않는 이유. 이 규칙 하나에서 CORS·XSS·CSRF가 갈라져 나온다.
브라우저는 무엇을 막나 1편
Authorization · RBAC
권한을 어떻게 표현하나
역할과 속성, 그리고 스코프. 권한을 무엇으로 적을지와 어디서 검사할지를 함께 정한다.
인증과 인가 7편
OAuth2 · Authorization
OAuth 2.0 - 열쇠를 주지 않고 권한만 넘긴다
구글로 로그인이 내 비밀번호를 받지 않는 이유. Authorization Code + PKCE 흐름 하나를 끝까지 따라간다.
인증과 인가 6편
Security · Authentication
패스키 - 보낼 비밀이 없으면 훔칠 것도 없다
비밀번호가 새는 사고는 전부 '비밀을 보낸다'는 한 가지에서 나온다. 안 보내고 증명하는 방법과, 그 대신 무엇이 어려워지는지 본다.
인증과 인가 5편
Session · JWT
세션이냐 토큰이냐
같은 문제에 정반대 답을 낸 두 방식을 네 개의 축으로 견준다. 틀린 선택이 아니라 다른 선택이다.
인증과 인가 4편
JWT · Token
JWT - 서버가 기억하지 않는다
토큰 안에 신원을 담고 위조만 막는다. 세 조각 구조와 검증 절차, 그리고 서명은 암호화가 아니라는 사실.
인증과 인가 3편
Session · Cookie
쿠키와 세션 - 서버가 기억한다
로그인 결과를 서버가 들고 있고 브라우저는 번호표만 든다. 쿠키·세션 ID·저장소·만료를 장면으로 따라간다.
인증과 인가 2편
Authentication · Authorization
인증과 인가는 다른 질문이다
로그인은 됐는데 403이 뜬다. 누구인가와 무엇을 할 수 있나는 서로 다른 질문이고, 실패했을 때 답도 다르다.
인증과 인가 1편
API · Versioning
버저닝과 하위 호환
v2를 냈는데 v1을 못 내리는 상황을 어떻게 피하나. 깨지 않고 바꾸는 방법이 먼저이고, 버전을 가르는 건 그다음이다.
API 설계 8편
API · gRPC
gRPC - 같은 양식을 미리 나눠 갖는다
REST도 JSON도 브라우저가 읽는다는 전제 위의 선택이었다. 그 전제가 없는 서버 사이 호출에서 gRPC가 무엇을 바꾸고 무엇을 내주는지 본다.
API 설계 7편
API · GraphQL
GraphQL - 필요한 것만 받는다
화면 하나에 API를 다섯 번 부르는 문제를 GraphQL은 어떻게 다르게 푸나. REST와의 차이와 그 대가만 본다.
API 설계 6편
API · JSON
JSON - 왜 이게 표준이 됐나
타입이 여섯 개뿐인 형식이 어떻게 API의 기본이 됐나. 큰 정수·날짜·null이라는 세 함정과 스키마 없음의 대가.
API 설계 5편
API · REST
상태 코드와 에러 응답
200 OK인데 본문에 error가 있는 응답은 왜 문제인가. 상태 코드를 고르는 기준과 에러 본문을 한 벌로 통일하는 법.
API 설계 4편
API · REST
Endpoint 설계
같은 목록을 주는 URL이 여럿이 되지 않게 하는 법. 컬렉션과 단건, 중첩 기준, 필터·정렬·페이징 파라미터와 목록 응답 모양을 정한다.
API 설계 3편
API · REST
REST - 자원으로 말한다
/getUserList는 왜 REST가 아닌가. 동사를 URL에서 걷어내고 자원과 메서드로 말하는 방식을 잡는다.
API 설계 2편
API · Design
API는 약속이다
내부 코드는 언제든 고치지만 공개한 API는 남이 이미 그 모양에 맞춰 코드를 짜뒀다. API를 계약으로 보는 관점을 잡는다.
API 설계 1편
WebSocket · HTTP
WebSocket - 요청 없이 받는다
서버가 먼저 말을 걸 수 없다는 전제를 뒤집는 방법들. 폴링부터 SSE, 그리고 프로토콜을 바꾸는 WebSocket까지.
HTTP는 어떻게 오가나 6편
HTTPS · TLS
HTTPS - 무엇을 감추고 무엇을 못 감추나
자물쇠가 떴다고 다 가려진 게 아니다. HTTPS가 실제로 감추는 것과, 감싸고도 그대로 노출되는 것을 가른다.
HTTP는 어떻게 오가나 5편
HTTP · Web
캐시 - 안 보내는 게 가장 빠르다
배포했는데 사용자 화면이 안 바뀐다. 그 사고에서 출발해 Cache-Control·ETag·조건부 요청이 무엇을 정하는지 본다.
HTTP는 어떻게 오가나 4편
HTTP · Web
연결을 매번 새로 맺지 않는다
요청을 보내려면 먼저 연결부터 맺어야 한다. 그 준비 비용을 줄이려는 시도가 HTTP 버전을 올려온 이유다.
HTTP는 어떻게 오가나 3편
HTTP · Web
상태를 안 갖는다는 것
서버는 방금 로그인한 사람도 다음 요청에서 못 알아본다. 그 불편을 일부러 감수한 이유와, 그래서 상태를 어디에 두게 됐는지.
HTTP는 어떻게 오가나 2편
HTTP · Web
요청과 응답 - 한 번의 왕복에 무엇이 오가나
주소창에 한 줄 쳤을 때 실제로 오가는 건 글자 몇 줄이다. 그 글자가 어떻게 생겼고 어디를 지나는지 본다.
HTTP는 어떻게 오가나 1편
Connection Pooling · Database
Connection Pooling
스레드가 DB를 부르려면 연결이 필요한데, 연결은 만드는 것도 무제한도 비싸다. 미리 열어 재사용하되, 연결은 DB가 상한을 정하는 자원이다.
동시성과 자원 풀링 3편
Thread Pool · Concurrency
Thread Pool
스레드는 만드는 것도 무제한도 비싸다. 미리 만들어 재사용하고, 그 개수로 동시 실행을 제한하는 것 - Thread Pool.
동시성과 자원 풀링 2편
Concurrency · Thread
Concurrency
서버는 요청을 동시에 처리해야 한다. 그런데 여러 스레드가 같은 것을 건드리면 조용히 어긋난다 - 경쟁 상태와 그걸 막는 법.
동시성과 자원 풀링 1편
Pagination · Database
Pagination
100만 건을 한 번에 줄 순 없다. 나눠 주는 두 방법 - offset과 cursor, 그리고 왜 offset이 뒤로 갈수록 느려지고 밀리는가.
Idempotency · HTTP
Idempotency
네트워크는 못 믿는다. 같은 요청이 두 번 와도 한 번 한 것과 같게 - 멱등성과, POST를 멱등하게 만드는 Idempotency Key, 그리고 그 키를 누가 어떻게 만드는가.
JPA · ORM
Persistence Context
save()를 안 불렀는데 UPDATE가 나간다. JPA가 엔티티를 관리하는 공간, 영속성 컨텍스트로 그 수수께끼를 푼다.
ORM · JPA
ORM
자바 객체와 DB 테이블 사이를 손으로 나르지 않는다. JPA로 개념을 잡고, ORM이 만드는 SQL까지 본다.
Middleware · Spring
Middleware
핸들러마다 반복되는 공통 처리를 요청과 응답 사이 한 줄로 세운다. Spring의 Filter로 개념을 잡는다.
Active Record · Design Pattern
Active Record
객체가 자기를 저장할 줄 안다. Repository와 정반대 선택이고, 틀린 선택이 아니라 다른 선택이다.
Aggregate · Design Pattern
Aggregate
어디까지가 한 덩어리인가. 함께 지켜야 할 것을 묶고, 그 경계를 트랜잭션과 저장소가 따라간다.
도메인 모델링 3편
Value Object · Design Pattern
Entity와 Value Object
무엇으로 같음을 판단하나. 식별자로 같은 것과 값이 같으면 같은 것, 그 둘을 갈라 쓰는 이유.
도메인 모델링 2편
Domain Model · Design Pattern
로직을 어디에 둘 것인가
업무 규칙을 절차에 늘어놓을 것인가, 객체에 넣을 것인가. 트랜잭션 스크립트와 도메인 모델, 그리고 둘을 가르는 기준.
도메인 모델링 1편
Unit of Work · Design Pattern
Unit of Work
저장할 때마다 DB에 쓰면 업무의 반쪽만 남을 수 있다. 변경을 한 단위로 모았다가 한 번에 반영하는 패턴.
DTO · Design Pattern
DTO
엔티티를 그대로 내보내면 DB 구조가 곧 API 계약이 된다. 계층을 건너는 전용 그릇을 따로 두는 패턴.
Service Layer · Design Pattern
Service Layer
컨트롤러에 업무 절차가 쌓인다. 절차를 서비스 계층으로 옮겨, 입구가 여럿이어도 규칙은 한 곳에 있게 만드는 패턴.
Repository Pattern · Design Pattern
Repository Pattern
비즈니스 로직에서 DB 코드를 걷어낸다. 데이터 접근을 인터페이스 뒤로 숨겨, 구현을 갈아끼워도 로직은 그대로 두는 패턴.
GoF · Behavioral
Interpreter
작은 언어의 문법을 객체 트리로 표현하고 그 트리를 재귀로 평가하는, 드물지만 발상이 또렷한 행위 패턴.
행동 패턴 11편
GoF · Behavioral
Visitor
객체 구조는 그대로 두고, 그 위를 도는 새 연산을 바깥의 방문자로 추가하는 행위 패턴.
행동 패턴 10편
GoF · Behavioral
Memento
객체의 내부 상태를 캡슐화를 깨지 않고 스냅샷으로 저장해뒀다가 되돌리는 행위 패턴.
행동 패턴 9편
GoF · Behavioral
Mediator
객체들이 서로 직접 참조하며 얽히지 않도록, 중재자를 하나 세워 소통을 그리로 몰아주는 행위 패턴.
행동 패턴 8편
GoF · Behavioral
Iterator
컬렉션의 속을 열어 보지 않고 원소를 순서대로 훑을 때. 순회를 캡슐화해 내부 구조와 순회 코드를 떼어 놓는 행위 패턴.
행동 패턴 7편
GoF · Behavioral
Chain of Responsibility
누가 처리할지 미리 못 정할 때. 요청을 처리자들의 사슬에 흘려보내 처리 가능한 자가 맡게 하는 행위 패턴.
행동 패턴 6편
GoF · Behavioral
State
상태에 따라 행동이 갈릴 때. 상태를 객체로 만들어 거대한 조건문을 다형성으로 바꾸는 행위 패턴.
행동 패턴 5편
GoF · Behavioral
Template Method
여러 흐름이 큰 틀은 같은데 한 단계만 다를 때. 뼈대를 상위가 고정하고 달라지는 구멍만 하위가 채우는 행위 패턴.
행동 패턴 4편
GoF · Behavioral
Command
요청을 나중에 실행하거나 되돌리거나 기록하고 싶을 때. 요청 자체를 객체로 캡슐화하는 행위 패턴.
행동 패턴 3편
GoF · Behavioral
Observer
상태가 바뀔 때마다 관심 있는 것들을 일일이 불러야 할 때. 구독한 여럿에게 자동으로 통지하는 행위 패턴.
행동 패턴 2편
GoF · Behavioral
Strategy
기준이 늘 때마다 if/switch를 고쳐야 할 때. 알고리즘을 인터페이스로 빼 런타임에 갈아끼우는 행위 패턴.
행동 패턴 1편
GoF · Structural
Flyweight
같은 객체를 수백만 개 만들어 메모리가 터질 때. 공유 가능한 부분을 뽑아 하나만 만들어 나눠 쓰는 구조 패턴.
구조 패턴 7편
GoF · Structural
Bridge
두 축이 곱해지며 클래스가 폭발할 때. '무엇'과 '어떻게'를 두 계층으로 갈라 다리로 잇고, 각자 독립해 자라게 하는 구조 패턴.
구조 패턴 6편
GoF · Structural
Composite
파일과 폴더처럼 개별과 묶음이 섞인 트리를, 클라이언트가 구분 없이 똑같이 다루게 하는 구조 패턴.
구조 패턴 5편
GoF · Structural
Facade
하나 하려고 여러 개를 순서대로 불러야 할 때. 복잡한 하위 시스템 앞에 단순한 창구 하나를 세우는 구조 패턴.
구조 패턴 4편
GoF · Structural
Proxy
진짜 객체 앞에 대리인을 세워 접근을 제어한다. 지연 로딩·권한 검사·캐싱을 진짜를 건드리지 않고 끼우는 구조 패턴.
구조 패턴 3편
GoF · Structural
Decorator
상속으로 조합을 만들면 클래스가 폭발한다. 같은 인터페이스로 감싸 기능을 덧입히고, 여러 겹으로 쌓는 구조 패턴.
구조 패턴 2편
GoF · Structural
Adapter
내 코드가 기대하는 인터페이스와 남의 코드가 주는 인터페이스가 안 맞을 때. 사이에 번역기를 끼워 붙게 만드는 구조 패턴.
구조 패턴 1편
GoF · Creational
Prototype
처음부터 만들지 않고, 이미 있는 객체를 복제해 새로 만든다. 얕은 복사의 함정과 clone()의 문제까지 다루는 마지막 생성 패턴.
생성 패턴 5편
GoF · Creational
Builder
인자가 많고 대부분 선택인 객체를, 생성자 폭발 없이 단계별로 조립한다. 읽히고, 필수를 강제하고, 끝에서 불변으로 굳히는 생성 패턴.
생성 패턴 4편
GoF · Creational
Abstract Factory
따로 만들면 짝이 어긋난다. 서로 맞아야 하는 관련 객체들을 한 세트로 만들어, 섞이지 않게 보장하는 생성 패턴.
생성 패턴 3편
GoF · Creational
Factory Method
객체를 만드는 코드가 구체 타입에 박히지 않게. 무엇을 만들지 하위 클래스가 결정하도록 생성을 메서드로 빼는 생성 패턴.
생성 패턴 2편
GoF · Creational
Singleton
앱 전체에 인스턴스가 딱 하나만 있어야 할 때. 만드는 법은 간단하지만, 멀티스레드와 전역 상태라는 두 함정이 따라오는 생성 패턴.
생성 패턴 1편
SOLID · DIP
Dependency Inversion Principle
고수준 정책이 저수준 구현에 매달리지 않게. 둘 사이에 추상화를 두어 의존의 방향을 뒤집는 마지막 SOLID 원칙.
SOLID 원칙 5편
SOLID · ISP
Interface Segregation Principle
쓰지도 않는 메서드에 의존하게 만들지 마라. 뚱뚱한 인터페이스를 역할별로 쪼개는 네 번째 SOLID 원칙.
SOLID 원칙 4편
SOLID · LSP
Liskov Substitution Principle
자식은 부모 자리에 넣어도 약속을 깨면 안 된다. 상속은 구조가 아니라 계약을 물려받는 것 - 세 번째 SOLID 원칙.
SOLID 원칙 3편
SOLID · OCP
Open/Closed Principle
새 동작은 추가하되 기존 코드는 고치지 않는다. 타입이 늘 때마다 if-else를 여는 대신, 다형성으로 확장점을 두는 두 번째 SOLID 원칙.
SOLID 원칙 2편
SOLID · SRP
Single Responsibility Principle
클래스가 바뀌는 이유는 하나여야 한다. '일'이 아니라 '이유'로 나누는 첫 번째 SOLID 원칙.
SOLID 원칙 1편
Database · Storage
B-tree와 LSM-tree - 읽기와 쓰기 중 무엇을 팔 것인가
8바이트를 바꾸려고 8KB를 다시 쓴다. 그게 싫으면 뒤집으면 되는데, 그러면 읽기가 대가를 낸다.
데이터베이스 공통 개념 14편
Database · NoSQL
NoSQL - 조립을 언제 하느냐의 문제다
SQL을 안 쓴다는 뜻이 아니다. 사실을 쪼개 두고 읽을 때 붙일 것인가, 읽을 모양대로 미리 붙여 둘 것인가. 그 하나에서 이득도 대가도 전부 나온다.
데이터베이스 공통 개념 13편
Database · Scaling
복제 - 방금 쓴 걸 왜 못 읽는가
읽기를 늘리려고 복제했더니 시간이 뒤엉킨다. 그리고 격리 수준은 이걸 막아주지 않는다.
데이터베이스 공통 개념 12편
Database · Scaling
파티셔닝과 샤딩 - 나누면 무엇을 잃는가
둘의 경계는 '누가 조각을 아는가'다. 그리고 샤딩하는 순간 지금까지의 트랜잭션 이야기가 대부분 무효가 된다.
데이터베이스 공통 개념 11편
Database · Design
키 설계 - 무엇으로 행을 가리킬 것인가
자연키가 배신하는 순간, 대리키를 쓰면서 흔히 빠뜨리는 것, 그리고 UUID가 인덱스를 망가뜨리는 이유.
데이터베이스 공통 개념 10편
Database · Design
정규화 - 한 테이블은 한 가지 사실만 말한다
정규형을 외우지 않고도 판단하는 법, 그리고 반정규화가 실제로 무엇을 사고파는 거래인지.
데이터베이스 공통 개념 9편
Database · Performance
실행 계획 - 세 가지만 보면 된다
EXPLAIN 출력이 외계어처럼 보일 때. 트리를 어느 방향으로 읽고, 어디서 범인을 찾는가.
데이터베이스 공통 개념 8편
Database · Join
조인 알고리즘 - DB는 세 가지 방법 중 하나를 고른다
중첩 반복·해시·정렬 병합이 각각 언제 이기는지, 그리고 조인이 갑자기 느려지는 진짜 이유.
데이터베이스 공통 개념 7편
Database · Index
인덱스 - 왜 빠르고, 왜 만들어도 안 타는가
B-tree가 이진트리가 아닌 이유부터, 인덱스를 만들어놓고도 풀스캔이 도는 다섯 가지 경우까지.
데이터베이스 공통 개념 6편
Database · Storage
블록 - DB는 바이트를 모른다
4바이트를 읽으려고 8KB를 읽는다. 낭비처럼 보이는 이 단위가 뒤에 나올 거의 모든 것의 바닥이다.
데이터베이스 공통 개념 5편
Database · Transaction
MVCC - 잠그는 대신 버전을 쌓는다
읽기가 쓰기를 막지 않게 만든 대가로 무엇을 떠안게 되는가. 버전 체인, 스냅샷, 그리고 청소 문제.
데이터베이스 공통 개념 4편
Database · Transaction
락과 데드락 - 잠가서 지키는 방식의 대가
공유락·배타락에서 2단계 잠금까지, 그리고 두 트랜잭션이 서로를 영원히 기다리게 되는 과정.
데이터베이스 공통 개념 3편
Database · Transaction
격리 수준 - 같이 읽고 쓰면 무엇이 깨지는가
더티 리드·반복 불가능 읽기·팬텀 리드가 언제 생기는지, 그리고 격리 수준이라는 이름이 왜 믿을 게 못 되는지.
데이터베이스 공통 개념 2편
Database · Transaction
트랜잭션과 ACID - 네 글자의 무게가 다르다
원자성·일관성·격리성·지속성이 각각 무엇을 보장하는지, 그리고 왜 넷 중 하나만 협상 대상인지.
데이터베이스 공통 개념 1편