Technical Blog

기술 인사이트

실시간 통신, 미디어 처리, AI 통합에 대한 심층 분석.Agora SDK를 중심으로 프로덕션 레벨의 구현을 다룹니다.

53
포스트
7
카테고리

primary 카테고리 또는 태그로 Backend에 속한 글을 모두 표시합니다.

Backend
·24분 읽기

SSL 인증서 완전 이해 가이드 — 만료·갱신 책임·DNS-01·CNAME 자동화

인증서 만료 6일 전 알림을 받았다면 무엇부터 확인해야 할까요? TLS 인증서가 일부러 만료되도록 설계된 이유부터 서비스 제공자가 Not After를 감지하는 방식, 고객 직접 제공과 관리형 인증서의 책임 경계, DNS-01에서 CNAME의 HOST와 VALUE가 맡는 역할까지 시각적인 흐름으로 정리합니다. 실고객 주소 대신 live.frank.example 가상 도메인으로 Cloudflare·Route 53 설정, dig·openssl 검증, CAA와 기존 TXT 충돌 같은 자동 갱신 실패 원인까지 실무 체크리스트로 설명합니다.

SSLTLS인증서ACME+6
Telephonyvia Backend
·30분 읽기

VoIP 푸시 인프라 완전 가이드 — APNs · PushKit · CallKit · Agora 통합 구현

"통화용 푸시 토큰은 일반 알림 토큰이랑 같은 거 아닌가요? 인증서는 왜 두 개나 받으라는 거죠?" RTC를 도입하는 고객이 가장 자주 던지는 질문입니다. 이 글은 PushKit이 별도 시스템이 아니라 APNs 위에서 도는 특수 모드라는 핵심을 짚으면서, 일반 푸시와 VoIP 푸시가 인증서, 토큰, 페이로드, 처리 방식까지 왜 갈라지는지 풀어냅니다. PushKit 등록부터 CallKit과 Agora RTC를 묶는 통합 코드, 그리고 자체 구축과 Agora Chat 매니지드 중 무엇을 골라야 하는지까지 실무 기준으로 정리했습니다.

iOSPushKitAPNsVoIP+5
Backend
·18분 읽기

TTFB 분해 — DNS / TCP / TLS / 서버 처리, 어디서 350ms가 새는가

"TTFB는 350ms인데 ping은 7ms입니다. 서버가 느린 건가요?" 답하려면 TTFB가 서버 처리 시간이 아니라는 사실부터 짚어야 합니다. 이 글은 요청부터 첫 바이트가 도착하기까지를 DNS 조회, TCP 핸드셰이크, TLS 협상, 서버 처리 네 단계로 분해하고, curl 한 줄로 각 구간 비용을 측정해 350ms가 실제로 어디서 새는지 찾아냅니다. ping 값에 따라 병목이 서버인지 네트워크인지 DNS 콜드 스타트인지 가려내는 진단법과 단계별 처방까지 정리했습니다.

TTFBDNSTCPTLS+5
Backend
·15분 읽기

Cloud Recording 점프 재생 무한 로딩 — moov / ENDLIST / DISCONTINUITY 트러블슈팅

다운로드는 다 끝났는데 영상을 중간으로 점프하면 무한 로딩이 걸리거나 아예 재생이 안 됩니다. 알고 보면 데이터가 손상된 게 아니라 인덱스가 불완전한 경우가 대부분입니다. 이 글은 MP4의 moov atom 위치, HLS의 ENDLIST 누락, 그리고 DISCONTINUITY 누락이라는 세 가지 패턴을 진단하는 법과 ffmpeg으로 고치는 처방을 정리하고, Agora Cloud Recording 결과물에 바로 쓸 수 있는 후처리 파이프라인까지 안내합니다.

Cloud RecordingMP4HLSmoov+5
Backend
·10분 읽기

TTS 서버 파이프라인 해부 — Google TTS → R2 캐시 → 브라우저 재생

