코딩교육 어떻게 할 것인가?

코딩 교육이 최근 열풍처럼 번지고 있다. 많은 사람들이 코딩 교육에 대하여 이야기 하는데 이걸 좀 생각해보고 싶다.

보통 아래와 같은 이야기들을 많이 한다.

1. 논리력, 사고력, 문제해결력을 향상시켜야 한다.
2. Computational Thinking 을 배우는 것이 중요하다.
3. 창의력을 중심으로한 교육이 되어야 한다.

모두 맞았어요 같은 뻔한 소리는 하고 싶지 않고 오히려 모두 틀렸다고 생각한다. 이유는 한가지인데 이미 이전에도 코딩 교육은 있었다. 외국의 케이스와는 매우 다르지만, 우리나라 같은 경우에는 컴퓨터 학원이 엄청나게 유행을 탔던 적이 있다. 15년정도 전까지도 우리나라에는 컴퓨터를 배우러 학원을 가는 학생들이 많았다. 가서 뭘 배웠냐고? 주로 GW-Basic 을 배웠다.

코딩 교육 새롭지 않다

물론 현대 개발 언어와는 하늘과 땅 차이가 난다고 해도 과언이 아니지만, 어찌됬던 그 당시에도 GW-Basic 으로 상당히 많은 것들을 만들 수 있었다. 주로 구구단으로 시작했고, 별표(*)로 피라미드나 마름모 꼴을 만드는 것과 같은 간단한 알고리즘 구현을 목표로 공부했었다. 그렇지만 나는 빌게이츠가 될 수 없었다.

좀 더 자세하게 이야기해보고 싶다. 베이직으로는 단순 별표 아트에서 넘어가 원을 그리거나, 상자 등 간단한 그림을 코딩으로 구현하는 데까지 해보았다. 당시 다니던 학원에서는 GW-Basic 만 가르쳤고, 다른 학원으로 옮겨서는 C 를 배웠다. (C++ 이 아직 대세가 되기 전 시절로 기억한다.) 어린 시절에는 사실 왜 해야되는지도 모르면서 그냥 하라니까 배웠던 것 같다. 데이터베이스를 만드는(!?) 수업을 들었던 것 같은데, 내가 할 수 있었던 건 그저 선생님이 주신 코드를 열심히 배껴쓰는 것 뿐이었다. 어쨋든 꽤 열심히 했었고, 재밌었지만 나는 역시 빌게이츠가 될 순 없었다. 뭘 만들어야 겠다는 생각도 못했지만, 그걸 서포트 해줄만한 사람도 없었다. 물론 게임을 만들고 싶어하긴 했지만, 딱히 그걸 코딩으로 시작할 엄두도 안났다. 대신 RPG 쯔꾸르 게임 제작엔진툴로 자작게임을 만들곤 했다.

나는 GW-BASIC 을 통해서 논리력이나 창의력 이런걸 배웠다고 생각하진 않는다. (툴을 사용하긴 했지만) 게임을 만들었던 것은 그냥 내가 하고 싶은 것이었었고, 투자할만한 시간과 열정이 있었기 때문이다. 코딩을 배웠다고 해서 없던 창의력이 생겨나지도 않았고, 컴퓨터적인 생각? 그런건 지금이나 그런가보다 할 뿐이지, 컴퓨터의 작동원리 같은 걸 초등학교 2-3학년이 쉽게 이해할리도 없었다. 코딩을 배운다고 해서 문제해결능력이 갑자기 생겨나지도 않는다. 물론 Basic 코드를 디버깅 하는 기본적인 방법이야 알게 되었지만, 그걸 다른곳에 적용한다는 것은 또 다른 이야기였다.

코딩은 왜 배워야 하는가?

