Skip to content

Software-engineering

  • Published on
    AI 코드 리뷰 도구의 마케팅 문구에는 "PR의 80%에 사람 코멘트가 필요 없다" 같은 숫자가 넘치지만, 정작 정밀도와 거짓 양성률을 함께 공개한 곳은 거의 없습니다. 공개된 측정치를 모아 보면 방향은 대체로 일치합니다 — 오픈소스 PR에서 AI 리뷰 코멘트가 실제 코드 변경으로 이어진 비율은 도구에 따라 0.9~19.2%로, 사람 코멘트의 60%에 크게 못 미쳤습니다(Gan 등, 깃허브 액션 16종·저장소 178곳·코멘트 22,326건). 반면 코멘트 해결을 정책으로 강제한 한 기업 사례에서는 같은 지표가 73.8%로 나왔고, 대신 PR 종료 시간이 5시간 52분에서 8시간 20분으로 늘었습니다. 80배 차이는 도구가 아니라 데이터셋과 측정 방식에서 나옵니다. 이 글은 그 숫자들의 조건을 하나씩 뜯어보고, 텐센트의 정적 분석 알람 76%가 거짓 양성이었다는 측정, 구글이 2018년부터 지켜 온 "거짓 양성 10% 넘으면 분석기를 끈다"는 규칙, 그리고 개발자의 "해결함" 라벨조차 정답이 아니라는 후속 연구(LLM 심사의 MCC가 거의 0)를 정리합니다. 결론은 AI 리뷰가 쓸모없다는 것이 아니라, 좁게 설정했을 때만 값을 한다는 것입니다.
  • Published on
    앞선 글은 FDE에게 필요한 지식 지도 — 리눅스·네트워크·쿠버네티스·DB·보안 — 를 정리했습니다. 그 지도는 문을 열어 줄 뿐, 고객사 건물 안에 들어간 뒤 실제로 무엇을 하는지는 말해 주지 않습니다. 이 글은 그 "동사"에 관한 것입니다. Palantir이 직접 쓴 Delta·Deployment Strategist 역할 문서, The Pragmatic Engineer의 취재, 그리고 현재 열려 있는 Anthropic·OpenAI FDE 공고를 근거로, 이 일의 대부분을 이루는 여섯 가지 움직임을 다룹니다 — 요구사항 발굴(요청한 것 vs 진짜 필요한 것), 고객의 도메인을 양쪽이 함께 가리킬 수 있는 공유 모델로 만들기, 지저분하고 에어갭이며 레거시인 환경에 통합하기, 피드백 도구로서의 데모, 언제 아니오라고 말하고 과잉 설계를 피할지, 그리고 유일하게 중요한 점수 — 짠 코드의 양이 아니라 채택. 마지막으로 가장 어려운 부분을 정직하게 적었습니다 — 남의 건물에서, 남의 일정에 맞춰, 다리(bridge)로 서 있는 일.
  • Published on
    무작위 대조 실험 두 개가 정반대의 답을 내놓았습니다. 하나는 AI를 쓴 개발자가 55.8% 빨랐다고 했고, 다른 하나는 19% 느렸다고 했습니다. 그런데 뒤의 숫자를 낸 METR은 2026년 2월 후속 연구를 발표하면서, 2025년 결과 위에 이제는 현재를 반영하지 않는다는 경고 배너를 스스로 붙였습니다. 이야기가 사라지는 게 아니라 오히려 날카로워집니다 — 후속 실험조차 참가자 자기선택 편향에 발목이 잡혀 효과의 부호를 확정하지 못했기 때문입니다. 그리고 철회되지 않은 발견이 하나 남습니다. 19% 느려진 개발자들은 실험을 마친 뒤에도 자신이 20% 빨라졌다고 믿었습니다. 이 글은 METR의 2025년 원 결과와 2026년 갱신, GitHub Copilot RCT, DORA, 스택오버플로 설문을 근거로, 왜 AI 생산성은 전문가조차 깨끗하게 측정하지 못하는지, 그렇다면 당신은 무엇을 해야 하는지 정리합니다.
  • Published on
    체감은 최악인데 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 보고서를 직접 받아 대조했습니다. 핵심은 "AI가 주니어 채용을 죽였다"가 아직 입증되지 않았고 금리·과잉채용 교정이라는 경쟁 가설이 타이밍상 더 잘 맞는다는 것, 그리고 아무도 가격에 넣지 않는 2차 효과 — 지금 주니어를 안 키우면 5년 뒤 시니어가 없다는 것입니다. 도파민도 공포팔이도 없이, 숫자에 출처와 날짜를 붙였습니다.
  • Published on
    AI가 3초 만에 거의 모든 것을 답해주는 시대에, 무엇을 깊게 배우고 무엇을 흘려보낼 것인가. 인지심리학은 불편한 답을 내놓습니다. 기억을 만드는 것은 정보를 보는 행위가 아니라 스스로 꺼내는 행위입니다. Roediger와 Karpicke의 실험에서 지문을 평균 14.2회 읽은 집단은 일주일 뒤 40%를 기억했고, 3.4회만 읽고 스스로 회상한 집단은 61%를 기억했습니다. 그런데 더 못 기억한 쪽이 자신을 더 확신했습니다. AI에게 인출을 대신 시키면 정확히 그 확신만 남습니다. 이 글은 읽기 목록이 아니라 전략을 제안합니다.
  • Published on
    더 많이, 더 빨리 짜면 승진한다고 믿는 엔지니어가 많습니다. 그런데 공개된 엔지니어링 사다리를 실제로 열어 보면 — Dropbox, CircleCI, Rent the Runway — 어디에도 "산출량"이라는 축이 없습니다. 대신 스코프, 협업 반경, 임팩트 레버리지가 있습니다. 이 글은 Will Larson의 스태프 엔지니어 네 가지 아키타입(Tech Lead, Architect, Solver, Right Hand), Tanya Reilly의 "Being Glue"가 실제로 말한 것, 그리고 공개 사다리의 실제 문장을 근거로 성장의 메커니즘을 정리합니다. 임팩트가 어떻게 증거가 되는가(설계 문서, 장애 대응, 멘토링, 팀 간 언블로킹), 글루 워크의 진짜 함정, 정치 없이 보이는 법, 그리고 사다리 자체가 회사마다 다르고 운이 섞인다는 정직한 사실까지. 마지막으로 AI가 코드 산출을 값싸게 만드는 시대에, 사다리가 원래부터 재던 축이 왜 더 중요해지는지 이야기합니다.
  • Published on
    코드 생성이 싸고 흔해지면 가치는 사라지지 않고 이동합니다 — 병목이 남아 있는 쪽으로. 지금 그 병목은 검증과 판단과 통합입니다. Jason Wei의 검증 비대칭성, DORA 2025(처리량은 올랐는데 배포 불안정성은 계속 상승), LinearB의 800만 PR 분석(AI가 만든 PR은 리뷰를 4.6배 오래 기다린다), Stack Overflow 2025(개발자 66%가 "거의 맞지만 정확히는 아닌" 코드를 최대 불만으로 꼽음)를 근거로 무엇이 감가하고 무엇이 절상하는지 정리했습니다. 핵심은 코드를 훑어보는 눈이 아니라 무엇이 정답인지를 공급하는 능력입니다. "개발자는 끝났다"와 "달라진 건 없다"를 모두 거부합니다.
  • Published on
    같은 도구가 한 실험에서는 55.8% 이득을, 다른 실험에서는 19% 손해를 냈습니다. 부호를 바꾼 것은 도구가 아니라 사용법이었습니다. METR, GitHub Copilot RCT, 스택오버플로 설문, 앤트로픽의 에이전트 설계 문서에서 끌어낸 다섯 가지 습관 — 작업 선택, 리뷰 예산, 기계 가드레일, 컨텍스트 설계, 자기 측정. 각각은 당신이 직접 검증할 수 있는 규칙 한 줄로 끝납니다.
  • Published on
    Tessl 연구진이 2026년 6월 arXiv에 올린 포지션 논문은, 오늘날의 코딩 벤치마크가 에이전트형 소프트웨어 엔지니어링과 근본적으로 어긋나 있다고 주장합니다. 벤치마크는 개별 모델을 재려고 만들어졌는데, 우리는 그것으로 모델·하네스·컨텍스트·환경·피드백이 얽힌 시스템 전체를 비교하고 있기 때문입니다. 논문은 세 가지 구체적 어긋남 — 모델과 하네스를 뭉뚱그리는 점수, 단일 정답 채점이 정당한 대안을 벌주는 점, 컴포넌트 단위 신호가 없어 개선을 이끌 수 없는 점 — 을 짚습니다. 이 글은 그 논증을 정리하고, 더 나은 평가가 컴포넌트 단위·다중 정답·시스템 인식이라는 방향으로 어떻게 생겨야 하는지 따져 봅니다.
  • Published on
    Forward Deployed Engineer(FDE)는 Palantir이 만든 직군으로, 엔지니어가 고객사에 직접 들어가 제품을 그들의 실제 환경에 배포·통합하는 역할입니다. 최근 OpenAI·Anthropic 같은 AI 회사들이 자사 모델을 고객 인프라에 얹기 위해 이 직군을 대거 채용하며 다시 주목받고 있습니다. 이 글은 FDE를 준비하는 사람을 위해, 역할의 실체(실제 소스 기반)와 정말로 중요한 소프트웨어 지식 — 리눅스·네트워크·컨테이너/쿠버네티스·데이터베이스·API 통합·데이터 파이프라인·낯선 환경 디버깅·보안 — 을 정리했습니다. 순수 SWE와 무엇이 다른지(깊이보다 넓이, 모호함, 고객 접점)도 솔직하게 적었습니다.
  • Published on
    PR의 리뷰 지연 시간은 작성자가 통제합니다. 작은 PR이 이기는 이유, '하나의 PR = 하나의 아이디어' 원칙, 가장 중요한 산출물인 PR 설명, 읽히는 디프 만들기, 스택 PR, 셀프 리뷰, 리뷰 피드백에 잘 답하는 법, 그리고 AI 시대의 PR 작성까지 — 복사해서 쓰는 PR 설명 템플릿과 함께 정리합니다.
  • Published on
    Meta의 PM은 자신을 'AI builder'라 부르고, LinkedIn은 'full stack builder' 프로그램을 열었고, Walmart의 'agent builder' 자리는 비개발 직원이 채웠다. Anthropic Claude Code 제작자는 '코딩은 사실상 풀렸고 소프트웨어 엔지니어라는 타이틀은 사라질 것'이라 말한다. GeekNews와 Hacker News를 뒤져 정리한, 'Coder에서 Builder로'의 진짜 의미 — Builder의 3대 역량(이해·지시·검증), '속 빈 빌더'의 위험, 그리고 변하지 않는 것까지. 균형 잡힌 실전 커리어 가이드.
  • Published on
    이직, 팀 이동, 인수받은 서비스 — 우리는 반복해서 '새로 들어온 사람'이 됩니다. 적응은 타고나는 게 아니라 배울 수 있는 기술입니다. 일단 돌려보기, 진입점 찾기, 디테일보다 형태 먼저 읽기, 요청 하나를 끝까지 따라가기, 테스트를 문서로 읽기, 도구 활용, 작은 변경 먼저 하기, 멘탈 맵 그리기, 무엇을 누구에게 물을지, 그리고 AI 에이전트와 함께 적응하기까지 — 복사해서 쓸 수 있는 체크리스트와 함께 정리합니다.
  • Published on
    AI가 코드를 쓰는 시대에 병목은 리뷰로 옮겨갔습니다. 사람 PR을 리뷰하는 것과 에이전트 출력물을 리뷰하는 것은 다른 기술입니다. AI 코드가 특유하게 틀리는 방식, 환각 API와 의미 없는 테스트를 걸러내는 검증 루프, 타입보다 테스트보다 사람의 순서, 'AI 슬롭'의 정체와 필터링까지 — 복사해 쓸 수 있는 체크리스트와 함께 정리합니다.
  • Published on
    대부분의 디버깅은 훈련되지 않은 추측이다. 재현 · 격리 · 가설 · 검증 · 수정 · 확인이라는 핵심 루프, git bisect와 이진 탐색, 스택 트레이스를 제대로 읽는 법, 하이젠버그와 레이스 컨디션 같은 어려운 버그, 그리고 AI 에이전트와 함께 디버깅하는 법까지 — 추론으로 버그를 잡는 기술을 정리한다.
  • Published on
    레거시 코드는 테스트가 없는 코드이고, 당신이 손대기 두려워하는 코드다. 그리고 누구나 언젠가 그것을 상속받는다. 안전하게 바꾸려면 테스트가 필요하고 테스트를 붙이려면 코드를 바꿔야 하는 딜레마, 현재 동작을 박제하는 특성화 테스트, 재작성 없이 테스트를 끼워 넣는 이음새, 새싹 메서드와 감싸기, 스트랭글러 무화과 패턴, 그리고 AI 에이전트가 여기서 어떻게 돕고 어떻게 망치는지까지 — 두려움을 절차로 바꾸는 기술을 정리한다.