지식의 저주
무심코 지나칠 수 있는 오해
지식의 저주라고 들어본 적이 있는가?
지식의 저주란 내가 알고 있는 것을 상대방도 당연히 알고 있을 것이라고 생각하는 오해를 의미한다. 지식의 저주는 알고 있는 지식의 편차로 인해 발생한다. 예컨대, 노래를 알고 있는 사람이 손가락으로 리듬을 치는 경우, 다른 사람은 손가락만 보고 리듬을 맞추기 어렵다.
나의 업무 영역을 기반으로 설명하면 다음과 같다. 시니어 개발자가 주니어 개발자를 가르칠 때, 시니어 개발자가 설명하는 내용을 듣고 주니어 개발자가 그 내면의 경험과 고민까지 알아차리기는 어렵다. 즉, 지식과 경험이 수반된 결과물을 설명할 때, 두 당사자 간에 지식의 저주가 발생할 수 있다.
최근에 내가 경험한 사례를 공유하고자 한다.
최근 팀에 주니어 개발자들이 합류했다. 대부분 백앤드 영역을 맡아서 개발했던 분들이다. 백앤드란 서비스에 필요한 요구사항 중 서버단에 들어가야 할 로직을 구현하는 업무를 뜻한다. 그들은 로직 구현 업무에 상당히 익숙하다. 명확한 요구사항을 전달하면 로직을 빠르게 구현한다. 처음 보는 오픈소스 코드도 단기간에 분석해서 수정할 수 있는 정도이다.
하지만 아키텍처링은 다소 미흡한 편이다. 아키텍처란 시스템의 전체적 구조를 고려한 설계이다. 예컨대, 아키텍처는 Database와의 연관성, 서비스 간 호출 구조, 서비스를 구성하는 인프라 등을 모두 아우른다. 아키텍처를 잘못 설계하면 아무리 좋은 코드를 작성해도 품질이 나아지기 힘들다. 구조를 잘못 설계한 건물은 좋은 자제를 사용해도 무너진다. 그래서 숙련된 개발자는 현재 시스템 구조와 구현 방식을 고려하여 효율적인 아키텍처를 도입하여 기반을 튼튼하게 다진다. 좋은 코드는 올바른 아키텍처링을 만났을 때 비로소 빛을 발한다.
내가 담당하는 DevOps 영역에서 아키텍처링은 큰 비중을 차지한다. DevOps 엔지니어는 인프라를 생성하고 관리하며, 개발 조직의 퍼포먼스 향상과 안정적인 서비스 지원을 위해 빌드/배포 파이프라인(CI/CD) 및 자동화를 담당한다. 그들은 서비스 요구사항에 맞는 적합한 인프라 아키텍처를 설계하고, 이를 효율적이고 안정적으로 운영할 수 있는 빌드/배포 파이프라인을 제공한다. 이 과정에서 자동화를 위한 일부 개발 영역이 들어갈 수도 있다. 다만, 규모가 큰 조직이 아니라면 자동화를 도입하기 전에 아키텍처링에 많은 시간을 할애한다.
나는 새로 합류한 주니어들에게 DevOps를 교육하는 역할을 맡았다. 이전에 해보지 못했던 아키텍처링을 스스로 고민해 보고 Fail Fast 정신으로 빠르게 시도할 수 있는 환경을 만들어 주었다. 그 과정에서 당연히 질문이 쏟아져 나왔고, 나는 이 질문들에 대해 하나씩 답변을 해주었다.
문제는 나의 미숙한 교육 방식에서 발생했다. 나는 질문사항에 대해 최대한 자세하게 설명하고자 노력했다. 하지만 실제로 그들이 알고 있는 지식의 범위는 나의 예상과 많이 달랐다. 내 기준에서 "자세하게" 설명하고 있었지만 그들은 모호하게 표면만 이해하고 있었다. 당연히 과제는 진전이 잘 되지 않았고, 반복적인 질문이 지속적으로 나오기 시작했다.
이 지식의 저주를 깨닫기까지 한 달이라는 시간이 걸렸다. 한 달 전에 기본 교육을 진행한 적이 있었는데, 반응을 보면서 그들이 대부분의 내용을 이해하고 있다고 생각했다. 다음에 교육할 때는 자연스럽게 기초 내용을 생략했는데, 여기서부터 지식의 저주가 시작된 것으로 파악된다.
현재, 어떻게 하면 이 저주를 풀 수 있는지 고민 중이다. 아직 해결책을 찾지는 못했다. 다만, 지식의 저주가 발생하고 있는 상황을 인지하고 있기에 해결책은 금방 찾아나갈 수 있으리라 믿는다. 우선 아래의 도서를 읽고 메시지 전달 방식을 바꿔보려고 한다.
(책을 읽고 배운 내용은 다른 포스트에서 다룰 예정이다)