실패를 용인하는 평가제도, 실제로 가능할까

평가를 잘 받으려면 실패하지 말아야 한다고 생각하시나요? 저도 한때는 그렇게 생각했습니다. 그런데 HR 업무를 10년 넘게 하면서 오히려 그 반대 방향의 제도를 직접 설계해본 경험이 있습니다. 실패를 기록하고, 거기서 작은 성공을 뽑아내고, 그것을 평가에 반영하는 파일럿이었습니다.

이게 말이 되는 소리냐고 하실 수 있습니다. 저도 처음엔 반신반의했으니까요. 그런데 계기가 있었습니다. 우리 팀이 먼저 시도했다가 초기 실패로 폐기한 아이디어를, 다른 조직이 나중에 잘 풀어서 성공시키는 걸 눈앞에서 본 겁니다. 아이디어가 나빴던 게 아니라, 풀어내는 방식이 달랐던 것이었습니다.

실패를 모아두는 것만으로는 부족하다

처음에는 단순하게 접근했습니다. 실패한 것들을 모아두는 공유 폴더를 하나 만들었습니다. 이름도 거창하게 붙였고, 팀원들한테 기록해달라고 요청도 했습니다. 그런데 예상보다 더 빠르게 유명무실해졌습니다. 폴더에는 파일이 쌓이는데, 무엇이 있는지, 왜 실패했는지, 어디까지 시도했는지를 아는 사람이 없었습니다.

이 경험이 오히려 더 명확한 방향을 잡게 해줬습니다. 실패를 기록하는 것과 실패를 활용하는 것은 전혀 다른 문제라는 걸 알게 된 겁니다. 많은 조직이 "실패를 두려워하지 말자"는 구호를 내걸지만, 정작 실패를 어떻게 다룰지에 대한 구조는 만들지 않는 경우가 많습니다. 구호와 제도는 별개입니다.

KDI 한국개발연구원에서도 혁신 촉진을 위해 실패 정보의 공유와 체계적 축적이 중요하다는 점을 언급한 바 있습니다. 실패를 자산으로 만들려면 검색 가능한 데이터로 바꾸는 작업이 선행되어야 한다는 방향성은 저도 그 과정에서 직접 체감했습니다.

Small Success를 평가에 연결하는 구조

그래서 고안한 방식이 이렇습니다. 실패 그 자체를 보상하는 게 아니라, 실패 과정에서 나온 작은 성공(small success)을 발굴하고, 그것을 포상하고 데이터화하는 것입니다. 이 작은 성공들이 쌓이면 다음 시도의 기반이 됩니다. 그리고 이 과정 전체를 평가 항목에 반영했습니다.

제가 직접 운영해보니, 이 제도가 잘 돌아가려면 최소한 아래 세 가지가 갖춰져야 한다고 느꼈습니다.

과제의 범위와 목적이 사전에 명확히 정의되어 있어야 합니다. 뭘 시도했는지가 기록되지 않으면 small success도 뽑아낼 수 없습니다.
평가자가 실패의 맥락을 이해할 수 있어야 합니다. "결과가 안 좋았다"와 "의미 있는 시도였다"를 구분하는 기준이 필요합니다.
포상이 형식적이지 않아야 합니다. 구성원이 체감하지 못하는 보상은 제도를 껍데기로 만듭니다.

저는 이 방식이 성과주의 평가와 충돌한다고 보지 않습니다. 오히려 미래 성과를 만들기 위한 투자를 현재 평가에 반영하는 개념으로 접근하면 훨씬 설득력이 생깁니다. 물론 이걸 평가위원회에서 설명할 때는 상당한 공을 들여야 했습니다.

부작용을 어디까지 감내할 것인가

운영을 하다 보니 예상치 못한 문제가 하나 생겼습니다. 초기에는 정말 핵심적인 과제들만 올라왔는데, 시간이 지나면서 시상을 받기 위해 만들어낸 과제들이 섞이기 시작했습니다. 겉보기에는 도전적으로 보이지만, 실제로는 처음부터 실패 가능성이 낮은 과제를 골라서 올리는 방식이었습니다.

실제로 운영해보니 이 부작용을 완전히 없애는 건 불가능하다고 봤습니다. 어느 정도는 감내해야 하는 비용입니다. 중요한 건 진짜 small success가 묻히지 않도록 데이터 구조를 잘 설계하는 것이었습니다. 저희는 RAG(검색 증강 생성) 방식을 활용한 데이터 레이크를 구성해서, 엔지니어들이 과거 실패 사례를 검색하고 맥락을 파악할 수 있도록 했습니다. 이 부분은 HR과 IT가 함께 움직이지 않으면 만들기 어려운 구조이기도 했습니다.

결국 이 제도의 핵심은 실패를 두려워하지 않는 문화를 만드는 것인데, 문화는 구호가 아니라 제도와 데이터로 만들어진다는 게 제가 이 파일럿을 통해 얻은 가장 큰 결론입니다.

아직 이 제도가 완성됐다고 말하기는 어렵습니다. 부작용도 있고, 평가자의 역량 편차도 변수입니다. 하지만 시도 자체를 기록하고, 거기서 의미를 꺼내는 구조를 갖추기 시작했다는 것만으로도 이전과는 다른 조직이 됐다고 느낍니다. 이 제도를 검토 중이시라면, 거창한 전사 도입보다 작은 팀 단위 파일럿으로 먼저 돌려보시길 권합니다. 구호가 아닌 데이터로 증명해야 조직이 납득합니다.