전체 글138 GitHub Actions 403 해결: GITHUB_TOKEN 권한·포크 PR·OIDC 점검 그림: GitHub Actions 403은 실행 이벤트, 토큰 권한, 외부 클라우드 역할을 차례로 분리해 점검합니다.GitHub Actions에서 Resource not accessible by integration 또는 HTTP 403이 나오면 토큰 문자열을 새로 만드는 것부터 시작하기 쉽습니다. 그러나 대부분은 어떤 이벤트로 실행됐는지, 어떤 권한이 부여됐는지, 어느 API가 거부했는지를 구분해야 해결됩니다. 특히 포크 PR과 OIDC 배포는 일반 push와 권한 조건이 다릅니다.1. 먼저 실패한 API와 실행 이벤트를 찾는다로그에서 실패한 단계와 요청 대상이 GitHub API인지, 패키지 레지스트리인지, AWS 같은 외부 서비스인지 확인하세요. 이어 워크플로의 on: 이벤트, 저장소·조직의 Act.. 2026. 9. 26. Let’s Encrypt 인증서 갱신 실패 해결: Certbot·DNS·포트 80·Nginx 점검 그림: 인증서 만료 확인부터 도메인 검증, 시험 갱신, 웹 서버 재적용까지의 점검 순서입니다.Let’s Encrypt 인증서 갱신에 실패했다면 곧바로 재설치를 반복하지 마세요. 실패 원인은 만료 시각, 도메인 검증 방식, DNS·포트 80 접근, Certbot 설정, Nginx 재적용 중 어디에 있는지 순서대로 확인해야 합니다. 이 글은 운영 서버에서 장애 범위를 좁히는 절차를 다룹니다.1. 만료와 실제 제공 인증서를 구분한다서버에 저장된 인증서 만료일과 사용자에게 보이는 인증서 만료일이 다를 수 있습니다. sudo certbot certificates로 Certbot 관리 인증서를 확인하고, 브라우저 또는 openssl s_client -connect example.com:443 -servername .. 2026. 9. 26. 기업용 CDN 선택: AWS CloudFront와 Cloudflare 캐시·원본·비용 비교 그림: CDN 선택은 공급사 이름보다 원본·캐시 키·비용 구조를 함께 검토하는 과정입니다.사이트가 느려 CDN을 도입하거나 바꾸려면 “어느 서비스가 빠른가”보다 무엇을 캐시하고, 원본에 무엇을 전달하며, 비용을 어떻게 예측할지를 먼저 정해야 합니다. AWS CloudFront와 Cloudflare를 운영 관점에서 비교하고 작은 실험으로 선택하는 방법을 정리합니다.1. CDN을 도입하기 전 문제를 측정한다이미지·CSS·JS 같은 정적 파일의 전송 지연인지, 로그인 후 동적 API 응답이 느린지 구분합니다. 지역별 응답 시간, 캐시 적중률, 원본 요청 수, 트래픽, 전송량을 기록하세요. 동적 API가 느린데 정적 파일 캐시만 늘리면 체감 개선이 작을 수 있습니다. CDN 앞에 놓을 도메인과 원본 인증 방식도.. 2026. 9. 26. 기업용 이메일 선택: Microsoft 365와 Google Workspace 비교·이전 체크리스트 그림: 라이선스보다 메일 이전과 MX 전환 계획을 먼저 비교하세요.회사 메일 서비스를 바꿀 때는 월 구독료만 비교하면 부족합니다. 기존 메일 이전, 주소 유지, 사용자 교육, 보안 정책까지 준비해야 업무가 끊기지 않습니다. Microsoft 365와 Google Workspace 중 무엇이 유리한지 도입 시나리오로 판단해 봅니다.1. 먼저 현재 사용 방식을 조사한다사용자 수와 공유 메일함, 별칭, 보관해야 할 메일·캘린더·연락처, 기존 문서 형식을 목록화하세요. Outlook·Excel·Teams 중심 조직과 Gmail·Drive·Docs 중심 조직은 교육 비용이 다릅니다. 모바일 기기 관리, 퇴사자 자료 보존, 감사 로그가 필요한지도 확인합니다. 기능은 구독 등급과 계약 조건에 따라 달라지므로 실제 구.. 2026. 9. 26. HTTP 429 Too Many Requests 해결: Retry-After·재시도 백오프·Nginx 제한 확인 그림: 429를 받으면 제한 위치와 재시도 시각을 확인하세요.API나 로그인 요청에서 429 Too Many Requests가 나오면 일정 시간 동안 허용량보다 많은 요청을 보낸 것입니다. 즉시 무한 재시도하면 서비스를 더 압박합니다. 어느 계층이 제한했고 Retry-After가 있는지 먼저 확인하세요.1. 429를 반환한 계층을 찾는다브라우저 개발자 도구 또는 curl -i로 응답 헤더, 요청 ID, 시간을 기록하세요. API 제공자, CDN·WAF, Nginx, 앱 각각에서 429를 반환할 수 있습니다. 같은 IP의 모든 사용자가 실패하는지, 한 API 키만 실패하는지 비교하면 제한 기준을 좁힐 수 있습니다.curl -i https://example.com/api/resourcesudo tail -n.. 2026. 9. 25. Kubernetes CrashLoopBackOff 해결 순서: 이전 로그·종료 코드·프로브·메모리 점검 그림: 반복 재시작은 이전 실행의 종료 이유부터 확인하세요.CrashLoopBackOff는 컨테이너가 반복 종료되어 Kubernetes가 재시작 사이 대기 시간을 늘리는 상태입니다. 하나의 원인 이름이 아닙니다. 이전 실행의 로그, 종료 이유, 이벤트를 모아야 재시작 루프를 고칠 수 있습니다.1. 파드와 실패 컨테이너를 특정한다kubectl get pods -n NAMESPACEkubectl describe pod POD_NAME -n NAMESPACEkubectl logs POD_NAME -c CONTAINER_NAME -n NAMESPACE --previous--previous는 이전에 종료된 컨테이너 로그를 보여줍니다. 여러 컨테이너가 있으면 -c로 대상을 지정하세요. describe의 Last S.. 2026. 9. 25. 이전 1 2 3 4 ··· 23 다음
