6/17일 오전 김태곤님 특강 "프론트엔드에서 이것만은 알았으면 좋겠다."

코드쓰는사람 https://taegon.kim/
링크드인 https://www.linkedin.com/in/taggon/

능력 = Hard Skills + Soft Skills

Hard Skills - 기본 프로그래밍 등 업무에 직접적인 관련된 스킬
Soft Skills - 협업자 간의 커뮤니케이션/보고/글 작성 등의 스킬

솔직히 개발자에게 하드 스킬은 솔직히 30~50% 정도만을 차지한다.
우리는 개인 개발자가 아닌 업체의 개발자로 취업을 위하기 때문에 소프트 스킬에도 비중을 두는 것이 중요하다.

그리고 커리어를 잘 관리하는 사람이 취업에 유리하다.

시간 위를 걷는 프로그래밍

시간이 지날 때마다 기능이 추가되기도 하지만 기능이 삭제되기도 하는 등 프로그래밍은 변하기 때문에 "시간 위를 걷는 프로그래밍"이라고 하신 듯하다.
예를 들면 예전에 10줄로 쓰던 코드가 시간이 지나면서 새로운 코드이 생겨 2~3줄 안에 쓰는 것도 있다.

좋은 코드/개발자의 조건

1. 테스트가 용이할 것

• E2E 테스트 프레임워크
  cypress - https://www.cypress.io/
  playwright - https://playwright.dev/

사람마다, 조직마다 다른 부분이다.
예를 들어 하나의 함수를 생성했을 때 한 줄로 설명할 수 있는 것이 좋은 코드이다.

• 테스트 할 수 있는 코드를 늘려라!
  실질적으로 테스트를 할 수 없는 코드가 있을 수 있다. fetch, 클릭 이벤트 등의 코드들은 에뮬레이션(조다희님 : 하드웨어적으로 수행되는 작업을 소프트웨어로 흉내내어 처리하는 방식)할 수 없기 때문에 이를 테스트 할 수 있는 코드로 기능을 작은 단위로 세분화(함수로 기능 분할)하는 과정을 거치면 에러를 발견하기 쉽고 방지하기 쉽다.

2. 읽기 쉬울 것

회사는 보통 팀으로 일하기 때문에 내 코드를 다른 사람이 보거나 다른 사람의 코드를 받아서 일하는 경우가 많다.
하지만 이 과정에서 남의 코드를 이해하지 못하는 경우(예를 들면, 읽기가 힘들고 함수명과 변수명도 명확하지 않는 경우)도 빈번하다.

안좋은 함수의 예 - processData, clear, reset
추천하는 이름 : normalizeResponseData, splitBookDataByCategory

그러니 코드의 의도를 명확히 드러내기 위해 변수/함수명 등이 길어지더라도 사용하는 것이 팀 업무에서 쌍방으로 도움이 된다!
또한 회사에서 허용한다면 한글로 작성하는 것도 좋은 방법이다!

3. 테스트 코드는 가능한 부분부터 작성하라

"사용자의 상상력은 개발자의 상상력을 훨씬 뛰어넘는다."

솔직히 테스트 코드를 작성하는 시간이 없을 수 있다. 하지만 테스트 코드 작성에 아예 손을 놓으라는 의미는 아니다.
"태곤"님의 경우 버그가 생겼을 때 테스트 코드를 작성하신다고 한다(인간의 기억력은 한계가 있기도 하고 개발에 습관이 있기 때문에). 이를 통해 나중에 똑같은 버그(회귀버그)가 생겼을 때 해결하기 쉽다.

"리펙토링(기능은 그대로, 코드는 더 효율적으로)"은 "TDD의 시작점"이다.

• 리펙토링 2판 (마틴 파울러 저) 추천

4. 가능한 "한 커밋"에는 "한 가지 문제"만 할 것 - 추적 가능하게 유지하기

"실험(프레임워크 변경 등)은 한 번에 하나씩만 - 고생 = (학습 프로젝트) 2"

한 커밋에 여러가지 문제를 넣는다면 코드에 문제가 발생했을 때 커밋의 히스토리를 살펴보게 되는데 그때 코드의 의도를 읽기가 힘들고 많은 수의 데이터를 살펴봐야하는 불편함가 있다.

