글 한 편을 만드는 일에는 소재를 고르고 독자가 궁금해할 질문을 찾는 판단이 있다. 반면 완성된 원고를 정해진 입력란에 넣고 결과를 확인하는 순서는 반복되는 부분이 많다. 나는 이 둘을 같은 자동화로 묶지 않고 내용은 이번 작업에서 만들고 검증한 전달 절차는 코드로 재사용하는 쪽을 택했다.

좋은 원고와 올바른 입력은 서로 다른 결과다

Recipe의 parameters는 이번 제목과 본문 같은 값을 받고 steps는 어디에 어떻게 입력하고 무엇을 확인할지 담는다. 입력란에서 본문이 일치한다고 원고의 사실과 논리가 검증되는 것은 아니다. 반대로 좋은 원고라도 잘못된 계정이나 게시판에 들어가면 전달 작업은 실패다.

이 구분을 해 두면 실패 원인도 좁힐 수 있다. 내용이 어려운지, 입력이 누락됐는지, 실제 저장이 확인되지 않았는지를 나눠 본다. 모든 문제를 다시 글 쓰기부터 시작하거나 마지막 버튼만 다시 누르는 식으로 처리하지 않는다. 창작의 품질과 실행의 정확성에는 다른 확인 질문이 필요했다.

이번 원고는 고정 코드 안에 숨기지 않는다

제목과 본문이 달라져도 같은 의미 대상과 단계, 결과 조건을 쓰면 전달 절차는 재사용할 수 있다. 값은 템플릿의 매개변수 자리로 전달하고 고정 동작은 정의에서 읽는다. 따옴표와 여러 줄 한글을 JSON 코드처럼 이어 붙이지 않고 문자열 값으로 치환하는 구현도 이 분리에 해당한다.

다만 값만 바뀌었다고 항상 같은 업무는 아니다. 대상 사이트와 첨부 종류, 실제 발행 여부가 달라지면 절차의 의미도 바뀐다. 단순 원고 입력 절차에 영상 업로드를 요청했다면 지원하지 않는 부분을 빼고 완료했다고 말할 수 없다. 재사용은 요청의 차이를 먼저 확인한 뒤 가능한 선택이다.

검색한 이름보다 실제 단계를 먼저 읽는다

workflow.run 경로는 프로그램을 inspect했는지 확인한다. 검색 결과의 이름과 과거 의도는 후보를 찾는 힌트다. 현재 요청과 다른 발행이나 삭제 동작이 정의에 포함될 수 있으므로 단계와 입력, 결과 조건을 읽어야 한다. 같은 요청에서 이미 변경을 한 뒤 전체 절차를 뒤늦게 실행하는 것도 막는다.

나는 편한 자동화를 “제목이 비슷한 프로그램을 바로 실행하는 기능”으로 만들고 싶지 않았다. 원하는 목적과 고정된 동작을 연결하는 선택이 먼저 있어야 한다. 현재 북극성에서는 외부 에이전트가 도구 계약을 읽고 명시적으로 요청한다. 예전 내부 CLI가 판단하던 구조를 현재 제품의 숨은 모델 기능으로 설명하지 않는다.

같은 절차를 찾는 기준에도 예외가 있다

recipeIdentity는 이름과 보통의 입력 기본값을 비워 실행 구조를 비교한다. 같은 순서에 원고만 달라졌다고 보관함을 계속 늘리지 않으려는 규칙이다. 그러나 예전 예약 UI와 다른 draft 진입점은 특별히 구분한다. 기본값처럼 보이는 operation이 실제 처리 경로를 바꾸는 경우가 있기 때문이다.

기존 시험은 이름과 검색 기본값이 달라도 같은 절차로 연결되고 구조나 프로필, 코드가 바뀌면 구별되는지 확인한다. 이를 모든 글의 의미를 자동 판정하는 기능으로 확대하지 않는다. 절차 동일성은 코드가 정한 구조 비교이며 원고의 독창성과 이번 실행 권한은 다른 판단이다.

보관과 실제 실행 검증을 나눠 보고한다

ProgramLibrary.save는 정의와 동반 파일을 만들고 초안·실행 검증 전 같은 상태를 남긴다. 파일을 만들었다는 사실만으로 새 Python이 실제 사이트에서 성공했다고 표시하지 않는다. 예전 자동 저장 문서는 당시의 성공 절차 보관 기준을 설명하지만 현재 모든 명령의 자동 캡처를 보장하는 근거로 쓰지 않는다.

이번 글은 현재 함수와 기존 시험, 역사 문서의 역할을 나눠 읽은 제작 기록이다. 새 외부 글을 게시하거나 원래 브라우저 작업을 실행하지 않았다. 이 사이트에 글을 발행한 결과와 북극성의 특정 매체 발행 검증도 서로 다른 근거다. 독자가 재사용할 때 무엇을 더 시험해야 하는지 남겨 두려 했다.

사람의 판단을 줄일 곳과 남길 곳을 정한다

반복되는 전달 순서를 코드로 남기면 다음 글에서 같은 입력 조작을 다시 설계할 이유는 줄어든다. 대신 이번 소재가 맞는지, 독자가 이해할 수 있는지, 어디까지 공개할지에는 다시 판단이 필요하다. 나는 자동화가 늘어난 만큼 그 판단을 더 구체적으로 남기는 편이 낫다고 생각한다.

맞춤 ERP나 홈페이지 관리도 같다. 자료를 해석하는 판단과 정해진 값의 저장·확인은 다른 층이다. 코드가 잘하는 반복을 맡기되 코드가 무엇을 확인했는지 설명할 수 있어야 한다. 전달 성공을 내용의 우수성으로 바꾸지 않는 구분이 지속적으로 글을 쌓아 가는 작업의 기반이 됐다.