개요 최근 기업들의 공고를 보면 재밌는 공고가 AI 애니메이션 플랫폼 개발건이었습니다. 해당 공고와 더불어서 AI로 생성하는 것과 관련된 공고들이 많이 올라오더군요. 그래서 호기심에 현재 프로젝트에 AI를 녹일 부분이 없을까 고민하던 중 썸네일 기능에 이를 적용하기로 했습니다. 기존 class 사이트에서는 영상의 프레임 단위로 썸네일을 골라 추출하는 기능을 제공했습니다. 여기에 추가 기능으로 썸네일을 직접 만들 수 있게 했습니다. 이미지 생성은 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 ...
개요 저번 글을 작성하던 중 배포 방식을 검토하다가 개선점이 보이더군요. 현재는 수동 배포로 버전 업데이트마다 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만 원이 소비되게 됩니다. 이대로는 서버를 유지하는 데 부담이 발생합니다. 흐름도 비용 절감을 위해서는 서버 비용을 줄이는 게 시급합니다. 제 돈이 녹고 있거든요. 이번에 적용할 방법은 인코딩 서버의 분리입니다. ...
개요 Class Project 1차 회고를 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을 재시도하도록 다음처럼 코드가 되어 있으므로, 이와 관련된 버그로 방향을 잡았습니다. ...
개요 1차 MVP는 현재 학원 내에서 배포 중이며, 도메인 연결 후 공유할 예정입니다. 슬슬 머릿속에는 있지만 말로는 정리가 안 되는 단계에 닿은 것 같아 글로 정리합니다. Anime Search에서의 한계 지난번에 진행했던 Anime Search Project에서 장면 검색 RAG까지 구현하며 결과적으로 마음에 들지 않았던 점은, 어디까지나 기술적 호기심 해결로 끝났다는 점이었습니다. 해당 글에서도 마지막에 다음과 같이 정리했죠. 위 파이프라인까지 구현해 6장 초반 화면처럼 자연어 검색이 동작합니다. 다만 아직 부족한 점도 있고, 실용성이 떨어지는 부분도 몇 군데 보였습니다. ...