그러니 작은 단위(한 가지의 문제)로 커밋을 하는 것을 습관화하는 것을 권장한다.

5. 나만의 학습 루틴을 만들어둬라

"어처피 평생 공부해야 합니다."

사람마다 학습방법이 다르다. 그래서 정답이 없기 때문에 본인에게 맞는 학습방법을 찾아서 루틴으로 만들어라!
"태곤"님의 경우 레퍼런스를 한번 읽고 냅다 만들어보는 것을 선호한다고 하셨다.

"영어"는 반드시 꾸준히 공부해야하는 것이다! 특히 "Reading"은 필수이다.
힘들겠지만 영어를 번역하는 연습을 해보는 것을 추천한다.
특히 Reading은 "최신 기술의 습득"에 좋은 영향을 끼친다.

6. 대체로 옳은 기술은 없다. "상황에 따른 선택"이 있을 뿐이다.

알면서도 비효율적인 선택을 해야할 때가 있다. 그러니 감정적인 스트레스를 받지 말 것을 명심하라.
개발자마다 생각이 다르기 때문에 코드에는 정답이 없다.
예를 들면 "클린 코드"가 누구에게는 "읽기 쉬운 코드", 다른 누구에는 "간결한 코드"를 가리키는 것처럼..

만약 정말 사용할 기술들이 마음에 안든다 싶으면 방법 두 가지

• 총대를 매고 다 엎을 각오를 할 것
• 퇴사

7. 프론트엔드 개발자는 절반쯤은 UX 전문가가 되어야 한다 - 코드 너머에 사용자가 있다.

프론트엔드가 만든 웹은 "사용자의 입장"에서 생각해야하는 부분이 많다.
보통 "프론트엔드는 그냥 기획자나 디자이너가 짜주는 대로 만드는 것 아닌가"라는 생각을 가지고 있지만 이렇게 하면 그저 "코드를 짜는 개발자"의 수준밖에 되지 않기 때문에 만약 사용자의 불편이 발생할 수 있는 디자인 등 UX 요소를 프론트엔드 선에서 발견하면 적극적으로 참여해서 의견(커뮤니케이션 시도)을 어필할 것을 권장한다.

프론트엔드가 UX에 신경을 쓴다면 보는 시야를 넓힐 수 있다.

8. 풀스택 엔지니어링 지식은 익히되 풀스택 엔지니어를 지향하지마라
   "하나 잘하기도 점점 어려워지기 때문에 전문 분야를 가지는데 리소스를 쏟아라"

사람의 에너지는 한정적이다.
물론 풀스택 엔지니어링 지식을 알고 있는 것은 본인한테 도움이 되지만 실무적인 퍼포먼스를 낼 수 없다면 풀스택이라고 말하는 것은 지양하는 것이 좋다.

9. "안 된다"라는 말은 그만하라

"시간과 돈을 앞세우자"

개발자는 디자이너나 기획자에게 불가능하다는 말을 많이 한다.
근데 만약 이렇게 되면 다른 팀원들로부터 부정적인 개발자라는 시선을 받을 수 있다.
그래서 되도록 구현에 깊이 생각/고민을 해보고 개발에 적당한 "시간"과 "비용"을 주장하며 상대방과 협의을 해볼 것을 권장한다.
이렇게 된다면 협의에서 상대방이 결정을 내려야하는 부분(결정의 책임을 전가)이 된다.

10. 거절의 3단계

숙고 -> 대안 제시 -> 이득

기술적으로 심사숙고 해보고 기술적/비용면에서 불가능하다면 협의를 해보고 대안을 제시하고 거절이 되거나 구현할 기능이 줄어들면 이득이다.

🔥 실무팁 - 거절할 때 비용은 "본인이 하기 싫은 정도"를 더 부과해서 주장할 것!

11. 이직은 늘 준비하는 것

"이직을 반드시 하라는 것이 아닌 이직을 항상 준비하고 있으라는 의미"

