기사 공유하기

코딩을 배우려면 전산학과에 가야 한다?
코딩은 프로그래머만 하는 일이다?

둘 다 틀렸다.

요즘 SW 교육 의무화 방침 관련해서 이런저런 갑론을박이 벌어지고 있어서, 이 문제에 대해 내 생각을 한 번 적어 보기로 하겠다. 다소 긴 글이 될 것 같으니 짧게 요약하자면:

  1. 전산학과는 코딩을 배우는 곳이 아니라, 자동화된 연산을 수행하는 데 필요한 수학적·공학적 지식을 배우는 곳이다.
  2. 이미 대부분의 사람은 코딩하면서 먹고 살고 있다. 아니, 이제는 코딩 안 하고 먹고 사는 게 더 힘들다(!).
  3. 한동안 이런 추세가 뒤집힐 가능성은 별로 없다. 오히려 심해졌으면 더 심해질 것이다.
  4. 따라서 논점은 코딩을 배워야 하느냐 아니냐가 아니다. 좀 더 생산적인 논쟁이 되려면, 논쟁의 초점을 조정할 필요가 있다.

코딩이란 무엇인가?

우선 코딩이라는 게 뭔지부터 짚고 넘어가자. 코딩이라는 말에는 여러 가지 뜻이 있지만, 코딩 교육 할 때의 ‘코딩’은 컴퓨터 프로그래밍을 가리킨다. 기계가 해석해서 실행할 수 있도록 작성된 명령서를 (컴퓨터) 프로그램이라 하고, 이를 작성하는 일을 (컴퓨터) 프로그래밍이라고 한다. 그러니까 코딩이란 기본적으로 기계에 명령을 내리는 행위라고 할 수 있겠다.

그럼 코딩이 세탁기 버튼 누르는 것과 다른 건 무엇일까? 이것도 기계에다 뭔가 명령을 내리는 건데? 정답은 일정한 문법 체계를 가진 언어의 사용 여부다. 세탁과 탈수 버튼(표현)이 있는 세탁기라고 해서 ‘세탁하고 탈수’ ‘세탁하고 탈수하고 또 세탁’ ‘세탁하고 탈수 두 번 하고 세탁’ 같은 표현이 무한정 만들어지지는 않는다. 인간의 언어가 ‘친구’와 ‘의’ 두 개의 표현만으로도 ‘친구’ ‘친구의 친구’ ‘친구의 친구의 친구’ … 처럼 무한한 표현을 만들 수 있는 것과는 대조적이다.

컴퓨터에게 주어지는 명령서는 일정한 문법을 가진 언어로 작성된다. 그래서 A와 B 두 개의 표현으로도 ‘AA’ ‘AB’ ‘AAB’ … 처럼 무한히 많은 표현을 만들어낼 수 있다. 바로 이 지점이 프로그래밍과 세탁기 조작의 차이점이다. 아래 이미지는 실제로 컴퓨터에 들어가는 코드의 예인데, 한쪽이 좀 더 사람에게 편하게 작성되어 있다는 정도의 차이는 있을지언정 ‘언어’가 사용되고 있다는 점에서는 모두 같다.

코드
컴퓨터가 알아들을 수 있는 명령서(code). 왼쪽은 CPU가 바로 알아들을 수 있는 형태의 언어(MIPS assembly). 오른쪽은 인간의 언어를 더 닮은 현대 고급 언어(scala). 둘 다 2 + 5 * 8을 계산한다.

