2020년 4월 회고

이번 달은 꽤 열심히 보낸 것 같다.

공적

1. Vue Composition API

곧 Vue 3.0이 출시될 예정이며 Composition API는 Vue 3.0의 내장 API이다. 회사에서 Vue를 사용하고 있기 때문에 Composition API에 대한 사전 조사가 필요했다.

Composition API를 사용하면 코드를 유지보수 하기 좋게 관리할 수 있으며, 재사용성 또한 증가하게 된다. 다만 아직 VueRouter나 Vuex 같은 서드파티와 연동하는 것에 대한 방법이 없는 상태다.

나는 Vuex의 Namespace 기능을 적극적으로 이용하고 있는데, Namespace 또한 지원하지 않는다.

Composition API와 this

Composition API에서는 this를 사용할 수 없도록 설계되어 있다. 그런데 Vuex의 경우 Namespace를 정의할 때 this를 사용한다. 그래서 Composition과 Vuex의 Namespace를 같이 사용할 경우 에러가 발생한다.

어쨌든 Composition API에 대한 글 중 제일 도움이 많이 되었던 것은 카카오에 다니는 친구가 작성한 이 글이다.

그리고 이 글을 읽으면서 친구의 포스트이므로 그냥 읽으면서 내 생각을 첨가한(?) PR을 날려도 되는지 물어봤다. 어찌보면 굉장히 무례한 부탁일 수 있었는데, 흔쾌하게 수락해진 친구에게 감사하고 미안했다. 결과적으로 친구도, 나도 만족할 수 있는 경험이 되었으리라 생각한다.

이게 바로 개발의 매력이고, 코드리뷰의 매력임을 느꼈다.

약간 삼천포로 빠졌는데, 어쨌든 중요한 점은 이러한 경험을 통해서 Composition API에 대해 이해할 수 있었다는 것이다. 그런데 우리 팀은 포털서비스를 만들어야 하기 때문에.. IE 호환성을 아예 놓을 수 있는 상황이 아니었다. 그래서 아직은 도입할 시기가 아니라고 결론을 내렸다. 젠장

아쉽지만 사이드 프로젝트에 적용해볼 생각이다.

2. 순정 API 개발

새로운 프로젝트 시작하게 맡게 되면서 처음부터 API를 만들어야 했다. 여태 만들어진 API를 유지보수만 하다가 처음부터 순정 API를 만드는 것이다.

회사에서 관리하고 있는 프로젝트는 대충 다음과 같은 Component를 사용한다.

• Adapter: 다른 API의 데이터를 가져옴
• Repository: DB 연동
• Service: Adapter나 Repository에서 필요한 데이터를 가져옴
• Facade: 각종 Service를 조합하여 필요한 데이터를 정제한다.
• Module: Facade에서 필요한 데이터를 가져온 다음 캐싱처리하여 모듈에 맞는 데이터로 반환
• TemplateFacade: Module을 조합하여 최종 데이터를 생성
• Caching: Service/Module 데이터를 캐싱
• Scheduler: Caching을 주기적으로 실행

이미 설계 가이드가 있기 때문에 잘 구성된 가이드라인대로만 만들면 큰 문제 없이 작동한다. 어쨌든 복습도 되고, 처음부터 만들기고 있기 때문에 즐겁게 임하는 중이다.

3. DynamoDB

앞으로 만들게 될 서비스는 DynamoDB를 사용할 예정이다. 물론 사용해도 큰 무리가 없는 서비스에만!

DynamoDB는 AWS에서 만든 NoSQL인데 앞으로의 서비스는 Node.js를 적극적으로 사용할 예정이기도 하고, NoSQL이 Node.js 같은 Non-blocking 방식과 궁합이 맞다.

non-blocking과 nosql

node와 mysql을 같이 사용할 경우, node의 성능을 최대한 뽑아내긴 힘들다. mysql의 경우 blocking 방식으로 작동하고, node의 경우 non-blocking 방식으로 작동하기 때문에 결국 mysql에 지연이 생기면 node도 똑같이 지연이 생기기 때문이다.

그래서 mysql과 nosql을 같이 사용하는 경우가 많은 것이다. 아니 같이 사용해야 한다. mysql을 사용할꺼면 그냥 spring을 쓰자.

DynamoDB의 경우 indexing이 굉장히 빠른데, Index를 생성할 때 하드카피를 하기 때문이다. 다만, 모든 질의가 전부 비용이기 때문에 설계를 처음부터 정교하게 해야한다. RDB의 경우 Entity와 Relation이 중요하지만(당연하게도...) DynamoDB의 경우 Query가 중요하다. 그래서 일단 RDB로 Entity를 설계하고, Relation을 설계한 다음, 이에 따른 Query를 만들어야한다. 그 후에 Query를 보고 필요한 Index를 설계한 다음에 DynamoDB의 Table을 설계한다.

어찌보면 당여한 과정이지만, 설계가 조금이라도 빗나가면 그 여파가 꽤 큰편이다.. 아직은 공부중이기 때문에 조금 더 정리가 되면 TIL에 올릴 생각이다.

4. 재택근무 종료

사회적 거리두기가 해제됨에 따라 재택근무도 종료되었다. 다만 출근 하자마자 다시 사회적거리두기 연장이 되었다는점 (이런 그랜드캐니언 같은 경우가!) 어쨌든 팀원들을 오랜만에 만나니 반갑기도 하고, 일하는 맛이 났다.

그런데 업무에 대한 질은 회사나 집이나 똑같은 것 같다. 주말 출근할 일이 있으면 그냥 집에서 했으면.. 하는 바람이 있다.

5. 총선

