2014년 8월 30일 토요일

나는 한달 동안 휴가를 갈 수 있을까?

내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까각자 한번 상상을 해보자.

내가 있던 없던 상관없이 회사는  돌아갈까아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까내가 없으면 회사가   돌아가도 문제지만 내가 있으나 없으나 회사가 아무  없이 돌아가도 불안하다혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.

유지보수가 어렵게 코딩하는 방법” 이란 책도 있다원제는 “How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다 책은 조크이지만 내가 없으면 유지보수가 몇배몇십배 어려워지는 온갖 다양한 방법을 소개하고 있다사실 본인도 유지보수가 어려워지는 방법들이다.

 년에 한번씩 강제로 한달 동안 휴가를 가야 하는 회사가 있다휴가기간 한달 동안 원격지에서 일을  있다는 것이 아니다진짜 휴가를 가야 한다이런 강제 휴가제도를 만든 이유는 어느 직원이던지  직원이 없어도 회사가  돌아가야 하기 때문이다업무의 특수성 때문에 한달 동안 자리를 비울 없는 직원이 있다면 회사의 조직을 바꾸던지 프로세스를 바꿔서 다른 사람으로 대체가 가능하거나보완이 가능하도록 한다누구든지 한달간 휴가를 떠나도 아무런 문제가 없이 해놔야 한다.

이런 회사에서는 직원들이 언제든지 짤릴  있다는 불안감을 가져야 할까?

가상의 이야기가 있다원자력 발전소에서 일하는 홍길동은 절대로 3 이상 휴가를   없다홍길동은 오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동 외에는 그런 기술이 없다고 하자홍길동은 수동으로 온도 제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다회사 입장에서는  비용을 투자 하는 것보다홍길동만  유지하면 적은 비용으로 발전소 운영이 가능하고 홍길동은 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다하지만 홍길동은 격무에 시달려서 회사를 그만두거나 불의의교통사고를 당할 수도 있다 나라의 발전소에서  높은 연봉으로 데려갈 수도 있다.

나는 강연이나 세미나를   자주 묻는다. “지금 당장 퇴사를 해도 회사에  문제가 없는 사람”. 그러면 거의 대부분 손을 드는 사람이 없다실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 보기도 한다.

반대로 그럼 당장 퇴사하면 회사가  돌아가는 사람” 손을 들라고 하면  사람들이 당당하게 손을번쩍 든다 사람은 떠밀려서 손을 든다그러면서 주변에서는 웅성웅성 말들이 많아진다약간의 빈소적인 말도 들려온다대부분의 회사에서 공통적인 현상이다.

우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도  영향을 받는 회사가 많다회사의 경영진은 문서화도 잘되어 있고 공유도  되어 있어서 문제 없다고 하는 경우도 있지만 속을 들여다 보면 유지보수에  쓸모도 없는 문서에 공유는 형식적으로 되어 있어서 실제로는  문제지만쉬쉬” 하는 경우가 많다개발자들도 자신이 없을  회사가   돌아가는 상황을 그렇게 나쁘게만보지 않기 때문에  이슈로 생각하지 않는다.

이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 들기도 하고신혼여행도 제대로 못가는 경우도 발생한다.

그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까단기적으로는 그렇게 생각할 있지만 장기적으로는 얘기가 완전히 달라진다.

나는 당장 퇴사하면 회사가  돌아가는 사람 하루 빨리 정리를 해야 하고, “지금 당장 퇴사를 해도 회사에  문제가 없는 사람 회사에  필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 돌아가는 사람 많다면 회사가 갑자기 망해도 이상하지 않은 상황이다이렇게 망한 회사들은 이런이유 때문에 망한 것이라는 것을 알아채기는 쉽지 않다.

지금 당장 퇴사를 해도 회사에  문제가 없는 사람” 중에는 정말로 하는 일이 없어서 있으나 마나 사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분  동안 해왔던 일들이 문서화가  되어 있고공유가 잘되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다이런 사람은회사의 미래의 프로젝트를 위해서  필요한 사람이다.

