Kind Engineering: 친절함이 더 나은 엔지니어를 만드는 이유

팀에서 조용히, 종종 오래 일한 엔지니어들 사이에서 이런 말이 나옵니다: "여기서는 내가 진짜 생각하는 것을 말할 수 있어." 단순하게 들립니다. 실제로는 드문 일이며 — 엄청나게 가치 있습니다. 이것을 가능하게 하는 조건들은 우연히 찾아오지 않습니다. 친절하기로 선택하는 사람들이 한 번의 상호작용을 통해 하나씩 만들어 갑니다.

상냥한 것이 아닙니다. 친절한 것입니다. 그 차이는 처음 보이는 것보다 훨씬 중요하며, 잘못 이해하면 팀에 큰 비용을 치르게 됩니다.

이 글은 친절한 엔지니어링이 실제로 무엇을 의미하는지에 대한 실용적인 탐구입니다 — 코드 리뷰, 장애 대응, 피드백 대화, 그리고 함께 일하는 사람들을 어떻게 대우하는지에 대한 조용한 선택들이 실제로 중요한 순간들에서. 여기 있는 많은 생각은 kind.engineering에 의해 형성되었으며, 건강한 팀을 만들고자 하는 사람이라면 꼭 읽어봐야 할 자료입니다. 아래 아이디어는 저 자신의 합성과 경험입니다; 그 사이트를 필수 추가 읽기로 고려하세요.

친절함은 상냥함과 같지 않습니다

친절함과 상냥함의 혼동은 놀랍도록 많은 기능 장애 팀들의 원인입니다. 상냥함은 편안합니다 — 어색한 순간을 부드럽게 하고, 평화를 유지하며, 따뜻하게 느껴집니다. 하지만 종종 공허합니다. 상냥한 사람은 데모에 심각한 결함이 있을 때 훌륭했다고 말합니다. 상냥한 사람은 비판적으로 보일 수 있는 댓글을 남기기보다 pull request를 승인합니다. 상냥한 사람은 회의에서 동의하고 나쁜 결정이 앞으로 나아가는 동안 조용히 있습니다.

친절함은 다릅니다. 친절함은 당신을 위하기 때문에 진실을 말합니다. 어려운 것을 말하지만, 숨게 만들기보다 성장하고 싶게 만드는 방식으로. kind.engineering의 저자는 이것을 아름답게 포착합니다: 상냥함은 케이크를 가져오고; 친절함은 당신의 매니저에게 가서 "이 사람이 탁월한 일을 하고 있습니다 — 다음 리드 역할에 추천해 주세요"라고 말합니다. 하나의 행동은 쉽고 비용이 없습니다. 다른 하나는 노력과 다른 사람의 미래에 대한 투자가 필요합니다.

친절함이 세 가지 중 꾸준히 가장 어려운 것임을 주목하세요. 솔직하고, 사려 깊으며, 동시에 투자되어야 합니다. 상냥함은 쉽습니다. 친절함은 노력이 필요합니다. 그리고 불친절함은, 단기적인 효율성이 어떻든, 거의 항상 시간이 지나면서 상황을 악화시킵니다.

친절함이 힘을 배가시키는 이유

친절함이 단지 있으면 좋은 것 — 도덕적 열망이지만 실용적인 레버가 아님 — 에 불과하다면, 그래도 추구할 가치가 있습니다. 하지만 고성과 팀의 연구와 실제 경험은 그것이 더 강한 무언가임을 시사합니다: 엔지니어링 산출물에 대한 진정한 힘의 배가입니다.

그 메커니즘은 심리적 안전감을 통해 작동합니다 — 조직 연구자 Amy Edmondson의 용어로, 이후 구글의 Project Aristotle에 의해 대중화되었습니다. 그녀의 발견은 많은 산업의 팀에서 확인된 것으로, 팀의 효과성을 가장 크게 예측하는 것은 구성원의 평균 IQ, 프로세스의 우아함, 또는 도구의 품질이 아닙니다. 팀원들이 대인 위험을 감수하는 것이 안전하다고 느끼는지 여부입니다: "멍청한" 질문을 하고, 모른다는 것을 인정하고, 확실하기 전에 잠재적인 문제를 지적하고, 시니어 동료와 의견을 달리하는 것.

심리적으로 안전한 팀에서, 버그가 의심되는 주니어 엔지니어는 그렇게 말합니다. 설계 결정을 이해하지 못하는 엔지니어는 질문합니다 — 잘못된 것을 만들며 사흘을 보내는 대신. 위험한 배포 선택을 발견한 사람은 다른 누군가가 해주기를 바라는 대신 리뷰 회의에서 말합니다. 이것들은 극적인 용기의 행위가 아닙니다. 문제를 일찍 잡는 팀과 프로덕션에서 잡는 팀을 구분하는 일상적인 정보 흐름입니다.

