직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 전체 글235 Compose exec가 CI에서 TTY 오류일 때: -T와 표준입력 구분 CI에서 Compose exec가 the input device is not a TTY로 멈추면 대화형 터미널 할당이 필요한지 먼저 확인하세요. Compose exec는 기본적으로 TTY를 할당하므로 비대화형 실행은 -T를 검토하고 표준입력 사용 여부는 따로 결정해야 합니다.적용 환경: Docker Compose V2의 exec와 실행 중인 서비스; Compose 프로젝트와 Docker 데몬 접근 권한 필요, Windows Git Bash·구형 docker-compose V1은 별도 진단. 자료 확인일: 2026-10-29. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 로컬 터미널과 CI 입력 환경이 다르다Docker 공식 문서는 Compose exec가 기.. 2026. 10. 30. Git push는 성공했는데 태그가 없을 때: 브랜치와 태그 전송 구분 브랜치 push가 성공했다고 로컬 태그도 모두 원격에 전송됐다고 가정하지 마세요. 로컬 태그의 존재와 대상 커밋을 확인하고, 실제 push 옵션·설정이 태그를 포함했는지 나누어 확인해야 합니다.적용 환경: Git 명령행 저장소와 원격 태그 목록 조회 권한; 실제 저장소 폴더에서 실행, 아래 명령은 로컬 조회 예시이며 원격 push는 실행하지 않음. 자료 확인일: 2026-10-29. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 브랜치와 태그는 별도의 참조다Git Book은 기본 git push가 태그를 자동 전송하지 않는다고 설명합니다. 다만 실제 동작은 명령의 refspec과 push.followTags 같은 설정의 영향을 받습니다. 성공 메시지 하나로 무.. 2026. 10. 30. S3 Batch Operations가 Complete인데 실패 객체가 남을 때: 완료 보고서 확인 S3 Batch Operations의 Complete는 작업 실행이 끝났다는 상태이며 모든 객체 작업이 성공했다는 보장은 아닙니다. 객체별 성공·실패를 완료 보고서와 작업 세부 정보에서 확인한 뒤 후속 작업 대상을 정하세요.적용 환경: 기존 Amazon S3 Batch Operations 작업과 완료 보고서; 작업·manifest·보고서 읽기 권한 필요, 새 작업 실행이나 객체 변경은 다루지 않음. 자료 확인일: 2026-10-29. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 작업의 종료와 객체별 결과는 다르다S3 Batch Operations는 manifest에 지정한 객체마다 태스크를 수행합니다. AWS의 상태 정의에 따르면 Complete에 도달한 작.. 2026. 10. 30. RDS 자동 확장 후 용량이 줄지 않을 때: 할당량과 여유 공간 구분 RDS 스토리지 자동 확장은 부족한 저장 공간을 늘리는 기능이며 이미 할당한 저장 공간을 자동으로 줄이지 않습니다. 데이터 정리 후에도 할당량이 남는다면 현재 할당량·여유 공간·자동 확장 상한을 따로 확인하세요.적용 환경: 스토리지 자동 확장을 지원하는 Amazon RDS DB 인스턴스의 기본 저장 공간; Aurora·추가 저장 볼륨 제외, 해당 인스턴스 설정과 지표 조회 권한 필요. 자료 확인일: 2026-10-29. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: 여유 공간 회복이 할당량 축소는 아니다자동 확장은 저장 공간 부족을 감지하면 할당량을 늘립니다. AWS 문서는 자동 확장 후의 할당 스토리지를 줄일 수 없다고 설명합니다. 따라서 데이터를 지워 여유.. 2026. 10. 30. curl에서 301·302만 보일 때: Location과 최종 URL 확인 curl에서 301·302가 보이면 첫 서버가 이동할 주소를 알려준 것인지 확인하세요. 기본 요청의 응답과 --location으로 따라간 뒤의 최종 응답을 나누어 기록하면 브라우저와 결과가 다른 이유를 좁힐 수 있습니다.적용 환경: curl 명령행 도구와 공개 HTTPS 조회용 URL; 아래 예시는 인증·쿠키·POST 데이터가 없는 GET만 대상으로 하며 POSIX 셸 기준. 자료 확인일: 2026-10-28. 공식 문서 기반 안내이며 실제 계정·운영 환경에서 실행한 시험 결과가 아닙니다.1. 원인: HTTP 이동을 자동으로 따라가지 않은 경우curl FAQ는 URL 뒤의 슬래시 유무 등으로 301 이동 응답이 생길 수 있으며 -L 또는 --location으로 HTTP 이동을 따라갈 수 있다고 설명합니다.. 2026. 10. 29. Git 과거 로그가 짧게 보일 때: shallow clone 여부부터 확인 CI나 새 복제본에서 과거 커밋이 보이지 않으면 먼저 shallow clone 여부를 확인하세요. 이력을 일부만 내려받은 상황은 커밋을 잃어버린 상황과 다르므로, 복구 명령보다 저장소와 조회 범위를 먼저 구분해야 합니다.적용 환경: Git의 --is-shallow-repository 옵션을 지원하는 로컬 저장소 또는 CI 체크아웃; 명령은 그 저장소 디렉터리에서 실행. 자료 확인일: 2026-10-28. 공식 문서와 별도 임시 저장소 시험을 구분해 안내합니다. 실제 운영·외부 원격 저장소에서 실행한 결과가 아닙니다.1. 원인: clone 깊이가 이력 탐색을 제한한다git clone --depth는 지정한 커밋 수로 이력을 제한하는 얕은 복제를 만듭니다. 기본적으로 단일 브랜치 복제를 함께 뜻하므로, 서버.. 2026. 10. 29. 이전 1 2 3 4 ··· 40 다음
