[프로젝트 회고] SSAFY 특화 프로젝트를 마치며

  6주 간, 2023.2.27 ~ 2023.4.7 기획부터 설계, 개발, 발표까지 팀 프로젝트를 진행했다. 두 번째로 진행한 프로젝트였지만 첫 번째와는 많이 달랐다.

 

 우선 개발적으로는 팀이 선택한 트랙에 맞는 '빅데이터 분산' 프로젝트를 진행해야 했었다는 점에서 기획과 기술적 제약 때문에 난이도가 높았다. 그리고 첫 번째 프로젝트 끝나자마자 바로 두 번째 프로젝트에 투입이 되어서 체력적으로도 지쳤었다. 이 두 가지 요인이 합쳐져서 힘들게 프로젝트를 진행했다.

 

 세번째 프로젝트에 바로 들어가게 되어서 바빠지기 전에, 그리고 잊어버리기 전에 지난 6주 간의 프로젝트 과정을 돌아보고자 한다. (🥕쉬고 싶어요..🥕)

 

 

 

 

 

📢 프로젝트 소개

• 프로젝트 인원 : 6명 (프론트엔드 2명, 백엔드 4명 (백엔드 1명이 인프라도 함))
• 프로젝트 : 항공권 검색 및 여행 물품 거래 웹서비스
• 깃허브 링크 : 링크 내림
  
  
• 협업 : Gitlab, Jira,  Notion, Mattermost, Slack
• 기술 스택
  • Frontend : React, Redux, Style components, Javascript
  • Backend : Spring Boot, Spring Cloud, JPA, QueryDsl, MySQL, Websocket, Redis
  • Data : Selenium, Hadoop, Spark
  • Infra : AWS EC2, Docker, Jenkins, Nginx

 

 

 

 

 

👩🏻‍💻 나의 역할

• 빅데이터 처리(Selenium, Hadoop)
• 백엔드 개발(Spring boot, MySQL, JPA, QueryDsl)
• PPT, UCC, 시연 담당

 

 

 

 

 

🚩 프로젝트 과정

1. 기획

 

  우리 팀은 빅데이터 중에서도 분산 트랙을 선택했다. 그래서 빅데이터를 다루지만 분산 처리에 맞는 기획을 해야 됐었다. 기획이 생각보다 너무 어려웠다. 기획을 할 때 데이터셋이 있는지, 있다면 빅데이터인지 고려해야 됐었다. 그리고 빅데이터인데 주기적으로 데이터가 유입이 되는지도 고려해야 됐었다. 충분히 많은 양의 데이터를 구할 수 있음에도 주기적으로 데이터가 유입이 되지 않아 채택되지 않은 아이디어가 많았다.

 

 게다가 '빅데이터 분산'이라는 주제의 특징 상 빅데이터를 분산 처리하는 과정이 큰 기술적 포인트이고, 이것을 서비스화하기에는 검색 및 시각화하는 것 밖에는 생각이 안 났다. 그래서 기획적으로 적당한 분량의 유의미한 서비스를 생각하는 데도 어려움이 컸다. 이전 기수 분산 트랙의 프로젝트들을 찾아봤는데, 주제가 겹치면 좀 그래서 더 제한적이었다고 생각한다.

 

지난 프로젝트에서도 거의 2주차까지 기획을 하게 되었지만, 이번은 '빅데이터 분산'이라는 주제 때문에 기획이 더욱 힘들어서 시작 단계부터 기획을 정하고 데이터를 찾는 데 많은 시간과 에너지를 쏟게 되었다. 팀원들 모두 기획이 도무지 나오지 않아서 지쳐갔다.

 

 여러 아이디어 중, 항공권 검색 서비스를 주제로 정하게 되었다. 매일 꾸준히 항공권 데이터가 유입이 되고 있고, 이걸 쌓는다면  유의미한 빅데이터가 되기 때문이다. 하지만 데이터를 가져오는 것에서도 해결해야 될 점이 있었다. 항공권 API가 있었지만(스카이스캐너 API) 하루에 불러올 수 있는 건 수가 제한되어 있고, 모을 수 있는 정보가 한정적이었다. 그래서 항공권 사이트를 크롤링해서 데이터를 구하기로 했다.

 

 

 

 

 

2. 설계

 

 다같이 디자인과 컨셉 회의를 하고 기능 명세서를 작성했다. 그리고 프론트엔드를 맡은 팀원들은 피그마로 UX/UI 설계를 하고, 백엔드를 맡게 된 팀원들은 ERD 설계, API 설계, 아키텍처 설계를 했다.

 

 

 

