혼자 시작하는 온보딩(Onboarding) 프로세스 구축

들어가며

안녕하세요. 클라우드 이노베이터 메가존클라우드 Cloud Advocate 팀의 현지환입니다.

이제는 많은 기업에서 '온보딩'이 보편화 되었습니다. 프로그램의 규모나 형태와 무관하게, 몇 가지 작은 절차라도 준비해서 시행하는 기업이 많아졌습니다. 특히 코로나의 시기를 지나는 지난 22년은 '온보딩' 트렌드의 정점을 찍었던 것으로 기억합니다. 당시에 수 많은 케이스가 공유되며 제 주변에 많은 회사도 미처 갖추지 못했던 시스템을 수립하고 정비했던 것으로 기억 합니다.

포스트 팬데믹 시대에 자연스럽게 시작된 환경 변화에 온보딩은 특히 중요한 역할을 했습니다. 새로운 입사자의 성공적인 정착을 돕기 위해 회사와 직무, 일 문화, 프로세스와 도구를 이해하고 적응하도록 도왔습니다. 그렇게 빠르게 적응한 입사자는 업무 투입 시간을 줄이고, 시간이 지날수록 회사에 더 많이 기여하며 온보딩의 효과를 입증했습니다.

많은 기업이 채용을 축소하거나 멈추고, 상시 채용으로 전환하며 채용 시장에 차가운 바람이 돌고 있습니다. 어려운 시기이지만 우리는 다가올 훈풍을 위해 준비해야 하는 시점입니다. 준비되어 있는 온보딩이 없다면 지금이 만들기에 아주 적합한 시기일지도 모릅니다.

제가 주로 다루는 분야인 교육을 이야기 할 때 늘 하는 말이 있습니다. "변화가 생기면 교육은 그 변화를 수용하고 계속 바뀌어야 한다. 그렇기 때문에 콘텐츠에는 생명 주기가 필요하고 주기에 따라 발전해야 한다"고 합니다. 세상은 아주 빠르게 변화하고 그에 맞춘 우리의 변화는 다소 느리게 따라갑니다. 하지만 멈춰 있을 수는 없습니다. 작은 변화를 만들어 빠르게 시행하고 결과에 따라 고쳐가는 것이 괜찮은 시도일 것 입니다.

PART 1 | 우리 회사 문제 알아보기

도대체 무엇부터 시작해야 하는가?

모든 일에는 시작과 끝이 있습니다. 계획했던 결과물이 만들어 진다는 것으로 끝은 꽤 명확합니다. 반면, 시작을 어디에서, 어떻게 해야 할 지 결정하는 것은 굉장히 어려운 일 입니다. 특히, 기존에는 아무것도 없는 상태에서 아무도 도와주는 사람이 없는 상황이라고 생각해보면 더더욱 어려운 일이 아닐까 싶습니다.

혼자서 온보딩을 만들어야 하는 상황이라고 생각해 보겠습니다. 그리고 교육 개발 방법론이나 개발 방법에 대해서 잘 모르고, 입사자 발생 시 별도의 프로세스가 정의되어 있지도 않다면, 그리고 전반적인 HR 경험이 부족해서 어떻게 해야 할 지에 대한 결정을 내리기에 부담스러운 상황이라면 어떨까요. 상당히 막막한 순간 일 것 같은데, 이런 경우에 여러분이라면 어떻게 시작하시겠습니까? 다음과 같이 해보면 조금은 해결의 실마리를 잡을 수 있습니다.

1. 알아보기

우리 회사에는 어떤 문제가 있을까요? 우리 구성원들은 어떤 문제를 겪고 있을까요?문제를 발견하는 능력은 문제 해결에 앞서 꽤 중요한 역량 입니다. 만약 그런 문제가 잘 보이지 않는다면 이런 활동을 해보면 어떨까요. 아래와 같은 활동을 통해 우리 조직의, 우리 구성원의 다양한 데이터를 수집할 수 있습니다. 우선 귀를 기울여서 듣는 것부터 시작해 봅시다. 우리 조직은, 우리 구성원은 어떤 문제가 있고 어려움을 겪고 있나요?

• 1:1
• 포커스 그룹 인터뷰
• 조직 만족도 조사

2. 발견하기

수집한 데이터에서 우리는 무엇을 발견할 수 있나요? 발견한 내용에 공감 할 수 있나요? 제가 온보딩을 처음 만들 때는 6명과 1:1으로 약 8시간 정도의 조사 시간을 거쳤고 그 시간 동안 여러 문제를 발견할 수 있었습니다. 여러분은 어떤 발견을 하셨나요, 분명 의미 있는 문제를 발견할 수 있을 것 입니다. 숫자는 중요하지 않습니다. 발견이 중요합니다. 하나라도 발견했다면 그것으로부터 시작해 볼 수 있습니다. 여러 개를 발견했다면 어떤 것이 더욱 시급한 문제인지, 무엇부터 해결 해야 할 지 우선 순위도 생각해봅시다.

