problem_solving/MarketRadar

2. 배포 이후 수행했던 것들

점심뭐먹지 2026. 3. 30. 04:27

0. 패치노트

더보기

2026-03-29

Added

- RSS 뉴스 수신 기능 추가 및 Vercel KV 기반 Rate Limiting 도입  
- DOMPurify 기반 HTML sanitize 적용  
- index.html에 DOMPurify 스크립트 추가  
Changed

- 프롬프트 수정/정확도 개선  
- AI 답변이 길어질 때 UI/CSS 표시 개선(긴 답변 대응)  
- Gemini 호출 5분 타임아웃(shutdown) 문제 수정  
- `/api/news` CORS allowlist 동작 수정  
- CORS 처리 리팩터링 및 에러 응답 개선

- 프롬프트 요청 비동기 promise로 수정, 병렬 요청으로 요청응답 속도 개선

Security

- Gemini 출력 렌더링 시 XSS 위험 완화(DOMPurify sanitize)


2026-03-28

Added (Project setup)

- 초기 커밋 및 프로젝트 파일 추가  

Added

- 2년 데이터 범위 지원(app.js)  (60일 이동평균선 분석에서 필요했음)
- Microsoft Clarity analytics 스크립트 추가(index.html)  

Changed

- 티커 표시 UI 개선(renderCards)  
- 차트 제목 표시 포맷 개선(통화 포함)  
- fetch 로직 변수명 정리(가독성)  
- 프롬프트 조건/임계값 조정(KRW/USD 관련 조건 포함)  
- Gemini 출력 토큰 상향(4096)  
- Gemini 모델/버전 및 엔드포인트 관련 변경(엔드포인트 설정에서 헤멤)  
- 에러 메시지 개선 및 CORS 지원 추가  
- 뉴스 RSS 기능 초기 추가  
- html 파일 구조 js, css 분리 및 리팩터링  
- Node.js 엔진 버전 24.x로 변경  - vercel에서 강제. 18버전 지원을 종료
- README 개편 및 프로젝트명 오타 수정  

 

최근 이틀간 Market Radar 프로젝트의 초기 배포 후 발견된 보안 취약점을 보완하고, AI 응답 속도 저하 문제를 해결하기 위한 작업들을 진행했다.

 

1. 주로 확인 했던 사항들 - 보안, 성능개선, UI

1-1. 보안(Security): 비용과 직결된 인프라 보호

AI API 모델(Gemini)은 호출당 비용이 발생하는 종량제 구조이기에, 악의적인 반복 요청이나 공격으로부터 서비스를 보호하는 것이 최우선 과제였다.

  • Vercel KV(Redis) 기반 Rate Limiting 도입
    • 문제: 동일 사용자가 짧은 시간 내에 '분석 버튼'을 연타하여 API 비용을 급증시킬 수 있는 리스크 확인.
    • 해결: Vercel KV(redis)를 활용하여 사용자당 요청 횟수를 제한하는 Rate Limit 로직을 구현했다. 이를 통해 무분별한 API 남용을 방지.
  • XSS 공격 방어 및 HTML Sanitization
    • 문제: AI 답변에 리치 텍스트를 지원하기 위해 HTML을 렌더링하는 과정에서 스크립트 주입(XSS) 위험성 발견.
    • 해결: DOMPurify 라이브러리를 도입하여 Gemini가 출력하는 모든 HTML 콘텐츠를 필터링(Sanitize). 보안을 위해 필요한 태그만 허용.
  • CORS 정책 강화
    • 문제: API 엔드포인트가 외부에서 중계 서버처럼 악용될 소지 확인.
    • 해결: /api/news 등 주요 엔드포인트에 Allowlist 방식의 CORS 처리를 적용하여 지정된 도메인에서만 접근 가능하도록 리팩터링.

1-2. 성능 개선(Performance): 사용자 경험과 안정성 확보

프롬프트가 길어짐에 따라 발생하는 타임아웃 문제와 느린 응답 속도를 비동기 처리 최적화로 해결했다.

  • 비동기 Promise 기반 병렬 처리 전환
    • 문제: 기존 순차적(Sequential) async/await 구조로 인해 전체 응답 시간이 지나치게 길어지는 병렬성 저하 문제 발생.
    • 해결: 프롬프트 요청 로직을 병렬 Promise 구조로 개편. 다수의 요청을 동시에 처리함으로써 체감 응답 속도를 5분 이상 증가하던 걸 5초대로 개선.

