코딩 교육이 최근 열풍처럼 번지고 있다. 많은 사람이 코딩 교육에 대하여 이야기하는데 이걸 좀 생각해보고 싶다.
보통 아래와 같은 이야기들을 많이 한다.
이런 이야기에 “모두 맞았어요.” 같은 뻔한 소리는 하고 싶지 않고 오히려 모두 틀렸다고 생각한다. 이유는 한 가지다. 이미 이전에도 코딩 교육은 있었다. 외국의 케이스와는 매우 다르지만, 우리나라 같은 경우에는 컴퓨터 학원이 엄청나게 유행을 탔던 적이 있다. 15년 정도 전까지도 우리나라에는 컴퓨터를 배우러 학원가는 학생들이 많았다. 가서 뭘 배웠느냐고? 주로 GW 베이직(GW-Basic)을 배웠다.
물론 현대의 개발 언어와는 하늘과 땅 차이가 난다고 해도 과언이 아니지만, 어찌 됐든 그 당시에도 GW 베이직으로 상당히 많은 것들을 만들 수 있었다. 주로 구구단으로 시작했고, 별표(*)로 피라미드나 마름모꼴을 만드는 것과 같은 간단한 알고리즘 구현을 목표로 공부했었다. 그렇지만 나는 빌게이츠가 될 수 없었다.
좀 더 자세하게 이야기해보고 싶다. 나는 베이직으로는 단순 별표 아트에서 넘어가 원을 그리거나 상자 등 간단한 그림을 코딩으로 구현하는 데까지 해보았다. 당시 다니던 학원에서는 GW 베이직만 가르쳤고, 다른 학원으로 옮겨서는 C를 배웠다. (C++ 이 아직 대세가 되기 전 시절로 기억한다.)
어린 시절에는 사실 왜 해야 되는지도 모르면서 그냥 하라니까 배웠던 것 같다. 데이터베이스를 만드는(!?) 수업을 들었던 것 같은데, 내가 할 수 있었던 건 그저 선생님이 주신 코드를 열심히 베껴 쓰는 것뿐이었다. 어쨌든 꽤 열심히 했었고, 재밌었지만 나는 역시 빌 게이츠가 될 순 없었다.
뭘 만들어야겠다는 생각도 못 했지만, 그걸 도와줄 만한 사람도 없었다. 물론 게임을 만들고 싶어 하긴 했지만, 딱히 그걸 코딩으로 시작할 엄두도 안 났다. 대신 RPG 쯔꾸르 게임 제작 툴로 자작게임을 만들곤 했다.
나는 GW 베이직을 통해서 논리력이나 창의력 같은 걸 배웠다고 생각하진 않는다. (툴을 사용하긴 했지만) 게임을 만들었던 것은 그냥 내가 하고 싶은 것이었고, 투자할만한 시간과 열정이 있었기 때문이다. 코딩을 배웠다고 해서 없던 창의력이 생겨나지도 않았고, 컴퓨터적인 생각? 그런 건 지금이나 그런가 보다 할 뿐이지, 컴퓨터의 작동원리 같은 걸 초등학교 2~3학년이 쉽게 이해할 리도 없었다.
코딩을 배운다고 해서 문제해결능력이 갑자기 생겨나지도 않는다. 물론 베이직 코드를 디버깅하는 기본적인 방법이야 알게 되었지만, 그걸 다른 곳에 적용한다는 것은 또 다른 이야기였다.
회사를 그만두고 창업 전선에 뛰어든 지 4년. 여러 곳에서 발표할 기회가 있을 때 나는 주로 “WHY – WHAT – HOW” 세 가지만을 이야기하곤 한다.
가장 많은 시간을 쏟고 중요하게 생각하는 건 WHY. 발표자료 분량을 봐도 WHY가 약 50%, WHAT이 35%, HOW는 15% 정도를 차지한다. 왜 해야 하는지 이유가 타당하다면 뭘 해야 할지는 명확해지고, 어떻게 해야 할지는 딱히 중요하지도 않다. (적어도 사업을 시작할 때는 말이다)
그럼 코딩은 왜 배워야 하는가? 논리적 사고? 컴퓨테이셔널 싱킹? 창의력? 이런 건 결코 코딩을 조금 배운다고 해서 생겨나지 않는다. 물론 도움이 될 수도 있겠지만 이런 걸 목표로 코딩하자고 이야기하는 것들은 결코 아니라고 생각한다.
내 생각엔 이렇다. 현대 사회는 날이 갈수록 세분화하고 있고 복잡해지고 있다. 작은 음식점이라도 하나 운영하려고 하면, 기본적인 재무제표 읽는 법이라든지 세법, 재고 관리, 고객 관리, 마케팅 등등… 배워야 할 것이 정말 수도 없이 많다. 게다가 각 산업에서 유사한 팩터가 많다고 해도, 각자의 특성에 따라 그 세부사항은 매우 달라지기 마련이다. 병원 약품 재고와 장난감 가게 재고를 어떻게 같이 취급할 수 있겠는가.
따라서 필요한 것을 직접 만들어 쓰진 않더라도 용도에 맞게 수정해서 사용해야 할 필요성이 생기고 있는 것이다. 그러다 보면 내가 하려던 일이 편리해지는 것은 물론이요, 해당 서비스의 판매도 이루어지게 되는 것이다.
소프트웨어 개발에 도움을 주는 소프트웨어는 무척이나 많은데 이러한 것들이 어느 날 갑자기 “우리 이런 걸 만듭시다!”하고 만들었을 것 같은가? 그렇지 않다. 개발자들이 업무를 하는 도중에 불편한 것들을 직접 개선하는 과정에서 태어난 부산물이다. 개발자들이 느끼는 불편함들을 개발자들이 고쳐나가는 게 당연하다고? 그렇다면 이러한 것은 모든 분야에 적용할 수 있다.
결국, 우리가 코딩을 배워야 하는 이유는 코딩 자체로 얻을 수 있는 어떠한 편익이나 능력 때문이 아니라 무엇을 만들 때 필요하기 때문이다.
재고 관리 시스템의 이러이러한 면이 불편해서 개선해야겠다. 그러니 저러저러한 것들을 배워서 이러이러한 부분을 수정해야겠다.
위와 같이 생각하는 것이 매우 자연스러워진다. 당장 취직해서 SI 산업 일꾼이 되기 위해 스크래치(Scratch; 아이들에게 프로그래밍 경험을 주기 위해 MIT에서 개발한 교육용 프로그래밍 언어)나 자바스크립트(Javascript)를 배우는 것이 절대 아니라는 뜻이다. 우리는 무언가를 만들기 위해 코딩을 배워야 한다.
무언가를 만드는 과정은 절대 간단하지 않다.
우선 개발 언어를 배워야 한다. 무엇을 만들고 싶어도, 그것이 어디까지 가능한지에 대해서 개발 지식이 없는 사람은 가늠할 수 없다. 그러니 우선은 컴퓨터가 어떻게 작동하는지까지는 아니더라도 (이러한 교육 또한 필요하지만, 너무 갈 길이 멀다. 이건 확신하건대 욕심이다.) 무언가를 만들기 위해서는 어떠한 문법이 필요하다 하는 것과 현재 인터넷이나 컴퓨터의 대략적인 구동 형태는 알아야 할 필요가 있다. 예를 들어, 웹 서비스를 만들기 위해서는 http request/response의 원리까지는 몰라도 ‘그런 것이 있다’ 정도는 알아야 하는 것이다.
두 번째로는 무엇을 만들 것인지 배워야 한다. 개발 워크샵을 2년 정도 진행해오면서 느낀 건데 사람들은 자신이 무엇을 만들 것인지, 무엇을 만들고 싶은지 잘 모른다. 이상이 너무 크거나 반대로 너무 자신을 과소평가하는 모습을 많이 보았다. 그러므로 무엇을 만들 수 있는지, 그것을 만들기 위해서 뭘 해야 하는지를 명확히 할 필요가 있다. 개발 입문자에게 적합한 목표를 지정해주고 단기간에 그것을 만들면서 성취감을 느끼게 해주어야 할 필요가 있다.
세 번째로는 만드는 과정을 배워야 한다. 우리가 건담 프라모델을 만들더라도 보통 3~4시간 정도는 시간을 쏟게 된다. 하물며 간단한 웹 서비스를 만든다고 생각해보자. 숙련자의 경우라면 1주일이면 프로로타입 정도는 가뿐히 만들어내겠지만, 보통 사람의 경우 1주일이면 예상하건대 로그인 하나 정도는 만들 수 있을 것 같다.
즉, 초심자에게 어떠한 것을 만드는 과정은 길고도 고된 과정의 연속이 된다. 누군가 지정해 준 ‘어떠한 것’을 만들려다가는 금방 포기하기 쉽고, 재미를 느끼기도 어렵다. 따라서 두 번째 과정에서 무엇을 만들 것인지 배운 후, 무엇을 만들 것인지 스스로 정하고 그 과정을 겪어야 할 필요가 있다. 당연히 개발 경험이 부족하므로 옆에서 지켜보고 도와줘야 할 사람이 필요하지만, 모든 걸 가르쳐줘서는 안 된다. 문제 해결 방안을 제시하는 것이 아니라, 계속된 질문을 통해 문제 해결 방안을 찾을 수 있도록 유도하는 역할이 필요하다.
“수단-목표-과정”의 3단계 수업 방식이 내가 생각하는 이상적인 코딩 교육의 모습이다. 선생님이 아니라 멘토가 필요하고, 수동적인 학생이 아닌 적극적으로 자신이 필요한 것을 어필하는 멘티가 되어야 한다.
질문은 적극적으로 하되, 스스로 찾아보는 과정을 게을리하지 않는 멘티가 되어야 하고, 모르는 것은 알려주되 과도한 지식을 불어넣지 않고, 멘티의 적극성을 떨어뜨리는 정답 공개 방식은 멘토가 가장 피해야 할 과정일 것이다.
나는 코딩을 처음 배울 때 수업이나 수업 유사한 것을 받아 본 기억이 별로 없다. 물론 혼자서 모든 걸 해낸 것은 결코 아니고, 도와주는 사람이 있었으나 그야말로 도와주는 사람이었지 나에게 가르쳐 주는 사람은 아니었다. 코드아카데미(Codecademy)를 통해 기초를 다졌고, Node.js는 남이 써놓은 코드를 보면서 그걸 이해하려는 노력 대신 써먹으려고 노력했다. 아두이노(Arduino) 또한 2시간짜리 워크샵을 한번 들은 게 전부였고, CAD는 지인에게서 스케치업(Sketchup) 워크샵을 2시간 정도 받은 후 내 휴대폰을 그리는 것부터 시작했다.
생각해보면 딱히 교육이라고 할만한 것을 받아본 기억이 없다. 그렇다고 내가 천재라고 할만한 것은 결코 아닌 게, 회사 근무 당시 컴퓨터 학원에 다니며 C++을 배웠지만, 열심히 했음에도 나의 이해도로는 도통 진도를 따라가지 못했다. 외려 그 수업을 이해하고 있는 사람들이 더 신기했을 정도였다.
반면 실제로 도와주는 사람이 있는 상태에서 독학할 경우 훨씬 진도가 빨랐다. 궁금한 점은 구글(정확히는 스택오버플로우(Stack Overflow))에서 검색을 했고 대부분 해결되었다.
코딩은 쉽다고 할 순 없지만, 그렇다고 뭔가 깨우친 사람들만 하는 것도 결코 아니다. 주위의 개발자들을 한번 잘 생각해봐라. 그 사람들의 지능이 나보다 엄청나게 뛰어나다고 느끼는가? 아닐 거라고 본다. 다들 뭐가 잘 안되면 구글링을 한다.
난 코딩을 배우려는 사람들에게 나만의 원칙 몇 가지를 알려주곤 한다.
순서는 좀 엉뚱하지만 가장 중요한 것은 3번 항목이다. 이해하지 말고 써먹어야 한다. 클래스니 객체니 상속이니 어쩌니 하는 것들을 이해하려고 하지 말자. 이해하려고 하지 말고 사용법만 기억해서 조금씩 사용해보자. 그러면 그 과정에서 저절로 이해하게 된다. 왜냐하면, 그 사람들도 그렇게 만들었기 때문이다.
어느 날 갑자기 클래스라는 걸 만들자고 한 것이 아니라 클래스라는 것을 만들어 쓰다 보니 개념이 생긴 것뿐이다. 이해보다 실행이 더 중요하다. 우리는 종종 그것을 오해하기 때문에 배우는 것에 대한 부담을 느끼게 된다. 우리가 만든 이론이란 것들은 대부분 하다 보니 생겨난 것들이지 이론이 정립되고 만들어진 것들이 아니다. 명심하자.
사실 코딩은 독학에 가깝다고 생각한다. 교육(?)으로 가르칠 수 있는 것에는 분명 한계가 있고 결국 무엇을 만드는 과정은 직접 배워갈 수밖에 없다. 따라서 만약 교육 과정에 코딩이 들어가야 한다면, 단순히 스크래치나 자바스크립트 혹은 파이썬(Python)을 배우는 것이 아니라 프로젝트로 진행해야 한다.
예를 들어 성적표 관리 시스템을 만든다면 직접 팀을 만들고 목표를 세우며 그 목표를 달성하는 과정에서 필요한 것들을 배워야 한다. ‘모든 사람이 코딩을 해야 한다’는 명제는 현대 사회에서 점점 더 중요해질 것이라 생각한다. 하지만 그보다 우리에게 중요한 것은 코딩을 해야 하는 이유이고 이것은 결국 ‘무언가를 만들기 위해서’라고 생각한다.
갑작스러운 코딩 열풍이 불고 있다. ‘이전부터 IT 관계자들은 코딩의 중요성에 대해서 여러 번 반복해왔는데 왜 이제 와서 코딩인가?’라는 질문을 스스로 해봤다. 나의 결론은 이렇다.
모든 사람이 코딩을 해야 하는 것이 아니라, 모든 사람이 코딩을 할 수 있는 시대가 된 것이다.
어셈블리, C 등 초기 개발 언어들은 보통 사람이 접하기에 복잡한 개념으로 가득했다. 하지만 이제는 너무나 쉬워졌다. 다만 쉬워진 만큼 다른 방식의 교육이 필요하다. 모든 사람이 할 수 있으니, 그걸로 뭘 할 수 있을지 배워야 하는 것이 지금 우리나라에 필요한 것 아닐까?