3. 고민하기

발견한 문제는 어떤 이유로 발생한 것 일까요? 그 원인이 정말 맞는 것 일까요? 문제를 발견했다면 다음으로는 원인과 현상에 대한 정의가 필요합니다. 그래야 해결 방법까지 도달 할 수 있습니다. 지금 우리 회사의 상태는 어떤지, 어떤 이유 때문에 이런 문제가 생기고 있는지 깊이 있는 고민을 해야 합니다. 개인의 발달에 메타인지가 중요한 것처럼, 문제의 본질을 찾기 위한 가급적 객관에 가까운 진단이 중요합니다. 그 진단을 기반으로 해결 방법을 찾을 수 있게 됩니다. 한 번 같이 고민해 봅시다.

4. 해법찾기

발견한 문제의 원인으로 도출한 이유를 어떻게 해결할 수 있을까요? 이유에 대한 가설을 중심으로 해결하기 위한 방법을 수립하고 실제 시행해 보면서 검증을 해야 합니다. 앞서 고민했던 것처럼 이유에 대한 명확한 인식이 진행된다면 우리는 주변에서 유용한 해법에 대한 힌트를 얻을 수 있습니다. 유사 상황에 대한 다른 회사가 해결한 케이스나, 내 주변에서 인맥이나 다른 회사를 다니는 친구의 이야기에서도 해결의 실마리를 찾을 수 있습니다. 모든 것이 정보가 됩니다. 해법을 구체화하고 실행 가능한 구조를 만들어 봅시다.

5. 보완하기

한 번에 모든 문제를 해결할 수 있을까요? 해결되었다면 그것으로 끝일까요? 실행 가능한 구조를 만들어서 실행했다면 데이터가 남을 것 입니다. 수립한 가설이 원인 해결에 얼마나 도움이 되었는지, 이 프로그램으로 얼마나 도움을 받았는지, 또 어떤 것을 해볼 수 있을지. 다양하게 수집한 피드백을 기반으로 우리는 또 다른 과제를 도출하고 그것을 달성하기 위한 지속적인 개선과 실행이 필요합니다. 어떤 주기로 어떻게 바꾸어 나갈지 설정해 봅시다.

중간 정산

지금까지 여러분이 읽어보고 생각한 내용은 PBL(Problem Based Learning)의 한 과정을 가장 가볍게 살펴본 것 입니다. PBL에는 여러가지 모형이 있는데, 저는 주로 1985년에 만들어진 Barrow의 모형을 가장 즐겨 사용합니다. 소프트웨어 개발 방법론, 혹은 교육 개발 방법론과 일치 하는 부분이 많아서 가장 익숙하기 때문이기도 합니다. 또 다른 이유는 우리가 문제를 중심으로 사고 하는 흐름을 반영하고 있기 때문입니다.방법론을 대하는 태도는 사람마다 다릅니다. 어떤 이는 방법론에서 규정하는 모든 것을 하나도 빠짐없이 지켜야만 한다고도 하고, 어떤 이는 방법론은 방법의 형태이니 필요한 부분만 차용해도 된다고 생각합니다. 무엇이 정론이다를 논할 생각은 없습니다. 결국 활용하는 사람이 어떻게 하느냐에 달려 있다고 생각합니다. PBL에 대한 자세한 내용은 여기에서 보실 수 있습니다.문제 해결을 위한 연습을 해보면 아마 조금 더 쉽게 이해가 될 것 같습니다. 시나리오를 정해서 우리 한 번 본격적인 실전을 대비한 연습을 시작해 볼까요?

PART 2 | 온보딩 프로세스 구축하기

시나리오를 기반으로 문제 해결을 위한 방법을 차례차례 진행해 봅시다. 여러분에 회사에 신입 사원이 들어 옵니다. 처음 있는 일이라면 어떤 준비를 할 수 있을까요?

