학파 설정이라는 차별화 — "같은 사주, 다른 해석"

 

"이 앱에서 본 사주랑 다른 앱에서 본 사주가 달라요." 사주 앱을 만들면 반드시 마주치는 질문이다. 같은 생년월일시를 입력했는데 결과가 다르다니, 사용자 입장에서는 당연히 의아하다. 이 문제를 숨기는 대신 정면으로 드러내기로 했다. 그것이 "학파 설정"이라는 기능의 출발점이었다.

왜 같은 생년월일시에도 다른 결과가 나오는가

사주명리는 수천 년의 역사를 가진 학문이다. 그 긴 시간 동안 다양한 학파와 유파가 생겨났고, 각 학파마다 계산 방식에 미묘한 차이가 있다. 핵심적인 차이점은 크게 네 가지다.

야자시(夜子時) 처리. 밤 11시에서 자정 사이에 태어난 사람의 일주를 어떻게 정할 것인가. 한 학파는 밤 11시가 지나면 다음 날로 본다. 다른 학파는 자정이 지나야 다음 날로 본다. 이 차이 하나로 일주 전체가 바뀌고, 당연히 십신 관계도 전부 달라진다.

진태양시(真太陽時) 적용. 시계로 보는 시간과 실제 태양의 위치에 따른 시간은 다르다. 서울과 부산의 경도가 다르니 같은 시각이라도 태양의 위치가 다르다. 진태양시를 적용하는 학파는 태어난 지역의 경도에 따라 시간을 보정한다. 적용하지 않는 학파는 표준시를 그대로 사용한다.

서머타임(일광절약시간) 보정. 한국은 과거 몇 차례 서머타임을 시행한 적이 있다. 1948~1961년, 그리고 1987~1988년. 이 기간에 태어난 사람의 시간을 1시간 빼야 하는지 말아야 하는지. 서머타임 보정을 적용하는 앱과 그렇지 않은 앱에서 결과가 갈린다.

12운성 음간 순역. 12운성을 계산할 때 양간은 순행, 음간은 역행한다는 것이 전통적인 방식이다. 하지만 일부 학파에서는 음간도 순행으로 계산한다. 이 차이로 12운성 결과가 크게 달라질 수 있다.

calculationSchool — 설정으로 풀다

대부분의 사주 앱은 이 중 하나의 방식을 선택해서 고정한다. 어떤 앱은 야자시를 적용하고, 어떤 앱은 적용하지 않는다. 사용자는 어느 쪽이 맞는지 판단할 수 없고, 결과가 다르면 어느 앱을 믿어야 하는지 혼란스러워한다.

다른 접근을 택했다. 사용자가 직접 선택하게 하는 것이다.

calculationSchool이라는 설정 객체를 만들었다. 이 객체에는 네 가지 옵션이 들어있다. 야자시 적용 여부, 진태양시 적용 여부, 서머타임 보정 여부, 12운성 음간 순역 방식. 사용자가 이 옵션들을 자유롭게 켜고 끄면, 같은 생년월일시라도 다른 결과를 확인할 수 있다.

이 설계의 핵심 철학은 "정답을 제시하는 것이 아니라 선택지를 제공하는 것"이다. 사주명리에서 이 옵션들 중 어느 것이 "정답"인지는 학파마다 의견이 다르다. 앱이 하나의 정답을 강제하는 것보다, 사용자가 자신이 신뢰하는 학파의 방식을 선택할 수 있게 하는 것이 더 정직한 접근이라고 판단했다.

CalculationSettings UI의 설계

기술적으로는 간단한 토글 몇 개지만, UI 설계에서는 고민이 많았다. 가장 큰 문제는 대부분의 사용자가 이 옵션들이 무엇을 의미하는지 모른다는 것이다.

첫 번째 원칙은 "기본값을 합리적으로 설정하는 것"이었다. 아무것도 건드리지 않아도 가장 보편적인 설정으로 결과가 나오도록 했다. 야자시 미적용, 진태양시 미적용, 서머타임 보정 적용, 12운성 전통 방식. 이것이 현재 한국에서 가장 널리 사용되는 조합이라고 판단한 기본값이다.

두 번째 원칙은 "각 옵션이 무엇인지 쉽게 설명하는 것"이었다. 야자시 옆에 물음표 아이콘을 두고, 터치하면 "밤 11시~12시에 태어난 분은 이 옵션에 따라 일주가 달라질 수 있습니다"라는 설명이 나오도록 했다. 진태양시도 마찬가지. "태어난 지역의 경도에 따라 시간을 보정합니다"라는 한 줄 설명.

세 번째 원칙은 "변경 시 즉각적인 피드백을 주는 것"이었다. 사용자가 야자시 옵션을 켜면, 사주 결과가 바뀌는지 안 바뀌는지를 즉시 보여준다. 밤 11시~12시 사이에 태어나지 않은 사람은 야자시 옵션을 바꿔도 결과가 같다. 그런 경우 "이 옵션은 현재 사주에 영향을 주지 않습니다"라는 메시지를 표시해 불필요한 혼란을 방지했다.

AppliedSettingsBadges — 투명성의 시각화

설정을 바꿀 수 있다는 것만으로는 부족했다. 현재 어떤 설정이 적용되어 있는지를 사주 분석 결과 화면에서 항상 보여줘야 했다. 그래서 만든 것이 AppliedSettingsBadges다.

