태그 보관물: 커뮤니케이션

코드는 짰는데 설명이 안 됩니다 — 비영어권 엔지니어가 겪는 ‘설명력의 함정’

2026년 06월 07일 정보부자 댓글 남기기

코드는 짰는데 설명이 안 됩니다 — 비영어권 엔지니어가 겪는 '설명력의 함정'

알고리즘 실력보다 무서운 언어 장벽, 단순한 영어 공부가 아닌 '사고의 전환'으로 돌파하는 법

해외 취업이나 글로벌 팀 합류를 준비하다 보면 정말 당혹스러운 순간이 옵니다. 화이트보드에 코드는 완벽하게 짰는데, 막상 “왜 이렇게 짰나요?”라는 질문을 받으면 머릿속이 하얘지는 경험 말이죠. 사실 기술 면접은 단순히 알고리즘이나 아키텍처 실력을 뽐내는 자리가 아니라, 내가 가진 생각을 영어로 어떻게 전달하느냐의 싸움에 가깝습니다 [1].

저 역시 비슷한 경험이 있습니다. 기술적으로는 정답에 도달했음에도 불구하고, 그 과정을 설명하는 영어 문장이 입안에서 맴돌 때의 그 답답함은 이루 말할 수 없죠. 면접관의 고개가 갸우뚱해지는 순간, 내 기술력마저 의심받고 있다는 공포가 밀려옵니다. 여기서 우리가 깨달아야 할 핵심이 있어요. 기술 면접의 본질은 정답을 맞히는 게 아니라 ‘사고 과정의 공유’라는 점입니다. 특히 우리 같은 비영어권 엔지니어들에게 필요한 건 단순한 영어 단어 암기가 아니에요. 머릿속의 번역 단계를 과감히 제거한 ‘영어 직접 사고’와, 완벽함보다는 전달력에 집중하는 전략적인 접근이 필요합니다.

문제는 ‘영어 실력’이 아니라 ‘번역 프로세스’에 있다

많은 분이 “영어를 더 공부해야 해”라고 생각하며 단어장을 펼치지만, 사실 면접장에서 우리를 괴롭히는 건 영어 실력 그 자체보다 ‘번역 프로세스’라는 병목 현상이에요. 보통 비영어권 화자들은 이런 단계를 거칩니다. [영어 청취 → 모국어로 번역 → 모국어로 생각 → 다시 영어로 번역].

이 과정에서 아주 미세한 지연(delay)이 발생하는데, 이게 면접이라는 압박감과 만나면 엄청난 스트레스로 다가옵니다. 예를 들어, 면접관이 “Can you walk me through your thought process?”라고 물었을 때, 우리는 머릿속으로 ‘사고 과정을 설명해달라는 뜻이구나’라고 번역하고, 다시 ‘제 생각은 이랬습니다’를 영어로 바꾸느라 정작 중요한 기술적 논리를 놓치게 됩니다. 답변이 부자연스러워지고, 스스로 “내 영어가 이상한가?”라는 생각에 빠지게 되죠.

“Most non-native speakers don’t actually think in English, they translate everything.” [3]

“대부분의 비영어권 화자는 영어로 생각하지 않고 모든 것을 번역하며, 이 과정이 응답의 자연스러움을 해칩니다.”

사실 문법적으로 완벽한 문장을 만들려는 집착이 오히려 독이 되는 경우가 많아요. 적절한 단어를 찾지 못해 머뭇거리는 사이 자신감은 떨어지고, 유창성은 더 낮아 보이는 악순환에 빠지게 됩니다 [2]. 면접관은 당신의 문법 점수를 매기는 선생님이 아니라, 함께 코드를 짤 동료를 찾는 엔지니어라는 사실을 기억해야 합니다.

코딩 능력과 언어 능력 사이의 ‘인지적 간극’

더 무서운 건, 이 언어 장벽이 단순히 ‘말하기’에만 머물지 않고 실제 기술적 구현 단계까지 영향을 준다는 거예요. 예를 들어 if, unless, while 같은 제어문들은 우리 모국어와 1:1로 딱 떨어지게 대응되지 않는 경우가 많습니다. 이 미묘한 차이 때문에 개념 파악에 혼선을 겪기도 하죠 [4].

