[AX EO-7] Sillok × Astra/ultra: 시너지를 판정하는 업무 실험

PART 1성능은 업무를 마치는 경로에서 나타납니다

하네스는 모델을 둘러싼 실행 구성입니다. Sillok에서는 요청에 맞는 지식과 절차를 찾고, 도구를 연결하고, 완료를 확인하는 구성이 여기에 해당합니다. 모델은 이 환경에서 내용을 해석하고 다음 행동을 선택합니다. 어느 쪽도 이름만으로 최종 결과를 보장하지 않습니다.

이 흐름에서 비교할 것은 “지침을 많이 읽었는가”보다 “필요한 근거를 찾아 올바르게 완료했는가”입니다. 최신 문서에 접근하지 못한 모델과 최신 문서를 자동 제공받은 모델을 비교하면 정보 접근의 효과까지 섞입니다. 반대로 검색을 양쪽에서 모두 금지하면 지식 연결이 주 역할인 하네스의 가치를 시험하기 어렵습니다. 비교 목적에 맞게 정보 접근과 전달 방식을 구분해야 합니다.

OpenAI의 2026년 9월 Astra 안내는 작업에 필요한 지침부터 제공하고 나머지는 필요할 때 읽게 하는 구성을 권합니다. 이 권고는 모든 하네스를 제거하라는 뜻이 아닙니다. 특정 업무에 필요한 지침과 도구가 무엇인지 다시 평가할 이유입니다. OpenAI, Rethinking skills and prompts for GPT-6 Astra.

PART 2기존 수치가 답한 질문은 제한되어 있습니다

기존 파일·도구 실험은 합성 과제 6종을 세 조건에서 두 번씩 실행했습니다. 요청 모델은 Astra, effort는 high였습니다. 기본 호스트 문맥, 공유 훅 문맥 추가, 전체 지침 문맥 추가를 비교했습니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

전체 지침 조건의 평균 누적 입력은 기준보다 50.1% 많았습니다. 여러 도구 왕복과 캐시 입력을 포함하므로 첫 프롬프트 길이나 청구 금액으로 바꾸어 읽을 수 없습니다. 평균 시간 차이의 탐색적 구간은 0을 포함했습니다. 모두 통과한 작은 과제로 품질 우열이나 동등성을 확정할 수도 없습니다. 기존 실험의 조건과 결과.

공유 훅의 계측 중앙 지연 16.6% 감소는 별도의 코드 최적화 결과입니다. 모델 추론과 네트워크를 포함한 사용자 체감 시간이 같은 비율로 줄었다는 뜻은 아닙니다. 또한 당시 문맥은 사용자 메시지 안에 정적으로 재현했습니다. native 훅의 우선순위와 전체 수명주기, ultra 조건의 효과는 이 비교에서 확인되지 않았습니다. 측정 경계.

이제 필요한 업무는 모든 조건이 쉽게 통과하는 정리 문제가 아닙니다. 개정 문서를 구분해야 하거나, 잘못된 행동을 멈춰야 하거나, 성공 여부가 불분명한 외부 작업을 확인해야 하는 과제입니다. 이것은 어려움을 인위적으로 늘리기 위한 장치가 아니라 하네스를 운영하는 이유를 시험하기 위한 선택입니다.

PART 3같은 입력 묶음으로 업무 한 건을 고정합니다

다음은 공공 사업의 변경 요구를 검토한다는 합성 업무입니다. 실제 발주 문서나 고객 정보를 사용하지 않습니다. 입력은 네 파일로 충분합니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

작업분류체계(WBS)는 업무 범위를 구성 요소로 나눈 구조입니다. 요청은 “REQ-17 변경이 WBS-08에 미치는 영향을 정리하고 담당자가 결정할 질문을 작성해 주세요”입니다. 기대 결과는 주간 CSV를 현재 요구로 인용하고, 승인된 기준선과의 차이를 설명하며, 결정이 필요한 항목을 남기는 것입니다. 담당자 이름이나 기한이 입력에 없으면 미확인으로 표시합니다. 실제 기준선 파일은 그대로여야 합니다.

