하네스 엔지니어링 완벽 해설: Antigravity, Claude Code, Cursor를 지탱하는 스택의 비밀

URL: https://www.youtube.com/watch?v=PzhJ3IWrN9Q
날짜: 2026-09-23
채널: Tech Bridge

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코딩 에이전트의 성능은 모델 하나의 지능보다 모델을 둘러싼 하네스(harness), 도구(tools), 맥락(context), 지식(knowledge)을 어떻게 설계하느냐에 좌우된다.==

• AI 에이전트는 대규모 언어 모델(LLM)에 에이전트 하네스를 결합한 시스템이다.
• 하네스는 모델의 의도를 파일 읽기, API 호출, 명령 실행, 메모리 검색, 검증 루프로 연결한다.
• 장기 자율성을 얻으려면 프롬프트를 길게 쓰는 대신 문서·도구·검증·관측성을 모델이 스스로 발견하도록 환경에 배치해야 한다.
• 실제 개발 스택은 모델 레이어, 하네스 레이어, 지식 레이어가 맞물릴 때 빠른 반복과 전문성, 안전성을 함께 얻는다.

핵심은 더 무거운 모델을 고르는 데 있지 않다. 좋은 결과의 기준을 문서화하고, 에이전트가 그 기준을 발견하고 실행하고 검증하는 경로를 만든 뒤, 작은 변경을 반복해서 신뢰 범위를 넓히는 데 있다.

1. AI 에이전트는 LLM과 하네스의 결합이다

에이전트 하네스(agent harness)는 LLM을 둘러싸서 텍스트 입력과 텍스트 출력만 가능하던 모델에 환경과 행동 능력을 부여하는 모든 구성 요소다.

1.1. 모델만으로 해결되는 질문과 하네스가 필요한 질문

1. LLM이 이미 알고 있는 답변

   1. “하늘은 왜 파란가?”, “농담 하나 해줘” 같은 질문은 모델이 학습한 지식만으로 답할 수 있다.
   2. 이 경우 모델은 추가 조사나 외부 행동 없이 단어를 생성하면 된다.

2. 환경 정보가 필요한 질문

   1. “비옷을 입어야 할까?”라는 질문에는 현재 날씨가 필요하므로 LLM 혼자서는 답을 확정할 수 없다.
   2. 하네스는 질문을 모델에 전달하고, 모델이 “날씨를 확인해 달라”는 행동 출력을 내놓으면 날씨 도구나 API를 실행한다.
   3. 하네스는 “맑고 기온이 98도다”라는 새 정보를 원래 질문과 함께 모델에 다시 넣는다.
   4. 모델은 “맑고 98도이므로 비옷이 필요 없다”라는 최종 답을 생성한다.

3. 하네스의 정의

   1. 하네스는 LLM을 감싸서 파일 읽기, API 호출, 명령 실행, 메모리 관리 같은 능력을 연결하는 실행 계층이다.
   2. 따라서 사용자가 AI와 상호작용할 때 실제로 마주하는 것은 순수한 LLM이 아니라 LLM과 하네스가 결합된 에이전트다.
   3. Gemini Flash와 Google Antigravity를 예로 들면 Gemini Flash가 모델이고 Google Antigravity가 하네스다.

1.2. Ryan Leupold가 말하는 하네스 엔지니어링

1. 용어가 등장한 배경

   1. Google의 Ryan Leupold는 코딩 에이전트를 완전 자율적으로 만드는 방법을 연구하면서 하네스라는 용어와 관련 작업을 발전시켰다.
   2. 2026년 2월 코딩 에이전트에 관한 작업을 공개했고, 이 개념이 업계 전반으로 빠르게 퍼졌다.
   3. Tilda는 Ryan의 “에이전트 우선 세계에서 Codex 활용하기(Leveraging Codex in an Agent-First World)” 에세이를 소프트웨어 엔지니어링의 미래를 생각하는 사람이라면 읽어야 할 글로 평가했다.

2. 직접 코딩하지 않는 실험

   1. Ryan은 2025년 5월 무렵부터 프로덕션에 들어갈 코드를 직접 편집하는 에디터를 사실상 열지 않았다고 말했다.
   2. Tilda도 자신의 방식으로 직접 코딩하지 않은 기간이 8주라고 덧붙였다.
   3. 이 방식은 자연어로 사양(specification)을 쓰고 에이전트가 구현하게 만든다는 점에서 편리하지만, 사람이 결과 코드를 자세히 읽지 않고 프로덕션에 넣는 일은 여전히 불안감을 준다.

