오픈소스 에이전트)#

키보드를 치는 로봇과 지도를 들고 화면을 가리키는 사람, 여러 모니터에 각기 다른 작업이 떠 있는 모습

기준 시점 · 2026년 10월. 코딩 에이전트는 거의 매주 기능이 추가되는 영역입니다. 이 장은 도구의 "형태"와 "고르는 원칙"에 집중하고, 특정 기능의 유무는 사용 시점에 확인하기 바랍니다.

코딩 에이전트를 별도의 장으로 다루는 이유는 분명합니다. 1인 스타트업에서 제품을 만드는 손이 바로 이 도구이기 때문입니다. 필자의 경우 “직접 타이핑하는 코딩"에 쓰는 시간이 몇 년 사이 극적으로 줄었고, 그 자리를 “에이전트에게 요구사항을 전달하고 결과를 검토하는 일"이 채웠습니다. 이 장은 그 도구들을 어떻게 이해하고 고르고 쓰는지를 정리합니다.

먼저 세 단어를 구분합니다: 모델, 에이전트, 클라이언트#

이 주제가 헷갈리는 가장 큰 이유는 모델, 에이전트, 클라이언트가 한꺼번에 섞여서 이야기되기 때문입니다.

모델: 생각하는 두뇌입니다. 1장에서 설명한 LLM 그 자체입니다.
에이전트: 두뇌를 실제로 일하게 만드는 작업 방식입니다. 파일을 읽고, 코드를 고치고, 명령을 실행하고, 테스트 결과를 보고 다시 고치는 반복 루프와, 그 루프를 감싸는 규칙(하네스)까지 포함합니다.
클라이언트: 사람이 에이전트를 사용하는 창구입니다. 에디터, 터미널, 데스크톱 앱, 웹, 메신저가 여기에 해당합니다.

쉽게 비유하면 모델은 엔진, 에이전트는 운전 방식과 변속기, 클라이언트는 운전석입니다. 겉으로는 같은 차처럼 보여도 엔진만 같고 운전 방식이 다르면 체감이 꽤 달라집니다. 예를 들어 Cursor의 채팅에서 OpenAI의 코딩 모델을 고르는 것과 Cursor 안에 Codex 확장을 설치해 쓰는 것은 전혀 다른 일입니다. 전자는 Cursor의 에이전트가 OpenAI 모델을 쓰는 것이고, 후자는 OpenAI의 에이전트가 Cursor라는 운전석에 들어온 것입니다. 같은 모델이라도 어떤 도구를 주고, 어떤 순서로 컨텍스트를 넣고, 실패했을 때 어떻게 재시도하는지가 다르기 때문에 결과가 달라집니다. 4장(에이전트와 하네스)에서 이 차이를 더 깊게 다룹니다.

도구 이름 하나에 세 층이 섞여 있습니다. 비교할 때는 어느 층을 비교하는지 먼저 정합니다.

형태별로 보는 코딩 에이전트#

같은 “코딩 AI"라도 성격이 꽤 다른데, 두 개의 축으로 보면 정리가 쉽습니다. 하나는 누가 운전하는가입니다. 사람이 주도하고 AI가 거드는 보조형(자동완성)부터, AI가 작업을 통째로 맡는 자율형까지의 스펙트럼입니다. 다른 하나는 어디서 도는가입니다. 내 로컬 에디터나 터미널인지, 클라우드에서 비동기로 도는지, 서버에 상주하며 메시지로 호출되는지입니다.

형태	대표 도구	성격	잘 맞는 상황
IDE형	Cursor, Windsurf, Antigravity, GitHub Copilot	에디터 안에서 사람이 운전하며 자동완성 · 채팅 · 에이전트를 함께 씀	코드를 보면서 방향을 자주 바꾸는 작업, 설계가 유동적인 초기 개발
CLI형	Claude Code, Codex CLI, Gemini CLI, Aider	터미널에서 저장소 전체를 다루며 작업을 맡김. 스크립트와 CI에 붙이기 쉬움	명확한 요구사항의 구현, 리팩터링, 테스트 보강, 자동화
클라우드 · 앱 생성형	Codex Web, Jules, Devin, v0 / Lovable / Replit	목표만 주면 비동기로 작업하거나, 프롬프트만으로 앱을 즉시 생성	로컬 머신을 점유하지 않는 긴 작업, 프로토타입
상주형(데몬)	Hermes Agent, OpenClaw	서버에 띄워 두고 메신저로 호출. 메모리와 스킬을 축적하며 크론으로 무인 실행	반복 운영 업무, 팀 공용 봇, 노트북을 닫아도 돌아가는 작업

