매일 배포하는 습관이 생기면, 일주일 동안 많은 변경 기록이 남게 됩니다.

설명 문구를 수정한 날, 입력 오류를 이해하기 쉽게 만든 날, 스마트폰 표시를 정리한 날, 문제가 발견되어 원래 상태로 되돌린 날. DeploymentNow의 기록이나 GitHub의 커밋을 보면 활동량은 확인할 수 있습니다.

하지만 배포 횟수가 많다고 해서 앱이 좋아졌다고는 할 수 없습니다.

• 같은 버그를 여러 번 수정했다.
• 공개는 성공했지만, 이용자가 변화를 알아차리지 못했다.
• 작은 변경의 의도였지만, 확인하는 데 매번 2시간이 걸렸다.
• 되돌리는 방법을 몰라 문제가 있는 상태를 오래 남겼다.
• AI가 제안한 개선 사항을 목적과의 관계를 보지 않고 공개했다.

이러한 주에도 횟수만 본다면 '7일 연속 배포'로 성공적으로 보입니다.

그래서 저는 주간 검토(weekly review)를 배포 수 집계가 아닌, 다음 네 가지를 확인하는 시간으로 삼습니다.

• 이용자에게 어떤 가치가 전달되었는가
• 그 가치를 무엇으로 확인했는가
• 문제가 생겼을 때 얼마나 쉽게 되돌릴 수 있는가
• 지속하기 위한 운영 부하(operational load)는 적절한가

이 글에서는 비엔지니어(non-engineer)도 매주 30분 정도에 실시할 수 있는 검토 방법을, 일일 기록, 분류, 판단, 다음 주 계획까지 구체적으로 정리합니다.

먼저 비슷한 세 가지를 구분합니다.

빌드 수 (Build count): 코드로부터 공개물을 만들려고 시도한 횟수
배포 수 (Deploy count): 새로운 내용을 환경에 반영하려고 시도한 횟수
전달된 가치: 이용자가 할 수 있게 된 것, 더 이상 헤매지 않게 된 것

DeploymentNow의 공식 문서를 보면, 풀 리퀘스트(Pull Request)의 프리뷰(preview) 역시 실제 배포와 함께 플랜의 빌드 수에 포함됩니다. Free 플랜에서는 하루 100회, Personal 플랜에서는 하루 1,000회가 상한선으로 안내되고 있습니다.

이 숫자는 이용 한도를 확인하는 데 중요하지만, 그 자체를 성과 지표로 삼을 수는 없습니다.

예를 들어, 같은 오류로 10번 빌드에 실패해도, 이용자에게 10가지 가치가 전달된 것은 아닙니다. 반대로, 설명 문구를 단 한 줄만 바꿨더라도, 이용자가 헤매지 않고 조작할 수 있게 되었다면 그것이 가치입니다.

주간 검토에서는 횟수를 활동량으로 기록하는 동시에, 가치는 별도로 다룹니다.

'버튼을 추가했다'가 아니라, 그 결과로 이용자가 무엇을 할 수 있게 되었는지를 적습니다.

변경: 공란 전송 시 메시지 추가
전달된 가치: 입력이 필요하다는 것을 알게 되어 다음 행동을 선택할 수 있다

가치는 큰 신기능에만 국한되지 않습니다.

• 조작할 수 있게 되었다
• 헤맴이 줄었다
• 읽기 쉬워졌다
• 실수를 발견할 수 있게 되었다
• 대기 시간이 짧아졌다
• 고장 났을 때 복구하기 쉬워졌다

내부 정리나 테스트 추가도 이용자에게 바로 보이지 않기 때문에 가치가 없는 것은 아닙니다. '다음 변경 사항을 안전하게 공개할 수 있다', '문제 발견이 빨라진다'와 같은 운영상의 가치가 있습니다.

AI의 완료 보고나 DeploymentNow의 성공 표시만으로는 증거가 부족합니다.

다음과 같은 확인 결과를 남깁니다.

• 공개 URL로 조작해 보았다
• 스마트폰 너비로 표시해 보았다
• 정상 입력과 공란 입력을 시도해 보았다
• 프리뷰 URL에서 변경 전후를 비교했다
• 이용자 1명에게 지정한 조작을 시도해 보게 했다
• 자동 테스트 결과를 확인했다
• 빌드 로그에 오류가 없음을 확인했다

