[Diary] 개발자 팁 영상을 보고 나서… 1탄 이력서 편

eo의 개발자 특집편을 보다

코드스테이츠 개발자 커뮤니티 채널에 올라온 유튜브 영상 하나가 있었다.
eo채널의 베테랑 개발자들이 인정한 필살 이력서 大공개 | 개발자 특집 2편.
한창 매일매일 이력서를 조금씩 손보며 입사 지원을 넣는 내게는 반드시 봐야 할 영상이었다.

제목만 봐도 ‘이런 이력서라면 회사가 뽑을 것이다’라는 내용을 담을 것 같아서 재빨리 봤다.
영상에 나오는 인물들 중에 한 분은 내가 이력서를 쓸 때 참고했던 분이었다…!
실제 참고 이력서를 보면서 얘기를 나누는 거다 보니, 그냥 이력서만 볼 때와는 또다른 면을 참고할 수 있었다.

이력서에 제목을 넣다.

위 이미지는 유튜브 영상에 나온 원희 님의 이력서 일부이다.
원희님은 이와 같이 설명했다.
이력서를 쓸 때는 제목이 제일 자극적으로 쓸 수 있는 요소임과 동시에, 후킹하는 요소가 될 수 있다.
그런데 이름만 쓰는 이력서가 많다. ㅇㅇㅇ라는 이름만 보고 ‘오, 좋은데?’라는 반응은 하기 힘들 것이다.
그렇기 떄문에 ‘이 사람이 왜 날 알아봐야 하는지 한 줄로 탁 꽂아주는 것’이 후킹하는 면에서 좋다고 생각된다.

또한 채용 담당자 입장에서는 되게 많은 이력서를 검토하기 때문에 일단 눈에 들어오는 게 중요하다.

이력서 제목에 맞게 나의 성과를 쓰기

위의 내용에 이어서, 채용 담당자 입장으론 개발자도 결국 비즈니스 밸류를 창출하기 위한 사람이고, 개발이라는 기술을 이용하는 사람이라고 생각할 것이다.
그렇기에 ‘나는 이런 개발을 해서 좋아진 같다.’가 아니라, 내가 이런 일을 했더니 매출이 이만큼 상승했다, 같은 나의 성과를 객관적인 지표로 보는 사람이다, 라는 걸 어필하고 싶어서 제목을 ‘데이터로 일하는 개발자’라고 선정했다고 한다.

우아한 형제들 대표님 왈,,,

우아한 형제들 대표님의 글 중 ‘일 잘하는 법’에 다섯 번째 내용이 개발자가 개발만 잘하고, 디자이너가 디자인만 잘하면 회사는 망한다.이다.
그래서 원희 님의 이력서 제목인 ‘데이터를 중요하게 여기면서 일을 하는 개발자’와 ‘그렇지 않은 개발자’가 뭐가 어떻게 다른지 생각해 보자.

원희 님은 개발자들이 주로 하는 얘기가 ‘클린 코드를 짜야 해.’예쁘고 아름다운 코드를 짜야 해’라며 그거에 대해 공부를 많이 하는 경우가 있다.
그렇지만 이는 완전히 맞는 말은 아니다. ‘아름다운 코드가 전부가 아니다.’
좋은 코드가 우리 비즈니스 성장에 얼마나 기여했는가를 한 번이라도 고민을 더 해볼 수 있다는 있는 게 ‘데이터’라는 도구라고 생각을 해서,
데이터를 보는 개발자들은 내가 짜는 코드가 몇 줄이든 그 몇 줄의 코드가 어떤 비즈니스적인 가치를 갖고 있는지 숫자로 확인하는 사람이라 생각한다. 즉 이 점이 차이라고 생각한다, 라고 얘기했다.

이력서에 매력 담기

이력서에서 나를 어떻게 표현해야 할지 모르겠는 사람들이 많다.
구직자들의 고민 리스트.

• 나도 내 매력을 모르겠다.
• 나만의 강점이 뭐지?
  
  

원희 님의 조언은 다음과 같다.

