블로그

#2026-03 762#culture 283#deep-dive 275#kubernetes 262#career 233#ai 223#llm 217#devops 198#2026-04 158#security 149#observability 118#database 113#communication 108#history 107#architecture 101#productivity 98#performance 93#linux 90#networking 89#finance 87#economy 84#mindset 80#psychology 79#ai-papers 78#food 78#it 78#travel 78#japanese 76#deep-learning 75#english 74#gpu 74#ai-agent 69#business-travel 69#postgresql 67#cs-fundamentals 63#rag 63#systems 63#python 56#learning 54#self-improvement 53

• 커넥션 풀 크기, 크게 잡으면 손해인 이유 — 대기열을 어디에 세울 것인가

  커넥션 풀을 키웠더니 오히려 느려지는 현상의 원리를 정리합니다. PostgreSQL의 프로세스 모델에서 커넥션이 왜 비싼지, 디스크와 CPU 병렬성이 유한하므로 대기열을 데이터베이스 안이 아니라 풀에 세우는 편이 나은 이유, 자주 인용되는 코어 수 기반 공식의 근거와 한계를 다룹니다. 마이크로서비스에서 인스턴스 수와 풀 크기의 곱이 최대 커넥션을 넘기는 전형적 사고, PgBouncer 세 가

  2026-07-26 · 26 분 읽기 #database#postgresql#connection-pool#pgbouncer#performance

• 인덱스를 만들었는데 안 타는 이유 — 옵티마이저가 맞고 내가 틀린 경우들

  인덱스를 만들었는데 실행 계획에 Seq Scan이 그대로 남는 이유를 원인별로 정리합니다. 선택도가 낮아서 옵티마이저가 일부러 무시하는 경우, 컬럼에 함수나 연산이 걸려 sargable하지 않은 경우, 타입 불일치로 암묵적 캐스팅이 일어나는 경우, LIKE 선행 와일드카드, OR 조건, 복합 인덱스 선두 컬럼 규칙, 통계 노후화, NULL 처리까지 실제 SQL과 실행 계획으로 확인합니다. 부

  2026-07-26 · 21 분 읽기 #database#postgresql#index#query-optimization#mysql

• 3막 구조는 법칙인가 관습인가 — 이야기 구조론의 계보와 그 한계

  영화들이 대체로 같은 자리에서 꺾이는 것은 우연이 아닙니다. 아리스토텔레스는 3막을 말한 적이 없고, 오늘날의 3막 구조는 시드 필드가 1979년에 페이지 수로 못 박으면서 산업 표준이 된 20세기의 발명품입니다. 표준 비트가 실제로 하는 기능적 일, 블레이크 스나이더의 비트 시트가 헐리우드를 균질하게 만들었다는 비판, 갈등 없이 작동하는 기승전결과 댄 하먼의 스토리 서클 같은 대안, 그리고

  2026-07-26 · 23 분 읽기 #storytelling#screenwriting#narrative#film#craft

• 시크릿 관리, .env 파일만으로는 부족한 이유 — 환경변수가 새는 경로와 로테이션 설계

  .env 파일을 .gitignore에 넣었다고 시크릿이 안전해지지는 않습니다. 프로세스 환경은 같은 호스트에서 /proc/PID/environ으로 그대로 읽히고, 크래시 리포트와 디버그 페이지와 CI 로그에 실려 나가며, 컨테이너 이미지 레이어에 영구히 남습니다. 이 글은 환경변수가 새어 나가는 실제 경로를 하나씩 보여주고, 시크릿이 이미 커밋된 경우의 대응 순서가 왜 히스토리 재작성이 아니

  2026-07-26 · 27 분 읽기 #security#secrets#devops#vault#kubernetes

