JMP에 데이터를 가져오는 것은 분석 워크플로의 핵심 부분이므로, JMP 18에서는 JMP가 접근할 수 있는 타사 데이터 소스의 범위를 넓히기 위해 새로운 데이터 커넥터를 도입했습니다. JMP 18은 ODBC 데이터 소스에 대한 더욱 세밀한 구성을 지원하며, 이러한 구성을 여러 플랫폼의 동료와 쉽게 공유하고 JMP Live에 게시할 수 있도록 합니다. 이 글에서는 JMP 18에 있는 데이터 커넥터뿐만 아니라 향후 JMP 버전에서 확장될 예정인 기능에 대해서도 다룹니다.
안녕하세요, 시청하시는 이 시간에 좋은 아침입니다. 저는 JMP의 소프트웨어 개발자인 닐 시키어스키입니다. 저는 JMP의 데이터 커넥터 프로젝트를 담당하는 주요 개발자 중 한 명입니다. 오늘 저는 이 데이터 커넥터 프로젝트에 대해, 그리고 이 프로젝트가 JMP 18에 어떤 의미를 가지는지, 또한 앞으로 어떤 방향으로 나아갈지에 대해 이야기하고자 합니다.
여기 세 가지 C가 있습니다. 이것이 바로 Data Connect를 통해 달성하고자 하는 핵심 목표입니다. 첫째, 이전보다 더 많은 데이터 소스에 쉽게 연결할 수 있도록 하는 것입니다. 둘째, 이러한 연결을 더욱 쉽게 공유할 수 있도록 하는 것입니다. 같은 플랫폼(Mac, Windows 또는 다른 플랫폼)을 사용하는 동료와 JMP Live를 통해 연결을 공유할 수 있도록 하는 것입니다. 더 많은 데이터 소스에 대한 액세스를 제공하는 동시에, 이 모든 작업을 하나의 공통 인터페이스에서 수행할 수 있도록 하는 것이 목표입니다.
JMP 18에서는 이 모든 것을 구현할 수 없었기 때문에 ODBC에 집중했습니다. ODBC는 JMP가 SQL Server, MySQL 등 다양한 데이터베이스와 같은 원격 데이터 소스와 통신하는 데 사용하는 기술입니다. ODBC를 선택한 이유는 이미 여러 종류의 데이터베이스에 접근할 수 있는 기술이므로, 더 많은 데이터베이스에 접근할 수 있도록 확장할 여지가 있다고 판단했기 때문입니다.
현재 몇 가지 장애물 때문에 그 부분이 다소 어렵습니다. 그것이 바로 저희가 그 부분을 검토하게 된 또 다른 이유입니다. 예를 들어, 어려움의 원인 중 하나는 SQL 코드에 있습니다. SQL 코드는 데이터베이스에서 데이터를 가져오는 데 사용되는 프로그래밍 언어인데, JMP는 이 코드를 생성하고 ODBC API를 통해 전송하여 결과를 받아 데이터를 표시해야 합니다.
모든 데이터베이스의 SQL 코드가 완전히 동일한 것은 아닙니다. 예를 들어, PostgreSQL 데이터베이스에서 테이블(이 경우 우리가 가장 좋아하는 큰 클래스)에서 몇 개의 열을 가져오는 경우 SQL 코드는 다음과 같습니다. 하지만 MySQL이나 다른 데이터베이스에서는 동일한 쿼리가 다음과 같이 나타납니다. PostgreSQL에서는 큰따옴표를 사용하고, MySQL에서는 백틱을 사용하며, SQL Server는 또 다릅니다.
이 권한 때문에 JMP는 어떤 데이터베이스와 통신하는지 알아야 합니다. 우리는 그 정보를 얻을 수 있습니다. 하지만 실제로 사용하려면 JMP가 각 데이터베이스 유형에 대해 알아야 합니다. JMP가 해당 데이터베이스 유형을 알지 못하는 경우, 특정 대체 동작이 적용됩니다. 이 동작이 제대로 작동하면 다행이지만, 항상 적절한 기본값을 설정하려고 노력해도 작동하지 않을 수 있습니다. 그런 경우에는 해당 데이터 소스와 함께 쿼리 빌더를 사용할 수 없습니다.
또 다른 어려움은 사용되는 연결 문자열입니다. JMP는 데이터베이스에 연결하기 위해 ODBC에 연결 위치, 연결 방법 등 다양한 정보를 알려주는 문자열을 제공해야 합니다. 아주 간단한 연결 문자열은 다음과 같습니다. 예를 들어, 우리가 연결하는 서버는 JMP에서 접근 권한이 있는 테스트 머신입니다. 앞으로 이러한 연결 문자열을 더 자세히 살펴보겠습니다.
하지만 더 중요한 것은 드라이버가 있다는 점입니다. 드라이버는 ODBC에 연결되어 특정 데이터 소스에 접근할 수 있도록 해주는 소프트웨어입니다. ODBC 자체는 데이터 소스에 대해 알지 못하며, 마치 소프트웨어처럼 Mac과 Windows에 각각 설치할 수 없습니다. 설치하더라도 두 개의 다른 소프트웨어를 다운로드해야 합니다. ODBC도 마찬가지입니다.
Actual SQL Server는 Actual이라는 회사에서 만든 SQL Server 드라이버로, Mac용입니다. 만약 제가 이 연결 문자열을 사용하는 연결을 다른 사람과 공유하고 싶은데, 그 사람이 Windows를 사용하거나 JMP Live를 사용한다면 연결 문자열을 변경해야 합니다.
그러려면 윈도우 드라이버가 뭔지 알아야 합니다. 이 경우에는 SQL Server라고 하죠. 저는 제 윈도우 컴퓨터에서 이걸 실행하면 잘 작동합니다. 하지만 마찬가지로 해당 데이터베이스가 뭔지 알아야 하고, 각 플랫폼에서 해당 데이터베이스에 대응하는 드라이버가 뭔지 알아야 합니다. 그래서 공유가 어려워지는 거죠.
JMP를 필요로 하는 데이터베이스 간의 차이점, 이러한 데이터베이스에 대한 지식, 그리고 다양한 연결 방식과 연결 문자열의 차이점을 알아야 합니다. 연결을 공유하기 어려울 수 있으며, 원하는 모든 데이터 소스를 연결하는 것도 어려울 수 있습니다.
이 문제를 해결하기 위해 JMP 18에 내부적으로 도입한 데이터 커넥터 프레임워크와 ODBC에 있는 특정 애플리케이션이 있습니다.
이러한 기능의 핵심 아이디어는 JMP가 연결 유형에 따라 내부적으로 설정하는 모든 옵션을 가져온 것입니다. SQL Server는 하나의 옵션 세트를 필요로 하고, PostgreSQL은 또 다른 옵션 세트를 필요로 합니다. 우리는 이러한 모든 옵션을 노출하고 각각 개별적으로 구성할 수 있도록 만들었습니다.
이렇게 하면 SQL Server와 어떤 면에서는 비슷하지만 다른 면에서는 다른 데이터베이스가 있을 때 옵션을 변경하면 제대로 작동합니다. 이러한 옵션은 단순히 환경 설정 메뉴에 있는 항목이 아닙니다. 이름을 지정할 수 있는 구성이며, 이를 공유할 수 있습니다.
전체 설정 세트를 얻을 수 있습니다. 이름을 지정할 수도 있죠. 그러면 특정 데이터베이스에 연결할 때 해당 설정을 참조할 수 있고, 다른 곳에 연결할 때는 다른 설정을 사용하면 됩니다. 이름이 지정되어 있기 때문에 이러한 연결을 공유하는 것도 훨씬 쉬워집니다.
마지막으로, 여러분이 설정하는 사항들은 플랫폼에 따라 다를 수 있습니다. 드라이버나 다른 설정들이 플랫폼에 따라 달라질 수 있다는 점을 방금 살펴보았습니다.
맥에서만 특정 작업을 수행하고 윈도우에서는 아무것도 수행하지 않아야 한다면, 그렇게 하는 것이 가능합니다. 더 세밀한 설정이 필요한 경우에도 가능할 수 있습니다. 이것이 핵심 개념입니다. 이제 이러한 개념에 대해 더 자세히 설명하겠지만, 모든 것을 실제로 보여주는 방식으로 설명하지는 않겠습니다.
여기 JMP가 있습니다. 파일 데이터베이스로 이동하면 데이터 커넥터라는 새로운 메뉴 항목이 있습니다. 이를 클릭하면 쿼리 빌더를 사용해 본 적이 있다면 매우 익숙한 창이 나타납니다. 새 연결을 클릭하면 구성 목록이 표시됩니다.
여기서 몇 가지 알아두어야 할 사항이 있습니다. 맨 위에 있는 것들은 모두 내장 구성 파일이므로 모두 com.jmp로 시작합니다. 이 파일들은 저희가 제공하는 것으로, 내부적으로 지원하던 다양한 데이터베이스에 해당하며, 이제 이러한 방식으로 외부에도 공개되었습니다.
이것들은 직접적인 연결에는 유용하지 않을 수 있습니다. 서버 정보 같은 것은 없지만, 새로운 구성을 만드는 기초 자료로는 여전히 유용합니다. 그 아래에는 다른 여러 구성들이 있습니다.
이것들 중 일부는 제가 직접 만들었습니다. 하지만 대부분은 JMP가 ODBC에서 관리하는 연결, 즉 DSN(도메인 소스 이름)을 기반으로 자동으로 생성한 것입니다. 여기에서 제 Mac에 있는 DSN 연결 목록을 볼 수 있으며, JMP에서도 이러한 DSN 중 일부를 확인할 수 있습니다.
이것들은 자동으로 생성되므로 시작하기가 더 쉽습니다. 이 창을 닫겠습니다. 생성된 연결 목록에 이러한 연결이 있으므로, 이상적으로는 '연결' 버튼을 클릭하기만 하면 가장 쉽게 사용할 수 있을 것입니다.
이건 실제로 작동하지 않습니다. 우리가 보는 것은 드라이버에서 보낸 오류 메시지입니다. 사용자 ID를 제공하지 않았다는 내용입니다. JMP가 이 구성을 변환하는 과정에서 해당 정보를 수집할 수 없었던 것입니다.
하지만 여기서 기회가 주어집니다. 대화 상자에서는 새 구성을 생성하여 이 구성을 그대로 사용할 수 있도록 제안하고 있습니다. 필요한 사용자 이름과 비밀번호를 추가한 다음 연결을 시도해 보겠습니다. '예'를 클릭하겠습니다.
이것은 커넥터 편집기입니다. 나중에 더 자세히 설명하겠지만, 지금은 필요한 정보만 입력해 보겠습니다. 비밀번호가 필요합니다. 이전에는 비밀번호가 없었지만, 이제 비밀번호를 입력할 것입니다. 입력해 보겠습니다. 사용자 이름도 필요합니다. 같은 방식으로 입력하면 됩니다.
이제 정보를 입력했으니 연결을 테스트해 보겠습니다. 연결이 성공한 것을 확인할 수 있습니다. 연결하기 전에 제대로 작동하는지 확인했으니, 설정을 저장해 두겠습니다. 이렇게 하면 나중에 다시 설정하는 번거로움을 줄일 수 있습니다. 연결을 구성했으니 이제 저장했습니다. 자, 이제 연결해 보겠습니다.
여기 스키마 목록이 있습니다. 이 스키마 중 하나를 선택하면 테이블 목록이 표시됩니다. 여기서 가장 중요한 테이블인 'BigClass'를 선택하겠습니다. 이제 가장 쉬운 방법은 해당 테이블을 여는 것입니다. '테이블 열기'를 클릭하면 테이블이 나타나는 것을 볼 수 있습니다. 좋습니다.
하지만 쿼리 빌더를 사용할 수도 있습니다. 이 창을 닫고 이제 쿼리 빌더 버튼을 클릭해 보겠습니다. 쿼리 빌더 창이 열리면 이전과 동일한 인터페이스가 나타납니다.
이제 쿼리를 만들어 보겠습니다. 단계별로 계속 살펴볼까요? 열을 추가하고 쿼리를 실행하면 쿼리가 완료된 후 테이블이 다시 나타납니다. 이제 테이블이 생성되었으니 모든 것이 제대로 작동하는 것을 확인했습니다. 그럼 다시 한번 해볼까요?
연결을 저장했으니 그걸 사용할 수 있을 거예요. 이제 연결을 끊겠습니다. 이제 갈 수 있어요. 저장해둔 연결을 찾아서 연결하면 됩니다. 이제 연결됐고 모든 게 다시 보이네요.
자, 이제 테이블을 다시 열어보죠. 테이블을 열었으니 다른 작업도 해볼 수 있겠네요. 앞서 공유에 대해 이야기했는데요, 동료들과 공유하는 것과 JMP Live와 공유하는 것 모두 포함됩니다. 먼저 JMP Live와 공유하는 것부터 시작해 보겠습니다.
데이터 테이블을 게시하겠습니다. 이렇게 테이블이 나타났습니다. 다음을 클릭하겠습니다. 제 개인 공간에 게시할 것이고, 이제 게시되었으니 닫고 JMP Live로 이동하겠습니다.
여기 제 개인 공간이 있는데, 이제 새로 고침할게요. 테이블이 보이시죠? 불러오세요. 로딩될 때까지 기다리시고, 이제 설정으로 이동하면 스크립트를 사용하여 데이터를 새로 고침하는 옵션이 있습니다. 여기서 쿼리 빌더와의 차이점을 확인할 수 있습니다. 이전에는 새로 고침 스크립트를 설정하려면 연결 문자열이 필요했습니다. 하지만 이제 소스 스크립트를 사용하면 조금 다른 점을 보실 수 있을 겁니다.
지금은 자세히 살펴보지 않겠습니다. 작동하는지만 확인하고 싶어서 저장해 두겠습니다. 자격 증명을 입력하고 새로 고침을 클릭하겠습니다. 작동하는지 확인해 보겠습니다. 실패했네요. 이유를 살펴보죠. 오류가 발생했습니다. 이해하기 조금 어려울 수 있지만, 유효한 드라이버를 지정하지 않았다는 뜻입니다.
스크립트를 좀 더 자세히 살펴보고 무슨 문제가 있는지 파악해 봅시다. 보시면 '드라이버 실제 오픈 소스 데이터베이스'라는 줄이 있습니다. 드라이버를 지정했는데, 보시다시피 맥 전용 드라이버 중 하나라서 작동하지 않는 것이 당연합니다.
이전에는 윈도우 드라이버 이름을 알아내서 여기에 입력하고 다시 시도해야 했지만, 이번에는 그럴 필요가 없습니다. 그냥 삭제하고 저장한 다음 다시 시도해 보겠습니다. 성공한 것 같으니 다시 로드하겠습니다.
여기서 특별히 달라진 점은 없습니다. 데이터 자체는 변경되지 않았지만, 새로 고쳐진 것을 확인할 수 있습니다. 이렇게 된 이유는 다음과 같습니다. 다시 스크립트를 살펴보겠습니다. 내장된 구성을 사용하고 있으며, JMP에서 생성한 구성과 일치하도록 추가 구성 항목을 추가했습니다.
일반적으로 JMP를 실제 서비스에 배포할 때는 사용자가 지정한 구성과 동일한 소스 스크립트를 생성합니다.
차이가 발생하는 이유는 다음과 같습니다. pkg-config에 단순히 ID JMP dev라고 지정하지 않는 이유는 JMP Live가 해당 이름을 인식하지 못하기 때문입니다. JMP Live와의 호환성을 높이기 위해, JMP Live에 내장된 구성 중 하나를 기반으로 하고 필요한 모든 항목을 추가하여 동일한 구성을 다시 생성하는 것입니다.
이 내장 기능 덕분에 모든 것이 제대로 작동합니다. 앞서 말씀드렸듯이 데이터 커넥터의 핵심 아이디어 중 하나는 플랫폼에 따라 설정을 변경할 수 있다는 것입니다. 내장된 Postgres 설정에서 볼 수 있듯이, 실행 중인 플랫폼에 맞는 드라이버를 자동으로 찾아줍니다.
제 맥에서는 윈도우용 오픈소스 데이터베이스 드라이버, 예를 들어 포스트그레스 드라이버를 찾아서 실행합니다. 내장된 드라이버들은 모두 그런 식으로 작동합니다.
이렇게 하면 Mac과 Windows 간, 그리고 서로 다른 드라이버가 설치된 기기 간의 공유가 훨씬 쉬워집니다. JMP가 실행 중입니다. 이제 JMP로 돌아가서 이 창을 닫겠습니다. 연결을 해제해서 깨끗한 상태로 돌아가겠습니다. 이제 구성이 완료되었습니다. 이 구성은 JMP에서 생성한 것입니다.
자, 이제 우리가 직접 구성을 만들고 싶다고 가정해 봅시다. ODBC 관리자를 통하지 않고 JMP가 구성을 인식해서 여기에 표시하는 방식이 아니라요. 이 부분도 동시에 살펴보고 좀 더 자세히 알아보겠습니다. 이번에는 SQL 서버에 연결해 보겠습니다. 바로 이 구성입니다.
그리고 '새로 만들기'를 클릭하면 이 구성을 기반으로 새 구성을 만들 수 있습니다. 따라서 SQL 서버에 대한 모든 세부 정보를 지정할 필요 없이 제 연결에 필요한 정보만 지정하면 됩니다. 이 창이 다시 나타나면 편집기가 표시됩니다. 이제 좀 더 자세히 살펴보겠습니다.
먼저 연결 유형과 JMP 18이 있는데, ODBC만 지원합니다. 다음으로 연결 기본 설정이 있는데, 말씀드린 대로 내장 SQL 서버 구성부터 시작합니다. 여기에서 SQL 서버 내장 구성이 보이는데, 여기서 원하는 설정을 지정합니다. 다른 옵션도 있습니다. ODBC의 기본 설정부터 완전히 처음부터 시작할 수도 있습니다.
파일 경로를 지정할 수도 있고, 기본 설정으로 사용할 구성을 지정할 수도 있습니다. 하지만 일반적으로는 다른 설정을 사용하게 될 것으로 예상되므로, 이 ID를 사용하게 될 것입니다. 그 아래에는 모든 옵션이 그룹별로 표시되어 있는데, 첫 번째 그룹은 연결 정보입니다.
어디에 연결할지, 어떤 자격 증명을 사용할지 등을 나타냅니다. ODBC 연결 문자열에 들어가는 내용이죠. 그 아래에는 다른 옵션들이 있는데, SQL에 대한 다양한 옵션과 기본 ODBC 계층에 대한 옵션도 있습니다.
여기서 '연결'로 이동하면 실제로 연결을 설정해야 합니다. 필요한 정보를 입력하겠습니다. 데이터베이스 이름은 SQBTest입니다. 이렇게 하면 이 확인란이 선택 해제되는 것을 볼 수 있습니다. 이 확인란은 기본 구성에서 가져온 값을 사용할지 여부를 나타냅니다.
제가 변경했든 안 했든 체크박스가 선택 해제된 상태입니다. 다시 선택하면 기본값으로 되돌아가지만, 이 값은 필요합니다. 다시 입력하겠습니다.
JMP 19까지 공유를 위한 드라이버가 여기에 보이네요. 이 작업은 필요하니 바로 진행하겠습니다. 비밀번호 값도 입력해야 하고요. 서버 이름은 다시 jmpdev2입니다. 사용자 이름도 입력했으니 연결이 되는지 확인해 보겠습니다. 연결되네요. 하지만 더 진행하기 전에 시나리오를 하나 생각해 보겠습니다. SQL Server에 직접 연결하는 것이 아니라, SQL Server와 매우 유사하지만 완전히 동일하지는 않은 다른 서비스에 연결하는 경우를 가정해 보겠습니다.
차이점은 SQL Server에서는 대괄호를 사용하는 반면, PostgreSQL에서는 큰따옴표를 사용한다는 점입니다. SQL 옵션들을 살펴보면 여러 가지 차이점을 발견할 수 있습니다. 먼저 따옴표 종류를 살펴보겠습니다. 현재는 대괄호로 지정되어 있습니다. 이를 큰따옴표로 바꾸면 데이터베이스 요구 사항과 일치하게 됩니다.
다행히 이 데모에서는 SQL Server가 대괄호와 큰따옴표 두 가지 모두를 지원합니다. 대괄호는 SQL Server의 기본 형식이지만, 큰따옴표는 더 일반적인 형식입니다. 둘 다 지원하므로 실제로 어떻게 작동하는지 살펴보겠습니다. 이 내용을 저장해 두겠습니다. 이제 제 SQL Server 계정이 될 겁니다. 연결해 보겠습니다.
테이블 목록을 보기 전에 먼저 클래스를 선택할 수 있습니다. 쿼리 빌더를 사용하면 해당 옵션이 나타나고, 생성된 SQL 코드가 우리가 선택한 내용을 반영하는 것을 볼 수 있습니다.
일반적으로는 대괄호 대신 큰따옴표를 사용하겠지만, 여기서는 큰따옴표를 사용했습니다. 이렇게 하면 제대로 작동하는 것을 확인할 수 있습니다. 쿼리를 실행해 보면 테이블이 반환됩니다. 다시 말하지만, 처음부터 설정을 새로 만드는 것이 아니라 기본 설정을 기반으로 구성을 만들었습니다. 몇 가지 옵션만 제공하면 완벽하게 작동하는 연결이 생성됩니다.
저는 동작 방식을 약간 다르게 조정할 수도 있었습니다. 이제 이렇게 많은 노력을 기울였는데, 만약 우리 조직의 다른 누군가가 이 기능을 활용하고 싶어 한다면 어떻게 해야 할까요? 제가 보여드린 것처럼 JMP Live뿐만 아니라 다른 사람들과도 이러한 연결을 공유할 수 있습니다.
그렇게 하려면 여기 있는 작은 빨간색 삼각형 메뉴를 사용하면 됩니다. 이걸 클릭하면 커넥터를 공유하는 옵션이 나타납니다. 제가 이 화면을 띄워 볼게요. 왼쪽에는 구성 목록이 있습니다. 여기에는 기본 제공 구성은 제외되어 있는데, 기본 제공 구성은 공유할 필요가 없기 때문입니다.
설정을 선택하면 오른쪽에 표시됩니다. 저는 더블 클릭해서 선택했지만, 이 버튼들을 이용해서 설정을 이동하거나 제거할 수도 있습니다. 이 버튼을 클릭하면 다시 추가할 수 있습니다. 설정을 공유하려면 추가 기능을 만들어야 합니다. JMP의 추가 기능을 활용하여 이러한 설정을 배포하고 쉽게 설치할 수 있도록 하겠습니다.
하지만 추가 기능이기 때문에 모든 추가 기능에는 ID가 필요합니다. 여기 아래쪽에 있는 상자가 바로 그 ID를 입력하는 곳입니다. 기본값은 하위 구성 요소의 순서를 바꾼 호스트 이름으로 설정됩니다. 제 컴퓨터의 주소는 mh382.mmt.com입니다. 이를 반전시키면 com.sas.mmt.mh302가 됩니다. 이것이 기본 ID가 됩니다. 저는 구성을 하나만 추가했기 때문에 해당 구성의 이름을 사용하게 됩니다. 하지만 예를 들어 다른 구성을 추가하면 '데이터 커넥터'라는 이름이 사용되겠죠.
하지만 저 부분을 삭제해 보겠습니다. 저장을 클릭하죠. 기본적으로 이름이 전체 ID에 JMP 추가 기능이 붙은 형태로 설정되는데, 그럴 필요는 없습니다. 좀 더 보기 좋게 만들 수 있으니 '서버'라고 하겠습니다. 사실, 더 좋은 방법도 있습니다. 이 기본 이름을 굳이 사용할 필요는 없으니 삭제하고 이름을 바꿔 보겠습니다. 예를 들어 '회사'라고 해보겠습니다. 제 사용자 이름을 사용해서, 올해 디스커버리 컨퍼런스에서 사용할 이름을 정하는 거죠.
저장을 누르세요. 좀 더 알아보기 쉬운 이름으로 바꿔 보겠습니다. 저장을 마치면 비밀번호를 유지할지 묻는 메시지가 나타납니다. 비밀번호는 다른 사람과 공유하고 싶지 않은 정보일 가능성이 높으므로 자동으로 삭제하는 옵션이 있습니다. 이 경우에는 비밀번호를 삭제하겠습니다.
보시다시피 저장됐습니다. 이제 제 바탕화면에 이 추가 기능이 설치되었네요. 그런데 이제 이걸 어떻게 해야 할까요? 다른 사람에게도 설치해 줄 수 있습니다. 하지만 저는 제 자신에게 설치해 보겠습니다. 이제 윈도우로 넘어가 보죠. 윈도우로 전환하고, 잠깐 로그인하면 JMP가 실행됩니다. 다운로드 폴더에 있는 이 추가 기능을 찾아서 설치하면 됩니다.
좋습니다. 이제 실제로 어떻게 작동하는지 확인해 보겠습니다. 파일, 데이터베이스, 데이터 커넥터로 이동합니다. 구성을 불러오겠습니다. 여기 보이시죠? 연결을 시도해 보겠습니다. 로그인 실패로 연결에 실패했다는 메시지가 나타납니다. 당연한 결과입니다. 비밀번호를 변경했으니까요. 좀 더 구성해 보겠습니다. 비밀번호를 다시 입력해 보겠습니다. 테스트해 보겠습니다. 잘 작동하는 것을 확인할 수 있습니다. 확인을 누르니 연결되었습니다.
우리는 Mac을 만들었습니다. [들리지 않는 부분 00:26:10] 그리고 Windows로 가져와서 연결할 수 있습니다. 모든 것이 제대로 작동하도록 하는 동일한 기능을 모두 확인할 수 있습니다. 이것이 공유입니다. 처음부터 구성을 설정하는 것입니다. 하지만 이 모든 것이 어떻게 작동하는지 그 이면에는 어떤 원리가 적용될까요? JMP로 돌아가 보겠습니다. SQL Server 내장 구성 아래에 이 내용이 표시됩니다. 우리가 만든 다른 구성들도 볼 수 있습니다.
그럼 어떻게 생겼을까요? 어디에 저장될까요? 기본 제공되는 설정 파일은 JMP 설치 폴더에 있지만, 직접 만든 설정 파일은 JMP 사용자 데이터 폴더에 다른 데이터와 함께 저장됩니다. 맥에서는 사용자 폴더의 라이브러리 폴더로 이동하고, 윈도우에서는 응용 프로그램 지원 폴더에서 JMP를 선택하면 됩니다.
이 폴더는 App Data 아래에 있습니다. 보시다시피 JMP 관련 정보, 버전 정보, Python 관련 파일, 데이터 커넥터 폴더 등이 있습니다.
해당 폴더를 열어보면 제가 설정한 모든 구성 파일과 ODBC를 통해 제 대신 생성된 JMP 파일들이 있습니다. 예를 들어, MySQL 서버 구성 파일과 JMP 데이터 커넥터(JMP DC) 확장 파일이 있습니다. 이러한 JMP DC 파일 외에도 JMPDataConnectorRegistry.JSON 파일이 있는데, 이 파일에는 MySQL 서버 이름과 해당 파일을 연결하는 정보가 담겨 있습니다.
이 파일에는 다른 정보도 포함될 수 있습니다. 하지만 안에 무엇이 있는지 살펴보겠습니다. 텍스트 편집기를 사용할 건데요, 아, 방금 말한 편집기가 잘못됐네요. 아주 비슷한 편집기 두 개를 찾았으니, 이 편집기를 열어 보겠습니다. 보시면 JSL처럼 보이는 텍스트가 많이 있는데, 실제로 JSL이거나 JSL의 하위 집합입니다.
여기 왼쪽에는 옵션 이름이 있고, 오른쪽에는 해당 값이 있습니다. 첫 번째 줄이 특별한데, 이는 기본 서버가 com.JMP.SQLServer로 식별될 서버임을 나타냅니다. 설정 내용을 보면, 우리가 설정한 서버가 해당 데이터베이스, 즉 프로 유형에 대한 수정 사항임을 알 수 있습니다.
일반적으로 왼쪽에 있는 옵션 이름들은 에디터에 표시되는 내용과 매우 유사합니다. 오른쪽에는 에디터에 표시되는 값들과 비슷한 값들이 있습니다. 여기에는 예시를 보여주는 작은 텍스트가 없습니다. 특히 사용자 이름과 비밀번호의 경우, 여기에 인코딩된 문자열이 있습니다. 이렇게 저장하는 이유는 사용자 이름과 비밀번호를 직접 저장하지 않기 위해서입니다.
하지만 JMP는 어쨌든 모두와 연결할 수 있었고, 앞서 말했듯이 이것은 JSL입니다. 플랫폼별 구성을 추가하려는 경우를 예로 들 수 있는데, 내장된 구성에서는 이미 살펴봤습니다. 하지만 직접 구성하고 싶다면, 예를 들어 아직 다루지 않은 옵션인 블록 페칭을 생각해 보겠습니다. 블록 페칭은 활성화할 수 있다면 데이터를 더 효율적으로 가져올 수 있는 기능이지만, 때때로 지원되지 않거나 제대로 작동하지 않을 수 있습니다.
제 Mac에서는 작동하지만 Windows에서는 작동하지 않는다고 가정해 보겠습니다. Windows와 Mac에서는 작동하도록 하고, 그 외의 경우에는 작동하지 않도록 하고 싶습니다. 이와 같이 Block Fetch 옵션을 JSL 표현식으로 설정하면 원하는 효과를 얻을 수 있습니다. 왜냐하면 오른쪽에 있는 값들은 모두 JSL 코드이기 때문입니다.
JMP가 이 설정을 불러올 때마다 이를 평가합니다. 그러면 "아, 그렇군요."라고 말하며, 이 경우에는 Mac을 사용하고 있으므로 블록 페칭이 켜져 있음을 확인합니다. 이렇게 작동하는 것입니다. 네, 그리고 JMP 자체에서도 JSL을 사용하여 이러한 기능을 사용할 수 있습니다. 이제 이 창은 닫겠습니다.
자, 이제 모두 닫아봅시다. 다시 JMP로 돌아왔네요. 스크립트 편집기를 열어보죠. 기본 템플릿입니다. 뭘 할 수 있을까요? 파일에서 설정을 불러올 수 있습니다. 메모리 데이터 커넥터를 사용할 겁니다. 다시 한번 살펴볼까요? 지금까지 MySQL 서버를 사용해 왔죠. 이 줄이 설정을 불러옵니다. 그러면 해당 설정이 표시됩니다. 이제 특정 값을 가져올 수 있습니다. 예를 들어, 우리가 설정한 블록 가져오기(Block Fetch) 옵션을 가져올 수 있죠.
아니면 따옴표 유형을 가져올 수도 있습니다. 옵션을 변경해서 따옴표 유형을 이전 값인 대괄호로 되돌릴 수 있습니다. 블록 가져오기 기능을 끄면 됩니다. 이제 다시 출력해서 원하는 효과가 나타나는지 확인해 보겠습니다. 이 모든 과정을 실행하면 블록 가져오기가 켜져 있고 따옴표 유형이 두 개로 설정된 것을 볼 수 있습니다. 하지만 설정을 변경한 후에는 모든 것이 꺼집니다.
이것이 바로 이 부분을 조작하는 방법 중 일부입니다. 전체를 살펴보면 기본값이 아닌 모든 값을 볼 수 있습니다. 예를 들어 사용자 이름과 비밀번호가 보입니다. 하지만 SQL Server에서 기본값과 다른 여러 옵션도 볼 수 있습니다. 이 모든 것을 레지스트리에서 확인할 수 있습니다. 이름과 실제 구성 간의 매핑은 JSL을 통해서도 접근할 수 있습니다.
여기에 변수가 있습니다. 이 변수를 사용하면 사용 가능한 모든 항목을 가져올 수 있습니다. 이 목록에는 우리가 만든 항목과 JMP에 내장된 항목이 모두 표시됩니다. Windows 환경에서 실행한다면 추가 기능을 통해 설치된 항목도 표시됩니다. 특정 항목에 대한 메타데이터도 가져올 수 있습니다. 여기에서 우리가 만든 구성을 다시 살펴보면 이름과 경로를 알 수 있습니다. 이는 필수적인 정보이지만, 유형도 포함되어 있으며 ODBC인 경우 드라이버 정보도 함께 표시됩니다.
JSL용 구성도 등록할 수 있습니다. 예를 들어, MySQLServer2DC라는 이름의 자체 구성을 작성한다고 가정해 보겠습니다. 새 경로 변수를 추가했습니다. 이 변수에 익숙하신 분들은 아시겠지만, 이 변수는 앞서 보여드렸던 데이터 커넥터 폴더를 가리킵니다. 이제 여기에 텍스트를 입력할 수 있습니다.
간단하게 진행하겠습니다. 먼저 MySQL 서버의 기본 설정을 복원하고, 몇 가지 데이터 유형을 원래대로 되돌리겠습니다. 이제 이렇게 되었습니다. 마지막으로 경로를 따라가서 등록하겠습니다. 이름은 다른 파일들과 마찬가지로 파일 이름과 일치해야 합니다. 경로도 입력해야 합니다. 이 모든 것을 실행하면 로드해 볼 수 있습니다.
여기서는 이전과 마찬가지로 두 개의 변수를 사용해 보겠습니다. 작동하는 것을 볼 수 있고, 여기에 무언가가 출력되는 것을 확인할 수 있습니다. 변경한 값도 확인할 수 있습니다. 보이시죠? 좋습니다. 다시 한번 확인했듯이, JSL을 사용하여 설정을 조작할 수 있습니다. 설정을 직접 다루려면 파일 시스템에서 설정 파일의 위치를 확인하고 플랫폼별 설정을 추가할 수도 있습니다.
지금까지 많은 이야기를 나눴습니다. 이제 마무리를 짓고 처음으로 돌아가 보겠습니다. 이 프로젝트에는 구체적인 목표가 있다고 말씀드렸었죠. 하나씩 살펴보겠습니다. 첫 번째 목표는 더 많은 데이터 소스에 연결할 수 있도록 하는 것이었습니다. JMP 18에서는 ODBC를 통해 데이터 소스 접근을 확장했습니다. 예를 들어 SQL Server용 JSON 형식을 변경한 것을 통해 앞으로 어떤 가능성이 열릴지 조금이나마 보여드렸기를 바랍니다.
데이터 소스와의 호환성을 향상시켰습니다. 공유 측면에서는 JMP Live와 Windows의 공유 기능을 보여드림으로써 어떤 기능을 제공하는지 명확히 이해하셨기를 바랍니다. 마지막으로, 더욱 통일된 상호 작용을 제공합니다. 이는 이전에는 볼 수 없었던 부분입니다. 새로운 인터페이스를 보여드렸고, ODBC에서만 작동하는 기능도 보여드렸습니다. 여기서 중요한 점은 저희가 ODBC에 집중하고 있으며, 다른 기능을 위한 기반을 다지고 있다는 것입니다. 이는 앞으로 저희가 선보일 기능들입니다.
JMP 18.1의 미래에 대해 말씀드리자면, 주로 편집기에 대한 몇 가지 사소한 개선 사항이 계획되어 있습니다. JMP 19에서는 편집기에 더 많은 개선 사항이 적용될 예정입니다. 하지만 무엇보다 중요한 것은 새로운 연결 방식이 추가될 것이라는 점입니다. 현재 ODBC에서만 사용 가능한 기능을 다른 방식으로도 확장할 계획입니다. 그중 첫 번째로 언급하고 싶은 것은 SAS입니다.
JMP 18에서는 SAS 연결 기능을 제거해야 했지만, JMP 19에서는 다시 제공하며 데이터 커넥터 프레임워크에 통합할 예정입니다. 즉, 연결 인터페이스, 구성 편집 편집기, 그리고 추가 기능처럼 구성을 공유하는 기능까지 모두 동일하게 유지됩니다. 또한 Amazon S3 및 Microsoft SharePoint 연결 기능도 추가할 예정입니다. 이는 많은 분들이 오랫동안 요청해 오셨던 기능입니다.
S3와 SharePoint의 흥미로운 점은 JMP에 포함되지 않고 배포된다는 것입니다. 반면 SAS는 JMP 18 이전 버전과 유사한 형태로 배포될 예정이며, 기존에 제공되던 GSL 기능들을 대부분 이용할 수 있게 될 것입니다.
S3와 SharePoint는 JMP에 포함되어 배포되지는 않지만, JMP 마켓플레이스를 통해 제공될 예정입니다. 이미 들어보신 분들도 계시겠지만, 혹시 모르시는 분들은 Discovery 행사에서 관련 내용을 접하게 되실 겁니다.
간단히 말하자면, JMP에 확장 기능을 배포하는 방법이 될 것입니다. S3 및 SharePoint 연결 기능을 이러한 방식으로 배포할 예정입니다. JMP에서 이러한 기능이 작동하도록 하려면, JMP에서 노출되는 Python API를 정의하여 해당 커넥터 프레임워크에 연결하는 데 필요한 모든 것과 인터페이스하고, 나아가 쿼리 빌더 등으로 이동할 수 있도록 할 것입니다.
이러한 기능을 구현하기 위해 해당 인터페이스를 사용했고, 기존 파이썬 라이브러리도 활용했습니다. 이는 파이썬 생태계의 놀라운 점 중 하나이며, JMP 18의 파이썬 통합을 개선하기 위해 우리가 기울인 노력의 결실이기도 합니다. 하지만 이러한 기능은 우리에게만 국한된 것이 아닙니다.
해당 인터페이스는 저희가 공개하고 문서화할 예정이며, 이를 통해 저희뿐만 아니라 여러분도 새로운 유형의 연결을 생성하고 JMP 및 쿼리 빌더와 통합할 수 있음을 알려드릴 것입니다. 모든 도구를 동일하게 사용할 수 있습니다.
이것이 우리가 앞으로 해나갈 일입니다. 제가 드릴 말씀은 이게 전부입니다. 다시 한번 말씀드리지만, 18 버전에서 우리가 이룬 성과가 제가 지금 이야기하고 있는 것과 같은 향후 개선 사항의 토대를 마련했을 뿐만 아니라, ODBC를 통해 우리가 할 수 있는 일들을 획기적으로 업그레이드해 주었다고 생각합니다.
더 많은 데이터 소스에 연결할 수 있고, 이러한 연결을 더 쉽게 공유할 수 있다는 점입니다. 앞으로 우리가 할 수 있는 일들이 훨씬 더 많아질 것이라고 생각합니다. 앞으로 어떤 일들이 가능해질지 기대됩니다. 그럼 이만 마치겠습니다. 들어주셔서 감사드리고, 앞으로도 계속해서 유익한 시간을 보내시길 바랍니다.
