화면에서 반복 문구를 지우고 표시를 고쳤어도 다음 빌드가 예전 형태를 다시 만들면 같은 문제를 반복하게 된다. 원래 요청에는 상세 페이지 수정을 템플릿에도 적용하자는 말이 있었다. 이미 만든 사이트의 출력과 앞으로 만들 사이트의 생성 과정을 함께 생각해야 하는 작업이었다.
기록에는 새 템플릿의 후처리·런타임 연결과, 기존 사이트에 완료한 수정만 다시 적용하는 함수가 따로 있다. 생성된 파일을 고치는 일과 생성 규칙을 고치는 일은 당장 같은 화면을 만들더라도 다음 빌드에서 다른 결과를 낼 수 있었다.
후속 템플릿 검수 기록과 생성·미리보기 코드는 확인 대상을 더 좁혀 준다. 공통 엔진, 현장에 복사된 엔진, 빌드 출력, 서버가 제공하는 경로를 순서대로 대조해야 지금 열린 화면의 출처를 찾을 수 있다.
현재 페이지의 수정과 다음 생성의 수정을 나눈다
최종 HTML을 직접 정리하면 현재 미리보기에서 결과를 빨리 볼 수 있다. 하지만 생성 입력과 후처리가 그대로라면 다음 생성 때 그 파일이 다시 쓰일 수 있다. 자료 값의 문제인지, 공통 화면 규칙의 문제인지, 해당 사이트만의 예외인지 먼저 나누어야 했다. 고친 줄의 위치보다 어떤 과정이 그 줄을 만드는지가 중요하다.
당시 공통 모듈 안내는 새 템플릿에 후처리와 실행 파일을 함께 전달하되 기존 사이트 엔진과 원본을 자동 변경하지 않는다고 설명한다. 새로운 생성 규칙과 기존 프로젝트의 유지 방식은 다른 경로다. 새 정본을 고쳤다는 사실만으로 이미 있는 모든 사이트가 같은 수정 결과를 받았다고 볼 수 없다.
새 현장은 생성 시점의 엔진을 복사해서 받는다
확인한 현장 생성 코드는 공통 엔진의 필요한 파일을 새 프로젝트의 .engine 폴더로 복사한다. 새 프로젝트의 빌드 명령은 그 안의 실행 코드를 사용한다. 각 엔진은 자기 모듈의 위치를 기준으로 필요한 파일을 찾는다. 공통 원본을 나중에 고쳐도 이미 만든 현장의 엔진이 함께 바뀌지는 않는다.
기존 안내는 공통 정본을 수정·동기화·봉인·검사하는 절차와 기존 현장에 적용하는 절차를 구분한다. 현장 생성 시험은 전달된 공통 파일이 해시 기록과 같은지, 유지관리용 동기화기가 현장 엔진에서 빠져 있는지 확인한다. 이번에는 그 시험 정의를 읽었으며 실행하지 않았다.
따라서 공통 파일을 고쳤는데 현장의 새 빌드가 예전 모습이라면, 먼저 그 현장이 사용하는 엔진과 수정 정본을 비교할 수 있다. 자료 입력이나 현장별 예외를 보존한 채 필요한 변경을 검토해야 한다. 현장 폴더를 새로 생성하거나 엔진 전체를 덮어쓰는 것을 첫 해결책으로 삼지는 않는다.
정적인 정리와 실행 중의 동작을 연결한다
보관된 빌드 변경에는 생성된 페이지에 공통 표시 정리를 적용하고 필요한 CSS와 JavaScript를 함께 복사하는 연결이 있다. 반복 문구를 정리하는 후처리와 창 크기나 선택 상태를 다루는 런타임을 나눠 갖는 구조다. 화면을 만드는 시점에 끝낼 수 있는 일과 화면이 열린 뒤에 필요한 일을 구별한 것이다.
보관된 변경 조각으로 확인할 수 있는 것은 빌드에 연결을 추가한 위치다. 필요한 자산이 출력에 들어갔는지, 페이지가 그 파일을 읽는지는 별도 검사 결과가 필요하다. 이번 집필에서 전체 빌드를 다시 실행한 것은 아니므로 구현과 실제 전달 결과를 구분해 설명한다.
기존 사이트는 이미 확인한 수정만 다시 적용한다
기존 사이트용 함수는 관리 장부에서 그 사이트의 technical-checked 항목을 읽고 해당 수정만 다시 실행하도록 작성되어 있다. 다른 사이트에서 끝낸 항목을 가져와 무조건 적용하는 방식이 아니다. 개별 추가 항목도 그 사이트의 상태를 보고 재적용한다. 먼저 한 수리의 범위가 다음 빌드에서도 기준이 되는 구조다.
이 함수는 장부의 상태를 신뢰하므로 완료 표시를 잘못 남기면 재적용도 잘못될 수 있다. 코드가 있다는 이유만으로 모든 미래 빌드에 자동 연결됐다고 판단할 수도 없다. 실제 생성 경로의 연결과 출력 후 검사가 함께 있어야 한다. 재적용 규칙과 그것을 호출하는 과정은 별도로 확인할 대상이다.
봉인과 코드 검사가 뜻하는 범위를 지킨다
원래 안내는 정본을 수정한 뒤 봉인 자료를 갱신하고 코드 검사를 하도록 한다. 봉인은 기준 파일을 식별하고 예상하지 않은 차이를 찾는 관리 장치다. 파일이 봉인과 같다는 사실이 화면의 적절함이나 문구의 사실성을 입증하지는 않는다. 무엇을 기준으로 묶었는지와 왜 고쳤는지 설명을 남겨야 한다.
실제 과거 실행 출력에는 공통 표시와 자료 선택 등을 다루는 템플릿 검사 마흔 개가 통과한 기록이 있다. 다른 검사가 섞인 명령의 실패를 그 통과 숫자로 덮지 않았고 별도 성공한 실행도 대조했다. 이들은 소스와 빌드 조건의 근거이며 원래 모든 고객 화면의 픽셀 검수가 아니다. 이번에는 보관된 코드를 실행하지 않았다.
새 빌드를 만들어도 열린 서버의 경로는 남아 있다
확인한 빌드는 기본적으로 새 출력 폴더를 만들고 그 경로를 last-build.json의 output으로 기록한다. 출력 폴더를 직접 지정하지 않은 미리보기 명령은 시작할 때 이 기록을 읽어 서버에 넘긴다. 서버는 받은 루트 경로 아래에서 요청한 파일을 찾는다. 매 요청마다 last-build.json을 다시 읽어 최신 출력으로 옮기지는 않는다.
이 구조에서는 새 빌드가 만들어졌어도 이미 실행 중인 서버가 이전 폴더를 계속 제공할 수 있다. 안내문도 재빌드 뒤 미리보기 서버를 종료하고 다시 실행해야 최신 빌드를 볼 수 있다고 설명한다. 브라우저 새로고침은 같은 주소에 다시 요청하는 행동이므로, 서버가 가리키는 폴더까지 바뀌었다는 확인을 대신하지 못한다.
아래는 이 관계를 보여 주는 합성 경로 예시다. 실제 현장의 실행 로그나 새 서버를 띄운 결과는 아니다. 고정되는 것은 서버의 루트 경로이며 파일 내용을 메모리에 고정한다는 뜻은 아니다. 같은 루트 안의 파일을 바꾸면 서버는 그 파일을 읽을 수 있다.
코드와 구현 살펴보기
Synthetic path relationship; no server executed
project/.engine -> builds/preview-A -> running server
new build -> builds/preview-B
last-build.json -> builds/preview-B
running server -> builds/preview-A다음 제작자가 알아야 할 수정 위치
자료 입력, 공통 정본, 사이트별 예외, 후처리, 런타임과 생성물 중 어디를 바꿨는지 기록할 수 있다. 재빌드 뒤 확인할 페이지와 남겨야 할 정상 기능도 함께 둔다. 의뢰자는 현재 화면만의 수정인지 이후 제작에도 남는 수정인지 알 수 있고, 제작자는 같은 문제를 다시 고칠 때 출발점을 찾을 수 있다.
급한 화면 수리에는 생성물을 직접 고칠 수도 있다. 다만 다음 생성에서 덮어쓰일 수정인지, 생성 규칙에도 반영할 수정인지 남겨야 한다. 그래야 한 번의 화면 수정과 재빌드 뒤에도 유지될 수정을 구분해 이어 갈 수 있다.
이번 코드 읽기에서 남길 확인 순서는 현장 폴더의 엔진, 최근 빌드 기록의 출력 경로, 열린 미리보기의 프로젝트·포트와 서버가 제공하는 경로다. 각 위치의 파일에 기대한 수정이 들어 있는지 대조한 뒤 화면을 검수한다. 이번 집필에서는 기존 미리보기나 운영 서버를 재시작·변경하지 않았고 특정 고객 사이트의 반영 문제를 해결했다고 보고하지 않는다.