소프트웨어 개발자, 신입사원 교육. 어떻게 해야할까?

팀 (출처 : Pixabay)

교육.

교육은 어렵다.

내가 성장하는 게 아니라, 남을 성장시키는 것이기 때문이다.

스스로 하지 않으면 아무리 옆에서 잘해줘도 소용이 없다.

 

옛날에는 답답했다.

일이 너무 많고 바빴다.

그래서 내가 직접했다.

가르칠 시간이 없었다.

 

그랬더니 여전히 나 혼자서만 일하게 되었다.

2명 이상 해야 하는 일이 오면 못한다고 튕겨내거나,

1달치 일을 2달로 늘려 잡았다.

병렬방식이 아니라 직렬방식으로 일한 것이다.

 

1년쯤 되니까 죽을 것 같았다.

올해 한 것을 내년에도 반복한다고 생각하니, 갑자기 암울해졌다.

나는 계속 도전하고 변화하고 싶었다.

이런 건 나랑 맞지 않았다.

 

대타를 길러야 했다.

어쩔 수 없이 교육이란 걸 시작하게 되었다.

 

가르치면 돼 ?

처음엔 적당한 사람을 데려다 놓고 가르쳤다.

그런데, 태도가 안 좋았다.

10을 가르치면 2정도의 일을 했다.

"사람은 가르치면 변해."

내 믿음에 오기가 붙었다.

가르치다가 홧병이 날 정도였다.

으르기도 하고, 달래기도 했다.

변하는 건 잠깐.

결국 제자리로 돌아왔다.

 

왜일까?

술을 사주면서 깊은 대화를 했다.

 

"그렇게까지 잘하고 싶은 생각이 없어요."

이게 핵심이었다.

 

불성실한 게 아니라 별 생각이 없었던 거다.

그렇다, 그 친구가 나쁜 게 아니었다.

"태도의 문제"가 아니라 "동기의 문제"였다.

"태도"는 결과였을 뿐이다.

 

"월급" 받으러 온 직장인에게 "열정"을 부탁할 순 없었다.

동기를 만들어주는 것은,

내 숙제이기도 했지만 회사의 숙제였다.

물론 그 친구의 숙제이기도 했다.

 

하지만 동기는 쉽게 만들어낼 수 없다.

나혼자서 만들 수 있는 것도 아니고,

남의 동기를 내가 만들 수 있는 것도 아니다.

 

일을 시키려니 "정리되지 않은 복잡한 일"을 줄 순 없었다.

"정리되고 단순한 일"을 줘야만 했다.

하지만 그렇게 정리된 일은 회사에 없다.

내가 그렇게 만들어야 했다.

휴우 ~

 

그렇게 만드느라고 내 일을 거의 하지 못했다.

초보자 1명치 일을 베테랑 1명과 초보자 1명이 매달리고 있다.

덕분에 내가 해야할 일이 빵구가 났다.

그래서 다른 일도 빵구가 나기 시작했다.

 

...

이런 관계를 오래 지속하긴 어려웠다.

아쉽게도 그 친구가 다른 곳으로 갈 수 있게 도와주었다.

 

채용

그 이후로는 사람뽑을 때 태도를 보았다.

인사를 잘한다던지, 공손한 말투를 본다는 게 아니다.

"동기"가 있는지 본다는 거다.

그 동기가 우리와 비슷한지 본다는 거다.

100% 맞을 순 없다.

50% 만 맞으면 아주 잘맞는거다.

아니 40%만 맞아도 일은 할 수 있다.

부모자식간에도 마음이 틀리고,

부부간에도 마음이 다르다.

회사에서 40% 맞으면 엄청 잘맞는거다.

 

교육

처음엔 뒤따라 다니면서, 일일히 코치 했다.

내 일이 두배로 늘었다.

죽을 것 같았다.

 

어느 순간 마음을 좀 놓았다.

너무 힘들어서 말이다.

그랬더니 그 친구가 뭔가를 알아서 해왔다.

아, 내가 과잉 친절했구나.

