[미디어창] KAIST 첫 공고 출신 입학생의 죽음 …좌절 감싸지 못한 '교육의 좌절'

    2011년 01월 11일 (화) 10:41:09     김창룡 인제대학교 언론정치학부 교수 ( cykim2002@yahoo.co.kr)    


자살하는 사람의 공통점은 ‘이 세상에 단 한 사람도 자신의 말을 들어줄 사람이 없다고 절망하는 상황에서 일어난다’고 한다. 세계 최고의 자살율을 기록하는 한국에서 그 많은 자살자의 수와 유형에 어찌 차별이 없을 수 있을까마는 어린 학생의 죽음은 자식을 가진 모든 부모의 가슴을 때리는 법이다. 더구나 카이스트같은 훌륭한 대학교에 진학한 학생이 제대로 꿈을 피워보지도 못하고 사라진다는 것은 국가적 손실이라는 차원에서 분명하게 짚고 넘어갈 필요가 있다.

숨진 A군은 2007년 국제 로봇 올림피아드 한국 대회에서 대상인 과학기술부 장관상을 받은 데 이어 2008년에는 국제 로봇 올림피아드 세계 대회에서 3등에 오르는 등 초등학교 2학년때부터 로봇 경진대회에 60여차례 참가해 뛰어난 실력을 보여왔다고 한다. 초등학교 4학년 때 과학경진대회에 참가해 최우수상을 받는 등 '로봇박사'로 불렸던 A군은 인문계고교를 다니다 로봇을 전문적으로 연구하고 싶다는 생각에 로봇 기능 전문계고로 전학까지 했을 정도였다고 한다.

이러한 재능덕분에 카이스트에 합격한 A군은 특히 영어로 수업이 진행되는 미적분학을 공부하는데 어려움이 컸던 것으로 알려졌다. 1학년 성적에 학사경고를 받을 정도여서 고민이 상당했다고 한다. 특히 영어는 한두학기만에 갑자기 성적이 오르는 과목이 아니어서 그의 갈등과 절망은 더욱 깊었으리라.

A군은 로봇분야에 관한한 매우 뛰어난 소질과 잠재력을 보인 것은 사실인 것 같다. 그러나 그에게 영어로 미적분학을 수학하 라고 지도한 것이 과연 적합했는지는 따져봐야 한다. 특정분야에 비범한 재능을 보인다고해서 영어강의를 수강할 정도의 수준을 갖췄다는 것은 아니다. 특별 재능을 가진 아이는 그 분야에서만 독특한 능력을 보였을 뿐 타분야는 평균이하일 경우도 종종 있었다. 미국의 유명 영화 감독 스필버그나 발명왕 에디슨 등도 학교 수업에는 크게 흥미를 느끼지못했거나 부적응자였다고 한다. 빌 게이츠의 경우 하버드 대학을 스스로 중퇴했을 정도였다. 타고난 천재성을 제대로 지도, 관리하지 못하게 되면 그것은 비극으로 끝나는 경우를 한국에서 종종 목격한다.

특별한 학생은 의외로 일상생활에서 오는 좌절과 갈등에 쉽게 대처하지 못하는 경우도 있었다. 자동차 경주 선수들은 차를 빨리 모는 법을 배우기전에 사고상황에서 어떻게 탈출하는 가를 먼저 배운다고 한다. 승리하는 법을 배우기 이전에 실패에서 탈출하는 법을 먼저 익히는 방식이다. 특별한 재능을 타고난 아이들에게 일상의 좌절과 갈등, 실패에서 먼저 극복하는 방법을 가르치고 체험시키는 것은 매우 중요한 부분이리라. 그들에게 ‘성공’ ‘일류대’를 외치기전에 작은 좌절과 실패를 먼저 경험하여 극복하도록 도와주는 것이 급선무다.

A군에게 카이스트의 선택은 어떤 것이었을까. 그가 공고생 최초로 카이스트에 합격했을 때 학교와 학부모 주변 사람들은 얼마나 환호했을까. 그는 주변의 과도한 기대와 자신의 부적응 사이의 현실적 갈등에서 헤어나지 못했던 것 같다. 그의 잠재력을 보고 선발한 카이스트의 입학사정관제에는 문제가 없는 것 같다. 문제는 선택받은 자가 그 학교와 운영방식에 대해 제대로 몰랐고 제대로 대응법을 찾아내지 못한 것으로 보인다. 특히 부모는 아이가 좋은 대학갔으니 모든 것을 믿고 맡긴다고 생각할 수 있지만 현실은 그렇지않다.

