Dev.Inn Tech Meetup 성장하는 개발자의 길
1ocate • 2022-12-09
오프닝
CTO CJ Networks 신정호
CTO가된 이후 스트레스를 많이 받아 고민이 많아 같은 C레벨 분께 상담을 받았지만 바빠서 참여하기 어려웠음.
3개월의 상담과정에서 마지막에 상담자분의 하신 말씀이 가장에 기억에 남음.
"C레벨의 숙명은 성장 무조건 성장 시켜야 한다, 절대적 가치, 숙제"
본인이 생각하는 성장의 뜻
"구성원 개개인의 성장이 조직의 성장"
본인이 생각하는 성장의 반대는 무엇인가?
"퇴보, 정체?"
"성장의 끝점에서 이뤄지는 기존 행동의 반복"
거울나라 엘리스에서 붉은 여왕이 엘리스에게 하는 말
"여기서는 같은 곳에 있으려면 쉬지 않고 힘껏 달려야 해.
어딘가 다른 데로 가고 싶으면 적어도 그보다 두 곱은 빨리 달려야 하고."
리 밴 베일런의 "붉은 여왕 가설"
주변 자연환경이나 경쟁 대상이 보다 빠른 속도로 변화하려하기 때문에 어떤 생물이 진화를 하게 되더라도 상대적으로 적자생존에 뒤처지게 되며, 이를 보상하기 위해 끊임없이 서로 재시도를 하는 과정에서 결국 자연계의 진화경쟁에선 어느 한쪽이 일방적인 승리를 거두지 못한다는 뜻
위키피디아 - 붉은 여왕 가설
Accenture Ceo 피에르 낭텀
"하이퍼포먼스기업 성장경로는 성공적으로 S곡선을 갈아타는 기업"
"성장할 때 다음에 올라탈 s곡선을 준비하라 갈아타지 못하면 그 기업은 죽는다."
출처:개발자와 기업이 함께 성장하는 기술 커뮤니티 그리고 디벨로퍼 릴레이션
우아한형제들 조은옥님
어떻게 개발자의 성장이 기업의 성장으로 이어지는가?
"답은 기술 커뮤니티에 있다."
커뮤니티?
"경험과 노하우"를 발전시키고 공유하므로써 그룹 구성원들이 성장할 수 있도록 돕는 집단"
"기업 안에서 존재 할 수 있다."
기업 바깥의 커뮤니티 가치
* 기술/개발에 대한 트랜드를 파악
* 개발자의 요즘 관심사를 알 수 있음
* 자사의 인지도를 높임
개발자향 기술 프로덕트를 가진 기업
* 피드백을 받을 수 있고, 개선점 파악
* 기존유저의 노하우로 신규유저의 학습 진입장벽 낮춤
* 유저가 자발적인 지지자 홍보대사
기업 내부의 커뮤니티
* 구성원의 역량향상과 성장을 도와줌
* 회사에 대한 소속감을 높임
* 조직간 사일로 해소
* 내부 구성원의 목소리를 통한 조직문화와 긍정적 인식을 외부에 전파하는 채널
기업의 바깥과 안을 통해 함께하고 커뮤니티 키움
Developer Relations?
개발자를 보는 시각
1) 개발자가 고객
2) 개발자가 핵심인재 및 채용의 대상
Public Relations
기업이 대중, 공중과 우호적인 관계를 만들기 위한 활동
ex) 언론홍보, 기자회견, 공중파출현, 소셜미디어, 세미나, 컨퍼런스
Developer Relations
기업이 개발자와의 우호적 관계
ex) 언론홍보, 기자회견, 공중파출현, 소셜미디어, 세미나, 컨퍼런스 전문적인 개발자 오디언스
시작
에벤젤리스트의 등장
애플의 "가이 가와사키"를 통해 애플 기기의 우수성 실리콘밸리에 전파함과 동시에
"가이 가와사키" 중심으로 커뮤니티가 만들어짐
* 제품/솔루션의 장점 소개
* 사람들이 잘 활용 할 수 있도록 도움
* 유저 커뮤니티를 만들어감
결과: 애플의 마케팅 전략을 바꾸고 애플의 전성기 시대를 도래하게 함.
단점 - 에반젤리스트의 단어가 종교적 색체 - 커뮤니티가 성장하는데 영업KPI로 위기
책 "가이 가와사키의 시장을 지배하는 마케팅"
디벨로퍼 애드보케이트으로 변화
* 멘토링 코칭, 기술에 대한 백그라운드
* 기술 커뮤니티와 개발자들의 목소리를 대변
* 상생을 위함
외국계 IT 회사의 DevRel 직무
* 유저 그로스 전략수립
* 개발자 행사 기획 및 운영
* 개발자 커뮤니티 운영 및 지원
* 기술 블로그, 소셜미디어, 콘텐츠 제작
* 대학생 및 교육/연구기관 지원
* 기업고객대상 스페셜 핸즈온 세션 운영
한국의 Developer Relations
고민의 시작
* 개발자 키우자 -> 양성
* 개발자 찾자 -> 커뮤니티/교류
* 개발자 뺏어오자 -> 처우/브랜딩
* 개발자 지키자 -> 개발문화 및 성장 시스템 활성화
실패 이유
* 통합적 관점 실행 어려움
* 무엇보다 개발자, 커뮤니티 이해 부족
=> DevRel 필요성 대두
Developer Relations의 사업분야
기업과 개발자의 관계를 만들고 유지하며 장기적으로 회사가 기술적 우위를 점할 수 있도록 기반과 생태계를 만드는 것
* 브랜딩
* 마케팅
* 커뮤니케이션
* 교육
* HR
* Tech CSR (기술을 통한 사회공헌)
DevRel의 직무 구분
* 뛰어난 기술적 역량 바탕
- 에벤젤리스트, 애드보케이트
* 기술 블로그, 컨텐츠
- 테크니컬 콘텐츠 매니저, 기술 블로그 에디터
* 마케팅, 브랜딩등 대외 커뮤니티케이 운영
- 개발자 프로그램 매니저
책 "기업의 성공을 이끄는 Developer Relations"
Developer Relations을 한문장으로 정리한다면
"개발자를 중심으로 다양한 분야가 한데 모여 멋진 관계를 만드는 일"
위대한 회사를 만드는 여정
원티드랩 공동창업자 황리건님
"창업에 대한 이야기"
"현재 다니고 있는 회사에서 더 좋은 영향력을 나타내기"
창업 포부
"NHN, MS 같이 위대한 회사를 만들고 싶다."
창업하면 뭐가 좋을까 고민
창업을 추천하는 부류
* 절박함
* 집, 주변에 창업 분위기가 있어야 한다.
* 커리어의 위기를 겪는 시기(35세)
* 창업을 안하면 답답해서 죽을 것 같음
사업 아이템 결정과 검증
* 아이디어 월드컵으로 사업 아이템 결정
* 페이스북 페이지와 구글 설문지로 사업테스트
"개발자가 이직하기 위해 사이드 프로젝트를 진행하는것에 착안"
* 스타트업 방정식(스타트업 교육, 린스타트업 등) 공부
* 실패 비용과 시간 최소화하여 연습
* 창업을 하기위해 경험과 네트워크를 쌓음
제로투원의 시기
"9개월동안 월급없이 지내기"
원티드의 초기성장
* 엑셀러레이터를 통해 초기투자를 받고, 후속 투자를 받아감
* 스폰서 확보, 지지자 중요
스타트업 본질(현실)
"지속가능하고 확장가능한 사업모델을 찾기 위해 구성된 임시조직"
* 지속가능하지 않음
* 확장가능하지 않음
* 사업모델이 불안전함
* 언젠가 없어질 조직
투자 회수의 위기를 통해 현실을 직시
* 불확실성: 회사가 망하거나 없어져서 실직할 리스크
* 예측불가: 최고와 최악의 리미트가 없는 업앤다운
* 체계없음: 정해져 있는 것이 없어서 스스로 만들어야 하는 환경
* 불협화음: 너무나 다른 배경, 경험, 가치관을 가진 동료와의 협업
* 고난이도: 나를 챙겨주는 사수나 매니저 없고 난이도 높은 업무
생존에 필요한 목표를 설정하고 치밀한 성장 계획을 세워 실행
"나보다 더 잘 할 수 있는 사람들을 꾸준히 영입"
스타트업을 추천하는 사람
* 큰 꿈을 꾸고 대단한 성취를 해보고 싶은 사람
* 긍정의 에너지
회사의 미션
"나답게 일하고 즐겁게 성장하는 것을 돕는다."
회사는 어떻게 위대해 질 수 있을까?
* 사업 성장과 비전
* 치밀한 전략과 실행
* 절실하게 성공을 원하는 사람들
* 위대해지고 싶다는 바램
사업을 안 하고 회사에서 하기
* 시장과 사업에 대해서 공부하기
* 신사업이나 기존 사업을 키워보기
* 고객이 원하고 사업 성과를 내는 제품을 만들어보기
제품과 개발자가 함께 성장
* 회사의 커리어 패스에 따라 성장하기
* 회사의 안전망과 복지 혜택 누리기
"팀원을 뽑는다면 나보다 높은 사람을 뽑는 것"
테크리더로 성장하는 중입니다.
인프랩 이동욱님
테크리더의 역할?
* 시스템 아키텍트
* 비즈니스분석가
* 프로젝트 매니저
* 소프트웨어 개발조직 리더
개발 조직의 성장
* Scale UP (팀의 확장)
우리팀만의 채용 공고 작성하기
* 우리팀만을 위한 조직이 아님
* 어떤 팀인지, 어떤 사람을 원하는지 적극적으로 공개
"배민에서 정산시스템팀, 기술, 채용공고 관리"
"인프런에서는 외부 유튜브 출현"
공들인 채용 공고는 제출되는 이력서의 질이 다르다.
"지원률이 변화함"
"원하는 사람이 뽑힘"
우리 팀원들은 기술 블로그를 안쓴다?
"나부터 쓴다" "테크리드로써 먼저 쓰게 되면 팀원들도 쓰게 됨"
적합성 확인
"팀 내에서 인정받는 동료에게 같은 질문을 해보고 어떤 대답을 하는지 확인"
"같은 대답을 한 지원자의 경우 대부분 비슷한 성향, 결이 같음"
공들여 키워놨더니 떠난다.
* 해결할 수 없는 문제
* 보상을 해줄 수 없으니 2~3년 떠나는 것은 확정
* 많은 시간과 노력이 필요없게 만들자
* 멘토나 사수 없이 배울 수 있도록
* 공유가 필요한 내용은 모두 위키에 "코드 리뷰, 개발팁, 도메인, 장애일지"등 문서화
* 날을 정해서 공유, 문서화
DM(Direct Message) 금지
* 그들만의 노하우, 지식으로 끝나버린다. 업무 관련은 모두 공개 채널에서 진행하고,
물어봐야하는 사항은 다 문서화로 기록해서 같은 질문이 나오지 않도록 한다.
* 모든 내용을 슬랙이나 위키에서 검색할 수 있게 함
최대한의 자동화로 사수가 없어도 잦은 피드백을 줄 수 있는 환경을 구성
* 정적분석(소나큐브)
* 테스트코드
* Lint, 코드 포맷팅
* 테스트코드 메소드명은 모두 한글로 작성한다.
* 신규 입사자가 테스트 코드만으로 비즈니스 로직을 이해 할 수 있도록 작성한다.
- 테스트코드 => 정책적인 내용 이해
신입 개발자를 위해 이렇게까지 해야해?
"신입 개발자를 적극적으로 채용해야 한다".
"좋은 경력 개발자를 뽑는 것은 복권에 가까움"
"노력대비 가장 확실한 효과 똘똘한 신입개발자 채용"
* 제어 할 수 없는 것에 기대하면 안된다.
* 제어 할 수 있는 것에 의존하여 개선하는 것이 좋다.
* 팀에 대한 애정을 높힘
낮은 수준에 사고에 익숙해야 남는 자원으로 높은 수준의 사고를 할 수 있다.
* 작은 것에 신경쓰게 하지 말아야 한다.
* 숙련도를 높이기 위해 가능한 가지수를 줄인다.
* 알짜 팁보다는 알고리즘,아키텍쳐등을 고민해봐야 한다.
Scale UP?
"적합한 사람이 모여있으면, 굳이 뭘 하지 않아도 알아서 성장
좋은 시니어 개발자 채용
"노력의 결과가 보장되지 않음"
좋은 시니어들의 노하우를 흡수하자
* 발표하다가 팀에 반할 수 있다.
* 팀에 전파
2달에 1번씩 외부 시니어 강연
* 이제는 먼저 필요한 노하우를 먼저 제시하는 팀원들
* 전문가를 팀에 연결시킴
함께자라기
* 팀원들과 함께 강의 수강해보기(코드리뷰 기반의 강의)
* CTO도 리뷰받는 모습을 통해 내 동료들이 모두 계속 성장 중이라는 시그널을 팀 전체에 전파
* 회사에 관심을 갖는 효과
한 팀에서 오래 근무한 시니어들은 그 자체만으로 사람이 팀이 노하우가 되기도 한다.
* 핵심멤버 일수록 더이상 성장하지 않을 수가 있다.
* 주니어 개발자에게 리뷰 받는 상황을 자주 만든다 (업무 Pair)
* (코드리뷰 기반) 외부 강의 함께 수강
* 테크리더가 없는 경우에도 강의를 듣도록 함
* 객관적으로 자신을 계속 들어나게 함
* 주니어와 시니어의 관계가 일방이여서는 안된다.
특정한 사람만 가능한 것은 위험신호
* 무조건 해당 시니어는 업무 로테이션
* 특정 사람만 할 수 있는 업무 범위가 있어서는 안된다.
욕망(기대) 수준 관리
* 기술, 방법론, 아키텍처에 대한 요구사항이 있다.
* 조직내에서 감당 가능한 범위내에서는 최대한 허용한다.
* 팀에서 달성하고 싶은 욕망이 없으면 복지, 보상에 대해서만 요구하게 됨.
팀원을 설득하는 법
* 모든 과정에서 팀원의 신뢰가 가장 우선.
* 싫은 리더가 제안하면 다 거부한다.
개인적인 관심
* 술자리나 친목을 의미하지 않음
* 다른 팀원들이 볼때 걱정되는 팀원 최우선
* 팀원들이 서로가 서로를 상태 체크하는 문화 조성
심리적 안정감
"칭찬은 공식적으로, 피드백은 개인적으로"
즉시 No 하지 않기
* 비난 하지 않을 것이라는 안정감을 주는 것
* 절대 그자리에서 즉시 부정적으로 답하지 않는다.
* 불편한 상황을 마주하게 된다 생각하면 말하지 않음
절벽으로 밀지 않기
"몰아세우기로 자기 계발을 강요하지 않는다"
스페셜리스트 vs 테크리드
* 모든 것은 팀원의 경험치로
* 업무 자동화, 모니터링 개선
"비즈니스 속도에 맞는 기술부채 수준을 관리하기 위한 준비를 한다."
제가 틀렸네요.
* 내가 틀렸다 라는 것을 말하는 용기와 연습
* 전지전능한 존재가 아니다.
항상 감사하기
프로그래머로서 산다는 것
쏘카 CTO 류석문
1. 개발자
필수능력
깔끔한 코드
* 사람이 이해하기 쉬운코드
* 변경이 용이한코드
* 유지보수 비용이 낮은 코드
깔끔한 코드 작성법
1) 테스트를 통과할 만한 코드작성
2) 리팩터링
* 사용하는 코드만 만들기
* 리팩토링
- 상시, 코드커밋
* 코드읽기
- 코드리뷰 버그 찾는 것 x
적절한 논리력
* 원리 탐색 능력
* 제약조건을 고려한 해법
* 단순한 디자인 (작은단위)
적절한 논리력을 기르려면
* 있는 것 잘쓰고
* 협업
* 사용기술 적절한 시점에 도입
실천법
* 꾸준한 연습
* 매일 몸값 올리는 시간을 가져라
* 동기부여 요소
* 동료
* 현재 필요할만큼만 해라
2. 좋은 개발자?
좋은 ~ 개발자
* 분야가 다양
* 시간 변동성
"자신을 한정지으면 변동성에 휘둘림"
"좋은"의 의미?
1) 공유
2) 협업
"시간 변동성 없음"
공유하는 이유
"결론은 개인의 이득 때문"
* 주변이 똑똑해져야 내가 편함
* 중요한 일을 할 수 있는 여유가 생김
* 좋은 평판을 얻을 수 있음
* 주변의 덛을 볼 확률이 올라감
공유대상
"무엇이든"
* 실패
- 새로운 기술 (*내가 써보고)
* 교육세미나
- 코드리뷰
협업의 전제조건: 상대를 이해하자
협읍의 필수요소: 자아존중감
* 자신이 존중 받을 가치가 있다고 믿음
* 있는 그대로의 자신을 인정함
* 타인의 부정적인 견해에 크게 영향 받지 않음
자아 존중감을 높이는 방법
"무엇을 통해 자아존중감을 높일 수 있는지 찾아야 한다."
좋은 개발자
* 공유
* 적절한 논리력
* 좋은 코드 작성능력
* 피드백
* 실천력
"연습이 완벽을 만든다."
패널토의
성장에 대해 가지고 있는 신념?
* 메타인지(무엇을 모르는 것에 대해서 아는 것) 하는 것이 중요
* 70%는 일에서 온다. 일을 잘할려고 노력할 때 성장이 온다.
* 하루하루 계획을 해야한다
좋은 CTO란?
* 기술로 회사의 성장을 이루는 것
* 타인을 이햬하는 능력
* 조직의 미흡한것 을 감수하고 가야할 때도 있어야 한다.
* 남을 내편으로 만드는 능력이 필요함
* CTO는 하나의 역할, 좋은 목표인가 고민해보고 자신이 뭘 좋아하는지 자신의 성향을 알아야 한다.
"자신이 좋은 것을 할 수 있는 선택지를 찾아서 찾아가면 좋다."
"회사에서 잘할 수 있는 방법을 찾아야한다."
조직내에서 욕망관리
* 신기술 적극 도입
* 욕망이 나올 수 있도록 심리적 안정감 중요
* 새로운 기술 도입하고 싶은 리스트 작성
"필요가 있으면(견고한 소프트웨어를 만들기 위해) 강제 해야 한다."
"창의적인 능력이 있어도 자세교정이 가능할때까지 노력해야 할 부분이 있다."