쿠팡ㅣ개발자 취업과 연봉협상, 조언이 필요해요!

쿠팡ㅣ개발자 취업과 연봉협상, 조언이 필요해요!

일자

상시
유형
아티클
태그
이 아티클은 <꿈의 직장 '네카라쿠배당토'> 시리즈의 4화입니다.


*해당 아티클은 wanted+ 영상 [우테코]  오늘의 개발자 : 프론트엔드4 를 바탕으로 구성되었습니다.


기획 의도
어떤 가치관을 갖고 있느냐에 따라 삶에 대한 이해도는 달라진다. 개발자도 마찬가지다. 어떤 직업의식을 가졌느냐에 따라 그 업에 대한 이해도는 달라질 테고, 자신이 몸담은 산업의 전망도 달리 보이기 마련이다. 업의 특성을 십분 살려 비즈니스적 가치를 고려할 줄 아는 개발자로서 확장을 꾀하고자 한다면 이번 아티클에 주목하라. 

이런 분이 읽으면 좋아요
- 비전공 또는 전공자로서 프론트엔드 개발자를 꿈꾸는 취준생
- 네카라쿠배당토의 프론트엔드 개발자로 성공적인 이직을 준비하는 주니어 개발자
- SI/SM이 아닌 자체 서비스를 하는 IT기업에서 원하는 능력을 키우며 한 단계 더 도약하고 싶은 개발자

이런 인사이트를 얻을 수 있어요
- 프론트엔드 개발자로 첫 발을 떼는 이들을 위한 로드맵 
- 개발자로서 전문성을 쌓기 위해 고민하는 이들을 위한 가이드 
- 아직 발견하지 못한 개발자의 역량을 어떻게 발굴할지 고민하는 이들을 위한 조언

ⓒ 셔터스톡


야, 너도 갈 수 있어! 네카라쿠배당토
프론트엔드 개발자를 꿈꾸는 취준생 여러분, 혹은 프론트엔드 개발자 주니어 시기를 보내는 여러분. 프론트엔드 개발자로서 어떤 회사가 좋고, 그 회사에 들어가기 위해서 어떤 준비가 필요한지, 면접은 어떻게 봐야 할지, 신입으로서 갖춰야 할 태도와 자세는 무엇인지, 어떤 경력을 쌓아 나가야 할지 등 한 번쯤 고민해 보셨으리라 생각합니다. 하지만 나에게 꼭 맞는 답을 찾기란 쉽지 않았을 거예요. 다른 이들의 조언도 ‘수단’이  될 뿐, 진정한 ‘방법’은 아니었을지도 모릅니다. 

먼저 그 길을 걸어온 선배의 입장에서 꼭 해주고 싶은 말은 간단명료합니다. ‘공부’에 올인하세요. 하지만 먼저 ‘공부를 하고 싶은 사람’이 되어야 합니다. 공부가 하기 싫어서 ‘비법’만을, ‘지름길’만을 찾아서 최대한 적게 공부하고 싶은 사람이 아니라 공부하는 과정에서 시행착오를 겪으며 이를 자신에게 적용하고 진짜 실력으로 만들어나가는 여정을 기꺼이 즐길 줄 아는 사람이 되어야 합니다. 저도 개발자가 되기 전 학원에 다니면서 먹고, 씻고, 자는 시간을 제외하곤 개발 공부에 올인했습니다. 첫 회사에 들어가서도 퇴근 후 공부를 이어갔어요. 취준생이든 직장인이든 각자가 처한 여건에 맞는 가처분 시간을 온전히 공부에 투자하세요.


