[회고록] 첫 직장, 2개월 수습기간 그리고 정규직 전환

⚡️~ 24. 05. 02 : 입사

길다면 길고 짧다면 짧았던 내 취준 기간이 끝나고 첫 출근 날이 다가왔다. 첫 회사 첫 출근인만큼 내 마음에 열정이 가득하다. 이 열정들이 회사 동료들에게까지 전파가 되었으면 좋겠다. 
 

⚡️~ 24. 07. 02 : 수습기간

📌좋은 사람들

입사 후 기대했던 온보딩은 없었다. 팀원들에게 자기소개를 하고 약 3일 간의 업무 적응 후 바로 개발 업무에 투입되었다. 그래도 좋은 팀원들이 있었기에 빠르게 적응할 수 있었다. 특히, 입사 후 얼마되지 않아 부사장님, 개발 1팀장님, 개발 3팀장님과 함께 회식을 했는데, 생각보다 마인드도 젊으시고 너무 재밌었다. 3차로 노래방도 갔는데 함께 춤도 추고 어깨동무(?)까지 했다. 물론 다음 날에 부끄러워서 인사는 못했다. 🤣
 

📌연구자와 개발자

입사하기 전부터 항상 고민해왔던 것은 "회사에서도 테스트, 클린코드, 객체지향을 지향할 것인가?"와 "클린하고 객체지향적이지 못해도 회사 컨벤션을 따라갈 것인가?"였다. 당연히 후자가 맞다는 생각을 했다. 하지만 막상 입사하고 첫 개발을 시작하면서 생각보다 객체지향적이지 못한 코드를 보니 받아들이기가 어려웠다. 특히, 첫 개발 업무로 Kakao URL 권한 Filter를 구현하면서 받아들이는 게 어려워 팀장님께 조언도 구했다. 이는 커뮤니케이션의 용이성 그리고 보안, 사이드 이펙트 등 너무 많은 이유가 있었다.
 
예를 들어, 회사에서의 개발 기한은 정해져있다. 당장 고객사에 나가야 하는데, 클린하고 객체지향적인 개발을 하기 위해 코드를 수정하고 이로 인해 사이드 이펙트가 발생하여 개발 기한을 못 맞춘다면 이는 개발자라 할 수 없다는 생각이 든다. 개발 기한을 신경쓰지 않고 당장 내가 궁금한 것을 연구하고 고객사를 생각하지 않는 개발자는 개발자가 아닌 연구자다.
 
물론 새로운 프로젝트를 하거나 기간이 충분하다면 전자 방향으로 개선하는 것도 좋다. 그리고 아예 생각을 배제하는 것보다는 어느정도 중간 타협점을 찾고, 점점 코드에 스며들게 하는 것도 좋다는 생각을 한다. 무조건 후자를 따른다는 것은 성장을 잊고 Bad Smell 코드를 전파하는 것일 수도 있다는 생각이 든다. 결론적으로는 고객사에게 나가야하고 우리는 혼자 개발하는 것이 아닌 팀원들과 개발하는 것이기 때문에 커뮤니케이션을 중요시해야 하는 것을 잊지 말아야 한다.
 

📌커뮤니케이션의 중요성

두 번째 업무로 PDF 변환 다운로드 기능을 개발하게 되었다. 난이도가 있는 업무는 아니였지만, 생각보다 개발 기간이 너무 오래 걸렸다. 원인은 성능 테스트 과정과 라이브러리 및 에러 분석 그리고 '커뮤니케이션'이다.
 
앞서 내가 테스트하고 분석한 과정들을 팀장님께 어떤 식으로 전달할 지 고민했다. 나름, 보고서도 작성하고 리뷰로도 열심히 남겼지만, 막상 팀장님을 마주하고 구두로 전달하려고 하니 횡설수설하는 나를 볼 수 있었다. 특히 맞선임께서 내가 의견을 전달하는 모습을 보고, 개선해야할 부분으로 말의 빠르기를 지적해주셨다. 어릴 때부터 급한 성격이 단점이었지만, 크게 불편한 점이 없었다. 하지만 성격이 급하니 말이 빠르고 말이 빠르니 전달력이 떨어지고 결국 듣는 사람 입장에서 듣기 불편하니, 회사에서의 협업 생활에 크게 문제가 되는 것을 몸소 느꼈다. 이처럼 주변 팀원들이 나의 단점을 무시하는 것이 아닌 캐치해주고 이 단점을 이겨낼 수 있도록 만들어주는 팀원이 있어서 입사를 잘한 것 같다는 생각을 한다. 기술 성장도 중요하지만 협업 능력, 커뮤니케이션 능력 부분에서도 성장하는 것이 중요하다는 생각이 든다.
 

⚡️24. 07. 02 ~ : 앞으로의 포부와 계획

1. '아마도'가 아닌 '확신'을 기반으로 내 의견을 전달할 수 있는 개발자가 되기.
커뮤니케이션에 있어서 중요한 것은 너무 많겠지만, 그 중에서도 스스로에 대한 믿음이 중요하다는 생각이 든다. 다만 믿음이 고집이 되면 안된다. 개발에 정답은 없을 뿐더러 제 3자의 의견을 들을 때, 내가 놓친 부분을 캐치할 수 있기 때문이다. 항상 열린 마음으로 부드럽게 설득하자.
 
2. 어떤 일이던 수치화하고 객관적으로 바라볼 수 있는 역량 키우기.
본인의 퍼포먼스를 파악하고 그에 맞게 스프린트 계획을 정리해야 하는데, 아직 나의 퍼포먼스를 파악하기 쉽지 않음을 느꼈다. 예를 들어, 과도하게 이슈를 잡거나, 3일이면 충분하다는 생각이 들었지만, 잦은 회의와 갑작스럽게 생긴 이슈 등을 고려하지 못해 기간 내에 개발을 끝내지 못하는 순간 책임감이 떨어지는 개발자가 된다. 때문에, 갑작스런 이슈 등을 대비하기 위해 약간의 버퍼를 둬보면서 본인의 퍼포먼스를 정확하게 파악하고 이슈 분배를 잘하는 것이 중요하다는 생각이 든다. 항상 어떤 일이든 수치화하고 객관적으로 바라볼 수 있는 시각을 가지자.