기본적 귀인 오류(Fundamental Attribution Error)란 무엇인가요? 팀 탓·유저 탓이 스타트업 성장을 갉아먹는 이유

기본적 귀인 오류는 스타트업의 지표 해석과 조직을 어떻게 망치나요?

결론부터 말하면, 성장이 멈춘 스타트업의 회의실에서는 거의 예외 없이 사람 이야기가 상황 이야기를 밀어냅니다. 기본적 귀인 오류(Fundamental Attribution Error)는 남의 행동을 볼 때 상황 요인을 과소평가하고 성격이나 능력 같은 기질 요인을 과대평가하는 인지 편향입니다. 1967년 존스와 해리스의 실험에서는 발표자의 입장이 동전 던지기로 정해졌다는 사실을 알려줬는데도 참가자들은 그 사람의 진짜 신념이라고 판단했습니다. 스타트업에서 이 편향은 두 얼굴로 나타납니다. 이탈한 사용자를 "귀찮아하는 유저"로 규정해 온보딩 마찰을 못 보게 만들고, 장애를 낸 동료를 "실수한 사람"으로 규정해 시스템 결함을 덮습니다. 구글 SRE와 엣시(Etsy)가 블레임리스 포스트모템을 표준으로 삼은 이유가 바로 여기에 있습니다.

기본적 귀인 오류는 스타트업의 지표 해석과 조직을 어떻게 망치나요?
이탈률 회의에서 "유저가 게을러서"라는 말이 나온 날
기본적 귀인 오류란 무엇인가: 카스트로 에세이에서 퀴즈쇼까지
스타트업에서 이 편향이 튀어나오는 네 가지 장면
지표를 사람 탓으로 읽지 않는 법: 상황 변수를 분리하는 기술
블레임리스 포스트모템: 상황 중심 회고를 조직에 심는 방법
기본적 귀인 오류를 줄이는 실전 4단계
FAQ
같이 읽으면 좋은 것들

이탈률 회의에서 "유저가 게을러서"라는 말이 나온 날

몇 해 전, 시리즈 A 직전이던 B2B SaaS 팀의 성장 회의에 앉아 있던 적이 있습니다. 가입 후 첫 프로젝트 생성까지 도달하는 비율이 34%에서 21%로 떨어진 상황이었어요. 프로덕트 리드가 화면에 퍼널을 띄웠고, 세 번째 슬라이드쯤에서 누군가 이렇게 말했습니다. "요즘 유저들이 워낙 인내심이 없어서요. 두 단계만 넘어가도 그냥 나가버립니다."

회의실이 조용히 동의했습니다. 다음 스프린트 과제는 "동기 부여 문구 강화"와 "이메일 리마인더 3회 발송"으로 정해졌습니다. 사람의 성향을 문제로 규정했으니, 해법도 사람의 마음을 흔드는 쪽으로 나온 겁니다.

두 주 뒤 지표는 21%에서 22%로 움직였습니다. 오차 범위였죠. 그때 데이터 분석가가 세션 리플레이 60건을 직접 돌려봤고, 전혀 다른 그림이 나왔습니다. 이탈이 집중된 지점은 문구가 있는 화면이 아니라 그 앞 단계, 조직 도메인을 입력하는 필드였습니다. 3주 전 배포에서 검증 로직이 바뀌면서 회사 메일이 아닌 계정은 아무 안내 없이 버튼이 비활성화되고 있었어요.

인내심의 문제가 아니라 안내의 문제였습니다. 안내 문구 한 줄과 예외 처리를 넣자 다음 주에 31%로 돌아왔고요. 이 사건이 남긴 건 숫자보다 질문의 순서였습니다. "왜 사용자가 이렇게 행동했지?"를 묻기 전에 "이 화면에서 사용자가 무엇을 할 수 있었지?"를 먼저 물어야 했다는 것.

기본적 귀인 오류란 무엇인가: 카스트로 에세이에서 퀴즈쇼까지

기본적 귀인 오류는 타인의 행동을 해석할 때 상황의 힘을 낮게 보고 그 사람의 기질을 높게 보는 체계적 왜곡을 말합니다. 대응 편향(correspondence bias)이라고도 부릅니다.

동전 던지기로 정해진 신념