3. 모델이 좋아져도 욕구를 자동으로 알지는 못한다

   1. 모델이 더 똑똑해지고 지시를 더 잘 따르는 현상은 전제로 삼아야 한다.
   2. 그러나 모델이 저절로 사용자가 원하는 ‘좋은 결과’를 더 잘 아는 것은 아니다.
   3. 하네스 엔지니어링은 모델 주변의 맥락과 환경을 큐레이션해 모델이 부팅할 때마다 무엇을 원하는지 자연스럽게 이해하도록 만드는 작업이다.
   4. 모델이 좋은 결과의 기준에 더 깊이 고정될수록 더 복잡한 일을 맡길 수 있다.

4. 게으른 프롬프터가 되기

   1. Ryan은 자신을 “믿을 수 없을 만큼 게으른 프롬프터”가 되고 싶은 사람이라고 표현했다.
   2. 도구와 맥락을 충분히 제공해 모델이 스스로 근거를 확보하게 했다면, 그 내용을 매번 프롬프트 앞부분에 장황하게 넣을 필요가 없다는 뜻이다.
   3. 모델에게 무엇을 말할지보다 모델이 스스로 찾아 읽고 실행할 수 있는 환경을 만드는 일이 더 오래가는 레버리지(leverage)가 된다.

1.3. 소프트웨어 공학 관행을 에이전트 환경으로 옮기기

1. 모든 좋은 관행을 왼쪽으로 이동하기

   1. 린터(linter), 명확한 코딩 규칙, 문서, 정적 검증기(static verifier), 테스트, 평가(evals) 등 확장 가능한 엔지니어링 관행은 에이전트 우선 워크플로에도 그대로 유효하다.
   2. 가장 단순한 개입은 결과가 나쁠 때 프롬프트를 바꾸지 않고 다시 시도하는 것이지만, 이 방식은 팀원과 시간 전체로 확장되지 않는다.
   3. 문서를 추가하고, agents.mmd처럼 관련 문서를 가리키는 안내 파일을 넣고, 정적 검증기와 테스트를 배치한 뒤, 궁극적으로 검증된 평가를 모델 개발 조직에 돌려보내는 식으로 개입 지점을 앞당긴다.

2. 시프트 레프트(shift left)의 의미

   1. 모델에 주는 개입을 소프트웨어 개발 과정에서 더 이른 시점에, 더 싸고 자동화된 형태로 배치하는 것이 시프트 레프트다.
   2. 프롬프트에 텍스트를 덧붙이는 일은 가장 늦고 오른쪽에 가까운 개입이다.
   3. 모델이 문서 코퍼스를 탐색하고 필요한 맥락을 스스로 찾아가도록 도구와 탐색 기능을 주면 더 왼쪽에 있는, 재사용 가능한 개입이 된다.
   4. 에이전트는 텍스트를 좋아하고 텍스트 위에서 작동하므로, 점점 더 정교한 자동화 방식으로 텍스트를 제공하는 설계가 특히 잘 맞는다.

3. 관측성과 결정성의 결합

   1. PromQL처럼 이미 널리 쓰이는 관측성(observability) 언어로 문제를 표현하면 모델이 학습 데이터에서 충분히 접한 패턴을 활용할 수 있다.
   2. 관측성 데이터의 수집과 집계를 검증된 일류 도구에 맡기고, CLI로 모델에 조밀한 맥락을 주면 자유로운 추론을 결정적인 도구 실행으로 바꿀 수 있다.
   3. 기존 소프트웨어 공학의 고수준 관행을 모델이 실행 가능한 도구 조합으로 바꾸면, 현재 코드 생성 비용이 낮기 때문에 과거보다 훨씬 많은 자동화를 시도할 수 있다.

4. 문서 구조도 하네스의 일부다

   1. Ryan은 문서의 본문 흐름을 깨지 않도록 링크를 인라인으로 흩뿌리지 않고 문단이나 목록 가까이에 앵커(anchor)처럼 배치한다.
   2. 앵커가 관련 텍스트와 가까운지 검사하는 테스트를 작성해 에이전트가 본문을 효율적으로 읽게 한다.
   3. 이 방식은 Ryan의 취향에서 출발한 다소 특이한 코드지만, 사람에게는 읽기 쉽고 에이전트에게는 맥락 손실이 적으며 팀이 검토하기도 쉽다.
   4. 사람이 코드를 직접 작성하지 않는 만큼 최종 산출물은 더 읽기 쉬워야 한다.

