응용과학으로서 중등교육에서 정규교과로 편성

보이지 않는 소프트웨어

응용과학으로서의 교육

정보교육의 방향이 어플리케이션 소프트웨어의 활용교육 중심에서 프로그래밍과 창의적 문제해결 중심으로 옮겨가면서 응용과학의 본질에 접근하고 있다는데 대해 두 가지 관점에서 긍정적인 입장이다.

  • 하나는 소프트웨어라는 것 자체가 형태를 가지고 있지 않지만 거의 모든 생활과 산업 분야에 존재하고 있는 생산물이라는 것을 인정하고, 우리 사회가 실물경제를 통한 성장중심의 산업에서 무형의 고부가가치 산업으로 넘어가고자 하는 진실성이 담긴 의지로서 환영하는 바이고,
  • 다른 하나는 이를 교육의 영역에서 받아들이고자 함으로써 산업기술훈련에서 응용과학교육의 영역으로 전일보 하게 되었다 점에서 긍정적으로 생각한다.

정보교육의 과거

지금의 이런 소프트웨어(코딩)교육이 처음 시도되는 것은 물론 아니다. 정보 교육에 대응하여 교실 정보화를 시작으로 실과 교과와 방과후, 동아리 활동 영역에서 이미 오래전 부터 시도해 오고 있었다. 오히려, 주변 선진국들보다 빠르게 갖추어진 인프라 덕분에 더 빨리 시작되어진 부분도 없지 않다. 하지만, 인프라를 지탱할 커리큘럼의 한계를 넘지 못하였고, 그 결과 정규 교과의 그늘에 가려 빛을 발해보지도 못하고 사그러들고 있었다.

Scratch가 존재하기도 전에 GREAT, KAS, 새빛과 같은 한국형 저작도구들로 다양한 CAI를 제작하고 있었고, 아이들도 GREAT와 같은 도구로 콘텐츠를 만드는 활동을 즐거워했다. 잠시나마… 한국형 저작도구들에 대해 좋지 않은 평가를 내리는 사람들도 많았다. 그렇다면, 비판적인 사람들이 대안을 가지고 있었느냐 ? 그런 것도 아니었다. ToolBook 이나 Authorware 같은 외국 도구들도 내내 매한가지였다.

그렇다면, 왜 이런 시도들이 자리잡지 못하고 매 번 반짝 빛내고는 사라져버린걸까?

정규교과로 편성

당장 당장 써먹을 수 있는 기술을 배우는 산업기술 커리큘럼은 의외로 명료하고 간단해서 가르치기도 쉽고, 평가하기도 매우 수월하다. 하지만, 창의적인 사고를 필요로 하는 응용과학 커리큘럼은 가시적인 어떤 성과가 나타나기까지 가르치는 사람의 안목과 학습자의 꾸준한 사고와 노력이 반영되어야만하고, 결과물 또한 천차만별이기 때문에 만들어내기 쉽지 않을 뿐더러 순수학문의 교과만큼 상당한 노력과 연구와 정성, 신뢰가 필요하다.

그렇다고 정규교과를 만들어서 가르칠 것인가에 대한 논의에 대해서 초등에서는 아직 이르다고 생각되지만, 중고등학교 과정에서 정규교과로 편성하여 선택교과로 운영하면 충분하리라는 생각이고,

중고등학교에서 운영되어서 응용과학의 영역으로 자리를 잡아가는 동안, 초등교사를 양성하는 교육대학교에서 필수과정을 개설해 충분한 소양을 갖추도록 하는 방안이 가장 현실적이지 않을까 싶다.

 

DOS 프로그래밍 이야기

MS-DOS

MS-DOS는 개인용 컴퓨터 시대를 예정보다 20배 이상 앞당겨 준 의미있는 운영체제가 아닐까 싶다. 당시 IBM에서 Personal Computer라는 이름을 붙인 컴퓨터(IBM-PC)의 아키텍쳐를 화끈하게 오픈하시는 바람에 컴퓨터 제조사들이 앞다투어 호환되는 컴퓨터들을 만들어내기 시작하고 (그래서, IBM-PC호환기종이라 부름) 전 세계가 개인용 컴퓨터 풍년을 맞이하게 되었다.

춘추전국시대의 중심에서 다양하게 설계된 IBM-PC호환기종들을 구동시킬 수 있는 운영체제인 MS-DOS를 (CP/M의 호환 OS인 86-DOS를 인수해서 라벨을 MS로 옮겨붙여) 탄생시켜, 전 세계의 IBM-PC 호환기종들을 일거에 평정한건 정말 기가막힌 행운과 사업수완과 안목이 만들어 낸 기회였다.

DOS 만들기 놀이?

당시 프로그래머들 사이에서 운영체제를 만들어 보는건 일종의 레벨을 정하는 놀이 정도였던 것으로 기억한다. 내가 만든 코드를 디스크에 기록하고 부팅시켜 메모리에 로드하여 커맨드를 입력하고 디스크를 읽어들이고 화면을 제어하는 기초적인 운영체제는 ‘좀 한다’는 사람들의 연습과제 쯤 되었던 적이 있다. 하지만, 이미 모든 시장을 선점한 IBM + Intel + MS 진영과 대적할 수는 없었다.

Ms_dos

