설계는 정답을 고르는 게 아니라 변경 비용을 정하는 일이다

1️⃣ 설계에 “정답”이 없다는 이유

환경은 항상 이렇습니다.

• 요구사항은 변한다
• 조직은 바뀐다
• 인력은 교체된다
• 예산과 일정은 흔들린다

그래서 설계의 질문은 이게 아닙니다.
❌ “가장 좋은 구조는?”
⭕ “무엇이 바뀔 때 제일 아프게 할 것인가?”

---

2️⃣ 변경 비용은 항상 비대칭이다

모든 변경 비용을 낮출 수는 없습니다.

바뀌는 것비용을 낮춰야 하는 이유

비즈니스 규칙	자주 바뀜
외부 연동	통제 불가
정책/법규	예측 불가
화면/플로우	민감

반대로:

바뀌지 말아야 할 것이유

핵심 도메인 모델	시스템 정체성
데이터 의미	과거까지 영향
권한/정합성 규칙	법·감사 리스크

👉 설계는 변경이 잦은 쪽에 여유를 주는 작업입니다.

---

3️⃣ 잘못된 설계의 신호

• “이건 처음부터 이렇게 가기로 했잖아요”
• “지금 구조상 어렵습니다”
• “전체 리팩토링이 필요합니다”
• “다음 버전에…”

이 말들이 잦아지면
변경 비용을 잘못 배치한 설계입니다.

---

4️⃣ 변경 비용을 다루는 실전 도구

• 도메인 경계 분리 (패키지·모듈)
• 인터페이스 우선 설계
• 정책/룰 외부화
• 데이터 이력 보존
• Feature Toggle

이건 패턴이 아니라 비용 제어 장치입니다.

---

5️⃣ 설계 판단 기준 문장

“이 요구가 바뀌면, 어디를 고치게 되는가?”

• 한 곳 → 좋은 설계
• 여러 레이어 → 위험
• DB부터 건드림 → 실패

---

6️⃣ 한 줄 요약

설계는 미래를 맞추는 일이 아니라,
미래가 틀렸을 때 덜 아프게 만드는 일이다.