이번 주에는 Claude Sonnet 5.5와 GPT-6.1 Sol이 잇달아 공개됐습니다. 새 모델이 나오면 가장 먼저 성능표와 가격표를 보게 됩니다. 하지만 실제 도입을 결정하려면 한 가지 질문이 더 필요합니다. 우리의 어떤 작업을 맡겼을 때, 검토까지 끝난 결과를 더 적은 비용과 시간으로 얻을 수 있는가?

OpenAI의 Decisions API와 GitHub Agentic Workflows 업데이트까지 함께 고른 이유도 여기에 있습니다. 업무에 모델을 붙이면 어떤 판단을 맡길지, 그 판단으로 어떤 행동까지 허용할지도 정해야 합니다. 이번 호는 네 소식을 다음 세 질문으로 읽습니다.

| 단계 | 판단할 질문 | 해당 소식 | | --- | --- | --- | | 모델 선택 | 같은 성공 기준을 충족하면서 비용과 검토 시간을 줄이는가? | Sonnet 5.5, GPT-6.1 Sol | | 판단 범위 | 무엇을 결정하게 하고, 언제 보류하게 할 것인가? | Decisions API | | 실행 경계 | 어디까지 행동하게 하고, 결과는 어떻게 점검할 것인가? | GitHub Agentic Workflows |

조사 범위는 한국 시간 9월 25~30일입니다. 아래의 ‘공식 확인’은 해당 발표·문서에서 내용을 확인했다는 뜻입니다. 공급사의 성능 주장을 독립 재현하거나 실제 기능을 직접 테스트한 것은 아닙니다.

1. Sonnet 5.5: 가격표가 같아도 작업 비용은 달라질 수 있다

PROOF LEVEL 03 · 공식 확인

사실 요약

Anthropic은 9월 28일 Claude Sonnet 5.5를 발표했습니다. 표준 가격은 100만 토큰당 입력 2달러·출력 10달러·캐시 읽기 0.20달러로 Sonnet 5와 같습니다. 회사는 토큰 사용량 감소로 자사 테스트에서 작업당 비용이 최대 30% 줄었으며, 출력 생성 속도는 30% 이상 빨라졌다고 설명합니다. 전체 업무 완료 시간이 같은 비율로 줄었다는 뜻은 아닙니다. 공식 발표

개발자에게 중요한 점

공식 발표는 기존에 thinking을 끄고 사용했다면 Sonnet 5.5로 이전하기 전에 between_tools 설정으로 바꾸도록 안내합니다. 기존에 추론을 끈 호출은 모델명만 교체해서 이전하면 안 되는 경우가 있습니다.

Lee's Take

지난 호의 Opus 5.5가 복잡한 작업을 위한 선택지였다면, 이번 Sonnet은 반복되는 일상 업무를 옮길 후보입니다. 다만 호출비가 줄어도 재시도나 사람의 수정이 늘면 작업 전체는 더 비싸질 수 있습니다. 모델·도구 비용과 실패 복구·최종 검토 시간을 함께 봐야 하는 이유입니다.

이번 주 해볼 일

  • 같은 버그 수정 작업과 성공 기준으로 완료율·재시도 포함 총 호출비·재시도 횟수·사람 검토 시간을 비교합니다.
  • thinking 설정을 사용하는 호출은 공식 마이그레이션 문서와 대조합니다.

원문: Anthropic — Introducing Claude Sonnet 5.5

2. GPT-6.1 Sol: 같은 계열에서도 다시 평가해야 할 이유

PROOF LEVEL 03 · 공식 확인

사실 요약

OpenAI는 9월 29일 DevDay에서 GPT-6.1 Sol을 공개했습니다. 표준 API 기본 단가는 100만 토큰당 입력 2달러·출력 10달러로 GPT-6 Sol과 같습니다. 달라진 것은 캐시 입력 단가로, 0.20달러에서 0.10달러로 50% 낮아졌습니다. 긴 입력 등 별도 요금 조건은 모델 문서를 확인해야 합니다. GPT-6.1 Sol 가격 · GPT-6 Sol 가격

회사는 코딩·컴퓨터 사용·전문 업무 평가의 개선도 보고했습니다. 이는 공급사가 공개한 평가 결과이며, L-Proof가 재현한 결과는 아닙니다. DevDay 발표 · 모델 소개

개발자에게 중요한 점

공식 소개의 사실 오류 평가는 과거 오류가 신고된 어려운 질문을 모은 것입니다. 그 수치를 일반 사용 환경의 오류율로 해석하면 안 됩니다. 평가 대상과 실제 서비스 입력의 차이를 먼저 살펴야 합니다.

Lee's Take

이번 변화는 기존 평가 세트를 다시 돌릴 이유가 됩니다. 다만 실패했던 작업만 재평가하면 새 모델이 기존 성공 사례를 망가뜨리는 회귀를 놓칠 수 있습니다. 성공·실패 사례를 함께 비교하고, 캐시 할인은 실제 캐시 입력 비중으로 계산해야 합니다. 전체 호출비가 절반으로 줄었다고 해석할 수는 없습니다.

