쏘카 CTO님 오픈토크 다녀온 썰.ssul

 

 

 

---

 

 

나를 3번 떨어트린 회사에서 오픈토크를 한다더라

SSAFY 활동이 끝나고 동문회를 가입했는데 어느 날 문자가 왔다.

"쏘카 류석문 CTO님과 함께 나누는 IT 트렌드 이야기"

신청해볼까 고민하던 찰나 동기들이 같이 가자고 해서 지원을 하게 되었다.

추첨을 통해 오픈토크 이후에 CTO님과 소규모 대화 시간을 가질 수 있었는데

쏘카에 3번 떨어졌다고 어필한 덕분인지(?) 뽑힐 수 있었다.

처음으로 쏘카에게 합격을 받은 순간이었다.

그래서 저는 왜 떨어트리셨ㄴ...

 

시간 변동성이 없는 개발자가 되자

오픈토크에서 다양한 이야기를 들을 수 있었는데 그중에서 인상 깊었던 내용을 적어보려 한다.

나는 요즘 좋은 개발자는 무엇일까, 좋은 코드는 무엇일까에 대한 고민들을 하고 있는데

류석문 CTO님께서 마침 이 이야기를 해주셨다.

 

세상에는 많은 종류의 개발자들이 있다.

서버 개발자, 웹 개발자, 네트워크 개발자, 모바일 개발자, PHP 개발자 등등...

시장은 계속 변화하기 때문에 하나의 기술로 평생 먹고살 순 없다.

어떤 기술은 흥하는가 하면 어떤 기술은 지기 마련이다.

그렇기 때문에 하나의 분야에 묶여버리면 안 된다.라고 말씀하셨다.

랭귀지가 나의 정체성이 돼서는 안 된다.

 

내 기술 스탯

 

이 이야기를 듣고 나는 정곡을 찔린듯한 기분이었다.

나는 안드로이드 개발이 좋다는 이유로, 안드로이드 개발자가 꼭 되겠다는 이유로 한 우물만 팠기 때문에

스탯을 육각형으로 나타내면 위의 파란색 스탯과 같다고 생각한다.

안드로이드는 현재 나의 정체성과도 같다.

그런데 앞으로 10년 뒤에도 안드로이드 기술이 꾸준히 각광받을 거라 보장할 수 있을까?

아예 사라져 버리는 것은 아닐까?

 

그래서 CTO님이 말하시길

시간 변동성이 없는 개발자가 되라고 말씀하셨다.

10년 뒤 채용시장에서도 먹히는 사람이 되라고.

특정 랭귀지에 종속되지 말고 어떤 상황에서도 회사가 채용하고 싶어 하는 개발자가 되라고 하셨다.

 

플레이스토어의 한 개발자분께 조언을 구하고자 메일을 보냈었다.

 

예전에 앱 개발을 하다가 혼자 해결하기 어려운 고질적인 문제가 있어

다짜고짜 플레이스토어의 한 개발자분께 메일을 보낸 적이 있다.

분명 메일 말머리에 "저는 안드로이드 개발자를 희망하고 있습니다"라고 소개를 했는데

서버, 클라이언트 개발 모두 열심히 하시면 좋을 것 같다는 말을 듣고 당시에는 이해가 가지 않았다.

 

왜지? 나는 안드로이드 개발자가 되고 싶다고 했는데?

안드로이드만 할 줄 아면 되는 거 아닌가?

지금 생각해보면 류석문 CTO님과 비슷한 의미로 말씀하셨던 게 아닌가 싶다.

회사에서 원하는 인재는 파란색 스탯을 가진 개발자가 아니라 (육각형 스탯에서)

회색 스탯을 가진 개발자구나 라는 것을 깨달았다.

 

핵심은 처음부터 기술 분야를 넓히라는 것이 아니라
하나의 기술을 깊게 파고 그다음 기술의 깊이를 가지는 것을 목표로 하라고 말씀드리고 싶어요.

