카드 몇 장으로 시작한 MVP를 운영 도구로 바꾸기까지: 키워드 레이더의 다섯 가지 개선

동기들에게 처음 보였던 화면에서 점점 개선되고 있습니다.
좌측 사이드바에 메뉴가 더 구성되었고, 세부적인 기능을 추가했습니다. 스터디장 류웅수님의 프로세스를 고민하면서 제가 반영할 부분을 취사선택하고 있습니다.
저 보다 먼저 고민한 분들의 흔적은 항상 의미있으니까요. ^^

블로그 글의 결과물도 좋아졌습니다. 이건 다음 번에 올리도록 하겠습니다.

📖 소개

키워드 레이더의 초기 화면은 기능을 확인하기에는 충분했지만, 글감과 원고가 계속 쌓이고 실제 API 비용이 발생하는 서비스로 쓰기에는 보완할 부분이 있었습니다. 카드 몇 개를 보여주는 화면은 데이터가 적을 때는 편하지만, 수백 건이 되면 과거 자료를 찾기 어려워집니다. 생성한 이미지도 원고와 떨어져 있으면 실제 블로그에서 어떻게 보일지 판단하기 힘들었습니다.

이번 작업에서는 화면을 보기 좋게 다듬는 데서 멈추지 않고, 사용자가 무엇을 눌렀을 때 어떤 데이터와 비용이 움직이는지까지 확인했습니다. 제가 대화에서 불편한 지점을 구체적으로 짚었고, Codex가 관련 코드와 데이터 흐름을 찾아 수정했습니다. 구현 결과는 설계, 구현, 검증을 구분해 확인했습니다.

다룬 내용은 다섯 가지입니다. 대규모 콘텐츠 보관함, 원고 안의 이미지 미리보기, 대표 이미지 제목 합성, 해시태그 입력 방식, 그리고 키워드를 누르기 전에는 AI 생성 비용이 발생하지 않도록 막는 작업입니다.

🛠️ 진행 방법

1. 카드형 보관함을 검색 가능한 25줄 목록으로 바꿨습니다

처음에는 글감과 작성한 글이 넓은 카드로 나열됐습니다. 데이터가 네 건일 때는 문제가 없었지만, 관심 분야와 키워드가 달라지고 원고가 수백 건 쌓이면 제목조차 기억하기 어렵다고 생각했습니다. 그래서 한 화면의 보기 좋은 카드보다 나중에 다시 찾을 수 있는 구조를 먼저 요구했습니다.

Codex는 카드 보기를 주 화면으로 유지하기보다 목록형을 기본으로 두고, 검색과 카테고리·상태·기간 필터, 최근 저장·수정순 정렬, 25건 페이지네이션을 적용하는 방향을 제안했습니다. 저는 이 구조를 선택했고 저장한 글감과 작성한 글에 반영했습니다. 항목을 선택하면 오른쪽 상세 패널에서 내용을 확인하고, 원고 작업은 더 넓은 화면으로 이어지도록 동선도 나눴습니다.

여기서 중요한 판단은 화면에서 25개만 자르는 것과 DB에서 조건에 맞는 25개만 조회하는 것은 다르다는 점이었습니다. 현재 MVP 화면을 단순하게 유지하면서도, 상용화 단계에서는 서버 검색과 페이지네이션으로 옮길 수 있는 기준을 함께 잡았습니다.

2. 이미지 5장을 원고 위와 본문 안에서 동시에 확인하게 했습니다

기존 화면에서는 이미지 5장이 원고 아래쪽에 따로 모여 있었습니다. 마음에 들지 않는 이미지를 다시 생성하는 기능은 있었지만, 이미지를 확인한 뒤 원고를 읽으려면 화면을 오가야 했습니다. 본문 속 배치 결과는 HTML을 내려받기 전까지 알 수 없었습니다.

