프로젝트 소개

PRP - for your Portrait Right Protection 프로젝트는 2022-07 ~ 2022-08 약 5주에 걸쳐 진행했던 프로젝트입니다.

제목을 보고 어느 정도 유추가 가능하실까요? 말 그대로 저작권을 보호할 수 있게 도와주는 서비스입니다.

사용자는 모자이크 처리할 영상과 모자이크를 처리하지 않을 사람의 이미지를 추가로 업로드하여 선택한 효과에 맞는 처리 결과를 사용자에게 제공합니다.

자세한 내용은 하단의 링크 확인을 부탁드립니다.

github

medium

맡은 역할 & 기능

제가 맡았던 역할은 프론트엔드입니다. 웹 프레임워크로는 React를 사용하였으며 그 밖에 AWS의 배포 및 Docker 설정, AI의 기본적인 틀을 잡는 역할을 수행하였습니다.

특히 Fimga를 사용해 UX/UI디자인도 진행해보는 경험도 겪어보았습니다. (비록 제가 디자인했던 페이지는 선택되지 않았지만요 ..ㅜ)

기본적으로 앞에서 수행했던 프로젝트와 마찬가지로 Notion을 통해 진행 상황과 스프린트를 정리하였으며 5주 동안 매일 Zoom을 통해 팀원과 협업하며 프로젝트를 진행하였습니다.

좋았던 점 & 얻은 것

  1. 코딩 규칙에 대한 정확한 명명

    본격적인 프로젝트를 진행하기 이전 팀에서 바로 진행했던 사항이 있습니다. 바로 변수명, 주석, 깃 commit 규칙과 같은 코딩 규칙을 정확히하고 팀원과 통일하는 작업이었습니다.

    prp-1

    prp-2

    codeStyle외에도 위 사진과 같이 변수 이름의 규칙을 명시할 뿐 아니라 주석을 달 때에도 어떤식으로 정리할지 사전에 정의해두었기 때문에

    향후 서로의 코드를 리뷰하거나 코드를 리펙토링할 때 효과적으로 진행할 수 있었던 것 같습니다.

    다소 귀찮고 불필요한 작업이라고 생각할 수도 있겠지만 장기적으로 보았을 때 정말 좋은 선택이였다고 생각합니다.

  2. 눈치 보지 않는 의견제시와 잦은 의견 충돌

    프로젝트 마감 7일전 프론트엔드에서 구현했던 모든 디자인들을 다 버리고 새롭게 디자인을 갈아엎었습니다.

    물론 당시에는 반대 의견도 있었지만 절충안을 선택하고 팀원분들께서 개의치 않고 적극적으로 개선 방향에 대한 의견을 제시하며 결국 깔끔한 디자인의 결과물을 산출할 수 있었습니다.

    그 밖에도 수많은 의견 충돌이 많았습니다. 하단의 사진은 그중 하나의 예시입니다.

    prp-3

    저는 초기에 API 횟수를 불필요하게 줄이는 게 좋다고 생각해서 위, 아래의 API를 한 번에 받는 게 좋겠다고 생각했었습니다.

    하지만 팀원분의 의견을 듣고 결국 따로따로 API를 호출하도록 설계하였는데요 오히려 비동기 처리를 할 때 먼저 로딩되는 이미지만 사용자에게 빨리 보여줄 수 있어서 분리하는 게 좋은 선택이라고 생각하게 되었습니다.

    결국 의사소통이 얼마나 중요하고 또 이런 의사소통이 활발하게 이뤄지는 분위기 조성과 환경이 단순한 코딩 작업 외에도 중요하다는 것을 배우게 되었습니다.

  3. 처리 결과의 비동기 처리

    사실 숨기고 싶었지만.. 저희 프로젝트의 영상처리 시간은 상당히 긴 시간이 걸립니다.

    단순히 사용자에게 처리되는 시간동안 로딩창을 보여주기에도 적절하다고 생각하지 않았기 때문에 결과 페이지에서 현재 작업중인 영상의 개수를 알려주고 사용자가 기다리는 동안 얼마든지 새로운 task를 진행할 수 있도록 Celery와 RabbitMQ를 사용한 비동기처리를 구현하였습니다.

    prp-4

    어떤 이유에서 비동기를 사용하였고 그 결과 사용자에게 어떤 식으로 데이터를 보여주고 처리할지 설계하는 과정을 통해 비동기 처리의 이점과 방법에 대한 구체적인 경험을 쌓을 수 있었습니다.

아쉬웠던 점

  1. 로딩 시간의 긴 시간

    앞서 장점에서 소개해 드렸던 부분이기도 하지만 결국 오랜 처리시간은 명확한 단점임이 틀림없습니다.

    아무래도 AI보다는 기능구현에 시간을 많이 사용했기 때문에 초기의 개선사항이였던 소리합성 문제는 해결하였지만 처리 시간까지는 개선하지 못해 아주 아쉬웠습니다.

    결국은 직접 AI를 학습시키지 않고 이미 만들어진 라이브러리를 사용했기 때문의 개선 방향에도 한계점이 있었던 것 같습니다.

    따라서 라이브러리를 가져다가 사용할 때는 커스터마이징을 하는데 한계점이 있을 수 있다는 단점을 충분히 이해하고 개발하는 데 사용해야 할 것 같습니다.

  2. 초기 설계의 미흡함이 불러온 대참사

    프로젝트 마감이 얼마남지 않은 시점에 DB스키마를 전부 뒤엎고 이에따라 프론트와 백엔드의 코드 수정이 대폭 진행됬던 시기가 있었습니다.

    설계를 할 때 큰 맥락에서 보지 않고 사용자의 입장에서 사용하지 않을 기능을 기준으로, 조금 더 편한 방향으로 스키마를 설계했기 때문이였습니다.

    당연히 이미 진행된 코드를 전부 수정하느라 더 많은 시간이 사용되었습니다.

    (그만큼 팀원들의 수면시간이 줄어들었습니다..)

    향후에는 초반 틀을 잡는 데 시간이 더 걸리더라도 꼼꼼하고 확실하게 백엔드 프론트엔드 가리지 않고 팀원 모두가 적극적으로 검토하고 확인하여 기반을 탄탄히 잡도록 해야겠다고 다짐하게 되었습니다.

마치며

제 MBTI는 ISFJ입니다. 갑자기 웬 뜬금없는 이야기냐고요? 성격도 조용조용하기 때문에 평소에 크게 생각하지 않았지만, 이번 프로젝트를 통해 크게 느낀 점이 있다면 바로 팀 분위기의 중요성입니다.

자유롭게 의견을 주고받을 수 있는 분위기가 개발 외적으로도 프로젝트에 긍정적인 영향을 미친다고 크게 느꼈고 이런 분위기 형성을 위한 말과 행동이 필요하다고 깊이 생각했기 때문입니다.

따라서 향후 프로젝트를 진행할 때 기술적 역량뿐 아니라 협업을 위한 자세와 태도도 충분히 배우고 공부해야 할 필요성이 있음을 인지하고 노력하려고 합니다🙂

카테고리:

업데이트:

댓글남기기