이런 ‘인지적 간극’은 코드의 퀄리티, 특히 네이밍에서 적나라하게 드러납니다. 적절한 영어 단어가 바로 떠오르지 않으니 변수명을 a, temp, 혹은 너무 포괄적인 table 같은 무의미한 이름으로 짓게 되는 경향이 있어요 [4].

// ❌ 언어 장벽으로 인해 네이밍이 모호해진 경우
function processData(data) {
  let a = []; // 무엇을 담는 배열인지 알 수 없음
  for (let i = 0; i < data.length; i++) {
    if (data[i].status === 'active') {
      a.push(data[i]); // 'activeUsers'라고 짓고 싶지만 단어가 바로 안 떠오름
    }
  }
  return a;
}

// ✅ 의도가 명확한 네이밍 (전달력 중심)
function filterActiveUsers(users) {
  const activeUsers = []; // 변수명만으로도 역할이 설명됨
  users.forEach(user => {
    if (user.isActive) {
      activeUsers.push(user);
    }
  });
  return activeUsers;
}

위 코드처럼 단순한 차이 같지만, 면접관 입장에서는 네이밍 하나가 엔지니어의 사고방식을 보여주는 지표가 됩니다. data_list라고 짓는 것과 user_transaction_history라고 명확히 짓는 것은 단순히 영어 실력의 차이가 아니라, 도메인을 얼마나 깊게 이해하고 설계했느냐의 차이로 읽히기 때문입니다. 게다가 기술적 어휘 하나를 몰라서 문장 전체의 의미가 흐릿해지는 상황이 발생하면, 내 기술력이 실제보다 낮게 평가받는 억울한 상황이 벌어지기도 하죠 [4].

전략적 돌파구: 완벽함(Perfection)보다 존재감(Presence)

그렇다면 어떻게 해야 할까요? 정답은 ‘완벽함’을 버리고 ‘존재감’을 택하는 것입니다. 면접관이 기대하는 건 원어민 수준의 발음이 아니에요. 그보다 중요한 건 자신감, 에너지, 그리고 상대의 말을 정확히 듣고 반응하는 태도입니다 [3].

실전에서 바로 써먹을 수 있는 팁 몇 가지를 공유할게요.

첫째, 정해진 답안을 통째로 외우지 마세요. 소위 ‘Tutored’ 스타일이라고 하는데, 외운 대로만 말하려다 보면 로봇처럼 들리고 예상치 못한 질문이 나왔을 때 완전히 무너집니다. 대신 본인에게 편한 단어를 사용해 자연스럽게 말하는 연습을 하세요. “I think this approach is better because…” 같은 단순한 패턴 몇 가지만 익혀두고, 그 뒤에 자신의 생각을 얹는 방식이 훨씬 유연합니다 [3].

둘째, ‘셀프 내레이션(Self-narration)’을 습관화하세요. “지금 커피를 타고 있어”, “이제 이메일을 확인해야지”처럼 일상의 행동을 영어로 묘사하는 겁니다. 코딩을 할 때도 “Now I’m creating a loop to iterate through the array”라고 중얼거려 보세요. 이렇게 하면 [영어 청취 → 영어 사고 → 영어 답변]으로 이어지는 직접 사고 회로를 구축하는 데 큰 도움이 됩니다 [3].

셋째, 모의 면접의 강도를 높이세요. 단순히 답변을 읽는 게 아니라, 누군가 내 말을 끊거나 꼬리 질문을 던지는 스트레스 상황을 시뮬레이션해야 실전에서 당황하지 않습니다. 특히 예상치 못한 질문을 받았을 때 당황하지 않고 시간을 버는 “That’s an interesting question, let me think about it for a moment” 같은 ‘필러(Filler)’ 문구를 전략적으로 활용하는 연습이 필요합니다 [5].

결국 핵심은 이 한 문장으로 요약됩니다.

“Fluency > Perfection, Practice > Fear, Trying > Avoiding” [3]

“유창함이 완벽함보다 중요하고, 연습이 두려움보다 앞서야 하며, 피하는 것보다 시도하는 것이 낫습니다.”

짚고 넘어갈 한계와 안티패턴

열심히 노력하는데도 성과가 안 난다면, 혹시 이런 ‘안티패턴’에 빠져 있지는 않은지 점검해 보세요.

