AI 페어 프로그래밍은 AI 를 옆자리 동료처럼 두고 코드를 함께 쓰는 방식입니다. 사람 둘이 하는 페어 프로그래밍에서 한 명이 운전(코드 작성)하고 한 명이 항해(방향·검토)하듯, AI 와 할 때도 누가 운전하고 누가 항해하는지를 정해야 잘 굴러갑니다. 이 글은 그 역할을 어떻게 나누는지, 맥락을 어떻게 주는지, 결과를 어떻게 검토하는지를 실제로 겪은 기준으로 적은 것입니다.
"AI 와 대화하며 코딩한다" 는 뜻의 바이브 코딩과 겹치는 부분이 많습니다. 차이가 있다면 바이브 코딩은 결과물 중심이고, 페어 프로그래밍은 과정에서 사람의 판단을 어디에 둘지에 더 무게가 있다는 점입니다.
먼저 세 단계로 나눕니다#
| 단계 | AI 가 하는 일 | 사람이 하는 일 | 도구 예 |
|---|---|---|---|
| 자동 완성 | 다음 줄·블록 제안 | 받을지 말지 즉시 판단 | Copilot, Gemini Code Assist |
| 대화 | 설명·에러 원인·짧은 수정 | 질문을 정확히 하고 답을 검증 | Copilot Chat, Continue |
| 에이전트 | 파일 여러 개를 읽고 고치고 실행 | 요구사항 정의, 범위 제한, 결과 검토 | Claude Code, Cline, Cursor 에이전트 |
단계가 올라갈수록 AI 가 운전하는 시간이 길어지고, 사람은 항해 쪽으로 옮겨 갑니다. 문제는 대부분 단계에 맞지 않는 역할을 사람이 붙잡고 있을 때 생깁니다. 자동 완성 단계에서 제안을 하나하나 설명해 달라고 하거나, 에이전트 단계에서 한 줄씩 승인하려 들면 둘 다 느려집니다.
1단계: 자동 완성에서 사람의 역할#
제안을 읽고 받습니다. Tab 을 반사적으로 누르는 습관이 가장 위험합니다. 제가 정한 기준은 두 가지입니다.
- 세 줄 이하는 읽고 받습니다. 변수명과 조건문 방향만 확인하면 됩니다.
- 세 줄을 넘는 제안은 일단 거절하고 직접 씁니다. 긴 제안은 내 의도와 어긋나는 경우가 많고, 받은 뒤 고치는 것이 처음부터 쓰는 것보다 오래 걸렸습니다.
실제로 겪은 일. 날짜 비교 함수에서 제안된 코드를 그대로 받았다가 시간대 처리가 빠진 채로 배포한 적이 있습니다. 테스트가 로컬 시간대에서만 통과했기 때문입니다. 그 뒤로 날짜·돈·권한이 들어간 제안은 길이와 상관없이 직접 씁니다.
2단계: 대화에서 맥락을 주는 순서#
대화형은 질문의 질이 답의 질입니다. 맥락을 주는 순서를 정해 두면 같은 질문도 결과가 달라졌습니다.
- 무엇을 하려는지 한 문장. "주문 목록 API 에 페이지네이션을 붙이려고 한다."
- 지금 상태. 관련 파일을 열어 두거나 코드를 선택한 뒤 묻습니다. 대부분의 확장이 열린 파일과 선택 영역을 맥락으로 넣습니다.
- 제약. "기존 응답 형식은 바꾸지 말 것", "라이브러리 추가 없이".
- 원하는 출력. "수정된 함수만", "설명 없이 코드만".
실제로 겪은 일. 제약을 빼먹으면 AI 는 가장 깔끔한 답을 줍니다. 깔끔한 답이 기존 응답 형식을 바꿔 버려 프런트엔드가 깨진 적이 있습니다. "바꾸지 말 것" 을 적는 습관은 그 뒤에 생겼습니다.
에러를 물을 때는 에러 메시지 전체와 스택의 첫 다섯 줄을 그대로 붙입니다. 요약해서 물으면 AI 도 요약된 답을 줍니다.
3단계: 에이전트에서 요청을 쪼개는 크기#
에이전트에게는 "결제 모듈을 새 API 로 옮겨 줘" 처럼 큰 요청을 할 수 있습니다. 되기는 됩니다. 그런데 검토할 수 없는 크기의 변경이 돌아오면 받을 수도 버릴 수도 없게 됩니다. 제가 정한 크기는 이렇습니다.
- 한 번에 하나의 결과. "마이그레이션 파일 만들기", "그에 맞춰 모델 수정", "테스트 추가" 를 세 번에 나눠 맡깁니다.
- diff 가 한 화면에 들어오는 크기. 넘으면 쪼갭니다.
- 먼저 계획을 받고, 그다음 실행. "어떻게 할지 먼저 적어 줘" 라고 하면 파일 목록과 순서가 나옵니다. 그 계획에서 빠진 것을 사람이 채운 뒤 실행시킵니다.
실제로 겪은 일. 대량 리네임을 한 번에 맡겼더니 요청 밖의 파일까지 "일관성을 위해" 고쳐 놓았습니다. 틀린 건 아니었지만 리뷰 범위가 두 배가 됐습니다. 그 뒤로는 "이 폴더 밖은 건드리지 말 것" 을 요청에 넣습니다. 도구별로 어느 단계에 강한지는 AI 코딩 도구 비교 2026에 정리했습니다.
생성된 코드를 검토하는 기준#
페어 프로그래밍에서 항해자의 핵심 역할은 검토입니다. AI 가 쓴 코드는 사람이 쓴 코드와 틀리는 방식이 다릅니다. 문법은 거의 틀리지 않고, 대신 아래에서 틀립니다.
| 자주 틀리는 곳 | 확인 방법 |
|---|---|
| 경계 조건(빈 배열, 0, null) | 그 입력으로 직접 호출해 본다 |
| 시간대·통화·권한 | 코드가 아니라 요구사항과 대조한다 |
| 존재하지 않는 API·옵션 | 공식 문서에서 이름을 검색한다 |
| 테스트가 구현을 베낀 경우 | 테스트가 "무엇을" 검증하는지 읽는다 |
| 에러 처리 생략 | 실패 경로를 일부러 만들어 본다 |
"테스트가 통과했다" 는 검토가 아닙니다. AI 가 테스트도 같이 썼다면 테스트가 구현을 그대로 베꼈을 수 있습니다. 테스트 코드를 먼저 읽고, 그 테스트가 내가 원하는 동작을 검증하는지 본 뒤에 결과를 봅니다.
혼자 개발할 때와 팀에서 쓸 때#
혼자일 때 가장 큰 효과는 "막혔을 때 물어볼 사람이 생긴다" 는 것입니다. 대신 검토자도 나 혼자라 위 표를 더 엄격하게 봐야 합니다. 저는 AI 가 만든 변경을 커밋하기 전에 diff 를 소리 내어 읽듯 한 줄씩 봅니다. 느리지만 이 습관이 배포 사고를 막았습니다.
팀일 때는 규칙을 먼저 정합니다.
- AI 가 만든 변경은 PR 설명에 그 사실을 적습니다. 리뷰어가 어디를 더 볼지 정할 수 있습니다.
- 프로젝트 규칙 파일(예: 에디터의 규칙 파일,
CLAUDE.md같은 안내 문서)에 코딩 컨벤션과 금지 사항을 적어 두면 사람마다 다른 결과가 줄어듭니다. - 리뷰는 사람이 합니다. AI 리뷰를 붙이더라도 "AI 가 AI 를 검토하는" 구조만으로 머지하지 않습니다.
Cursor 로 규칙·스킬·리뷰를 나눠 PR 을 만드는 흐름은 Cursor PR 워크플로에 따로 적었습니다.
자주 하는 실수#
- 설명 없이 "고쳐 줘". 무엇이 왜 잘못됐는지 모르면 AI 도 모릅니다.
- 긴 대화를 한 세션에 계속 쌓기. 맥락이 길어지면 앞의 제약을 잊습니다. 작업이 바뀌면 새 대화를 엽니다.
- AI 가 모르는 사내 라이브러리를 쓰게 하기. 그 라이브러리의 사용 예를 먼저 보여 주지 않으면 비슷한 공개 라이브러리 문법으로 지어냅니다.
- 배운 것을 안 남기기. AI 와 해결한 문제는 금방 잊힙니다. 왜 그렇게 고쳤는지 커밋 메시지나 주석에 한 줄 남깁니다.
정리#
AI 페어 프로그래밍은 도구를 고르는 문제라기보다 역할을 정하는 문제였습니다. 자동 완성에서는 읽고 받기, 대화에서는 맥락을 순서대로 주기, 에이전트에서는 검토할 수 있는 크기로 쪼개기. 이 셋만 지켜도 결과가 달라집니다. 생성된 코드는 읽고 넘깁니다. 도구가 바뀌어도 그 습관은 안 바뀌었습니다.
처음 시작하는 사람을 위한 프롬프팅 기초는 Vibe Coding 실전 — AI 페어 프로그래밍의 기술에, VS Code 에서 쓸 확장은 VS Code AI 확장 프로그램 추천 2026에 정리해 두었습니다.
