안녕하세요 사실 귀찮은 건 아니구요 머리 한 움큼 쥐어뜯으면서 개발했습니다 렛츠고 문제는 그렇게 시작됐습니다 ??? : 경제 리포트 서비스에 리포트만 있으면 뭐 앱에 들어오나요 바로 설득돼서 무슨 기능 넣을까 하다가 생각한 게요약된 뉴스 푸시 알림 기능입니다 그래도 사실 막 어렵진 않았습니다. 이미 뉴스 크롤링과 요약 모듈이 존재했거덩요 문제는 FCM 가장 중요한건 기기마다 할당되는 FCM 토큰을 어떻게 관리할지였는데, 사실 뭐가 어렵냐고 생각할 수도 있습니다 그냥 유저 테이블에 필드 하나 추가하면 되는거 아니냐고요? 네 맞습니다. 근데 우리 서비스는 유저 테이블이 없어요 간단한 서비스 만들려고 유저 관리도 안하고 인증도 안하고 그래서 생각한 방법이 이겁니다 앱 최초 접속시 UUID로 ID를 부여하고..

안녕하세요 저희 서비스 "BigPicture"는 매일 자동으로 여러 경제 지표와 뉴스를 크롤링하여 매주 경제 리포트를 생성해주는 서비스인데요 이거 리포트 어케 생성하는걸까요? 그러게요 사실 첨엔 LLM에 데이터 싹다 털어넣고 만들어줘! 하면 주는줄 알았는데 이딴 결과물이 나옴 눈앞에 산학프로젝트 성적 C+가 아른아른 거리는데요 마침 인프런 만우절 때 사놓은 1000원짜리 RAG 강의가 있어서 그걸 들어봤습니다 AI 에이전트로 구현하는 RAG 시스템(w. LangGraph)| 판다스 스튜디오 - 인프런 강의현재 평점 4.9점 수강생 7569명인 강의를 만나보세요. 랭그래프(LangGraph)로 구현하는 검색증강생성(RAG) 지능형 AI 에이전트! 이론부터 실전까지, 초보자도 쉽게 따라할 수 있는 핸즈..

안녕하세요. 리얼 허거덩거덩스한 상황인데요 문제는 그렇게 시작됐습니다. 저희 서비스 "BigPicture"는 매일 자동으로 여러 경제 지표와 뉴스를 크롤링하여 매주 경제 리포트를 생성해주는 서비스인데요 크롤링 시 모종의 이유로 실패해서 데이터를 수집하지 못한다면 큰일나겠죠~? 사실 또 저희가 크롤링 후 변환 로직에 LLM과 베타버전인 자바용 랭체인을 사용해서 예상치 못한 오류가 엄청 많았습니다. 그래서 생각해낸게... 크롤링 로직을 재시도 로직으로 감싸서 실행하자! 크 시작합니다 우선 파라미터로 메인 로직을 () -> ~~~ 로 넘겨줘야 할 것 같은데, 뭘 써야할까요? 찾아보니 Supplier라는 인터페이스가 있었습니다. 이런걸 함수형 인터페이스라 부르는데 대표적으로 Predicate입력값을 하나 받아..

꿈 아니었구요. 안녕하세요. 문제는 그렇게 시작됐습니다. 저희 서비스는 포인트 획득 / 소비 기능을 비관적 락인 네임드 락을 통해 관리하고 있는데요 Facade 계층으로 코드 갈아엎기안녕하세요. 문제는 그렇게 시작됐습니다. @Transactionalpublic void saveComment(String userId, Long diaryId, CommentRequest commentRequest) { Member member = getMember(userId); Diary diary = getDiary(diaryId); List acceptedMembers = friendChdockerel.tistory.com내용이 궁금하시면 위 글을 읽어보시면 됩니다. 근데 저는 이 네임드 락과 이벤트 기반 비동기 처리..

안녕하세요. 문제는 그렇게 시작됐습니다. @Transactionalpublic void saveComment(String userId, Long diaryId, CommentRequest commentRequest) { Member member = getMember(userId); Diary diary = getDiary(diaryId); List acceptedMembers = friendCheckService.getFriendMembers(diary.getMember().getUserId()); if (!diary.isWriter(member) && !acceptedMembers.contains(member)) { throw new UnauthorizedExcepti..

한 학기동안 열심히 후꾸루마꾸루 프로젝트를 말았는데요. 끝나고 나니까 개선할게 좀 보이더라구요. 저희 AI 기반 감정 케어 다이어리 서비스인 "토닥"은 포인트 로그를 조회할 수 있습니다. 포인트는 출석해도 주고, 일기 써도 주고, 댓글 써도 주고사용은 나무 성장 시킬 때 쓸 수 있습니다. 그만큼 분류 기준이 많은데, 로그가 많아지면 사용자가 분류기준으로 검색했을 때 시간이 좀 오래 걸릴 거 같더라구요. MySQL로 EXPLAIN 분석해보니 역시나 조회하려 하면 Full Table Scan이 발생하네요.비용이 상당합니다 아주. 근데 지금 로그에 여러 칼럼이 있습니다.user_id, point_type, point_status, created_at 이 있는데, 어떤 순서로 복합 인덱스를 적용해야할까요? ..