• 전체 인원 25명 중 개발자 19명
• 인력 구성의 대부분은 미드레벨, 시니어. 개발팀 신입은 없음
• B2C 대상으로 콘텐츠 서비스를 하는 IT 회사
• 올해 시리즈 A 투자를 통해 30억 원의 자본금 획득
• 아직 적자지만 꾸준히 매출이 오르는 등 BM이 확실한 편
• 입사 후 3개월의 시용 기간이 있음
• 기존 온보딩이나 입사 프로세스 없음
• 오늘을 시작으로 올해 동안 3명 정도의 신입 사원이 입사할 예정
• 5일 중 하루는 재택 근무, 나머지는 사무실 출근
• 사무실은 강남대로 쪽에 있는 작은 8층 건물의 2개 층을 사용 중
• 주요 업무 도구는 Google Workspace, Microsoft Office, Slack, JetBrains Dev Tools, etc.
• 회사의 조직 문화는 명확하지 않음
• 개발팀의 개발 문화는 명확한 편
• 입사하는 신입 사원은 Front-end 개발자(마이스터 고등학교 출신, 20살, 미필, 남자, 일과 성장에 대한 열정은 있지만 다소 내성적인 성격으로 주변과 관계에 관해 적극적인 면을 가지지는 못함)

지금부터 우리는 이 회사를 다닌다고 생각해 봅시다. 회사의 이름도 필요하겠네요. 'Dodolin'이라고 해볼까요? '도돌린'이라고 부르면 될 것 같습니다. 도돌린에 다니는 우리는 현재 상황을 제대로 이해하고 있습니다. 우리가 입사할 때를 생각해보면 별다른 프로그램의 진행이나 케어를 받았던 기억은 없습니다. 왜냐하면 별도의 프로세스가 없었기 때문이죠. 이런 상황에서 신입 사원이 온다는 통보를 받았습니다. 우리에게 내려진 미션은 입사까지 남은 두 달 동안 온보딩 프로세스를 만들어라 입니다.어떻게 시작해 볼까요?

(1) 목표 정하기

앞서 살펴본 방법대로 진행하기 전에 우리 이것부터 정해 볼 필요가 있을 것 같습니다. 온보딩의 목표를 설정하고 방향에 대한 일치를 먼저 시작해 보면 어떨까 합니다. 이번 온보딩에 어떤 목표를 설정하고 싶은가요? 여러분이 입사할 때와 같이 방치 됨에 대한 느낌을 받지 않도록 신경 쓰면 좋을 것 같습니다. 동료와 함께 고민한 결과 다음과 같이 목표를 지정해 봅니다.

• 시용 기간 동안 회사에 잘 적응할 것
• 6개월 이내에 단독 업무 투입을 위한 준비를 할 수 있을 것
• 1년 이내 퇴사하지 않도록 할 것
• 장기적으로 최소 3년 간 회사에 근속 할 수 있는 좋은 시작이 되도록 할 것

(2) 문제 정의

신입 사원에게는 어떤 내용이 필요할까요. 주어진 조건에서 문제를 발견해 봅시다. 그리고 더 구체적인 상황을 자세하게 가정해 볼까요.

• 전체 인원 25명 중 개발자 19명 → 프로덕트 개발팀에 인원이 많습니다. 프로덕트 개발에 얼마나 비중을 두고 있는지 가늠할 수 있습니다. 반면 지원 인력이나 세일즈 등의 인력 구성은 부족할 수 있습니다.
• 인력 구성의 대부분은 미드레벨, 시니어. 개발팀 신입은 없음 → 신입이 없다는 것은 가치관과 문화 차이, 기대치와 능력치의 차이가 있을 수 있다는 가정이 가능합니다.
• B2C 대상으로 콘텐츠 서비스를 하는 IT 회사
• 올해 시리즈 A 투자를 통해 30억 원의 자본금 획득 → 당분간 인원 확충이 지속될 것으로 생각할 수 있습니다.
• 아직 적자지만 꾸준히 매출이 오르는 등 BM이 확실한 편
• 입사 후 3개월의 시용 기간이 있음
• 기존 온보딩이나 입사 프로세스 없음
• 오늘을 시작으로 올해 동안 3명 정도의 신입 사원이 입사할 예정 → 신입 외에도 상시 충원은 계속 될 것이며, 연차나 경력에 따른 프로그램 세분화가 필요할 수 있다고 생각합니다.
• 5일 중 하루는 재택 근무, 나머지는 사무실 출근 → 프로그램은 온오프라인 복합 구성이나 라포(Rappor) 향상을 위한 별도의 고민이 필요합니다.
• 사무실은 강남대로 쪽에 있는 작은 8층 건물의 2개 층을 사용 중
• 주요 업무 도구는 Google Workspace, Microsoft Office, Slack, JetBrains Dev Tools, etc → 다양한 도구에 적응하는 프로그램이 필요할 수 있습니다.
• 회사의 조직 문화는 명확하지 않음 → 조직 문화에 앞선 기업 문화의 중심을 설정할 필요가 있을 수 있습니다.
• 개발팀의 개발 문화는 명확한 편 → 개발팀의 개발 문화에 정착할 수 있는 안내나, 해당 부서 내 온보딩을 위한 조언이 필요할 수 있습니다.
• 입사하는 신입 사원은 Front-end 개발자(마이스터 고등학교 출신, 20살, 미필, 남자, 일과 성장에 대한 열정은 있지만 주변과 관계에 관해 다소 적극적인 면을 가지지는 못함) → 사회 초년생을 위한 비즈니스 매너, 커뮤니케이션 등 소프트스킬 교육이 있으면 더욱 좋을 것 같습니다.

