AI로 개인 블로그를 만들 때 어디까지 맡겨도 될까, 직접 나눈 역할과 검증 기준
개인 블로그 제작과 운영에서 AI에게 맡기기 좋은 작업, 사람이 승인해야 할 결정, 위험도별 중단 기준과 실제 검증 순서를 정리합니다.
AI 코딩 도구를 처음 사용할 때는 어디까지 할 수 있는지가 가장 궁금했습니다. 직접 써보니 사이트 구조를 만들고 여러 파일을 수정하는 것뿐 아니라 기존 콘텐츠 이전, 오류 분석, 빌드와 서버 배포까지 도움받을 수 있었습니다. 웹개발 경험이 많지 않았던 제가 Ghost 블로그를 Astro로 옮기고 지금의 minml을 운영할 수 있었던 것도 그 덕분입니다.
하지만 작업 범위가 넓어질수록 질문은 달라졌습니다. 할 수 있는 일과 맡겨도 되는 일은 같지 않았습니다. AI가 정확한 명령을 만들 수 있어도 어느 서버를 바꿀지, 어떤 글을 공개할지, 백업 없이 삭제해도 되는지를 스스로 결정하게 할 수는 없습니다. 화면이 잘 열려도 내용이 사실인지, 개인정보가 섞이지 않았는지까지 자동으로 보장되지는 않습니다.
지금은 AI와 사람의 역할을 도구 이름으로 나누지 않습니다. AI는 조사·초안·반복 작업·검사를 빠르게 수행하고, 저는 목적·범위·공개 여부·되돌리기 어려운 변경을 결정합니다. 이 글은 그 기준을 실제 개인 블로그 제작 과정에 맞춰 정리한 기록입니다.
역할은 기획·제작·검증·공개의 네 단계로 나눴습니다
AI에게 “사이트를 만들어줘”라고 한꺼번에 맡기면 결과는 나올 수 있습니다. 다만 문제가 생겼을 때 어느 판단부터 다시 해야 하는지 알기 어렵습니다. 저는 작업을 네 단계로 나누고 각 단계에서 AI가 실행할 일과 제가 승인할 일을 정했습니다.
| 단계 | AI에게 맡긴 일 | 제가 직접 결정하거나 확인한 일 |
|---|---|---|
| 기획 | 기존 파일과 글 목록 조사, 구조안과 대안 제시 | 사이트 주제, 독자, 남길 기능과 버릴 기능 |
| 제작 | 코드·문서 초안, 반복 변환, 여러 파일의 일관된 수정 | 문장의 사실성, 디자인 방향, 공개해도 되는 정보 |
| 검증 | 빌드, 링크·이미지 검사, 차이 비교, 오류 원인 분석 | 검사 기준이 충분한지, 화면과 내용이 의도에 맞는지 |
| 공개 | 승인된 절차에 따라 업로드와 상태 확인 | 배포 시점, 운영 서버 변경, 실패 시 롤백 여부 |
핵심은 사람이 모든 명령을 직접 입력해야 한다는 뜻이 아닙니다. 실제 실행은 AI가 더 빠르고 정확한 경우도 많았습니다. 대신 결과에 영향을 받는 범위와 되돌리는 방법을 사람이 먼저 정해야 했습니다.
AI에게 가장 잘 맞았던 일은 먼저 읽고 반복하는 작업이었습니다
기존 상태를 빠짐없이 조사하기
새 기능을 만들기 전에 어떤 파일과 주소가 이미 있는지 파악하는 일은 AI에게 맡기기 좋았습니다. Ghost에서 Astro로 옮길 때도 먼저 콘텐츠 JSON, 이미지 디렉터리와 기존 URL을 각각 조사했습니다. 원본을 건드리지 않는 읽기 작업이라 결과를 비교하기 쉽고, 빠뜨린 항목도 목록으로 확인할 수 있었습니다.
이번 사이트 구조 개편에서도 공개 글 23편을 먼저 읽고 제작·이전, 운영·보안, AI 활용의 세 묶음으로 나눴습니다. AI가 분류 코드를 만들었지만 주제 이름과 사이트에서 강조할 흐름은 제가 정했습니다. 분류되지 않은 공개 글이 있으면 빌드를 중단하도록 해 새 글이 메뉴에서 빠지는 문제도 막았습니다.
형식이 정해진 반복 작업 처리하기
Ghost에서 Astro로 콘텐츠를 이전할 때 가장 많은 양을 차지한 것은 HTML 본문을 Markdown으로 바꾸고 이미지 주소를 고치는 반복 작업이었습니다. 변환 규칙을 한 번 정한 뒤 여러 글에 적용하고, 결과 개수와 파일 존재 여부를 비교하는 일은 AI가 하기 좋았습니다.
블로그 카드처럼 같은 모양이 반복되는 코드도 마찬가지였습니다. 한 번 만든 목록 컴포넌트를 홈, 전체 글과 세 개의 주제 페이지에서 함께 쓰면 나중에 디자인을 고칠 위치도 줄어듭니다. 사람은 어떤 정보가 카드에 보여야 하는지 결정하고, AI는 같은 규칙이 모든 목록에 적용되도록 구현할 수 있었습니다.
검사 절차를 코드로 옮기기
AI의 결과를 다른 AI 답변으로만 검토하면 같은 전제를 놓칠 수 있습니다. 그래서 정답을 명확히 판정할 수 있는 항목은 실행 가능한 검사로 바꿨습니다.
- 모든 공개 글이 콘텐츠 스키마를 통과하는가
- 내부 링크가 실제 생성 페이지나 지정한 리디렉션으로 이어지는가
- 본문과 대표 이미지의 로컬 파일이 존재하는가
- 공개하지 않을 초안이 목록과 사이트맵에서 제외되는가
- 운영 서버의 새 페이지가
200, 없는 시험 주소가404인가 - 새 릴리스의 디렉터리가
755, 일반 파일이644인가
검사 코드는 AI가 만들고 실행할 수 있지만 무엇을 실패로 볼지는 사람이 정합니다. 예를 들어 홈페이지가 200이어도 존재하지 않는 주소까지 200이면 정상 배포로 보지 않았습니다.
사람이 직접 결정해야 했던 일은 결과보다 경계에 가까웠습니다
사이트가 무엇을 위한 곳인지
AI는 여러 메뉴 이름과 디자인을 제안할 수 있습니다. 그러나 minml을 AI 제품 소식 모음으로 만들지, 개인 블로그 제작과 운영 경험을 기록하는 곳으로 만들지는 제가 선택해야 합니다. 이 목적이 정해져야 어떤 글을 합치고, 무엇을 초안으로 돌리고, 어떤 세 가지 주제를 상단에 보여줄지도 판단할 수 있습니다.
명확한 목적 없이 검색어마다 글을 만들면 각각의 문장은 그럴듯해도 사이트 전체에서는 서로 연결되지 않습니다. 반대로 주제가 정해지면 새 글이 기존 경험을 보충하는지, 단지 비슷한 내용을 다시 쓰는지도 비교할 수 있습니다.
경험과 사실을 어디까지 주장할지
AI는 자연스러운 후기 문장을 만들 수 있지만 제가 하지 않은 경험까지 사실로 만들 수는 없습니다. 작업 시간을 재지 않았다면 정확한 시간을 쓰지 않고, 비용은 결제 시점과 환율에 따라 달라질 수 있다고 밝혔습니다. 서버 상태도 확인한 날짜와 항목의 범위 안에서만 설명했습니다.
특히 “문제가 없었다”, “안전하다”, “무중단이다” 같은 표현은 검사 범위보다 커지기 쉽습니다. 저는 홈페이지와 새 글이 열렸다는 사실을 서버 전체가 안전하다는 결론으로 확대하지 않습니다. 확인한 주소와 권한, 로그의 기간을 구체적으로 적고 그 밖의 가능성은 남겨둡니다.
삭제·계정·서버 설정처럼 영향이 큰 변경
로컬 문장 한 줄을 고치는 일과 운영 서버의 방화벽을 바꾸는 일은 같은 승인 기준을 적용할 수 없습니다. 기존 서비스를 중지하거나 파일을 삭제하는 작업은 먼저 정확한 대상과 백업, 복구 순서를 확인합니다. 다른 사이트가 같은 서버를 사용한다면 작업 대상에서 제외한다고 명시하고, 배포 후에는 응답만 확인합니다.
AI가 명령을 실행할 권한이 있다는 사실은 그 변경을 해도 된다는 승인과 다릅니다. OpenAI도 실제 에이전트 운영에서 기술적 경계를 명확히 하고 위험도가 높은 작업을 명시적으로 드러내는 통제를 설명합니다. Claude Code 역시 허용·차단 도구와 권한 모드를 별도로 제공합니다. 도구마다 화면과 옵션은 달라도, 제 작업에서는 권한과 의사결정을 분리한다는 원칙이 같았습니다.
최종 공개 여부
글이 완성되고 빌드가 통과해도 바로 배포하지 않습니다. 본문, 제목, 설명, 링크, 명령 예시와 이미지에 공개하면 안 되는 값이 없는지 한 번 더 읽습니다. 수정할 때도 같은 검토를 반복합니다. AI가 자동 탐지한 결과가 깨끗하더라도 문맥상 서버 구조를 지나치게 자세히 드러내는 표현은 사람이 판단해야 합니다.
기술 글의 발행 전 보안 검토 과정을 별도 규칙으로 만든 이유도 여기에 있습니다. 명령 자체는 공개해도 괜찮지만 실제 출력에는 IP, 사용자 이름이나 내부 경로가 들어갈 수 있습니다. 코드는 예시 값으로 바꾸고 원본 출력은 싣지 않는 편이 안전했습니다.
작업 위험도에 따라 멈추는 지점도 달리했습니다
모든 행동마다 승인을 요구하면 작업이 지나치게 느려지고, 반대로 모든 권한을 한 번에 주면 실수의 범위가 커집니다. 저는 되돌리기 쉬운지와 외부에 영향을 주는지를 기준으로 세 단계로 나눴습니다.
| 위험도 | 예시 | 진행 기준 |
|---|---|---|
| 낮음 | 파일 읽기, 글 목록 조사, 로컬 검색, 빌드 결과 분석 | 목표 범위 안에서 바로 진행하고 결과 보고 |
| 중간 | 로컬 코드·글 수정, 새 이미지 생성, 테스트 파일 추가 | 변경 내역과 미리보기로 확인한 뒤 커밋 |
| 높음 | 운영 서버 변경, 삭제, 방화벽·인증서 수정, 외부 공개 | 대상·백업·복구 방법을 확인하고 명시적 승인 후 실행 |
위험도는 명령의 길이로 정하지 않습니다. 한 줄짜리 삭제 명령이 수십 파일의 CSS 수정보다 위험할 수 있습니다. 또한 같은 명령도 실행 위치에 따라 달라집니다. 비어 있는 임시 폴더를 지우는 것과 현재 서비스가 읽는 디렉터리를 지우는 일은 전혀 다릅니다.
요청할 때는 목표와 함께 건드리지 않을 범위도 적었습니다
제가 실제 작업에서 가장 자주 사용하는 요청 구조는 다섯 가지입니다.
- 목표: 방문자가 최종적으로 보게 될 결과
- 현재 상태: 기존 기술, 글 수와 이미 알고 있는 문제
- 변경 범위: 수정해도 되는 파일·페이지·서비스
- 제외 범위: 삭제하지 않을 데이터와 건드리지 않을 다른 사이트
- 완료 조건: 빌드, 링크, 화면, 보안과 공개 응답 기준
예를 들어 “메뉴를 보기 좋게 바꿔줘”보다 다음처럼 요청하면 검토 기준이 분명해집니다.
기존 글 주소와 디자인의 기본 분위기는 유지한다. 공개 글을 세 개의 명확한 주제로 나누고 상단 메뉴, 주제별 목록과 전체 글 페이지를 만든다. 모든 공개 글이 정확히 한 주제에 포함되어야 한다. 다른 사이트와 운영 서버 설정은 변경하지 않는다. 로컬 빌드와 내부 링크 검사를 통과한 뒤 실제 화면을 확인한다.
완벽한 프롬프트를 처음부터 만드는 것이 목적은 아닙니다. AI가 기존 상태를 조사한 뒤 예상과 다른 부분을 알려주면 범위를 다시 좁힐 수 있습니다. 중요한 것은 작업 중 목표가 달라졌을 때 원래 요청까지 조용히 확장하지 않는 것입니다.
실제 제작에서는 여덟 단계를 반복했습니다
1. 결과와 중단 조건을 먼저 정합니다
무엇을 만들지뿐 아니라 언제 멈춰야 하는지도 적습니다. 삭제 대상이 모호하거나 기존 글 주소가 바뀌거나 다른 서비스에 영향을 줄 가능성이 있으면 실행보다 확인이 먼저입니다.
2. 수정 전에 현재 상태를 읽습니다
Git 변경 상태, 관련 파일, 기존 페이지와 이미지 위치를 확인합니다. 운영 작업이라면 접속한 대상과 현재 서비스 상태를 읽기 전용으로 먼저 확인합니다.
3. 사람이 구조를 선택합니다
AI가 제시한 대안 가운데 사이트 목적에 맞는 방향을 고릅니다. 이번에는 글을 도구 이름별로 나누기보다 제작·이전, 운영·보안, AI 활용이라는 독자의 작업 흐름으로 나눴습니다.
4. AI가 파일을 수정합니다
선택한 구조에 맞춰 코드와 글을 바꾸고 반복되는 부분은 공통화합니다. 이미 사용자가 수정한 파일이 있다면 덮어쓰지 않고 변경 범위를 분리합니다.
5. 자동 검사를 실행합니다
타입 검사, 정적 빌드, 내부 링크와 이미지 경로를 확인합니다. 실패하면 배포하지 않고 어느 입력이 기준을 어겼는지부터 찾습니다.
6. 화면과 문장을 사람이 읽습니다
데스크톱과 모바일에서 메뉴가 겹치지 않는지, 제목과 카드가 읽기 쉬운지 확인합니다. 글은 같은 말을 반복하지 않는지, 실제 경험보다 크게 주장한 문장이 없는지 읽습니다.
7. 개인정보와 운영 정보를 따로 검사합니다
IP, 이메일, 계정, 키, 토큰, 로컬 절대 경로와 실제 명령 출력을 자동 패턴으로 찾습니다. 이미지에는 터미널, 브라우저 계정, QR 코드나 알아볼 수 있는 개인 정보가 없는지 직접 봅니다.
8. 커밋과 배포를 분리합니다
검증된 변경을 먼저 커밋하고, 배포 요청이 있을 때 새 릴리스로 올립니다. 공개 전 파일과 권한을 검사하고, 공개 후에는 홈페이지와 새 페이지뿐 아니라 사이트맵, 실제 404, 리디렉션과 같은 서버의 다른 사이트도 확인합니다.
네 번의 문제를 겪은 뒤 검증 기준이 생겼습니다
지금의 절차는 처음부터 설계한 완벽한 규칙이 아닙니다. 실제 문제가 하나씩 생길 때마다 다음 작업에서도 반복할 수 있는 검사로 바뀌었습니다.
| 발견한 문제 | 처음에는 놓친 이유 | 이후 추가한 기준 |
|---|---|---|
| 본문의 깨진 내부 링크 | Astro 빌드가 성공했음 | 생성 HTML의 내부 경로를 별도 검사 |
배포 디렉터리 권한 707 |
페이지는 정상적으로 열렸음 | 공개 전 755/644 정규화와 쓰기 권한 검사 |
| 과거 릴리스 24개 누적 | 롤백 파일이 많으면 좋다고 생각함 | 현재 포함 최근 5개, 삭제 전 드라이런 |
| 기술 글의 운영 정보 노출 위험 | 명령 예시만 확인함 | 본문·출력·메타데이터·이미지를 별도 보안 검토 |
이 문제들은 AI가 쓸모없어서 생긴 것이 아닙니다. 요청한 기준 안에서는 작업을 완료했지만 제가 완료 조건을 충분히 정하지 않았던 경우가 많았습니다. 한 번 발견한 문제를 기억에만 의존하지 않고 검사 코드나 프로젝트 규칙으로 남기자 다음 글과 배포에서도 같은 기준을 적용할 수 있었습니다.
최근 작업 결과도 한 가지 성공 신호로 판단하지 않았습니다
이 글을 추가하기 직전인 2026년 9월 11일 사이트 구조 개편 배포에서 Astro 빌드는 34개 페이지를 만들었습니다. 별도 검증과 운영 배포 결과는 다음과 같았습니다. 이 글이 추가되면서 공개 글과 생성 페이지는 각각 한 편씩 늘었습니다.
| 확인 항목 | 결과 |
|---|---|
| 공개 글 | 23편 |
| 공개에서 제외한 초안 | 10편 |
| 검사한 생성 HTML | 40개 |
| 내부 경로 | 38개 |
| 로컬 이미지 | 24개 |
| 새 주제·전체 글 페이지 | 모두 200 |
| 실제 없는 시험 주소 | 404 |
| 통합한 과거 주소 | 301 |
| 새 릴리스 권한 | 디렉터리 755, 파일 644 |
여기에 실제 브라우저 화면도 따로 확인했습니다. 수치가 모두 맞아도 메뉴가 지나치게 빽빽하거나 글의 분류가 독자에게 이해되지 않으면 구조 개편의 목적을 달성한 것이 아니기 때문입니다. 반대로 화면이 깔끔해 보여도 빠진 글이나 잘못된 주소가 있으면 배포할 수 없습니다.
AI를 많이 쓰는 것보다 검토 가능한 상태를 만드는 것이 중요했습니다
AI를 사용하면 혼자서는 시작하기 어려웠던 작업을 실제 결과물로 만들 수 있습니다. 저도 웹개발 경험이 거의 없는 상태에서 사이트를 만든 뒤 콘텐츠 이전, 디자인 수정과 서버 운영까지 범위를 넓혔습니다. 그렇지만 AI에게 맡기는 범위가 커질수록 사람이 해야 할 일이 사라지기보다 바뀌었습니다.
코드를 직접 입력하는 시간은 줄었지만 목적을 설명하고, 영향을 받는 범위를 정하고, 결과가 사실인지 확인하는 일은 더 중요해졌습니다. 자동 검사를 만들면 반복 확인은 줄일 수 있어도 무엇을 검사할지까지 자동으로 결정되지는 않습니다. 특히 공개 콘텐츠와 운영 서버에서는 “실행할 수 있다”보다 “왜 지금 실행해도 되는가”에 답할 수 있어야 했습니다.
제 기준에서 좋은 AI 작업은 사람이 결과를 믿어버리는 상태가 아닙니다. 변경된 파일과 문장을 확인할 수 있고, 실패 조건이 명확하며, 공개 전후 결과를 비교하고, 문제가 생기면 직전 상태로 돌아갈 수 있는 작업입니다.
앞으로 도구가 더 많은 일을 자동으로 처리하더라도 역할 구분은 비슷하게 유지할 생각입니다. AI는 빠르게 읽고 만들고 검사합니다. 저는 목적과 경계를 정하고, 실제 경험과 공개 정보를 확인하고, 되돌리기 어려운 변경을 승인합니다. 개인 블로그처럼 한 사람이 모든 책임을 지는 사이트에서는 이 구분이 작업을 느리게 만드는 절차가 아니라 오래 운영하기 위한 최소한의 안전장치였습니다.