개발자가 맘상하지 않는 피드백

답답하면 직접 개발하던가?

피드백의 중요성과어려움

직장생활은 매번 피드백과 개선의 연속이다. 작업내용에 대해 상사나 동료들에게 피드백을 받고 개선점을 찾아 고쳐나간다. 그러다보면 작업물은 공동의 목표에 닿아가고, 만족에 다가가게 된다. 그런데 우리의 직장생활이 짜증나고 힘든건 그 피드백이 감정을 상하게 하고, 공동의 목표에 다가가는 것 같다는 느낌을 주지 않기 때문이다.

우리는 기획자로서 요청한 사항에 대해 개발자의 작업물들에 대해 피드백을 한다. 우리가 피드백을 하는 목표는 ’제품을 개선하기 위함’ 이다. 만약 지속 가능한 개선을 원한다면 개발자와 좋은 관계를 유지하면서도 제품을 개선시키는 피드백 방법을 찾아야 한다. 그렇지 않다면 상사의 피드백에 감정이 상한 우리들처럼 개발자도 마음이 떠나 조직과 제품에 안좋은 영향을 미칠 것이다. 어떻게 개발자의 마음을 상하지 않도록 피드백 할 것인지 알아보자.

피드백하기 전 알아야 할 기본원칙

타인의 업무나 아이디어등에 대해 피드백하기전에 반드시 유념해야 할 것은 이야기하는 사람이나 듣는 사람이나 같은 컨텍스트에 있다는 것이다. 쉽게말하면 우리는 같은편이고 적은 회사 밖의 경쟁제품이지 이야기를 하고있는 동료가 되어선 안된다. 개발자들은 분명 우리 제품을 개선하기위해 노력하는 사람이다. 그래서 대화를 시작할때 “그래 당신이 옳다.“라는 말로 먼저 공감을 해주고 시작하면 좋다. 한국식 대화시작어 ”아니, 잠깐만요” 라고 시작하는것은 피하라고 조언하고 싶다.

피드백을 할때는 문제가 아닌 해결에 초점을 맞춰야한다. 문제가 무엇인지, 누가그랬는지 확인하는 것 보다 어떻게 개선해 나갈 것인지 언제까지 조치가 가능한지 확인하는게 더 중요하다. 타겟이 되면 방어적인 태도를 취하기 마련이다. 누구나 실수할 수 있음을 이해하고 해결방법을 찾을 수 있도록 리드해야한다. 같은 맥락에서 작업자 개인에 대한 피드백이 아닌 작업물 자체에 대해 초점을 맞춰야 한다. “어제 김대리님 반영하신거 안된다고 게시판에 글올라왔던데요.”라는 말보다 “어제반영한 ***티켓건 이슈가 있다는 리포트가있는데, 같이 확인해봤으면 좋겠습니다.” 라는 말로 타겟을 사람이아닌 작업물로 조정해야 한다.

피드백 내용은 작업자의 전문성과 자율성을 존중하며 정해야 한다. 일정을 산출하는 회의에서 “이건 그렇게 길게 안걸릴거 같은데요? n일만 쓰시면 안될까요?” 라고 말하면, “답답하면 니가 뛰든가”라는 기성용선수의 유명한 이야기가 떠오른다.

존중이 없이 피드백을 하고 상대방의 긍정적 반응을 기대하기는 어렵다. 어디까지 내가 이야기할 수 있는지 영역을 확인하고 상대방의 영역을 침범하는 일은 지양해야 한다.

사람마다 선호하는 피드백 스타일은 다를 수 있다. 직접적으로 문제되는 부분을 이야기하는것을 좋아하는 사람도 있지만, 돌려서 말해주면 스스로 문제를 찾아내는것을 선호하는 사람도 있다. 몇 번 함께 일하다 보면 선호하는 방식을 감지할 수 있지만, 새롭게 만난 사람에게 피드백을 해야하는 상황이라면 어떤방식을 선호하는지 물어보는것도 좋다.

