Aider로 AI 코딩할 때 덜 헤매고 더 잘 쓰는 현실 꿀팁들

요즘 개발자들 사이에서 바이브 코딩이라는 말, 진짜 자주 들리죠. 저도 처음엔 좀 삐딱하게 봤어요. “AI가 코드를 대신 짜준다고? 그래도 결국 내가 다 봐야 하는 거 아냐?” 이런 마음이었거든요. 그런데 막상 써보니까… 음, 이건 좀 다르더라고요. 특히 Aider를 제대로 쓰기 시작한 뒤로는 코드 수정 속도가 확실히 빨라졌어요.

근데 그렇다고 마냥 장밋빛은 아니에요. 솔직히 말하면, 처음엔 저도 꽤 많이 삽질했습니다. 프롬프트를 대충 던졌더니 엉뚱한 파일을 건드리고, 작은 수정 하나 하자고 토큰을 왕창 써버리고, 가끔은 “야, 너 왜 거기까지 고쳤어…” 싶은 순간도 있었고요. AI 코딩이 편하긴 한데, 이게 운전 보조 장치 같은 느낌이에요. 핸들은 결국 내가 잡고 있어야 합니다.

그래서 오늘은 제가 개발하면서 실제로 써먹고 있는 Aider 코드 수정 꿀팁을 좀 편하게 풀어보려고 해요. 20년 넘게 개발 일을 하다 보니 새로운 도구를 볼 때 살짝 의심부터 하는 편인데요, Aider는 잘만 쓰면 꽤 든든한 동료가 됩니다. 다만 얘한테 일을 잘 시키려면, 말도 잘 걸어야 하고 환경도 좀 맞춰줘야 해요. 사람도 그렇잖아요. 아무 설명 없이 “이거 좀 알아서 해줘” 하면 대부분 망합니다...

Aider 쓰기 전에 환경 설정부터 살짝 잡아두면 훨씬 편해요

Aider를 처음 설치하고 나면 보통 이런 생각이 들어요. “그냥 터미널에서 실행하면 되는 거 아냐?” 네, 되긴 됩니다. 근데 기본 설정 그대로 쓰면 생각보다 불편한 부분이 많아요. 특히 프로젝트가 조금만 커져도 토큰이 훅훅 나가고, AI가 자꾸 필요 이상으로 말을 많이 하거나 명령어를 추천하면서 흐름을 끊을 때가 있거든요.

제가 먼저 챙기는 건 --model 옵션이에요. 이거 은근히 중요합니다. 고성능 모델을 쓰면 답변 품질은 좋지만, 매번 그런 모델을 쓰기엔 비용이 좀 부담스럽죠. 사실 간단한 리팩토링이나 변수명 정리, 작은 버그 수정 정도는 꼭 비싼 모델을 쓸 필요가 없어요.

저는 보통 가벼운 작업에서는 claude-3-haiku 같은 빠르고 저렴한 모델을 먼저 씁니다. 그러다가 로직이 복잡하거나, 여러 파일이 얽혀 있거나, 테스트가 계속 깨지는 골치 아픈 상황이면 그때 gpt-4나 sonnet 계열로 올려요. 이 방식이 꽤 현실적이에요. 뭐랄까, 동네 마트 갈 때마다 대형 트럭 끌고 나갈 필요는 없잖아요.

또 하나 제가 좋아하는 옵션이 --no-suggest-shell-commands예요. Aider가 종종 “이 명령어를 실행해보세요” 같은 식으로 터미널 명령을 제안하거든요. 물론 도움이 될 때도 있어요. 그런데 저는 코드 수정에 집중하고 싶은 상황에서 그런 제안이 자꾸 나오면 흐름이 끊기더라고요. 그래서 코드만 깔끔하게 고치고 싶을 땐 이 옵션을 켜둡니다.

--git 옵션도 거의 필수에 가깝다고 봐요. Aider가 작업하면서 git을 활용하게 해주면, 수정 이력이 남아서 마음이 훨씬 편합니다. AI가 아무리 잘해도 가끔은 사고를 치거든요. 이럴 때 되돌릴 수 있는 안전망이 있느냐 없느냐는 차이가 큽니다. 개발하다 보면 작은 보험 하나가 멘탈을 살려줄 때가 있잖아요.