반대의 경우는  동안 저질러 놓은 일이 많고 자신이 아니면 유지가  된다 하나 해결하려고 해도  개발자에게 물어봐야 하고다른 사람들은 시스템에 대해서 이해하기도 어렵고  개발자가 한두 시간이면 뚝딱 해결할  있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고해결을 했다고 해도  다른 문제를 만들어 냈을까봐 두렵다회사입장에서는  리스크가 아닐  없없다하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려 다닌다.

물론 개발자가 일부러 이런 경우는 흔치 않다회사의 문화프로세스가 엉망이니 그냥 열심히 하던대로 개발을 하다 보면 이런 현상은 십중팔구 일어난다특히나 개발 능력이 뛰어난 개발자들에게서이런 현상이   일어난다혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가없고혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 유지보수가 어렵게 코딩하는 방법” 이란 책을 공부한 사람처럼 코딩하는 경우도 있다.

이렇게 자신의 과거 업무에 발목이 잡혀있는 개발자들은 앞으로 나아가면서 성장하기 어렵다회사의미래 프로젝트좀더 어렵고 재미있는 일을 못하게 된다새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일 하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게된다자신의 과거의 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.

물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다개발자를 부품으로만 생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를  있다실제이런 회사도 많이 있고 이런 회사에서 일하는 개발자라면 유지보수가 어렵게 코딩하는 방법  공부하기를 바란다.

개발자가 자신이 없어도 회사가 문제 없이 돌아가게 하려면 공유를  해야 한다문화적으로 성숙되고 프로세스를  갖춘 회사라면 모든 개발업무가 진행되면서 자연스럽게 공유가 되는 시스템을 갖추고 있다중간 중간 리뷰 과정을  거치고 문서화가 되며 지식과 경험이 자연스럽게 여러 사람과 공유가 된다이런 프로세스를 뒷받침할 기반시스템도 적절히 갖추고 있다공유를 위한 공유가 아니기 때문에 훨씬 자연스럽고 부담도 없다.

자신은 어떤가 생각을 해보자한달간 휴가를   있을까회사의 모든 직원이 각자 한달간 휴가를  있을까그렇지 않다면 무엇을 바꿔야 할지 생각해보자.

2014년 8월 16일 토요일

편한 개발환경이 가져온 부작용

필자는 개발자를 채용할 때 인터뷰 시 칠판을 이용한 코딩 테스트를 꼭 실시한다. 아무리 화려한 이력을 가지고 있다고 하더라도 코딩 테스트를 통과하지 못하면 채용하지 않는다. 코딩 테스트 문제는 정말 간단하다. 

숫자를 문자로 변환한다든지, 숫자 몇 개를 정렬하는 등 아주 단순한 문제다. 코딩 테스트에서 확인하는 것은 개발자의 논리적인 사고, 창의력, 문제 해결 능력이다. 그리고 문제를 해결하기 위해서 면접관과 어떻게 커뮤니케이션을 해나가는지 보는 것도 중요한 요소다. 문법은 중요하게 보지 않고 개발언어는 아무거나 선택해도 된다. 

실제로 여러 지원자에게 코딩 테스트를 실시하면 안타깝게도 코딩 테스트를 통과하는 비율은 매우 낮다. 경력은 화려하게 잘 얘기하는데 코딩 및 논리적인 사고는 어처구니 없이 형편없는 경우가 많다. 그래서 서류 심사를 통과한 지원자를 대상으로 온라인 코딩 테스트를 먼저 실시하곤 한다.

온라인 코딩 테스트는 약간 난이도가 있는 문제를 주고 24시간 안에 코딩을 해서 제출하게 하는 것이다. 컴파일이 되어야 하고 실행이 되어야 하며 알고리즘의 효율성을 보기 위해서 실행 제한 시간도 있다. 이런 온라인 코딩 테스트는 어차피 인터뷰에서 탈락할 지원자를 걸러줌으로써 인터뷰 시간과 비용을 절약하는데 도움이 된다. 

