개발자에게 재택 근무가 필요한 이유

과거 서울 남부의 경기도에서 소프트웨어 개발자를 채용할 때였다. 서울에서 별로 멀리 떨어져 있지 않은 경기도에 있는 곳인데도 많은 지원자들이 거리상의 문제로 지원을 포기 했고, 특히 서울 북부에 사는 사람들은 인터뷰 시에도 출퇴근의 어려움에 대한 걱정을 토로했다. 

얼마 전 한 소프트웨어 회사는 서울에서 판교로 사옥을 이전했다. 그런데 서울 북부나 일산 등지에 사는 직원들을 주축으로 많은 개발자들이 회사 이전과 동시에 퇴사를 했다. 특히 몇몇 핵심 개발자들의 퇴사는 회사의 큰 손해가 아닐 수 없었다. 

아직도 우리나라 소프트웨어 회사의 근무형태는 농업사회에서 보여주는 전통적인 근면 성실을 강조하는 근무 시스템에서 크게 벗어나지 못하고 있다. 시간에 맞춰서 출퇴근을 하고 야근까지 하면서 상사에게 오랜 시간 열심히 땅을 파는 모습을 보여줘야 ‘열심히 일을 하고 있구나’ 하며 안심을 한다. 이런 현상을 보면 소프트웨어 개발이 지식 산업이 아닌 노동집약적 산업이라고 오해하고 있다는 생각이 든다. 

이렇게 시간 딱딱 맞춰서 사무실 자리에 앉아서 일을 해야 하는 시스템은 많은 한계를 가지고 있다. 대한민국이 아니라 미국이라면 어떨까? 거리의 제약은 수십배로 커진다. 많은 개발자들은 회사 근처로 이사를 하기도 하지만 재택 근무 형태로 일하는 개발자도 많다. 

재택 근무가 가능하면 회사에 꼭 필요한 개발자를 거리의 제약 없이 채용 할 수 있다. 같은 재택근무라도 상황에 따라서 근무 조건은 매우 다양하다. 일주일에 한번씩 출근을 하기도 하고 아예 원격으로 일하는 개발자들도 있다.

우리나라에서는 직장이 너무 멀어서 출퇴근에 2, 3시간씩 걸려도 아이들 학교 문제도 있고 직장을 옮길 때마다 이사를 하기는 쉽지가 않다. 그래서 개발자 채용에 거리 제약이 있고 회사에 꼭 필요한 개발자인데도 채용하기 어려운 경우도 많다. 

재택근무가 일반적이지 않은 이유는 옆에 앉아 같이 일하지 않으면 일이 제대로 진행되지도 않고 어떻게 일을 하고 있는지 알 수도 믿을 수도 없기 때문이다. 같이 모여서 일하지 않으면 일이 제대로 진행되지 않는다. 

필자는 여러 회사에서 강연이나 세미나를 할 때 종종 “여러분이 모두 회사에 나오지 않고 집에서 원격으로 일하면 어떻게 됩니까?”라는 질문을 한다. 100%의 회사들이 일이 전혀 제대로 진행되지 않을 것이라고 얘기를 한다. 개발자들은 허무맹랑한 질문이라는 표현을 하기도 한다. 이는 단지 재택근무가 가능한지 불가능한지 문제는 아니다. 

재택근무가 불가능한 회사는 문화적으로 프로세스적으로 개선할 점이 많은 회사다. 회사가 개발에 필요한 시스템을 잘 갖추고 있고 공유와 문서화가 잘 되어 있으면 재택근무는 그렇게 어려운 일이 아니다. 오히려 집에서 일하는 것이 더 효율적인 경우가 많다. 

재택근무가 불가능한 회사에서는 개발자들이 수시로 물어보고 의논을 하고 회의도 해야 한다고 한다. 이런 환경을 보면 회의가 너무 많고 공유와 문서화가 잘 안되어 있다는 것을 단적으로 알 수 있다. 문서나 시스템으로 대부분의 내용은 공유하고 대부분의 커뮤니케이션은 시스템을 통해서 해야 한다. 회의도 스카이프등을 이용해서 원격으로 할 수 있다. 

꼭 대면회의가 필요한 경우에 회사를 나오면 된다. 이런 환경이 갖춰지면 재택근무가 가능하다.

재택근무를 하면 개발자들이 열심히 일하는지 알 수 없어서 그렇게 할 수 없다는 회사 관계자도 만난 적이 있다. 하지만 회사에 있으면 열심히 일하는지 알 수 있는가? 시스템, 문화와 프로세스가 제대로 되어 있으면 개발 성과와 결과물이 시스템에 제대로 남고 동료 검토를 통해서 동료들이 서로 누가 어떻게 일하는지 다 알고 있다. 

