AI Driven Development는 AI에게 코드를 맡기는 방식이 아니라, 개발자가 문제 정의와 검증을 더 촘촘하게 하는 작업 방식입니다. 이 글은 3부작 중 1탄으로, 팀이나 개인 프로젝트에 AI 기반 개발 흐름을 적용하기 전에 필요한 기본 루프를 정리합니다. 글을 읽고 나면 요구사항을 작은 작업으로 나누고, AI 초안을 테스트와 리뷰로 닫는 실무 흐름을 설계할 수 있습니다.

이 글은 2026년 7월 1일 기준의 GitHub Copilot 문서와 DORA 연구 자료를 참고했습니다. 특정 도구의 최신 기능보다 오래 유지되는 개발 프로세스에 초점을 맞춥니다.

시리즈에서 다룰 범위

이번 시리즈는 AI Driven Development를 개인의 생산성 팁이 아니라 개발 프로세스 관점에서 정리합니다. 1탄은 작업 흐름, 2탄은 팀 규칙과 코드베이스 컨텍스트, 3탄은 품질 측정과 운영 적용을 다룰 예정입니다.

편	주제	핵심 질문
1탄	작업 흐름 설계	AI를 개발 루프 어디에 넣을 것인가?
2탄	팀 규칙과 컨텍스트	AI가 따라야 할 기준을 어떻게 제공할 것인가?
3탄	품질 측정과 운영	빨라진 개발이 품질 저하로 이어지지 않게 어떻게 볼 것인가?

이 글의 목표는 “좋은 프롬프트 모음”을 만드는 것이 아닙니다. 프롬프트는 중요하지만, 프롬프트만 잘 써서는 실무 개발이 안정되지 않습니다. 실제로 필요한 것은 AI가 만든 결과를 받아들이기 전에 요구사항, 변경 범위, 테스트, 리뷰 기준을 명확히 하는 루프입니다.

AI Driven Development란 무엇인가

AI Driven Development는 개발자가 AI 도구를 사용해 분석, 설계, 구현, 테스트, 리뷰의 일부를 빠르게 반복하는 방식입니다. 여기서 중요한 단어는 Driven입니다. AI가 모든 결정을 대신한다는 뜻이 아니라, 개발 흐름을 더 작은 검증 단위로 움직이게 만드는 동력으로 AI를 사용한다는 뜻에 가깝습니다.

기존 개발에서는 요구사항을 읽고 개발자가 머릿속에서 설계를 만든 뒤 코드를 작성했습니다. AI를 도입하면 이 흐름이 조금 바뀝니다. 개발자는 먼저 요구사항과 제약을 명확히 쓰고, AI에게 초안이나 대안을 요청한 다음, 그 결과가 실제 코드베이스와 운영 조건에 맞는지 검증합니다.

따라서 AI Driven Development의 핵심은 자동 생성이 아니라 짧은 피드백 루프입니다. 한 번에 큰 기능을 맡기면 틀린 방향으로 빠르게 멀어질 수 있습니다. 반대로 작은 작업 단위로 나누면 AI가 만든 결과를 사람이 이해하고 테스트하기 쉬워집니다.

왜 작업 흐름부터 설계해야 할까?

AI 도구를 처음 도입할 때 흔한 실수는 도구 사용법부터 익히는 것입니다. 물론 단축키와 명령어도 필요합니다. 하지만 실제 실패는 도구를 못 써서가 아니라, 어떤 일을 맡길지 정하지 않은 상태에서 결과를 그대로 받아들이기 때문에 생깁니다.

예를 들어 “주문 취소 기능 만들어 줘”라고 요청하면 AI는 컨트롤러, 서비스, 테스트 초안을 빠르게 만들 수 있습니다. 문제는 취소 가능 시간, 결제 상태, 부분 취소, 정산 이후 처리, 이벤트 발행, 중복 요청 같은 정책이 빠질 수 있다는 점입니다. 이 정보는 도구가 자동으로 알 수 없습니다.

작업 흐름을 먼저 설계하면 AI에게 맡길 일과 사람이 판단할 일을 분리할 수 있습니다. 반복적인 코드 초안, 테스트 케이스 후보, 리팩터링 대안은 AI에게 맡기기 좋습니다. 반면 도메인 정책, 장애 시 피해 범위, 데이터 정합성, 배포 전략은 사람이 먼저 기준을 정해야 합니다.

기본 루프: 정의, 분해, 생성, 검증

