저는 자주 틀립니다

AI 요약

Boris Cherny가 팀에 공유한 메모를 공개했습니다. AI 시대에 제품을 만드는 사람들에게 도움이 되기를 바란다는 취지입니다. 글의 출발점은 자신이 거의 모든 문제를 다룰 때 따르는 사고 순서입니다. 저자는 이 순서를 정답이나 보편 규칙으로 제시하지 않고, 자신이 실제로 사용하는 방식이라고 설명합니다.

■ 문제를 다루는 여섯 단계

첫 단계는 현재 이용할 수 있는 정보를 파악하는 일입니다. 그다음에는 빠진 정보를 모읍니다. 세 번째로 문제를 명확히 정의합니다. 네 번째로 문제를 풀기 위한 분명하고 단순한 접근법을 정합니다. 다섯 번째로 목표를 세웁니다. 마지막으로 목표를 이루기 위해 긴급성을 갖고 행동합니다.

저자는 이 여섯 단계를 한 번 실행하고 끝내지 않습니다. 진행 중에 새로운 정보를 얻으면 세 번째부터 다섯 번째 단계로 돌아갑니다. 문제를 다시 정의하고, 접근법과 목표를 다시 정한 뒤 같은 과정을 반복합니다. 복잡한 문제라면 올바른 방향을 찾기까지 여러 번 시도할 수 있습니다. 이 과정은 겉으로 보기에 계속 계획을 바꾸는 일처럼 느껴질 수 있습니다. 하지만 새 데이터가 들어왔을 때 판단을 고치는 과정 전체가 문제 해결의 일부라는 점을 인식하면, 이런 변화는 건강한 조정이 됩니다. 저자는 새로운 정보가 나오면 기존의 사전 판단을 업데이트해야 한다고 말합니다.

■ 제품에도 같은 절차를 적용합니다

저자는 이 대략적인 프레임워크를 거의 모든 문제와 제품에 적용합니다. 제품은 사용자에게 발생한 문제를 해결하는 것이라고 보기 때문입니다. 저자는 대부분의 날에 이 사고 순서를 여러 번 반복합니다. 특정 제품을 만들 때만 쓰는 별도 방법이 아니라, 일상적으로 문제를 바라보는 기본 절차에 가깝습니다.

이 접근에서 각 단계가 빠졌는지, 또는 어느 단계가 충분히 실행되지 않았는지를 확인하는 일도 중요하게 다룹니다. 저자는 다른 사람에게 피드백을 줄 때도 있고, 자신도 같은 방식으로 피드백을 받기를 기대합니다. 피드백은 나중에 평가하는 방식보다 실시간에 가깝게 주려고 합니다. 그래야 개인이나 팀이 더 빨리 배우고 다음 행동을 바꿀 수 있다고 보기 때문입니다.

■ 자주 발생하는 실패는 문제 정의와 해결 접근법입니다

저자가 가장 자주 발견하는 실패는 세 번째 단계와 네 번째 단계입니다. 문제를 명확하게 정의하지 못하거나, 해결을 위한 접근법을 분명하고 단순하게 만들지 못하는 경우입니다. 이 두 단계 가운데 하나라도 빠지면 계획이 복잡해지고 성공 여부를 판단할 기준도 흐려집니다.

특히 복잡한 문제에서는 계획을 세운 사람이 자기 계획의 불명확함을 알아차리기 어렵다고 설명합니다. 계획을 만든 본인은 필요한 배경과 의도를 이미 알고 있기 때문에, 다른 사람이 읽었을 때 어느 부분이 모호한지 놓치기 쉽습니다. 그래서 다른 사람에게 계획을 설명하고 피드백을 받는 일이 더 중요해집니다. 피드백은 계획의 모든 내용을 대신 결정하는 절차가 아니라, 문제 정의와 해결 방식이 실제로 다른 사람에게도 분명하게 전달되는지 확인하는 과정으로 제시됩니다.

■ 틀린 판단을 고치는 태도

저자는 이 사고 절차 자체가 잘못되었을 가능성도 열어 둡니다. 여섯 단계로 문제를 다루는 방식뿐 아니라, 그 방식을 점검하는 상위 과정도 틀릴 수 있으며, 새로운 정보가 있다면 바꿀 수 있다고 말합니다.

그래서 저자는 틀리는 일을 좋아한다고 표현합니다. 틀렸다는 사실을 인정하면 문제를 더 정확하게 정의할 수 있고, 적절한 해결책을 찾을 수 있으며, 더 빠르게 배울 수 있다고 보기 때문입니다. 글에서 말하는 ‘틀림’은 실패를 미화하는 표현이 아니라, 새로운 정보가 나왔을 때 기존 문제 정의와 목표를 수정하는 태도에 가깝습니다. 다만 저자는 이 방식이 모든 사람에게 맞는 유일한 프레임워크라고 주장하지 않습니다.

■ 피드백과 권력 관계를 둘러싼 반응

