프로그래밍 언어를 둘러싼 논쟁이 왜 격해지는지, 경험의 주관성과 공감의 역할을 통해 살펴보고 서로 다른 가치와 사고방식을 존중하는 대화법을 제안한다.
프로그래머에 대한 고정관념 가운데 하나는 그들이 흑백논리를 좋아한다는 것이다. 프로그래머는 무언가가 좋거나 나쁘거나, 도덕적이거나 비도덕적이거나, 책임감 있거나 무책임하길 바란다는 말이다. 어쩌면 프로그래머는 자신이 프로그래밍하는 컴퓨터만큼 이진적이길 좋아한다는 생각이 낭만적으로 들릴지도 모른다. 환원주의적이냐고? 거의 틀림없다. 그래도 스스로를 조금 비웃어 보자. 우리, 가끔은 놀림감이 되어도 싸니까.
개인적으로, ‘뉘앙스를 못 알아차리는 프로그래머’라는 클리셰가 사실인지 모르겠다. 다만 그게 프로그래머의 속성이건, 키보드 뒤에 있는 인간의 속성이건 간에, 우리가 서로에게 동의하지 않는 강도는 늘 놀랍다. 현업 프로그래머 아무 무리에게나 가장 싫어하는 프로그래밍 언어가 무엇인지 물어보라. 큰 확률로, 분위기는 금방 뜨거워진다. 왜일까? 똑같은 일을 하면서도 수만, 수십만의 다른 사람들과 경험이 배치될 때조차, 왜 우리는 우리가 옳고 남이 틀렸다고 강하게 느끼게 만드는 게 프로그래밍에는 있는 걸까?
나는 그 질문을 자주 생각한다.
인간은 사소한 것에 유난히 집착하는 재주가 있다. 고양이 대 개, 넥타이를 매는 올바른 방법, 심지어 한 주의 시작이 무슨 요일인지 같은 거의 모든 것에 대해—어딘가 인터넷 포럼에는 누군가가 에세이를 써놨을 가능성이 높다. 동료들을 이해하려는 시도를 포기하고 손을 들어 버리는 건 쉬운 일이다. 때때로 그들은 다른 행성에서 온 외계인처럼 보이니까.
하지만 내가 흥미롭게 느끼는 것은, 아주 작은 것들이 사람들을 가장 화나게 만든다는 점이다. 양자역학의 최선의 해석을 두고 소리를 지르며 싸우는 사람은 거의 없지만, 누군가가 자신은 그냥 _스타워즈_에 별로 관심이 없다고 말하는 순간, 우정이 시험대에 오른다. 이 현상을 설명하는 단순한 이유는 ‘접근성’일 수 있다. 대부분의 사람은 양자역학을 이해하고 논쟁할 수 있을 만큼 준비되어 있지 않지만, 화장지의 종이가 어느 방향으로 나와야 하는지에 대해서는 거의 누구나 의견을 낼 수 있다.1
그 설명에 일리는 있지만, 개인적으로는 그게 전부라고 생각하지 않는다. 우리는 자신의 경험이 보편적이라는 생각에 너무 익숙해져 있어서, 똑같은 일을 겪고도 전혀 다른 결론에 이른 사람이 있다는 사실을 알게 되면, 그건 단지 좌절감을 넘어 아예 이해 불가능하게 느껴진다고 생각한다.
2015년의 현상인 “그 드레스”를 예로 들어 보자. 어떤 사람은 검정과 파랑을 보고, 어떤 사람은 흰색과 금색을 본다. 그리고 솔직히 말해, 무엇으로 보느냐는 조금도 의미 있는 것에 영향을 주지 않는다. 이렇게 완전히 무관한 것이 어떻게 주요 언론사들이 보도할 정도의 범문화적 현상이 되었을까? 내 추측은 이렇다. 사람들은 시각—우리가 세상을 감지하는 주된 방식—이 객관적이고 보편적인 현실 이해를 제공하지 않는다는 사실에 익숙하지 않다.
우리의 문화와 사회가 작동하는 이유는, 차이가 있음에도 불구하고 우리는 모두 인간이기 때문이다. 우리는 먹고, 자고, 서로와 시간을 보내는 것을 좋아하며, 주변 사람들과 연결되어 있음을 좋아한다. 그래서 어떤 영화를 보고 기분이 좋아지는 어떤 지점을 건드렸을 때, 거의 모든 면에서 의견이 맞는 절친이 그 영화를 전혀 좋아하지 않았다는 사실을 이해하기가 몹시 어렵다.
물론 진실은, 우리가 경험하는 것 중 객관적인 것은 거의 없다는 것이다. 네, 기본 산수가 우주의 어디에서나 참이라는 점에는 꽤 자신할 수 있고, 모두가 어떤 탁자가 갈색이라고 동의한다면 아마 그럴 것이다. 사람마다 좋아하는 음식이나 매력적이라고 느끼는 패션 같은 것들이 주관적이라는 사실은 두 번 생각하지 않아도 받아들인다. 문제는 그 사이사이, 미묘한 것들이다! “그 드레스”가 대부분의 사람에게 믿기지 않았던 이유는, 천 번 중 아홉백아흔아홉 번은 두 사람이 같은 사진을 볼 때 그 안에 들어 있는 색에 대해 적어도 대부분은 동의하기 때문이다. 우리는 같은 객관적 현실을 다른 렌즈로 보고 있다고 생각하지 않는다. 그냥 객관적 진리를 직접 지각하고 있다고 여긴다.
드레스의 경우, 당신이 “얀니(yanny)”로 들었는지 “로럴(laurel)”로 들었는지, 또는 소닉 게임이 그동안 한 번이라도 정말 좋았다고 믿는지 여부 같은 주관적 불일치는 본질적으로 무해하다. 하지만 그렇지 않을 때는 어떨까? 우리의 경험이 보편적이라는 잘못된 믿음이 실제로 해를 끼칠 수 있을까?
나는 답이 절대적으로, 명백하게 그렇다 고 생각한다.
간단한 질문: 함수형과 명령형 프로그래밍 중 어느 쪽이 더 나은가?
내 블로그의 평소 주제를 보면, 독자 대부분은 전자를 고를 것 같다. 하지만 실제로 어떤 답을 골랐는지는 중요하지 않다. 아마 당신은 그 선택을 뒷받침할 꽤 이성적인 논거가 있다고 느낄 것이다. 그게 단순한 취향 문제는 아니잖아… 그렇지?
음, 아니, 그러지 않기를 바란다. 세상이 너무 주관적이어서 어느 것을 옹호할 수조차 없는 건 아니라고 생각한다—한동안 “모든 것이 XML”이라는 걸 시도해 봤고, 그게 정말 좋은 생각이 아니었다는 데 동의했잖는가. 하지만 위 질문에 대한 당신의 답이 완전히 객관적으로 정당화될 수 있다고 진심으로 믿는다면(그런 사람은 많다), 하스켈에 관한 거의 모든 글의 일반적인 Hacker News 댓글 스레드는 어떻게 설명할 것인가?
나는 가능하면 Hacker News를 읽지 않으려 한다. 읽으면 대체로 화만 나기 때문이다,2 하지만 최근 하스켈을 프로덕션에서 사용하는 것에 대한 블로그 글을 두고 나온 토론에 대한 링크를 우연히 보게 되었다. 몇 가지 댓글을 살펴보자.
한 토론 가지에서 어떤 사용자가 이렇게 쓴다:
Haskell is great for business and great in production
동의하지 않는다. 아름다운 언어이긴 하지만, 대규모로 사용하기에 필요한 많은 기능이 부족하다. 내 경험상 하스켈 엔지니어들은 매우 똑똑하지만, 그들이 만드는 환경/문화는 팀워크를 기르기 어렵게 만든다.
지난 4년 동안 프로덕션에서 처음에는 하스켈을 사용했던 두 회사에 있었다. 한 곳은 Go로 전환했고 다른 한 곳은 코드를 Rust로 다시 쓰고 있다.
첫 문단은 구체성이 부족한 단정이긴 하지만, 그럴듯하게 들리기도 한다. 마지막 두 문장은 전적으로 일화지만, 일화도 직감보다는 낫다. 다른 사람의 응답을 보자:
나는 하스켈로 시작한 꽤 훌륭한 엔지니어들을 만난 적이 있다. 그들은 다른 언어에서 주니어 레벨일 때조차 그 언어의 시니어 엔지니어보다 훨씬 쉽게 우아한 해법을 낸다. 그 코드를 그대로 프로덕션에 넣지는 않겠지만, 무슨 일이 일어나고 있는지는 아주 쉽게 보이고, 대규모 OOP의 가장 큰 결점이라고 생각하는 초기 추상화의 망령에 시달리지 않는다.
[…]
내 순진한 관점에서 보면, 무엇이든 클래스로 만들고, 상태를 들고 여기저기 부작용을 넣는 건 쉽다. 하지만 모나드의 번거로움은 필요할 때까지 마주하고 싶지 않다. 그래서 함수형으로 시작했다가 확장해 나가면, 자동으로 더 깔끔한 코드 쪽으로 기울게 된다.
역시 다소 모호하고 상위 수준이지만, 이 또한 그럴듯하다. 이 댓글들 중 하나를 읽고 곧바로 짜증이 치밀어 반박 논리를 머릿속으로 짜기 시작했다면, 잠시 감정에서 벗어나(그게 아무리 이성적일지라도!) 최대한 호의적으로 해석해 보길 권한다. 토론은 계속된다:
Haskell gives one plenty of rope to hang himself on complexity.
너무 많아서, 개발자들은 공포만큼 깊은 혐오를 키우게 된다. 피할 수 없다. 그 혐오를 키우지 못한 이들은 첫 번째 루브 골드버그 머신의 작동을 여전히 파헤치느라 매몰되어 있고, 연락이 닿지 않는다.
정확하다고 보든 말든 간에, 하스켈이 매우 복잡한 언어라는 인식을 가진 사람이 꽤 많다는 것은 분명하다. 그들 중 적어도 일부는 진지하게 시도해 봤을 것이다. 그럼 아직 ‘깨달음을 얻지’ 못한 것일까? 그들은 무엇을 놓치고 있을까? 아마 뒤이은 댓글이 설명을 덧붙여 줄지도 모른다:
안녕하세요, 여기서 사람들이 불평하는 모든 것(그리고 그 불평은 정당하다)이 C++에도 사실이라고 봅니다. C++의 많은 복잡성(특히 15–20년 전 템플릿 영역)은 인기가 높아진 뒤에 생겨났기에, 사람들은 이미 그것에 얽매여 있었습니다.
[…]
C++ 커뮤니티는 지난 5년 정도 사이에 나쁜 충동을 잘 억누르고, 합리적인 표현력을 유지하면서도 깔끔하고 명료하며 효율적인 코드를 쓰게 만드는 데 꽤 능숙해졌습니다.
C++에서 하스켈로 들어온 제게도 같은 본능이 있습니다. 하스켈은 순수한 즐거움이었습니다. 이점은 정말로 있고, 쉽게 얻을 수 있습니다. 다만 트레이드오프를 생각해야 합니다.
그 주장도 합리적으로 들린다. 모든 것은 적당히, 그렇지 않은가? 동의하지 않는다면, 그리고 당신이 하스켈은 그럴 가치가 없다고 생각한다면, 이 사람이 당신과 달리 무엇을 가치 있게 보는 걸까? 당신이 보는 것을 그들은 무엇을 놓치고 있을까?
내가 어디로 가고 있는지 짐작할 수 있을 것이다. 이 논쟁들은 반박 가능한 단단한 사실이나 엄격한 현실 세계의 증거에 기초하지 않고, 직감과 개인적 선호에 바탕을 둔다. 그렇다고 이게 틀렸고, 무효이며, 무가치하니, 어떤 언어가 가장 빠르고 버그가 가장 적게 기능을 출시하게 해 주는지 연구를 하고, 그걸 모두가 쓰기로 합의해야 한다는 뜻일까?
아니요!
이 대화들이 주관적인 이유는, 좋든 싫든, 인간이 서로 다른 방식으로 생각하고 서로 다른 것을 가치 있게 여기며, 프로그래밍 언어가 우리가 자신을 표현하는 매체이기 때문이다. 하스켈을 쓰는 많은 사람들에게(나를 포함해), 타입 시스템으로 문제를 모델링하는 데서—호박 속에 무언가를 가두는 것처럼—유쾌한 기쁨이 있다. 다른 이들은 전혀 개의치 않는다. 더 나아가, 어떤 사람들은 하스켈의 의미 있는 공백과 수많은 중위 연산자를 분명히 혐오하지만, 나는 별로 신경 쓰지 않는다. 우리 중 누가 틀린 걸까? 그렇다면 왜? 신뢰성 이야기야 마음껏 하라. 하지만 우리가 가진 몇 안 되는 엄밀한 수치는 어느 쪽이든 별 근거를 제공하지 못한다.
앞서 언급한 Hacker News 스레드에서 어떤 댓글러는 하스켈을 “고통과 고문” 그 자체로 묘사했지만, 또 다른 이는 “프로덕션에서 하스켈을 좀 썼는데 정말 즐거웠다”고 말한다. 사람들은 이런 차이를 설명하기 위해 끊임없이 변명과 합리화를 내놓는다—대부분의 사람은 먼저 명령형 프로그래밍에 노출된다고 지적하면, 다른 쪽은 하스켈이 아주 오래 있었음에도 그다지 널리 쓰이지 않는다고 받아친다—그러나 그 어떤 주장도 사람들의 마음을 바꾸지는 못하는 듯하다.
사람들은 종종 이런 대화를 겪고서 혼란스럽고 분개한 채로 돌아선다. 그들에게는 자신의 관점이 너무나 자명해 보이기에, 다른 사람이 다르게 본다는 걸 상상하기가 어렵다. 왜 상대가 그걸 이해하지 못하는지 머리를 싸맨다. 분명 뭔가 핵심을 오해했거나, 어떤 기쁨을 아직 맛보지 못했거나, 아직 베어 보지 않은 날카로운 모서리가 있을 것이다. 하지만 얼마나 시간을 들여 그들에게 닿으려 노력하든, 어찌 된 일인지, 결코 충분하지 않다.
이런 종류의 논의가 항상 헛수고라고는 인정하지 않겠다. 때때로 사람들의 마음을 바꾸거나, 이해하지 못했던 새로운 아이디어를 보게 만드는 데 정말로 성공하기도 한다. 사람들이 침착함을 유지하고 서로의 마음가짐 차이를 인정하면서도 배우도록 돕는다면, 모두가 이득을 본다.
안타깝게도, 내 경험상 그런 일은 드물다. 사람들은 누군가가 자신과 다르게 보면 자연스레 화가 난다. 그것은 혼란스럽고 방향 감각을 잃게 만들며, 심지어 혐오감마저 불러일으킬 수 있다. 이런 감정들은 공감에 전혀 도움이 되지 않는다. 다른 사람들이 다르게 생각할 수 있는 방식을 고려하지 못하면, 우리는 대화에서 얻을 수 있었던 통찰을 스스로 거부하는 셈이다. 왜냐하면 우리는 잠시라도 다른 누군가의 낯설고 때로는 불편한 가치와 경험을 끌어안기를 허락하지 않았기 때문이다. 우리는 우리의 색채 지각이 생각만큼 보편적이지 않을 수 있음을 받아들이기를 거부하고, 그 결과 빛, 색, 인간의 시각에 대해 배울 수 있었던 놀라운 통찰을 놓친다.
논쟁 상대에게 공감하지 못하는 것도 이미 충분히 나쁘지만, 내 생각에 자신의 관점이 주관적일 수도 있음을 받아들이지 못하는 태도는 간접적으로 더 나쁜 결과를 낳는다. 같은 스레드에서 나온 이 댓글을 보자:
너는 하스켈로 거의 프로그래밍을 해 보지 않았고, 뭘 말하는지 모르는 것처럼 들린다. 하스켈은 내가 처음 배운 언어였다. 나는 전혀 그렇게 생각하지 않았고, 지금도 그렇다. 자바 같은 걸 배우는 것보다 더 어렵다고는 느껴지지 않는다.
이 댓글러가 진심으로 한 말이라 의심하지 않는다. 그들에게는 하스켈이 어렵지 않았던 것이다. 그들이 답글을 단 댓글은 독설적이고 공격적이었기에, 한소리 들을 법도 했을지 모른다… 하지만 이건 사적인 대화가 아니다. 하스켈을 배우고 있는 누군가가 이 스레드를 읽다가, 하스켈이 쉬워야 한다고 말하는 댓글을 보면 어떤 기분이 들까? 그들이 조금이라도 어려움을 겪고 있었다면, 무슨 생각을 하게 될까?
내가 그 입장이었다면, 조금 멍청하다고 느꼈을지도 모른다. 내가 정말 하스켈에 어울리는지, 그냥 포기해야 하는지 고민했을 것이다. 계속 시도해 보겠다는 격려나 기대감은 확실히 느끼지 못했을 것이다.
왜 이 댓글러에게 하스켈이 수월했는지는 모른다. 이미 어떤 개념에 노출되어 있었을 수도 있고, 그들의 사고방식에 잘 맞았을 수도 있고, 어쩌면 아주 뛰어났을 수도 있다. 모르겠다. 하지만 어떤 이유든, 이런 방식으로—비록 간접적이더라도—다른 사람의 지능을 모욕하는 것은 좌절 앞에서 공감이 부족하다는 증거이고, 의도는 상처를 주려는 것이 아니었을지라도 여전히 심각한 해를 끼칠 수 있다.
분명히 하자. 나는 댓글러가 자신의 경험이 달랐던 척하라거나, 아예 말을 아꼈어야 한다고 말하는 게 아니다. ‘가짜 친절’을 믿지 않는다—내 경험상, 나는 진심에서 우러나온 말로 이야기할 때 사람들에게 가장 잘 닿는다. 내가 했을 법한 것은 내 이야기를 다른 방식으로 전하는 것이다. 이를테면 이렇게 썼을 것이다:
많은 사람이 하스켈을 어렵다고 느끼는 것은 사실이고, 어떤 사람은 그럴 가치가 없다고 여기는 것도 충분히 이해합니다. 당신이 하스켈을 쓰고 싶지 않다면 그건 괜찮습니다. 하지만 개인적으로 저는 하스켈을 정말 즐겨 쓰고, 제 동료들도 그렇습니다. 우리가 하스켈로 훌륭한 소프트웨어를 낸다고 생각하는데, 그건 하스켈이 우리가 프로그램 구축에 대해 생각하는 방식과 자연스럽게—심지어 기쁘게!—맞닿아 있기 때문입니다.
저는 개인적으로 다른 분들만큼 하스켈을 배우는 게 어렵지는 않았지만, 그래도 노력은 필요했고, 어떤 면에서는 때가 맞았던 것 같습니다. 제 주변에는 처음에 꽤 고생했던 분들도 많고, 그럴 만하다고 생각합니다. 그래도 그분들은 훌륭한 하스켈 프로그래머가 되었고, 그 과정이 가치 있었다고 말합니다. 우리 팀의 다이내믹은 다른 언어였다면 지금과 같지 않았을 것입니다.
나는 동의하지 않는 댓글에 답할 때, 상대의 경험을 무효화하지 않으면서 다른 관점을 보여 주는 개인적 이야기를 하려고 한다. 결과가 고마움 대신 빈정거림으로 돌아오거나(혹은 아무 반응이 없거나) 할 때도 있지만, 공격적이지도 과하게 방어적이지도 않게 자신의 자신의 경험을 감정의 언어로 이야기하는 것이 꽤 먼 길을 가게 해 주는 일임에 놀랄지도 모른다. 그들이 호응해 주어 무엇이 답답한지—근본적이고 주관적인 이견을 넘어—설명해 준다면, 당신도 뭔가를 배울 수 있다.
의견을 가지는 건 괜찮다. 좋아하고 싫어하는 것이 있는 것도 괜찮다. 남들이 당신처럼 보지 않는다는 사실에 좌절하는 것도, 당신이 믿는 기술과 가치를 옹호하는 것도 괜찮다. 다만 다른 사람의 현실이 틀렸다고 말하는 것은 괜찮지 않다.
우리 모두의 주관적 차이를 포용하는 법을 배우면, 더 친절해질 뿐 아니라 더 행복해질 것이다.
