프로젝트를 열심히 달린거 같은데, 막상 나오는 결과물이 영 흡족하지 않는다.
가만히 생각해보면, 자잘한 것들에 시간을 조금 뺏기는 느낌이다.
API
가장 큰 고민이다.
어째서인지 모르겠지만, Spring에서는 model의 형태와 리턴값 등을 DB와 맞추지 않았다.(5년 전에 Spring 배울때는 맞췄던거 같은데...아마 디자인 패턴이 바뀐거 일수도 있다. 나중에 공부해야겠다)
그래서 API의 수많큼 다양한 Type이 프로젝트에 존재하게 되었다.
초기에 기획을 할때 협업에 대한 부분을 충분히 고려했어야 한다.
그리고 API에 대한 처리를 요청하면 당장 Spring은 새로운 기술을 도입하는라 API를 후순위로 미루는 경우가 있었다.
그때 당시 어차피 혼자서 할 수 있는 다른 일들이 있었기에 혼자 처리를 하면서 API가 완성되면 API 작업을 하고, 또다시 기다리는 동안은 혼자 할 수 있는 일을 하는 식으로 협업을 했다.
Spring 입장에서는 편하지만 돌이켜보니 정신없이 옮겨다니라 복잡했던 것 같다.
가끔 API를 말도없이 바꾸는 경우가 있었다.
초반에는 정보를 계속 요청하다가 후반부에는 귀찮아져서 Spring 소스코드를 가져다가 직접 까서 보는 방식으로 해결했다.
Spring에도 관심을 가지는건 좋은 자세지만...협업을 생각한다면 서로간의 합을 맞출겸 계속 주의를 줘야했을지도 모르겠다.
디자인
물론 가장 큰 문제는 디자이너의 탈주였다.
와이어 프레임으로 개발을 진행하다보니 고민이 많았고 망설임도 많았던것 같다.
CSS의 깊이가 부족해서일까 기능을 만드는 것보다 더 큰 시간을 CSS와 디자인에 쏟은것 같다.
명확한 목표가 없이 방황하면서 만들었기 때문에 더욱 많은 시간을 쏟은것 같다.
기획
가장 큰 문제가 디자인이었다면, 가장 아쉬운 것은 기획었다.
원래 초기의 프로젝트 기획은 WebRTC를 이용한 음성 통신 및 채팅 기반 어몽어스(마피아류) 게임을 하고자 했다.
Spring 또한 미디어 서버, 소켓 관리 등의 기술적인 챌린지가 있고,
Front 또한 다양한 게임 디자인(나는 도트풍의 디자인을 그리는게 취미였다), 페이지, WebRTC 및 WebSocket을 도입할 수 있고 다른 일반적인 프로젝트에 비해 차이점이 있기 때문에 만족스러운 아이디어였다.
아쉽게도 이 아이디어는 프로젝트를 시작하고 바로 폐기되었다
'알아보니 Spring이 WebRTC해도 Node로 하는게 더 나아서 별다른 메리트가 없네요'
그리되어 우리는 좀더 일반적인 아이디어를 고민했고 그게 레시피 공유 사이트였다.
처음 아이디어를 내면서 제법 많은 의견을 냈었다. Open API를 통한 현재 물가 데이터를 연동시키는 기능등을 고려했었다.
하지만 아쉽게도 일정 문제와 방향성 문제로 개발은 되지 않았다.
사실 많은 것들을 놓친 느낌이다.
왜냐면 우리의 중점은 기술적인 것이었기 때문이다.
'우리 일단 기술적인 걸 중심으로 고려를 하죠'
배우기 위해 왔다는 의견이 주류였기에 자연스레 우리는 어떤 기술을 도입할까 라는 이야기가 나왔다.
Spring은 엘라스틱 서치을 통한 검색 기능을 도입하고자 했다.
Spring의 기술적 챌린지를 만족시키고 나서 고려를 해본 React 챌린지는...그냥 페이지 였다.
자잘한 일들을 디테일하게 고민하고 처리하는 것이 기술적 챌린지가 되었다.
물론 그 다짐은 디자이너가 탈주하고 할일이 늘어나면서 많이 놓치게 되었다.
어떻게 해야했을까?
협력은 중요하지만, 일방적인 협력은 언젠간 한쪽이 무너진다.
이번 경험은 그걸 배운것 같다.
어쩌면 조금은 이기적으로 나를 위한 의견을 냈어야 했었던것 같다.
디자이너 집안에 개인적인 문제가 생긴건 슬픈 문제지만, 인간으로서의 공감대신 책임감을 좀더 자극했어야 할지도 모르겠다.
기술적인 챌린지가 없다면, 개인 공부를 좀더 치중했어야 한다.
프로젝트를 위해 개발하는 만큼, 나를 위한 공부를 좀더 치중했어야했던것 같다.
많은 경험을 남긴만큼 아쉬움도 큰 프로젝트였지만,
돌아가기엔 늦은만큼 그저 좀더 아름다운 마무리를 해야겠다.
잘 읽었습니다.