AI로 사이드프로젝트를 만들 때, 사실 코드는 먼저가 아니었다

AI가 빨라질수록 사람이 먼저 정해야 하는 것

AI 코딩 도구를 쓰면 첫 화면은 금방 나온다. 처음엔 이게 제일 신기했다. 와, 벌써 화면이 생겼네! 그런데 문제는 첫 화면이 나온 뒤부터다. 어떤 페이지를 검색에 노출할지, 어떤 기능은 서버 없이 갈지, 어떤 데이터는 파일로 관리할지, 어떤 흐름은 다음 단계로 미룰지 정하지 않으면 빠른 생성 속도가 오히려 방향을 흐린다.

작은 사이드프로젝트에서 가장 먼저 할 일은 기술 선택이 아니라 범위 선택이다. 로그인, 결제, 댓글, 랭킹, AI API 호출은 모두 매력적이지만 첫 검증에는 무겁다. 나중에 붙이면 된다. 아니, 나중에 붙일 수 있게만 남겨두면 된다. 정적 배포, 콘텐츠 파일, 브라우저 상호작용만으로 반응을 볼 수 있으면 그게 1차 구조로 충분하다.

내가 쓰는 순서

• - 한 문장으로 사이트 역할을 정한다
• - 첫 방문자가 할 행동을 하나로 줄인다
• - 데이터를 코드 밖 파일로 뺄 수 있는지 본다
• - sitemap에 넣을 페이지를 작게 정한다
• - 배포 후 Search Console에서 실제 색인 상태를 본다
• - 기능 추가보다 콘텐츠 반복 속도를 먼저 본다

AI에게 바로 “앱 만들어줘”라고 말하면 대체로 그럴듯한 화면이 나온다. 하지만 서비스가 살아남으려면 화면보다 반복 구조가 중요하다. 글 하나를 추가할 때 관련 Play가 같이 생기고, Play 결과에서 다시 글로 돌아가는 구조가 있으면 다음 실험을 빨리 만들 수 있다.

이 순서를 정하지 않으면 작업이 이상하게 부풀어 오른다. 블로그 글을 하나 쓰다가 검색 페이지를 고치고, Play를 만들다가 랭킹을 생각하고, sitemap을 정리하다가 다국어 route를 다시 열고 싶어진다. 전부 가능한 일이지만 전부 지금 필요한 일은 아니다. 그래서 AI에게 맡기기 전에 먼저 “오늘 공개 표면에 남을 것”을 적어둔다.

코드보다 먼저 고른 것

이 표를 먼저 잡고 나서야 AI에게 맡길 일이 보였다. 컴포넌트 작성, 비슷한 카드 구조, JSON 스키마 반복은 AI가 빠르다. 반대로 "이 페이지를 공개 대표 글로 볼 것인가", "이 짧은 메모를 Play 제작 로그로 묶을 것인가"는 사람이 정해야 한다. 이 판단을 건너뛰면 코드가 빨라질수록 사이트는 더 얇아진다.

bobob.app에서 실제로 먼저 잠근 표면

2026-07-03 기준으로 이 사이트에서 먼저 잠근 것은 기능 목록이 아니라 공개 표면의 순서였다. 홈은 도구 모음 설명보다 Blog + Play 전환 이유를 먼저 보여야 했다. `/blog`는 최신 글 목록만 길게 쌓는 대신 세 개의 첫 읽을 글을 앞에 두어야 했다. `/play`는 시작 버튼만 있는 장난감 목록이 아니라 결과, 공유, 관련 글, 관련 Play로 이어져야 했다.

이 순서를 잠그지 않으면 AI에게 시킬 일이 계속 바뀐다. 홈을 고치다 보면 다시 도구 페이지를 키우고 싶고, Play를 만들다 보면 점수판과 로그인 저장을 붙이고 싶어진다. 그래서 먼저 "외부에서 처음 볼 사람에게 어떤 페이지가 사이트 주인을 설명하는가"를 적었다.

이 표를 만들어두면 요청이 훨씬 작아진다. "사이트를 멋지게 만들어줘"가 아니라 "홈 첫 화면에서 대표 글 3개가 먼저 보이는지 확인해줘", "noindex 제작 메모가 검색 기본 결과에 섞이지 않는지 봐줘"처럼 말할 수 있다. AI가 빠르게 코드를 만들수록 이런 좁은 요청이 더 중요하다. 넓은 요청은 넓은 결과를 만들고, 넓은 결과는 확인할 표면을 늘린다.

실제로 미룬 기능들

처음 생각한 기능 후보는 더 많았다. 하지만 작은 사이트가 먼저 증명해야 하는 것은 기능 목록이 아니라 한 가지 사용 흐름이다. 그래서 아래 기능은 의도적으로 뒤로 밀었다.

• - 계정 저장은 나중으로 미뤘다. 지금은 브라우저에서 바로 읽고 바로 눌러보는 흐름이 더 중요하다.
• - 랭킹은 넣지 않았다. 점수 경쟁보다 결과 화면에서 관련 글이나 다른 Play로 이어지는 구조가 먼저다.
• - 댓글은 넣지 않았다. 공개 입력면은 관리 부담이 생기고, 첫 품질 점검의 초점을 흐린다.
• - AI API 호출 기능도 넣지 않았다. 이 사이트의 첫 역할은 AI 호출 서비스가 아니라 직접 만든 글과 작은 실험을 보여주는 것이다.
• - 모든 글을 sitemap에 넣지 않았다. 짧은 제작 메모는 archive/noindex 후보로 두고, 대표 글과 Play 중심으로 제출 표면을 좁혔다.

