프로젝트 소개
우리 팀은 AI기업과 연계 프로젝트를 했다. 기업에서 제공하는 서비스는 클라이언트가 음성과 아바타를 선택하면 ai가 해당 음성과 아바타로 정해진 대사를 말하는 영상이 만들어진다. 기업에 기존 웹서비스는 기초적인 모습이였다. 그래서 클라이언트에게 더 나은 서비스 제공이 목표였고 우리는 디자인팀, 프론트엔드팀, 백엔드팀이 모여서 함께 문제를 해결해갔다.
(기업에서 IA, 와이어프레임, API를 제공받았습니다.)
서비스 파트
- 렌딩 페이지
메인 페이지이다. 기업을 소개하고 로그인, 로그아웃을 할 수 있고 프로젝트 생성과 히스토리로 이동할 수 있다. - 회원가입 / 로그인
JWT 기반으로 회원 인증을 하도록 토큰을 발급한다. 소셜 로그인을 구현했다. - 히스토리
만든 프로젝트와 생성한 영상을 확인할 수 있다. 이름 수정, 다운로드, 삭제를 할 수 있다. - 프로젝트 작업 페이지
총 3단계로 텍스트 입력, 텍스트 수정, 아바타 생성으로 나뉜다.
프로젝트의 목적은 클라이언트에게 더 높은 편의성을 제공하는 것이다. 그래서 디자인팀은 기업에서 준 와이어프레임에 각 단계별 페이지 이동이 아닌 프로젝트 작업 페이지 3단계를 한 페이지에서 작업할 수 있도록 디자인을 했다. 그리고 디자인팀 이슈로 프론트엔드 팀에서 디자인을 직접 하기도 했다.
역할
- 히스토리
- 프로젝트 작업 페이지
- 네비게이션 바
- 텍스트 입력
- 아바타 미리보기
- 음성 모델
- 음성 업로드
- 음성 옵션
- 음성 다운로드
- 영상 합성
(기업에서 오해의 소지를 방지하기 위해 기업명을 명시하지 말아달라는 요청을 받아 가렸습니다.)
챌린지
음성 업로드
사용자가 업로드한 오디오 파일을 서버와 어떻게 주고 받을지에 대해 처음 구현해보는 기능이여서 백엔드와 함께 의논하며 방법을 찾아갔다.
서버에서 binary 타입이 필요했고 blob 데이터를 보내면 될거라고 판단했다. 하지만 blob만으로는 서버에서 받지 못했고 다시 생각한 방법으로 base64 인코딩을 해서 ArratBuffer, TypeArray로 blob을 재생성 했다. 하지만 문제 해결을 하지 못하고 논의를 다시 했다.
우리에게 필요한 데이터 타입이 어떤 것인지, 데이터의 목적이 무엇인지, 추후에 프론트에서 어떻게 쓰일지를 정리를 했다. binary type이면서 서버로 전송 가능한건 무엇인지 고민했고 이 고민을 토대로 이전에 찾지 못했던 form 태그의 활용성을 알게 됐다. Multipart/form-data enctype으로 File 객체를 담은 form 데이터를 전송했다.
정확한 목적을 알고 지금 필요한 정보가 무엇인지 판단이 되었다면 문제 해결에 더 가까워지는 것을 경험을 할 수 있었다.
업로드 전
업로드 후
보완점
리뷰문화
서로 코드를 보고서 리뷰를 하지 못해서 아쉽다. 그저 응원과 소감을 적는 정도로만 리뷰가 끝나다보니 그 점이 아쉬웠다. 하지만 직접 대면으로 나에게 모르는 것을 질문하고 찾아봐주고 도와주는 시간이 있었어서 PR에서도 그런 기록이 남고 보완해 갔으면 좋았을거 같다.
반응형 디자인
반응형이 되기 위한 구조를 기획에서 설계하지 못했다. 디자인팀의 이슈 등 시간이 부족했고 어려움이 많았다고 생각한다. 반응형과 적응형 중 선택을 하고 추후 유지보수 또는 추가 개발이 이뤄질 상황을 대비해서 설계에 결정이 되고 설계가 됐어야 했다는 보완점이 있었다.
웹 성능
memo, useMemo, 로직 간결화 등 리팩토링을 했지만 많이 부족하다. 우선 나는 이번 프로젝트에서 React.memo와 useMemo를 처음 사용해봤는데 올바르게 사용하지 못했다. React.memo로 래핑할땐 props 값의 변화를 생각하지 못하고 무분별하게 사용이 되서 성능이 오히려 저하된듯하다. Lighthouse 성능 검사에 Perfomance 점수가 이전 점수보다 더 낮게 나온것을 확인했다. 확실히 공부를 해야겠다는 계획을 가지게 됐다. 그리고 이미지 최적화와 여러 방면에서 성능이 향상되는 방법을 찾아 보지 못했다.
UX
react suspense로 Progress Indicator 구현을 사용하지 못했다. 음성 모델에 경우 API 지연시간이 1초 미만이다. 그래서 Progress Indicator 주요 지침에 맞지 않고 오히려 사용자에게 거슬리는 경험을 주게 됐다. 히스토리 조회와 프로젝트 생성시 프로젝트 조회는 1.3s가 걸린다. 렌더링이 이뤄지고서 로딩 애니메이션이 시작된다. react suspense를 활용해 더 사용자 경험을 높일 수 있는 보완점이 된다.
팀 협업
이번 프로젝트 이전에 두 번 팀 협업 경험을 해봤다. 이전까지는 개발 팀 협업이 어떤 플로우로 진행되는지 감만 잡혀있던 느낌이었는데 이번엔 두 번의 경험을 토대로 계획을 세우고 소통을 하고 컨벤션을 지킨 거 같다. 다 끝나고서 느낀 점은 소통의 중요성이다. 프로젝트 초반부터 디자인팀 내에서 소통 이슈가 생겨서 계획에 차질이 생기고 중후반부터는 디자인팀에서 가장 적극적이셨던 분은 교통사고 나고 다른 팀원들은 한 가지 소통하는 데 이틀이 걸리는 이슈로 인해서 상당히 답답했다. 문제를 해결할 수 있는 능력보다 소통하려는 의지, 적극성이 더 필요한 능력이 아닐까 하는 생각이 들기도 했다.
백엔드 팀과 협업은 좋은 경험이 되었다. 서버에서 로직이 처리되어야 하는 데이터를 요청하고 프론트에서 전송되어야 하는 데이터를 요청받는 소통에서 서로에게 좋은 영향을 끼친거 같다. 음성 업로드를 개발할 때에 폼데이터를 어떻게 받을지, base64로 인코딩을 해야 하는지 등 많은 소통이 있었다. 백엔드에게 어떻게 요청해야 하고 소통을 해야 하는지 배울 수 있었다. 백엔드 팀원들 덕에 프로젝트 경험과 결과물이 뿌듯함에 이를 수 있었다고 생각한다.
프론트팀 협업은 사람들도 좋고 끝까지 따라와 줘서 고마웠다. 그러면서도 아쉬운 점이 있는 것은 팀원 간에 서로 도움을 주고받는 과정과 리뷰 문화가 잘 이뤄지지 않은 거 같다. 아무래도 이 프로젝트에서 팀원들 스스로 부족함을 많이 느끼다 보니 리뷰 문화를 가질 여유가 없다고 생각이 들었나 보다. 내가 가능한 최대한 도움을 줬지만 조금의 아쉬움이 있다.
나를 많이 돌아볼 수 있었다. 소통과는 별개로 팀 내에서 나의 책임을 다하기 위해서 의지와 실력이 보장돼있어야 한다는 생각이 들었다. 팀 내에서 내가 팀원을 도울 수 있는 능력이 있을 수 있고 내 역할에 책임을 다해서 팀원, 프로젝트에 민폐가 되지 않는 것이 최소한의 팀에 소속된 팀원의 자세이지 않을까 생각했다. 이번 프로젝트도 어려움이 있었고 개발 고민도 많았다. 이전 프로젝트를 하면서도 똑같이 어려움이 있었고 개발 고민도 있었지만 차이점이 있다면 고민의 시간이 길면 오히려 독이 되는 것을 알고 있었다. 개발 고민이 길어지지 않도록 이번 프로젝트를 진행했다. 그래서 나의 목표를 달성하고 팀원들을 도와줄 수 있었고 프로젝트를 마무리할 수 있었다.
