주간 리뷰를 다음 주 작업 환경에 반영하는 방법 – AI 지침, 일일 체크리스트, 복구 절차 업데이트

매일 배포(deploy) 과정을 주간 단위로 되돌아보면, '다음 주에는 조심해야겠다'는 개선점을 발견할 수 있습니다.

• AI에 요청한 범위보다 큰 변경 사항이 발생했다.
• 프리뷰를 봤는데 스마트폰 표시 확인을 잊었다.
• 빌드 성공을 보고 안심하여 공개 URL을 건드리지 않았다.
• 되돌릴 커밋은 알았지만, 되돌린 후의 확인 항목이 없었다.
• 매일 같은 정보를 다시 찾아야 해서 작업 시작까지 시간이 오래 걸렸다.

하지만 이러한 내용들을 주간 메모에 적는 것만으로는 다음 주에도 똑같은 실수가 발생합니다. 사람은 바쁜 날 기억에 의존할 수 없습니다. AI 역시 이전 대화에서 결정한 주의사항을 다른 날의 새로운 요청에서 반드시 계승한다고 보장할 수는 없습니다.

필요한 것은 반성(反省)을 늘리는 것이 아니라, 다음 작업 시 반드시 눈에 띄는 곳에 개선점을 심어 놓는 것입니다.

저는 주간 리뷰를 통해 발견한 개선 사항들을 다음 네 가지 장소에 반영합니다.

• AI 지침서 (AIへの指示書)
• 매일 시작 전/공개 전 체크리스트
• 문제가 발생했을 때의 복구 카드
• 다음 주 작업을 시작할 수 있는 조건

이 글에서는 비(非)엔지니어가 30~45분 만에 일주일간 발견한 내용을 다음 주 작업 환경에 반영하는 방법을 설명합니다. 새로운 관리 도구를 늘리는 이야기가 아닙니다. 평소 사용하는 문서, 체크리스트, 폴더를 조금씩 업데이트하여 AI, GitHub, DeployNow 등을 사용할 매일의 흐름 자체를 개선하는 이야기입니다.

주간 리뷰가 끝날 무렵에 다음과 같은 문장을 남겼다고 가정해 봅시다.

스마트폰에서 버튼이 누르기 어려웠다.
다음번에는 스마트폰 표시도 확인해야겠다.

이는 발견(発見)으로서는 맞지만, 실행 메커니즘이 없습니다.

• 언제 확인할 것인가?
• 어떤 화면 폭으로 볼 것인가?
• 누가 확인할 것인가?
• 무엇을 기준으로 합격으로 할 것인가?
• 불합격이라면 공개를 멈출 것인가?

이렇게 구체화되어야 비로소 다음 주 행동이 바뀝니다.

개선 전:

다음번에는 스마트폰도 확인한다.

개선 후:

풀 리퀘스트(Pull Request)를 병합하기 전에, 프리뷰 URL을 390px 폭으로 열어본다.
탑, 입력, 완료의 세 화면에서 글자 중첩과 버튼 누르기 용이성을 확인한다.
하나라도 조작할 수 없으면 병합하지 않는다.

개선된 문장에는 타이밍, 대상, 합격 조건, 정지 조건이 있습니다. 이 형태라면 자신에게도 AI에게도 전달할 수 있습니다.

모든 개선 사항을 긴 절차서에 추가하면 읽히지 않습니다. 개선의 성질에 맞게 위치를 분리합니다.

'공개 URL 확인을 잊었다'는 것은 일일 체크리스트에 반영합니다.

'되돌린 후에 어디를 확인할지 몰랐다'는 복구 카드에 반영합니다.

'미해결의 중대한 문제가 있는데도 새로운 기능으로 넘어갔다'는 다음 주 시작 조건에 반영합니다.

놓을 장소가 정해지면, 주간 리뷰가 감상회가 아니라 환경 업데이트 작업이 됩니다.

지난주 기록에서 다음 조건에 해당하는 것을 선택합니다.

