야생형 개발자가 되어보자!

프로젝트 기간: 2022.03.06 ~ 2022.06.08
밑바닥부터 배포까지!!

❗️프로젝트 시작

경제학을 전공하던 문돌이가 개발자가 되겠다고 선언한 지 약 한 달만에 프로젝트를 하게 됐다. 자바도 스프링도 까막눈이던 내가 무작정 프로젝트를 하게 된 것은 친구의 조언이 컸다.

개발자로 빠르게 성장하기 위해선 (김영한님 표현에 따르면) 야생형 개발자가 될 필요가 있으나, 몇 년간 학자형 공부를 해온 나에겐 쉬이 받아들이기 힘든 방식이었다. 그래서 '일단' 뭐든 지 만들어보면서 부딪히고 해결해 나가며 성장하는 방법을 추천받았고, 바로 프로젝트를 진행해보기로 하였다.

💡프로젝트 아이디어

평소 테니스를 치려고 예약 좀 하고자 하면 복잡한 예약 체계에 혀를 내두르게 된다.

우선 예약 체계가 공공과 사설로 나뉘어져 있다. (타지역은 잘 모르겠으나) 공공서비스예약 페이지에서 서울의 공공 체육 시설을 저렴한 가격에 예약하고 사용할 수 있다. 한편, 서울에서 운영하지 않는 테니스장의 경우 각 업체에서 운영하는 예약 페이지를 이용해야 한다.

서울시 공공서비스예약의 경우에도 예약 기준이 테니스 센터별로 제각기다. 위 사진처럼, 신도림은 평일, 주말 여부 / 코트 이름 / 게임 시간대로 페이지를 나누어 예약을 받는다. 반면 마루공원은 오로지 코트 이름만으로 예약을 구분한다.

목표는 위에서 언급한 두 가지의 불편함을 해결하는 서비스를 제공하는 것이다. (1) 공공과 사설 예약 서비스를 통합, (2) 통일된 기준으로 구분 된 예약 체계를 제공함으로써 손쉬운 예약 서비스를 제공하고자 했다.

😎 프로젝트 진행

📜 MVP 작성

우리가 원하는 서비스를 만들기 위해서는 어떤 기능이 제공되어야 하는가?라는 질문에 답을 할 필요가 있었다. 그리고 이를 정의하고 정리하기 위해 요구사항 정의서를 작성했다. 기본적인 회원기능과 핵심이 되는 테니스에 관련된 사항들을 정의하고, 구체적으로는 어떤 기능들이 제공되어야 하는지를 정의했다.

프로젝트의 진행을 위해, 무엇을 구현해야 하는가에 집중하여 회의를 진행했다. 노션을 이용하여

진행상황 공유

협업에 있어서 진행상황 공유는 상당히 중요하다. 내가 구현한 API를 프론트에서 사용해야 되기 때문일 수도 있고, 팀원이 헤매고 있지는 않은 지 확인하는 측면에서도 중요하다. Jira나 Trello 같은 서비스도 있었지만, Notion에서 각종 문서(회의록, 요구사항 정의서)들을 관리하고 있었기 때문에, 진행상황 공유도 Notion을 통해 진행했다.

👨‍💻 개발

일단 박아! 하는 생각으로 시작한 프로젝트였기 때문에, 리팩토링이나 클린코드, 객체지향 같은 중요한 개념 혹은 관점들을 적용해 볼 여력 따위는 없었다. Spring도 김영한님의 입문 강의를 본 게 전부였기 때문에, API 하나하나 구현하는 게 지옥 같은 과정이었다.

그래도 의미있게 고민했던 하나가 공공예약서비스에서 크롤링한 데이터를 어떻게 효율적으로 업데이트 시킬 것인가?였다.

공공예약서비스에서 크롤링을 한 번 진행하면 못해도 21,420개의 데이터가 나온다. 오전 8시부터 오후 9시까지 한 시간 단위로 예약 정보가 존재하면, 코트 당 하루에 12건의 예약정보가 존재한다. 예약 정보는 보통 한 달 치가 공개되어 있다. 테니스 센터가 17개, 센터당 코트 수를 3개씩만 잡아도 21,420건이다. 이것도 보수적으로 측정한 것이다. 센터에 따라 10개 이상의 코트가 존재하는 경우도 고려한다면, 데이터는 상당할 것이다.

