데이터 작업을 고칠 때마다 원격 환경을 기다려야 한다면 작은 수정도 무거워진다. 로컬에서 쿼리와 파일 처리를 확인할 수 있는 도구가 반가운 이유다. 다만 로컬에서 결과가 맞았다는 말에 “실제 배포에서도 안전하게 동작한다”는 의미까지 담으면 곤란하다. 결과를 계산하는 능력과 누가 그 계산을 해도 되는지는 다른 검사를 요구한다.
10월 29일 Hacker News에서 발견한 MiniLake는 노트북에서 Databricks API를 흉내 내는 프로젝트다. 공식 설명은 실제 SQL, Delta Lake와 Spark 작업 실행을 지원한다고 밝힌다. 동시에 인증 없이 동작하고 권한을 허용하는 로컬 도구이며 단일 프로세스라는 경계도 적어 둔다. 이 한계를 읽는 일이 기능 목록을 읽는 일만큼 중요하다.
참고 원문: 관련 원문을 직접 읽기
시험에서 생략한 것을 적어 보기
나는 로컬 대체 도구를 검토할 때 “얼마나 비슷한가”보다 “이번 시험에서는 무엇을 생략했는가”를 먼저 묻고 싶다. 동작을 단순하게 만드는 것은 좋은 설계일 수 있다. 문제는 생략이 사라진 듯 보고될 때 생긴다. 개발을 빠르게 하는 모형과 서비스의 권한 체계를 검증하는 환경은 목적이 다르다.
가상의 주문 데이터 작업을 생각해 보자. 입력 파일에 세 줄이 있고, 취소 주문 한 줄을 제외하면 두 줄이 남아야 한다. 로컬 테스트는 필터와 집계 결과, 파일 형식, API 응답을 확인하는 데 쓸 수 있다. 이 예시는 설명을 위한 설계이며 MiniLake를 설치하거나 실제 데이터를 실행한 결과가 아니다.
같은 작업에 두 역할을 넣으면 질문이 달라진다. 분석자는 주문 합계를 읽을 수 있지만 원본을 삭제할 수 없고, 운영자는 승인된 정리 작업만 수행한다고 가정하자. 로컬 도구가 모든 권한을 허용한다면 두 역할의 실패 조건을 그곳에서 검증했다고 할 수 없다. 쿼리가 성공했다는 결과는 남기되 권한 열은 미검증으로 두어야 한다.
계약을 작게 나누는 표
점검표는 입력, 기대 출력, 확인 환경, 남은 위험의 네 열이면 시작할 수 있다. 첫 행에는 “취소 주문을 뺀 결과 두 줄”을 적는다. 다음 행에는 “읽기 전용 역할의 삭제 요청 거절”을 적는다. 전자는 로컬 결과 비교 후보이고 후자는 실제 권한 경계가 있는 별도 환경의 검증 후보다. 표의 빈칸이 둘을 구분해 준다.
또 다른 행에는 작업의 상태 변화를 쓴다. 제출한 작업이 대기와 실행을 거쳐 끝나는지, 실패가 어떻게 보이는지다. API 모양이 비슷해도 실제 클러스터의 자원 부족과 지연까지 재현하는 것은 아니다. 로컬에서 빨리 끝난 시간을 원격 서비스의 처리 시간으로 바꿔 적지 않는다. 단일 프로세스의 성공을 고가용성의 증거로 쓸 수도 없다.
이렇게 나누면 어떤 도구를 쓸지 정하는 일도 단순해진다. 수정한 SQL의 결과가 궁금하다면 빠른 로컬 반복이 유용하다. 접근 제어가 궁금하다면 그 질문에 답하는 환경이 필요하다. 둘 중 하나만 골라야 하는 문제가 아니다. 서로 다른 질문을 같은 “테스트 통과”라는 제목 아래 숨기지 않는 것이 핵심이다.
같은 작은 자료를 두 곳에서 읽기
제안할 수 있는 다음 단계는 민감한 실제 자료 대신 인위적으로 만든 작은 입력을 준비하는 일이다. 정상 행, 빠진 필드, 중복 행을 넣고 기대 결과를 손으로 계산한다. 그 입력과 기대 결과를 보존하면 로컬과 승인된 통합 환경에서 같은 질문을 할 수 있다. 데이터 수를 크게 늘리기 전에 의미가 맞는지 확인하는 방식이다.
예를 들어 원본 세 줄 중 두 줄의 주문 번호가 같다면 무엇을 기대해야 할까. 하나로 합칠지, 오류로 돌려줄지, 둘 다 남길지는 프로그램 밖의 업무 규칙이다. 도구가 정답을 대신 골라 주지는 않는다. 따라서 기대 결과 파일 옆에 중복을 어떻게 해석했는지 한 문장도 둔다. 통과한 숫자보다 그 문장이 나중의 변경을 설명한다.
자료 이동도 별도 검토 대상이다. 로컬이라는 이름만으로 개인정보가 안전해지거나 보관 의무가 사라지지 않는다. 예제에는 가상 값을 쓰고, 로그와 출력 파일에 무엇이 남는지 확인해야 한다. 이 글은 운영 자료를 복사하라는 안내가 아니며 클라우드 사용 비용을 모두 없앨 수 있다는 약속도 아니다. 로컬 계산에도 장비와 관리 시간이 든다.
공식 설명의 지원 범위는 변할 수 있다. 그래서 사용한 버전과 확인한 날짜, 미검증 항목을 같이 남긴다. 나중에 인증 기능이 추가되더라도 이전 시험 결과를 새 기능의 증거로 재사용할 수는 없다. 새로운 경계를 실제로 확인한 뒤에야 표의 상태를 바꾸는 편이 정확하다.
권한 검사에서는 거절되어야 하는 요청을 성공 사례만큼 중요하게 둔다. 가상의 읽기 전용 역할이 허용되지 않은 자료에 접근했을 때, 결과가 비어 있는 것과 명시적으로 거절되는 것은 서로 다르다. 빈 결과는 자료가 없다는 뜻으로 오해될 수 있다. 기대한 거절 방식과 기록을 명시해야 계산 정확성 검사와 접근 제어 검사가 같은 표 안에서도 분리된다.
로컬 도구가 주는 가장 큰 도움은 모든 것을 대신하는 데 있지 않을 수 있다. 자주 바꾸는 계산을 가까이 가져오면, 원격 환경에서는 정말 필요한 위험을 더 선명하게 확인할 수 있다. 나는 다음 테스트 보고서에 통과 목록과 함께 생략 목록도 적어 두고 싶다. 지금 “성공”이라고 부르는 결과에는 어떤 질문이 아직 빠져 있을까?
함께 읽기: 컨테이너와 파일의 관계를 확인하기