형태가 다를 뿐 우열은 아닙니다. 필자는 네 형태를 모두 쓰고 있고, 작업의 성격에 따라 고릅니다.

Cursor: AI 중심 IDE#

GitHub Copilot이 개발자들 사이에서 신선한 충격을 주고 있던 흐름 속에서, 비교적 빠른 시기에 Cursor 같은 “AI 중심(AI-first) IDE"가 등장했습니다. Cursor는 VS Code 기반의 에디터 경험 위에, 코드 자동완성 / 채팅을 넘어 코드베이스 단위의 변경 작업을 맡기는 워크플로를 전면에 둔 도구입니다. 비슷한 계열로 Windsurf와 구글의 Antigravity 등이 있습니다.

필자가 처음 Cursor를 사용하기 시작했을 때는 “Copilot보다 조금 더 좋은 수준"처럼 느껴졌습니다. 하지만 에이전트 기능이 들어오면서 체감이 크게 달라졌습니다. 요구사항을 전달하면 에이전트가 코드베이스를 탐색하고 여러 파일을 수정하며, 필요한 경우 수정 이유를 설명하는 식으로 “작업을 끝까지 밀어주는” 경험에 가까워졌기 때문입니다. 지금은 에이전트가 브라우저를 띄워 화면을 확인하거나, MCP로 외부 서비스를 다루거나, 여러 작업을 병렬로 돌리는 것까지 IDE 안에서 됩니다.

Claude Code: 터미널에서 저장소를 맡기는 에이전트#

Claude Code는 Anthropic의 코딩 에이전트로, 터미널에서 출발해 IDE 확장, 데스크톱 앱, 웹, 메신저로 운전석을 넓혀 왔습니다. 저장소 루트의 지침 파일(CLAUDE.md)을 읽고 시작하고, 반복 작업을 절차로 고정하는 스킬, 세션 간 지식을 쌓는 메모리, 서브에이전트로 작업을 나누는 기능, 외부 도구를 붙이는 MCP를 갖추고 있습니다. 필자는 이 블로그의 글 작성 · 번역 · 뉴스 브리프 작성을 Claude Code의 스킬로 올려 두고 운영하며, 회사에서는 Cursor를 메인으로 두고 Claude Code를 보조로 씁니다.

Codex: OpenAI의 에이전트 런타임#

Codex는 OpenAI의 코딩 에이전트인데, 처음 접하면 CLI, 데스크톱 앱, 웹, IDE 확장, SDK가 각각 무엇인지 헷갈리기 쉽습니다. 공식 문서를 기준으로 정리하면, CLI / 앱 / 웹 / IDE 확장은 같은 Codex 에이전트를 다른 운전석에서 쓰는 것이고, SDK는 그 에이전트를 프로그램에서 제어하는 인터페이스입니다. 반면 Cursor 채팅에서 OpenAI 모델을 고르는 것은 Codex 모델은 쓰지만 Codex 에이전트를 쓰는 것은 아닙니다. 필자는 CLI를 기준점으로 삼고, 필요할 때 Claude Code 안에서 Codex를 리뷰어로 불러 쓰는 플러그인(다른 모델의 관점으로 코드를 한 번 더 검토하게 하는 용도)도 활용합니다.

오픈소스와 상주형 에이전트#

OpenCode, Aider, Cline 같은 오픈소스 에이전트는 어떤 모델이든 붙일 수 있고 코드가 공개되어 있다는 점이 강점입니다. 상주형인 Hermes Agent는 한 걸음 더 나가서, 서버에 띄워 두고 Slack이나 Discord에서 메시지로 부리고, 작업 경험에서 스스로 스킬을 만들고, 크론으로 일일 리포트 같은 무인 작업을 돌립니다. Docker 같은 컨테이너 백엔드를 고르면 에이전트의 행동 반경을 “마운트한 폴더만"으로 정확히 제한할 수 있다는 점도 중요합니다. 필자는 회사에서 Hermes를 제품 개발과 광고 운영 양쪽에 쓰고 있고, 개인용으로도 원격 서버에 띄워 노트북을 닫아도 일하는 환경을 만들었습니다. 그 경험은 실행 편의 “혼자 일 나누기"에서 다룹니다.

필자가 쓰는 방식: 페어 프로그래밍의 내비게이터#