• 같은 실수가 2회 이상 발생했다
• 공개 중인 사용자에게 영향을 줄 가능성이 있었다
• 복구하는 데 30분 이상 걸렸다
• 매일 5분 이상, 같은 정보를 찾고 있었다
• AI의 출력을 어디까지 신뢰해야 할지 망설였다

모든 후보를 고치려고 하지 않습니다. 일주일 동안은 3건 이내로 합니다.

우선순위는 다음 순서가 충분합니다.

1. 비밀 정보, 데이터 손실, 공개 중단으로 이어지는 것
2. 사용자가 조작할 수 없게 되는 것
3. 되돌릴 수 없거나 확인 방법이 없는 것
... 

가벼운 문구 수정보다, 공개 중단이나 복구가 불가능한 문제를 먼저 다룹니다.

각 후보를 다음 5개 항목으로 다시 작성합니다.

계기: 무엇이 일어났는가?
적용 시점: 언제 사용할 것인가?
행동: 무엇을 할 것인가?
... 

예시:

계기: AI가 요청 범위를 벗어난 설정 파일을 변경했다
적용 시점: AI에게 수정을 요청할 때
행동: 변경 가능한 파일과 건드리지 않을 곳을 먼저 나열한다
... 

여기서 중요한 것은 '주의하다', '꼼꼼히 보다'와 같은 감정의 표현을 관찰 가능한 행동으로 바꾼다는 것입니다.

1건의 개선 사항을 반드시 4군데 모두에 쓸 필요는 없습니다. 가장 효과가 큰 1~2곳에 넣습니다.

예를 들어, 스마트폰 확인 누락이라면 AI 지침을 길게 쓰는 것보다 공개 전 체크리스트에 한 줄 추가하는 것이 더 직접적입니다.

반대로, AI가 변경 범위를 넓히는 문제라면, 공개 전에 발견하는 것만으로는 늦기 때문에 AI 지침서와 차이점 확인(diff) 양쪽 모두에 넣습니다.

문서를 업데이트한 것만으로 완료하지 않습니다. 실제 공개를 진행하지 않고 짧은 모의 실행을 합니다.

• 새로운 템플릿으로 AI 지침을 한 번 작성한다.
• 일일 체크리스트를 위에서부터 읽으며 3분 이내에 완료할 수 있는지 측정한다.
• 복구 카드를 보고 마지막 정상 커밋(commit)을 특정한다.
• 시작 조건의 각 항목에 대해 현재 '예'라고 답할 수 있는지 확인한다.

시뮬레이션 실행 중 막혔던 문장은 그 자리에서 짧게 수정합니다.

최소한 다음 사항은 기록합니다.

## 운영 업데이트 2026-11-05
- 변경 이유: 스마트폰 확인이 2회 누락됨
- 변경 항목: 공개 전 체크 4번
...

업데이트 이유를 남기면 나중에 '왜 이 절차가 존재하는지' 알 수 있습니다. 이유를 알 수 없는 규칙은 삭제해도 되는지 판단할 수 없어, 절차서가 무거워집니다.

AI에 대한 요청은 그날의 대화로만 끝내지 않고, 짧은 공통 템플릿을 가지는 것이 안정적입니다.

## 이번 목표
사용자가 빈칸으로 전송했을 때, 다음에 무엇을 해야 할지 알 수 있도록 한다.
## 변경 가능한 범위
...

주간 리뷰로 개선하는 것은 템플릿 전체가 아니라, 실패와 관련된 한 줄입니다.

예를 들어 AI가 대규모 정리를 시작했다면, '임의 리팩토링은 수행하지 않는다'를 수정하지 않을 범위에 추가합니다. 확인 결과가 모호했던 경우라면, '실행한 확인과 미실행의 확인을 나누어 표시한다'를 완료 조건에 추가합니다.

다만, 지침을 계속 늘리면 중요한 경계가 묻히게 됩니다. 추가할 때는 다음 중 하나도 수행합니다.

• 같은 의미의 오래된 줄을 대체한다.
• 특정 작업만의 주의사항은 별도의 템플릿으로 옮긴다.
• 3주 동안 사용하지 않았고, 지킬 이유도 사라진 항목을 검토한다.

