이 기사의 대상 독자

• Claude Code(또는 Cursor 등의 AI 코딩 툴)를 사용하고 있지만, 「지시 → 구현」의 단순한 왕복 단계에서 멈춰 있는 분
• AI에게 맡길 범위와 인간이 쥐고 있어야 할 범위의 경계선에 대해 고민하고 있는 분
• 개인적으로 Web 서비스나 미디어를 운영하며, 런칭을 가속화하고 싶은 분

반대로, 프로그래밍 입문이나 Claude Code의 셋업 방법은 다루지 않습니다.

결론: AI를 2개의 역할로 나누었더니, 런칭이 2일 만에 끝났다

최근, 행정 급여 정보를 검색할 수 있는 데이터베이스 사이트(약 7,800건 수록)를 구축했습니다. 도메인 취득부터 데이터 파이프라인 구축, SEO 구현, 팩트 체크가 완료된 블로그 기사 10개 공개, 주간 자동 운용 체제 구축까지, 소요된 기간은 실질적으로 2일입니다.

기존의 개인 개발에서는 이 정도 규모의 사이트는 출시까지 수개월이 걸리는 것이 상례였습니다. AI를 사용하는 개발자들 사이에서도 「2주 ~ 1개월」이 흔히 말하는 기준선입니다. 그것이 2일 만에 끝난 가장 큰 요인은 AI의 성능이 아니라 체제의 구성 방식에 있었습니다.

구체적으로는, 다음과 같은 3자 분업입니다.

포인트는, Claude Code의 완료 보고를 내가 아닌 또 다른 Claude에게 리뷰하게 하는 것입니다. 나는 두 AI 사이에서 결과물과 지시서를 나르고, 중요한 지점에서 판단만 합니다. 이 기사에서는 이 체제의 구체적인 운영 방식과 실제로 발생한 문제, 그리고 솔직한 한계에 대해 말씀드리겠습니다.

이 사이트를 만들기로 결심한 계기는, 급여나 수당 정보가 행정 기관마다 분산되어 있어 자신과 관련된 제도를 찾는 것이 생각보다 힘들다고 느꼈기 때문입니다. 어렵게 공개된 정보임에도 필요한 사람에게 전달되지 않는 것은 아쉬운 일입니다. 그래서 우선 검색하기 쉬운 형태로 정리하면 어디까지 유용해질 수 있을지, 개인 개발로서 시도해 보기로 했습니다.

왜 「지시 → 구현」의 단순 왕복으로는 빨라지지 않는가

Claude Code는 우수하지만, 모호한 지시를 주면 모호한 방향으로 전력 질주합니다. 저도 이전에는 「〇〇한 사이트를 만들어줘」라고 지시하고, 나온 결과물을 보며 수정 지시를 거듭하는 방식으로 사용했습니다. 이렇게 하면 되돌아오는 작업(rework)이 많아져 결국 인간이 병목 현상이 됩니다.

시행착오 끝에 도달한 것이 페이즈 분할과 체크포인트 주도(checkpoint-driven) 방식입니다.

페이즈 1: 조사 및 설계 제안 (구현 금지)
↓ 인간이 승인
페이즈 2: 기반 구축 (배포 금지)
...

각 페이즈의 프롬프트에는 반드시 「이번에 할 일」과 같은 분량의 **「해서는 안 될 일」**을 작성합니다. 예를 들어 페이즈 1이라면 다음과 같은 제약 사항입니다.

## 제약·주의사항
- 구현·파일 생성·배포는 아직 수행하지 말 것. 조사 및 제안 리포트만 작성할 것
- 제안은 「권장안 + 대안」 형식으로, 판단 근거를 제시할 것
...

「권장안 + 대안」 형식을 강제하는 것이 은근히 효과적입니다. AI는 내버려 두면 하나의 안을 높은 확신도로 내놓지만, 대안과 트레이드오프(trade-off)를 병기하게 하면 인간이 판단할 수 있는 재료가 되기 때문입니다.

