같은 일을 Python으로도 주피터로도 실행하고 싶었다. 두 곳에 클릭과 입력 코드를 따로 쓰면 한쪽만 수정되고 결과가 달라지기 쉽다. 나는 설명과 입력 화면은 각 형식에 맞게 두면서 실제 업무 정의와 호스트 실행 경로는 공유하도록 만들었다. 같은 파일처럼 보이는 것보다 같은 절차를 부르는지가 중요했다.
보관함의 두 실행은 같은 정의에서 출발한다
ProgramRunner.start는 같은 프로그램을 load하고 Python과 notebook 방식 중 하나를 고른다. Python은 workflow.py를, notebook은 공통 run_notebook.py에 inspect.ipynb와 결과 위치를 넘긴다. 입력과 프로그램 ID, 실행 ID는 같은 실행 준비의 일부다. 메뉴가 둘이라고 업무 정의가 둘이 되는 구조는 아니다.
정의와 파일 hash를 읽는 단계도 앞에 있다. notebook을 실행한다는 이유로 변경 검사나 선택 파일 검사를 건너뛰지 않는다. 나는 형식을 바꿔 실행하면 보호 규칙이 약해지는 틈을 줄이려 했다. 다만 캡처처럼 별도의 네이티브 실행 경로가 있으므로 모든 플러그인이 반드시 Python 프로세스를 거친다고 말하지 않는다.
SDK는 새 브라우저를 만드는 코드가 아니다
Browser.run_recipe는 호스트가 전달한 실행 연결과 자격, ID를 사용해 요청한다. 자기 Chrome을 띄우거나 쿠키를 복사해 로그인하는 함수가 아니다. 호스트는 현재 실행이 맞는지 확인하고 공통 executeRecipe로 요청을 넘긴다. 의미 대상과 실제 조작의 검증은 그 호스트 경로에 남는다.
이 연결을 운영체제 샌드박스나 같은 사용자 계정의 모든 악성 코드를 막는 장치로 설명하지 않는다. 로컬 Python의 일반 능력과 SDK의 브라우저 계약은 다르다. 두 형식에서 같은 연결을 쓴다는 사실은 업무 경로가 모인다는 뜻이지 파일 실행 자체의 모든 위험을 없앤다는 뜻이 아니다.
노트북은 같은 절차를 단계별로 검토하게 한다
생성한 노트북은 Workflow를 만들고 입력 items를 준비한다. prepare에서 자료와 대상을 확인하고 run에서 실행하며 status에서 결과를 읽는다. 화면을 읽는 사람이 어느 셀부터 확인해야 하는지 설명을 붙이되 실제 클릭 코드를 셀마다 복제하지 않는다.
보관함에서 시작한 단일 실행과 프로젝트 안에서 열린 업무 노트북은 어댑터가 다르다. 전자는 실행 연결을 통해 Browser를 부르고 후자는 program.prepare와 runItem 같은 호스트 도구를 사용한다. 같다는 말을 두 어댑터의 수명과 재개 방식까지 완전히 같다는 주장으로 넓히지 않았다.
셀 재실행과 새 업무를 같은 것으로 보지 않는다
보관함의 실행 연결 안에서는 같은 key와 입력에 같은 promise를 사용한다. 프로젝트 업무 노트북은 job_id와 항목 ID, 입력 지문과 정의 hash를 원장에 남긴다. 따라서 셀을 다시 눌렀을 때 완료 결과를 재사용하는 층과 새 회차를 시작하는 층이 다르다.
정상적인 새 업무에는 새 실행 맥락이 필요하지만 결과 미확정을 피하려고 ID를 바꾸면 안 된다. 이 차이는 실행 어댑터를 하나로 뭉뚱그리면 놓치기 쉽다. 나는 한 정의를 여러 화면에서 쓰면서도 각 화면의 버튼이 어떤 수명의 작업을 요청하는지 설명하려 했다. 상세 중복 방지는 다른 글에서 다룬다.
기존 시험은 입력값과 실제 결과를 나눠 본다
제품 보관함 시험은 Python 실행에서 fixture iframe에 입력하고 CSV 결과 파일의 실제 내용을 확인한다. 재시작 뒤 notebook 실행에서는 다른 입력을 넣고 기존 자동화 탭이 중복되지 않는지, 실행 노트북 셀이 저장되는지 검사한다. 메뉴 이름만 존재하는지 보는 시험과 다르다.
이번 콘텐츠 작업에서는 해당 시험 코드와 구현을 읽었고 원래 앱을 재실행하지 않았다. 아래 합성 모듈은 CLI와 직접 작성한 노트북 코드 셀이 같은 컴파일 계획을 만드는지22개 시험 안에서 대조한다. 별도 Jupyter 커널이나 원격 Studio 연결이 검증된 것은 아니다. 각 확인의 범위를 분리해 남겼다.
수정할 핵심은 줄이고 설명할 접점은 늘린다
고정 업무 로직을 함께 쓰면 같은 오류를 두 군데에서 고칠 필요가 줄어든다. 대신 Python 사용자와 노트북 사용자가 준비와 결과를 어떻게 읽는지는 각 접점에서 잘 설명해야 한다. 코드 공유만으로 사용 흐름까지 저절로 좋아지는 것은 아니었다.
홈페이지 관리자와 관리 CLI에도 비슷한 기준을 적용할 수 있다. 같은 내용을 다루되 한쪽은 화면으로, 다른 쪽은 명령과 자료로 요청한다. 중요한 검증과 저장 경로는 공유하고 각 접점에서는 상태를 정확히 보여 주는 방식이다. 나는 여러 도구를 지원하는 일을 독립 구현의 수를 늘리는 일보다 같은 업무 계약으로 연결하는 일로 보고 있다.