연말 회고에 대하여

개발자 사람들은 날씨가 추워지면 연례 행사로 한 해 있었던 일을 블로그 포스트로 정리하곤 한다. 개발자 사람들은 왜 회고를 할까? 개발자 사람들은 글을 쓰기가 귀찮아서 '커밋 메시지 잘 쓰기', '테크니컬 라이팅 잘 하기' 뭐 이런 것들도 쓰지 않던가? 그런데 나는 왜 2020 회고를 하려고 하지?

3d

올 한 해 제일 남는 키워드는 이건 것 같다.

 

처음에는 react를 하게 되었는데, 19년 말에

yeong die

yeongdie/yeongdie.github.io

이 사이트 작업을 하게 되었고 그리고

sungchuni/ws-visu-obj

이런 작업을 하게 되었다.

 

이것은 윙크스톤파트너스라는 회사의 페이지에 들어갈 비주얼라이제이션 오브젝트이다. 컴포넌트에 따라 2d로 혹은 3d로 각 점과 선의 좌표를 관리한다. 지금은 홈페이지 디자인이 바뀌어 볼 수 없지만

sungchuni/ws-dev-sungchuni

데모 프로젝트를 따로 만들어뒀지롱, (클라이언트를 위한 시연용이었다.)

내가 어떻게 해도 나를 신뢰할 사람이 일을 줘서 주도적으로 일을 진행할 수 있었다. 미리 작은 react 프로젝트를 만들어 본 게 큰 도움이 되었다.

 

이때에는 이미 react hooks 관련한 안내 자료도 많고 베스트 프랙티스도 여러 군데에서 접할 수 있었으나, 저 컴포넌트가 사용될 기존 프로젝트가 hooks를 전혀 사용하지 않고 있는 것 같아 아마 전부 클래스 기반의 컴포넌트로 진행했던 것 같다. (나중에 hooks로 만든 컴포넌트를 몇 개 더 발견했지만, 기조를 지키기로 하였다.) 지금 다시 컴포넌트 소스를 보니 이렇게 props가 크면 큰일나 하고 과거의 나에게 메시지를 보내고 싶다. 다만 그때에도 먼저 걱정을 했는지 index.d.ts 하나 작성을 해서 큰 도움을 받았던 것 같다. 클라이언트쪽 개발자로부터 이게(타입 선언 파일이) 도움이 된다고 했던 것도 같다.

 

그리고 헬로우봇, hellobot.co/store/featured

여기서 판매하는 보고서report 템플릿 작업을 했다. 한 10개를 했던가? 8개? 이걸 하면서 아주 하드하게 angular 문법을 쭉쭉 흡수했다, 나는 Angular 문서를 읽으면서

끝에는 모두가 angular에 가 닿으리라.

뭐 그런 생각을 했다. 지금은 좀 아니다, 삼국지(a, r, v) 장군들 셋 다 잘하는 거 같다. 삼대장의 기세 싸움은 분기별로 꾸준히 변하는 걸로 보인다. 지금은 vue v3가 매우 진일보한 것처럼 보이지만, react가 더 밝은 미래 비전을 제시하고 있다.

 

gist.github.com/sungchuni/d23746c036a64e0d8cf9d981e707426b

헬로우봇 보고서 작업은 비즈니스 로직에 착 들러붙은 템플릿이어서 가져올 수 있는 코드가 꽤 없었다. 이 정도가 전부일 듯 하다. 한글 종성을 가지고 조사 찾기, 이걸 더 많은 케이스에 대해 대응 가능하게 발전시킬 수는 있을 것 같은데, 저번에 검색을 해보니 다른 언어로 작성된 선배 라이브러리들이 많더라, 나는 국어국문학과가 아닌가? 이건 언젠가 한다.

 

윙크스톤의 프로젝트랑 헬로우봇 프로젝트를 하면서 거의 모든 캔버스API 메소드랑 프로퍼티 문서를 다시 보게 되었다. 실 사용시의 주의점, 그러니까 프레임은 어떻게 다루고 상태 관리를 어떻게 하는지랑, 그걸 2d 화면에 어떻게 투영project 할지랑, 그리기 함수는 어떻게 나누면 좋고 등등 을 익히고 나서는, 아 원래 하려는 게 이런 거였지? 하는 생각을 하였지.

 

나는 원래 기획자를 먼저 했었는데, 개발자로 전향하게 된 계기를 물어보면 항상 쉽게, 안 된다고 하는 걸 내가 하려고 하고 대답할 수 있다. 자연스럽게 ui 개발쪽으로 시작해서 프론트엔드로 넘어온 것 같다. 이를테면 폴더 트리 컴포넌트 작성하기 같은 것들. (그때로 얼른 돌아가서 이거 이렇게 이렇게 하자구요, 말씀 전해드리고 싶다.)

 

