엔지니어의 리더십: 피드백 루프, 실패한 보고는 없다

작성자:

회사 생활을 하다 보면 다양한 보고를 하게 됩니다. 그리고 처음 관리자가 되고 나니 보고의 성격이 달라졌습니다. 그 전까지는 제가 만든 보고서를 직접 보고하는 일이 많았다면, 관리자 입장에서는 팀원들이 만든 보고자료로 팀원들과 함께 보고를 이끌어야 했습니다. 이때, 보고가 끝나고 나면 이 보고를 어떻게 마무리 지어야 할지 고민이 되었고, 그때 택한 방법이 보고를 복기하는 것이었습니다.

중요한 보고가 끝나면 주요 멤버들과 모여 방금 끝난 보고를 함께 복기했습니다. 그 자리에서 저는 보고 결과에서 긍정 시그널을 최대한 찾아 공유하고, 함께 토론했습니다. 칭찬을 받았다면 우리가 맞는 방향으로 가고 있다는 확인이니 좋고, 혼이 났다면 어디를 고쳐야 하는지 방향을 알게 되었으니 그것도 좋았습니다.

그래서 저는 이렇게 말하곤 했습니다. “실패한 보고는 없다. 모든 보고는 잘된 보고다.”

사실 소프트웨어 엔지니어링의 여러 원칙들이 피드백 루프와 관련하여 비슷한 이야기를 하고 있습니다. 제가 작성한 지난 글 「엔지니어의 리더십: 오탐과 미탐, 기술의 판단 기준」이 보고를 받는 쪽의 검토 기준을, 「엔지니어의 리더십: 보이지 않는 축, 아는 만큼 보인다」가 상대의 축을 읽는 법을 다뤘다면, 이번 글에서는 보고를 하는 쪽의 관점에서 정리해 보았습니다.

목차

피드백 루프

애자일 회고, 중요한 것은 결과가 아니라 프로세스

애자일 개발 방법론에는 회고(retrospective)가 있습니다. 스프린트가 끝나면 팀이 모여 잘한 점과 개선할 점을 정리합니다. 이때 중요한 것은 회고가 스프린트의 성패를 판정하는 자리가 아니라는 점입니다. 결과가 좋았든 나빴든, 그 결과를 만든 프로세스를 데이터로 놓고 검토합니다.

보고도 마찬가지입니다. 보고 결과는 우리 팀의 능력에 대한 판정이 아니라, 우리가 일하는 방식에 대한 프로세스 데이터입니다. 보고를 마치고 함께 복기하던 그 자리는 사실 보고에 대한 회고였던 셈입니다.

CI/CD 피드백 루프, 실패한 빌드의 의미

CI/CD 파이프라인에도 피드백 루프가 있습니다. 빌드가 실패하면 파이프라인은 실패 지점을 알려주고, 개발자는 그 정보로 코드를 고쳐 다시 빌드합니다. 실패한 빌드를 놓고 좌절하는 개발자는 없습니다. 실패는 종착점이 아니라 다음 빌드를 개선하는 입력값이기 때문입니다.

사실, 혼난 보고도 같습니다. 그 보고는 실패한 것이 아니라, 다음 보고를 개선하는 입력값을 확보한 것입니다. 실패한 빌드가 없듯, 실패한 보고도 없습니다.

강화학습 리워드, 낮은 점수도 신호다

강화학습에서 에이전트는 행동마다 리워드를 받습니다. 리워드가 높으면 그 행동을 강화하고, 낮으면 정책을 수정합니다. 여기서 핵심은 리워드가 높든 낮든 모두 정책 업데이트에 쓰이는 신호라는 점입니다. 낮은 리워드를 받았다고 학습이 실패한 것이 아닙니다. 오히려 낮은 리워드가 없으면 에이전트는 무엇을 고쳐야 할지 알 수 없습니다.

보고에서 받는 낮은 평가도 같은 신호입니다. 지금의 방향을 수정하라는, 그것도 꽤 구체적인 정보를 담은 신호입니다.

어긋난 순간, 변명 대신 탐색

잘 진행되던 보고가 어긋나기 시작하는 순간이 있습니다. 보고받는 분의 표정이 굳어지고, 질문이 날카로워집니다. 이때 분명한 사실은 보고 자료나 보고 내용 중 어딘가가 보고받는 사람을 만족시키지 못했다는 점입니다.

이 순간 가장 흔한 반응은 변명입니다. 하지만 가장 필요한 행동은 그 어긋난 지점을 빠르게 찾는 것입니다.

