AI 코딩 방법: 리뷰를 통과하는 실전 워크플로

AI 코딩 방법을 익히면 흔히 이런 일이 생겨요. 티켓을 열고 설명을 채팅창에 붙여 넣으면 그럴듯한 코드 200줄이 돌아오고, 컴파일도 돼요. 이틀 뒤 리뷰어가 왜 기존 재시도 래퍼를 무시했냐고 묻는데, 팀 누구도 답하지 못하죠. 생성 단계는 잘 됐지만 그 앞뒤가 무너진 전형적인 실패예요. 아래는 제가 신입 엔지니어에게 알려 주는 워크플로예요. AI를 레포를 한 번도 본 적 없는 빠르고 자신만만한 주니어처럼 다루고, 타이핑 시간이 아니라 리뷰 시간을 기준으로 설계했어요.

AI 코딩 방법을 쓰면 정말 빨라질까요?

상황에 따라 다르고, 솔직한 답은 작업 종류에 달려 있어요. Stack Overflow 2025 개발자 설문에 따르면 응답자의 84%가 AI 도구를 쓰고 있거나 쓸 계획이에요. 그런데 출력 결과를 어느 정도라도 신뢰한다는 응답은 33%뿐이에요. 가장 큰 불만은 66%가 꼽은 '거의 맞는데 뭔가 아쉬운' 코드였어요. 45.2%는 AI가 만든 코드를 디버깅하는 데 예상보다 시간이 더 걸린다고 답했어요.

통제된 실험 데이터는 덜 낙관적이에요. METR의 2025년 연구에서는 익숙한 오픈소스 레포에서 일하는 숙련 개발자 16명이 실제 이슈 246개를 처리했어요. AI 사용을 허용했을 때 이들은 약 19% 더 느리게 끝냈는데, 본인들은 약 20% 빨라졌다고 믿었어요. METR은 이후 더 최신 데이터를 발표했으니, 이 숫자는 2025년 초 도구의 스냅샷으로 보는 게 맞아요.

결론은 'AI는 느리다'가 아니에요. 체감 속도는 믿을 만한 지표가 아니라는 거예요. 첫 초안이 얼마나 빨리 나왔는지 대신, 티켓에서 병합된 PR까지 걸린 시간을 분 단위로 재 보세요.

프롬프트를 쓰기 전에 무엇을 적어야 할까요?

본인의 말로 10줄 이내의 계획을 먼저 적어 보세요. 이 과정을 건너뛰면 모델이 빈틈을 자기 추측으로 채우는데, 그 추측은 정의상 일반적인 답이에요. 제 템플릿은 짧아요.

1. 동작 변화를 한 문장으로 적기

2. 건드릴 것으로 예상되는 파일 적기 (확실하지 않아도 괜찮아요)

3. 새 코드가 재사용해야 할 기존 함수나 패턴 적기

4. 하지 말아야 할 것 하나 적기 (새 의존성 추가 금지, 스키마 변경 금지 등)

5. 동작을 확인할 방법 적기 (테스트, curl, 스크린샷)

많은 사람이 3번을 건너뛰는데, '거의 맞는' 코드의 상당수가 여기서 나와요. 헬퍼 이름을 적거나 모델이 직접 읽을 수 있게 하지 않으면, 모델은 withRetry 헬퍼가 있다는 사실을 몰라요.

'앱 전체를 만들어 줘' 같은 프롬프트는 피하세요. 초보자든 시니어든 같은 결과를 얻어요. 아무도 이해하지 못하는 거대한 diff와 끝나지 않은 프로젝트예요.

실제로 쓸 만한 프롬프트는 어떻게 생겼을까요?

실제 자잘한 작업으로 예를 들어 볼게요. 웹훅 전송기가 수신 측 타임아웃이 나면 이벤트를 떨어뜨려요. '웹훅 안정성 고쳐 줘'처럼 쓰는 약한 프롬프트 대신, 티켓처럼 쓰면 이렇게 돼요.

Add retry with exponential backoff to sendWebhook() in src/webhooks/sender.ts.
Reuse withRetry() from lib/http.ts. Max 4 attempts, jitter on.
Do not change the public signature or add dependencies.
Add a vitest case for a receiver that fails twice, then succeeds.

이 프롬프트는 파일, 재사용할 헬퍼, 제한, 검증 방법을 모두 이름으로 적어요. 결과는 한 번에 읽을 수 있는 30줄 안팎의 diff예요. diff가 150줄로 돌아왔다면 모델이 엉뚱한 데로 샌 거예요. 그럴 땐 고쳐 쓰지 말고 거부하세요.

