지속가능한 개발자 성장 스킬 5가지

F-Lab : 상위 1% 개발자들의 멘토링

2022-12-18

개요

개발이라는 분야의 깊이는 얕다면 얕고, 깊다면 깊다.

내가 만들었던 어플리케이션에 사용자가 많아질수록, 데이터가 많이 쌓일수록, 새로운 기능이 추가될수록, 어쩌면 개선을 하면 할수록 더 문제가 많아질 수도 있다. 이러한 직업 적 특성으로 인해, 개발자가 업이 되면 성장이라는 단어에 집착하게 된다.

하지만 방향이 뚜렷하지 않거나, 방법이 효율적이지 않거나, 혹은 과도한 노력이 필요한 방식을 택한다면 이는 어떤 의미에서건 지속적이기 어렵다.

Continous라는 말이 뜻하는 지속적이라는 단어가 어떠한 의미인지는 진지하게 개발에 임해봤다면 모두가 그 무게감을 알 수 있을 것이다.

모든 방법과, 방향에는 개인차가 있겠지만 지속적일 수 있는 방법이야말로 당신이 주니어를 넘어 미드 레벨 엔지니어, 시니어, 리드의 기회, 그리고 그 기회를 다른 사람에게 폐를 끼치지 않고 진정한 고수준 개발자임을 드러낼 자산을 쌓을 수 있다고 생각한다.

지속이라는 무게

Github 잔디 심기라는 말이 있다.

바로 Github의 커밋을 말하는데, 이를 매일 빠짐없이 하는 것을 일일 커밋이라 불리는데, 근면 성실함의 상징으로 여겨져 유행이 되기도 했고, 여전히 성실함의 증명으로 쓰일 수 있다.

아쉽게도 일일 커밋이란 현실적으로 매우 어렵다. 이를 굳은 결심과 강한 의지로 한 달, 세 달, 길게는 일 년까지는 어떻게든 할 수 있을 것이다. 하지만 이를 평생 할 수 있을까?

또 그 발현 방향이 커밋으로 한정된다는 측면도 달성을 어렵게 하는 요인이다. 설계도 성장이고, 책을 읽는 것도, 코드 리뷰를 하는 것도, 오픈 소스를 열어 보는 것도, 그 날 안에 마무리되지 않은 개발도 학습이고 지속성 있는 노력이다. 이 노력을 커밋이라는, 또 일일이라는 틀에 맞추려다 보면 대부분의 사람에게는 현실이지 않다는 것을 깨닫게 된다.

물론 일일 커밋이 되는 분들이 있을 것이다. 모든 삶의 포커스와 우선순위를 일일 커밋이 가능하게끔, 작업의 단위도 아주 작게, 삽질한 기록마저 커밋으로 승화 시키면 가능할 수도 있을 것이다.

하지만 대부분의 사람에게 일일 커밋이란 지속적일 수 없는 노력의 방향이고 방식이라고 생각한다. 우리는 현실적이어야 하며, 효율도 추구해 지속 가능하게 삶에 녹여내는 것이 중요하다. 극한의 퍼포먼스를 내느라 견뎌내는 1년이 아니라, 10년 20년 30년의 개발 인생에 녹아드는 습관이 필요하다.

지속적으로 가능한 5가지 스킬

1. 정보 습득

습득방법

News Letter, RSS 구독, Slack Bot, 개발 커뮤니티 이용
이 과정에서 실습해 보고 싶은 정보, 더 공부하고 싶은 분야인지를 생각하면서 하는 것이 좋다.
우리의 시간은 유한하고, 세상의 모든 지식을 습득할 수는 없다.

News Letter, 커뮤니티

RSS 모음

활용 루틴 예

Slack, Feedly 등으로 RSS 구독
- 구독 된 정보를 주기적으로 가볍게 훑으면서, 한번 분류한다. 이 과정에서, 모르는 키워드에 대해서 어떤 의미인지 알아보는 과정을 거치는 것이 좋다.
분류된 정보를 여유가 있을 때 살펴본다.
- 파고들고 싶은 주제인지, 관심이 주제 여부에 따라서 시간을 들일지 고민한다.

2. 학습

책

책은 정제된 자료다.
검수와 검증이 이뤄지므로 학습에 좋은 수단이 될 수 있다.
다만 책이 깊이 있는 만큼 절대적인 시간이 아주 많이 소요된다.
- 입문서 수준의 책에서도 개념 이해를 뚜렷이 하는 수준으로
아래 추천 서적은 실제로 내가 읽은 서적 기반으로 작성한 목록이다.

3. 정리하기

습득한 정보에 대해 학습된 결과를 정리/요약한다.
이 과정에서 최대한 검증된 방향으로 정리한다.
위키, Notion, 블로그 등에 공유할 수 있게 정리하는 습관을 들인다.

권장 방식

학습하는 과정 중에서는 가볍게 요약정리한다.
이를 정제해서 블로그에 올린다.
작업 속도가 조금 더 들어가더라도, 정리하면서 진행한다.

권장하지 않는 방식

작업이 끝나고, 몰아서 정리하는 방식
이런 경우 기억도 잘 안 나기도 하고, 어떠한 글을 참고했는지, 어떠한 과정을 통해, 어떠한 생각을 통해 문제를 해결 지에 대해서 기억이 잘 안 남는 경우가 많다.
분명히 당시에는 좋은 경험이고, 성장에 도움이 된 유의미한 경험이었음에도 정리해야 된다는 사실 자체를 잊게 되기도 해서 잊히게 된다.

F-Lab 멘티 분들의 예시

