이번 주는 밀리지 않고 WIL을 쓰겠노라 다짐했건만... 또 실패해버렸다. 아직 새벽이니까 세이프한거라도 보면 안될까? 😩
하지만 이미 일요일은 끝났고 ㅠ 결국 월요일에 WIL을 작성하게 되었다.
이번 주는 드디어 MVP를 만들어서 발표할 수 있었다.
그 동안 막힌 부분도 많았지만, 게임 로직을 구현하는 쪽을 같이 작업하면서 websocket 흐름이 약간은 이해되었다.
MVP 발표를 하면서 느낀건 내가 얼마나 내가 지금 만들고 있는 프로덕트에 대한 기술 이해도가 낮은지였다.
🔥 기술적 의사 결정은 신중히!
지금까지 항해에서 나눠준 자료에 있는 방식이나 구글링했을 때 남들이 사용하는 방식으로만 코드를 짜고는 했었다.
왜 이런 방식으로 코드를 작성하는지, 어떤 이점이 있는지, 또 어떤 상황에 이런 방식이 효율적인지는 생각하지 않고 일단 기능을 구현하는 것에 집중했었는데, 초반에는 그래도 괜찮았다고 생각한다.
아직 잘 모르기 때문에 다른 사람들의 코드를 보면서 구현 먼저 해보는 방식은 나쁘지 않았다고 생각하지만, 이제 조금씩 기능을 구현하는 것 자체에 익숙해지면, 내가 하는 일에 이유와 목적을 더 명확히 해야하는 것이다.
다만 실전 프로젝트에서도 지속적으로 생각없이 기능 구현에만 집중을 했었는데, MVP 발표 때 시니어 개발자분께 들은 피드백은 사용한 기술 스택에 대한 이해도가 낮다는 말이었다 ㅠㅠ
사실 이해도가 낮은건 당연한 말이지만, 적어도 내가 한 행동에 대한 설득력이 전혀 없어보일 정도로 나는 생각없이 코드를 작성하고 있었다.
당연히 지금은 다양하게 알 수 없으니 적어도 내가 사용할 수 있는 기술 스택에 대해서 무엇인지 아는것 외에도 왜 사용하는지도 깊게 생각해봐야겠다.
🔥 WebRTC 더 이해하기
이번 프로젝트에서 또 추가로 알게된 것이 있다면 WebRTC라는 것이다. 나만 모른닭 프로젝트가 게임이다보니 음성/영상 채팅을 할 수 있도록 구현해야 했는데, 해당 기능을 구현하기 위해선 WebRTC를 사용해야했다.
직접적으로 코드를 작성하진 않았지만, 다른 조원분이 작성한 코드를 하나하나 읽어보며 대충 데이터의 흐름은 파악했었다.
하지만 아직도 이해가 잘 되지 않았는데, 조만간 WebRTC에 대해 공부하고 포스팅을 하도록 해야겠다.
그래도 핵심적인(?) 개념 중 이해한 것은, 서버 없이 클라이언트(사용자)간의 Peer to peer 연결을 맺어서 서버를 거치는 방식보다 더 빠르고 실시간성이 보장된다는 것이다. 또한 HTTPS 연결이 강제적으로 적용되어서 훨씬 더 안전하다고한다.
아직까진 WebRTC가 뭔지, 어디에 쓰이는지 정도만 알고있는데, 추가로 알아야할 개념이 너무 많다.
Turn, Stun, NAT, ICE Candidate 등 진심 뭔지 모를 용어들이 나오는데, 꼭 공부해둬야겠다.
직접적으로 구현하지 않았어도 내가 참여한 프로젝트의 핵심 기능인데 몰라서는 안되니까!!! 그리고 나중에 써먹어보고싶으니까!!!
꼭 정리해둬야지!
🔥 배포는 어떻게 해야할까?
HTTPS 배포를 위해서 CloudFront를 사용했는데, 한번 배포했더니 새로 업데이트가 안되는 이슈가 있었다.
구글링을 해보니 캐싱의 의해 이전 버전이 계속 운영되는 것이었는데, 캐시 무효화를 해도 계속해서 502 error 페이지만 나타났었다.
계속 구글링을 해봤지만... 애초에 왜 그렇게 되는지 이해를 못 했고, 배포 문제에만 매달리기엔 너무 정신이 없어서 일단 그냥 EC2로 배포를 해버렸다. 그랬더니 아니나 다를까... 멘토님의 질문이 CloudFront로 배포된 파일들이 캐싱에 의해 이전 버전만 서비스되는 문제점을 어떻게 해결했는지였다.
CloudFront에 대해 이해하고 문제를 해결했다고 말 하고 싶었지만...! 사실 충분히 파고들지 못 하고 다른 방식으로 돌려버려서 문제를 회피한것 같은 기분이 들었다.
CloudFront에 대해 추후 더 공부하고 정확한 사용법을 알아보겠다고 했지만 솔직히 너무 정신이 없어서 그럴 수 있을지 의문이다.
그래도 배포 관련해서 팁을 하나 얻었는데, 배포할 때 npx 명령어를 사용하면 코드가 경량화된다는 것이다.
npm insatll -g serve
npx serve -s buildnpx의 경우 한 번만 실행시킬 서버를 다운로드 하는 것이고, serve라는 웹서버를 다운받아서 실행 시킬 때, build를 root로 하겠다는 의미라고 한다.
리액트 전체를 다 서버로 돌리는 것이 아니라 build를 통해 용량을 줄여서 배포하면 유저 입장에서는 더 가벼운 웹앱을 이용할 수 있다니 다음에 빌드할 땐 npx를 이용해서 빌드를 해봐야겠다.
MVP를 발표하는 자리였지만, 사실 기능이 안정적으로 구현되지 않아서 멘토님이 우리의 프로덕트를 제대로 확인하시지 못 하셨다고 한다. 많은 기능을 개발하고 좋은 디자인을 입히는 것도 중요하지만, mvp라는 것에 더 집중해서 개발된 기능이 원활하게 돌아가는 것에 초점을 둬야겠다.
MVP를 배포하는 것도 어쨌든 production release인데, 배포를 하기 전에 개발된 내용이 충분히 반영되었는지 확인하고, 배포 이후에도 서비스가 원활하게 돌아가는지 한번 더 확인을 해야한다.
기획자였을땐 당연하게 하던 그 workflow가 왜 개발을 하니까 고려가 안됐던걸까?
솔직히 부족한 실력으로 기능을 구현하는 것에 급급해서 전체적인 그림을 보지 못 한것이 가장 큰 원인이라고 생각한다. 그래도 기능 구현이 전부가 아니기 때문에, 조금 더 넓은 시야에서 프로젝트를 바라볼 수 있는 눈을 다시 키워야겠다.
