비개발자 친구들에게
내 일을 설명하는 일이 어려운 이유
"그래서 컴퓨터 고치는 거야?" — 이 질문에 몇 번 답했는지 모른다
명절 때마다 반복되는 그 대화
개발자가 된 이후로 명절은 조금 피곤해졌다. 친척들이 "요즘 뭐 해?"라고 물어볼 때마다 같은 패턴이 반복된다. 어떻게 설명해도 "아 그렇구나~"로 끝나고, 며칠 뒤 다시 "그래서 컴퓨터 고치는 거야?"라는 질문이 온다.
처음엔 제대로 설명하려고 애썼다. 웹사이트가 어떻게 작동하는지, 프론트엔드가 뭔지, 데이터가 어떻게 흐르는지. 그 설명이 끝나갈 즈음이면 상대방의 눈이 조금씩 흐려졌다. 지금은 다르게 대답한다. 근데 여전히 완벽하지 않다.
이 글은 그 어려움의 정체가 뭔지, 왜 개발 일이 유독 설명하기 어려운지, 그리고 그나마 효과 있었던 방법들을 솔직하게 정리한 것이다.
실제로 들어온 질문들
왜 개발 일은 유독 설명이 어려울까
다른 직업들을 생각해보면 이해가 된다. 의사는 "사람 몸 고쳐요", 선생님은 "아이들 가르쳐요", 요리사는 "음식 만들어요" — 한 문장으로 핵심이 전달된다. 그런데 개발자는 뭐가 문제일까.
첫째, 결과물이 눈에 안 보인다. 목수는 완성된 의자가 있다. 요리사는 완성된 음식이 있다. 개발자가 3주 동안 만든 건 버튼 하나일 수 있다. 그 버튼이 왜 3주가 걸렸는지를 설명하려면 API 설계, 상태 관리, 예외 처리, 테스트까지 얘기해야 한다. 눈에 보이는 결과물과 실제 작업량의 간극이 엄청나다.
둘째, 직군이 너무 세분화돼 있다. "개발자"라는 단어 하나 뒤에 프론트엔드, 백엔드, 풀스택, 데브옵스, 데이터 엔지니어, AI 엔지니어... 같은 직군이 수십 개 있다. 이걸 다 설명하면 청중이 떠나고, 안 하면 "다 같은 거 아니야?"가 돼버린다.
셋째, 추상화 레벨이 너무 높다. 내가 하는 일의 대부분이 개념이다. 데이터 구조, 상태, API, 컴포넌트 — 이걸 비유 없이 설명하면 상대방은 빠르게 흥미를 잃는다. 그렇다고 비유를 들면 "완전히 같은 건 아닌데..."가 되어서 계속 말을 덧붙이게 된다.
개발 일을 설명하기 어려운 건 상대방이 이해를 못 해서가 아니다. 보이지 않는 것을 언어로 전달하는 게 본질적으로 어렵기 때문이다.
가장 많이 받는 오해들
IT 기기 수리는 별도 직군이 있다. 개발자는 소프트웨어를 만드는 사람이다. 하드웨어 문제는 대부분 나도 모른다.
웹 개발자와 앱 개발자는 다른 기술을 쓴다. 내가 웹을 잘 해도 iOS 앱은 처음부터 배워야 한다. 수술 잘 하는 의사가 치과 치료도 한다는 게 아닌 것처럼.
하루 중 절반 이상이 회의, 코드 리뷰, 슬랙, 기획 검토다. 순수하게 코딩만 하는 시간은 생각보다 적다. 개발자는 협업직이다.
보안 전문가는 완전히 다른 분야다. 웹 개발자가 해킹을 할 수 있는 건 요리사가 칼을 잘 다뤄서 수술도 할 수 있다는 말만큼 논리가 없다.
가장 당혹스러웠던 대화들
비유가 효과 있었던 것들 — 그리고 한계
설명을 잘 하려고 여러 비유를 써봤다. 어떤 건 통했고, 어떤 건 안 통했다. 효과 있었던 것들을 정리한다.
백엔드는 건물의 구조(기둥, 배관, 전기), 프론트엔드는 인테리어(벽지, 가구, 조명). 사용자는 인테리어만 보지만 구조가 없으면 무너진다. 대부분 "아~" 하고 넘어간다. 가장 많이 쓰는 비유다.
코드는 레시피다. 컴퓨터라는 요리사한테 "이 재료를 이 순서로 이렇게 만들어라"고 아주 정밀하게 설명하는 것. 레시피 한 줄이 틀리면 전혀 다른 요리가 나온다. 이 비유는 비교적 잘 통한다.
개발팀은 영화 제작팀이다. 기획자는 시나리오 작가, 디자이너는 미술감독, 개발자는 연출팀. 사용자가 보는 건 완성된 영화지만, 그 뒤에 수백 명의 작업이 있다. 직관적이지만 "그럼 넌 뭐야?"가 나온다.
API를 설명할 때 쓴다. "내가 카카오톡 앱에서 메시지를 보내면, 그게 서버라는 우체국을 거쳐서 상대방 폰으로 전달돼. 그 우체국 통로를 API라고 해." 추상적인 개념을 물리적으로 풀 때 좋다.
모든 비유에는 "완전히 같은 건 아니지만..."이 붙는다. 비유가 너무 잘 맞아떨어지면 "그럼 개발이 건물 짓는 거랑 같네?"라는 결론이 나온다. 비유는 입구일 뿐이고, 세부로 들어가면 결국 새로운 설명이 필요하다.
지금 내가 쓰는 설명 방법
몇 년을 시행착오한 끝에 지금은 상대방에 따라 다르게 답한다. 상황별로 정리하면 이렇다.
부모님께: "네이버, 카카오 같은 웹사이트 만드는 사람이에요. 사람들이 폰에서 누르는 버튼, 사진, 글씨 — 그거 화면에 뜨게 만드는 거예요."
친구들한테: "앱이나 웹사이트 만들어. 사용자가 보는 화면 쪽. 버튼 누르면 반응하고, 데이터 불러오고, 그런 거."
전혀 모르는 어른께: "IT 회사에서 인터넷으로 서비스 만드는 일 해요." — 더 설명 안 한다.
관심 있어 하는 사람한테: 그때부터 진짜 설명을 시작한다. 그 전에는 아무리 잘 설명해도 소용없다.
이걸 깨달은 게 꽤 늦었다. 설명을 더 잘 해야 한다고 생각하면서 계속 다른 비유를 찾고 있었는데, 어느 날 알았다. 상대방이 진짜 알고 싶어서 물어보는 게 아닌 경우가 많다는 걸.
"뭐 해요?"는 종종 대화 시작을 위한 인사다. 깊게 알고 싶어서 묻는 게 아닐 때가 많다. 그걸 모르고 5분짜리 설명을 시작하면 상대방은 이미 딴 생각이고, 나만 열심히 설명하는 상황이 된다.
진짜 관심 있는 사람은 "그래서 그게 어떻게 돼요?" 같은 후속 질문을 한다. 그 신호가 오기 전까지는 짧게 답하고 상대방 반응을 본다.
반대로 — 비개발자 일을 이해 못 한 경우
솔직하게 고백하면, 나도 비개발자 친구들의 일을 잘 모른다. 법무팀 친구가 "계약서 검토"를 설명할 때, 마케터 친구가 "퍼포먼스 마케팅"을 얘기할 때, HR 친구가 "조직 문화 구축"을 얘기할 때 — 나도 "아~ 그렇구나"하면서 반쯤 넘어간 적이 있다.
설명이 어렵고 이해하기 어려운 건 개발 일만의 문제가 아니었다. 자기 전문성의 내부를 외부에 전달하는 건 모든 분야가 어렵다. 개발이 특히 추상적인 건 맞지만, 어느 정도는 모든 직업이 가진 문제다.
내 일을 설명 못 하는 게 부끄럽지 않아도 된다. 상대방이 몰라도 괜찮다. 모든 걸 이해받을 필요는 없다. 가끔은 "IT 쪽 일 해요"로 충분하다.
그래도 이건 좋다 — 이해받은 순간들
언젠가 고등학교 친구가 진지하게 물어왔다. "야, 너 만든 거 실제로 쓰는 사람 있어?" 그 질문에 내가 만든 기능의 사용자 수, 그게 실제 사람들 삶에 어떻게 쓰이는지 얘기했더니 "오 진짜? 와 그거 신기하다"는 반응이 왔다. 기술 설명이 아니라 영향에 대해 얘기했더니 달랐다.
또 한 번은 부모님이 내가 만든 페이지를 직접 쓰는 경험을 했을 때였다. 설명보다 경험이 훨씬 강력했다. "아, 이게 네가 만든 거야?" 그 한 마디가 모든 설명보다 더 이해를 만들었다.
기술이 아니라 결과와 영향으로 설명하는 것. "나는 Next.js로 SSR 최적화를 하고 있어"가 아니라 "내가 버튼 하나를 고쳤더니 하루에 3천 명이 더 구매했어" — 이런 식으로. 사람들이 공감하는 건 기술이 아니라 결과다.
개발자 4년 차에 든 결론은 이거다. 내 일을 완벽하게 설명하는 건 애초에 불가능하다. 설명의 완성도보다 상대방이 얼마나 알고 싶어 하는지가 더 중요하다. 그리고 모든 사람이 내 일을 이해해야 할 필요는 없다.
엄마가 내가 뭘 만드는지 정확히 몰라도 괜찮다. "컴퓨터 관련 일"로 이해하셔도 된다. 중요한 건 내가 매일 만들고 있는 것들이 누군가의 삶을 조금 편하게 만들고 있다는 것이다. 그 가치를 나는 알고 있고, 그것으로 충분하다.
💬 비개발자한테 내 일을 설명하다 겪은 에피소드 있으신가요?
가장 당황스러웠던 질문, 의외로 잘 통했던 비유, 혹은 완전히 포기하고 "컴퓨터 일 해요"로 끝낸 경험 — 어떤 이야기든 댓글로 나눠주세요. 공감되는 에피소드를 공유해주시면 함께 웃을 수 있을 것 같습니다.
'개발자 > 멘탈 라이프스타일' 카테고리의 다른 글
| 개발자가 슬럼프 왔을 때 해결한 방법 (0) | 2026.07.23 |
|---|---|
| 혼자 일하는 개발자의 외로움과 극복법 (0) | 2026.07.16 |
| 개발자가 워라밸 지키는 현실적인 방법 (0) | 2026.07.09 |
| 재택근무와 출근 중 어떤 게 더 생산적이었나 (0) | 2026.07.02 |
| 개발자의 건강 관리 - 거북목, 손목터널, 눈 건강 | 직접 겪고 배운 것들 (0) | 2026.06.25 |
