Project10 [마침표] 02. Wireframe / Design Token / ERD Wireframe다음으로 와이어프레임을 스케치했다.전체적인 디자인 틀과 애니메이션을 담았다.쪽팔려서 모자이크좀 했다.피그마로 만드는 선택지도 있었지만, 아래와 같은 이유로 패드를 이용해 스케치를 했다.1인 개발이기 때문에 내용을 체계적으로 공유할 일이 없음.프로젝트의 규모가 작기에 절대적인 분량이 적음.미니멀한 디자인 언어를 사용할 예정이기 때문에 구현이 단순함.Design Token이전에 포트폴리오 작업 할 때, 디자인 토큰 사전 정의의 중요성을 느껴서 미리 지정해보았다.실제로 구현할 때 변경될 여지는 충분히 있다.더보기ColorPrimary Text#111111Sub Text#666666Disabled (Hint)#CCCCCCBackground#FAF9F6Point (V button)#222222 T.. 2025. 12. 22. [마침표] 01. State Diagram / Flowchart Mermaid를 활용하여 상태 다이어그램과 플로우차트를 간단하게 구현하였다. 일반적인 CRUD 기반 프로젝트라면 ER Diagram 또는 Wireframe을 먼저 진행한다.그러나 이 앱은 시간과 사용자의 행위에 따른 데이터의 상태가 엄격해야 하기 때문에 State Diagram과 Flowchart를 먼저 진행하였다. 1. State DiagramState Diagram을 통해 "오늘의 문장"이라는 객체가 시간과 사용자 행위에 따라 어떻게 변하는지를 정의하였다.일반적인 게시글과 달리, 이 앱의 기록은 수정 가능한 시간에 제한이 있다. 따라서 Closed 상태와 Locked 상태를 분리하였다. 핵심 로직Expired (만료): 사용자가 앱을 켜지 않아도 시간이 흐르면 데이터는 Empty에서 Expired로 .. 2025. 12. 20. [마침표] 00. 제품 철학 및 제약 정의서 1. Concept앱 이름마침표: 하루를 닫는 한 문장.하루 한 문장 기록 앱하루를 단 한 문장으로만 기록함으로써, 기록의 부담을 최소화하고 사고의 밀도를 높이는 기록 앱. 2. Motivation필사 경험을 통해 짧은 문장 기록의 효용을 체감AI, 숏폼 중심 환경에서 사유와 사고 시간이 급격히 줄어드는 문제 인식기록의 분량을 극단적으로 제한하면 기록이 부담이 아니라 습관이 될 수 있다는 가설3. Problem Statement기록을 하고 싶지만, 무엇을 써야 할지 몰라 입력창 앞에서 멈추는 순간이 반복된다.핵심 문제기록 욕구는 있으나 앱, 분량, 형식, 완성도에 대한 진입 장벽이 높음기존 다이어리 앱은 ‘많이 쓰는 사용자’에 최적화되어 있음4. Solution & Value Proposition4.1 .. 2025. 12. 14. [추천 모델] 06. 백엔드 서버 연동 및 테스트 (完) 구성NestJS 백엔드 프로젝트에 recommendations 폴더를 생성하였다.Controller → Service → FastAPI 서버 순서로 API 호출이 진행된다.ModuleController와 Service를 묶어주는 모듈 구성이다.HttpModule을 등록하여 RecommendationService가 외부 서버인 FastAPI서버와 HTTP 통신을 할 수 있도록 설정한다.Controller - 클라이언트가 GET 방식으로 /recommendations 경로로 API를 요청하면 해당 컨트롤러가 요청을 받는다.- 이때, @GetUser() 데코레이터를 통해 로그인된 사용자의 ID 정보를 가져온다.- 가져온 사용자 ID와 현재 시각을 Service계층의 getPersonalizedRecommend.. 2025. 11. 1. [추천 모델] 05. FAISS 인덱스, FastAPI 서버 구축 FAISS의 정의, 선택 이유FAISS란?Facebook Ai Similarity Search의 약자로, Meta의 AI 연구소에서 개발한 유사 벡터 검색 라이브러리.FAISS를 사용하는 이유도서관에서 책 A와 비슷한 책 10권을 찾고자 하는 경우에 비유하자면,일반적인 검색 방식은 모든 책을 책 A와 일일히 비교해야 한다.만약 책이 수십, 수백만권이면 굉장히 오래 걸릴 것이다. FAISS 방식으로 A와 비슷한 책 10권을 찾는 경우에는,미리 도서관의 모든 책의 핵심 내용을 요약하여 색인을 만들어 둔다.이후 색인을 활용해 A와 가장 비슷한 책 10권을 빠르게 찾아낸다. 현재 프로젝트에서 도서관의 책들은 가게 벡터(Item Vector)이고, 책 A는 사용자 벡터(User Vector)이다.즉 FAISS는 .. 2025. 10. 23. [추천 모델] 04. 모델 구현 및 평가 (3): 모델 구현 마무리 Review Data 변경에 따른 재학습기존 리뷰 데이터는 user_id가 약 20종류, review수가 2,000여개였다.새로운 리뷰 데이터는 user_id가 약 370종류, review수가 3,700여개이다. 새로운 리뷰 데이터 바탕으로 지금까지의 모든 과정을 다시 진행해보겠다. 먼저, Baseline 모델이다.테스트 정확도는 6.79%이다. Exp2 모델이다.테스트 정확도는 12.25%이다.Baseline 모델에 비해 5.46%의 성능 향상을 보였다. Exp3 모델이다.이전 데이터셋을 통한 학습에서는 성능 감소 즉, 노이즈로 인식했었다. 테스트 정확도는 15.73%이다.Exp2 모델에 비해 3.48%의 성능 향상을 보였다. 이전 데이터셋에서는 meal_time 피처가 사용자의 선호를 학습하기에 불충.. 2025. 10. 17. [추천 모델] 03. 모델 구현 및 평가 (2): Exp 2, 3 / Trouble Shooting Exp 2: category 추가기존 Baseline 모델에 category feature를 추가했다. 분석학습 데이터로 학습한 결과이다. Loss Graph - 빨간 선Baseline 모델과 같이 매우 안정적이다.epoch 2에서 가장 낮은 손실값을 기록했으며, 이후로 미세하게 증가하며 overfitting의 조짐을 보였다. Accuracy Graph - 빨간 선첫 epoch부터 10%를 넘는 정확도를 보였으며, 최종적으로 14%까지 상승했다.이를 통해 category feature를 통해 사용자의 취향을 더 잘 파악할 수 있게 되었다. 테스트 데이터를 통해 구한 Top-10 Accuracy는 약 15.6%이다.Baseline 모델에 비해 7.1% 향상되었다. (14% 개선)즉, 이 모델은 15.6% .. 2025. 10. 16. [추천 모델] 02. 모델 구현 및 평가 (1): Baseline Model Baseline Model 구현가장 먼저 구현할 모델이다.이 모델에서는 최소한의 faeture 즉, user_id와 store_id만을 사용한다.이를 통해 모델은 사용자와 가게의 기본적인 관계를 학습한다.추후 다른 feature를 추가하여 점진적 복잡성을 구현한다. 이러한 순서로 진행하는 이유는 아래와 같다.1. 최소한의 성능 기준 확보최소한의 모델을 성능 기준으로 삼음으로써, 추후 여러 feature들이 추가되었을 때 그 feature가 모델 성능을 얼마나 향상시켰는지를 측정할 수 있다.2. 디버깅 용이성모델이 혹시라도 제대로 학습되지 않을 때, 원인이 user_id와 store_id 사이의 관계 문제인지, 아니면 다른 피처의 문제인지 찾아내기 쉽다. 모델의 핵심 구성은 위와 같다.user_id와 st.. 2025. 10. 16. [추천 모델] 01. 데이터 전처리 프로젝트 폴더 구조 및 개발환경 설정위와 같은 구조로 폴더를 생성하였다.data ⎹ processed: 전처리된 데이터(학습, 테스트 데이터) 저장 ⎹ raw: 리뷰 데이터 원본 저장notebooks ⎹ saved_models: 모델 개발 중간 과정들을 저장 ⎹ ~.ipynb: 실제 코드 이후 venv를 통해 python 가상환경을 설정하여 각종 라이브러리의 버전 관리를 로컬과 분리하였다.데이터 전처리1. 데이터 타입 변환 및 결측치 확인이후 진행할 time값 피처 엔지니어링을 위해 time 데이터의 타입을 object에서 datetime으로 변경하였다.결측치 또한 없음을 확인하였다. 2. Time Feature Engineering사용자의 특정 시점 패턴을 파악하기 위해 t.. 2025. 10. 14. 이전 1 2 다음
