Git : Wordy
당연하게도(?) 시작은 순조롭지 않았다.
기획단계에서 소극적인 반응들, 프론트 직무 희망자가 없고 초기 이탈자가 생기는 등의 많은 이슈가 있었다.
전에라면 급한 성격에 나서서 이렇게하고 저렇게하자 그랬겠지만, 전 프로젝트 때 너무 의욕이 앞서 자기주장만 내세우다 마찰이 생겼던거 같아 이번엔 한 발짝 뒤로 물러나있기로 마음먹은 터라, 어느정도 마음을 내려놓고 프로젝트를 진행하게 되었던것 같다.
또 이번 프로젝트엔 필수로 AI기능을 접목시켜야 했었는데 나는 자신이 없었다.
관심분야가 아닌데다 다소 높은 난이도, 살짝 꺽여버린 마음(?ㅋ)까지 더해져 AI 모델이 어떻게 구성되고 돌아가는지 정도만 이해하고 있었을 뿐, 실제로 모델을 만들고 학습시키기엔 역량이 부족한 상태였다.
다행이도 해당 기술에 관심을 가져주신 팀원분들이 계서서 AI관련 직무에서 벗어날 수 있었지만 프론트 직무 희망자가 아예 없는게 가장 큰 문제였다.
결국 프론트 개발경험이 있으신 한 분이 총대를 메고 혼자서 프론트를 담당하시기로 했지만, 개인적인 사정으로 중도하차까지 고려를 하고 계셨던 상태였기에 사실 이 때 프로젝트가 완성되지 않을수도 있겠구나 생각했었다.
프로젝트는 혼자 할 수 없고, 각자 희망하는 바도 다르기에 어쩔수없이 이런 상황이 생기게 된다.
하지만 나도 못하는걸 다른 사람이 해주길 바라는건 이기적이라 생각하니 좀 더 마음을 내려놓고 편안하게 진행을 했었던 것 같다.
그렇게 프로젝트는 진행되었고 프론트 개발 진행 속도가 썩 좋지 않았다. 우리가 메인으로 사용해야할 데이터셋 가공에 차질도 생겨 초기에 기획했던 기능들을 하나 둘 씩 없애기 시작하니 내가 할 일이 점점 사라지기 시작했었다.
막바지에 팀원 모두가 프론트개발에 두 손 두 발 다 거들어서 완성시켰는데, 다들 프론트 직무를 희망하지 않음에도 불구하고 너무나 잘해주셔서 나만 편하게 버스에 탑승한 기분이다.
팀원들의 노고와 희생 덕분에 상당한 여유?를 부릴 수 있었는데, 그 전 프로젝트에선 밀려오는 업무량에 데드라인까지 기능개발에 초첨을두고 했었다면 이번엔 내가 작성한 코드를 되돌아보고 생각하고, 나아가 최적화까지 해볼 수 있는 기회가 생겼었던 것 같다.
최대한 아주아주 쉽게 설명하자 (feat. 문서화)
간혹 프론트 직무자와 대화를 하다보면 서로 무슨말을 하는지 모를때가 자주 생긴다.
프론트 : 이건 이렇게해서 이러이러하게 전역관리를 할거에요
내 입장에선 대충 외계어처럼 들린다.
이런 일도 있었다.
Front : 이건 DB 어디에 들어가있는거에요?
me : 아 그건 OOO 테이블에 저장되어있어요.
Front : 그럼 DB는 어디에 있는거에요?
me : ㅖ?내가 프론트의 상태관리에 관심이 없듯이, 상대도 내 직무 관련 지식에는 관심이 없을 수 있다.
어디까지 내 입장에서나 시스템 아키텍쳐라든지, 데이터베이스라든지 끊임없이 생각하기에 당연한 개념들이지만
상대방 입장에선 용어조차 어려운 벅찬 개념일 수 있다.
당연히 이정도는 알지 않을까? 하고 뱉은 말들이, 상대는 되물어보기 민망하기에 이해하지 못한 채 넘어가서 결국 더 큰 문제를 만든 경우도 많지 않았나 생각이 든다.
API명세서를 별도로 작성하지 않고 swagger를 사용하기로 했었는데 swagger를 처음 접해본 프론트 입장에선 이 조차도 어려웠던 터라, 프로젝트가 어느정도 마무리되어가서야 어떻게 사용하는건지 물어보셨는데 좀 신선한 충격이였다. 이해를 위해 swagger와 같은 기능들을 어떻게 사용해야하는지 설명을 적어두고, 서비스 로직이 어떻게 흘러가는지 시퀀스 다이어그램을 그렸었는데 충분하지 않았던건가 생각했다.
협업에 있어서 상대를 얼마나 정확하게 이해시킬 수 있는지는 정말 중요한 것 같다.
상대는 내가 만든 문서가 어디에 있는지조차 상상 이상으로 관심이 없다. 포기하지 말고 끊임없이 이해시키고 알려주어야 한다.
또 모르는게 있다면 주저하지 않고 물어볼 수 있는 자세 또한 중요한 것 같다(나도 전 프로젝트에서 패스파람과 쿼리스트링의 차이를 몰랐지만 마음속 깊은 곳 자존심으로 인해 입꾹닫 하고 사고를 쳤었다..)
이 에러가 당신것이 아니라는 보장은 없다
보통 API를 개발하면 포스트맨이나 Jest같은 라이브러리를 사용해 해당 기능들을 테스트한 후 프론트에 전달하는 방식으로 개발을 진행했었다. 내 쪽에서 테스트에 문제가 없는 상태라면 '서버는 정상적으로 응답하고 있는데요?' 시전을 자주 나는모르쇠 하게 된다.
그렇게 프론트직무자의 울부짖는 아우성에 눈을 감고 귀를 막았지만, 사실 알고 봤더니 해당 에러는 배포과정에서 경로를 잘못설정해 요청이 길을 못찾고 있던 상황.
문제의 시발점은 처음으로 도메인을 사용해봤고, nginx 를 리버스프록시 서버로 사용하게 되면서 나 조차도 아직 익숙하지 않은 기술을 사용해놓고 문제없이 돌아가고 있다 스스로 확신해버린 것이다 (미안해 도은짱..그리고사랑해)
완벽한 코드는 없다 특히 내꺼
방심하지 말자.
시스템 아키텍쳐
그 전 프로젝트에선 그저 단순히 프론트를 nginx로 배포하고, 서버는 pm2로 배포하는 아주 단순한 방법을 사용했다면, 이번엔 어느정도 여유가 생겨서 CI/CD까지 적용한 배포를 진행해보고자 했었다.
CI/CD는 캠프에서 제공하는 VM의 ssh키가 없어서 실제로 정상작동하는지 확인은 못했지만, 도커를 이용한 배포는 상당히 재밌었다. nginx 프록시 설정은 거의 헤딩한 수준으로 혼자서 처음 해보는거라 어려움이 있었지만 이론으로만 알고 있던것들을 직접 해보는 좋은 경험있다. 다음 사이드프로젝트에선 jenkins와 쿠버네티스를 이용해볼 예정이다.
쿼리 최적화
한 번의 요청에 하나의 쿼리가 가장 이상적이다
안다. 귀에서 피날 지경이다.
하지만 막상 api를 개발하다보면 정말 지키기 어려운 이상향이다.
데이터베이스를 어떻게 설계하는지도 중요한데 이미 어느정도 완성이 되어버린 상황에서 데이터베이스 구조를 고치기란 쉽지 않다. 그렇기에 또 초기 기획이 중요하다.
그동안 진행했던 프로젝트에선 성능이고 뭐고 테스트해볼 시간도 없이 기능개발만 하기 바빴지만, 이번엔 상당한 여유가 있었기에 내가 작성한 쿼리를 되돌아 볼 기회가 생겼었다.
이번 프로젝트에선 단순히 기능개발이 아닌, 시스템을 어떻게 설계하고 성능을 어떻게 개선할것인지에 대한 많은 고민을 해볼 수 있는 기회가 있어서 좋았다. 사실 이제 기능구현보단 이런 부분에 대해 더 깊은 고민을 해봐야하지 않나 생각이 든다.