다만, 어떻게 공부해야 효율적인지 그 ‘방법’이 중요합니다. 아무런 방향성 없이, 전략 없이 잘못된 방향으로 열심히만 하면 시간을 소비하게 될 뿐입니다. 먼저 방향을 명확히 설정해야 합니다. 충실은 그다음이고요. 우리는 흔히 ‘수단과 방법을 가리지 않고~’란 말을 쓰곤 합니다. 여기서 수단을 ‘점’으로 방법을 ‘선’으로 각각 비유한다면 수단은 학원, 인강, 부트캠프 등 명사처럼 딱 떨어지는 개별적인 행동을 의미하고, 방법은 일정한 방향을 갖는 ‘선’과 같습니다. 수단과 방법은 모두 필요하지만, ‘방향성’이 전제되어야 효율적인 방법으로 공부를 할 수 있습니다. 만약 자신의 학습과정에서 단순히 수단만을 찾고 있던 것은 아닌지 생각해 보세요. 열심히는 하지만 여전히 ‘잘 모르겠다’는 생각이 든다면 ‘선(방향)’을 찾는 데 집중하길 권합니다.

효율적인 방법을 찾고 싶다면 내가 어떤 방법으로 공부하고 있는지 인식하는 게 우선입니다. 사고방식을 효율적으로 바꾸는 방법 중 하나는 그동안 내가 사고하고 행동하던 방식의 순서를 거꾸로 해보는 겁니다. 사실 우리가 진정 달성하길 원하는 목표는 앞이 아니라 뒤에 있거든요. 뒤에 있는 걸 이루기 위한 준비 단계로 앞의 것을 먼저 하는 식인데, 이걸 기존에 해오던 방식대로 앞에서부터 하는 게 아니라 거꾸로 뒤에서부터 해보자는 겁니다. 개발 세계에서의 예를 하나 들어보면 TDD(테스트 주도 개발·Test-driven development)를 떠올릴 수 있을 것입니다. 개발을 먼저 하고 테스트를 하는 게 아니라 테스트를 먼저 만들어 놓고 이를 통과하는 기능을 나중에 구현하는 방식인 거죠. 

이번에는 일을 하는 방식으로 한 번 더 예를 더 들어볼게요. 아마존에서는 Working Backwords 방식으로 일을 한다고 합니다. 직역하면 ‘거꾸로 일하기’죠. 아마존의 경우 실체는 물론 구체적인 계획조차 없는데도 불구하고 모든 것이 완성된 시점을 상상하며 보도자료를 ‘먼저’ 작성한다고 합니다. 우리는 이런 걸 만들었고, 이것으로 세상은 어떻게 바뀔 것이고, 어떤 기대효과가 있으며, 이로 인해 주가는 어떻게 변할 것인지 보도자료 배포 시점까지 구체적으로 작성합니다. 달성하고자 하는 ‘목표’를 먼저 설정하는 것이죠. 그리고 이렇게 작성한 보도자료에 맞춰 일을 합니다. 그럼 쓸데없는 일을 하느라 낭비하는 시간을 최대로 줄일 수 있고 모든 구성원들이 바라보는 목표를 일치시킬 수 있습니다. 토스도 비슷한 방식으로 세상에 나왔죠. 초창기 토스는 앱이 개발되기도 전에 그저 디자인 프로토타입을 동영상으로 만들어 ‘이런 서비스를 만들겠다’고 시장에 먼저 알린 뒤 시장의 반응을 확인하는 과정을 거쳤습니다. 쉬운 송금 서비스를 고객이 정말로 원하는지 확인하는 과정으로서 자신들이 세운 가설을 최소한의 비용으로 검증하고 toss 서비스를 개발한 것이죠. 


취준생 여러분들도 이러한 방식으로 거꾸로 생각을 해보시면 어떨까요? 무작정 공부를 하고, 공부 방법을 찾고, 학원을 찾아가는 것 말고 거꾸로 생각해 보세요. 당장의 목표는 취업일 테니 아무 준비가 되어 있지 않아도 채용 정보를 먼저 검색해 보는 겁니다. 그리고 채용정보를 통해 시장이 원하는 기술과 인재상을 파악하고 이를 증명할 수 있는, 합격하는 이력서를 먼저 쓰는 것입니다. 그리고 그렇게 작성된 이력서에 나를 맞추는 것입니다. 이렇게 하지 않고 무작정 공부부터 시작하거나 학원에 의존하게 되면 열심히 했어도 시장에서 원하는 공부가 되어 있는 게 아니라 학원에서 원하는(실무와 동떨어져 학원의 수준과 방향에 맞춰진) 공부가 되어 결국 길을 잃게 될 수도 있습니다.

