2022.3.2nd

지난 주에 연구한것들을 토대로 우리 어플리케이션에 WebRTC를 붙이는 작업을 했다.

통신에 있어 우리 어플리케이션의 구조는 오직 socket 통신만을 전담하는, node로 작성한 signalling server와 메인 기능을 수행하는 spring server, 이렇게 두개의 서버가 있고 react로 개발한 클라이언트가 두 서버가 송수신하는 정보를 양 쪽에 전달하는 교두보 역할을 맡게되는 구조이다.

클라이언트의 상태에 따라 socket에 알맞은 behavior를 가져야 했고, 또 거기에 맞춰 spring 서버에 정보를 보내주도록 개발했는데 굉장히 까다로웠다.

이번주 금요일까진 node의 response 시점이 명확하지 않았고, 그로인해 react의 동작 순서를 예측할 수가 없어서 많이 헤멨었다. spring은 spring대로 부분부분 고장난 API가 더 헷갈리게 만들었었고..

하지만 이번 프로젝트에선 node server를 내 로컬환경에서 돌리면서 서버와 클라이언트 양 쪽의 로그를 확인하며 개발했기에 클라이언트 개발자인 내가 통신 시점을 정확하게 인지하게 됐고, 그에 맞춰 react코드를 다시 짬으로서 통신의 핵심적인 부분들은 완전히 정리된 상황이다.

redux를 사용해 클라이언트가 어떤 상태인지를 관리하면 어떨까 하는 아이디어가 많이 도움이 됐다.

이번주에 느낀점이 있다.

눈 감은채로 바둑을 둬서 이기는 사람은 없다는 것이다.

코드에 휩싸여서 정신없이 두드리는건 쉽고 익숙한 일을 할 때나, 개발이 잘 풀릴때나 할 수 있는 행동이고, 문제가 생긴다면 바로 문제가 발생했음을 의식적으로 자기자신에게 주지시키고, 멀리서 정확하고 냉정한 시야로 프로젝트 전체를, 파트 전체를, 파일 전체를 조망해야 한다는걸 깨달았다.

나에게도 개발모드랑 디버그모드가 필요하다는 말이다.

문제가 있을 때 마음 급해져서 생각없이 키보드를 두드리는건 절대로 문제를 해결해주지 않고 상황을 더 더 더 나쁘게 만들뿐이다.

관조하는것을 즐기는 성향은 프로그래밍에 있어 내가 가진 몇 안되는 장점이다. 나는 이걸 사용해 언제나 문제를 해결해낼것이다.

잊지말자.

동시에 트러블 슈팅을 작성하는 것에 대한 효능도 다시 한 번 깨달았다.

글로 적는것은 오염된 시야를 초기화하는데 커다란 도움을 준다.

앞으로 문제가 생기면 키보드에서 손 떼고, 쇼파에 앉아서 핸드폰 메모장을 켜야지!