개인적으로는 ~/.aider.conf.yml 파일을 만들어두는 걸 추천해요. 매번 옵션 입력하는 것도 은근 귀찮습니다. 저 같은 경우에는 자주 쓰는 옵션을 아예 설정 파일에 박아둬요. 예를 들면 이런 것들이죠.

• auto-commits: true 또는 작업 성향에 따라 false
• lint: true
• map-tokens: 1024
• model 기본값 지정

특히 lint: true는 꽤 쏠쏠해요. AI가 수정한 코드가 문법적으로는 맞아 보여도 스타일이 어긋나거나, import 정리가 이상하거나, 사소한 오타가 들어가는 경우가 있거든요. 린트가 한 번 잡아주면 그런 실수를 초반에 걸러낼 수 있습니다.

저도 처음엔 설정 파일까지 만드는 게 좀 과한가 싶었어요. 그런데 한두 달 써보니까 생각이 바뀌더라고요. 자주 쓰는 도구일수록 초기 세팅을 해두는 게 결국 시간을 아껴줍니다. 여행 갈 때도 매번 짐 싸는 리스트가 있으면 훨씬 덜 빠뜨리잖아요. 개발 도구도 비슷합니다.

토큰 아끼는 습관이 곧 AI 코딩 실력입니다

AI 코딩을 하다 보면 슬슬 신경 쓰이는 게 있어요. 바로 토큰 비용입니다. 처음엔 신기해서 막 던지게 되거든요. “이 파일도 보고, 저 파일도 보고, 전체 구조도 파악해줘.” 이렇게요. 그런데 Aider는 컨텍스트에 들어가는 파일이 많아질수록 토큰을 많이 씁니다. 프로젝트가 커지면 이게 진짜 무섭게 늘어나요.

제가 겪어보니 핵심은 단순해요. 필요한 파일만 열기. 이거 하나만 지켜도 토큰 사용량이 확 줄어듭니다. 예를 들어 Aider 실행할 때 이런 식으로 파일을 잔뜩 넣는 경우가 있어요.

aider src/main.py src/utils.py src/models.py src/services/payment.py

물론 전부 필요한 상황이라면 어쩔 수 없죠. 그런데 대부분은 그렇지 않아요. 실제로 수정해야 하는 파일은 하나인데, 혹시 몰라서 주변 파일까지 다 넣는 경우가 많습니다. 그러면 AI는 그 파일들을 전부 읽고 판단해야 하니까 비용도 늘고, 오히려 엉뚱한 판단을 할 가능성도 올라가요.

저는 보통 수정 대상 파일만 먼저 열고, 관련 파일은 프롬프트 안에서 짧게 언급합니다. 예를 들면 이런 식이에요.

src/main.py의 calculate_total 함수만 수정해줘. 이 함수는 src/utils.py의 format_price를 사용하고 있는데, format_price 자체는 수정하지 마.

이렇게 말하면 훨씬 안전합니다. AI에게 필요한 맥락은 주되, 모든 파일을 통째로 던지진 않는 거죠. 솔직히 이 습관 하나만 들어도 Aider 쓰는 느낌이 꽤 달라져요.

프롬프트도 마찬가지입니다. 길게 쓴다고 좋은 게 아니에요. 오히려 짧고 구체적인 프롬프트가 훨씬 잘 먹힙니다. “이 코드 좀 개선해줘” 같은 말은 듣기엔 편하지만, AI 입장에서는 너무 넓어요. 개선이 성능 개선인지, 가독성 개선인지, 예외 처리 추가인지, 구조 변경인지 알 수가 없거든요.

이런 식의 요청은 위험합니다.

이 코드 좀 깔끔하게 정리해줘.

대신 이렇게 말하는 게 좋아요.

calculate_total 함수에서 소수점 둘째 자리까지 반올림되도록 return 부분만 수정해줘. 함수 이름과 파라미터는 바꾸지 마.

