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

Will DePue의 A Stargate for Data는 AI 산업의 관심이 컴퓨트에 치우쳐 있는 동안, 다음 병목은 데이터가 될 수 있다고 말한다. X에 올라온 원문 포스트는 이 문제의식을 짧게 던지고, LinkedIn 글은 그 배경을 길게 설명한다. Data 핵심 정리 핵심 주장: AI 발전은 모델 크기와 데이터 양을 함께 키우며 진행됐지만, 이제 공개 인터넷 데이터가 부족해지는 국면에 들어가고 있다. 전환점: 과거에는 GPU가 부족하고 인터넷 데이터는 충분했다. 앞으로는 컴퓨트가 커질수록, 각 산업의 비공개 지식과 실제 업무 데이터가 더 큰 병목이 된다. 시장 크기: DePue는 외부 데이터 벤더 지출이 이미 연간 약 70억 달러이며, 2030년에는 연간 1,000억 달러 이상으로 커질 수 있다고 본다. 경쟁 구도: 컴퓨트는 같은 칩과 비슷한 클러스터를 살 수 있지만, 데이터는 독점 계약·전문가 네트워크·품질 관리·도메인 커버리지로 차별화된다. 전략 질문: 컴퓨트를 위해 Stargate 같은 초대형 인프라를 만든다면, 데이터에도 그에 맞는 국가·산업 규모의 수집 프로젝트가 필요하지 않느냐는 질문이다. 1) 인터넷은 AI에게 주어진 일회성 보조금이었다 원문에서 가장 좋은 비유는 인터넷을 “한 번뿐인 보조금"으로 보는 관점이다. 딥러닝은 수십 년 동안 사람들이 의도치 않게 쌓아 둔 책, 블로그, 이미지, 영상, 논문, 토론 기록을 거의 한꺼번에 이용했다. 공개 웹은 모델이 세상을 배우는 거대한 기본 교재였다. ...

systematicls의 X Article “What The New 100x Agentic Engineer Looks Like In The Era Of Fable & GPT 5.6”은 에이전틱 코딩의 생산성 격차가 어디서 생기는지 다룬 글이다. 핵심은 단순하다. 모델이 강해질수록 차이는 “AI가 코드를 잘 쓰는가"보다 사람이 원하는 결과와 trade-off를 얼마나 정확히 표현하는가에서 난다. TL;DR 핵심 정리 평준화는 일어나지 않는다: 에이전트가 코드를 대신 써도, 에이전트 뒤의 사람이 가진 맥락·판단·선호에 따라 결과 품질은 크게 갈린다. 새 병목은 선호 표현이다: 강한 모델은 구현 후보를 많이 만들 수 있지만, 어떤 후보가 우리 상황의 Pareto frontier에 가까운지는 사람이 알려줘야 한다. 선언형과 명령형을 구분해야 한다: 목표만 중요한 일은 선언형으로 맡기고, 실패 비용이 큰 핵심 경로는 명령형 제약으로 좁혀야 한다. 전략은 하네스에, 전술은 작업 지시문에: 조직 전체 원칙은 규칙·스킬·검증 루프로 저장하고, 프로젝트별 핵심 20%는 작업마다 분명히 적어야 한다. 1) 에이전트가 모두를 같은 수준으로 만들지는 않는다 초기에는 코딩 에이전트가 개발자 생산성을 평준화할 것이라는 기대가 있었다. 누구나 좋은 모델을 쓰면 비슷한 결과를 낼 수 있다는 생각이다. ...

Addy Osmani의 2026년 7월 글 **“Agentic Autonomy Levels”**는 AI 코딩 에이전트에게 일을 맡길 때 필요한 기준을 다룹니다. 핵심은 단순합니다. 에이전트가 더 많이 할 수 있다는 사실과, 실제로 더 많이 맡겨도 된다는 판단은 별개입니다. 원문: X article / Substack 공개본 핵심 핵심 정리 두 축: 단일 에이전트가 얼마나 멀리 가는지(agency)와 여러 에이전트를 얼마나 잘 조율하는지(orchestration)를 분리해서 봐야 한다. 6단계: Assist, Supervised action, Scoped task delegation, Goal-driven autonomy, Parallel delegation, Managed-by-exception orchestration으로 올라간다. 판단 기준: 높은 자율성은 “믿어도 된다"가 아니라 “틀렸을 때 빨리 알고, 쉽게 되돌리고, 독립 증거로 확인할 수 있다"에 가깝다. 실무 계약: 목표, 범위, 비목표, 권한, 중단 조건, 증거, 에스컬레이션, 예산을 작업 전에 정해야 한다. 최종 병목: 에이전트 시대에도 병목은 실행이 아니라 검증이다. 1) 자율성은 한 줄짜리 등급이 아니다 기존에는 “AI-native 수준"을 하나의 사다리로 표현하는 방식이 많았습니다. 하지만 Addy는 이제 그 방식만으로는 부족하다고 말합니다. ...

