산학협력 : 소프트웨어 교육의 현장성 확보

또 듣는 이야기지만 소프트웨어 개발자가 부족하다. 또 듣는 이야기지만 학교를 마친 졸업생들의 개발 역량이 회사가 필요로 하는 실무 역량에 크게 미치지 못한다고 한다. 닷컴 버블 이후 소강상태가 잠시 있었을 뿐 이런 이야기가 나오지 않은 때는 없었다. 아마 이 상황은 영원히 지속될 것으로 생각된다.

 

개발자 부족을 외치는 기사 제목들

우선 회사 입장. 개발자가 부족한 것과 지원자 또는 신입 개발자 역량이 부족한 것도 서로 연동되어 있다. 지원자는 많은데 쓸 만한 사람이 없다는 것이 더 맞는 표현일 수 있다. 회사가 기대하는 실무 역량에 관한 정의도 회사의 규모, 회사의 제품 또는 서비스에 따라 다를 수 있다. 표현은 다르게 할 수 있지만, 사실 이 모든 것은 돈 또는 돈과 호환되는 자원의 문제일 뿐이다. 좋은 개발자를 뽑으려면 채용이 될 만한 환경의 준비, 홍보, 채용 과정, 그리고 채용 후에 좋은 개발자에 합당한 비용을 지불할 준비가 되어 있어야 한다.

 

다음은 교육기관 입장. 현장형 교육이 중요하다고 한다. 현장형 교육이란 현장에서 필요한 기술을 학교에서 배워야 한다는 의미보다는 현장처럼 배울 수 있는 환경을 교육에서 제공해야 한다는 것을 의미한다. 당연히 그런 환경에서 배워 학생들이 졸업 또는 수료 시점에 바로 써먹을 수 있는 기술 역량과 태도 역량을 갖추는 수준에 이르게 만드는 것이 교육의 지향점이 되어야 한다.

 

다시 생각해보면,  학교는 학교이고 현장은 현장이다. 같아지는 것은 일단 불가능하다. 현장형 교육이 되려면 학교가 학교스러운 상태에서 현장스러운 상태로 바뀌어야 한다. 소프트웨어는 사람들이 협력해서 만들어간다. 현장스럽게 가려면 학교의 사람들인 교수, 조교, 학생 모두 ‘학교 모드’에서 ‘현장 모드’로 마음가짐을 바꾸어야 한다는 것을 의미하고, 이론도 이론이지만, 현장에 있을만한 문제를 현장의 방식(도구와 협업)으로 해결하는 경험이 학교에서 제공되어야 한다. 그런데 학교는 학교이다. 비슷하게 할 수는 있지만 매우 힘들고, 학교만의 노력으로는 비슷하게 만들기도 어렵다는 것이 받아들여야 하는 현실이다. 교수는 개발자가 아니라 교수다. 대부분 현업 개발자 수준의 경험이 부족하다. 학생은 그냥 주어진 숙제만 하던 학생이고, 조교는 학생의 연장인 경우가 많다. 그렇다고 학교가 잘못된 것은 아니다. 그들은 학교의 사람들로서 나름의 역할을 다하여 왔고, 또 그 역할로 평가를 받기 때문이다.

 

학교가 현장다워지려면 학교도 갖은 노력을 해야 하고, 현장을 가진 산업도 학교와 친하게 지내기 위한 노력을 경주해야 한다. 세상에 공짜는 없다. 말이 노력이지 사람이든 돈이든 자원이 들어간다. 그리고 그 투자의 결과가 투입된 자원보다 커지도록, 즉 HR 관점에서 생산성이 높아지도록, 학교와 회사 모두 시스템화하는 작업이 필요하다.

 

회사가 개발자를 잘 뽑기 위해서는 당연히 개발자 보기에 좋은 회사여야 한다. 여기서 키워드는 ‘보기’와 ‘좋은’이다. 여러 조건이 있겠지만 회사 자체가 좋은 회사가 아니면 좋은 개발자를 뽑을 수 없다. 좋은 회사는 성장이 가능한 회사이다. 좋은 회사는 지금 근무하고 있는 개발자 직원이 자기 친구에게 ‘너도 와라’며 우리 회사가 좋다고 추천할 수 있는 회사이다. 일단 좋은 회사라고 치고, 우리 회사가 ‘있다’는 것과 ‘좋다’는 것을 예비 개발자들에게 노출시켜야 한다. 경력이나 대학을 졸업한 신입이나 개발자를 뽑으려면 우선 그들이 ‘아는’ 회사가 되어야 한다. 놀랍게도 학생들은 회사를 찾는 노력을 거의 하지 않는다. 그들을 탓할 것이 아니다. 그들이 우리가 모셔와야 하는 고객임을 인정하고 회사가 일을 해야 한다. 우리 회사의 개발자를 학생들, 예비 개발자들, 개발자들이 있는 학교 커뮤니티로 보내고 우리를 소개해야 한다.