가장 흔한 실수가 문법책과 단어장 위주로 공부하는 겁니다. 이건 실제 말하기 능력과는 괴리된 ‘죽은 지식’을 쌓는 일이에요. 이제는 책을 덮고 실제로 그 영어를 사용하는 환경에 자신을 던져야 할 때입니다. 오픈소스 프로젝트에 참여해 PR 코멘트를 달거나, 글로벌 개발자 커뮤니티에서 토론하는 경험이 문법책 10권보다 훨씬 효과적입니다 [3].

또한, 완벽한 문장이 구성될 때까지 침묵하는 습관은 정말 위험합니다. 면접관은 당신이 생각 중인지, 아니면 소통이 불가능한 상태인지 알 수 없거든요. 차라리 “Let me think for a second”라고 말하며 소통의 끈을 유지하세요. 침묵은 불안감을 증폭시키지만, 짧은 말 한마디는 당신이 상황을 컨트롤하고 있다는 인상을 줍니다.

마지막으로, 실패의 원인을 외부 요인(인종차별이나 면접관의 인내심 부족 등)으로 돌리는 태도는 성장을 가로막습니다. 물론 불합리한 경우가 있을 수 있지만, 언어 장벽이라는 핵심 문제를 직시하고 해결하려는 의지가 있을 때 비로소 돌파구가 보입니다 [6].

핵심 요약

면접은 정답 맞히기가 아니라 ‘함께 일하고 싶은 동료’임을 증명하는 소통 과정입니다.
번역 단계를 없애는 ‘영어 직접 사고’ 훈련이 유창성의 핵심이에요.
완벽한 문법보다 명확한 의도 전달과 긍정적인 에너지가 더 강력한 무기가 됩니다.
언어적 한계를 보완할 수 있도록 GitHub나 기술 블로그 같은 강력한 포트폴리오를 구축하세요 [6].
AI 도구(ExtraBrain 등)는 대신 말해주는 도구가 아니라, 사고를 확장하고 준비를 돕는 보조 수단으로 활용하시길 권합니다 [7, 8].

사실 저도 예전에 “풀 수는 있는데 설명할 수 없었던” 그 절망적인 기분을 잘 압니다. 내 머릿속의 정답은 금덩어리인데, 입 밖으로 나오는 건 부서진 조각들뿐인 그 느낌 말이죠. 그래서 ‘사고의 확장’을 돕는 도구들에 관심을 갖게 되었고, 그것이 ExtraBrain의 철학으로 이어졌습니다.

결국 중요한 건 ‘완벽한 영어’가 아닙니다. 조금 서툴더라도 내 생각을 전달하겠다는 ‘포기하지 않는 소통 의지’예요. 그 의지가 보일 때, 면접관은 당신의 코드 너머에 있는 진짜 실력을 알아봐 줄 겁니다.

참고 자료 (References)

1. [medium.com] I Could Solve the Problem, but I Could Not Explain It in English. That Is How ExtraBrain Started — https://medium.com/@andrewsokolov/i-could-solve-the-problem-but-i-could-not-explain-it-in-english-that-is-how-extrabrain-started-e7b88558d472 2. [reddit.com] For the non-native English speakers, what’s your biggest challenge … — https://www.reddit.com/r/interviews/comments/1l1w5en/for_the_nonnative_english_speakers_whats_your 3. [linkedin.com] Interview Tips for Non-Native English Speakers — https://www.linkedin.com/posts/mattatemujinreddy_interview-tips-especially-for-non-native-activity-7383175421674024960-jtSv 4. [dev.to] Barriers in Coding for Non-Native English Speakers — https://dev.to/knheidorn/barriers-in-coding-for-non-native-english-speakers-2c65 5. [reddit.com] How to practice job interviews as a non-native English speaker — https://www.reddit.com/r/interviews/comments/1loz4gq/how_to_practice_job_interviews_as_a_nonnative 6. [workplace.stackexchange.com] I’m a decent coder but not a native English speaker… — https://workplace.stackexchange.com/questions/144872/i-m-a-decent-coder-but-not-a-native-english-speaker-can-i-get-a-job-without-hav 7. [extrabrain.app] ExtraBrain – Local-First AI Interview & Meeting Copilot — https://extrabrain.app/ 8. [toolpilot.ai] ExtraBrain – Local-first AI interview and meeting copilot — https://www.toolpilot.ai/products/extrabrain