1967년 에드워드 존스와 빅터 해리스는 참가자들에게 쿠바 카스트로 정권을 옹호하거나 비판하는 짧은 글을 읽게 했습니다. 절반에게는 글쓴이가 입장을 직접 골랐다고 알려줬고, 나머지 절반에게는 동전 던지기로 배정됐다고 알려줬습니다. 후자라면 글 내용은 글쓴이 생각과 무관해야 정상이죠. 그런데도 참가자들은 카스트로 옹호 글을 쓴 사람을 더 친카스트로적인 인물로 평가했습니다. 상황 제약을 명확히 알려줬는데도 글에서 인격을 읽어낸 겁니다.

퀴즈쇼 실험이 보여준 역할의 함정

1977년 리 로스(Lee Ross)는 이 현상에 기본적 귀인 오류라는 이름을 붙였고, 같은 해 애머빌·스타인메츠와 함께 유명한 퀴즈쇼 실험을 진행했습니다. 참가자를 무작위로 출제자와 응답자로 나누고, 출제자에게는 자기가 아는 아주 어려운 문제를 만들게 했습니다. 응답자는 당연히 많이 틀렸습니다. 관찰자들은 이 상황을 지켜본 뒤 출제자를 응답자보다 훨씬 지식이 풍부한 사람으로 평가했습니다. 역할이 동전처럼 무작위로 배정됐다는 사실을 모두가 알고 있었는데도요.

이 실험이 스타트업에 주는 함의는 꽤 서늘합니다. 조직에서 누가 유능해 보이는가는 실제 역량만큼이나 그 사람이 어떤 역할과 정보 위에 서 있는가에 좌우된다는 뜻이니까요. 데이터 접근 권한이 있는 사람은 통찰이 있어 보이고, 고객 미팅에 들어가는 사람은 시장 감각이 있어 보입니다.

행위자-관찰자 비대칭과 자기 위주 편향

여기에 두 가지 곁가지가 붙습니다. 행위자-관찰자 비대칭은 같은 행동이라도 내가 하면 상황 탓, 남이 하면 성격 탓으로 읽는 경향입니다. 내가 늦으면 도로가 막힌 거고, 동료가 늦으면 시간 관념이 없는 겁니다. 자기 위주 편향은 성공은 내 능력 덕이고 실패는 환경 탓이라는 방향으로 작동합니다. 창업자가 초기 성장은 제품력으로 설명하고 정체기는 시장 탓으로 설명한다면, 두 편향이 동시에 작동하고 있는 셈입니다.

문화 차이도 확인됐습니다. 밀러의 1984년 비교 연구에서 미국 아동은 나이가 들수록 성격 중심 설명을 늘렸지만, 인도 아동은 상황 중심 설명을 더 많이 썼습니다. 개인의 의지를 강조하는 문화일수록 이 편향이 강해진다는 신호입니다.

스타트업에서 이 편향이 튀어나오는 네 가지 장면

한 줄로 요약하면, 기본적 귀인 오류는 조직이 고칠 수 있는 것 대신 고칠 수 없는 것을 문제로 지목하게 만듭니다.

장면	기질 귀인(흔한 해석)	상황 귀인(대개 진짜 원인)
온보딩 이탈	사용자가 참을성이 없다	필수 입력값이 많고 실패 안내가 없다
장애 발생	담당자가 부주의했다	롤백 절차와 알람 임계값이 없었다
영업 부진	세일즈가 절실하지 않다	타깃 세그먼트와 가격 구간이 어긋났다
채용 실패	그 사람이 우리와 안 맞았다	온보딩 30일 계획과 성과 정의가 없었다

이탈률을 사람 성향으로 설명할 때

가장 비싼 형태입니다. 이탈을 사용자 성향으로 규정하면 제품 개선 백로그가 사라지고, 대신 푸시 알림 빈도와 할인 쿠폰 같은 자극 강화 수단이 늘어나죠. 근본 마찰은 그대로라서 반년쯤 뒤 같은 회의를 다시 하게 됩니다.

장애를 개인 실수로 종결할 때

배포 사고 회고에서 "누가 그랬는지"가 먼저 나오면 다음 사고는 보고되지 않습니다. 구글 SRE 문서도 이 지점을 짚습니다. 비난 중심 문화에서는 사건이 양탄자 밑으로 쓸려 들어가고, 조직의 위험은 오히려 커집니다.

팀원 평가를 맥락 없이 할 때

원격 근무 비중이 높은 팀에서 특히 잦습니다. 보이는 건 결과물과 응답 속도뿐이고, 그 사람이 어떤 인터럽트와 의존성 속에 있었는지는 안 보입니다. 관찰 가능성이 낮을수록 기질 귀인이 강해집니다.

경쟁사 성공을 창업자 개인기로 읽을 때