회사를 그만두고 창업 전서에 뛰어든지 4년. 여러군데서 발표할 기회가 있는데 그럴때 나는 주로 WHY - WHAT - HOW 세가지만을 이야기하곤 한다. 가장 많은 시간을 쏟고 중요하게 생각하는건 WHY. 발표자료 분량을 봐도 WHY 가 약 50%, WHAT 이 35%, HOW 는 15% 정도를 차지한다. 왜 해야하는지 이유가 타당하다면 뭘 해야할지는 명확해지고, 어떻게 해야할지는 딱히 중요하지도 않다. (적어도 사업을 시작할때는 말이다.)

그럼 코딩은 왜 배워야 하는가? 논리적 사고? 컴퓨테이셔널 싱킹? 창의력? 이런건 결코 코딩을 좀 배운다고 해서 생겨나지 않는다. 오히려 이러한 것들을 코딩을 하기 위해서 필요한 요소들이지, for 문으로 구구단을 만들어본다고 해서 갑자기 툭 튀어나오지 않는다는 말이다. 물론 도움이 되는 것도 사실이겠지만 이런걸 목표로해서 코딩을 하자고 이야기하는 것들은 결코 아니라고 생각한다.

내 생각엔 이렇다. 현대 사회는 날이 갈수록 세분화되고 있고 복잡해지고 있다. 작은 음식점이라도 하나 운영하려고 하면, 기본적인 제무재표 읽는 법이라든지 세법, 재고 관리, 고객 관리, 마케팅 등등.. 배워야 할것이 정말 수도 없이 많다. 게다가 각 산업은 유사한 팩터가 많긴 하다고 해도, 각자의 특성에 따라 그 세부사항은 매우 달라지기 마련이다. 병원 약품의 재고와 장난감 가게의 재고를 어떻게 같이 취급할 수 있겠는가.

따라서 필요한 것은 만들어 쓰진 않더라도 용도에 맞게 수정해서 사용해야 할 필요성이 생기고 있는 것이다. 그러면 내가 하려던 일이 편리해지는 것은 물론이요, 부작용으로 해당 서비스의 판매도 이루어지게 되는 것이다. 소프트웨어 개발에 도움을 주는 소프트웨어는 무척이나 많은데 이러한 것들이 어느날 갑자기 우리 이런걸 만듭시다 하고 만들었을 것 같은가? 그렇지 않다. 개발자들이 업무를 하는 도중에 불편한 것들을 직접 개선시키는 과정에서 태어난 부산물이다. 개발자들이 느끼는 불편함들을 개발자들이 고쳐나가는게 당연하다고? 그렇다면 이러한 것은 모든 분야에 적용할 수 있다.

코딩교육에서 뭘 배워야 하는가?

결국 우리가 코딩을 배워야 하는 이유는 코딩 자체로 얻을 수 있는 어떠한 편익이나 능력 때문이 아니라 무엇을 만들때 필요하기 때문이다.

재고 관리 시스템의 이러이러한 면이 불편해서 개선해야겠다. 그러니 저러저러한 것들을 배워서 이러이러한 부분을 수정해야겠다.

라고 생각하는 것이 매우 자연스러워진다. Scratch 를 배우고 Javascript 를 배워야 하는 것이 당장 취직해서 SI 산업에 일꾼이 되기 위해서가 절대로 아니라는 뜻이다. 우리는 무엇인가를 만들기위해서 코딩을 배워야 한다.

무엇인가를 만드는 과정은 결코 간단한 것이 아니다. 우선 기본적으로는 개발 언어를 배워야 한다. 무엇을 만들고 싶어도, 그것이 어디까지 가능한지에 대해서 개발 지식이 없는 사람은 가늠할 수 없기 때문에, 우선은 컴퓨터가 어떻게 작동하는지 까지는 아니더라도 (이러한 교육 또한 필요하지만 너무 갈길이 멀다. 이건 확신컨데 욕심이다.) 구구단을 만들기 위해서는 어떠한 문법이 필요하다 하는 것과 현재 인터넷이나 컴퓨터의 대략적인 구동 형태는 알아야할 필요가 있다. 예를 들어, 웹서비스를 만들기위해서는 http request / response 의 원리까지는 몰라도 그런것이 있다 정도는 알아야 하는 것이다.