그런데 우리 서비스는 예약 정보를 제공한다는 측면에서 데이터가 굉장히 빠르게 업데이트 될 필요가 있다. 6만 건의 데이터를 어떻게 빠르게 업로드 시킬 것인 지에 대한 고민이 분명히 필요했고, 나름의 고민 끝에 결과물을 내놓기는 했었다.

결과물이 굉장히 불만족스러워서, 나중에 이런 고민을 해보기도 했다.

👨‍👦‍👦 협업

프로젝트도 처음이지만, 프론트와의 협업도 처음이었기 때문에 어려운 점이 많았다. 처음엔 내가 작성한 코드를 프론트가 보고 API를 사용하겠지 하는 무시무시한 생각을 했었다. 생각해보면 나조차도 Java가 아직 어려운데, Java를 사용하지도 않는 프론트가 코드를 보고 API 사용한다? 어림도 없다.

그래서 Swagger를 이용하여 API 문서를 제공함으로써, 프론트가 API를 사용하는데 편의성을 제공하고자 하였다.

프로젝트 진행 당시에는 Slack이나 별다른 협업 툴을 알지 못했어서 카톡으로 문제 상황에 대한 공유를 진행했다. 아무래도 카톡은 개인 메신저의 성격이 강하기 때문에, 업무로 카톡이 오면 스트레스가 느껴지는 부분이 없잖아 있었다. 추후에 프로젝트를 또 하게 된다면, 별도 메신저를 사용하는 게 바람직하지 않을까 생각한다.

🖥️ Devops

이런 저런 서비스를 이용하기보다는 AWS만을 이용하여 Devops를 구성하기로 하였다. 빌드 파일을 FileZila를 이용하여 수동으로 배포했고, Route 53을 이용하여 도메인을 설정해보기도 했다. 마지막엔 ALB 설정을 해보면서 다양한 Devops 서비스를 이용해보고자 하였다.

사용한 서비스 중, EC2, RDS, S3를 제외하면 이해가 잘 안 되는 부분이 많다. 이런 부분은 추후에 더 공부를 진행하면서 채워나가야 할 부분이다.

사실 Devops는 아쉬운 부분이 너무나도 많다. Jenkins, Code Deploy, Docker 등 많은 서비스들을 활용해보지 못했고, 무엇보다도 배포를 자동화하지 못했다는 사실이 너무나도 아쉬웠다.

결과물

서버를 내리기 전에 사진을 많이 남겨뒀어야 했는데, 그러지 못한 게 아쉽지만..

서비스를 개발하면서 초기 MVP 모델보다 더 많은 기능들을 개발하게 됐다. 초기에는 예약 정보만 전달해주려 했지만, 이후 내가 원하는 코트, 시간대가 예약 가능하게 변경되는 경우 메일을 보내 알림을 주는 등, 다양한 기능이 추가 됐다. 실제로 제공되고 있는 서비스들도 이러한 과정들을 거쳐 현재의 서비스가 되었을 것이라 경험해보는 귀중한 기회였다.

느낀점

학자형 공부를 하다가 야생형 공부를 해보니 정말 신세계였다. 책만 읽으며 탁상공론하기보다, 직접 프로젝트를 만들며 부딪히니 정말 빠르게 성장함을 느꼈다. 강의에서 제공되는 잘 동작하는 예제를 따라 치는 것과, 내가 손수 작성하여 에러가 뿜어져 나오는 코드를 해결하는 것의 성장 속도 차이는 상당했다.

직접 부딪히는 성장도 경험했지만, 동시에 장벽도 경험했다. 프론트도 다르지 않겠지만, Java라는 언어, Spring이라는 프레임워크의 깊이는 예상보다도 깊었다. 어떻게 매번 새로운 에러와 지식들이 나를 반겨주는지 놀라울 지경이다. 이런 놀라움은 비단 언어와 프레임워크에 그치지 않는다. Devops라는 거대한 영역은 또 한 번 커다란 충격을 주었다. 수많은 컴퓨팅 용어와 네트워크 용어들로 어려움을 겪었고, 그러한 용어들에 익숙해지는 과정이 분명히 필요할 것이라 생각된다.

사이드 프로젝트가 그렇다고들 하지만, 끝까지 마무리하지 못해 아쉬움이 남는다. 나부터 열심히 사용하며 애정을 갖고 운영을 했다면 더욱 많은 경험을 해봤을텐데, 운영 단계를 경험하지 못하고 프로젝트를 끝내게 된 것이 못내 아쉽다.