별거 아닌 차이 같지만 결과는 완전히 달라집니다. AI는 말을 잘 알아듣는 편이지만, 마음을 읽지는 못해요. 이걸 인정하는 순간부터 프롬프트가 좋아집니다. 예전엔 저도 “이 정도면 알아서 하겠지”라고 생각했는데, 아니더라고요. AI는 알아서 하는 척하다가 진짜 알아서 많이 바꿔버립니다...

--map-tokens 옵션도 챙겨볼 만해요. Aider는 코드베이스 구조를 파악하기 위해 map을 만드는데, 이때 사용하는 토큰 수를 제한할 수 있습니다. 기본값이 너무 크다고 느껴지면 --map-tokens 1024 정도로 낮춰보세요. 작은 프로젝트나 단순 수정 작업에서는 512도 괜찮을 때가 있어요.

• 작은 개인 프로젝트: --map-tokens 512 또는 1024
• 중간 규모 업무 프로젝트: --map-tokens 1024에서 시작
• 여러 모듈이 얽힌 복잡한 수정: 필요할 때만 더 크게 조정

저는 개인 프로젝트에서는 거의 1024로 맞춰놓고 씁니다. 회사 업무에서는 상황을 봐요. 인증, 결제, 권한처럼 연관 범위가 넓은 기능은 map을 조금 더 넓게 잡고, 단순 화면 문구나 작은 함수 수정은 확 줄입니다. 별거 아닌 것 같지만 한 달 단위로 보면 꽤 차이가 납니다.

“이 부분만 바꿔줘”를 제대로 말하는 게 진짜 기술이에요

Aider를 쓰다 보면 제일 중요한 감각이 생깁니다. AI에게 작업 범위를 좁혀주는 감각이에요. 이게 없으면 AI가 너무 열심히 일합니다. 문제는 너무 열심히 해서 문제죠. 나는 한 줄만 바꾸고 싶었는데 함수 전체를 리팩토링하고, 클래스 구조까지 손대고, 갑자기 테스트까지 바꾸는 경우도 있어요.

그래서 저는 가능하면 수정 범위를 아주 명확하게 말합니다. 라인 번호를 알고 있다면 라인 번호까지 말해주는 게 좋아요.

src/main.py의 45번째 줄부터 60번째 줄까지 있는 calculate_total 함수만 봐줘. 52번째 줄 return 문장만 수정하고, 다른 로직은 건드리지 마.

이렇게 말하면 AI가 훨씬 조심스럽게 움직입니다. 특히 “다른 로직은 건드리지 마” 같은 문장을 넣는 게 은근히 효과가 좋아요. AI에게 금지 구역을 알려주는 느낌이랄까요.

변경 전후를 직접 알려주는 것도 좋습니다. 예를 들어 현재 코드가 이렇게 되어 있다고 해볼게요.

return price * 1.1

이걸 바꾸고 싶다면 그냥 “세금 계산을 고쳐줘”라고 하지 말고, 이렇게 말하는 게 훨씬 낫습니다.

현재 return price * 1.1로 되어 있는 부분을 return round(price * 1.1, 2)로 바꿔줘. 세금 계산 방식 자체는 변경하지 마.

이런 식으로 요청하면 AI가 의도를 훨씬 정확히 이해합니다. 반대로 “세금 계산을 개선해줘”라고 하면 AI는 정말 개선을 해버릴 수 있어요. 세율 상수를 만들고, 예외 처리를 넣고, 새로운 helper 함수를 만들고… 물론 어떤 상황에선 고맙죠. 그런데 운영 중인 서비스 코드에서는 이런 과한 친절이 사고가 되기도 합니다.

제가 실제로 한번 겪었던 일인데요. 예전에 간단한 날짜 포맷 수정만 부탁했는데, AI가 날짜 처리 유틸 전체를 “더 깔끔하게” 바꿔버린 적이 있어요. 겉으로는 멀쩡했는데 특정 타임존에서 테스트가 깨지더라고요. 그 뒤로는 프롬프트에 거의 습관처럼 씁니다. “요청한 부분 외에는 수정하지 마.” 이 문장, 꽤 든든합니다.

