Goodhart's Law

Lilian Weng의 글 Harness Engineering for Self-Improvement는 AI 자기개선을 모델 가중치의 문제로만 보지 않는다. 모델 주변에서 실행을 조율하는 하네스, 즉 도구 호출, 메모리, 워크플로, 권한, 평가 루프까지 포함한 시스템이 가까운 미래의 핵심 개선 대상이라는 주장이다. Harness 핵심 정리 하네스의 역할: 베이스 모델이 어떻게 생각하고, 어떤 도구를 쓰고, 무엇을 기억하고, 어떤 결과를 통과시킬지 정하는 실행 시스템이다. 가까운 경로: 자기개선은 모델이 곧장 자기 가중치를 수정하는 장면보다, 하네스와 연구 파이프라인을 개선하는 형태로 먼저 올 가능성이 크다. 중요 패턴: 워크플로 자동화, 파일 시스템 기반 장기 기억, 서브에이전트와 백엔드 작업 관리가 반복해서 등장한다. 최적화 대상: 프롬프트에서 구조화 컨텍스트, 워크플로, 하네스 코드, 옵티마이저 코드로 점점 내려간다. 현실적 한계: 평가가 흐릿한 영역에서는 보상 해킹, 실패 은폐, 다양성 붕괴, 장기 유지보수 비용을 피하기 어렵다. 1) 하네스는 프롬프트보다 실행 시스템에 가깝다 초기 에이전트 설명은 보통 LLM + memory + tools + planning + action 같은 공식으로 끝났다. Weng은 여기에 한 층을 더 얹는다. 실제 제품에서 중요한 것은 모델에게 좋은 말을 건네는 것만이 아니라, 모델이 어떤 루프 안에서 관찰하고, 실행하고, 실패를 기록하고, 다시 시도하게 만드는가다. ...

AI 도구를 모두에게 열어주고, 사용량이 늘고, 슬랙에 성공 사례 채널이 생겼다고 해서 팀이 정말 더 강해졌다고 말할 수는 없다. Ably의 글은 이 착시를 정면으로 다룬다. 질문은 단순하다. AI가 우리 팀을 더 유능하게 만들고 있는가, 아니면 더 바쁘게 만들고 있는가? 원문: Is AI making your teams better, or just busier? TL;DR 핵심 정리 사용량은 쉬운 지표지만 약한 지표다: 매일 AI를 열어 같은 일을 조금 빨리 해도 높은 도입률로 보인다. 그러나 팀의 가능 업무 범위가 넓어졌는지는 알 수 없다. 두 가지 KPI가 핵심이다: AI로 새롭게 가능해진 결과가 있는지, AI가 일상 업무 방식 안에 얼마나 깊게 들어왔는지를 월별로 본다. 점수는 증거로만 오른다: 팀 리드가 1~5점으로 평가하되, “무엇을 했고 왜 더 나아졌는지” 사례가 없으면 점수 상승은 없다. 초기 2점은 실패가 아니다: Ably도 첫 평가에서 두 KPI 모두 2점 수준에서 시작했다. 중요한 것은 높은 출발점이 아니라 매달 좋아지는 궤적이다. 사용량 지표의 함정 AI 도입 성과를 볼 때 가장 쉬운 방법은 “누가 쓰고 있는가”, “얼마나 자주 쓰는가"를 세는 것이다. 하지만 이 지표는 품질을 말하지 않는다. AI 도구를 매일 열어도 기존 업무를 조금 더 빠르게 할 뿐이라면, 팀 역량은 크게 변하지 않는다. ...

보내주신 글은 현직 개발자와 관리자가 느끼는 “AI 환상(Hype)과 실제 업무 사이의 괴리” 를 아주 날카롭게 짚고 있습니다. 특히 단순한 성능 지표가 아닌, 작업의 복잡도 와 부작용(Side-effects) 이라는 두 축으로 AI의 유용성을 정의한 점이 매우 인상적입니다. 출처: Getting Real With LLMs - Gilad Peleg 🚀 실무 중심의 AI 활용 매트릭스 이 글은 엔지니어링 업무를 복잡도(X축) 와 부작용/파급력(Y축) 으로 나누어, 현재 LLM이 실제로 도움이 되는 영역과 단순히 “연기(Smoke & Mirrors)“에 불과한 영역을 구분합니다. ...