사전 설계에서 반복 설계로

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

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

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/