본문으로 건너뛰기

주간 소식 모음: Harness², Claude Code 내장 플러그인 You should Know 등 (10.12 ~ 10.20)

서동명
4분 분량

10월 12일부터 10월 20일까지 읽고 본 소식을 모았습니다. AI 시대에 개발자에게 남는 일을 다룬 글을 여럿 읽었고, Google Research의 Harness²와 Claude Code 내장 플러그인 You should Know 소식도 함께 담았습니다.

AI 에이전트·코딩​

요즘 개발자들이 AI 때문에 진짜 빡치는 순간 (The Age of the Soft Skill 해설) (영상)​

  • 실력만 좋으면 괜찮던 시대는 끝났음
    • AI 가 사람을 표면으로 드러냄
    • 결과물을 AI가 잘 만들기 때문에, 기존에 결과물 뒤에 숨어있던 그 사람의 인성, 태도, 모습들이 더 잘 보이게됨
  • 미트 프록시 (meat proxy)
    • AI 답변을 프록시 하는 사람을 의미하는데, 2026년에 할 수 있는 "최악" 의 행동
    • 쓸데없이 시간만 낭비하게됨
    • AI 를 쓰지 말라는게 아니라, 다른 사람에게 답변할 때 핵심 부분만 요약, 정리하고 노이즈 버려서 잘 전달해야함
  • "쓰는 비용은 공짜" 이고 "읽는 비용은 여전히 높음"
    • AI 가 쓴 글을 그대로 넘기는건 "공유" 가 아니라 동료에게 일을 떠넘기는 행위
  • 일하기 좋은 사람은?
    • 말하는게 정확한가?
    • 답이 얼마나 빨리 오는가?
    • 물어본 것만 답변하는게 아니라, 그게 어떤 의미인지, 주변 영향 범위는 어디까지인지 고민하고 답변하는 사람 (맥락 파악)
    • 친절한 사람
      • 친절하지 않더라도 핵심 잘 전달하고, 일정 관리 잘하고, 잡소리 없는 사람도 일하기 편한 사람
  • -> 기존에는 소프트스킬이 약해도 실력이 뛰어나면 버틸 수 있었지만, 이제는 AI 가 하드스킬이 더 뛰어나기 때문에 소프트스킬이 더 중요함

코드를 쓰지도 읽지도 않는다면 소프트웨어 엔지니어는 무엇을 하나​

  • Clean Code의 저자 Uncle Bob이 더 이상 코드를 읽지 않는다고 말한 것을 두고, 코드를 쓰지도 읽지도 않는다면 소프트웨어 엔지니어는 무엇을 해야 하냐고 묻는 X 게시물
  • 소프트웨어 엔지니어는 항상 하던 일을 그대로 하면됨
    • 시스템의 구성과 구조가 견고하고, 유지보수 가능하도록 보장하며, 시스템의 동작이 사용자의 요구사항을 충족하도록 만드는 것
  • 컴파일러를 사용한다고 해서 바이너리 코드를 세세히 읽을 필요가 없는 것처럼, 반드시 코드를 상세하게 읽어야만 하는 것은 아님

Harness Engineering: How to Build AI Agents That Don't Fall Apart​

  • 에이전트가 반복해서 실패할 때 프롬프트나 모델을 바꾸는 대신 모델을 둘러싼 환경(harness)을 설계해야 한다는 X 아티클로, production harness가 맡는 7가지 역할과 체크리스트를 정리함

AI 네이티브 기업의 30가지 특징​

  • 도구 도입이 아니라 운영 구조의 전면 재설계를 전제
    • 모두가 빌더, 3개월마다 워크플로우를 버리고 다시 상상할 각오, 사람의 판단은 프로세스의 첫 단계와 마지막 단계에만 투입, 모든 것을 기록하고, 인프라를 구축하고.

Claude Code 내장 플러그인 You should Know — 놓치기 쉬운 출력을 다시 알려주기​

  • 보조 에이전트가 지켜보다가, 사용자나 Claude 가 놓쳤을 법한 것을 알려주는 기능

    /plugin enable cc-plugin-you-should-know@builtin

  • Claude Mods 위에서 동작하는 내장 모드

Harness² — 작업마다 스스로 다듬어지는 에이전트 하네스 (Google Research)​

  • 모델의 가중치를 변경하지 않고 재귀적 학습을 통해 스스로 최적화를 진행
  • 작업 단위 재귀
    • Propose-Probe-Compose 단계를 통해 현재 작업의 실행 하네스를 개선
    • 동일한 작업에 대한 그 효과를 조사하며, 정답 피드백 없이 실행 간의 행동 대조를 통해 개선
  • 하네스 단위 재귀
    • 각 작업이 끝나면 결정된 하네스와 여러 실행 과정에서 얻은 결과들을 저장하고, 다음 하네스를 개선할 때 선반영

AI·LLM 엔지니어링​

