일을 위한 일
결국 엔지니어들은 '일을 위한 일'에서 스트레스를 받는다는 거고, 이건 조직과 구조의 비효율적인 프로세스에서 기인하는 게 큰 것 같다.
엔지니어들은 '엔지니어링'이 하고 싶은거지, 시시콜콜한 문서를 만들고 싶어 하지 않는거지. 기술 문서라면 그나마 낫고, '시시콜콜한 문서'는 결국 조직의 '변덕'으로 인해 이러한-혹은 해설해주어야 하는 문서를 작성하는 일이 빈번하게 일어나는 것.’
핫픽스 문서는 어디에 기록해야 하는가? 사내 위키인가? 제품 릴리즈? 코드 주석? 셋 다 기록할 거라면, 그것에 대한 '버전 관리'는 어떻게 할 것인가? 조직 차원에서 Single Source of Truth를 어떻게 준수할 것인가?
당장 내가 겪은 환경만 해도 일을 위한 일과 그런 기록과 소통을 위한 채널이 꽤 많다. 의존성은 줄일수록 좋고, 간단할 수록 좋다. 내가 볼 때는 어떤 도구던 효율의 차이일 뿐, 기능하지 못하는 건 없다. 이렇게 멀티 채널이 되는 게 문제다.
애매함이나 잠재적 문제를 치워버리기 위해서 참고 작업을 수행하는데, 조직과 제품의 변덕으로 인해 결국 애매함과 잠재적인 문제가 해결되지 않는다면 엔지니어들은 힘이 빠질 수 밖에 없다.
정리를 위한 정리는 필요하지 않고, 어떤 사안에 대해 딱 정하고 가는 것은 트레이드 오프를 동반한다. 미래는 예측할 수 없기에. 다만 히스토리를 남겨놓는다면 이후에 시프트하는 것은 비용이 들지만 이해할 수 있는 결정이 되고, 구성원들의 포커스를 다시 한 곳으로 몰게 하는 것도 어렵지 않다. 그것은 곧 조직의 케이스 스터디가 되고, 조직 차원의 자산이 된다. 개인의 차원에서도 커리어를 설명하기 좋다.
정하고 가는 것은 트레이드 오프를 동반한다. 미래는 예측할 수 없기에. 다만 히스토리를 남겨놓는다면 이후에 시프트하는 것은 비용이 들지만 이해할 수 있는 결정이 되고, 구성원들의 포커스를 다시 한 곳으로 몰게 하는 것도 어렵지 않다.
엔지니어의 채용에서는 비즈니스/제품에 대한 케이스 스터디를 논하고자 하고, 이것은 트레이드 오프를 충분한 기술적 깊이를 동반한 채 검증하고 선택했나를 질의하고 싶은 것이지, 특정 기술에 대한 테스트를 보고 싶은 게 아니다.