감정을 변수로 옮기다 — 3계층 감정 모델

- 4월 09, 2026

이제 본격적으로 감정을 설계할 차례다. 호감도+1의 한계를 파악했으니, 그걸 대체할 시스템을 만들어야 한다. AI에게 말했다. "호감도 하나가 아니라, 사람의 감정을 좀 더 현실적으로 표현할 수 있는 변수 시스템을 만들고 싶어."

그리고 여기서부터 AI가 본격적으로 힘을 발휘하기 시작했다. 감정을 구조화하는 작업, 즉 추상적인 것을 변수와 계층으로 분해하는 작업은 AI가 잘하는 영역이다.

감정은 몇 개가 필요한가

첫 번째 질문이 이거였다. "감정 변수를 몇 개 두면 될까?"

AI의 답은 의외로 신중했다. "많으면 많을수록 좋은 게 아니다. 변수가 많아지면 오버엔지니어링이 된다." 그리고 핵심적인 구분을 제안했다.

표현해야 하는 감정의 종류는 많아도 된다. 하지만 시스템이 직접 추적하는 상태값은 구조적으로 정리되어야 한다.

무슨 뜻인가. 사랑, 슬픔, 분노, 자만, 시기, 질투, 믿음, 신뢰, 긴장, 갈등, 두려움, 공포, 선망. 이런 감정을 전부 독립 변수로 나열할 수는 있다. 하지만 그러면 상호작용 규칙이 폭증한다. 어떤 이벤트가 뭘 얼마나 바꾸는가, 사랑과 신뢰가 동시에 오를 수 있는가, 시기와 선망의 차이는 어떤 조건에서 갈라지는가. 정의 없이 변수만 많으면 게임이 더 가짜가 된다.

그래서 AI가 제안한 건 감정을 레이어로 나누는 것이었다.

3계층 모델

AI와 반복적으로 대화하면서 정리된 구조가 이거다.

A층: 근본 성향 / 욕구 — 캐릭터의 고유값. 쉽게 안 바뀐다. 게임 시작 시 설정되고, 플레이 중에는 거의 변하지 않는다.

애정 욕구 (need_for_affection)
거절 공포 (fear_of_rejection)
자존심 (pride)
불안정감 (insecurity)

이건 캐릭터의 "성격"이다. 왜 이 사람이 이런 행동을 하는지의 근본 이유.

B층: 현재 감정 상태 — 장면이나 사건에 반응해서 흔들린다. 순간적이고 유동적이다.

애정 (affection)
분노 (anger)
슬픔 (sadness)
질투 (jealousy)
선망 (admiration)
두려움 (fear)

이건 "지금 이 순간" 캐릭터가 느끼는 것. 장면마다 바뀔 수 있다.

C층: 관계 상태 — 상대와 축적된 결과. 비교적 천천히 바뀐다.

신뢰 (trust)
의존 (reliance)
친밀감 (intimacy)
긴장 (tension)
원한 (resentment)
존경 (respect)

이건 "지금까지 쌓인 관계의 상태". 한 번의 이벤트로 크게 바뀌지 않는다.

왜 3개로 나누는가

이 분리가 중요한 이유를 AI가 예시로 설명했다.

"질투가 높고 신뢰도 높은 상태"가 가능해진다. 좋아하고 믿지만 질투할 수 있으니까. 이건 현실적이다. 호감도 시스템에서는 이게 불가능하다. 질투가 올라가면 호감도가 내려가는 식으로밖에 표현 못 하니까.

또 다른 예시. "애정은 높은데 신뢰가 낮은 상태". 끌리지만 못 믿는 관계. "신뢰는 높은데 애정이 낮은 상태". 소중하지만 연애는 아닌 관계. 단일 수치에서는 이 차이가 보이지 않지만, 3계층에서는 자연스럽게 표현된다.

그리고 가장 중요한 것. 사랑은 어디에도 없다. 사랑이라는 변수는 시스템에 존재하지 않는다. 대신 사랑은 C층 변수들의 조합으로 "발생"한다.

신뢰 >= 70
친밀감 >= 60
상실 공포 >= 30
상대를 반복적으로 우선 선택 >= 5회

