ActivePapers Pharo 에디션

Konrad Hinsen 이 작성한 ActivePapers Pharo 에디션, 2019 년 5 월 10 일 게시 ActivePapers 패밀리에 새로운 멤버가 합류했습니다: 바로 ActivePaper Pharo 에디션 입니다. 대부분 동일한 아이디어와 개념을 두 가지 다른 플랫폼에서 구현하는 파이썬 및 JVM 에디션과 달리, Pharo 에디션은 차별화된 목표를 추구합니다. 바로 재현 가능하고 이해하기 쉬우며 검증 가능한 컴퓨터 지원 연구 (computer-aided research) 를 위한 인간 - 컴퓨터 인터페이스를 탐구하는 것입니다.

ActivePapers 파이썬 에디션과 관련해 가장 자주 받은 질문 중 하나는”이것이 Jupyter 노트북과 호환되나요?”였습니다. 처음에는”아직은 아니지만 작업 중입니다”라고 답했고, 실제로 작업을 진행했습니다. 그러나 그 노력은 만족스러운 결과로 이어지지 못했습니다. 한 가지 이유는 기술적 장애물이었습니다. ActivePaper 내부에 Jupyter 노트북을 포함시키려 시도했지만, 이는 불가능함이 드러났습니다. Jupyter 의 투 - 프로세스 설계 (커널과 노트북 편집기가 통신 프로토콜로 연결된 별개의 프로세스임) 가 HDF5 라이브러리의 제한 사항 (어떤 시점에서도 오직 하나의 프로세스만 파일에 쓸 수 있음) 과 호환되지 않았기 때문입니다. 즉, 노트북과 그곳에서 계산된 결과를 동일한 HDF5 파일에 저장할 수 없다는 뜻입니다.

그러나 ActivePapers 와 Jupyter 의 통합에 대해 깊이 고민할수록, 선형 노트북 (코드, 문서화, 결과 셀의 연속) 이 간단한 경우를 제외하면 과학적 계산을 문서화하는 작업에 실제로 적합하지 않다는 점을 깨달았습니다. 공개된 다양한 ActivePapers 를 살펴보면 invariably 여러 스크립트와 몇 개의 라이브러리 모듈로 구성되어 있습니다. 표면적으로는 노트북이 스크립트를 대체하여 문서화 기능을 제공할 수 있을 것처럼 보일 수 있습니다. 그러나 훌륭한 문서화는 일부가 아닌 전체를 문서화해야 합니다. 여러 스크립트와 라이브러리 모듈의 코드를 하나로 엮어야 합니다. 보통 계산 방법 (computational methods) 은 라이브러리 모듈에 구현되고, 스크립트는 이를 데이터셋에 적용합니다. 만약 문서화가 스크립트별로 이루어진다면, 방법론 자체는 어떻게 문서화하겠습니까?

오늘날 수많은 Jupyter 노트북이 공개되어 있는데, 그들은 이 문제를 어떻게 해결하고 있을까요? 물론 모두를 살펴본 것은 아니지만, 지금까지의 인상으로는 크게 두 가지 경우가 있습니다. 가장 흔한 경우는 잘 알려진 라이브러리에 구현된 표준적이고 익숙한 방법론에 기반한 데이터 분석을 문서화하는 노트북입니다. 이런 노트북의 독자들은 해당 방법론에 이미 익숙하거나 다른 곳에서 학습할 것이라고 가정합니다. 다른 경우는 전체 방법론 구현을 노트북에 포함시키는 경우입니다. 이는 단순한 방법론으로 제한될 뿐만 아니라, 방법론 구현을 재사용할 수 없다는 큰 단점이 있습니다.

저의 연구는 주로 새로운 계산 방법론을 개발하고 평가하는 데 초점을 맞추고 있으므로, 노트북이 제 작업에는 적합하지 않다는 결론에 도달했습니다. 사실 직접 시도해보면서 이미 같은 결론에 이르렀습니다. 새로운 프로젝트를 노트북으로 시작할 때마다 곧바로 기존 방식인 모듈과 스크립트로 전환했고, 문서화는 별도의 텍스트 파일로 작성했습니다. 개인적으로 사용하기에는 이 기법이 충분히 훌륭하다고 느꼈지만, 아무리 잘 정리된 파일 묶음이라도 다른 과학자 (심지어 공동 연구자라도) 가 기꺼이 파고들고 싶어 하는 형태는 아니었습니다.

