매일 배포 기록을 숫자로 바꾸기: 작업 시간, 확인 누락, 재작업으로 복잡한 체크리스트를 간소화하는 방법

매일 배포(Deployment) 시의 운영 대시보드를 만들면, 작업 시작부터 공개 후 확인까지의 순서가 갖춰집니다.

하지만 실제로 사용하기 시작하면 다른 문제들이 눈에 띕니다.

• 체크 항목이 너무 많아 읽는 것만으로도 시간이 오래 걸린다.
• 매번 같은 장소에서 AI와의 대화를 반복해야 한다.
• 미리보기 확인은 했지만, 스마트폰 화면 표시만 빠뜨리는 경우가 있다.
• 배포 성공 후, 실제 운영 URL을 열기까지 중단이 발생한다.
• 45분 만에 끝낼 예정이었는데, 매번 90분을 초과한다.
• 일일 기록은 남지만, 다음 주에는 무엇을 개선해야 할지 알 수 없다.

이런 상태에서 '더욱 꼼꼼하게 확인하자'고 하면, 운영 대시보드는 더욱 무거워집니다.

필요한 것은 모든 작업을 세밀하게 감시하는 것이 아닙니다. 이미 남겨둔 일일 기록을 바탕으로 다음 세 가지 요소만 눈에 보이게 하는 것입니다.

• 어느 단계에서 시간이 오래 걸렸는지
• 어떤 확인 절차가 누락되었는지
• 어디서 재작업(Rework)이 발생했는지

이 3가지만 알면, 불필요한 체크를 줄이고 자주 막히는 부분만 개선할 수 있습니다.

본 글에서는 비엔지니어(non-engineer)도 스프레드시트 소프트웨어나 전용 대시보드를 만들지 않고, 마크다운(Markdown) 기록을 활용하여 매주 30분 만에 운영 대시보드를 가볍게 만드는 방법을 설명합니다.

먼저, 무엇을 위해 숫자를 볼지 결정해야 합니다.

작업 시간이 긴 사람을 비난하기 위해서가 아닙니다. 체크 누락을 실패점으로 계산하기 위해서도 아닙니다.

보는 목적은 다음 질문에 답하는 것입니다.

어디에서 정보를 찾고 있는지
어디서 판단 자료가 부족한지
어떤 확인 절차가 매번 필요한지
...

예를 들어, GitHub의 차이점(diff) 확인에 20분이 걸린 날이 계속되었다고 가정해 봅시다.

원인은 '확인이 느린 사람' 때문이 아니라, AI가 변경한 범위가 너무 넓거나, 풀 리퀘스트(Pull Request) 자체가 크거나, 목적 외 정리가 섞여 있는 등 작업 설계 자체의 문제일 수 있습니다.

숫자는 사람을 가리키는 것이 아니라, 작업의 병목 현상(詰まり)을 찾는 단서로 사용합니다.

자세한 작업 로그를 모두 저장하면, 기록하는 행위 자체가 부담이 됩니다.

하루에 한 건씩 다음 7가지 항목으로 정리합니다.

## 2026-11-08
- 목적: 공란일 때 안내를 명확하게 하는 것
- 총 시간: 52분
...

'가장 긴 단계'만 하나 적는 것이 핵심입니다.

모든 과정을 초 단위로 기록할 필요는 없습니다. 우선, 시간이 가장 많이 소요된 장소가 어디인지 아는 것으로 충분합니다.

시간을 비교하기 위해서는 매일 동일한 구분을 사용합니다.

1. 시작 준비
2. AI 요청 및 수정
3. GitHub 차이점 확인
...

오늘의 목적, 변경 범위, 중단 조건, 마지막 정상 지점을 결정하는 시간입니다.

AI에게 지시하고 결과를 받아, 범위를 벗어난 변경이나 부족한 부분을 수정하는 시간입니다.

변경 파일, 삭제, 설정 변경, 테스트 결과를 확인하는 시간입니다.

정상 작동, 실패하기 쉬운 작업, 스마트폰 표시 등을 확인하는 시간입니다.

사용자의 승인 후, 운영 환경에 반영하고 배포 완료를 확인하는 시간입니다.

사용자와 동일한 진입점에서 운영을 진행하며, 결과와 미확인 사항을 남기는 시간입니다.

단계명은 자신의 운영 대시보드에 맞춰 바꿔도 괜찮습니다. 다만, 주중에 이름이나 경계를 자주 바꾸면 비교가 불가능해집니다. 1주일 동안은 동일한 구분을 사용해야 합니다.