소프트웨어 개발자 관점에서 좋은 회사가 되기 위해 할 수 있는 노력들은 [클릭 -> 개발자 채용 가이드북 <- 클릭]에서 찾아볼 수 있다. 주로 Tech-HR, DevRel (Developer Relations) 활동에 관한 것들이다. 다른 회사나 정부가 안 도와준다. 이 쪽에 회사가 비용을 써야 한다. 그 비용이 Search Firm에게 지불해야 할 비용보다 적을 가능성이 높다.

 

이 글에서는 학교와 산업과의 접점에서 벌어지는 여러 일들에 어떤 준비가 필요한지에 대하여 정리해보고자 한다. 이 글의 기조는 학교와 회사 양쪽이 노력을 해야 한다는, 즉 양쪽이 의미 있는 자원을 투입해야 한다는 것이다. (전통적인 산학협력 R&D, 즉 산업에서 필요로 하는 신기술의 연구 개발을 교수를 포함하는 연구팀에 의뢰하거나 공동 수행하는 경우는 여기서 다루지 않고, 주로 취업 역량을 전제로 진행되는 산학협력 교육만 다룬다.)

 

(출처, 전주대학교 링크사업단)

이 글은 가능한 모든 고려 사항을 적극적으로 적은 것이다. 학교나 산업이 처한 여러 상황 상, 아래 내용 중에 틀렸거나, 좋은데 도저히 실행 불가능하거나, 다른 더 좋은 방법이 있는 경우가 많을 것이다. 이 글이 공유된 소셜미디어나 이 블로그의 댓글로 기탄없이 적어주시면 공감 가는 내용들을 적극 반영해드리겠다. 

 

취업 설명회

• 회사 : Job description을 준비하자. 학교가 제공하는 어떤 페이지에 올리거나 회사의 개발자 모집 공고 링크를 전달할 수 있겠다. 입사하면 만들 제품(서비스)과 그 안에서의 역할, 필요한 이론적 역량, 필요한 기술적 경험, 우대 기술/경험 (최근 여러 회사의 JD를 보면, 이 우대 조건을 도저히 신입 개발자는 경험하기 어려운 내용으로 채운 회사들이 정말 많다. 신입을 정말 뽑을 생각이 있다면, 너무 세게 쓰지 말자), 근무처/대략연봉범위/복지, 그리고 채용프로세스/예상소요기간, 회사정보 등등 기본 사항을 담자.
• 회사 : 취업 설명회에 인사/채용 담당자보다는 회사의 기술 스택에 익숙한 리더급 개발자를 보내자. 회사의 개발 프로세스, 사용하는 (오픈소스) 기술들, 현재 개발하고 있는 또는 개발 예정인 기술, 신입이 들어오면 팀 안에서 신입 주변에서 벌어지는 일, 사수가 하는 일, 개발자로서 느낄 수 있는 조직 문화를 설명하자, 그리고 학생들의 질문을 받고 답을 해주자. 이 장면에서 학생들에게 ‘내가 들어가면 성장할 수 있는 회사’라는 신뢰를 주어야 한다. 해당 학교 출신의 개발자가 동행하면 좋겠다. 가벼운 굿즈도 준비하고 단독 행사라면 현장 참여 학생들을 위한 간식을 준비할 수도 있다.
• 회사 : 현장에서 설명회가 끝나면 바로 관심이 있는 친구들을 면접 볼 준비를 하고 시간을 충분히 잡아서 간다.
• 학교 : 소프트웨어 학과라면 독자적인 취업지원 역량을 갖추도록 노력하자. 대학의 취업 지원 조직은 대개 ‘공사’, ‘은행’, ‘문과형 대기업’, ‘공채’에 특화된 조직이다. 개발자 취업 지원에 필요한 정보나 지원 체계가 부족한 경우가 많다. 궁극적으로는 세상 모든 직업이 소프트웨어 직업이 된다. 따라서 자체 역량을 키운 뒤, 대학의 취업지원 조직을 개발자 취업 지원을 잘 하는 쪽으로 바뀌도록 도와주자.
• 학교 : 학생들에게 취업 설명회 공지를 하고 이력서를 준비시킨다. 대부분 학생들은 이력서가 준비되어 있지 않다. 정말이다. 이력서를 저학년 때부터 쓰게 하고 지속적으로 업데이트시키자. 또 개발자 이력서 쓰는 법을 안내하자. 인터넷에 동영상도 많고, 좋은 템플릿도 많다. 또 개발자 채용 경험이 많은 개발자나 개발자 Search Firm의 리크루터를 초청해서 이력서 리뷰를 해주자.
• 학교 : 모의 면접을 해보자. 모든 면접은 피면접자에게 회사에 필요한 역량이 준비되어 있는지, 아니면 그런 역량을 빠르게 학습할 수 있는지를 확인한다. 그 확인을 위한 질문이 어떻게 나가는지 학생들이 직간접적으로 미리 경험하게 하자. 채용 면접 경험이 풍부한 (유명) 개발자를 면접관으로 초청하고 모의 면접 대상 학생을 선정하여 진행한다. 면접 과정을 녹화하거나 중계하여 모든 학생들이 보게 하자. 아주 효과가 좋다.
• 학교 : 학생들에게 취업설명회에 나올 회사(들)에 대하여 조사를 시키자. 미리 질문도 받아 회사 측에 전달하자. 그래야 면접 때 좋은 질문을 할 수 있다. 많은 면접관들은 자기 질문에 대답하는 것만큼이나 피면접자가 어떤 질문을 자기에게 하는지를 중요하게 생각한다.

 