"저기는 대표가 워낙 대단해서"라는 문장은 편하지만 배울 게 없습니다. 타이밍, 규제 변화, 유통 채널 선점 같은 상황 변수를 뜯어봐야 우리 전략에 옮길 조각이 나옵니다. 이 오독은 생존자 편향과 결합할 때 특히 위험해집니다.

지표를 사람 탓으로 읽지 않는 법: 상황 변수를 분리하는 기술

핵심은 지표 해석 회의에 상황 가설을 반드시 한 개 이상 올리는 규칙을 만드는 것입니다.

1단계, 행동을 문장으로 다시 쓰기

"사용자가 이탈했다"는 관찰이 아니라 이미 해석입니다. 관찰은 "가입 후 3단계 화면에서 평균 8초 머문 뒤 뒤로 가기를 눌렀다"입니다. 동사와 시점, 화면을 명시하면 성격 형용사가 끼어들 자리가 줄어듭니다.

2단계, 상황 후보를 최소 세 개 나열하기

기술적 실패, 정보 부족, 인센티브 불일치 세 축이면 대부분 커버됩니다. 앞의 SaaS 팀은 검증 로직 변경과 오류 안내 부재가 정답이었고, 처음 세운 가설은 셋 중 어디에도 속하지 않았습니다.

3단계, 세션 리플레이와 인터뷰로 반증 시도

숫자만 보면 기질 귀인을 반박할 재료가 없습니다. 저는 이탈 구간 세션을 최소 30건 보는 걸 기준선으로 삼는데, 20건쯤에서 패턴이 반복되면 그게 대체로 진짜 원인이었습니다.

4단계, 코호트로 상황을 통제하기

유입 채널, 기기, 배포 버전으로 코호트를 쪼개면 사람 성향처럼 보이던 것이 대개 특정 조건의 문제로 좁혀집니다. 안드로이드 특정 버전에서만 결제 시트가 잘리는 문제를 "결제 의지가 낮은 사용자군"이라 부르던 팀도 봤습니다.

회고 문서에 "누가"를 쓰는 칸을 아예 없애고 "무엇이 그 판단을 합리적으로 만들었나"를 쓰게 합니다.
지표 리뷰 템플릿 상단에 상황 가설 3개 칸을 고정 배치합니다.
사람 이름이 등장하는 원인 진술은 회의록에서 자동으로 재작성 대상으로 표시합니다.

블레임리스 포스트모템: 상황 중심 회고를 조직에 심는 방법

한 줄 요약하면, 블레임리스 포스트모템은 기본적 귀인 오류를 조직 프로세스 수준에서 차단하는 장치입니다.

2012년 5월 엣시(Etsy)의 존 알스포는 "Blameless PostMortems and a Just Culture"를 발표했고, 이 글은 십수 년이 지난 지금까지 SRE 분야에서 가장 많이 인용되는 문서 중 하나로 남아 있습니다. 구글은 이를 SRE 북에 표준 관행으로 편입시켰습니다. 두 문서가 공유하는 전제는 단순합니다. 사건에 관여한 모든 사람은 그 시점에 자기가 가진 정보로 옳다고 판단한 행동을 했다고 가정한다는 것.

이 가정이 중요한 건 질문의 방향을 통째로 바꾸기 때문입니다. "왜 이 사람은 잘못된 행동을 했나"가 아니라 "왜 이 행동이 그 순간에는 합리적으로 보였나"를 묻게 되죠. 후자는 대시보드 설계, 알람 문구, 문서 위치, 권한 구조 같은 고칠 수 있는 대상을 끌어냅니다.

회고를 여는 기준을 미리 정해두기

구글 SRE는 포스트모템 트리거를 사전에 정의합니다. 사용자 노출 다운타임이 임계값을 넘었을 때, 데이터 손실이 났을 때, 온콜 엔지니어가 개입했을 때, 모니터링이 실패했을 때. 기준을 미리 정해두면 "이건 회고할 만한 일인가"를 두고 벌어지는 정치가 사라집니다.

문화를 유지하는 쪽이 더 어렵습니다

블레임리스 문화가 무너지는 가장 흔한 경로는 경영진의 언어입니다. 회고 문서는 상황 중심으로 쓰였는데 대표가 슬랙에 "이번 건은 누구 책임인지 확실히 하자"고 한 줄 쓰면 그 뒤 회고의 솔직함은 급격히 떨어집니다. 비난 기반 문화는 책임감이 아니라 은폐를 만듭니다.

