코디챗봇 프로젝트

[Aura_Ai] [4편] GPT API를 활용한 서비스 설계

frontend-diary-log 2026. 2. 1. 22:01

📘 #4. GPT API를 활용한 서비스 설계 (심화편)

Aura_AI Day 13–14

“GPT를 붙인 게 아니라, 운영 가능한 AI 서비스를 설계했습니다”

안녕하세요.
Aura AI 프로젝트 Day 13–14 작업 기록입니다.

이번 단계에서는 단순히 GPT API를 호출하는 기능 구현이 아니라,
👉 실제 서비스 환경에서 안정적으로 동작하는 ‘추천 시스템 아키텍처’를 설계하는 데 집중했습니다.

많은 GPT 프로젝트가

“질문 → GPT → 답변 출력”

수준에서 끝납니다.

하지만 이 방식은 데모는 가능해도, 실서비스 운영은 불가능합니다.

그래서 저는 다음 질문부터 시작했습니다.

“GPT를 어떻게 붙일까?” ❌
“GPT를 어떻게 ‘서비스 안에서 통제’할까?” ✅

이 글은 그 설계 과정을 정리한 기록입니다.

✅ 1. GPT만 붙이면 왜 서비스가 망가질까?

GPT는 매우 똑똑하지만,
서비스 친화적인 도구는 아닙니다.

즉, 그대로 쓰면 반드시 문제가 발생합니다.

❌ 문제 1 — 응답이 텍스트라 UI 확장이 불가능

GPT 기본 응답:

오늘은 날씨가 추우니 패딩을 추천합니다...

이건 사람이 읽기엔 좋지만,

프론트엔드 입장에서는:

top 어디?
bottom 어디?
신발은?
이유는?

👉 구조화가 안 됨

결과:

카드 UI 불가능
스타일 분리 불가능
자동화 불가능

즉 프론트에서 매번 문자열 파싱 지옥 시작

❌ 문제 2 — GPT는 ‘상황’을 모른다

GPT는 다음을 전혀 모릅니다.

지금 2월인지 8월인지
서울인지 제주도인지
30도인지 0도인지

그래서 추천 품질이 랜덤해집니다.

패션 추천에서 날씨는:

👉 “옵션”이 아니라 “필수 조건”

입니다.

❌ 문제 3 — GPT는 느리고, 가끔 죽는다

실무에서 자주 발생:

응답 20초 이상 지연
API 타임아웃
500 에러

GPT가 멈추면?

👉 서비스 전체가 멈춤

이건 치명적인 장애입니다.

그래서 저는 결론을 내렸습니다.

GPT를 “기능”으로 쓰면 위험하다
GPT를 “하나의 외부 의존성”으로 통제해야 한다

✅ 2. 그래서 만든 최종 아키텍처

전체 데이터 파이프라인

[Frontend]
사용자 입력 + 위치 + 스타일
        ↓
[Backend API]
날씨 조회 + 캐싱
        ↓
프롬프트 생성
        ↓
GPT 호출 (JSON 강제 + timeout)
        ↓
JSON 응답 반환
        ↓
[Frontend]
JSON.parse → 카드 UI 렌더링

여기서 핵심은:

👉 GPT가 중심이 아니라, 파이프라인의 “한 단계”일 뿐이라는 것

입니다.

즉,

❌ GPT 중심 구조
✅ 서비스 중심 구조

로 설계했습니다.

✅ 3. 핵심 설계 결정 (왜 이 방식을 선택했는가)

이 부분이 면접에서 가장 중요한 포인트입니다.

① 프롬프트 빌더 분리

❌ 보통 하는 실수

# router 안에서 바로 프롬프트 작성
messages = [...]

이렇게 하면:

코드 지저분
규칙 수정 어려움
테스트 불가

✅ 제가 선택한 방식

services/prompt_builder.py

프롬프트를 “서비스 정책”으로 보고 분리했습니다.

💡 왜 좋은가?

추천 규칙 한 파일에서 관리
유지보수 쉬움
A/B 테스트 가능
비즈니스 로직 명확

👉 프롬프트도 코드 자산으로 관리

② JSON 응답 강제 (가장 중요 ⭐)

GPT 옵션

response_format={"type": "json_object"}

💡 왜 필수인가?

이 한 줄 덕분에:

BeforeAfter

텍스트	구조화 JSON
파싱 필요	JSON.parse
UI 어렵	카드/리스트 가능
불안정	안정

👉 이건 단순 편의 기능이 아닙니다.

🔥 실무에서 의미

프론트 개발 생산성 ↑
버그 ↓
데이터 계약 명확
타입 안정성 ↑

즉 협업 친화적 설계

③ 날씨 API + 캐싱

왜 캐싱했는가?

날씨는:

자주 바뀌지 않음
호출 비용 있음
응답 느림

그래서 10분 캐싱 적용.

💡 효과

API 비용 절감
체감 속도 향상
서버 부하 감소

👉 실무에서 “당연히 해야 하는 최적화”

면접에서 이거 말하면:

“아, 이 사람 실제 운영 생각했구나”

반응 100% 나옵니다.

④ timeout + fallback

timeout=20
except:
    return 기본 JSON

💡 왜 중요한가?

GPT 장애가 나도:

👉 서비스는 항상 응답

즉,

AI 실패 ≠ 서비스 실패

이게 바로 프로덕션 사고방식입니다.

✅ 4. 이 설계의 ‘진짜 장점’

여기가 핵심입니다.
면접관이 가장 좋아하는 부분입니다.

🚀 장점 정리

1️⃣ 확장성

추천 항목 추가 쉬움
카드 UI 자유롭게 변경 가능

2️⃣ 유지보수성

프롬프트/날씨/GPT 분리
각 모듈 독립 테스트 가능

3️⃣ 비용 절감

캐싱
불필요한 GPT 호출 감소

4️⃣ 안정성

timeout
fallback
위치 거부 시 기본값

👉 항상 응답하는 시스템

5️⃣ 협업 친화

JSON 데이터 계약
프론트/백 분업 쉬움

6️⃣ 실무 적합성

“데모용 GPT”가 아니라
“운영 가능한 AI 서비스”

✅ 5. 면접에서 이렇게 말하면 좋습니다 (실전 답변 예시)

Q. GPT 연동에서 가장 신경 쓴 부분은?

단순 API 연결이 아니라, 서비스 구조 안에서 통제하는 데 집중했습니다.
JSON 강제, 캐싱, timeout, fallback을 통해 실무 환경에서도 안정적으로 동작하도록 설계했습니다.

Q. 왜 JSON 응답을 강제했나요?

프론트에서 UI 자동화를 하기 위해 구조화된 데이터가 필요했습니다. 텍스트는 확장성이 떨어져 실무에 적합하지 않다고 판단했습니다.

Q. GPT 장애가 나면 어떻게 되나요?

timeout과 fallback JSON을 두어 항상 응답을 반환하도록 설계했습니다. AI 실패가 서비스 실패로 이어지지 않도록 했습니다.

Q. 프롬프트를 왜 분리했나요?

프롬프트도 추천 정책이기 때문에 비즈니스 로직으로 보고 서비스 레이어로 분리했습니다.

✅ 최종 결론

Day 14는

❌ GPT 붙이기
✅ GPT 서비스 설계

였습니다.

즉,

데모 개발자 → 실무형 개발자
로 사고방식이 바뀐 날이라고 생각합니다.