[udemy] 프론트엔드 개발자 성장 가이드

 

First session

 

TDD의 철학을 적용해보는 피드백 주도 학습 방법

- 메이커준

 

TDD 장점

난이도를 잘 조절할 수 있게 됨

=> 스트레스를 관리할 수 있게 됨

=> 에너지 관리를 할 수 있게 됨

=> 기분 좋게 변화하는 짜릿함을 느낄 수 있다

 

TDD란?

Test Driven Development

저서 '테스트 주도 개발' - 켄트 벡

테스트를 먼저 만들고, 테스트를 통과하기 위한 코드를 짜는 개발 방법

ex. 생년월일을 입력 받아서 나이를 출력해주는 프로그램

 

테스트를 먼저 만들고, 실제 코드를 작성하고, 원하는 대로 동작하는지 빠르게 피드백을 받는 것

=> 테스트 코드는 의도치 않은 유용한 부산물 / 핵심은 더 자주, 더 빨리 '피드백'을 받는 것

 

결정과 피드백 사이의 갭을 좁히기

결정 - 내가 시도하려는 것

피드백 - 성공 / 실패

ex. 농구공을 던졌는데 내가 던진 공이 들어갔는지 1달 뒤에 알 수 있다면?

 

Q. 인터넷 강의를 보며 이론적인 건 이해를 해도 실제 개발을 하려고 하면 뭐부터 해야할지 모르겠어요

A. 1. 내가 해결할 수 있는 가장 작은 영역부터 풀어나가며 피드백 받기 (단, 핵심 포함하게)

    ex. 계산기 : 핵심 기능부터 생각 - 사칙연산 - 필요한 최소한의 숫자 2개 => 2개의 숫자를 다루는 계산기부터 만들기

          1. ui 없이 사칙연산이 되는 것만 먼저 빠르게 만들기(콘솔로 찍으며 동작 되는지 피드백)

          2. input으로 사용자 입력 받고 이벤트 처리하기(최소한의 ui)

          3. 숫자 UI 추가하고 이벤트 처리하기

          4. ui 레이아웃 잡기

          5. 스타일 입히기

 

TDD의 핵심적인 사고 방식인 결정과 피드백 사이의 갭을 줄이는 방법으로 학습 전략을 개선해 보자.

 

아는 즐거움 < 변화하는 즐거움

 

second session

 

개발자: 지식의 저주

- 포코

 

지식의 저주 : 내가 아는 것을, 남도 알 것이다. => 대부분의 사람들은 본인이 알고 있다면 상대방도 알고 있을 것이라 생각한다.

이때 상대방이 나 자신이라면? => 안다고 착각하는 상황

개발자들은 본인이 알고 있다고 생각하는 경우가 있다.

알고 있다고 생각하는 기준은 뭘까

 

메타인지

자신의 인지 과정에 대해 관찰 · 발견 · 통제 · 판단하는 정신 작용

 

가고 싶은 회사들의 채용공고를 많이 보는 게 중요

- 공통적인 부분을 뽑아 컵으로 보고 내가 얼마나 해당되는지 컵에 든 물로 비유해 생각해볼 수 있음

 

아는 만큼 보인다.
많이 알게 되니 내가 모르는 게 계속 보인다.
알면 알수록 앞으로도 배워야 할 것들이 계속 있다.
배워야할 것들이 너무 많아 압도된다.
=> 본인이 얼만큼 아는지도 모르겠고 회사가 원하는 기준도 모르겠다
=> 기술은 계속 변하는데 의미 있는 건지 모르겠다.

 

지식의 저주 탈출하는 방법

1. 컴퓨터 공학은 일종의 학문이다.

더 이상 개발을 얕보지 말고 어려운 학문임을 인정하자.

2. 인스턴트 학습의 유혹에 빠지지 말자.

쉬워 보이는 교육 컨텐츠에 익숙해져 평생 따라할 순 없다.

ex. 1시간만에 xxx 만들기, 영어 원문은 무시한 채 한글 검색 결과만 찾는 행태...