요령이 두 가지 있어요. 먼저 계획부터 받고, 파일을 바꾸기 전에 읽으세요. 잘못된 계획은 30초를 잃게 하지만, 잘못된 diff는 10분을 잃게 해요. 그리고 답이 빗나가면 논쟁하지 말고 어긴 제약을 다시 짚어 주세요. "새 의존성을 추가했는데 규칙은 의존성 금지예요"라고 한 줄 쓰는 편이 긴 설명보다 잘 먹혀요.

어떤 도구가 어떤 작업에 맞을까요?

도구의 형태는 세 가지이고, 이를 헷갈리는 게 두 번째로 흔한 실수예요.

인라인 자동완성은 타이핑하는 동안 다음 줄을 예측해요. 패턴이 이미 화면에 있는 보일러플레이트와 테스트에 좋아요. 에디터 안 채팅은 선택한 코드에 대한 질문에 답하고, 수정 제안을 hunk 단위로 수락하게 해요. 에이전트는 작업을 받아 파일을 읽고 명령을 실행한 뒤 브랜치를 만들어 와요.

고르는 기준은 검증을 얼마나 싸게 할 수 있느냐예요. 2초면 읽을 수 있는 자동완성은 위험이 낮아요. 파일 14개를 건드리는 에이전트 실행은 보상이 크지만 리뷰 비용도 커요.

Cursor는 에디터 중심으로 쓰는 사람에게 맞는 선택지예요. Tab 자동완성과 병렬 에이전트 세션이 강한 VS Code 포크예요. 하루 종일 에디터에 살고 있다면 가치가 있어요. 팀이 JetBrains를 표준으로 쓰고 바꿀 생각이 없다면 건너뛰세요.

GitHub Copilot은 이미 GitHub을 쓰는 팀에게 마찰이 가장 적은 선택이에요. PR, 이슈, 리뷰가 한곳에 있기 때문이에요. 다만 청구 방식을 확인하세요. 2026년 6월부터 사용량 기반 AI 크레딧으로 바뀌어서, 에이전트를 많이 쓰면 좌석 가격보다 비용이 더 나와요.

Claude Code는 터미널 중심의 에이전트 도구예요. 리팩터링이나 버그 추적을 맡기고 결과를 리뷰하는 방식으로 써요. 인라인 자동완성은 없고 Claude 모델만 쓸 수 있어요. 작업 단위로 위임하고 싶다면 합리적인 선택이에요.

Aider는 스크립트로 제어하고 git을 중심으로 동작하는 선택지예요. 변경할 때마다 메시지와 함께 자동 커밋하므로, 롤백은 git revert면 돼요. 모델 토큰 비용만 내기 때문에 비용을 직접 통제하고 싶은 사람에게 맞아요.

AI가 레포를 무시하는 코드를 어떻게 막을까요?

컨텍스트를 의도적으로 주세요. 나쁜 결과의 대부분은 모델이 관련 파일을 한 번도 보지 못해서 생겨요.

습관이 세 가지 있어요. 첫째, 디렉터리 전체가 아니라 패턴을 정의하는 파일 두세 개만 첨부하세요. 둘째, 실패한 테스트나 에러는 설명하지 말고 그대로 붙여 넣으세요. 셋째, 레포에 짧은 규칙 파일을 두세요. 네이밍, 에러 처리, 금지 라이브러리 같은 내용이면 충분해요. 대부분의 에이전트 도구가 실행할 때마다 이 파일을 읽어요.

# AI-RULES.md
- Errors: return Result, never throw in services/
- HTTP calls go through lib/http.ts (has retry + tracing)
- No new deps without a note in the PR description
- Tests: vitest, colocated as *.test.ts

이런 네 줄만으로도 리뷰 코멘트가 눈에 띄게 줄어요. 사람에게도 도움이 돼요.

아직 잘 모르는 레포라면 편집을 요청하기 전에 질문부터 하세요. "세션 만료는 어디에서 강제되고, 무엇이 그걸 호출하나요?"가 "리프레시 토큰을 추가해 줘"보다 나은 첫 프롬프트예요. 답을 읽고, 답이 인용한 파일 두 개를 열어 본 다음에 무엇을 바꿀지 정하세요. 원래 하던 grep, blame, 동료에게 묻기 루프를 더 빠르게 도는 것뿐이에요.

AI가 만든 코드는 어떻게 리뷰해야 할까요?

동료 코드보다 느리게 리뷰해야 해요. 동료는 여러분의 코드베이스에서 쌓은 실적이 있지만, 모델에게는 그런 실적이 없어요.

제 체크리스트는 이 순서예요.

