직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 전체 글203 Git unrelated histories 해결: 원격 주소와 공통 조상부터 확인 refusing to merge unrelated histories는 두 이력의 공통 조상을 찾지 못한 상황에서 나타날 수 있습니다. 먼저 저장소·원격 주소·비교 대상이 맞는지 확인하세요. 의도적으로 독립된 이력을 합치는 경우에만 --allow-unrelated-histories를 검토하고, 원본 보존과 충돌 검토를 먼저 준비합니다.원인: 같은 파일이 있어도 같은 커밋 이력은 아니다로컬과 원격에서 각각 새 저장소를 초기화했거나 다른 저장소를 연결하면 파일 이름이 비슷해도 이력이 독립적일 수 있습니다. 오류를 없애기 위해 곧바로 강제 푸시하거나 .git을 삭제하면 보존해야 할 기록을 잃을 수 있습니다.상태우선 확인피할 조치원격 주소 불일치저장소 선택무조건 병합이력 제한 가능clone 범위독립 이력 단정독립.. 2026. 10. 21. Docker Compose 달러 기호가 사라질 때: 보간과 컨테이너 셸 구분 Compose의 변수 경고나 빈 문자열이 보이면 먼저 값을 바꾸는 주체가 Compose인지 컨테이너 안의 셸인지 구분하세요. Compose 단계에서 문자 그대로의 달러 기호를 넘기려면 $$를 사용할 수 있지만, 이후 셸이 그 문자를 다시 해석하는지는 별도 문제입니다.원인: YAML을 읽는 단계와 명령 실행 단계를 혼동한다Compose는 설정의 달러 변수 표현을 해석할 수 있습니다. 정의되지 않은 변수에 기본값도 없으면 경고 후 빈 문자열로 바뀔 수 있습니다. 애플리케이션이 실행되기도 전에 값이 달라지는 상황입니다. 컨테이너 환경변수에 같은 이름이 있다는 이유만으로 Compose가 그 값을 알 것이라고 가정하지 마세요.관찰확인 위치다음 판단변수 미정의 경고Compose 입력출처·기본값달러 그대로 전달 필요.. 2026. 10. 21. CloudFront Functions와 Lambda@Edge 선택: 네트워크·본문·실행 시점 확인 짧은 URL 변경이나 헤더 정리는 CloudFront Functions부터 검토합니다. 외부 네트워크 조회, 요청 본문 접근, 원본 요청·응답 이벤트가 필요하면 Lambda@Edge의 지원 범위를 확인하세요. 요청마다 실행할 코드와 캐시를 놓쳤을 때 실행할 코드를 먼저 구분해야 합니다.혼동의 원인: 엣지에서 실행한다는 말만 보고 고른다두 기능 모두 CloudFront 요청 흐름에 코드를 연결하지만 같은 실행 환경은 아닙니다. URL 하나를 바꾸는 작업과 외부 권한 서버의 응답을 기다리는 작업은 필요한 자원이 다릅니다. 먼저 입력 정보, 호출 대상, 실행 시점을 한 줄씩 적어 보세요.필요 동작검토 후보주의짧은 URL·헤더 변경Functions런타임 제한외부 네트워크 조회Lambda@Edge지연·실패 처리요.. 2026. 10. 21. SQS Standard와 FIFO 선택: 순서 보장 범위와 중복 처리 방지 구분 메시지 순서가 업무 결과를 바꾸지 않고 중복 처리를 견딜 수 있으면 Standard가 후보입니다. 주문·계정처럼 같은 대상 안의 순서가 중요하면 FIFO와 메시지 그룹을 검토하세요. FIFO를 선택해도 소비자의 재처리와 데이터베이스 부수 효과까지 자동으로 한 번만 실행된다고 가정하면 안 됩니다.혼동의 원인: 전달 순서와 업무 완료를 같은 것으로 본다큐에 들어간 순서, 소비자가 받은 순서, 데이터베이스에 반영한 순서는 별개입니다. 예를 들어 한 주문의 생성과 취소가 뒤바뀌면 문제가 생길 수 있지만 서로 다른 주문의 처리 순서는 중요하지 않을 수 있습니다. 큐 이름을 고르기 전에 이 경계를 정해야 합니다.조건후보별도 검증독립 작업Standard중복·순서 변화대상별 순서 필요FIFO그룹 경계외부 API 부수 .. 2026. 10. 21. Linux 용량이 남는데 No space left on device: inode와 실제 저장 경로 확인 No space left on device가 나오는데 df -h에 여유가 있다면 실패한 경로의 파일시스템을 기준으로 df -i도 확인하세요. 데이터 블록과 inode 여유는 다른 정보입니다. 홈 디렉터리의 여유 공간을 보고 다른 마운트나 컨테이너의 저장 경로도 괜찮다고 판단하면 원인을 놓칠 수 있습니다.원인: 용량 수치 하나가 모든 자원을 뜻하지 않는다파일시스템은 파일 내용뿐 아니라 파일을 관리하는 정보도 필요합니다. 작은 파일이 많이 쌓이면 총 바이트만으로는 상태를 설명하기 어려울 수 있습니다. 또한 /tmp, 데이터 볼륨, 컨테이너 저장 경로가 서로 다른 파일시스템일 수 있습니다. 오류가 난 정확한 경로와 실행 환경을 먼저 적어야 합니다.관찰다음 확인주의블록 여유 있음같은 경로 df -i다른 마운트 .. 2026. 10. 19. Git detached HEAD 해결: 브랜치 이동 전에 커밋을 보존하는 순서 detached HEAD는 저장소가 고장 났다는 뜻이 아닙니다. 브랜치 이름 대신 특정 커밋을 보고 있는 상태입니다. 그 상태에서 만든 커밋을 남기려면 다른 브랜치로 이동하기 전에 현재 커밋에 새 브랜치를 붙이세요. 이미 이동했다면 reflog에서 실제 커밋을 확인한 뒤 복구 브랜치를 만듭니다.원인: 브랜치가 아니라 커밋을 체크아웃했다태그나 커밋 ID로 이전 버전을 확인하면 현재 위치가 브랜치와 떨어질 수 있습니다. 이 상태에서도 커밋은 만들 수 있지만 새 커밋이 원래 브랜치를 자동으로 앞으로 이동시키지는 않습니다. CI가 특정 커밋을 정확히 빌드하려고 이런 상태를 만드는 경우도 있으므로 경고만 보고 수정할 필요는 없습니다.상태먼저 할 일피할 일현재 detached 커밋 유지새 브랜치 생성먼저 다른 곳 .. 2026. 10. 19. 이전 1 2 3 4 ··· 34 다음
