모델만 갈아끼우지 않습니다 — 플래시·Boost·Skills 세 층을 오늘 레포에 잡으십시오 | DAKER 커뮤니티

코딩 에이전트가 막히면, 많은 팀은 더 큰 모델로 갈아끼웁니다. Google Cloud Tech의 Agent Factory 에피소드 「Agent Harnesses Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor」는 다른 질문을 합니다. 문제는 모델이 아니라, LLM을 둘러싼 에이전트 하네스일 수 있습니다. 채널은 Google Cloud Tech이고, 업로드 기준일은 2026년 9월 14일입니다.

영상에서 말하는 정의는 짧습니다. AI 에이전트 = 대규모 언어 모델 + 에이전트 하네스입니다. 하네스는 에이전트 안에서 LLM이 아닌 나머지 전부입니다. 예시로 Gemini Flash를 모델로, Google Antigravity를 하네스로 듭니다. 「하늘을 왜 파랗게 보이지?」「농담 하나」처럼 이미 답이 있는 질문과 달리, 「비를 입어야 할까?」는 모델만으로는 답할 수 없습니다. 하네스가 날씨 같은 외부 정보를 가져온 뒤, 원래 질문과 새 정보를 다시 모델에 넣어야 합니다. 우리가 AI와 대화한다고 느끼는 순간에도, 실제로는 에이전트(모델+하네스)와 상호작용하는 경우가 많다고 설명합니다.

이 에피소드에서 Googler Ryan Leopo는 하네스라는 말을 퍼뜨린 당사자로 소개됩니다. 그는 2026년 2월 에세이에서 에이전트 우선 소프트웨어 엔지니어링을 다루었고, 인터뷰에서는 「작년 5월 이후 에디터를 거의 열지 않았다」는 식으로 에이전트에 코드를 맡기는 실험을 이어 왔다고 말합니다. 하네스 엔지니어링의 목표는 「게으른 프롬프터」가 되는 쪽에 가깝습니다. 모델이 부팅할 때마다 내가 원하는 품질 기준을 스스로 찾도록, 도구와 맥락·환경을 미리 큐레이션합니다. 프롬프트 앞에 설명을 잔뜩 싣는 대신, 문서·규칙·검증이 레포에 남아 있게 만드는 일입니다. 모델이 더 똑똑해져도 「내가 무엇을 원하는지」를 기본값으로 알아내지는 않는다는 관찰이 그 근거입니다.

개입은 오른쪽(즉석 프롬프트)에서 왼쪽(환경·자동화)으로 옮길수록 싸게 반복됩니다. 영상에서 말하는 스펙트럼은 대략 이렇게 이어집니다. 같은 프롬프트를 다시 시도하기 → 문서 추가 → 그 문서를 가리키는 agents.md → 정적 검증기와 테스트 → 평가(eval)로 올리기. 린터·코딩 컨벤션·익숙한 관측 도구 형태도 「에이전트 우선」 워크플로에서 잘 먹힌다고 합니다. 학습 데이터에 잘 잡혀 있고, 수집·집계를 검증된 도구로 옮긴 뒤 CLI로 모델에 밀도 높은 맥락을 주는 패턴이 잘 맞기 때문입니다. 실패가 보이면 「왜 그런 산출물이 나왔는지」를 되짚어, 같은 실수를 반복하지 않도록 환경에 되먹입니다.

긴 시간 축도 강조됩니다. 조직의 일은 한 번에 완성되지 않고 반복으로 쌓입니다. 에이전트가 그 생산에 제대로 참여하려면, 산출물을 조직이 좋은 것으로 보는 「황금 실」에 계속 다시 맞춰야 합니다. 다양한 팀원이 에이전트에 기여하면 프론트·백엔드 같은 강점이 쌓인다는 비유도 나옵니다. 다만 공개 본문에서는 게임 비유로 늘리지 않고, 「필요한 전문성을 환경에 누적한다」는 실무 의미만 가져가겠습니다.

후반부는 주간 스택을 세 층으로 정리합니다. 아래 숫자와 제품명은 영상 서술 기준이며, 가격·설치 한 줄 명령·별점의 실시간 값은 여기서 단정하지 않습니다.

