블로그입니다

10년전 쯤 안정적으로 다니던 회사가 있었다
안정적이란 말은 돈을 많이 받지는 않았지만 심적 스트레스 없고 개인적인 시간이 많았던 곳이였다는 뜻이다
이 회사에서의 일은 재미없었으나 여유 시간이 많아서 나의 개인적인 일을 할 수 있었다
내 개인적인 일이라 함은 코드로 무언가를 만드는것이다
나는 코드를 이용해 무언가를 만드는 작업을 아주 오래전부터 계속 해왔다
작업의 목적은 순수히 100% 내 만족이였다
그래서 누군가의 요구조건을 충족시킬 필요도 없었다
그런만큼 수익을 염두하지 않았던 작업들이다
왜인지는 모르겠으나 나는 무언가를 만들어내는 것을 좋아했다
개발에서의 특징은 무언가를 만들어내는데 있어서 계속 막힌다는 점이 있는데
무언가에 막힐때에 그것이 실제로 가능한 일인지 애초에 불가능한 일을 하려고 노력하고있는지를 알기 어려웠다
때로는 실제로 하고자하는게 불가능한 일인 경우도 적지 않게 있었다
당시 웹은 지금처럼 다양한것들이 가능할 수 없었다
지금의 웹은 단지 "홈페이지"를 넘어서 "애플리케이션"이기도 "게임"이 될수도 있을 정도의 기능을 제공하지만
당시의 웹은 그저 웹페이지에 불과한 수준이였다
이런 제약 때문인지 웹을 만드는 사람은 이 주어진 제약적 환경을 넘어서고자 하는 열망이 있었다
단순히 웹페이지를 넘어서는 형태를 예로 들어보자면 "채팅" "음악플레이어" "영화예매사이트" 와 같은것들이다
지금은 쌉가능한것들이지만 당시에는 이런게 어떻게 하면 가능할지를 개발자가 진짜 스스로 개발을 해서 길을 찾아내야했다
주변에 개발을 하는 사람이 없어서 주제에 대해서 함께 고민할 상대도 없었다
채팅을 예로 들자면 현재에는 웹소켓이라는 것이 있지만 당시에는 웹페이지에서 단말기와 서버가 계속 연결을 맺게하는 기술이 마땅히 없었다
http로 접속을 맺고 끊지 않고 유지하는 방식의 방법이 있긴 했지만 딱히 마음에 드는 방법이 아니였다
그래서 보통 이 시기에 사람들이 선택했던 방법은 웹페이지를 프레임 내에서 새로고침을 하는것이였다
새로고침을 할때에 문제는 화면이 깜빡거리는 효과가 생긴다는 점이 있었다
3초마다 화면이 새로고침 되는 과정에서 깜빡이는 것이다
당시는 이런 상황이였다
꽤나 별로이다
그러던 중 Gmail의 등장으로 Ajax라는것이 개발자들에게 알려지게 됐다
Gmail이 Ajax 기술을 사용해서 만든 대표적인 사이트로 당시 유명세를 탔다
또한 아무나 Gmail계정을 만들수 없었다.
초대장이 필요했고 초대장이 한때는 100달러에 거래되기도 했다
아무튼 당시 나도 Ajax라는걸 접하게 되었는데 이것이 채팅에서 깜빡임을 없애줄 수 있는 획기적인 해결책이 될수 있었고, 이것을 경험했던 나는 너무 기뻣던 기억이 난다
지금은 Ajax는 너무 당연한것이였으나 당시 나에게는 절대로 당연한것이 아니였다
Ajax를 알기 전에는 다른 꼼수적 방법으로 Ajax와 같은 흉내를 내서 채팅에서의 깜빡임을 이미 없앤 상황이긴 했었다
아무튼 이런 다양한 제약때문에 Rich Internet Application 라는 말까지 생겨날 정도였다
이 말은 좀더 풍부한 기능이 제공되어 웹페이지를 넘어서 애플리케이션에 가까운 정도의 웹을 의미한다
현재에는 그냥 당연한 것이 된 그것이다
현재에는 WebAPI의 기능이 막강해졌다
그러나 당시에는 그러지 못했다
그래서 당시 이것의 대안은 ActiveX 였다 RIA를 열망하던 사람들에게 ActiveX 는 굉장히 멋진것으로 다가왔을것으로 생각된다
나 또한 이것에 열광했다
웹에서 절대 불가능한것으로 여겨지던것들을 가능케 해주는것이였기 때문이다
당시 브라우저 점유율의 대부분은 IE가 차지하고 있었고 IE에서는 ajax도 ActiveX를 기반으로 구현되고있던 상황이였다
대표적으로 Flash, Flex, Silverlight 와 같은것들이 있고 이 기술은 대형 웹사이트들에서도 적극적으로 도입했다
나 또한 신나서 이리저리 공부해서 다양한 재미있는것들 만들었다
물론 이때의 작업들도 순수히 내 만족이 목적인 작업들이였다
돈은 더럽게 없었으면서 왜 이리 돈버는데는 게을렀고 그냥 놀기만 좋아했는지 지금도 모르겠지만 지금도 크게 다르지는 않은것같다

사람들은 다양하고 다양한만큼 각자에게 맞는 학습방법이 있을 수 있습니다.
앞으로 이야기 하고자 하는 학습방법도 모두에게 맞는 학습방법이 아닐 수도 있습니다만, 이 방식이 맞을 분들에게는 굉장히 효율적인 방법일 수 있을것이라고 생각합니다.

코딩실력은 무언가를 만들어보면서 막히는 문제를 어떻게 해결할지 고민하고 해결하는 과정속에서 자라난다는 것을 전제로 시작하는 이야기입니다.

"그래서 많이 만들어보면 잘할수 있게됩니다" 이렇게 이야기 하면 꽤 막연하게 들릴수 밖에 없을것 같습니다.
"모르는데 어떻게 만들어?" 라는 생각이 아마 가장 먼저 들수 있지 않을까 생각합니다.
아마도 사람에 따라서 듣는 사람입장에서는 현실성 없는 이상적인 이야기정도로 들릴 수도 있을것 같습니다.

