어제 진행되었던 GDG Devfest Incheon을 다녀왔습니다.
송도가 생각보다 거리가 멀어 갈 때는 괜히 신청했나 했지만, 컨퍼런스가 진행된 송도 컨벤시아가 쾌적하기도 하고 세션들의 내용도 좋아서 내년에도 참여하고 싶다 생각이 들었어요.
시니어 개발자 노하우 - 개발 잘하는 방법 (권대건님 / JNPMEDI)
부제 - 문제정의부터 해결까지 완벽과정
이전 슥삭 CTO를 지내시고, 현재는 JNPMEDI에서 개발 리드를 하고 계시는 권대건님이 "시니어 개발자 노하우 - 개발 잘하는 방법" 이라는 주제로 발표를 해주셨어요.
저의 경우는 아직 주니어 입장에서 큰 그림을 보지 못한 채 개발을 하는 경우가 많은 것 같습니다.
해당 발표에서 대건님은 문제 정의와 해결에 대한 여러 가지 방법론과 예시를 알려주었는데, 그 중에서 문제 정의 canvas와 5 why's 분석은 내가 어떤 문제를 해결해야 하는 지 파악하는 데 유용할 것 같습니다.
하단은 제가 발표를 들으면서 메모한 내용입니다.
문제 정의란? 문제를 해결하기 위해 올바르게 이해하는 과정
문제 정의 핵심 요소
- 무엇이 문제인지 / 왜 문제가 발생했는지 / 어떤 결과를 기대하는지
제대로된 문제 정의가 이루어지지 않고 프로젝트가 진행되면 리소스가 낭비됨(프로젝트 지연, 비용 초과 등)
이러한 실패를 겪지 않으려면 초기 단계에서 충분한 시간을 투자해야 함 - align을 위해
문제 정의를 도와주는 툴
fishbone diagram
문제 정의 canvas는 6가지로 이루어져 있음
context - 맥락 이해
root problem - 내면의 문제 파악
alternative - 현재 상태에서 다른 대안은 없는가. 개발을 하지 않더라도 해결할 수 있는 대안 등. 임팩트 확인
customers - 대상이 누구인지 / 먼저 대상을 정의하지 않기
emotional impact - 당사자가 어떤 문제를 겪고 있는지
quantifiable impact 정량적인 임팩트 - 돈, 상품, 시간 등이 얼마나 감소하는지
alternative shortcoming - 대안에 대한 단점 확인
5 why’s 분석 - 5번의 why를 생각하는 것. 꼬리 물기.
계획 수립
- 기한이 있고 / 구체적이고 / 예측 가능하고 / 현실적 / 달성 가능한(다음 로드맵을 계속 고려해야 함 ex. ver1, ver2, 외부 내부 달성 방해 요인 파악 필요)
우선순위 설정
MoSCoW 기법 (Must, Should, Could, Won’t)
문제 해결 - 바라보는 관점에 따라 해결할 수 있는 방법이 달라짐
needed - 유연한 사고 방식
- 복잡한 문제를 작은 단위로 쪼개기
ex - 개발할 때 공통의 성격을 가진 문제를 결합하는 것도 중요함
- 추상화 레벨을 조정하기 - 큰그림과 세부 사항 균형 맞추기
ex - 해당 기능 개발할 때, 문제 요구사항을 고려하면서 해야 함. 확장성 고려
- 가설로 접근하기 - 문제를 명확하게 정의
ex - 문제가 생겼을 때 코드부터 보는 것이 아닌, 문제 가능성 케이스들을 고려해보는 것.
- 디버깅과 회고 - 실패에서 배워라
레슨런이 반복되도록
- 협업의 힘 - 혼자서 해결하지 마라
소통과정에서 생기는 마찰을 무서워하지 말고 계속 핑퐁하다 보면 더 나은 문제 해결이 가능함
최적의 코드 작성
- DRY 원칙 적용 (Don’t repeat yourself)
- KISS 원칙 적용 ( Keep it simple, stupid)
코드 리뷰
- 코드 품질 향상 / 학습 및 지식 공유 / 협업과 소통 / 유지보수 용이 / 개발 속도 향상빅테크 엔지니어 성장비법 우리팀에 복붙하기
엔지니어링 커리어 래더로 팀 메타인지를 함께 올리는 방법
해당 주제는 하이퍼커넥트에서 엔지니어로, 뱅크샐러드에서 매니저를 경험하시고 현재는 마나부 라는 회사를 창업하신 박준호님이 발표를 해주셨습니다.
커리어 래더 라는 것은 처음 들어봤고, L3, L4.. 라는 명칭만 들어봤는데 레벨을 통한 체계화된 직무 역량 관리를 간접 경험해볼 수 있어서 좋았습니다.
### 엔지니어링 커리어 래더란
엔지니어 커리어를 체계적으로 성장할 수 있게 돕는 명확한 역할과 기대치를 정의한 프레임워크
빅테크에서 주로 쓰는 레벨 제도 ex. L3, L4, L5…
매니저가 무엇이냐?
우리나라에선 매니저라는 역할이 잘 정의되어 있지 않았음. 매니저 ≠ 팀장.
사람을 잘 관리하는 것과 기술 역량이 높은 것은 분리 되어야 할 필요가 있음.
매니저는 보통 L5부터
L3: 인턴 / 신입 / 주니어
L4: 주니어와 시니어 사이 중니어
기능 단위를 도맡아 하고, 책임감 / 안정성
L5: 테크 리드 / 시니어 엔지니어
L6: 스태프 엔지니어
페이스북은 L3 → L4 2년, L4 → L5 4년 정도 소요. L5부터는 비즈니스 임팩트 있는 큰 프로젝트에 기여 필요
### 엔지니어 커리어 래더링 적용하기
매니저와 엔지니어가 대화하는 것이 제일 중요. ex. 원온원을 통해
역량 기준을 통해 항목에 색을 입혀 서로의 시선을 봄.
역량 기준이 없다면 어디선가 퍼오기
커리어 래더 - 희망편
ex. 다른 회사에서 좋은 오퍼를 받았을 때 매니저와 고민 / 매니저가 고민을 같이 함
커리어 래더 - 절망편
커리어 래더 - 응용편
커리어 래더 - 소통하기
뱅크샐러드에서 적용했던 엔지니어링 매니징 방법 / 매니저와 같이 얼라인
### 주기적으로 발전을 체크해보는 방법
3~6개월 정도의 주기가 적당함.
역량표를 바탕으로 6개월간의 변화를 소재로 대화
- 개발자는 성장 확인
- 매니저는 기회 확보
다음 라운드의 향상 목표 선정
다른 회사의 커리어 래더에 대한 이야기들은 여기서 확인해보실 수 있어요.
