태그: #software-engineering
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 17 편
AI 코드 리뷰는 실제로 쓸 만한가 — 측정된 증거가 말하는 정확도와 거짓 양성
AI 코드 리뷰 도구의 마케팅 문구에는 "PR의 80%에 사람 코멘트가 필요 없다" 같은 숫자가 넘치지만, 정작 정밀도와 거짓 양성률을 함께 공개한 곳은 거의 없습니다. 공개된 측정치를 모아 보면 방향은 대체로 일치합니다 — 오픈소스 PR에서 AI 리뷰 코멘트가 실제 코드 변경으로 이어진 비율은 도구에 따라 0.9~19.2%로, 사람 코멘트의 60%에 크게 못 미쳤습니다(Gan 등, 깃허브
2026-07-17 · 47 분 읽기 #ai#code-review#static-analysis#evaluation#software-engineeringForward Deployed Engineer의 크래프트 — 요구사항 발굴, 도메인 모델링, 그리고 채택을 향한 최적화
앞선 글은 FDE에게 필요한 지식 지도 — 리눅스·네트워크·쿠버네티스·DB·보안 — 를 정리했습니다. 그 지도는 문을 열어 줄 뿐, 고객사 건물 안에 들어간 뒤 실제로 무엇을 하는지는 말해 주지 않습니다. 이 글은 그 "동사"에 관한 것입니다. Palantir이 직접 쓴 Delta·Deployment Strategist 역할 문서, The Pragmatic Engineer의 취재, 그리고 현
2026-07-15 · 21 분 읽기 #career#fde#solutions-engineering#software-engineering#palantir무엇을 깊게 배우고, 무엇을 흘려보낼 것인가 — AI가 다 답해주는 시대의 학습 전략
AI가 3초 만에 거의 모든 것을 답해주는 시대에, 무엇을 깊게 배우고 무엇을 흘려보낼 것인가. 인지심리학은 불편한 답을 내놓습니다. 기억을 만드는 것은 정보를 보는 행위가 아니라 스스로 꺼내는 행위입니다. Roediger와 Karpicke의 실험에서 지문을 평균 14.2회 읽은 집단은 일주일 뒤 40%를 기억했고, 3.4회만 읽고 스스로 회상한 집단은 61%를 기억했습니다. 그런데 더 못
2026-07-12 · 24 분 읽기 #career#learning#ai#software-engineering코드 생성이 싸질 때 값이 오르는 기술 — 감가하는 것과 절상하는 것
코드 생성이 싸고 흔해지면 가치는 사라지지 않고 이동합니다 — 병목이 남아 있는 쪽으로. 지금 그 병목은 검증과 판단과 통합입니다. 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-reviewAI는 정말 개발자를 빠르게 만드는가 — 측정된 숫자들이 말하는 것
무작위 대조 실험 두 개가 정반대의 답을 내놓았습니다. 하나는 AI를 쓴 개발자가 55.8% 빨랐다고 했고, 다른 하나는 19% 느렸다고 했습니다. 그런데 뒤의 숫자를 낸 METR은 2026년 2월 후속 연구를 발표하면서, 2025년 결과 위에 이제는 현재를 반영하지 않는다는 경고 배너를 스스로 붙였습니다. 이야기가 사라지는 게 아니라 오히려 날카로워집니다 — 후속 실험조차 참가자 자기선택
2026-07-12 · 36 분 읽기 #career#ai#productivity#software-engineering#developer-experienceAI 코딩 도구와 잘 일하는 다섯 가지 습관
같은 도구가 한 실험에서는 55.8% 이득을, 다른 실험에서는 19% 손해를 냈습니다. 부호를 바꾼 것은 도구가 아니라 사용법이었습니다. METR, GitHub Copilot RCT, 스택오버플로 설문, 앤트로픽의 에이전트 설계 문서에서 끌어낸 다섯 가지 습관 — 작업 선택, 리뷰 예산, 기계 가드레일, 컨텍스트 설계, 자기 측정. 각각은 당신이 직접 검증할 수 있는 규칙 한 줄로 끝납니다.
2026-07-12 · 19 분 읽기 #ai#productivity#software-engineering#developer-experience2026년 개발자 채용 시장 — 데이터가 말하는 것과 말하지 않는 것
체감은 최악인데 BLS는 10년간 15% 성장을 예측합니다. 둘 다 맞습니다. Indeed 채용공고 지수 원데이터(2020년 2월=100, 2022년 2월 고점 233.87, 2026년 6월 72.51), layoffs.fyi(2026년 7월까지 120,936명), BLS 2024–34 전망, Stanford의 주니어 16% 감소 논문과 그것을 정면 반박하는 EIG 보고서를 직접 받아 대조했
2026-07-12 · 18 분 읽기 #career#job-market#software-engineering#hiring시니어에서 스태프로 — 엔지니어의 성장에서 실제로 평가받는 것
더 많이, 더 빨리 짜면 승진한다고 믿는 엔지니어가 많습니다. 그런데 공개된 엔지니어링 사다리를 실제로 열어 보면 — Dropbox, CircleCI, Rent the Runway — 어디에도 "산출량"이라는 축이 없습니다. 대신 스코프, 협업 반경, 임팩트 레버리지가 있습니다. 이 글은 Will Larson의 스태프 엔지니어 네 가지 아키타입(Tech Lead, Architect, Solv
2026-07-12 · 22 분 읽기 #career#software-engineering#growth#staff-engineer코딩 벤치마크는 에이전트 시대와 어긋나 있다 — 리더보드가 에이전트를 잘못 비교하는 세 가지 이유
Tessl 연구진이 2026년 6월 arXiv에 올린 포지션 논문은, 오늘날의 코딩 벤치마크가 에이전트형 소프트웨어 엔지니어링과 근본적으로 어긋나 있다고 주장합니다. 벤치마크는 개별 모델을 재려고 만들어졌는데, 우리는 그것으로 모델·하네스·컨텍스트·환경·피드백이 얽힌 시스템 전체를 비교하고 있기 때문입니다. 논문은 세 가지 구체적 어긋남 — 모델과 하네스를 뭉뚱그리는 점수, 단일 정답 채점이
2026-07-11 · 12 분 읽기 #ai#agents#evaluation#software-engineering#coding-benchmarksForward Deployed Engineer(FDE)를 준비하며 — 필요한 소프트웨어 지식 지도
Forward Deployed Engineer(FDE)는 Palantir이 만든 직군으로, 엔지니어가 고객사에 직접 들어가 제품을 그들의 실제 환경에 배포·통합하는 역할입니다. 최근 OpenAI·Anthropic 같은 AI 회사들이 자사 모델을 고객 인프라에 얹기 위해 이 직군을 대거 채용하며 다시 주목받고 있습니다. 이 글은 FDE를 준비하는 사람을 위해, 역할의 실체(실제 소스 기반)와
2026-07-11 · 12 분 읽기 #career#fde#software-engineering#palantir#solutions-engineering레거시 코드 다루기 — 무섭고 오래된 코드를 두려움 없이 바꾸는 법
레거시 코드는 테스트가 없는 코드이고, 당신이 손대기 두려워하는 코드다. 그리고 누구나 언젠가 그것을 상속받는다. 안전하게 바꾸려면 테스트가 필요하고 테스트를 붙이려면 코드를 바꿔야 하는 딜레마, 현재 동작을 박제하는 특성화 테스트, 재작성 없이 테스트를 끼워 넣는 이음새, 새싹 메서드와 감싸기, 스트랭글러 무화과 패턴, 그리고 AI 에이전트가 여기서 어떻게 돕고 어떻게 망치는지까지 — 두려
2026-05-14 · 50 분 읽기 #legacy-code#refactoring#characterization-tests#strangler-fig#technical-debtAI가 쓴 코드를 리뷰하는 법: 에이전트 출력물을 위한 검증 규율과 'AI 슬롭' 걸러내기
AI가 코드를 쓰는 시대에 병목은 리뷰로 옮겨갔습니다. 사람 PR을 리뷰하는 것과 에이전트 출력물을 리뷰하는 것은 다른 기술입니다. AI 코드가 특유하게 틀리는 방식, 환각 API와 의미 없는 테스트를 걸러내는 검증 루프, 타입보다 테스트보다 사람의 순서, 'AI 슬롭'의 정체와 필터링까지 — 복사해 쓸 수 있는 체크리스트와 함께 정리합니다.
2026-05-14 · 39 분 읽기 #code-review#ai-generated-code#verification#ai-slop#quality개발자의 다음 커리어는 'Builder' — '엔지니어'가 저무는 시대, 무엇을 준비할 것인가 (2026)
Meta의 PM은 자신을 'AI builder'라 부르고, LinkedIn은 'full stack builder' 프로그램을 열었고, Walmart의 'agent builder' 자리는 비개발 직원이 채웠다. Anthropic Claude Code 제작자는 '코딩은 사실상 풀렸고 소프트웨어 엔지니어라는 타이틀은 사라질 것'이라 말한다. GeekNews와 Hacker News를 뒤져 정리한,
2026-05-14 · 23 분 읽기 #career#builder#ai-era#developer-career#vibe-coding리뷰 가능한 PR 쓰기: 작은 PR, 좋은 설명, 스택 PR로 리뷰어를 빠르게 만드는 법
PR의 리뷰 지연 시간은 작성자가 통제합니다. 작은 PR이 이기는 이유, '하나의 PR = 하나의 아이디어' 원칙, 가장 중요한 산출물인 PR 설명, 읽히는 디프 만들기, 스택 PR, 셀프 리뷰, 리뷰 피드백에 잘 답하는 법, 그리고 AI 시대의 PR 작성까지 — 복사해서 쓰는 PR 설명 템플릿과 함께 정리합니다.
2026-05-14 · 41 분 읽기 #pull-request#code-review#git#stacked-prs#collaboration체계적 디버깅 — 추측이 아니라 추론으로 버그를 잡는 법
대부분의 디버깅은 훈련되지 않은 추측이다. 재현 · 격리 · 가설 · 검증 · 수정 · 확인이라는 핵심 루프, git bisect와 이진 탐색, 스택 트레이스를 제대로 읽는 법, 하이젠버그와 레이스 컨디션 같은 어려운 버그, 그리고 AI 에이전트와 함께 디버깅하는 법까지 — 추론으로 버그를 잡는 기술을 정리한다.
2026-05-14 · 38 분 읽기 #debugging#methodology#engineering-craft#git-bisect#observability낯선 코드베이스에 빠르게 적응하기: 새로 들어온 사람의 기술
이직, 팀 이동, 인수받은 서비스 — 우리는 반복해서 '새로 들어온 사람'이 됩니다. 적응은 타고나는 게 아니라 배울 수 있는 기술입니다. 일단 돌려보기, 진입점 찾기, 디테일보다 형태 먼저 읽기, 요청 하나를 끝까지 따라가기, 테스트를 문서로 읽기, 도구 활용, 작은 변경 먼저 하기, 멘탈 맵 그리기, 무엇을 누구에게 물을지, 그리고 AI 에이전트와 함께 적응하기까지 — 복사해서 쓸 수 있
2026-05-14 · 42 분 읽기 #onboarding#codebase#learning#newcomer#developer-craft거대 소프트웨어는 어떻게 개발하고 관리하고 유지할까? — SW 업데이트 시스템까지
수백만 줄의 코드, 수천 명의 개발자가 참여하는 거대 소프트웨어는 어떻게 개발되고, 업데이트되고, 유지되는가? 아키텍처, 배포, 자동 업데이트 시스템까지 깊이 파헤칩니다.
2026-04-11 · 31 분 읽기 #devops#software-engineering#architecture#update-system#large-scale