항해 99 5주차 - 5일차

 "두둥" 오늘은 "두둥" 프로젝트 시작하는 날이다. 

 

 아침에 일어나자마자 듣게 되는 팀 변경과 같이 나오는 프로젝트 시작이라는 말, 솔직히 코딩 자체를 처음 하는 사람에겐 너무 빠른 속도가 아닌가...라는 생각을 굉장히 많이 해왔다. 하지만 뭐가 있다고 해도 나름대로 구현은 가능하니까(?) 일단 해보자 라는 심정으로 하려고 한다. 

 

 그런 이유로 오늘은 기획과 와이드 프레임, api명세서 스케쥴 조절 등 프로젝트를 진행하기 위한 기초적인 준비를 한 날이었다. 

 

 1. 기획 (+ 팀 빌딩)

 기획의 경우 가장 먼저 생각한 것은 팀이 좋아하는 것이 무엇인가 라는 포인트였다. 좋아하는 것을 중심으로 하여야

소비자의 관점으로 무엇이 필요한지 즉, 고객층에게 어떤 점을 어필가능한지 알기 편하다는 것이 1번이며 다음으로 이왕하는 거 즐겁게 코딩하자라는 것이 2번이었다. 그런 이유로 각각의 관심사를 말해 그중에 가장 많은 관심을 가진 " 낚시 " 가 

프로젝트의 중심 주제가 되었다. 

 주제를 중심으로 무엇이 필요하며, 어떤 것을 구현하고 싶고 어떤 형식으로 표현하고 싶은지 이 3가지 문제를 중심으로 api, 와이드 프레임, ERD를 구상하였다. 

 

 2. api명세서 

 지금 팀에서 담당하는 부분은 백엔드(이하 "백') Spring을 담당하고 있기 때문에 명세서를 어떤 식으로 표현하여야 프론트엔드(이하 "프")와 소통하기 간편할까 라는 관점에서 생각을 많이 한 하루였다. 생겼던 문제로는 DB의 구조를 생각할 때, 우리는 자동으로 생성되는 key값을 중심으로 생각한 것과 실제 사용하는 user_id를 혼동해서 생각해 오해가 생긴 점, 

백의 경우 단순하게 username 과 password를 통해 PostMan에서 데이터를 주고받는 것으로만 정보를 확인한 것으로 

인해 사용자와 닉네임을 그냥 무시하고 바로 하려고 했던 점 이 두가지가 명세서를 작성하면서 가장 크게 당황한 소통의 

문제였다고 생각한다. 

 

 때문에 이런 점은 현재 username이 사용자가 아니라 Id로 사용하고 있는데, 혹시 사용자로 생각하시는 게 맞으신가요? 와 같은 방식으로 실제 생각이 다른 부분을 확인하는 방식으로 문제지점을 찾고, 수정해 나가며 서로 표현하고자 하는 바를 

명세서에 모두 넣었다고 생각한다. 

 

 더하여 백의 관점으로 볼 때 이런 데이터도 필요한가? 싶은 정보들도 우린 이걸 이런식으로 표현 가능해요~라는 식으로 프에서 와이드 프레임을 통해 보여주니 소통이 보다 편리했던 것 같다. 처음 해보는 프와의 협업이었는데, 나름대로 서로를 의식하여 말하지 못한 게 아니라 조율해 가는 과정이 순탄하고 합리적으로 진행되어 보다 협업이 즐겁게 다가온 프로젝트 시작이었다고 생각한다.