항목	비난 중심 회고	상황 중심 회고
첫 질문	누가 배포했나	어떤 신호가 없었나
산출물	재발 방지 다짐	알람·가드레일·문서 변경
다음 사고 보고	축소·지연	조기 공유
학습 대상	개인	시스템

조직 문화 관점에서 더 넓게 보고 싶다면 스타트업 조직 문화 완전 가이드를 함께 읽어보시면 연결점이 잘 보입니다.

기본적 귀인 오류를 줄이는 실전 4단계

초보 팀도 이번 주에 시작할 수 있는 순서로 정리했습니다.

1단계. 회의록에서 형용사 사냥하기. 지난 4주 회의록에서 사람을 수식하는 형용사와 성향 표현을 전부 찾아 표시합니다. 게으르다, 절실하지 않다, 꼼꼼하지 않다, 참을성 없다 같은 단어들이요. 생각보다 많이 나옵니다. 이 목록 자체가 조직의 편향 지도가 됩니다.

2단계. 원인 진술 형식 바꾸기. "A가 B를 놓쳤다"를 "B를 놓치기 쉬운 조건이 무엇이었나"로 다시 씁니다. 형식만 바꿔도 후속 액션의 성격이 달라집니다. 전자에서는 주의 촉구가 나오고 후자에서는 체크리스트와 자동화가 나옵니다.

3단계. 반대 가설 담당자 지정. 회의마다 한 명을 지정해 기질 귀인에 대한 상황 설명을 반드시 제시하게 합니다. 역할로 못 박아야 작동합니다. 자발적 반론에 기대면 아무도 하지 않거든요. 이 장치는 확증 편향 완화에도 그대로 쓸 수 있습니다.

4단계. 상황 변수 로그 남기기. 배포 버전, 실험 노출 그룹, 외부 이벤트, 채널 믹스 변화를 지표와 같은 타임라인에 기록합니다. 3개월쯤 쌓이면 "사람이 변했다"는 설명이 필요한 구간이 거의 사라집니다. 대부분은 상황이 변했더라고요.

주의점도 있습니다. 상황 귀인을 만능으로 쓰면 책임 소재가 흐려진다는 반론이 늘 따라오죠. 블레임리스는 책임을 없애는 게 아니라 개인 처벌 대신 시스템 개선으로 책임을 이행하는 방식입니다. 반복되는 패턴에 아무 조치도 하지 않는 회고는 무해한 척하는 의례일 뿐입니다.

FAQ

기본적 귀인 오류와 확증 편향은 어떻게 다른가요?

기본적 귀인 오류는 원인을 어디에 두는가의 문제이고, 확증 편향은 어떤 증거를 받아들이는가의 문제입니다. 실무에서는 붙어서 나타나죠. "저 유저는 원래 관심이 없다"고 귀인한 뒤 그 가설에 맞는 데이터만 골라 보는 식입니다.

상황 중심으로 보면 성과 관리가 느슨해지지 않나요?

오히려 반대인 경우가 많습니다. 기질 귀인은 "더 노력하자"라는 측정 불가능한 결론으로 끝나기 쉽고, 상황 귀인은 프로세스·도구·권한처럼 검증 가능한 대상을 남깁니다. 다만 같은 문제가 반복되는데도 구조 변경이 없다면 그건 상황 귀인이 아니라 회피입니다.

규모가 작은 초기 팀에도 포스트모템이 필요한가요?

필요합니다. 다섯 명짜리 팀이라면 30분짜리 경량 버전으로 충분해요. 무엇이 일어났는지, 그 시점에 어떤 정보가 있었는지, 어떤 신호가 없었는지, 다음에 무엇을 바꿀지 네 칸이면 됩니다.

이탈 원인이 정말 사용자 쪽에 있는 경우는 없나요?

당연히 있습니다. 애초에 문제 자체를 겪지 않는 세그먼트를 데려온 경우가 대표적이죠. 하지만 그것도 성격 문제가 아니라 획득 채널과 타깃 정의라는 상황 변수입니다. 사람 성향으로 결론이 나면 할 일이 없어지고, 상황으로 옮기면 할 일이 생깁니다.

편향을 줄이는 데 얼마나 걸리나요?

개인의 자각만으로는 거의 줄지 않는다는 게 연구들의 공통된 결론에 가깝습니다. 그래서 회의 템플릿, 트리거 기준, 반대 가설 담당자처럼 프로세스에 심는 방식이 현실적입니다. 템플릿을 바꾸면 다음 회의부터 언어가 달라지고, 언어가 달라지면 한두 달 안에 액션 아이템의 성격이 바뀝니다.