Deutsche Börse는 제네레이티브 AI 도구를 구축하여 Zeppelin 노트북을 Databricks로 대규모 마이그레이션하는 방법을 알아봅니다.

Deutsche Börse Group에서 저희 StatistiX 플랫폼은 그룹 전체의 모든 Clearing 및 Trading 데이터의 약 95%를 제공하며 수백 명의 비즈니스 사용자를 위한 셀프 서비스 분석을 지원합니다. 해당 데이터를 액세스 가능하고 실행 가능하게 유지하는 것이 저희가 하는 모든 일의 핵심입니다.

수년간 이는 HDFS 및 Oracle 데이터 시스템에 액세스할 수 있는 Cloudera에서 실행되는 Zeppelin 노트북을 의미했습니다. 이 플랫폼은 저희에게 잘 맞았지만 환경이 바뀌었습니다. Cloudera는 2027년에 Zeppelin을 완전히 폐기할 예정이며, 저희 분석 워크로드는 클라우드로 이동하고 있으며, Databricks가 저희의 새로운 통합 분석 플랫폼으로 선정되었습니다. 이 조합은 대부분의 조직이 과소평가하는 마이그레이션 과제를 야기했습니다. 즉, 2,000명 이상의 사용자와 많은 수의 노트북(많은 노트북이 일상적인 비즈니스 워크플로우에 깊숙이 통합되어 있음)을 모두 이동해야 했습니다.

모든 것을 수동으로 다시 작성하는 데는 수년이 걸릴 것입니다. 그래서 저희는 Databricks에서 더 나은 경로를 구축하기로 결정했습니다.

노트북 마이그레이션 문제

인프라 마이그레이션은 많은 주목을 받습니다. 노트북 마이그레이션은 그렇지 않은 경향이 있으며, 이것이 팀의 속도를 늦추는 큰 이유 중 하나입니다.

저희의 Zeppelin 노트북은 단순한 스크립트가 아니었습니다. 복잡한 SQL 및 Python 로직, 사용자 지정 인터프리터, Oracle 및 HDFS 참조, 시각화, 위젯 및 수년에 걸쳐 구축된 예약 로직을 포함하고 있었습니다. 각 노트북은 이를 사용하는 비즈니스 팀의 기관 지식을 반영했습니다. 전체 노트북 환경에 걸친 다양성 때문에 로직이 너무 이질적이고 비즈니스별로 자동화된 규칙으로는 안정적으로 처리할 수 없었기 때문에 규칙 기반 재작성 엔진은 비실용적이었습니다.

이 제약은 더 명확한 설계 통찰력으로 이어졌습니다. 즉, 구조와 로직을 분리하고 각 부분에 적합한 도구를 적용하는 것입니다. 구조적 변환(Zeppelin의 단락 형식을 Databricks 셀에 매핑, 인터프리터 구문 번역, 메타데이터 재서식 지정)은 결정론적이며 자동화 가능하지만, 로직 재구성은 그렇지 않습니다. 다행히 LLM은 이 구조적 변환 부분에 탁월합니다.

Databricks 앱에서 변환기 구축

이 설계 원칙을 바탕으로 저희는 마이그레이션 워크플로우를 위해 특별히 설계된 Databricks 앱인 Zeppelin to Databricks Notebook Converter를 구축했습니다.

이 앱은 변환의 구조적 측면을 처리합니다. Zeppelin 단락은 Databricks 셀이 되고, 인터프리터 매핑이 적용됩니다 (%python, %sql, %pyspark 등은 Databricks 해당 항목으로 번역됨). 노트북 메타데이터는 유효한 .ipynb JSON으로 재서식 지정됩니다. 원본 콘텐츠는 정확하게 유지됩니다. 이 단계에서는 로직을 재작성하는 것이 아니라 다음 단계를 위해 준비하는 것입니다.

다음 단계는 Genie입니다. 업로드된 각 노트북에 대해 앱은 Zeppelin 환경에 대한 특정 세부 정보(사용자 지정 인터프리터, 데이터 소스 및 구성 패턴 등)를 포함하는 컨텍스트 인식 프롬프트를 자동으로 생성합니다. 이 프롬프트는 Genie가 Databricks 네이티브 방식으로 로직을 정확하게 재구성하는 데 필요한 컨텍스트를 제공합니다.

비즈니스 사용자를 위한 워크플로우는 간단합니다.

1. Zeppelin 노트북을 JSON으로 내보냅니다.
2. Databricks 앱에 업로드합니다.
3. 변환을 클릭합니다.
4. 변환된 .ipynb를 다운로드합니다.
5. Databricks를 열고 노트북을 업로드하고 Genie를 실행한 다음 생성된 프롬프트를 붙여넣습니다.
6. Genie가 명확한 질문을 하고 노트북을 재구성합니다.