인턴

 

취업과 달리 인턴은 회사에 갔다가 학교로 돌아오며, 교육기관 입장에서는 회사의 업무를 경험하는 인턴 과정이 교육의 일환으로서 학점 또는 다른 운영 요소와 연계되어 있기 때문에 더 정교한 절차가 필요하다.

 

• 회사 : 인턴 모집을 위한 홍보, 선발, 운영, 평가, 회고를 위한 예산을 확보하자. 인턴은 공짜 노동력이 아니다. 인턴 운영 예산에는 인턴에게 지급해야 할 인건비, 인턴을 지도할 사수의 (기회비용에 해당하는) 인건비를 포함한다. 다시 말하지만 인턴은 공짜 노동력이 아니다. 이 비용으로 인턴이 일을 해서 회사에 대한 인식 또는 회사의 제품/서비스 가치를 높일 수 있다면 정말 남는 장사이다. 그리고 그 인턴이 우리 기대에 부응하여 정직원이 된다면 채용 및 On-boarding 비용으로 인턴을 위해 쓴 예산이 아깝지 않다.
• 회사 : 인턴용 Job description을 준비하자. 보수나 복지 혜택을 제외하고는 위 직원 채용을 위한 JD와 크게 다르지 않다. 인턴과 직원을 거의 비슷하게 보자. 인턴 결과 채용으로 이루어지는 기준과 과정을 좀 더 기술하자.
• 회사 : 학생은 인턴을 하면서 회사를 정확하게 알아간다. 따라서 잘 해주자. 그들이 단기간에 스스로 성장함을 느끼게 하자. 이 회사가 여러 관점에서 자신이 성장할 수 있는 회사라는 확신이 있어야 인턴 후에 정직원으로 들어올 생각을 한다. 또 자기는 들어오지 않아도 다른 친구에게 이 회사가 좋다고 떠들어준다. 단 한 명이라도 우리 편인 만드는 것이 중요하다.
• 회사 : 인턴이 그의 롤 모델을 우리 회사에서 찾을 수 있게 하자. 인턴에게 붙여주는 사수가 그 롤 모델일 수도 있고, 더 높은 레벨의 개발자와 임원을 주기적으로 만나게 하여 배우고 싶고, 되고 싶은 롤 모델이 이 회사에 있음을 느끼게 하자.
• 회사 : 인턴을 평가하고 피드백하는 프로세스를 확보하자. 당연히 인턴이 작성한 코드도 리뷰를 해줘야 하고, 협업 개발의 일원이 되게 하자. 자주 피드백을 해줘야 소속감, 성취감, 성장감을 느낀다. 인턴은 독립적으로 일을 하는 프리랜서가 아님을 잊어서는 안 된다.
• 회사 : 인턴 선발을 신중하게 하자. 학교에서 보내주는 학생을 그냥 받지 말자. 그렇게 했다가 결과가 좋지 않으면 학생과 회사, 학교 모두에게 손해이고, 다음 인턴 선발 사이클에 학생들 지원이 없어진다. 인턴의 역량이 되면 정직원으로 채용한다는 생각을 가지고 직원 채용 수준에 근접한 서류 평가와 면접을 진행하자. 원래 개발자가 부족하다고 하지 않았나? 인턴 과정은 인턴을 하는 학생에게 큰 배움의 기회이고, 회사도 나중에 정직원이 될 가능성이 높은 개발자 풀을 더 잘 확보할 수 있다.
• 회사 : 인턴이 끝나고 자격이 충분하면 우리 회사에 오라는 정직원 채용 오퍼를 공식적으로, 진지하게 하자. 며칠 안에 오퍼가 갈 수 있다는 것을 미리 통보하자. 인턴 과정의 피드백과 함께 같이 보내는 것이 좋다. ‘올래?’ 이렇게 말하는 거 말고, 정직원 합격 때 보내는 채용 오퍼 문서를 정중하게 보내서 정말 뽑고 싶다는 진정성이 있음을 보여주자.
• 학교 : 학생들에게 인턴 모집도 취업 설명회와 거의 같은 수준으로 준비시키자.
• 학교 : 취업과 달리 인턴은 2-3개월 후에 돌아온다는 것을 가정하는 교육의 일환이다. 따라서 그 기간에 뭔가를 배워야 하는 것이 큰 전제이다. 학생들 스스로는 숙제가 아닌 새로운 프로젝트를 하면 배웠다고 착각하기 쉽다. 배움은 문제를 이해, 정의하고 해결책을 찾아 실제 구현하고 발표하는 경험을 단계별로 리뷰받고 개선하는 과정에서 이루어진다. 인턴 과정에서 리뷰와 피드백을 경험하고 있는지 확인해야 한다.
• 회사 : 인턴은 학생의 역량(aka. 노동력)을 회사에 무상 제공하는 제도가 아니다. 학생들은 자신의 기여분에서 교육(지도)을 받는 만큼의 수업료를 뺀 임금을 받아야 한다. 회사가 지불할 수도 있고, 정부의 지원금일 수도 있지만 학생들은 임금을 받아야 한다. 전문적 역량이 돈과 어떻게 교환될 수 있는지를 배우는 것도 큰 의미가 있다. 노동법상 애매한 부분이 있지만, 실습생에게도 근로자성이 인정되면 당연히 최저임금 이상의 인건비, 4대 보험 등이 제공되어야 하는 것이 원칙이다.
• 학교 : 인턴은 회사 주도 프로그램이지만, 교육 행위의 일부임을 명확하게 한다. 회사의 인턴 운영 프로세스가 없거나 부족한 것 같으면, 인턴을 받는 회사와 R&R를 명확하게 하는 계약서에 가까운 문서를 만들어 공유하자. 이 문서에는 시기별로 회사에서 학교로 전달되어야 할 평가지, 학생/사수/학교/회사가 인턴 기간 동안 해야 할 일들을 명확하게 적도록 하자.
• 학교 : 인턴을 갔다가 돌아온 학생들이 회고를 하는 시간을 공식적으로 갖도록 하자. 인턴을 갔던 회사에게도 이런 회고 모임이 사후에 있다는 것을 먼저 알리고, 회고 후 해당 회사에 대한 내용을 피드백 하자. 회사들도 더 좋은 인턴 프로그램을 운영하기 위한 여러 목소리와 제안을 기다리고 있을 것이다. 또 아직 인턴 경험이 없는 학생들도 참여시켜 인턴을 간접 경험하게 하고 인턴 참여 의지를 높이자.

 

