시작하며,
요즘 공모전을 준비하느라 매우 바쁜 일상을 보내고 있다! 해당 공모전을 준비하며 배워가는 것이 매우 많아 블로그를 통해 글로 이런 과정을 남기고자한다.
공모전 초기부터 해당 글을 작성했으면 좋았겠지만 그렇지 못하여 공모전 초기의 과정부터 간략하게 요약하여 여기에 남기려 한다.
어떻게 시작되었는가?
사실 공모전에 참여할 생각은 없었다. 학교에서 진행하던 스터디 그룹에서의 마지막 과제가 팀프로젝트였으며 해당 팀프로젝트 주제를 고민하던 중, 기왕 할거라면 공모전에 나온 주제를 참고하는 것이 주제를 선정하는 것이 더 편할 것 같다 라는 말이 나와 공모전을 찾던 중 해볼만한 공모전을 찾게되어 참가하게 되었다.
팀원들은 이전 스터디그룹에 있던 인원 일부와 스터디그룹장의 지인 한분이 추가되어 구성되었고, 공모전에 제출한 아이디어에 간단한 살을 덧붙여가며 작업을 시작했다.
개발자에게 제일 힘든 것은 기획
보통 회사의 경우 기획자가 따로 있기 때문에 이런 고민은 하지 않는다. 그러나 우리의 경우 해당 프로젝트를 기획자를 데려오는 등의 프로젝트를 키우는 것 보다는 현재 있는 인원에서 프로젝트를 충실히 진행해나가는 길을 선택하였다.
어찌되었든, 기획단계부터 개발자 여럿이 모여 의논을 해야했고 그 중 가장 괜찮았던 주제 맛집지도 로 선정 하였다. 해당 주제의 경우 어느정도 기획이 되어있었고 해당 주제가 공모전과도 적합하게 잘 어울린다고 생각하여 선정하였다.
기획을 하면서 가장 어려웠던 점은 해당 기능을 구현하기 위해서는 어떤 데이터가 필요하며 해당 데이터를 어떻게 얻을 수 있을지 고민하는 것이었다.
처음에 구성된 기획안에 따라 초기 구성안과 기획의도 등이 담긴 피피티를 제작하여 제출하였고.감사하게도,본선에 진출하게 되었다.
문제가 발생했던 것은 본선진출 이후였다.
바로 초기 기획안을 토대로 개발작업을 하기 위한 데이터 수집이 매우 어렵다는 사실 때문이었다.
초기 기획안에는 우리의 차별점을 위해 매운음식 지도라는 기능이 있었다.
해당 지도를 만들기 위해서는 맵기의 기준을 어떻게 정해야하는지? 맵기는 어떻게 알 것인지? 등의 의문사항을 가지게 되었고,
이러한 정보는 객관적이지 못하기 때문에 해당 기능을 폐기하기로 결정하였다.
위에서 언급했던 맵기등의 기능이 엎어진 것 과는 별개로 단순하게 맛집지도라는 것이 메리트가 없다고 느낀 팀장이 우리 프로젝트를 사용해야하는 이유를 생각해보자고 건의하여 프로젝트의 방향성을 잡았다.
그리고 그렇게 잡힌 프로젝트의 주제는 혼밥족들을 위한 맛집지도였다.
주제의 타겟층이 명확하게 잡힌 것이다.
변경된 기획안에 따라 우리는 일단,프로젝트에 있어서 가장 필요한 데이터를 중심으로 수집하기로 하였다 바로 음식점 정보 이다.
데이터 이렇게 구하기 어려운 것이었나?
우리의 경우 기본적으로 가지고 있는 데이터가 없었기 때문에 인터넷 검색을 통해 데이터를 손수 수집하였다.
진짜, 손수 우리가 아는 맛집을 검색하여 이름,주소,전화번호,위치값 등을 수집했다.
물론 공모전에서 주는 API도 사용할 예정이긴 하지만,해당 데이터는 추후 이용하기로 하였기 때문에 음식점 데이터를 모으는 것을 우선으로 하였다.
항상 느끼는거지만 개발프로젝트를 시작하기에 앞서 가장 힘든건 발품을 팔아 데이터를 수집하는 일이다.이전에 보안관련 프로젝트를 진행하려고 했었는데 KISA에서 우리가 원하는 데이터를 배포하고 있어 해당 데이터를 받으려고 했더니 나주로 USB를 보내주면 데이터를 담아 택배로 보내준다고했었다. 보안때문에 어쩔수없는 상황이긴했지만 번거로웠다. 데이터를 구하기가 진짜 힘들다 이래서 기업들이 무료로 서비스를 풀고 사람들 데이터를 수집해가는 것을 선택한것같기도하다..이를테면 구글이라던가 구글이라던가..
본격적인 개발에 앞서 의논해야했던 것들
데이터도 수집했겠다 본격적인 개발을 시작하나 했는데 아직 멀었다.
아키텍쳐를 구성해야했다.
우리프로젝트의 아키텍쳐 구성은 다음과 같다.
넷플릭스 유레카 서버를 이용하여 스프링부트 프로젝트를 여러개로 구성한다.
1.유레카 서버 - client 서버들을 관리하는 서버이다.
2.api-gateway - 외부에서 접근하는 서버이다. 클라이언트단에서 api-gateway로 요청을 하면 api-gateway에서 적합한 micro service에게 전달해준다. 해당 서버에 cors와 관련된 설정들을 해주면된다.
3.micro-service - 백단에서 우리가 코드를 직접 작성하는 부분이다. 이러한 식으로 분리를 하면 각각의 서비스가 독립성을 유지하기 때문에 유지보수가 쉬워진다.
msa에 대한 자세한 내용은
MSA(Micro Service Architecture)로의 전환
참고하면 좋을 것 같다. 해당 내용에 대한 부분은 공부가 더 필요할 것 같아서 추후 블로그 포스팅으로도 올려보려고 한다.
글을 마무리하며
추후 본격적인 개발을 시작하였다.이제부터 그 이후 개발을 하면서 겪었던 문제라던지,고민에 대해서 차곡차곡 글을 작성하여 공유해보고자한다.