- 기술을 깊게 가지는 것과 넓게 가지는 것 중 무엇이 중요한가요? 에 대한 CTO님의 답변 中 -

 

적절한 논리력을 가지자

이 주제도 꽤 흥미로워서 기억이 난다.

100만 명이 이용하는 앱에서 그에 맞는 품질의 로그인 서비스를 개발했다고 하자.

사용자도 만족하고, 개발자도 훌륭하게 개발을 잘했다고 볼 수 있다.

이번엔 100명이 이용하는 앱에서 아까 100만 명 앱 급의 서비스를 개발했다고 하자.

사용자는 만족할 것이다. 그러면 개발자는 개발을 잘했다고 볼 수 있을까?

정답은 아니다.

 

사용자는 사용하는 입장이기 때문에 기능이 좋을수록 좋겠지만

개발자는 주어진 비용 내에서 개발을 해야 한다.

프로젝트 기간이나, 예산 따위를 고려할 필요가 있다는 것이다.

이렇게 과하게 개발을 하는 것을 오버 엔지니어링이라 부른다.

류석진 CTO님은 오버 엔지니어링을 피할 수 있는 적절한 논리력을 가지자고 하셨다.

 

이번에 나도 해커톤을 하면서 이 부분에 굉장히 많이 공감할 수 있었다.

기획자와 디자이너는 사용자 입장에서 생각하기 때문에

새롭고 다양한 기술을 넣으려고 하는데

개발자인 내 입장에서는 2박 3일이라는 짧은 시간 안에 개발을 해야 하기 때문에

이 부분에 협의점을 찾는 일이 꽤나 어려웠다.

개발하려는 서비스가 과한지 아닌지 판단할 수 있는 논리력과

이를 비 개발자들에게 설명하고 설득할 수 있는 능력

이것이 개발자에게 요구되는 스킬인 것 같다.

 

코드 리뷰는 버그 찾기를 하는 것이 아니다

여태까지 팀원의 코드에서 버그나 잠재적인 문제를 찾으면 뿌듯함을 느꼈었다.

내가 리뷰를 잘하고 있군! 하면서 스스로 칭찬을 하기도 했다.

그래서 이 말을 듣고 충격을 받았다.

그럼 여태까지 내가 해온 리뷰가 잘못되었다는 거야...? 😱

 

CTO님 왈, 코드 리뷰는 Readable한 코드인지 아닌지를 보는 것이라고 한다.

버그가 발견되면 그건 작성자가 아직 준비가 안된 것이며

읽기 좋은 코드라고 생각되면 얼마든지 LGTM을 날려도 된다고 하셨다.

 

생각해보면 내가 팀원들과 코드 리뷰를 시작하고부터 버그에 대한 책임감을 덜 느끼게 된 것 같다.

어차피 팀원들이 내 코드를 한 번 쫙 읽어줄 테니까,

나중에 버그가 터지면 리뷰 때 발견 못한 팀원들의 책임도 어느 정도 있을 테니까

라는 생각을 무의식 중에 했던 것 같다. (이런 못난 놈!)

코드 리뷰는 버그 찾기가 아니다.

PR에 올라오는 코드는 이미 충분히 검증된 코드여야 한다.

코드 리뷰는 깔끔하고 읽기 좋은 코드를 작성하기 위한 리뷰라는 것.

이제부터 기억해야겠다.

 

마치며

사실 이것 말고도 도움이 되는 내용들이 정말 많았다.

하지만 블로그에 다 적어버리면 CTO님의 강연 내용이 스포가 되어버리니깐...

궁금하신 분들은 직접 강연을 가보시길! 추천드립니당

 

앞으로 이런 강연을 많이 들으러 다녀야겠다는 생각이 들었다.

누군가 반 평생 직접 겪으면서 배운 것들을 듣는다는 건

내 생각과 행동에 긍정적인 영향을 줄 수 있는 것 같다.