제품을 만드는 일은 정답을 한 번에 맞히는 경기가 아니다. 개발자이자 관리자인 보리스 체르니가 최근 자신의 팀에 공유한 뒤 블로그에도 올린 짧은 메모는 이 점을 정면으로 짚는다. 글의 제목부터가 "나는 자주 틀린다(I am often wrong)"이고, 그는 틀리는 것을 부끄러워하기는커녕 "가장 좋아하는 일"이라고까지 말한다. AI가 제품 개발의 전제를 빠르게 바꾸는 지금, 이 태도가 왜 실무적으로 의미가 있는지 살펴볼 만하다.
체르니는 거의 모든 문제와 제품에 동일한 접근 절차를 적용한다고 말한다. 그는 이를 여섯 단계로 이루어진 대략적 틀로 설명하는데, 원문에서 그 여섯 단계의 구체적 항목 전체가 그대로 나열되지는 않는다. 다만 그가 강조하는 핵심은 분명하다. 작업 도중에는 늘 새로운 정보가 들어오고, 그때마다 문제 정의와 접근 방식(그가 3~5단계라고 부르는 부분)으로 되돌아가 다시 정의하고 반복해야 한다는 것이다. 그는 이 과정을 하루에도 여러 번 돌린다고 덧붙인다.
되돌아가는 것은 실패가 아니다
중요한 것은 이 반복을 바라보는 프레임이다. 계획을 세웠다가 새 데이터 때문에 다시 뒤엎는 일은 겉보기에 "갈팡질팡(thrashy)"하는 것처럼 느껴진다. 많은 조직에서 이런 번복은 무능이나 준비 부족의 신호로 읽히고, 그래서 사람들은 초기 계획을 방어하는 데 에너지를 쓰곤 한다. 체르니의 주장은 정반대다. 새로운 데이터가 나왔을 때 방향을 조정하는 것이야말로 문제를 실제로 푸는 유일한 방법이며, 그 사실을 인지하고 있다면 이 요동침은 건강한 것이라는 얘기다. 그는 이를 "새 데이터가 있으면 사전 믿음(priors)을 갱신해야 한다"는 말로 정리한다.
이 관점은 특히 복잡한 문제에서 힘을 발휘한다. 단순한 과제라면 한 번의 계획으로 끝나겠지만, 변수가 많은 제품 문제는 여러 번의 시도를 거쳐야 제대로 잡힌다는 것을 그는 전제한다. 즉 번복의 횟수 자체가 문제의 난이도를 반영하는 것이지, 담당자의 역량 부족을 뜻하지는 않는다는 것이다. 실무자 입장에서 이는 계획을 처음부터 완벽하게 만들려는 압박에서 벗어나, 대신 조정 가능한 구조로 계획을 세우는 편이 낫다는 시사점을 준다.
가장 흔한 실패는 '문제를 흐릿하게 두는 것'
체르니가 팀에 피드백을 줄 때 가장 자주 지적하는 두 가지 실패 유형은 구체적이다. 하나는 문제를 명확하게 정의하지 못하는 것이고, 다른 하나는 접근 방식을 분명하고 단순하게 세우지 못하는 것이다. 이 둘 중 하나라도 빠지면 계획은 복잡해지고 성공 기준은 모호해진다. 많은 팀이 겪는 "열심히 일했는데 무엇을 달성했는지 말하기 어려운" 상태가 바로 여기서 나온다.
특히 그는 이 불명확함이 복잡한 문제에서는 계획을 만든 당사자에게 잘 보이지 않는다는 점을 경고한다. 자기 계획의 흐릿한 부분은 스스로 발견하기 어렵기 때문에, 다른 사람의 피드백을 받는 일이 더욱 중요해진다는 것이다. 그가 실시간 피드백을 강조하고, 자신도 같은 피드백을 되돌려 받기를 기대한다고 밝힌 이유가 여기에 있다. 피드백을 즉시 주고받아야 개인과 팀이 더 빨리 배울 수 있다는 판단이다.
실무에 옮길 때의 한계
다만 이 메모를 그대로 조직에 이식하려 할 때 짚어둘 점도 있다. 원문은 여섯 단계의 세부 내용을 완결된 형태로 제시하지 않고, 저자 개인의 작업 습관을 압축한 노트에 가깝다. 따라서 이것을 정형화된 방법론으로 받아들이기보다, 문제 정의와 단순한 접근을 반복적으로 갱신한다는 원칙으로 이해하는 편이 정확하다. 또한 잦은 방향 전환이 건강하려면, 체르니가 전제하듯 구성원 전원이 "이것은 과정의 일부"라는 공감대를 공유해야 한다. 그 합의가 없으면 같은 번복이 신뢰를 갉아먹는 신호로 오독될 수 있다.
체르니는 이 메타 프로세스 자체가 틀렸다면 그것도 바꿀 용의가 있다고 말하며 글을 맺는다. 결국 그가 말하는 '틀림에 대한 사랑'은 겸손의 수사가 아니라, 문제를 더 선명하게 정의하고 더 빨리 배우기 위한 실용적 도구다. AI가 개발 주기를 압축하고 가설 검증 비용을 낮추는 환경에서, 초기 판단을 얼마나 빠르고 담담하게 갱신하느냐가 제품의 방향을 가른다는 점에서 곱씹어볼 만한 태도다.