나는 잘 했는데요

개발자의 시선으로 바라본 자기평가의 편향성과 메타인지 높이는 법

 

소프트웨어 개발자로 일하면서 주기적으로 자기평가를 하게 됩니다. 특히 미들웨어처럼 복잡한 시스템을 개발하는 업무를 하다 보면, 스스로의 업무와 성과를 객관적으로 평가하는 일이 생각보다 어렵다는 것을 자주 느꼈습니다. 저는 제가 직접 평가를 받는 과정과, 평가를 하는 과정을 모두 경험하면서 개발자마다 자기평가 방식이 왜 다를까에 대해 여러 번 생각해보았습니다.

 

이 글에서는 제가 경험한 것을 바탕으로 개발자들이 자기평가를 할 때 어떤 편향성이 나타나는지, 그 이유는 무엇인지, 또 이를 개선할 수 있는 메타인지 역량에 대해서도 편안한 관점으로 이야기해보고자 합니다.

---

개발자마다 자기평가 방식이 다른 이유

같은 팀에서 함께 일하다 보면, 비슷한 업무를 한 동료들도 자기평가 방식이 상당히 다르다는 것을 발견하곤 합니다. 어떤 동료는 자신이 잘했던 일과 부족했던 점을 꼼꼼하게 분석하는 반면, 다른 동료는 "최선을 다했다" 정도의 표현을 반복하기도 합니다.

 

처음에는 개인의 성격이나 업무 스타일 때문이라고 생각했지만, 제가 평가를 받는 입장에서 평가를 하는 입장으로 바뀌어보니, 더 근본적인 이유가 있다는 것을 알게 됐습니다. 그것은 바로 자기객관화 능력과 메타인지 역량의 차이였습니다.

 

자기객관화란 자신을 마치 제삼자처럼 바라볼 수 있는 능력을 말합니다. 메타인지는 자기의 사고와 행동을 스스로 점검하고 조정하는 능력입니다. 이 두 능력이 뛰어난 사람은 자기 평가를 더 정확하고 명확하게 할 수 있었습니다. 반면 두 능력이 부족한 사람은 자신을 평가할 때 모호한 표현에 머물렀습니다.

---

조하리의 창으로 본 자기평가의 편향성

개발자로 일하며 많은 동료의 평가를 접하면서, 자기평가에 대한 편향성을 자연스럽게 떠올리게 한 것이 바로 ‘조하리의 창’이라는 개념이었습니다.

 

 

조하리의 창은 자기 자신과 타인이 자신을 인식하는 정도를 네 가지 영역으로 나눈 심리학적 개념입니다. ‘열린 창’은 자신과 타인 모두 아는 영역, ‘숨겨진 창’은 자신만 아는 영역, ‘맹점의 창’은 타인만 아는 영역, ‘미지의 창’은 자신과 타인 모두 모르는 영역을 의미합니다.

 

제가 만난 개발자 중 자기 평가를 명확히 하는 사람들은 주로 ‘열린 창’이 컸습니다. 이들은 타인의 피드백을 편하게 받아들이고 이를 자기 평가에 적극적으로 반영했습니다. 반대로 자기평가에 편향이 심한 사람들은 주로 ‘숨겨진 창’과 ‘맹점의 창’이 큰 경우였습니다. 이들은 자기의 부족한 점을 잘 받아들이지 못했고, 평가 과정에서 자신의 성과를 지나치게 부풀리거나 혹은 너무 축소했습니다.

 

실제로 평가를 담당하면서도, 편향된 평가를 하는 동료에게 피드백을 줄 때는 많은 어려움이 있었습니다. 그들은 스스로 가진 인식의 한계 때문에 평가 결과를 받아들이는 데 더 큰 저항감을 나타냈기 때문입니다.

 

---

성장 마인드셋과 자기평가의 관계

다양한 개발자와 일하며 가장 인상 깊었던 것은 성장 마인드셋을 가진 동료들의 특징이었습니다.

 

성장 마인드셋이란 심리학자 캐럴 드웩이 제안한 개념으로, 지금 자신의 능력이 부족하더라도 꾸준히 노력하면 성장할 수 있다고 믿는 태도를 말합니다. 제가 함께 일했던 개발자 중 성장 마인드셋이 뛰어난 사람들은 자기 평가를 더 정직하고 구체적으로 했습니다. 그들은 자신이 부족했던 점을 오히려 배움의 기회로 삼고, 평가를 성장의 도구로 적극적으로 활용했습니다.

 

