앨리스 토끼굴

"언제나 앨리스의 토끼굴Rabbit Hole*에 빠지지 않도록 주의해야 합니다."

*어떤 개념을 이해하기 위해 파고들수록 또다른 개념을 이해할 필요가 생겨서 처음 의도한 학습 방향과 점점 멀어지는 현상을 <이상한 나라의 앨리스>에 등장하는 토끼굴에 비유한 말

[모던 자바스크립트 딥 다이브] : 들어가며 VI

초보자는 무엇이 중요한지 모릅니다

"모르는 게 너무 많아요 ㅠㅠ"

코칭을 하다보면 이런 말을 자주 듣습니다. 세상에 어느 분야나 앎에는 끝이 없습니다. 코딩이라고 특별하진 않습니다. 매우 좁은 분야를 집중해서 파고들더라도 모든 걸 아는 건 불가능합니다.

그래서 보통 "일단 중요한 핵심만" 공부하라고들 합니다. 완벽주의에 빠지지 말고, 일단 넘어가라는 것이죠. 여기까지는 다들 아는 이야기이고, 저도 자주 하는 조언입니다.

그러면 그런 조언을 듣고도 왜 코딩을 시작하는 초보자들은 토끼굴에 빠지게 되는 걸까요? 그 이유를 알아야겠습니다. "무엇이 중요한지 모르기 때문에" 그렇다는 건 동어 반복이니까요.

추상적이다

코딩의 개념들은 추상적이고 눈에 보이지 않습니다. 상태나 http 요청, xml, 선언적이니 edge computing이니 하는 개념들을 듣다보면, 시키는대로 하곤 있는데 내가 뭘 하고 있는지 모르게 됩니다.

낯설다

John Von Neumann once said to Felix Smith, "Young man, in mathematics you don't understand things. You just get used to them."

존 폰 노이만은 펠릭스 스미스에게 이렇게 말한 적이 있다, "젊은이, 수학에서 당신은 그것들(things)을 이해하는 게 아닐세. 그저 익숙해질 뿐이야."

여러분은 한글과 한국어로 쓰인 이 글을 읽고 있지요? 한국어는 참 어려운 언어라고 하는데, 여러분이 한국인이라면 모국어에 익숙하기 때문에 어렵지 않을 겁니다

생각해보면 영어는 물론이고 수학이나 프로그래밍도 외국어입니다. 서버가 요청을 보내고 받고 어쩌고 하는 걸 듣도 보도 못했으니. 외국어로 쓰인 글을 읽는 것처럼 정신이 멍해집니다.

낯선 외국에 떨어진 것처럼, 헤매는 것도 당연하지요. 불안하고 두려울 겁니다!

이런 설명이 그럴듯하게 느껴지시나요? 다른 이유도 있을 수 있겠습니다만, 일단 이 둘에 집중해봅시다.

전문가에게는 당연하지만, 초보자에게는 아닙니다

1. 전문가는 초보자가 지각하지 못하는 정보의 특징과 의미 있는 패턴을 지각한다.
2. 전문가는 분야에 대한 깊은 이해를 반영하면서 조직화된 풍부한 내용 지식을 가지고 있다
3. 전문가의 지식은 분리된 사실이나 명제의 형태로 단순화될 수 없으며, 지식을 적용할 수 있는 맥락을 반영한다. 즉, 지식은 상황에 따라 '조건화'되어 있다.

[학습과학 : 뇌, 마음, 경험 그리고 교육]

이제 구체적인 상황을 하나 예로 들어서, 초보자의 사고 과정을 따라가며 해결책을 제시해보겠습니다.

js로 코딩을 시작하는 분들은, nodejs를 설치하고 실행하게 됩니다. 안타깝게도 여기서부터 막히시는 경우가 많습니다. 저는 개발환경을 구축하면서 꼬이지 않은 경우가 없거든요.

보통 설치가 잘 됐는지 확인하기 위해, 프로그램의 버전을 출력해보곤 합니다.

node-v를 터미널에 쳤는데, 다음과 같은 에러가 나왔다고 해봅시다.