Apple ][ 의 Apple DOS 3.3도  있었던 것으로 기억되는데, 본격적으로 입문한 기기가 8088(XT) 기종이다 보니, (값비싼) Apple ][ 는 친구 집에서 오락용으로 몇 번 만져본게 전부였다. ( ][ = 로마숫자 II의 당시 애플식 표기)

Apple-II

뭐, 당시로서는 지금처럼 아름다운 툴들이 마땅히 없었으니 edit 이나 debug (MS-DOS외부커맨드)나 가지고 놀고, MASM (MS매크로어셈블러) 을 왜 공부해야 하는지 이유도 모른 채, 필요에 의해 그냥 즐겼던 것으로 기억(만) 된다. 8086/8088 어셈블러를 다루면서 컴퓨터바이러스의 일부를 메모리에 덤프하고 잘라내 고치고 변형시키면서 습득한 기술로 바이러스 만드는 놀이에 미친듯이 빠져서 꿈속에서도 답을 찾으며 지내기 시작했지만. 남들보다 월등히 떨어지는 생체 CPU로 인한 슬럼프와 학업성적의 급락, 집구석에 처박혀 두문불출 오타쿠 생활에 대한 가족갈등 등이 복잡하게 얽혀, 한계를 극복하지 못하던 어느 날…

Quick-BASIC 4.5

친구의 PC를 가지고 놀다가 우연히 발견한 인터프리터가 있었으니… 바로 Quick-BASIC 이었다. 뭐, 엄밀히 말하자면, MS-DOS에 내장된 보급형(?) Quick-BASIC이 아닌 Quick-BASIC 4.5 였다. 컴파일러가 제공되었기 때문에, 인터프리터로 손쉽게 코딩하고, 키보드 한 번에 컴파일하여 .EXE 파일로 생성할 수 있었기 때문에, 교육대학교에 진학해서 대학신문사 DM발송 프로그램을 제작해 술값 정도 버는 알바도 했었다.

개인적으로 참 못된 성격이 하나 있는데, 컴퓨터 게임을 하더라도 남들이 기피하는 캐릭터나 장비를 어떻게든 마스터해서 고수가 되려 한다든지(사무라이쇼다운의 다치바나 유쿄, 태켄의 레이 우롱, 맥워리어의 타나토스 같은…), 여튼 남들이 하지 않는 길을 찾는 것이 지금까지도 고치고 싶지 않은 부분이다.

QuickBasic_Opening_Screen

그래서, 한창 재미있게 물올리고 있던, C와 Pascal에서 과감히 손을 떼고, Quick-BASIC으로 전향해서 끝판 왕을 깨보려 시도해 나갔고, 처절한 한계를 접하기도 하고, 어쩔 수 없이 C나 어셈블러로 모듈을 컴파일해서 불러들이는 꼼수를 사용하기도 하면서 나름 괜찮은 코드들을 만들어가며 레벨을 높였다. (지금 생각해보면 얼마나 바보같은 짓이었는지 모른다)

1994년만 해도 BASIC을 한다고 하면, 일단 까고(?) 들어갈 정도로 볼랜드사의 Turbo C의 인기가 절정에 이르던 시절이었지만, Quick-BASIC으로 BIOS Interrupt를 이용해 왠만한 PC 제어 프로그램은 금새금새 만들 수 있었기 때문에, 큰 필요성을 느끼지 못했다.

예를들어, 플로피디스크 드라이브를 대기시켰다가 디스켓을 넣으면, DOS 커맨드를 입력하지 않아도 자동으로 파일 목록을 보여주며, 키보드를 이용해 파일을 선택하고 실행할 수 있도록 하는 간단한 기능?

NC, Mdir

지금은 Windows 라는 GUI 환경의 기가막힌 운영체제가 너무나 빠르고 편리하게 동작하고 있어서, 위의 내용이 잘 이해되지 않을지도 모르겠다. MS-DOS 세대는 공감하겠지만, NC(norton commander)나 Mdir 없이 PC를 이용 한다는 것은, 마치 마우스 없이 Windows를 사용하는 것과 같은 의미였다. 그런 환상적인 유틸리티인 NC와 Mdir의 모든 기능을 똑같이 Quick-BASIC으로 구현할 수 있을 정도로 푹 빠져들어 있었다.

재귀호출, 시분할, 램상주, 삭제파일복구, 디스크무결성검사 같은 간단한(?) 코드 부터, 시리얼포트와 모뎀을 이용한 네트워킹 같은 신통방통한 코드까지…

불행히도, C와 같은 언어는 라이브러리가 잘 공개되어 있어서 갖다 붙이고 값만 주고 받으면 구현되었지만, Quick-BASIC은 코드 자체가 공개되어 있지 않았고, 온라인으로 소스 코드를 구하기도 쉽지 않았던 시절이라 어렵사리 구한(성안당에 근무하셨던 아버지를 통해) 서적과 절반은 알아듣지도 못하는 영문 문서를 보면서 핵심 알고리즘을 0 byte 코딩했었다는 점이 지금도 추억으로 남아있다.

당연히, 좋지도 않은 머리로 맨 땅에 헤딩하려니 상당한 시간과 노력이 들었지만, 그 만큼 온갖 잔머리를 둘려야만 했었고, 제대로 작동할 때의 성취감은 이루 말할 수 없는 전율과 심각한 중독 증세를 일으켰다. 암호문을 역해독하는 문제를 푸느라 방학 2주 가량을 잠도 거의 안자고 밥만먹고 컴퓨터 앞에 앉아서 50여장의 낙서 가득한 연습장과 어이없이 수학공식 가득한 문서를 보며, 수업시간에 거들떠 보지도 않던 ‘수학의 정석’을 본의 아니게 공부했던 기억도 있다.

뭐, 더 이야기를 풀고 싶어도 5년이 지나면 기억을 상실하는 고질병이 있어서 더이상은 기억이 나지 않아, 에피소드를 나열하기에 어려움이 있지만, 그 중에서 가장 종합적이고 기억이 살아있는 경험을 한꼭지 풀어볼까 한다.

메모리 점유없이 다른 프로그램을 실행하기

Quick-BASIC에서 외부 프로그램을 실행하기 위해서는 SHELL 명령을 이용하면 된다. 그런데, SHELL 명령은 본 프로그램이 메모리에 상주해 있는 상태에서 COMMAND.COM이 프로그램 명령어를 실행하기 때문에, 당시 512KB, 640KB (MB도 아니고 GB도 아닌) 의 주기억장치(RAM)을 사용하던 8088 PC에서 본 프로그램의 메모리를 차지한 상태에서 큰 메모리가 필요한 외부 프로그램이 실행하다보면, 메모리 부족을 일으키게 되는 문제가 있었다.

Super Signal Man = SS.EXE

이름도 참 유치하게, 슈퍼시그널맨이라니…

필요성

8088(XT) 컴퓨터로 어떤 배치작업이나 파일을 압축하는 등의 작업울 실행하면 CPU의 속도도 문제가 있었지만, 디스크의 I/O 속도가 지금의 기기들과는 천지차이였기 때문에, 상상 이상의 시간이 소요되었고, 게다가 MS-DOS는 멀티태스킹 운영체제가 아니었기 때문에 작업이 끝날 때까지 모니터 앞에 앉아서 마냥 기다리고 있어야 했다.

이런 불필요한 기다림을 줄이기 위해 SS.EXE는 파일 압축이나 기타 오랜 시간이 걸리는 명령이 끝나면, PC스피커로 음악을 연주해 종료를 알려주는 유틸리티였다. 명령을 내리고 나면, 작업이 끝나 음악이 연주될 때까지 PC앞을 떠나 차를 마시거나 다른 일을 할 수 있는 하이브리드 멀티태스킹(?)을 구현하는게 핵심이었다.

커맨드

C:\> SS.EXE [COMMAND]
ex) C:\> SS.EXE PKZIP C:\DOCUMENT\*.* A:\BACKUP.ZIP -&
ex) C:\> SS.EXE XCOPY C:\PICTURES\*.* A:\

핵심 알고리즘

Quick-BASIC으로 작성된 SS.EXE가 아규먼트로 받아온 명령을 해석하여

SHELL 커맨드를 사용하지 않고, 명령어를 실행한 뒤,