주어진 조건을 토대로 현재 상태에서 여러 발견을 할 수 있었습니다.

(3) 조사 하기

이제 나의 생각이 아니라 우리의 생각을 알아볼 필요가 있을 것 같습니다.

[1:1 인터뷰]

개인의 문제를 발견하는 데에는 1:1이 가장 좋습니다. 업무 능력, 업무 성과, 개인적인 성장, 커리어 등 다양한 고민을 함께 이야기 할 수 있습니다. 개인의 문제를 조직의 문제로 보기에는 무리가 있습니다. 하지만 개인적인 깊은 교감에서 발견하는 내용이, 여러 명에게 반복되는 문제라면 조금 더 유심히 살펴볼 필요는 있습니다.각기 다른 세대, 역할, 연차를 가진 10명의 구성원과 1:1을 통해 다음과 같은 의견을 확인했습니다.

• 세대 간 갈등 : 업무 방식, 의사소통 스타일 등에서 차이가 있습니다. 이로 인해 의견 대립이나 이해 부족으로 인한 작은 갈등이 있다고 합니다.
• 역할 간 커뮤니케이션 부족 : 직무나 부서가 다른 구성원 사이에 업무 프로세스나 우선순위에 대한 이해 부족으로 커뮤니케이션 문제가 있습니다.
• 경력 개발 기회 부족 : 업무 외에는 성장 기회와 교육 기회가 부족하다고 느낍니다.
• 업무 과부하 : 높은 업무 강도와 스트레스로 인해 직원들이 번아웃을 겪는 구성원이 있습니다.
• 복리후생 및 보상 체계 : 임금, 복지 혜택, 성과 보상 등에 대한 불만족이 있습니다.

[포커스 그룹 인터뷰]

포커스 그룹 인터뷰는 조건을 다양하게 설정하여 해 볼 수 있습니다. 팀장을 모아서 함께 이야기를 해보거나, 주니어를 보아서 함께 이야기 해보거나, 2년차 구성원을 모아서 이야기 해 보거나. 그룹으로 묶는 인원에 따라 다양한 시선을 확인할 수 있고, 서로 공감하는 문제를 발견하여 더 깊은 현실적인 해결책을 위한 한 걸음을 내딛어 볼 수 있습니다. 미드레벨 개발자를 대상으로 FGI를 진행하고 본인들이 신입이었을 때 어려웠던 점을 다음과 같이 수집했습니다.

• 코드 리뷰와 피드백 부족 : 스스로 하는 일이 맞는 것인지 확신할 수 없고, 불확실성을 해소하지 못해 답답했던 경험이 있다고 합니다.
• 의사 소통과 협업 능력 부족 : 일을 시작하기 전에는 혼자서 무언가를 하거나 친구와 함께 작업한 경험이 대부분이라 원활한 의사 소통이나 협업 방식 적응이 어려웠다고 합니다.
• 기술 스택 적응 어려움 : 사용하는 기술 스택이나 도구가 많아서 초기에 적응하는 것이 어려웠다고 합니다.

[조직 만족도 조사]

조직 만족도 조사, 직무 적응도 조사 등 다양한 설문은 데이터 수집의 좋은 수단 입니다. 우리 조직은 어떤지, 직무는 어떤지, 현재 업무와 직무 능력 관련 상황은 어떤지, 어떤 어려움을 겪고 있는지 등을 조사하면 의미 있는 문제를 발견할 수 있습니다.전사 인원을 대상으로 만족도 조사를 진행했더니 평균 만족도 3.8에 개선이 필요하다는 의견이 많이 나왔습니다. 취합해 보면 다음과 같은 의견으로 압축 됩니다.

• 회사 문화 및 비전 공유
  • 회사의 미션, 비전, 핵심 가치에 대한 명확한 설명, 회사의 조직 문화와 업무 방식에 대한 이해 증진 필요
• 업무 프로세스 및 시스템 교육
  • 본인 업무와 관련된 프로세스 및 시스템에 대한 상세 교육, 실제 업무 수행에 필요한 실무 지식 및 스킬 전수 필요
• 멘토링 및 피드백 체계 구축
  • 신입 사원에게 경력 직원을 멘토로 배정하여 적응 지원, 정기적인 피드백 제공을 통해 성장 기회 마련 필요

