[Review] Kind Engineering: 친절하게 일하는 방법

Programming/ETC

[Review] Kind Engineering: 친절하게 일하는 방법

Jonghyuk Baek 2025. 2. 15. 21:45

Introduction

최근 인터넷 뉴스에서 Kind Engineering 이라는 개념을 보게 되었는데, 한번 정리해 두면 좋을 것 같아 글을 작성해 본다.

원문을 바로 보고 싶다면: 링크

친절함 (Kindness) 이란?

“Kind is about being invested in other people, figuring out how to help them, meeting them where they are.”
"친절함은 다른 사람에게 투자하고, 그들을 돕는 방법을 알아내고, 그들이 있는 곳에서 그들을 만나는 것입니다."
— Tanya Reilly

위는 Squarespace의 수석 엔지니어 Tanya Reilly의 친절함 (Kindness) 에 대한 정의다. 상대방을 위해 무언가를 투자하고, 그들의 상황과 입장을 존중하면서 (meeting them where they are) 돕고자 하는 것을 의미한다고 해석할 수 있다.

• 친절함과 나이스함: 나이스해지지 말고 친절해져라

친절함과 (Kind) 나이스함 (Nice) 은 잘 구분해야 한다. 나이스함은 예의 바름에 더 가까우며, 친절하고 상냥한 태도를 주로 의미한다. 반면 친절함은 누군가를 돕는 데에 있어 더 적극적으로 행동하고, 그들의 입장에서 필요한 도움을 주는 것을 의미한다.

• 세상 사람은 세 종류로 나눌 수 있다

친절해져서 어떤 것이 좋아지는가? 원문에서는 Giver가 되어서 얻는 이점을 소개하면서 친절해져서 좋은 점을 설명한다. 세상에는 Taker, Matcher, Giver 세 종류의 사람이 있다. 주는 것보다 많은 것을 받는 사람, 받는 만큼 주는 사람, 받은 것보다 더 주는 사람을 의미한다. Adam Grant의 Give and Take라는 책에서는 Giver가 되는 것의 이점을 아래와 같이 서술한다.

더 생산적이 된다
더욱 의미있는 관계를 구축한다
도움을 받을 가능성이 더 높다
더 성공적이고 행복해진다

정직함 (Honesty)

정직함은 신뢰와 건설적인 비판을 만들며, 팀원들의 성장을 돕고, 협력 관계를 더 깊이 이해하는 기반이 된다. 또한 상대방을 ‘있는 그대로’ 이해하기 위한 필수 요소이다. 상대가 어떤 상황에 있고, 어떤 도움이 필요한지 파악하려면 솔직해야 한다. 거짓 없고 투명한 태도가 있어야, 상대의 입장과 상황을 존중하며 도울 수 있다.

• 일터에서의 모습 (Being At Work)

공과 사를 분리해야 한다는 주장도 있지만, “일”과 “개인”을 엄격히 분리하기보다, ‘온전한 나’를 드러내는게 나을 때가 있다. 동료들에게 내가 어떤 사람인지(취미, 관심사 등)를 공유하면, 서로를 더 깊이 이해할 수 있게 된다. 동료의 배경과 ‘이야기’를 알아야 진짜 상태를 파악하고 적절히 돕기 쉽다고 한다.

표면적인 업무 성과만 보면 도움이 필요한지 알기 어렵다. 따라서 개인적인 경계선을 존중하되, 지나친 분리는 동료와의 관계 형성을 방해할 수 있다. 어느 정도의 취향·개인사 공유가 신뢰 구축과 심리적 안전감 형성에 도움을 준다.

• 도움을 주고 싶다면 정직해져라 (Be Honest… When It Helps)

‘하얀 거짓말’(white lie)은 그 의도가 악의적이지 않다 해도, 듣는 상대방의 성장에는 전혀 도움이 되지 않는다. 진실을 부드럽게 전달하되, 상대가 발전할 수 있는 피드백을 주는 것이 핵심이다. 예를 들어, 누군가 새로운 아키텍처를 도입하려는 회의를 열었는데 설득이 잘 진행되지 않는 경우 “회의 잘했어!” 라고만 칭찬하기보다, “이번 부분을 보완하면 더 잘 설득할 수 있을 것 같아”처럼 구체적을 솔루션을 제공하는 것이 상대방의 발전에는 더욱 도움이 된다. 자신감을 얻고 용기를 얻는 것도 중요하지만, 결국 하고자 했던 것을 진행시키지 못 하게 된다면 어떻게 되겠는가? 결국 의도가 어떻게 되었던 해당 칭찬이 거짓말이라는 것을 깨닫게 되고, 장기적으로는 나나 상대방 모두에게 좋은 결과는 아니다.

