Aider 리뷰 2026: 실제로 커밋을 수행하는 터미널 AI 코딩 에이전트 (테스트 완료)

이 기사는 원래 aifoss.dev에 게시되었습니다.

Aider는 VS Code 확장 프로그램을 설치하거나, 브라우저 도구에 로그인하거나, GUI를 위해 터미널을 포기할 필요가 없는 AI 코딩 어시스턴트(AI coding assistant)를 원할 때 찾는 도구입니다. Aider는 셸(shell)에서 실행되며, 실제 파일을 편집하고, 각 변경 사항을 스스로 생성한 설명 메시지와 함께 Git에 자동으로 커밋합니다. 이러한 워크플로(workflow)는 당신이 정확히 원하는 것이거나, 혹은 결코 받아들일 수 없는 요소일 것이며, 이 두 진영 사이의 경계는 대부분의 도구 비교보다 훨씬 더 명확합니다.

테스트 버전: v0.86.2 (2026년 2월 기준 마지막 안정 버전 — 최신 버전은 PyPI를 확인하세요). 라이선스: Apache 2.0. GitHub 별(star) 4만 개 이상, 설치 410만 회.

Aider가 실제로 하는 일

저장소(repo) 내의 하나 이상의 파일을 Aider로 지정함으로써 세션을 시작합니다:

aider src/main.py src/utils.py

그다음부터는 원하는 내용을 평이한 영어로 설명하면 됩니다: "auth 함수를 예외를 던지는 대신 Result 타입을 반환하도록 리팩터링(refactor)해줘", "목록 엔드포인트에 페이지네이션(pagination)을 추가해줘", "test_parser.py의 실패하는 테스트를 수정해줘". Aider는 파일을 직접 편집하고 각 변경 사항을 설명 메시지와 함께 Git에 커밋합니다.

그러한 Git-first 철학은 이 도구의 가장 강력한 차별점입니다. 대부분의 AI 코딩 도구는 Git을 AI 작업이 끝난 후에 수행하는 부수적인 작업으로 취급합니다. 반면 Aider는 Git을 상태 머신(state machine)으로 취급합니다. 모든 변경 사항은 추적되고, 모든 롤백(rollback)은 깔끔하며, AI가 정확히 무엇을 건드렸는지 항상 알 수 있습니다. 무언가 망가진다면, git revert HEAD를 통해 몇 초 만에 이전 상태로 되돌릴 수 있습니다.

이 워크플로는 숙련된 엔지니어들이 이미 일하는 방식과 일치합니다: 점진적으로 편집하고, 자주 커밋하며, 차이점(diff)을 검토합니다. Aider는 이 루프를 대체하는 것이 아니라 그 루프 안에 자연스럽게 끼어듭니다.

설치

Aider는 Python 3.10–3.12를 요구합니다. Python 3.13은 uv를 통해 작동하지만 공식적으로 지원되지는 않습니다 — uv는 필요한 경우 자동으로 별도의 Python 3.12를 가져옵니다.

# 권장 사항: uv를 통한 격리된 설치
pip install uv
uv tool install aider-chat
...

프로젝트 디렉토리에서 처음 실행할 때, Aider는 세션 파일을 위한 .aider 디렉토리를 생성하고 .gitignore에 .aider*를 자동으로 추가합니다. 따라서 Aider의 자체 관리 작업이 저장소(repo) 기록을 어지럽히지 않습니다.

시작하기 전에 모델 API 키를 설정하세요:

# Claude (Aider의 Polyglot 벤치마크에서 가장 좋은 결과)
export ANTHROPIC_API_KEY=sk-ant-...
aider --model claude-sonnet-4-20250514
...

매번 동일한 설정을 사용하는 프로젝트의 경우, 프로젝트 루트에 .aider.conf.yml 파일을 만들어 설정을 저장하세요:

model: claude-sonnet-4-20250514
architect: true
editor-model: claiku-haiku-4-5-20251001

Architect mode (아키텍트 모드)

Architect mode는 Aider가 출시한 기능 중 가장 중요한 기능입니다. 이 기능이 해결하는 문제는 실질적입니다. 코드에 대해 매우 뛰어난 추론을 수행하는 프런티어 모델(frontier models)조차 종종 잘못된 형식의 디프(diff) 출력을 생성하곤 합니다. 6개의 파일을 깔끔하게 리팩터링(refactor)할 계획을 세울 수 있는 모델이라도, 때로는 적용할 수 없는 깨진 패치(patch) 구문을 생성할 수 있습니다.

해결책은 작업을 두 개의 모델로 나누는 것입니다. 첫 번째 모델("architect")은 무엇을 왜 변경해야 하는지 계획을 세웁니다. 두 번째 모델("editor")은 그 계획을 받아 실제 파일 수정 사항을 생성합니다. 이를 통해 비용이 많이 드는 모델로부터 정교한 추론을 얻고, 더 저렴하고 정밀한 모델로부터 깔끔하고 신뢰할 수 있는 출력을 얻을 수 있습니다.

# 비용 효율적인 아키텍트 모드 분할
aider --architect \
  --model claude-opus-4-20250514 \
...

단순한 단일 파일 변경의 경우, 오버헤드(overhead)가 더 클 수 있으므로 빠른 모델을 직접 실행하세요. 반면 여러 파일에 걸친 리팩터링, 구조적 변경, 또는 복잡한 로직 재작성의 경우, 아키텍트 모드는 편집 실패를 눈에 띄게 줄여줍니다.

