[TIL] 나만무 6/23 ~ 6/29

6/23(월) :

5팀 2차 발표 피드백

발표자 : 팀장

• 기술적 챌린지에 대하여 기획 부분에서 구체화 하여 발표에 추가할 것
• 위치 정보의 경우, 사용자에게 권한을 요청하는 경우 등 → 이런것을 웹, 앱의 구현 부분도 나누어서 선택한다
• 합주 영상 저장 및 처리 부분에서 어떤 솔루션을 사용할것인지?
  • AWS 내에서도 이에 특화된 서비스가 있을수도 있고, 외부 솔루션을 찾아야 할 수도 있고
  • 영상이 S3에 저장이 된다면, 사용자가 영상을 다운을 받는 방식인건지, 이를 어떻게 불러올것인지?
  • 그리고 이 영상을 받아올때까지, 사용자가 기다리는 시간 등을 어떻게 처리할 예정인지
• 영상의 업로드 시점? (영상이 올라가는 시간도 있을거고, S3에 저장하는 시점도 중요하다)
  • 어떤 영상을, 언제, 어디에 저장을 할것인지?
  • 영상 처리에 대한 파이프라인 구체화가 필요하다
  • 유튜브 등을 참고해서 어떤 방식으로 동작하는지 리서치 후 설계에 대해 고민하라
• 총 발표 시간 : 4분 51초 (준비시간 포함, 코치 피드백 제외)

❌ iOS FFmpeg Testing → 실패!

이번 프로젝트에서는 FFmpeg 라이브러리가 꼭 필요하다. 숏폼 영상 편집 기능을 넣으려면 필수적인 요소인데… 찾아보니 올해부터 FFmpeg 공식적인 React Native 지원이 중단됐다고 한다. 특히 iOS와 Android 환경에서는 바이너리를 직접 찾아서 넣어야 한다.

그래서 혹시 다른 대안이 있을까 싶어 이것저것 찾아봤지만, 현재로선 오픈소스로 쓸 수 있는 것 중에서는 FFmpeg이 가장 적합했다. 결국 우리가 해야 할 일은 ‘바이너리를 어떻게든 프로젝트에 넣는 것’…! 그래서 하루 종일 그 방법을 파고들었다.

하지만 문제는, 나한텐 React Native 자체가 처음이라는 거 😅

빌드 과정 하나하나가 낯설고, 에러도 만만치 않았다. 특히 Cocoapods 호환 문제로 인해 아주 기본적인 iOS 빌드조차 한참을 헤매었다. 결과적으로 실질적인 FFmpeg 테스트까지는 가지 못했고, 빌드 환경 세팅만 하다가 하루가 다 지나가버렸다. 그래도 이 과정을 통해 React Native의 빌드 구조나 iOS 개발 환경에 대해 많이 배운 하루였다. 아직은 버거워도, 조금씩 풀어가보려고 한다.

6/24(화):

숏폼 DB 로직 브레인스토밍

내일 있을 최종 기획 발표를 앞두고, 숏폼 영상 업로드부터 DB 처리까지의 전반적인 흐름을 조사하고 정리해보았다. 우리가 개발하려는 서비스에서는 사용자가 직접 영상을 업로드하고 편집할 수 있어야 하고, 그에 따른 백엔드의 처리 로직과 데이터 흐름을 구체화할 필요가 있었다. 그래서 내가 담당한 부분은 “숏폼 영상의 전체 업로드/관리 흐름을 어떻게 구성할지” 에 대한 로직 정리였다.

조사한 내용을 바탕으로 다음과 같이 Flowchart를 구성해보았다.

👇

1. 사용자 요청 → 프론트엔드 처리

• 사용자가 직접 영상을 촬영하거나 기존 영상을 선택해 업로드 요청을 보낸다.
• 이때 영상 편집 여부에 따라 분기 처리되며, 편집/삭제/수정 등의 요청은 각각 프론트에서 API 요청으로 이어진다.

2. 백엔드 로직