어떤 점은 잘 진행했고, 어떤 점은 향후 다르게 시도해 봐야 할지 정직함을 바탕으로 전달하자.

비동기적 커뮤니케이션 (Async Communication)

기술 업계에서는 모든 것이 변화한다는 것이 유일하게 불변하는 요소라 할 수 있다. 따라서 이런 혼란스러운 환경에서, 이를 둘러싼 소통 방법을 숙달하는 것이 중요하다 할 수 있다. 이러한 소통 중 가장 많이 접하게 될 것이 코드 리뷰 및 Pull Request 일 것이다 (참고). 단순히 기계적으로 approve를 누르는 것이 아니라, 변경된 사항을 이해하고 그것의 배경을 충분히 이해하는 것이 이들의 핵심이다.

• "어떻게"가 아닌 "왜"에 집중해라 (Understanding The Why, Not Just The How)

이를 위해서는 우선 취조나 거만함이 아닌, 호기심이 담긴 어조로 시작하는 것이 중요하다. 부정적 어조는 듣는 상대방을 방어적이게 만들며, 이런 상태에서는 피드백을 수용하기가 어려워지기 때문에 결과적으로는 무엇을 배우거나 성장하기가 어렵다.

무엇이 어떻게 변경되었는지를 보는 것이 아니라, 변경의 이유에 대해 먼저 이해해보고자 하자. 왜 이게 삭제되었고, 왜 이게 재사용되며 이 작은 도우미 함수는 왜 추가되고 있는지 그 배경을 생각해 보자. 여기서 중요한 것은, 악의나 무능을 가정하지 않는 것이다. 내가 무언가를 놓치고 있다고 항상 가정하고, "정정 (correction)"이 아닌 "설명 (clarification)" 을 요청하자. 무작정 머리끄댕이를 잡고 "이건 이렇게 하는겁니다", 또는 "이건 틀린 것 같은데요" 를 던지지 말자. 대신 "이 부분을 이렇게 하신 이유가 뭔가요?" 처럼 이해가 필요한 부분을 존중하는 태도로 묻자.

• Nitpicks

“Nitpicks are unimportant comments, where the code could be merged without even addressing them. These could be things like variable declarations being in alphabetical order, unit tests following a certain structure, or brackets being on the same line.”
"Nitpick은 중요하지 않은 코멘트로, 반영하지 않아도 병합할 수 있는 변경을 담고 있습니다. 예를 들어 변수 선언이 알파벳순으로 되어야 한다던가, 단위 테스트가 특정 구조를 따라야 한다던가, 괄호가 같은 줄에 있어야 한다는 것일 수 있습니다."
— Gergely Orosz, How to Make Good Code Reviews Better

Nitpick (꼭 고치지는 않아도 되는 중요하지 않은 코멘트) 은 ‘필수 수정 사항’이 아님을 명확히 밝혀 상대의 부담을 덜어주자. 코멘트에 "Nitpick: ~" 과 같이 프리픽스를 붙이는 방법도 있다. 이를 통해 너무 바쁘거나 아직 피드백을 받아들일 준비가 되지 않은 경우 스킵할 수 있다. 이미 충분히 작업으로 인해 바쁘고 스트레스 받는 사람에게 알아서 중요한 코멘트와 중요하지 않은 코멘트를 구분하게 하는 것은 너무 큰 부담일 수 있다. 나중에 다시 찾을 수 있도록 해 두기만 하자.

또한, 너무 잦은 Nitpick이 발생한다면 직접 하기보다는 린터 또는 포매터를 사용해 자동화를 하자. 사람과 사람이 매번 씨름하기보다는 자동화된 도구를 사용해 팀 표준에 코드를 맞추는 것이 더욱 효과적이다.

• 동기 vs 비동기 (Sync vs Async)

