코딩관계론

왜 대어 IPO 자동화 프로세스가 필요할까?IPO(기업공개) 프로세스는 예비심사부터 승인, 청약, 상장까지 여러 단계를 거치며, 중요한 이벤트마다 투자자들의 관심이 쏟아집니다. 특히 시장에서 ‘대어(大魚)’라고 불릴 정도로 규모가 큰 종목은 더욱 주목받죠.하지만 이런 대어 IPO 종목을 찾고, 그 종목에 연관된 주주나 관련주를 빠르게 파악하며, 시점별로 쏟아지는 뉴스를 정리하기란 쉽지 않습니다.그래서 저는 대어 IPO에 관한 정보를 자동으로 추적하고, 해당 종목들의 단계별 소식을 인사이트 형태로 바로바로 뽑아내는 자동화 프로세스를 만들어보자는 아이디어를 떠올렸습니다.이를 위해선 다음 세 가지가 필수적이었습니다.대어 종목 식별관련주 파악뉴스/공시 모니터링 및 반응 평가처음에는 단순한 키워드 검색과 규칙 기..

주식 종목 자동 완성 기능 개선 및 Elasticsearch 활용기존에는 RDB(Relational Database) 기반으로 주식 종목 자동 완성 기능을 구현했으나, 이 방식에서는 오타 교정 기능이 기본적으로 제공되지 않기 때문에, 추가적인 비즈니스 로직을 개발해야 하는 부담이 있었다. 이에 따라 **Elasticsearch(이하 ES)**의 Fuzzy 검색 기능을 활용하여 보다 효율적인 자동 완성 시스템을 구축하기로 결정했다.또한, 향후 나스닥(NASDAQ) 종목까지 지원하게 될 경우, 대규모 데이터 처리를 위한 역색인(Inverted Index) 기반의 검색 시스템이 필수적이므로, 확장성을 고려하여 ES를 도입했다.1. 검색어 자동 완성 기능 벤치마킹우선, 주요 검색 시스템들이 자동 완성을 어떻게 ..