Hacker News에서는 이 글의 문제 해결 절차보다 피드백을 주고받는 조직 문화와 권력 관계를 둘러싼 반응이 많이 나왔습니다. 한 댓글은 영향력이 큰 위치에 있는 사람이라면 더 신중하고 체계적으로 행동해야 한다고 지적했습니다. 다른 댓글은 개인의 프레임워크를 팀원에게 따르게 한 뒤, 따르지 않으면 피드백이라는 이름으로 압박할 수 있다고 비판했습니다. 저자는 자신이 관리자가 아니라 IC라고 답했지만, 다른 독자는 높은 수준의 IC도 리더십 위치에 있으며 그 사람이 주는 피드백에는 상당한 무게가 실린다고 반박했습니다.

저자는 댓글 답변에서 이 글의 프레임워크가 유일한 정답이 아니며, 자신이 생각하는 방식을 팀에 전달하려고 쓴 글이라고 설명합니다. 또 ‘피드백’이라는 단어가 사람마다 다르게 받아들여질 수 있다고 인정합니다. 비난 없이 솔직하게 말하는 문화를 경험하지 못했다면, 피드백이라는 표현을 구성원이 조직의 방식에 맞도록 만들거나 경력에 영향을 주는 수단으로 느낄 수 있다는 설명입니다.

저자는 피드백을 주는 사람과 받는 사람 사이에 본질적인 권력 관계가 있다는 점도 인정합니다. 동시에 조직 문화가 피드백을 더 직접적인 대화를 위한 솔직한 방식으로 받아들이고, 동료들이 서로에게 직접 말할 때 심리적 안전을 느끼도록 만든다면 피드백이 모두에게 더 나은 문화를 만들고 결과도 개선한다고 말합니다. 자신은 여러 사람에게 피드백을 주었고, 그만큼 여러 차례 피드백을 받았다고 덧붙입니다. 이에 대해 다른 댓글은 IC라는 지위가 권력 관계를 약화한다고 보기는 어렵고, 심리적 안전 역시 자동으로 보장되지 않으며 사람마다 다르게 경험한다고 지적합니다.

■ Hacker News 반응

• @verdverm — 죄송하지만, 영향력이 어느 수준을 넘으면 속도를 늦추고 더 체계적으로 행동해야 합니다. 그렇게 가볍게 말해서도 안 됩니다.
• @glimshe — 개인적인 만능 프레임워크를 가진 관리자가 사람들에게 그 프레임워크를 따르라고 요구하고, 따르지 않으면 “피드백”을 주는 것만큼 짜증 나는 일도 없습니다.
• @dofm — 그가 자주 틀린다는 건 다들 알고 있습니다. 하지만 당신의 성과 평가에 관해서도 틀리는지는 모르겠습니다.
• @bcherny — 글쓴이입니다. 이것은 유일하게 옳은 프레임워크가 아니라 제가 사용하는 프레임워크입니다. 이 글의 목적은 제가 생각하는 방식을 팀에 전달하는 것이었습니다. 생각하는 방식에는 여러 가지가 있고, 그중 하나가 다른 방식보다 더 옳은 것은 아닙니다. 여기서 “피드백”이라는 단어도 여러 의미로 쓰였을 수 있습니다. 피드백이 솔직하고 비난 없는 문화의 일부인 조직에서 일해 본 적이 없다면, 이 단어가 누군가를 조직 방식에 맞추거나 경력에 영향을 주기 위한 불성실한 회사식 표현처럼 느껴질 수 있다는 점을 이해합니다. 피드백을 주는 사람과 받는 사람 사이에는 본질적인 권력 관계도 있습니다. 다만 조직 문화가 피드백을 더 직접적인 대화를 나누기 위한 솔직한 방식으로 받아들이고, 동료들이 이런 방식으로 직접 이야기할 때 심리적으로 안전하다고 느낀다면, 피드백은 모두를 위한 문화를 더 나아지게 하고 결국 더 나은 결과를 만드는 데 도움이 됩니다. 저는 여러 사람에게 피드백을 주었고, 그만큼 여러 번 피드백을 받았습니다. 그리고 저는 관리자(manager)가 아니라 IC입니다.
• @xfz — 댓글에 답하고 경험을 공유해 주셔서 감사합니다. “그리고 저는 관리자(manager)가 아니라 IC입니다”라는 말은 여기에 있는 권력 관계를 축소해서 보는 것 같습니다. 그 정도 수준의 IC라면 리더십 위치에 있지 않다고 말하기 어렵고, 그 사람이 주는 피드백에는 여전히 상당한 무게가 실립니다. 심리적 안전은 바람직한 목표이지만 자동으로 보장되지 않으며, 모든 사람이 똑같이 경험하지도 않습니다. 이 상황에서 심리적 안전에 지나치게 의존하는 일은 조심해야 한다고 봅니다.

원문: Boris Cherny / 커뮤니티: Hacker News / 번역·요약: Trawling