News-Cookie!의 아키텍처 설계

이번에 Langchain을 공부해볼겸 새로운 토이 프로젝트를 기획해보게 되었다. 나름 재미있고 도전적인 프로젝트가 될 것 같아서 조금 설레기도하고 걱정도 된다. 여러 사람들이 재밌게 사용해주면 좋겠다(이왕 이걸로 돈도 많이 벌면 좋겠땅 히히힣)

News-cookie??

사용자가 던진 질문에 따라서 뉴스를 요약해주는 웹 프로그램.

기존 AI가 넘겨주는 답변보다 조금 더 양질의 데이터를 얻고싶어서 기획하게 된 프로젝트이다. 

 

News-Cookie의 시스템 아키텍처

큰 시스템의 아키텍처는 위와 같다. 

 

하나하나씩 뜯어보자!

NEXT.JS (FRONTEND + BACKEND )

웹 개발 프레임워크는 Next.js를 선택했다. 이유는 아래와 같다.

 - 1인 개발로 진행되는 만큼 서버를 따로 구축하는 것은 비용, 유지보수, 관리 측면에서 사치이다. (ex. AWS, Docker, Nginx, Spring은 관리하는데 비용도 들어가고 각각 관리해야한다.)
- Front와 Backend모두 한 프레임 워크 안에서 해결할 수 있다.

- Vercel에 배포하기 최적이다.(vercel이 next.js를 만들었기 때문에 github의 main branch에 merge하기만 하면 배포가 되는 구조)

 

 

SEO, Tracking

Google, naver SEO를 사용하기로 했다.

뭐 이건 검색엔진에 나왔으면 하니까 당연한사실 

우선 SEO를 등록하는 것은 정말 중요한데 내가 만든 서비스의 news-cookie라는 이름은 나만 안다. 즉 모두가 다 아는 cookie, news와 같은 키워드로 검색이 되게 하려면 SEO세팅은 필수

 

vercel Analysis

사용자가 몇 명이나 들어오는지 분석은 정말 중요하다. 하지만 그렇다고 해서 지금 당장 logging layer를 프로젝트에 포함시키는 것은 위험하다. 이 프로젝트가 망할지 안망할지 모르는데 무작정 로그를 넣는건 좋지 않다는 판단이다. 나중에 사용자가 늘어나면 당연히 로깅시스템을 넣어야 하겠지만 초기 분석을 위해선 vercel Analysis를 추천한다. 하루에 몇 명 들어왔는지 볼 수 있어서 편리하다.

 

AI-Agent

LangChain을 사용하는 이유

- 써보고싶어서
단순하다 요즘에 인기라서 써보고싶었다. 애초에 LangChain을 쓰기 위해 기획한 프로젝트이다. 

 

- 특정 사용자에게 특화된 서비스를 제공하고 싶어서
우선 LangChain 은 AIModel + harness와 같다. 내가 어떤 하네스를 씌울지 정하는 것이다. 나는 소식을 빠르고 가볍게 보고싶은 사용자들을 위해 이 서비스를 기획했다. 애초에 내가 AI소식 찾아보고싶어서 기획한 프로젝트이기도 하다.

 

tavily

내 AI서비스의 주요 harness가 될 API이다. 

AI가 읽기 좋게 본문을 크롤링하고 핵심만 요약해서 넘겨준다. 

뉴스 전용 검색모드가 있어서. 최신 외신 뉴스를 잡는데 특화되어 있다.

그리고 매달 1000회 무료로 제공해준다.(무료가 짱이야)

 

Supabase

해당 서비스는 쿠키라는 이름의 AI Token 을 소비하기 때문에 회원제가 필요하다. 

회원이 있어야 개별 토큰 관리가 되기 때문이다. 그러니까 로그인 기능은 불가피하다.

 

Google oAuth
종종 웹 사이트를 돌아다니다보면 "google로 로그인"을 확인할 수 있다. google의 계정을 로그인할 때 사용할 예정

 

그럼 이제 유저의 정보를 저장할 저장소가 필요하다.

 

RDBMS 

관계형 테이블로 구성했다. 우선 명확한 사유가 있는데, 바로 ACID즉 원자성을 지키기 위해서다.

이 시스템에는 결제라는게 들어가있다. 토큰을 충전하는 과정이나 토큰을 사용하는 과정에서 문제가 발생했다면 우리는 문제가 발생하기 이 전으로 돌아가야만 한다. 즉 결제과정, 토큰 사용과정을 트랜잭션으로 묶어서 관리해야한다.

 

위 그림은 DB의 관계를 나타낸다.

payment_history의 polar_order_id같은 경우 polar서비스에서 가끔 결제 성공을 두 번씩 쏴주는 경우가 발생한다. 즉 이런 경우 실제로 유저는 1번 충전했는데 결과는 2번충전한 것과 같은 결과가 나오게 된다. 그러면 운영자 손해니까 UNIQUE 즉, 유일한 값으로 만들어서 중복 호출을 막도록 하자

 

token_usage_logs테이블의 경우 검색하는 유저가 많아질 수록, 로그 값이 많아지게 된다. 이때 UUID를 사용하게 되면 데이터가 들어올때마다 DB내부의 인덱스 트리가 뒤죽박죽 꼬인다. 인덱스 용량, 속도를 위해서 순차로 증강하는 bigint를 사용하기로 하자.

 