• 기능 명세서

 

 다같이 기능 명세서를 작성하면서 기획을 구채화하고, 동시에 디자인 컨셉 UX/UI 등을 이야기했었다.

 

 

 

 

• 피그마

 

 저번 프로젝트는 웹앱이어서 모바일 뷰로 설계를 했는데, 이번에는 완전히 웹에 맞게 설계를 했다. 개인적으로 웹이 화면이 넓어서 설계하기에는 더 어려운 것 같다. 나는 이번 프로젝트에서는 디자인과 UX/UI에 관여를 많이 안 했고, 피그마를 하나도 안 만지고 완전히 프론트엔드에게 맡기게 되었다.

 

 

 

• ERD

 

 이전에는 서비스를 위해 필요한 정보만을 고려하여 DB를 설계했었다. 하지만 이번에는 크롤링을 해서 얻을 수 있는 데이터가 따로 있었고, 크롤링해서 얻어오게 될 데이터와 서비스를 위해 필요한 정보에 차이가 있었다. 이를 고려해서 DB를 설계해야 해서 까다로웠다. 그리고 실제로 개발 단계에 들어가서 크롤링을 하고 데이터를 처리하면서 누락되거나 추가적으로 필요한 정보들도 있어서 조금씩 계속 바뀌게 되었다.

 

 

 

 

 

• API 명세서

 

 이전 프로젝트에서는 Swagger를 적극 활용했기 때문에 API 명세서에 response는 말고, url 패턴과 request 위주로 적었다. 이번 프로젝트에서는 팀원들이 Swagger를 쓰지 않고, 직접 Json 형태의 request, response를 써 문서로 관리해 Postman으로 테스트를 한다고 했다. 그래서 이번 팀의 개발 문화에 맞게 API 명세서를 쓰게 되었다.

 

 Swagger를 쓰면 알아서 JSON 형태를 만들어주는데, JSON에 담을 필요한 객체 및 필드들을 직접 타이핑해야 돼서 귀찮았었다. 하지만 이 방식도 장점이 있다는 것을 깨달았다. Swagger는 따로 Entity와 Controller에 명시를 해야 하고, 배포를 해야 팀원이 문서를 볼 수 있다. 하지만 문서로 따로 정리해 둔다면 배포가 안되어도 서로 바로 확인할 수 있었다.

 

 

 

 

 

• 아키텍처

최종 아키텍처

 

 지난 프로젝트처럼 이번 프로젝트도 백엔드 서버가 Spring Cloud를 활용하여 MSA로 설계가 되었고, Docker와 Jenkins를 활용하여 CI/CD 환경에서 개발 및 배포되었다. 하지만 다른 점은 크롤링한 데이터셋부터 DB까지 이어지는 빅데이터 파이프라인이 있다는 것이다.

 

또한, 프로젝트 막바지에는 프로메테우스나 엘라스틱서치 같은 모니터링 도구도 추가가 되었다.

 

 

 

 

 

• 빅데이터 파이프라인

 

 

 항공권 정보를 Selenium을 활용해 크롤링해서 파일로 저장하고, 큰 용량의 파일(빅데이터)를 Hadoop에서 읽어 처리해서 저장하고, Spark를 통해 고속으로 연산 처리를 하고, RDB로 이관하는 데이터 파이프라인을 설계했다.

 

이번 프로젝트에서 처음으로 빅데이터를 다뤄보기도 하고, 관련 지식이 전무했기 때문에 이에 대해 공부하는 과정이 오래걸렸다. 빅데이터 파이프라인을 설계하기 위해 빅데이터 시스템 아키텍처를 엄청 찾아 봐야 했다. 그런데 관련 자료도 많이 없어서 어려웠다.

 

 

 

 

 

3. 개발

• 크롤링

 Selenium을 이용하여 항공권 사이트에서 매일 약 40만 건의 항공권 정보를 크롤링했다. 크롤링하고자하는 웹 페이지를 분석해 항공권 검색시 출력해는 데 필요한 정보를 선택해서 가져오도록 했다.

 

 전세계 모든 주요 노선에 대해 크롤링해야 했고, 그 양이 방대했기 때문에 크롤링하는 데 많은 시간이 소요되어 팀원끼리 분량을 잘 나눠 크롤링을 해야 됐었다. 그리고 오랜 시간 크롤링하게 되면, 브라우저가 차단되었기 때문에 차단되는 주기를 분석하여 일정 분량마다 쉬었다가 크롤링해야 됐다.

 

 

