FEConf 참석!
아주 운이 좋게 FEConf의 티켓을 얻게 되었다.
풍문으로는 20초만에 티켓팅이 끝났다고 알고 있다.
그래서 감사한 마음으로 프론트엔드도 공부할 겸 참석했다.
들었던 세션 중에 인상 깊었던 내용들을 정리해본다.
SSR 환경(Node.js) 메모리 누수 디버깅 가이드
간략한 정리
개인적으로 위의 세션을 듣고 정리해본 프로파일의 흐름이다.
- Metrics
- 보고자 하는 메트릭을 먼저 정한다. (메모리 누수 같은 경우에는 당연히 메모리를 메트릭으로서 관찰한다.)
- 해당 메트릭을 이용하여 마치 KPI와 같은 것들을 계산할 수 있다.
- 이 세션에서는 Retained Size와 Shallow Size를 나눈 값을 사용했다.
- 즉, 특정 객체의 1 메모리 당 얼만큼의 의존성 메모리가 있는 지 확인하기 위한 용도이다.
- Code / Platform
- 메트릭은 코드와 플랫폼으로부터 영향 받을 수 있다.
- 메모리 메트릭을 개선하기 위해서 전역 변수(코드)를 지우거나, GC 알고리즘(플랫폼)을 변경할 수 있다.
- Chart & Tool & Phenomenon
- 메트릭은 모니터링 툴을 이용해서 시각화 할 수 있다.
- 이 시각화된 데이터를 바탕으로 특정 현상을 해석하고, 메트릭 개선의 여지를 파악할 수 있다.
- 이 세션에서는 시간별 메모리 할당 그래프가 산 모양인 경우에 OOM(현상)이 발생했다고 판단하고, 메모리 메트릭을 개선하고자 했다. 왜냐하면, 메모리가 계속 커지다가 한계에 도달하는 경우에 운영체제가 해당 프로세스를 죽이기 때문이다.
느낀 점
소프트웨어의 본질은 알고리즘과 자료구조에 있다
누구나 소프트웨어는 알고리즘과 자료구조에 근간을 두고 있음을 알고 있고 당연하게 여길 것이다. 그런데 이 사실이 내게 조금 다르게 다가온 것은, 막상 실제로 그것을 보게 되니 신기했고 더 확실히 체감됐기 때문이다.
자바 백엔드는 메모리 상에서 객체를 그래프 자료구조를 통해 저장하고, Mark & Sweep이란 알고리즘을 통해 가비지 컬렉션을 한다. 그런데 이는 프론트엔드에서도 동일하게 적용될 수 있고, 로보틱스 분야에서도 동일하게 적용될 수 있다. 나는 이런 공통점을 인턴 생활을 하면서도 느꼈고, 이번 컨퍼런스에서 다시금 느끼게 됐다.
즉 하나의 분야에서 자료구조와 알고리즘이 사용되는 방식을 깊게 알고 있다면 어떤 분야에서든지 나는 적응할 수 있고, 새로운 기술을 큰 노력 없이 이해할 수 있게 되는 것이다. 새삼스럽지만 너무나 매력적인 일이 아닌가? 그래서 난 실제 사용되는 프로덕트 내부에서 자료구조와 알고리즘을 배워나가는 것이 매우 중요한 일이라 생각하게 됐다.
KPI가 KPI가 되기 위해 필요한 것
난 세션에서 정의한 'retained size/shallow size'이 공식이 정말 아름답게 느껴졌다. 이는 객체의 1 메모리 당 얼마만큼의 종속적인 메모리가 존재하는지 계산하는 식이다. 원하고자 하는 데이터를 정말 정확하게 묘사해낸 공식이라 생각이 들었다.
나 또한 요즘 KPI 업무를 하고 있는데, KPI가 KPI가 되기 위해선 위의 공식처럼 원하고자 하는 현상을 정확히 짚어내야 함을 다시금 느낄 수 있었다. 그리고 이는 마치 수학과 세상의 관계와 닮아 있다고 느꼈다. 수학은 실제 세계를 모방할 수 있지만, 오히려 반대로 수학 세계에만 존재하던 것이 실제 세계에 영향을 끼칠 수도 있다. 이처럼 좋은 KPI란 세상에 없었던 새로운 통찰을 줄 수 있는 공식이어야 한다.
몇 천 페이지의 유저 가이드를 새로 만들며
느낀 점
어떻게든 문제를 해결하는 것이 중요하다
이 세션에서 가장 놀란 점은 정말 신기한 방법으로 문제를 해결했다는 점이다. 여기서 발생했던 문제점은 리액트 코드로 페이지를 퍼블리싱 할 때 리액트가 html 최신 기능을 지원하지 않아서 원하는 요구사항을 구현하지 못한 것이었다. 만약에 나라면, 리액트단에서 어떻게든 문제를 해결하고자 했을 것이다. 예를 들어, 리액트 라이브러리를 요구사항에 맞게 수정할 수 있는 방법을 찾는다든지 말이다.
그런데 발표자는 html이 대소문자를 구분하지 않는다는 사실과 ReactDOM은 정의된 소문자로 시작하는 속성에만 관여한다는 사실을 이용해서 문제를 우회했다. 어떻게 보면 근본적인 문제 해결 방법은 아니라 생각한다. 왜냐하면 만약 리액트가 해당 기능을 지원하게 된다면 사용하지 않을 방법이기 때문이다. 그런데도 난 이런 접근 방식이 좋았던 이유는 결국 시간 내에 문제를 해결했기 때문이다.
회사에서 일을 하다보면, 정석적으로 문제를 해결하려고 노력하다가 시간을 허비하는 경우가 종종 있었다. 즉 좀 더 멋진, 좀 더 어려운 방법으로 문제를 풀려다가 시간을 허비했던 것이다. 처음에는 그것이 내 능력을 입증할 수 있는 기회라고 생각했었다. 그런데 오히려 중요한 것은 어떻게든 시간 내에 문제를 해결하는 것이었다. 비록 너무나 간단하고 쉬운 방법일지라도 말이다. 물론 세션에서 보여준 방식이 쉽다고 하는 것은 아니지만 다시금 내게 어떻게든 문제를 시간 내에 풀어내야 한다는 정신을 일깨워주었다.
