구글 캠퍼스 리쿠르팅 데이 후기 (2017.05.25)

구글 캠퍼스 리쿠르팅 데이가 있어 오늘 참가하였다.

많은 유명 스타트업 들이 참가 하였고, 회사에 대한 소개와 어떠한 채용포지션을 뽑고 있는지에 대해 설명하고 

각 분야 ( 개발자, 기획자, 마케팅 등 ) 커리어토크도 진행되었다.

시작이 저녁7시 인지라 식사를 못하신 분들을 위해 이렇게 김밥과 물도 지원 해주셨다. 

자 본론으로 넘어가서 

이번 이야기에서는 티켓몬스터의 CTO이신 이승배님께서 커리어토크에서 해주신 좋은 이야기들을 공유하려 한다. 

( 이야기를 재미있게 풀어주신 티몬의 CTO 이승배님 )

소프트웨어 엔지니어란?

많은 사람에게 물어보면 다음과 같이 답변한다.

1. 프로그램 짜는 사람

2. 소프트웨어를 설계하고 개발하는 사람

이승배님께서 생각하시는 소프트웨어 엔지니어란?

->가장 중요한 키워드는 문제라고 생각한다. 소프트웨어 엔지니어는 주어진 문제를 소프트웨어적으로 해결하는 사람.

이것이 가장 중요한 접근방법이라 생각한다.

소프트웨어의 방점이 있는 것이 아니라 사실은 문제라는 것에 방점이 있다.

많은 사람들이 다음과 같이 물어본다.

" 내가 무슨 기술이 부족합니까? "

" 무슨 기술을 가져야 합니까? "

" 내가 무슨 기술을 써야지 유망 하겠습니까? "

참고로 90년대 초 중반에는 세계에서 가장 돈 많이버는 DBMS회사에 자격증을 따면 먹고사는데 지장이 없다 라고 계속 이야기 했었다.

실제로 그 길로 나간 사람들도 많이 있었다. 하지만 세월이 바뀌니 달라졌다.

( 요즘에는 기술들도 워낙 빨리 바뀌고 하니 정해진 답은 없으며, 기술 습득 능력이 빠른 사람이 최고라는 것을 말하시는듯 하였다. )

나는 풀스택 개발자가 될꺼야, 나는 안드로이드 개발자가 될꺼야, 나는 iOS 개발자가 될꺼야 많은 

생각들을 하실테고 물론 나만의 특기를 가지는 것은 중요하지만, 근본 적으로 문제를 풀 수 있느냐 아니냐의 문제라고 생각한다.

그럼 그 문제는 어떻게 해결할까?

=> 창의적으로

좋은 아이디어를 원하는 것이 아니라,  될 때까지 해결하는 것이 중요하다. 

티몬에서 있었던 사례를 보자,

개발자가 일을 할때, 작업 큐가 16개가 넘어가면 사람이 처리할 수가 없는 수준이 된다. 그런데 회사에서는 160개씩 막 다 받는다. 그럼 작업의 큐는 없애야 하니 개발은 계속하는데 처리하는 속도보다 쌓이는 속도가 더 빠르면 개발자가 해야할 일은 끝이 없어지는 무한루프에 빠지게 되는 현상이 된다.

그럼 어떻게 해야하나? ( 이 부분이 창의적으로 문제를 해결한 사례를 이야기 해주신 부분  )

당신은 큐를 비우는 것이 목적인데 당신이 처리하는 속도보다 큐가 쌓이는 속도가 빠르니 이 큐는 못 끝낼것이라 판단, 비용청구 하는 부서에 가서 상황이 이러하니 큐를 비우기 위해 사람을 20명 더 뽑아주세요 라고 요구하였고 이후에는 큐를 비우는 사람, 비즈니스 플로우를 설계하는 사람, 시스템 기획 하는 사람 모두가 행복해 짐. 

( 이렇게 문제 해결을 하는데 있어서 모든 것이 소프트웨어 적으로만 생각 할 것이 아니라 크게 보고 문제를 해결 하는 방법도 있다는 것을 말씀해주심 )

