[💬] 개인적으로 클로드하고 티키타카 할때 쓰는 프롬프트들

[익명(condemn3986)]

# 설계 원칙 — 상수 / 시뮬레이션 / UI 3층 분리

## 한 줄 요약

> **상수 데이터 + 시뮬레이션 모델만 읽으면 이 프로그램이 뭘 하는지 전부 알 수 있어야 한다.**

> UI 코드는 한 줄도 안 봐도 된다.

---

## 1. 세 개의 층

### 1-1. 상수 데이터 (Constant Data)

프로그램 실행 중 **절대 변하지 않는** 값.

규칙의 재료이며, 시뮬레이션이 참조만 한다.

- 템플릿, 스펙, 밸런스 테이블, 공식의 계수 등

- 런타임에 쓰기(write) 금지. 읽기(read) 전용

- 코드 안에 매직 넘버로 흩어지지 않고 한 곳에 모인다

- 이 층만 읽으면 **"이 세계에 어떤 것들이 존재하고, 각각의 수치가 얼마인지"** 알 수 있다

### 1-2. 시뮬레이션 모델 (Simulation Model)

하나의 독립적인 시뮬레이션의 **상태(state)** 와 **규칙(logic)**.

- 현재 상태를 나타내는 변수를 소유한다

- 상수 데이터를 참조해서 상태를 변이(mutate)하는 함수를 가진다

- UI를 모른다. 화면, 버튼, 애니메이션, 입력 장치의 존재를 전제하지 않는다

- 이 층은 **명령(command)을 받아서 상태를 바꾸고, 결과를 알린다**

- 상수 데이터 + 이 층만 읽으면 **"이 시뮬레이션이 어떤 순서로, 어떤 규칙에 따라 돌아가는지"** 전부 추적할 수 있다

### 1-3. UI (Presentation)

사용자에게 보여주고, 사용자의 입력을 받는 층.

- 시뮬레이션의 상태를 **읽어서 화면에 반영**한다

- 사용자의 조작을 **시뮬레이션의 명령으로 번역**해서 전달한다

- 자기 자신의 표시 상태(애니메이션 진행, 패널 열림/닫힘 등)는 자유롭게 가진다

- 시뮬레이션의 상태를 직접 변경하지 않는다

---

## 2. 층 사이의 규칙

### 의존 방향은 한쪽뿐이다

```

상수 데이터 ← 시뮬레이션 모델 ← UI

```

- 상수 데이터는 아무것도 모른다

- 시뮬레이션은 상수 데이터만 안다. UI를 모른다

- UI는 상수 데이터와 시뮬레이션 둘 다 안다

역방향 의존은 금지한다. 시뮬레이션이 "지금 어떤 화면이 열려 있는지" 알면 안 된다.

### 시뮬레이션은 스스로 완결된다

시뮬레이션의 상태 전이가 UI의 호출에 의존해선 안 된다.

- **위반 예시**: 카드를 사용한 뒤, UI가 "전투 끝났는지 확인해줘"를 호출해야만 종료 판정이 일어남

- **올바른 예시**: 카드 사용 함수 내부에서 종료 조건을 스스로 검사하고 결과를 알림

UI가 특정 순서로 특정 함수를 호출해줘야만 시뮬레이션이 올바르게 작동하는 구조는,

시뮬레이션의 규칙이 UI 코드에 유출된 것이다.

### 시뮬레이션의 상태에 UI 관심사를 넣지 않는다

- **위반 예시**: 시뮬레이션 상태에 `phase = "title"`, `phase = "map_screen"` 같은 화면 이름이 들어감

- **올바른 예시**: 시뮬레이션은 `state = "idle"`, `state = "in_combat"` 같은 게임 상태만 가지고, 어떤 화면을 보여줄지는 UI가 매핑함

판별 기준: **"이 상태값이 터미널(CLI) 환경에서도 의미가 있는가?"**

"title_screen"은 터미널에서 의미가 없다. "전투 중"은 터미널에서도 의미가 있다.

---

## 3. 독립적인 시뮬레이션의 경계

프로그램 안에 시뮬레이션이 여러 개 있을 수 있다.

