[SSAFY] 2학기 자율프로젝트 : Alert You

작성:    

업데이트:

카테고리:

태그: ,

들어가기

프로젝트 정보


프로젝트 과정

팀 구성

자율 프로젝트는 특화 프로젝트부터 다음에 같이 팀을 하자고 장난스럽게 구애한 시원이 형이 진심으로 제안해준 덕분에 처음으로 팀원으로서 SSAFY 프로젝트에 마음 편하게 참여할 수 있었다. 서른 살, 직장생활 경력자였던 시원이 형의 리더십과 성격을 잘 알았기 때문에 의심의 여지 없이 믿고 맡길 수 있는 팀장이라고 생각했다.

팀원은 1학기 때 대전 2반이었던 비전공자들끼리 모였고, 프론트 3명, 백엔드 3명의 일반적인 비율로 구성했다. 나는 프론트 개발 리드를 담당했고, 프론트 리더로서 두 형님들을 이끌고 프론트 개발을 진행했다. 사실상 3명이 공동 리더인 것처럼 두 분 모두 너무나 적극적인 성격이셔서 리더로서 특별히 힘들게 없었고 어려울 것도 없었다.


도메인 및 기술 스택 선정

역시나 프로젝트의 첫 단추인 아이템 선정은 고민이 많았다. 나는 사실 아이템은 상관 없었고, 유일한 욕심으로는 기술 스택으로 React를 사용해보고 싶다는 것이었다. 사실상 도메인을 크게 타지 않을 것이라 판단했기 때문에 다양한 아이디어들을 제시했다.


수많은 아이디어들이 오고가는 사이에서 학교 폭력 신고와 관련된 서비스로 계획이 결정되며 방향을 잡았는데, 긴급 신고나 녹음 등 서비스 성격에 필수적인 기능들의 구현을 미리 생각해보니 웹 서비스보다는 디바이스를 더 활용하기 좋은 어플리케이션을 메인으로 개발하게 되었다.

프로젝트에서 React를 사용해보지 못했기 때문에 React Native를 활용하는 방향으로 이끌었고, 마침 프론트 팀원들 모두 React를 프로젝트에 활용해보았으며, React Native를 활용해본 경험이 있는 팀원이 있었기 때문에 설득력을 얻었다. 결국 RN을 활용한 어플리케이션 개발로 방향을 잡을 수 있었다.


하지만 React를 활용한 웹 서비스 개발과는 성격이 다소 다를 수 있었기 때문에 React를 활용한 랜딩 및 서비스 소개 페이지에 대한 추가 개발을 기획하여 내가 웹 개발을 담당하게 되었다.(하지만 작업 공수나 서비스 성격을 고려하니 별도의 웹 페이지가 불필요하다고 판단되어 이를 제외하고 RN 개발에 집중하게 된다.)


개발 과정

학교 폭력과 관련된 서비스이다 보니, 기획적인 부분에 정말 많이 신경을 썼다. 정확히는 사용자의 입장에서 생각해보는 것이 정말 필요했다.


  1. 악용하면 어떡해?

우리 서비스는 학교 폭력 피해자 뿐만이 아니라 가해자도 설치할 수 있을 것이다.

  • 피해자의 신고 위치가 드러난다면 선생님이나 신고 접수자가 현장에 도달해 피해자를 구조하기 이전에 가해자가 신고자를 찾아내 보복하면 어떡하지?
  • 선생님에게 신고를 할만큼 큰 사건이 아니어서 주변 친구들에게 도움을 요청하려고 한다면, 가해자가 피해자에게 강제로 친구를 맺어서 자신만의 노예로 만들 듯 호출을 하면 어떡하지?
  • 허위신고를 많이 한 학생들에 대해 신고 기능을 무력화할 때 가해자가 피해자들에게 강제로 허위 신고를 많이 누적해서 신고 기능을 무력화하면 어떡하지?

등 가해자의 악용 사례에 대한 대비를 하며 기능을 작지만 탄탄하게 개발해야 했다.


  1. 적용 범위는?