하지만 창의적으로 생각하지 못하고 많은 개발자들은 업무 절차가 틀린 것은 당연히 나에게 주어진 숙련이고, 이걸 소프트웨어로 어떻게 풀어야 할것이냐의 문제로 생각 하는 것이 문제다.이것은 좋은 말로 하면 되게 착하고 나쁜말로 하면 되게 숙맥이다. 누가 쎄게 밀어 부치면 해달라는 대로 해준다.(매우동감) 하지만 대부분의 경우에는 이러한 업무 방식이 모두에게 행복하지 않은 결과를 가져온다. 

모두가 행복해지려면 어떻게 해야할까? 

비즈니스, 기획, 디자인, 다 뜯어 고칠 수 있다 라고 생각하자.

하지만 대부분의 개발자는 어떠한가?

나에게 주어진 요구사항은 이것이니 최선을 다해서 구현을 해야지라는 것에 초점이 맞춰져 있다.

여기서 내가 창의성을 발휘 하는 것은 내가 여기서 삼항 연산자를 써야 하는지, 이항 연산자를 써야하는 문제가 아니다.

이런 기술적 창의력도 중요하지만 사실은 더 앞쪽( 비즈니스, 기획, 디자인, 등등 )이 중요하다.

---

티몬에서는 어떤 인재를 채용하고자 하는가?

많은 사람들이 저는 뭘 더해서 저의 단점을 보완하고 실력을 키울 수 있습니까 라고 물어본다. 티몬에서는 인재를 뽑는 기준이 정말 단순하다.

1. 티몬 나름대로의 항목들이 있다. 이 모든 항목들에 과락만 면하고 최고점의 한개가 우리가 원하는 커트라인을 넘어야 한다.

    ex) 협업능력, 커뮤니케이션 능력, 설계 능력, 테스팅 능력, 구현 능력

많은 사람들은 상대적인 평가를 한다. 이 사람이랑 비교했을때 내가 뭐가 부족하지? 우리는 끓임없이 배운다.

But 내가 뭘 잘하는지 설명할 줄 알아야지, 나를 뭘 못합니다라는 것을 생각 할 필요가 없다.

대부분의 성장하는 회사들은 사람들을 채용할때 사람들을 절대평가로 평가한다.

항상 사람이 모자르기 때문에 항상 절대평가로 평가한다.

정말 사람이 귀하고 급한 회사들은 절대 평가를 한다.

그래서 티몬 이승배님이 면접을 볼때 면접자에게 물어보는 질문은 “뭘 잘하세요?”라는 질문을 자주하고

면접자 분들에게서 답변을 들었을때 “우와 정말 잘하시겠네요!” 라는 말이 나올 수 있게 설명을 해주기를 원하신다는 말을 하였다.

신입, 1년차와 같은 분들에게는 설마 코딩능력이 얼마나 좋은지 증명해보세요 라는 의도로 질문 하는것이 아닌,

훌륭한 소프트웨어 개발자가 되기위해 당신이 갖추어야할 덕목 중에서 당신이 잘하는 것이 뭐라고 생각합니까?

1. 커뮤니케이션 능력

2. 협업 능력

3. 문제해결 능력

따라서 신입의 경우 면접을 볼때 - 까다로운 문제를 많이 낸다

( 문제 내는 항목은 - 여러분이 전공 3학년 1학기 안에 배운 전공과목 안에서만 낸다. )

---

좋은 개발자가 되기 위한 3가지 방법

* Step-1. 개발자가 무언가를 하기 위해선 학습능력이 있어야 한다.

내가 오늘 무언가 했는데 내가 한 이것이 모르는거면 알 때까지 한다.

ex) 내가 선배에게 뭔 가를 물어봤을 때 맵이라는 인터페이스에 해쉬맵을 써라고 한다면, 맵이라는 인터페이스가 어떠한 역할을 하고 해쉬맵은 어떻게 동작하는지 그리고 해쉬맵이 있다는 것은 다른 맵들도 있다는 것이니 그 외에 것들도 궁금해야 한다. 이러한 것들을 파고들고 알때 까지 해본다. But 우리는 시험에 나올것만 공부 해왔기 때문에 학습 능력이라는 기준이 뭐냐면 내가 이걸 알았을때 과연 실용적인 효과가 있느냐 없느냐로 판단짓는다.