그런데 말입니다.
무언가를 만들어본다는 말에서 "무언가" 라는것은 그게 그 어떤것이여도 상관이 없다는 이야기입니다.
즉 거창할 필요없고 아주 시시한것이여도 상관없다는 의미입니다.
"Hello 라는 이름이 쓰여진 버튼을 만들고 버튼을 눌렀을때 버튼의 색을 노란색으로 바뀌도록 하는 것"을 그 "무언가"라는 이름의 미션으로 정해도 상관없다는 이야기입니다.
지금 이야기한 이 미션은 사람에 따라 누군가에겐 간단할수도, 또는 어려울수도 있습니다.
이것이 어렵다고 생각하는 사람이라면 "눌러도 작동안하는 Hello 라는 이름이 쓰여진 버튼을 만들어보는 것"으로 미션을 축소해서 난이도를 줄여서 해볼 수 있습니다.
"눌러도 작동안하는 Hello 라는 이름이 쓰여진 버튼을 만들어보는 것" 을 할수 잇는 사람이라면,
"눌러도 작동안하는 World 라는 이름이 쓰여진 버튼을 만들어보는 것" 도 해볼 수 있겠지요.
혹은 "Hello버튼을 누르면 World버튼이 생성되도록 만들어보는 것"도 시도 해볼 수 있을지 모릅니다.
만약 이렇게 떠올려 본 미션이 내가 아는 범위를 좀 넘어서는 이유로 방법을 몰라서 어렵다면 안해도 괜찮습니다. 물론 도전해보는것도 좋습니다.
이렇듯 현재 알고있는, 혹은 살짝 내가 아는 범위를 넘어서는 미션들을 생각해볼 수 있는 만큼 다양하게 생각해내보고 그것들을 모두 만들어 보는겁니다.

이렇게 해보기 위해서 자신이 가진 코딩실력과 크게 동떨어져있는 대단한 지식들이 필요한것이 아닙니다.
왜냐하면 이 미션은 스스로가 할 수 있을것 같은 정도의 난이도로 스스로가 고려해서 만든 미션들이기 때문입니다.
물론 이렇게 스스로에 의해 만들어진 미션들이라 할지라도 만들어보기 전에는 쉬울지 알기 어려울 수 있습니다.
그러나 그럴땐 해보다가 어려우면 난이도를 더 낮추면 되는것이지요.

이렇게 스스로 미션을 떠올려보고 만들어보는 과정에서 스스로가 무엇에 어려움을 느끼고 무엇을 모르는지를 명확하게 알수 있게됩니다.
이때 어려움을 느낀 그것들이 무엇보다도 지금 알아야할 학습우선순위의 가장 위에있는 내용들이라고 생각해도 무방합니다.
그리고 이렇게 스스로가 만들어낸 미션에서 막힌 문제를 어떻게 해결할지 방법을 찾아가는 과정에서 진짜 실력이 쌓입니다.
그리고 이렇게 만든 미션들은 스스로의 실력을 고려해서 만든 미션들입니다.
만약 무언가에 막힌다면 스스로가 처한 상황이 어떤상황인지 그리고 무엇을 몰라서 못하고있는건지를 판단하기 수월합니다.
따라서 자신이 처한 문제에 대해 방법을 찾아가는 과정도 스스로의 논리를 통해 접근하기 수월합니다.
이 상황에서는 누군가에게 질문을 하더라도 그냥 단순히 "어떻게하나요" 가 아니라 "이러이러한 이유때문에 무엇이 문제가된다 그래서 이 문제를 해결하기 위한 방법이 필요하다" 라고 자신이 처한 상황을 논리적으로 전달할 수 있게됩니다.
목표를 달성하기 위해 알아야할 것이 무엇인지, 현재 무엇이 부족한지를 명확하게 논리적으로 인지하고있는 것 만으로도 해결에 가까워져 있다고 이야기해도 과언이 아닙니다.

그런데 이 방법에는 한가지 어려운점이 있습니다.
이 방법은 스스로가 해볼만한 주제를 창작해서 스스로에게 부여해서 스스로 해결하는 과정을 거쳐야하는 방법입니다.
따라서 학습자는 이것을 하기 위해서는 능동적이고 자기주도적이여야 한다는 점입니다.
이 방법의 학습효율은 매우 훌륭하다고 생각하지만 절대적으로 자기주도적이고 능동적이여야하는 점이 있기 때문에 이 방법이 모두에게 쉬운 방법이라고 이야기하기는 어려울수도 있을것 같습니다.
일단 스스로를 움직일 수 있을만한 흥미로운 주제를 스스로가 떠올리는 것이 사람에 따라서는 쉽지 않을수도 있습니다.

이 어려운 점을 어떻게 해결해야할까..?
호기심이란건 어떤 계기가 없이 문득 떠오르기도하지만 보통은 그러기 쉽지 않습니다.
그러나 어떤 계기가 하나 있다면 호기심은 거기에서 출발할 수 있습니다.
그럼 호기심을 만들어낼 수 있을 계기가 일단 있어야할텐데요..

화면에 버튼을 하나 만들어서 그 버튼을 잠시 바라보며 생각해보는겁니다.
자.. 일단 버튼을 하나 만들었습니다.
그 다음 무엇을 해볼 수 있을까..
버튼이니까 누르면 어떤 일이 일어나게 해 볼수 있을텐데..
무슨일이 일어나게 해볼까..
생각해보는겁니다.

