Kernel360 :: 파이널 프로젝트를 회고하며..

이번에 파이널 프로젝트 종료 발표회를 하면서 어느덧 이 긴 여정의 끝도 다가오고 있습니다.

정규 개발관련 과정은 모두 끝나고 남은 기간은 취업 준비기간으로, 2주뿐이 남지 않아 사실 끝났다고 보아도 무방하긴 합니다.

파이널 프로젝트를 진행하면서 겪은 회고를 남기고자 이렇게 글을 한편 남깁니다.

이번 파이널도 제가 팀장으로 아래의 플랫폼을 개발 하였습니다.

https://kernel360-final-1.oopy.io/1cb51560-c111-453e-922a-efd7329ed7aa

3팀 : WashFit

github :: https://github.com/Kernel360/F1-WashFit-BE

GitHub - Kernel360/F1-WashFit-BE: 세차용품 안전정보 제공 및 검증 된 세차 정보를 보여주는 플랫폼

무엇을 했는가?

ㆍ기획 총괄, 백엔드 팀장
ㆍ회원가입, 로그인, 플랫폼 보안관련 코드 작성
ㆍ모니터링 시스템 구축

사실 이 프로젝트 주제를 발의를 할까 말까 좀 고민을 했었습니다.

팀장이라는 직책을 맡으면 개발을 하기 힘들고 다방면으로 신경을 써야 한다는 점

모두가 다방면으로 쉽게 이해 할 수 있는 주제가 아니라면, 결국 팀장이 기획을 도맡아 진행해야 한다는 점

나는 배우러 왔는데 기술적 시도보다 다른 부분에 대해서 많이 신경 써야 할 일이 생긴다면 좀 그렇지 아니한가?

스스로 돌이켜보면 잘 알고 있었는데 이 주제를 썩히자니 이렇게 사람 모여서 각잡고 해보기도 쉽지 않을 것도 알기에 포기하기도 아쉬웠고 될대로 되라 되는만큼 하자 라는 식으로 스타트를 끊었고 중간에 고난이 좀 있었지만 아무튼 결국 최소한의 기능을 제공하는 알파버전 플랫폼이 완성 되었습니다.

무엇이 좋았나?

ㆍ생각만 하고 있었던 플랫폼의 실체화 구현

이 플랫폼의 필요성은 예전 2018년도때부터 착안하여 현재에 이르러서도 이러한 플랫폼이 나오지 않아 필요로 함을 느꼈습니다. 세차에 관심있는 사람들의 주 된 고민은 '내가 쓰는 제품의 정보를 찾아보기 힘들다' 인데 이러한 갈증을 해소함에 있어 좋은 기획이었다 생각합니다. 이러한 생각을 할 수 있는 원동력은 글을 쓰는 저부터가 세차에 관심이 많기 때문이었습니다.

ㆍ공정한 출발선

개발을 하려면 팀이 있어야 하는데 팀원 리쿠르팅은 파이널 프로젝트의 대한 주제 발표를 한 이후 크루분들의 자율적 지원으로 이루어졌습니다. (1~3지망 지원순) 그렇기에 백엔드 팀은 이견없이 자신이 어떠한 이유로든 자신이 하고싶어서 모였고, 과정이 끝나는 이날까지 꾸준한 참여율을 보임으로써 백엔드쪽 개발은 문제 없겠지 싶었습니다. (결국 문제는 있었지만)

ㆍ본받을 점있는 훌륭한 팀원분들과의 협업

팀원분들이 스스로 나서서 어떠한 것을 더 해야 할지, 무언가를 구현 할 땐 기획 의도와 부합한지, 기술적 구현을 할 때 고민의 시간을 가지고 잘 모르겠다 싶으면 바로 물어보고 해결하려는 자의적인 태도, 코드리뷰를 통해 개선이 필요한 부분은 과감히 이야기 함으로써 코드 품질에도 신경쓰고자 하였고 대내 대외 넓은 범위로 신경을 쓴다고 놓친 부분들이 많았는데 팀원분들의 도움덕분에 무사히 진행 할 수 있었습니다.

