에이전트에게 맡길 일과 직접 볼 일

에이전트에게 일을 맡기다 보면 처음에는 뭐든 시켜보고 싶어집니다. 저도 그랬습니다. 글 정리, 코드 수정, 빌드 확인까지 잘하니 “그냥 다 맡겨도 되나” 싶은 순간이 있었습니다.

그런데 Daejin Lab을 손보면서 금방 선이 보였습니다. 반복 확인은 맡길 수 있지만, 공개 판단이나 방향 결정까지 넘기면 글이 이상하게 매끈해집니다. 빠르긴 한데 제가 운영하는 블로그라는 느낌이 약해졌습니다.

맡기기 좋은 일

에이전트에게 맡기기 좋은 일은 결과물이 분명하고 되돌리기 쉬운 작업입니다.

프로젝트 구조 읽기
관련 파일 후보 찾기
Markdown 글의 반복 표현 줄이기
작은 컴포넌트 수정
빌드 에러 원인 후보 정리
변경사항 요약
다음 작업 체크리스트 작성

이번 블로그에서는 기존 글을 보강할 때 특히 유용했습니다. 예를 들어 “일반론이 많은 글 10개를 찾아서 실제 구축 환경, 명령어, 막힌 지점을 넣는다”는 작업은 범위가 분명합니다. 수정 후 npm run build로 바로 확인할 수도 있습니다.

맡기기 애매한 일

반대로 정답이 하나가 아닌 일은 그대로 맡기기 어렵습니다.

블로그 주제 최종 결정
브랜드 이름 결정
도메인 구매 여부
AdSense 신청 시점
유료 도구 결제 여부
계정 권한 설정
법률·세무·투자 판단

이런 작업은 의견을 참고할 수는 있어도 최종 판단을 넘기면 안 됩니다. 특히 결제, 계정, 공개 범위는 실수했을 때 되돌리기가 어렵습니다.

요청할 때 넣는 정보

제가 안정적이라고 느낀 요청 형식은 아래에 가깝습니다.

목표: 기존 블로그 글을 승인 준비 관점에서 보강한다.
현재 상태: Astro 블로그, Markdown 글 30~40개 수준, Cloudflare Pages 배포.
원하는 결과물: 실제 경험과 명령어가 들어간 보강 문단.
제약 조건: 자동 발행 금지, API 키 노출 금지.
완료 기준: npm run build 성공, 공개 URL 확인.

“좋은 글로 만들어줘”라고만 하면 도구가 추측을 많이 합니다. 반대로 현재 상태와 완료 기준을 주면 훨씬 덜 흔들립니다.

끝난 뒤 확인할 것

에이전트가 끝났다고 해서 바로 믿지는 않습니다. 최소한 아래는 직접 확인합니다.

npm run build

배포한 뒤에는 공개 사이트도 봅니다.

/blog/
/categories/
/sitemap.xml
수정한 글 URL

Search Console처럼 외부 서비스가 끼어 있으면 더 조심해야 합니다. 화면에는 아직 “가져올 수 없음”이 남아 있어도, 실제 파일이 200으로 열리고 XML 파싱이 되면 다른 판단이 필요합니다.

오토파일럿으로 맡길 때의 제한선

이번 블로그 보강 작업은 에이전트에게 맡기기 좋은 편에 속합니다. 수정 대상 파일이 분명하고, 빌드로 결과를 확인할 수 있기 때문입니다.

다만 오토파일럿으로 진행해도 멈춰야 하는 선은 따로 둡니다.

가능: 글 보강, 내부 링크 정리, 파비콘/OG 같은 로컬 자산 추가
가능: npm run build, sitemap 생성 결과 확인, git diff 확인
주의: 로컬 커밋은 작업 단위가 명확할 때만
중단: git push, Search Console 콘솔 조작, 결제, 계정 설정 변경

이렇게 선을 나누면 “알아서 진행”과 “내 승인 없이 하면 안 되는 일”이 섞이지 않습니다. 개인 프로젝트에서는 이 구분이 특히 중요했습니다.

실제로 맡겼던 이번 작업

Daejin Lab 보강에서는 에이전트에게 아래처럼 작은 단위를 맡겼습니다.

브랜치 만들기
짧은 글 후보 5개 고르기
updatedDate와 본문 보강하기
npm run build로 깨지는지 보기
감사 스크립트로 짧은 글 지표 다시 확인하기
커밋 메시지에 검증 결과 남기기

이 범위는 실패해도 되돌릴 수 있고, 결과도 git diff와 빌드로 확인할 수 있습니다. 반대로 push, Search Console 조작, AdSense 신청, 실제 문의 이메일 공개처럼 외부에 영향을 주는 일은 멈춤선으로 남겼습니다.

