개발 및 IT운영

Agent Factory 요약: 에이전트 하네스, 시프트 레프트, 자율 코딩

2026년 10월 6일

https://storage.googleapis.com/gweb-cloudblog-publish/images/agent-factory-recap-agent-harness.max-2500x2500.png

Mollie Pettit

Developer Relations Engineer

Smitha Kolan

Senior Developer Relations

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

이번 Agent Factory 에피소드에서는 Google Cloud의 소프트웨어 엔지니어이자 에이전트 하네스라는 용어를 창안한 Ryan Lopopolo와 함께 자율 에이전트를 활용한 인프라 빌드 작업의 현실을 살펴봅니다. 수동 코드 편집기를 없애는 것부터 팀 공동작업을 RPG 게임에서 능력치를 올리는 과정에 비유하는 것까지, Ryan은 풍부한 컨텍스트에 기반을 두고 모델을 그라운딩하고 개발 초기부터 개입하는 것이 어떻게 높은 수준의 에이전트 자율성을 실현할 수 있는지 상세히 설명합니다.

이 게시물에서는 함께 나눈 대화의 핵심 아이디어를 안내합니다. 주제를 빠르게 요약하거나 링크와 타임스탬프를 통해 특정 세그먼트를 더 자세히 살펴보려면 이 게시물을 이용해 보세요.

에이전트 하네스 - 정의

타임스탬프: [00:30]

여기서 정의하는 AI 에이전트는 대규모 언어 모델(LLM)과 에이전트 하네스가 결합된 형태입니다.

하네스는 모델 자체가 아니라 LLM을 둘러싸고 있는 모든 요소라고 생각하면 됩니다. 예를 들어 Google Antigravity에서 Gemini 3.8 Flash를 사용하여 작업하는 경우 Gemini Flash는 LLM에 해당하고 Google Antigravity는 하네스에 해당합니다.

지원 시스템이 없는 모델은 간단한 질문에 즉시 답변할 수 있지만, 자체적으로 실시간 상황을 확인하거나 작업공간과 상호작용할 수 없습니다. 사용자가 "하늘은 왜 파란색이야?"와 같은 질문을 하면 지원 시스템이 없는 LLM도 문제없이 답변할 수 있습니다. 하지만 "오늘 우비를 입어야 할까?"와 같은 질문을 받으면 이 모델에는 필요한 데이터가 없기 때문에 스스로 답변할 수 없습니다. 이때 하네스는 사용자의 의도를 파악하고, 실시간 날씨 도구에 쿼리하고, 해당 컨텍스트를 프롬프트로 다시 구성한 후, 이를 모델에 전달하므로 모델은 정보에 입각한 답변을 생성할 수 있습니다.

Ryan Lopopolo가 전하는 에이전트 하네스와 자율 코딩

Tilde Thurium이 Ryan Lopopolo와 함께 프로덕션 환경에서 완전한 자율 코딩 워크플로를 실행하는 데 필요한 사항에 대해 이야기했습니다. 아래 요약 내용을 살펴보세요.

프로덕션 코드를 작성할 필요가 없는 하네스 개념의 탄생

타임스탬프: [02:22]

에이전트 하네스라는 용어는 자율 코딩 에이전트에 관한 Ryan의 광범위한 연구에서 비롯되었으며, 2026년 2월 에이전트 중심 세상에서 코딩 모델의 활용에 대해 다룬 에세이에서 집대성되었습니다. Ryan은 지난해 5월 이후로 기존의 코드 편집기를 한번도 열지 않았으며 Google Cloud로 이직하는 과정에서도 이 기록을 이어가고 있다고 밝혔습니다. 이 패러다임에서는 엔지니어가 더 이상 개별 구문 라인을 작성하거나 검토하지 않습니다. 대신 자연어 사양 수준에서 작업하고 pull 요청, 문서, 스프레드시트와 같은 최종 아티팩트를 검사합니다. 그런 다음 최종 결과가 조직의 표준을 충족하는지 여부를 판단합니다.

