개요 저번 글을 작성하던 중 배포 방식을 검토하다가 개선점이 보이더군요. 현재는 수동 배포로 버전 업데이트마다 SSH(Secure Shell)로 EC2(Elastic Compute Cloud)에 접근하여 이미지를 빌드하고 실행하는 방식을 하고 있었습니다. 저번 글에서는 스팟 인스턴스를 추가함으로써 API 서버의 사양을 줄이는 것을 목표로 하고 있었는데, 이런 식으로 서버에서 이미지를 빌드한다면 필연적으로 빌드 과정을 감당할 정도의 메모리 공간이 추가로 필요하다는 점입니다. 관련해서 찾아보니 AWS 서비스 중에 이미지를 저장하는 ECR(Elastic Container Registry) 기능이 있는 것을 확인했습니다. 이걸로 이미지를 ECR에 올리고 서버는 이 이미지를 pull하기만 하면 기존에 빌드로 발생하던 1GB~2GB의 저장 공간을 줄일 수 있을 겁니다. ...

개요 현재까지 다음과 같이 비용이 지출되고 있습니다. 월간 총 지출: $43.69 (6월 22일까지), 일일 3달러가 소비되고 있죠. 현재 서버의 인스턴스 유형이 m7i-flex.large인 점이 가장 큰 이유이죠. 하지만 인코딩 작업을 돌리려면 서버 PC의 사양이 어느 정도 따라줘야 했고, AWS에서 크레딧으로 접근할 수 있는 가장 좋은 서버 사양이 해당하는 것이었기에 이를 선택한 이유가 되었죠. 하지만 이대로 가면 한 달에 90달러, 대략 14만 원이 소비되게 됩니다. 이대로는 서버를 유지하는데 부담이 발생합니다. ...

개요 저번 회고에서 마지막에 언급했던 부분을 진행하려 합니다. 또한 현재는 원본 코덱과 관계없이 항상 transcode하도록 되어 있습니다. 이미 H.264/AAC인 영상은 -c copy로 패키징만 하도록 분기하면 인코딩 시간을 더 줄일 수 있으니 이 부분도 연구가 필요하죠 코덱을 기준으로 재인코딩 대신 기존 스트림을 그대로 쓰고 패키징만 하면 속도가 빨라지는 점은 쉽게 납득이 갔습니다. 다만 내부적으로 어떻게 다른지, 재인코딩 없이 패키징만 하면 되는 경우는 무엇이 다른지가 궁금했습니다. HLS 궁금증 HLS에서 H.264는 인코딩을 안 해도 되는 이유? H.264인지 아닌지는 크게 중요하지 않더군요. 실제 기준은 타깃 플레이어 지원 범위와 HLS authoring 조건을 원본이 이미 만족하는지가 인코딩 여부를 정합니다. 관련 사양은 Apple 문서와 RFC에서 정리해 두고 있습니다. ...

개요 지난 글이 6월 9일에 적었으니 8일 만에 진행 사항을 정리하게 되네요. 확장할 기능에 대해서 다음처럼 정리를 했죠. 개발 예정인 기능이 아직 많습니다. 실질적으로 사용자에게 가장 큰 변화를 주는 기능을 먼저 구현할 예정입니다. - 업로드가 아닌 유튜브 링크를 통한 공유 - 자유 게시판 그 후에는 테스트와 고도화를 병행할 생각이지만, 무엇보다 비용 절감에 초점을 둘 예정이죠. 고도화에서는 아래 영역에 대해서 작업이 필요하죠. - HLS 세그먼트 다수 업로드: `.ts`마다 S3 PutObject가 늘어 요청 비용이 오르는 문제 해결 - 인코딩 서버 구현: ffmpeg를 쓰지 않고 직접 인코딩 구현해서 최적화 - 멀티파트 업로드로 바이트 단위 청크 전송을 최적화 - 디스크 문제: 로컬에 원본 파일과 인코딩 파일이 동시에 존재할 때도 괜찮은지 체크 - 배포 비용 절감의 필요 테스트 및 분석 영역 - 과부하 테스트 - 큰 파일이 들어왔을 때(GB 단위) - 보안 이슈 체크 결과적으로는 다음과 같이 정리되었습니다. ...