시작과 종료 시간을 매번 측정하는 것이 부담스럽다면, 처음에는 3단계로 기록합니다.

시작 준비: 짧음
AI 요청: 김
차이점 확인: 보통
...

이 기록을 5일치 나열하면, AI 요청만 '김' 상태가 지속되고 있다는 것을 알 수 있습니다.

숫자를 세밀하게 하는 것은 개선할 부분이 발견되었기 때문입니다.

체크 항목이 공란이라고 해서 모두 확인 누락은 아닙니다.

실시: 확인함
미실시: 필요했지만 확인하지 않음
대상 외: 이번 변경에는 불필요했음
...

예를 들어, 문장만 수정한 날에 데이터베이스 쓰기 확인을 하지 않았다면, 그것은 대상 외일 수 있습니다.

반면에, 스마트폰용 버튼 배치를 바꿨는데 스마트폰 너비를 확인하지 않았다면 미실시입니다.

이 구분이 없으면, 운영 대시보드는 모든 변경 사항마다 모든 항목을 확인해야 하는 무거운 절차를 따르게 됩니다.

일일 기록은 다음과 같이 작성합니다.

## 확인 결과
- 정상 입력: 실시
- 공란: 실시
...

'미실시'가 계속되는 항목은 주의력 문제가 아니라 배치를 재검토해야 합니다.

• 확인 항목이 사용하는 화면에서 벗어나 있지는 않은지
• 이름이 모호하지 않은지
• 언제 확인할지 결정되어 있는지
• 합격 조건이 명확한지
• 대상 외로 처리할 수 있는 조건이 없는지

재작업이란, 같은 작업을 단순히 두 번 수행했다는 것을 의미하지 않습니다.

이미 진행했던 단계에서 이전 단계로 되돌아가는 것을 말합니다.

미리보기(Preview)에서 표시 깨짐 발견
→ AI 요청으로 복귀
차이점 확인(Diff Check)에서 범위 외 변경 발견
...

기록해야 할 내용은 다음 세 가지입니다.

회수: 몇 번 복귀했는지
복귀 지점: 어느 단계로 돌아갔는지
사유: 무엇이 부족했는지

예시:

• 재작업: 2회
• 차이점 확인 → AI 요청: 목적 외 파일 정리 내용이 섞임
• 미리보기 → AI 요청: 공란일 때 표시가 스마트폰에서 겹침

재작업이 많다는 것 자체가 나쁘다고 단정할 수는 없습니다.
미리보기에서 문제를 발견하고 본 반영 전에 복귀했다면, 안전 기능이 작동한 결과입니다. 주목해야 할 것은 같은 이유가 반복되고 있는지 여부입니다.

주말 동안 5일 치를 다음 표에 정리합니다.

가장 길었던 회수가 많은 단계
미실시 항목이 2회 이상 있었던 확인 사항
같은 복귀 지점으로 돌아간 횟수
...

위 예시의 경우, 수요일만을 '실패'로 보기보다는 AI 요청과 차이점 확인에 개선할 여지가 있다고 생각합니다.

평균 대신, 5일 치를 짧은 순으로 나열한 중간값(중앙값)을 봅니다.

38분, 43분, 46분, 52분, 91분
중앙값: 46분

평균은 91분이 걸린 하루에 의해 끌어당겨집니다. 평소 작업량이 어느 정도인지 보고 싶다면, 중앙값이 더 이해하기 쉽습니다.

필요했던 확인 사항 중 미실시된 항목의 수를 봅니다.

필수 확인: 25건
미실시: 3건
확인 누락률: 3 ÷ 25 = 12% 

대상 외는 분모에 포함하지 않습니다. 보류(Pending) 건은 기한 내에 확인했는지 여부를 별도로 봅니다.

작업 일수에 비해, 얼마나 자주 전 단계로 돌아갔는지 봅니다.

작업일: 5일
재작업: 4회
1일당: 0.8회

횟수만으로 좋고 나쁨을 판단하지 말고, 이유를 조합합니다.
같은 이유로 3번 돌아갔다면, 작업판(Operation Board)이나 AI 지시를 변경할 후보가 됩니다.

가시화(Visualization)의 목적은 그래프를 만드는 것이 아닙니다. 다음 주에 하나를 바꾸는 것입니다.

고려 가능한 원인:

