겉보기엔 데브옵스와 인공지능...그 밑에 흐르고 있는 ‘본질’은?
컴퓨터 관련 교육의 두 가지 핵심 사안...코딩과 목적성
[보안뉴스 문가용 기자] 정보보안의 관점에서 본 해외 IT 분야의 지난 반년은 ‘데브옵스’로 정리가 가능하다. 앱 하나를 통째로 만드는 대신 기능별로 잘게 쪼개서 동시에 개발을 진행하고 나중에 필요한 것들만 가져다 붙이는 이 개발 방법론이 각광받고 있는 이유가 있다. 앱 출시를 빠르게 해주고, 잘게 쪼갠 각 요소들(마이크로서비스라고 부른다)을 재활용해 새로운 결과물을 금방 또 만들 수도 있게 되며, 보안을 더 꼼꼼하게 점검할 수 있게 해주기 때문이다.
데브옵스를 위한 변화들 중 자주 언급되는 것
하지만 ‘지난 반년의 키워드가 데브옵스’라고 할 때 고개를 끄덕이는 독자보단 갸웃거리는 쪽이 더 많을 것으로 예상된다. 전문가의 칼럼이나 매체에서 다루는 것만큼 실제 현장에서의 적용 사례가 많지 않기 때문이다.
그게 데브옵스든 워터폴이든, 개발의 방법론 자체를 완전히 바꾸는 건 운영체제나 핸드폰 바꾸는 것과는 차원이 다른 일이다. 중앙에서 관리를 해야만 직성이 풀리는 부서장, 처음부터 내 손으로 직접 만들어야만 하는 완벽주의 개발자, 개발이든 보안이든 고객관리든 정해진 부서에서 내 기능만 제대로 발휘하면 밥값을 다 한 거라고 생각하는 직원들이 하나하나 모여서 만들어진 기업 문화가 송두리째 바뀌어야만 데브옵스를 적용시킬 수 있다는 전문가들의 의견이 과장이 아닌 것이다.
데브옵스 도입이라는 주제 안에서는 항상 나오는 이야기들이 있다. 새로운 앱을 개발한다는 사례 안에서 정리하면 대략 다음과 같다.
1) 조직 차원에서 앱 출시가 갖는 의미와 목표, 비전을 모두가 공유해야 한다. 그래야 2)번이 가능하므로.
2) 사전에 공유된(단순히 ‘공지된’이 아니라) 목표 아래 서로 다른 전문분야에 대한 지식을 어느 정도 갖추고 있어야 한다. 그래야 3)번이 가능하므로.
3) 첫 기획 회의 때부터 개발, 보안, 배포, 고객 상담, 법무 팀 등 모든 부서가 참여해 의견을 조합해 나가야 한다. 앱이 탄생하는 전 과정 동안 참여자가 자기 부서 입장만 고집할 것이 아니라 최대한 배려하고 타협점을 찾아 ‘되는 방향’으로 가야 한다. 그래야 4)번이 가능하므로.
4) 이러한 방식으로 운영되는 소그룹들이 프로젝트별로 생겼다가 사라졌다가 할 수 있어야 한다. 그래야 데브옵스가 정착한 것이므로.
데브옵스를 위한 변화들, 공동체 정신 강조하는가?
어떤 느낌인가? 일견 융화력이나 희생정신, 혹은 공동체 정신을 강조하는 것처럼 보인다. 하지만 실상은 그렇지 않다. 다시 한 번 위에서 언급된 내용들을 살펴보자.
1) 먼저, 비전과 목표를 공유해야 한다고 한다. 특기나 지위, 맡은 역할이 다 달라도 지향하는 바가 같아야 한다는 것이다. 이는 어느 조직에 있더라도 개개인에게 요구되는 바니 넘어가자. 그러나 이게 사실은 제일 무서운 부분이다. 뒷부분에 설명을 이어가겠다.
2) 다음은 ‘다른 기능들을 이해하고 있어야 한다’는 것이다. 그런데 이건 ‘서로의 차이를 이해하라’거나 ‘술 한 잔 하면서 친해져라’라는 걸 넘어선다. ‘앱’이나 ‘소프트웨어’라는 전문적인 결과물을 함께 만들어내려면 코딩이 어떤 방식과 논리로 진행되는지, 보안 관리는 구체적으로 어떤 일을 포함하고 있는 건지, 고객들이 주로 어떤 상담을 해오는지, 법에 저촉되는 사안이 뭐가 있는지 등을 꽤나 높은 수준으로 파악해야만 한다. 그게 아니면 같이 일을 하면서 ‘잘 몰라서 하는’ 양보밖에 할 수 있는 게 없게 된다. 그런데 이는 위험하다. 프로젝트 팀 단위가 소수이기 때문이다. 소수로 움직일 때는 실수가 크게 부각되기 마련이다.
3) 기획 회의 때 의견을 조합하라고 하는 것 역시 소프트웨어나 앱을 빈틈없이 만들기 위한 것이므로 그저 서로 양보하고 희생하고 넘어가라는 게 아니다. 이상적인 데브옵스 체제에서 소수의 팀으로 뭉쳤다가 흩어졌다가 하려면 자기가 맡은 기능을 완벽하게 수행해야 한다. 소수가 움직이기 때문에 ‘빵꾸’가 날 때 확연하게 눈에 띌 수밖에 없기 때문에 양보나 희생이 미덕이 되지 못한다.
2)~3)번을 합하면 어떤 결론이 나오는가? 화합과 하모니의 아름다움을 강조한 것처럼 보이지만 사실은 극단적일 정도로 개인의 뛰어난 능력을 요구한다는 것이다. 혼자서 어지간한 분야들을 다 높은 수준으로 이해하고 있어야만 하고, 맡은 역할을 빈틈없이 해내야만 한다.
여기에 애초에 데브옵스가 부각되기 시작한 ‘출시 속도’까지 끼얹어 보자. 그야말로 기계의 부품처럼 한 사람 한 사람이 각자의 기능을 고장도 없고 양보도 없이 발휘해야 한다. 페론 로보틱스(Perrone Robotics)의 수석 엔지니어인 에릭 브루노(Eric Bruno)가 “시야가 넓은 장인정신이 강조될 것”을 예측하는 것도 이런 맥락에서다.
장인이 되어야 하는 또 다른 이유, 인공지능
한 사람 한 사람의 뛰어난 기능이 요구되는 시대로 나아가고 있다는 증거가 또 있으니 바로 ‘인공지능’의 가파른 발전 속도다. 알파고의 출현 이후 대중들에게도 큰 관심을 받고 있는 기술인 인공지능은 최근 인간 바둑기사 중 최고수인 커제 9단까지 압도적으로 누르는 데 성공했다. 게다가 아마존 알렉사나 아이폰 시리의 등장으로 인공지능은 우리가 깨닫기도 전에 일상으로 들어와 버렸다. 이미 인공지능에 밀려 직장을 잃은 사람도 있을 정도다.
인공지능 기술이 사람의 경쟁상대로 우려된다는 것 자체가 이미 사람을 한 조직의 ‘기능’으로서 보고 있다는 뜻이다. 4차 산업혁명이 언급되고 있는 때, 어쩐지 최초 산업혁명으로 회귀한 느낌 아닌가? 사람은 기계로 대체해도 될 만큼의 것으로서 인식되고 있다. 에릭 브루노는 “인공지능을 앞세운 자동화 문화 역시 데브옵스의 중추적인 요소가 될 것”이라고 예상하고 있다.
데브옵스가 만들어가는 환경에서부터 인공지능의 추격까지, 인간은 계속해서 발전하고 공부하고 실력을 키워갈 수밖에 없는 처지에 놓이게 되었다. 그것이 ‘데브옵스’라는 형태로 굳어진 지표면 아래서 들끓고 있는 마그마의 정체다. 그리고 그것이 진정한 지난 상반기에 대한 결산이다.
인공지능이 우리의 일자리를 위협한다는 그 케케묵은 이야기가 아니다. 우리가 생각하는 것보다 더 심각한 경쟁 구도로 자연스럽게 내몰리고 있다는 것이다. 왜? 이야기를 처음으로 돌리면 답이 있다. 앱의 빠른 출시라는 공동의 목표와 비전 때문에 위에서 이 부분이 가장 무서운 부분이라고 한 것은, 이 어설픈 공동체 정신이 빠른 경쟁 구도에 놓인 사람의 눈을 가리기 때문이다.
무엇을 위해 발전하는지, 큰 그림 안에서 현재 위치가 어디인지 생각해볼 새도 없이 그저 하루하루 ‘기능 발휘’에만 집중하다보면 했던 실수를 반복하게 하고, 배움을 멈추게 만든다. 4차건 5차건 그 옛날 1차건, 산업혁명이란 것과 지금의 상황에 기시감이 느껴지는 것도 다 그 때문이다. 어쩌면 가장 발전된 인공지능은 그렇게 맹목적으로 자기발전을 해버린 인간이 아닐는지.
데브옵스로 향하고 있다는 걸 알려주는 지표들
그렇다면 지금 우리는 어디쯤에 있을까? 지금은 상상도 할 수 없는 그 무한 속도의 경쟁 구도 속에 이미 돌입했을까? 데브옵스가 아직은 막 퍼지기 시작한 때이니 그렇지는 않다. 하지만 분명히 그 방향으로 가고 있긴 하다. 이를 알려주는 지표들이 어느 정도 존재한다. 공식적인 건 아니지만 대략 다음과 같다.
1) API와 클라우드의 활용이 부쩍 늘어나기 시작했다. 레고 블록 하나하나처럼 잘게 쪼개진 각각의 부품들, 즉 마이크로서비스가 조립될 수 있게 해주는 게 바로 이 API이고, 데브옵스의 핵심 가치라고도 볼 수 있는 ‘유연성’을 극대화시켜주는 게 클라우드이다.
2) 도커(Docker)라는 콘테이너(container) 기술이 널리 활용되기 시작했다. 콘테이너는 마이크로서비스를 담아두는 그릇이다.
3) CD와 CI란 개념이 활용하기 시작했다면 두어 걸음은 더 발을 떼었다고 볼 수 있다. CD는 지속적인 배포, CI는 지속적인 통합을 의미하는 약자로, 마이크로서비스가 유기적으로 붙었다 떨어졌다 조립됐다 재활용됐다 하는 그 과정 자체를 말한다.
4) 여기에서 조금 더 나아가면 오케스트레이션 기술에 자연히 관심이 쏠리게 된다. 많아진 콘테이너와 마이크로소프트를 사방팔방으로 흩어놓을 수가 없으니, 이것 역시 한 데 모아야 할 필요가 있는데 그때 필요한 것이 오케스트레이션 기술이다.
미래, 어떻게 대비할까?
이 흐름을 막을 수는 없다. 그래도 우리는 괜찮다. 다만 우리 자식들이 지금과는 다른 경쟁 구도 속에서 살아갈 것은 거의 확실하다. 보안 업체 CA의 아태지역 CTO인 스티븐 마일스(Stephen Miles)는 “코딩 교육이 답”이라고 말한다. 리서치 전문기관인 TRPC의 림 메이앤(Lim May-Ann)도 마찬가지다. 뉴욕타임즈는 지난 6월 27일 실리콘 밸리가 미국 교육 과정에 코딩을 넣으려고 한다는 보도를 한 바 있다. 애플의 팀 쿡도 이런 움직임에 동참하는 사람 중 하나다. “코딩은 모든 공공학교의 교육 과정에 포함되어야 합니다.”
우리나라에서는 코딩 교육이 ‘초등학교 교과 과정’이라는 민감한 사안과 맞물려 첨예한 논란의 대상이지만 해외 보안 컨퍼런스에 참석해보면 ‘코딩 교육이 앞으로 더욱 중요해질 것’이라는 의견들을 많이 들을 수 있다. 초등학생 때부터 개발자를 목표로 코딩을 가르치라는 게 아니라, 미래에는 코딩이 기본 상식이 될 거라는 데에 모두가 동의하고 있다.
스티븐 마일스와 림 메이앤은 “실제로 우리 아이들에게 코딩을 배우라고 한다”고 말하며 그 이유에 대해 “미래 사회에서 코딩은 마치 현대 문명 사회의 읽기, 쓰기와 같은 기능을 할 것이기 때문”이라고 설명한다. 이는 Code.org의 설립자인 헤이디 파르토비(Hadi Partovi)의 “컴퓨터 과학은 산수나 언어 학습과 똑같은 중요도를 가지고 있다”는 설명과 일치한다.
이들은 “경쟁 구도에서 살아남기 위해 미리 개발을 가르치라”고 말하는 게 아니다. 아이들이 커서 자기 주위에서 무슨 일이 벌어지고 있는지 제대로 조사하고 직접 파악할 수 있도록 준비시키라는 것이다. 마치 국제화된 시대를 위해 영어를 배우듯, 과학이 발달한 시대에 수학을 익히듯, IT 기술의 시대엔 IT 언어로 더 많은 기회를 보장받으라는 것이 크게 억지스럽지는 않다. 다만 지금으로선 상상이 안 될 수는 있다.
또한 컴퓨터를 일찍부터 ‘도구’로서 배우는 것도 중요하다. 컴퓨터 교육학을 전공해 주중엔 금융회사의 IT 담당자로 근무하고 주말엔 아이들 대상으로 컴퓨터 교육 봉사활동을 펼치는 익명의 전문가는(인터뷰 동의를 회사로부터 구하지 못했다) “도구라는 걸 매 수업 시간 강조한다”고 말한다.
“도구로서 컴퓨터를 가르친다는 건, 사용하는 목적이 있을 때만 컴퓨터를 켜는 훈련과도 맞물립니다. 인터넷을 통해 회원가입을 하는 것, 자신의 개인정보를 누군가에게 전달하는 것, 사진을 업로드하는 것 모두 ‘목적이 분명할 때만’ 하도록 가르칩니다. 자연히 보안 교육도 되더군요. 각종 중독 예방에도 도움이 되리라 보고 있고요.”
특이하게도 그는 ‘리눅스 시스템’에서 아이들을 가르친다. 일단 무료라 아이들 편에서 교육비가 덜 부담스럽기 때문이기도 하지만 “다가오는 사물인터넷 시대에 가장 많이 사용될 것으로 보이는 리눅스 체제에 대비케 하기 위해서”이기도 하다. 아직 코딩 교육까지는 진도가 나가지 않았다. “컴퓨터의 ‘주인’으로서 태도를 교육하는 것이 먼저입니다. 이 부분을 확실히 하고 나면 코딩 교육도 진행할 예정입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
컴퓨터 관련 교육의 두 가지 핵심 사안...코딩과 목적성
[보안뉴스 문가용 기자] 정보보안의 관점에서 본 해외 IT 분야의 지난 반년은 ‘데브옵스’로 정리가 가능하다. 앱 하나를 통째로 만드는 대신 기능별로 잘게 쪼개서 동시에 개발을 진행하고 나중에 필요한 것들만 가져다 붙이는 이 개발 방법론이 각광받고 있는 이유가 있다. 앱 출시를 빠르게 해주고, 잘게 쪼갠 각 요소들(마이크로서비스라고 부른다)을 재활용해 새로운 결과물을 금방 또 만들 수도 있게 되며, 보안을 더 꼼꼼하게 점검할 수 있게 해주기 때문이다.
[이미지 = dreamstime]
데브옵스를 위한 변화들 중 자주 언급되는 것
하지만 ‘지난 반년의 키워드가 데브옵스’라고 할 때 고개를 끄덕이는 독자보단 갸웃거리는 쪽이 더 많을 것으로 예상된다. 전문가의 칼럼이나 매체에서 다루는 것만큼 실제 현장에서의 적용 사례가 많지 않기 때문이다.
그게 데브옵스든 워터폴이든, 개발의 방법론 자체를 완전히 바꾸는 건 운영체제나 핸드폰 바꾸는 것과는 차원이 다른 일이다. 중앙에서 관리를 해야만 직성이 풀리는 부서장, 처음부터 내 손으로 직접 만들어야만 하는 완벽주의 개발자, 개발이든 보안이든 고객관리든 정해진 부서에서 내 기능만 제대로 발휘하면 밥값을 다 한 거라고 생각하는 직원들이 하나하나 모여서 만들어진 기업 문화가 송두리째 바뀌어야만 데브옵스를 적용시킬 수 있다는 전문가들의 의견이 과장이 아닌 것이다.
데브옵스 도입이라는 주제 안에서는 항상 나오는 이야기들이 있다. 새로운 앱을 개발한다는 사례 안에서 정리하면 대략 다음과 같다.
1) 조직 차원에서 앱 출시가 갖는 의미와 목표, 비전을 모두가 공유해야 한다. 그래야 2)번이 가능하므로.
2) 사전에 공유된(단순히 ‘공지된’이 아니라) 목표 아래 서로 다른 전문분야에 대한 지식을 어느 정도 갖추고 있어야 한다. 그래야 3)번이 가능하므로.
3) 첫 기획 회의 때부터 개발, 보안, 배포, 고객 상담, 법무 팀 등 모든 부서가 참여해 의견을 조합해 나가야 한다. 앱이 탄생하는 전 과정 동안 참여자가 자기 부서 입장만 고집할 것이 아니라 최대한 배려하고 타협점을 찾아 ‘되는 방향’으로 가야 한다. 그래야 4)번이 가능하므로.
4) 이러한 방식으로 운영되는 소그룹들이 프로젝트별로 생겼다가 사라졌다가 할 수 있어야 한다. 그래야 데브옵스가 정착한 것이므로.
데브옵스를 위한 변화들, 공동체 정신 강조하는가?
어떤 느낌인가? 일견 융화력이나 희생정신, 혹은 공동체 정신을 강조하는 것처럼 보인다. 하지만 실상은 그렇지 않다. 다시 한 번 위에서 언급된 내용들을 살펴보자.
1) 먼저, 비전과 목표를 공유해야 한다고 한다. 특기나 지위, 맡은 역할이 다 달라도 지향하는 바가 같아야 한다는 것이다. 이는 어느 조직에 있더라도 개개인에게 요구되는 바니 넘어가자. 그러나 이게 사실은 제일 무서운 부분이다. 뒷부분에 설명을 이어가겠다.
2) 다음은 ‘다른 기능들을 이해하고 있어야 한다’는 것이다. 그런데 이건 ‘서로의 차이를 이해하라’거나 ‘술 한 잔 하면서 친해져라’라는 걸 넘어선다. ‘앱’이나 ‘소프트웨어’라는 전문적인 결과물을 함께 만들어내려면 코딩이 어떤 방식과 논리로 진행되는지, 보안 관리는 구체적으로 어떤 일을 포함하고 있는 건지, 고객들이 주로 어떤 상담을 해오는지, 법에 저촉되는 사안이 뭐가 있는지 등을 꽤나 높은 수준으로 파악해야만 한다. 그게 아니면 같이 일을 하면서 ‘잘 몰라서 하는’ 양보밖에 할 수 있는 게 없게 된다. 그런데 이는 위험하다. 프로젝트 팀 단위가 소수이기 때문이다. 소수로 움직일 때는 실수가 크게 부각되기 마련이다.
3) 기획 회의 때 의견을 조합하라고 하는 것 역시 소프트웨어나 앱을 빈틈없이 만들기 위한 것이므로 그저 서로 양보하고 희생하고 넘어가라는 게 아니다. 이상적인 데브옵스 체제에서 소수의 팀으로 뭉쳤다가 흩어졌다가 하려면 자기가 맡은 기능을 완벽하게 수행해야 한다. 소수가 움직이기 때문에 ‘빵꾸’가 날 때 확연하게 눈에 띌 수밖에 없기 때문에 양보나 희생이 미덕이 되지 못한다.
2)~3)번을 합하면 어떤 결론이 나오는가? 화합과 하모니의 아름다움을 강조한 것처럼 보이지만 사실은 극단적일 정도로 개인의 뛰어난 능력을 요구한다는 것이다. 혼자서 어지간한 분야들을 다 높은 수준으로 이해하고 있어야만 하고, 맡은 역할을 빈틈없이 해내야만 한다.
여기에 애초에 데브옵스가 부각되기 시작한 ‘출시 속도’까지 끼얹어 보자. 그야말로 기계의 부품처럼 한 사람 한 사람이 각자의 기능을 고장도 없고 양보도 없이 발휘해야 한다. 페론 로보틱스(Perrone Robotics)의 수석 엔지니어인 에릭 브루노(Eric Bruno)가 “시야가 넓은 장인정신이 강조될 것”을 예측하는 것도 이런 맥락에서다.
장인이 되어야 하는 또 다른 이유, 인공지능
한 사람 한 사람의 뛰어난 기능이 요구되는 시대로 나아가고 있다는 증거가 또 있으니 바로 ‘인공지능’의 가파른 발전 속도다. 알파고의 출현 이후 대중들에게도 큰 관심을 받고 있는 기술인 인공지능은 최근 인간 바둑기사 중 최고수인 커제 9단까지 압도적으로 누르는 데 성공했다. 게다가 아마존 알렉사나 아이폰 시리의 등장으로 인공지능은 우리가 깨닫기도 전에 일상으로 들어와 버렸다. 이미 인공지능에 밀려 직장을 잃은 사람도 있을 정도다.
인공지능 기술이 사람의 경쟁상대로 우려된다는 것 자체가 이미 사람을 한 조직의 ‘기능’으로서 보고 있다는 뜻이다. 4차 산업혁명이 언급되고 있는 때, 어쩐지 최초 산업혁명으로 회귀한 느낌 아닌가? 사람은 기계로 대체해도 될 만큼의 것으로서 인식되고 있다. 에릭 브루노는 “인공지능을 앞세운 자동화 문화 역시 데브옵스의 중추적인 요소가 될 것”이라고 예상하고 있다.
데브옵스가 만들어가는 환경에서부터 인공지능의 추격까지, 인간은 계속해서 발전하고 공부하고 실력을 키워갈 수밖에 없는 처지에 놓이게 되었다. 그것이 ‘데브옵스’라는 형태로 굳어진 지표면 아래서 들끓고 있는 마그마의 정체다. 그리고 그것이 진정한 지난 상반기에 대한 결산이다.
인공지능이 우리의 일자리를 위협한다는 그 케케묵은 이야기가 아니다. 우리가 생각하는 것보다 더 심각한 경쟁 구도로 자연스럽게 내몰리고 있다는 것이다. 왜? 이야기를 처음으로 돌리면 답이 있다. 앱의 빠른 출시라는 공동의 목표와 비전 때문에 위에서 이 부분이 가장 무서운 부분이라고 한 것은, 이 어설픈 공동체 정신이 빠른 경쟁 구도에 놓인 사람의 눈을 가리기 때문이다.
무엇을 위해 발전하는지, 큰 그림 안에서 현재 위치가 어디인지 생각해볼 새도 없이 그저 하루하루 ‘기능 발휘’에만 집중하다보면 했던 실수를 반복하게 하고, 배움을 멈추게 만든다. 4차건 5차건 그 옛날 1차건, 산업혁명이란 것과 지금의 상황에 기시감이 느껴지는 것도 다 그 때문이다. 어쩌면 가장 발전된 인공지능은 그렇게 맹목적으로 자기발전을 해버린 인간이 아닐는지.
데브옵스로 향하고 있다는 걸 알려주는 지표들
그렇다면 지금 우리는 어디쯤에 있을까? 지금은 상상도 할 수 없는 그 무한 속도의 경쟁 구도 속에 이미 돌입했을까? 데브옵스가 아직은 막 퍼지기 시작한 때이니 그렇지는 않다. 하지만 분명히 그 방향으로 가고 있긴 하다. 이를 알려주는 지표들이 어느 정도 존재한다. 공식적인 건 아니지만 대략 다음과 같다.
1) API와 클라우드의 활용이 부쩍 늘어나기 시작했다. 레고 블록 하나하나처럼 잘게 쪼개진 각각의 부품들, 즉 마이크로서비스가 조립될 수 있게 해주는 게 바로 이 API이고, 데브옵스의 핵심 가치라고도 볼 수 있는 ‘유연성’을 극대화시켜주는 게 클라우드이다.
2) 도커(Docker)라는 콘테이너(container) 기술이 널리 활용되기 시작했다. 콘테이너는 마이크로서비스를 담아두는 그릇이다.
3) CD와 CI란 개념이 활용하기 시작했다면 두어 걸음은 더 발을 떼었다고 볼 수 있다. CD는 지속적인 배포, CI는 지속적인 통합을 의미하는 약자로, 마이크로서비스가 유기적으로 붙었다 떨어졌다 조립됐다 재활용됐다 하는 그 과정 자체를 말한다.
4) 여기에서 조금 더 나아가면 오케스트레이션 기술에 자연히 관심이 쏠리게 된다. 많아진 콘테이너와 마이크로소프트를 사방팔방으로 흩어놓을 수가 없으니, 이것 역시 한 데 모아야 할 필요가 있는데 그때 필요한 것이 오케스트레이션 기술이다.
미래, 어떻게 대비할까?
이 흐름을 막을 수는 없다. 그래도 우리는 괜찮다. 다만 우리 자식들이 지금과는 다른 경쟁 구도 속에서 살아갈 것은 거의 확실하다. 보안 업체 CA의 아태지역 CTO인 스티븐 마일스(Stephen Miles)는 “코딩 교육이 답”이라고 말한다. 리서치 전문기관인 TRPC의 림 메이앤(Lim May-Ann)도 마찬가지다. 뉴욕타임즈는 지난 6월 27일 실리콘 밸리가 미국 교육 과정에 코딩을 넣으려고 한다는 보도를 한 바 있다. 애플의 팀 쿡도 이런 움직임에 동참하는 사람 중 하나다. “코딩은 모든 공공학교의 교육 과정에 포함되어야 합니다.”
우리나라에서는 코딩 교육이 ‘초등학교 교과 과정’이라는 민감한 사안과 맞물려 첨예한 논란의 대상이지만 해외 보안 컨퍼런스에 참석해보면 ‘코딩 교육이 앞으로 더욱 중요해질 것’이라는 의견들을 많이 들을 수 있다. 초등학생 때부터 개발자를 목표로 코딩을 가르치라는 게 아니라, 미래에는 코딩이 기본 상식이 될 거라는 데에 모두가 동의하고 있다.
스티븐 마일스와 림 메이앤은 “실제로 우리 아이들에게 코딩을 배우라고 한다”고 말하며 그 이유에 대해 “미래 사회에서 코딩은 마치 현대 문명 사회의 읽기, 쓰기와 같은 기능을 할 것이기 때문”이라고 설명한다. 이는 Code.org의 설립자인 헤이디 파르토비(Hadi Partovi)의 “컴퓨터 과학은 산수나 언어 학습과 똑같은 중요도를 가지고 있다”는 설명과 일치한다.
이들은 “경쟁 구도에서 살아남기 위해 미리 개발을 가르치라”고 말하는 게 아니다. 아이들이 커서 자기 주위에서 무슨 일이 벌어지고 있는지 제대로 조사하고 직접 파악할 수 있도록 준비시키라는 것이다. 마치 국제화된 시대를 위해 영어를 배우듯, 과학이 발달한 시대에 수학을 익히듯, IT 기술의 시대엔 IT 언어로 더 많은 기회를 보장받으라는 것이 크게 억지스럽지는 않다. 다만 지금으로선 상상이 안 될 수는 있다.
또한 컴퓨터를 일찍부터 ‘도구’로서 배우는 것도 중요하다. 컴퓨터 교육학을 전공해 주중엔 금융회사의 IT 담당자로 근무하고 주말엔 아이들 대상으로 컴퓨터 교육 봉사활동을 펼치는 익명의 전문가는(인터뷰 동의를 회사로부터 구하지 못했다) “도구라는 걸 매 수업 시간 강조한다”고 말한다.
“도구로서 컴퓨터를 가르친다는 건, 사용하는 목적이 있을 때만 컴퓨터를 켜는 훈련과도 맞물립니다. 인터넷을 통해 회원가입을 하는 것, 자신의 개인정보를 누군가에게 전달하는 것, 사진을 업로드하는 것 모두 ‘목적이 분명할 때만’ 하도록 가르칩니다. 자연히 보안 교육도 되더군요. 각종 중독 예방에도 도움이 되리라 보고 있고요.”
특이하게도 그는 ‘리눅스 시스템’에서 아이들을 가르친다. 일단 무료라 아이들 편에서 교육비가 덜 부담스럽기 때문이기도 하지만 “다가오는 사물인터넷 시대에 가장 많이 사용될 것으로 보이는 리눅스 체제에 대비케 하기 위해서”이기도 하다. 아직 코딩 교육까지는 진도가 나가지 않았다. “컴퓨터의 ‘주인’으로서 태도를 교육하는 것이 먼저입니다. 이 부분을 확실히 하고 나면 코딩 교육도 진행할 예정입니다.”
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-04-18] 
.jpg)