갑자기 팀이 없어져서 나가게 되는 경우 등 다양한 이유로 퇴사할 이유가 생기기 떄문에 이런 상황을 대비하기 위해 내가 가진 스킬을 점검을 자주 해보고 채용 공고도 자주 찾아보는 것을 추천한다.
그리고 이직 준비를 항상하고 있으면 "회사에서 받는 스트레스"에 조금 덜 예민해진다.
참고로 채용 공고를 자주 보면 시장에서 현재 지향하는 트랜디한 스킬을 찾아볼 수 있다.
그리고 이직을 위해 필요한 이력서도 주기적으로 업데이트하는 습관을 가지는 것이 좋다.

이직할 때 볼 것 : 커리어 / 연봉 / 워라벨

"커리어"가 좋아지면 "연봉"이 올라가고 좋은 조건으로 취업에 유리하다.
하지만 "워라벨"은 주니어 입장에서는 신경안쓰고 해보는 것을 권장한다. 어처피 고생은 한번 해봐야 깨닫는 것이 많다.

• 커리어은 "시간 + 스토리"이다.
  스토리와 발전없는 연차는 마이너스이다. 시간이 흐르면서 나의 스토리가 얼마나 잘 다듬어지는지에 대한 정도
  스토리가 좋아지면 자동으로 커리어도 좋아지는 경우가 많다.

• 연봉은 성과급/복지보다 연봉을 선택하라
  회사 입장에서 성과급이나 복지를 주장하며 연봉을 후려치는 경우가 많기 때문에 무조건 연봉을 선택하는 것이 좋다.

• 가능하다면 자신의 기술이 메인으로 사용되는 회사로 가는 게 좋다.
  만약 내 기술이 회사의 메인 스킬이 아니라면 회사가 위험할 때 우선순위를 통해 회사를 나가야하는 경우가 발생할 수 있다.
  커리어 면에서도 자신의 기술이 메인인 것이 더 좋다.

12. 뱀의 머리보다는 용의 꼬리가 낫다.

"하드캐리할 자신 있으면 예외"

13. 호인과 호구는 다르다.
    무리한 부탁을 받았을 때 다 받아주지말고 거절할 때는 정중하게 거절할 것!

14. 독서하듯 코드를 읽자

프레임워크의 변화 등을 자주 봐두는 것은 매우 좋은 습관이다.
예를 들면 nullish 같은 연산 스킬 등이 있다.

15. 문제는 시스템으로 예방하자
    Linter, Formatter, TypeScript, SCM, 버전을 롤백할 수 있는 Git 등 좋은 tool이 많으니 불편함을 겪는다면 이용하는 것이 개발자의 스트레스를 줄일 수 있기 때문에 권장한다.

16. Repeat Yourself

