피드백
우리는 협업을 하면서 서로 많은 피드백을 주고 받습니다.
개발자라면 많은 경우 코드리뷰를 주고 받기도 하고 기획 단계에서 디자이너, 매니저 등 다양한 직군들과의 커뮤니케이션을 통해 제안을 하거나 의견을 교환하기도 하죠.
이 과정에서 “너무 좋은 것 같아요!”, “고생하셨어요!” 와 같이 기분이 좋으면서 달콤한 피드백이 있고 “이 코드는 왜 이렇게 짜셨나요?”, “공식 문서를 한번 읽어보면 바로 알 수 있는건데” 와 같이 날카롭고 상처를 입힐 수 있는 피드백이 있습니다.
이 두 종류의 피드백들은 상황마다 필요한 순간이 있다고 생각할 수 있지만 대부분 도움이 되지 않습니다.
설탕 피드백
“너무 좋은 것 같아요!”
“고생하셨어요.”
“LGTM”
이러한 피드백들은 듣기는 좋지만 돌아서면 아무런 가치가 남지 않습니다.
정확히 어느 부분이 납득이 가거나 놀라웠는지, 개선할 부분은 없었는지를 남기지 않습니다.
구체적으로 무엇을 잘했는지 못했는지 모르기 때문에 다음 작업에 적용할 수 없거나 잘못된 방식을 정답이라고 생각합니다.
그들에게 나쁜 의도는 없습니다. 다만 갈등을 피하고 싶거나 당신의 코드에 깊이 신경 쓸 에너지가 없을 뿐입니다.
좋은 말만 하고 예의를 너무 갖추어 주는 경향이 있는데, 본인들도 좋은 말만 해주는게 마음이 편하기 때문입니다.
이들의 칭찬은 성장을 위한 양분이 아니라 현상 유지를 위한 무의미한 설탕일 뿐입니다.
유리조각 피드백
이 코드는 왜 이렇게 짜셨나요?
어떤 의도로 이렇게 작성하셨나요?
공식 문서를 한번 읽어보면 바로 알 수 있는 건데..
겉으로 보기에는 솔직하고 직설적인 피드백처럼 보일 수 있습니다.
하지만 솔직함과 무례함은 한 끗 차이입니다.
이런 말투는 상대의 감정을 고려하지 않기 때문에 듣는 사람에게는 날카로운 유리조각처럼 깊은 상처만 남기기도 합니다.
이들은 도움을 주려는 마음보다는 자신의 지식을 과시하려는 욕구가 크거나 본인의 화를 억누르지 못하는 경우가 더 많습니다.
즉시 떠오르는 말을 거침없이 내뱉으며 본인의 감정을 정당한 피드백으로 포장하기도 합니다.
결과적으로 이런 방식은 성장과 협업에 아무런 기여도 하지 못하고, 팀 문화를 해치는 독이 됩니다.
이러한 피드백은 투명하게 널브러져 있지만 밟는 순간 다치게 하는 유리조각일 뿐입니다.
좋은 피드백
좋은 피드백은 누군가에게 입 냄새가 난다는 사실을 상처 없이 전달하는 것만큼이나 어렵습니다.
사실을 말하지 않으면 그 사람은 창피를 당할 수도 있고,
그렇다고 직설적으로 이야기하면 기분 나빠할 수도 있습니다.
문제가 있는 코드를 보고도 조용히 넘어가거나 듣기 좋은 말만 해준다면 기술 부채는 계속 쌓여가며 언젠가부터 유지보수가 불가능에 가까워지기 시작하게 되고,
솔직함을 가장하여 무례하고 감정적인 피드백을 준다면 상처를 남기며 팀원들의 관계를 무너뜨리고 극단적으로 퇴사자가 많아지기 시작합니다.
그럼 어떻게 해야 좋은 피드백을 남길 수 있을까요?
객관적이어야 한다
Bad:
저는 이 방식을 별로 선호하지 않는데..
Better:
이 구현 방식은 우리 팀의 컨벤션 기준에서 어긋나는 부분이 있어요.
예를 들어 A 규칙에서는 B를 권장하고 있습니다. 이 기준에 맞춰 수정하면 유지보수에 더 도움이 될 것 같아요. (링크)
개인의 주관적인 선호도는 중요하지 않습니다.
구현 방식이 문제가 된다면 팀에서 합의한 컨벤션에 어긋나는지, 단점이 드러나는 구현 방식이기 때문에 새로운 룰을 추가해야 할지를 먼저 검토해야 합니다.
가능하다면 근거 자료, 공식 문서, 레퍼런스 예시 등을 함께 제시해 검증 가능한 논리로 이야기해야 합니다.
구체적이여야 한다
Bad:
너무 좋아요! LGTM!
Better:
이 부분에서 응집도가 높아지면서 가독성이 좋아졌어요. 흩어져 있던 서비스 로직들이 한 곳에 모아지면서 흐름을 이해하기 더 쉬워졌습니다.
이런 방식은 향후 기능 확장에도 유리할 것 같아요. 좋은 구현 방식이라고 생각합니다.
코드 리뷰는 단순히 “좋아요”라고 말하는 것이 아니라, 무엇이 왜 좋은지 구체적으로 설명해야 합니다.
예를 들어 가독성, 구조적 장점, 성능 개선 포인트 등을 명확히 짚어주면 작성자가 어떤 방향이 강점을 갖고 있는지 더 잘 이해할 수 있습니다.
구체적인 피드백은 좋은 코드 습관을 강화하는 데 도움이 되고, 팀의 코드 스타일 기준을 정립하는 데도 도움이 됩니다.
개선 방향을 함께 제안한다
Bad:
이렇게 구현하시면 안돼요.
Better:
이 로직은 현재 중복된 계산이 여러 번 발생해서 성능 비용이 조금 클 수 있어요.
useEffect를 없애고 state를 정리하면 불필요한 연산을 줄일 수 있을 것 같습니다.
아래처럼 수정해볼 수 있을 것 같아요. (예시 코드)
요구사항 분석 자체가 잘못 되었는지, 어느 코드 라인이 잘못 되었는지, 구현하는 방향이 잘못 되었는지, 구현 방식이 잘못 되었는지를 명확하게 해야 합니다.
모호한 표현은 상대방이 개선 방향을 스스로 추측하게 만들어 불필요한 시간 소모를 발생시킵니다.
문제를 지적하는 것만이 아니라 구체적인 근거와 예시코드, 참고 문서 등을 함께 제공하면, 상대방은 문제를 빠르게 이해하고 효과적으로 수정할 수 있습니다.
상대를 존중한다
Bad:
이건 좀 너무 기본적인 거 아닌가요?
Better:
이 부분은 제가 이해가 조금 어려웠는데, 어떤 의도로 작성하셨는지 설명해주실 수 있을까요?
다른 방식으로 접근하면 이해하는데에 도움이 될 수 있을 것 같아 의견을 나눠보고 싶습니다.
논의해보고 더 좋은 방향을 함께 찾으면 좋을 것 같습니다.
상대를 존중하지 않는 표현들은 정보 전달보다 감정적 공격에 가까워 상대방을 방어적으로 만들고, 피드백의 본래 목적을 무너뜨립니다.
사실관계보다 비난과 비교, 감정 표현에 초점이 맞춰져 있어, 관계를 악화시키고 해결해야할 문제를 오히려 더 악화시킬 수 있습니다.
마음가짐
정말 죄송한데.. 사실 아까 식사 하실 때
입 냄새가 조금 나더라고요. 저만 알고 있겠습니다.
누군가는 이 말을 듣고 바로 화장실로 가거나 식사 후 바로 양치를 할 것이고, 누군가는 한 귀로 흘려버릴 것입니다.
아무리 좋은 피드백을 남긴다고 한들 리뷰를 받는 사람의 행동이 바뀌지 않는다면 무의미한 피드백이 될 뿐입니다.
따라서 우리는 좋은 피드백을 남겨야 하지만 동시에 좋은 피드백을 잘 수용할 줄 알아야 합니다.
피드백에서 감정을 걷어내고 사실만을 받아들여야 합니다. 피드백을 평가가 아닌 검증으로 바라보아야 합니다.
나에 대해 왜곡 없이 좋은 피드백을 남겨주는 사람들의 말을 주의 깊게 듣을 줄 알아야 합니다.
누군가에게 좋은 조언을 받았을 때, 그 가치를 아는 것도 능력입니다.
결론
피드백을 주고 받는 것은 서로 옳고 그름을 따지는 것이 아닙니다.
팀이 갖고 있는 문제를 더 잘 해결하고 미래에 예기치 못하게 발생할 문제들을 최소화 하는 수단일 뿐입니다.
설탕 피드백처럼 달콤하기만 하거나 유리조각 피드백처럼 상처만 남기기보다는,
객관적이고 구체적이고 실질적인 개선을 돕는 피드백을 주고받아야 합니다.
좋은 피드백을 주고받을 수 있는 그릇을 갖춘다면 우리는 더욱 더 단단한 개발자가 되고 단단한 팀을 만들 수 있습니다.
