20년 전, 개발 좀 한다는 개발자의 명함에는 보이지 않는 타이틀이 하나 더 있었다. 프레임워크 개발자. 대형 SI 회사마다 자체 프레임워크를 만들었고, 프로젝트에 투입되는 개발자들은 그 프레임워크 위에서 코드를 짰다. 프리랜서 개발자 중에서도 실력 있는 이들은 자신만의 프레임워크를 들고 다녔다. 회사가 바뀌어도, 프로젝트가 바뀌어도 자기 프레임워크 하나면 어디서든 빠르게 결과물을 만들어낼 수 있었기 때문이다.

이유는 단순했다. 프레임워크는 개발의 표준화와 안정성을 보장했고, 개발 기간을 획기적으로 단축해주었다. 당시 한국의 금융권은 메인프레임에서 자바 기반 차세대 시스템으로의 대전환을 겪고 있었는데, 글로벌 오픈소스 프레임워크가 아직 미성숙하던 시절이었다. DB 커넥션 풀, 공통 예외 처리, 로깅, 인증, 트랜잭션 관리, MVC 기본 구조. 이것들을 매 프로젝트마다 새로 만드는 것은 시간 낭비였고, 한번 잘 만들어 놓으면 수십 개의 프로젝트에서 재사용할 수 있었다. 자체 프레임워크를 가진 회사와 개발자는 그 자체로 기술력의 증명이었고, 수주 경쟁에서 결정적인 차별점이 되었다. 프레임워크를 만들 수 있느냐가 개발자와 회사를 평가하는 핵심 기준이었던 것이다. 좋은 프레임워크를 보유한 SI 회사에는 자연스럽게 프로젝트가 몰렸고, 그 프레임워크에 익숙한 개발자들의 몸값도 함께 올라갔다. 프레임워크는 기술적 자산인 동시에 비즈니스 자산이었다.

지금은 아무도 프레임워크를 만들었다고 위대함을 논하지 않는다. React, Spring Boot, Next.js, FastAPI. 오픈소스 생태계가 성숙하면서 선택지가 넘쳐나고, 프레임워크 자체는 더 이상 경쟁력이 아니게 되었다. 전자정부 표준프레임워크가 등장해 공공 프로젝트의 벤더 종속성을 해소한 것도 이 흐름의 일부였다. 프레임워크의 시대가 끝난 것이 아니라, 프레임워크가 당연한 것이 된 시대가 온 것이다. 그 결과 개발자를 평가하는 기준도 바뀌었다. 어떤 프레임워크를 만들었느냐가 아니라, 주어진 프레임워크 위에서 어떤 제품을 만들어내느냐가 중요해진 것이다.

그런데 지금, AI 코딩이 한창인 이 시점에 전혀 새로운 종류의 프레임워크가 필요해지고 있다. 이전의 프레임워크가 사람 개발자를 위해 만들어진 것이었다면, 이번에는 자율적으로 동작하는 개발 에이전트를 위한 환경이 필요한 상황이다. 프레임워크라는 단어가 정확히 맞지는 않는다. 엔드투엔드로 동작하는 에이전트에게 프레임워크는 인간 중심의 개념이기 때문이다. 아마 다른 명칭이 생기겠지만, 지금으로서는 ‘AutoDevAgent 환경’이라고 부르는 것이 가장 가까울 것이다.

아직 사람이 먼저인 AI 코딩

지금의 AI 코딩은 이런 식으로 동작한다. 개발자가 프롬프트를 쓴다. Claude Code나 Cursor 같은 코딩 에이전트가 코드를 생성한다. 개발자가 결과를 확인하고, 다시 프롬프트를 쓴다. 자연어로 몇 줄 적고 엔터를 치면 대부분의 시간은 기다림의 연속이다. 에이전트가 코드를 만들어내는 동안 사람은 화면을 바라보고 있을 뿐이다.