사주 분석 결과 상단에 작은 배지들이 나열된다. "야자시: OFF", "진태양시: ON", "서머타임 보정: ON" 같은 식이다. 이 배지들을 보면 현재 결과가 어떤 설정 조합으로 계산된 것인지 한눈에 알 수 있다.

다른 사주 앱과 결과가 다를 때, 사용자는 이 배지를 보고 "아, 이 앱은 진태양시를 적용한 결과구나. 다른 앱은 적용하지 않았을 수 있겠다"라고 이해할 수 있다. 결과의 차이가 "오류"가 아니라 "설정의 차이"라는 것을 투명하게 보여주는 장치다.

이 배지 시스템은 사소해 보이지만 사용자 신뢰에 큰 영향을 미쳤다. 결과를 보여주면서 "이것은 이런 기준으로 계산한 것입니다"라고 명시하는 것 자체가 전문성과 정직함의 표현이다.

"같은 사주인데 왜 다른 결과?" 에 대한 답

학파 설정 기능은 단순한 기능 추가가 아니라, 사주 도메인의 근본적인 문제에 대한 앱 차원의 답이었다.

다른 앱들이 하나의 정답을 제시하고 "우리가 맞다"라고 주장할 때, 이 앱은 "사주명리에는 여러 학파가 있고, 각 학파의 계산 방식이 다릅니다. 여기서 당신이 선택하세요"라고 말한다. 이 접근은 두 가지 효과를 가진다.

하나는 신뢰 확보. 자기 방식만 옳다고 주장하는 것보다, 여러 방식이 존재함을 인정하고 선택지를 제공하는 것이 더 정직하다. 사용자들은 이 투명성을 긍정적으로 평가한다.

다른 하나는 학습 도구로서의 가치. 같은 사주에 야자시를 적용했을 때와 적용하지 않았을 때 결과가 어떻게 달라지는지를 직접 비교해볼 수 있다. 사주를 공부하는 사람에게 이보다 좋은 학습 도구가 있을까.

사주 앱에서 "명리학 학습 도구"로

학파 설정 기능을 넣으면서 프로젝트의 성격이 미묘하게 변했다. 단순히 사주를 봐주는 앱에서, 사주명리를 탐구할 수 있는 도구로. 사용자가 수동적으로 결과를 받아보는 것이 아니라, 능동적으로 설정을 바꿔보며 사주의 원리를 이해하게 되는 구조다.

이 변화는 타깃 사용자층에도 영향을 미쳤다. 처음에는 "내 사주가 궁금한 일반인"이 주요 타깃이었지만, 학파 설정이 추가되면서 "사주를 공부하는 학습자"도 의미 있는 사용자층으로 부상했다. 학습 도구로서의 포지셔닝은 차별화 측면에서 강력한 무기가 됐다.

정답이 여러 개인 도메인에서의 설계 철학

학파 설정 기능을 구현하면서 얻은 가장 큰 교훈은 이것이다. "정답이 여러 개인 도메인에서는 하나의 정답을 강제하는 것보다, 선택의 투명성을 제공하는 것이 더 나은 설계다."

이 원칙은 사주 앱에만 적용되는 것이 아니다. 의학, 법률, 요리, 교육 — 전문가들 사이에서도 의견이 나뉘는 도메인은 많다. 그런 도메인의 서비스를 설계할 때, "우리가 정답을 알고 있다"고 주장하는 것보다 "이런 선택지들이 있고, 각각의 근거는 이것입니다"라고 제시하는 것이 사용자에 대한 존중이다.

AI와 이 기능을 설계할 때도 비슷한 대화가 오갔다. "야자시를 적용하는 게 맞아, 안 하는 게 맞아?"라고 물었을 때 AI는 양쪽의 근거를 모두 설명하고, "사용자가 선택할 수 있게 하는 것이 가장 합리적"이라는 의견을 냈다. AI 역시 이 도메인에서 하나의 정답을 강제하지 않은 것이다. 이 태도가 학파 설정 기능의 설계 철학과 자연스럽게 연결됐다.

이 과정에서 배운 것

첫째, 도메인의 불확실성을 숨기지 말고 드러내는 것이 오히려 신뢰를 준다. 사주명리처럼 학파가 나뉘는 영역에서 "우리만 맞다"고 하면 전문가에게 공격받기 쉽다. 차이를 인정하고 투명하게 보여주는 것이 방어적이면서도 공격적인 전략이다.

둘째, 설정 기능은 기본값이 생명이다. 사용자의 90%는 설정을 건드리지 않는다. 기본값이 합리적이어야 대부분의 사용자가 좋은 경험을 한다. 나머지 10%의 파워 유저를 위해 커스터마이징이 존재하는 것이다.

셋째, 차별화는 기능의 양이 아니라 관점의 깊이에서 온다. 다른 사주 앱도 야자시나 진태양시를 처리한다. 하지만 그것을 사용자에게 "선택지"로 제공하고, "왜 다른지"를 설명해주는 앱은 드물다. 이 작은 관점의 차이가 앱의 정체성을 만들었다.

다음 편 예고

학파 설정까지 구현하면서 프로젝트의 기능적 완성도는 높아졌다. 그런데 이 모든 과정에서 가장 결정적인 역할을 한 것이 하나 있다. 바로 설계 문서다. 타로 프로젝트에서는 대화로 코드를 짰다면, 사주 프로젝트에서는 문서를 먼저 쓰고 코드를 짰다. 이 차이가 왜 게임 체인저였는지, 19편에서 다룬다.