인프콘 2022 데브챗 부스 그 후
다시 모인 인프랩 개발자들 🏃

요즘 개발자 취업준비생 혹은 주니어 개발자의 고민은 뭘까요? 인프런은 인프콘 2022를 통해 개발자분들의 다양한 고민을 만나볼 수 있었어요. 데브챗은 인프콘 내내 만석일 정도로 인기였습니다. 하지만 제한된 시간 때문에 더 많은 이야기를 나누지 못해서, 참가자와 인프랩 개발자 모두 아쉬웠다는 말씀을 많이 해주셨어요.

_{인프콘 2022 데브챗 부스의 열정적이었던 현장!}

인프랩 개발자들은 더 많은 이야기를 전하기 위해 한 자리에 모였습니다. 데브챗에서 많이 언급되었던 주제와 질문을 중심으로 자유롭게 대화를 나누는 시간을 가져보았어요. 이력서, 커리어, 업무 방식을 주제로 나눴던 대화를 여러분께 공개합니다!

※ 아래 대화는 개발자 개인의 의견으로, 정답이 아닐 수 있습니다.

---

키워드 1. 취업/이직

자미(HR) 여기가 아무래도 인프랩 개발자들만 모인 자리다 보니, 인프랩 기준으로 말씀드려야 할 것 같아요.

준프(FE) 저는 현재 프런트엔드 개발자 채용에 참여 중인데요. 저희 프런트엔드 파트에서 정했던 나름 공식적인 기준을 말씀드릴 수 있을 것 같아요.

일단 신입이나 저년차 주니어분들께는 프로젝트 진행 과정을 남긴 문서가 꼭 있으면 좋다고 말씀드리고 싶어요. 블로그 등의 형태로요. 기록을 남길 땐 본인의 경험을 위주로 담아냈으면 좋겠어요. 그리고 기초 이상의 지식이 필요해요. 지식이라는 말이 조금 부담스럽게 느껴질 수도 있는데, 배열에 map이라는 메서드가 있다는 걸 알고 활용할 수 있는 정도는 필요하다고 생각해요.

3년 이상의 경력이 있는 분들의 경우엔 빠르게 변하는 기술 트렌드를 잘 따라가고 있는지를 파악하려고 해요.

이력서의 경우엔 흔히 우리가 알고 있는 정형화된 형식은 선호하지 않는 것 같아요. 그런 이력서 형식은 팀에서 원하는 정보를 충분히 담아내기 쉽지 않다고 생각하거든요. 직무에 특화된 이력서가 필요해요.

몰리(FE) 개인적인 생각으로는 자기소개가 길지 않아도 괜찮은 것 같아요. 지원자의 성장 배경 같은 내용보단 구체적인 프로젝트 경험이 더 많이 채워지면 좋겠어요.

_{이력서를 구성할 때, 면접에서 충분히 답변할 수 있는 내용들로 채워보세요.}

후리(BE) 제가 참여했던 백엔드 채용 경험을 떠올려봤을 때, 문장의 가독성도 중요한 것 같아요. 첫 문장이 200자가 넘는 이력서를 받은 적이 있는데, 처음부터 읽기가 너무 힘들었어요. 코딩이라는 게 결국은 어떤 기능을 구현하기 위한 로직을 프로그래밍 언어로 표현하는 건데, 본인의 생각과 이야기를 글로 표현하는 것이 부족하다고 느끼게 되면 개발자로서 매력이 떨어진다고 생각해요.

지난 데브챗에선 본인이 채용에 참여하게 되었는데, 채용 과정에서 사람을 어떻게 봐야 할지 모르겠다고 이야기해준 분이 있었어요. 모든 직업이 그렇겠지만, 저는 특히 개발자라는 직업은 개발을 좋아하고 즐겁게 할 수 있어야 한다고 생각해요. 면접에서 그걸 파악하는 게 쉬운 일은 아니지만, 요즘 관심 있는 분야, 최근에 읽은 개발 도서, 구독하는 개발 콘텐츠 등을 자주 여쭤보면서 파악하려고 노력해요.

그리고 지원동기도 꽤 중요하다고 생각해요. 저는 지원자가 지원한 다른 회사를 여쭤보면서 우리 회사의 서비스 자체에 관심이 있어서 지원했는지, 스펙이 맞아서 지원했는지 등을 확인하기도 해요. 물론 지원동기가 필수 조건은 아니지만, 비슷한 수준의 지원자가 있다면 충분히 가산점으로 작용할 수 있는 것 같아요.

_{인프랩 프론트엔드와 백엔드 개발자들의 열띤(?) 대화의 현장.}

