사전 설계에서 반복 설계로

긴 사전 설계 중심 습관에서 벗어나 AI와 작은 실험을 반복하며 구조를 발견하는 에이전틱 개발 설계 방식을 정리합니다.

핵심 요약

설계 강도는 구현 비용에 비례하며, 구현 비용이 급락한 에이전틱 시대에는 설계 문서 비중을 전체의 5~10%로 줄이는 전략이 맞습니다.
BDUF 대신 IPFR 사이클(Intent → Prototype → Feedback → Refactor)로 구조를 "계획"이 아니라 "발견"으로 도출합니다.
의도만 전달하고 구현 방법은 지정하지 않아야 AI의 가치가 살아납니다. 피드백은 제약조건과 문제 현상을 구체적으로 짚어야 합니다.
3회 반복해도 수렴하지 않으면 멈추고 의도 모호·피드백 부정확·BDUF 영역 중 무엇인지 진단합니다.
팀 간 API 계약, 데이터 모델 핵심 구조, 보안 아키텍처처럼 변경·실수 비용이 큰 영역은 여전히 사전 설계가 필요합니다.

"설계를 충분히 하고 구현에 들어가라." 개발자라면 수없이 들어온 말이다. 그리고 대부분의 경우 맞는 말이었다.

그런데 에이전틱 시대로 오면서 이 원칙의 전제가 바뀌었다. 구현 비용이 확 줄었기 때문이다.

Big Design Up Front의 역사

사전 설계는 구현 비용이 비싸던 시대에는 합리적인 전략이었다.

1970s — 폭포수 모델

구현 비용이 극히 높아 설계에 최대한 투자하던 시대.

1990s — RUP

반복적이지만 여전히 무거운 설계 프로세스.

2001 — 애자일 선언

"작동하는 소프트웨어를 자주 전달." 설계와 구현의 반복이 시작됨.

2010s — 린 스타트업

MVP 중심 빠른 검증. 필요한 만큼만 설계.

2024+ — 에이전틱 코딩

구현 비용이 급격히 하락하면서 설계의 의미 자체가 재정의됨.

각 시대의 설계 강도는 구현 비용에 비례했다.

관찰 기반 모델

퍼센트는 업계 평균 통계가 아니라, 설계 강도가 어떻게 옮겨 갔는지 보여주려고 잡은 개념적 비중입니다.

시대	구현 비용	변경 비용	최적 설계 전략	설계 문서 비중
폭포수 1970s	매우 높음	극히 높음	최대한 사전 설계	전체 시간의 40%
애자일 2000s	보통	관리 가능	충분히 설계하되 반복	전체 시간의 20%
에이전틱 2024+	매우 낮음	매우 낮음	최소 설계 후 빠르게 반복	전체 시간의 5-10%

구현 비용의 극적 변화: 예시 수치

구현 비용이 줄었다는 게 구체적으로 무슨 말일까?

동일 기능의 시간 비교

"사용자 알림 시스템: 이메일 + 슬랙 채널, 실패 시 재시도, 확장 가능한 구조"

단계	BDUF 방식 소요 시간	반복 설계 방식 소요 시간	시간 차이
요구사항 분석	2시간	30분	1.5시간 절약
설계 문서 작성	4시간	의도 문서 15분	3.75시간 절약
설계 리뷰 미팅	1시간	-	1시간 절약
설계 수정	2시간	-	2시간 절약
구현	8시간	AI 생성 + 검증 2시간	6시간 절약
테스트 작성	3시간	AI 생성 + 검증 1시간	2시간 절약
통합 테스트	2시간	1시간	1시간 절약
합계	22시간	약 5시간	17시간 절약

이 비교의 함정

22시간 대 5시간은 극단적인 비교다. 실제로는 반복 설계에서 예상치 못한 문제로 반복을 더 돌려야 하는 경우가 많아, 현실적인 차이는 2-3배 정도다. 중요한 건 절대 시간이 아니라 피드백 루프의 속도다.

변경 비용의 차이가 만드는 전략 변화

구체적 예시: 동일 기능을 두 방식으로 설계

"주문 상태 변경 시 관련자에게 알림을 보내는 시스템"을 BDUF 방식과 반복 설계 방식으로 비교한다.