• 첫 업로드인지, 혹은 기존 영상 편집인지에 따라 처리가 다르다.
• 특히, POST 요청 이후에 edit 요청이 들어오면 에러를 발생시켜야 한다는 점도 체크해야 한다.
• 영상이 이미 업로드된 상태인지 확인한 후, 업로드가 필요한 경우 S3로 업로드된다.

3. 데이터베이스 및 캐시 처리

• PostgreSQL에는 사용자 데이터 및 영상 관련 메타데이터가 저장된다.
• Redis는 스크롤 기반 피드의 캐싱이나 좋아요/조회수 등의 임시 처리용으로 고려 중이다.
• 영상 자체를 Redis에 저장하는 건 부적절하다는 결론이 나서, 영상 파일은 S3에 저장하고 URL만 DB에서 관리한다.

CloudFront → ❌ 사용하지 않기로 결정

처음에는 영상 콘텐츠의 전송 속도를 높이기 위해 CloudFront CDN 사용을 고려했지만, 팀원들과 논의 끝에 결국 사용하지 않기로 결정했다.

• S3 버킷을 서울 리전으로 생성하면, 영상 요청에 대한 지연이 거의 없다는 점
• CloudFront의 설정 복잡도 및 캐시 무효화 처리 등을 고려했을 때, 얻는 이점 대비 관리 비용이 더 크다는 점

이러한 이유로 단일 S3 버킷 + DB 구성만으로도 충분하다고 판단했다. 그래서 현재 아키텍처에서는 CloudFront 없이 S3만을 통해 영상 데이터를 제공하는 방향으로 정리되었다.

하지만 한 가지 고민해봐야 할것은 Redis를 어떻게 효율적으로 사용할지, 어떤 데이터를 저장해서 무한 스크롤을 잘 구현할지 고민해봐야 한다.

이번 흐름도를 정리하면서 단순한 기능 구현이 아니라, 시스템 아키텍처 레벨에서 성능과 효율성까지 고려해야 한다는 점을 많이 느꼈다. 특히 CDN 사용 여부나 캐시 전략, 메타데이터 처리 같은 부분은 개발 전에도 충분히 고민이 필요한 포인트였다. 무엇보다도 재미있었던 건, 단순히 “코드 짜기”가 아니라 서비스 전체를 어떻게 설계할지를 고민하는 과정 그 자체였다.

정답은 없지만, 우리가 내리는 선택이 왜 합리적인지를 설명할 수 있어야 한다는 것. 그게 이번 기획에서 가장 의미 있었던 부분이었다 😊

6/25(수):

5팀 최종 기획 발표 피드백

이동석 코치

1. 영상 처리 방식에 대한 고민
   • 영상 인코딩을 서버에서만 구현을 한다면, 서버 큐를 어떻게 구현 할 것인지?
   • 하나의 인스턴스 풀의 점유율이 높다면 다른 인스턴스로 위임하여 병렬 처리하는 방식에 대한 고민이 필요하다
   • 영상 인코딩을 클라이언트에 위임할 수 있는 방법은 없을지에 대한 고민 필요
   • 영상에 다른 영상을 얹는 과정에서의 음성과 영상간의 싱크 처리에 대한 명확한 기술적 검증

유윤선 코치

1. 기능의 구분
   • 중고 거래와 릴스 플랫폼의 UI적 분리가 필요하다
   • 이 두개의 서비스 간의 기획 상의 연결고리가 부족하다 (스토리텔링 연결성 필요)
2. 여러 합주 영상이 합쳐져서 각각의 영상 파일로 저장이 된다면, 클라이언트 렌더링은 최종 버전만 렌더링 되도록 한다면 여러 영상을 하나의 화면에서 보여줄 필요가 없다. 이러한 구현이 가능한지 알아 봐라.

Testing FFmpeg WASM in FE : 프론트엔드에서 영상 합치기