5. 최종 산출물을 보고 원인을 거슬러 올라가기

   1. 에이전트가 코드, Google Docs, Google Sheets 중 무엇을 만들든 최종 산출물을 먼저 보고 합리적인지 판단하는 것이 기본 검토 방식이다.
   2. 결과가 이상하면 어떤 맥락과 잘못된 추론이 그 산출물을 만들었는지 되짚을 수 있어야 한다.
   3. Ryan이 “말 안 듣는 에이전트의 머리를 한 대 때려 같은 실수를 반복하지 않게 한다”고 농담한 표현은, 실패 결과를 환경과 검증 규칙 개선으로 연결한다는 뜻이다.

1.4. 긴 시간 범위의 자율성을 만드는 반복 루프

1. 조직의 ‘황금 실마리(golden thread)’에 결과를 계속 맞추기

   1. Google이라는 사업도 한 번의 작업으로 완성되지 않고 수년간 많은 사람이 반복적으로 기여해 만들어졌다.
   2. 에이전트를 조직의 작업 생산에 참여시키려면 에이전트가 만드는 산출물을 조직이 ‘좋다’고 여기는 기준선에 계속 재정렬해야 한다.
   3. 하네스 엔지니어링은 에이전트를 기준선으로 되돌리는 점점 정교해지는 기법들의 모음이다.

2. 작은 PR에서 큰 루프로

   1. 먼저 사람이 검토하기 쉬운 작은 PR을 만든다.
   2. 작은 PR이 검토하기 쉽다면 그 검토 자체의 일부를 에이전트에게 맡길 수 있다.
   3. 변경 범위의 상태 공간(state space)을 좁히면 사람 개입을 줄이면서 더 긴 시간 범위의 작업을 실행할 수 있다.
   4. 작은 변경을 끝에서 끝까지 쌓아도 결과가 합리적이라는 신뢰가 생기면, 언어 전체 마이그레이션처럼 큰 작업도 실행 가능해진다.

3. 에이전트 팀의 전문성 조합

   1. Ryan은 새 팀원으로 React 아키텍트를 추가하면 프론트엔드 아키텍처와 성능에 투자되는 주의력이 RPG 캐릭터의 능력치처럼 올라간다고 비유했다.
   2. 서로 다른 전문성을 가진 에이전트들이 하나의 레버리지 생산자에 기여하면 각자의 강점을 합친 균형 잡힌 에이전트를 만들 수 있다.
   3. 백엔드 아키텍처와 프론트엔드 성능을 모두 요구하는 미지의 업무를 사람이 스프린트 초에 나눠주지 않아도 된다.
   4. 에이전트가 자신이 할 일을 먼저 분류하고 필요한 전문 맥락을 동적으로 찾아 활성화하는 능력이 높은 자율성의 핵심이다.

4. 모호성을 멀리까지 벗겨내기

   1. 주니어 엔지니어에게는 작은 명확한 일을, 시니어 엔지니어에게는 더 모호한 업무를, 스태프 엔지니어에게는 조직의 6개월 뒤 문제를 맡기는 것처럼 에이전트의 루프도 단계적으로 키운다.
   2. “얼마나 먼 미래까지 모호성을 벗겨내 에이전트가 그 업무의 자율성을 갖게 할 수 있는가?”가 자율성의 크기를 측정하는 질문이다.
   3. 사람이 프롬프트와 세부 작업 지시를 계속 붙잡지 않고 산출물만 감독하려면, 이 루프 크기를 작은 업무에서 큰 비즈니스 로직으로 확장해야 한다.

1.5. 모델을 고정하지 말고 도구와 맥락에 투자하기

1. 직접 하네스를 만들 필요는 없다

   1. Ryan은 자신이 별도의 하네스를 만들어 본 적이 없다고 말했다.
   2. 여기서 말하는 하네스 엔지니어링은 새로운 프레임워크를 만드는 일이라기보다, 기존 에이전트 시스템에 높은 야망을 적용하고 실패를 관찰하며 환경을 개선하는 일이다.
   3. 새 모델이 나오는 즉시 가장 좋은 모델을 선택하고, 기존에 가능하다고 생각한 한계를 적극적으로 버려야 한다.