저는 31살에 처음 개발자가 되었어요. 당시에 제 목표는 ‘3년 이내에 네이버에 간다’였어요. 그리고 이런 식으로 구체적인 목표와 방향, 시점을 설정하고, 그 목표에 나를 맞추는 식으로 공부했어요. 출발선에 선 나는 매우 하찮지만 ‘그게 되겠어?’라고 주위에서 조롱할 정도로 높은 목표치를 잡고 공부해야 그 중간이라도 간다고 생각해요. 그렇게 하니 3년 내 네이버는 아니지만, 2년 내 쿠팡에 올 수 있었답니다.

ⓒ 셔터스톡


좋은 회사를 찾기 위해 “좋은”게 뭔지 먼저 생각해 보자!
회사를 선택할 때 좋다, 나쁘다의 기준을 어디에 두고 있나요? 좋은 회사를 찾기 위해서는 회사에 대해서도 자세히 알아야 하지만 그보다 나를 더 자세히 알아야 합니다. ‘회사가 좋은 것’인지 아니면 ‘내가 좋아하는 것을 회사가 제공해 줄 수 있는 것’인지를 구분해야 한다는 것입니다. 예를 들어 연봉이 높다면 이것은 누구에게나 좋은 것이므로 회사가 좋은 것이라고 볼 수 있지만 체계가 잘 잡혀있다는 것은 누구에게나 좋은 것이라고 보기는 어렵습니다. 이미 잡힌 체계에 따르기보다 체계를 직접 만드는 걸 더 좋아하는 사람도 있기 때문입니다.

또한 더 빠르게 의사결정을 해야 하고 더 기민하게 움직여야 하는 멀티 플레이어들이 모인 회사에서는 오히려 체계가 없는 게 더 나을 수 있습니다. 좋은 회사 중에는 이런 회사도 많은데, 체계가 있고 체계에 따르기를 좋아하는 사람은 이런 회사에 가면 안 됩니다. 객관적으로 좋은 회사라고 평가되더라도 그런 사람에게는 안 좋은 회사이기 때문입니다. 물론 그 회사 입장에서도 이런 사람은 원치 않을 겁니다.

회사가 집에서 멀다면 좋은 회사라고 생각되더라도 선택이 망설여지기 마련입니다. 이럴 때는 회사가 멀리 있는 것인지 집이 멀리 있는 것인지 생각해 볼 필요가 있겠습니다. 회사는 그저 회사들이 있는 그 지역에 모여 있을 뿐입니다. 강남, 판교가 대표적입니다. 집에서 가까운 회사에 취업하려고 하기보다는 회사에서 가까운 집에 살려고 하는 사고방식이 삶을 더 나은 방향으로 가게 할 것입니다.


‘성장할 수 있는 회사 vs. 성장과 별 상관없는 회사’ 
여러분은 어느 회사를 좋은 회사라고 생각하시나요? 여기에도 답은 없습니다. 모든 사람이 다 성장하고 싶어 하는 것은 아니기 때문입니다. 개인의 성장을 요구하지 않는 회사를 선호하는 사람도 있습니다. 제가 주니어 일 때는 성장에 대한 열망이 최우선이었기 때문에 성장 욕구가 없는 사람들을 이해하기 힘들었습니다. 그런데 시간이 지나고 보니 저마다 회사에서 무엇으로 만족감을 느끼는지 우선순위가 다르다는 걸 깨달았죠. 좋은 회사냐, 나쁜 회사냐의 기준은 내 안에 있습니다. 내가 회사에 원하는 것은 무엇인지, 회사에 다니며 최종적으로 이루고 싶은 내 모습이 무엇인지 먼저 고민해야 합니다. 그렇게 성향을 파악했다면 개발자로서 두 가지 옵션 중 하나를 선택해야 합니다. 


