풀캠정글러

우리팀의 프로덕트는 지금 python flask 서버와 CRA 클라이언트로 이루어진 웹서비스이다. 문제는 서버의 영상분석 & JSON파싱 계산량이 너무 많고, 게다가 그걸 굳이 서버가 할 필요도 없다는 것 다른 한명의 백엔드 팀원은 AWS 배포를 진행중이지만, 줄인다고 줄인 사용량으로도 좀 버거운 것 같다. 하지만 이걸 electron을 이용한 데스크톱 앱으로 다시 개발해서 배포 방향을 튼다면 대부분의 문제가 해결된다 각각의 영상 분석 프로세스를 유저의 컴퓨터로 떠넘기면 서버는 로그인, DB와의 중계 정도만 해주니 정말 쾌적할거고 컴퓨터 성능도 우리 AWS 프리티어 서버보단 당연히 좋으니 더 빠를거고... 유저는 서버에 줄을 설 필요도 없고 영상을 자르는 exe를 줄지 영상을 다운로드해줄지 고민할 필요도..

목요일 발표 전까진 거의 발표준비만 했다 프론트단에서 다운로드 기능 연결을 좀 헤메는거같아서 직접 구현 팀원이 북마크별 메모 기능을 구현해서 컷툴이 컷 잘라줄때 파일명을 메모로 해주게 변경 시연에 잘 보여야 되는 부분만 미리 시각적으로 좋은 UI 좀 만들어두기 차트가 뭘 의미하고 컷은 어떻게 따는지 간단한 사용법이 페이지에 보이도록 html 수정 개발 관련해서 내가한일은 지난 5일간 이정도밖에 없는듯 팀내 의사결정, 발표준비, 자료제작같이 개발이 아닌 일들도 팀장이라 경험해보는건 좋지만 가끔씩은 내가 팀장이 아니라 어딘가의 팀원이었다면 하는 생각도 든다. 체감상 주어진 시간의 1/4 이상을 '개발이 아닌 일'에 쓰고 있는 것 같은데 한달이라는 이 시간을 전부 개발에만 썼다면? 하는 미련 그래서 처음엔 팀..

1. exe 컷툴보다는 영상 다운로드가 낫다 협력사 피드백에서도 나왔던 의견이었다. 사실 영상을 다운로드해주는게 더 직관적이고, 심지어 구현도 더 쉽다. 발표라는 짧은 어필포인트에선 이게 편집자는 원본을 갖고있고 아카이브에서 컷을 잘라 줘도 품질이 나빠 못쓴다~ 이런 뒷배경을 깔 수도 없는 노릇이다. 현업자 분들이 두명이나 그렇게 느끼셨다면 청중의 생각도 같다 봐야할테니, 컷영상 파일 다운로드를 제공하는게 맞는 것 같다. 하지만 아카이브로부터 다운로드를 제공하는건 정책 위반이니 편집자가 원본을 갖고있다는 가정 하에 그 로컬파일을 자른 파일을 제공하는 것이 맞을 것 같다. 2. 웹서비스일 필요가 있나? 이것도 협력사 피드백에서도 나왔던 의견... 사실 처음 만들때 아 아무튼 웹서비스 하고 탄성적으로 만들었..

위와같이 status에 따라 파일을 생성, 삭제해주는 api를 만들고 파일을 다운로드할 path를 추가하면 POST로 북마크를 보낸 뒤 위 path에 접근하는 것으로 생성된 zip파일의 다운로드가 가능 생성요청POST -> 다운로드경로접근 -> 삭제요청POST를 해주는 버튼은 프론트가 구현할거라 믿고 자러가자... 자고일어나면 내일부턴 개발자가 아니라 발표노예 ㅜㅜ

마무리 발표 전 마지막으로 구현할 목표 로컬의 원본 파일을 유저가 고른 북마크들 구간대로 잘라주는 exe 다운로드 구현 구상하는 비즈니스 로직은 아래와 같다 0. client로부터 유저가 북마크한 구간 정보를 수신 1. 북마크 구간 정보를 txt파일로 동적 생성 2. 영상분할 function을 수행하는 exe파일, ffmpeg.exe, 위의 txt파일을 모은 zip 파일 생성 3. zip 파일을 flask의 sendfile로 client에 제공 4. 동적 생성된 txt, zip 삭제 -> 다운로드받은 유저는 압축을 풀고 exe를 실행하여 원본파일 이름을 입력하면 영상이 분할됨 이를 위해 구현해야 할 부분은 영상분할 function 설계 function을 수행하는 exe build exe, txt, ffm..