두번째로는 무엇을 만들것인지 배워야 한다. 개발 워크샵을 2년 정도 진행해오면서 느낀 바로 사람들은 자신이 무엇을 만들것인지 무엇을 만들고 싶은지 잘 모른다. 이상이 너무 크다거나, 반대로 너무 자신을 과소평가 한다거나 하는 모습을 많이 보았다. 때문에 무엇을 만들 수 있는지, 그것을 만들기위해서 뭘 해야 하는지를 명확히 할 필요가 있다. 개발 입문자에게 적합한 목표를 지정해주고 단기간에 그것을 만들면서 성취감을 느끼게 해주어야 할 필요가 있다.

세번째로는 만드는 과정을 배워야한다. 우리가 건담 프라모델을 만들더라도 제품에 따라 다르지만 보통 3-4시간하는 시간을 쏟게 된다. 하물며 간단한 웹 서비스를 만든다고 생각해보자. 물론 숙련자의 경우 1주일이면 프로로타입 정도는 가뿐히 해내겠지만, 보통 사람의 경우 1주일이면 예상컨데 로그인 하나 정도는 만들 수 있을 것 같다. 즉, 초심자에게 어떠한 것을 만드는 과정은 길고도 고된 과정의 연속이 된다. 그렇기 때문에 누군가 지정해준 '어떠한 것'을 만들려다가는 금방 포기하기 쉽고, 재미를 느끼기도 어렵다. 따라서 두번째 과정에서 무엇을 만들것인지 배운 이후, 무엇을 만들것인지 스스로 정하고 그 과정을 겪어야할 필요가 있다. 당연히 개발 경험이 부족하기 때문에 옆에서 지켜보고 도와주어야 할 사람이 필요하지만, 그렇다고 해서 모든 걸 가르쳐주어서는 안된다. 문제 해결 방안을 제시하는 것이 아니라, 계속된 질문을 통해 문제 해결 방안을 찾을 수 있도록 유도하는 역할이 필요하다.

수단-목표-과정 의 3단계 수업 방식이 내가 생각하는 이상적인 코딩 교육의 모습이다. 선생님이 아니라 멘토가 필요하고, 수동적인 학생이 아닌 적극적으로 자신이 필요한 것을 어필하는 멘티가 되어야 한다. 질문은 적극적으로 하되, 스스로 찾아보는 과정을 게을리하지 않는 멘티가 되어야 하고, 모르는 것은 알려주되 과도한 지식을 불어넣지 않고, 멘티의 적극성을 떨어뜨리는 정답 공개 방식은 멘토가 가장 피해야 할 과정일 것이다.

어떻게 배워야 할까?

나는 코딩을 처음 배울때 사실 수업이나 유사한 것을 받아본 기억이 별로 없다. 물론 혼자서 모든 걸 해낸 것은 결코 아니고, 도와주는 사람이 있었으나 그야말로 도와주는 사람이었지 나에게 가르쳐 주는 사람은 아니었다. Codecademy를 통해 기초를 다졌고, Node.js는 남이 써놓은 코드를 보면서 그걸 이해하려 들지 않고 써먹으려 노력했다. Arduino 또한 2시간짜리 워크샵을 한번 들은게 전부였고, CAD는 지인에게서 Sketchup 워크샵을 2시간정도 받고나서 내 휴대폰을 그려보는 것부터 시작했다.

생각해보면 딱히 교육이라고 할만한 것을 받아본 기억이 없다. 내가 천재라고 할만한 것은 결코 아닌게, 회사를 다닐때 컴퓨터 학원을 다니면서 C++ 을 배웠지만 열심히 했음에도 나의 이해도가 도통 진도를 따라가지 못했다. 외려 그 수업을 이해하고 있는 사람들이 더 신기했을 정도였다. 실제로 도와주는 사람이 있는 상태에서 독학을 할 경우가 훨씬 진도가 빨랐다. 궁금한 점은 Google (정확히는 Stackoverflow)에서 검색해보았고 대부분 해결되었다. 코딩은 쉽다고 할 순 없지만, 그렇다고 뭔가 깨우친 사람들만 하는 것도 결코 아니다. 주위의 개발자들을 한번 잘 생각해봐라. 그 사람들의 지능이 나보다 엄청나게 뛰어나다고 느끼던가? 아닐거라고 본다. 다들 뭐 안되면 Google 검색한다.

