Entire가 에이전트 협업용 Git 플랫폼을 공개했다

Entire의 공동 창업자이자 CEO인 토머스 돔케(Thomas Dohmke)는 에이전트와 개발자가 함께 일하도록 설계한 Git 포지(Git forge) Entire를 공개했다. 제품은 코드 검토 도구 Trails, 분산형 Git 호스팅, 에이전트 세션과 프롬프트를 저장소에 연결하는 Continuous Memory를 중심으로 구성된다. Entire는 현재 모든 개발자가 이용할 수 있으며 AI를 중심으로 개발하는 팀과 에이전트에 특히 최적화했다고 밝혔다.

Trails로 코드 검토하기

기존 풀 리퀘스트(PR)에서는 개발자 의견이 시간순으로 쌓이고, 연속 통합(CI) 상태와 병합 버튼이 페이지 아래쪽에 놓인다. Entire는 코딩 에이전트가 코드 검토 에이전트의 의견을 반영하고 다시 검토하는 과정에서 PR 타임라인이 긴 설명으로 가득 차, 에이전트만 읽는 감사 기록처럼 됐다고 설명한다. 이 때문에 개발자가 자신 있게 병합할 수 있는지 판단하는 데 필요한 정보가 잘 드러나지 않는다는 것이다.

Trails는 코드를 푸시할 때마다 계산하는 평가 점수를 페이지 상단에 보여준다. 개발자는 코딩 에이전트와 검토 에이전트가 안정된 상태에 이를 만큼 충분히 반복 작업을 했는지 확인할 수 있다. 신뢰도가 높고 위험이 낮으며 모든 발견 사항이 해결됐을 때 병합하는 것이 목표다.

Trail은 Entire에서 버그 신고나 기능 요청을 작성해 시작할 수 있다. 구현을 시작하기 전이나 시작한 뒤에는 에이전트에서 바로 시작할 수도 있다. 코드를 푸시할 준비가 됐을 때 PR을 여는 방식과 비슷하다. 하나의 Trail은 여러 저장소에 걸친 변경 사항을 함께 묶을 수 있다.

Trail에 코드를 푸시하면 Entire가 검토 에이전트를 실행해 커밋을 살핀다. 각 에이전트는 클라우드 샌드박스에서 독립적으로 실행되며 점수와 근거를 제출한다. Entire는 여러 저장소에서 Security, Slop, Human Review Required 평가를 사용한다고 밝혔다. 예를 들어 Slop 점수가 주황색이면 개발자는 에이전트에 평가 결과를 바탕으로 수정과 푸시를 반복하도록 지시할 수 있고, 점수가 녹색으로 바뀌는지 확인할 수 있다. 각 평가에는 최근 5회 실행 결과와 현재 실행 결과가 표시된다. Entire는 한 번의 반복으로는 중요한 문제를 놓치는 경우가 많다며, 반복 작업과 점수 안정화가 에이전트 코딩의 성공에 중요하다고 설명한다.

프로젝트마다 코드 품질, 보안, Slop을 평가하는 사전 정의 에이전트가 제공되며 저장소별로 활성화할 수 있다. 자체 에이전트는 Entire 인터페이스에서 설정하거나 저장소에 .json 설정 파일로 지정할 수 있다. Entire는 최신 모델을 사용하는 Claude Code와 Codex를 Daytona와 E2B가 제공하는 격리된 클라우드 샌드박스에서 실행한다고 밝혔다. Daytona와 E2B

에이전트는 푸시할 때마다 심각도별 발견 사항과 수정 제안을 반환할 수도 있다. 해결되지 않은 항목은 Trail에 계속 표시하고, 해결된 항목은 숨기되 메뉴에서 다시 확인할 수 있다. 에이전트나 개발자는 발견 사항을 해결하거나 무시할 수 있으며, PR처럼 발견 사항과 의견을 게시할 수도 있다. 저장소별로 Gates를 활성화하면 승인 전에 충족해야 할 조건을 지정할 수 있다. 여기에는 사람의 승인과 CI 검사 통과도 포함된다.

