Class Project 문제 생성
개요 처음 이 프로젝트를 만들 땐 단 한 명의 수강생이 있었으면 좋겠다는 생각이 들었지만, 프로젝트에 투입하는 리소스가 늘수록 좀 더 사용자의 체류 시간을 높이고 싶어졌습니다. 영상 콘텐츠를 다루면 참 좋은 게, 확장할 수 있는 기능이 참 많더군요. 이번에는 사용자에게 직접적으로 닿는 3가지 기능을 추가해봤습니다. ...
개요 처음 이 프로젝트를 만들 땐 단 한 명의 수강생이 있었으면 좋겠다는 생각이 들었지만, 프로젝트에 투입하는 리소스가 늘수록 좀 더 사용자의 체류 시간을 높이고 싶어졌습니다. 영상 콘텐츠를 다루면 참 좋은 게, 확장할 수 있는 기능이 참 많더군요. 이번에는 사용자에게 직접적으로 닿는 3가지 기능을 추가해봤습니다. ...
사이드 프로젝트 Class S 사이트 주소 OTT 서비스 구조를 직접 만들어보고 싶어서 진행한 사이드 프로젝트 관련해서 전체 히스토리를 보고 싶으시다면, Class Project 카테고리로 가시면 됩니다. 개요 사이드 프로젝트를 보여줄 때 직접 시연하는 걸 보여줄 수 있지만 다음과 같은 제약이 발생할 수 있죠. ...
개요 이전 하이브리드 검색에서 강의 내용을 청크로 나누고 FTS와 임베딩을 쌓아 두었습니다. 이번에는 그 인덱스를 써서, 질문에 관련 구간을 찾은 뒤 LLM이 답하게 하는 RAG를 붙이려 합니다. 이유는 AWS에 Class S를 배포할 때 아마존 큐라는 서비스를 이용해서 모르는 부분과 배포 구조에 대해 조언을 받았는데, 굉장히 편하다는 인상을 받았고, 이 구조를 만드는 데 비용이 얼마나 발생할까? 그리고 그 비용을 최적화하는 데 어떻게 했을까?라는 의문에서 시작했습니다. ...
개요 Class S를 만들었던 지난 하이브리드 검색 글에서는 텍스트를 토큰으로 나눠 검색하는 FTS 방식과, 임베딩 모델을 거쳐 수치로 표현해 비교하는 벡터 검색 방식을 사용했습니다. 전에는 이 두 방식을 로직 흐름으로 짧게 지나갔지만, 이번에는 더 면밀히 봐봅시다. ...
개요 이전 하이브리드 검색에서는 FTS, 벡터, 조회수를 0.45 / 0.45 / 0.10으로 섞어 순위를 매겼습니다. 그 비중은 일단 동작하게 둔 값이었고, 어떤 조합이 사용자가 원하는지 알 수 없었죠. 실제 서비스에서는 A/B 테스트나 카나리 테스트로 이를 시험해 보기에, 이게 가능한 구조를 적용해 봤습니다. ...
개요 처음에 강의 공유 사이트로 컨셉을 잡고 배포했던 이유에는, 동영상처럼 무거운 데이터를 다루고 싶었던 점도과 함께, 여기서 빠져나갈 갈래가 많다는 점도도 있었습니다. LLM 관련 기능을 붙이려면 콘텐츠가 필요한데, 그에 가장 잘 맞는 서비스라고 생각해 접근했습니다. ...
개요 이 글의 목표는 Go 채널을 사용법만 나열하는 것이 아니라, 런타임 내부 구조를 따라가며 왜 그렇게 동작하는지 이해하는 것입니다. 앞부분에서는 chan.go의 생성, 송수신, 버퍼 구조를 읽고, 뒷부분에서는 내부 스케줄 정책을 바꾸지 않은 채 관측 훅을 붙여 채널이 GMP 대기 경로와 실제 로직이 어떻게 맞닿는지 실험으로 확인합니다. ...
서비스 방문자 수 부트캠프 수업을 매일 녹화하고 쉬는 시간을 기준으로 영상을 나눠 업로드한 결과, 다음과 같은 트래픽이 발생했습니다. 외부 커뮤니티에 노출한 곳은 제 개인 블로그뿐이므로 블로그나 링크드인을 통해 들어온 소수의 인원과 실제로 복습을 위해 영상을 보는 몇 사람 정도가 전부일 것으로 추측했습니다. ...
개요 최근 기업들의 공고를 보면 재밌는 공고가 AI 애니메이션 플랫폼 개발건이었습니다. 해당 공고와 더불어서 AI로 생성하는 것과 관련된 공고들이 많이 올라오더군요. 그래서 호기심에 현재 프로젝트에 AI를 녹일 부분이 없을까 고민하던 중 썸네일 기능에 이를 적용하기로 했습니다. ...
개요 Class Project 2차 회고를 적은 지 12일 만에 진행 사항을 정리합니다. 2차 회고 마지막 Todo는 다음과 같았습니다. 지금 당장은 배포 비용 절감이 중요합니다. 현재 EC2 온디맨드 인스턴스만으로 하루 약 $3(월 $90 전후)이 나가고 있습니다. 현재 구조에서 벗어나 Spot 인스턴스로 인코딩을 분리하고 DB를 RDS로 옮긴다고 가정하면 웹/API용 EC2 스펙을 줄일 수 있습니다. 하지만 Spot 중단 시에는 인코딩 잡 재시도가 필요하다는 점 때문에 프로세스가 복잡해지게 되고, 자연스럽게 버그가 발생할 가능성이 높아질 테니 연구가 필요합니다. 또한 현재는 원본 코덱과 관계없이 항상 transcode하도록 되어 있습니다. 이미 H.264/AAC인 영상은 -c copy로 패키징만 하도록 분기하면 인코딩 시간을 더 줄일 수 있으니 이 부분도 연구가 필요하죠. 마지막으로 도메인 붙여봐야겠군요 이번 기간에 수정의 중심은 인코딩 파이프라인 고도화와 인프라 분리였습니다. 2차까지는 단일 EC2 위에서 기능 추가와 ffmpeg 튜닝을 진행했다면, 이번에는 월 비용을 줄이는 데 집중했습니다. ※ 해당 동영상 스트리밍 사이트는 다음 주소에서 볼 수 있습니다. http://43.201.141.69 ...