유수민님의 주간 학습 일지
https://velog.io/@sweet_sumin/2022.11.2111.27
안건주님의 블로그
https://velog.io/@ahngj96
문다영님의 블로그
https://velog.io/@mdy0102

4. 실습하기

따라하기

보통 대부분의 패키지나 기술은 Getting Started나 Tutorial 등을 제공한다.
해당 자료를 무작정 따라 한다.

변형하기

해당 자료의 입력값을 바꿔보면서, 어떠한 원리인지 파악한다.
로직에 대한 이해가 이뤄진다면, 로직에 대한 변형도 좋다.
내가 배우고 있는 기능 혹은 언어나, 프레임워크 모두 완벽하지 않다.
이 과정에서 버그를 찾게 된다면, 공식 contributor가 되는 명예를 누릴 기회로 이어질 수도 있다.

테스트 케이스 추가하기

보통 예제까지는 테스트 케이스는 제공 안되는 경우가 많다.
테스트 케이스를 추가하며 동작 방식을 조금 더 깊이 이해할 수 있을 것이다.

5. 적용

Toy Project에 활용

시간이 많이 필요한 접근인 만큼 활용처가 떠오를 경우에만 해도 좋다.
또한 변형이나 테스트 케이스를 추가하다 보면 아 이 기능을 어디에 써먹으면 좋을까라고 접근해도 무방하고, 이미 만들어둔 Toy Project에 기능을 추가하거나 개선하는 접근도 좋다.
가능한 이러한 변화는 feature 브랜치를 만들어서 진행한다면, 기록적인 측면에서도 형상 관리에서도 좋다.

실무 프로젝트에 제안/적용

Toy Project에서 검증된 내용은 설득의 근거로써 유의미하다.
선행 학습, 검증이 일정 수준 이루어졌으므로, 실제 업무로의 활용까지 가는 사이클을 크게 단축시킬 수 있다.
공유/제안 만으로도 의미 있다.
실제 업무에 활용되면 좋겠지만, 항상 그럴 순 없을 것이다.
이 과정 자체를 밟다 보면, 좋은 동료나 상사가 옆에 있을수록 그들도 자극을 받을 것이다.
또한 피드백을 통해 더 퀄리티 있는 학습 결과를 낼 수 있는 방향에 도움을 받게 되기도 한다.

이러한 노력에 드는 시간은 얼마인가?

내 경험상 이러한 노력은 업무 시간에 뜨는 시간이나, 몰입이 되기 전인 업무 시작 전 30분, 몰입을 마칠 업무 마무리 전 15분 정도만 써도 충분했다.

다만 실습이나, 책 읽기 같은 경우에는 들어가는 시간이 적지 않다. 그렇기에 어떠한 주제를 파고들 것인지, 얼마나 깊이 있게 파고들 것 인지에 대한 선택과 집중이 개인의 상황, 열정, 습관에 따라 달라질 것이다.

나의 경우에는 별다른 일정이 없는 주중에는 최소 5시간을 개인 개발에 쏟고, 주말의 경우에도 별다른 일정이 없을 때는 최소 6시간을 쏟는다.

물론 이 과정이 즐거워야 하며, 이 과정에서 얻는 것이 뚜렷할수록 더 오래, 꾸준히 할 수 있을 것이다.

어떠한 주제로, 얼마나 깊이 파고 들어야 할까?

]계측이 어려운 삽질 경험을 줄이기 위한 학습도 좋고, 이미 이해도가 있는 기술에 대해 더 깊이 파고드는 것도 좋다. 삽질을 줄일 수 있는 노력도 개선이기에 좋은 접근이라고 볼 수 있을 것이다.

또한 이미 만들고 있는 프로젝트의 작은 부분을 개선하기 위한 학습을 하고, 그에 대한 적용도 좋다. 이미 동작하고 있는 서비스에 대한 개선은 시도까지 가는 과정을 조금 더 쉽게 해준다.

모든 학습마다 new project부터 시작되는 거창한 설계나, 계획이 필요하다면 용두사미가 되기 쉽고, 이러한 경험이 누적될수록 내가 유의미한 학습 사이클을 유지할 수 있는지 의심이 되기 때문이다.

그래서 위에서 언급한 대로, 가벼운 예제 따라 하기도 얼마든지 좋다.

다만 따라 하는 과정에서 원리를 이해하려는 노력, 활용 가능한 포인트를 짚어내는 노력과 시도가 더해지다 보면 그 이상을 해낼 수 있을 것이다.

마치며

5가지 스킬에 대해서 이야기했지만, 나는 1~3번까지만 잘 해내도 충분히 좋은 학습 습관을 가지기 시작했다고 말해주고 싶다.

언급한 대로 4~5번 스킬은 시간이 많이 필요하기에, 모든 학습 분야에 대해서 시도할 수 없기 때문이기도 하지만, 나는 깊이와 넓이 모두 어느 정도 갖춘 개발자를 지향하는 것이 가능성이 무궁무진한 주니어 개발자에게 유의미한 부분이 많다고 생각하고 있기 때문이기도 하다.

물론 내 제안은 나의 경험과, 내가 해온 방식에 대한 설명일 뿐이고, 자신에게 맞는 방식을 찾는 것이 더 중요하다고 생각한다.

그리고 그 시도와 노력의 꾸준함이 우리가 선택한 개발자라는 직군에게 필요한 핵심 역량 중 하나라는 것만 유념하고, 성장에 대한 다양한 고민과 노력을 기울인다면 훌륭한 시니어로 성장할 수 있지 않을까 싶다.