2023년 마무리 (+ 2022년)
예전에 올린 "또 다른 챕터"에 내가 왜 한국을 떠나 캐나다로 돌아오게 되었는지에 대해 적었다. 그 글을 올린 지 거의 2년이나 지난 지금, 회사에서 겪은 다양한 변화들을 되돌아볼 때가 된 것 같다.
커리어 성장에 집중할 수 있는 환경
한국에서 일하면서 가장 어려웠던 점 중 하나는 커리어 성장을 위한 명확하고 체계적인 로드맵의 부재였다. 물론 회사는 임직원들이 성장하길 장려하고 지속적으로 적절한 환경을 만들고 있다고 알려준다. 하지만 내가 느낀 차가운 현실은 혼자 알아서 성장해야 한다는 환경이 당연했다. 내 커리어의 다음 단계를 위해 정확히 어떤 부분을 개선해야 하는지 객관적으로 파악하는 것은 꽤나 어려웠다. 같이 일했던 동료 중 한 명이 "개발자라면 혼자 성장할 줄 알아야 해요"라고 내게 말해줬던 적이 있다. 생각이 많아지는 조언이지만, 아직도 좋은 조언인지는 잘 모르겠다. 서울에서의 2년 남짓한 경험에서 깨달은 건, 개발자의 커리어 성장은 근본적으로 기술적 역량 향상에만 초점이 맞춰져 있다는 것이다.
지금 회사에서는 상황이 정말 다르다. 팀장들은 (engineering manager) 내게 커리어 목표를 세우도록 끊임없이 유도한다. 뿐만 아니라, 커리어 방향과 일치하는 프로젝트를 찾고 앞으로의 성장에 대한 전반적인 대화를 할 수 있도록 도와준다. 자연스럽게 내 커리어에 대해 더 많은 시간을 할애하게 되는 환경이다. 현 회사에는 레벨마다 기대하는 역량이 명시되어 있는 개발자 레벨이 존재하다. 완벽한 시스템은 아니지만 다음 레벨로 올라가기 위해서 어떤 역량을 가져야 하는지 명확하게 알려주는 프레임워크를 제공해 준다.
유연성 있는 워라밸
한국은 일하는 시간이 길다는 편견 혹은 고정관념이 예전부터 존재하지만 북미의 많은 사람이 생각하는 것처럼 한국 개발자의 워라밸이 극단적이진 않다고 느꼈다. 다른 문화에서 오는 업무에 대한 기대치는 많이 다르고 유연성은 적지만 한국의 워라밸은 점점 나아지고 있다고 생각한다. 경험상 일주일이 넘는 긴 휴가를 쓰는 건 권장하지 않고 (지금과 같은 연말에도) 항상 회사/팀의 연락을 받을 수 있어야 하는 것이 당연하다 느꼈다. 한국에서 일한 회사 중 한 곳에서 출퇴근 시간을 매일 기록해야 한다고 했을 때 크게 놀란적이 있다. 심지어 인턴일 때도 경험해보지 못한 신기한 (?) 문화였다.
On-call (대기? 당직?) 스케줄, 급한 프로젝트, 혹은 "빨리 테스트해보고 싶다"와 같은 이유 때문에 업무 시간이 크게 줄었다고 할 순 없지만 캐나다에 돌아온 뒤로 내 시간에 대한 자율성이 더 높아졌다. 퇴근 후 슬랙을 확인하지 않고 업무에서 아예 로그오프 하는 것이 사회적으로 용인되는 환경이 한 몫했다.
문서화: 0부터 100까지
다녀본 모든 한국 회사에서는 부실한 문서화가 큰 문제로 고려되지 않았다는 점이 흥미롭고 조금은 실망스러웠다. 당연히 문서가 없는 것은 아니었지만 대게 수정되지 않았거나 작성자마다 일관되지 않은 서식으로 관리되었다. 소수의 인원들만 문서 유지 관리에 시간을 할애하고 있었다. 상황에 따라 우려 제기를 했음에도 불구하고 경영진/리더급 사람들의 공통적인 반응은 시간이 부족하다는 것이었다, 모든 개발자는 코딩하느라 바빴다. 2천만 명의 월간 활성 사용자 수를 가진 회사에서도 같은 문제가 존재했다. 팀과 이해관계자들이 이해하기 쉬운 문서를 작성하고 최신 정보로 유지하는 것은 어려운 일이다. 하지만, 문서화에 대한 관심이 부족한 점은 문제였다. 한국에서 일하는 동안 개발 계획부터 배포까지 아우르는 엔지니어링 디자인 문서를 (engineering design document) 단 하나도 작성하지 않아도 되었다는 사실은 지금 회사에선 믿을 수 없는 일이다.
공평하게 말하면 한국 회사가 아닌 곳에서도 문서화 개선은 항상 필요했다. 현 직장에서 눈에 띄는 점은 문서화가 가진 역할에 대한 인식이다. 2년 동안 문서화가 필요 없던 시기를 지나서 지금은 많은 엔지니어링 디자인 문서를 만들고 검토하는 작업을 하고 있다. 유일한 단점은 개발 속도가 떨어진다는 것이다. 문서 리뷰 단계가 가끔 엄격하게 진행되면서 빠른 반복을 (iteration) 어렵게 만든다. 문서화와 개발 프로세스 사이의 적절한 균형을 찾는 것은 꽤나 어려운 일이다.
100회가 넘는 기술 면접 진행
한국 개발자 면접 과정은 북미에서 흔히 접할 수 있는 과정과 크게 달랐다. 한국에서 경험한 본 면접은 보통 한 개의 기술 면접과 한 개의 인성 면접으로 짜여있었다. 회사마다 다르지만 각 면접은 60분에서 90분 정도 진행되었고 기술 면접에는 2~3명의 면접관이 참여했다. 면접에 등장한 질문들은 주로 지원자의 업무에서 사용되는 기술에 대한 지식 (예: JVM의 다양한 garbage collection, locking 방식) 및 특정 프레임워크에 대한 친숙도에 (예: Spring Boot의 기능들) 초점이 맞춰져 있다. 지원자들은 자신의 지식의 깊이와 넓이에 평가된다. 특이했던 점은 본 면접에는 코딩 면접이나 시스템 설계 면접이 없었다. 모든 면접이 양방향으로 소통한다는 느낌이 없었고 일부 면접은 조사를 받는 듯한 느낌을 받았다.
지원자에 대한 종합적인 시각을 제공하는 데 있어서 이러한 면접 방식은 제한적이라 생각한다. 그래서 한국에서는 지원자 자리에 있는 것뿐만 아니라 면접관으로 참여하는 것도 좋아하지 않았다. 개발자 역량 평가에 큰 가치를 가져다주지 못하는 것 같다. 그러다 보니 캐나다와 미국 다수의 회사들이 진행하는 면접 형식을 선호한다. 협업 환경에서 이뤄지는 여러 라운드와 다양한 유형의 면접이 포함된 방식이다. 비록 면접에 참여하는 양측 모두 더 많은 시간과 노력을 요구하지만, 이러한 방식이 지원자의 적합성 평가에 필요한 포괄적인 방법을 제공한다고 생각한다. 만약 여기에서도 암기한 내용을 확인하는 질문들로만 면접을 진행해야 했다면 지난 2년 간 100개 이상의 기술 면접에 참여하지 않았을 것이다.
적고 나서 보니 한국에서 개발자로 일하는 것에 대한 부정적인 견해만 보여준 게 아닌가 싶다. 캐나다와 미국에서 대부분의 경력을 쌓아왔기 때문에, 한국에서 일하면서 직접 겪은 업무 문화는 상당히 이국적으로 다가왔다. 캐나다에서 한국으로 갔을 때 느꼈던 변화가 한국에서 캐나다로 다시 돌아왔을 때 느낀 변화보다 훨씬 더 컸다. 그래서 이런 글을 쓰게 되었다. 세계 여러 나라에서 같은 직업을 해본 이력은 다양한 경험을 해보면서 어디에서든지 빠르게 적응을 하는 데에 도움이 되고 있다.