‘내 것’을 만드는 회사 vs. ‘클라이언트’의 것을 만드는 회사
여기서 ‘내 것’이라 함은 자체 서비스를 기반으로 하며 그 소유권이 회사에 있는 경우를 의미합니다. 반면 ‘클라이언트’의 것을 만든다는 것은 SI/SM 또는 에이전시처럼 외주 계약을 따내서 클라이언트의 문제를 대신 해결해 주는 경우를 의미하죠. 이 두 갈래의 길에서 어떤 선택이 더 좋은지는 각 개인이 무엇에 더 가치를 두는지 그리고 개인의 성향에 달려있습니다. 회사가 어떤 길을 걷고 있고, 내가 이 회사를 갔을 때 어떤 길을 가게 될지 먼저 고민해 보고 해답을 얻는다면 방향을 정하는 데 도움이 됩니다.


이력서는 전단지가 아니다
서류 제출 단계에서 고배를 마시는 이유는 전략의 부재 때문입니다. 그동안 자신의 이력서를 전단지 취급하지는 않았는지 돌아보세요. 회사 이름만 바꾼, 동일한 템플릿의 이력서를 이곳저곳 찔러 넣고 ‘합격’하기만을 바라진 않았나요? 길거리에서 전단지를 나눠줄 때도 나름의 전략이 있습니다. 하물며 서류 제출 시 핵심인 이력서에는 마땅한 전략과 나름의 정성이 담겨있어야 합니다. 무엇보다도 이력서는 내가 가고 싶은 회사에 넣는 서류니까 그 회사의 채용조건에 부합해서 나를 뽑을 수밖에 없을 만큼 매력적으로 작성해야 합니다. 이력서를 통해 회사에 대한 나의 애정을 충분히 보여줘야 면접까지 갈 확률을 높일 수 있습니다.

저는 이력서 작성에 적게는 10시간 많게는 며칠을 투자합니다. 이력서를 준비하면서 회사를 낱낱이 조사하고, 회사가 내건 채용 목적과 신규 채용으로 기대하는 바가 무엇인지를 파악해서 이력서에 최대한 담고자 했었습니다. 채용담당자가 원하는 내용으로요. 내가 보여주고 싶은 것을 내 안에서 꺼낼 게 아니라 상대가 원하는 걸 꺼내서 보여줘야 합니다. 그렇게 내가 낼 수 있는 아웃풋을 이력서에 충분히 담고 전략적으로 어필해야 합니다. 

흔히들 서류 전형에서 떨어지면 “실력 내지는 스펙이 좋지 못해서”라고 자신이 가진 것을 덜 가졌다고 비관하는데 그 생각을 바꿔서 가진 것을 충분히 꺼내지 못했거나 상대에 맞게 올바르게 꺼내지 못했을 가능성에 대해 생각해 봐야 합니다. 특히 신입의 이력서에 필요한 것은 실력보다 잠재력이고 매력입니다. 회사는 신입의 성장 가능성에 투자하는 것이지, 현재 신입이 가진 실력에 베팅하는 게 아닙니다.


‘면접’은 이력서에 드러난 약점을 장점으로 바꿀 수 있는 기회의 장이다.
면접 단계에 올라왔다면 이력서에 드러난 약점은 최소한 결격사유는 아닙니다. 악재는 불확실성이 존재할 때 악재이며 이미 드러난 악재는 불확실성이 해소되었다는 측면에서 호재가 될 수 있습니다. 자신이 생각하는 마이너스 요소(학력, 비전공, 나이, 스펙 등)가 이력서에서 드러났는데 면접에 왔다면 더 이상 이것들에 얽매여 소극적인 면접에 임하지 마시고 자신감을 가지세요. 그리고 ‘어떻게’ 하면 이 약점의 이면을 보여주고 긍정적인 기회요소로 전환시킬 수 있는지 전략을 세우는 데 집중하세요. 