길면 12초까지 나오던 요청응답을 4초로 줄여버렸다.

  • Gemini 셧다운(Timeout) 이슈 해결 
    • 문제: 긴 프롬프트와 복잡한 분석으로 인해 Gemini API 호출이 5분 타임아웃에 걸려 강제 종료되는 현상 발생.
    • 해결: 요청 구조를 최적화하고 타임아웃 설정을 조정하여 긴 답변 생성 시에도 안정적으로 결과를 수신할 수 있도록 수정.

응답 텍스트 양에 상관 없이 프론트에서 안잘리도록 css 수정

  • UI/CSS 최적화
    • AI 답변이 길어질 경우 레이아웃이 깨지는 문제를 방지하기 위해 긴 텍스트 대응 CSS를 적용하고, 60일 이동평균선 분석을 위한 데이터 범위(2년치)를 확보하여 분석의 정확도를 항샹.

1-3. 주요 기술 스택 업데이트

  • Runtime: Node.js 24.x (Vercel 환경 최신 기준 준수)
  • Analytics: Microsoft Clarity 도입을 통한 사용자 행동 패턴 분석 시작
  • Infrastructure: Vercel KV, RSS News Feed Integration

2. 회고

소프트웨어 생명 주기에서 배포는 마지막이지만, 제품 타임라인에서 차지하는 비중이 가장 많을 수도 있다.

 

회사 다니며 신규 개발도 진행했지만, 라이브 서비스 및 장애대응도 자주 맡았었다.

프로덕트에 따라 개발까지 이르는 과정이 배포보다 긴 회사들도 있었지만, 안정적으로 서비스가 운영되는 회사의 경우에는 보통 개발보다는 라이브 서비스와 장애대응의 기간이 더 길어지곤 했다.

 

안타깝게도 업계에서는 라이브 서비스와 장애대응을 그닥 잘 쳐주지는 않는 느낌이었지만, 어찌되었든 상황에 따라서는 배포 이후의 환경이 중요할 수 있다. 보통 잘 만드는 회사들은 이 배포 이후의 환경들을 더 오래 맞닥뜨리게 된다.

 

빠르게 웹페이지를 프로토타이핑 해서 배포까지 경험을 했으니, 이 뒤의 단계는 배포와 운영에 대한 조치와, 경험, 그리고 서비스 고도화가 될 것 같다.

 

3. 이후의 계획

3-1. Escape from Vercel

기능을 더 붙이는 것도 좋지만, 일단은 Vercel을 벗어나려 한다.

Vercel을 벗어나려는 이유는 편하긴 하지만, 해상도가 높은 운영 분석등을 하려 하면 '요금제를 올리세요!'라는 과금정책을 유지중이기 때문이다. - 그리고 기본적으로 엣지 컴퓨팅이고, '알아서 다 해드립니다'라는 구조라 서버 구축에는 그닥 좋은 경험이 안된다는 걸 깨달았다.

풀스택으로 기술을 배우기는 했지만, 방향은 하나로 정하는 게 나을 것 같고. 백엔드 쪽을 더 심화하는 게 나을 것이라는 판단이 섰다.

 

3-2. 백엔드 고도화

서버리스를 뜯어고치게 된다면 자연스레 방향은 서버와 DB 구축으로 이어진다.

현재의 제미나이 답변 품질이 아주 믿을만 한지는 물음표가 찍히고 있다.

한정된 데이터를 야후 파이낸스의 API 호출에 의지하고 있기 때문에, 아무래도 API calling 횟수도 신경쓰인다.

 

때문에 RSS용 워커 도입을 통한 오라클 클라우드에서의 DB 구축과 프롬프트 향상을 위한 서버 구축 , 클라우드 플레어의 인프라 적용등을 진행할 예정이다.

 

한국은 연합뉴스 같은 곳에서 아직 무료로 RSS를 발행중인데, 아무래도 다른 시간대의 뉴스들이 더 필요한 지라 그런 RSS를 무료로 발행하는 곳이 얼마나 있는지를 조사중이다. 시간대 차이도 있거니와, 아무래도 한국 주식은 미국 증시 영향을 많이 받다보니 새벽에 뉴스가 들어오는 경우도 꽤 있는 것 같아서.

 

최종적으로는 도커나 k8s까지 도입을 해볼까 하는데, 일단은 오라클로 이사를 간 뒤에 마저 고민을 좀 해봐야 할 거 같다.

이런 건 역시 처음부터 아키텍처를 그리고 작업하면 편하지만, 경험해보고 나면 좀 더 그런 걸 잘 그릴 수 있게 될 거 같다는 생각이 든다.