그리고 가능하면 요청을 한 번에 너무 많이 넣지 않는 게 좋아요. “이 함수 수정하고, 테스트 추가하고, 타입 정리하고, 성능도 개선하고, 중복도 제거해줘” 이렇게 한 번에 던지면 결과가 애매해질 때가 많습니다. 사람에게 일을 시켜도 그렇잖아요. 한 번에 다 말하면 중요한 게 흐려집니다.

저는 보통 이런 흐름으로 나눠서 시킵니다.

• 문제가 되는 함수나 파일을 먼저 설명한다.
• 수정 범위를 제한한다.
• 변경 의도를 한 문장으로 말한다.
• 건드리면 안 되는 부분을 분명히 말한다.
• 수정 후 테스트나 lint 기준을 확인한다.

말로 쓰면 길어 보이지만, 실제 프롬프트는 짧아도 됩니다. 중요한 건 친절함이 아니라 정확함이에요. 물론 너무 딱딱하게 쓸 필요는 없고요. 그냥 같이 일하는 동료에게 말하듯이, “여기만 이렇게 바꿔줘. 나머지는 그대로 둬” 정도면 충분합니다.

Aider 실전 워크플로우는 git과 함께 굴리는 게 마음 편합니다

Aider는 코드 수정 도구지만, 저는 거의 항상 git workflow랑 같이 씁니다. 이건 습관이기도 하고, 안전장치이기도 해요. AI가 코드를 잘 고쳐주는 순간도 많지만, 가끔은 너무 당당하게 틀립니다. 그럴 때 되돌릴 수 있어야 마음 편하게 실험할 수 있어요.

작업을 시작하기 전에는 별도 브랜치를 만드는 편입니다. 예를 들면 이런 식이죠.

git checkout -b feature/aider-refactor

이렇게 해두면 AI가 수정한 내용이 메인 브랜치에 바로 섞이지 않아서 좋습니다. 나중에 diff를 보면서 천천히 리뷰할 수도 있고요. 마음에 안 들면 브랜치째 버리면 됩니다. 개발하다 보면 버리는 용기도 필요합니다. 아까워서 붙잡고 있다가 더 꼬이는 경우, 우리 다 알잖아요.

Aider의 auto-commit 기능은 편합니다. 정말 편해요. 그런데 저는 상황에 따라 꺼두기도 합니다. 왜냐하면 AI가 너무 작은 단위로 커밋을 만들 때도 있고, 반대로 여러 변경을 한꺼번에 묶어버릴 때도 있거든요. 커밋 이력은 나중에 문제를 추적할 때 꽤 중요해서, 저는 의미 있는 단위로 남기는 걸 좋아합니다.

그래서 업무 코드에서는 --no-auto-commits를 켜고 직접 /commit을 치는 경우가 많아요. 커밋 메시지도 대충 “fix bug”라고 쓰기보다는 조금 구체적으로 남깁니다.

• calculate_total 함수의 소수점 반올림 처리 수정
• payment validation에서 null amount 예외 처리 추가
• user profile update 로직의 불필요한 중복 제거

이렇게 남겨두면 나중에 훨씬 편합니다. 특히 팀 프로젝트에서는 더 그래요. AI가 만든 코드라고 해도 결국 리뷰하고 운영하는 건 사람이니까요.

/undo 명령어도 자주 씁니다. Aider가 마음에 안 드는 방향으로 수정했을 때 바로 되돌릴 수 있어서 좋아요. 다만 너무 막 누르진 않는 게 좋습니다. 연속으로 /undo를 치다 보면 생각보다 많은 변경사항이 사라질 수 있거든요. 저는 보통 undo 전에 git diff나 git log를 한번 봅니다. 귀찮아 보여도 이게 사고를 줄여줘요.

제 워크플로우는 대충 이런 느낌입니다.

• 작업용 브랜치를 만든다.
• 수정할 파일만 Aider에 넘긴다.
• 작은 단위로 프롬프트를 던진다.
• AI가 수정한 뒤 바로 diff를 확인한다.
• 테스트와 lint를 돌린다.
• 괜찮으면 의미 있는 단위로 commit한다.