실행된 명령어가 종료되면, 다시 SS.EXE로 돌아와 음악을 연주하고 끝.

문제

SHELL 커맨드를 사용하지 않으면, 외부 명령어를 실행할 방법이 없음.

명령어를 실행했다 하더라도 종료 후에 다시 SS.EXE를 재 실행할 수 있는 방법은?

해결책

  • SS.EXE가 명령어가 포함된 _SS_.BAT 파일을 생성한 뒤,
C:\> TYPE _SS_.BAT
CLS
@ECHO OFF
PKZIP C:\DOCUMENT\** A:\BACKUP.ZIP -&
SS.EXE /end
  • SS.EXE를 종료한 상태에서 _SS_.BAT 배치파일을 실행 시키고,
  • 배치파일에 기록된 대로 다시 SS.EXE를 실행
  • 단, 종료 시그널을 발생시키도록 옵션을 다시 입력받아 실행하여 음악 연주

또 다른 문제

  • 이미 프로그램이 종료된 시점에서 무슨 수로 _SS_.BAT 파일을 어떻게 실행시킬 것인가?
  • 여기서 SHELL을 호출하면 결국 도루묵인데.

궁극의 해결책

인터럽트를 이용한 키보드 버퍼 제어

내가 닉네임에 사용할 정도로 존경하는 인물인 Peter Norton은 정말 천재였다. 원서로 된 MS-DOS 매뉴얼을 읽던 도중, 천금같은 아이디어를 얻었는데… 키보드 버퍼를 조작해 마치 내가 키보드로 직접 입력한 것 처럼 기록하면 프로그램이 종료된 다음, 키보드 버퍼의 내용이 타이핑 되어 실행된다는 것이었다.

소스코드를 첨부하고 싶지만, 1996년도 백업디스크가 손상되어 모든 소스코드들을 날려버리고 근 한 달을 패닉상태로 지낸 사건이 있었다. 그 때 사라진 1988년부터의 천금같은 소스 코드들에 대한 미련을 술과 함께 잊어가면서 동시에 기억도, 뇌세포도 상당부분 지워져 버렸다. (지금의 컴맹으로 다시 태어나게 된 중대한 사건 중 하나)

정리

  1. SS.EXE와 명령어를 입력한다.
  2. 입력하지 않은 경우 사용법이 안내된다.
  3. SS.EXE는 명령어가 담긴 _SS_.BAT 파일을 디스크에 생성한다.
  4. 프로그램을 종료하기 전, 인터럽트를 가로채 키보드 버퍼에 _SS_.BAT <엔터> 를 기록한다. (엔터를 ASCII 코드로 반드시 기록해야 함)
  5. _SS_.BAT 파일에 기록된 대로 명령이 실행된 다음,
  6. /end 라는 종료 옵션을 받은 SS.EXE는 음악을 연주
  7. – 개선된 버전에서는 화면보호기와 함께 실행했던 것으로 기억됨.

 

DOS 기반 프로그래밍의 추억

상상+만들기=상상+프로그래밍

개인적으로 과학과 공작에 유달리 관심이 많아 서랍장을 온통 주워온 고물과 분해한 부품들로 꽉 채워, 그저 틈나는 대로 무언가를 만들었던 어린 시절

TV외화 시리즈의 주인공안 맥가이버를 보며, 주인공 ‘MACGYVER’가 만들었던 어떤 것을 집에 와서 꼭~ 만들어야만 했던 추억

초등학교에 취학하기 전부터, 출판사에 근무하시던 아버지께서 편집을 위해 가져오신 전자전기관련 서적과 일본에서 들여와 번역한 과학이론서적, 관상이며 음양오행이며 한자가 잔뜩 섞인 동양 철학 서적을 그림책 보듯이 빠져들어, 알아 듣지도 못하는 내용을 그림과 숫자와 글을 내 멋대로 이해해가며 어렴풋이나마 이해가 될 때까지 수십 번을 곱씹고 읽으며, 마치 놀이하듯 책 읽던 기억

이런 어린 시절의 기억들이 물리학자의 꿈을 갖게 하였고, 성장의 과정에서 컴퓨터라는 기회를 만나 ‘내가 상상한’ 것을 ‘공작하여 만들기’에서 ‘컴퓨터로 구현하기’로 살짝 방향 전환을 했을 뿐…

프로그래밍교육에 대한 질문

  1. 최근 프로그래밍교육이라는 화두를 접하며, 우리 교육이 인문학과 기초과학에 충분히 접근하여 아이들이 충분히 경험하고 있는가에 대한 질문과
  2. 아이들의 생각과 두뇌를 활짝 열어 놓은 준비된 상태에서, 응용과학을 이야기하고자 하는 것인가 하는 질문을 던지고 싶다.

프로그래밍교육에 대한 시도는 여러 차례 이루어져 왔었다. 물론, 시도 자체를 부정하는 것은 결코 아니다. 시도하지 않으면 배우는 것도 없고, 발전도 없다는데 전적으로 동감한다.

  • 다만, 인프라에 비해 교육과정이 준비되지 않았다거나,
  • 상업적 이해 관계가 교육현장보다 강했다거나,
  • 정부주도 실적중심의 비교육적 사업에 대한 관심이 지나쳤다거나,
  • 교사들 스스로의 가르칠 필요성보다 교사들이 가르쳐야만 한다는 압력이 지배적이었다거나,

하는 문제가 충분히 해소되고 있는지에 대한 궁금증일 뿐이다.

미친 놈에서 컴맹의 길로 접어든지 20년 가까이 되어가는 시점에서 옛 추억을 떠올리며, 그냥 옛 추억이 떠올라 한 꼭지 적어 보았다. 인기가 좋으면, 다른 이야기 꼭지를 풀게 될지도… ^^

 

컴맹 맥노턴 선생.

 

 

(추신) 워낙 오래 전 기억이고, 좋지도 않은 머리로 쥐어짜내 쓰다보니, 내용 중에 잘못된 부분이 있을 겁니다. 아래 댓글로 콕~ 찍어주시면 감사하겠습니다.

컴퓨터프로그래밍교육과 언어(외국어)의 벽, 사고와 글쓰기

범용적인 프로그래밍 언어로 아이들에게 컴퓨터프로그래밍을 교육하는데 가장 큰 걸림돌은 역시 ‘외국어’이다. 변수와 상수, 배열, 프로시져, 함수, 객체를 명명하는데 영어는 큰 장해물이 된다. 초등에서는 사고와 글쓰기를 통해 준비의 단계로, 중등에서 영어와 함께 본격적으로 시도해 보는 것은 어떨까?

각인효과

BASIC이 프로그래밍 언어로 우리에게 다가와 오타쿠 초호기들의 모니터 형광물질을 초록으로 불태우던 시절…