각 시뮬레이션은 **서로 다른 관심사**를 다루며, 각자의 상태와 규칙을 독립적으로 가진다.

### 경계를 어떻게 나누는가

하나의 시뮬레이션이 다루는 범위는 **"하나의 규칙 체계 안에서 일어나는 상태 변화의 단위"** 이다.

예를 들어:

- 전투 한 판의 턴 진행, 카드 사용, 데미지 계산 → 하나의 시뮬레이션

- 런 전체의 노드 이동, 자원 관리, 전투 결과 반영 → 별개의 시뮬레이션

- 상점에서의 구매/판매 → 별개의 시뮬레이션

### 시뮬레이션 간 통신

- 시뮬레이션끼리 직접 상태를 읽거나 쓰지 않는다

- 한 시뮬레이션이 끝나면 **결과(result)** 를 반환한다

- 상위 시뮬레이션이 그 결과를 받아서 자기 상태에 반영한다

```

런 시뮬레이션 → 전투 시뮬레이션 시작(입력 전달)

전투 시뮬레이션 → 결과 반환 {승패, 잔여 HP, ...}

런 시뮬레이션 → 결과를 자기 상태에 반영

```

---

## 4. 검증 기준

원칙이 지켜지고 있는지 확인하는 자가 점검 항목.

### 읽기 테스트

상수 데이터 파일과 시뮬레이션 모델 파일만 열어서, 다음 질문에 전부 답할 수 있는가:

- 이 시뮬레이션에 어떤 상태가 있는가?

- 어떤 입력(명령)을 받을 수 있는가?

- 각 명령을 실행하면 상태가 어떻게 바뀌는가?

- 어떤 조건에서 시뮬레이션이 끝나는가?

하나라도 "UI 코드를 봐야 알 수 있다"면 위반이다.

### 교체 테스트

UI를 통째로 다른 것으로 교체해도 시뮬레이션이 정확히 동일하게 작동하는가?

예: GUI → 텍스트 CLI, 또는 GUI → 자동화 테스트 하네스

### 삭제 테스트

UI 파일을 전부 삭제했을 때, 시뮬레이션 모델에 컴파일 에러가 생기는가?

생긴다면 역방향 의존이 존재하는 것이다.

---

## 5. 허용 / 불허 경계선 정리

| 상황 | 허용 여부 |

|---|---|

| 시뮬레이션이 상수 데이터를 읽는다 | ✅ |

| UI가 시뮬레이션 상태를 읽는다 | ✅ |

| UI가 시뮬레이션에 명령을 보낸다 | ✅ |

| UI가 자체 표시 상태를 갖는다 (애니메이션, 패널 열림 등) | ✅ |

| 시뮬레이션이 자체 상태 변이 후 스스로 후속 판정을 한다 | ✅ |

| 시뮬레이션이 UI 함수를 호출한다 | ❌ |

| 시뮬레이션 상태에 화면/레이아웃 이름이 들어간다 | ❌ |

| UI가 시뮬레이션 상태를 직접 수정한다 | ❌ |

| 시뮬레이션의 규칙 일부가 UI 코드 안에만 존재한다 | ❌ |

| 시뮬레이션끼리 서로의 내부 상태를 직접 읽고 쓴다 | ❌ |

# 경계를 어디에 그을 것인가

> 자른 조각을 이어붙이기만 하면 원하는 것이 완성되도록 자르는 것. 그것이 설계다.

-----

## 전제: 데이터와 뷰는 나눈다

뷰는 데이터의 투영이다. 데이터가 완결되면 뷰를 붙이는 것은 어렵지 않다. 뷰에서 아키텍처가 무너지는 경우는 대부분 데이터가 완결되지 않아서 뷰가 로직을 떠안게 된 경우다. 이 분리는 상식이므로 더 이상 논하지 않는다.

-----

## 진짜 문제: 메인 모델의 소유권

데이터와 뷰를 나눈 후, 데이터 쪽 내부를 다시 자르는 것 — 여기서 설계 역량이 갈린다.

