AI 코딩 도구는 처음에는 시간을 아껴주는 것처럼 느껴집니다. 실제로도 작은 구현이나 반복 수정에서는 빠릅니다. 다만 사용 방식이 정리되지 않으면 비용이 예상보다 빨리 늘어납니다.

Daejin Lab을 만들면서 비용을 늘리는 건 도구 자체보다 “같은 설명을 반복하는 방식”이라는 생각이 들었습니다.

같은 설명을 계속할 때

프로젝트 구조, 금지사항, 배포 방식, 검증 명령을 매번 다시 설명하면 컨텍스트가 길어집니다.

이 프로젝트는 Astro 기반이다.
배포는 Cloudflare Pages다.
출력 폴더는 dist다.
공개 주소는 pages.dev다.
API 키와 토큰은 커밋하지 않는다.
자동 발행은 하지 않는다.

이런 내용은 대화로 계속 반복할 게 아니라 파일로 남기는 편이 낫습니다. 이 프로젝트에서는 상위 AGENTS.md와 블로그 운영 문서가 그 역할을 합니다.

큰 작업을 한 번에 맡길 때

“블로그를 완성해줘” 같은 요청은 편하지만 비쌉니다. 중간에 방향이 틀어지면 다시 읽고, 다시 설명하고, 다시 고쳐야 합니다.

저는 지금 아래 순서로 나눕니다.

구조 확인
계획 작성
파일 1~3개 수정
빌드 확인
다음 단계 진행

작게 나누면 속도가 느려 보이지만, 실패했을 때 되돌리는 비용이 줄어듭니다.

에러를 대충 설명할 때

“안 됩니다”라고만 말하면 도구는 원인을 추측합니다. 그러면 대화가 길어지고, 엉뚱한 파일을 건드릴 가능성도 커집니다.

에러가 있으면 최소한 아래를 같이 줍니다.

실행한 명령어
전체 에러 메시지
관련 파일 경로
직전에 바꾼 내용
원하는 완료 기준

예를 들어 Search Console 문제가 있을 때도 “sitemap이 안 돼요”보다 “/sitemap.xml은 200이고 XML 파싱도 되는데 GSC 화면은 가져올 수 없음으로 남아 있다”라고 쓰는 편이 훨씬 낫습니다.

검증을 말로만 끝낼 때

도구가 “될 것 같다”고 말해도 실제로 되는지는 별개입니다. Daejin Lab에서는 최소한 아래 명령을 고정했습니다.

npm run build

배포 뒤에는 공개 URL도 확인합니다.

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

이 검증을 빼면 비용을 아낀 것처럼 보여도 나중에 재작업 비용이 더 커질 수 있습니다.

지금 정한 습관

현재는 아래 습관을 유지하려고 합니다.

큰 목표를 바로 실행하지 않고 단계로 나눈다.
수정 전 관련 파일을 먼저 읽는다.
한 번에 너무 많은 파일을 바꾸지 않는다.
npm run build로 확인한다.
성공한 절차는 문서나 wiki에 남긴다.
같은 문제를 두 번 설명하지 않게 한다.

비용 관리는 단순히 토큰을 아끼는 문제가 아니었습니다. 잘못된 자동화로 생기는 재작업을 줄이는 일이 더 컸습니다.

이번 블로그 작업에서 확인한 비용 포인트

이번 작업에서도 비용을 늘리는 지점은 분명했습니다. sitemap 문제를 계속 고치려고 하면 코드 변경은 많아지지만 실제 개선은 없을 수 있습니다. 반대로 한 번 점검해서 정상 조건을 확인한 뒤에는 콘텐츠 품질 개선으로 넘어가는 편이 낫습니다.

이번에 고정한 판단은 아래와 같습니다.

sitemap: 200 OK, XML 파싱 성공, Googlebot 유사 요청 성공이면 동결
콘텐츠: 기존 31개 글 중 약한 10개부터 보강
카테고리: 개발 자동화와 로컬 LLM을 우선 보강
브랜딩: 큰 리디자인보다 파비콘/OG/문구부터 정리
검증: npm run build를 통과하지 않으면 완료로 보지 않음

토큰과 시간은 “무엇을 더 고칠지”보다 “이제 무엇은 그만 고칠지”를 정할 때 더 많이 아껴졌습니다.

비용을 줄이는 기준

코딩 도구 비용을 줄이는 핵심은 멋진 프롬프트보다 좋은 작업 구조였습니다. 설명을 문서화하고, 일을 작게 나누고, 검증 명령을 고정하면 비용과 시행착오를 같이 줄일 수 있습니다.