아이디어를 쏘아 맞히는 건 실력이 아닙니다 — 개발팀 회의 문화에 대한 이야기

회의실에서 가장 빛나는 사람은 누구인가요?

팀 회의 시간에 누군가 새로운 아이디어를 꺼내면, 곧바로 "그건 안 될 거야"라고 말하는 사람이 꼭 한 명쯤 있지 않나요? 재밌는 건, 그런 사람이 종종 '분석력이 뛰어나다'거나 '현실적인 사람'이라는 평가를 받는다는 거예요. 소프트웨어 엔지니어 Scott Lawson이 쓴 글 "Shooting down ideas is not a skill"은 바로 이 현상을 정면으로 다루고 있어요. 아이디어를 비판하는 건 쉽지만, 그게 진짜 능력일까? 라는 질문을 던지는 거죠.

비판은 쉽고, 창조는 어렵다

이 글의 핵심 주장은 명쾌해요. 아이디어를 부수는 것과 아이디어를 만드는 것은 전혀 다른 난이도의 일이라는 거예요. 이게 뭐냐면, 누군가 "이런 식으로 아키텍처를 바꿔보면 어떨까요?"라고 제안했을 때 "그건 스케일링 문제가 있을 거야"라고 지적하는 건 솔직히 몇 초면 돼요. 하지만 그 스케일링 문제까지 고려한 대안을 내놓는 건 몇 시간, 며칠이 걸리는 작업이거든요.

문제는 조직 안에서 이 두 가지가 비슷한 무게로 취급된다는 거예요. 오히려 아이디어를 빠르게 격추하는 사람이 "날카롭다"는 인상을 주기 때문에, 회의실에서의 존재감이 더 커지는 역설이 생기죠. Scott은 이걸 "비대칭 인정(asymmetric credit)" 문제라고 불러요. 부수는 쪽은 즉각적으로 보상을 받고, 만드는 쪽은 실패 리스크까지 짊어져야 하니까요.

비판 중독이 팀에 미치는 영향

이런 문화가 자리 잡으면 팀에 어떤 일이 벌어질까요? 가장 먼저 일어나는 건 "자기 검열"이에요. 사람들이 아이디어를 꺼내기 전에 "이거 말하면 또 깎이겠지"라고 생각하게 되는 거예요. 그러면 회의 시간에 진짜 혁신적인 아이디어는 절대 테이블 위에 올라오지 않아요. 안전한 것, 이미 검증된 것만 이야기하게 되죠.

개발팀에서 이게 특히 치명적인 이유가 있어요. 소프트웨어 개발은 본질적으로 불확실성을 다루는 일이거든요. 새로운 기술 도입, 아키텍처 변경, 리팩토링 범위 결정 — 이런 판단들은 "해봐야 아는" 영역이 많아요. 그런데 아이디어를 쏘아 맞히는 문화에서는 "해봐야 아는 것"을 제안하는 것 자체가 리스크가 돼요. 결과적으로 팀은 현상 유지에 갇히게 되고요.

Scott이 지적하는 또 하나의 포인트가 있어요. 비판이 구체적이지 않은 경우가 많다는 거예요. "그건 복잡해질 거야", "유지보수가 힘들 거야" 같은 말은 사실 거의 모든 아이디어에 적용할 수 있는 범용 비판이에요. 진짜 도움이 되는 피드백은 "이 부분에서 이런 구체적인 문제가 생길 수 있고, 이렇게 하면 해결할 수 있을 것 같다"처럼 대안을 포함한 건데, 그건 훨씬 더 많은 노력이 필요하죠.

건설적 비판과 파괴적 비판의 차이

그렇다고 모든 비판이 나쁘다는 얘기는 아니에요. 코드 리뷰에서 버그를 지적하거나, 설계에서 보안 취약점을 찾아내는 건 당연히 중요한 일이죠. Scott이 구분하는 건 "건설적 비판"과 "지위 과시를 위한 비판"이에요.

건설적 비판은 아이디어를 더 좋게 만들려는 의도에서 출발해요. "이 접근 방식은 동시성 문제가 있을 수 있는데, 락 대신 메시지 큐를 쓰면 어떨까?" 같은 식이죠. 반면, 파괴적 비판은 그냥 "그건 안 돼"에서 끝나요. 대안도 없고, 아이디어를 발전시키려는 의도도 없어요. 말한 사람이 똑똑해 보이는 효과만 있을 뿐이죠.

실제로 구글의 초기 문화나 픽사의 "브레인트러스트" 회의 같은 사례를 보면, 혁신적인 조직일수록 아이디어의 초기 단계에서는 비판보다 확장을 먼저 시도해요. "Yes, and..." 접근 방식이라고 하는 건데, 아이디어를 일단 받아들이고 거기에 무언가를 더하는 거예요.

한국 개발 문화에서 더 와닿는 이야기

솔직히 말하면, 이 글이 한국 개발자들에게 특히 와닿을 수 있다고 생각해요. 한국 직장 문화에서는 연차나 직급이 발언의 무게에 영향을 주는 경우가 많잖아요. 시니어 개발자가 "그건 안 돼"라고 하면, 주니어 입장에서는 반박하기가 정말 어렵거든요. 그러다 보면 주니어들의 신선한 시각이나 다른 관점이 묻히는 경우가 생겨요.

코드 리뷰 문화에서도 비슷한 패턴을 볼 수 있어요. 리뷰가 "이건 왜 이렇게 했어?"라는 질문 형식의 공격이 되는 경우와, "이 부분은 이렇게 바꾸면 이런 장점이 있을 것 같아"라는 제안이 되는 경우는 천지 차이잖아요.

팀 리드나 시니어 역할을 하고 계신 분이라면, 자신이 혹시 "아이디어 저격수" 역할을 하고 있지는 않은지 한번 돌아볼 필요가 있어요. 그리고 팀 전체적으로도, 아이디어를 꺼내는 것이 심리적으로 안전한 환경인지 점검해보면 좋겠어요.