프롬프트의 목적지(Goal)가 알고리즘의 뼈대를 바꾼다: 사상체질 진단 웹앱 구현기

사상의학 웹앱 소개

프로젝트 목표와 배경

동일한 사상의학 원전 데이터를 기반으로 노트북LM(NotebookLM)과 제미나이(Gemini)를 활용해 웹앱을 제작했으나, 초기 프롬프트의 기획 방향(목적지)에 따라 최종 구현된 알고리즘과 로직에서 극적인 차이가 발생하는 흥미로운 경험을 했습니다.

  • Index 버전 (index_2.html): AI에게 직접 "체질 판단 로직을 짜달라"고 요청한 결과물입니다.

  • Patient 버전 (patient.html): "체질 구분표"를 먼저 도출한 뒤, 이를 바탕으로 "제품기획서(PRD)"를 만들어달라고 단계적으로 요청한 결과물입니다.

두 버전은 원전 기반의 정밀도와 사용자 가독성 측면에서 완전히 다른 장단점을 보여주었습니다. 왜 이런 결과의 차이가 발생했는지 분석하고, 이를 통해 배운 AI 프롬프트 엔지니어링의 핵심 인사이트와 한의학 데이터를 다룰 때의 설계 딜레마를 공유하고자 합니다.

진행 방법

도구 사용 및 활용 방법

사상의학 원전 데이터를 학습시킨 노트북LM과 제미나이를 조합하여 사용했습니다. 동일한 데이터 소스를 제공했음에도 불구하고, AI가 부여받은 '역할(Persona)'과 '추상화 레벨'에 따라 로직 설계 방식이 완전히 달라졌습니다.

💡 기획 방향에 따른 AI의 역할 해석 차이

  • Index 버전 (엔진 중심 개발): AI가 자신을 '백엔드 개발자 및 알고리즘 설계자'로 인식했습니다. 그 결과, 사상의학 원전 데이터(9대 세부 계열)를 오차 없이 계산할 수 있도록 구조화(Tree 구조, 타이브레이크 로직, 수치 시각화)하는 데 집중했습니다.

  • Patient 버전 (사용자 시나리오 기획): [원전 → 구분표 → PRD]라는 단계적 가공을 거치며 AI가 자신을 '서비스 기획자(PM)'로 인식했습니다. 사용자 경험(UX)에 집중하느라 정밀한 로직(태양인 누락, 동점자 처리 미흡)은 단순화된 반면, 환자용 문항의 표현력은 극대화되었습니다.

Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.

  • Index 버전 생성 프롬프트: "사상의학 원전 데이터를 기반으로, 주체질 판정 후 세부 계열로 분화하는 정밀한 체질 판단 알고리즘 로직을 구현한 HTML 코드를 작성해줘."

  • Patient 버전 생성 프롬프트: "앞서 만든 체질 구분표를 토대로, 실제 환자가 사용할 예진 시스템의 제품기획서(PRD)를 작성하고 이를 구동 가능한 웹앱 HTML 코드를 변환해줘."

Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.

한국어 테스트 스크린샷

Tip: 코드 전문은 코드블록에 감싸서 작성해주세요.

HTML

Open optionsauto

<!DOCTYPE html>
<html>
<head>
    <title>사상체질 진단 시스템</title>
</head>
<body>
    </body>
</html>

결과와 배운 점

AI 프롬프트 엔지니어링의 인사이트

AI에게 "무엇을 만들어달라고 하느냐(Goal)"에 따라 내부 알고리즘의 뼈대 자체가 바뀐다는 것을 깊이 깨달았습니다.

  • Index 버전의 결과 (우수한 두뇌): 9대 세부 계열 완벽 반영, 2단계 동적 트리 구조, 동점자 타이브레이크 시스템 등 알고리즘의 정확도가 매우 높았습니다.

  • Patient 버전의 결과 (우수한 얼굴): "밤새알 모양 대변", "얼음장 같은 손발" 등 환자가 직관적으로 선택할 수 있는 훌륭한 구어체 UX 라이팅이 도출되었습니다.

  • 클로드가 분석한 Index버전(전자)과 Patient버전(후자)의 차이는 다음과 같습니다.

    한국어 한국어 한국어 한국어 한국어 한국어 한국어 한국어

💡 나만의 꿀팁

하나의 프롬프트로 '완벽한 로직'과 '친절한 UX'를 동시에 얻기는 어렵습니다. [엔진 개발용 기술 프롬프트][사용자 경험 기획용 프롬프트]를 철저히 분리하여 각각 최상의 결과물을 얻은 뒤, 이를 하나로 합치는 '소프트웨어 통합(Integration)' 프로세스를 거치는 것이 가장 효과적입니다.