일요일까지 개발하고 월요일부터 발표준비할 계획이었지만 오늘까지만 개발하고 일요일부턴 발표준비를 하는게 낫다는 의견을 들었다 그동안의 파멸적인 발표능력을 보았을때 백번 맞는 말ㅋㅋ 월요일부터 하겠다 = 월요일 저녁부터 하겠다 -> 이틀밖에 안남음 생활패턴이 낮밤이 뒤집어진것도 고려하면 월요일부터 했다간 정말 시간이 없긴 하다 오늘안에 내가 개발할 부분은 마무리짓고 일요일부턴 발표연습을 해보자 이미 날짜상으로는 일요일이지만 퇴근하기 전까진 아무튼 '오늘'임 아무튼 오늘 할일 1 보관된 chat file을 읽어 API로 보낼 json 형식으로 되돌리는 함수 구현 chat message는 다른 data와는 다르게 파일의 형태로 서버가 보관하기로 결정한 상황 시청자들이 쓴 온갖 텍스트가 다 적혀있어서, 이걸 DB..

아호코라식은 KMP를 트라이에서 쓰는 알고리즘이다 트라이의 각 노드는 매칭을 확인할 글자, 성공시 넘어갈 자식노드, 실패시 돌아갈 실패함수의 리턴 노드를 갖고있고, 리프노드라면 매칭 성공시 아웃풋 함수를 실행시킨다. KMP가 하나의 검색어 = 1차원 스트링에서 실패함수를 만들듯이 아호코라식은 여러개의 패턴을 트라이로 묶어 거기서 실패함수를 만든다. 브루트포스나 KMP는 n개의 검색어를 검색하면 n배의 시간이 들지만, 아호코라식은 그렇지 않은 것이 장점 알고리즘 공부할때 구현해둔 class가 있어서 가져다가 써보니 시연에 쓸 슈카월드 영상에서 키워드를 검색하는데 0,1초만에 끝난다 굿 디스크를 읽는 작업이고, 나름 5만명이 본 4시간짜리 영상인데도 성능이 꽤 좋다 이정도면 물건너 버튜버가 등판해도 1초컷할..

먼 옛날 이런 일이 있었다 https://uneducatedjungler.tistory.com/160 Day 11 : front에 보낼 Audio 데이터 경량화 오늘할일(이었던것) Chat flow 분석 프로토타입 고치기 chat flow는 오디오나 비디오랑 다르게 그냥 텍스트 형태의 JSON이라 다루기는 쉽다 그래서 주제 고르는 단계에서 대충 구현은 해둔 상태 진짜 uneducatedjungler.tistory.com 옛날옛적부터 개선하려고 생각은 했지만 할일에 치여 못했던 프로세스 정리 그동안 워낙 바빠서 주먹구구식 chat Process를 달고 가끔씩 에러터지는걸 피해가면서 개발해왔는데 오늘 목표였던걸 끝내고 시간이 조금 남았으니 지금이 해결할 기회인 것 같다 pytchat은 소켓을 열고 json데..

우리 서버측의 가장 큰 문제, 메모리 소모량 5시간짜리 영상 하나만 요청이 들어와도 램을 5기가씩 먹으니 아마존 인스턴스로 배포하긴 무리가 있다. 무지막지한 램 소모량의 원인은 numpy를 이용한 rawdata의 계산 때문이다. 영상의 픽셀이나 음원의 파형을 numpy로 분석하는데, 영상의 rawdata를 램에 올린다는 것은 무압축 영상을 램에 통째로 올리는 것과 동치이니 램이 훅갈수밖에 없다... 메모리 소모량은 당연히 영상의 시간에 비례한다. 그렇다면 영상을 소분해서 파일화하고, 그때그때 당장 계산할 일부분만 램에 올리는 것으로 쓸데없이 계산 전, 후로 램에 올라가있는 부분들을 내려놓게 되어 효율 개선이 가능할 것 물론 영상을 작은 단위로 자르는 데에 시간은 더 들겠지만, FFmpeg의 cut을 이용..

협력사 멘토링 이후 생각해볼 것이 많았다. 남들 다 하니까 하자는 느낌이었던 커뮤니케이션 툴은 개발하지 않는 것으로 결정 핵심 기능과는 아무 연계가 없는데, 개발을 시작하면 프로토콜부터 다 갈아엎어야 한다. 협력사님 말씀대로 이건 좀... 중간발표 직후 당장 프론트에서 보여줄 것이 없을 때는 해볼만한 아이디어였지만 이젠 우리 조와 어울리는 다른 아이디어의 구현목표가 많이 쌓여있다. 대신 데이터 차트와 영상을 보며 편집자 유저가 고른 하이라이트 북마크들, 이것을 이용한 아웃풋을 몇개 개발하기로 했다. 1. 크롬 익스텍션 편집자 유저가 editor 페이지에서 작업을 마치고 내보내기한 북마크 구간들의 데이터는 우리 서버에 저장 익스텐션의 설치자(=시청자)는 해당 url의 풀영상을 볼 때 편집자가 북마킹한 구간..