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

처음에는 저도 프롬프트 문장에 집착했습니다. 더 정확하게 쓰고, 조건을 더 길게 붙이고, 금지사항을 촘촘하게 넣으면 AI가 알아서 좋은 결과를 줄 거라고 생각했습니다.

그런데 Daejin Lab을 고치다 보니, 막히는 지점은 프롬프트 문장이 아니었습니다. 일을 너무 크게 던지는 게 문제였습니다. “블로그를 좋게 해줘”라고 하면 결과는 그럴듯한데, 나중에 보면 제가 원한 방향과 조금씩 어긋났습니다.

오히려 잘 먹혔던 요청은 훨씬 작았습니다.

이 글의 첫 문단을 경험담으로 바꾸고,
내부 링크를 확인하고,
build를 돌려줘.

이 정도로 쪼개면 제가 확인할 수 있었습니다. 그때부터 프롬프트보다 작업 분해를 먼저 보게 됐습니다.

큰 요청은 자주 흔들린다

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

글쓰기부터 배포와 검수까지 전부 자동으로 굴러가는 블로그 시스템을 만들어줘.

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

블로그 주제 선정
기술 스택 결정
글감 관리
글 작성
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 관련 파일.
하지 말아야 할 것: 도메인 확정 전에는 canonical을 바꾸지 않는다.
완료 기준: npm run build 성공, sitemap.xml 200, sitemap URL 수 확인.

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

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

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

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

이번 5개 글 보강도 이렇게 나눴다

이번 작업에서도 “남은 글을 전부 좋게 만들어줘”가 아니라, 감사 결과에서 약한 글 5개만 골랐습니다.

대상: 내부 링크가 0~1개이고 대표 이미지가 없는 글
수정 범위: 기존 글 5개
보강 기준: 실제 운영 메모, 내부 링크 2개 이상, 기존 OG 이미지 연결
검증 기준: npm run build, 로컬 HTML snippet, sitemap URL 수, 내부 링크 누락 확인
하지 않은 것: git push, Cloudflare 배포, Search Console 콘솔 조작

이렇게 나누면 작업이 끝났는지 보기가 쉬웠습니다. 코딩 도구 비용이 늘어나는 순간에서 적은 것처럼, 비용을 줄이는 방법은 모델을 덜 쓰는 것보다 재작업이 덜 생기게 만드는 쪽에 가까웠습니다.

도구에게 맡길 일과 사람이 잡을 일

작업을 쪼갤 때는 “무엇을 시킬지”만이 아니라 “어디서 멈출지”도 같이 정해야 했습니다. Daejin Lab 작업에서는 도구가 잘하는 일과 사람이 판단해야 하는 일이 꽤 분명하게 나뉘었습니다.

도구에게 맡긴 일: 약한 글 후보 추출, 내부 링크 수 계산, 빌드 실행, sitemap URL 수 확인
사람이 잡을 일: 어떤 글을 먼저 고칠지, 과장된 표현을 뺄지, push할지 말지, 콘솔을 조작할지 말지

이 경계를 정하지 않으면 작은 보강 작업도 금방 커집니다. 예를 들어 내부 링크가 부족하다는 이유만으로 모든 글을 한 번에 고치기 시작하면, 검증 범위가 커지고 어떤 변경이 효과가 있었는지 보기 어려워집니다. 반대로 5개씩 끊어서 수정하면 감사 지표가 어떻게 바뀌는지 그때그때 볼 수 있습니다.

이번 작업에서도 git push와 Cloudflare 배포는 일부러 하지 않았습니다. 코드와 콘텐츠를 로컬 커밋으로 묶고, 빌드와 로컬 HTML 확인까지 끝낸 뒤 멈추는 것이 안전한 완료 기준이었습니다. 이 기준은 발행 버튼을 자동화하지 않기로 한 이유와 같은 운영선입니다.

다시 쓸 때 남긴 기준

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

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

Daejin Lab에서 쪼갠 실제 단위

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

기술 SEO 정리: title, description, canonical, sitemap 확인
AdSense 준비: 약한 글 선별 후 실제 운영 맥락 추가
UX 보강: 홈, 글 목록, 글 상세에서 신뢰 요소 확인
검증: npm run build 통과 후 diff와 내부 링크 확인

이 방식은 블로그 초안 검수 체크리스트와도 연결됩니다. 초안이든 코드 수정이든, 큰 요청을 작은 검증 단위로 바꿔야 사람이 마지막 판단을 하기 쉬웠습니다. 배포 단계에서는 Cloudflare Pages 배포 후 꼭 확인하는 체크리스트를 같이 봅니다.

프롬프트보다 먼저 자를 것

이 글을 다시 보면서 제일 먼저 든 생각은 “문장이 아니라 단위가 문제였구나”였습니다.

좋은 프롬프트도 있어야 합니다. 다만 큰 일을 한 번에 던지면 결과를 보기도, 고치기도 어려웠습니다. 긴 프롬프트를 쓰면 뭔가 통제하고 있다는 느낌은 듭니다. 하지만 목표가 큰 상태라면, 문장이 길어져도 일은 여전히 큽니다.