이번 주 해볼 일

  • 기존 Sol의 성공·실패 작업을 함께 재평가하고, 같은 통과 기준에서 호출비와 사람 검토 시간이 어떻게 달라지는지 기록합니다.
  • 전체 입력 중 캐시 입력 비중을 확인해 예상 비용을 계산합니다.

원문: OpenAI — Introducing GPT-6.1 Sol

3. Decisions API: 에이전트의 다음 행동을 유한한 선택지로

PROOF LEVEL 03 · 공식 확인

사실 요약

OpenAI는 9월 29일 Decisions API를 제한적 프리뷰로 발표했습니다. Luna의 능력을 사용자가 정의한 질문과 유한한 답변 선택지에 집중시키는 구조입니다. 텍스트·이미지 문맥을 받아 분류나 요청 라우팅, 에이전트의 다음 행동 선택에 쓸 답을 제공합니다. 발표 당시 더 넓은 공개는 향후 며칠 내 계획으로 안내됐습니다. 공식 발표

개발자에게 중요한 점

도입하려면 질문뿐 아니라 반환할 답의 목록과 각 답을 받은 뒤의 동작도 정의해야 합니다. 답의 형식이 제한돼도 올바른 선택을 한다는 보장은 없습니다. 현재 확인한 발표만으로 가격·지연·세부 API 계약은 판단하지 않습니다.

Lee's Take

선택지를 유한하게 만들어도 현실의 입력까지 그 안에 들어오지는 않습니다. 애플리케이션에 ‘판단 불가’나 ‘사람 검토’ 같은 보류 경로를 두길 제안합니다. API의 기능 보장과는 별개로, 모델이 적절한 시점에 보류하는지도 평가해야 합니다.

이번 주 해볼 일

  • 현재 워크플로의 분기 하나를 골라 선택지별 기준과 예시, 보류된 요청을 받을 담당자를 정합니다.
  • 애매한 입력을 자동 처리로 잘못 보내는 경우와, 정상 요청을 불필요하게 보류하는 경우를 나누어 기록합니다.

원문: OpenAI — DevDay 2026 Recap, Decisions API

4. GitHub Agentic Workflows: 실행 경계와 감사 결과를 함께 점검하라

PROOF LEVEL 03 · 공식 확인

사실 요약

GitHub Agentic Workflows의 9월 28일 주간 정리는 9월 27일 나온 v0.89.22를 소개합니다. Docker sbx·gVisor 런타임이 제거됐습니다. 기존 workflow frontmatter의 sandbox.agent.runtime에 docker-sbx나 gvisor를 명시했다면 다음 컴파일 전에 cloud-hypervisor로 변경해야 합니다. 또한 network.hosted-web으로 AWF 네트워크 경계 밖에서 동작하는 공급자 호스팅 웹 도구의 도메인 허용·차단 정책을 지정할 수 있습니다.

감사 기능도 보강됐습니다. gh aw audit --group은 감사 결과를 실행별·코드별로 묶어 발생 횟수를 보여주며, 감사 보고에 MCP payload 크기 정보도 추가됐습니다. 공식 주간 정리

개발자에게 중요한 점

로컬 실행 환경의 방화벽과 공급자 측 웹 도구가 따르는 정책은 구분해서 확인해야 합니다. 이 변경은 github/gh-aw에 관한 것으로, 모든 GitHub Actions나 Copilot 환경이 같은 방식으로 바뀌었다는 뜻은 아닙니다.

Lee's Take

실행 전에는 허용 범위를 정하고, 실행 후에는 그 경계가 의도대로 작동했는지 확인해야 합니다. 감사 결과의 집계는 반복되는 문제를 찾는 데 도움이 될 수 있지만, 실행 결과의 정확성은 별도로 확인해야 합니다.

이번 주 해볼 일

  • gh-aw 사용자라면 기존 런타임 설정과 호스팅 웹 도구 사용 여부를 확인합니다.
  • 허용·차단 도메인을 각각 호출해 정책 적용을 확인하고, 해당 실행의 감사 결과도 함께 살펴봅니다.

원문: GitHub Agentic Workflows — Weekly Update, September 28, 2026

새 모델이 나왔다고 전체 워크플로를 옮길 필요는 없습니다. 먼저 맡길 작업과 성공 기준을 정하고, 그 기준을 통과한 결과를 얻기까지 호출비와 사람의 시간이 얼마나 드는지 비교합니다. 이어서 모델이 결정할 범위와 보류할 조건을 정하고, 실제 행동에는 별도의 권한 경계를 둡니다. 실행 뒤에는 결과와 기록을 대조합니다.

이번 네 소식을 함께 보면 질문은 ‘어떤 모델이 가장 좋은가’에서 끝나지 않습니다. 맡길 작업, 판단할 범위, 실행할 권한을 나누고 각각을 검증하는 것. 모델을 바꾸기 전에 먼저 해볼 일입니다.