학생 프로젝트에 대한 현장 개발자 멘토링

• 학교와 회사 : 회사의 현업 개발자 참여 모드를 협의한다. 학교에 여러 프로젝트 팀이 있는 경우 팀별로 다를 수도 있다. 필요하면 우선 경력이나 직군 등 멘토의 자격을 정한다. 참여 모드에는 다음과 같은 것이 포함될 수 있고, 일부는 팀과 멘토가 협의해서 정할 수 있다. 팀이 실제 작업을 하는 장소(회사, 학교, 기타), 팀과 멘토의 미팅 장소(회사, 학교, 온라인, 기타) 및 주기 (예, 주 1 회), 멘토 / 팀(원)의 미팅 보고서 작성 주체와 주기, 멘토링의 범위 (멘토가 모든 것을 다 알 수는 없기 때문에, 저절로 한계가 정해지겠지만, 그 범위를 벗어날 때 사내의 다른 멘토를 소개해준다거나 - 아래 멘토의 역할 참조), 멘토에 대한 보상 (무상, 시간당 ??원의 전문가 활용비 지급, 교통비만 지급, 보상을 득하기 위해 필요한 서류와 처리 절차 등.)
• 학교 : 학생들이 하고 싶은 프로젝트 주제와 생각하는 개발 방향을 수집하고 이 팀을 멘토링 해줄 회사 또는 멘토링을 하고자 하는 개발자 분들에게 전달하여 팀-멘토 매칭을 한다. 멘토의 프로필을 공개하고 학생들이 멘토를 선택하는 방식을 취할 수도 있다. 팀당 멘토 한 명만 허용할 때, 팀에 대한 경쟁 또는 멘토에 대한 경쟁이 있다면 경우 해소할 규칙을 정한다. 당연히 한 팀에 여러 멘토가, 또는 한 멘토가 여러 팀을 멘토링 할 수도 있다.
• 학교 : 학생들에게 멘토의 역할을 어디까지 기대할 수 있는지와 멘토링 받을 때 필요한 Paperwork들에 대하여 설명한다.
• 학교 : 멘토를 위한 가이드를 만든다. 교육기관의 특성에 따라 Dos and Don'ts가 다를 수 있다. 질문에 대답만 하는 것, 더 많은 Resource를 멘토가 알아서 제공하는 것, 강의 수준의 도움을 주는 것, 코드나 문서를 리뷰하는 것, 코딩에 참여하여 직접 도와주는 것 등을 권장하겠지만, 일부는 제한할 수도 있고, 그냥 멘토에게 맡길 수도 있다. 하지만 멘토가 할 수 있는 행위들에 대한 정리가 필요하다. 또 멘토에게 주기적인 보고서와 팀에 대한 평가 문서를 제출받는 것이 보통이기 때문에, 그 작성 가이드도 필요하다. 멘토는 귀한 분들이다. 그들이 쓰는 시간을 줄여줘야 한다.
• 학교 : 멘토에게 제공할 (객관적인) 학생 정보를 준비하고, 이력서 수준 또는 자기소개서를 학생들이 직접 준비하도록 한다. 멘토가 학생에 대하여 더 잘 파악하고 있을수록 더 잘 도와줄 수 있다. 필요하면 교육 기관의 학생관리 시스템에 멘토가 직접 접근할 수 있게 하여, 학생에 대한 학습 history, port folio를 멘토가 볼 수 있게 한다.
• 학교 : 학교 주도의 프로젝트에는 팀별로 담당 교수가 있다. 담당 교수의 역할이 무엇인지 멘토와 학생에게 고지한다. 또 어떤 결정 사안에 대하여 학생, 담당교수, 멘토의 생각이 다른 경우 최종 콜은 누가 하는지 정해 알린다 (통상 학생이다.)
• 회사 : 회사는 사내 개발자들에게 이런 프로그램이 있고 ‘업무의 일부’로서 ‘~~ 교육기관과 학생 프로젝트에 대한 멘토링을 할 개발자를 모집함’을 알린다. 자원자를 받을 수도 있고 할당을 할 수도 있겠다. 이런 프로그램의 목표는 첫째, 똘똘한 학생을 미리 알아보고 찜하기 위하여. 둘째, 우리 회사에 이런 훌륭한 개발자가 있다는 것을 학생들에게 보여주기 위하여, 셋째, 우리 회사가 기술적 혁신을 추가하는 좋은 회사임을 알리기 위하여, 넷째, 우리 기술이나 데이터, 또는 서비스에 익숙한 학생들을 만들어 학생들이 직장으로 우리를 선택할 가능성을 높이는 것 등이다.
• 멘토 : 개인 자격의 멘토를 포함해서 멘토는 첫 미팅에서 자신이 도와줄 수 있는 범위를 명확하게 한다. (흔히 고객/사용자 관점에서 기획이라고 퉁쳐서 말하는) 프로젝트 방향성의 설정, (흔히 학생들은 설계라고 하는) 프로젝트의 기술적 접근 방법, (팀의 진행 상황 공유와 필요시 개입을 위한) 협업 방식과 도구의 제안, 코드 리뷰, 문서 리뷰, 팀원 수준으로 아니라도 코드의 일부 작성 또는 트러블 슈팅, 매니저 역할의 일부 (초기 작업이나 이슈의 배분, 일정 관리 등)이다. 물론 자신이 도와줄 수 있는 범위를 벗어난 경우, 도움을 줄 다른 훌륭한 분을 학생들에게 소개해주는 것은 언제나 환영받을 일이다.

 