만약 코멘트가 너무 많아지면, 실시간(동기적) 대화로 전환하는게 나을 때가 있다. 댓글만 주고받다 보면 시간이 오래 걸리고 맥락이 분산되므로, 직접 소통이 더 효율적일 수 있다. 또한, 공개된 장소에서의 대규모 피드백은 심리적 압박을 줄 수 있다. 필요하다면 1:1 대화나 소규모 미팅 등 안전한 환경에서 솔직한 의견을 교환하는 것이 좋다.

심리적 안전감 (Psychological Safety)

심리적 안전감이란, “얼마나 안전하게 개인이 문제를 제기하고 이를 해결해낼 수 있는가?” 로 요약될 수 있다. 만약 문제를 발견해 내어서 이를 보고했는데, 발견자에 대한 불이익으로 돌아간다면 (예: "문제 제기한 사람이 개인 업무 시간을 쪼개서 해결해 오시죠") 심리적 안전감이 충분하지 않은 상태이며 팀은 잦은 문제 은폐로 인해 조기에 해결할 수 있던 작은 문제를 이후에 거대하게 불어난 상태로 마주할 수 있다.

기술적 문제뿐 아니라 다양한 문제를 자유롭게 논의할 수 있는 분위기가 중요하다. 안전감을 느끼지 못하면, 개개인의 발언이나 참여가 크게 위축되고 모두의 성장 기회가 줄어들게 된다. 물론 현재는 많은 조직문화가 바뀌며 직원 개개인의 주도성과 문제 해결 능력을 신뢰하는 방향으로 진화 중이긴 하다.

• 피드백을 독려하라(Encourage Feedback)

심리적 안전감을 구축하기 위해 첫 번째로 해야 할 것은 스스로 먼저 피드백을 요청하는 것이다. “내가 무엇을 더 잘할 수 있을까?”라는 태도로 발전을 위해 상대방의 조언을 구하는 자세를 취함으로써, 상대방도 안전하게 피드백할 수 있는 상황을 만들 수 있다. 자신이 좀더 열린, 비판에 수용적인 자세를 취하면, 상대방도 조직 내에서 이러한 자세를 취해도 괜찮다는 것을 깨닫고 이에 동참할 수 있다.

다른 실천 방안으로는 ‘Start/Stop/Keep’ 구조를 사용해 피드백을 나누는 것이다.

새로 시작해야 할 것 (Start)
이제는 멈춰야 할 것 (Stop)
앞으로 계속해야 할 것 (Keep)

회의나 프로젝트 뒤에 이 구조로 피드백을 나누면 구체적 개선 방향을 도출하기 쉽다.

• 포용하라 (Be Inclusive)

배경 및 선호가 다른 사람들을 이해하고, 그들이 편한 방식으로 의견을 낼 기회를 제공해라. 예를 들어 많은 사람들이 회의에서 주요한 의견을 내지 못 하는 경우, 미리 문서를 공유한다던지, 익명 설문 폼을 뿌린다던지, 회의 중 직접 호명 등 다양한 방법을 적용할 수 있다. 이는 ‘그들이 있는 자리에서 만나는 것’(meeting them where they are)의 연장선이다. 사람들이 목소리를 낼 수 있도록, 각자의 상황과 성향에 맞는 채널을 열어두자.

• 비난하지 않기 (No Blame)

문제가 발생했을 시에는 이것을 개인의 실패로 몰아가지 말고, 이를 방지하기 위해 프로세스·환경·워크플로우를 함께 점검하자. “팀 전체가 함께 성공하고, 함께 실패한다”는 마인드를 가지자. 책임을 묻지 말라는 것은 아니다. 다만 문제가 발생했을 때 쉽게 누군가를 희생양 만들지는 말라는 의미이다. 무언가 팀 내에서 오류가 발생하면 전체적 맥락(결정 과정, 가정, 경험 등)을 돌아보고 개선점을 찾자. 앞으로의 결과물이 중요하지, 누군가를 배제시키는 것이 중요한 게 아니다.

• 실패를 학습 기회로 돌려라 (Turn Failure Into Learning)

