AI를 도입하고 나면 표준적인 개발 워크플로는 어떤 모습인가요?

Question

IT Interview Practice · Accepted Answer

AI는 소프트웨어 생명주기를 없애지 않습니다 — 각 단계를 **압축** 하고, 여러분의 일을 코드를 *작성하는* 것에서 코드를 **명세하고, 리뷰하고, 검증하는** 것으로 옮깁니다. 동일한 단계(spec → design → implement → review → test → ship)를 유지하되, **사람이 통과시키는 게이트(human gate)** 를 명시적으로 만드세요.

**멘탈 모델:** AI를 빠르고 열정적인 주니어 페어로 다루세요 — 빠르게 초안을 내지만 방향과 점검이 필요합니다. 작업의 단위는 "전부 직접 타이핑"이 아니라 매 단계에서의 *"명세 → 생성 → 검증"* 이 됩니다.

## 워크플로

```text
Spec ──▶ Design ──▶ Implement ──▶ Review ──▶ Test ──▶ Ship
 AI       AI         AI            HUMAN      AI        HUMAN
 draft    options    code+tests    gate       gen+run   gate
```

- **명세(Spec)를 먼저.** AI는 명세만큼만 좋습니다 — 생성 전에 명확한 문제 정의 + 수용 기준(acceptance criteria)을 작성하세요. 쓰레기 명세 → 자신만만한 쓰레기 코드.
- **설계(Design).** AI에게 트레이드오프가 있는 2~3가지 접근을 요청하고, 사람이 고릅니다.
- **구현(Implement).** AI가 코드 + 테스트 초안을 만들고, 여러분은 작고 리뷰 가능한 단계로 방향을 잡습니다.
- **리뷰(사람 게이트, 타협 불가).** 코드를 이해하는 누군가가 승인합니다 — AI 출력은 더 **적게** 가 아니라 더 **많이** 리뷰됩니다.
- **테스트(Test).** AI가 테스트 생성/확장을 돕고, CI가 실행합니다.
- **배포(Ship).** 배포/롤백 결정은 사람이 소유합니다.

핵심 전환: 병목이 *작성*에서 **리뷰와 검증** 으로 옮겨갑니다 — 그러니 순수 타이핑 속도가 아니라 명세, 테스트, 리뷰에 투자하세요.

## 인터뷰 관점

면접관은 여러분이 엔지니어링 규율을 유지하는지, 아니면 그냥 "AI가 쓰게 두는지" 확인합니다. **약한** 답변: "AI가 코드를 쓰니까 더 빨리 배포한다." **강한** 답변: 동일한 생명주기, AI는 각 단계를 가속하고, 사람이 게이트(명세, 리뷰, 배포)를 소유하며, **검증이 새로운 병목** 이다.

## 함정

명세를 건너뛰면 자신만만한 헛소리가 나옵니다; 리뷰를 건너뛰면 품질/보안 부채가 쌓입니다; 코드 줄 수가 아니라 **결과(outcomes)**(동작하는 소프트웨어, 더 적은 장애)를 측정하세요.

워크플로

인터뷰 관점

함정

관련 질문