기획자의 눈빛이 더 혼란스러워 보입니다. 아마 개발자라면 누구나 한 번쯤 겪어봤을 겁니다. 내게는 너무 당연한 용어가, 상대방에게는 외계어처럼 들리는 상황 말이죠. 마케터에게 프로젝트를 설명하다가, 디자이너와 협업하다가도 이런 벽에 부딪힙니다. 심지어 부모님께 내가 하는 일을 소개하다가도 말이죠. 문제는 기술 용어가 어려워서가 아닙니다. 우리가 '설명'이 아니라 '번역'만 하고 있기 때문입니다. 오늘은 개발자가 비개발자에게 기술 용어를 진짜로 쉽게 설명하는 방법을 알아보겠습니다.

왜 우리는 설명을 못 할까?

지식의 저주(Curse of Knowledge)

심리학에서는 이를 '지식의 저주(Curse of Knowledge)'라고 부릅니다. 어떤 것을 너무 잘 알게 되면, 그것을 모르던 시절을 기억하지 못하게 되는 현상이죠. 개발자에게 '변수'는 너무 기본 개념입니다. 수십 년째 써온 개념이니까요. 하지만 비개발자에게 "변수에 값을 할당한다"는 말은 완전히 새로운 외계어입니다.

실제로 제가 신입 시절, 선배 개발자에게 물었습니다. "비동기 처리가 정확히 뭔가요?"

선배는 이렇게 답했습니다. "콜백 큐에 들어간 함수가 이벤트 루프를 통해 콜스택으로 올라가는 거지."

저는 더 혼란스러워졌습니다. 콜백 큐? 이벤트 루프? 콜스택? 하나를 물었더니 세 개의 새로운 용어가 튀어나왔죠. 이것이 바로 지식의 저주입니다. 전문가는 기본 개념을 설명할 때도 전문 용어로 설명합니다. 왜냐하면 그것이 가장 정확하고 효율적이니까요. 하지만 상대방이 그 용어를 모른다면, 설명은 오히려 독이 됩니다.

추상적 개념의 함정

기술 용어의 두 번째 문제는 대부분이 '눈에 보이지 않는' 추상적 개념이라는 점입니다. 책상, 의자, 사과처럼 만질 수 있는 게 아니라, 머릿속에서만 존재하는 개념이죠. 그래서 비유 없이는 이해하기 어렵습니다.

"클라우드가 뭐예요?"라고 물으면, 대부분 이렇게 답합니다.

"서버를 직접 관리하지 않고 필요할 때 컴퓨팅 리소스를 빌려 쓰는 거예요."

이 설명은 기술적으로 정확합니다. 하지만 '컴퓨팅 리소스'가 뭔지 모르는 사람에게는 여전히 안개 속입니다. 추상어를 또 다른 추상어로 설명하는 셈이니까요. 반면, 이렇게 설명하면 어떨까요?

"집에서 김치냉장고 사는 대신, 필요할 때만 마트 냉장 보관함 빌려 쓰는 거예요. 전기세도 안 나오고, 고장 나면 마트에서 알아서 고쳐주죠. 클라우드도 똑같아요. 내 컴퓨터에 프로그램 깔지 않고, 필요할 때 인터넷으로 빌려 쓰는 거예요."

갑자기 이해가 되기 시작합니다. 추상적 개념이 구체적 사물로 바뀌는 순간, 머릿속에 그림이 그려지니까요.

맥락 없는 설명

세 번째 문제는 '왜'를 빼먹고 '무엇'만 설명하는 것입니다. 상대방은 이 기술이 왜 필요한지, 어떤 문제를 해결하는지 모르는데, 갑자기 정의부터 듣게 되는 거죠.

"Docker가 뭐예요?"라고 물으면 대부분 이렇게 시작합니다.

"컨테이너 기반 가상화 플랫폼이에요."

상대방은 '컨테이너'도 모르고, '가상화'도 처음 듣는데 정의부터 나오니 당연히 이해가 안 됩니다.

대신 문제 상황부터 설명하면 어떨까요?

"프로그램을 만들었는데, 내 컴퓨터에선 잘 되는데 다른 사람 컴퓨터에선 안 돌아가는 경우가 많아요. 윈도우냐 맥이냐, 파이썬 버전이 뭐냐에 따라 달라지거든요. 그래서 '프로그램+필요한 환경'을 통째로 박스에 담아서 옮기는 방법을 만들었어요. 그게 Docker예요. 어디서든 그 박스만 열면 똑같이 작동하죠."

맥락이 생기니까 이해가 쉬워집니다. 사람들은 '무엇'보다 '왜'를 먼저 알아야 관심을 갖고, 관심이 있어야 이해하려고 노력하니까요.

쉽게 설명하는 3가지 핵심 원칙