기준으로, 매번 읽는 공통 지침은 한 화면 정도를 유지합니다.

매일의 체크를 하나의 긴 표로 만들면, 지금 어디를 봐야 할지 알 수 없습니다. '시작 전', '본 반영 전', '공개 후' 세 가지로 나눕니다.

[ ] 오늘 전달할 가치를 한 문장으로 작성했다
[ ] 변경 가능한 범위를 결정했다
[ ] 건드리지 않을 장소를 결정했다
...

[ ] 변경 파일 목록을 확인했다
[ ] 자동 테스트의 성공과 미실행을 구분했다
[ ] 프리뷰 URL로 대상 작업을 확인했다
...

[ ] 배포 기록이 성공했는지 확인했다
[ ] 공개 URL을 새 탭에서 열었다
[ ] 정상 작동을 1회 수행했다
...

DeployNow는 GitHub에 연결된 대상 브랜치로 푸시(push)를 받으면 빌드와 배포를 시작하고, 성공하면 공개 중인 사이트에 반영합니다. 따라서 '푸시가 가능했는지'와 '공개 URL에서 이용할 수 있었는지'는 별도로 확인해야 합니다.

체크 항목은 단순히 늘리는 것이 아니라, 매주 시간을 측정합니다. 일일 확인만으로 20분이 걸린다면, 중복을 통합하거나 변경 내용에 따라 사용하는 조건부 체크로 나눕니다.

문제가 발생했을 때, 긴 주간 보고서를 다시 읽어볼 여유가 없습니다. 복구(Recovery)만 한 페이지로 정리합니다.

# 복구 카드
## 1. 먼저 중단하기
- 새로운 변경과 머지(merge)를 중단한다...

DeployNow에서는 자동 배포를 중단해도 공개 중인 사이트와 GitHub 리포지토리의 연결은 유지됩니다. 중단된 동안에는 푸시에 의한 새로운 배포가 시작되지 않습니다. 재개하면 다음 푸시부터 자동 배포가 작동합니다. 이 특성은 조사 중에 새로운 변경 사항이 본(本)에 들어오는 것을 막을 수 있는 선택지로 사용될 수 있습니다.

다만, 자동 배포를 중단하는 것 자체가 고장 난 공개 상태를 이전 상태로 되돌리는 조작은 아닙니다. 중단, 복구, 확인, 재개는 별개의 절차로 작성합니다.

또한, 프리뷰는 URL을 아는 사람이 접근할 수 있으며, DeployNow 자체에는 접근 제한 기능이 없습니다. 복구 확인용 프리뷰에 비밀 정보나 공개 전 기밀 데이터를 함부로 두지 않는 것도 복구 카드에 남깁니다.

주간 리뷰 결과가 빨간색이라도 월요일이 되면 새로운 기능을 시작하고 싶어집니다. 그래서 '무엇을 만들 것인가'보다 '시작해도 되는가'를 확인합니다.

[ ] 지난주의 중대한 문제에 대해, 지속/중단/복구 판단이 있는지
[ ] 마지막으로 정상이었던 본(本) 커밋이 무엇인지 알 수 있는지
[ ] AI에 대한 공통 지침이 최신인지
...

하나라도 '아니오'가 있다면, 반드시 작업을 전면 중단한다는 의미는 아닙니다. 먼저 그 부족한 부분을 고치는 운영 개선을 이번 주 첫 변경으로 삼습니다.

예시:

마지막 정상 커밋이 불명확함
→ 신규 기능을 시작하지 않고, 본 배포 기록과 GitHub의 대응을 확인한다.
복구 카드가 오래됨...

시작 조건은 작업을 늦추는 관문이 아닙니다. 막막한 상태로 만들기 시작하여 도중에 되돌리는 시간을 줄이기 위한 관문입니다.

어느 주에 AI에게 '전송 버튼의 문구를 바꿔달라'고 요청했는데, 주변 부품 정리까지 제안받았습니다. 차이가 커지고, 프리뷰 확인에도 시간이 걸렸다고 가정합니다.