• 모델 층 — 에이전트는 디렉터리를 보고, 함수를 고치고, 단위 테스트를 돌리는 일을 한 작업에서 수십 번(영상 표현으로는 20·40·60회) 반복할 수 있습니다. 그래서 빠른·비용 효율적인 플래시급 모델(에피소드에서는 Gemini 3.8 Flash를 일일 드라이버로 소개)이 실시간 루프를 실용적으로 만듭니다. 「가장 무거운 추론 모델만」이 항상 정답이 아니라는 점이 핵심입니다.
• 하네스 층 — Antigravity의 Boost는 한 문장으로 「단일 모델을 조율된 팀으로 바꾸는 슬래시 명령」입니다. 오케스트레이터가 있고, 전문 서브에이전트를 병렬로 돌리며, 코드베이스에 닿기 전 독립 검증 패스를 둡니다. 일상적인 UI 추가·코드베이스 탐색에는 기본 에이전트를 쓰고, 복잡한 엔지니어링에 Boost를 아껴 쓰라고 합니다. 영상은 실행 모드 비교 표로 「언제 Boost를 쓸지」를 보여 줍니다.
• 지식 층 — Google Skills는 필요할 때 불러오는 큐레이션된 도메인 지식입니다. MCP 서버만도 아니고, 무거운 플러그인도 아니라고 구분합니다. 영상 기준 저장소는 GitHub 스타가 약 1만 9천을 넘었고, Google Cloud·Firebase·Flutter·Maps 등 100개 넘는 스킬을 담으며, Claude Code·Codex·Antigravity처럼 하네스에 묶이지 않는다고 소개합니다. 클라우드 인프라를 에이전트가 「추측」하지 않게 막는 층입니다.

Ryan은 「나는 하네스를 직접 만들어 본 적이 없다」고도 말합니다. Antigravity 같은 시스템을 고정해 두고, 나오는 즉시 가장 좋은 모델을 쓰며, 실패를 관찰한 뒤 코드와 문장으로 환경을 다듬으라는 조언입니다. 능력 과잉(capability overhang) — 모델은 이미 좋은데 우리가 뽑아내는 유용한 일이 따라가지 못하는 상태 — 을 줄이는 쪽이 적용 엔지니어의 일이라고도 합니다. Google Cloud를 「에이전트가 잘 다루는 컴퓨터」로 만들려는 동기와도 이어집니다.

이 영상이 주장하지 않는 것도 분명히 하겠습니다. 특정 하네스가 모든 팀에서 항상 최고라는 결론은 없습니다. Cursor·Claude Code·Antigravity를 나란히 언급하는 이유는 「스택을 어떻게 짜는지」를 보이기 위함이지, 한 제품을 홍보 문장으로 단정하기 위함이 아닙니다. 또한 유튜브 링크는 본문에 두지 않습니다. 제목과 채널명으로만 출처를 밝힙니다.

해커톤·바이브코딩에서도 같은 축이 통합니다. 제출 직전에 모델만 바꾸기보다, 팀이 합의한 규칙·검증·지식이 레포에 남아 있어야 에이전트가 긴 시간 동안 같은 품질 기준을 따라갑니다. DAKER에서 데모를 만들 때도 「한 번의 긴 프롬프트」보다 「세 층이 레포에 보이는가」를 먼저 점검하는 편이 실패를 싸게 만듭니다.

오늘 한 가지 행동: DAKER나 해커톤 레포를 열고, (1) 빠른 루프용 모델 설정, (2) 오케스트레이션·검증이 있는 하네스 경로, (3) 도메인 지식을 불러올 Skills/문서 위치를 한 페이지에 적어 두십시오. 프롬프트 문장을 늘리기 전에 세 층이 어디에 있는지부터 보이게 만드는 것이 이 영상의 실무 포인트입니다. agents.md에 문서 링크를 걸고, 린터·테스트가 에이전트 루프에 들어가게 한 뒤, 클라우드·프레임워크 지식은 Skills 같은 온디맨드 층으로 분리해 보십시오.

관련 플랫폼 안내: 해커톤·팀·커뮤니티는 daker.ai, 알고리즘 경진대회는 dacon.io에서 확인하실 수 있습니다.