사실, 지금까지도 빌 게이츠 형님이 버리지 못한 이유를 이해할 수 있을 것 같은 ‘각인’ 효과와… (빌 형이 살아있을 동안에는 절대로 BASIC이라는 언어가 사라지지 않을 것이라는 예언도 있었지;;;)
프로그래밍에서 아이들은 일단 언어의 벽에 부딪히게 된다.

흔히들 명령어셋을 이야기하지만… 알고리즘을 구현하는데 실제로 명령어셋은 몇 개 안된다. 몇 개 안된다는 것은 시간이 지나면 저절로 익혀지는 것이라는 뜻인지라, 이 보다 변수/상수의 명명이 훨씬 아이들에게 어렵게 다가오는 것이고, 무척이나 중요한 습관이다.

이름붙이기

일전에, 상용 소프트웨어의 코드를 (루트는 비밀) 받아서 자연어처리를 위해 분해해 재가공한 적이 있다. 놀라운 사실은… 이 코드가 꽤 여러 차례 버전업을 했음에도 불구하고…

변수와 배열 정의가 $aa, $abc, $jaum(자음), $sajeun(사전) 이런 식으로 되어 있었다… 함수와 프로시져도 open_sajeun(사전열어?), nanum_munja(문자나눔?) 너무 놀라서 전체 코드를 다 봤는데… 부분부분 이런 식이었고, 다른 사람이 손댄 부분은 또 알아보기 쉬운 사전적 단어들이 이용되어 있었다.

프로그래밍 중 코딩교육에서 절대로 가볍게 생각해서는 안되는 부분이
$a=1
$b=2
$c=$a+$b
이런 것이라 생각한다.

일시적으로 사용하는 변수는 일시적이라는 의미의 단어tmp/temp등을 변수명 앞에 붙인다거나, 변수의 목적에 맞는 단어를 앞에 붙이고, 대소문자를 적절히 활용하고, 특수한 목적에 따라 언더바(_)를 이용하는 등의 룰이 있다. 이런 룰이 시작부터 각인되어야 할 부분이고, 기본적인 약속이므로 지키도록 해야 한다. 우리 아이들에게는 한글로 코딩할 수 있는 인터프리터가 나오지 않는이상… 결코, 쉽지 않은 부분이다.

생각하기와 글쓰기

그래서 초등학교에서 프로그래밍의 시작은 생각하기와 글쓰기와 생각하기와 글쓰기다. 이게 완성되어 중등학교에서 영단어와 매칭시키는 단계로 연결되어야 하지 않나 생각해본다. (영재아들 이야기는 일단 생략)

하고자 하는 알고리즘과 동작을 글로 남기고, 글을 읽어가며 문단문단을 순서에 맞게 재배열하고, 문장과 문장을 나열하여 연결하기 쉽도록 단어를 고치고, 처음부터 끝까지 함께 읽어가며 동작과 알고리즘을 정확히 이해하도록 하는 것이 시작이다.

교사와 함께 코딩하기

프로그래밍의 백미, 컴파일되어 실행되는 코드를 보면서 느끼는 성취감과 희열이다. 아이들에게도 물론 필요할 것이다. 어렵지 않다. 코딩은 교사가 해주면 된다. 아이와 옆에 앉아서 네가 내린 명령은 이렇게 작성하면 되고… 실행하면 이렇게 되는거야~ 실행해보자! 손으로 도화지에 그려온 오브젝트를 스캔해서 이미지로 변환시키고 코드에 넣는 활동이 바로 교사가 해야 할 역할이고, 보조교사가 도와야 할 부분이 아닌가 생각한다. 이런 활동 속에 스스로 해보고 싶은 아이들이 탄생할 것이고, 소양을 키워나가는 것은 그들의 몫으로 남겨두는 것은 어떨까?

우리 반에서 아이들과 시도해 본 것들에 대한 시행착오와 나름의 시도를 개선해 나가고 있지만, 항상 어려움에 부딪히는 것들이 저런 사고와 글쓰기 부분이고, 이런 활동이 선행되지 않으면 프로그래밍이라는 것이 그저 새로운 경험과 놀이 정도로 끝나게 되어 안타까움을 느끼고 있다.

(가르치는 사람이 컴맹이라 그런 것일지도 모르겠다… ㅠㅠ;;)

수용적이고 존중하는 분위기

창조적인 프로그래밍을 위해서는 학급의 수용적인 분위기가 필요하다. 비단 프로그래밍에서만 필요한 것은 아니겠지만, 창의적인 생각이 자연스럽게 모두에게 인정받을 수 있는 분위기를 이끌어내는 것이 매우 중요하다.

초등학생들과 컴퓨터프로그래밍(이하 프로그래밍) 접하기 전에 생각해 볼 문제가 있다. 우리는 학급 담임제이기 때문에 한 학급 단위를 기준으로 생각해 보자.

생각해 볼 문제

  1. 학급 전체에게 가르칠 것인가? – 보조교사가 없는 현실에서 학급 전체일 수 밖에 없다. 일단은 영재반이나 방과후나 동아리 활동은 빼고 생각해 보자.
  2. 목표를 충분히 생각하고 있는가? – 코딩 기술? 프로그래밍 원리? 창의적 사고? 문제 해결력? 교과연계? 진로지도? 소질계발?
  3. 흥미나 관심이 없는 학생은 어떻게 해야 할 것인가? – 프로그래밍에 흥미를 가진 친구와 팀을 이루어 다른 분야의 능력으로 협동하게 할 것인지, 어떤 자극을 통해 함께 참여하도록 유도할 것인지.
  4. 왜? 프로그래밍을 접해야 한다고 생각하는가? – 1,2,3이 준비되긴 했는데, 왜 프로그래밍을 접하게 해야 하는지 충분하고 분명한 이유를 제시할 수 있을 만큼, 교사 스스로 동기부여가 되어 있는가? 단지 유행이라서? 교과서에 하라고 하니까? 연수에서 배운대로 한 번 해보려고?는 아닌지.

나는 교사야. 전분가란 말이지. 나의 수업과 교육관에 미루어 교육적으로 유의미한 활동이고, 우리 학급 학생들에게 필요한 내용이라면 망설일 필요 없지.

수용적 분위기

모두 갖추어졌다면, 다음으로 필요한 것은 동기부여일 것이다. 그런데, 이것보다 더 중요한 것이 있는데, 어느 누구도 지적하지 않는 부분이다. 바로, 학급의 분위기다. 뭐, 여기에 대해 두 말 할 나위 없을 것이다. 비단 프로그래밍이 아니더라도, 도국수사과음미실체영바슬즐을 포함한 수 많은 학교 교육의 기반이 되는 것이니까. 학급 자체의 분위기가 ‘발견했거나 만들어낸 무언가’에 대해 모두가 감동하고 부러워할 준비가 항시 되어 있어야 한다.

  • 집에서 만들어 온 색종이 접기
  • 낙서로 그린 어떤 그림
  • 이쑤시개로 만든 집
  • 싹이 나온 강낭콩 씨앗
  • 유튜브를 보고 만든  특이한 종이 비행기
  • 아버지와 만든 플라모델
  • 학급 줄넘기 3종목 3관왕
  • 놀러가서 찍은 사진

