1.이 글은 2023년 8월부터 2024년 2월까지 진행된 플레이데이터 데이터 애널리스트 과정의 최종 프로젝트에서 했던 내용들을 정리하는 글이다.
2.프로젝트 개요에 그치지 않고, 프로젝트에 쓰였던 기술들과 코드들을 전체적으로 리뷰할 것이다. 그렇기에 이 글에 끝나지 않고 시리즈로 글을 연재할 것이다.
한 시리즈에 하나의 프로젝트에 쓰인 기술 스택을 총 망라하여 정리할 것이다.
3.프로젝트 소개
이름:ROADs
이름 해석: Road Obstacle Ai Detection service(도로 장애물 ai 감지 서비스)
프로젝트 기능:
1.yolo 모델로 도로 장애물을 감지하고, 그 정보를 데이터베이스에 저장한다.
2.데이테베이스에 저장한 데이터는 지도에 마커로 나타난다.
3.'지자체 페이지'에 가면, 기간/지역별로 데이터를 보이게 할 수 있다.
4.'데이터 상세보기'에 가면, 기간/지역/아이디별로 데이터를 보이게 할 수 있다.
이 프로젝트는 pm포함 4명이서 진행했으며, 크게
pm/머신러닝,딥러닝 파트/웹 개발
파트로 나뉘었는데, 필자는 웹 개발 파트를 맡았다.
그래서 이 시리즈도 웹 개발을 어떻게 했는지를 위주로 작성할 계획이다.
물론, 주제를 정하고, 딥러닝 모델을 정하고, 어떤 데이터로 학습을 시킬 것인지 등에 관한 것들을 팀원들과 같이 정했다.
4.프로젝트 진행 과정-처음엔 그랬지....
우리는 플레이데이터가 소개해 준 멘토님의 지도에 따라서 프로젝트를 진행했었다.
처음에 우리는 주제만 대충 정하고, 어떤 방식으로 개발을 할 것인지에 관해 정해두지 않았으나, 멘토님께서
개발 목적,흐름 등을 문서화하지 않으면, 프로젝트를 관리하기 어렵다.
라는 말씀하신 것을 듣고, 개발에 착수하기 전에 관련 문서들을 작업했다.
이번 글에서는 개발 관련 문서들을 소개하고, 실질 개발 과정은 다음 글부터 소개하도록 하겠다.
작업한 관련 문서들을 소개하겠다. 처음은 srs이다.
5.srs(Software requirements specification)
srs는 개발하고자 하는 소프트웨어가 무엇을 하는 것이고 어떻게 작동할지를 예상하는 문서의 집합이다.
쉽게 말하면, 종합 설계도와 같다.
srs는 종합 설계도와 같으며, 프로젝트의 전체적인 그림을 제공하기 때문에, 개발 프로젝트에서 매우 중요한 위치를 차지하고 있다.
아래는 우리 팀이 작업한 srs의 예시이다.


이런 식으로, 아이디어가 무엇이고, 제공하고자 하는 서비스가 무엇이고, 각 단계에서 어떤 기능을 하는지에 관해 자세히 작성한다.
또한, 개발을 할 때 중간중간 이 문서를 확인하면서 어떤 부분이 개발 완료되었고, 어떤 부분이 부족한지 체크를 했다.
6.기획서
우리가 아는 기획서와 같다. 프로젝트에 대한 기획을 문서로 작성했다.
서비스 구성,수행 절차, 계획 등을 작성했다.





7.개발 설계서
데이터베이스 설계, 화면 설계 등 프로젝트에서 설계가 필요한 모든 부분에 대한 설계서를 작성했다. 아래는 설계서에서 일부분만 따온 캡쳐 이미지이다.







8.데이터베이스 스키마
간단하다. 데이터베이스에 어떤 컬럼이 쓰일 것인지, 컬럼의 자료형과 primary key 여부 등을 세세하게 적은 문서이다.

9.이렇게 문서 작업들을 모두 마친 다음에야 멘토님께서 개발 작업을 시키셨다. 처음에는 왜 코딩을 하는 것을 재치고 문서를 먼저 작성하게 하셨는지 이해가 가지 않았지만, 개발을 하면서
미리 작성해 둔 문서들을 토대로 개발을 하니 길잡이가 잘 되는구나!
라는 생각이 들어서 다행이라는 감정이 들었다. 멘토님에게 감사한 마음은 덤이었다!
10.기술스택
이렇게 프로젝트를 진행했을 때, 기술 스택은 아래 이미지와 같이 나왔다.

글로도 설명을 해보자면,
collaboration: google drive, slack, github
design: figma, function12
data: ai hub,postgresql
cloud:aws(s3,polly)
analytics/machine learning: python,pytorch,opencv,yolov8
web:flask,html/js/css
back-end:spring-boot,spring data jpa,java
이렇게 기술 스택이 나왔다.
딱 봐도 많아 보이고, 많은게 사실이기도 하지만, 프로젝트를 효율적으로 진행하고자 고민을 한 결과 저런 기술스택이 저절로 쌓였다.
(그러니 '프로젝트 하려면 저 많은걸 해야 해?'라는 고민은 접어 두시라.... 필자도 했는데 여러분도 못할 거 없다! :) )
11.팀으로 개발을 하면서 어려웠던 점/해결책
1.멘토님의 멘토링이 약간 회사의 부하직원을 대하듯이 너무 엄격했다.
그리해서 팀원들과 '멘토님과 어떻게 의견 조율을 해 나갈까'에 대해 저절로 토의를 많이 하게 되었고, 성공적으로 의견 조율을 해 나가고 프로젝트를 끝마칠 수 있었다.
2.부트캠프의 막바지에 이뤄진 프로젝트였다 보니, 팀원들이 오전에 오지 않거나 의견에서 갈등이 생기거나, 중간에 팀원 중 한명이 나갔다거나 하는 갈등이 있었다. 하지만, 나간 팀원도 '취업'이라는 정당한 사유로 나간 것이고, 기본적으로 서로가 갈등을 원만히 해결하고 프로젝트를 끝내고자 하는 목적으로 뭉쳤었다. 그래서 문제나 갈등이 생길 때 마다 서로가 원만하게 해결할 수 있었다.
솔직히 말해서, 다른 팀은 중간에 사람이 탈주하고 잠수타고 그런 일이 있었다는데...(누군지는 모른다.)그 점에서 너무 다행이라고 생각이 든다.
12.자, 다음 글 부터는 본격적으로 개발 구현에 대해 글을 남길 예정이다.
본격적인 개발 구현이 궁금하다면 다음 글을 봐주세요! :)
13.깃허브 주소
필자의 코드들을 저장한 깃허브 주소이다.
(궁금하시다면 방문을 추천드립니다!)