운 좋게 추첨이 되어서 다녀온 점핏의 개취콘
온라인으로만 참석했다가 이번에 처음으로 오프라인으로 참석하는 기회가 되었다.

4/30일 일요일에 열린 컨퍼런스지만 한 달이 조금 더 지난 6월 4일 정리하는 글을 적어보려고 한다.

발표 내용 전부보다는 마음에 들어서 메모했던 것 위주로 쓰려고 한다.
각색이나 내 생각도 들어가 있을 가능성 다분.

프론트엔드 개발자의 소프트스킬과 하드스킬세션과 협업?! 이렇게 한번해봐세션을 포스팅할 예정이다.

FE개발자의 소프트스킬과 하드스킬 - 김태곤 개발자님

💡 능력은 Hard Skills과 Soft Skills이 합쳐졌을 때 나오는 것이다.

• 코드는 영원하지 않습니다.
  • 코드는 늙기도 하고, 시간이 지나면 저절로 고장 나기도 한다.
  • 시간이 지나면 오류가 생길 수도 있고 작동하지 않을 수 있다.

그러므로 좋은 코드를 작성하는 것이 좋다. 좋은 코드는 유지보수를 쉽게 하려면 좋은 코드를 작성해야 한다고 하기도 한다. 하지만 좋은 코드는 개인마다 조직마다 정의 or 의미가 다를 수 있다.

• 좋은 코드는 무엇일까? 어떤 조건을 갖춰야 할까?
  1. 테스트가 용이할 것
     1. class나 함수 안에 많은 기능이 들어가 있을 때, 그 안에서 오류가 생긴다면 찾기가 쉽지 않다. 이때는 함수를 나눠서 테스트할 수 있다. (기능별 / 비동기일 때 / 액션 / 패치 등)
  2. 읽기 쉬울 것 / 가독성을 잃지 않기
     1. 주석 역시 보조하지만, 코드가 명확한 것이 좋다. 변수, 함수의 이름을 길게 적어도 좋다. (명확해야 함)
  3. 일관성을 유지하자.
     1. 변수, 함수, 네임 컨벤션, 구조 등 같은 규칙을 적용한다.
  4. 테스트코드는 가능한 부분부터 시작하자(TDD)
     1. 버그가 생긴다면 그것에 대한 테스트 코드를 만들자 → 이후에 같은 버그가 생길 가능성 상승(. 회귀 버그)
     2. 처음부터 테스트 코드를 작성하기는 어렵지만 가능한 부분부터 시작하는 것이 좋다. 작은 단위라도 Chat GPT한테 테스트 코드를 작성시켜 보자.
     3. 장애 회고 좋은 방법 같음 → 내가 현재 작성하고 있는 에러노트랑 비슷할 것 같고 요긴하게 쓰일 것 같다.
  5. 한 커밋에는 한 가지 문제만 올리자
     1. 자주 / 잦게 올려도 된다.
     2. 추적하기 쉽게 만들어야 한다.
  6. 실험은 한 번에 하나씩만 하자

개발 / 학습 방법론

• 나에게 맞는 학습루틴을 찾자.
  • 개발자는 어차피 평생 공부를 때문에 자신만의 학습루틴을 찾는 것이중요하다.
  • 언젠가 본 적이 있는 글인데, 어떤 것을 튜토리얼이나 블로그글, 공식 문서든 자신에게 맞는 것이 있다. 내가 어떤 것을 찾는데 그것이 어렵거나 이해하지 못했다면, 다른 자료를 찾는 것이 도움이 될 것이라고 하는 것이었다. 어쩌면 이것이 맞을 수도 있겠다고 생각한 것이. 어떤 개념을 찾아보더라도 뭐라고 하는지 이해 못 할 때가 많지만 결국 그게 무슨 소리인지 이해도 못 하고 계속 들여다볼 때가 생기는 것이었다. 빨리 포기하고 다른 자료를 찾아보자.