3. 언젠가는 이해하겠지

대충 넘어가지 말고 러닝 커브를 극복하자

고통스럽지만 완벽하게 이해하도록 노력하자

4. 지름길은 없다.

나만의 로드맵을 그리자

어차피 선택에 대한 책임은 내가 진다.

5. 모범 사례가 될 것인가.

모범 사례만 찾는 하이에나가 될 것인가.

실패를 두려워하면 성공할 수 없다.

6. 포기할 이유를 찾지 않기

스스로 한계를 만들지 않기

합리화 하지 않기

실천하자 그리고 꾸준히 하자

 

요약

1. 지식의 저주에 빠진 건 아닌지 지속적으로 점검하자.

2. 아는 만큼 보인다.

3. 메타 인지 능력을 향상하자.

4. 하지만 압도되지 말자.

 

약속

1. 더 이상 개발을 얕보지 말자.

2. 인스턴트 학습의 유혹에 빠지지 말자.

3. 완벽하게 이해하고 넘어가자(No Pain, No Gain)

4. 나만의 로드맵을 그리자. 선택에 대한 책임은 내가 진다.

5. 모범 사례가 되자.

6. 포기할 이유를 찾기 금지, 합리화 금지 => 꾸준히 실천

 

QnA

1. UI 먼저? 기술 먼저?

(메이커준) 가장 핵심적인 것을 먼저(계산기는 로직이 핵심) UI가 핵심이면 UI 먼저 구현

(포코) 사용자가 만지는 부분부터 먼저(UI 먼저) 작업하는 것을 선호

=> 자신만의 방법을 만들어 나갈 것

 

2. TDD에서 테스트 코드를 먼저 작성하는 것과 뒤에 작성하는 것의 차이

(메이커준) 테스트 코드를 먼저 작성하는 것 : 더 빨리 피드백을 받을 수 있음

(포코) 코드부터 만들고 테스트하면 답정너와 비슷함(실패하는 테스트 코드가 안나올 수 있음) 테스트 코드를 먼저 작성하는 게 좋음

 

3. TDD 코드를 통합할 때 어려움이 있진 않은지?

(메이커준) 피드백을 받으며 개발하면 자연스럽게 기존 작성 코드가 리팩토링 되므로 통합이 쉬워질 가능성이 큼 그러나 상황에 따라 다를 수 있음

 

4. 어떤 개발자가 좋은 개발자로 평가 받는 지 기준을 모르겠음

(포코) 함께 일하기 좋은 개발자(내가 못하는 걸 개발한다거나, 공유를 잘 한다거나...), 성과를 이륙한 개발자

(메이커준) 아주 상대적인 개념. 각자 본인만의 기준을 3가지 정도 세우는 것이 좋을 것(회사마다 다를 수 있고...)

 

5. 개발에 재능이 없는 것 같고 내 길이 아닌 것 같다...

(포코) 본인보다 잘하는 개발자가 중학생이었던 경우, 스터디에서 잘하는 사람들이 더 노력하는 걸 봤던 경우 현타가 왔었다. 강연 내용에 있어 답은 생략하겠다.0

(메이커준) 어떻게 하면 더 효율적으로 학습할 수 있을 지, 장점을 효과적으로 살릴 수 있을 지 많이 고민 했다.

 

6. 유지보수 업무를 할 때 성장하는 방법

(포코) 본인이 1인분을 할 수 있는지 점검해보고 회사에 어필을 해볼 것.

(메이커준) 회사에서 모든 걸 해결하려고 하지 말고 당장 시도할 수 있는 것부터 해볼 것

 

7. 뷰 할 줄 아는데 리액트 해야하나? 기술 하나 할 줄 아는데 다른 기술을 해야하나?

(메이커준) 본인이 불안해서 이런 고민을 하는 것으로 보인다. 뷰 잘하는데 리액트 안해봤다고 떨어뜨리지는 않을 것이다. 지금 하고 있는 걸 어떻게 하면 더 잘하고 잘 표현할 수 있을 지 고민해보면 좋을 것 같다.