이 구조의 본질은 명확하다. Human First다. 사람이 먼저 지시하고, 에이전트가 뒤따르는 구조. 사람의 프롬프트 없이는 아무것도 시작되지 않고, 사람이 확인하지 않으면 다음 단계로 넘어가지 않는다. AI가 코드를 작성하는 시대라고 하지만, 실상은 사람이 에이전트를 한 줄 한 줄 이끌고 있는 것이다. 마치 자율주행 기술이 Level 5에 도달했음에도 운전자가 핸들에서 손을 떼지 못하는 것과 비슷하다. 기술은 준비되었지만, 환경과 신뢰가 따라가지 못하고 있는 상황이다. 자율주행차에 운전석이 필요 없어지는 시점이 오듯, 코딩에서도 사람의 프롬프트 없이 에이전트가 스스로 판단하고 행동하는 시점이 오고 있다. 문제는 그 시점이 언제냐가 아니다. 이미 와 있다. 다만 그에 맞는 도로와 신호 체계, 즉 환경이 아직 갖춰지지 않았을 뿐이다.

그런데 이미 Claude Code가, Gemini CLI가, Cursor의 Cloud Agent가 충분히 잘 수행할 수 있는 수준에 도달했다. Anthropic의 CEO 다리오 아모데이는 2025년 3월, 미국 외교협회(CFR) 강연에서 이렇게 말했다. “3~6개월 내에 AI가 코드의 90%를 작성하게 될 것이고, 12개월 후에는 사실상 모든 코드를 AI가 작성하는 세상이 올 수도 있다(may be).” 유보적인 표현이 붙어 있었지만, 방향 자체는 단호했다. 그리고 정확히 1년이 지난 지금, 그 방향은 현실이 되어가고 있다.

Anthropic 내부에서는 일부 팀의 코드 중 90% 이상을 Claude가 작성하고 있다. Y Combinator의 2025년 겨울 배치에서는 참여 스타트업의 25%가 코드베이스의 95% 이상을 AI로 생성했다. 이미 AI가 작성하는 코드의 비중은 빠르게 증가하고 있으며, 이 추세는 되돌릴 수 없는 방향이 되었다.

사람보다 코드를 잘 작성하는 에이전트라면, 에이전트가 사람보다 앞에 있어야 하는 것이 맞다. Human-Agent가 아니라 Agent-Human 순서로. 에이전트가 먼저 분석하고, 먼저 설계하고, 먼저 코드를 작성하고, 먼저 테스트를 수행한다. 사람은 그 결과를 검토하고 방향을 조정하는 역할로 이동한다. 하지만 지금의 도구와 환경은 여전히 사람에게 귀속되어 있다. IDE는 사람이 타이핑하는 것을 전제로 설계되었고, Git은 사람이 커밋 메시지를 쓰는 것을 전제로 만들어졌으며, CI/CD 파이프라인은 사람이 트리거하는 것을 기본으로 한다. 에이전트에게 최적화된 환경은 아직 존재하지 않는 것이다.

월 200달러. 이 가격이면 거의 무제한에 가까운 AI 개발이 가능하다. Claude Max, Cursor Ultra, ChatGPT Pro 모두 이 가격대에 수렴했다. 서로 다른 비즈니스 모델을 가진 세 회사가 같은 가격에 도달했다는 것은, 시장이 ‘파워 유저 개발자가 하루 종일 에이전트를 돌리는 데 지불할 의향이 있는 금액’의 균형점을 찾았다는 뜻이다. 이 에이전트들은 24시간 일할 수 있고, 수정을 요청해도 투덜거리지 않으며, 주말도 없다. 문제는 비용이 아니다. 이 강력한 에이전트들이 일할 수 있는 ‘환경’이 아직 사람 중심으로 설계되어 있다는 것이 문제다.

에이전트를 위한 인프라가 온다

이런 생각의 연장선에서 실제로 자동화 파이프라인을 구축해본 적이 있다. Claude Code를 GitHub Actions와 연결하고, GitHub에 이슈를 올리면 에이전트가 자동으로 이슈를 분석하고, 브랜치를 생성하고, 코드를 작성하고, 테스트를 수행하며, PR을 생성하고, 리뷰 후 머지까지 처리하는 환경을 구성한 것이다. 특정 프로젝트에서 이 파이프라인이 매우 잘 작동하는 것을 확인했고, 이것이 단순한 실험이 아니라 실제 개발 방식의 미래라는 확신을 갖게 되었다.

