10월 구름톤 트레이닝 세미나 내용 정리, 온라인 참석

🍂10월 구름톤 트레이닝 세미나 안내

[Session 1]

• 주제 : 구름 IDE 개발 프로세스 및 개발자들이 일하는 방식
• 일시 : 2023.10.20.(금) 15:30~16:50
• 강사 : 구름 IDE 테크 리더 Mac

[Session 2]

• 주제 : [Part2] 개발자로의 성장 : 기본기
• 일시 : 2023.10.20.(금) 17:00~18:30
• 강사 : 구름 대표이사 Wayne

이번 달도 구름에서 세미나가 열려서 이번에는 온라인으로 참석했다!

오프라인으로 참석하신 스터디 팀원분들이랑 직접 인사는 못해 아쉬웠지만 온라인으로 참석해 세미나에서 좋은 정보 들을 수 있었다.

 

---

[Section 1]

현업에서 제품을 만드는 과정

 

개발자가 갖추어야 하는 역량

개발 = 사용자의 문제를 해결

1. 요구 사항의 기술적 검토
2. 기능 구조 설계
3. 기능의 구현

 

개발만이 아니라 문서 작업이 많음

 

개발 역량만큼 소통이 중요하다

다른 직군들과도 잘 소통

 

• 소통 -> 사람마다 받아들이는 게 다를 수 있음

 

서로 잘 소통이(align) 되었는지 확인, 반복이 필요

 

서로의 소통의 차이를 줄일 수 있다 = 사용자가 원하는 제품을 더 잘 만들 수 있다

사용자의 문제를 해결하기 위한 공동의 목표를 효율적으로 달성하기 위해 최선을 다하자

 

= 개인플레이보다는 협업을 잘하자

이어 달리기

 

• 성장을 멈추지 마라

Silver Bullet: something that very quickly and easily solves a serious problem

 

Q & A

기술 스택?

• 기술 스택이 다를 때 유심하게 보는 부분 ⇒ 기존 스택을 어떤 방식으로 공부했고, 새로운 스택을 접했을 때 빠르게 적용할 수 있을까

CI/CD 툴에서 Jenkins를 쓰는 이유?

• 현재 많은 사용자가 있고, 알람 기능 등이 있는 좋은 점

개발사항 구현에 필요한 공수 측정은 어떻게 하시나요?

• 공수 측정을 잘하려면 다양한 개발을 많이 해보는 방법밖에 없음
• 설계를 해보고 다른 개발자와 논의(리더급, 테크 리더)
• 공수 설정한 것과 실제 업무시 공수 측정이 다르면 “왜” 다른지 생각해 보기(계획 고민) ⇒ 실제 performance와 맞춰나가기

개발 공부 책 or 인강?

• 좋은 인강이 많음
• 인강을 듣고 이후에 책을 통해 자세한 내용, 깊숙한 내용들 확인

번아웃 관리?

• 안 좋은 생각들이 올 때 생각을 안 하고 내려놓으려고 한다.

갈등?

• 의견 충돌이 나는 상황에서 리더는 빠른 의사결정이 필요할 때 리더 의견을 따라달라고 하고, 시간이 충분할 때는 충분히 의사소통을 진행하고 넘어가려고 함

문서 정리

• 플로우가 있어야 그에 따라 개발하기 좋다
• 여러 가지 분기 나눠서
• 시간이 짧을 때 문서 작성이 어렵지만 프로젝트 기간 이후로라도 문서 작성을 해놓는 것이 좋다

---

[Section 2]

개발자에게 필요한 능력?

수학 x, 어린 나이에 시작 x, 학위 x

 

: 반복과 체득

(책만 봐서는 안된다)

10,000 시간의 법칙

 

8시간 x 1200일 = 9600시간

나는 실패하지 않았다. 단지 1000가지 방법을 찾아냈을 뿐

 

체득하는 법

→ 오랜 시간이 지나도 해보라고 하면 몸이 자동으로 할 정도 = 체득

→ 어려운 문제를 많이 겪을수록 체득은 많아진다.

→ 도전 = 정면으로 맞서 싸움을 걺

 

도전의 혜택

drilling

 

개발자에게 중요한 역량

 

• 기술적 능력
• 커뮤니케이션
  • 같이 일하고 싶다 → 자신도 느낀다
  • 디자이너, 기획자, 영업, 프론트/백엔드 등과 소통
• 팀워크 + 리더십
  • 사회는 조직사회
  • 주어진 문제를 자기 주도적으로 팀원들과 협력하여 풀어가는가
  • 좋은 리더십과 좋은 팔로우십(⇒ 리더십으로 이어짐, 잘 따르는 사람이 좋은 리더가 됨)
• 영향력 → ‘이 사람 없으면 이 프로젝트 안 돌아간다’
  • 직책
  • 외부 커뮤니티 활동
  • GitHub Star 등
• 포트폴리오 및 경력
  • 포트폴리오 = 그동안 해낸 Trace → 권위를 만들어 줌(권위는 실력으로부터 나옴)
  • 따르고 싶은 리더 = 성공적인 프로젝트를 많이 해본 사람
• 성장 잠재력
  • 성장하지 않으면 회사와 멀어질 수밖에 없다
  • 1년을 했지만 앞으로의 5년이 보이는 사람

 

+) 엔지니어는 문제를 해결하는 사람이지만 내가 원하는 방식이 아니라 고객이 원하는 방식, 다른 방식으로 해결할 수 있다. 현실적으로 본인이 하고자 하는 일을 못하게 될 수 있음.

⭐️ 대표님이 항상 강조하시는 MVP 모델

 

개발자로서의 성과는 어떻게 인정받을 수 있을까?

 

Q & A

성장잠재력을 어떻게 보여줄 수 있을까?

• 빠르게 프로젝트 진행한 능력 등등

성장하는 사람과 그렇지 않은 사람의 차이?

• 포기하지 않고 열심히 하는 사람들은 될 때까지 한다.
• 계속 반복하고 시도
• 거듭된 실패 속에서 성공을 해본 경험이 있는 사람('하다보면 되겠지' 믿음이 있는 사람이 체득을 잘함)

가장 좋아하는 프로그래밍 언어가 무엇이냐고 물어보면 '저는 00 언어가 좋지만 다른 프로그래밍 언어도 레퍼런스를 참고해 보면 할 수 있습니다.'라는 답변이 Best ⇒ 말랑말랑한 성장잠재력, 생각이 갇혀있지 않은 사람이 같이 일하고 싶음

 

회사를 선택하는 기준?

• IT 회사는 리더급이 엔지니어 출신이 있으면 좋다고 생각.
• 세상에는 개발자와 비개발자라는 표현이 있다.

 

개발자의 잦은 이직

• 초반경력에 너무 많이 이직하지 마라. 차라리 초반에 준비해서 가고 싶은 회사를 가라.
• 이력서 검토 시 이직이 너무 잦으면 좋지 않음.
• 특별한 일이 없으면 이직을 할 때 너무 많은 공백기를 가지지 마라. 커리어 연속성이 나타날 수 있도록 하는 게 좋다.

 

세미나를 들으면서 제 나름대로 정리한 내용이라 빠진 부분들이 있을 수 있습니다.

 

궁금했던 내용도 듣고 한 달에 한 번 다시 동기부여 받기 좋은 세미나였다 :)