이렇게 적어두면 AI에게도 더 정확히 지시할 수 있다. “랭킹까지 만들어줘”가 아니라 “결과 링크와 관련 글 연결만 확인해줘”라고 말하게 된다. 요청이 좁아지면 결과도 좁아지고, 검증할 수 있는 범위도 작아진다.

완료라고 부르는 기준

작은 사이트에서 완료는 파일 생성이 아니다. 적어도 로컬에서 페이지가 뜨고, 빌드가 되고, sitemap/feed/search 경로에 의도한 만큼만 들어가고, 실제 화면에서 첫 행동이 보일 때 완료에 가까워진다. 특히 콘텐츠는 더 조심해야 한다. 제목만 그럴듯한 짧은 글이 늘어나는 것보다, 대표 글 몇 개가 사이트 방향을 분명히 말하는 편이 낫다.

그래서 AI로 만든 사이드프로젝트일수록 사람이 마지막에 줄이는 일을 해야 한다. 기능을 줄이고, sitemap을 줄이고, 목록에 보일 글을 줄인다. 줄인 뒤 남은 것들이 더 분명하면 그게 좋은 1차 구조다.

내가 보는 완료 기준도 표로 바뀌었다.

이 표는 느리게 보이지만 실제로는 시간을 아낀다. 어디까지 봐야 완료인지 정하지 않으면 매번 새 기능을 하나 더 붙이고 싶어진다. 완료 기준을 줄이면 작업도 줄고, 공개 후에 설명할 수 있는 상태가 된다.

AI에게 요청하기 전에 쓰는 작은 확인서

요즘은 바로 프롬프트를 쓰고 싶을 때가 많다. 그런데 바로 쓰면 결과물이 너무 잘 나온 척한다. 그래서 새 기능이나 새 글을 만들기 전에는 아래 확인서를 먼저 적는다.

• - 이 작업이 홈, Blog, Play, 검색, sitemap 중 어느 표면을 바꾸는지 적는다.
• - 새 페이지가 필요한 일인지, 기존 대표 글 안에 흡수할 일인지 먼저 고른다.
• - 사용자가 처음 볼 문장과 마지막에 누를 링크를 한 줄씩 적는다.
• - 서버, 계정, 저장, 랭킹, 댓글처럼 지금 미룰 기능을 미리 적는다.
• - 완료 후 확인할 명령을 적는다. 글이면 `harness:blog-play-mvp`, Play면 `harness:play-interaction`, 공개 표면이면 live discovery까지 본다.
• - 외부 도구에서 확인해야 하는 것은 배포 성공과 분리해서 기록한다. sitemap 제출은 제출일 뿐이고, 색인 여부는 별도 관찰이다.

이 확인서가 있으면 AI가 만든 결과를 거절하기도 쉬워진다. 예를 들어 멋진 랭킹 보드가 나와도 지금 확인서에 "계정 저장과 랭킹은 미룸"이라고 적혀 있으면 넣지 않는다. 글이 짧게 여러 개 생겨도 "기존 대표 글 안에 흡수할 일"이라고 적혀 있으면 새 제출 페이지로 만들지 않는다. AI를 덜 쓰겠다는 뜻이 아니다. AI가 만든 것을 공개 표면에 올릴지 말지는 사람이 끝까지 잡겠다는 뜻이다.

이번 정리에서 실제로 남긴 검증 기록

이 사이트에서 가장 크게 배운 것은 로컬 성공과 외부 관찰을 섞으면 안 된다는 점이다. 로컬에서 글이 렌더링되고, 빌드가 통과하고, sitemap이 의도한 숫자로 나오더라도 외부 검색 도구가 그 페이지를 어떻게 보는지는 다른 문제다. 그래서 기록도 둘로 나눴다.

이 표를 공개 글에 남기는 이유는 숫자를 자랑하려는 게 아니다. 작은 사이트가 AI로 빠르게 만들어졌더라도, 운영자가 어떤 숫자를 신뢰하고 어떤 숫자는 아직 proof로 보지 않는지 보여주고 싶었다. 이 구분이 없으면 빠른 생성 속도는 곧 빠른 착각이 된다.

바로 해보기

프롬프트 재료 나누기는 이 문제를 작은 분류 게임으로 만든 것이다. AI에게 던질 문장을 목적, 맥락, 제약으로 나누는 연습을 한다. 질문이 정리되면 코드 생성도 덜 흔들린다.

다음 프로젝트에 그대로 가져갈 기준

다음에도 AI로 작은 서비스를 만들면 먼저 공개 표면을 적을 것이다. 홈, 대표 글, Play, 검색, sitemap, feed처럼 외부에서 볼 경로를 먼저 적고, 그 안에 들어갈 콘텐츠 수를 제한한다. 기능은 그 다음이다. 이렇게 시작하면 AI가 만든 화면을 어디에 붙일지 덜 흔들린다.

또 처음부터 모든 글을 색인 대상으로 보지 않는다. 초안, 제작 메모, 실험 기록은 내부적으로 쌓되, 대표 글로 남길 만한 것만 목록과 sitemap에 보낸다. 이 순서가 있어야 빠른 생성 속도가 사이트 품질을 망치지 않는다.

AI 코딩 도구는 계속 쓸 것이다. 다만 이제는 “얼마나 빨리 만들었나”보다 “어떤 표면만 공개했나”를 먼저 본다. 작은 사이트는 많은 기능보다 또렷한 반복 구조가 더 오래간다. bobob.app에서 그 구조는 글을 쓰고, 작은 Play로 손을 움직이게 하고, 결과에서 다시 글이나 다른 Play로 돌아오게 하는 흐름이다.