때마침 안드레이 카파시가 autoresearch를 공개하며 큰 반향을 일으켰다. 2026년 3월 7일, 카파시는 약 630줄의 파이썬 코드로 만든 이 프로젝트를 GitHub에 올렸다. autoresearch의 핵심은 단순하면서도 혁명적이다. AI 에이전트에게 실제 LLM 학습 환경을 주고, 스스로 가설을 세우고, 코드를 수정하고, 5분간 학습을 돌리고, 결과를 평가해서 개선점을 커밋하거나 폐기하는 과정을 무한 반복하게 하는 것이다. 사람은 이 루프에 개입하지 않는다. 사람이 건드리는 것은 에이전트에게 주어지는 지시서인 program.md, 단 하나뿐이다.

결과는 놀라웠다. 카파시가 이틀 동안 돌린 결과, 에이전트는 약 700개의 자율적인 변경을 시도했고 그중 20개의 유의미한 개선을 찾아냈다. 이미 충분히 최적화되었다고 생각한 프로젝트에서 GPT-2 학습 시간을 11% 단축시킨 것이다. 카파시 본인이 20년간의 경험으로도 놓쳤던 어텐션 스케일링과 정규화의 문제점을 에이전트가 잡아냈다. 일주일 만에 GitHub 스타 3만 개를 넘겼고, Shopify의 CEO 토비 뤼트케는 이를 즉시 내부 프로젝트에 적용해 37개의 자율 실험을 돌렸다. 0.8B 규모의 모델이 기존 1.6B 모델을 능가하는 19% 성능 향상을 달성한 것이다.

카파시는 여기서 멈추지 않았다. 불과 며칠 후 agenthub를 공개했다. autoresearch가 한 명의 박사과정 연구원을 모사하는 것이었다면, agenthub는 연구 커뮤니티 전체를 모사하려는 시도다. 카파시가 직접 쓴 태그라인이 핵심을 관통한다. “GitHub is for humans. AgentHub is for agents.” GitHub의 브랜치, 풀 리퀘스트, 머지 충돌, 코드 리뷰라는 협업 모델은 모두 사람을 위해 설계된 것이다. 에이전트에게는 다른 구조가 필요하다. agenthub는 ‘main’ 브랜치 개념이 없는 순수한 git DAG, 에이전트 간 소통을 위한 메시지 보드, 에이전트별 API 키와 속도 제한 등 에이전트를 일급 시민으로 대우하는 아키텍처를 제안했다. Go 언어로 작성된 단일 바이너리와 SQLite 하나로 동작하며, 카파시 본인도 “Work in progress. Just a sketch. Thinking…“이라고 명시했다. 완성품이 아니라 사고의 프로토타입인 것이다. 하지만 이 스케치가 가리키는 방향은 분명하다. 에이전트가 주인공인 개발 환경이 필요하다는 것이다. 기존의 도구들을 에이전트가 ‘사용하게 해주는’ 수준이 아니라, 에이전트의 작업 방식에 맞춰 처음부터 설계된 환경이 필요하다는 것이다. 사람은 코드를 한 줄씩 읽지만 에이전트는 코드베이스 전체를 한 번에 인식한다. 사람은 순차적으로 한 작업을 끝내고 다음으로 넘어가지만 에이전트는 수십 개의 실험을 병렬로 돌릴 수 있다. 사람은 머지 충돌을 눈으로 해결하지만 에이전트에게는 DAG 구조의 비선형적 브랜칭이 더 자연스럽다. 같은 도구를 쓸 이유가 없다.

그런데 이 아이디어는 카파시만의 것이 아니었다. 2026년 2월 10일, GitHub의 전 CEO 토마스 돔케가 Entire라는 회사를 공개했다. 6,000만 달러의 시드 투자, 3억 달러 기업가치. 개발자 도구 역사상 가장 큰 규모의 시드 라운드였다. 돔케는 2021년부터 약 4년간 GitHub의 CEO로 재임하면서 GitHub Copilot의 성장을 이끌었던 인물이다. 그런 사람이 자신이 이끌던 플랫폼의 한계를 정면으로 지적하며 새 회사를 세운 것이다.