FAQ

비영어권 엔지니어가 기술 면접에서 겪는 가장 큰 병목 현상은 무엇인가요?

단순한 영어 실력 부족보다는 '번역 프로세스'가 문제입니다. [영어 청취 → 모국어 번역 → 모국어 생각 → 영어 번역]의 단계를 거치면서 발생하는 지연이 스트레스를 유발하고 답변의 자연스러움을 해칩니다.

언어 장벽이 실제 코딩 구현이나 퀄리티에 어떤 영향을 주나요?

제어문 등의 개념 파악에 혼선을 겪을 수 있으며, 특히 변수 네이밍에서 드러납니다. 적절한 단어가 떠오르지 않아 'a'나 'temp' 같은 모호한 이름을 사용하게 되면, 면접관에게 도메인 이해도나 설계 능력이 부족한 것으로 비춰질 수 있습니다.

영어 직접 사고 회로를 구축하기 위한 구체적인 방법은 무엇인가요?

'셀프 내레이션(Self-narration)'을 습관화하는 것이 도움이 됩니다. 일상의 행동이나 코딩 과정을 "Now I'm creating a loop…"와 같이 영어로 중얼거리며 묘사하는 연습을 통해 번역 단계 없는 사고 회로를 만들 수 있습니다.

면접 중 예상치 못한 질문을 받아 당황했을 때는 어떻게 대처해야 하나요?

완벽한 문장이 생각날 때까지 침묵하는 대신, "That's an interesting question, let me think about it for a moment"와 같은 '필러(Filler)' 문구를 전략적으로 사용하여 소통의 끈을 유지하고 시간을 버는 것이 좋습니다.

영어 말하기 능력을 키우기 위해 피해야 할 '안티패턴'은 무엇인가요?

문법책과 단어장 위주로 공부하는 것은 실제 말하기와 괴리된 '죽은 지식'을 쌓는 일입니다. 대신 오픈소스 프로젝트 참여나 글로벌 개발자 커뮤니티 토론처럼 실제로 영어를 사용하는 환경에 자신을 던지는 것이 훨씬 효과적입니다.

인사이트

나와 너, 그리고 ‘제3의 존재’: 관계의 균형을 바꾸는 심리적 메커니즘

2026년 04월 21일 정보부자 댓글 남기기

나와 너, 그리고 '제3의 존재': 관계의 균형을 바꾸는 심리적 메커니즘

단순한 이자 관계를 넘어 우리 사이에 개입하는 보이지 않는 심리적 실체, '제3의 존재(The Third Presence)'가 어떻게 인간관계와 창의적 협업의 질을 결정짓는지 분석합니다.

우리는 흔히 인간관계를 ‘나’와 ‘너’라는 두 점의 연결로 생각합니다. 대화는 주고받는 것이고, 갈등은 서로의 의견 차이에서 발생하며, 사랑은 두 사람의 감정이 맞닿을 때 일어난다고 믿습니다. 하지만 실제 삶에서 우리가 겪는 관계의 역동은 이토록 단순하지 않습니다. 분명히 두 사람이 마주 보고 있는데, 정작 대화의 흐름을 지배하는 것은 두 사람 모두의 의도가 아닌, 정체 모를 ‘무언가’일 때가 많습니다.

상대방의 사소한 말투 하나에 갑자기 분노가 치밀어 오르거나, 논리적으로는 이해가 가는데 왠지 모르게 거부감이 드는 경험을 해보셨을 겁니다. 이는 단순히 개인의 성격 결함이나 상대의 잘못이 아니라, 두 사람 사이에 형성된 보이지 않는 심리적 공간, 즉 ‘제3의 존재(The Third Presence)’가 작동하고 있기 때문입니다. 이 보이지 않는 실체는 관계의 중재자가 되기도 하지만, 때로는 소통을 가로막는 거대한 벽이 되기도 합니다.

제3의 존재란 무엇인가: 관계의 보이지 않는 삼각형