이번 달에는 총선이 있었다. 우리 회사는 포털서비스를 제공하기 때문에 이러한 국가적인 이벤트에 민감하다. 내가 담당하는 서비스 또한 그랬기 때문에 여러모로 신경을 많이 써야 했다. 결과적으론 아무일도 일어나지 않았다. 무슨 일이 터져 봐야 경험이 되긴 할텐데..

어쨌든 다행이다!

사적

1. Server Side Rendering

진짜 SSR 때문에 한 동안 고생을 너무 많이 했다. Vue에서 제공하는 가이드라인이 너무 빈약하고, API 문서도 잘못 되었거나 반영되지 않은 것들이 많았다.

SSR과 CSR을 같이 하기 위한 가이드라인이 없다.

일단 첫 번째로 화나는 점은, SSR에 대한 가이드라인은 있는데 CSR을 같이 사용하는 방법에 대한 가이드라인은 없다. 어쨌든 SSR에 CSR을 연동하기 위해선 다음과 같은 과정이 필요하다.

1. CSR의 Template에 SSR의 Template을 합쳐야 한다.
2. CSR 코드를 번들링(빌드) 한다. 이 때 Template도 Bundling 코드에 포함된다.
3. CSR에서 Build된 Template를 SSR에서 사용한다.

이에 대한 안내는 정말 1도 없다는 점... 이와 관련 내용도 5월달에 정리해서 올릴 예정이다.

window와 document를 사용하는 코드들

SSR은 기본적으로 CSR의 코드를 Server에서 실행한 다음 Client로 전달하는 것이다. 이 때 발생하는 문제가 바로 window와 document는 Server Side에서 사용할 수 없다는 것이다. 그래서 직접 window와 document를 만들어주거나, 혹은 Render와 관련된 코드에는 window와 document를 사용하지 않는 것이다. 그런데 이게 말이 쉽지 직접 해보면 욕나온다.

어떤 방법이 제일 좋을까 고민하다가 찾아난 해결책이 JSDOM을 사용하는 것이다.

JSDOM

JSDOM은 말 그대로 가상의 window와 document를 만들어주는 것이다. 그냥 존재 자체만으로도 그 가치가 있다.

SSR을 실행할 때 JSDOM을 만들어주고, SSR 실행이 끝나면 JSDOM을 제거하는 것이다. 이렇게 또 한 문제를 해결할 수 있었다. (Funcking SSR!)

제대로된 Tutorial을 찾을 수 없다.

SSR의 가장 큰 문제점 중 하나가 바로 제대로된 튜토리얼이 없다는 것이다. github를 찾아봐도, 구글링을 해봐도, 이것만 보면 이해할 수 있다 싶은 튜토리얼은 존재하지 않았다. 혹은, 누군가 올렸는데 검색 순위에서 밀려났거나.

2. 오픈소스 기여 시도

Vue SSR을 작업하면서 약간의 문제가 있는 것을 발견하고 PR을 올렸으나, 받아들여지진 않은 것 같다. 일단 e2e test를 통과하지 못했는데.. 에초에 건드린 코드가 e2e Test와 관련이 없었기 때문에 그냥 그러려니 하고 방치중이다.

이 때를 계기로 PR을 적극적으로 사용중이다.

3. 알고리즘 스터디

여자친구가 학교 후배들을 대상으로 알고리즘 스터디를 만들고 진행하고 있다. 그리고 나는 멘토(?)로 참여중이다.

그러면서 깃허브 활동량이 눈에 띄게 늘었다. PR 사용량도 늘어나고 있고, 무엇보다 구성원이 눈에 띄게 성장하고 있는 모습을 보이고 있기 때문에 큰 보람을 느끼는 중이다.

스터디를 하면서 느낀점은, 일단 다른 사람들의 생각을 직접적이든 간접적이든 어떤 형태로든 알 수 있다는 것 자체가 큰 도움이 된다는 것이다. 사고방식이나 문제풀이 과정 등 정말 기상천외(?)한 방법으로 문제를 해결한다.

그리고 알려주는 것들을 스폰지처럼 잘 흡수하는 사람이 있기 때문에 가르침에 대한 보람과 즐거움도 느낄 수 있다.

4. 스파르타 코딩클럽 멘토 신청

페이스북/코덕 등에서 광고를 보다가 우연히 스파르타 코딩클럽을 알게 되었다. 그리고 멘토를 수시로 구하는 중이었기 때문에 바로 신청했다. 몇 년동안 고등학교에서 강의를 하다가 요즘에 강의를 하지 않고 있으니까 허전함이 느껴진다. 무엇보다 부수입이 필요하다.

그래서 부디 꼭.. 합격하기를 바라는 중이다.

5. 일일커밋과 코덕

이번 달은 역대급으로 커밋을 많이 했다.

그냥 정신 차려보니까 그렇게 되어있었다. 그래서 코덕 순위도 2위까지 올렸는데... 1위와의 격차는 별짓을 다 해도 좁혀지지가 않았다. 무엇보다 하루 활동량에 대한 점수 제한이 있었기 때문에 꾸준히 활동을 하지 않으면 결국 따라잡을 수 없는 구조다. 즉, 성실성을 겨루는 서비스라고 할 수 있다. 아쉽지만 이렇게 많은 사람들 중에 두 번째로 성실하게 공부한 것이라는 증거기 때문에 일단 만족하는 걸로.

언젠간 1등 한 번 해보자!

스터디를 같이 하는 후배들에게도 안내해줬기 때문에 같이 top10 안에 들어가면 기분 째질 것 같다.

Summary

• Composition API 조사
• 오픈소스 기여 시도
• 코덕 2등
• 알고리즘 스터디