정리하자면, 코딩이란 일정한 문법을 가진 인공적 언어를 사용해서 기계가 이해하고 실행할 수 있는 명령서를 작성하는 행위라고 할 수 있겠다. 이런 일을 하는 이유는 물론 편의성 때문이다. 예를 들어서 복잡한 계산식을 계산해야 할 때마다 계산기를 붙들고 열심히 버튼을 눌러대는 것보다, 미리 계산을 수행하는 방법에 대한 명령서를 주고 나중에 필요할 때마다 이를 실행시키는 게 더 편하고 정확하다. 공학용 계산기에 미리 수식을 저장[footnote]이 경우 사용되는 문법은 수학 시간에 수식 쓸 때 쓰는 문법과 거의 똑같다. 프로그래밍 언어 자체가 수식에서 유래한 것이니 당연한 것이지만.[/footnote]해 놓으면(=문법에 따라 원하는 계산 결과를 내는 명령서를 만들어 주면) 필요할 때마다 호출해서 쓸 수 있는 것처럼 말이다.

전산학과에서는 도대체 뭘 배울까

여기까지만 봐도 ‘코딩은 전산학 전공자가 하는 것’이라는 생각이 완전한 착각이라는 게 드러난다. 공학용 계산기를 사용하는 사람들, 그러니까 사실상 전 이공계가 다 코딩을 하고 있다. 사실 공학용 계산기 써야 할 수준이면 애교고, 두꺼운 전공서적을 옆에 두고 밤새 전산실에서 Matlab 코딩을 하는 경우가 흔하다. 괜히 공대 필수과목에 프로그래밍이 하나씩 들어 있는 게 아니다. 대학에서만 그러는 것도 아니다. 사회 나가서도 매일같이 컴퓨터 앞에 앉아서 ‘명령서’만 쓰고 있는 조선 엔지니어, 재료 엔지니어가 수두룩[footnote]Matlab은 컴퓨터과학 학회 양대 산맥 중 하나인 IEEE가 발행한 학회지에서 선정한 세계 10대 프로그래밍 언어에 선정되기도 했다. 통계 처리 언어인 R 역시 6위에 랭크. 1~5위가 전업 개발자용 언어인 데다가 2014년 같은 조사에서 9위였던 것을 상기하면 가히 R 돌풍이라 할 만하다.[/footnote]하다.

