태그: #career
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 233 편
하네스 엔지니어로 성장하기 — 왜 생긴 직무이고 무엇을 연습해야 하나
하네스 엔지니어라는 직함은 채용 공고에 드물지만, 그 일은 에이전트를 배포하는 모든 팀에 이미 있습니다. 하네스 엔지니어링 시리즈 마지막 8편에서 이 직무가 왜 생겼는지, 기존 소프트웨어 역량이 어떻게 재배치되는지, 그리고 관측과 지문부터 자기 개선 루프까지 여섯 개의 근육을 하네스 RPG의 6개 티어로 단계별 연습하는 경로를 정리했습니다.
2026-08-12 · 9 분 읽기 #llm#agent#harness-engineering#하네스엔지니어링#AI에이전트개발자 이직 후기와 연봉 협상 글 여덟 편 — 성공담이 아니라 절차를 적은 글만 골랐습니다
이직 후기는 많지만 대부분 결과만 남습니다. 이 글은 과정을 순서대로 적은 한국어 글 여덟 편을 모았습니다. 이직 전체 과정을 기록한 후기 세 편, 연봉 협상의 근거를 다룬 글 한 편, 이력서와 경력기술서 작성법 세 편, 그리고 합격 여부와 무관하게 면접을 복기한 글 한 편입니다. 링크는 모두 직접 열어 확인했으며 각 글이 어느 단계를 다루는지와 누가 읽으면 좋은지를 정리했습니다.
2026-08-12 · 17 분 읽기 #큐레이션#korean-blogs#career#job-change#salary-negotiation엔지니어를 위한 한국어 돈 글 아홉 편 — 상품을 파는 글을 걷어내니 계산 구조만 남았습니다
연말정산, 4대보험, 스톡옵션 과세, 퇴직금, 프리랜서 종합소득세. 개발자가 한 번쯤 검색하지만 검색 결과의 대부분이 환급 앱과 금융 상품 광고로 채워지는 주제들입니다. 상품을 파는 글을 전부 제외하고 계산이 왜 그렇게 되는지를 설명하는 글만 남긴 결과, 아홉 편이 남았고 그중 여섯 편이 공식 안내였습니다. 링크는 모두 직접 열어 확인했으며 각 항목마다 어떤 계산 구조를 설명하는지, 누가 읽
2026-08-12 · 20 분 읽기 #큐레이션#korean-blogs#money#tax#payroll국내 개발 블로그 명글 큐레이션 5 — 커리어와 성장, 직접 열어 확인한 14편
개발자 커리어와 성장을 다룬 한국어 글 중에서 구체적이고 재현 가능한 14편을 골랐습니다. 이력서를 공개하며 원칙을 밝힌 글 두 편과 이력서를 서사로 보는 관점, AI 시대에 성장이 멈추는 구조와 일하는 방식의 변화, 무엇을 써야 하는가에 대한 답, 단점과 약점을 가르는 언어, 번아웃을 겪고 나온 기록, 프로그래머의 수명, 완벽주의를 내려놓은 이야기, 초보 팀장의 1년 회고, 조직의 지속성을
2026-08-12 · 23 분 읽기 #curation#큐레이션#career#growth#resumePoC는 왜 프로덕션에 못 가는가 — 성공 기준, 보안 검토, 인수인계
데모에서 박수를 받은 PoC의 상당수는 그대로 죽습니다. 기술이 부족해서가 아니라 성공 기준이 없어서, 보안 검토를 마지막에 시작해서, 챔피언이 없어서, PoC 환경과 프로덕션 환경의 격차를 늦게 발견해서입니다. Forward Deployed Engineer(FDE)의 일에서 PoC를 프로덕션으로 옮기는 구간은 기술보다 운영 설계가 승부처입니다. 시작 전에 합의하는 성공 기준 문서, 첫 주에
2026-08-12 · 11 분 읽기 #career#fde#forward-deployed-engineer#poc#productionFDE 인터뷰 준비 — 진단 시나리오, 고객 시뮬레이션, 케이스 스터디
Forward Deployed Engineer(FDE) 인터뷰는 알고리즘 문제 대신 낯선 시스템의 장애 진단 시나리오를, 컬처핏 질문 대신 화난 고객 역할극을 내놓는 경우가 많습니다. 측정하려는 것이 코드가 아니라 현장에서의 판단이기 때문입니다. 회사마다 형식은 다르다는 전제 위에서, 공개 채용 공고들이 공통으로 요구하는 능력을 기술 진단 라운드, 고객 시뮬레이션 라운드, 케이스 스터디의 세
2026-08-12 · 11 분 읽기 #career#fde#forward-deployed-engineer#interview#job-searchFDE 온보딩 90일 — 파악, 단독 티켓, 주도 미션의 세 달
Forward Deployed Engineer(FDE)의 온보딩은 회사와 고객사, 두 겹의 낯선 환경에 동시에 적응하는 일이라서 일반 엔지니어의 온보딩보다 설계가 더 필요합니다. 1개월 차에는 환경·제품·사람의 지도를 그리고, 2개월 차에는 단독 티켓으로 신뢰 계좌를 만들고, 3개월 차에는 작은 미션 하나를 주도합니다. 주차별 체크리스트와 각 달의 함정, 그리고 90일이 끝났을 때 스스로를
2026-08-12 · 9 분 읽기 #career#fde#forward-deployed-engineer#onboarding#checklist백엔드·데브옵스·데이터 엔지니어에서 FDE로 — 6개월 전환 로드맵
Forward Deployed Engineer(FDE)로의 전환을 고민하는 사람의 대부분은 백엔드, 데브옵스·SRE, 데이터 엔지니어 중 하나에서 출발합니다. 좋은 소식은 어느 배경이든 FDE 기술 지도의 절반은 이미 갖고 있다는 것이고, 나쁜 소식은 나머지 절반이 배경마다 다르다는 것입니다. 세 배경 각각에 대해 이미 가진 것과 채워야 할 것을 가르고, 공통으로 필요한 고객 대면 기술을 짚
2026-08-12 · 10 분 읽기 #career#fde#forward-deployed-engineer#career-transition#roadmapFDE(Forward Deployed Engineer)란 무엇인가 — 고객사 현장에 배치되는 엔지니어
팔란티어가 만들었고 OpenAI와 앤트로픽이 앞다투어 뽑는 직함, 포워드 디플로이드 엔지니어(FDE)를 한국어로 제대로 정리합니다. 본사가 아니라 고객사 현장에 배치되어 제품과 고객 시스템 사이의 마지막 구간을 코드로 잇는 직무가 무엇인지, 솔루션스 아키텍트·세일즈 엔지니어·컨설턴트·서포트 엔지니어와 어떻게 다른지 표로 가르고, 미완성 플랫폼일수록 현장 엔지니어링이 제품의 일부가 된다는 구조
2026-08-12 · 12 분 읽기 #career#fde#forward-deployed-engineer#ai#job-searchFDE 장애 진단 플레이북 — 접속 권한부터 보고서까지 6단계
자기 서비스의 장애와 고객사 장애의 결정적 차이는 아는 것이 없는 상태에서 시작한다는 점입니다. 그래서 Forward Deployed Engineer(FDE)에게는 실력보다 순서가 먼저 필요합니다. 접속과 권한 확인, 증상 재현, 계층 분리, 원인 가설, 검증, 보고서의 6단계를 결제 API 간헐 504라는 구성한 예시 하나로 관통하며, 각 단계에서 실제로 치는 kubectl, curl, g
2026-08-12 · 11 분 읽기 #career#fde#forward-deployed-engineer#incident-response#debugging"느려요"를 엔지니어링 문제로 옮기는 법 — FDE 고객 커뮤니케이션
고객은 버그 리포트를 주지 않습니다. "느려요", "안 돼요", "가끔 이상해요" 같은 고통 리포트를 줍니다. Forward Deployed Engineer(FDE)의 핵심 기술 하나는 이 말을 측정 가능한 엔지니어링 문제로 번역하는 질문법입니다. 언제부터, 누가, 무엇을 할 때, 얼마나, 무엇과 비교해서의 다섯 축으로 증상을 좁히는 법, 같은 상황에서 신뢰를 깎는 답변과 쌓는 답변의 대비,
2026-08-12 · 10 분 읽기 #career#fde#forward-deployed-engineer#communication#customer-successFDE 기술 지도 — 8개 도메인의 최소선, 실무선, 확인 질문
Forward Deployed Engineer(FDE)에게 필요한 기술을 리눅스, 네트워크, 쿠버네티스, 데이터베이스, 인증·보안, 관측성, 클라우드·인프라, 고객 커뮤니케이션의 8개 도메인으로 지도화합니다. 도메인마다 왜 필요한지, 이력서가 아니라 현장에서 통하는 최소선은 어디인지, 실무선은 어디인지, 그리고 자기 위치를 재는 확인 질문 세 개를 붙였습니다. 전부를 다 갖춘 사람은 없으니
2026-08-12 · 12 분 읽기 #career#fde#forward-deployed-engineer#skills#roadmap코드가 어려운 부분이 아니었다는 말이 왜 그렇게 화를 돋우는가
2026년 8월에 Hacker News 상단을 차지한 에세이 하나는 코드는 원래 어려운 부분이 아니었다는 말이 모든 프로그래머에 대한 모욕이라고 주장합니다. 이 글은 그 반박에 동의하되 이유를 다르게 봅니다. 그 문장이 화를 돋우는 것은 틀려서가 아니라 코드라는 단어의 의미를 도중에 바꿔치기하기 때문입니다. 코드를 세 층으로 쪼개면 양쪽 주장이 각각 어디서 참인지가 보이고, 우리 팀이 실제로
2026-08-09 · 14 분 읽기 #career#craft#ai#engineering-culture#skills마찰이 사라지면 안목이 남는 게 아니라 안목을 기를 길이 사라집니다
2026년 8월에 화제가 된 에세이 Taste Is All That Is Left는 만드는 일이 싸지면서 무엇을 만들 가치가 있는지 판단하는 능력만 희소해졌다고 말합니다. 이 글은 그 진단에 동의하면서 한 걸음 더 들어갑니다. 안목은 노력이라는 필터의 부산물이었고, 필터가 사라지면 안목이 자동으로 남는 것이 아니라 안목을 기르던 경로가 함께 사라집니다. 그래서 필요한 것은 마찰을 의도적으로
2026-08-09 · 13 분 읽기 #career#craft#ai#code-review#mentoring글로 설득하기 — 디자인 문서와 RFC가 통과되는 구조
설계 문서, RFC, 제안서, 장애 후속 권고를 쓰는 사람을 위한 글입니다. 자신이 문제를 푼 순서가 아니라 원하는 결정을 맨 앞에 두는 법, 기각한 대안을 드러내는 것이 왜 제안과 광고를 가르는 유일한 표지인지, 아무것도 하지 않을 때의 비용을 어떻게 숫자로 만드는지, 훑어 읽는 결정자를 어떻게 상대하는지를 정리했습니다. 그리고 가장 중요한 것, 내가 없는 회의에서 인용될 문단을 어떻게 쓰
2026-08-02 · 25 분 읽기 #career#writing#persuasion#design-doc#engineering설득의 구조 — 말재주가 아니라 순서가 사람을 움직입니다
설득은 표현을 다듬기 한참 전에 구조에서 먼저 실패합니다. 주장보다 공유 전제를 먼저 세우는 일, 가장 강한 근거를 주의가 가장 높은 지점에 두는 일, 요구를 승낙할 수 있는 크기로 줄이는 일, 그리고 사람은 설득당하기를 거부한다는 비대칭까지 네 개의 축으로 정리했습니다. 정교화 가능성 모델과 접종 이론은 증거의 무게가 서로 다르다는 점, 문간에 발 들여놓기나 자아 고갈처럼 널리 인용되지만
2026-08-02 · 33 분 읽기 #career#persuasion#communication#influence#psychology반론을 다루는 법 — 사실 논쟁, 가치 논쟁, 지위 논쟁을 구별하기
설득을 배우는 사람 대부분이 건너뛰는 부분이 반론입니다. 상대의 논거를 상대보다 잘 정리해 소리 내어 확인하는 절차로서의 스틸맨, 가장 강한 반론을 내가 먼저 꺼내는 것이 왜 신뢰를 깎지 않고 올리는지, 사실 이견과 가치 이견과 지위 이견을 어떻게 구별하고 각각 무엇으로 대응해야 하는지를 정리했습니다. 논쟁 중간에 내가 틀렸다는 것을 알았을 때의 처리, 그리고 널리 인용되지만 대규모 재현에서
2026-08-02 · 27 분 읽기 #career#persuasion#communication#conflict#teamworkGo-To-Market 플레이북을 엔지니어가 읽는 법 — 유통이 제품 품질을 이기는 구간
2026년 7월 말 GeekNews에 NFX의 "업그레이드된 Go-To-Market 플레이북"이 올라왔습니다. VC가 쓴 관점 글이고, 안에 있는 숫자는 표본이 아니라 선별된 일화입니다. 이 글은 그 플레이북을 기술 독자용으로 번역합니다. 유통이 제품 품질을 이기는 구간이 어디인지, 개발자 대상 셀프서브의 실제 전환율이 얼마인지(개발자 대상 제품의 중간 전환율은 비개발자 대상의 절반입니다),
2026-07-31 · 24 분 읽기 #startup#go-to-market#product-led-growth#developer-tools#career매니저가 된다는 것의 진실 — 시니어 엔지니어에 회의가 더해지는 일이 아니다
2026년 7월 말 GeekNews에 올라온 "매니저가 된다는 것의 진실"은 열네 가지 항목을 나열한 개인 경험 에세이입니다. 이 글은 그 항목들이 왜 반복해서 나타나는지를 구조로 설명합니다. 매니저 역할의 본질은 업무량 증가가 아니라 출력 함수의 교체이고, 앤디 그로브의 정의대로 출력이 팀의 출력으로 바뀌는 순간 피드백 루프는 분 단위에서 분기 단위로 늘어나며 판독 가능성을 잃습니다. 개인
2026-07-31 · 25 분 읽기 #career#engineering-management#leadership#ic-to-manager#feedback-loop재능이라는 허상 — 연습 연구가 실제로 말하는 것과, 무엇이 복리로 쌓이는가
2026년 7월 말 GeekNews 상단에 "재능이라는 허상"이 올랐습니다. 제목만 보면 재능과 연습에 관한 과학 논쟁 같지만, 원문은 주니어 개발자의 커리어 불안을 다룬 개인 에세이이고 인용된 연구는 한 편도 없습니다. 이 글은 실제 문헌을 따라갑니다. 에릭슨의 1993년 논문이 무엇을 주장했고 무엇을 주장하지 않았는지, 매크나마라 메타분석이 말하는 분산 설명력 12퍼센트와 2018년 정오
2026-07-31 · 26 분 읽기 #career#deliberate-practice#expertise#psych-papers#mindset