찾는 기준은 이미 있습니다. 지난 글에서 보고 자료는 조직의 상태를 요약한 뷰(View)라고 했습니다. 보고가 어긋났다는 것은 그 뷰 어딘가에 왜곡(오탐)이나 누락(미탐)이 있다는 뜻입니다. 보고받는 분의 날카로운 질문은 바로 그 지점을 가리키는 검산 과정이지, 보고자에 대한 심문이 아닙니다.

태도도 마찬가지입니다. 「보이지 않는 축」에서 반문하는 왜와 분석하는 왜를 구분했습니다. 변명은 반문하는 왜입니다. “내 보고는 맞는데 왜 혼내는가”라는 반응입니다. 어긋난 지점의 탐색은 분석하는 왜입니다. “보고받는 분은 왜 만족하지 못했는가, 그분이 보는 축은 무엇인가”를 묻는 것입니다.

더글러스 스톤(Douglas Stone)과 쉴라 힌(Sheila Heen)은 「Thanks for the Feedback」에서 피드백 받기가 어려운 이유를 설명합니다. 사람에게는 배우고 성장하려는 욕구와 지금 모습 그대로 인정받고 싶은 욕구가 있는데, 피드백은 이 두 욕구가 정면으로 충돌하는 지점이라는 것입니다. 변명은 인정받으려는 욕구가 이긴 결과입니다.

흥미로운 것은, 이 충돌을 인식하는 것만으로도 반응이 달라진다는 점입니다. “지금 내가 방어하고 싶은 것은 자연스러운 반응이다”라고 알아차리는 순간, 방어 대신 탐색을 선택할 여지가 생깁니다. 낮은 리워드를 받은 에이전트가 해야 할 일은 리워드에 항의하는 것이 아니라 정책을 수정하는 것입니다.

사람은 리워드 함수가 아니다

주의해야 할 점은 피드백을 신호로 다루라는 말이 감정을 무시하라는 말이 아니라는 것입니다.

강화학습의 에이전트와 사람은 결정적으로 다릅니다. 에이전트는 낮은 리워드를 받아도 자존심이 상하지 않고, 리워드를 주는 쪽과의 관계를 걱정하지 않으며, 몇 번이고 다시 시도할 수 있습니다. 사람은 그렇지 않습니다. 혼이 나면 아픕니다. 공들인 보고가 무너지면 속이 상합니다. 그 감정은 자연스러운 것이고, 억누른다고 사라지지 않습니다.

스톤과 힌은 같은 책에서 피드백이 사람을 흔드는 이유를 세 가지로 정리합니다. 내용이 틀렸다고 느낄 때(진실), 피드백을 주는 사람이 마음에 들지 않을 때(관계), 그리고 피드백이 나라는 사람 자체를 건드릴 때(정체성)입니다. 보고에서 받는 질책이 유독 아픈 것은 세 번째 때문입니다. “이 자료의 이 부분이 부족하다”라는 신호가 “나는 부족한 사람이다”라는 판정으로 번역되어 들리는 것입니다.

캐럴 드웩(Carol Dweck)은 「Mindset」에서 이 번역이 마인드셋에 따라 달라진다고 설명합니다. 능력이 고정되어 있다고 믿는 사람에게 피드백은 그 고정된 능력에 대한 최종 판정입니다. 그래서 피할수록 이득입니다. 반면 능력이 성장한다고 믿는 사람, 즉 성장 마인드셋(growth mindset)을 가진 사람에게 피드백은 다음 성장의 재료입니다. 그래서 많이 받을수록 이득입니다. 같은 질책이 한쪽에는 위협이고 다른 쪽에는 정보입니다.

주목할 점은 이것이 감정의 문제가 아니라 해석의 문제라는 것입니다. 속상한 감정은 그대로 두되, 그 피드백이 “너는 부족한 사람이다”라는 판정이 아니라 “이 지점을 고치면 된다”라는 신호라고 해석하는 것입니다. 감정을 존중하면서 해석을 바꾸는 것. 그것이 피드백을 신호로 다루는 태도의 실체입니다.

이 구분은 피드백을 주는 리더에게도 똑같이 적용됩니다. 구성원은 리워드 함수가 아니므로, 질책의 강도를 높인다고 신호가 더 명확해지지 않습니다. 오히려 정체성을 건드리는 순간 상대는 신호를 듣지 못하고 방어에 들어갑니다. 신호는 구체적일수록, 판정은 적을수록 잘 전달됩니다.

판정 대신 피드백 루프

