[회고] 첫 프로젝트: 임금님귀(King'sEars)! 비밀을 말하고 싶어 마음이 답답한 이들을 위한 플랫폼

https://kingdonkey.site/

약 3개월 반 정도의 코드스테이츠 소프트웨어 엔지니어링 과정을 모두 수행하고, 드디어 첫 프로젝트를 완료했다. 2주 동안 진행되는 프로젝트라고 했지만, 사실 초기 인트로와 기획 등의 회의 시간이 많았기 때문에 실제 코딩을 한 기간은 5일 정도밖에 되지 않았기에 빠듯한 일정이라고 할 수 있었다.

우리팀의 팀원 분들은 개개인이 뛰어난 슈퍼플레이어라서 별 어려움 없이 수월하게 프로젝트를 진행할 수 있었다. 사실, '비밀'과 관련된 아주 짤막한 준 소셜미디어 아이디어가 있다고 했을 때 우리 팀원 분들이 받아들여주실까, 프로젝트 사이즈로 너무 작은 것은 아닌가 걱정이 되었지만 모두들 너무 흔쾌히 진행하자고 해주셔서 너무 고마웠다.

이번 포스팅에선 우리가 만든 첫 작품이 어떤 서비스인지 소개하고, 어떤 동기로 본 프로젝트를 하게 되었으며, 어떤 과정과 어려움을 걸쳐 배포까지 하게 되었는지를 소개하고자 한다.

 

Presentation

 

 

 

팀 소개

<프론트>
* 팀장님 (Github)
* 본인 (Github)

<백엔드>
* 데이빋졍 (Github)
* 데브옵스 각성자 (Github)

우리팀의 이름은 DevPull이다. Git upstream에 merge할 때 까먹지 말고 pull을 꼭 하자는 ⭐️밝고 희망찬 의미⭐️를 가지고 있다. 이름 덕택인지 우리 팀의 브랜치 머지 기록은 아주 깔끔하다. 다들 처음이었지만, 서로 알려주고 도와주면서 힘들이지 않고 깃헙 워크플로우를 경험해볼 수 있었다.

특히나, 우리 팀의 팀장님은 김씨 성이 아니라 깃씨 성일 것이라는 합리적인 의심이 들정도로 우리 기수에서 압도적으로 깃을 잘 사용하시는 분이었다 (아닛 같이 배우는 입장 아니였냐규!!). 덕분에 많이 배울 수 있었고, 더 수월히 진행한 것 같다. 👍

이게 처음 git workflow를 접해본 자들의 기록이라닛! 역시 우리팀!

 

노력했으세오

프로젝트 소개 🐴 👑 👍

그리스 신화 속, 아폴로 신의 노여움을 산 미다스왕. 당나귀 귀를 가졌다

이야기 속 주인공은 임금님 귀가 당나귀 귀라는 비밀을 알게 되었을 때, 그 비밀을 말하고 싶어 너무나 큰 심적 고통을 느꼈다. 참고 참다가 한계점에 도달했을 때 몰래 나가 땅을 파고 "임금님 귀는 당나귀 귀!!!"라고 속 시원히 외쳤고, 이후 그 자리에 갈대밭이 생겨 바람이 불 때마다 "임금님 귀는 당나귀 귀~~~귀이이~~~"라는 소리가 들리기 시작했다고 전해진다.

당나귀 귀 설화 - 위키백과, 우리 모두의 백과사전

우리 프로젝트의 이름은 이 이야기에서 영감을 받아 King's Ears, 즉 임금님 귀라고 이름을 지었다. 임금님의 말할 수 없는 비밀을 간직하고 있던 이발사의 답답함을 풀어줄 수 있는 그런 공간을 지향한다. 비밀을 알고 있는건 이점이 될 수도 있지만, 동시에 엄청난 심적 고통을 선사할 수도 있기 때문에 풀어줄 장소가 필요하다고 생각되었기 때문이다!

임금님귀는 비밀이라고해서 꼭 임금님의 신체 비밀이나 국가 기밀과 같은 거창한 게 아니라, 사소하면서 웃픈 TMI를 공유할 수 있는 그런 장소이다.

우리 팀원 중 다재다능한 데이빗졍이 만들어준 GIF. 로그인 후 비밀보기 버튼을 클릭하면 랜덤한 비밀을 열람할 수 있다.

유저는 나만 알고 있는 비밀이나 사소한 TMI를 '비밀쓰기' 기능을 통해 작성할 수 있다. 작성이 완료된 비밀은, 다른 누군가가 '비밀보기' 기능을 사용했을 때 랜덤하게 보여지게 된다. 서버 쪽에서 랜덤한 로직으로 비밀을 골라오기 때문에 어떤 비밀이 보여질지 아!무!도! 모른다.

비밀이 나오면, 다른 유저들이 누른 좋아요/싫어요 개수를 볼 수 있으며, 내가 좋아요/싫어요를 누를 수도 있다.

우리 서비스는 🐴덩키킹덤(Donkey Kingdom)이라는, 여타 사회와 다를 바 없이 여러 비밀과 가십이 발생하고 사라지는 왕국에서 유저가 한 개인으로 비밀을 듣게 된다는 컨셉을 가지고 있기 때문에 이전에 보았던 비밀이 또 다시 나올 수도 있다 (의도한 것이다). 왜냐면 비밀이나 가십은 내가 이미 알고 있어도, 다른 누군가가 와서 이미 아는 이야기를 또 전해줄 수도 있기 때문이다.

 

이게 다라고 생각한다면 경기도 오산! (죄송합니다..😭)

비밀을 쓰고 보는데에 추가적인 재미를 더하기 위해, 그리고 덩키킹덤🐴의 주민으로써 적절한 신분을 부여하기 위해 레벨 시스템을 추가했다. 레벨은 총 5가지로, 작성한 비밀의 개수에 따라 올라가도록 만들었다. 작성한 비밀의 개수와 상관 없이, 서버에서 가장 많은 비밀을 누설한 유저(최고 떠벌이)에겐 영광스런 킹 동 키의 호칭이 부여된다. 강력한 느낌을 주기 위해 띄어쓰기를 주었다. (강력함+1)

지존좌 킹 동 키 유저의 이름은 메인 페이지에 표시되어 사이트를 이용하는 모두가 볼 수 있다.

영광스런 지존의 자리, 김 동 키.. 아, 아니 킹 동 키...&nbsp;

현재 나의 레벨, 내가 쓴 비밀의 개수, 그리고 내가 본 최근 비밀 5개와 내가 쓴 최근 비밀 5개를 마이페이지에서 확인할 수 있다. 마이페이지엔 비밀번호 변경과 회원탈퇴 기능 또한 추가되어 있다.

 

랜딩페이지 디자인

 

임금님귀 랜딩페이지

동화 속 이발사가 속시원하게 비밀을 외친 그 장소는 갈대 숲으로 변했다. 우리는 그러한 이야기에서 모티브를 받아, 덩키킹덤에 자리 잡은 '비밀의 숲'을 조성하는 것을 목표로 전체적인 디자인을 고안했다.

Lively하다는 느낌을 주기 위해 전체 배경으로 비밀의 숲과 덩키킹덤 컨셉에 맞는 중세 마을 분위기가 보여지는 비디오를 넣었다. 또한, '비밀'이기 때문에 너무 밝지 않으면서, 미스테리한 푸른 분위기가 나도록 영상에 컬러감을 입혔다. 그래서 나머지 배경도 녹색이 중심이지만, 푸른 계열이 얼핏 띄도록 조정했다.

기술 스텍

임금님귀 프로젝트 기술 스텍

임금님귀 프로젝트의 프론트단에선 UI 컴포넌트 구성을 위해 React를 사용했고, 상태 관리를 위해 Redux를 도입했다. 나와 우리 팀장님이 프론트를 맡아서 작업했는데, 우리 둘다 Hooks를 추가적으로 공부해서 사용했기 때문에 앱 전반에 클래스 컴포넌트는 사용하지 않았다.

서버는 우리 팀의 두 스타플레이어가 맡았다. node.js를 기반으로 express를 사용해 서버를 구축했으며, DB는 관계형으로 MySQL을, 그리고 쿼리는 Sequelize를 사용했다. 첫 프로젝트였고, 복습의 목적이 강했기 때문에 우리는 코드스테이츠의 요구 사항에 맞춰 서비스 개별 토큰을 사용한 로그인 방식을 도입해야했다(OAuth로 물론 할 수 있었지만, 개별 인증을 꼭 넣어야 했기 때문에 도입하지 않았다). 그래서 JWT를 사용해 refresh 및 access token으로 인증을 구현했다.

배포는 AWS의 S3(클라이언트), EC2(서버), 그리고 RDS(데이터베이스)를 사용했다. 그런데 우리는 refresh token을 쿠키에 저장할 필요가 있었기 때문에, https로 사이트를 구축해야했다. 그래서 이에 추가로 Route53, Load Balancer, CloudFront, 그리고 Certificate Manager를 이용해야 했다.

 

"🌼 첫 프로젝트의 경험, 이후의 양분이 되어라! 🌼"

새벽에 100% 집중 모드로 슬라이드를 만들다가 정신을 차려보니 나도 모르게 개화🌼하고 있었다. 나를 제외한 팀원 분들은 모두 남성분들이지만 마음들이 다들 너그러우셔서 이것도 흔퀘히 오케이해주셨다.👌

개발자가 되기 이전, 전혀 다른 분야였지만 당연히 Professional한 세팅에서의 협업 경험은 많았다. 하지만 이번 프로젝트는 개발 프로젝트로서의 첫 협업이었고, 그래서 배운 점도 느낀 점도 많았다.

우리 팀 4명은 첫 프로젝트가 끝나고 다시 모두 모여 회의를 진행했다. 이번 프로젝트를 양분 삼아 다음 프로젝트에서 더욱 더 만족스러운, 더 완성도 높은 경험과 결과물을 가져가자는 의미로 말이다. 그래서 이 회의를 통해 위와 같이 총 4가지로 분류할 수 있는 개선 사항들을 도출할 수 있었다.

1. 체계적인 배포 계획의 필요성

첫째로, 우리 모두 배포라는 것을 처음 해보았다!! 배포를 진행하면서 "아, 이래서 DevOps 직군이 필요하구나"를 뼈저리게🤬 느꼈다. 도대체 코드 상 그 어떠한 문제도 없는데 자꾸만 튀어나오는 CORS 에러... 그리고 로컬에선 되는데 배포단만 가면 저장되지 않는 너란 쿠키 나쁜 쿠키 🍪... 우리 팀 네명은 이틀 연속 새벽까지 이 문제를 해결하기 위해 고군분투했다.

그러다가 기한을 맞추기 위해 배포를 포기하려던차, 띄용! 백엔드의 팀원분이 신성처럼 데브옵스의 능력을 각성하셨다.👍 첫 프로젝트가 끝나가는 막바지, 스케줄에 맞춰야 했기 때문에 자연스럽게 분업의 형태로 마무리 작업이 진행 되었다. 나는 프로젝트 발표 준비를 하기 위해 슬라이드와 영상을 촬영해야 했고, 나머지 팀원 분들은 데브옵스 각성자님과 함께 마지막 테스팅에 집중했다.

결국 CORS 문제 또한 코드나 S3, CloudFront에서의 세팅 문제가 아니라 Load Balancer의 극세사 민감성 때문이라는 걸 알게 되었다. 테스팅 와중 kingdonkey로 시작하는 각종 무료 도메인은 우리 팀이 죄다 사용했을 정도로 (ㅋㅋㅋㅋㅋㅋ) 각종 시도를 다해보았고, 결국 끝까지 포기하지 않은 데브옵스 각성자님의 지도와 팀원들의 끈질긴 시도 덕에 배포에 성공하게 되었다. 동시에 프로젝트 발표 준비도 기한까지 늦지 않게 맞출 수 있어서 우리의 상황에서 최고의 아웃풋을 얻었다고 할 수 있게 된 것이다!

이를 통해 우리가 느낀 점은, 다음 프로젝트를 진행할 땐 우선 단계별로 배포 버전을 미리 기획해서, 차분히 진행해야한다는 점이었다. 또한, 다음 파이널 프로젝트 때엔 배포 담당자를 미리 지정하여 체계적으로 작업을 수행하자고 의견을 모았다. 그리고 그 담당자는, 당연히 우리 데브옵스 각성자님이 되실 예정이고 말이다.👍 (미리 감사드립니다 찡끗 😜)

2. 탄탄한 시간 계획의 중요성

부끄럽지만 스스로 발전하기 위해 공유한다. 이제는 안다... 이게 3시간짜리가 절대 아니라는걸...*^^* 과거의 나는 참 꿈과 희망의 세계에 살고 있었구나

둘째로, 프로젝트를 시작하기에 앞서 세심한 task 고려 및 분배가 정말 중요하다는 것을 느꼈다. 프로젝트에 직접적으로 들어가기에 앞서 Github repository의 Issues에 필요할 것이라 예상되는 작업들을 Task Card로 작성했었다. 그런데 아무래도 모두들 처음 해보는 작업이기 때문에, 이 작업에 시간이 얼마나 걸릴지, 어떤 추가적인 일들이 이것과 연관되어 있는 것인지, 이 작업의 사이즈가 얼마나 클지 미리 예상하는 것이 굉장히 어려웠다.

그렇기 때문에, 앞서 작성한 task card들에 추가로 엄청난 부가적인 일들이 있다는 것을 직접 시작하고 나서야 알게 되었다. 그래서 다음 파이널 프로젝트 때엔 이번 경험을 토대로 좀 더 상세히, 좀 더 현실성 있게 세분화된 task card를 작성하는 연습을 할 것이다. 물론 아직 쪼렙이라 어색하고 모르는 점이 많지만, 더 많이 작업하고 더 많이 커밋하다보면 점점 늘지 않겠는가?!

3. 테스팅 계획 및 절차의 필요성

처음하는 프로젝트이기 때문에 아무래도 기능 구현이나 배포를 실현시킨다는 목표에 우리 모두의 시선이 집중되어 있었다. 결과적으로 테스팅과 관련하여선 상대적으로 별다른 계획이나 절차를 생각하지 않았다. 그렇기 때문에 팀원들 각자가 정해진 가이드라인 없이 테스팅을 진행하게 되었고, 그래서 예상치 못하게 효율성이 떨어지는 면이 어느 정도 있었다고 본다.

또한, 배포단에서 도대체 이유를 알 수 없게 계속 에러가 발생했기 때문에 AWS 서비스들의 여러 가지 설정들을 바꿔가며 테스팅을 해보았는데, 그 상세 내역을 기록하지 않아서 초반에 해결했다고 생각했던 에러가 후반에 또 발생하고 하는 일들이 몇 번 있었다.

이러한 문제들을 해결하기 위해 다음 프로젝트 때엔 테스팅을 진행할 때 꼼꼼하게 내가 어떤 설정을 바꾸었었고 그로 인해 어떠한 결과가 있었는지 꾸준히 기록하고 그걸 공유하면서 효율성을 증가시키기로 했다. 💯

4. 업무 기록 및 공유의 중요성

마지막으로, 코딩 프로젝트의 협업에 있어서 서로 어떤 작업을 진행할 예정인지, 오늘은 무엇을 했는지 등을 팀원들과 공유하는 것이 얼마나 중요한지 느낄 수 있었다. Task card를 작성했음에도, 서로 연관되어 있는 컴포넌트를 만든다거나 할 때 의도치 않게 겹치는 업무가 발생했기 때문이다.

이에 대한 해결 방안으로 우리는 다음 프로젝트에는 DevLog 작성을 업무 진행 상황 공유 목적으로 필수 작성하기로 정했다. 또한, 버그나 에러 발생 시 Error handling issue 생성으로 상세한 기록을 남겨 공유하기로 했다. 어떤 에러가 발생했는지, 어떠한 방법들을 시도했는지, 그리고 결과적으로 어떤 방법으로 최종 해결을 했는지 등을 기록하여 더욱 원활한 협업을 이뤄낼 예정이다.

끝으로...

프로젝트를 모두 완료하고나니 (물론 버그 투성이지만), 다음 번에 더 잘하자는 생각이 열심히 든다. 새로운 스텍을 배워 적용시킬 생각을 하니 기대가 되기도 한다. 이번 첫번째 프로젝트에서 회고에 많은 시간을 투자한만큼, 이 경험을 양분 삼아 더욱 괜찮은 프로젝트를 만들기 위해 정진할 예정이다.

임금님귀엔 많은 버그가 있지만 내 눈엔 귀엽다

 

 

🌸 추가: 화상채팅 기반의 온라인 스터디 카페 '사각사각' 보러가기!

2021.07.21 - [Learn to Code] - [프로젝트] 실시간 화상채팅앱을 개발했어요! (feat. Socket.IO & WebRTC)

[프로젝트] 실시간 화상채팅앱을 개발했어요! (feat. Socket.IO & WebRTC)