반대로 고정 마인드셋을 가진 사람들은 자기 평가에서 자신의 성과나 역량을 과장하거나 축소하는 경향을 보였습니다. 이런 동료들은 자기 평가를 자신의 능력이나 자존심을 지키기 위한 수단으로 활용하는 모습이 자주 보였습니다.

---

메타인지 역량을 높이기 위한 연습 방법

저 또한 처음부터 자기 평가를 정확히 했던 것은 아닙니니다. 저 역시 평가를 통해 스스로를 객관화하는 것이 어렵다고 느꼈기 때문에 여러 가지 방법을 시도했습니다. 제가 직접 효과를 본 방법은 다음과 같은 네 가지였습니다.

 

첫째, 저는 매일 업무가 끝나면 간단한 메모를 남겼습니다. 하루 동안 잘한 점, 개선이 필요했던 점을 간략히 기록하는 것만으로도 자기 객관화 능력이 자연스럽게 향상되는 것을 느꼈습니다.

 

둘째, 업무 중간마다 자기 자신에게 질문하는 습관을 가졌습니다. ‘지금 이 방식이 정말 최선인가?’ 혹은 ‘내가 놓치고 있는 것은 무엇인가?’ 같은 질문을 반복하면 무의식적으로 행하는 습관을 의식적으로 점검할 수 있게 됩니다.

 

셋째, 2주에 한 번씩은 ‘자기 피드백 세션’을 갖는 시간을 만들었습니다. 짧게라도 스스로의 성과를 점검하고 개선할 부분을 찾는 시간을 꾸준히 갖다 보니, 메타인지 능력도 점점 좋아지는 것을 느꼈습니다.

 

마지막으로 동료들의 업무 방식을 주의 깊게 관찰하고 나와의 차이를 분석하는 습관을 길렀습니다. 이를 통해 제 업무 방식의 장단점을 자연스럽게 비교하고, 제가 보지 못했던 부분을 발견할 수 있었습니다.

 

 

간단하게 작성했지만 이 4가지를 반복하는 건 보기보다 상당히 고통스러운 일입니다. 깜깜한 어둠 속에서 길이 있을지 없을지 모르는 그런 막연함에서 시작해 무한히 많은 가지치기를 하며 경우의 수를 탐색해가는 과정이기 때문입니다.

 

유효하게 고민해야 할 부분과, 그렇지 않고 러프하게 검토하고 지나쳐야 할 부분들에 대한 적절한 힘조절과 배분이 되지 않으면 영원히 끝나지 않는 탐색의 시간을 갖게 됩니다. 작은 것 부터 찬찬히 뇌에 힘 주고 있는 시간을 유지하는 연습이라고 생각했습니다. 

---

개발자의 자기평가를 돕기 위한 평가자의 역할

평가자로서 동료 개발자들의 평가 과정을 지켜보며, 가장 중요하다고 느낀 점은 명확한 피드백과 평가 기준을 제시하는 것이었습니다. 특히 자기 평가의 편향성을 가진 개발자들에게는 객관적인 데이터나 지표를 통해 자신의 상태를 확인할 수 있도록 돕는 것이 필요했습니다.

 

또한 자기평가가 부정확한 개발자일수록, 평가 과정이 자신의 능력을 검증받는 시간이 아니라 더 성장하기 위한 과정이라는 점을 인지시키는 것이 중요했습니다.

이러한 노력이 반복되면서 평가에 방어적이었던 동료들도 조금씩 객관적이고 명확한 평가를 할 수 있게 되는 것을 확인했습니다.

 

만약 평가자가 명확한 가이드라인을 제시하지 않거나, 목표하는 지향점을 공유하지 않는다면 논의를 통해 싱크를 맞추는 과정이 필요합니다. 현실적으로 어렵다면 스스로라도 가이드라인과 목표점을 설정해 스스로 그 진행상황을 체크해 나가는 준비를 해 보는 건 어떨까요?

 

---

평가라는 제도는 두렵고 어려운 일일 수 있습니다. 그러나 소프트웨어 개발자에게 자기평가는 단순한 평가 과정이 아니라 자신의 업무 방식을 돌아보고 메타인지 역량을 키울 수 있는 좋은 기회입니다. 스스로를 객관적으로 바라보고 평가할 수 있다면, 개인과 팀 모두 더 큰 성장을 이룰 수 있을 것입니다. 제 경험이 여러분에게도 작은 도움이 되었으면 합니다.