솔직한 피드백을 위한 환경 만들기

솔직한 피드백의 어려움

시행착오를 겪다 보면 조직에 노하우가 축적된다고 합니다. 하지만 정확히는 조직이 아니라 시행착오를 경험한 개인에게 노하우가 축적됩니다. 많은 조직이 노하우의 전수를 위해 문서화를 강조하지만 문서를 통해 전달할 수 있는 노하우는 극히 일부입니다. 심지어 대부분의 사람들은 문서를 제대로 읽지도 않습니다. 그렇기 때문에 서로 솔직하게 피드백을 줄 수 있는 문화는 중요합니다. 누군가 시행착오를 통해 배움을 얻었다면, 똑같은 문제를 반복하려는 사람을 목격했을 때 솔직하게 이야기할 수 있어야 합니다. 그래야 조직 수준에서 시행착오가 반복되는 문제를 방지할 수 있습니다.

솔직한 피드백의 중요성을 이야기할 때 많은 사람들이 고개를 끄덕이며 그 중요성에 동의합니다. 하지만 머리로 이해했다고 해서 솔직한 이야기를 거침없이 할 수 있는 것은 아닙니다. 문제를 인지했지만 서로 말하지 않는 상황은 흔히 일어납니다.

이유는 다양합니다. 내향적인 사람들이 주를 이루는 그룹이거나, 상대방의 기분이 상할까봐 지나치게 걱정하는 분위기가 있다거나, 내가 잘 모르는 분야여서 주눅 들어 있을 수 있습니다.

문제 제기에 소극적인 사람들도 문제를 제기해야 한다는 사실을 모르는 것은 아닙니다. 내가 이 말을 꺼내면 매일 얼굴 보고 협업해야 하는 상대방의 감정이 상하고 나와 어색한 관계가 될 수도 있다는 사실에 두려움을 느껴 망설이는 것 뿐입니다.

제품의 문제를 사용자의 관점에서 고민해야 하듯이, 솔직하게 피드백 주는 문화를 정착시키는 일도 어려움을 겪는 사람 관점에서 해결책을 찾아야 합니다. 눈치 보지 말라는 이야기를 반복하기 보다는, 피드백 받는 사람들의 감정을 관리할 현실적인 방법들을 찾아 실천하는 것이 더 좋은 방법입니다.

감정을 관리하는 능력에는 개인차가 있습니다. 부정적인 의견을 거침없이 수용하는 사람이 있고, 조심스러운 의견 제시에도 불같이 화를 내는 사람이 있으며, 동의하지 않더라도 감정을 꾹 누른 채 반대 의견을 제시하지 않는 사람도 있습니다.

하지만 개인이 감정을 얼마나 능숙하게 관리하느냐와 별개로, 비판을 공격으로 받아들이는 기제는 대부분의 사람들에게 공통적으로 나타납니다. 레이 달리오의 원칙을 보면 다음과 같은 내용이 있습니다.

조직이 이러한 원초적 방어기제와 관계 없이 냉정하게 의사결정하도록 훈련하는 일은 매우 어렵습니다. 하지만 다양한 시도를 하다보니 나름 긍정적인 효과가 있는 방법들이 있었습니다.

솔직한 피드백을 위한 환경 만들기

면대면을 의도적으로

최근 유연 근무제, 원격 근무제를 도입하는 회사가 많아지면서 비대면, 비동기로 일하는 문화가 급속도로 확산되고 있습니다. 시대의 흐름에 따라 회식도 점점 간소화되어가는 추세죠. 이러한 추세는 너무나 명확해서 시간이 지날수록 점점 더 많은 회사의 업무 방식은 슬랙이나 노션과 같은 도구에 의존한 비대면 커뮤니케이션을 중심으로 이루어질 것입니다.

사실 대부분의 업무는 비대면으로 진행해도 전혀 문제가 없습니다. 하지만 예민한 피드백을 주고 받는 사람들끼리는 회식, 티타임, 워크샵과 같은 면대면 활동을 활발히 갖는 게 좋습니다. 왜냐하면 직접 얼굴을 보고 대화하는 경우 상대방의 감정 변화를 알아챌 수 있는 단서가 훨씬 풍성하기 때문입니다. 상대방이 어떤 이야기에 어떻게 반응하는지 예상할 수 있다면, 피드백을 주는 사람의 심리적 부담감도 훨씬 줄어듭니다.

선공감 후설명

깊이 고민하고 시간을 쏟아 문제의 해결책을 고민하다 보면 누구나 자신의 아이디어가 모든 문제를 획기적으로 해결해 줄 것 같은 환상에 빠지게 됩니다. 이상한 일이 아닙니다. 애초에 아이디어란 자신의 경험과 지식을 모두 동원하여 내놓은 해결책이기 때문입니다.

