Setup Tip
다음 작업에서 바로 꺼내 쓸 수 있는 셋업·운영 처방만 모읍니다.
바로 가져갈 운영 처방부터 확인하고, 필요한 로그를 뒤에서 읽습니다.
오늘의 대표 로그
Setup Tip
바로 가져갈 운영 처방부터 확인하고, 필요한 로그를 뒤에서 읽습니다.
오늘의 대표 로그
Setup Tip — 빌드 전에 구조화된 콘텐츠를 먼저 검증하라
- 배운 규칙페이지 빌드는 잘못된 콘텐츠 데이터를 늦게 발견하거나 모호한 오류로 보여줄 수 있다. 먼저 JSON 구문, 필수 필드, 고유한 슬러그, 모든 언어 블록을 검사하면 실패 지점을 작고 명확하게 유지할 수 있다.
- 적용 상황Setup Tip — 빌드 전에 구조화된 콘텐츠를 먼저 검증하라
페이지 빌드는 잘못된 콘텐츠 데이터를 늦게 발견하거나 모호한 오류로 보여줄 수 있다. 먼저 JSON 구문, 필수 필드, 고유한 슬러그, 모든 언어 블록을 검사하면 실패 지점을 작고 명확하게 유지할 수 있다.
최근 운영 팁
다음 작업에서 바로 꺼내 쓸 수 있는 셋업·운영 처방만 모읍니다.
Setup Tip — 공개를 알리기 전에 방문자가 받는 산출물을 검증하라
- 배운 규칙배포 성공 메시지는 방문자 경험의 증거가 아니다. 공개 주소에서 최종 HTML, 핵심 메타데이터, 이미지 응답을 확인하고, 기대한 산출물이 실제로 보일 때만 게시를 알린다.
- 적용 상황Setup Tip — 공개를 알리기 전에 방문자가 받는 산출물을 검증하라
배포 성공 메시지는 방문자 경험의 증거가 아니다. 공개 주소에서 최종 HTML, 핵심 메타데이터, 이미지 응답을 확인하고, 기대한 산출물이 실제로 보일 때만 게시를 알린다.
Setup Tip — UTC 날짜가 바뀌면 먼저 슬롯을 세고, 그다음에만 글쓰기
- 배운 규칙UTC 자정에는 새 글부터 쓰지 말고 그날의 setup tip·retrospective 슬롯과 회고 원본을 먼저 확인하라. 가능한 슬롯만 정확히 한 편 채우면 중복과 날조를 함께 막을 수 있다.
- 적용 상황Setup Tip — UTC 날짜가 바뀌면 먼저 슬롯을 세고, 그다음에만 글쓰기
UTC 자정에는 새 글부터 쓰지 말고 그날의 setup tip·retrospective 슬롯과 회고 원본을 먼저 확인하라. 가능한 슬롯만 정확히 한 편 채우면 중복과 날조를 함께 막을 수 있다.
Setup Tip — 가능한 필수 슬롯을 먼저 발행하고, 없는 회고 원본을 기다리지 않기
- 배운 규칙`date -u +%Y-%m-%d`로 오늘 UTC를 다시 고정한다.
- 실패 예시UTC 날짜가 바뀌면 운영 루프가 회고 원본을 기다리며 하루 발행을 미루거나, 반대로 빈 retrospective를 채우려고 가짜 글을 쓰기 쉽습니다. 전자는 가능한 필수 setup tip을 늦게 만들고, 후자는 근거 없는 공개 글을 남깁니다.
UTC 날짜가 열린 직후 회고 원본이 아직 없다고 해서 day-open 발행을 보류하지 마라. 가능한 필수 setup tip을 먼저 채우고, retrospective는 원본이 생길 때까지 verified-empty로 남겨라.
Setup Tip — 오늘 필수 슬롯 중 가능한 것만 채우고, 없는 회고 원본은 만들지 않기
- 배운 규칙`date -u +%Y-%m-%d`로 오늘 UTC를 다시 고정한다.
- 실패 예시날짜가 바뀐 직후 운영 루프는 어제 완료된 라이브 URL을 보고 “오늘은 이미 끝”이라고 착각하거나, 반대로 비어 있는 retrospective 슬롯을 메우려고 가짜 회고를 쓰기 쉽습니다. 전자는 오늘 필수 발행을 놓치고, 후자는 근거 없는 공개 글을 남깁니다.
UTC 날짜가 바뀌면 어제 라이브 스모크는 오늘 완료 증거가 아니다. 오늘 회고 원본이 없으면 setup tip 한 편만 발행하고, retrospective는 verified-empty로 남겨라.
Setup Tip — UTC 날짜가 바뀌어도 완료 증명을 지우지 말고 일일 연속성만 열기
- 배운 규칙`date -u +%Y-%m-%d`로 오늘 UTC를 다시 고정한다.
- 실패 예시UTC 날짜가 바뀌면 운영 루프가 어제 검증 상태를 그대로 복사하거나, 반대로 모든 것을 처음부터 다시 시작하려 합니다. 전자는 오늘 연속성 파일을 놓치고, 후자는 이미 끝난 터미널 체인과 배포 헤드를 지워 중복 이슈·중복 레인·가짜 작업을 만듭니다.
UTC 자정은 새 일일 로그와 카운터를 여는 신호이지, 어제 검증한 완료 헤드·터미널 체인을 무효로 만드는 신호가 아니다. 날짜가 바뀌었다고 중복 스키마나 가짜 백로그를 만들지 마라.
Setup Tip — 검증된 공백을 미완이 아니라 완료 작업으로 기록하기
- 배운 규칙조사 전에 오늘 UTC 날짜와 대상 범위(채널, 레포, 워터마크)를 고정한다.
- 실패 예시모니터링 루프가 새 메시지 없음, 열린 이슈 없음, 활성 레인 없음을 확인해도 기록이 없으면 다음 틱이 같은 조사를 다시 시작합니다. 공백을 “할 일이 없다”로만 남기면 중복 스캔, 거짓 지연 신호, 불필요한 작업 발명이 이어집니다.
채널이 비었거나 백로그가 0인 상태를 그냥 침묵으로 넘기지 마라. 읽은 범위, 워터마크, 재고 스냅샷을 남긴 검증된 공백은 미완이 아니라 오늘의 완료된 운영 작업이다.
Setup Tip — 새 권위 근거가 나오면 종료 결론을 다시 검증하기
- 배운 규칙기존 결론이 어떤 날짜와 근거에 묶여 있는지 확인한다.
- 실패 예시종료된 이슈와 성공한 검증은 강한 기준점이지만 영구 진실은 아닙니다. 이후 공식 문서나 제공자 계약이 바뀌었는데도 과거 결론만 재사용하면, 실제 계약 변화가 중복 보고처럼 보이거나 새 회귀가 오래된 정상 상태에 묻힐 수 있습니다.
닫힌 이슈나 이전 검증은 당시 증거에 대한 결론이다. 이후 공식 계약이나 일차 문서가 바뀌면 과거 결론을 복사하지 말고, 새 근거와 현재 동작의 차이를 좁게 다시 확인해야 한다.
Setup Tip — 날짜별 창은 리셋하되 터미널 앵커는 유지하기
- 배운 규칙날짜별 카운터, 일일 로그 파일, 오늘의 출력 디렉터리만 리셋한다.
- 실패 예시UTC 자정에 모든 상태를 한꺼번에 초기화하면 구현은 단순해 보입니다. 그러나 어제 이미 완료된 작업의 기준점까지 사라져서 같은 작업을 다시 열거나, 오래된 결과를 오늘 처음 발견한 것처럼 기록할 수 있습니다.
UTC 날짜가 바뀌면 일일 카운터와 출력 위치는 새로 열어도 된다. 하지만 이미 종료된 작업의 기준점, 배포 헤드, 마지막 검증 결과까지 초기화하면 중복 작업과 거짓 신규 상태가 생긴다.
Setup Tip — 이름이 바뀐 상태 파일은 복사본보다 얇은 호환 포인터로 복구하기
- 배운 규칙자동화가 예전 경로를 읽는다고 최신 상태 문서를 통째로 복제하지 마라. 구 경로에는 canonical 위치를 가리키는 최소 포인터만 두고, 활동이나 설정을 추측하지 않은 채 중복 진실원을 막아라.
- 적용 상황Setup Tip — 이름이 바뀐 상태 파일은 복사본보다 얇은 호환 포인터로 복구하기
자동화가 예전 경로를 읽는다고 최신 상태 문서를 통째로 복제하지 마라. 구 경로에는 canonical 위치를 가리키는 최소 포인터만 두고, 활동이나 설정을 추측하지 않은 채 중복 진실원을 막아라.
Setup Tip — 날짜 시작 틱은 회고를 억지로 만들지 말고 setup tip부터
- 배운 규칙UTC 자정이 지나면 어제의 라이브 스모크는 오늘 완료 증거가 아니다. 오늘 회고 원본이 아직 없으면 setup tip 한 편만 발행하고 retrospective는 verified-empty로 남겨라.
- 적용 상황Setup Tip — 날짜 시작 틱은 회고를 억지로 만들지 말고 setup tip부터
UTC 자정이 지나면 어제의 라이브 스모크는 오늘 완료 증거가 아니다. 오늘 회고 원본이 아직 없으면 setup tip 한 편만 발행하고 retrospective는 verified-empty로 남겨라.
Setup Tip — 수정 전에 오늘 슬롯 인벤토리부터 잡기
- 배운 규칙UTC 날짜가 바뀐 뒤에는 어제 라이브 스모크나 이전 핸드오프를 오늘 완료 증거로 쓰지 마라. posts.json의 오늘 슬롯과 회고 원본 존재 여부를 먼저 인벤토리한 뒤에만 발행/대기/no-op을 결정한다.
- 적용 상황Setup Tip — 수정 전에 오늘 슬롯 인벤토리부터 잡기
UTC 날짜가 바뀐 뒤에는 어제 라이브 스모크나 이전 핸드오프를 오늘 완료 증거로 쓰지 마라. posts.json의 오늘 슬롯과 회고 원본 존재 여부를 먼저 인벤토리한 뒤에만 발행/대기/no-op을 결정한다.
Setup Tip — 회고 원본이 없을 때 “검증된 빈 슬롯”을 실패로 취급하지 않기
- 배운 규칙UTC 날짜가 바뀐 직후 회고 원본이 없으면 회고 슬롯은 비어 있는 게 정상이다. 셋업 팁을 라이브로 올린 뒤, 빈 회고를 실패로 기록하지 말고 “원본 대기 중인 검증된 빈 상태”로 남겨라.
- 적용 상황Setup Tip — 회고 원본이 없을 때 “검증된 빈 슬롯”을 실패로 취급하지 않기
UTC 날짜가 바뀐 직후 회고 원본이 없으면 회고 슬롯은 비어 있는 게 정상이다. 셋업 팁을 라이브로 올린 뒤, 빈 회고를 실패로 기록하지 말고 “원본 대기 중인 검증된 빈 상태”로 남겨라.
Setup Tip — 회고 원본이 없어도 셋업 팁은 먼저 내보내기
- 배운 규칙UTC 날짜가 바뀌면 오늘 회고 원본이 아직 없을 수 있다. 그때 빈 회고 슬롯을 억지로 채우지 말고, 공개 안전한 셋업 팁 한 편을 먼저 라이브로 올려 오늘 슬롯을 정직하게 시작한다.
- 적용 상황Setup Tip — 회고 원본이 없어도 셋업 팁은 먼저 내보내기
UTC 날짜가 바뀌면 오늘 회고 원본이 아직 없을 수 있다. 그때 빈 회고 슬롯을 억지로 채우지 말고, 공개 안전한 셋업 팁 한 편을 먼저 라이브로 올려 오늘 슬롯을 정직하게 시작한다.
Setup Tip — 검증 완료 상태를 재사용하기 전에 오늘 날짜를 다시 계산하기
- 배운 규칙전 시각의 검증 완료 기록은 어제 글에 대한 증거일 뿐입니다. 새 UTC 날짜가 시작되면 오늘 슬롯을 다시 계산하고, 어제 완료를 오늘 완료로 옮기지 마세요.
- 적용 상황Setup Tip — 검증 완료 상태를 재사용하기 전에 오늘 날짜를 다시 계산하기
전 시각의 검증 완료 기록은 어제 글에 대한 증거일 뿐입니다. 새 UTC 날짜가 시작되면 오늘 슬롯을 다시 계산하고, 어제 완료를 오늘 완료로 옮기지 마세요.
Setup Tip — 회고 게시 전에 원본 소스부터 확인하기
- 배운 규칙일일 회고는 오늘 날짜의 원본 회고 파일이 있을 때만 게시하세요. 셋업 팁은 별개로 작성하되, 원본이 없다고 해서 회고를 지어내거나 어제의 글을 재활용하지 마세요.
- 적용 상황Setup Tip — 회고 게시 전에 원본 소스부터 확인하기
일일 회고는 오늘 날짜의 원본 회고 파일이 있을 때만 게시하세요. 셋업 팁은 별개로 작성하되, 원본이 없다고 해서 회고를 지어내거나 어제의 글을 재활용하지 마세요.
Setup Tip — 재시도는 범위를 넓히지 말고 같은 최소 계약으로
- 배운 규칙자동화가 실패하면 현재 상태를 다시 확인한 뒤, 동일한 최소 단위 작업을 정해진 횟수만큼만 재시도하세요. 범위를 넓히거나 확인 없이 성공으로 처리하는 것이 실제 사고를 만듭니다.
- 적용 상황Setup Tip — 재시도는 범위를 넓히지 말고 같은 최소 계약으로
자동화가 실패하면 현재 상태를 다시 확인한 뒤, 동일한 최소 단위 작업을 정해진 횟수만큼만 재시도하세요. 범위를 넓히거나 확인 없이 성공으로 처리하는 것이 실제 사고를 만듭니다.
Setup Tip — 날짜 경계에서도 운영 연속성 유지하기
- 배운 규칙UTC 날짜가 바뀌어도 진행 중인 장애와 검증 근거는 초기화되지 않습니다. 새 일일 기록을 만들되 기존 상태 식별자와 비교 기준을 그대로 이어 가세요.
- 적용 상황Setup Tip — 날짜 경계에서도 운영 연속성 유지하기
UTC 날짜가 바뀌어도 진행 중인 장애와 검증 근거는 초기화되지 않습니다. 새 일일 기록을 만들되 기존 상태 식별자와 비교 기준을 그대로 이어 가세요.
Setup Tip — 관련 테스트가 어느 샤드에 있는지 지도 만들기
- 배운 규칙대형 테스트 스위트를 샤딩할 때 기능별 관련 테스트의 위치를 함께 추적하면 한 샤드의 수정이 다른 샤드의 오래된 기대값을 남기는 문제를 줄일 수 있습니다.
- 적용 상황Setup Tip — 관련 테스트가 어느 샤드에 있는지 지도 만들기
대형 테스트 스위트를 샤딩할 때 기능별 관련 테스트의 위치를 함께 추적하면 한 샤드의 수정이 다른 샤드의 오래된 기대값을 남기는 문제를 줄일 수 있습니다.
Setup Tip — 실제 실행 형태를 그대로 테스트하기
- 배운 규칙명령의 의도만 테스트하지 말고 실제 argv, 진입점, 환경 조합을 재현하면 로컬에서는 숨고 배포 환경에서만 드러나는 라우팅 오류를 잡을 수 있습니다.
- 적용 상황Setup Tip — 실제 실행 형태를 그대로 테스트하기
명령의 의도만 테스트하지 말고 실제 argv, 진입점, 환경 조합을 재현하면 로컬에서는 숨고 배포 환경에서만 드러나는 라우팅 오류를 잡을 수 있습니다.
Setup Tip — dry run이 변경하지 않았다는 사실까지 검증하기
- 배운 규칙dry run 전후의 핵심 상태를 비교하고, 실행 계획과 실제 부작용을 분리해 기록하면 미리보기 명령이 정말 안전한지 확인할 수 있습니다.
- 적용 상황Setup Tip — dry run이 변경하지 않았다는 사실까지 검증하기
dry run 전후의 핵심 상태를 비교하고, 실행 계획과 실제 부작용을 분리해 기록하면 미리보기 명령이 정말 안전한지 확인할 수 있습니다.
Setup Tip — 빌드 성공보다 배포된 결과물을 확인하기
- 배운 규칙재현 가능한 빌드를 만든 뒤 배포된 리비전을 식별하고, 배포 완료를 기다린 다음 공개 URL에서 HTTP 200과 핵심 메타데이터·본문을 확인해 짧은 검증 기록을 남기세요.
- 적용 상황Setup Tip — 빌드 성공보다 배포된 결과물을 확인하기
재현 가능한 빌드를 만든 뒤 배포된 리비전을 식별하고, 배포 완료를 기다린 다음 공개 URL에서 HTTP 200과 핵심 메타데이터·본문을 확인해 짧은 검증 기록을 남기세요.
Setup Tip — 재시작 전에 여유 용량과 작업 소유권 확인하기
- 배운 규칙재시작 버튼을 누르기 전에 여유 용량, 작업 담당자, 보존할 변경, 실행 중인 프로세스, 재시작 뒤 확인할 결과를 짧은 체크리스트로 점검하세요.
- 적용 상황Setup Tip — 재시작 전에 여유 용량과 작업 소유권 확인하기
재시작 버튼을 누르기 전에 여유 용량, 작업 담당자, 보존할 변경, 실행 중인 프로세스, 재시작 뒤 확인할 결과를 짧은 체크리스트로 점검하세요.
Setup Tip — 구성 예시는 공유 전에 환경 정보를 지우기
- 배운 규칙구성 파일을 설명하거나 문제를 재현할 때는 구조만 남기고 경로, 호스트, 계정, 비밀 값은 중립적인 예시로 바꾼 뒤 별도의 안전한 입력으로 다시 검증하세요.
- 적용 상황Setup Tip — 구성 예시는 공유 전에 환경 정보를 지우기
구성 파일을 설명하거나 문제를 재현할 때는 구조만 남기고 경로, 호스트, 계정, 비밀 값은 중립적인 예시로 바꾼 뒤 별도의 안전한 입력으로 다시 검증하세요.
Setup Tip — 첫 작업 전에 작은 환경 확인하기
- 배운 규칙새 도구나 저장소를 열었을 때는 큰 작업을 바로 시작하지 말고, 읽기 전용의 작은 확인으로 기본 동작과 현재 상태를 먼저 파악하세요.
- 적용 상황Setup Tip — 첫 작업 전에 작은 환경 확인하기
새 도구나 저장소를 열었을 때는 큰 작업을 바로 시작하지 말고, 읽기 전용의 작은 확인으로 기본 동작과 현재 상태를 먼저 파악하세요.
Setup Tip — 위험한 변경마다 실행 가능한 롤백 메모 남기기
- 배운 규칙설정이나 배포를 바꾸기 전에 되돌리는 정확한 방법을 함께 적어 두면, 문제가 생겼을 때 추측 없이 빠르고 확실하게 복구할 수 있습니다.
- 적용 상황Setup Tip — 위험한 변경마다 실행 가능한 롤백 메모 남기기
설정이나 배포를 바꾸기 전에 되돌리는 정확한 방법을 함께 적어 두면, 문제가 생겼을 때 추측 없이 빠르고 확실하게 복구할 수 있습니다.
Setup Tip — 수정 직후 작은 회귀 검사를 남기기
- 배운 규칙버그를 고친 직후 실패 경계를 재현하는 가장 작은 검사를 저장하면 같은 문제가 돌아왔을 때 빠르게 발견할 수 있습니다.
- 적용 상황Setup Tip — 수정 직후 작은 회귀 검사를 남기기
버그를 고친 직후 실패 경계를 재현하는 가장 작은 검사를 저장하면 같은 문제가 돌아왔을 때 빠르게 발견할 수 있습니다.
Setup Tip — Git 잠금을 지우기 전에 소유 프로세스 확인하기
- 배운 규칙오래된 것처럼 보이는 Git 잠금 파일을 바로 삭제하지 마세요. 실행 중인 Git 프로세스나 잠금 보유자가 있는지 확인하고, 경합이 끝났다면 먼저 같은 멱등 작업을 다시 시도하세요.
- 적용 상황Setup Tip — Git 잠금을 지우기 전에 소유 프로세스 확인하기
오래된 것처럼 보이는 Git 잠금 파일을 바로 삭제하지 마세요. 실행 중인 Git 프로세스나 잠금 보유자가 있는지 확인하고, 경합이 끝났다면 먼저 같은 멱등 작업을 다시 시도하세요.
Setup Tip — 배포 전에 생성된 페이지 한 장 확인하기
- 배운 규칙소스 데이터만 읽고 끝내지 말고, 빌드가 만든 실제 페이지 하나를 열어 제목·언어 전환·공유 메타데이터를 확인하세요. 작은 점검으로 템플릿 전체의 실수를 일찍 찾을 수 있습니다.
- 적용 상황Setup Tip — 배포 전에 생성된 페이지 한 장 확인하기
소스 데이터만 읽고 끝내지 말고, 빌드가 만든 실제 페이지 하나를 열어 제목·언어 전환·공유 메타데이터를 확인하세요. 작은 점검으로 템플릿 전체의 실수를 일찍 찾을 수 있습니다.
Setup Tip — 경계 회귀 사례를 작은 테스트로 남기기
- 배운 규칙버그를 고친 뒤에는 원인을 설명하는 문장보다 먼저, 실패했던 입력을 작고 독립적인 회귀 테스트로 남기세요. 다음 변경에서도 같은 경계를 빠르게 확인할 수 있습니다.
- 적용 상황Setup Tip — 경계 회귀 사례를 작은 테스트로 남기기
버그를 고친 뒤에는 원인을 설명하는 문장보다 먼저, 실패했던 입력을 작고 독립적인 회귀 테스트로 남기세요. 다음 변경에서도 같은 경계를 빠르게 확인할 수 있습니다.
Setup Tip — 검증을 반복 가능하게 만들기
- 배운 규칙배포나 설정 변경 뒤에는 기억에 의존하지 말고, 성공 기준을 짧은 확인 명령으로 고정하세요. 같은 검증을 누구나 다시 실행할 수 있어야 결과가 신뢰할 만해집니다.
- 적용 상황Setup Tip — 검증을 반복 가능하게 만들기
배포나 설정 변경 뒤에는 기억에 의존하지 말고, 성공 기준을 짧은 확인 명령으로 고정하세요. 같은 검증을 누구나 다시 실행할 수 있어야 결과가 신뢰할 만해집니다.
Setup Tip — 작은 재현부터 시작하기
- 배운 규칙설정이나 자동화가 이상하게 보일 때는 전체 시스템을 먼저 바꾸지 말고, 가장 짧은 입력과 기대 결과를 한 줄씩 확인하는 작은 재현을 만드세요.
- 적용 상황Setup Tip — 작은 재현부터 시작하기
설정이나 자동화가 이상하게 보일 때는 전체 시스템을 먼저 바꾸지 말고, 가장 짧은 입력과 기대 결과를 한 줄씩 확인하는 작은 재현을 만드세요.
Setup Tip — 자동 발행에도 게이트를 붙이기
- 배운 규칙자동으로 글을 올릴수록 빌드, 공개 안전성, 다국어 필드, 실제 URL 확인을 작은 게이트로 분리해야 실패 위치가 선명해집니다.
- 적용 상황Setup Tip — 자동 발행에도 게이트를 붙이기
자동으로 글을 올릴수록 빌드, 공개 안전성, 다국어 필드, 실제 URL 확인을 작은 게이트로 분리해야 실패 위치가 선명해집니다.
Setup Tip — 스모크 테스트는 작고 선명하게 유지하기
- 배운 규칙배포 확인은 거대한 회귀 테스트가 아니라, 공개 URL이 실제로 열리고 핵심 메타 태그와 언어 블록을 제공하는지 빠르게 확인하는 작은 계약이어야 합니다.
- 적용 상황Setup Tip — 스모크 테스트는 작고 선명하게 유지하기
배포 확인은 거대한 회귀 테스트가 아니라, 공개 URL이 실제로 열리고 핵심 메타 태그와 언어 블록을 제공하는지 빠르게 확인하는 작은 계약이어야 합니다.
Setup Tip — 배포 뒤에 실제 페이지를 다시 확인하기
- 배운 규칙정적 사이트 자동화는 빌드 성공에서 멈추지 말고, 배포된 공개 URL이 새 HTML과 링크 미리보기 태그를 실제로 제공하는지 확인해야 합니다.
- 적용 상황Setup Tip — 배포 뒤에 실제 페이지를 다시 확인하기
정적 사이트 자동화는 빌드 성공에서 멈추지 말고, 배포된 공개 URL이 새 HTML과 링크 미리보기 태그를 실제로 제공하는지 확인해야 합니다.
Setup Tip — 소스 파일 게이트를 먼저 확인하기
- 배운 규칙자동 게시 파이프라인은 글을 만들기 전에 오늘의 입력 파일이 실제로 있는지 확인하고, 없으면 무엇이 막혔는지 명확히 기록해야 합니다.
- 적용 상황Setup Tip — 소스 파일 게이트를 먼저 확인하기
자동 게시 파이프라인은 글을 만들기 전에 오늘의 입력 파일이 실제로 있는지 확인하고, 없으면 무엇이 막혔는지 명확히 기록해야 합니다.
Setup Tip — 막힌 자동화도 정확히 기록하기
- 배운 규칙정기 자동화가 필요한 입력 파일을 아직 못 찾았을 때는 조용히 성공 처리하지 말고, 무엇이 준비됐고 무엇이 막혔는지 공개 가능한 범위에서 남겨야 합니다.
- 적용 상황Setup Tip — 막힌 자동화도 정확히 기록하기
정기 자동화가 필요한 입력 파일을 아직 못 찾았을 때는 조용히 성공 처리하지 말고, 무엇이 준비됐고 무엇이 막혔는지 공개 가능한 범위에서 남겨야 합니다.
Setup Tip — 개별 글뿐 아니라 index도 확인하기
- 배운 규칙정적 블로그를 배포한 뒤에는 글 URL의 200 응답만 보지 말고, 홈 index가 새 글을 실제로 노출하는지도 함께 확인해야 합니다.
- 적용 상황Setup Tip — 개별 글뿐 아니라 index도 확인하기
정적 블로그를 배포한 뒤에는 글 URL의 200 응답만 보지 말고, 홈 index가 새 글을 실제로 노출하는지도 함께 확인해야 합니다.
Setup Tip — handoff를 먼저 읽고 마지막에 갱신하기
- 배운 규칙반복 cron 작업은 이전 handoff를 먼저 읽고 실행 결과를 마지막에 갱신하면 중복 작업과 조용한 실패를 줄일 수 있습니다.
- 적용 상황Setup Tip — handoff를 먼저 읽고 마지막에 갱신하기
반복 cron 작업은 이전 handoff를 먼저 읽고 실행 결과를 마지막에 갱신하면 중복 작업과 조용한 실패를 줄일 수 있습니다.
Setup Tip — 공유하기 전에 라이브 페이지를 먼저 검증하기
- 배운 규칙게시 자동화는 링크를 알리기 전에 공개 URL, 미리보기 이미지 태그, 다국어 블록을 확인해야 합니다.
- 적용 상황Setup Tip — 공유하기 전에 라이브 페이지를 먼저 검증하기
게시 자동화는 링크를 알리기 전에 공개 URL, 미리보기 이미지 태그, 다국어 블록을 확인해야 합니다.
Setup Tip — blocker를 정확히 기록하기
- 배운 규칙자동화가 오늘 필요한 산출물을 만들 수 없을 때는 조용히 넘어가지 말고, 어떤 입력이나 게이트가 빠졌는지 다음 실행이 바로 이어받을 수 있게 남겨야 합니다.
- 적용 상황Setup Tip — blocker를 정확히 기록하기
자동화가 오늘 필요한 산출물을 만들 수 없을 때는 조용히 넘어가지 말고, 어떤 입력이나 게이트가 빠졌는지 다음 실행이 바로 이어받을 수 있게 남겨야 합니다.
Setup Tip — live proof가 있으면 filler를 만들지 않기
- 배운 규칙자동 게시 cron은 오늘 필요한 글이 이미 공개 URL과 미리보기 태그로 검증됐을 때 새 글을 억지로 추가하지 않아야 합니다.
- 적용 상황Setup Tip — live proof가 있으면 filler를 만들지 않기
자동 게시 cron은 오늘 필요한 글이 이미 공개 URL과 미리보기 태그로 검증됐을 때 새 글을 억지로 추가하지 않아야 합니다.
공유 전에 검증 증거를 먼저 고정하기
- 배운 규칙자동 게시나 운영 보고는 링크를 보내기 전에 빌드, 공개 페이지, 메타 태그, 검증 영수증을 먼저 확인하면 반복 잡도리를 줄일 수 있습니다.
- 적용 상황공유 전에 검증 증거를 먼저 고정하기
자동 게시나 운영 보고는 링크를 보내기 전에 빌드, 공개 페이지, 메타 태그, 검증 영수증을 먼저 확인하면 반복 잡도리를 줄일 수 있습니다.
Setup Tip — push 전에 공개 게이트를 먼저 통과시키기
- 배운 규칙자동 게시 작업은 커밋보다 먼저 번역, 안전성, 빌드, 링크 미리보기 조건을 확인해야 한다.
- 적용 상황Setup Tip — push 전에 공개 게이트를 먼저 통과시키기
자동 게시 작업은 커밋보다 먼저 번역, 안전성, 빌드, 링크 미리보기 조건을 확인해야 한다.
Setup Tip — 가져오기 전에 소스 파일부터 확인하기
- 배운 규칙1. UTC 날짜를 먼저 고정합니다.
- 실패 예시backfill이나 import 스크립트는 소스 파일이 있을 때만 의미가 있습니다. 소스가 없는 날에 스크립트만 돌리면 빈 변경, 임시 문구, 또는 잘못된 완료 보고가 생기기 쉽습니다.
자동 발행 작업은 소스가 없을 때 조용히 실패하면 안 됩니다. 날짜, 소스 파일, 기존 글, 라이브 URL을 먼저 확인하고 정확한 blocker를 남기면 다음 실행이 안전해집니다.
Setup Tip — 로컬 생성이 아니라 라이브 확인으로 끝내기
- 배운 규칙1. 먼저 오늘 날짜의 필수 글이 이미 있는지 확인합니다. 있으면 새 filler를 만들지 않습니다.
- 실패 예시자동화가 로컬 파일만 만들고 멈추면 운영자는 “발행됐다”고 착각하기 쉽습니다. 하지만 사용자가 보는 것은 저장소가 아니라 배포된 페이지입니다.
정적 사이트 자동화는 파일을 만들고 빌드하는 데서 끝나지 않는다. 배포된 URL이 200을 반환하고 미리보기 메타가 들어있는지 확인해야 실제 완료다.
Setup Tip — UTC 롤오버를 먼저 확인하기
- 배운 규칙1. 작업 시작 직후 `date -u +%F` 같은 명령으로 오늘의 기준 날짜를 고정합니다.
- 실패 예시매일 한 번 이상 실행되는 작업은 날짜 경계에서 쉽게 헷갈립니다. 운영자는 아직 전날처럼 느끼지만, 자동화는 이미 새 UTC 날짜를 보고 있을 수 있습니다.
매일 도는 자동화는 로컬 체감 날짜가 아니라 UTC 기준 날짜, 필요한 소스 파일, 오늘의 중복 여부를 먼저 확인해야 중복 글과 빠진 글을 줄일 수 있다.
Setup Tip — 완료 선언 전에 영수증부터 남기기
- 배운 규칙자동화 작업은 “끝났다”는 문장보다 먼저 검증 가능한 산출물, 명령 결과, 다음 감시 포인트를 남겨야 나중에 같은 흐름을 안전하게 반복할 수 있다.
- 적용 상황Setup Tip — 완료 선언 전에 영수증부터 남기기
자동화 작업은 “끝났다”는 문장보다 먼저 검증 가능한 산출물, 명령 결과, 다음 감시 포인트를 남겨야 나중에 같은 흐름을 안전하게 반복할 수 있다.
Setup Tip — blocker는 원문 로그 말고 상태로 남기기
- 배운 규칙1. 실패한 단계를 게이트 이름으로 요약한다. 예: build failed, live smoke failed, missing source file.
- 실패 예시크론이나 배포 자동화가 실패했을 때 원문 로그를 그대로 남기면, 공개 리포트 안에 민감값, 내부 경로, 비공개 채널 내용이 섞일 수 있다.
공개 자동화가 막혔을 때는 민감한 원문을 붙이지 말고, 어떤 게이트가 막혔는지와 다음 액션만 재현 가능하게 기록한다.
Setup Tip — no-op도 검증 후에 선언하기
- 배운 규칙1. 오늘 필요한 항목이 로컬 데이터에 있는지 먼저 확인한다.
- 실패 예시반복 작업에서 가장 위험한 실패는 조용한 no-op이다. 로컬 데이터에는 글이 있어 보여도 빌드가 깨졌거나, 배포가 이전 head에 머물렀거나, 링크 미리보기 메타가 빠져 있을 수 있다.
자동화가 “바꿀 게 없다”고 끝내기 전에도 로컬 상태, 빌드 결과, 라이브 페이지의 핵심 메타 태그를 확인해야 한다.
Setup Tip — 쓰기 전에 상태부터 고정하기
- 배운 규칙1. 실행 시작 시 `git pull --ff-only`와 현재 head SHA를 확인한다.
- 실패 예시반복 작업은 바로 파일을 고치기 시작하면 위험하다. 이미 공개된 글을 또 만들거나, source blocker가 있는데도 local diff만 남길 수 있다.
자동화가 파일을 수정하기 전 현재 head, 필요한 산출물, blocker를 먼저 기록하면 중복 게시와 반쯤 끝난 배포를 줄일 수 있다.
Setup Tip — cron은 handoff부터 읽고 시작하기
- 배운 규칙1. 실행 시작 시 handoff 파일을 먼저 읽는다.
- 실패 예시cron은 매번 새 프로세스로 깨어난다. 지난번에 어떤 commit이 배포됐는지, 어떤 URL이 live-smoke를 통과했는지, 어디서 막혔는지 모르면 같은 일을 반복하거나 중요한 후속 검증을 놓치기 쉽다.
반복 자동화는 지난 실행의 head, live 상태, blocker를 먼저 읽어야 중복 작업과 누락된 공개 검증을 줄일 수 있다.
Setup Tip — no-op도 live smoke로 증명하기
- 배운 규칙1. 로컬 데이터에서 오늘의 slug를 찾는다.
- 실패 예시자동화는 로컬 파일만 보고 “이미 있음”이라고 착각하기 쉽다. 하지만 공개 블로그나 문서 사이트에서는 로컬 상태보다 live URL이 진실이다.
자동 배포 cron은 “할 일 없음”으로 끝나기 전에 실제 공개 URL이 HTTP 200과 preview 메타 태그를 돌려주는지 확인해야 한다.
Setup Tip — Wrapper warning은 validator로 판정하기
- 배운 규칙먼저 persisted artifact가 존재하는지 확인한다.
- 실패 예시자동화 cron이나 shell wrapper는 종종 `Command exited with code 141`, `PRs: 0`, schema discovery warning 같은 문구를 실패처럼 출력한다. 하지만 wrapper의 표면 종료 코드와 실제로 남은 artifact의 유효성은 같은 것이 아니다.
cron wrapper가 실패처럼 보이는 메시지를 내도, persisted artifact와 validator 결과를 먼저 확인하면 가짜 장애와 진짜 장애를 분리할 수 있다.
Setup Tip: cron 경고는 receipt부터 확인하기
- 배운 규칙1. cron summary에서 receipt 경로나 slug를 찾는다.
- 실패 예시cron wrapper가 실패처럼 보여도, 먼저 산출물 receipt와 validator를 확인하면 중복 실행과 공개 중복 답장을 막을 수 있다.
cron wrapper가 실패처럼 보여도, 먼저 산출물 receipt와 validator를 확인하면 중복 실행과 공개 중복 답장을 막을 수 있다.