면접 자리에서 면접관이 “나이가 많은 편인데…”라고 말한다면 나이가 많아서 당신을 떨어뜨리겠다는 말이 아닙니다. 그저 우려가 되는 것이므로 나이가 많아서 생기는 이득을 궁금해 한다는 것으로 이해하고 답변하여 우려를 해소하는 것과 동시에 오히려 장점으로 어필하면 됩니다. 학력이 낮다, 비전공자다, 스펙이 약하다 등, 모두 마찬가지 관점에서 접근해야 합니다. 이를 보완할 장점 요소를 준비해서 프레임 전환을 꾀해야 합니다. 면접이 끝나면, 면접관 머리에는 ㅇㅇ한  지원자’라는 이미지만 남기 때문에 나이나 학력 얘기에 너무 치우치지 않도록 경계하고, 자신의 장점을 어필하는 데 집중하세요. “나이는 많지만 그래도 oo 잘하실 분”이라는 긍정적인 이미지를 남겨야 하니까요. 

그리고 면접관이 “마지막으로 하고 싶은 말 있으면 해도 좋습니다”라고 말한다면 이 말은 정말 하고 싶은 말을 하는 기회로 삼을 게 아니라 면접관이 듣고 싶은 말을 할 기회로 삼는 게 좋습니다. 앞서 언급했듯 내가 하고 싶은 말이 아니라 상대방이 원하는 말을 꺼내야 할 타이밍이죠. 그래서 현장에서는 면접관의 성향을 잘 파악해야 합니다. 면접관이 겸손한 스타일을 선호하는지, 신입의 패기를 기대하는지에 따라 답변도, 태도도 달라질 테니까요. 마지막으로 면접도 이력서와 마찬가지로 선택과 집중이 필요합니다. 면접의 감을 익힌다는 이유로 면접을 많이 보는 게 좋다는 의견도 있지만, 그런 의도라면 ‘좋은’ 면접을 많이 보세요. 한 번의 ‘좋은’ 면접이 다수의 ‘좋지 않은’ 면접보다 더 좋은 아웃풋을 낼 수 있습니다. “봐서 뭐해 어차피 떨어질 텐데”와 같은 반응이 나올법한 면접이 바로 좋은 면접입니다.
 면접을 많이 봐야 하는 이유는 면접을 대비하기 위함입니다. 따라서 좋은 면접을 많이 봐야 좋은 회사에 합격 할 확률을 올릴 수 있습니다. 면접의 질과 상관없이 면접을 무작정 많이 보면 대비 하는 수준도 그만큼 낮아지고 결과적으로 회사 보는 눈도 그만큼 낮아지기 마련입니다.

ⓒ 셔터스톡


연. 봉. 협. 상! 모든 협상은 결렬될 가능성을 내포한다
이직할 때와 달리 재직 중 인사평가에 의한 연봉 계약은 협상이 없는 통보가 일반적입니다. 그 통보받은 연봉을 인정 못 할 때 연봉 협상이란 것을 시도해 볼 수 있습니다. 통보받은 연봉을 인정 못해서 협상을 시도했는데 협상 끝에 처음 통보받은 연봉과 변함이 없다면 퇴사를 하는 게 수순입니다. 그러므로 재직 중 연봉협상은 최후통첩이라고 생각하고 시도하는 게 좋습니다. 그러면 이직 과정에서는 어떨까요? 일반적으로 최종 합격하고 입사 날짜 조율과 함께 연봉 협상을 하게 됩니다. 결렬될 여지를 두는 게 연봉협상이지만, 이직 시기를 언제로 정하느냐에 따라 많게는 1년에 3번까지 연봉을 올릴 수도 있습니다. 그만큼 이직을 할 때는 협상 그 자체도 중요하지만 ‘시점’도 중요합니다. 그 시점은 현재 다니는 회사와 이직할 회사의 인사평가 기간을 중심으로 고려합니다. 아래 그래프는 실제로 이직을 하면서 연봉을 3번 올린 저의 사례입니다. (아래의 녹색화살표가 연봉 인상)