최종 화면 순서는 원고 정보, 가로 이미지 5장, 옵시디언 저장 영역, 이미지가 삽입된 본문으로 정리했습니다. 가로 이미지에는 다운로드와 재생성 기능을 그대로 남겼고, 같은 이미지들을 본문 문맥에 맞는 위치에도 표시했습니다. 본문 이미지는 흐름을 끊는 캡션 없이 보여주도록 했습니다.

이 과정에서 제 요구를 처음부터 정확하게 반영하지 못해 이미지가 본문에만 들어가고 가로 5장 영역은 빠지는 시행착오가 있었습니다. 이후 배치 순서와 유지해야 할 기능을 문장으로 다시 고정한 뒤 구현과 브라우저 검증을 진행했습니다. 원고 열기 버튼도 화면 아래까지 이동하지 않아도 되도록 상단 접근 동선으로 조정했습니다.

3. 대표 이미지 제목은 배경을 가리지 않도록 다시 다듬었습니다

첫 번째 이미지는 블로그 대표 이미지이므로 글 제목을 중앙에 넣기로 했습니다. AI가 한글까지 그리게 하지 않고, 배경 이미지를 만든 뒤 프로그램에서 최종 제목을 합성했습니다. 제목은 단어 단위로 줄을 나누고 가로·세로 중앙에 배치했습니다.

처음 적용한 짙은 초록색 제목 박스는 글자를 잘 보이게 했지만 이미지의 상당 부분을 가렸습니다. 박스를 제거하고 폰트 크기를 약 10% 줄인 뒤 그림자로 가독성을 확보하는 방향으로 바꿨습니다. 여기서 다시 문제가 생겼습니다. 화면용 CSS의 text-stroke와 다운로드 합성용 Canvas의 strokeText가 동시에 들어가면서 글자 안쪽에 검은 선이 보였습니다.

외곽선을 요청한 적이 없는데 가독성을 높이겠다는 판단으로 불필요한 스타일을 추가한 것이 원인이었습니다. 두 경로의 외곽선을 모두 제거하고 흰색 글자 바깥의 부드러운 그림자만 남겼습니다. 화면 외곽선은 0px, 다운로드 합성의 외곽선 호출은 0회로 회귀 검사에 고정했습니다. 수정된 버전은 커밋과 push, 운영 배포까지 마쳤습니다.

4. 해시태그는 별도 버튼 없이 스페이스바로 완성하게 했습니다

추가 키워드 입력란은 처음에 스페이스바가 제대로 동작하지 않았고 Enter를 눌러도 키워드가 등록되지 않았습니다. 사용자가 무엇을 해야 하는지 화면만 보고 이해하기 어려운 상태였습니다.

제가 원한 방식은 키보드로 #을 입력하면 키워드 작성이 시작되고, 스페이스바를 누르는 순간 하나의 키워드가 완성되는 흐름이었습니다. 다음 키워드는 다시 #을 입력하면서 시작합니다. 별도의 추가 버튼은 만들지 않았습니다.

처음 설명할 때 제가 # 버튼이라고 잘못 표현했지만, 곧바로 물리적인 버튼이 아니라 키보드 문자라고 정정했습니다. 이 차이를 다시 확인한 뒤 입력 상태를 수정했고, 첫 번째 키워드가 스페이스바로 등록되는지, 두 번째 키워드가 새로 시작되는지, 삭제와 모바일 가로 넘침까지 브라우저에서 검사했습니다. 해당 수정도 커밋과 운영 배포를 완료했습니다.

5. 키워드를 직접 누르기 전에는 AI 생성 API를 호출하지 않게 했습니다

마지막 문제는 화면이 아니라 비용과 연결돼 있었습니다. ‘발행할 키워드 우선순위’에서 카테고리만 바꿨는데도 첫 번째 키워드의 글감 10개를 만드는 로딩이 시작됐습니다. 사용자가 키워드를 선택하지 않았는데 페이지 진입이나 필터 변경만으로 AI 요청이 나가면, 사용하지 않은 결과에도 비용이 발생할 수 있습니다.