여러 피드백 원칙 중 마지막으로 중요한 건 피드백 제공자로서 모범을 보이는 자세다. 듣는이가 노예가 된 것 처럼 마치 주인인 양 피드백하는 사람들이 있다. 함께 일하는 동료들에게 피드백을 하는거라면 함께 이 문제를 해결하자는 건설적인 태도를 갖고 격려하며 수정될 때 까지 같이 챙기는 모습을 보여야 한다.

효과적인 피드백 전달법

기본 원칙을 상기한 상태에서 피드백을 하기로 마음먹었다면 도움이 될 몇가지 전달방법이 있다. 피드백을 하는 시간과 장소를 통제하면 상대방을 배려하고 존중하는 느낌을 줄 수 있다. 많은사람들이 참여한 회의에서 특정 사안에 대해 지적하면 의도가 그렇지 않더라도 모욕당한 기분이 들 수 있다. 1:1 상황을 만들고 다른사람들에게 공개되지 않은 상황에서 피드백하면 불필요한 감정상함을 방지할수 있다.

긍정적인 말로 이야기를 시작하는것은 전통적인 대화스킬중 하나이다. 칭찬으로 이야기를 시작해 본론에서 하고자하는 메시지를 전달하고, 마지막엔 칭찬으로 마무리하면 핵심내용은 전달하되 기분상하는것을 어느정도 막을 수 있다.

말의 주체를 상대방이 아니라 나로 조정하는것도 공격성을 줄이는데 도움이 된다. 이는 ‘나 전달법’ 이라고 부른다. “아까 과장님이 이야기한거 이해가 안되요.” 보다 “제가 아직 개념이 확실히 잡히지 않아서 그런데 한번더 설명해 주시겠어요?”라며 주체를 ‘나’로 바꾸면 상대방의 방어적 태도를 누그러뜨릴 수 있다.

피드백의 대상이 개발자라면 구체적이고 객관적인 표현을 사용하는것이 필요하다. “게시판보니까 일부 유저가 참여가 안되는 문제가 있대요.“라는 표현은 ”지난 반영 직후부터 어제 확인시점까지 페이지에서 ’참여’버튼을 눌렀을때 페이지가 무한로딩하는 증상이 있었다는 고객 리포트가 6건 확인됐어요.“라고 말하면 문제를 해결하는 구체적 진입점을 찾는데 도움을 줄 수 있다. 또 말로 설명하기보다 가능하면 시각자료를 활용하는것이 좋다. 특히 재연방법이 담긴 동영상자료가 있다면 문제를 진단하고 해결하는데 큰 도움이 되기 때문에 화면을 녹화해두는 습관을 가지면 좋다.

적극적 경청과 대화 기술(Deep-dive)

효과적으로 피드백을 주고받기 위한 구체적인 대화 스킬들을 몇가지 더 소개한다. 대화를 시작할때 개방형 질문으로 시작해 원하는 방향으로 흐름을 이끄는 방법이 있다. 네/아니오로 귀결되는 질문이 아닌 상대방의 참여를 유도하는 질문을 통해 답변자의 아이디어나 다양한 관점을 이끌어 낼 수 있다. “과장님은 혹시 이런 비슷한 문제를 경험해본적이 있으세요?” 혹은 “이 이슈를 확인하기위해 과장님이 저라면 어떤걸 좀더 챙겨보면 좋을까요?“ 라는 질문은 상대방의 경험을 존중하고 적극적 참여를 유도할 수 있는 힘이 있다.

대화를 할때 바디랭기지를 적극적으로 활용하면 좋다. 상대방이 이야기할때 미소를 지으며 눈을 맞추고, 끄덕이는등 경청의 신호를 들으면 상대방은 자기 생각을 이야기하고 싶어진다. 대화하며 상대방의 호감을 얻는 기술로 ‘반복하기‘ 기술이 있다. 상대방의 마지막 문장을 따라하는건데, 우리가 구현할 수 없는 제약에 부딪혔을때 개발자가 ”B사 API에서 이 값을 주지 않아서 안되요.“라고 말했을때, “API에서 값을 주지 않아서 안되는군요, 다른 방법이 없을까요?“라고 반복하는 것이다. 상대가 나를 이해하고있다는 느낌을 줄 뿐더러 참여를 유도하는 방식으로 대화를 풀어간다면 성공적인 피드백 대화로 이끌어 나가는데 도움이 된다.