• 읽기 전에 먼저 실행하세요. 직접 쓴 테스트가 통과하는 것이, 자신만만한 설명보다 나아요.

• import부터 읽으세요. 지어낸 패키지와 낯선 헬퍼는 여기서 제일 먼저 드러나요.

• 빠진 것을 찾으세요. 에러 경로, null 처리, 정리(cleanup) 같은 부분이에요. 모델은 해피 패스를 잘 써요.

• diff 크기를 확인하세요. 10줄짜리 수정을 요청했는데 120줄이 나왔다면, 요청하지 않은 부분까지 다시 쓰였다는 뜻이에요.

• 설명할 수 없는 줄은 지우세요. 리뷰에서 방어할 수 없는 줄은 머지하지 않아요.

커밋은 작게, 메시지는 솔직하게 유지하세요. "웹훅 전송기에 재시도 추가 (AI 보조, 테스트 추가)"라고 쓰면 충분해요. 숨기면 누구에게도 도움이 안 되고, 나중에 디버깅만 어려워져요.

절대 AI에게 맡기면 안 되는 작업은 무엇일까요?

틀렸을 때 조용하고 비싸게 망가지는 작업이에요. 인증 로직, 결제 흐름, 데이터 마이그레이션, 권한 검사가 대표적이에요. '거의 맞는' 코드가 테스트는 통과하고 운영에서 깨지는 곳이죠.

그래도 쓸 수는 있어요. 다만 모드를 바꾸세요. 코드를 쓰게 하지 말고, 여러분의 코드를 검토시켜서 위험 목록을 받으세요. 잠재 이슈 다섯 개의 목록을 읽는 데는 3분이면 되지만, 생성된 마이그레이션을 읽고 그 코드를 의심하느라 보내는 시간은 오후 한나절이 될 수 있어요.

배우는 중이라면 제외 대상이 하나 더 있어요. 먼저 직접 첫 버전을 쓰고, 그다음에 모델에게 비평을 맡기세요. 생성된 버전을 늘 그대로 수락하는 주니어는 프로그래밍이 아니라 프롬프트 쓰는 법을 배우게 되고, 그 차이는 첫 장애에서 드러나요.

팀 단위로 도입하는 방법과 첫 주 계획은 무엇일까요?

개인과 팀의 차이는 리뷰 부담이에요. 에이전트를 쓰는 개발자 한 명이 리뷰어가 읽을 수 있는 양보다 많은 PR을 하루에 열 수 있어요. 도입 초기에 세 가지에 합의하세요.

1. 크기 상한. 변경 줄 수가 수백 줄을 넘는 PR은 누가 만들었든 쪼개세요.

2. 공개 규범. 변경이 AI 보조인지 밝혀서 리뷰어가 주의를 조절할 수 있게 하세요.

3. 공유 규칙 파일. 개인 프롬프트 다섯 개보다 컨벤션의 단일 출처가 나아요.

온보딩에는 질문 중심 읽기가 가장 좋았어요. 신입이 어시스턴트에게 무엇이 어디에 있는지 묻고, 코드에서 직접 검증하는 방식이에요. 검증하지 못하는 코드를 떠안기지 않으면서도 '이건 누구 담당이지?'를 헤매는 첫 주를 줄여 줘요.

첫 주 계획은 이렇게 복사해서 쓰세요.

1. 1일차: 테스트와 보일러플레이트에만 인라인 자동완성을 쓰세요.

2. 2일차: 하루에 질문 세 개를 채팅으로 묻고, 답을 각각 검증하세요.

3. 3일차: 작업당 작은 편집 하나만 채팅이 제안하게 하고, 모든 hunk를 읽으세요.

4. 4일차: 브랜치에서 설정 키 이름 바꾸기처럼 위험이 낮은 작업에 에이전트를 써 보세요.

5. 5일차: 리뷰에서 거슬렸던 점을 모아 규칙 파일을 작성하세요.

한 주 동안 숫자 하나만 추적하세요. 티켓을 시작한 순간부터 병합된 PR까지 걸린 분 단위 시간이에요. 리뷰 수정 시간도 포함하세요. 시간이 줄지 않았다면, 그 도구가 여러분의 일과 맞지 않는 지점을 알게 된 거예요. 그것도 하나의 결과예요.

제가 본 가장 확실한 이득은 생성이 아니라 이해예요. 낯선 모듈을 한 시간이 아니라 10분 만에 파악하는 것이죠. 코드를 쓰는 일은 원래 느린 부분이 아니었어요. 읽고, 결정하고, 검증하는 일이 느렸어요. 도구를 그쪽으로 돌리고, 병합 버튼은 여러분의 판단으로 누르세요. 나머지는 따라옵니다.