약간의 설명을 덧붙이자면 

MySQL은 클러스터드 인덱스를 사용한다.

즉 디스크 상의 실제 데이터 정렬 순서 = PK 순서이다.

여기에 UUID처럼 무작위 값을 PK로 넣으면, 새로운 데이터가 삽입될 때마다. 디스크 중간 파트를 헤집고 들어가야해서 page Split현상이 일어나고 성능이 떨어지게 된다. 그래서 MySQL에서는 순차적인 Auto_increment를 쓰곤한다. 

 

PostgreSQL은 힙테이블을 사용한다. 

PK를 생성한다고 해서 실제 데이터가 그 순서대로 디스크에 정렬되지 않는다.

즉 UUID로 생성을 한다고해서 MySQL처럼 디스크 중간에 데이터를 낑겨 넣는 수고는 하지 않아도 된다. 

 

Heap구조는 디스크의 빈 공간에 들어오는 순서대로 아무렇게나 저장한다. PK는 그 데이터가 어디 있는지 주소가 가리키는  B-tree이다.(백엔드 개발자 단골질문인 B-tree맞다)

PostgreSQL은 MySQL처럼 UUID를 써도 데이터를 삽입할 때 성능이 크게 떨어지지 않으나, PK 인덱스 트리(B-tree)는 업데이트가 되어야 한다. 값을 넣을때마다 변경이 되야하는건 매한가지 이다. UUID를 사용하면 인덱스 노드가 무작위로 쪼개져서 인덱스 크기가 커지고 메모리 효율이 떨어지게되지만 bigint는 인덱스 트리 항상 우측 끝에만 노드가 추가되기때문에 메모리 방어가 잘된다. 
그리고 UUID는 16바이트거나 혹은 문자로 저장시 36바이트의 용량이 필요하지만 bigint는 8바이트면 된다. 만약 데이터가 수백만 건 쌓이면 인덱스 용량 차이만 몇 배가 날 것이고 이는 DB조회 속도에 영향을 끼친다.

 

news_snapchat 테이블은 다른 테이블과 다른데 바로 JSONB데이터 타입을 가지고 있다는것이다.

RDBMS를 사용해야하는 이유는 결제와 같은 민감한 정보를 다루기 때문에 원자성이 꼭 필요하다는 것, 그리고 트랜잭션으로 결제, 토큰 사용과 같은 작업을 묶어야하기 때문인데 new_snapchats은 그 목적과는 거리가 멀다.

이 테이블은 AI Agent가 외부 API(Tavily)를 통해 실시간으로 스크래핑한 뉴스 원천 데이터(Raw Data)를 적재하기 위한 일종의 로그 시스템(Log System) 및 캐싱 레이어에 가깝다.

유저의 검색 요청 쿼리와 그에 대응하는 AI의 뉴스 수집 결과를 이 테이블에 저장하는 핵심 이유는 다음과 같다.

 

첫째, 데이터의 비정형성과 확장성 확보이다. 언론사마다 뉴스 데이터의 구조(포맷, 메타데이터 필드)가 제각각 다르기 때문에, 이를 RDBMS의 고정된 컬럼으로 쪼개어 저장하면 스키마 변경 시 유연성이 떨어진다. 따라서 PostgreSQL의 고성능 바이너리 NoSQL 타입인 JSONB를 활용해 가변적인 로 데이터를 변형 없이 통째로 적재한다.

 

둘째, 검색 비용 절감을 위한 캐싱(Caching) 전략이다. 유저가 입력한 검색어의 의미나 키워드가 유사한 경우(예: *"ChatGPT 최신 소식"*과 "최근 OpenAI의 ChatGPT 소식은 어때?"), 매번 비용이 발생하는 외부 검색 API와 LLM을 중복 호출할 필요가 없다. 이 테이블에 누적된 과거 스냅샷을 기반으로 유사도 검색을 수행하여 캐싱된 데이터를 즉시 반환함으로써, 시스템 응답 속도(Latency)를 극대화하고 AI API 호출 비용을 획기적으로 절감할 수 있다. 하지만 일단은 캐싱은 사용하지 않을 생각이다. 일단 유저가 모일지 안모일지도 모르는데 덥썩 캐싱부터 수행하는건 아니라고 생각하기 때문(물론 개발 포트폴리오라면 무조건 붙히자)

 

셋째, 프롬프트 고도화를 위한 디버깅 및 분석 로그 역할이다. 실시간으로 에이전트가 어떤 데이터를 수집했고 LLM이 이를 어떻게 요약했는지 추적함으로써, 환각 현상(Hallucination)을 방지하고 시스템 프롬프트의 정확도를 지속적으로 모니터링하여 서비스를 고도화하는 소중한 피드백 루프로 활용된다.

 

---

이로써 아키텍처 글이 완성되었다. 오랜만에 개발 지식을 끄집어낸것 같은 기분이다. 역시 아키텍처 설계는 너무나도 중요해 

다음 글은 아마도 핵심 로직이 어떤식으로 이루어지는지 구성할 것 같다.