무엇이 아쉬웠나?

ㆍ출발선은 공정했지만 신호탄은 공정하지 않았다 → 뜻이 맞는 팀을 꾸리기가 힘들었다

백엔드팀은 그렇게 꾸려졌다 쳐도, 결국 트렌드를 따라가는 기술스택에 맞춰가는 개발을 한다는건 프론트엔드도 전담해야 할 사람이 필요한데요. 과정 중간중에 프론트엔드 개발자도 투입하자로 급하게 결정되어 패캠측에서 구인을 해주긴 하였지만 팀당 인원 2명 고정 배당을 약속하였어도 참여자가 부족한 관계로 결국 적지적소에 인력을 배치받지 못했습니다. 이로 인해 전체적인 프로젝트의 진행이 늦춰진 것이 아쉬웠습니다. 커널 2기부턴 프론트/백엔드를 같이 뽑는다고 하니, 지금보다 나아질꺼라 믿습니다. ^^

물론 프론트엔드 배정도 파이널 프로젝트 발표를 통해서 공정하게 프론트분들이 지망하여 배정을 하는 것이므로 구미가 당겨지도록 발표를 잘 못한 본인의 잘못, 접근성이 떨어지는 프로젝트 주제도 영향이 있었을 것입니다.

그래도 지금 결과물을 만드는데 있어 뒤늦게나마 프론트엔드, 디자이너 훌륭한분들이 참여해주시고 만나게되어 공식적인 발표 이후에도 지속적인 개선 개발을 할 수 있을 것 같다 생각이 듭니다. 확신이 아닌, '같다'의 표현은 현재가 신입 공채 시즌이기도 하고 취업이 우선인 분들이 대부분이기 때문입니다. (기존 프론트 2인은 구직하러 가시고, 새롭게 한분이 오신 상태입니다.)

ㆍ봉은사까지 왔다갔다 하는 이동시간이 참으로 아깝구나

저의 주거지가 인천 끝자락인 관계로 항시 모여서 진행하는 서울 동쪽 끝 패스트파이브 삼성 4호점까지는 거리가 완행 2시간 급행 1시간 반정도로 기대보단 가까울수도, 그러나 출퇴 시간을 생각했을땐 결국 먼 거리입니다.

이 거리의 대한 고민은 과정 초기 1주차때도 했었는데요. 많은 시간을 갈아넣기도 부족한 파이널 프로젝트에서 결국 이부분이 발목을 붙잡혔습니다. 주차지원이라도 되서 차로 이동을 다녔다면 아침 일찍 나오고, 밤 늦게 갔을텐데 대중교통을 이용해서 이동하는 과정에선 한번에 앉아가지 않는이상 코드를 보지도 못하고 허공에 날리는 시간이 되버려서 아쉬웠습니다.

 

ㆍ기술적 시도에 대해 한계까지 부딫치진 못했다. 

이번 프로젝트를 하면서 수많은 기술 스택과 인프라를 구축하여 플랫폼을 만들었는데요. 분명 경험 한 것은 좋은 일입니다.

그러나, '이 기술스택 또는 인프라를 왜 썼고, 어느정도 아느냐, ~한 상황이 있을때 어떻게 대처 할 것이냐?' 같은 물음을 듣는다면 온건히 대답 할 수 있는 스택이 많지 못함을 느꼈습니다. 특히 필자가 관심있게 바라본 JPA의 대한 활용 능력 극대화, JPA만으로는 결국 한계가 있는 쿼리 속도 개선을 위한 Querydsl 활용, RDB의 통신을 최소화 하기 위한 MemDB 활용은 만족할만큼 하지 못하여 별도의 시간을 들여 공부를 더 해야겠다라는 생각이 들었습니다. AWS도 말할 것 없지요.