얼마 전 온라인 코딩 테스트를 실시하는데 어처구니 없는 일이 발생했다. 온라인 코딩 테스트는 꼭 본인이 작성해야 한다는 규칙이 있다. 하지만 온라인의 특성상 주변 지인들에게 약간의 힌트성 도움을 받는 것은 어쩔 수 없다고 생각하고 있다. 출제한 문제는 유명한 코딩 테스트 사이트에서 가져온 문제다. 

하지만 지원자는 문제를 받자마자 본인이 풀 생각을 하지 않고 바로 인터넷을 검색하여 해당 사이트를 찾아냈다. 그리고 해당 문제를 푼 사람을 찾아서 소스코드를 보내달라는 이메일을 보낸 것이다. 그런데 이메일을 받은 사람은 프로 개발자가 아니라 초등학생이었던 것이다. 전문 개발자를 채용하려고 실시하는 코딩 테스트에서 자신이 못 풀겠다고 초등학생에게 소스코드를 요청하는 일이 발생한 것이다. 

인터넷을 검색해서 알고리즘을 참고한다 던지 아이디어를 구하는 것은 가능하지만 소스코드를 달라고 하는 것은 명백한 속임수(Cheating)이라고 생각한다. 이런 개발자는 실력을 떠나서 채용할 수가 없다. 

다른 사례다. 온라인 코딩 테스트를 훌륭하게 통과해서 인터뷰를 진행한 개발자 얘기다. 그런데 칠판 코딩 테스트에서 이상한 일이 발생했다. 온라인 코딩 테스트 문제는 개발자의 논리력, 창의력이 없으면 풀기 어렵기 때문에 칠판 코딩 테스트에서 좋은 결과를 보여줄 것으로 예상했는데 인터뷰 현장에서 형편 없는 결과를 보여줬다. 

혹시 긴장해서 원래 실력을 보여주지 못하는 것이 아닐까 생각해서 여러가지 질문을 해봐도 원래 실력이 없었다는 것이 확인이 되었다. 그렇게 탈락을 한 후 이상한 생각이 들어서 온라인 코딩 테스트에서 제출한 답안을 인터넷에 검색을 해보니, 해당 문제를 미국에서 자바로 풀어 놓은 답안과 한 글자도 틀리지 않고 동일한 것을 확인했다. 

그 뒤 온라인 코딩 테스트를 세상에 없는 문제로 새로 만들어야 고민을 했지만 지원자가 속임수를 쓰는지 확인할 수도 있으므로 그냥 진행하기로 했다. 단, 지원자에게는 본인이 직접 풀어야 한다고 꼭 당부를 하고 있다. 

이런 일이 발생하는 이유는 무엇일까? 요즘 개발자들은 과거에 비해서 훨씬 개발하기 편한 환경에 있다. 개발하다가 필요한 모듈이나 알고리즘은 인터넷을 검색해보면 다 찾을 수 있다. 그러다 보니 원리는 생각하지도 않고 본인이 이해도 하지 않고 그냥 인터넷에서 소스코드를 가져다가 사용하는 경우가 매우 많다.

과거에 인터넷(웹)이 없을 때나 초창기 까지는 소스코드를 구할 곳은 책을 제외하고는 별로 없었다. 그래서 개발자들이 책을 많이 보고 본인이 이해를 해서 직접 구현을 해야 했고, 그러다 보니 소프트웨어 이론에 대해서 속속들이 잘 알아야 했다. 과거에 뛰어난 개발자가 더 많았던 이유는 이런 환경에 기인한 것이 아닌가 생각된다. 