2. 과도한 스캐폴딩을 피하기

   1. 에이전트가 실패한 이유를 에이전트와 자기 자신에게 질문하고, 코드와 문서를 값싸게 만들 수 있다는 점을 이용해 실패가 재발하지 않도록 환경을 고친다.
   2. 파일 읽기, GPT 호출, 임의 명령 실행은 사실상 모든 하네스가 제공하는 공통 인터페이스다.
   3. 품질 개선을 도구와 맥락에 집중하면 모델이 바뀌어도 계속 사용할 수 있는 부분에 레버리지가 쌓인다.
   4. 모델을 지나치게 고정된 규칙으로 둘러싸면 모델이 좋아졌을 때 불필요한 제약이 되고, 버리기 아까운 매몰비용(sunk cost fallacy)에 빠질 수 있다.

3. Google Cloud를 에이전트의 컴퓨터로 만들기

   1. Ryan은 현재 Google Cloud에서 클라우드 운영을 돕는 최상의 에이전트를 만들고 있다.
   2. AI 모델이 실제로 유용한 작업으로 전환하지 못한 능력인 ‘능력 과잉(capability overhang)’이 아직 크다고 보고, 배포 공간과 야망을 넓혀 그 과잉을 흡수하는 일을 목표로 삼는다.
   3. Google Cloud는 복잡한 시스템이 층층이 쌓인 매우 크고 깊은 구멍이자 사실상 거대한 컴퓨터다.
   4. “클라우드는 없다. 다른 사람의 컴퓨터일 뿐이다”라는 오래된 농담을 받아 Ryan은 에이전트에게 “아주 큰 다른 사람의 컴퓨터”를 주고 싶다고 말했다.

4. 계속 갱신해야 하는 마지막 조언

   1. AI 도구의 발전 속도가 빠르므로 무엇이 가능한지에 대한 자신의 기준을 계속 갱신해야 한다.
   2. 미래에도 유효한 전문성을 쌓으려면 모델과 하네스가 좋아져도 남는 두 인터페이스인 도구와 맥락에 집중해야 한다.
   3. 에이전트는 최종적으로 사람이 생각하는 ‘좋음’에 맞추기 위한 맥락을 항상 필요로 한다.
   4. 지식을 점점 더 강력한 도구로 옮기면 그 도구가 기억과 규칙 집행을 동시에 맡아 모델이 시간이 갈수록 더 흥미로운 일을 하게 된다.

2. 직접 만드는 하네스의 설계 선택

Billy의 코드 데모는 프레임워크를 호출하는 데 그치지 않고 프레임워크가 고장 났을 때 내부에서 무슨 일이 일어나는지 이해하는 방법을 보여준다.

2.1. 모델의 도구 사용 의도와 실제 행동 연결하기

1. 도구를 아는 모델과 도구를 실행하는 시스템의 차이

   1. 도구 사용에 맞게 파인튜닝된 모델은 파일을 만지고 API를 호출하고 맥락과 메모리를 관리해야 한다는 사실을 알 수 있다.
   2. 그러나 모델 단독으로는 환경과 상호작용할 통로가 없으므로 “파일을 검사해야 한다”라는 텍스트만 출력한다.
   3. 하네스는 그 의도를 읽고 실제 파일 읽기 도구를 호출해 결과를 다시 모델에 전달한다.

2. 하네스의 목적

   1. 모델이 코딩, 글쓰기, 리서치 중 어떤 일을 해야 하든 의도를 원하는 실행으로 연결하는 것이 하네스의 목적이다.
   2. 문제마다 필요한 실행 순서와 안전 규칙이 다르므로 모든 문제를 해결하는 단 하나의 최선 하네스는 존재하지 않는다.

2.2. 하네스를 설계하는 세 가지 축

1. 루핑(Looping)

   1. 작업이 끝날 때까지 몇 번 반복할지 정한다.
   2. 한 번의 도구 호출로 끝낼지, 오류를 읽고 다음 행동을 선택하는 폐쇄 루프로 돌릴지 결정한다.

2. 도구(Tools)

   1. 어떤 도구를 제공할지, 언제 도구를 써야 하는지, 도구를 어떤 순서와 인자로 사용할지 정한다.
   2. 도구는 모델의 추론을 실제 환경의 결정적인 작업으로 바꾸므로 종류보다 연결 방식과 검증이 중요하다.