난 코딩을 배우려는 사람들에게 나만의 원칙 몇가지를 알려주곤 한다.

1. 우리는 만들기 위해서 배우는 것이지 배우기 위해서 만드는 것이 아니다.
2. 하고 싶은 프로젝트를 조금씩 만들어간다는 생각으로 시작하라.
3. 이해하려고 하지 말고, 써먹는다는 생각으로 해보라.
4. 배우고자 하는 언어가 있다면 얇은 책을 한국 사람이 쓴 걸로 골라라.
5. 웹 튜토리얼을 따라가되 정 이해가 안될때는 동영상을 찾아보자.
6. 모르는 것은 우선 검색으로 해결해보자. 하다하다 안될때까지.
7. 멘토를 찾아라. 날 가르쳐주기 위한 사람이 아닌 도와줄 사람을.

순서는 좀 엉뚱하지만 가장 중요한 것은 3번 항목이다. 이해하지 말고 써먹어야 한다. 클래스니 객체니, 상속이니 어쩌구니 하는 것들을 이해하려고 하지 말자. 이해하려고 하지 말고 사용법만 기억해서 조금씩 사용해보도록 하자. 그러면 그 과정에서 저절로 이해하게 된다. 왜냐하면 그사람들도 그렇게 만들었기 때문이다. 어느날 갑자기 클래스라는 걸 만들자 한것이 아니라 클래스라는 것을 만들어 쓰다보니 개념이 생긴 것 뿐이다. 이해보다 실행이 더 중요하다. 우리는 종종 그것을 오해하면서부터 배우는 것에 대한 부담을 느끼게 된다. 우리가 만든 이론이란 것들은 대부분 하다보니 생겨난 것들이지 이론이 정립되고 만들어진 것들이 아니다. 명심하자.

정리

사실 코딩은 독학에 가깝다고 생각한다. 교육(?)으로 가르쳐 줄 수 있는 것들에는 분명 한계가 있고 결국 무엇을 만드는 과정은 직접 배워갈 수 밖에 없다. 때문에 만약 교육 과정에 코딩이 들어가야 한다면, 단순히 Scratch 나 Javascript 혹은 Python 을 배우는 것이 아니라 프로젝트로 진행해야 한다. 성적표 관리 시스템이라도 직접 팀을 만들고, 목표를 세우며 그 목표를 달성하는 과정에서 필요한 것들을 배워야 한다. 모든 사람이 코딩을 해야 한다 는 것 당연히 현대 사회에서 점점 더 중요해질 것이라고 생각한다. 하지만 그보다 우리에게 중요한 것은 코딩을 해야하는 이유이고 이것은 결국 무엇을 만들기 위해서라고 생각한다.

갑작스러운 코딩 열풍. 이전부터 IT 관계자들은 코딩의 중요성에 대해서 여러번 반복해왔는데 왜 이제와서 코딩인가? 라는 질문을 스스로에게 던져보았다. 나의 결론은 이렇다. 모든 사람이 코딩을 해야 하는 것이 아니라, 모든 사람이 코딩을 할 수 있는 시대가 된 것이다. 어셈블리, C 기타 초기 개발 언어들은 보통사람이 접하기에 복잡한 개념으로 가득했다. 하지만 이제는 너무나 쉬워졌다. 다만 쉬워진만큼 다른 방식의 교육이 필요하다. 모든 사람이 할 수 있으니, 그걸로 뭘 할 수 있을지 배워야 하는 것이 지금 우리나라에 필요한 것 아닐까?