400시간 후, 2MB 제한 해제로 매출이 획기적으로 증가한 비결

때로는 한동안 소프트웨어 엔지니어로 일하다 보면 기술의 어떤 영역이 늪지대인지 알게 됩니다.

당신은 그것을 어떻게 해야 하는지 정확히 알고 있고, 일어날 수 있는 모든 문제를 알고 있으며, 특별한 주의를 기울여 그러한 영역에 접근하고, 누군가가 자신이 그 일을 더 빨리 할 수 있고 앞에 무엇이 있는지 모르는 것이 더 낫다고 생각할 때 크게 웃습니다.

이것은 제가 경력을 쌓는 동안 많은 경험을 했던 분야 중 하나에 대한 이야기입니다.

400시간의 비디오 업로드가 나에게 가르쳐 준 것

2007년쯤 YouTube는 이미 2년이 흘렀으며 아직까지 이에 대해 아는 사람이 거의 없었습니다. 사람들은 SD로 비디오를 녹화하고 이를 CD나 DVD에 저장했습니다.

예전에는 다운로드하는 데 비용이 많이 들었기 때문에 모든 비디오를 인터넷에 업로드할 것이라고는 아무도 상상하지 못했습니다.

음, 아마도 토렌트를 제외하고 말이죠. 하지만 화면을 녹화하고 캡션을 추가하는 앱이 이미 있었기 때문에 온라인으로 비디오 튜토리얼을 업로드할 수 있는지 알아보는 것은 흥미로웠습니다.

그 이후로 저는 CentOS 서버를 구입하고 온라인 비디오 튜토리얼 사이트를 구축하기 시작했습니다.

그것이 작동하려면 사람들이 튜토리얼을 업로드할 수 있게 하는 방법과 사람들이 튜토리얼을 볼 수 있게 하는 방법이라는 두 가지를 알아내야 했습니다.

영상을 올리는 건 꽤 쉬웠던 것 같아요. HTML에 입력 필드를 추가하고 서버에서 파일을 받기만 하면 됩니다.

그러나 예상보다 어려운 일이 발생했습니다. 첫 번째는 비디오의 크기였고, 두 번째는 인터넷 연결의 품질이었습니다.

필요한 모든 것을 제공하는 유일한 언어인 PHP를 사용하는 내 서버는 훌륭했습니다. Apache에서 실행되었고 나중에는 Nginx에서 실행되었습니다.

Ngnix 초기 버전의 문제는 그러한 페이로드를 기대하지 않았다는 것입니다. 서버가 최대 30~60분의 지속적인 업로드와 전송 크기를 허용할 수 있도록 여러 설정을 구성해야 했습니다. 약간의 실험이 필요했고 결국 성공했습니다.

또 다른 문제는 Ngnix가 프로세스를 포크하는 방식이었습니다. Ngnix의 초기 버전에는 포크가 예기치 않게 중단되는 몇 가지 버그가 있었습니다.

한 사용자가 매달린 이러한 포크는 나중에 다른 사용자에게 할당되어 해당 사용자도 동영상을 업로드할 수 없게 되었습니다.

누가 어떤 프로세스를 사용했는지에 대한 정보를 저장하고 해당 프로세스를 수행해야 할 때 해당 프로세스를 종료해야 했습니다. 게다가 낮에도 버그가 쌓이기 때문에 매일 밤 정기적으로 모든 프로세스를 종료해야 했습니다.

Nginx 및 PHP 구성에 오랜 시간을 보낸 후 결국 업로드가 작동하기 시작했습니다.

다음 단계는 사용자에게 비디오를 표시하는 것이었습니다. 그 당시에는 온라인 플레이어가 한 명 있었습니다. 이름은 기억나지 않지만 좋았고 자막도 제공되었습니다. 모든 사람이 비디오 튜토리얼을 통해 배울 수 있기를 원했기 때문에 이는 중요했습니다.

그런데 또 다른 문제가 발생했습니다. 원본 비디오를 재생하는 것은 매우 어려웠습니다. 매우 빠른 연결에서는 결함이 많이 발생했으며 때로는 브라우저가 중단되기도 했습니다.

