AI에게 코드를 처음부터 작성하게 할 때와 기존 코드를 리뷰/리팩터링만 하게 할 때는 언제인가요?

Question

IT Interview Practice · Accepted Answer

경험칙: 실수가 싸고 명확한 곳에서는 AI가 **작성**하게 하고, 실수가 비싸거나 미묘한 곳에서는 **리뷰/리팩터링**에 사용하세요. 결정 요인은 출력을 검증하는 데 드는 비용입니다.

## 처음부터 작성하게 할 때

- **Greenfield와 boilerplate** — 새 util, config 파일, CRUD endpoint, regex. 깨뜨릴 숨은 맥락이 없습니다.
- **익숙하지 않은 API/라이브러리** — AI는 당신이 모르는 라이브러리의 표면을 알고, 당신은 docs로 검증합니다.
- **일회용/프로토타입 코드** — 완벽함보다 속도가 중요합니다.

이런 경우 버그 비용이 낮고 결과를 처음부터 끝까지 읽을 수 있습니다.

## 리뷰/리팩터링에만 사용할 때

- **비즈니스 핵심 로직** — 결제, auth, 금액 계산. 그럴듯해 보이는 틀린 답은 위험합니다.
- **미묘한 코드** — concurrency, 보안, "맞아 보이는 것"이 "맞는 것"이 아닌 edge-case가 많은 알고리즘.
- **거대한 기존 시스템** — AI는 코드베이스가 의존하는 모든 불변식을 볼 수 없어서, 그 안에 생성하면 조용히 깨질 위험이 있습니다.

여기서는 AI를 **두 번째 눈**으로 둡니다. AI가 제안하고, 당신이 결정합니다.

```text
                 버그 비용 낮음            버그 비용 높음
새 코드           ✅ AI가 작성              ⚠️ AI 초안, 당신이 강하게 검증
기존 코드         ✅ AI가 리팩터링          ✅ AI가 리뷰, 당신이 변경 작성
```

## 트레이드오프와 위험

처음부터 작성하는 것은 빠르지만 AI가 API를 지어낼(**hallucination**) 수 있거나 볼 수 없는 맥락을 놓칠 수 있습니다. 리뷰는 더 안전하지만 더 느리고 당신이 주는 맥락만큼만 좋습니다. 어느 쪽이든 당신이 **책임지는 작성자**입니다 — AI는 도구이지 commit에 서명하는 사람이 아닙니다.

## 왜 중요한가

이를 잘못 판단하는 것이 AI 보조 개발이 어긋나는 지점입니다. 사람들은 나중에 완전히 검증할 수 없는 핵심 로직을 AI에게 생성하게 하거나, AI가 몇 초 만에 만들 수 있는 사소한 boilerplate를 손으로 씁니다. 모드(**작성** vs **리뷰/리팩터링**)를 **틀렸을 때의 비용**에 맞추면 싼 것에는 빠르고 위험한 것에는 신중해집니다. 시험되는 기술은 검증 노력을 어디에 쏟을지에 대한 판단이지, AI에게 프롬프트를 줄 수 있는지가 아닙니다.

처음부터 작성하게 할 때

리뷰/리팩터링에만 사용할 때

트레이드오프와 위험

왜 중요한가

관련 질문