ⓒ 김수호 


이직하는 시점은 나의 경력을 기준으로 잡는 게 아니라 현재 회사와 이직할 회사의 인사평가 기간을 기준으로 해야 합니다. 단순히 실력만 좋다고 해서 연봉이 올라가는 게 아닙니다. 실력만으로 연봉을 높이려면 누구도 범접하기 어려운 수준에 있어야 합니다. 시장에서도 물건이나 서비스의 가격을 결정하는 변수가 여러 가지죠. 일반적으로 원가 또는 품질에 따라 가격이 달라진다고 믿겠지만 실제로는 ‘언제, 어디서’ 같은 변수가 가격에 더 크게 영향을 미칩니다. 똑같은 옷을 여름에 사는 것과 겨울에 사는 것이 가격이 다르고, 동대문에서 파는 것과 백화점에서 파는 것이 가격이 다릅니다. 연봉도 마찬가지죠. 비유하자면 원가는 노력을, 품질은 실력을 의미하는데요. 노력과 실력이 연봉에 미치는 영향보다, 언제 이직을 하느냐, 어디로 이직을 하느냐가 연봉에 훨씬 큰 영향을 미칩니다. 올해가 상장 전 스톡옵션을 받을 수 있는 마지막 기회라든지, 대규모 공채가 특별히 있다든지, 마케팅 차원에서 신입의 연봉을 갑자기 올려서 이전 공채 기수보다 초봉이 더 높게 된다든지, 신입이 경력직보다 더 높은 연봉을 받게 된다든지 하는 일들이 개발자의 세계에서는 매우 빈번하게 일어납니다.


‘좋은 개발자’가 되고 싶다면?
좋은 개발자가 되고 싶다면 SI/SM은 최대한 빨리 벗어나는 게 좋습니다. 좋은 개발자를 어떻게 정의하는지는 모두가 생각이 다르겠지만, 그 정의가 어떠하든 어떻게 하면 더 좋은 개발자를 채용할 수 있을까를 고민하는 회사와 사람들은 SI/SM에 없기 때문입니다. 좋은 개발자라고 불리는 개발자들이 현재 어떤 회사에 주로 있는지 또 그들은 어디서 어디로 이직을 해가는지를 보면 자체 서비스를 하는 회사가 답이라는 것을 알 수 있습니다. SI/SM과 자체 서비스를 하는 회사는 정말 많은 게 다릅니다. 기술 스택이 다른 것은 물론이고 개발 문화뿐만 아니라 사고하는 구조도 일하는 방식도 모두 다릅니다. 따라서 경력이 쌓일수록 갖춰야 하는 능력의 방향은 점점 벌어집니다.

취준생의 경우 처음부터 네카라쿠배당토에 들어가지 못하더라도 좌절하지 마세요. 초기 스타트업에서 시작했더라도 그곳에서 네카라쿠배당토에서 온 사수를 만날 수도 있으니까요. 그래서 어디를 가게 되더라도 먼저 ‘좋은 개발자’란 무엇인지 가치를 세우고, 좋은 개발자와 함께 하는 시간을 만들어 가세요. 그리고 잊지 마세요. 학습 방법도 이직도 연봉협상도 회사 생활도 모두 자신만의 ‘좋은 회사, 좋은 개발자’에 대한 신념이 있어야 한다는 것을요.