실패는 절대적이지 않으며, 새로운 아이디어와 혁신을 가져오는 계기가 된다. 안전한 환경에서는 도전적인 시도와 실험이 가능해지며, 더 과감한 발전이 가능하다. 다만 무작정 도전하고 실패를 반복하는 것이 아니라, 실패 시에는 체계적인 사후 분석(Postmortem) 등의 방식을 통해 구조적으로 실패 사례를 학습하자. 세부적인 회고 프로세스를 통해 다음 번엔 더 나은 결과로 이어질 수 있다.

피드백 / 비판 (Feedback / Criticism)

• 피드백과 비판에 대한 공통 원칙

비판을 요청하는 첫 번째 사람이 되면서, 일방적으로 비판을 퍼붓지 말자. 피드백은 받을 수도 있고 줄 수도 있는 것이다. 지나치게 비판적인 이미지로 인해 신뢰를 잃고 좋은 피드백을 전달할 기회를 놓칠 수 있다. 또한 피드백 대상 문제를 ‘행동’에 한정하고, ‘개인’을 공격하지 않는 것도 중요하다.

또한 구체적이고 세부적인 예시를 들어야 진정성 있고 효과적인 피드백이 된다. 칭찬에도 구체성이 있으면 훨씬 진정성 있게 느껴진다. 항상 가능한 것은 아니지만, 비판적인 피드백을 주어야 할 때에는 해결책을 함께 제시할 수 있도록 해 보자. 당장 시도해 볼 만한 것이 있다면 개선을 시도해 보기가 훨씬 쉬워진다. 항상 답이 있는 것은 아니겠지만, 최소한 가능한 해결책이 있을 지 한번씩 고민해 보자.

• 피드백 받기 (Receiving)

하지만 피드백이란건 듣기 힘들 수 있고, 이건 본인에게도 마찬가지이다. 본인의 피드백 방식 선호 (대면 / 문서 / 비공개 등)를 주변에 알리고, 본인이 편한 방식으로 피드백을 듣자. 자신이 받아들이기 쉬운 경로를 만들어 두면 나도 모르게 나올 수 있는 방어적인 태도가 줄어들 수 있다. 또한, 피드백에 즉각 반응하기보다 잠시 시간을 두고(감정 정리 후) 수용해 보자. 피드백을 들었을 시 어느정도 방어적이 되는 것은 자연스러운 현상이다. 15분 정도 휴식 후 다시 생각해보면 훨씬 합리적으로 받아들이게 된다.

만약 정보가 더 필요하다면 구체적인 예시나 상황 설명을 추가로 요청하자. 본인이 처한 문제를 더욱 명확히 알아야 비로소 발전할 수 있다.

• 피드백 주기 (Giving)

피드백을 줄 때에는, 3가지 요소를 고려하면 좋다. 감정 (Emotion), 신뢰도/전문성 (Credibility), 논리 (Logic).

1. 감정: 듣는 이의 감정 상태를 고려하자 (본인의 개인적인 감정에 휩쓸리지 말자).

2. 신뢰도 / 전문성: 내가 충분히 해당 문제에 대해 전문성 및 신뢰도를 갖추고 있다면 피드백의 효과가 훨씬 높아질 수 있다.

3. 논리: 왜 이런 결론에 이르렀는지에 대해 최대한 구체적으로 제시하자.

결론

원문에서는 친절함을 크게 3가지 관점 — 1. 커뮤니케이션, 2. 정직함(솔직함), 그리고 3. 심리적 안전감 — 의 관점에서 설명하며, 최종적으로 다음 질문을 던진다.

“당신이 속한 팀과 회사에서, 어떻게 하면 더 ‘친절’할 수 있을까?”

결국엔 이 글에선 상대방을 진심으로 이해하고 (Safety), 솔직하게 소통하며 (Honesty), 협업 과정에서 적극적인 도움 (Kindness)을 주고받는 것이 핵심이라는 점을 강조한다.

사실 여기서 언급된 내용들은 다양한 엔지니어 도서 및 조직문화 도서에서 공통적으로 언급되는 내용들이기도 하다 (구글 엔지니어는 이렇게 일한다, 두려움 없는 조직 등). 이러한 내용이 당연해 보일 수도 있지만, 여기서 언급되는 내용들을 항상 실천하기는 어려울 것이다. 가끔씩 이 내용들을 떠올리면서 일하는데 참고해 봤으면 좋겠다.

아래는 참고할 만한 페이지들이다.