“소프트웨어회사에서 재택근무를
할 수가 있는가?” 라는 필요조건에는 다양한 문제가 있다. 먼저 간단히
소개 정도만 할 주제는 보안이다. 보안이라고 하면 한 회사에서 습득한 지식, 설계문서, 소스코드 등 지적재산을 다른 회사에서 사용할 수 있는가에 대한 도덕적 혹은 법적인 주제이다.
구글의 전 개발자였던 Levandowski 가 구글의 비밀을 우버에 가져가 자율자동차에 기여를 한
것에 대한 구글의 소송에서 일주전인 3월4일에 최종판결이 났는데 Levandowski는 구글에게 2000억원, 우버는 구글에게
3000억원을 배상하게 되었다. Levandowski는 개인파산을 신청했지만 아직
형사소송은 진행 중인데 10년 형을 받을 것으로 예상하고 있다. 이런
경우를 보면 미국이 얼마나 파렴치범에 대해 준엄한 법의 심판이 있는지를 알 수 있다.
실리콘밸리에 있는 필자의 옛 동료나 주위에
있는 사람들이 지금도 재택근무를 할 때 소스코드를 비롯해서 많은 회사 정보가 개인에게 노출된다. 하지만 Levandowski 케이스와
같은 강력한 처벌이 있다는 것을 너무 잘 알고 있기 때문에 전 인생을 걸고 도박을 할 것이 아니라면 그런 생각은 할 수가 없다. 분위기가 그렇기 때문에 회사도 극히 조심하고 그런 직원은 미리 해고시키기 때문에 몰래 범죄를 저지르기도 어렵다. 국내 회사들의 경우는 Virtual Desktop 같은 방법을 이용하여 재택근무는 커녕,
회사 안에서도 정보유출을 막기 위한 많은 방법을 사용하지만 불편하기도 하고 비용도 들고 결국 생산성을 낮추는 큰 원인이다.
이런 지적재산권에 대한 범죄 행위를 법과
사회와 회사와 개인이 얼마나 심각하게 받아들이는가 하는 문제인데 이는 도덕성과 법에 관한 문제이니 여기까지만 얘기하고 진짜 중요한 문제는 다음에
있다.
글로벌 회사에 관련된 필자의 강연에서 꼭
빠지지 않는 주제가 있다. 소프트웨어 회사는 “전화, 메신저, 대면 미팅, 이메일대화”의 4가지가 없는 상태에서도 업무를 진행할
수 있어야 한다는 것이다. 이 4가지는 있으면 편리하지만 이것이 없을
때 업무를 진행하기 어렵다면 원천적으로 큰 Risk를 가지고 있는 것이다. 바로 “옹기종기 개발문화”이다. 있으면 편리한 도구이긴 하지만 없으면 안 되는 필수적인 도구로 변화되어 버린 옹기종기 개발문화인 것이다. 항상 옆에 사람이 있어야 하고 즉각적으로 접근이 가능한 상태의 환경에 중독되어 있는 것이다.
재택근무를 꼭 할 수 밖에 없는 환경이 자주
오지는 않겠지만 코로나 바이러스 사태가 그럴 수도 있다는 것을 보여준다. 미국과 같이 거리의 개념이 한국의 몇 배 정도 되는 곳에서는 꼭 모여서 업무를 해야 한다는 강제성을 부여하기가 어렵다.
그런 식으로는 직원 채용하기도 어렵다. 더 나아가 인도, 베트남, 브라질, 러시아 등을 비롯한 많은 외국의 인력들과
개발을 같이 해야 하는데 시공간의 차이 때문이라도 전화, 메신저, 대면미팅,
이메일대화는 어렵다. 필자가 근무했던 모든 글로벌회사에서도 출근은 하지만 며칠씩
아무하고도 업무에 대한 얘기는 하지 않은 적도 많다. 시공간의 문제는 아닌 것이다. 옆에 두고 옹기종기 개발하는 문화가 아닌 것이다.
이 4개의 공통점은 모두 사적인 대화이다. 어떤 주제에 대한 대화가 시작될 때부터 모든 사람에게 투명하게 공개되지 않는 사적인 공간에서의 대화이다. 소수의 사람들이 의논해서 결과를 도출하고 그 결과를 모두 공개한다고 해서 투명한 것은 절대 아니다. 결과는 회사에서 어차피 공개되게 되지만 중간에 벌어진 과정이나 배경 등은 다른 사람들이 알 길이 없고 좋은 의견을 제시할 기회 자체가
없다.
이 4개의 사적 대화방식에 대한 의존도가 얼마나 큰 정도가 소프트웨어회사의 수준이
아마추어인지 프로인지를 구별하는 가장 명확한 잣대이다. 이런 근본 이유는 소프트웨어는 지식산업이기 때문이다.
반면에 관리자와 같이 Daily Operation을 해야 하는 사람들은 재택근무가
어렵다.
그런 면에서 스크럼 애자일과 같은 옹기종기
개발방식이 얼마나 제한된 조건에서만 사용 가능한 지를 추측할 수 있다. 버클리대학의 전산학 교수가 소프트웨어공학 강의에서 한 말이 자기는 개발을 시작할 때면 항상 이메일과 휴대폰을 꺼놓는다고 한다.
그럼 소프트웨어 개발자로 범위를 좁혀서 생각해
보자. 이 4개가
없이는 개발 활동이 불가능한 것으로 보이는데 반대로
개발이 가능하려면 무엇이 필요할까? 다음 3가지가 필요하다.
“소스코드관리시스템, 이슈관리 시스템, 정확한
Specification” 이 절대적으로 필요하다. 필자가 3개를 나열한 순서에 중요한 의미가 숨어 있다. 이 3개의 공통점은 모두 투명한 협업의 방법이다. 소스코드, 이슈 진행 상황, 해야 할 업무에 대한 투명한 정보를 모두에게 실시간으로 제공한다.
먼저 소스코드관리시스템을 보자. 국내에서 약 10년 전만 해도 소스코드관리시스템이
왜 필요한지를 이해하는 개발자들이 많지 않았다. 자기 나름대로 소스코드 버전 관리를 하는
Know-how가 있다고 주장하는 것을 많이 봤지만 그들의 사고방식을 깨뜨리기는 어려웠다. 경험하지 않은 사람에게 그 가치를 설명하는 것은 원천적으로 불가능하기 때문이다. 하지만 세월이
흘러서 자연 진화라도 하다 보니 지금은 거의 모든 개발자가 소스코드관리시스템이 없이는 개발이 불가능하다는 것을 깨달은 시기가 되었다.
Git를 사용하는 것이 무슨 대단한
역량으로 생각되던 웃기는 상황이 지금은 자랑거리도 안 되는 너무나 당연한 것으로 되었다. 소프트웨어의 역사와 같이 해온 소스관리시스템의 개념만 알면 모든 소스코드관리시스템은 다 유사한 제품에 불과하다. 구글에서는 자체 제품을 사용한다. 국내에서 소스코드관리시스템에 대한 인식수준과 실리콘밸리에서
30년 전에 필자가 있었던 환경과 비교하면 적어도 30년 이상의 갭이 존재한다.
두번째로 이슈관리시스템을 보자. 국내에서 아직 왜 이슈관리시스템이 절대적으로 필요한지를 이해하는 회사는
많지 않다. 약 10년 전의 소스코드관리시스템의 상황과 비슷하다.
나름대로 이슈관리시스템이 없이도 개인의 극히 제한된 Know-how 방식으로도 업무가
가능하다고 생각하는 경우가 많다. 이런 사고방식에서 깨어나는 것이 일단 도전적인 과제이다. 역시 경험해보지 못한 상태에서 깨달아야 하는 어려움이 있다.
통상적인 회사에서는 수 많은 회의로 시간을
보내면서 그렇게 하는 것이 열심히 일하는 것으로 인정 받을 수 있을 지 모르지만 효율성이 지극히 낮은 어수선한 방법이다. 다행히 어떤 선각자가 통찰력이 있어서 이미 이슈관리시스템을 도입해서 사용하고
있다고 해도 사적 대화방식을 대체할 만큼 효율적으로 사용하기는 어렵다. 골프채를 샀다고 골프를 잘 치는 것은
아닌 것과 같다. 사용하기 시작한 다음부터도 Know-How가 축적되기
위해서는 많은 경험과 지혜가 필요하다. 많은 경우에 원숭이가 표면적으로 인간 흉내 내듯이 하다 보면 배가 산으로 가기도
한다.
하여튼 Jira라고 하는 이슈관리시스템을 성공적으로 개발한 호주의
Atlassian이란 회사는 호주의 Microsoft라 불릴 정도로 세계적으로도
가장 성공한 회사가 되었다. 필자의 경험으로 봐도 기존의 수 많은 이슈관리시스템보다 잘 만든 것은 사실이다.
지금은 무조건 Jira를 사용하라고 추천한다. 국내 소프트웨어 산업계에서의 유행은 대부분은 소수에만 적용되는 위험하고 낭비적인 유행이었는데 Jira는
잘못된 선택이 될 수 없는 유일한 좋은 유행이다.
세번째는 정확한 Specification이다. 필자의
많은 다른 기사에서 언급했듯이 Specification은 SRS(Software
Requirement Specification)이라고도 한다. 이 단계는 아직 국내에서
극히 몇 안 되는 회사만이 조금 이해하고 있거나 현재 자신의 상태에 대한 자아인식(Meta-Cognition)을 하고 있는 상황이다. 자아 인식을 하고 있다는 것은 이미 반은 진행된 것과 같으니 희망적인
회사이다. SRS는 문서이지만 중요한 것은 분석이라는 행위이다. 국내의
거의 모든 회사는 아직 이슈관리시스템이 없이 개발이 불가능하다는 두번째 단계 조차도 깨닫지 못하고 있는 수준이고 그냥 유행 따라 사치품 정도로
사용하고 있는 것이 현실이다. SRS는 더 갈 길이 멀다. 물론 SRS도 원숭이흉내 수준에서 스스로 자아도취 하면서 실제로는 재택근무도 불가능하고 생산성을 높여 주지도 않는 상태가 대부분이다.
SRS라고 하면 거창한 행위나
Template을 연상하는데 이론적인 소프트웨어 공학자들이 퍼트려 놓은 잘못된 개념이다. 사실 진정한 소프트웨어 공학자는 이론적이면 안 된다. 공학은 현실을 다루는 것이기 때문에 이론과
공학은 상충되는 개념이며 이론적인 공학자는 그냥 자체모순인 용어다. 실용적인 분석을 학교에서 가르친다는 것 자체가
모순에 가깝다. 학교에서 배울 것이 있고 회사에서 배울 것이 있다. 이론으로 무장한 가짜 소프트웨어공학자가 많은 것이 국내의 상황이다. 이는 실리콘밸리의
스탠포드 대학이나 버클리 대학에서 소프트웨어 공학을 어떤 식으로 가르치는 지를 비교해 보면 이해할 수 있다.
SRS는 위에서 언급한
4개의 사적인 Communication이 없이도 재택근무를 하기 위해 개발할 제품에 대한 충분한 정보를
적어 놓은 것이다. 물론 그렇게 만든 행위는 분석행위이다. 어떤 경우는
한두 페이지 일 수도 있고 어떤 경우는 수천 페이지 일 경우도 있다. 이런 추상적인 개념을 이해하는 것은 정형적인 Template과 방법론에 익숙한 개발자들에게는 매우 도전적인 과제이다. 한번 미신에 빠지면 그 습관과 생각에서 헤어나오기 힘들다.
결론은 소스코드관리시스템, 이슈관리시스템과 SRS의
3개가 재택근무를 가능하게 하는 필요충분 조건이다. 4개의 사적인
Communication은 응급시에 사용하는 사치품 정도로 생각하면 된다. 이제
소스코드관리시스템의 필요성에 대해 이해를 했다면 아직 2단계가 더 남아 있는 것이 통상적인 국내의 수준이다.
미래를 예측해 보면 약 10년 후에는 이슈관리시스템이 없이는 개발이 불가능하다라고
대다수의 개발자들이 인식할 수 있을 것으로 예상한다. 그 다음에는 차원을 달리하는 SRS라는 분석행위가 기다리고 있다.
마지막으로 필자가 이 3개가 없으면 개발이 불가능하다고 했는데 100% 사실은 아니다. 가능한 경우도 있다. 이런 경우를 열심히
부자가 되기 위한 방법을 설명했는데 그런 노력을 하지 않고도 부자가 되는 방법이 있다. 로토에 당첨되는 것이다.
이 말은 미국의 소프트웨어 컨설턴트인 Robert Japenga한 말이다. 미신에 현혹되어 기적을 바라는 어리석은 인생을 살지 말라는 교훈이다.
과연 국내에서 재택근무가 가능할까? 회의적이다. 하루 이틀은 가능하겠지만
그 다음부터는 어떤 현상이 일어날지는 눈에 선하다. 코로나 바이러스 때문에 생긴 천재지변이 아니더라도 지금도 효율적으로 개발하기 위해서는 재택근무가 가능한 3개의 역량을 가지고 있어야 한다.
댓글 없음:
댓글 쓰기