개발자로 살기

멘토 정보
임민영 멘토 (현 어린이 전용 SNS '놀잇' CTO)

마인드 셋

나는 어떤 사람인가?

직업, 취미, 좋아하는 운동, 자주 쓰는 언어나 툴, 관심사, 하는 일...
이 중 최소한 3가지는 정리해보자. 현재-과거-미래의 형태로 정리해두면 좋다.

내가 무얼 좋아하고, 힘들 때 어떻게 해야하는지, 어떤 환경을 견딜 수 있는 사람인지
나를 알아가는 것이 중요하다!

• 내가 요즘 하는 것, 내가 잘 하는 것
• 과거의 나, 현재의 내가 어떤 사람인가

나 === 개발자가 아니라 나 = { 직업: 개발자 }

개발자는 _____하는 사람이다

개발자는 기능을 구현하고 '문제를 해결하는' 사람이다.
끝없는 수정과 테스트의 반복. 만드는 것보다 고치는 일이 더 많다.
그러나 주어진 시간 내에 문제를 해결하는 사람!

개발자는 개발만 하는 사람이 아닌 개발도 하는 사람

로드맵

로드맵을 활용할 때 필요한 것은 내가 하고자 하는 것을 하기 위해 어떤 것을 공부해야 하는지 알기 위한 것이다. 절대적으로 모든 로드맵을 다 따라하고 공부했는지 일일히 체크하지 않아도 된다.

중요한 것은 '방향성과 가이드라인', 내가 가고자 하는 방향인지 정확히 아는 것.
끝없이 스스로 되물어야 하고 뭘 하고 싶은지 모르겠다면 CS(Computer Science)를 공부하자!

로드맵 기본 경로

1. 만들기

• 언어/환경
• 내가 하려는 일에 따라서 디테일이 달라질 수 있다

2. 고치기/공유하기

• Git
• 디자인 패턴, 아키텍쳐
• 그 외 함께 만들기 위해서 정해야할 것들

3. 확인하기

• 테스트 방법론
• 테스트

4. 배포하기*

• Github Actions, Code deploy, putty 등..
• 내 코드를 다른 사람이 접근할 수 있도록 하기

5. 자동화

• 배포 자동화, 테스트 자동화
• 매번 내가 할 것이냐 명령어 한 줄로 자동화 할 것이냐
• Jenkins, Code Magic...

내가 단순히 '코더'가 되고싶은 것이 아니라 '개발자'가 되고 싶다면 앞선 만들고 고치는 것 외에 확인/배포/자동화 하는 기술을 더욱 깊이 알아야 한다. 물론 앞에 두개를 하지 않으면 뒤에 3개는 따라오지 않는다.

내가 가고자하는 기업에 자격 요건과 우대사항에서 다루는 툴과 개발 환경을 경험해보는 것을 로드맵으로 구성해보자! 그리고 내가 다루는 플랫폼이 어떻게 변하는지를 확인하자!

• 크롬의 developer 사이트 참고
• 크롬 익스텐션 서핏 (아티클)

우리는 하나 더 해야한다

개발자는 '개발만' 하는 사람이 아닌 '개발도' 하는 사람. 그리고 갓 졸업한 학생이 아니라 사회 경험이 있는 사람들이라면 더더욱 원활한 의사소통/커뮤니케이션/소프트 스킬이 필요하다. 즉, 잘 말하고 잘 들어야 한다.

1. 고객한테 잘 하자

🙍🏻‍♀️ "개발자님, 제가 ~가 필요해요!"
🤦🏻‍♂️ "개발자님, 제가 ~가 안돼요!"

회사 내부에도 고객이 있다는 것을 인지하자. 급발진 금지. 그들이 물어보는 것을 다 해줘야하는 게 아니다. 마치 처음 산 기계를 조작해야 하거나, 사용 중이던 기계가 고장났을 때 설명서를 읽는 것처럼 우리도 설명서 역할을 해주어야 한다.

2. 당연한 것은 없다.

🙎🏻‍♀️🙎🏻‍♂️ "그거 3일 걸린다면서요?"
👩🏻‍💻👨🏻‍💻 "코드 짜는 것만 3일이고.. 테스트가 어쩌구..(구구절절)"

대게 많은 개발자가 착각하는 것은 내가 아는 것을 남도 알고있다고 생각하는 것이다.
당연하다고 생각하는 모든 것은 TMI일지라도 최대한 설명하고 넘어가야 한다.

기업에서 개발자는 돈과 많이 관련되어 있다.
개발에 시간이 많이 들수록 기업 입장에서는 많은 돈이 들어간다. 시간의 중요성을 인지하자!

3. 데이터로 말하자

인간의 직관은 생각보다 별로다. 그리고 위험하다. 직관은 '내가 아는 것에서' 나오는 것이기 때문에 나의 직관은 생각보다 오류가 많다. 그러므로 내가 어느 것을 주장하고자 할 때에는 내가 주장하는 것이 맞는 것인지 뒷받침할 데이터를 가지고 있는 것이 좋다.

예를 들어 Sentry에서 어떤 기능에 대한 오류 결과를 아래와 같이 나타났다고 하자.

🔧 A 기능 : 30
🔩 B 기능 : 2

개발자는 해당 데이터가 정확히 무엇을 의미하는지 파악해야 한다.

• 오류가 3천만번 중에 30번인지, 2번 중 2번인지...
• 클릭 횟수가 일주일에 30번인지, 일주일에 2번인지...

이런 데이터가 있어야 의사소통이 원활할 수 있다. 개발우선순위라던지, 기능 삭제나 추가 등 모든 곳에서 '데이터'가 필요하다. 데이터가 없을 경우 데이터를 모으는 것부터 시작하자.

자책하지 말고 회고하자

회고란 스스로 칭찬하고 고칠 점 찾는 것 = 덜 괴롭게 나아지기 (내 탓 금지!)
나에게 잘 맞는 회고 방법과 회고 단위를 찾아서 적용하자.

회고 방법론

• KPT
• PMI
• DAKI
• 4Ls

회고 단위

• 프로젝트가 끝날 때 마다
• 한달마다
• 분기마다
• 등등등...

회고 내용

회고 방법론에 따라 본인에게 잘 맞는 방향으로 적용하되 기준을 세우자.
e.g 최소 n개는 적기 (좋은점 n개, 고칠점 n개 등)

사이드 프로젝트

"목적이 있는" 개인 프로젝트를 하자.
프로젝트는 목적이 있어야한다. 목적이 없는 프로젝트는 '코딩 놀이'에 불과함

팀은 어떻게 구하지?

일단 올리지 말고 '주제'를 잡자. 관심있는 주제로 선정하는 것이 좋다. 하지만 현재 개발자라면 내가 현재 일 하고 있는 도메인은 피하자! 대외비나 기밀유출 이슈를 최대한 피해가는 것이 좋다.

기능은 내가 할 줄 아는 것보다 조금 더.

• 매번 CRUD만 했다면 동영상 플레이어나 텍스트 에디터 넣어보기
• 지난 회고 내용을 반영하기

시간을 정해두고 하자

• 목표일정을 정하지 않으면 평생하게 된다. 미완성이더라도 종료하기!
• 목표일정을 잡기 어렵다면 실패할 프로젝트를 먼저 하자

개인 회고는 필수

• 팀 회고를 원치 않는 팀원이 있다면? 강요는 하지 않되 권유 정도는 해보자
• 개인적으로라도 회고록을 쓰고, 지난 회고와 비교해보자
• 본인의 감정도 기록하자. 일기 같다고 생각하자.