
기술로 모든 문제를 풀 수 있다는 착각
개발자라면 한 번쯤 이런 경험이 있으실 거예요. 동료가 뭔가 불편하다고 말하면, 듣는 척하다가 머릿속으론 이미 해결책을 설계하고 있죠. '아, 이건 자동화 스크립트 하나 짜면 끝이겠네', '이 프로세스는 리팩토링하면 되겠다' 하고요. 그런데 정작 상대방이 정말 하고 싶었던 말은 '나 지금 지쳤어'였을 수도 있거든요.
이번에 Ashley Rolfmore라는 분이 쓴 에세이 'Stop trying to engineer your way out of listening to people'은 바로 이 지점을 정면으로 짚습니다. 엔지니어링이라는 훈련이 우리에게 준 강력한 무기인 '문제 해결 사고'가, 사람 사이의 관계에선 오히려 장벽이 될 수 있다는 이야기예요.
엔지니어가 빠지기 쉬운 함정
필자가 지적하는 핵심은 이거예요. 우리는 모든 문제를 '입력이 들어오면 처리해서 출력을 내는 함수'처럼 보는 데 익숙합니다. 버그 리포트가 들어오면 재현하고, 원인 찾고, 패치하고, 배포하잖아요. 이 사이클이 몸에 배면 사람의 감정이나 불만도 똑같이 처리하려고 들게 돼요. 상대가 '요즘 온콜이 너무 힘들어요'라고 말하면 바로 '그럼 온콜 로테이션을 이렇게 바꿀까요?'라고 튀어나오는 거죠.
근데 생각해보면, 사람이 누군가에게 감정을 털어놓을 때 그 사람이 원하는 건 해결책인 경우가 의외로 적어요. '내가 이만큼 힘들다는 걸 당신이 알아줬으면 좋겠다'가 더 클 때가 많거든요. 해결책을 즉답으로 내놓는 건 마치 '네 문제는 5분이면 고칠 수 있는 사소한 거야'라고 말하는 것처럼 느껴질 수 있어요. 상대를 존중하는 것처럼 보여도 실제론 그 경험을 축소시키는 거죠.
매니저와 테크리드에게 특히 중요한 이야기
이 글이 특히 뼈를 때리는 대상은 매니저와 테크리드예요. 1:1 미팅에서 팀원이 조심스럽게 꺼낸 이야기를 '액션 아이템'으로 바꿔버리는 순간, 그 팀원은 다음부터 진짜 속마음은 숨기게 됩니다. 왜냐하면 '내가 뭐라 말하면 일이 하나 더 생기거나, 내가 일을 못 한다는 평가로 번지거나' 하는 학습이 이뤄지거든요.
필자는 이걸 조직에서 흔히 보이는 'process-ification'이라고 부르기도 해요. 사람 문제를 프로세스 문제로 치환하는 습관이에요. 누가 번아웃이다? 그럼 '웰빙 위원회'를 만들어. 팀 분위기가 안 좋다? 그럼 '정기 회고 프레임워크'를 도입해. 이렇게 구조로 덮어버리면 경영진 입장에선 '조치했다'는 안도감이 생기지만, 정작 밑바닥의 감정은 그대로거든요.
그럼 어떻게 해야 하나
글에서 제안하는 건 의외로 단순해요. 일단 듣기예요. 해결책을 꺼내기 전에, '그 얘기 좀 더 해줄래요?', '언제부터 그랬어요?', '가장 힘든 순간이 언제였어요?' 같은 질문을 먼저 던지는 거죠. 그리고 상대가 원하는 게 해결책인지, 공감인지, 아니면 그냥 누군가에게 말하고 싶었던 건지를 확인하는 거예요. '제가 같이 해결책을 찾아볼까요, 아니면 일단 들어주는 게 도움이 될까요?'라고 직접 물어봐도 괜찮고요.
이게 엔지니어한텐 꽤 어색한 스킬이에요. 우리는 'MTTR(평균 복구 시간)'을 줄이는 훈련을 오래 받아왔잖아요. 그런데 사람 문제에서는 MTTR을 줄이는 게 목표가 아니에요. 상대가 안전하다고 느끼는 공간을 만드는 게 목표죠.
업계 맥락
이 논의는 최근 몇 년간 테크 업계의 번아웃, 대규모 정리해고, 원격 근무 확산과 맞물려 계속 커지고 있어요. Google의 전설적인 'Project Aristotle' 연구도 결론이 비슷했거든요. 팀 성과를 가장 크게 좌우하는 요인은 천재적인 개인이 아니라 '심리적 안전감(psychological safety)'이었다는 거예요. 말하기 어려운 얘기를 꺼낼 수 있는 분위기요.
DORA, SPACE 같은 개발 생산성 프레임워크도 점점 '개발자 경험(developer experience)'의 정성적 측면을 강조하는 방향으로 옮겨가고 있고요.
한국 개발자에게 주는 시사점
한국 개발 조직은 연차 문화와 수직적 커뮤니케이션 관성이 여전히 남아 있어서, 주니어가 '힘들다'고 말하는 데 드는 용기가 다른 나라보다 크다고 생각해요. 그래서 시니어나 리드 포지션에 계신 분들이 이 글의 메시지를 한 번 새겨두시면 좋겠어요. 팀원이 어렵게 꺼낸 말 앞에서, 해결책을 내기 전에 3초만 멈추고 '더 듣기'를 선택해보시는 거요.
주니어 입장에서도 유용한 교훈이 있어요. 동료가 고민을 얘기할 때, 나도 모르게 '야 그건 이렇게 하면 되잖아'라고 하던 습관을 한 번 점검해보시면 관계의 질이 꽤 달라집니다.
마무리
코드는 고칠 수 있지만 사람은 고치는 게 아니에요. 같이 살아가는 거죠. 최근에 동료의 얘기를 들을 때, 여러분은 해결책을 내놓으셨나요, 아니면 끝까지 들어주셨나요?
🔗 출처: Hacker News
TTJ 코딩클래스 정규반
월급 외 수입,
코딩으로 만들 수 있습니다
17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.
"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"
실제 수강생 후기- 비전공자도 6개월이면 첫 수익
- 20년 경력 개발자 직강
- 자동화 프로그램 + 소스코드 제공