돔케의 진단은 명확했다. “자동차 산업이 수공업 방식의 생산 시스템을 이동식 조립 라인으로 대체했던 것처럼, 이제 우리는 기계가 코드의 주된 생산자인 세상에 맞춰 소프트웨어 개발 생명주기를 재설계해야 한다.” Entire의 구조는 세 개의 레이어로 이루어져 있다. 가장 아래에는 Git과 호환되지만 처음부터 새로 설계한 데이터베이스가 있다. Git이 ‘무엇이 바뀌었는가’만 기록한다면, 이 데이터베이스는 ‘왜 바뀌었는가’까지 저장한다. 에이전트가 코드를 변경할 때의 추론 과정, 참조한 문맥, 기각한 대안들까지 모두 기록하는 것이다. 중간에는 여러 에이전트가 함께 작업할 수 있도록 하는 시맨틱 추론 레이어가 있고, 맨 위에는 에이전트와 사람의 협업을 위한 인터페이스가 놓인다.

Entire가 가장 먼저 내놓은 오픈소스 도구의 이름은 Checkpoints다. AI 에이전트가 코드를 작성할 때 그 뒤에 숨겨진 추론 과정, 프롬프트, 의사결정 맥락을 코드와 함께 기록하는 CLI 도구다. 현재 Claude Code와 Gemini CLI를 지원한다. 지금의 에이전트 개발 과정에서 오래 방치된 문제가 하나 있다. 에이전트와의 대화는 휘발성이다. 프롬프트는 터미널에 머물고, 추론 과정은 컨텍스트 윈도우 안에서 소비되다 대화가 끝나면 사라진다. 코드는 Git에 커밋되지만, Git은 코드가 바뀐 사실만 기록할 뿐 왜 그렇게 바뀌었는지는 알려주지 않는다. 에이전트가 한 번의 세션에서 수백, 수천 줄의 코드를 생성하는 시대에 이 맥락의 부재는 치명적이다. 초기 설계의 제약 조건, 여러 대안 사이의 트레이드오프, 최종적으로 기각된 접근법들. 이 모든 것이 사라지면 남는 것은 ‘무엇’만 있고 ‘왜’는 없는 코드다. 3개월 후 그 코드를 유지보수해야 할 때, 사람도 에이전트도 왜 이 코드가 이렇게 작성되었는지 알 수 없다.

돔케는 이렇게도 말했다. “곧 개발자들은 더 이상 코드 자체를 들여다보지 않게 될 것이다. 에이전트가 사람이 리뷰할 수 있는 양보다 훨씬 많은 코드를 작성할 것이기 때문이다.” 이것은 코드 리뷰라는 개념 자체의 재정의를 의미한다. 사람이 모든 코드를 한 줄씩 읽는 대신, 에이전트의 추론 과정과 의도를 검증하는 방식으로의 전환이다.

카파시의 autoresearch와 agenthub, 돔케의 Entire. 이것들이 같은 시기에 등장한 것은 우연이 아니다. 모두 하나의 질문에 대한 답이다. 에이전트가 코드의 주된 생산자인 시대에, 에이전트를 위한 인프라는 어떤 모습이어야 하는가. autoresearch는 에이전트가 자율적으로 실험하고 학습하는 루프의 프로토타입이고, agenthub는 에이전트 간 대규모 협업을 위한 플랫폼의 스케치이며, Entire는 이 모든 것을 상업적 규모로 구현하려는 첫 번째 기업이다. 카파시가 X에서 밝힌 다음 단계의 비전도 같은 방향을 가리킨다. “SETI@home처럼 비동기적으로 대규모 협업하는 에이전트 시스템이 되어야 한다. 목표는 한 명의 박사과정을 모사하는 것이 아니라, 연구 커뮤니티 전체를 모사하는 것이다.”

에이전트가 일하는 현장

이론이 아닌 현실을 보자. 자율 개발 에이전트는 이미 실제 코드베이스에서 일하고 있으며, 그 규모는 빠르게 확대되고 있다.

