에이전트 성능, 모델보다 하네스가 갈라놓을 때: Flash·Boost·Skills로 보는 세 층 구조 | DAKER 커뮤니티
코딩 에이전트가 기대만큼 일하지 않을 때, 먼저 모델부터 바꾸는 경우가 많습니다. 하지만 Google Cloud Tech의 Agent Factory 에피소드 Agent Harnesses Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor는 다른 지점을 짚습니다. 병목은 모델 자체보다, 그 모델을 둘러싼 에이전트 하네스에 있을 수 있다는 이야기입니다.
지금 이 관점이 중요한 이유는 분명합니다. 해커톤이든 팀 레포든, 한 번의 긴 프롬프트보다 반복 가능한 환경이 성능을 더 오래 지탱하기 때문입니다. 영상의 설명을 따라가 보면, 에이전트를 잘 쓰는 팀이 왜 문서·검증·지식 구조를 먼저 손보는지 자연스럽게 이해하게 됩니다.
에이전트는 모델만이 아니라 하네스까지 포함합니다
영상에서 제시하는 정의는 단순합니다. AI 에이전트 = 대규모 언어 모델 + 에이전트 하네스입니다. 여기서 하네스는 에이전트 안에서 LLM이 아닌 나머지 전부를 뜻합니다. 예시로는 Gemini Flash를 모델로, Google Antigravity를 하네스로 듭니다.
문제는 모델이 아니라, LLM을 둘러싼 에이전트 하네스일 수 있습니다.
이 설명은 간단한 질문과 외부 정보가 필요한 질문을 나누는 대목에서 더 분명해집니다. 하늘이 왜 파랗게 보이는지, 농담 하나를 말해 달라는 요청은 모델 내부 지식만으로도 답할 수 있습니다. 반면 비를 입어야 할지 같은 질문은 현재 날씨라는 바깥 정보가 필요합니다. 이때 하네스가 외부 정보를 가져오고, 원래 질문과 함께 다시 모델에 넣어야 답이 성립합니다. 우리가 AI와 대화한다고 느끼는 순간에도, 실제로는 모델 단독이 아니라 에이전트 전체와 상호작용하는 경우가 많다는 설명입니다.
하네스 엔지니어링은 프롬프트를 길게 쓰는 일이 아닙니다
이 에피소드에서 Googler Ryan Leopo는 하네스라는 말을 퍼뜨린 인물로 소개됩니다. 그는 2026년 2월 에세이에서 에이전트 우선 소프트웨어 엔지니어링을 다뤘고, 인터뷰에서는 작년 5월 이후 에디터를 거의 열지 않았다는 식으로 에이전트에 코드를 맡기는 실험을 이어 왔다고 말합니다.
여기서 핵심은 하네스 엔지니어링의 목표가 이른바 게으른 프롬프터에 가깝다는 점입니다. 프롬프트 앞머리에 설명을 계속 덧붙이는 대신, 모델이 부팅할 때마다 원하는 품질 기준을 스스로 찾을 수 있도록 도구와 맥락, 환경을 미리 정리해 두는 방식입니다. 문서, 규칙, 검증이 레포에 남아 있어야 한다는 뜻이기도 합니다.
모델이 더 똑똑해져도 내가 무엇을 원하는지까지 기본값으로 알아내지는 않습니다.
그래서 개입은 즉석 프롬프트보다 환경과 자동화 쪽으로 옮길수록 반복 비용이 낮아집니다. 영상에서 제시하는 흐름은 같은 프롬프트를 다시 시도하는 단계에서 시작해, 문서를 추가하고, 그 문서를 가리키는 agents.md를 두고, 정적 검증기와 테스트를 붙인 뒤, 평가(eval)로 올리는 방향으로 이어집니다. 린터, 코딩 컨벤션, 익숙한 관측 도구도 에이전트 우선 워크플로에 잘 맞는다고 설명합니다. 실패가 보이면 왜 그런 산출물이 나왔는지 되짚고, 같은 실수를 반복하지 않도록 다시 환경에 반영하는 식입니다.
좋은 에이전트는 긴 시간 축에서 같은 기준을 유지합니다
영상은 조직의 일이 한 번에 끝나지 않고 반복으로 쌓인다는 점도 강조합니다. 에이전트가 그 생산 과정에 제대로 참여하려면, 조직이 좋은 결과물이라고 보는 기준에 계속 다시 맞춰져야 합니다. 다양한 팀원이 에이전트 환경에 기여하면, 각자의 전문성이 환경에 누적된다는 비유도 여기서 나옵니다.
결국 중요한 것은 한 번 잘 되는 데모가 아니라, 시간이 지나도 같은 품질 기준을 따라가게 만드는 구조입니다. 해커톤이나 바이브코딩에서도 이 관점은 그대로 통합니다. 제출 직전에 모델만 바꾸는 것보다, 팀이 합의한 규칙과 검증, 지식이 레포에 남아 있는 편이 더 안정적입니다.
영상이 정리한 주간 스택: 모델·하네스·지식의 세 층
후반부에서 Ryan은 주간 스택을 세 층으로 정리합니다. 아래 내용은 영상 서술 기준이며, 가격이나 설치 명령, 별점의 실시간 값은 여기서 단정하지 않습니다.
모델 층
에이전트는 한 작업 안에서 디렉터리를 보고, 함수를 고치고, 단위 테스트를 돌리는 일을 수십 번 반복할 수 있습니다. 영상 표현으로는 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 같은 시스템을 고정해 두고, 나오는 즉시 가장 좋은 모델을 쓰며, 실패를 관찰한 뒤 코드와 문장으로 환경을 다듬으라고 조언합니다. 여기서 말하는 적용 엔지니어의 역할은 능력 과잉, 즉 모델은 이미 충분히 좋은데 우리가 실제 유용한 일로 끌어내지 못하는 상태를 줄이는 데 가깝습니다.
실패를 관찰한 뒤, 코드와 문장으로 환경을 다듬는 일이 중요합니다.
이 맥락은 Google Cloud를 에이전트가 잘 다루는 컴퓨터로 만들려는 동기와도 이어집니다. 결국 모델 교체보다 먼저 볼 것은, 에이전트가 일할 수 있는 환경이 얼마나 잘 정리되어 있는가입니다.
이 영상이 말하지 않는 것
다만 이 영상이 특정 하네스가 모든 팀에서 항상 최고라고 결론내리는 것은 아닙니다. Cursor·Claude Code·Antigravity를 나란히 언급하는 이유도 한 제품을 홍보하기 위해서가 아니라, 스택을 어떻게 짜는지 보여 주기 위해서입니다.
출처는 Google Cloud Tech 채널의 Agent Factory 에피소드 Agent Harnesses Explained: Inside the Stack Behind Antigravity, Claude Code & Cursor이며, 업로드 기준일은 2026년 9월 14일입니다.
레포에서 먼저 보일 것은 세 층의 위치입니다
DAKER에서 데모를 만들 때도 실무 포인트는 비슷합니다. 한 번의 긴 프롬프트보다, 세 층이 레포에 보이는가를 먼저 점검하는 편이 실패를 더 싸게 만듭니다. 빠른 루프용 모델 설정이 있는지, 오케스트레이션과 검증이 들어간 하네스 경로가 있는지, 도메인 지식을 불러올 Skills나 문서 위치가 정리되어 있는지를 한 페이지에서 볼 수 있으면 됩니다.
agents.md에 문서 링크를 걸고, 린터와 테스트가 에이전트 루프에 들어가게 두고, 클라우드나 프레임워크 지식은 Skills 같은 온디맨드 층으로 분리하는 방식이 이 영상의 실무 감각에 가깝습니다.
참고 자료
관련 플랫폼 안내: 해커톤·팀·커뮤니티는 https://daker.ai, 알고리즘 경진대회는 https://dacon.io에서 확인하실 수 있습니다.
여러분의 레포에는 모델, 하네스, 지식의 세 층이 지금 얼마나 분명하게 드러나 있나요?