저런 작은 것들이 당연하거나 손쉬운 것이 결코 아니다. 어느 누구에게는 엄청난 노력의 결과인 것이고, 서로 칭찬하고 격려해야 할 ‘노력’의 결과다. ‘저런건 나도 할 수 있어’라는 말과 생각이 어느 구석에서 나온다거나, ‘그러게말이야’라는 맞받아치기가 나와서는 절대로 안된다. 왜냐하면, 저런 결과물들이 모두 프로그래밍의 다른 형태이기 때문이다.

창작물에 대한 존중

나의 손끝에서 땀방울로 맺어진 창작물이 존중해 주지 못하는 분위기에서 ‘도전’과 ‘성취’를 맛본다는 건 어지간한 마인드컨트롤 없이는 불가능한 일이다. 특히나 프로그래밍을 배워가는 과정에서는 ‘동기부여’와 ‘문제해결’과 ‘배경지식보충’과 이를 넘어서려는 ‘창의적사고’ 등이 계속적으로 이루어져야만 그 중독성에 빠져들 수 있다. 이런 유기적이고 복합적인 활동을 지속하는 것은 매우 지치고 힘들고 어려운 일이다. 그런데, 학급의 분위기가 갖추어지지 않아 번번이 좌절하거나 무시당하는 경험이 누적되면, 프로그래밍 수업을 지속할 이유가 사라져 버린다. 처음에는 쉽지 않겠지만, 작은 고개 몇 개를 넘고 나면 내가 만들 수 있는 세상이 무한히 열리게 되는데, 작은 고개를 넘는 고난의 여정은 스스로의 자기 암시보다 주변 친구들의 격려와 기대가 훨씬 더 큰 도움이 된다.

고등학교시절 내가 만든 컴퓨터바이러스로 담임 선생님의 컴퓨터를 감염시켜 디스켓을 망가뜨리고 아무렇지도 않게 복구해드리는 장난에 대한 내 친구들의 격려(?)가 엄청난 힘이 되었다.

학급 경영의 중요성과 교사의 뚜렷한 교육관이 바탕이 되어야만 한다는 ‘교과서적’인 뻔한 이야기가 프로그래밍교육의 시작이라니. 이게 무슨 말도 안되는 소리란 말인가. 그러게말이다. 여하튼, 그 다음이 ‘동기부여’ 다. :맥노턴.

교육용 프로그래밍언어/도구 소개

1. MS Kodu

공식사이트 http://fuse.microsoft.com/projects/kodu

Microsoft에서 교육프로젝트의 하나로 추진하는 Kodu 게임제작 도구를 먼저 소개한다. 3차원 그래픽을 이용한 아케이드 게임 제작이 가장 큰 매력으로, 3차원 스테이지를 자유롭게 만들고 오브젝트들을 배치하여 각각의 움직임과 스코어 등을 프로그래밍하여 게임을 즐길 수 있다.

 

 

코드를 입력한다거나 복잡한 알고리즘이 필요하지 않으며, 마우스만으로 프로그래밍할 수 있어 초보적인 프로그래밍 원리컴퓨터를 제어하고, 성취감을 느끼기에는 환상 그 자체이다.

MS의 XBox 컨트롤러 하나로 프로그래밍이 가능할 정도로 간단하고, 내가 만든 게임을 내가 즐길 수 있다는 것이 가장 큰 매력이라고 볼 수 있다. 3D게임을 만들 수 있다고 해서 비행시뮬레이션을 생각하기에는 다소 무리가 있다.

다만, 다국어를 지원하지 않아 몰입도가 떨어진다. 세부설정을 통해 게임의 긴장감과 난이도를 정할 수 있는데, 직관적이지 않은 목록형인데다가 영어로 되어 있어 아이들에게 설명해주기 어려운 문제가 있다. 뭐, 관심있는 아이들은 낱말 뜻을 찾거나 물어보거나 서로 가르쳐주면서 조작하는걸 보면 크게 문제되지 않을 수도 있겠다. 뜻이 있으면 길은 닦으면 되니까…

XNA기반에서 3D를 구현하는데, XNA 개발 당시에 다국어를 염두하지 않아 다국어를 지원하려면 기초공사부터 다시 해야 한다고 한다…

가장 핵심적인 기본적인 제어명령은 아이콘으로 되어 있어서, 아이들에게 접근이 어려운 것은 아니다. 교사가 직접 만들어서 보여주기만 해도 금새 따라하고 응용까지 단숨에 이루어졌고, 푸근한 인상의 꽁지머리 아저씨의 튜토리얼을 통해 아이들끼리 무언가를 만들기 시작했다.

1인용 슈팅게임을 즉석에서 제작해 보여주고 얼마 쯤 실습시간을 주었는데, 학생들 몇몇이 소란스러워 가 보았더니… 어느 새 (컴퓨터에 관심이 많은) 한 학생이 2인용으로 만들어 친구와 슈팅게임을 즐기고 있었다. 2인용 게임이라니… 아이들은 정말 놀라운 존재다.

Cooool

  1. 3D 아케이드 게임을 제작할 수 있다는 것 자체가 대박
  2. 마우스와 아이콘으로 제어명령을 입력할 수 있어 매우 쉬움
  3. 제어 명령에 따라 오류없이 잘 동작함
  4. 부드러운 움직임과 귀여운 캐릭터들로 몰입도 높음

More

  1. 제작한 결과물을 공유하기 어려움. 배포판을 생성 할 수 있었으면…
  2. 기본적인 제어기능은 매우 쉬우나, 세부설정 메뉴가 직관적이지 않아 복잡
  3. 다국어를 지원하지 않아 세부설정이 다소 어려움
  4. 네트워크 협력플레이 기능을 바라는건 다소 무리일까?

 

2. MIT Scratch

공식사이트 : http://scratch.mit.edu/

MIT에서 교육 프로젝트로 제작한 저작도구이다. 명령행을 직접 입력하는 BASIC, JAVA 같은 프로그래밍 언어의 경우, 영어권 학생들에게는 얼마간 학습하면 쉽게 익숙해질 수 있을지 몰라도 비영어권의 학생들에게는 영어라는 언어부터 장애물이 된다. 하지만, 스크래치처럼 마우스로 (다국어로 번역된) 명령블럭을 이어붙이는 방식은 언어라는 큰 장애물을 극복할 수 있도록 해준다.

