Build Log
버튼 하나로 글이 올라갈 때까지 — N-Layer Blog 자동화 완성기
N-Layer Build Log 5부작의 마지막 기록. 아이디어에서 AI 초안, MDX, 검증과 사람의 공개 판단까지 연결한 제작 흐름을 돌아본다. 지금 자동화된 부분과 수동 배포, 다음 단계의 가능성을 구분했다.
1편의 시작에는 작은 아쉬움이 있었다. 결과물은 남는데, 그 과정에서 했던 생각은 사라진다는 것. 무엇을 만들었는지만큼 왜 만들었고 어디에서 방향을 바꿨는지도 남기고 싶었다.
처음에는 블로그를 자동화하려고 했다. 끝에 와서 보니 만들고 있던 것은 **‘생각을 기록으로 바꾸는 시스템’**에 가까웠다.
다섯 번째이자 마지막 글에서는 앞선 설명을 하나씩 되풀이하기보다, 그 작업들이 어떻게 이어지는지 살펴보려 한다. 아이디어가 초안이 되고, 파일과 이미지가 연결되고, 검사와 사람의 판단을 거쳐 공개할 결과물이 준비되는 흐름이다.
제목에는 ‘버튼 하나’와 ‘완성기’를 넣었다. 다만 현재 주제 선정부터 운영 사이트 게시까지 끝내 주는 버튼은 없다. 자동으로 수행하는 변환·검사와 사람이 시작하고 결정하는 단계가 연결된 첫 제작 흐름을 정리한다는 의미다.
처음 생각했던 자동화
처음 기대를 단순하게 그리면 ‘주제 → AI에게 요청 → 글 생성 → 게시’였다. 글만 나오면 나머지는 자연스럽게 따라올 것처럼 보였다.
그 그림에는 빠진 것이 많았다. 제목과 날짜, 사진을 담을 구조가 없고, 무엇이 실제 경험인지 판단할 사람도 분명하지 않다. 오류를 검사할 단계와 아직 공개하지 않을 글을 구분하는 규칙도 없다.
2편의 구조는 문장을 같은 형식으로 넘기는 데 필요했다. 3편의 역할 구분은 그 문장에 누구의 경험과 판단이 들어가는지 정하기 위한 것이었다. 4편의 검사는 잘못된 결과를 공개하기 전에 멈추기 위한 것이었다.
이것들은 글쓰기 옆에 붙인 부가 기능이 아니라, 글 한 편을 공개 가능한 기록으로 바꾸는 연결 부분이었다.
실제로 만들어진 흐름
지금도 시작은 사람이다. 무엇을 남길지, 어떤 질문에 답할지와 실제 경험을 제공한다. 이번 5편도 제목과 핵심 질문, 포함할 내용과 작업 범위를 먼저 정한 요청에서 시작했다.
AI는 앞선 글과 실제 파일, 결과 보고서를 읽고 구성을 잡는다. 본문과 표를 정리하고 도표를 만든 뒤, 기존 MDX 형식으로 옮긴다. 글은 content/blog/에, 시각자료는 public/blog/ 아래 같은 slug의 폴더에 저장한다. 본문에는 그 파일 경로와 설명을 연결한다.
이 연결이 중요했다. 문서만 완성하는 것이 아니라, 글과 이미지가 같은 이름의 작업 단위로 움직이게 된 것이다. 사진을 따로 찾아 다시 붙이는 대신, 글 파일이 어떤 시각자료를 쓰는지 명확하게 가리킨다.
먼저 published: false로 저장하고 로컬 초안 미리보기를 만든다. 글과 화면을 확인하며 lint, 타입 검사와 테스트를 실행한다. 현재 npm test는 빌드를 먼저 하고 테스트를 실행한다. 초안도 검사하지만 공개용 결과물의 페이지와 이미지에는 포함하지 않는다.
그다음 기존 페이지와 앞선 글을 확인하고, 사람이 내용과 공개 범위를 판단한다. 공개 준비를 승인한 글은 published: true로 바꾸고 공개용 빌드와 검증을 다시 마친다. 그 결과를 커밋해 검토 가능한 변경으로 남긴다.
여기까지가 이번 시리즈에서 반복해 사용한 게시 준비 흐름이다. 운영 사이트 배포는 별도의 승인과 실행이 필요한 단계다. 현재 GitHub remote도 연결되어 있지 않아 자동 push나 push에 따른 자동 배포 흐름은 없다. 이번 작업 역시 push와 production 재배포를 하지 않는다.
이 도표는 한 번의 실행으로 모두 진행되는 프로그램을 뜻하지 않는다. 같은 파일 규칙과 검사 기준을 사용해 사람이 각 작업을 이어 가는 현재 흐름이다. 초안 생성, 검토, 공개 준비 사이에서는 수정할 곳이 생기면 앞 단계로 돌아간다.
자동화된 것과 아직 사람이 하는 것
‘자동화됐다’는 말도 단계마다 뜻이 달랐다. AI가 형식을 적용하는 일, 프로그램이 같은 규칙으로 검사하는 일, 별도 명령을 사람이 실행하는 일을 모두 한 종류로 묶으면 현재 상태를 과장하게 된다.
| 단계 | 현재 상태 |
|---|---|
| 주제·경험·방향 | 사람이 제공하고 결정 |
| 초안·구성 | 요청한 범위에서 AI 활용 |
| 글 구조화·MDX | AI가 기존 파일 규칙 적용, 빌드가 검증·변환 |
| 시각자료 | AI가 SVG·배치 준비, 실제 화면은 캡처 후 검토 |
| 저장·이미지 연결 | 로컬 파일로 관리, 글별 경로 규칙 사용 |
| Draft 보호 | 공개용 빌드가 글·이미지·목록·피드 제외 |
| 코드·형식·동작 검사 | 명령을 실행하면 자동 수행, 실행과 결과 대응은 사람이 관리 |
| 화면·사실·최종 판단 | AI 확인 보조와 사람 검토 |
| 공개용 HTML 생성 | 빌드가 자동 변환 |
| Git commit | 검증 후 요청 범위에서 실행 |
| push / production deploy | 자동 연결 없음, 별도 승인 범위에서 수동 실행 |
얼마나 자동화됐는가
시간을 얼마나 절약했는지는 아직 측정하지 않았다. 자동화율을 숫자로 말할 근거도 없다. 대신 파일과 결과 보고서에서 확인할 수 있는 구조는 있다.
이번 시리즈는 실제 글 5편이다. 기능 확인용 초안은 이 수에 포함하지 않는다. 다섯 글의 본문에는 그림 21개와 표 6개가 들어 있다. 그림은 실제 화면 이미지 4개, 흐름·역할 도표 15개, 그래프 2개로 나뉜다.
그래프 중 1편의 막대는 측정한 작업량이 아니라 설명용 상대값이다. 이번 글의 그래프는 각 편 완료 시점의 전체 테스트 수라는 실제 기록을 사용한다. 둘을 같은 성과 데이터로 볼 수는 없다.
앞선 결과 보고서에는 1편 12개, 2편 13개, 3편 15개, 4편 17개의 테스트가 통과했다고 적혀 있다. 이번 5편에서는 전체 시리즈 출력·링크와 5편 초안 보호를 확인하는 테스트를 추가해 19개 전체 테스트를 검증한다.
검사가 늘어난 이유는 글이 추가되면서 확인할 주소, 시각자료와 공개 경계도 늘었기 때문이다. 테스트 수에는 기존 홈페이지와 프로젝트 페이지 검사도 포함된다. 개수의 증가보다 어떤 실패를 확인하는지가 더 중요하다.
명령 기준으로는 lint, typecheck, tests, build 네 가지를 사용한다. 이들은 확인 범위가 서로 다르고, 브라우저의 화면 확인과 사람의 사실·내용 검토가 따로 남는다. 네 명령이 있다는 이유로 전체 판단의 네 부분이 자동화됐다고 계산하지는 않는다.
자동화하면서 가장 크게 바뀐 생각
처음에는 AI에게 얼마나 많은 일을 맡길 수 있는지가 궁금했다. 지금은 맡길 일의 경계를 얼마나 명확하게 정할 수 있는지가 더 중요해졌다.
구조가 먼저 있어야 같은 규칙을 반복할 수 있다. 반복되는 파일 형식과 내용 판단을 분리해야, 사진 경로를 다시 적는 일과 내 경험을 공개하는 일을 다르게 다룰 수 있다. 초안을 빨리 만드는 것만큼 틀린 결과를 발견하고 멈추는 일도 필요하다.
이 흐름에서 사람은 사라지지 않았다. 시작할 때는 주제와 경험을 제공하고, 끝에서는 의도와 맥락, 공개 여부를 판단한다. 그 사이의 반복 작업이 정리될수록 그 판단에 집중할 여지가 생긴다.
아직 자동화하지 않은 것
현재 주제를 자동으로 모으는 기능은 없다. 외부 자료의 사실관계를 모두 자동 검증하는 기능도 없다. AI가 스스로 초안을 만들고 사람에게 승인을 요청한 뒤 게시하는 상시 작업도 아직 연결하지 않았다.
GitHub push와 production deploy는 자동화하지 않았다. published: true만으로 배포가 시작되지도 않는다. 검사 실패가 별도로 실행하는 배포를 강제로 막거나, 실패한 로컬 빌드를 자동 복원하는 기능도 현재 없다. 승인 없는 공개는 앞으로 붙일 편의 기능으로 보지 않고 계속 남겨 둘 경계로 본다.
여기서 말하는 완성은 ‘모든 것이 자동’이라는 뜻이 아니다. 어디까지 자동화하고 어디에 사람을 남길지가 정리된 첫 번째 완성형이라는 의미다.
완료된 것은 글을 같은 규칙으로 담고, 검사하고, 공개할 결과물을 준비하는 기반과 작업 절차다. 무인 운영과 한 버튼 게시까지 완성했다고 말할 단계는 아니다.
다음 자동화는 ‘게시’가 아니라 ‘시작’일 수도 있다
기반이 생겼다고 바로 게시 버튼부터 붙여야 하는 것은 아니다. 다음에는 시작을 돕는 쪽이 더 유용할 수도 있다.
기록할 주제 후보를 모으고, 이전 글과 겹치는지 살피고, 자료를 정리해 draft를 준비하는 흐름을 생각할 수 있다. 사람은 후보를 선택하고 자료와 초안을 검토한다. 검토할 때 필요한 근거까지 함께 전달된다면 글을 시작할 때의 반복도 줄어들 것이다.
이것은 Phase 2의 가능성이다. 이번 작업에서는 수집기나 승인 시스템, 게시 자동화를 새로 구현하지 않는다. 실제로 연결할 때도 자료의 출처, 초안 보호와 공개 결정의 경계를 다시 확인해야 한다.
다섯 편의 기록을 마치며
처음에는 글을 자동으로 올리는 모습을 떠올렸다. 하지만 다섯 편을 준비하며 더 중요하게 남은 것은, 작업 중에 한 생각을 잊히지 않는 기록으로 바꾸는 구조였다.
무엇을 남길지 정하고, AI와 정리하고, 파일로 담고, 검사하고, 사람이 다시 읽는 과정이 이어졌다. 이제 기록은 흩어진 대화에서만 찾는 것이 아니라, 같은 형식의 글과 시각자료, 검증 결과와 변경 이력으로 남는다.
이 글로 ‘블로그 자동화 만들기’ 5부작을 마친다.
이전 글: 4편 — 자동화에서 가장 중요한 건 ‘만드는 것’이 아니라 ‘잘못 올리지 않는 것’이었다
전체 시리즈
- 블로그를 직접 만들기로 했다 — 자동화의 시작
- 글 한 편은 어떻게 웹페이지가 되는가 — 블로그의 구조를 만들다
- AI에게 글쓰기를 맡기면 블로그가 자동화될까?
- 자동화에서 가장 중요한 건 ‘만드는 것’이 아니라 ‘잘못 올리지 않는 것’이었다
- 버튼 하나로 글이 올라갈 때까지 — N-Layer Blog 자동화 완성기
자동화의 끝은 사람이 사라지는 곳보다, 사람이 한 생각이 사라지지 않게 되는 곳에 더 가까웠다.