2022년 상반기 회고

2022년 상반기에는 사내 팀 이동이 있었고, 좋은 기회로 개발자 채용 과정에 참여해보았고,

또 나름의 기준을 정해 이직에 성공하기도 했다. 

팀 이동, 채용 참여, 이직 등의 키워드만 보아도 알 수 있듯이 꽤나 역동적이였던 시간

그 흐름이 이제야 일단락되어 다소 늦었지만 상반기 중 배우고 깨달은 것들을 정리해본다.

1. 사내 팀 이동으로 배운 스스로의 힘

회사 내부 사정으로 어드민을 개발하던 팀에서 랜딩페이지를 다루는 팀으로 이동하게 되었다. 

이동한 팀에서 새로운 스택인 Next.JS, emotion을 접했고, 실제 사용자가 존재하는 서비스의 유지보수 작업도 해보았다. 

자신의 의견을 자유롭게 개진해볼 수 있는 환경 덕분에 아래의 경험들도 해볼 수 있었다.

사용자경험 향상을 위해 스스로 개선점을 찾아내 고쳐본 경험

사용자의 액션을 불러일으켜야 하는 UI에 애니메이션을 더할 것을 제안하거나,

데이터 로딩을 개선하기 위해 lazy loading을 고민하고 skeleton UI를 도입하는 등 주체적으로 사고하고 실행해봤다.

주도적으로 팀 개발문화를 형성해본 경험

팀의 commit convention을 제안해 수립하고 commitizen을 도입하며 팀 문화에 기여하고자 노력해봤다.

사소한 경험일지라도 주어지는 업무 외에 스스로 문제점을 정의해 개선해보며 느낀 뿌듯함과 자기효능감은 차곡차곡 쌓여 직업에 대한 애정으로도, 주체적으로 사고하고 행동하려는 동력으로도 쓰이고 있다.

2. 개발자 채용에 참여하며 피부로 깨달은 것들

낮은 연차임에도 불구하고  '함께하게 될 동료' 자격으로 개발자 채용 과정에 참여하게 되었다.

80여건에 달하는 이력서를 검토하며 면접 대상자를 선별했고, 면접에도 참여했다. 

처음엔 다소 부담스러웠지만 과정 속에서 피부로 느끼며 배운 점들이 있어 너무나 소중한 경험이였다. 

연차와 회사에서 원하는 실력이 반드시 비례하지는 않는다

(*  중요한 건 '회사에서 원하는'이란 글귀인데, 모든 경력직 지원자분들의 실력이 객관적으로 부족했다는 이야기가 아니다. 회사의 수요와 일치하지 않았다는 뜻이고, 다른 곳에 가시면 또 다른 결과를 접하실 수도 있었을 것.)

 

이 생각은 나만 느낀 게 아니였는지, 경력자 위주로 시작했던 면접에선 결국 회사의 수요와 더 잘맞을거라 판단된 신입지원자를 채용하게 되었다. 몇십, 몇백명의 개발자가 있는 대기업이 아닌 한명 한명의 영향력이 큰 스타트업인 만큼 하드스킬뿐만 아니라 소프트스킬도 참 중요했다. 변화가 많은 환경에서의 적응력, 최신 기술에 대한 학습 의지, 주체적으로 개선점을 찾아내는 (말 그대로 일을 찾아내는) 적극성 등 

기록의 중요성

정형화된 이력서 포맷과 이력 몇 줄로는 이 지원자가 어떤 잠재력을 가지고 있고 어떤 성향을 가지고 있는지 전혀 짐작할 수 없었다. 

이력서에 링크된 GitHub 계정의 Repo를 보면서 어떤 스택을 사용해봤구나, 사소한 거라도 직접 만들어보며 익히려 하는구나, 어떤 식으로 코드를 짜는구나 등 하드스킬을 짐작해보았고

 

개발 블로그에 써진 글들을 보며 일에 대해 어떤 생각과 태도를 가지고 있는지, 요즘 관심있는 기술은 어떤 것인지, 학습한 내용은 어떤 식으로 정리하는지 등을 파악할 수 있었다. (이렇게 한명 한명 파악하다보니 시간은 좀 걸렸다.) 

 

