개발자로서 '성공'하고 싶다면 한 번씩 봐주셨으면 합니다.

들어가기 앞서

당신이 만약 지금 이런 상태를 가지고 계신다면 이 글이 도움이 될 것 같습니다.

• 지금 하고 있는 나의 개발 공부 방법이 잘 하고 있는 것인가 확신히 들지 않는 사람에게
• 이론이든, 알고리즘이든, 프로젝트든 다 해야할 거 같아, 하나에 분야에 제대로 집중하지 못하고 컨텍스트 스위칭이 빈번한 사람에게
• 난 열!심!히 살고 크게 한번 성공해보고싶다!(돈많이벌고싶다, 명예를 가지고싶다) 라는 사람들에게

2023년 10월쯤, 개발자의 공부 방법에 대해서 글을 작성했었던 적이 있었습니다.

그때에 비해서 세상도 많이 바뀌었고 나도 많이 바뀐 듯 합니다.

과거의 글을 읽어보며 생각보다 비효율적인 방법에 부끄러운점도 있었으며 나름대로 "아 그땐 그랬지" 하고 스스로 다시 멈췄던 습관을 이어 나가기도 했습니다

개발자 공부 어떻게 해야될까요?

이번 글은 시간이 지나며 바뀐 저의 마인드 셋, 공부 방법 그리고 성장에 대한 노하우등등에 대해서 얘기해보려고 합니다.

이 글에서 여러분들이 제가 앞으로 적을 많은 진리들중 '딱 하나'만이라도 진리를 가져가셨다면 저는 성공했다고 생각하겠습니다.

개발자 공부 어떻게 해야될까요?

다양한 개발자/학생들의 공부 방법을 집계해 특성별로 두개로 그룹핑을 해보면 대강 다음과 같은 그룹들로 분류되는 것 같습니다.

1. 일단 만들어보고 모르는 지식들을 골라 공부하기
2. A~Z 까지 모든 지식을 알기위해 거대한 사전을 갖고 천천히.

뭐가 정답 같은가요?

정답은 없다! 와 같은 진부한 얘기를 할것 같았다면 애초에 이 글을 쓰지도 않았습니다.

1번으로 하시면 됩니다.

여러분들도 아마 많은 개발자 선배, 선생님 혹은 교수님 혹은 유명한 개발자들의 발언속에서도 1번에 정답이라는 것을 이미 깨우치고 있을것같습니다.

그런데 하기가 힘들죠? 아래와 같은 생각들이 드니까요

1. "뭐 이미 이런식으로 동작 하겠지.. 굳이 빌드까지 해야..."
2. "이런 케이스에 이런것도 고려하면 이것저것 더해야하고 귀찮은 작업만 많아지고.."
3. "난 아직 이런 개념이 부족한데... 문서 몇번만 더 완독하고 할까"

네 저도 공감합니다. 프로젝트 세팅, 디자인, 예외케이스 고려, 부족한 아이디어 등 귀찮아서 던질때도 있고 개념 부족으로 인한 불안감으로 문서와 책을 더 바라보게 됩니다.

뭐 나쁜건 아닌데, 일단 저 케이스들마다 일단 만들어야하는 이유를 하나씩 반박해보겠습니다.

3번 부터 반박해볼게요 "난 아직 이런 개념이 부족한데.." << 정확히 어떤 개념이 필요하고 어떤 부분이 얼만큼 부족한지 알고계시나요? 그렇다면 좋습니다 당장 책을 피세요. 그렇지만 웬만해서는 다들 그렇지 않을 것 같습니다.

대강 처음듣는 단어들이 몇개보이니까 대강 지식에 대한 무지를 블랙박스로 보고 어렵다라고 판단하시게 될 것입 니다. 그리고 책을 펴도 어떤게 필요한지. 어떤게 핵심인지 확인하기 어렵습니다.

인간의 뇌는 지식을 습득할때, 문제를 제시하고 그 문제를 해결했을때야 가장 오래동안 저장이 됩니다. 물론 자기 자신의 전화번호처럼 의미도 없는 숫자를 무식하게 많은 반복으로 외우는 것도 방법일 수 있겠지만 너무 비효율적입니다.

그래서 결론은 개념공부를 진행할땐 내가 지금 당장 어떤것이 필요한지 그리고 이걸 왜 해야하는지 why를 제시해야합니다. 나에게 지금 무엇(what)이 필요한지는 나의 탐색범위를 좁혀줄 것이고 why는 자기 자신의 동기를 유지시켜줘 책을 빨리 덮지 않게 해줄것입니다.

결과적으로 일단 무언가를 만들다보면 막히는 부분이 무조건 있을 것이고, 보이지 않는 무지의 블랙박스가 화이트박스로 변하게 될 것입니다. 네 무엇을 내가 모르는지 정확하게 인지하게 되는것이죠.

