STEP 01. AI 서비스 기획 기초 — 문제 정의부터 CRUD 설계까지

 

보통 사주보러가면 물어보는 것들이 있다. 올해 재물운이 어떻고 연애운이 어떻고

재회운이 어떻고 하는 그런 것들

사주명식에는 보통 그 사람이 타고난 행동 패턴이 들어있다.

어떤 방식으로 판단하고, 어디에서 에너지를 제일 많이 쓰고, 

어떤 환경에서 힘을 발휘하고, 대운이 바뀌면 그 패턴이 강해지기도, 눌리기도 한다.

사주를 보고 파악해야할 건 너는 원래 이런 사람이니 시기마다 전략적으로 움직여라를 알려주는 서비스다.

 

그런데 이걸 제대로 하려면 기존 AI사주 앱들의 방식으로는 안된다.

 

대부분의 AI사주앱은  이렇게 작동한다.

생년월일을 받아서 AI한테 넘기고, AI가 알아서 판단하고 해석까지 한다.

 

문제는 사주에는 만세력이라는 계산 체계가 있고, 신강신약이라는 판단기준이 있고, 

용신이라는 핵심 변수가 있다 이걸 AI가 혼자 처리하면 그럴듯해 보이지만 틀리는 경우가 많다.

타고난 특성을 정확하게 읽어내려면 이 판단 과정이 정밀해야하는데,

AI한테 전부 맡기면 같은 사주를 넣어도 매법ㄴ 다른 답이 나올 수 있다.

 

기획 단계에서 이 문제를 먼저 정의하지 않으면, 

아무리 UI를 예쁘게 만들어도 서비스의 핵심이 흔들린다.

AI서비스 기획의 첫번째 질문은 AI한테 뭘 맡기고 뭘 맡기지 않을 것인가다.

 

찐망고는 이 구조를 조금 바꿨는데

엔진이 먼저 판단하고, AI는 그 결과를 사람말로 번역만 한다. 

만세력 계산, 신강신약 분석, 용신도출까지 전부 서버에서 자체 로직으로 처리하고, 

그결과값을 AI한테 넘겨서 해석문을 생성하는 구조다. AI가 통역사인 셈이다.

 

이 구조를 택한 이유는 정확도 때문인데 AI한테 판단을 맡겼을 때 

같은 사주를 넣어도 매번 다른 답이 나올 수 있다.

하지만 엔진이 판단하면 같은 입력에는 항상 같은 형태의 분석이 나온다

AI는 읽기 좋게 풀어주기만 하면 된다.

 

서비스를 기획 할 때 이런 역할 분리를 먼저 정하면, 이후 기술 선택과 데이터 설계가 자연스럽게 따라온다.

반대로 이걸 정하지 않고 만들기 시작하면, 나중에 분명 구조를 뜯어고쳐야 하는 순간이 옴

 

서비스를 만들 때 제일 먼저 한건 뭘 저장할 것인가였다.

분석결과 본문, 사용자가 입력한 생년월일시에 관련된 사주명식, 

캐싱을 위한 키 값, 그리고 로그인연동 후 연결할 사용자의 ID, 사용자 정보는 jsonb형태로 저장했다.

현재 상황, 혼인여부, 자녀유무 등등으로 까지 포함하기 위해서다.

왜 현재 상황까지 받아야 하는지를 굳이 이야기해보자면

같은 사주라도 직장인과 사업자의 해석이 달라야 하기 때문이다.

기혼과 미혼의 관계운 해석도 같을 순 없다.

이 값들은 AI가 풀어줄때 맥락으로 주입된다.

캐시키는 이 모든 입력값의 조합으로 만든다.

같은 생년월일이라도 혼인 여부가 다르면 다른 결과가 나와야 하니까.

데이터 설계는 결국 이 서비스가 같다고 볼 것과 다르다고 볼 것의 기준을 정하는 작업이다.

 

사주 서비스라고 해도 결국 웹 서비스다.

데이터의 생성, 조회, 갱신, 삭제가 전부 일어난다. 

기획 단계에서 이 네가지 흐름을 먼저 그려보면, 서비스에 필요한 기능과 화면이 정리된다.

사용자가 생년월일시와 현재 상황을 입력하고 분석을 요청하면,

엔진이 돌아가고 그 결과가 DB에 저장된다. 이게 Create다 

마이페이지에서는 이전에 했던 분석 기록을 전부 다시 볼 수 있다.

로그인한 사용자의 ID로 필터링해서 최신순으로 정렬한다.

Kakao로그인을 연동한 이유도 여기에 있다. 비회원이면 기록을 묶어줄수가 없다.

이게 Read다.

Update는 조금 다르게 작동한다.

기존 기록을 수정하는게 아니라, 같은 명식이라도 현재 상황이 바뀌면 새로운 분석이 생성되는 구조다.

작년에 미혼직장인으로 분석했던 사람이 올해 기혼 사업자가 됐다면?

같은 사주여도 해석이 달라져야 한다. 

캐시키가 현재 상황까지 포함하는 이유가 이거다.

계정탈퇴를 누르면 사용자 데이터가 삭제된다.

Supabase의 sevice role key를 사용해서 서버사이드에서만 처리한다.

프론트엔드에서 직접 삭제 권한을 주면 보안 문제가 생기니까. 이게 Delete다.

어떤 서비스든 CRUD흐름을 먼저 그려보면 필요한 화면, 필요한 API, 

필요한권한 구조가 한번에 정리된다.

기획서를 쓰기전에 이 네글자를 먼저채워볼 것

 

사주 엔진 로직은 전부 서버에서만 돌아간다. 브라우저에는 계산 로직이 단 한줄도 보이지 않는다.

이건 일부러 그런거긴 한데

사주분석로직이 프론트에 노출되면 누구든 볼수도 있고 해서

API route안에서만 계산하고, 프론트엔드는 결과만 받아서 보여준다.

기획단계에서 이 서비스의 핵심 로직을 어디에 둘것인가를 정하는건

기술적판단이기도 하지만 사업적 판단이기도 한다.

 

이 서비스는 기획부터 런칭까지 3주이상 걸렸다.

재미나이를 주로 협업하면서 만들었고 기술 스택은 Next.js, Vercel, Supabase이다

런칭 후 DB에 250건 이상의 분석 기록이 쌓였고, 

피드백 40건 중 만족률은 92.5%였다.

유입경로는 거의 전부 카카오톡 공유, 광고비 0원에 CTR 44.7%

 

 

찐망고 사주풀이 | 달콤한 운명 리포트

 

 

기획이 끝나면 다음은 검증을 해봐야한다.

다음글에는 리뷰데이터를 AI로 마이닝하고, 사용자의 시선 흐름을 사전에 검증하는 과정을 다룬다.