1) 상대방이 아는 것에서 시작하라

좋은 설명은 항상 상대방의 세계에서 출발합니다. 상대방이 이미 알고 있는 개념, 경험했던 일상, 익숙한 사물에 빗대어 설명할 때 비로소 낯선 기술 용어가 친근하게 다가옵니다. 새로운 지식은 기존 지식과 연결될 때 가장 빠르게 이해되기 때문입니다.

나쁜 예시: "캐시는 메모리에 임시 저장하는 거예요."
좋은 예시: "교과서 읽다가 중요한 페이지에 포스트잇 붙이잖아요? 나중에 다시 처음부터 안 찾고 바로 그 페이지 펼 수 있죠. 캐시가 그런 거예요. 자주 쓰는 데이터를 바로 꺼낼 수 있게 가까운 곳에 메모해 두는 거죠."

2) 구체적인 이미지를 그려라

추상적 개념을 구체적 사물로 전환하세요. 머릿속에 그림이 그려지지 않는 설명은 기억에 남지 않습니다. 사람들은 추상적인 정의보다 구체적인 이미지를 훨씬 쉽게 이해하고 오래 기억합니다. "시스템"이나 "프로세스" 같은 추상어 대신, 도서관, 식당, 우체국처럼 누구나 아는 장소와 사물로 치환해 보세요.

데이터베이스 설명하기

나쁜 설명: "데이터베이스는 데이터를 구조화해서 저장하는 시스템입니다."
좋은 설명: "도서관을 상상해 보세요. 책(데이터)이 있고, 사서(데이터베이스 관리 시스템)가 있고, 책 찾는 방법(쿼리)이 있죠.

작가 이름으로 찾을 수도 있고, 제목으로 찾을 수도 있어요. 사서에게 ‘한강 작가의 <소년이 온다>라는 책 있나요?’라고 물으면, 사서가 서가에 가서 찾아줍니다. 이게 바로 데이터베이스예요."

3) '왜'를 먼저 설명하라

기술의 '무엇'보다 '왜'가 먼저입니다. 어떤 기술이 왜 필요한지, 어떤 문제를 해결하기 위해 만들어졌는지를 먼저 설명하면 맥락이 생깁니다. 맥락이 있어야 세부 내용이 의미 있게 들리고, 상대방도 능동적으로 이해하려 노력하게 됩니다. 정의와 스펙부터 나열하면 상대방은 처음부터 흥미를 잃습니다.

프론트엔드/백엔드 설명하기

나쁜 순서: "프론트엔드는 HTML, CSS, JavaScript로 만들고요, 백엔드는 서버 사이드 로직을 담당해요."
좋은 순서: "웹사이트를 만들 때 두 가지가 필요해요. 첫째, 사용자가 보고 클릭하는 화면(프론트엔드)이고, 둘째, 버튼 누르면 실제로 일이 일어나게 하는 뒷단 시스템(백엔드)이죠. 예를 들어, 쿠팡에서 '구매하기' 버튼 누르면, 버튼(프론트엔드)을 클릭하는 거지만, 실제로는 뒤에서 재고 확인하고, 결제 처리하고, 배송 접수하는 일(백엔드)이 일어나는 거죠."

이런 설명은 조심하세요

전문 용어를 전문 용어로 설명하기

나쁜 예시: "쿠버네티스는 컨테이너 오케스트레이션 도구예요."
좋은 예시: "프로그램 여러 개를 자동으로 켜고 끄고 관리해 주는 관리자예요. 마치 공연 무대에서 조명, 음향, 배우 입장 타이밍 다 조율하는 연출자 같은 거죠. 예를 들어 쿠팡 앱을 쓰는 사람이 갑자기 100만 명으로 늘어나면, 쿠버네티스가 자동으로 서버를 10대에서 100대로 늘렸다가, 새벽에 사용자가 줄면 다시 10대로 줄여서 비용을 절약합니다."
왜 문제인가? '컨테이너'와 '오케스트레이션'이라는 새로운 전문 용어 2개를 추가로 설명해야 하는 악순환에 빠집니다. 하나를 물었는데 세 개를 들으면 상대방은 더 혼란스러워집니다.

정확함에 집착하지 않기

완벽히 정확한 설명보다, 이해 가능한 설명이 낫습니다. 기술적으로 엄밀히 말하면 "브라우저는 HTML 파서와 CSS 엔진과 JavaScript 인터프리터로 구성된 렌더링 엔진을..."이 맞지만, "인터넷 주소 치면 웹사이트 보여주는 프로그램"이면 충분합니다.