(포코) 이걸 극복을 못하면 합리화를 하게 된다고 생각한다. (ex내가 뷰를 해서 저 리액트 하는 회사에 떨어진 거야) 막상 뽑아서 다른 거 시키는 회사 정말 많다. 뭘 바꾸려고 하기보다 본질에 집중하는 게 중요하다.

 

8. 현직 개발자가 현업에서 개발을 하는데 있어서 완벽하게 해내야만 하나요? 공부를 하는 데 있어서 정말 많은 막힘과 어려움이 있어서 질문 드립니다.

(포코) 어쩔 수 없이 완벽하게 하기 위해 노력해야 한다.

(메이커준) 누구나 완벽할 수 없기 때문에 피드백을 통해 노력하는 것이 중요하다. 큰 결함들을 어떻게 하면 더 빠르게 탐지할 수 있고 방지할 수 있을지...테스트 코드를 이용하는 이유도 같다.

 

9. 프론트엔드 개발자로 지속적으로 성장하고 싶은데 어떤 것을 바라보고 능력을 향상 시켜야 할지 고민다.

(포코) 뒤도 봤으면 좋겠다. 옛날의 못했던 나를 보며 환기할 수 있는 시간으르 가졌으면 한다.

(메이커준) 본인이 원하는 모습을 그려봤으면 좋겠다.

 

10. 주니어에서 시니어로 가는 과정에서 필수적으로 알아야 하는 지식이나 필요한 역량은 무엇이라고 생각하시나요?

(포코) 없다고 생각한다. 같은 기술이 다른 회사에선 주니어로 통할 수도 있고...메타 인지가 중요하다. 내가 지금 이 회사에서 주니어인지 시니어인지 당연히 느낄 수 밖에 없다. 용두사미로 들어가서 1인분이라도 해야지 하고 노력하며 점점 올라간다던가..

(메이커준) 연차나 나이로 나뉘는 게 아닌 것 같다. 시니어는 주니어보다 훨씬 더 복잡하고 어려운 문제를 해결할 수 있는 역량을 갖는 것이라고 생각한다. 내가 생각했을 때 나는 지금 어느정도 수준의 문제를 해결할 수 있는지, 내가 해결했던 문제는 어느정도 수준이었는지 판단하는게 중요하다고 생각한다. 해외에선 연차를 물어보는 사람도 없고 아무도 신경쓰지 않기 때문에 본인이 어느정도 수준의 문제를 해결할 수 있는지에 집중하는 게 맞는 것 같다.

 

11. 새로운 기술에 대한 대처 방법?

(포코) 프론트엔드 기술이 요새 많이 편리해졌다. 리액트 같은 기술들이 점점 훌륭해지고 있기 때문에 그걸 잘 사용하면 되는 시대에 와 있다고 좋게 생각했으면 좋겠다. '새로운 기술이 이래서 좋구나...'하고 느끼는 식의...모든 기술이 상향 평준화 되고 있는 시대다. 무임승차 한다는 느낌으로 배울 수 있는 기회라고 생각했으면 좋겠다.

(메이커준) 이렇게 불안하고 뭘 학습해야할 지 모를 때일수록 본질에 집중해야 한다. 소프트웨어의 본질은 문제 해결이다. 결국 도구에 불과하다. 문제 해결을 하기 위한 더 좋은 도구들이 계속 나오고 있다고 생각했으면 한다. 이 문제 해결을 하기 위해 가장 효과적인 도구는 무엇일까? 하고 탐색하면 오히려 새로운 기술이 더 반가울 수 있다. 나는 어떤 문제를 해결하고 싶어하는지 많이 생각했으면 좋겠다.

 

---

느낀 점

켄트 벡 - 강연, 정리한 글 등 찾아보기

ui 제작부터가 아닌 핵심 기능부터 만들어보기

인스턴트 학습은 정말 뜨끔했다.

자신을 좀더 믿고 선택을 소중히 하자.

포기하지 않고 꾸준히!!!!!! 하는 자세의 중요성을 잊지 말자.