많은 기술스택을 도입함으로써 좋은점은 이 기술스택이 어느 시점에 도입되어야 할지, 도입 시기가 어긋난다면 어떠한 사이드 이펙트가 발생하는지의 대한 체감을 어김없이 할 수 있었습니다.

하나만 예시로 뽑자면 flyway라는 sql 형상관리 라이브러리는 변화가 보수적인 운영단계에선 변화의 대한 히스토리를 여김없이 파악 할 수 있고 여차하면 롤백하기에도 수월해지므로 좋은 것임이 분명하지만 기획의 변동에 따라 구조가 언제든 틀어질 수 있는 개발단계에서는 적용이 부적절하다 느꼈습니다. flyway가 관리하는 sql이 적용 될때마다 그 시점의 키를 별도로 스키마 히스토리 테이블에 저장하게 되는데 이와 관련된 변경감지가 발생한다면 에러를 내뱉기 때문입니다.

일궈낸 기술적 시도?

액추에이터 기반 모니터링 시스템에 대해 개요를 이해 할 수 있었다.

제가 작성한 이 공간의 블로그 글로 확인 할 수 있습니다.

JPA 환경에서의 CRUD, Querydsl을 활용한 응용 조회

이 부분도 추가 개선 될 저희 프로젝트 깃허브 리드미에 추가 될 예정입니다. (정리하기엔 내용이 많네요)

Spring Security 없이 구현 한 보안관련 설정들

제가 담당한 파트가 이전 근무 경험에서도 중히 여겨지는 파트였지만 직접 실제로 구현을 하진않고 운영 레벨에서 약간의 핸들링을 주로 맡았었기에 이번에는 직접 한땀 한땀 구현을 해보자라는 생각이 들었습니다. 특히 스프링3 기반의 스프링 시큐리티도 같이 사용했었는데 이때는 애노테이션 설정 및 bean 생성 기반이 아닌 xml에서 한땀한땀 설정해주던 상대적 레거시 코드를 다뤘었습니다. 덕분에 지금의 스프링 부트 2.x ~ 3버전에서 많이 추상화 되어있는 시큐리티에 대해  어느정도 큰 흐름은 이해를 하고 있었는데 이 것 때문에 저희 플랫폼에서 굳이 시큐리티를 써야 할까? 라는 생각이 먼저 들었고 그에 따라 머릿속에 나름의 판단은 있었지만 해답을 경험하고 싶었습니다. 겸사겸사 세션 기반이 아닌 요즘 많이들 쓰는 jwt라는 기술 스택에 대해서도 새로이 익히면서 플랫폼을 이용하는 사용자 입장에서 이 기술스택 이점과  리프레시 토큰이 왜 대중적인 방법인지에 대해 이해 할 수 있었습니다.

플랫폼이 얻어낸 성과

서비스 제공을 위한 API 엔드포인트 75개 개발

초록누리 openAPI를 통해 세차용품 안전정보 5500건 수집

화학제품 관련 다른 분야 (화장품, 디퓨저 등) 확장 가능성 확인

구독자 10만, 65만 보유중인 유튜브 채널에서의 홍보 (알파버전만으로는 사용자 참여형 기능이 부족하므로 추후 예정)

6개 브랜드에 대한 제품 정보 등록 협약

앞으로의 계획

도메인을 구매한 김에 1년치 만료 될때까지는 운영...하고싶다(?)

요즘 개발자 채용은 운영경험을 많이 봅니다. 헤드라인이 꽤 높아졌죠. 그런 의미도 있고, 이 플랫폼 자체도 목표로 한 만큼의 기능을 달성한다면 상당한 수요가 발생 할 것이라 예측되어 엄근진하게 창업까지 생각 해 볼 수 있지 않을까 싶습니다.

물론 운영을 하려면 저 혼자만으로 되는게 아니고, 현재 참여중인 디자이너분과 프론트 개발자분이 어느정도 약속 된 기간까지 같이 함께 해주셔야 가능하다는 점이....