brunch

라이킷 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 이십사 Dec 17. 2022

선배 CTO에게 배운 것들

앞서 간 사람은 지혜가 있다.

1. 개발자를 보는 안목

Q. 제가 부족한 탓이겠지만, 실력을 가늠하기가 쉽지가 않습니다.

알고리즘, 깃헙, 포트폴리오(블로그) 이 세가지를 직접 보아도 개발을 잘 하는지 알기가 어렵습니다.

우선 코딩테스트는 난이도를 어느 수준으로 조절해야하는지 고민인데, 너무 어려운 수준까지는 필요 없다고 생각하여 난이도를 조절하였더니 변별력이 크게 없는 것 같고, 포트폴리오는 물론 좋은 수단이지만 그렇다고 실력이 확연하게 드러나지는 않는 것 같습니다. (특히 팀으로 진행한 경우에)

또한, 보통 개발실력과 커뮤니케이션(협업 능력) 두 가지로 지원자를 평가한다면. 어느 부분을 더 중요하게 생각하시나요? 이번에 지원한 분 중에 이전 회사에서 다소 이기적인 업무성향 때문에 평이 좋지 않은데 실력은 괜찮아보이는 분이 있어서 더 고민이 되는 상황입니다.

A. 스탠다드를 높게 설정하고 거기에 맞추려고 하니까 개발자 뽑기가 힘든 건데, 어차피 대기업말고 스타트업에 오는 분들은 그 스탠다드가 엄청 높을 거라고 생각을, 기대를 하면 안된다. 그만큼 대우해주지도 않지 않는가? 차라리 대기업하고 다른 무언가를 만들어서 스탠다드를 맞출 생각하는게 좋다. 함수형 프로그래밍 언어를 좋아하는 사람이 올 수있도록 판을 짜놓았는데, 대기업에서는 그런 환경을 제공하지 않기 때문에 오는 사람이 있다. 이렇게 뭔가 다른 방식으로 좋은 개발자를 데려오는 것도 방법이다.

그리고, 잘 내보내는 것이 중요하다. 썩은 사과는 그 주위 사과도 같이 썩게 만든다. 그래서 정말 문제가 있는 분이라면 잘 보내줘야 한다. 맞지 않아도 보내줘야한다. 굳이 사람 고쳐쓰려고 하지마라.

2. 좋은 개발팀을 만드는 방법

느린 방법과 빠른 방법이 있다.

느린 방법은 한 명 한 명 잘 뽑아서 잘 가르치고, 개발 문화를 아주 해피하게 가져가는 그런 방법이다.

빠른 방법은 애초에 기대를 많이 하지 않고, 잘하는 사람을 많이 뽑고 약간은 외주처럼 굴리고 또, 그만큼의 보상은 해주는 방법이다.

R사는 느린 방법으로 했지만, 경쟁사인 K사는 후자의 방법으로 했다. 지금 K사는 비교 불가능한 정도의 성장을 이뤄냈기 때문에 뭐가 더 좋냐고 봤을 때, 당연히 개발자 입장에서는 전자가 좋겠지만 오히려 큰 회사에서 성장하는 경험을 쌓은 후자도 만족할 수 있다.

회사의 프레임을 어디에 두느냐에 따라서 개발팀 구성의 전략이 굉장히 달라진다.

3. 개발과 코드리뷰, PR, 매니징 관련, 채용 등 업무를 어느 비중으로 했는지?

- Q. 업무가 너무 겹쳐서 내가 병목이 되는 느낌이 조금 든다.

- A. 코드는 20~30프로 밖에 짜지 못한다. 리뷰도 거의 잔소리만하고, 채용이 중요하다보니 매일 면접을 본다.

이렇게 될 수 있는 건, 다들 경력이 있어서 알아서 하기 때문이다.

또 하나의 팁은 코드 리뷰에서 뭔가를 뒤집기는 힘들다. 계획 과정에서 훨씬 더 고민을 많이 하게 해라.

4. 팀에 따른 개발자 채용 규모

- Q. 회사에서 개발자 채용 규모를 어떻게 정하셨는지가 궁금합니다.

욕심 같아서는 개발자를 더 모셔와서 프로덕트를 더 만들고 싶은데, 그 때 발생하는 커뮤니케이션 비용이 만만치 않을 것 같아서 다소 망설여집니다. 혹시 이 부분에서도 조언을 구할 수 있을까요? 최소 몇 개월 전에 맞춰서 해야하나?

- A. 헤드카운트를 정해놓고 하기는 쉽지 않다. 이것 역시 회사의 프레임에 따라 다르다.

5. 주니어와 시니어 중에서 어떤 개발자를 선호하시는지?

- A. 시니어다. 심지어 시니어도 와서 온보딩을 4주간 한다. 주니어 뽑을 생각은 없다.

6. 지금 회사는 어떻게 조인하게 되신건지?

- A. 서비스의 방향성이 마음에 들어서 합류했다.

7. CTO로서의 성장을 하는 방법

- A. R사에 근무할 때는 최신기술들(Js, ML, 데이터 등)에 대해서 내가 미리 알아야 한다고 생각해서 그 걸 공부하려고 했지만 오히려 지금 드는 생각은 그걸 잘하는 사람 뽑아서 맡기는 게 낫다는 것이다. 오히려 CTO로서의 강점을 가져가려면 그 외의 부분들을 강화시키는 게 더 좋다.

- 소셜 스킬 : 업무 분배, 인력 매니징

- 업무 스킬 : 업무 스케쥴, 회의 일정 등을 정해주는 것

- 기술 스킬 : 기초적인 걸 잘할 수록 강점이다. 사실 이게 정말 중요하다. (함수형 프로그래밍, SICP)

[듣고 난 생각]

- 정공법으로 기초 CS공부, 수학적인 것을 더 깊게 공부해야겠다는 생각.

- 코드 짜는 것이야 비슷할 수 있다. 툴을 쓰는 것도 비슷할 수 있다. 하지만 리딩하려면 펀더맨탈이 강한 사람이 있어야 하고, 그걸 CTO가 하는게 좋다.

- 코드를 많이 넘기고, 내 시간을 챙기고, 중요한 것만 하는 게 일 잘하는 것이다. 괜히 이것 저것 다 하려고 하지 말자.

keyword