작은 문구 변경에도 불구하고, 변경 범위가 너무 넓었습니다.
목적과 관련 없는 정리를 동시에 진행했기 때문에 확인 대상이 늘어났습니다.

이번 목적과 직접적인 관련이 없는 정리, 명칭 변경, 부품 분할은 하지 않습니다.
필요하다고 생각되어도 실행하지 않고, 별도의 안건으로 보고합니다.

[ ] 변경 파일은 예정된 범위에만 있는가
[ ] 목적 외의 정리가 섞여있지 않은가

이번 문제가 실제 프로덕션 장애(Production Failure)가 아니라면, 복구 카드(Recovery Card)는 수정하지 않습니다. 모든 개선 사항을 무리하게 적용하는 것도 중요합니다.

[ ] 첫 번째 변경은 하나의 가치와 하나의 확인 방법으로 설명할 수 있는가

이로써 'AI에게 더 신중하게 의존해야 한다'는 추상적인 반성이, 다음 요청과 확인 과정에서 활용 가능한 환경으로 바뀝니다.

AI는 주간 리뷰 반영 작업을 상당히 도와줄 수 있습니다.

AI에 맡기기 쉬운 것:

• 1주일 기록에서 반복적으로 발생한 문제 추출하기
• 문제를 지침(Instruction), 일일 확인(Daily Check), 복구(Recovery), 시작 조건(Start Condition)으로 분류하기
• 중복되는 체크 항목 찾기
• 모호한 문장을 행동 및 합격 조건으로 다시 작성할 초안 제시하기
• 변경 전후의 절차 차이점 요약하기

사람이 결정해야 하는 것:

• 어떤 문제를 최우선 순위로 둘지
• 프로덕션 반영을 멈추는 영향의 크기
• 기밀 정보나 사용자 데이터에 대한 경계
• 복구 실행 및 자동 배포(Auto Deploy) 재개
• 규칙을 표준화, 보류, 삭제할 판단

AI 요청 예시:

다음은 이번 주 일일 기록입니다.
같은 원인으로 반복된 문제 3가지를 추출해 주세요.
각 문제를 'AI 지침', '일일 체크', '복구 카드', '차주 시작 조건'의
... 

이 요청만으로는 채택을 자동화하지 않습니다. 제 작업에 맞는지 확인하고, 사람이 선택한 것만 절차에 반영합니다.

개선을 매주 추가하면, 한 달 후에는 읽기 어려운 양이 됩니다. 추가와 동시에 정리 기준을 갖습니다.

같은 시점, 같은 대상, 같은 중단 조건의 항목은 하나로 통합합니다.

환경 변수를 변경한 날에만 필요한 확인 사항은 매일 공통 체크에서 제외합니다.

다음 조건을 모두 충족하는 항목은 삭제 후보입니다.

• 3주 이상 사용하지 않은 경우
• 대상 기능이나 운영 자체가 존재하지 않는 경우
• 다른 항목으로 같은 경계를 지킬 수 있는 경우
• 삭제해도 중단 조건이 상실되지 않는 경우

빈도가 낮더라도, 기밀 정보, 데이터 손실(Data Loss), 프로덕션 중단, 사람의 승인(Human Approval)에 관한 경계는 단순히 사용하지 않았다는 이유로 지우지 않습니다.

절차의 목적은 모든 과거를 보존하는 것이 아니라, 다음 작업에서 안전하게 판단할 수 있도록 하는 것입니다. 상세한 사건은 주간 기록으로 남기고, 매번 사용하는 짧은 행동만 작업 환경에 남깁니다.

개선의 효과는 '문서를 고쳤다'로 측정하지 않습니다. 다음 주에 다음 변화가 있었는지 봅니다.

• 사용하는 타이밍이 달랐는지
• 문장이 길어서 읽히지 않았는지
• 합격 조건이 모호했는지
• 체크 장소가 평소 동선에서 벗어났는지
• 애초에 문제의 원인을 오해했는지

이 관점에서, 위치나 작성 방식을 다시 바꿉니다.

처음부터 복잡한 관리 시스템은 필요하지 않습니다.

