직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 전체 글215 journalctl -b -1 로그가 없을 때: 이전 부팅 기록과 저장 방식 점검 이전 부팅 로그가 안 보인다면 먼저 보유 중인 부팅 목록과 조회 권한을 확인하고, journald 저장 방식과 보존 정책을 살펴보세요. 지금 영구 저장을 켜도 이미 사라진 과거 기록이 다시 생기지는 않습니다.적용 환경: systemd 255 공식 매뉴얼 기준 Linux; 배포판 설정과 설치 버전 별도 확인. 공식 문서 확인일: 2026-10-23. 아래 내용은 문서 기반 점검 가이드이며 운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 조회할 기록이 남아 있는지 먼저 봅니다journalctl --list-boots는 현재 읽을 수 있는 저널의 부팅 번호·ID·시간 범위를 보여 줍니다. -b -1은 이전 부팅을 고르는 옵션이지, 없어진 로그를 복구하는 명령이 아닙니다. 권한 부족 안내가 있으면 승인된.. 2026. 10. 24. git stash 후 새 파일이 남을 때: 미추적 파일과 무시 파일 구분 git stash 뒤에 새 파일이 남는다면 먼저 미추적 파일인지, 무시된 파일인지 구분하세요. 기본 보관 범위에 새 파일이 모두 포함된다고 가정하면 작업을 잃을 수 있습니다.적용 환경: Git CLI; git --version과 설치된 git stash 도움말 확인. 공식 문서 확인일: 2026-10-23. 아래 내용은 문서 기반 점검 가이드이며 운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 파일 상태마다 포함 범위가 다릅니다파일 상태보관 옵션을 볼 때추적 중인 변경기본 stash 범위 확인미추적 파일-u 포함 여부 확인무시된 파일-u만으로 포함되지 않음status의 짧은 형식에서 ??는 미추적, --ignored로 표시한 !!는 무시된 경로입니다. 표시 범위를 좁혀 놓았다면 파일이 안 보일 수.. 2026. 10. 24. S3 만료 후 용량이 남는 이유: 삭제 마커와 비현재 버전 구분 버전 관리가 켜진 S3 버킷에서는 현재 객체를 만료시켜도 이전 데이터 버전이 남을 수 있습니다. 목록에서 사라졌다는 사실과 저장 데이터가 영구 삭제됐다는 사실을 구분해야 합니다.적용 환경: Amazon S3 버전 관리 Enabled 버킷; Suspended와 Object Lock은 별도 확인. 공식 문서 확인일: 2026-10-23. 아래 내용은 문서 기반 점검 가이드이며 운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 현재 목록이 전체 저장량은 아닙니다Enabled 버킷의 현재 버전 만료는 삭제 마커를 현재 버전으로 만들고 기존 데이터를 비현재 버전으로 남기는 방식입니다. 비현재 버전도 저장되어 있는 동안 비용 검토 대상입니다. 삭제 마커는 원본 데이터의 영구 삭제 증명이 아닙니다.구분확인할 의.. 2026. 10. 24. CloudWatch 데이터 부족 경보: missing·ignore·breaching 선택 기준 CloudWatch의 데이터 부족을 정상값 0으로 단정하지 마세요. 계속 보내야 하는 지표인지, 오류가 있을 때만 보내는 지표인지부터 구분하고 누락 데이터 처리와 경보 이력을 확인합니다.적용 환경: AWS CloudWatch 일반 지표 경보, 공식 문서 2026-10-23 확인. 문서 기반 가이드이며 실제 서비스 설정 변경·시험 결과가 아닙니다.1. 원인: 값이 없는 것과 정상값은 다릅니다수집 장애로 지표가 끊길 수도 있고, 이벤트가 있을 때만 값을 내보내는 설계일 수도 있습니다. 먼저 계정·리전·네임스페이스·차원이 실제 자원과 맞는지 확인합니다. 지표를 잘못 선택한 문제를 누락 처리 설정으로 덮지 않습니다.2. 해결 순서: 지표의 의미에 맞춰 선택합니다값누락값을 평가할 때의 의미notBreaching임.. 2026. 10. 24. curl은 성공인데 HTTP 404일 때: 종료 코드와 응답 상태를 따로 확인 curl의 종료 코드 0만으로 HTTP 요청이 업무상 성공했다고 판단하지 마세요. HTTP 404 응답을 정상적으로 받았을 때 기본 curl은 0으로 끝날 수 있습니다. HTTP 오류를 실패로 처리하면서 본문도 남기려면 지원 버전의 --fail-with-body와 응답 코드를 함께 확인하세요.원인: 통신 처리 결과와 HTTP 의미를 하나로 본다프로세스가 응답을 받는 데 성공했다는 판단과, 서버가 요청한 자원을 제공했다는 판단은 다릅니다. HTTP 4xx·5xx와 연결·DNS·TLS 실패를 같은 오류로 처리하면 잘못된 재시도나 배포 성공 판정으로 이어질 수 있습니다. 자동화에서는 종료 상태와 HTTP 코드와 본문을 각각 기록하는 편이 원인을 좁히기 쉽습니다.조회 방식HTTP 404의 처리본문 처리기본 cu.. 2026. 10. 23. git diff가 비어 있는데 변경이 남을 때: 작업 트리·인덱스·HEAD 비교 git add 뒤 일반 git diff가 비어 있다면 변경이 사라졌다고 판단하지 말고 git diff --cached를 확인하세요. 기본 diff는 작업 트리와 인덱스를, --cached는 인덱스와 HEAD를 비교합니다. 먼저 상태와 비교 범위를 읽고 되돌리기 명령은 사용하지 않는 것이 안전합니다.원인: diff가 비교하는 두 상태를 놓친다같은 파일도 작업 트리, 스테이징 영역인 인덱스, 마지막 커밋인 HEAD에 서로 다른 내용이 있을 수 있습니다. git add는 이후 커밋할 내용을 인덱스에 올립니다. 그 뒤 작업 파일을 다시 바꾸지 않았다면 기본 diff는 비어 있을 수 있지만, 인덱스와 HEAD의 차이는 남습니다.조회 명령비교 범위읽을 의미git diff작업 트리 ↔ 인덱스아직 스테이징하지 않은 수.. 2026. 10. 23. 이전 1 2 3 4 ··· 36 다음
