IT 관련해서 외국의 좋은 기사나 글들을 많이 소개해서 내가 최근 자주 찾는 블로그에, "영화 속 프로그램 코드의 진실"이라는 포스팅이 떴다. (이 블로그의 성격이 그런 것인지는 잘 모르겠다. 예전 포스팅까지 다 뒤져 보지는 않았기 때문에.. 하여간 최근의 글들은 그렇다) 읽다보니 몇가지 떠오르는 생각이 있어서 오랜만에 포스팅. 물론 이 블로그의 주인인 ENTClic님처럼, 나도 프로그래머도 해커도 아니다.
물론 매트릭스에 나오는 장면들은 지금의 기준으로는 다소 황당하긴 하다. 하지만 실제로는 코드를 빠른 속도로 스크롤하는 경우는 있을 수 있다.
첫째, 긴 코드에서 내가 원하는 부분을 찾고 싶을 때다. 스크롤 휠을 주루룩 내리면서 대충 훑어 보면, 각 줄의 내용은 파악할 수 없어도 내가 찾고자 하던 'foobar()'라는 함수가 들어가 있는 줄이 지나가면 눈에 들어 온다. 빠른 속도로 달리는 차 안에서 길가의 간판을 죽 훑을때 각 간판의 내용을 전부 읽을 수는 없지만, 내가 가고자 하던 식당의 간판은 눈에 확 들어오는 것과 마찬가지다.
두번째, 스크롤되어 지나가는 내용이 코드가 아니라 로그인 경우다. 간단히 설명하자면 로그는 프로그램이 어떤 식으로 돌아가고 있는지를 화면에 출력하는 기록이라고 보면 된다. 프로그램의 사용자는 볼 일이 없고, 관리자나 개발자가 보는 기록이다. 개발자는 프로그램이 최종적으로 어떤 결과를 내는지 과정을 보기 위해 코드 곳곳에 로그를 삽입하고, 실행을 시켜본 뒤 로그를 보면서 문제점을 수정(디버깅)하는 경우가 많다. 이때 로그가 주루루룩 빠른 속도로 올라가게 마련인데 결국 내가 봐야할 곳은 한두 줄이기 때문에 그 부분이 내 예상과 다르게 나오면 금방 알 수 있다.
직장 생활 초기에 베타 제품의 테스팅을 많이 하면서, 프로그램이 제대로 안 돌아가서 내가 일부 수정해야 하는 경우가 많았다. 이때 로그를 지겹게 들여다 봤는데 엔지니어가 아닌 사람이 내가 이런 일을 하고 있는 걸 어깨 너머로 보더니, 아니 저렇게 많은 내용이 잘 알아보지도 못하게 주루룩 지나가는데 어떻게 한번 보고 문제점을 찾느냐고 신기해 하던 기억이 난다. 모르면 신기해 보이지만 익숙해지면 누구나 할 수 있다. (...그건 아닌가?)
물론 예를 들어 남이 작성한 코드를 그렇게 휘리릭 스크롤해서 읽으면서 순식간에 파악할 수 있는 사람은 없다고 봐도 무방하다. 매트릭스에서 해커들이 들여다 보는 건 해킹을 위해서라기보다는 시스템 모니터링을 위해서다. 인간의 인지 능력은 미세한 차이를 상대적으로 구별해 내는 데 뛰어나기 때문에(절대적인 구별에는 젬병), 화면에 줄줄 흘러가는 로그를 하염없이 들여다 보다가 뭔가 이상한 점이 발견된 걸 찾아내는 건 어느 정도의 경험과 실력을 갖춘 엔지니어에게는 (현재로서도) 그리 어려운 일은 아니다.
20여년 전에 EGA 급 모니터를 쓰던 시절에는 검은 화면 위에 녹색 텍스트가 일반적이었는데 그때의 인식이 지금까지 이어져 오고 있나보다. 그때는 해상도가 낮아서 화면에 표현되는 줄의 수가 몇개 안돼서 저런 색조합이 가독성에 도움이 되거나 최소한 심각한 수준은 아니었던 모양인데, 요새처럼 해상도 높은 화면에 깨알 만한 글자들이 조밀하게 흩어져 있는 코드의 색조합이 이렇다면 눈이 아파서 읽을 수가 없을 거다.
호랑이 담배먹던 시전에는 복잡한 코드를 작성하면 머리가 좋거나 실력이 뛰어나다고 생각했었다. 병 잘 고치는 의사보다는 환자에게 설명 잘해 주는 의사가 인기 있는 것처럼, 요새는 남이 알아보기 편하게, 즉 재사용이 편하게 짜여진 코드가 잘 짜여진 코드다. 물론 글자나 줄의 배열이 아니라 로직의 구조를 말하는 거다.
...아 덴장 적다 보니 또 길어지네. 4~8번까지는 패스.
이건 게임하는 사람들도 마찬가지로 알고 있는데, 시스템에 익숙해질 수록 마우스를 덜쓰게 되어 있는건 맞다. 마우스를 움직여서 버튼을 클릭하거나 메뉴를 풀다운하는 대신 단축키를 사용한다. 일단 컴퓨터를 사용하는 기본적인 자세는 두손을 가지런히 키보드 위에 올려놓은 상태인데, 마우스를 잡기 위해서는 손이 움직여서 마우스를 잡아야 하고 그 후에 다시 키보드 위로 돌아와야 한다. 빠른 속도로 작업을 하는 동안에는 이 정도의 움직임도 큰 낭비가 된다.
큐베이스나 로직같은 미디 프로그램도, 익숙해지면 익숙해질 수록 단축키를 많이 사용하고 마우스는 적게 사용하게 된다. 심지어 포토샵같은 그래픽 프로그램도, 화면에 선을 그릴 때는 당연히 마우스나 스타일러스를 사용하지만, 메뉴 선택이나 명령어 입력 등에는 마우스 대신 단축키를 사용하므로, (같은 내용의 작업일 경우) 능숙한 사용자는 초보자보다 마우스를 훨씬 적게 사용한다.
유닉스나 리눅스 시스템에서 텍스트 에디터로 vi라는 것을 많이 사용하는데, 마우스를 전혀 사용하지 않고 오로지 단축키만으로 문서 편집을 한다. 워드프로세서나 메모장 등의 문서 편집 방식에 익숙한 사람한테는 황당하게 복잡한 편집기지만, 조금만 익숙해지면 마우스를 사용하는 것보다 훨씬 빠르게 시스템 문서나 프로그램 코드를 편집할 수 있다.
쥬라기공원에서 10대 소녀가 마우스 하나만 갖고 시스템을 해킹하는 건 물론 말도 안되는 설정이다. 그녀가 해커 수준의 프로그래밍 실력을 갖춘 것이라기보다는 주위의 모든 어른들이 마우스 조작조차 제대로 못할 정도로 심각한 수준의 컴맹이었다, 라고 보는 것이 맞다. (벌써 십수년 전 영화니 그런 설정이 꼭 억지만은 아니라고 하겠다)
이건 뭐 물론 영화사에 길이 남을 무식한 장면. 극장에서 볼때 내가 다 민망하더라.
옮길 회사의 입사 날짜가 아직 확정이 되지 않았음에도 불구하고, 내가 책임질 기술 부분에 대한 in-depth training이 있으니 하던 일 접고 일단 교육을 받으라고 한다. 개발자가 물건너 날아와서 직접 강의하는데 당분간 이런 기회가 없을 거라나. 교육을 입사일 이후에 받으면 이것도 다 근무일수로 치겠지만 지금은 아니잖아. 3일 짜리 교육인데 일당으로 계산해봐도 꽤 된다. (한달에 21일 정도 근무하는 것으로 치면 월급의 1/7이다) 뭐 이런 저런 핑계를 대고 쌩까는 방법도 없는 건 아니지만 입사 이후 본격적으로 업무 시작할 때 몰라서 헤매봐야 나만 손해니까, 허공에 날아간 내 일당은 생각지 말고 직원도 아니면서 공짜 교육 받는다 생각하고 듣기로 했다. (이 회사의 교육은 비싸기로 유명하다)
프로그래밍 API에 대한 교육이라, 강사가 프로젝터로 자신의 PC 화면을 뿌리고는 직접 코드를 작성하면서 설명하는 상당히 무식한 방법을 따르고 있는데, 화면의 글자 크기가 작아 보기에 영 답답하다. 영화에서 컴퓨터 화면이 나오는 장면들을 보면 항상 예외없이 글자들이 대문짝만하게 나오는데, 실제로 그렇게 작업을 하는 사람은 없을 거다. 하지만 (나도 지금 1400x1050 해상도의 윈도우에서 10pt 정도의 크기로 이 포스팅을 적고 있지만) 사람들이 보통 사용하는 글자 크기로 영화에서 보여준다면 관객들은 이 사람이 무슨 일을 하고 있는 건지 절대 알아볼 수 없다.
1. 코드는 움직이지 않는다.
영화를 보면 컴퓨터화면에서 읽을 수 조차 없이 코드가 화면을 따라 빠른 속도로 스크롤 되는 것을 볼 수 있다.
그러면 해커는 그 것을 보고 어떻게 해결해야 하는지 곧바로 알 수가 있다.
사실은 그렇지 않다고 한다..만약 저런 속도로 코드가 출력된다면 신문 6개를 동시에 읽는 것과 같다고 한다.
즉 아무리 뛰어난 프로그래머라도 저건 불가능 하다고 한다.
프로그램을 실행시키고 다시 천천히 스크롤 하면서 한줄 한 줄씩 검사를 하지 저런 방식으로 코드를 검사하는 사람은 아무도 없다고..
물론 매트릭스에 나오는 장면들은 지금의 기준으로는 다소 황당하긴 하다. 하지만 실제로는 코드를 빠른 속도로 스크롤하는 경우는 있을 수 있다.
첫째, 긴 코드에서 내가 원하는 부분을 찾고 싶을 때다. 스크롤 휠을 주루룩 내리면서 대충 훑어 보면, 각 줄의 내용은 파악할 수 없어도 내가 찾고자 하던 'foobar()'라는 함수가 들어가 있는 줄이 지나가면 눈에 들어 온다. 빠른 속도로 달리는 차 안에서 길가의 간판을 죽 훑을때 각 간판의 내용을 전부 읽을 수는 없지만, 내가 가고자 하던 식당의 간판은 눈에 확 들어오는 것과 마찬가지다.
두번째, 스크롤되어 지나가는 내용이 코드가 아니라 로그인 경우다. 간단히 설명하자면 로그는 프로그램이 어떤 식으로 돌아가고 있는지를 화면에 출력하는 기록이라고 보면 된다. 프로그램의 사용자는 볼 일이 없고, 관리자나 개발자가 보는 기록이다. 개발자는 프로그램이 최종적으로 어떤 결과를 내는지 과정을 보기 위해 코드 곳곳에 로그를 삽입하고, 실행을 시켜본 뒤 로그를 보면서 문제점을 수정(디버깅)하는 경우가 많다. 이때 로그가 주루루룩 빠른 속도로 올라가게 마련인데 결국 내가 봐야할 곳은 한두 줄이기 때문에 그 부분이 내 예상과 다르게 나오면 금방 알 수 있다.
직장 생활 초기에 베타 제품의 테스팅을 많이 하면서, 프로그램이 제대로 안 돌아가서 내가 일부 수정해야 하는 경우가 많았다. 이때 로그를 지겹게 들여다 봤는데 엔지니어가 아닌 사람이 내가 이런 일을 하고 있는 걸 어깨 너머로 보더니, 아니 저렇게 많은 내용이 잘 알아보지도 못하게 주루룩 지나가는데 어떻게 한번 보고 문제점을 찾느냐고 신기해 하던 기억이 난다. 모르면 신기해 보이지만 익숙해지면 누구나 할 수 있다. (...그건 아닌가?)
물론 예를 들어 남이 작성한 코드를 그렇게 휘리릭 스크롤해서 읽으면서 순식간에 파악할 수 있는 사람은 없다고 봐도 무방하다. 매트릭스에서 해커들이 들여다 보는 건 해킹을 위해서라기보다는 시스템 모니터링을 위해서다. 인간의 인지 능력은 미세한 차이를 상대적으로 구별해 내는 데 뛰어나기 때문에(절대적인 구별에는 젬병), 화면에 줄줄 흘러가는 로그를 하염없이 들여다 보다가 뭔가 이상한 점이 발견된 걸 찾아내는 건 어느 정도의 경험과 실력을 갖춘 엔지니어에게는 (현재로서도) 그리 어려운 일은 아니다.
2. 코드는 검은 화면위에 나오는 녹색 텍스트가 아니다.
물론 그렇게도 할 수는 있지만 대부분의 프로그래머들은 syntax highlighting등을 사용해서 ANSI color를 사용한다고 한다.
20여년 전에 EGA 급 모니터를 쓰던 시절에는 검은 화면 위에 녹색 텍스트가 일반적이었는데 그때의 인식이 지금까지 이어져 오고 있나보다. 그때는 해상도가 낮아서 화면에 표현되는 줄의 수가 몇개 안돼서 저런 색조합이 가독성에 도움이 되거나 최소한 심각한 수준은 아니었던 모양인데, 요새처럼 해상도 높은 화면에 깨알 만한 글자들이 조밀하게 흩어져 있는 코드의 색조합이 이렇다면 눈이 아파서 읽을 수가 없을 거다.
3. 코드는 구조를 가지고 있다.
영화에서 해커들을 보면 스페이스 바나 엔터를 쳐서 코딩하는 경우가 거의 없다.
즉 모든 것이 한 줄로 이어지는 구조를 가지고 있는 것이다.
실제로는 그렇지 않다고 한다.
이젠 프로그램 코드도 알기 쉬운 구조로 만든다고 한다.
호랑이 담배먹던 시전에는 복잡한 코드를 작성하면 머리가 좋거나 실력이 뛰어나다고 생각했었다. 병 잘 고치는 의사보다는 환자에게 설명 잘해 주는 의사가 인기 있는 것처럼, 요새는 남이 알아보기 편하게, 즉 재사용이 편하게 짜여진 코드가 잘 짜여진 코드다. 물론 글자나 줄의 배열이 아니라 로직의 구조를 말하는 거다.
...아 덴장 적다 보니 또 길어지네. 4~8번까지는 패스.
9. 코드를 쓰는 사람들도 마우스를 사용한다.
영화에서 보면 해커가 마우스 사용하는 모습을 거의 볼 수가 없다.
물론 프로그래머들이 빠른 타이핑 실력을 가지고는 있지만 마우스 사용하지 않는 사람도 없다.
이건 게임하는 사람들도 마찬가지로 알고 있는데, 시스템에 익숙해질 수록 마우스를 덜쓰게 되어 있는건 맞다. 마우스를 움직여서 버튼을 클릭하거나 메뉴를 풀다운하는 대신 단축키를 사용한다. 일단 컴퓨터를 사용하는 기본적인 자세는 두손을 가지런히 키보드 위에 올려놓은 상태인데, 마우스를 잡기 위해서는 손이 움직여서 마우스를 잡아야 하고 그 후에 다시 키보드 위로 돌아와야 한다. 빠른 속도로 작업을 하는 동안에는 이 정도의 움직임도 큰 낭비가 된다.
큐베이스나 로직같은 미디 프로그램도, 익숙해지면 익숙해질 수록 단축키를 많이 사용하고 마우스는 적게 사용하게 된다. 심지어 포토샵같은 그래픽 프로그램도, 화면에 선을 그릴 때는 당연히 마우스나 스타일러스를 사용하지만, 메뉴 선택이나 명령어 입력 등에는 마우스 대신 단축키를 사용하므로, (같은 내용의 작업일 경우) 능숙한 사용자는 초보자보다 마우스를 훨씬 적게 사용한다.
유닉스나 리눅스 시스템에서 텍스트 에디터로 vi라는 것을 많이 사용하는데, 마우스를 전혀 사용하지 않고 오로지 단축키만으로 문서 편집을 한다. 워드프로세서나 메모장 등의 문서 편집 방식에 익숙한 사람한테는 황당하게 복잡한 편집기지만, 조금만 익숙해지면 마우스를 사용하는 것보다 훨씬 빠르게 시스템 문서나 프로그램 코드를 편집할 수 있다.
쥬라기공원에서 10대 소녀가 마우스 하나만 갖고 시스템을 해킹하는 건 물론 말도 안되는 설정이다. 그녀가 해커 수준의 프로그래밍 실력을 갖춘 것이라기보다는 주위의 모든 어른들이 마우스 조작조차 제대로 못할 정도로 심각한 수준의 컴맹이었다, 라고 보는 것이 맞다. (벌써 십수년 전 영화니 그런 설정이 꼭 억지만은 아니라고 하겠다)
10 대부분의 코드는 크로스 플랫폼이 아니다.
Independence Day 영화에서는 애플노트북에서 만든 바이러스를 외계인 컴퓨터에 넣어서 전염 시키는데..이런 방법은 절대로 일어날 수 없다.
애플과 윈도우사이에서도 잘 되지 않는데 어떻게 외계인 컴퓨터에..OTL
이건 뭐 물론 영화사에 길이 남을 무식한 장면. 극장에서 볼때 내가 다 민망하더라.
옮길 회사의 입사 날짜가 아직 확정이 되지 않았음에도 불구하고, 내가 책임질 기술 부분에 대한 in-depth training이 있으니 하던 일 접고 일단 교육을 받으라고 한다. 개발자가 물건너 날아와서 직접 강의하는데 당분간 이런 기회가 없을 거라나. 교육을 입사일 이후에 받으면 이것도 다 근무일수로 치겠지만 지금은 아니잖아. 3일 짜리 교육인데 일당으로 계산해봐도 꽤 된다. (한달에 21일 정도 근무하는 것으로 치면 월급의 1/7이다) 뭐 이런 저런 핑계를 대고 쌩까는 방법도 없는 건 아니지만 입사 이후 본격적으로 업무 시작할 때 몰라서 헤매봐야 나만 손해니까, 허공에 날아간 내 일당은 생각지 말고 직원도 아니면서 공짜 교육 받는다 생각하고 듣기로 했다. (이 회사의 교육은 비싸기로 유명하다)
프로그래밍 API에 대한 교육이라, 강사가 프로젝터로 자신의 PC 화면을 뿌리고는 직접 코드를 작성하면서 설명하는 상당히 무식한 방법을 따르고 있는데, 화면의 글자 크기가 작아 보기에 영 답답하다. 영화에서 컴퓨터 화면이 나오는 장면들을 보면 항상 예외없이 글자들이 대문짝만하게 나오는데, 실제로 그렇게 작업을 하는 사람은 없을 거다. 하지만 (나도 지금 1400x1050 해상도의 윈도우에서 10pt 정도의 크기로 이 포스팅을 적고 있지만) 사람들이 보통 사용하는 글자 크기로 영화에서 보여준다면 관객들은 이 사람이 무슨 일을 하고 있는 건지 절대 알아볼 수 없다.
제 글이 도움이 되셨다면, RSS 구독해 주세요!! (클릭->>) 
재미있게 읽고 돌아가겠습니다...^^
항상 봐 오던 이야기지만은 같이 프로그램을 공부하는 학생들끼리는 "저것은 아니다~~ 에이.." 이러는데 이렇게 일목 요연하게 정리를 한신것으로 보아서 정말 많은 생각을 하시고 글을 적으신것 같습니다.
좀더 다른 사람들이 영화에서 한부분만이라도 진실을 볼 수 있다면은 좋을지도 모르겠습니다.
ㅎㅎ..글 잘 읽었습니다 ^^
아주 잘 분석을 하셨네요..역시 노력과 습관으로 가능한 것들도 있군요^^
별로 생각하고 적은 글은 아니구요.. ^^
전문가 집단이 등장하는 영화의 경우 그들로부터 인정을 받기가 쉽지 않은데, 결국 그 집단은 어디까지나 소재일 뿐 영화가 하고자 하는 건 일반 대중하고의 소통이니까, 소통을 위해 전문분야의 현실을 다소 변형해서 보여주는건 충분히 받아들일 수 있어야 한다고 생각합니다. 물론 그렇다고는 해도 인디펜던스데이는 용서가 안되지요.
노력과 습관은 공중부양도 가능하게 하는 걸로 알고 있습니다. ^^