일단 지금 뭘 만들고싶은게 없다면 단순한 게임이라도 만들기를 추천드립니다. 유명한 개발자중 리누스 토발즈(Linus Tovalds) 도 어렸을 적 단순한 게임을 만들며, 컴퓨터 구조에 대해 흥미와 궁금증을 가졌고 결과적으로 전세계에서 가장 뛰어난 개발자중 한명이 되었습니다.

일단 빨리 Hello World부터 찍으세요 시간이 반입니다. 요즘엔 인공지능에 발전으로 이러한 시작의 진입 장벽을 더욱더 낮춰가는 세대가 되었습니다. 최대한 많은 why와 what을 찍어내서 당신의 뇌속 문서에 대한 탐색엔진을 튜닝해보시는걸 추천드립니다

만약 연습용으로 만드는 프로젝트를 하려고 했다면, 이미 당신이 이 프로젝트에 동작을 다 예측이 가능하다고요? 아 네 좋습니다. 그럼 다른 부류의 프로젝트를 시작해보세요. 예를들어 원격 캐시에 관련한 강의를 듣고 만들어 보려하는데 이미 강의로 들은 지식으로 인해 굳이 실습할필요 없어보인다구요? 그럼 로컬캐시로 만들어보세요.

You aren't gonna need it

제가 좋아하는 개발자 원칙입니다. YAGNI(You aren't gonna need it) 원칙

"프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 익스트림 프로그래밍(XP)의 원칙"

"프로그래머가 필요하다고 간주할 때 까지" << 그렇습니다 우리는 하나의 의사 결정에 대해 정말 필요한가라는 생각을 해야합니다.

근데 종종 이런 분들이 자주 보일때가 있는데, 개발자스럽게 오버 엔지니어링입니다.

프로그래머가 필요하다고 간주할 때 까지 라는 문장에서 프로그래머가 적절하게 필요하다고 현실적인 이유와 수치해석으로 결정함. 이라는 전제가 깔려있는 것 같은데 이게 지적 허영심이나 발생하지도 않을 트래픽과 유저스토리를 휴리스틱(쉽게말해 대강 감으로)하게 결정하는 실수들이 많이 보입니다. 그럼 이 원칙은 전달하고싶은 바가 깨져버리게 되는것이죠.

이건 뭐 개발자로서 빵점을 뚫고 마이너스 백만점입니다. "요즘 빅테크 기업들이 많이 쓴데ㅠ", "와 이거 진짜 신의 오픈소스야!(써본거 이거밖에 없음)"

네.. 제가 하고싶은말은 솔직히 how는 개발자들이 고민할 것 중에 우선순위가 가장 낮습니다. 실제로 why와 what이 가장 중요하죠 프로덕트 개발을 진행하신다면 일단 가장 먼저 직면하신 도메인 문제를 풀어나가주셨으면 합니다. how는 이미 팀내에서 증명된 익숙한 솔루션들을 쓰는게 좋지 않을까 웬만해선 네

높은 고퀄리티와 깔끔한 ui/ux의 모니터링 솔루션?, 빅테크 기업들이 사용하는 솔루션들과 기교들? 제 개인적인 생각으론 터미널과 화이트보드 만으로도 성공하는 소프트웨어를 개발할 수 있다고 생각합니다.

조직이 늘어남에 따라 수치적으로 현실적으로. 진심으로 필요하다고 생각하실 때, 확정적인 문제가 예측이 되지 않고 대강대강 발생하지 않을까? 싶을때는 의사결정을 하지 않아주셨으면 합니다.

네? 신입이라 이력서에 그럼 쓸게 없다구요? 빅테크 기업들이 사용하는 솔루션들을 사용해서 프로젝트를 진행했는데, 회사에서 면접질문으로 이걸 결정한 이유가 무엇인가요? 에 대해서 계속해서 패배하신다구요?

"~에 인터페이스가 익숙해서, 리소스를 작게 설정해서 사용했다.", "미래의 확장 가능성을 생각했을때 OO만큼에 성장지표가 나왔다. 그래서 OO를 썼다.", "연구 목적으로 사용했다" <<< 뭐 이런 내용이 나올 수는 있도록 의사결정을 해보십쇼 웬만해서는 사용하지 않는다가 정배일것같긴한데, 이미 만들어 버렸다면, 이유라도 어거지로 꺼내서 만들어보죠(일단 취업이 먼저니까ㅋㅋ)

기록/회고

어떤 선배 개발자 분이 저에게 말씀을 해주신바가 있습니다. 나는 블로그에 단순 개념만 정리하고 그러는것보단 진짜 핵심을 파고들며 회고하고 퀄리티가 좋은게 한두개 있는 애들이 플러스가 되더라.

음 틀린말은 아닙니다. 근데 살짝 반대하는 점도 있습니다. 저는 기록장을 꽤 오랫동안 작성을 했고 github에서 운영중입니다 (star 250) https://github.com/rlaope/estudy

다들 만약 저 기록장을 한번씩 보고 오셨다면 아시겠지만, 기초적인 개념들도 적혀있는게 있고 조금 짬뽕되어있는 내용도 있으며 딥한 연구내용도 다 섞여있습니다.

저는 솔직히 간단한 지식이라도 규모가 거대해진다면 즉 아주 많이 작성하게 된다면 결과적으로 이것도 플러스가 된다고 생각합니다. 전 이 기록장으로 아주 많은 기회를 얻기도 했으며 취준생시절 취업에 도움이 된적도 있었습니다.

결과적으로 상대방에게 와~! 를 심어줄 수 있게 전략을 짜는게 좋은데, 굳이 처음부터 딥한 게시글을 작성하려다 보면 너무 힘들수가 있어요. 그래서 저는 간단한 개념부터 시작합니다. 그렇게 간단한게 여러개 나무를 심다보면 결과적으로 숲이 완성이 되더라고요.

저도 이 노트를 작성해나가면서 확신이 들지 않아 잠시 끊어볼까도 싶었지만 간단한 내용 만이라도 일단 작성해봤습니다. 그러던 어느날, 슬슬 내가 작성하는 글마다 내용이 더욱 깊어지며 더욱 작성도 쉬워지고 양도 더 많아졌습니다.

기록을 누군가에게 보여주는 목적으로 하는것도 아니긴 하지만, 적어도 자랑할만 하다면 자랑하는게 나에게 도움이 될수도 있다고 생각해서 얘기를 해봤습니다. 누군가에게 보여주지 않더라도 핵심은 이겁니다. 작은것부터 간단하게 써나가다보면 그 씨앗들은 언젠간 숲을 이루게 될 것입니다.

그리고 개념 기록과 별개로, 회고를 진행하는 것입니다.

저는 개인적으로 회고라고 엄청 거창하게 몇천줄 가까이 되는 책을 작성하라는게 아닙니다. 간단하게 한두문장만이라도 분기마다 이런게 문제였고 앞으로 다음 분기는 이렇게 지내보자라는 생각을 갖고 전략을 세우셨으면 합니다.

저희 팀에 경력이 꽤 오래되신 동료분께서 일은 시도와 시련, 그리고 회고의 싸이클로 성장하고 성공해나간다는 말씀을 해주신적이 있습니다.

자신이 지금 어디에 있는지, 어느게 문제인지 스스로 깨닫지 못하면 문제 개선은 이루어질 수 없습니다.

회고에 대한 진입장벽이 있으신 분들은 제가 진행하는 다음과같은 방식의 프레임워크를 추천드립니다.

wins-woops-wow 라는 프레임워크인데 저는 분기마다 아래와 같은 카테고리로 3문장씩 씁니다.

• WINS - 이번 분기에 잘한 것
• WOOPS - 아쉬웠던 점, 다음엔 더 잘할 수 있는 것
• WOW - 놀라웠던 점, 예상치 못했던 배움/발견

쓰는데 5분정도 걸리는 것 같은데 저는 대충 이렇게 쓴거같습니다.

지피티로 탬플릿 만들어달라하면 잘 만들어주니까 md로 관리해보는것도 은근 꿀팁입니다.

결론

요약을 조금 해드리겠습니다. 3가지에 대한 대주제로 내용을 작성한 것 같은데 각 주제마다 제가 가장 전달해드리고싶은 핵심을 전달드리면

1. how보단 why, what순으로 (일단 만들고 why를 많이 생산하기)
2. 합리적인 판단, "이게 무조건적으로 필요하지 않을 것 같은데요?"
3. 기록, 슬로우 스타트, 하지만 끝은 압도적으로

사실 한 내용마다 글 여러개를 쓰고싶었지만 하나의 글로 쓰려다보니 축약되고 전달되지 못한 내용들도 있어 아쉽긴한데, 일단 핵심만은 전달할 수 있었던 것 같습니다.

애초에 내가 잘 성장하고 있나, 불안함을 느낀다는 것 자체가 잘하고 있는 증거라고도 볼 수 있습니다.

일단은 뭐.. 이거 다 읽으신분들은 알아서 잘 하시는 분들일것이라고도 생각이 되네요 ㅋㅋ

다들 열심히 또 효율적이게 개발하고 꼭 좋은결과만 있으며 압도적으로 성공하셨으면 좋겠습니다.