옆에서 일하나 멀리서 일하나 다 알 수 있다. 하지만 그렇지 않으면 옆에서 일해도 커뮤니케이션이 어렵고 누가 열심히 일하고 누가 놀고 있는지 잘 알지 못하는 경우가 많다. 

지금 당장 이런 성숙된 문화와 효율적인 프로세스와 시스템을 갖추지 않고 재택근무를 추진한다면 어떻게 될까? 우려하고 있는 모든 문제가 드러날 것이다. 재택근무는 거리의 제약을 뛰어넘어 뛰어난 개발자를 채용할 수 있게도 할 뿐만 아니라 가정에 사정이 있는 개발자도 회사를 그만두지 않아도 된다. 

가정 사정상 아이를 돌보기 위해서 회사에 10시부터 3시까지 밖에 있지 못하는 뛰어난 개발자가 있다고 하자. 이렇게 일하는 것을 어떻게 허용할 것인가? 누구는 일주일에 이틀밖에 회사에 나올 수 없다고 하자. 이런 개발자가 회사에 꼭 필요한 사람이라면 채용해서 활용할 수 있을 것인가? 

재택근무는 그 자체로도 필요하고 회사의 문화나 프로세스의 성숙도를 가늠할 수 있는 지표로 볼 수도 있다. 필자는 회사에서는 야근을 별로 하지 않고 야간과 주말을 가리지 않고 회사의 시스템에 붙어서 이슈를 확인하고 의논을 하며 코드리뷰를 하는 등스스로 찾아서 일을 하는 것이 일상화 되어 있다. 가족이 나를 필요로 할 때 가족과 지낼 수 있으며 언제 어디서나 일할 준비가 되어 있고 일을 할 수 있다. 주말에도 굳이 회사에 나가지 않아도 원격으로 쉽게 일할 수 있다. 시간, 공간적인 제약은 별 문제가 되지 않는다. 

우리 회사는 개발자들의 재택근무가 가능하지 생각해보자. 현재는 어렵다는 생각이 든다면 그 이유가 회사에서 모여서 일할 때도 비슷한 문제를 가지고 있을 가능성이 높다. 어떻게 고쳐나가야 하는지 생각해보자. 재택근무가 가능한 시스템이 회사의 개발 문화 성숙도를 한층 높여줄 것이다.

이글은 ZDNet Korea에 기고한 글입니다.

SW업계에는 망치를 만드는 사람이 많다

누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서 쓰는 사람들이 매우 많다. 소프트웨어 업계에도 망치와 못을 전문적으로 만드는 회사가 꽤 많지만 우리나라에서는 장사가 잘 안 되는 것이 현실이다. 

이같은 상황은 흔히 NIH(Not Invented Here) 신드롬이라고 불리기도 한다. 우리나라의 경우 더 심한 경향을 보이고 있고 이유도 매우 다양하다. 기업간에 협업이 잘되어야 망치회사도 흥하고 망치를 사다 쓰는 회사도 직접 만들어 쓰는 것보다 훨씬 효과적으로 소프트웨어를 개발할 수 있다. 망치 회사가 흥해야 망치를 만드는데 필요한 툴을 만드는 회사도 흥해서 덩달아 여러 회사가 잘되게 된다. 그런데 왜 우리나라에서는 이렇게 기업간의 협업이 잘 안 되는 것일까?

나는 여러 소프트웨어 관계자를 만나는데 엔진, 라이브러리 류의 소프트웨어를 개발하는 회사들은 국내 시장의 특수성에 대해서 하소연을 한다. 자신들의 솔루션이 국내 소프트웨어 회사들에게는 별로 인기가 없고 해외에서는 찾는 사람이 많다고 한다. 국내에서는 특히 조심을 하는 것이 기업들은 가격을 후려치려고 하고 데모를 보여주면 그대로 흉내 내서 만들기도 한다는 것이다. 물론 엉터리로 흉내는 내는 것이지만 이런 식으로 국내에서는 별로 비전이 없다고 한다. 

기업들은 자신들의 전문 분야에 집중하고 전문 분야를 개발하는데 필요한 툴이나 시스템은 다른 기업과 협력을 하는 것이 좋은데 이런 협력이 잘 안 되는 이유를 한번 살펴보자. 

첫째, NIH(Not Invented Here)신드롬이다. 