DRY(Don't Repeat Yourself)이라는 말이 있지만 "좋은 반복"도 있다.
"좋은 반복"은 "효과적인 학습"이 된다.
예를 들어 "자바스크립트"로 구현한 앱을 "리액트" 등과 같은 프레임워크로 다시 만들어보는 반복 학습은 스킬업하는데 효과적인 방법이 된다.

17. Divide and Conquer(작게 나누어 정복하라)

프로젝트 일정이 길수록 예측하기가 어렵지만 전체 프로젝트를 작은 단위로 나누어 개발하라.
테스트 측면에서도 유리하나 확장면에서도 매우 유리하다. 그리고 문제가 발생하면 그 부분만 해결하면 된다.

18. 질문에도 기술이 있다.

질문을 할 때, "어떤 것을 해봤는데 안되었는지", "어떤 에러가 발생했는지" 등 자세하게 질문하는 것이 좋다.
질문이 무섭더라도 "묻지않아서 사고치는 것"보다 "부끄럽더라도 질문하고 배우는 것"이 더 낫다.

15분 구글링 법칙 = 15분 동안 구글링을 해보고 만약 해결책을 찾을 수 없다면 동료에게 도움을 요청하는 법칙
하지만 "15분 구글링 법칙"처럼 본인이 문제를 해결하려 노력을 했다는 것을 알려주고 요청하는 것이 질문을 받는 입장에서는 나에 대한 부정적인 이미지를

19. 시간은 금이다.

내 시간도 중요하지만 상대방의 시간도 중요하다.
그러니 나의 시간을 효율적으로 사용하고 상대방의 시간을 효율적으로 사용하는 방안을 생각하길 바란다.

20. 너무 열심히 안 살아도 된다.

학습에 체력이 떨어져 번아웃이 오는 경우가 많다.
하지만 이렇게 생각하자.

"어제보다 나은 사람이면 충분하다"

21. 전문가 얘기를 너무 많이 듣지 말자

"내 문제는 내가 제일 잘 안다"

남의 얘기를 많이 들어봤자 시간이 지나면 내가 전문가보다 더 자세히 아는 분야가 생긴다.
전문가 얘기를 절대적으로 맹신하지말고 본인이 직접 경험한 것을 믿을 것이 좋다.
자신에 초점을 맞춰라!

---

Q&A

• 000 님 : 아까 독서하듯 코드를 읽자고 하셨는데, 보통 어디서 코드를 찾아서 읽으시는 편인가요?

https://github.com/trending

하루마다 스타를 가장 많이 받은 레포지토리를 볼 수 있는 깃허브 페이지.
본인이 관심있는 키워드 등을 기준으로 하루마다 보다 보면 도움이 될 수 있다.

• 000님 추천 링크
  https://javascriptweekly.com/
  https://react.statuscode.com/
  https://frontendweekly.co/

또한 해외 테크 트렌드 소식을 볼 수 있는 것을 구독해서 받아보는 방법도 좋다.

• 000님 : 오토매틱은 원격근무라는 개념을 만든 최초의 회사로 알고 있습니다.

국내 다수의 스타트업들이 워드프레스 원격근무 문화를 참고해서 원격근무를 도입하고 있는 것으로 알고 있는데 원격 근무의 장/단점을 알려주시면 훈련생 분들이 회사를 지원할 때 도움이 될 듯 합니다!

예시) 원격근무 100% 회사 지원시 고려해야될 점

원격근무의 장점은 시간활용이 자유롭다. 다만 실질적으로 출근하지 않아 오직 결과물로 평가를 받기 때문에 시간 활용을 마음대로 해서는 안된다.
단점은 업무하는 과정이 외롭고 신입 개발자의 경우 멘토가 없기 때문에 성장하기가 힘들다.

• 000님 : 혹시 평상시에 기록하시는 루틴이 있으실까요? 저는 기록자체를 잘 안하던 사람이라... 블로그 글부터 쓰려니 조금 막막하구 힘들더라구요....!!
• 허지현님 : 개발자가 블로그를 운영해야 할 이유 https://taegon.kim/archives/7107

개발자는 글쓰는 능력이 중요하다고 생각하는 편이다.
(못들었당..ㅎ)

• 000님 : 저희가 앞으로 팀프로젝트를 시작하는데 사람마다 에너지와 능력이 다를거라고 생각합니다.
  그래서 상대적으로 누군가는 더 많은 개발을 맡을테고, 누군가는 상대적으로 적은부분은 개발을 맡아서 할 수도 있을것 같은데 어떻게 팀프로젝트 업무를 나누면 좋을지 그리고 하루에 얼만큼에 시간을 투자하는것이 적절할까가 궁금합니다..!

적은 부분을 맡은 구성원은 자신의 성장을 위해 많은 부분을 시도해볼 것을 추천한다.
어처피 잘하는 구성원은 많은 부분을 할 수 밖에 없다.

코드리뷰를 적극적으로 해볼 것을 권장한다. 코드리뷰는 "지적하는 것"이 아닌 "피드백을 주는 것"이라는 것을 명심해라.
그리고 개발에 미숙한 사람의 코드에 정답을 주는 것보다 피드백을 주고 스스로 학습하는 계기를 주는 것이 좋은 방법이다.

• 000님 : 코드리뷰의 시간은 어느정도 쓰는게 좋을까요?

이건 개인이 설정할 수 밖에 없다.

• 000님 : 말씀하신 소프트 스킬들을 어떻게 이력서에서 드러낼 수 있을까요? 혹시 그런 스킬들이 있을까요?

커뮤니케이션 스킬(내가 작성한 코드를 잘 설명할 수 있는 기술), 폐관수련하듯 묵묵히 홀로 문제를 해결하려고 하지않고 꾸준히 자신을 알리며 도움을 주저없이 청하는 것도 커뮤니케이션의 능력 중 하나이다.