시연 영상
0. 프로젝트 소개
프로젝트명: Samadhi - 실시간 요가 자세 분석 서비스
기간: 2025.09 - 2025.12 (약 4개월)
팀 구성: 5인
Samadhi는 웹캠 영상과 화면 공유 영상을 활용해 사용자의 요가 자세를 기준 영상과 실시간으로 비교·분석하는 웹 기반 서비스입니다. 별도의 앱 설치 없이 브라우저만으로 사용 가능하며, 영상 데이터는 서버로 전송하지 않고 클라이언트 단에서 즉시 처리됩니다.
4개월간 5인 팀을 이끌며 서비스를 개발했고, 그 결과 IA × AI 해커톤 장려상 수상과 총 6회의 대외 발표를 성공적으로 진행했습니다.
핵심 특징
- MediaPipe를 브라우저에서 직접 실행
- 화면 공유 방식으로 유튜브 등 사용자가 원하는 영상 사용 가능
- 관절 좌표 + 관절 각도 기반 실시간 유사도 점수 제공
- 40가지 요가 자세 자동 인식 및 타임라인 기록
나의 역할
- 팀장: 4개월 프로젝트 일정 설계, Notion 기반 태스크 관리 및 회의 주도
- 프론트엔드 리드: MediaPipe 통합, 실시간 랜드마크 검출·시각화
- 기술 의사결정: Screen Capture 방식 채택, 온디바이스 추론 구조 설계
- 대외 활동: 제안~최종까지 6회 공식 발표 주도
팀 구성
1. 프로젝트 배경
기존 AI 홈트레이닝 서비스는 제공되는 자체 콘텐츠 안에서만 동작한다는 한계가 있었습니다.
실제 사용자들은 유튜브와 같은 외부 운동 영상을 보며 운동하는 경우가 많지만,
이 과정에서 자세 교정에 대한 피드백을 받을 방법이 없었습니다.
요가는 동작이 비교적 정적이고, 관절 정렬과 각도가 중요하며, 표준화된 자세 정의가 존재해
실시간 자세 분석에 특히 적합한 운동입니다.
이에 따라 저희는 사용자가 선택한 영상과 자신의 자세를 웹 브라우저에서 즉시 비교할 수 있는
실시간 요가 자세 분석 서비스 Samadhi를 기획했습니다.
2. 아키텍처 및 기술 스택
Samadhi는 브라우저 단에서 실시간 영상 처리와 추론이 모두 이루어지는 구조로 설계했습니다. 영상 스트림 → 자세 추론 → 시각화까지의 전 과정을 클라이언트에서 처리해 지연 없이 즉각적인 피드백을 제공하는 것이 목표였습니다.
MediaPipe
MediaPipe는 브라우저에서 직접 실행 가능한 자세 추론 라이브러리로, 실시간 처리에 필요한 성능과 안정성을 모두 만족했습니다. 특히 BlazePose 모델은 요가처럼 정적인 동작이 많은 환경에서 랜드마크 안정성이 높아, 실시간 자세 비교와 시각화에 가장 적합하다고 판단했습니다.
Next.js
Next.js를 사용해 SSR과 CSR을 상황에 맞게 분리하고, MediaPipe처럼 브라우저 API에 강하게 의존하는 로직을 클라이언트 영역으로 명확히 분리했습니다. use client 지시어를 통해 영상 처리·Canvas 렌더링 로직이 서버 렌더링에 포함되지 않도록 설계해 예측 가능한 실행 환경을 유지했습니다.
Zustand
실시간 Canvas 렌더링 환경에서는 불필요한 리렌더링 자체가 성능 저하로 직결됩니다. Zustand는 보일러플레이트가 적고 선택적 상태 구독이 가능해 실시간 처리에 필요한 최소한의 상태만 구독하도록 설계하기에 적합했습니다.
3. 상태 관리 전략
실시간 처리를 안정적으로 유지하기 위해 입력 소스별 상태를 명확히 분리했습니다.
poseStore.ts에서- 웹캠
- 이미지
- 영상
각 소스의 상태를 독립적으로 관리해, 업데이트 주기가 달라도 서로 간섭하지 않도록 설계했습니다.
또한 Zustand의 선택적 구독을 활용해 스켈레톤을 그리는 Canvas 컴포넌트만 필요한 상태를 구독하도록 구성했습니다. 이를 통해 React 리렌더링 비용을 최소화하고, 실시간 시각화 성능을 안정적으로 유지할 수 있었습니다.
4. 에피소드
(1) 팀 리딩 및 프로젝트 진행
1. 상황
4개월간 진행된 프로젝트의 팀장으로서 단순 개발을 넘어 프로젝트의 완성도와 외부 평가를 통해 가치를 검증하는 데 주력했습니다.
팀원마다 기술 관심사와 속도가 달라 방향이 흔들릴 수 있었는데, 주차별 목표와 산출물을 명확히 정의해 공통 목표를 유지하려 노력했습니다. 특히 기술 실험과 발표 준비를 병행해야 해서 우선순위를 조율하는 것이 가장 어려웠습니다.
2. 행동
- 명확한 목표 설정 및 팀원 역할 분배
- Notion을 활용한 체계적인 일정 및 산출물 관리
- 제안 발표, 1·2차 중간 점검, 해커톤 발표, 최종 발표 등 총 6회의 공식 발표 자료 작성 및 발표 진행
3. 결과
- IA x AI 해커톤 장려상 수상
- 교내 부스 운영을 통한 서비스 시연
(2) 화면 공유 기반 영상 입력 처리
1. 상황
초기에는 유튜브 영상을 iframe 또는 video 태그로 임베딩해 분석하려 했으나, 유튜브의 동일 출처 정책(CORS)으로 인해 영상 픽셀 데이터에 접근할 수 없었습니다.
MediaPipe는 프레임 단위 이미지 입력이 필요하기 때문에 iframe 기반 유튜브 영상은 기술적으로 분석이 불가능했습니다.
2. 행동
입력 방식을 DOM 요소가 아닌 MediaStream 레벨로 전환했습니다.
브라우저가 제공하는 Screen Capture API를 활용해 사용자가 보고 있는 탭 화면을 직접 비디오 스트림으로 받아 MediaPipe의 입력으로 전달하도록 설계를 변경했습니다.
이 방식으로 플랫폼에 상관없이 모든 웹 영상을 동일한 파이프라인으로 처리할 수 있게 되었습니다.
3. 결과
- 특정 플랫폼에 종속되지 않는 범용 자세 분석 구조 확보
- 영상 업로드 서비스가 아닌 실시간 시청 화면 분석 서비스로 서비스 정체성 명확화
아쉬운 점
탭 전환이나 화면 가림 시 스트림이 중단되는 경우에 대한 UX 예외 처리를 충분히 하지 못했습니다. 향후 visibilitychange 이벤트와 스트림 상태 감지를 통해 보완할 계획입니다.
(3) 브라우저 환경에서의 추론 성능 점검
1. 상황
실시간 포즈 분석 서비스 특성상 브라우저 메인 스레드에서 MediaPipe 추론, Canvas 렌더링, React 상태 업데이트가 동시에 실행되는 구조였습니다.
MediaPipe의 detectForVideo는 한 프레임당 수십 ms가 소요되었고, 이를 requestAnimationFrame 루프 안에서 Canvas 렌더링과 함께 처리하자 UI 프리징과 FPS 드랍이 발생했습니다. 특히 추론 로직이 메인 스레드를 블로킹하면서 렌더링 안정성이 가장 큰 병목으로 드러났습니다.
2. 행동
병목을 해소하기 위해 Web Worker로 추론을 분리하는 구조를 실험했습니다.
- 메인 스레드: 화면 렌더링과 사용자 인터랙션 담당
- Worker 스레드: 포즈 추정 및 계산 로직 담당
그러나 단순 분리는 만능 해결책이 아니었습니다. ImageBitmap 전송과 메시지 직렬화 과정에서 예상보다 큰 오버헤드가 발생했고, 프레임 동기화가 어긋날 경우 Race Condition이 생길 수 있음을 확인했습니다.
이 과정에서 “무조건 스레드를 분리하는 것”보다 렌더링과 연산의 책임을 명확히 나누고, 프레임 기준을 분리하는 것이 더 중요하다는 결론에 도달했습니다.
최종 구조
- Main Thread
- 60fps Canvas 렌더링
- 각 입력 소스의 ImageBitmap 생성
- 워커 결과 수신 후 스켈레톤 및 피드백 시각화
- Webcam Pose Worker
- 웹캠 스트림 기반 포즈 추정
- 관절 좌표 및 각도 계산
- Screen Capture Pose Worker
- 화면 공유 스트림 기반 포즈 추정
- 기준 영상 자세 분석 및 타임라인 기록
추론 결과는 프레임마다 동기화하지 않고, 가장 최근 결과를 기준으로 렌더링에 반영하는 방식으로 설계했습니다.
3. 결과
- 렌더링 프레임: 60fps 안정 유지
- 포즈 추정 빈도: 약 30fps 유지
- 스레드 간 통신 오버헤드: 평균 약 9ms
시각적 피드백의 부드러움과 분석 정확도 사이의 균형을 확보할 수 있었고, 실제 사용자 환경에서 체감 성능이 유의미하게 개선되었습니다.
학습
- 비동기 메시지 처리는 단순 분리가 아니라 동기화 전략 설계의 문제임을 체감했습니다.
- 개발 기기의 성능이 병목을 가릴 수 있어, 다양한 환경에서의 성능 점검이 중요하다는 점을 배웠습니다.
- 클라이언트 사이드 추론은 성능·기기 편차라는 명확한 한계를 가진다는 점을 인식하게 되었습니다.
개선 방향
향후에는 저사양 기기 대응을 위해
- 서버 사이드 추론을 보조적으로 활용하는 하이브리드 구조
- MediaPipe 경량 모델 또는 WebAssembly 최적화 를 함께 검토해볼 수 있다고 생각합니다.
5. 회고 및 향후 개선 방향
1. 성과
- 4개월간 팀을 리딩하며 해커톤 수상, 총 6회의 공식 발표 등 대외 성과 창출
- MediaPipe와 Screen Capture API를 결합해 범용 영상 기반 자세 분석 서비스 구현
- Zustand의 선택적 구독을 활용해 실시간 Canvas 렌더링 환경에서도 안정적인 상태 관리 구조 설계
2. 개선 방향
- 저사양 기기 대응:
모든 연산을 클라이언트에서 처리하는 구조의 한계를 경험한 만큼, 서버 사이드 추론 또는 클라이언트–서버 혼합 구조를 함께 설계해 기기 성능에 따른 편차를 완화하고 싶습니다. - UX 고도화:
화면 공유 중단, 탭 전환 등 Screen Capture API 특유의 예외 상황에 대해 스트림 상태 감지 및 사용자 피드백을 강화할 필요가 있습니다. - 성능 최적화:
Web Worker를 무조건 분리하는 방식이 아닌, 실제 병목 지점을 기준으로 한 프로파일링 기반 최적화 전략을 적용하고자 합니다.
3. 배운 점
이번 프로젝트를 통해 기술 선택은 단순한 구현 가능 여부가 아니라 성능, 사용자 환경, 확장성까지 고려한 트레이드오프의 문제임을 깊이 이해하게 되었습니다.
브라우저 단 추론을 직접 설계하고 한계를 체감했기 때문에, 이후 프로젝트에서는 상황에 따라 클라이언트 추론과 서버 추론을 선택·조합할 수 있는 아키텍처를 설계하는 것이 더 바람직하다고 판단하게 되었습니다.
또한 팀 프로젝트에서 명확한 목표 설정과 커뮤니케이션, 그리고 우선순위 관리가 기술적 완성도만큼 중요하다는 점을 체감한 경험이었습니다.