사이버네틱스
경력근거: 타이트사주의 신규 기능 개발 및 운영 - 웹 및 모바일 앱 서비스 개발 - AI 기능을 활용한 신규 사용자 경험 설계
※ 실제 산출물이 아닌 AI 예측 시안입니다.
'사람들은 정답보다 나를 이해할 수 있는 언어를 원한다' 는 공고 문장이 이 도구의 출력 형태(계산값을 언어로 바꾸는 카드)를 그대로 정의합니다. 사주를 하나의 프레임으로 활용해 사주 2.0 을 만든다는 방향에서, 계산(프레임)과 해석(언어)을 분리한 구조가 타이트사주의 신규 기능 축과 맞닿습니다. 이 포트폴리오가 보여주는 것은 결정론 규칙 엔진 설계와 LLM 문구 생성의 분리 구현이며, 명리 상담 전문성은 주장하지 않습니다. 간지 계산 규칙은 공개 자료 수준이고 해석의 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
공고가 타이트사주를 시작점으로 자기이해와 삶의 방향을 돕는 사주 2.0 을 만들고 있다고 밝힙니다. 계산 결과를 자기이해 카드로 바꿔주는 이 도구가 그 방향의 축소판입니다.
공고가 AI 기능을 활용한 신규 사용자 경험 설계를 주요 업무로 둡니다. 규칙 계산과 LLM 문구 생성을 분리한 이 구조가 환각 없는 AI 경험 설계의 근거가 됩니다.
Next.js·FastAPI 실무 경험과 Claude Code 등 AI 개발 도구 활용을 요구합니다. 이 도구의 프런트·API·개발 과정이 그 스택 그대로입니다.
생년월일시와 궁금한 주제(일·관계·방향)를 입력하면, 60갑자·절기 룩업 테이블 규칙으로 사주 원국(연·월·일·시 간지)과 오행 분포를 계산하고, LLM 이 그 계산값만 근거로 오늘의 자기이해 카드 한 장을 써주는 리포트 도구입니다. 카드의 모든 문장은 어떤 계산 축(오행 과다·부족 등)에서 나왔는지 추적됩니다.
타이트사주 같은 서비스를 쓰면서 결과 문구가 그럴듯한데 어디까지가 계산이고 어디부터가 붙인 말인지 궁금했던 사용자입니다. 시간을 모르는 채로도 넣어보고, 내 오행 분포 같은 계산 근거를 먼저 보고 해석 문구를 읽고 싶은 사람입니다.
간지·오행 계산을 결정론 규칙으로 분리하고 LLM 에는 계산 결과만 건네면, 사주 콘텐츠의 신뢰 문제(어디까지가 계산인가)를 구조로 풀면서 해석 문구의 품질은 LLM 이 끌어올릴 수 있습니다.
60갑자·절기 룩업 기반 원국·오행 계산 엔진(단위 테스트 포함)과 FastAPI API, 카드 화면까지 Next.js 로 묶어 Vercel 에 배포한 완결품입니다. 출생 시간 미상 입력도 시주 없이 동작합니다.
AWS 에 배포해 운영하고, 만세력 대조 정답표 100건 대비 간지·오행 계산 전수 일치 리포트와 절기 경계·자정 경계 케이스 회귀 테스트가 남은 상태입니다.
일·관계·방향 주제별 카드 템플릿이 늘고, 카드 문장이 계산 축을 벗어나 단정(수명·재물 예언 등)하면 걸러내는 금칙 검사기가 붙은 상태입니다.
생년월일시를 넣으면 원국·오행 분포와 근거가 달린 자기이해 카드가 나오는 흐름을 시연합니다(출생 시간 미상 입력 포함).
간지·오행 계산이 만세력 대조 정답표와 100% 일치함을 전수 채점으로 보여줍니다(표본: 정답표 100건, 절기·자정 경계 포함, 자동 채점).
카드의 모든 문장이 계산 결과에 실재하는 축을 인용하는지, 금칙 단정 표현이 없는지 자동 검사를 통과합니다(카드 30장 기준).
계산 일치는 작성자가 만든 룩업 테이블 범위 안의 검증이고, 카드 문구가 사용자에게 실제로 와닿는지는 사이버네틱스의 실사용자 반응이 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태로 만듭니다.
계산 검증은 작성자가 구성한 룩업 테이블 범위 안의 자가채점이라 만세력 전체의 정확성 증명이 아닙니다. 면접에서는 데모 동작과 검증 구조로 솔직하게 설명합니다.
정답을 내가 만들었으니 잘 맞는 게 당연해지는 함정이 있어, 절기 경계일·자정 출생·시간 미상·음력 표기 흔들림을 더미에 일부러 섞습니다.
명리 해석의 깊이는 유파마다 달라 카드 문구의 해석 타당성은 검증 대상에서 뺍니다. 이 도구는 계산과 해석의 분리 구조를 보여줄 뿐 명리 상담 전문성을 주장하지 않습니다.
실서비스 전환 시 진태양시 보정·서머타임 이력 같은 시간 보정 규칙 추가가 필요합니다. 이는 도입 단계 과제로 분리합니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
계산 엔진의 입력이 되는 출생 기록입니다. 경계·결측·표기 흔들림을 일부러 담아 규칙 엔진의 분기를 시험합니다.
| profile_id | birth_date | birth_time | calendar_raw | calendar_std | sex | question_topic |
|---|---|---|---|---|---|---|
| P-001 | 1994-03-15 | 08:30 | 양력 | 양력 | 여 | 방향 |
| P-002 | 1988-02-04 | 17:10 | 양력 | 양력 | 남 | 일 |
| P-003 | 1997-11-02 | — | solar | 양력 | 여 | 관계 |
| P-004 | 1990-01-01 | 00:05 | 양력 | 양력 | — | 방향 |
| P-005 | 1992-06-21 | 23:40 | 양력 | 양력 | 남 | 일 |
다음 JSON Schema 를 그대로 만족하는 출생 기록 행을 30개 더 만들어 주세요: {"type":"object","properties":{"profile_id":{"type":"string"},"birth_date":{"type":"string"},"birth_time":{"type":["string","null"]},"calendar_raw":{"type":"string"},"calendar_std":{"type":["string","null"],"enum":["양력","음력",null]},"sex":{"type":["string","null"]},"question_topic":{"type":"string","enum":["일","관계","방향"]}},"required":["profile_id","birth_date","calendar_raw","question_topic"]} 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) birth_time 이 null(시간 미상) 5건 이상, (2) 절기 교체일(입춘 2/4 전후·동지 등)과 자정 경계(23:30~00:30) 출생 5건, (3) calendar_raw 표기 흔들림(양력/solar/그레고리력, 음력/lunar/모름) 5건과 calendar_std 매핑 불가(null) 2건, (4) 연도 경계(12/31·1/1)와 윤년 2/29 출생 3건.{"type":"object","properties":{"profile_id":{"type":"string"},"birth_date":{"type":"string"},"birth_time":{"type":["string","null"]},"calendar_raw":{"type":"string"},"calendar_std":{"type":["string","null"],"enum":["양력","음력",null]},"sex":{"type":["string","null"]},"question_topic":{"type":"string","enum":["일","관계","방향"]}},"required":["profile_id","birth_date","calendar_raw","question_topic"]}간지 계산과 오행 판정의 기준 룩업입니다. 절기 경계 시각과 천간·지지의 오행 매핑을 담아 정답을 규칙으로 결정합니다.
| rule_id | rule_type | key | value | effective_at |
|---|---|---|---|---|
| R-001 | 천간오행 | 갑 | 목 | — |
| R-002 | 천간오행 | 병 | 화 | — |
| R-003 | 천간오행 | 무 | 토 | — |
| R-004 | 천간오행 | 경 | 금 | — |
| R-005 | 천간오행 | 임 | 수 | — |
다음 JSON Schema 를 그대로 만족하는 사주 계산 룩업 행을 40개 더 만들어 주세요: {"type":"object","properties":{"rule_id":{"type":"string"},"rule_type":{"type":"string","enum":["천간오행","지지오행","절기경계","시주경계"]},"key":{"type":"string"},"value":{"type":"string"},"effective_at":{"type":["string","null"]}},"required":["rule_id","rule_type","key","value"]} 천간 10·지지 12 의 오행 매핑을 빠짐없이 채우고, 시주경계 12시진을 모두 넣을 것. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 절기경계는 연도별로 시각이 달라지므로 같은 절기의 다른 연도 행을 5건 이상(effective_at 분 단위까지), (2) 자시(23:00-01:00)처럼 날짜를 넘는 경계 행 포함, (3) effective_at 이 null 인 불변 규칙과 시각 규칙이 섞여 있어야 함.{"type":"object","properties":{"rule_id":{"type":"string"},"rule_type":{"type":"string","enum":["천간오행","지지오행","절기경계","시주경계"]},"key":{"type":"string"},"value":{"type":"string"},"effective_at":{"type":["string","null"]}},"required":["rule_id","rule_type","key","value"]}| React | 오행 분포 차트와 계산 근거 펼쳐보기가 있는 카드 화면을 만듭니다 |
| Next.js | 리포트 앱 프레임워크이며 1주차 완성품을 Vercel 로 바로 배포합니다 |
| FastAPI | 원국 계산 엔진과 카드 생성을 묶은 API 서버입니다. 계산 로직의 단위 테스트를 여기서 돌립니다 |
| AWS | 2주차부터 API 서버를 AWS 로 배포해 운영합니다 |
| Claude | 계산된 원국·오행 값만 근거로 자기이해 카드 문구를 생성합니다. 개발 과정에서도 Claude Code 로 작업해 공고의 AI 활용 문화와 같은 방식을 씁니다 |
✓ pass → 여기서 멈춰도 완결입니다. 더 키우려면 AWS 배포와 만세력 대조 전수 채점으로 넘어갑니다.
✓ pass → 주제별 카드 확장과 금칙 검사기 강화로 넘어갑니다.
원국 계산 결과와 그 계산값만 근거로 쓴 자기이해 카드입니다. 문장마다 어떤 계산 축에서 나왔는지 추적됩니다.
{"type":"object","properties":{"profile_id":{"type":"string"},"pillars":{"type":"object","properties":{"year":{"type":"string"},"month":{"type":"string"},"day":{"type":"string"},"hour":{"type":["string","null"]}},"required":["year","month","day"]},"five_elements":{"type":"object","properties":{"목":{"type":"integer"},"화":{"type":"integer"},"토":{"type":"integer"},"금":{"type":"integer"},"수":{"type":"integer"}},"required":["목","화","토","금","수"]},"card":{"type":"object","properties":{"headline":{"type":"string"},"body":{"type":"string"},"evidence":{"type":"array","items":{"type":"object","properties":{"axis":{"type":"string"},"value":{"type":"string"}},"required":["axis","value"]}}},"required":["headline","body","evidence"]},"hedge":{"type":"string"}},"required":["profile_id","pillars","five_elements","card","hedge"]}[
{
"profile_id": "P-001",
"pillars": {
"year": "갑술",
"month": "정묘",
"day": "임진",
"hour": "갑진"
},
"five_elements": {
"목": 3,
"화": 1,
"토": 3,
"금": 0,
"수": 1
},
"card": {
"headline": "벌여 놓은 것을 거두는 힘이 아쉬운 날",
"body": "목 기운이 셋으로 가장 많아 시작하고 뻗어 나가는 쪽에 힘이 실립니다. 반대로 금 기운은 비어 있어 마무리 짓고 추려내는 축이 약하게 잡힙니다. 오늘은 새 일을 더 벌이기보다 진행 중인 일 하나를 끝내는 데 시간을 쓰면 균형이 맞습니다.",
"evidence": [
{
"axis": "오행 최다",
"value": "목 3"
},
{
"axis": "오행 부재",
"value": "금 0"
}
]
},
"hedge": "계산은 더미 룩업 테이블 기준이며 카드 문구는 계산값의 언어화일 뿐 운세 단정이 아닙니다."
},
{
"profile_id": "P-009",
"pillars": {
"year": "계유",
"month": "갑자",
"day": "정미",
"hour": null
},
"five_elements": {
"목": 1,
"화": 1,
"토": 1,
"금": 1,
"수": 2
},
"card": {
"headline": "시간을 몰라도 읽히는 만큼만 읽습니다",
"body": "출생 시간이 없어 시주를 뺀 세 기둥으로만 계산했습니다. 수 기운이 상대적으로 많아 생각을 모으고 정리하는 축이 도드라집니다. 시간이 확인되면 하루 리듬 축이 더해져 방향 질문에 한 겹 더 답할 수 있습니다.",
"evidence": [
{
"axis": "시주 결측",
"value": "hour null"
},
{
"axis": "오행 최다",
"value": "수 2"
}
]
},
"hedge": "시주 없는 부분 계산임을 카드에 그대로 노출했습니다. 합성 룩업 기준 계산입니다."
},
{
"profile_id": "P-005",
"pillars": {
"year": "임신",
"month": "병오",
"day": "기해",
"hour": "을해"
},
"five_elements": {
"목": 1,
"화": 2,
"토": 1,
"금": 1,
"수": 3
},
"card": {
"headline": "일 질문에는 물과 불의 줄다리기로 답합니다",
"body": "자정 직전(23:40) 출생이라 자시 경계 규칙로 시주가 결정됐습니다. 수 기운 셋과 화 기운 둘이 맞서는 분포라, 일에서는 몰입(화)과 재검토(수)를 번갈아 쓰는 방식이 계산 결과와 맞습니다.",
"evidence": [
{
"axis": "시주 경계 적용",
"value": "자시 23:00-01:00"
},
{
"axis": "오행 대비",
"value": "수 3 vs 화 2"
}
]
},
"hedge": "자시 처리 방식은 룩업 테이블에 정의된 한 가지 규칙만 적용했으며 유파별 차이는 다루지 않습니다."
}
][자동 검증 · 스크립트가 전수 수행] 1. 출력이 JSON Schema 형식을 통과하는지 확인합니다(형식 깨진 카드가 화면에 나가는 것을 차단). 2. pillars 와 five_elements 가 규칙 엔진 재계산 결과와 100% 일치하는지 확인합니다(정답은 LLM 이 아니라 룩업 규칙이 결정). 3. card.evidence 의 모든 axis·value 가 계산 결과에 실재하는지 확인합니다(계산에 없는 근거 인용 차단). 4. 금칙 목록(수명·질병·재물 단정 표현)이 body 에 없는지 확인합니다. [수동 검증 · 사람이 표본 확인] 1. 카드 문구가 evidence 범위를 넘어 과장하지 않는지 30장을 표본 검토합니다. 2. 시간 미상 카드가 부분 계산임을 숨기지 않는지 확인합니다.
포트폴리오가 “무엇을 만들지”라면, 시나리오 테스트는 “현장에서 어떻게 판단·소통할지” 입니다. 실제 이 채용공고 맥락의 대본을 읽고 무엇을 물어야 할지 직접 써봅니다.