팀 프로젝트 19일차 회고

·2022년 5월 27일
0

팀 프로젝트

목록 보기
20/34
post-thumbnail

오늘은 마지막 점검이 있던 날이였다.

점검에서 다양한 이야기를 들었는데 그렇게 말을 하는건 이해가 되는데
중요한게 너무 얄팍하게 가르쳐주고 이 짧은 시간내로 소화해야한다는 식으로
느낌을 받아서 이해가 가질 않았다.

플레이그라운드는 30% 유닛 테스트를 하면 50% TDD는 80%

세상에 완벽한 코드는 없으니 TDD를 하면서 진행한 코드의 완성도는 80%
유닛 테스트라도 진행을 한 코드의 완성도는 50%
플레이그라운드 상에서만 진행을 한 코드의 완성도는 30%라는 이야기를 들었다.

이 말은 나도 이해를 할 수 있는데, 테스트 코드도 못짜고 이것밖에 못하냐 라는 어투로 이야기를 해서 당황스러웠다.

테스트는 정말 중요하다고 나도 당연히 생각한다, 왜냐하면 결제로직이 아니더라도 사용자에게 불쾌한 경험을 느낀다면 사용자의 이탈로 이어질 수 있기 때문에 오류를 최대한 잡아야한다.

근데 우리는 테스트에 관한 수업을 고작 3시간을 받았고 그마저도 간이 유닛 테스트를 만들어서 수업에서 사용했다.

테스트를 해보려고 한다면 물론 할 수 있을 것이다, 공부도 추가적으로 해서 도입도 할 수 있는데.....
20일 가량의 프로젝트 기간중에 TDD는 당연 무리일 것이고,
유닛 테스트마저도 약식만 해도 제법 분량이 많은데

팀플을 진행하는 모든 팀이 테스트코드를 짜지 못했는데 본인들의 커리큘럼을 부정을 하는 것인지는 모르겠으나 스트레스를 엄청 심하게 받았다.

분산 트랜잭션

이것은 추가적인 피드백으로 받은 내용인데, 어디서 들었는지 깜빡했는데;

분산 트랜잭션을 적용하면 DB의 부하를 확 줄일 수 있다면서 넌지시 던져줬는데
그..... 도대체 무엇을 원하는지 정말 모르겠다.

물론 좋다는 것도 알고 어떤 작용이 이루어지는지 예측이 되는 단어지만
MSA에서 상당히 도입할 수 있고 말 그대로 레벨업에 필요한 것들이라서

어떻게 보면 막연하게 기분이 나쁘기도 하는데 그만큼 능력이 있는 사람이 하는 조언이고
또 틀린 말은 하나도 없기 때문에 찾아보고 배워서 다 적용을 해야겠다는 생각이 들었다.

이게 내 성장의 원동력이 된다는 것이 확 느껴지는 하루였다고 생각했다.

누군가 찍어누르면 아, 내가 더 노력해서 저 사람한테 가르쳐주는 날이 올 때까지 죽자사자 노력한다. 라는 마인드가 배움의 길에 있어서 참 도움이 많이 되는 것 같다, 이러다보면 가끔 술도 마시곤 하지만.

이미지 업로드 최적화

이미지업로드에 대한 이야기도 듣게 되었는데,
내가 생각하는 것이 맞는지 한번 더 물어봤어야 했는데 시간이 끝나서 나왔다.

현재 우리 팀 프로젝트에서 진행되는 이미지 업로드의 구조다.

  1. 클라이언트가 파일 업로드를 한다.
  2. 백엔드 서버의 api를 작동시켜 클라이언트가 업로드한 file을 google storage에 넣은 후 signed_url을 리턴해준다.
  3. 프론트는 그 signed_url을 바탕으로 유저가 작성하는 게시글에 뿌려준다.
  4. 유저가 게시글을 작성할 경우 해당하는 signed_url이 게시글과 join되어 image DB에 저장된다.

이렇게 4개의 구조로 진행이 되고 있다.

이 중 storage 용량의 부하를 줄이기 위하여 .webp라는 확장자로 바꾸는 옵션을 추가해놨는데, 있어보이게 하는 헛짓이라는 이야기를 듣게 됐다.

이게 교육자로써 해도 될 법한 말인지 도대체 뭐인지 기분 나쁘게 하는데엔 뭐가 있는 것 같다.

뭐 아무튼 물론 프론트에서 용량이 큰 파일이라면 커팅하는 것이 기본이라고 생각하고 있었지만
storage의 부하를 줄이기 위하여 저 옵션을 달아놨는데

storage는 생각보다 용량을 채우는게 어렵다며 그런 걱정은 하지 않아도 되고, 조금 더 부하를 줄일 수 있으니 생각을 해보라는 답도 받았다.

내가 생각하는 부하를 줄이는 방법은 아래와 같다.

  1. 클라이언트가 이미지 업로드를 할 경우 임시 URL을 만들어서 그것을 미리보기 형식으로 보여준다.
  2. 클라이언트가 실제로 작성하기 버튼을 누를 경우 그것에 대하여 storage에 이미지가 업로드가 된다.

즉 정말 존재하는 것만 이미지가 storage에 올라가면 된다고 생각하는데, 생각해보면 벨로그도 그렇게 쓰지는 않는 것 같아서 생각을 해봐야할 것 같다랄까.

벨로그도 보면 사진을 올려놓고 글 작성하기를 하지 않아도
다른 컴퓨터에서 해당하는 이미지의 URL로 접근이 가능한 것을 확인할 수 있는데,
일정 시간이 지나도 글에 존재하지 않는다면 삭제하는 형식으로 사용을 하고 있는 것으로 보인다.

크론탭같이 일정 주기로 루프를 돌려서 글에 없는 이미지를 삭제한다던가 그런 작업을 하고 있는 것으로 보이는데, 이 부분에 대해서는 고민을 조금 더 해봐야할 것 같다.


팀장이기에, 더욱 생각을 했어야만 했던 것들

팀프로젝트가 거의 완료가 되어가고, 종료를 앞두고 있는 시점에 왔다.

그리고 PM의 포지션과 팀 리더를 맡은 나는 아쉬운게 너무 많은 포지션의 주인이라고 생각한다.

어떤 것이 아쉬웠냐면, 스케쥴 부분에서 조금 더 명확한 가이드라인을 주지 않은 것에 대하여 내 자신에게 너무 멍청했다고 생각하고 있다.

매일매일 이런식으로 자기가 해야하는 작업에 대한 정확한 가이드가 존재했다면
매일 아침마다 회의를 진행해서 지라, 깃허브에 작업 진행에 대하여 조금 더 밀도있게 문서화를 했더라면 이런 일이 벌어지지 않았을 것이라고 생각을 하고 있다.

리더가 모든 것을 할 수 없겠지만, 최대한 많은 부분에서의 조율자 역할을 해줬어야 했는데

이제라도 생각해서 다행인건지, 경험을 해보고 나서야 알게 되어서 멍청한 것인지
사람마다 바라보는 관점은 다르겠지만, 나는 후자라고 생각한다.

조금 더 깊게 생각하고, 한번만 더 바닥을 두드리고 나아갔다면 더 좋은 결과물을 낼 수 있었을텐데
그것이 너무 아쉽고, 만약 현재 팀원들과 사이드 프로젝트가 진행된다면 그것에 조금 더 고려를 해볼 것이다.

물론, 지금 프로젝트 또한 최대한 완벽하게, 완성도 높게 끝낼 것이다.

6일만 더 힘내자 우리팀원들

profile
물류 서비스 Backend Software Developer

0개의 댓글