[회고] FLOS, 프로젝트 회고록

들어가기 전에....

안녕하세요, 개발자 1-hee 입니다.

오늘은 올해 1월 부터 약 7주간 진행한 프로젝트 회고록을 작성해 보려고 합니다.

아마추어 개발자 교육생 6명이 모여서 서비스 하나를 만들어보기 위해 고군분투 했던 이야기 지금 바로 시작해볼게요.

 

주제 선정

이번 프로젝트는 우리가 일상 속에서 사용하는 SNS를 주제로 새로운 서비스를 만드는 도전을 해보았습니다.

물론, 실제 SNS 서비스를 제공하려면 Facebook, Instagram, Tiktok이라는 거대한 기업에 도전하는 격이었지만, 우리 팀은 우리의 창의성을 무기로 프로젝트에 도전을 하기로 결정했습니다.

 

"남들에게 보여주기 위한 서비스가 아닌, 서로에게 공감하는 것에 중점을 둔 SNS를 만들어보자."

 

이 한마디가 이번 프로젝트에서 우리 팀이 추구했던 프로젝트 주제 선정의 이유입니다.

 

서비스명은 FLOS라고 지었고, 라틴어로 꽃이라는 의미를 가지고 있는데

역경을 이겨내고 피어나는 한 송이의 꽃처럼 우리의 SNS 활동이 긍정적인 선순환을 이루길 바라는 뜻을 담았습니다.

 

서비스 조사

이번 프로젝트는 s사에서 주관하는 개발자 아카데미에서 진행한 프로젝트인데, 다른 교육생들에게도 저희 서비스를 소개하고 주제의 타당성을 증명하기 위해 사전 조사와 발표자료를 열심히 만들었습니다.

 

아래는, 실제 발표에 사용했던 ppt 자료 중 일부를 발췌한 것입니다.

 

 

이번 발표에서 우리 팀이 강조하고 싶었던 것은 "SNS의 과시성" 을 해결해야 한다 라는 메세지의 전달이었습니다.

 

SNS는 빠르게 서로의 안부를 확인하고, 타인에게 나의 일상을 빠르게 공유할 수 있다는 장점도 있지만,

이런 인스턴트한 속성 때문에 그 취지가 변질되어 상대적 박탈감을 느끼는 등

사회적 부작용이 존재하므로 이 부분에 있어서는 꼭 개선해야 될 점이라고 생각했어요.

 

 

이번 발표에 사용한 자료에서도 위와 같이 기사의 헤드라인을 따와서

현재 SNS가 앓고 있는 사회적 문제를 해결고자 한다는 메세지를 전달하려고 노력했어요.

 

우리가 만든 SNS 서비스는 타인에게 보여지기 위한 서비스가 아닌,

상호 간에 존중을 바탕으로 진실된 소통이 실현되는 플랫폼을 만들고 싶었습니다.

 

그래서 네이버의 CLOVA Sentiment API를 사용했고,

사용자가 작성한 게시글에서 감정을 분석한 뒤,

직접 만든 마스코트와 함께 사용자에게 피드백을 주어 흥미와 호기심을 유발할 전략이었죠.

 

FLOS의 마스코트 구름이가 감정분석 결과를 사용자에게 안내하는 장면

 

 

---

 

아래 이미지는 저희 프로젝트에서 사용했던 네이버의 CLOVA API의 개발자 문서 캡처본 입니다.

역시 큰 서비스 기업에서 제공하는 기능이라 그런지 성능은 정말 훌륭했어요.

 

 

 

📝 NAVER CLOVA Sentiment API 가이드 문서

https://api.ncloud-docs.com/docs/ai-naver-clovasentiment-api

감정분석

 

---

 

서비스 설계의 시작, Figma

코드로 화면을 구현하고 기능을 개발하기 전에,

우리팀의 프론트엔드 개발자 팀원들은 UX/UI 디자이너로서의 역량도 힘껏 펼쳐 보았습니다.

이때 적극적으로 사용한 것이 바로 Figma였습니다. 이때만 해도 단순 디자인 툴이라고만 생각했었는데,