'확인 완료'라고 쓰는 대신, 무엇을 어떻게 확인했는지를 짧게 적습니다.

되돌리기 용이성(reversibility)은 문제가 발생한 날에만 해당되는 것이 아닙니다. 안심하고 작은 변경을 계속할 수 있는 조건입니다.

확인해야 할 것은 다음입니다.

• 마지막 정상 커밋(commit)이 파악되는가
• 1개의 커밋에 여러 목적이 뒤섞여 있지 않은가
• 공개 중인 브랜치(branch)가 파악되는가
• 문제가 있는 기능만 멈출 수 있는가
• 자동 배포를 중단할 판단 기준이 있는가
• 복구 후에 확인해야 할 조작이 결정되어 있는가

'Git이니까 되돌릴 수 있을 거야'로는 불충분합니다. 누가, 어느 커밋으로, 어떤 절차로 되돌리고, 그 후에 무엇을 확인할지까지 말로 합니다.

매일 지속하기 위해서는 변경 자체뿐만 아니라, 확인과 복구에 걸리는 시간도 봅니다.

구현: 20분
로컬 확인: 10분
프리뷰 확인: 8분
...

작은 문구 수정에 2시간이 걸린다면, 조작 환경이나 체크 항목이 너무 복잡할 가능성이 있습니다. 반대로, 확인 시간이 0분이거나 한다면, 안전성을 생략하고 있을 가능성이 있습니다.

주말에 채팅 기록이나 GitHub를 전부 되짚어보면 시간이 많이 걸립니다. 매일, 1배포당 단 한 줄만 남깁니다.

여기서 '전달된 가치가 없는 날'을 숨기지 않습니다.

조사, 실패, 보류 역시 운영의 일부입니다. 가치가 전달되지 못한 이유를 알면 다음 주 개선 자료가 됩니다.

상태는 다음 5가지 정도면 충분합니다.

완료: 공개 URL에서 확인 완료
조건부: 일부 미확인 또는 이용 제한 있음
보류: 본 버전 반영하지 않음
... 

'빌드 성공'을 완료 조건으로 삼지 않는 것이 중요합니다.

1주일간의 배포를 기능 추가만으로 평가하지 않습니다. 다음 5가지로 나누어 평가합니다.

주 안에 신뢰성이나 운영 개선이 단 한 건도 없는 상태가 계속된다면, 공개 속도가 안전성을 따라잡고 있는지 확인합니다.

다음 내용을 목록화합니다.

• 본 버전으로 반영한 커밋(Commit)
• 프리뷰를 만든 풀 리퀘스트(Pull Request)
• DeployNow의 성공/실패/보류 상태
• 공개 URL에서 확인한 조작
• 되돌린 변경 사항
• 미해결 문제

AI에게 목록화를 맡겨도 좋지만, 원래 커밋, 풀 리퀘스트, 배포 이력으로 돌아갈 수 있도록 합니다.

각 변경 사항을 활용 가치, 이해 용이성, 신뢰성, 운영 개선, 정리로 나눕니다.

분류할 수 없는 변경이 있다면, '왜 공개했는지'가 모호했을 가능성이 있습니다. 다음부터는 작업 전에 목적을 작성하도록 합니다.

가치, 증거, 되돌리기 용이성, 운영 부하를 세밀한 점수가 아닌 3단계로 봅니다.

가치: 녹색. 공란일 때의 막힘을 1명의 조작으로 해소 확인
증거: 녹색. 공개 URL에서 정상/공란 확인
되돌리기 용이성: 황색(Yellow). 되돌릴 커밋은 있지만 절차 미확인
... 

평균 점수를 내지 않습니다. 되돌리기 용이성이 빨간색임에도 불구하고, 다른 3개 항목이 녹색이라고 해서 합격이라고 할 수 없기 때문입니다.

각 항목을 다음 4가지로 분류합니다.

지속: 잘된 절차를 표준화함
수정: 문제는 있지만, 범위를 한정하여 개선함
중단: 영향이 크고, 확인될 때까지 사용하지 않음
... 

