{"_meta":{"entity":"Pivot Studio","type":"Insight Article","canonical_url":"https://pivotstudio.co.kr/insights/verified-boilerplate-two-sites-ai-speed","published_at":"2026-06-30T07:05:53.767Z"},"knowledge":{"title":"속도는 AI가 만들지 않습니다","summary":"같은 보일러플레이트로 두 사이트를 만들었고, 교회 사이트 뼈대는 4일 만에 나왔습니다. 그런데 그 속도를 만든 건 AI가 아니라, 미리 검증을 끝낸 토대였습니다. 두 프로젝트로 확인한 '검증된 레일'의 힘을 정리했습니다.","full_markdown":"one verified foundation, two websites built on top\n\n6월 한 달 동안, 우리는 같은 보일러플레이트(pivot-forge) 하나로 웹사이트를 두 개 만들었습니다. 하나는 우리 회사 사이트고, 다른 하나는 클라이언트인 교회 사이트입니다. 성격이 완전히 다른 두 프로젝트였죠.\n\n그중 교회 사이트는 퍼블릭과 어드민을 합쳐 러프한 화면이 나오기까지 나흘이 걸렸습니다. 빠르다고 느끼셨을 수도 있겠네요. 그런데 그 속도를 만든 건 AI가 아니었습니다.\n\n## 그럼 4일 만에 화면이 어떻게 나왔을까요?\n\n먼저 솔직하게 짚고 갈게요. 나흘은 '완성'이 아닙니다. 퍼블릭과 어드민의 거친 뼈대가 서기까지 걸린 시간이에요. 그 뒤에 디테일을 다듬고 검수하는 시간은 따로 들어갑니다.\n\n그런데도 이 속도가 가능했던 건, AI가 빨라서가 아닙니다. 그 위에서 작업할 토대를 미리 검증해 뒀기 때문입니다.\n\n우리는 [지난 글](https://pivotstudio.co.kr/insights/ai-agent-coding-web-agency)에서 AI 에이전트에게 '자유'가 아니라 '레일'을 깔아준다고 이야기했습니다. 이번 글은 그 이야기를 실제 프로젝트 두 개에 적용해본 기록입니다. 방법론을 다시 설명하려는 게 아니라, 그게 현장에서 진짜로 굴러갔는지를 보여드리려고요.\n\n## 만들기 전에, 레일부터 두들겨봤습니다\n\n중요한 건 두 프로젝트를 시작하기 '전에' 한 일입니다. 우리는 pivot-forge를 만든 다음, 그 위에 뭔가를 올리기 전에 보일러플레이트 자체부터 점검했어요.\n\ninspecting and testing a foundation before building on it\n\n- **레드팀 테스트** — 일부러 약한 길목을 찾아 공격해봤습니다.\n- **보안 점검** — 서버 검증과 권한 가드가 기본값으로 작동하는지 확인했습니다.\n- **성능 점검** — 응답 속도와 빌드에 병목이 없는지 살폈습니다.\n\n이걸 다 통과시킨 다음에야 실제 프로젝트를 올렸습니다. 순서가 핵심이에요. 토대를 검증하지 않은 채 빠르게 만들면, 그 속도는 고스란히 빚이 됩니다. 반대로 한 번 검증된 토대 위에서는, 아무리 빨리 만들어도 같은 안전 기준이 따라옵니다.\n\n그래서 우리가 말하는 속도는 '대충 빠른 것'이 아닙니다. '검증된 토대 위에서의 빠름'이에요.\n\n이 전제를 깔고 보면, 두 프로젝트는 서로 다른 질문에 답합니다. 회사 사이트는 '레일이 잘 깔렸을 때 뭐가 가능한가'를, 교회 사이트는 '그 레일이 진짜 클라이언트 환경에서도 버티는가'를 보여줍니다.\n\n## 우리 사이트는 마음대로 할 수 있었습니다\n\n회사 사이트는 클라이언트 요구사항이 없는, 제일 편한 조건이었습니다. 보일러플레이트를 만든 사람이 직접 그 위에서 작업하는 거니까요.\n\n여기서 사람이 한 일은 두 가지입니다. 하나, 데이터베이스에서 구멍 나 있던 부분을 메워 구조를 다시 단단하게 잡았습니다. 둘, 어드민 UI를 디자인 시스템 기준으로 완전히 새로 짰습니다. 그동안 임시방편으로 쌓여 있던 화면들을, 토큰 기반의 일관된 기준 위에 다시 올린 거죠.\n\nrebuilding a messy structure into a clean orderly one\n\nAI가 한 일은 그 기준 위에서 반복 작업을 채우는 것이었습니다. 사람이 디자인 시스템과 DB 구조라는 '기준'을 정해두면, AI는 그 기준을 따르는 화면과 로직을 채워나갑니다. 기준이 또렷할수록, AI가 내놓은 결과에서 손볼 곳이 줄어들어요.\n\n## 교회 사이트는 그렇지 않았습니다\n\n교회 사이트는 정반대였습니다. 실제 클라이언트가 있고, 실제 요구사항이 있고, 무엇보다 개발자가 아닌 운영자가 직접 관리해야 하는 환경이었어요. 통제된 실험실이 아니라, 레일이 현실에서도 버티는지 시험하는 자리였습니다.\n\n여기서 제일 중요한 일은 화면을 그리는 게 아니었습니다. 그 앞에서 내린 설계 판단이었죠. 요구된 관리 기능은 마흔두 개였습니다. 그런데 우리는 이걸 일곱 개의 재사용 가능한 CRUD 패턴으로 압축했습니다. 마흔두 개를 마흔두 번 만드는 대신, 본질이 같은 것끼리 묶어 일곱 개의 틀로 추린 겁니다.\n\nmany scattered pieces simplified into a few reusable templates\n\n이 압축이 왜 중요할까요. '관리 기능 마흔두 개 만들어'라고 AI한테 던지는 것과, 사람이 먼저 일곱 개 패턴으로 정리해두고 '이 틀대로 반복해'라고 맡기는 건 전혀 다른 일이기 때문입니다. 앞쪽은 AI가 매번 새로 판단해야 하고, 뒤쪽은 이미 검증된 틀을 복제하는 일에 가깝습니다. 사람이 큰 그림을 잡고 AI가 레일 위에서 실행한다 — 그 원칙이 가장 또렷하게 드러난 장면이었어요.\n\n그렇게 같은 보일러플레이트 위에서 퍼블릭과 어드민의 거친 뼈대가 나흘 만에 섰습니다. 다시 말씀드리지만 완성이 아니라 뼈대까지의 시간이고, 이 속도는 일곱 개 패턴이라는 사람의 설계와 미리 검증해둔 레일이 함께 있었기에 나온 결과입니다.\n\n## 결국, 속도는 토대에서 나옵니다\n\n두 프로젝트는 한 가지 사실을 두 번 확인해줍니다. 같은 보일러플레이트가 통제된 우리 환경에서도, 현실의 클라이언트 환경에서도 똑같이 작동했다는 것. 화이트라벨이니 재사용성이니 하는 말은 입으로 주장한다고 증명되지 않습니다. 조건이 다른 프로젝트들이 같은 토대를 나눠 썼을 때, 그제야 증명됩니다.\n\n그리고 그 모든 속도의 출처는 AI가 아니었습니다. AI보다 먼저 검증을 끝낸 레일이었죠. 레드팀과 보안, 성능을 통과한 토대를 한 번 만들어두면, 그 위에 올라가는 모든 프로젝트가 같은 기준을 물려받습니다.\n\n진짜 속도는 빨리 만드는 데서 나오지 않습니다. 다시 만들지 않아도 되는 토대에서 나옵니다."},"facts_and_qa":[]}