LLM이 전문가를 대체 못 하는 이유는 실력이 아니라 비용이다​

  • 코드 작성은 이제 AI 가 더 잘하기 때문에, 개발자는 코드 대신 규칙을 정하고, 아키텍처를 결정
  • LLM 은 평균 (범용적인 결과) 을 주기 때문에, 그 위에 개인 (또는 회사) 의 기준을 쌓을 수 있어야함
  • 도구를 사용하고 경쟁에 뛰어드는 참가자가 되기 위한 노력
    1. 의견을 갖는 연습 (기준이 없는것보다 틀린 기준이 더 낫다)
    2. 의견을 파일로 옮기고, 도구가 그대로 하는지 확인 (작성만 하는것이 아니라, 도구가 기준대로 움직이는지 보는 것까지가 한 세트)
    3. 비공개 기준이 쌓이는 곳에서 일하기 (공개된 지식은 모델이 다 가져가기 때문에, 공개되지 않은 지식이 있는 곳에서 일하기)

경력 개발자 기술면접 AX 질문 8개 — RAG·인퍼런스 비용·데이터 유출·LiteLLM​

  • 경력직 개발자 기술면접에서 많이 묻는 AX 관련 질문 8개(RAG와 Fine-tuning 선택, 인퍼런스 비용 절감, 외부 LLM API로 인한 데이터 유출 방어, LiteLLM을 proxy 레이어로 두는 이유 등)를 모은 Threads 글

LLM 역량 인식의 깔때기 — 4개 층과 3개 원인 (Karpathy)​

  • 미경험: 60억 (~75%)
    • LLM 을 거의 접한적 없음
  • 가벼운 사용자: 10~20억 (~20%)
    • 무료 등급의 ChatGPT 류를 가끔, 비정기적으로 사용함:
    • 챗봇, 검색, 글쓰기 보조도구 정도로 사용
  • 전문 사용자: 2,000만명 (0.2%)
    • 수학과 코딩, 최전선에서 LLM 을 전문적으로 사용
    • 몇 주, 몇 달이 걸리던 크고 복잡한 프로젝트들을 에이전트가 프롬프트 하나로 완료할 수 있다는것을 보게됨
  • 내부자: ~5,000명 (0.00006%)
    • AI 기업 안에서 최신 시스템을 다루며, 수천 개의 에이전트가 몇 주에 걸쳐 대형 프로젝트에서 협업하는 모습을 보게됨
    • 사람의 이해가 병목이 되기 시작함

AI 경쟁의 다음 전장은 회사의 기억 — Cerebras 지식베이스​

  • 원칙: 데이터는 흩어져 있는게 정상
    • 단일 진실 공급원은 현실에서 거의 동작하지 않는다고봄
    • 정보는 편하고 손에 익은 곳에 생김
  • 지식 베이스 구조 (3가지를 제공)
    • 내부 데이터를 수집하고 저장하는 플랫폼
    • 해당 데이터를 쿼리하는 플랫폼
    • 인증과 권한 부여를 적용하고 감사 및 분석 기능을 갖춘 계층
  • 여러 소스의 임베딩, 원본 데이터, 요약, 메타데이터는 하나의 Postgres 테이블에 저장
  • 다양한 검색 기법을 결합하여 빠르게 탐색할 수 있도록 구성
  • 실제 데이터에 유연하면서도 성장하는 데이터를 유지할 수 있는 구조화된 검색 경험을 완성함

개발자는 끝났다 — 코드 작성 이후에 남는 책임​

  • “코드만 쓰는 개발자, 이슈 티켓만 치던 개발자는 끝났다”

  • 대부분 비즈니스는 비즈니스 전략에 의해 결정되고, IT 비즈니스의 핵심인 소프트웨어도 많고 많은 구성 요소 중 하나일 뿐임. 하지만 개발을 잘 못해서 망하는 비즈니스는 수두룩함

    • 잘못된 설계 판단으로 쌓인 더 이상 갚지 못하는 기술 부채, 섣부른 기술 솔루션 도입, 잘못된 엔지니어링 팀 인사 구성 등.
    • 잘하는 개발자는 이미 이전부터 당장 주어진 요구사항 이상을 봄

  • 갚을 수 있는 부채는 자산이 되지만, 갚지 못하는 부채는 그냥 망하는 것임

  • The Feynman Problem-Solving Algorithm

    1. write down the problem;
    2. think very hard;
    3. write down the answer;

  • 상상력은 아무거나 많이 만들어내는 능력이 아니라, 풀어야 할 문제를 다시 보고, 전달받은 요구사항 밖의 다른 답을 그려보는 능력임

    “An engineer who cares at least as much about the what and the why as the how. So what are they doing and who are they doing it for?”

  • 프로덕트가 어떤 과정으로 동작하는지에 대한 멘탈 모델을 가지고 있어야함. 데이터가 어디에서 들어와 어떤 상태를 거쳐 사용자에게 도달하는지, 그 사이에 어떤 의존성과 실패 가능성이 있는지를 설명할 수 있어야 함

    • AI 시대에 개발자의 책임은 코드를 작성하는것에서, 어떻게 검증할지, 어떻게 결정할지 정하는 방향으로 이동함

    "삶의 ‘왜’를 가진 사람은 거의 모든 ‘어떻게’와도 살아갈 수 있다."

    — 프리드리히 니체, 《우상의 황혼》, 「잠언과 화살」 12

그 밖의 소식​