워라밸('Work-life balance)의 해석
일과 삶의 균형이라는 것에 대해서 무게감은 어느 쪽에?
1970년대에 등장한 이 개념에 대해서 우리는 어떤 식으로 받아들이고, 어떤 식으로 해석하고 있는 것일까?
단편적으로 2000년대 들어오기 이전의 한국사회는 연봉과는 상관없이 높은 업무 강도를 자랑했다.
필자 역시, 월요일 출근해서 토요일 퇴근하는 경험을 하지 않은 것이 아니다.
결론적으로 이야기한다면, 극도로 '일'에 몰두하던 사회에서 '워라밸'이란 의미는 매우 배부르고, 너무 이상적인 이야기라고 폄훼할 수 있다.
하지만, 개개인의 능력과 업무 집중도가 중요해진 현재의 작업환경은
극도로 노동시간이 중요하던 때와 비교해서 다른 개념으로 생각해야 한다.
업무의 집중도와 생산성을 높이려면 당연하게 해야 할 것들을 하지 않는 것이 문제이고, 워라밸은 정확한 의미로 해석이 될 필요가 있다.
워라밸을 위한 행동과 체크리스트는 다음과 같이 나열할 수 있다.
정시퇴근,
퇴근 후에 업무 연락하지 않기,
업무 집중도를 위한 시간 보장,
불필요한 회의는 하지 않고 생산성 높은 회의를 하는 것,
뜬구름 잡는 모호한 업무지시가 아니라 구체적인 지시하기,
일하는 사람이 꼭 자리에 앉지 않더라도 일할 수 있는 것과 재택근무와 같은 유연성,
문서 중심의 보고가 아닌 의미 전달이 가능한 간단한 보고,
술만 마시는 회식이 아니라 커뮤니케이션을 위한 회식 문화,
휴가와 연차에 대한 자유로움,
경영진이나 관리자들의 구체적인 실현 등이
현재 워라밸이 추구하고 있는 개념이라고 정리가 된다.
다만, 가장 논란이 되는 '정시퇴근'에 대해서는 아직도 잘못된 콘셉트로 이해하지 못하는 사람들이 많다.
특히, '야근'을 많이 하는 '직원'이 과연 '좋은 직원'인가 하는 평가에 대해서는 다음과 같이 풀어서 설명하겠다. 다른 분야 보다는 필자의 영역인 '소프트웨어 개발자'들을 기준으로 설명하도록 하겠다.
스타트업이나 소프트웨어 개발 업무의 '특성'상 야근이나 주말근무는 사실상 너무도 당연한 것이기는 하다. 하지만, 이 '야근'이나 '연장 근무'의 개념은 기존의 업무환경에서의 상황과 다르다는 것을 먼저 인지해야 한다.
첫째. 소프트웨어 개발의 경우 서비스는 24x7의 연속성 높은 업무이다.
24시간 7일 동안 휴일에 상관없이 서비스는 동작해야 한다. 버그이던, 네트워크 장애이든, 클라우드나 DNS동작 버그이든, 사용하고 있는 네이버나 구글의 지도 서비스의 변동사항이던 서비스를 무제한 적으로 모니터링을 해야 하는 소프트웨어 개발팀은 이미, 사실상 야근이나 연장근무를 너무 당연하게 하고 있다.
편하게 휴가나 명절 때라고 하더라도, 해당 서비스를 구동하기 위한 준비나 작업, 모니터링의 업무는 끊임없이 연장되어 있다. 특히나, 신규 서비스가 노출되는 경우의 스트레는 일반인들이 생각하는 생각 이상이다.
둘째. 소프트웨어 개발자는 필요한 야근은 알아서 수행한다.
특정 시점, 다른 개발자와의 약속, 타 부서의 요청 등을 완수하고, 지키기 위해서 최대한 자신의 업무를 효율적으로 배치하려고 하고, 이를 지키기 위해서 최대한 자신의 일정을 쪼개고, 배치한다.
다만, 말도 안 되는 기간 설정, 무책임하게 바뀌는 기획이나 환경, 통제 안 되는 상황에서의 야근 강요에 대해서는 대부분 부정적으로 생각한다.
셋째. 야근을 지금 몇 주 한다고, 서비스가 안정화되거나 드라마틱한 성과가 나오지 않는다는 것을 개발자들은 알고 있다.
사실, 가장 중요한 요소가 이 부분이다. 비개발자나 개발을 잘 모르는 경영진의 입장에서는 한두 주, 한 달/두 달만 고생하면 엄청난 보너스나 멋진 결과물들이 드라마틱하게 펼쳐질 것 같은 최대한의 희망적인 목표나 환경에 대해서 예측하지만, 개발자들은 그런 관점을 가장 두려워한다.
어떤 시스템이나 서비스들은 어떻게 고민하고 설계하고, 개발되어도 문제는 분명하게 나타나고, 해당 문제를 해소하기 위해서 또 다른 시간이 소요된다는 것을 알고 있다.
지금 당장 불타올라봐야, 드라마틱한 결과물이 나오지 않을 것이 불을 보듯 뻔한데, 개발자들에게 야근을 이야기하는 행위는 자해행위에 가깝다.
넷째. 동기부여가 명확하면 개발자는 야근을 하고, 주말근무를 해서라도 문제를 해결하려 할 것이다.
구체적인 목표, 완벽에 가까운 기획, 누가 봐도 의미 있을 듯한 사용자 반응이 예상되는 사용성의 드라마틱한 가능성, 손발이 맞는 동료 개발자와 관련 부서의 협업이 구체적으로 동작한다면, 개발자는 알아서 일한다.
슬프지만, 이런 '동기부여'가 가능한 부서나 회사를 만드는 것은 매우 어렵다.
비즈니스 모델이 혁신적이고, 완벽에 가까운 기획서를 만든다는 것 자체가 쉽지 않기 때문이다.
다섯째. 사실, 어쩔 수 없이 개발자가 야근하고 있다면... 그것은 대부분 뒷수습의 경우에 해당된다.
쓸데없는 회의가 길어지고, 기획서가 뒤죽박죽이고, 낮시간에 기획 요소들을 점검하느라고 시간을 대부분 소모했다면, 개발자들은 한숨을 쉬면서 개발 시간을 확보하기 위해서 어쩔 수 없이, 야근을 하고 있을 것이다.
다만, 이렇게 야근하는 개발자들 모두가... 다른 회사나, 더 좋은 동료들이 있는 곳에 대한 깊이 있는 생각이 더 많아진다.
여섯째. 기획이 부정확하면, 개발자들의 노력은 2배 이상, 개발 속도도 2배 이상 느려지고, 품질도 엉망이 된다.
개발자들은 머릿속이 논리 정연하게 구성되어야 안심하면서 코드를 나열한다. 하지만, 개발 진행 시에 논리가 부정확해지거나, 부정적인 결과물이 예상되는 경우가 예측되면 코드를 더 진행하지 못하고, 해당 코드를 재정립하려고 애를 쓴다.
그러다가, 개발자 스스로 해결이 안 되면, 팀 동료와 확인하다가, 그래도 확인이 안 되면, 기획자에게 관련 기획을 문의하고 논의하고, 조정하려고 한다.
더 슬픈 것은 그런 의문점에 대한 질문에 대해서 기획자가 또 다른 방향으로 기획을 틀어가면서 부정확한 서비스에 대해서 이야기를 하게 되면, 심한 경우에는 현재 만들고 있는 개발 코드에 대해서 개발자 스스로 신뢰를 하지 못하게 된다.
결국, 레거시의 대부분은 개발자들이 만드는 내용들도 있지만, ( 대부분 숙련된 개발자들은 본인 스스로 이런 문제를 일으키지 않는다. 숙련된 개발자를 전제조건으로 하고 있다는 것을 잊지 말자. ). 대부분의 이런 상황은 경영진이거나 기획자들이 자초한 행위들의 결과물이 된다.
자포자기가 되거나 비개발자들의 비논리적인 상황에서 만들어진 코드는 '동작'하는 것처럼 보이지만, 실제 동작중에 조금만 틀어지거나, 비정상적인 이슈가 발생되면 전체 서비스에 영향으로 주거나, 앞으로 꼼짝할 수 없는 상황으로 서비스가 망가진다.
.
.
.
그렇다. '의미 있는 야근과 주말근무'를 하는 개발자나 작업자들에게는 해당되지 않겠지만, 대부분의 개발자와 작업자들은 '쓸데없는 야근'을 더 많이 한다.
심지어, 제대로 야근 업무를 하면서 업무를 맞추기 위해서 애를 쓰는 개발자들의 업무 의욕을 꺾는 비개발 조직들도 있다. ( 자기들끼리 놀거나, 게임을 하거나, 술을 마시면서 야근 업무 분위기를 해치는 경우도 비일비재하다. )
.
.
.
소프트웨어 개발자들의 워라밸에 대해서 다시 한번 정리한다.
1. 우리는 보다 명쾌한 비즈니스 목표와 구체적인 기획서가 있다면, 어떻게든 개발 기간을 단축하려고 애를 쓴다.
2. 한번 진행에 들어간 기획과 개발 내용에 대해서 짧게 개발하는 스프린트나 애자일 선언과 같은 내용을 제발 숙지해주기 바란다.
3. 회사에서 쓸데없이 야근을 하는 사람을 막아주었으면 좋겠다.
4. 능력이 부족한 동료들도 많다. 능력이 부족한 비개발자에 대한 인사조정이 없다면, 이 역시 개발자들을 절망에 빠트린다. 그들의 삶과 이상도 중요하지만, 개발자들의 삶과 이상에 대해서 존중해주기 바란다.
마지막으로...
소프트웨어 개발자들은...
삶과 일에 대한 경계선이 모호합니다.
그들이
최대한 일하게 해 주세요.
그리고,
그들이 일하는 순간은
그 업무와 그 일에 대해서 고민하기 시작하면서부터입니다.