학생 vs. 직장인, 이 차이에 따라 전혀 다른 길을 걷게 된다
취준생에서 직장인으로 신분이 바뀌면 많은 것들이 달라집니다. 학교에서는 개인 평가를 받았다면, 회사는 개인 평가뿐만 아니라 팀, 조직 평가로 이어지죠. 팀이나 조직의 평가가 좋지 않으면 개인의 평가도 좋지 않을 수 있습니다. 학교에서의 경쟁자가 회사에서는 팀워크의 대상이 되죠. 세상은 그대로인데 세상을 대하는 그 입장과 역할이 바뀐 만큼 이를 대하는 우리의 관점과 태도도 바뀌어야 합니다. 

학생일 때는 내가 공부를 못 하면 나 혼자 피해를 봅니다. 하지만 직장인은 본인이 일을 못하면 본인보다 우선 타인이 피해를 봅니다. 나로 인해 내 동료가 피해를 보거나 회사가 피해를 보는 식입니다. 그래서 기본적으로 직장인은 일을 잘해야 합니다. 타인에게 피해를 주지 않기 위해서라도 말이죠. “신입이니까 잘 못해도 괜찮아”, “신입에게 큰 기대 안 해”라는 말이 있는데, 이 말은 신입 당사자가 스스로를 위로하기 위한 말이 아닙니다. 이 말은 신입을 케어해야 하는 임무를 건네받은 사람들, 신입으로 인해 피해를 볼 수 있는 입장에서나 할 수 있는 말입니다. 남에게 피해를 끼치는 입장이면서 자신의 부족함을 합리화하는 말은 절대 하지 마세요.

내가 일을 잘 한다고 해서 일을 잘하지 못하는 사람을 향해 총을 겨누면 그것 또한 안될 일입니다. 왜냐하면 아군이니까요. 공부를 잘하는 학생도 있고, 못하는 학생도 있듯이, 일을 잘하는 직장인도 있고, 부족한 직장인도 있습니다. 부상당한 아군에게 총을 겨누지 말고 부축을 해주세요. 총구가 향하는 곳에 있는 사람도 총을 든 사람을 적으로 인식하지만 아군에게 총을 겨누는 사람을 본 사람들도 총을 든 사람을 적으로 인식합니다. 생각보다 IT 바닥이 정말 좁습니다.(웃음) 마찬가지로 디자이너도 아군입니다. 절대 싸우지 마세요. 실무를 진행하다 보면 서로 사고 구조가 다르기 때문에 이견이 많지만, 이건 맞고 틀리고의 문제가 아니에요. 우리 제품을 더 좋게 만드는 방향으로 내는 각자의 의견이기 때문에 충돌은 피하고, 선의의 팀워크를 유지하는 방향으로 나아가야 합니다. 

마지막으로 신입으로서의 패기든 뭐든 다 좋은데 무엇보다도 ‘메타인지’가 필요해요. 끊임없이 실력 향상을 위해 공부하세요. “그 연차치고 잘하네”라는 말을 듣는 것은 매우 쉽습니다. 연차가 쌓이기 전에 조금만 노력하면 누구나 들을 수 있는 칭찬입니다. 문제는 연차가 쌓이는 속도가 능력이 쌓이는 속도보다 월등히 빠르다는 것입니다. 더닝 크루거(Dunning -Krugger Effect) 효과라고 하죠. 경험이 많이 쌓여야 자신의 실력을 정확히 파악할 수 있습니다. 경험을 쌓기 위해선 시간이 필요한데, 흘러간 시간의 속도에 비해 실력이 떨어진다면 경력이 쌓일수록 이직은 되려 힘들어집니다. 

다시 앞으로 돌아가 ‘좋은 개발자’가 되기 위해 함께 나누었던 이야기들을 떠올려보세요. 여러분들은 어떤 개발자가 되고 싶으신가요? 이 글을 읽기 전보다 명확한, 그림이 그려졌기를 바라겠습니다. 



▶ <꿈의 직장 ‘네카라쿠배당토’> 시리즈 보러 가기



CREDIT


권지혜ㅣ객원 에디터



발행일 2022.02.08