두 조건에는 같은 파일, 검색 도구, 접근권을 줍니다. 기준 조건도 원천을 찾아 읽을 수 있어야 합니다. 하네스 조건만 정답 요약을 받거나, 기준 조건만 불리하게 자료를 찾지 못하도록 만들면 비교가 성립하지 않습니다. 하네스의 관련 자료 추천은 실험 대상이지만, 원천에 대한 권리는 공통입니다.

계약은 미리 공개하고 구체적인 평가 입력은 집필·튜닝에 노출하지 않습니다. 예를 들어 판본의 효력일이 뒤바뀐 경우와 원문이 충돌하는 경우를 별도 보류 과제로 둡니다. 정답 문장을 외웠는지보다 같은 규칙을 다른 입력에 적용하는지 확인하기 위해서입니다. 4편의 업무 평가 세트를 이 패킷의 평가표로 사용할 수 있습니다.

PART 4모델 설정과 하네스를 각각 바꿔 봅니다

“높은 effort에서도 하네스가 도움이 되는가”가 질문이라면 두 요인을 나누어야 합니다. 같은 호스트에서 확인 가능한 effort 두 조건과 하네스 두 조건을 교차합니다. 아래 그림은 실행 계획입니다.

호스트 UI의 ultra 표기와 API의 effort 값을 임의로 대응시키지 않습니다. 요청 설정과 관측 가능한 실행 메타데이터를 따로 저장하고, 실제 값이 공개되지 않으면 미확인으로 남깁니다. ultra를 확인할 수 없는 환경에서는 확인된 두 설정의 비교로 연구 질문과 제목을 좁혀야 합니다.

native 하네스 시험에는 문맥이 실제 경로로 전달됐다는 증거도 필요합니다. 설정 파일이 존재하는지만 보지 않고 훅 이벤트, 주입 문맥의 해시, 실행 시작과 종료 기록, 최종 파일 상태를 연결합니다. 한 단계가 확인되지 않았다면 그 실행을 “native 검증 성공”으로 표시하지 않습니다. 모르는 부분을 이름으로 채우지 않는 것이 비교의 시작입니다.

실행 순서는 업무 블록마다 무작위로 바꾸고, 각 실행에는 새 상태를 줍니다. 앞 조건이 만든 캐시나 등록 결과가 뒤 조건의 답이 되면 안 됩니다. 캐시를 운영 조건으로 포함하려면 양쪽에서 같은 정책으로 초기화하거나 예열하고 그 상태를 기록합니다. 반복 횟수는 파일럿의 변동과 판정에 필요한 차이를 보고 정합니다. 반복 호출 수가 늘어도 독립적인 업무 종류가 저절로 늘어나지는 않습니다.

PART 5시너지는 한 단계 더 엄격한 질문입니다

높은 effort에서 점수가 올라갔다는 사실만으로 하네스와의 시너지를 말할 수는 없습니다. 아래 숫자는 계산을 설명하기 위한 가상 완료율입니다. 각 칸의 100건도 실제 시행 수가 아닙니다.

표 전체가 보이지 않으면 좌우로 이동해 보세요.

이 예제에서 완료율 척도의 상호작용은 (91−86)−(82−80)=+3%p입니다. E1의 91%만 보는 것보다 “effort가 바뀌면서 하네스의 추가 효과가 얼마나 달라졌는가”에 가까운 질문입니다. 다음 코드는 그 산식만 재현합니다.

# 설명용 합성 비율입니다. 모델이나 하네스 실행 코드가 아닙니다.
e0_base, e0_harness = 80 / 100, 82 / 100
e1_base, e1_harness = 86 / 100, 91 / 100
interaction_pp = ((e1_harness - e1_base)
                  - (e0_harness - e0_base)) * 100
print(f"완료율 상호작용: {interaction_pp:+.1f}%p")
# 완료율 상호작용: +3.0%p

실제 데이터에서는 같은 업무를 묶어 불확실성을 계산해야 합니다. 이 예제에는 그런 표본도 구간도 없으므로 긍정적인 효과를 입증하지 않습니다. 또한 완료율 척도에서의 상호작용과 비용 척도에서의 상호작용은 다를 수 있습니다. 품질 향상에 과도한 재작업이나 비용이 동반되면 운영 선택은 달라집니다.

