안다는 것과 잘 설명한다는 것은 다른 능력이다
깊은 전문성이 있어도 왜 설명은 어려울 수 있는지, 그리고 지식을 다른 사람이 이해하고 기억하고 활용할 수 있는 형태로 바꾸는 방법을 다룹니다.
아주 흔한 역설
10년 동안 일한 사람도 “이 일을 어떻게 하나요?”라는 질문에 세부사항을 쏟아내며 정작 무엇이 중요한지는 알려주지 못할 수 있습니다. 전문성이 부족해서가 아닙니다. 전문성과 전문성을 전달하는 능력은 다른 기술이기 때문입니다.
전문가는 많은 정보 층을 동시에 봅니다. 초보자는 그렇지 않습니다. 전문가는 자신의 머릿속 모델 안에서 이야기하기 때문에 다른 사람이 따라오기 위해 필요한 중간 단계를 쉽게 건너뜁니다.
알기, 이해하기, 설명하기, 이해시키기
네 단계로 볼 수 있습니다. 정보를 아는 것 , 원인과 관계를 이해하는 것 , 이해한 것을 설명하는 것 , 그리고 상대에게 맞는 언어·예시·구조를 통해 이해하도록 돕는 것 입니다.
Tips, 강의, 가이드가 지향해야 할 것은 마지막 단계입니다. 독자는 당신이 아는 모든 것을 볼 필요가 없습니다. 자신의 질문에서 실제로 쓸 수 있는 결론까지 가는 명확한 경로가 필요합니다.
흔한 실수: 내가 아는 것에서 시작하기
글쓴이는 자신이 말하고 싶은 것에서 시작하기 쉽습니다. 하지만 독자는 질문, 문제, 결정하지 못한 상황에서 들어옵니다.
“내가 무엇을 공유할 수 있지?”가 아니라 독자는 지금 무엇을 이해하거나 해결하려 하는가? 를 물어야 합니다. 이 질문 하나로 포함할 정보, 예시, 순서가 달라집니다.
Framework: Reader → Problem → Insight → Explanation → Application
다섯 단계입니다. Reader — 누구를 위한 글인가. Problem — 무엇에서 막히는가. Insight — 가장 중요한 관점은 무엇인가. Explanation — 어떤 논리, 예시, 대비가 필요한가. Application — 이해한 뒤 무엇을 다르게 할 수 있는가.
이 구조는 글을 지식 과시가 아니라 독자를 앞으로 움직이게 하는 도구로 만듭니다.
개인 경험을 재사용 가능한 지식으로 바꾸기
제품 디자이너가 “저는 항상 wireframe 전에 사용자 인터뷰를 합니다”라고 말하면 아직 개인적인 습관에 가깝습니다.
더 좋은 표현은 이렇습니다. “wireframe을 너무 일찍 만들면 검증되지 않은 가정에 팀이 고정될 수 있다. 화면을 그리기 전에 사용자가 하려는 일, 방해 요소, 현재 사용하는 대안 세 가지를 먼저 확인하라.”
경험이 다른 사람도 쓸 수 있는 원칙이 됩니다.
단순화는 얕게 만드는 일이 아니다
쉽게 설명하려면 오히려 깊이 이해해야 합니다. 핵심, 예외, 특정 상황에서만 필요한 세부사항을 구분해야 하기 때문입니다.
좋은 설명은 복잡성을 없애지 않습니다. 독자가 필요한 순서에 맞춰 복잡성을 재배열합니다.
좋은 글은 내가 얼마나 많이 아는지 증명할 필요가 없다
숨은 목적이 전문성을 과시하는 것이라면 용어, 각주, 곁가지가 늘어납니다. 목적이 이해라면 더 적게 말하지만 더 정확하게 선택하게 됩니다.
편집할 때는 이렇게 물어보세요. 이 문단을 빼면 독자가 핵심 아이디어를 이해하거나 적용하지 못하게 되는가?
Forwork Tips에 적용하기
좋은 Forwork Tips는 구체적인 업무 문제에서 시작하고, 하나의 핵심 insight를 제시하며, 왜 중요한지 설명하고, 마지막에 적용 방법을 보여줘야 합니다.
또한 Project와 연결해 실제 경험의 근거를 보여주고, Profile과 연결해 전문성을 강화하거나, Event와 Letter로 더 긴 대화로 확장할 수 있습니다.
결론
지식을 잘 전달한다는 것은 아는 것을 줄이는 일이 아닙니다. 다른 사람이 그 지식 안으로 들어갈 수 있는 길을 설계하는 일입니다.
그때 경험은 한 사람의 머릿속에만 머무르지 않고 읽히고, 기억되고, 토론되고, 적용되고, 다른 업무 증거와 연결되는 지식 자산이 됩니다.