하네스 엔지니어링이란 모델이 성공할 수 있는 환경에 모델을 배치하는 방법을 연구하고 이를 실무에 적용하는 과정을 말합니다. 이러한 작업을 거치지 않으면 '프롬프트 작성 후 잘 되기만을 기도'하는 상황에 처하게 됩니다.

Ryan Lopopolo

컨텍스트 큐레이션 및 지연 프롬프트 작성

타임스탬프: [03:35]

사전 하네스 투자는 엔지니어가 프롬프트 작성을 지연해도 효과를 발휘합니다. 저장소에 구조화된 문서, 명확한 인터페이스, 검색 가능한 도구가 포함되어 있다면 매일 아침 프롬프트 상자에 긴 텍스트를 붙여넣을 필요가 없습니다.

"저는 아주 게으른 프롬프트 작성자가 되고 싶습니다. 모델을 그라운딩하는 데 필요한 도구와 컨텍스트를 제공하는 작업을 완료했다면 긴 프롬프트를 작성할 필요가 없습니다. 모델이 알아서 해결하니까요."

이 모델은 하네스를 사용하여 관련 컨텍스트를 가져오므로 별도의 감독 없이도 대규모 코드베이스를 탐색하고 복잡한 작업을 실행할 수 있습니다.

시프트 레프트: 자율 가드레일로서의 엔지니어링 권장사항

타임스탬프: [05:00]

에이전트가 실패하면 개발자는 다양한 개입 방식을 고려하게 됩니다. 가장 일반적인 방식은 프롬프트를 수정하거나 다시 시도하는 것이지만, 이를 팀 전체로 확장하기 어렵습니다.

"제가 생각할 수 있는 가장 간단하고 단순하며 어리석은 개입은 말 그대로 다른 것은 아무것도 변경하지 않고 프롬프트를 다시 시도하는 것입니다. 하지만 시프트 레프트는 프롬프트, 저장소 문서, 린터, 테스트, 업스트림 평가에 이르기까지 비용이 가장 적게 들고 자동화할 수 있는 개발 수명 주기의 초기 단계에 개입하여 문제를 해결하는 것을 의미합니다."

다음 단계에서 모델이 올바르게 판단하기를 기대하는 대신, 시프트 레프트를 통해 표준을 환경에 직접 삽입합니다. 린터, 테스트, AGENTS.md 파일은 사용자가 바람직한 결과라고 생각하는 기준을 기억하고 실행하는 역할을 합니다. 따라서 에이전트가 지속적인 개입 없이도 정해진 궤도를 벗어나지 않고 올바르게 작동하도록 보장할 수 있습니다.

기존 도구 및 결정론 활용

타임스탬프: [06:50]

에이전트는 사전 학습 데이터에 많이 등장하는 패턴을 이미 반영하는 도구를 사용할 때 진가를 발휘합니다. 모델을 표준 명령줄 인터페이스와 페어링하면 추론이 결정론적 성격을 띠게 되며, 컨텍스트 집계에 따른 부담이 모델에서 신뢰할 수 있는 도구로 옮겨집니다.

또한 Ryan은 컨텍스트 효율성을 높이기 위한 환경 설계 방법을 공유했습니다. 바로 링크 앵커가 인라인이 아니라 해당 텍스트 블록 바로 아래에 위치하도록 마크다운 파일을 구성하는 것입니다. 이렇게 하면 컨텍스트가 복잡해지는 것을 방지하고 '중간에 길을 잃는' 검색 문제를 완화할 수 있습니다. Ryan은 최종 상태 아티팩트를 검토하는 방식으로만 작업하기 때문에 문서를 읽기 쉽게 유지하면 실행 과정을 쉽게 검사할 수 있습니다.

"저는 pull 요청을 보고 검토할 수 있기를 원합니다. 에이전트가 잘못된 결정을 내렸다면 어디서 잘못되었는지 알아야 에이전트를 바로잡고 다시는 같은 실수를 하지 않도록 할 수 있습니다."

장기 계획 및 에이전트 루프 확장

타임스탬프: [09:45]