3. 메모리(Memory)

   1. 워크플로에서 과거 결과를 얼마나 중요하게 취급할지 정한다.
   2. 메모리를 언제 검색하고, 긴 맥락을 언제 압축(compaction)하며, 실패 원인을 다음 반복에 어떻게 전달할지 설계한다.

2.3. 선형 하네스: 결정성이 필요한 작업

1. 실행 흐름

   1. 파일을 한 번 검사하고, 그 정보를 바탕으로 추천을 출력한 뒤 종료한다.
   2. 파일을 볼 필요가 없으면 곧바로 답을 반환한다.
   3. 매번 같은 순서로 도구를 읽고 응답을 합성한 뒤 끝내므로 실행 흐름이 예측 가능하다.

2. 적합한 상황

   1. 같은 작업을 매번 같은 방식으로 처리해야 하는 경우 선형 패턴이 유리하다.
   2. 반복적인 자율 수정이 필요하지 않고 결과의 결정성(determinism)이 중요한 작업에 적합하다.

2.4. 폐쇄 루프 하네스: 코드 편집과 오류 회복

1. 실행 흐름

   1. 코드 변경을 적용하고 테스트를 실행한다.
   2. 테스트가 통과하지 않으면 단순히 실패 여부만 보지 않고 구체적인 오류 출력을 메모리에 넣는다.
   3. 에이전트는 오류를 읽고 다시 코드를 수정한 뒤 테스트를 반복한다.
   4. 데모는 테스트 통과 또는 최대 5회 반복 뒤 반환하도록 구성됐다.

2. 폐쇄 루프가 필요한 이유

   1. 코드 작업은 한 번의 출력으로 완료되지 않고 변경→실행→실패 원인 확인→수정의 순환을 요구한다.
   2. 테스트 실패의 원인을 다음 추론에 다시 공급하면 에이전트가 환경의 피드백을 이용해 문제를 해결할 수 있다.

2.5. Google ADK: 기능과 안전 가드레일을 함께 사용하기

1. ADK의 역할

   1. Google의 Agent Development Kit(ADK)는 에이전트 기능, 더 많은 가드레일, 메모리 압축을 직접 구현하지 않고도 사용할 수 있게 한다.
   2. 완제품을 그대로 쓰는 것보다 많은 커스터마이징을 유지하면서도 모든 기능을 처음부터 짜지 않아도 된다.

2. 파괴적 명령 차단

   1. block_destructive_commands 함수 같은 검증기를 두어 위험한 행동을 실행하기 전에 차단한다.
   2. 파일 삭제, 데이터베이스 삭제(drop), GitHub 푸시 같은 명령은 코드 실행 전에 막는다.
   3. 자율성이 커질수록 테스트와 검증뿐 아니라 명령 수준의 안전 경계도 함께 커져야 한다.

3. Antigravity·Cloud Code·Cursor를 관통하는 에이전틱 개발 스택

화면에 보이는 제품 이름보다 모델·하네스·지식의 세 레이어가 각 도구를 매끄럽게 만드는 실제 구조다.

3.1. 모델 레이어: Gemini 3.8 Flash

1. 빠른 모델이 에이전트에 맞는 이유

   1. 에이전트는 단일 프롬프트 박스가 아니라 디렉터리 검사, 함수 수정, 단위 테스트 실행을 계속 반복하는 루프다.
   2. 한 작업을 끝내기 위해 20회, 40회, 60회까지 순차적인 홉(hop)을 수행할 수 있다.
   3. 반복 횟수가 많으면 속도와 비용이 누적되므로 가장 무거운 추론 모델이 항상 최선은 아니다.

2. Flash의 실용적 장점

   1. Gemini 3.8 Flash는 가볍고 빠르며 비용 효율적이어서 수십 번의 반복을 빠르게 수행한다.
   2. 빠른 응답은 사용자가 에이전트 루프를 계속 관찰하게 하고, 큰 비용을 발생시키지 않으면서 실시간 작업감을 유지한다.
   3. 에이전틱 워크플로에서 Flash는 성능을 낮춘 선택이 아니라 반복 루프를 실제로 작동시키는 핵심 조건이다.

3.2. 하네스 레이어: Antigravity의 boost

1. 하나의 모델을 협업 팀으로 바꾸기

   1. boost는 단일 모델을 조정된 팀으로 바꾸는 slash command다.
   2. 오케스트레이터가 전문화된 하위 에이전트를 병렬로 실행한다.
   3. 코드베이스에 변경을 반영하기 전에 독립적인 검증 패스가 작업을 철저히 감사한다.