실제 사례: 주니어 개발자가 기획자에게 설명하다가 "정확히는 TCP/IP 프로토콜 위에서 HTTP 요청을 보내고..."라고 시작했습니다. 기획자는 "그냥 데이터 주고받는다고 하면 안 돼요?"라고 되물었죠. 100점짜리 정확한 설명보다 70점짜리 이해 가능한 설명이 훨씬 유용합니다. 학술 논문이 아니라 소통이 목적이니까요.

예시 없이 개념만 설명하기

정의만 나열: "인터페이스는 서로 다른 시스템 간 상호작용을 위한 접점입니다."

이건 정의입니다. 설명이 아니죠. 국어사전처럼 정확하지만 머릿속에 아무 이미지도 그려지지 않습니다.

예시와 함께: "리모컨을 생각해 보세요. TV 내부가 어떻게 작동하는지 몰라도, 버튼만 누르면 채널이 바뀌잖아요. 그 버튼들이 바로 인터페이스예요. ATM기도 마찬가지죠. 은행 시스템이 어떻게 돌아가는지 몰라도 화면 버튼만 누르면 돈이 나옵니다. 사용자와 복잡한 시스템 사이를 연결해 주는 간단한 창구가 인터페이스입니다."

추상적 개념이 구체적 사물로 바뀌는 순간, 친절한 개발자에 한발자국 더 나아가게 되었습니다.

설명 능력을 키우는 실전 방법

1) 어린이 테스트

주변에 어린이가 있다면 한번 설명을 해보세요. 어린이가 이해할 수 있다면 누구나 이해할 수 있습니다. 실제로 파인만이라는 물리학자는 "복잡한 개념을 초등학생에게 설명할 수 없다면, 당신도 제대로 이해하지 못한 것"이라고 했습니다.

실전 연습 방법:

명절에 조카가 "삼촌/이모는 무슨 일 해요?"라고 물으면 절호의 기회입니다
"클라우드 컴퓨팅"을 설명하려다 막힌다면, "넷플릭스에서 영화 보잖아? 그 영화가 삼촌 컴퓨터에 저장된 게 아니라 먼 곳 큰 컴퓨터에 있는 거야"라고 바꿔보세요
초등학생이 고개를 끄덕이면 성공, 눈을 깜빡이면 다시 설명

2) 비유 수집 습관

좋은 비유를 만나면 메모를 해보세요.

블로그에소 글을 읽다가
유튜브 강의를 보다가
동료의 설명을 듣다가

"오, 이 비유 좋은데?" 싶으면 바로 노트에 적어두세요. 나중에 써먹을 수 있습니다.

실제 활용 예시: 저는 노션에 '비유 사전' 페이지를 만들어뒀습니다. "Docker = 이사용 박스", "API = 식당 메뉴판", "Git Branch = 평행 세계" 같은 비유들을 모아두니, 설명할 일이 생기면 바로 꺼내 쓸 수 있더군요. 특히 선배 개발자들의 설명을 들을 때 "지금 이 비유 진짜 좋다" 싶으면 그 자리에서 폰 메모장에 적습니다.

3) 기술 블로그를 비전공자 언어로 쓰기

기술 블로그를 쓸 때는 독자를 '비전공자'로 설정해 보세요. 내가 아는 것을 독자도 안다고 가정하지 마세요. 오히려 "이 글을 처음 코딩을 접하는 사람이 읽는다면?"이라고 상상하며 쓰면, 불필요한 전문 용어를 걸러내고 핵심만 남기는 훈련이 됩니다. 이 과정을 반복하다 보면 어느새 복잡한 개념을 누구에게나 쉽게 풀어내는 설명 근육이 붙습니다.

구체적 실천법:

글 쓸 때 "기술 용어 제로 챌린지"를 해보세요. API, 서버, 클라이언트 같은 단어 없이 설명하기
첫 문단은 반드시 일상 비유로 시작하기
비전공자 친구에게 읽혀보기
이해 안 되는 부분이 나오면 문단 전체를 다시 쓰기

실전 비유 사전

서버 / 클라이언트

"음식점을 생각해 보세요. 손님(클라이언트)이 주문하면, 주방(서버)에서 요리해서 갖다줍니다. 손님은 주방이 어떻게 생겼는지, 어떻게 요리하는지 몰라도 되죠. 여러분이 네이버에서 '날씨'를 검색(주문)하면, 네이버 서버(주방)가 기상청 데이터를 가공해서 화면에 보여줍니다. 손님이 많으면 주방을 늘리듯이, 사용자가 많아지면 서버도 증설합니다."

배포 / 업데이트

"게임 업데이트 받아본 적 있죠? 회사에서 버그 고치고 새 기능 추가한 걸 여러분 폰/컴퓨터로 보내는 거예요. 배포도 똑같아요. 개발자가 만든 새 버전을 실제 사용자들이 쓸 수 있게 서버에 올리는 거죠. 예를 들어 카카오톡에서 '이모티콘 선물하기' 기능을 새로 만들었다면, 이걸 앱스토어와 구글 플레이에 올려서 사용자들이 받을 수 있게 하는 과정이 배포입니다."