하네스 엔지니어링의 핵심 과제는 에이전트가 장기적인 관점에서 일관성을 유지하도록 하는 것입니다. 인간 조직은 일회성 프롬프트가 아닌 반복적인 개선을 통해 소프트웨어를 개발하므로 에이전트 워크플로도 이러한 주기를 반영해야 합니다. 하네스 엔지니어링은 엄격하게 범위가 정해져 있고 검토 가능한 pull 요청을 사용하여 에이전트의 상태 공간을 좁힙니다. 이러한 신뢰도 높은 변경사항을 엔드 투 엔드로 쌓아 올리면 감독자는 루프 크기를 점진적으로 확장할 수 있으므로, 에이전트는 전체 언어 마이그레이션을 포함한 대규모 이니셔티브를 자율적으로 실행할 수 있을 때까지 신뢰를 구축할 수 있습니다.

RPG 능력치처럼 에이전트 팀 큐레이션

타임스탬프: [11:58]

개별 전문 분야에 따라 스프린트 작업을 분배하는 대신, 다양하게 구성된 팀이 에이전트의 역량 강화에 기여하게 되면 에이전트는 모든 구성원의 강점을 담은 핵심적인 업무 생산자로 거듭나게 됩니다. Ryan은 에이전트의 역량을 높이는 과정을 캐릭터 시트를 작성하는 것에 비유했습니다.

"마치 RPG 캐릭터의 능력치를 키우는 것과 비슷합니다. React 설계자가 팀에 새로 합류하면 이 사람의 전문성이 더해져 프런트엔드 아키텍처와 성능 관련 능력치가 크게 향상되는 식이죠."

이러한 집단적 전문성이 환경에 내재화되면 에이전트는 들어오는 작업을 자율적으로 분류하고 필요에 따라 적합한 기술을 활성화하여 백엔드 설계자와 프런트엔드 전문가의 역할을 모두 수행할 수 있습니다.

커스텀 하네스가 아닌 도구에서 시너지 창출

타임스탬프: [14:38]

자체적으로 커스텀 에이전트 하네스를 빌드해야 할지 고민하는 개발자에게 Ryan은 처음부터 빌드하지 말라는 명확한 조언을 건넸습니다. 표준 하네스는 이미 파일 읽기, grep 검색, 명령어 실행과 같은 기본적인 기능을 제공합니다. 스캐폴딩 기능을 과도하게 사용하여 엄격한 맞춤형 프레임워크로 에이전트를 구성하면 기술 부채가 발생하고, 프런티어 모델이 발전함에 따라 매몰 비용이라는 함정에 빠지게 됩니다.

"도구와 컨텍스트의 품질을 개선하는 데 모든 역량을 집중하면 새로운 모델이 출시될 때마다 자유롭게 도입할 수 있으며, 절대 구식이 되지 않는 시스템에서 지속적으로 시너지를 창출할 수 있습니다."

Google Cloud 운영 및 기능 격차 해소

타임스탬프: [16:47]

Ryan은 Google Cloud에서 자신의 업무에 대해 이야기하면서 기능 격차, 즉 프런티어 AI 모델이 이론적으로 수행할 수 있는 작업과 현재 프로덕션에서 추출되는 유용한 작업 간의 차이를 없애고자 하는 동기를 설명했습니다. 클라우드는 방대하고 프로그래밍 가능한 플랫폼 역할을 하므로, Google Cloud를 직접 이용하기 위한 인터페이스를 에이전트에 제공하면 인프라를 효율적으로 관리하고 배포할 수 있게 되어, 원시 모델 기능을 실질적인 엔터프라이즈 유틸리티로 전환할 수 있습니다.

AI에 대한 기존 사고방식의 지속적인 업데이트

타임스탬프: [18:13]

AI 개발 속도가 빨라짐에 따라 엔지니어와 팀은 기존의 한계를 적극적으로 극복하고 이러한 모델을 통해 달성할 수 있는 목표를 끊임없이 재평가해야 합니다. Ryan은 "우리가 가진 훌륭한 도구를 활용하여 어떤 작업이 가능한지에 대한 생각을 지속적으로 업데이트하는 것이 매우 중요합니다"라고 강조했습니다. 6개월 전에는 작동하지 않던 기능이 오늘날의 프런티어 모델에서는 원활하게 실행되는 경우가 종종 있습니다. 개발자는 경직된 워크플로에 갇히기보다는 모든 모델 업그레이드에서 관련성을 유지할 수 있는 확장성이 뛰어난 두 가지 인터페이스인 도구와 컨텍스트를 중심으로 빌드해야 합니다.

