<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://kth4778.github.io/</id><title>BigTae's Dev Log</title><subtitle>개발자로 성장하며 마주한 고민, 선택, 해결 과정을 기록합니다.</subtitle> <updated>2026-06-05T01:58:09+09:00</updated> <author> <name>TaeHyeon Kim</name> <uri>https://kth4778.github.io/</uri> </author><link rel="self" type="application/atom+xml" href="https://kth4778.github.io/feed.xml"/><link rel="alternate" type="text/html" hreflang="ko" href="https://kth4778.github.io/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 TaeHyeon Kim </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>DASH — 유튜브가 LLHLS 대신 선택한 이유</title><link href="https://kth4778.github.io/posts/dash-streaming-protocol/" rel="alternate" type="text/html" title="DASH — 유튜브가 LLHLS 대신 선택한 이유" /><published>2026-06-05T10:00:00+09:00</published> <updated>2026-06-05T10:00:00+09:00</updated> <id>https://kth4778.github.io/posts/dash-streaming-protocol/</id> <content type="text/html" src="https://kth4778.github.io/posts/dash-streaming-protocol/" /> <author> <name>TaeHyeon Kim</name> </author> <category term="백엔드" /> <category term="스트리밍" /> <summary>지난번에 HLS랑 LLHLS를 정리했는데, 쓰면서 계속 걸리는 게 있었다. 치지직은 LLHLS를 쓴다고 배웠는데, 그럼 유튜브는? 유튜브도 같은 방식으로 영상 쪼개서 보내는 거 맞는데, 확인해보니 .mpd 라는 파일이 나왔다. HLS랑 다른 방식이었다. 이게 DASH다. DASH가 왜 생겼나 HLS는 애플이 2009년에 만들었다. 처음엔 라이선스 조건이 있었고, 구글이나 넷플릭스 입장에선 애플한테 의존하는 게 껄끄러웠을 거다. 그래서 2012년에 구글, 넷플릭스, 마이크로소프트 등이 모여서 ISO 국제 표준으로 DASH를 만들었다. 공식 명칭은 MPEG-DASH고, 로열티 없이 누구나 쓸 수 있다. 출발점부터 목적이 달랐다. HLS는 아이폰에서 잘 돌아가게, DASH는 특정 회사에 종속되지...</summary> </entry> <entry><title>이력서 5줄을 완성하기까지 — SW마에스트로 17기 개발 일지</title><link href="https://kth4778.github.io/posts/soma17-dev-log/" rel="alternate" type="text/html" title="이력서 5줄을 완성하기까지 — SW마에스트로 17기 개발 일지" /><published>2026-06-03T00:00:00+09:00</published> <updated>2026-06-03T00:00:00+09:00</updated> <id>https://kth4778.github.io/posts/soma17-dev-log/</id> <content type="text/html" src="https://kth4778.github.io/posts/soma17-dev-log/" /> <author> <name>TaeHyeon Kim</name> </author> <category term="SW마에스트로" /> <summary>AI 기반 라이브 스트리밍 하이라이트 자동 클립 추출 및 태깅 시스템 SW마에스트로 17기 실시간·이벤트 처리 백엔드 개발자 2026.05 ~ 6개월 뒤 이 5줄을 면접에서 30초 안에 말할 수 있는 상태가 목표다. 매달 마지막 주에 진척을 기록한다. 목표 — 이력서 5줄 공식 API socket.io 기반 동시 100채널 채팅 수집 — 1,000 msg/s 처리량에서 p95 지연 200ms 유지 Kafka 파티셔닝·키 설계로 컨슈머 그룹 6개 운영, 메시지 유실 0건 + idempotency-key 기반 중복 처리 차단 EWMA·CUSUM·z-score 3종 비교 후 채팅 폭발 감지 알고리즘 적용 — FP 30% ...</summary> </entry> <entry><title>팩토리 패턴 + 전략 패턴 — 만드는 책임과 동작하는 책임을 나누다</title><link href="https://kth4778.github.io/posts/factory-strategy-pattern/" rel="alternate" type="text/html" title="팩토리 패턴 + 전략 패턴 — 만드는 책임과 동작하는 책임을 나누다" /><published>2026-06-01T00:00:00+09:00</published> <updated>2026-06-01T00:00:00+09:00</updated> <id>https://kth4778.github.io/posts/factory-strategy-pattern/</id> <content type="text/html" src="https://kth4778.github.io/posts/factory-strategy-pattern/" /> <author> <name>TaeHyeon Kim</name> </author> <category term="책 Log" /> <category term="면접을 위한 CS 전공지식 노트" /> <category term="팩토리·전략 패턴" /> <summary>싱글톤 패턴에 이어 팩토리 패턴과 전략 패턴을 공부했다. 이 두 패턴은 따로 배웠는데 쓰다 보면 같이 쓰는 경우가 많다는 게 흥미로웠다. 팩토리 패턴 — 객체 생성을 공장에 맡기다 결제 시스템을 만든다고 해보자. 카카오페이, 네이버페이, 신용카드 세 가지 방법이 있다. if (type.equals("kakao")) { payment = new KakaoPayment(); } else if (type.equals("naver")) { payment = new NaverPayment(); } else if (type.equals("card")) { payment = new CardPayment(); } 나중에 토스페이가 추가되면? 이 if-else가 코드 여러 곳에 퍼져있...</summary> </entry> <entry><title>싱글톤 패턴 — 왜 인스턴스는 딱 하나여야 할까</title><link href="https://kth4778.github.io/posts/singleton-pattern/" rel="alternate" type="text/html" title="싱글톤 패턴 — 왜 인스턴스는 딱 하나여야 할까" /><published>2026-05-31T00:00:00+09:00</published> <updated>2026-06-01T01:01:04+09:00</updated> <id>https://kth4778.github.io/posts/singleton-pattern/</id> <content type="text/html" src="https://kth4778.github.io/posts/singleton-pattern/" /> <author> <name>TaeHyeon Kim</name> </author> <category term="책 Log" /> <category term="면접을 위한 CS 전공지식 노트" /> <category term="싱글톤 패턴" /> <summary>CS 전공지식 노트를 읽기 시작했다. 1장 첫 번째 주제가 싱글톤 패턴이었는데, 사실 이름은 많이 들어봤지만 제대로 설명해보라고 하면 자신 없었다. 하나만 있어야 하는 것들 게임에서 소리를 담당하는 객체가 두 개라면 어떻게 될까. 볼륨을 낮춰도 한쪽은 여전히 시끄럽다. DB 커넥션 풀이 두 개라면 각자 따로 연결을 맺으니 비용이 두 배다. “앱 전체에서 딱 하나만 있어야 하는 것”에 쓰는 게 싱글톤 패턴이다. 구조는 단순하다. 세 가지만 기억하면 된다. 생성자를 private으로 막아서 외부에서 new를 못 하게 하고, 클래스 내부에 자기 자신을 static 변수로 들고 있고, getInstance() 메서드 하나로만 접근하게 한다. public class Singleton { pr...</summary> </entry> <entry><title>당근 기술 블로그 — 처음 살펴본 서킷 브레이커와 SLA</title><link href="https://kth4778.github.io/posts/karrot-feed-stability-article-review/" rel="alternate" type="text/html" title="당근 기술 블로그 — 처음 살펴본 서킷 브레이커와 SLA" /><published>2026-05-28T00:00:00+09:00</published> <updated>2026-06-05T01:51:30+09:00</updated> <id>https://kth4778.github.io/posts/karrot-feed-stability-article-review/</id> <content type="text/html" src="https://kth4778.github.io/posts/karrot-feed-stability-article-review/" /> <author> <name>TaeHyeon Kim</name> </author> <category term="백엔드" /> <category term="시스템 설계" /> <summary>멘토님이 당근 기술 블로그 링크를 보내주셨다. 피드시스템 안정성 향상기인데, 읽으면서 이름만 들어봤던 개념들이 실제로 어떻게 쓰이는지 처음 감이 왔다. 연쇄 장애 — 하나가 죽으면 왜 전체가 죽나 당근 피드에는 동네생활, 중고거래, 구인공고, 중고차, 부동산 등 여러 마이크로서비스가 붙어있다. 사용자가 피드를 열면 이 서비스들한테 동시에 요청해서 결과를 조합해 보여준다. 문제는 중고거래 서비스 하나가 느려지기 시작하면 피드 서비스가 응답을 기다리면서 스레드를 계속 점유한다는 거다. 요청이 쌓이고, 결국 피드 서비스도 같이 터진다. 중고거래 서비스 응답 지연 → 피드 서비스 스레드 점유 → 다른 사용자 요청도 대기 → 피드 서비스 전체 마비 이걸 연쇄 장애(Cascading ...</summary> </entry> </feed>
