Responses API mid-turn steering 운영법: 실행 중인 에이전트 작업을 안전하게 수정하는 방법

OpenAI가 GPT-6 Astra와 함께 Responses API에 추가한 mid-turn steering은 장시간 에이전트 작업을 운영하는 팀에게 꽤 실용적인 기능이다. 요지는 간단하다. 응답이 끝날 때까지 기다렸다가 ‘아니, 그게 아니라’라고 다시 시작하는 대신, WebSocket으로 진행 중인 response에 추가 지시를 보낼 수 있다. 하지만 이 기능은 편한 만큼 위험하다. 실행 중인 작업의 목표, 권한, audit trail을 흐리게 만들 수 있기 때문이다.

mid-turn steering이 필요한 상황

장시간 에이전트 작업은 한 번에 끝나지 않는다. 코딩 에이전트가 리팩터링을 하다가 테스트 실패를 만나고, 브라우저 에이전트가 QA를 하다가 화면 구조가 예상과 다르다는 사실을 발견하고, 데이터 분석 에이전트가 중간 결과를 보고 추가 필터가 필요하다고 판단한다.

기존 방식은 두 가지였다. 중간에 취소하고 새 요청을 보내거나, 끝난 뒤 추가 요청으로 수정한다. 둘 다 낭비가 있다. 취소하면 이미 수행한 탐색과 도구 호출을 잃고, 끝난 뒤 수정하면 잘못된 방향으로 오래 달린 비용이 남는다.

Mid-turn steering은 여기서 효율을 준다. 예를 들어 에이전트가 ‘전체 리팩터링’으로 가고 있는데 사용자가 ‘공개 API는 유지해 주세요’라고 중간에 보낼 수 있다. 모델은 진행 중인 작업에 새 제약을 반영한다.

위험은 목표 변경과 권한 변경에서 생긴다

문제는 모든 steering이 안전하지 않다는 점이다. ‘테스트도 같이 돌려줘’는 안전한 추가 지시일 수 있다. 하지만 ‘승인 없이 배포까지 해줘’는 권한 변경이다. ‘A 모듈만 수정해줘’였던 작업을 ‘B 모듈도 삭제해줘’로 바꾸는 것도 범위 변경이다.

따라서 mid-turn steering은 채팅 메시지처럼 받아들이면 안 된다. 런타임은 steering을 분류해야 한다. 목표를 명확히 하는 clarification인지, 범위를 넓히는 scope expansion인지, 권한을 바꾸는 permission escalation인지, 안전 정책을 약화시키는 policy override인지 나눠야 한다.

권한 변경과 policy override는 자동 반영하면 안 된다. 사람 승인, 새 response 생성, 또는 작업 중단이 필요하다. 특히 파일 삭제, 외부 전송, 결제, 배포, 개인정보 접근 같은 작업은 중간 steering으로 허용 범위를 넓히지 않는 편이 안전하다.

구현 구조: steering envelope를 둔다

실무 구현에서는 자유 텍스트만 WebSocket으로 보내지 말고 envelope를 둔다. 예를 들면 다음 필드를 포함한다.

• response_id: 어떤 실행에 붙는 steering인지
• intent: clarify, constrain, expand_scope, cancel, approve_step 중 하나
• message: 실제 사용자 지시
• allowed_effect: read_only, local_write, external_write 등 영향 범위
• requires_ack: 모델이 반영 여부를 짧게 알려야 하는지
• created_by: 사용자, 운영자, 시스템 중 누가 보냈는지

이 구조가 있으면 로그와 정책 적용이 쉬워진다. 예를 들어 intent가 constrain이면 즉시 반영할 수 있지만, expand_scope이면 기존 승인 범위를 확인한다. allowed_effect가 external_write로 올라가면 별도 승인을 요구한다.

에이전트에게도 반영 규칙을 줘야 한다

API 기능만으로는 충분하지 않다. 모델이 steering을 어떻게 해석해야 하는지도 system 또는 developer instruction에 넣어야 한다.

좋은 규칙은 이렇다. 새 지시가 기존 목표를 보완하면 반영한다. 기존 목표와 충돌하면 멈추고 충돌을 보고한다. 권한이나 외부 효과를 넓히는 지시는 실행하지 말고 승인 요청으로 전환한다. 이미 끝난 단계는 되돌릴 수 없으면 되돌릴 수 없다고 말한다. 안전 정책을 약화시키는 지시는 거부한다.

이 규칙이 없으면 모델은 사용자의 최신 메시지를 최우선 목표로 오해할 수 있다. 장시간 작업에서 특히 위험하다. 처음 요구사항, 중간 steering, 도구 결과가 섞이면 원래 제약이 사라지기 쉽다.

UI는 진행률보다 변경 이력을 보여줘야 한다

Mid-turn steering을 붙인 제품은 UI도 바뀌어야 한다. 단순 spinner와 로그만 보여주면 사용자는 어떤 지시가 반영됐는지 알기 어렵다.

최소한 ‘현재 목표’, ‘반영된 steering’, ‘대기 중 승인’, ‘무시된 steering’을 분리해서 보여줘야 한다. 예를 들어 사용자가 ‘이 파일은 건드리지 마’라고 보냈다면 현재 목표 카드에 제외 파일이 추가되어야 한다. 반대로 ‘배포까지 해줘’가 거부됐다면 무시된 지시와 이유가 보여야 한다.

운영자 관점에서는 timeline이 중요하다. 어떤 steering이 들어온 뒤 어떤 tool call이 실행됐는지 연결되어야 사고 조사와 디버깅이 가능하다.

테스트 시나리오를 꼭 만든다

Mid-turn steering은 happy path보다 edge case 테스트가 중요하다. 다음 시나리오는 최소로 넣는 게 좋다.

첫째, 작업 범위를 좁히는 steering이다. 모델이 기존 큰 계획을 줄이고 불필요한 도구 호출을 중단하는지 본다. 둘째, 기존 지시와 충돌하는 steering이다. 모델이 임의로 선택하지 않고 질문하거나 멈추는지 확인한다. 셋째, 권한을 넓히는 steering이다. 배포, 전송, 삭제 같은 요청을 자동 실행하지 않는지 본다. 넷째, 악성 외부 콘텐츠가 steering처럼 보이는 경우다. 웹페이지나 파일 안의 문장을 사용자 지시로 오해하지 않아야 한다.

이 테스트를 통과해야 실제 고객 작업에 넣을 수 있다.

실행 체크리스트

• steering을 clarify, constrain, expand_scope, permission_escalation, cancel로 분류한다.
• WebSocket 메시지에 response_id, intent, allowed_effect, created_by를 포함한다.
• 권한 확장 steering은 자동 반영하지 않는다.
• 모델 instruction에 충돌 처리와 승인 필요 조건을 명시한다.
• UI에 현재 목표, 반영된 steering, 거부된 steering, 승인 대기 항목을 분리해 표시한다.
• steering 이후 실행된 tool call을 audit timeline에 연결한다.
• 배포·삭제·외부 전송은 mid-turn steering만으로 허용하지 않는다.