<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>taeyun.blog — 김태윤의 엔지니어링 노트</title><link>https://taeyun.blog/</link><description>백엔드와 미디어 인프라의 개발 기록</description><language>ko</language><item><title>PokeClip의 Live와 DVR을 나누고, 다시 이어 붙이는 조건</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-live-dvr-separation-handoff/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-live-dvr-separation-handoff/</guid><pubDate>Wed, 28 Oct 2026 10:22:22 GMT</pubDate><description>Live·DVR URL 분리, DB 기준의 S3 매니페스트 발행, 자동 핸드오프의 조건을 연결합니다. 완료한 발행·되감기 연동과 진행 중인 시간축 검증을 구분합니다.</description></item><item><title>컨테이너는 살아 있고 설정 파일은 사라졌다: PokeClip Media 호스트의 재시작 경계</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-media-host-restart-lifecycle/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-media-host-restart-lifecycle/</guid><pubDate>Wed, 28 Oct 2026 10:22:04 GMT</pubDate><description>비정상 종료 시험에서 남은 컨테이너와 삭제된 비밀 파일이 충돌한 원인을 추적하고, 정리·마운트·재생성 조건을 함께 보완했습니다.</description></item><item><title>MediaMTX 앞 nginx가 확인해야 했던 것: 허용한 방송과 요청한 방송의 일치</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-nginx-playback-request-boundary/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-nginx-playback-request-boundary/</guid><pubDate>Wed, 28 Oct 2026 10:22:04 GMT</pubDate><description>경로의 방송 ID와 playback 쿼리를 대조하고, 정규화·중복 파라미터 우회 요청이 상류에 도달하지 않도록 검증한 기록입니다.</description></item><item><title>MediaMTX 종료가 멈춘 이유: 시작하지 않은 인증서 감시 작업을 기다리고 있었다</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-certloader-no-watcher-shutdown/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-certloader-no-watcher-shutdown/</guid><pubDate>Wed, 28 Oct 2026 09:38:23 GMT</pubDate><description>읽기 전용 파일시스템에서 발생한 CertLoader 종료 교착을 재현하고, no-watch 경로의 완료 신호와 저장 성공·실패 회귀 테스트로 수정한 PR #6427 기록.</description></item><item><title>워크트리는 나눴는데 검사는 섞였다: 개발 하네스의 세션 격리와 루트 고정</title><link>https://taeyun.blog/posts/0-to-1/harness-session-isolation-worktree-root/</link><guid>https://taeyun.blog/posts/0-to-1/harness-session-isolation-worktree-root/</guid><pubDate>Wed, 28 Oct 2026 09:38:09 GMT</pubDate><description>동시 개발 세션이 검사 상태를 공유하고 워크트리 편집을 놓치던 문제를 세션별 상태와 고정 루트로 개선한 기록.</description></item><item><title>PokeClip의 DB 인증을 공통 모듈로 묶기: RDS IAM, TLS, 연결 풀의 경계</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-shared-db-auth-iam-tls/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-shared-db-auth-iam-tls/</guid><pubDate>Wed, 28 Oct 2026 09:38:09 GMT</pubDate><description>두 서비스의 세 연결 풀에 흩어진 DB 접속 정책을 pgconf로 모으고, IAM 토큰 재발급과 verify-full을 실험 RDS에서 검증한 기록.</description></item><item><title>오류 0건 뒤의 빈틈을 찾는 일: PokeClip · MediaMTX · Shakedown 개발 기록</title><link>https://taeyun.blog/posts/0-to-1/portfolio-engineering-notes/</link><guid>https://taeyun.blog/posts/0-to-1/portfolio-engineering-notes/</guid><pubDate>Fri, 16 Oct 2026 03:37:00 GMT</pubDate><description>공통 DB 인증, nginx 요청 검증, DVR 발행과 복구, MediaMTX 기여를 만든 판단과 검증을 연결한 기술 글 모음.</description></item><item><title>채팅이 많으면 하이라이트일까: 자동 탐지의 가설과 수동 대체 경로</title><link>https://taeyun.blog/posts/0-to-1/chat-highlight-research-and-fallback/</link><guid>https://taeyun.blog/posts/0-to-1/chat-highlight-research-and-fallback/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>채널별 기준선·고유 참여자·미디어 시간 보정을 검토한 연구 기록. 검증된 정확도 성과와 구분합니다.</description></item><item><title>클립을 파일로만 저장하지 않은 이유: 편집 레시피와 렌더의 경계</title><link>https://taeyun.blog/posts/0-to-1/clip-edit-recipe-render-boundary/</link><guid>https://taeyun.blog/posts/0-to-1/clip-edit-recipe-render-boundary/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>원본을 보존하고 편집 의도를 데이터로 남기면서, 되감기 재포장과 최종 렌더를 구분한 PokeClip 설계 기록.</description></item><item><title>테스트가 모두 통과해도 CI를 실패시켜야 할 때</title><link>https://taeyun.blog/posts/0-to-1/coverage-gate-that-fails-when-tests-disappear/</link><guid>https://taeyun.blog/posts/0-to-1/coverage-gate-that-fails-when-tests-disappear/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>테스트 제외 실험과 정수 교차곱으로 80% 커버리지 게이트의 실제 차단과 경계값을 검증한 기록.</description></item><item><title>CI 경로 필터를 바꾸려면 브랜치 보호부터 바꿔야 했다</title><link>https://taeyun.blog/posts/0-to-1/media-ci-path-filter-required-check-tradeoff/</link><guid>https://taeyun.blog/posts/0-to-1/media-ci-path-filter-required-check-tradeoff/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>미디어와 무관한 PR의 CI 표시를 없애며 필수 검사 포기, 적용 순서, 롤백을 함께 다룬 PR #163.</description></item><item><title>마이크를 고르는 문제에 상시 VAD가 필요할까</title><link>https://taeyun.blog/posts/0-to-1/microphone-selection-without-always-on-vad/</link><guid>https://taeyun.blog/posts/0-to-1/microphone-selection-without-always-on-vad/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>말소리 검출과 마이크 선택을 구분하고, 클립 구간의 RMS·미리듣기로 분석 범위를 줄인 설계 판단.</description></item><item><title>streamId의 의미를 바꾸기 전에 소비자의 조회부터 확인했다</title><link>https://taeyun.blog/posts/0-to-1/stream-id-contract-compatible-migration/</link><guid>https://taeyun.blog/posts/0-to-1/stream-id-contract-compatible-migration/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>방송 회차와 실제 미디어 경로를 분리하면서 기존 소비자의 조회와 배포 순서를 조율한 계약 변경.</description></item><item><title>기본값을 복사했는데 왜 다른 설정까지 바뀔까: 인증 설정의 두 가지 회귀</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-auth-defaults-normalization-and-clone/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-auth-defaults-normalization-and-clone/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>nil·빈 슬라이스 비교와 중첩 기본값 공유를 함께 고친 MediaMTX #6205의 수정·회귀 테스트·호환성.</description></item><item><title>Close가 반환했는데 인증서 watcher는 살아 있었다</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-certificate-watcher-close-join/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-certificate-watcher-close-join/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>종료 요청과 실제 완료를 분리하고 갱신 중간을 통제해 20/20 실패→20/20 통과를 확인한 MediaMTX #6261.</description></item><item><title>서버는 켜졌는데 방송을 재생할 수 없었다: HLS 설정 검증을 앞당기기</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-hls-segment-count-validation/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-hls-segment-count-validation/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>MediaMTX #6154에서 런타임 먹서의 최소 조각 수를 공통 설정 검증에 맞추고 v1.21.0에 반영한 과정.</description></item><item><title>실패한 명령이 종료 코드 0으로 보인 이유: 빠진 return 하나의 영향</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-hook-exit-code-return/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-hook-exit-code-return/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>MediaMTX #6155에서 non-Windows 훅의 실패 종료 코드를 복구하고 재시작 설정별 관측 결과를 검증한 기록.</description></item><item><title>훅 로그를 더 모으면 종료도 더 기다릴까: 유실률과 역압력 실험</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-hook-output-backpressure-experiments/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-hook-output-backpressure-experiments/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>동시 훅 1·4·8·16개의 파일 로그 유실과 종료 꼬리, 별도 가드 v2 보존 실험을 구분한 로컬 관측 기록.</description></item><item><title>안전하게 기다리려던 수정이 교착을 만들 수 있었다: 미병합 PR #6206</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-logger-reload-rejected-lifecycle-fix/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-logger-reload-rejected-lifecycle-fix/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>로거 재생성 전에 훅을 기다리는 접근의 가용성 비용과 교착 한계, 유지보수자의 대체 수정까지 남긴 기록.</description></item><item><title>대체 화면은 보여주되 녹화하지 않기: 기존 PR을 이어 완성한 상태 경계</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-offline-recording-source-lifecycle/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-offline-recording-source-lifecycle/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>기존 #5767의 기여를 보존하고 static source·offline reload 경계를 보완해 MediaMTX v1.21.0에 반영한 #6182.</description></item><item><title>시작조차 못 한 명령은 stderr를 남길 수 없다: 빠진 7종 훅 콜백</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-seven-hooks-missing-exit-callback/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-seven-hooks-missing-exit-callback/</guid><pubDate>Thu, 15 Oct 2026 02:40:52 GMT</pubDate><description>13개 외부 명령 생성 지점을 대조해 빠진 실패 보고 7곳을 연결하고 통제한 19개 사건을 검증한 #6259.</description></item><item><title>백업이 있다는 말 대신 복원한 데이터로 확인했습니다</title><link>https://taeyun.blog/posts/0-to-1/shakedown-database-restore-proves-backup/</link><guid>https://taeyun.blog/posts/0-to-1/shakedown-database-restore-proves-backup/</guid><pubDate>Thu, 15 Oct 2026 02:36:25 GMT</pubDate><description>MySQL 수동 스냅샷과 MongoDB 데이터 볼륨을 새 대상에 복원하고, 이전 데이터·새 쓰기를 검증하며 자동 백업의 권한 한계를 구분했습니다.</description></item><item><title>TLS로 연결됐는데도 더 확인한 것: MySQL 호스트 검증과 MongoDB 장애 전환</title><link>https://taeyun.blog/posts/0-to-1/shakedown-database-tls-identity-and-failover/</link><guid>https://taeyun.blog/posts/0-to-1/shakedown-database-tls-identity-and-failover/</guid><pubDate>Thu, 15 Oct 2026 02:36:25 GMT</pubDate><description>MySQL의 정상 TLS와 잘못된 호스트 거부를 짝으로 확인하고, MongoDB의 암호화·단일 primary 장애 전환을 별도 검증했습니다.</description></item><item><title>잘못된 Java 구문이 ALLOW를 받았을 때: 보안 검사 앞에 구문 검사를 둔 이유</title><link>https://taeyun.blog/posts/0-to-1/shakedown-java-syntax-before-security-scan/</link><guid>https://taeyun.blog/posts/0-to-1/shakedown-java-syntax-before-security-scan/</guid><pubDate>Thu, 15 Oct 2026 02:36:25 GMT</pubDate><description>Semgrep 경로에서 잘못된 Java 구문이 ALLOW를 받은 반례를 유지하고, Tree-sitter 사전 검사로 SCAN_FAILED 경계를 보완했습니다.</description></item><item><title>재부팅 후에는 살아나고, 삭제 후에는 살아나지 않아야 했습니다</title><link>https://taeyun.blog/posts/0-to-1/shakedown-reboot-recovery-and-deletion/</link><guid>https://taeyun.blog/posts/0-to-1/shakedown-reboot-recovery-and-deletion/</guid><pubDate>Thu, 15 Oct 2026 02:36:25 GMT</pubDate><description>수동 시작이 필요했던 초기 결과를 보완하고, 제품 API 배포 뒤 재부팅 복구와 DELETE 뒤 미부활을 두 번의 실제 EC2 재부팅으로 확인했습니다.</description></item><item><title>MediaMTX 업그레이드에서 이미지만 바꾸면 놓치는 것들</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-dependency-upgrade-contracts/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-dependency-upgrade-contracts/</guid><pubDate>Thu, 15 Oct 2026 02:33:48 GMT</pubDate><description>MediaMTX 포크 전환 때 설정·훅·녹화 입력의 9개 전제를 재검증하고, 제품 이미지와 테스트·라이브러리의 버전 기준을 함께 맞췄습니다.</description></item><item><title>Shakedown에서 AI가 만들 수 있는 배포 구성을 먼저 제한한 이유</title><link>https://taeyun.blog/posts/0-to-1/shakedown-bounded-ai-image-generation/</link><guid>https://taeyun.blog/posts/0-to-1/shakedown-bounded-ai-image-generation/</guid><pubDate>Thu, 15 Oct 2026 02:33:48 GMT</pubDate><description>기존 Dockerfile과 지원 스택 규칙을 먼저 사용하고, 실패할 때만 Claude를 호출하도록 이미지 생성과 인프라 판단의 범위를 제한했습니다.</description></item><item><title>선택한 배포 계획을 AWS에 적용하고, 장애 뒤 복구까지 확인하기</title><link>https://taeyun.blog/posts/0-to-1/shakedown-plan-deployment-and-recovery/</link><guid>https://taeyun.blog/posts/0-to-1/shakedown-plan-deployment-and-recovery/</guid><pubDate>Thu, 15 Oct 2026 02:33:48 GMT</pubDate><description>저장된 배포 계획을 실제 AWS 자원에 연결하고, 기동·중지 시간 예산과 태스크·RDS 장애 뒤 복구를 별도 조건으로 확인했습니다.</description></item><item><title>사용자별 SRT 암호를 제안하며 인증 범위와 대기 비용을 함께 살펴봤습니다</title><link>https://taeyun.blog/posts/open-source-analysis/mediamtx-user-srt-passphrase-boundaries/</link><guid>https://taeyun.blog/posts/open-source-analysis/mediamtx-user-srt-passphrase-boundaries/</guid><pubDate>Thu, 15 Oct 2026 02:33:48 GMT</pubDate><description>사용자별 SRT passphrase 제안에서 기존 경로 암호의 호환성, 비밀값 처리, HTTP 성공 본문을 기다리는 비용을 함께 검증했습니다.</description></item><item><title>시간값만 바꿨더니 8.10초가 39.87초가 됐습니다</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-cdn-timeline-normalization/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-cdn-timeline-normalization/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>같은 녹화 파일 10개에서 init 분리와 tfdt 변경을 분리해 S3·CDN 직접 재생의 시간축 조건을 확인했습니다.</description></item><item><title>늦게 끝난 writer가 새 재생목록을 덮는다면</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-database-authoritative-manifest-publishing/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-database-authoritative-manifest-publishing/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>DB 장부·작성 권한·세대·S3 조건부 PUT을 나눈 설계와 실제 S3에서 재시작 전후 발행을 확인한 결과를 설명합니다.</description></item><item><title>재포장 23.43→3.05ms: 같은 I/O 범위로 다시 측정한 이유</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-go-remux-same-io-benchmark/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-go-remux-same-io-benchmark/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>FFmpeg 프로세스 호출을 상주 Go 재포장으로 바꾸고, 같은 입력·읽기·쓰기를 포함한 200회 대조와 동시성 비용을 확인했습니다.</description></item><item><title>276개 파일을 회수해도 p95만으로는 부족했습니다: 알림 유실을 견디는 인덱서</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-indexer-recovery-without-events/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-indexer-recovery-without-events/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>완료 훅·파일 감시·재스캔을 나눠 설계하고, 정상과 알림 유실 네 조건에서 누락·중복과 마지막 파일 지연을 확인했습니다.</description></item><item><title>6초 창 때문에 라이브러리를 포크할 필요가 있을까</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-live-window-without-fork/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-live-window-without-fork/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>재생목록 창·실제 시청 지연·녹화 길이를 분리해 7조각·약 14초 창과 녹화 4초를 독립적으로 선택했습니다.</description></item><item><title>12번이 준비돼도 11번을 건너뛰면 안 됩니다: HLS 목록 경계 검증</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-manifest-window-boundaries/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-manifest-window-boundaries/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>연속 확정 구간과 최근 1시간 창을 계산하고, 10만 행 원장의 초기 계산·tail 갱신·전체 렌더 비용을 구분했습니다.</description></item><item><title>재생 조각이 만들어졌다는 것과 저장됐다는 것을 나누기</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-playback-producer-boundaries/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-playback-producer-boundaries/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>원본·재생 조각·init의 독립 상태, MinIO 업로드 확인, 16MiB 입력 경계와 동시성 비용을 설명합니다.</description></item><item><title>재접속의 0.2초 빈틈: 타임스탬프와 불연속 태그를 함께 바꾸기</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-reconnect-audio-gap/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-reconnect-audio-gap/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>이른 트랙 끝과 DISCONTINUITY 조합을 대조하고, 동일 init 조건에서 150조각·두 재접속 경계를 확인했습니다.</description></item><item><title>USER만 바꾸면 녹화가 깨진다: scratch와 새 볼륨의 권한 설계</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-scratch-volume-ownership/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-scratch-volume-ownership/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>런타임 root 작업 없이 녹화와 사이드카 읽기를 유지하기 위해 이미지 단계에서 소유권을 확정했습니다.</description></item><item><title>3.9초부터 자르면 첫 조각이 빠진다: 조회 계약과 8,020개 경계 검증</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-segment-overlap-contract/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-segment-overlap-contract/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>시작점 BETWEEN을 실제 구간 겹침으로 정정하고, 계약 확정·팀원 구현·SQL 정확성 시험을 구분했습니다.</description></item><item><title>끝난 재생목록은 다시 열지 않기로 했습니다</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-session-url-and-endlist/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-session-url-and-endlist/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>송출 키·녹화기 표식·논리 회차를 분리하고 ENDLIST 불변과 조건부 이전 회차 계승을 설계했습니다.</description></item><item><title>S3 파일 8개, 246.2→130.5ms: 새 저장 계층을 보류한 이유</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-storage-before-new-layer/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-storage-before-new-layer/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>4초 객체라는 작업 단위를 기준으로 새 저장 계층 도입을 보류하고 PUT·GET·동시성의 실제 측정 범위를 나눴습니다.</description></item><item><title>가짜 실패 행 1,121개가 남았다: 테스트 DB의 소유권부터 확인하기</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-test-database-ownership-marker/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-test-database-ownership-marker/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>테스트 종료 정리로 해결되지 않는 개발 DB 오염을 전용 DB와 명시적 소유 표식으로 차단한 과정입니다.</description></item><item><title>S3에는 올라갔는데 DB는 pending: 업로드 복구의 기준을 정하다</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-upload-state-and-recovery/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-upload-state-and-recovery/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>큐 접수·객체 생성·DB 완료를 나누고, 스위퍼의 접수 회차와 실제 PostgreSQL 상태 복구를 별도로 검증했습니다.</description></item><item><title>오류는 0건인데 61.94초가 보이지 않았습니다</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-zero-errors-missing-playback/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-zero-errors-missing-playback/</guid><pubDate>Thu, 15 Oct 2026 02:28:22 GMT</pubDate><description>141.97초 목록이 80.03초로 인식되고 60초 탐색이 약 87초로 이동한 현상에서 재생 성공 조건을 다시 정했습니다.</description></item><item><title>오디오 자동 배정이 방송자의 원래 설정을 망가뜨리지 않게 하기</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-audio-assignment-user-state/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-audio-assignment-user-state/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>본방 트랙 2의 440Hz 보존과 컬렉션별 복원을 대조했습니다. 자동 배정을 켜는 것만큼 끈 뒤의 상태도 확인한 기록입니다.</description></item><item><title>200인데 검은 화면이었다: 세 원인이 겹친 HLS 재생 문제 추적</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-black-screen-three-causes/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-black-screen-three-causes/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>서버 오류를 없애도 검은 화면은 남았습니다. GAP 7개와 hls.js 초기화를 차례로 조사하고 실제 재생·되감기까지 확인했습니다.</description></item><item><title>원본 요청 1,254건을 28건으로: 캐시 키와 인증 전달을 분리한 실험</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-cdn-cache-auth-measurement/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-cdn-cache-auth-measurement/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>401이 난 첫 시도에서 캐시 키와 원본 전달 정책을 분리했습니다. 원본 요청 1,254→28건과 97.95%의 분모, 403 검증을 함께 설명합니다.</description></item><item><title>편집을 맡긴다고 채널 게시까지 맡기는 것은 아니다</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-editing-upload-authorization/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-editing-upload-authorization/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>편집 결과를 보존하면서 게시 결정은 방송자에게 남기기 위해 제작·직접 업로드·자동 업로드와 승인 대기를 나눈 설계입니다.</description></item><item><title>채팅 수집을 Spring으로 바꾼 이유: 언어보다 먼저 정할 책임</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-language-ownership-boundaries/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-language-ownership-boundaries/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>채팅 담당자가 바뀌면서 Node 자산 재사용과 이후 변경 검토 비용을 다시 비교해 Spring 전환을 선택했습니다.</description></item><item><title>방송이 끝나기 전에 클립을 만들려면: 라이브·되감기·편집 경로 나누기</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-live-editing-boundaries/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-live-editing-boundaries/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>편집 원본에는 오디오 6개를 보존하고 되감기는 1개로 단순화했습니다. 같은 방송의 소비 목적이 달라 처리 경로를 나눈 이유입니다.</description></item><item><title>미디어 서버를 전부 만들려던 계획을 바꾼 이유</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-mediamtx-build-or-adopt/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-mediamtx-build-or-adopt/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>OBS→SRT→녹화·재생을 확인한 뒤 직접 구현할 범위를 파일 색인·복구·시간축으로 좁혔습니다.</description></item><item><title>오디오 6개가 보인다고 검증이 끝난 것은 아니었다</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-multiaudio-end-to-end-verification/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-multiaudio-end-to-end-verification/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>6트랙의 존재, 선택 추출, 실제 소리 보존을 나누어 검사했습니다. 무음 입력과 테스트 톤은 다른 것을 증명합니다.</description></item><item><title>본방 인코더 하나로 SRT도 보내기: 시작과 종료가 더 어려웠다</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-obs-shared-encoder-srt/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-obs-shared-encoder-srt/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>로컬에서 x264 인코더 1개로 RTMP·SRT를 함께 보냈습니다. 시작 전 GOP 설정과 실행 중 거절, 종료 수명을 함께 다뤘습니다.</description></item><item><title>OBS 안에 OAuth를 다시 만들지 않고 계정을 연결하는 방법</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-one-time-pairing-contract/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-one-time-pairing-contract/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>8자·10분·일회용 코드로 OBS를 연결하면서 시도 제한과 재사용 응답, 사용 기록의 보존 기간까지 정했습니다.</description></item><item><title>부분 목록으로 방송을 지우지 않기: 폐기한 경로 조정 설계에서 남은 판단</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-path-reconciler-design-history/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-path-reconciler-design-history/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>연결별 인증으로 전환하며 폐기한 path-reconciler 설계입니다. 부분 목록으로 삭제하지 않는 규칙과 인증 지연의 영향을 남겼습니다.</description></item><item><title>해시로 충분한 값과 다시 읽어야 하는 비밀: SRT 키 저장을 바꿀 계획</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-secret-storage-migration-plan/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-secret-storage-migration-plan/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>현재 PG의 passphrase를 Secrets Manager로 옮기는 전환을 준비 중입니다. 원문 사용과 키 대조를 나눈 이유 및 변경 조건을 설명합니다.</description></item><item><title>소스 약 10개를 직접 추적하는 대신 OBS 6트랙을 선택한 이유</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-six-track-input-contract/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-six-track-input-contract/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>약 10개 소스를 직접 추적하는 대신 필요한 편집 조합을 OBS 6트랙으로 표현하고 전달·복원을 확인했습니다.</description></item><item><title>API처럼 교체할 수 없는 서버: 방송 상태를 가진 미디어의 배포 경계</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-stateful-media-deployment/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-stateful-media-deployment/</guid><pubDate>Thu, 15 Oct 2026 02:27:08 GMT</pubDate><description>UDP 세션·진행 중 녹화·업로드 전 파일이 남는 미디어를 코어 API와 다르게 배치한 이유입니다.</description></item><item><title>치지직·SOOP 실시간 채팅 수집기를 만들며 겪은 문제들</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-chat-collector-postmortem/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-chat-collector-postmortem/</guid><pubDate>Sat, 04 Jul 2026 16:00:56 GMT</pubDate><description>방송 채팅 데이터로 하이라이트를 찾아내는 도구를 만들면서 부딪힌 문제들과 해결 과정, 그리고 한 번의 틀린 가설에 대한 기록이다.</description></item><item><title>채팅은 알고 있었다 - PokeClip 파이프라인을 갈아엎은 기록 (v3→v4)</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-v3-to-v4-cascade/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-v3-to-v4-cascade/</guid><pubDate>Fri, 03 Jul 2026 07:30:00 GMT</pubDate><description>지난 글에서 PokéClip의 v3 아키텍처를 소개했다. 영상(YOLO)·음성(Whisper)·채팅 세 신호를 병렬로 분석하고, 둘 이상이 임계치를 넘으면 하이라이트로 판정하는 &quot;E 하이브리드&quot; 구조였다.</description></item><item><title>방송 시작부터 재생까지 — 가정으로 살펴보는 라이브 트랜스코딩 인프라</title><link>https://taeyun.blog/posts/tech-blurting/live-transcoding-infrastructure/</link><guid>https://taeyun.blog/posts/tech-blurting/live-transcoding-infrastructure/</guid><pubDate>Mon, 22 Jun 2026 06:38:47 GMT</pubDate><description>이 글은 가상의 라이브 파이프라인을 구성해 책임과 비용을 비교하는 학습 노트다. 처음부터 등장하는 6.2초는 단계별 시간을 임의로 배정한 예시이며, 치지직이나 다른 서비스에서 측정한 시작 지연이 아니다.</description></item><item><title>HLS와 DASH가 미디어 조각을 공유하는 방법 — CMAF</title><link>https://taeyun.blog/posts/tech-blurting/cmaf-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/cmaf-deep-dive/</guid><pubDate>Mon, 22 Jun 2026 02:15:31 GMT</pubDate><description>HLS와 DASH는 서로 다른 매니페스트를 사용한다. 그렇다고 항상 영상을 두 번 인코딩해야 하는 것은 아니다. 같은 압축 비트스트림을 다른 컨테이너로 포장할 수 있기 때문이다.</description></item><item><title>NVENC와 x264의 비용을 비교하려면 — GPU 트랜스코딩의 조건</title><link>https://taeyun.blog/posts/tech-blurting/nvenc-gpu-transcoding/</link><guid>https://taeyun.blog/posts/tech-blurting/nvenc-gpu-transcoding/</guid><pubDate>Sun, 21 Jun 2026 17:22:28 GMT</pubDate><description>NVENC의 비용을 x264와 비교하려면 같은 입력·출력 사다리·화질 목표에서 지속 처리량을 측정해야 한다. 동시 방송 1,000개와 5개 출력이 있다는 사실만으로 서버 대수를 결정할 수 없다. 5개 출력의 해상도와 처리 비용도 서로 다르다.</description></item><item><title>콘텐츠마다 다른 화질 사다리 — ABR Ladder 설계</title><link>https://taeyun.blog/posts/tech-blurting/abr-ladder-design/</link><guid>https://taeyun.blog/posts/tech-blurting/abr-ladder-design/</guid><pubDate>Sun, 21 Jun 2026 16:55:58 GMT</pubDate><description>ABR은 같은 콘텐츠를 여러 해상도·비트레이트로 준비해 재생 조건에 맞게 선택하는 방식이다. 코덱까지 나누면 출력 개수가 더 늘어난다. 그러나 “Netflix는 모든 영화를 50번 인코딩한다”는 고정 숫자를 뒷받침할 근거는 없어 제거했다.</description></item><item><title>코덱은 기술이 아니라 비즈니스 결정이다 — 시나리오/비용/디버깅 종합</title><link>https://taeyun.blog/posts/tech-blurting/codec-decision-and-debugging/</link><guid>https://taeyun.blog/posts/tech-blurting/codec-decision-and-debugging/</guid><pubDate>Sun, 21 Jun 2026 03:33:24 GMT</pubDate><description>지금까지 H.264, AAC, H.265, Opus, AV1, VP9까지 코덱 6개를 봤다. 각각의 압축 원리와 라이센스 구조를 알아도, 실무 질문은 결국 하나로 모인다.</description></item><item><title>FFmpeg로 읽는 라이브 미디어 파이프라인 — 입력부터 인코딩과 출력까지</title><link>https://taeyun.blog/posts/tech-blurting/ffmpeg-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/ffmpeg-deep-dive/</guid><pubDate>Sat, 20 Jun 2026 19:18:25 GMT</pubDate><description>치지직, Twitch, Netflix의 라이브/VOD 인프라를 뜯어보면 공통점이 있다. 모두 FFmpeg 위에서 굴러간다. 그것도 인프라만이 아니다.</description></item><item><title>AV1과 VP9 — 압축 기술과 로열티 프리 목표를 구분해서 보기</title><link>https://taeyun.blog/posts/tech-blurting/av1-vp9-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/av1-vp9-deep-dive/</guid><pubDate>Sat, 20 Jun 2026 13:54:28 GMT</pubDate><description>영상 코덱의 역사는 단순했다. ITU + ISO가 H.264 만들고, H.265 만들고. 모두 그걸 쓰면 됐다.</description></item><item><title>Discord 음성이 1초도 안 끊기는 비밀 — Opus</title><link>https://taeyun.blog/posts/tech-blurting/opus-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/opus-deep-dive/</guid><pubDate>Sat, 20 Jun 2026 06:25:34 GMT</pubDate><description>Discord 음성 채팅을 켜놓고 게임할 때, 통신사가 LTE 약전계에 진입해도 목소리가 거의 안 끊기는 경험. WhatsApp 보이스 메시지가 1990년대 모뎀 같은 인터넷에서도 들리는 경험. Zoom이 카페 와이파이에서도 화면은 깨져도 음성은 계속 들리는 경험.</description></item><item><title>H.265를 선택할 때 압축 효율만으로 부족한 이유 — 호환성과 HDR</title><link>https://taeyun.blog/posts/tech-blurting/h265-hdr-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/h265-hdr-deep-dive/</guid><pubDate>Sat, 20 Jun 2026 05:42:30 GMT</pubDate><description>H.265(HEVC)는 H.264보다 발전한 압축 도구를 제공한다. 실제 비트레이트 절감률과 인코딩 비용은 콘텐츠·설정·구현에 따라 달라진다. 보급률 1%나 항상 50% 절감처럼 단일 숫자로 일반화할 근거는 이 글에 없다.</description></item><item><title>영상 옆의 128kbps — AAC와 오디오 코덱을 따로 살펴야 하는 이유</title><link>https://taeyun.blog/posts/tech-blurting/aac-and-friends/</link><guid>https://taeyun.blog/posts/tech-blurting/aac-and-friends/</guid><pubDate>Sat, 20 Jun 2026 01:44:52 GMT</pubDate><description>영상 6Mbps와 오디오 128kbps를 가정하면 오디오 비중은 128 ÷ (6000 + 128) × 100 ≈ 2.09%다. 오버헤드를 제외한 예시이며, 고정적인 5%가 아니다.</description></item><item><title>373MB/s에서 6Mbps로 — 조건을 명시하고 이해하는 H.264 압축</title><link>https://taeyun.blog/posts/tech-blurting/h264-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/h264-deep-dive/</guid><pubDate>Sat, 20 Jun 2026 01:38:55 GMT</pubDate><description>1080p 60fps를 RGB 8비트 × 3채널, 패딩 없는 raw 영상으로 계산하면 1920 × 1080 × 3 × 60 = 373,248,000바이트/초, 즉 373.248MB/s다. 1시간은 약 1.344TB다. 여기서 MB·TB는 10진 단위다.</description></item><item><title>RTMP를 IETF가 끝내려고 하는 중 — WHIP/WHEP</title><link>https://taeyun.blog/posts/tech-blurting/whip-whep-modern-ingest/</link><guid>https://taeyun.blog/posts/tech-blurting/whip-whep-modern-ingest/</guid><pubDate>Sat, 20 Jun 2026 01:12:18 GMT</pubDate><description>[지난 시리즈](../rtmp-still-alive/)에서 RTMP가 20년이 지나도 안 죽는 이유를 봤다. 도입 비용 0, 호환성 100%, 생태계 관성.</description></item><item><title>Google이 Skype 독점을 깨려고 만든 — WebRTC</title><link>https://taeyun.blog/posts/tech-blurting/webrtc-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/webrtc-deep-dive/</guid><pubDate>Sat, 20 Jun 2026 01:04:12 GMT</pubDate><description>2010년만 해도 화상 통화는 무조건 별도 프로그램 설치가 필요했다. Skype, MSN Messenger, 시스코의 WebEx. 브라우저에서 카메라/마이크에 접근할 방법이 없었다. 자체 P2P 프로토콜은 폐쇄적이었고, 기업이 가입자를 가두는 도구였다.</description></item><item><title>방송사들이 인터넷으로 송출할 때 쓰는 비밀병기 — SRT</title><link>https://taeyun.blog/posts/tech-blurting/srt-broadcaster-protocol/</link><guid>https://taeyun.blog/posts/tech-blurting/srt-broadcaster-protocol/</guid><pubDate>Sat, 20 Jun 2026 00:28:59 GMT</pubDate><description>올림픽이나 월드컵 중계를 보면 현장 카메라 → 본사 → 시청자로 신호가 흐른다. 옛날엔 위성/전용선이었다. 한 번 깔면 안정적이지만 한 번 쏘는 데 수천만 원.</description></item><item><title>HLS의 25초 지연을 2초로 — LL-HLS는 무엇을 바꿨나</title><link>https://taeyun.blog/posts/tech-blurting/ll-hls-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/ll-hls-deep-dive/</guid><pubDate>Sat, 20 Jun 2026 00:20:35 GMT</pubDate><description>라이브 방송을 보다가 채팅이 영상보다 빠른 경험, 게임 스포일러가 채팅으로 먼저 새는 경험, 다 해봤을 거다. 이게 일반 HLS의 18~25초 지연 때문이다.</description></item><item><title>DASH가 기술적으로 더 좋은데 왜 HLS가 이겼나</title><link>https://taeyun.blog/posts/tech-blurting/dash-vs-hls/</link><guid>https://taeyun.blog/posts/tech-blurting/dash-vs-hls/</guid><pubDate>Fri, 19 Jun 2026 19:17:40 GMT</pubDate><description>기술 표준의 역사에서 자주 보이는 패턴이 있다. 기술적으로 더 우수한 게 시장에서 진다.</description></item><item><title>라이브 영상이 그냥 파일이라고? — HLS의 미친 발상</title><link>https://taeyun.blog/posts/tech-blurting/hls-just-files/</link><guid>https://taeyun.blog/posts/tech-blurting/hls-just-files/</guid><pubDate>Fri, 19 Jun 2026 19:06:03 GMT</pubDate><description>2009년 Apple이 한 결정이 라이브 스트리밍의 모든 걸 바꿨다.</description></item><item><title>Flash는 2020년에 죽었는데 RTMP는 왜 안 죽나</title><link>https://taeyun.blog/posts/tech-blurting/rtmp-still-alive/</link><guid>https://taeyun.blog/posts/tech-blurting/rtmp-still-alive/</guid><pubDate>Fri, 19 Jun 2026 18:09:07 GMT</pubDate><description>OBS 켜본 사람은 다 알 거다. 방송 설정에 들어가면 &quot;서버&quot;와 &quot;스트림 키&quot;를 입력하라고 한다. 그 서버 주소가 rtmp://로 시작한다.</description></item><item><title>시청자 수와 비트레이트로 계산하는 CDN 전송량과 비용</title><link>https://taeyun.blog/posts/tech-blurting/cdn-for-live-streaming/</link><guid>https://taeyun.blog/posts/tech-blurting/cdn-for-live-streaming/</guid><pubDate>Fri, 19 Jun 2026 17:36:58 GMT</pubDate><description>라이브 CDN의 전송량은 평균 동시 시청자 수, 비트레이트, 시간으로 추산할 수 있다. 청구 금액에는 실제 계약 단가와 과금 조건이 더 필요하다.</description></item><item><title>버퍼링은 왜 생기나 — TCP HoL Blocking부터 Origin Shield까지</title><link>https://taeyun.blog/posts/tech-blurting/buffering-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/buffering-deep-dive/</guid><pubDate>Sun, 14 Jun 2026 06:01:19 GMT</pubDate><description>&quot;왜 갑자기 영상이 멈추지?&quot;</description></item><item><title>화질이 좋다는 건 정확히 무슨 뜻인가 — 해상도, 비트레이트, ABR</title><link>https://taeyun.blog/posts/tech-blurting/video-quality-bitrate-abr/</link><guid>https://taeyun.blog/posts/tech-blurting/video-quality-bitrate-abr/</guid><pubDate>Sun, 14 Jun 2026 01:40:52 GMT</pubDate><description>&quot;이 영상 1080p인데 왜 깨져 보이지?&quot;</description></item><item><title>1080p 영상의 데이터량부터 다시 계산하기 — 스트리밍의 기초 4가지</title><link>https://taeyun.blog/posts/tech-blurting/streaming-basics-from-scratch/</link><guid>https://taeyun.blog/posts/tech-blurting/streaming-basics-from-scratch/</guid><pubDate>Sun, 14 Jun 2026 01:11:10 GMT</pubDate><description>치지직 입사를 목표로 스트리밍 기술을 공부 중이다. HLS, WebRTC 같은 프로토콜부터 본 게 아니라 더 아래 — &quot;동영상이 도대체 뭐길래 압축이 필요한가&quot;, &quot;TCP는 왜 라이브에 안 맞나&quot; 같은 기초부터 다시 정리했다.</description></item><item><title>치지직 하이라이트 자동 추출 파이프라인 설계기 - PokeClip</title><link>https://taeyun.blog/posts/0-to-1/pokeclip-architecture/</link><guid>https://taeyun.blog/posts/0-to-1/pokeclip-architecture/</guid><pubDate>Fri, 12 Jun 2026 15:52:51 GMT</pubDate><description>라이브 방송에서 하이라이트 클립을 자동으로 뽑아내는 시스템을 만들었다. 치지직 스트림을 실시간으로 받아서 재밌는 순간을 감지하고, 클립으로 저장하는 파이프라인이다.</description></item><item><title>RTMP, MPEG-TS, SRT - 직접 짜면서 이해한 것들</title><link>https://taeyun.blog/posts/tech-blurting/rtmp-mpeg-ts-srt/</link><guid>https://taeyun.blog/posts/tech-blurting/rtmp-mpeg-ts-srt/</guid><pubDate>Fri, 12 Jun 2026 15:36:41 GMT</pubDate><description>치지직 스트림에서 오디오를 분리해서 분석하는 파이프라인을 짜야 했다. 처음엔 HLS로 받으면 되는 거 아닌가 싶었는데, 알고 보니 완전히 다른 문제였다.</description></item><item><title>6개월 후 내 이력서에 있을 것들 — 미디어 백엔드 편</title><link>https://taeyun.blog/posts/0-to-1/soma-k1-6month-goals/</link><guid>https://taeyun.blog/posts/0-to-1/soma-k1-6month-goals/</guid><pubDate>Tue, 02 Jun 2026 12:35:59 GMT</pubDate><description>--- 이력서</description></item><item><title>클린 아키텍처 — 로버트 C. 마틴</title><link>https://taeyun.blog/posts/book-review/clean-architecture-review/</link><guid>https://taeyun.blog/posts/book-review/clean-architecture-review/</guid><pubDate>Sun, 31 May 2026 09:27:00 GMT</pubDate><description>![클린 아키텍처 표지](/images/clean-architecture-cover.jpg)</description></item><item><title>HLS 완전 정복 — 치지직 입사 수준으로</title><link>https://taeyun.blog/posts/tech-blurting/hls-deep-dive/</link><guid>https://taeyun.blog/posts/tech-blurting/hls-deep-dive/</guid><pubDate>Fri, 29 May 2026 15:00:00 GMT</pubDate><description>2009년 애플이 만들었다. 당시 웹 영상 재생은 Flash 기반이었는데 아이폰에 Flash가 없었다. 그래서 Flash 없이 HTTP만으로 스트리밍할 수 있는 방법으로 만든 게 HLS다.</description></item><item><title>GitHub Pages 블로그 자동화 시스템 고도화 보고서</title><link>https://taeyun.blog/posts/0-to-1/blog-improvement-report/</link><guid>https://taeyun.blog/posts/0-to-1/blog-improvement-report/</guid><pubDate>Wed, 20 May 2026 09:00:00 GMT</pubDate><description>본 문서는 GitHub Pages 블로그 자동화 시스템 초기 구축 이후 진행된 기능 고도화 작업에 대한 회고 보고서이다. 성공적으로 구현된 기능뿐 아니라 시도하였으나 실패하거나 한계에 부딪힌 사례도 함께 기록하여, 실제 개발 과정을 있는 그대로 남긴다.</description></item><item><title>GitHub Pages 블로그 자동화 구축기</title><link>https://taeyun.blog/posts/0-to-1/github-pages-blog-automation/</link><guid>https://taeyun.blog/posts/0-to-1/github-pages-blog-automation/</guid><pubDate>Wed, 20 May 2026 01:00:00 GMT</pubDate><description>- - -</description></item><item><title>Kafka 핵심 개념 기술 피드백</title><link>https://taeyun.blog/posts/tech-blurting/kafka-core-concepts-technical-review/</link><guid>https://taeyun.blog/posts/tech-blurting/kafka-core-concepts-technical-review/</guid><pubDate>Mon, 18 May 2026 01:00:00 GMT</pubDate><description>카프카란 대용량 이벤트 처리 시스템 디스크에 순차적으로 저장하기 때문에 속도가 빠름 비동기 처리 백에서 작동 직접적으로 클라이언트와 소통하지 않음 이녀석의 역할을 단순히 데이터를 저장하는 역할 jvm에 접근하지 않고 os cache page를 사용하기 때문에 속도가 빠름 실시간성이 강함 메세지 묶음 처리 그러나 용도…</description></item></channel></rss>