<div id="readability-page-1" class="page"><div><p>2019년부터 반기마다 회고를 블로그에 써보고 있는데 그래도 쌓이니까 꽤 재미가 있다.</p>
<h2 id="회사일-이야기"><a href="#%ED%9A%8C%EC%82%AC%EC%9D%BC-%EC%9D%B4%EC%95%BC%EA%B8%B0" aria-label="회사일 이야기 permalink"></a>회사일 이야기</h2>
<p>올해 3Q 까지는 JSP 페이지를 걷어내는 일을 주로 했었는데 나머지 기간에는 그거 오픈하고 성능 개선한다고 시간을 좀 썼었다.</p>
<p>오픈하기 전에는 IE 10+ 지원하느라고 좀 시간을 많이 썼다. 사실 이런 류의 작업은 오픈하는 타이밍에 누군가 한두명이 고생해서 호환성을 맞춰놓으면 신규 피처 넣을 때는 그게 깨질 일이 잘 없어서 그냥 쭉 호환성이 유지되는 경우가 대부분이다. 내가 그 한 두명이 될 것이냐 말 것이냐가 문제인데 이게 어드민 툴 개발에서는 느낄 수 없는, 사용자 대상 프로젝트에서만 느낄 수 있는 일이라고 생각해서 이번에는 그 한두명이 되보았고, 다행히 polyfill 잘 넣고 메소드를 주의해서 쓰면 되는 일이 대부분이라서 엄청 고생스럽지는 않았다 (물론 이건 내가 사용하는 프레임워크의 지원 범위 이내에서 호환성을 맞출 때의 이야기고 그걸 넘어서려면 아예 얘기가 달라진다).</p>
<p>성능 관해서는 처음에는 JSP 로 그린 페이지보다 React로 SSR 한 페이지에서 성능 지표가 더 안 좋아서 약간 멘붕을 했었는데 지금와서 생각해보면 애초에 브라우저에서 할 일이 많아지니까 당연한 것 같기도 하다 (html 파싱해서 렌더하면 끝나는거랑, props 가지고 다시 렌더해보고 hydration 하는거랑 비교하는거니까). 마찬가지로, JSP로 렌더한 페이지에 비해서 Redux + React로 SSR 페이지에는 initialState가 serialize되서 html 어딘가에 박혀있으니 당연히 용량이 더 클 수 밖에 없다. 물론 그 이후에 상태 조작할 때는 비교할 수 없는  편의성의 차이가 있지만…단순 성능관점에서는 plain html 보다 빠를 수가 없다는 사실을 최근 들어서야 깨달았다. React를 계속 쓸거면 결국 불필요한 렌더와 다운로드를 줄이는 수 밖에 없고 (ssr을 꼭 필요한 부분에만 한다던가 - 아니면 이 포스팅을 쓰면서 <a href="https://twitter.com/zxzl/status/1343213753253302272" target="_blank" rel="nofollow noopener noreferrer">깨달았는데</a> hydration만 미뤄도 된다), React를 계속 안쓰면 좀 더 html에 가까운 접근들 (예를 들면 <a href="hotwire.dev">hotwire</a> - 개인적으로는 이게 <code>$.html()</code>이랑 뭐가 다른지 잘 모르겠다)를 파보는 것도 좋을 것 같다.</p>
<p>페이지 개발과 별개로 최근에는 서비스에 필요한 데이터를 비정규화된 형태로 만들어서 쓰는 작업도 요새 많이 고민중이다 (BFF 처럼 Database For Frontend 라고 생각하면 개념이 딱 맞다). 원래 우리 조직은 엄청 빵빵한 오라클 디비를 백엔드랑 프론트엔드 서비스가 같이 바라보는 형태였는데 올해는 이걸 걷어내는 형태로 백엔드 분들이 고생을 많이 해주셨다 (참조: <a href="https://deview.kr/2020/sessions/384" target="_blank" rel="nofollow noopener noreferrer">DEVIEW 2020 :: Bye Oracle, Hello PG: 쇼핑검색플랫폼, MSA로 새옷을 갈아입다.</a>). 사실 그래서 새 플랫폼에서 나오는 스냅샷과 CDC 스트림을 가지고 적절한 형태로 데이터를 만들어서 서비스에서 쓰기만 하면 된다. 안되는 일이라기보다는 하면 되는 일인데 최대한 개발자가 개입할 일이 적고 요구사항이 바뀌어도 맞추기 대응이 편한 무엇일까가 고민이 많다가… 결국 옵션들을 늘어놓고 하나씩 해보는 수밖에 없다는 결론에 이르러서 요새 이것저것 해보는 중이다.</p>
<p>이런 류의 작업에서는 전체적인 그림을 그리는 작업도 중요하고, 그 그림대로 구현을 해보면서 기존 컴포넌트를 대체해서 조심스럽게 조금씩 새 컴포넌트를 끼워넣는 것도 중요하다고 생각한다. 결국 후자를 많이 해본 사람만이 전자를 잘 할 수 밖에 없고, 나는 전자/후자 다 경험이 적기 때문에 일단 뭐라도 해보면서 교훈을 얻는 수 밖에 없다.</p>
<h2 id="개인-공부-이야기"><a href="#%EA%B0%9C%EC%9D%B8-%EA%B3%B5%EB%B6%80-%EC%9D%B4%EC%95%BC%EA%B8%B0" aria-label="개인 공부 이야기 permalink"></a>개인 공부 이야기</h2>
<p><a href="https://blog.shik.kr/2020-two-thirds/" target="_blank" rel="nofollow noopener noreferrer">2020년 2/3 회고</a>에서 리트코드를 많이 못풀어서 아쉽다고 썼었는데 그 때부터는 리트코드를 좀 신경써서 풀어서 이제는 어쨌든 미디움까지는 꽤 수월하게 푸는 것 같다. 확실히 도구/프레임워크 공부를 하는 것 보다는 진척도가 눈에 딱 보여서 스스로 생산적이라고 느끼기 쉬운 것은 좋았는데 여전히 하드만 보면 정신을 못차려서 (ㅜㅜ) 어떤 방식으로 수련을 해야 하드도 잘 풀지는 아직도 잘 모르겠다.</p>
<p>미디움까지 내가 효험을 본 방법을 공유해보면</p>
<ol>
<li>주제를 하나 찍는다 (예를 들면 <code>hash</code>)</li>
<li>이지 중에 frequency 초록색인걸 푼다.</li>
<li>미디엄 중에 frequency 초록색, 노란색인걸 다 푼다. 30~40분 봐도 모르겠으면 답을 본다.</li>
</ol>
<p>해서 한 200개 풀면 좀 적응이 되었는데 하드부터는 <code>30~40분 봐도 모르겠으면 답을 본다</code> 에서 답을 보는 비중이 너무 높아져서 쉽게 멘탈이 부서지는게 문제다. 100개 정도 답을 보면 좀 나아질까 싶다.</p>
<p>문제 풀이를 하다보면 다른 공부가 가성비가 떨어지는 것처럼 느껴지고, 책은 더더욱 안 읽게 되서 올해는 책을 많이 읽지는 못했다 (블로그에 가보니 다해야 17권 읽었다 ㅜㅜ (<a href="https://blog.naver.com/library/LibraryView.nhn?blogId=hyungshike&amp;skinType=&amp;skinId=&amp;from=menu" target="_blank" rel="nofollow noopener noreferrer">서재 참고</a>)  저 중에서 한 3개만 꼽으라면</p>
<ul>
<li>세습 중산층 사회</li>
<li>마이크로서비스 패턴</li>
<li>노동의 시대는 끝났다</li>
</ul>
<p>가 기억에 많이 남는다.</p>
<h2 id="개인의-삶"><a href="#%EA%B0%9C%EC%9D%B8%EC%9D%98-%EC%82%B6" aria-label="개인의 삶 permalink"></a>개인의 삶</h2>
<p>원래는 건강에 대해서 체중 / 체력 빼고 별로 신경을 안 썼는데 건강검진에서 이슈가 발견되서 수술을 해야되는 상황이 생기니까…생각보다 건강이 중요하구나하고 많이 느꼈다.  재택근무를 하면 어차피 점심시간이 남으니까 점심시간마다 30분 정도 걷고 있는데 이게 정말 큰 차이를 만드는 것을 느껴서 거의 습관의 일부가 된 것 같다.</p>
<p>요즘은 8시간 근무 기준으로 하루에 2시간 정도는 스스로를 위해 쓰는 습관이 생겼는데… 이것까지 만약 일하는 시간으로 생각하면 개발자라는 직업이 그렇게 숫자로만 따지면 그렇게 워라밸이 좋은 직업은 아니구나 싶다 (좀 잘해져서 생산성이 올라가면 더 적은 시간을 쓰고 같은 일을 할 수 있지 않을까 꿈만 꾸는 중)</p></div></div>

Blog by Hyeungshik Jung

2019년부터 반기마다 회고를 블로그에 써보고 있는데 그래도 쌓이니까 꽤 재미가 있다.
회사일 이야기
올해 3Q 까지는 JSP 페이지를 걷어내는 일을 주로 했었는데 나머지 기간에는 그거 오픈하고 성능 개선한다고 시간을 좀 썼었다.
오픈하기 전에는 IE 10+ 지원하느라고 좀 시간을 많이 썼다. 사실 이런 류의 작업은 오픈하는 타이밍에 누군가 한두명이 고생해서 호환성을 맞춰놓으면 신규 피처 넣을 때는 그게 깨질 일이 잘 없어서 그냥 쭉 호환성이 유지되는 경우가 대부분이다. 내가 그 한 두명이 될 것이냐 말 것이냐가 문제인데 이게 어드민 툴 개발에서는 느낄 수 없는, 사용자 대상 프로젝트에서만 느낄 수 있는 일이라고 생각해서 이번에는 그 한두명이 되보았고, 다행히 polyfill 잘 넣고 메소드를 주의해서 쓰면 되는 일이 대부분이라서 엄청 고생스럽지는 않았다 (물론 이건 내가 사용하는 프레임워크의 지원 범위 이내에서 호환성을 맞출 때의 이야기고 그걸 넘어서려면 아예 얘기가 달라진다).
성능 관해서는 처음에는 JSP 로 그린 페이지보다 React로 SSR 한 페이지에서 성능 지표가 더 안 좋아서 약간 멘붕을 했었는데 지금와서 생각해보면 애초에 브라우저에서 할 일이 많아지니까 당연한 것 같기도 하다 (html 파싱해서 렌더하면 끝나는거랑, props 가지고 다시 렌더해보고 hydration 하는거랑 비교하는거니까). 마찬가지로, JSP로 렌더한 페이지에 비해서 Redux + React로 SSR 페이지에는 initialState가 serialize되서 html 어딘가에 박혀있으니 당연히 용량이 더 클 수 밖에 없다. 물론 그 이후에 상태 조작할 때는 비교할 수 없는  편의성의 차이가 있지만…단순 성능관점에서는 plain html 보다 빠를 수가 없다는 사실을 최근 들어서야 깨달았다. React를 계속 쓸거면 결국 불필요한 렌더와 다운로드를 줄이는 수 밖에 없고 (ssr을 꼭 필요한 부분에만 한다던가 - 아니면 이 포스팅을 쓰면서 깨달았는데 hydration만 미뤄도 된다), React를 계속 안쓰면 좀 더 html에 가까운 접근들 (예를 들면 hotwire - 개인적으로는 이게 $.html()이랑 뭐가 다른지 잘 모르겠다)를 파보는 것도 좋을 것 같다.
페이지 개발과 별개로 최근에는 서비스에 필요한 데이터를 비정규화된 형태로 만들어서 쓰는 작업도 요새 많이 고민중이다 (BFF 처럼 Database For Frontend 라고 생각하면 개념이 딱 맞다). 원래 우리 조직은 엄청 빵빵한 오라클 디비를 백엔드랑 프론트엔드 서비스가 같이 바라보는 형태였는데 올해는 이걸 걷어내는 형태로 백엔드 분들이 고생을 많이 해주셨다 (참조: DEVIEW 2020 :: Bye Oracle, Hello PG: 쇼핑검색플랫폼, MSA로 새옷을 갈아입다.). 사실 그래서 새 플랫폼에서 나오는 스냅샷과 CDC 스트림을 가지고 적절한 형태로 데이터를 만들어서 서비스에서 쓰기만 하면 된다. 안되는 일이라기보다는 하면 되는 일인데 최대한 개발자가 개입할 일이 적고 요구사항이 바뀌어도 맞추기 대응이 편한 무엇일까가 고민이 많다가… 결국 옵션들을 늘어놓고 하나씩 해보는 수밖에 없다는 결론에 이르러서 요새 이것저것 해보는 중이다.
이런 류의 작업에서는 전체적인 그림을 그리는 작업도 중요하고, 그 그림대로 구현을 해보면서 기존 컴포넌트를 대체해서 조심스럽게 조금씩 새 컴포넌트를 끼워넣는 것도 중요하다고 생각한다. 결국 후자를 많이 해본 사람만이 전자를 잘 할 수 밖에 없고, 나는 전자/후자 다 경험이 적기 때문에 일단 뭐라도 해보면서 교훈을 얻는 수 밖에 없다.
개인 공부 이야기
2020년 2/3 회고에서 리트코드를 많이 못풀어서 아쉽다고 썼었는데 그 때부터는 리트코드를 좀 신경써서 풀어서 이제는 어쨌든 미디움까지는 꽤 수월하게 푸는 것 같다. 확실히 도구/프레임워크 공부를 하는 것 보다는 진척도가 눈에 딱 보여서 스스로 생산적이라고 느끼기 쉬운 것은 좋았는데 여전히 하드만 보면 정신을 못차려서 (ㅜㅜ) 어떤 방식으로 수련을 해야 하드도 잘 풀지는 아직도 잘 모르겠다.
미디움까지 내가 효험을 본 방법을 공유해보면
주제를 하나 찍는다 (예를 들면 hash)
이지 중에 frequency 초록색인걸 푼다.
미디엄 중에 frequency 초록색, 노란색인걸 다 푼다. 30~40분 봐도 모르겠으면 답을 본다.
해서 한 200개 풀면 좀 적응이 되었는데 하드부터는 30~40분 봐도 모르겠으면 답을 본다 에서 답을 보는 비중이 너무 높아져서 쉽게 멘탈이 부서지는게 문제다. 100개 정도 답을 보면 좀 나아질까 싶다.
문제 풀이를 하다보면 다른 공부가 가성비가 떨어지는 것처럼 느껴지고, 책은 더더욱 안 읽게 되서 올해는 책을 많이 읽지는 못했다 (블로그에 가보니 다해야 17권 읽었다 ㅜㅜ (서재 참고)  저 중에서 한 3개만 꼽으라면
세습 중산층 사회
마이크로서비스 패턴
노동의 시대는 끝났다
가 기억에 많이 남는다.
개인의 삶
원래는 건강에 대해서 체중 / 체력 빼고 별로 신경을 안 썼는데 건강검진에서 이슈가 발견되서 수술을 해야되는 상황이 생기니까…생각보다 건강이 중요하구나하고 많이 느꼈다.  재택근무를 하면 어차피 점심시간이 남으니까 점심시간마다 30분 정도 걷고 있는데 이게 정말 큰 차이를 만드는 것을 느껴서 거의 습관의 일부가 된 것 같다.
요즘은 8시간 근무 기준으로 하루에 2시간 정도는 스스로를 위해 쓰는 습관이 생겼는데… 이것까지 만약 일하는 시간으로 생각하면 개발자라는 직업이 그렇게 숫자로만 따지면 그렇게 워라밸이 좋은 직업은 아니구나 싶다 (좀 잘해져서 생산성이 올라가면 더 적은 시간을 쓰고 같은 일을 할 수 있지 않을까 꿈만 꾸는 중)

2020년 회고

댓글