• 가장 좋은 공부 방법은 누군가를 가르쳐 주는 것이다.
  • 발표도 좋은 방법인 것 같다.
  • 나는 주로 러버덕 디버깅을 유용하게 쓰는 편.
• 옳은 기술은 없고 상황에 따른 선택이 있다. 그만큼 클린코드에 대한 원칙도 다르다.
  • 그런만큼 나는 어떤 생각을 가지고 있는지 정리할 필요가 있다고 생각했다.
• FE인 만큼 UX(User experience)에 대해서도 공부하자 .
• 풀 스택 엔지니어링 지식을 익히자. 하지만 지향점은 아닌 것을 명심하자.
• 거절하는 방법(‘안 된다’라는 말은 그만하자.)
  • 숙고 / 고민하는 척
  • 대안 제시 (말도 안 되는 대안도 괜찮다)
  • 기간이나 돈의 문제라면 % 을 올려서 제안해도 된다. 그것을 하지 않거나 혹은 금액을 올려서 받거나 기간을 늘려줄 수도 있다.

커리어 관련

• 이직은 항상 준비하기
  • 이력서 업데이트는 6개월에서 1년에 한 번씩 하자
  • 면접을 보면서 연습. 되도 좋고 안되도 좋다!
  • 다니던 회사에서 무엇을 배웠는지 추가하기.
• 커리어 = 시간 + 스토리 (어떤 성장을 했는지)
• 성과급 + 복지 < 연봉 (이직 시 중요하다)
  • 복지가 없을 땐 연봉을 올리자.
• 자기 기술이 메인이 되는 회사에 가자
  • 기술 비용을 줄여야 할 경우 메인이 아닌 것부터 사라질 가능성이 높다.
• 용이 꼬리가 낫다.
  • 뱀의 머리는 배우는 것이 없고, 나의 밑천이 드러나는 중인 것이다.
  • 내가 배울 것이 없을 때 떠날 것. 그리고 내 주변에 나보다 잘하는 사람이 많은 곳으로 가자.
• 실무능력 = 프로그래밍 스킬(구현) + 도메인 지식(문제정의) + 커뮤니케이션(협업)
• 가능한 한 작게 시작하자
  • 이것저것 많은 것 패턴 새로운 기술 등을 더하게 되면 나중에 수습이 불가하다.
  • 더하는 것보다 빼기가 어렵다 (KISS, YAGNI)
• 새로운 기술을 이용해 같은 것을 만들면 더 쉽게 이용할 수 있을지도?
• 작게 나누어 정복하자
  • 일정 같은 것도 작게 나누면 일정 추적이 용이하다.

추천도서

구글엔지니어는 이렇게 일한다.
프로그래머의 뇌
오늘도 개발자가 안된다고 말했다.

JUMPIT TO FRONT-END 다시보기
김태곤 개발자님
블로그
트위터

후기

이곳저곳에서 주워들었던 것들은 한곳에서 모아서 들은 기분이다. 어설프게 알고 있던 지식과 방법들을 좀 더 명확하게 알게 되는 시간이었고, 새로운 이야기도 많이 들어서 생각이 확장되는 기분이었다.
사실 모든 내용이 거를 게 없어서 어떤 게 딱 잡아서 좋다! 라고 하기 오히려 어려웠다.
나 같은(앞날이 한 치 앞도 보이지 않고, 내가 하는 것이 잘하고 있는지) 주니어 개발자들에게 추천해 주고 싶다.
김태곤 개발자님과 커피 챗해보고 싶다. 좋은 이야기나 나에게 도움이 되는 이야기를 맞춤으로 들을 수 있을 것 같아서 상상만으로도 두근두근한다. 제 멘토님이 되주세요..
위의 글은 발표자님의 내용을 정리 한 것이지만, 내 생각도 들어가 있어서 읽으시는 분들에게는 헷갈릴 수 있을 것 같다. 위의 영상 다시 보기 하는 것을 추천해 드린다.