[명경] Navid는 왜 실패했고 FateMirror는 어떻게 남았나

처음 만들고 싶었던 건 단순한 사주 결과 페이지가 아니었다. 사주, 동의보감, 별자리, 궁합, 주역을 한 번에 엮어 사용자의 상태와 방향을 종합적으로 보여주는 제품을 만들고 싶었다. 말로만 들으면 그럴듯했다. 한 사람을 한 가지 관점으로만 보지 않고 여러 층으로 읽어주는 개인 분석 도구처럼 보였기 때문이다. 같은 입력인데 어떤 환경에서만 명경가 도드라졌다. 그래서 용어 사전 대신, 그 날 무엇을 보고 무엇을 바꿨는지부터 적는다.

Navid가 막힌 지점

이전 질문은 “무엇까지 분석할 수 있을까”였다. FateMirror에서 질문은 바뀌었다. Navid를 다시 만든다면 기능 목록부터 쓰지 않을 것이다. 먼저 이런 질문을 적었을 것이다. 틀렸을 때도 문제였다. 어느 문장이 사주 계산에서 나온 것인지, 어느 문장이 주역적 해석인지, 어느 문장이 건강 암시에 가까운지 추적하기 어려웠다. 고칠 수도 없었다. 데이터가 섞이면 디버깅할 위치도 같이 사라진다. 1월부터 설계는 계속하고 있었다. 다만 초반 설계는 지금 보면 방향보다 욕심이 앞섰다. 무엇을 보여줄지보다 무엇까지 보여줄 수 있을지를 먼저 생각했다. 그래서 제품의 중심축이 자꾸 흔들렸다.

처음에는 기능이 답일 줄 알았다

Navid는 실패한 제품이었지만, 없어도 되는 실패는 아니었다. 무엇을 섞으면 안 되는지, 어떤 데이터부터 고정해야 하는지, 사용자가 읽는 문장과 내부 계산을 왜 분리해야 하는지 알려준 초기 작품이었다. 이 질문이 생긴 뒤에야 사주 데이터도 다르게 보였다. 더 많은 문장을 만드는 재료가 아니라, 사용자가 자기 패턴을 읽을 때 필요한 최소한의 구조로 봐야 했다.

결과는 예언처럼 닫히면 안 됐다. 사용자가 자기 경험과 비교하며 읽을 수 있어야 했다. 각 레이어가 어떤 입력을 받고, 어떤 근거로 판단하며, 최종 결과에서 어느 정도의 책임을 가져야 하는지 정리되지 않은 상태에서 기능을 얹었다. 그러자 분석이 깊어진 것이 아니라 모든 것이 섞였다. | 질문 | 확인하려는 것 | |---|---| | 이 레이어는 어떤 입력을 요구하는가? | 입력 계약 | | 이 레이어의 근거는 무엇인가? | provenance | | 다른 레이어와 충돌하면 무엇을 우선하는가? | 판단 우선순위 | | 사용자가 이 문장을 어떻게 받아들일 수 있는가? | 위험도 | | 틀렸을 때 어느 부분을 고칠 수 있는가? | 디버깅 가능성 | | 이 문장은 사용자의 선택권을 남기는가? | 제품 윤리 | FateMirror는 Navid에 뭔가를 더 붙여 만든 결과가 아니다.

오히려 반대다. 너무 많이 붙였던 것을 걷어내고, 사주 데이터 하나만 남긴 뒤 다시 잡은 좁은 시작점에 가깝다. 특히 명경에서는 재현 조건을 같이 적어야 의미가 있었다.

FateMirror로 남은 순간

