에이전트가 터미널 안으로 들어왔다. 스마트폰 화면에도 올라탔다. 심지어 쓸수록 스스로 나아진다고 주장하기 시작했다. 2025년 상반기, AI 코딩 에이전트 씬에는 세 가지 뚜렷한 벡터가 동시에 출현했다. 각각이 '어디서', '언제', '얼마나 스스로' 작동하는지를 정의하는 벡터들이다. 그리고 이 세 흐름은 합쳐졌을 때 개발자에게 하나의 날카로운 질문을 던진다. 무엇을 위임하고, 무엇을 직접 설계할 것인가.
1. 터미널 장악 전략: Grok Build가 노리는 것
xAI가 공개한 Grok Build는 표면적으로 'CLI 기반 AI 코딩 에이전트'다. 하지만 실제로 들여다보면 전략적 포지셔닝이 더 선명하다. Cursor나 GitHub Copilot이 IDE 레이어에서 개발자 경험을 장악했다면, Grok Build는 터미널 레이어를 점령하려 한다. 개발자가 가장 날 것의 상태로 시스템과 대화하는 그 공간이다.
주목할 기능은 두 가지다. 첫째, Plan Mode. 단순히 코드를 생성하는 게 아니라 복잡한 작업을 단계별 계획으로 먼저 제시하고, 개발자가 승인·수정·재작성을 결정할 수 있게 한다. 계획이 확정된 이후에만 코드 변경이 발생하고, 변경 사항은 diff 형태로 추적된다. 이건 단순한 UX 디테일이 아니다. '에이전트가 뭘 하려는지 개발자가 항상 알 수 있어야 한다'는 인간 감독 원칙을 워크플로우 구조 안에 박아넣은 설계다.
둘째, 병렬 서브에이전트 구조. 대규모 작업을 여러 전문화된 서브에이전트에 분산해 동시에 처리할 수 있고, 각 에이전트는 독립적인 Git worktree에서 실행된다. 멀티 기능 개발이나 대규모 리팩토링을 동시에 돌릴 수 있다는 의미다. AGENTS.md, MCP 서버, 훅 등 기존 개발 생태계 요소를 별도 설정 없이 자동 인식한다는 점도 눈에 띈다. 마찰을 최소화하면서 기존 워크플로우 안에 조용히 녹아드는 전략이다.
인공지능신문 보도 기준으로, xAI는 현재 SuperGrok Heavy 구독자 대상 얼리 베타로 제공 중이다. 경쟁 지형은 이미 OpenAI Codex, Anthropic Claude Code, Google Gemini Code Assist, GitHub Copilot으로 빼곡하다. 그 사이에서 Grok Build가 택한 차별점은 코드 생성 성능보다 오케스트레이션과 제어 가능성이다. 이 방향은 AI 코딩 경쟁의 다음 라운드가 어디서 벌어질지를 시사한다.
2. 모바일 통합: Codex가 바꾸는 '개발 장소'의 정의
OpenAI가 ChatGPT 모바일 앱에 Codex를 통합한 건 단순한 기능 추가가 아니다. 이건 개발이 일어나는 장소의 개념을 해체하는 시도다. 코드는 여전히 개발자의 로컬 머신이나 원격 서버에 있다. 인증 정보도, 파일 권한도 그쪽에 있다. 스마트폰은 그 모든 걸 제어하는 경량 지휘 단말기 역할만 한다.
핵심 경험은 '연속적 협업'이다. 커피를 기다리는 3분 동안 버그 조사를 시작하고, 출근길에 리팩토링 방향을 결정하고, 회의 전에 브리핑 생성을 승인한다. Codex가 수행하는 작업 스레드를 실시간으로 확인하고, 방향을 수정하거나 명령을 승인하는 '짧은 개입'이 이제 데스크톱 없이도 가능해졌다. aitimes 보도에 따르면 전 세계 400만 명 이상이 매주 Codex를 사용하고 있다.
보안 설계도 흥미롭다. 공개 인터넷에 직접 노출되지 않는 보안 릴레이 인프라를 별도 구축했다. Remote SSH 정식 출시, 프로그래밍 방식 액세스 토큰, Hooks 기능, HIPAA 지원까지 함께 공개됐다. 이건 Codex 모바일 통합이 개인 개발자 편의가 아니라 기업 환경에서의 에이전트 상시 운용을 목표로 설계됐다는 걸 보여준다.
3. Self-improving: Hermes Agent가 증명하려는 것
'쓸수록 나아진다'는 말은 마케팅 카피처럼 들리기 쉽다. 그런데 Nous Research가 MIT 라이선스로 공개한 Hermes Agent는 이걸 코드 레벨에서 구현했다는 점에서 다르다. 요즘IT 분석 기준으로, 자가 성장 구조는 세 개의 핵심 디렉토리로 작동한다. 에이전트 루프 본체인 agent/, 절차적 기억이 쌓이는 skills/, 사용 흔적을 다음 세대 모델 학습 데이터로 변환하는 environments/.
Self-improving의 실제 메커니즘은 이렇다. 도구 호출 5회 이상의 작업을 완료하면 그 절차를 마크다운 문서로 ~/.hermes/skills/에 자동 저장한다. 무작정 쌓는 게 아니라 '다시 쓸 만한 절차'만 선별해 남긴다. 저장된 스킬은 유사한 상황에서 에이전트가 자동으로 검색해 활용한다. 메모리 검색에는 외부 벡터 DB 대신 SQLite FTS5를 써서, 5달러짜리 가상 서버에서도 1만 개 이상 문서를 10ms 안에 처리한다.
더 흥미로운 건 메모리 갱신 구조다. 에이전트가 작업 중에 자기 기록을 직접 add·replace·remove로 수정한다. 절차가 부정확했거나, 환경이 바뀌었거나, 더 나은 방법을 발견했을 때 스스로 고치는 루프다. 여기에 Honcho 기반 외부 메모리 백엔드가 붙어 사용자의 발화·선호·작업 패턴을 세션 너머에서 누적한다. 다음 세션에서 처음부터 다시 설명하지 않아도 된다.
결과는 숫자로 나왔다. 출시 두 달 반 만에 OpenRouter 일간 토큰 사용량 1위. 누적 사용 토큰 1조 200억 개. GitHub star 11주 차 14만 5천 개. 커뮤니티 반응에서 특히 주목할 건 '출시 때 폭발적 하이프'가 아니라 '한 달 굴린 다음에야 진짜 모양이 드러나는 도구'라는 평가다. 이건 Hermes가 지향하는 가치와 정확히 일치한다.
세 흐름이 수렴하는 질문: 위임의 기술
터미널 장악(Grok Build), 모바일 상시 접속(Codex), 절차적 자기개선(Hermes). 이 세 흐름을 하나의 축으로 읽으면 공통된 방향이 보인다. 에이전트가 더 깊이, 더 넓게, 더 오래 개발자의 워크플로우 안에 상주한다. 더 이상 '필요할 때 켜는 도구'가 아니라 '항상 켜져 있는 작업자'로 진화하고 있다.
이 변화가 프론트엔드 개발자에게 던지는 실용적 질문은 세 가지다.
첫째, 어떤 작업을 에이전트에 위임할 것인가. Plan Mode처럼 에이전트가 먼저 계획을 내놓고 개발자가 승인하는 구조는, 역설적으로 개발자가 '무엇이 좋은 계획인지 판단할 수 있는 능력'을 더 요구한다. 코드 생성은 위임하되 아키텍처 방향 설정과 품질 기준은 직접 쥐어야 한다.
둘째, 에이전트의 기억 설계에 얼마나 투자할 것인가. Hermes의 AGENTS.md, skills 디렉토리, MEMORY.md는 개발자가 직접 설계하고 관리해야 하는 영역이다. 에이전트가 쌓는 기억의 질은 결국 초기에 개발자가 무엇을 가르치고 어떤 절차를 승인했는지에 달려 있다.
셋째, 모바일 접근성이 생겼을 때 '짧은 개입'을 어떻게 설계할 것인가. 에이전트가 장시간 자율적으로 돌아가는 환경에서는 중간 체크포인트의 품질이 최종 결과물의 품질을 결정한다. 언제 어떤 판단을 내릴지에 대한 개발자의 기준이 더 중요해진다.
물론 경계해야 할 것도 있다. Hermes 커뮤니티가 지적한 대로, 스킬 포이즈닝, MCP 서버 샌드박스 부재, 자격 증명 노출 리스크는 실제 팀 환경에서 무시하기 어려운 문제다. 에이전트가 내 컴퓨터와 계정의 권한을 상당 부분 위임받는 구조에서 거버넌스 설계는 선택이 아니라 전제 조건이다.
에이전트 시대의 개발자 역량은 점점 더 '무엇을 어떻게 위임하는지 설계하는 능력'으로 수렴하고 있다. 터미널에서, 스마트폰에서, 잠자는 사이에도 돌아가는 에이전트를 갖게 됐을 때—개발자의 진짜 레버리지는 그 에이전트에게 무엇을 가르치고, 어떤 경계를 그어주고, 어느 순간에 직접 개입할지를 결정하는 판단력에 있다. 도구의 3세대가 열렸다. 그 도구를 다루는 방식도 3세대로 업그레이드할 차례다.