IP로 학원에 배포하며 테스트를 진행하던 중, 업로드 과정에서 다음과 같은 버그가 발생한 것을 확인했습니다. Job 테이블 데이터를 확인해 보니, 다음처럼 status는 failed이지만 completed_at 값이 존재해 서비스 프로세스상 예상한 데이터 상태가 아니었습니다. completed_at 값이 있다면 status는 completed여야 했습니다. id | status | course_name | error_message | created_at | updated_at | completed_at --------------------------------------+------------+-------------------------+-------------------------------------------------------------------------------------------------------+-------------------------------+-------------------------------+------------------------------- 29fc0ec8-8f54-43fc-8dc9-2c92d0e877e0 | failed | 배열 | An error occurred (NoSuchKey) when calling the GetObject operation: The specified key does not exist. | 2026-06-15 08:39:37.532818+00 | 2026-06-15 14:32:11.78985+00 | 2026-06-15 12:31:10.671766+00 0e460663-1de7-4813-a128-5895d3265d70 | processing | DDL - 2 | | 2026-06-15 08:38:17.577126+00 | 2026-06-15 12:31:10.869183+00 | 76dcdfc5-54a6-46da-88c8-093ec68b34f6 | completed | DDL | | 2026-06-15 08:26:43.584661+00 | 2026-06-15 10:13:57.687732+00 | 2026-06-15 10:13:57.687653+00 3eff8d62-19cb-4de4-a282-127bc4b3130f | failed | Limit | An error occurred (NoSuchKey) when calling the GetObject operation: The specified key does not exist. | 2026-06-15 08:18:12.511962+00 | 2026-06-15 14:32:11.914926+00 | 2026-06-15 09:22:42.636486+00 da51db02-dec2-4c48-98eb-3f1ce814360a | completed | Sub Query 연습문제 풀이 | | 2026-06-15 08:14:15.792211+00 | 2026-06-15 09:20:24.200712+00 | 2026-06-15 09:20:24.200621+00 7274d1d0-cb3b-4968-b2be-b1a3fecadc81 | completed | test | | 2026-06-13 13:14:25.077061+00 | 2026-06-13 13:24:46.968948+00 | 2026-06-13 13:24:46.968876+00 174733b5-1daf-45a1-8917-418512249c99 | completed | 업로드 테스트 | | 2026-06-13 12:54:14.423268+00 | 2026-06-13 13:04:50.440667+00 | 2026-06-13 13:04:50.440582+00 42c62df1-1a68-4df5-8596-a2ef0cc83987 | completed | Sub Query | | 2026-06-12 07:21:23.330349+00 | 2026-06-12 08:02:24.979543+00 | 2026-06-12 08:02:24.979464+00 c63f7271-8b41-4524-a91b-f8838b25aec5 | completed | Join | | 2026-06-12 03:16:45.313736+00 | 2026-06-12 04:16:24.737723+00 | 2026-06-12 04:16:24.737644+00 75341055-d81f-418b-98ef-8d8dd33ddc19 | completed | 반복문 | | 2026-06-11 06:58:51.113466+00 | 2026-06-11 07:25:07.850604+00 | 2026-06-11 07:25:07.850508+00 문제 1: status와 completed_at 조합 Celery가 실패 시 run_publish_job을 재시도하도록 다음처럼 코드가 되어 있으므로, 이와 관련된 버그로 방향을 잡았습니다. ...

FFmpeg FFmpeg is the leading multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything that humans and machines have created FFmpeg는 인간과 기계가 만들어낸 거의 모든 것을 디코딩/인코딩, 트랜스코딩, 먹스/디먹스, 스트림, 필터링 및 재생할 수 있는 선도적인 멀티미디어 프레임워크입니다. FFmpeg about 동영상 편집에서 FFmpeg는 오픈소스로 이루어진 표준 프로그램입니다. 동영상 관련 프로그램을 만들면 꼭 FFmpeg가 끼게 되더군요. 이번에 만드는 사이트 최적화를 위해 테스트와 벤치마크를 진행했으며, 그 과정을 정리합니다. ...

개요 1차 MVP는 현재 학원 내에서 배포 중이며, 도메인 연결 후 공유할 예정입니다. 슬슬 머릿속에는 있지만 말로는 정리가 안 되는 단계에 닿은 것 같아 글로 정리합니다. Anime Search에서의 한계 지난번에 진행했던 Anime Search Project에서 장면 검색 RAG까지 구현하며 결과적으로 마음에 들지 않았던 점은, 어디까지나 기술적 호기심 해결로 끝났다는 점이었습니다. 해당 글에서도 마지막에 다음과 같이 정리했죠. 위 파이프라인까지 구현해 6장 초반 화면처럼 자연어 검색이 동작합니다. 다만 아직 부족한 점도 있고, 실용성이 떨어지는 부분도 몇 군데 보였습니다. ...