AI Driven Development의 기본 루프는 네 단계로 시작하면 충분합니다.

단계	개발자의 역할	AI에게 맡길 수 있는 일	산출물
정의	문제와 완료 조건을 쓴다	빠진 질문 후보 제안	작업 카드, 수용 기준
분해	변경 범위를 작게 나눈다	구현 순서와 영향 파일 후보 제안	작은 작업 목록
생성	초안을 요청한다	코드, 테스트, 문서 초안 생성	변경 후보
검증	테스트와 리뷰로 확인한다	회귀 위험, 누락 케이스 점검	통과한 변경

이 루프는 복잡해 보이지만 실제로는 평소 개발을 더 명시적으로 적는 일입니다. AI가 없을 때도 좋은 개발자는 비슷한 과정을 머릿속으로 거칩니다. AI를 사용할 때는 그 과정을 글로 남겨야 합니다. 그래야 AI가 같은 맥락을 따라오고, 사람도 결과를 검증할 기준을 잃지 않습니다.

1단계: 요구사항을 작업 계약으로 바꾸기

AI에게 바로 구현을 요청하기 전에 요구사항을 작업 계약으로 바꿔야 합니다. 작업 계약은 거창한 문서가 아닙니다. 무엇을 바꿀지, 무엇은 바꾸지 않을지, 어떤 조건을 만족하면 끝났다고 볼지 적은 짧은 기준입니다.

아래 예시는 주문 취소 API를 추가한다고 가정한 작업 계약입니다. 실제 서비스에서는 더 많은 정책이 필요하지만, 핵심은 AI에게도 사람 리뷰어에게도 같은 기준을 제공하는 것입니다.

작업 목표:
- 배송 시작 전 주문을 사용자가 취소할 수 있게 한다.

변경 범위:
- 주문 단건 취소 API를 추가한다.
- 기존 결제 취소 로직은 직접 변경하지 않고 포트를 통해 호출한다.
- 관리자 취소 기능은 이번 작업에서 제외한다.

수용 기준:
- 본인 주문이 아니면 403을 반환한다.
- 이미 배송 시작된 주문은 409를 반환한다.
- 같은 취소 요청이 두 번 들어와도 주문 상태가 한 번만 바뀐다.
- 성공 시 OrderCancelled 이벤트를 한 번 발행한다.

검증:
- 단위 테스트로 상태 전이와 권한을 확인한다.
- 통합 테스트로 API 응답 코드를 확인한다.

이 정도만 적어도 AI 응답의 품질이 달라집니다. “취소 기능 구현”이라는 모호한 요청은 다양한 해석이 가능하지만, 위 계약은 구현 범위와 제외 범위를 함께 알려 줍니다. 특히 제외 범위가 중요합니다. AI는 도움이 되려고 주변 코드까지 바꾸는 초안을 만들 수 있기 때문입니다.

작업 계약을 만들 때는 먼저 AI에게 질문을 시키는 방식도 좋습니다. “이 요구사항에서 구현 전에 확인해야 할 정책 질문을 10개만 뽑아 줘”라고 요청하면 놓친 조건을 발견하기 쉽습니다. 다만 질문의 답은 도구가 아니라 제품 담당자, 도메인 담당자, 운영 경험을 가진 개발자가 확정해야 합니다.

2단계: 작은 단위로 분해하기

AI는 작은 작업에서 더 잘 동작합니다. 한 번에 엔티티, API, 이벤트, 마이그레이션, 테스트, 문서까지 맡기면 결과가 커지고 검토 비용도 커집니다. 특히 기존 코드베이스에서는 작은 변경일수록 스타일과 경계를 맞추기 쉽습니다.

주문 취소 기능이라면 다음처럼 나눌 수 있습니다.

• 도메인 상태 전이 규칙과 테스트를 먼저 작성한다.
• 취소 유스케이스 서비스와 포트를 추가한다.
• API 컨트롤러와 요청/응답 DTO를 연결한다.
• 이벤트 발행과 멱등성 처리를 추가한다.
• 통합 테스트와 문서를 보강한다.

분해의 기준은 “한 번에 리뷰할 수 있는가?”입니다. AI가 만든 코드가 500줄을 넘어가면 개발자는 이상한 부분을 놓치기 쉽습니다. 반대로 50줄 안팎의 변경은 의도와 결과를 비교하기 좋습니다. 작은 작업은 실패해도 되돌리기 쉽고, 다음 프롬프트에 이전 결과를 반영하기도 쉽습니다.