버그

"책에 오타가 있는 것처럼, 프로그램에도 실수가 있어요. '로그인' 버튼 눌렀는데 로그아웃되거나, 100원짜리 물건인데 가격이 1,000원으로 나오는 것처럼요. 작은 버그 하나가 전체 서비스를 마비시킬 수도 있어요. 그래서 개발자들은 배포 전에 버그를 찾아내려고 밤샘 테스트를 합니다."

테스트 코드

"학교 수학 문제집에 답안지가 있잖아요? 문제 다 풀고 답 맞춰보면 틀린 거 바로 알 수 있죠. 테스트 코드가 바로 그 답안지예요. 프로그램 만들 때도 '이렇게 하면 이런 결과가 나와야 한다'는 답을 미리 적어놓는 거예요. 그럼 컴퓨터가 자동으로 채점해 줍니다. 예를 들어볼게요. '2 + 3을 계산하는 계산기'를 만들었다면, 테스트 코드에는 '답은 5여야 한다'고 적어놔요. 그리고 실행하면 컴퓨터가 '정답!' 또는 '틀렸어, 6이 나왔어'라고 알려줍니다.

쿠팡 같은 쇼핑몰은 버튼이 수천 개예요. 개발자가 하나하나 다 눌러보는 건 불가능하죠. 그래서 테스트 코드가 밤새 자동으로 '이 버튼 누르면 장바구니에 담기나?', '저 버튼을 누르면 결제가 되나?' 다 확인해줍니다. 다음날 출근하면 '어제 수정한 거 문제없어요' 하고 결과 알려주는 거죠."

라이브러리 / 프레임워크

"요리할 때 양념장 직접 안 만들고 '다시다' 쓰잖아요? 개발도 마찬가지예요. 자주 쓰는 기능들을 다른 개발자들이 미리 만들어놨어요. 라이브러리는 '다시다' 같은 거고요(필요할 때 가져다 씀), 프레임워크는 '밀키트' 같은 거예요(요리 순서랑 재료가 다 정해져 있음). 카카오 로그인 기능을 직접 만들면 한 달 걸리지만, 카카오가 제공하는 라이브러리를 쓰면 하루 만에 끝납니다."

반응형 웹

"신문은 크기가 정해져 있지만, 웹사이트는 핸드폰으로도 보고 컴퓨터로도 보잖아요? 화면 크기에 따라 자동으로 레이아웃이 바뀌는 게 반응형이에요. 마치 자동으로 접히는 우산처럼요. 쿠팡을 컴퓨터로 보면 상품이 한 줄에 5개씩 보이지만, 폰으로 보면 한 줄에 2개씩 보이죠. 같은 사이트인데 기기에 맞춰 자동으로 배치가 바뀌는 겁니다."

Git / 버전 관리

"워드로 리포트 쓸 때 '최종.docx', '최종_최종.docx', '진짜최종.docx' 이렇게 파일 여러 개 만들어본 적 있죠? Git은 그걸 자동으로 정리해주는 거예요. 어제 버전, 오늘 버전, 누가 언제 뭘 고쳤는지 다 기록하고, 필요하면 예전 버전으로 되돌릴 수도 있어요. 팀 프로젝트 할 때 A가 로그인 기능 만들고, B가 결제 기능 만들어도 Git이 자동으로 합쳐줍니다. 충돌 나면 알려주기도 하고요."

설명은 배려다

좋은 코드는 읽기 쉬운 코드입니다. 변수명을 명확히 짓고, 주석을 달고, 함수를 작게 나누는 이유는 다른 사람이 읽기 쉽게 하려는 배려죠. 좋은 설명도 마찬가지입니다. "상대방이 이해할 수 있게" 설명하는 것은 배려입니다. "내 지식을 과시하는 것"이 아니라 "상대방의 눈높이에서 시작하는 것"이 진짜 전문가의 태도입니다.

다음에 누군가 "API가 뭐예요?"라고 물어올 때, 당황하지 마세요. 오히려 기회입니다. 내가 정말 이해하고 있는지 확인하고, 설명 근육을 키울 수 있는 순간이니까요. 그리고 기억하세요. 어려운 것을 어렵게 설명하는 건 쉽습니다. 어려운 것을 쉽게 설명하는 것이 진짜 실력입니다.

오늘부터 비개발자에게 기술 용어 설명한다고 생각하고 한번 연습해 보세요. 그러다 보면 어느새, 기술과 사람 사이의 다리가 되어있을 겁니다.

<참조 문헌>
[과학자의 말하기] 제1편: 왜 내 말은 아무도 못 알아들을까? - 소통에 서툰 천재들