node-v
node-v: command not found

겨우 한 줄이지만. 이 에러를 이해하려면 많은 암묵지가 필요합니다. 암묵지란 어디서 말이나 글로 설명해주지 않고, "감"처럼 전수되는 지식을 말합니다.

• command가 무엇인지?
• command not found는 무슨 뜻인지?
• 터미널은 command를 어떻게 찾아오는지?
• 명령어는 어떤 구조로 되어 있는지?
  • 예를 들어 option이나 flag는 무엇인지?

터미널에 익숙한 사람들은 이 에러의 원인을 빠르게 추측할 수 있고, 문제도 해결할 수 있습니다.

하지만 초보자들은 그런 경험이 없습니다. 상상의 나래를 펼치게 됩니다. 예를 들자면 다음과 같습니다.

• 소문자라 그런 건 아닐까? -V라고 치면 될 것 같아.
• -를 하나만 쳐서 그런 건 아닐까? -- 두 번 치면 되지 않을까?
• 약어라서 그렇진 않을까? --version이라 치면 되지 않을까?
• 오타를 낸 것은 아닐까? deno-v 라고 치면 잘 되지 않을까?

중요한 사실은 이런 추측이 꼭 잘못되거나 이상한 게 아니라는 겁니다. 예를 들어 실제로 node의 창시자가 새로 만든 deno는 deno -v라고 치면 에러를 뱉습니다. deno --version이라고 쳐야 버전을 출력하죠.

정답은 -v와 같은 옵션은 node 같은 명령어(command)와 띄어 써주어야 한다는 것입니다. 그러니까 node-v처럼 붙여 쓰면 안 되고, node -v처럼 써줘야 한다는 것이죠. 붙여 쓰면 node-v를 통째로 하나의 명령어로 인식하게 됩니다.

그러면 초보자는 이런 상황에서 어떻게 해야 혼자 문제를 해결할 수 있었을까요?

어디까지 파고들지 판단하고 결정합시다

보통 여기서 "나는 기본기가 부족해 ㅠㅠ"로 점프하는 경우가 많습니다.

저희 예에서는 "리눅스 커맨드 라인을 제대로 공부해야겠어" 같은 거죠. 리눅스 커맨드 라인에 대한 책을 사거나, 강의를 듣기 시작합니다. 더 나아가 운영체제의 원리나 논리회로, 양자역학과 미적분학 같은 걸 공부하려 하시기도 해요.

이게 바로 앨리스 토끼굴입니다. 산으로 가는 거죠.

node를 설치하려한 이유가 원래 있었을 겁니다. 서버를 돌린다던가, 리액트로 프로젝트를 한다던가 말이죠. 그런데 공부"해야 한다"는 리스트가 계속 추가되는 겁니다.

리눅스 커맨드 라인을 배우는 것 자체는 나쁘다는 게 아닙니다. 오히려 커맨드 라인은 한 번 제대로 배워보는 게 좋습니다.

문제는 불안이나 두려움이 강박으로 이어지는 겁니다. 앞서 말했듯 시니어가 되더라도 세상에는 모르는 게 훨씬 많을 겁니다. 불안을 노력이나 성취로 해결하려 한다면. 목이 마르다고 바닷물을 마시는 것과 다르지 않습니다.

우리는 불안에 휘둘리는 게 아니라, 판단하고 결정을 해야 합니다. 무엇을 배우고, 무엇을 배우지 않을지. 내가 필요한 건 어디까지인지 말이죠.

앎의 수준을 세세하게 나눕시다.

우리는 아는 것과 모르는 것으로 세상을 나눕니다. 나는 HTML은 알지만, React는 몰라~ 같은 식으로 말이죠. 이력서에 HTML은 80% 정도 수준이라고 쓰기도 합니다.

하지만 안다고 다 아는 게 아니고, 모른다고 다 모르는 게 아닙니다. 앎의 수준을 더 세분화해봅시다.

• 그것의 존재조차 모른다
  • 예를 들어 커맨드라는 말을 처음 듣는다
