나와 마찰을 종종 빚었던 동료가 결국 회사를 떠나는 걸로 결론이 났다. 마지막에는 아키텍쳐 스택에 따라 분리하고 각자의 일을 하는 걸로 정했지만, 효과는 없었나 보다.

업무 분리를 조금 더 빨리 시도해봤어야 했는데, 늦은 감이 없잖아 있었다. 한편으로 그렇게 분리해서 적응이 된다고 한들, 문제의 근본은 해결되는 것이 아니기에 임시방편일 수 밖에 없었겠지만 하는 생각도 있다.

어차피 사람이야 나고 들 수 밖에 없는 것이다. 그렇다면 조직으로서 우리는 어떤 교훈을 얻을 수 있을까?

첫째는, 인터뷰 프로세스에 대한 것이다. 최소한 개발에 대한 철학은 검증해 볼 수 있어야 한다. 그러기 위해서 먼저 지금 있는 사람들끼리 생각을 확립해야 한다. 우리가 어떤 식으로 일하는 지 결정 되어야, 어떤 인재를 원하는지 알 수 있기 때문이다.

둘째는 멘토링에 대한 것이다. 팀 내 다이내믹스가 오작동을 하고 있을 때, 팀 외부에서 이를 도와줄 모멘텀을 만드는 것도 방법일 수 있다. 신규 입사자가 적응하는 데 도움이 되는 것은 물론이다.

셋째는 회의실을 분리해야 한다. 현재는 사정상 업무 공간과 회의 공간이 뒤섞여 있는데, 이를 분리하는 것이 중요하다. 삼투압 커뮤니케이션은 일반적인 업무 공간에서 일어나는 것이 맞다. 그러나 회의는 참가자들의 대화가 격리되어야 한다. 일종의 블랙박스처럼 회의실 들어갈 때와 나왔을 때의 차이, 즉 결과만 알면 되는 것이다.

세번째 아이디어는 이사를 해야하는 것이니, 내가 취할 액션이 없어 보이고, 두번째는 일단 건의를 했다. 문제는 첫번째 인데, 일단 인터뷰 프로세스에 회사 사람들을 참가시키는것보다 급한 일은 기존 멤버들의 개발 철학 확립이다.

그러기 위해서 회사 사람들과 코딩과 개발에 대한 이야기를 하는 기회가 많아져야 하는 것이 중요할 것 같고, 코딩 도장 처럼 같이 공부를 해보는 것도 의미가 있을 듯 하다.

하지만 당분간은 나도 좀 웅크리고, 코딩에 전념하기로 했으니, 세미나 같은 것들보다 우선 토이프로젝트를 하나 시작하고, 사람들에게 소개해서 관심 있는 사람들과 같이 작업해보는 연습장으로 써보는 것이 좋을 것 같다.