긴급 신고를 하게 된다면 신고는 누구에게 가는 게 맞는 것인가에 대한 고민을 많이 했다. 담임 선생님인가? 학생부장 선생님인가? 학교 경찰인가, 지역 경찰인가, 상담 선생님인가? 선생님은 학생들의 신고 기록을 볼 수 있어야 하나? 선생님조차 가해학생과 한 패여서 이를 악용하면 피해학생은 정말 큰 좌절감과 무력감을 느낄텐데?

등등 어떤 범위까지 알림이 가야하는 지에 대한 고민, 그리고 이에 대한 악용의 가능성도 또 가늠해야 했다.


그래서 어떻게 개발한 건가요?

위의 다양한 고민들을 녹여낸 기획으로 한땀한땀 개발한 기능들이 GitHub README에 있으니 참고하시길 바란다.


회고

처음 써보는 기술들

React 활용 자체에도 익숙치 않았는데, Recoil, react query 등 다양한 라이브러리를 겸해서 사용해야 했기 때문에 걱정이 앞섰지만, 열심히 학습하고 부딪히면서 적응할 수 있었다. 특히 recoil은 말로만 들었던 react 상태관리 라이브러리인데, 실제로 사용해보니 예전에 공부했던 useState와 비슷하게 너무나 간단한 문법으로 전역 상태 관리가 가능해서 쉽게 사용할 수 있었다.


React Native 개발, 정말 쉽지 않다

  1. 라이브러리의 의존성 문제

나는 홈 화면의 기능들, 녹취나 카메라 촬영, 갤러리 접근과 위치 정보 등 모바일 기기의 특징을 활용하는 기능 개발을 맡았는데, 이 각각이 정식 React Native에서 지원하는 것이 아니라 NPM community에 있는 라이브러리를 활용해야만 가능한 것들이었다. 그러다보니 각 라이브러리마다 환경 설정에 애를 먹었고, 버전 문제로 충돌하거나 공식문서의 설치 가이드가 잘못 되어서 헤매는 등 개발 외적으로 어려움을 많이 겪어야 했다.


개인이 개발한 라이브러리이다보니 npm의 어떤 시점부터 어떤 시점까지만 적용이 가능한 라이브러리들이 몇 있었다. 그런데 여러 라이브러리들을 사용하다보면 서로의 영역이 교차하지 않는 경우들이 생겼는데, npm install로 라이브러리를 설치하려고 할 때 엄청 에러들이 발생하곤 했다. 이를 해결하려고 머리를 많이 싸매보았는데, 결국 해결하지 못하고 npm install -f로 강제 설치를 하는 강압적인 방법을 사용하곤 했다. 그마저도 제대로 동작하지 않아 며칠을 고생했던 라이브러리도 있었다.

RN 개발의 걸림돌로 가장 크게 느껴진 문제였다.


  1. 클래스형 문법

라이브러리 사용 예시에서 함수형으로 구현된 개발 예시가 많이 없고, 대부분 클래스형 문법이어서 이를 함수형으로 마이그레이션 하기가 어려웠다. 최대한 가능한 마이그레이션은 진행해서 함수형으로 바꿔 적용해보려 노력했지만, 컴포넌트의 생명주기에 따른 문법이 꽤나 달랐고, 사용하는 방식도 녹록치 않아 그래도 클래스형을 사용한 코드들이 많았다.


  1. 불친절한 공식문서

공식 document들이 없거나 유지보수가 되지 않는 경우가 많았다. 역시 위의 맥락과 비슷하게 현재 사용하지 않는 문법이나 ES6 이전의 문법들이 있었고, 실제 사용해야 하는 기능을 제대로 찾지 못하게 문서가 엉성하게 구성된 경우가 많았다. 그래서 github의 다양한 오픈소스나 google 검색을 통해서 레퍼런스를 찾아보며 얼렁뚱땅 활용 예시를 익히고 개발하는 등 개발 자체보다 기능 탐색에 시간을 많이 들였다.


  1. 개발자 도구 사용의 어려움

