- 조금 더 common한 코드 베이스에 기여하기 / 목적 조직에서 일하기
웹 코드 베이스에 대한 이해도가 늘어나고 shared, common 정도로 표현되는 공통 모듈에 대한 기여도 자연스레 늘어났다. 목적 조직에서 몇 개월간 일하기도 했는데 작년 한 해 가장 몰입해서 일했던 경험으로 기억됐다. 내가 맡은 부분이 아니더라도 전체 제품에 대한 맥락을 고민하는 경험이 좋았다. 자연스레 업무시간 내 회의와 논의하는 시간은 상대적으로 늘어나고 코드를 집중해서 작업하는 시간은 줄었던 점은 아쉽다.
- 희망 퇴직과 인수합병 이슈
회사가 경영상 어려움으로 인해 인원을 절반 가량 감축했다. 나도 회사를 계속 다닐지, 혹은 다닐 수 있을지 걱정하고 고민하느라 심적으로 어려웠다. 결과적으로는 계속 회사를 다니고 있다
회사가 감정적으로 격정적인 시즌이었다. 떠나기로 마음 먹은 분들은 그 자리에서 바로 짐을 싸고 나가셨다. 함께 일하던 동료들을 하루아침에 떠나보내는 일이 쉽지 않았다. 희망퇴직 이후로도 회사의 인수/합병 이슈 등이 반복되었다. 거취의 불확실성을 지닌 채로 일하는 것이 직원으로서 불안정하게 느껴진 한 해였던 것 같다.
배운 점이 있다면 이러한 변화 조차도 버텨낼 수 있는 어려움이라는 것을 알았다는 점이다. 그런 상황에서 스트레스를 받는 것은 피할 수 없었지만 할 일을 하다보니 어떻게든 버텨냈다.
당연한 사실이지만 회사와 개인은 계약 관계이고, 그 계약은 생각보다 견고하지 않을 수도 있겠다는 생각도 들었다. 개인으로서 더 길게 이어질 내 삶을 잘 개발하기 위해 노력해야겠다는 생각도 들었다.
어떤 선택을 하셨던지 함께 어려운 일을 겪은 동료 분들이 다들 잘 지내셨으면 좋겠다.
- 혼자 개발하기
희망 퇴직으로 인해 웹 프론트엔드팀 팀원들이 모두 떠났다. 혼자서 잘 해낼 수 있을지 걱정이 많았다. 가장 오래 시간을 보낸 팀 동료들이 떠나니 일적인 면을 떠나서 심적으로도 어려웠다.
홀로 제품 개발에 투입되니 심리적 압박을 느끼는 경우가 종종 있었다. 어떤 문제가 잘 풀리지 않을 때, 기한은 정해져 있고 함께 논의할 사람은 없으니 그러한 압박감이 주는 스트레스가 있었다.
어떤 태스크를 진행하고 있는데 새롭게 다른 태스크가 들어오는 것의 핸들링이 힘들었다. 원래라면 다른 동료와 잘 분배해서 처리했을 일인데 이제는 어떻게든 혼자 해내야 하는 일이 됐다.
일단 일이 새롭게 들어오면 우선순위와 마감 기한에 대해서 커뮤니케이션을 했다. 급한 일이라면 진행 중인 일이 있더라도 미뤄두고 먼저 처리하는 등의 태스크 관리가 필요했다. 회사 Jira와는 별개로 개인적으로 ToDoist 등 툴을 사용해 일감을 정리했다. 개인 툴에 들어온 일의 우선순위, 마감기한, 업무 내용과 메모 등을 정리해 어쩔 수 없이 많아지는 업무 간 context switching을 효율적으로 할 수 있도록 노력했다.
돌이켜보면 일이 많았던 것도 있었겠지만 혼자라는 사실이 주는 심리적 압박감에 더욱 이것저것 도구나 방법 등을 찾았던 것 같다.
결과적으로 큰 이슈 없이 홀로 회사의 웹을 약 4개월간 운영했다. 신규 입사자 분이 오셔서 1인팀 생활은 마무리할 수 있었다. 웹 개발의 병목이 제품 개발 전체의 병목이 되는 상황이 두려웠는데 그런 상황은 일어나지 않아서 다행이다. 또한 내 의사결정이 미치는 범위가 상대적으로 커지는 상황을 경험하고 익숙해질 수 있었던 것 같다.
- 채용 프로세스 참여
같이 일할 팀원을 뽑는 채용 프로세스에도 참여했다. 면접관으로서 면접에 참여하는 일이 처음에는 긴장되고 부담스러웠다. 회사의 얼굴로서 공적인 자리에 참여한다고 생각하니 어깨가 무겁게 느껴졌다.
자연스레 지원자를 어떻게 평가할 것인가? 혹은 어떤 질문을 할 것인가? 에 대한 고민도 이어졌다.
개인적으로 퀴즈 식의 면접은 면접자를 검증하는데 큰 도움이 되지 않는다고 생각한다. 왜냐하면 그런 식의 질문들은 면접 준비를 했다면 대답이 가능한 종류의 질 문이기 때문이다. 혹은 어떤 질문은 실무와 매우 동떨어져 준비를 '해야만' 대답이 가능한 경우도 있을 것이다.
내가 같이 일하고 싶은 사람은 면접 준비를 잘 하는 사람은 아니었다. 벼락 치기가 가능한 질문에 대답을 잘한다고 해서 조직에서 원하는 역량을 검증할 수 없다고 생각했다.
퀴즈 같은 질문을 최대한 지양하고 면접자 분이 문제를 접근하는 방법이나 어떤 주제에 대한 개인적인 의견들에 대해서 질문했다. 또한 그것을 표현하는 커뮤니케이션 내지는 태도 또한 집중해서 보았다.
- 정답 맞추기
코드에 정답이 있다고 생각하곤 했다. 작업을 시작하기 전에 best practice 따위의 검색 결과를 주욱 훑었다. 문제에 대해 내가 떠올리지 못하고 있는 정답이 있을 거라고 생각했다.
지금으로서 내린 결론은 설사 그것이 존재하더라도 그다지 중요하지 않다는 것이다. 요구사항은 항상 변화하고 그로인해 '그때는 맞지만 지금은 틀리다'와 같은 상황이 계속 발생한다. 그 때 그렇게 탐닉했던 정답은 지금에 와서는 의미없는 것이 되는 경우가 많았다. 결론적으로는 정답에 대한 탐닉은 그만두기로 했다. 이는 코드 퀄리티를 포기하겠다는 의미는 전혀 아니다. 문제를 바라보는 관점이 달라졌다는 정도의 의미로 볼 수 있겠다. 변경을 감히 예측할 수는 없지만, 변경이 용이한 코드를 만들어야 한다는 생각이다.
지금까지 같이 일하며 '이런 사람과 일하면 좋았다'라는 사람들의 특징을 떠올려 보았다. 그런 사람들은 항상 정답을 제시하는 사람들은 아니었다. 여러 모습들이 있겠지만 그들은 대체로 주어진 기한을 준수하고, 과정과 결과를 공유하고, 꾸준히 개선을 해내는 사람들 이라고 생각한다. 편안한 논의 파트너이기도 했다. 그렇다면 나 또한 항상 퀴즈의 정답을 맞추는 사람일 필요는 없을 것이다.