34  램프셰이딩

“묻는 사람은 5분 동안 바보이지만, 묻지 않는 사람은 영원히 바보로 남습니다.” - 작자 미상

우리는 흔히 아는 것이 힘이라는 말을 듣습니다. 대체로 맞는 말입니다. 하지만 모르는 것도 힘이 될 수 있습니다. 경력에서 지식의 부족을 일종의 힘으로 휘두를 수 있는 단계가 적어도 두 번은 있다고 생각합니다(여기서 힘이란 남을 지배한다는 옹졸한 의미가 아니라, 필요한 일을 하도록 다른 사람에게 영향을 미치는 능력이라는 중립적인 의미입니다).

이 장에서는 램프셰이딩으로 남은 경력 내내 무지를 무기로 휘두르는 방법을 이야기하겠습니다!

34.1 아주 높은 직급에 올랐을 때

첫째, 일반적으로 개인 기여자로부터 적어도 두어 단계 떨어져 있는 고위 경영진에 속해 있을 때입니다. 일정 수준을 넘어서면 여러분은 정답을 알고 있으라고 급여를 받는 것이 아닙니다. 그것은 여러분의 직속 부하 직원들이 할 일입니다. 올바른 질문을 던지고, 팀이 그 답을 얻는 방법을 알아낼 수 있도록 돕는 것이 여러분의 일입니다.

지금까지 경력을 쌓으며 제가 자주 목격한 바로는, 중간 관리자나 주니어가 아니라 고위 경영진이야말로 “잠깐, 잠깐, 잠깐만요. 지금 무슨 일이 벌어지고 있는지 이해가 안 됩니다. 다섯 살짜리한테 설명하듯 말해 줄 수 있습니까?”라고 말할 가능성이 가장 높습니다.

제대로 하면 이는 허술한 논리를 드러내고 헛소리를 깨부술 수 있으며, 특히 “쉽게 설명할 수 없다면 충분히 이해하지 못한 것이다”라는 (대체로 옳은) 믿음과 함께 제시될 때 더욱 그렇습니다.

참고: 무능한 경영진이 효과적인 리더가 되는 데 필요한 도메인 지식을 갖추지 않아도 된다고 면죄부를 주려는 것은 아닙니다. 저는 단지 시니어 레벨에서는 모든 것을 알고 있으리라고 기대받지 않는다는 점, 그리고 그것이 “아는 것이 힘이다”에 대한 흥미로운 예외라는 점을 지적하는 것뿐입니다.

34.2 처음 시작할 때

둘째, 새로 들어왔을 때입니다. 보통 경력을 막 시작한 신입이거나 커뮤니티 또는 회사에 새로 합류한 사람이 이에 해당합니다. 이 단계에서도 역시 여러분이 무엇이든 알고 있으리라 기대하는 사람은 아무도 없습니다. 물론 누군가를 속여 여러분을 채용하게 만들 만큼은 알아야 했을 것입니다. 하지만 거짓말을 하거나 알면서 말하지 않는 식으로 속이지만 않았다면, 지식에 빈틈이 있다는 이유로 태도를 바꿔 여러분을 해고할 사람은 없습니다.

물론 이것이 적용되지 않는 경우도 있습니다. 주니어 인력은 가장 쉽게 대체되는 존재이고, 어떤 회사는 멘토링과 채용에 대해 건강한 태도를 갖고 있지 않습니다. 하지만 일반적으로 저는 테크 업계가 이를테면 금융 업계보다 멘토링 면에서 훨씬 낫다고 생각합니다. 테크 기업은 보통 시니어나 팀 리드에게 주니어를 멘토링할 명시적인 책임을 부여하며, 특히 커리어 래더(장 26)의 일부로 그렇게 합니다.

세는 방식에 따라 2~4번 경력을 새로 시작한 저이니, 완전한 초보가 되어 본 경험이 꽤 많으리라고 짐작하실 수도 있습니다.

34.3 이야기 시간입니다!

여기서는 부트캠프를 막 마치고 새 개발자 일자리에 출근한 첫날에 대해 이야기해 드리겠습니다.

저희 팀원은 모두 같은 날 입사했습니다. 신입 세 명이었습니다(저와 경력이 더 많은 개발자 두 명). 새 상사는 회사에서 오래 근무한 자신감 넘치는 시니어 개발자였는데, 저희에게 기술 스택을 차근차근 설명해 주고 있었습니다. 그러다 갑자기 말을 멈추더니 이렇게 말했습니다. “아, 그런데 우리는 TypeScript를 쓸 겁니다. 다들 TypeScript 아시죠?” 동료 1이 고개를 끄덕였고, 동료 2도 고개를 끄덕였습니다. 당연하죠, 우리 다 프로인데, 당연히 TypeScript 쓰죠라는 무언의 분위기가 흘렀습니다.

그러자 모든 시선이 저에게 쏠렸습니다.

저는 또래 압력에 약합니다. Gretchen Rubin의 네 가지 성향(Four Tendencies) 모델에 따르면 저는 ’의무형(Obliger)’입니다. 저는 다른 사람을 기쁘게 하는 것을 좋아하고 제 걱정은 뒤로 미뤄 둡니다. 물론 제가 다닌 부트캠프에서는 TypeScript를 가르치지 않았습니다. 풀스택 JS를 배우는 데 주어진 시간이 겨우 세 달뿐이었으니까요! 그리고 물론 저는 그렇다고 대답하고 싶었습니다!

