Skip to content

Engineering

  • Published on
    설계 문서, RFC, 제안서, 장애 후속 권고를 쓰는 사람을 위한 글입니다. 자신이 문제를 푼 순서가 아니라 원하는 결정을 맨 앞에 두는 법, 기각한 대안을 드러내는 것이 왜 제안과 광고를 가르는 유일한 표지인지, 아무것도 하지 않을 때의 비용을 어떻게 숫자로 만드는지, 훑어 읽는 결정자를 어떻게 상대하는지를 정리했습니다. 그리고 가장 중요한 것, 내가 없는 회의에서 인용될 문단을 어떻게 쓰는지를 다룹니다. 약한 제안 문단 하나를 실제로 다시 쓰고 문서에서 작동하는 수를 표로 모았습니다.
  • Published on
    2026년 상반기에 공개된 대규모 LLM 마이그레이션 사례들(53만 줄 Zig to Rust, 16만 5천 줄 Python to TypeScript)에서 공통된 절차를 뽑아 실행 가능한 순서로 정리합니다. 핵심은 순서입니다 — 번역을 시작하기 전에 동작 오라클을 세우고, 일부러 망가뜨린 코드로 그 오라클이 떨어지는지부터 확인합니다. 그다음 검증 가능한 경계로 잘라 큐를 만들고, 완료 판정을 디스크 상태에 맡겨 모든 단계를 되돌릴 수 있게 유지합니다. 측정 지표는 변환한 줄 수가 아니라 사람이 실제로 읽은 디프 비율과 규칙 위반 재발률입니다. 조용한 의미 변형, 환각 API, 엉뚱한 이유로 통과하는 테스트라는 세 가지 실패 모드와 그 탐지법도 함께 다룹니다.
  • Published on
    2026년 7월 30일 martinfowler.com에 올라온 The Economic Benefit of Refactoring은 1만 7천 줄짜리 모듈을 15단계에 걸쳐 리팩터링하면서, 같은 변경 요청을 매번 다시 돌려 입력 토큰이 159,564개에서 27,360개로 83퍼센트 줄어드는 것을 측정했습니다. 흥미로운 실험이지만 저자 스스로 단일 실험이자 그린필드 앱 하나라고 못 박습니다. 이 글은 그 실험과 기존 증거(Tornhill과 Borg의 39개 코드베이스 연구, 그리고 리팩터링이 오히려 결함을 유발한다는 반대 방향 연구들)를 나란히 놓고, 변경 빈도 곱하기 결함 비용 대 리팩터 비용이라는 회수 기간 계산식과 git 한 줄로 그 입력값을 뽑는 방법을 정리합니다.
  • Published on
    코드 리뷰에는 결함 발견, 지식 전파, 코드 소유권 공유라는 세 가지 목적이 있지만 대부분의 팀은 첫 번째만 하고 나머지 둘을 놓칩니다. 리뷰어는 완벽을 요구하는 사람이 아니라 코드가 명확히 나아졌는지 판단하는 사람이라는 구글의 승인 기준, 강도 표시 접두어가 만드는 차이, 관찰과 영향과 제안으로 나눈 문장 구조, 200에서 400줄이라는 PR 크기 통념의 출처와 그 한계, 왕복을 줄이는 PR 설명, 리뷰를 받는 쪽의 기술까지 정리했습니다. 리뷰가 기술이 아니라 권력 게임이 될 때의 신호도 함께 다룹니다.
  • Published on
    시스템 설계 면접에는 정답이 없습니다. 그래서 채점되는 것은 무엇을 그렸는가가 아니라 어떻게 좁혀 갔는가입니다. 45분을 5분·10분·15분·10분·5분으로 쪼개는 시간 예산, 메모리에서 대륙 간 왕복까지 자릿수로 외워 둘 지연 시간 계층, DAU 하나에서 QPS와 스토리지를 뽑는 개략 추정, 그리고 후보를 가장 자주 무너뜨리는 네 가지 습관을 정리했습니다. 마지막으로, 감점이 아니라 가점이 되는 방식으로 모른다고 말하는 법까지 다룹니다.
  • Published on
    Anthropic의 엔지니어링 가이드 "Building Effective Agents"를 실무 레퍼런스로 정리했습니다. 워크플로와 에이전트의 정확한 구분, 모든 것의 기본 블록인 증강된 LLM(검색·도구·메모리), 다섯 가지 워크플로 패턴(프롬프트 체이닝·라우팅·병렬화·오케스트레이터-워커·이밸류에이터-옵티마이저)을 각각 언제 쓰는지와 예시로 다룹니다. 자율 에이전트가 실제로 무엇인지, 언제 워크플로 대신 에이전트를 꺼내야 하는지, 그리고 과설계·무한 루프·비용/지연 같은 실패 모드까지 솔직하게 적었습니다. 개발자와 AI 에이전트가 두고두고 인용할 수 있는 지도를 목표로 했습니다.
  • Published on
    버그를 노려보며 코드를 이리저리 바꾸는 대신, 과학자처럼 가설을 세우고 예측을 하고 실험으로 검증하는 방법. 문제 공간을 이분 탐색으로 좁히고, 최소 재현 예제를 만들고, git bisect로 범인 커밋을 찾고, 에러 메시지를 실제로 읽는 법까지. 추측을 방법론으로 바꾸는 실전 디버깅 가이드.
  • Published on
    팔란티어가 대중화하고 이제 OpenAI·Anthropic 같은 AI 회사의 솔루션 조직에서 다시 뜨거워진 포워드 배포 엔지니어(FDE) 역할을 정리합니다. 고객에게 파견되어 소프트웨어 엔지니어링·프로덕트·솔루션·약간의 세일즈와 컨설팅을 섞어 고객의 진짜 문제를 끝까지 해결하는 사람. SWE·SE·PM·컨설턴트와 무엇이 다른지, 그리고 왜 AI가 FDE를 다시 필요하게 만들었는지 살펴봅니다.
  • Published on
    개발자는 코드를 쓰는 시간보다 읽는 시간이 훨씬 많습니다. 그런데 코드 읽기는 아무도 가르쳐 주지 않습니다. 진입점을 찾고, 모든 줄이 아니라 데이터를 따라가고, 테스트와 타입을 문서로 삼고, grep과 IDE 점프로 콜 그래프를 그리고, 직접 돌려 보며 print를 찍고, 뭔가를 바꿔 무엇이 깨지는지 관찰하는 법. 낯선 코드베이스를 빠르게 장악하는 실전 전략.
  • Published on
    포워드 배포 엔지니어(FDE)가 며칠 만에 고객의 실제 데이터 위에서 돌아가는 데모를 만들어 판을 뒤집는 방법. 의도적으로 버릴 기술 부채, 위험을 걷어내는 스파이크, 언제 하드코딩할지, 아하 모먼트까지 최단으로 가는 법, 기대치 관리, 그리고 프로토타입에서 프로덕션으로 넘어가는 이주까지. 현장에서 검증된 FDE 프로토타이핑 플레이북을 정리합니다.
  • Published on
    "컴퓨터 과학에서 어려운 것은 두 가지, 캐시 무효화와 이름 짓기뿐"이라는 농담에는 진심이 담겨 있습니다. 좋은 이름이 왜 구현이 아니라 의도를 드러내야 하는지, 이름 길이와 스코프의 관계, 헝가리안 표기법을 피해야 하는 이유, 검색 가능성, 불리언·함수·컬렉션 관례, 그리고 이름 바꾸기를 하나의 리팩터링으로 다루는 법까지 정리합니다.
  • Published on
    좋은 아이디어가 채택되지 않는 이유는 대개 아이디어가 나빠서가 아니라 전달이 나빠서입니다. 이 글은 설계 문서와 RFC로 제안하는 법, 해답이 아니라 문제로 먼저 설득하는 법, 경영진과 동료 엔지니어에게 메시지를 다르게 맞추는 법, 논쟁에서 진 뒤에 나아가는 "동의하지 않지만 따른다", 비동기와 동기 커뮤니케이션의 선택, 모든 결정의 비용을 명시하는 법, 그리고 "강한 의견, 느슨하게 쥐기"가 나쁜 태도의 핑계로 변질되는 함정을 다룹니다.
  • Published on
    코드 리뷰는 결함을 잡는 기술 활동인 동시에, 사람과 사람 사이의 대화입니다. 사람이 아니라 코드를 리뷰하는 프레이밍, nit과 blocker를 구분하는 컨벤셔널 코멘트, 명령 대신 질문하기, 작은 PR이 진짜 리뷰를 받는 이유, 잘한 코드를 칭찬하기, 작성자로서 피드백을 우아하게 받는 법, 그리고 리뷰어와 작성자가 나눠 지는 양방향 책임까지 다룹니다.
  • Published on
    재시도와 백오프, 타임아웃, 하트비트, 일관성 모델, 백프레셔, 우아한 성능 저하, 멱등성, 두 장군 문제, TTL이 붙은 캐시로서의 신뢰. 분산 시스템을 어렵게 만드는 문제들은 사람과 가까워지는 일을 어렵게 만드는 문제와 놀랍도록 똑같습니다. 엔지니어의 눈으로 연애를 다시 읽어 봅니다.
  • Published on
    포워드 배포 엔지니어(FDE)와 프로덕트 사이의 피드백 루프. N명의 고객에게서 같은 패턴을 발견하고, 설정과 추상화로 뽑아내고, 삼진 규칙으로 언제 일반화하지 말아야 할지 판단하기. 한 고객을 위해 빨리 만드는 것과 모두를 위해 짓는 것 사이의 긴장, 그리고 훌륭한 제품이 어떻게 전방 배치 작업에서 태어나는지 이야기합니다.
  • Published on
    스토아주의의 통제 이분법, 실용주의의 작동하는 진리, 본질주의와 장인정신을 엔지니어의 일상에 적용하는 법을 다룹니다. 추상적 훈계가 아니라 코드 리뷰, 장애 대응, 커리어 결정 같은 구체적 상황에서 어떻게 쓰는지, 그리고 과한 자기계발의 함정을 어떻게 피하는지 살펴봅니다.
  • Published on
    지구상에서 가장 많이 배포된 데이터베이스는 오라클도, 포스트그레스도 아닌 SQLite입니다. 여러분의 폰, 브라우저, 심지어 비행기 안에도 있습니다. 서버 없는 단일 파일 설계, 클라이언트-서버 DB를 이길 때, WAL 모드, 인메모리 DB로 테스트하기, WASM으로 브라우저에서 돌리기, litestream으로 내구성 확보까지 정리합니다.
  • Published on
    Larry Ellison의 상시 녹화 발언, 시애틀 감시 인프라 도보 투어, 연령 인증 의무화까지 — 2026년의 감시 논쟁은 결국 그 시스템을 만드는 개발자의 손 위에서 벌어집니다. 감시 기술의 스펙트럼, 개발자가 마주치는 윤리적 순간들, 데이터 최소화와 보존 기한 자동화 같은 프라이버시 엔지니어링 실무, 그리고 조직 안에서 거절하는 기술까지 정리합니다.
  • Published on
    스타트업 현실의 엔지니어링. 0→1 vs 1→10 vs 10→100, PMF 전/후, 기술 부채의 전략적 활용, Next.js/Supabase/Vercel 기본 스택, 창업 18개월·피봇, Founding Engineer vs Early Employee, YC·Series A/B 스케일 고통, EM 전환 타이밍까지 — 2025년 스타트업에서 엔지니어로 이기는 법.