
분명히 옆사람은 듣기만 했는데, 답은 내가 찾았다
개발자라면 이런 경험 다들 있을 거예요. 버그 하나를 몇 시간째 못 잡아서 머리를 쥐어뜯다가, 옆자리 동료한테 "이거 좀 같이 봐줄래요?" 하면서 상황을 처음부터 설명하기 시작하는 순간, 말이 채 끝나기도 전에 "아, 잠깐만요. 여기가 문제였네요" 하고 스스로 답을 찾아버리는 거. 정작 동료는 의자만 돌려서 듣고 있었을 뿐인데 말이죠.
이번 글은 바로 그 현상을 정면으로 파고들어요. 글쓴이는 이걸 '대화 배당금(dialogue dividend)'이라고 불러요. 누군가에게 소리 내서 생각을 풀어놓는 것만으로도, 혼자 머릿속으로 굴릴 때보다 더 나은 결론에 도달한다는 거예요. '배당금'이라는 단어를 쓴 게 재밌는데요. 주식을 들고만 있어도 배당이 들어오는 것처럼, 그냥 입 밖으로 꺼내기만 해도 공짜로 따라오는 이득이 있다는 뜻이거든요.
머릿속 생각은 생각보다 엉성하다
이게 왜 그럴까요. 우리는 보통 "나는 머릿속으로 이미 다 정리했어"라고 착각하는데, 실제로 머릿속 생각은 굉장히 흐릿하고 압축돼 있어요. 중간 단계를 건너뛰고, 검증 안 된 가정을 슬쩍 깔고 넘어가고, "대충 이렇게 되겠지" 하는 부분이 잔뜩 섞여 있죠.
그런데 이걸 말로 바꾸려면 어떻게 돼요? 단어를 골라야 하고, 순서를 정해야 하고, 문장으로 이어 붙여야 해요. 이 과정에서 머릿속에서 대충 뭉개고 있던 부분이 강제로 드러나요. "어... 그러니까 여기서 이 값이... 어? 이거 왜 이렇게 되지?" 하는 순간, 생각의 빈틈이 눈에 보이는 거예요. 혼잣말로도 어느 정도 효과가 있지만, 듣는 사람이 앞에 있으면 효과가 훨씬 커져요. 상대가 이해하게 만들어야 한다는 부담이 생기니까, 더 또박또박 논리를 세우게 되거든요.
러버덕부터 페어 프로그래밍까지
사실 개발 업계는 이 원리를 오래전부터 알고 있었어요. 가장 유명한 게 '러버덕 디버깅(rubber duck debugging)'이에요. 책상 위에 고무 오리 인형 하나 올려두고, 코드를 한 줄 한 줄 오리한테 설명하다 보면 버그를 찾게 된다는 거죠. 오리는 당연히 아무 말도 안 해요. 핵심은 '설명하는 행위' 그 자체에 있는 거예요.
페어 프로그래밍이나 코드 리뷰가 효과적인 이유도 비슷한 맥락이에요. 내 코드를 남에게 설명 가능한 형태로 만드는 순간, 내가 놓친 게 보이거든요. 글쓰기도 마찬가지고요. 그래서 "막히면 일단 동료한테 설명해봐", "이슈에 상황을 글로 적어봐" 같은 조언이 괜히 나온 게 아니에요.
한국 개발자에게 주는 시사점
요즘은 옆에 사람이 없어도 AI한테 설명하면서 생각을 정리하는 분들이 많아졌죠. 사실 이것도 대화 배당금의 연장선이에요. AI가 정답을 주든 안 주든, 내 문제를 말이 되게 풀어 적는 과정에서 이미 절반은 풀리는 경우가 많거든요. 혼자 일하는 1인 개발자나 사이드 프로젝트 하는 분들한테 특히 의미가 커요.
실무에서 당장 써먹으려면, "30분 막히면 무조건 누군가(또는 무언가)에게 소리 내어 설명한다"는 규칙을 만들어보세요. 팀이라면 막혔을 때 부담 없이 "잠깐 설명 좀 들어줄래요?"라고 말할 수 있는 분위기를 만드는 게 생산성에 직접적으로 도움이 돼요. 질문하는 게 민폐가 아니라, 오히려 팀 전체의 시간을 아끼는 일이라는 걸 서로 알아두는 거죠.
마무리
핵심은 한 줄이에요. 생각은 머릿속에 가둬둘 때보다 입 밖으로 꺼낼 때 더 또렷해진다. 여러분은 막혔을 때 주로 어떻게 푸나요? 동료한테 말부터 거는 편인가요, 아니면 혼자 끝까지 붙잡는 편인가요? 그리고 AI한테 설명하는 게 사람한테 설명하는 것만큼 효과가 있다고 느끼시나요?
🔗 출처: Hacker News
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공