DevAI회고

AI 페어 프로그래밍에서 내가 망친 5가지, 그리고 고친 방법

2026.04.16

잘 쓰는 법보다 잘못 쓰는 법이 많다

AI 페어 프로그래밍을 1년쯤 하면서 깨달은 게 있다. 잘 쓰는 패턴은 한정적인데, 잘못 쓰는 방식은 끝없이 다양하다. 내가 망친 케이스를 모아보면 자기 위로용 컬렉션이 한 권 나온다.

이 글은 그 컬렉션에서 다섯 개를 골라낸 거다. 가르치려는 글이 아니라 솔직한 회고다. 같은 함정에 빠지는 사람이 있다면, "혼자만 그런 게 아니구나" 정도로 위안 삼아도 좋다.

1. "다 알아서 해줘"의 함정

가장 먼저 망친 패턴이다. 큰 작업을 한 줄로 던졌다.

> 결제 시스템 만들어줘

AI는 진짜로 코드를 다 만든다. 파일 수십 개가 한 번에 들어찬다. 그래서 좋아 보였다. 30분 만에 결제 시스템이 생긴 줄 알았다.

문제는 그 다음 주에 터졌다. 내가 그 코드를 한 줄도 이해하지 못하고 있었다. 사용한 라이브러리를 모르고, DB 스키마가 왜 그렇게 됐는지 모르고, 트랜잭션 경계가 어디인지 몰랐다. 버그가 났을 때 내가 할 수 있는 게 없었다.

어떻게 고쳤나

큰 작업을 한 줄로 던지지 않는다. 대신 Plan Mode나 brainstorming 스킬로 먼저 설계를 같이 한다. AI에게 단계별 계획을 받고, 각 단계의 의도를 묻고, 내가 이해한 다음에 구현으로 들어간다.

규칙: 내가 그 코드를 디버깅할 자신이 없으면, AI에게 만들지 말라고 한다. 만들어달라고 하기 전에 내가 한 줄로 그 코드의 핵심 로직을 설명할 수 있어야 한다.

2. AI가 만든 테스트를 그대로 믿는다

"테스트 코드도 짜줘"라고 시켰다. AI가 테스트를 만들었다. 테스트가 통과했다. 끝난 줄 알았다.

며칠 뒤 프로덕션에서 버그가 발견됐다. 검증해보니 테스트가 테스트하고 있다고 착각하는 케이스였다. mock이 너무 많아서 실제 로직이 한 번도 실행되지 않거나, assertion이 의미 없는 부분만 검증하거나, 엣지 케이스가 누락돼 있었다.

AI가 "테스트 통과"라고 하는 것과 "이 코드가 정확하다"는 같은 말이 아니다. AI가 만든 테스트는 자기가 만든 코드의 행동을 그대로 테스트하기 쉽다. 즉 버그가 있으면 그 버그를 검증하는 테스트가 만들어진다.

어떻게 고쳤나

테스트를 받으면 두 가지를 항상 한다.

  1. 테스트가 무엇을 검증하는지 한 줄로 요약해보라고 시킨다. 요약이 모호하면 테스트가 모호한 거다.
  2. 고의로 코드를 깨뜨려본다. 핵심 로직을 한 줄 주석 처리하고 테스트를 돌린다. 테스트가 실패하지 않으면, 그건 아무것도 검증하지 않는 테스트다.

이 두 단계만 추가해도 가짜 테스트의 절반 이상이 걸러진다.

3. 컨텍스트를 매번 새로 시작한다

같은 프로젝트를 매일 만지는데, 매번 Claude Code 세션을 새로 열어서 처음부터 설명했다. "이 프로젝트는 Next.js를 쓰고, DB는 Supabase고..." 하루에 같은 말을 다섯 번씩 했다.

문제는 시간 낭비뿐 아니라, 매번 약간씩 다르게 설명한다는 거였다. 어느 날은 캐싱 정책을 자세히 말하고, 어느 날은 인증 방식을 자세히 말한다. AI가 받는 인상이 매일 달라진다. 같은 질문에 다른 답이 나오기 시작한다.

어떻게 고쳤나

CLAUDE.md에 프로젝트 컨텍스트를 박는다. 한 번 잘 써두면 모든 세션에서 같은 컨텍스트가 들어온다. 매일 다섯 번씩 설명하던 걸 안 해도 된다.

