복잡한 기술 개념을 비전문가에게 설명해야 했던 경험이 있다면, 그 상황에서 어떻게 접근했는지 이야기해 주세요.

복잡한 기술 개념을 비전문가에게 설명한 경험은 팀 프로젝트 발표 때 있었습니다. 머신러닝 모델 성능을 발표해야 했는데, 팀원 중 절반이 통계 배경이 없는 디자이너·기획자였습니다. 저는 정확도 수치 대신 '100명 중 틀리는 사람이 몇 명인지'로 바꿔서 설명했고, 모델을 자동 분류 규칙을 만드는 과정으로 비유했습니다. 그 방식이 통했고, 팀원들이 모델 선택 이유를 이해한 뒤 UI에 불확실성 표시를 추가하자는 아이디어를 직접 냈습니다. 앞으로도 기술을 설명할 때 상대방의 언어로 번역하는 것이 핵심이라는 것을 기억하겠습니다. 이해가 없으면 협업이 없고, 번역이 없으면 이해가 없습니다. 앞으로도 기술을 설명할 때 상대방의 배경 지식을 먼저 확인하고 그 언어로 시작하는 방식을 유지하겠습니다. 전문 용어는 공통 언어가 생긴 뒤에야 써야 합니다. 비전문가에게 이해받는 것이 전문가에게 인정받는 것만큼 중요합니다. 소통은 내가 아는 것을 전달하는 게 아니라 상대가 이해하게 만드는 것입니다.

인턴십 때 API 연동 작업 중 기획팀에게 중간 보고를 해야 했던 순간이 있었습니다. "서버 간 통신이 실패한다"는 말로는 상황이 전달되지 않았고, 기획자들은 "왜 기능이 안 되는지"만 알고 싶어 했습니다. 저는 API를 식당 주문서로 비유했습니다. 주문서가 형식이 틀리면 주방이 이해를 못 하고, 그게 지금 우리가 겪는 상황이라고 설명했습니다. 무엇이 틀렸는지 명확히 가리킬 수 있다는 걸 보여주자 기획자들이 "그럼 얼마나 걸려?"라는 실질적인 질문으로 넘어왔습니다. 이후에는 기술적 내용을 공유할 때 반드시 한 줄 요약과 예상 영향을 먼저 말하는 방식을 택하고 있습니다. 이해하지 못한 사람을 탓하기보다 전달 방식을 바꾸는 쪽이 훨씬 빠르다는 걸 그때 배웠습니다. 소통의 책임은 말한 사람에게 있고, 이해가 됐는지는 상대의 반응으로 확인해야 합니다.

학과 스터디에서 데이터베이스 트랜잭션 개념을 비전공 학우에게 설명할 기회가 있었습니다. "원자성", "격리성" 같은 용어를 그대로 쓰자 표정이 굳었고, 저는 설명 방식을 바꿔야 했습니다. 편의점 계산대에서 카드가 승인되고 영수증이 나오는 과정으로 비유했습니다. 카드는 됐는데 영수증이 안 나오면 다시 처음으로 돌아가야 한다 — 그게 트랜잭션이라고 설명하자 고개가 끄덕여졌습니다. 비유를 찾는 데 가장 많은 시간을 쏟았지만, 그만큼 이후 설명이 짧아졌습니다. 학우가 나중에 "그 개념이 생각보다 중요한 거였네"라고 말했을 때, 그게 설명이 통했다는 신호라고 느꼈습니다. 이제는 기술 개념을 처음 접하는 사람에게 설명할 때 용어보다 상황을 먼저 그리는 방식을 씁니다. 정확한 설명과 이해 가능한 설명은 다르고, 둘 다 필요한 순간이 있습니다.