[SUPP] 페어와의 협업 맛을 돋우는 애피타이저 - 3

 

우아한 테크코스 2기 과정 중 크루들과 제작한 서비스인 SUPP에 대한 글입니다.

 

프로젝트 로고

 

나를 비롯하여 또링, 스티치, 알트 그리고 코즈까지 5명이 모여 SUPP 개발 팀이 꾸려지고 기획과 개발을 진행했다. 이번 글에서는 배포 과정과 서비스 공개 그리고 그 이후의 순간들에 대해 알아보자.

 

배포의 순간

배포.... 레벨 3 기간 동안 칵테일픽 프로젝트를 진행하면서 배포를 경험했으나 아직도 어려운 그 이름..! 당시 SUPP을 구현할 때 배포는 더더욱 미지의 세계였고 공부하고 싶은 마음만 그득한 상태였다. 
배포 과정을 시작하게 된 계기는 크루들에게 서비스를 공개할 데모 날이 잡혔기 때문이었다. 바로 6월 17일 테코톡 시간이었다(테코톡은 우테코 크루들이 주제를 정해 10분 정도 발표하는 시간이다) 시간은 한 주 정도 남은 상황. 배포는 하나도 진행되지 않은 상태였다. 하지만 우리에게는 스프링 부트와 AWS로 혼자 구현하는 웹 서비스가 있었다. SUPP 개발에도 참고했으며 배포까지도 참고할 수 있는 든든한 지침서였다. SUPP의 배포는 EC2를 이용하여 서버를 띄우고 RDS를 이용하여 MariaDB를 사용한 데이터 베이스를 띄웠다. 그리고 크롬 익스텐션으로는 서버에 api를 쏴서 원하는 정보를 가져올 수 있도록 구성했다.

 

당시 공유를 위해 노션에 정리했던 배포 관련 글

 

6월 11일 데모 데이가 일주일도 남지 않은 시점에 1차 배포가 완료되었다. 그리고는 당연하게(?) 이슈가 발생했다. 당시에는 서비스에 따로 도메인을 연결하지 않고 EC2와 연결된 고정 ip로 익스텐션과 서버가 통신했다. 이 상황에서 익스텐션이 서버와 통신을 주고받으며 이슈가 생겼다. 익스텐션이 실행되고 있는 우테코 교육 사이트는 https를 기반으로 통신한다. 하지만 SUPP 서버는 http로 통신한다. 이러한 차이에서 익스텐션이 서버로부터 정보를 가져와 우테코 교육 사이트로 뿌려줄 때에 Mixed contents 에러가 발생했다. https를 사용하는 우테코 교육 사이트 입장에서는 검증되지 않은 http를 기반으로 한 api에서 오는 정보를 믿을 수 없다는 이유에서 발생시키는 오류였다. 다시 긴급하게 회의. Mixed contents를 해결하기 위해서는 서버에 도메인을 달고 https 또한 붙여서 두 사이트 모두 https로 바꿔줘야 한다는 결론에 도달했다.(우테코 교육 사이트를 http로 바꿀 수는 없기 때문) 도메인을 구입하고 nginx를 앞에 붙여서 https를 달자는 의견이 나왔지만 처음 시도하는 배포인 점과 더불어 우테코 미션과 병행하던 당시의 일정으로는 힘들다는 판단을 내렸다. 그리고 찾은 대안은 CloudFront. 우테코 1기의 루피님께서 테코톡 발표를 하시며 우리와 비슷한 문제를 겪으셨고 당시 임시 해결법으로 사용하셨기에 우리도 적용해봤다. 촉박한 시간과 구현 가능성 그리고 지식 간의 타협 속에 배포는 완료되었고 프로젝트 데모데이가 다가왔다.

 

첫 데모 당시 서비스 구성, 출처: SUPP 테코톡 발표 자료

 

---

 

서비스 공개의 순간

