19년 차 개발자가 고찰한 주니어 개발자가 성장하기 좋은 회사 환경

📌 글 작성

성장에 관심이 많은 F-Lab 백앤드 멘토 Elkein
아주 작은 스타트업 여럿과 NHN, 넷마블, 크래프톤 등을 거쳤으며
게임 산업, 클라우드 플랫폼 개발, 웹 개발 등을 두루 경험한 개발자

개요

이젠 익숙해지기까지 한 신조어가 있다.

‘네카라쿠배’

최근에는 네카라쿠배토당야까지 묶는 듯하다.

한편 게임 업계에는 훨씬 오래된 용어가 있다.

‘3N (Nexon, NC Soft, Netmarble)’

3N에 해당하는 회사들이 시기마다 조금 바뀌어왔고, 탑티어 게임 회사를 지칭하는 용어도 조금씩 다르게 규정되지만, 상징적인 단어로 봐도 무방하겠다.

여하튼 이러한 네임드 회사의 경우, 좋을 확률이 높다.

물론 대기업이라고 해서 모든 면이 자신에게 마지않으며, 예상치 못한 부바부, 팀바팀의 변수도 있으며, 상사가 별로면 나머지 조건이 다 좋아도 불만족스러울 수 있다.

그럼에도 확률상 높은 것은 사실이니, 누구나 가고 싶어 하는 회사들인 것은 사실이다.

채용 정보의 불균형으로 인해, 우리는 어떠한 팀을 골라서 지원하지만, 그 팀이 어떠한 문화를 가지고 있는지, 어떠한 사람들과 일하게 되는지, 어떠한 가치관을 높게 두는지 등에 대한 정보를 얻기 힘들다.

아니 질문 계기가 있더라도, 확인하는 경우도, 확인받는 경우도 드문 게 사실이다.

이번 글에서는, 회사에서 얻을 수 있는 좋은 경험, 환경은 어떤 것에 있으며, 이를 면접 과정이나 공고에서 확인 가능한 부분은 무엇이 있을지 알아보자.

좋은 환경 정의

첫째로, 연봉, 복지 등이 있겠다.

너무 중요하고, 너무 당연해서 부연 설명은 하지 않겠다.

둘째로, 훌륭한 동료가 옆에 있는 것이 좋다.

같이 일하면서 배우게 되는 것이 아주 많다.

코드 리뷰도 크로스 체크를 통해 버그를 줄이는 목적도 있지만, 서로의 장점이 시너지가 나고, 서로 배우기를 바라는 효과도 의도하는 것이다.

대화에서도 많은 것을 배우게 된다. 티타임, 식사 중 대화, 개발 관련 스몰 토크, 개발 결과물 수많은 부분에서 배우게 되고, 환경이 사람을 만든다라는 말처럼, 개발에서의 환경은 바로 동료라고 볼 수 있다.

훌륭한 동료가 곧 복지라는 말이 괜히 나온 것이 아니다.

많은 회사가 같이 일할 동료들이 기술 면접을 보게 되는데, 이 과정에서 면접관이 나에게 좋은 동료가 되어줄 사람들인지 확인해야 한다.

대 부분 면접 시간의 제한이 있다고 하더라도, 탕비실이나 카페테리아 등에서라도 추가적인 질문에 응해준다. 면접 후 질문 시간을 이용해서 좋은 동료를 만날 수 있는지 확인해야 한다.

셋째로, 자체 서비스 보유 여부, 트래픽

런칭이나 특정 목적(일정 완수, 테스트 통과 등)을 달성하는 것이 우선인 환경에서는 유지보수를 고려할 때나 엔지니어링적인 관점의 고민이 우선 순위에서 밀리기 마련이다. 상술한 좋은 동료가, 좋은 시니어가 있어도 조직 전체의 목표의 우선 순위에 영향을 받는다.

제품이 애정을 가졌을 때, 엔지니어링적인 퀄리티와 제품의 완성도에 균형을 잡고자 노력하게 된다.

자체 서비스가 있다고 반드시 개발 문화가 좋다는 뜻은 아니지만, 그럴 확률이 높다고 보면 좋다.

여기서 조금 더 욕심을 낸다면, 트래픽이 많은 자체 서비스라면 더 좋다.

직군을 막론하고 많은 트래픽은 유의미한 개발 경험을 가져다주지만, 백엔드 개발자라면 훨씬 더 유의미한 지표다.

대용량 트래픽을 다루면서 경험할 수 있는 것들