"에이전트는 사용자가 바람직한 결과라고 생각하는 기준에 맞게 마지막 단계까지 조정하기 위해 항상 컨텍스트를 필요로 합니다. 또한 사용자가 바람직한 결과라고 생각하는 기준을 기억하고 실행하는 역할을 하는 더욱 강력한 도구를 활용하여 이 과정을 점진적으로 발전시켜 나간다면, 시간 경과에 따라 모델이 점점 더 흥미로운 작업을 해내는 모습을 보고 계속해서 놀라게 될 것입니다."

커스텀 하네스 빌드하기

다음으로 Billy Jacobson은 개발자가 특정 작업을 위해 자체적으로 에이전트 하네스를 맞춤설정하는 방법을 소개했습니다.

자세히 들여다보기: 커스텀 하네스를 빌드하는 이유

타임스탬프: [19:44]

코드를 작성하기에 앞서 Billy는 개발자가 하네스를 블랙박스처럼 취급하기보다는 하네스의 메커니즘을 이해해야 하는 이유를 설명했습니다. "프레임워크를 그냥 사용할 수도 있지만, 훌륭한 엔지니어라면 프레임워크를 제대로 이해해야 합니다"라는 엔지니어링 멘토의 조언을 떠올리며, Billy는 에이전트가 오작동할 때 발생하는 문제를 디버깅하는 가장 좋은 방법은 하네스를 직접 빌드하는 것이라고 설명했습니다. 모든 워크플로에 대해 설계와 관련한 세 가지 중요한 결정을 평가할 수 있습니다.

루프: 에이전트가 몇 번 반복 실행해야 하며, 어떤 조건에서 종료 상태를 트리거하나요?
도구: 에이전트가 어떤 특정 도구에 액세스해야 하며, 언제 어떻게 호출해야 하나요?
메모리: 대화 메모리와 운영 메모리는 얼마나 중요하며, 언제 검색하거나 압축해야 하나요?

선형 에이전트 하네스: 결정론적 단일 패스 실행

타임스탬프: [21:34]

Billy는 루프가 필요 없는 결정론적 워크플로를 위해 설계된 미니멀한 선형 하네스를 시연했습니다. 이 패턴은 높은 수준의 결정론이 필요하고 에이전트가 매번 정확히 동일한 실행 흐름을 수행해야 하는 표적 검사, 파일 변환 또는 단일 턴 데이터 분석에 적합합니다.

폐쇄 루프 에이전트 하네스: 반복적인 테스트 기반 복구

타임스탬프: [22:45]

적극적인 버그 수정과 리팩터링이 필요한 작업의 경우 폐쇄 루프 하네스는 검증된 해결책에 도달하는 데 필요한 반복적인 추론을 제공합니다.

이 데모에서 Billy는 요구사항을 충족하지 못하는 문제를 해결하기 위해 자동화된 코드 편집을 적용하는 에이전트를 선보였습니다. 이 과정에서 하네스는 업데이트된 코드베이스에 대해 단위 테스트 모음을 실행합니다. 테스트가 실패하면 런타임은 표준 실패 로그와 상세한 스택 트레이스를 캡처하여 해당 오류 진단 정보를 에이전트의 작업 메모리에 직접 제공합니다. 이 프로세스는 모든 단위 테스트를 통과할 때까지 지속적으로 반복되지만, 무한 루프와 과도한 실행 비용을 방지하기 위해 5회 반복으로 제한됩니다.

Google의 에이전트 개발 키트(ADK)를 활용한 가드레일 하네스

타임스탬프: [23:25]

핵심 오케스트레이션 파이프라인을 처음부터 다시 작성하지 않고도 커스텀 동작이 필요한 개발자를 위해 Google의 에이전트 개발 키트(ADK)는 자동화된 메모리 관리 및 실행 보호 장치가 포함된 스캐폴딩을 제공합니다.