2. 언제 사용할 것인가

   1. 일반 기능 추가, UI 컴포넌트 작성, 코드베이스 탐색에는 기본 에이전트가 빠르고 효율적이므로 boost가 필요하지 않다.
   2. 여러 전문성이 얽힌 깊고 복잡한 엔지니어링 문제에 boost를 아껴 쓰면 병렬 전문성, 오케스트레이션, 독립 검증의 이점을 얻는다.
   3. 화면에는 Antigravity의 세 실행 모드를 비교하는 표가 제시됐지만, 자막에는 표의 각 행과 수치가 전사되지 않았다. 핵심 기준은 일상 업무에는 기본 모드, 복잡한 업무에는 boost라는 구분이다.

3.3. 지식 레이어: Google Skills

1. 에이전트가 추측하지 않게 만드는 큐레이션 지식

   1. 클라우드 인프라를 구성할 때 에이전트가 무엇을 어떻게 설정해야 하는지 아는 것은 모델의 일반 지능만으로 해결되지 않는다.
   2. Google Skills는 에이전트가 필요할 때 불러오는 정제된 도메인 지식(curated domain knowledge)이다.
   3. 무거운 플러그인이나 단순한 MCP 서버가 아니라, 에이전트가 추측하지 않고 정확히 실행하게 하는 정밀한 맥락이다.

2. 규모와 적용 범위

   1. Google Skills 저장소는 GitHub에서 19,000개 이상의 별을 받았으며 아직 초기 단계이고 활발히 발전 중이다.
   2. Google Cloud, Firebase, Flutter, Maps 등을 포괄하는 100개 이상의 스킬이 들어 있다.
   3. 초기 단계이므로 새로운 기여자가 참여할 수 있는 창도 넓다.

3. 하네스에 종속되지 않는 설치

   1. 모든 스킬은 한 번의 명령으로 설치할 수 있다.
   2. Cloud Code, Codex, Google Antigravity처럼 서로 다른 하네스가 같은 저장소를 읽을 수 있다.
   3. 모델과 하네스가 교체되어도 전문 지식 자산을 재사용할 수 있다는 점이 지식 레이어의 핵심 레버리지다.

4. 주요 발언 모음

“나는 믿을 수 없을 만큼 게으른 프롬프터가 되고 싶다. 모델이 스스로 근거를 잡는 데 필요한 도구와 맥락을 주었다면 프롬프트 앞부분에 그것을 미리 다 넣을 필요가 없다.” — Ryan Leupold

“에이전트가 좋은 일을 하지 못한 순간을 관찰하고, 왜 실패했는지 에이전트와 자신에게 질문한 뒤, 코드와 산문을 값싸게 만들 수 있다는 사실을 이용해 환경을 다듬어라.” — Ryan Leupold

“작은 PR이 검토하기 쉽다면 에이전트가 그 검토의 일부를 수행하게 할 수 있고, 작은 PR의 상태 공간을 좁히면 더 긴 시간 범위로 갈 수 있다.” — Ryan Leupold

“얼마나 먼 미래까지 모호성을 벗겨내 에이전트가 그 업무의 자율성을 갖게 할 수 있는가?” — 자율성의 크기를 묻는 질문

“에이전트는 항상 맥락을 필요로 한다. 그 지식을 기억과 좋은 결과의 집행 수단인 점점 더 강력한 도구로 옮겨라.” — Ryan Leupold

“코딩 에이전트에는 더 똑똑한 모델이 필요한 것이 아니라 더 나은 스택이 필요하다.” — Smitha

“클라우드는 없다. 다른 사람의 컴퓨터일 뿐이다.” — 클라우드 업계의 농담

핵심 데이터 & 수치

• 2026년 2월: Ryan Leupold가 코딩 에이전트와 하네스 엔지니어링 관련 작업을 공개한 시점이다.
• 2025년 5월 무렵: Ryan이 직접 프로덕션 코드를 편집하는 에디터를 열지 않았다고 말한 시점이다.
• 8주: Tilda가 직접 코딩하지 않고 에이전트를 사용한 기간이다.
• 20·40·60회: 하나의 작업을 끝내기 위해 에이전트가 수행할 수 있는 반복 홉의 예시다.
• 최대 5회: 데모 폐쇄 루프 하네스가 테스트 실패 후 반복하도록 둔 상한이다.
• 19,000개 이상: Google Skills GitHub 저장소의 별(star) 수다.
• 100개 이상: Google Cloud, Firebase, Flutter, Maps 등을 아우르는 Google Skills의 스킬 수다.
• 세 레이어: 에이전틱 개발 스택을 구성하는 모델, 하네스, 지식 레이어다.
• 세 가지 설계 축: 직접 하네스를 만들 때 결정해야 하는 루핑, 도구, 메모리다.