버튼을 누르면 console 에 hello 라고 출력해본다
버튼을 누르면 버튼의 색을 바꾼다
버튼을 누를때마다 버튼이 커지게 한다
버튼을 누를때마다 버튼이 작아지게 한다
버튼을 누를때마다 버튼이 작아지게하다가 너무 작아지면 버튼이 제거되게 한다
버튼을 누를때마다 버튼의 점점 흐려지다가 아주 흐려지면 버튼이 제거되게 한다
버튼을 누르면 버튼이 사라지게 한다
버튼을 누르면 5초후에 버튼이 사라지게 한다
버튼을 누르면 5초후에 새로운 버튼이 누른 버튼 왼쪽에 생성되게 한다
버튼을 누르면 5초후에 새로운 버튼이 누른 버튼 왼쪽에 생성되게 하고 생성된 버튼을 누르면 5초후에 누른 버튼의 오른쪽에 있는 버튼이 제거되게 한다
버튼을 누르면 버튼의 색을 현재 시간이 밤이면 Black, 낮이면 White가 되도록 해본다
버튼을 누르면 여섯개의 무작위의 숫자가 출력되게 해본다
버튼을 누르면 1에서 10사이의 숫자가 무작위로 하나 출력되게 해본다
버튼의 모양을 토글스위치로 만들고 누를때마다 on off 되게 만들어본다
버튼을 누르면 오늘의 날짜를 출력하도록 해본다
버튼을 누르면 macOS에 폴더마다 생성되는 .DS_Store 파일을 모두 사라지게 만들어본다
버튼을 누르면 컴퓨터 내에 중복되는 파일이 있다면 하나만 남겨두고 지우게 만들어본다
버튼을 누르면 버튼의 색을 현재 실제 기온에 따라 30도 이상의 뜨거운 기온이면 빨간색, 24도정도의 온화한 기온이면 녹색으로 표현되게 해본다
버튼을 누르면 현재시간을 출력하도록 해본다
버튼을 누르면 오늘의 원달러 환율을 출력해본다
버튼을 누르면 어제와 비교해서 비트코인이 얼마나 변동이 생겼는지 출력해본다
버튼을 누르면 오늘의 날씨의 기온을 출력하도록 해본다
버튼을 누르면 사진파일을 선택하는 창이 나오게 한다
버튼을 누르면 사진파일을 선택하는 창이 나오게 해서 파일을 선택하면 사진의 해상도를 구해서 출력하도록 한다
버튼을 누르면 사진파일을 선택하는 창이 나오게 해서 파일을 선택하면 사진을 촬영한 카메라의 모델명을 출력하도록한다
버튼을 누르면 사진파일을 선택하는 창이 나오게 해서 파일을 선택하면 사진을 촬영한 카메라의 현재 중고가격을 출력하도록 한다
버튼을 누르면 사진파일을 선택하는 창이 나오게 해서 파일을 선택하면 사진을 촬영한 카메라 제조사의 현재 주가를 출력하도록 한다
버튼을 누르면 음악파일을 선택하는 창이 나오게 해서 파일을 선택하면 음악의 재생길이를 출력하도록 한다
버튼을 누르면 음악파일을 선택하는 창이 나오게 해서 파일을 선택하면 음악을 재생한다
버튼을 누르면 음악파일을 선택하는 창이 나오게 해서 파일을 선택하면 음악의 음을 그래프로 표현해서 보여준다
버튼을 누르면 음악파일을 선택하는 창이 나오게 해서 파일을 선택하면 노래를 부른 가수의 성별을 판단해서 출력하도록 해본다
버튼을 두개 만들고 A버튼을 누르면 음악파일을 선택하는 창이 나오게 해서 파일을 선택할수 있게 하고 B버튼을 누르면 선택한 음악파일이 재생되도록 한다
이렇게 끝없이 떠올려보는겁니다.
기존의 아이디어에 살을 계속 조금 붙여보는 방법으로 계속 떠올려볼 수 있습니다.
이렇게 떠올려본것은 어려운 미션일수도 있고 수월할수도있습니다.
일단은 자신이 할 수 있을지는 이런 아이디어를 떠올려본 후 그냥 해보는겁니다.
하다가 어려우면 포기하고 미션을 좀 축소시켜서 해보면 되는겁니다.
호기심이 생기기를 바랍니다.
그래야 실행하게 됩니다.

왜 미션을 스스로 생성해내야하는가에 대한 의문을 가질 수 있습니다.
분명 스스로 할거리를 생성해내지 않아도 이런 해볼거리들을 찾을 방법들이 많이 있습니다.
하지만 이 미션들은 나의 관심사에서 동떨어져있거나 내 실력이 고려되지 않은 미션들일 가능성이 높습니다.
나의 상황과 관심사와 동떨어진 주제들이 아무리 중요한 내용이라고 하더라도 동기부여가 되기 쉽지 않을거라는 생각입니다.
자신의 실력이 고려되지 않은 미션을 하게되면 고려되지 않은 만큼 자신의 논리가 문제해결에 개입될 여지가 줄어들어 그만큼 스스로 무언가를 해나가고 있다는 느낌을 받기도 어려울겁니다.

결론..
이 방법은 처음에 이야기했듯 모두에게 효과적인 방법이 아닐수도 있습니다
이 방법은 스스로가 이러한 호기심을 만들어내고 스스로가 스스로에게 미션을 부여할 수 있는 자기가 자기를 주도할수 있는 능동적인 사람들에게 매우 효과적일것이라 생각합니다

실력이 부족한것과 무언가를 만들어 볼 수 있는지의 여부와 관련이 없습니다
실력이 부족하다고 하여 아무것도 만들 수 없음을 의미하는 것이 아닙니다
현재 실력으로 할수 있는 범위 혹은 조금 넘어서는 범위내에서 아주 간단한것이라도 상관없습니다
무언가를 만들어보는 시도를 한다는건 그 과정에서 무언가 막히는 것을 만나게되는 가능성을 만드는 활동이기도 합니다
이 과정에서 진짜 실력이 만들어집니다

간혹 "비동기 함수"라는 말을 듣는경우가 있습니다
그런데 이 용어는 듣는 사람으로 하여금 모호함을 느낄수 있게 합니다
왜냐하면 말하는 사람이 비동기 함수를 어떤 함수로써 정의하고 있는지에 대해 듣는사람은 확신할 수 없다고 생각하는게 논리적입니다

async function test(){}

이 함수는 비동기 함수일까요?
의견A: 비동기라는 의미의 단어인 async가 붙어있기 때문에 비동기함수입니다
의견B: 비동기적 작동을 하는 코드를 포함하지 않은 코드이기 때문에 비동기함수가 아닙니다

말하는 사람은 "비동기 함수" 를 이 두가지 의견중 어떤 생각으로 말했을까요?
"모릅니다.."