'수정'과 '중단'을 구분합니다.

예를 들어 기록 서식이 너무 길다면, 운영하면서 짧게 만들 수 있습니다. 반면, 비밀 정보가 프리뷰에 노출될 가능성이 있다면, 해당 기능을 중단하고 확인합니다.

개선안을 10가지 나열해도 실행할 수는 없습니다.

다음 주에 지킬 것을 3가지까지 선택합니다.

## 다음 주 약속
1. 작업 전에 '전달 가치'를 1문장으로 작성하기
2. 본 버전 반영 전 프리뷰 URL에서 스마트폰 폭 확인하기
... 

신규 기능 계획이 아니라, 작업의 질을 바꾸는 약속도 포함합니다.

접근 분석(Access Analytics)이 없어도 가치를 확인할 수 있습니다.

개발 화면이 아닌 공개 URL을 열고, 처음 사용하는 것처럼 조작합니다.

'자유롭게 사용하고 느낌을 주세요'가 아니라, 구체적인 조작을 1가지 부탁합니다.

이 URL을 열고, 메모를 1건 추가해 주세요.
막혔던 부분과, 끝까지 할 수 있었는지만 알려주세요.

같은 질문이 줄었거나, 에러의 의미를 물어보지 않게 되었다는 변화도 가치입니다.

변경 전에 60초 걸렸던 조작이 30초가 되었다면, 개선의 증거가 됩니다. 다만 한 번의 측정만으로 단정하지 않고, 조건을 맞춥니다.

이용자에게 전달되기 전에 프리뷰에서 문제를 발견한 것도 가치입니다. 공개하지 않은 변경 사항이 손실을 막아준 경우가 있을 수 있습니다.

되돌리기 용이성을 'Git을 사용하고 있으니 괜찮다'로 끝내지 않고, 다음 질문으로 확인합니다.

Q1. 현재 본 버전 커밋을 1분 이내에 특정할 수 있는가
Q2. 마지막으로 정상이었던 커밋을 특정할 수 있는가
Q3. 문제의 변경 사항만 설명할 수 있는가
... 

6개 중 답할 수 없는 것을 다음 주 운영 개선 항목에 넣습니다.

DeployNow의 공식 사양으로는, 자동 배포를 정지해도 공개 중인 사이트와 GitHub 연결은 유지됩니다. 또한, GitHub 연결을 해제해도 그전까지의 배포 이력과 공개 중인 사이트는 남아 있습니다.

이 사양은 중단 수단을 생각하는 자료가 되지만, 조작 전에는 영향을 확인하고 누가 재개할지 기록합니다.

긴 보고서가 아니라, 다음 주 판단에 필요한 내용으로 좁힙니다.

매일 배포 주간 검토

대상: 2026-10-26~2026-11-01

활동

...

AI는 형식화된 일일 기록을 바탕으로 다음 단계를 보조할 수 있습니다.

• 커밋과 배포 결과를 날짜순으로 배열하기
• 목적이 유사한 변경 사항들을 그룹화하기
• 증거가 비어있는(공란인) 변경 사항 추출하기
• 롤백(Rollback) 커밋 기록이 없는 기록 찾기
• 작업 시간의 중앙값과 최댓값을 계산하기
• 주간 요약 초안 작성하기
• 다음 주 개선 후보 제안하기

하지만 AI에게 '이번 주는 성공했는지', '어떤 변경 사항에 가치가 있었는지'를 전적으로 위임해서는 안 됩니다.

인간이 결정해야 하는 것은 다음과 같습니다.

• 누구에게 가치인지
• 증거로서 충분한지
• 미확인 상태를 수용할 것인지
• 어떤 문제로 프로덕션(Production) 사용을 중단할 것인지
• 운영 부하(Operational Load)를 어디까지 허용할 것인지
• 다음 주에 무엇을 하지 않을 것인지

AI의 요약이 정확한지 확인하기 위해 원본 커밋, 배포 이력(Deployment History), 공개 URL로 돌아가서 검토합니다.

단순히 누가 몇 번 배포했는지 나열만 하면, 검토보다는 횟수를 우선시하게 됩니다. 횟수는 활동량으로 취급하고, 가치와 증거는 반드시 함께 배치해야 합니다.