이때 AI에게 “구현해 줘”보다 “작업을 어떤 순서로 나누면 테스트 가능한가?”를 먼저 물어보는 편이 좋습니다. 도구가 제안한 순서를 그대로 따를 필요는 없지만, 영향 범위 후보를 빠르게 훑는 데 도움이 됩니다.

3단계: AI에게 줄 컨텍스트를 고르기

AI에게 컨텍스트를 많이 주는 것이 항상 좋은 것은 아닙니다. 관련 없는 파일이 많으면 응답이 산만해지고, 오래된 코드 패턴을 따라 할 수도 있습니다. 필요한 것은 전체 저장소 덤프가 아니라 이번 작업의 판단에 필요한 최소 자료입니다.

보통은 다음 자료를 우선 제공합니다.

• 비슷한 기능의 기존 구현 파일
• 도메인 모델과 상태 전이 코드
• 테스트 스타일을 보여 주는 최근 테스트
• 에러 응답 규칙이나 API 응답 포맷
• 팀이 지켜야 하는 코딩 규칙

컨텍스트를 줄 때는 “이 파일들을 참고하되, 공개 API 이름은 바꾸지 마라”처럼 제약을 함께 적는 것이 좋습니다. 제약 없이 예시 파일만 주면 AI가 더 깔끔해 보이는 구조로 바꾸려 할 수 있습니다. 실무에서는 깔끔함보다 호환성과 변경 범위가 더 중요할 때가 많습니다.

실전 예제: 테스트 가능한 요청으로 바꾸기

아래 코드는 주문 취소 정책을 아주 단순화한 Java 예제입니다. 핵심은 AI에게 이런 테스트를 먼저 만들게 하거나, 최소한 이 테스트를 통과하는 구현만 요청하는 방식으로 작업을 좁히는 것입니다.

import java.time.LocalDateTime;

public final class OrderCancelPolicy {
    public enum Status {
        PAID,
        PREPARING,
        SHIPPED,
        CANCELLED
    }

    public record Order(
            long id,
            long ownerId,
            Status status,
            LocalDateTime cancelledAt
    ) {
        public Order cancel(long requesterId, LocalDateTime requestedAt) {
            if (ownerId != requesterId) {
                throw new ForbiddenOrderAccessException();
            }

            if (status == Status.SHIPPED) {
                throw new OrderAlreadyShippedException();
            }

            if (status == Status.CANCELLED) {
                return this;
            }

            return new Order(id, ownerId, Status.CANCELLED, requestedAt);
        }
    }

    public static final class ForbiddenOrderAccessException
            extends RuntimeException {
    }

    public static final class OrderAlreadyShippedException
            extends RuntimeException {
    }
}

이 코드는 프레임워크 없이 정책만 보여 줍니다. 실무에서는 엔티티 구조, 예외 타입, 이벤트 발행 방식이 프로젝트마다 다릅니다. 그래서 AI에게 “이 코드 그대로 넣어 줘”라고 요청하기보다, 기존 프로젝트의 주문 모델을 참고해 같은 정책을 테스트로 표현하게 하는 편이 안전합니다.

예를 들어 다음처럼 요청할 수 있습니다.

Order 도메인의 취소 정책 테스트를 먼저 작성해 주세요.

참고할 파일:
- Order.java
- OrderStatus.java
- OrderTest.java

반드시 검증할 조건:
- 주문 소유자가 아니면 예외가 발생한다.
- 배송 시작 상태에서는 취소할 수 없다.
- 이미 취소된 주문은 같은 요청을 다시 받아도 상태가 바뀌지 않는다.
- 취소 성공 시 취소 시간이 기록된다.

제약:
- 운영 코드 변경 없이 테스트 초안만 작성한다.
- 기존 테스트 스타일과 assertion 방식을 따른다.

이 요청의 장점은 AI가 바로 운영 코드를 바꾸지 않는다는 점입니다. 먼저 테스트 초안을 보고 정책 이해가 맞는지 확인할 수 있습니다. 테스트가 틀렸다면 구현 전에 수정하면 됩니다. 테스트가 맞다면 그다음에 “방금 작성한 테스트를 통과하도록 최소 변경만 해 주세요”라고 요청할 수 있습니다.

4단계: 검증을 사람의 마지막 단계로 남기지 않기