Cursor로 개발하는 경험은 페어 프로그래밍에 비유할 수 있습니다. 에이전트가 드라이버(코드 작성 / 수정)를 맡고, 개발자는 내비게이터(개발 방향 / 요구사항 전달 / 결과 검토)를 맡는 형태입니다. 이때 내비게이터 역할의 핵심은 “코드를 대신 짜게 하는 것"이 아니라, 목표 / 제약 / 품질 기준을 명확히 주고 결과를 검토해 의도에 맞게 수렴시키는 것입니다.

몇 가지 습관이 결과의 품질을 크게 좌우합니다.

테스트로 끝을 정의합니다. 에이전트에게 테스트 코드를 작성하게 하고 실제로 실행해서 “작업이 끝났는지"를 스스로 점검하게 만듭니다. “그럴듯해 보이는 결과"가 아니라 “동작이 검증된 결과"로 마무리하는 습관입니다.
지침은 채팅이 아니라 파일에 둡니다. 3장에서 본 규칙 파일, 스킬, 메모리 구조입니다. 도구마다 인식하는 파일명이 달라서(Claude Code는 CLAUDE.md, Cursor는 .cursor/rules/, Codex는 AGENTS.md), 메인 도구의 파일에 규칙을 쓰고 나머지 도구의 파일은 그것을 참조하게 만들면 규칙을 한 곳에서만 관리할 수 있습니다.
병렬로 돌리되 사람의 리듬을 지킵니다. 서로 다른 작업을 여러 세션으로 동시에 진행하면 개발자 한 명이 두세 개의 일을 처리하는 효과가 납니다. 다만 세션 사이를 오가는 사람의 머리가 새로운 병목이 됩니다. 이 문제는 실행 편의 “혼자 일 나누기"에서 따로 다룹니다.
다른 모델로 한 번 더 봅니다. 중요한 변경은 다른 벤더의 모델로 리뷰를 돌립니다. 같은 모델이 쓰고 같은 모델이 검토하면 같은 맹점을 공유합니다.

마지막으로, 필자는 코딩 에이전트가 “개발자만을 위한 도구"에 머물지 않는다고 느꼈습니다. 코드 작성 외에도 로컬 파일을 읽고 수정하거나, 작업을 자동화하기 위해 명령을 실행하고, 외부 도구를 연결해 업무 흐름을 확장할 수 있기 때문입니다. 이 책의 원고 자체도 코딩 에이전트와 함께 썼습니다. 비개발 업무에 이 방식을 적용하는 이야기는 4부에서 이어집니다.

도구를 고르는 원칙#

필자는 처음에는 “어떤 도구에 정착해야 하나"를 고민했지만, 결국 비슷한 컨셉의 도구들이 서로 경쟁하며 빠르게 기능을 따라잡는 구조라고 보고 일단 하나에 정착하기로 했습니다. 다른 도구에 새로운 기능이 추가되면 곧 비슷한 기능이 들어올 것이라는 가정 아래, 도구 선택의 비용보다 업무 방식 자체를 바꾸는 데 집중한 것입니다. 그 뒤로 몇 가지 원칙이 생겼습니다.

기준점 하나를 먼저 잡습니다. 메인 도구를 정하고 그 도구의 지침 파일과 스킬을 자산으로 쌓습니다. 다른 도구는 역할(리뷰어, 병렬 작업자, 상주 봇)별로 붙입니다.
구독의 경제성을 활용합니다. 개인이 하루 종일 쓰는 코딩 에이전트는 월 구독이 API보다 훨씬 경제적입니다. 다만 그 구독을 내 제품의 백엔드로 끌어다 쓰려는 시도는 하지 않습니다(앞 장 참고).
도구 종속을 파일 구조로 막습니다. 규칙, 설계 문서, 메모리를 저장소 안의 평범한 마크다운으로 두면 어떤 도구로 열어도 같은 컨텍스트에서 시작합니다.
기본값을 믿지 않습니다. 샌드박스는 기본으로 꺼져 있고, 질문에 답이 없으면 멈춰 있고, 읽지 말라고 적어 둔 파일도 읽을 수 있습니다. 이 한계와 대응은 실행 편의 운영 장에서 다룹니다.

정리#

코딩 에이전트는 모델 · 에이전트 · 클라이언트의 세 층으로 나눠 이해해야 비교가 됩니다.
IDE형, CLI형, 클라우드형, 상주형은 우열이 아니라 작업 성격에 따른 선택입니다.
사람은 내비게이터입니다. 테스트로 끝을 정의하고, 지침을 파일에 두고, 다른 모델로 검토합니다.
기준점 하나를 잡고, 구독의 경제성을 쓰고, 종속은 파일 구조로 막고, 기본값은 믿지 않습니다.