요즘은 쉽게 소스코드를 구할 수 있다 보니 깊게 생각하는 습관을 가지기는 어렵다. 개발자들의 고충을 이해하지 못하는 것도 아니다. 촉박한 시간 안에 빨리 구현을 해내야 하고 누가 설계를 잘 해주는 것도 아니고 서로 리뷰를 통해서 내가 작성한 코드를 누가 잘 봐주는 경우도 흔치 않다. 

그러다 보니 부랴부랴 인터넷에서 구한 소스코드를 이해도 못하고 그대로 사용하기 일쑤다. 요즘 개발자들을 만나보면 소프트웨어 이론을 속속들이 잘 모르는 경우가 많다. 메모리의 기본 구조도 잘 모르고 기본적인 자료구조와 알고리즘도 잘 모르곤 한다. 대학에서 이런 기본 이론을 철저히 가르쳐야 하는데 이런 이론보다 실무를 가르치는 것이 아닌가 의구심이 들기도 한다. 모든 대학이 그런 것은 아니지만 이론보다 실무를 가르친다면 학원과 다를 것이 없다. 그래서 실무 중심 사관학교라는 대학의 광고를 듣다 보면 안타까운 생각이 든다. 

이렇게 개발하기 좋은 환경이 오히려 개발자들의 실력을 떨어뜨리고 있는 것이 아닌가 걱정이 되고 있는 사례들이다. 현재 소프트웨어 공부를 하고 있는 학생이라면 실전 코딩보다도 소프트웨어 기초 이론을 철저히 익히라는 얘기를 하고 싶다. 실전 경험도 중요하지만 기초가 약하다면 언제든지 문제가 될 수 있다. 

회사에서는 개발자에게 이론, 경험을 전파하는 수단은 코드리뷰, 설계리뷰다. 선배 또는 동료가 소스코드나 설계서를 보고 리뷰를 하면서 서로의 경험과 이론, 노하우를 전달하는 것이다. 서로 리뷰를 통해서 개발자는 같이 성장해나가는 것이다. 피어리뷰(동료검토)를 하지 않거나 형식적으로 하지 않는 회사에서는 개발자들의 성장이 몇 배 느릴 수 밖에 없다. 

개발자는 구글을 믿고 개발을 할 것이 아니고 믿어야 할 것은 자신의 두뇌와 동료들이다. 구글은 단지 거들뿐이다.

이 글은 ZDNet Korea에 기고한 입니다.

2014년 8월 15일 금요일

인원 늘면 꼬이는 SW개발문화의 현주소

꽤 오래 전 TV에서 혼자서 무인 자동차를 개발하고 있는 한 대학 교수의 이야기를 본 적이 있다. 20년째 혼자서 연구를 하고 있었고 조금씩 개량해서 그 당시 한적한 국도를 혼자서 달릴 수 있는 수준이었지만 복잡한 도로에서는 제대로 달릴 수 없었다. 

어린 마음에 참 대단하다는 생각을 했고 운전자 없이 도로를 달리는 차들을 상상해 보기도 했다. 그러나 그 뒤에 어떻게 되었는지는 알 수가 없다. 

하지만 현재 구글은 이미 실용적인 수준의 무인 자동차를 개발했다. 시중에 운전자가 없는 자동차가 굴러다니는 것을 볼수 있기 일보직전이다.  둘의 차이는 무엇일까? 

20년전 필자가 다니던 H사는 전국적으로 뛰어나다는 소프트웨어 개발자들이 모여들었다. 필자가 참여했던 프로젝트 중 하나는 팀원이 4명이었다. 그런데 같은 종류의 제품을 만드는 미국의 경쟁회사인 C사는 프로젝트 팀원이 400명이었다. 4대400으로 경쟁하는 것이었다. 그때는 내심 부러워했지만 그때 만약 400명의 개발자가 있었다면 미국 회사 정도 제품을 만들어 낼 수 있었을까? 나는 프로젝트 팀원이었는데 스펙을 본 적도 없다. 스펙이 없기 때문이었다. 나는 팀장이 구두로 설명하면 일을 하곤 했는데 400명의 개발자가 추가 됐어도 크게 다르지 않았을 것이다.

