728x90 반응형 전체 글187 GitHub Actions 릴리즈 자동화 실패담 — 토큰 권한과 산출물 경로 로컬에서 만든 exe와 zip을 수동으로 배포하다가 태그와 첨부 파일이 자꾸 어긋났다. GitHub Actions로 릴리즈 절차를 자동화했지만, 처음에는 토큰 권한에서 막혔고 OS별 산출물 경로도 다시 살펴봐야 했다.수동 배포에서 태그와 파일이 어긋났다처음에는 로컬에서 빌드한 exe만 수동으로 올려도 충분할 줄 알았다. 태그는 손으로 만들고, zip은 드래그해서 Release에 붙이면 끝이라고 생각했다.그런데 배포를 몇 번 반복하자 버전 태그와 첨부 파일이 계속 어긋났다. 어느 날은 태그만 올라가고 asset이 빠졌고, 어떤 날은 예전 빌드가 그대로 남아 있었다. 배포는 됐는데 무엇이 배포됐는지 불확실해졌다.GitHub Actions로 릴리즈 절차를 고정했다그래서 태그를 푸시하면 GitHub Action.. 2026. 10. 18. 자기 PC 원격 접속을 막고 최근 연결 기록 기준을 다시 잡았다 원격 제어 프로그램에서 최근 연결 기록의 시각 기준을 나누고, 자기 PC로의 접속을 막도록 정리했다. 온라인 상태는 하트비트 시각을 쓰고, 자기 PC인지는 별도의 해시 식별값으로 판별했다.두 정보는 기준 시각이 달라야 했다관리 화면에는 현장 PC의 온라인 표시와 마지막 연결 시각이 나온다. 최근 원격 연결한 PC 다섯 대를 보여 주는 목록도 별도로 있다.온라인 표시는 현재 PC 상태를 묻고, 최근 목록은 실제 원격 연결 이력을 묻는다. 뜻이 다른데도 기준 시각이 섞일 수 있는 구조여서 집계를 분리했다.온라인은 상태 확인, 최근 목록은 연결 성공온라인 표시와 마지막 연결 시각은 하트비트·pong 확인 시각을 유지한다.최근 연결 5대는 성공한 원격 연결의 connected_at 시각으로만 집계한다.연결에 실.. 2026. 10. 18. C 로그 파서에서 fgets를 믿었다가 긴 로그가 두 줄로 갈라진 날 C 로그 파서를 만들다가 긴 HEX 덤프가 엉뚱한 줄로 파싱되는 일을 겪었다. 원인은 fgets가 한 줄 전체를 읽어준다고 믿었던 데 있었다. 링 버퍼로 개행까지 재조립하고, 넘친 줄은 버리는 방식으로 고쳤다.짧은 로그에서는 문제가 없었다처음에는 char buf[1024]에 fgets로 한 줄씩 읽고, strtok로 필드만 나누면 충분할 줄 알았다. 짧은 상태 로그에서는 문제없이 돌아갔다.그런데 장비가 긴 HEX 덤프를 한 줄로 밀어내자 파싱 결과가 가끔 말도 안 되게 나왔다. 처음에는 장비가 이상한 데이터를 보내는 줄 알았다. 로그를 hex로 찍어보면서 원인을 다시 살펴봤다.fgets는 한 줄을 보장하지 않았다문제는 fgets의 동작을 잘못 이해한 데 있었다. 처음에는 개행을 만날 때까지 한 줄 전체를.. 2026. 10. 18. C++ 시리얼 포트 핸들 누수, 스마트 포인터로 수명 관리한 날 시리얼 포트를 닫았다고 생각했는데, 다시 연결할 때 간헐적으로 "이미 사용 중" 오류가 떴다. 원인은 예외나 연결 중단 경로에서 close 호출이 빠지는 것이었다. 결국 스마트 포인터보다 먼저 정리해야 했던 건 자원의 소유권이었다.시리얼 핸들이 남아 다시 연결하지 못했다처음에는 raw pointer로 포트 객체를 만들고, 닫을 때 delete하면 될 줄 알았다. 정상 종료 버튼을 누르는 경로에서는 문제없어 보였다.그런데 예외가 발생하거나 UI에서 연결을 중간에 끊으면 핸들이 남았다. 다시 열 때 "이미 사용 중" 오류가 간헐적으로 발생했다.close 호출이 빠지는 경로가 여러 곳이었다디버거로 확인해 보니 close 호출이 건너뛰어지는 경로가 한 곳이 아니었다. 정상 종료만 생각하고 정리 코드를 배치한 것.. 2026. 10. 18. 하트비트 pong마다 SQLite에 쓰던 구조, PC 증가에 대비해 5초 병합으로 바꿨다 원격 제어 프로그램의 관리 서버에서 PC 수에 따라 반복되는 작업을 정리했다. pong 기록은 5초 단위로 묶고, 업데이트 큐 점검은 서버 한 곳으로 모았다.PC 수에 따라 늘어나던 반복 작업관리 서버는 현장 PC의 에이전트와 WebSocket으로 통신한다. 연결 상태는 pong과 HTTP 하트비트 등으로 확인한다.상태를 확인할 때마다 서버에서 처리할 작업도 늘어난다. 현장 PC가 늘어날수록 같은 점검이 반복되는 구조를 살펴봤다.이 글에서 다룰 반복 작업은 크게 세 가지다. 서버와 관리 화면의 처리 흐름을 나눠 정리했다.pong을 받을 때마다 수행하던 SQLite 상태 기록하트비트마다 반복하던 전체 업데이트 큐 점검관리 화면에서 PC 목록 전체의 상태를 조회하던 방식이 변경은 구현과 검증, 배포를 마친 .. 2026. 10. 18. 비동기 GPU 인코딩에서 peer가 바뀌던 문제, 프레임에 소유자를 심다 원격 제어 프로그램의 GPU H.264 송출을 점검하며 비동기 시작 시점의 peer 식별 문제를 수정했다. 정지 화면 보완 범위도 조정했지만, NVIDIA 현장의 해결 여부는 아직 확인하지 못했다.비동기 InitEncode가 놓친 소유자WebRTC의 InitEncode는 비동기로 실행되므로 이 단계에는 담당 peer가 확정되지 않았다. 기존에는 프로세스 전역의 active peer 힌트를 이용해 소유자를 추정했다.이 힌트의 스코프가 인코더 태스크보다 먼저 끝나면 다른 peer의 MaxQP가 묶일 위험이 있었다. 소유자가 없는 인코더 하나에 peer를 임의 연결하던 예외 처리도 제거했다.소유 프레임이 도착한 뒤 MFT를 열었다캡처 프레임에 peer ID와 정지 보완 플래그를 담는 불변 wrapper를 도입.. 2026. 10. 18. 이전 1 2 3 4 ··· 32 다음 728x90 반응형