• 들어봤지만, 모호하고 막연한 편견을 가지고 있다
  • 예를 들어 터미널은 대충 해커들이 쓰는 멋진 검은 화면이라 생각한다.
• 무엇이고 언제 왜 필요한지 대강 알지만, 할 줄은 모른다.
  • 예를 들어 명령어나 환경 변수에 대한 글을 북마크해놓고 안 읽고 있다
• 간단한 경험이 있지만, 자주 자료를 참고하거나 도움을 구해야 한다. 문제 해결에 시간이 오래 걸린다.
  • 예를 들어 책이나 강의를 보고 필요한 명령어를 따라칠 수 있다.
• 일반적인 경우는 잘 해낼 수 있지만, 특이한 경우는 도움을 구해야 한다. 상황에 맞지 않아도 익숙한 해결책을 적용하기도 한다.
  • 예를 들어 터미널에서 설치하고 실행하고, 환경 변수를 설정하는 일들을 할 수 있다. 책이나 문서가 낡거나 잘못되어 있으면 헤매게 된다.
• 빠르게 숙달되어서 할 수 있다. 자주 하는 실수를 알고 있고. 익숙하고 "유창(fluent)"하게 느껴진다. 특이하고 비전형적인 상황에도 대처할 수 있다.
  • 예를 들어 마우스를 쓰는 것보다 빠르게 터미널을 사용한다. 머리 속에 패키지가 설치되고 실행되는 심성 모형(mental model)을 그릴 수 있다.

우리는 보통 많이 알 수록 좋다고 생각합니다. 그래서 모든 걸 유창하게 하고 싶어합니다.

하지만 세상은 변하고 모든 지식이 나에게 쓸모 있는 건 아닙니다. 사실 대부분은 "무엇이고 언제 왜 필요한지?"만 알고 있으면 충분합니다. 그러면 스스로 판단할 수 있습니다. 필요한 상황이 왔을 때 배우면 되니까요.

예를 들어 저는...

• GraphQL이나 Relay는 왜 쓰는지 정도는 알지만, 뭘 만들어 본 적은 없습니다.
  • 배워보면 도움이 될만한 상황도 여러 번 봐서 공부해보려 해요.
• C나 Rust로 저수준 시스템 프로그래밍을 할 줄 모릅니다
  • 수업을 착각해서 논리회로 수업을 들은 적이 있습니다. 가산기나 이진수를 십진수로 변환하는 논리회로를 만들 줄 알지만, 쓸모가 없었습니다.
• ORM 없이 SQL로 10개가 넘는 테이블을 설계하거나, 최적화해본 적이 없습니다.
  • 앞으로도 ORM을 쓰거나 EdgeDb를 쓸 것 같아요.
• redux로 장난감 todo list 이상의 도메인을 모델링해본 적이 없습니다
  • 당분간은 redux-saga나 thunk 같은 미들웨어를 배울 생각이 없어요.
• css grid를 예제 복사 붙여넣기 이상으로 쓸 줄 모릅니다
  • CSS를 잘 몰라서 고통스러운 일이 많았습니다.

추천하는 글에 있는 댄 아브라모의 글도 읽어보세요.

지식을 쪼개자

또 도움이 되는 접근 방법이 있다면, 지식을 잘게 쪼개는 겁니다.

예를 들어 "리액트를 할 줄 안다"는 말은 너무 두루뭉술합니다. 왜냐면 리액트를 잘 한다는 것도 여러가지 부분으로 나눠서 생각해볼 수 있기 때문입니다.

• 리액트의 독특한 렌더링 방식을 잘 안다는 뜻인지?
• class component를 안다는 건지?
  • 아니면 구조 분해 할당과 hook을 잘 쓴다는 건지...
• suspense나 portal 같은 최신 기능을 잘 사용하는지?
• radix나 react-hook-form, react-query 같은 리액트 용 라이브러리를 잘 다루는지?
• nextjs나 remix 같은 서버 사이드 렌더링 프레임워크를 잘 다룬다는 건지?
• semantic html을 모르고, 모든 걸 div로 만든다면 리액트를 잘 하는 걸까요?