그 당시 H사를 다니던 뛰어난 개발자들은 전국 각지의 회사들로 흩어져서 일당백의 개발자로 일하고 있고, 들으면 알만한 수많은 소프트웨어를 개발했다. 하지만 안타깝게도 글로벌 시장에서 성공한 소프트웨어를 개발한 사례는 내 기억에는 없다. 돈을 많이 번 사례로는 게임회사를 운영한 경우가 있지만 게임의 핵심 경쟁력이 소프트웨어는 아니기 때문에 예외로 해야 할 것이다. 작은 회사를 유지하면서 건실하게 유지하고 있는 회사도 있지만 큰 회사로 성장한 경우 소프트웨어 역량은 형편없어지는 사례를 자주 보았다. 

한국에서 개인 또는 소수 개발팀이 소프트웨어를 알차게 만들어서 꽤 인기를 끄는 경우를 종종 보게 된다. 규모가 꽤 큰 외국 개발팀에서 생산하는 소프트웨어보다 괜찮은 경우도 있다. 이런 굉장한 효율을 보여주는개발팀은 대부분 10명이하의 소규모팀이다. 

하지만 개발팀이 수십, 수백명이 넘어가면 효율은 점점 떨어진다. 개발자가 1000명이 넘는 회사를 가보면 거대한 개발조직이 가지고 있는 장점을 별로 찾아볼 수가 없다. 개발자는 1000명이지만 개발자 10명짜리 회사가 100개 모여있는 것처럼 느껴진다. 팀간에 지식은 공유가 잘 안되고 협조하기도 쉽지 않다. 하나의 거대한 지식 공동체라기보다는 조직적으로 잘나눠지고 관리되는 팀일 뿐이다. 

이런 현상은 현재 일하고 있는 개발자들 탓은 아니다. 한국 개발자들도 지식 공동체가 잘 구축되어있는 회사에서 처음부터 개발을 시작했다면 어떻게 서로 지식을 공유하고 협업하는지 자연스럽게 몸에 익혔을 것이다. 그런 문화속에서 대규모 프로젝트를 이끌 수 있는 아키텍트가 탄생하기 마련이다. 하지만 그런 문화가없는 조직에서는 기업의 문화를 그대로 배울 수 밖에 없다. 

비싼 툴을 쓴다고 프로세스를 강화한다고 해서 지식공동체가 만들어지는 것은 아니고 오히려 점점 멀어지게 된다. 

지식을 공유한다고 이슈관리시스템을 쓰고 위키, KMS를 도입하지만 골프채를 바꾼다고 골프를 잘치게 되는 것은 아니다. 툴은 필요하지만 먼저 문화를 익혀야 한다. 문화는 사회에 나와서 갑자기 익히기도 어렵다. 학교에서부터 공유, 토론, 협업문화를 익힐 수 있는 수업을 위주로 문화를 구축해 나가야 한다. 

한국에서 미국에 이민을간 중학생이 미술 수업시간에 그림을 그리는데 반에서 가장 잘그렸다. 하지만 B 학점을 받았다. A 학점을 받은 학생은 자신보다 그림을 못그렸지만 그림에 대해서 설명을 훨씬 잘했다고 한다. 

미국에서는 대학수업 대부분의 과목에 토론수업이 병행되고 있다. 강의를 받고 끝나는것이 아니라 그만큼의 토론수업이 또 진행된다. 토론이 항상 몸에 베이게 되는 것이다. “토론, 까짓별거야? 우리도하면되지”라고 생각하면 오산이다. 

십여년을 토론수업을 하면서 배워온 사람들과는 문화적인 차이는 명백히 드러난다. 토론을 몸으로 익혀온사람들은 소프트웨어를 개발할 때도 적절한 커뮤니케이션과 공유, 협업이 자연스럽게 이루어진다. 

