AI마다 쓰기 편한 도구를 붙이고 싶었지만, 도구마다 발행 규칙을 새로 만들고 싶지는 않았다. K-POP PULSE의 8월 초 기록은 기사 발행과 수정을 공통 서비스로 모으고, 내부 API와 로컬 CLI가 그 함수를 사용하도록 바꾼 과정을 남겼다.

같은 검사를 여러 곳에 복사하면 다음 수정 때 한쪽만 바뀔 수 있다. 나는 입력을 만드는 도구와 저장을 결정하는 통로의 책임을 나누려 했다. 초기 설계, 당시 실제 호출과 지금 제작기를 발행하는 STAGE24의 별도 구현을 각각 읽어 설명한다.

편집기의 모양이 달라도 공개 조건은 같아야 한다

초기 설계는 편집자가 발행을 요청할 때와 예약 작업이 처리할 때 모두 공개 조건을 확인하도록 했다. 한 화면에서 미리 확인한 상태만으로 이후 실행이 무조건 통과하는 구조를 피하려는 방향이다. 이 문서는 당시 설계이며 현재 원본 관리자 버튼을 새로 실행한 검사는 아니다.

CLI와 화면은 원고를 받는 방법이 다를 수 있다. 화면은 항목을 보여 주고 CLI는 파일이나 구조화 입력을 받지만, 어느 쪽으로 왔는지 때문에 근거가 없는 글이 통과해서는 안 된다. 나는 새 인터페이스를 붙일 때 서버가 같은 공개 책임을 맡는지 먼저 읽는다.

공통 서비스를 호출한 실제 연결을 확인한다

당시 코드 작성과 수정 응답은 공통 서비스가 만들어지고 내부 API가 그 서비스에 발행과 수정을 맡겼음을 보여 준다. 이어서 로컬 헬퍼가 같은 함수를 가져오는 입력도 있다. 이 회차의 검사와 가져오기 확인 출력은 남아 있지만 그것만으로 모든 화면 경로를 똑같이 검수했다고 말하지 않는다.

후속 게시 CLI와 가이드 수정 코드에도 공통 함수 가져오기가 남아 있다. 나는 통일이라는 문서 제목보다 실제 호출이 어디로 들어가는지 확인한다. 공통 이름을 가진 별도 파일이 여러 개라면 규칙의 복제가 다시 생길 수 있고, 같은 함수에 도달해도 그 앞에서 잘못된 값을 만들 수 있다.

발행 뒤의 부수 작업도 어디에서 맡을지 정한다

한 수정 기록은 검색 알림을 API 입구에서 공통 서비스로 옮기고 입구의 중복 알림을 제거했다. 특정 입구로 들어온 발행만 알림을 받는 차이를 줄이려는 변경이었다. 후속 검사 통과와 가져오기 결과도 기록에 남아 있다.

나는 이 결과를 모든 검색엔진의 수신이나 색인이 성공했다는 뜻으로 쓰지 않는다. 발행 저장과 알림 전달은 서로 다른 결과다. 부수 작업이 실패하면 무엇이 저장됐고 무엇을 다시 확인할지 알 수 있어야 한다. 코드의 공통 위치와 외부 서비스의 실제 결과도 나누어 보고한다.

현재 이 제작기 사이트에서는 같은 API로 연결했다

STAGE24는 K-POP PULSE와 다른 구현이다. 현재 코드에서 관리자 화면의 발행 동작과 관리 CLI가 같은 인증 콘텐츠 API 동작을 요청하는 것을 읽었다. 서버는 검토 근거와 공개 조건을 확인하고, 전달한 현재 버전으로 수정 충돌을 처리한다.

이 설명은 현재 코드 연결과 내가 실제 사용한 CLI의 결과에 근거한다. 원본 K-POP 관리자 화면이 정확히 같은 payload 서비스를 쓴다는 확인으로 넓히지 않는다. 새 버튼의 실제 브라우저 조작도 코드 읽기와는 별도다. 같은 원칙을 적용하더라도 사이트와 확인 범위를 구별해서 남긴다.

성공 응답 뒤에 저장과 공개를 다시 읽는다

공통 통로가 있다는 사실이 입력 오류를 없애지는 않는다. 이 프로젝트의 다른 일정 기록에는 잘못된 필드를 보내도 성공처럼 보이는 상태를 받은 경우가 있다. 인터페이스를 추가할 때는 허용 필드, 오류와 충돌 상태, 저장된 값을 다시 읽는 절차까지 입력 계약으로 정해야 한다.

아래는 그 책임을 다른 사이트에 설명하는 새 지도다. 실제 관리 주소나 토큰, 원본 코드의 복사본은 아니다. 초안 저장과 공개 요청, 공개 본문 읽기를 구별한다. 응답을 확인하지 못한 경우에는 같은 작업의 저장 상태부터 읽고 재시도를 정해 중복 쓰기를 줄이려 한다.

코드와 구현 살펴보기

새 설명용 발행 책임 지도. 원본 경로나 자격정보가 아니다.

CLI or editor form
  -> authenticated request with inspected manuscript and current version
  -> shared server validation and persistence
  -> explicit result: saved, blocked, conflict or inspection required
  -> read stored state and public content

# New explanatory responsibility map, not an original route or credential.

새 도구가 늘어도 수정할 기준은 찾을 수 있게 한다

나는 도구가 많아질수록 어떤 파일과 계약이 정본인지 더 분명히 남기려 한다. 다른 AI나 컴퓨터에서 이어 쓰더라도 실제 서버 규칙과 현재 원고 버전을 읽고 작업할 수 있어야 한다. 문서에서 통일을 선언한 것만으로 이런 연결이 자동으로 유지되지는 않는다.

공통 통로는 편집 판단을 없애는 장치가 아니다. 자료를 고르고 문장을 검토하는 판단은 남겨 두되, 그 결과를 저장하고 공개하는 책임을 일관되게 만든다. 도구를 바꿀 때 다시 복제할 규칙보다 함께 확인할 입력과 결과를 남기는 편이 다음 작업에 도움이 되었다.