직접 만든 소프트웨어, 두 가지 개발 기록 구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다. MediaMTX 스트리밍 제어 서버Docker Compose 구성과 파일·라이브·멀티캐스트 송출 RTSP CCTV 관제·분석 프로그램관제 그룹, 영역·출입선, 이벤트 이력을 연결하는 구조 전체 글199 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. Aurora Serverless v2와 프로비저닝 비교: 최소 ACU·유휴 시간·지연 조건 사용량 변화가 크다면 Aurora Serverless v2를, 지속적으로 일정한 부하와 용량 계획이 중요하다면 프로비저닝 구성을 함께 비교하세요. Serverless라는 이름만으로 유휴 비용이 항상 0이 되지는 않습니다. 최소 ACU, 자동 일시 중지 지원 조건, 연결 상태와 재개 지연을 확인해야 합니다.선택이 빗나가는 원인: 평균 부하만 보는 것하루 평균 사용량이 낮아도 출근 시간에 연결과 쿼리가 몰릴 수 있습니다. 반대로 접속자가 적어 보여도 백그라운드 작업이 데이터베이스를 계속 사용하기도 합니다. 견적에는 평균만 넣고 최소 용량은 가장 작게 정하면 실제 필요한 응답 시간을 충족하지 못할 수 있습니다.관찰검토 방향시험 항목큰 부하 변화Serverless 후보확장 중 지연일정한 지속 부하프로비저닝과 비.. 2026. 10. 19. API Gateway HTTP API와 REST API 선택: WAF·사용량 계획·비공개 엔드포인트 확인 AWS API Gateway 안에서 HTTP API와 REST API를 고를 때는 WAF 연동, 고객별 사용량 계획, 비공개 API 엔드포인트가 필요한지 먼저 확인하세요. 이 요구가 있으면 REST API를 우선 검토합니다. 단순한 공개 HTTP 백엔드 연결과 JWT 인증이 중심이라면 HTTP API가 후보지만, 낮은 단가만 보고 필요한 기능을 빼면 안 됩니다.혼동의 원인: 제품 이름과 API 설계 방식을 섞는다HTTP API도 RESTful API를 제공할 수 있습니다. 여기서 REST API는 AWS 상품 유형 이름입니다. REST 방식으로 설계했다는 이유만으로 반드시 REST API 상품을 골라야 한다는 뜻은 아닙니다. 팀의 요구사항을 인증, 접속 경로, 고객별 제어로 나눠 보면 선택이 쉬워집니다... 2026. 10. 19. systemd start-limit-hit 해결: 최초 실패를 고친 뒤 reset-failed로 복구 start-limit-hit나 Start request repeated too quickly가 보이면 먼저 제한에 도달하기 전의 최초 실패 로그를 찾으세요. reset-failed는 실패 상태와 시작 제한 카운터를 정리하지만 프로그램의 오류를 수정하지 않습니다. 원인을 고친 다음 대상 서비스만 재개하고 재발 여부를 확인해야 합니다.원인: 마지막 메시지는 시작을 막은 결과일 수 있다서비스가 짧은 시간에 여러 번 시작되면 systemd의 시작 횟수 제한에 걸릴 수 있습니다. 자동 재시작뿐 아니라 수동 시작도 해당 제한과 관계되므로 같은 start 명령을 연속 실행해 해결하려고 하면 진단이 더 어려워집니다. 마지막 제한 메시지 앞에 설정 누락, 실행 파일 오류, 의존 대상 접근 실패 같은 실제 원인이 있는지 .. 2026. 10. 18. Docker invalid reference format 해결: 이미지 이름과 셸 인수를 구분해 점검 invalid reference format은 먼저 Docker가 IMAGE 인수로 무엇을 받았는지 확인해야 하는 오류입니다. 저장소 이름 문법이 틀렸을 수도 있지만, 따옴표가 빠진 경로나 빈 변수 때문에 다른 문자열이 이미지로 해석될 수도 있습니다. 이미지 전체를 무조건 소문자로 바꾸거나 다시 빌드하기 전에 인수 경계를 확인하세요.원인: 이미지 참조의 문법 오류와 인수 위치 오류가 같은 메시지로 보일 수 있다docker run은 옵션 다음에 이미지 인수를 받고 그 뒤에 컨테이너 명령과 인수를 받습니다. 옵션 값이 공백에서 잘리면 예상하지 않은 조각이 IMAGE 자리에 놓일 수 있습니다. 이 단계에서 실패했다면 애플리케이션 로그나 컨테이너 네트워크부터 수정하는 것은 원인과 맞지 않을 수 있습니다.관찰먼저.. 2026. 10. 18. 이전 1 2 3 4 ··· 34 다음