그리고 개발자들이 오늘 이런이런 문제가 있었는데 해결했어요 라며 나에게 와서 

원인, 현상, 내가 접근한 방법에 대해서 이야기 해준다.

하지만, 왜 해결 됬는지에 대해선 언급이 없다. 

"구글 스택오버 플로우를 찾아봤더니 이렇게 하면 해결된다고 해서 했더니 해결됐다.”

이렇게만 하고 끝내는 분들에게 하고싶으신말 “안.궁.굼.해?"

개발을 하는데 있어서 내가 모르는 부분에 대해서 건전한 호기심이 정말 중요하다!

들려주신 이야기의 한 예로 사내에 14~15년 동안 C언어로 이미지 프로세싱만 한 사람이 있다. 

이 분에게 C 이미지 프로세싱에 대해서 물어보면 단 한번도 막힘 없이 모든 것을 상세하게 이야기 할 수 있는 능력자분이라고 하신다.

이승배 님께서 그 분을 채용 했을 때 다음과 같은 질문을 하셨다.

“저희 회사 Java쓰는 데 괜찮으세요?”

“네”

“저희 회사 커머스 개발 하는 회사인데 괜찮으세요?”

“네”

“제가 뭘 도와드리면 될까요?”

“일주일만 시간주시면 제가 배워서 할게요”

그리고는 정말 일주일만에 다 배워서 큰 무리 없이 개발 진행을 하셨다.

이러한 예를 보면 정말 내가 어떤 상황에 떨어져도 스스로 학습하고 적용할수 있는 능력은 정말 중요한 것이다.

언어를 공부할때 가장 중요한 학습능력이란?

    1. API습득능력

    2. 설계패러다임을 얼마나 잘 활용하느냐

        ( 자바는 자바답게!, 노드는 노드답게!, 스칼라는 스칼라답게! ) 

* Step-2. 문제 해결능력

능력자가 되려면?

다독(多讀)

다작(多作)

다상량(多商量)

문제 해결능력을 키우기 위해선, 많은 코드를 접하여 읽고, 따라 흉내내보고, 깊이 생각해야 한다.

* Step-3. 브랜드와 키워드

시니어 레벨이 되면 브랜드와 키워드가 중요하다.

개발도 잘하고, 기획도 잘하고, 디자인도 잘하고, 이런 모두를 잘하는 사람은 없다.

만약 “ㅇㅇㅇ씨 일잘 하나요? 어떤 사람인가요?” 라고 물어봤을 때, 그사람 어떤 사람이다 라고 이야기할 수 있는

브랜드나 키워드가 있어야 한다.

나는 엔지니어 측면에서 뭘 잘합니다 라고 이야기 하는것이 가장 중요하다.

한 예로 승배님께서는 예전에 난 디버깅 못하고, UI 프로그래밍 못하니 앞단에 넣어주세요 라고 이야기 하셨다고 한다.

내가 Apply 하려고 하는 회사에서 내가 비즈니스 측면에서 무엇이 도움이 될까?

( 회사 마다 달라야 함 )

ex) 비즈니스와 협업을 해서 문제를 해결할 줄 아는 테크니컬 리더입니다.

인성

요즘 면접에서 자기의 성격에 대해서 장단점을 이야기 해보세요 물어보면

다 똑같이 대답한다고 한다.

-> 남과 다른 장점을 이야기 해줘야 한다. 그래야 회사에서는 판단이 쉽다.

만약 자신이 서비스를 만드는 사람이기 때문에 굉장히 테크니컬 한 회사랑은 맞지 않는 경우가 있다.

이러한 부분은 정말 중요하다. 만약 이런 회사를 가게 된다면 죽었다 깨어나도 자신과 맞지 않을 수 있다.

( 자신은 서비스를 만드는 것을 좋아하는데 굉장히 테크니컬한 회사를 가면 일적 스타일이 맞지 않아서 괴울 수 있다는 말이신듯 )

나는 내가 아이디어 낸 것이 일주일 내에 내 눈 앞에서 돌아가야 하고, 그 사이에 통계가 나와야 하고 수치가 나와야 한다.

이런 경우 나는 비즈니스에 밀착해서 일하는 사람입니다 라고 표현하는 것이다.

---