모르죠..
따라서 명칭하자면 "비동기 함수" 라는 표현보다는
"코드상 function 앞에 async 키워드 붙이는 함수"
혹은
"코드상 function 앞에 async 키워드가 붙어있지는 않지만 비동기적 작동을 하는 코드가 포함된 함수"
라고 조금 구체적으로 표현하는게 커뮤니케이션에 훨씬 이롭습니다

필요하고 중요하다고 생각합니다
창의력은 길이 없는 상황에 처해졌을때 어떻게 길을 만들어낼지에 있어서 중요하다고 생각합니다
길이 없는 상황은 비단 소프트웨어 개발자들에게만 해당되는 이야기가 아니라 삶을 사는 모든 사람들에게 해당되는 이야기 아닐까 합니다
살면서 문제를 겪는 상황은 누구나 겪으니까요
다른 말로 문제 해결 능력이라고 말할수도 있지요

사례를 이야기해보자면 다음과 같습니다

가령 사이트의 특성상 실시간적으로 화면상의 내용이 수시로 바뀜에 따라 계속 화면을 갱신해 줌에 있어서 성능적 비효율이 존재하는 상황에서 이 문제를 어떻게 해결할지 고민해야 하는 상황이 있다고 할때..
이런 고민에서는 아무래도 창의적인 생각이 필요하지 않을까 합니다.
"계속 DOM에 접근을 해서 갱신을 해주는데서 비효율이 발생하니 따로 메모리상에 DOM과 같은 구조의 데이터를 준비해서 값의 변경시 이 메모리상의 데이터를 바꿔주고 이 모습에서 변경된 부분만 DOM에 반영해줘서 DOM접근을 최소화하는 아이디어는 어떨까?" 라는 창의적인 아이디어가 있었던것이죠.

나도 최근 나름 창의력을 발휘한 경우를 이야기를 해보자면 다음과 같습니다.
이번에 개발중인 게임에서는 맵이라는 개념이 필요했는데 맵데이터를 어떻게 만드는게 좋을지를 고민해야했어요
여기서 맵이란 자료구조의 Map이 아닌 게임에서의 지도를 의미합니다
맵에디터를 따로 만들기에는 손이 많이 가서 떠올린 아이디어가 나름 창의적이였습니다.
그림판을 열고 돋보기로 최대 확대해서, 픽셀이 네모로 보일정도로 확대해서 그냥 픽셀을 찍어서 png로 저장해서 png를 게임에 포함시키면 게임에서 구동중에 맵데이터로 변환하는 방식입니다
픽셀 하나당 게임상의 오브젝트이며 색상에 따라 오브젝트의 속성을 결정하는 방식으로 문제를 해결했습니다
이렇게 했을때 얻은 장점은 맵데이터의 제작수고를 덜고, 덤으로 맵데이터의 용량도 작게 만들수 있었죠

이것을 하는 과정에서도 중간중간 또 창의력이 필요했던 상황들이 있었는데요
처음의 아이디어는 png를 기반으로해서 맵데이터에 해당하는 json을 생성해서 json을 게임에 포함시키는 방법이였습니다.
그래서 png를 맵데이터로 변환하는 툴이 필요했고 이것을 커맨드라인인터페이스로 툴을 사용하는것이 편리하겠다고 생각했습니다.
그런데 png를 맵데이터로 변환하는것은 이미 WebAPI를 이용해서 만들어둔 상황이고 이것은 웹브라우저에서만 작동하죠..
근데 이것을 실행하는 환경이 커맨드라인인터페이스가 되면 웹브라우저환경이 아니기 때문에 WebAPI를 사용하는 코드가 작동될수 없습니다.
이 상황에서 길을 찾아야지요.
어떻게 커맨드라인인터페이스에서 WebAPI를 사용할수 있을까?
떠올린 방법은 퍼펫티어를 헤드리스로 구동해서 크로미움에서 해당 코드를 구동시키면 WebAPI사용이 가능하고 그렇게 처리된 결과를 얻어내면 되는것이였죠.
그렇게 해서 해결했습니다.

그런데 두번째 문제가 발생했습니다
변환된 맵데이터가 너무 큰것입니다
결과적으로 게임의 용량이 커졌죠
1000바이트였던 png를 맵으로 변환시키니 1MB가 되는 상황이였습니다
또 생각을 해야죠.. 아이디어를 만들어야해요 창의적으로..

그래서 떠올린 아이디어..
png를 변환시켜서 게임에 넣는게 아니라 그냥 png자체를 게임에 넣고 게임 구동중에 맵데이터로 변환하게끔하자는 생각이였습니다
png데이터 자체가 꽤 작고 단순하기 때문에 맵데이터로 변환하는것 자체는 게임이 WebAPI를 사용활 수 있는 환경이였고 큰 성능이 필요한 부분이 아니여서 별 문제 없는 상황이였습니다

세상에는 많은 솔루션들이 있죠.
개발자들입장에서는 그 솔루션은 보통 라이브러리나 프레임웍형태로 접하게 되고 이것들의 시작은 나름의 불편함과 고충의 해결을 위함이였지 않을까 합니다
그렇게 해서 대단한 라이브러리들이 탄생했고 현대의 개발자들은 누군가의 창의력의 산물의 도움을 받으며 이들도 또한 창의력을 발휘하고 있는것이죠

개발자 뿐 아니라 모든 사람에게는 창의력이 필요합니다

프로그래밍을 처음 시작하는 단계에서는
스스로만의 생각으로 무언가를 해냈다는 경험을 해서 성취감과 재미를 느끼는 것이 중요합니다
하지만 입문 초반에는 프로그래밍 언어라는것을 공부하는것으로 대부분의 시간을 씁니다

그리고 그 공부의 범위는 생각보다 넓게느껴집니다
단지 느낌이 아니라 실제로 많습니다
그런데 반가운 소식이 있는데요 이 많은것들 중에는 선택적요소가 상당수라는점입니다
선택적요소란 알면 편하고 몰라도 좀 불편할 뿐 뭔가를 해내는데 문제는 없는 요소입니다
어떤것은 몰라도 불편하지도 않을 것들도 많이 있습니다