기능의 완성과 배포의 성공이라는 기쁨을 뒤로하고 서비스 공개라는 다른 도전을 위해 팀원들과 함께 노력했다. 배포 환경에서 발생한 버그를 해결함과 더불어 보다 사용성을 발전시키기 위한 기능 추가도 이뤄졌다. 당시의 프로젝트는 개발 과정에서 테스트를 작성하지 않았기에 기능을 추가할 때 조마조마한 마음으로 진행했다 또한 개발 서버를 따로 띄우지 않았기에 로컬에서 완성한 기능을 바로 배포 서버에 적용해서 확인해보는 수준이었다. 이때의 교훈으로 리팩터링 목록이 만들어졌음은 아래에서 다시 이야기하도록 하겠다.
우리는 데모 발표를 준비했다. 발표는 다섯 명의 팀원 모두가 참여했다. 전반부는 나와 알트가 프로젝트의 개요와 시연을 진행했다. 그리고 코즈가 기술 스택과 프로젝트 구조에 대한 내용을 발표했다. 후반부는 후기와 레벨 3 프로젝트를 진행할 크루들을 위한 경험담으로 진행되었는데 스티치와 또링이 힘써줬다. 
서비스 운영 과정에는 항상 예상치 못한 문제가 터지기 마련이다. 발표를 마치고 실제 크루들이 Github OAuth를 이용해서 회원가입을 하는 과정에서 github이 지정해둔 api 제한(rate limit)을 넘은 api 요청을 보내서 정상적으로 회원가입이 진행되지 못했던 아쉬움이 있다. 바로 해결할 수 없는 문제였기에 사용자들이 불편함을 느꼈고 바로 피드백을 받았다. 이 부분은 아직까지 해결해야 할 과제로 남아있다. 우여곡절이 있었지만 서비스를 사용해본 크루들로부터 긍정적인 피드백도 받고 어떻게든 SUPP 1차 공개를 마무리했다는 생각에 들뜬 우리였다. 데모 발표가 궁금하다면 영상을 참고하시라. 

 

---

 

그 이후

서비스 발표 후의 시간은 정신없이 흘러갔다. 우리는 간단하게 어떤 점들을 2차 배포에 반영할지 정했고 데모 발표에서도 공유했다. 애착이 가는 서비스기에 빨리 발전시키고 싶었다. 하지만 레벨 3를 진행하는 동안은 각자의 프로젝트를 진행하느라 SUPP을 돌볼 시간이 없었다(발표는 레벨 2의 후반부에 진행되었다) 레벨 3가 끝난 후 방학 기간이 우리 팀의 상황을 다시 돌아볼 시점이었다. 팀원 각자 모자란 공부, 가족과의 즐거운 시간, 새로운 도전을 하던 방학 기간 중 우리는 화상회의를 진행했다. 핵심 내용은 기존에 작성한 리팩터링 요소들 정리였다. 그리고 각자 하고 싶은 이슈를 맡아 진행하기로 결정했다. 

 

9월 1일 회의록에서 발췌

 

기능 추가보다는 당시에 부족했던 점들을 보완하자고 의견이 모였다. 현재까지의 진행 상황으로는 테스트 코드 작성과 기본적인 서버 리팩터링 그리고 크롬 익스텐션 배포(지금까지는 빌드된 파일을 활용했다)가 완료되었다. 프론트 리팩토링은 내가 담당하여 진행하였지만 로그인 로직이 많이 수정되어 이에 대응하다보니 방학이 끝났다. 못다한 리팩토링은 레벨 4 이후에라도 차차 진행하고 완성할 예정이다. 이렇게 방학 중에 적용된 리팩토링 사항은 레벨 4가 시작되는 날에 맞춰 다시 배포되었다. 그리고 우아한 테크코스 소통 채널에 버전 2 업데이트에 대한 글도 작성했다. 수고해준 또링에게 감사를 👍

 

 

 

---

 

회고의 순간

우테코에서는 프로젝트나 페어 혹은 하나의 업무를 마무리하면 회고를 진행한다. 물론 SUPP도 회고를 진행했다. 이는 데모 발표 때에 반영되어 또링과 스티치가 발표할 내용이 되었고 우리의 리팩터링 목록이 되었다. 그때의 회고를 참고하여, 나의 추가적인 생각을 덧붙여 다시 회고를 작성해보고자 한다.

칭찬할 점

• 원활한 팀원 간의 소통
  • 팀 프로젝트의 가장 중요한 부분은 개발보다 사람이라고 생각한다. 단체 채팅방에서는 의미 있는 대화를 이어나갔으며, 회의도 지루하지 않고 재미있게 잘 진행되었다. 멋진 친구들과 함께 프로젝트를 잘 마무리했다는 점에서 가장 잘한 점이 아닐까 싶다.
    
    
• 실 사용자가 있는 서비스를 개발
  • 눈 앞에 있는 우테코 크루들이 직접 프로젝트를 사용하고 피드백을 줬다. 이 부분은 서비스를 개발하는 입장에서 책임감과 재미를 가져다주었다. 처음 아이디어를 냈던 순간에 상상했던 즐거움을 이뤄냈기에 칭찬하고 싶다.
    
    
