지식의 저주
지식이 많다고 항상 유리한 것은 아니다.
혹시 다른 사람에게 내가 알고 있는 것을 이해시키기 어려웠던 경험이 있나요?
그렇다면 지식의 저주에 빠져 있었을지도 모릅니다.
우리는 세상을 살아가며 수많은 정보를 습득하고 내보내며 살아갑니다. 그 정보들은 쌓여 개인의 지식이 되기도 하고, 한 분야의 전문가는 풍부한 지식을 가지게 됩니다. 이 지식 덕분에 경쟁력이 생기고, 더 많은 일을 해낼 수 있게 됩니다. 하지만 지식이 많다고 해서 언제나 우월하거나 유리하다고 착각하기 쉬운데, 언제나 그런 것은 아닙니다.
이와 관련한 스터디가 있습니다. 경제학자 캐머러, 로웬스타인, 웨버가 연구했던 개념 ‘지식의 저주’입니다.
더 많은 정보를 가진 사람이, 덜 아는 사람의 행동이나 판단을 정확히 예측하지 못하는 인지 편향
보통 ‘정보가 많은 쪽이 거래나 협상에서 늘 우위를 점할 것‘이라고 가정합니다. 하지만 이 연구는, 정보를 덜 가진 상대를 마치 ‘나와 비슷한 정보를 알고 있는 사람‘처럼 대하는 순간, 불필요하게 양보하거나 가격을 왜곡하는 상황이 벌어진다는 것을 말합니다.
https://www.cmu.edu/dietrich/sds/docs/loewenstein/CurseknowledgeEconSet.pdf지식의 저주는 특정 직군에만 나타나는 문제가 아니라, 사람과 사람의 대화 전반에 걸쳐 나타나는 인지심리학 현상입니다.
조금만 좁혀서 보면, 디자이너의 포트폴리오, 면접, 협업, UX 설계 과정에서 이 현상을 특히 자주 경험하게 됩니다. 상대방에게 어느 정도까지 설명해야 할지 파악하지 못해 커뮤니케이션 오류가 발생하는 것이죠. 사용자를 세심하게 살피는 프로덕트 디자이너조차, 막상 상대의 이해 수준에 맞춰 정보를 조절하는 일은 여전히 어렵습니다. 특히 포트폴리오나 면접에서는 상대방을 과대 혹은 과소 평가해, 적절한 수준의 정보량과 난이도를 맞추지 못하는 경우가 많습니다.
그렇다면 지식이란 무엇이고, 왜 이런 ‘서로 이해하지 못하는 상황‘이 반복해서 생기는 걸까요?
지식은 사실의 목록이 아닌 패턴화된 이해
먼저 ‘지식’의 사전적 의미를 살펴보겠습니다.
지식 : 어떤 대상에 대하여 배우거나 실천을 통하여 알게 된 명확한 인식이나 이해
여기서 주목할 점은 ‘배우거나‘, ‘실천을 통하여 알게 된‘이라는 부분입니다. 지식은 단순한 사실의 집합이 아니라, 이해하고 적용하는 과정에서 만들어지는 패턴화된 인식에 가깝습니다. 지식의 양이 많아질수록 ‘안다‘는 감각은 커지지만, 동시에 그 구조도 더 복잡해집니다.
패턴화된 인식이 많아질수록, 그 지식을 가진 사람에게는 그것이 점점 세상의 기본값처럼 느껴지는 경험을 하기도 합니다. 어느 순간부터는 대중의 이해 수준을 실제보다 높게 평가하게 되기도 합니다.
이렇게 쌓인 지식은 말과 문장 속에서 무의식적으로 드러납니다. 자연스럽게 이야기하고 있다고 느끼지만, 그 안에는 이미 여러 단계의 개념과 전제가 압축되어 들어가 있어서, 듣는 사람 입장에서는 어려운 내용이 되어 버립니다. 어려운 개념도 아주 기초 단계로 풀어 설명하면 충분히 이해할 수 있음에도 이 단계를 생략하게 됩니다.
특히 모든 현상의 기초 원리가 아니라, 이미 여러 차례 정제, 고도화된 단계의 지식일수록 기초 설명 단계를 건너뛰기 쉽습니다. 복잡한 과정을 한꺼번에 묶어 하나의 단어나 문장으로 말해 버리기 때문에, 그 단어를 공유하지 못하는 사람과는 속도가 맞지 않게됩니다.
이때 한 번 습득된 지식은 각자의 머릿속 지식 구조 안에서 다시 배치되고 의미가 재정리됩니다. 같은 정보를 받아도 이해도와 사고 방식이 다르기 때문에, 거기서 자연스럽게 지식의 편차가 생기게 됩니다. 그리고 이 재구성 과정에서 정보를 묶는 단위, 즉 지식의 그룹화 단위인 ‘청크’가 형성됩니다
청크가 맞을 때는 대화가 빨라지고, 어긋날 때는 끝까지 엇갈린다
‘청크’는 정보나 데이터, 지식을 작은 단위로 묶은 덩어리를 말합니다. 예로 들어 보겠습니다.
A: 이 프로젝트는 간단해요. 기존 플로우 유지한 채, 중간에 확인 단계 하나만 넣은 거라서요.
(A의 머릿속) “간단 → 우리 도메인에선 흔한 패턴, 이미 여러 번 써본 컴포넌트, 개발팀도 바로 이해했던 변경, 그래서 리스크도 낮고 구현도 1스프린트면 끝난다고 느끼는 청크”
B: 근데 문서만 보면 왜 이게 중요한지 잘 모르겠어요. 사용자 입장에선 뭐가 달라진 거죠?
(B의 머릿속) “간단 → 입력 필드 몇 개만 줄였다는 수준, 도메인 컨텍스트나 기존 에러 상황은 잘 모르고, ‘중간 확인 단계’가 왜 필요했는지에 대한 정보는 거의 없음”
이때 A는 포트폴리오에서 '간단하다' 정도로만 설명하고 있지만, 그 안에는 도메인 이해, 기존 에러 패턴, 규제/리스크 고려, 개발 협업 과정까지 한꺼번에 묶인 큰 청크가 들어 있습니다. 반대로 B(리뷰어, 면접관)는 그 청크를 공유하지 못하기 때문에, 같은 '간단하다'는 말을 들으면서도 '그래서 정확히 뭘 했고, 그게 왜 의미 있는지'를 끝까지 복원하지 못합니다.
작성자는 '내가 알고 있는 전제를 상대도 어느 정도는 알고 있을 것'이라는 감각으로 문장을 압축해서 쓰고, 읽는 사람은 그 전제를 공유하지 못한 채, 지식의 공백이 많은 채로 설명을 받아들입니다. 결과적으로, 실제로는 복잡하고 가치 있는 일을 해냈음에도 문서에서는 '별로 안 어려운 작업을 한 사람'처럼 보이게 됩니다.
물론 같은 도메인에서 오래 일했고, 지식 수준이 비슷한 사람들끼리라면 이런 청크가 오히려 포트폴리오 리뷰를 엄청 빠르게 만들어 줍니다.
리뷰어 C: 이 프로젝트, 진짜 의료 SaaS스럽다. 특히 온보딩 부분이.
(리뷰어 A의 머릿속) “의료 SaaS스럽다 → 복잡한 권한 구조, 감사 로그, KYC/규제 대응, 보수적인 배포 전략, 의사·코디네이터·어드민이 섞여 있는 계정 체계까지 한 번에 떠오르는 거대한 청크”
지원자 D: 맞아요. 의료 SaaS라서 그 특유의 리스크랑 워크플로우를 많이 탔어요. 그래서 온보딩도 일반 B2B랑 다르게 설계했어요.
(지원자 B의 머릿속) “의료 SaaS스럽다 → 의료진이 바쁜 상황에서 쓰는 UI, 환자 정보 민감도, 정책 변경 주기, 병원 내 IT 인프라 제약 등, 이 프로젝트에서 풀고자 했던 거의 모든 제약 조건이 압축된 청크”
여기서 '의료 SaaS스럽다'는 말은, 그냥 수식어가 아니라 의료 SaaS라는 장르, 그동안 보아 온 여러 제품의 패턴, 규제 환경과 릴리즈 문화까지 포괄하는 하나의 큰 청크입니다.
리뷰어 A가 '의료 SaaS스럽다'고 말하는 순간, 원래라면 몇 분 동안 설명해야 하는 도메인 맥락과 제약 조건, UX 패턴에 대한 인상을 한 문장으로 압축해 피드백합니다. 그리고 지원자 B 역시 이 청크를 충분히 갖고 있었기 때문에, 둘은 아주 짧은 말만으로도 꽤 깊은 이야기를 주고받을 수 있습니다.
이렇게 청크가 잘 맞는 상황에서는, 포트폴리오도 짧은 표현만으로 많은 정보를 주고받을 수 있고, 도메인 전문가끼리의 리뷰나 동료 디자이너 간 피드백이 매우 효율적으로 돌아갑니다. 이런 청크 덕분에 인류의 지식 수준은 엄청나게 발전해 왔습니다. 아인슈타인이 상대성이론을 동료 연구자들과 발전시키기 위해 대화할 때, 매번 상대성이론의 근본과 기초 단계부터 전부 설명해야 했다면, 과연 제대로 된 토론이 가능했을까요? 청크를 구성하는 것은 뇌의 기본적인 사고 과정이고, 그 청크를 언제 압축해서 쓰고 언제 풀어야 하는지 아는 사람이 소통 능력이 뛰어난 사람에 가깝습니다.
상대방의 수준을 이해하고 적당한 수준으로 대화하기
그래서 지식을 전하는 커뮤니케이션에서는, 내가 배우고 체득한 것을 타인의 이해 수준에 맞게 전달하는 것이 매우 중요합니다. 그 기준은, 지식을 전달받는 대상의 수준을 이해하는 것에서 시작합니다.
앞에서 지식의 저주를 ‘더 많은 정보를 가진 사람이 덜 아는 사람의 행동이나 판단을 예측하지 못하는 인지 편향‘이라고 정의했습니다. 여기에는 순수한 지식 수준의 차이와 지식을 묶는 청크의 구성이 달라서 대화가 잘못되는 경우가 많습니다.
특히, 많은 정보를 담아야 하는 포트폴리오에서는 ‘이 정도면 알겠지‘라는 방심이 자주 발생합니다. 제작자는 오랜 시간 관련 지식을 다루어 왔고, 자기 자신이 여러 번 읽고 수정했기 때문에 ‘적당한 수준‘이라고 느끼기 쉽습니다. 그러나 바로 그 적당한 수준에 숨은 '이해하기 어렵게 묶인 정보‘ 때문에, 전달받는 사람이 보유하지 않은 청크를 전제로 설명하게 되고, 그 결과 논리적 빈틈이나 오해가 발생합니다.
그렇다고 청크 수준을 지나치게 낮춰 기초부터 모두 설명하면 페이지가 너무 많아집니다. 반대로 전문성을 낮추기 위해 많은 맥락을 빼면, 깊이 있게 탐구한 강점을 설득력 있게 보여 주기 어려워집니다. 이 지점은 포트폴리오라는 형식의 맹점이면서, 디자이너 직무의 특성에서 비롯되기도 합니다.
프로덕트 디자이너는 대체로 그래픽 결과물보다 기획력, UX, 비즈니스 이해를 중심으로 성과를 설명합니다. 그래서 특정 도메인에 대한 깊은 지식이 쌓이기 쉽습니다. 같은 도메인 사람에게는 짧은 시간 안에 매력적으로 이야기를 풀 수 있지만, 다른 도메인의 사람에게는 긴 설명 과정이 필요합니다. 그런데 포트폴리오와 면접은 페이지와 시간이 제한돼 있어, 결국 지식의 수준과 양을 의도적으로 조절하게 됩니다. 그 결과 깊게 파고든 지식이 오히려 강점으로 드러나지 못하는 역설이 생깁니다.
물론 이런 구조적 한계 속에서도, 논리를 갖추고 매력적인 흐름으로 포트폴리오를 구성해 내는 사람들도 있습니다. 그들 역시 수많은 시도와 수정을 거치며, 조금씩 지식의 저주를 다루는 법을 익혀 왔을 거라 생각합니다.
예측이 아닌 검증해보기
이런 구조적 한계 안에서 지식의 저주를 완화하는 가장 현실적인 방법은 피드백을 받는 것 입니다. 내가 담고 있는 지식의 청크가 적절한지, 예상 독자의 수준에서 테스트하고 개선하는 것이죠. 피드백과 반복이 많을수록 적정한 지식 수준을 더 잘 맞출 수 있습니다.
특히, 수 많은 지식의 집합체로 만들어진 어느정도의 '평균'으로 가정할 수 있는 AI의 평가나 검토를 받는 것도 좋습니다. AI의 피드백을 받는 것이죠. 프롬프트로 '엄격하게 비평해줘', '너는 이제부터 내가 지원할 회사의 디자인 면접관이야'와 같이 임무와 페르소나를 부여하여 나의 지식을 한 번 필터링 해보는 것이 도움이 됩니다. 물론 완벽하게 믿을 수 없지만요.
마지막으로 청크를 맞추는 것이 어렵다면 평소의 대화에서 부터 맞지 않는지 확인해보는것도 필요합니다. '나의 사고 구조가 다른 사람과 다른지', '내가 지나치게 기초 지식을 뛰어 넘거나 맥락을 잘못 파악한게 아닌지', 지식의 저주를 겪고 있다는 느낌이 들 때에는, 가장 먼저 내가 보유한 지식과 사고 방식을 과대 평가도, 과소 평가도 하지 않고 객관적으로 바라보는 것에서 시작해야 합니다.
그다음 ‘지식의 이해 차이는 분명 존재한다‘는 전제를 받아들이고, 직접 전달할 대상이 아닌 다른 사람을 통해 내 설명을 점검받아 보는 것이 도움이 됩니다. 목표(채용, 설득, 교육 등)가 분명하다면, 그 목적에 맞게 청크의 수준을 계속 다듬는 과정이 목표를 달성하는게 아주 큰 도움이 될 것입니다.
여기까지 ‘지식의 저주’라는 인지 편향을 다뤄 보았습니다. 결론은 다소 원론적으로 느껴질 수 있지만, 지식의 구조와 습득 방식, 그리고 이해 차이가 어디에서 시작되는지 이해하면 보이는 것이 분명히 달라진다고 생각해 이 글을 쓰게 되었습니다.
경력이 많은 전문가나, 박사처럼 지식 수준이 매우 높은 사람일수록 ‘적절한 설명의 수준’을 찾는 일이 더 어려울 수 있을 것 같습니다. 때로는 성과가 제대로 전달되지 않아 반감되기도 하고요. 그래서 그런 사람들이 함께 살아가는 사람과 연결될 수 있는 환경을 조성하는 일 역시 중요하다고 느낍니다. 그래서 정말 어려운 건 지식을 쌓는 것이 아니라 쌓인 지식을 잘 전달하는 것이지 않나 생각하게 됩니다. 물론 제가 보유한 지식이 충분하지 못해 의사소통이 잘 안 되는 것일 수도 있고요.
긴 글 읽어주셔서 감사합니다.