BDUF 방식의 설계 결과

설계 문서에서 결정한 구조:

src/
  notifications/
    interfaces/
      NotificationChannel.ts
      NotificationStrategy.ts
      NotificationFormatter.ts
    channels/
      EmailChannel.ts
      SlackChannel.ts
      SmsChannel.ts          # 아직 필요 없지만 "확장성을 위해"
    strategies/
      OrderCreatedStrategy.ts
      OrderShippedStrategy.ts
      OrderDeliveredStrategy.ts
    formatters/
      HtmlFormatter.ts
      PlainTextFormatter.ts
      SlackBlockFormatter.ts
    factories/
      ChannelFactory.ts
      StrategyFactory.ts
    NotificationService.ts
    NotificationQueue.ts
    NotificationRetry.ts

파일 13개, 인터페이스 3개, 팩토리 2개. 설계에 6시간, 구현에 12시간. 그런데 출시 후 첫 달에 실제로 쓴 채널은 이메일과 슬랙 2개뿐이었다.

반복 설계 방식의 진행 과정

1회차 - 의도 전달:

"주문 상태가 바뀌면 이메일과 슬랙으로 알림을 보내줘. 전송 실패 시 3회 재시도."

AI가 생성한 첫 구조:

src/
  notifications/
    notify.ts              # 메인 함수
    channels.ts            # 이메일, 슬랙 전송
    retry.ts               # 재시도 로직

3개 파일. 검증 10분. 동작 확인 완료.

2회차 - 피드백:

"새 채널 추가 시 기존 코드 수정 없이 가능하게 해줘."

src/
  notifications/
    notify.ts
    channels/
      email.ts
      slack.ts
      index.ts             # 채널 레지스트리
    retry.ts

4개 파일로 확장. 동작 확인 + 구조 검토 15분.

3회차 - 프로덕션 정제:

"에러 로깅 추가하고, 알림 전송 이력을 DB에 저장해줘."

최종 5개 파일. 총 소요 시간 약 2시간.

YAGNI 원칙의 자연스러운 적용

반복 설계에서는 "나중에 필요할 수도 있으니까" 미리 만들어 두는 코드가 줄어든다. 정말 필요해지면 그때 AI에게 맡기면 되니까, 지금 필요한 것에만 집중하면 된다. 에이전틱 시대에 YAGNI가 더 잘 먹히는 이유다.

BDUF vs 반복 설계: 상황별 판단

반복 설계가 항상 최선인 건 아니다. 상황에 따라 더 잘 맞는 방식이 달라진다.

판단 기준	BDUF가 적합한 경우	반복 설계가 적합한 경우
변경 영향 범위	여러 팀이 의존하는 인터페이스	한 팀 내부 구현
실수 비용	보안, 결제, 의료 등 치명적 영역	일반 비즈니스 로직
요구사항 확실성	법규나 규격으로 확정된 요구사항	사용자 피드백으로 변할 수 있는 요구사항
구현 복잡도	분산 시스템 간 합의가 필요한 경우	단일 서비스 내 기능
되돌리기 비용	DB 스키마, 공개 API 등 롤백 어려움	코드만 변경하면 되는 경우

이 매트릭스에서 눈여겨볼 점은, 일상적인 개발 작업 대부분이 좌측(낮은 변경 비용)에 몰려 있다는 것이다. BDUF가 정말 필요한 우측 상단의 작업은 전체 개발 시간에서 일부에 그치는 경우가 많다. 그런데도 많은 팀이 모든 작업에 똑같은 설계 강도를 적용하는 관성을 보인다.

설계 문서 vs 작동하는 프로토타입

전통적으로 "정확한 설계"의 기준은 설계 문서였다. 하지만 설계 문서에는 구조적인 한계가 있다.

비교 항목	설계 문서	작동하는 프로토타입
모호성	자연어의 해석 차이 존재	코드는 모호하지 않음
실행 가능성	종이 위의 구조	즉시 실행하고 확인 가능
엣지 케이스 발견	상상에 의존	실행하면 드러남
팀 커뮤니케이션	텍스트로 설명	동작하는 데모로 설명
유지보수 비용	문서와 코드 동기화 필요	코드가 곧 문서
초기 투자 비용	작성 시간이 김	빠르게 생성 가능

