바이브 모델링 및 소프트웨어 제조 공정 가이드라인

바이브 모델링은 설계자의 직관적인 의도(Vibe)를 AI에게 정확히 전달하여 도메인의 핵심 구조를 설계하고, 이를 5단계의 정교한 공정을 통해 실제 코드로 변환하는 AI 협업 설계 방법론입니다.

1단계: Vibe Sync (컨텍스트 동기화) 설계의 목적과 시스템의 페르소나를 정의합니다.
- 목적: AI가 보편적인 데이터(Default)로 오해하지 않도록 도메인의 경계를 명확히 설정합니다.
- 예시: 식당용 주문 시스템이 아닌, 백오피스 운영자용 메뉴 권한 관리 시스템임을 명시합니다.
2단계: Dynamic Skeleton (동적 뼈대 구축) 정적 구조를 설계하기 전, 유스케이스 중심의 액티비티를 설계합니다.
- 목적: 데이터의 저장 구조보다 데이터의 흐름과 변화를 우선시하여 비즈니스 로직의 누락을 방지합니다.
- 방법: 단일 유스케이스 단위로 액티비티(Flow)를 도출하며, 한 번에 여러 흐름을 섞지 않습니다.
3단계: Vibe Iteration (의도 디버깅 및 구체화) 액티비티를 지탱할 모델의 속성과 책임을 정의합니다.
- 목적: AI가 테이블 설계에 매몰되는 것을 방지하고, 모델이 스스로 비즈니스 규칙을 판단하는 풍부한 도메인 모델(Rich Domain Model)을 만듭니다.
- 방법: 액티비티와 모델을 연결하여, 각 모델이 특정 행위를 수행하기 위해 필요한 정보와 규칙을 할당합니다.

바이브 모델링의 결과물은 아래의 패키지 구조와 노출 규칙(Visibility)에 따라 물리적 코드로 안착됩니다.

단계	패키지(Package)	역할 및 구성 요소	노출 여부 (Visibility)
1단계	application	유스케이스 인터페이스, 도메인 이벤트	선택적 노출 (NamedInterface)
2단계	model	엔티티(Aggregate Root), 도메인 로직	내부 전용 (Internal)
3단계	port	Repository 및 외부 연동 인터페이스	혼합 구성 (Port/Contract)
4단계	infra	포트 구현체(Adapter), DB 세부 설정	내부 전용 (Internal)
5단계	api	컨트롤러(Controller), 웹 진입점	내부 전용 (Internal)

전처리 우선의 법칙
- 바이브 코딩(구현)에 진입하기 전, 반드시 1~3단계의 바이브 모델링을 통해 AI와 의도를 동기화해야 합니다
행위 중심 설계
- 모델은 항상 액티비티를 지원하기 위해 존재해야 하며, 단순한 데이터 저장소(Entity)로 전락하지 않도록 감시합니다.
객체 지향 매핑 원칙
- Aggregate Root와 Entity는 가변 상태와 복잡한 행위를 담기 위해 class로 구현합니다.
- 식별자가 없는 값 객체(Value Object)는 불변성 보장을 위해 record로 구현합니다.
- 액티비티는 흐름을 제어하는 Service Interface로 도출합니다.
설계 보호 및 격리
- model(2단계)과 infra(4단계)는 철저히 내부(Internal)로 격리하여 외부 모듈의 접근을 차단합니다.
- 모듈 간의 소통은 오직 application(1단계)의 인터페이스와 이벤트를 통해서만 이루어져야 합니다.
알고리즘 설계의 예외성
- 정밀한 수치 계산이나 복잡한 논리 구조가 필요한 알고리즘 영역은 바이브 모델링 대신 의사코드(Pseudocode)와 제약 조건을 명시하는 포멀 설계 방식을 적용합니다.

이 공정을 준수함으로써 설계자는 AI와의 대화에서 주도권을 유지하고, 프롬프트 지옥에서 벗어나 비즈니스 가치에 집중할 수 있습니다. 결과적으로 변경에 유연하고 내부 응집도가 높은 고품질의 Modulith 시스템을 빠르게 구축할 수 있습니다.

코딩하는오후