우주(BE) 제가 이력서를 썼던 때를 생각해보면 '앱 개발 다수/파이프라인 구축' 같이 나열 형식은 차별화가 될 수 없는 것 같아요. 그래서 전 서비스 운영 방식, 어려움 극복 등 저를 더 잘 드러낼 수 있게 쓰려고 노력했어요. 그리고 하드 스킬에 치중된 이력서가 많은데, 소프트 스킬에 대한 내용도 예시를 들어 작성하면 좋을 것 같아요.

몰리(FE) 이력서에서도 본인의 관심 분야를 충분히 드러내면 좋겠어요. 채용 담당자 입장에선 지원자에 대해 아무것도 모르기 때문에 기대할 수 있는 요소가 필요하더라고요. 그리고 팀 프로젝트를 작성할 땐, 기여도보다 어떤 성과를 냈는지 위주로 적으면 좋을 것 같아요. 기여도는 주관적인 부분이니까요.

후리(BE) 이력서 내용을 기반으로 질문을 받았을 때 충분히 답변할 수 있는 내용 위주로 적는 것도 중요한 것 같아요. 멋진 이력서를 위해 확실하게 알지 못하는 지식에 대해 적으면 면접 때 헤맬 수밖에 없더라고요.

---

키워드 2. 커리어

준프(FE) 리드하는 건 연차 불문하고 어려운 게 너무 당연한 것 같아요. 누구나 리딩을 하게 되면 시행착오를 겪게 되는데, 그걸 충분히 경험해야 한다고 생각합니다. 그리고 그걸 잘 기록해야 해요. 팀원이 나에게 어려움을 상담했을 때 어떤 대화를 했는지, 논쟁 상황에서 나는 어떤 역할을 했는지, 내가 개선할 점은 무엇인지 같은 것들이요.

비스타(BE) 팀원들의 업무 방식이나 팀원 개개인의 성격 같은 팀의 성향을 파악하는 게 필요한 것 같아요. 저의 입사 초반을 떠올렸을 때 말하지 않아도 챙겨주는 동료보단 필요한 순간에 답변을 줄 수 있는 동료가 좋았어요. 제가 지금 새로운 팀원의 서포터 역할을 하는 중이거든요. 제가 먼저 나서서 이것저것 알려드리진 않는데, 그분이 먼저 질문을 하시면 충실히 답변하려고 노력하고 있어요.

우주(BE) 제가 전에 다녔던 회사에선 백엔드 개발자가 저 포함해서 두 명이었어요. 그리고 제가 아닌 상대방이 리딩했고요. 그때의 경험을 떠올려보면, 여러 가지 업무의 일정을 적절히 정하고 역할을 분배하는 게 리딩의 시작이라는 생각이 들었어요. 리딩을 할 땐 꼭 기술적인 것뿐만 아니라 매니징 스킬도 필요한 것 같아요.

홍시(FE) 예전에 우아한형제들 기술 블로그에서 봤던 글이 생각나요. 똑같은 질문을 100번 하면 100번 대답해주겠다.

후리(BE) 수습 기간에 잘 적응할 수 있도록 도와주는 게 회사의 역할이라고 생각해요. 그리고 증명은 결과가 아닌 과정으로 해야 해요. 주어진 업무를 계획된 일정 내에 해내는 게 다가 아니라, 그 과정에 있는 팀원과의 커뮤니케이션 같은 걸 더 신경 써야 해요.

준프(FE) '증명'을 도출하는 건 회사의 몫인 것 같아요. 과제를 주는 방식 같은 게 있겠죠. 근데 이건 조직의 문화나 성격에 따라서 천차만별이에요. 인프랩의 경우엔 평가는 면접에서 마치고, 수습 기간엔 핏(Fit)처럼 부족한 면을 팀 차원에서 채워주려고 노력해요.

몰리(FE) 자신을 증명하는 가장 간단한 방법은 문서화입니다. 별거 아닌 것처럼 보이는 업무라도 기록해주는 게 중요하더라고요. 그리고 피드백을 받으려는 시도를 많이 하면 좋을 것 같아요.

홍시(FE) 맞아요. 저도 예전에 간단한 업무는 기록 없이 진행하기도 했는데, 요즘은 사소한 업무도 기록을 남기려고 노력하고 있어요.

자미(HR) 만약에 수습 기간 후에 최종 면접같이 정규직 전환 심사가 있는 곳은 예외인 것 같아요.

_{성장의 과정을 꾸준히 기록해봐요.}

