전체 글53 [마침표] 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. [CS] 저는 HTML 프로그래머입니다. 개발을 처음 배울 때 “HTML은 프로그래밍 언어가 아니다.” 라는 말을 종종 듣곤 한다. 그런데 막상 HTML 파일을 뜯어보면 뭔가 코드 비슷한것을 적고, 브라우저는 그걸 또 해석해서 화면을 출력한다.겉보기엔 프로그래밍 언어처럼 생겼는데…도대체 왜 프로그래밍 언어가 아닐까? 튜링 완전성 관점에서 이 질문을 풀어본다.1. 튜링 완전성(Turing Completeness)이란?튜링 완전하다는 건 한 문장으로 요약하면 아래와 같다.충분한 시간과 메모리가 있다면, 어떤 계산 문제라도 표현할 수 있는 능력. 조건문, 반복문, 상태 변화, 메모리 조작 등을 이용해일반적인 계산 처리를 할 수 있어야 튜링 완전한 언어다. C, Java, Python 등 익숙한 언어들이 여기에 해당된다.즉, 위 언어들은 튜링 완전한 .. 2025. 12. 1. [회고] 학술제 탈락 원인 분석 학술제 예선에서 탈락했다.솔직히 본선 진출에 대한 기대가 있었기에 아쉬움이 남는 것이 사실이었다.하지만 아쉬움과 억울함은 잠시 덮어두고, 프로젝트 기획부터 발표까지의 전 과정을 복기하며 실패 원인을 분석해보았다.원인 1: 잘못된 문제 정의와 시장 검증 부재가장 큰 원인은 프로젝트의 모티베이션, 즉 "해결하고자 하는 문제" 자체에 대한 탐색이 완벽하지 못했다는 점이다. 3학년 겨울방학부터 준비해 온 주제가 있었으나, 교수님의 "공감되지 않는다"는 피드백에 따라 급하게 주제를 변경해야 했다.주제 탐색부터 선정 마감까지 남은 시간은 단 2~3일이었다. 이 과정에서 '지역화폐 활성화 플랫폼'이라는 주제를 선정했다.당시 우리 팀과 주변 지인들(주로 20대 학생)은 '여민전'이라는 지역 화폐를 거의 사용하지 않았고.. 2025. 11. 12. [추천 모델] 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. 이전 1 2 3 4 ··· 6 다음