AI로 개발 속도가 빨라질수록 검증을 마지막에 몰아넣으면 위험합니다. 빠르게 만든 변경이 많아진 뒤에야 테스트가 깨지면 원인을 찾기 어렵습니다. 검증은 마지막 관문이 아니라 각 작업 단위마다 붙는 작은 문이어야 합니다.

가장 단순한 검증 흐름은 다음과 같습니다.

1. AI에게 요구사항의 빠진 질문을 묻게 한다.
2. 개발자가 답을 확정해 작업 계약을 만든다.
3. AI에게 테스트 초안을 요청한다.
4. 개발자가 테스트의 정책 해석을 검토한다.
5. AI에게 최소 구현을 요청한다.
6. 로컬 테스트와 정적 분석을 실행한다.
7. AI에게 변경 diff 기준의 리뷰를 요청한다.
8. 사람이 최종 리뷰에서 도메인과 운영 위험을 확인한다.

여기서 AI 리뷰는 사람 리뷰를 대체하지 않습니다. AI는 반복적인 누락, 네이밍 불일치, 테스트 케이스 후보를 찾는 데 유용합니다. 하지만 도메인 정책이 맞는지, 장애가 났을 때 피해가 어디까지 번지는지, 배포 순서가 안전한지는 사람이 판단해야 합니다.

리뷰 프롬프트는 구현 프롬프트와 달라야 한다

구현을 요청할 때는 목표와 제약을 줍니다. 리뷰를 요청할 때는 관점을 줘야 합니다. 같은 AI에게 “리뷰해 줘”라고만 하면 일반적인 스타일 피드백에 머물 수 있습니다.

다음처럼 리뷰 관점을 좁히면 결과가 더 쓸모 있어집니다.

아래 diff를 리뷰해 주세요.

관점:
- 기존 API 호환성이 깨지는 부분이 있는가?
- 주문 취소가 중복 실행될 가능성이 있는가?
- 테스트가 구현을 따라 쓰기만 하고 정책을 검증하지 않는가?
- 예외가 사용자에게 잘못된 HTTP 상태로 매핑되는가?

출력 형식:
- 심각도 높은 문제부터 정리한다.
- 문제가 없으면 억지로 지적하지 않는다.
- 스타일 취향보다 동작 오류와 회귀 위험을 우선한다.

이 프롬프트는 리뷰 기준을 코드 스타일보다 동작과 회귀 위험에 둡니다. AI 리뷰의 목적은 “뭔가를 말하게 하는 것”이 아니라, 사람이 놓치기 쉬운 검토 관점을 빠르게 보조하는 것입니다. 아무 문제도 없을 때 억지 피드백을 만들지 말라는 조건도 중요합니다.

자주 하는 실수와 주의사항

큰 작업을 한 번에 맡긴다

큰 작업은 AI가 보기에도, 사람이 검토하기에도 어렵습니다. 결과가 그럴듯해 보여도 요구사항 일부가 빠졌는지 확인하기 힘듭니다. 기능을 도메인 규칙, 어댑터 연결, API, 테스트, 문서처럼 작게 나누고 각 단계마다 검증해야 합니다.

수용 기준 없이 구현부터 요청한다

수용 기준이 없으면 AI는 가장 흔한 구현을 제안합니다. 하지만 실무 기능의 차이는 흔한 코드가 아니라 예외 정책에서 생깁니다. “성공해야 한다”보다 “어떤 경우에 실패해야 하는가”를 먼저 적어야 합니다.

AI가 만든 테스트를 그대로 신뢰한다

AI가 만든 테스트는 종종 구현을 그대로 따라 씁니다. 이런 테스트는 회귀를 막기보다 현재 코드를 고정하는 역할만 합니다. 테스트 이름과 assertion이 요구사항의 언어로 쓰였는지 확인해야 합니다.

코드베이스 규칙을 매번 새로 설명한다

매번 프롬프트에 규칙을 길게 쓰면 누락이 생깁니다. 팀에서 반복적으로 쓰는 규칙은 저장소 문서, PR 템플릿, 도구별 instruction 파일로 관리하는 편이 좋습니다. 이 내용은 2탄에서 더 자세히 다룰 예정입니다.

속도만 지표로 본다

AI 도입 후 작업 시간이 줄어도 결함, 재작업, 리뷰 지연이 늘면 전체 개발 성과는 좋아졌다고 보기 어렵습니다. DORA 연구에서도 AI 도입은 개인 생산성과 만족도 같은 이점과 함께 소프트웨어 전달 안정성 측면의 tradeoff를 같이 봐야 한다고 설명합니다. 팀은 속도와 품질을 함께 관찰해야 합니다.