• 목표가 한 문장으로 작성되지 않음
• 변경 범위가 넓음
• 완료 조건이 모호함
• AI가 매번 프로젝트 구성을 찾는 과정이 필요함

개선 예시:

START_HERE에 대상 파일을 기재한다.
변경은 하나의 가치로 한정한다.
허용 파일과 변경 금지 영역을 미리 전달한다.

고려 가능한 원인:

• AI에게 '틈틈이 정리하지 않는다'는 점을 알려주지 않음
• Pull Request(PR)가 너무 큼
• 설정 변경과 표시 변경이 혼재되어 있음

개선 예시:

목적 외 정리는 별도의 제안으로 한다.
변경 파일 수의 상한선을 정한다.
표시와 설정을 다른 작업으로 분리한다.

고려 가능한 원인:

• DAILY_CHECK.md가 다른 탭에 있음 - 확인하는 화면 폭이 결정되지 않음
• 미리보기 확인 완료 조건에 포함되어 있지 않음

개선 예시:

미리보기 URL 바로 다음에 체크표를 연다.
390px 폭으로 3개의 화면을 본다.
확인하지 않았다면 본 반영으로 진행하지 않는다.

고려 가능한 원인:

• 본 반영(Production) URL을 매번 찾음
• 확인해야 할 3가지 작업이 결정되지 않음
• 공개 직후 다른 작업을 시작함

개선 예시:

본 반영 URL을 START_HERE에 배치한다.
톱/변경 부분/주요 작업의 3가지로 한정한다.
공개 후 확인이 끝날 때까지 새로운 작업을 시작하지 않는다.

매주 항목을 추가하면, 작업판은 반드시 복잡해집니다.

삭제 후보는 다음 순서로 찾아봅니다.

START_HERE.md와 DAILY_CHECK.md에 같은 설명이 있다면, 진입점에는 링크만 남깁니다.

닫힌 Pull Request, 삭제된 브랜치, 사용하지 않는 URL을 제외합니다.
환경 변수를 변경한 날에만 필요한 확인 사항을 매일 공통 항목에서 분리합니다.
매일 작성하지만 4주 동안 한 번도 판단에 쓰지 않은 항목은 목적을 확인합니다.

다만, 기밀 정보, 데이터 손실, 본 반영 중단, Human Approval(인간 승인), 복구와 관련된 경계는 사용하지 않았다고 해서 삭제하지 않습니다.

체크를 가볍게 하는 가장 확실한 방법은 매번 수행하는 것과 변경 내용에 따라 수행하는 것을 분리하는 것입니다.

[ ] 오늘 전달할 가치가 한 문장이다
[ ] 변경 범위와 접촉하지 않는 부분이 있다
[ ] 실제 차이점을 확인했다
... 

[ ] 스마트폰 폭
[ ] 긴 문자열
[ ] 글자 겹침
... 

[ ] 정상적인 저장
[ ] 공란/중복/상한선
[ ] 기존 데이터에 미치는 영향
... 

[ ] 변경 전 값 기록
[ ] 프로덕션과 프리뷰 구분
[ ] 값을 화면/로그/AI에 붙이지 않음
...

매일의 공통 체크가 짧아지고, 필요한 안전 확인은 변경별 카드로 남습니다.

5일간의 일일 기록을 AI에 전달하여 집계를 도움받을 수 있습니다.

다음은 이번 주 5일간의 매일 배포 기록입니다.
1. 각 날짜별 총 시간, 가장 긴 단계, 미실시 건수, 재작업 횟수, 결과를 표로 만들어 주세요.
2. 동일한 단계가 가장 길어진 횟수를 세어 주세요.
...

AI는 표 작성, 횟수 집계, 유사 이유 분류에 능숙합니다.

한편, 어떤 리스크를 남길지, 어떤 확인 절차를 줄일지, 프로덕션 반영을 멈출지는 사람이 결정합니다.

집계 결과에 "이 확인은 불필요함"이라고 적혀 있어도, 자동으로 절차에서 삭제하지 않습니다.

숫자를 보면 개선하고 싶은 곳이 많이 발견됩니다.
하지만, 동시에 5가지를 변경하면 다음 주에 어떤 개선이 효과를 보았는지 알 수 없습니다.

다음 순서대로 1가지를 선택합니다.

1. 기밀 정보/데이터 손실/공개 중단으로 이어지는 문제
2. 프로덕션에서 사용자가 조작할 수 없게 되는 문제
3. 같은 이유로 2회 이상 재작업한 장소
...