상황 기반으로 발견한 문제와 세 가지 방법을 통해 조사하여 발견한 문제로도 충분히 많은 내용을 확인할 수 있었습니다. 이 문제들은 온보딩으로 풀 수 있는 것, 조직 문화로 풀 수 있는 것, 제도로 풀 수 있는 것, 프로세스와 업무로 풀 수 있는 것 등 다양하게 구별해 볼 수 있을 것 같습니다. 제가 보기에도 너무 많은 내용이 도출되어(이 시나리오는 제가 썼는데도 말입니다) 이후 단계의 원활한 진행을 위해 아래와 같이 온보딩으로 풀 수 있는 문제를 다섯 가지로 재정의 하겠습니다.

1. 회사의 미션, 비전, 핵심 가치
2. 업무 방식 이해 (프로세스, 도구, 협업)
3. 비즈니스 매너, 커뮤니케이션 등 기초 소프트스킬
4. 성장과 피드백 (+멘토링)
5. 기술 스택 적응, 코드 리뷰 등 기술 문화

(4) 문제 분석

해결 방법 도출에 앞서 문제를 좀 더 자세히 들여다 보고 발견을 위한 시간을 가져 보겠습니다. 앞서 정의한 다섯 가지 문제는 한 번에 해결 할 수 없을지 모르는 복잡한 문제라는 것을 알 수 있습니다. 그래도 작은 해법을 발견하고 하나 씩 실천해 보면 좀 더 나은 방법에 다가서게 될 것이고, 궁극적인 해결에 도달 할 수 있을 것 입니다. 지금부터 살펴 볼까요.

1. 회사의 미션, 비전, 핵심 가치

MVC로 불리는 Misson, Vision, Core Value 입니다. 회사와 구성원이 어떤 방향으로 가야 할 지를 정해주는 매우 중요한 나침반 입니다. 대부분은 C레벨의 의지로 시작되지만, 어설프게 구성되면 허울 뿐인 말에 그치기도 합니다. MVC를 수립하고 문화로 키워내는 것은 단시간에 이룰 수 없는 매우 긴 노력이 필요합니다. 다행히 도돌린에는 인재상과 중첩되어 사용되고 있는 핵심 가치가 있습니다. 다만 언제부터 있었는지, 어떻게 만들어졌는지 히스토리를 아는 사람이 없습니다. 그래도 핵심 가치가 존재 한다는 점에서 적어도 어느 시점에는 C레벨의 의지가 투영된 결과라는 점은 추정해 볼 수 있습니다. 그래도 그동안 채용의 한 기준으로 사용되어 왔기 때문입니다.

당장 입사자가 입사하는 시점까지 새로운 개념을 만들고 기존 구성원과 동기화 하기에는 물리적 시간이 부족합니다. 기존 핵심 가치를 더욱 발전시켜서 문화의 축을 만드는 작업을 하기로 결심했습니다.핵심 가치가 문화가 되고 의사 결정의 기준이 되도록 만들었던 케이스를 찾아봅니다. 생각보다 많은 회사, 그리고 글로벌 회사의 한국 지사에서 시행했던 많은 케이스를 손쉽게 찾아 볼 수 있었습니다. 수집한 사례를 분석해 보니 교육과 워크샵의 두 가지 형태로 진행 할 수 있을 것 같다는 힌트를 발견했습니다. 핵심 가치 교육으로 개념을 이해 시키고, 워크샵을 통해서 핵심 가치를 기반으로 올바른 의사 결정을 하는 방법을 구현해 보기로 결심했습니다.

2. 업무 방식 이해 (프로세스, 도구, 협업)

업무 방식을 이해한다는 것은 회사의 비즈니스 프로세스를 이해하고 더 빠른 업무 적응을 할 수 있는 중요한 지식입니다. 입사 당시에 우리 회사의 업무 방식을 잘 몰라서 어려웠고, 프로세스 같이 명확히 정의되어 있지 않아서 이슈가 발생할 때 마다 해결하기 위해서 이 사람, 저 사람에게 쫓아다니며 물어보고 일을 진행했던 것에 대한 이야기를 해 준 구성원이 있었습니다.업무 방식을 이해하는데 도움이 되는 경험에 대한 케이스를 조사 해 보니, 두 가지 유형이 도출됩니다. 하나는 프로세스 교육과 프로토콜 매뉴얼 입니다. 조금 욕심일 수 있지만 도돌린이 어떻게 일하는 지를 설명하기에 좋은 자료가 될 수 있기에 조금 무리해서 두 가지를 모두 진행해 보기로 합니다.교육은 프로세스에 대한 자세한 이야기 보다는 회사 전체의 일 문화가 어떻게 구성되는 지를 설명하는 내용으로 생각했습니다.