방법 1. 주변 동려들에게 물어보기.

나랑 일할 때 어떤 게 내 인재로 느껴져?
같은, ‘나의 강점을 타인의 시선으로 뽑아내는 것’이 하나의 방법이다. 실제로 이로 인해 나도 모르는 내 강점을 알게 될 수도 있다.

만약 물어볼 주변 동료가 없다면?

방법 2. 나의 활동 리스트업 하기

그동안 내가 했던 활동들을 쫙 나열해 보는 것이다.
그러면 반복되는 키워드들이 있음을 발견할 수 있을 것이다.
그 반복되는 키워드를 활용하면 된다. 제목으로도 선정할 수 있다.

조은 님은 다음과 같은 방법을 얘기했다.

방법 3. 15분 일기 쓰기

15분 시간만 맞춰 두고 일기를 쓰는 것이다.
그러면 시간 제한 때문에 내가 쓰고 싶었던 내용만 쓰게 된다는 게 특징이다.
그 내용에서 ‘아 내가 이런 사람이기를 원하는구나’, 같은 순수한 욕심이 드러나게 된다.
그 키워드를 이력서에 풀어내는 것이다.

방법 4. 이력서 자주 업데이트 하기

사람의 기억력은 생각보다 짧다.
그렇기 때문에 매달 업데이트하는 게 좋고, 이전 이력서를 돌아보다 보면 ‘내가 이 시점에선 이걸 중요시여겼네?’ 같은 것들을 돌이켜볼 수 있는 시간을 가질 수 있다.

높은 합격률의 원희 님 이력서 포인트는?

원희 님의 이력서 초반엔 Introduce라는 소개파트가 있다.
이 파트에 대해 사람들 의견이 많은데(있는 게 좋다, 안 좋다 등), 원희 님은 자신의 이야기를 글로 풀어내는 것에 자신이 있었고, 강점이라고 생각해서 이 포인트를 넣었다고 한다.
(나도 ‘Introduce’를 넣어 채용 담당자 뇌리에 이야기를 담아내겠다는 의지로 두 문단만 간략하게 넣었다.)

‘내가 이런 거에 관심이 있어요’만 적기엔 신뢰도가 부족하니, ‘내가 이런 거에 관심이 있어서 이런 일들을 했다’라는 내용을 빠지지 않게끔 노력했다고 한다.
나의 실제 사례, 나의 노력 같은 걸 녹이면 좋다.

인프런의 CTO 이동욱 님은 원희 님의 이력서의 좋은 점 첫 번째는 구체적인 숫자로 표현한 것이라고 한다.
기업에 첫 번째 개발자로 들어가서 50억 투자를 유치하고 40명 규모의 팀으로 성장할 때까지 ~~… 이러한 문장이 좋다는 것이다.

두 번째 좋은 점은 성과를 이력서에 잘 녹여낸 것이다. 위의 문장 자체가 그러함을 잘 표현했다.

조은 님은 이러한 Introduce 소개 파트를 쓰면 좋은 점으로 채용 담당자가 어떤 면을 중점적으로 이 이력서를 봐야 하는지 알기 쉬워진다고 한다.

원희 님은 자신이 작은 스타트업 회사 출신이기에 채용 담당자가 이 회사를 모를 수 있겠다는 생각을 했기에, 숫자적으로 어떠한 성과를 냈는지 적으려고 노력했다고 한다.
또한 어떤 역할로 어떤 일을 했는지도 최대한 숫자나 의도를 쓰려고 했다고 한다.

내가 이 일을 한 이유는 이러한 목적이 있기 때문이다.
내가 이 일을 했기 때문에 이러한 개선이 있었다.

이러한 아웃풋(결과물), 아웃컴(성과)을 쓰려고 한 것이다.

이 얘기에 커리어 액셀러레이터 김나이 님도 ‘결과’, ‘성과’, ‘숫자’ 포인트가 너무 좋다고 집었다.
실제로 수많은 개발자 이력서를 볼 때 이 포인트들이 빠진 경우가 많다고 한다.
사실 그 자체보다 밸류(가치)가 더 중요함을 알아두면 좋다.

