친절한 엔지니어링
(kind.engineering)친절함이란?
Kind is about being invested in other people, figuring out how to help them, meeting them where they are.
친절함은 다른 사람에 투자하고, 돕는 방법을 찾으며, 원하는 바를 충족시킵니다.
— Tanya Reilly, Continuous
친절함은 위에 Tanya Reilly가 말한 대로, 사람에 투자하는 것을 말합니다. 그저 상냥함이 아니라 상대의 입장이 되어 그 감정과 배경을 이해하는 것을 뜻합니다. 모든 상황에서 만능은 아니지만, 여러 문제를 해결하는 데 도움을 줄 수 있습니다.
자상함
- "전문적임"을 넘어 자신의 일에 집중하세요.
- 개방적이고 인간답게 행동해 신뢰를 쌓으세요.
- 사람들을 직접 대하되 사려깊게 보살펴주세요.
- 하얀 거짓말은 나쁘지 않지만 사람을 성장시킬 수 없습니다.
- 자상함을 잃지 마시고, 좋은 행동을 칭찬하시고 개선할 점을 주세요.
비동기적인(async) 소통
- 변화에 있어 "무엇을?"과 "어떻게?"뿐 아니라 "왜?"에 대해서도 더 많이 이해하려고 노력하세요.
- 악의나 무능함을 가정하지 마세요.
- 강하거나 논란이 다분한 발언 대신 마음이 열려 있는 질문을 하세요.
- 지적에 앞서 꼬리표가 명확하게 붙어 있는 것이 중요합니다.
- 많이 지적하면 업무에 더 큰 지장을 될 수 있습니다.
- 의견이 많으면 소통을 순차적인 방식으로 바꾸세요.
심리적 안정
- 팀이나 동료에게 가장 먼저 피드백을 요청하세요.
- 피드백의 구조는 다음과 같이 간단합니다:
- 잘된 점
- 잘못된 점
- 나중에 할 일
- 사람들의 배경, 역사, 그리고 개인적인 선호를 개방적으로 받아들이세요.
- 회의나 문서에 크게 기여하지 못 하는 사람들을 주시하고, 그들이 목소리를 낼 방법을 찾아보세요.
- 사람들이 옳다고 느끼는 어떤 방식으로든 자신을 표현할 수 있도록 목소리를 내세요.
- 종종 개별적인 실패는 실제로 프로세스, 환경 또는 워크플로우의 실패를 불러올 수 있습니다.
- 우리는 함께 성공하고, 실패합니다.
- 모든 "실패"나 사건은 성장하고 배울 수 있는 기회로 기념되어야 합니다.
- 혁신을 촉진하기 위해서, 사람들이 위험을 감수하고, 도전하며, 이런 행동이 안전하다고 느끼도록 장려해야 합니다.
피드백/비판
- 처음부터 평가하는 사람이 아닌, 평가를 가장 먼저 받는 사람이 되세요.
- 개인적인 사항으로 만들지 마세요.
- 피드백이나 칭찬을 할 때는 가능한 한 구체적이고 철저하게 하려고 노력하세요.
- 누군가에게 비판적인 피드백을 준다면, 해결책도 제시해 보세요.
- 자신의 피드백 선호도를 이해하세요.
- 듣고 이해한 다음 피드백을 주신 분께 감사를 드리세요.
- 지금 당장 반응하지 말고, 시간을 내어 생각을 정리하고 피드백을 처리하세요.
- 설명이나 예시를 요청하세요.
- 피드백을 주는 세 가지 요소를 기억하세요:
- 감정
- 신뢰성
- 논리
- 자신이 아닌 청취자의 감정을 고려하세요.
- 전문성과 겸손함을 보여주세요.
- 당신의 업무 방식과 결론에 도달하는 방법을 보여주세요.
위 자료를 바탕으로 개발에서는 어떻게 친절한 엔지니어링을 적용할 수 있는가
일명 KDD(Kindness Driven Development)를 AI 도움으로 만들어 보았습니다.
코드 작성
- 주석과 문서화를 "왜?"에 중점을 두어 작성하세요. 코드가 존재하는 이유와 배경을 설명하는 것이 중요합니다.
- 복잡한 로직에는 도메인 용어를 활용한 변수명과 함수명을 사용해 다른 개발자가 이해하기 쉽게 만드세요.
- 새로운 기술이나 패턴을 도입할 때는 팀원들의 학습 곡선을 고려하세요.
- 레거시 코드를 비난하지 마세요. 당시의 제약사항과 맥락이 있었을 것입니다.
- 미래의 유지보수 담당자를 위해 엣지 케이스와 실패 케이스에 대한 처리를 문서화하세요.
아키텍처 설계 - 시스템 설계 시 운영팀과 QA팀의 관점도 고려하세요.
- 모니터링과 디버깅을 쉽게 만드는 것도 친절한 설계의 일부입니다.
- 확장성있는 설계는 미래의 팀원들을 위한 배려입니다.
- 기술 부채를 관리할 때는 완벽한 제거가 아닌 "관리 가능한 수준"을 목표로 하세요.
- 새로운 기능 추가가 쉬운 구조를 만드는 것이 중요합니다.
코드 리뷰 - 리뷰 요청 시 변경사항의 컨텍스트를 충분히 설명하세요.
- "이렇게 하면 어떨까요?"와 같은 제안형 피드백을 사용하세요.
- 긍정적인 부분도 반드시 언급하세요. "이 부분 정말 깔끔하네요"
- 대안을 제시할 때는 그 이유도 함께 설명하세요.
- 시급하지 않은 개선사항은 따로 이슈로 등록하여 현재 PR의 범위를 존중하세요.
테스트 코드 - 테스트 실패 시 명확한 에러 메시지를 제공하세요.
- 테스트 케이스는 문서화의 역할도 합니다. 비즈니스 규칙을 잘 설명하는 테스트를 작성하세요.
- 다른 개발자가 테스트를 쉽게 추가할 수 있는 구조를 만드세요.
- 테스트 데이터는 이해하기 쉬운 실제 사례를 사용하세요.
- 테스트 환경 설정을 자동화하여 진입 장벽을 낮추세요.
배포와 운영 - 배포 스크립트에 충분한 설명과 가이드를 포함하세요.
- 장애 발생 시 디버깅에 도움되는 로그를 미리 준비하세요.
- 설정 변경이 필요한 경우, 영향도를 문서화하세요.
- 새로운 기능 출시 시 롤백 계획도 함께 준비하세요.
- 운영 가이드는 신입 개발자의 관점에서 작성하세요.
지식 공유 - 트러블슈팅 경험을 문서화하여 공유하세요.
- 새로운 기술 도입 시 학습 자료를 만들어 공유하세요.
- 코드 작성 가이드는 "왜 이렇게 하기로 했는지"를 포함하세요.
- 정기적인 기술 공유 시간을 통해 팀의 성장을 도모하세요.
- 질문하기 좋은 환경을 만들어 주니어 개발자의 성장을 돕습니다.