• 평균 응답 시간이 거짓말하는 이유 — p50, p95, p99를 제대로 읽는 법

  평균 응답 시간이 80ms인 서비스에서 사용자가 3초를 기다리는 일은 흔합니다. 롱테일 분포에서 평균이 무엇을 감추는지, p50과 p95, p99, p99.9가 각각 어떤 질문에 답하는지, 그리고 p99가 왜 "100명 중 1명"이 아닌지를 숫자로 설명합니다. 백분위는 평균낼 수 없다는 결정적 사실과 그래서 히스토그램이 필요한 이유, 프로메테우스 histogramquantile의 선형 보간

  2026-07-26 · 18 분 읽기 #observability#percentile#prometheus#histogram#slo

• HTTP Keep-Alive와 커넥션 재사용 — 간헐적 502를 만드는 타임아웃 경쟁 조건

  백엔드 로그에는 아무 오류가 없는데 로드밸런서에서만 간헐적으로 502가 섞여 나온다면 대부분 커넥션 재사용 경쟁 조건입니다. 서버가 유휴 커넥션을 닫는 바로 그 순간 클라이언트가 그 커넥션에 요청을 쓰면 FIN과 요청이 엇갈립니다. 왜 백엔드 keepalive 타임아웃을 로드밸런서 유휴 타임아웃보다 길게 잡아야 하는지, curl -w로 namelookup과 connect와 appconnect

  2026-07-26 · 26 분 읽기 #network#http#performance#load-balancer#tcp

• 잘 결정하는 법 — 좋은 결정과 좋은 결과는 다릅니다

  슈퍼볼 마지막 패스가 인터셉트되자 모두가 최악의 선택이라고 불렀습니다. 하지만 결과로 결정을 채점하는 습관은 배울 수 있는 것을 거의 다 지워 버립니다. 애니 듀크의 리절팅 개념, 되돌릴 수 있는 문과 없는 문을 나누는 베이조스의 기준, 사전 부검과 10/10/10, 만족화와 극대화의 차이, 그리고 결정 일지까지 정리했습니다. 결정의 품질을 실제로 높이고 나중에 채점할 수 있게 만드는 절차에

  2026-07-26 · 22 분 읽기 #mindset#decision-making#psychology#productivity#self-improvement

• CPU steal time과 스로틀링 — top의 st, 버스터블 크레딧, CFS 쿼터를 가르는 법

  CPU 사용률은 40%인데 p99 지연이 튀고, top의 st 열에는 20%가 찍혀 있습니다. 겉으로 비슷해 보이는 이 증상에는 세 가지 전혀 다른 원인이 있습니다. 하이퍼바이저가 vCPU에 물리 CPU를 주지 않는 steal time, 버스터블 인스턴스의 CPU 크레딧 고갈, 그리고 top에 아예 보이지 않는 cgroup CFS 쿼터 스로틀링입니다. st가 몇 퍼센트부터 문제인지, nrth

  2026-07-26 · 28 분 읽기 #linux#cpu#cgroups#kubernetes#cloud

• 지도는 왜 거짓말을 하는가 — 메르카토르에서 검색 알고리즘까지

  그린란드는 아프리카의 14분의 1 크기지만 교실 벽의 세계지도에서는 비슷해 보입니다. 이것은 실수가 아니라 설계입니다. 구면을 평면에 펴는 일이 수학적으로 불가능하다는 가우스의 증명에서 출발해, 항해용으로 각도를 지키려고 면적을 포기한 1569년 메르카토르 도법, 정치적 항의로 등장했으나 그 자체로 왜곡을 안고 있던 페터스 도법 논쟁, 중심과 위쪽을 어디에 두느냐의 정치, 그리고 정확성이 아

  2026-07-26 · 26 분 읽기 #humanities#history#cartography#geography#power

• 도커 네트워크 모드와 연결 문제 — bridge, host, overlay, 그리고 127.0.0.1의 함정

  컨테이너는 떴는데 접속이 안 되는 상황을 모드별 동작 원리로 풀어냅니다. 기본 bridge에서 컨테이너가 서로를 이름으로 못 찾는 이유와 사용자 정의 네트워크의 내장 DNS, 포트 퍼블리싱이 실제로 만드는 iptables DNAT 규칙, 바인딩 주소를 127.0.0.1로 제한하는 것의 보안 의미를 다룹니다. 컨테이너 안의 루프백이 호스트가 아니라는 점과 host.docker.internal,

  2026-07-26 · 22 분 읽기 #docker#docker-network#iptables#networking#devops