한가지 덧붙이면 대화를 할때 침묵을 효과적으로 활용하는것도 좋다. 대화중 침묵은 강력한 효과가 있다. 깊이 생각하고있다는 인상을 주고 상대방으로 하여금 무언가 말해야한다는 강한 신호를 준다. 반대로 상대방이 침묵을 한다면 그 시간을 존중하는 태도를 보임으로서 충분히 생각할 시간을 제공하는 것도 필요하다. 침묵의 활용방법에 대해서는 아래 브런치 글을 활용하면 좋다(https://brunch.co.kr/@thebcstory/163)

상황별 피드백 전략

버그 리포팅을 할 때는 재현 단계와 예상 결과를 명확히 전달하는 것이 중요하다. "로그인 후 프로필 페이지에서 '수정' 버튼을 클릭하면 오류 메시지 없이 화면이 멈춥니다. 정상적으로는 수정 모드로 전환되어야 합니다."와 같이 구체적으로 설명하면 개발자가 문제를 빠르게 파악하고 해결할 수 있다. 가능하다면 로그나 오류 메시지도 함께 제공하는 것이 좋다.

UI/UX 개선을 요청할 때는 사용자 입장에서 페르소나를 활용해 설명하는 것이 효과적이다. "우리 주요 사용자인 30대 직장인이 퇴근 후 피곤한 상태에서 이 앱을 사용할 때, 이 버튼의 위치가 손이 닿기 어려운 곳에 있어 불편함을 느낄 수 있습니다"와 같이 맥락을 제공하면 개발자도 사용자 경험의 중요성을 이해하기 쉽다. 가능하다면 사용자 테스트 결과나 피드백 데이터를 함께 제시하면 더욱 설득력이 있다.

성능 이슈를 논의할 때는 구체적인 데이터를 들어 설명하되, 그것이 개발자의 잘못이 아닐 가능성이 높음을 인지해야 한다. "최근 페이지 로딩 시간이 3초에서 7초로 늘어났는데, 이는 사용자 이탈률과 직접적인 연관이 있습니다. 함께 원인을 찾아볼 수 있을까요?"와 같이 접근하면 방어적 태도를 줄일 수 있다. 성능 이슈는 다양한 요인에서 발생할 수 있으므로, 함께 문제를 해결하는 자세가 중요하다.

코드 품질에 관한 피드백은 가장 조심스러워야 하는 영역이다. 개발자에게 코드는 자신의 전문성과 직결된 부분이기 때문이다. 직접적인 비판 대신 질문으로 접근하는 것이 좋다. "이 부분이 나중에 확장될 때 어떻게 대응할 수 있을까요?" 또는 "최근 많이 바쁘셨죠? 이 부분을 리팩토링할 시간이 있다면 어떻게 개선하고 싶으신가요?"와 같이 개발자 스스로 개선점을 찾도록 유도하는 것이 효과적이다.

일정 지연이 발생했을 때는 비난 없이 해결책을 함께 모색하는 자세가 중요하다. "예상보다 작업이 길어지고 있는데, 어떤 어려움이 있는지 이해하고 싶습니다. 제가 도울 수 있는 부분이 있을까요?"라고 접근하면 개발자는 방어적 태도 대신 솔직하게 상황을 공유할 가능성이 높아진다. 일정 지연은 대개 예상치 못한 기술적 문제나 요구사항 변경에서 비롯되므로, 함께 해결책을 찾는 것이 중요하다.

팀 협업 문제를 다룰 때는 개인에게 책임을 전가하지 않는 것이 핵심이다. "우리 팀의 커뮤니케이션 방식이 효율적이지 않은 것 같습니다. 어떻게 하면 정보 공유가 더 원활해질 수 있을까요?"와 같이 팀 전체의 문제로 접근하면 방어적 태도를 줄일 수 있다. 협업 문제는 대개 시스템적인 이슈이므로, 개인을 탓하기보다 프로세스 개선에 초점을 맞추는 것이 효과적이다.

피드백 이후 Follow Up

피드백을 제공한 후에는 개선 사항을 인정하고 칭찬하는 것이 중요하다. 개발자가 피드백을 반영해 변화를 만들었다면, 그 노력과 결과를 구체적으로 인정해주어야 한다. "지난번 논의했던 로딩 속도 이슈를 해결해주셔서 감사합니다. 7초에서 2초로 줄어들어서 사용자 반응이 너무 좋아요."와 같이 구체적인 칭찬은 개발자에게 동기부여가 되고, 앞으로도 피드백을 수용하는 긍정적인 태도를 형성하는 데 도움이 된다.

피드백은 일회성 이벤트가 아닌 지속적인 소통의 일부가 되어야 한다. 정기적인 1:1 미팅이나 코드 리뷰 세션을 통해 개발자와의 소통 채널을 열어두는 것이 중요하다. 이를 통해 작은 이슈들이 큰 문제로 발전하기 전에 해결할 수 있고, 서로에 대한 이해도 깊어진다.

제공한 피드백이 실제로 어떤 효과를 가져왔는지 측정하는 것도 중요하다. 사용자 만족도, 버그 발생률, 개발 속도 등 객관적인 지표를 통해 피드백의 효과를 확인할 수 있다. 이러한 데이터는 앞으로의 피드백 방향을 설정하는 데 도움이 된다.

마지막으로, 자신의 피드백 방식을 지속적으로 개선하는 자세가 필요하다. 완벽한 피드백은 없으며, 상황과 상대에 따라 적절한 방식은 달라질 수 있다. 때로는 "제가 피드백을 드리는 방식에 대해 어떻게 생각하시나요? 더 도움이 되는 방법이 있을까요?"라고 물어보는 것도 좋은 방법이다. 이를 통해 피드백 제공자로서 자신의 스킬을 향상시킬 수 있다.

건강한 피드백 문화를 만들자.

진정으로 효과적인 피드백은 양쪽이 모두 좋은 태도를 가질 때 가능하다. 기획자가 개발자에게 피드백을 주는 것뿐만 아니라, 개발자도 기획자에게 피드백을 줄 수 있는 환경을 조성하는 것이 중요하다. "저의 기획 문서나 요구사항 정의에 대해 어떤 부분이 더 명확했으면 좋겠는지 알려주세요"라고 먼저 요청함으로써 양방향 피드백의 문을 열 수 있다.

건강한 피드백 문화의 핵심은 신뢰와 존중이다. 서로가 같은 목표를 향해 나아가는 동료라는 인식, 그리고 피드백이 개인을 비난하기 위한 것이 아니라 제품과 팀을 개선하기 위한 것이라는 믿음이 바탕이 되어야 한다. 이러한 신뢰는 하루아침에 형성되지 않으며, 일관된 행동과 태도를 통해 시간을 두고 구축해야 한다.

지속적인 개선을 위한 열린 소통 문화는 팀의 성장에 필수적이다. 실수를 숨기거나 비난하는 대신, 이를 학습의 기회로 삼는 문화를 조성해야 한다. "실패해도 괜찮다, 그러나 같은 실패를 반복하지 말자"라는 마인드셋은 혁신과 성장을 촉진한다.

결국, 효과적인 피드백은 단순한 기술이나 방법론을 넘어서는 문화적 요소다. 개발자의 마음을 상하지 않게 하는 피드백은 단기적으로는 원활한 협업을, 장기적으로는 더 나은 제품과 더 강한 팀을 만드는 기반이 된다. 우리 모두가 피드백을 주고받는 방식에 조금만 더 신경 쓴다면, 일의 결과물뿐만 아니라 일하는 과정 자체도 더욱 풍요로워질 것이다.