같은 문장을 100번 읽어줘도 Google TTS 요금이 1회분만 나오게 하려면 어떻게 설계해야 할까? 이 글은 텍스트를 음성으로 바꾸는 서버 API의 내부를 코드와 함께 따라간다. 입력값을 SHA-256 해시로 묶어 중복을 막고, R2 대신 DB로 캐시를 조회해 응답을 50배 빠르게 만들며, await를 떼어내 업로드를 백그라운드로 넘기는 트릭까지 읽고 나면, 작은 오디오 요청 하나가 비용과 속도를 동시에 챙기는 구조가 손에 잡힌다.

TTSR2캐시Base64
Backend시리즈
·15분 읽기

FFmpeg 실전 파이프라인 — Agora 녹화에서 프로덕션 VOD까지

Individual 모드로 녹화하면 S3에는 유저별로 쪼개진 m3u8과 수백 개의 ts 세그먼트만 쌓일 뿐, 바로 보여줄 VOD는 없습니다. 이 글은 그 원자재를 프로덕션 다시보기로 만드는 전 과정을 따라갑니다. m3u8을 MP4로 무손실 변환하고, 파일명에 박힌 UTC 타임스탬프로 유저들의 입장 시점을 맞추고, 여러 화면을 하나의 그리드로 합성한 뒤 CRF와 2-pass로 품질을 조율하는 FFmpeg 명령을 하나씩 풀어냅니다. 마지막에는 S3에서 받아 CDN으로 올리는 자동화 스크립트와, 언제 Mix 대신 Individual이 경제적인지까지 짚습니다.

FFmpegCloud Recordingfilter_complexCRF+1
Backend시리즈
·14분 읽기

FFmpeg, 미디어의 스위스 아미 나이프 — 컨테이너, 코덱, 스트림

녹화 파일이 만들어진 뒤 사용자에게 닿기까지, TS를 MP4로 바꾸고 트랙을 합치고 구간을 자르는 후처리의 한복판에는 늘 FFmpeg이 있다. 이 글은 컨테이너와 코덱, 스트림이라는 세 개념으로 FFmpeg을 다시 정리하고, 왜 후처리의 대부분이 무손실 remux인 -c copy로 끝나는지, 트랜스코딩은 언제 꺼내야 하는지를 명령어 예시와 함께 풀어낸다. 디코딩부터 인코딩까지 내부 5단계가 어떻게 돌아가는지 알고 나면 에러 메시지도 옵션 조합도 한결 또렷해진다.

FFmpegCodecContainerMuxing+1
Mediavia Backend시리즈
·12분 읽기

M3U8과 TS 파일의 모든 것 — HLS Deep Dive

녹화 파일을 열었더니 MP4가 아니라 m3u8 파일 하나와 잘게 쪼개진 ts 조각들이 나옵니다. 왜 이런 구조일까요? 답은 장애 내성에 있습니다. MP4는 재생에 필요한 메타데이터가 파일 끝에 몰려 있어 서버가 중간에 죽으면 녹화 전체를 잃지만, HLS는 영상을 짧은 세그먼트로 쪼개 저장하므로 이미 완성된 조각은 살아남습니다. 이 글에서는 그 차이가 생기는 원리부터 TS 패킷 구조, M3U8 태그 해석, 세그먼트를 I-frame에서 자르는 이유, Agora의 슬라이싱 규칙까지 실무에서 녹화 파일을 다룰 때 알아야 할 내용을 정리합니다.

HLSM3U8TSI-frame+1
Mediavia Backend시리즈
·12분 읽기

녹화 모드 해부 — Individual, Mix, Web의 내부 파이프라인