이는 React Native 잘못이 아니라, 모바일 어플리케이션 개발 특성으로 발생한 문제였다. React Native는 어플리케이션 개발 툴인만큼 에뮬레이터를 화면에 띄워 UI 개발 내용이나 기능을 테스트해야 했는데, 이 환경 설정이나 지속적인 연결이 어려웠다. 웹 같은 경우에는 브라우저만 켜두어도 console로 다양한 확인들을 해볼 수 있었겠지만, 앱은 그렇지가 못했다. 프론트 UI 개발에 있어 개발자 검사 도구를 쉽게 활용하지 못한다는 점이 상당히 힘들게 다가왔다.

나중에는 에뮬레이터 대신 실제 핸드폰에 연결해 핸드폰으로 동작을 확인하곤 했는데, 알 수 없는 이유로 한 두 번씩 연결이 끊기기를 반복해서 native를 종종 껐다 켜줘야 하는 불편을 겪어야 했다.


  1. 애니메이션과 native-base 개발

개발 초기에는 빠른 개발을 위해 natice-base라는 React 스타일링 프레임워크에 의존했다. 다양한 기능들을 보유했고, 공식문서도 나쁘지 않게 구성되어 있어서 사용에 큰 무리가 없을 것이라 판단했기 때문이다. 또한 RN에서 구현할 수 없는 animation/transition css도 tsx 차원에서 쉽게 구현할 수 있었고, 다양한 컴포넌트를 지원하는 것이 좋아보였다.

그런데 tsx에 클래스에 디자인 유틸 요소를 넣어 스타일하는 방식(ex. 부트스트랩)의 고질적인 문제처럼 tsx가 길고 더러워진다는 점이 있었고, 이것이 많이 아쉽게 느껴졌다. 그래서 stylesheet를 활용한 스타일링으로 무게를 실었고, non-framework 개발까지 가능하게 되었다. 결과적으로는 stylesheet를 혼용해 깔끔한 tsx를 유지할 수 있게 되었다.


디자인은 역시 쉽지 않다

개발 외적으로 또다른 어려움은 디자인이었다. 모던하면서도 눈이 띄는 디자인, 그리고 디자인에서 그치지 않고 UX를 고려한 디자인을 만들어내기 위해 노력을 많이 했는데, 과연 프로젝트들을 거치면서 나의 디자인 능력이 많이 발전했는가에 대한 고찰을 해보았다. 음… 아닌 것 같았다. 내 디자인 센스는 많이 늘어나지를 못했다…

다른 동기들의 산출물은 대단할 정도로 높은 퀄리티를 자랑하는 경우도 있는데 나는 왜 이런가 하는 자기 반성을 해보기도 했고, 이것이 자극이 되어 디자인 개선에 시간을 많이 투자하기도 했다. 다행히 점차 팀원 모두에게 만족스러운 디자인으로 개선이 되었고, 확실히 미적으로 발전한 서비스를 개발할 수 있게 되어 기쁘게 생각한다.


편안한 프로젝트

SSAFY의 1년을 열심히 달려온만큼 이전처럼 온 시간을 다 갈아넣어 개발하는 등 많이 힘을 빼지 않고 효율적으로 움직여서 개발하자는 데에 모두가 합의했다. 물론 대충한다는 의미가 아니라, 삶과 개발의 밸런스를 맞추면 개발하자는 것이었다. 그런만큼 이전과는 꽤나 다른 여유와 완급조절이 빛났던 프로젝트였다.


산책과 스트레칭 시간

자율 프로젝트 중간에 전면 오프라인으로 변경되었다. (5프라인) 전면 오프라인이 되면서 장기전을 위한 체력 관리가 더더욱 필요했는데, 하루종일 앉아서 개발만 하는 우리 개발자들의 육체적, 정신적 건강을 챙기기 위해 스트레칭과 휴식 시간을 종종 가졌다.

image image
   