대규모 프로젝트의 성공은 뛰어난 아키텍트에 달려있다. 한국에 뛰어난 프로그래머는 많지만 뛰어난 아키텍트는 절대적으로 부족한 이유가 이런 환경에 기인한 것이라고 생각한다. 개발자 10만 양병설, 초등학생 SW 교육을 외치기 전에 문화를 바꾸는데 더 노력을 해야 한다. 

2014년 8월 1일 금요일

SW교육, 프로그래밍이 핵심 아니다

메르세데스벤츠의 CEO 디터는“이제 자동차는 기름이 아닌 소프트웨어로 달린다”고 말했다. 앞으로의 산업에서 소프트웨어가 차지하는 중요도를 단적으로 나타내는 말이다. 과거 전세계 제조업시장에서 1등자리를내주었던 미국이 세계 최고의 소프트웨어 기술을 기반으로 제조업 부활을 위한 용트림을 시작했다. 

우리나라 전자 회사들이 그 짧은 기간에 외국의 세계 1등 기업들을 제치고 매출에서는 세계 최고가 되었지만 점점 넘지 못할 벽으로 점점 뚜렷하게 다가오는 것이 바로 소프트웨어의 역량 차이다. 개별적인 근면 성실함과 똑똑한 머리와 치열한 의지로 외국에서 100년 넘게 이룩한 산업기반을 몇 십 년 만에 앞지른 분야도 있지만 소프트웨어 분야에서는 차이를 좁히기는커녕 점점 더 뒤쳐지고 있는 듯하다. 

과거 소프트웨어라고 하면 워드프로세서나 스프레드시트, 게임 같은 것을 먼저 떠올렸다. 하지만 사실 하드웨어에 장착되는 임베디드 소프트웨어의 시장도 만만치 않게 컸고 규모는 점점 커지는 양상이다. 소프트웨어가 제조업의 기반을 뒤흔들 정도가 됐다. 옛날에는 소프트웨어는 제조업 즉, 하드웨어의 보조적인 역할에 불과했으나 지금이나 앞으로는 소프트웨어가 오히려 기반산업이 되어가고 있으며 소프트웨어 역량이 제조업 경쟁력의 핵심이 되어가고 있다. 

세상은 소프트웨어를 중심으로 바뀌어 가고 있는데 필자가 접한 대기업을 비롯한 수많은 회사들의 대응은 무신경하기 그지없다. 몇몇 기업은 소프트웨어의 중요성을 외치고는 있지만 그 대책이 소프트웨어를 전혀 모르는 탱크 같은 추진력을 가진 경영자에게 모든 것을 맡기고 기껏해야 개발자들을 끊임없는 밤샘 작업으로 내몰고 오히려 불편한 비싼 툴을 사주고 프로세스는 과도하게 복잡하게 해서 품질을 올린다고 한다. 

경영자가 소프트웨어를 모르니 잡상인에 현혹되는 것은 당연하다. 이런 식으로 소프트웨어 경쟁력을 높인다고 하니 경쟁력이 오히려 떨어지는 것이 이상할 일이 아니다. 

다행히 몇몇 기업은 소프트웨어 전문가를 경영진으로 채용해서 진정한 소프트웨어 역량 발전에 힘을 쓰고 있지만 기업의 정치 역학 구조에서 소프트웨어 전문가들이 힘을 제대로 못쓰는 경우가 많아서 안타까움을 더하고 있다. 즉, 소프트웨어 전문 경영자들이 실력은 있는데 정치에서 밀리는 것이다.

지금 당장 기업들은 소프트웨어 역량 부족으로 발등에 불이 떨어졌지만 더 중요한 것은 미래다. 전체 산업에서 차지하는 소프트웨어의 비중은 향후 10~20년 동안 폭발적으로 증가할 것이 확실시 되고 있다. 즉, 20년 후에는 엄청난 수의 소프트웨어 개발자가 필요하게 된다. 

