이제 AI적요소, 백엔드, 프론트엔드까지는 다 완성했다.

이제 백엔드, 프론트엔드적으로 개별 테스트를 통해 서비스를 완성해나가려고 한다.

통합 테스트 우선순위

  1. 사용자 프로필 & 정책 매칭
    • 사용자 프로필이 MySQL에 올바르게 저장되는지 테스트
    • 벡터 검색 및 랭킹 알고리즘이 사용자 속성에 기반한 관련 정책을 반환하는지 확인
    • 엣지 케이스 테스트 (예: 특정 기준에 맞는 정책이 거의 없는 사용자)
  2. RAG 기반 챗봇
    • 질문 유형에 따른 응답 정확도 테스트
    • 정책 내용에 대한 복잡한 질문 처리 능력
    • 답변을 모를 때 적절하게 대응하는지 확인

다음과 같이 진행예정이다.

그러다가 챗봇테스트중 기능추가가 필요한 부분을 발견했다. 지금은 대화목록이 저장되지않는데 Chat gpt나 Claude나 여타 LLM들은 모두 왼쪽 사이드바에 기존 대화목록이 저장된다. 꼭 필요한 기능이라고 생각하는데 까먹었다.

  • 채팅 목록 표시 UI 추가
  • 새 채팅 생성 기능 구현
  • 기존 채팅 선택 기능 구현
  • 채팅 삭제 기능 구현

이렇게 4가지 Task로 분류하여 하나하나 설계하였다.

그러다 의문점을 발견했다. 대화가 새로 생길때마다 Mysql에 아래와 같이 쌓이게 된다.

image-20250410120125953

image-20250410120143966

그렇게 id에맞게 도메인이 주어지는데

http://localhost:3000/chat/19

image-20250410115649466

Chatgpt의 채팅별로 도메인을 확인해보니 아래와 같았다.

https://chatgpt.com/c/67f4b938-1700-8003-8651-78b27eeed822

내가 지금 구현한 방식은 단순한 숫자 기반 URL이고 Chatgpt는 UUID 기반 URL이다.

Chatgpt에게 어떤 방식으로 하는게 나을까 물어보니


**1. 숫자 기반 URL **

장점

  • 간결함: URL이 짧고 간단하여 사용자가 쉽게 기억하거나 공유할 수 있습니다.
  • 구현 용이성: 데이터베이스에서 기본 키(예: ID)를 직접 사용하기 때문에 구현이 간단합니다.
  • 빠른 접근: URL을 통해 특정 리소스에 직접 접근하기 쉬움.

단점

  • 의미 부족: URL만 보고 어떤 콘텐츠인지 알기 어렵습니다. 이는 사용자 경험이나 신뢰도에 영향을 줄 수 있습니다.
  • 보안 문제: 순차적인 ID는 예측 가능하므로, 악의적인 사용자가 다른 리소스를 무작위로 요청할 가능성이 있습니다.

2. UUID 기반 URL

장점

  • 보안 강화: UUID는 예측하기 어렵기 때문에 무작위 요청이나 데이터 노출 위험을 줄일 수 있습니다.
  • 유니크함: 전역적으로 고유한 식별자를 생성하므로, 충돌 위험이 거의 없습니다.
  • 스케일링 적합: 대규모 시스템에서 리소스를 관리하거나 분산 환경에서 데이터를 처리할 때 유리합니다.

단점

  • 가독성 저하: URL이 길고 복잡하여 사용자가 기억하거나 공유하기 어렵습니다.
  • SEO 영향: 의미 없는 문자열은 검색 엔진 최적화(SEO)에 불리할 수 있습니다. 검색 엔진은 URL에서 키워드를 분석하여 페이지 내용을 이해하므로, UUID는 이 점에서 불리합니다.

두 방식의 선택 기준

1. 프로젝트 규모 및 목적

  • 작은 프로젝트나 내부 시스템에서는 간단한 숫자 기반 ID가 적합합니다.
  • 대규모 시스템, 특히 보안이나 글로벌 유니크 ID가 중요한 경우 UUID를 사용하는 것이 좋습니다.

2. 사용자 경험 및 SEO

  • 사용자 친화적이고 SEO를 고려해야 하는 경우, 의미 있는 키워드나 간결한 URL 구조를 사용하는 것이 더 유리합니다.

3. 보안 요구사항

  • 보안이 중요한 애플리케이션에서는 UUID와 같은 비예측 가능한 식별자를 사용하는 것이 더 안전합니다.

결론

숫자 기반 ID는 간단하고 효율적이지만, 보안과 확장성을 고려한다면 UUID가 더 나은 선택일 수 있습니다. 그러나 두 방식을 혼합하여 상황에 맞게 사용하는 것도 가능합니다(예: /chat/{UUID} 또는 /chat/{ID}-{slug}). 최종적으로는 프로젝트의 요구사항과 우선순위에 따라 결정해야 합니다.


좀 더 규모가 크고 보안이 중요한 프로젝트라면 UUID를 쓰겟는데 그건 아니니까 그대로 진행하기로 했다.

이제

  • 정책 추천 다듬기.
  • 프로필 걍 회원가입 한번 하면 수정안되게 하기
  • 정책 검색탭이 아니라 정책 추천탭으로 수정
  • 챗봇상담 누를때마다 계속 새 대화창 쌓이는거 막기(새로고침이나 ‘새 대화’누를때마다 안쌓이는것처럼)

이게 굉장히 어려웠다.

애매하네. 우선 지역은 필요없어서 없앨거고. 연령대,성별은 그대로둘거고. 고용상태가 재직자, 구직자, 자영업자, 학생으로 지금 나뉘어잇는데 애매하네.

청년, 고령자(신중년), 장애인, 여성(육아지원), 외국인근로자, 사업주, 직업능력개발

정책집이 크게 카테고리가 이렇게 나뉘는데. 어케 회원가입할때 그리고 정책 추천페이지에서 필터링을 어케 걸어야 효과적일까?

이거 필터링 나누고 한번 정책추천이 어케 나오는지 테스트해보자.

우선 pdf 전부 넣고 다시 테스트하자.

그리고 정책추천이 맛이 너무 없으면 파인콘에서 인지몰라도 어디파이프라인에서 요약을 한번 걸고. 그 페이지를 불러올때 요약된걸 보여주자. 지금은 너무 내용도 중간에 끊기고 불친절하다.

그리고 관심정책 눌러서 내 프로필에서 확인가능하게 하자. db에 저장하게 하면되고.

그리고 마지막으로 LLM테스트하고

(im)후처리해서 안나오게하기

알림서비스 다 지워버리기