가장 큰 프로덕션 위험은 문제를 알아차리고도 말하지 않은 엔지니어일 수 있습니다

AI 요약

월요일 배포를 앞둔 목요일, 데이터베이스 마이그레이션에서 이상을 발견한 엔지니어가 있습니다. 테스트도 통과하고 대시보드에도 경고가 없지만 뭔가 불안합니다. 이미 세 번 검토한 일을 다시 꺼내기 어렵다고 느낀 엔지니어는 결국 “괜찮을 것 같습니다”라고 말합니다. 배포 뒤 서비스가 중단되자 팀은 왜 미리 알아채지 못했는지 묻습니다. 실제로는 누군가 알아챘지만, 문제를 말하는 비용이 침묵하는 비용보다 크게 느껴졌습니다.

심리적 안전감은 불편한 말을 할 수 있는가의 문제입니다

저자는 심리적 안전감(Psychological Safety)을 서로 친절하게 대하는 분위기나 갈등을 피하는 상태로 보지 않습니다. 팀원이 대인 관계의 위험을 감수해도 안전하다고 믿는 상태라는 Amy Edmondson의 정의를 소개한 뒤, 엔지니어링 팀에 맞춰 “나를 나쁘게 보이게 할 수도 있는 말을 할 수 있는가”라고 풀어 씁니다. 실수를 인정하거나, 다른 사람의 판단에 반대하거나, 나쁜 소식을 전하거나, 모른다고 말하는 순간에 팀의 반응을 살펴보면 됩니다.

말을 부드럽게 하려다 우려를 흐리는 것도 문제입니다. 설계 검토에서 확장성 우려를 “작은 생각”이나 “막을 정도는 아니다”라고 표현하면, 듣는 쪽은 큰 문제가 없다고 받아들일 수 있습니다. 말한 사람은 우려를 제기했다고 생각하지만, 관리자는 위험이 없다고 이해합니다. 저자는 사람을 공격하지 않으면서 문제를 분명히 말해야 한다고 설명합니다. 예를 들어 “트래픽이 두 배가 되면 큐가 단일 병목이 될까 걱정됩니다. 결정 전에 그 가정을 시험해 볼까요?”라고 말할 수 있습니다.

실수와 반대 의견을 다루는 방식

실수를 보고한 사람에게 “어떻게 이런 일이 생기게 했나요?”라고 먼저 묻기보다, 빠르게 알린 점에 감사를 표하고 서비스를 안정시킨 다음 원인과 바꿀 점을 살펴보는 편이 낫습니다. 심리적 안전감은 책임을 묻지 않는다는 뜻이 아닙니다. 실수를 보고해도 비난받지 않도록 하면서, 무엇이 통제 가능했고 절차를 어떻게 바꿀지 확인하는 방식입니다.

상급자에게 반대할 때는 사람과 결정을 분리합니다. “이 설계는 틀렸습니다” 대신 우려의 근거와 예상 결과를 설명하고 가정을 시험하자고 제안합니다. 반대 의견을 듣는 쪽도 “이미 결정했습니다”라고 막기보다 “제가 놓친 게 무엇인가요?” 또는 “어떤 근거가 있으면 다시 검토할까요?”라고 물을 수 있습니다. 지위가 높은 사람일수록 “모르겠습니다”라고 말하기 어려워지므로, 먼저 자신의 불확실성을 드러내 질문해도 괜찮다는 신호를 주는 일도 필요합니다.

나쁜 소식은 일찍 듣고, 문제 발견을 추가 업무로 만들지 않습니다

문제를 발견한 엔지니어가 해결책까지 마련한 뒤에야 알리려 하면 대응할 시간이 줄어듭니다. “마감일을 놓칠 수 있습니다. 아직 해결책은 없지만 지금 알려야 합니다”라고 먼저 공유하는 편이 낫습니다. 관리자는 “다음 주 금요일보다 오늘 아는 편이 낫습니다. 무엇이 바뀌었고 선택지는 무엇인가요?”라고 응답할 수 있습니다. 나쁜 소식을 일찍 전한 사람을 벌주면 더 나은 소식을 얻는 게 아니라 더 늦은 소식을 듣게 됩니다.

리더는 우려나 반대 의견을 들은 첫 순간에 방어부터 하기보다 “더 말해 주세요”, “무엇이 걱정되나요?”, “우리가 틀렸다면 어떤 일이 생기나요?”라고 물어볼 수 있습니다. 눈을 굴리거나 말을 끊는 작은 반응도 다음에 문제를 꺼내지 말라는 신호가 될 수 있습니다. 리더가 아닌 구성원도 근거와 예상 결과를 명확히 말하고 확신의 정도를 함께 밝힐 수 있지만, 조직 문화를 고치는 책임까지 혼자 져야 하는 것은 아닙니다. 솔직한 말을 반복해서 방어적으로 받아들이거나 무시하는 환경은 말하기 기술만으로 바뀌지 않습니다.