결론 및 시사점

1. LLM의 지능을 에이전트의 실제 능력으로 바꾸는 핵심은 하네스의 실행 연결, 지식 검색, 피드백 루프다.
2. 가장 좋은 모델만 기다리기보다 현재 모델이 실패하는 구체적인 방식을 관찰하고 문서·도구·테스트·가드레일을 추가해야 한다.
3. 긴 프롬프트를 매번 작성하는 방법보다 에이전트가 필요한 맥락을 스스로 찾는 탐색 가능한 환경이 확장성이 높다.
4. 작은 PR과 작은 검증 루프로 시작하고, 결과의 기준선이 안정되면 병렬 에이전트와 더 큰 업무 범위로 자율성을 넓혀야 한다.
5. 모델 교체에 덜 흔들리는 자산은 도구와 맥락이며, 이 둘이 지식의 기억과 품질 기준의 집행을 맡는다.
6. 선형 하네스는 결정성이 필요한 업무에, 폐쇄 루프는 코드 수정과 오류 회복에, ADK 같은 프레임워크는 안전성과 커스터마이징의 균형에 적합하다.
7. boost 같은 오케스트레이션은 모든 작업의 기본값이 아니라 여러 전문성이 필요한 고난도 작업에 써야 한다.
8. 빠르고 저렴한 Flash 계열 모델, 작업에 맞는 하네스, 온디맨드 도메인 지식이 결합되면 고빈도 에이전트 루프가 현실적인 개발 방식이 된다.

핵심 요약 (20줄)

AI 에이전트는 대규모 언어 모델(LLM)과 모델을 둘러싼 에이전트 하네스의 결합이다. 하네스는 모델의 텍스트 의도를 파일 읽기와 API 호출과 명령 실행으로 연결한다. 비옷을 입을지 묻는 질문에는 현재 날씨를 조회하는 하네스의 행동이 필요하다. 모델이 똑똑해져도 사용자가 원하는 좋은 결과를 저절로 이해하지는 못한다. 도구와 문서를 잘 큐레이션하면 에이전트가 매번 긴 프롬프트를 요구하지 않는다. 린터와 코딩 규칙과 테스트는 에이전트의 행동을 좋은 결과의 기준선에 묶는다. 시프트 레프트는 검증과 지식을 프롬프트 뒤가 아니라 개발 과정 앞쪽에 배치하는 전략이다. PromQL과 CLI 같은 검증된 도구는 자유로운 추론을 결정적인 실행과 조밀한 맥락으로 바꾼다. 문서 링크를 관련 문단 가까이에 앵커로 두면 사람의 가독성과 에이전트의 맥락 효율을 함께 얻는다. 작은 PR을 반복해서 검증하면 에이전트가 더 긴 시간 범위의 작업을 안정적으로 수행한다. React 아키텍트 같은 전문 에이전트를 조합하면 팀의 능력치를 확장할 수 있다. 에이전트가 업무를 분류하고 필요한 전문 지식을 동적으로 불러오면 자율성이 커진다. 하네스를 직접 만들 때는 루핑과 도구와 메모리를 핵심 설계 축으로 결정해야 한다. 선형 하네스는 한 번 읽고 답하는 결정적인 업무에 적합하다. 폐쇄 루프 하네스는 코드 수정과 테스트 실패와 재수정을 반복한다. Google ADK는 메모리 압축과 가드레일과 커스터마이징을 함께 제공한다. 파일 삭제와 데이터베이스 삭제와 GitHub 푸시는 자율 실행 전에 차단해야 한다. Gemini 3.8 Flash는 20회에서 60회까지 이어지는 고빈도 루프에 속도와 비용 면에서 적합하다. Antigravity의 boost는 오케스트레이터와 병렬 하위 에이전트와 독립 검증을 결합한다. Google Skills는 100개 이상의 도메인 지식을 Cloud Code와 Codex와 Antigravity에 공통으로 제공한다.