철학 / 의사결정 프레임워크

접근법을 선택하는 방법

"Ranvier 방식"과 "생태계 방식" 사이에서 선택해야 할 때, 이 프레임워크를 사용하여 정보에 입각한 결정을 내리세요.

질문하기 (순서대로)

첫 번째 "예"가 접근법을 결정합니다:

1. 이것이 핵심 비즈니스 로직인가?
(검증, 계산, 오케스트레이션)
→ Ranvier 방식: 시각화, 조합, 테스트 용이성

2. Schematic 그래프에서 보아야 하는가?
(복잡한 흐름 디버그, 팀을 위한 문서화)
→ Ranvier 방식: Transition만 Circuit 뷰에 나타남

3. 이것이 순수한 인프라인가?
(CORS, TLS, rate limiting, circuit breaking)
→ 생태계 방식: 검증된 라이브러리(Tower) 재사용

4. 기존 코드베이스에서 마이그레이션 중인가?
(Tower 앱, actix 서비스)
→ 하이브리드: 생태계로 시작, 점진적으로 Ranvier 도입

5. 팀이 이미 도구 X를 알고 있는가?
(Tower, Axum, diesel)
→ 생태계 방식 → Ranvier: 기존 지식 사용, 나중에 Transition으로 래핑

의사결정 플로차트

시작
  │
  ├─ 핵심 비즈니스 로직? ───예──> Ranvier 방식 (Transition)
  │
  ├─ 시각화 필요? ────예──> Ranvier 방식
  │
  ├─ 순수 인프라? ───예──> 생태계 방식 (Tower/라이브러리)
  │
  ├─ 기존 것 마이그레이션? ────예──> 하이브리드 (Tower + Ranvier)
  │
  └─ 기본 ────────────────────> Ranvier 방식 (확신이 없을 때)

요약 표

도메인	Ranvier 방식	생태계 방식	하이브리드
비즈니스 로직	✅ 항상	❌ 절대	-
복잡한 인증	✅ 권장	⚠️ 가능	✅ 흔함
CORS	❌ 과함	✅ Tower 사용	-
데이터베이스	✅ Transition으로 래핑	⚠️ 직접 사용 OK	✅ 흔함
메트릭	⚠️ 수동	✅ Tower 사용	-
미들웨어	✅ 비즈니스 규칙용	✅ 인프라용	✅ 흔함

✅ 권장 | ⚠️ 허용 가능 | ❌ 안티패턴

언제 Ranvier를 사용해야 하는가?

새 프로젝트, 복잡한 워크플로우 → ✅ 순수 Ranvier (Transition)

새 프로젝트, 간단한 CRUD → ⚠️ Ranvier일 수도 (또는 더 간단한 프레임워크 OK)

기존 Tower 앱 → ✅ 하이브리드 (Tower 유지, 새 기능에 Ranvier 추가)

기존 actix/Axum 앱 → ✅ 핸들러에 Ranvier 임베드

마이크로서비스 오케스트레이션 → ✅ 오케스트레이터에 Ranvier

리프 CRUD 서비스 → ❌ 더 간단한 프레임워크 사용

CORS/기본 인증만 필요 → ❌ Tower/actix/Axum 미들웨어가 더 간단

다단계 상태 머신 → ✅ Ranvier의 강점

기본 권장사항: 확신이 없고 어떤 다단계 로직이 있다면 Ranvier를 사용하세요. 시각화만으로도 투자 가치가 있습니다.

상세한 시나리오, 코드 예제, 마이그레이션 경로는 PHILOSOPHY.md — 의사결정 프레임워크를 참조하세요.