project/
├── AI_REQUEST.md # AI에게 공통 지침
├── DAILY_CHECK.md # 시작 전・프로덕션 반영 전・공개 후
... 

주간 리뷰의 끝에, 다음 주 시작 조건과 3가지까지의 개선 이력을 남깁니다.

이 세 파일을 실제로 작업을 시작하는 곳에서 바로 열 수 있게 합니다. 만들어만 두고 보지 않는 문서보다 매일 여는 짧은 문서가 더 유용합니다.

AI에게 공통 지침을 한 화면에 만들고, 변경해도 되는 범위와 중단 조건을 작성합니다.

시작 전, 프로덕션 반영 전, 공개 후의 체크를 만들고 실행 시간을 측정합니다.

마지막으로 정상이었던 커밋(Commit)을 확인하고, 복구 카드에 기록합니다.

공개를 수반하지 않는 작은 변경으로 AI 지침과 일일 체크를 모의 실행합니다.

복구 카드를 읽고, 중단, 정상 지점 특정, 확인, 재개 판단 순서를 설명할 수 있는지 시험해 봅니다.

중복되는 항목과 사용하지 않은 항목을 찾습니다.

가장 효과적이었던 개선 사항을 하나 표준화하고, 다음 주에 남길 개선 사항을 최대 3가지까지 선택합니다.

처음부터 완벽한 절차를 만드는 것이 아니라, 사용하다 막힌 곳을 다음 주 환경으로 되돌립니다.

본 기사에서는 DeployNow의 현행 사양에 대해 2026년 11월 4일 공식 문서를 통해 다음 사항을 확인했습니다.

• GitHub에 연결된 대상 브랜치로 push하면, 자동으로 빌드와 배포(deploy)가 시작됩니다.
• 자동 배포를 중지해도, 공개 사이트와 리포지토리 연결은 유지됩니다.
• 자동 배포가 중지된 동안에는 push에 의한 배포나 새로운 프리뷰 생성/업데이트가 작동하지 않습니다.
• 프리뷰 URL에는 DeployNow 측의 접근 제한 기능이 없습니다.

화면이나 사양은 변경될 수 있습니다. 실제로 설정을 변경할 때는 최신 공식 정보를 확인해 주십시오.

참고:

주간 리뷰의 가치는 좋았던 점과 나빴던 점을 기록하는 것만이 아닙니다. 발견한 개선 사항을 다음 주 작업에서 자연스럽게 사용할 수 있는 환경으로 되돌리는 데 있습니다.

이번 핵심 내용은 다음과 같습니다.

• 개선은 '주의할 점'이 아니라, 적용 시점, 행동, 합격 조건(pass condition), 중지 조건(stop condition)으로 바꿉니다.
• AI에 대한 지침, 일일 체크리스트, 복구 카드, 다음 주 시작 조건 등으로 분리합니다.
• 1주일 동안 바꿀 것은 최대 3가지로 제한합니다.
• 문서를 업데이트한 후, 공개를 동반하지 않는 모의 실행을 합니다.
• AI에게는 추출과 정리를 맡기고, 우선순위, 중지, 복구, 재개는 사람이 결정합니다.
• 추가뿐만 아니라, 통합(integration), 조건부화(conditionalization), 삭제도 매주 수행합니다.
• 효과는 다음 주 행동이 달라졌는지로 확인합니다.

매일 배포를 계속할수록 작업 환경에는 작은 개선이 축적됩니다. 중요한 것은 실패를 없애는 것이 아니라, 실패로부터 얻은 지식을 다음 작업에 적용하여 같은 망설임을 줄이는 것입니다.

첫걸음은 이번 주 반성 중 하나를 골라, "다음에는 주의한다"를 "언제, 무엇을 확인하고, 무엇이 발생하면 멈출지"로 다시 작성하는 것입니다.

다음 시간에는 이 3개의 파일을 실제 폴더와 브라우저 작업 흐름(workflow)에 배치하여, 작업 시작부터 공개 후 확인까지 망설임 없이 열 수 있는 '데일리 배포 대시보드'를 만드는 방법을 정리하겠습니다.