새로운 것을 빨리 배우고 싶을 때 유용한 팁
2020년 11월 06일 작성TL;DR
- 유튜브를 적극 활용한다.
- 업무와 관계있는 공부를 하자.
- 명확한 목표를 세우고 공부하자.
시작하며
프로토타이핑 팀이라는 곳이 들어온지 1년이 좀 넘었는데, 정말 다양한 분야를 접하게 되었다.
멀티 오브젝트 트래킹 모델 튜닝 -> ECS 를 이용한 MSA -> 추천엔진(퍼스널라이즈) 및 MLOps -> IoT
대략 위의 내용들을 2달마다 바꿔가면서 해왔다. (중간중간 이전에 했던걸 조금 바꿔서 다시 해야할 때도 있다.)
AWS의 프로토타이핑은 PoC 랑은 좀 다르게 실제로 프로덕션으로 출시하기 전에 고객들이 우려가 되는 부분을 같이 만들면서 AWS 에 enable 하도록 도와준다. (개발자들이 스스로 쉽게 할 수 있는 업무는 안온다는 뜻..)
그러다보니 실제 프로덕트를 만들 개발자들과 같이 개발을 하게 되고, 공식 문서를 읽어보세요 보다는 개발에 더 도움이 되는 내용(디테일한 내용)을 알고 있어야 한다.
즉, 나의 매일 업무는 아래와 같이 정리할 수 있다.
기존에 해보지 않았던 분야에 대해, 2달내에 준 프로덕션 퀄리티의 실제로 동작하는 서비스를 만들어내면서, 다른 개발자들에게 영향력을 줄 수 있는 정도의 깊이도 있어야한다.
이 글 에서는 지난 1년간 빠르게 새로운 것을 배울 때 유용했었던 세가지 팁을 적어본다.
유튜브 먼저 검색한다
나는 요즘 새로운 분야를 시작할 때 일단 유튜브를 검색한다. (AWS 에 특화된 내용이라면 사내 유튜브 같은 서비스가 있는데 거기도 검색한다.)
그래서 어느정도 머리에 정리가 되었거나 적절한 유튜브 영상이 없으면, 그제서야 공식 매뉴얼을 읽거나 구글에서 블로그를 검색한다.
글은 내가 빠르게 읽고 이해할 수 있다면 필요한 정보만 빠르게 획득하고 빠져나갈 수 있게 때문에 획기적으로 시간을 줄일 수 있다.
반면 비디오는 어디에 내가 원하는 정보가 있을지 감이 안오기 때문에 비디오 길이의 50% 정도는 소모해야한다. (그래서 검색했을때도 러닝타임이 긴 유튜브는 잘 안본다)
대신 비디오는 제작하는데 공수가 많이 들기 때문인지, 지식단계별로 매우 고품질의 콘텐츠가 글보다 훨씬 많다.
따라서 글은 내가 무엇을 알고 싶은지 명확히 알고 있을 때 매우 도움이 된다.
그리고 비디오는 내가 무엇을 모르는지도 잘 모를 때 크게 도움이 된다.
(단점은 둘다 영어를 잘 알수록 정보습득 시간이 줄어든다..)
업무와 관계있는 분야를 공부한다
다음 팁과 연관이 있는건데 일단 따로 적어본다.
생존영어가 잘 느는것처럼 매일의 업무와 관계가 있는 분야여야 스스로 동기가 생기고 집중도 잘 된다.
개발자들이 사이드 프로젝트 라고 부르면서 신기술을 써보는걸 많이 하는 것 같다.
개인적으로는 새로운 것을 배우려는 의지에서는 크게 평가하지만 그렇게 배운 기술 자체가 의미있는 수준이 되는 것은 쉽지 않다.
그리고 새로운 기술일수록 며칠만 안쓰면 바로 다 까먹는다. 이전 회사 다닐때 집에서 유니티로 혼자 게임도 만들어봤는데 지금은 다 까먹음
그래서 개인적으로 사이드 프로젝트를 할거면 현재 내가 매일 다루는 기술에 관련된 것을 하도록 권장한다.
예를 들어, 현재 회사에서 메시지큐로 Kafka 를 쓰고 있다면, Kafka 를 좀 더 깊게 사용해보는 데모를 만든다거나 EventStore 또는 ActiveMQ Artemis 등으로 대체해보는 데모를 만드는 것이 커리어에 (특히 이직시에도) 훨씬 도움이 된다.
명확한 목표를 세운다
파인만이 말했듯, 어떠한 정보를 얻을 때 어느정도 깊이까지 알게되면 만족하는지는 사람마다 다르다.
자원이 무한하면 만족할때까지 깊이있게 정보를 계속 얻으면 좋겠지만 보통은 자원이 제한되어 있기 때문에 그럴수가 없다.
따라서 내가 가진 자원을 고려하여 깊이(기술의 이해도)와 폭(기능의 개수)에 대해 명확한 목표를 세우는 것이 효과적이다.
예를 들면, 12월 06일까지 AWS IoT Core 랑 라즈베리파이로 RFID 출입로깅 시스템 데모를 만들어봐야지. 정도가 되겠다.
(출입로깅 시스템의 세부적인 내용은 만들면서 정해도 된다)
좋은 목표는 크게 2가지 특성을 가진다.
- 기간
- 결과물
보통 기간을 아무렇게나 정해도 되는거면 우선순위가 낮은 일일 것이다. 그리고 우선순위가 낮은일은 영영 안해도 되는 경우가 많다.
반면 데드라인이 정해진 목표는(업무와 관계있거나 면접준비거나), 기간과 함께 내가 투입할 수 있는 시간이 나온다. 보통 맨먼스라고 부른다. 그리고 그 맨먼스에 따라 결과물의 구체적인 범위가 결정된다.
예를 들면, 이벤트소싱 + CQRS 로 헬로워드 구현해보기 라는 아이템이 있었는데 실제로 저 워크로드를 할당 받아서 구현해야하는 상황이 오기전까지 대략 2년 정도 백로그에 들어있었다.
결과물은 예와 같은 시스템일수도 있고, 라이브러리일 수도 있다.
결과물은 형태와 관계없이 명확한 범위를 정해주는 것이 중요하다. 결과물의 범위를 명확히 하면 어느정도 깊이까지 해당 기술을 다룰지도 정해진다.
위에 예를 들었던 Event Sourcing + CQRS 로 헬로월드 구현하기 는 실제로 진행되기전에 마감일을 정하고,
마감일까지 투입할 시간을 고려해서 몇개의 마이크로서비스가 몇개의 API 와 이벤트 타입을 처리할지 등이 정하고,
마지막으로 간단한 데모 시나리오도 정한뒤에 작업을 시작했다. (물론 대부분 처음 계획한 내용보다 더 적은 기능들을 구현하게 된다)
위의 2가지만 잘 생각하면서 진행한다면 진행을 하는 프로세스는 중요하지 않다. (혼자 하는거니깐) 애자일로 해도 되고 내킬때 해도 된다.
마치며
사이드 프로젝트를 한번에 2개를 진행할 수 있거나, 사이드 프로젝트에 하루 4시간이상 쓸 수 있다면,
뭔가 잘못되어가고 있다는 뜻일 수도 있다. 이직을 해야한다는 뜻일 수도 있고