회사 동료들과 1년 넘게 유지 중인 스터디가 있습니다. 공유하고 싶은 다양한 주제를 가져와서 함께 의견을 공유하는 방식으로 1주 ~ 3주 당 1회로 꾸준하게 진행하고 있습니다.
이번주에는 제가 발표 차례가 되어 이력서를 갱신하면서 느낀 점과 5월 22일'작은 서비스 조금씩 개선하기'에 참여하고 느낀 점을 공유했습니다.
행사 참여에 대해 별도로 글을 쓰기엔 이해한 바와 내용이 적어, 근황까지 엮어서 작성했습니다..
이력서를 다시 쓰면서 느낀 점
취업 준비를 하다보면 사람인, 잡코리아와 같은 플랫폼에 이력서를 작성합니다. 취업 정보 플랫폼에 있는 양식에 맞춰 내용을 기입하고, 어필하고 싶은 부분을 긁어모아 추가하면 흔한 이력서 한 개가 완성됩니다. 이 이력서를 들고 취업을 했고, 어찌어찌 개발자로 일을 하고 있습니다.
하지만 더 좋은 도전과 기회를 만나려면 이력서도 중요합니다. 아무리 좋은 스킬과 경험, 자신감이 있어도 서류를 통과해야 보여드릴 수 있으니까요. 솔직히 저는 경력이 화려한 사람도 아니고, 실력도 여전히 노력이 필요한 사람입니다. 그럼에도 이력서를 고칠 기회가 생겨 고쳐보니, "궁금하다"를 유도할 수 있는 이력서가 생겨 기쁘더라구요. 이제서야 고칠 생각을 했다니 아쉽습니다.
아무튼, 이번에 선배 개발자님의 도움을 받아 이력서를 수정하면서 공유할 수 있는 부분을 몇가지 적었습니다.
핵심 정보에 집중하기
어쩌면 당연하지만, 저처럼 조바심나는 사람들이 경계해야할 부분입니다.
저는 제 성과를 어필하기 위해 온갖 내용을 다 적었습니다. 제가 메인으로 어필해야할 스킬셋은 물론이요, 한 번 사용해본 것 부터 참여한 교육까지 최대한 최대한 딱지를 많이 붙였습니다.
선배 개발자님께서 보시고 하신 말씀은, 이를 정리하길 바라셨습니다.
- 국비 교육을 포함한 교육 이력은 제외하자. 전공 학부 졸업 외에는 크게 도움되지 않는 정보다
- 스킬 항목에는 면접에서 심화 질문에 답변할 수 있는 항목만 추가하자. 그 외 정보는 다른 항목에 옮겨, 경험해보았다는 점만 남겨두자.
덕분에 대학 졸업만 남긴 채, 교육받았던 내용과 주 스킬인 Java 외에는 내용이 없어졌습니다. 최근에 진행하고 있는 Python 과 딥러닝도 우선은 제외했습니다.
개발과 관련된 항목으로 어필하기
위와 같은 맥락이지만, 제가 중요하다 생각한 정보와 면접관님이 관심갖는 정보는 차이가 있습니다. 중소기업에서 진급을 빨리 했다는 둥, 군대에서 어떤 경험을 했다는 둥... 그것이 개발과 관련이 없으면 크게 의미가 없다고 말씀해주셨습니다.
특히나 주니어에게 기대하는 부분은 우리 업무를 잘 따라올 수 있는가, 잠재력이 있는가를 바라기 때문에 개발 경험에 대한 어필이 중요합니다.
같은 맥락으로, 포트폴리오와 같은 토이 프로젝트도 단순히 코드의 내용은 중요하지 않았습니다. 운영에서 겪었던 장애나 개선 사항을 고민하고 조치했는지를 묻게 만드는 게 중요합니다.
개발과 관련된 어필을 하려면
개발과 관련된 어필을 위해서는 "어떤 개발"과 "어떤 이득"인지가 필요합니다.
- 서비스 개발의 경우, 코드 개선으로 인한 성과를 숫자로 표현
- 동료들을 위해 나서서 개선 또는 문화를 개선 (자동화, API화 등)
- 동료들을 위한 리액션이 좋은가 (해당 프로젝트시 힘을 불어넣거나 보조)
그리고 이와 함께, 저는 '경력기술서'에 '사업'에 참여한 내용을 위주로 적었습니다. 솔루션 담당이니 만큼 신규 개발보다 기능의 수정과 장애 대응 업무가 주였기 때문입니다. 그럼에도 '개발자'로서 어필하기 위해서는 개발적인 경험과 동료를 위한 어필이 필요했습니다.
그래서 저는 사업과 관련된 경력 내용을 정리하고, 최대한 쥐어짠 개발 위주의 경험들을 나열했습니다.
이력서는 면접관의 시선에서 봐줄 수 있는 분께 도움을 받으면 좋다
결과적으로 개선점을 찾을 수 있던 이유는, 직접 면접관을 경험한 적이 있는 선배 개발자님의 도움이 컸습니다. 주니어끼리 고민하고 개선하는 것보다, 면접관님의 시선을 빌리는 것이 정확한 해답을 주었습니다.
개인의 이력과 실력이 부끄럽더라도, 용기내어 이력서를 공개하고 검토를 받아보셨으면 좋겠습니다.
피처 토글
한빛앤 - 작은 서비스 조금씩 개선하기 행사에 다녀왔습니다. 더 나은 배포 방법을 고민하던 중 MSA를 도입했고, 이와 함께 적용했던 프론트엔드의 Module Federation, 백엔드 쪽의 피처 토글을 적용했던 경험기를 공유해주셨습니다.
마침 스터디 동료분께서 발표자님의 회사에서 근무하신터라 관심이 갔고, 서비스 회사에서의 개발 문화를 들을 수 있어 참여했습니다.
그 중에서도 피처 토글에 관한 이야기만 스터디에서 조금 공유했습니다.
피처 토글을 적용한 이유
당시 발표자님 회사는 브런치가 7개까지도 늘어난 적이 있었고, 배포에서 드는 비용을 절약하기 위해 노력을 하던 시기였습니다. 그러다보니 우선 코드를 통합하고 관리하는 Trunk Based Development로 정하였고, 코드 충돌로 인한 배포의 불편함을 줄이고자 피처 토글을 적용하였습니다.
피처 토글을 적용하면서 고려한 사항
- 기존 코드에 영향이 없을 것
if - else사용 배제 - 단일책임원칙- 서비스 코드에는 전략이 포함되지 않게 구성
적용 후의 장점
- 기존 서비스에 영향이 없이 배포 가능
- 원하는 시점에 종료/적용 가능
- 배포와 개발을 분리하여 진행 가능
주의 사항
- 토글에 대한 default 옵션을 지정해야 한다
- 토글의 전략도 다양하므로, 이를 고민하고 구현해야 한다
스터디원의 추가 첨언
피처 토글을 적용하는 방법 또한 다양하다
저는 피처 토글을 발표자님께서 구현하신 형태로 처음 보았습니다. 그래서 "너무 피처 토글의 책임이 큰게 아닌가요?"라는 질문을 드렸습니다.
왜냐하면 피처 제어를 위한 페이지가 별도로 존재하고, 이 기능을 이용하여 광고의 제어(특정 지역, 특정 기간)까지 사용하기 때문입니다.
그런데 말씀하셨을 때는 "개발자의 편의를 위해 구현했다, 기획 등 다른 사람들은 이것에 대해 잘 모른다"라고 답변주시더라구요.
이 질문을 스터디원께도 공유드렸더니, 피처 토글의 다양한 구현 방법의 하나이고 그 중에 하나일 뿐이라고 말하셨습니다. 발표자님의 구현 형태도 Gate 형태의 클래스를 구현해야했고, 이것이 고민되어 직접 피처 토글을 구현하신 적도 있고, 또는 라이브러리를 사용해서 적용할 수도 있기 때문입니다.
피처 토글의 적용이 필요한 형태에 따라 적절하게 구현하는 것이 좋다는 걸 알았습니다.
행사 후기
현장에서 마이크로 서비스 아키텍처에 대해 관심 있는 사람, 그리고 프론트와 백엔드의 기술 하나씩을 훑었는데요. 3가지 주제를 얕게 가져가다보니, 주제를 조금 더 줄여서 집중하는 게 어땠을까 생각이 들었습니다.
그럼에도 불구하고, 한 회사의 서비스를 중심으로 이야기를 풀어나가서 더욱 흥미있게 들을 수 있었습니다.
그리고 사전 질문에서 "피처 토글 구현을 위해 서드 파티를 사용하셨나요?"라는 다소 깊이 없는 질문을 드렸는데, 이 질문이 뽑혀서 책도 받았습니다! 감사합니다!
책의 제목은 '더 나은 프로그래머 되는 법'입니다. 한빛미디어에서 출판한 책인데, 기술보다 '개발자'의 소프트 스킬에 관한 내용으로 채워져있습니다. 스터디 멤버의 말을 빌려보면, "기술은 더 잘하는 사람이 많다. 그렇기에 협력하는 방법과 소프트 스킬을 더 갈고 닦게 된다. 사내에서도 요즘엔 기술보다 소프트 스킬에 더 관심을 가지고 있다."라고 말씀하셨습니다.
기술보다 겸손, 협력에 집중할 수 있는 책을 얻게 되어 더욱 영광입니다. 가능하다면 책을 읽고 후기를 스터디에 공유해보려고 합니다.
이번주에는 AI 관련 행사가 2건(데브콘 5월엔 AI와 모두의 연구소 모두팝)을 참여할 계획입니다.
해당 행사의 참여 후기도 공유드릴 내용이 있다면 적어보겠습니다.
난잡한 글을 읽어주셔서 감사합니다.
