김세민
← 프로젝트 목록

웹 서비스

마케팅 운영 플랫폼

API는 정상인데 외부에서 접속이 안 되는 문제를 앱·프록시·방화벽 계층으로 나눠 추적하며, 데이터 조회 API를 인증·캐시·관리 화면을 갖춘 운영 서비스로 정리했습니다.

기간
2026.01 – 2026.04
역할
백엔드 API · 운영 관리자 · 권한 설계 · 협업 환경
구현·동작 확인
장애 추적 과정 · 재구성 예시
  1. $ curl -s 127.0.0.1:8000/health
  2. {"ok": true, "db": "connected"}
  3. $ tail -f /var/log/nginx/access.log
  4. 외부 요청이 도달하지 않음
  5. → 원인 분리: 앱 ✓ · 프록시 설정 · 방화벽
  6. $ sudo nginx -t && sudo nginx -s reload
  7. → GCP 인바운드 80/443 허용 규칙 추가

업무 배경과 해결 과정

  1. 배경

    마케팅 실무에서 반복되던 데이터 조회 작업을 일회성 스크립트가 아닌 재사용 가능한 서버 API와 운영자 모니터링 화면으로 구조화했습니다. 같은 조직에서 계층형 광고 운영 관리자의 권한 설계, 내부 업무관리 시스템의 협업 환경 정비, 마케팅 SaaS 기획도 함께 다뤘습니다. 2026년 1월부터 4월까지 진행했습니다.

  2. 어려웠던 점

    FastAPI의 /health 응답과 DB 연결은 정상인데, 외부 요청이 Nginx access log까지 도달하지 않았습니다. "서비스가 안 된다"는 현상만으로는 어디가 문제인지 알 수 없었습니다.

  3. 이렇게 풀었습니다

    애플리케이션 → 리버스 프록시 → 네트워크 방화벽을 별도 원인 계층으로 나눠 점검했습니다. 중복된 server_name 설정을 정리하고 nginx -t·reload 절차를 거쳤으며, GCP 인바운드 방화벽에 80/443 허용 규칙을 추가했습니다. 서버에서 No module named uvicorn 오류가 났을 때는 시스템 Python과 가상환경의 차이를 확인해 .venv/bin/python -m uvicorn으로 실행하도록 바꿨습니다.

전체 장애처럼 보이는 현상도 계층별로 나눠 좁혀 가면 원인에 빨리 닿을 수 있다는 것을 배웠습니다.

직접 만든 것

FastAPI·PostgreSQL 기반 조회 API에 API Key 인증, 캐시, 관리자 화면을 구성하고, 서버 외부 접속 장애를 애플리케이션·프록시·방화벽 계층으로 나눠 추적했습니다.

  1. 01

    식별자별 조회 엔드포인트

    조회 대상 식별자의 유형에 따라 서로 다른 처리 로직을 호출하도록 v1 조회 라우트를 나누고, 서비스 로직과 데이터 계층을 분리한 서버 구조를 만들었습니다.

  2. 02

    PostgreSQL 캐시

    캐시 테이블로 같은 대상의 중복 조회를 줄이고 최근 캐시 항목을 확인할 수 있게 했습니다. DB 초기화와 테이블 소유권 문제도 함께 점검했습니다.

  3. 03

    API Key 인증과 버전 분리

    v1 조회 API와 v2 관리자 기능을 분리하고 API Key 검증 엔드포인트를 구현했습니다. 키 유효기간은 기본 30일(환경변수로 변경 가능)이며 이용 기기 식별자 기준으로 키와 기기를 결합합니다.

  4. 04

    운영 관리자 화면

    /admin 화면에 조회 통계, API Key 발급·목록, 최근 캐시 30건을 보여 주도록 구현했습니다. /health는 서비스명, 버전, DB 연결 상태를 함께 반환합니다.

사용 기술Python · FastAPI · PostgreSQL · Nginx · GCP VM · Next.js · Supabase · Vue