RoboCup Dutch Open, CC BY NC ND https://flic.kr/p/bQLfHa
Mathworks사의 대표 제품인 Matlab. 1970년대 말에 개발이 시작되어 지금은 공학 컴퓨팅 언어의 대세가 되었다. 공대 출신자 중에 이걸 안 만져 본 사람이 드물 정도. (출처: RoboCup Dutch Open, CC BY NC ND

그렇다면 전산학과에서는 대체 뭘 하는 걸까? 바로 그 ‘명령서’의 자동화된 실행을 가능케 하는 이론적인 지식을 배운다. 사칙연산밖에 할 줄 모르는 CPU가 어떻게 복잡한 미적분 결과물이나 삼각함수 값을 산출해 내는지, 이상하게 느끼신 적은 없으셨나? 화면상에 박힌 텍스트 덩어리가 어떻게 디지털 회로에서 처리되는 bit의 형태로 가공되어 실행되는지, 궁금하지는 않으셨나? 전산학과에서 배우는 것은 바로 이러한 일이 가능해지도록 하는 수학적, 공학적 지식이다.

물론, 전산학과에서의 코딩은 이공계 다른 학과에서 바라보는 코딩과 그 무게가 전혀 다르다. 공대에서 바라보는 영어와 영문학과에서 바라보는 영어의 무게가 완전히 다른 것과 마찬가지로 말이다. 코딩을 안 하고서 저런 지식을 쌓는 것은 거의 불가능에 가깝기 때문에, 전산학 전공자들은 다른 이공계 전공자들과 비교하면 훨씬 더 코딩을 많이 할 수밖에 없다. 숙련도나 경험 면에서 비교가 안 되는 데다가 배경 이론까지 배우기 때문에, 이 사람들이 코딩을 훨씬 잘하는 건 이상한 일이 아니다. 하지만 그렇다고 해서, 전산학과가 코딩 배우는 곳은 아니다. 천문학과가 망원경 다루는 방법 배우는 곳이 아닌 것과 마찬가지다.

Everybody is coding!

그럼 코딩은 이공계만 하는 걸까? 그렇지도 않다. 심리학과, 경제학과, 사회학과에서도 코딩한다. 혹시 이런 학과에서 개설되는 통계 수업 들어 보신 분? 여기 수업 들어가 보면 손으로 통계 계산 안 하고 SPSS나 R 같은 통계 처리 언어를 사용해서 통계 계산을 한다. 이런 통계 패키지에 쓰이는 명령어 역시 프로그래밍 언어이기 때문에 단순한 명령들을 서로 조합해서 복잡한 통계 처리를 행할 수 있는 것이다.

그러니까, 당신이 대학에서 이런 쪽 전공을 했다면 이미 코딩을 해봤을 가능성이 크다. 학문적으로 좀 더 파고들 생각이라면 말할 것도 없다. 당신은 평생 통계에서 벗어날 수 없으며, 코딩에 대해서도 마찬가지일 것이다.

‘아무리 그래도 대부분 사람이 코딩하면서 먹고 살고 있다는 건 비약 아니냐’고 물을지도 모르겠다. 근데 사실, 위에서 나열한 것들은 그저 사족에 불과하다. 대한민국 아니 전 세계의 직장인들이 절대로 빠져나가지 못하는 궁극의 코딩 환경이 있기 때문이다: 엑셀.

끝판왕.JPG
끝판왕.JPG

사람들 대부분이 무심코 넘어가서 잘 모르는 사실이지만, ‘엑셀질’은 엄연히 코딩이다. 엑셀의 수식 기능이 ‘기계가 알아들을 수 있는 문법을 갖춰 쓴 명령서’이기 때문이다. 셀에 ‘=B2’라고만 적어 넣기만 해도 “이 셀의 값은 B2 셀의 내용과 같아야 한다.”라고 명령을 내린 셈이 된다. 그렇기 때문에 B2 셀의 내용을 바꾸면 이 셀의 값도 자동으로 바뀌는 것이다.

좀 더 정확히 말하자면, 엑셀의 수식 기능은 앞에서 소개한 통계 특화, 공학 특화 언어들과는 달리 나 같은 전업 개발자가 다루는 언어에 비해 별로 모자라는 게 없다. 애당초 전업 개발자들이 쓰던 언어를 조금 손봐서 엑셀에 내장시킨 것이기 때문이다. 정작 세월이 흐르면서 엑셀 바깥에서는 멸종하다시피 했지만, 엄연히 프로그래밍 언어라는 점에서는 변함이 없다.[footnote]기억하고 있는 사람 있는지 모르겠지만, 1994년에 발생한 인텔 펜티엄 CPU 대란 당시 인텔 CPU의 소수점 연산 기능에 문제가 있음을 증명하는 데도 엑셀이 쓰였다.[/footnote] 그래서 전산병들의 장잉력과 결합하면 지뢰찾기는 물론이고 턴제 전략 시뮬레이션 같은 무서운 물건들이 쏟아져 나온다.

이런 느낌
이런 느낌 (대사 합성, 이미지 출처: 레바 @twit_reva , 레진코믹스 레바툰 제 25화 ‘웹툰 데뷔하는 만화’)

사무직 직장인 중에서 엑셀을 안 쓰는 사람은 사실상 존재하지 않는다. 세무사나 회계사는 물론이고, 의사나 변호사 같은 ‘사’자 타이틀 보유자조차 피해 나갈 수 없는 게 엑셀이다. 요컨대, 이미 대부분 사람들은 코딩 없이 밥벌이가 안 되는 상황이다. 스스로는 잘 느끼지 못하고 있을지는 몰라도 말이다.

연산 폭주 시대

왜 이런 일이 벌어진 것일까? 앞서 예로 들었던 공학용 계산기 이야기로 돌아가자. 우리가 흔히 지나치는 것이지만, 현대 공학은 극도로 복잡한 수학적 모델 위에 건설된 대성당이라고 할 수 있다. 잘 와 닿지 않는다면, 지금으로부터 100년 전으로 돌아가 보면 된다. 컴퓨터의 발명자 중에 콘라트 추제라는 사람이 있다. 그런데 이 사람이 계산하는 기계의 개발에 매달리게 된 계기가 좀 재미있다.

토목 공학을 전공하던 학부생 시절, 전공 공부를 하는 것보다 방정식을 풀면서 계산 삽질을 하는 데 더 많은 시간을 보내야 했던 것. 대학을 마치고 추제는 헨셸 사에 취직해서 비행기를 설계하는 부서에 들어갔는데, 대학 시절 하던 계산이 그냥 커피였다면 여기서 하는 일은 T.O.P.[footnote]컴퓨터의 또 다른 발명자 중 한 사람인 하워드 에이킨 역시 비슷한 경험을 했다. 수학 박사 학위 논문을 쓰는 과정에서 끔찍하게 많은 계산에 시달렸던 것.[/footnote]… 추제가 개발한 초기의 컴퓨터들 역시 항공기 설계를 위해 만들어진 기계였다.

하지만 지금은? 혹시 공대 교과서 참고문헌 목록 뒤져보신 분? 찾아보면 알겠지만, 거기 나오는 수학적 모델 중에 추제의 컴퓨터보다 나중에 나온 게 한 무더기다. 사용되는 수학적 모델이 훨씬 복잡한 것은 물론이다. 수학적 모델이 복잡하다는 얘기는 곧 계산할 게 많다는 얘기도 된다. 장난 전화 거는 기계를 만드는 데도 컴퓨터를 동원해 계산해야 하는 마당에 다른 물건들은 오죽할까?

너도나도 공학용 계산기를 들고 다니는 것 아니 요즘 기계 중 실시간으로 연산을 처리해 주는 마이크로프로세서나 펌웨어 안 들어간 걸 더 보기 힘든 건 바로 이것 때문이다. 설계뿐만 아니라 동작에도 복잡한 수학적 모델이 사용되고 있으니까. 정리하자면, 지금의 공업 생산품은 100년 전의 그것과 비교를 불허하는 막대한 정보 처리의 결과물인 것이다.

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

모든 게 이런 식이다. 화물을 사람 손으로 선적하던 100년 전과는 달리, 현재의 컨테이너 화물 선적은 상당한 양의 연산(Cargo load scheduling)이 필요하다. 화물선 한 척에 서로 다른 무게의 컨테이너가 수백 개인데, 아무렇게나 실었다가 한쪽으로 쏠리기라도 하면 큰일 날 일 아닌가? 그걸 주고받으려면?

이미 1930년대부터 급증하는 우편물의 목적지를 더 빠르게 분류하기 위해 전국의 주소에 일정한 번호(Postal Code)를 부여하는 방안이 논의되고 있었다. 지금처럼 “인도네시아에서 보낸 부품 A는 x 항공편에 막 선적이 끝났고, y 조립공장에서 바닥난 부품 B는 추가분이 트럭으로 도착 직전” 이렇게 실시간으로 파악하는 건 SF 소설에나 나올 만한 이야기였던 것이다.

사무실도 마찬가지. 이미 100년 전부터 전미에 걸친 사업을 하고 있던 P&G는 다양한 제품의 생산 및 유통에 들어가는 이런 식의 노력에 시달린 나머지 사업부(division)라 불리는 대단히 예외적인 조직 체계를 도입해야 했다. 그게 왜 ‘예외적’인 거냐고? 내 말이 그 말이다. 100년 전 극도로 예외적이었던 것이 지금은 일상이 됐다. 요즘은 당시의 P&G보다 더 다양한 상품과 복잡한 생산 유통 라인을 가진 기업이 수두룩하다. 대기업들이 업무 처리 시스템 개발하는 데 수백억 원을 때려 넣는 게 괜히 그러는 게 아니다.

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

옛날 기술과 지금 기술 사이에 있는 것이 정보 처리다. 옛날 화물 운송과 지금 화물 운송 사이에 있는 것도 정보 처리고, 사업부 조직이 예외적인 것이었던 시절의 사무실과 지금의 사무실의 차이도 정보의 처리다. 그리고 이 모든 사회적 변화를 통틀어서 정보화 시대의 도래라고 하는 것이다. (웹 서핑 같은 거 하고는 솔직히 별 상관없다.)

모두가 코딩하게 된 건 정보화 사회의 도래로 인해 수반된 결과에 불과하다. 처리해야 할 정보가 폭주해서 도저히 사람 손으로는 처리할 수가 없으니, 이런저런 것을 처리하라는 명령서를 써서 기계한테 주고 있다는 얘기다. Matlab 프로그래밍을 하는 엔지니어에서부터 엑셀을 붙잡고 있는 직장인까지, 전부 다.

코딩 교육에 대해 반대하는 사람 중에 이러는 사람들이 있다:

‘왜 전산학과에서나 배우는 코딩을 모두에게 강요하려 하느냐’

‘모두가 컴퓨터 프로그래머가 되어야 할 필요가 있느냐’

나 역시 코딩 교육 의무화에 대해서는 다소 의구심을 가진 사람이지만, 이런 주장은 현실성을 완전히 결여하고 있다. 전산학과는 코딩 배우는 데가 아니고, 이미 모두가 코딩하고 있으며, 시대의 흐름상 이게 뒤집힐 가능성은 희박하니까. 전산학이 최고의 학문이라는 것도 아니고, 당신이 당신 일을 때려 워야 하는 것도 아니다. 당신은 그저 기계가 당신을 위해 무엇을 계산해 주면 좋을지, 명령서를 작성하는 방법만 알면 된다. 당신의 지적 활동에 도움을 줄 정도로 말이다.

기계공학과 대학원생이 Matlab 코딩을 못 해서 아이디어를 발전시키지 못하고 어버버 하고 있다면? 사회학자가 코딩을 못 해서 가설을 검증하지 못한다면? 직장인이 엑셀질을 못 해서 할 필요도 없는 야근을 연거푸 하고 있다면? 좀 더 확실하게, 엑셀질을 잘못해서 경제 정책이 산으로 가버린다면? 이런 한심한 사태가 벌어지지 않을 정도까지만 코딩할 줄 알면(≒엑셀질을 할 줄 알면) 된다는 얘기다. 그 이상 – 나처럼 대형 연산 시스템을 개발한다든가 – 은 전혀 필요 없다.

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

그게 최선입니까

그러면 역시 중고등학교에서 의무적으로 코딩을 가르치는 게 좋을까? 글쎄, 여기서부터 이야기가 좀 달라진다. 나는 코딩을 의무 교육 기간에 가르치기 전에 고민해 봐야 할 주제들이 있다고 생각한다.

우선, 왜 하필 중고등학교에서 가르쳐야 하는지? ‘A를 배워야 한다’와 ‘A를 의무 교육 과정에서 배워야 한다’는 엄연히 다른 문제다. 운전 역시 현대인의 필수 스킬이지만, 운전을 학교에서 가르치지는 않는다. 당신이 코딩 교육을 지지하는 사람이라면, 중고등학교에서 코딩을 가르치는 것이 지금처럼 대학에서 배우거나 사회 나와서 배우는 것보다 왜 더 나은지에 대해 설명할 필요가 있을 거다.

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

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

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

* 참고로 교육부와 미래창조과학부는 2015년 7월 21일 국무회의에서 초·중·고등학생 소프트웨어 교육을 확정하고, 9월에 구체적인 교육 과정을 고시할 것임을 예고했다. 그리고 역시나 졸렬한 계획 수립으로 신나게 까이고 있다.

[divide style=”2″]

[box type=”note”]이 글은 필자의 블로그(gorekun.log)에서도 볼 수 있습니다. 슬로우뉴스 원칙에 따라 원문(, )을 편집해 발행했습니다. (편집자)[/box]

관련 글

9 댓글

댓글이 닫혔습니다.