회사 프로젝트에 학생들의 (학교에서, 회사에서) 참여

 

이 방식은 프로젝트 주제를 학생이 아닌 멘토가 속한 회사에서 지정한다는 점에서 위의 '학생 프로젝트에 대한 현장 개발자 멘토링' 프로그램과 다르고, 완전히 상관없지는 않겠지만 취업을 전제로 유급으로 회사 일을 하는 '인턴' 프로그램과도 다르다. 이 프로그램은 회사가 대학의 현장형 교육에 참여함으로써 채용 후보를 만날 기회를 늘리고, 회사가 기술적으로 문화적으로 좋다는 인식을 심어주기 위함이다. 물론 이 과정의 참여 학생 가운데 회사에 필요한 역량을 가진 학생들에게 인턴 또는 정직원 오퍼를 할 수도 있다.

학생 팀이 수행할 프로젝트 주제를 회사가 지정한다는 의미에서 학생들 생각한 주제보다는 훨씬 더 고객에게 가까운 프로젝트이므로 '현장형 교육'이라는 취지에 더 적합하다. 대부분의 고려 사항은 '학생 프로젝트에 대한 현장 개발자 멘토링'과 유사하다. 추가적이거나 다른 부분은 다음과 같다.

 

• 회사: 이 산학협력은 자선사업이 아님을 명확하게 인식하자.
• 회사 : 학생들과 수행할 과제를 신중하게 설정하나 고른다. 신중해야 하는 이유는 이 프로젝트 수행 최우선 목표가 교육인지라, 사내 개발자 수준의 R&R을 학생들에게 부과하기 어렵다는 것이다. 즉, 실패했을 때 Risk가 있는 과제는 이 용도로 적합하지 않을 수도 있다는 의미이다.
• 회사 : 이 사업이 있다는 것과 학생들과 해보면 좋을 프로젝트를 각 팀이 제안하라고 사내에 알린다. 자발적으로 참여할 팀이 많으면 좋으나, 그렇지 않은 경우 할당을 할 수도 있겠다. 이런 형태의 산학협력은 회사의 리크루팅/홍보 등의 관점에서 중요함과 업무의 일부라는 것을 설파하자.
• 회사 : 참여 학생들의 시스템 접근 권한을 결정한다. 회사의 프로젝트를 하기 때문에 회사의 (공통) repository를 보거나 이용할 수도 있고, 그것을 막을 수도 있다. 큰 회사들은 권한 부여와 회수를 위한 정책과 시스템이 잘 갖춰고 있는 경우가 많지만, 작은 회사는 그렇지 않을 수도 있어 결정이 필요하다.
• 학교와 회사 : 이 과정의 목표가 '교육'임을 양측이 명확히 한다. 회사에게도 도움이 되어야 하지만 이 과정을 통해 학생들의 (기술적) 성장이 이루어져야 함이 가장 중요하다. 이 목적이 달성될 가능성이 없거나 훼손될 때 과정을 중간에 중단할 수 있음을 서로 인식하자.

