본문으로 건너뛰기
Hooney Notes

피드백은 일찍, 사람에 대한 판단은 천천히

사람을 판단하기 전에 프로세스와 리더십을 점검하고, 책임과 권한이 분명한 상태에서 피드백하려 한다.

  • 일하는 방식
  • 협업
  • 피드백
  • 디자인
  • 프로세스
서로 다른 파랑과 주황 경로가 필드노트 위에서 만나 하나의 점검 경로로 이어지는 장면.

검토에서 기준의 차이를 발견하고, 그 차이를 다음 작업의 체크 항목으로 남겼다면 이제 그 기준을 실제 피드백에 사용해야 한다.

나는 개선이 필요하다고 느끼면 일찍 부딪혀보는 편이다. 누가 맞는지 가리기 전에, 무엇이 다른지 알아야 하기 때문이다. 내가 말하는 마찰은 싸움에 가깝기보다 코드 리뷰와 같은 피드백에 가깝다.

무엇을 완료라고 생각하는지, 어디까지를 자기 일이라고 보는지, 바꾸기 어렵다면 그 이유는 무엇인지. 이런 차이를 모른 채 일을 서두르고 싶지는 않다.

예를 들어 디자인을 넘기는 사람은 화면을 그렸으니 완료라고 생각할 수 있다. 반면 받는 사람은 좁은 화면에서의 상태와 예외까지 결정되어 있어야 완료라고 생각할 수 있다. 두 사람 모두 자기 기준에서는 일을 끝냈지만, 다음 단계에 필요한 조건은 다르다.

이 차이를 개발이나 QA에서 처음 발견하면 누군가는 뒤에서 빈칸을 채워야 한다. 구현을 시작한 뒤에야 서로 다른 일을 생각하고 있었다는 사실을 알게 되기 때문이다.

그래서 “왜 시작부터 부딪히느냐”는 질문에는 이렇게 답할 수 있다.

시작부터 문제가 있는지 확인하는 거다. 일이 진행된 뒤에야 서로 다른 일을 생각하고 있었다는 걸 알고 싶지 않아서.

사람보다 프로세스를 먼저 본다

문제가 보이면 먼저 거시적으로 살펴야 한다. 완료 기준이 명확했는지, 필요한 정보와 시간이 있었는지, 결정할 사람에게 실제 권한이 있었는지, 리더의 결정이 늦어져 병목이 생기지는 않았는지부터 확인한다.

같은 누락이 여러 사람과 여러 작업에서 반복된다면 개인의 성의가 첫 번째 원인일 가능성은 낮다. 역할의 경계가 불분명하거나, 결정권은 없는데 책임만 주어졌거나, 리더가 해결해야 할 충돌을 실무자끼리 감당하고 있을 수 있다. 이때 사람부터 평가하면 조직이 만든 문제를 개인에게 넘기게 된다.

프로세스와 리더십을 점검한 뒤에는 개인의 실행을 봐야 한다. 기준과 권한, 필요한 지원이 주어졌는데도 같은 문제가 반복된다면 그때는 역량과 선택, 책임의 문제를 구체적으로 다룰 수 있다. 사람을 무조건 보호하자는 뜻도, 개인의 책임을 없애자는 뜻도 아니다.

나는 평가의 순서가 프로세스와 리더십에서 개인으로 가야 한다고 생각한다. 이 순서는 사람을 성급한 판단에서 보호하면서, 조직이 자신의 구조적 문제를 숨기지 못하게 한다.

빠르게 부딪히는 것과 강하게 부딪히는 것은 다르다

다만 빠르게 질문하는 것과 강하게 압박하는 것은 분리해야 한다. 처음부터 압박을 크게 주면, 상대가 업무를 어떻게 생각하는지보다 압박받을 때 어떻게 방어하는지를 보게 될 수도 있다. 관찰하려던 목적이 흐려지는 것이다.

“왜 개선할 생각을 안 하세요?”라고 묻는 대신, “이 누락 때문에 다음 단계에서 같은 질문이 반복되는데, 전달 전에 확인하기 어려운 이유가 뭔가요?”라고 물을 수 있다.

이렇게 물으면 관심의 문제인지, 시간의 문제인지, 권한의 문제인지 확인할 여지가 생긴다. 문제를 늦추지 않으면서도 사람에 대한 결론은 잠시 보류할 수 있다.

질문은 일찍 하되, 사람에 대한 결론은 서두르지 않는 것. 내가 말하는 이른 마찰은 그 태도에 가깝다.

결정권에는 근거와 책임이 함께 있어야 한다

사람에 대한 판단을 늦추려면 피드백의 근거가 먼저 보여야 한다. 어떤 완료 기준이 빠졌는지, 기존 규칙과 무엇이 다른지, 다음 단계에 어떤 재작업을 만드는지를 함께 볼 수 있어야 한다.