GitHub의 Copilot 코딩 에이전트는 이슈가 할당되면 격리된 GitHub Actions 환경에서 코드를 분석하고, 변경사항을 구현하고, 테스트를 수행한 뒤 드래프트 PR을 생성한다. 스스로 코드를 리뷰한 뒤 사람에게 승인을 요청하는 것까지가 자동이다. 2026년 3월에는 Jira 연동도 추가되어, 프로젝트 매니저가 Jira에 이슈를 등록하면 에이전트가 자동으로 개발에 착수하는 워크플로우가 가능해졌다. 1,500만 명 이상의 개발자가 사용하고 있으며, 포춘 100대 기업의 90%가 고객이다.

Cursor의 Cloud Agent는 더 극적이다. 2026년 2월에 출시된 이 기능에서 각 에이전트는 독립된 우분투 가상머신 안에서 동작한다. 레포지토리를 클론하고, 코드를 작성하고, 테스트를 수행하고, 브라우저를 열어 직접 UI를 클릭하며 결과를 확인하고, 머지 가능한 상태의 PR을 전체 세션의 비디오 녹화와 함께 전달한다. 25시간 이상 자율적으로 작업을 이어가는 것도 가능하다. Cursor를 만든 Anysphere는 에이전트 사용량이 1년 만에 15배 증가했다고 밝혔고, 탭 자동완성 사용자보다 에이전트 사용자가 2배 더 많아졌다. 2025년 3월만 해도 자동완성이 주류였던 것을 생각하면, 코딩 도구의 패러다임 자체가 1년 만에 뒤집힌 것이다.

자율 코딩 에이전트의 원조격인 Devin도 빠르게 성숙하고 있다. Slack이나 Teams를 통해 비동기적으로 작업을 수행하며, 자체 샌드박스 환경에서 셸, 에디터, 브라우저를 자유롭게 사용한다. PR 머지율이 전년 대비 34%에서 67%로 두 배 가까이 올랐다. 핀테크 기업 Ramp에서는 주당 최대 80건의 PR을 Devin이 처리한다. 브라질의 디지털 은행 Nubank의 사례는 더 인상적이다. 8년간 쌓인 600만 줄 이상의 레거시 ETL 코드를 마이그레이션하는 작업이었는데, 원래 1,000명의 엔지니어가 18개월 걸릴 것으로 추산된 프로젝트를 수 주 만에 완료했다. 사람이라면 코드를 읽고, 이해하고, 새로운 아키텍처에 맞게 재작성하는 과정에서 컨텍스트 스위칭 비용이 엄청났을 것이다. 에이전트는 피로하지 않고, 600만 줄의 코드를 읽는 데 감정적 저항이 없으며, 패턴을 인식하는 속도가 사람과 비교할 수 없이 빠르다.

OpenAI의 Codex는 주간 활성 사용자가 160만 명을 돌파했고 2026년 초 이후 3배로 증가했다. Google의 Gemini CLI는 Apache 2.0 오픈소스로 가장 관대한 무료 티어를 제공 중이다. 분당 60회 요청, 하루 1,000회까지 무료이며, GitHub Actions와 연동하여 이슈 트리아지, PR 리뷰, 위임된 개발까지 자동화할 수 있다.

이 도구들은 각각 강력하지만, 한 가지 공통점이 있다. 여전히 사람이 시작 버튼을 누르고, 사람이 최종 배포를 승인한다는 것이다. 완전한 자율은 아직 아니다. 하지만 코드 분석, 설계, 구현, 테스트, PR 생성까지 그 중간의 모든 과정은 이미 에이전트가 혼자서 해내고 있다. 그리고 이 ‘중간’의 범위가 빠르게 확장되고 있다. Ramp의 경우 Airflow 에러 로그가 발생하면 자동으로 Devin이 트리거되어 문제를 수정하고 PR을 여는 파이프라인을 운영 중이다. 시작 버튼마저 사람이 아닌 시스템이 누르기 시작한 것이다. 이쯤 되면 질문을 바꿔야 한다. “에이전트가 코딩을 할 수 있는가”가 아니라, “에이전트가 코딩을 잘 하기 위해 어떤 환경이 필요한가”가 진짜 질문이다.

바이브 코딩 그 이후

