들어가며...
SW 엔지니어를 위한 역할기반 로드맵(KR-SI-1401)을 공개한 이후로 3000여 다운로드와 다양한 의견이 있었습니다. 출발점 치고는 매우 요란하다는 느낌입니다. 용두사미가 안되었으면 하는 바램입니다. 지난 2월 25일, 국가인적자원개발 컨소시엄에서 주최한 소프트웨어 역량강화 세미나에서 “로드맵 조정(tailoring) 및 활용”이라는 주제로 여러 분들과 함께하는 시간을 가졌습니다. 30분이라는 짧은 발표 시간에 참 많은 이야기를 했습니다. 기억을 더듬어 발표 내용을 글로 정리합니다. 발표자료를 보실 때 이 글이 도움이 되시길 바랍니다. (세미나의 다른 발표자료는 KOSTA 홈페이지(http://www.kosta.or.kr/)의 자료실로 가시면 볼 수 있습니다.)
발표자료 다운로드: 로드맵기반 SW엔지니어 역량개발 방안(20140306_송태국)
1. 로드맵 이해(2 쪽)
로드맵에 대해 어떤 분은 직접 이야기 해주시고, 어떤 분들은 sns 에 모여 열띤 논쟁을 했습니다. 어느 것 하나 소홀히 할 수 없는 소중한 의견들이었습니다. 의견을 주신 모든 분들께 감사의 마음을 전합니다.
이 로드맵은 참조용으로 만든 로드맵입니다. "로드맵의 실체를 보여 주자"가 첫번째 목적이고, "역할 기반으로 만들어야 한다는 주장"이 그 다음 목적입니다. 온라인 상에서 일부 오해하신 것 처럼 “모든 개발 조직은 이 로드맵을 가져다 적용해야 한다”가 아닙니다. “이런 방식(역할 기반)의 로드맵을 만들되 조직의 특성에 맞도록 새로 만들거나, 참조 로드맵을 조정(tailoring)하여 적용해야 한다”라는 의견을 제시하고 있습니다.
1.1 역할 그룹 이해(3, 4 쪽)
역할 그룹은 “로드맵: 역할기반 SW 엔지니어 분류”에서 서술하였듯이 로드맵 구성을 위한 중요한 기준 중에 하나입니다. SW 개발에 참여하는 모든 역할을 관리, 개발 기술, 도메인, 시스템 엔지니어링, 솔루션 엔지니어링 다섯 가지로 분류하였습니다. 따라서 SW 개발 프로젝트에 참여하는 모든 역할 담당자는 반드시 다섯 가지 역할 그룹에는 속해 있는 역할을 수행합니다.
다섯 가지 그룹 중에 시스템 엔지니어링 역할그룹과 솔루션 엔지니어링 그룹은 HW나 솔루션 벤더에서 주로 이끌어 가는 기술입니다. 그러다 보니 SW 개발 조직에서 직접 해당 활동을 수행하는 경우가 드물어 로드맵의 대상 역할그룹이 되는 경우가 별로 없습니다. 따라서 관리, 도메인, 개발 기술, 세 가지 역할 그룹이 개발 조직을 위한 로드맵의 역할 그룹에 포함됩니다.
SW 개발 조직이 수행하는 개발의 특성에 따라, 특정 역할 그룹을 배제하거나 또는 최소한의 역할만을 정의하여 포함시키기도 합니다. 예를 들면, SM을 주로 하는 조직에서는 관리, 도메인, 개발 기술 역할그룹을 모두 포함하며, SI 개발에서 전문 협력업체로 주로 참여하는 개발조직은 도메인과 개발 기술 역할그룹 만을 포함하며, SI 개발에서 단순 협력업체로 참여하는 개발조직은 도메인 역할그룹을 제외하고 개발기술 역할그룹 만을 포함합니다.
세부 역할 정의는 참조 로드맵(KR-SI-1401)에서 정의한 역할을 참조하여 조직 고유의 역할을 정의합니다. 조직에서 정의하는 조직 고유의 역할은 이미 정의한 역할을 재정의하거나 통합된 형태일 수 있습니다. 몇몇 역할을 통합하여 하나로 부르는 방식은 미리 정의한 역할 명세에 혼란을 가져올 수 있습니다. 따라서, 참조용 역할 이름을 재정의하는 수준에서 조정하는 것이 바람직합니다.
1.2 로드맵 구성요소 (5, 6 쪽)
역할기반 로드맵을 구성하는 두 가지 요소는 역할(role)과 기술(skill)입니다. 기술은 곧 역할역량 을 표현하는 수단이기도 합니다. 그런데 이 역할을 자세하게 정의한 역할 명세서(role specification)와 기술 명세서(skill specification)를 모아 놓은 업계의 표준 라이브러리가 필요합니다. 기술의 발전에 따라 새로운 기술이 등장하고 그 기술은 기존 역할 담당자에게 추가로 할당되거나 새로운 역할이 등장합니다. 불과 몇 년 전만 하더라도 데이터 과학자(data scientist)라는 역할은 없었지만, 빅데이터의 물결을 타고 시장에서 가장 애타게 찾는 역할이 되었습니다.
역할 라이브러리와 기술 라이브러리를 구축하여 공유할 수 있도록 하는 것은 소프트웨어 업계의 과제입니다. 이러한 라이브러리는 SW 개발자의 직무를 정의할 때도 훌륭한 참조자료로 활용할 수 있습니다. 주체가 누가되는 하루 빨리 라이브러리 구축에 나서야 합니다. 그 때까지는 로드맵을 중심으로 우선 정의를 해 나가겠습니다.
2. 로드맵 활용 (7 쪽)
참조용 로드맵(KR-SI-1401)은 말 그대로 참조용 로드맵입니다. 현재 사용하고 있는 기술을 가급적 많이 담아서 로드맵을 만들었습니다. 참조용 로드맵을 바로 적용할 수 있는 개발조직은 흔치 않을 겁니다. 개발 조직은 저마다의 특성을 가지고 있어서 서로 다른 로드맵을 요구합니다. 참조용 로드맵을 기반으로 조직 고유의 로드맵을 만들어 가는 과정을 “조정(tailoring) 과정”이라 부릅니다.
조직의 SW 엔지니어링 역량을 높이는 작업에 로드맵을 사용할 수 있습니다. 엔지니어 개인과 팀의 역량을 로드맵에서 제시하는 역할과 기술이라는 요소로 표현할 수 있습니다. 즉, 어떤 엔지니어가 “수행 가능한(acceptable)” 역할로 그 엔지니어의 역량을 표현합니다. 엔지니어는 하나 이상의 수행 가능한 역할을 가집니다. 어떤 엔지니어는 수행 가능한 역할 개수가 많을 수 있습니다. 이런 엔지니어를 역할 범위(coverage)가 넓다고 표현합니다. 어떤 엔지니어는 수행 가능한 역할 개수가 적지만 높은 수준의 역할을 수행할 수 있습니다. 역할의 넓이 보다는 깊이를 가진 엔지니어라고 표현합니다. 개별 엔지니어의 역할 특성을 더하면 팀의 역할 특성을 알 수 있습니다. 역할 특성을 통해 조직 역량의 강점과 약점을 알 수 있습니다.
2.1 로드맵 구축 (8 ~ 11 쪽)
이 발표자료의 목적은 로드맵 구축 절차를 공유함으로써 적은 노력만으로도 조직 고유의 로드맵을 구축하고 활용할 수 있도록 도움을 주는 것입니다. 로드맵 구축하기 위한 절차가 8쪽 그림 오른쪽에 있습니다. 현재 두 개 회사에서 관련 활동을 수행 중입니다. 끝나는 대로 로드맵 구축 절차를 자세하게 정리하여 공유하겠습니다.
조직 고유의 로드맵을 구축하려면, 절차, 참조 로드맵, 역할/기술 라이브러리가 필요합니다. 로드맵은 이제 걸음마 단계입니다. 각 개발 조직에서 수행한 로드맵 구축을 위한 노력들이 공유된다면 훨씬 더 쉽고 정확하게, 시행착오 없이 로드맵을 구축할 수 있겠지요.
로드맵 구축의 두 가지 축은 기술 조정과 역할 조정입니다. 참조 로드맵에서 정의한 기술 중에 개발 조직에 필요한 기술을 골라 내거나 추가합니다. 필요하면 기술 카테고리도 다시 정의할 수 있습니다. 저는 기술을 정의할 때, 9 쪽에서처럼 프로그래밍 언어, 모델링, 프레임워크, 플랫폼, 환경과 프로세스라는 다섯 가지 카테고리를 사용합니다. 때로는 소통이라는 카테고리를 추가하기도 합니다.
역할을 조정하는 과정에서 조직의 개발 프로세스(=개발 방법론)을 검토하는 것이 좋은 방법입니다. 왜냐면 개발 프로세스는 결국 팀이 개발하는 방법을 잘 정의해 놓은 곳으로, “어떤 역할(role) 담당자가 어떤 활동(activity)을 통해서 어떤 산출물(work product)을 만들어 내는가”로 요약할 수 있기 때문입니다. 잘 정의된 개발 프로세스를 보유하고 있다면 역할 조정은 아주 쉬울 수 밖에 없습니다. 11 쪽의 내용을 참조하세요.
2.2 엔지니어 역량 분석(12 ~ 16 쪽)
엔지니어 역량 분석 또는 평가는 가장 어려운 활동입니다. 객관적이 평가 방법을 찾는 일이 쉽지않을 뿐만 아니라 찾았다 하더라도 평가 결과에 대해서 엔지니어들의 공감을 얻어내기가 힘듭니다. 완전한 방법을 찾기 어려운 탓에 평가가 지연되다가 흐지부지 되는 경우가 많습니다. 따라서 아주 간단한 방법으로 평가를 우선 시작하는 것이 중요합니다.
12쪽을 보시면 1. 간단한 설문, 2. 복잡한 진단 체계, 3. 단순 시험 등으로 평가 방법 세 가지를 제시하였습니다. 빠른 평가 진행을 위해 “간단한 설문”으로 시작하실 것을 권해 드립니다. 저는 12쪽에서 평가 대상 엔지니어용 7가지, 팀장용 3가지를 제시했는데 조직 상황에 맞게 새로운 항목을 추가할 수도 있습니다.
단순한 시험만으로 엔지니어를 평가하는 것은 바람직하지 않습니다. 특히 시험 결과로 엔지니어를 줄 세우는 것은 가장 나쁜 평가 방법으로 원하는 결과(엔지니어의 역량 특성이나 수준 파악)를 얻지 못할 뿐만 아니라 평가 자체에 대한 신뢰를 얻을 수 없습니다. 따라서 시험은 복잡한 진단 체계의 한 가지 방법으로서만 의미가 있으며, 그것도 특정 역할에서만 평가 수단으로 의미를 찾을 수 있습니다.
처음 평가는 간결하게 출발한 다음, 6개월 또는 1년 정도의 시간을 가지고 천천히 역량 진단 체계를 만들어 가야 합니다. 평가 체계는 평가를 넘어서 엔지니어들이 자신의 역량을 어떻게 향상 시켜야 하는 지를 안내하는 역할을 합니다. 중요한 만큼 신중하게 추진해야 하며 역량 개발 담당자 뿐만 아니라, 개발 팀장, 엔지니어 모두의 공감대를 얻을 수 있어야 합니다.
엔지니어의 역량 분석은 개인을 넘어 팀, 조직 전체의 엔지니어링 역량 특성을 알 수 있습니다. 어떤 역할역량이 취약한 지 바로 알 수 있고, 누가 어떤 역할 역량을 가지고 있는 지 알 수 있고, 팀의 역량 특성도 알 수 있습니다. 역량의 본질적인 특성은 정성적이지만, 역할과 기술을 통해 엔지니어링 역량을 정량화 하고 가시화 할 수 있습니다. 정량화하여 보여 줄 수 있으므로, 다음 작업은 아주 쉽게 진행할 수 있습니다.
2.3 목표역할 설정(17, 18 쪽)
엔지니어 개인과 팀의 역량을 분석하여 현재 개인과 팀의 역량 특성을 알 수 있습니다. 이제 역량 개발로 가는 길을 떠나 봅니다. 우선 목표를 설정해야 합니다. 목표를 설정하는 방식은 매우 간단합니다. 우리는 “수행 가능한 역할”이라는 기준 값을 가지고 있습니다.
수행 가능한 역할은 역할 적합도로 상세하게 표현할 수 있습니다. 도메인 모델러로 역할 적합도 70%라는 의미는 역할을 수행할 수 있는데 그 수준이 70% 라는 것입니다. 그리고 이 역할 적합도는 그 역할 수행에 필요한 역할 기술을 평가한 값의 평균값입니다.
목표 설정은 기존에 수행 가능한 역할의 역할 적합도를 높이는 방식으로 합니다. 즉, 2014년 초에 초급 웹 프론트 엔지니어로 50 퍼센트의 역할 적합도를 가진 것으로 평가된 엔지니어가 2014년 말에 80%로 역할 적합도를 올리는 것을 목표로 할 수 있습니다. 때로는 새로운 역할을 목표로 정할 수도 있습니다. 새해에는 프로젝트 관리자 역할을 목표로 하고, 역할 적합도는 30% 수준으로 설정할 수 있습니다.
목표 설정은 곧 목표 역할 및 역할 적합도 설정입니다. 목표 설정은 개인의 바램과 팀과 조직의 기술 방향을 반영합니다. 개인과 팀의 취약점을 보완하거나 회사의 전략 목표에 추진력을 얻기 위해 특정 역할역량을 강화할 수 있도록 목표를 설정합니다. 역할을 통해 역량을 정량화 하고 가시화 함으로써 목표 설정이 아주 간단합니다.
2.4 교육훈련계획 수립(19, 20 쪽)
개인, 팀, 조직의 목표 역할을 설정하고 나면, 현재 “수행 가능한” 역할과 목표 역할 사이에 차이가 발생합니다. 이 차이를 메우기 위해서는 역할역량에 해당하는 기술 수준을 높여야 합니다. 그 기술 수준을 높이기 위해서 해당 기술과 관련된 교육과정에 참여합니다.
2014년 KOSTA의 교육과정은 로드맵을 기반으로 기획하였습니다. 따라서 로드맵에서 목표 역할을 진입하기 위해 어떤 교육을 받아야 하는 지 쉽게 알 수 있도록 역할 단위로 교육과정을 만들었습니다. 교육훈련 계획 뿐만 아니라 교육훈련 과정 기획에 로드맵을 활용한 좋은 예입니다.
교육훈련 계획을 수립하고 나면, 누가 무슨 교육을 들어야 하는 지 명확하게 정리됩니다. 수요가 많은 즉, 참여자가 많은 교육은 외부 강사를 초빙하여 기업 내부에서 수행하는 것도 교육의 효과를 높일 수 있는 좋은 방법입니다. 참여자가 적은 교육은 해당 교육 기관의 강의장으로 가야 합니다.
2.5 교육훈련 성과 분석(21 쪽)
현재의 엔지니어링 역량을 “수행 가능한” 역할로 치환하여 정량화를 하였습니다. 그 결과 교육훈련 계획이 명확하였습니다. 성과 분석 또는 매우 쉽고 간단합니다. 성과 역시 “수행 가능한” 역할이 얼마나 증가하였는가 또는 해당 역할의 역할 적합도가 얼마나 높아졌는가로 이야기 할 수 있습니다.
올해 초 대비, 취약한 역할이 많이 보완되었음을 표를 통해서 쉽게 알 수 있습니다. 그리고 어떤 역할은 내부에서 양성하기 보다는 채용을 통해 역할 역량을 보완할 수도 있습니다. 채용이든 교육훈련이든, 올해 우리 조직이 설정한 목표를 달성했는지 여부를 쉽게 알 수 있습니다.
2.6 역량평가체계(22 쪽)
“2.2 엔지니어 역량 분석”에서 미리 이야기 했듯이 조직의 엔지니어 역량평가 체계를 만드는 데는 많은 노력과 시간이 들어갑니다. 처음에는 간단한 설문으로 엔지니어의 역량특성을 표현합니다. 그리고 조직이 필요로 하는 진정한 엔지니어의 모습을 정확히 그릴 수 있을 때까지 천천히 기간을 가지고 역량평가 체계를 만들어 가야 합니다. 엔지니어에서부터 인사 담당자, 관리자, 임원 모두가 공감하는 역량평가체계를 갖추지 않는다면 바로 잊혀 질 것입니다.
2.7 경력경로 안내(23 쪽)
팀장은 로드맵을 바탕으로 팀원의 경력 경로를 안내해 줄 수 있습니다. 로드맵에서 엔지니어의 현재 위치를 바탕으로, 개인이 원하거나 팀이나 조직이 원하는 미래 역할을 함께 고민합니다. 엔지니어가 어느 방향으로 움직여야 하는 지 이야기할 때, 로드맵은 지도와 같은 역할을 합니다.
마무리 하며...
20여 쪽 남짓한 발표 자료에 많은 내용을 담으려 했습니다. 세미나에 참석하지 않고 자료만 보시는 분께는 자료가 답답할 수 있습니다. 약간의 글로 세미나 자료를 보완했습니다. 그럼에도 부족할 수 밖에 없습니다. 온라인이든 오프라인이든 보다 다양하고 깊은 토의할 수 있는 자리가 생겼으면 하는 바램입니다. 여러분의 피드백은 언제든지 환영합니다(tsong@nextree.co.kr, 송태국). 감사합니다.
발표자료 다운로드: 로드맵기반 SW엔지니어 역량개발 방안(20140306_송태국)