친절함이 심리적 안전감을 구축합니다. 질문에 어떠한 경멸의 흔적도 없이 응답할 때, 그 사람 — 그리고 모든 관찰자 — 이 미래에 질문하는 것을 더 안전하게 만듭니다. 비난 없는 장애 리뷰를 진행할 때, 다음에 아슬아슬한 순간을 보고하는 것을 더 안전하게 만듭니다. 솔직하고 배려 있는 피드백을 주고 수신자가 그로부터 성장할 때, 팀 전체는 피드백이 위협이 아닌 선물임을 배웁니다.

실용적인 성과들이 빠르게 복리로 쌓입니다:

• 버그가 더 일찍 드러납니다. 사람들이 무능해 보이는 것을 두려워하지 않을 때, 실제 장애가 되기 전에 반쯤 형성된 우려를 지적합니다.
• 학습이 가속화됩니다. 질문이 제기됩니다. 지식이 공유됩니다. 주니어가 더 빠르게 성장합니다.
• 이탈이 줄어듭니다. 존중받고 투자받는다고 느끼는 팀에서는 사람들이 떠나지 않습니다. 스스로가 위축된다고 느끼는 팀에서 떠납니다.
• 결정이 개선됩니다. 다양한 관점이 실제로 표현되며, 가장 큰 목소리가 방을 지배하기 때문에 자기 검열되지 않습니다.

실천 속의 친절함

철학은 금요일 오후 4시에 pull request에 댓글을 남겨야 할 때까지 유용합니다. 친절한 엔지니어링이 실제로 중요한 순간에 어떻게 보이는지입니다.

코드 리뷰에서

코드 리뷰는 아마도 엔지니어링에서 가장 높은 빈도의 친절함 테스트입니다. 잘 수행되면, 팀이 가진 가장 가치 있는 실천 중 하나입니다. 불친절하게 수행되면, 사람들이 일을 제출하는 것을 피하게 만들고, 분노로 리뷰를 미루거나, 완전히 이탈하게 만드는 두려움의 원천이 됩니다.

역동성을 지속적으로 개선하는 몇 가지 원칙:

• 무엇에 대해 댓글 달기 전에 이유를 이해하세요. 판결 내리기 전에 열린 질문을 하세요. "콜백 대신 폴링 접근법을 사용한 이유가 궁금합니다 — 내가 놓치고 있는 제약이 있나요?"는 대화를 초대합니다. "콜백을 써야 합니다"는 대화를 닫습니다.
• 사소한 지적에 라벨을 붙이세요. "Nit: 여기서 더 설명적인 변수 이름을 쓰겠지만, 그냥 두어도 완전히 괜찮아요." 그 한 단어는 작성자에게 말합니다: 이것은 선택적이고, 이것 때문에 차단하지 않으며, 더 큰 댓글들이 진짜 주의가 필요한 것입니다.
• 코드와 사람을 구분하세요. "이 함수가 여러 가지를 합니다"는 코드에 대한 피드백입니다. "당신은 항상 너무 많은 것을 하는 함수를 작성합니다"는 사람에 대한 피드백입니다. 하나는 유용합니다; 다른 하나는 그저 불쾌합니다.
• 많은 피드백에는 동기식 대화로 전환하세요. 접근법에 대해 여섯 가지 주요 우려가 있다면, 벽 같은 댓글은 공개적인 질책처럼 느껴질 수 있습니다. 10분짜리 통화는 더 친절하고, 더 빠르며, 실제로 문제를 해결할 가능성이 더 높습니다.

친절하게 코드 리뷰하는 방법에 대한 동반 글에서도 이 주제를 더 깊이 다루고 있습니다.

장애 대응에서

장애는 팀 문화에 대한 스트레스 테스트입니다. 압박 하에 실제 결과와 함께, 모든 습관 — 좋은 것과 나쁜 것 — 이 증폭됩니다. 가장 친절하고 효과적인 팀은 비난 없는 회고를 진행합니다: 사람들은 가진 정보와 도구로 행동했으며, 시스템이 실패할 때는 개인이 아닌 시스템 — 이 변화가 필요하다는 가정.

이것은 책임감을 낮추는 것이 아닙니다. 같은 실수가 고립되어 일어나는 경우가 드물다는 것을 이해하는 것입니다. 누군가가 잘못된 설정을 배포한 것은 배포 프로세스가 두 번째 눈을 요구하지 않았기 때문입니다. 누군가가 알림을 놓친 것은 그날 아침 발생한 40개 중 하나였기 때문입니다. 비난할 사람을 찾는 것은 종결처럼 느껴지지만 아무것도 고치지 않습니다. 비난 없는 포스트모템은 사람이 빠진 프로세스의 공백을 찾아서 대신 그것을 고칩니다.