그런데 생각해봅시다
프로그래밍을 처음 입문해서 아무것도 할 줄 모르는 상태에서 간단한것이라도 할줄 알게 되는 것과 더 편하게 다양한 방법으로 할수 있게되는 것 둘중 무엇의 가치가 클까요?
못하는 상태에서는 편하게 하는것의 가치보다 할줄 알게되는 것의 가치가 훨씬 큽니다
간단한 것이라도 할 줄 알게되서 해내는 경험을 하는게 더 중요합니다

이런점에서 처음에는 무엇을 공부하고 무엇을 공부하지 않을지 우선순위를 잘 정해서 해 나가는것이 너무 중요합니다

하지만 입문자 입장에서는 무엇이 중요한지를 판단하기 어렵습니다
그래서 제가 제안해드리고자 합니다
이 제안은 프로그래밍을 처음 입문하고 아직 스스로 뭔가 생각대로 코드를 만들어낸 경험을 못해본 분들을 대상으로 합니다

이 글에서는 자바스크립트 학습에 있어서 학습범위를 줄이는 방법에 대해 안내하고자 합니다
학습범위를 줄인다고해서 덜 할수있게 되고 그런게 전혀 아닙니다

---------------------
자바스크립트에서는 변수를 만드는 키워드가 세개가 제공되죠
let, const, var
값을 담는 변수를 준비하는 키워드들입니다
이것들은 서로 사용상 조금씩의 차이점들이 존재합니다
이 모든걸 다 익힘으로써 이 차이점들에 대해 다 숙지할 필요가 없습니다
let 하나만을 쓰도록 하고 let의 특징만을 알아두는것 만으로도 초반에 다양한 프로그래밍 경험해보는데에 있어서 전혀 문제없습니다.
let 하나만 선택하게 될때 몰라도 되는것들은 var와의 차이점, 특히 var에서의 호이스팅과 스코프의 특성들에 대해서 알 필요가 없게되고 물론 const와의 차이점도 알 필요가 없게됩니다.

---------------------
자바스크립트에서는 함수를 준비하는 방법이 아래와 같이 나뉠 수 있습니다
/*1*/ let ff = function(){}
/*2*/ let ff = ()=>{}
/*3*/ function ff(){}

셋중 1번의 방식만을 습득합니다
1번의 방식만 선택하면 몰라도 되는것들은 당연 2, 3번과의 차이점이며 차이점에는 2번과의 차이점은 생성자로써의 사용가능여부, this, arguments등등에 대한 이야기.. 3번과의 차이점은 호이스팅, 스코프에 대한 특성들이 있습니다.
또한 1번의 방식은 변수에 12, "hello"와 같은 데이터를 담는것처럼 함수도 데이터로써 취급해서 변수에 담을 수 있다는 감각을 익힐 수 있게되어 생각을 다음과 같이 확장 할 수 있습니다

함수도 12와 "hello"와 같은 데이터라면
console.log(12) 와 console.log("hello") 처럼 어떤 함수의 매개값으로 넘기는것이 가능한것 처럼
console.log(function(){}) 처럼 함수도 매개값으로 넘기는것이 가능하겠구나~ 라는 생각으로 확장할 수 있는 기회가 됩니다

---------------------
자바스크립트에서 클래스를 준비하는 방법도 함수를 준비하는 방법의 차이가 존재하는 것 같은 차이가 존재합니다
/*1*/ let Hello = class {}
/*2*/ class Hello {}
둘중 1번의 방식을 습득합니다
1번을 선택한 이유는 함수준비하는 방법에서의 이유와 같습니다
class{} 또한 값으로써 취급한다라는것을 받아들이기에 용이하며 특별히 2번방식으로 했을때 스코프와 호이스팅이 어떻게 이루어지는지에 대해 따로 알아볼 필요가 없어집니다

---------------------
자바스크립트에는 TDZ, 호이스팅이라는 개념이 있습니다
그러나 윗 글들에서 선택을 배제함을 통해 호이스팅을 몰라도 되는 상황을 만들었습니다
그리고 애초에 변수 선언 전에 접근하고자 하는 시도 자체를 안하면 TDZ라는것에 대해 신경쓰지 않아도 됩니다
console.log(data);
let data=123;
이와 같은 시도 하지 말자는겁니다.

---------------------
자바스크립트에서는 비구조화할당, 스프리드, 옵셔널체이닝, 템플릿리터럴, 널리시등등의 문법이 제공됩니다
알면 편합니다. 그러나 몰라도 문제 없습니다. 불편할뿐입니다.
모른다고해서 뭘 못하고 그러진 않습니다

---------------------
실행컨텍스트, 클로저라는 개념이 존재합니다
이것들에 집중하는 대신 스코프에 대해 집중합시다
스코프를 알고나면 이것들은 당연한 이야기가 됩니다
그리고 스코프의 이해는 윗 글들에서 let 하나만 사용하고 함수와 클래스선언에 대한것도 let에 담는것으로 상황을 제한해둔 덕에 훨씬 쉬워지게 되었습니다
let 의 스코프 특성에 대해서만 이해하면 됩니다

---------------------
자바스크립트에는 상황에 따라 다른코드를 실행할 방법들이 존재합니다
if, 삼항연산자, switch 등이 존재 하지만 이 중에서는 if 하나만 익힙니다.
if 하나로 충분합니다

---------------------
자바스크립트에는 반복기능을 제공하는것들이 많이 있습니다
for, while, do while 또한 Array 객체에 붙어있는 다양한 배열반복 함수들.. forEach map filter등등..
이중 while 하나만 알아도 상관없습니다
while 하나로 그 외의 것들이 모두 커버됩니다
물론 상황에 따라 좀더 편한게 있을수도 있지만 처음에 할줄 모를때는 편한것의 가치보다 불편하게라도 할줄 알게되는 것의 가치가 크며 사실상 while 하나로 모든걸 다 할수 있습니다
그럼 왜 for가 아닌 while인지에 대해 이야기해보자면 "만약 비가오면 우산을 쓰자" 와 같은처리를 하기 위해 사용하는것이 if 라는것입니다.
if(비오면){우산쓰기} 와 같은 모습의 코드가 만들어지죠
while은 코드의 모습이 if와 완전동일합니다
while(비오면){우산쓰기}
우리는 if는 이미 사용하기로 결정했습니다
그렇다면 if를 하는 김에 모양이 if와 똑같은 while를 선택하는게 아무래도 배움의 부담을 줄일수 있겠지요