자신들이 최고라고 생각하면서 자신들이 직접 개발하지 않은 것은 배척하는 현상이다. 이런 개발자들을 인터뷰해보면 자신들이 개발하는 것은 너무 어려워서 자신들, 자신의 회사에서 밖에 개발하지 못한다는 얘기를 한다. 이와 똑같은 현상이 여러 기업에서 벌어지고 있으므로 똑똑한 사람들은 여기 저기 많이 있으며 외부의 창의력과 좋은 아이디어도 받아들일 마음가짐이 되어야 한다. 

세계적인 3D 설계 소프트웨어를 개발하는 오토데스크(Autodesk) 사는 진작부터 3D그래픽엔진은 테크소프트3D(TechSoft3D)사 엔진을 사용하고 있다. 그래픽관련 부분은 전문업체에 맡기고 자신들은 설계 애플리케이션에 집중하기 위해서다. 

둘째, 근시안적으로 비용을 절약하려는 경우다. 

요즘은 오픈소스 소프트웨어가 넘쳐나서 외부의 도움을 받을 수 있는 라이브러리, 툴, 컴포넌트 등이 많지만 여전히 상용 소프트웨어의 도움이 필요한 분야도 많다. 때로는 오픈소스와 상용 소프트웨어 사이에서 저울질을 해야할 때도 있다. 라이선스 계약에 따라서 제품을 팔 때마다 몇 % 또는 얼마의 비용이 계속 발생하기 때문에 커다란 결정이 아닐 수 없다. 

상용 소프트웨어를 활용하면 라이선스 비용 외에는 커다란 추가 비용이 없이 본연의 개발에 집중할 수 있다. 하지만 라이브러리, 툴, 엔진류를 직접 개발하면 개발 비용이 꾸준히 들어가게 된다. 오픈소스를 이용할 경우에도 이를 학습하고 유지하기 위해서 상당한 비용이 들어간다. 소프트웨어는 아기처럼 한번 탄생하고 나면 먹여주고 재워주고 비용이 계속 들어간다. 

초기 개발 비용의 수십배, 수백배가 들기도 한다. 상용 소프트웨어를 구매하는 비용은 명확하게 비용으로 보이지만 직접 개발하는데 들어가는 비용은 초기 개발비용만 고려해서 우습게 보는 경향이 있다. 하지만 대부분의 경우 직접 개발하는데 드는 비용이 상용 소프트웨어를 사다 쓰는 비용보다 훨씬 많이 들어간다. 게다가 더 큰 문제는 회사에서 본연의 제품에 집중하지 못하고 망치 만들고 못 만드는데 노력이 분산 된다는 것이다. 심지어는 망치를 잘못 만들어서 집을 제대로 만들지 못하기도 한다. 

물론 무조건 상용 소프트웨어를 써야 한다는 것은 아니다. 직접 개발을 하거나 오픈소스를 활용하는 것이 좋은 경우도 아주 많다. 여기에 들어가는 비용을 절대로 사소하게 생각하면 안된다는 것이다. 상용 소프트웨어라 하더라도 협력하기에 따라서 표준 제시 가격보다 획기적인 라이선스 조건으로 계약을 하는 것은 아주 흔한 일이다. 서로 윈윈할 수 있는 조건만 잘 맞는다면 가격은 그렇게 큰 장애물이 아니다.

셋째, 우리는 다르다고 생각하는 것이다. 

개발에 필요한 기반시스템을 구축해야 하는데 회사의 프로세스가 다른 회사들과 달라서 사다 쓰지 못하고 직접 개발을 해야 한다고 주장하는 경우를 많이 보았다. 한 예가 이슈관리시스템이다. 버그추적시스템이라고도 한다. 자신들의 회사는 개발 프로세스가 일반적인 경우와 달라서 거기에 맞추느라고 직접 개발을 해서 쓴다고 한다. 

하지만 대부분의 경우 우물 안의 개구리 같은 생각이다. 예외적인 몇 가지 경우를 제외하고는 자신들의 프로세스 자체가 잘못되거나 비효율적인 경우다. 그런데 그런 프로세스가 옳고 이에 맞는 시스템이 없다고 착각을 하고 있는 것이다. 시중에는 Mantis, Redmine, Jira 등 좋은 이슈관리, 버그추적 시스템이 많이 있고 이런 툴을 제대로만 사용한다면 좋은 개발 문화도 덤으로 얻을 수 있다. 자신들의 프로세스가 이런 툴과 맞지 않는다면 툴을 직접 개발하기 보다는 프로세스를 툴에 맞추는 것이 나을 가능성이 훨씬 높다. 

넷째, 상용 소프트웨어에는 없는 기능이라서 직접 개발해야 한다고 주장하는 경우다. 