ffmpeg가 이미 있어서 영상을 최적화하는 방법을 알아냈습니다. 비디오 튜토리얼의 중요한 측면은 전체 화면을 고품질로 보여주고 싶다는 것입니다. 그렇지 않으면 사람들이 클릭한 내용과 모니터에 표시되는 텍스트를 볼 수 없기 때문입니다.

당시 라이브 녹화에 비해 비디오 튜토리얼은 품질에 대한 요구 사항이 더 높았습니다(이것이 비디오 튜토리얼이 수년 동안 YouTube의 강력한 기반이 아니었던 이유입니다).

고품질과 작은 비디오 크기에 대한 할인 혜택을 얻으려면 ffmpeg를 사용하여 많은 실험이 필요했습니다. 물론 즉시 완료할 수는 없기 때문에 MySQL 데이터베이스를 쿼리하고 아직 제대로 변환되지 않은 비디오를 찾는 크론 작업이 있었습니다.

ffmpeg로만 제작된 영상이 아닌지 확인하는 것도 중요했습니다. ffmpeg는 훌륭했지만 때로는 비디오나 오디오 압축 형식, 심지어 입력 비디오의 크기도 마음에 들지 않았습니다. 결과적으로 출력영상이 나왔으나 검은색이었습니다.

그래서 또 다른 크론 작업을 추가했습니다. 그 작업은 출력 비디오에서 ffmpeg를 다시 실행하고, 크기와 해상도를 읽고, 썸네일에 필요한 프레임 하나를 가져오는 것이었습니다. 다음으로 프로세스는 썸네일의 픽셀을 확인하여 그것이 검은색인지 확인했습니다. 오류가 없고 썸네일이 검은색이 아닌 경우 변환이 성공한 것으로 간주됩니다.

나는 그것으로 충분할 것이라고 생각했지만 그렇지 않았습니다. 때때로 ffmpeg 또는 다른 라이브러리가 중단되기 때문입니다. 이는 변환 프로세스 또는 유효성 검사 프로세스도 중단되어 문제가 발생한 경우 정보를 저장할 수 없음을 의미합니다.

그래서 또 다른 cron 프로세스를 추가했습니다. 세 번째 프로세스는 이전 두 프로세스를 확인하는 작업이었습니다. 변환 프로세스가 시작되었을 때, 마지막으로 살아 있다고 보고했을 때 데이터베이스를 체크인하고 현재 시간과 비교했습니다.

예를 들어 변환이 3시간 동안 응답하지 않은 경우 변환을 실패로 표시하고 재실행을 위해 추가했습니다. 작업 30분 후에도 유효성 검사 프로세스가 응답하지 않으면 데이터베이스 유효성 검사가 실패한 것이므로 비디오를 처음부터 변환해야 하고 프로세스를 종료해야 했습니다.

보통 그게 도움이 됐어요. 세 번째로 작동하지 않으면 시스템에서 이메일을 보냈는데 뭔가 잘못된 것입니다.

결국 시스템이 작동했고 사람들은 비디오를 업로드할 수 있었습니다. 비디오가 변환되어 썸네일 및 자막과 함께 페이지에 표시되었습니다.

제가 400시간 넘게 투자한 흥미로운 프로젝트였습니다. 비디오, 오디오 처리 및 검증에 대해 많은 것을 가르쳐주었습니다.

하지만 업로드를 처리하는 일은 제가 집중해야 할 늪지대라는 사실도 배웠습니다. 성과가 있었습니다…

업로드를 제한하면 판매가 제한됩니다

지금 2023년에는 상황이 다르다고 생각할 수도 있습니다. 하지만 그렇지 않습니다. 확실히 많은 것들이 변했습니다. 처리 능력과 저장 공간을 확보하는 것이 더 쉽습니다. 인터넷 연결이 더 좋습니다. 도구가 더 좋고 더 자세한 문서가 있습니다.

