2021년 4월 3일에 시작해서 2021년 6월 20일에 끝났다. 첫번째 파트를 1주일 만에 끝내서 이러다가 3주 만에 다 보는거 아닌감? 했는데, 역시나 중간 — 뒤로 갈수록 다른 재밌는 것들(개발과 관련 없는 책이라던가, 술이라던가…) 이 자꾸 눈에 들어와서 수강 가능 기간 종료 이틀 남기고 졸업했다.
수강을 시작한 가장 단순한 이유는 재직중인 회사에서 비용 지원을 해주기 때문에 “안 들을 이유가 없어서”이다. 회사로부터는 Udacity 측에 지불하는 라이선스 비용이 꽤 크기 때문에 신청한 프로그램을 제 기한 내에 끝내지 못하는 경우 불이익이 있을 수 있으므로, 성실한 참여 부탁한다는 신신당부의 첨언을 들었다. 사람 심리가 못되어서 뭔가 이런 경고의 말을 들어야 긴장이 그나마 된다.
다른 이유는 업무할 때 소홀히 생각했던 부분을 다시 생각하고 싶었기 때문이다. 아무래도 서비스 개발을 하다 보면 기능을 새로 추가할 때 루틴이 정해져 있고, 코드 아키텍처에 익숙해지면 거기에 맞추어 유지보수를 하면 되므로 익숙해 지면 별다른 생각 없이 업무를 하기 쉬워진다. 그러다보면 프로젝트에 맞춤형 인간이 되어가는 느낌이 들어서 기분이 별로 좋지 않다. 특정 프레임워크나 라이브러리에서 벗어나서 바닐라 JS에 대해 생각해 보는 시간을 가지고 싶었다.
이 나노디그리는 객체 지향 자바스크립트, 함수형 프로그래밍, 그리고 비동기 프로그래밍 세 파트로 구성되어 있다. 그동안 업무를 하면서 접했던 코드를 떠올리며 복습하면 좋은 기회가 될 것 같았다. 그런데 이 기준으로 따지면 함수형이나 비동기 프로그래밍보다 객체 지향 자바스크립트에서 뜨끔하는 부분이 많았다. 비동기 프로그래밍은 실제 업무에서 접할 기회가 많았어서 프로젝트 진행에 별다른 시간이 들지 않았다.
생각해 본 것들
객체 지향
객체 지향은 Java를 배우면서 접한 프로그래밍 패러다임인데 자바스크립트로는 실무에서 적용할 기회(특히 prototype을 직접 사용한다던가, mixin pattern을 사용할 기회)가 별로 없었다. 오히려 GraphQL API 서버를 만들어 보면서 비동기 프로그래밍에 대해 더 생각해 볼 기회가 있었다. 프론트 단에서는 함수형 React 컴포넌트를 Route, Container, Element 단위로 쪼개서 설계하고 이를 잘 조합하는 정도로만 작업을 했다.
JS 개발 서적에서는 정말 많이 다루는 내용인데, 막상 실무에서는 그렇게 쓸 기회가 없었으니, ‘헷갈리기 쉬워서 책이나 강의에서 분량을 길게 뽑기 좋은 개념’과 ‘실무에서 많이 쓰이는 개념’ 사이는 관련성에 대해서도 한번 생각해 보게 되었다. ‘헷갈린다’라는 것은 이름이나 사용법이 직관적이지 않는다는 것인데, 그렇다면 그것은 사용을 자제하거나 회피하는 편이 더 좋지 않을까? 생각해보면 클래스나 프로토타입 보다는(물론 내가 사용한 npm library 내부에 이들을 적극적으로 활용한 코드가 있긴 할 것이다), 모듈 패턴을 실무에서 많이 사용했다.
프로토타입을 제일 처음 접했을 때 이해하기가 어려웠다. JS에서는 이를 기반으로 객체 지향을 구현하지만, Java 같은 클래스 기반 언어와 프로토타입 기반 언어의 차이점을 익히고, 나중에 스펙에 추가되어 JS 클래스가 등장하므로 이를 사용한 객체 지향 프로그래밍도 (살짝이나마) 알고 있어야 했기 때문이다. 아, 그런데 또, JS 클래스는 프로토타입의 문법적 설탕이라고 하는데 차이점도 또 있다고 한다! JS 객체 지향 학습할 때는 뭔가 안심할 수 있는 단계가 없고 다음에는 어떤 장애물이 등장할 지 불안하다.
예전에 Python, C++, C, Java 등의 언어를 먼저 많이 쓴 사람들이 JS를 신랄하게 비난할 때 잘 이해가 안갔는데, 이제는 공감간다. 그리고 가끔 드는 생각은 자바스크립트는 원시 타입을 제외한 나머지 값들은 모두 객체라는데 객체를 가지고 객체 지향 프로그래밍을 한다는 말이 잘 이해가 가지 않는다. 이미 나는 프로그래머인데 프로그래머가 되기 위해서 프로그래머 지향 훈련을 하고 있다는 말처럼 들린다. 자, 불평은 이제 마치도록 하겠다.
카일 심슨의 ‘You Don’t Know JS — this와 객체 프로토타입, 비동기와 성능’ 책의 6장 초반에 다음과같은 문단이 나온다.
간단해 보이는 걸 왜 이렇게 복잡하게 만들어야 하는 걸까 하고 당연히 의문이 들게 마련이다. 뚜껑을 열어보니 안에는 상당히 지저분한 것 투성이다. 그러니 자바스크립트 개발자들은 대체로 깊숙히 알려고 하기보단 남이 만든 소스나 클래스 라이브러리를 가져다 쓸 생각부터 하게 되는 것이다.
4장, 5장은 그동안 객체 지향 프로그래밍을 JS로 구현하느라 고군분투한 개발자들의 노고를 설명해주고, 6장 ‘작동 위임’ 챕터에서 자바스크립트 객체의 Prototype 체계 사고법에 대해 설명한다. 2년 전 쯤에 읽었을 때는 카일 심슨이 왜 다른 언어의 객체 지향 프로그래밍 사고 방식을 자바스크립트에 적용하는 데 반대하는 입장인지 이해가 안갔다. 그래도 서서히 이해가 가고 있으니 다행이다.
클래스 기반의 상속과 프로토타입 기반의 상속 차이점에 대해 잘 알아둬야겠다. 특히 가장 큰 차이점은 프로퍼티 확장이 런타임에 가능하느냐, 가능하지 않느냐인 것 같다. 프로토타입 기반 상속의 경우에는 가능하기 때문에 사전에 약속되지 않은 확장이 이루어지는 경우 혼란을 일으킬 여지가 다분하다. 물론 유연성이 주어지는 것이기 때문에 마냥 단점이라고는 할 수 없겠다.
JS에서의 객체 지향 프로그래밍을 공부할 때는, 클래스 기반 언어 나라에서 이주해 온 사람들이 자기가 익숙한 언어에서 뭔가를 하나씩 빼와서 JS 스펙에 추가해 나가는 과정을 공부해 나가는 것이라고 생각하면 흐름을 따라가기 쉬울 것 같다.
- As a JS Developer, This Is What Keeps Me Up at Night
- You Don’t Know JS — This & Object, Prototype — Ch4. Mixing (Up) “Class” Objects — Javascript “Classes”
- MDN — Class-based vs. prototype-based languages
불변 자료 구조
대학교 2학년 때 자료구조 수업을 들었긴 들었는데, 불변 자료 구조에 대해 들어본 기억이 전혀 없다. 자료구조에 관심이 없었기 때문에 더 신경을 안써서 그랬는지도 모르겠다. (관심 없이 듣는 과목이 이렇게나 해롭습니다.) 그래서 함수형 프로그래밍 파트에 Immutable.js 라이브러리 설명이 나오는데, 여기서 불변형 자료구조의 장점에 대해 설명하는 부분이 잘 이해가 가지 않았다.
반성하는 의미에서 참고 자료로 링크된 Anjana Vakil의 함수형 프로그래밍 JSConf 발표를 한국어로 옮기는 작업을 해봤다. (바로가기) 친근한 분위기로 최대한 쉽게 설명하려는 모습이 너무 인상깊다. 메일을 주고 받다가 트위터 계정이 있으면 태그를 걸어주겠다 했는데, 아쉽게도 트위터를 하지 않아서 번역 허가 내준것으로도 충분히 고맙다고 했다.
Task Queue: Macro & Micro
비동기 프로그래밍 파트에서 빼 놓을 수 없는 이벤트 루프! 하지만 이것도 내 머릿속에는 잘 정리되지 않은 상태였다. Task Queue가 있고, 일반 동기 작업 코드, SetTimeout, Promise가 실행되는 시점이 다르다는 정도로만 알고 있었다. 발표 자료나 글을 보면 이벤트 루프는 무한 기호(∞)로 자주 표현된다. 말그대로 끝이 없기 때문이다. 그런데 “macrotask queue”와 “microtask queue”가 따로 있는지는 몰랐다. (얼마 전에 DSLR 카메라 렌즈를 사려고 열심히 구글링한 덕분에 갑자기 매크로 렌즈와 마이크로 렌즈가 떠오르긴 했다.)
microtask queue는 프로미스(혹은 async/await)를 다루고, macrotask queue는 이 외의 다른 작업들이 들어간다. 그래서 JS 엔진의 call stack이 비어있음이 감지되면, 우선 가장 첫번째로 macrotask queue의 가장 오래된 태스크인 작업(예: script)을 하나 실행하고, microtask queue의 작업을 모두 실행하고 macrotask queue의 작업을 하나 완료하고, 그 다음에 렌더링이 이루어진다. 이 과정을 이벤트 루프에서 무한히 반복한다. 더 자세한 내용은 아래 Javascript info 사이트 링크를 확인하면 된다. 설명이 무지 깔끔하게 되어 있어 좋아하는 사이트다.
프로미스와 Async/Await 사용
업무할 때 ‘프로미스와 async/await를 섞어 쓰면 보기 안좋다’라는 이상한 강박이 있어서 일관적으로 하나만 사용하려고 했는데, 때에 따라서는 섞어 썼을 때 좀 더 코드가 깔끔해지는 경우가 있다. 비동기 작업에 대한 `resolve`, `reject` 처리를 코드 중간 중간에 해 줄 필요가 있는 경우에는 프로미스가 더 좋은 선택이 된다. 역시 모든지 너무 빡빡하게 기준을 세우면 안된다.
프로젝트 과제 하면서 써본 것들
- HTML `details` & `summary` element: 개발 뉴스레터에서 예전에 `details`와 `summary` 태그만 가지고 모달 만드는 아티클을 본 적이 있었다. (예시) 두번째 과제에서 이미지 갤러리를 모달로 띄우고 싶었는데 이 방법이 생각나서 한번 해봤다. 만들어 본 결과, 너무 편했다. 다만 이 요소들은 IE 지원이 되지 않으므로 실무에서 IE를 지원해야 할 경우에는 쓰지 못한다.
- JS Modules: 자바스크립트 파일을 모듈별로 나눠서 깔끔하게 import, export 하고 싶어는데 웹팩 설정 하기에는 너무나 귀찮았다. 그래서 찾아봤는데, 별도의 설정 작업 없이 `<script type=”module” />`을 사용하면 된다고 한다. MDN 문서를 참고해서 작업했다.
- Fetch API: 위의 모듈과 같은 이유로 설정 작업 하기 귀찮아서 기본으로 지원되는 fetch API를 사용해 서버로부터 데이터를 요청하고 받아왔다. 역시나 IE에서는 지원이 안된다. MDN에 따르면, XMLHttpRequest와 차이점은 fetch API가 서비스 워커 같은 다른 기술과 호환이 쉽다는 것이다. (MDN)
기타
좋았던 점
- 매 파트마다 프로젝트 과제가 하나씩 주어지고, 제출하면 리뷰어가 피드백을 해주면서 합/불합을 결정하는데 피드백이 상당히 알차다. 리뷰 속도도 엄청 빨라서, 항상 주말에 과제를 제출했는데 늦어도 1시간 내로 피드백이 온다. 프로젝트 채점 기준(rubric)이 꼼꼼하게 주어지기 때문에 서로가 시간 낭비하는 기분이 별로 없다.
- 강의 중간 중간 꽤 알찬 퀴즈가 섞여 있고 마지막에 배운 개념을 총동원한 프로젝트로 정리하는 구성이라서 개발 서적을 보고 알아서 실습을 하는 것보다 효율적이다. 토이 프로젝트 생각하기 귀차니즘에 빠진 분들에게 추천한다.
- 각 챕터가 비디오와 텍스트가 한 페이지 내에 섞여 있는 구조라서 비디오 + 슬라이드 파일 조합에 비해 왔다갔다 할 일이 적어 좋다.
별로였던 점
- 기분탓인거 같은데, 첫번째 파트가 오타가 제일 적고 준비가 제일 잘 된 느낌이다. 뒤로 갈수록 수강자가 줄어들어서 그러는 것인지는 모르나 오타가 종종 눈에 띈다. 몇개는 캡쳐해서 리포트 넣었는데 아직 피드백이 없다. (더 인기가 많은 나노디그리는 보는 눈이 많아 다를지도!)
수강팁
- 각 나노디그리 홈페이지 들어가면 “등록 마감까지 몇일” 남았다느니, 할인 쿠폰 적용 가능이라던지 마케팅 문구가 떠 있는데 백화점 세일같이 말만 바꿔서 거의 상시 하는 이벤트이므로 여기에 혹해서 서둘러 등록할 필요는 없다. 놓치면 다음에 또 세일한다.
- 프로젝트 하다가 막히면 GitHub 프로젝트 템플릿 저장소에 들어가서 다른 수강생들이 남긴 issue를 보는 편이 가장 문제 해결에 편하다. 프로젝트 템플릿 코드가 몇가지 outdated 된 부분이나 오타가 있었는데, 업무 경험이 있다면 어디서 버그가 나오는건지 감으로 빠르게 수정이 가능하지만 업무 경험이 없거나 적은 분들은 혼자 보려면 해결이 오래 걸릴 수도 있을 것 같다.
- reddit의 어떤 스레드를 보니, 나노디그리 가격이 점점 올라가고 그에 반해 학생 지원은 줄어들고 있다고 한다. (댓글에서 보듯이 공격적인 VC들의 자금 회수 압박이 원인 중 하나일수도 있겠다. 비영리 기관이 아니니깐…) 그래서 금전적으로 무리해서 수강할 필요는 없을 것 같다. Coursera나 edx에서도 비슷한 내용의 강의가 많기 때문이다. 다만 나노디그리는 프로젝트 과제 및 1:1 피드백 시스템이 좋으니, 이것을 원하면 추천한다.
- 각 모듈마다 수강 예상 소요 시간이 적혀 있기는 한데, 본인이 잘 모르는 모듈인 경우에는 이것저것 찾아보는 시간까지 합해서, 원래 예상 시간의 1.5배 정도의 시간이 소요된다고 보면 된다.
마치며
3개월 동안 듬성 듬성 들으면서 소홀히 했던 생각들을 정리해 볼 수 있는 좋은 기회였다. 업무에서 조금 벗어나서 정리의 시간을 가지고 싶은 분들께 추천한다.
중급 자바스크립트를 들었으니 작년에 기초만 봤던 파이썬 중급 과정을 듣고 싶어졌다. 파이썬이 선수 요건이 되는 고급 과정들이 많아서 언어 중에 배워두면 개발자 커리어에 제일 도움이 많이 될 것 같다. 나노디그리 난이도 레벨을 보면 파이썬 관련 과정들을 초중급 정도의 낮은 레벨로 두었고 Java나 C++를 중급 이상의 레벨로 두었는데, 요즘 한국 학부 과정에서도 이런 순서로 가르치고 있는지 갑자기 궁금해진다.