오늘은 팀 피드백을 바탕으로, FFmpeg를 WebAssembly(WASM)로 활용해 브라우저에서 영상 편집이 가능한지 테스트해봤다. 목표는 프론트엔드 단에서 React 환경으로 FFmpeg 라이브러리를 실행해 영상들을 편집할 수 있는 구조가 될 수 있는지 확인하는 것!

🛠️ 구현 개요

• ffmpeg.wasm 라이브러리를 설치하고, 브라우저 내에서 직접 FFmpeg 명령어를 실행하는 방식으로 진행.
• 다양한 비디오 타입을 다룰 수 있는지를 확인하기 위해, 일부러 MOV 형식의 파일을 인풋으로 넣고 MP4로 변환해서 출력하는 흐름을 테스트했다.
• 특히 웹 환경에서는 렌더링이 프레임 단위로 끊기면서 느려지는 문제가 발생했기 때문에, fps=30을 고정값으로 설정해서 처리 속도를 개선해보았다.

🎞️ 영상 합치기 로직 (React + FFmpeg WASM)

// 더 간단하고 안정적인 hstack 필터 사용
      // 두 비디오의 길이를 맞추고 좌우로 배치
      const filterComplex = [
        // 1. 첫 번째 비디오: 480x360으로 스케일링 + 패딩
        '[0:v]fps=30,scale=480:360:force_original_aspect_ratio=decrease,pad=480:360:(ow-iw)/2:(oh-ih)/2[v0]',
        // 2. 두 번째 비디오: 480x360으로 스케일링 + 패딩  
        '[1:v]fps=30,scale=480:360:force_original_aspect_ratio=decrease,pad=480:360:(ow-iw)/2:(oh-ih)/2[v1]',
        // 3. 좌우로 합치기
        '[v0][v1]hstack=inputs=2[v]'
      ].join(';');

      await ffmpeg.run(
        '-i', 'video1.mp4',
        '-i', 'video2.mp4',
        '-filter_complex', filterComplex,
        '-map', '[v]',
        '-map', '0:a?',
        '-r', '30',
        '-c:v', 'libx264',
        '-preset', 'ultrafast',
        '-crf', '28',
        '-shortest', // 더 짧은 비디오 길이에 맞춤
        '-y',
        'output_sidebyside.mp4'
      );

• fps=30: 프레임 수 고정으로 렌더링 속도 개선
• scale + pad: 해상도를 강제 통일해 깔끔한 병합 유도
• hstack: 좌우로 영상 붙이기
• crf 28: 인코딩 품질을 중간 정도로 설정
• shortest: 두 영상 중 더 짧은 쪽에 맞춰 자동 종료

최종 화면

🤔 현재 고민 포인트

현재 기획 중인 숏폼 편집 기능은 최대 6개의 연주 영상을 클라이언트에서 병합하는 것을 목표로 하고 있다. 실제로 WebAssembly 기반 FFmpeg를 활용해 프론트에서 직접 영상 병합을 시도해보았고, 동작은 확인되었지만 여러 현실적인 한계점들에 대해 생각해보았다.

1. 해상도 품질 저하

• 영상 수가 늘어날수록 각 비디오를 축소해야 하므로, 출력 영상의 해상도는 필연적으로 낮아진다.
• 특히 hstack, vstack 등 필터를 연속 적용하면 누적적으로 화질 손실이 발생.
• 단순히 화면에 표시되는 문제가 아니라, 최종 인코딩된 영상 품질 자체가 낮아진다.

2. 디바이스 성능에 따라 품질/속도 편차

• WebAssembly 기반 FFmpeg는 사용자의 브라우저 성능에 직접적으로 의존한다.
• 고성능 PC에서는 무리 없이 동작하지만, 저사양 노트북, 태블릿, 모바일 브라우저에서는 처리 속도와 결과물 품질이 눈에 띄게 떨어질 수 있음.
• 게다가 브라우저 별 지원 범위나 메모리 제한도 변수로 작용한다.

3. 렌더링 UX 문제: 사용자 대기 시간 증가