심리학과 정신분석학적 관점에서 ‘제3의 존재’는 물리적인 제3자를 의미하는 것이 아닙니다. 이는 두 사람이 상호작용하며 만들어내는 ‘공동의 심리적 장(Field)’ 또는 ‘관계적 공간’을 뜻합니다. 예를 들어, 부부 관계에서 두 사람이 공유하는 ‘역사’, ‘가치관’, ‘해결되지 않은 갈등의 앙금’ 등이 합쳐져 하나의 독립된 성격처럼 작동하는 현상입니다.

이 개념은 단순히 추상적인 이론에 그치지 않습니다. 우리가 타인과 관계를 맺을 때, 우리는 상대방 그 자체를 보는 것이 아니라 ‘나와 상대방 사이에 놓인 필터’를 통해 상대를 인식합니다. 이 필터가 바로 제3의 존재입니다. 긍정적인 제3의 존재가 형성된 관계에서는 서로의 실수를 너그럽게 이해하는 ‘신뢰의 공간’이 작동하지만, 부정적인 제3의 존재가 자리 잡은 관계에서는 작은 오해가 큰 싸움으로 번지는 ‘불신의 공간’이 지배하게 됩니다.

관계의 역동을 결정짓는 심리적 메커니즘

제3의 존재가 우리 관계에서 구체적으로 어떻게 작동하는지 이해하려면, ‘투사’와 ‘전이’라는 개념을 살펴봐야 합니다. 우리는 과거의 경험이나 상처를 현재의 관계에 투영합니다. 내가 과거에 권위적인 아버지 밑에서 자랐다면, 현재의 상사와 대화할 때 내 앞에는 ‘상사’라는 개인뿐만 아니라 ‘권위적 아버지’라는 제3의 존재가 함께 앉아 있는 셈입니다.

이때 발생하는 현상은 다음과 같습니다.

지각의 왜곡: 상대방의 중립적인 행동을 공격적으로 해석하게 만듭니다.
반응의 자동화: 현재의 상황과 무관하게 과거의 패턴대로 반응하게 합니다.
감정의 증폭: 실제 사건의 크기보다 훨씬 더 강렬한 감정적 반응을 이끌어냅니다.

결국 우리는 ‘너’와 대화하는 것이 아니라, 우리 사이에 놓인 ‘제3의 존재’와 대화하고 있는 경우가 많습니다. 이를 인지하지 못하면 우리는 끊임없이 같은 이유로 다투고, 같은 패턴의 관계 실패를 반복하게 됩니다.

창의적 협업과 ‘제3의 공간’의 긍정적 활용

제3의 존재가 반드시 갈등의 원인이 되는 것은 아닙니다. 오히려 고도의 창의성이 필요한 협업이나 예술적 파트너십에서는 이 ‘제3의 공간’을 의도적으로 구축하는 것이 핵심입니다. 두 전문가가 만나 각자의 고집을 꺾고, 두 사람의 능력을 합친 것 이상의 ‘제3의 결과물’을 만들어내는 과정이 바로 긍정적인 제3의 존재를 창조하는 과정입니다.

성공적인 팀워크를 발휘하는 조직은 ‘우리 팀만의 문화’라는 제3의 존재를 가지고 있습니다. 개개인의 역량보다 더 강력한 팀의 정체성이 형성되면, 구성원들은 서로를 감시하거나 경쟁하지 않고도 공동의 목표를 향해 유기적으로 움직입니다. 이는 ‘나의 의견’과 ‘너의 의견’이 충돌하는 것이 아니라, ‘우리 사이의 최선(The Third Way)’을 찾는 과정으로 진화하기 때문입니다.

제3의 존재를 다루는 기술적 접근과 한계

그렇다면 이 보이지 않는 존재를 어떻게 관리할 수 있을까요? 가장 중요한 것은 ‘객관화’입니다. 갈등이 발생했을 때 “너는 왜 그래?”라고 상대를 비난하는 대신, “우리 사이에 지금 어떤 흐름이 흐르고 있는가?”라고 질문을 던지는 것입니다.

이러한 접근 방식의 장단점은 다음과 같습니다.