어떤 작업에도 최종 의사결정권자는 있어야 한다. 그 일을 실제로 추진하는 DRI(직접 책임자)가 여러 의견과 근거를 확인한 뒤 “이 정도면 됐다”고 결정하고, 실행과 결과에 책임지는 것이 맞다.

리더도 이 검토의 예외가 아니다. 리더가 맡은 범위에서는 그 리더가 DRI여야 한다. 직접 실행에서 멀어진 채 사람을 평가하는 데 그치는 것이 아니라, 우선순위를 정하고 필요한 결정을 내리며 반복되는 문제를 프로세스 개선으로 바꿔야 한다. 조직은 리더에게 충분한 권한과 자원을 주었는지 점검하고, 동시에 그 리더가 병목과 재작업을 실제로 줄였는지도 검토해야 한다.

내가 조직을 만든다면 리더에게 같은 범위의 실무자보다 적어도 1.5배, 역할의 무게에 따라 2배를 보상할 준비가 되어 있어야 한다고 생각한다. 직함이 더 높아서가 아니라, 더 넓고 어려운 책임을 맡기기 때문이다. 리더는 직접 움직이고, 결정하고, 결과를 설명하고, 다음에는 같은 문제가 반복되지 않도록 일하는 방식을 고쳐야 한다.

충분한 보상과 결정 권한은 주지 않은 채 실무자의 책임까지 떠넘기는 자리는 리더십이 아니다. 반대로 실행 능력과 책임이 확인되지 않은 사람에게 직함만 주고 사람을 관리하게 해서도 안 된다. 리더는 사람 위에 있는 사람이 아니라, 팀이 더 잘 일할 수 있는 조건을 만들고 그 결과에 책임지는 사람이어야 한다.

문제는 결정권이 있다는 사실이 아니다. 근거와 책임은 보이지 않은 채 그 사람과 가까운 사람이 더 쉽게 예외를 얻는 방식이 반복되는 것이다. 공식 절차가 있어도 실제 통과 여부가 친분에 따라 달라진다면 품질의 기준은 작업이 아니라 관계가 된다.

사람 사이의 정치적인 판단을 완전히 없앨 수는 없다. 나 역시 내 판단을 지키고 싶어질 수 있다. 그래서 적어도 사업에서 완료와 품질을 정하는 과정은 개인의 권위가 아니라 공개된 기준과 근거에 가까워지도록 계속 고쳐야 한다고 생각한다.

AI는 DRI를 대신하는 결정권자가 아니라, 개인에 따라 달라지는 첫 검토를 줄이는 장치가 될 수 있다. 합의한 체크리스트와 관찰 가능한 수치를 기준으로 누락을 먼저 보여주고, 같은 조건에는 같은 질문을 제시하는 역할이다.

그 이후의 피드백과 리뷰는 사람이 함께해야 한다. AI가 표시한 항목이 실제 문제인지, 예외를 허용할 이유가 있는지, 기준 자체를 바꿔야 하는지 대화한다. 최종적으로는 DRI가 결정하고 그 결과에 책임진다. AI는 사람을 평가하는 심판이 아니라, 사람들이 같은 근거에서 대화를 시작하게 돕는 리뷰어여야 한다.

마찰의 목적은 승리가 아니다

부딪힌 뒤에 누가 옳았는지를 확인하는 것만으로는 충분하지 않다. 무엇을 완료라고 부를지, 누가 결정할지, 다음에는 어떤 정보를 남길지를 합의해야 한다.

그렇지 않으면 같은 대화가 다른 화면과 다른 일정에서 다시 반복된다. 그때 내가 제공한 것은 개선을 위한 마찰이 아니라, 매번 일을 움직이기 위한 개인적인 압박이 된다.

나는 불편한 질문을 피하고 싶지는 않다. 다만 질문이 상대를 몰아붙이는 방식이 아니라, 다음 단계의 조건을 분명히 하는 방식이어야 한다고 생각한다.

일찍 부딪힌다는 것은 갈등을 빨리 만드는 일이 아니다. 서로 다른 완료 기준과 책임의 경계를 늦기 전에 확인하는 일이다. 이번에 드러난 차이가 공개된 기준으로 남고, 다음 피드백이 그 기준에서 시작될 때 마찰은 비로소 일을 더 잘되게 만든다.

Hooney (Seolhun)

소프트웨어를 만들고, Firstage를 운영합니다. 이곳에는 일하고 배우고 살아가며 무엇을 선택했고, 왜 그렇게 생각했는지를 남깁니다.

의견과 대화

댓글은 누구나 읽을 수 있습니다. 의견을 남기려면 GitHub 계정으로 로그인해 주세요.

댓글이 보이지 않나요?GitHub에서 대화 찾기 ↗