여기서 핵심은 AI가 수정한 코드를 바로 믿지 않는 것입니다. 이건 불신이라기보다는 습관이에요. 좋은 개발자는 자기 코드도 의심하잖아요. 하물며 AI가 만든 코드는 더더욱 확인해야죠.

프롬프트는 길게 쓰는 게 아니라, 덜 오해하게 쓰는 겁니다

Aider를 쓰면서 많이 느끼는 건데, 프롬프트를 잘 쓴다는 게 꼭 장황하게 쓴다는 뜻은 아니에요. 오히려 군더더기 없는 말이 좋습니다. 다만 핵심 조건은 빠지면 안 돼요. 특히 다음 네 가지는 자주 넣는 편입니다.

• 어느 파일을 수정할지
• 어느 함수나 클래스가 대상인지
• 무엇을 바꿔야 하는지
• 무엇은 절대 바꾸면 안 되는지

예를 들면 이런 프롬프트가 꽤 좋습니다.

src/payment.py의 validate_payment 함수만 수정해줘. amount가 None이면 ValueError를 발생시키도록 처리하고, 기존의 음수 체크 로직은 그대로 둬. 함수 시그니처와 다른 함수는 수정하지 마.

이 정도면 충분히 구체적입니다. AI가 불필요하게 파일 전체를 뜯어고칠 가능성도 줄어들고요. 사실 사람에게 코드 리뷰 요청할 때도 이렇게 말하면 훨씬 편하잖아요. “여기 null 처리만 봐줘”라고 말하는 것과 “전체적으로 봐줘”는 완전히 다른 요청입니다.

반대로 이런 프롬프트는 좀 위험해요.

payment 로직 좀 안정적으로 바꿔줘.

이건 너무 넓습니다. 안정적이라는 말은 멋있지만, 구현 지시로는 애매해요. AI가 예외 처리를 추가할 수도 있고, 구조를 바꿀 수도 있고, 심지어 기존 동작을 바꿔버릴 수도 있습니다. 운영 서비스에서는 이런 애매함이 비용이 됩니다. 괜히 무서운 말 하는 게 아니라, 진짜로요.

저는 요즘 Aider에게 일을 줄 때 약간 이런 식으로 생각합니다. “똑똑한 주니어 개발자에게 작업을 부탁한다면 어떻게 설명할까?” 너무 무시하듯이 말할 필요도 없고, 너무 믿고 맡길 필요도 없어요. 맥락을 주고, 범위를 정하고, 결과를 확인하면 됩니다. 이 균형이 꽤 중요해요.

테스트와 리뷰는 AI 코딩에서도 절대 건너뛰면 안 됩니다

Aider가 코드를 고쳐주면 그 순간 기분이 좋습니다. 특히 복잡해 보이던 코드를 순식간에 정리해주면 “오, 이거 진짜 물건인데?” 싶죠. 그런데 거기서 바로 끝내면 위험합니다. AI가 만든 코드는 반드시 테스트해야 합니다.

제가 특히 많이 보는 부분은 경계값 조건이에요. AI는 일반적인 케이스는 잘 맞추는 편인데, 애매한 입력값이나 예외 상황에서 실수하는 경우가 종종 있습니다.

• 값이 None일 때
• 빈 문자열이 들어올 때
• 0이나 음수 같은 경계값이 들어올 때
• 리스트가 비어 있을 때
• timezone이나 locale이 얽혀 있을 때

이런 건 사람이 한 번 더 봐야 합니다. AI가 “테스트도 통과할 겁니다”라고 말해도 믿지 마세요. 실제로 돌려봐야 합니다. 저는 Aider 작업 후에는 거의 습관처럼 테스트 명령을 실행합니다. 작은 프로젝트면 전체 테스트를 돌리고, 큰 프로젝트면 관련 테스트라도 꼭 돌려요.

그리고 diff 리뷰도 중요합니다. AI가 내가 요청한 부분만 바꿨는지, 이상한 import가 추가되진 않았는지, 함수 시그니처를 건드리진 않았는지 확인해야 해요. 코드는 동작만 맞으면 끝이 아니라, 나중에 누가 봐도 이해할 수 있어야 하니까요.