Billy는 ADK의 기본 컨텍스트 압축 기능을 활용해 이전 대화 내용을 요약하여 연장된 디버깅 실행 기간 동안 컨텍스트 윈도우가 과도하게 커지는 것을 방지하는 예시를 살펴보았습니다. 커스텀 인터셉트 후크는 셸 작업을 실행하기 전에 검사하고 필터링하여 재귀적 파일 삭제, 데이터베이스 삭제, 무단 원격 git 푸시와 같은 고위험 작업을 자동으로 차단합니다. 이 아키텍처에서는 도구 실행 경계를 세밀하게 제어하는 동시에 맞춤형 하네스 프레임워크의 유지보수 부담을 줄일 수 있습니다.

3계층 에이전트 개발 스택: Gemini 3.8 Flash, Google Antigravity, Google Skills

타임스탬프: [25:27]

다음으로 Smitha Kolan은 코딩 에이전트에 항상 더 복잡한 추론 모델이 필요한 것은 아니라는 점을 자세히 설명하면서, 에이전트 스택의 세 가지 계층인 모델, 하네스, 지식 간에 균형을 유지하는 것이 고성능의 비결이라고 강조했습니다.

"코딩 에이전트에 더 스마트한 모델이 필요한 것은 아닙니다. 모델, 하네스, 지식으로 구성된 더 나은 스택이 필요합니다. 이 세 가지가 완벽하게 조화를 이룰 때 모든 것이 달라집니다."

이어 Smitha는 최근에 즐겨 사용하고 있는 세 가지 도구를 스택의 각 계층별로 하나씩 소개했습니다.

계층 1 | 모델 | Gemini 3.8 Flash: 실행 빈도가 높은 에이전트 루프는 작업당 20~60회의 순차적 홉(파일 검사, 함수 업데이트, 단위 테스트 실행)을 실행합니다. 반복이 거듭될수록 지연 시간과 API 비용이 누적되므로, Gemini 3.8 Flash와 같이 반응성이 뛰어난 경량의 모델을 사용하면 막대한 비용을 들이지 않고도 실시간 에이전트 루프를 실용적으로 구현할 수 있습니다.

계층 2 | 하네스 | Google Antigravity(/boost): 기본 Antigravity는 표준 탐색 및 구성요소 생성 작업을 처리합니다 또한 여기에 /boost 명령어를 추가하면 조정자가 가동되어 특화된 하위 에이전트를 병렬로 조율한 후 최종적으로 파일을 수정하기 전에 독립적인 감사 단계를 수행합니다.

계층 3 | 지식 | Google Skills 저장소: GitHub에서 19,000개 이상의 별표를 기록했으며 Google Cloud, Firebase, Flutter, 지도 등 다양한 분야에서 엄선된 100개 이상의 도메인 패키지를 보유한 이 저장소는 특정 하네스에 구애받지 않으면서 필요에 따라 정확한 도메인 컨텍스트를 제공하므로 에이전트는 클라우드 구성을 추측하지 않아도 됩니다.

직접 빌드해 보기

효과적인 코딩 에이전트를 빌드하려면 단순히 더 큰 모델로 교체하는 관행에서 벗어나야 합니다. 하네스 엔지니어링에 대한 Ryan Lopopolo의 철학에서 알 수 있듯이, 개발자의 역량을 강화하는 길은 권장사항을 개발 초기 단계부터 활용하고 모델 업그레이드 후에도 지속적으로 활용 가능한 풍부한 도구, 결정론적 검증 도구, 잘 선별된 컨텍스트에 투자하는 데 있습니다. 여기에 빠른 추론 모델, 구조화된 오케스트레이션 하네스, 모듈식 도메인 지식이 결합되면 에이전트는 단순한 대화거리에 그치지 않고 신뢰할 수 있는 자율 엔지니어링 파트너로 진화하게 됩니다.

실제로 적용해 볼 준비가 되셨나요? 이 에피소드에서 다룬 도구와 리소스를 살펴보세요.