블로그
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 3704 편
#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
회사를 고르는 기준 — 성장하는 곳과 정체된 곳의 신호
회사를 고를 때 대부분의 순서는 뒤집혀 있습니다. 이름값과 보상과 기술 스택을 먼저 보고, 3년 뒤의 자신을 실제로 만드는 문제와 사람을 나중에 봅니다. 성장하는 조직에서 반복 관찰되는 신호와 정체된 조직에서 반복되는 신호를 나누고, 문화가 어떠냐는 추상 질문 대신 사건을 묻는 질문으로 면접에서 정보를 얻는 방법을 정리했습니다. 제품과 조직과 기술 중 무엇을 먼저 봐야 하는지, 역질문 관행이
2026-08-15 · 10 분 읽기 #career#job-search#interview#decision-making#company-culture우리가 실제로 아는 것과 모르는 것 — 커리어 예측을 다루는 법
개발자의 미래에 대한 글은 대부분 두 가지 중 하나입니다. 걱정하지 말라는 위로거나, 지금 준비하지 않으면 도태된다는 경고거나. 둘 다 아무도 뒷받침할 수 없는 예측을 사실처럼 말한다는 점에서 같은 문장입니다. 이 글은 관측된 것과 예측된 것을 갈라놓는 데서 시작합니다. 널리 인용된 2013년 옥스퍼드 연구가 실제로 무엇을 계산했는지, 1964년에도 거의 같은 경고가 있었다는 사실, 그리고
2026-08-15 · 12 분 읽기 #career#ai#uncertainty#forecasting#job-security5년에서 10년차의 정체감 — 성장 곡선이 완만해지는 것은 정상입니다
5년차를 넘기면 성장이 멈춘 것 같은 시기가 옵니다. 이 글은 그 감각을 위로하지 않고 왜 그렇게 느껴지는지 설명합니다. 초년의 성장은 눈금이 있었고 이후의 성장은 눈금이 없다는 점, 평가 기준이 산출물에서 영향으로 조용히 옮겨 간다는 점, 깊이와 넓이의 질문을 세로획 한 문장으로 바꾸는 법, 매니저 트랙 압력을 판단하는 기준, 그리고 이 시기의 진짜 위험이 실력 저하가 아니라 고립이라는 관
2026-08-15 · 11 분 읽기 #career#mid-career#plateau#growth#engineering-manager직업과 자아를 분리하기 — 정체성이 직무에 붙어 있을 때 생기는 일
조직 개편과 팀 해체는 원래 업무상의 사건입니다. 그런데 정체성이 직무에 걸려 있으면 같은 사건이 존재에 대한 사건으로 도착합니다. 이 글은 그 구조를 세 가지 증상으로 분해하고, 이것이 일을 덜 사랑하라는 말이 아니라 지분 구조의 문제임을 짚습니다. 그다음 회사 밖 정체성이 실제로 작동하기 위한 세 가지 조건과 자주 빠지는 조건 하나, 일 안에서도 직함 대신 서술에 정체성을 붙이는 방법,
2026-08-15 · 10 분 읽기 #career#identity#burnout#resilience#self-worthAI 도구와 일하는 법을 하나의 기술로 — 위임 기준과 검증 절차
AI 도구를 잘 쓴다는 말은 무엇을 맡겼고 결과를 어떻게 판정했는지를 빼면 아무것도 뜻하지 않습니다. 이 글은 위임 가능성을 난이도가 아니라 검증 비용으로 가르는 기준, 맡기기 전에 네 줄로 적는 위임 카드, 결과를 받은 뒤 읽는 순서를 바꾸는 검증 절차, 그리고 생산성이 오히려 떨어지는 네 가지 패턴을 다룹니다. 무작위 대조 실험과 대규모 개발자 설문에서 나온 숫자를 인용하되 그 숫자가 무
2026-08-15 · 14 분 읽기 #career#skills#ai#verification#engineering-practice문제를 정의하는 능력 — 잘못된 문제를 완벽히 푸는 실패를 피하는 법
잘못된 문제를 완벽히 푼 결과물은 맞는 문제를 어설프게 푼 결과물보다 대개 더 나쁩니다. 어설픈 답은 부족하다는 신호를 주지만 완벽한 답은 끝났다는 신호를 주기 때문입니다. 이 글은 요구사항을 액면 그대로 받지 않고 되묻는 세 개의 질문, 무엇을 만들지 않을지를 이유와 함께 먼저 적는 비목표 작성법, 여섯 줄짜리 문제 진술서, 그리고 범위를 줄이는 것과 문제를 바꿔치기하는 것을 구별하는 기준
2026-08-15 · 12 분 읽기 #career#skills#problem-framing#requirements#scoping배우는 방법을 배우기 — 기초와 유행을 가르는 기준, 깊게 팔 하나를 고르는 법
학습 전략은 대개 무엇을 배울지의 목록으로 나오지만, 실제로 필요한 것은 무엇을 안 배울지 정하는 기준입니다. 이 글은 기초와 유행을 가르는 한 가지 질문, 도구가 요점인 자리에서 그 도구가 구현한 아이디어를 배우는 규칙, 깊게 팔 하나를 고르는 세 가지 기준, 읽기가 왜 학습이 아닌지, 그리고 학습을 실행 가능한 증거로 남기는 방법을 다룹니다. 인출 연습에 대한 관찰과 그 관찰의 한계도 함
2026-08-15 · 13 분 읽기 #career#skills#learning#fundamentals#deliberate-practice떠날 때와 남을 때 — 이직이 해결하는 문제와 따라오는 문제
이직은 환경이 원인인 문제에는 잘 듣고, 원인이 나에게 있는 문제에는 따라옵니다. 이 구분을 먼저 세우지 않으면 같은 상황을 회사만 바꿔 가며 반복하게 됩니다. 남아 있어야만 쌓이는 복리가 무엇인지, 늘 1년 차만 반복할 때 어떤 능력이 비는지, 떠나기 전에 확인해야 할 다섯 가지는 무엇인지 정리했습니다. 남기로 한 결정과 그냥 미루는 표류를 가르는 기준은 기한과 조건이 붙어 있는지 하나뿐입
2026-08-15 · 10 분 읽기 #career#job-change#decision-making#growth#retention인맥을 급할 때 만들지 않기 — 도움이 오가는 관계는 어떻게 생기는가
직장을 잃은 다음에 주소록을 여는 순서는 대개 늦습니다. 상대가 매정해서가 아니라 몇 년 만의 첫 연락이 부탁일 때 요청의 구조가 무거워지기 때문입니다. 관계가 실제로 만들어지는 자리가 행사가 아니라 함께 일한 흔적인 이유, 겹치지 않는 정보가 왜 먼 관계에서 오는지, 낯선 커뮤니티에 자기소개가 아니라 기여로 들어가는 방법을 정리했습니다. 유지가 안부가 아니라 유용함이어야 하는 이유와, 도움
2026-08-15 · 10 분 읽기 #career#networking#community#relationships#job-search면접을 양방향 평가로 쓰기 — 준비 순서와 설계 라운드
면접은 두 시간 남짓 동안 서로가 서로의 표본을 뽑는 자리입니다. 한쪽 방향으로만 쓰면 정보의 절반을 버리게 됩니다. 준비의 순서가 왜 대체로 뒤집혀 있는지, 시스템 설계 라운드에서 채점되는 것이 정답 구조가 아니라 무엇인지, 면접관이 던지는 질문이 그 조직에 대해 무엇을 말해 주는지 정리했습니다. 떨어진 뒤에 스스로 복기하는 방법과, 단일 탈락을 실력의 측정값으로 읽으면 왜 과적합인지도 다
2026-08-15 · 10 분 읽기 #career#interview#system-design#job-search#feedback무엇으로 알려질 것인가 — 포지셔닝은 실력과 다른 속도로 자란다
실력은 매일 조금씩 늘지만 포지셔닝은 남이 나를 다시 떠올릴 계기가 있을 때만 갱신됩니다. 이 시차가 엔지니어 커리어의 억울함 대부분을 만듭니다. 포지셔닝이 실력과 어떻게 다른지, 범위를 좁히는 일이 왜 기회를 줄이는 대신 늘리는지, 포지셔닝의 재료가 기술 스택이 아니라 문제 유형이어야 하는 이유, 그리고 자기를 한 문장으로 설명하지 못할 때 조용히 새어 나가는 네 가지 비용을 정리했습니다.
2026-08-15 · 10 분 읽기 #career#positioning#career-strategy#growth#personal-brand그래서 월요일에 무엇을 하나 — 90일 안에 통제 가능한 것들
시리즈의 마지막 편입니다. 앞의 아홉 편을 실행 가능한 크기로 접습니다. 지금 나를 누르는 것들을 통제 가능, 영향만 가능, 통제 불가의 세 칸으로 나눈 뒤, 첫 번째 칸에 실제로 들어가는 항목들을 90일 순서로 배치합니다. 한 분기에 두 개만 고르는 규칙, 통제할 수 없는 것을 놓아주는 세 개의 질문, 감당과 포기의 차이, 그리고 이 목록의 어느 항목도 안전을 보장하지 않는다는 정직한 마무
2026-08-15 · 10 분 읽기 #career#anxiety#action-plan#uncertainty#checklist해고가 걱정될 때 실제로 하는 준비 — 감정이 아니라 체크리스트
잘릴지도 모른다는 걱정은 아무것도 바꾸지 않지만, 준비는 통보 이후의 선택지 수를 바꿉니다. 이 글은 감정을 다루는 대신 네 개의 칸으로 된 체크리스트를 제시합니다. 재정 활주로, 평소에 살려 두는 서류, 급할 때 만들지 않는 네트워크, 회사 밖에 남는 증거. 각 칸에서 무엇이 실제 준비이고 무엇이 준비처럼 보이는 일인지 구분하고, 분기에 한 시간이면 끝나는 점검 루틴으로 접습니다. 준비가
2026-08-15 · 10 분 읽기 #career#layoff#job-security#preparation#resume커리어 불안의 절반은 돈 문제입니다 — 활주로 계산과 고정비의 구조
이 일이 몇 년 뒤에도 있을까 하는 걱정의 아래에는 대개 없어지면 몇 달을 버티나가 깔려 있습니다. 미래는 예측할 수 없지만 이 숫자는 오늘 계산할 수 있습니다. 이 글은 활주로 개월 수를 구하는 두 개의 숫자와 그 정의, 분자를 키우는 것과 분모를 줄이는 것의 성질 차이, 고정비가 만드는 선택지, 그리고 활주로가 협상에서 실제로 하는 일을 다룹니다. 투자 이야기는 없습니다. 상품도 수익률도
2026-08-15 · 12 분 읽기 #career#financial-runway#money#negotiation#job-security기술 부채 완전 가이드: 식별하고 측정하고 갚기 ♪ 들을 수 있어요
기술 부채를 설득하기 전 단계, 즉 어디에 있는지 찾아내고 숫자를 붙이는 방법을 다룹니다. Fowler의 사분면으로 은유의 원래 뜻을 정리하고, 부채가 아닌 것을 걸러 내고, 변경 빈도와 복잡도로 핫스팟을 찾고, DORA 지표로 이자를 관측하고, 부채 목록과 상환 계획을 유지하는 절차, 그리고 갚지 않기로 결정하는 방법까지 정리합니다.
2026-08-15 · 43 분 읽기 #기술부채#리팩터링#코드품질#tech-debt#dora설계 문서 완전 가이드: 결정을 남기는 문서와 사라지는 문서 ♪ 들을 수 있어요
설계 문서를 글쓰기 기술이 아니라 팀의 의사결정 인프라로 다룹니다. 1-pager·설계 문서·ADR·RFC 중 무엇을 언제 쓰는지, 리뷰를 어떤 절차로 운영하는지, 내려진 결정이 어떻게 만료되는지, 그리고 문서가 실패하는 여덟 가지 방식을 정리합니다.
2026-08-15 · 42 분 읽기 #설계문서#adr#rfc#design-doc#기술문서테스트 전략 완전 가이드: 피라미드 논쟁 대신 결정 기준 ♪ 들을 수 있어요
테스트 피라미드와 테스팅 트로피 중 무엇이 맞는지 고르는 대신, 그 논쟁을 실제 축으로 분해해 팀이 자기 비율을 스스로 정하는 방법을 정리합니다. 단위의 정의, 비용 함수, 목 사용 범위, 커버리지 숫자, 결함 분포 데이터, 느리고 깨지는 테스트의 운영 규칙까지 결정 기준 중심으로 다룹니다.
2026-08-15 · 42 분 읽기 #테스트#아키텍처#testing#test-pyramid#coverage에러 처리 완전 가이드: 실패를 계약으로 설계하기 ♪ 들을 수 있어요
에러 처리를 예외 문법이 아니라 인터페이스 계약의 일부로 다룹니다. 오류를 분류하는 두 축, 예외와 반환값 논쟁의 실제 축, 경계마다 오류를 번역하는 규칙, RFC 9457 기반 HTTP 오류 계약, 멱등성 없는 재시도의 위험, 타임아웃 예산, 관측, 그리고 사용자에게 무엇을 말할 것인지까지 정리합니다.
2026-08-15 · 43 분 읽기 #에러처리#재시도#rfc9457#타임아웃#관측가능성코드 리뷰 완전 가이드: 리뷰를 프로세스로 설계하기 ♪ 들을 수 있어요
코드 리뷰를 대화가 아니라 처리량·지연 시간·소유권을 가진 시스템으로 봅니다. 승인 기준의 문서화, 변경 크기, 1영업일 응답 규칙, 사람과 자동화의 분담, 소유권과 승인 규칙, 코멘트 등급, 교착 시 에스컬레이션, 그리고 리뷰 지표가 오용되는 방식까지 운영 관점에서 정리합니다.
2026-08-15 · 40 분 읽기 #코드리뷰#개발문화#code-review#process#automation동시성 완전 가이드: 공유 상태를 줄여 나가는 순서 ♪ 들을 수 있어요
애플리케이션 설계자가 동시성 문제를 다룰 때 밟는 작업 순서를 정리합니다. 공유 상태를 없앨 수 있는지부터 확인하고, 없앨 수 없으면 범위를 좁히고, 남은 것에 원자성 경계와 잠금을 씌우고, 프로세스 밖으로 나가면 트랜잭션과 멱등성으로 지키고, 마지막에 테스트로 확인합니다. 개념 구분이나 인프라 비교가 아니라 코드를 쓰는 사람의 결정 순서에 초점을 둡니다.
2026-08-15 · 45 분 읽기 #동시성#아키텍처#concurrency#locking#backpressure