이번 포스팅에서는 터미널 기반 AI 페어프로그래밍 도구인 aider에 대해서 정리하고자 한다. Cursor나 VS Code 확장이 에디터 안에서 AI를 붙이는 방식이라면, aider는 반대로 터미널에 상주하면서 git 저장소를 직접 다루는 방식이다. 요청을 말하면 파일을 고치고, 고친 내용을 곧바로 커밋해 준다. GitHub 스타 4.8만 개를 넘긴 이 도구를 두고 설치부터 모델 연결, 세 가지 채팅 모드, git 안전장치, 설정 파일까지 실무 관점에서 짚어 본다.
aider가 Cursor·Claude Code와 다른 지점
aider는 에디터에 종속되지 않는 터미널 CLI라는 점에서 가장 크게 갈린다. Cursor처럼 전용 에디터를 깔 필요도, VS Code 확장을 설치할 필요도 없다. 어떤 편집기를 쓰든 그대로 두고, 터미널 한 칸만 aider에 내주면 된다. 대신 aider는 git 저장소를 1급 시민으로 취급한다. 코드를 수정하면 자동으로 커밋하고, 마음에 안 들면 커밋 하나를 통째로 되돌린다.
세 도구의 성격을 한 줄로 비교하면 이렇다.
| 도구 | 형태 | git 연동 | 컨텍스트 파악 |
|---|---|---|---|
| aider | 터미널 CLI(에디터 무관) | 자동 커밋·되돌리기 내장 | 저장소 전체 맵(repo map) |
| Cursor | 전용 에디터(VS Code 포크) | 수동 | 열린 파일·인덱스 |
| Claude Code | 터미널 CLI | 수동/훅 | 파일 읽기·검색 |
Claude Code·Codex를 직접 쓰는 것과 비교하면
Claude Code나 OpenAI Codex CLI도 터미널에서 도는 AI 코딩 도구라 aider와 자주 비교된다. 셋 다 CLI지만 지향점이 다르다. Claude Code·Codex는 각 벤더가 자사 모델에 맞춰 만든 에이전트형 도구로, 스스로 파일을 탐색·수정하고 명령을 실행하는 자동화에 강하다. 반면 aider는 모델을 갈아 끼우는 개방성과 git 중심의 명시적 통제가 특징이다. 장단점을 정리하면 이렇다.
| 관점 | aider | Claude Code / Codex 직접 사용 |
|---|---|---|
| 모델 선택 | Claude·GPT·Gemini 등 자유롭게 교체·혼합(architect+editor) | 대체로 자사 모델에 고정(Claude / GPT 계열) |
| 파일 제어 | /add로 편집 범위를 직접 지정 — 명시적·안전 | 에이전트가 알아서 탐색·수정 — 편하지만 범위가 넓음 |
| git 연동 | 변경마다 자동 커밋 + /undo 되돌리기 내장 | 도구별로 상이(커밋은 대체로 수동/직접) |
| 자동화 수준 | 대화 주도 — 사람이 단계마다 개입 | 에이전트 주도 — 다단계 작업을 스스로 진행 |
| 비용 | 쓴 API 토큰만큼 pay-as-you-go | 구독 또는 API(도구·플랜에 따라 다름) |
정리하면, “여러 모델을 저울질하며 변경 하나하나를 git으로 통제하고 싶다”면 aider가, “한 벤더 생태계 안에서 에이전트에게 일을 통째로 맡기고 싶다”면 Claude Code·Codex가 손에 맞는다. 실제로는 둘을 배타적으로 볼 필요가 없어서, 앞서 소개한 cmux·Herdr 같은 멀티플렉서로 aider와 Claude Code를 나란히 띄워 쓰는 사람도 많다.
aider의 또 다른 강점은 repo map이다. 채팅에 파일을 다 넣지 않아도, 저장소 구조를 요약한 맵을 모델에 함께 전달해 “이 프로젝트가 어떻게 생겼는지”를 파악하게 한다. 덕분에 큰 프로젝트에서도 편집 대상 파일 한두 개만 넣고 작업할 수 있다. 자세한 소개는 aider 공식 GitHub에 정리돼 있다. Python·JavaScript·Rust·Go 등 100개 이상 언어를 지원하고, 라이선스는 Apache 2.0이다.
여러 AI 코딩 에이전트를 한 터미널에서 병렬로 굴리는 방식이 궁금하다면 cmux 사용법이나 Herdr 가이드를 먼저 참고해도 좋다. aider는 그 무리에 넣기 좋은 단일 에이전트다.
설치와 첫 실행 — 3분이면 끝난다
aider는 파이썬 패키지라 설치가 단순하다. 공식이 권장하는 방법은 별도 설치 관리자를 쓰는 것으로, 파이썬 환경 오염 없이 aider 전용 가상환경을 만들어 준다. 아래 두 줄이면 설치가 끝난다.
# 권장: aider 전용 설치 관리자 (독립 환경으로 격리 설치)
python -m pip install aider-install
aider-installaider-install은 uv 기반으로 aider를 격리된 환경에 넣고 실행 파일만 PATH에 연결한다. 이때 필요한 파이썬은 3.8~3.13이며, 조건에 맞는 파이썬이 없으면 aider-install이 전용 환경에 파이썬 3.12를 알아서 마련해 준다. 시스템 파이썬에 직접 얹고 싶다면 python -m pip install aider-chat 한 줄로도 되는데, 이 경우엔 시스템 파이썬이 3.8~3.13 범위여야 한다. 설치가 끝나면 아무 인자 없이 실행할 수 있는데, aider는 반드시 git 저장소 안에서 돌리는 것을 전제로 한다.
# 작업할 프로젝트로 이동 후 실행
cd my-project
aider디렉터리가 git 저장소가 아니면 aider가 새로 git init을 제안한다. 자동 커밋·되돌리기 같은 기능이 전부 git 위에서 돌아가므로, aider를 쓸 프로젝트는 git으로 관리하는 편이 좋다. 첫 실행 시 모델과 API 키를 물으니, 다음 절에서 그 부분을 짚는다.
Claude·GPT 모델을 aider에 연결하기
aider는 특정 모델에 묶이지 않고 원하는 LLM을 골라 붙이는 구조다. Anthropic Claude, OpenAI, DeepSeek 등을 --model 플래그로 지정하고, API 키는 환경 변수나 인자로 넘긴다. 가장 흔한 두 가지 조합은 아래와 같다.
# Anthropic Claude (Sonnet 별칭)
export ANTHROPIC_API_KEY=sk-ant-...
aider --model sonnet
# OpenAI
export OPENAI_API_KEY=sk-...
aider --model gpt-4o
# 키를 인자로 직접 넘기는 방식 (환경 변수 대신)
aider --model sonnet --api-key anthropic=sk-ant-...sonnet·opus·gpt-4o 같은 값은 aider가 관리하는 모델 별칭이라, aider를 최신으로 유지하면 별칭이 각 벤더의 최신 모델로 매핑된다. 긴 모델 ID를 매번 외울 필요 없이 별칭만 기억하면 되는 셈이다. 세션 도중 모델을 바꾸려면 채팅 안에서 /model 명령을 쓴다.
Claude Pro 구독으로 그냥 못 쓰나 — API 방식만 지원한다
여기서 짚어둘 점이 있다. aider는 API 키 방식만 지원하며, Claude Pro나 ChatGPT Plus 같은 구독 플랜으로는 직접 연결되지 않는다. 구독은 웹·앱의 챗 인터페이스 전용이고, aider처럼 프로그램이 대신 호출하는 도구는 별도의 API 키와 사용량 기반(pay-as-you-go) 과금이 필요하기 때문이다. Anthropic도 “유료 Claude 구독은 챗 경험을 위한 것이며 Claude API·콘솔 사용은 포함하지 않는다”고 명확히 안내한다. 그래서 aider를 쓰려면 각 벤더의 개발자 콘솔에서 API 키를 발급받아 환경 변수로 넣어야 한다.
세 주요 벤더별로 aider에 쓰기 좋은 모델과 발급처를 정리하면 아래와 같다. 점수는 aider 공식 코드 편집 리더보드(다국어 벤치마크) 기준이며, 모델은 자주 갱신되므로 실제 사용 시 리더보드에서 최신 값을 확인하는 편이 좋다.
| 벤더 | 추천 모델(별칭/이름) | API 키 환경변수 | 키 발급처 | 리더보드 점수 |
|---|---|---|---|---|
| OpenAI | GPT-5 / o3 / gpt-4.1 | OPENAI_API_KEY | platform.openai.com | 약 88%(GPT-5) |
| Google Gemini | Gemini 2.5 Pro | GEMINI_API_KEY | aistudio.google.com | 약 83% |
| Anthropic Claude | sonnet / opus | ANTHROPIC_API_KEY | console.anthropic.com | 약 72%(Opus 4) |
비용 없이 맛보고 싶다면 방법이 아주 없지는 않다. 공식 모델 문서에 따르면 OpenRouter가 일부 모델에 일일 한도 안에서 무료 접근을 제공하고, 로컬에서 Ollama로 오픈 모델을 붙일 수도 있다. 다만 코딩 품질은 위 상용 모델과 차이가 있으므로, 실무용으로는 유료 API를 권한다.
> /model opus키가 노출되지 않게 하려면 API 키를 셸 프로파일이나 .env에 두고 환경 변수로 읽는 방식이 안전하다. 어떤 모델이 코딩에 유리한지는 aider 공식 모델 문서에서 벤더별 권장 설정과 리더보드를 확인할 수 있다.
code·ask·architect 모드 — 언제 무엇을 쓰나
aider에는 네 가지 채팅 모드가 있고, 이걸 상황에 맞게 갈아타느냐가 작업 속도를 좌우한다. 기본은 code 모드(바로 파일을 고침)이고, 그 밖에 ask(고치지 않고 논의만), architect(두 모델로 설계와 편집을 분리), help(aider 사용법 질문)가 있다. 한 번만 임시로 바꾸려면 메시지 앞에 /code·/ask·/architect를 붙이고, 계속 유지하려면 /chat-mode를 쓴다.
> /ask 이 결제 모듈에서 동시성 문제가 생길 만한 지점이 어디야?
architect> 재고 차감 로직을 락 없이 안전하게 바꾸고 싶어
> /chat-mode ask실무에서 자주 손이 가는 건 architect 모드다. 이 모드는 요청을 두 모델에 나눠 보낸다. 먼저 architect 모델(주 모델)이 해결 전략을 세우고, 이어 editor 모델(--editor-model로 지정)이 그 전략을 실제 파일 편집으로 옮긴다.
# 설계는 추론에 강한 모델, 편집은 정확한 편집에 강한 모델로 분리
aider --architect --model o1 --editor-model sonnet이 구조가 왜 필요한지는 써 보면 금방 납득이 된다. 추론에 강한 모델은 “무엇을 어떻게 바꿀지” 계획은 잘 세우지만 정확한 diff 편집에는 의외로 약한 경우가 있다. 계획은 추론 모델에, 실제 편집은 편집에 능한 모델에 맡기면 결과가 눈에 띄게 안정된다. 반대로 간단한 수정이라면 굳이 architect를 쓸 필요 없이 code 모드가 빠르다. 모드별 상세 동작은 aider 모드 문서에 정리돼 있다.
가장 실전적인 흐름은 ask로 논의하고 code로 실행하는 왕복이다. /ask로 접근 방식을 합의한 뒤, “그대로 진행해” 한마디로 code 모드에 넘겨 편집을 시킨다. 곧장 code로 시작하기보다 이 한 단계를 거치면 엉뚱한 방향으로 파일을 갈아엎는 사고를 크게 줄일 수 있다.
채팅 중 핵심 명령어 — /add부터 /undo까지
aider의 실제 작업은 슬래시 명령으로 굴러간다. 그중 매일 쓰는 것만 추리면 파일을 편집 대상에 넣는 /add, 참조용으로만 넣는 /read-only, 방금 변경을 되돌리는 /undo, 셸 명령 출력을 대화에 넣는 /run이다. 자주 쓰는 명령을 표로 정리한다.
| 명령 | 하는 일 |
|---|---|
/add <파일> | 파일을 편집 대상으로 채팅에 추가 |
/read-only <파일> | 참조 전용으로 추가(모델이 수정 못 함) |
/drop <파일> | 채팅에서 파일 제거(컨텍스트 절약) |
/ask | 파일 수정 없이 질문만 |
/code | 코드 변경 요청 |
/architect | architect/editor 2모델 모드 |
/run <명령> | 셸 명령 실행 후 출력을 대화에 추가 |
/test <명령> | 명령 실행, 실패(비정상 종료) 시 출력 추가 |
/diff | 마지막 메시지 이후 변경 diff 표시 |
/undo | aider가 만든 마지막 커밋 되돌리기 |
/tokens | 현재 컨텍스트 토큰 사용량 보고 |
/clear | 대화 히스토리 초기화 |
여기서 초보가 가장 많이 하는 실수가 /add로 파일을 너무 많이 넣는 것이다. 공식 문서도 “편집이 필요하다고 생각되는 파일만 넣어라. 관련 없는 코드가 많으면 LLM을 산만하게 하고 혼란시킨다”고 못 박는다. aider는 repo map으로 저장소 구조를 이미 파악하고 있으므로, 실제로 고칠 파일 한두 개만 넣으면 된다. 규칙 문서(코딩 컨벤션 등)는 /read-only로 넣어 두면 매 요청마다 참조하되 수정되지 않는다. 전체 명령 목록은 aider 명령어 문서에서 확인할 수 있다.
작업이 막히면 회복 요령도 정해져 있다. /clear로 대화를 리셋하고, 필요 없는 파일을 /drop하고, /ask로 먼저 상의한 뒤, 그래도 안 풀리면 /model로 모델을 바꿔 본다.
git 안전장치 — 자동 커밋과 한 방 되돌리기
aider가 코드를 마음대로 고쳐도 겁나지 않는 이유는 모든 변경이 git 커밋으로 남기 때문이다. aider는 편집을 마칠 때마다 자동으로 커밋하고, 커밋 메시지는 diff와 대화를 요약해 Conventional Commits 형식으로 생성한다. 결과가 마음에 들지 않으면 /undo 한 번으로 aider의 마지막 커밋을 통째로 되돌린다.
> 로그인 실패 시 429 응답에 Retry-After 헤더를 붙여줘
# aider가 파일 수정 후 자동 커밋: "feat: add Retry-After header on 429"
> /undo # 방금 커밋이 마음에 안 들면 즉시 되돌리기
> /diff # 마지막 메시지 이후 바뀐 내용만 확인이 자동 커밋 동작은 상황에 따라 끄는 게 나을 때도 있다. 예를 들어 하나의 논리적 변경을 여러 요청에 걸쳐 완성하고 마지막에 직접 커밋하고 싶다면, 자동 커밋을 꺼 두는 편이 히스토리가 깔끔하다. 관련 플래그는 아래와 같다.
aider --no-auto-commits # 각 편집마다 자동 커밋하지 않음
aider --no-dirty-commits # 기존 미커밋 변경을 먼저 커밋하지 않음
aider --no-git # git 사용 자체를 끔(대신 백업은 직접 챙겨야 함)한 가지 주의할 점은, aider가 작업 시작 시 기존 미커밋 변경(dirty files)을 먼저 커밋하고 자기 작업을 얹는다는 것이다. 내 작업과 aider 작업을 히스토리에서 갈라 두려는 의도지만, 자칫 미완성 코드까지 딸려 커밋될 수 있다. aider를 켜기 전에 작업 트리를 한 번 정리(커밋 또는 stash)해 두는 습관을 들인 이유가 여기 있다. 커밋 작성자 표기(--attribute-author로 이름에 “(aider)” 부기, --attribute-co-authored-by로 Co-authored-by 추가) 같은 세부 옵션은 aider git 문서에 정리돼 있다.
한 번의 사이클, 실제로는 이렇게 흘러간다
지금까지의 명령을 하나로 꿰면 실제 작업은 아래 흐름이 된다. 로그인 API에 실패 제한(rate limit)을 붙이는 작은 작업을 예로 든다.
$ aider --model sonnet
> /add src/auth/login.py
> /ask 로그인 실패가 반복되면 어떻게 막는 게 좋을까?
# aider가 파일은 건드리지 않고 접근 방식만 제안 (예: 실패 카운트 + 429 응답)
> /code 방금 제안대로 5회 실패 시 429를 반환하도록 구현해줘
# login.py를 수정하고 자동 커밋: "feat: rate limit login after 5 failures"
> /test pytest tests/test_login.py
# 테스트 실패 출력이 대화에 들어오고, aider가 원인을 읽어 수정 후 재커밋
> /diff # 최종 변경 확인
> /undo # 마음에 안 들면 마지막 커밋만 되돌리기이 한 사이클에 aider의 설계 의도가 압축돼 있다. /ask로 먼저 방향을 맞추고, /code로 편집을 시키고, /test로 검증하고, /diff와 /undo로 결과를 통제한다. 곧장 “이거 구현해”라고 던지는 것보다 이 리듬을 지킬 때 엉뚱한 결과로 시간을 날리는 일이 확연히 줄어든다.
말로만 하면 와닿지 않으니 실제로 돌려 봤다. add 함수만 있는 calculator.py를 git 저장소에 두고, aider에게 “두 수를 빼는 subtract 함수를 추가해줘”라고 한 줄 요청한 결과다. 모델은 무료로 발급받을 수 있는 Gemini를 붙였고, 요청 한 번에 aider가 파일을 고치고 곧바로 커밋까지 마쳤다.
출력의 마지막 두 줄이 핵심이다. Applied edit to calculator.py로 실제 파일이 수정됐고, 이어 Commit … feat: add subtract function으로 aider가 변경을 자동 커밋했다. 비용도 이 한 번의 편집에 $0.0011로 찍혔다 — 앞서 말한 pay-as-you-go 과금이 이렇게 토큰 단위로 붙는다. 마음에 안 들면 /undo로 이 커밋을 그대로 되돌리면 된다.
.aider.conf.yml로 설정을 고정하기
매번 같은 플래그를 타이핑하기 번거롭다면 .aider.conf.yml 설정 파일에 못박아 두면 된다. aider는 이 파일을 홈 디렉터리 → git 저장소 루트 → 현재 디렉터리 순으로 읽고, 뒤에서 읽은 값이 앞을 덮어쓴다. 이 순서를 이용하면 개인 공통 설정은 홈에, 프로젝트 전용 설정은 저장소 루트에 두는 식으로 계층을 나눌 수 있다.
공식 문서에 따르면 aider의 대부분의 옵션을 이 파일에 넣을 수 있다. 커맨드라인 플래그 거의 전부에 대응하는 YAML 키가 있어서(--no-auto-commits → auto-commits: false 식), 매번 붙이던 플래그를 전부 설정 파일로 옮길 수 있다. 자주 쓰는 것을 한데 모은 실전 예시는 아래와 같다.
# ~/.aider.conf.yml (홈) 또는 저장소 루트에 둔다
# 모델 3종 (주 모델 / 편집 모델 / 커밋 메시지용 약한 모델)
model: sonnet
editor-model: sonnet
weak-model: gpt-4o-mini
# 편집 방식
edit-format: diff
# git 동작
auto-commits: false # 각 편집마다 자동 커밋하지 않음
dirty-commits: false # 기존 미커밋 변경을 먼저 커밋하지 않음
attribute-author: true # 커밋 author에 "(aider)" 부기
attribute-co-authored-by: true # Co-authored-by 트레일러 추가
# 편집 후 자동으로 린트·테스트 실행
auto-lint: true
auto-test: false
lint-cmd:
- python: ruff check --fix
- javascript: eslint --fix
test-cmd: pytest tests/
# repo map / 캐시 (토큰 절약)
map-tokens: 1024 # repo map 토큰 예산
cache-prompts: true # 프롬프트 캐시로 반복 비용 절감
# 참조 전용 파일(항상 컨텍스트에 두되 수정 금지)
read:
- CONVENTIONS.md
- docs/architecture.md
# 표시
dark-mode: true
stream: true이 설정에서 손이 자주 가는 건 auto-lint와 test-cmd다. auto-lint: true면 편집 직후 지정한 린터를 돌려 문제가 있으면 aider가 스스로 고치려 시도한다. test-cmd를 걸어 두고 /test를 실행하면, 테스트가 실패했을 때 그 출력을 aider가 읽어 원인을 진단한다. read에 코딩 컨벤션 문서를 넣어 두면 매 요청마다 그 규칙을 참조하니, 프로젝트 스타일을 일관되게 유지하는 데 잘 듣는다. 설정 키 전체 목록과 우선순위 규칙은 aider 설정 문서에서 확인할 수 있다.
여기서 weak-model은 커밋 메시지 생성처럼 가벼운 작업에 쓰는 저렴한 모델을 따로 지정하는 옵션이고, cache-prompts: true는 반복되는 프롬프트를 캐싱해 API 비용을 줄인다. edit-format은 모델이 코드를 어떤 형식으로 고칠지(diff/whole 등)를 정한다. 즉 명령줄에서 매번 붙이던 플래그를 전부 이 파일에 못박아, 프로젝트마다 일관된 aider 동작을 고정할 수 있다.
흔한 함정과 실무 팁
aider를 처음 쓸 때 가장 자주 부딪히는 문제는 토큰 비용과 컨텍스트 오염이다. 저장소 맵과 여러 파일을 매 요청에 실어 보내다 보면 토큰이 무섭게 쌓인다. 실전에서 통하는 요령은 몇 가지로 좁혀진다.
가장 먼저 지킬 건 /add를 최소한으로 하는 것이다. 고칠 파일만 넣고, 끝난 파일은 /drop으로 뺀다. /tokens로 사용량을 수시로 들여다보면 비용 감각이 금방 잡힌다. 그다음은 작업을 잘게 쪼개는 습관이다. “결제 모듈 전체를 리팩터링해줘” 같은 한 방 요청은 십중팔구 산으로 간다. 함수 단위로 나눠 요청하고 각 단계에서 /diff로 확인하는 편이 결과가 훨씬 안정적이다. 저장소에 들어가면 안 되는 파일은 .aiderignore로 걸러 repo map에서 빼면 된다(형식은 .gitignore와 같다).
답이 자꾸 엉뚱하게 나올 때는 모델을 탓하기 전에 컨텍스트를 의심하는 편이 맞다. 나도 처음엔 “모델이 왜 이렇게 멍청하지” 싶었는데, 열어 보면 관련 없는 파일을 잔뜩 넣어 둔 내 탓인 경우가 대부분이었다. 이럴 땐 /clear로 대화를 리셋하고 파일을 정리한 뒤 다시 시작한다. 외부 라이브러리 사용법이 필요하면 문서 URL을 붙여 /web으로 스크랩해 넣거나, 로컬 문서를 /read-only로 근거로 제공한다. 이런 요령은 aider 사용 팁 문서에 더 정리돼 있다.
마지막으로, aider는 단독으로도 강력하지만 여러 개를 동시에 굴릴 때 진가가 나온다. 한 저장소의 서로 다른 작업을 여러 aider 세션으로 나눠 병렬 진행하려면 터미널 멀티플렉서가 필요하다. 이때는 Orca vs cmux 비교를 참고해 병렬 실행 도구를 고르면 된다. Claude Code 계열 도구와 함께 쓰는 생태계 전반은 Claude Code Agent Skills 정리에서 이어 볼 수 있다.
FAQ
aider는 Cursor나 GitHub Copilot과 뭐가 다른가요?
aider는 에디터에 붙는 확장이 아니라 터미널에서 독립적으로 도는 CLI다. Cursor는 전용 에디터, Copilot은 에디터 안 자동완성·채팅에 가깝다면, aider는 편집기를 가리지 않고 git 저장소를 직접 다룬다. 특히 변경을 자동 커밋하고 /undo로 되돌리는 git 워크플로가 내장돼 있어, “AI가 고친 걸 안전하게 검토·롤백”하는 데 강하다.
aider는 무료인가요? 비용은 어떻게 드나요?
aider 자체는 Apache 2.0 오픈소스라 무료다. 다만 aider는 자체 모델이 없고 Claude·GPT 같은 외부 LLM의 API를 호출하므로, 그 API 사용료가 든다. 비용은 요청에 실어 보내는 토큰량에 비례하므로, /add를 최소화하고 /tokens로 사용량을 확인하며 큰 작업을 잘게 쪼개면 비용을 눈에 띄게 줄일 수 있다.
aider가 코드를 잘못 고치면 어떻게 되돌리나요?
/undo를 입력하면 aider가 만든 마지막 커밋이 즉시 되돌려진다. 모든 변경이 git 커밋으로 남기 때문에 가능한 일이다. 여러 단계를 되돌리려면 일반 git 명령(git reset 등)을 그대로 쓰면 된다. 작업 전에 트리를 커밋해 깨끗이 해 두면, 문제가 생겨도 aider 커밋만 골라 되돌리기 쉽다.
architect 모드는 언제 써야 하나요?
설계와 편집을 분리하고 싶은 복잡한 변경에 쓴다. architect 모델이 전략을 세우고 editor 모델이 실제 편집을 하므로, 추론에 강한 모델(계획)과 편집에 정확한 모델(적용)을 짝지을 수 있다. 반대로 오타 수정이나 작은 함수 변경 같은 단순 작업은 기본 code 모드가 더 빠르고 저렴하다.
aider로 여러 작업을 동시에 진행할 수 있나요?
가능하다. 한 프로젝트의 서로 다른 작업을 여러 aider 세션으로 나눠 병렬로 돌릴 수 있는데, 이때는 tmux·cmux·Herdr 같은 터미널 멀티플렉서로 세션을 관리하면 편하다. 다만 같은 저장소에서 동시에 편집하면 커밋이 충돌할 수 있으므로, 작업 영역을 파일·브랜치 단위로 나눠 두는 편이 안전하다.
repo map이 다 안다면서 왜 /add로 파일을 직접 넣어야 하나요?
repo map과 /add는 하는 일이 다르다. repo map은 저장소 전체의 뼈대(심볼·함수 시그니처)만 자동으로 담아 구조 파악에 쓰이고, 실제 편집을 하려면 그 파일의 전체 내용이 필요해 /add로 넣는다. 매번 여러 파일을 넣을 필요는 없다 — 보통 고칠 파일 한두 개만 넣으면 되고, 작업하다 더 필요한 파일이 있으면 aider가 먼저 ‘이 파일도 추가할까요?’라고 제안한다. 이 수동 지정은 번거로움이라기보다, AI가 건드릴 범위를 내가 정해 의도치 않은 수정과 토큰 낭비를 막는 안전장치에 가깝다.
마치며
지금까지 터미널 AI 페어프로그래밍 도구 aider를 설치부터 모델 연결, 세 가지 모드, git 안전장치, 설정 파일까지 정리해 보았다. 직접 써 보며 가장 인상적이었던 건 “AI가 고친 코드가 전부 git 커밋으로 남는다”는 설계였다. 에디터 안에서 AI가 파일을 바꿀 때 늘 조마조마했던 마음이, /undo 한 줄로 꽤 편해졌다. 반대로 자동 커밋이 내 미완성 코드까지 물고 가는 바람에 히스토리가 지저분해진 적도 있어서, 지금은 aider를 켜기 전에 작업 트리를 먼저 정리하는 습관이 생겼다. 처음이라면 작은 저장소에서 /ask로 대화부터 시작해 감을 잡고, 익숙해지면 architect 모드와 설정 파일로 자신만의 워크플로를 다듬어 가길 권한다.