j-node 님의 블로그

최종 프로젝트(도메인 선정) 시작

오늘 벌어진 일1. 도메인 선정 시주요 원칙: 다각도에서 도메인 및 주제 검토방식: 어제의 아이디어들에서 도메인 관심도, 실현 가능성, 핵심 가치/문제 중요도 등을 기준으로 4가지 선정(식품 성분, 주식 매매 관리, 웨딩 견적, 경제 뉴스 요약 및 개인화)과정: AI 기반으로 '데이터 수급, 사업적 가치, 문제 심각도, 기존 서비스 한계, mvp 범위'를 기준으로 상, 중, 하로 분류 후 검토결과: AI의 결과 검토하는 과정에서, 타깃 유저와 방향성, 경쟁사와의 차별성에 따라 갑자기 갈래가 나뉨식품 성분: 식품 성분 분석은 기존 서비스 '푸드랩'이 있음. → 한국 제품에 관심 있거나 한국에 체류하는 외국인 타깃으로 바꾸는 게 어떤지?주식 매매 관리: 개인 매매 기록, 트래킹으로 생각 → 데이터 수급 고려..

블로그 글 두 편(j-node.tistory.com/71 = 1·2·5화, /72 = 3·4화)의 QUESTIONS 목록을, 토스 원문 아티클(toss.tech/article/undercover-silo-2~6)과 외부 자료로 CLAUDE가 검증한 정리본. 근거가 있는 내용만 담았고, 확인 불가한 부분은 그대로 표시. 상세 출처는 맨 아래 〈참고문헌〉 참고.1화: 유저 그로스 (인플로우)Q1. "보상이 극단적으로 크면 기대감이 왜곡된다"가 맞나? (심리학 문헌 검증)판정: 방향은 맞지만, 단일 이론이 아니라 여러 연구를 압축한 실무형 표현이며 "왜곡 = 기대감 하락"으로만 읽으면 부정확. 이 문구와 정확히 일치하는 이름의 이론은 없고, 인접한 세 갈래 연구가 방향성을 뒷받침한다.큰 보상의 체감 가치가 압..

3화: 페이스 페이Problem페이스 페이의 생소함으로 인한 진입 장벽이 있음페이스 페이 사용 시 에러 메시지에 주의를 기울이지 않음Solution접근 방식얼굴 인식을 결제가 아닌 다른 곳에서 경험하도록공공 디바이스상의 에러 메시지를 얼굴 가까이 위치.얼굴 등록얼굴 등록 사전 신청그러나, 얼굴 인증의 생소함, 어색함으로 이탈(특히 갤럭시 유저) by 설문전략: 보상 없는 이벤트로 자주 노출해서 익숙하게 만들자WHY? 보상 있었다면 ('얼굴 등록하면 얼마 드린다') → 사용자가 개인정보 판다고 느낄 수 있음방식: 바이럴 이벤트 - AI로 얼굴 인식해 아바타/프로필 만들어주기, '전생 찾기'/'떡국 먹고 회춘하기' 처럼 재미있는 결과결제 전환의 문제: 바이럴 이벤트가 공식 디바이스(카페 식당 등에 있는)의 ..

1화: 유저 그로스Problem유저 그로스Solution접근 방식새 유저 데려오거나 vs. 기존 유저 붙잡기새 유저에 집중 위한 방식: 마케팅 vs. 기존 유저의 추천 바이럴기존 유저의 추천 바이럴 선택핵심 지표: 공유율복권강력한 기대감보상이 극단적으로 크면 기대감이 왜곡된다는 심리학 이론 참고반복 참여 유도복권이 성공한 뒤, 보상만 살짝 바꾼 복권 이벤트 지표 별로 안 좋았음바이럴은 2번까지는 성공적, 이후 성과 꺾인다고 함.아이템 유형을 바꾸면 새로운 초대자 급증하기도 함.바이럴: 사용자에게 기대감, 만족감 동시에 주어야 함 + 직관적 + 반복 참여 유도이탈율 낮추고 공유율 끌어올리는 유저 플로우 설계하기방식: '틀린 글자 맞추기’ 챌린지에서 튜토리얼을 싹 빼고 카운트다운을 맨 앞에 두는 흐름'단계별..

1번 글각 이해관계자들에게 왜 필요한지, 실사례를 잘 소개함.2번 글각 단계나 방식을 비유로 잘 설명해줌. 상황별 데이터 파이프라인 툴을 추천 굿.3번 글각 단계별 코드 예시 있음.*내가 참고하려고 요약함. 정확한 내용은 원문 참고1. 데이터 파이프라인이란?자동으로 데이터를 하나 이상의 소스에서 하나 이상의 목적지로 이동하는 시스템.그 과정에서 transforming, cleaning, enriching이 동반됨.2. 주요 구성 요소Sources: Customer database(CRM 등), website analytics, API, cloud storage, IoT devicesPipeline engine: the middleware layerDestinations: Data warehouses, r..