꾸준한 개인 공부가 필요한 직업이라는 건 인지하고 나름의 노력을 하고 있지만, 내심 회사생활을 착실히 하다보면 나도 모르는 새 질 좋은 경험도 함께 쌓이지 않을까 기대했었다. 그리고 이번 경험에서 그 기대는 와장창 깨져버렸다 .

 

물론 누구나 알 법한 회사에서의 경력, 오픈소스 기여 등 화려한 경력이 있다면 그 자체로도 설명이 가능할 수도 있겠지만 그

렇지 않은 단계라면 내가 뻗어나가고 싶은 갈래로 더 꾸준히 노력해야 경쟁력을 갖출수 있다는 사실이 현실로 다가왔다.

이력서에, 블로그에, Github에 나를 어떻게 더 녹여낼 수 있을까 고민해보는 계기가 되었다.

3. 이직을 고민하고, 실행하기까지

마치 경력의 최소단위처럼 일컬어지는 1년을 채우지않고 7개월만에 이직하게 되었다.

짧은 경력을 가지고 이동을 하는 결정을 내리기까지는 나 자신에게도, 이력서를 제출한 회사에게도 납득할만한 이유가 필요했다.

그 이유는 내가 생각하는 프론트엔드 개발 직무와, 이직을 하며 가장 중요하게 생각한 기준과 연결된다.

 

스스로 생각하기에 프론트엔드 개발자는 사람과 가장 맞닿아 있는 개발 직무다.

기획자, 프로덕트 디자이너, QA엔지니어, 프론트엔드 개발자, 백엔드 개발자 등 모든 개발 프로세스 인력과 소통하며 개발을 진행하고 개발 프로세스의 종착점인 사용자와도 접점을 가진다. 그렇기에 더더욱 사람과 소통하며 개발하는 방법을 알고 있어야 한다고 생각했다.

또 여러 갈래의 시니어 트랙 중 EM 직무에 관심이 있는 만큼 기술적인 지식만큼 매니징 스킬을 배우고 싶었다. 

 

주니어 중에서도 1년 미만의 낮은 연차인 지금은 원하는 기능을 구현하는 실력을 높이는 것도 중요하지만 

다양한 직군과 협업을 해나가며 개발을 하는 방법을 배워야하는 시기라고 판단했다. 

따라서 이직을 하며 가장 중요하게 생각한 기준은 기획 - 개발 - QA 등 개발 프로세스별 인원이 명확하게 구분되어 존재하고 협업하고 있는가였다. 

 

전 회사는 기획자, QA 엔지니어가 존재하지 않아 프로덕트 디자이너 1명과 2명의 개발자가 모든 개발 프로세스를 자체적으로 해결했으며

신규 인력 영입은 영업 직군에 밀려 개발 직군이 채용될 가능성은 현저히 낮았다.

메인 프로덕트가 오프라인 영업 서비스였으니 경영진 입장에선 개발 인력을 채용하는 것보단 당장 매출을 올릴 수 있는 영업 직군을 채용하는게 비즈니스적으로 옳은 선택이였을지도 모른다. 다만 개발자 입장에서는 아쉬움이 남는 환경이였다.

 

시간이 흘러 더 큰 곳에 가서 익히면 되지않나?라고 생각할 수도 있지만 개발 방향을 수립하는 시행착오의 시기는

되도록 연차가 낮을 때 겪고 싶었다. 나도 모르게 굳어버릴 아집이 생길까봐 두렵기도 했다.

 

레거시 코드를 파악하고 개선해나가는 것보다 아예 처음부터 만들어나가는게 더 쉽듯이,

조금이라도 말랑말랑할 때 여러 직군과 실무적으로 협업하며 개발해나가는 방식을 몸에 새기려 한다. 

 

모든 면접장에서 위 내용을 토대로 이직 사유를 설명했고 또 관련해서 회사 측에 이런 저런 질문을 하기도 했다.

좁은 식견에서 비롯된 나만의 생각일까 걱정하기도 했는데 다행히도 면접관 분들이 이해와 공감을 해주셨고 합격까지 이어질 수 있었다. 

 

오퍼 메일에서 담당하게 될 서비스를 미리 전달받은 뒤 새 회사의 출근일을 기다리고 있는 지금,

잘 할 수 있을까 떨리기도 하고 새로운 업무와 환경에 대한 기분좋은 설렘이 공존하고 있다.

조금 더 뿌듯하게 채워진 마음으로 하반기 회고를 작성할 수 있기를!