실패한 빌드(Build), 되돌린 변경 사항, 중단된 아이디어도 남겨야 합니다. 무엇을 공개하지 않기로 판단했는지 여부가 다음 안전성을 높입니다.

편리해 보이지만, 민감 정보 문제와 문자 간격 문제를 평균값으로 섞어버릴 수는 없습니다. 중요한 경계는 빨강/노랑/초록과 이유를 들어 확인해야 합니다.

검토 후에 확인 항목을 10개 추가하면 다음 주 부하가 늘어납니다. 다음 주 목표는 3가지 이내로 제한하고, 불필요해진 절차도 삭제합니다.

프리뷰(Preview)에서 발견했지만 공개하지 않은 문제점 역시 성과입니다. DeployNow에서는 프리뷰 배포도 이력에 배열되며 빌드 로그를 확인할 수 있습니다. 프로덕션으로 내보내지 않기로 결정한 판단 또한 기록해야 합니다.

처음부터 완벽한 지표를 만들 필요는 없습니다.

기록 항목을 한 번에 늘리면, 기록하는 것 자체가 목적이 됩니다. 매주 하나씩 추가하고, 정말 판단에 사용된 항목만 남겨야 합니다.

이 글 작성 시점(2026년 11월 4일)에 공식 문서에서 다음 사항들을 확인했습니다.

• 지정한 프로덕션 브랜치로 푸시(push)하면 자동 배포가 시작됨
• 그 외의 브랜치로 푸시할 경우, 프로덕션 사이트는 업데이트되지 않음
• 풀 리퀘스트(Pull Request)를 통해 프로덕션과 별도의 URL을 가진 프리뷰를 만들 수 있음
• 프리뷰에 푸시하면 동일한 URL이 업데이트됨
• 프리뷰 배포도 프로덕션과 함께 하루당 빌드 수에 포함되어 계산됨
• 배포 화면에서 진행 상황과 빌드 로그를 확인할 수 있음
• 자동 배포를 중지해도 공개 중인 사이트와 GitHub 연결은 유지됨
• GitHub 연결을 해제하더라도, 그까지의 배포 이력과 공개 중인 사이트는 남아있음

참고:

매일 배포 주간 검토는 횟수를 칭찬하는 자리가 아닙니다.

• 빌드 수, 배포 수, 전달된 가치를 구분해야 합니다.
• 가치, 증거, 되돌리기 용이성(Reversibility), 운영 부하의 4가지 관점에서 봐야 합니다.
• 일일 기록은 1배포당 1줄로 통일해야 합니다.
• 기능뿐만 아니라, 이해하기 쉬움, 신뢰성, 운영 개선, 정리도 평가합니다.
• 30분 안에 사실 수집, 분류, 평가, 판단, 다음 주 설정까지 완료해야 합니다.
• 점수의 평균이 아닌, 빨강/노랑/초록과 이유를 들어 판단해야 합니다.
• 실패, 보류(Hold), 되돌린 변경 사항, 공개하지 않은 판단도 남겨야 합니다.
• 다음 주 목표는 3가지 이내로 제한합니다.
• AI에게 집계는 맡기고, 가치와 중단 판단은 인간이 가져가야 합니다.

매일 배포를 지속하는 목적은 공개 횟수를 늘리는 것이 아닙니다.

사용자에게 작은 가치를 전달하고, 그 결과를 확인하며, 문제가 있으면 짧은 시간 안에 되돌리고, 다음 날도 안심하고 개선을 계속할 수 있는 상태를 만드는 것입니다.

1주일이 끝났을 때, '몇 번 배포했는지'가 아니라, '무엇이 좋아졌고, 무엇으로 확인했으며, 어디로 돌아갈 수 있는지'를 설명할 수 있게 되는 것. 그 상태에 이르면, 매일 배포는 작업량 기록에서 학습과 개선의 시스템으로 바뀝니다.

다음 시간에는 주간 검토에서 발견한 개선 사항을 AI에게 지시하고, 일일 체크 및 복구 절차로 되돌려 다음 주 작업 환경 자체를 업데이트하는 방법을 정리하겠습니다.