그러나 여전히 기본 설정을 사용하면 크기 때문에 일부 업로드가 실패합니다. 기본 업로드 양식은 Android 기기에서 작동하지 않습니다. 나는 많은 웹 앱에서 이 문제를 계속해서 봅니다.

다양한 형식의 비디오는 물론 사진까지 처리하기가 어렵습니다. 특히 지금부터 새로운 실험 형식이 있습니다.

예를 들어 몇 년 전 저는 소셜 미디어용 콘텐츠 관리 및 계획 시스템을 개발하고 있었습니다.

마케팅 담당자에게 업로드된 사진을 편집할 수 있는 기능을 제공해야 했습니다. 자르기 및 필터와 같은 기본적인 것입니다. 최신 라이브러리를 사용하더라도 100% 신뢰할 수는 없었으며 최소한 허용 가능한 수준까지 사용할 수 있도록 하려면 많은 조정이 필요했습니다.

많은 경우 파일 업로드는 프로세스의 중요한 단계입니다. 예를 들어 긴 양식을 작성하고 마지막 단계에서 파일을 업로드해야 합니다.

어떤 이유로든 업로드가 실패하면 사용자가 이미 입력한 모든 데이터를 잃지 않도록 보호해야 합니다.

업로드가 실패하는 경우 또는 파일에 적용하는 다음 프로세스에 대한 시나리오를 처리해야 합니다.

이러한 문제 중 일부를 해결하는 한 가지 방법은 사용자를 크기와 형식으로 제한하는 것입니다. 유혹적으로 들립니다.

저는 최근 사람들이 사진을 업로드하여 자신만의 제품을 만들 수 있는 전자상거래 프로젝트에 참여하고 있었습니다. 그러나 앱은 이미지 크기를 2MB, 해상도를 1000x1000px로 제한했습니다.

이러한 제한을 3MB 및 2000x2000px로 늘리자는 제안이 있었습니다. 나는 휴대폰을 꺼내 사진을 찍어 사람들에게 사진의 크기가 무엇인지 보여주었다.

4MB이고 약 3000x3000px이었습니다. 그래서 이를 설명하기 위한 또 다른 제안이 나왔습니다. 그래서 저는 휴대폰으로 사진을 찍을 때 해상도를 높이고 이러한 제한을 모두 제거해야 한다고 말했습니다.

업로드하기 전에 사진을 변환하고 축소할 수 있기 때문에 제한을 유지하자는 제안도 있었습니다.

맞습니다. 하지만 대부분의 사람들은 어떻게 해야 할지 모르고, 생각하고 싶지도 않고, 어렵다고 느낄 수도 있습니다. 나는 클라이언트와 팀이 한계를 완전히 없애도록 설득할 수 있었습니다.

매출이 대폭 증가하고 이탈률도 낮아져 사람들이 휴대폰으로 제품을 구매하고 싶어했지만 요구 사항으로 인해 차단되었기 때문에 이는 큰 움직임이었습니다. 한도를 높이는 것은 많은 사람들이 원하는 제품을 구매할 수 있도록 하는 쉬운 솔루션 중 하나였습니다.

파일 업로드는 늪지대이지만 어떤 경우에는 판매 및 고객 만족(다시 판매)에 매우 중요할 수 있습니다.

이것이 바로 제가 개발한 파일 업로드를 처리하는 시스템 영역에 특별한 주의를 기울이는 이유입니다. 이는 고객 비즈니스에 가장 큰 영향을 미칠 수 있는 영역이기 때문입니다.

파일업로드 관련 사연이 있나요? 댓글로 공유해주세요!

또한 하트 아이콘을 클릭하고 소셜 미디어에 좋아요를 누르고 공유하세요. 그러한 주제에 대해 더 많이 글을 쓰도록 동기를 부여합니다!

소프트웨어 엔지니어로서 너무 많이 생각하고 싶지 않다면 Filestack 도 확인해보세요. Javascript 파일 업로드를 처리하는 API입니다. 그들은 이 이야기를 가지고 내가 참가하는 콘테스트를 후원합니다. Filestack 및 HackerNoon - 공유 동기를 부여해 주셔서 감사합니다! 해보니 정말 좋았어요!