직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 전체 글223 원격 로그는 남는데 docker logs는 짧을 때: dual logging 캐시 확인 원격 저장소에 로그가 남아 있는데 docker logs에서 오래된 기록이 보이지 않으면 dual logging의 로컬 캐시 범위를 확인하세요. 원격 보존 기간과 로컬 조회 캐시는 서로 다른 저장 경로입니다.적용 환경: Docker Engine 컨테이너; 애플리케이션 출력과 실제 컨테이너 로깅 설정을 확인할 권한 필요. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 원격 저장과 로컬 조회는 다름Docker Engine은 로그 읽기를 지원하지 않는 드라이버를 사용할 때 dual logging을 자동으로 활성화합니다. local 드라이버를 캐시로 사용해 최근 로그를 읽게 하지만 이 캐시가 원격 저장소 전체를 조회하는 창은 아닙니다.기본 캐시는 컨테이너당 압.. 2026. 10. 27. git add를 취소하고 파일은 남기려면: restore --staged 확인 순서 git add만 취소하고 편집한 파일을 남기려면 작업 트리가 아니라 인덱스를 대상으로 해야 합니다. 커밋이 있는 저장소에서 git restore --staged로 특정 파일의 스테이징을 취소한 뒤, 파일 내용과 두 diff를 확인하세요.적용 환경: git restore를 지원하는 Git 2.23 이상, 커밋이 존재하는 로컬 저장소의 추적 파일. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 같은 restore라도 바꾸는 대상이 다름형태기본 대상과 주의restore --staged인덱스 복원; 기본 원본 HEADrestore작업 트리 복원; 미보존 편집 유실 위험--staged --worktree양쪽 변경; 단순 add 취소와 다름파일을 일부만 스테이징.. 2026. 10. 27. CloudWatch Logs 보존 기간을 줄이기 전: 삭제 시점과 복구 한계 확인 CloudWatch Logs 보존 기간을 줄이는 작업은 표시 옵션 변경이 아니라 오래된 로그의 삭제로 이어질 수 있는 변경입니다. 로그 그룹과 필요한 보존 기간을 확인하고, 이미 삭제된 로그는 기간을 다시 늘려도 돌아오지 않는다는 점부터 검토하세요.적용 환경: Amazon CloudWatch Logs 로그 그룹; 조직의 보존 의무와 별도 백업 여부는 담당자가 확인. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 보존 기준과 삭제 완료 시각을 혼동한 로그 그룹 안의 스트림들은 보존 설정을 공유합니다. 기본적으로 로그는 무기한 보존되며, 보존 설정을 바꾸면 기준을 지난 이벤트는 삭제 대상으로 표시됩니다. 실제 삭제에는 통상 최대 72시간이 걸리며 드물게 .. 2026. 10. 27. S3 파일은 없는데 용량이 남을 때: 미완료 멀티파트 업로드 점검 S3 객체 목록에서 파일을 찾지 못해도 완료하지 않은 멀티파트 업로드의 파트가 남아 있을 수 있습니다. 완료 객체 만료 규칙과 미완료 업로드 중단 규칙을 구분하고, 아직 진행 중인 작업인지 먼저 확인하세요.적용 환경: Amazon S3 일반 목적 버킷의 멀티파트 업로드; 완료 객체 만료와 구분. 자료 확인일: 2026-10-26. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 객체와 업로드 파트는 다른 상태대용량 전송을 여러 파트로 나누다가 완료 단계에 이르지 못하면 업로드 상태와 파트가 남을 수 있습니다. 객체 목록만 비교해서 사용량 차이를 전부 삭제 마커 때문이라고 결론 내리면 이 경로를 놓칩니다.운영 점검표에는 버킷, 업로드 식별자, 시작 시각, 전송 애플리케이션, 담당자를 나눠 .. 2026. 10. 27. systemd 설정이 반영되지 않을 때: daemon-reload·reload·restart 구분 systemd 유닛 파일을 수정했다면 daemon-reload로 관리자에게 다시 읽게 해야 합니다. 그러나 이것만으로 실행 중인 서비스가 새 실행 조건으로 바뀌지는 않습니다. 서비스 자체 설정 재읽기와 프로세스 재시작을 구분하세요.적용 환경: systemd 255 공식 문서 기준; 설치 버전과 배포판 정책은 적용 전 확인. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 서로 다른 설정 파일을 같은 방식으로 반영동작대상daemon-reloadsystemd 관리자와 유닛 구성reload서비스 자체의 지원되는 설정 재읽기restart서비스를 중지한 뒤 다시 시작웹 서버 설정과 systemd 서비스 유닛은 담당하는 프로그램이 다릅니다. 변경한 파일이 어느 쪽.. 2026. 10. 26. Git 커밋을 잃어버렸을 때: reflog 확인 후 복구 브랜치부터 만드는 순서 reset이나 rebase 뒤 커밋이 보이지 않으면 먼저 로컬 reflog에서 후보를 찾고 내용을 확인하세요. 바로 reset --hard를 실행하기보다 새 복구 브랜치를 만들어 후보 커밋을 보존하는 편이 현재 작업을 보호하기 쉽습니다.적용 환경: reflog와 해당 커밋 객체가 남아 있는 로컬 Git 저장소. 자료 확인일: 2026-10-25. 문서 기반 안내이며 실제 운영 시험 결과가 아닙니다.1. 원인: 현재 브랜치에서 안 보이는 것과 삭제는 다릅니다reflog는 로컬 참조가 이동한 기록입니다. HEAD 기록에는 브랜치 전환도 포함됩니다. 일반 커밋 이력과 다르며 원격 저장소와 같은 기록을 공유한다고 가정하면 안 됩니다.이 방법은 커밋 객체와 필요한 기록이 남아 있을 때의 경로입니다. 커밋하지 않은.. 2026. 10. 26. 이전 1 2 3 4 ··· 38 다음