---------------------
자바스크립트에서는 객체를 생성하는 방법이 다양하게 존재합니다
여기서 이야기하는 객체 생성이란 new 키워드를 이용해서 생성하는 객체입니다
이 객체생성에 대한 내용은 안보도록 합시다
일단 안봐도 괜찮습니다
초심자를 조금 지난 분들이라면 본다 하더라도 함수를 생성자로써 사용하는 방법은 사용하지 않도록 합시다
대신 class문법을 사용합니다
class문법을 사용할때 알지 않아도 되는 내용은 prototype을 직접 준비 하는 등의 자바스크립트의 특성을 재치있게 응용해서 객체지향을 직접 개발자가 구현하는 방법에 대해 신경 쓸 필요가 많이 줄어듭니다
class를 쓰는것이 곧 그것들을 하는셈입니다.

---------------------
자바스크립트에는 엄격모드란게 있습니다
엄격모드일때와 아닐때의 작동의 차이가 있습니다
그냥 항상 엄격모드로 쓰면 이 차이를 모두 알 필요가 없어집니다

---------------------
자바스크립트에는 값을 비교하는 방법으로 ==와 ===가 있습니다
===는 내 생각과 조금 더 가까운 결과를 내줍니다
==는 특성을 모두 알아야 오해없이 쓸수 있다는 어려운점이 있습니다
===하나만 알면됩니다

---------------------
자바스크립트에서는 문자열 "5" 를 5로 바꿔주는 방법이 다양합니다
+"5" ~~"5" Number("5") "5"-0 "5"*1 등등..
이중 아무거나 하나 사용하면 됩니다
모두 알필요 없습니다

---------------------
자바스크립트에서는 비동기코드를 예쁘게 만들어주는 수단들이 존재합니다
여기서 예쁘다는것은 프로그래머가 코드를 보는 입장에서 느끼는 것입니다.
자바스크립트에서는 비동기코드를 만들때 코드의 복잡도가 올라가는 경향이 있습니다.
이것을 개선해주기 위한 수단으로써 Promise, async/await, generator등이 존재하는데요
그냥 이것들 모두 사용하지 않고 코드를 예쁘게 만드는 것을 포기합시다
좀 농담같은 말이지만 지금 이 전체적 이야기의 맥락에서 볼때 코드를 예쁘게 만드는것은 선택사항으로 구분짓는것이 어울립니다
예쁘게 만들지 않는다면 선택할 수 있는 방법이 콜백함수를 사용하는것인데 이것의 단점은 코드가 복잡해진다는 것입니다
그래도 불편한 것보다 할줄알게 되는것이 더 우선순위에 있다는 점과 특히 이 비동기코드를 예쁘게 만들어주는 방법들은 일단 예쁘지 않은 코드에 고통받아본 경험이 있는 상태에서 받아들일때 그 필요를 더욱 공감할 수 있기 때문에 배제했습니다.
초심자를 조금 지난 분들이라면 Promise에는 then 이라는것이 있습니다. 이 then을 사용하는 대신 async/await 를 사용합시다.

---------------------
에러처리를 하는 방법이 제공됩니다
try{}catch{} 라는것인데
알면 좋습니다
그런데 모른다고해서 막 뭘 절대 못만들고 그러는건 아닙니다

---------------------
이외에 더 있을 수 있는데 우선 생각나는 것들에 대해 이야기해봤습니다
이 이야기는 앞서 언급했듯 대상자가 정해져있습니다.
스스로 생각한대로 무언가 만들어가는 경험을 못해본 분들이 최소한의 것만 익히고 무언가를 해보는데에 있어서 필수적인 내용들만을 선정한겁니다.
이것들을 익히고 무언가를 해 나가는 경험을 해 나가게 되면 그때 스스로에게 무엇이 필요할지 무엇을 공부해야할지에 대한 판단을 어느정도는 스스로하는것이 가능해질 수 있습니다
또한 위에 선정한 필수요소들만으로 다양하게 만들어보면서 익숙해지고 나면, 그 외의 배제되었던 것들을 배우는 것은 처음에 아무것도 할줄 몰랐을 때보다 여유가 생겨서 그걸 배우는게 큰 문제가 아니게 됩니다.
어느정도 기본 개발의 감이 생긴 시점에서 부족한 부분을 채워넣는것은 하려면 얼마든 할수 있는것이 되는것입니다.
처음부터 한번에 모든걸 다 잘할 수는 없습니다
우선순위를 정해서 먼저 필수적인것을 익혀서 뭐라도 할줄아는 상태가 되는게 중요합니다.

자 공구함이 하나 있습니다
이 공구함 안에는 모종삽, 숫가락, 분무기, 가위등이 담겨있습니다
각각의 사용법과 용도가 다르죠

그리고 여기에 A, B 두 사람이 있습니다 
두 사람 모두 어떤 이유에서인지 이 공구함의 공구들의 사용법을 배우려고 합니다

A는 공구의 사용법을 배워서 꽃가게에 취직 하고자 합니다
B는 공구를 사용해서 꽃을 심고자 합니다.

A의 상황을 먼저 한번 보도록 하죠
A는 취업을 위해서는 면접을 봐야합니다
면접시 면접관이 공구 사용법에 대해 다양하게 물어볼 예정입니다
그래서 A는 다양한 공구사용법들을 미리 숙지해둬야합니다