실제로 아이들과 함께 학습해보면, 컴퓨터에 대한 소질 여하를 떠나서 타이핑 없이 마우스로 작성하고 실행하여 디버깅하는 ‘프로그래밍’에 너무 쉽게 접근하여 자기만의 세계에 쉽게 빠져들었다.

 

 

스프라이트(오브젝트) 중심의 제어를 통해 손쉽게 프로그래밍을 학습할 수 있다. Windows, MacOS, Linux의 다양한 운영체제다국어 환경을 제공하여 환경제약이 적고, 스프라이트(객체)를 즉석에서 편집할 수 있는 도구들을 제공하여 아이디어만 떠올린다면 제작에 그리 큰 노력이 들지 않는다. 너무 많은 것을 바라지만 않는다면…

Cooool…

  1. 다양한 OS 플랫폼 지원 (Windows, MacOS, Linux)
  2. 한글을 지원하여 초등학생에게도 만족
  3. 블럭조립형으로 명령행을 타이핑하지 않아도 됨
  4. 즉각적인 실행과 확인으로 빠른 디버깅 가능
  5. 에디터를 통해 스프라이트(오브젝트)를 쉽게 생성/편집 가능
  6. 공식 페이지를 이용해 코드를 공유

More…

  1. 객체마다 코드가 산재하여 전체적인 흐름을 파악하기 어려움
  2. 저작도구의 성격이 강하므로 세련되고 정밀한 코딩은 무리
  3. 컴파일러나 패키징 도구가 없어 배포판 생성이 어려움

 

3. MS Small BASIC

공식사이트 http://smallbasic.com/

Mr. Bill을 감동시켰던 BASIC. GW-BASIC, Quick-BASIC, Visual-BASIC 시리즈들은 MS의 운영체제와 함께하고 있다. Mr. Bill 생전에 BASIC시리즈는 사라지지 않을 것이라고 이야기들 한다. MS-DOS기반의 Quick-BASIC(정식버전)은 컴파일러를 제공했고, 인터럽트(int13)제어, 어셈블러, C라이브러리를 이용할 수 있어 강력한 프로그래밍이 가능했다.

BASIC은 대화형으로 작성되고 명령문에 기호가 적어 학습용으로 훌륭한 언어라는 장점 위에 MS가 BASIC을 상당히 발전시켜 놓았다. 매우 똑똑한 에디터와 인터프리터 덕분에 메모리 구조와 형변환 같은 자질구레한 것에 크게 신경을 쓰지 않아도 되는 편리함을 제공하면서도 예상밖의 강력한 결과물을 만들어낼 수 있다.

 

 

Small BASIC은 Visual-BASIC의 기본 명령어 세트에 객체지향구조를 도입하고, 프로퍼티와 매소드들을 단순화시킨 버전이다. Visual Studio가 설치되어 있다면, 제작한 코드를 컴파일하여 배포할 수 있을 정도의 유용성을 제공하므로 프로그래밍에 조금 더 관심을 갖는 (고학년) 학생이 있다면 권장할만한 프로그래밍언어이다.

Coool…

  1. 객체지향형 프로그래밍 가능
  2. 프로시져, 모듈을 통한 구조적 프로그래밍 실습
  3. 지능형 Editor로 에러를 예방하거나 디버깅에 도움을 줌
  4. Visual Studio(무료)와 연계하여 완성(실행) 파일 생성 가능

More…

  1. 타이핑이 필요하여 간단한 영단어를 알고 있어야 함
  2. 0Byte 코딩은 간혹 뇌를 다운시켜 멍하게 만들기도 함
  3. 객체?? 객체지향?? 개념의 이해없이 깨끗하게 접근하면 별것 아닌 그 이름…

 

 

학생들에게 도움이 될만한 웹프로그래밍언어를 살펴보려 했으나, 솔직히 English 라는 아주 무거운 짐을 덜어야만 가능하다는 점 때문에 적용해 볼 수 없었다. HTML같은 Markup Language도 언어라면 언어라고 볼 수 있겠지만, 조건, 분기, 반복, 연산과 같은 기본기능을 구현할 수 없으므로 다소 무리라고 본다.

대신 Code.org를 마스터하고 이를 소개할까한다.
(Code.org 자체의 이해할 수 없는 에러들만 없다면 말이다)

공부의 과정으로서 컴퓨터 프로그래밍이란

나의 어린시절 꿈은 의사였다. 가난한 사람을 무료로 치료해주겠다는 생각… 시간이 지나 과학자에서 발명가로 꿈이 바뀐 까닭도 어려운 사람을 돕겠다는 이유 때문이었다. 컴퓨터과학자가 되기 위해 꿈꾸면서도 내가 만든 소프트웨어로 사람들이 편리해졌으면 좋겠다는 생각이었다.

컴퓨터를 접한건 초등학교3학년 시절… 친구의 집에 놀러가 MSX를 처음 만져본 이후 키보드 A를 누르면 화면에 A가 찍히는 모습을 보고 완전히 빠져들게 되었다.

손재주 때문에 책상 서랍이 온통 고물상 저리가라였고, 온갖 고물들을 조합해 무언가를 만들어내는게 일상이었다. 손이 베이고, 찔리고, 피부가 접착제에 녹아 쓰라리고, 인두에 데이고… 하지만, 컴퓨터는 이런 고통없이 내 뜻대로 움직이는 ‘마법’의 상자였다.

컴퓨터를 접하고 프로그래밍을 시작한건 중학교2학년 무렵, 8088cpu를 사용하는 XT 컴퓨터를 부모님께서 구입해주신 것이 계기가 되었다.

Quickbasic + Assembly + C로 시작된 장난이 정도를 지나쳐 광적인 수준으로 빠져들게 되었고… (자세한 이야기는 생략)

 

 

공부를 할 때도 프로그래밍 하듯 했다. 내 스타일대로 지식을 재창조하고, 구조화하고, 반복되는 부분들은 모듈화하거나 공식화하는 활동 속에서 지식의 공통된 구조를 찾기 시작했다.

전체 맥락을 보고 학습해야 할 부분을 세분화하여 효율성을 높이는 등의 꼼수를 통해, 그렇게 하고 싶던 컴퓨터프로그래밍 시간을 늘리고 공부시간을 줄일 수 있었다. 성적이 중간은 나와야 하니까…

그렇다고, 컴퓨터프로그래밍이 공부에 도움이 되기 때문에 억지로라도 해야한다며 강요하는건 접근 방식부터 잘못이다. 물론, 억지로라도 하다보면 강력한 중독성 때문에 나도 모르게 빠져들 수 밖에 없긴 하지만.

