GPT-6 Astra 실행 중 방향 조정: 처음부터 다시 시작하지 않고 작업 바꾸기

실행 중 방향 조정이 바꾸는 것

공식 방향 조정 문서는 Responses API의 WebSocket 연결을 통한 GPT-6 Astra 지원을 설명합니다. 방향 조정과 이전 작업 취소는 명확히 구분됩니다. 이미 전달한 출력은 다시 쓰지 않으며, 시작된 도구 작업도 자동 취소되지 않습니다.

인터페이스에도 이 구분을 반영해야 합니다. ‘요구사항 변경’과 ‘작업 중지’는 서로 다른 의미여야 합니다. 외부 쓰기 작업이 진행 중일 때 사용자가 대상을 바꾸더라도, 애플리케이션은 이전 쓰기가 실행되지 않았다고 가정해서는 안 됩니다.

좋은 상태 메시지는 무엇이 아직 대기 중이고 무엇이 완료되었는지 알려 줍니다. 원래 요청을 조용히 바꿔 사용자가 마지막 작업에 어떤 지시가 적용됐는지 추측하게 하기보다, ‘새 요구사항은 다음 작업에 적용됩니다’라고 설명하는 편이 명확합니다.

방향 조정 이벤트의 순서 이해하기

스트리밍은 출력이 도착하는 대로 보여 주는 기능입니다. 방향 조정은 이후 작업을 이끌 지시를 바꾸는 기능입니다. 제품이 한쪽을 지원한다고 다른 쪽도 제공하는 것은 아닙니다.

문서에 나온 WebSocket 흐름에서는 response.create로 시작하고 response.created를 기다립니다. 같은 연결에서 응답 ID를 previous_response_id에, 수정한 지시를 input에 담아 response.steer를 보냅니다. response.steer.accepted는 업데이트가 대기열에 들어갔다는 뜻이며, 변경된 작업이 모두 끝났다는 뜻은 아닙니다. 필요한 도구 결과나 승인이 없으면 response.steer.pending이 이를 알려 줍니다. 이어서 실행되는 작업은 원래 응답과 구분해 추적하세요.

마찬가지로 작업 완료 후의 일반적인 후속 메시지는 응답 실행 중의 지시 변경과 다릅니다. 검토자가 작업 경과를 정확히 재구성할 수 있도록 애플리케이션 로그에서 두 경로를 구분하세요.

GPT-6 Astra 가이드는 실행 중 방향 조정을 모델의 새로운 작업 흐름 기능 중 하나로 소개합니다. 그렇다고 모든 채팅창이나 타사 애플리케이션이 필요한 이벤트 처리를 구현했다는 뜻은 아닙니다. 화면에 표시된 모델 이름뿐 아니라 실제 사용하는 인터페이스도 확인하세요.

애플리케이션 화면에서는 ‘변경 요청 수신’과 ‘새 작업 완료’를 구분하세요. 아직 실행 중인 작업 옆에 현재 요구사항을 표시하세요. 이는 권장하는 화면 설계이며, API가 완성된 작업 대시보드를 제공한다는 주장은 아닙니다.

유용한 기존 작업을 보존하는 변경 지시 작성하기

좋은 변경 지시는 무엇이 달라졌고, 무엇은 유지하며, 다음에 무엇을 해서는 안 되는지 설명합니다.

예를 들어 ‘기존 데스크톱 레이아웃은 유지해 줘. 다음 단계는 터치 조작에 집중해 줘. 현재 빌드를 게시하거나 교체하지 마’라고 요청할 수 있습니다. 유용한 맥락을 유지하면서 다음 행동의 범위를 좁힐 수 있습니다.

반면 ‘다르게 만들어 줘’라는 요청은 새로운 목표인지, 시각적 수정인지, 중지 요청인지 도우미가 추측하게 만듭니다. 인터페이스에서 현재 목표를 보여 주고 구체적인 요구사항을 수정하게 하면 도움이 됩니다.

변경 지시가 완료된 작업과 충돌하면 이를 명확히 알리세요. 사용자가 수정을 원하더라도 그것은 별도의 범위와 결과를 갖는 새로운 작업입니다.

도우미가 프로토타입의 키보드 조작을 검토하는 도중 디자이너가 모바일 요구사항을 추가했다고 가정해 보세요. 유용한 지시는 ‘전부 다시 해’가 아니라 ‘게임플레이 목표는 유지하고, 다음으로 터치 입력을 검토하되 기존 키보드 동작은 바꾸지 마’입니다.

앞서 얻은 관찰 결과는 여전히 유용할 수 있습니다. 새 테스트에는 터치 대상 크기, 의도치 않은 반복 입력, 화면 방향 전환, 같은 행동에 대한 피드백의 일관성을 포함하세요. 이는 권장 검사 항목이며, 측정된 Astra 성능에 관한 주장이 아닙니다.