• 클라이언트에서 직접 렌더링할 경우, 사용자는 편집 완료까지 계속 기다려야 한다는 단점이 있음.
• 영상 병합 시, 중간 로딩 없이 블로킹(blocking) 되기 때문에 UX에 악영향.
• 특히 대용량 영상(고화질 연주 영상 등) 편집 시, 수초 ~ 수십초 이상 대기가 필요할 수 있음.

즉, 모든 편집 과정을 프론트엔드에서 처리할지, 일부는 서버에 위임할지에 대한 구조적 판단이 필요하다. 특히 연주 영상을 스태킹할수록 퀄리티 저하가 심해지는 현상을 어떻게 보완할지는 다음 테스트 과제가 될 듯하다. 앱의 경우 클라이언트에서 렌더링하는 것이 기기 성능을 직접 활용하므로 더 빠르고 안정적인 렌더링이 가능할 수 있을 것 같다. 이것 또한 추후 과제로 테스트 해보기로 했다.

6/26(목):

iOS - FFMpeg 실행 성공적! 😎

드디어… 드디어! iOS에서 FFmpeg 바이너리 주입 및 빌드에 성공했다!

오랫동안 헤매던 ffmpeg-kit의 지원 중단 이슈를 아래 글을 참고해서 해결할 수 있었다.

바로 이 글 👇

https://medium.com/@nooruddinlakhani/resolved-ffmpegkit-retirement-issue-in-react-native-a-complete-guide-0f54b113b390

물론 full-gpl 패키지 인 점이 조금은 아쉽지만.. 우선 작동하는 바이너리와 구체적인 가이드라인이 있는 문서를 찾았다는 것에 만족하기로 했다.

 

이전에 XCode 실행부터 여러모로 아무것도 없는 react-native 빌드까지 너무 힘들었지만 결국 테스트까지 완료했다는 것에 뿌듯하다!! 우선 내가 겪은 트러블 슈팅만 간단하게 적어 보겠다.

TroubleShoot 1: build 시 with-environment.sh 를 찾을 수 없음

Xcode 빌드시 아래와 같은 에러 발생:

node_modules/react-native/scripts/with-environment.sh not found

https://stackoverflow.com/questions/44492197/react-native-ios-build-cant-find-node

 

📌 해결 방법:

• Build Phases에서 해당 스크립트 경로 수동 수정
• bundle exec pod install 다시 실행
• 모든 캐시 삭제 후 재빌드

TroubleShoot 2: 비디오 경로를 찾을 수 없음

처음엔 Xcode에 삽입한 파일 경로를 직접 입력했지만 작동하지 않았다.

→ 결국 캐시 디렉토리에 복사해서 경로를 참조하는 방식으로 우회 했다.

→ 이게 최선인지는 모르겠으나, 일단 된다!

import { Platform } from 'react-native';
import RNFS from 'react-native-fs';

export const copyAssetToCache = async (filename: string): Promise<string> => {
    const sourcePath =
    Platform.OS === 'ios'
        ? `${RNFS.MainBundlePath}/${filename}`
        : `assets://${filename}`;

    const destPath = `${RNFS.CachesDirectoryPath}/${filename}`;

    const exists = await RNFS.exists(destPath);
    if (!exists) {
    await RNFS.copyFile(sourcePath, destPath);
    console.log(`📦 Copied ${filename} to cache`);
    }

    return destPath;
};

1차 Side-by-Side Video Merge Test 완료

최종적으로, 두 개의 영상을 좌우로 합치는 테스트까지 성공적으로 마쳤다. 앱 내 FFmpeg 렌더링 파이프라인을 실제로 돌려본 건 처음이라 꽤 의미 있는 테스트였다.

6/27(금):

📱 Android FFmpeg 바이너리 모듈 삽입 구현 – 성공!