「리뷰 담당 Claude」가 무엇을 하고 있는가

이 체제의 핵심은 Claude Code의 완료 보고를 별도의 Claude(채팅 측)에게 읽게 하여 리뷰하게 하는 공정입니다.

실례를 들어보겠습니다. 페이즈 2의 완료 보고에서, Claude Code는 「실제 데이터 약 7,800건을 가져오기 하여 빌드 성공」이라고 보고해 왔습니다. 얼핏 보면 완벽합니다. 하지만 보고 끝부분의 전달 사항에 「데이터 파일(52MB)의 배포 시 취급 방식 미정」이라는 한 줄이 있었습니다.

리뷰 담당 Claude는 이 부분을 포착하여, 「Vercel의 서버리스 환경에서 52MB의 JSON을 매번 읽는 구성은 콜드 스타트(cold start)를 악화시킨다. ISR 재검증 시의 동작도 로컬과 달라질 가능성이 있다. 다음 페이즈로 넘어가기 전에 이 문제를 해결해야 한다」라고 지적하며, 해결책을 3가지 안(경량 인덱스 추출 / 1건당 1파일 분할 / 외부 스토리지)으로 비교한 뒤 수정 지시 프롬프트를 만들어 주었습니다.

결과적으로 「목록용 경량 인덱스 2.45MB + 상세 정보는 1개 제도당 1파일」이라는 하이브리드 구성으로 결정되었고, 운영 환경에서 문제가 발생하기 전에 구조 자체를 해결할 수 있었습니다.

인간인 제가 이 보고를 읽었다면, 「빌드 성공」이라는 글자에 안심하고 전달 사항을 대충 훑어보고 지나쳤을 것입니다. AI의 보고서는 AI에게 읽게 하는 것이 누락을 줄인다는 것을 실감했습니다.

또 하나 리뷰 담당(Reviewer) 덕분에 도움을 받은 것이 블로그 기사의 팩트 체크 (Fact Check) 설계입니다. 처음에는 "기사를 작성한 후, 그대로 AI에게 내용을 확인 및 수정하게 하면 된다"라고 생각했습니다. 하지만 리뷰 담당으로부터 검증과 수정을 한꺼번에 맡기면, 어디가 틀렸고 무엇을 고쳤는지 인간이 추적하기 어려워진다는 지적을 받았습니다.

그래서 "먼저 불일치 사항을 보고만 한다", "수정은 인간이 확인한 후 별도의 공정에서 수행한다"라는 흐름으로 변경했습니다. 이 분리가 실제로 무엇을 방지했는지는 다음 장에서 말씀드리겠습니다.

YMYL 영역이었기에, 일부러 "완전 자동화하지 않는" 설계로 했다

이 사이트는 급여금·수당이라는 돈과 관련된 정보를 다룹니다. 이른바 YMYL (Your Money or Your Life) 영역으로, 금액을 한 자리만 틀려도 독자에게 실질적인 피해를 줄 수 있습니다.

그래서 AI 활용 기사임에도 역설적이게도, "AI가 자동으로 할 수 있는 일"에 인간의 게이트 (Gate)를 의도적으로 끼워 넣었습니다.

팩트 체크를 "보고와 수정"으로 분리하기

전 장에서 언급한 "검증과 수정의 분리"의 구체적인 형태입니다. 블로그 기사는 Claude Code가 초안을 작성하지만, 공개 전에 모든 기사의 사실 주장(금액·대상자·기한)을 웹 검색을 통해 1차 정보원과 대조하게 하고, 그 결과를 표 형식의 문서로 기록하게 합니다. 프롬프트(Prompt)에서는 다음과 같이 표현하고 있습니다.

각 기사에 대해, 본문 중의 모든 사실 주장을 추출하고,
1차 정보원과 대조하여 검증할 것.
불일치·확인 불가능한 항목은 기사를 수정하지 말고 보고만 할 것
...

