# 친절한 엔지니어링

> Clean Markdown view of GeekNews topic #19212. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=19212](https://news.hada.io/topic?id=19212)
- GeekNews Markdown: [https://news.hada.io/topic/19212.md](https://news.hada.io/topic/19212.md)
- Type: news
- Author: [carnoxen](https://news.hada.io/@carnoxen)
- Published: 2025-02-13T17:47:16+09:00
- Updated: 2025-02-13T17:47:16+09:00
- Original source: [kind.engineering](https://kind.engineering/)
- Points: 35
- Comments: 5

## Summary

친절함은 사람에 투자하는 것을 말하며, 그저 상냥함이 아니라 상대의 입장이 되어 그 감정과 배경을 이해하는 것을 뜻합니다. 모든 상황에서 만능은 아니지만, 여러 문제를 해결하는 데 도움을 줄 수 있습니다.   
- **자상함** : 자상함을 잃지 마시고, 좋은 행동을 칭찬하시고 개선할 점을 주세요.  
- **비동기적인(async) 소통** : 변화에 있어 "무엇을?"과 "어떻게?"뿐 아니라 "왜?"에 대해서도 더 많이 이해하려고 노력하세요.  
- **심리적 안정** : 혁신을 촉진하기 위해서, 사람들이 위험을 감수하고, 도전하며, 이런 행동이 안전하다고 느끼도록 장려해야 합니다.  
- **피드백/비판** : 처음부터 평가하는 사람이 아닌, 평가를 가장 먼저 받는 사람이 되세요. 누군가에게 비판적인 피드백을 준다면, 해결책도 제시해 보세요.

## Topic Body

#### 친절함이란?  
  
> 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) 소통  
  
* 변화에 있어 "무엇을?"과 "어떻게?"뿐 아니라 "왜?"에 대해서도 더 많이 이해하려고 노력하세요.  
* 악의나 무능함을 가정하지 마세요.  
* 강하거나 논란이 다분한 발언 대신 마음이 열려 있는 질문을 하세요.  
* 지적에 앞서 꼬리표가 명확하게 붙어 있는 것이 중요합니다.  
* 많이 지적하면 업무에 더 큰 지장을 될 수 있습니다.  
* 의견이 많으면 소통을 순차적인 방식으로 바꾸세요.  
  
##### 심리적 안정  
  
* 팀이나 동료에게 가장 먼저 피드백을 요청하세요.  
* 피드백의 구조는 다음과 같이 간단합니다:  
    * 잘된 점  
    * 잘못된 점  
    * 나중에 할 일  
* 사람들의 배경, 역사, 그리고 개인적인 선호를 개방적으로 받아들이세요.  
* 회의나 문서에 크게 기여하지 못 하는 사람들을 주시하고, 그들이 목소리를 낼 방법을 찾아보세요.  
* 사람들이 옳다고 느끼는 어떤 방식으로든 자신을 표현할 수 있도록 목소리를 내세요.  
* 종종 개별적인 실패는 실제로 프로세스, 환경 또는 워크플로우의 실패를 불러올 수 있습니다.  
* 우리는 함께 성공하고, 실패합니다.  
* 모든 "실패"나 사건은 성장하고 배울 수 있는 기회로 기념되어야 합니다.  
* 혁신을 촉진하기 위해서, 사람들이 위험을 감수하고, 도전하며, 이런 행동이 안전하다고 느끼도록 장려해야 합니다.  
  
##### 피드백/비판  
  
* 처음부터 평가하는 사람이 아닌, 평가를 가장 먼저 받는 사람이 되세요.  
* 개인적인 사항으로 만들지 마세요.  
* 피드백이나 칭찬을 할 때는 가능한 한 구체적이고 철저하게 하려고 노력하세요.  
* 누군가에게 비판적인 피드백을 준다면, 해결책도 제시해 보세요.  
* 자신의 피드백 선호도를 이해하세요.  
* 듣고 이해한 다음 피드백을 주신 분께 감사를 드리세요.  
* 지금 당장 반응하지 말고, 시간을 내어 생각을 정리하고 피드백을 처리하세요.  
* 설명이나 예시를 요청하세요.  
* 피드백을 주는 세 가지 요소를 기억하세요:   
    * 감정  
    * 신뢰성  
    * 논리  
* 자신이 아닌 청취자의 감정을 고려하세요.  
* 전문성과 겸손함을 보여주세요.  
* 당신의 업무 방식과 결론에 도달하는 방법을 보여주세요.  
  
---  
  
* [기술 업계의 독성 말투 문제, 고칩시다!](https://edykim.com/ko/post/tech-has-a-toxic-tone-problem-lets-fix-it/)

## Comments



### Comment 34536

- Author: arfwene
- Created: 2025-02-14T09:32:53+09:00
- Points: 2

당연한 일이지만 실천하기 어렵네요..

### Comment 34522

- Author: aster
- Created: 2025-02-13T19:36:05+09:00
- Points: 7

위 자료를 바탕으로 개발에서는 어떻게 친절한 엔지니어링을 적용할 수 있는가  
일명 KDD(Kindness Driven Development)를 AI 도움으로 만들어 보았습니다.  
  
  
코드 작성  
- 주석과 문서화를 "왜?"에 중점을 두어 작성하세요. 코드가 존재하는 이유와 배경을 설명하는 것이 중요합니다.  
- 복잡한 로직에는 도메인 용어를 활용한 변수명과 함수명을 사용해 다른 개발자가 이해하기 쉽게 만드세요.  
- 새로운 기술이나 패턴을 도입할 때는 팀원들의 학습 곡선을 고려하세요.  
- 레거시 코드를 비난하지 마세요. 당시의 제약사항과 맥락이 있었을 것입니다.  
- 미래의 유지보수 담당자를 위해 엣지 케이스와 실패 케이스에 대한 처리를 문서화하세요.  
아키텍처 설계  
- 시스템 설계 시 운영팀과 QA팀의 관점도 고려하세요.  
- 모니터링과 디버깅을 쉽게 만드는 것도 친절한 설계의 일부입니다.  
- 확장성있는 설계는 미래의 팀원들을 위한 배려입니다.  
- 기술 부채를 관리할 때는 완벽한 제거가 아닌 "관리 가능한 수준"을 목표로 하세요.  
- 새로운 기능 추가가 쉬운 구조를 만드는 것이 중요합니다.  
코드 리뷰  
- 리뷰 요청 시 변경사항의 컨텍스트를 충분히 설명하세요.  
- "이렇게 하면 어떨까요?"와 같은 제안형 피드백을 사용하세요.  
- 긍정적인 부분도 반드시 언급하세요. "이 부분 정말 깔끔하네요"  
- 대안을 제시할 때는 그 이유도 함께 설명하세요.  
- 시급하지 않은 개선사항은 따로 이슈로 등록하여 현재 PR의 범위를 존중하세요.  
테스트 코드  
- 테스트 실패 시 명확한 에러 메시지를 제공하세요.  
- 테스트 케이스는 문서화의 역할도 합니다. 비즈니스 규칙을 잘 설명하는 테스트를 작성하세요.  
- 다른 개발자가 테스트를 쉽게 추가할 수 있는 구조를 만드세요.  
- 테스트 데이터는 이해하기 쉬운 실제 사례를 사용하세요.  
- 테스트 환경 설정을 자동화하여 진입 장벽을 낮추세요.  
배포와 운영  
- 배포 스크립트에 충분한 설명과 가이드를 포함하세요.  
- 장애 발생 시 디버깅에 도움되는 로그를 미리 준비하세요.  
- 설정 변경이 필요한 경우, 영향도를 문서화하세요.  
- 새로운 기능 출시 시 롤백 계획도 함께 준비하세요.  
- 운영 가이드는 신입 개발자의 관점에서 작성하세요.  
지식 공유  
- 트러블슈팅 경험을 문서화하여 공유하세요.  
- 새로운 기술 도입 시 학습 자료를 만들어 공유하세요.  
- 코드 작성 가이드는 "왜 이렇게 하기로 했는지"를 포함하세요.  
- 정기적인 기술 공유 시간을 통해 팀의 성장을 도모하세요.  
- 질문하기 좋은 환경을 만들어 주니어 개발자의 성장을 돕습니다.

### Comment 34657

- Author: bbulbum
- Created: 2025-02-17T01:11:32+09:00
- Points: 2
- Parent comment: 34522
- Depth: 1

따로 글로 써도 좋을 정도의 내용인데요 ㅎㅎ

### Comment 34643

- Author: laeyoung
- Created: 2025-02-16T13:35:48+09:00
- Points: 2
- Parent comment: 34522
- Depth: 1

굉장히 좋네요!

### Comment 34576

- Author: aer0700
- Created: 2025-02-14T16:26:17+09:00
- Points: 2
- Parent comment: 34522
- Depth: 1

굉장히 좋은 댓글이네요