과학 워크플로에 함수형 언어를 심다: Rex가 던지는 질문

과학 데이터 처리나 대규모 파이프라인을 다뤄본 사람이라면, 워크플로 도구가 결국 어떤 길을 걷는지 익숙할 것이다. 처음에는 명령어를 순서대로 잇는 방향성 비순환 그래프(DAG)로 출발하지만, 시간이 지나면 조건 분기와 반복, 템플릿, 플러그인 모델이 하나씩 덧붙으며 어설픈 자체 표현식 언어로 자라난다. 결과적으로 설정 파일에 외부 템플릿 언어를 얹어야 겨우 유지되는 구조가 되곤 한다. Peter Kelly가 공개한 Rex(Rush Expressions)는 이 순서를 뒤집는다. 그래프에서 언어로 진화하는 대신, 처음부터 작은 범용 함수형 언어에서 시작해 워크플로를 그 위에 표현한다.

Rex는 정적 타입의 순수 함수형 언어로, Hindley–Milner 타입 추론, 대수적 데이터 타입(ADT), 레코드, 패턴 매칭, 파라메트릭 다형성, 타입 클래스, 고차 함수, 재귀, 모듈을 갖추고 있다. 분석 로직은 불변 값에 대한 순수 변환으로 기술하고, 계산 집약적인 실제 작업은 타입이 지정된 도구 모듈을 통해 외부 프로그램에 위임한다. 현재 main 브랜치는 v4를 향한 작업 중 버전으로 3.9.x로 매겨져 있으며, 워크플로 계층인 rex-workflow는 활발히 개발 중이다. 안정 버전의 코어 언어는 별도 저장소(talo/rex)에 있다.

순수성과 타입이 만드는 두 가지 이득

실제 파이프라인은 정적인 명령 나열로 끝나지 않는다. 코호트 전체에 분석을 매핑하고, 관측값을 그룹으로 묶고, 메타데이터에 따라 분기하고, 도메인 특유의 실패 정보를 보존하면서 여러 도구를 조합해 재사용 가능한 방법론으로 포장해야 한다. 이런 연산은 함수형 프로그램에서 자연스럽게 표현된다. Rex는 엄격 평가(strict evaluation)를 쓰지만 표현식과 함수는 순수하다. 언어 차원의 숨은 가변 상태에 의미가 좌우되지 않으므로, 평가기는 서로 독립적인 비동기 호출을 스레드나 퓨처, 락, async/await, 콜백 그래프를 사용자가 직접 관리하지 않아도 동시에 실행할 수 있다. 순차적 의존은 한 결과를 다음 입력으로 넘기는 방식으로 드러나고, 독립적인 작업은 소스 코드상에서도 독립적으로 남는다.

순수성은 리뷰 가능성도 높인다. 함수의 인자는 그것이 쓸 수 있는 데이터를, 반환 타입은 만들어낼 수 있는 것을 기술하며, ADT는 예상되는 모든 결과를 열거할 수 있다. 도구 모듈은 평범한 타입 값을 돌려주는 방식으로 이 모델을 유지하므로, 예상 가능한 잘못된 요청이나 도구 프로세스 실패는 워크플로 안에서 매칭해 처리할 수 있다. 반면 스토리지 장애나 실행기 오류 같은 인프라 문제는 평가 오류로 남겨, 도메인 실패와 런타임 자체의 실패를 명확히 구분한다. 도구 옵션도 정체불명의 맵이 아니라 레코드와 ADT로 표현되어, Image가 들어갈 자리에 Media가 실수로 끼어드는 식의 배선 오류를 컴파일러가 값비싼 외부 프로세스를 띄우기 전에 잡아낸다.

값으로서의 아티팩트, 그리고 좁은 도구 경계