• 협업을 추구하는 핵심 가치
• 도돌린 구성원의 직무
• 회사 전체의 업무 흐름 (직무 별, 상황 별)
• 협업에서 중요한 것 (기록, 소통)

을 교육 자료로 준비합니다. 각 직무 별 간략한 업무 매뉴얼의 구성을 위해

• 3가지 정도의 가장 빈번한 업무 상황 설정
• 순서도 형태의 업무 흐름 이미지
• 플레이 북 형태로 의사 결정 트리 정리 제공

를 각 직무의 시니어에게 부탁 드려 보았습니다.관련 내용을 정리하면 전반적으로 업무 방식을 이해하는 큰 그림을 마련할 수 있을 것 같습니다.

3. 비즈니스 매너 및 커뮤니케이션 (기초 소프트스킬)

온보딩을 만드는 1차 타겟 대상이 이번에 합류하는 신입 사원이기 때문에 회사 생활이 처음일 수 있습니다. 신입의 입장에서 생각해보면 여러가지 비즈니스 상황에서 매너나 행동 방식에 대해 고민을 많이 하게 되는 경우가 많습니다. 실제로 앞선 조사 상황에서 그런 부문에서 당혹스러움을 느끼거나 교육이 필요하다는 이야기를 많이 들었습니다. 어떤 것이 필요할 지를 생각해 보았습니다.

• 메일 쓰기
• 전화 매너
• 복장
• 명함 매너
• 회의 매너
• 커뮤니케이션 (온 오프라인)

비즈니스 매너가 중요한 이유는 전문가로서 내 외부에서 신뢰를 얻고, 그것을 기반으로 원활한 소통과 협업을 하려면 필요하다는 목소리를 적극 반영하기로 했습니다. 모든 콘텐츠는 '전문가'가 되어야 한다는 메시지로 중심을 잡고, 가치는 '신뢰'를 기반으로 한 '협업'으로 드러나게 된다고 이야기 하기로 정했습니다. 이제부터 메일을 잘 쓰는 것은 전문가로 내외부에 신뢰를 얻고 더 잘 협업하기 위해서라고 이야기를 할 것 입니다. 

4. 성장과 피드백 (멘토링)

신입 사원에게는 성장은 중요한 키워드 입니다. 그리고 내부에서 상호 성장을 촉진하기 위한 가장 좋은 촉매가 피드백이라는 것은 리더십 측면에서 많이 강조되어 오고 있습니다. 따라서 성장과 관련된 가장 첫 발걸음은 피드백에 대한 적응으로 목표를 설정했습니다. 피드백을 위해서는 신규 입사자 뿐만 아니라 기존 구성원이나 리더의 교육이 필연적입니다. 기존 구성원이나 리더가 받아야 할 교육에 대해서는 배제하고 신규 입사자 위주로 고민을 해보면 다음과 같은 것을 해 볼 수 있을 것 같습니다.

• IDP를 이용한 성장 계획 워크샵
• 피드백과 수용 관련 교육
• 조직 적응 설문 (1월, 3월, 6월, 1년)
• 기술 멘토 지정 : 직무 기술 적응을 담당해 줄 조력자 (주 2회, 1시간)
• 생활 멘토 지정 : HR 인력과 매칭해서 시용 기간 동안 사내 적응을 담당해 줄 조력자 (주 1회, 1시간)
• 커리어 멘토 지정 : 동일 직무 IC(Individual contributors)에 해당하는 시니어와 매칭하여 성장과 커리어를 도와 줄 조력자 (월 1회, 1시간)

신규 입사자에게는 우리의 새로운 구성원에 대해서 우리가 이렇게 준비하고 노력하고 있다는 메시지를, 기존 구성원에게는 새로운 구성원이 빨리 적응해야 우리의 업무를 효율적으로 나누고 더 많은 상호 성장의 기회를 가질 수 있음을 지속적으로 설득해야 할 필요는 있을 것 같습니다.특히 멘토링 관련해서는 어떻게 해야 할 지에 대한 주요 담당 인원에 대한 매뉴얼을 제공할 필요는 있어 보입니다.

5. 기술 스택 적응, 코드 리뷰 등 기술 문화

HR에서 모든 부서의 직무를 이해하고, 모든 부서의 업무 방식을 이해하기는 어렵습니다. 최대한의 이해를 바탕으로 한다 해도 구체적인 내용에 도달하기는 쉽지 않습니다. 따라서 이 조건에 대해서는 각 부서에서 해결할 수 있도록 가이드를 해야 할 것 같습니다. 다만 각 부서에서 효과적으로 진행할 수 있도록 어떻게 해결해야 할 지에 대한 방향과 단서를 제공할 필요는 있어 보입니다.