CLAUDE.md를 처음 쓸 때 흔한 실수가 너무 길게 쓰는 거다. 토큰만 잡아먹고 효과가 떨어진다. 핵심만 추리는 게 중요하다. 그 얘기를 따로 정리한 글이 있다.

4. AI에게 "왜?"를 안 물었다

AI가 코드를 만들면, 그 코드가 동작하는지만 봤다. 왜 그렇게 짰는지는 안 물었다. 동작하니까 됐다고 생각했다.

이 패턴의 문제는 늦게 드러난다. 6개월쯤 지나서 그 코드를 다시 만질 때, 왜 거기에 그 if문이 있는지 아무도 모른다. AI도 모른다. 코드만 남고 의도가 사라진다.

어떻게 고쳤나

코드를 받으면 선택의 이유를 묻는 습관을 들였다.

> 왜 useEffect 대신 useLayoutEffect를 썼지?
> 이 부분에 트랜잭션을 안 걸어도 되는 이유가 있나?
> 이 함수를 분리한 이유가 뭐야?

대답이 그럴듯하면 그 답을 코드 옆에 한 줄 코멘트로 남기거나, 커밋 메시지에 적는다. 대답이 모호하면 그 부분을 다시 점검한다. 보통 모호한 대답이 나오는 자리에 잠재 버그가 있다.

5. 잘못된 것을 빠르게 만드는 데 집중했다

AI 도구의 매력은 속도다. 5분 만에 컴포넌트 하나가 뚝딱 나온다. 그 속도에 취해서, 속도가 잘못된 방향을 만드는 데도 적용된다는 걸 잊었다.

예: 어느 날 사용자 검색 기능을 만들었다. AI가 5분 만에 만들어줬다. 1주일 뒤에 보니, 기능 자체가 잘못된 방향이었다. 페이지네이션이 아니라 무한 스크롤이어야 했고, 검색은 풀텍스트가 아니라 카테고리 필터가 우선이어야 했다. 5분짜리 결과물이 1주일을 낭비한 출발점이 됐다.

AI는 무엇을 만들지 안 정해준다. 그건 사람의 일이다. 잘못된 명세를 받으면 잘못된 걸 빠르게 만든다.

어떻게 고쳤나

코드를 시키기 전에 요구사항을 한 번 더 확인하는 의식을 박았다. brainstorming 스킬, deep-interview, 또는 그냥 종이에 적어보기. 사용 시나리오 3개를 적고, 그 시나리오에서 이 기능이 어떻게 동작하는지 확인한다.

요구사항이 흔들리는 자리에서는 코드를 시키지 않는다. 코드 시키기는 가장 비싼 의사결정이다.

공통 패턴

다섯 가지를 늘어놓고 보니 공통점이 보인다. AI에게 의사결정을 떠넘긴 자리에서 망쳤다.

  • 1번: 설계 결정을 떠넘김
  • 2번: 검증 책임을 떠넘김
  • 3번: 컨텍스트 관리를 떠넘김
  • 4번: 의도 기록을 떠넘김
  • 5번: 요구사항 정의를 떠넘김

AI는 도구다. 도구는 결정을 못 한다. 결정은 사람이, 실행은 AI가라는 분담이 무너지면 결과물이 무너진다.

거꾸로 말하면, 이 분담을 의식하기 시작한 다음부터는 AI 도구의 가치가 눈에 띄게 올라갔다. 같은 도구인데 결과가 다르다. 도구가 좋아진 게 아니라, 내가 도구를 잘못 쓰던 걸 멈춘 거다.

정리

AI 페어 프로그래밍을 잘하는 법은 결국 AI에게 무엇을 시키지 않을지를 정하는 것에 가깝다. 시킬 수 있는 건 많다. 시키지 말아야 하는 것을 가려내는 게 어렵다.

내 다섯 가지 실패 패턴을 한 줄씩 정리하면 이렇다.

  1. 큰 작업을 한 줄로 던지지 마라
  2. AI가 만든 테스트를 그대로 믿지 마라
  3. 컨텍스트를 매 세션 다시 입력하지 마라
  4. 코드를 받으면 "왜"를 물어라
  5. 요구사항이 흔들리면 코드를 시키지 마라

이 다섯 가지 다음에 또 다른 실패 다섯 가지가 기다리고 있을 거다. AI 도구는 빠르게 변하고, 잘못 쓰는 법도 같이 변한다. 그래도 한 번 망쳐본 패턴에는 다시 안 빠진다는 게 위안이다.