기존에는 뉴스 문서의 빠른 검색과 다양한 기능 제공을 위해 데이터베이스(DB)를 사용했으나, 성능과 확장성 측면에서 한계를 느껴 엘라스틱서치(Elasticsearch)를 도입하기로 했습니다.기본적으로 텍스트 검색은 대부분의 DB가 지원하며, 개발자가 직접 구현할 수도 있지만, 효율적이고 빠른 검색을 위해 전문 검색 엔진을 사용하는 것이 더 효과적입니다.1. 엘라스틱서치(Elasticsearch)란?엘라스틱서치는 검색과 분석을 위해 설계된 분산형 RESTful 검색 엔진입니다.Lucene 기반: 내부적으로 Apache Lucene 라이브러리를 사용해 텍스트를 색인하고 검색합니다. 강력한 전문 검색 기능을 제공합니다.분산 처리: 대규모 데이터를 효율적으로 처리하기 위해 여러 노드에 데이터를 샤딩(shardi..

시스템 구조 및 배경이전 시스템 설계에서는 뉴스 데이터를 처리하는 서버가 단일 인스턴스로 구성되어 있었습니다. 이 때문에 Java의 ConcurrentHashMap을 이용한 간단한 동시성 처리 방식만으로도 어느 정도 운영이 가능했습니다. 그러나 파이썬에서 GPT API를 호출하는 결과와 자바에서 GPT API를 호출하는 결과에 차이가 생기면서, 추가적인 처리 로직을 자바 서버 쪽에서 담당해야 했습니다. 이 변화로 인해 단일 서버가 감당할 수 있는 동시성 처리의 한계가 명확히 드러났습니다. 아래 글은 서버 스케일아웃(확장) 작업 중 발생한 여러 문제를 해결해 나가는 과정(트러블슈팅)에 대해 정리한 내용입니다. 기존 단일 서버 환경에서 처리하던 뉴스를 대규모로 확장하고, 각 단계별로 분산 처리를 도입하면서 ..

아래의 빨간색 버튼은 사용자가 특정 주식 정보를 갱신하기 위한 버튼입니다. 해당 버튼을 클릭하면 뉴스 업데이트가 진행되며, 서버에 정보 갱신 요청이 전달됩니다. 서버는 요청을 비동기적으로 처리하기 때문에 즉시 응답을 프론트엔드에 전송하고, 프론트엔드는 폴링(polling) 방식을 통해 갱신 완료 여부를 지속적으로 확인합니다.단순한 API임에도 불구하고, 실행 시간이 점차 증가하면서 DB 커넥션 문제(아래 이미지 참조)가 발생했습니다. 요약하면, 주식 정보 조회 시 DB 커넥션을 획득하는 과정에서 문제가 발생한 것으로 보입니다. 그러나 DB 커넥션에 문제가 있다면 다른 요청들도 영향을 받아야 하는데, 실제로는 정상적으로 조회되고 있어 의문이 생겼습니다. 이 동작방식의 간단한 요약도를 보면 주식의 정보 조회..

지금까지 에드센스 가입을 두 번이나 신청했지만 모두 거절당했다. 처음에는 사이트가 충분히 개발되지 않아서 거절된 줄 알았는데, 알고 보니 뉴스 링크 때문에 수익화가 승인되지 않은 것이었다.이 문제를 해결하기 위해 GPT를 활용해 원인을 분석해봤다. 결과적으로 두 가지 문제점을 발견했는데, 첫째는 트래픽 부족이었고, 둘째는 페이지에 포함된 외부 링크가 너무 많다는 것이었다. 여러 뉴스 중에서 필요한 내용만 선별해서 링크를 올린 것이었는데, 이렇게 많은 외부 링크가 에드센스의 정책에 문제가 될 것이라고는 예상하지 못했다. 앞으로는 화면을 재구성하고, 외부 뉴스 링크 대신 핵심 내용을 요약하거나 독창적인 내용으로 재구성하여 게시할 계획이다.이를 구체적으로 실현하기 위한 방안은 다음과 같다.0. Adfit 먼저..

앞서 사용했던 기술들을 바탕으로, 어디에서도 확인할 수 없는 기능이었던 시장의 테마를 실시간으로 추적해주는 ‘테마 맵’을 개발했다. 처음엔 단순히 시세 변동을 시각화하는 수준이었는데, 점차 발전시키면서 시장에서 주목받는 테마별 흐름을 한눈에 파악할 수 있도록 만들었다. 그 결과, 사용자들이 조금씩 접속하기 시작했고, 긍정적인 피드백도 늘어나는 추세다. 오랫동안 준비한 프로젝트라 그런지, 직접 만든 서비스에 사람들이 관심을 보이니 정말 기분이 좋다. 그런데 아직 해결해야 할 과제도 있다. 현재 테마 맵은 20분 전 가격 데이터를 기준으로 하고 있는데, 이 시간 차이가 생각보다 커서 실시간성에 대한 아쉬움을 느끼는 사용자들도 있다. 어떻게 하면 더 빠르고 정확한 데이터를 반영할 수 있을지 고민 중이다. ..

데이터를 적재하기 위해 대규모 배치 작업을 실행한 후, 검색 쿼리의 성능이 현저히 떨어지는 문제가 발생했습니다. 또한 다양한 데이터 오류도 함께 드러났습니다.이 중 가장 시급한 이슈는 쿼리 성능이었는데, 아래와 같이 특정 문서를 찾는 쿼리가 4초 가까이 걸리는 상황을 확인했습니다. 1. 쿼리 실행 계획(Explain) 확인문제가 되는 쿼리의 실행 계획을 확인하기 위해, 다음과 같은 명령어(explain("executionStats"))를 사용했습니다:이를 해결하기 위해서  먼저 어떻게 쿼리가 실행되고 있는지 궁금하여 다음과 같이 질의하하여 쿼리 실행 계획을 알아봤다. 아래의 명령어를 사용하면 쿼리의 실행계획을 분석할 수 있다.db.news.find({'stockCode': '437730', 'isRela..

1. 문제 상황현재 뉴스 패치 시스템은 AWS SQS(메시지 큐)를 통해 3개의 Lambda 함수가 뉴스 데이터를 처리하고 있습니다.그런데 뉴스 분석 과정에서 하나의 파티션에서 모든 작업을 처리하다 보니, 컨슈머 랙(Consumer Lag)이 급격히 증가하는 문제가 발생했습니다.해결 시도가장 먼저 고려한 방법은 파티션을 늘리는 것이었습니다. 하지만 동시성이 증가하면 자연스럽게 동일 데이터 접근 충돌 문제가 발생할 가능성이 커지므로, 이를 해결할 방법도 함께 고민해야 했습니다.3. 동시성 이슈 해결 방법 검토파티션을 늘린다면 여러 개의 Lambda가 동시에 같은 데이터에 접근할 가능성이 증가합니다. 이를 해결하기 위해 여러 가지 방법을 검토했습니다.1) 분산 락 사용Redis나 Zookeeper를 이용한 ..

1. 문제 정의: 테마 관련 뉴스 판별의 필요성주식 시장에는 AI, 2차전지, 신재생에너지, 원전 등 다양한 테마가 존재합니다.하지만 테마 키워드로 뉴스를 크롤링해보면, 정작 투자 의사 결정에 직접적인 도움이 되지 않는 ‘정보성이 없는 뉴스’들이 다수 섞여 들어옵니다.예를 들어,“원자력발전소” 키워드로 기사를 검색했더니, 원전 설비나 정책, 기업 동향이 아닌 단순 지역 소식(‘원자력 주변 축제’ 관련 기사 등)도 함께 크롤링되는 상황이 발생합니다.이는 결국 ‘테마 관련 투자 정보’로는 가치가 떨어집니다. 이처럼 “이 뉴스가 정말 테마와 관련 있는가?"를 정확히 필터링해내는 로직이 필요합니다.이를 위해 초기에 시도했던 두 가지 접근은 다음과 같습니다.간단한 규칙 기반 필터링특정 키워드 리스트(예: “원전”..

1. 문제 정의처음 뉴스 데이터를 크롤링할 때, 하나의 고정된 IP로 다수의 요청을 보냈더니 IP 제한에 걸려 원하는 데이터를 안정적으로 수집하지 못하는 상황에 직면했습니다. 이를 해결하기 위해 처음에는 두 가지 방법을 시도했습니다.2. 시도된 해결 방법2.1 프록시 서버 사용시도 배경: 크롤링 트래픽을 분산하기 위해 프록시 서버 IP를 활용하려 했습니다.문제점:비용 부담: 신뢰할 만한 프록시 IP 제공 서비스는 가격이 비쌌습니다.신뢰성 문제: 불안정한 프록시로 인해 데이터 수집의 안정성이 낮아졌습니다.2.2 네이버 API 활용장점: 네이버에서 제공하는 공식 API를 사용하면 안정적으로 데이터를 수집할 수 있었습니다.단점:날짜 제한: 특정 날짜 이후의 뉴스 데이터는 제공되지 않아 완전한 데이터 수집이 불..

1. 문제 상황매일 밤, 주식 Insight를 갱신하기 위해서는 여러 단계를 거쳐야 합니다:뉴스 데이터 크롤링외부 API 호출 (주식 정보 등)DB 적재 및 분석/가공매일 밤, 주식 Insight를 갱신하기 위해 여러 단계를 거치는 과정에서 우리는 다음과 같은 기술적 도전에 직면했습니다:뉴스 데이터 크롤링외부 API 호출 (주식 정보 등)DB 적재 및 분석/가공초기에는 동기적 HTTP 요청으로 직관적으로 처리했지만, 더 큰 규모와 빠른 처리가 요구되면서 새로운 아키텍처를 모색해야 했습니다.초창기에는 순차적(동기) HTTP 요청으로 처리했습니다. 이 경우,“동시에 큰 트래픽이 발생하지 않는다”는 장점“각 단계별로 순차성을 보장한다”는 직관적 이해도그러나 처리 시간이 오래 걸린다는 치명적인 단점이 있었습니다..