• Hadoop

 매일 약 40만 건에 달하는 데이터를 처리하고 저장하기 위해 빅데이터 분산 시스템인 Hadoop을 사용했다. 여러 파일로 흩어져 있는 같은 날에 수집한 데이터들을(GB 단위였다) Hadoop을 통해 한 번에 전처리해 HDFS에 저장했다. 그리고 항공권 추이를 계산하기 위해 고속 연산을 지원하는 Spark 서버에 제공했다.

 

 하둡을 설치하고 실행하는 데 어려움이 있었다. 원래 교육 측에서 제공한 하둡 공용 클러스터에서 데이터를 처리하고 저장했었다. 하지만 여러 팀이 사용하다보니 공용 클러스터가 중단되고 초기화되는 문제가 생기면서, 개발 환경을 팀 EC2 서버로 옮기게 되었다. Hadoop을 설치하고 설정하는 데 많은 시간이 소요가 되었다.

 

 

• Querydsl

 항공권 검색은 출발지와 도착지 날짜를 선택하고, 세부 검색 조건으로는 경유 횟수와 가격 범위가 있었다. 그리고 정렬(금액순, 경유지순)과 페이징, 카운팅까지 해야 됐다. JPA만으로 검색 기능을 구현하기에는 쿼리문이 복잡해지고, 많은 조건 분기 때문에 코드의 가독성이 안 좋아졌다.

 

 그래서 동적으로 쿼리를 생성할 수 있고, 정렬, 페이징 등의 기능을 효과적으로 처리할 수 있는 QueryDsl을 사용하게 되었다. QueryDsl을 쓰니 복잡한 쿼리를 한번에 처리할 수 있었고, 코드의 가독성이 증가했다.

 

 

• 인덱스 추가

 항공권 데이터가 많았기 때문에 조회에 많은 시간이 걸렸다. 조회 속도를 개선하려고 DB에 인덱스를 추가했다. 검색 필수 조건에 해당하는 컬럼들을 조합해 인덱스를 구성했다. 그리고 그 중 Query Cost가 작은 조합으로 인덱스를 추가했다. 결국 약 240ms가 걸리던 항공권 검색 API를 약 40ms로 줄일 수 있었다. 

 

 

 

그 외

• 데일리 스크럼

 매일 아침에 일과 시작 전, 팀에서 스크럼 미팅을 진행했다. 컨설턴트님께서 어느 회사의 개발 문화로 스탠딩 미팅을 영상으로 소개해주셨다. 미팅 시간을 줄이기 위해 서서 미팅을 진행하는 문화라고 한다. 그래서 우리도 매일 아침에 서서 각자의 개발 진행 상황과 해야 할 일에 대해 이야기하며 미팅을 진행했다. 아침에 활기차게 미팅을 빠르게 진행하기에 좋았다.

 

 

• 브랜치 전략

  자주 기능을 개발하고 실시간으로 배포를 해야했기 때문에 브랜치 관리가 필요했다. 우선 크게 Master, Develop, Feature 3가지 레벨로 나눴다. 그리고 Feature 브랜치를 각각 마이크로 서비스로 나눴고, 추가적으로 프론트와 백엔드로도 나누게 되었다. 이렇게 개발을 하니 인프라 단에서 CI/CD를 구성해 배포하기도 편했다.

 

 

• 개발 컨벤션

 팀에서 개발에 들어가기 전에 확실한 컨벤션을 정했다. Jira의 백로그 이름 규칙부터 Git의 커밋 메시지, 프론트엔드와 백엔드 프로젝트 파일의 패키지와 클래스명까지 정한 뒤, Notion에 정리를 했다. 그리고 이를 바탕으로 모든 팀원이 일관된 규칙에 따라 개발을 했다.

 

덕분에 Jira에서 진행 상황을 한눈에 파악할 수 있었고, 개발 중에는 같은 백엔드 팀원의 코드를 파악하기에 좋았다. 사소한 것이지만 팀 내에서 컨벤션을 정한 덕분에 개발 외에 드는 리소스를 줄일 수 있었고, 개발 컨벤션의 중요성에 대해 실감하게 되었다.

 

 

 

4. 발표

 

 

 

 

 

📖 배운 점 / 느낀 점

• 협업의 중요성

 

 

 

📖 아쉬운 점

• 설계

 

• 테스트 코드