rex-workflow는 모든 객체를 그 바이트의 BLAKE3 해시로 이름 붙이는 콘텐츠 주소 저장소(CAS)를 포함한다. 트리 항목은 종류·해시·크기를 기록하고 트리가 다른 트리를 담을 수 있어, 하나의 루트 해시가 완전한 불변 디렉터리 계층을 식별한다. 새 아티팩트를 만들어도 기존 것이 변하지 않고, 같은 내용으로 put하면 같은 값이 돌아온다. Git의 객체 모델처럼 변경 경로를 따라 새 트리를 만드는 방식이다. 다만 저자는 여기에 분명한 선을 긋는다. 해시는 바이트를 식별할 뿐, 그것을 만든 워크플로·파라미터·도구 버전·컨테이너를 기록하지 않으며, 입력이 불변이어도 외부 도구는 비결정적일 수 있다. 캐싱과 이력 추적은 이 명시적 경계 위에서 엄밀하게 구축해야 할 대상이지, 해시가 저절로 보장하는 마법이 아니다.

Rex는 워크플로 프로그램에 범용 셸 명령을 절대 노출하지 않는다. 대신 호스트가 지원 연산을 타입으로 기술한 모듈을 등록하고, 각 요청은 ToolExecutionPlan으로 컴파일된다. 워크플로는 실행 파일 경로나 컨테이너 이미지, 호스트 마운트, 작업 디렉터리, 임의의 Docker 옵션을 고를 수 없다. 새 연산을 추가하는 일은 Rust API 차원의 명시적 결정이지 셸 접근이 우발적으로 확장되는 것이 아니다. 이 폐쇄적 경계는 LLM이 생성했거나 신뢰할 수 없는 워크플로에 특히 유효하다. 정적 타입이 빠르고 신호가 강한 피드백을 주고, 순수 코드는 검토하기 쉬우며, 생성된 프로그램이 호스트에 요청할 수 있는 범위가 원천적으로 좁혀지기 때문이다.

격리는 배포 선택으로

같은 타입 도구 계획은 호스트가 고른 여러 백엔드에서 실행될 수 있고 워크플로 자체는 바뀌지 않는다. 로컬 실행기는 임시 작업 공간을 만들어 CAS 입력을 펼치고 호스트에 설치된 카탈로그 실행 파일을 돌린 뒤 출력을 다시 CAS로 가져온다. 개발 단계에는 편하지만 저자가 명확히 못박듯 이는 OS 샌드박스가 아니다. 프로세스는 여전히 호스트 사용자의 권한과 환경을 그대로 갖는다. 반면 Docker 실행기는 API를 동일하게 유지하면서 각 도구 호출을 새 컨테이너에 넣는다. 번들 이미지는 표면을 더 좁혀, FFmpeg API는 네트워크 소스·캡처 장치·하드웨어 가속을 노출하지 않고 ImageMagick은 네트워크와 간접 경로 코더 등을 비활성화한 심층 방어 정책을 적용한다. DockerToolImages는 다이제스트로 고정된 이미지 참조를 요구하며 실행기는 --pull=never로 동작해 워크플로 평가가 레지스트리에 접속하거나 이미지를 재빌드하는 부작용을 일으키지 않는다.

현 단계의 한계도 솔직하다. 저장소는 rex-tool-ffmpeg:local 같은 태그로 개발 이미지를 로컬에서 빌드하며, 게시된 멀티플랫폼 이미지와 릴리스 다이제스트 잠금은 아직 향후 과제다. 통제된 이미지 공급망이 필요한 프로덕션 사용자는 지금으로선 자신의 이미지를 직접 제공하고 고정해야 한다. 그럼에도 Rex의 설계 방향은 한국 실무자에게 시사점이 있다. 워크플로 언어는 무엇을 계산할지 기술하고, 바이트가 어디에 살지·어떤 도구 구현을 신뢰할지·어떻게 격리하고 어떤 운영 한계를 둘지는 호스트 정책으로 분리한다. rex-workflow가 라이브러리로도 제공되어 임베딩 애플리케이션이 자체 스토어와 실행기를 고르고, ToolExecutor 트레이트를 구현해 실행 계획을 다른 샌드박스나 워커 서비스로 라우팅할 수 있다는 점은, 도메인 과학 소프트웨어를 셸 명령이 아닌 통제된 하나의 능력으로 편입시키려는 조직에 실용적인 출발점이 될 수 있다.