“실패해도 괜찮아” 라고 말하지 않기로 했습니다

더 보기 편한 링크는 이 곳을 눌러주세요

개발의 끝에 마주한 평가

개발을 하는 것을 옆에서 지켜볼 때면, 가장 많이 받는 요구 중에 하나가 바로 “이 정도면 충분한지” 입니다.

“리이오 이정도로 코드를 짜면 괜찮을까요?”, “이정도면 완성이라고 볼 수 있는 건가요?” 그리고 저 역시도 이러한 질문에는 항상 비슷한 대답을 할 수 밖에 없었습니다.

“이 부분은 고민을 정말 많이 한 흔적이 보여서 좋아요.”, “여기는 좀 더 고민하면 좋아지겠는데요?” 그리고 그들은 저의 대답에서 둘 중의 하나의 경험을 합니다. 바로 “합격” 아니면 “불합격” 입니다.

평가가 아닌 실험

사실 합격과 불합격은 시험이나 평가 뒤에 따라오는 행위입니다. 배우는 사람은 스스로를 평가할 필요는 있지만, 남에게 평가받아야만 배움이 남는 것은 아닙니다.

그래서 이제부터는 다르게 질문하고 다른 질문을 요구하려고합니다.

“이 정도 코드를 짜면서 무엇을 배웠어요?”

“다음에 또 이걸 한다면 다르게 해 볼 수 있는 부분은 어떤게 있어 보여요?”

“본인이 느끼기에 최선을 다했나요?”

사실 위의 질문들은 회고의 질문들과도 맞닿아 있습니다. 마찬가지로 회고에서도 한 프로젝트의 평가를 하지 않도록 가이드 해야겠다는 생각을 했습니다.

새로운 방향성

결국 배움의 과정에서 평가를 하지 않고 개선을 생각하게 함으로 그들은 그들의 배움에 실험을 계획할 수 있고, 그 실험에서 자신이 무엇을 배웠는지를 인지하고 무엇을 배우지 못했는지도 인지할 수 있습니다.

이 모든 일은 “실패해도 괜찮아.”, “지금 마음껏 실패해.”라는 말이 실패해도 괜찮은 분위기와 문화를 만들 수 있을 것 이라는 믿음이 부서지면서 생긴 의문에서 출발한 탐구였습니다.

  • 왜 실패 해도 괜찮다고 했는데, 기를 쓰고 성공하려는 걸까?
  • 실패해도 괜찮다고 느끼게 하려면 어떤 것들을 제공해야할까?
  • 애시당초 실패해도 괜찮은게 맞기는 한건가?

이러한 질문들의 결과는 “실패는 해도 괜찮아는 동작하지 않는다” 이고, 그래서 배우는 사람은 성공과 실패의 잣대위에 올라가 있는 것이 아닌. 가설의 검증과 새로운 가설의 수립의 판 위에 올라와 있다고 느끼게 해주는 것 입니다.

정리

저의 틀린 가설인 “실패해도 괜찮다고 말 해주면 괜찮을 것이다.” 를 버리고. 새로운 가설인 “실패가 아니야 실험이야”를 검증해보려고 합니다.

더 많은 것들을 효율적이고 자발적으로 배울 수 있도록 만드는 방법을 고민해보겠습니다.

댓글

이 블로그의 인기 게시물

[IOS] AppDelegate는 뭐하는 녀석이지?

[git] git의 upstream과 origin 헷갈리는 사람 손!

[git] Github 이슈 라벨(issue labels)