워라밸은 퇴근시간의 문제가 아니다.

17 Jul 2019 » Story

몇달 전에 페이스북에서 한참 ‘워라밸’에 관한 주제가 오갔던 적이 있다.
이 주제를 가지고 얘기하려 하는데, 늘 하던 방식대로 이게 대체 무슨 의미인지부터..

이 글을 쓰려 했던 이유는 사실 ‘직업과 개인이 어떻게 분리돼?’ 와 같은 반응들이 당시에 꽤 보였기 때문이다.
그것도 나보다 윗 세대의 분들이 그렇게 얘기하는걸 보고 분노한 것도 있다.

라떼
라떼는 말야….

Work and Life Balance

먼저 다음백과를 보면 주로 ‘일상을 즐기고’, ‘저녁이 있는 삶’과 같은 얘기를 하고 있다.
마찬가지로 위키피디아에서도 ‘개인, 직업, 가정 생활에 대한 요구가 동등한 평형상태’ 로 이 설명을 시작한다.

이런 내용만 가지고 간단하게 정리해보면 결국 ‘직업’과 ‘개인’ 사이의 균형이다.

균형을 잡기 위해서는 구분해야 한다.

직업을 가진 나와 개인으로써의 나는 같은 사람이기 때문에 분리할 수는 없다. 하지만 분리될 수는 없지만 ‘회사의 일’과 ‘내 일’을 구분해야 한다. 그것을 구분할 수 있어야 균형을 잡을 수 있기에.. 그리고 우리는 이것을 역할 이라고 부르고 워라밸의 문제란 결국 이 역할간 균형의 문제이다.

문제는 이 역할 차이를 인지하지 못하고 단순히 퇴근시간을 기준으로 워라밸을 논하는 경우인데, 이런 경우 회사에서 자기만족을 성취하는 것을 스스로 자랑스럽게 생각하는 경우도 꽤 보인다. 이 역할의 구분점은 ‘왜’ 혹은 ‘무엇을 위해’ 하는 행위인가 하는 질문이다. 개발 자체를 즐기면서 직업으로도 가지고 있는 사람들은 ‘조직의 개발자로써의 나’와 ‘개인 개발자로써의 나’의 역할 자체가 모호할 수 있는데 아래와 같은 경우가 이러한 예시이다.


  • 자신의 개발조직에서 어떠한 목표가 있고,
  • 그 목표를 해결하기 위해 평소에 자신이 관심을 가지고 있는 기술이 해결책이 되리라 생각해서 제안을 하고
  • 그 조직이 그 부분에 박수치거나 공감을 해서 도입을 하게 되는 경우

  • 자신의 개발조직에서 어떠한 목표가 있고,
  • 그 목표를 해결하기 위해서는 다른 여러가지 선택이 있지만, 자신의 기술적 관심에 의해 특정 기술을 강력하게 주장한 경우1

앞의 경우는 그 조직이 필요한 부분에 대해 자신이 평소에 관심을 가지고 있던 기술을 통해 해결책을 제시한 경우이다.
뒤의 경우는 개인의 관심을 위한 행동인데, 이런 사람들은 워라밸을 위해 칼퇴근을 얘기하면 안된다. 회사에서 돈을 받고 일하는 시간을 자기 만족을 위해 사용한 경우다.

이 두가지가 크게 다르지 않아 보일 수 있지만 전자는 ‘개발’을 위해 ‘기술’을 수단으로 사용했다면, 후자는 ‘기술’을 위해 ‘개발’을 수단으로 사용했다.2 조직의 해결을 위해 제안한 것처럼 포장했지만, 사실은 자신의 기술적 욕심이 과도하게 반영되지 않았는지는 그 개발자 스스로만이 가장 정확하게 알 수 있다.

회사에서 어떤 기술을 사용하다가 관심이 생겨 개인적으로 더 깊게 연구해 볼수도 있고,(일 -> 개인)
혹은 개인으로써 관심을 갖고 연구하던 기술이 필요에 의해 사용하게 될 수도 있다.(개인 -> 일)
이처럼 개인과 직업이 완전히 별개의 것일수는 없지만

  • 기능(역할)에 따라 모듈(생활)을 구분하고
  • 각 모듈이 낮은 의존성 아래에서 상호 연동되어 돌아간다