회사에서 만든 컴포넌트 몇 개를, 그러니까 레거시 페이지를 vue 앱으로 포팅하면서, 캔버스로 ui로 구현을 했다. 마음 같아선 할 수 있는 것 전부를 그렇게 하고 싶었지만, 반발을 예상해서 조금씩, 슬라이더 컴포넌트나 차트 같은 것들을 그렇게 했다. 나는 결과물이 매우 마음에 들었고, 기존 라이브러리를 충분히 대체할만하다고 판단했다. 특히 차트 같은 건 기존에 구글의 Charts를 썼던 것을 버렸는데, 번들 용량이 충분히 작아져서 기뻤다. (나는 라이브러리를 버릴 때 좋아하는 사람) -> 그렇지만 연말에 회사에서 라이브러리의 사용과 관련해서 깊은 논쟁이 생겨버렸다, 결국 우리는 underscore를 하드하게 사용하기로 했다.

 

여기까지가 대강 봄이 되기 전의 이야기이고 봄, 한 4월 쯤부터 약 5-6주 동안에는 회사 서비스인데 학생복지스토어의 관리자 페이지를 graphql이랑 apollo를 express에 얹어서 vue 앱으로 새로 만들었다. 포팅이라고 하기엔 페이지 개편도 좀 하고 기초 ui도 정리를 많이 했다. graphql, dataloader, apollo, express 서버 쿡북은 언제 정리를 하고 싶긴 한데, 할 때는 생각보다 긴 작업이 아니라 생각했는데 지금 거기에 얹힌 것들이 많아서 좀 까마득하긴 하다. 사실 서버 만드는 것도 재미가 있지만 제일 재밌는 건 이니시스가 넘긴 php 라이브러리를 전부 nodejs 서비스로 포팅한 일이었다. 하면서 php 라이브러리의 오타도 발견했고(끝자리가 특정 숫자로 끝나는 거래에 대해서만 오류가 발생했다, 지금 생각해도 이걸 찾은 게 말이 안되는군.) 음 결국 우리는 php를 서버에서 치울 수 있었다. 내 로컬 도커에서도 php 이미지 방을 바로 뺐다, 뺐어 난 신이 났어.

 

gist.github.com/sungchuni/a628880f10b4a4cee5ce055a58ef6460

이것은

 

Pagination | GraphQL

이 문서의 내용을 apollo에서 지시자로 구현한 내용이다. 매번 특정 응답 타입에 대해, 그 타입의 노드와 그 타입의 노드를 포함하는 페이지 타입을 매번 선언하기가 싫어서 이런 것을 만들었다.

아래처럼 `Log`라는 기존의 타입이 있다면

type Log {
  message: String
  timestamp: Int
}

특정 쿼리에 대해 아래와 같이

type Query {
  getLogs: Log @paginate
}

지시자만 추가하면 된다. 

이것도 뭔가 스키마 문법을 빌려서 사용법을 표현하고 싶었는데, 기존의 graphql의 것으로는 어려워서 주석으로 만들어 abstract type이라는 표현을 썼다. 흠 지금 보면 지시자 구현부를 더 분할하고 읽기 좋게 만들 수 있을 것 같다. 이것은 나중의 블로그 포스트를 작성할 때 작업할 것.

 

그리고 올 하반기에는 거의 테스트 테스트 드리븐 테스트 테스트, 회사 일정을 미리 쭉 당겨놓고 테스트 코드를 작성하고 팀원들을 설득하는 걸 어떻게 하나 고민했던 것 같다. 거의 내가 작업했던 모든 클라이언트 컴포넌트, 서버 라우터에 대해 테스트 코드를 작성해본 것 같다. 결국 얼마전에 한 서비스에서 운영 배포하는 데에 성공했고, 나름 의미가 있도록 리팩터링 작업과 병행했다. 나름이라는 말을 왜 넣었나? 정말 유효했고 좋았다.

 

연구의 산출물로

단일 함수에 대한 브라우저 환경의 자바스크립트 테스트 작성 (tistory.com)

이런 포스트도 쓸 수 있었고, 또

sungchuni/parse-matchers

sungchuni.github.io/parse-matchers/

이런 웹앱도 만들었다, 이런 걸 왜 만들었는지에 대해선 또

Jest, Jasmine의 matchers 메소드 비교, 대조 (tistory.com)

여기에 정리를 했다.

 

아, 회사 업무를 하면서 캔버스를 이용한 이미지 다운스케일링 메소드 작업도 했다. 이것은 여기 티스토리 블로그에 시리즈로 정리를 했는데, 한 5회차 중의 3회분 정도만 작성을 하고 멈추어있는 상태이다. 현재 운영 코드는 여기 마지막 포스트의 것보다는 조금 더 세련되었다. exif 메타에 접근해서 오리엔테이션 정보만 파싱하는 메소드도 같이 쓰는데, 이것도 따로 포스트를 적을 생각이다.

 

