시험 기간이라 공부하는데 더 이상 학점이 필요 없다보니 집중이 너무 안 돼서
잠시 기분 좀 환기할 겸 써보는 가벼운 글입니다.
개인적인 주관이 가득하게 들어간 글이지만, 이런 글이라도 필요하신 절박한 분들을 위해 작성합니다.
📕 목차
1. EDD/RDD
2. 목표를 잡아라
3. 계획을 세워라
4. 실천에 옮겨라
1. EDD/RDD
📌 개요
최근들어 뭘 공부해야 할 지 도저히 모르겠다고 찾아오는 사람이 많았다.
학부생들이야 그렇다 쳐도 현직자 분들은 대체 왜 저 같은 거한테....🙄
이 글은 절대 내가 잘나서거나, 뭐 대단한 사람이기 때문이 아니라는 점. 그저 계획을 세우는 방법을 공유하려는 것 뿐이다.
예전에는 그런 사람들에게 혼자서 블로그를 만드는 사이드 프로젝트를 해보라고 권유했었다.
UI는 그냥 저작권 없는 다른 플랫폼에서 가져오고, 개발에만 집중하면 프론트부터 백까지 광범위한 지식을 얻을 수 있다고 생각했기 때문이다.
그런데 이 이야기를 족히 20명한테는 한 거 같은데, 겨우 1명만 하길래 요새는 별로 권하지 않는다.
아무래도 나처럼 순수하게 코딩을 즐기는 사람이 좀처럼 없기 때문인 거 같긴 한데,
여튼 남에게 도움이 되지 않을 조언을 주는 것도 별로 내키지 않았다.
그러다가 슬슬 취준을 위해 시동을 켜고 있을 때 주워들은 말이 있는데, 그것이 바로 EDD(혹은 RDD)였다.
더 작성하기 전에 미리 이야기해두고 싶은 게, 나는 이력서 주도 개발을 기반으로 공부하지 않는다.
이 글은 코딩 그 자체를 순수하게 즐길 수 있고, 이 일을 사랑하는 사람들에겐 해당하지 않는다.
어차피 그런 긱한 사람들은 본인이 할 일을 알아서 자체 생산하고 있을 텐데, 뭘 굳이..
그렇지만 내 공부 계획은 어쩌면 EDD와 비슷했다고 생각한다.
그래서 목표를 정하고, 계획을 세우는 방법에 대해 공유하는 게 주 목적이다.
📌 EDD(이력서 주도 개발) / RDD(Resume Driven Develop)
그냥 말 장난에 불과하다.
이력서(or 포트폴리오)에 내가 가고 싶은 회사에서 요구하는 인재 혹은 적어도 내가 취업 전에 되고 싶은 이상적인 나의 모습을 기반으로 적어두고, 정말 그렇게 되기 위해 공부하는 전략이다.
그래서인지, EDD를 해보라고 권유하면 대부분이 농담인 줄 알고 웃는다.
하지만 현실적으로 따졌을 때 국내 기업 중에 개발자의 철학을 따지는 곳이 얼마나 있을까.
대기업은 스스로 양성하면 되니, 코테랑 CS 지식, 인성 검사를 주로 확인하고, 규모가 작은 스타트업일 수록 바로 실무에 투입 가능한 사람을 찾던데.
대기업을 노리는 거라면 개발 공부가 아니라 코테랑 CS 지식만 줄창 공부하면 된다.
거짓말 같겠지만 내가 지금까지 봤던 대기업 입사자들은 코딩 실력이 월등한 사람이 아니라, CS 지식과 코테 실력이 탄탄한 사람이었다.
다만, 개발 잘 하는 사람들이 보통 두 가지 모두 해당하는 경우가 많을 뿐.
한국은 programmer가 아닌, frameworker를 많이들 찾는다.
그러니 어쩌면 EDD를 하기에 최적의 환경을 갖추고 있다고 생각한다.
그리고 생각해보면 EDD가 주는 장점 또한 명확하다.
- 뚜렷한 목표가 존재한다.
- 목표를 위한 객관적인 기준을 세울 지표가 존재한다. (회사에서 요구하는 기술 및 우대 사항 참고)
- 목표를 달성하기 위한 데드라인 존재 (원하는 취업 시기)
2. 목표를 잡아라
📌 목표를 어떻게 잡을 것인가?
나는 내가 졸업 전까지 배우고 싶은 기술과 해보고 싶은 활동들을 나열했었지만,
EDD라면 그보다 훨씬 쉽게 목표를 잡을 수 있다.
그냥 회사 채용 공고를 확인해보면, 거기서 이미 내가 공부해야 할 게 무엇인지 모두 알려주고 있다. ㅋㅋㅋ
그런데 직군마다, 회사마다, 그리고 또 도메인 마다 요구하는 기술이 달라진다.
그래서 최소한 본인이 가고 싶은 직군 정도는 스스로 정해야 한다. (이거까지 어떻게 해야 할 지 모르겠다고 한다면, 더 이상 내가 해줄 말이 없다..나는 모든 걸 다 해보고, 백엔드를 하기로 결정했었다.)
이제 원하던 목표가 생기긴 했는데, 솔직히 처음 보면 막막하기 그지 없을 것이다.
그래서 보통 여기서 다들 포기하던데, 중요한 건 이 다음부터.
📌 이상적인 나를 포트폴리오에 작성하라
자신만이 생각하는 미래의 모습이 있을 것이다.
오히려 EDD에서는 속물적으로 생각하는 게 더 도움이 될 지도?
그런 자신의 모습을 상상하여 포트폴리오를 작성해보면 된다.
근데 너무 과하게 느껴지거나, 아니면 열심히 부풀려봤지만 이 정도로 취업할 수 있을까? 싶을 텐데, 걱정하지 마시라.
당신의 모니터 한 쪽에 켜져 있어야 할 채용 공고가 기준을 정해주고 있으니.
그리고 지금은 좀 과장되어도 좋다.
어차피 목표를 너무 낮게 잡지 않는 이상, 달성하지 못 할 확률이 크기 때문.
(솔직히 신입한테 쿠버네티스 경험을 묻는 이유를 아직도 난 잘 모르겠다.)
3. 계획을 세워라
📌 현실과 이상의 간극 확인하기
대부분 여기서 극심한 현타를 맞이한다.
뭐, 어쩔 수 있나...받아들여야지.
EDD가 쉽다는 말은 한 적이 없다.
포트폴리오에 작성한 이상적인 나는 현실의 나와 엄청난 괴리가 존재할 것이다.
그렇다고 현실을 부정하면 안 되고, 반드시 직시해야 한다.
그래야 올바른 계획을 세울 수 있기 때문이다.
현재 내가 확실히 아는 것과 알아야 하는 것들을 전부 나열해보자.
📌 분기 별로 배울 것들을 분류하라
개인적으로 거시적인 계획과 미시적인 목표는 모두 존재해야 하지만, 취급을 조금 달리할 필요가 있다.
거시적인 계획을 디테일하게 작성하려 하면, 대부분은 도중에 포기하게 될 것이다.
그리고 뭔지도 모르는 내용들을 현재 시점에서 정확히 계획한다는 게 애초에 불가능하다.
그러니 거시적인 계획은 추상적이어도 좋다고 생각한다.
나같은 경우엔 처음에는 연도 별로 내가 배우고 싶은 내용과 하고 싶은 활동들을 정리했다.
그리고 한 해가 끝났을 때, 적어도 이 정도 수준까지는 올라가 있을 것이라는 기대치를 작성했다.
조금 더 세부적으로 나가서, 한 해에 배우기로 한 내용들을 또 분기별로 쪼갰었다.
EDD를 실천할 사람이라면, 배워야 할 기술 스택들을 위와 같이 나눠보면 된다고 생각한다.
📌 가장 세부적인 계획은 분기 시작점마다 생각하라
미시적인 계획은 보다 체계적으로 진행해야 한다.
다만 다음 분기의 일들, 내년 일들은 모두 무시해도 좋다.
그저 이번 분기에 내가 해야 할 일들에 포커싱하자.
얾...사실 위 시간표는 내가 생각해도 가장 광기 그 자체였던 작년 여름 방학 때의 모습이긴 한데,
그냥 하루 종일 공부만 했던 것 같다.
개발보다는 개발을 본격적으로 시작하기 전의 베이스 지식을 최대한 쌓아두는 것이 해당 분기의 목표였기 때문에, 개발 시간을 매우 적게 편성했었다. (심지어 안 했을 때도 많았음)
하다보면 계획이 뭔가 잘못되었다 싶은 경우도 있을 것이다.
예를 들어, 지금 배우기엔 너무 이른 내용이라거나, 공부하는 데 시간이 더 필요하다고 느끼는 것들 등등
그런 건 계획을 조금씩 수정해나가면서 조정하면 된다.
1년의 계획을 세우는 것보단, 반 년의 계획을 세우는 게 쉽다.
반 년의 계획보단 한 분기의 계획을 세우는 것이 쉽다.
최종 목표를 위한 작은 목표와 계획들로 나눠서 각개 격파한다는 느낌으로 하면, 조금은 공부하는 게 즐거워질 수도 있다.
근데 보통 이 쯤 이야기하면, 나더러 변태라고 이야기 안 들어주던데 슬프네.
4. 실천에 옮겨라
📌 실천에 옮기지 않을 계획은 무의미 하다
사실 이 파트가 가장 쓸 말이 없다.
앞서 말했다시피 나는 그냥 코딩을 하는 것으로 즐거움의 원동력을 얻는 사람이라 거의 무한 동력으로 공부할 자신이 있기 때문...
심지어 번아웃이 올 뻔 했을 때도 코딩을 쉰 적은 없었다.
그래도 이런 나도 가끔은 지루한 공부를 할 때가 있긴 했으니, 그 때마다 어떻게 했는지라도 써보려 한다.
📌 Connecting the dots
내 주변 사람들에게 항상 하는 말이 있는데, "세상에 쓸모없는 지식은 없다"는 것이다.
개발을 한 번도 해본 적 없는 사람이 CS 지식을 공부해보면, 대체 이걸 언제 써먹는 건데 싶을 것이다.
그런데 나는 개발과는 전혀 상관 없어보는 UX와 기획과 관련한 공부도 해봤다. (물론 이건 재밌어서 했다.)
그 때 주위 사람들이 "백엔드 개발자가 될 거라면서, 그런 걸 공부해서 어디 쓸 거냐?"라고 했고, 솔직히 반박할 수는 없었다.
그저 이런 지식마저 필요한 순간이 올 것이라는 믿음만이 있었을 뿐.
결과적으로 어떠했는가?
- 안드로이드를 개발할 때 MVVM 클린 아키텍처에서 나오는 Use Case가 무슨 의미인지 알 수 있었다.
- 운영체제에서 동시성을 다루는 기법으로 다중화된 서버 환경에서 데이터 베이스에 접근할 때 생기는 동시성 문제를 해결할 수 있었다.
- 단순히 리뷰 속도를 향상시키기 위한 목적으로 도입했던 작은 PR룰 덕분에, 작업의 관심사를 분리할 수 있었고, 이는 개발하는 시점에 이점을 주기도 했다.
- TDD에서 말하는 사전 조건과 인수 조건 따위의 용어가 기획에서부터 나온다는 사실 또한 알 수 있었다.
- 디자인 팀과 이야기 할 때 단순히 기술적 구현 가능성이 아닌, UX 관점에서 무엇이 더 낫고 정책적으로 어떤 것들이 필요한 지 대화가 가능해졌다.
모두가 쓸모 없을 거라 했지만, 우습게도 단 하나도 쓸모 없던 게 없었다.
점 지식이 하나로 이어질 때의 쾌감을 아는가?
장담컨데, 이 맛에 한 번 취해보면 절대 끊지 못 하게 될 것이다.
📌 비슷한 수준의 실력과 열정을 가진 동료를 찾아라
내가 스터디를 할 때마다 많이 실망스러웠던 점은 나와 비슷한 수준의 열정을 가진 사람이 너무 적었다는 점이었다.
그러다 보니, 스터디가 진행될 수록 성장률의 차이로 인해 점차 스터디가 아닌 멘토링이 되어 갔다.
경험 상, 혼자보단 함께 하는 것이 학습 지속성을 유지하는 데 도움이 된다.
그렇지만 실력 혹은 열정이 크게 차이나는 인원이 있다면 과감히 배제하는 것이 좋다.
📌 결론
나는 철학이 없는 개발자를 별로 좋아하진 않지만, 그렇다고 실리적인 이유로 공부하는 사람을 싫어하지도 않는다.
코딩이라는 분야를 찾기까진 정말 많은 분야에 대해 몰입해봤고, 그러다 찾은 나의 적성이었기에 이렇게 즐겁게 할 수 있을 뿐. 도저히 애정할 수 없는 분야를 공부하라고 한다면, 내가 이 포스팅을 읽고 있는 사람이었지 않았을까 ㅋㅋㅋ
여튼 개발자를 준비하는 모든 사람 뿐만 아니라, 모든 사람이 자신만의 꿈을 이룰 수 있었으면 좋겠다.