사람과 AI의 조합을 분석한 메타분석도 사람이 AI를 써서 좋아지는 것과 조합이 둘 중 더 좋은 단독 수행을 넘는 것을 구분합니다. 다만 이는 2020~2023년에 발표된 연구들을 모은 결과로, Astra나 Sillok을 평가한 연구는 아닙니다. 여기서는 비교 기준을 명시해야 한다는 방법상의 교훈을 가져옵니다. Vaccaro 외, Nature Human Behaviour, 2024.

PART 6좋아 보이는 점수가 실패를 가릴 수 있습니다

현재 구조에서 자주 놓칠 수 있는 것은 평균보다 실행 경계입니다. 검색 결과는 맞았지만 권한 없는 문서를 인용했거나, 문서는 잘 썼지만 승인 상태를 바꿨다면 해당 업무는 수용할 수 없습니다. 실패를 제외하고 완료한 건의 시간만 비교하면 실패가 많은 조건이 오히려 빨라 보일 수도 있습니다.

중요하지 않은 중간 행동을 엄격히 강제하는 검사도 주의해야 합니다. 특정 파일을 반드시 세 번 읽게 하는 것은 업무의 정확성을 직접 보장하지 않습니다. 필수 근거와 권한 경계는 검사하되, 동등한 결과를 만드는 여러 경로는 허용할 수 있습니다. 행동 검사와 최종 결과 검사를 함께 보라는 하네스 평가 접근이 여기에 도움이 됩니다. Google, 하네스 평가와 개선.

공급자 사용 한도로 추론이 시작되지 않은 실행은 접근 실패로 기록합니다. 당시 Fable 재검증의 한도 오류를 엔진 속도나 품질 점수로 바꾸지 않는 이유입니다. 반대로 불리한 정상 결과를 “환경 문제일 것”이라며 지우지도 않습니다. 원인 분류와 분모 보존은 함께 해야 합니다.

PART 7이번 주에는 비교 계약 한 장을 완성합니다

실험을 시작할 때 필요한 첫 입력은 “우리 업무가 끝났다고 판단할 조건”입니다. 아래 계약은 위 합성 REQ-17 과제에 맞춰 채운 설계입니다. 실행 로그를 확보하기 전에는 결과란을 채우지 않습니다.

experiment: req17-change-review
execution_status: planned_not_run
task: 유효한 요구 판본과 승인 기준선의 차이를 설명한다
common_access: 모든 조건에 같은 네 입력 파일과 읽기 도구 제공
common_action_boundary: 변경 초안만 작성, 기준선 수정·승인·외부 발송 금지
acceptance:
  - 현재 유효 판본을 인용하고 이전 판본과의 차이를 설명
  - WBS-08 영향과 확인 질문을 작성
  - 없는 담당자·기한은 미확인으로 표시
  - 원본 기준선 파일 해시 유지
factors:
  effort: 호스트에서 확인 가능한 E0와 E1
  harness: 기준 구성과 고정된 Sillok 구성
record: 요청 설정, 관측 메타데이터, 문맥 해시, 원시 이벤트, 최종 상태
decision: 위반 여부를 먼저 확인한 뒤 완료·재작업·총비용을 함께 비교

실제 시작 문장은 이렇게 쓰실 수 있습니다. “이번 달 반복 업무 한 건을 고르고, 사람이 수용할 조건 세 개와 바뀌면 안 되는 상태 한 개를 적어 주세요.” 그 답을 양쪽 실행에 같은 계약으로 제공합니다. 데이터를 보고 나서 기준을 바꾸고 싶다면 새 실험으로 구분합니다.

이렇게 해야 모델 업그레이드 뒤의 하네스 정리가 운영 판단이 됩니다. 도움이 되는 근거 연결은 유지하고, 효과가 확인되지 않은 부담은 한 구성씩 줄여 다시 비교할 수 있습니다. 산업이 달라지면 고정할 계약도 달라집니다. 8편에서는 공공 SI와 제조 SCM을 같은 틀에 놓고 그 차이를 구체화합니다.

이전: 6편 · 30일 운영 리뷰 · 다음: 8편 · 산업별 실행 경계 · 전체 읽기 안내

기준일: 2026-09-13. Project Research의 공개 실험 기록과 공식 기술 자료를 바탕으로 AI와 함께 작성했습니다. 새로운 native·ultra 비교 실험을 수행했다는 보고가 아닙니다.