책 10배의 법칙을 읽고 든 생각이다.

어느덧 내가 개발자가 된 지 2년이 지났다. 시간이 어떻게 이렇게 빠르나 싶다. 1년 동안 뭐했는지, 요즘 나의 근황과 커리어에 대한 고민을 적어 보려 한다.

사실 Graphmark 프로젝트 끝난지는 2달이 지났지만, 재충전 핑계로 이제야 회고글을 작성한다.

2월 6일부로 필자도 드디어 2년차 개발자가 되었다. 2, 3주년은 몰라도 1주년은 좀 기념할 만한 것 같아 ㅎㅎ… 응애응애에서 응애가 된 기념으로 1년 동안 개발자로서의 나의 삶을 돌아보려 한다.

celery는 한마디로 queue를 중간에 두고 백그라운드 작업을 실행할 수 있게 하는 파이썬 라이브러리다. python, 백그라운드 작업 하면 딱 떠오르는 유명한 라이브러리라서 이쪽에 관심이 있던, 혹은 프로젝트를 진행하셨던 분들이라면 아마 다 아실 거라 생각한다. 회사 프로젝트에서 celery를 사용할 일이 있어서 celery worker를 ecs로 배포했는데, 이와 관련하여 고민했던 과정들을 적어보고자 한다.

오늘은 1~2주 전에 docker + vpn을 사용하면서 겪었던 네트워크 이슈에 대해서 잊기 전에 써보려고 한다.

오늘은 vpn을 aws에서 사용할 때 service discovery로 ecs container에 접근할 수 있도록 삽질세팅했던 경험을 공유하고자 한다. (짧음)

우선 vscode가 python 타입을 어떻게 아는지부터 알아야 한다.

원래 python을 혐오하는 사람 중 한 명이었으나 회사에서 3개월 넘게 쓰면서 미운정이 들기도 했고 이 주제를 공부하면서 강력한 OOP 언어가 될 수 있다는 것을 알게 되었다. 우선 찾아보게 된 배경 + 앞으로 나올 글의 흐름은 다음과 같다.

지금까지 알아온 것들을 바탕으로 Nest container가 어떻게 DI와 IoC를 적용하는 지 살펴보자. 정말정말 복잡하고 글도 길고 코드도 필자가 보고싶었던 부분만 본 거고 모든 내용이 필자의 뇌피셜이고 아 이런게 있구나 하는 정도로만 봐주길 바란다. 구조를 보여주는 사진도 추상적으로 마음대로 그린 것이다. 뇌피셜 주의

이제 필요한 개념들을 다 알았으니 7편과 8편에서는 이 개념들이 NestJS 소스코드에 어떻게 적용되었는지 알아볼 것이다. 이번 7편에서는 token이 어떻게 관리되는지부터 살펴보자. 뇌피셜 주의

NestJS에서 소스코드 보다가 정말 신선했던 부분이 있었는데, 이게 NestJS를 개발한 사람이 혼자 이 방법을 생각해내서 사용한건지, 아니면 많이 쓰이는 방법인데 필자만 몰랐던 건지 모르겠지만 아무튼 되게 똑똑한 방법이고 활용성 높은 코드라고 느껴서 이렇게 따로 글을 써봤다. 나중에 알게 된 사실인데 테스트 패키지인 jest에서도 똑같아 보이는 걸 봤다. [링크] done promise는 여러 곳에서 많이 쓰이는 것 같다.

NestJS는 데코레이터와 reflection 기능을 기반으로 동작한다. 서비스로 등록하고 싶은 클래스에 Injectable 데코레이터를 달아주고, 모듈로 등록하고 싶은 클래스에 Module 데코레이터를 달아줘야만 metadata를 클래스에 할당해서 제대로 동작하기 때문이다.

factory provider가 dynamic module에서 어떻게 쓰이는 지 알아보려면 당연히 dynamic module이 뭔지 알아야 한다. 이번 편에서도 되도록 공식문서를 번역하는 것은 지양하도록 하겠다.

2편에서는 provider wrapper를 잠깐 살펴봤었다. 후에 나올 dynamic module을 이해하기 위해서는 factory provider를 알아야 하는데, 이를 위해 custom provider를 살펴보자.

Nest container를 통해 dependency가 관리된다는 건 알겠는데, 인스턴스를 뭘로 구분할까? 예를 들면 CatService의 인스턴스를 어딘가에 저장해놓고 DogService가 instantiate될 때 그걸 불러와야 하는데, 그 어딘가에는 CatService 말고 다른 인스턴스들도 있을건데, 뭘로 CatService의 인스턴스를 찾을까?

NestJS에 대해 나름 깊게 탐구할 일이 생겨 그동안 알아봤던 것들을 공유하고자 한다. 사실 마지막 7, 8편을 쓰려고 이 많은 걸 썼다.

pulumi에는 dynamic resource provider 라는 게 존재한다. 리소스의 lifecycle을 직접 관리할 수 있는데, 여러모로 편리하고 확장성 있는 기능이다. (terraform에는 없다고 한다.) 원래 이런 게 있는지도 몰랐었는데 회사에서 좀 특별한? 상황이 생겨서 이러한 기능이 필요해서 찾다 보니 발견하게 됐다.

여기 공식 문서 내용이 잘 돼있어 이 내용 중심으로 작성해봤다. 사실 플랫폼 사용자가 적어 구글링 해도 잘 안나와서 공식 문서만 믿고 가야한다. 다행히 aws처럼 공식 문서가 끔찍하게 돼있지는 않아서 볼 만하다.

회사 다니면서 mac을 처음 써봐서 homebrew를 설치하다가, 문득 os마다 하나씩은 존재하는 패키지 관리자는 어떻게 동작하는지 궁금했던 게 기억나서 회사에서 동일 주제로 세미나를 했던 걸 정리하고자 한다.

오늘(230307) pulumi destroy를 해서 회사에서 동작하는 개발용 서비스를 중지시켰다. pulumi cli가 내부적으로 어떻게 동작하는지 몰라서 일어난 일이다. 원래 있던 리소스의 파라미터 값을 편하게 가져오기 위해 pulumi import를 사용해서 코드를 짰으나 이게 pulumi 서버와 연동되는 줄 몰랐다.