게시글을 작성하는 지금은 이때보다 더 성능이 강력해졌더라고요..😲

 

Figma를 사용해 화면을 설계하는 것에 공을 들였던 이유는,

건축에서도 건물을 짓기 전 상세한 도면이 중요하듯이

소프트웨어도 서비스를 만들기 전 설계하는 작업이 매우 중요하다고 생각했기 때문입니다.

 

 

위의 사진은 지난 7주 동안의 프로젝트를 위해 피그마에서 열심히 노력했던

우리 팀의 흔적이 가득 남아있는 피그마의 한 페이지를 캡처한 것입니다. 😀

 

---

프로젝트를 하면서 어려웠던 점은?

 

원격 저장소를 생성하고 함께 협업을 할 때, 예상치 못한 다양한 어려움이 있었어요.

구체적으로,  원격 저장소로부터 각자의 계정명으로 분기한 브랜치로부터 develop 이라는 개발 브랜치로 합치는 과정에서 자주 충돌(conflict)가 발생했었습니다.

 

이처럼 병합하는 과정에서 한번 충돌이 한번 발생하면 이를 해결하느라 많은 시간이 소모되었습니다.

 

이때 가장 주의를 기울인 부분은 다른 팀원의 작업 이력이 사라지지 않도록 잘 병합하느라 바쁘게 소통하고 문제를 해결했던 경험이 생생하네요.

 

이때 원격 저장소로는 깃랩(GitLab)을 사용했는데,

원격 저장소를 통해 여러 명의 개발자가 함께 일하는 경험이 처음인지라 어떤 방법이 좋은 것인지 판단이 어려웠습니다.

그래서, 저보다 경험이 많았던 컴퓨터 공학과 친구에게 많이 물어보기도 했고 구글에 검색도 하면서 배움을 통해 판단의 기준을 수립하고 경험으로부터 배운 노하우를 쌓으려고 노력했습니다.

 

이때 시도했던 전략 중에는 다른 팀원들은 개발에만 집중할 수 있도록 일부로 제 브랜치 쪽으로 충돌이 발생하게 유도하여 해결한 적이 많았습니다.

 

그런데, 지금 와서 생각해보니 이 또한 경험의 부족으로 다소 무식한(?) 방법을 채택했었던 것 같네요.

 

그래도 나중에는 팀원들과 함께 일종의 업무 규칙을 설정해서 커밋 푸시의 주기, 단위 등을 협의하였는데,

이 때 상호 간에 잘 협의했던 것이 브랜치 관리에 아주 결정적으로 도움이 되었고,

충돌의 발생 횟수를 획기적으로 줄여서 팀 전체의 생산성이 오르는 성취도 달성했습니다.

---

프로젝트를 하면서 느낀점

이번 프로젝트는 다른 교육생들에게 설명하는 중간 발표 시간을 가졌었는데,

서비스에 대해서 긍정적으로 평가한 사람들도 있는 반면에 회의적으로 피드백을 준 사람도 있었습니다.

그 중 기억에 남았던 평가는 '식물 키우기 서비스 아닌가요' 라는 피드백이었는데,
서비스를 기획하면서 너무 팀원끼리만 아이디어를 공유하고 다른 사람의 의견이나 피드백은 받아보려 하지 않았구나 하는 반성을 하게 되었고 프로젝트의 감성이나 컨셉도 중요하지만 합리적인 부분도 어필 되는 것이 중요하다는 것을 배울 수 있었습니다.

 

그리고 이번 프로젝트를 통해 리액트(React) 프레임워크를 비롯한 프론트엔드 분야의 다양한 기술 스텍에 익숙해지고 사용자의 경험을 고려하며 서비스를 개발하는 사용자 중심의 개발을 경험해볼 수 있어서 좋았습니다.

 

그리고 이러한 배움의 기회는 혼자가 아닌 함께였기에 얻을 수 있었다는 생각이 들었습니다.

 

이상으로 회고록은 마치도록 할게요.

긴글 읽어주셔서 감사합니다 😀