여러 상용 소프트웨어 또는 오픈 소스를 조사해봐도 99%는 만족하는데 1% 기능이 부족해서 사용하지 못하는 경우도 많다. 그런데 예상외로 상용 소프트웨어를 만드는 회사들은 추가 기능 개발 요청에 상당히 적극적인 경우가 많다. 그런데 그런 시도를 해보지도 않고 그냥 포기를 하고 직접 만든다고 하곤 한다. 

당장 오늘 내일 필요한 것이 아니고 기획단계에서부터 검토를 할 경우 수개월의 여유기간이 있고 이 기간 동안에 추가 기능을 개발할 회사는 얼마든지 찾을 수가 있다. 하지만 이렇게 계획적으로 개발을 하지 않고 당장 필요하다고 하면 외부 업체와 협력할 시간적인 여유는 없게 된다. 급하다고 직접 만들기도 하는데 이는 새로운 문제의 시작일 가능성이 높다. 

영어 또한 상당히 큰 장벽이다. 이런 것을 조사하고 추가 개발을 요청하고 협력 방안을 조율하려면 어설픈 영어 가지고는 부족하다. 영어도 잘하고 소프트웨어 업계가 어떻게 돌아가는지도 잘 알아야 하기 때문에 그냥 영어만 잘하는 사람 가지고도 안 된다. 그래서 영어 실력이 부족하다 보니 시도도 못해보거나 시도를 해보다가도 매끄럽게 협력이 잘 안되는 경우가 많다.

소프트웨어 회사들이 다양한 소프트웨어를 개발하고 서로 협력해서 서로 키워가는 것은 전체 소프트웨어 생태계의 성장에 중요한 역할을 한다. 그런데 빌딩을 만드는데 집중할 업체에서 망치를 만드는데 신경을 쓰고 망치 업체는 망하고 이런 일이 반복되면 소프트웨어 생태계는 점점 쪼그라들고 만다. 

개발자들도 문제다. 기술을 잘 모르는 경영자들은 이런 판단을 직접 할 수는 없다. 개발자들에게 망치를 만드는 것이 좋은가, 사다 쓰는 것이 좋은가 물어볼 때 위에 제시한 이유들을 들어서 직접 개발해야 한다는 주장을 하는 경우가 압도적으로 많다. 잘못된 판단으로 빌딩을 만드는 회사는 망해도 개발자에게는 망치를 만드는 기술이 남았다고 생각할지는 몰라도 망치 전문업체의 기술에 비하면 “새발의 피”에 불과한 기술일 뿐이다. 

각 기업에서 이런 잘못된 판단이 이루어지는 이유 중 하나는 CTO의 부재 때문이다. 이런 결정은 회사의 미래에 매우 중요한 결정이기 때문에 개발자 한 명의 의견을 들어서 결정하는 것도 위험하고 회사의 기술을 책임지는 CTO가 결정을 해야 한다. 

소프트웨어 개발은 개인간의 협업도 중요하지만 기업간의 협업도 매우 중요하다. 내 것이 최고라는 생각을 버리고 서로 협력을 할 때 전체 소프트웨어 생태계가 좀더 나아질 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

평등한 토론이 SW혁신 만든다

소프트웨어에서 창의적인 혁신은 천재 한 사람의 머리에서 나오는 것이 아니다. 여러 직원들의 격 없는 평등한 토론에서 탄생하는 것이다. 이런 토론 문화 없이 혁신적인 소프트웨어가 탄생하기는 어렵다. 이는 비단 소프트웨어만의 문제는 아니다. 

우리는 흔히 회의를 하면 침묵을 지키는 사람들이 많다. 좋은 아이디어를 얘기하면 “그래, 네가 꺼낸 아이디어니까 네가 책임지고 완료해봐”라고 시키기 일쑤다. 꺼낸 얘기에 대해서 상사에게 면박을 당하기도 하고 교장님 훈시처럼 얘기를 듣고 있어야 하기도 한다. 이런 일이 반복되다 보니 좋은 아이디어가 있어도 얘기를 안하고 점차 시키는 일만 하게 된다. 

옛말에 “가만히 있으면 중간이라도 간다”는 말이 있지만 회의 분위기를 이렇게 만드는 회사에서는 혁신과 발전을 기대하기는 어렵다. 상사의 문제도 있지만 우리나라에서는 어려서부터 토론 훈련이 안되어 있어서 회사에서도 토론이 어렵다. 나도 마찬가지로 그런 환경에서 자라왔다. 그런 토론 훈련 없이 직장에서 동료들과 토론을 하다 보면 권위의식을 내세워서 토론을 망치곤 한다. 

