
해가 바뀌고 올해엔 어떻게 공부해야하나 하는 고민을 많이 했다. 그래서 개발자 커뮤니티에서 사이드 프로젝트 팀을 찾아 들어갔고, 운영체제, 컴퓨터 구조 스터디도 매주 하고 있다.  
그럼에도 약간의 막막함은 사라지지 않던 차에, 오픈소스 강의로 유명한 Udemy에서 지속적인 성장을 하고자 하는 개발자를 위한 웨비나가 있다고 하길래 냉큼 신청했다. 듣고 느낀 점을 휘리릭 적어본다.

[Udemy 지속 성장하기 위한 개발자의 학습법](https://okky.kr/article/1154436)

## TDD의 철학으로 이해하는 피드백 주도 학습 방법 by Maker Jun 멘토

TDD란 '테스트를 먼저 만들고, 실제 코드를 작성하고, 원하는 대로 동작하는지 빠르게 피드백을 받는 것'을 말한다. 한국어로는 테스트 주도 개발이라고 한다.  
이러한 개발을 하기 위해선 **결정과 피드백 사이의 갭**을 인식하고, 그 **갭을 조절하기 위한 테크닉**이 필요하다.  
해야하는 것(결정)과 테스트 결과(피드백)의 차이를 줄여 최종적으로 해야하는 것=결과 가 되도록 만드는 것이다.

## TDD가 필요한 이유

TDD가 필요한 이유는 딱 한 문장이 설명해준다. **"만약 내가 던진 농구공이 들어갔는지 1달 뒤에 알 수 있다면?"**  
아마도 기다리다 지칠 것이다. 어쩌면 내가 농구공을 던졌다는 사실 자체를 잊어버릴 수도 있다.  
TDD를 한다는 것은 농구골대에 공을 던져 그 공이 들어갔는지, 안 들어갔는지 바로 확인하며 코드를 짜는 것과 같다.  
Maker Jun 님은 계산기를 예로 드셨다.

### TDD 방식대로 계산기 구현

<img src='/images/blog/2202/ds2.jpg'/>

일단은 특별한 UI 없이, 계산기의 주 목적인 사칙연산이 되는 코드만 짠다.  
그리고 그 코드가 테스트를 통과한다면 다음 단계로 넘어간다.

<img src='/images/blog/2202/ds3.jpg'/>

두번째로는 최소한의 UI를 만들고 사용자 입력을 받아 이벤트 처리하는 부분을 구현한다.  
그리고 또 피드백을 하고, 덧붙이고, UI 전체 레이아웃을 잡고, 스타일을 입히고...

테스트 개발의 핵심은 **분할 개발**이다!!!  
이런 식으로 결정과 피드백 사이의 괴리를 줄여가면 MVP(Minimal Viable Product)를 만들 수 있게 된다.

### 우리는 피드백 주도 학습을 하자!

Maker Jun 멘토님은 테스트를 먼저 만들고 개발하는 TDD처럼 우리가 피드백 주도 학습을 해야한다고 말하셨다.  
TDD처럼 나의 부족한 점을 정의하고 피드백을 해 그 약점을 고칠 수 있는 것부터 하나하나 공부를 하자는 거다!  
이 때 중요한 것은 **내가 지금 가지고 있는 지식으로 가장 작은 영역부터 해결해나가는 것**이다.

### 내가 적용할 것

가장 먼저 나는 프론트 엔드 개발을 할 때 UI부터 다뤘는데, 그러면 안된다는 것을 깨달았다.  
UI 먼저 할 게 아니라 내가 구현해야하는 것을 확실히 결정하고 테스트 코드를 기반으로 개발을 해야하는 것이었다.  
JS면 콘솔에서 가볍게 테스트를 하는 건 어떨까?  
리액트가 어떻게 돌아가는 지와 어느정도의 구현법은 잘 알지만, Redux를 자유롭게 쓰지는 못한다.  
그러면 일단 Redux의 다큐먼트를 보고 내가 모르는 부분을 찾아서 그부분부터 시작하면 되는 거다.  
중요한 건 내가 해야하는 걸 내가 해결할 수 있는 범위 내에서 최대한 잘게 쪼개는 것이었다.  
개발자로서 배워야하는 어마어마한 양의 기술과 라이브러리에 압도되곤 하는 나같은 주니어 개발자에게 꼭 필요한 조언이었다.

## 개발자 : 지식의 저주 by Poco Jang 멘토

<img src='/images/blog/2202/ds4.jpg'/>

대부분의 사람들은 본인이 알고 있다면 상대방도 알고 있을 것이라 생각한다.(Chip Heath의 '스틱' 중에서)  
그래서 그 지식을 공유할 필요가 없다고 생각해 기술 블로그를 잘 쓰지 않는다.   
또 "개발자로서 배워야할 것은 많은데 기술은 계속 변하잖아요. 이게 의미가 있는 건가요?"라고 묻는다.  
많이 알게 되면 내가 모르는 게 계속 보여 압도당하기도 한다.

### 아는 만큼 보인다

<img src='/images/blog/2202/ds6.jpg'/>

여기서 또 나오는 **메타 인지**! 내가 아는 것, 모르는 것을 잘 구분할 줄 아는게 중요하다.  
채용 공고에서 겹치는 게 **트렌드 기술**이다.

### 마음가짐의 중요성

<img src='/images/blog/2202/ds7.jpg'/>

왼쪽 사진의 물컵을 보고 '반밖에 못 채웠네'라고 하는 사람이 있고 '반이나 찼네!!'라고 하는 사람이 있다.   
회사의 구인공고를 볼 때도 '난 반밖에 못 채웠네... 지원하지 말자'라고 생각하지말고, '난 반이나 할 줄 아네!'라고 생각하자.

### Poco Jang 멘토님이 말하는 것

<img src='/images/blog/2202/ds5.jpg'/>

1. 컴퓨터 공학은 일종의 학문이다. 더 이상 개발을 얕보지 말자. **어려운 학문임을 인정하자.**
2. '1시간 만에 00앱 만들기', '3개월 만에 XXX 개발자로'... 등 **인스턴트 학습의 유혹에 빠지지 말자**. 쉬워보이는 교육 컨텐츠에 익숙해져 평생 따라만 하지 말자.
3. "언젠가는 이해하겠지" 대충 넘어가지 말고 러닝 커브를 극복하자. 고통스럽지만 완벽하게 이해하도록 노력하자.
4. 지름길은 없다. 나만의 학습 로드맵을 그리자. 어차피 선택에 대한 책임은 내가 진다.
5. 모범 사례만 찾지 말고 **모범 사례가 되자.**
6. **포기할 이유를 찾지 말자.**

### 내가 적용할 것

내가 원하는 직무의 자격요건과 우대 사항 등을 보고 필요한 기술 스택, 경험의 교집합을 수집하자.  
그리고 그에 맞는 지식과 경험을 쌓자.

### 웨비나가 끝나고

거의 2시간 진행됐는데 멘토님들이 즐겁게 진행해주시고 질문에 잘 대답해주셔서 좋았다.
들으면서 계속 나한테 하는 말 같았다. 나만의 로드맵을 그려보자!!!


더 나은 개발자가 되기 위해 나는 어떻게 공부해야할까?

개발자의 공부

'개발자의 공부'에 관한 글들을 모아봤어요.

개발자로서 지속 성장하기 위해서 나는 앞으로 뭘 어떻게 해야할까?