모든 시스템에는 메인 모델이 있다. 시스템 전체의 영속 상태를 들고 있는 하나의 데이터 구조다. 게임이면 런 상태, 웹이면 세션, 에디터라면 문서. 이 메인 모델이 데이터의 주인이다.

설계의 핵심 질문은 **"이 데이터를 누가 소유하는가"**이다. 답은 항상 메인 모델이어야 한다. 서브 시스템은 메인 모델의 데이터를 **빌려 쓰고 돌려주는** 함수다. 자기 소유의 영속 데이터를 갖지 않는다.

```

메인 모델 ──(데이터 전달)──→ 서브 시스템 ──(변환된 데이터 반환)──→ 메인 모델

```

서브 시스템은 실행 중에만 존재하는 임시 구조를 만들 수 있다. 하지만 끝나면 정리해서 메인 모델이 이해하는 형태로 돌려주고 사라진다.

-----

## 동기화는 경계 실패의 징후다

서브 시스템이 메인 모델과 같은 데이터의 사본을 들고 있으면, 동기화가 필요해진다. A를 고쳤는데 B도 고쳐야 하고, 그 순서가 중요하고, 빠뜨리면 불일치가 생긴다.

동기화가 필요한 순간, 경계가 잘못 그어진 것이다. 데이터의 소유권이 분산되어 있다는 뜻이기 때문이다.

해결은 소유권을 한 곳에 모으는 것이다. 메인 모델이 유일한 주인이고, 서브 시스템은 빌려 쓰기만 하면 동기화 자체가 존재하지 않는다. 동기화할 대상이 없으니까.

```

잘못된 구조:

메인 ←→ 서브A (deck 사본 보유)

메인 ←→ 서브B (deck 사본 보유)

→ A가 deck을 바꾸면 B의 deck도 맞춰야 한다

올바른 구조:

메인 (deck 소유)

서브A: f(deck) → deck' ← 빌려 쓰고 돌려줌

서브B: g(deck') → deck'' ← 이미 반영된 걸 받음

→ 동기화 없음

```

-----

## 서브 시스템의 복잡도가 경계를 정당화한다

서브 시스템이 별도 경계를 가질 자격이 있으려면, 내부에 자체적인 루프나 상태 전이가 있어야 한다. 단순한 변환 — 값을 받아서 계산하고 돌려주는 것 — 은 메인 모델 내부의 함수면 충분하다. 경계를 세우면 경계 유지 비용이 내용물보다 커진다.

기준: **서브 시스템 내부를 또 잘라야 할 만큼 복잡한가?** 그렇다면 경계가 정당하다. 아니라면 메인 모델의 함수로 남겨둔다.

-----

## 자르는 기준은 데이터 흐름이다

어떤 시스템이든 데이터가 들어오고, 변환되고, 나간다. 자르는 기준은 **데이터의 형태가 바뀌는 지점**이다.

```

버튼 눌림 → 이동 의도(방향+속도) → 물리적 위치 변화 → 렌더 커맨드

```

각 화살표가 데이터 형태의 전환이고, 그 전환점이 경계 후보다. "이 지점에서 자르면 양쪽이 서로의 내부를 몰라도 되는가?"가 판단 기준이다.

이동 의도 → 물리적 위치 변화에서 자르면, 이동 의도 모듈은 방향+속도를 내놓고 물리 모듈은 방향+속도를 받는다. 별도 변환 없이 꽂힌다. 그런데 만약 엉뚱한 데서 잘랐다면 — 예를 들어 키보드 입력과 마우스 입력 기준으로 나눴다면 — 양쪽 다 "이동 의도"를 각자 만들어야 하고, 합치는 변환이 생긴다.

잘 자른 조각은 A의 출력 형태가 B의 입력 형태와 이미 일치한다. 별도 변환 없이 꽂힌다.

"이게 현실에서 뭐처럼 생겼는지"가 아니라 "데이터가 여기서 끊기는지"가 기준이다. **"어디서 자르느냐"가 모듈성을 결정하는 것이지, 모듈화 기법을 적용한다고 모듈성이 생기는 게 아니다.**

-----

## DOD와 OOP는 대립이 아니다