드디어 Android에서도 FFmpeg 실행이 가능하도록 바이너리 삽입을 성공적으로 마무리했다!! iOS에 이어 Android까지 연동이 완료되면서, 이제 FFmpeg 기반 영상 편집 기능이 양 플랫폼 모두에서 작동할 수 있는 기본 환경을 갖춘 셈이다. 정말 예상보다 훨씬 복잡하고 까다로웠다. 안드로이드 빌드는 한 번 돌릴 때마다 시간이 오래 걸리고, JDK 버전 충돌부터 Gradle 꼬임, Kotlin 오류까지 쉴 새 없이 터지는 에러들을 하나하나 잡아가며 캐시를 수십 번은 지운 것 같다. 그러다 결국 새벽 2시, 병합된 영상이 출력되는 걸 보자마자 자리에서 벌떡 일어나서 "꺅!!! 됐다!!!" 하고 소리를 질렀고, 바로 팀원들한테 영상 자랑하면서 모두가 “오 됐어??” 하며 축하해줘서 기분이 좋았다. 안되는 코드를 하루종일 바라보다가 결국 성공했을때! 그 순간이 코딩하면서 제일 짜릿한것 같다. 마치 처음 코딩을 배웠을때 Hello World를 처음 찍어본 기분이랄까? 팀원과 다 같이 기분좋게 웃으면서 퇴근했다.

📁 주요 수정 파일

• /android/app/build.gradle
• /android/build.gradle
• /android/src/main/assets/video.mp4 (테스트용 영상 삽입)
• /android/app/libs/에 .aar 바이너리 직접 추가
• node_modules/ffmpeg-kit-react-native/android/build.gradle
• scripts/patch-ffmpeg.js: FFmpeg 경로 자동 패치 스크립트

🔗 참고한 글

👉 Resolved FFmpegKit Retirement Issue in React Native

🐞 Troubleshooting 정리

1. JDK 버전 호환 문제

• JDK 24 → react-native-video@6.0.0 과 호환되지 않음
• JDK Zulu 17 설치 후, ~/.zshrc에 환경변수 추가

export JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home
export PATH="$JAVA_HOME/bin:$PATH"

2. Kotlin Null-safety Type Mismatch

Type mismatch: inferred type is 'ReadableMap?', but 'ReadableMap' was expected

• Kotlin 1.8 이상에서 타입 체크가 엄격해짐
• 해결 방법: react-native-video@6.0.0-alpha.11 버전으로 업그레이드

3. JVM Target 불일치 오류

Inconsistent JVM-target compatibility detected for tasks ...

• android/app/build.gradle 내에 kotlinOptions 추가:

kotlinOptions {
  jvmTarget = '17'
}

🔁 FFmpeg aar 자동 패치 스크립트

npm install 할 때마다 FFmpeg 모듈 경로를 못찾는 문제가 생겼고, 매번 수동으로 수정하는 건 너무 비효율적이라 자동 패치 스크립트 (patch-ffmpeg.js) 작성.

덕분에 이제 npm install 할 때마다 알아서 .aar 바이너리 붙여준다 😎

// package.json
"scripts": {
  "postinstall": "node scripts/patch-ffmpeg.js && cd android && ./gradlew downloadAar"
}

6/28(토):

기능 명세서 정리와 API 설계 준비

토요일은 비교적 조용하게 흘러갔다. 큰 구현 작업은 없었고, 주로 기능 명세서를 작성하고 전체 구조를 정리하는 데 시간을 썼다.

우리 팀장이 먼저 도커 기반의 서버 배포 환경을 세팅해줘서, 이제는 각자 역할에 따라 본격적으로 기능을 나눠서 구현해나갈 수 있는 상황이 되었고, 나는 앞으로 API 설계를 맡기로 했다. 사실 단순한 게시판 기능처럼 보여도, 막상 명세서를 작성하려고 보면 생각보다 고려할게 많았다. 와이어프레임만 봐도 구현해야 할 세부 기능들이 꽤 많았고, 사용자 흐름 하나하나를 실제 API로 어떻게 표현할지 정리하면서 설계의 중요성을 다시 느꼈다.