앱 자체는 shadcn UI 프런트엔드로 구축되었습니다. 원래 Streamlit 프로토타입을 구축했지만 shadcn이 더 전문적이고 확장 가능한 인터페이스를 제공한다고 생각했습니다. Databricks 앱 개발 경험을 통해 별도의 인프라를 구축하지 않고도 신속하게 출시할 수 있었습니다.

자동화하지 않기로 선택한 것

가장 중요한 설계 결정 중 하나는 도구가 의도적으로 그대로 두어야 할 것을 결정하는 것이었습니다.

변환기는 SQL 로직, Python 로직, 시각화, 위젯, Oracle 및 HDFS 참조, 예약 로직 또는 비즈니스별 사용자 지정 코드를 재작성하지 않습니다. 이 모든 콘텐츠는 변환된 노트북에 그대로 유지됩니다. 자동 재작성은 오류를 발생시키고 결과에 대한 신뢰를 손상시킬 수 있기 때문입니다. 이것들은 노트북마다 가장 많이 다르며 가장 비즈니스에 중요한 로직을 담고 있는 요소입니다. 규칙으로는 할 수 없는 컨텍스트를 해석하고 명확한 질문을 하고 판단을 내릴 수 있는 Genie의 몫입니다.

결정론적 부분을 자동화하고 가변적 부분을 위임하는 이 하이브리드 접근 방식을 통해 규칙 기반 시스템의 취약성을 피하고 AI가 실제로 성능을 발휘하는 곳에 활용할 수 있습니다.

결과: 몇 시간에서 몇 분으로

구조적 변환과 AI 지원 로직 재구성을 결합함으로써 노트북 재개발 시간을 수 시간의 수동 작업에서 노트북당 15~20분으로 단축했습니다(복잡성에 따라 다름). 여러 비즈니스 도메인에 걸친 이와 같은 대규모 마이그레이션의 경우, 이 접근 방식은 리소스 집약적이고 시간이 많이 소요되는 작업이 훨씬 적은 시간이 걸리는 확장 가능하고 반복 가능한 워크플로우로 전환합니다.

속도 향상은 작업의 성격도 바꿉니다. 비즈니스 사용자는 자신의 노트북을 마이그레이션하기 위해 깊은 Databricks 전문 지식이 필요하지 않습니다. 짧은 단계 시퀀스를 따르고 프롬프트를 받고 Genie가 재구성을 수행하도록 합니다. 이 도구는 마이그레이션에 전담 엔지니어링 팀이 필요하지 않을 정도로 접근하기 쉽습니다.

배운 점

이 프로젝트에서 나온 몇 가지 원칙은 유사한 노력에 적용할 수 있습니다.

• 과도한 엔지니어링을 피하십시오. 저희의 첫 번째 시도는 오버헤드를 추가하면서 핵심 문제를 해결하지 못한 더 복잡한 에이전트 아키텍처를 사용했습니다. 간단한 UI와 깔끔한 백엔드가 정확히 충분했습니다.
• 규칙 기반 재작성은 이질적인 콘텐츠에 대해 확장되지 않습니다. 저희 노트북 전반의 로직 다양성으로 인해 규칙이 비실용적이었습니다. LLM은 이러한 변동성을 처리하는 데 필수적이며, 자동화와 AI 간의 전환을 신중하게 설계하는 것이 핵심입니다.
• 컨텍스트는 좋은 프롬프트와 훌륭한 프롬프트의 차이입니다. 일반적인 Genie 프롬프트는 일반적인 결과를 생성합니다. 저희 특정 환경(인터프리터, 데이터 소스, 구성 패턴)에 대한 지식을 인코딩하는 프롬프트에 투자하는 것이 실제로 사용할 수 있는 결과를 만드는 것입니다.
• 플랫폼 팀을 조기에 참여시키십시오. 빌드 전반에 걸쳐 Databricks 팀과의 협업은 저희가 일관성을 유지하고 재작업을 피하는 데 도움이 되었습니다.

다음 단계

변환기 도구의 초기 개발은 완료되었지만, 현재 대규모 실제 테스트를 진행 중입니다. 저희의 즉각적인 우선 순위는 정확도를 개선하기 위한 프롬프트 정의를 마무리하고, 여러 비즈니스 엔티티 및 IT에 걸친 노트북으로 도구를 검증하고, 사용자 온보딩을 준비하는 것입니다.

더 넓은 의미가 저희를 가장 흥분시키는 부분입니다. 이 프로젝트는 AI 지원 마이그레이션이 미래의 기능이 아니라 현재 사용 가능하다는 것을 보여주었습니다! Databricks 앱과 생성형 AI를 결합함으로써 클라우드 변환의 가장 어려운 문제 중 하나를 빠르고 확장 가능한 프로세스로 전환하는 반복 가능한 워크플로우를 구축했습니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)