개발자는 게으르고 귀찮아야 발전이 있다고 생각한다.

이야기를 마무리 하며, 두 가지 면에서 말씀 드리고 싶다.

1. 즐겨라 - 소프트웨어 개발자의 모든 분야가 즐거워야 한다.

아는 사람은 좋아하는 사람만 못하고 좋아하는 사람은 즐기는 사람만 못하다.

나는 엄밀히 말하면 코딩을 하는 사람이지만 잘 안맞는 사람이었다 하지만 사람들과 토론하는걸 좋아했다 그래서 아키텍처를 많이 한 것 같다 그리고 잘하는것 같다. 

여러분들이 잘하는것을 극대화하여 즐겼으면 좋겠다.

2. 우리 한국 사람들은 빨리 습득하고 빨리 결과물을 내는 것을 잘한다. 이것은 장점이라 생각한다.

    서비스 만들때 이 장점들을 잘 활용했으면 좋겠다.

---

후기

구글 캠퍼스 리쿠르팅 데이가 끝나고 집에가는 지하철에서 내내 "내가 가장 잘 하는 것은 무엇을까?" 라는 고민에 빠지게 되었다. 정말 간단한 질문이지만 답을 내리기가 쉽지 않았고, 이 질문을 소프트웨어 적으로 접목하여 생각하니 더욱 답변 하기가 어려운 기분이 들었다. 가만히 생각해보면 나도 지식을 습득하기 위한 노력을 많이 하였고, 문제 해결을 위한 호기심은 가득했지만, 정작 문제가 해결 되고 나면 왜 해결 되었는지를 놓치고 지낸것 같다. 왜 그랬을까? 라고 생각을 해보면 그렇게 하면 학습 속도가 너무 느린것 같아 그렇게 하지 않았던 것 같다. 문제 해결을 했으니 다음 스탭으로 넘어가또 다른 부분에 대해 공부하고 싶었지, 정작 왜 문제 해결이 되었는가에 대해 가장 근본적인 부분을 놓치고 지나친것 같다.

곰곰히 생각 해보았다. 정말 파고들고 파고들고 하는 것이 정말 나에게 엄청난 발전이고 도움되는 일일까? 

고등학교 학창 시절까지 거슬러 올라가보면 왜 내가 가장 중요한 스탭인 왜 해결되었나?를 놓치게 된 계기는 다음과 같은것 같다.

- 남들 하는 만큼만 공부했다 ( 공부에 게을렀다 ).

- 하지만 내가 원하는 공부 방식은 알 때까지 파고들고 파고들고 하는 방식이었다.

- 친구들 또는 선생님에게 질문을 할때면 고개를 절레절레 할 정도로 너무 불필요 한것 까지 깊숙히 알려고 한다고 핀잔을 들었다.

- 그럴때마다 듣는 이야기 “그런것 까지는 시험에 안나와, 필요한 것만해” 

- 결론은 그렇게 느린 학습(?)을 하다보니 성적은 늘 좋지 않았던것 같다. 

  ( 공부에 투자되는 시간 대비 너무 깊게 파고들려고 하다보니 정작 시험에 나올 분량을 다 공부하지 못하는 현상 발생 )

그래서 얻은 결과는 남들과 똑같은 시간을 공부는 해도 결과는 나쁜 성적이었고, 그 이후에는 좋은 성적을 받기 위해 나와는 맞지 않은 학습 방법을 나에게 맞추려고 하면서 살아 온 것같다. (사실은 공부를 더 많이 했으면 됬을텐데 재미가 없어서 게을렀던것 같다. )하지만 이승배님 말을 듣고나서는 조금더 느린 방법을 선택 하더라도 내가 개발일을 1~2년 하고 그만둘게 아니니 장기적으로 봤을때 나쁘지 않은 방법이라 생각하게 되었다. 커리어토크 이후 스스로 반성 하는 계기가 되었고, 앞으로 어떻게 학습능력을 키워 나가야 할지 감이 잡힌것 같아 기분이 좋다. 내가 개발자로 커리어를 쌓아가는데 상대적인 평가가 아닌 절대적 평가로 나를 판단하고 뒤돌아 봐야겠다는 생각을 하게 되었다.

좋은 말씀 해주신 이승배님 감사드립니다.