구분	장점 (Pros)	단점 및 한계 (Cons)
객관화 전략	감정적 충돌을 줄이고 문제의 본질에 집중 가능	상대방이 이를 ‘회피’나 ‘분석적 태도’로 느껴 거부감을 가질 수 있음
공동 공간 구축	심리적 안전감을 형성하여 창의적 시너지 극대화	구축하는 데 많은 시간과 상호 신뢰라는 전제 조건이 필요함

실전 적용: 건강한 관계를 위한 액션 가이드

지금 당장 당신의 관계 속에 숨어 있는 제3의 존재를 건강하게 바꾸고 싶다면, 다음의 단계를 실천해 보십시오.

패턴 인식하기: 반복적으로 발생하는 갈등의 지점을 기록하십시오. 특정 상황에서 항상 같은 감정이 든다면, 그것은 당신과 상대의 문제가 아니라 그 사이에 형성된 ‘부정적 제3의 존재’가 신호를 보내는 것입니다.
언어의 전환: “너 때문에 화가 나”라는 ‘너-중심’ 화법에서 “우리 사이에 지금 긴장감이 흐르는 것 같아”라는 ‘관계-중심’ 화법으로 바꾸십시오. 문제의 주체를 사람이 아닌 ‘공간’으로 옮기는 것입니다.
새로운 기억 심기: 제3의 존재는 누적된 경험으로 만들어집니다. 의도적으로 작은 성공 경험(함께 무언가를 완수하거나, 진심 어린 사과를 주고받는 것)을 쌓아 관계의 필터를 교체하십시오.
경계 설정하기: 상대방의 투사가 나에게 전이되지 않도록 심리적 경계를 세우십시오. 상대가 화를 내는 이유가 정말 나 때문인지, 아니면 그 사람이 가진 과거의 제3의 존재 때문인지 구분하는 연습이 필요합니다.

결론: 관계의 주인으로 살아남기

결국 인간관계의 성숙함이란, 내 앞에 있는 사람이 온전한 그 사람으로 보이게 하는 능력을 갖추는 것입니다. 우리 사이에 끼어든 과거의 망령, 편견, 오해라는 ‘제3의 존재’를 걷어내고, 오직 지금 이 순간의 ‘너’와 ‘나’로 마주하는 것이죠.

기업의 리더든, 가정의 부모든, 사회의 일원이든 우리는 모두 관계 속에서 살아갑니다. 내가 통제할 수 없는 상대방을 바꾸려 노력하는 것은 불가능에 가깝습니다. 하지만 우리 사이에 형성된 ‘제3의 존재’는 우리가 함께 노력한다면 충분히 바꿀 수 있습니다. 오늘 당신의 소중한 사람과 대화할 때, 두 사람 사이에 어떤 보이지 않는 존재가 함께 앉아 있는지 잠시 살펴보시기 바랍니다. 그 존재를 인식하는 순간, 당신은 비로소 관계의 주도권을 쥐게 될 것입니다.

FAQ

The Third Presence의 핵심 쟁점은 무엇인가요?

핵심 문제 정의, 비용 구조, 실제 적용 방법, 리스크를 함께 봐야 합니다.

The Third Presence를 바로 도입해도 되나요?

작은 범위에서 실험하고 데이터를 확인한 뒤 단계적으로 확대하는 편이 안전합니다.

실무에서 가장 먼저 확인할 것은 무엇인가요?

목표 지표, 대상 사용자, 예산 범위, 운영 책임자를 먼저 명확히 해야 합니다.

법률이나 정책 이슈도 함께 봐야 하나요?

네. 데이터 수집 방식, 플랫폼 정책, 개인정보 관련 제한을 반드시 점검해야 합니다.

성과를 어떻게 측정하면 좋나요?

비용, 전환율, 클릭률, 운영 공수, 재사용 가능성 같은 지표를 함께 보는 것이 좋습니다.

지금 바로 시작할 수 있는 실무 액션

현재 팀의 AI 활용 범위와 검증 절차를 먼저 문서화합니다.
작은 파일럿 프로젝트로 KPI를 정하고 2~4주 단위로 검증합니다.
보안, 품질, 리뷰 기준을 자동화 도구와 함께 연결합니다.

인사이트

당연한 단어가 갑자기 어려워지는 이유: 정의의 역설과 인지적 함정

2026년 04월 20일 정보부자 댓글 남기기