우주(BE) 저는 외부 동아리나 커뮤니티처럼 다른 사람들이랑 함께할 수 있는 환경을 만들려고 노력했어요. 다양한 개발자를 만나고 프로젝트를 같이 하다 보면 자신의 위치를 알게 되더라고요.

몰리(FE) 공감해요. 개발자 생태계가 생각보다 좁아서 커뮤니티를 통하면 좋은 개발자를 건너서 알게 되는 경우가 있거든요. 그리고 지금의 방식이 어떻든 자신의 기준에 맞게 개발하고 공부하면서 그걸 논리적으로 잘 설명할 수 있다면 괜찮은 것 같아요.

준프(FE) 멘토가 없는 환경에서 업무했던 저의 경험을 돌이켜보면, 개발과 관련된 글을 많이 읽었던 것 같아요. 사실 개인의 불안함을 완전히 회복하는 건 어렵다고 생각해요.

홍시(FE) 개인적으로는 불안함 관련해서 이 영상이 많이 도움이 됐어요.

토리(FE) 누구든 피드백 받을 사람이 있다면 피드백을 요청하는 게 제일 좋은 것 같아요. 인프런 멘토링처럼 외부에서 멘토를 찾아봐도 괜찮다고 생각해요.

---

키워드 3. 업무 형태

몰리(FE) 파트장이 없으면 뭔가를 결정할 때 오랜 시간이 걸리는 것 같아요. 이럴 땐 보통 의견 취합을 잘하는 팀원이 의견을 빠르게 정리해주셔서 빠른 결정에 도움을 받고 있습니다.

홍시(FE) 좋게 말하면 민주주의죠. 저희 파트는 결정에 너무 오랜 시간이 걸리는 경험을 하고 나서 일단 뭐든 빠르게 시도하기로 합의했어요. 빠르게 시도하고, 성공이든 실패든 결론을 내리고, 다음 스텝으로 넘어가는 식으로요.

후리(BE) 가장 이상적인 건 팀원 개개인이 책임감을 가지고 일하는 거예요. 파트장이 없다는 건 일종의 이데아를 꿈꾸며 일하는 거라고 해야 할까요. 모든 개인이 서비스에 대한 주인의식을 가지고 일하면 좋지만, 일방적으로 희생을 강요할 수도 없잖아요. 그래서 서로에 대한 신뢰가 중요한 것 같아요.

_{오늘도 열심히 일하는 개발자.jpg}

몰리(FE) 제가 이전에 다녔던 회사에서 1년 반 동안 1인 개발자였거든요. 일하면서 느낀 건 스스로 노력하는 방법밖에 없다는 거예요. 스터디를 하거나, 나름의 기준을 세워서 거기에 맞게 코딩하거나. 결국 스스로 성장의 길을 만들 필요가 있더라고요.

후리(BE) 본인이 5년 차 미만이라면 사수가 없는 환경을 경험해보는 것도 나쁘진 않은 것 같아요. 연차가 적을 때 얕고 넓은 경험을 하는 건 괜찮다고 생각하거든요. 사실 사수가 없다는 건 울타리가 없다는 의미이기도 하잖아요. 사수가 없다면 오히려 본인이 경험할 수 있는 폭은 넓어지는 건데, 그 환경에서 본인이 얼마나 배워가는지가 중요한 거죠.

토리(FE) 사수는 내가 모르는 것을 알려주는 역할도 하잖아요. 그런데 사수가 하나부터 열까지 알아서 떠먹여 주진 않거든요.

비스타(BE) 맞아요. 결국 도움은 필요한 사람이 요청하고, 답을 찾아야 하는 것 같아요. 꼭 사수가 아니더라도 주변에 도움을 구할 다른 동료가 있다면 꾸준히 도움을 요청하는 게 좋다고 생각해요.

 

---

인프랩 개발자들의 대화, 어떠셨나요?
경력이 얼마나 됐든, 지금 처한 상황이 어떻든
성장을 위해선 많은 노력이 필요한 것 같아요.
인프런은 성장을 위해 나아가는 여러분을
항상 응원하겠습니다.

주니어 개발자의 고민에 대한 의견이 있으시다면
자유롭게 댓글 남겨주세요!

---

[주간 인프런]의 새 이름, [인프메이션]!

매달 첫 번째 & 세 번째 화요일마다 찾아오는 인프런 뉴스레터,
[헬로 인프런]으로 가장 빨리 인프메이션을 받아보세요!
지난 [인프메이션] 이 궁금하다면? (클릭)

헬로 인프런 구독하러 가기 💌
([인프런 소식 및 홍보]를 ON으로 바꿔주세요 😊)