이직을 꿈꾸는 개발자들에게 선배 개발자들이 진솔하게 전하는 개발자 이야기
개발자 커리어 컨퍼런스
- 인사 담당자가 말하는 개발자 채용
- 개발자로서의 성장
- 한국 개발 커리어의 현실
개발자, 되고 보니 끝이 아니더라
개발자로 커리어는 시작했지만, 연차가 쌓일수록 이직을 비롯해 누구에게 물어봐야 할지, 어디서 찾아야 할지 모르는 궁금증이 쌓여만 갑니다.
5년차, 10년차, 20년차 개발자 연사님들이 각 연차별 어떤 고민을 하고 어떻게 해결해야 하는지 그 어디에서도 들을 수 없었던 개발자의 진솔한 이야기를 전달합니다.
이직을 고민하고 있거나, 개발자의 성장과 방향성에 고민하고 있다면 이 컨퍼런스를 통해 해답을 찾을 수 있습니다.
Session 1. 인사담당자가 말하는 개발자 채용
발표주제 :
개발 실력과 원하는 회사에 입사하는 것은 다른 문제입니다.
CTO/개발팀장들 보다도 가장 먼저 서류를 검토하고 인성면접을 진행하며 내 성과를 평가하는 인사팀이 개발자 채용, 평가에 대해 갖고 있는 솔직한 생각을 공개합니다.
- 인사 담당자가 바라본 개발자의 특징/특성
- HR팀이 개발자에 요구하는 역량들
- 개발자의 커리어는 어떻게 성장시켜야 하는가?
발표자 :
25년차 대기업 HR 총괄(임원급)
발표내용 :
無!!!!!!!!!
Session 2. 개발자, 직장인? 직업인?
개발자로서 실력을 키워 성장하는 법과, 개발팀 직원으로서 좋은 인사고과를 받고 살아남아 승진하는 법은 다릅니다.
개발 실력과 회사 생활 양쪽을 모두 신경써야하는 직장인 개발자를 위한 성장 꿀팁을 공개합니다.
Session 2-1 : 5년차 개발자
발표자 :
5년차 개발자 김범준
<개발과 업무의 경계에서>
개발이 즐거워서 개발을 시작했지만 회사생활을 하면 할수록 즐거웠던 개발이 업무로 느껴질 때가 있습니다.
그 경계에서 어떻게 하면 두마리 토끼를 잡을 수 있는지 함께 생각해 봅시다
경력 :
- (현) 레이니스트 [Rainist.,co.ltd] Software Engineer
- (전) 투데잇당 Software engineer
- (전) 두닷두Dodotdo에서 Software engineer
- (전) OJWorld에서 Software engineer
- Software Maestro 6기
- Mash-Up 단장
발표내용 :
잠깐 나갔다왔는데 끝나있었다. ㅠㅜ;
Session 2-2 : 10년차 개발자
발표자 :
10년차 개발자 이경일
발표내용 :
<어떻게 하면 추천받는 개발자가 될 수 있을까?>
: 개발자로 일하면서 우리 조직에 개발자를 추천 했던 혹은 다른 회사에 개발자를 추천드렸던 이야기와 개인적인 개발자 추천 기준을 공유합니다.
경력 :
- (현) KAKAO Commerce platform Developer
- (전) NAVER Main platform Developer
- (전) CJ O Shopping Commerce platform Developer
- (전) NHN i&s, Technology Services Backend Server Developer
발표 경력
- OKKY – 개발자 커리어 관리 관련 발표
- SpringCamp 2017 – Spring Cloud 관련 발표
발표내용 :
회사는 항상 개발자가 부족하다고 한다.
그러나, 막상 개발자는 자기가 갈 회사를 찾기 힘들다.
모든 회사는 개발자를 채용하기 위해 매우 노력한다.
1. 경력공채
2. 지인(사내)추천
회사에서 사람을 뽑는 방법은 2가지가 있다.
그 중 지인 추천에 대해서 이야기하면,
지인 추천을 받는 것 중에 특이하게 개발자가 아닌 사람들에게 추천을 받는 경우가 있다.
그러므로 모든 일을 할때는 커뮤니케이션이 매우 중요하다.
개발자가 아닌 사람을 이해시키는 토론 능력도 매우 중요하다.
가끔 기획자와 사이가 안좋은 개발자들이 보이지만, 기획자를 통해 추천을 받는 경우도 존재하기 때문이다.
모든 사람들과 좋은 관계를 가지는 것이 중요하다.
당연한 일이지만, 모든 일에 최선을 다하여,
자신의 서비스의 오너쉽, 전문성그리고 해당 도메인의 이해를 알고 있어 그것을 주변사람들에게 인정을 받는 개발자가 되면 된다.
그러므로, 자신이 하고 했던 업무를 적극적으로 표현하는 것이 좋다.
온라인에 자신을 표현할 수 있는 커뮤니케이션을 이용한다. (github, blog, facebook 등)
물론 회사 내부의 소스를 함부로 올리지 않도록 지양해야한다.
직접 자신이 세미나에 강사로 자신의 업무를 표현하는 것도 나쁘지 않다.
컴퍼런스는 배우려 가는 것보다 지인을 만나러 갈수 있는 장을 만드는 것도 하나의 방법이다.
온라인에서 발생했던 인맥을 오프라인 커뮤니케이션으로 되도록 한다. (세미나, study group 등)
마지막으로 나에게 블랙리스크된 사람들이 존재한다.
난 개발을 너무 잘하기 때문에 이거는 완벽하고 더이상 수정할 수 없어라고 옹고집적인 개발자는,
절대 추천하지 않는다.
Session 2-3 : 20년차 개발자(CTO)
발표자 :
20년차 개발자 임세준
발표내용 :
<관리자와 개발자>
: 향후 커리어를 관리자와 개발자 사이에서 고민하시는 분들을 위해 관리자와 개발자의 차이, 스타트업 CTO로서 그 둘 사이에서 어떤 고민들을 했는지를 이야기 합니다
경력 :
- (현)드라마앤컴퍼니 Drama & Company 개발그룹 / Group Leader
- (전)LG U+ Smart SME 기술 책임자
- (전)한국 Oracle SOA/IDM 제품의 Technical Consultant
발표내용 :
개발자로서 CTO가 된 경험담을 이야기하자면, CTO는 도대체 뭐하는 거냐고 묻는 경우가 많다.
개발을 좋아하고 CODDING 을 좋아하는 사람이 막상 CTO가 되었을 때,
단순히 기술리더로써 기술적인 문제만을 해결하는 것이 아닌,
기술 외적인 문제도 해결해야하는 책임이 생기게 되는 거 같다.
물론, 그럼에도 불구하고 기술리더로써 기술적인 문제를 해결해야한다.
개발적으로는 다음과 같은 문제를 해결해야한다.
1. Understading problems
2. managing the flow of ideas
3. maintaining quality
관리적으로는 다음과 같이 프로젝트 관리를 하여 해결해야한다.
1. 태스크의 리스트 업 및 공수산정
2. 태스크 작업 순서 및 계획 수립
3. 프로젝트 진행시 발생하는 이슈 해결
그 외의 조직적인 문제들도 해결해야한다.
1. 구성원들이 더 높은 성과를 낼 수 있는 환경구축
2. 개발 구성원의 이슈 해결 및 만족도 재고
3. 구성원간의 모호한 R&R 정립
그렇게 문제들을 해결하면서 목표 달성을 위한 문화를 만들어야한다.
목표 달성을 위한 개발 문화/프로세스를 만들어 해결한다.
1. 업무 프로세스 : 스크럼, PP, 코드 리뷰
2. 품질 관리 : 단위 테스트, QA 프로세스
3. Risk taking : 신기술 도입 장려 vs 보수적 기술 도입
이런 문화프로세스를 조직원들이 자동적으로 할 수 있도록 도와줘야한다.
이런것들을 해결하는데 CTO로써 매우 노력을 해야한다.
일정은 정해진 거 같은데, 우선은 해보자 하고 우겨넣으면,
개발자들은 코드를 잘 짜자라는 마음보다 어떻게든 빨리 해결하자라는 마음을 가지게 된다.
결과적으로 보기 싫은 CODDING가 양산되고,
결과적으로 개발자들은 열씸히 해도 안되는 구나 하는 생각이 든다.
프로젝트가 끝나도 보람이 되지 않는다.
이런게 반복되면 결국 개발자들은 이직을 하게 된다.
CTO는 이러한 문제점들에 대한 이슈 및 해결책들을 고민해서 해결해야한다.
CTO가 되어서 기쁜점.
- 더 크고 복잡하고 어려운 문제를 해결하고 있다.
- 회사에 더 많이 기여하고 있다..
슬픈점.
- 코딩을 더 이상 할 수 없다
- 문제 해결에 대한 스트레스가 크다
Q&A
Q : 임세준 CTO님에게 질문드리고 싶습니다.
만약 계속 개발자로서 여러 경험을 쌓고 커뮤니케이션 기술을 늘리고 커리어를 만들어가면,
개발자의 최종 종착지가, CTO가 되거나, vp엔지니어가 되거나, 이야기 주신거 처럼 치킨을 굽거나 할거 같은데요.
어느정도의 개발자가 모인 개발회사에서
CTO가 없는 회사는 기술의 바다에서 선장 없이 헤매는 배라며 힘들게 cto를 모셔오는데,
막상 개발자들끼리 저분이 CTO가 맞나? 그냥 연구소장이나 관리자같은데?
이런 의문이 드는 거 같습니다.
그런데, 보통의 회사에 CTO가 있어도 하는 일은 전체 개발 조직을 관리하고 여러 프로젝트의 진행을 챙기는 등의 관리 일을 많이 한고,
또 경영자에게 보고를 하기 위한 보고서를 만드는데 시간을 쓰다보니,
진짜 개발자가 원하는 기술을 챙기기란 시간적으로도 불가능하기 때문에 혹시 나도 치킨을 굽지 않고,
계속 개발자로 버틴다면 저렇게 될까? 라고 체념하고 있는 부분인데,
그런 촉박한 시간안에 개발적인 부분,
Understading problems
managing the flow of ideas
maintaining quality
이런 부분들에 대해서 어떻게 극복하셨는지가 궁금합니다.
A : 상황마다 CTO로써의 역활과 책임에 따라 다르게 행동해야 한다.
가장 먼저 프로젝트 기술적으로 난이도가 있는지 먼저 판단하고,
기술력 프로젝트 난이도 (별도의 시간을 두어서라도) 별로 해당 문제에 대한 처리를 해야한다.
기술관점으로 우리가 풀어야할 문제? 해결? 목표? 이 세가지에 대한 명확한 정의를 우선한다.
그리고 그 때 가장 최적의 아키텍쳐에 대한 논의와 아이디어 회의를 해당 개발조직과 충분한 논의를 거친다.
담당자와의 효율적인 결론을 상황에 따른 기술난이도에 대한 집중도에 대한 문제를 우선적으로 처리한다.
Session 3. 내가 보는 한국 개발 커리어의 현실
내가 개발자로서 언제까지 살아남을 수 있을까?
핫한 기술 스택 열심히 배우면 이직/승진이 쉬워질까?
앞으로도 수십년 개발자로서 사회생활을 해야하는 당신을 위한 동료 개발자들의 생생한 증언을 들어보세요.
Session 3-1 : 5년차 개발자
발표자 :
5년차 개발자 조은
<7년을 돌이켜 보며>
유수의 대기업, 스타트업, IT 기업을 거쳐 지금에 이른 개발자의 과거 경험을 공유하며 개발자의 커리어 패스에 대해 고민해 봅니다.
경력 :
- (현) NAVER Front End Developer
- (전) 우아한형제들 Front End Developer
- (전) NHN Technology Services UI Developer
- (전) SK Communications UI Developer
발표내용 :
내 소개를 하자면, html & css 잘하는 사람은 드물지만 잘할 수 있다는 (쉽다는) 사람은 무수히 존재하는 정체불명의 언어인 마크업 개발자다.
크고 작은 컴퍼런스에 200개 정도 꾸준히 참여했으며,
스터디도 지속적으로 했다.
온라인으로 계속 인맥을 샇았으며 CTO도 알고, 실장도 알게 되었다.
그로인해 추천이직으로 네이버에 들어가게 되었다.
물론 추천이라고 쉽진않다. 매우 빡세게 시험을 보고 면접도 보고 하고 다할 정도의 자기자신의 스펙을 쌓아야한다.
면접의 장점은 2가지가 있었다.
1. 잘하는 점과 못하는 점을 알 수 있었다.
- 면접을 자주 보는 것이 좋다.
2. 앞으로 어디에 초점을 맞춰야할 지 알수있다.
- 한 회사에 오래있으면, 정체(루즈)하게 된다. 같은 업무만 반복하게 되기 때문이다. 그런데 면접을 보게 되면, 어떤 부분이 부족하고 현재 회사에서 바라는 인재상에 대해 알게 된다.
Session 3-2 : 10년차 개발자
발표자 :
10년차 개발자 최완복
<개발자 홀로서기>
지금은 인하우스 개발을 하고 있지만 커리어의 상당 부분을 프리랜서로 살아남는 데 보냈던 10년차 개발자의 야생 생존법을 공유합니다.
경력 :
- (현)iOS 개발자, 하이퍼커넥트
- (전)iOS 개발자, 프렌트립
- 프리랜서 개발자
◾프렌트립, GE Healthcare, LG Hitach, 민트기술, 푸른밤, UNIST, 울산대병원, 조커팩 등
◾9건 이상의 iOS & OS X 개발 프로젝트 및 iOS 개발 컨설팅 / 교육 수행
- (전)공동창업자 및 개발팀장, 슬리트
발표내용 :
새로운 기술을 시스템에 바로 적용하는 것도 좋다.
물론 책임은 본인이 지는 것이고, 실제 적용했다가 심각한 오류로 원복을 할 수도 있다.
가르키는 것이 가장 최고의 학습법이다.
사내/사외 발표를 가리지 않고 하는 것이 좋다.
커뮤니티 활동은 매우 중요하다.
새로운 신기술의 동향과 행사소식을 파악하는데 용이하다.
컴퍼런스도 처음에는 좋은게 많았지만, 요근래 다양해지면서 좋은 행사를 골라가는 눈을 길러야한다.
새로운 지식을 계속 도전하는 것이 현재 업무에 신기술을 적용하는 것이라고 했지만,
그게 아니더라도 공부를 계속해야한다.
프리랜서의 단점은 좋은 동료가 없다. 이 갭을 메꾸기 위한 커뮤니티 활동이다.
Session 3-3 : 20년차 개발자
발표자 :
20년차 개발자 굿닥CTO 신현묵
<20년차 개발자로 살아남는 법>
20년 동안 개발자로 성장하려면 어떤 준비해야 할까. 개발자 20년 커리어 플랜을 세우는 법, 신현묵 CTO님으로부터 전해 듣습니다.
경력 :
- 현) 케어랩스 CTO 현) (사)한국디지털헬스산업협회 상임이사
- 저서 : 백세코딩
- 스윗트래커 CTO, 와탭랩스 CBO, 로코즌 부사장/연구소장, 우리들의료재단/명지의료재단 IT담당이사
- 자문) NHN Labs, 말랑스튜디오, 베스티안의료재단, RolandBerger, 인피니트헬스케어
발표내용 :
20년까지 개발자가 먹고 살수있기는 힘들다.
왜냐하면, 20년차 개발자가 할 수 있는 일은 3년차도 할 수 있기 때문이다.
오히려 20년차가 하면, 손도 느리고, 허리 아프고 연봉만 높다.
20년차 그 이상을 개발자로서 살아가려면 고참을 인정해줄 직군을 찾거나 방법을 찾아야한다.
예를 들어 회사에 20년차 CTO인데 연봉이 7천만원? 그런데는 회사로서의 가치가 없다.
직군을 인정 안해준다는 말이고, 그것을 개발자에 대한 대우로서 나타난다.
10년차 넘었는데 개발자를 뽑는 곳은 많을 것이다.
그러나, 20년차가 넘어서도 개발자를 하고 싶다면, 고참개발자를 인정하는 회사를 찾지 않으면 명예퇴직을 당할 수 밖에 없다.
나이가 먹어가면서 계속 인건비가 올라간다고 착각하면 안된다.
사람마다 다르며, 연봉 2억이 넘는 사람도 있고 1억도 안되는 사람도 있다.
20년차 직장인? 20년차 코더? 20년차 사회인? 어떤 사람이 될 것인지 본인이 결정해야한다.
20년차가 되기전에 경험해야할 것은 다음과 같다.
1. 다양한 경험 (대기업 No. 대리 이상이 되면 꼰대 정신을 가진다.)
2. peer 리뷰가 가능한 환경
3. 뛰어난 동료
4. 운 or 돈
실제로 1년에 1억~2억정도 벌 수있는 개발자가 1.5명 정도 필요한 일은 의외로 많이 찾을 수 있다.
그정도 시장은 개발자가 혼자 해도 된다.
하지만 실제 연 10억 매출 이상의 일을 마켓분석은 창업의 영역이지, 개발자의 영역이 아니다.
물론 혼자서 8억~12억 정도 매출을 발생하는 1인 개발자도 있긴하지만 그것은 운과 경험에 해당한다.
Q&A
Q : 이직 시기는 언제 하면 되는가?
A :
5년차 개발자 조은의 생각
1. 솔류션이 없는 것에 대한 불만이 있을 때!
- 윗선에 이야기하고 고민도 하고 납득도 해주는데 이루어지지 않았을 때! (feat. 좌절감)
20년차 CTO 신현묵의 생각
1. 경영자가 삽질할 때
2. 자신이 만든 솔류션이 정상동작하고, 자신이 할일이 없다고 생각할 때
- 자신이 없어도 된다(할일이 없다)
10년차 개발자 최완복의 생각
1. 새로운 기술에 대한 욕망(?)
Q : 쥬니어와 시니어를 구분짓는 것은 뭐라 생각하느냐?
A :
10년차 개발자 최완복의 생각
A급과 B급의 차이는 본인 업무 이외의 새로운 뭔가를 하느냐로 판단한다.
물론 업무만해도 A급인 사람을 보긴했지만, 아직은 업무 이외의 뭔가를 하는 사람이라고 생각한다.
쥬니어와 시니어를 가르는 것은 의사 결정과 책임이다.
5년차 개발자 조은의 생각
회사는 성과를 만드는 조직이고, 개발자는 성과를 내는데 명확하다.
맡은 업무 및 목표를 "잘"만드는 것이다.
"잘"이라는 기준은 애매하다.
어렸을 떄는 빨리 짜는 게 "잘"이었는데,
지금은 테스트도 "잘"하고, 설계도 "잘"하고, 탄탄하게 "잘" 만든다가 기준이 되는 거 같다.
시니어를 초월하신 20년차 CTO 신현묵의 생각
정말 띄어난 개발자는 탄력적이고 좋은 팀을 찾는 시각을 가진다.
일을 하다보면 과다품질을 가진 사람들이 보인다.
경력이 많으면 코드는 간결해진다. 과다 품질을 하는 사람은 주니어다.
쓸데없는 프레임웍을 사용하는 중급자도 주니어다.
우리팀, 우리 비즈니스, 우리 회사에 맞는 개발을 하는 정적기준을 찾는 자를 시니어라고 생각한다.
느낀점
세미나는 일방적인 연구자료에 대한 발표를 듣는 자리고,
컴퍼런스는 의견교환, 회의같은거라 생각한다.
당연히 개발자 커리어 컴퍼런스라 많은 의견을 나눌 수 있을 거라 생각했는데,
시간적인 한계가 너무나 많았다.
정말 시간이 너무 아쉬운 금쪽같은 시간이었다.
이직하자. 더 많은 경험을 위해서.
공부하자. 더 나은 경험을 위해서.
컴퍼런스 & 세미나를 많이 듣자. 새로운 시야를 위해서.
이 컴퍼런스를 듣고 바뀐점(바꿀려고 노력하는 점)
- github 시작. (기존 블로그 삭제 후 githubs 통합)
- 너무 회사에 목숨걸지 않기. (내 개인의 삶의 소중함을 깨닫기.)
- 소스는 간결하고 명료하게
- 회사 업무 외적인일 찾기