• 데드락 진단과 예방 — 로그에서 두 쿼리를 특정하는 법

  deadlock detected 오류를 만났을 때 무엇을 봐야 하는지 순서대로 정리합니다. PostgreSQL의 데드락 리포트와 MySQL의 SHOW ENGINE INNODB STATUS 출력을 한 줄씩 해석해 어느 두 쿼리가 엮였는지 특정하는 방법, 실무에서 반복되는 세 가지 패턴인 갱신 순서 불일치와 인덱스 부재로 인한 락 범위 확대와 외래 키가 유발하는 부모 행 잠금을 다룹니다. dea

  2026-07-26 · 25 분 읽기 #database#postgresql#deadlock#locking#mysql

• 사이드 프로젝트를 커리어 자산으로 만드는 법 — 완성 기준, 공개 시점, 회고

  대부분의 사이드 프로젝트는 재능이 부족해서가 아니라 완성 기준이 없고, 공개 시점이 없고, 회고가 없어서 죽습니다. 자산이 되는 프로젝트에는 남이 볼 수 있고, 내 판단이 드러나고, 이야기로 말할 수 있다는 세 가지 조건이 있습니다. 스코프를 2주 안에 배포 가능한 크기로 강제하는 법, 면접에서 실제로 물어보는 것이 왜 완성도가 아니라 판단의 흔적인지, 글쓰기와 발표가 코드보다 레버리지가 큰

  2026-07-26 · 21 분 읽기 #career#side-project#portfolio#growth#productivity

• 연봉 협상의 기술 — 이미 같은 편이 된 사람들끼리 조건을 맞추는 일

  오퍼 메일 앞에서 손이 멈추는 이유는 대부분 정보 부족이 아니라 부끄러움입니다. 하지만 오퍼가 나왔다는 것은 회사가 이미 나를 고르기로 했다는 뜻이고, 남은 일은 같은 편이 된 사람들끼리 조건을 맞추는 것뿐입니다. 시장 데이터로 정보 비대칭을 좁히는 법, 첫 숫자의 효과와 그 한계, 목표를 범위의 아래쪽에 두는 제시법, 기본급 말고도 테이블 위에 있는 여덟 가지, 초반의 희망 연봉 질문에 답

  2026-07-26 · 22 분 읽기 #career#negotiation#salary#job-search#communication

• 이직 타이밍을 판단하는 법 — 도망치는 이직과 올라타는 이직을 가르는 질문

  이직해야 할지 고민될 때 필요한 것은 용기가 아니라 판단 기준입니다. 지금 회사의 문제가 사라진다면 남을 것인가라는 한 문장으로 도피형과 성장형을 가르고, 학습 곡선이 평평해진 구간을 신호로 읽고, 짧은 근속의 반복이 실제로 만드는 비용과 그 예외를 따집니다. 이직으로만 연봉이 오르는 구조는 시장 국면에 따라 커졌다 사라지고, 좋은 이유처럼 보이지만 아닌 신호도 분명히 있습니다. 결심한 뒤에

  2026-07-26 · 21 분 읽기 #career#job-change#decision-making#growth#job-search

• 시스템 설계 면접 준비법 — 정답이 아니라 좁혀 가는 과정을 채점받는 45분 ♪ 들을 수 있어요

  시스템 설계 면접에는 정답이 없습니다. 그래서 채점되는 것은 무엇을 그렸는가가 아니라 어떻게 좁혀 갔는가입니다. 45분을 5분·10분·15분·10분·5분으로 쪼개는 시간 예산, 메모리에서 대륙 간 왕복까지 자릿수로 외워 둘 지연 시간 계층, DAU 하나에서 QPS와 스토리지를 뽑는 개략 추정, 그리고 후보를 가장 자주 무너뜨리는 네 가지 습관을 정리했습니다. 마지막으로, 감점이 아니라 가점이

  2026-07-26 · 19 분 읽기 #career#interview#system-design#engineering#job-search

