OKKY의 4월 세미나 '개발자, 어떻게 성장하는가' 후기

영상 링크 :

https://www.youtube.com/watch?v=3jkDAeahXes 

 

 

OKKY의 4월 세미나로 국민대학교 이민석 교수님의 개발자, 어떻게 성장하는가? 영상을 시청했다.

1시간 30분 영상으로 상당히 길다고 생각했지만 들을 수록 점점 솔깃한 내용이어서 흥미로웠다.

 

와 닿았던 내용 정리:

[개발자의 성장이란 무엇일까?]

 

1. 잘 성장하고 있는 개발자 자가진단

    - 언제 시작했는지도 모르게 코딩하곤 한다.

    - 최근에 새로운 언어, 도구, 수학 개념을 배운 것이 있다.

    - 관심 있게 보고 있는 오픈소스 프로젝트가 몇 개 있다.

    - 지난 6개월 동안, 커뮤니티에서 발표를 해 본 적이 있다.

    - 나는 누군가의 멘토이며, 또 누군가의 멘티읻.

    - 개인 프로젝트 리파지토리와 문서를 잘 유지하고 있다.

    - 전에 작성한 내 코드가 너무 깔금해서 감동한 적이 있다.

    - 코딩/개발에 쓰는 시간이 주당 몇 시간인지 알고 있다.

    - 내가 참여하고 있는 프로젝트의 전체 구조를 잘 설명할 수 있다.

    - 내가 배포한 소프트웨어의 사용자 피드백에 귀 기울이고 있다.

 

2. Computational thinking 훈련이 필요하다. -> '사람'의 위대함과 '컴퓨터'라는 멍청하고 수동적인 기계 사이의 갭 메우기이다.

 

3. 디테일은 역시 누군가가 만들기는 하지만, 우리는 불러서 쓰는 거다.

 

4. 알고리즘은 Coding Test를 통과할 수준까지 '토익처럼' 공부하자.

    - 정답 보는 걸 두려워하지 말자. 패턴을 익히는 것이 중요하다.

    - 하지만 이해하고, 코드를 직접 짜봐야 한다. 그렇지 않으면 면접 때 털린다.

    - 현업에서는 예쁘게 짜고 CPU 값, 메모리 값, 클라우드 사용료가 내리기를 기도하자.

    - 알고리즘을 잘 짜는 것보다 데이터와 아키텍처를 잘 설계하는 것이 중요하다.

 

[성장에 관한 오해]

 

1. 문제풀이식은 정답 학습으로는 성장할 수 없다.

    - 학습 동기와 몰입, 배움의 열정과 진정성으로 역량이 성장한다.

 

2. 재미는 과정이 아니라, 좋은 성과나 보람이다. '재미가 있는지'를 판단하는 시점이 틀렸었다.

    - 재미를 느끼고 동기를 지속적으로 유지하려면 성취의 단계를 더 잘게 나누어야 한다.

    - 재미와 재미 사이의 간격을 줄여야 한다.

 

[학교는 학교다.]

 

1. 학교는 학교고, 부트캠프는 부트캠프다. 현장을 능가하는 배움터는 없다.

    - 고객이 있는 뭔가를 만들어 보는 경험이 필요하다.

    - 좋은 개발 프로세스와 멘토가 있는 현장에서만 '배움'이 가능하다.

 

2. 회사는 업무를 수행할 수 있는 기본 역량과 성장 가능성을 보고 채용을 한다.

    - 매일 나는 무엇을 할 수 있게 되었는지를 성찰하고 이력서를 개정하자.

 

[성장에 필요한 것들]

 

1. 생산성

    - 마우스로 가는 시간을 아껴서 Hot-Key를 쓰자, vim 에디터를 쓰자

    - 디버거를 쓰자

    - AI 도구를 잘 알고 쓰자

 

2. 시간 관리를 하자. 우리는 프로다. 시간 관리를 해야 자기 몸값을 안다.

    - issue 관리 노트를 쓰고, 예측 시간과 해결에 걸린 실제 시간을 쓰자.

 

3. 새로운 문제로 기획하느라 머리 쓰는 시간을 아끼자.

    - 이미 만들어진 것을 따라 만드는 것도 좋다. 쉽게 배우고 팀 안에서 문제의 관점을 논의하는 것이 중요하다.

    - 점진적으로 (MVP, Lean 등), 디버깅, 코드 리뷰, 테스트, 릴리즈를 하면서 가자

 

4. '예외 case(boundary 조건)는 잘 처리되었는지', '문제에 대한 답이 논리적이고 시간적으로 잘 도출되는지', '코드는 style, 가독성, 성능 관점으로 아름다운지'

    - 이 문제와 연관된 지식을 잘 습득했는지, 협업은 잘 되었는지 회고로 확인하자.

 

5. 우리가 추구해야 할 팀 활동 (철저한 협업)

    - 문제에 대한 학습과 토론, 팀원들의 문제에 대한 관점 공유 조정

    - 역할의 분담과 동시에 같이 배울 수 있는 협업 구조/도구도 정의 (다른 팀원의 작업 진행 볼 수 있고, 리뷰와 코멘트, QA 할수 있도록) (도구 연동: github(issue tracking, pr/merge, ci/ci, wiki) + slack 연동) -> 여기까지 전체 프로젝트 기간의 1/3 정도를 써도 세상 망하지 않음

    - Lean한 방식의 진행 (점진적 개발): 모든 시점에 보여줄 결과물이 존재(만들고 리뷰하고, test하고, 기능 추가 반복)

    - 모두 내용을 알고 있으므로, 결과 발표는 발표 제일 잘하는 사람이 하자

    - 책임을 묻는 것이 아닌 배우기 위한 회고를 하자(기술, 방법, 관점 및 태도)