사랑을 직접 올리지 않는 설계

- 4월 09, 2026

이전 편에서 3계층 감정 모델을 설계했다. 그 중 가장 중요한 원칙이 하나 있다. 사랑이라는 변수는 시스템에 존재하지 않는다.

love += 1은 없다. 대신 사랑은 다른 변수들의 조합에서 "발생"한다. 이게 이 시스템의 핵심이고, 기존 호감도 시스템과의 가장 큰 차이다.

왜 사랑을 직접 변수로 두면 안 되는가

AI와 이 주제로 대화했을 때, AI가 흥미로운 관점을 제시했다.

"사랑은 다른 감정과 같은 급이 아니다."

슬픔, 분노, 질투, 두려움. 이것들은 단발적 감정이다. 특정 사건에 반응해서 올라가거나 내려간다. 하지만 사랑은 다르다. 사랑은 보통 단발 감정보다 누적된 관계 해석의 결과에 가깝다.

신뢰가 높다. 의존이 있다. 친밀감이 쌓였다. 질투도 약간 있다. 상실 공포가 있다. 상대를 반복적으로 우선 선택한다. 이 조합을 플레이어가 "사랑"으로 읽는 거다.

시스템적으로 이걸 표현하면 이렇다.

love_state = (
    trust >= 70 and
    intimacy >= 60 and
    fear_of_loss >= 30 and
    chosen_priority >= 5
)

love를 직접 올리는 게 아니라, 사랑이 발생하는 조건을 설계하는 것이다. 이 차이가 크다.

왜 이 방식이 더 자연스러운가

현실을 생각해보자. 누군가를 사랑하게 되는 순간을 정확히 짚을 수 있는 사람이 있는가? 대부분은 없다. 어느 날 문득 "아, 내가 이 사람을 좋아하는구나"를 깨닫는 거다. 사랑은 시작 버튼을 누르는 게 아니라, 이미 쌓여 있던 것을 인식하는 거다.

love += 1 시스템에서는 이 경험을 재현할 수 없다. 선택할 때마다 사랑이 올라가니까, 플레이어는 "지금 사랑이 몇 점쯤 되겠지"를 계산하게 된다. 감정이 아니라 점수 관리가 된다.

조건 조합형에서는 다르다. 플레이어는 사랑 수치를 모른다. 사랑이라는 변수 자체가 없으니까. 대신 "이 캐릭터를 신뢰하게 됐다", "함께 있는 시간이 편해졌다", "이 사람이 없어지면 싫겠다" 같은 감각들이 따로따로 쌓인다. 그리고 어느 순간, 이야기가 그 조합을 "사랑"이라고 보여준다.

이게 현실의 경험과 훨씬 가깝다.

AI에게 "사랑에 빠지는 과정을 시스템적으로 표현해봐"라고 했을 때, AI가 이런 시퀀스를 보여줬다. 처음에는 호기심(curiosity)만 있다. 시간이 지나면서 편안함(comfort)이 쌓인다. 어느 순간 상대가 없는 상태가 불편해진다(fear_of_loss 상승). 그리고 상대를 위해 자기 것을 양보하는 선택을 반복한다(chosen_priority 누적). 이 과정의 어느 지점에서 "아, 이건 사랑이구나"를 깨닫게 되는 거다. 한 번의 이벤트가 아니라, 누적의 결과로.

이걸 코드가 아니라 이야기로 번역하는 게 시나리오 작가의 일이다.

조합이 만드는 다양한 관계

이 설계의 또 다른 강점은, 같은 "좋아함"도 다르게 나온다는 거다.

끌리지만 못 믿는 관계 — affection 높음, trust 낮음. 함께 있으면 설레지만, 결정적인 순간에 의지할 수 없다.

소중하지만 연애는 아닌 관계 — trust 높음, affection 낮음. 어떤 일이 있어도 이 사람은 변하지 않을 거라는 확신. 하지만 가슴이 뛰지는 않는다.

강하게 끌리지만 위험한 관계 — affection 높음, tension 높음. 열정적이지만 갈등도 크다. 함께 있으면 강렬하지만 안정적이지 않다.

잃고 싶지 않은 소중한 존재 — respect 높음, fear_of_loss 높음. 연애인지 우정인지 경계가 모호하다. 하지만 이 사람이 없어지는 건 상상할 수 없다.

