---
title: "'사람 얘기 듣기'를 엔지니어링으로 치환하지 마라"
published: 2026-04-19T20:09:09.000Z
canonical: https://jeff.news/article/1836
---
# '사람 얘기 듣기'를 엔지니어링으로 치환하지 마라

소프트웨어 업계가 '사람 말을 잘 듣는 일'을 프레임워크·시스템·사회기술 시스템 같은 용어로 포장해 회피한다는 문제 제기 글. 저자는 듣기를 방해하는 전형적 가정들(전문 분야 편향, 기술자/비기술자 이분법, 말=생각 가정 등)을 나열하면서 이런 오해가 놓친 인사이트와 기술 부채로 되돌아온다고 지적한다.

- 저자가 소프트웨어 업계에서 반복해서 목격하는 패턴 — 문제의 뿌리는 두 가지
  - 사람들이 서로 **얘기를 안 함**
  - 얘기해도 **듣지를 않음**
- 디자이너·프로덕트 쪽에서 첫 번째 문제에 접근할 때 꺼내는 해법이 주로 "프레임워크", "시스템", 요즘 유행하는 "사회기술 시스템(socio-technical system)" 같은 용어들
  - 저자 왈 — 엔지니어가 친숙해할 단어로 포장해서 **"사람 얘기 듣기"를 회피**하는 짓
  - "더 나은 시스템이 필요한 게 아니라, 그냥 일을 안 하고 있는 것"

### 듣는다는 걸 오해하는 방식들

- **듣기 ≠ 요구한 걸 그대로 만들어주기**
  - JTBD(Jobs To Be Done), Outcome Driven Innovation, UX 쪽의 공감 지도(empathy mapping) 등이 이 부분은 이미 충분히 다룸
- **전문 분야 편향** — "이건 당연히 알겠지?" 함정
  - 상대가 해당 영역 전문가라도 내가 아는 그 지점은 모를 수 있음
  - 상대가 "뭘 아는지"를 먼저 파악해야 제대로 들을 수 있음
- **"기술적"이라는 단어를 하나로 취급하기**
  - 소프트웨어 개발자들이 유난히 빠지는 함정
  - 기술은 광범위한 지식 영역의 스펙트럼이지 "내가 했던 개발자 경험"이 곧 "기술적"인 게 아님
  - 사람을 "기술자 vs 비기술자" 이분법으로 보는 순간 놓치는 인사이트가 생김
- **모두가 나랑 같은 자원을 갖고 있다고 가정**
  - 같은 건강 상태라도 관리 방식·가용 에너지가 다름
  - 경제적 여유에 따른 리스크 선호도 차이
- **한 명의 특성으로 전체를 일반화**
  - "나이 든 사람은 컴퓨터 잘 모른다" 같은 편견
  - "모든 여성이 네 엄마나 딸은 아니다"
- **사람(조직)이 정적이라는 가정**
  - 거시적으로는 성격 자체가 시간에 따라 바뀜
  - 미시적으로는 회사에서의 페르소나와 집에서의 모습이 다름, 스트레스 상황에서 판단이 달라짐
  - 이게 바로 **"고정형 프로젝트 관리가 소프트웨어 개발에서 안 통하는 근본 이유**" — 요구사항 박아놓는 동안 사람이 변하고, 기대치가 누적되면서 결과물과 현실이 벌어짐
- **말한 것 = 생각한 것이라는 가정**
  - 대다수는 자기가 의도대로 말한다고 믿지만 실제론 그렇지 않음
- **사람을 판단하기**
  - 문서를 엉망으로 써놓고 이해 못 한 사람을 탓하는 버릇
  - 누군가를 무시하는 순간 제대로 듣는 건 사실상 불가능
- **80명을 "개인 1명 × 80"으로 취급**
  - 오히려 B2B가 B2C보다 더 인간적임 — 지저분한 관계, 조직도와 실제 영향력의 괴리, 집단 역학이 추가로 얹힘

### 안 듣는 걸 방치하면

- 가장 돈 되는 인사이트를 놓치고, 경쟁사에 추월당함
- 의외로 **기술 부채의 원천**이 되기도 함 — 오해 하나가 코드에 새 로직을 추가시키고, 그게 나중에 짐이 됨
- 저자의 결론: "언제 우리가 안 듣고 있는지 알아차리는 단서 정도는 될 것" — 더 잘 듣자는 자기반성 글

## 핵심 포인트

- 진짜 문제는 '더 나은 시스템'이 아니라 사람 얘기 듣기를 회피하는 것
- 듣기 ≠ 상대가 원한다고 말하는 걸 그대로 만들어주기
- '기술적 vs 비기술적' 이분법이 개발자가 빠지는 대표 함정
- 사람은 정적이지 않음 → 고정형 프로젝트 관리가 안 통하는 근본 이유
- 오해 하나가 코드에 불필요한 로직을 추가시키고 기술 부채의 원천이 됨

## 인사이트

요구사항 수집 단계의 오해를 '더 정교한 프로세스'로 해결하려는 시도가 역설적으로 기술 부채를 낳는다는 관점. 프레임워크 도입 전에 '내가 왜 이 사람을 안 듣고 있는가'를 먼저 점검하라는 에세이.