여기서 한 걸음 더 나아가 생각해볼 것이 있다. 지금 일어나고 있는 변화의 성격이다. 이것은 도구의 업그레이드가 아니라 역할의 재정의다.

2025년 2월, 카파시는 ‘바이브 코딩’이라는 개념을 만들어냈다. AI에게 자연어로 지시하고, 결과물의 ‘느낌(vibe)’이 맞으면 수용하는 방식이었다. 코드를 읽지 않고, 에러가 나면 에러 메시지를 그대로 붙여넣고, 되면 되는 대로 가는 것. 이 용어는 폭발적으로 확산되었고, AI 코딩의 첫 번째 문화를 형성했다.

하지만 정확히 1년 후인 2026년 2월, 같은 카파시가 바이브 코딩의 시대가 지났다고 선언하며 ‘에이전틱 엔지니어링’이라는 새 개념을 제시했다. “새로운 기본값은, 99%의 시간 동안 직접 코드를 작성하지 않는 것이다. 에이전트를 오케스트레이션하고 감독하는 것이며, 거기에는 기술과 과학, 그리고 전문성이 필요하다.” 바이브에서 엔지니어링으로의 전환. 느낌으로 코딩하던 시대에서, 에이전트를 체계적으로 운용하는 시대로의 이행이다. 같은 사람이 만든 용어가 1년 만에 교체된다는 것 자체가 이 분야의 변화 속도를 보여준다.

이 전환이 의미하는 바는 깊다. 바이브 코딩이 ‘아무나 코드를 만들 수 있다’는 민주화의 서사였다면, 에이전틱 엔지니어링은 ‘에이전트를 잘 운용하는 것이 새로운 전문성이다’라는 재전문화의 서사다. 코드를 직접 작성하는 능력의 가치는 줄어들지만, 에이전트가 올바른 코드를 작성하도록 환경을 설계하고, 결과를 검증하고, 시스템 전체의 방향을 잡는 능력의 가치는 오히려 높아진다. 바이브 코딩에서는 결과물이 대충 돌아가면 충분했지만, 에이전틱 엔지니어링에서는 테스트 커버리지, 보안 검증, 성능 기준, 배포 전략까지 모두 에이전트의 작업 범위 안에 들어온다. 느슨한 지시가 아니라 정밀한 설계가 필요한 것이다.

결국 이것은 소프트웨어 엔지니어링이라는 분야 자체의 재정의다. 가치가 코드를 작성하는 것에서 코드를 검증하는 것으로 이동하고 있다. 요구사항 분석, 아키텍처 설계, 코딩, 테스트, 비평까지 각각의 역할을 전문화된 에이전트들이 분담하는 다중 에이전트 구조가 현실로 다가오고 있다. 마치 건축 현장에서 설계사, 구조 엔지니어, 시공팀, 감리팀이 각자의 전문성으로 협업하는 것처럼, 한 명의 개발자가 10~20개의 에이전트를 동시에 지휘하는 모습은 더 이상 공상과학이 아니다.

그런데 여기에 역설이 하나 있다. AI 코딩 도구의 사용률은 빠르게 증가하고 있지만, 에이전트가 만들어낸 코드에 대한 신뢰는 오히려 줄고 있다. 에이전트가 만들어낸 코드를 믿을 수 있느냐는 질문은, 결국 에이전트가 어떤 환경에서 어떤 맥락으로 그 코드를 작성했는지를 추적할 수 있느냐는 질문과 같다. 에이전트의 능력과 사람의 신뢰 사이의 간극, 이것을 메우는 것이 바로 AutoDevAgent 환경의 역할이다.

자동 피드백 시스템이라는 새로운 환경