재현 검사에서는 카테고리만 선택했는데 생성 API가 이미 1~2회 호출됐습니다. 코드를 확인해 보니 선택 상태 초기값, 실데이터 갱신 직후, 선택값이 없을 때의 대체값까지 세 곳에서 첫 키워드를 자동 선택하고 있었습니다. 세 자동 선택을 제거하고 카테고리를 바꿀 때 기존 선택값도 비우도록 수정했습니다.

한 가지 비용 문제를 더 발견했습니다. 키워드를 직접 눌러도 검색 수요가 도착하기 전에 글감 API를 한 번 호출하고, 연관 키워드가 도착한 뒤 다시 호출해 총 2회가 발생했습니다. 검색 수요 확인이 끝난 뒤 추천 영역을 열도록 순서를 바꿨습니다. 전용 브라우저 검사 결과는 페이지 진입과 카테고리 선택에서 0회, 검색 수요 로딩 중에도 0회, 키워드를 직접 선택한 뒤 1회였습니다.

이 마지막 수정은 로컬 구현과 검증까지만 완료했습니다. 아직 커밋·push·운영 배포 전이므로 현재 운영 사이트에 반영됐다고 쓰지 않았습니다.

💡 결과와 배운 점

시행착오: 요구사항을 기능 단위로만 이해하면 이미지 위치를 한쪽에만 적용하거나, 가독성을 높이겠다며 요청하지 않은 외곽선을 넣는 문제가 생겼습니다. 화면, HTML, 다운로드처럼 같은 결과를 소비하는 경로를 함께 확인해야 했습니다.
비용에 대한 관점: 카테고리 필터와 키워드 선택은 화면에서는 가까워 보여도 의미가 다릅니다. 필터는 목록만 바꾸고, 유료 생성은 사용자의 명시적인 선택 뒤에 실행해야 합니다.
검증 방식: 단순히 화면이 보이는지만 확인하지 않고 API 호출 횟수를 직접 세는 전용 브라우저 검사를 만들었습니다. 이 검사 덕분에 키워드 한 번 클릭에 요청이 두 번 발생하는 문제까지 찾았습니다.
현재 남은 부분: 전체 UI 검사에는 제품 버전과 과거 원고·이미지 문구를 기대하는 오래된 항목 4개가 남아 있습니다. 마지막 비용 차단 수정도 운영 배포 전입니다.
앞으로의 계획: 오래된 전체 UI 기대값을 현재 화면에 맞게 정리한 뒤 마지막 수정 사항을 커밋·push·배포하고, 운영 환경에서도 요청 횟수와 오류 로그를 다시 확인할 계획입니다.

📚 도움 받은 글 (옵션)

외부 글은 사용하지 않았습니다. 실제 Codex 대화 기록과 키워드 레이더 저장소의 코드, 테스트와 브라우저 검증 결과만 근거로 작성했습니다.

✅ Do (해야 할 것)

데이터가 늘어날 시점을 기준으로 검색·필터·페이지네이션 범위 정하기
카테고리 필터와 실제 키워드 선택 상태를 분리하기
화면·HTML·다운로드처럼 같은 결과를 쓰는 경로를 함께 확인하기
유료 API는 사용자 행동 전후의 호출 횟수로 검증하기
설계·구현·검증·배포 상태를 구분해 기록하기

❌ Don't (하지 말아야 할 것)

카테고리 필터 변경을 키워드 선택으로 간주하기
페이지 진입만으로 유료 생성 API 호출하기
화면만 수정하고 HTML·다운로드 경로는 누락하기
자동 검사가 통과했다는 이유로 시각 검수를 생략하기
검증하지 않은 운영 반영을 완료로 보고하기

😈 정말 찐찐찐 마지막 할인가!!! 24기 AI 스터디 😈