개인의 태도만으로는 한계가 있습니다. 보고 체계 자체가 판정하는 방식으로 설계되어 있으면, 구성원은 결국 방어적으로 움직입니다. 혼나지 않을 보고, 문제가 드러나지 않는 보고를 만들게 됩니다.

이것이 조직에 치명적인 이유는 앞의 뷰 개념으로 설명됩니다. 보고가 성적표가 되는 순간, 구성원은 뷰를 다듬기 시작합니다. 나쁜 소식은 뒤로 미루거나 뺍니다(미탐). 성과는 실제보다 좋게 포장합니다(오탐). 보고 한 건 한 건은 매끄러워지지만, 경영진이 보는 뷰는 실체에서 점점 멀어집니다. 판정 구조는 구성원을 벌하는 것이 아니라 조직의 눈을 멀게 합니다. 무엇이 어긋나 있는지를 가장 먼저 알아야 할 사람이 가장 늦게 알게 됩니다.

보고 체계를 판정이 아닌 피드백 루프 구조로 바꾸는 것이 중요합니다.

  • 복기 : 보고 결과를 함께 검토하는 자리, 보고를 “제출”이 아니라 “신호 수집”의 단계로 재정의
  • 긍정 시그널 : 검토는 긍정 시그널, 잘된 지점을 먼저 확인 후 어긋난 지점을 말하는 것이 안전, 나쁜 소식이 숨지 않는다
  • 루프 닫기 : 찾아낸 수정 지점을 다음 보고에 실제로 반영, 반영하지 않는 신호 수집은 요식행위

처음 관리자가 되었던 시절 보고를 복기하던 자리가 바로 이 장치였습니다. 보고 직후 멤버들과 모여 긍정 시그널을 찾아 공유하고 토론하는 것, 그 자리에서 보고 결과는 누군가의 성적표가 아니라 팀이 함께 검토하는 데이터가 되었습니다. 칭찬은 방향 확인으로, 질책은 수정 지점으로 변환되어 다음 보고의 입력값이 되었습니다. 파이프라인의 피드백 루프를 조직에 만든 것입니다.

AI가 보고서를 써주는 시대

이 이야기는 AI 시대에 더 중요해집니다. 이전 글 「AI시대: AI 친화적인 보고? 문제는 ‘보고받는 사람’」에서 다뤘듯, 보고서 작성의 대부분을 AI가 대신해주는 시대가 오고 있기 때문입니다. 역설적으로, 이때 보고자는 더 방어적으로 가기 쉽습니다.

제가 생각하기에 적극적 피드백 수용의 관점에서 핵심이 되는 것은 내용을 얼마나 소유하고 있는가입니다. 보고 자리에서 날카로운 질문이 왔을 때 어긋난 지점을 찾으려면, 보고자가 내용을 장악하고 있어야 합니다. AI가 쓴 문서를 이해하지 못한 채 보고하면, 질문 앞에서 탐색은커녕 “AI가 그렇게 정리했습니다”라는 말밖에 할 수 없습니다. 이것은 방어도 탐색도 아닌 책임의 실종입니다. 피드백은 내용의 주인에게만 신호가 됩니다. 주인이 아닌 사람에게는 어긋난 지점을 가리켜줘도 그것이 소음일 뿐입니다.

AI를 잘 쓰는 것도 결국 같은 루프입니다. AI가 만든 초안을 스스로 먼저 검산하고, 보고에서 받은 피드백을 다음 보고의 컨텍스트로 축적하는 것입니다.

결국 같은 AI가 보고자에 따라 반대로 쓰입니다. 내용을 소유하지 않은 보고자에게는 단순한 포장 도구가 되고, 내용의 주인에게는 피드백 루프를 가속하는 도구가 됩니다.

맺음말

보고를 일회성 이벤트로 보면, 보고 결과는 잘했다 못했다는 한 가지 의미만 갖습니다. 그러나 보고는 수많은 업무 흐름의 중간에 놓인 연결입니다. 이번 보고는 이전 업무를 정리한 것이고, 동시에 다음 업무의 입력입니다.

그렇게 보면 보고의 진짜 의미는 보고 내용 자체를 넘어, 보고를 통해 얻은 맥락까지 포함합니다. 그리고 그 맥락에서 가장 중요한 것은 방향의 확인입니다. 칭찬이든 질책이든, 우리가 어디로 가야 하는지를 알게 되었다면 그 보고는 제 역할을 다한 것입니다.

실패한 보고는 없습니다. 단지 성장하는 과정일 뿐입니다.

ChulJoo Kim (김철주)

※ 참고문헌

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기