설계 문서가 필요 없다는 말이 아니다. 설계 문서만으로는 정확한 설계가 나오지 않는다는 이야기다. 설계 문서에 적힌 구조와 막상 구현하면서 발견하는 구조 사이에는 거의 늘 괴리가 생긴다. 구현 비용이 비싸던 시절에는 이 괴리를 감수할 수밖에 없었지만, 구현 비용이 낮아진 지금은 다른 전략을 쓸 수 있다.

반복 설계의 구조: IPFR 사이클

Intent - Prototype - Feedback - Refactor

Intent - 의도 정의

구현 세부사항이 아니라 무엇을 이루려는지를 분명히 하는 단계다.

의도 중심의 정의:

사용자가 결제를 완료하면 이메일과 슬랙으로 알림을 보낸다.
- 전송 실패 시 3회까지 재시도
- 새 채널 추가가 쉬워야 함
- 알림 전송이 결제 프로세스를 블로킹하면 안 됨

구현 방법을 미리 지정한 정의:

Observer 패턴으로 알림 시스템을 만들어.
NotificationService 클래스에 send 메서드가 있고,
EmailChannel과 SlackChannel이 NotificationChannel 인터페이스를 구현해.

구현 방법 지정의 역설

두 번째 예시의 문제는 이미 구조를 정해 버렸다는 데 있다. 의도만 전달하면 AI가 상황에 맞는 구조를 제안하고, 개발자는 그 구조가 적절한지 따져보는 역할을 맡는다. 구조를 미리 못 박으면 AI의 가치가 크게 줄어든다.

Prototype과 Feedback

생성된 코드를 살펴보면서 두 가지를 판단하는 단계다.

동작 정확성: 의도한 대로 작동하는가?
구조 적절성: 이 구조가 향후 변경에 유연한가?

여기서 피드백의 품질이 반복 설계의 성패를 가른다.

모호한 피드백	구체적 피드백	차이점
"더 깔끔하게 해줘"	"알림 채널 추가 시 기존 코드 수정 없이 가능하게 해줘"	구체적 제약조건 제시
"성능이 걱정돼"	"알림 전송이 결제 응답을 블로킹해. 비동기로 분리해줘"	문제 현상 명시
"뭔가 이상해"	"에러 발생 시 재시도 로직이 없어. 3회 재시도 추가해줘"	누락 기능 특정

시니어 개발자가 반복 설계에서 발휘하는 가장 큰 강점이 바로 이 피드백 품질이다. 10년간 쌓은 경험이 "무엇이 문제이고, 왜 문제이며, 어떤 제약조건이 필요한지"를 정확히 짚어내는 능력으로 바뀐다.

Refactor - 구조 개선

2-3회 반복 후 작동하는 프로토타입이 나오면, 구조를 정리하는 단계다. 이때 비로소 패턴 이름을 붙이고, 디렉토리를 정리하고, 인터페이스를 명확히 한다.

예전에는 이 작업을 맨 처음에 했지만, 반복 설계에서는 맨 마지막에 한다. 구조가 "계획"이 아니라 **"발견"**에서 나온다는 관점의 전환이다.

반복 설계가 실패하는 경우

반복 설계는 만능이 아니다. 실무에서 자주 보이는 실패 패턴이 있다.

실패 패턴	증상	원인
방향 없는 반복	5회 이상 반복해도 수렴하지 않음	의도 정의가 모호한 경우가 많음
프로토타입 고착	작동하는 코드를 그대로 프로덕션에 사용	리팩터 단계를 생략하는 경향
부분 최적화 함정	개별 기능은 잘 되지만 전체 구조가 엉망	시스템 레벨 설계가 부재한 경우
피드백 품질 저하	AI가 같은 실수를 반복	피드백이 모호하거나 일관성이 없을 때 발생
시간 역전	반복 설계가 BDUF보다 오래 걸림	잘못된 영역에 반복 설계를 적용한 경우

프로토타입의 프로덕션 직행 문제

반복 설계의 가장 큰 위험은 "작동하니까 이대로 배포하자"는 유혹이다. 프로토타입은 구조를 발견하려고 쓰는 도구이지, 프로덕션 코드가 아니다. 발견한 구조를 바탕으로 프로덕션 품질의 코드를 다시 만드는 과정을 건너뛰면, 기술 부채가 빠르게 쌓인다.