공고생출신이 과학고 출신들과 로봇이 아닌 공부로 경쟁해야 하는 상황은 이미 험난한 과정이 예고된 것이나 다름없었다. 언제든지 그만두고 나올 수 있도록 아이에게 선택의 부담감을 줄여줬어야 한다. 한국에서 카이스트나 서울대 등은 성공을 상징한다. 이런 대학기관을 중퇴한다는 것은 곧 실패를 의미하기 때문에 포기가 쉽지않다.

그러나 그런 것은 일반 학생들에 한정돼야 한다. 특별한 재능을 가진 학생에게 특정 조직은 특별한 굴레가 될 수 있다. 형식도 껍데기도 넘어설 수 있는 재능을 가진 아이에게 세속적인 기준과 한계를 보인 것은 아닌지...

           
      ▲ 김창룡 인제대학교 언론정치학부 교수.      

세 살때 천자문을 외우고 구구단 등을 뗀 한 영재(gifted child)가 있었다. 영국의 교육기관에서 공식적으로 인정한 영재 아이였다. 한국으로 돌아온 그는 강남의 사설영재학원들을 다녀봤지만 ‘평가’조차 제대로 받지못했다. 엉터리 영재학원들은 돈벌이에만 급급했다.

암기력이 뛰어난 그는 뭐든지 외우는데는 탁월한 재능을 보였다. 그러나 돌발행동, 컴퓨터게임에 빠지기 등 일상의 유혹에서 빠져나오지 못하거나 운동에는 전혀 소질이 없는 등 평균이하의 모습도 곳곳에서 나타났다.

수능1%안에 들어가는 학생이었지만 선행학습을 하지않은 관계로 고교내신성적이 좋지않았다. 그는 결국 서울의 한 대학교에 입학하지못했다. 그의 좌절감은 매우 컸지만 그의 성취와 능력을 더욱 인정하고 용기를 주는 일이 더욱 절실했다. 실패감속에 눈물까지 보였던 그는 한 동남아 국가로 가서 그곳에서 편입전 문 대학교를 다녔다. 작은 좌절과 시련의 연속이었지만 그런 생활속의 어려움을 극복하는 것은 매우 훌륭한 교육이라고 판단했다. 그의 미래가 어떻게 될 지는 모르지만 성공이전에 좌절과 실패에서 극복하는 과정과 그 가치를 먼저 익히는 노력이 필요하다고 믿는다.

학생의 실패는 모든 교육자의 좌절이다. 특히 재능이 뛰어난 학생의 절망은 한국대학교육의 실패를 의미한다. 강의생활 10년을 넘겼지만 어떻게 해야 매학기 강의에 혼과 정열을 불어넣을 수 있을지, 어떻게 소외되고 좌절하는 학생의 고민을 털어놓게 할 수 있을지 늘 반성과 고민이 앞선다. 어린 학생의 좌절에 슬픔이 깊은 날이다.

경우에 다라 두가지 정도의 의미로 사용되는 용어입니다.

< 18/40/60 법칙  >
나는 60년을 넘게 살아오면서 '18/40/60'법칙에 놀라운 지혜가 담겨 있음을 점차 확신하게 되었다.

18세에는 다른 사람이 자신을 어떻게 생각하는지 걱정한다.
40세에는 다른 사람이 자신을 어떻게 생각하든 신경쓰지 않는다.
그러나 60세에는 당신에 대해 생각이라도 해본 사람이 아무도 없었다는 것을 깨닫게 된다!

Hence, we don't need to be conscious of the eyes of others.

1. 출력을 하다보면 모양새 좋게.. 혹은 원하는 포맷으로 출력하고 싶을 때가 있다.

setiosflags

먼저 - http://www.cplusplus.com/reference/iostream/manipulators/setiosflags/
를 참고 하자.

위 링크에 아래쪽을 보면

See also

ios_base::flags

Get/set format flags (public member function)

구문들이 있다.
이들도 보는 참고하는 것이 좋겠다.


