사람이 원하는 것은 사이트 선택표를 채우는 일보다 준비한 자료로 어떤 일을 몇 번 할지 말하는 것이다. 나는 반복 작업 화면에서 내부 프로그램 ID와 연결 JSON을 직접 고르게 하는 부담을 줄이고 싶었다. 대신 그 값을 없애는 것이 아니라 외부 에이전트가 현재 요청과 기존 플러그인을 한 번 대조해 연결하게 했다.

숨긴 필드는 기능이 사라졌다는 뜻이 아니다

반복 작업의 recipeDetails는 platform·work_program·work_inputs를 hiddenParameters로 둔다. 화면에는 작업 요청과 횟수, 자료 위치와 필요한 시간, 실행 방법을 설명한다. 프로그램 ID와 자료 치환 계획은 내부 전달에 남아 있다. 사용자가 매번 JSON을 입력하지 않아도 실행 계약은 존재해야 한다.

숨김은 권한 검사도 보안 경계도 아니다. 잘못된 프로그램을 연결하거나 이번 입력이 빠졌다면 뒤의 실제 검사에서 멈춰야 한다. 나는 필드를 적게 보이게 하는 일과 판단을 생략하는 일을 구분했다. 사람이 답해야 할 질문을 줄이는 대신 프로그램이 확인할 책임까지 줄여서는 안 된다.

외부 에이전트의 계획과 반복기의 판단을 나눈다

현재 구조는 외부 Codex가 프로젝트와 탭, 활성 플러그인을 읽고 맞는 절차를 한 번 연결한다. workProgram이 주어지면 일반 workflow로 해석하는 경로가 있다. 내부 반복기가 매 회차 모델을 불러 다음 버튼을 고르는 방식은 아니다.

단순한 사이트 단서와 횟수 추출도 있지만 모든 자연어를 완전히 이해하는 엔진은 아니다. 서로 다른 대상과 수량이 섞이면 명시적인 계획을 요구한다. 다른 작업이 적혀 있는데 현재 블로그 탭이라는 이유만으로 블로그 업무를 고르지도 않는다. 나는 언어로 요청할 수 있는 편의와 내부 해석의 실제 한계를 함께 설명한다.

내부 정의는 지원하는 자료 치환만 받는다

workDefinition은 연결한 절차에 반복기 자신이 들어 있지 않은지 확인한다. 반복기가 반복기를 다시 부르는 재귀 연결은 거절한다. 입력 키는 실제 매개변수와 맞아야 하고 값에는 정해 둔 자료 자리만 허용한다. title·body·schedule·folder·index·file·files 같은 값이다.

임의 셸과 코드를 이 자리에서 실행하지 않는다. file 치환은 선택 파일이 정확히 하나인지 확인한다. 여러 파일이 있는데 편한 하나를 고르는 일도 하지 않는다. 나는 일반 반복을 확장할 때 모든 자유를 한 문자열에 몰아넣기보다 실제 업무 자료를 명확한 값으로 연결하는 쪽을 택했다.

오래된 시작 주소를 실제 사이트 이동으로 오해하지 않는다

공통 Recipe에는 과거 경로의 시작 주소가 남아 있지만 notebookReservation 단계는 typed reservation.run으로 넘긴다. 기존 단위 시험은 그 호출이 한 번이고 브라우저 탐색을 만들지 않는지 확인한다. 파일의 사이트 문자열 하나를 보고 일반 업무도 반드시 그 사이트를 연다고 설명하지 않는다.

기존 프로그램을 새 입력 구조로 갱신하는 시험도 같은 ID 연결과 사용자 메모 보존을 확인한다. 편집한 setup은 덮지 않고 거절하는 경우가 있다. 나는 화면 용어를 바꿀 때 실행 정의의 호환성과 기존 작업을 함께 봐야 한다고 생각했다. 새 이름만 붙이고 내부 관계를 확인하지 않으면 사용자에게 설명한 기능과 실제 동작이 갈라질 수 있다.

코드 검수와 사용자가 보는 화면 검수를 나눈다

이번 글은 hiddenParameters와 해석 함수, 기존 시험의 요청 자료를 읽어 정리했다. 실제 운영 브라우저에서 화면을 새로 조작한 검수는 하지 않았다. 어떤 필드가 숨김 대상으로 선언됐는지 확인한 것과 모든 화면 크기에서 사용하기 편한지 확인한 것은 다르다.

공개한 폴더 반복기 예제는 합성 자료와 선언한 결과로 진행을 검토한다.24개 파일 시험은 실제 원본 보존과 순서 조건을 확인하지만 외부 에이전트의 자연어 계획을 시험한 것은 아니다. 나는 연결된 기능들이 있다는 이유로 서로의 검증 범위를 대신하게 하지 않는다. 필요한 다음 검수가 무엇인지도 제작 기록에 남긴다.

사용자는 업무를 말하고 시스템은 연결 책임을 진다

대표나 직원에게 필요한 것은 내부 어댑터의 이름보다 어떤 자료가 어디까지 처리되는지다. 나는 사람이 판단해야 하는 공개 범위와 수량, 대상을 앞에 두고 구현용 값을 뒤의 연결 계층에서 관리하는 흐름을 선호한다. 기술 설명을 없애기보다 필요한 사람에게 필요한 위치에서 보여 주는 것이다.

이 방식은 맞춤 ERP와 홈페이지 관리자에도 적용할 수 있다. 사용자는 자기 업무의 말로 요청하고 프로그램은 그 말을 실제 입력과 확인 조건으로 바꿔야 한다. 직관적인 화면은 판단을 숨기는 화면보다 누가 어떤 선택을 했는지 나중에 설명할 수 있는 화면에서 시작한다고 생각한다.