| Navid가 남긴 것 | FateMirror에서 다시 쓴 방식 | |---|---| | 입력 → 결과 → 공유 흐름 | 사주 데이터 중심의 좁은 결과 흐름으로 유지 | | 카드형 결과 UI | 전문용어를 전면에 쌓지 않고 점진 공개 | | 위키/근거 설명 욕구 | 전면 결과와 분리된 신뢰 레이어로 이동 | | 종합 분석 실패 | 섞지 말아야 할 레이어 목록으로 전환 | | 긴 해석 문장 | 사용자가 비교하며 읽을 수 있는 관찰 문장으로 축소 | 사주가 가장 쉬워서가 아니었다. 최소한 사주는 붙잡을 수 있는 축이 있었다. 생년월일시, 절기, 간지, 오행, 십신, 대운처럼 입력과 계산, 검증해야 할 경계가 비교적 분명했다. 먼저 하나의 축을 세우지 못하면 다른 레이어를 얹어도 다시 무너질 수밖에 없었다. | 레이어 | 기대했던 역할 | 실제 문제 | |---|---|---| | 사주 | 생년월일시 기반 기질과 흐름 | 계산 경계만으로도 충분히 복잡했다 | | 동의보감식 해석 | 몸과 생활 리듬에 대한 힌트 | 건강/의학 뉘앙스가 생겨 책임 범위가 커졌다 | | 별자리 | 다른 시간 기반 성향 해석 | 사주와 상징 체계가 달라 근거가 섞였다 | | 궁합 | 관계 분석 | 두 사람의 데이터와 관계 맥락이 필요했다 | | 주역 | 질문과 변화의 해석 | 질문 중심 구조라 생년월일시 결과와 충돌했다 | 사주를 가지고 사람을 단정할 것인가. 아니면 사용자가 자기 삶을 다시 읽을 수 있게 비춰줄 것인가. 사주는 생년월일시, 성별, 출생지, 역법 같은 입력을 요구한다. 궁합은 두 사람의 정보가 필요하다. 주역은 사용자가 던진 질문과 그 질문이 놓인 상황이 중요하다. 동의보감식 해석은 몸 상태나 생활 습관 없이 말하면 위험하다. 별자리는 또 다른 시간 체계와 상징 체계를 쓴다. FateMirror는 기능을 확장해서 나온 제품이 아니다. 책임질 수 없는 해석을 덜어내면서 나온 제품이다. 사용자에게 보이는 문장과 내부 상태 이름을 분리해 두니 논의가 빨라졌다. 명경를 설명할 때 서버/클라이언트/사용자 중 누구 문장으로 말하는지 먼저 고르면 논쟁이 줄었다.

실패와 남음 경계 나누기

처음에는 이 표를 이렇게 보지 못했다. 각각이 흥미로운 재료였고, 잘 엮으면 더 풍부한 결과가 될 거라고 봤다. 하지만 많은 관점을 모으는 일과 많은 관점을 한 데이터 구조 안에 밀어 넣는 일은 전혀 달랐다. 해석형 제품은 많이 말할수록 좋아지는 제품이 아니다. 특히 사주처럼 사람의 성향, 관계, 흐름을 다루는 도메인에서는 더 그렇다.

그럴듯한 문장이 많아질수록 사용자는 결과에 끌려갈 수 있다. 제품은 그 힘을 조심해야 한다. 가장 먼저 남은 것은 흐름이었다. 사용자가 생년월일시를 넣고, 결과를 읽고, 저장하거나 공유하고, 모르는 개념은 위키처럼 따라가며 확인하는 흐름은 계속 유효했다. 문제는 그 흐름 안에 너무 많은 해석 체계를 동시에 넣었다는 데 있었다.

그래서 이름도 중요했다. 운명을 맞히는 도구처럼 보이면 안 됐다. 사용자가 결과를 수동적으로 받아들이는 제품이 아니라, 자기 기질과 흐름을 비춰보는 인터페이스여야 했다. 그래서 명경, FateMirror라는 이름이 맞았다. 맞힌다는 느낌보다 비춘다는 느낌이 필요했다.

구현과 운영에 남긴 조건

| 걷어낸 것 | 남긴 판단 | |---|---| | 동의보감식 건강 해석 | 건강 암시는 입력과 책임 범위가 더 필요하다 | | 별자리 | 다른 상징 체계는 별도 제품이나 별도 레이어로 분리해야 한다 | | 궁합 | 관계 분석은 단일 사용자 결과와 다른 입력 계약이 필요하다 | | 주역 | 질문 중심 해석은 생년월일시 기반 결과와 분리해야 한다 | | 종합 분석 톤 | 한 제품은 먼저 하나의 책임 있는 축을 가져야 한다 | 동의보감식 건강 해석을 뺐다. 별자리도 뺐다. 궁합도 분리했다. 주역도 전면 결과에서 걷어냈다. 처음에는 아까웠다. 각각은 독립된 제품이나 별도 레이어로 다룰 수 있는 재료였다. 하지만 첫 제품의 한 결과 안에서 함께 책임질 수 있는 재료는 아니었다. 특히 명경에서는 재현 조건을 같이 적어야 의미가 있었다. 그래서 Navid는 폐기물이 아니었다. 제품으로는 실패했지만, 다음 설계의 바닥선을 그었다. 특히 명경에서는 재현 조건을 같이 적어야 의미가 있었다. | Navid 초기 실험 | FateMirror 방향 | |---|---| | 여러 해석 체계를 종합 | 사주 데이터 중심 | | 결과를 많이 제공 | 책임질 수 있는 문장만 제공 | | 도메인 레이어 혼합 | 계산, 해석, 표현 경계 분리 | | 점술/운세처럼 보일 위험 | 거울/자기이해 프레임 | | 근거가 뒤섞임 | 입력과 계산 근거를 먼저 고정 | | 확장 욕심 | 삭제와 경계 설정 우선 |

