마지막 수정:

프롬프트보다 중요한 작업 분해 방식


AI 도구를 쓰다 보면 좋은 프롬프트를 찾게 됩니다. 저도 처음에는 문장 하나를 잘 쓰면 결과가 확 좋아질 거라고 생각했습니다.

그런데 Daejin Lab을 만들면서 느낀 건 조금 달랐습니다. 프롬프트보다 먼저 필요한 건 작업을 작게 나누는 일이었습니다.

큰 요청은 자주 흔들린다

예를 들어 이런 요청은 보기에는 편합니다.

수익형 블로그를 자동으로 운영하는 시스템을 만들어줘.

하지만 이 안에는 너무 많은 일이 섞여 있습니다.

블로그 주제 선정
기술 스택 결정
글감 관리
글 작성
SEO 설정
배포 자동화
수익화 정책 검토
운영 루틴 설계

이렇게 던지면 결과가 크고 모호해집니다. 도구가 뭔가 많이 해주긴 하는데, 나중에 보면 내가 원한 방향과 어긋난 부분을 다시 고쳐야 합니다.

이번 블로그는 이렇게 쪼갰다

Daejin Lab은 처음부터 “블로그 5개 운영”을 바로 만들지 않았습니다. 먼저 1호 블로그만 잘게 나눴습니다.

1호 블로그 주제 정하기
Astro 프로젝트 만들기
GitHub 저장소 연결하기
Cloudflare Pages 배포하기
Search Console 인증하기
sitemap 제출하기
초기 글 채우기
카테고리 페이지 추가하기
AdSense 준비 관점으로 글 보강하기

각 단계마다 성공 기준도 따로 잡았습니다. 예를 들어 배포 단계는 단순했습니다.

공개 URL이 열린다.
/blog/에서 글 목록이 보인다.
/sitemap.xml이 200으로 열린다.

글 보강 단계는 기준이 다릅니다.

일반론을 줄인다.
실제 환경을 넣는다.
막힌 지점을 넣는다.
명령어나 URL 구조를 넣는다.
npm run build가 통과한다.

기준이 작아지면 결과를 확인하기 쉬워집니다.

제가 쓰는 요청 형식

지금은 요청을 보통 아래처럼 씁니다.

목표:
현재 상태:
수정할 범위:
하지 말아야 할 것:
완료 기준:

예시는 이렇습니다.

목표: Search Console sitemap 문제를 점검한다.
현재 상태: Cloudflare Pages에 Astro 블로그가 배포되어 있다.
수정할 범위: robots.txt, astro.config.mjs, sitemap 관련 파일.
하지 말아야 할 것: 도메인 확정 전 daejinlab.com으로 canonical을 바꾸지 않는다.
완료 기준: npm run build 성공, sitemap.xml 200, sitemap URL 42개 확인.

이렇게 쓰면 도구가 덜 넘겨짚습니다. 특히 “하지 말아야 할 것”을 적어두면 불필요한 대형 수정을 줄일 수 있습니다.

AdSense 준비에도 같은 방식이 맞다

AdSense 준비도 “승인되게 해줘”라고 쓰면 너무 큽니다. 실제 작업 단위는 더 작습니다.

소개 페이지 신뢰도 확인
문의 페이지 확인
개인정보처리방침 확인
광고·제휴 고지 확인
일반론 많은 글 10개 보강
직접 경험형 글 확보
Search Console 색인 확인

지금 Daejin Lab은 글 수만 늘리는 단계는 지났고, 각 글에 실제 작업 흔적을 넣는 단계에 있습니다. 이건 자동으로 많이 쓰는 것보다, 좁은 범위를 정해서 고치는 편이 낫습니다.

다시 쓸 때 남긴 기준

좋은 프롬프트 하나가 모든 걸 해결해주지는 않았습니다. 효과가 있었던 건 일을 작게 나누고, 각 단계마다 확인 기준을 둔 방식이었습니다.

AI 도구는 이 구조 안에 넣었을 때 훨씬 실용적입니다. 큰 목표를 작은 완료 기준으로 쪼개면, 블로그 운영도 개발 작업도 덜 흔들립니다.

Daejin Lab에서 쪼갠 실제 단위

이번 블로그 보강에서도 “사이트를 좋게 만들어줘”라고 한 번에 맡기지 않았습니다. 실제로는 아래처럼 완료 기준을 나눠서 봤습니다.

큰 목표작게 나눈 작업완료 기준
기술 SEO 정리title, description, canonical, sitemap 확인중복 title과 짧은 description 수정
AdSense 준비약한 글 10개 선별각 글에 표, 내부 링크, 실제 운영 맥락 추가
UX 보강홈, 글 목록, 글 상세 개선Lab Status, 카테고리 카운트, 작성자 카드 노출
검증빌드와 공개 반영 확인npm run build 통과 후 diff 확인

이 방식은 블로그 초안 검수 체크리스트와도 연결됩니다. 초안이든 코드 수정이든, 큰 요청을 작은 검증 단위로 바꿔야 사람이 마지막 판단을 하기 쉬웠습니다.