새로운 회사, 큰 꿈과 희망을 가지고 이직을 하기엔 더 큰 문제가 우리 앞을 도사리고 있을 확률이 높다. 낯선 공간, 낯선 사람, 낯선 개발도구들. 모든 것이 낯선 상황에서 어떻게 새로운 조직에서 성과를 만들 수 있을까?
1. 신뢰가 우선이다.
바꾸고 싶어도 참아라.
일을 하기 전에 기본적으로 신뢰를 쌓아야 한다. 조직에 새로운 사람이 왔을 때 일은 어떻게 해야 할까요? 라는 익명 질문에 우아한 형제들 대표님은 이렇게 답했다.
“일을 시키기 전에 상대방과의 신뢰관계 형성이 먼저입니다.”
인상깊은 답변이었다. 사람들과의 신뢰를 쌓지도 않은 채 억지로 무언가를 하려다 보면 커뮤니케이션이 부족할 것이다. 그러면 완전히 다른 방향성으로 갈 확률이 매우 높다. 또한, 내가 편한 방식으로 바꾸자고 주장하는 건 신뢰관계가 없는 상황에서는 반감이 먼저 생기기 마련이다. 바꾸려고 하는 것보다 왜 동료들이 그렇게 하고 있는지를 이해하는 것이 필요하다. 적어도 3개월은 기존 일하는 방식을 건들지 말고 자연스럽게 스며들어야 한다.
관찰자처럼 어떻게 일하는지를 지켜보는 것도 방법 중 하나이다. 다른 사람들이 어떻게 업무를 진행하는지 아는 것은 내가 업무를 할 때의 좋은 레퍼런스가 될 수 있다. 또한, 내가 업무를 진행할 때 끊임없이 피드백을 받을 수 있도록 해야 한다. 내가 엉뚱한 방향으로 가지 않게끔 방향성을 항상 확인해야한다. 팀이 원하는 방향성으로 업무를 진행 중인지에 대해 이야기하면서 팀원들과 커뮤니케이션을 통해 신뢰를 쌓아야 한다.
2. 과거를 무시하지 마라.
새로운 조직이나 프로젝트에서 기존의 코드를 보면 리팩터링 욕구가 막 샘솟을지도 모른다. 당장 멈춰야 한다. 그 코드는 과거의 누군가에게는 최선이었을 것이다.
완벽한 코드는 세상에 없다. 지속적으로 좋은 코드를 향해 변화하는 코드만 있을 뿐이다. 조금씩 꾸준하게 개선을 해나가야 하며 한번에 갈아엎을 생각을 하지 말아야 한다. 그것을 무시하고 폄하하는 말투는 최악이다. 코드 리뷰 등을 통해서 토론하고 다수가 동의하는 구조로 개선해 나가야 한다. 설득이 필요하다면 샘플 프로젝트 등을 통해서 예시를 보고 설득해야 한다.
3. 회고의 중요성
회고란 지나온 길을 뒤돌아보고 앞으로 더 나은 방향으로 나아가기 위한 과정이라고 본다. 첫 회고에서 동료들의 아쉬운 점 중 코드 리뷰가 힘들다는 내용이 공통적으로 있었다. 나만의 고민이 아니였구나 하는 걸 깨달았고 의견을 내어 매주 오프라인 코드 리뷰를 제안하기도 했었다.
입사 6개월 차에 회고를 하자고 먼저 제안을 했다. 업무 리딩 해주셨던 분이 흔쾌히 승낙을 해주셨고 나에게 주도해서 진행해달라고 위임해주셨다. KPT 형식으로 회고를 진행하였다. 첫 회고의 Try 결과인 action item으로 업무 워크숍을 진행하고 git branch, 전략 공유 등이 나왔었다. 그 후로 매월 1회 회고를 진행하면서 팀원들과 생각을 일치시키고 비전을 align하기 위해 노력을 하고 있다.
마무리하며…
기존 동료들이 어떻게 일하고 있었는지를 파악한 후, 신뢰를 기반으로 팀 문화에 적응하고 조금씩 개선해나가야 한다. 사람들과의 개발에 대한 방향성과 약속들을 정리해 나가면 좋다. 방법 중 하나로 오프라인 코드 리뷰가 있다.
마지막으로 회고라는 도구를 강력하게 사용하길 바란다. 동료들간의 공감되는 문제를 찾아내고 같이 해결해가는 게 중요하다. 개발, 개발 문화, 업무 방식 모두 주기적인 피드백을 바탕으로 개선해 나가는게 좋을 것 같다. 어느 조직에서든 나 혼자 잘해서 큰 성과를 만들어낼 수는 없다. 내 옆에 있는 동료들과 함께 해야 한다.
글 원문 출처 : https://blog.anyjava.net/127