• 기술 스택 적응을 위해서는 각 팀 별, 각 직무 별 사용하는 기술에 대한 리스트를 작성하고 101 수준에 해당되는 엔트리 급 외부 교육을 매칭하여 교육 수강을 독려합니다.
• 기술 스택 적응을 위해서는 각 팀 별, 각 직무 별 사용하는 기술에 대해 기초 교육 이후 최소한의 적응을 위한 과제를 만들고, 신규 입사자에 제공하여 기술 적응을 위한 최소한의 장치를 마련합니다.
• 코드 리뷰 등 기술 문화 이해를 위해서는 각 팀 별, 각 직무 별 프로세스를 설명하는 한 페이지 분량의 이미지를 만들 수 있도록 상호 협력 합니다.

모든 조건을 한 번에 해결할 수는 없어도 최소한의 장치에 대한 마련은 가능하리라 생각합니다.

(5) 문제 해결 방법 결정

지금까지 탐색하고 고민했던 결과로 어떤 프로그램을 제공할지 정리가 되었습니다. 이제 효과적으로 동작하도록 어떤 기간 동안, 어떤 시점에 어떻게 배치해서 신규 입사자에게 도움이 되고, 기존 구성원이 부담스럽지 않을지에 대한 고민이 필요합니다.이 시점에서는 중요한 고민이 하나 필요한데, 교육에 대해서 생각하는 관점 입니다.

효율 보다는 효과가 중요하다

'사람'과 '관계'를 만드는 프로그램인 온보딩은 효율적으로 진행하면 접촉면이 필연적으로 적어지기 때문에 목적을 달성하기 어려워 질 수 있습니다. 따라서 휴먼터치라고 불리는 많은 접촉면을 많이 만드는 것이 효과적으로 온보딩하는데 좋다고 생각합니다. 필연적으로 효율 보다는 효과를 쫓게 됩니다.앞서 결정했던 교육, 워크샵, 프로그램을 어떻게 배치할지는 다음 버드뷰 화해팀의 온보딩 내용을 참고해 보시면 좋을 것 같습니다. 캘린더에 일자 별로 어떤 것을 스스로 해야 할지, 어떤 세션을 들어야 할지 등으로 잘 나눠서 정리해 두었습니다.

(6) 시행하기

첫 시행을 앞두고 있습니다. 완벽한 준비가 되었을까요? '완벽'이라는 단어가 주는 압박감은 실로 대단합니다. 처음 하는 업무이고, 처음 만든 프로그램인데 '완벽'을 찾는 다는 것은 무리한 요구인 것 같습니다. 조금은 부담을 덜어보시죠. 사람이 하는 일은 실패가 따르기 마련인데, 우리는 설령 실패하더라도 그 실패를 통해 배울 수 있고, 더 나은 프로그램으로 개선할 수 있다고 생각해 보면 어떨까요. 한결 마음이 편해지지 않나요? 첫 시행이기 때문에 일종에 파일럿 프로그램, 혹은 베타 프로그램을 시행한다고 생각해 봅시다. 우리는 반드시 이번 시행을 통해서 더 나은 개선을 위한 실마리를 발견할 수 있을 것이라는 믿음도 가져 봅시다.운영 관점에서 어떤 것을 고려해야 할까요?참여 하는 사람을 위한 설명서가 준비 되어 있는지부터 살펴볼까요.

• 신입 사원 매뉴얼
• 구성원(참여자) 매뉴얼
• 운영 매뉴얼

신입 사원이 보아야 할 내용, 기존 구성원이 온보딩에 함께 하기 위해서 알아야 할 내용, 운영을 내가 아닌 다른 사람도 할 수 있도록 알아야 할 내용을 모두 문서로 준비해 봅니다. 문서로 준비하고 배포하면 끝일까요? 아닙니다. 매뉴얼을 잘 보지 않는 특성을 감안하면 관련자를 사전에 교육하는 시간도 필요합니다. 하지만 교육에도 참여하지 않는 분도 있다면 우리는 다소 번거롭지만 처음을 시작하기 위해서 쫓아다니며 설명하고 설득할 필요는 있을 것 같습니다. 이렇게 준비가 되었습니다.드디어, 오늘 입니다. 신입 사원이 들어옵니다. 모든 준비가 잘 되어 있는지 한 번 다시 살펴 봅시다. 운영을 위한 내부 도구는 잘 준비되어 있는지, 준비한 프로그램의 내용은 문제가 없는지, 입사자가 사용할 장비와 소프트웨어는 빠짐 없이 준비했는지, 그것 외에 더 생각해야 할 것은 없는지 확인해 봅시다. 지금부터 준비한 모든 것을 진행해 봅니다!

