오늘로 Reddit에 온 지 100일째입니다. 이 기간 동안 저는 두 가지 프로젝트를 완성했는데, 둘 다 처음부터 끝까지 Claude Code를 이용해 작성했습니다. 바로 getkeptapp.com과 dailyaitools.ai입니다. 후자는 매일 아침 제가 아무것도 건드리지 않아도 새로운 AI 도구 페이지를 게시하는 디렉토리 사이트입니다. 이 글에서는 dailyaitools.ai에 초점을 맞추겠지만, kept에 대해서도 언제든지 이야기할 준비가 되어 있습니다.

이 디렉토리는 23일 전에 만들어졌고, 커밋은 282개, 항목(entries)은 52개, 비교 페이지는 135개입니다. 지난 28일간의 Search Console 기록을 보면 노출(impressions)은 4,156회, 클릭은 5회였습니다. 그러니 이 글은 승리한 사람의 것이 아니라 구축하는 사람의 노트로 읽어주시면 됩니다. 빌드 과정에서 얻은 교훈이 트래픽 수치보다 훨씬 가치가 있습니다.

Claude가 빛을 발했던 부분

오랫동안 유지되는 저장소 규칙(Long-lived repo rules). 제 CLAUDE.md 파일은 300줄에 달하며, 그 안에 있는 모든 규칙은 특정 버그에서 얻은 상처와 같습니다. Claude는 이 규칙들을 세션 전반에 걸쳐 다른 코딩 도구에서는 얻지 못했던 방식으로 준수합니다. 이는 파일이 부패하는 것이 아니라 계속해서 응집력을 갖게 만든다는 의미입니다. 단 하나의 파일 덕분에 사이트가 매일 스스로 게시되면서도 여전히 정확성을 유지할 수 있었습니다.

다른 코드를 관리(policing)하는 코드 작성. 제가 이 도구로 만든 가장 좋은 것은 기능(feature)이 아니라 검증기(verifier)였습니다. 주간 작업은 모든 공급업체의 가격 페이지를 다시 읽고, 구조화된 등급을 저희 사이트가 주장하는 내용과 비교하여 차이점(diffs)을 확인합니다. Claude는 이 과정의 비관적인 버전 설계에 능했습니다. 즉, 가져오기(fetch)가 절반만 작동할 때, 페이지가 다르게 렌더링되어 플랜이 사라질 때, 심지어 검사기 자체(checker itself)가 환각(hallucinates)을 일으킬 때 어떤 일이 발생하는지를요.

뼈대를 가진 산문(Prose with a spine). 저는 Claude에게 이모 대시(-) 사용 금지,

가벼운 질문들은 가장 빠른 곳으로 향합니다. cron 표현식이 무엇을 의미하는지 묻기 위해 리포지토리 인식 에이전트 (repo-aware agent)를 여는 것은 우리 둘 모두에게 시간 낭비입니다.

네 가지 실패, 네 가지 규칙

한 도구 페이지가 "Vercel 플랫폼 배포"를 기능으로 설명했습니다. 벤더의 사이트는 일시적인 404 화면을 띄웠고, 스크래퍼 (scraper)는 이를 깔끔하게 가져왔으며, 모델은 해당 오류 페이지에 대해 충실한 항목을 작성했습니다. 쓰레기를 깔끔하게 가져오는 것은 가져오기에 실패하는 것보다 더 위험합니다. 아무것도 잘못된 것처럼 보이지 않기 때문입니다. 이제 저는 오류 화면 같은 냄새가 나는 짧은 문서들은 버립니다.

제 파이프라인이 X(구 트위터)에서 beautifulai를 태그했습니다. 실제 계정은 beautifulai_였고 제가 태그한 것은 파킹된 계정이었습니다. 이제 핸들 (handle)은 해당 프로필이 도구 자체의 도메인을 참조하는 경우에만 사용합니다. 확인에 실패하면 게시물에는 일반 이름만 사용합니다.

로고 가져오기 도구는 일반적인 지구본 아이콘을 잡아내기 위해 1KB 미만의 모든 것을 거부했습니다. 단색 로고는 그보다 작게 압축됩니다. 실제 256px 마크가 943바이트였던 유료 파트너가 빈 모노그램 카드가 포함된 트윗을 받게 되었습니다. 파일 크기가 아니라 픽셀 치수로 순위를 매기세요.

저는 Claude에게 제 사이트의 깨진 내부 링크를 검토하게 했지만 아무것도 찾지 못했습니다. 그 후 소스 코드 대신 빌드된 HTML을 감사 (audit)하게 했더니 수십 개를 찾아냈습니다. 잘못된 URL 중 두 개는 데이터 배열 (data array) 안에 있었고 하나는 클라이언트 JS에서 조립되었기 때문에, 모델이 읽은 어떤 파일에도 문자열 형태로 존재하지 않았습니다. 레시피 (recipe)가 아니라 결과물 (artifact)을 검토하세요.

첫날 누군가에게 해주고 싶은 말

CLAUDE.md를 스타일 가이드가 아닌 실수 기록용 로그로 작성하세요. "파일 크기를 품질 신호로 사용하지 마세요. 여기 빈 카드가 배포된 날의 기록이 있습니다"라는 문구는 컨텍스트 압축 (context compaction) 과정에서도 살아남습니다. "깨끗한 코드를 작성하세요"라는 문구는 살아남지 못합니다.

모델이 제안하게 하고, 문자열 매칭 (string matching)이 폐기하게 하세요. 저의 시맨틱 체커 (semantic checker)는 원하는 어떤 항목이든 플래그 (flag)를 지정할 수 있지만, 모든 주장에는 소스에서 가져온 20자 이상의 인용구가 포함되어야 하며, 저는 그 인용구가 존재하는지 확인한 후에 보여줍니다. 환각 (hallucination)을 일으키는 체커는 올바른 작업을 비난하는 대신 침묵합니다. 프롬프트 (prompt)에서 "알 수 없음 (unknown)"을 정답이 되게 만드세요. 대부분의 잘못된 출력은 모델이 비워두어야 할 필드를 채우려 할 때 발생합니다.

빌드 감사 (build audit) 자체가 배포를 실패하게 만드세요. 저의 경우, 깨진 링크나 잘못된 스키마 블록 (malformed schema block)이 있으면 0이 아닌 종료 코드 (non-zero exit)로 종료됩니다. 저는 결함을 주입하고 빌드가 실패(red)하는 것을 지켜봄으로써 각 체크가 작동함을 증명했습니다. 따라서 성공(green)은 무언가 의미를 갖습니다. 기능을 구현하기 전에 가드레일 (guardrail)을 먼저 배포하세요. 위의 네 가지 실패 사례는 각각 가드레일이 있었을 때보다 더 많은 시간을 소모하게 만들었습니다. 100일째인 지금도 트래픽은 여전히 0에 가깝습니다. 저는 이것이