소프트웨어 개발자가 많이 필요하다고 해서 착실한 준비없이 급하다고 학원 같은 곳에서 개발언어 약간 가르쳐서 저급 개발자를 양산해서는 소프트웨어 경쟁력을 가질 수 없다. 급하게 부족한 인력을 보충할 수는 있겠지만 지금과 같이 열악한 소프트웨어 환경을 더 악화시키는 역할을 할 것 같은 우려가 된다. 

소프트웨어가 산업이 중심이 되는 미래를 대비하기 위해서는 초, 중, 고 모든 과정에서 필수적으로 소프트웨어를 대비한 교육을 해야 한다. 소프트웨어 교육이라고 하면 개발 언어를 가르쳐야 한다고 생각하면 눈감고 코끼리의 뒷다리를 만지는 격이다. 현재 우리나라 소프트웨어 역량이 뒤쳐지는 이유가 코딩을 잘 못해서는 아니기 때문이다. 개발 문화와 환경을 바꿀 수 있는 교육을 해야 한다. 

먼저 소프트웨어에 기초가 되는 지식을 좀더 많이 가르쳐야 한다. 수학, 논리학, 과학 등 논리적인 사고를 좀더 많이 하게 하고 뛰어난 논리력을 가지고 있는 학생들에게 좀더 많은 기회와 동기를 부여해야 한다. 

다음으로는 소프트웨어 문화를 바꿀 수 있는 교육을 해야 한다. 소프트웨어 개발에서 가장 중요한 것이 협업이다. 그러기 위해서 토론, 협동, 발표를 위주로 한 교육을 해야 한다. 과거에는 한 반에 학생이 60~70명이나 되어서 토론식 교육이 불가능했지만 지금은 20~30여명의 학생이라서 토론식 교육이 충분히 가능하다. 학교에서도 토론식 교육을 점점 증가시키고 있지만 너무 더디다. 자칫 배 떠난 뒤에 손 흔드는 격이 될 수도 있다. 좀더 과감히 비중을 늘려야 한다. 

뻔하고 당연한 얘기 같지만 학부모로서 아이들의 교육과정을 지켜보면 급격한 변화에 대응하여 무신경하고 느리기 그지없다. 

암기 잘하는 학생도 공부를 잘한다고 할 수 있겠지만 토론을 잘하고 발표를 잘하는 학생에게 좀더 높은 점수를 주고 이런 학생들을 많이 키워내야 한다. 소프트웨어 개발의 핵심 역량은 토론과 협업이다. 어릴 때부터 몸에 베어 있지만 않으면 성인이 되어서 갑자기 잘 할 수는 없다. 

학생들에게 프로그래밍을 가르치는 것은 그 후순위가 될 것이다. 이런 조건 없이 프로그래밍만 가르치고 사지선다식 시험을 본다면 지금보다 나아질 것은 전혀 없다. 프로그래밍도 토론, 협업, 발표를 융합한 교육이 되어야 한다. 

필자는 지금 우연한 기회에 영재 초등학생에게 프로그래밍을 가르치고 있다. 그 결과 초등학생들이 절대 학습시간이 부족하여 프로그래밍 실력은 성인에 비해서 떨어지지만 논리력은 성인 못지 않게 뛰어나다는 것을 알게 되었다. 사실 웬만한 개발자보다 논리력이 뛰어나기도 하고 이런 초등학생들이 개발 문화를 몸에 익히고 프로그래밍 실력까지 갖춘다면 미래에 뛰어난 소프트웨어 아키텍트로 성장할 것으로 확신한다. 우리나라는 이런 미래의 소프트웨어 아키텍트가 수천명, 수만명이 필요하다. 우리나라가 2등국가로 떨어지지 않으려면 꼭 필요하다. 

이것이 당장 학생들에게 제대로 된 소프트웨어 교육이 필요한 이유다. 

이글은 ZDNet Korea에 기고한 입니다.