G3 AI 코딩 에이전트, 진짜 '야근 대신'이 될 수 있을까

G3가 보여준 3시간짜리 자동 코딩 실험

퇴근 후 노트북만 열면 "밤새 돌려두고 아침에 완성된 서비스 받아보기"를 꿈꾸는 사람이 많습니다. 그런데 지금까지의 AI 코딩 도구는 멋진 데모와 달리, 조금만 복잡해지면 결국 사람이 밤을 새우는 쪽으로 끝나는 경우가 많았습니다.

G3가 흥미로운 지점을 찌르는 이유는, 이 한계를 정면으로 인정하고 구조 자체를 갈아엎어 보겠다고 나섰기 때문입니다. 연구진은 터미널 기반 Git 저장소 탐색기라는, 제법 까다로운 앱을 완전히 자동으로 만들게 했습니다. 백엔드 호출, 외부 프로세스 실행, 복잡한 텍스트 파싱, UI 상태 관리까지 엮여 있는 작업입니다. 그 결과는 세 시간 가까운 자율 실행 끝에, 요구사항을 모두 만족하는 애플리케이션과 테스트 코드까지 포함된 약 1800줄짜리 코드베이스였습니다. 중간에 사람이 단 한 줄의 메시지도 보내지 않은 상태였습니다.

여기서 많이들 놓치는 부분이 있습니다. 이 사례의 핵심은 "와, 세 시간 만에 앱 완성"이라는 자극적인 문장이 아니라, 그 세 시간을 버티게 해 준 구조적 설계입니다. 그냥 더 똑똑한 모델을 붙인 것이 아니라, 아예 두 개의 에이전트를 서로 싸우게 만들어 버렸다는 점이 중요합니다. 제 기준에서는 이 구조가 앞으로 나올 엔터프라이즈용 AI 개발 플랫폼의 초기 버전처럼 보입니다.

'바이브 코딩'의 한계를 직면하게 된 이유

많은 개발자가 이미 Cursor나 Windsurf, Claude Code 같은 도구로 '대화하듯 코딩'하는 경험을 했습니다. 간단한 스크립트, 작은 리팩터링, React 컴포넌트 스타일 손보기 정도까지는 이 방식이 꽤 쓸 만합니다. 문제는 서비스 기획서 한 장 분량을 그대로 구현해야 하는 순간부터입니다.

대부분의 대화형 코딩은 점점 길어지는 대화 기록에 발이 묶입니다. 과거에 틀렸던 코드 조각, 이미 지워버린 설계, 바뀐 요구사항이 전부 한 세션 안에서 얽히면서, 모델이 현재 상태를 제대로 파악하지 못합니다. 그래서 "고쳤다"고 답하지만 여전히 깨지는 테스트, 존재하지 않는 함수 호출, 심지어 아예 실행되지 않는 코드를 내놓는 상황이 반복됩니다. 저라면 이런 세션이 길어지기 시작하는 순간, 아예 프로젝트를 새 채팅으로 옮겨 버리는 편입니다. 그 정도로 누적된 문맥이 독이 되는 경우가 많기 때문입니다.

G3가 선택한 '망각' 전략의 의미

G3는 이 문제를 정반대 방향에서 풀었습니다. 기억을 더 많이 붙잡는 대신, 매 턴마다 기억을 지워 버리는 방식을 선택했습니다. 플레이어 에이전트는 항상 같은 역할만 수행합니다. 요구사항과 최신 피드백을 기준으로 코드를 새로 작성하거나 수정하고, 파일을 만들고, 명령을 실행합니다. 반대로 코치 에이전트는 오직 평가와 비판만 담당합니다. 빌드를 돌리고, 테스트를 실행하고, 로그를 읽고, 어디가 실패했는지 정리해서# G3 AI 코딩 에이전트, 진짜 '야근 대신'# G3 AI 코딩 에이전트, 진짜 '야근 대신'럿"에 가깝게 쓰는 편이 리스크 관리 측면에서 낫다고 봅니다.

시작 전 반드시 체크할 것

누구에게 중요한 이슈인가

G3 같은 오토코딩 에이전트는, 장기적으로 복잡한 내부 도구나 백엔드 서비스를 반복해서 만들어야 하는 팀에게 의미가 큽니다. 특히 테스트 코드 비중이 높고, 문서 기반 개발 문화가 이미 어느 정도 자리 잡은 팀이라면 투자 대비 효과를 체감하기 좋습니다. 반대로, 사이드 프로젝트 위주로 빠르게 프로토타입을 돌려보는 개인 개발자나 초기 스타트업에게는 아직 과투자일 수 있습니다. 그냥 Cursor나 일반 챗봇 기반 코딩 보조가 더 가볍고 민첩합니다.

국내 환경에서는 클라우드 비용과 API 비용에 더 민감한 경우가 많습니다. 그래서 대형 서비스 전체를 한 번에 맡기기보다는, 범위가 명확한 모듈 단위로 쪼개 G3를 테스트하는 방식이 현실적입니다. 예를 들어 내부에서만 쓰는 리포트 생성기, 특정 로그를 분석하는 TUI 도구, 반복적인 CRUD 기반 관리 서비스 같은 영역이 초기 실험 대상으로 적합합니다.

현실적 제약과 첫 행동

현실적인 제약은 세 가지 정도로 정리됩니다. 첫째, 속도입니다. 빠르게 결과를 보고 싶은 태스크에는 맞지 않습니다. 둘째, 비용입니다. 고급 모델 기반이라 토큰 비용이 무시하기 어렵습니다. 셋째, 스펙 작성 역량입니다. 요구사항 문서를 제대로 만들지 못하면 도구 성능이 반 토막 이하로 줄어듭니다.

그래서 첫 행동은 거창하지 않아도 됩니다. 저라면 우선 팀에서 이미 존재하는 작은 CLI 도구나 내부 스크립트 하나를 골라, 이를 재구현하는 요구사항 문서를 마크다운으로 써 보겠습니다. 그 문서를 G3에 넣어 한 번 돌려 보고, 결과 코드와 테스트, 로그를 팀과 함께 리뷰하면서 "우리 조직의 문서 문화로 이 도구를 활용할 수 있나"를 점검하겠습니다. 이 단계에서 막히면, 아직은 오토코딩을 논할 때가 아니라 요구사항 정리와 테스트 문화부터 손볼 시점입니다.

결국 G3는 "AI가 개발자를 완전히 대체하는가"라는 질문보다는, "테스트와 리뷰, 명세 기반 개발이라는 오래된 원칙을 AI에게 어떻게 맡길 것인가"라는 질문에 더 가깝습니다. 이 질문이 마음에 걸린다면, 작은 실험부터 시작해 볼 가치는 충분합니다.

출처 및 참고 :