요약
생각을 소리 내어 혼자 중계하면 문제를 더 잘 풀 수 있다는 경험담입니다.
블로그 boristhebrave.com을 쓰는 보리스의 글입니다. 면접에서 지원자에게 생각을 소리 내어 말해 달라고 요청하던 그는 퍼즐 게임 The Witness를 하면서 같은 방법을 자신에게 써 봤습니다.
왜 중요한가
- 말은 생각보다 느리고 부정확한데도 소리 내어 생각하는 편이 더 낫다는 관찰입니다.
- LLM은 구조상 생각을 토큰으로 써 내야 되짚을 수 있는데, 비슷한 효과가 사람에게도 나타난다는 점이 새롭습니다.
- 면접에서나 쓰는 인위적인 기술로 여겼던 방법을 혼자 일할 때의 도구로 다시 보게 합니다.
핵심 내용
- 지루하던 The Witness를 하며 혼자 생각을 중계했더니 게임이 활기를 띠고 퍼즐도 더 잘 풀렸다고 했습니다.
- 러버덕 디버깅(인형에게 문제를 설명하다 스스로 답을 찾는 방법)과 같은 원리라고 봤습니다.
- 말로 풀면 숨은 가정을 점검하고, 생각을 우선순위와 의존 관계에 따라 차례로 정리하게 됩니다.
- 직관 대신 규칙에 이름을 붙이게 되고, 임의로 고른 선택지가 드러나 되돌아가기도 쉬워진다고 했습니다.
- 약 6,000명을 분석한 메타 연구도 중간 정도의 효과를 확인했지만, 호손 효과(관찰을 의식해 결과가 달라지는 현상)일 수 있다는 단서도 달았습니다.
HN 반응
- 면접관 경험이 있는 이용자들은 지원자의 사고 과정을 지켜보는 것이 면접에서 가장 값진 정보라고 입을 모았습니다.
- 반대로 머릿속에서 말로 생각하지 않거나 다 풀고 나서야 설명할 수 있다는 이용자들은 실시간 설명이 오히려 문제 풀이를 방해한다고 반박했습니다.
저는 최근 몇몇 회사에서 면접을 볼 때 거의 매번 이렇게 말을 꺼냈습니다. “좀 어색하게 느껴지실 수도 있지만, 이 코딩 문제는 문제를 푸시는 과정을 말로 설명해 주셨으면 합니다. 도움이 된다면 저를 인턴이라고 생각하세요. 좋은 아이디어든 나쁜 아이디어든, 고민 중인 방식의 장단점이든 전부 제가 지원자께서 문제에 어떻게 접근하시는지 파악하는 데 소중한 정보입니다.”
이렇게 명시적으로 말해 주면, 면접관이 무엇을 기대하는지 지원자가 암묵적으로 눈치껏 알아내려 할 때보다 마음이 좀 더 편해지는 것 같습니다. (그리고 불완전할 수도 있는 접근법을 감히 제안하는 지원자를 자동으로 탈락시키는 면접관이 많다는 것도 압니다.)
저는 면접관이 이러는 게 항상 싫었습니다. 제 사고의 흐름은 거꾸로 가거나, 아주 추상적이거나, 아무튼 대다수 사람들이 생각하는 방식과 완전히 다른 경우가 많아서, 그 자리에서 제 생각을 말로 풀어내는 건 불가능하진 않더라도 몹시 어렵습니다. 학교에서 글쓰기 과제를 할 때도 첫 문장을 쓰기 전에 결론에 이른 과정을 뒤집거나 재배열하는 데 시간을 많이 써야 했습니다. 게다가 결론에 이르는 것 자체가 막다른 길을 여러 번 거치는 일입니다. 어떤 대목에서는 순식간에 지나가기도 하고, 어떤 대목에서는 (대개 버릴 코드를 짜 가며) 막다른 길인 줄 알면서도 맥락을 파악하는 데 도움이 되니까 힘들게 토끼굴을 따라 들어가야 하기도 합니다. 선형적인 사고의 흐름을 만들기 시작하기 전에, 하물며 알아볼 수 있는 코드로 옮기기 전에, 먼저 문제 전체를 머릿속에 넣고 어느 정도는 탐색해 볼 수 있어야 합니다.
다시 말해 저는 일을 풀어 가는 과정을 실시간으로 설명할 수 없습니다. 먼저 조용히 끝까지 풀어내야 하고, 적어도 처음부터 끝까지 전체 경로가 어떤지 자세히 파악해야 하며, 그러고 나서야 내 생각을 설명할 수 있기를 기대할 수 있습니다. 생각하는 도중에 생각을 설명하라는 요구는 누가 저한테 시킬 수 있는 일 중에서 가장 스트레스가 크고 불가능한 일입니다. 차라리 면접 과정에서 손가락을 부러뜨리는 편이 낫겠습니다.
면접관 입장에서 이게 꽤 난감하다는 건 압니다. 그리고 이 방식이 합리적이라고 생각하시는 분이라면 저 같은 사람과 가까이서 일하는 게 맞지 않으실 수도 있겠죠(다만 관리자일 뿐이라면, 알아 두셔야 할 편향입니다).
마찬가지로 페어 코딩 같은 방식도 저한테는 전혀 맞지 않습니다. 팀 플레이어가 아니라는 뜻은 아닙니다. 설계나 즉석 기술 토론은 좋아하고 도움도 받습니다. 다만 다른 사람과 나란히 앉아서, 심지어 누가 어깨너머로 지켜보는 상태에서 코드를 짜라고는 하지 말아 주세요. 저를 포함해서 관련된 모두가 머리를 쥐어뜯게 될 뿐입니다. 물론 저와 비슷하게 생각하는 사람들과는 가장 잘 일합니다. 서로 선을 언제 어떻게 긋고 무엇을 기대해야 하는지 본능적으로 알거든요.
저 같은 사람을 면접하려면 지원자가 (추상적이든 구체적이든) 이정표를 짚어 보게 해서, 어려운 문제를 헤쳐 나갈 경험과 이해가 있는지 확인하는 게 아마 가장 좋을 겁니다. 다만 그 자리에서 실제로 길을 찾아 나가 보라고만 하지 마세요. 지원자가 실제로 점들을 어떻게 이어 가는지 보고 싶다면 이미 작성한 코드를 보세요. 다른 대부분의 분야와 달리 소프트웨어 개발자는 공유하기 쉬운 작업물이 쌓여 있는 경우가 많고, 이미 공개돼 있는 경우도 많습니다.
저는 엔지니어 지원자를 수십 명 면접해 봤습니다. 면접에서 제가 보려는 핵심은 지원자가 어떻게 생각하는지, 그리고 면접 자리에서 함께 일하는 느낌이 어떤지입니다.
기술적인 사안을 잘 소통하지 못하면 대체로 마이너스입니다.
그렇지만 지원자가 그런 질문으로 즉석에서 몰리면 잘 못한다고 솔직하게 말하고, 실제로 문제를 어떻게 푸는지 설명할 수 있고, 실무 환경에서 그 방식이 어떻게 통했는지 사례를 들 수 있다면, 그 답이 설득력 있을 경우 저는 그 사람을 그 직무 후보로 고려할 겁니다.
즉, 어떤 문제에 어떻게 접근할지 설명해 달라고 했는데 문제의 가장자리를 탐색하려고 버릴 코드를 좀 짜 볼 것 같다고 답하셨다면, 그건 좋은 답이라는 겁니다.
아니면 그 사람이 선형적인 단어가 아니라 추상적인 개념으로 생각하고(문제를 풀고) 있는 걸 수도 있죠. 많은 사람이 글을 읽을 때 입으로 단어를 따라 하거나 머릿속이나 입으로 단어를 듣지 않으면 생각을 못 한다고 해서, 다른 사람들까지 생각을 풀어 가는 자기 효율을 깎아 먹어야 하는 건 아닙니다. 개념형 사고를 하는 두 사람은 선형적 언어형 사고를 하는 사람들이 따라가기 힘든 초압축 속기 같은 방식으로 소통할 수 있습니다. “소통을 못 한다”라기보다는 “개념화를 못 한다”와 “언어화를 못 한다”가 맞붙은 상황에 가깝습니다.
두 부류 모두 마지막에는 간단명료하게 종합해야 하고, 둘 다 호흡을 맞추려고 노력해야 합니다. 그리고 두 사고방식 모두 팀에서 쓸모가 있습니다. 문제는, 개념형 사고를 하는 사람은 언어형 사고를 하는 사람을 면접할 수 있지만 그 반대는 더 어렵다는 점입니다.
개발자가 LLM과 함께 일하는 일이 점점 당연해지고 있으니, 어느 정도 높은 수준에서 분명하게 소통하는 능력이 과거보다 훨씬 더 중요해졌다고 말할 수도 있지 않을까 싶습니다.
저는 이게 정말 힘듭니다(그리고 지금은 실직 상태입니다).
제 생각에는 그게 바로 부모 댓글 작성자가 말하려는 요점이라고 봅니다. “이 사람이 CommunicationBench 3.0-beta7에서 효율적으로 소통하는가” 같은 절대적인 문제가 아니라는 겁니다. “내가 이 사람 옆에 매일 앉아서 끊임없이 소통하며 일하면 잘 지낼 수 있을까, 아니면 힘들까?”의 문제죠. 여기에는 다소 임의적이면서도 지극히 실용적인, 아주 개인적인 부분이 있습니다.
(단서를 달자면, 저는 늘 말 그대로 매일 옆자리에 앉아 끊임없이 소통할 수도 있는 소규모 팀원을 뽑는 면접을 해 왔습니다. 대기업 면접은 다르겠죠.)
저는 가끔 객체 사이의 관계로 생각합니다. 복도를 오르내리며 천천히 걸어 다니는데, “객체”는 복도 여기저기에 떠 있는 흐릿한 형체일 뿐입니다. 그렇게 생각하는 중이면 그 “추론의 사슬”을 설명하기가 어렵습니다.
그래도 관계를 다 파악하고 나면 말로 설명할 수 있습니다. “왜 이렇게 안 했어요?” “그건 영 투박한 느낌이었어요. 이쪽이 X, Y, Z 때문에 더 깔끔해 보였고요.”
하지만 면접에서 그 모드로 들어가야 했던 적은 한 번도 없습니다. 아니면 면접이 저한테는 너무 “즉각적”이고 상호작용이 너무 많아서 그 모드에 들어가지 못하는 걸 수도 있고요.
저는 당신과 그렇게 다르게 생각하는 것 같지 않은데도 몇 번의 면접을 성공적으로 통과했습니다. 저는 원 글쓴이보다 한 걸음 더 나아가서, 지원자에게 이렇게 말하기도 합니다. 저한테는 다른 사람이 읽을 수 있도록 이 사람을 채용해야 하는 근거로 채워야 할 빈 메모지가 있다고요. 코딩 문제는 그 작업을 시작하게 해 주는 계기입니다.
생각을 말해 주면 답 말고도 더 많은 걸 얻을 수 있고, 대화에 가까워집니다. 저는 지원자일 때 무엇이든 생각하다가 비슷한 프로젝트가 있으면 그 얘기를 꺼냅니다. 면접관 입장에서는 경험을 끌어내기가 어렵습니다. 너무 많은 사람이 추상적인 얘기에 머물러서 속이 터질 지경이거든요. (제가 이 자리를 얻도록 도와드릴게요! “할 수 있어요”는 아무 의미가 없고, “언제 했는지”가 전부입니다.)
그래도 많은 면접관은 이렇게 보지 않고 안타깝게도 퀴즈처럼 다룬다고 확신합니다. 지원자일 때 들은 면접 조언 중 최고는 이거였습니다. 면접관은 처음 5분 안에 당신을 채용할지 결정한다. 나머지 면접은 그 결정을 스스로와 다른 사람들에게 납득시키려는 과정이다.
꼭 물어보고 싶은 게 있습니다. 저는 46살이고, 약 30년 동안 밥벌이로 코드를 써 왔지만 정규직인 적은 없고 항상 계약직이었습니다. 당장 AI로 재작성하는 위험을 감수하지 않을 비기술 기업들을 위해 코드를 충분히 많이 짜고 유지보수해 왔기 때문에, 아마 은퇴할 때까지 버틸 수 있을 겁니다. 하지만 면접을 보거나 저를 팔아야 했던 건 아주 오래전 일입니다.
저는 늘 면접은 쉽게 통과하리라 생각했지만, 팀에서 그다지 잘 일하지 못한다는 점에서 이 모든 일이 있기 전에도 제 생각이 틀렸을 수 있습니다.
그런데 한편으로는, 지금 와서 지원자가 결과물을 내놓는 것보다 사고 과정을 설명할 수 있는지가 정말 가치 있는 질문일까요? 20년 전, 실제로 그게 중요했을 때는 왜 그런 질문을 하지 않았을까요? 아니면 기준이 더 높아져야 하는데 그들을 가르쳐 줄 경험 많은 개발자 풀이 없어서 지금 더 중요해진 걸까요?
저는 부모 댓글 작성자가 말한 것과 정확히 같은 방식으로 합니다. 제 견해도 같습니다.
핵심은 주니어인지 시니어인지 가려내는 게 아닙니다. 지원자가 문제를 끝까지 생각해 낼 수 있는지가 핵심입니다. 생각을 말로 잘 표현할 필요조차 없습니다. 저는 그저 문제를 어떻게 (그리고 과연) 쪼개서 열어 보고, 그 안을 걸어 보고, 풀어낸 다음, (적어도 본인 보기에는) 그럴듯한 해법으로 수렴해 가는지를 보고 싶을 뿐입니다.
막히면 저는 기꺼이 도와줍니다. 흐름을 끊거나 엉뚱한 방향으로 돌리지 않고요. 엉뚱한 토끼굴로 들어가면 문제를 깨닫고 정상 궤도로 돌아오도록 유도 질문을 던지기도 합니다.
기준이 더 높아지는 게 아닙니다. 제 경험상 안타깝게도 면접을 보러 오는 사람이 엄청나게 많은데, 그중에는 문제를 머릿속에서 모델링하지 못하고, 자기 코드가 어떻게 돌아갈지 모델링하지(코드 실행을 머릿속으로 그려 보지) 못하고, 논리적으로 풀어내지 못하는 사람이 많습니다. 이들은 스택 오버플로, 도움말, 튜토리얼에서 맹목적으로 복사해 붙이는 것으로 버텨 온 경우가 많습니다. 그 비율이 엄청납니다.
저도 코딩을 아주 오랫동안 해 왔고(당신보다 연배가 위입니다), 초창기에는 이런 대화를 굳이 요청하지 않아도 자연스럽게 이뤄졌습니다. 제가 면접을 받는 입장이던 거의 모든 면접이 그랬어요. 문제를 던져 주면 저는 거기에 빠져들지 않을 수 없었거든요. 기술 직군 지원자는 실제로 애정이나 열정, 실력이 조금은 있어서 그 길로 들어선 사람들뿐이었죠.
그런데 거대한 산업이 되면서 그 길에 들어선 대부분은 ‘해커(문제 해결사)’가 전혀 아니었습니다. 그저 높은 연봉이 좋았던 거죠. 지능이 있을 수도 있지만, 독립적으로 코드를 책임질 만한 능력이 없는 사람이 많았습니다. 그래도 적당한 프레임워크 등이 있으면 기본적인 CRUD에는 쓸모가 있습니다. 그래서 엔터프라이즈 애플리케이션, 자바/C# 같은 초대형 플랫폼·프레임워크 영역에서 번성합니다.
일자리는 적은데 지원자는 너무 많습니다. 그러니 모든 지원자를 검증해야 한다고 느끼는 사람들이 온갖 터무니없는 필터를 만들어 내는 거죠. 사실 관련 경험이 있는 사람이면 거의 누구를 뽑아도 일은 해내겠지만, 그러면 좋은 채용 절차로 보이지 않을 테니까요.
저는 실무 엔지니어링 경력이 약 15년이고, 몇몇 역할에서 채용 관리자로도 일하며 수십 명의 지원자를 면접했습니다.
모든 지원자가 자기 경험을 정확하게 말하고 모든 지원자가 그 직무를 소화할 수 있는 세상에서 살고 싶지만, 안타깝게도 현실은 그렇지 않습니다.
대부분 보여 주기식인 필터(리트코드 같은)가 있다는 데는 동의하지만, 자기가 하는 일을 말로 풀어 설명할 수 있는 것은 기본 중의 기본입니다. 엔지니어뿐 아니라 모든 전문직이 그렇습니다.
“팀에서 잘 일하는가”가 기술 기업이 가장 우선으로 걸러 내려는 항목이라는 걸 알게 되실 가능성이 높다고 봅니다. 기술적 역량도 물론 좋지만, 대기업에서는 소통과 협업이 업무의 절반입니다.
“팀에서 잘 일한다”는 것은 문제를 푸는 동안 자기 생각을 설명하는 능력과는 전혀 상관이 없습니다.
제가 일했던 모든 팀은 제 기여를 높이 평가했습니다. 바로 제가 동료들에게 내가 문제를 어떻게 풀었는지, 또는 그들이 문제를 어떻게 풀어야 하는지를 각자의 이해 수준에 맞게 달리 설명해 주는 데 기꺼이 많은 시간을 썼기 때문입니다.
반면에 저 역시 생각이 진행되는 도중에 그것을 설명하는 건 전혀 못 합니다. 상대가 알아듣게 다시 풀어내다 보면 생각의 속도가 너무 많이 느려지기 때문입니다.
생각을 실시간으로 설명하려면 일종의 언어 번역까지 필요합니다. 저는 혼자 속으로 말할 때 정확하고 모호하지 않은 단어로 이루어진 특별한 언어를 쓰는데, 그 뜻이 많은 경우 단어의 옛 뜻과 일치합니다. 현대어에서는 아주 많은 단어가 뜻이 모호해졌고, 부적절한 맥락에서 자주 쓰이는 바람에 의미가 크게 희석됐기 때문입니다.
그래서 다른 사람들에게 기술적 해법을 설명할 때는 보통 제가 그것을 생각할 때 쓰는 단어를 쓰지 않고, 요즘 더 유행하는 단어를 씁니다. 상대가 그 단어에 익숙하리라 기대하기 때문이죠. 그 단어들이 적절하지 않다고 생각할 때조차 그렇습니다.
생각하는 동안 이런 번역을 하는 건 너무 어렵고, 저는 이유 없이 수시로 유행하는 단어로 생각하려고 하지 않습니다. 제 생각에 개념에 올바른 이름을 붙이는 것은 개념을 제대로 이해하고 사용하는 데 매우 중요하기 때문입니다.
상위 경영진과 소통하고 협업하면서 그들의 요청을 탄탄한 코드로 바꾸는 일이요? 그게 제가 돈 받고 하는 일입니다. 다른 코더와 소통하고 협업하는 일은요? 그건 별로 아닙니다. 참고로 저는 기술 기업을 위해 일하지 않는다고 분명히 말했습니다.
맞습니다. 제 말은, 나중에 계약직에서 벗어나 전환하려 한다면 이 점이 더 큰 문제가 될 가능성이 높다는 겁니다. 사내 개발팀은 협업을 매우 중시하고, 면접 과정은 (가능한 한도에서) “외톨이 늑대” 같은 엔지니어를 걸러 내려 합니다.
저도 최근에 이런 면접을 봤는데, 제 생각을 가능한 한 자세히 전부 말했습니다. 그런데 탈락 통보와 함께 받은 피드백은 “풀이 과정을 더 보고 싶었다”는 것이었습니다.
그러니 지원자가 마음이 편해질 수는 있겠지만, 정말 중요한 건 실제로 귀 기울여 듣는 일이라고 생각합니다.
“문제를 말로 풀어 보기”, “메모하기”, “문제 스케치하기”를 “Chain of thought”라는 틀로 다시 포장하다니요. 흥미롭네요. 뇌를 관 속을 흐르는 물이나 시계 장치로 개념화하던 시대에도 사람들이 자기 특성을 이렇게 거꾸로 의인화했을지 궁금합니다.
“톱니바퀴가 돌아간다”나 “나사가 풀렸다” 같은 표현이 그 시대의 흔적이겠죠. 지금의 어텐션 시퀀스 모델 열병에서 깨어나고 나면 어떤 흔적이 일상어에 오래 남을지 흥미로울 겁니다.
저는 어려운 작업을 풀어 갈 때 제 노트에 스스로에게 말하듯 “chain of thought”를 적습니다. “비공개 라이브 트윗”이라고 불러도 되겠네요.
가끔은 초능력처럼 느껴집니다. “시작하기 전의 불안”이 사라지고, 모든 것이 “간단한 단계를 따라가는” 사소한 순서로 바뀌거든요.
저도 그렇게 합니다. 제 느낌에는 이렇게 하는 사람, 아니 제대로 메모하는 사람 자체가 아주 드뭅니다. 같이 일하는 사람 대부분이 몇 달보다 오래된 일은 전혀 기억하지 못하는 것 같은 걸 보고 하는 말입니다.
ㅋㅋ 저는 기억나는 게 거의 없지만, 전부 노트에 있어요. 그게 더 낫다고 생각해요. 뭔가를 기억해 내려고 머리를 무겁게 할 필요가 없잖아요.
지원자의 사고 과정을 직접 지켜보는 것이 저한테는 아마 면접 과정에서 가장 가치 있는 부분입니다. 그에 견줄 만한 건 없어요. 그냥 문제를 푸는 모습을 듣고 보게 해 주세요.
자기 사고 과정을 전혀 접해 본 적 없는 사람으로서, 저는 이게 늘 너무 차별적이라고 느껴요! ;)
이게 anendophasia, 즉 내면의 목소리가 없는 상태와 관련 있는지 궁금합니다. 자기 성찰과 언어적 작업 기억에 영향을 준다고 하더라고요.
모든 사람에게 내면의 목소리가 있는 것은 아니다: anendophasia의 행동적 결과 - https://doi.org/10.1177/09567976241243004
저는 아판타지아(aphantasia)가 있어서 anendophasia는 악몽처럼 들리지만, 그게 있는 사람들은 저와 정반대로 느끼겠죠. 예전에 anendophasia가 있을 것 같은 사람들을 만난 적이 있지만, 무례하게 보이지 않고 그 얘기를 꺼낼 방법을 모르겠더라고요.
anendophasia가 있는 분 중에 경험담을 들려주실 분 계신가요?
네, 저도 아주 잘 압니다. 저는 내면에서 의미를 말로 풀어내는 일이 전혀 없습니다. 사람들이 명상 이야기를 하면서 머리를 비우라는 식으로 말하는 걸 들으면 늘 웃음이 나요. 그게 제 평소 상태거든요. 그 안은 완전히 고요합니다...
하지만 그 정도가 아닙니다. 저는 생각이라는 걸 의식적으로 인지하는 일 자체가 전혀 없어요. 오히려 TV 드라마 세브란스에 나오는 사람들이 “느낌이 맞을 때까지” 숫자를 응시하는 것과 훨씬 비슷합니다.
결과가 머릿속에 그냥 불쑥 떠오르는데, 대개 붙잡을 수도 없는 어떤 느낌으로 올 뿐이고, 소리 내어 말하거나 글로 쓸 때에야 의미 있는 형태를 갖춥니다. 글로 쓰는 중에도 그 과정은 이어집니다. 딱 맞을 때까지는 영 맞지 않는, 조율이 안 된 듯한 거슬리는 느낌이 계속되는 거죠.
한 가지 예외가 있습니다. 비몽사몽 상태는 제가 곱씹을 수 있는 유일한 상태(예: 스트레스와 관련된 것)인데, 그때도 언어가 아니라 이미지와 감각의 조합에 더 가깝습니다. 이걸 말로 옮기기가 어렵네요(말장난 아닙니다)...
anendophasia를 안에서 본 아주 흥미로운 묘사네요. 내면의 독백, 즉 단어와 이미지가 끊임없이 흐르는 상태가 없다는 건 상상하기 어렵습니다. 그 안이 얼마나 조용하고 좋을까요! 저는 그 흐름을 멈추려면 의식적으로 한 걸음 물러서야 하고, 주의가 딴 데로 흘러가면 흐름이 저절로 다시 시작됩니다.
시각적으로 생각하는 편이라고 하시겠어요, 아니면 이미지도 전혀 없나요? 단어도 이미지도 없이 어떻게 생각할 수 있는지 상상해 보려고 (하하) 애쓰는 중입니다. 제가 공감할 수 있는 가장 가까운 경우는 피아노 같은 악기를 연주할 때입니다. 그때는 내적으로 구체적인 개념 없이, 단어도 색도 형태도 소리조차 없이 생각하는 과정이, 심지어 문제 해결까지 있습니다. 생각해 보니 수학을 하거나 소프트웨어를 쓸 때도 가끔 그런 비언어적(그리고 비시각적) 사고 모드에 들어갑니다. 행동하면서 생각하는 것과 같아요. 대개는 외부 매체를 통해, 코드, 숫자, 연산, 음악이나 미술을 그것이 만들어지는 순간에 빚어내면서요.
대부분의 사람이 가끔은 의식적이든 아니든 이렇게 한다고 생각해요. 다만 주된 사고방식이 아닐 뿐이죠. 흥미롭네요.
어쩌면 과거에는 더 흔했을 수도 있고, 불교 수도원 같은 일부 하위문화에서도 그럴 수 있겠죠. 아니면 동물이나 식물의 “사고 과정”, 단어 없이 문제를 해결하는 방식과도 비슷할 거예요.
시각적 상상력과 내면의 독백은 서로 보완하는 관계가 아니라 오히려 직교하는 능력에 가깝습니다. 저는 둘 다에서 한참 멀리 있습니다. 답이 길어서 죄송하지만, 이 주제는 마주칠 때마다 저를 붙잡아요... ;-) 그리고 제가 이제 말씀드릴 내용을 생각하면 아이러니하게도, 주변 사람들은 저를 상상력이 아주 풍부한 사람이라고 합니다.
저는 의식적인 시각 이미지가 없습니다. 사랑하는 사람들의 얼굴을 떠올리지 못하고, 기억 속 장면을 시각적으로 일관되게 느껴지는 방식으로 “보지” 못합니다. 때때로 그림 연습을 해 봤는데도 사람, 동물, 풍경을 기억만으로 그리지 못합니다. 실제 모델이나 참고 사진이 있어야 해요. 상상의 장면이나 더 기본적인 형태는 그리거나 칠할 수 있겠지만, 참고 자료 없이 사실적인 건 힘들 겁니다. 결함이 있다는 건 알아보지만, 빠진 부분을 불러낼 수는 없어요.
저는 내면의 독백도 전혀 없습니다. 제 생각은 언어적이지 않습니다. 이미 생각해 낸 다음에 그 아이디어를 말로 옮기는 건 제가 따로 해야 하는 일입니다. 단어에 대해 생각하는 건 하나의 작업으로 할 수 있지만, 단어로 생각하지는 않습니다. 이 면접 전략도 저한테는 악몽처럼 들립니다. 철학적이거나 심리학적인 방식으로 “내가 어떻게 생각하는지”는 길게 말할 수 있어도, 실제 사고 과정을 말로 옮길 수 있는 중간 단계의 연속인 것처럼 읊을 수는 없습니다. 그건 저한테 터무니없이 맞지 않아요.
그와 대조적으로 저는 고유수용성 감각과, 실제 3차원과 4차원(시공간) 구조 양쪽의 공간 관계 혹은 위상에 대한 감각을 위한 꽤 강력한 내면의 무대가 있습니다. 집중하면 추락, 회전, 충격, 비행 같은 것을 상상하면서 신체 감각을 거의 불러일으킬 수 있습니다. 이럴 때 의도치 않게 내면의 오디오 무대가 작동해서 그에 대응하는 음향 효과를 상상하기도 합니다.
제 공간 무대에는 1인칭 버전과 3인칭 버전이 있습니다. 가끔은 역동적인 무대, 즉 움직이는 3D 대상들에 대해 생각할 수 있지만, 더 흔하게는 이동 벡터 정보를 포함하는 좀 더 정적인 무대 감각으로 바뀝니다. (아쉽게도 이 덕에 제가 무용수가 되거나 안무를 감상하게 되지는 않았습니다...) 이걸 사람들에게 어떻게 설명해야 할지는 모르겠어요. 저는 그것을 “보지” 않습니다. 느끼거나 압니다. 원근법 같은 투영이 있어서 가까운 공간을 선호하거나 확대할 수는 있지만, 가려짐이나 조명 같은 시각적 감각질(qualia)은 없습니다.
항상은 아니지만 가끔 저는 더 추상적인 생각을 이 공간 무대에 대응되는 위상 구조에 얹기도 합니다. 그러면 문제의 형태, 문제 공간, 그 위에서 이루어지는 탐색 과정을 “느낄” 수 있습니다.
앞에서 말했듯이 저는 내면의 오디오 무대가 있습니다. 임의의 소리를 생각할 수 있고, 마치 보조 채널로 실시간 청각을 희미하게 재현한 듯한 경험이 됩니다. 강도와 주파수, 타이밍과 리듬 같은 감각질이 있습니다. 화음, 소음, 날카로운 어택 같은 것도 전달할 수 있습니다. 극단적일 때는 가슴을 때리는 깊은 저음이나 귀에서 지글거리는 하이햇 같은 신체 감각을 거의 유도할 수 있습니다. 하지만 이건 늘 구석 한쪽에 있는 장치처럼 접근할 수 있는 것이고, 실제 청각으로 착각하는 일은 없습니다. 이것과 실제 청각은 병렬로 작동할 수 있지만, 실제 소리가 압도적으로 크거나 의미 있는 내용으로 가득하면 내면의 무대에 주의를 기울이기가 더 어렵습니다.
단어에 대해 생각할 때는 가끔 이 오디오 무대를 씁니다. 어느 정도는 사람들이 말하던 것을 기억해 내거나 억양 등을 넣어 가상의 말을 돌려 볼 수 있습니다. 다른 오디오 사고보다 소리의 감각질은 좀 더 빈약한데, 소리의 질보다 의미와 감정 내용에 더 집중하기 때문입니다. 누구의 목소리를 상상하는지는 알지만, 소리 감각질을 풍부하거나 충실하게 합성하는 것은 아닙니다. 음악적 생각은 그 풍부함이 더 많이 따라옵니다.
하지만 저는 더 상징적인 또 다른 언어 무대가 있습니다. 실시간으로 흐르는 스트림이라기보다 파스 트리 같은, 단어의 위상을 느끼는 것에 더 가깝습니다. 그것이 제 공간/위상 무대에서 의미 단위로 변형되기 때문에 시각적 과정이라고 말하는 건 잘못일 겁니다. 모든 단어가 아니라 절, 장 등의 순차적 구조에 대해 생각하는 식으로 추상화할 수도 있습니다.
마지막으로, 위에서 말한 모든 것은 제가 적용할 수 있는 도구처럼 느껴집니다. “나” 자신이나 제 핵심적인 생각처럼 느껴지지는 않습니다. 이 모든 것의 배후에서 일어나는 제 생각을 설명하기는 아주 어렵습니다. 위의 감각들 중에는 세계 속에서 닻을 내린 제 실제 위치를 나타내는 버전이 있고, 제가 조작할 수 있는 추가적인 “상상” 버전들이 있습니다. 진짜 저는 이들 사이를 오가는 형체 없는 주의 같은 것입니다.
(아마도) 트라우마의 영향 때문에 저는 상황 인식이 매우 높습니다. 그래서 제 주의가 현실 세계 감시에서 완전히 분리되는 일은 아주 드뭅니다. 하지만 다른 문제 해결이나 회상, 되새김에 정말 집중할 때는 그 우선순위를 약간 낮출 수 있습니다. 믹싱 보드에서 한 배합에서 다른 배합으로 넘어가는데, 급작스럽게 바뀌느냐 부드럽게 섞이며 이행하느냐의 정도가 다양한 것과 비슷합니다...
문제를 풀려고 하면서 생각을 말로 풀어내면 제 IQ가 적어도 20점은 떨어집니다.
면접이 IQ를 평가하지 않는 게 다행이네요 :)