이렇게 생각하면 경력이 길다고 무조건 고수일 수는 없습니다. 세상은 넓고 복잡할 뿐만 아니라, 계속 변하기까지 합니다. 리액트 경력이 10년이라도 suspense나 portal 앞에서는 초보자일 수 있어요. (참, 리액트는 2013년에 나왔다고 합니다.)

그러니 막연하게 모든 걸 알아야 한다는 부담감보다는, 구체적으로 무엇을 배워서 어떻게 써먹고 싶은지 생각해보세요. 그렇게 하나씩 빈틈을 채워가면 됩니다. 어떤 건 평생 안 채워도 될지도 모르지요. ;)

구체적인 목표를 세우는 법에 대해서도 일일회고 가이드에서 다룬 적 있습니다. 더 자세한 이야기가 필요하면 읽어보세요.

당장 필요한 것, 앞으로 필요할지도 모르는 것

당장 필요한 것과 앞으로 필요할지도 모르는 걸 구분하면 좋습니다. 잠시 멈춰서, 어떤 문제를 해결하기 위해서 이걸 공부하는 건지 스스로 물어보세요.

구체적인 질문 먼저

아까 노드를 설치하는 예를 다시 볼까요? 노드도 잘 설치했고, 매번 프로젝트를 실행하는데 큰 어려움이 없다면... 리눅스 커맨드의 복잡한 구조를 당장 알 필요는 없습니다.

하지만 이런저런 도구를 쓰다보면 다양한 커맨드라인 옵션을 보시게 될 거에요. 이런 때에 리눅스 명령어의 구조를 배워보면 좋습니다.

이왕이면 구체적인 궁금증부터 시작해보세요. 예를 들어 저는 리믹스를 쓰면서 tailwind를 설정하는데, package.json에 다음과 같은 명령어를 넣으라고 하더군요.

{
  // ...
  "dev": "run-p \"dev:*\"",
  "dev:css": "postcss styles --base styles --dir app/styles -w",
  "dev:remix": "remix dev",
  // ...
}

그리고 pino라는 logger를 설정하려 하니, 서버를 실행하는 명령어에 다음과 같이 넣어주라고 했습니다.

node app.js | pino-pretty

흠, 그러면 저는 의문이 생깁니다. 저는 app.js도 없고 node로 서버를 실행하지도 않는 걸요? 그러면 저는 어떻게 해야하는 걸까요?

• |는 뭐하는 걸까요?
  • node app.js 뒤에 pino-pretty를 해주는 이유는 뭘까요?
• run-p는 어디에 쓰는 걸까요?
• 왜 \"dev:*\""처럼 \"라고 쓰는 걸까요?
• 저 옵션들은 무슨 뜻일까요?
• 왜 --dir은 --를 두 번 쓰는데, -w는 한 번만 쓸까요?
• dev:css랑 dev:remix는 각각 어떤 역할을 하는 걸까요?

이러면 "리눅스 커맨드 라인을 공부하자"처럼 너무 멀리 가기 쉽지 않습니다. 당장 문제를 해결하는데 필요한 것이기도 하고요.

탐험 : 호기심과 낭비도 쓸모 있다

근시안적으로만 살자는 건 아닙니다. 무엇이던 극단은 안 좋습니다. 지금 당장 업무나 사이드 프로젝트에서 쓰는 것만 공부한다면, 나에게 익숙한 곳에서 벗어날 수 없을 겁니다.

그래서 저는 찍먹과 탐험을 추천합니다.

예를 들어 저는 지금은 프런트엔드를 하지만, 옛날에는 백엔드를 하던 시절이 있었습니다. 그래서 서버 사이드 렌더링을 하는 remix나 nextjs 같은 프레임워크가 낯설지 않았어요. 리눅스 환경에도 더 익숙했고요.

"하나에 집중해 볼 생각은 없으세요?"라는 말을 듣기도 하지만. 백엔드 경험은 결국 지금 프런트엔드를 하면서도 도움이 되었어요.

고착에서 빠져나와 다양한 경험을 하기