시행착오와 개선점

기획서(PRD) 단계를 거친 patient.html 버전의 경우, 여러 단계의 추상화 거름망을 거치면서 정밀한 원전 데이터가 일부 유실(태양인 분류 누락, 동점 시 특정 체질 강제 지정 등)되는 현상이 발생했습니다. AI에게 단계적 가공(PRD 변환 등)을 시킬 때는 핵심 연산 로직이 유실되지 않도록 가이드라인을 강하게 묶어주어야 한다는 것을 배웠습니다.

데이터베이스 구축의 핵심 딜레마

이번 실험을 진행하며 한의학 임상 데이터를 시스템화할 때 마주하는 '설계 선후 관계에 따른 방향성 차이'를 명확히 정의할 수 있었습니다. 아래 두 작업 중 무엇을 먼저 하느냐에 따라 데이터베이스를 구축하는 '건축 방식'과 '초기 결과물'이 달라질 뿐만 아니라, 초기에 희생(유실)되는 데이터의 성격도 완전히 달라집니다.

  1. 각 감별 지표(Property)들에 부여할 구체적인 '가중치 수식(Formula)' 산출

  2. 체질적 특징들을 임상 평가 프로토콜에 맞추어 체계적인 '표준 용어(SNOMED CT 등)'로 맵핑하는 작업

구분

① 수식(Formula) 및 로직 산출 우선

② 표준 용어 맵핑(Mapping) 우선

개념

용어의 이름보다 '진단이 정확하게 작동하는가'에 집중

수식을 짜기 전에 데이터 규격과 용어 표준을 먼저 세팅

특징

DB에 임시 명칭(손발온도, 응가상태)으로 속성을 만들고 가중치 계산 수식을 즉시 연결하여 테스트

수족부_한열_상태, 대변_조활_양상 등 체계적이고 호환성 높은 데이터 구조를 먼저 확립

장점

아이디어를 실행 가능한 프로토타입(MVP)으로 빠르게 확인 가능, 알고리즘 디버깅이 쉬움

대규모 분석, AI 요약 연동, 외부 기관과의 호환성 극대화, 추후 코드가 깨질 위험이 적음

단점

추후 공식 의학 용어로 전환 시 짜두었던 변수명과 수식을 일일이 수정하는 번거로움 발생

초기 분류 및 표준화 작업에 시간이 오래 걸려 실제 작동 화면을 보기까지 시간이 소요됨

⚠️ 유실 위험 데이터

[데이터 호환성 및 표준 맥락 유실]


빠른 구현을 위해 임의의 변수명을 사용하므로, 나중에 데이터가 쌓여도 타 기관의 임상 프로토콜이나 국제 표준(SNOMED CT) 데이터와 연동되지 않아 기록 데이터의 학술적 가치가 유실될 위험이 큽니다.

[정밀 알고리즘 및 예외 케이스 유실]


용어를 규격화하고 추상화(요약)하는 과정에서, 사상의학 고유의 정밀한 예외 로직(ex. 태양인 분류 알고리즘, 동점자 타이브레이크 조건문 등)이 누락되거나 단순화되어 알고리즘의 정밀성이 유실될 위험이 큽니다.

추천

"내 머릿속 로직이 컴퓨터에서 구현되는지 빠르게 검증하고 싶다."

"나중에 두 번 일하지 않도록 처음부터 확장성 높은 완벽한 구조를 잡고 싶다."

도움이 필요한 부분

코드를 수정하거나 새로운 감별 지표를 추가할 때마다, 기존에 잘 작동하던 로직이 깨지거나 특정 체질(예: 태양인) 분류가 다시 누락되는 등의 사이드 이펙트(Side Effect)가 새로이 발생하고 있습니다. 이를 효율적으로 걸러내고 무결성을 검증할 좋은 방법이 필요합니다.

앞으로의 계획

index_2.html이 가진 강력한 '2단계 동적 트리 진단 엔진' 위에 , 임상 프로토콜에 맞춘 '표준 의료 용어 데이터 구조'를 이식하고, 최종적으로 patient.html이 가진 '친근한 구어체 질문 UX'를 입힐 예정입니다.

선후 관계의 차이로 인해 각기 다른 데이터 유실 위험을 안고 태어난 두 개의 코드를 현명하게 결합하여, 실제 임상 현장에서도 널리 활용할 수 있는 완성도 높은 '사상체질 예진 시뮬레이터 마스터피스'를 완성하는 것이 다음 목표입니다.

도움 받은 글 (옵션)

  • 지난주 지식 베이스 스터디

3
2개의 답글

뉴스레터 무료 구독