당연한 단어가 갑자기 어려워지는 이유: 정의의 역설과 인지적 함정

우리가 일상적으로 사용하는 쉬운 단어들이 막상 정의하려 할 때 복잡해지는 현상을 통해, 인간 인지의 작동 방식과 언어적 한계가 비즈니스 커뮤니케이션에 주는 시사점을 분석합니다.

우리는 왜 ‘사랑’이나 ‘행복’을 정의하지 못하는가

어린 시절, 우리는 ‘사랑’이나 ‘정의’, ‘행복’ 같은 단어들을 아주 자연스럽게 사용했습니다. 특별한 사전적 정의를 배우지 않았음에도 그 단어가 어떤 맥락에서 쓰이는지 본능적으로 이해했기 때문입니다. 하지만 성인이 되어 누군가에게 “정확히 사랑이 무엇인지 정의해 보세요”라는 요청을 받는 순간, 우리는 갑작스러운 당혹감에 휩싸입니다. 분명히 알고 있는 개념인데, 그것을 언어라는 틀에 가두려는 순간 단어는 미끄러지듯 빠져나가고 설명은 점점 더 복잡해집니다.

이 현상은 단순한 어휘력의 부족이 아닙니다. 이는 ‘정의의 복잡성(Definitional Complexity)’이라 불리는 인지적 메커니즘의 결과입니다. 우리는 개념을 ‘직관적’으로 파악하는 능력과 그것을 ‘명시적’으로 서술하는 능력을 서로 다르게 사용합니다. 직관은 패턴 인식에 기반하지만, 정의는 논리적 분석에 기반하기 때문입니다. 이 간극이 바로 우리가 쉬운 단어 앞에서 작아지는 이유입니다.

직관적 이해와 명시적 정의의 충돌

인간의 뇌는 효율성을 극대화하기 위해 많은 정보를 ‘뭉텅이(Chunking)’ 형태로 저장합니다. 예를 들어 ‘의자’라는 단어를 들었을 때, 우리 뇌는 다리가 네 개고 등받이가 있는 가구라는 세부 명세서를 읽는 것이 아니라, ‘앉을 수 있는 도구’라는 전체적인 이미지와 경험을 즉각적으로 불러옵니다. 이것이 직관적 이해입니다.

문제는 우리가 이 직관을 ‘정의’로 변환하려 할 때 발생합니다. 정의를 내린다는 것은 해당 개념이 가진 고유한 속성을 추출하고, 동시에 다른 개념과 구별되는 경계선을 긋는 작업입니다. 이때 다음과 같은 인지적 충돌이 일어납니다.

경계의 모호성: ‘의자’를 정의하려 하면, 1인용 소파는 의자인가? 벤치는 의자인가? 등받이 없는 스툴은 의자인가? 라는 질문에 직면합니다.
순환 논리의 함정: ‘행복은 만족스러운 상태이다’라고 정의하면, 다시 ‘만족이란 무엇인가’라는 질문으로 이어지는 무한 루프에 빠집니다.
맥락의 상실: 단어는 상황에 따라 의미가 변하지만, 정의는 고정된 값을 요구합니다. 이 과정에서 단어가 가진 풍부한 맥락이 거세됩니다.

비즈니스 현장에서 발생하는 ‘정의의 저주’

이러한 언어적 복잡성은 개인의 철학적 고민에 그치지 않고, 기업의 실무 현장에서 치명적인 커뮤니케이션 오류로 이어집니다. 특히 ‘효율성’, ‘혁신’, ‘고객 만족’과 같은 추상적인 단어들이 프로젝트의 핵심 KPI로 설정될 때 비극이 시작됩니다.

예를 들어, 경영진이 “우리 서비스의 ‘사용자 경험(UX)’을 개선하라”고 지시했다고 가정해 봅시다. ‘사용자 경험’은 누구나 이해하는 쉬운 단어처럼 보이지만, 이를 정의하려는 순간 팀원마다 해석이 갈립니다. 개발자는 ‘로딩 속도의 단축’으로, 디자이너는 ‘심미적 인터페이스’로, 마케터는 ‘구매 전환율의 상승’으로 정의합니다. 각자가 가진 직관적 이해는 일치하는 것처럼 보였으나, 명시적 정의 단계에서 서로 다른 방향을 바라보고 있었던 것입니다.