HLS and ABR HLS(HTTP Live Streaming)는 HTTP로 .m3u8, .m3u 플레이리스트와 짧은 미디어 세그먼트를 주고받으며 영상을 이어 재생하는 방식입니다. 네트워크나 기기 상황에 맞춰 ABR(Adaptive Bitrate, 적응형 비트레이트)로 화질(Variant)을 바꿔 끊김을 줄입니다. 애플에서 개발한 HTTP 기반 스트리밍 방식으로 애플 사이트에서 가이드라인을 참고할 수도 있습니다. 인코딩을 구분하면 다음과 같습니다. CBR(Constant Bit Rate): 구간마다 비트레이트가 거의 일정한 인코딩 VBR(Variable Bit Rate): 장면 복잡도에 따라 비트레이트가 달라지는 인코딩 ABR(Adaptive Bitrate): 서버가 여러 화질(Variant)을 제공하고, 클라이언트가 대역폭, 버퍼, CPU 등을 보고 그중 하나를 선택하고 전환하는 재생 방식 (HLS Master playlist와 연결) HLS는 ABR Streaming을 제공하는 프로토콜로 동영상 스트리밍에 가장 많이 쓰이는 방식 중 하나입니다. 이 문서(RFC 8216)는 HTTP 위에서 동작하는 미디어 전송 프로토콜(HLS)을 정의해 구현 간 상호 운용성을 맞춥니다. 이 프로토콜을 사용하면 클라이언트는 서버로부터 연속적인 미디어 스트림을 수신하여 표현할 수 있습니다. ...

1. 개요 애니메이션이나 드라마를 보실 때 내가 몇 화까지 본지는 기억이 안 나지만 특정 장면만 떠오를 때가 있습니다. 이 문제를 해결하기 위해 사용자가 원하는 장면이 나온 회차를 쉽게 찾을 수 있는 검색 시스템을 만들어 보려 합니다. 그래서 이번 글의 목적은 실제 서비스에서도 써 볼 수 있는 애니메이션 장면 검색 RAG 시스템을 구축하는 것입니다. 다음 챕터들로 만들어봅시다. 2. 멀티모달 임베딩에서는 모델 사용법을 익히고, 모델에 데이터를 넣어 결과를 받은 뒤 대략 시각화해 봅니다. 3. 대용량 전처리 파이프라인에서는 동영상 전처리 작업을 할 때 가장 빠른 옵션 값을 찾아봅시다. 4. 벡터 검색 엔진 구축 (Qdrant)에서는 모델에서 읽은 값을 벡터 DB에 적재합니다. 5. 비동기 시스템 구조 (Celery, Job Worker & Redis Queue)에서는 3·4장 파이프라인을 HTTP 밖으로 분리하고, Celery·Redis·Django(task queue)로 잡 구조를 잡습니다. 6. 자연어 검색에서는 Qdrant 검색 API·UI를 붙이고, 필요하면 LLM으로 결과를 정리합니다. 2. 멀티모달 임베딩 멀티모달 임베딩 공간(Multimodal Embedding Space) 은 텍스트, 이미지, 동영상 프레임 등 서로 다른 형태의 데이터(모달리티)를 하나의 통일된 다차원 벡터 공간에 매핑하는 기술입니다. ...

지금까지 동시성 프로그램을 스레드 기반 동시성만으로 구축하는 것이 유일한 방법인 것처럼 작성해왔습니다. 이는 당연히 전혀 사실과는 거리가 멀고, 여러 다른 스타일의 동시 프로그래밍이 있습니다. 이 스타일은 이벤트 기반 동시성으로 알려져 있으며 node.js와 같은 서버 측 프레임워크를 포함한 현대 시스템에서 인기를 얻고 있습니다. 그 뿌리는 아래에서 논의할 C/UNIX 시스템에 있습니다. node.js는 단일 스레드임에도 이벤트 루프와 비동기 I/O를 통해 non-blocking I/O 모델로 동작 C/UNIX 시스템은 1969년 미국 벨 연구소(Bell Labs)에서 개발된 UNIX 운영체제와, 이 운영체제를 작성하는 데 사용된 C 언어의 긴밀한 관계를 기반으로 하는 서버 및 워크스테이션용 운영체제 환경 이벤트 기반 동시성이 해결하는 문제는 두 가지입니다. ...