이런 분리는 작업을 작게 나눠 프롬프트에 넣는 방법과 개인 프로젝트에 AGENTS.md를 두는 이유에서 정한 운영 방식과도 연결됩니다. 요청을 작게 자를수록 에이전트는 더 잘하고, 책임 경계가 흐려질수록 사람이 다시 확인할 일이 늘어납니다.

검증 가능한 일만 맡긴다

에이전트는 작업자를 없애는 도구라기보다, 작게 나눈 일을 빠르게 처리하는 보조자에 가깝습니다.

검증 가능한 일은 맡긴다.
책임이 따르는 판단은 직접 한다.

이 기준을 지키면 개인 블로그, 개발 자동화, 글감 관리 같은 작업에서 꽤 안전하게 쓸 수 있습니다. 특히 블로그 운영에서는 “글을 고쳤다”보다 “고친 뒤 빌드와 공개 확인까지 했는가”가 더 중요합니다. 배포 후 확인 흐름은 Cloudflare Pages 배포 후 새 글이 실제로 보이는지 확인하는 법에 따로 남겼습니다.

이번 사이트 작업에서 나눈 역할

Daejin Lab을 보강할 때도 에이전트에게 모든 판단을 맡기지는 않았습니다. 수정 가능한 파일 작업과 승인 경계가 있는 작업을 분리해두니 진행이 훨씬 안정적이었습니다.

작업	에이전트에게 맡긴 범위	직접 봐야 하는 범위
코드 수정	Astro 컴포넌트, CSS, 글 목록 구조 수정	디자인 방향과 최종 느낌 판단
콘텐츠 보강	약한 글 후보, 표와 내부 링크 추가	실제 경험으로 말할 수 있는지 확인
검증	빌드 실행, diff 요약	Search Console 화면의 최종 상태 판단
배포	커밋 메시지 초안과 변경 요약	push, AdSense 신청, 외부 콘솔 조작 승인

이 선은 Claude Code를 프로젝트 작업 비서처럼 쓰는 법과 발행 버튼을 자동화하지 않기로 한 이유에서 정한 원칙과 같습니다. 빠르게 처리하되, 책임이 있는 버튼은 사람이 눌러야 합니다.

맡기기 전에 적어둘 선

지금은 에이전트에게 맡길 일을 조금 좁게 봅니다. 파일을 찾고, 짧은 글을 골라내고, 빌드를 돌리고, sitemap 숫자를 확인하는 일은 맡깁니다. 기준이 분명하기 때문입니다.

반대로 제목을 얼마나 세게 쓸지, AdSense 신청을 지금 누를지, Search Console 상태를 기다릴지 같은 판단은 제가 봅니다. 도구가 빠르게 움직일수록, 멈추는 결정은 사람이 해야 한다는 쪽으로 기준을 잡았습니다.

에이전트가 일을 잘해도 이상하게 제가 더 피곤한 순간이 있었습니다. 결과는 빠르게 나오는데, 그 결과가 맞는지 확인하느라 다시 처음부터 읽어야 할 때였습니다. 다음에는 요청하기 전에 “검증 방법”과 “멈출 지점”을 먼저 적어두려고 합니다.

2026-05-31에 다시 본 좋은 작업과 나쁜 작업

AI 에이전트에게 무엇을 맡길지의 기준은 AdSense 대응에서 더 분명해졌습니다. 약한 글 후보를 찾고, 링크와 이미지 누락을 계산하고, build를 돌리는 일은 잘 맞았습니다. 반대로 AdSense 콘솔의 재검토 버튼을 누르거나 공개 책임을 넘기는 일은 맞지 않았습니다.

반복 작업, 검색, 판단, 승인으로 나누는 AI 에이전트 작업 경계 카드

이 카드는 AI 에이전트에게 맡기기 좋은 일과 사람이 남길 일을 구분합니다.

참고한 공식 문서

확인하지 않은 것

이 글은 특정 AI 에이전트 제품 순위가 아닙니다. 작업 유형을 나누는 기준입니다. 도구 성능은 권한, 파일 접근, 테스트 가능성에 따라 달라집니다.

FAQ

AI 에이전트에게 가장 잘 맞는 일은 무엇인가요?

파일 찾기, 반복 수정, 정적 검사, build 실행처럼 결과를 바로 확인할 수 있는 일입니다.

맡기면 위험한 일은 무엇인가요?

계정 조작, 결제, 공개 발행, 법률·투자 판단처럼 외부 책임이 큰 작업입니다.

좋은 작업 기준은 무엇인가요?

범위가 작고, 되돌릴 수 있고, 검증 명령이 있는 작업입니다.

이번 재검토에서 이 글의 결론은 더 단순해졌습니다. 에이전트가 잘하는 일은 반복과 검증이고, 사람이 남겨야 하는 일은 공개 책임과 최종 판단입니다. 이 선이 흐려지면 편의보다 사고 가능성이 커집니다. 좋은 작업을 고르는 기준이 있어야 에이전트 사용도 비용이 아니라 도구가 됩니다.