AI-Assisted Engineering Talk #4/27
Hailong Zhang — Gru.ai / GBOX.AI
Coding.net을 텐센트에 매각하고, AI 코딩 에이전트 회사 Gru.ai를 창업한 Hailong Zhang이 2025년 2월 AI Engineer Summit에서 발표한 강연이옵니다. 이 분의 핵심 메시지는 명쾌합니다 — 에이전트는 혼자 똑똑해서 일하는 것이 아니라, 기존 워크플로우의 점검 게이트를 재사용해서 일한다는 것. 자기 회사의 에이전트 ‘Guru’가 이미 커밋 수 기준 1등 기여자라는 도그푸딩 수치로 뒷받침합니다.
다섯 가지 요점
1. AI 코딩 협업은 동기와 비동기, 두 모드 모두 필요하다
동기형(Cursor, Copilot)은 IDE 안에서 사람이 타이핑하는 동안 함께 작동합니다. 비동기형(GitHub bot 등)은 워크플로우 안에서 트리거되어 사람의 주의 없이 자율 완수 후 산출물(PR 등)을 제출합니다. 같은 작업의 다른 구현이 아니라 다른 시점에 끼어드는 두 종류의 협업이며, 실세계 문제를 풀려면 둘 다 있어야 한다는 입장이옵니다.
sync-vs-async coding-agents
2. AI 시대에 unit test의 가치는 더 올라간다
AI의 탭 한 번에 다중 파일, 다중 영역 코드가 동시에 생성됩니다. 사람이 이 모든 생성을 추적할 수 없으니 무언가를 반드시 놓치게 됩니다. 빠른 코드 생산은 곧 빠른 버그 생산이기도 하지요. Unit test가 이 위험을 흡수하는 안전망이 되며, AI 시대 이전보다 한계 가치가 오히려 더 높아진다는 진단이옵니다.
unit-test verification
3. 에이전트의 작업 단위는 PR, 점검 게이트는 인간 머지
Guru의 사이클은 이러합니다 — 변경 감지, 새 unit test 추가 또는 기존 테스트 수정 판단, 코드 작성, 실행 검증, 테스트 요약과 커버리지 정보를 담은 별도 PR 제출. 인간은 그 PR을 검토하고 머지 여부만 결정합니다. 에이전트가 새 검증 인프라를 만든 것이 아니라 이미 있던 인간 워크플로우의 게이트를 재사용한 것이옵니다.
PR-as-unit async-agent
4. 에이전트 문제의 적정 크기는 자동 검증이 가능한 단위로 환원된다
“unit test 작성"은 좋은 에이전트 문제 — 입력(변경 코드)과 검증(테스트 통과/커버리지)이 모두 자동화됩니다. “소프트웨어 엔지니어링"은 좋지 않은 문제 — 너무 크고 자동 검증이 안 됩니다. 크기가 아니라 자동 검증 가능성이 문제를 가르는 진짜 기준이라는 점이 명쾌한 지적이옵니다.
problem-definition verification-bound
5. 단일 에이전트가 아니라 Agent OS 플랫폼이 다음 단계
리팩토링, E2E 테스트, 문서화 등 새 에이전트를 매번 처음부터 만들 수는 없습니다. 작업이 달라도 비슷한 런타임, 도구, 컨텍스트를 공유하므로 공통 인프라를 Agent OS로 추출해 새 에이전트를 빠르게 양산한다는 비전이옵니다. 강연 직후 Hailong이 GBOX.AI(에이전트용 컴퓨팅 환경)로 피벗한 것과 정확히 맞닿는 이야기이기도 합니다.
agent-os platform
Guru 도그푸딩 메트릭
말로만 하는 것이 아니라, Gru.ai 자체 리포에서의 수치를 공개하였사옵니다.
- 50% — 외부 사용자 환경PR 머지율
- 80% — 자체 리포 unit test 중Guru 작성 비율
- #1 — 커밋 수 기준1등 기여자 = Guru
2025년 2월 시점에 이미 에이전트가 인간보다 많은 커밋을 만드는 코드베이스가 존재한다는 도그푸딩 사실이옵니다. 완벽하다고 하진 않았지만, 프로덕션에서 의미 있는 수치라고 발표자 스스로 평가하였습니다.
에이전트 빌드 4계층 스택
에이전트를 구축할 때의 계층 구조를 위에서 아래로 정리한 것이옵니다. 어느 한 층을 건너뛰면 그 위층이 구조적으로 깨지며, 1-2층 없이 LLM부터 손대는 것이 가장 흔한 실패라고 짚었습니다.
이 발표에서 도출된 통찰
💡 [Insight 1] 비동기 에이전트는 기존 점검 게이트를 재사용한다
비동기 에이전트(Guru, GitHub bot 등)가 자율 작동 가능한 진짜 이유는 새로운 검증 인프라를 만들어서가 아닙니다. 이미 존재하던 인간 워크플로우의 점검 게이트(PR 머지, 코드 리뷰, CI)를 재사용했기 때문이옵니다. 새 도메인에 비동기 에이전트를 도입하고 싶다면, 첫 질문은 “어떤 인간 게이트가 자동 트리거 가능한가"여야 합니다.
💡 [Insight 2] 에이전트 문제 단위는 자동 검증 가능성이다
“unit test = 좋은 문제, software engineering = 나쁜 문제"의 본질은 크기가 아니라 자동 검증 가능성이옵니다. “작고 집중된 에이전트를 만들라"는 흔한 권고는, 사실 행동 단위의 권고가 아니라 검증을 자동화할 수 있는 단위의 권고이며 — 새 에이전트 문제를 정의할 때 첫 질문은 “이걸 자동으로 검증할 수 있는가?“여야 합니다. ## 다른 발표와의 접점
같은 27편 시리즈에서 다이제스트한 선행 발표들과 의미 있는 연결이 보입니다.
- 12-Factor Agents (Dex Horthy) — “워크플로우에 사는 작은 에이전트들"은 Factor 10(작고 집중된 에이전트) 원칙과 정확히 정렬됩니다. “doable 문제의 단위"는 Factor 10 + 검증 비대칭성과 겹치며, “코드베이스 환경의 컨텍스트 풀"은 Factor 3(컨텍스트 윈도우를 직접 소유)과 호응합니다.
- Making Codebases Agent Ready (Eno Reyes) — “AI 시대 unit test의 안전망"은 “자동화된 검증이 에이전트의 율속이다"와 직접 연결됩니다. “코드베이스 환경의 컨텍스트 풀"은 “Agent-readiness는 코드베이스의 속성이다”, “코드베이스가 에이전트의 인지 외골격이다"와 수렴합니다.
- To the Moon! — Augment Agent — “동기/비동기 분기"는 Mission Control 메타포와 호응합니다. “Guru PR 자율 사이클"은 “Chat은 가설, Agent는 검증” + “시뮬레이터를 검증 경계로 둔 자율 실행"과 겹치며, 도그푸딩 메트릭은 “자율성은 검증 표면의 함수다"의 실증 사례로 읽힙니다.
Hailong Zhang
Coding.net을 텐센트에 매각한 후 Babelcloud를 창업하고, Gru.ai로 ‘AI 에이전트가 다양한 소프트웨어 엔지니어링 태스크를 완수하도록’ 하는 데 집중했습니다. 2025년 초 GBOX.AI(에이전트용 컴퓨팅 환경)로 피벗했는데, 본 강연(2025-02)은 Gru에서 GBOX로 넘어가는 직전 시점이옵니다.
강연 본문의 ‘Agent OS’ 비전이 곧 GBOX.AI의 방향과 직접 맞닿아 있어, 제품 비전의 밑그림을 발표 형식으로 공개한 것이라 볼 수도 있겠습니다.