• 작은 버그 하나가 얼마나 큰 사고가 될 수 있는지
• 유닛 테스트나 자동화, 자동화 테스트 등으로 커버리지를 갖추려는 노력이 어떠한 효과가 있는지
• stateless를 왜 유지해야 하는지
• stateless를 유지 못하는 구조라면 왜 스케일 아웃을 대비해야 하는지
• 병목 지점을 어떻게 찾는지
• 병목 지점을 어떻게 해결하는지
• 로그가 얼마나 소중한지
• 자원 사용 현황이 어떤 의미인지
  • 정적인 트래픽
    — 배치성 작업
    — 처리할 데이터양을 확인 하고 작업 가능
    — 정적 페이지
    — 캐시 히트률이 아주 높은 데이터
  • 동적인 트래픽
    — 실시간 REST API 호출
    — 웹 소켓
    — WebRTC

• 모니터링, 오토 스케일링의 중요성

이외에도 나열하자면 더 많을 것이다.

이렇듯 작은 규모의 서비스에서는 느끼지 못할 확률이 높은 감정, 경험, 판단, 이해도를 가져다주기에, 대용량 트래픽 경험자를 선호하는 측면이 있고, 우리도 그런 경험을 할 수 있는 환경이라면 유의미한 경험치를 쌓을 수 있는 확률이 높아지는 것이라 볼 수 있겠다.

넷째로, 훌륭한 리더가 이끄는 조직이 좋다.

동료가 좋아도, 자체 서비스를 가지고 있어도 리더의 성향과 역량은 아주 중요한 요소다.

극단에 치우친 리더보다는 균형을 잘 잡는 리더가 좋다.

자체 서비스가 없다고 해도 리더의 의지가 있다면 개발 문화를 지킬 수 있고, 자체 서비스가 있다고 해도 리더의 의지가 없다면 개발 문화는 좋아질 수 없다.

자기 개발, Dev Toy를 통한 자기 발전도 유의미하고, 짬 내서 개선하고, 자동화하고, 유닛 테스트 작성하고, 성능 테스트 진행하고 모두 좋지만, 리더의 의지가 없다면 시간 배분, 동료의 지원을 받기 어렵다.

사실 문화를 신경 쓰거나, 퀄리티를 높이려는 노력과 일정의 상관관계가 높지 않다.

극단적인 개발 문화 추구도 그다지 좋은 환경이라 보기 어렵지만, 극단적인 일정 위주 문화도 장기적으로 수많은 기술 부채와, 발전에 악영향을 주기 쉽다.

그래서 결국 내가 지원하는 회사가 어떤 회사인지, 면접 과정에서 질문을 던지고 이를 통해 좋은 환경의 회사인지 확인하는 과정이 필요하다.

면접때 물어보면 좋은 질문

1. 개발 팀

• 인원 구성
  • 시니어 비율
    시니어는 1~2명 이상 있으면 좋지만, 그렇지 않더라도 대화 과정에서 배울게 많고, 존중받는 면접 경험이면 괜찮다.
  • 어떤 경험의 시니어

• 팀 전체 인원 규모
  • 6명 정도가 좋다고 생각한다.
  • 팀 규모가 크다 보면, 소통에 드는 시간이 커지게 되는 측면도 많고, 팀 동료들의 작업 물이나, 생각을 들여다보는 데에 시간을 들이기 쉽지 않다.
  • 회의실이나, 카페테리아에서 자리 찾기도 수월한 수라고 볼 수 있다.

• 소통 방식
  • 자연스러운 스몰토크 속에서, 서로에게 영향을 주고받는다. 이러한 계기가 자주 있고, 이를 지향하는지 확인해 봐야 한다.

• 코드 리뷰
  • 어떠한 규칙을 가지고 하는지
  • 핵심 논점

• 설계 리뷰/공유

• 문서화에 대한 노력

• 자동화에 대한 노력

2. 리더 면접 (CTO나, 실장, 랩장 등)

• 조직 운영 규칙
  • 포괄적인 질문을 할 때, 조금 더 많은 정보를 얻게 되는 경우가 있다. 이때 얻은 정보를 바탕으로 팀장 면접 혹은 개발 팀 면접에서의 오차를 통해 해당 회사가 일관된 문화를 가졌는지, 혹은 그렇지 않은지 확인할 수도 있겠다.

• 개발과 사업의 밸런스
  • 몇 대 몇인가
    내 선호도를 말하자면, 개발 5:5 또는 6:4 사업 혹은 사업 6:4도 괜찮다고 생각한다.
  • 개발 9:1, 8:2, 7:3 사업 이런 경우도 썩 좋지 않다. 개발팀이 유닛 테스트 커버리지 달성률 높이는데 한 달 쓰고 스트레스 테스트한다고 한 달 쓰고 아키텍처 우아하게 만든다고 세 달 쓰고

• 어떠한 사람이 좋은 개발자라 생각하는가
  • 자신이 그런 개발자가 되고 싶은지
  • 그런 개발자의 자질을 가지고 있다면 잘 맞을 확률이 높다