원문: A Field Guide to Fable: Finding Your Unknowns 참고: Know your unknowns — examples Fable 핵심 정리 핵심 주장: Fable급 모델에서는 “모델이 충분히 똑똑한가"보다 “내가 작업의 빈칸을 충분히 드러냈는가"가 결과를 좌우한다. 지도와 영토: prompt, skill, context는 지도이고 실제 코드베이스, 사용자 요구, 운영 제약은 영토다. 두 사이의 간격이 unknowns다. 네 가지 분류: known knowns, known unknowns, unknown knowns, unknown unknowns로 나누면 AI가 어디서 추측하게 되는지 보인다. 실무 방법: 구현 전에는 blindspot pass와 인터뷰, 구현 중에는 변경 기록, 구현 후에는 pitch나 quiz로 숨은 가정을 다시 꺼낸다. 1) 문제는 더 긴 prompt가 아니다 Thariq Shihipar의 글은 “AI에게 일을 잘 시키는 법"처럼 보이지만, 핵심은 단순한 prompt 기술이 아닙니다. 더 정확히는 내가 무엇을 모르는지 AI와 함께 발견하는 법에 가깝습니다. ...

Jesse Vincent의 Some new agentic patterns는 에이전트를 더 잘 쓰는 프롬프트 팁이 아니다. 핵심은 에이전트를 위한 제품을 만들 때, 실제 사용자 역할의 에이전트가 구현 에이전트와 직접 대화하게 하는 개발 방식이다. 원문: Some new agentic patterns Agent Loop 핵심 정리 새 패턴: 사람이 중간에서 피드백을 전달하지 않고, Claude Code가 Slackline을 통해 Ada-sen에게 직접 테스트를 요청했다. 사용자 모델: Sen 2.0은 단순 비서가 아니라 자기 도구, 메모리, 작업공간, 자격 증명을 가진 장기 실행 동료 에이전트로 설계된다. 보안 전제: Lethal Trifecta를 완전히 없애는 대신, 외부 통신 권한과 자격 증명 접근을 임시 서브에이전트와 중재자 에이전트로 분리한다. 실무 포인트: 코딩 에이전트에 맞는 컨텍스트 압축은 여러 대화를 동시에 이어가는 페르소나형 에이전트에는 맞지 않을 수 있다. 결과: Ada가 스펙을 검토하고, Claude가 구현하고, Ada가 다시 테스트하면서 품질 개선 목록과 수정 요청까지 생성했다. 1) 배경: Slack 안의 여러 에이전트 Prime Radiant에는 여러 에이전트가 Slack 안에서 일한다. Scribble은 문제 보고와 새 정보를 듣고 티켓을 열거나 내부 위키를 갱신한다. Nora는 go-to-market 업무를 돕는 주니어 동료처럼 행동한다. Spec-together는 멀티플레이어 Brainstorm 앱의 초기 실험이었다. ...