흔한 오해: "데이터 지향이면 객체를 쓰면 안 된다." 아니다.

DOD가 말하는 건 "객체를 쓰지 마라"가 아니라 **"데이터가 어떻게 흐르고 변환되는지를 먼저 이해하라"**이다. 그건 칼질의 기준이지, 칼질의 결과물이 아니다. 결과물은 클래스일 수 있고, 모듈일 수 있고, 컴포넌트일 수 있다.

문제가 되는 건 OOP를 "현실 세계의 분류 체계"에서 시작하는 것이다. 가령 게임에 전사, 마법사, 궁수가 있으면 각각을 별도 클래스로 만들어야 할 것 같지만, 데이터 흐름을 보면 셋 다 (스탯, 장비, 스킬 목록)이라는 동일한 구조를 거쳐 같은 전투 파이프라인으로 들어간다. 나눌 이유가 없는 걸 나누면 캐릭터 타입마다 중복 로직이 생긴다. 반대로, 인벤토리와 장비 시스템은 겉보기에 "아이템"이라는 하나의 개념 같지만, 인벤토리는 소유와 수량의 데이터이고 장비는 슬롯 매핑과 스탯 변환의 데이터다. 흐름이 다르므로 나눠야 한다.

**객체를 나누는 기준은 데이터의 흐름이어야지, 개념의 분류가 아니다.** 단, 이런 판단은 탑다운 설계 단계에서 처음 나오는 것이 아니다. 데이터의 실제 형태와 연산을 바텀업으로 확인하는 과정에서 이미 논의되어야 할 일이다.

-----

## 패턴 템플릿으로 자르지 마라

디자인 패턴은 본질적으로 "이 모양으로 자르면 된다"는 기성 칼질 템플릿이다. 잘하는 사람일수록 패턴에 회의적인 이유가 여기에 있다.

숙련된 설계자는 문제의 데이터 흐름에서 경계를 발견한다. 패턴을 먼저 들고 오면 문제의 자연스러운 경계가 아니라 패턴의 경계에 맞추게 된다. 순서가 뒤집히는 것이다.

패턴을 아는 것과 적용하는 것은 다르다. 잘하는 사람은 패턴을 아주 잘 알면서도 안 쓴다. 모르니까 안 쓰는 게 아니라 알아서 안 쓰는 것이 숙련이다.

-----

## 경계가 작업 분배를 결정한다

경계가 잘 그어져 있으면 작업 분배는 자명하다. 각 조각이 서로의 내부를 몰라도 되므로, 조각 단위로 사람에게 넘기면 된다. 입력과 출력의 형태만 합의하면, 내부 구현은 각자 알아서 해도 결과물이 맞물린다.

**작업 분배는 설계의 결과물이지, 별도의 의사결정이 아니다.** 잘 자르면 자명하고, 못 자르면 가망없다.

-----

## 경계를 다시 긋는 타이밍

경계는 한 번 긋고 끝이 아니다. 구현 과정에서 틀렸음이 드러난다.

징후는 명확하다. 한 조각을 고쳤는데 다른 조각이 깨진다. 한 기능을 추가하려면 세 개의 모듈을 동시에 열어야 한다. 두 모듈 사이에 동기화 코드가 생겼다. 전부 경계가 데이터 흐름과 어긋나 있다는 신호다.

이때 해야 할 일은 우회 코드를 정교하게 만드는 게 아니라 경계를 옮기는 것이다. 경계를 다시 긋는 비용은 시간이 갈수록 올라간다. 그래서 징후가 보이는 즉시 움직여야 한다. 늦을수록 "차라리 새로 만들자"가 합리적인 선택이 되는데, 그건 설계를 다시 하겠다는 말이지 구현을 다시 하겠다는 말이 아니다.

-----

여기서부터는 체계화할 수 없다. 감각의 영역. 프레임은 여기까지다.

이렇게 2개 상단에 md 파일로 만들어 놓고 참고하라고 하고, 가끔 나건 게건 해깔려서 좀 찐빠난거 없나 살펴보기도 하고 함.

[레알팜(lottohelp)]