문제를 전체적으로 내려다보고 생각을 정리하고, 낭비를 줄이고, 재창조하고, 문제를 해결하는 활동 그 자체가 학습자에게는 커다란 도움이 되는 것은 분명하다… 경험상…

이렇게 나름대로 잘 짜여진 생각 구조를 만든 다음에는 카세트테잎 갈아끼우듯 생각 구조에 원하는 분야를 대입하면 의외로 잘 맞아떨어진다. 어차피 학문이라는건 학자들이 수많은 시간 고민하고 나름의 짜임으로 풀어낸 조각이니까… 내 생각 구조로 옮겨 심으면 왜 고민했는지 알게되고, 가설에서 결론을 위해 어떤 노력을 했을지 금새 감이 온다. (뭐, 안그럴 수도 있겠고)

이렇듯 아이들에게 프로그래밍이란 새로운 공부가 아니라, 앞으로 해야 할 공부를 돕는 하나의 과정이라 보면 맞을 듯 싶다. 개인적인 생각에, 컴퓨터프로그래밍에 깊게 파면 더 좋겠고…

컴퓨터프로그래밍  = 과학실험 = 수학적해결 = 짜임새있는글쓰기 = 미술디자인=

학문이란 깊게 파면 일맥 상통하니 말이다…

프로그래밍이지만 프로그래밍이라고 하지 않으면 더 재미있는 것…

해마다 한 가지씩 주제를 정해 아이들에게 프로그래밍에 대해 가르치면서 시행착오와 희망을 탐색중이다.

프로그래밍이라면 처음부터 컴퓨터프로그래밍을 떠올리겠지만…
프로그래밍이라는 것도 일종의 자동화기술이다. 실험실의 반복된 실험 절차나 기계의 동작 매카니즘과 똑같다.

파일압축기술이라 설명하지 않고, 규칙성 있는 숫자와 문자를 짧게 줄이고 반대로 만드는 방법을 연습시켜봤다. 의외로 잘 한다. 여자아이들도 어렵지 않게 압축된 코드를 원래대로 역해독하는데 성공했다.

픽셀그래픽이라는 설명하지 않고, 모눈을 칠해 캐릭터를 만들어보기로 했다. 0/1 매트릭스로 바꾸어 다시 캐릭터로 변환하고, 0/1/2/3으로 바꾸어 색을 입혀봤다. 5×5, 7×7, 10×10으로 처리해서 다이아모드, 하트 모두 완벽히 재현해 냈다.

데이터통신이라고 설명하지 않고, 앞서 가르친 픽셀그래픽을 숫자로 바꾸기로 했다. 시작은 흰색, 다음은 검정색. 523은 흰색 다섯 칸, 검정색 두 칸, 흰색 세 칸이 되는 것으로 약속하고 친구들에게 그림을 숫자로 바꾸어 알려주면 상대방은 다시 그림으로 바꾸어보았다. 시간이 걸리지만, 재미있어하고… 자기들끼리 생활에서 응용하기도 했다. (사실 이 데이터통신은 교생실습 때, 컴퓨터교육과 후배가 진행하는 모습을 보고 배운 것이다. 지도교사가 내가 아니었으므로 사전협의를 하지는 못했지만, 아직 멈춰있는 나의 픽셀그래픽을 데이터통신으로 업그레이드 하게 되는 계기가 되었다…)

시퀀스프로그래밍이라 설명하지 않고, 화장실까지 가는 모든 동작을 나열하게 했다. 의자에서 일어나서부터 화장실에서 볼일을 보고 돌아오는 모든 과정을 나열했다. 친구와 합쳐서 더 세밀하게 기록해보도록 했다. 신났다. 그 다음, 친구를 로봇으로 생각하고 순서대로 움직이게 하고 수정하도록 했다. 모두 상당한 수준의 로봇프로그래머가 되었다.

등등…

암호화는 ㄱ=a, ㄴ=b… ㅏ=0, ㅑ=1… 이런식으로 만들어가는 방법을 가르쳐줬더니, 아이들은 이미 ㄱ=r, ㄴ=s, ㄷ=e… 를 사용하고 있었다는 놀라운 사실… ㅎㅎ; QWERTY 키보드를 보고 만들었다나?

우리가 어려운 영어 써가면서 프로그래밍이다!로 시작하면 포기하기 일쑤일 것이다. 우리 교육현실에서는 아이들과 이런 놀이를 많이 할 수 없지만, 여러 교과의 구석구석에 이와 같은 놀이를 접목시킬 수 있다는 사실… 이런 활동을 언플러그드 컴퓨팅이라 한다던데…

이런 활동 후에 터틀그래픽, 플래시게임제작도구로 발전시켜
현재는 1인1PC와 KODU를 이용해 3D게임을 만들고 있는데…

내년에는 간단히 무한궤도차량이나 과학상자로봇으로 업그레이드를 해볼까 한다.

게임제작과 KODU 프로젝트

컴퓨터 게임

컴퓨터게임의 즐거움에 대해 이야기해서 무엇하리. 모바일 기기로 즐기는 성난새angrybird나 애들팡anipang과 같은 게임도 컴퓨터 게임이다. 오래되지 않은 과거만 하더라도 컴퓨터게임(이하 게임)은 애들이나 즐기는 것이라며 무시하던 시기가 있었다.

신경망 알고리즘

사실 컴퓨터게임의 역사는 컴퓨터 탄생의 역사와 맞먹는다고 볼 수 있다. 핑퐁pingpong을 알고 있을지 모르겠다. 다이얼이 유일한 컨트롤러이고, 사용자와 컴퓨터가 벽 또는 라켓을 맞고 튄 공을 뒤로 빠지지 않도록 받아 치는 게임이다. 이 게임은 단순히 레벨이 올라가면 점점 컴퓨터 라켓의 속도가 빨라지는 단순한 알고리즘부터, ‘신경망’을 이용한 인공지능 알고리즘을 적용하기도 한다.

신경망을 이용한 인공지능 알고리즘을 적용하면, 처음 한동안은 잘못 프로그래밍한 것으로 착각할 정도로 바보같이 움직인다. 가만히 서있다가 스코어 차이가 벌어지기 시작하면서 공 쪽을 이동하고 직선으로 튀어오는 공만 받을 수 있다가 벽에 맞아 튀는 공도 받아 칠 수 있는 수준이 된다. 게임의 결과는 굳이 꺼내지 않겠다. 내가 만든 코드에 감탄하면서도 승부에 집착하면 건강을 해칠 수 있다…

게임 중독

최근의 게임들은 기막힌 시나리오와 함께 고성능, 소형화된 개인용컴퓨터의 발달로 실사와 유사한 3차원 화면과 영화같이 화려한 액션이 가미되어, 한 번 빠져들면 헤어나올 수 없을 정도로 멋지게 제작되고 있다.

