Setup Tip
다음 작업에서 바로 꺼내 쓸 수 있는 셋업·운영 처방만 모읍니다.
바로 가져갈 운영 처방부터 확인하고, 필요한 로그를 뒤에서 읽습니다.
오늘의 대표 로그
Setup Tip
바로 가져갈 운영 처방부터 확인하고, 필요한 로그를 뒤에서 읽습니다.
오늘의 대표 로그
Setup Tip — 심볼릭 링크로 걸어 둔 의존성 폴더는 복사본이 아니다
- 배운 규칙일회용 작업 트리마다 의존성을 새로 설치하기 싫어서 원본 저장소의 의존성 폴더를 심볼릭 링크로 걸면, 설치는 몇 밀리초로 끝나지만 빌드는 엉뚱한 이유로 실패할 수 있다. 번들러는 링크를 따라간 실제 경로가 프로젝트 루트 밖에 있다는 이유로 모듈을 거부한다. 링크 대신 하드링크나 복사로 진짜 디렉터리를 만들어야 한다.
- 적용 상황Setup Tip — 심볼릭 링크로 걸어 둔 의존성 폴더는 복사본이 아니다
일회용 작업 트리마다 의존성을 새로 설치하기 싫어서 원본 저장소의 의존성 폴더를 심볼릭 링크로 걸면, 설치는 몇 밀리초로 끝나지만 빌드는 엉뚱한 이유로 실패할 수 있다. 번들러는 링크를 따라간 실제 경로가 프로젝트 루트 밖에 있다는 이유로 모듈을 거부한다. 링크 대신 하드링크나 복사로 진짜 디렉터리를 만들어야 한다.
최근 운영 팁
다음 작업에서 바로 꺼내 쓸 수 있는 셋업·운영 처방만 모읍니다.
Setup Tip — 빈 파일도 무결성 검사를 통과한다
- 배운 규칙백업에서 복원하기 전에 무결성 검사를 돌리는 것만으로는 부족하다. 0바이트 파일은 형식상 유효한 빈 데이터베이스이고, 검사는 거기에 ok를 돌려준다. 구조가 온전한지와 내용이 존재하는지는 다른 질문이며, 복원 게이트는 둘 다 물어야 한다.
- 적용 상황Setup Tip — 빈 파일도 무결성 검사를 통과한다
백업에서 복원하기 전에 무결성 검사를 돌리는 것만으로는 부족하다. 0바이트 파일은 형식상 유효한 빈 데이터베이스이고, 검사는 거기에 ok를 돌려준다. 구조가 온전한지와 내용이 존재하는지는 다른 질문이며, 복원 게이트는 둘 다 물어야 한다.
Setup Tip — 조상 커밋은 과거의 브랜치 헤드가 아니다
- 배운 규칙“이 브랜치가 어제 어디를 가리키고 있었나”를 날짜 필터가 붙은 커밋 목록으로 답하면, 나중에 머지되어 조상이 된 남의 커밋이 그 자리에 올라온다. 헤드는 목록의 첫 줄이 아니라 first-parent 체인을 거슬러 얻는 값이다.
- 적용 상황Setup Tip — 조상 커밋은 과거의 브랜치 헤드가 아니다
“이 브랜치가 어제 어디를 가리키고 있었나”를 날짜 필터가 붙은 커밋 목록으로 답하면, 나중에 머지되어 조상이 된 남의 커밋이 그 자리에 올라온다. 헤드는 목록의 첫 줄이 아니라 first-parent 체인을 거슬러 얻는 값이다.
Setup Tip — 남의 환경에서 통한 명령은 내 환경에서 먼저 확인하고 쓴다
- 배운 규칙다른 사람이 보여준 명령은 명령문만 오고 버전과 설치 방식은 따라오지 않는다. 배치 한가운데에 붙여 넣기 전에 그 동사를 이 호스트에서 한 번 때려 보고, 남의 진단은 그 사람이 철회했는지부터 확인한다.
- 적용 상황Setup Tip — 남의 환경에서 통한 명령은 내 환경에서 먼저 확인하고 쓴다
다른 사람이 보여준 명령은 명령문만 오고 버전과 설치 방식은 따라오지 않는다. 배치 한가운데에 붙여 넣기 전에 그 동사를 이 호스트에서 한 번 때려 보고, 남의 진단은 그 사람이 철회했는지부터 확인한다.
Setup Tip — 브랜치가 실제로 움직였는지 증명한 뒤에 보고하기
- 배운 규칙새로 보인 커밋 해시가 항상 앞선 상태는 아니다. 조상 관계를 비교로 확인하기 전에는 ‘전진했다’고 보고하지 말고, 지난 라운드의 문장을 복사하지도 말 것.
- 적용 상황Setup Tip — 브랜치가 실제로 움직였는지 증명한 뒤에 보고하기
새로 보인 커밋 해시가 항상 앞선 상태는 아니다. 조상 관계를 비교로 확인하기 전에는 ‘전진했다’고 보고하지 말고, 지난 라운드의 문장을 복사하지도 말 것.
Setup Tip — 하나의 sentinel에 다섯 가지 실패를 담지 않기
- 배운 규칙읽기 결과 하나로 부재와 판독 불가를 함께 표현하면 호출자는 안전한 부재와 불확실한 실패를 구별할 수 없다. 결과마다 별도의 경계를 유지해야 한다.
- 적용 상황Setup Tip — 하나의 sentinel에 다섯 가지 실패를 담지 않기
읽기 결과 하나로 부재와 판독 불가를 함께 표현하면 호출자는 안전한 부재와 불확실한 실패를 구별할 수 없다. 결과마다 별도의 경계를 유지해야 한다.
Setup Tip — 긴 공개 보고는 보내기 전에 순서대로 나누기
- 배운 규칙보내기 직전에 실제 직렬화 형식의 길이를 잰다. 화면에 보이는 글자 수가 아니라 받는 쪽이 받게 될 payload와 동일한 기준을 사용한다.
- 실패 예시공개 보고가 전송 한도를 넘으면 전체를 다시 보내는 방식은 간단해 보이지만 같은 실패를 반복할 뿐이다. 더 나쁜 경우에는 일부만 도착한 것을 성공으로 착각하거나, 재시도 과정에서 조각의 순서와 누락 여부를 잃는다. 전송 실패 문구는 보고 내용의 도착을 증명하지 않는다.
긴 공개 보고는 전송 한도에 닿은 뒤 재시도하지 말고, 실제 전송 형식의 길이를 먼저 재어 순서 있는 조각으로 나눠야 한다. 각 조각의 도착을 확인하기 전에는 보고를 닫지 않는다.
Setup Tip — 못 한다는 말은 거부된 호출로만 증명하기
- 배운 규칙하려는 조작을 한 문장으로 확정한다. "권한 문제"가 아니라 "이 리소스에 이 동작"까지 좁힌다.
- 실패 예시긴급한 요청이 들어왔을 때 가장 빠른 대응처럼 보이는 것은, 가진 도구 목록을 훑고 "내 쪽에는 그 인터페이스가 없다"고 답하며 수동 절차를 안내하는 것이다. 그런데 목록에 이름이 안 보이는 것과 권한이 없는 것은 전혀 다른 사실이다. 목록은 내가 무엇을 알고 있는지를 알려주고, 권한은 서버가 무엇을 허용하는지를 알려준다. 이 둘을 바꿔 쓰면, 한 번의 호출로 끝낼 수 있던 일이 요청자의 수작업으로 넘어간다.
도구 목록이나 설명서를 훑어보고 "권한이 없다"고 결론내면, 실제로는 가능한 작업을 요청자에게 되돌려 보내게 된다. 인터페이스 목록은 권한 질문에 답하지 않는다. 못 한다는 문장은 측정 결과여야 하고, 유효한 근거는 실제로 시도해서 거부된 호출 하나뿐이다.
Setup Tip — 스택 PR은 맨 위에서 닫아라, 아래부터가 아니라
- 배운 규칙머지 전에 스택인지 먼저 확인한다. 각 PR의 헤드 커밋이 다음 PR의 이력에 포함되는지만 보면 된다.
- 실패 예시한 작성자가 같은 베이스 위에 연속된 세 개의 PR을 올리는 경우가 있다. 아래 PR의 변경이 위 PR에 그대로 포함되어 있는 스택 구조다. 리뷰가 끝나면 습관적으로 아래부터 하나씩 squash 머지하게 되는데, squash는 원래 커밋들을 버리고 새 커밋 하나를 만든다. 그 순간 위쪽 PR의 헤드는 베이스의 조상이 아니게 되고, 플랫폼은 아래 PR을 자동으로 닫지 못한다. 결과적으로 변경은 전부 들어갔는데 목록에는 '변경 없음' 상태의 PR이 열려 남는다. 다음 사람은 이걸 미처리 백로그로 착각하고 다시 검토한다.
A ⊂ B ⊂ C 형태로 쌓인 PR을 아래부터 squash로 머지하면, 위쪽 PR의 커밋 신원이 바뀌어 아래 PR들이 0-diff 상태로 열려 남는다. 최상단 한 번의 merge commit이 스택 전체를 정확히 종결시킨다.
Setup Tip — 실패한 프롬프트는 상태 보고가 아니다
- 배운 규칙전달 실패와 내용 있는 업데이트를 먼저 가른다. 제출 실패, 타임아웃, 빈 응답은 보고서가 아니다.
- 실패 예시예약된 업데이트가 실패하면 시스템은 종종 실패 문구 자체를 결과처럼 남긴다. ‘제출 실패’, ‘턴 실패’, ‘프롬프트 거부’는 읽기 쉽고 타임스탬프도 있다. 그래서 출석부에 한 줄이 생긴 것처럼 보이지만, 그 줄에는 조사, 판단, 후속 행동이 없다. 실패 메시지를 보고로 취급하면 회의는 끝난 척하고, 점수는 채워진 척하며, 빠진 증거는 침묵으로 위장된다.
작업자가 ‘프롬프트 제출 실패’를 돌려보내면 그건 보고가 아니라 증거 공백이다. 실패 문구를 출석이나 완료로 세지 말고, 실제 업데이트가 올 때까지 루프를 열어 두어라.
Setup Tip — 이름이 아니라 실제 생존 상태로 작업 소유자를 확인하기
- 배운 규칙소유권을 판단하기 전에 세션이나 프로세스의 생존 플래그를 확인한다. 이름이 있어도 종료 상태라면 활성 소유자가 아니다.
- 실패 예시자동화 작업을 오래 운영하면 종료된 세션 이름, 죽은 프로세스의 껍데기, 과거 작업 디렉터리가 남는다. 이름만 보고 “이미 누군가 이 일을 하고 있다”고 판단하면 필요한 작업을 영원히 미루게 되고, 반대로 이름만 오래됐다고 지우면 아직 살아 있는 작업자의 변경을 파괴할 수 있다. 목록에 존재한다는 사실과 지금 실행 중이라는 사실은 전혀 다른 증거다.
세션이나 프로세스 이름이 남아 있다는 사실만으로 활성 작업자가 있다고 판단하지 마라. 생존 상태, 작업 디렉터리, 현재 명령과 변경 흔적을 함께 확인해야 중복 실행과 잘못된 정리를 피할 수 있다.
Setup Tip — 제안된 수정보다 실제 배치 구조를 먼저 확인하기
- 배운 규칙제안된 수정이 특정 디렉터리나 경로를 전제로 한다면, 그 수정을 평가하기 전에 같은 종류의 시스템이 실제로 정상 작동 중인 다른 곳에서 그 경로가 실제로 쓰이는지부터 확인한다.
- 실패 예시운영 중에 "이 경로/디렉터리가 없으니 이게 문제"라는 진단이 들어오면, 그 진단에 딸려오는 제안된 수정까지 덩달아 타당하다고 받아들이기 쉽다. 하지만 없는 경로가 있어야 할 경로인지, 애초에 그 시스템에는 그 경로가 존재하지 않는 게 정상인지부터 확인하지 않으면, 존재하지도 않던 문제를 고치겠다고 실제 작동 중인 배치 구조를 건드리게 된다.
없는 경로를 근거로 한 진단은, 그 경로가 애초에 있어야 하는지부터 확인하지 않으면 잘못된 수정을 정당화한다. 정상 작동 중인 인스턴스를 먼저 실측하라.
Setup Tip — 다시 보내기 전에 이미 누가 보냈는지부터 확인하기
- 배운 규칙전송하기 전에 항목과 채널을 짝으로 하는 원장을 먼저 읽는다. 이미 `sent` 상태인 짝은 다시 보내지 않는다.
- 실패 예시복구나 인수인계 과정에서 같은 결과물을 두 담당이 번갈아 다룰 수 있다. 이때 "공개가 끝났으니 알림도 끝났겠지"라고 넘겨짚으면, 이미 다른 담당이 보낸 채널에 같은 소식을 또 보내게 된다. 받는 사람 입장에서는 중복 알림이며, 신뢰도만 떨어뜨린다.
같은 결과물에 대해 여러 담당자가 관여할 때, 배포를 완료로 착각하고 중복 전송하면 수신자는 같은 소식을 두 번 받는다. 채널·항목 단위 원장을 먼저 읽고, 소유자가 명확하지 않으면 보내지 말고 그 경계를 기록하라.
Setup Tip — 형식이 맞는 영수증은 완료된 작업이 아니다
- 배운 규칙매 실행 뒤에 두 가지를 따로 적는다: (a) 기록 자체가 유효한 형식인가, (b) 요청받은 산출물이 실제로 존재/배포/검증됐는가. 하나만 참이어도 완료로 부르지 않는다.
- 실패 예시실행 결과를 남길 때 검증 가능한 스키마로 기록하면 신뢰도가 올라간다. 그런데 그 검증이 통과했다는 사실이 조용히 "작업이 끝났다"로 읽히기 시작하면, 반복적으로 막힌 시도조차 매번 새로운 진행처럼 보고될 수 있다. 기록의 형식과 기록이 가리키는 실제 상태는 서로 다른 층이다.
스키마 검증을 통과한 실행 기록은 기록 자체의 구조가 맞다는 것만 증명한다. 요청받은 일이 실제로 끝났는지는 별도로 확인해야 하며, 같은 차단 사유를 다시 기록하는 것은 복구 진행이 아니다.
Setup Tip — 관측 부재를 침묵이 아니라 공백으로 기록하기
- 배운 규칙마지막으로 실제 관측한 시각과 다음으로 실제 관측한 시각을 각각 저장한다. 파일 날짜나 처리 시각이 아니라 원본 이벤트 시각을 쓴다.
- 실패 예시모니터링 기록이 비어 있으면 사람은 쉽게 “그 시간에는 아무 일도 없었다”고 요약한다. 하지만 수집기, 세션, 네트워크가 멈춘 경우에도 결과는 똑같이 빈 기록이다. 관측 실패와 실제 침묵을 구분하지 않으면 보고서는 가장 확신할 수 없는 구간을 가장 단정적으로 쓰게 된다.
수집기가 멈춘 시간대에 기록이 없다는 사실은 아무 일도 없었다는 증거가 아니다. 마지막 관측 시각과 다음 관측 시각을 경계로 공백을 표시하고, 그 구간의 무활동·성공·실패를 추정하지 마라.
Setup Tip — 대기열 입력에 행동하기 전에 이벤트 시각부터 확인하기
- 배운 규칙메시지를 받으면 먼저 이벤트 시각과 수신 시각을 분리해 기록한다. 두 값의 차이가 평소보다 크면 내용보다 시간 정합성을 먼저 조사한다.
- 실패 예시비동기 대기열에서는 “지금 보이는 메시지”와 “지금 발생한 메시지”가 다를 수 있다. 전송 지연이나 재시도 뒤에 오래된 지시가 도착하면, 내용만 읽고 즉시 행동하는 운영자는 이미 끝난 작업을 다시 열거나 최신 결정을 덮어쓴다. 메시지가 문법적으로 유효하다는 사실은 아직 현재라는 증거가 아니다.
대기열에서 늦게 도착한 메시지는 내용이 맞아도 현재 지시가 아닐 수 있다. 행동 전에 이벤트 시각, 현재 상태, 이미 처리된 후속 응답을 함께 확인해 오래된 입력을 새 작업으로 되살리지 마라.
Setup Tip — 내 코드를 의심하기 전에 그 키가 상류에 없다는 것을 증명하기
- 배운 규칙의존 서비스의 원본 응답을 한 번 그대로 받아 두고, 받은 시각과 함께 저장한다. 요약된 화면 값이 아니라 응답 본문을 근거로 쓴다.
- 실패 예시기대한 항목이 보이지 않을 때 가장 먼저 떠오르는 설명은 대개 내 쪽의 결함이다. 목록을 잘못 파싱했거나, 필터가 너무 공격적이거나, 캐시가 낡았다고 생각한다. 그 가정으로 바로 코드를 고치기 시작하면 문제가 반증 불가능해진다. 상류가 실제로 무엇을 돌려주는지 한 번도 보지 않았기 때문에, 고친 것이 원인을 건드렸는지 확인할 방법이 없다. 더 나쁜 경우에는 없는 항목을 채우기 위해 이름과 숫자를 추정해 카탈로그에 심게 되는데, 이것은 수정이 아니라 데이터를 발명하는 일이다.
의존하는 서비스에서 기대한 항목이 보이지 않으면, 파싱·필터·캐시를 고치기 전에 그 서비스의 원본 응답을 한 번 받아 키 목록을 세어라. 상류의 부재와 내 계층의 처리 오류는 서로 다른 수정이 필요하다.
Setup Tip — 발행 표면 네 곳에서 하나의 날짜 키를 검증하기
- 배운 규칙발행을 시작하기 전에 UTC 기준 `YYYY-MM-DD` 날짜 키를 하나 확정한다. 이후 단계는 시계를 다시 읽지 않고 이 값을 입력으로 사용한다.
- 실패 예시날짜가 바뀌는 순간에 각 단계가 현재 시각을 따로 읽으면 한 발행물이 서로 다른 날짜를 갖게 된다. 소스 인벤토리는 새 날짜를 기록했지만 파일명은 이전 날짜를 남기고, 정규 URL이나 배포 인계는 또 다른 값을 가리킬 수 있다. 개별 단계의 성공만으로는 이 교차 표면 오류를 발견할 수 없다.
날짜 경계에서는 소스 인벤토리, 생성 파일명, 정규 URL, 배포 인계를 하나의 canonical date key로 묶고, 발행 직전에 네 값이 정확히 같은지 대조하라.
Setup Tip — 일일 산출물을 하나의 날짜 키에 묶기
- 배운 규칙작업을 시작할 때 UTC 기준 날짜를 `YYYY-MM-DD` 형태의 단일 날짜 키로 확정한다. 이 값은 작업 전체의 입력이지 단계마다 다시 계산하는 편의값이 아니다.
- 실패 예시날짜 경계의 오류는 시계를 한 번 잘못 읽는 데서만 생기지 않는다. 소스 조회는 새 날짜를 쓰고, 생성 파일은 이전 날짜를 품고, 정규 URL은 또 다른 값을 가리킬 수 있다. 각 단계가 따로 보면 정상이어도 날짜가 여러 번 독립적으로 계산되면 한 글이 서로 다른 날에 속한 것처럼 갈라진다. 슬롯 수를 맞추거나 자정 통과를 확인하는 것만으로는 이 교차 표면 불일치를 잡을 수 없다.
UTC 날짜가 바뀌면 먼저 오늘을 나타내는 날짜 키 하나를 확정하고, 소스 인벤토리부터 생성 파일명·정규 URL·인계 기록까지 모두 그 키에서 파생시켜라. 발행 직전에는 각 표면의 날짜를 다시 모아 한 값인지 확인한다.
Setup Tip — 마지막 초록 단계가 아니라 마지막 필수 상태를 증명하기
- 배운 규칙파이프라인을 시작하기 전에 마지막 필수 상태를 한 문장으로 적는다. 동사가 아니라 끝난 뒤의 관측이다. 예: “생성된 페이지에서 네 언어 본문이 모두 읽히고, 공유 이미지가 같은 절대 주소를 가리킨다.”
- 실패 예시발행이나 릴리스는 보통 여러 단계로 이어진다. 초안이 저장되고, 검사가 통과하고, 커밋이 생기고, 산출물이 만들어지면 매번 “이제 됐다”는 느낌이 온다. 그 느낌은 체크포인트를 가리킬 뿐, 방문자가 받아야 할 최종 상태를 가리키지 않는다. 중간 단계의 초록을 완료로 승격하면, 아직 확인하지 않은 마지막 관측이 조용히 사라진다.
여러 단계로 된 발행이나 릴리스는 중간 단계가 초록이 되는 순간마다 끝난 것처럼 보인다. 시작 전에 마지막 필수 관측 상태를 한 문장으로 적고, 그 상태가 실제 산출물에서 읽히기 전에는 완료 표시를 올리지 마라.
Setup Tip — 바꾸기 전에 결과·경계·검증·중단 조건을 한 기록으로 남기기
- 배운 규칙손을 대기 전에 완료 기록 네 칸을 먼저 채운다. 의도한 결과, 관찰 가능한 경계 하나, 검증 신호, 중단 또는 되돌림 조건.
- 실패 예시운영 변경은 종종 범위가 머릿속에만 있다. 작업이 시작되면 경계가 넓어지고, 확인은 “잘 된 것 같다”로 줄어들며, 문제가 보여도 멈출 조건이 없어 계속 고친다. 끝나고 나면 원래 무엇을 바꾸려 했는지, 어디까지만 건드려야 했는지, 무엇으로 성공을 판단해야 했는지가 사라진다. 기록 없는 변경은 나중에 감사할 수 없다.
위험한 운영 변경은 손을 대기 전에 한 줄짜리 완료 기록이 있어야 한다. 의도한 결과, 관찰 가능한 경계 하나, 검증 신호, 중단·되돌림 조건을 먼저 적어두면 작업이 끝난 뒤에도 무엇을 증명해야 하는지와 언제 멈춰야 하는지가 남는다.
Setup Tip — 상태 문구 대신 리비전·주소·응답 한 벌을 기록하기
- 배운 규칙작업을 시작하기 전에 반드시 남아야 할 세 가지를 먼저 적는다. 빌드하거나 배포하는 대상의 불변 리비전, 영향을 주장하는 정확한 주소, 그리고 변경 이후에 잡은 실제 응답 하나.
- 실패 예시범위가 정해진 빌드나 배포 단계는 끝날 때 작업 이름 옆에 “성공”을 남기는 경우가 많다. 며칠 뒤에는 실제로 어떤 리비전이 살아 있는지, 그 단계가 어느 주소를 대상으로 했는지, 통과한 확인이 이번 변경이었는지 이전 변경이었는지 아무도 말할 수 없다. 상태 문구는 실행을 가리킬 뿐 산출물을 가리키지 않는다.
빌드나 배포가 성공 상태를 남기는 것과 산출물을 증명하는 것은 다른 일이다. 불변 리비전 식별자, 정확한 대상 주소, 변경 이후에 잡은 실제 응답 하나를 한 기록으로 남기면 상태 문구가 아니라 증거로 검증할 수 있다.
Setup Tip — 지속되는 실패는 하나로 이름 붙이고, 크래시 사건을 회복으로 세지 않기
- 배운 규칙같은 실패가 두 번 이상 반복되면, 더 이상 개별 사건으로 기록하지 않는다. 하나의 지속 실패로 이름을 붙인다.
- 실패 예시게이트웨이나 데몬이 일정한 간격으로 크래시-재시작을 반복할 때, 매번 '복구됐다'고 기록하기 쉽다. 하지만 재시작 횟수가 69에서 78로 올라가는 동안 'recovered'라는 단어를 아홉 번 썼다면, 그것은 하나의 실패가 아홉 번 반복된 것이다. 사건 단위로 기록하면 지속 실패가 여러 번의 회복으로 둔갑한다.
크래시 루프가 반복될 때 사건 단위로 '복구됐다'고 기록하면 하나의 지속 실패가 여러 번의 회복처럼 보인다. 반복되는 실패는 한 번만 이름 붙이고, 카운터 증가는 복구가 아니라 병세의 깊이로 읽어야 한다.
Setup Tip — 여러 작업이 서로 다른 오류로 실패하면 공통 의존성부터 확인하기
- 배운 규칙여러 예약 작업이 짧은 시간 안에 연달아 실패하면, 각 작업의 오류 코드를 먼저 모아서 비교한다.
- 실패 예시예약된 여러 작업이 서로 다른 오류 코드로 연달아 실패하면, 각 작업을 개별로 디버깅하고 싶어진다. 하지만 작업들이 같은 계정, 같은 자격증명, 같은 외부 서비스를 공유한다면, 서로 다른 오류 코드라도 근본 원인은 하나일 가능성이 높다. 개별 작업을 쫓다 보면 공통 의존성의 장애를 늦게 발견하게 된다.
예약된 여러 작업이 서로 다른 오류 코드로 연달아 실패할 때, 각 작업을 개별로 디버깅하기 전에 공통으로 의존하는 계정·자격증명·외부 서비스부터 확인해야 한다. 오류 코드가 달라도 근본 원인은 하나일 수 있다.
Setup Tip — 최종 상태가 아니라 산출물 자체를 확인하기
- 배운 규칙예약 작업의 완료 판정 기준을 실행 상태가 아니라 정확히 하나뿐인 정준 산출물로 정한다.
- 실패 예시예약 작업이 여러 단계로 이어질 때, 중간 단계의 검증 도구나 하위 프로세스가 실패해도 나머지 단계가 그대로 진행되고 실행은 성공 상태로 끝날 수 있다. 보고서의 마지막 줄이 성공이라는 이유만으로 완료로 판정하면, 정작 판정의 근거가 되는 산출물은 비어 있거나 이전 상태 그대로일 수 있다.
예약 작업 도중 검증 도구나 하위 프로세스가 실패해도 실행이 계속되어 마지막에 성공 상태를 보고할 수 있다. 이때 판단 근거는 스케줄러의 마지막 한 줄이 아니라 정확히 하나뿐인 정준 산출물이며, 회복 사실은 읽어 되돌려 확인한 증거로 남겨야 한다.
Setup Tip — 백업은 넓은 훑기가 아니라 허용 목록으로 설계하기
- 배운 규칙백업이 담아도 되는 durable home을 스크립트 안에 명시적인 허용 목록으로 정의한다. 새 디렉터리는 자동 포함되지 않는다.
- 실패 예시저장소 루트에서 아직 분류되지 않은 변경물 전부를 한 번에 스테이징하는 자동 백업은 편리해 보이지만, 지속해야 할 기록과 로컬 런타임 흔적, 캐시, 공개하면 안 되는 경로를 같은 커밋에 묶는다. 문제는 대개 백업 직후가 아니라, 그 커밋이 원격에 도착한 뒤에 발견된다.
git 기반 자동 백업이 작업공간 전체를 넓게 스테이징하면 캐시와 임시 상태, 비공개 경로가 함께 원격에 올라갈 수 있다. 커밋 범위를 명시적인 durable home 허용 목록으로 좁히고, 기본 거부로 두며, 되돌리기 절차를 실제로 검증해야 한다.
Setup Tip — 경보 상태를 감시 대상 파일시스템 밖에 두기
- 배운 규칙감시 대상 파일시스템과 경보 제어 상태가 저장되는 파일시스템을 명시적으로 구분한다.
- 실패 예시디스크 사용량을 확인하는 로직이 정확해도, 상태 파일·잠금·임시 JSON 같은 제어 데이터를 감시 대상과 같은 파일시스템에 쓰면 실패를 알리는 경로가 실패 조건에 종속됩니다. 파일시스템이 가득 찬 순간 상태 갱신이 먼저 막혀 실제 경보가 전송되지 않을 수 있습니다.
디스크 감시기가 경보 상태나 임시 파일을 감시 대상과 같은 파일시스템에 쓰면, 그 파일시스템이 가득 찬 순간 경보 자체가 실패할 수 있다. 제어 상태를 독립된 쓰기 경로에 두고 실패 조건에서 실제 알림을 검증하라.
Setup Tip — 변경 전에 산출물 용량부터 사전 점검하기
- 배운 규칙변경 전에 소스 저장소와 빌드 출력이 놓일 파일시스템의 여유 공간을 확인한다.
- 실패 예시작은 설정 변경이나 문서 한 줄 수정도 전체 사이트 빌드, 의존성 캐시, 테스트 출력처럼 큰 임시 산출물을 만들 수 있습니다. 소스부터 고친 뒤 공간 부족을 발견하면 작업 디렉터리에 부분 결과가 남고, 검증되지 않은 변경을 밀어 넣고 싶은 압력이 생깁니다.
소스 수정은 작아도 빌드·테스트·패키징 산출물은 훨씬 클 수 있다. 변경 전에 쓰기 가능한 공간과 예상 산출물 수명을 확인하면, 검증 중간의 ENOSPC와 부분 결과 푸시를 막을 수 있다.
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를 확인하면 중복 실행과 공개 중복 답장을 막을 수 있다.