그런데 신기하게도 타인의 입장에서 보면 잠재적인 문제가 가장 먼저 눈에 들어옵니다. 피드백을 주는 사람 입장에서 문제가 눈에 보이고 입이 근질거리더라도 잠깐만 참으세요. 고개를 끄덕이며 상대방 노력에 대해 공감을 표현한 다음 이야기를 시작하는 게 좋습니다.

제품과 관련한 의사결정을 하다보면 시스템 개선에 대한 요청을 받았지만 거절해야 하는 경우가 빈번합니다. 이 때도 무작정 안된다는 이야기를 꺼내기 보다는 상대방이 왜 이런 이야기를 꺼냈는지 그 상황에 대해 먼저 공감을 한 다음, 요청을 들어주기 어려운 현실적인 이유를 차분하게 설명해 주는 게 좋습니다.

아이디어 숙성

업무 분위기에 가장 큰 영향을 주는 요인 중 하나가 바로 주어진 일정입니다. 일정이 너무 빡빡하게 잡혀 있으면 이해도가 충분히 깊어지기도 전에 구현(개발)을 시작해야만 합니다. 목적지에 빨리 달려가고 있는 것 같지만 한참 가다보면 잘못된 곳으로 가고 있다는 사실을 뒤늦게 깨달을 때가 있습니다.

이런 문제가 발생하는 이유는 아이디어에 대해 충분한 숙성기간을 갖지 않았기 때문입니다. 우리가 어떤 문제에 대해서 깊이 파고들어 최선의 해결책을 찾으려고 노력하다보면 점점 문제와 해결책에 대한 이해도가 높아지고 더 좋은 해결책을 찾을 수 있습니다. 하지만 그 시점에 이미 임계점 이상으로 개발이 진행되어 있다면 확정된 해결책을 변경하기란 쉽지 않습니다. 시간을 갖고 아이디어를 숙성시키면, 문제를 제기하는 시점의 구현 매몰비용을 최소화 할 수 있습니다.

아이디어 숙성을 이야기할 때 자주 듣는 반대 의견이 있습니다. “일단 린(lean)하게 해야한다. 논의만 하고 진행을 못하니 답답하다.”라는 것입니다. 하지만 린한게 무엇인지 잘 생각해 봐야 합니다. 서비스 초기에는 무조건 빠른 게 답일 수도 있습니다. 하지만 충성고객이 충분히 늘어난 단계에서는 린(lean)의 개념도 바뀌어야 합니다. 다양한 고객이 상황을 어떻게 받아들일 것인지 숙고하는 과정은 줄여도 되는 요소가 아닙니다. 린(lean)은 무조건 일정을 줄이는게 아니라, 불필요한 프로세스를 최소화 한다는 관점에서 접근하는 게 좋습니다.

계획과 실행을 병렬로

프로덕트 매니저와 디자이너는 개발 시작 시점보다 한 분기 정도 앞서서 계획을 세우고 움직이면 좋습니다. 현재 실행 단계에 있는 업무, 다시 말해 개발이 진행되고 있는 프로젝트가 아닌 업무에 시간과 에너지를 할당하는 것입니다.

일단 개발이 시작되면 개발자는 당면한 기술문제를 해결하고 제품이나 기능이 출시되도록 만드느라 정신이 없습니다. 이 기간동안 프로덕트 매니저는 다음으로 어떤 문제를 해결할지에 대한 우선순위를 고민하고, 디자이너는 다양한 레퍼런스에 대해 조사할 시간을 확보해야 합니다. 또한 프로토타입을 만들어 다양한 이해관계자와 이야기 하면서 미리 파악하지 못한 이슈는 없는지 검토해야 합니다.

린(lean)이라는 단어가 남용되는 있는 것처럼 애자일(agile)이라는 단어가 남용되는 경우가 있습니다. 개발자가 너무 늦은 시점에 프로젝트에 참여하는 폭포수(waterfall)방식의 단점은 극복되어야 하지만, 그렇다고 해서 요구사항 정의 및 디자인이 개발과 동시에 진행되어야 하는 것은 아닙니다.

계획과 실행은 명확히 분리하는 편이 좋습니다. 일이 계획 단계에 있을 경우, PM이 주도하면서 개발자가 요구사항 및 디자인에 대한 리뷰어로서 참여할 수 있는 환경을 조성하는 게 좋습니다. 일이 실행 단계로 넘어가면 주도권을 개발자에게 넘기고 PM과 디자이너는 제품 출시를 보조하는 역할로 참여해야 합니다. 이렇게 계획과 실행단계를 명확히 구분하면 더 많은 사람이 편하게 문제를 제기할 수 있습니다.

피드백 주기를 빠르게

제품을 만드는 사람들은 무언가를 만드는 일 자체가 좋은 사람인 경우가 많습니다. 그런데 좋아하는 일을 하다보면 자연스레 그 결과물과도 사랑에 빠지기 쉽습니다. 사랑에 빠진 사람에게는 엄청난 에너지가 뿜어져 나오지만 그만큼 객관적인 시각을 갖지 못하게 될 가능성이 높습니다.