언제 AI에게 맡기기 좋은가

AI는 반복과 비교가 많은 작업에서 특히 유용합니다. 기존 패턴을 참고한 DTO, 테스트 후보, 마이그레이션 초안, 문서 초안, 로그 분석, 리팩터링 대안처럼 정답을 검증할 수 있는 작업이 좋습니다.

반대로 다음 작업은 바로 맡기기보다 사람이 먼저 경계를 정해야 합니다.

• 결제, 권한, 개인정보처럼 실패 비용이 큰 변경
• 데이터 마이그레이션과 롤백 전략이 필요한 변경
• 요구사항이 아직 정책으로 확정되지 않은 기능
• 장애 대응 절차나 운영 권한을 바꾸는 작업
• 보안 토큰, 고객 데이터, 내부 비밀값이 포함될 수 있는 작업

AI를 쓰지 말자는 뜻이 아닙니다. 이런 작업에서도 AI는 체크리스트, 테스트 후보, 위험 분석 초안을 만들 수 있습니다. 다만 실행 권한과 최종 판단은 사람과 시스템의 검증 절차 안에 있어야 합니다.

개인 프로젝트에 바로 적용하는 작은 시작

팀 전체 프로세스를 바꾸기 전에는 개인 작업에서 작은 루프를 먼저 시도하는 것이 좋습니다. 다음 템플릿을 작업 시작 전에 작성해 보세요.

오늘 작업:

문제:

변경 범위:

제외 범위:

AI에게 맡길 일:

내가 직접 판단할 일:

완료 조건:

검증 명령:

처음에는 번거롭게 느껴질 수 있습니다. 하지만 이 템플릿은 AI에게 줄 컨텍스트이면서, 나중에 PR 설명과 리뷰 체크리스트가 됩니다. 개발 중간에 방향이 바뀌면 템플릿을 수정하고 다시 작은 작업으로 나누면 됩니다.

개인 프로젝트에서는 특히 “검증 명령”을 비워 두지 않는 습관이 중요합니다. ./gradlew test, npm test, bundle exec jekyll build처럼 실제로 실행할 명령을 적어 두면 AI가 만든 변경을 감으로 받아들이지 않게 됩니다.

팀에 적용하기 전 체크리스트

AI Driven Development를 팀에 적용하려면 도구 계정부터 배포하기보다 다음 질문에 먼저 답해야 합니다.

• 어떤 작업은 AI 사용을 권장하고, 어떤 작업은 제한할 것인가?
• 저장소의 코딩 규칙과 아키텍처 경계는 어디에 문서화할 것인가?
• AI가 만든 코드는 일반 코드와 같은 리뷰 기준을 통과하는가?
• 테스트가 없는 영역에서 AI 생성 코드를 어떻게 제한할 것인가?
• 민감 정보와 고객 데이터를 프롬프트에 넣지 않도록 어떤 장치를 둘 것인가?
• 생산성뿐 아니라 결함, 재작업, 리뷰 시간도 함께 볼 것인가?

이 질문은 2탄과 3탄으로 이어지는 다리입니다. 2탄에서는 저장소 규칙, 프롬프트 파일, 코드베이스 컨텍스트를 정리하는 방법을 다룹니다. 3탄에서는 AI 도입 후 품질과 운영 안정성을 어떻게 측정할지 살펴볼 예정입니다.

결론 및 도움말

AI Driven Development의 출발점은 더 강한 도구를 고르는 일이 아니라, 개발 작업을 더 작고 검증 가능한 단위로 바꾸는 일입니다. 요구사항을 작업 계약으로 만들고, 작은 단위로 분해하고, AI 초안을 테스트와 리뷰로 닫는 흐름이 먼저입니다.

AI는 개발 속도를 높일 수 있지만, 방향과 기준이 없으면 잘못된 코드를 더 빠르게 만들 수도 있습니다. 1탄에서는 기본 루프를 잡았으니, 다음 글에서는 이 루프가 팀 안에서 반복되도록 저장소 규칙과 컨텍스트를 설계하는 방법을 다루겠습니다.

참고자료/레퍼런스

• GitHub Docs: Prompt engineering for GitHub Copilot
• GitHub Docs: Responsible use of GitHub Copilot features
• DORA: Artificial Intelligence
• DORA: 2024 Accelerate State of DevOps Report
• Martin Fowler: Exploring Generative AI