테크에서 친절함의 예시: “shitty code” 사례
Source: Dev.to
Introduction
Disclaimer: this article reflects my personal opinion and is not intended as an absolute truth.
짧은 경력 동안 나는 개발자들이 누군가의 작업을 리뷰하면서 “정말 shitty code다”라고 중얼거리는 모습을 여러 번 들었다. 로버트 C. 마틴도 Clean Code에서 “bad code”를 하나의 지표로 언급한다. 불만은 이해할 수 있지만, 그 표현은 건설적인 가치를 전혀 제공하지 않는다: 설명도 없고, 동료가 개선하도록 돕겠다는 의지도 없으며, 순전히 판단적인 말이다. 게다가 팀 내 긴장을 초래할 수 있다. 당신이 방금 작성한 코드를 “shitty”라고 라벨링한다면 동료는 어떻게 반응할까?
Why the Term Is Problematic
- 건설적인 피드백 부족 – 이 문구는 코드를 어떻게 개선할지에 대한 안내를 제공하지 않는다.
- 갈등 가능성 – 자아를 배제하려는 팀이라 할지라도, 이러한 언어는 공격으로 받아들여질 수 있다.
- 자아와 심리적 안전 – 관리자의 관점에서 보면, 이 용어는 독이 될 수 있다. 완전히 자아에서 벗어나 있지 않다면, 이 발언은 인간관계를 해치고 신뢰를 약화시킨다.
Context Matters
“좋은” 혹은 “나쁜” 코드에 대한 인식은 시간이 지나면서 변한다. 2000년대에 견고하다고 여겨졌던 코드베이스도 20년 후면 구식으로 보일 수 있다. 스타트업처럼 비즈니스 모델 검증에 집중하는 빠르게 움직이는 환경에서는 속도가 우아함보다 우선시된다. 팀은 MVP를 빠르게 제공하기 위해 의도적으로 기술 부채를 감수하기도 한다. 이런 상황에서 “quick and dirty” 솔루션은 무능함의 표시라기보다 실용적인 선택이다.
Impact on Psychological Safety
연구에 따르면 psychological safety가 고성능 팀의 가장 큰 예측 변수임이 일관되게 나타난다. 거친 라벨을 사용하면 다음과 같은 문제가 발생한다:
- 심리적으로 안전한 환경 조성을 방해한다.
- 솔직한 피드백을 받을 가능성이 줄어든다.
두 효과 모두 팀이 잠재력을 최대한 발휘하고 생산성을 높이는 데 장애가 된다.
Recommendations
1. Replace the phrase
- “suboptimal code” 혹은 **“code that could be improved”**와 같은 중립적인 용어를 사용한다.
- 코드가 왜 개선이 필요한지 설명하고 구체적인 개선 방안을 제시한다.
2. Address the issue directly
- 해당 용어가 팀에 불편함을 주고 있다면, 1:1 대화를 통해 그 영향을 논의한다.
- 피드백은 사람보다는 코드에 초점을 맞추는 문화를 장려한다.
3. Foster constructive dialogue
- 비판은 구체적이고 실행 가능하며 존중하는 방식이어야 함을 강조한다.
- 복잡한 해결책을 찾기보다 간단하고 중립적인 언어 전환만으로도 충분히 효과적이다.
Conclusion
“shitty code”라는 표현은 건설적인 가이드를 제공하지 못하고 심리적 안전을 해칠 수 있기 때문에 해롭다. “suboptimal code”와 같은 중립적인 용어를 채택하고 명확하고 실행 가능한 피드백에 집중함으로써, 팀은 존중하는 분위기를 유지하면서도 코드 품질을 향상시킬 수 있다. 중립적이고 건설적인 자세를 유지하며, 열린 토론을 위한 안전한 환경을 최우선으로 하자.