프로젝트 기록
PokeClip의 Live와 DVR을 나누고, 다시 이어 붙이는 조건
Live·DVR URL 분리, DB 기준의 S3 매니페스트 발행, 자동 핸드오프의 조건을 연결합니다. 완료한 발행·되감기 연동과 진행 중인 시간축 검증을 구분합니다.
쌓아 온 기록
문제의 시작부터 검증의 끝까지. 총 90편의 글.
프로젝트 기록
컨테이너는 살아 있고 설정 파일은 사라졌다: PokeClip Media 호스트의 재시작 경계
비정상 종료 시험에서 남은 컨테이너와 삭제된 비밀 파일이 충돌한 원인을 추적하고, 정리·마운트·재생성 조건을 함께 보완했습니다.
프로젝트 기록
MediaMTX 앞 nginx가 확인해야 했던 것: 허용한 방송과 요청한 방송의 일치
경로의 방송 ID와 playback 쿼리를 대조하고, 정규화·중복 파라미터 우회 요청이 상류에 도달하지 않도록 검증한 기록입니다.
오픈소스
MediaMTX 종료가 멈춘 이유: 시작하지 않은 인증서 감시 작업을 기다리고 있었다
읽기 전용 파일시스템에서 발생한 CertLoader 종료 교착을 재현하고, no-watch 경로의 완료 신호와 저장 성공·실패 회귀 테스트로 수정한 PR #6427 기록.
개발 노트
워크트리는 나눴는데 검사는 섞였다: 개발 하네스의 세션 격리와 루트 고정
동시 개발 세션이 검사 상태를 공유하고 워크트리 편집을 놓치던 문제를 세션별 상태와 고정 루트로 개선한 기록.
프로젝트 기록
PokeClip의 DB 인증을 공통 모듈로 묶기: RDS IAM, TLS, 연결 풀의 경계
두 서비스의 세 연결 풀에 흩어진 DB 접속 정책을 pgconf로 모으고, IAM 토큰 재발급과 verify-full을 실험 RDS에서 검증한 기록.
프로젝트 기록
오류 0건 뒤의 빈틈을 찾는 일: PokeClip · MediaMTX · Shakedown 개발 기록
공통 DB 인증, nginx 요청 검증, DVR 발행과 복구, MediaMTX 기여를 만든 판단과 검증을 연결한 기술 글 모음.
프로젝트 기록
채팅이 많으면 하이라이트일까: 자동 탐지의 가설과 수동 대체 경로
채널별 기준선·고유 참여자·미디어 시간 보정을 검토한 연구 기록. 검증된 정확도 성과와 구분합니다.
프로젝트 기록
클립을 파일로만 저장하지 않은 이유: 편집 레시피와 렌더의 경계
원본을 보존하고 편집 의도를 데이터로 남기면서, 되감기 재포장과 최종 렌더를 구분한 PokeClip 설계 기록.
프로젝트 기록
테스트가 모두 통과해도 CI를 실패시켜야 할 때
테스트 제외 실험과 정수 교차곱으로 80% 커버리지 게이트의 실제 차단과 경계값을 검증한 기록.
프로젝트 기록
CI 경로 필터를 바꾸려면 브랜치 보호부터 바꿔야 했다
미디어와 무관한 PR의 CI 표시를 없애며 필수 검사 포기, 적용 순서, 롤백을 함께 다룬 PR #163.
프로젝트 기록
마이크를 고르는 문제에 상시 VAD가 필요할까
말소리 검출과 마이크 선택을 구분하고, 클립 구간의 RMS·미리듣기로 분석 범위를 줄인 설계 판단.
프로젝트 기록
streamId의 의미를 바꾸기 전에 소비자의 조회부터 확인했다
방송 회차와 실제 미디어 경로를 분리하면서 기존 소비자의 조회와 배포 순서를 조율한 계약 변경.
오픈소스
기본값을 복사했는데 왜 다른 설정까지 바뀔까: 인증 설정의 두 가지 회귀
nil·빈 슬라이스 비교와 중첩 기본값 공유를 함께 고친 MediaMTX #6205의 수정·회귀 테스트·호환성.
오픈소스
Close가 반환했는데 인증서 watcher는 살아 있었다
종료 요청과 실제 완료를 분리하고 갱신 중간을 통제해 20/20 실패→20/20 통과를 확인한 MediaMTX #6261.
오픈소스
서버는 켜졌는데 방송을 재생할 수 없었다: HLS 설정 검증을 앞당기기
MediaMTX #6154에서 런타임 먹서의 최소 조각 수를 공통 설정 검증에 맞추고 v1.21.0에 반영한 과정.
오픈소스
실패한 명령이 종료 코드 0으로 보인 이유: 빠진 return 하나의 영향
MediaMTX #6155에서 non-Windows 훅의 실패 종료 코드를 복구하고 재시작 설정별 관측 결과를 검증한 기록.
오픈소스
훅 로그를 더 모으면 종료도 더 기다릴까: 유실률과 역압력 실험
동시 훅 1·4·8·16개의 파일 로그 유실과 종료 꼬리, 별도 가드 v2 보존 실험을 구분한 로컬 관측 기록.
오픈소스
안전하게 기다리려던 수정이 교착을 만들 수 있었다: 미병합 PR #6206
로거 재생성 전에 훅을 기다리는 접근의 가용성 비용과 교착 한계, 유지보수자의 대체 수정까지 남긴 기록.
오픈소스
대체 화면은 보여주되 녹화하지 않기: 기존 PR을 이어 완성한 상태 경계
기존 #5767의 기여를 보존하고 static source·offline reload 경계를 보완해 MediaMTX v1.21.0에 반영한 #6182.
오픈소스
시작조차 못 한 명령은 stderr를 남길 수 없다: 빠진 7종 훅 콜백
13개 외부 명령 생성 지점을 대조해 빠진 실패 보고 7곳을 연결하고 통제한 19개 사건을 검증한 #6259.
프로젝트 기록
백업이 있다는 말 대신 복원한 데이터로 확인했습니다
MySQL 수동 스냅샷과 MongoDB 데이터 볼륨을 새 대상에 복원하고, 이전 데이터·새 쓰기를 검증하며 자동 백업의 권한 한계를 구분했습니다.
프로젝트 기록
TLS로 연결됐는데도 더 확인한 것: MySQL 호스트 검증과 MongoDB 장애 전환
MySQL의 정상 TLS와 잘못된 호스트 거부를 짝으로 확인하고, MongoDB의 암호화·단일 primary 장애 전환을 별도 검증했습니다.
프로젝트 기록
잘못된 Java 구문이 ALLOW를 받았을 때: 보안 검사 앞에 구문 검사를 둔 이유
Semgrep 경로에서 잘못된 Java 구문이 ALLOW를 받은 반례를 유지하고, Tree-sitter 사전 검사로 SCAN_FAILED 경계를 보완했습니다.
프로젝트 기록
재부팅 후에는 살아나고, 삭제 후에는 살아나지 않아야 했습니다
수동 시작이 필요했던 초기 결과를 보완하고, 제품 API 배포 뒤 재부팅 복구와 DELETE 뒤 미부활을 두 번의 실제 EC2 재부팅으로 확인했습니다.
프로젝트 기록
MediaMTX 업그레이드에서 이미지만 바꾸면 놓치는 것들
MediaMTX 포크 전환 때 설정·훅·녹화 입력의 9개 전제를 재검증하고, 제품 이미지와 테스트·라이브러리의 버전 기준을 함께 맞췄습니다.
프로젝트 기록
Shakedown에서 AI가 만들 수 있는 배포 구성을 먼저 제한한 이유
기존 Dockerfile과 지원 스택 규칙을 먼저 사용하고, 실패할 때만 Claude를 호출하도록 이미지 생성과 인프라 판단의 범위를 제한했습니다.
프로젝트 기록
선택한 배포 계획을 AWS에 적용하고, 장애 뒤 복구까지 확인하기
저장된 배포 계획을 실제 AWS 자원에 연결하고, 기동·중지 시간 예산과 태스크·RDS 장애 뒤 복구를 별도 조건으로 확인했습니다.
오픈소스
사용자별 SRT 암호를 제안하며 인증 범위와 대기 비용을 함께 살펴봤습니다
사용자별 SRT passphrase 제안에서 기존 경로 암호의 호환성, 비밀값 처리, HTTP 성공 본문을 기다리는 비용을 함께 검증했습니다.
프로젝트 기록
시간값만 바꿨더니 8.10초가 39.87초가 됐습니다
같은 녹화 파일 10개에서 init 분리와 tfdt 변경을 분리해 S3·CDN 직접 재생의 시간축 조건을 확인했습니다.
프로젝트 기록
늦게 끝난 writer가 새 재생목록을 덮는다면
DB 장부·작성 권한·세대·S3 조건부 PUT을 나눈 설계와 실제 S3에서 재시작 전후 발행을 확인한 결과를 설명합니다.
프로젝트 기록
재포장 23.43→3.05ms: 같은 I/O 범위로 다시 측정한 이유
FFmpeg 프로세스 호출을 상주 Go 재포장으로 바꾸고, 같은 입력·읽기·쓰기를 포함한 200회 대조와 동시성 비용을 확인했습니다.
프로젝트 기록
276개 파일을 회수해도 p95만으로는 부족했습니다: 알림 유실을 견디는 인덱서
완료 훅·파일 감시·재스캔을 나눠 설계하고, 정상과 알림 유실 네 조건에서 누락·중복과 마지막 파일 지연을 확인했습니다.
프로젝트 기록
6초 창 때문에 라이브러리를 포크할 필요가 있을까
재생목록 창·실제 시청 지연·녹화 길이를 분리해 7조각·약 14초 창과 녹화 4초를 독립적으로 선택했습니다.
프로젝트 기록
12번이 준비돼도 11번을 건너뛰면 안 됩니다: HLS 목록 경계 검증
연속 확정 구간과 최근 1시간 창을 계산하고, 10만 행 원장의 초기 계산·tail 갱신·전체 렌더 비용을 구분했습니다.
프로젝트 기록
재생 조각이 만들어졌다는 것과 저장됐다는 것을 나누기
원본·재생 조각·init의 독립 상태, MinIO 업로드 확인, 16MiB 입력 경계와 동시성 비용을 설명합니다.
프로젝트 기록
재접속의 0.2초 빈틈: 타임스탬프와 불연속 태그를 함께 바꾸기
이른 트랙 끝과 DISCONTINUITY 조합을 대조하고, 동일 init 조건에서 150조각·두 재접속 경계를 확인했습니다.
프로젝트 기록
USER만 바꾸면 녹화가 깨진다: scratch와 새 볼륨의 권한 설계
런타임 root 작업 없이 녹화와 사이드카 읽기를 유지하기 위해 이미지 단계에서 소유권을 확정했습니다.
프로젝트 기록
3.9초부터 자르면 첫 조각이 빠진다: 조회 계약과 8,020개 경계 검증
시작점 BETWEEN을 실제 구간 겹침으로 정정하고, 계약 확정·팀원 구현·SQL 정확성 시험을 구분했습니다.
프로젝트 기록
끝난 재생목록은 다시 열지 않기로 했습니다
송출 키·녹화기 표식·논리 회차를 분리하고 ENDLIST 불변과 조건부 이전 회차 계승을 설계했습니다.
프로젝트 기록
S3 파일 8개, 246.2→130.5ms: 새 저장 계층을 보류한 이유
4초 객체라는 작업 단위를 기준으로 새 저장 계층 도입을 보류하고 PUT·GET·동시성의 실제 측정 범위를 나눴습니다.
프로젝트 기록
가짜 실패 행 1,121개가 남았다: 테스트 DB의 소유권부터 확인하기
테스트 종료 정리로 해결되지 않는 개발 DB 오염을 전용 DB와 명시적 소유 표식으로 차단한 과정입니다.
프로젝트 기록
S3에는 올라갔는데 DB는 pending: 업로드 복구의 기준을 정하다
큐 접수·객체 생성·DB 완료를 나누고, 스위퍼의 접수 회차와 실제 PostgreSQL 상태 복구를 별도로 검증했습니다.
프로젝트 기록
오류는 0건인데 61.94초가 보이지 않았습니다
141.97초 목록이 80.03초로 인식되고 60초 탐색이 약 87초로 이동한 현상에서 재생 성공 조건을 다시 정했습니다.
프로젝트 기록
오디오 자동 배정이 방송자의 원래 설정을 망가뜨리지 않게 하기
본방 트랙 2의 440Hz 보존과 컬렉션별 복원을 대조했습니다. 자동 배정을 켜는 것만큼 끈 뒤의 상태도 확인한 기록입니다.
프로젝트 기록
200인데 검은 화면이었다: 세 원인이 겹친 HLS 재생 문제 추적
서버 오류를 없애도 검은 화면은 남았습니다. GAP 7개와 hls.js 초기화를 차례로 조사하고 실제 재생·되감기까지 확인했습니다.
프로젝트 기록
원본 요청 1,254건을 28건으로: 캐시 키와 인증 전달을 분리한 실험
401이 난 첫 시도에서 캐시 키와 원본 전달 정책을 분리했습니다. 원본 요청 1,254→28건과 97.95%의 분모, 403 검증을 함께 설명합니다.
프로젝트 기록
편집을 맡긴다고 채널 게시까지 맡기는 것은 아니다
편집 결과를 보존하면서 게시 결정은 방송자에게 남기기 위해 제작·직접 업로드·자동 업로드와 승인 대기를 나눈 설계입니다.
프로젝트 기록
채팅 수집을 Spring으로 바꾼 이유: 언어보다 먼저 정할 책임
채팅 담당자가 바뀌면서 Node 자산 재사용과 이후 변경 검토 비용을 다시 비교해 Spring 전환을 선택했습니다.
프로젝트 기록
방송이 끝나기 전에 클립을 만들려면: 라이브·되감기·편집 경로 나누기
편집 원본에는 오디오 6개를 보존하고 되감기는 1개로 단순화했습니다. 같은 방송의 소비 목적이 달라 처리 경로를 나눈 이유입니다.
프로젝트 기록
미디어 서버를 전부 만들려던 계획을 바꾼 이유
OBS→SRT→녹화·재생을 확인한 뒤 직접 구현할 범위를 파일 색인·복구·시간축으로 좁혔습니다.
프로젝트 기록
오디오 6개가 보인다고 검증이 끝난 것은 아니었다
6트랙의 존재, 선택 추출, 실제 소리 보존을 나누어 검사했습니다. 무음 입력과 테스트 톤은 다른 것을 증명합니다.
프로젝트 기록
본방 인코더 하나로 SRT도 보내기: 시작과 종료가 더 어려웠다
로컬에서 x264 인코더 1개로 RTMP·SRT를 함께 보냈습니다. 시작 전 GOP 설정과 실행 중 거절, 종료 수명을 함께 다뤘습니다.
프로젝트 기록
OBS 안에 OAuth를 다시 만들지 않고 계정을 연결하는 방법
8자·10분·일회용 코드로 OBS를 연결하면서 시도 제한과 재사용 응답, 사용 기록의 보존 기간까지 정했습니다.
프로젝트 기록
부분 목록으로 방송을 지우지 않기: 폐기한 경로 조정 설계에서 남은 판단
연결별 인증으로 전환하며 폐기한 path-reconciler 설계입니다. 부분 목록으로 삭제하지 않는 규칙과 인증 지연의 영향을 남겼습니다.
프로젝트 기록
해시로 충분한 값과 다시 읽어야 하는 비밀: SRT 키 저장을 바꿀 계획
현재 PG의 passphrase를 Secrets Manager로 옮기는 전환을 준비 중입니다. 원문 사용과 키 대조를 나눈 이유 및 변경 조건을 설명합니다.
프로젝트 기록
소스 약 10개를 직접 추적하는 대신 OBS 6트랙을 선택한 이유
약 10개 소스를 직접 추적하는 대신 필요한 편집 조합을 OBS 6트랙으로 표현하고 전달·복원을 확인했습니다.
프로젝트 기록
API처럼 교체할 수 없는 서버: 방송 상태를 가진 미디어의 배포 경계
UDP 세션·진행 중 녹화·업로드 전 파일이 남는 미디어를 코어 API와 다르게 배치한 이유입니다.
프로젝트 기록
치지직·SOOP 실시간 채팅 수집기를 만들며 겪은 문제들
방송 채팅 데이터로 하이라이트를 찾아내는 도구를 만들면서 부딪힌 문제들과 해결 과정, 그리고 한 번의 틀린 가설에 대한 기록이다.
프로젝트 기록
채팅은 알고 있었다 - PokeClip 파이프라인을 갈아엎은 기록 (v3→v4)
지난 글에서 PokéClip의 v3 아키텍처를 소개했다. 영상(YOLO)·음성(Whisper)·채팅 세 신호를 병렬로 분석하고, 둘 이상이 임계치를 넘으면 하이라이트로 판정하는 "E 하이브리드" 구조였다.
기술 해설
방송 시작부터 재생까지 — 가정으로 살펴보는 라이브 트랜스코딩 인프라
이 글은 가상의 라이브 파이프라인을 구성해 책임과 비용을 비교하는 학습 노트다. 처음부터 등장하는 6.2초는 단계별 시간을 임의로 배정한 예시이며, 치지직이나 다른 서비스에서 측정한 시작 지연이 아니다.
기술 해설
HLS와 DASH가 미디어 조각을 공유하는 방법 — CMAF
HLS와 DASH는 서로 다른 매니페스트를 사용한다. 그렇다고 항상 영상을 두 번 인코딩해야 하는 것은 아니다. 같은 압축 비트스트림을 다른 컨테이너로 포장할 수 있기 때문이다.
기술 해설
NVENC와 x264의 비용을 비교하려면 — GPU 트랜스코딩의 조건
NVENC의 비용을 x264와 비교하려면 같은 입력·출력 사다리·화질 목표에서 지속 처리량을 측정해야 한다. 동시 방송 1,000개와 5개 출력이 있다는 사실만으로 서버 대수를 결정할 수 없다. 5개 출력의 해상도와 처리 비용도 서로 다르다.
기술 해설
콘텐츠마다 다른 화질 사다리 — ABR Ladder 설계
ABR은 같은 콘텐츠를 여러 해상도·비트레이트로 준비해 재생 조건에 맞게 선택하는 방식이다. 코덱까지 나누면 출력 개수가 더 늘어난다. 그러나 “Netflix는 모든 영화를 50번 인코딩한다”는 고정 숫자를 뒷받침할 근거는 없어 제거했다.
기술 해설
코덱은 기술이 아니라 비즈니스 결정이다 — 시나리오/비용/디버깅 종합
지금까지 H.264, AAC, H.265, Opus, AV1, VP9까지 코덱 6개를 봤다. 각각의 압축 원리와 라이센스 구조를 알아도, 실무 질문은 결국 하나로 모인다.
기술 해설
FFmpeg로 읽는 라이브 미디어 파이프라인 — 입력부터 인코딩과 출력까지
치지직, Twitch, Netflix의 라이브/VOD 인프라를 뜯어보면 공통점이 있다. 모두 FFmpeg 위에서 굴러간다. 그것도 인프라만이 아니다.
기술 해설
AV1과 VP9 — 압축 기술과 로열티 프리 목표를 구분해서 보기
영상 코덱의 역사는 단순했다. ITU + ISO가 H.264 만들고, H.265 만들고. 모두 그걸 쓰면 됐다.
기술 해설
Discord 음성이 1초도 안 끊기는 비밀 — Opus
Discord 음성 채팅을 켜놓고 게임할 때, 통신사가 LTE 약전계에 진입해도 목소리가 거의 안 끊기는 경험. WhatsApp 보이스 메시지가 1990년대 모뎀 같은 인터넷에서도 들리는 경험. Zoom이 카페 와이파이에서도 화면은 깨져도 음성은 계속 들리는 경험.
기술 해설
H.265를 선택할 때 압축 효율만으로 부족한 이유 — 호환성과 HDR
H.265(HEVC)는 H.264보다 발전한 압축 도구를 제공한다. 실제 비트레이트 절감률과 인코딩 비용은 콘텐츠·설정·구현에 따라 달라진다. 보급률 1%나 항상 50% 절감처럼 단일 숫자로 일반화할 근거는 이 글에 없다.
기술 해설
영상 옆의 128kbps — AAC와 오디오 코덱을 따로 살펴야 하는 이유
영상 6Mbps와 오디오 128kbps를 가정하면 오디오 비중은 128 ÷ (6000 + 128) × 100 ≈ 2.09%다. 오버헤드를 제외한 예시이며, 고정적인 5%가 아니다.
기술 해설
373MB/s에서 6Mbps로 — 조건을 명시하고 이해하는 H.264 압축
1080p 60fps를 RGB 8비트 × 3채널, 패딩 없는 raw 영상으로 계산하면 1920 × 1080 × 3 × 60 = 373,248,000바이트/초, 즉 373.248MB/s다. 1시간은 약 1.344TB다. 여기서 MB·TB는 10진 단위다.
기술 해설
RTMP를 IETF가 끝내려고 하는 중 — WHIP/WHEP
[지난 시리즈](../rtmp-still-alive/)에서 RTMP가 20년이 지나도 안 죽는 이유를 봤다. 도입 비용 0, 호환성 100%, 생태계 관성.
기술 해설
Google이 Skype 독점을 깨려고 만든 — WebRTC
2010년만 해도 화상 통화는 무조건 별도 프로그램 설치가 필요했다. Skype, MSN Messenger, 시스코의 WebEx. 브라우저에서 카메라/마이크에 접근할 방법이 없었다. 자체 P2P 프로토콜은 폐쇄적이었고, 기업이 가입자를 가두는 도구였다.
기술 해설
방송사들이 인터넷으로 송출할 때 쓰는 비밀병기 — SRT
올림픽이나 월드컵 중계를 보면 현장 카메라 → 본사 → 시청자로 신호가 흐른다. 옛날엔 위성/전용선이었다. 한 번 깔면 안정적이지만 한 번 쏘는 데 수천만 원.
기술 해설
HLS의 25초 지연을 2초로 — LL-HLS는 무엇을 바꿨나
라이브 방송을 보다가 채팅이 영상보다 빠른 경험, 게임 스포일러가 채팅으로 먼저 새는 경험, 다 해봤을 거다. 이게 일반 HLS의 18~25초 지연 때문이다.
기술 해설
DASH가 기술적으로 더 좋은데 왜 HLS가 이겼나
기술 표준의 역사에서 자주 보이는 패턴이 있다. 기술적으로 더 우수한 게 시장에서 진다.
기술 해설
라이브 영상이 그냥 파일이라고? — HLS의 미친 발상
2009년 Apple이 한 결정이 라이브 스트리밍의 모든 걸 바꿨다.
기술 해설
Flash는 2020년에 죽었는데 RTMP는 왜 안 죽나
OBS 켜본 사람은 다 알 거다. 방송 설정에 들어가면 "서버"와 "스트림 키"를 입력하라고 한다. 그 서버 주소가 rtmp://로 시작한다.
기술 해설
시청자 수와 비트레이트로 계산하는 CDN 전송량과 비용
라이브 CDN의 전송량은 평균 동시 시청자 수, 비트레이트, 시간으로 추산할 수 있다. 청구 금액에는 실제 계약 단가와 과금 조건이 더 필요하다.
기술 해설
버퍼링은 왜 생기나 — TCP HoL Blocking부터 Origin Shield까지
"왜 갑자기 영상이 멈추지?"
기술 해설
화질이 좋다는 건 정확히 무슨 뜻인가 — 해상도, 비트레이트, ABR
"이 영상 1080p인데 왜 깨져 보이지?"
기술 해설
1080p 영상의 데이터량부터 다시 계산하기 — 스트리밍의 기초 4가지
치지직 입사를 목표로 스트리밍 기술을 공부 중이다. HLS, WebRTC 같은 프로토콜부터 본 게 아니라 더 아래 — "동영상이 도대체 뭐길래 압축이 필요한가", "TCP는 왜 라이브에 안 맞나" 같은 기초부터 다시 정리했다.
프로젝트 기록
치지직 하이라이트 자동 추출 파이프라인 설계기 - PokeClip
라이브 방송에서 하이라이트 클립을 자동으로 뽑아내는 시스템을 만들었다. 치지직 스트림을 실시간으로 받아서 재밌는 순간을 감지하고, 클립으로 저장하는 파이프라인이다.
기술 해설
RTMP, MPEG-TS, SRT - 직접 짜면서 이해한 것들
치지직 스트림에서 오디오를 분리해서 분석하는 파이프라인을 짜야 했다. 처음엔 HLS로 받으면 되는 거 아닌가 싶었는데, 알고 보니 완전히 다른 문제였다.
개발 노트
6개월 후 내 이력서에 있을 것들 — 미디어 백엔드 편
--- 이력서
개발 노트
클린 아키텍처 — 로버트 C. 마틴
기술 해설
HLS 완전 정복 — 치지직 입사 수준으로
2009년 애플이 만들었다. 당시 웹 영상 재생은 Flash 기반이었는데 아이폰에 Flash가 없었다. 그래서 Flash 없이 HTTP만으로 스트리밍할 수 있는 방법으로 만든 게 HLS다.
개발 노트
GitHub Pages 블로그 자동화 시스템 고도화 보고서
본 문서는 GitHub Pages 블로그 자동화 시스템 초기 구축 이후 진행된 기능 고도화 작업에 대한 회고 보고서이다. 성공적으로 구현된 기능뿐 아니라 시도하였으나 실패하거나 한계에 부딪힌 사례도 함께 기록하여, 실제 개발 과정을 있는 그대로 남긴다.
개발 노트
GitHub Pages 블로그 자동화 구축기
- - -
기술 해설
Kafka 핵심 개념 기술 피드백
카프카란 대용량 이벤트 처리 시스템 디스크에 순차적으로 저장하기 때문에 속도가 빠름 비동기 처리 백에서 작동 직접적으로 클라이언트와 소통하지 않음 이녀석의 역할을 단순히 데이터를 저장하는 역할 jvm에 접근하지 않고 os cache page를 사용하기 때문에 속도가 빠름 실시간성이 강함 메세지 묶음 처리 그러나 용도…