https://helloworld.kurly.com/blog/bigquery-1/ 컬리의 BigQuery 도입기 - 1부 - 컬리 기술 블로그컬리 데이터 파이프라인의 BigQuery 도입 배경과 그 주안점helloworld.kurly.com 1부: 전환 배경 기존 시스템의 4가지 문제① 긴 지연시간 : 데이터가 창고에 도착하기까지 20분~1시간 걸림.② 스토리지 부족 : 데이터가 계속 쌓여 오래된 데이터를 주기적으로 삭제해야 했음.③ 느린 쿼리 응답 : 적재 작업과 조회 작업이 같은 자원을 두고 경쟁해 서로 성능을 떨어뜨림.④ 복잡한 적재 과정 : 데이터가 창고에 도달하기까지 거치는 경로(파이프라인)가 지나치게 길고 얽혀 있음.기존 파이프라인의 경로여러 원본 DB → CDC(변경분 추출) → Kafka(..

오늘 벌어진 일https://app.notion.com/p/MVP-3b8bd1c1726c8026a0f2edfbc14c53f1 MVP 프로젝트 개인 회고 | Notion@6 CAN DO IT!app.notion.com1. 발표를 함주요 피드백:잘한 점목표, 전략 정합성: 7.4프로 앱 설치 감소 → 광고비 x, 기존 유저 체류 늘리기 겨냥경쟁사 분석: 정확한 경쟁사, 자체 기준으로 비교경쟁사 분석이 prd에 없으면 안 된다! 상위기획서-경쟁사 분석 많이a/b test 설계 완성도ai 태깅로직 구체적 리서치 (문장단위 판단 멀티라벨 엣지케이스)주요 개선점voc 리뷰 중에 비율 적은데 왜 데스크리서치, 설문으로 방향 틀었음?’문제의 크기보다~’ = 가장 큰 문제보다 가장 쉬운 문제 골랐다고 들릴 수 있음⇒ 비..

오늘 벌어진 일1. 기획 명세서, 기능 명세서 수정주요 수정 사항:1) 예외 처리 vs. 엣지 케이스Problem: 분류 오래 걸림 Why? 예외 처리, 엣지 케이스 명확한 차이를 몰랐음Solution: 튜터님께서 이 구분이 그렇게 중요한 게 아니라고 하심. 중요한 건 이런 비정상적/예외적 상황에 어떻게 대처할 것인지. → 예외 처리는 오류, 엣지 케이스는 오류는 아니지만 드문 케이스로 정리함. 2) 표현 통일(키워드, 축, 카테고리 등등...)2. 중요한 추정(태깅 오류 관련)Problem: 1,2차 MVP에서 태깅은 되었는데, 하이라이트 표시가 안 되었던 경우 있었음.Why?(Probably..) 1) 태깅 시 원문에서 그대로 문장을 가져온 게 아니라 재구성, 요약했을 가능성 → 그래서 원문에 하이..

오늘 벌어진 일1. 3차 MVP를 받음. 태깅 품질 많이 개선됨.수정 성공 주요 사항:2차 MVP 태깅 오류 일부 개선됨. 1) 태깅 안 되던 것 → 태깅 됨2) 오분류 → 비교적 잘 분류3) 태깅에서 배제되는 리뷰 없이 모두 필터링됨 Problem: 태깅, 하이라이트 완벽하지는 않음1) 하이라이트 안 되는 경우 있음(사전에 있는 단어임에도)2) 오분류(e.g. '입구 표시' 를 위치로 잘못 태깅)3) 하이라이트가 단어에만 되는 경우 있음(대부분 문장이나 어구에 하이라이트 잘 됨)Why? i don't know either.... 도저히 알 수가 없음. 각 오류가 일부 리뷰에서만 발생해서 더욱 모르겠음.Solution: 해결챌은 아니고 대처 → MVP 이후 태깅 고도화하기로 결정 Try: 기능명세서 + ..

오늘 벌어진 일1. 2차 MVP를 받음. 여전히 동일한 태깅 문제 발생.수정 성공 주요 사항:1) 블라인드 리뷰 제외됨.2) 사진 안 깨짐3) 로딩 빠름(배치 처리로 변경해서) Problem: 태깅 품질 여전히 나쁨1) 태깅되어야 하는데, 태깅이 안 됨2) 태깅 안 돼야 하는데, 태깅되어 버튼 선택 시 노출되어버림(e.g. '정위치에 없어서'를 숙소 위치로 오분류)3) 리뷰가 아예 태깅에서 배제됨(=리뷰가 어떤 리뷰에도 필터링이 안 됨)Why? 문제 1,2의 경우, 사전 기반 분류 vs. 맥락으로 판단 사이에서 기능명세를 상세히 안 했기 때문.문제 3의 경우 원인을 도저히 모르겠음.Solution: 기능명세서를 claude 기반으로 전면 수정.AI로 작성한 기능명세서 주요 수정 사항:- 소제목별로 분류됨..