관심 있는 부분의 옛날 이야기를 듣는 일은 흥미롭다.
학교에 단 한 대밖에 없는 IBM 메인프레임에서 수치 해석 문제를 풀기 위해 한 시간씩 기달려서 카드에 천공을 뚫어 묶어 제출하면, 오퍼레이터는 그 명령어를 밤새 돌려서 결과물을 출력하여 준다고 했다. 출력된 결과물에 에러가 뜨면, 다시 또 한 시간씩 기다려서 천공 카드를 작업하기를 수차례 반복하게 된다. 자연히 문제는 실수를 얼마만큼 내지 않느냐가 되었다. 그 언어가 FORTRAN이었다. 이 언어는 Formular Translating에서 그 이름을 지었다. J3에 의해서 Fortran 2003의 개정판 Fortran 2008이 여전히 개발 중이다.
그래서 그는 컴퓨터를 무척이나 싫어했다. 전자계산기가 사람이 풀 수 없는 문제를 수치적으로 근사해서 풀어주는 것은 좋지만 입출력 과정이 너무나 번거로웠기 때문이다. 어느 날 친구가 전자 상가에서 애플 개인화 컴퓨터의 초기 형태를 사 들고 와서 그에게 보여 주었다. 명령 행 입력방식이었던 애플의 컴퓨터는, 커맨드 라인에 원하는 프로그램을 입력하고 기다리면 결과가 바로 나왔다. 놀랄 수밖에 없었다.
이후 C라는 언어가 개발되고 C라는 언어를 바탕으로 운영체제들이 개발되면서, 포트란을 사용하던 사람은 우리가 정말 이렇게 쉽게 개발해도 되나, 포트란을 사용하던 당시에 그들이 가졌던 프로그램의 확신을 버리고, 프로그래밍 언어의 라이브러리를 전적으로 믿을 수밖에 없는 상황에 닥치게 되었다. 천공 방식의 포트란은 C보다 기계에 가까운 것이었기 때문에 어디에서 에러가 나면 어디가 틀렸는지 명명백백했지만 여기서는 그렇게 세부적으로 확인하기란 현실적으로 어려운 일이었기 때문이었다. 나사가 그 당시의 슈퍼컴퓨터라고는 하지만 현재 사용하고 있는 휴대전화에도 미치지 못할 성능에서 우주선을 달에 보내야 했던 제약조건은, 가치를 매길 수 없는 알고리즘들의 발전과 최적화를 가져왔다. 또한, C는 high-level programming language였음에도 불구하고, 하드웨어의 어드레스를 직접 다룰 수 있다는 점에서 기계어 쪽과 가까운 메리트가 있었다. 하지만 재사용성(모듈의 부재)는 치명적인 C의 약점이었다.
컴퓨터의 하드웨어가 발전하고 메모리의 용량도 해마다 증가함에 따라서, 최적화 제약조건은 고려할 필요가 점차 사라졌다. 비결정 다항(Non-deterministic Polynomial) 문제로 효율적인 알고리즘을 짜는 것이 불가능한 문제가 아니라면, 최적화에만 매달리기 보다 유지보수하기 쉽고 가독성이 좋은 코드를 작성하는 편이 더 나았다. 부족한 메모리를 사서 해결할 수 있을 정도라면 말이다. 스크립트 언어인 파이썬, 루비 등이 등장하면서 코드를 쓰기란 더욱 편해졌다. 매쓰매티카, 메이플같은 프로그램의 너무 고차원의 프로그래밍 환경이라 필요없는 모든 라이브러리를 잔뜩 불러와 컴퓨터가 느려지고, 가끔 잘못된 라이브러리를 참조하여 연산할 경우 그 결과도 틀릴 수가 있다. 현재에는 파이썬이 수치 해석이나 전산 시늉에 가장 적합한 타협안으로 보인다. 직접 코드를 타이핑해서 인터프리팅할 경우, 자기가 필요한 모듈들만 불러와서 계산할 수 있어 더 효율적이다. User-friendly하면서도 루비처럼 너무 고차원의 스크립트 언어도 아니기 때문이다.
비선형 미분 방정식의 경우 대부분 Closed form으로 풀리지 않는다. 해석적으로 풀리지 않는 문제의 경우 special function으로 근사 후 그 수치를 플롯하여, 대체적인 해나 생김새를 알 수 있다. 주기가 무한히 길어지는 Strange attractor cycle의 그래프를 분석할 때 컴퓨터의 도움을 받으면 문제가 좀 더 쉬워진다. 이런 방법은 누가 따로 가르쳐주는 것이 아니기 때문에, 스스로 앞으로 난제와의 전투에 필요한 유리한 도구를 갖춘다는 마음으로 공부할 필요가 있다.
댓글 없음:
댓글 쓰기