이번에는 거창한 주제 대신
작지만 끝까지 만들어서 배포까지 해볼 수 있는 서비스를 하나 정했다.
그렇게 시작된 서비스는 FortuneBear로 짓게 되었다.

서비스 아이디어

FortuneBear는 흔한 운세 서비스와는 조금 다르게 만들고 싶었다.
미래를 단정하거나 겁을 주는 말은 최대한 피하고
오늘 하루를 기준으로 이 정도는 조심해도 되겠다 정도만 말해주는 캐릭터로 정했다.

말투도 중요했는데 정확한 척하지 않고 틀릴 수도 있다는 여지를 남기면서 
괜히 진지한데 곰이라서 웃긴 느낌을 내보려고 했다.

프론트엔드 구성

프론트엔드는 순수 HTML, CSS, JavaScript로 구성했다.
프레임워크 없이 간 이유는 구조를 단순하게 유지하고 배포와 수정 과정을 빠르게 반복하기 위해서였다.

Netlify로 정적 페이지를 배포했고 메인 화면 + 결과 영역 + 후기 영역으로 구조를 분리하였다.
하루 최대 3회 사용 제한을 처음에 걸어놓았는데
내가 테스트하다보니 너무 적어서 7회로 늘렸다(chatgpt api키는 토큰사용량에 따라 요금 청구)

특히 결과를 바로 보여주기보다는 중간 문구가 있는것이 좋다고 판단했다.
“포춘베어가 생각 중이다…”라는 상태를 잠깐 보여준 뒤 결과가 나타나도록 연출했다.
작은 UX 요소지만 캐릭터 성격을 살리기 위해 넣은 부분이다.

백엔드(API) 구성

백엔드는 Node.js와 Express로 구성했다.
처음부터 복잡한 구조를 만들기보다는 API 서버로서 역할이 분명하게 드러나도록 설계하는 데 집중했다.

백엔드의 역할은 크게 두 가지였다.

첫 번째는 오늘의 리스크를 생성해주는 API다.
프론트단에서 버튼을 누르면 /api/risk로 POST 요청이 들어오게 된다. POST 방식은 태그 안에 내용을 담아 전달하는 방식이다.
서버에서는 OpenAI API를 호출해서 포춘베어 말투에 맞는 텍스트를 생성한 뒤 그대로 반환하는 구조다.

이때 단순히 결과만 받아서 전달하는 게 아니라 프롬프트 단계에서부터 규칙을 꽤 세세하게 잡았다.
예언처럼 보이지 않도록 하고 자극적인 단어를 쓰지 않게 제한하고, 1인칭으로 관찰하듯 말하도록 명시했다.

결과적으로 이 API는 생년월일과 태어난 시간을 입력하는 전형적인 운세 생성기라기보다는
말투와 기준이 고정된 텍스트 생성 API에 가까운 형태가 됐다.

두 번째는 사용자 후기를 저장하고 조회하는 API다.
이 부분은 처음 기획에는 없던 기능이었다.
프론트엔드를 어느 정도 완성하고 나서 서비스가 일방적으로 말만 던지는 구조보다
사용자가 한마디 남길 수 있는 통로가 있으면 좋겠다는 생각이 들었다.

그래서 기존 /api/risk만 있던 서버에 후기 관련 API를 추가했다.

• POST /api/reviews
  익명 닉네임과 후기를 받아 DB에 저장

• GET /api/reviews
  최근에 작성된 후기 몇 개를 조회

DB는 SQLite를 사용했다.
별도의 로그인이나 계정 개념 없이 익명 닉네임과 텍스트만 저장하는 구조라
가볍고 단순한 파일 기반 DB가 지금 단계에 적합하다고 판단했다.

배포는 Render를 사용했는데 백엔드 배포는 서버 배포이기 때문에 우리가 직접 눈으로 무언가를 확인할 수 있는 구조는 아니다.
프론트엔드와 분리된 순수 API 서버로 운영했고 Netlify에 올라간 프론트에서는 Render에 배포된 API 주소로만 요청을 보낸다.

이 과정에서 한 번 막혔던 문제가 있었는데, 후기 API를 추가한 뒤에도 /api/reviews가 계속 Cannot GET으로 나오는 상황이었다.
원인은 코드 문제가 아니라 GitHub에 푸시만 하고 Render에서 Manual Deploy를 하지 않은 상태였다.
깃허브에 커밋하고 푸시만 하면 자동으로 배포되는줄 알고 계속 기다렸는데 Settings 안에 옵션에서 
auto check를 해야 커밋기록에 대해서 자동으로 빌드를 해주는 걸 좀 뒤늦게 찾아내서 살짝 헤매는 경험을 했다.

이 경험을 통해 로컬 코드, GitHub 코드, 실제 배포되어 실행 중인 코드가 항상 같지는 않다는 걸 다시 한번 상기하게 되었다..

처음에는 /api/risk 하나만 있는 단순한 서버였지만 후기 기능을 추가하면서
사용자 피드백을 받는 구조로 추후 업그레이드할 수 있을 것 같다.
아마 다음에는 PostGRE SQL을 이용해서 한번 도전해볼 것 같다.

GPT API 프롬프트 설계

처음에는 결과가 너무 자극적으로 나오는 문제가 있었다.
교통사고, 큰 위험 같은 표현이 자주 나와서
사용자에게 부담이 될 수 있겠다는 생각이 들었다.

그래서 프롬프트를 다음 기준으로 다시 설계했다.

• 예언하지 않는다

• 사고, 재난, 불행 같은 단어 사용 금지

• 1인칭 화법

• 단정하지 않고 관찰하듯 말하기

• 선택처럼 제안하기

지금 구조의 한계와 정리

현재 후기 DB는 SQLite 파일 기반이다.
Render 무료 플랜 특성상 서버가 재시작되면
DB가 초기화될 수 있다는 한계가 있다.

이 부분은 의도적으로 남겨두었다.
지금 단계에서는 영구 데이터보다
구조를 설계하고 설명할 수 있는 상태가 더 중요하다고 판단했다.

다음 단계로는 Supabase나 PostgreSQL로
후기 저장 구조를 이전할 계획이다.

오늘 정리

FortuneBear를 만들면서 느낀 건 기능 하나를 만드는 것보다 왜 이렇게 만들었는지를 설명할 수 있는 상태가 훨씬 중요하다는 점이었다.

아직 작은 서비스지만 아이디어 → 구현 → 배포 → 문제 해결까지
전체 흐름을 직접 경험해봤다는 점에서 의미 있는 기록으로 남기고 싶다.