비용 계산을 해보면 종종 사용자에게 유리하게 작용합니다. Opus는 토큰당 비용이 비싸지만, 아키텍트 역할에는 많은 토큰이 필요하지 않습니다. Haiku가 대량의 편집 생성 작업을 처리합니다. 결과적으로 전체 세션 비용은 모든 작업에 Opus를 사용하는 것보다 더 낮으면서도 품질은 더 높게 나오는 경우가 많습니다.

모델 지원 및 Polyglot 벤치마크

Aider는 자체적인 Polyglot 코딩 벤치마크 (Polyglot coding benchmark)를 공개합니다. 이는 단순한 지식 테스트가 아닌 실제 환경의 성능을 반영하도록 설계된 다국어 코드 편집 작업입니다. 이 리더보드는 새로운 모델이 출시될 때마다 업데이트되므로, 코딩 작업을 위한 모델을 선택할 때 가장 정직한 리소스 중 하나로 꼽힙니다.

2026년 중반 기준으로, Claude Opus 4.x가 Aider Polyglot 벤치마크를 선도하고 있습니다. GPT-4o와 Gemini 2.5 Pro 모두 강력한 성능을 보여줍니다. DeepSeek는 더 낮은 API 비용으로 경쟁력 있는 품질을 제공합니다. 로컬 모델의 경우, qwen2.5-coder:32b가 가장 강력한 오픈 웨이트 (open-weight) 옵션입니다.

제공업체 (Provider)	권장 모델	비고
Anthropic	claude-sonnet-4-20250514	일상적인 사용을 위한 최적의 품질/비용 균형
...

Ollama 컨텍스트 윈도우 (context window) 문제

Aider + Ollama 조합은 작동하지만, 대부분의 설정 가이드가 생략하는 치명적인 설정이 하나 있습니다. Ollama의 기본 컨텍스트 윈도우 (context window)는 2,048 토큰입니다. 사소하지 않은 규모의 코드베이스(codebase)라면, 이는 Aider가 파일 내용의 대부분을 조용히 버리고 있다는 것을 의미하며, Ollama는 이에 대해 경고를 주지 않습니다. 실제 문제는 컨텍스트 절단 (context truncation)임에도 불구하고, 결과는 마치 모델 품질 문제처럼 보일 것입니다.

첫 세션을 시작하기 전에 이를 수정하세요:

# Ollama를 시작하기 전에 컨텍스트를 32k로 설정
OLLAMA_NUM_CTX=32768 ollama serve

또는 Modelfile에 영구적으로 추가하세요:

FROM qwen2.5-coder:32b
PARAMETER num_ctx 32768

Ollama 리뷰 (Our Ollama review)에서는 컨텍스트 윈도우 (context window) 설정이 VRAM 사용량과 어떻게 상호작용하는지를 포함하여 Ollama의 구성을 더 심도 있게 다룹니다.

편집 형식 (Edit formats)

Aider는 파일에 변경 사항을 기록하는 여러 형식을 지원합니다. 모델 선택에 따라 어떤 형식이 안정적으로 작동하는지가 달라지기 때문에 이 점은 중요합니다.

whole: 파일 전체를 다시 작성합니다. 가장 신뢰할 수 있지만, 토큰 비용이 가장 높습니다.
udiff: 통합 디프 (Unified diff) 형식입니다. 효율적이지만 성능이 낮은 모델에 의해 가끔 잘못 적용될 수 있습니다.
editor-diff / editor-whole: 아키텍트 모드 (architect mode)에서 사용됩니다. 에디터 모델이 아키텍트의 계획을 전달받아 타겟팅된 변경 사항을 생성합니다.

Aider는 사용 중인 모델에 따라 형식을 선택합니다. Claude 또는 GPT-4o 세션의 경우 기본 설정으로도 충분합니다. 만약 로컬 모델을 사용할 때 편집 적용 실패(edit application failures)가 빈번하게 발생한다면, --edit-format whole 옵션을 사용하는 것이 보통 해결책이 되지만 토큰 사용량이 늘어나는 비용이 발생합니다.

세션 워크플로우 및 명령어

Aider 세션에 진입하면, 다음 명령어들이 일상적인 사용의 대부분을 커버합니다:

/add src/api/routes.py        # 파일을 세션 컨텍스트(context)에 추가
/drop src/api/routes.py       # 컨텍스트에서 파일 제거
/run pytest tests/            # 명령어를 실행하고 그 출력을 컨텍스트에 포함
...

/run 명령어는 대부분의 사용자가 과소평가하는 명령어입니다. 테스트 스위트(test suite)를 실행하고, Aider가 실패한 출력 내용을 확인하게 한 뒤, 실패한 테스트를 수정하도록 요청하는 패턴은 매우 신뢰할 수 있고 빠릅니다. Aider는 정확한 에러를 읽고, 어떤 파일이 범위(scope) 내에 있는지 파악하여 타겟팅된 수정(targeted fixes)을 수행합니다. 스택 트레이스(stack traces)를 복사해서 붙여넣을 필요가 없습니다.

/ask 명령어는 변경 사항 없이 분석만 필요할 때 유용합니다. 특정 함수가 무엇을 하는지 묻거나, 리팩토링(refactoring) 계획을 요청하거나, 어떤 테스트가 포함되어야 하는지 물어본 다음, 진행 여부를 결정할 수 있습니다.

Aider vs. 대안들

끊임없이 언급되는 두 가지 비교 대상은 Aider vs. Cline, 그리고 Aider vs. Continue.dev입니다.

| 기능 | Aider | Cline | Cont