Buildkite·Depot과 CI 연동

Entire는 Trails에 CI 제공업체를 통합하며, 현재 Buildkite와 Depot을 지원한다고 밝혔다. 에이전트가 코드를 작성하는 상황에서 CI는 프롬프트가 의도하지 않은 변경을 막는 안전장치 역할을 한다는 설명이다. Grady Booch가 1991년에 처음 제안한 CI는 현대 소프트웨어 개발 과정에서 팀이 하루 수백 차례 배포할 수 있게 한 핵심 요소라고 Entire는 덧붙였다. CI 통합 안내

Buildkite는 프로젝트 수준에서 설정한다. 한 프로젝트의 여러 저장소가 같은 인프라를 쓰는 경우가 많기 때문이다. Buildkite를 연결하면 푸시할 때마다 Buildkite 인프라나 사용자의 자체 인프라에서 빌드가 실행된다. 결과는 Trail에 검사 항목으로 표시되며 빌드에 실패하면 병합이 차단된다. 에이전트는 Buildkite API, CLI 또는 MCP를 이용해 전체 반복 과정을 자동화할 수도 있다. GitHub Actions 사용자는 워크플로를 다시 작성하지 않고 bk pipeline convert를 실행해 이전할 수 있다.

Depot은 GitHub Actions와 호환되는 소프트웨어 전달 인프라를 제공하며, GitHub를 거치지 않고 기존 워크플로를 실행한다. 팀은 Entire에서 몇 번의 클릭으로 Depot을 연결하고 같은 과정에서 Depot 계정을 만들 수 있다. 이어 depot ci migrate를 실행하면 GitHub Actions 워크플로를 찾아 Depot CI 워크플로로 전환하고 검토가 필요한 항목을 표시한다. 함께 제공되는 명령어로 비밀 값과 변수를 가져올 수 있어 이전한 워크플로를 몇 분 안에 실행할 수 있다. 팀은 기존 워크플로를 유지하면서 첫 실행부터 빠르고 안정적인 CI를 이용할 수 있으며, 비용은 초 단위로 계산돼 작업이 빨라질수록 비용이 줄어든다고 Depot은 설명한다.

저장소를 원하는 지역에 호스팅하기

Entire는 Git과 호환되는 새 소스 관리 서버를 기반으로 한다. 분산 객체 저장소와 트랜잭션 참조 데이터베이스를 사용하며, Entire에서 새 저장소를 만들거나 GitHub 저장소를 미러링할 수 있다. Entire는 이 구조를 바탕으로 자사 서비스를 현재 운영 중인 가장 빠른 Git 포지라고 소개했다. 공개 벤치마크에 따르면 푸시 속도는 GitHub보다 최대 89배, Cursor Origin보다 6배 빠르다. 사용자는 프로젝트와 저장소를 여러 지역에 복제하거나 데이터 거주 요건 등에 따라 거주 지역에만 둘 수 있다. 현재 미국, 유럽연합, 호주, 인도에서 서비스를 제공한다. 오픈소스 벤치마크

푸시 성능 수치(초당 푸시 수)는 다음과 같다.

새 저장소는 웹 인터페이스에서 만들거나 Entire CLI를 사용하는 에이전트에서 만들 수 있다. 저장소는 조직 또는 개인 계정에 속한 프로젝트 안에 놓인다. 프로젝트를 만들 때 기본 지역을 고르고 저장소를 하나 이상의 지역에 복제한다. Entire 저장소 만들기

