AI 기반 멘탈케어 플랫폼 "Mind-Log"

Overview

사용자의 감정과 심리 상태를 AI가 분석하여 위로와 솔루션을 제공하는 멘탈케어 플랫폼입니다.
KT Cloud Tech Up 생성형 AI 과정(18인)의 팀 프로젝트로 진행했으며, 기획부터 보안 점검까지 전 과정을 팀장으로 총괄했습니다.
내 역할: 팀장(PM 및 AI 개발 겸임) — 18인 규모 리딩, 초기 프로젝트 기획 참여, AI 파이프라인 설계, RAG 시스템 구현, 일정 및 산출물 총괄.

Tech Stack & 선택 근거

Python / FastAPI — AI 서빙 서버 - LangChain / LangGraph — RAG 파이프라인 및 멀티 노드 대화 그래프 (persona/history/chat 병렬 실행) - AWS Bedrock — Claude 3.x LLM, Titan Embed v2, Titan Image v2, Guardrails (PII 탐지·콘텐츠 안전) - PostgreSQL + pgvector — 명제 벡터 저장 및 cosine 유사도 검색 - Redis — 대화 이력 캐시 - AES-256-GCM — 민감 데이터 필드 암호화

Troubleshooting

Problem

세션 단위 RAG로는 검색 정밀도가 낮아 과거 상담 컨텍스트가 제대로 반영되지 않음

Cause

세션 단위 청크가 너무 커서 잡음이 많고, 관련 정보가 유사도 임계값을 넘지 못하거나 불필요한 내용까지 함께 주입되는 문제

Alternatives

1) 청크 크기를 줄여 단순 텍스트 분할
2) 검색 수를 늘려 보완
3) 세션 요약에서 원자적 명제(Proposition)를 추출해 검색 단위 세분화

Decision

세션 컨텍스트를 LLM으로 5~10개의 원자적 명제로 분해해 pgvector에 저장.

Proposition 단위 RAG 필터링으로 과거 상담 컨텍스트 정밀도 향상, 개인화 상담 경험 구현

Troubleshooting

Problem

민감 상담 데이터를 AES-256-GCM으로 암호화하면 벡터 검색 외 조회 방법이 없어지는 문제

Cause

암호화된 텍스트에 Full-text Search나 키워드 검색을 적용할 수 없으므로 기존 레거시 텍스트 검색 방식과 함께 사용하기 어려움

Alternatives

1) 암호화를 포기하고 평문 저장 (보안 원칙 위반)
2) 검색 전용 평문 필드와 암호화 필드를 이중 관리
3) 벡터 임베딩은 평문 기준으로 생성·저장하고, content만 암호화하여 검색은 dense vector 전용으로 운용

Decision

벡터 임베딩을 암호화 전 평문 기준으로 생성해 pgvector에 저장. 검색 결과 반환 후 content를 복호화하여 LLM에 주입. 
Full-text Search는 사용하지 않고 dense vector 검색만 사용하는 구조로 설계

보안을 유지하면서 의미 유사도 기반 RAG 검색 구현

Troubleshooting

Problem

심리 상담 서비스 특성상 사용자 입력의 개인정보 노출과 AI 출력의 유해 콘텐츠를 동시에 차단해야 하는 요구사항

Cause

멘탈케어 특성상 자해·자살 관련 내용이나 직접적인 의료 처방 요청이 발생할 수 있으며, 동시에 이름·연락처 등 개인식별정보가 상담 중 노출될 수 있음

Alternatives

1) 정규식·키워드 필터 직접 구현 (규칙 기반, 유지보수 부담)
2) 별도 분류 모델로 입출력 검사
3) AWS Bedrock Guardrails에 위임

Decision

Bedrock Guardrails의 apply_guardrail API를 사전 검사로 사용. 입력 단계에서 PII 감지 시 익명화 처리 후 LLM 호출, 주제 차단·콘텐츠 필터는 LLM 호출 없이 즉시 종료. 출력 단계에서도 유해 콘텐츠 자동 검사. AWS 오류 시 서비스 가용성 우선(Fail-open) 적용

입출력 양방향 안전망 구축으로 개인정보 보호 및 유해 콘텐츠 차단

Troubleshooting

Problem

AI 개발을 직접 담당하면서 18인 팀의 일정·산출물 관리를 겸임해야 하는 상황

Cause

AI·프론트엔드·백엔드·인프라·보안 등 전문 영역이 분리된 구조에서 파트 간 인터페이스 명세가 늦어지면 전체 개발이 블로킹되는 리스크가 있었음

Alternatives

1) 파트별 독립 진행 후 막판 통합 (인터페이스 충돌 위험)
2) 모든 기술 결정을 전체 회의로 처리 (속도 저하)
3) 서비스 간 API·데이터 계약을 초기에 확정 후 병렬 개발

Decision

AI·백엔드 간 내부 API 인터페이스와 데이터 구조를 개발 초기에 명세화하여 팀 내 블로커를 최소화. 매일 아침 스크럼으로 각 파트의 이슈와 진행 상황을 공유하며 병목 지점을 조기 발견

기획~보안 전 과정 소통의 기준을 마련

Results & 회고

보안팀 단위 테스트 전 항목 성공률 100% 달성
Proposition-based RAG 필터링으로 과거 상담 컨텍스트 정밀도 향상
위기 감지 4단계 시스템으로 상담 중 실시간 안전망 구축
18인 규모 팀 리딩 및 AI 개발 겸임으로 기술·관리 역량 동시 강화
회고: 팀 리더로서 18인의 다양한 역량을 가진 팀원들을 이끌며 기술적 결정과 인적 조율을 동시에 수행하는 것이 가장 큰 도전이었습니다. 기획과 매니징에 치중해 기술적 깊이가 아쉬웠지만 팀 매니징에 대한 인사이트를 얻기 아주 좋은 과정이었습니다.