우리는 잘 모르는 것에 편견이나 잘못된 지식을 가지는 경우가 많습니다. 경험을 해봤더라도 그래요. 내가 경험해본 것만 가지고 일반화 해버리곤 합니다. 예를 들자면 테스트나 타입, 함수형이 그럴까요? 동적 타입 언어의 장점을 잘 모르는 사람들은, 동적 타입은 큰 프로젝트에서는 쓸 수 없다고 그러곤 합니다.

그러니 다양한 경험을 해보세요. 여러 연구에서 다양성이 중요함을 강조합니다. 여성이나 소수자가 뒤섞인 팀은 더 좋은 성과를 냅니다. 비슷하게 바둑만 가르친 학생보다, 바둑과 비슷한 게임 여러 개를 함께 배운 학생이 바둑을 더 잘 둡니다. 하나의 언어만 2년 동안 공부한 사람보다, 두 개의 언어를 각각 1년 씩 공부한 사람이 두 개의 언어를 둘 다 더 잘 합니다. 이를 교육학에서는 교차(interleaving) 연습의 효과라고도 해요.

나에게 익숙한 것에 착 달라붙어 빠져나오지 못하는 현상을 심리학에서는 '고착'이라 불러요. 이에 대해서는 고착에서 빠져나와 창의적 통찰을 얻는 법이라는 글을 썼으니, 읽어보세요!

쓸모와 즐거움을 찾고, 따라가자.

저는 공부에는 두 가지 목적이 있다고 생각합니다. 하나는 쓸모이고, 하나는 즐거움입니다.

사람들은 적성이나 취향이 존재한다 생각하지만, 그게 유전자로 정해지는 것 같진 않습니다. 저는 쌍둥이가 있는데, 동생은 저처럼 코딩을 좋아하지 않거든요.

저는 코딩은 일이라 생각합니다. "나는 코딩이 너무 즐거워!"라는 사람은 많지 않아요. 저만 해도 물리학으로는 못 먹고 살 것 같아서 코딩을 시작했습니다. 에러 속에서 8시간 넘게 "왜 안 되는 거지" 머리를 붙잡고 있는 삶은 고통스러웠고, 즐겁지 않았어요!

심리학자들이 말하길 사람들은 자기가 잘 하는 일을 좋아한다고 합니다. 그래서 꾸준히 포기하지 않고 해나가는 사람들은, 당장은 잘 못하더라도, 장기적으로는 높은 성취를 이루게 되고. 그러면 자기가 하는 일을 좋아하게 된다고 말이죠.

문제는 잘 하기도 쉽지 않고, 잘 하지 못하는데 꾸준히 하기도 쉽지 않다는 거에요.

그러면 다른 방향도 생각해볼만 합니다. 잘 한다의 기준은 절대적이지 않습니다. 내가 잘 한다고 생각하고, 사람들이 멋지고 잘 한다고 해주면 잘 하는 겁니다. 또 사람들이 잘 한다고 해도, 내가 그 말을 믿지 않으면 소용이 없습니다.

그러니 해결책도 여러 가지에요. 치료사들은 선순환에 대해 이야기하고는 합니다.

먼저 나를 지지해주고 응원해주는 사람을 찾는 겁니다. 가장 좋은 방법은 사람들을 도와주는 가치 있는 일을 하는 거에요. 사람들에게 실제로 도움이 되는 걸 만들고, 공유하고, 응원해주세요.

우리는 대단한 실력을 가진 사람만 남을 도와줄 수 있다고 생각하지만, 오히려 남을 도와주면서 배우는 게 더 많습니다. 잘못하고 실수하면 어떨까 걱정된다면 더 열심히 공부하게 되니까요.

다른 하나는 지금 당장 작은 즐거움을 찾는 겁니다. 저에게는 테스트가 그랬습니다. 테스트로 조금씩 하나하나 확인하고 실험하면서 진행하는 법을 배우니까, 문제가 생겨도 빠르게 해결할 수 있게 되었어요. 그러니 좌절도 줄어들고, 하나씩 해결해나가며 즐거워하게 되었지요.