• 1on1을 낭비하지 않는 법 — 상태 보고가 아니라 팀원의 회의로 만들기

  매주 30분씩 1년이면 26시간입니다. 그 시간의 대부분이 슬랙 세 줄로 대체 가능한 상태 보고로 흘러갑니다. 앤디 그로브가 하이 아웃풋 매니지먼트에서 세운 원칙부터 벤 호로위츠의 10퍼센트 규칙, 팀원이 들고 가야 할 네 칸의 의제, 양쪽이 쓸 수 있는 질문 은행, 매니저가 계속 취소할 때의 3단계 대응, 그리고 공유 문서 한 장이 6개월 뒤 평가를 바꾸는 이유까지 정리했습니다. 1on1이

  2026-07-26 · 20 분 읽기 #career#management#one-on-one#feedback#communication

• CORS 에러, 서버를 고쳐야 하는 이유 — 브라우저 정책의 정확한 동작과 잘못된 해법들

  CORS는 서버를 지키는 보안 장치가 아니라 브라우저가 스크립트에게 응답을 읽게 해 줄지 판단하는 정책입니다. 그래서 curl은 되고 브라우저만 막히며, 고칠 곳은 언제나 서버의 응답 헤더입니다. 프리플라이트가 발생하는 정확한 조건, credentials를 쓸 때 와일드카드를 못 쓰는 이유, Vary 헤더가 없어서 CDN 캐시가 오염되는 사고, 브라우저 에러 메시지별 원인 해독표를 정리했습니

  2026-07-26 · 25 분 읽기 #web#cors#http#browser-security#api

• 웹소켓, SSE, 폴링 — 실시간 통신 방식 고르기와 대부분 웹소켓이 필요 없는 이유

  실시간이라는 요구사항 대부분은 서버에서 클라이언트로 가는 단방향 전달이고, 그런 경우 SSE가 웹소켓보다 훨씬 단순하면서 HTTP 인프라를 그대로 씁니다. 자동 재연결과 Last-Event-ID 재개가 규격에 내장되어 있고 인증과 로깅과 압축이 평소 쓰던 것과 같습니다. 폴링과 롱폴링을 포함한 네 방식의 지연과 비용을 표로 비교하고, 웹소켓이 정말 필요한 경계를 정합니다. 프록시 유휴 타임아

  2026-07-26 · 24 분 읽기 #web#websocket#server-sent-events#realtime#scalability

• JWT와 세션, 무엇을 언제 — 상태를 어디에 둘 것인가로 정리하는 인증 선택

  JWT와 세션의 차이는 암호화나 성능이 아니라 인증 상태를 서버에 둘 것인가 클라이언트에 둘 것인가 하나입니다. 이 선택에서 즉시 무효화 불가능이라는 JWT의 근본 약점이 따라 나오고, 짧은 만료와 리프레시 토큰과 블랙리스트라는 대응책이 왜 결국 상태를 다시 불러들이는지가 설명됩니다. 토큰 저장 위치를 두고 벌어지는 localStorage의 XSS 노출과 httpOnly 쿠키의 CSRF 노출

  2026-07-26 · 23 분 읽기 #web#jwt#session#authentication#security

• HTTP 캐싱 제대로 쓰기 — Cache-Control, ETag, stale-while-revalidate의 정확한 의미

  no-cache는 캐시하지 말라는 뜻이 아니라 캐시하되 쓰기 전에 검증하라는 뜻입니다. 이 한 글자 차이를 시작으로 Cache-Control 지시어의 정확한 의미, 조건부 요청과 304가 실제로 절약하는 것과 절약하지 못하는 것, 해시 파일명과 immutable이 프런트엔드 배포의 표준이 된 이유를 정리했습니다. 브라우저와 CDN과 리버스 프록시라는 세 계층이 서로 다른 방식으로만 무효화된다

  2026-07-26 · 20 분 읽기 #web#http-caching#cache-control#cdn#performance