HAN STORY

💡 목표싹틔움 서버에 Kafka 를 도입해 메인서버와 알림서버 사이에서 데이터들이 성공적으로 주고 받을 수 있고자 했다.📚 메인서버 Kafka 설정KafkaConfig더보기@Configuration@EnableKafkapublic class KafkaConfig { @Value("${app.kafka-brokers}") private String kafkaBrokers; @Bean public KafkaTemplate kafkaTemplate() { return new KafkaTemplate(producerFactory()); } @Bean public ProducerFactory producerFactory() { Map produce..

📚 RabbitMQ특징프로토콜: AMQP (표준 메시징 프로토콜 지원)메시지 전달: Push 모델 기반. 브로커가 소비자에게 메시지를 적극적으로 전달.큐 중심 설계: 메시지가 큐에 저장되고, 소비자가 이를 처리하는 전통적인 방식. 메시지 삭제는 소비자가 처리 후 ACK(확인 응답)를 보내면 이루어짐.라우팅: Exchange를 통해 Direct, Topic, Fanout, Headers 방식으로 유연하게 메시지 라우팅 가능.구성: 단일 노드에서 동작 가능하며, 클러스터링 지원은 있지만 Kafka만큼 분산 시스템에 특화되지 않음. 메시지 보장: 메시지 확인 및 재전송 메커니즘으로 높은 신뢰성 제공한다.사용 사례작업 큐 관리: 예를 들어, 사용자 등록 후 환영 이메일 전송, 이미지 변환 작업 등 비동기 작업..

🌱 개요싹틔움 메인서버에서 알림 기능을 구현하는 서버를 따로 분리해 MSA 방식으로 구현하고자 했다. 🌱 왜 굳이 서버를 분리할까?1. 독립적인 확장성알림 기능은 사용량이 급격하게 늘어날 수 있는 부분이다. 그렇기 때문에 MSA 로 분리하면 알림 서버만 별도로 스케일 업/아웃할 수 있어 유연성이 증가한다. 2. 장애 격리알림기능에 트래픽이 몰리거나, 카카오 등 외부 API 알림 기능을 구현할 때 이 기능에서 문제가 생겨도 메인 서버에 영향을 주지 않아 안정성이 증가한다. 3. 독립적인 배포 및 개발알림 서버는 다른 주기로 배포하거나, 다른 언어나 프레임 워크로 개발이 가능해진다.  4. 유지보수 용이성관심사가 명확하게 분리되어 집중적으로 관리할 수 있고 다른 팀원들과 협업시에도 수월하다. 코드베이스가..

✔️ TouchableOpacity, ...styles Work Travel  header 에서 onPress 를 활용해서 work 와 travel 의 상태를 true 로 저장시켰다.이 상태값을 활용해서 이후에 placeholder, list 들을 상태값에 따라 다르게 보여지게 한다. styles 앞에 ... 을 붙이면 기존 객체를 그대로 가져와서 새로 추가하는 내용만 수정한다는 뜻이다. ✔️ TextInput TextInput 의 다양한 prop 을 이용해서 Customizing 해주었다.완료 버튼을 done 으로 바꿔주었다.onSubmitEditing 에 addTodo 함수를 연결해주었다. ✔️ Todo 저장const onChangeText = (payload) => setText(payl..

✔️ 날씨 불러오기expo install expo-location const getWeather = async () => { const {granted} = await Location.requestForegroundPermissionsAsync(); if (!granted) { setOk(false); } const { coords: {latitude, longitude}, } = await Location.getCurrentPositionAsync({accuracy: 5}) const location = await Location.reverseGeocodeAsync({latitude,..

✔️ React Native Components and apishttps://reactnative.dev/docs/components-and-apis Core Components and APIs · React NativeReact Native provides a number of built-in Core Components ready for you to use in your app. You can find them all in the left sidebar (or menu above, if you are on a narrow screen). If you're not sure where to get started, take a look at the following catreactnative.dev ✔️ ..

✔️ Application Structure 우리가 직접 코드를 짜는 곳은 JavaScript 와 Markup/Styling 이다.하지만 어플리케이션은 그 이외에 구조들이 필요하다.Android 같은 경우에는 나머지 부분이 Java 로 되어있고, IOS 같은 경우는 swift 로 되어있다.그렇기 때문에 우리가 앱을 만들 때에는 Java, X-code 등 환경세팅이 복잡하게 필요한 것이다.✔️ React Native 작동 원리기존에 ReactJS 같은 경우는 코드를 그대로 브라우저에서 실행하는 원리이지만,React Native 는 코드를 그대로 실행하는 브라우저가 있는 것이 아닌, ios 와 android 로 각 각 번역해주는 번역기 라고 생각을 해주면 된다.각 각의 ios 와 android 에 bridg..

📚 개요기존에 구현했던 방식인 아티클 생성 후에 태그들이 생성되어도 사용자 관심도를 계산하기 위해서 태그들간의 유사도를 계산하는 로직이 들어가지 않는 한 사용자가 그 전에 게시글과 상호작용을 하여도 관심도를 계산할 수가 없다.그렇다고 유사도를 측정하는 로직을 넣자니, 시간이 오래 걸리기 때문에 한계가 있었다. 📚 고민* 클러스터링 기반 접근 태그를 사전에 클러스터링해서 새 태그를 클러스터에 매핑. 사용자 관심도도 클러스터 단위로 관리 (?)세부 과정:초기 클러스터링:태그를 메인 카테고리(예: "스포츠")별로 나눠 클러스터 생성(예: "축구 클러스터", "농구 클러스터").Tag_Clusters에 저장.새 태그 처리:기존 클러스터와 비교 → 유사하면 배정, 아니면 Temp_Tags에 임시 저장.새벽에 ..

📚 Article 작성 로직 고민  💡 현재 로직:아티클 생성 (3.62s) → 태그 5개 및 아티클과의 연관성 분석 및 테이블 생성 (9.16s)   → 기존 태그들과의 유사도 분석 및 테이블 생성 (1m 30s) 문제: 시간이 많이 걸린다. 1. 우선 태그를 5개에서 3개로 줄여야겠다. ai 가 5개를 뽑으면서 태그가 너무 다양해지고 의미는 같고 단어만 조금 다른 태그들이 생겼다. 2. 연관성 분석을 꼭 해야할까? 라는 생각을 했다. 어차피 연관이 있는 태그를 ai 가 뽑아주는건데 그걸 수치화로 더 자세히 할 필요가 있을까. 3. 기존 태그들을 전체 조회하면서 생성된 태그들과의 유사도를 분석하고 저장하는 로직을 게시글 등록과는 분리시켜야겠다. 시간이 많이 걸리고 이는 점점 태그가 많아질수록 증가될..

📚 서비스 개요와 설계 목표⚡ 고민메인 카테고리만으로 글을 나열하면 사용자가 세부 관심사를 반영하기 어렵다. 예를 들어, "스포츠" 안에 "축구"와 "농구"가 섞이면 사용자가 원하는 주제를 필터링하기 힘들다. 나는 AI가 상세 카테고리를 동적으로 생성해 이를 해결하고자 했다.  Grok3 는 상세 카테고리를 초기에는 최대 5개로 제한하고, 최소 2개 글이 있어야 생성하도록 제안했다. 이는 콘텐츠 부족 문제를 피하면서도 유연성을 유지할 거 같지만 더 생각해봐야겠다.📚 상세 카테고리 설계와 문제 해결🚨 동적 상세 카테고리 도입상세 카테고리(태그)는 게시글당 5개까지 동적으로 생성된다. 나는 이를 AI가 글 내용을 분석해 자동으로 분류하는 방법을 생각했다.예를 들어, "손흥민 골 기록" 글은 "유럽축구"..