사전 설계에서 반복 설계로

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

하지만 에이전틱 시대에는 이 원칙의 전제가 바뀌었다. 구현 비용이 극적으로 줄었기 때문이다.

Big Design Up Front의 역사

사전 설계 방식은 구현 비용이 높던 시대의 합리적 전략이었다.

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

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

구현 비용이 줄었다는 것은 구체적으로 무엇을 의미하는가?

동일 기능의 시간 비교

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

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

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

"주문 상태 변경 시 관련자에게 알림을 보내는 시스템"을 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시간.

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

모든 상황에서 반복 설계가 최적인 것은 아니다. 상황별로 어떤 접근이 더 적합한지 달라진다.

이 매트릭스에서 흥미로운 점은, 대부분의 일상적 개발 작업이 좌측(낮은 변경 비용)에 위치한다는 것이다. BDUF가 정말 필요한 우측 상단의 작업은 전체 개발 시간의 일부에 불과한 경우가 많다. 그럼에도 많은 팀에서 모든 작업에 동일한 설계 강도를 적용하는 관성이 관찰된다.

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

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

이것은 "설계 문서가 필요 없다"는 주장이 아니다. **"설계 문서만으로는 정확한 설계가 불가능하다"**는 관찰이다. 설계 문서에 적힌 구조와 실제 구현 과정에서 발견되는 구조 사이에는 거의 항상 괴리가 존재한다. 구현 비용이 높던 시절에는 이 괴리를 감수할 수밖에 없었지만, 구현 비용이 낮아진 지금은 다른 전략이 가능해졌다.

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

Intent - Prototype - Feedback - Refactor

Intent - 의도 정의

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

의도 중심의 정의:

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

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

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

Prototype과 Feedback

생성된 코드를 검토하면서 두 가지를 판단하는 단계다.

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

여기서 피드백의 품질이 반복 설계의 성패를 가르는 경향이 있다.

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

Refactor - 구조 개선

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

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

반복 설계가 실패하는 경우

반복 설계는 만능이 아니다. 실무에서 관찰되는 실패 패턴들이 있다.

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

3회 반복 후에도 구조가 수렴하지 않는 경우, 반복을 계속하는 것보다 멈추고 원인을 진단하는 것이 효과적인 경향이 있다. 수렴하지 않는 원인은 대체로 세 가지 중 하나다: 의도가 모호하거나, 피드백이 부정확하거나, 애초에 BDUF가 필요한 영역이거나.

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

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

BDUF의 숨겨진 비용

BDUF의 직접 비용만 보면 "철저한 설계"로 보이지만, 숨겨진 비용을 포함하면 다른 그림이 나타난다.

반복 설계의 현실적 적용

반복 설계가 이론적으로는 매력적이지만, 실제 도입 과정에서 관찰되는 몇 가지 현실적 측면이 있다.

첫째, 팀 전체가 동시에 전환하기 어렵다. 한 명이 반복 설계로 일하고 나머지가 BDUF로 일하면, 설계 리뷰 과정에서 충돌이 발생하는 경우가 많다. "설계 문서는 어디 있어?"라는 질문에 "작동하는 프로토타입이 여기 있다"는 답이 조직적으로 수용되려면 시간이 필요하다.

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

셋째, 프로토타입에서 프로덕션으로의 전환 단계를 생략하는 유혹이 크다. "작동하는데 왜 다시 만들어?"라는 질문은 자연스럽다. 하지만 프로토타입 코드가 그대로 프로덕션에 올라가면, 6개월 뒤에 그 코드를 유지보수해야 하는 사람이 고통받게 된다. 이 점은 반복 설계를 도입하는 팀에서 가장 빈번하게 관찰되는 함정이다.

이 챕터의 핵심

다음 장 미리보기

다음 챕터에서는 반복 설계의 핵심 도구인 프롬프트를 설계 언어로 다루는 방법을 다룹니다.

참고 자료

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