이 환경을 ‘자동 피드백 시스템’이라 부르고 싶다. 사람 사이의 피드백을 통해 사람과 서비스가 성장하듯, AutoDevAgent와 피드백을 주고받으며 에이전트도 사람도, 그리고 소프트웨어도 함께 성장하는 구조다. 카파시의 autoresearch가 정확히 이 구조로 동작한다. 에이전트가 가설을 세우고, 실험하고, 결과를 평가하고, 개선하는 무한 루프. 사람은 그 루프의 규칙을 설계할 뿐, 루프 안에 들어가지 않는다. 카파시는 이렇게 썼다. “당신은 연구자로서 평소처럼 파이썬 파일을 만지는 것이 아니다. 대신 program.md 마크다운 파일을 프로그래밍하는 것이다.” 코드를 작성하는 것이 아니라, 코드를 작성하는 에이전트의 행동 규칙을 설계하는 것. 이것이 새로운 시대의 ‘개발’이다.

여기서 핵심적인 통찰이 하나 있다. 자동 피드백 시스템이 작동하려면 에이전트의 행동이 ‘관찰 가능’해야 한다는 것이다. 에이전트가 무엇을 했는지, 왜 그런 결정을 내렸는지, 어떤 대안을 검토하고 기각했는지가 기록되어야 피드백이 가능하다. 이것이 바로 돔케의 Entire가 Checkpoints를 첫 번째 제품으로 내놓은 이유이며, 카파시의 autoresearch가 모든 실험 결과를 git에 커밋하도록 설계된 이유다. 관찰할 수 없는 에이전트에게는 피드백을 줄 수 없고, 피드백을 받지 못하는 에이전트는 성장하지 못한다.

사람 개발자가 개발할 때 환경 구성이 중요하듯, AutoDevAgent가 개발하는 환경을 구성하는 것도 마찬가지로 중요하다. 아니, 어쩌면 더 중요하다. 사람은 환경이 불완전해도 경험과 직관으로 보완할 수 있지만, 에이전트에게는 환경이 곧 세계의 전부이기 때문이다. 에이전트가 접근할 수 있는 코드베이스의 범위, 실행할 수 있는 테스트의 종류, 참조할 수 있는 문서와 히스토리, 다른 에이전트와 소통할 수 있는 채널. 이 모든 것이 환경이고, 이 환경의 질이 곧 에이전트의 출력 품질을 결정한다. 인간의 최소 통제 속에서 개발을 진행하는 AutoDevAgent를 위한 환경 구성. 이것이 AI 에이전트 코딩 시대의 새로운 프레임워크가 될 것이다.

20년 전 프레임워크가 개발자에게 표준화된 환경을 제공하여 생산성을 높였듯이, 자동 피드백 시스템은 에이전트에게 자율적으로 일할 수 있는 환경을 제공한다. 차이가 있다면, 이전의 프레임워크는 사람의 실수를 줄이기 위한 것이었고, 새로운 환경은 에이전트의 자율성을 극대화하기 위한 것이라는 점이다.

정리하면 이런 그림이다. 20년 전 한국의 SI 회사들이 자체 프레임워크로 개발자의 생산성을 높였다. 그 프레임워크들은 오픈소스의 성숙과 표준프레임워크의 등장으로 보편화되었고, 프레임워크 자체는 경쟁력이 아닌 기본값이 되었다. 지금 같은 일이 다시 반복되고 있다. GitHub, IDE, CI/CD로 대표되는 현재의 개발 환경은 사람을 위해 설계된 것이다. 그러나 개발의 주체가 에이전트로 이동하면서, 에이전트를 위한 환경이 새로운 프레임워크로 부상하고 있다. 카파시의 autoresearch와 agenthub는 그 첫 번째 스케치이고, 돔케의 Entire는 그 스케치를 산업 규모로 구현하려는 첫 번째 회사다.

지금 이 환경을 설계하는 것이 곧 다음 시대의 경쟁력이다. 20년 전 프레임워크를 만들 수 있느냐가 개발자의 실력을 증명했듯이, 앞으로는 에이전트가 자율적으로 일할 수 있는 환경을 설계할 수 있느냐가 새로운 기준이 될 것이다. 사람과 에이전트 사이의 자동 피드백 시스템이 동작하는 환경, Human의 최소 통제 속에서 Agent가 먼저 행동하는 구조. 그것이 AI 코딩 시대의 프레임워크다. 그리고 이 프레임워크를 먼저 완성하는 자가, 20년 전의 프레임워크 개발자들이 그랬듯이, 다음 시대의 표준을 정의하게 될 것이다.

참고 자료