B의 상황도 봅시다
B는 꽃 심기가 취미입니다
그래서 B의 목적은 꽃 심기입니다
B에게는 꽃을 심는 과정에서 흙을 파야할 일이 있습니다
다양한 공구가 공구함에 들어있지만
흙을 파기 위해서 모든 공구의 사용법들을 숙지해야할 필요는 없습니다
모종삽이나 숫가락으로 흙을 팔 수 있겠죠
이 두개의 사용법을 모두 알아야할까요?
그럴필요도 없죠 둘중 하나만 사용할줄 알면됩니다
적당히 마음에 드는것 선택하면 됩니다
왠만해서 둘중에 하나만 쓰게될겁니다
저는 모종삽이 어울려보이네요
궂이 앞으로도 숫가락이 필요할것 같지는 않습니다
뭐 만약에 필요한 상황이 생기면 그때 숙지하면 되는것이지요
결과적으로 B는 배워야할 것의 양이 줄어들게 되었고
모종삽 사용법하나 익혀서 모종삽을 계속 쓰다보니 결과적으로 흙파기 고수가 됐어요
하지만 여전히 숫가락 사용법은 모릅니다

공부의 목적이 취직이라면 어쩔 수 없이 A가 했던 것 처럼 가급적 다양하게 숙지해둬야합니다
그러나 과정이 없이 다양하게 숙지한 상태가 되는것은 있기 어려운일입니다
결국에는 B가했던것과 같은 경험들을 많이 겪으면서 이를 거쳐서 다양하게 아는 상태가 될수있는거죠
B가 했던 방법에서 주목해야할 것은 최대한 선택적인 것들은 배제한다는 것입니다
모종삽과 숫가락중 모종삽하나만 선택했고 이것에만 집중했죠
모종삽으로 흙파기 고수가 되면 그때는 여유가 생겨서 숫가락은 뭐 언제든 알고자 한다면 알수있는것이 되는겁니다
그러니까 처음부터 모종삽, 숫가락, 가위, 분무기 모두 익히는데 열을 올릴 필요가 전혀 없습니다
중요한건 필수적인것만 딱 익혀서 다양한 사용을 해보는겁니다

여기서 중요한게 계속 다양하게 사용해보는 경험을 하는게 너무 중요한데요
자주 써야 익숙해진다는건 그냥 누가해도 당연한 말이죠..
B의 경우는 꽃 심기가 취미라고 합니다
그러다보니 자주 심게되었죠
그런데 하면서 계속 막혔다고합니다
막혔다라는건 물음표(?) 가 생겼다는거죠
알아야할 주제가 만들어졌다는 이야기입니다
계속 하다보니 모르는게 생기고, 모르는게 생기면 하고자 하는 일을 못하고
그러면 그것을 알게된다는것은 하고자 하는 일을 할수있게 된다는 의미가 생기다보니
더 알고싶게 되었고 그러다보니 결국알게되고..
이게 반복되다보니 결국 잘하게 되었다는 이야기입니다.

A의 경우는 B의 경우처럼 꽃심기가 취미는 아닙니다.
A의 목표는 취직입니다.
사실 목표가 취직이라하더라도 결국 목표가 취미였던 B가 했던것과 같은 과정을 피할 수는 없습니다
B가 새로운 지식을 만난 계기는 대부분 꽃을 심다보니 몰라서 막힌것이 계기가 된 경우들입니다
그러나 B처럼 꽃심기라는 활동을 하지 않으면 막힐일이 없습니다.
그래서 알아야할 것이 딱히 사실 없죠.
알아야할 것은 책을 넘길때 그때 있게될 뿐입니다.

책을 넘겼을때 그 지식이 거기에 있던 이유는 A가 원했기 때문이 아닙니다
그냥 그게 거기에 있었기 때문입니다
이것에 대해 A의 알고싶은 마음은 어느정도일까요
B가 자신의 프로젝트에서 막혀서 모르면 앞으로나아가지 못할 그것을 알고싶은 마음의 크기와 비교했을때 어떨까요
사실 이 마음의 크기란건 사람마다 각자의 마음가짐과 가치관에 따라 너무나도 다를것이라 뭐라고 말하기는 어려운 부분인것같습니다

그러나 내가 A였다면 사실 그 지식이 뭐가됐던 그렇게 중요하지는 않을것같습니다. 그 지식을 아는것보다 취직을 하는것이 더 중요하다고 생각할 것 같습니다.
내가 B였다면 그 지식을 아는것이 자신의 취미생활의 질을 더 높여주는 큰 힘으로 생각될 것 같습니다.

내가 좋아할 때 잘 할수 있습니다

사실 이 글은 효율적으로 학습하는 학습전략에 대해 이야기하고자 했는데 결국 좋아하는 사람이 잘하게된다라는 진리를 말하는것으로 흘러가게 되었습니다

토이프로젝트에 대해 이야기 하기전에 나 나름의 정의를 내려보고자 한다.
토이프로젝트는 아무 의무도 가지지 않고 재미, 호기심을 기반으로 해보는 말 그대로 장난감 같은 프로젝트이며 이 재미와 호기심이라는 감정은 어떤 아이디어에 기반한다라고 정의해보고자 한다.
이 정의는 내 정의이고 사람마다 다를 수 있으며 아래 이야기는 이 정의를 기반으로 진행한다.
첫번째 어려운점
앞에서 단어 뜻을 정의했듯이 나는 토이프로젝트는 재미, 호기심이 발화점이 되어 시작될 때 토이프로젝트라는 단어가 가장 어울릴것이라고 생각하고 이상적이라고 생각한다.

그런데 "코딩을 잘 하려면 토이프로젝트를 해보세요" 라는 말이 좀 어느정도 "밥을 먹고 바로 누우면 건강에 안좋습니다"같은 상식적인 내용이 되어 보통 어렵지 않게 들을수 있는 말이 되었다.
그래서 이 의미로써, 즉 코딩학습측면에서 토이프로젝트를 시작하고자 하는 경우들이 없지 않을것이라 생각한다.
이 때에는 내게 해보고싶은 것이 생긴 것이 토이프로젝트를 하게 된 동기가 된 것이 아니라 "토이프로젝트를 해야한다"라는 생각이 동기가되는것이다.
이렇게 토이프로젝트를 해야한다는 것 자체가 동기가 될때는 "사실 정작 해보고싶은게 있지는 않다라는 것" 일 가능성이 높다는 것이다.
해보고싶은 무언가가 먼저 있고 이것을 통해 재미와 호기심을 느끼게 된것이 동기가 된다라는 나의 토이프로젝트에 대한 정의를 반하게 되는 모습이다.

