풀스택

EasyPrompt 개발

오늘은 EasyPrompt(이지프롬)의 "확장 가능성"을 점검하는 것부터 시작해서, 실제로 부족했던 부분들을 하나씩 채워나간 하루였다. 큰 기능 하나를 만든 게 아니라, 서비스를 운영하는 데 꼭 필요했지만 미뤄뒀던 것들을 순서대로 정리한 느낌이다.

1. 시작: 프로젝트 현황 점검

먼저 지금까지 만든 EasyPrompt가 어떤 가치와 활용성을 가지는지 다시 짚어봤다. 결론은 이랬다.

• 핵심 가치는 "표준 서식이 없어서 매번 처음부터 만드는 업무 상황"에 빈칸 채우기 UX를 붙인 것
• 인프라가 Cloudflare 풀스택(Pages+Workers+D1)이라 운영비 부담이 거의 없어 확장이 쉬움
• 다만 관리자 도구가 덜 갖춰져 있고, 실사용 데이터가 전혀 없다는 게 약점

이 점검을 바탕으로 우선순위를 정했다: 관리 도구 완성 → 사용 데이터 확보 → 데이터 기반 콘텐츠 확장.

2. 관리자 프롬프트 폼 관리 UI

프롬프트는 관리자 화면에서 만들 수 있었지만, 정작 그 프롬프트에 들어가는 입력 필드(prompt_forms)는 DB에 직접 넣어야 했다. 콘텐츠를 늘리려면 매번 DB를 직접 만져야 하는 병목이었던 셈.

PromptFormsManager 컴포넌트를 새로 만들어서, 프롬프트 목록에서 "필드 관리" 버튼을 누르면 그 프롬프트의 입력 필드(라벨/placeholder/순서)를 바로 추가·수정·삭제할 수 있게 했다. 백엔드 API는 이미 만들어져 있던 걸 그대로 재사용했다 — 콘텐츠 운영 병목만 제거하면 되는 문제였다.

3. "어떤 프롬프트가 실제로 쓰이는가"를 볼 수 있게 만들기

관리자가 콘텐츠를 늘리고는 있었지만, 정작 어떤 프롬프트가 실제로 쓰이는지 알 방법이 없었다. histories(생성 기록)와 favorites(즐겨찾기) 테이블은 이미 쌓이고 있었는데, 이걸 집계해서 보여주는 화면이 없었던 것.

GET /admin/stats/prompts API를 하나 추가해서, 프롬프트별 생성 횟수·즐겨찾기 수를 관리자 목록에 표시하도록 했다. 새 인프라 없이 기존 테이블에 서브쿼리 카운트만 얹으면 되는 가벼운 작업이었다.

이 과정에서 재밌는 걸 하나 발견했다: 스키마에 view_count 컬럼이 처음부터 있었는데, 실제로는 어디서도 증가시키는 코드가 없어서 항상 0이었다. 죽은 컬럼이었던 셈. 나중에 이 컬럼도 살렸다(아래 5번).

4. 콘텐츠 확장 — "인사(HR)" 카테고리 신규 추가

원래 계획은 "데이터를 보고 콘텐츠를 확장하자"였는데, 막 배포한 직후라 데이터가 없었다. 이럴 땐 억지로 데이터를 기다리기보다, 기존 4개 카테고리(경영기획/마케팅/영업/일반사무)를 훑어보고 비어 있는 영역을 판단으로 채우는 게 낫다고 판단했다.

살펴보니 채용공고, 면접 평가, 합격/불합격 통보, 인사평가 피드백, 조직 개편 안내, 오프보딩처럼 "표준 서식 없이 매번 새로 쓰는" HR 실무 상황이 통째로 비어 있었다. 그래서 "인사(HR)" 카테고리를 새로 만들고 프롬프트 8개를 추가했다.

콘텐츠를 만들 때는 예전에 썼던 방식 그대로, 파이썬 스크립트로 제목 중복과 {n} 자리표시자 개수 = 입력 필드 개수를 assert로 검증한 다음 SQL을 뽑아냈다. 손으로 30개 넘는 INSERT를 짜다 보면 반드시 실수가 나오는데, 이 방식이 훨씬 안전하다.

5. 죽어있던 view_count 살리기

3번에서 발견한 문제로 돌아가서, view_count를 실제로 채우기 시작했다. 프롬프트 상세 조회(GET /prompts/:id) 시점에 카운트를 올리도록 했는데, 응답을 늦추지 않으려고 waitUntil로 백그라운드 처리했다.

이게 의미가 있는 이유: 생성 횟수와 즐겨찾기는 로그인한 사용자만 잡히는데, view_count는 로그인 여부와 상관없이 "프롬프트를 열어봤다"는 신호를 잡아준다. 나중에 프리미엄 기능을 어디에 도입할지 판단하려면 이런 전체 트래픽 신호가 필요하다.

6. 마지막 발견 — 생성 기록을 조회할 방법이 없었다

여기저기 훑어보다가 꽤 눈에 띄는 빈틈을 하나 더 찾았다. /generate를 호출할 때마다 로그인 사용자의 결과가 histories 테이블에 저장되고는 있었는데, 이걸 불러오는 API도, 보여주는 화면도 없었다. 즐겨찾기는 마이페이지에서 볼 수 있는데 생성 기록은 그냥 DB에 쌓이기만 하고 사라지는 구조였던 것.

GET /histories API를 만들고, 마이페이지에 "최근 생성 기록" 섹션을 추가했다. 프롬프트 제목, 생성일, 생성된 텍스트(3줄 미리보기), 복사 버튼으로 구성했다. 이제 사용자가 예전에 만든 결과를 다시 찾아볼 수 있다.

오늘의 흐름 요약

1. 프로젝트 가치/활용성 재점검
2. 관리자 프롬프트 폼 관리 UI 추가 (콘텐츠 운영 병목 제거)
3. 프롬프트별 생성 횟수/즐겨찾기 집계 API + 관리자 화면 반영
4. 데이터 없는 상태에서 판단으로 "인사(HR)" 카테고리 8개 프롬프트 추가
5. 죽어있던 view_count 컬럼 활성화 (전체 트래픽 신호 확보)
6. 사용자용 생성 기록(histories) 조회 기능 추가

모든 변경사항은 로컬 D1(wrangler dev)로 먼저 검증한 뒤 원격 D1/Cloudflare Workers에 배포했다. 특히 배포 직후 새 라우트가 잠깐 404를 내다가 몇 초 뒤 정상화되는 현상을 다시 한 번 확인했는데, 이건 예전에도 겪었던 Cloudflare 특유의 배포 직후 전파 지연으로 보인다.

다음 단계는 "프리미엄 기능을 어디에 도입할지"인데, 이건 오늘 살린 view_count/생성 횟수/즐겨찾기 데이터가 어느 정도 쌓인 뒤에 판단하기로 했다. 감으로 미리 설계하기보다, 실제로 사람들이 어떤 프롬프트를 많이 보고 많이 쓰는지 지켜보는 게 먼저다.