본문 바로가기

직접 만든 소프트웨어, 두 가지 개발 기록

구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다.

MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조

전체 글211

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.
CloudFront 캐시 정책과 오리진 요청 정책: 캐시 키와 추가 전달값 구분 응답을 구분하는 값은 캐시 키 설계에서, 오리진에만 추가로 필요한 값은 오리진 요청 정책에서 검토하세요. 오리진으로 전달했다는 이유만으로 캐시가 나뉘지는 않습니다. 개인화·인증 응답에는 이 구분을 기계적으로 적용하지 말고 별도의 캐시 안전성을 확인해야 합니다.원인: 전달하는 값과 응답을 구분하는 값을 같은 것으로 본다캐시 정책은 헤더·쿠키·쿼리 문자열 등 캐시 키에 포함할 값과 TTL을 다룹니다. 오리진 요청 정책은 캐시 키에 없는 추가 정보를 오리진 요청에 포함하는 용도로 사용할 수 있습니다. 캐시 키에 포함한 값은 오리진 요청에도 포함됩니다. 캐시 적중 때마다 오리진 요청이 발생하는 것으로 이해하면 검증이 어긋납니다.질문검토 대상확인할 결과이 값에 따라 응답이 다른가캐시 키 또는 캐시 금지 설계서로 .. 2026. 10. 23.
CloudTrail Event history와 Trail 선택: 조회 기간·이벤트 유형·보존 책임 구분 최근 관리 이벤트를 계정·리전 단위로 확인할 때는 Event history에서 시작하고, 지속적인 보관이나 데이터 이벤트 수집이 필요하면 Trail의 범위·저장·조회 설계를 따로 검토하세요. “CloudTrail을 쓴다”는 한 문장만으로 모든 활동이 보관됐다고 판단할 수 없습니다.원인: 현재 조회되는 기록과 지속 수집 설정을 혼동한다Event history는 최근 90일의 리전별 관리 이벤트를 보여 주며 Trail이나 이벤트 데이터 스토어와 별개입니다. 기본 조회 화면에 나타난다는 사실과 조직 전체·장기 보관 요구를 만족한다는 판단은 다릅니다. 애플리케이션 오류 로그나 사용자 행동 분석도 이 범위와 구분해야 합니다.확인할 요구먼저 볼 곳놓치기 쉬운 조건최근 관리 작업 확인Event history계정·리전.. 2026. 10. 23.
rsync 복사 경로가 한 단계 달라질 때: 소스 끝 슬래시와 dry-run 확인 rsync의 소스 디렉터리 끝에 슬래시가 있으면 보통 그 안의 내용을 복사하고, 없으면 디렉터리 이름을 포함하는 차이가 생깁니다. 목적지 상태와 파일 수에 따른 다른 규칙도 있으므로 실행 전 dry-run 결과에서 실제 상대 경로를 확인하세요.원인: 복사하려는 범위와 입력 경로가 다르다같은 파일이 들어 있는 폴더라도 “폴더 자체”와 “그 안의 내용”은 목적지 구조가 다릅니다. 소스 끝의 /를 장식처럼 취급하면 배포 파일이 예상보다 한 단계 아래에 놓일 수 있습니다. 반대로 경로 차이를 고친다며 운영 목적지를 삭제하면 별개의 손실을 만들 수 있습니다.소스 입력빈 목적지의 예읽을 범위sourcewhole/source/demo.txt디렉터리 이름 포함source/contents/demo.txt안의 내용1. 버.. 2026. 10. 22.
gitignore가 적용되지 않을 때: 추적 파일과 규칙 일치를 따로 확인 이미 Git이 추적하는 파일에는 .gitignore를 추가해도 추적이 자동 해제되지 않습니다. 먼저 git ls-files로 추적 상태를 보고, git check-ignore로 규칙을 확인하세요. 두 질문을 섞으면 정상 동작을 캐시 오류로 오해하기 쉽습니다.원인: 추적 상태와 무시 규칙은 다른 문제다무시 규칙은 의도적으로 추적하지 않을 파일에 사용합니다. 이미 인덱스에 있는 파일을 계속 수정하고 있다면 규칙을 추가해도 변경이 보일 수 있습니다. 먼저 저장소 루트와 대상 경로를 확인하고, 파일 내용에 비밀값이 있으면 출력이나 화면 공유에 포함하지 마세요.관찰확인할 질문다음 단계ls-files에 파일 표시이미 추적 중인가추적 유지 필요성 검토미추적인데 규칙 불일치패턴·위치가 맞나check-ignore 진단규.. 2026. 10. 22.

티스토리툴바