• 개발하고 끝이 아닌 리팩터링을 진행
  • 레벨 3 방학 동안 진행했던 리팩터링 과정이 SUPP을 살아있게 만들었다. 단순하게 배포하고 마는 프로젝트는 누구나 할 수 있다고 생각한다. 하지만 부족한 부분에 대해 시간을 따로 내서 보완하는 과정은 귀찮고 어렵기 마련이다. 이런 어려움을 이겨내고 리팩터링을 진행했고 앞으로 더 발전할 것이기에 칭찬한다.
    
    
• 협업에 도움이 되는 서비스를 제작
  • 개발자로서의 작은 꿈이 있다면 노션이나 슬랙, 구글 독스와 같은 협업에 도움이 되는 툴을 제작하는 것이다. 보다 효과적인 협업을 돕고 많은 사람들의 생산성이 올라간다면 정말 뿌듯할 것이다. SUPP도 페어 프로그래밍이라는 협업의 가장 작은 단위에 도움이 되는 서비스라는 점에서 꿈에 한 발짝 더 다가간 느낌이 든다. 기분이 좋다.
    
    
• 내용 정리가 잘 된 프로젝트
  • 프로젝트 회의록이 잘 정리되어있지 않다면 팀원들 간의 정보 불일치가 생기거나 다르게 이해하는 상황이 생기기 마련이다. SUPP을 진행하며 회의록을 잘 정리해두었기에 이를 참고하여 커뮤니케이션을 원활하게 진행할 수 있었다. 또한 이렇게 회고 글도 회의록을 참고하여 수월하게 작성할 수 있다. 회의록에 끈질기게 매달린 팀원들에게 박수를 보낸다.

 

보완할 점

• 테스트 코드
  • 첫 배포를 진행할 때에 SUPP에는 테스트 코드가 아예 없었다. 우테코에서 TDD와 테스트 코드 짜는 법을 배우는 크루로써는 좋지 못한 결과이다. 기능 하나를 추가하는 데에도 불안감에 휩싸이는 일이 발생했다. 우리 팀은 이번 경험을 통해 꼭 테스트 코드를 짜야겠다는 생각을 하게 되었고 리팩터링 과정에서 반영했다.
    
    
• 프론트
  • 당시의 프론트 스킬은 지금에 비하면 많이 부족했다. 당시 실력으로 최선을 다한 프로젝트지만 지금 와서 본다면 수정될 사항이 많이 보인다. 서비스의 유연함과 사용성을 위해, 머스테치에 대한 의존성을 제거하고 React를 이용해 리팩터링을 진행하고 있다.
    
    
• 배포
  • AWS를 활용하여 처음 진행하는 배포였다. 물론 이 또한 이동욱 님의 책을 따라 진행했다. 배포 과정에서 문제가 발생해서 임시로 CloudFront를 활용해서 배포를 완료했다. 하지만 임시로 적용한 방법이기에 계속 유지하기엔 무리가 있다. 따라서 프론트 리팩터링이 끝나는 대로 새로운 프로젝트 구성에 맞춰 배포를 다시 진행할 예정이다. 추가적으로 지금은 EC2에 직접 접속하여 관리하는 Secret Key와 같은 민감한 정보를 Github Submodule을 활용하여 관리할 예정이다.
    
    
• 일정 관리
  • 체계적인 데드라인 없이 프로젝트가 진행되었다. 그렇기에 중간에 일정이 늘어지고 열정이 분산됐다. SUPP이라는 프로젝트는 사이드 프로젝트로서 당연히 우테코 본 과정에 비해서는 우선순위가 낮았다. 그렇기에 이렇게 유동적으로 가져가는 편이 당시로써는 최선의 선택이었다. 하지만 우테코가 끝난 이후에 추가적인 개발 프로세스가 진행될 경우에는 그때의 상황에 맞도록 주기적으로 일정 관리를 할 수 있어야 한다. 
    
    

 

---

 

지금까지 세 편의 글로 SUPP 프로젝트의 시작과 끝 그리고 미래에 대해 이야기했다. 우테코를 진행하며 재미있게 했던 사이드 프로젝트라 애착이 간다. 프로젝트에 대한 장문의 글을 작성해본 경험이 처음인데 블로그를 시작했기에 얻은 즐거운 경험이다. 내가 진행했던 다른 프로젝트에 대해서도 글로 남겨 그때를 기억하고 칭찬과 반성의 시간을 가져보고 싶다. 글을 마치며 앞으로 리팩터링이 더 진행되어 다음 글로 돌아 온다는 말과 함께 프로젝트를 진행한 또링, 스티치, 알트 그리고 코즈에게 감사의 말을 전한다. 코로나가 나아지면 회식하자고~