더닝-크루거 효과(Dunning–Kruger Effect)
중년개발자
@loxo
약 10시간 전
개발도 인생도, 가장 위험한 순간은 “다 안다”는 착각일 수 있다
더닝-크루거 효과(Dunning–Kruger Effect)
‘더닝-크루거(Dunning–Kruger)’는 어려운 심리학 용어처럼 들릴 수 있지만, 사실은 사람의 이름에서 비롯된 표현이다.
1999년 미국의 심리학자 **데이비드 더닝(David Dunning)**과 **저스틴 크루거(Justin Kruger)**는 한 가지 질문을 연구했다.
“왜 실력이 부족한 사람이 오히려 자신의 능력을 가장 높게 평가할까?”
연구는 한 가지 역설을 보여준다. 어떤 영역의 능력이 부족한 사람은 자신의 부족함을 판단하는 능력 또한 부족할 수 있다. 반대로 실력이 뛰어난 사람은 자신이 모르는 것이 얼마나 많은지 알기 때문에, 자신의 능력을 더 조심스럽게 평가하는 경향을 보일 수 있다.
이 현상은 두 연구자의 이름을 따 **더닝-크루거 효과(Dunning–Kruger Effect)**라고 불리게 되었다.
더닝-크루거 효과를 한 장의 그래프로 보면
① 무지의 봉우리 (Peak of Mount Stupid)
신규 SI 프로젝트에 처음 투입되어 화면 몇 개와 CRUD 기능을 빠르게 만든 뒤에는 이런 생각이 들 수 있다.
“이 정도면 업무 시스템도 크게 다르지 않겠는데?”
요구사항 문서와 화면 설계서만 보면, 시스템은 비교적 단순해 보인다. 아직은 마감 배치, 월말 정산, 권한별 예외, 외부 기관 연계, 데이터 이관, 장애 대응 같은 조건들이 충분히 드러나지 않았기 때문이다.
② 절망의 골짜기 (Valley of Despair)
프로젝트가 진행될수록 처음에는 보이지 않던 현실이 나타난다.
사용자 테스트에서 “이 경우에는 이렇게 처리해야 한다”는 업무 규칙이 새로 나오고, 기존 시스템 데이터에는 형식이 맞지 않는 값이 섞여 있다. 외부 연계는 응답이 지연되거나 중복 요청이 발생하며, 오픈 직전에는 수년간 누적된 데이터와 권한 체계, 마감 일정이 한꺼번에 고려 대상이 된다.
그 시점에는 다음과 같은 생각에 이를 수 있다.
“내가 알고 있던 것은 전체가 아니라 작은 조각이었구나.”
이 단계의 혼란은 능력이 부족해졌다는 뜻이라기보다, 문제의 실제 크기를 조금 더 정확히 인식하기 시작했다는 신호일 수 있다.
③ 깨달음의 오르막 (Slope of Enlightenment)
경험이 쌓이면 질문이 많아진다.
화면 기능을 구현하기 전에 업무 흐름을 확인하고, 데이터 정합성과 예외 상황을 살피며, 장애가 났을 때의 복구 방식을 함께 고민하게 된다. 코드 자체보다 설계와 운영 환경을 함께 보게 된다.
신규 SI 프로젝트에서는 이런 질문들이 자연스럽게 따라올 수 있다.
- 기준정보가 변경되면 이미 처리된 거래는 어떻게 되나요?
- 월말 마감 중 장애가 나면 어디부터 재처리하나요?
- 기존 시스템의 데이터 오류는 어떤 기준으로 보정하나요?
- 외부 연계가 실패했을 때 재전송과 중복 처리는 어떻게 하나요?
- 현업 담당자별 권한 차이는 어떤 업무 규칙을 의미하나요?
- 오픈 후 데이터량이 늘어나도 같은 성능이 유지될까요?
답보다 질문이 많아지는 변화는 우유부단함보다, 세상이 단순하지 않다는 사실을 이해하기 시작한 결과에 가깝다.
④ 지속의 고원 (Plateau of Sustainability)
경험이 쌓인 사람은 모든 것을 안다고 말하기보다, 판단에 조건을 붙이는 경우가 많다.
“현재 확인된 요구사항 기준으로는 가능해 보입니다.”
“운영 데이터와 마감 시나리오를 함께 확인해봐야 합니다.”
“제가 놓친 업무 규칙이 있을 수 있으니 현업 검증이 필요합니다.”
이는 단순한 겸손의 표현만은 아니다. 기술, 업무, 사람, 운영 환경이 예상보다 복잡하다는 사실을 경험으로 알게 된 결과일 수 있다.
신규 SI 프로젝트에서 더 위험한 것은 자신감보다 조언이 들리지 않는 상태일 수 있다
더닝-크루거 효과는 흔히 “초보자는 자신감이 넘친다”는 정도로 이해되곤 한다.
하지만 신규 SI 프로젝트에서 더 주의 깊게 볼 부분은 자신감의 크기보다, 다른 관점과 조언을 받아들일 여지가 남아 있는지일 수 있다.
자신의 생각이 맞다고 확신하는 순간, 새로운 정보를 배우기보다 이미 가진 믿음을 지키는 쪽으로 마음이 기울기도 한다. 머릿속에서 결론이 이미 끝난 상태가 되기 때문이다.
“내 생각이 맞을 거야.”
신규 SI 프로젝트에서는 이런 일이 자주 벌어진다
선배 개발자가 말한다.
“그 구조는 오픈 후 운영에서 문제가 생길 가능성이 커.”
그러나 신규 프로젝트에 참여한 개발자는 이렇게 생각할 수 있다.
“이번 프로젝트는 사용자 수가 많지 않으니 괜찮을 거예요.”
하지만 사용자 수보다 중요한 것은 월말에 동시에 실행되는 업무, 배치 처리량, 외부 연계 건수, 누적 데이터와 같은 조건일 수 있다.
DBA가 말한다.
“그 인덱스는 데이터가 쌓이면 성능 문제가 생길 수 있어.”
개발자는 이렇게 답할 수도 있다.
“초기 이관 데이터가 많지 않아서 괜찮을 것 같은데요.”
그러나 신규 SI의 초기 데이터 규모와 오픈 후 몇 년간 쌓이는 거래 데이터의 규모는 다를 수 있다. 특히 조회 조건과 통계성 화면, 월말 집계 작업은 초기 테스트에서는 보이지 않던 부담을 만들기도 한다.
아키텍트가 말한다.
“현재 업무 규모와 조직 구조라면 마이크로서비스로 나누기에는 아직 이르다.”
하지만 이미 머릿속에서는 이런 결론이 내려져 있을 수 있다.
“요즘은 다 MSA잖아요.”
신규 SI 프로젝트에서는 기술 선택이 목적보다 앞서는 경우가 생길 수 있다. 서비스 분리가 실제 업무 경계, 배포 체계, 장애 대응 책임, 운영 인력과 맞지 않으면 복잡성만 늘어날 수도 있다.
조언을 듣는 것과 조언을 받아들이는 것은 다르다. 말은 들었지만, 기존의 결론이 강하면 그 말은 설계와 판단에 반영되지 못할 수 있다.
왜 이런 일이 생길까?
사람은 현실을 있는 그대로 보기보다, 자신이 이미 믿고 있는 생각을 뒷받침하는 정보를 더 쉽게 찾고 받아들이는 경향이 있다.
이를 **확증편향(Confirmation Bias)**이라고 한다.
더닝-크루거 효과와 확증편향이 함께 작동하면 신규 SI 프로젝트에서도 다음과 같은 흐름이 만들어질 수 있다.
요구사항 일부와 기술을 조금 이해한다.
│
▼
“이 정도면 전체 구조를 다 알겠다.”
│
▼
현업, DBA, 인프라, 선임의 조언이 크게 들리지 않는다.
│
▼
자기 생각과 익숙한 방식만 맞다고 확신한다.
│
▼
통합 테스트나 오픈 이후 예상하지 못한 문제가 생긴다.
│
▼
요구사항, 환경, 다른 팀의 문제라고 생각한다.
│
▼
자신의 생각은 더욱 굳어진다.
│
▼
다시 조언을 듣지 않게 된다.이 과정은 누군가가 의도적으로 다른 사람의 말을 무시해서만 생기는 것은 아니다.
때로는 자신의 생각 속에서 스스로를 가두는 방식으로 나타난다.
인생에서도 비슷한 장면을 발견할 수 있다
20대에는 세상이 비교적 단순해 보일 수 있다.
노력하면 성공할 수 있다고 믿고, 충분히 노력하면 대부분의 문제를 해결할 수 있다고 생각하기도 한다.
30대에는 사람이 논리보다 감정으로 움직이는 순간이 많다는 것을 경험하게 된다.
40대 이후에는 사람을 바꾸는 일이 프로그램의 버그를 고치는 일보다 훨씬 어렵다는 사실을 체감하기도 한다.
그래서 시간이 지날수록 말이 줄어드는 경우가 있다.
많이 알아서라기보다, 많이 틀려봤기 때문일 수 있다.
경험이 쌓일수록 질문이 먼저 나올 수 있다
처음에는 답을 먼저 말하기 쉽다.
“됩니다.”
하지만 신규 SI 프로젝트를 여러 번 경험할수록 답보다 질문이 먼저 떠오르기도 한다.
- 요구사항은 정말 확정인가요?
- 현업 부서마다 같은 용어를 같은 의미로 사용하나요?
- 기존 시스템 데이터의 오류와 누락은 어떻게 처리하나요?
- 장애가 나면 복구는 어떻게 하나요?
- 예외 케이스와 마감 시나리오는 확인했나요?
- 운영 환경에서도 같은 성능과 결과가 나올까요?
- 오픈 이후 변경 요청은 어떤 방식으로 관리하나요?
질문이 많다는 것은 결정을 피한다는 뜻은 아니다.
오히려 업무의 조건과 운영 결과를 함께 살피려는 태도일 수 있다. 하나의 답을 내리기 전 확인할 것이 많다는 사실을 인식하는 것이다.
결국 좋은 개발자에게 중요한 것은
가장 많은 언어를 아는 사람인지, 가장 화려한 기술을 쓰는 사람인지로만 판단하기는 어렵다.
신규 SI 프로젝트에서는 특히, 현업 담당자·DBA·인프라 담당자·테스트 담당자·동료 개발자의 조언을 끝까지 들을 수 있는 태도가 프로젝트의 품질을 바꾸기도 한다.
자신이 틀릴 가능성을 알고 있는 사람은 다른 관점을 쉽게 닫지 않는다. 그리고 그 가능성을 인정하는 순간, 생각은 다시 움직이기 시작한다.
무지는 자신감을 만들 수 있다.
경험은 겸손을 만들 수 있다.
그리고 사람을 크게 성장시키는 것은 지식의 양만이 아니라,
“내가 틀릴 수도 있다.”
라는 한 문장을 받아들일 수 있는 태도일지도 모른다.