웹 이력서 비결

요즘 웹 이력서를 많이 쓰는 추세이다.

링크 달기

매력은 디테일에서 나온다고 생각하는 원희 님은, 웹 이력서의 경우 링크를 달 수 있다는 점이 그 디테일을 살릴 수 있어서 좋다고 생각한다고 한다.
또한 기록할 수 있는 링크는 최대한 링크를 달았다고 한다.

많은 링크? 무조건 좋은 건 아니다

동욱 님은 링크가 무조건 많다고 좋은 건 아니라고 한다.
링크는 적절한 곳에 들어가야 한다. 궁금한 포인트마다 들어가면 좋은 것이다.
이 활동이 뭐였을까? » 링크 들어가면 상세히 있음 / 이 활동은 뭐지? » 링크 들어가면 상세히 있음
이러한 이력서는 끝나지 않았으면 하는 드라마를 보는 느낌으로 보일 정도로 좋다고 한다.

사수 없는 주니어

여기부터는 이력서 자체의 내용보다는 면접에서 이뤄질 것 같은, 혹은 참고할 만한 개발자 얘기들이 담겨 있다.

원희 님은 사수가 없는 곳에 첫 개발자로 취직했었다.
사수가 없어서 힘들었을 것 같은데 어땠냐는 질문에, 원희님은 이렇게 대답했다.
독서모임 회사에 자신이 들어서니 문과생들 사이에 혼자 있는 개발자가 되었었다고 한다.
심지어 IT 쪽 경력이 있는 직원분도 없고, 그동안 외주 업체들의 짜집기식 프로그램들만 있었다고 한다. (=굉장히 열악한 환경)
주니어였던 원희 님은 매우 힘들었지만, 해결을 내부가 아닌 외부에서 하려고 했다.
뻔뻔함이 이때 많이 성장했다고 하는데, 대표님 친구 중 CTO가 있다면 그분을 소개해 달라 하고는 ‘ㅇㅇ님 제가 이런 문제가 있는 어떻게 해결하면 좋을까요?’ 같은 조언을 구하며 이곳저곳 다 찔러봤다고 한다.

이에 나이 님은 내부에 사수가 없다면 밖에서라도 만든 것 같다고 했다. 또한 이런 자세로 일해서 빠르게 성장하신 것 같다는 얘기도 했다.
한편으로 이러한 경력 때문인지 원희님은 리드만 다섯 번을 한 경험이 있는데, 일반적인 개발자보다는 제너럴한 관점을 가졌을 거 같다는 질문도 이었다.

그에 원희 님은 다른 개발자분들에 비해 좀 더 비즈니스적인 것 같다는 답을 했다.
이 회사에 내가 얼만큼 기여를 하고 있는가, 내가 했던 일들이 얼마나 비즈니스 임팩을 만들고 있는가를 제일 중요시여겼다고 한다.
원희 님이 초기 스타트업에 많이 있었던 이유는 초기 스타트업은 손만 대면 해결할 수 있는 문제들이 많고, 그 임팩트가 크기 때문이라고 한다.
눈에 밟히는 것들을 오지랖을 하나씩 부리다 보니까 자연스럽게 제네럴리스트가 됐다고 한다.

하지만 지금은 전문성에 대한 고민이 생겼는데, 조금 더 큰 규모의 스타트업에 일하기 시작하며 문제가 생겼다고 한다.
예전에는 5만 가지고 있어도 성과를 낼 수 있었는데, 더 큰 스타트업에서는 그게 더 이상 안 되는 시점이 왔다고 한다.
그래서 요즘은 발을 넓히는 것보단 한 가지에 뾰족하게 집중해서 전문성을 쌓으려는 노력을 한다고 한다.
회사 규모에 따라 필요한 역량이 다르다는 것을 알았기에, 그걸 제너럴리스트분들이 알았으면 좋겠다고 한다.

개발자 소통 문제