그게 이 친구를 망치고 있었구나.

 

태도가 나쁜 친구 때 썼던 방식을

나도 모르게 이 친구에게 쓰고 있었다.

옛사랑이 한 잘못을, 새사람에게 꾸짖고 있는 느낌이었다.

내가 좀 찌질했다.

 

나를 리셋했다.

그에게 과제를 내고, 따라 오는지 보았다.

과제가 끝나면, 함께 내용을 체크하고 상용서버에 올려주었다.

100점짜리는 없다.

60점만 되어도 올려주었다.

그리고는, 이걸 어떻게 고쳐나가야 하는지 알려주었다.

수정 배포 전에는 나와 함께 보게 했다.

 

서로 점점 익숙해져갔다.

교육에 대한 나의 부하는 점점 줄었다.

그러면서, 상용서버 배포도 스스로 하게 시켰다.

다만 몇가지 원칙과 팁들을 가르쳐줬다.

 

오류가 나면 어떻게 대처해야 하는지,

어떻게 원복을 시켜야 하는지

하나 둘씩 준비하게 했다.

그렇게 상용서버의 접근통제 및 관리권한도 넘겨주었다.

 

빠른 친구는 3개월, 아닌 친구는 6개월 정도 걸렸다.

훌륭하게 새로운 멤버로 밥값을 했다.

6개월이 지나도 적응 못하는 친구도 있었다.

깊은 면담을 했다.

일에 대한 철학이 회사와 다른 경우가 많았다.

 

마음 안가는데 일을 시킨다면, 감시하듯 일해야 한다.

1명 일을 2명이 하는 것일 뿐 아니라 서로에게 힘들다.

못할 짓이다.

그렇게 한다고 점점 나아질거라는 보장도 없다.

 

신입사원

대학을 갓나온 친구들은 부담스럽다.

그 친구도 부담스럽겠지만 조직도 부담스럽다.

조직이 그 친구에게 할애할 시간이 많지 않기 때문이다.

어쨌든 시작은 해본다.

 

우선 간단한 통계프로그램을 짜게 한다.

조회만 있고, 데이터를 변경하거나 쌓을 일이 없기 때문이다.

실패하더라도 현재 돌아가는 시스템에 영향을 주지 않는다.

실패하면 그대로 냅두거나 걷어내면 된다.

 

이 일은 코드는 간단한데, 업무는 그렇지 않다.

통계를 짜려면 시스템을 전체적으로 이해해야 한다.

어떤 데이터가 쌓이고, 어떤 기준으로 쌓이는지도 알아야 한다.

어떤 업무가 어떤 업무에 의존적인지도 알아야 한다.

 

보고 싶은 데이터를 추리다보면,

현재 데이터를 클렌징할 일도 생긴다.

자르고 붙이면서 가공해야 한다.

당연히 선임한테 설명을 들어야 되고,

옆부서 담당자와도 이야기해야 한다.

 

통계짜는 일을 부탁했는데,

대화없이 혼자 책보고 공부하면 난감하다.

선임한테 묻고 현재 시스템 공부하라고 내준 숙제인데,

Java Spring 책만 보고 있으면 정말 난감하다.

 

뒷담화에 우루루 몰려다니는 것도 난감하다.

사소한 일 시켰다고 불평하고만 있으면 난감하다.

알게된 레거시 허점을 히죽거리고 다니면 그것도 난감하다.

 

사실 그거 해결하려고 신입사원을 뽑았는데,

자기 일도 안하면서 불평하고 있으면 정말 난감하다.

 

지나가는 열병일 수도 있으니 기다려준다.

매주 상태가 악화되면 난감하다.

문제를 같이 풀자고 뽑은 친구인데, 

일을 안하면 누군가는 2배로 일을 해야 한다.

미워서가 아니라, 조직이 못받아준다.

 

성장

교육결과는 작더라도 선임일을 덜어가는 거다.

선임 일을 대체할 정도가 되면, 기존 시스템에 대해 모르는 건 없게 된다.