• 학교와 회사 : 대학의 경우, 이 과정을 수업의 일환으로 할 수 있다. 한 학기 또는 한 달 정도의 기간을 정해 회사의 개발자가 자사의 기술, 데이터와 관련된 강의를 하고 해당 강의의 과제 성격으로 프로젝트를 하는 방식으로 진행할 수도 있다.
• 학교 : 이 협력 과정에 혹시 지도교수가 있다면 해당 지도교수의 역할을 회사와 학생들에게 이야기한다.
• 학교와 회사 : 팀별로 회사별로 회사의 팀별로 다르겠지만, 학생들이 작업을 하는데 필요한 장비와 비용 부담을 누가 할지 정한다. 학생들이 개발에 사용할 장비(대개는 노트북)를 어떻게 조달할지 결정한다. 또 개발에 부품 구매 등 소모성 비용이 드는 경우 그 비용 부담 주체도 정한다. 교육 기관의 경우 학교 자체 예산 또는 정부 사업으로 이런 산학협력 과제에 쓸 예산이 있는 경우도 있지만, 그 예산이 많지 않고 예산 사용에 따른 paper work도 복잡해서 과제 진행에 방해가 되기도 한다..
• 학교 : 학생들의 작업이나 담당 멘토와의 미팅을 위한 공간은 학교여도 좋고, 주기적인 회사 출퇴근, 기타 등 어디여도 좋다. 회사 또는 팀 단위로 협의를 한다. 그전에 '특별한 이유가 없다면 회사의 공간에서 개발을 한다' 같은 기본적인 정책을 마련하고 회사와 팀별로 결정한다.
• 회사 : 인턴의 경우 그 기간 동안 확실한 소속감이 있지만, 이런 기업 프로젝트 수행 과정은 그보다는 약할 수밖에 없다. 하지만 회사의 프로젝트를 수행하는 것이므로 참여 학생들에게 소속감을 주기 위한 것들 (출입카드의 발급, 소소한 굿즈의 제공, 회식 참여 등)은 학생들의 소속감을 높여 회사에 대한 좋은 인식을 강하게 남길 수 있다.
• 학교 : 프로젝트의 ownership이 회사에 있으므로, 학생들로부터 주기적인 진행 상황 보고를 받는다. 학생들이 과정의 취지를 크게 벗어나 회사에서 당연히 '돈을 받고 해야 할 만한 일'을 멘토링이나 피드백 없이 진행하는 경우나, 학교와 회사가 처음 합의했던 R&R이 전혀 지켜지지 않아서 교육이라는 이 과정의 목적을 달성하기 어려운 경우, 적극 개입하여 조정하거나, 과제를 중단하는 등의 조치를 취한다. 또 이런 중단을 결정할 수 있음을 회사에 사전에 알려야 한다.
• 학교 : 이 과제의 마감될 때, 회사 측에서 학교로 참여 학생에 대한 평가 보고서를 어떤 형태로 보낼지 회사에 공유한다.

 