그리고 오늘은 특히, 이전에 팀원들이 개별적으로 작성했던 코드들을 다시 리뷰하면서, 어떤 구조로 테스트가 진행됐고, 이를 최대한 수정 없이 API 구성에 녹여낼 수 있을지 고민하는 시간이 되었다. 단순히 새로 짜기보다는, 기존 흐름을 잘 살리면서 서버 요청과 응답 구조를 정리하는 데에 집중했다.

구현은 없었지만 내가 맡은 역할을 구체화하고, 그 기반을 정비하는 데 의미 있는 하루였다. 작은 기능이라도 그 안에는 생각해야 할 맥락이 많고, 기획과 코드 사이를 연결하는 역할이 얼마나 중요한지를 새삼 깨달았다.

회식! 감성포차 레츠고

나만무가 시작한 지 딱 2주밖에 안 됐는데, 벌써 2차 회식 돌파! 일주일에 한 번은 거의 회식 타임인 것 같다 😅 저번 주엔 1팀이랑, 이번 주는 4팀이랑 같이 감성포차에서 회식했다. (우리 팀이 왜인지 인기가 많다..!)

감성포차는 소문대로 감성 분위기 뿜뿜에다 음식도 너무 맛있었다. 심지어 고양이도 봤는데 너무 귀여웠다! 사진을 못찍은게 살짝 아쉽다. 우리 반 사람들이 감성포차 김치가 그렇게 맛있다고 해서 너무 궁금했는데 정말 간만에 먹어보는 집 김치 맛이랄까? 근데 여기 와서 맵찔이가 되어버린 나에게는 살짝 매웠다 ㅠㅠ 훈제 삼겹, 파전, 계란말이, 만두전골, 똥집까지… 제대로 포식! 진짜 배터지게 먹었다ㅎㅎ 한 주에 한 번 힐링할 수 있어서 좋다!

6/29(일):

☀️ 일요일, 자유시간의 기록

일요일은 자유 시간!

전날에 너무 신나게 놀아서 그런지, 오후 3시쯤 되어서야 기어 나왔다. 진짜 전날 신나게 놀긴 했나 보다… 😅

오후 4시쯤 러닝을 다녀왔는데, 역시 여름은 여름인지 해가 떠있을때는 너무 덥다. 결국 3km 정도만 뛰고 집에 돌아왔다. 사실 원래 계획은 쥬시에서 아사이볼 하나 딱! 먹으면서 상큼하게 마무리하는 거였는데… 쥬시가 문을 닫았다 🥲 결국 오는 길에 아메리카노 하나만 들고 돌아왔다.

👩‍💻 저녁엔 API 개발 타임

오후 7시쯤 출근해서 API 개발에 집중했다.

오늘은 간단한 게시판용 CRUD API 기초를 만들었는데, ERD 설계를 같이 하다 보니 생각보다 머리 쓸 일이 많았다. 특히 중복 데이터 처리나 데이터 간 연관성을 어떻게 정리할지 고민이 많았는데, 이게 단순히 코드만 짜는 게 아니라, 전체 구조를 설계하고 조율하는 과정이라 그런지 은근히 재미있다.

게시글과 유저, 댓글 사이의 관계를 생각하다 보면 "이건 누가 갖고 있어야 하지?" "이건 중복돼도 되나?" 같은 질문들이 계속 떠올랐다. 또 지도 정보 같은 경우도 여러 곳에서 참조하는데, 어떻게 데이터베이스를 구성해야 간단한 드롭다운 목록 생성부터, 실제 위치 정보 반환까지 모든 정보를 하나의 테이블로 아우를 수 있을지 등 고민할 거리가 많았다. 아직은 작은 게시판 기능이지만, 데이터를 구조화하고 API로 연결해두면 그 위에서 많은 기능들을 쌓아갈 수 있다는 점에서 집을 짓기 위한 도로를 하나 하나 깔아가는 기분이랄까? 기초부터 설계하고 그림을 완성하는 과정이 재밌는 것 같다.

아직은 많이 부족하고 추가할 내용이 많지만.. 오늘까지 완성된 ERD 초안이다!