개선 기록:

## 다음 주 변경 사항
- 대상: AI 요청
- 근거: 5일 중 3일에서 가장 길었음, 범위 외 변경으로 인한 재작업 2회
...

"변경하지 않을 것"도 적으면, 효율화를 위해 안전 경계까지 벗어나는 것을 막을 수 있습니다.

다음 주에도 같은 3가지를 확인합니다.

중앙 작업 시간
확인 누락률
재작업률 및 이유

예시:

평균 점수를 내지 않고, 3가지를 개별적으로 판단합니다.

매일 배포 개선 과정에서, 다음과 같은 항목까지 모으기 시작하면 기록이 지속되지 않습니다.

• AI와의 메시지 수
• 클릭 수
• 열린 탭 수
• 변경 행 수
• 모든 대기 시간
• 모든 테스트 건수
• 세밀한 감정 점수

이들 중 필요한 조사도 있지만, 처음부터 상시로 기록하지는 않습니다.
새로운 숫자를 추가하는 조건은 다음과 같습니다.

판단에 사용할 질문이 있다
1분 이내에 기록할 수 있다
다음 주 행동을 바꿀 수 있다
...

질문이 없는 숫자는 보기 좋은 대시보드를 만드는 데 그치기 쉽습니다.

작업판을 바꾸지 않고, 시간, 미실시, 재작업, 결과를 기록합니다.
도중에 알게 되더라도, 중대한 안전 문제가 아니라면 먼저 5일간의 추세를 봅니다.

동일한 병목 현상이 반복된 장소에서, 다음 주에 바꿀 것을 1가지만 선택합니다. 체크 위치, AI 지시의 시작 부분, 조건부 카드 분리 등, 단 하나만 반영합니다.

시간, 확인 누락, 재작업이 어떻게 변했는지 확인합니다. 개선하지 못하면, 사람의 노력보다는 원인이나 위치를 검토합니다.

# 매일 배포 작업판 리뷰
## 이번 주 결과
- 작업 일수: 5일
...

이렇게 하면, 주간 검토가 느낌이 아니라 다음 작업판을 변경할 판단 자료가 됩니다.

확인을 건너뛰면 시간은 짧아집니다. 확인 누락과 재작업을 함께 봅니다.
기록에 시간이 걸려, 매일 배포가 부담스러워집니다. 가장 긴 단계부터 시작합니다.

변경과 관련 없는 확인까지 미실시로 처리하면, 체크를 줄일 수 없습니다. 실행, 미실시, 대상 외, 보류로 나눕니다.
프리뷰에서 문제를 발견하고 되돌아갈 수 있었던 것은 안전한 운영의 결과입니다. 같은 원인이 반복되고 있는지 봅니다.

집계와 제안은 AI에게 맡길 수 있지만, 안전 경계를 줄이는 판단은 사람이 합니다. 어떤 변경이 효과가 있었는지 알 수 없게 됩니다. 1주일에 단 하나만 반영합니다.

매일 배포 작업판은 항목을 늘릴수록 안전해지는 것은 아닙니다. 실제 일일 기록에서, 시간이 걸리는 곳, 확인이 누락되는 곳, 이전 단계로 돌아가는 곳을 찾아 필요한 부분만 변경함으로써 가볍게 만들 수 있습니다.

이번 요점은 다음과 같습니다.

• 일일 기록은 목적, 시간, 가장 긴 단계, 확인, 누락, 재작업, 결과로 통일한다
• 작업을 6단계로 나누고, 가장 시간이 걸렸던 곳만 기록한다
• 공란을 미실시, 대상 외, 보류로 나눈다
• 재작업은 횟수, 복귀 지점, 이유를 기록한다
• 주간에는 중앙 시간, 확인 누락률, 재작업률을 본다
• 작업판을 공통 체크와 조건부 체크로 분리한다
• AI에게 집계를 맡기고, 삭제와 중단 판단은 사람이 한다
• 개선은 1주일에 단 하나만 반영하고, 같은 숫자로 비교한다

첫 번째 단계는 오늘 작업이 끝났을 때 '총 시간', '가장 시간이 오래 걸린 단계', '재작업 횟수' 세 가지만 기록하는 것입니다.

다음번에는 대시보드(조작판) 개선을 계속해도 줄어들지 않는 작업을 발견했을 때, 그 작업을 자동화할지, 사람이 지속할지, 아니면 중단할지를 판단하는 기준을 정리합니다.