그래서 앞으로는 요청을 작게 자르는 쪽을 먼저 볼 생각입니다. 파일 찾기, 문장 수정, 링크 확인, 빌드 검증처럼 단계가 나뉘면 AI도 덜 헷갈리고, 저도 결과를 덜 불안하게 볼 수 있었습니다.

2026-05-31에 다시 보니 부족했던 점

이 글은 원래 프롬프트보다 작업 분해가 중요하다는 기준을 말하는 글이었습니다. 그런데 애드센스 실패 뒤 다시 보니, 말은 맞지만 증거가 약했습니다. 그래서 Daejin Lab에서 실제로 쓰는 “작게 자르고 확인하는 흐름”을 공개용 카드로 추가했습니다.

큰 요청을 범위, 검증, 승인 단계로 나누는 작업 분해 흐름

이 흐름은 프롬프트 요령이 아니라 운영 방식입니다. 큰 요청을 작은 파일·검증·승인 단위로 나누면, AI가 만든 결과를 사람이 확인하기 쉬워집니다.

이번 애드센스 대응도 같은 방식으로 진행했습니다. “사이트 전체를 좋게 해줘”가 아니라 짧은 공개 글 5개, 공식 출처, 본문 증거 이미지, FAQ, build 검증처럼 끝나는 조건을 나눴습니다. 한 번에 다 고치려 했다면, 아마 무엇이 좋아졌는지 저도 설명하기 어려웠을 겁니다.

참고한 공식 문서

작업 분해 자체는 Daejin Lab 운영 판단이지만, AI 도구를 쓸 때의 지시 구조와 콘텐츠 품질 기준은 공식 문서를 같이 봅니다.

공식 문서를 그대로 옮기려는 목적은 아닙니다. 제 기준은 더 단순합니다. 작업을 작게 자르고, 확인 가능한 결과를 남기고, 공개 책임이 있는 단계는 사람이 결정합니다.

확인하지 않은 것

이 글은 모든 AI 도구에 통하는 정답 프롬프트를 제시하지 않습니다. 도구마다 권한, 파일 접근, 실행 방식이 다릅니다. 그래서 “좋은 문장 하나”보다 “검증 가능한 작은 단위”를 우선 기준으로 둡니다.

FAQ

프롬프트를 길게 쓰면 더 안전하지 않나요?

항상 그렇지는 않았습니다. 긴 프롬프트 안에 서로 다른 목표가 섞이면 결과가 더 흔들렸습니다. 범위와 완료 기준을 분리하는 쪽이 더 안전했습니다.

작업 분해의 최소 단위는 어느 정도인가요?

제가 쓰는 기준은 파일 1~~5개, 검증 명령 1~~3개, 되돌릴 수 있는 변경입니다. 그보다 커지면 먼저 계획으로 분리합니다.

애드센스 대응에도 이 방식이 필요한가요?

필요했습니다. 글 수를 늘리는 요청은 너무 큽니다. 약한 글을 고르고, 각 글에 근거와 한계를 추가하고, 빌드와 라이브 확인을 따로 보는 식으로 잘라야 했습니다.

이번 재검토에서 다시 쓴 요청 단위

이번 애드센스 대응을 하면서 실제로 쓴 단위는 더 작았습니다. “가치가 별로 없는 콘텐츠를 해결한다”는 말은 방향일 뿐이고, 작업 지시는 아래처럼 바뀌어야 했습니다.

대상 글 5개를 고른다.
각 글에 공개용 증거 카드 1개를 만든다.
공식 출처를 2개 이상 붙인다.
확인하지 않은 것을 분리한다.
FAQ를 추가한다.
build와 publish gate를 통과한다.
라이브 URL에서 실제 반영을 확인한다.

이렇게 적어야 완료 여부가 보였습니다. “글을 좋게 만든다”는 말은 끝이 없습니다. 반대로 이미지가 들어갔는지, 공식 출처가 있는지, sitemap에 남아 있는지, 콘솔 에러가 없는지는 눈으로 볼 수 있습니다. 제가 큰 목표보다 작은 완료 기준을 먼저 쓰게 된 이유가 여기에 있습니다.

이 글에서 다시 확인한 마지막 기준

이 글은 프롬프트 문장 모음이 아니라 작업을 자르는 기준을 남기는 글이어야 했습니다. 그래서 공개 글에서 볼 부분은 “어떤 표현을 쓰면 AI가 잘 답하는가”보다, “어떤 단위로 나누면 사람이 결과를 확인할 수 있는가”입니다.

이번 보강에서도 큰 목표를 바로 실행하지 않았습니다. 글 5개, 증거 카드, 공식 출처, FAQ, build 검증처럼 끝나는 조건을 나눴습니다. 이렇게 해야 실패해도 되돌릴 수 있고, 성공해도 무엇이 좋아졌는지 설명하기 쉽습니다.

작업 분해를 잘하면 실패도 작아집니다. 한 번에 전체 사이트를 바꾸면 어디서 잘못됐는지 찾기 어렵지만, 글 5개와 검증 명령을 묶으면 되돌릴 수 있습니다. 다음번에도 저는 아마 프롬프트 문장을 다듬기 전에, 먼저 일을 어디까지 자를지부터 적을 것 같습니다.