다양한 직무를 경험해 본 원희 님에게 나이 님이 질문하다.
비개발 직군과의 소통을 어떻게 생각하는가?

개발 직군이 아닌 분들은 어떤 게 개발로 해결되는지도 모르고, 개발 관련 문제를 어떻게 요청해야 하는지도 모르는 경우가 많다.
말을 해서 싸우면 해결하면 되지만, 개발을 몰라서 말조차 못하는 상황이 온다는 것이다.
그래서 원희 님은 비개발 직군의 입장에서 소통을 하려고 했었다고 한다.
다른 직무의 분들이 겪는 문제를 캐치해서 같이 얘기해 보는 것이다.

그래서 이 사이클을 한번 돌면 비개발 직무 부들도 개발 프로세스에 대해 어느 정도 이해를 하기 시작한다고 한다.

사실 난 이 부분을 듣고 어느 직무 파트에 있던 다 그래야 하지 않나, 라는 생각을 했다.
개발자든, 영업자든, 기획자든, 다른 파트의 입장에서도 생각할 줄 알아야 한다는 것이다.
원희 님 같은 분들이 각 파트마다 존재한다면, 정말 더할나위 없는 기업이 탄생할 것 같다.

자기만의 단어 사전을 없애라

동욱 님이 면접에서 자주 질문하는 것 중 하나는 개발적으로 어떤 사고가 났는데 이 사고를 눈앞의 면접관들이 개발을 모르는 사람들이라고 가정하고 설명해 봐라라고 한다.
동욱 님은 회사 개발자 직원들에게 자주 강조하는 것이 자기만의 단어 사전을 없애라라고 한다.
자기 머릿속에는 기술적인 용어들이 다 정리되어 있으니까 그 용어를 쉽게 쓰지만, 그 용어가 없다는 셈 치고 설명을 하는 게 습관이 되어 있어야 다른 직군이랑 빠르게 이야기를 하기 때문에 그렇다고 한다.

유독 개발 직군만!

조은 님은 개발 직군만 유달리 다른 직군과의 소통에 문제가 생기는 경우가 많은 것 같다고 한다.
왜 개발자만 문제가 생길까? 라는 고민을 하다가, 개발자는 근본적으로 다른 직군과 커뮤니케이션을 자주 안 했던 것이 원인인 것 같다고 한다. 즉, 기존에 커뮤니케이션을 안 했다는 것이다.
개발이라 하면 그들만의 세상이 있다는 오해가 있고, 심지어 개발자들 본인도 그렇게 생각하고, ‘말이 안 통하겠지?’라는 인식을 갖는다는 것이다.
기술의 이해도가 문제가 아니라, 서로의 오해로 인한 평행선을 그리고 있다는 문제인 것 같다고 한다.
이 평행선을 허물고 없애려는 노력이 필요하다는 게 조은 님 의견이었다.

나는 이 얘기를 들을 때 개발 직군이 아니었던 때를 생각하면 그렇다, 싶으면서도 이 또한 앞서 말했던 것처럼 어느 직군이든 다른 직군에 대해 그렇게 생각할 수도 있겠다고 생각했다.
물론 개발 직군의 경우 한글, 영어 등의 기본 문법이 아닌 컴퓨터 프로그램 언어를 사용하는 직군이어서 더 선이 그어질 수도 있겠다.
그러나 어느 직군이든 본인의 툴을 갖고 일을 하는 것은 매한가지이니, 소통 자체는 어느 직군이든 중요하다고 생각한다.
그런데 역시, 전문가분들 말씀처럼 개발 직군 자체가 그렇다, 한다면, 조은 님이 말씀하신 것처럼 근본적으로 평행선을 그으려 한 과거의 이력들이 문제가 아닐까 싶다.
나는 개발 비전공자로서 이 분야, 저 분야 여러 가지를 경험해 봤으니, 소통을 해 보려고 노력해야겠다는 생각이 이 영상을 보며 더욱 강하게 들었다.

카카오페이로 커피사기 ❤️ 토스 계좌로 커피사기 ❤️