같은 프로젝트에서 함께 다룬 작업

  1. 계층형 광고 운영 관리자

    설계·시안

    총괄 운영자 → 총판 → 대행사 → 셀러로 이어지는 4단계 조직의 권한·정산 요구사항을 역할 기반 관리자 도구로 설계하고 화면 시안을 만들었습니다.

    • 같은 메뉴라도 누가 누구를 조회·생성·수정할 수 있는지를 먼저 정의하고, 데이터 가시성과 액션 권한을 분리
    • 조직·역할·캠페인·정산 엔터티의 Supabase 스키마와 FK·배열 타입 의존성 검토
    • 대시보드·계정/권한·광고·슬롯/발주·정산 화면을 요구사항 → 권한 → DB 필드로 역추적할 수 있게 문서화

    Vue · Tailwind CSS · Supabase · PostgreSQL실서비스 연결과 운영 성과는 확인되지 않은 설계·시안 단계입니다.

  2. 내부 업무관리 시스템(ERP) 협업

    분석·협업

    고객·상품·영업·정산을 다루는 내부 업무관리 시스템(Next.js·Supabase)의 구조를 분석하고 협업 개발 환경을 정비했습니다.

    • App Router 페이지 구조, Supabase 연동 모듈, Vercel 배포 설정, SQL 마이그레이션 파악
    • main/develop/작업 브랜치와 PR 기반 흐름을 정리하고 .coderabbit.yaml로 CodeRabbit 리뷰 연동 검증
    • 설정 파일만 바뀐 PR에서 path filter 때문에 리뷰가 skip되는 경우를 확인
    • package.json 파싱 오류·Git short read 문제를 조사하고, Vercel + Supabase와 GCP/AWS 대안의 비용·구조 비교 검토

    Next.js · TypeScript · Supabase · Vercel · CodeRabbit시스템 화면은 기존 서비스의 기능 범위이며, 화면 전체를 직접 개발한 것은 아닙니다.

  3. 마케팅 SaaS 기획·프로토타입

    기획·프로토타입

    시중 마케팅 도구 4종을 비교하고, 탐색부터 성과 리포트까지 잇는 통합 워크스페이스를 기획해 HTML 프로토타입으로 만들었습니다.

    • 탐색 → 후보 저장 → 경쟁 분석 → 프로젝트 관리 → 추적 → 성과 리포트로 이어지는 사용자 흐름 설계
    • 초기 MVP의 탭 중첩과 출처 없는 KPI를 점검하고 "한 화면 = 한 데이터 목적" 원칙으로 재설계 방향 정리
    • 기획 배경·벤치마크·포지셔닝·MVP 범위를 대표 공유용 보고서로 정리

    HTML · CSS · JavaScript · Chart.js상용 출시, 사용자, 매출 성과는 없습니다.

  4. 홈페이지 유지보수 검토

    검토·계획

    호스팅 기반 회사 홈페이지의 관리 방식을 파악하고, Git 이력화와 문의 폼 보안 작업의 안전한 절차를 세웠습니다.

    • 호스팅 서버에서 Remote-SSH 개발이 제한되는 점을 확인하고, 로컬 Git 개발 후 FTP/SFTP로 올리는 흐름 제안
    • 대용량 PDF 때문에 GitHub push가 거부되는 원인을 분석하고 바이너리 이력 제외 전략 검토
    • 스팸 문의 정리와 CAPTCHA 서버 검증을 백업 → 저장 위치 파악 → 정리 → 폼 검증 순서로 계획

    스팸 정리와 CAPTCHA 적용 완료는 확인되지 않았습니다.

담당 범위
  • FastAPI 조회 API, API Key 인증, PostgreSQL 캐시, 관리자 화면 구현
  • Nginx·GCP VM 외부 접속 장애와 서버 실행 환경 오류 조사·대응
  • 광고 운영 관리자의 RBAC·데이터 모델·UI 시안 설계, 내부 시스템 구조 분석과 PR·코드리뷰 흐름 점검
처리 흐름
  1. API Key 검증

    요청 키와 이용 기기 확인

  2. FastAPI 라우팅

    식별자 유형별 조회 로직 호출

  3. PostgreSQL 캐시

    캐시 조회·저장으로 중복 조회 감소

  4. 관리자 확인

    /admin에서 요청·키·캐시 상태 확인

한계와 남은 과제
  • systemd 전환은 검토 단계

    nohup 재시작을 재부팅 시 자동 기동하는 systemd 서비스로 바꾸는 안을 검토했으며, 최종 운영 적용 여부는 확인되지 않았습니다.

  • 성능 수치는 적지 않음

    응답 속도, 성공률, 실제 호출량은 검증 로그가 없어 적지 않았습니다.

  • 공개 범위

    회사 내부 서비스라 회사명, 서비스명, 데이터 출처, 엔드포인트 경로 같은 세부 사항은 일반화해 적었습니다.