요약
Fortran 첫 설명서가 나온 지 70년을 맞아, 12월 영국 맨체스터에서 기념 행사가 열립니다.
케임브리지대학교 기후과학컴퓨팅연구소(ICCS)의 조 월워크가 Fortran 공식 사이트에 올린 행사 안내 글입니다. Fortran의 첫 설명서는 70년 전 10월 15일에 나왔고, ICCS가 이를 기념하는 워크숍을 엽니다.
왜 중요한가
- 글쓴이는 Fortran이 원자력 공학, 기상·기후 예측, 재료과학에서 지금도 가장 먼저 고르는 언어라고 말합니다.
- 지난 70년을 돌아보는 데서 그치지 않고, 앞으로 70년을 사용자들이 함께 논의하는 자리로 짜였습니다.
- 참가비가 없고 Zoom으로도 참여할 수 있어 현장에 오지 못하는 사용자도 함께할 수 있습니다.
핵심 내용
- 행사는 2026년 12월 1일 맨체스터 과학산업박물관에서 열리고, 워크숍은 오후 2시 30분부터 6시 15분까지입니다.
- 로런스버클리국립연구소의 데이미언 루슨이 Fortran의 지난 70년을 주제로 기조연설을 합니다.
- 최근 개발 현황을 다루는 짧은 발표(라이트닝 토크)와 앞으로 70년을 논의하는 자유 토론이 이어집니다.
- 저녁에는 전시장에서 리셉션이 열리고, 1940년대 실험용 컴퓨터 '베이비'를 시연합니다.
- 등록은 11월 9일에 마감하며, 짧은 발표와 포스터, 토론 주제도 제안할 수 있습니다.
HN 반응
- 지금도 쓸 만한지를 두고 C가 낫다는 의견과, 포인터 별칭(같은 메모리를 여러 포인터가 가리킴)이 없어 수치 계산 최적화에 유리하다는 반론이 맞섰습니다.
- 1950~60년대 코드를 유지보수한 이용자들은 여섯 글자로 제한된 변수명과 COMMON 블록, GOTO에 시달린 경험을 회고했습니다.
컴퓨터 역사 박물관(CHM)에서 존 배커스(John Backus)[1]의 구술 역사[0]를 수집해 두었는데, 포트란이 만들어질 무렵 컴퓨팅이 어땠는지에 대한 이야기가 나옵니다.
CHM의 구술 역사는 정말 좋아합니다. 하나씩 천천히 다 보고 있는데, 보석 같은 영상이 꽤 많습니다(켄 톰슨, 데니스 리치, 마거릿 해밀턴, 고든 무어, 프레드 브룩스, 존 워녹 등).
[0] https://www.youtube.com/watch?v=dDsWTyLEgbk
[1] https://en.wikipedia.org/wiki/John_Backus
배커스가 1976년 제1회 컴퓨팅 역사 국제 연구 학회에서 했던 "1950년대 미국의 프로그래밍 - 개인적인 인상들" 강연도 있습니다. https://www.youtube.com/watch?v=EylBknGtkqA 학회 논문은 A History of Computing in the Twentieth Century(1980, Metropolis, Howlett, Rota 편, ISBN 0-12-491650-3 )의 125~135쪽에 실려 있습니다. https://archive.org/details/historyofcomputi0000inte/page/125/mode/2up 당연히 1978년 제1회 History of Programming Languages 학회에서도 한 세션을 차지했고 https://dl.acm.org/doi/10.1145/960118.808379 배커스가 거기서 다시 강연을 했습니다. https://dl.acm.org/doi/book/10.1145/800025#sec2 그리고 물론 진 새멋(Jean Sammet)이 1969년에 쓴 Programming languages: history and fundamentals(ISBN 0137299885)에서도 주인공 격이고, FORTRAN 부분은 143쪽에서 시작합니다. https://archive.org/details/programminglangu00unse/page/143/mode/2up .
저는 50년대 포트란 코드를 아직도 쓰면서 지금도 유지보수하는 소프트웨어를 다뤘던 적이 있습니다. 기억하기로는 포트란이 70만 줄쯤 됐고, 지금도 쓰이는 포트란 코드베이스 중 가장 오래되고 가장 큰 축에 들 겁니다.
거기서 맡은 첫 프로젝트가 코드에서 홀러리스(Hollerith) 상수를 전부 걷어내는 일이었습니다. 포트란은 문자열이라는 개념보다 먼저 나온 언어라서 문자열을 정수로 다뤄야 했습니다. 거기에 원래 포트란의 동적 메모리 시스템인 Dynosour까지 얽히면 재앙이었습니다. 이게 equivalence된 배열을 포인터처럼 썼거든요.
덕분에 JavaBeanFactoryFactory 같은 이름의 고마움도 알게 됐습니다. 원래 포트란은 식별자를 6글자로 제한했고, 첫 글자는 변수가 정수인지, 논리형(bool)인지, 실수형(float)인지를 나타냈습니다. ILBNK1 같은 이름보다는 100글자짜리 이름을 언제든 택하겠습니다.
GOTO는 의외로 큰 문제가 아니었습니다. 다만 구조적 코드가 읽기에 확실히 더 쉽습니다. 들여쓰기 관행도 구조적 코드와 함께 들어왔으니까요.
전체적으로 훌륭한 경험이었지만, 일 자체는 흥미로웠어도 다시 하고 싶지는 않습니다.
제가 들어 본 중에서는 지금도 쓰이는 가장 오래된 포트란 코드베이스 중 하나일 수는 있어도, 가장 큰 건 아닙니다. (문자 자료형은 '77년에 들어온 거 맞죠?)
E3SM [0]은 지금도 유지보수되고 있고, F90 코드가 200만 줄쯤 됩니다.
현대 포트란에는 편리한 기능이 많이 들어와 있습니다.
[0] https://e3sm.atlassian.net/wiki/spaces/DOC/overview | https://github.com/E3SM-Project/E3SM
홀러리스를 걷어낸다는 건 처음에 포트란에서 문자열을 적던 방식을 말하는 겁니다. https://en.wikipedia.org/wiki/Hollerith_constant
짧은 이름 말고도 common 블록과 computed goto가 원시 시대 포트란을 유지보수하던 시절 저를 괴롭힌 주범이었습니다. 제 첫 프로젝트이자 인턴 프로젝트가, 펀치 카드 시대(60년대 초반이 가장 유력했습니다)의 코드베이스를 텍스트로 옮겨 놓은 것을 f77로 컴파일되게 번역하는 일이었습니다. 다행히 문자열은 거의 다룰 필요가 없었습니다.
포트란은 저에게 아주 중요한 언어였습니다.
초기 마이크로컴퓨터와 BASIC으로 컴퓨터를 접하며 자랐는데, 아버지가 TRS-80용 포트란을 가지고 계셨습니다.
독학해 보려고 했지만 문서는 컴파일러 호출법을 적은 레퍼런스일 뿐 언어를 배우는 용도가 아니었습니다. 포트란 책을 찾아도 꽤 오래된 책이라 테이프니 펀치니 하는 이야기만 나왔습니다.
그래서 그 시도는 흐지부지됐습니다.
하지만 대학교 첫 학기에 포트란(77) 수업을 들었습니다. 학교의 CDC Cyber 메인프레임으로 포트란을 가르쳤습니다.
8비트 PET BASIC과는 꽤 큰 차이였습니다.
그런데 가장 중요한 건, 8비트 컴퓨터와 똑같은 개념을 다른 접근 방식으로 접하게 됐다는 점입니다.
덕분에 사물을 더 높은 차원에서 보는 법을 얻었습니다. 포트란이 세상을 보는 방식, Cyber가 세상을 보여 주는 방식, 그리고 BASIC과 PET이 "같은 것의 다른 모습"이라는 점, 이 두 가지 시각에 모두 끼워 맞춰야 했으니까요.
또 다중 사용자 시스템과 그 시스템이 제공하는 온갖 흥미로운 기능을 쓸 수 있게 됐습니다.
학교에 처음 PC 실습실이 생기고 사람들에게 마이크로컴퓨터로 Turbo Pascal을 가르치기 시작했을 때가 기억납니다. 그때 저는 그 사용자들이 더 큰 세상을 놓치고 있다고 느꼈습니다. "누구나" 집에서 PC나 마이크로컴퓨터는 쓸 수 있지만, 메인프레임이나 다중 사용자 미니컴퓨터는 그렇지 않으니까요. 바깥에는 훨씬 더 큰 세상이 있는데, 우리는 처음 본 것을 어미로 따르는 아기 오리처럼 굴기 쉽습니다.
지금은 세상이 달라졌고 직업적으로 포트란을 써 본 적은 없지만, 포트란과 그 환경을 배운 경험에는 정말 감사합니다. 더 넓게 배우게 해 주는 아주 강력한 매개였습니다.
또 포트란은 제가 컴퓨터에 관해 "가르침을 받은" 거의 유일한 대상이기도 했습니다(고등학교 선생님께 20분 동안 BASIC을 소개받은 것은 빼고요). 나머지는 거의 다 책 같은 걸로 독학했고, 학교 수업을 듣기 전에 이미 대부분 알고 있었습니다.
앨런 케이가 올바른 관점은 IQ 80점의 가치가 있다고 말하곤 했던 걸로 기억합니다. 우리는 늘 경험과 시야를 넓히려고 애써야 합니다. 잘못된 관점은 잔뜩 얻게 되지만, 그렇게 얻은 관점 하나가 다른 누구도 바로 알아내기 어려운 문제에 딱 들어맞는 열쇠가 될 수 있습니다.
하하, 저도 고등학교 때 그 TRS-80용 (마이크로소프트!) 포트란을 썼습니다. 화학 실험 보고서용으로 계산 과정에서 오차 범위와 유효 숫자를 전파하는 라이브러리를 만들었죠. (BASIC으로도 아마 됐겠지만, 어떻게든 포트란을 써 볼 핑계를 찾고 있었던 것 같아요 :-)
포트란은 역사적으로는 중요하지만 요즘 선택할 만한 언어로는 별로 안 보입니다.
저는 Fortran 77로 작성된 독점 제트 엔진 해석 소프트웨어 모음을 다뤘는데, 빠르긴 해도 아주 원시적인 느낌이었습니다.
요즘은 속도로나 가독성으로나 C가 훨씬 나은 선택이라고 생각합니다.
정말 최고 성능이 필요하다면, 포트란이 어셈블리를 직접 쓰는 것보다 크게 유리하다고 보지는 않습니다.
벡터 머신에서는 포트란이 (훨씬) 더 빠른 코드를 만들어 냈습니다. (a) "먼지 쌓인 카드 뭉치(dusty deck)" 코드용 전처리기에 엄청난 공을 들였고, (b) 포인터가 없어서 겹침(aliasing)이 생기지 않으니 컴파일러가 제 할 일을 할 수 있었기 때문입니다. C 코드는 일부 포인터가 서로 겹치지 않으니 최적화해도 된다고 알려 주려면 #pragma가 잔뜩 필요했습니다.
저희는 코드의 프런트엔드와 I/O는 C로, 계산은 포트란으로 짜는 게 최선이라는 걸 알게 됐습니다. 특히 맞춤형 라이브러리를 쓰면 계산이 가장 빨랐습니다.
배열 기반 프로그래밍은 포트란이 처음 만들었고, numpy가 그걸 발전시켰고, 이제 Julia가 마침내 완성했다고 할 수 있죠.
포트란은 처음부터 배열이 있긴 했지만, 식이 배열을 만들어 낼 수 없었기 때문에 사소한 의미를 빼면 "배열 기반 프로그래밍"을 위한 언어는 아니었습니다. 일급 배열을 처음 만든 언어는 APL이고, 그쪽이 NumPy를 비롯한 대부분의 후속 언어보다 훨씬 앞서 있습니다.
현대 포트란은 배열 프로그래밍 지원이 꽤 쓸 만합니다.
저는 2018년에 소프트웨어 개발자로서 첫 직장에서 시뮬레이션 솔버 때문에 포트란을 썼습니다. 지금도 이 언어가 좋아요! 현대 포트란은 아주 아주 빠르고, 선형대수에는 C보다 훨씬 쓰기 좋습니다. 그래서 제 생각에 수치 계산에는 지금도 최고의 언어입니다. 생일 축하해요!
예전에 일하던 대학 전산 센터에서 프로그래밍 문제를 봐 주는 무료 헬프데스크를 맡았습니다. "프로그램 최신 출력본 가지고 오셨어요?"라고 물으면 대부분 돌아갔죠.
가장 안타까웠던 건 화학공학 박사과정생이었습니다. 논문 작업이 거의 끝나 가는데 결과가 재현되지 않아 고생하고 있었어요. 30분쯤 디버깅하다 보니 그 학생이 초기화되지 않은 포트란 배열 상태를 데이터로 쓰고 있다는 걸 알게 됐습니다. 그 학생의 발견은 아마 연기처럼 사라졌겠죠.
저는 40년 전 첫 직장에서 FORTRAN으로 프로그래밍을 시작했습니다. 소프트웨어 공학 관점에서는 끔찍한 부분이 많았습니다. COMMON 블록, GOTO, ENTRY 포인트(서브루틴 중간으로 진입하는 것!) 같은 것들이요. 그래도 최초의 고수준 언어 중 하나였고, 언어 설계자들도 배울 게 많던 시절이었습니다.
저는 (특정 영역의 X선 산란과 흡수를 다루는, 말하자면 꽤 "틈새" 분야의) 오픈 소스 포트란 라이브러리를 작성한 적이 있는데, 진심으로 궁금합니다. 요즘 포트란이 다른 언어보다 나은 점이나 강점이 있다면 뭘까요? 포트란이 "옳은" 선택이라고 할 만한 상황이 있을까요?
포트란이 초기에 가졌던 절대적인 장점(수치 정밀도, 비에일리어싱)은 상당 부분 C가 받아들였습니다.
하지만 포트란이 여전히 훌륭한 선택인 이유는, C에 비해 비교적 단순한 언어이고 수학 공식을 코드로 옮기기에 아주 좋기 때문입니다. 세련되지 못한 코드도 그럭저럭 빠르게 돌아가고(C는 그렇지 않죠), 이런 점들 덕분에 전문 프로그래머나 소프트웨어 엔지니어가 아니라 도메인 전문가(즉 과학자)가 프로그램을 짤 때 실제로 좋은 언어가 됩니다.
하나 여쭤봐도 될까요? 그 라이브러리를 왜 포트란으로 작성하셨나요? 그러니까 작성하실 당시에는 지금 하신 질문에 어떻게 답하셨을지요.
포트란은 에일리어스가 없어서 배열 처리 최적화가 아주 아주 잘 된다고 들었습니다. 오늘날 하나의 답이 될 수 있겠죠. 연속성의 가치도 있습니다. 다른 사람들이 쌓아 놓은 것 위에 올릴 수 있으니 그 언어를 고른다는 거죠. 물론 이건 오래된 언어라면 어디에나 해당되겠지만... 지금 누군가 수치 처리 라이브러리를 새로 만든다면 합리적으로 적용될 수 있다고 봅니다. 포트란으로 짜서 파이썬에서 호출하는 식으로요!
답은 "지도교수님이 자기가 쓰는 언어라며 고집하셨기 때문"이었습니다. 저는 77이 아니라 Fortran 95를 쓰겠다고 싸워야 했어요. 그러니 말씀하신 대로, 그 가치는 익숙하고 편하게 쓰는 언어로 기존 커뮤니티의 코드베이스 위에 쌓는다는 데 있었던 것 같습니다.
제 생각에 포트란은 자기 틈새 분야에서는 최고입니다. 고도로 최적화된 기계어로 컴파일되는 수치 알고리즘을 짜면서도 (적어도 F90부터는) 읽기도 직관적으로도 괜찮은 수준이니까요. 파이썬용 연산 집약적 수치 확장을 짜는 가장 쉬운 방법이라고 해도 무방할 겁니다 (단, 싱글 스레드여야 하고, numpy로 안 되는 경우여야 하고, GPU를 안 쓸 때 얘기지만요...).
한때 맨 처음 버전의 FORTRAN은 어떻게 생겼는지 꽤 궁금해서 거기서 FizzBuzz [1]를 짜 봤습니다.
정말 뼈대만 있는 언어였고, 고수준 어셈블리 매크로 언어에 가까운 느낌이었습니다. 잘한 점 하나는 흔히 쓰는 "수학" 표기(+, -, *, /, 연산을 묶는 괄호, 변수)로 수식을 표현할 수 있다는 점이었습니다. 당시에는 혁명적이었겠죠. 하지만 제어 구조가 아주 제한적이어서 사실상 전부 점프와 goto였습니다. IF도 조건부 점프의 문법적 설탕에 불과했고요. 물론 언어에 함수는 없었습니다.
[1] https://mveg.es/posts/fizzbuzz-in-fortran-1/
이름부터가 "Formula Translation(수식 번역)"의 약자니까요.
맞습니다. 앞선 사례가 있긴 했지만, 이런 걸 제공한 첫 "주류"(그 시대 기준으로) 언어는 포트란이었습니다.
90년대 중반에 화학 공학 플랜트의 증류탑을 모델링하는 데 포트란을 썼습니다. 여기서 읽어 보니 핵공학에서는 지금도 포트란이 주력 언어라고 하네요. 놀랍지만, 왠지 모르게 기쁩니다.
예전에 천문학자들과 일할 때 전 애인이 "A Fortran Coloring Book"을 선물해 줬습니다. 저는 아직 대학원생이었는데, 덕분에 포트란을 배울 핑계가 생겼죠.
제 두 번째 대학 코업 근무에서 FORTRAN 77 컴파일러 프런트엔드를 작성했고, 그게 16년간 이어진 첫 정식 직장으로 연결됐습니다. 요즘 기준으로는 미친 수준입니다. 어떤 경우에는 여러 줄에 걸친 문장이 어떤 종류의 문장인지 알아내려면 끝에서 두 번째 글자까지 봐야 합니다.
대학을 졸업하자마자 80년대 중반 캐나다 제록스 연구소에서 포트란으로 첫 레이 트레이서를 작성했습니다. 환경은 VAX 11/750에 RasterTech 컬러 모니터(기억이 맞다면 512x512)였어요. [0]
구현은 데이비드 로저스(David Rogers)의 "Procedural Elements for Computer Graphics"를 바탕으로 했습니다. 당시 3D 그래픽스 교재는 단 두 권뿐이었는데, 다른 하나는 폴리와 밴담(Foley and VanDam)이었죠.
재귀를 지원하지 않는 언어에서 스택을 직접 관리했던 기억이 납니다. 많이 배웠어요. 좋은 시절이었습니다.
[0] https://medium.com/@kaveh808/8-summer-at-xerox-in-24-bit-color-74ad465a07be
더 정확히 말하면 이렇습니다.
수년간의 FORTRAN. 그다음 수년간의 Fortran.
저는 1990년대에 포트란을 배우고 싶어서 대학 도서관에서 포트란 책을 빌렸습니다. 첫 페이지인가 두 번째 페이지에 "주석을 표시하려면 펀치 카드의 첫 번째 열에 문자 'C'를 뚫으세요"라고 쓰여 있더군요. 책을 반납했고 포트란은 끝내 배우지 않았습니다.
그렇긴 해도 기초가 되는 라이브러리가 정말 많이 포트란으로 구현됐습니다(BLAS, LINPACK/EISPACK, LAPACK, MINPACK, FISHPACK, FFTPACK 등). 그 점은 고맙게 생각합니다.
메인프레임 시대 시스템은 80자짜리 펀치 카드를 기반으로 고정 크기나 제한된 크기의 버퍼와 자료구조를 쓰는 경우가 많았습니다. 360의 대부분의 주소 지정 모드는 레지스터에 든 포인터에 12비트 즉치 변위를 더하는 방식이었고요 [1] 바이트 같은 것도 그렇고요.
비웃기는 쉽지만, C 프로그래머들은 스택 위의 가변 크기 버퍼나 malloc(), free() 같은 걸 감당하지 못한다는 걸 입증해 왔습니다.
초기 FORTRAN [2]에는 스택조차 없었습니다. 그래서 재귀 함수를 작성할 수 없었고, 프로그램이 부팅될 때 배열 크기에 대한 매개변수를 받으면 메모리 배치를 시작할 때 전부 정해졌습니다. 저는 AVR-8용 잔상(persistence of vision) 디스플레이 컨트롤러를 개발할 때, 어셈블리 프로그램은 정적으로 할당된 구조체와 데이터를 주고받으면 되는데 C 컴파일러는 별다른 이유도 없이 스택 포인터를 계속 옮겨 대서 미칠 지경이었습니다. [3]
FORTRAN과 COBOL은 Syntactic Structures가 나온 시기와 비슷하게 나왔기 때문에, 당연히 문법을 파싱하는 확립된 이론도, 파서 생성기도 없었습니다. 드래곤 북도 없었지만, 그 시절에 컴파일러를 개발하던 영웅적인 기법들은 완전히 잊히진 않았어도 전설이 되었습니다.
저는 고등학교 때 VAX에서 포트란 프로그램을 몇 개 짰고, 대학 비교 프로그래밍 언어 수업에서도 짰고, 1990년 대학원에서는 포트란 알고리즘을 많이 정적 할당 Java로 변환했고, 박사후 연구원 때는 LAPACK용 JNI 바인딩을 만들어 주는 생성기를 작성했습니다.
[1] ... 예를 들어 전형적인 구조체는 4096바이트 미만이죠
[2] FORTRAN 90 표준 이전에도 DEC FORTRAN에서는 /RECURSIVE 플래그를 줄 수 있었습니다
[3] Creative Computing에 실린 "BASIC보다 나은 프로그래밍 언어로 피보나치를 계산하면 얼마나 우아한지" 같은 기사들 때문에 우리는 큰 피해를 입었습니다. 재귀는 C의 메모리 관리처럼 대부분의 프로그래머가 제대로 감당하지 못하는 것 중 하나이기 때문입니다.