같은 채널을 녹화해도 Individual, Mix, Web 중 무엇을 고르느냐에 따라 서버 안에서 벌어지는 일이 완전히 달라집니다. 출력 파일 구조부터 CPU 부하, 비용까지 모두 이 선택 시점에 결정되기 때문입니다. 각 모드가 스트림을 어떻게 처리하는지, 오디오 믹싱과 비디오 합성이 내부적으로 어떤 연산을 거치는지, 그리고 헤드리스 브라우저로 화면을 캡처하는 Web 모드가 왜 가장 무거운지를 짚어 봅니다. 어떤 상황에 어떤 모드를 골라야 하는지 판단 기준까지 정리합니다.

Cloud RecordingIndividualMixWeb+1
Backend시리즈
·8분 읽기

내 서버에서 직접 녹화한다면 — On-Premise vs Cloud Recording

"데이터가 반드시 우리 서버에 있어야 합니다." 이 한 마디가 나오는 순간, 편리한 Cloud Recording은 선택지에서 빠집니다. 규제 산업이나 영상 프레임을 실시간 AI로 분석해야 하는 상황이라면, 녹화 파일이 외부 클라우드를 거치는 구조 자체가 문제가 되기 때문입니다. 이 글은 자체 Linux 서버에 Native SDK를 설치하는 On-Premise Recording이 Cloud와 어떻게 다른지, YUV 프레임과 PCM 샘플에 직접 접근해 실시간 AI 파이프라인을 어떻게 구성하는지, 그리고 운영 부담을 감수하고서라도 On-Premise를 골라야 하는 기준은 무엇인지 정리합니다.

On-Premise RecordingCloud RecordingYUVRaw Data+1
Backend시리즈
·10분 읽기

실시간 통화, 왜 녹화해야 하는가 — Cloud Recording Architecture

통화가 끝나면 대화는 그냥 사라집니다. WebRTC는 본질적으로 일시적이라 미디어가 흐르고 연결이 끊기면 그걸로 끝이죠. 하지만 금융 상담 기록 제출, 과외 수업 다시보기, 원격 진료 기록 연동처럼 통화가 사라지면 안 되는 상황은 점점 많아집니다. 이 글은 왜 브라우저 직접 녹화로는 부족한지, Agora Cloud Recording이 유령 참가자 패턴으로 어떻게 채널에 몰래 들어와 녹화하는지, acquire부터 stop까지 라이프사이클과 두 종류의 인증 키를 어떻게 다루는지 설명합니다.

Cloud RecordingGhost ParticipantSD-RTNREST API
Backend
·8분 읽기

Cloud Recording 녹화 파일은 어떻게 저장되는가? — S3 실시간 업로드, 끊김 복구, 재생까지

상담 통화를 Agora Cloud Recording으로 녹화하면 그 파일은 S3에 정확히 언제, 어떻게 올라갈까요? 녹화 중에 TS 조각이 실시간으로 업로드되는 구조부터, 네트워크가 끊겼을 때 어떤 파일이 살아남고 무엇이 깨지는지, 30분 상담이면 MP4가 왜 하나로 끝나는지까지 짚어봅니다. 마지막에는 S3에 쌓인 녹음을 presigned URL로 안전하게 재생하는 실제 백엔드와 플레이어 코드까지 담았습니다.

Cloud RecordingS3HLSMP4+1
Backend
·6분 읽기

Cloud Recording으로 스트림 자동 녹화하기 (Backend)

사용자가 통화 도중 앱을 닫거나 네트워크가 끊기면 그동안 쌓인 녹화 데이터는 어떻게 될까요? 브라우저에서 직접 녹화하면 클라이언트 부하와 데이터 유실이라는 한계에 부딪힙니다. Agora Cloud Recording은 보이지 않는 가상 유저를 채널에 접속시켜 서버에서 스트림을 믹싱하고 S3 같은 클라우드 스토리지에 직접 저장하는 방식으로 이 문제를 풀어냅니다. acquire에서 start, stop으로 이어지는 REST API 흐름과 mix·individual·web 세 가지 녹화 모드의 쓰임새까지 정리했습니다.

Cloud RecordingREST APICSPAWS S3

© 2026 Frank Kim. All rights reserved.