소프트웨어 개발에서 인공지능 도구를 활용하는 일은 더 이상 프롬프트 하나를 작성하고 답변을 기다리는 것에 국한되지 않는다. 개발자들은 반복적인 실행 루프, 다중 에이전트, 모델을 둘러싸고 모델을 유도하는 시스템에 대해 점점 더 많이 이야기하고 있다. GitHub Blog는 2026년 9월 2일 Cassidy Williams가 게시한 가이드에서 이러한 개념을 정리하려고 했다. 이 가이드는 Marlene Mhangami와 GPS가 참여한 GitHub Podcast의 논의를 바탕으로 한다.
이 용어 중 일부는 새로운 실천 패턴을 설명하고, 일부는 이미 존재하던 아이디어에 현대적인 이름을 붙인다. 반면 다른 용어의 의미는 여전히 형성되는 중이다. 따라서 이 가이드는 이러한 단어를 최종적인 표준으로 제시하지 않고, 소프트웨어 개발 팀 사이에서 진행 중인 논의를 이해하는 방법으로 제시한다.
단일 프롬프트에서 루프 엔지니어링으로
루프 엔지니어링은 매번 에이전트에게 단일 작업을 수동으로 수행하도록 요청하는 대신, 에이전트를 중심으로 반복 가능한 시스템을 설계하는 것을 의미한다. 제시된 예시는 새 프로젝트 이슈를 가져오는 예약 프로세스를 만들고, 이를 에이전트에 전달해 요약하고 수정 사항을 제안하게 한 다음, 결과를 검증하고 해결되지 않은 사례를 다른 경로로 에스컬레이션하는 것이다.
이런 의미에서 루프는 인공지능에 맞게 구성된 cron 작업과 비슷해 보이지만, 단순한 예약 기능보다 더 많은 요소가 필요하다. 가이드는 구체적인 스킬, 행동 모니터링, 출력 검증, 작업 지시, 그리고 개입이나 검토가 가능한 중단 지점을 언급한다.
Ralph loops는 루프라는 개념을 더 단순하고 직접적으로 적용한 방식이다. 에이전트에 대개 요구 사항이나 사양에서 출발한 작업의 상세한 설명을 제공하고, 에이전트가 작업을 완료했다고 판단할 때까지 계속 작업하게 한다. 이 방식은 작업을 계획, 실행, 점검의 반복 주기로 나누는 데 도움이 될 수 있지만, 각 주기에서 더 많은 토큰과 컨텍스트, 컴퓨팅 성능을 소모하면 비용이 많이 들고 비효율적일 수 있다.
팀, 플릿, 하네스의 차이
squads와 fleets는 여러 에이전트 사이에 작업을 분배하는 방식을 설명한다. 팀은 서로 다른 역할을 맡은 에이전트들의 집단이다. 한 에이전트는 계획을 세우고, 다른 에이전트는 계획을 검토하며, 세 번째 에이전트는 실행하고, 네 번째 에이전트는 테스트하며, 다섯 번째 에이전트는 결과를 검토한다. 플릿은 여러 작업을 동시에 병렬로 수행하는 에이전트들을 가리킨다. 전체 팀을 병렬 플릿 안에서 실행할 수도 있고, 역할을 순차적으로 구성할 수도 있다.
여기서 실용적인 아이디어는 한 에이전트에게 모든 일을 맡기는 대신 전문화와 병렬화를 활용하는 것이다. 하지만 여러 에이전트가 존재한다고 해서 자동으로 품질이 높아지는 것은 아니다. 글 자체도 이점은 역할을 분배하고 통제하며 출력을 검증하는 팀의 능력과 관련이 있다고 설명한다.
실행 하네스 또는 harness는 모델을 워크플로 안에서 사용할 수 있게 만드는 모델 주변의 모든 것을 가리킨다. 여기에는 도구, 권한, 메모리, 컨텍스트, 작업 간 조정이 포함된다. 가이드는 GitHub Copilot을 모델과 코드베이스, 편집기, 풀 리퀘스트, 터미널을 연결하는 시스템의 예로 제시한다. 하네스 엔지니어링은 모델을 둘러싼 이 시스템을 설계하고 개선하는 일이다.
피드백을 통한 개선
hill climbing이라는 용어는 피드백을 바탕으로 에이전트와 하네스를 점진적으로 개선하는 것을 설명하는 데 사용된다. 팀은 평가 테스트를 통해 에이전트의 성능을 측정하는 것에서 시작한 다음, 결과가 충분히 정확하지 않을 때 도구나 컨텍스트 또는 지시 방식을 수정할 수 있다.
예를 들어 풀 리퀘스트 검토에서 측정 대상은 에이전트가 댓글을 생성할 수 있는지만이 아니다. 의미 있는 오류를 찾아내고 유용한 권고를 제시하는지도 포함된다. 여기서 실용적으로 얻을 수 있는 결론은 워크플로에 에이전트를 도입하는 것이 종착점이 아니라는 점이다. 도입 이후에는 측정과 수정의 지속적인 순환이 시작된다.
역할과 모델에 관한 용어
현장 파견 엔지니어는 인공지능의 물결이 오기 전부터 존재하던 역할을 설명한다. 예를 들어 고객과 직접 소통하는 소프트웨어 엔지니어, 세일즈 엔지니어, 솔루션 엔지니어가 이에 해당한다. 인공지능의 맥락에서 이 역할은 팀이 도구, 워크플로, 에이전트를 조정하고 기존 시스템에 통합하도록 돕는다.
폐쇄형 모델은 API나 호스팅 제품을 통해 제공되며, 사용자가 가중치나 학습 데이터 또는 학습 방식을 이용할 수 없다. 오픈 웨이트 모델은 가중치를 다운로드해 로컬 또는 사용자의 인프라에서 실행할 수 있게 하지만, 이것이 데이터와 학습 방식까지 반드시 공개된다는 의미는 아니다. 오픈 소스 모델에서는 공개 범위가 더 넓어져 모델, 코드, 데이터, 학습 과정까지 검사하고 재사용하며 수정할 수 있다.
이 가이드가 중요한 이유
실질적인 변화는 새로운 용어집의 등장에만 있는 것이 아니다. 논의가 “모델이 무엇을 생성할 수 있는가?”라는 질문에서 “모델을 중심으로 반복 가능하고 측정 가능한 시스템을 어떻게 구축할 것인가?”라는 질문으로 이동하고 있다는 점에 있다. 이는 프로세스 안에서 에이전트를 실행하는 방안을 고려하는 개발 팀에 중요하다. 용어를 선택하는 것만으로는 권한, 검증 메커니즘, 인간이 개입할 지점, 반복 비용을 정할 수 없기 때문이다.
그럼에도 출처는 용어가 안정적이지 않다는 점을 인정한다. 일부는 정착할 수 있고, 일부는 사라지거나 더 정확한 표현으로 대체될 수 있다. 따라서 여전히 가장 중요한 질문은 실용적인 것들이다. 워크플로를 신뢰할 수 있는 방식으로 반복할 수 있는가? 결과는 어떻게 검토하는가? 인간은 언제 개입하는가? 모델에 어느 정도까지 의존하는 것이 허용되는가? 글에 따르면 이러한 질문은 유행하는 모든 단어를 따라가는 것보다 더 중요하다.