솔직히 이 부분이 조금 귀찮습니다. AI가 다 해줬으면 좋겠는데, 또 내가 봐야 하니까요. 근데 생각해보면 예전보다 훨씬 나아진 거예요. 예전엔 직접 다 고치고 직접 다 확인했는데, 이제는 AI가 초안을 빠르게 만들어주고 저는 방향과 품질을 보는 쪽으로 바뀐 거니까요. 역할이 조금 달라진 느낌입니다.

Aider는 만능 해결사가 아니라, 손발 잘 맞는 개발 보조 도구예요

Aider를 몇 달 써보면서 제 생각은 좀 명확해졌어요. 이 도구는 정말 강력합니다. 특히 반복적인 수정, 작은 버그 수정, 리팩토링 초안 만들기, 테스트 코드 보강 같은 작업에서는 생산성을 확 올려줘요. 잘 맞을 때는 체감상 2배, 어떤 날은 3배까지도 빠르게 느껴집니다.

하지만 Aider는 만능 해결사가 아닙니다. 여기서 착각하면 오히려 일이 늘어요. AI가 만든 코드를 검토하지 않고 그대로 넣었다가 운영에서 문제 나면, 그 책임은 결국 개발자에게 옵니다. 냉정하지만 이건 변하지 않아요.

제가 생각하는 좋은 사용법은 이렇습니다. AI에게는 속도를 맡기고, 개발자는 방향과 판단을 맡는 거예요. Aider가 초안을 만들고, 반복 작업을 줄이고, 귀찮은 수정 포인트를 빠르게 처리하게 합니다. 대신 설계 판단, 도메인 이해, 예외 상황, 품질 기준은 사람이 잡아줘야 합니다.

조금 감성적으로 말하면, Aider는 옆자리에서 같이 일하는 빠른 동료 같아요. 손은 빠른데 우리 서비스 사정은 아직 잘 모릅니다. 그러니까 제가 알려줘야 해요. “여긴 건드리면 안 돼”, “이 로직은 오래된 고객사 때문에 유지해야 해”, “이 테스트는 꼭 통과해야 해.” 이런 맥락은 아직 사람이 훨씬 잘 압니다.

그래서 Aider를 잘 쓰려면 프롬프트 스킬도 필요하고, 토큰을 아끼는 감각도 필요하고, git으로 안전망을 만드는 습관도 필요합니다. 그런데 너무 어렵게 생각하진 않아도 돼요. 몇 번만 삽질해보면 금방 감이 옵니다. 저도 그랬고요.

혹시 지금 Aider를 막 쓰기 시작했다면, 처음부터 큰 작업을 맡기진 말아보세요. 작은 함수 수정, 테스트 코드 추가, 단순 리팩토링부터 시작하는 게 좋습니다. 그리고 AI가 수정한 내용을 꼭 diff로 확인해보세요. 이 과정을 반복하다 보면 “아, 얘한테는 이렇게 말해야 잘 알아듣는구나” 하는 감이 생깁니다.

개발 도구는 결국 내 손에 익어야 진짜 도구가 됩니다. Aider도 마찬가지예요. 처음엔 좀 어색하고, 가끔은 엉뚱하고, 토큰도 생각보다 많이 쓰지만… 잘 길들이면 꽤 든든합니다. 저도 아직 완전히 정답을 찾은 건 아니지만, 이 정도만 지켜도 훨씬 덜 헤매고 더 편하게 쓸 수 있더라고요.

AI 코딩은 이제 잠깐 지나가는 유행이라기보다는, 개발자의 작업 방식 자체를 바꾸는 흐름에 가까운 것 같아요. 다만 중요한 건 휘둘리지 않는 거죠. 도구를 쓰되, 판단은 내가 한다. 저는 이 원칙 하나만큼은 계속 가져가려고 합니다. 그래야 편해지면서도 코드 품질은 지킬 수 있으니까요.

🔍 관련 정보 더 보기