저자는 대화 원칙으로 POA, 즉 Polite(예의), Open(개방성), Assertive(단호함)를 제시합니다. 예의를 지키되 호기심을 갖고, 실제 우려를 흐리지 않고 말하는 방식입니다. 이 원칙이 올바른 기술 결정을 보장하지는 않지만, 팀이 이미 알고 있는 정보를 더 많이 드러내면 불확실성에 일찍 대응할 여지가 생깁니다.

Reddit 반응

• @u/DelusionalPianist — 제가 아는 사람들 중 상당수는 말해도 개인적으로 얻는 게 거의 없기 때문에 입을 다뭅니다. 심하면 “또 다른 난장판이네요. 이제 당신이 맡으세요”라는 상황이 됩니다. 이미 퇴사할 마음을 먹었고, 말해도 아무것도 바뀌지 않는다고 생각해서 그러기도 합니다.
  • @u/AralSeaMariner — 맞습니다. 문제가 생기지 않도록 막았다는 사실은 입증하기 어렵습니다. 말한 뒤 조정이 이뤄지고 배포가 잘 끝나도, 어떤 곳에서는 괜한 이유로 절차를 늦춘 까다로운 사람 취급을 받을 수 있습니다.
  • @u/surveysaysno — “문제만 가져오지 말고 해결책도 가져오라”는 말을 들을 때마다, 그런 논리가 딥워터 호라이즌 폭발 같은 문제로 이어진다고 말하고 싶습니다. 상황을 설명하는 데 불이익이 있으면 중요한 맥락이 빠집니다.
• @u/MissiveFinding6111 — “어, 이거 이상한데”라고 말할 때마다 그걸 조사하고 해결할 책임이 누구에게 돌아오는지 아시죠? 바로 저입니다.
  • @u/coderqi — 원래 하던 일도 그대로 하면서 말입니다.
  • @u/RoomyRoots — 보상도 제대로 없고요.
  • @u/Khaka-Semeniuk — 문제를 알아챈 대가는 매번 더 많은 문제입니다.
• @u/throwaway09234023322 — 다른 분들 말에 동의합니다. 99%의 경우 관리자는 발견한 사람에게 고치라고 하고, 다른 업무를 덜어 주지도 보상하지도 않으니 사람들이 말하지 않습니다.
  • @u/Haunting_Ratio_795 — 틀렸습니다. 20%의 경우에는 관리자가 PIP로 보복합니다.
• @u/panther_ra — 이상한 동작을 봤을 때 침묵하면 아무 일도 생기지 않습니다. 말해 봐야 보너스도 못 받고 시간을 쓰게 됩니다.
  • @u/badguy84 — 담당 업무니까 보너스를 받지 않는다는 말 자체는 동의할 수 있습니다. 하지만 문제를 발견하면 추가 업무를 떠안거나, 출시를 막는 사람 취급을 받습니다. IT 조직 대부분에서 업무 소유권과 거버넌스는 엉망입니다.
• @u/homelaberator — 체르노빌을 다룬 작품을 최근에 봤는데, 그런 문화가 얼마나 흔한지 생각하게 됐습니다. 상황을 개선하려면 결함을 인정할 수 있어야 합니다. 사람들은 보복 걱정 없이 반대하고 솔직하게 말할 수 있어야 합니다. 항공 업계는 책임자를 찾기보다 무엇이 잘못됐고 재발을 어떻게 막을지 살피는 방식의 장점을 보여 줍니다. 누군가 실수했다면 왜 그런 행동을 했는지, 어떤 상황이 그 행동을 가능하게 했는지, 막을 감독 절차는 왜 없었는지 물어야 합니다.
• @u/WorkHardPlayLittle — 얼마 전 떠난 직장에서는 제가 틀렸다고 말하거나 반대하면 관리자가 제가 무례하고 못된 사람인 것처럼 몰아갔습니다. 조용히 있으면 시니어 엔지니어답게 의견을 내지 않는다고 지적받았습니다. 어느 쪽이든 답이 없어서 새 직장으로 옮겼습니다. 한 달 뒤 팀 전체와 관리자까지 해고됐습니다.
• @u/neopointer — 보안 문제를 제기했지만 아무도 조치하지 않았습니다. 나중에 외부 사람들이 같은 문제를 찾아 버그 바운티로 신고하자 갑자기 급히 고쳐야 하는 일이 됐습니다.
• @u/ScrumpyIT — 댓글을 읽어 보면 문제는 엔지니어가 아닌 것 같습니다. “이상한데요”라고 말한 사람이 그 일을 떠안아 기존 업무까지 해야 한다면, 침묵은 합리적인 선택입니다. 의견을 내는 팀은 문제를 발견한 일과 해결하는 일을 분리합니다. 발견한 사람은 공유하고, 팀이 처리 가치와 담당자를 함께 정합니다. 문제를 알아챈 사람이 자동으로 떠맡지 않습니다. 실제로 중요한 문제로 드러났을 때 누가 발견했는지 공개적으로 말해 주는 것도 중요합니다.

원문: ShiftMag / 번역·요약: Trawling