[기고] 주 52시간 근무제 시행, SI 프로젝트의 효율적인 개발 방법의 필요성
- 기자명 양석호
- 입력 2018.07.01 00:53
- 댓글 0
SNS 기사보내기
페이스북(으)로 기사보내기 트위터(으)로 기사보내기 카카오톡(으)로 기사보내기 URL복사(으)로 기사보내기 이메일(으)로 기사보내기 다른 공유 찾기 기사스크랩하기
양석호 이젠고 솔루션R&D팀장
[컴퓨터월드] 고용·근로시장 환경변화, 주 52시간 근무제 도입
2018년 7월 1일은 우리나라 노동시장에서 큰 전환점이 되는 날로 기억될 것이다. 이 날부터 직원 300명 이상의 사업장은 ‘주 52시간 근무제’를 적용 받는다. 노동시장의 충격을 최소화하기 위해 이 근로시간 단축 안은 단계적으로 시행된다. 직원 50명 이상에서 300명 미만은 2020년 1월 1일부터, 직원 50명 미만의 사업장은 2021년 7월 1일부터이다. 다만 30명 미만의 사업장인 경우에는 2022년 12월 31일까지 특별연장근로시간 8시간이 추가적으로 허용된다.
물론 예외도 있다. 24시간 근무가 불가피하거나 공공상의 목적이 있는 운송업, 보건업 등 5개 업종은 특례업종으로 분류돼 이 기준을 적용받지 않는다. 그러나 이 업종도 최소 11시간의 휴식이 법적으로 보장되어야 한다.
이 제도에 대한 직장인들의 생각을 알아봤다. 6월 초 잡코리아가 300명 이상 기업의 직장인 905명을 대상으로 진행한 설문조사의 결과를 보면 아직까지는 기대 반 걱정 반으로 나타나고 있다.
직장인들은 이 제도의 시행으로 업무생산성이 향상될 것(55%)으로 기대하고 있었으며, 직장 만족도가 향상(32.2%)되고 인력이 충원(27.6%)될 것으로 예상했다. 반면 업무량의 변화는 없는데 근무시간만 줄어 야근수당을 못 받는 것은 아닌지(60.8%), 업무 분담이 필요한데 직원 충원이 안 되면 어떻게 해야 할지(44.2%), 그리고 줄어든 근무시간 내에서 더 많은 일을 해야함으로써 업무성과가 저하되는 것이 아닌지(44.2%)에 대한 우려도 있었다.
‘일과 삶의 균형을 위한 1,800시간대 노동시간 실현’이라는 구호 아래 정부에서 과감하게 추진 중인 이 제도는 궁극적으로는 행복한 일터를 만들기 위한 방법으로 크게 환영을 받아야 하지만 모두가 환영하는 것은 아니라는 얘기다. 기업과 노동자 모두 준비가 충분하지 않아 이 제도가 안착되기까지는 많은 시간이 필요하며 해결해야 할 문제가 많아 보인다.
소프트웨어 업계와 개발자들에게 미칠 영향
‘주 52시간 근무제’로 당장 IT업계는 발등에 불이 떨어졌다. 시스템 개발운영 상 수시로 발생하는 긴급한 버그에 대한 대처, 끊임없는 프로그램의 수정, 지속적 보안 업데이트 및 신규개발시스템의 오픈 등으로 근무형태가 일정하지 않은 업종의 특성 상 주 52시간 근무제는 현실과 동떨어졌다는 것이 IT업계의 입장이다. IT서비스산업협회가 지난 4월 이사회를 소집해 IT서비스산업을 특례업종으로 지정해줄 것을 요청하는 등 대응책을 결의한 것도 이런 이유에서였다.
그렇다면 주 52시간 근무제는 IT업계에서 어떤 영향을 미치게 되는 것일까? 가장 먼저 눈에 띄는 것은 프로젝트 일정을 준수하기 위해 연장근무가 불가피하게 일어나는 사업장, 사이트의 법위반 소지이다. 물론 최장 6개월의 시정 기간을 준다고는 하지만 프로젝트를 의뢰한 고객이나 개발을 수행하는 업체에게 과연 유효적절한 해법인지는 여전히 의심스럽다.
개발을 담당하는 사업체 입장에서는 연장근무로 휴일근로가 8시간 넘게 진행될 때 휴일근로수당에 대한 인건비 부담 또한 생각하지 않을 수 있다. 실질임금 하락에 따른 급여인상이나 유지도 당장 힘들어 질 수 있으며 추가인력선발이나 업무 부담에 기인한 효율성도 무시할 수 없다.
개발자는 또 어떤가? 근로시간을 법으로 보장받는 것 자체는 긍정적일 수 있으나 대부분 개발환경이 열악하고 근로조건이 좋지 않은 상황에서 근로시간의 단축은 임금하락과 이에 따른 근로의욕 감소 및 여러 정신적, 육체적 피해 또한 100% 보장받을 수 있다고 현 시점에서 그 누구도 장담할 수는 없다. 이는 누가 시키지 않아도 맡은 바 책임을 다하고 그 누구보다도 프로젝트의 성공을 위해 밤낮을 가리지 않고 묵묵히 일하는 이 땅의 모든 개발자들에게 더 큰 짐을 어깨 위에 지워주는 것은 아닐까?
개발 생산성을 높이기 위한 노력, 그리고 사람
현장에서 이야기하는 업무의 효율화
이번 근로시간 단축 안과는 별개로 개발에 대하여 오랫동안 묵혀두었던 숙제가 하나 있다. 그런데 이번 제도 시행을 앞두고 그 문제가 수면위로 떠오르고 있다. 그동안 모두들 두 눈을 감고 외면했던 바로 ‘효율 문제’다.
세계 노동시장에서 우리나라 노동자의 업무생산성은 선진국과 비교할 때 매우 낮은 것으로 나타나고 있다. IT업계도 마찬가지다. 효율성을 높이기 위해 IT 업계에서는 나름대로 오래전부터 노력해 왔다. 기술 발전과 함께 점점 방대해지고 복잡하지는 시스템을 개발하기 위해서는 개발생산성이 뒤따라야 만했다. 이런 노력의 결과로 RAD, 애자일(agile) 이나 CBD, OOP 및 다양한 CASE Tool, 더불어 수많은 플랫폼과 프레임워크들이 나왔다.
급변하는 시대에 적합하게 사용할 수 있는 도구들이 계속해서 개발된 것이다. 헤아릴 수 없이 많은 이런 도구들의 중심엔 ‘효율의 문제’가 자리하고 있었다. 높은 생산성을 확보하고 품질을 향상시키고 프로젝트를 정해진 기간 내에 완료하기 위해서는 효율성이 중요했다. 위에서 언급한 도구들의 등장으로 소프트웨어 개발에 있어 어느 정도의 생산성과 품질을 확보할 수 있었다.
그런데 현장의 개발자들은 과연 이 생산성과 품질을 정확히 이해하고 행동하고 있으며 그 결과에 대한 만족하고 있을까? 중요하다고 강조하는 개발생산성과 산출물의 품질은 과연 무엇으로 이뤄내고 있는 것일까? 이 자리에서 단정하고 말할 수 없는 수많은 성공요소들이 있으나 그 중의 으뜸은 누가 뭐라 해도 치열한 개발현장에서 직접 몸을 부딪치며 여러 난관을 헤쳐 나가고 있는, 바로 ‘개발자’다.
개발자들의 역량 차이를 줄이고자 하는 노력들
세상에 수많은 일들의 주체는 ‘사람’이다. 그 사람들 중에 개발자가 있으며 개발자들은 일을 통해서 성취감을 얻고 자부심을 가지며 일에 대한 대가를 받는다. 그런데 개발자들의 일은 대게 정량적이기 보다는 정성적이다. 특히나 기계가 아닌 사람은 산업화 사회에서 생산성에 대한 이슈로부터 자유로울 수가 없다. 사람이 가진 능력은 사람마다 모두 다르고 무엇을 어떻게 발휘 하느냐에 따라 그 결과는 너무나도 확연히 달라지기 때문이다.
그래서 사람으로 생산성 문제를 해결해 보고자하는 연구가 있었다. 그 시작은 새크먼(Sackman H), 에릭슨(Erikson WJ), 그랜트(Grant EE)인 세 사람이 낸 『Exploratory Experimental Studies Comparing Online and Offline Programming Performance』이라는 논문에 그 고민의 흔적이 여실히 남아 있다. 이들은 개발 평균 경력이 7년차인 전문적인 개발자들에게 똑같은 업무를 주고 생산성을 비교했다. 그 결과 개발자에 따라 개발 시간은 최대 9배, 프로그램 사이즈는 5배, 실행속도는 10배, 코딩만 고려했을 경우에는 최대 18배나 차이가 났으며 디버깅 시간은 무려 28배까지 차이가 나는 것을 확인했다.
하지만 사람인 개발자는 능력 차이 외에도 컨디션이나 주변의 여러 상황에도 영향을 받을 수밖에 없다. 모든 조건이 동일하다 할지라도 개발자에 따라 생산성에 차이가 날 수 밖에 없으며 산출물은 개발자의 역량에 가장 큰 영향을 받게 된다. 그렇다면 어떻게 해야 이 문제를 조금이나마 해소할 수 있는가? 그 답은 개발자의 역량 차이를 있는 그대로 인정하고 이를 도울 수 있는 개발도구를 이용하는 것이다.
보다 쉽고 빠르게!
소프트웨어 개발을 도와주는 여러 가지 도구들
개발도구는 개발자의 역량을 보완해주고 개발방법론이나 관리 프로세스와 더불어 목표한 개발생산성과 품질을 확보하는 수단으로 인식되고 있다. 개발자로 인한 역량의 차이는 인정을 하되 개발자를 적극적으로 지원하면서 과정과 결과 치를 만들어 낼 수 있는 방법인 것이다.
이와 관련한 연구결과도 있다. 앞서 새크먼(Sackman H)의 연구와 궤를 같이하면서 본격적으로 ‘소프트웨어 위기’를 극복해 보고자 소프트웨어 개발에 대한 평가에 초점을 맞춘 연구는 2013년 예그훕(Yaeghoob Yavari)과 하산(Hassan Bashiri)에 의해 수행됐다.
이들은 『Effort Estimation of Software Development: Depth View on IRAN Case』이라는 논문에서 성공적인 소프트웨어 개발 프로젝트를 위해서는 적절한 노력과 비용이 필요하며 개발노력을 정확하게 예측할 수 있다면 프로젝트 품질과 효율성을 제어하여 생산성을 확보할 수 있다고 주장한다.
프로젝트에 대한 개발노력을 평가하는 측면에서 정성적인 사람보다는 정량적인 요소, 즉 소프트웨어 개발단계의 여러 부분에서 정확하고 수치적인 조사와 평가가 필요하고 이를 위한 정확한 계획과 분석에 노력을 기울이면서 이와 병행하여 개발도구의 역할을 강조하고 있다. 그렇다면 우리 주변에서 살펴볼 수 있고 있고 경험해본 개발도구들 중 프레임워크를 예로 들어보자.
여기 Spring과 Struts로 개발한 산출물과 JSP, Servlet으로 개발한 산출물이 있다. 같은 기능을 가지고 있다는 전제 하에 목표 달성을 위해 프레임워크를 활용하면 그 코드 량이 현저히 줄어드는 것을 확인할 수 있다. 코드 량이 적다는 것은 그만큼 더 많은 자원을 활용할 수 있고 오류의 가능성을 대폭 낮춰줄 수 있다는 의미이다.
프레임워크는 이미 많은 기능들이 공통화가 되어 있어 최소의 코드만을 요구한다. 뿐만 아니라 지속적인 검증의 결과로 개발자들에게 도움을 줄 수 있는 많은 유틸리티와 개발 가이드라인을 제공해 프로젝트 초기 단계에서 실패 가능성을 미연에 방지하고 준비 기간을 대폭 줄일 수가 있다. 프로젝트 기간의 단축과 안정적인 운영으로 불필요한 비용을 줄이고 프로젝트를 성공가능성을 그만큼 높여준다.
다시 주목받는 비주얼 프로그래민 랭귀지(Visual Programming Language)
지난해 초 은행 차세대 프로젝트 개발을 두고 국내 유명 기업이 격돌했다. 이 업체들은 모두 생산성과 품질 향상을 기반을 둔 프로젝트 비용절감을 위한 방법으로서 기존의 개발방법론이 아닌 MDE(MDD/MDA)를 제안했다. MDE는 최근 업계에서 다시 주목받는 핵심 키워드 중의 하나로 OMG에서 내세운 모델주도형구조(MDA)에 기반을 둔 모델주도형개발(MDD) 방법론을 지칭한다. MDE는 정형화된 모델을 중심으로 개발 분석과 설계를 수행하고 소스코드와 여러 산출물을 자동 생성한다.
기존의 전통적 개발방식과 비교했을 때 가장 큰 차이점은 시스템 개발에 필요한 주요 사항들을 시각화하는 즉 비주얼 프로그래밍 랭귀지(Visual Programming Language)를 사용한다는 점이다. 비주얼 프로그래밍 랭귀지(Visual Programming Language)는 사람의 직접적인 코딩을 대체 또는 최소화하여 그 기능 구현이 직관적이고 쉽고 빠르며 시스템을 개발하면서 완성을 하기 전에 기능적 요소들에 대한 확인과 검증을 효과적으로 할 수 있다는 장점이 있다.
이러한 장점의 사례는 쉽게 찾아 볼 수 있는데 어린이 프로그래밍 교육 교재인 스크래치부터 IBM의 블루믹스(Bluemix)까지 적용 범위도 넓다. 표현의 방법도 블록(block) 쌓기 방식부터 UML이나 개발자에게 친숙한 플로우차트(Flowchart) 개발 방식까지 그 유형도 매우 다양하다.
그렇다면 이 비주얼 프로그래밍 랭귀지의 패러다임이 각광받는 이유는 어디에 있을까? 그 이유는 바로 ‘시각화’와 ‘최소한의 코딩’이다. 시각화 관점에서 도메인이 익숙한 사용자 관점에서의 이해와 이를 토대로 시스템을 효과적으로 구현할 수 있다. 즉 개발자뿐만 아니라 모든 도메인의 이해관계자들의 의사소통을 도모하고 시각화된 방법으로 개발이 가능하다는 것이다. 코딩이 없는 개발과 코딩을 하더라도 최소화할 수 있는 기능은 개발자의 직관적 이해를 바탕으로 개발의 편의성을 최대한 제공함으로써 개발 시간의 단축 및 효율을 극대화 할 수 있다.
비주얼 프로그래밍 랭기지 기반의 제품들은 이미 수많은 성공사례를 만들고 환경의 변화에 앞서 대응할 수 있는 능력을 보여주었다. 제품의 성숙도 또한 이미 실제 프로젝트를 수행하는데 있어 제품 도입을 고려해야할 수준에까지 올라와 있다. 앞서 이야기한 개발자의 역량 외에 다른 변수를 최소화하고 생산성과 품질을 보장받는, 프로젝트를 성공으로 이끄는 방법 중 하나가 되었다.
효율과 효과로 말하는 소프트웨어 개발
소프트웨어개발을 지원하는 비주얼 프로그래밍 랭귀지 기반의 CASE 툴이나 다수의 도구, 개발방법론은 쉽고 빠른 개발과 이에 따른 일정 수준 이상의 품질 보장을 목표로 한다는 공통점이 있다. 생산성과 품질은 기술의 빠른 발전과 업무 복잡성의 지속적인 증가로 애를 먹는 모든 프로젝트의 성공을 좌지우지하는 가장 중요한 요소로 그 어느 하나도 소홀히 할 수 없다. 이런 면에서 오랜 기간 발전을 거듭하면서 개발된 비주얼 프로그래밍 랭귀지 기반의 개발도구들이 고객뿐만 아니라 개발자 사이에서도 더욱 관심을 받고 있다.
소프트웨어 개발의 패러다임은 끊임없이 변화하고 있다. 이 변화는 시간이 가면 갈수록 더 빠른 속도로 더욱 다양한 시장의 요구를 충족시키기 위한 방법들을 계속 찾고 있으며 근로환경과 여러 조건들은 새로운 제도 앞에서 도전을 받고 있다.
처음에는 다소 아프고 힘들겠지만 근로시간의 단축은 개발환경에서 많은 변화를 예고하고 있으며 개발자들에게는 환경에 영향을 받기 보다는 적극적인 자세로 업무에 임하고 열린 마음으로 주변의 관심을 가지고 준비하라는 메시지를 던진다.
성공적인 프로젝트는 프로젝트를 기획한 특정 몇몇의 사람들이 아니라 프로젝트에 참여하는 모든 개발자가 최적의 방법을 찾고 실행함으로서 성취될 수 있다. 현재 개발자들의 손에는 생산 지향적 개발생산성의 효율성과 효과지향의 고품질로 화답할 수 있는 비주얼 프로그래밍 랭귀지 기반의 개발도구가 들려 있다. 이 도구들은 본연의 역할 뿐만 아니라 개발자 간의 역량을 좁혀줄 수 있는 환경을 마련하는데도 일조할 것이다. 그렇다면 이제 본격적으로 비주얼 프로그래밍 랭귀지 개발도구를 맞이해 보면 어떨까?