cout.flags ( ios::left );

C++에서 ifstream으로 파일을 읽다가 다시 그 위치를 처음으로 돌리고 싶을때

가끔 is.seekg(0, ios::beg); 이게 먹히지 않는 경우가 발생한다.

처음에는 결국 해결 방법을 못 찾아서 파일을 닫고 다시 열어서 읽었던 기억이있다.

혹시나 다음과 같은 경우라면 해결 방법이 있다.

다음->     파일을 끝까지 읽어 EOF(End Of File) 까지 간경우 bad() state 이기 때문에 clear()를 seekg 전에 써줘야 한다.

-      data.clear();

-      data.seekg(0);

Since you've gone till the EOF, the stream is now in a bad() state. You need to clear() it before you can seekg():

Reference : http://www.gamedev.net/community/forums/topic.asp?topic_id=447865

Assignment 5 개로 이루어져 있다.
Symbol Table 25
Expression 35
Pass1 45
Pass2 50
Link Loader..

각각의 점수를 보듯이..Pass2에 가장 많은 시간이 들어간다.

오늘이 Pass2의 Due..

C++ 특히 ..모듈화, 이 부분을 다시 생각하게끔 만드는 숙제인 것 같다.

짜면짤수록 쓰레기 value들 스파게티소스가 되버리는등.. 시간만 허락한다면

Readability 를 좋게 만들수 있을텐데..


제일 많이 느끼는건 Pseudo code를 많이 써보는 연습을 하는게
훗날 시간절약하는데 많이 도움이 될것 같다.

깨달음은 참 쉽다

 단지 한가지 필요하다면 변하려 한다는 의지가 확고한 사람이다

 하지만 경험해 보아서 알지만 어느정도 고통을 받아야 사람들은 변화하려고 한다

 처음에는 약한 고통으로 시작해 변화하려는 의지가 빈둥빈둥 이지만

 그 고통이 중간쯤 되면 약간 의지를 갖고 변화하려다 원상태로 돌아오고

 그 고통이 극에 달할때 사람들은 그제서야 진짜 변화를 시작 하려 한다

 이래서 사람들은 고통이 필요하다 물론 예외도 있겠지만이다

  

다른 말은 쓰지 않겠다

단지 이 말들을 집중해 주길 바란다

 나 자신을 그냥 사랑하자

 무슨일이 있어도 나를 사랑 하는 것이다

 사람들에게 상처를 받아도 나를 사랑하고

 원하는 일이 되지 않아 빈털터리가 되어도 나를 사랑하고

 배우자가 없어도 나를 사랑하고

 모든 사람이 나를 싫어해도 나는 나를 사랑해야한다

 나 자신을 사랑하는건 절대 쉬어서는 안되는 일이다

 

 여기서 또 이런생각을 하는 사람이 있을 것이다

 그래도 이상황은 절대로 사랑할수 없는 상황이다

 시크릿의 말을 빌리자면 지니는 그상황을 더욱더 사랑할수 없게 만들것이다

 두려움도 중독이다 당신이 두려움을 그렇게 느끼기를 바라니 두려움을 느끼는것이고

 사랑을 느끼기 바라면 당신은 삶을 후회없이 살수 있을 것이다

 

절대 사랑할수없다는 말은 하지말자

 아니 그것 역시 사랑하자

 사랑하고 사랑하다보면 세상은 사랑으로 바뀔것이다

 세상이 사랑으로 바뀌 었다는것을 보고난뒤 나를 본다면

 사랑 그자체 경이로움의 대상일 것이다

 

 사랑할수 없는 이유는 없다 단지 당신이 사랑을 하지 않는것일 뿐이다

 사랑하자 사랑은 축복이다

 

가장 중요한것은 숨쉬듯 사랑하는것이다 이말을 흘려들을수도 있다 나역시 그랬으니까

 하지만 제일 중요한것이 숨쉬듯 사랑하는것이다

 이것을 잊지 말기를 부탁한다

[출처] 사랑하자 무엇이든 사랑하자 (비욘드 더 시크릿 Beyond the secret) |작성자 비밀

 

Data type의 equility를 비교할 때, Name equivalence와 Structural equivalence의 두가지 컨셉이 있습니다.

Name equivalence