SSAFY 대전캠퍼스는 자연 속에 위치하는데, 산책로도 있고, 스트레칭장도 있어서 한창 지쳐갈 오후 시간에 한 두 번씩 몸을 풀러 팀 전체가 나갔다. 다리를 찢어주면 그것만큼 시원한 것이 없다.


팀원으로서 참여

지금까지 팀장으로서 프로젝트를 이끌었던 이전 프로젝트들과 달리 이번 프로젝트는 팀원으로서 임했던 프로젝트였다. 경험 많고 리더십 좋은 큰 형님이 기대처럼 프로젝트를 잘 이끌어주셔서 원활하게 팀으로서 잘 운영이 되었다고 느꼈고, 팀원으로서 잘하는 리더의 밑에서 팔로워로서 활동하며 리더의 자질과 역량에 대해 생각해볼 수 있는 좋은 기회였다.

한편으로는 리더가 가지고 있는 팀 운영, 질 좋은 발표, 프로젝트의 책임감을 내려놓다보니 팀, 문서 관리보다 개발에 집중할 수 있는 상황이 좋았다. 마음의 부담이 훨씬 덜해서 몸도 마음도 덜 피곤했던 프로젝트였다고 느꼈다. 아무래도 마냥 리더 체질은 아닌가보다.


팀워크를 위한 오락은 필요하다

image

이번 프로젝트에서는 특별히 닉네임 제도나 일일 회고 등은 진행하지 않았으나, 1학기 같은 반이었다는 큰 유대감으로 프로젝트 진행 중간중간 여러 오락적인 요소들이 자연스럽게 묻어났다. 특히 ‘알럿유작명소’ 수준으로 서로 팀원들에 대한 별명들을 지어주어 하나의 문화로 자리잡았다. 다양한 별명들이 생겨났다.


기억에 남는 일

기도 메타

위에서도 말했듯이 RN 개발을 계속하면 계속할수록 빌드가 터지는 일이 빈번했다. 온종일 매달린 빌드 시도에도 빌드가 되지 않자 우리는 하늘의 힘을 빌리는 소위 ‘기도메타’까지 사용하기 이르렀다.

image image
   

웃기면서도 놀라운 일은 이 기도메타 이후 빌드가 성공했다는 점이다.


자율 프로젝트 이름값을 했다

다양한 프로젝트들이 선보여졌다. 그 중에서 우리 대전 캠퍼스에서는 Unity를 활용한 3D SSAFY 탈출 게임이 인기가 상당했다. FPS 게임인데, 왕년에 유행했던 미니 서든 같은 느낌이었다. 꽤나 부드럽게 동작했고, 나름 난이도가 있어서 자율 프로젝트 발표 이후 교육생들이 이 게임의 끝장을 봤던 게 기억에 남는다.

다른 캠퍼스의 프로젝트에서 기억에 남는 것은, 미소녀연애시뮬레이션(이하 ‘미연시’)을 개발자 버전으로 만든 것이었다. 알고리즘이나 CS 관련 지식들을 풀어내야 스토리의 진행이 가능했는데, 컨셉이 유달리 특이했던 것과 대비되는 엄청난 퀄리티로 우수 프로젝트로 선정되어 전국 캠퍼스 교육생들 앞에서 발표를 진행했다. 이를 지켜보는 모든 교육생들이 즐거움, 한편으로는 신기함을 넘어선 경이로움으로 프로젝트를 감상했다.

대단한 점과 웃긴 점이 있는데, 대단한 점은 모든 스토리가 탄탄하게 짜여져있는 것과 함께 Novel AI를 활용해 직접 찍은 사진으로 애니메이션 캐릭터를 만들어 화면에 사용했다는 점이고, 웃긴 점은 이 프로젝트의 메인 담당 교육생은 이전부터 오타쿠 컨셉의 프로젝트를 만들어 우수 프로젝트로 선정, 3번의 전국 우수 프로젝트 소개에서 얼굴을 비췄다는 사실이다. 어느 한 분야라도 최고가 된다면 모두가 박수를 친다는 게 사실인가 싶다.

댓글남기기