과학적으로 페타바이트 데이터를 분석하는 ROOT

 (root.cern)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 고에너지물리 같은 대규모 연구에서 필요한 대량 데이터 처리와 과학 분석을 지원하며, 현재 ROOT 파일에는 2엑사바이트가 넘는 데이터가 저장돼 있음
  • Higgs 발견에도 ROOT가 쓰여, 실험 데이터 분석에서 검증된 실제 활용 사례를 가진 도구임
  • 오픈소스로 자유롭게 사용·수정할 수 있고, 공개 개발 프로세스를 통해 사용자 기여를 받음
  • 함께 제공되는 C++ 인터프리터는 빠른 프로토타이핑에 적합하며, Python 동적 바인딩으로 모든 구성요소에 접근 가능함
  • Jupyter 노트북도 지원해 C++·Python 기반 분석을 노트북 환경으로 확장할 수 있고, 릴리스와 교육·해커톤 소식도 계속 공개되고 있음

ROOT의 데이터 분석 역할

  • ROOT는 대량 데이터의 처리와 과학적 분석을 가능하게 하는 도구임

오픈소스 개발과 기여

C++·Python·노트북 기반 사용 방식

블로그와 릴리스 소식

  • 최근 블로그 항목에는 C++ 다큐멘터리 YouTube 공개 초대, ROOT와 C++ 다큐멘터리 트레일러, ROOT Advanced Course 2026, 3rd ROOT Hackathon 관련 글이 있음
  • 최신 릴리스 목록에는 다음 버전이 포함돼 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 예전 생각이 남. 입자물리 쪽에서 일할 때 ROOT를 많이 썼고, 애증이 있었음
    한편으로는 기술 부채와 특이한 관성이 많았지만, 다른 한편으로는 matplotlib 같은 더 “현대적” 선택지보다 ROOT에서 쉬운 일이 꽤 있었음. 예를 들면 히스토그램, 필드가 있는 객체를 “열”에 담는 고도로 구조화된 데이터, x/y 배열을 따로 할당하지 않고 함수를 바로 그리는 작업 등임
    직관적인 객체지향 API도 좋았음. pandas/matplotlib의 메서드 체이닝, [] 문법 남용, 여러 마법 같은 동작보다 구식 C++나 Java에 가까운 느낌이었고, 우아하진 않고 장황하지만 과학 분석에서는 오히려 장점일 수 있음
    5년 전쯤 떠났을 때 ROOT는 변화 중이었고, 오래된 CINT 인터프리터를 걷어내고 clang 기반 코드베이스로 옮긴 상태였음. 지금은 C++나 Python으로 Jupyter에서 분석을 돌릴 수 있는 것으로 알고, 코드 품질도 많이 좋아졌다고 들음

    • ROOT의 가장 좋은 점은 데이터 적재 방식이었음. 디스크에서 열 기반으로 잘라 읽는 TTree는 정말 좋은 아이디어였고, 졸업 후 산업계로 옮긴 뒤에도 같은 방식으로 동작하는 걸 계속 찾고 있음
    • matplotlib은 히스토그램 중심이 아니라서 그런지, 요즘은 RAM이 충분해서인지, 서로 겹친 점이 너무 많아 쓸모없는 산점도를 자주 보게 됨. 보기 괴로움
    • 다들 ROOT와 애증 관계가 있음. 약간 스톡홀름 증후군 같기도 함
    • Haskell도 이런 걸 만드는 데 잘 맞을지 궁금함
    • 요즘은 ChatGPT 덕분에 matplotlib의 끔찍한 API가 예전만큼 큰 문제는 아님

  • 새 분석이 ROOT를 기본으로 써야 할 이유는 많지 않음. 더 사용자 친화적이고 제정신인 선택지인 uproot 같은 걸 쓰는 편이 나음
    레거시 워크플로가 있거나 실험별로 ROOT 위에 커스텀 패치를 많이 얹어둔 경우는 있겠지만, 물리 분석만 놓고 보면 스스로를 괴롭히는 선택일 수 있음
    404 페이지도 마음에 듦. 그리고 room 404 이야기는 아님
    https://github.com/scikit-hep/uproot5
    https://root.cern/404/

    • uproot에 대한 흔한 비판은 행별 계산이 복잡해질 때 유연하지 않다는 점임. Python의 for 루프가 너무 느리기 때문임
      이럴 때는 Numba를 쓰거나, 잘 동작할 때만 가능하지만, 아니면 부끄러운 홍보를 하자면 Julia를 쓸 수 있음: https://github.com/JuliaHEP/UnROOT.jl
      입자물리에서 Julia를 쓰는 것에 대한 과거 HN 논의: https://news.ycombinator.com/item?id=38512793

  • 과학적 발견에 쓰이는 대규모 소프트웨어 프로젝트를 보는 건 멋짐
    다른 예로, LIGO에서는 GStreamer로 중력파를 찾았음: https://lscsoft.docs.ligo.org/gstlal/

    • 여기서는 오히려 반대에 가까움. CERN에 데이터 분석 프레임워크가 필요해서 CERN이 개발·유지·공개한 것임
      다만 외부인이 실제로 쓰는 게 좋은 생각인지는 모르겠음. 내 경험은 좀 오래됐을 수 있지만 꽤 투박하고 낡았음. CERN이나 입자물리 작업에서의 큰 장점은 사실상 표준이라 내부 협업이 쉽다는 점임
    • 이 둘은 꽤 다른 예임. ROOT는 강력한 데이터 분석 프레임워크지만, 그 강력함에도 불구하고 충분히 범용적이고 쓰기 쉽게 만들지 못해 고에너지 물리학 밖으로 거의 나가지 못했음
      반면 GStreamer는 설계가 아름다운 플랫폼이고, 아키텍처가 좋아서 원래 만든 사람들이 상상하지 못했을 법한 전혀 다른 시나리오에도 쉽게 추상화해 재사용할 수 있음
    • 멋지지 않은 점은 ROOT가 대규모 소프트웨어 프로젝트를 운영하는 법을 전혀 모르는 사람들이 “설계”하고 만들었다는 것임
      그 흔적이 곳곳에 보임. 거대한 단일체라서 조금만 비정상적인 일을 하려 해도 계속 싸워야 함. 자주 쓰지 않아도 돼서 다행이지만, 아직 어느 정도는 접하고 있음
    • “중력파를 LIGO에서 GStreamer로 찾았다”고? 뭐라고?!

  • 개인적으로 ROOT는 너무 많은 걸 하려 하고, API 설계가 좋지 않으며, 무엇보다 라이브러리로서의 ROOT와 프로그램으로서의 ROOT가 분리되어 있지 않음
    전역 상태가 많고, 사람들이 ROOT 프로그램 방식으로 써야 한다는 가정이 깔려 있음. ROOT 6가 일부를 고치기 시작했지만 시간이 걸리고, 개인적으로는 llvm과 clang에 너무 깊이 기대면서 빌드 시간이 더 늘고 프로젝트로서 고치기 어려워졌다고 봄
    오랫동안 입출력 형식 문서도 빈약했고 구현도 하나뿐이었음
    지금은 groot, uproot, freehep, openscientist 등 덕분에 ROOT 전체를 끌고 오지 않고도 ROOT 데이터를 읽고 쓸 수 있음. 데이터에서 상호운용성은 매우 중요하다고 봄. 20년, 30년 뒤에도 그 유일한 데이터를 다시 읽을 수 있다는 희망을 가지려면 필수임
    https://go-hep.org/x/hep/groot
    go-hep의 주 개발자임

    • uproot은 아직도 TEfficiency 읽기를 제대로 구현하지 못한 것으로 아는데, 솔직히 아쉬움

  • 아, root… 매일 6 이전 버전을 쓰지 않아도 된다는 사실에 감사하게 됨

    • Root는 입자물리를 공부하지 않기로 한 이유 중 하나였음
    • 인터페이스를 깨더라도 드디어 root를 좋게 만들겠다는 버전 7을 아직도 기다리고 있음. 2016년쯤 처음 들었던 것 같은데, 진짜 증발한 약속 같음

  • 컴퓨터과학 배경은 없지만 뛰어난 물리학자들이 쓴 코드를 밤늦게 디버깅하던 기억이 떠오름

    • 2013년쯤 온라인 대출 웹사이트에서 일했는데, 리스크 예측 모델을 만들려고 입자물리학자들을 고용했었음
      그들은 모델링에 ROOT를 쓰고 Ruby로 인터페이스를 만들었는데, 소프트웨어 공학 관점에서는 괴물 같았음. 그래도 통계 관점에서는 꽤 괜찮았음
      Python 생태계가 뜨기 훨씬 전이었고, R의 머신러닝 패키지도 막 시작하던 시기였음
    • 2000줄짜리 main()이 상상됨

  • Root는 실험 입자물리에서 엄청난 작업의 중추인 건 맞지만, 새 대학원생에게는 악몽이기도 함
    입자물리에 사실상 깊게 박혀 있어서 가까운 시일 안에 바뀔 것 같지는 않음

    • 지금은 pyroot와 uproot이 있어서 새 대학원생도 배우기 쉬운 선택지가 생겼고, 그렇게 나쁘지만은 않음
      문제는 보통 실험 서비스의 일부로 유지보수해야 하는 레거시 코드에 있음

  • 내가 쓰는 Root 부분은 C++ 인터프리터인 Cling과 Jupyter 노트북의 Xeus임
    어느 날 밤 benchmarkgames의 가장 빠른 n-body를 Xeus와 Python 3로 비교해 봤음. 같은 Binder 인스턴스에서 Xeus는 15.58초였고, Python3 커널로 가장 빠른 Python 코드를 돌리니 5분이 걸렸음. 출력은 두 실행 모두 정확히 같았음
    이 프로그램에서 동적 C++ 실행 오버헤드를 약 300%로 잡아도 Cling은 매우 빠름. SIMD나 벡터화는 쓰지 않았고 benchmarkgames의 코드만 썼음. Cling은 주로 C++로 컴파일되는 언어를 위한 빠른 JIT 대체재로 씀

    • 내 네이티브 Clojure 방언의 JIT 컴파일에 Cling을 쓰고 있음: https://github.com/jank-lang/jank
      C++를 Clojure 세계로 가져오고, Clojure와 대화형 프로그래밍을 C++ 세계로 가져오려는 시도임

  • 소스 코드: https://github.com/root-project

  • “Eclipse IDE에서 CERN ROOT 스크립트와 ROOT 기반 프로그램 디버깅”이라니
    맙소사, 악몽이 떠오름. 끔찍한 환경에서도 비범한 것을 만들 수 있다는 점은 분명히 보여줌

    • Eclipse 얘기인 건지 잘 모르겠음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.