본문 바로가기

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

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

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

전체 글187

Docker·CI Git dubious ownership 해결: UID·마운트·safe.directory 점검 Docker나 CI에서 detected dubious ownership in repository가 나오면 Git 실행 사용자와 저장소의 실제 소유자를 먼저 비교하세요. UID·GID와 마운트 설계를 맞추는 것이 우선이며, 의도적으로 공유하는 신뢰된 저장소만 정확한 경로의 safe.directory 예외로 검토합니다. 모든 저장소를 신뢰하는 와일드카드 설정은 사용하지 않습니다. 이 글은 Git 소유권 검사이며 Docker 소켓 권한이나 파일 쓰기 권한 오류와는 별도입니다.원인: 쓰기 권한과 저장소 소유권 검사는 다르다호스트의 저장소를 컨테이너에 bind mount하면 컨테이너가 보는 경로와 실행 사용자가 호스트 작업 환경과 다를 수 있습니다. 파일을 읽거나 쓸 수 있어도 Git이 다른 소유자의 저장소를 신.. 2026. 10. 16.
SSH Host key verification failed 해결: 지문·포트·known_hosts 확인 순서 Host key verification failed가 나오면 known_hosts를 통째로 지우지 말고, 실제 접속할 호스트·포트와 서버 호스트 키 지문을 신뢰 가능한 별도 경로에서 먼저 확인하세요. 정당한 서버 교체가 확인된 뒤 해당 항목만 갱신합니다. 이 오류는 서버 신원 확인 문제이며 사용자의 개인 키로 로그인하는 Permission denied (publickey)와 해결 순서가 다릅니다. 아래는 OpenSSH를 쓰는 Linux·macOS·CI 환경의 문서 기반 절차입니다.원인 구분: 새 서버·바뀐 키·잘못된 접속 대상서버 재설치로 호스트 키가 바뀌었을 수도 있지만 DNS·프록시·포트 설정 때문에 다른 서버에 닿았을 수도 있습니다. 경고는 공격 가능성도 포함하므로 “오래된 캐시”로 단정하지 않습니.. 2026. 10. 16.
EBS gp3와 io2 비교: EC2 데이터베이스 지연·IOPS·비용 선택 기준 일반적인 블록 스토리지 성능을 조절하려면 gp3의 용량·IOPS·처리량을 먼저 검토하고, 지연에 민감한 DB가 더 일관된 낮은 스토리지 지연을 요구할 때 io2 Block Express를 비교합니다. 볼륨을 바꾸기 전에 EC2 인스턴스의 EBS 한도와 실제 DB 병목을 확인해야 합니다. 이 글은 EC2에 연결한 EBS 볼륨을 기준으로 하며 RDS의 관리형 스토리지 설정이나 EFS 공유 파일 시스템에 그대로 적용하는 절차가 아닙니다.원인부터 분리: IOPS가 높아도 쿼리가 느릴 수 있다IOPS는 초당 입출력 횟수, 처리량은 초당 전송 데이터량, 지연은 입출력 한 번이 끝나기까지 걸리는 시간입니다. 큰 순차 읽기와 작은 무작위 쓰기는 필요한 자원이 다릅니다. 캐시 부족, 잠금 대기, CPU, 쿼리 계획 문제.. 2026. 10. 16.
Lambda 예약된·프로비저닝된 동시성 비교: API 콜드 스타트·상한·비용 선택 예약된 동시성은 함수가 사용할 동시 실행 용량을 확보하면서 상한을 정하는 설정이고, 프로비저닝된 동시성은 실행 환경을 미리 초기화해 시작 지연을 줄이는 유료 설정입니다. API의 첫 응답이 느리다는 이유로 예약된 동시성만 늘려도 콜드 스타트가 사라지지는 않습니다. 이 글은 일반적인 리전 내 Lambda 함수의 동기 API 호출을 기준으로, 두 설정의 선택과 적용 후 확인 방법을 설명합니다. 이벤트 소스별 별도 제한은 따로 확인해야 합니다.혼동의 원인: 동시 실행 상한과 시작 준비를 같은 것으로 보기동시성은 처리 중인 요청의 수이고 초당 요청 수와 다릅니다. 같은 요청률이라도 실행 시간이 길어지면 동시에 필요한 환경이 늘어납니다. 먼저 느린 시간이 초기화, 핸들러 실행, DB 연결 또는 외부 호출 중 어디.. 2026. 10. 16.
PostgreSQL statement timeout 해결: 잠금 대기·세션 설정·트랜잭션 범위 점검 canceling statement due to statement timeout은 PostgreSQL이 한 명령의 시간 예산을 넘겨 취소했다는 뜻입니다. 먼저 실제 접속의 설정값과 잠금 대기를 확인하고, 즉시 timeout을 0으로 끄거나 전체 DB 제한을 늘리지 마세요. statement_timeout에는 잠금 대기 시간도 포함될 수 있습니다. 쿼리 자체가 느린지, 다른 트랜잭션을 기다리는지, 앱·프록시에서 먼저 끊겼는지 나눠야 합니다.이 글은 PostgreSQL 16 공식 문서를 기준으로 한 진단입니다. 다른 주 버전은 지원 설정과 동작을 해당 버전 문서에서 확인합니다. 예제는 문서 검토용 SQL이며 운영 DB에 연결하거나 쿼리를 실행한 결과는 아닙니다. 오류 메시지·시각·연결 경로를 보존한 뒤 제한.. 2026. 10. 15.
Nginx 정적 파일 404 해결: root·alias 경로와 try_files 점검 순서 파일은 있는데 Nginx 정적 요청이 404라면, 요청 URI에서 실제 파일 경로를 한 번 계산하고 오류 로그가 찾은 경로와 비교하세요. root는 URI를 지정한 디렉터리 뒤에 붙이고, alias는 선택된 location 부분을 다른 경로로 바꿉니다. 호스트에 파일이 존재한다는 사실만으로 Nginx 프로세스가 같은 경로를 본다고 확정할 수 없습니다.Linux의 Nginx가 정적 파일을 직접 제공하는 경우를 다룹니다. Docker를 쓰면 컨테이너 안의 파일 경로를 기준으로 점검합니다. proxy_pass 뒤 애플리케이션이 돌려준 404는 별도 경로입니다. 공식 문서 확인일은 2026년 10월 14일이며 아래 경로는 설명용 예시입니다. 실제 서버에서 재현하거나 설정을 적용했다고 주장하지 않습니다.404 원.. 2026. 10. 15.

티스토리툴바