새로운 걸 붙일 때

어떻게 만들어야 할지 의견개진을 해도 헛소리가 아니게 된다.

 

선임도 알게 된다.

자기가 하던 일이기 때문에 쉽게 알 수 있다.

코드 검증도 자연스레 하게 된다.

큰 노력을 들이지 않아도 허점을 쉽게 발견할 수 있다.

 

선임도 말하기 편하게 된다.

왜 메모리DB를 도입해야 하는지

어떤 기술을 쓰게 될지,

어떻게 코드를 짜올려야 할지,

일정이랑 업무량이 어떻게 될지,

누구 일을 빼주고, 누가 일을 해야 할지,

굳이 회의실에서 2시간씩 회의하지 않아도

일상 대화를 통해 결정할 수 있게 된다.

 

이 정도 되면 교육이라고는 할 수 없다.

하지만, 책에 나오지 않는 내용일뿐 분명한 교육이다.

 

1년정도 이렇게 한 싸이클을 같이 돌면, 믿음이 생긴다.

 

팀원이 된다는 것

팀원이 된다는 건, 서로의 허점을 보완해줄 수 있다는 뜻이다.

큰 일을 나누어서 처리할 수 있다는 뜻이다.

내가 맘 놓고 잠깐 자리를 비워도 좋다는 뜻이다.

 

사실 이 상태가 되어야 "교육"이 끝난다.

짧으면 6개월, 길면 1년 걸린다.

 

러닝커브가 현저히 떨어지고,

말귀를 못알아 듣는 친구라면 모르겠지만,

대부분 이 정도 기간 안에 적응한다.

 

3년 법칙

좋은 육성문화를 가지고 있더라도 팀이 4-5년씩 유지되진 못한다.

진급도 해야 하고, 회사 규모도 커지기 때문이다.

다른 회사에서 더 비싼 연봉을 부르기도 한다.

연봉방어를 해줄 수 없다면, 어쩔 수 없이 놓아줘야 한다.

 

경험상 드림팀은 3년 정도 되니 흩어진다.

일잘하는 팀장이었다면, 임원으로 진급해있을거구.

일잘하는 과장이었다면, 팀장으로 진급해있을거다.

일잘하는 팀원이었다면, 어딘가 비싼 연봉에 팔려가 있을 것이다.

 

소스코드 백업해둬봐야 2-3년이면 확 바뀐다.

좋은 팀에 들어왔다면, 일 잘하는 스킬을 배워가는 게 좋다.

업무 규모가 커지면 어떻게 일하는지,

연구해야 하는 일은 어떻게 시작하고 어떻게 끝을 맺는지

눈여겨서 배워두는 게 좋다.

 

좋은 코드는 github 과 인터넷을 통해서 배울 수 있다.

개발능력은 로직이나 이론으로 배워가는 게 좋다.

 

하지만, 역시 솔루션은 "문제현장"에서 움직이는 어플리케이션들이다.

그 현장에 있는 것만으로 배우는 건 많아진다.

 

팀문화

"개발문화가 좋은 회사에 취직해."

"그런 회사가 어디 있니?"

 

개발문화를 "CEO의 정책"으로 이해하는 사람이 있다.

영어이름쓰기, 자율출퇴근제로만 이해한다. 

모르면 그럴 수도 있다.

 

혹은 "강의"로 이해하는 사람이 있다.

실리콘밸리에서 이렇게 해요.

정보수집용으로는 맞다.

 

하지만, 개발문화는 "실천"이다.

교육과 성장은 "실천"이 만든 분위기에서 이루어지는거다.

그런데, 그건 한 사람이 모두 만드는 거 아니다.

서로 도와야 한다.

 

밖에서 알 수 있을까?

모른다.

들어가보거나 들어가본 사람들 평을 듣는거다.

 

※ 

이런 스토리와 아주 거리가 먼 현장도 많다.

그리고 이것만 정답은 아니다.

좋은 곳도 있고, 나쁜 곳도 있다.

하지만 여기선 스킵하자.

 

끝.