이 때 효율적인 방법 중 하나가 피드백의 주기를 빠르게 하는 것입니다. 해결해야 할 문제나 솔루션의 불확실성이 높을 때, 일시적으로 리뷰의 빈도를 주당 3~5회 정도로 올리는 것입니다. 타인의 시선을 자주 접하게 할수록 문제를 더 객관적으로 볼 수 있을 가능성은 증가합니다.

주의해야 할 점도 있습니다. 피드백의 주기를 빠르게 한다는 사실이 리뷰 횟수 총량의 증가를 의미하지 않는다는 것입니다. 많은 피드백을 필요로 하는 프로젝트 초기에 리뷰를 자주 진행하면, 프로젝트 중반 이후에 접어들수록 이야기 하거나 협의해야 할 사항이 훨씬 줄어들기 때문에 전체적인 커뮤니케이션 비용은 오히려 낮아지는 경우가 많습니다.

세 명 이상 그룹으로 모여서 리뷰하기

리뷰를 진행하다보면 객관적인 시각에서 피드백을 줬는데, 주관적인 느낌으로 피드백을 주려 한다고 받아들이는 경우도 많습니다. 이러한 문제를 방지할 수 있는 좋은 수단은 동시에 두 명 이상이 피드백을 주도록 하는 것입니다. 경험이 많은 사람도 때때로 멍청한 아이디어를 내는 경우가 있습니다. 이런 아이디어가 나올 경우 두 명 이상의 사람은 동시에 반대 의견을 낼 테고, 피드백을 받는 사람도 본인의 의견이 정말 맞는지에 대해서 다시 한 번 진지하게 되돌아 볼 것입니다. 따라서 피드백을 주고 받을 때에는 전체 인원이 세 명 이상 그룹으로 구성되도록 하는 것이 좋습니다.

의사결정을 다수결로 해야 한다는 뜻은 결코 아닙니다. 세 명중 두 명이 반대하더라도 계속 의논하고 설득해서 진행해야 하는 일도 있습니다. 중요한 사실은 두 명이 동시에 반대 의견을 내는 것은, 멍청한 아이디어를 이야기 한 사람의 머릿속이 번쩍하게 하는데 특효약이라는 점입니다.

적절한 도구를 사용하여 리뷰과정을 기록하기

반복적으로 리뷰하며 요구사항과 디자인을 수정해 나가다보면 처음에 상상한 제품과 전혀 다른 결과물에 도달할 때가 많습니다. 이 때 발생하는 문제는 프로젝트 초기부터 참여한 사람과 나중에 참여하는 사람간에 이해도 격차가 발생한다는 점입니다.

이미 리뷰를 함께 해 온 사람에겐 당연하게 느껴지는 부분에 대해서 “왜 이런 형태가 된 것인가요?”라는 질문을 할 때가 많습니다. 당연한 이야기겠지만 이런 질문을 하는 사람에게도 차분하고 친절하게 설명해줘야 합니다. 이런 설명 과정이 매끄럽지 않으면 초기 리뷰에 참석하는 소수의 사람들에게 배타적인 감정을 품을 수 있습니다.

이렇게 설명하는 데에 드는 커뮤니케이션 비용은 결코 적지 않습니다. 그래서 처음부터 많은 사람을 리뷰에 참석시킬까 하는 유혹에 빠지게 됩니다. 하지만 리뷰에 참석하는 사람이 처음부터 많으면 안됩니다. 사람들의 시간을 낭비할 뿐더러 요구사항과 디자인의 수정 방향도 갈피를 잡기가 어렵게 됩니다. 리뷰는 3~5인 정도의 소수 인원으로 시작하여 최종적으로는 프로젝트에 참여하는 모든 사람의 의견을 수렴하는 방식으로 서서히 확장하는편이 좋습니다.

더 좋은 피드백 시스템의 지속가능성을 위하여, 이런 커뮤니케이션 비용 문제도 극복되어야 합니다. 리뷰 때마다 미리 내용을 문서 형태로 준비하고, 리뷰가 끝난 후에 회의록을 잘 남겨 두는 방식으로 해결할 수 있습니다. 이렇게 하면 프로젝트 종반에 참여하는 사람도 리뷰 과정을 훑어보면서 효율적으로 진행상황을 따라잡을 수 있습니다.

마치며

“내가 이전에 이런 시도를 했더니 이런 문제가 있었다. 참고하시라.”라는 이야기는 어찌 보면 꼰대 같이 느껴지기도 합니다. 정서적인 반발감이 생기기 쉽습니다. 주관이 강한 구성원들은 이미 선험자가 있더라도 처음부터 다시 고민하고 직접 시행착오를 해보며 학습하고 싶어합니다. 하지만 회사라는 집단의 관점에서 보면, 시행착오의 반복을 방관하는 상황이 일어나서는 안됩니다. 이 글이 건강한 피드백 문화를 고민하는 조직에 조금이라도 도움이 되길 바랍니다.

리디 기술 블로그