회의에서

친절한 엔지니어는 공간을 만듭니다. 말하지 않은 사람을 알아채고 초대합니다. 빠른 말로 조용한 사색가들을 압도하지 않습니다. 가장 적극적이었던 사람들뿐만 아니라 모든 사람이 같은 이해를 갖고 떠날 수 있도록 결정을 요약합니다. 약속을 이행하여 사람들의 시간과 말이 의미 있게 다루어지도록 합니다.

거절할 때

역설적으로, 명확하고 일찍 거절하는 것이 예스라고 말하고 과소 달성하는 것보다 종종 더 친절합니다. 완료할 수 없는 일을 받아들이면, 요청한 사람은 실현되지 않을 약속 주변으로 계획하며 기다립니다. "15일까지는 이것을 맡을 수 없지만, 더 빨리 도와줄 수 있는 사람이 있습니다"라고 말할 때 — 그것은 그들이 진짜 결정을 내릴 수 있게 해주는 유용한 정보입니다.

글루 작업과 스폰서십에서

가장 친절한 엔지니어링 작업 중 일부는 거의 보이지 않습니다: 다음 신규 입사자가 사흘 동안 혼란스러워하지 않도록 온보딩 문서를 작성하는 사람, 주니어의 아이디어가 묻히지 않도록 계획 회의에서 지지하는 사람, 동료의 매니저에게 인정받을 만한 일에 대해 알리는 사람. 이것이 스폰서십입니다 — 다른 사람의 성장과 가시성에 적극적으로 투자하는 것. 상대적으로 비용이 적고 엄청나게 복리로 쌓입니다.

친절함은 '예스맨'을 의미하지 않습니다

이것은 가장 자주 나오는 반론이며, 직접적인 답이 필요합니다. 친절한 엔지니어링은 높은 기준과 완전히 양립 가능합니다 — 사실, 그것을 요구합니다. 목표는 모든 사람을 편안하게 만드는 것이 아닙니다; 솔직하고 건설적인 참여가 가능하게 만드는 것입니다. 그것들은 다른 것입니다.

높은 기준을 친절하게 유지한다는 것은: 기준이 무엇인지 명확히 하고, 왜 중요한지 설명하며, 사람들이 그것을 충족하도록 돕는 것을 의미합니다 — 단순히 그들이 부족하다는 것을 지적하는 것이 아니라. "테스트 없이는 이것을 머지할 수 없습니다 — 우리의 커버리지가 여섯 달 전 장애와 우리 사이에 있는 것이기 때문입니다"는 높은 기준이면서 친절합니다. "이건 테스트가 없는데, 명백히 용납할 수 없습니다"는 높은 기준이면서 불친절합니다. 원하는 결과는 같습니다; 거기까지 가는 경로는 매우 다릅니다.

잘 반박하는 것도 친절합니다. 결정에 동의하지 않을 때, 이유와 함께 명확히 말하는 것은 선물입니다 — 특히 그 후에 반대편으로 결정이 나면 그 결정에 헌신한다면. 불친절한 것은 수동적 반대입니다: 방에서 동의하고 이후에 결과를 약화시키거나, 말하는 것이 어색했기 때문에 조용히 있으며 나쁜 결정이 진행되도록 하는 것.

친절한 엔지니어는 또한 팀을 보호합니다. 때로는 비현실적인 일정에 대해 이해관계자들과의 어려운 대화를 의미하거나, 그 방에서 스스로를 변호할 수 없는 사람들을 번아웃시킬 요구를 거부하는 것을 의미합니다. 이것은 상냥함이 아닙니다 — 개인적인 비용을 치르면서 행사하는 진짜 배려입니다.

자신에게 친절하기

자신에게 불친절한 엔지니어들은 종종 다른 사람들에게도 불친절합니다. 만성적인 과로, 도움 요청 거부, 항상 유능해 보여야 한다는 필요 — 이것들은 미덕이 아닙니다. 판단력을 침식하고, 분노를 만들며, 진정한 협업을 어렵게 만드는 피로한 패턴입니다.

히어로 문화 — 장애를 밤새워 고친 사람, 혼자서 컴포넌트를 재작성한 사람, 항상 이용 가능하고 항상 달성하는 사람의 찬미 — 는 매혹적이지만 위험합니다. 히어로가 없어서는 안 된다고 느끼게 만들고 모든 다른 사람들에게 같은 방식으로 수행해야 한다는 엄청난 압박을 비밀리에 줍니다. 또한 지식을 위험하게 집중시키고 그 사람이 없을 때 팀을 취약하게 만듭니다.