이 조건이 충족됐을 때, 플레이어가 "이건 사랑이다"라고 느끼게 만드는 거다. love += 1이 아니라, 조건의 결과로 사랑이 나타나게 하는 설계.

각 감정에 정의가 필요하다

AI가 강하게 주장한 것 중 하나가 이거다. "변수를 만들었으면 반드시 정의서를 작성해라."

belief: 상대 말이 사실일 거라고 여기는 정도
trust: 상대에게 자신을 맡길 수 있는 정도
envy: 상대가 가진 것을 부러워함
jealousy: 상대가 타인에게 빼앗길까 불안해함
tension: 아직 터지지 않은 불편함
conflict: 이미 표면화된 충돌
fear: 회피/위축을 낳는 불안
admiration: 닮고 싶거나 우러러보는 감정

이 정의가 없으면 작가, 기획, 코드가 다 따로 놀게 된다. "신뢰가 올라간다"는 말이 사람마다 다른 의미를 갖게 되면 시스템이 일관성을 잃는다.

이건 개발자 경험이 있어서 바로 와닿았다. 코드에서 변수 이름을 모호하게 지으면 나중에 혼란이 오는 것과 같은 문제다. 감정 변수도 마찬가지. 이름만 있으면 안 되고, 정의가 있어야 한다.

이벤트 반응 함수

변수를 나열하는 건 시작에 불과하다. 진짜 중요한 건 "어떤 이벤트가 어떤 변수를 얼마나 바꾸는가"이다.

AI가 제안한 구조가 이거다. 변화 규칙을 직접 다 쓰지 말고, 이벤트 타입별로 템플릿화하라.

def apply_reaction(kind):
    if kind == "kept_promise":
        em["trust"] += 8
        em["belief"] += 5
        em["affection"] += 3

    elif kind == "public_humiliation":
        em["anger"] += 10
        em["sadness"] += 6
        em["trust"] -= 7
        em["conflict"] += 8

    elif kind == "saw_with_rival":
        em["jealousy"] += 9
        em["fear"] += 4
        em["affection"] += 2

"약속을 지켰다"는 이벤트가 신뢰를 8, 믿음을 5, 애정을 3 올린다. "공개적으로 창피를 줬다"는 이벤트가 분노를 10 올리고 신뢰를 7 내린다. 이렇게 이벤트 단위로 감정 변화를 정의하면 관리가 된다.

그리고 여기서 한 가지 더. 모든 감정을 매 장면 계산하지 말고, "활성 감정"만 꺼내 써야 한다. 시스템에 20개 감정이 있어도, 어떤 장면에서 실제로 쓰는 건 2~4개면 된다.

재회 장면: 그리움, 경계, 신뢰
배신 장면: 분노, 슬픔, 갈등
라이벌 등장: 질투, 선망, 불안

이렇게 장면별 활성 감정을 제한하면, 깊이는 유지되고 복잡도는 통제된다.

이 설계가 가능한 이유

솔직히, 이 정도 복잡도의 시스템을 혼자 설계했으면 중간에 포기했을 거다. 변수 간의 관계를 정의하고, 이벤트별 변화량을 조정하고, 테스트 케이스를 만드는 작업이 방대하다.

AI가 있으니까 가능하다. 변수 구조를 제안하고, 정의서를 작성하고, 이벤트 반응 함수의 초안을 만들고, 균형이 맞는지 시뮬레이션하는 일. 이런 반복적이고 구조적인 작업에서 AI는 빠르고 정확하다.

물론 최종 판단은 사람이 해야 한다. "약속을 지켰을 때 신뢰가 8 오르는 게 맞나? 5가 더 적절하지 않나?" 이런 감각적 조정은 AI가 해줄 수 없다. 하지만 초안을 빠르게 만들고, 수정 사항을 즉시 반영하는 건 AI의 강점이다.

다음 편에서는 이 3계층 모델의 핵심을 더 깊이 파고든다. 사랑을 직접 올리지 않는 설계.

다음 편: 사랑을 직접 올리지 않는 설계 — 사랑은 누적 해석의 결과다

이 블로그 검색

goldtag