좋습니다. 오늘 시청해 주셔서 감사합니다. 물론 JMP에 대해 이야기하겠지만, 특히 Amirys에서 분석 워크플로 자동화에 JMP를 사용하는 방법을 자세히 살펴보겠습니다. 또한, JMP 기본 플랫폼을 사용하여 더 복잡한 프로세스와 일반화된 자동화 또는 데이터 자동화도 살펴보겠습니다. 본론으로 들어가기 전에 간단히 제 소개를 하겠습니다. 저는 Stefan입니다. Amirys에서 데이터 과학 부문 부소장으로 일하고 있으며, 생명 과학 업계에서 15년 동안 다양한 경험을 쌓았습니다. 화학 실험실, 발효 실험실, 고처리량 스크리닝 팀 등에서 근무했습니다. 품질 관리, 통계, 데이터 분석, 그리고 물론 데이터 과학 분야에서도 일했습니다. 데이터를 저장하는 방식부터 사람들이 데이터를 사용하고 접근하는 방식까지 모든 것을 좋아합니다. 현재 AMRA 과학 커뮤니티를 위해 자체 툴과 분석 방법론을 지원하고 있습니다. 오늘은 세 가지 주요 부분을 다루겠습니다. 자동화 사례들을 살펴보는 데 사용할 사례 연구에 대한 배경과 맥락을 간략하게 설명해 드리겠습니다. 아주 간단하게 시작해 보겠습니다.
JMP를 사용하여 실행 분석 워크플로를 자동화하는 방법은 무엇일까요? 이는 매일 수행하는 분석이며 효율성을 조금 더 높이고 싶을 수 있습니다. 마지막 부분에서는 보다 복잡한 워크플로를 살펴보는 고급 자동화에 대해 알아보겠습니다. 분석을 살펴볼 수도 있습니다. 더 광범위한 기술 팀에서 사용되는 이러한 워크플로를 어떻게 분석할까요? 데이터 처리 및 수집과 분석 부분을 모두 지원하도록 일반화하는 방법은 무엇일까요? 오늘의 사례 연구는 제가 근무하는 회사인 Amirys에 대한 것입니다. Amirys에 대한 배경 지식이 조금 있습니다. 저희는 합성 생물학 회사입니다. 효모 프로그래밍과 산업 발효를 전문으로 하며 효모 당을 공급하고 그 당을 순수한 성분이나 화학 물질로 전환합니다. 저희는 캘리포니아주 에머리빌에 본사를 두고 있으며 대부분의 제조를 브라질에서 수행합니다. 오늘의 사례 연구는 제조 측면이 아니라 연구 측면에 관한 것입니다. 에머리빌에는 '스크린 및 분석 랩'이라고 부르는 고도로 자동화된 랩이 여러 개 있는데, 여기서 우리는 매달 96개의 벽면 플레이트에서 수십만 개의 균주를 걸러냅니다.
플레이트의 바코드 사진을 보실 수 있습니다. 저희가 소규모 발효기에 사용하는 것입니다. 이 곳에서 이 균주들이 얼마나 생산하는지, 무엇을 생산하는지 확인하기 위한 첫 번째 테스트를 진행합니다. 저희는 이 균주들의 특정 표현형을 찾고 있습니다. 96웰 플레이트에서 배양한 후, 다양한 분석 기법을 사용하여 측정값을 생성합니다. 종종 플레이트 웰에서 다차원 측정값을 생성합니다. 또한, 저희는 많은 자체 데이터베이스를 보유하고 있으며, 관련 메타데이터와 함께 많은 데이터가 애플리케이션 데이터베이스와 데이터웨어하우스에 저장되어 JMP와 같은 도구를 사용하여 접근할 수 있습니다. 바로 여기서 JMP가 활용됩니다. 물론, 이 스크리닝의 마지막 단계는 많은 균주를 스크리닝하고 많은 데이터를 생성하는 것입니다. 이제 이 데이터를 이해하고, 어떤 균주를 반응기 발효 시설에 도입할지, 그리고 잠재적으로는 브라질에서 제조할지 결정해야 합니다.
JMP를 활용한 간단한 자동화부터 시작해 보겠습니다. 오늘 제가 드리고 싶은 것은 JMP 자동화를 한 번도 사용해 본 적이 없고, 해당 플랫폼을 사용해 본 적도 없는 분들을 위해, 비교적 코딩 없이 쉽게 이해할 수 있는 방식으로 이 플랫폼을 소개해 드리고, 이러한 플랫폼의 구축 방식과 제가 직접 배우고 다른 사람들에게서 자동화 플랫폼을 사용하며 배운 내용을 기본적으로 이해하실 수 있도록 도와드리는 것입니다.
10번 이상 반복하는 작업이라면 자동화하는 것이 좋다고 말하고 싶습니다. 자동화를 처음 접하는 분이라면 직접 분석하는 것이 가장 좋다고 생각합니다. 이러한 분석의 장점은, 이미 잘 알고 있거나 이미 잘 알고 있다면 스스로 피드백을 줄 수 있다는 것입니다. 물론, 대규모 팀을 대상으로 광범위한 분석을 시도하는 것보다 훨씬 간단합니다. 이 예시에서는 플레이트에 한 번 측정하는 매우 간단한 측정값을 살펴보겠습니다. 배양 전 단계부터 생산 단계까지 플레이트를 순차적으로 배포하는 방식입니다. 두 번째 플레이트에서는 한 번 측정합니다. 이 모의 실험에서는 "이렇게 똑같은 실험을 반복해서 실행하고 있습니다."라고 가정합니다. 이렇게 할 때마다 데이터를 JMP로 가져옵니다. 계산된 열을 추가합니다. 그런 다음 해당 열을 필터링하고, 의사 결정에 도움이 되는 시각적 및 통계적 테스트를 생성합니다. 한 번만 하면 시간이 많이 걸리지 않지만, 매일 반복적으로 하면 시간이 쌓이기 시작합니다.
자동화 부분으로 넘어가기 전에, 구조화된 데이터에 대해 간략하게 언급하고 싶은데, 이는 자동화의 필수 조건입니다. 이러한 표준화 및 구조화의 상당 부분이 업스트림, 즉 데이터를 수집하여 데이터베이스나 CSV 파일로 처리하는 단계에서 이루어진다면 훨씬 수월해질 것입니다. 저희의 경우, 데이터베이스는 이미 구조화된 상태로 제공됩니다. 물론 JMP에서도 이러한 데이터 수집을 많이 할 수 있으며, 종종 애플리케이션이나 수행하려는 분석에 따라 달라질 수 있습니다. 하지만 데이터의 출처가 무엇인지 생각해 보세요. 업스트림에서 더 자세히 다룰수록 더 좋습니다. 데이터베이스 데이터를 사용하는 경우 쿼리 빌더를 사용하는 것이 좋습니다. 오늘은 그 이상 자세히 다루지는 않겠습니다. 이것이 제가 일반적으로 권장하는 방식입니다. JMP 스크립팅의 기본이자 토대는 로그입니다. 알든 모르든, JMP는 기본적으로 UI를 클릭하는 것만으로 작업 내용, JSL, 실행 중인 스크립트 등을 항상 기록합니다. 보기 메뉴에서 로그를 클릭하면 로그가 표시되고, 수행한 대부분의 단계가 기록된 것을 확인할 수 있습니다.
어느 한 단계를 클릭하면 해당 단계를 실행하는 데 사용된 JSL이 표시됩니다. 이 예에서는 계산된 열을 추가하는 첫 번째 단계를 수행하고 있으며, 해당 열을 클릭하고 거기에서 JSL을 강조 표시했습니다. 이는 단계에서 실행되는 JSL을 노출하는 빠른 첫 번째 방법이며, 로그에서 해당 코드를 직접 실행하거나 이전 코드를 다시 실행할 수 있습니다. 즉, 로그는 실제로 자동화를 시도하는 곳이 아닙니다. 이 코드의 출처가 많을 뿐입니다. 로그에서 데이터를 꺼내 데이터 테이블로 가져오는 한 가지 방법은 데이터 테이블 스크립트를 사용하는 것입니다. 이것은 오랫동안 JMP에서 단계별 자동화를 만드는 방법이었습니다. 이 예에서, 저는 이 데이터 테이블로 가서 작은 빨간색 핫스팟을 클릭하고, 새로운 스크립트를 생성했습니다. 그러면 빈 창이 나타나고, 로그에서 직접 두 단계의 코드를 붙여넣습니다. 첫 번째는 새로운 열을 만드는 것이고, 두 번째는 해당 열에 대한 수식을 설정하는 것입니다.
더 나아가 코드를 정리할 수도 있습니다. 완전히 선택 사항입니다. 하지만 이후 섹션에서 더 복잡한 예제에 대해 이야기하기 시작할 때 코드를 가장 유지 관리하기 쉽거나 가장 깔끔하게 만들려면 어떻게 해야 할까 고민할 수 있습니다. 이 경우 두 단계 정리를 수행했습니다. 첫 번째 단계에서 중복된 데이터 테이블 참조를 제거했습니다. 두 번째 단계에서는 열 이름을 바꾸지 않고 열 21로 다시 이름을 바꾸어 더욱 압축했습니다. 처음부터 올바른 이름을 지정했습니다. 각 상자는 작동합니다. 정확히 같은 작업을 수행합니다. 이 경우 성능 차이를 알아차리지 못하지만 더 깔끔하고 유지 관리하기 쉬운 코드로 이어질 수 있습니다. JSL을 처음 사용하고 이 코드를 보면 이게 무슨 기능인지 알 수 있습니다. 이러한 내용을 좋아하는 LLM에 붙여넣을 수 있습니다. Copilot, ChatGPT 등을 사용합니다. JMP 학습 봇이 있다면, 그걸 사용해서 "이 코드는 무슨 일을 하는 거지?"라고 물어보세요. 그러면 일반적으로 코드가 무슨 일을 하는지에 대한 좋은 아이디어를 얻을 수 있습니다.
로그에서 데이터를 가져오거나, 아니면 데이터를 가져오지 않고, 로그에서 코드를 가져와 데이터 테이블 스크립트에 붙여넣었습니다. 이것이 JSL을 자동으로 생성하는 가장 수동적인 방법입니다. 여기에서 확인할 수 있습니다. 1단계에서 계산된 열을 추가하는 것과 같은 이름을 붙였습니다. 대부분의 플랫폼에서 이러한 테이블 스크립트를 생성하고 특정 출력을 생성한 스크립트를 저장하는 간단한 방법이 더 많습니다. 많은 플랫폼에서 빨간색 핫스팟 아래에 이러한 옵션이 있습니다. 빨간색 핫스팟 아래에서 맨 아래를 볼 수 있습니다. 여러 옵션을 제공하는 스크립트 저장 옵션이 있습니다. 클립보드에 저장하거나 데이터 테이블에 직접 저장할 수도 있는데, 우리가 할 일은 다른 옵션과 함께 하는 것입니다. 이렇게 하면 UI에서 바로 JSL을 자동으로 생성하는 매우 쉬운 방법이 됩니다. 데이터 테이블에 저장했습니다. 이 경우에는 스크립트의 이름을 바꾸고 2단계에서 데이터 필터를 지정한 다음 분석을 진행했습니다. 마지막 단계에서는 Y x X 플롯을 생성하고 참조 그룹에 Dunnett 테스트를 적용하여 이 작업을 수행할 수 있습니다.
다시, 여기서 우리는 빨간색 핫스팟으로 가서 스크립트 저장으로 가서 그것을 데이터 테이블에 저장합니다.우리가 만든 것은 이 의사 워크플로입니다.이 3단계 자동화가 있습니다.이 테이블에 계산된 열을 추가하고, 데이터 필터를 추가하거나 데이터 필터를 적용한 다음 Dunnett의 테스트를 사용하여 단방향 분석을 수행합니다.이것은 테이블 스크립트를 사용하는 공간으로 이어지고, JMP 16이나 17까지 오랫동안 이 워크플로가 등장했습니다.그때쯤 워크플로가 등장했습니다.이 워크플로는 실제로 추가 기능으로 이러한 테이블 스크립트를 레벨업할 수 있는 곳으로 이어졌습니다.워크플로는 새로운 플랫폼입니다.JMP의 독립형 플랫폼입니다.파일, 새로 만들기, 워크플로로 이동하여 액세스할 수 있습니다.이러한 워크플로의 개발 용이성뿐만 아니라 이러한 워크플로를 사용하는 최종 사용자 경험을 증폭시킬 수 있는 여러 기능이 있습니다.예를 들어, 워크플로의 모든 단계를 실행하는 단일 버튼이 있습니다. JMP에서 진행 중인 작업을 기록하고 워크플로에 자동으로 추가하는 단계 기록 기능이 있습니다. 워크플로에서 스크립트에 직접 주석을 달 수 있고, 논리 게이트, 상호작용, 사용자 프롬프트 등 다양한 기능을 추가할 수 있습니다. 오늘 시간이 부족하여 모두 다루지는 않겠지만요.
하지만 특히 고급 버전에서 몇 가지 예를 보여드리겠습니다. 이제 테이블 스크립트를 사용하여 가상 워크플로를 만들 수 있습니다. 워크플로가 존재하기 전에 이것을 만들었고, JMP에서 워크플로 플랫폼을 추가했으며, 이제 워크플로 빌더에 추가했다고 상상해 보세요. 여기서는 세 단계만 추가했습니다. 각 단계의 JSL을 붙여넣었고, 데이터 테이블 스크립트에서와 마찬가지로 워크플로에도 정확히 세 단계가 있는 것을 볼 수 있습니다. 실제 데이터 또는 데모 데이터에서 이러한 세 단계가 어떻게 보이는지 간략하게 보여드리겠습니다. 첫 번째 예에서는 구조화된 데이터가 있습니다. 여러 측정값이 있습니다. 이러한 측정값이 있습니다. 다시 한 번 이 세 단계를 수행하려고 합니다. 이 데이터 테이블 스크립트 방식에서는 하나씩 누르기만 하면 됩니다. 저는 그것을 누릅니다. 이제 계산된 열을 추가했습니다. 데이터 필터를 적용하면 팝업 창이 나타나고 이 필터가 적용됩니다. 그런 다음 이 특정 실험에 대한 단방향 분석을 생성합니다.
정말 간단하죠? 잘 작동합니다. 이런 간단한 작업에 아주 적합합니다. 워크플로로 이동해야 하나요? 좀 더 정교한 작업이 필요하나요? 꼭 그럴 필요는 없습니다. 작동한다면 다행입니다. 재설정할 수도 있는데, 여기서 수동으로 해야 한다는 것을 알 수 있을 겁니다. 행 상태를 지우고 데이터 필터가 닫혔는지 확인한 다음 워크플로를 살펴볼 것입니다. 이것도 세 단계입니다. 여기서 더 좋은 점은 이제 코드를 자동으로 볼 수 있다는 것입니다. 여기서는 그렇게 할 수 없습니다. 여기서는 마우스 오른쪽 버튼을 클릭하고 편집으로 가서 새 창에서 정의를 실제로 확인해야 합니다. 반면에 이 다른 옵션에서는 각 단계의 코드를 볼 수 있습니다. 여기서는 재생을 누르면 세 단계가 모두 함께 진행됩니다. 오류 없이 실행되었다는 것을 알려주는 작고 예쁜 녹색 확인 표시가 있습니다. 새 열이 있는 것을 볼 수 있습니다. 필터를 적용했고 동일한 분석이 열렸습니다. 좀 더 깔끔해졌습니다. 다음 섹션에서는 워크플로를 사용하여 얻을 수 있는 다른 편리한 기능에 대해 좀 더 자세히 살펴보겠습니다.
데모에서 아주 간략하게 언급하고 싶은 것은 기록 버튼입니다. 특히 JSL에 익숙하지 않더라도 코딩에 전혀 익숙하지 않더라도 자동화를 직접 만드는 가장 쉬운 방법입니다. 여기서 할 수 있는 일은 기록을 누르는 것뿐이며, 이제 이 플랫폼에서 하는 모든 일이 해당 워크플로에 캡처됩니다. 더미 예제를 만들어 보겠습니다. 여기에 분포를 생성하는 측정값의 분포를 그리겠습니다. 이것이 정말 의미 있는 것을 의미한다고 가정하겠습니다. 워크플로로 돌아가면 이제 여기에 새 단계가 있는 것을 볼 수 있습니다. 여기에 JSL 스크립트가 있습니다. 이름을 바꾸고, 메모를 추가하고, 수정하는 등의 작업을 할 수 있습니다. 워크플로 빌더의 정말 좋은 기능 중 하나는 이 기록 버튼입니다. 한 단계 더 발전시켜 볼까요? 소파나 매우 특정한 애플리케이션을 위해 무언가를 자동화했을 수도 있습니다. 하나의 실험 유형에만 효과가 있을 수도 있습니다. 이를 어떻게 더 복잡한 프로세스에 적용할 수 있을까요? 이것이 바로 우리가 가진 질문이었습니다.
Amirys에서는 다양한 실험 유형이 매우 다양하고, 가능한 한 적은 워크플로우로 이러한 유형을 지원할 수 있기를 바랍니다. 모든 반복 작업마다 고유한 워크플로우를 만들고 싶지는 않습니다. 유지 관리가 불가능하고 개발이 매우 어려워지기 때문입니다. 고급 개발 단계로 진입할 때 제가 제안하고 싶은 한 가지는 JMP 커뮤니티의 어딘가에서 본 영상인데, JMP 프로젝트를 사용하여 개발 환경이라고 부르는 것을 구성하는 것입니다. 이러한 복잡한 작업을 자동화할 때 겪는 어려움 중 하나는 데이터 테이블, 창, 팝업 창 등 온갖 것들이 생겨나 관리하기 어렵다는 것입니다. Project를 사용하면 개발 작업의 래퍼로 사용할 수 있습니다. 또한 해당 도구를 최종적으로 사용할 때도 마찬가지입니다.
여기에 Workspace와 Contents 같은 기본 프로젝트 플랫폼 몇 개가 열려 있습니다. 플레이스홀더로 저널을 추가했습니다. 워크플로에서 열리는 모든 새 창은 데스크톱의 새 창이 아닌 새 탭으로 열립니다. 물론 이 저널을 문서나 지침으로 사용할 수도 있습니다. 오른쪽에는 제가 직접 만든 실제 워크플로가 있고, 아래쪽에는 로그도 추가했습니다.
문제 해결이 필요하거나 오류 메시지에 대한 자세한 내용을 확인해야 할 때, 바로 로그가 표시되어 있어 하나의 창에서 모든 작업을 직접 수행할 수 있습니다. 이 프로젝트 내에서 이 워크플로를 시연하는 방식도 이와 같습니다. 제가 받은 일반 사용자 피드백은 표와 시각적 자료가 너무 많아지지 않았다는 점이 매우 긍정적이었습니다. 자동화 일반화에 대해 이야기할 때는, 데이터 자동화든 물리적 자동화든, 실험실이나 제조 현장에서 자동화를 일반화하는 것은 쉬운 일이 아니기 때문에 영향력이 큰 애플리케이션을 목표로 합니다. 많은 노력과 비용, 그리고 시간이 필요합니다. 일반적으로 데이터 워크플로를 자동화하려면 워크플로를 표준화하거나 표준화를 추진하는 수단으로 활용하는 것을 우선시하세요. "이걸 표준화하면 매일 하는 정말 힘든 데이터 처리 작업도 자동화할 수 있습니다."라고 말할 수 있습니다.
데이터 워크플로는 프로세스 자체 때문이든, 사람들이 데이터를 보는 방식 때문이든 어느 정도 유연성이 필요한 경우가 많습니다. 바로 이런 부분에서 단계별로 자동화를 구현할 수 있습니다. JMP의 가장 큰 장점은 바로 이 부분입니다. 자동화를 한다면 왜 Python을 사용하지 않느냐는 질문을 많이 받았기 때문입니다. 순수 코드 기반 플랫폼을 사용해서 자동화를 구현하는 것도 좋은 방법입니다. 문제는 순수 코드 기반 플랫폼을 만들면 사람들에게 큰 진입 장벽이 생긴다는 것입니다. 처음부터 끝까지 자동화할 수 없다면, 어느 정도 수준에 도달했을 때 사용자가 직접 처리해야 하고, "Python에 능숙해야 합니다"라고 말해야 한다면, 제가 함께 일하는 과학자들처럼 매우 기술적인 커뮤니티에서도 진입 장벽이 커집니다.
JMP는 첫 번째 부분만 자동화할 수 있어서 정말 좋습니다. 최종 사용자는 JMP에 접속한 상태입니다. UI가 있고, 그 UI를 그대로 사용할 수 있습니다. 원하는 작업을 자유롭게 수행할 수 있고, 자동화를 활용할 수 있습니다. 물론, 노력이 필요하기 때문에 큰 효과를 낼 수 있는 기회를 찾고 싶습니다. 저희의 경우, 플레이트 실험을 검토하면서 과학자들에게 "이 데이터를 가져오는 데 얼마나 많은 시간을 쓰고 계신가요?"라고 물었습니다. 사람들이 이 작업을 매우 수동으로, 복사-붙여넣기 식으로 반복적인 작업을 하고 있다는 것을 알게 되었습니다.
우리 팀에는 과학자가 17명 있었습니다. 간단한 설문조사를 해보니 이 모든 작업에 한 사람의 시간, 꽤 비싼 인력이 투입되고 있다고 추산했습니다. "이런 작업들은 대부분 수작업이고 반복적이며 자동화가 가능해 보이는데요."라고 말할 수 있는 기회였습니다. 한번 시도해 볼까요? 여러분이 마주하게 될 가장 큰 과제는 복잡성입니다. 자동화에 대해 생각해 보면 두 가지 축이 있습니다. 하나는 워크플로의 총 단계 수이고, 다른 하나는 각 단계의 변형 수입니다. 변형은 사실상 경로의 갈림길과 같습니다. 오른쪽 다이어그램이 마음에 드는 이유는 특정 프로세스의 반복이나 변형이 너무 많아 해결해야 할 문제가 기하급수적으로 커질 수 있기 때문입니다. 실제로 작업을 진행하면서 스스로에게 질문해야 합니다. "관리 가능한가?", "관리 불가능한 경우, 어떻게 하면 관리 가능하게 만들 수 있을까?" 앞서 언급했듯이 표준화를 통해 변동을 제거할 수도 있고, "이런 예외 상황은 이 데이터 분석으로는 뒷받침되지 않을 거야"라고 말할 수도 있습니다.
워크플로에서 확인할 수 있듯이 오류 메시지를 추가할 수도 있습니다. 자동화 오프 램프를 통해 단계를 제거할 수도 있습니다. 제가 말씀드린 것은 바로 사용자가 직접 처리하도록 하는 것입니다. 매우 정교하고 고유한 품질 관리 단계가 있는 경우 워크플로를 일시 중지하고 사용자가 필요한 작업을 수행하도록 한 다음, 해당 단계에서 워크플로를 재개할 수 있습니다. 여러 가지 방법을 생각해 볼 수 있지만, 자동화를 고려할 때는 계획이 확실히 유리합니다. 저희의 경우, 이러한 플레이트 프로세스를 살펴보았고, 이것이 제가 처음에 제시했던 예시입니다. 단일 플레이트 전파가 있는 경우, 단일 측정을 수행하고 이 프로세스를 매우 전파적인 프로세스라고 부릅니다.
이것이 실험마다 어떻게 다른지 폭넓게 살펴보기 시작했을 때, "사실, 때로는 이 플레이트에서 한 번만 측정하는 것이 아니라 두 번 측정하기도 한다"는 것을 알게 되었습니다. 때로는 직렬 전파의 첫 번째 플레이트에서도 측정을 합니다. 때로는 두 플레이트 모두에서 두 번 측정하기도 합니다. 때로는 플레이트를 실제로 분리하기도 합니다. 단순히 일대일로 연결하는 것이 아니라, 일대일로 연결하거나 일대다로 연결하는 것입니다.
저희는 그 측정들을 하고 있습니다. 때로는 두 측정을 나누어서 실제로 두 측정 모두 다르게 수행하기도 합니다. 여러분이 이 과정을 모두 기록해 주실 거라고 기대하지는 않지만, 제가 보여드리고자 하는 것은 저희 프로세스가 상당히 분산되어 있다는 것입니다. 몇 가지 예를 보여드리는 것뿐입니다. 저희 프로세스에는 수십 가지의 다양한 변형이 있습니다. 저희는 프로세스 자체의 복잡성, 즉 저희 연구실에서 데이터를 생성하는 프로세스 자체를 살펴보고 있었습니다. 사람들이 데이터를 보고 분석하는 방식이 얼마나 표준적인지, 어떤 통계적 검정을 사용하는지, 요약 지표를 사용하는지, 아니면 중앙값이나 평균을 사용하는지에 대해서는 전혀 생각하지 못했습니다.
복잡성은 순식간에 엄청나게 커질 수 있지만, 사전에 충분한 정보를 조사하는 것이 중요합니다. 저희가 작업해 온 것은 현재 진행 중인 작업입니다. 배포는 되었지만, 지속적으로 개선하고 있습니다. 제가 추천하는 또 다른 점은 최소한으로 유용한 것이 무엇인지 파악하고, 최종 사용자로부터 자주 피드백을 받는 것입니다. 저희는 평면 분석을 위해 이러한 일반화된 접근 방식을 고안했습니다.
더 복잡한 워크플로는 다음과 같습니다. 실제로 데이터베이스에서 데이터를 직접 조정하여 사용자가 원하는 특정 실험에 따라 해당 데이터를 필터링하도록 합니다. 데이터 유형을 수정하고, 명명 규칙을 지정하고, 일관성을 유지하는 등 다양한 데이터 정리 작업을 수행합니다. 이 프로세스를 기반으로 데이터를 분할합니다. 직렬 전파를 확인했습니다. 어떤 측정값이 어떤 플레이트와 연관되어 있는지 파악해야 합니다. 몇 가지 검사를 수행하여 이 프로세스가 지원하지 않는 것은 아닌지, 이 자동화에서 지원하지 않는 측정값은 아닌지 확인합니다. 오류를 발생시키고 사용자에게 메시지를 표시합니다. 피벗팅을 중심으로 더 많은 데이터 정리를 수행합니다. 심지어 오프라인 데이터를 추가하는 옵션도 제공합니다. 사용자는 자신의 유전형에 대한 수동 주석을 가질 수 있습니다. 마지막으로 기본 시각화 및 분석 세트를 생성합니다.
이 부분에 대해 더 자세히 설명하면, 어떤 모습인지 보여드리겠습니다. 지금 보여드린 것처럼, 프로젝트가 진행 중입니다. 작업 공간 콘텐츠, 저널, 로그가 여기에 있습니다. 데모에 필요하지 않고 화면에서 귀중한 공간을 차지하고 있으므로 로그를 닫겠습니다.
하지만 여기에는 워크플로가 있습니다. 각 단계의 기능을 이해할 수 있도록 최대한 사람이 읽기 쉽게 단계를 구성했습니다. 이 경우, 이 컨퍼런스의 목적에 맞게 단계를 활성화하거나 비활성화할 수 있다는 것도 알 수 있습니다. 회사 데이터베이스에 연결하여 실제 실험 데이터를 가져오지 않기 때문에 정적 데이터만 가져오는 것입니다. 기본적으로 원시 데이터가 여기에 있습니다. 또한 여기에 몇 가지 논리 게이트가 있는 것을 보실 수 있습니다. if/out 문을 사용하면 논리 스위치나 다른 경로, 행의 다른 포크를 사용하여 데이터가 다음과 같으면 이렇게 하고, 그렇지 않으면 이렇게 할 수 있습니다.
실행해 보겠습니다. 데이터를 가져오고 있습니다. 약간 수동적인 표현이 섞인 듯한 문구가 있는데, 그냥... 사용자에게 피드백을 줄 수 있는 작은 팝업을 만들 수 있습니다. "좋아요."라고 말했습니다. PC 플레이트에는 B 측정값만 있는 거죠? 그게 우리가 허용하는 유일한 값입니다. 잘 하셨습니다. 확인을 누르니 계속 실행됩니다. 이제 프롬프트를 표시합니다. "수동으로 만든 메타데이터를 결합하시겠습니까?"라는 메시지입니다.
이 데이터 세트에는 일반적으로 유전형 데이터가 있습니다. 처음 실행할 때는 '아니요'를 누릅니다. 사실, 데이터가 없습니다. '좋아요, 그냥 실행해 볼게요.'라고 말하는 것과 같습니다. 이제 생성도 완료되었고, 모든 것을 실행했습니다. 모든 항목에 녹색 체크 표시가 있습니다. 왼쪽에는 여러 데이터 표와 기본 성능 시각화, 그리고 균주 선택을 위해 플레이트에 적용한 정규화가 표시됩니다.
여기서 정말 멋진 점은, 워크플로에서 이 버튼을 누르면, "재설정"이라는 기능이 있는데, 이 버튼을 누르면 워크플로에서 열었던 모든 항목이 닫히고 처음으로 돌아갑니다. 이제 재설정이 완료되었습니다. 저널과 처음에 있던 작은 화살표로 돌아간 것을 알 수 있습니다. 이제 다시 실행할 수 있습니다. 같은 프롬프트에서 "예"라고 대답하겠습니다. 그러면 약간 다른 경로로 이동하게 됩니다. "예, 수동 데이터를 추가하겠습니다"라고 대답하겠습니다. 이제 데이터를 조인하는 데 어떤 열을 사용할지 묻는 또 다른 프롬프트가 나타납니다. 고유 식별자인 X 번호를 사용하겠습니다.
네 가지 균주를 사용합니다. 확인을 클릭합니다. 그러면 "데이터 세트에서 이 데이터를 찾을 수 없습니다."라는 메시지가 표시됩니다. 물론, 제 오프라인 데이터이기 때문에 표시되지 않습니다. 제 컴퓨터로 가서 데이터가 어디에 있는지 찾아보겠습니다. 이 경우에는 CSV 파일로 저장해 두었고, 이를 결합해서 해당 스크립트를 실행합니다. 이 시점에서 실제로 동일한 결과를 얻는 것을 알 수 있습니다. 정규화도 있고, 측정값에 대한 그래프 빌더 상자 그림 시각화도 있습니다. 하지만 이제 몇 가지 추가적인... 열, 프로모터 돌연변이, 그리고 오프라인 데이터에 있던 다른 정보를 기본 데이터에 결합했습니다.
이러한 일반화된 워크플로는 매우 강력해질 수 있습니다. 이를 게시할 때 프로젝트에도 저장합니다. 이는 프로젝트의 워크플로입니다. 여기에 사용자 설명서와 관련성이 있을 수 있는 다른 내부 문서로의 하이퍼링크를 추가합니다. 사용자가 여기에 접속하여 재생 버튼을 누르고, 실험 ID를 입력하면, 가져온 데이터가 동적으로 변경되고, 이를 통해 실행됩니다.
여기서 제가 오류 발생과 같은 몇 가지 기능을 추가했다는 것을 알 수 있을 겁니다. 이는 저희가 지원하지 않는 특정 사례나 예상치 못한 실험 유형에서 발생하는 오류입니다. 또 다른 팁은, 일반화를 고려하고 있다면 기본적으로 자동 생성된 많은 테이블 및 열 참조를 고려해야 한다는 것입니다. 레코드 버튼을 사용하든, 플랫폼의 빨간색 드롭다운을 사용하든, 이러한 참조는 일반적으로 명시적입니다. 데이터 테이블의 이름, 열의 이름이라고 표시될 것입니다. 하지만 일반화할 때 이러한 참조가 항상 확장되는 것은 아닙니다.
JSL을 직접 수정하고 배우게 될 수 있는 부분 중 하나는 열 및 데이터 테이블 참조, 이를 관리하는 방법, 그리고 이를 동적으로 만드는 방법입니다. 가져오는 열의 개수는 사용자가 가져오는 내용에 따라 달라질 수 있으며, 저는 이를 지원해야 합니다. 이 영역에 익숙해지면 거의 확실히 JSL을 작성하고 JSL 코드를 작성해야 할 것입니다. 하지만 JMP가 워크플로 기록, 로그, 그리고 모든 위험 요소 및 스크립트 저장 옵션 등 대부분의 작업의 90%를 대신 처리해 줄 것입니다.
JSL을 작성해야 할 때가 있는데, 어디로 가야 할까요? 저는 다양한 데이터 도구, 데이터 소프트웨어, 코딩 언어를 사용해 봤습니다. JMP 학습 자료는 정말 훌륭합니다. 기본적으로 애플리케이션 자체에 스크립팅 인덱스가 있습니다. 요즘에는 LLM 지원을 통해 JSL 문제 해결이나 생성까지 할 수 있습니다. Python 같은 언어만큼 좋지는 않다고 생각합니다. 부분적으로는 학습 데이터 세트가 Python보다 훨씬 작기 때문이지만, 그래도 도움이 될 수 있습니다.
JMP 커뮤니티는 정말 최고의 플랫폼입니다. 포럼을 활용하세요. 올해 초에 있었던 구체적인 사례를 하나 소개합니다. 제가 이 질문을 작성했는데, 제가 가장 중요하게 생각하는 건 바로 시간입니다. 오후 7시 15분에 질문을 올렸는데, 전설적인 짐이 같은 날 오후 9시 45분에 답변을 해줬습니다. 다음 날 아침, 마크가 약 12시간 만에 답변을 해줬습니다. 제 질문에 대해 두 명의 전문가가 24시간도 안 되어 답변을 해줬습니다. 제가 포럼에 글을 올릴 때마다 항상 경험했던 경험입니다.
모두에게, 특히 Mark와 Jim에게 감사드립니다. 여러분의 이름은 항상 보지만, 포럼에 있는 모든 사람들이 그 이름들을 사용하고 있습니다. 여러분의 배움에 매우 귀중합니다. 이것으로 마무리하며, 여러분의 조직, 팀, 연구실, 그리고 어떤 업무를 하든 일반화된 자동화를 적용할 수 있는 효과적인 기회를 찾아보시기를 권합니다. 저희의 경우, 한 달 동안 50개 이상의 실험을 수행하는 데 실험당 몇 시간을 소비하는 분야를 발견했습니다. 한 사람이 그 데이터를 처리하는 데 소비한 시간은 고작 1시간에 불과했습니다.
일단 그 목표를 달성하고 복잡성을 관리하고 계획하면 실험 설계와 플레이트 스크리닝 프로세스에 많은 변동성이 발생합니다. 사용자 옵션을 제공하고, 지원하는 보고 기능을 제한하는 동시에 JMP UI를 활용하여 "여기부터는 여러분의 선택입니다"라고 말함으로써 이 문제를 해결했습니다. 원하는 방식으로 시각화할 수 있습니다. 이를 통해 이러한 고급 워크플로를 구현하고 반복적인 작업을 없애고 분석을 표준화하는 데 활용할 수 있습니다. 제가 자주 목격한 것은, 우리가 표준화를 선호하지만 데이터 분석에 관해서는 그것을 단순한 작업으로 여기는 경우가 많다는 것입니다.
맞는 말이지만, 모범 사례를 설정할 수 있는 부분도 있습니다. 이 데이터를 어떻게 봐야 할까요? 이 데이터가 갖는 특성에 맞는 적절한 통계적 검정은 무엇일까요? 이를 통해 JMP 워크플로우와 같은 방식으로 이러한 사항들을 체계화할 수 있습니다.