결국 정의되지 않은 쉬운 단어는 조직 내에서 ‘합의된 오해’를 만들어냅니다. 모두가 고개를 끄덕이지만, 결과물은 서로 딴판인 상황이 발생하는 이유가 바로 여기에 있습니다.

정의의 복잡성을 극복하는 전략적 접근

그렇다면 우리는 어떻게 이 인지적 함정을 피하고 명확한 소통을 할 수 있을까요? 모든 단어를 사전적으로 정의하는 것은 불가능하며 비효율적입니다. 대신 다음과 같은 실무적 접근법이 필요합니다.

1. 긍정적 정의보다 ‘부정적 정의’ 활용하기

어떤 개념이 무엇인지 정의하기 어렵다면, 그것이 ‘무엇이 아닌지’를 먼저 규정하십시오. “혁신이란 무엇인가?”라는 질문에 답하기 어렵다면, “우리 팀이 생각하는 혁신이 절대 아닌 것은 무엇인가?”를 논의하는 것이 훨씬 빠르고 정확합니다. 제외 대상을 명확히 함으로써 개념의 외곽선을 그리는 방식입니다.

2. 추상적 단어를 ‘행동 지표’로 치환하기

단어의 정의에 매몰되지 말고, 그 단어가 구현되었을 때 나타나는 ‘관찰 가능한 행동’을 정의하십시오. ‘친절한 서비스’라는 단어를 정의하는 대신, ‘고객이 매장에 들어왔을 때 3초 이내에 눈을 맞추고 인사하는 것’으로 치환하는 것입니다. 형용사를 동사로 바꾸는 순간, 정의의 복잡성은 사라지고 실행 가능성이 생깁니다.

3. 공유된 사례(Case)를 통한 동기화

백 마디의 정의보다 하나의 구체적인 사례가 더 강력합니다. “우리가 지향하는 ‘고품질’의 기준은 A사의 B 제품과 같은 수준이다”라고 명시하는 것입니다. 이는 뇌의 패턴 인식 능력을 활용하여, 복잡한 정의 과정을 건너뛰고 즉각적인 개념 동기화를 가능하게 합니다.

실무자를 위한 액션 아이템: 커뮤니케이션 체크리스트

지금 당장 협업 중인 프로젝트에서 다음과 같은 단어들을 사용하고 있다면, 잠시 멈추고 아래 단계를 적용해 보시기 바랍니다.

단어 식별: 회의록이나 기획서에서 ‘최적화’, ‘고도화’, ‘합리적’, ‘효율적’과 같은 추상적 형용사를 찾아내십시오.
가설적 정의 요청: 상대방에게 “제가 이해한 ‘최적화’는 [A라는 상태]를 의미하는데, OO님께서 생각하시는 정의와 일치하나요?”라고 질문하십시오.
운영적 정의(Operational Definition) 수립: 해당 단어가 달성되었음을 어떻게 측정할 것인지(Metric)를 합의하십시오. 측정 가능한 수치가 곧 그 조직에서의 ‘정의’가 됩니다.

결론: 언어의 한계를 인정하는 것이 소통의 시작이다

단어가 정의되는 순간 그 단어의 생동감은 사라질지도 모릅니다. 하지만 비즈니스와 협업의 세계에서는 ‘모호한 풍요로움’보다 ‘명확한 빈곤함’이 훨씬 안전합니다. 우리가 쉬운 단어를 정의하는 데 어려움을 겪는 것은 지능의 문제가 아니라 인간 인지의 본성입니다.

중요한 것은 우리가 서로 다른 정의를 가지고 있을 수 있다는 사실을 인지하는 것입니다. 당연하다고 생각하는 단어일수록 의심하고, 정의하려 애쓰기보다 구체적인 행동과 사례로 소통하십시오. 그것이 정의의 복잡성이라는 늪에서 빠져나와 실질적인 성과를 만드는 가장 빠른 길입니다.

FAQ

Definitional Complexity: Why Simple Words Become Difficult the Moment When we Try to Defin의 핵심 쟁점은 무엇인가요?

핵심 문제 정의, 비용 구조, 실제 적용 방법, 리스크를 함께 봐야 합니다.