누가 이런 글을 썼나
Anthropic에서 Claude Code를 만든 보리스 체르니(Boris Cherny)가 자기 블로그에 '나는 자주 틀린다(I am often wrong)'라는 제목의 글을 올렸어요. 카테고리가 관리(management)와 제품(product)이에요. 그러니까 코드 얘기가 아니라, 팀을 이끌고 제품 방향을 정하는 사람으로서의 이야기라는 거죠.
이 사람이 누구냐면, 오라일리에서 나온 'Programming TypeScript' 책의 저자이고, Meta에서 일하다가 Anthropic으로 옮겨서 2025년 2월에 Claude Code를 세상에 내놓은 사람이에요. 터미널에서 돌아가는 AI 코딩 에이전트라는, 당시엔 꽤 낯선 형태의 제품이었는데 지금은 개발자들의 작업 방식을 바꿔놓은 도구가 됐죠. 그런 제품을 만든 사람이 스스로 자주 틀린다고 말하는 건 생각보다 큰 의미가 있어요. 글의 세부 논지와 구체적인 사례는 원문을 꼭 읽어보시고요, 여기서는 이 제목이 던지는 화두를 개발자 관점에서 풀어볼게요.
왜 '틀림'이 리더의 기본값인가
제품을 만드는 사람은 매일 결정을 내려요. 이 기능을 넣을지 말지, 이 UI가 맞는지, 이번 분기에 뭘 우선할지. 그런데 이 결정들은 대부분 정보가 부족한 상태에서 내려져요. 사용자가 뭘 원하는지 완전히 알 수 없고, 경쟁사가 뭘 내놓을지도 모르고, 기술이 어디로 갈지는 더더욱 모르죠. 그러니까 확률적으로 틀리는 게 당연해요. 열 번 결정하면 서너 번은 틀리는 게 정상이고, AI처럼 몇 달 단위로 판이 바뀌는 분야라면 그 비율은 더 올라가요.
문제는 많은 조직이 이걸 인정하지 않는다는 거예요. 리더가 틀리면 안 된다는 압박이 있으면 두 가지 일이 생겨요. 첫째, 리더가 결정을 미뤄요. 확신이 설 때까지 기다리다가 타이밍을 놓치죠. 둘째, 틀린 결정을 내렸을 때 인정을 안 해요. 이미 방향이 잘못됐다는 신호가 보이는데도 밀고 나가요. 자존심 때문에, 혹은 조직 분위기 때문에요. 이 두 번째가 훨씬 비싸요. 틀린 결정 자체보다 틀린 걸 알고도 안 고치는 기간이 조직을 갉아먹거든요.
틀림을 다루는 프레임워크들
이 주제를 다룬 고전적인 프레임이 몇 개 있어요. 제프 베이조스의 '양방향 문' 개념이 대표적이에요. 이게 뭐냐면, 결정을 두 종류로 나누는 거예요. 되돌릴 수 있는 결정은 양방향 문이라 빨리 통과하고, 아니면 다시 돌아오면 돼요. 되돌리기 어려운 결정은 일방향 문이라 신중해야 하고요. 핵심은 대부분의 결정이 양방향 문인데도 사람들이 일방향 문처럼 다루느라 느려진다는 거예요.
'강한 의견, 약한 고집(strong opinions, weakly held)'이라는 말도 자주 인용돼요. 결정할 땐 명확하게 방향을 잡되, 반대 근거가 나오면 미련 없이 바꾸라는 뜻이에요. 그리고 이게 작동하려면 팀원들이 리더에게 '그거 틀린 것 같은데요'라고 말할 수 있어야 해요. 구글이 팀 생산성을 연구한 프로젝트 아리스토텔레스에서 가장 중요한 요소로 꼽은 게 심리적 안전감이었는데, 결국 같은 얘기예요. 리더가 먼저 '나 자주 틀려'라고 선언하는 건 이 안전감을 만드는 가장 빠른 방법이기도 해요.
AI 시대에 이 얘기가 더 중요해진 이유
여기서 재밌는 게, AI 코딩 도구가 이 계산을 바꿔놓고 있다는 거예요. 예전엔 기능 하나 만들어보는 데 몇 주가 걸렸어요. 그러니까 틀린 결정의 비용이 컸고, 결정 전에 오래 고민하는 게 합리적이었죠. 그런데 지금은 프로토타입을 몇 시간 만에 만들 수 있어요. 그러면 고민하는 시간보다 그냥 만들어서 써보는 게 더 싸요. 틀리는 비용이 낮아지니까 '빨리 틀리고 빨리 고치는' 전략이 훨씬 유리해지는 거예요.
Claude Code 팀 자체가 이런 방식으로 일한다고 알려져 있어요. 체르니는 Claude Code 코드의 대부분을 Claude Code 자신이 작성한다고 공개적으로 말한 적이 있고, 기능을 빠르게 넣었다가 반응이 없으면 빠르게 빼는 식으로 운영한다고 해요. 그러니까 '나는 자주 틀린다'는 겸손의 표현이라기보다, 이 속도로 움직이려면 틀리는 걸 시스템의 일부로 받아들여야 한다는 현실적인 선언에 가깝게 읽혀요.
한국 개발자에게는
솔직히 한국 조직 문화에서 이게 쉽지 않다는 건 다들 아실 거예요. 회의에서 윗사람 의견이 곧 결론이 되고, 그게 틀렸다는 게 나중에 드러나도 아무도 말을 안 꺼내는 경우가 많죠. 그런데 이제 실험 비용이 이렇게 낮아진 시대에 그런 문화를 유지하면 조직 전체가 느려져요. 팀장이라면 이번 주 회의에서 한 번쯤 '내가 지난번에 정한 거, 지금 보니 틀린 것 같아'라고 말해보세요. 그 한마디가 팀의 속도를 바꿔요. 주니어라면 리더가 틀린 걸 지적하는 게 무례가 아니라 기여라는 걸 기억하세요. 물론 근거를 갖고, 대안과 함께요.
그리고 개인 차원에서도 적용돼요. 자기 결정에 얼마나 확신이 있었고 실제로 얼마나 맞았는지 기록해 보는 것, 이걸 '캘리브레이션'이라고 하는데, 몇 달만 해보면 자기가 어떤 종류의 결정에서 자주 틀리는지 패턴이 보여요. 기술 선택에서는 잘 맞는데 일정 추정에서는 늘 낙관적이라든가 하는 식으로요. 그 패턴을 알면 다음 결정에서 어디에 더 신중해야 하는지가 보이죠.
정리하며
틀리는 건 피할 수 없고, 중요한 건 얼마나 빨리 알아차리고 얼마나 싸게 되돌리느냐다. 이게 오늘의 한 줄이에요.
여러분 팀은 어떠세요? 리더가 자기 결정을 뒤집었을 때 '역시 믿을 만하다'는 반응이 나오나요, 아니면 '또 바뀌었네'라는 피로감이 나오나요? 그 차이는 어디서 오는 걸까요?
🔗 출처: Hacker News