이는 토이프로젝트라는것을 해야한다는 사실이 먼저 미리 정해진 상황이다.
근데 토이프로젝트 주제가 없는 상황인거다.. 그래서 이런 상황에서 토이프로젝트로 할것을 생각해내야한다라는 웃지못할 상황이 만들어진다.
할 일이 있어서 그 일을 하는것이 아니라 일을 하긴 해야하는데 정작 할 일이 없어서 뭘 할지를 억지로 떠올리는 상황을 만들어버리는 셈이다.

애초에 없던 호기심, 흥미들을 억지로 만들어내는건 쉽지 않은 일이다.
그래서 흔히들 손쉽게 선택할 수 있는것은 "클론코딩" 이란것이다.
이미 만들어져있는 어떤 결과물을 모방해서 똑같이 만들어보는 활동이다.
물론 이것을 하며 가질 기분은 사람마다 다를것이다. 설령 할게없어서 클론코딩을 선택했다 하더라도 하는 과정에서 알지못했던 재미를 만날수도 있다.
하지만 그러지 못할 가능성도 존재한다.

계속 재미 흥미 호기심을 강조하는데.. 재미 없으면 안되나?

안된다고 생각한다.
재미없으면 안하게될거니까.
재미, 호기심과 같은 동기가 중요한 이유는 사람은 자연히 편한것 관심있는것 좋아하는것으로 손이 가고 생각이 오랜시간 머물기 마련이다.
그리고 무엇보다 내 정의에 따르자면 재미없으면 토이프로젝트라고 부를 수 없다.
두번째 어려운 점
프로젝트라는것은 아무리 토이라고 하더라도 시작이 있으면 끝이 있기 마련이다.
그런데 무언가를 시작해서 끝을 낸다는건 쉬운일이 아니다.
왜 이게 쉽지 않은 일인지에 대해서는 사람의 심리는 사람마다 다르고 복잡한것이라 뭐라고 딱 무자르듯 정의하기 어려울 것이다.
그럼에도 이유를 나름 생각해보자면 정말 많은 이유가 있겠지만 "무언가 쓸모있는것을 만들어야한다" 라는 생각이 있다면 부담으로 작용될 수 있고 이 부담은 실행을 소극적이게 만들지 않을까 한다.
과정은 즐거워야 한다. 그래야 토이프로젝트다. 하지만 어떤 의무가 주어지면 즐거움보다는 부담이 클 수 있고 그래서 안하게되기 쉽다.
내가 정의한 토이프로젝트는 의무를 가지지 않는다는 것에도 반하게되는 모습이다.
세번째 어려운 점
코딩을 해서 무언가를 만들어내는 형태의 프로젝트의 특징은 작업을 할수록 기존에 만들어진 코드에 의해 앞으로의 일의 복잡성이 높아질 수 있다는 점이 있다.
토이프로젝트의 규모가 클수록 코드의 복잡도가 올라갈 가능성이 높고 복잡해진 코드에는 다시 손이 가기 어렵다.
그래서 결국 안하게되는 효과가 생긴다..
물론 프로젝트가 진행되어가도 코드의 복잡성을 최소화할 수 있는것이 이 분야에서의 중요한 능력이기도 하다.
그리고 복잡한 코드를 복잡하지 않도록 만드는것에서도 재미포인트를 찾을 수 있으며 이것이 가능한 경우라면 비교적 큰 규모의 토이프로젝트를 해보는것도 나쁘지 않다.
그러나 이게 어렵다면 거창한것 만드는것이 아닌 한두시간안에 끝을 볼 수 있을정도의 작은 규모의 것들을 많이 만들어보도록 하자.
그래서 어쩌라고
토이프로젝트에서 가장 중요한건 정의에서도 말했듯 재미이다
즉 심신의 안정이다.
이거 하면서 스트레스받으면 절대 안된다.
토이프로젝트는 말그대로 장난감을 가지고 "노는" 활동이여야한다.
애써 인내하고 노력하는 활동이 아니라 편하고 즐겁기위해 하는 "노는" 활동이여야 된다.
그러니까 재미를 느낄 무언가가 없는 상황이라면 그냥 안하는게 낫다.
재미가 아니라 실력을 늘려야한다는 의무를 가지게 되는 순간부터 토이프로젝트라는 이름이 안어울리게 되는것이다.

재미와 연결지을 무언가가 없는 사람은 토이프로젝트를 못하나?
어렵다고 생각한다.
이건 사람의 성향의 문제인것같다.
관심사가 아닌데 관심을 가지기는 어려운거다.

그럼에도 토이프로젝트를 실력향상을 목적으로 하고자한다면 해야할 그 미션을 최소화하는것이 좋다.
거창한것 만드는것이 아닌 한두시간안에 끝을 볼 수 있을정도의 작은 규모의 것들을 많이 만들어보도록 하자.
실력은 실제로 무언가를 만들어가는 과정에서 막히는 것을 해결할때 쌓인다는것은 내가 확신하는 부분이다

아직 앱을 만들 실력이 없다고 스스로 생각한다.
그래서 시작을 안한다.
대신 공부를 한다.
그리고 공부를 하면서도 항상 실력이 없다는 생각은 품고있는다.
아무래도 공부가 쉽진 않을테니 이런 생각이 더 들기 마련일것이다.
그래서 계속 공부를 한다.
공부만 한다.

이것이 앱을 못만드는 이유다.
만들기 시작을 안했기 때문이다.

그럼 반문할 수 있다
"모르는데 어떻게 만들어?"
이것에 대한 대답은 다음과 같다
"개발은 모든것이 해결되어있는 상태가 아닌 해결해야할것들이 쌓여있고 앞으로 어떤 문제를 만날지 모르는 상태에서 만나게 될 문제를 해결해 나가는 것이다"
그러니까 하면서 계속 모르는게 생기기 마련이고 그때마다 알아가면서 만들어가는것이다.

복권에 당첨이 못되는 이유는 복권을 안샀기 때문이다.
앱을 못만드는 이유는 앱만들기를 시작을 안했기 때문이다.

Just Do It