지금 ‘느슨한 결합(loose coupling)’에 대해 얘기하는 중이다.

이 구분은 프로페셔널과 아마추어3의 구분인데, 지금 세대에는 프로페셔널 개발자의 영역에서 ‘개인’의 영역은 없다. 우리는 협업을 통해 팀으로 일하기 때문에 이 구분이 더더욱 중요하다. 형상관리시스템 등을 통해 통합된 소스 코드에는 ‘내가 작성한 코드’는 있을지언정, ‘내 코드’는 없다.

만약 회사에 ‘프로’ 개발자가 있다면, 그냥 냅둬라

작게는 팀이건 혹은 회사건 조직에서 필요한 것은 딱 두가지다.

  • 이 사람의 역할은 무엇인가? 선발투수? 불펜투수? 계정관리 프론트엔드 개발자? 결제 정보 데이터 분석가?
  • 이 사람이 우리 역할을 얼마만큼 하고 있는지 어떻게 올바르게 평가할 수 있을 것인가.

프로라면 주어진 역할을 충분히 하면 된다. 개개인의 ‘루틴’은 조직보다도 그 스스로가 더 잘 아는 ‘자신이 일을 가장 잘하기 위한’ 방식이다.

개인 루틴의 중요성
불펜투구 따위 안하면 뭐 어때?

조직에서 신경써야 할 것은, 그 사람의 역할이 무엇인지를 명확히 제시하고 잘못된 평가를 통해 좋은 ‘프로’를 놓치지 않도록 노력하는 것이다. 이러한 역할과 평가에 대한 기준이야말로 노동 생산성과 같은 단어를 입에 담을 최소한의 자격이다.

워라밸과는 다른 이런 얘기를 꺼내는 이유는 단순하다. 워라밸이 무너지는 회사의 특성은 이런 기준조차 없이 아직도 모던 타임스의 배경 속에서 살고 있다.
하지만 소프트웨어 개발은 대량 생산에 집중하지 않아도 되기 때문에 다시 ‘잘 만드는’ 것에 집중하게 된다. 산업 혁명 이전의 장인정신과 같은 개념이 시간을 거슬러 다시 등장하는 이유는 제조업 기반의 시스템으로 소프트웨어 개발을 이해할 수 없기 때문이다.
이것을 모르는 굴뚝기업4은 ‘개발자 + 시간 = 생산성’의 공식에 매몰될 수 밖에 없다.

반대로 전문적인 개발조직이라면 프로 개발자에게는 적극적으로 워라밸을 강요해야 한다.
이미 자신이 일을 잘하기 위한 루틴을 익힌 사람들은 스스로 알아서 잘 하기는 하지만, 개발자들의 Geek스러움이 종종 스스로 폭주하게 하기도 한다.

사실 이런 면에서 대한민국에서도 IT 기업에서는 자율출퇴근제나 책임근무제와 같은 방식이 자리잡고 있다.
물론 이런 회사들의 또다른 공통점은 좋은 개발자를 잡기 위해 수단방법 안가리고 달려 든다는 점이기도 하고…


  1. 이런 부분을 개발자의 자유라고 착각하는 경우가 있는데, 자유는 타인의 자유를 침해하거나 타인에게 강요하지 않아야 한다.(존 스튜어트 밀(John Stuart Mill)의 <자유론>에 나오는 얘기이다. 이 선을 넘는 것을 '방종'이라 한다.) 특히 협업이 중심이 되는 현대의 개발조직에서 타인에게 불필요한 학습곡선을 강요하는 것을 자유로 포장하면 안된다. 물론 건강한 개발조직이라면 합리적인 의사소통을 통해 필요한 부분에 대해서는 적극적으로 수용하는 한편 불필요한 복잡성을 낮추기 위해 노력한다. 

  2. 본말전도. 이보다 더 정확한 표현이 있을까. 물론 연구소 같은 곳에서는 기술 자체를 수단으로 삼기도 하지만 개발조직에서는 기술은 개발을 위한 수단으로 사용된다. 

  3. 실력이 없다는 의미로써의 아마추어가 아니라 돈을 받느냐 받지 않느냐의 의미적인 구분이다. 

  4. 오랫만에 안영회 선배님의 글 제목을 인용해 보았다. 


Tags : philosophy