Name equivalence는 두 data type의 type name이 같을 때만 data type이 같다고 봅니다. 즉 type name Vect1을 가진 X와 Z는 대입이 되지만(X := Z), X := Y(Vect2)는 대입이 불가능합니다.

/* Figure 1 Type equility*/

program main(input, output);

type Vect1: array[1 .. 10] of real;
Vect2: array[1 .. 10] of real;

var X, Z: Vect1; Y: Vect2;

procedure Sub(A: Vect1);
...
end;

begin - main program
X := Y;
SUub(Y)
end.

• 대입 연산에 사용되는 모든 data object가 type name을 가져야 합니다. 즉, anonymous type이 존재하지 않습니다.
• Data object가 subprogram의 argument로 전달될 때, data type이 재정의될 수 없습니다. 즉, Single type definition이 프로그램 전체 범위를 지원해야 하므로 global type definition이 사용되야 합니다.

Structural equivalence

Structural equivalence는 두 data type의 internal components가 같을 때 data type이 같다고 봅니다. Internal components가 같다는 뜻은 Storage representation이 같다는 것을 의미하기 때문입니다.

Figure 1의 Vect1과 Vect2는 Name equivalence의 관점에서는 다른 data type이지만 Structural equivalence의 관점에서는 component의 number, type, order가 같기 때문에 같습니다.

/* Figure 2 Structural equivalence */

type Meters = integer;
Liters = integer;

var Len: Meters;
Vol: Liters;

• Component의 이름, type, 순서가 같은가? 만약 component가 배열일 경우 subscript range가 같은가? 하는 미묘한 차이점으로 인한 문제가 발생할 수 있습니다.
• Figure 2와 같이 프로그래머가 다른 type으로 선언했지만 우연하게 Structural equivalence에 따라 같은 data type으로 인식되어 static type checking에 걸리지 않을 수 있습니다.
• Type checking을 위해서는 data type의 structure를 모두 검사해야 하기때문에 매우 costly합니다.

 

이 글은 Visual Studio에서 프로젝트 작성시 #pragma once 가 붙는 이유의 궁금증에서 시작된 http://second815.tistory.com/entry/pragma-once-why-it-is-always-attached-when-we-making-new-class-file-in-visual-studio 글에서 시작된 관련 포스트이다.



Reference: 원문
http://kin.naver.com/qna/detail.nhn?d1id=1&dirId=1040101&docId=66305804&qb=I2lmbmRlZg==&enc=utf8&section=kin&rank=2&sort=0&spq=0&pid=fIH9fg331xCssaC5UHVssv--070546&sid=S652MnMdrksAAD-ZjGM

Abstract:

Ex Code :
#include <stdio.h> #define WORD 1 int main( void ) { #ifdef WORD printf("Hello, "); #endif #ifndef WORD2 printf("world\n"); #endif #ifndef WORD printf("HaHa\n"); return 1; }

자 하나씩 설명에 들어간다. 먼저 #define

#define WORD 1 = 이것은 WORD를 1로 치환
너무나 잘 알고있는 매크로 ..

그리고 궁극적으로 알고자 했던 명령어
#ifdef WORD
 printf("Hello, ");
#endif

 여기서 #ifdef WORD 라는것은
                              'WORD란 단어가 define가 되어있다면' 
즉 WORD란 단어가 위에서 #define WORD 으로 define되어 있으므로 참이 되고
그 다음줄 printf("Hello, ");가 실행

endif는 '{' 가 쓰이면 '}' 로 항상 닫아주는 녀석과 같은 역할을 한다!
#endif 
#ifdef 구문이 끝났음을 알림.

이 문은 #ifdef 나 #ifndef를 선언했을때 필수적으로 짝을 맞춰야 한다.
즉 #ifdef 를 한번 선언했다면 #endif 한번, #ifdef를 두번 선언했다면 #endif를 두번 선언해야
한다.

#ifndef .. 이걸 이용함으로써 컴파일러가 헤더파일을 두번 컴파일 하지 않게 한다!
 #ifndef WORD2 도 비슷.
이것은 #ifdef와는 반대로
                           'WORD2란 단어가 define되어 있지 않다면'
이란 뜻.
즉 WORD2란 단어는 위에서 #define에 의해 define된 적이 없으므로 참이되고
그 다음줄 printf("world/n");이 실행.

 #ifndef WORD
 printf("HaHa\n");

