**<span style="font-size: 13px; color: #181818">회사의 남는 토큰을 활용하여 소품종 대량 생산 해봤습니다.</span>** 제가 낸 아이디어도 있고 AI가 아이디어 낸 것도 있습니다. https://www,funsoft.co.kr  ``` 개인 사이트 하나에 웹게임·계산기·퀴즈 **152개**를 밀어넣었습니다. 큰 서비스 하나를 잘 만드는 대신, 작은 걸 계속 찍어내는 쪽으로 굴려봤습니다. 자랑보다는 **뭐가 통했고 뭐가 안 통했는지** 적어보려 합니다. 👉 https://funsoft.co.kr --- ## 왜 작은 걸 많이 만들었나 큰 거 하나는 **틀리면 전부 날아갑니다.** 작은 거 152개는 하나가 망해도 151개가 남습니다. 검색 관점에서도 다릅니다. 서비스 하나는 검색어 하나를 먹지만, 152개는 152개의 검색어를 먹습니다. "연차 계산기"로 들어온 사람과 "스도쿠"로 들어온 사람은 완전히 다른 사람인데, 사이트는 하나입니다. 개당 제작 시간은 반나절에서 하루 정도입니다. AI 없이는 못 할 속도였습니다. --- ## 실제로 통한 것 ### 1. 한 항목에 한 URL 사자성어 사전을 만들 때 목록 페이지 하나로 끝내지 않고 **77개 단어를 각각 URL로 팠습니다.** `/idiom/새옹지마/` 같은 식으로요. "새옹지마 뜻"을 검색하는 사람은 목록 페이지를 원하는 게 아니라 그 단어 페이지를 원합니다. 페이지 하나 늘리는 비용은 거의 0인데 검색 진입점이 77배가 됩니다. 같은 방식으로 급식 조회는 학교별로, AI 용어사전은 용어 65개를 각각 URL로 뺐습니다. 지금 사이트맵에 **338개 URL**이 등록돼 있는데, 서비스 수보다 훨씬 많은 이유가 이겁니다. ### 2. "한 번 보고 마는 것" vs "계속 다시 검색하는 것" 만들어놓고 조회수를 비교해보니 격차가 극단적이었습니다. 가장 잘 되는 페이지는 게임 아이템 시세표입니다. **누적 13,000회를 넘겼는데**, 이유가 명확합니다. 거래할 때마다 다시 검색하거든요. 반면 심리테스트처럼 한 번 보고 끝나는 건 아무리 잘 만들어도 재방문이 안 생깁니다. 만들기 전에 **"이걸 같은 사람이 두 번 검색할까?"**를 먼저 따지게 됐습니다. ### 3. 블로그가 유일하게 제대로 도는 유입 경로 도구를 아무리 만들어도 검색에 걸리기까지 몇 달이 걸립니다. 그런데 블로그 글은 훨씬 빨리 잡히더군요. 그래서 글 하단에 관련 도구를 자동으로 붙이는 걸 만들어서, 글로 들어온 사람을 도구로 흘려보내고 있습니다. --- ## 실제로 안 통한 것 **만들어놓고 링크를 안 걸면 아무도 안 옵니다.** 당연한 얘긴데 152개쯤 되니까 내가 만든 걸 나도 까먹습니다. 메인에서 링크가 안 걸린 채로 몇 달을 방치된 페이지가 여럿 나왔습니다. **예쁜 것과 검색되는 것은 별개입니다.** 공들여 만든 인터랙션 좋은 페이지가 조회수 두 자리, 대충 만든 계산기가 네 자리인 경우가 흔합니다. --- ## AI로 대량생산할 때 진짜 병목은 속도가 아니라 검증입니다 빨리 만드는 건 이제 문제가 아닙니다. 문제는 **틀린 걸 빨리 만든다는 것**입니다. 최근에 겪은 세 가지입니다. ### 2048 상하 반전 만들고 눈으로 보면 잘 굴러갑니다. 근데 회전 함수가 시계 방향이라 위 키가 아래로 동작하고 있었습니다. 플레이해보면 "어 좀 이상한데?" 정도라 놓치기 쉽습니다. 브라우저 없이 노드에서 보드 배열만 넣고 돌려보는 테스트를 짜서 잡았습니다. **눈으로 보는 검수로는 절대 못 잡았을 버그**였습니다. ### HTTP 200으로 서버 경로가 노출되고 있었음 전체 페이지를 훑어보다가 PHP Parse error가 난 페이지 3개를 발견했습니다. 문제는 이게 **상태 코드 200으로 나가면서** 에러 메시지에 서버 절대 경로가 그대로 찍히고 있었다는 겁니다. 원인 중 하나는 `echo "...src=\"https://...\""` 안에서 따옴표가 깨진 것, 하나는 `if` 없는 `else`였습니다. 사람이 훑으면 안 보입니다. 전체 파일에 `php -l` 돌리니 3초 만에 나왔습니다. ### 검사 결과가 전부 "통과"로 나오던 사건 인라인 JS 문법 검사를 돌렸더니 22개 페이지 중 21개가 "JS 없음"으로 나왔습니다. 실제로는 다 있었습니다. 원인은 **한 프로세스에서 페이지를 반복 include 한 것**이었습니다. `require_once`가 두 번째부터 안 걸리니 출력이 비었던 거죠. 페이지마다 프로세스를 새로 띄우게 고치니 정상적으로 잡혔습니다. 무서운 건 **틀린 검사가 조용히 통과로 나온다**는 점입니다. 실패하면 알아채는데, 성공했다고 거짓말하면 모릅니다. --- ## 성능: 범인은 방문자 카운터였습니다 전 페이지 TTFB가 1.6~1.8초였습니다. 원인이 방문자 카운터 하나였습니다. - 매 요청마다 `CREATE TABLE IF NOT EXISTS` 실행 - 매 요청마다 외부 IP 조회 API 호출 - 매 요청마다 `DELETE ... WHERE id NOT IN (SELECT ... LIMIT 200000)` 각각 스키마 생성은 파일 마커로 1회만, IP 조회는 결과를 테이블에 캐시, 정리 쿼리는 500분의 1 확률로만 PK 커트라인 방식으로 바꿨습니다. **1.6초 → 0.95초.** 105개 페이지가 한 번에 40% 빨라졌습니다. 페이지를 아무리 잘 만들어도 공통 include 하나가 전부를 깎아먹고 있었습니다. --- ## 최근에 만든 것 AI 용어가 하도 여기저기서 들려서 **용어사전 65개 + 테스트**를 붙였습니다. - 📖 AI 용어사전 — https://funsoft.co.kr/aiterm/ - 🎯 AI 코딩 얼마나 아십니까? (10문제) — https://funsoft.co.kr/aiquiz/ "어떤 모델이 제일 좋냐" 같은 건 일부러 한 문제도 안 넣었습니다. 몇 달이면 틀린 내용이 되니까요. 토큰, 할루시네이션, RAG, 파인튜닝처럼 **몇 년 가는 개념**만 담았습니다. RAG랑 파인튜닝 차이를 설명할 수 있으면 7점은 나옵니다. 여기 계신 분들은 만점 나오실 것 같은데, 궁금하네요. --- ## 정리 혼자서 서비스 152개를 굴리는 건 이제 기술적으로 가능합니다. 다만 만드는 속도가 빨라진 만큼 **검증을 자동화하지 않으면 틀린 게 그대로 쌓입니다.** 저는 그걸 배포하고 한참 뒤에 알았습니다. 혹시 둘러보시다가 이상한 거 보이면 알려주세요. 사이트 안에 의견 남기는 곳 만들어뒀습니다. 👉 https://funsoft.co.kr ```