Day 89. Final 최종 발표회까지 마친 하루

너무 귀엽지 않아요? ><

우리 프론트엔드 두 분이서 일일히 한 땀 한 땀 장인정신으로 빚어낸 우리 3조 부스 !!!! 진짜 내 기준 제일 예쁘고 우리 프로젝트 컨셉이랑도 딱 맞았다. 

 

최종 발표회가 있었던 오늘, 게더에 축제의 장이 열렸다. 새벽까지 테스트코드를 열심히 짠 덕에 커버리지는 82%를 달성한 기쁨과 함께 하루를 즐기게 되었다.

 

그 와중에 발표 후 멘토님이 피드백 해주신 내용을 빠짐없이 정리하려고 노력했고, 또 우리 부스로 따로 찾아와주신 분들의 질의응답도 기록해두었다. 나중에 면접 대비한다고 생각하고..

 

- 최종발표 피드백

우리가 SSE 기능 개선을 위해 Spring Web Flux까지 도전해보았다고 적었는데, 이는 초가집에 불이 났는데 헬기로 불을 끄려고 시도하는 것과 같다고 하셨다. 단순히 Emitter의 유효하지 않는 커넥션만 끊어주면 해결될 일이라서 해결 방법을 잡는 포인트가 아쉽다고 하셨다. 커넥션 풀을 점거하지 않도록 코드를 구현해야하니 중간에 쓰레드 풀을 만들어서 emitter가 가장 많이 생겼을 때 갯수를 측정하고 그 갯수 만큼 풀이 만들어지도록 구성을 하라고 하셨다. 그러니까 이것 저것 도입해보려고 하지말고 기본적으로 코드를 다시 뜯어보는 것을 추천하셨다. 

왜 그것을 놓치고 있었을까.. 코드에 문제가 있으니 오류가 생기는 것이었을텐데, 그러면 당연히 코드를 뜯어보는게 우선이되었어야지...!! 😩 

그리고 우리가 제공하고 있는 코드에디터 기능을 그냥 단순히 에디터에서 멈추지말고 페어프로그래밍이 가능하도록 추가했다면 진짜 실제로 회사에서 써도 될 만한 프로젝트라고 말씀해주셨다.  

 

 

- 실무에서도 포트가 겹치는 경우가 많이 생긴다.

우리는 단순히 인스턴스를 구분해주는 것으로 해결을 봤는데, 리버스 프록시를 좀 더 공부하고 포트 겹침 문제를 해결해봤으면 하는 아쉬움이 있었다.. 프록시 서버에 대해 공부했다고 생각했는데 좀 더 봐야겠다는 생각을 함.

 

- sse 기능에 대한 질문

웹 소켓도 사용하고 redis pub/sub도 사용하는데 다른 방법으로 시도한 이유? 에 대해서도 공통적으로 많이 물어보셨다. 진짜 SSE 기능에 대해서는 아쉬움이 너무 많다. 직접 담당하지 않아서 로직 흐름도 사실 이해가 100% 되지 않은 상황이라 이런 질문이 들어올 때 제대로 답을 할 수 없었다. 이제 이력서도 쓰고 취업 준비를 해야하니까 하면서 SSE 로직을 좀 더 파봐야겠다는 생각뿐...

 

- 모니터링의 중요성

지금 에러로그를 따로 관리하고 있지 않아서 모니터링을 어떻게 하고 있냐는 질문도 받았다. 사실 sentry를 적용해보려고 하긴 했는데 작업 막바지에 생각했던 부분이라 이제 와서 무슨 소용이냐.. 라는 생각이 가장 많긴 했었다ㅠ 에러로그를 따로 관리해야하는 이유를 알고 있지만 그 때 당시 더 중요한 일이 많았어서 뒤로, 또 뒤로 밀린 것이라고 말할 수 밖에 ㅠㅠ

 

- 테스트코드

어떤 회사의 경우 테스트코드가 없으면 보지도 않는다고 하시더라. 그런 면에서는 우리가 테스트코드를 열심히 쓴게 헛되지 않았구나.. 라는 생각을 했다.

 

 

이렇게 질문을 직접적으로 받아보니 아쉬운 점이 더 많이 보인 프로젝트였다. 앞으로 기간동안 조금 더 개선하기 위해 보완하고 내가 스스로 이해해야할 부분이 다 숙제로 남은 기분이다. 더 바빠질 것 같긴 한데 오늘은 드디어 최종 발표회를 마쳤으니 조금 쉬어보..는것도 나쁘지 않...ㅎㅎㅎ