3회 규칙: 수렴 여부의 판단

3회 반복하고도 구조가 수렴하지 않으면, 반복을 더 돌리기보다 일단 멈추고 원인을 진단하는 편이 낫다. 수렴하지 않는 원인은 대체로 셋 중 하나다: 의도가 모호하거나, 피드백이 부정확하거나, 애초에 BDUF가 필요한 영역이거나.

사전 설계가 여전히 필요한 영역

영역	사전 설계 필요도	이유	반복 설계와의 결합
팀 간 API 계약	높음	여러 팀이 동시에 의존	API 스펙만 BDUF, 구현은 반복
데이터 모델 핵심 구조	높음	마이그레이션 비용이 여전히 높음	필드 추가는 반복, 구조 변경은 BDUF
보안 아키텍처	높음	실수의 비용이 극히 높음	위협 모델은 BDUF, 구현은 반복
UI 인터랙션	낮음	빠르게 만들어보고 피드백	전면 반복 설계
내부 유틸리티	낮음	변경 영향 범위가 작음	전면 반복 설계
프로토타입 PoC	매우 낮음	검증이 목적	전면 반복 설계

여기서 눈에 띄는 패턴이 있다. BDUF가 필요한 영역과 반복 설계가 맞는 영역은 서로 배타적이지 않다. 오히려 한 프로젝트 안에서 두 방식이 공존하는 게 가장 현실적이다. API 스펙은 BDUF로 합의하고, 그 스펙의 구현은 반복 설계로 빠르게 진행하는 식이다.

BDUF의 숨겨진 비용

BDUF는 직접 비용만 보면 "철저한 설계"처럼 보이지만, 숨은 비용까지 따지면 그림이 달라진다.

비용 항목	BDUF	반복 설계
설계 문서 작성 시간	4-8시간	15-30분
설계 문서 유지보수	구현 변경 때마다 동기화 필요	코드가 곧 문서
설계 리뷰 미팅 비용	참석자 수 x 1시간	코드 리뷰로 대체
과잉 설계 비용	사용되지 않는 추상화 구현	필요할 때 추가
설계-구현 괴리 비용	구현하며 설계와 달라지는 비용	괴리가 발생하지 않음
잘못된 설계 방향 비용	설계 완료 후 방향 전환 어려움	언제든 방향 전환 가능

가장 비싼 비용은 마지막 행이다

BDUF의 가장 큰 숨은 비용은 매몰 비용 효과다. 6시간 들여 만든 설계 문서가 있으면, 더 나은 방향이 보여도 "이미 설계했으니까"라며 기존 방향을 붙잡게 된다. 반복 설계에서는 이 함정에 빠질 여지가 줄어든다.

반복 설계의 현실적 적용

반복 설계는 이론으로는 매력적이지만, 막상 도입해 보면 부딪히는 현실이 몇 가지 있다.

첫째, 팀 전체가 한꺼번에 전환하기는 어렵다. 한 명은 반복 설계로 일하는데 나머지는 BDUF로 일하면, 설계 리뷰에서 충돌이 잦다. "설계 문서는 어디 있어?"라는 질문에 "작동하는 프로토타입이 여기 있다"는 답이 조직에 받아들여지려면 시간이 걸린다.

둘째, IPFR 사이클의 품질은 의도를 정의하는 능력에 크게 좌우된다. 시니어 개발자가 반복 설계에서 강점을 발휘하는 이유가 바로 여기 있다. 10년간 쌓은 도메인 지식과 기술적 판단력이 정확한 의도 정의와 날카로운 피드백으로 이어진다.

셋째, 프로토타입에서 프로덕션으로 넘어가는 단계를 건너뛰고 싶은 유혹이 크다. "작동하는데 왜 다시 만들어?"라는 의문은 자연스럽다. 하지만 프로토타입 코드가 그대로 프로덕션에 올라가면, 6개월 뒤에 그 코드를 유지보수해야 하는 사람이 고생한다. 반복 설계를 도입하는 팀에서 가장 자주 보이는 함정이다.

Beck, K. et al. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org/