Cloudflare Workers 로그 확인: 빈 화면이라면 요청부터 확인해요
Cloudflare Workers 로그 확인 화면이 비어 있어도 요청 성공을 뜻하지는 않아요. 실시간 로그는 이벤트를 저장하지 않고, 트래픽이 많으면 샘플링으로 메시지가 누락될 수 있어요. 정상 배포로 판단하기 전에 의도적으로 보낸 요청의 시각·경로·관찰 화면·응답을 연결하세요.
실시간 로그: 관찰 중인 이벤트를 보는 용도이며, 저장된 이력은 아니에요.
저장 로그: 프로젝트 설정과 검색 조건을 기록하고 Workers Logs에서 별도로 확인하세요.
판단: 대응 기록을 찾지 못한 요청은 오류가 안 보여도 미검증 상태예요.
운영 장애 보고가 아닌 문서 기반 현장 매뉴얼이에요. 검토일: 2026-09-09 at 09:20:58 +09:00. 배포 테스트는 하지 않았어요. 조건: 문서상 실시간·저장 로그의 차이와 독자의 실제 런타임·프로젝트 설정을 전제로 해요.
조용한 화면에는 답하지 못한 질문이 남아요
아무것도 안 떴으니 문제가 없었다고 생각하기 쉬워요.
하지만 핵심 질문이 빠져 있어요. 이 관찰과 확인하려는 요청을 연결하는 근거는 무엇인가요?
공식 실시간 로그 문서에 따르면 스트림은 호출 이벤트·사용자 정의 로그·오류를 보여주지만 저장하지 않아요. 트래픽이 많으면 샘플링으로 메시지가 누락되고 경고가 표시될 수 있어요.
따라서 빈 화면은 해당 관찰 조건에서 일치하는 이벤트를 보지 못했다는 뜻이에요. 의도한 배포에 요청이 도달했는지, 기대한 작업을 마쳤는지는 별도 근거가 필요해요.
반대로 로그 누락만으로 앱 고장을 입증할 수도 없어요.
빈 화면은 관찰이고, 정상 요청이라는 결론에는 근거가 필요해요.
실시간 관찰과 저장 이력은 다른 질문에 답해요
Workers Logs는 실시간 스트림과 구별되는 저장 로그 화면이에요. 혼용하면 배포 확인을 재현하기 어려워져요.
실시간 화면은 요청 중 무엇이 보이는지, 저장 화면은 나중에 어떤 기록을 검색할 수 있는지에 답해요. 모두 선택한 배포·설정·관찰 범위를 확인해야 해요.
확인 기록에는 화면을 명시하세요. “로그 확인”보다 “요청 중 실시간 스트림 관찰”, “기록한 구간을 Workers Logs에서 검색”이 수행한 작업을 정확히 나타내요.
빈 화면을 해석하기 전에 판단 표를 사용하세요.
| 관찰 | 근거가 뒷받침하는 결론 | 다음 확인 |
|---|---|---|
| 실시간 화면이 비어 있음 | 해당 화면에서 일치 이벤트를 관찰하지 못함 | 관찰 시점·선택 배포·활성 필터 |
| 실시간 샘플링 경고 표시 | 스트림에서 메시지가 누락될 수 있음 | 경고를 기록하고 완전성을 주장하지 않기 |
| 실시간 호출 이벤트 표시 | 호출 이벤트를 관찰함 | 의도한 요청과 연결하고 결과 확인 |
| 저장 검색 결과 없음 | 해당 검색에서 일치 기록을 찾지 못함 | 프로젝트 로그 설정·구간·필터 |
| 일치 기록에 오류 있음 | 대응 이벤트에 오류가 기록됨 | 요청 결과·기대 동작과 비교 |
비교 설명: 실시간·저장 관찰이 뒷받침하는 결론은 달라요. 테스트한 배포의 화면이 아닌 문서 기반 판단 보조 표예요.
요청 전에 추적할 수 있게 준비하세요
기대 결과를 설명할 수 있는 무해한 동작으로 시작하세요. 앱이 허용하면 읽기 전용 확인을 택하세요. 예상 밖 결과를 성공으로 받아들이지 않도록 요청 전에 기대 동작을 적으세요.
대상 배포는 민감하지 않은 별칭으로 기록하고, 관련 런타임·설정도 적으세요. 실제 프로젝트와 최신 공식 문서에 맞는지는 독자가 확인해야 해요.
관찰 화면을 준비하세요. 실시간 확인은 요청 전에 스트림을 열고 관찰 시작 시각을, 저장 확인은 검색 구간과 필터를 기록하세요.
요청을 보내고 시간대가 포함된 시각, 민감정보를 제거한 경로, 화면에 보이는 응답을 적어 기대 결과와 비교하세요.
대응 이벤트나 기록을 찾아 연결 근거를 설명하세요. 불확실하면 인접 이벤트를 추정으로 연결하지 말고 “일치 확인 못함”으로 적으세요.
권장 재현 절차이며, 특정 배포가 통과했다는 증거는 아니에요.
확인 기록에 개인정보를 남기지 마세요
요청 추적 기록은 개인의 입력 없이 확인 과정을 설명해야 해요.
출생 정보를 받는 앱에서는 생년월일·출생 시각·이름·전체 입력 페이로드를 로그에 남기지 마세요. 해당 값이 쿼리 문자열에 있으면 전체 URL을 복사하지 마세요. 경로에도 개인정보가 들어갈 수 있으니 제거해야 해요.
폼 제출이 필요하면 가상 입력을 쓰되 추적 기록에는 남기지 마세요. 제출값 대신 확인한 동작을 적으세요.
오류와 스크린샷도 같아요. 진단 출력을 공유 기록에 넣기 전에 검토하고, 자격 증명·세션 데이터·원본 요청 본문은 제외하세요.
유용한 요청 확인 기록은 개인정보 없이 동작과 근거를 남겨요.
이 추적 기록을 배포 체크리스트에 복사하세요
의도적으로 보낸 요청을 확인하는 빈 양식이에요. 대괄호는 측정값이 아닌 입력 자리예요.
| 항목 | 입력 |
|---|---|
| 확인 날짜와 시간대 | [날짜; 시간대] |
| 대상 | [민감하지 않은 배포 별칭] |
| 런타임과 관련 설정 | [검증한 프로젝트 조건] |
| 기대 동작 | [요청 전에 정의한 관찰 가능한 결과] |
| 요청 시각 | [시간대 포함 시각] |
| 요청 메서드와 정제한 경로 | [메서드; 개인정보 없는 경로] |
| 관찰 화면 | [실시간 로그 / Workers Logs] |
| 관찰 시점 | [실시간 시작 시각 / 저장 검색 구간] |
| 필터 | [실제 사용한 필터] |
| 샘플링 근거 | [경고 관찰 / 경고 못 봄 / 알 수 없음] |
| 보이는 응답 | [상태와 민감하지 않은 동작] |
| 일치 로그 근거 | [민감정보를 제거한 이벤트 요약 / 일치 확인 못함] |
| 판단과 다음 행동 | [근거 있는 결론; 미해결 확인 사항] |
양식 설명: 기대 동작·관찰 조건·결과를 연결하는 빈 요청 추적 기록이에요. 출생 정보와 원본 페이로드는 의도적으로 제외해요.
“경고 못 봄”은 그대로 관찰로 남기세요. “샘플링 비활성화”로 바꾸면 안 돼요. 호출 일치도 “앱 전체 정상”을 뜻하지 않아요.
판단 범위를 근거 안에 두세요
문서상 샘플링은 관찰의 한계이며, 이번 작업에서 겪은 실패가 아니에요. 장애·설치·성능 결과를 측정하지 않았어요.
가상의 폼 확인에서 응답과 일치 호출은 해당 요청에 관한 제한적 판단을 뒷받침할 수 있어요. 모든 계산의 정확성이나 이후 요청의 동일한 동작까지 입증하지는 못해요. 응답은 보이지만 이벤트를 연결하지 못했다면 두 사실을 그대로 남기세요.
선택적으로 참고할 앱 맥락은 단일 프로젝트용 자체 소스 상품인 한국어 사주 소스 라이선스예요. 상품 페이지에서 현재 제공물과 설치 요건을 안내해요. 이 설명이 고객의 설치 성공이나 모든 런타임과의 호환성을 입증하지는 않아요.
요청과 관찰을 연결하지 못했다면 정직한 판단은 “미검증”이에요.
최종 판단은 보이는 요청 결과와 범위를 명시한 로그 근거를 짝짓는 거예요. 로그가 없다는 사실만으로 정상을 주장할 수는 없어요.
요청 추적 기록을 복사하고, 자신의 배포에서 무해한 요청으로 채워보세요.
관련 빌드 로그
Workers 로그가 비어 있다면 요청 시각·경로·관찰 화면·샘플링 근거·결과를 함께 확인할 때까지 요청은 미검증 상태예요.