• 앞으로의 기술 리딩 방향
  • 바퀴의 재발명 or 잘 가져다 쓰기
  • 신기술 or 안정적인 기술
  • 안정적이게 변화 주는 방법

• CTO는 개발자 베이스가 탄탄할수록 좋다.
  • 다른 부분에서의 강점이 있는 경우도 좋지만, 기술적인 판단, 리딩, 공감, 소통을 위해서는 대화가 통해야 하는데, 개발자 베이스를 빨리 벗어난 리더나, 특정 경험만 뾰족한 리더는 보통 균형적이고, 합리적인 판단을 못 내리는 경우가 많았다.

• 팀 구성
  • 개발 조직들은 어떻게 구성되어 있으며, 롤이 어떻게 나뉘어 있는지 확인해 보면 좋다. 이를 통해 나에게 요구되는 역량, 혹은 내가 부족하지만 키워서 커버해야 되는 역량, 지원받을 수 있는 부분 등을 판단할 수 있다.
  • 예시
    - 기술 지원
    인프라 팀 or 데브옵스
    빅데이터 or 빅데이터 인프라 팀
    DB팀
    - 백엔드
    - 프론트엔드
    - 앱 개발
    - 데이터 분석팀

3. 팀장

• 관리 규칙
  • 어떠한 가치관으로 리딩하는지
  • 그 가치관이 정립되지 않은 경우에는, 회사 전사 규칙을 따라가는 경우가 많거나, 자신의 독단으로 회사의 방침과 무관한 규칙을 가졌는지 등을 체크해 보는 것이 좋다.

• 관리 방식
  • 일정 관리 방식
  • 업무 롤에서의 개인의 자율 범위
  • 근태 관리
    - 유연할수록, 일정 관리는 더 타이트해야 함
    - 야근이란 의미의 타이트가 아니라, 일정 준수 개념
    - 일정 연기의 당위성이 떨어지기 쉬움

• 토론 문화
  • 최종 결정권은 리더에게 있되, 논의 자체는 열린 구조가 좋다고 생각한다.

• 교육 문화
  • 비용 지원도 크면 좋다.
    - 인프런, 패캠
    - 도서 지원 무제한에 근접하면 좋음
    - 시간도 지원주면 좋다
    - 사외 교육/ 세미나 지원
    - 팀 내 스터디
    - 기술 토론 시간
    - 기술 피드백 시간

• 어떠한 개발자가 팀에 필요하다고 생각하는지
  • 딜러
    - 그냥 능력이 출중함
    - 이 사람 한 명이 일반 개발자 * 5 이상
  • 탱커
    - 묵묵히 성과가 덜되는 일
    - 누군가 해야 되는 일
    - 커리어 관리에 덜 도움 되지만, 꼭 필요한 일
    - 시간 많이 드는데 효율은 적은 일
    - 단순 노가다
    - 혹은 이에 대한 자동화
  • 힐러
    - 팀의 분위기 메이커
    - 무슨 얘기를 해도 호응
    - 회식, 스몰토크, 식사 시간 등에서 편하게 대화를 이어나가는 분위기 메이커
    - 무거운 이야기 제때 끊어주며 대화 온도/주제 조절
    - 어떠한 업무의 방향이나, 의문점, 연구가 필요한 난도 높은 이슈를 개선안 제시 (힐러니까 이 부분은 약할 수도 있고, 이 부분도 잘 할 수도 있고)
    - 해결책 마련
    - 같이 고민
    - 리서치 도움

• (저를 뽑으신다면) 저는 어떤 면이 강점이 있어서 팀에 필요할 거라고 생각하셨나요?

• 제 이력서에 어떤 부분이 팀에 도움이 될 거 같아서, 면접 제안을 주셨나요?

면접 때 물어본 질문에서 얻어야 되는 추론

면접 과정에서 어떠한 감정을 느꼈는지, 어떠한 생각을 가진 사람들과 일하게 되는지, 자신이 원하는 환경, 좋은 환경의 회사인지 확인하는 것이 필요하다.

특히 초봉이나 평균 연봉은 공개되어 있는 경우가 많은데, 그 이외의 요소는 확인하기 어렵다.

특히나, 문화의 경우 공개되지 않은 회사가 너무 많다.

그렇다 보니 우리는 좋은 문화가 어떤 요소가 필요한지 생각해야 하며, 그 생각한 요소를 얼마나 많이 가진 팀에 합류할 수 있는지 알아야 한다.

진리의 팀바팀/실바실이라는 말이 있듯, 회사의 규모가 클수록 공통된 문화를 가지지 않은 경우가 많다.

또한 리더의 의지가 개별 팀이나 실에는 적용되지 않는 경우도 많기에, 이름 있는 회사니까 꼭 가보고 싶다는 생각을 넘어서, 나에게 맞는 좋은 문화를 가진회사인지 꼭 판단해보면 좋겠다.