에서는 #ifndef WORD에서 WORD는 이미 define되어 있으므로 거짓이 되서
그 다름줄인  printf("HaHa\n"); 가 실행되지 않는다

즉 출력결과는 Hello world 가 된다!

#pragma once 를 쓰는 이유에 대해 포스팅했었다.
간단하게 이유를 설명하자면 여러개의 헤더파일과 cpp파일이 있을때
컴파일시 h파일을 중복되서 컴파일함을 없애주기 위해서이다.

http://second815.tistory.com/3  #pragma once 를 쓰는 이유

그러나 #pragma once는 표준이 아니다!

http://ptah.tistory.com/16
에서 다음과 같은 내용을 퍼왔다. 아래에 카피해두었다.

http://neodreamer.tistory.com/310
확실히 개념이 서질 않는다면 이 링크의 글을 읽어본다. 가장 명확한듯하다.


그전에  #ifdef, #ifndef, #endif 에 대해 알고싶다면
http://second815.tistory.com/5 를 읽어본다.



http://neodreamer.tistory.com/310 의 내용

보통 Visual Studio 계통의 소스에서는 #progma once를 자주 보게 됩니다.
그러나 GCC 계통의 소스에서는 보기가 힘들죠. (전 아직 뵌적이 없습니다.)

결론부터 말하자면 저라면 #ifndef 를 사용하겠습니다.
아직 #progma once는 표준이 아니기 때문이죠.
C99는 다음과 같은 표준을 가지고 있다고 합니다.

#pragma STDC FP_CONTRACT on-off #pragma STDC FENV_ACCESS on-off #pragma STDC CX_LIMITED_RANGE on-off on-off := ON | OFF | DEFAULT

추가적으로 VS에서는 #progma가 컴파일 속도가 더 빠르다고 합니다.
#progma once를 만나자마자 건너뛰어서라는데 얼마나 빠를지는...

따라서 저의 경우 헤더에 다음과 같이 적습니다.

#progma once #ifndef __ANY_THING__ #define __ANY_THING__ ... #endif

http://neodreamer.tistory.com/310의 내용

C++ 프로그래밍에서 헤더의 중복 #include 를 방지하는 방법으로 #pragma once 와 #ifndef 를 활용하는 방법이 있다. 이 두 방법은 모든 컴파일러에서 동작하는 것은 아니다.

우선 사용법을 보면 #pragma once 의 경우 헤더의 상단에 한번 적용 하면 된다.
#pragma once class something { int a; public: something(); ~something(); int getA( void ) { return a; }; void setA( int a1 ) { a = a1; }; }

그리고 #ifndef 를 활용하는 방법은 아래 처럼 define 이 되지 않았을 경우 지정된 값을 지정하여 이후에 다시 불러 들이는 것을 방지한다.
#ifndef __SOMETHING_H__ #define __SOMETHING_H__ class something { int a; public: something(); ~something(); int getA( void ) { return a; }; void setA( int a1 ) { a = a1; }; } #endif // __SOMETHING_H__

위 두 가지 방법은 여러가지 면에서 차이가 있다.

우선 첫 번째의 경우인 #pragma once 의 경우 컴파일러 지시자로 이를 한번 인식한 후 다음부터 같은 파일의 경우 파일을 읽기조차 하지 않는다. 그래서 컴파일 단계의 파일 해석 단계는 두 번째 방법보다 빠르다. 하지만 컴파일러 지시자로 특정 컴파일러에서만 동작을 한다. 이 지시자는 Visual C++ 5.0 이상에서만 동작을 한다.

두 번째의 경우 모든 컴파일러에서 동작을 하지만 헤더 파일을 여러번 include 를 할 경우 매번 헤더 파일을 열어서 define 여부를 확인해야 하기 때문에 컴파일 과정인 파일 해석 단계에서 첫 번째 방법보다 다소 느리다.

두 가지 방법은 속도와 호환성 문제가 얽혀 있는데 무지 큰 프로젝트가 아닐 경우 속도에서는 크게 차이가 나지 않을 것 같고 Visual C++ 에서만 작업하는 것이 아니라면 호환성을 고려하여 두번째 방법을 사용하는 것이 좋아 보인다.