산학 협력, 어렵다. 특히 늘 인력이 부족하다고 느끼는 '산'쪽에서는 협력에 인력이 들어가기 때문에 더 어렵게 느낀다. 하지만, 산학 협력은 기업의 의무나 자선 사업이 아니다. 좋은 인재를 뽑고, 좋은 인재를 키우는 사내 문화를 만드는 지속 가능한 투자이다. 그리고 교육 기관 입장에서는 학생들에 대한 부가서비스가 아니다. 원래 해야 하는 일이다. 즉, 누가 봐도 산학 협력은 필수인 것이다. 

 

당연히 해야 하는 것이라면 모든 산학협력 행위의 운영 목표는 생산성이어야 한다. 이전의 산학 협력은 특정 교수(또는 강사, 교육 운영자)의 네트워크 역량에 의존하는 경우가 많았다. 그 방식은 지속 가능하지 않다. 누구든 운영이 가능하도록 매뉴얼화해야 한다. 특히 학생 수가 많거나 회사가 많아질 때, 운영비용이 비례해서 증가하지 않도록 시스템화를 해야 한다.

 

잘 하자.

 

*

 

Disclaimer: 이 글은 글쓴이의 개인적 의견이며, 글쓴이가 속한 조직의 의견이 아닙니다. 여기 기술된 방법들이 잘 적용될 수 있는 회사도 있고, 위 방법에는 제시되지 않는 완전히 다른 방법이 큰 효과를 볼 수도 있을 것입니다. 이 글과 다른 의견, 제안이 있으시면 아래 댓글이나 이 글이 공유된 다른 미디어에 댓글로 제시해주시면 검토 후 글에 반영하도록 하겠습니다.