태그: #engineering
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 23 편
#engineering 태그가 붙은 글은 23편이고, 가장 최근 글은 2026-08-02에 올라왔습니다.
함께 자주 붙은 태그: #career 7 #ai 4 #culture 4 #fde 3 #fundamentals 3
최근 90일 동안 많이 읽힌 글:
글로 설득하기 — 디자인 문서와 RFC가 통과되는 구조
설계 문서, RFC, 제안서, 장애 후속 권고를 쓰는 사람을 위한 글입니다. 자신이 문제를 푼 순서가 아니라 원하는 결정을 맨 앞에 두는 법, 기각한 대안을 드러내는 것이 왜 제안과 광고를 가르는 유일한 표지인지, 아무것도 하지 않을 때의 비용을 어떻게 숫자로 만드는지, 훑어 읽는 결정자를 어떻게 상대하는지를 정리했습니다. 그리고 가장 중요한 것, 내가 없는 회의에서 인용될 문단을 어떻게 쓰
2026-08-02 · 25 분 읽기 #career#writing#persuasion#design-doc#engineering리팩터링의 경제학, 언제 비용이 회수되나 — 변경 빈도로 계산하는 법
2026년 7월 30일 martinfowler.com에 올라온 The Economic Benefit of Refactoring은 1만 7천 줄짜리 모듈을 15단계에 걸쳐 리팩터링하면서, 같은 변경 요청을 매번 다시 돌려 입력 토큰이 159,564개에서 27,360개로 83퍼센트 줄어드는 것을 측정했습니다. 흥미로운 실험이지만 저자 스스로 단일 실험이자 그린필드 앱 하나라고 못 박습니다. 이
2026-07-31 · 27 분 읽기 #refactoring#engineering#technical-debt#ai#metricsAI로 코드베이스를 옮기는 실전 절차 — 심판을 먼저 세우고, 줄 수가 아니라 리뷰율을 측정한다
2026년 상반기에 공개된 대규모 LLM 마이그레이션 사례들(53만 줄 Zig to Rust, 16만 5천 줄 Python to TypeScript)에서 공통된 절차를 뽑아 실행 가능한 순서로 정리합니다. 핵심은 순서입니다 — 번역을 시작하기 전에 동작 오라클을 세우고, 일부러 망가뜨린 코드로 그 오라클이 떨어지는지부터 확인합니다. 그다음 검증 가능한 경계로 잘라 큐를 만들고, 완료 판정을
2026-07-31 · 23 분 읽기 #ai#migration#refactoring#testing#engineering시스템 설계 면접 준비법 — 정답이 아니라 좁혀 가는 과정을 채점받는 45분 ♪ 들을 수 있어요
시스템 설계 면접에는 정답이 없습니다. 그래서 채점되는 것은 무엇을 그렸는가가 아니라 어떻게 좁혀 갔는가입니다. 45분을 5분·10분·15분·10분·5분으로 쪼개는 시간 예산, 메모리에서 대륙 간 왕복까지 자릿수로 외워 둘 지연 시간 계층, DAU 하나에서 QPS와 스토리지를 뽑는 개략 추정, 그리고 후보를 가장 자주 무너뜨리는 네 가지 습관을 정리했습니다. 마지막으로, 감점이 아니라 가점이
2026-07-26 · 19 분 읽기 #career#interview#system-design#engineering#job-search가르치는 코드 리뷰, 상처 주는 코드 리뷰 — 같은 지적을 다르게 만드는 것들
코드 리뷰에는 결함 발견, 지식 전파, 코드 소유권 공유라는 세 가지 목적이 있지만 대부분의 팀은 첫 번째만 하고 나머지 둘을 놓칩니다. 리뷰어는 완벽을 요구하는 사람이 아니라 코드가 명확히 나아졌는지 판단하는 사람이라는 구글의 승인 기준, 강도 표시 접두어가 만드는 차이, 관찰과 영향과 제안으로 나눈 문장 구조, 200에서 400줄이라는 PR 크기 통념의 출처와 그 한계, 왕복을 줄이는 P
2026-07-26 · 20 분 읽기 #career#code-review#engineering#feedback#teamwork효과적인 AI 에이전트 만들기 — 워크플로 다섯 패턴과 에이전트 레퍼런스
Anthropic의 엔지니어링 가이드 "Building Effective Agents"를 실무 레퍼런스로 정리했습니다. 워크플로와 에이전트의 정확한 구분, 모든 것의 기본 블록인 증강된 LLM(검색·도구·메모리), 다섯 가지 워크플로 패턴(프롬프트 체이닝·라우팅·병렬화·오케스트레이터-워커·이밸류에이터-옵티마이저)을 각각 언제 쓰는지와 예시로 다룹니다. 자율 에이전트가 실제로 무엇인지, 언제
2026-07-11 · 17 분 읽기 #ai#agents#llm#engineering#anthropic과학자처럼 디버깅하기: 가설 기반 디버깅
버그를 노려보며 코드를 이리저리 바꾸는 대신, 과학자처럼 가설을 세우고 예측을 하고 실험으로 검증하는 방법. 문제 공간을 이분 탐색으로 좁히고, 최소 재현 예제를 만들고, git bisect로 범인 커밋을 찾고, 에러 메시지를 실제로 읽는 법까지. 추측을 방법론으로 바꾸는 실전 디버깅 가이드.
2026-07-03 · 25 분 읽기 #debugging#engineering#productivity#fundamentals포워드 배포 엔지니어(FDE)란 무엇인가
팔란티어가 대중화하고 이제 OpenAI·Anthropic 같은 AI 회사의 솔루션 조직에서 다시 뜨거워진 포워드 배포 엔지니어(FDE) 역할을 정리합니다. 고객에게 파견되어 소프트웨어 엔지니어링·프로덕트·솔루션·약간의 세일즈와 컨설팅을 섞어 고객의 진짜 문제를 끝까지 해결하는 사람. SWE·SE·PM·컨설턴트와 무엇이 다른지, 그리고 왜 AI가 FDE를 다시 필요하게 만들었는지 살펴봅니다.
2026-07-02 · 14 분 읽기 #career#engineering#fde남이 쓴 코드 읽는 법
개발자는 코드를 쓰는 시간보다 읽는 시간이 훨씬 많습니다. 그런데 코드 읽기는 아무도 가르쳐 주지 않습니다. 진입점을 찾고, 모든 줄이 아니라 데이터를 따라가고, 테스트와 타입을 문서로 삼고, grep과 IDE 점프로 콜 그래프를 그리고, 직접 돌려 보며 print를 찍고, 뭔가를 바꿔 무엇이 깨지는지 관찰하는 법. 낯선 코드베이스를 빠르게 장악하는 실전 전략.
2026-07-01 · 22 분 읽기 #code-reading#engineering#onboarding#fundamentals코드에서 이름 짓기: 가장 어려운 쉬운 일
"컴퓨터 과학에서 어려운 것은 두 가지, 캐시 무효화와 이름 짓기뿐"이라는 농담에는 진심이 담겨 있습니다. 좋은 이름이 왜 구현이 아니라 의도를 드러내야 하는지, 이름 길이와 스코프의 관계, 헝가리안 표기법을 피해야 하는 이유, 검색 가능성, 불리언·함수·컬렉션 관례, 그리고 이름 바꾸기를 하나의 리팩터링으로 다루는 법까지 정리합니다.
2026-06-30 · 16 분 읽기 #clean-code#engineering#fundamentalsFDE 플레이북: 버리는 프로토타입으로 이기기
포워드 배포 엔지니어(FDE)가 며칠 만에 고객의 실제 데이터 위에서 돌아가는 데모를 만들어 판을 뒤집는 방법. 의도적으로 버릴 기술 부채, 위험을 걷어내는 스파이크, 언제 하드코딩할지, 아하 모먼트까지 최단으로 가는 법, 기대치 관리, 그리고 프로토타입에서 프로덕션으로 넘어가는 이주까지. 현장에서 검증된 FDE 프로토타이핑 플레이북을 정리합니다.
2026-06-30 · 16 분 읽기 #engineering#prototyping#fde엔지니어를 위한 대화법: 기술 결정을 설득하는 법
좋은 아이디어가 채택되지 않는 이유는 대개 아이디어가 나빠서가 아니라 전달이 나빠서입니다. 이 글은 설계 문서와 RFC로 제안하는 법, 해답이 아니라 문제로 먼저 설득하는 법, 경영진과 동료 엔지니어에게 메시지를 다르게 맞추는 법, 논쟁에서 진 뒤에 나아가는 "동의하지 않지만 따른다", 비동기와 동기 커뮤니케이션의 선택, 모든 결정의 비용을 명시하는 법, 그리고 "강한 의견, 느슨하게 쥐기"
2026-06-27 · 26 분 읽기 #career#communication#engineering코드 리뷰의 대화법: 갈등 없이 피드백 주고받기
코드 리뷰는 결함을 잡는 기술 활동인 동시에, 사람과 사람 사이의 대화입니다. 사람이 아니라 코드를 리뷰하는 프레이밍, nit과 blocker를 구분하는 컨벤셔널 코멘트, 명령 대신 질문하기, 작은 PR이 진짜 리뷰를 받는 이유, 잘한 코드를 칭찬하기, 작성자로서 피드백을 우아하게 받는 법, 그리고 리뷰어와 작성자가 나눠 지는 양방향 책임까지 다룹니다.
2026-06-26 · 29 분 읽기 #code-review#communication#engineering이해의 기쁨 — LLM 시대에도 깊이 이해해야 하는 이유 ♪ 들을 수 있어요
검색과 LLM은 빠른 답을 주지만, 깊은 이해는 통제와 소유권을 줍니다. 추상화 너머를 보는 것의 가치, 도구에 끌려가지 않는 태도, 디버깅과 장애에서 드러나는 이해의 차이, 학습으로서의 이해, 그리고 언제 추상화에 기대도 되는지의 균형을 정리합니다.
2026-06-25 · 46 분 읽기 #culture#learning#craftsmanship#understanding#engineering기술적 과욕과 스코프 — 카맥의 회고에서 배우는 것 ♪ 들을 수 있어요
존 카맥이 공개한 Quake 개발 회고를 단서로, 초기 게임 개발의 기술적 야심과 조직 운영 문제를 일반적 교훈으로 풀어냅니다. 안정적 기반을 택하는 가치, 스코프 관리와 기술부채, 야심과 현실의 균형, 작은 팀의 의사결정을 정리합니다.
2026-06-25 · 49 분 읽기 #culture#engineering#scope#technical-debt#team분산 시스템이 알려준 연애의 기술
재시도와 백오프, 타임아웃, 하트비트, 일관성 모델, 백프레셔, 우아한 성능 저하, 멱등성, 두 장군 문제, TTL이 붙은 캐시로서의 신뢰. 분산 시스템을 어렵게 만드는 문제들은 사람과 가까워지는 일을 어렵게 만드는 문제와 놀랍도록 똑같습니다. 엔지니어의 눈으로 연애를 다시 읽어 봅니다.
2026-06-25 · 25 분 읽기 #engineering#relationships#fun#distributed-systems맞춤형에서 플랫폼으로: FDE 작업을 제품화하기
포워드 배포 엔지니어(FDE)와 프로덕트 사이의 피드백 루프. N명의 고객에게서 같은 패턴을 발견하고, 설정과 추상화로 뽑아내고, 삼진 규칙으로 언제 일반화하지 말아야 할지 판단하기. 한 고객을 위해 빨리 만드는 것과 모두를 위해 짓는 것 사이의 긴장, 그리고 훌륭한 제품이 어떻게 전방 배치 작업에서 태어나는지 이야기합니다.
2026-06-24 · 15 분 읽기 #product#engineering#fde초심을 잃지 않기 — 편함의 유혹을 이기는 법 ♪ 들을 수 있어요
초심은 거창한 다짐이 아니라 매일 흐려지는 무엇입니다. 편함의 유혹과 단기적 달콤함이 어떻게 부메랑이 되는지, 그리고 주어진 기간에 미션을 완수하는 사람으로 남기 위한 장치를 정리합니다.
2026-06-19 · 60 분 읽기 #beginners-mind#discipline#engineering#habits#culture엔지니어를 위한 철학 — 스토아주의와 실용주의를 일에 적용하기 ♪ 들을 수 있어요
스토아주의의 통제 이분법, 실용주의의 작동하는 진리, 본질주의와 장인정신을 엔지니어의 일상에 적용하는 법을 다룹니다. 추상적 훈계가 아니라 코드 리뷰, 장애 대응, 커리어 결정 같은 구체적 상황에서 어떻게 쓰는지, 그리고 과한 자기계발의 함정을 어떻게 피하는지 살펴봅니다.
2026-06-16 · 45 분 읽기 #philosophy#stoicism#pragmatism#engineering#mindsetSQLite는 어디에나 있다
지구상에서 가장 많이 배포된 데이터베이스는 오라클도, 포스트그레스도 아닌 SQLite입니다. 여러분의 폰, 브라우저, 심지어 비행기 안에도 있습니다. 서버 없는 단일 파일 설계, 클라이언트-서버 DB를 이길 때, WAL 모드, 인메모리 DB로 테스트하기, WASM으로 브라우저에서 돌리기, litestream으로 내구성 확보까지 정리합니다.
2026-06-15 · 23 분 읽기 #databases#sqlite#engineering