Laurie Voss는 AI가 프로그래밍이라는 직업을 없애고 있다기보다, 주니어 개발자가 성장하던 기존 경로를 먼저 무너뜨리고 있다고 본다. 동시에 소프트웨어를 만드는 능력은 마케터, 창업자, 교사, 분석가, PM 같은 더 넓은 직군으로 퍼지고 있다. 원문: AI has torched the market for junior programmers TL;DR 핵심 정리 주니어 시장의 충격이 가장 크다: Stanford Digital Economy Lab의 ADP 급여 데이터 기준 22~25세 개발자 고용은 2022년 말 고점 대비 19% 감소했다. 평균 지표는 착시를 만든다: 전체 소프트웨어 개발자 고용은 늘었지만, 주니어가 전체 개발자 중 작은 비중이라 평균만 보면 하락이 잘 보이지 않는다. 코드 작성 자체보다 판단의 가치가 커졌다: 명세대로 코드를 쓰는 역할은 줄고, 어떤 문제를 풀지 정하고 결과를 검증하는 역할은 상대적으로 강해지고 있다. 새로운 제작자는 이미 등장했다: GitHub 신규 계정, App Store 신규 제출, Vercel·Lovable·Replit 사용량은 비개발자도 AI로 소프트웨어를 만들기 시작했음을 보여준다. 가장 큰 위험은 성장 사다리의 단절이다: AI가 초급 코드를 대신 쓰면, 신입이 리뷰와 반복을 통해 시니어로 자라는 경로가 약해진다. 핵심 주장 이 글의 핵심은 “프로그래밍이 죽었다"가 아닙니다. 더 정확히는 프로그래밍이 특정 직함에서 보편 능력으로 이동하고 있다는 주장입니다. ...

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가 조직을 바꾼다는 말은 자주 인원 감축 이야기로 흘러갑니다. Miguel Carranza의 글은 방향을 다르게 잡습니다. 핵심은 사람을 덜 뽑자는 것이 아니라, 팀을 작게 쪼개 새로 합류한 사람이 더 많은 회의가 아니라 더 많은 병렬성을 만들게 하자는 주장입니다. 원문: AI shouldn’t shrink headcount. It should shrink teams Small Teams 핵심 정리 핵심 주장: AI의 조직 효과는 인원 감축보다 팀 크기 축소에 있다. 작은 팀은 결정권과 책임 소재가 뚜렷하다. 병목 이동: AI가 첫 구현과 낯선 코드 검토 비용을 낮추면, 중요한 일은 “코드를 누가 쓰는가"보다 “무엇을 만들고 언제 멈출지 판단하는가"가 된다. RevenueCat 사례: OCTO는 신뢰 높은 시니어 IC들이 새 베팅과 중요 프로젝트를 빠르게 검증하는 작은 조직 실험이었다. 제품팀 적용: 1~3명 엔지니어, 공유 PM·디자인, 명확한 Tech Lead 구조로 팀 수를 늘리고 회의 규모를 줄였다. 주의점: 작은 팀은 중복과 용량 리스크가 크다. 그래서 매니저는 모든 팀에 같은 시간을 쓰기보다 막힌 곳에 깊게 들어가야 한다. 1) AI는 채용 논리를 없애지 않고 팀 토폴로지를 바꾼다 Carranza가 먼저 선을 긋는 지점은 중요합니다. 작은 팀은 “AI가 있으니 사람을 덜 뽑자"는 말이 아닙니다. 오히려 채용이 늘어날 때 그 사람이 더 큰 회의에 흡수되지 않고, 새로운 실행 단위를 만들게 하자는 말입니다. ...

LinkedIn Engineering이 2026년 6월 18일 공개한 **“Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing”**는 AI 에이전트가 실제 대규모 서비스의 품질 관리를 어떻게 바꿀 수 있는지 보여주는 사례입니다. 원문: Quality Assurance Agent: Reimagining Software Quality with AI-Driven Autonomous Testing AI 핵심 정리 문제 배경: LinkedIn은 iOS, Android, Web, 36개 이상 언어, 사용자 유형, 멤버십, 실험 조합 때문에 전통적인 UI 자동화만으로 모든 변화를 따라가기 어렵다. 해결 방식: QA Agent는 selector에 의존하지 않고 VLM으로 화면을 읽으며, planner, analytical reasoning model, fine-tuned visual grounding model을 나눠 쓴다. 운영 구조: 안정적인 흐름은 deterministic replay로 빠르게 실행하고, 화면이 바뀌면 vision-based planning으로 넘어간다. 검증 장치: view tree, tracking log, action history, error detection pipeline, golden dataset을 통해 phantom bug보다 실제 버그 탐지를 우선한다. 현재 규모: LinkedIn은 350개 이상 테스트를 30분 주기로 실행하며, QA Agent가 200개 이상 유효 버그를 찾았다고 밝혔다. 1) 전통적인 UI 테스트가 막히는 지점 LinkedIn의 품질 문제는 단순히 화면이 많다는 수준이 아닙니다. 같은 기능이라도 사용자 유형, 언어, 멤버십, 실험군, 개인화 상태에 따라 다른 화면이 나옵니다. LinkedIn은 이 조합을 “하나의 앱이 아니라 수천 개의 permutation"에 가깝게 설명합니다. ...