가을 이후로는 unity를 가지고 Quarantine Etudes라는 이름의 webgl 앱을 만들었다. 웹앱 쪽은 svelte로 만들었는데, svelte는 팀을 만들어서 팀원끼리의 굳건한 결의가 없다면 엉망진창 폴더를 만들기에 딱 좋을 거 같다. (노 보일러플레이트를 표방하는 프레임워크들은 다 요모양이다. 하지만 사랑스럽지,) 지금 사실 서버를 안 죽여놨는데 뭐 이걸 공개하기에는 앱이 한 70mb가 되어서, 그게 다 돈이어서 어렵다. 이 홍보용 포스트만 링크한다.

 

이 프로젝트를 하면서는 아까 내가 angular에 대해 말할 때랑 똑같이

아 c#이여, 아 microsoft여, 

하는 환희가 좀 터졌던 것 같다. 그치만 c#이나 닷넷 관련 싫어하는 사람들이 꽤 많은 것 같기도 하고, 나는 좋았는데 말이야. 이걸 하면서 리스트 계열 타입 인스턴스의 sort 메소드를 가지고 배열 랜더마이징 하는 게 굉장히 바보 같다는 걸 깨닫게 되었다. 이런 javascript 테스트 헬퍼 하나 적어두고 포스트 쓰기는 미루어 두었다. -> 그런데 v8이 배열을 정렬할 때 쓰는 timsort는 그냥 .sort(() => Math.random() - .5) 이런 식으로 해도 균등한 랜덤 배열이 출력된다. (사실 내 본진에서 그냥 그랬기 때문에 내가 c#에서도 그렇게 하다가 손바닥 맞은 것 같아.)

 

unity는 마지막으로 한 번 더 내가 하고 싶은 게 이런 건가? 하는 생각이 들게 해주었다. 우아한 코딩 세계, 앞으로 어쩌다가 세상이 한 번 지겨우면 나는 내가 지구를 만들어서 여행을 다닐거야.

 

왠지 다시 20년 1월로 돌아가서, 그때부터 nuxt 사용하지 않는 express, vue 서버사이드렌더링 빌드 스크립트를 만들었고, preload까지 지원하는 선에서 마무리를 지었다. nuxt가 초기 빌드 속도가 느려서 불만족이었는데 결과물은 마음에 들었다. 하지만 아직 기존 사이트에서 vue 앱으로 전환된 비율이 크지 않아, 그냥 앱이 작아서 빌드가 빠른 걸 수도 있다. 최근에 나는 esbuild에 대해 심각하게 고찰 중이다. nuxt 프로젝트였던 대학백과는 커뮤니티를 릴리즈했다. 8월에 한 한 달을 작업한 걸로 커밋 로그가 기록되어 있는데, 리뷰하는 데에 오래 걸려서 다소 지쳤었다. 그래도 많은 어린이들(고등학생)이 이걸 사용하고 친구들을 만나고 있는 것 같아 기쁘다. 12월에는 express 서버의 일부 라우터를 분해하는 데에 에너지를 썼다. 테스트를 만들어서 넣고 단계적 리팩토링을(중복된 거대 라우터들을 외부 컨텍스트 객체를 공유하는 작은 함수를 호출하는 식으로 바꾸고, 나중에는 컨텍스트 공유하지 않는 독립 함수들의 조합 형식으로 변경했다.) 진행했다. 이제 다른 라우터들을 어쩌지?

 

rescript-lang.org/ 여기 문서를 꼼꼼히 한 절반을 읽다가 javascript interop 섹션 앞에서 멈추어 있는 상태이다. 나는 이사 때문에 바빴거든, 근데 javascript interop이 이 언어한테 있는 가장 큰 강점인 것 같다. 강점인가? 약점인가? 함수형 류 언어들이 exhaustiveness 이야길 많이 하는데 그걸 웹 클라이언트에서도 도입할 수 있겠군 싶어서 시작했다. 할 수 있을까? (다른 사람을 설득할 수 있겠느냐는) (말이지.)

 

뭔가 올해에 한 일이랑 블로그 포스트 앞으로 어떻게 할 건지 이런 것들이 뒤죽박죽이다. 요즘에는

gist.github.com/sungchuni/d185a4bd44d627c8eb212a34e1703856

이렇게 debounce나 throttle처럼 쓸 수 있는 axios 인스턴스를 위한 자동 cancellation 래퍼 메소드에 대해 정리를 할 생각이다. 가능하면 ember-concurrency (ember-concurrency.com) 요기에서 지원되는 동작들 대부분은 흡수하고 싶은데, 음 다는 안 되었던 것 같은데 지금 좀 보고 자야겠다.

 

그러면 2020년 안녕히,