호감도 시스템에서는 이 네 가지가 전부 "호감도 70"으로 같다. 3계층 시스템에서는 전부 다른 관계다. 그리고 이 다른 관계들이 다른 이야기를 만들고, 다른 감정을 만든다.

상태 전이: 감정의 흐름

AI가 제안한 중요한 개념이 하나 더 있다. 수치보다 상태 전이를 먼저 만들라.

감정 변수의 숫자가 중요한 게 아니라, 관계가 어떤 상태에서 어떤 상태로 이동하는가가 중요하다.

긍정적 전이:
경계 → 호기심 → 안도 → 신뢰 → 의존 → 애착 → 사랑

부정적 전이:
경계 → 흥미 → 기대 → 실망 → 분노 → 갈등 → 단절

같은 출발점에서 시작해도, 어떤 이벤트를 겪느냐에 따라 경로가 갈라진다. 이 전이 흐름을 먼저 설계하고, 그 다음에 "어떤 변수 조합이 어떤 상태에 해당하는가"를 정의하는 게 순서다.

이건 상태 기계(State Machine) 패턴과 비슷하다. 개발자에게는 익숙한 개념이다. 감정을 상태 기계로 관리한다는 발상이 처음에는 기계적으로 느껴졌지만, 생각해보면 이야기의 흐름 자체가 상태 전이의 연속이다. 관계가 깊어지는 건 상태가 전이되는 거고, 관계가 망가지는 것도 상태가 전이되는 거다.

사랑의 다양한 형태

이 시스템에서는 사랑도 단일하지 않다. 조건 조합에 따라 다른 종류의 사랑이 나온다.

신뢰 기반 사랑 — trust와 intimacy가 높고, fear_of_loss는 낮음. 안정적이고 편안한 사랑. 드라마틱하지 않지만 단단하다.

불안 기반 사랑 — affection과 fear_of_loss가 높고, trust는 낮음. 강렬하지만 불안한 사랑. 집착에 가까울 수 있다.

존경 기반 사랑 — respect과 admiration이 높고, intimacy는 중간. 우러러보는 감정에서 시작된 사랑. 대등한 관계로 가기 어려울 수 있다.

갈등 속 사랑 — affection과 tension이 동시에 높음. 좋아하는데 맞지 않는 관계. 화해와 충돌을 반복한다.

이 각각이 다른 이야기를 만들고, 다른 엔딩으로 이어진다. "사랑했는데 왜 안 됐는가"에 대한 답이 달라진다. 하나는 불안 때문에, 하나는 존경이 대등함을 방해해서, 하나는 갈등이 신뢰를 먹어치워서.

AI와의 협업 지점

이 설계에서 AI가 특히 유용했던 건 세 가지다.

첫째, 변수 간 관계의 일관성 검증. "이 이벤트에서 신뢰가 올라가면 긴장은 어떻게 돼야 해?" 같은 질문에 AI가 논리적으로 답해준다. 사람은 직감으로 잡지만, 빠뜨리는 게 생긴다. AI는 빠뜨리지 않는다.

둘째, 조합의 경우의 수 시뮬레이션. 변수 6개가 각각 0~100 범위라면 조합은 사실상 무한하다. AI에게 "이 변수 조합이면 어떤 관계 상태야?"를 물으면, 현실적인 해석을 내놓는다.

셋째, 정의서 작성. 각 변수의 의미, 변화 규칙, 상호작용을 문서화하는 작업이 방대한데, AI가 초안을 빠르게 작성해준다.

사람이 해야 할 건 이거다. "이 관계가 진짜 그런 느낌인가?" 시스템이 출력하는 결과가 감정적으로 납득이 되는지를 판단하는 일. 이건 AI가 해줄 수 없다. 숫자가 아무리 맞아도, 느낌이 틀리면 의미가 없다. 감정 시스템의 최종 검증은 항상 사람의 감각이어야 한다.

다음 편에서는 이 감정 시스템의 세 번째 요소를 다룬다. 장면이 감정을 밀어올리는 구조. 같은 대사도 상황에 따라 완전히 다른 의미를 갖는 컨텍스트 시스템.

다음 편: 장면이 감정을 밀어올린다 — 컨텍스트 시스템 설계

이 블로그 검색

goldtag