태그: #skills
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 21 편
엔지니어의 쓰는 능력 — 설계 문서, 사고 보고서, 리뷰 코멘트가 하는 일
엔지니어에게 글쓰기가 중요하다는 말은 흔하지만, 왜 중요한지가 대개 승진 이야기로 끝납니다. 이 글은 다른 순서로 봅니다. 글은 먼저 사고의 검증 장치이고, 조직 안에서 반박 가능한 표면을 만드는 도구이며, 그 결과로 평가에 영향을 줍니다. 설계 문서에서 가장 중요한 것이 왜 버린 대안인지, 사고 보고서에서 사실과 해석을 나누는 것이 왜 정치가 아니라 기술인지, 리뷰 코멘트에 등급을 붙이는
2026-08-15 · 13 분 읽기 #career#skills#technical-writing#design-doc#postmortem검증 설계 — 테스트를 통과 여부가 아니라 신뢰 근거로 보기
테스트가 초록불이라는 사실 자체는 아무것도 말해 주지 않습니다. 무엇을 안 걱정해도 되는지가 정해져 있을 때만 초록불에 뜻이 생깁니다. 이 글은 테스트를 통과 여부가 아니라 신뢰 근거로 다루는 방법을 다룹니다. 각 테스트에 신뢰 문장을 붙이는 연습, 커버리지가 실제로 재는 것과 재지 못하는 것의 차이, 검증하지 않기로 한 것을 명시적으로 적어야 하는 이유, 그리고 정답표가 없는 영역에서 판정
2026-08-15 · 12 분 읽기 #career#skills#testing#verification#craft프로덕션 감각 — 장애를 겪어 본 사람이 다르게 보는 것들
같은 설계 문서를 읽어도 장애를 겪어 본 사람은 다른 것을 읽습니다. 이게 새벽에 깨지면 무슨 로그가 남는지, 되돌리는 데 몇 분이 걸리는지, 되돌린 뒤 이미 들어간 데이터는 어떻게 되는지입니다. 이 글은 프로덕션이 왜 코드가 아니라 상태인지, 100퍼센트가 왜 옳은 신뢰성 목표가 아닌지, 관측과 롤백과 점진 배포가 왜 도구 도입이 아니라 기본값의 문제인지, 그리고 장애를 직접 겪지 않고도
2026-08-15 · 13 분 읽기 #career#skills#sre#production#reliability디버깅은 왜 대체가 어려운가 — 배제의 기술과 가설의 문장
디버깅은 코드를 쓰는 일과 방향이 반대입니다. 쓰기는 가능한 것을 하나 만들어 내는 일이고, 디버깅은 가능한 것들을 하나만 남을 때까지 지우는 일입니다. 이 글은 디버깅이 왜 검증 비용이 비싼 쪽에 남는지, 반증 가능한 가설을 어떻게 문장으로 쓰는지, 시스템을 계층으로 잘라 절반씩 좁히는 절차가 어떻게 작동하는지, 그리고 재현되지 않는 문제를 재현 대신 관측으로 공략하는 법을 다룹니다. 같은
2026-08-15 · 13 분 읽기 #career#skills#debugging#craft#troubleshootingAI 도구와 일하는 법을 하나의 기술로 — 위임 기준과 검증 절차
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무엇이 비싸게 남는가 — 생성이 싸질 때 값이 오르는 네 가지
IT 엔지니어가 앞으로 무엇을 준비해야 하는지 묻는 질문에 도구 목록으로 답하면 그 답은 2년이면 낡습니다. 이 글은 다른 축을 제안합니다. 값이 남는 기술은 검증 비용이 비싼 기술이라는 것입니다. 생성 비용과 검증 비용을 두 축으로 놓고 네 칸을 그리면, 자동화가 어디를 먼저 먹었고 어디에 사람이 남는지가 한 장에 정리됩니다. 그리고 이 틀에는 반전이 하나 있습니다. 엔지니어의 일은 검증을
2026-08-15 · 13 분 읽기 #career#skills#ai#craft#engineering-culture남이 쓴 것을 읽는 능력 — 코드베이스 진입과 문서 없는 시스템 역설계
쓰기는 연습이 강제되지만 읽기는 그렇지 않습니다. 그래서 읽기는 모두가 매일 하면서도 아무도 훈련하지 않는 기술이 됐고, 생성이 싸진 지금 가장 빠르게 값이 오른 능력이 됐습니다. 이 글은 낯선 대규모 코드베이스에 진입하는 일곱 단계 절차, 문서가 없는 시스템을 실행 중인 상태에서 역설계하는 방법, 그리고 코드에 절대 남지 않는 정보가 무엇인지를 다룹니다. 읽기가 왜 검증 비용이 비싼 쪽에
2026-08-15 · 12 분 읽기 #career#skills#code-reading#craft#legacy-code도메인 지식이 왜 방어선인가 — 업을 아는 엔지니어와 기술만 아는 엔지니어
도메인 지식은 코드에도 문서에도 없고 사람과 관행에만 있습니다. 그래서 이 시리즈가 말해 온 검증 비용을 가장 비싸게 만드는 요인이자, 그 비용을 감당할 수 있는 사람이 남는 이유입니다. 이 글은 업을 아는 엔지니어가 질문과 예외와 요구 해석에서 무엇을 다르게 하는지, 회의에서 쓰는 말과 코드에 있는 이름이 어긋날 때 무엇이 깨지는지, 도메인을 익히는 여섯 단계 절차, 그리고 도메인 지식이
2026-08-15 · 14 분 읽기 #career#skills#domain-knowledge#ddd#ontology오래된 기술과 함께 나이 드는 것에 대한 두려움
연차가 쌓이면 불안의 모양이 바뀝니다. 시작할 자리가 있을까에서, 내가 서 있는 자리가 언제 없어질까로. 이 글은 그 두려움을 두 개로 나눕니다. 쌓은 것의 감가와 다시 배울 능력의 감소. 그다음 지식을 유통기한이 다른 세 개의 층으로 갈라 무엇이 실제로 낡고 무엇이 남는지 보고, 같은 십 년이 어떤 조건에서 자산이 되고 어떤 조건에서 부채가 되는지를 각각 세 가지와 네 가지로 정리합니다.
2026-08-15 · 12 분 읽기 #career#senior-engineer#obsolescence#skills#agingFDE 기술 지도 — 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코드 생성이 싸질 때 값이 오르는 기술 — 감가하는 것과 절상하는 것
코드 생성이 싸고 흔해지면 가치는 사라지지 않고 이동합니다 — 병목이 남아 있는 쪽으로. 지금 그 병목은 검증과 판단과 통합입니다. Jason Wei의 검증 비대칭성, DORA 2025(처리량은 올랐는데 배포 불안정성은 계속 상승), LinearB의 800만 PR 분석(AI가 만든 PR은 리뷰를 4.6배 오래 기다린다), Stack Overflow 2025(개발자 66%가 "거의 맞지만 정확
2026-07-12 · 27 분 읽기 #career#software-engineering#ai#skills#code-review기술 면접 준비 플레이북 — 코딩·시스템 설계·행동 면접까지
기술 면접은 실력의 시험이자 별도의 기술입니다. 코딩 면접의 패턴 학습법, 시스템 설계 면접의 5단계 프레임, STAR 기법으로 행동 면접 스토리 은행 만들기, 직무별 단골 질문, 그리고 8주 역산 계획까지 — 면접관이 실제로 보는 신호를 기준으로 준비법을 정리합니다. 직무 지식 지도 편, AI 공부법 편과 이어지는 3부작의 2편입니다.
2026-07-06 · 14 분 읽기 #career#interview#skills#preparation2026 떠오르는 직무별 필요 지식 지도 — 무엇을 공부해야 하는가
AI/LLM 엔지니어, 플랫폼·DevOps/SRE, 보안 엔지니어, 데이터 엔지니어, 프론트엔드 — 지금 가장 수요가 높은 다섯 직무가 각각 어떤 지식을 요구하는지 체크리스트로 정리합니다. 직무를 관통하는 공통 역량과, 각 지식을 브라우저에서 바로 연습할 수 있는 도구·레퍼런스까지 함께 담았습니다. 면접 준비 편, AI 공부법 편과 이어지는 3부작의 1편입니다.
2026-07-06 · 15 분 읽기 #career#roadmap#skills#learning복리로 쌓이는 커리어 — 열정을 좇지 말고 실력을 쌓아라
좋은 커리어는 "열정을 따라가서" 만들어지지 않습니다. 희소하고 가치 있는 실력, 평판, 관계를 시간에 걸쳐 복리로 쌓아야 만들어집니다. 커리어 자본 이론, 의식적 연습, 레버리지, 그리고 매년 반복 가능한 실천 루프까지 — 복리로 쌓이는 커리어를 만드는 법을 정리합니다.
2026-07-03 · 28 분 읽기 #career#growth#skills#productivity2026년 AI 코딩 워크플로 베스트 프랙티스 — CLAUDE.md, AGENTS.md, .cursorrules, Skills, 서브에이전트, MCP 깊게 보기
2026년 현재 AI 코딩 도구가 모이는 표준 — CLAUDE.md, AGENTS.md, .cursorrules, .github/copilot-instructions.md, 그리고 Claude Code의 Skills·서브에이전트·hooks·MCP·permission 모드까지. 어떤 파일에 무엇을 넣고, 어떻게 계층화하고, 무엇을 피해야 하는지. 복사해서 쓸 수 있는 스니펫과 함께 정리합니다.
2026-05-14 · 37 분 읽기 #ai-coding#claude-md#agents-md#cursorrules#claude-codeClaude Code Skills 직접 만들기 — SKILL.md 한 장으로 에이전트의 새 도구를 빚는 실전 핸즈온 (2026)
Anthropic이 2025년 가을에 처음 도입하고 12월에 오픈 표준화한 Agent Skills는 2026년 5월 현재 Claude Code의 표준 확장 방식이 되었다. 본질은 단순하다 — YAML 프론트매터 + 마크다운 지시 + 필요하면 스크립트/레퍼런스. 모델이 description을 읽고 스스로 invoke 여부를 결정한다. 이 글은 SKILL.md의 정확한 스펙(필드 전부), 디렉터
2026-05-14 · 37 분 읽기 #claude-code#skills#anthropic#ai-tooling#hands-onAI 하네스란 무엇인가: Skills, Context, Hooks, Permissions로 AI를 제어하는 오케스트레이션 아키텍처
AI 하네스(Harness)는 AI 모델을 감싸서 제어하는 오케스트레이션 레이어입니다. System Prompt, Tools, Context, Skills, Hooks, Permissions, Memory의 7가지 구성 요소를 해부하고, Claude Agent SDK와 LangGraph로 직접 만드는 방법까지 — AI 엔지니어 필독 가이드.
2026-03-23 · 56 분 읽기 #ai-harness#claude-code#agent-sdk#skills#context