터치 조작 요구사항을 구체화하려면 아케이드 게임을 플레이하면서 탭, 길게 누르기, 빠른 반복 입력이 어떻게 표현되는지 살펴보세요. 관찰한 내용을 다음 검토의 명세로 활용하되, 어떤 모델이 게임을 만들었는지 또는 모델을 사용했는지는 추측하지 마세요.

요구사항 변경을 위한 작업 상태 모델

애플리케이션 기록에서 계획 중, 실행 중, 완료된 작업을 구분할 수 있게 하세요.

아래 표는 애플리케이션 설계를 돕기 위한 것으로, API 이벤트 참조 문서를 대신하지 않습니다. 모든 작업을 수정 가능한 문단처럼 취급하는 흔한 실수를 방지하는 데 도움이 됩니다.

도구 결과를 해당 결과를 발생시킨 작업과 연결하세요. 늦게 도착한 결과를 새 요구사항에 따라 얻은 근거로 오인해서는 안 됩니다. 더 이상 다음 판단에 적합하지 않은 오래된 결과도 기록할 필요가 있습니다.

요구사항 A에 따라 읽기 작업을 시작하고, 사용자가 요구사항 B를 제출한 뒤, 이전 읽기 결과가 돌아오는 상황을 가정해 보세요. 결과를 A에 연결해 저장한 다음 B에도 답이 되는지 판단하세요. 새 검사 결과로 이름만 바꾸지 마세요. 예를 들어 키보드 처리에 관한 결과가 터치 조작의 정상 동작까지 입증하지는 않습니다.

실제 변경은 애플리케이션에서 통제하기

모호한 변경 요청과 영향이 큰 작업 사이에서 모델만이 유일한 안전장치가 되어서는 안 됩니다. 애플리케이션은 제안된 쓰기 작업을 대기열로 관리하고, 영향이 큰 단계에는 승인을 요구하며, 그 승인이 최신 작업과 여전히 일치하는지 확인할 수 있습니다.

예를 들어 사용자가 초안 업로드를 승인한 뒤 대상 프로젝트를 바꿨다면, 기존 승인을 새 대상으로 조용히 이전해서는 안 됩니다. 대상과 업로드할 내용을 다시 확인하세요.

외부 메시지, 구매, 삭제, 배포에도 같은 원칙이 적용됩니다. 방향 조정은 도우미가 수정된 목표를 이해하도록 돕지만, 트랜잭션 시스템이나 롤백 보장을 제공하지는 않습니다.

읽기 전용 작업에서는 늦게 도착한 결과가 대개 불필요한 작업이나 혼란을 일으킵니다. 쓰기 작업에서는 실제 상태가 바뀔 수 있습니다. 두 상황을 따로 설계하고 테스트하세요.

처리하기 까다로운 시점에 변경 요청 테스트하기

아래는 제안하는 통합 테스트 계획입니다. 이 글을 위해 실제로 실행한 테스트는 아닙니다.

각 사례에서 사용자에게 보여 줄 상태, 새 작업을 시작해도 되는지, 완료를 어떻게 기록할지 정하세요. 모델이 새 메시지를 확인했다고 말하는지만 보지 말고 동작의 일관성으로 성공 여부를 평가하세요.

• 도구가 시작되기 전에 변경 요청이 도착함.
• 읽기 전용 도구가 실행 중일 때 도착함.
• 쓰기 작업이 이미 진행 중일 때 도착함.
• 서로 충돌하는 요구사항을 담은 두 변경 요청이 도착함.
• 사용자가 확인 메시지를 보기 전에 연결이 끊김.
• 이전 작업 버전에 속하는 도구 결과가 늦게 도착함.

다음 행동을 사용자에게 보여 주기

신뢰할 수 있는 방향 조정 경험은 현재 목표, 이미 완료한 작업, 승인을 기다리는 다음 행동을 보여 줍니다. 사용자가 긴 대화 기록을 읽고 이를 추측하게 해서는 안 됩니다.

실질적인 이점은 불필요한 재시작을 줄이는 것이며, 무제한의 자율성을 제공하는 것이 아닙니다. 변경 사항을 검토할 수 있게 하고 실제로 일어난 일을 정확하게 기록하세요.

새로운 상호작용 요구사항을 만들어 보려면 게임 라이브러리를 둘러보고 검토할 조작 방식 하나를 고르세요. 무엇을 유지하고, 무엇을 바꾸며, 무엇이 승인을 기다려야 하는지 진행 중에도 정확히 말할 수 있을 만큼 범위를 좁히세요.