하나의 절차를 여러 프로젝트에서 쓰면 등록은 한 번이면 좋겠다. 그런데 한 업무에 맞춰 고친 부분이 다른 업무까지 바꾸면 재사용이 오히려 위험해진다. 나는 공통 목록에서 처음 가져온 정의를 프로젝트의 사본으로 남기고 이후의 수정과 실행 기록은 그 안에서 관리하도록 나눴다.
처음 가져오는 시점에 사본을 만든다
ProjectProgramLibrary는 공통 ProgramLibrary를 받아 프로젝트별 programs 위치를 사용한다. synchronize는 공통 목록의 프로그램 폴더를 살피고 해당 프로젝트에 manifest가 이미 있으면 건너뛴다. 같은 프로그램 ID를 쓰면서도 파일 위치와 실행 기록의 소속을 분리하는 구조다.
항상 공통 파일을 직접 참조하면 등록은 간단하지만 수정의 영향 범위가 커진다. 반대로 모든 업무를 별도 ID로 다시 등록하면 같은 절차인지 찾기 어렵다. 나는 공통 ID와 프로젝트별 정의를 함께 유지했다. 공통으로 발견하는 것과 실행할 내용을 한곳에서 공유하는 것은 다른 결정이었다.
복사할 파일 목록을 좁히고 완료 표시를 뒤에 둔다
프로젝트에 처음 전달하는 것은 recipe.json과 workflow.py, inspect.ipynb, README, manifest다. 실행 원장과 인증 정보, 사용자 파일을 공통 정의 복사의 목록에 넣지 않는다. 프로그램을 재사용한다는 이유로 원래 실행의 자료까지 따라가게 만들고 싶지 않았다.
manifest는 마지막에 복사한다. 다음 동기화가 완료된 사본이라고 판단하는 표시를 본문 파일보다 먼저 두지 않으려는 순서다. 이것이 여러 파일의 완전한 원자적 트랜잭션은 아니다. 중간 실패와 여러 프로세스의 경쟁까지 모두 해결됐다고 설명하지 않고 코드가 실제로 제공하는 완료 경계를 말한다.
로컬 파일을 바꿨다고 검증도 자동 갱신하지 않는다
프로젝트의 recipe만 임의로 바꾸면 다음 load에서 PROGRAM_CHANGED가 발생한다. 실제 hash와 manifest에 남긴 hash가 다르기 때문이다. 이 hash는 recipe와 workflow, 노트북의 셀 종류·소스 구성을 함께 읽는다. 화면 이름만 바꾸고 예전 검증 결과를 계속 쓰는 경로가 아니다.
다른 프로젝트의 같은 ID와 공통 목록 파일은 원래 내용으로 남는다. 수정이 고립돼 있다는 것과 그 수정본이 실행 준비됐다는 것을 나눈 것이다. 정상 수정은 검토와 갱신 절차를 거쳐야 한다. 나는 내용 보존을 이유로 검증 표시까지 그대로 믿게 하지 않으려 했다.
사용 지침과 활성화도 프로젝트의 상태다
사용자가 만든 스킬은 공통 목록에서 처음 가져온 뒤 프로젝트의 skill.json이 있으면 다시 덮어쓰지 않는다. 실제 읽기는 그 프로젝트에서 켜진 지침인지 확인한다. 공통 목록에 존재한다는 이유로 모든 작업에 내용을 주입하는 구조와는 다르다.
기존 시험은 한쪽 지침만 수정해 다른 프로젝트의 문구가 남는지 확인한다. 한쪽 스위치를 꺼도 다른 쪽은 켜져 있어야 한다. 내장 지침 초기화와 사용자 정의 사본의 경로는 코드에서 다르므로 이 규칙을 모든 내장 파일의 영구 고정으로 확대하지 않는다. 사용자 수정본을 다루는 정확한 범위를 설명하는 것이 중요했다.
시험은 바뀐 쪽의 거절까지 확인한다
프로그램 시험은 두 프로젝트의 폴더가 다른지 먼저 보고, 한쪽 recipe를 수정한다. 다른 쪽과 공통 목록의 원본 내용이 그대로인지 확인한 뒤 수정한 쪽은 load가 실패하고 다른 쪽은 정상 정의를 읽는지 본다. 수정한 화면이 보인다는 것보다 강한 비교가 필요했다.
이 글에서는 실제 함수와 기존 시험 코드를 대조했으며 원래 개발 앱과 사용자 프로젝트를 수정하지 않았다. 아래 공유 모듈은 같은 판단을 메모리 안의 텍스트 사본으로 새로 구현해21개 시험을 실행한 예제다. 실제 파일 배포와 원래 앱 검증은 포함하지 않으므로 두 근거의 범위를 구분해 두었다.
공통 개선은 선택 가능한 변경으로 남긴다
기존 사본을 보존하면 공통 개선이 모든 곳에 즉시 적용되지 않는다. 운영에서는 어느 프로젝트가 어느 정의를 쓰는지 확인하고 필요한 곳에 변경을 검토하는 일이 남는다. 나는 이 비용을 숨기지 않는다. 자동 업데이트 하나로 처리하면 프로젝트마다 달랐던 업무 판단이 지워질 수 있다.
회사 맞춤 프로그램도 비슷하다. 같은 기본 기능으로 시작했어도 용어와 입력, 처리 순서는 다를 수 있다. 공통 기반은 유지하되 현장에 맞춘 부분은 소유와 검증 범위를 따로 둬야 한다. 북극성에서는 최초 사본과 변경 해시, 프로젝트별 사용 설정이 그 구분을 실제 코드로 만드는 출발점이 됐다.