터미널 안에서 AI에게 파일을 고치게 하고, 변경 내용을 확인한 뒤 Git 커밋까지 끝내고 싶다면 aider가 가장 가벼운 선택지 중 하나입니다. Cursor처럼 IDE를 바꾸지 않아도 되고, Claude Code처럼 대화형 에이전트 느낌으로 로컬 저장소를 바로 수정할 수 있습니다.
작은 버그 수정용 브랜치를 하나 만들고, 관련 파일 1~2개만 추가해 aider 워크플로를 직접 테스트해보세요.
제가 테스트할 때 가장 편했던 흐름은 단순했습니다. 작은 이슈를 하나 고르고, 관련 파일을 aider에 추가한 다음, 수정 요청 → diff 확인 → 테스트 → 커밋 순서로 진행하는 방식입니다. 특히 이미 Git으로 관리 중인 프로젝트라면 체감 속도가 빠릅니다.
아래 설치 명령어를 따라 한 뒤, 한 파일만 대상으로 수정해보면 실패 부담이 적습니다.
바로 설치하고 실행하는 기본 셋업
aider는 Python 기반 도구입니다. 로컬에 Python이 있다면 pipx로 설치하는 방식이 깔끔합니다. 프로젝트별 의존성과 섞이지 않아서 나중에 지우기도 편합니다.
pipx install aider-chat
cd my-project
aider모델은 OpenAI, Anthropic Claude, Google Gemini 등 여러 API를 연결할 수 있습니다. 예를 들어 Claude를 쓴다면 환경변수로 키를 넣고 실행합니다.
export ANTHROPIC_API_KEY="your_api_key"
aider --model claude-3-5-sonnet-20241022OpenAI를 쓰는 경우도 비슷합니다. 팀에서 이미 ChatGPT API 크레딧을 관리하고 있다면 OpenAI 쪽으로 시작하는 편이 운영상 편할 수 있습니다.
최소 명령어 5개만 기억하기
처음부터 모든 명령어를 외울 필요는 없습니다. 아래 정도만 알아도 실제 작업은 시작할 수 있습니다.
aider: 현재 Git 저장소에서 대화 시작/add app/api/route.ts: AI가 수정할 파일 추가/diff: 변경된 내용을 확인/run npm test: 테스트 명령 실행/commit: 변경 내용을 커밋
직접 써본 작업 흐름: 작은 API 버그 고치기
예를 들어 Next.js 프로젝트에서 결제 상태를 반환하는 API 라우트가 있다고 가정해보겠습니다. 응답 코드가 애매해서 프론트에서 실패 처리를 못 하는 상황입니다.
aider
/add app/api/billing/status/route.ts
/add lib/billing.ts그다음 이렇게 요청합니다.
결제 상태 조회에서 고객 ID가 없으면 400을 반환하고, 외부 API 오류는 502로 분리해줘. 기존 응답 타입은 유지해줘.
aider는 파일을 읽고 수정안을 냅니다. 여기서 바로 믿고 끝내기보다 /diff로 바뀐 부분을 보는 게 중요합니다. 마음에 들면 /run npm test로 테스트를 돌리고, 통과하면 /commit으로 커밋 메시지까지 생성할 수 있습니다.
이 과정이 좋은 이유는 “AI가 코드를 제안했다”에서 멈추지 않고, 실제 저장소 변경과 Git 기록까지 한 흐름으로 이어진다는 점입니다.
aider, Claude Code, Cursor는 어디가 다를까
세 도구는 모두 AI 코딩에 쓰이지만 손에 잡히는 사용감은 꽤 다릅니다. 터미널 중심으로 일하는 개발자라면 aider가 빠르고, IDE에서 파일 탐색과 UI 보조가 필요하면 Cursor가 편합니다.
| 도구 | 잘 맞는 상황 | 아쉬운 점 |
|---|---|---|
| aider | Git 저장소에서 터미널로 수정·diff·커밋까지 처리 | GUI가 없어 초보자는 처음에 건조하게 느낄 수 있음 |
| Claude Code | 에이전트에게 넓은 범위의 작업을 맡기고 싶을 때 | 작업 범위 통제가 느슨하면 원치 않는 수정이 생길 수 있음 |
| Cursor | IDE 안에서 파일을 보며 코드 작성, 리팩터링, 검색을 함께 할 때 | 터미널 중심 워크플로와는 리듬이 다를 수 있음 |
이런 사람에게 추천합니다
aider는 이미 Git, CLI, 테스트 명령에 익숙한 개발자에게 특히 잘 맞습니다. 백엔드 API 수정, 작은 리팩터링, 문서와 코드 동시 수정, 테스트 실패 원인 추적처럼 범위가 명확한 작업에서 효율이 좋습니다.
반대로 코드베이스 구조를 아직 잘 모르는 입문자라면 Cursor로 파일을 눈으로 보면서 시작하는 편이 낫습니다. 디자이너나 기획자와 함께 화면 단위로 수정해야 하는 프로젝트도 IDE형 도구가 편합니다.
흔한 실수: 파일을 너무 많이 열어두는 것
처음 사용할 때 가장 많이 막히는 지점은 컨텍스트를 많이 주면 더 잘할 거라고 생각하는 겁니다. 실제로는 관련 없는 파일까지 잔뜩 추가하면 모델이 핵심을 놓치거나, 불필요한 리팩터링을 제안할 때가 있습니다.
저는 보통 “문제가 있는 파일 1개 + 타입이나 유틸 파일 1개” 정도로 시작합니다. 그래도 부족하면 그때 /add로 파일을 늘립니다. 작은 단위로 대화해야 diff 리뷰도 빨라집니다.
FAQ
Git 저장소가 아니어도 사용할 수 있나요?
쓸 수는 있지만 추천하지 않습니다. 이 도구의 강점은 변경 추적과 커밋 흐름에 있으므로, 먼저 git init을 해두는 편이 안전합니다.
커밋 메시지도 자동으로 만들어주나요?
네. /commit을 실행하면 변경 내용을 바탕으로 메시지를 제안합니다. 다만 팀 컨벤션이 있다면 생성된 메시지를 그대로 쓰지 말고 한 번 다듬는 것이 좋습니다.
비용이 많이 나오지 않나요?
사용 모델과 파일 크기, 대화 길이에 따라 달라집니다. 처음에는 작은 파일로 실습하고, 긴 로그나 빌드 결과를 통째로 붙여넣지 않는 식으로 토큰 사용량을 관리하세요.
Claude Code와 같이 써도 되나요?
가능합니다. 예를 들어 Claude Code로 큰 작업 계획을 세우고, aider로 특정 파일 수정과 커밋을 처리하는 식으로 나눌 수 있습니다. 단, 같은 브랜치에서 동시에 여러 도구가 파일을 바꾸면 충돌이 날 수 있으니 작업 단위를 분리하세요.
오늘 바로 해볼 다음 행동
새로운 사이드 프로젝트 전체를 맡기기보다, 현재 프로젝트에서 “테스트 하나가 실패하는 작은 문제”를 고르세요. 브랜치를 새로 만들고, 관련 파일 두 개만 추가한 뒤, 수정 요청과 /diff 확인까지 해보면 자신에게 맞는지 금방 판단할 수 있습니다.
터미널을 자주 쓰고 커밋 단위로 일하는 개발자라면 aider는 꽤 실용적인 AI 코딩 에이전트입니다. 핵심은 많이 맡기는 것이 아니라, 작은 변경을 빠르게 만들고 사람이 마지막 결정을 하는 흐름입니다.
관련 링크
- ai 코딩 구독 요금 비교: Claude Code·Cursor·Copilot, 빌드용으로 돈값 하는 조합
- claude code artifacts, 웹 미리보기 대신 파일로 남기는 실전 작업법
- claude code 모델 추천: 실제 빌드 작업에서 Sonnet과 Opus를 나눠 쓰는 기준
- 관련 태그 더 보기
- 카테고리 더 보기
- 검색 결과 더 보기
- 참고 링크