실패했다고 해서 전부 버릴 수 있는 건 아니었다. Navid는 제품으로 실패했지만, 다음 제품을 만들 때 필요한 뼈대를 남겼다. '[명경 Navid는 왜 실패했고 FateMirror는 어떻게 남았나'을 관통하는 질문은 이 섹션에서도 같았고, 답만 더 구체적이 됐다. ## 롤백을 남긴 이유 — Navid는

입력은 생년월일시와 질문으로 좁히고, 계산은 사주 데이터에 집중하고, 결과는 카드와 해석 흐름으로 정리했다. 위키와 근거 설명은 전면 결과를 무겁게 만드는 대신, 필요할 때 더 깊게 들어가는 레이어로 두기 시작했다. 내부 계산과 사용자가 읽는 문장을 분리해야 한다는 판단도 이때부터 선명해졌다. 두 번째로 남은 것은 화면의 감각이었다.

긴 문장 하나로 모든 것을 말하기보다 카드, 상세 설명, 더 깊이 보기 같은 층을 나눠야 한다는 판단은 Navid에서 나왔다. 전면에는 사용자가 바로 읽을 수 있는 문장을 두고, 복잡한 근거는 뒤쪽으로 보내야 했다. 초기 Navid의 욕심은 컸다. 사주만 계산해서 보여주는 도구로 끝내고 싶지 않았다. 태어난 시간의 기질, 몸의 리듬, 관계, 질문에 대한 변화의 방향까지 한 화면에서 이어지면 더 입체적인 결과가 나올 거라고 생각했다.

특히 명경에서는 재현 조건을 같이 적어야 의미가 있었다. 그런데 Navid에서는 이 차이가 충분히 분리되지 않았다. 서로 다른 입력 계약을 가진 레이어들이 하나의 종합 결과 안으로 들어왔다. 결과 페이지는 풍부해진 것이 아니라 불명확해졌다. 사용자는 여러 관점을 받는 것이 아니라 서로 다른 문법의 문장들이 한 페이지에 붙어 있는 결과를 받게 됐다.

그 실패가 없었다면 계속 여러 해석 체계를 한 화면에 쌓으려 했을 것이다. 더 많은 레이어, 더 긴 결과, 더 그럴듯한 문장을 만들었을 가능성이 크다. 하지만 해석형 제품에서 중요한 것은 많이 말하는 능력이 아니었다. 어떤 데이터를 믿고, 어떤 문장을 하지 않을지 정하는 능력이 먼저였다. 특히 명경에서는 재현 조건을 같이 적어야 의미가 있었다.

다만 그 실패 덕분에 FateMirror는 처음부터 하나의 질문을 붙잡고 시작할 수 있었다. 특히 명경에서는 재현 조건을 같이 적어야 의미가 있었다.

마치며

FateMirror에서 바뀐 것은 기능 수가 아니라 판단 순서였다. 예전에는 만들 수 있는 해석을 먼저 떠올렸다. FateMirror에서는 사용자가 안전하게 읽을 수 있는 경계를 먼저 잡았다. FateMirror 시리즈의 첫 글이다. 다음 글에서는 사주 하나만 남긴 뒤에도 왜 절기, 자시, 윤달, timezone, provider 검증이 계속 문제가 됐는지 정리할 예정이다. 특히 명경에서는 재현 조건을 같이 적어야 의미가 있었다. 세 번째로 남은 것은 실패의 목록이었다. 어떤 레이어를 섞으면 결과가 흐려지는지, 어떤 문장이 사용자를 불안하게 만드는지, 어떤 데이터가 없으면 결과를 책임질 수 없는지 Navid가 먼저 보여줬다. 이 목록은 그대로 FateMirror의 금지선이 됐다.