우리나라가 원래 이렇게 토론에 관심이 없었던 것은 아니다. 고대 그리스 때도 교육의 기본은 토론이었듯이 공자도 제자들과 열띤 토론을 했듯이 우리나라도 조선시대에는 토론이 중요한 교육의 중심이었다. 우리나라에 토론이 사라지고 “상명하복”만 남게 된 결정적인 이유가 전쟁과 군사정권을 거치며 군대식 문화가 교육에도 적용된 것이 아닌가 생각한다. 내가 고등학교를 다닐 때도 열심히 외워서 시험을 잘 보면 되지 논리적으로 얘기를 해서 누구를 설득할 필요가 없었다. 

지금이라도 마음먹고 평등하고 자유롭게 토론을 하면 된다고 생각하지만 그렇게 쉬운 일은 아니다. 훈련이 안되어 있으면 몸에 벤 습관이 툭 튀어나오게 되어 있다. 문화라는 것이 누구 하나 바뀐다고 해결되는 것이 아니라서 토론 문화도 마찬가지로 한사람이 아무리 평등하고 자유로운 토론을 하자고 부르짖어도 상사 한사람이 분위기를 망칠 수 있다. 평등한 토론을 하려면 모두가 바뀌어야 한다. 

좋은 토론 문화는 다음과 같은 것들이 있다. 

남의 얘기 경청하기, 논리적으로 설득하기, 적극적으로 참여하기, 주제에 집중하기, 좋은 남의 의견을 받아들이기, 창의적이고 자유롭게 얘기하기, 서열과 관계없이 어떠한 얘기라도 하기 등이다.

반대로 나쁜 토론 문화에는 다음과 같은 것들이 있다. 

권위 내세우기, 비 논리적으로 얘기하기, 과장해서 판단을 흐리기, 잘못된 정보를 얘기하기, 남의 얘기 끊고 끼어들기, 면박주기, 무조건 딴지 걸기, 침묵하기, 화내기, 우기기, 때쓰기, 남의 얘기를 전혀 받아들이지 않기, 인식공격하기, 비방하기, 주제에서 벗어난 딴 얘기 하기, 떠넘기기다.

나쁜 토론 문화는 나도 수많은 회의에서 실제로 경험한 것들을 적은 것이며 이런 곳에서는 교장선생님 훈시 수준을 못넘는 회의를 하며 혁신은 꿈도 꾸지 못하는 회사 분위기를 만든다. 

사장과 말단 개발자가 격이 없이 자유롭게 토론하고 그 속에서 혁신이 튀어 나오는 외국 소프트웨어 회사를 어떻게 따라 할 수 있을까? 어려서부터 토론을 훈련 받은 그들을 어떻게 따라 할 수 있을까? 서열과 권위의식이 별로 없는 환경에서 평등하게 하는 토론을 어떻게 따라 할 수 있을까? 

뾰족한 수는 없고 권위의식을 버리고 서열문화를 버리고 평등한 토론을 훈련하는 수 밖에 없다고 생각한다. 이런 평등한 토론 문화를 위해서 모든 직원의 직급을 없애고 영어 이름을 부르는 회사가 있다. 사장이 스스로 나서서 권위의식을 없애고 평등한 토론문화를 만들어 가는 회사도 있다. 이런 회사의 토론 분위기는 사뭇 다르다. 반말하는 사람 없이 서로 존칭을 하며 직급 없이 이름을 부른다. 일단 외형적으로 평등한 분위기를 조성하며 내용적으로도 자유로운 토론이 이어지며 좋은 토론 문화를 만들어나가기 위해서 노력한다. 나쁜 토론 문화는 보이는대로 제거하기 위해서 애쓴다. 

이는 평등한 토론 문화가 중요하다는 회사의 경영자들의 생각과 의지에서 비롯된다. 소프트웨어 회사는 혁신 없이는 도태된다. 모든 직원들의 창의력을 밑바닥에서부터 끌어낼 때 혁신이 나올 수 있다. 토론 문화는 상명하복이 완전히 고착된 우리나라 큰 기업들이 외국의 소프트웨어 회사들을 이기기 어려운 결정적인 이유 중 하나다. 반짝 이길 수는 있어도 직원들이 불행하게 일하면 지속적으로 이기기는 어렵다. 직원들이 행복하게 일하면서도 혁신과 성장을 하려면 평등한 토론 문화가 꼭 필요하다. 

이글은 ZDNet Korea에 기고한 칼럼입니다.