지속 가능한 속도는 낮은 야망의 신호가 아닙니다. 명확하게 생각하고, 좋은 피드백을 주며, 대화에 진정으로 존재하고, 몇 달이 아닌 몇 년 동안 좋은 일을 계속 할 수 있게 해주는 것입니다. 자신에게 친절한 엔지니어들 — 경계를 설정하고, 도움을 구하고, 불확실성을 인정하는 — 은 동료들이 가장 함께 일하고 싶어 하는 사람들인 경향이 있습니다. 알고 보니, 취약성은 신뢰를 구축합니다. 취약하지 않음을 연기하는 것은 그렇지 않습니다.

이것은 또한 나중이 아닌 일찍 도움을 구하는 것을 의미합니다. 두 시간 동안 막혔을 때 하는 질문은 자신과 물어보는 사람에게 친절합니다 — 유용한 맥락과 해결 가능한 문제를 줍니다. 이틀간의 조용한 고투 후에 하는 같은 질문은 모든 사람에게 더 어렵습니다.

역할과 팀 크기에 따른 친절함의 확장

친절한 엔지니어링은 어디에 앉아 있는지와 조직이 얼마나 큰지에 따라 다소 다르게 보이지만, 핵심은 일정하게 유지됩니다.

개인 기여자로서, 대부분의 친절함은 로컬입니다: 코드 리뷰, 페어 프로그래밍, Slack에서 질문에 어떻게 응답하는지, 다음 사람이 다시 알아내지 않도록 방금 알아낸 것을 문서화하는지 여부. 이 순간들은 개별적으로 작고 집합적으로 엄청납니다. 모든 IC가 위의 것들을 업무의 일부로 취급하는 팀은 그렇지 않은 팀보다 눈에 띄게 더 좋은 일터입니다.

테크 리드로서, 팀의 규범에 불균형적인 영향을 미칩니다. 피드백을 주는 방식이 피드백이 주어지는 방식이 됩니다. 판결을 내리기보다 질문을 한다면, 다른 사람들도 그렇게 합니다. 실수를 비판하기보다 일찍 문제를 드러낸 사람을 축하한다면, 모든 사람이 일찍 문제를 드러내는 것을 더 안전하게 만듭니다. 가장 가치 있는 단 하나의 친절함 투자는 팀 상호작용의 문화를 설정하는 것입니다 — 그리고 그것을 하는 가장 빠른 방법은 모든 코드 리뷰와 모든 회의에서 스스로 그 행동을 모델로 보여 주는 것입니다.

매니저로서, 레버가 바뀝니다. 심리적 안전감에는 이제 포함됩니다: 이것을 말하면 내 직업을 잃을까? 그것은 많은 사람들에게 진짜 우려이며, 적극적으로 해소되어야 합니다 — 말로, 위험 감수에 대한 반응으로, 나쁜 소식을 가져올 때 어떻게 하는지로. 나쁜 소식에 좌절로 반응하는 매니저는 팀이 나쁜 소식을 숨기도록 훈련시킵니다. "일찍 알려줘서 고마워요, 함께 생각해봐요"로 응답하는 매니저는 팀이 일찍 알려주도록 훈련시킵니다. 결과의 차이는 극적입니다.

큰 조직에서, 규모의 친절함은 종종 친절한 행동을 기본값으로 만드는 구조를 만드는 것을 의미합니다: 비난 없는 포스트모템 템플릿, 엔지니어링 핸드북의 명시적 코드 리뷰 규범, 대인 패턴을 드러내는 360도 피드백 프로세스, 개인이 배포한 것뿐만 아니라 팀원들을 어떻게 성장시키고 지원하는지를 포함하는 승진 기준.

친절함은 복리로 쌓입니다. 잘 전달된 모든 솔직한 리뷰, 경멸 없이 답변된 모든 질문, 실제로 공백을 찾는 모든 비난 없는 포스트모템 — 이것들 각각은 팀 전체가 인출하는 신뢰 계정에 작은 예금입니다. 시간이 지나면서, 그 계정이 좋은 일이 일어나는 것처럼 느껴지는 팀과 그렇지 않은 팀을 구분하는 것입니다. 신중하게 구축할 가치가 있습니다.

특정 실천에 대해 더 깊이 알고 싶다면, 이 시리즈의 다음 글은 훌륭한 Pull Request 작성하는 방법의 기술을 살펴봅니다 — 이것 자체가 리뷰어에 대한 친절함의 행위입니다.