저는 아마 겉으로도 드러났을 법한 당황의 순간을 겪은 뒤, “아니요, 저는 TypeScript를 모릅니다.”라고 답했습니다. 상사는 그저 고개를 끄덕이며 “일하면서 배우면 됩니다”라고 말하고는 다음 이야기로 넘어갔습니다.

처음 몇 달 동안 그런 작은 시험을 아마 열두 번쯤은 치렀던 것 같습니다. 전문적인 코드 리뷰를 할 줄 알았을까요? (몰랐습니다) BEM 네이밍을 할 줄 알았을까요? (몰랐고, 자랑스럽게도 지금도 모릅니다) Clean Code가 무엇인지 알았을까요? (음.. 몰랐습니다).

제가 모른다고 고백할 때마다 그들은 제가 배워야 할 것을 알려 주었고, 저는 따라잡을 수 있었습니다. 제가 실수를 하면, 그들은 제가 무엇을 잘못했는지 가르쳐 주었습니다. 그렇다고 그들이 어쩌겠습니까, 저를 해고하겠습니까? 그들은 부트캠프를 갓 마친 저를 채용할 때 이미 무엇을 감수하는지 알고 있었습니다.

제가 모른다는 사실을 선뜻 인정한다는 것을 보여 준 덕분에, 제가 무언가를 안다고 말할 때의 신뢰도도 높아졌습니다. 모른다고 털어놓는 데 아무 거리낌이 없다는 것을 이미 보여 주었기 때문입니다. 이로 인해 팀 내 신뢰가 높아졌습니다.

34.4 램프셰이딩

이처럼 무지를 고백하는 것은 경력의 시니어 단계와 주니어 단계 모두에서 효과가 있음을 알 수 있습니다. 하지만 이는 개별적인 상황에서도 효과가 있습니다. 예를 들어 공개적으로 배우기를 하면서 자신이 모르는 부분에 대해 단서를 달아 둘 때가 그렇습니다.

창작 글쓰기에 가볍게 관심을 두고 있다 보니, 저는 이 기법을 램프셰이딩과 자주 비교합니다. TV Tropes의 내용을 인용하면 다음과 같습니다.

램프셰이드 걸기(Lampshade Hanging, 좀 더 비공식적으로는 램프셰이딩)는 매우 개연성 없는 플롯 전개든 특히 노골적인 트로프 사용이든, 관객의 ’자발적인 불신의 유예’를 위협하는 이야기 속 요소를 그 요소에 주의를 환기한 뒤 그냥 넘어가는 방식으로 처리하는 작가들의 기법입니다.

실생활에 적용하면 이렇습니다: 다른 사람이 지적하기 전에 자신의 약점을 스스로 먼저 드러내는 것입니다.

사실, 제대로 돌아가는 팀이라면 대부분 그 뒤에는 다른 사람들이 여러분의 약점을 고치도록 도와야 하는 입장이 됩니다. 이것이 바로 소프트 파워입니다.

(특정 연령대의) 많은 미국인은 이를 8 마일의 마지막 배틀과 연결 지으며 곧바로 공감합니다. 영화에서 에미넴은 상대인 파파 닥이 지적하려던 자신의 약점을 하나도 빠짐없이 먼저 늘어놓으며 시작하는데, 말 그대로 파파 닥의 입에서 나올 말을 모조리 가로채고 자신을 공감 가는 인물로 만들어 버립니다. 여기서 약점이 곧 강점이 되는 것은 순전히 램프셰이딩 덕분입니다.

34.5 멍청한 질문 면책 조항

실생활에서 저는 “멍청한 질문 면책 조항(Stupid Question Safe Harbor)”(SQSH)을 꺼내 들며 미리 짚고 넘어가는 경우가 많습니다.

“세이프 하버(Safe Harbor)”란 규칙이 불명확하여 회색 지대에 놓일 수 있는 특정 행위를 명시적으로 허용하는 법적 개념입니다. 그래서 저는 누군가 “멍청한 질문이 하나 있습니다”라고 말할 때 우리가 어떻게 행동하는지를 설명하는 비유로 이 개념을 사용합니다.

우리가 “멍청한 질문 면책 조항(Stupid Question Safe Harbor)”을 꺼낼 때, 우리는 그 질문이 멍청할 수도 있다는 점을 인정하는 것이며, 동시에(AND) 사실 멍청한 질문이란 없다는 것을 모두가 알고 있다는 점도 인정하는 것입니다. 그래도 정말 기초적인 것을 묻기 위해 일단 이렇게 짚고 넘어가는 것입니다. 체면을 지키는 것보다 서로를 이해하는 것이 더 중요하기 때문입니다.

여기서 요령은 실제로 체면을 지키고 있다는 점입니다. 이제 SQSH를 꺼냈으니, 사람들은 여러분이 역할극을 하고 있다는 것을 이해하고, 여러분은 잘 알려진 대화 방식을 명시적으로 꺼내 들고 있는 것이며, 여러분이 정말로 그렇게 멍청한 것은 아닙니다. 그렇지 않습니까? 그렇지 않습니까?? 긴장한 웃음

여러 사람이 함께 있는 상황에서는 SQSH가 긍정적 외부 효과를 냅니다. 같은 것을 궁금해하는 사람이 여럿일 수 있지만, “바보 같은 질문”을 하는 “부담”은 한 사람만 지면 되고, 그런데도 모두가 이득을 봅니다. 저는 이 서비스형 바보 같은 질문(Stupid Questions as a Service) 역할을 즐겨 맡습니다.

34.6 고급 램프셰이딩

램프셰이딩을 알아보는 눈이 생기면, 현실에서 이를 강력하게 활용하여 공개적으로 배우는 사람들을 발견하게 될 것입니다: