(1편에서 이어집니다)

왜 모두가 코딩을 하고 있는 것일까? 도대체 무슨 일이 벌어진 것일까?

연산 폭주 시대

앞서 예로 들었던 공학용 계산기 이야기로 돌아가자. 우리가 흔히 지나치는 것이지만, 현대 공학은 극도로 복잡한 수학적 모델 위에 건설된 대성당이라고 할 수 있다. 잘 와닿지 않는다면, 지금으로부터 100년 전으로 돌아가 보면 된다. 컴퓨터의 발명자 중에 콘라트 추제라는 사람이 있다. 그런데, 이 사람이 계산하는 기계의 개발에 매달리게 된 계기가 좀 재미있다. 토목 공학을 전공하던 학부생 시절, 전공 공부를 하는 것보다 방정식을 풀면서 계산 삽질을 하는 데 더 많은 시간을 보내야 했던 것. 대학을 마치고 추제는 헨셸 사에 취직해서 비행기를 설계하는 부서에 들어갔는데, 대학 시절 하던 계산이 그냥 커피였다면 여기서 하는 일은 TOP1... 추제가 개발한 초기의 컴퓨터들 역시 항공기 설계를 위해 만들어진 기계였다.

하지만 지금은? 혹시 공대 교과서 참고문헌 목록 뒤져보신 분? 찾아 보면 알겠지만, 거기 나오는 수학적 모델 중에 추제의 컴퓨터보다 나중에 나온 게 한 무더기다. 사용되는 수학적 모델이 훨씬 복잡한 것은 물론이다. 수학적 모델이 복잡하다는 얘기는 곧 계산할 게 많다는 얘기도 된다. 장난 전화 거는 기계를 만드는 데도 컴퓨터를 동원해 계산을 해야 하는 마당에 다른 물건들은 오죽할까?2 너도나도 공학용 계산기를 들고 다니는 것 아니 요즘 기계 중 실시간으로 연산을 처리해 주는 마이크로프로세서나 펌웨어 안 들어간 걸 더 보기 힘든 건 바로 이것 때문이다. 설계뿐만 아니라 동작에도 복잡한 수학적 모델이 사용되고 있으니까. 정리하자면, 지금의 공업 생산품은 100년 전의 그것과 비교를 불허하는 막대한 정보 처리의 결과물인 것이다.

https://live.staticflickr.com/3077/3242874849_b7674db58b_b.jpg

콘라트 추제가 개발한 최초의 프로그램 제어 컴퓨터, Z3(1941). 지금의 디지털 컴퓨터와는 달리 기계식으로 제작됐다. 컴퓨터 역사 박물관 소장. (출처: flickr@phrenologist)

모든 게 이런 식이다. 화물을 사람 손으로 선적하던 100년 전과는 달리, 현재의 컨테이너 화물 선적은 상당한 양의 연산(Cargo load scheduling)을 필요로 한다. 화물선 한 척에 서로 다른 무게의 컨테이너가 수백 개인데, 아무렇게나 실었다가 한 쪽으로 쏠리기라도 하면 큰일 날 일 아닌가? 그걸 주고받으려면? 이미 1930년대부터 급증하는 우편물의 목적지를 더 빠르게 분류하기 위해 전국의 주소지에 일정한 번호(Postal Code)를 부여하는 방안이 논의되고 있었다. 지금처럼 "인도네시아에서 보낸 부품 A는 x 항공편에 막 선적이 끝났고, y 조립공장에서 바닥난 부품 B는 추가분이 트럭으로 도착 직전" 이렇게 실시간으로 파악하는 건 SF 소설에나 나올 만한 이야기3였던 것이다. 사무실도 마찬가지. 이미 100년 전부터 전미에 걸친 사업을 하고 있던 P&G는 다양한 제품의 생산 및 유통에 들어가는 이런 류의 노력에 시달린 나머지 사업부(division)라 불리는 대단히 예외적인 조직 체계를 도입해야 했다. 그게 왜 '예외적'인 거냐고? 내 말이 그 말이다. 100년 전 극도로 예외적이었던 것이 지금은 일상이 됐다. 요즘은 당시의 P&G보다 더 다양한 상품과 복잡한 생산 유통 라인을 가진 기업이 수두룩하다. 대기업들이 업무 처리 시스템 개발하는 데 수백억을 때려 넣는 게 괜히 그러는 게 아니다.

https://live.staticflickr.com/1171/1373677306_ce0f7f8493_b.jpg

보잉 747-200의 항공 기관사 계기판. 초기의 비행기에는 계기판이 몇 없었지만, 1930년대 엔진이 넷 달린 대형 항공기가 등장하면서 비행기의 각종 상태를 알려 주는 (=정보를 표시해 주는) 계기판이 조종석을 새까맣게 뒤덮기 시작했다. 그러고도 모자라서 제어 장치 조작을 전담하는 (=실시간 정보 처리를 도와 주는) 항공 기관사(Flight Engineer)가 따로 배치되어 파일럿의 일을 거들어야 했다. 이 보직은 이후 자동화된 제어 시스템으로 대체되었기 때문에, 요즘은 볼 수 없다. (출처: flickr@thezipper)

옛날의 기술과 지금의 기술 사이에 있는 것이 정보의 처리다. 옛날의 화물 운송과 지금의 화물 운송 사이에 있는 것도 정보의 처리4고, 사업부 조직이 예외적인 것이었던 시절의 사무실과 지금의 사무실의 차이도 정보의 처리다. 그리고 이 모든 사회적 변화를 통틀어서 정보화 시대의 도래라고 하는 것이다. (웹 서핑 같은 거하고는, 솔직히 별 상관 없다.) 모두가 코딩을 하게 된 건 정보화 사회의 도래로 인해 수반된 결과에 불과하다. 처리해야 할 정보가 폭주해서 도저히 사람 손으로는 처리할 수가 없으니, 이런저런 것을 처리하라는 명령서를 써서 기계한테 주고 있다는 얘기다. Matlab 프로그래밍을 하고 있는 엔지니어에서부터 엑셀을 붙잡고 있는 직장인까지, 전부 다.

코딩 교육에 대해 반대하는 사람들 중에 이러는 사람들이 있다: "왜 전산학과에서나 배우는 코딩을 모두에게 강요하려 하느냐" "모두가 컴퓨터 프로그래머가 되어야 할 필요가 있느냐" 나 역시 코딩 교육 의무화에 대해서는 다소 의구심을 가진 사람이지만, 이런 주장은 현실성을 완전히 결여하고 있다. 전산학과는 코딩 배우는 데가 아니고, 이미 모두가 코딩을 하고 있으며, 시대의 흐름상 이게 뒤집어질 가능성은 희박하니까. 전산학이 최고의 학문이라는 것도 아니고, 당신이 당신 일을 때려 치워야 하는 것도 아니다. 당신은 그저 기계가 당신을 위해 무엇을 계산해 주면 좋을지, 명령서를 작성하는 방법만 알면 된다. 당신의 지적 활동에 도움을 줄 정도로 말이다. 기계공학과 대학원생이 Matlab 코딩을 못 해서 아이디어를 발전시키지 못하고 어버버 하고 있다면? 사회학자가 코딩을 못해서 가설을 검증하지 못한다면? 직장인이 엑셀질을 못 해서 할 필요도 없는 야근을 연거푸 하고 있다면? 좀 더 확실하게, 엑셀질을 잘못해서 경제 정책이 산으로 가버린다면? 이런 한심한 사태가 벌어지지 않을 정도까지만 코딩을 할 줄 알면(≒엑셀질을 할 줄 알면) 된다는 얘기다. 그 이상 - 나처럼 대형 연산 시스템을 개발한다던가 - 은 전혀 필요없다.

코딩은 전산학과에서 배우는 것인가? (2)

문명의 충돌. 미국의 정치학자 새뮤얼 헌팅턴이 문명의 충돌(1992)에서 주장한 9개 문명권 개념이 실재하는지는 오랫동안 논쟁의 대상이 되어 왔다. 2013년 3월, 스탠포드 대학 사회학과 연구팀이 Yahoo의 메일 교환 데이터를 분석하여 헌팅턴의 이론을 뒷받침하는 증거를 찾아냈다. (*출처: http://www.technologyreview.com/view/512116/global-e-mail-patterns-reveal-clash-of-civilizations/)

그게 최선입니까

그러면 역시 중고등학교에서 의무적으로 코딩을 가르치는 게 좋을까? 글쎄, 여기서부터 이야기가 좀 달라진다. 나는 코딩을 의무 교육 기간에 가르치기 전에 고민해 봐야 할 주제들이 있다고 생각한다. 우선, 왜 하필 중고등학교에서 가르쳐야 하는지? "A를 배워야 한다" 와 "A를 의무 교육 과정에서 배워야 한다" 는 엄연히 다른 문제다. 운전 역시 현대인의 필수 스킬이지만, 운전을 학교에서 가르치지는 않는다. 당신이 코딩 교육을 지지하는 사람이라면, 중고등학교에서 코딩을 가르치는 것이 지금처럼 대학에서 배우거나 사회 나와서 배우는 것보다 왜 더 나은지에 대해 설명할 필요가 있을 거다.

두 번째는 좀 더 실제적인 측면이다: 위에서 언급한 교육적 효과를 거두기 위해 코딩을 전담해서 다루는 별도 과목이 반드시 필요한지? 초중고 12년은 인생에 있어서 매우 중요한 시간이고, 한 치도 낭비하기 어려운 기간이다. 그렇기 때문에 학교에서 배우는 지식은 가능하면 오랫동안 사용될 수 있는, 기초적이고 개념적인 것이 좋다. 코딩 교과목이 별도로 없을 경우, 코딩에 활용되는 수학적 개념들4을 배우는 것이 힘들거나 불가능한지? 만약 그렇다면, 코딩 교과목은 이러한 개념을 학습시키는 데 적절한 구성으로 되어 있는지? 이런 질문에 대답할 수 없다면, 코딩이 별도 교과목으로 추가되어야 할 필요성은 설득력이 떨어질 것이다.

비디오 아트의 개척자, 백남준이 자신의 작품(etude 1, 1967-1968)을 개발하기 위해 작성한 Fortran 코드. 1967년. 오랫동안 자료 더미 속에서 잊혀져 있다가 최근 발견됐다. 스미소니언 미술관 소장. (*출처: http://www.smithsonianmag.com/smithsonian-institution/new-works-nam-june-paik-discovered-smithsonian-american-art-museum-180954571/)

내가 코딩 교육 논란에 대해 하고 싶은 이야기는 여기까지다. 결론이 어떻게 나게 됐던, 이왕 공론장에 올라온 거 좀 더 의미 있게 논쟁을 했으면 좋겠다.

* 2015년 7월 23일 추가: 교육부와 미래창조과학부는 21일 국무회의에서 초·중·고등학생 소프트웨어 교육을 확정하고, 9월에 구체적인 교육 과정을 고시할 것임을 예고했다. 그리고 역시나 졸렬한 계획 수립으로 신나게 까이고 있다.
* 2015년 8월 16일 추가: 항공기의 운항 과정에서 얼마나 많은 정보가 실시간으로 오가고 있는지를 엿보고 싶다면 이 기사를 추천.


  1. 컴퓨터의 또다른 발명자 중 한 사람인 하워드 에이킨 역시 비슷한 경험을 했다. 수학 박사 학위 논문을 쓰는 과정에서 끔찍하게 많은 계산에 시달렸던 것. 

  2. 그런 의미에서 '무식하고 생각이 단순한 공돌이' 따위의 말은 완전한 개소리다. 이딴 헛소리 내뱉는 인간들은 대체 얼마나 고차원적인 사유 하고 사신다고. 

  3. 요즘은 이 기능도 아주 많이 대중화되서 일반인들도 자주 사용한다. 실시간 택배 추적 기능이 바로 그것이다. 

  4. 키(Key)의 개념이라던가, 속성(Attribute)의 성질이라던가, 연산 순서라던가... 실제로 엑셀 붙들고 삽질하고 있던 지인들을 도와 주던 경험에 비추어 보면 이런 개념이 머릿속에 없어서 고생하는 경우가 더 많았다.