실제로 이 메커니즘을 통해 10개 기사 중 2건의 불일치가 발견되었습니다. 하나는 제도 시작 경위에 대한 설명의 차이였고, 다른 하나는 신청 창구가 되는 실시 주체에 대한 기술 오류였습니다. 두 가지 모두 "탐지 → 인간이 수정 필요 여부 판단 → 수정 → 재검증"의 흐름으로 해결했습니다. 탐지와 수정을 나누는 것은 한 단계가 더 추가되지만, AI가 "검증하는 김에 잘해보려고 멋대로 써버리는" 사고를 구조적으로 방지할 수 있습니다.

주간 자동 운용도 "공개만큼은 절대로 시키지 않는다"

사이트 운용은 Claude Code의 스케줄 실행에 맡기고 있지만, 그 지시서 (SKILL.md)에는 다음과 같이 적혀 있습니다.

**공개 판단 (draft: false로 변경)은 반드시 사용자가 수행한다.
이 루틴이 자동으로 공개하는 일은 절대로 없다.**

나아가, 이미 공개된 기사의 내용 수정은 main 브랜치로의 직접 커밋을 금지하고, 반드시 리뷰용 브랜치로 격리합니다. 빌드 실패 시의 재시도(Retry)는 2회까지, 본방 확인에 실패하면 자동으로 revert, 무인으로 건드려도 좋은 코드 수정은 3가지 종류로 한정하여 열거하는 방식 등, "해서는 안 되는 일"을 "할 수 있는 일"보다 더 정성스럽게 적어두고 있습니다.

무인 실행되는 AI에게 전달하는 지시서는 성선설에 기반해 작성하면 사고가 납니다. "망설여지면 쓰지 않는다·공개하지 않는다·로그에 남겨 인간에게 묻는다"라는 안전 중심의 원칙을 명문화해 두는 것을 추천합니다.

솔직한 이야기: 압축할 수 없었던 것들

좋은 점만 쓰면 공정하지 않기에 한계점도 적어둡니다.

Google의 평가 시계는 압축할 수 없습니다. 사이트는 2일 만에 만들 수 있어도, 검색 엔진에 인덱싱(Indexing)되고 순위가 매겨지며 수익이 발생하기까지의 수개월은 예전과 마찬가지로 걸립니다. 그렇기에 "빨리 공개해서 크롤링(Crawling) 시계를 돌리기 시작하는 것"에 가치가 있었다고도 할 수 있습니다.

계정 조작은 결국 인간의 몫입니다. DNS 설정, 애널리틱스(Analytics) 프로퍼티 생성, 도메인 구매. 이 부분은 AI에게 인증 정보를 넘기는 리스크가 더 크기 때문에 제가 직접 움직였습니다. 2일 중 체감상 2~3할은 이런 종류의 작업입니다.

과거의 실패 자산이 없으면 이 속도는 나오지 않습니다. 저는 동일한 유형의 사이트를 2개 운영하고 있으며, 그 과정에서 밟았던 지뢰(내용이 빈약한 페이지로 인한 광고 심사 탈락, 구조화 데이터에 의도치 않은 URL 혼입 등)에 대한 대책을 프롬프트에 심어 넣을 수 있었습니다. 첫 번째 사이트부터 이 속도가 나오는 것은 아니라는 점을 솔직하게 밝혀둡니다.

요약

• Claude (설계 리뷰) × Claude Code (구현) × 인간 (승인)의 삼자 분업으로, 데이터베이스 사이트 구축이 실질적으로 2일 만에 완료되었다
• 속도의 원천은 "단계 분할 + 체크포인트"와 "AI의 보고를 AI가 리뷰하게 하는" 체제
• YMYL 영역에서는 의도적으로 자동화를 멈추는 인간 게이트(공개 승인·팩트 체크의 탐지와 수정 분리)를 설치한다
• 단, SEO 시간과 계정 조작은 압축할 수 없다

비슷한 체제를 구축하려는 분들께 참고가 된다면 좋겠습니다.

Discussion