몇 달 전 우연히 Pharo 를 접하게 되었습니다 (재현 가능 연구 MOOC 에서 강사 역할을 맡기 전에, 학습자의 관점에서 MOOC 경험을 쌓고자 Pharo MOOC 에 등록했었죠). 그곳에서 매우 다른 종류의 상호작용 컴퓨팅 환경을 발견했습니다. Pharo 는 비교적 최근 멤버인 Smalltalk 패밀리의 일원으로, 오랫동안 탐색 가능성 (explorability) 과 이해 가능성 (understandability) 을 중시해 온 역사를 지니고 있습니다 (자세한 내용은 이 블로그 포스트 를 참조하세요). 이어 빠르게 Glamorous Toolkit 을 발견했는데, 이는 Pharo 기반으로 구축된 새로운 상호작용 환경으로, 몰더블 개발 도구 (moldable development tools) 를 통해 한층 더 높은 수준의 탐색 가능성을 목표로 합니다. 핵심 아이디어는 개발자가 도메인 특화 검사 도구를 추가하여 환경을 확장할 수 있어야 한다는 점입니다. 이러한 아이디어의 지적 배경은 Rafael Luque 의 블로그 포스트 에서 잘 요약되어 있습니다.

관련 항목: DataCamp — 브라우저에서 직접 코딩하는 대화형 Python 및 데이터 과학 과정.

Pharo 생태계의 현재 및 미래 환경과 비교하면, 계산용 노트북은 매우 제한적이고 구속적으로 느껴집니다. 그 기원을 고려하면 놀랄 일도 아닙니다. 오늘날의 Jupyter 와 RMarkdown 은 1980 년대 초반 Mathematica 가 도입한 노트북 아이디어의 사소한 변형에 불과합니다. Mathematica 역시 대부분의 다른 컴퓨터 대수 시스템처럼 Lisp 의 유산을 바탕으로 했습니다. Lisp 는 1950 년대에 컴퓨팅에 많은 혁신적 기능을 도입했는데, 그중 하나가 Read-Eval-Print 루프 (REPL) 를 통한 상호작용이었습니다. 당시 사용자 인터페이스 하드웨어 (줄 단위 터미널) 의 제약 내에서 상호작용을 구현하는 자연스러운 방식이었죠. 반면 Smalltalk 는 1970 년대부터 그래픽 디스플레이와 포인팅 장치를 처음부터 채택했습니다. 다만 당시에는 극소수만이 접근할 수 있던 하드웨어에 의존해야 한다는 대가를 치렀습니다.

Marshall McLuhan 이 가르쳤듯, 우리가 먼저 도구를 형성하고 나면 도구가 우리를 형성합니다. 1950 년대의 줄 단위 터미널은 컴퓨터 사용자에게 특정 사고방식을 각인시켰으며, 이는 수십 년间 더 우수한 접근법이 존재했음에도 오늘날의 계산 노트북까지도 계승하고 있습니다. 그리고 그 우수한 기술은 단순히 니치 시스템으로 남아있는 Smalltalk 만이 아닙니다. 비선형 GUI 는 이미지나 사운드 파일을 다룰 때 우리 모두가 사용하는 방식입니다. 이러한 작업들은 줄 단위로 수행하기 거의 불가능하므로, GUI 가 등장하기 전에는 사실상 이루어지지 않았습니다. 계산 작업의 경우 GUI 는 아마도 너무 늦게 등장했을 것입니다. 선형적 사고가 이미 문화적 규범으로 자리 잡은 뒤였으니까요.

ActivePapers 의 Pharo 에디션은 GToolkit 환경을 소프트웨어 개발이 아닌 컴퓨터 지원 연구를 수행하는 환경으로 조성하는 것을 목표로 합니다. 이 두 활동은 구별되지만 많은 공통점을 공유합니다. 주요 차이점은 과학이 데이터와 모델에 집중하며, 소프트웨어는 단지 수단일 뿐이라는 점입니다. 그러나 그 수단이 너무나 중요하기에 다른 모든 것이 이를 중심으로 구조화됩니다. 게다가 소프트웨어 개발 역시 데이터 (소프트웨어에 관한) 와 모델 (명세서로서) 을 다룹니다. 결국 차이는 근본적이기보다 점진적입니다.

독자가 가장 좋아하는 것: Dataquest — 안내된 터미널 및 실제 데이터 세트를 갖춘 프로젝트 기반 데이터 과학 경로.

이 여정은 이제 막 시작되었으며, 어디로 이어질지 저도 정확히 알 수 없습니다. 향후 업데이트를 기대해 주세요! 그동안 이 데모 영상 을 시청해 보시기 바랍니다.

댓글 제공: Disqus