한계를 받아들이면, 더 빠르게 성장할 수 있습니다

이런저런 조언을 했지만, 이 모든 게 효과가 없을 수도 있습니다. 결국 우리의 한계를 받아들여야 합니다.

우리는 자주 욕심을 부리고는 합니다. 모든 걸 잘 하고 싶은 것만 욕심이 아니고요. "내가 지금 하는 일이라도 잘 하고 싶다"던가 "수퍼 코더는 못 되더라도, 취업이라도 하고 싶다" 같은 당연하고 평범한 마음도 그렇습니다.

그런데 진실을 말하자면. 우리가 수퍼 코더라고 생각하는 사람들도 자기 실력이 부족하고 공부를 안 한다고 자책하는 경우가 많습니다. 마치 전교 1등이 하나 틀렸다고 우는 것처럼요.

한국인의 병이라고 생각해요. 트위터만 유독 그런 사람이 많은지 모르겠지만, 불안과 두려움이 사라지는 날은 오지 않을 것 같아요. 코칭을 하다보면 이런 마음의 문제가 학습 전략보다 중요하다 생각이 듭니다.

역설적이지만, 잘 하려 할 수록 공부나 일을 힘들어 하고 지치게 됩니다. 계속 해나갈 수가 없어요. 세상은 넓고 복잡하고, 변합니다. 심지어 인간의 뇌는 얼마 전에 배운 것도 다 까먹습니다. 코드에는 피드백이 바로 옵니다. 안 돌아가고 에러가 나고, 해결이 안 될 때마다 "나는 프로그래밍이랑 안 맞나봐 ㅠㅠ" 하면서 울 수 밖에 없어요. 앨리스 토끼굴에 빠져서, 중요하지 않은 것에 시간을 낭비하게 되기도 합니다.

그러니 거꾸로 생각해보세요. 한계를 받아들인다는 게 성장하지 않는다는 건 아닙니다.

그날 배우고 나아가는 한 걸음 한 걸음에 집중해보세요. 까먹고 망가진 건 복습하고 보수하면 됩니다. 사람의 기억은 까먹고 다시 되새기면서 점점 강해집니다. 그건 멍청한 게 아니고, 자연스러운 겁니다. 우리는 천재가 아니지만, 나아가고 있어요. 천재들만 데리고는 대단한 일을 해낼 수 없습니다.

저는 이 말을 더 좋아합니다.

"평범한 사람들이 모여 함께 비범한 혁신을 만들어내는 것"

추천하는 자료

사례로 알아보는 문제를 효과적으로 해결하는 방법 - 한윤석(코드숨)

링크

질문을 던지면서 문제를 해결해나가는 과정을 자세히 묘사한 글입니다.

문제 상황을 만나면 일단 아는 것과 모르는 것으로 구분해 내야 합니다. 그 다음 아는 것만으로 문제를 해결할 수 있는지 계획을 세워야 합니다. 만약 아는 것만으로 해결할 수 없다면 자료 조사를 통해서 문제를 해결하는데 필요한 자료들을 수집해야 합니다. 수집한 자료들로 다시 계획을 세워보고, 안되면 다시 자료조사를 하고 실행해야 합니다.

2018년, 내가 모르는 기술들 - 댄 아브라모

링크 댄은 리액트 코어 팀의 프로그래머로, 리덕스도 만들었습니다. 이 글에서는 댄이 자기가 모르는 기술들에 대해 이야기합니다. 그는 재미있고 겸손한 사람이에요.

댄은 가상 코딩 인터뷰를 하는 유튜브에 출연한 적이 있습니다. 다음은 한 댓글이에요.

the creator of redux taking so long to center a div gives me so much hope in my skills

삶을 충만하게 만드는 "지속 가능한" 운동 - 멜라니 조이

링크 멜라니 조이는 심리학을 전공한 동물권 운동가입니다. 이 영상은 동물권에 관심이 없더라도 보시면 좋다고 생각해요. 나를 희생하지 않으면서도 가치 있는 삶에서 에너지를 얻으며 살아가는 방법을 이야기합니다.