GitHub를 계속 기준 저장소로 쓰려면 Entire용 GitHub App을 승인한 뒤 저장소와 Entire 내 지역을 골라 미러링하면 된다. 미러링한 저장소에서도 Entire에 기본 호스팅한 저장소와 마찬가지로 PR 위에서 Trails를 사용할 수 있다. 미러링 상태에서는 푸시 트래픽이 GitHub를 거친다. 서비스가 중단되면 Entire는 지역 미러에서 클론과 가져오기를 계속 제공하고, GitHub가 복구될 때까지 에이전트는 entire/unmirrored/로 시작하는 브랜치에 푸시할 수 있다. 저장소 미러링

GitHub에서 저장소를 이전하는 방법은 두 가지다. 미국에서 미러링 중이라면 저장소 설정에서 GitHub 연결 해제를 선택하고 옮길 프로젝트를 지정해 미러를 분리할 수 있다. 미러링 없이 바로 이전하려면 entire-migrate 플러그인을 이용할 수 있다. 로컬 컴퓨터나 CI/CD 워크플로에서 GitHub 저장소를 가져와 Entire로 푸시하는 방법도 있다. GitHub에서 이전하기 · entire-migrate CLI 안내

세션을 지속적인 메모리로 저장하기

개발자와 에이전트는 기능을 만들고 버그를 수정하면서 결정을 내리고, 제약을 발견하며, 여러 접근법을 시험한다. 하지만 세션이 끝나면 이 지식 대부분이 사라진다. 새 세션을 시작하면 에이전트는 새 컨텍스트 창에서 다시 배워야 하며, Entire는 이 과정이 느리고 비용도 많이 든다고 설명한다.

Entire가 Continuous Memory라고 부르는 방식은 세션과 프롬프트를 Git 저장소에 동기화해 코딩 에이전트가 계속 이용하고 검색할 수 있게 한다. Entire는 CI가 코드를 모으고 CD가 배포한다면 Continuous Memory는 이해를 다음 작업으로 이어간다고 설명한다.

Entire CLI의 두 명령어가 이 기능을 지원한다. entire-graph는 코드 구조를 나타내는 지도를 만들며, Entire의 테스트에서 토큰을 최대 71% 절약했다고 한다. entire-brain은 에이전트 세션을 색인해 그래프에 연결하고, 에이전트가 지속적으로 보존된 메모리를 검색할 수 있게 한다. 두 플러그인은 오픈소스이며 로컬 우선으로 설계됐다. entire-brain은 entire-graph가 만든 코드 지도를 기반으로 동작한다.

entire-graph는 Git 저장소의 미리 계산된 지도를 에이전트에 제공한다. 여기에는 순위가 매겨진 코드 검색 결과와 정의, 호출자, 타입, 경로, 변경 영향이 포함되며 각 항목에 file:line 위치가 붙는다. 내장 분석기는 tree-sitter로 저장소를 로컬에서 분석하며 네트워크 요청, 모델 호출, API 키 조회를 하지 않는다. entire-graph 설정 안내

entire-brain은 저장소에 지속적인 메모리 계층을 만들어 에이전트가 적절한 시점에 필요한 맥락, 즉 ‘무엇이 바뀌었는가’의 배경인 ‘왜’를 이용하도록 한다. entire-graph가 만든 코드 지도를 색인하고 Entire CLI를 통해 Git 기록에 저장된 과거 에이전트 세션과 연결한다. 예를 들어 청구 시스템의 반올림 버그로 불일치 오류가 생긴 경우, entire-graph는 송장 계산이 거치는 호출자와 테스트를 추적하고 entire-brain은 현재 로직의 의도, 이미 배포한 수정과 그 이유, 이전 변경 때 실패한 테스트를 에이전트에 제공할 수 있다.

entire-brain을 Entire 백엔드에 연결하면 팀의 에이전트 메모리를 각자의 컴퓨터 대신 공유 공간에 둘 수 있다. 각 Trail에는 에이전트가 만든 메모리가 표시돼 검토자가 개발자의 결정과 에이전트가 학습한 사실을 확인할 수 있다. entire-brain 안내