부족한 후임 교육 어떻게 시키세요?

매일 혹은 정해진 시간에 코드를 리뷰합니다.
함께 리뷰할 여력이 안 되면, SCM을 쓰시면 좋습니다.
매일 로컬 사본을 업데이트 하면서, 업데이트된 내용을 보면 파악이 어렵지 않습니다.
(커밋 주기나 커멘트 등 커밋 습관을 바로잡아 줄 수도 있고...)
이렇게 리뷰 하면서

1) 구조가 이상하거나 괴상한 코드를 만들어 낸다 -> 문제를 정확히 짚어 줍니다.
2) 같은 문제가 또 발생한다 -> 저번에 알려 준 문제를 바탕으로 스스로 풀게 합니다. 못 풀면 바로 답을 알려주지 말고 옆에 붙어서 어떻게 풀려고 했는지를 따라가면서 푸는 방법을 알려줍니다.
3) 조금 미흡하지만 해결하려고 노력한 게 보인다 -> 지나친 수준 미달이 아니라면 셋에 두 번은 적당히 넘어가는 식으로 긴장을 조금씩 완화(?)하면서 간간히 문제점과 더 나은 방법을 제시합니다. 물론 본인이 별 스트레스 안 받고 알려주는 사람도 안 피곤하다면야 보이는 족족 알려주면 좋지만요 ㅡㅅㅡ

이때 관리자 입장에서는
- 알려 준 내용을 잘 활용하는지(지적할 사항이 점차 줄어드는지)
- 이렇게 알려주는 것을 자기 발전에 도움이 된다 생각하고 달갑게 받아들이는지
를 확인할 필요가 있습니다. 이 두 가지가 되지 않는 사람은 추후 계속 함께 일하기가 정말 어렵습니다.

이 두 가지가 되는 사람이라면 알려 줄 것은 알려주되, 비 권위적인 자세로 임하는 게 좋습니다. 무슨 소리냐면 이렇게 지적을 하다 보면 지적하는 내가 반드시 가장 옳은 답이 아닐 수도 있고 듣는 입장에서는 그런 의도로 작성한 코드가 아닌데 억울하게 듣는 소리가 있을 수도 있습니다. 혹은 후임이 작성한 코드가 다른 면까지 고려했을 때 최선의 방안일 수도 있고, 그리고 내가 과거에 했던 이야기를 잊어버리고 다른 이야기를 하게 되거나 하는 수도 있습니다. 이 경우 호통을 치다가 얼버무리면 모양새가 좋지 않겠지요.(...) 처음에 문제점을 지적하는 입장과 이유를 명확히 알려주고 토론의 자세로 임하다 보면 나중에 배우는 경우도 생깁니다(!).

그리고 제 경험으로는 처음부터 마인드의 문제로 보는 것은 별로 좋지 않습니다. 어느정도 경계는 해야겠지만, 그렇다고 처음부터 이런 이야기를 해야지 하면 자칫 경험 부족에서 나올 수 있는 어떤 실수도 다 마인드 문제로 보일 수가 있습니다. 닥달한다고 갑자기 뇌의 숨겨진 구석에서 프로그래밍 지식 같은 게 튀어나오고 하지 않습니다. 모르는 건 가르쳐 줘야 합니다. 다만 같은 실수가 반복되는데도 본인이 별 노력이 없어 보인다 싶으면 그때 비전이나, 평소의 시간 활용 같은 좀 사적인 이야기로 넘어갈 수는 있겠습니다. 물론 사람마다 가장 적합한 방법이 분명 따로 있기는 할 겁니다만 (...)

그리고 위에 언급하신 경고창이나 escape 처리의 경우, 개발 가이드가 부재한 상황으로 보이는데요. 혹 분명히 문서에 명시 되어 있는데도 무시한다면 이 역시 알려주고 바로잡을 필요가 있습니다.

쓰고 보니 위에서 다 나온 이야기만 한 것 같군요. 어디까지나 제 스타일입니다. 욕설과 망신을 번갈아 주면서-_- 깨우쳐 주는 경우도 있다고 들었습니다만 제 경우는 받은 적도 준 적도 없고 앞으로 할 생각도 없어서 모르겠습니다.