(7) 회고하고 보완하기

신입 사원을 위해, 그리고 이후 추가 입사할 새로운 동료를 위해 준비한 온보딩이 한 사이클 완료 되었습니다. 온보딩에서 준비한 것 중 어떤 것이 예측한 어려움을 해결하는데 도움이 되었는지, 의도대로 설계한 입사자 경험은 어땠는지, 어떤 것이 제대로 동작하지 않았는지, 입사자 입장에서 어떤 부분이 좋았고, 어떤 부분이 보완이 필요한지 다양한 의견을 들을 수 있게 됩니다. 긍정적인 내용이든 부정적인 내용이든 우선 모두 수집해 봅시다. 이 중에서 칭찬과 비판은 정리해 봅시다. 칭찬을 기반으로는 어떻게 더 잘해낼 지를 고민하고, 비판을 기반으로는 실패를 인정하고 수용하고 변경할 수 있어야 합니다. 입사자의 의견이나 나의 개인 회고도 필요하지만, 온보딩을 위해 함께 애써준 모든 동료의 이야기도 들어보면 좋겠습니다.

MVC 모델이 추상적이라 잘 와 닿지 않았습니다
비즈니스 매너에 고객 커뮤니케이션 관련한 내용이 추가되면 좋겠습니다
멘토가 주는 피드백이 평가 같이 느껴졌습니다

이런 의견이 수집 되었다면

• MVC를 고도화하고 관련 교육과 워크샵을 통해 내재화를 더 진행하고, 의사 결정의 기준이 될 수 있도록 반복해보겠습니다
• 고객 커뮤니케이션을 위한 톤과 피치, 몸짓 언어, 대화 기법에 대한 구체적인 교육을 만들겠습니다
• 멘토의 언어를 위한 가이드를 제시하고, 올바르고 안전한 피드백 교육을 만들겠습니다

와 같은 보완 계획을 세울 수 있습니다. 온보딩을 필두로 한 내부 교육 체계를 조금 더 구체화하고 조금 더 발전할 수 있을 것 같습니다.

(8) 다시 처음으로

지금까지 우리는 문제를 발견하고, 해결하기 위한 방법을 만들고, 그것을 프로그램 온보딩을 진행하고, 그 결과에서 보완할 과제를 3개 발견했습니다. 보완하기 위해 준비는 지금부터 시작해야겠습니다. 온보딩 자체는 바꾸어야 할 점이 없을까요? 이 글의 처음에 콘텐츠는 계속 바뀌어야 한다는 이야기를 했었습니다. 보완 과제를 달성하고 온보딩의 부족한 점을 채웠다면 일정 주기에 따라 전체 프로그램을 진단해 볼 필요가 있습니다. 지금 우리 회사의 상황에서 적합한 프로그램인지, 노후화 된 콘텐츠는 없는지, 문제 발견 단계에서 우선 순위를 낮춰서 개발하지 않았지만 추가적으로 개발할 콘텐츠나 프로그램은 없는지, 운영 방식의 개선이 필요한 점은 없는지 점검이 필요합니다. 도돌린 온보딩의 생명 주기 설정은 다음과 같이 결정했습니다.

입사자 발생과 입사자 수에 대한 경향을 보고 단기 개선을 결정했고, 콘텐츠를 중심으로 노후화가 진행되는 것이 1~2년 사이에 빈번하다는 것을 경험으로 알고 있어서 장기 개선을 결정했습니다. 이 결정에 영원한 것은 아닙니다. 결국 변화에 유연하게 대응하기 위해서는 언제든지 변화가 있을 수 있다는 것을 염두에 두고 관리할 수 있어야 합니다. 그러기 위해서는 사전에 변화를 관리하는 방법에 대한 고민도 필요할 것 같습니다. 여러분의 회사, 상황, 프로그램 대비 콘텐츠의 종류에 따라 주기를 설정하고 개선하는 방법을 마련해 보면 좋겠습니다.

마치며

이제 어떻게 해야 할 지 머리 속에 좀 그려지시나요? 하나의 예를 들어 이야기 드렸지만 적합한 방법일 수도 그렇지 않을 수도 있습니다. 방법론은 방법의 하나이지 무조건 적인 진리는 아니라고 생각합니다. 결국 더 나은 무언가를 창조하는 것은 이런 방법론이나 사례를 응용하여 여러분의 지식과 경험을 토대로 만들어 가는 것이 아닐까 합니다. 이 글이 여러분의 능력을 발휘하는데 작은 아이디어나 도움이 되길 바랍니다.

참고 링크
https://speakerdeck.com/lemonadegt/gyoyugeuro-munhwa-mandeulgi-chapter-2