Study/Side Proejct / / 2025. 2. 19. 22:03

[Smart Ad] 프로젝트 소개 및 아키텍처 구성

🗒️ 개요

안녕하세요. 사이드 프로젝트를 하나 진행하려 합니다. 기존에 주력해온 Spring Boot의 주요 기능을 이번 기회에 더욱 깊게 학습하며, 코틀린을 사용해보지 않았던 만큼, 이번 프로젝트를 통해 새로운 언어와 기술을 이해하는 계기로 삼기 위한 것도 있고, 실제로 사용하기 위한 서비스이기 때문에 프로젝트를 진행하면서 지금까지 이론으로만 학습하던 부분에 대해 피부로 와닿도록 기술을 익히기 위한 게 주 목적입니다.

네이버 광고 API를 통해서 효율적인 광고 관리 시스템을 만드는게 프로젝트의 목표입니다.

❓ 고민점

사실 가장 큰 고민은 '어떤 기술을 선택할지', '학습 범위를 어디까지 잡을지' 이게 90% 였던 것 같습니다.

그래서 기준점을 잡기로 했습니다.

첫 번째, 인프라는 가장 단순하지만 HA 구성을 통해 단일 장애 지점(SPOF)이 없어야 한다.

두 번째, 모든 선택은 근거가 있어야 한다. 하지만 클라우드 환경을 경험하기 위해 최대한 클라우드 서비스를 사용한다.

위 2개의 기준점을 통해 아래의 아키텍처를 구성하게 되었습니다.

🎈 전체 아키텍처 구성

1. 프론트엔드 및 API 서버

서비스 선택: Kotlin + Spring Boot

  • 코틀린 학습이라는 목표와 가장 익숙한 기술을 통해 효율적인 서버 개발

주요 기능 :

  • 자동 입찰
  • 캠페인, 광고 그룹, 키워드 등록, 조회, 수정 및 삭제 기능
  • API 요청 생성 및 데이터베이스 기록을 통한 작업 관리
  • Naver AD API 호출 시 Rate Limit(429 Error)을 피하기 위한 Auto Scaling & Load Balancing

2. 데이터 저장소 (DB)

서비스 선택: Cloud SQL (MySQL)

  • RDB를 통해 데이터를 관리하고, GCP의 초기 지급되는 크레딧을 사용하여 비용 부담 ↓
  • 사용의 용이성, 유연성, 빠른 성능과 높은 안정성, 커뮤니티와 자료도 제일 활성화

3. 외부 API 호출 워커 (자동 입찰 및 시세 조회 처리)

서비스 선택: Cloud Run (별도 인스턴스)

  • Cloud Tasks 및 Kotlin과의 연동을 통해 API 호출 작업을 처리
  • 네이버 API 호출 이후 응답 결과를 데이터베이스에 저장, 사용자 설정에 맞춰 알림을 제공

4.작업 큐 / 스케줄링

서비스 선택: Cloud Tasks

  • HTTP 엔드포인트를 대상으로 작업 큐를 구성하며, 쉬운 딜레이 및 재시도 정책 설정
  • 사용자 캠페인 등록 시 주기적인 작업 메시지를 생성하고, Cloud Run 워커에 전달하여 Naver API 호출을 제어
  • GCP Cloud Pub/Sub과 비교하여 단순한 현재 작업에 적당하다고 판단되어 선택

5. 네트워크 분산 및 외부 API 호출 보안

  • Cloud Run 서비스는 VPC와 연결하여 외부 노출을 최소화하고 안전한 API 호출 환경을 유지
  • Cloud NAT 및 Secret Manager를 활용하여 외부 API 호출 시 보안을 강화

6. CI/CD 및 모니터링

CI/CD 파이프라인: Cloud Build

  • GitHub와 연동하여 코드 푸시 시 자동으로 이미지 빌드 및 배포
  • Cloud Logging 및 Monitoring을 통해 API 호출 실패와 서비스 상태 조회 가능

🌤️ 운영 시나리오 (전체 플로우)

  1. 사용자가 네이버 검색광고 API 키를 등록하고 특정 키워드에 최소, 최대 금액과 노출 순위, 한도를 설정
  2. 사용자 설정이 저장되면 API 서버는 자동 입찰 작업을 생성하여 Cloud Tasks에 작업 메시지를 전달
  3. Cloud Tasks는 설정된 주기에 따라 API 호출 워커로 요청을 전송하며, 워커는 네이버 API를 호출
  4. 네이버 API의 응답 데이터를 기반으로 결과를 데이터베이스에 기록
  5. 시스템은 Cloud Monitoring 및 Logging을 통해 모니터링

우선적으로 가장 필요하다고 느껴지는 부분만 구성했는데, 생각보다 서비스를 많이 사용하게 되어서 고민이 되기도 합니다. 앞으로 서비스 요구사항을 확정하고 Naver AD API를 분석하면서 계속해서 변경 될 가능성이 있기에 가장 간단한 프로토타입을 먼저 만든 뒤 점진적으로 개선 할 계획입니다.