내가 봐도 멋진데, 아이들은 오죽할까. 특히나 요새 아이들은 컴퓨터 게임을 정말 좋아하고, 또 쉽게 빠져든다. 컨텐츠의 우수함도 한 몫 하겠지만, 사회적인 문제도 크다. 함께 놀 친구도 (학원가서) 없고, 부모님도 맞벌이 나가시고, 형제도 없는 상황에서 TV와 곰인형, 컴퓨터와 친구가 될 수 밖에…

나이, 학년, 학력의 수준과 상관없이 학생들에게 프로그래밍을 가르치는 건 결코 쉬운 일이 아니다. 프로그래밍이 어려워서가 아니고, ‘동기부여’가 되지 않기 때문이다. 설령 ‘동기부여’가 잘 되었다 하더라도 어느 정도의 사고력이나 문제해결력이 갖추어지지 않았다면 넘어야 할 산이 좀 더 많을 수 있겠다.

아이들이 즐거워하는 게임을 개발하는 것으로 동기부여를 하면 어떨까? 즐기는 게임을 벗어나 만들어 보는 게임이다.

RPG2000

한 때, RPG2000 이라는 롤플레잉게임RPG 제작 도구를 통해 프로그래밍을 시도했었다. 하지만,

  1. 유료SW이기 때문에, 라이센스를 구입해 컴퓨터실에 설치하기 곤란했고,
  2. 시나리오가 없으면 제작의 의미가 없었고,
  3. 심지어 바닥과 벽의 타일을 깔아서 배경을 만들어야 하므로 시간이 오래 걸렸고,
  4. 배우는 시간이 필요했다.

이런 점에서, 학생들과 교실에서 수업하려면

  1. 가능하면 무료로 교실과 가정에 보급이 가능해야 하고,
  2. 배우는 시간이 짧아야 하며,
  3. 문제 해결의 실마리를 인터페이스가 제공해야 하고,
  4. 즉각적인 수정과 재프로그래밍으로 재미를 높여야 한다.

프로그래밍을 이해하기 위한 첫걸음의 의미로도 RPG보다는 한 판짜리 아케이드 게임이 더 잘 어울린다. 즉각적인 피드백으로 오류를 찾아내고 조금 더 재미있게 재구성하는 과정에서 성취감을 느껴야 발전 속도가 빨라지게 마련이니까.

KODU Project

모든 것을 만족시킬 Microsft사의 프로젝트. KODU Project http://fuse.microsoft.com/page/kodu 를 소개한다.

banners-kodu

(게임에서 흔히 사용되는) 몇 가지의 필수 영단어들 – Load, Save, Mouse, Click, Left, Right 수준? – 을 알고 있거나, 영단어가 어렵다면 아이콘의 의미 정도는 알아낼 수 있을 정도의 상식만 있으면 어렵지 않게 원하는 아케이드를 제작할 수 있다.

더 놀랍고 흥미로운 사실은 2차원 상의 아케이드 게임이 아닌, 3차원으로 진행되는 게임을 만들어 볼 수 있다는 점이다.

KODU의 놀라운 점들을 정리해 보면,

  1. 키보드를 이용하는 복잡한 스크립트script 언어대신에, 조건문에 맞는 아이콘의 선택과 배열로 게임을 제작할 수 있다. Xbox 컨트롤러가 있다면 조금 더 게임을 즐기기 편하다.
  2. 별도의 랜더링이나 제작 과정에서 즉각적으로 수정하고 반영할 수 있다. 반응이 빠르고 부드러우며 논리오류를 발생시킬 여지가 적으며 확실하다.
  3. 변수/상수/분기/반복/조건문을 모르더라도 생각 자체를 그대로 구현할 수 있다. 구상하고 – 예상하고 – 제작하고 – 즐기고 – 고칠점을 찾고 – 다시 예상하고 – 제작하고 – 즐기는 반복이다.
  4. 놀이다. 그 자체로 동기부여와 친구간의 협력과 선의의 경쟁을 통해 더 나은 결과를 생산할 수 있다.

이런 의견의 뒷켠에는 ‘KODU’와 프로그래밍과의 연관성은 인정하지만, 그 과정이 ‘교육적’인 의미가 있느냐는 질문을 받게 마련이다. 질문자가 바라는 잘 디자인된 유의미한 활동의 ‘학교 안 교육’도 있겠지만, 학생들이 자발적 동기로 경험하는 활동 자체가 ‘학교 밖 교육’이라고 볼 수 있지 않은가? 라고 반문할 수 있지 않을까?

‘학교 안 교육’이라는 의미는 ‘잘 짜여진’ 교육과정과 교육 시스템, 교사에 의해 제공되거나 의도된 활동 속에서 깨달음을 얻는 ‘서비스’를 통칭한 것이다. 사교육도 마찬가지… 그 이외에 학생의 개인적, 사회적 경험을 통한 깨달음을 ‘학교 밖 교육’이라고 해보았다.

실제로 80분 수업에서 학생들의 KODU 학습 속도는 무척 빨랐다. KODU 안내 동영상을 같이 시청하면서 다른 영상을 보는 방법을 설명해주니 금새 따라하기 시작했고, (개인적으로 시도해본 적 없는) 2인용 게임까지 만들어 함께 진행하고 있었다. (ASDW키와 화살표방향키를 이용한 슈팅게임)

Installing Kodu video

KODU Install

First Game tutorial

KODU First Game

일부 학생들은 게임과 액션 자체에 흥미가 부족해 다른 친구의 작품을 ‘즐기는’ 정도에 머무르긴 했지만, 이렇게 친구가 게임을 만들 수 있다는 사실 자체를 학습한 것을 활동 결과로 평가하였다.

아쉬운 점

다만, 몇 가지 아쉬운 점은

  1. 친구간에 결과물을 네트워크를 통해 쉽게 공유해 즐길 수 있으면 어땠을까 하는 생각,
  2. 아니면, 게임을 패키징하여 친구와 주고받으면서 즐길 수 있도록 하면 좋겠고,
  3. 저학년을 위해 한글화를 지원했으면… (그저 바램일 뿐일 수도… 필수 라이브러리인 XNA의 Unicode Font 처리 문제가 있어서… 불가능해 보인다… 뚱뚱한 OpenGL이나 DirectX로 다시 탄생하면 모를까…)
  4. 게임의 시작과 종료에 실제 판매하는 게임처럼 멋진 인터페이스를 제공하면 어떨까 하는 생각 정도?

어떤 분야든 한 번쯤 ‘제대로 미쳐’보면, 다른 학문과도 쉽게 통한다고 한다. KODU는 한 번쯤 중독되어도 좋다고 본다.

– 추후 프로그래밍 이야기에서 KODU의 프로그래밍 요소를 추출하여볼까 한다. 이번엔 소개만~ ^^

 

맥노턴