후회
언제부터인가 “후회 하지 말자”라는 생각을 하면서 살고 있다.
하지만 2023년은 내게 너무나도 후회되는 한해이다.
이직을 두번이나 한 해였다.
2022년 말 합격 통보를 받아 2023년 1월 말 회사를 옮겼고, 같은 해 9월 다시 다른 회사로 이직하게 되었다. 고졸 개발자로 커리어 초반에는 열악한 회사에 다니다 보니 개발자로 먹고살려고 이직하게 되었지만, 경력이 쌓여가면서 내 커리어를 위해 그런 선택은 하지 않을 거로 생각하였는데 왜 이런 선택을 할 수밖에 없었는지 되짚어 보자
이유
일단 2023년 1월 이직을 하려고 한 이유는 무엇이었을까?
나라는 개발자의 시장가치는 어떠할지 궁금하였다.
심플하고 중요하지만, 더 많은 이유가 있었어야 하였다.
2023년 두 번째 이직은 너무나도 명확했다.
나에게 너무 맞지 않는 회사다.
이 결론은 입사하여, 한 달 만에 내린 결론이고, 퇴사 후 다른 회사에 다니면서 정말 잘한 결정이었다고 생각한다.
그러면 그렇게 결정한 기준은 무엇이었을까?
기준
경력을 쌓아오면서 경험한 것들에 대해 좋고 싫음, 옳고 그름에 대해 내 나름의 기준이 생겼을 것인데 그런 것들에 대해 정리하는 시간을 갖지 않았다.
기준이 없었기에 나에게 맞지 않는 선택을 하였고 이를 바로잡기 위해 엄청난 노력을 하여야 했다.
성장
개발자는 일하면서도 성장 할 수 있다라는 생각을 가지고 있었다.
그렇기에 지금 다니는 회사보다 더 큰 회사를 가면 그 회사가 가지고 있는 기술력을 통해 더 성장할 수 있지 않을까 하는 막연한 동경을 가지고 있었던거 같다.
얼마 전 참석해서 들었던 구름 COMMIT - 김영재님의 시야가 넓은 개발자는 무엇이 다를까?(이하 COMMIT - 김영재님 세션)에서 들었던 ”성장은 셀프입니다.”라는 짧지만 강력한 메시지를 듣고 나는 어떻게 성장해 왔는지 되돌아보기로 했다.
개발 서적과 스터디
처음 일을 시작하고 몇 개월이 안 되어서 우연히 알라딘 중고 매장을 들렀다가 개발 서적 할인율이 높은 것을 보고 너무 감격하며 구매한 기억이 있다.(4년 차 즈음부터 개발 서적 구매 지원되는 회사에 다녔으나, 습관이 되어 아직도 많은 서적을 직접 구매를…)
그렇게 개발 서적을 구매해 읽고 업무에 적용도 해보고, 게을러져 읽지 않는 책이 있으면 스터디를 찾아 참여하면서 강제로라도 읽으려고 노력해 왔던 거 같다.
블로그 글에도 좋은 내용들이 많지만, 지식이 단편적으로 올라오기 때문에 개발 서적을 통해 알게 된 것들이 더 많지 않았나 싶다.
커리어 멘토가 되어주는 이전 동료
본인은 아시는지 모르겠지만 커리어 고민이 있으면 전화하게 되는 전 회사 동료가 있는데 나이, 경력도 비슷하지만, 이분과의 대화를 통해 늘 새로운 인사이트를 얻고 내 커리어를 쌓아 올리는 데 많은 도움을 받았다.
슈퍼 개발자와?!의 만남
짧게 재직한 스타트업에서 한 명의 백엔드 개발자가 반년도 안되는 시간에 정말 많은 것을 할 수 있다는 것을 옆에서 경험한 시간이 있다.(인프라 구성부터 서비스 운영까지…)
같이 개발을 진행하면서 하나의 서비스를 위해 많은 것들이 필요하고 공부해야 할 것이 많다는 것을 깨닫고 학습의 영역을 넓히게 된 경험이다.(몇 년 전부터 사내에서 프론트엔드 인프라 구축을 위해 많은 시간을 쓰고 있는 건 이때의 경험 때문일까?..…)
반면교사
너무나도 많은 반면교사를 만났기 때문에 다 이야기하진 못하지만
나는 저렇게 하지(되지) 말아야지 다짐하고
경력이 쌓인 요즘은 나도 누군가의 반면교사가 되지 말아 야지를 늘 다짐한다.
결국 성장은 셀프
정리해보니
스스로 공부하고, 스터디에 참가하고, 옆의 동료 경험을 내 경험으로 만들고자 노력해 오면서 성장해 왔다.
큰 회사에 다니지 않았음에도 성장 할 수 있었다.
무조건 큰 회사에 가야 성장할 수 있다는 생각은 정답이 아니라고 정리가 되었다.
하지만 주변의 어떤 “동료”가 있는지는 중요할 것 같다.
물론, 나도 그런 동료가 되어야 하겠지만..
리더
리더가 정말 중요하다는 것을 또 한 번 깨닫는 한해였고,
내가 리더가 되거나 아니면 또 다른 선택을 해야 한다면 어떤 부분을 기준으로 삼아야 할까…?
앞에 참석했던 우아한형제들의 시니어 공감테크쇼, COMMIT - 김영재님 세션을 들으면서 한 분이 떠올랐다.
가장 오래 재직했던 회사의 팀장님
내가 경험한 것을 통해 내 나름의 기준을 정리해 보자
목표와 얼라인
항상 해가 바뀌기 전 팀의 내년 해야 할 일을 정리하시고 공유를 하셨고 중간에 목표가 바뀌면 이에 대해서 공유하셨었다.
매해 하시다 보니 당연한 줄 알고 있었는데 내가 경험한 대다수의 관리자는 목표를 공유하지 않고 task만 시키는 경우가 많았다.
이렇게 task만 진행하다 보면 서로 바라보는 골이 다르게 되어 중간에 이를 바로 잡으려면 몇 배의 에너지가 소모되는 경험도 하였다. (중간에라도 알면 다행일지도….)
올해 조직의 목표는 무엇인가요? 목표의 점검은 언제, 어떤 방식으로 진행되고 있나요? 어떤 방식으로 목표를 공유하고 계시나요?
위임과 피드백
2년 넘게 팀의 프론트엔드 파트 리드를 한 적이 있다. 나 포함 3명인 조그마한 구성이었지만 많은 부분을 위임하셨기에 파트 원들과 상의해 가며 자유롭게 진행하고 더 책임감을 가지고 일을 진행하였던 거 같다.
최근 이런저런 리더십 관련 글을 읽으면서 위임을 통해 자율성 → 동기부여 → 책임감으로 이어진다고 하는데 직접 경험하지 않았나 싶다.
피드백을 주려면 상대에 대해 알아야 한다. 업무라면 진행되고 있는 내용에 대해 파악해야 제대로 된 피드백을 줄 수 있을 것 같다. 하지만 팀원이 많아지고 업무의 형태가 많아지면 챙기기가 쉽지 않은데 어떻게 진행하셨을까?
Jira의 Plans로 일정 시각화, 관련 업무는 무조건 티켓링크를 달도록 하셨고 또 관련 문서를 Confluence에 작성할 때도 티켓링크를 달도록 하여 컨택스트가 하나의 티켓에 모일 수 있도록 하셨는데 이를 통해서 업무 파악을 쉽게 하려고 하셨던 것이 아니셨을까?, 그렇기에 피드백 또한 적절히 이루어질 수 있도록 하셨던 거 같다.
조직의 업무 형태는 어떤 것들이 있나요? 조직의 업무 진행을 위해 어떤 것들을 확인하시나요? 조직의 일정 파악은 어떻게 하고 계시나요? 어떤 피드백을 하고 있나요?
일을 할 수 있게 해주는 리더
일을 하라고 쪼는 리더가 아닌 일을 할 수 있게 해주는 리더이다.
COMMIT - 김영재님 세션 중 “인터페이스”를 이야기하시는 부분이 있으셨다.
들으면서 협업하는 부분에 있어서 인터페이스가 가장 중요하지 않을까 생각하면서 리더는 팀원 간, 팀 간, 그리고 프로젝트의 모든 이해관계자와의 협업에 앞서서 인터페이스를 정의해야 하지 않을까? 라는 생각을 하였다.
또 모든 부분을 챙길 수 없으니 서로 협업하는 부분의 인터페이스를 정의하고 시작하라고 팀원들에게 요청해야 하지 않을까?
이를 통해 팀원들이 “자기 일만”하는 것이 아닌 “팀원 간” 일을 할 수 있게 하여야 하지 않을까? 라는 생각을 하게 되었다.
조직이 일을 하기위한 어떤 약속들이 존재하나요? 이 약속들이 잘 지켜지고 있나요? 이 약속들이 문서화 되어 관리되고 있나요?
피해야 할 리더십
피해야 할 리더의 유형도 많을 텐데 최근에 본 링크드인 글로 대신해 본다.
비겁한 리더십
그 외
이 부분 말고도 선택의 기준은 많지만 직장을 다닌다면 선택하는 기준이라 적지 않을 생각이다.
앞으로
앞으로 선택은 신중히
나만의 기준을 세워가면서
그 기준을 내가 지켜가면서
그렇게 커리어를 쌓아가야 하지 않을까?…