핵심 요약
- 사업들을 진행 단계 하나의 축으로만 묶어 놓으니 /business 페이지가 뒤죽박죽이었다. 그래서 분야(커머스·소프트웨어·창작)와 진행 상태를 분리하는 정보구조 개편을 했고, /work로 경로를 통째로 옮겼다.
- 성장로그는 원래 커밋 제목만 긁어 나열하는 자동 기록이었는데, 이번에 재료를 커밋 본문(이유)까지 넓히고 판단이 없는 날은 아예 발행하지 않는 게이트를 넣었다.
- 발행 본문에서 깃 원문(커밋 문구, 파일명)을 완전히 빼고 LLM 참고 재료로만 쓰도록 바꿨다. 개인 저장소 내용이 글에 그대로 새어나가는 걸 막기 위한 조치다.
- WorryCheck 다운로드 수 0회 노출, 관리자 전용 문구가 방문자 화면에 그대로 보이던 것 등 자잘한 노출 실수도 같이 정리했다.
왜 /work부터 다시 짰나
처음에 사업 페이지는 stage(아이디어, 개발 중, 베타, 출시 준비, 운영 중, 보류) 하나로만 분류되어 있었다. 문제는 이 축이 '뭘 만드는지'와 '얼마나 진행됐는지'를 동시에 말하려다 보니 어느 쪽도 제대로 설명을 못 했다는 점이다. 커머스 사업과 소프트웨어 프로젝트가 같은 목록에 뒤섞여 있으면 방문자 입장에서 이게 뭘 하는 사람인지 한눈에 안 들어온다.
그래서 category(commerce/software/creative)를 stage와 독립된 축으로 새로 뒀다. DB에 컬럼을 추가하고 기존 데이터는 slug 기준으로 백필했다. 관리자 화면에도 분야 선택 UI를 새로 넣었는데, 이 작업 중에 로컬 빌드가 놓친 타입 오류를 하나 잡았다.
로컬에서 통과했다고 안심할 게 아니라는 걸 다시 확인한 셈이다. 앞으로는 배포 전에 tsc를 직접 돌려보는 습관이 필요하다.
구조를 바꾼 김에 상단 내비게이션도 손을 봤다. 작업(분야 드롭다운)·글·성장 로그·소개로 좁히고, 투자·독서·여행·이야기 네 개 주제는 상단에서 빼서 /writing 페이지의 필터 칩으로 옮겼다. 상단 메뉴에 다 욱여넣기보다 자주 볼 것과 가끔 찾아볼 것을 분리하는 게 맞다고 판단했다.
빌드 오류: BusinessInput["category"]가 필요한데 로컬 vinext 빌드는
tsc를 돌리지 않아 이 타입 불일치를 놓쳤다. Vercel 배포 시점에야 발견.자동화를 고치기 전에 먼저 무엇을 기록할지부터 다시 물었다
성장로그는 원래 그날의 커밋 제목을 모아서 자동으로 글을 만드는 기능이었다. 그런데 만들고 나서 다시 보니 이게 그냥 커밋 로그를 예쁘게 포장한 것에 불과했다. 제목만 봐서는 왜 그 코드를 바꿨는지 알 수 없으니, 글도 결국 '무엇을 했다'의 나열에서 벗어나지 못했다.
그래서 재료 자체를 바꿨다. 커밋 제목뿐 아니라 본문(이유가 적힌 부분)까지 넣고, 판단 메모를 글의 중심에 놓도록 프롬프트를 다시 짰다. 그리고 편집장 게이트라는 걸 넣었는데, 버핏 기준으로 채점해서 70점 미만이면 재작성하고 60점 미만이면 그날은 발행을 포기하는 방식이다. 판단이 없는 날은 억지로 글을 만들지 않는다는 원칙을 코드로 못박은 셈이다.
이 과정에서 가장 신경 쓴 부분은 프라이버시였다. 처음에는 커밋 원문을 참고해서 글을 쓰다 보니 발행된 본문에 깃 커밋 문구나 파일명이 그대로 드러날 위험이 있었다. WorryCheck는 개인 고민 데이터를 다루는 앱이라 이 문제가 더 민감했다. 그래서 3중 방어를 넣었다.
작문 엔진도 몇 번 바꿨다. 처음엔 Claude CLI 구독을 그대로 썼고, 그다음 DeepSeek API를 우선 순위로 올렸다가, 결국 Sonnet 5 CLI를 우선으로 하고 DeepSeek을 폴백으로 두는 순서로 정리했다. DeepSeek을 폴백으로 남겨두면서 한자(중국어) 유출 감지도 추가했는데, 이건 폴백이 걸릴 경우를 대비한 최소한의 안전장치였다.
1. 입력 단계에서 PII·시크릿 마스킹
2. 프롬프트에서 원문 인용 금지 명시
3. 출력 유출 대조검사 — 걸리면 재작성, 재실패 시 발행 포기화면과 문구도 결국 같은 원칙으로 정리됐다
/work와 홈 카테고리 레이아웃이 깨져 있던 것도 이번에 고쳤다. /work 목록에서 항목 4개를 3열 그리드에 억지로 넣다 보니 설명 텍스트가 28px짜리 화살표 칸에 갇혀 세로로 흐르는 버그가 있었다. grid-template-areas로 상태·제목+설명·화살표 위치를 명시적으로 나눠서 해결했다. 홈 카테고리의 긴 영문 라벨이 고정폭 칸에서 줄바꿈되던 것도 한글을 위에 얹는 kicker 방식으로 바꿔서 정리했다.
WorryCheck 페이지에서는 출시 전 상태인데 누적 다운로드 0회가 그대로 노출되고 있었다. 이건 showsDownloadCount라는 플래그로 감추고 대신 지원 플랫폼(iOS·Android)을 보여주는 쪽으로 바꿨다. 더 눈에 띄었던 건 "관리자 페이지에서 변경", "앱스토어 누적 수를 직접 업데이트" 같은 내부 안내 문구가 방문자용 화면에 그대로 노출돼 있던 부분이다. 관리자용으로 짠 문구를 그대로 복붙해서 공개 페이지에 옮겨 쓴 실수였는데, 방문자용 카피로 바꿔서 정리했다.
이 밖에 파비콘 추가, 모바일 내비 줄바꿈 처리, 페이지 가로 넘침 수정, sitemap에 성장로그 URL 포함, 페이지별 트위터 메타 정리 같은 자잘한 작업도 같은 날 같이 처리했다. 큰 흐름은 아니지만 방문자가 실제로 마주치는 화면의 완성도를 채우는 작업이었다.
자동화를 만들 때는 무엇을 기록할지부터 정해야 한다
이번 하루를 지나고 보니 순서가 중요했다는 생각이 든다. 정보구조(분야와 상태를 분리하는 것)를 먼저 바로잡지 않았다면 성장로그 자동화도 결국 뒤죽박죽인 데이터 위에 글을 쌓는 꼴이 됐을 거다. 자동화나 자동 생성 기능을 만들기 전에, 그 기능이 무엇을 재료로 삼을지와 무엇을 기록하지 않을지를 먼저 정해야 나중에 통째로 다시 짜는 일을 줄일 수 있다.