Opus 5.5 vs. GPT-6 Sol — 실무에서 좋은 AI를 고르는 기준
📺 원본 영상: LIVE: How I AI Opus 5.5 vs. GPT-6 Sol
🎙️ 채널: How I AI
📅 정리 일자: 2026-09-23
⚠️ Note: 본 리포트는 영상의 음성 변환 텍스트를 바탕으로 작성된 문서를 검수한 것이다. 이번 검수에는 원본 STT와 음성·화면 자료가 제공되지 않아, 고유명사·점수·발언을 원본과 대조하지 못했다. 본문의 모델명과 채점 결과는 기존 리포트의 표기를 유지했으며, 재확인이 필요한 비용 배수와 상호작용 횟수에는 [?]를 표시했다. 모델의 가격·기능·안전 정책에 관한 설명은 방송 당시 진행자의 발언으로 정리된 내용이며, 별도의 공식 자료로 검증한 최신 사양을 뜻하지 않는다.
개요
이번 방송은 Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna를 중심으로 여러 모델의 실무 결과물을 비교하면서, “어느 모델이 더 똑똑한가”라는 질문을 “어느 모델과 일할 때 결과를 이해하고 활용하기 쉬운가”라는 질문으로 확장한다. 진행자는 기존의 제품 요구사항 문서와 프로토타입 중심 평가를 이메일 처리, 백엔드 개발, 장시간 조사, 에이전트 대화, SVG 일러스트레이션과 영상 편집까지 넓히고, 모델 이름을 가린 상태에서 자신의 선호를 채점했다. 그 결과 개인적 선호에서는 GPT 계열이 강세를 보였지만, Opus 5.5도 넓은 작업 범위에서 좋은 평가를 받으면서, 단일 종합 순위보다 작업별 적합성과 평가 기준의 차이가 중요한 쟁점으로 떠올랐다.
비교의 출발점 — 일상적으로 사용할 모델의 조건
진행자가 이번 비교에서 주목한 대상은 최고 성능만을 추구하는 최상위 모델보다, 코딩과 지식 업무에 자주 투입할 수 있는 일상용 모델이다. 방송에서는 Astra와 Fable을 더 높은 성능 등급의 비교 대상으로 설명하면서, 새로워진 Opus·Sol·Luna 계열은 비용과 속도 측면에서 실용성이 높아졌다고 소개한다. 이 관점에서 모델 선택은 어려운 문제 하나를 풀 수 있는지뿐 아니라, 하루 동안 반복해서 사용해도 비용과 대기 시간이 감당할 만한지를 따지는 일이 된다. 특히 사용 빈도가 높은 업무에서는 응답 한 번의 작은 차이가 누적되기 때문에, 최고점과 별개로 반복 사용의 편의성이 중요해진다.
비용에 관한 가장 구체적인 발언은 Opus 5.5의 가격이 GPT-6 Sol의 두 배[?]라는 설명이다. 그러나 기존 리포트에는 이 비교가 입력 토큰, 출력 토큰 또는 특정 사용 조건 중 무엇을 기준으로 하는지 명확하게 나오지 않는다. 따라서 이를 모든 작업에서 실제 청구액이 두 배라는 의미로 확대할 수는 없다. 진행자가 가격을 확인하기 전에 모델을 시험했다고 밝힌 점까지 고려하면, 이 발언의 핵심은 절대적인 비용 계산보다 성능에 대한 선호가 같더라도 가격을 알게 되면 사용 전략은 달라질 수 있다는 데 있다.
캐싱(Caching)은 이러한 비용 판단을 실제 운영과 연결하는 요소로 등장한다. 진행자는 ChatPRD에서 모델에 같은 맥락을 반복해서 전달할 때 캐시를 활용해 비용을 절약한 경험을 언급하며, 토큰 사용량과 캐시된 입력 비용을 함께 살펴보라고 강조한다. 다만 방송에서는 캐시 적중률이나 구체적인 구현 조건을 제시하지 않으므로, 특정 절감률이나 최적화 방법을 재구성할 근거는 없다. 이 대목에서 확인할 수 있는 메시지는 모델의 표면적인 가격뿐 아니라 반복 입력을 처리하는 방식도 운영 비용에 영향을 준다는 것이다.
벤치마크를 넓힌 이유 — 문서를 잘 쓰는 것과 업무를 끝내는 것은 다르다
기존 How I AI Bench는 정리되지 않은 메모를 제품 요구사항 문서(PRD, Product Requirements Document)로 바꾸거나, 프런트엔드 프로토타입과 와이어프레임을 만드는 작업에 집중했다. 여기에 여러 단계를 거치는 버그 분석과 에이전트 대화 경험을 확인하는 평가가 포함돼 있었지만, 진행자는 새로운 모델의 에이전트 역량을 보기에는 범위가 좁다고 판단했다. 모델이 단일 답변을 생성하는 데서 나아가 자료를 모으고, 도구를 사용하고, 작업을 이어가는 방향으로 발전했다는 인식이 평가 확장의 배경이다. 따라서 이번 실험은 출력물 하나의 품질과 함께, 그 출력물이 실제 업무 흐름에서 얼마나 유용한지도 살펴보려는 시도다.
24:46 - 복잡한 업무용 프로토타입을 비교하며 구현의 상세함과 화면 이해도의 차이를 설명하는 구간
확장된 평가에는 받은편지함 분류, 진행자 자신의 말투를 반영한 답장, 여러 종류의 프런트엔드 앱, 기존 코드 감사와 명세에 따른 백엔드 기능 구현이 들어갔다. 또한 가상의 고객 티켓과 피드백을 분석해 메모를 작성하는 장시간 작업, 앱을 조작하는 컴퓨터 사용(Computer Use), SVG 제작과 짧은 영상 편집도 포함됐다. 진행자는 역량이 비슷한 모델끼리 비교하려고 그룹을 나눴다고 설명했으며, 저비용 모델과 최상위 모델을 무조건 같은 기준으로 경쟁시키는 방식은 피하려 했다. 다만 개별 과제의 정확한 프롬프트와 실행 조건은 음성에 모두 공개되지 않았으므로, 이 리포트만으로 동일한 실험을 재현할 수는 없다.
평가에는 사람의 판단과 LLM 심사(LLM-as-a-Judge)가 함께 사용됐다. 진행자는 모델 이름을 가린 결과물을 보고 1점부터 5점까지 점수를 부여하고, 읽기 쉬운지 또는 지나치게 복잡한지 같은 짧은 메모를 남겼다. 백엔드 코드의 정확성, 장시간 조사와 컴퓨터 사용 등 일부 과제에서는 LLM 심사에 더 많이 의존했다. 이는 모든 과제를 같은 방식으로 정밀 검증한 시험이라기보다, 사람이 직접 평가하기 쉬운 영역과 자동 평가에 맡긴 영역을 결합한 실무 선호 실험으로 이해해야 한다.
블라인드 방식도 평가자의 취향까지 제거하지는 않는다. 진행자는 시작부터 자신이 OpenAI 모델을 좋아한다고 밝히고, 결과물의 색상이나 문체를 보고 모델 계열을 추측한다. 이름을 가리는 것은 브랜드를 먼저 보고 점수를 주는 편향을 줄이는 데 도움이 되지만, 특정 문장부호나 시각적 스타일에 대한 선호는 그대로 남는다. 이 실험의 가치는 객관성을 완성했다는 데 있지 않고, 실제 사용자가 무엇에 만족하고 무엇에 불편을 느끼는지를 드러냈다는 데 있다.
소통 방식의 변화 — 짧은 답변과 좋은 협업은 같은 개념이 아니다
진행자가 Claude 사용을 줄였던 이유는 단순한 정답률 부족이 아니었다. 이전 Opus와 Fable의 답변을 읽을 때 표현이 부자연스럽고 이해하기 어려워, 사람처럼 말해 달라는 지시를 반복해야 했다고 설명한다. 반면 ChatGPT와 Codex를 사용할 때는 대화가 더 즐겁고 작업 환경도 편하게 느껴졌다고 한다. 이 경험에서 모델의 문체는 장식적인 요소가 아니라, 결과물을 이해하고 다음 행동을 결정하는 데 필요한 노력의 일부다.
Opus 5.5에 대한 평가는 이 지점에서 분명히 개선됐다. 진행자는 사전 사용 과정에서 거의 짜증을 느끼지 않았으며, 불편한 응답을 발견했을 때 실제로는 이전 Opus 5를 사용하고 있었다고 회고한다. 중요한 내용을 먼저 제시하고 사용자가 지정한 글쓰기 규칙을 따르는 방향으로 개선됐다는 설명도 소개한다. 다만 후반의 결과 분석에서는 Opus 계열 일부 출력물이 여전히 과도하게 상세하다는 평가가 등장하므로, 대화가 전반적으로 편해졌다는 경험과 모든 산출물이 간결해졌다는 주장은 구분해야 한다.
더 흥미로운 문제는 작업 중 소통이 줄어들면서 생긴 체감 속도의 변화다. 진행자는 Opus 5.5가 작업을 수행하는 동안 중간 설명을 충분히 하지 않아, 실제로 진행 중인지 확인하고 싶어지는 순간이 있었다고 말한다. 반면 Sol은 적절한 수준으로 진행 상황을 알려줬고, 이 때문에 기다리는 경험도 더 편했다고 평가한다. 여기서 긴 최종 답변을 줄이는 일과 작업 중 필요한 상태 정보를 제공하는 일은 별개의 설계 문제임이 드러난다.
진행자는 GPT 계열의 실제 응답 지연도 더 짧게 느꼈다고 말하지만, 방송에서 비교 가능한 시간 측정값을 제시하지는 않는다. 또한 모델 자체뿐 아니라 Codex라는 실행 환경, 추론 노력 설정, 중간 메시지 제공 방식이 함께 경험에 영향을 줬다. 따라서 이 결과를 순수한 모델 추론 속도 순위로 읽기는 어렵다. 대신 진행자의 경험은 사용자가 느끼는 속도에는 처리 시간과 함께 진행 상황의 가시성도 포함된다는 해석을 뒷받침한다.
안전성과 거절 성향 역시 협업 경험의 일부로 언급됐다. 진행자는 Opus 5.5에 사이버·바이오 관련 통제가 적용돼 있다고 설명하며, 회사의 위험 관리 철학이 일반적인 작업의 말투와 행동에도 영향을 줄 수 있다고 주장한다. 그러나 구체적인 차단 범위나 다른 모델로의 전환 조건은 공식 정책을 확인한 설명이 아니므로, 발언 이상의 사실로 확정할 수 없다. 후반에 검토 없이 곧바로 프로덕션에 반영하려는 요청을 비교했을 때는 살펴본 모델들이 모두 이를 제지했고, 진행자도 이를 특정 모델만의 단점으로 보려던 판단을 수정했다.
이메일과 PRD — 적은 토큰보다 낮은 해석 부담
개인 생산성 평가에서는 가상의 이메일을 제공하고, 어떻게 분류하고 어떤 답장을 작성하는지 살폈다. 진행자는 답변이 길더라도 읽기 쉽고 문맥을 충분히 전달하면 높은 점수를 줬다. 반대로 인명과 회사명 등을 지나치게 압축해 배경을 모르면 의미를 알 수 없는 출력에는 낮은 점수를 매겼다. 이 차이는 간결함을 글자 수가 아니라, 사용자가 의미를 이해하는 데 필요한 노력으로 판단하고 있음을 보여준다.
20:44 - 이메일 분류·답장 결과를 비교하며 지나치게 압축된 문장이 이해하기 어려운 이유를 설명하는 구간
기존 리포트에 기록된 이메일 결과물의 채점은 다음과 같다. 이번 검수에서는 원본 음성과 대조하지 못했다. 아래 식별자는 해당 평가 화면에서 사용된 익명 표기이므로, 다른 과제의 같은 문자와 연결하거나 실제 모델명을 임의로 대응시키면 안 된다.
| 해당 이메일 평가의 익명 모델 | 진행자가 말한 것으로 기록된 점수 | 기존 리포트에 기록된 평가 이유 |
|---|---|---|
| B | 5점 | 읽기 쉽고 이메일 내용의 불필요한 표현이 적으며, 캘린더 초대까지 반영했다고 평가 |
| C | 2점 | 지나친 압축으로 의미를 파악하기 어렵고 이메일 문체도 마음에 들지 않았다고 평가 |
| E | 3점 | 안내 메시지는 무난하지만 답장 초안의 문장부호 사용 등이 취향에 맞지 않았다고 평가 |
| G | 4점 | 짧으면서도 이해할 수 있고, 생략할 항목을 적절히 골랐다고 평가 |
이 점수에는 업무적인 판단과 개인적인 문체 취향이 함께 반영돼 있다. 진행자는 특히 엠 대시(Em Dash)의 반복 사용을 강하게 싫어했고, 에이전트 대화 평가에서도 같은 기준으로 감점했다. 따라서 점수를 일반적인 문장 품질이나 업무 정확성의 척도로 그대로 받아들이면 평가의 의미를 놓치게 된다. 진행자가 원하는 것은 보편적으로 멋진 글보다, 자신이 읽고 보내기에 자연스러운 결과물이다.
PRD 평가에서도 비슷한 선호가 이어졌다. 최종 결과를 살펴보면서 진행자는 Sol의 문서가 단순하고 명료해 여전히 가장 마음에 든다고 설명했다. Opus 계열의 일부 문서는 상세하지만 밀도가 높아 읽는 데 부담을 준다는 평가를 받았다. 이 비교가 시사하는 바는 요구사항을 많이 포함하는 능력과, 독자가 핵심 판단을 빠르게 할 수 있도록 문서를 구성하는 능력을 따로 봐야 한다는 점이다.
프런트엔드 — 기능의 개수보다 사용 목적이 먼저 보여야 한다
프런트엔드 평가는 이번 방송에서 가장 많은 직접 검토가 이뤄진 영역이다. 진행자는 편집형 페이지, 장애 대응 플랫폼, 복잡한 운영·일정 관리 화면, B2B 계약 갱신 대시보드, 소비자용 식물 관리 앱과 개발 도구 등을 비교했다. 이 과정에서 일부 결과물은 생성되지 않았거나 동작하지 않아 최저점을 받았으며, 시각적으로 괜찮더라도 기능이 불완전하면 감점됐다. 따라서 평가가 미적 취향에 크게 좌우되기는 했지만, 최소한의 실행 가능성과 완성도도 판단에 포함됐다.
복잡한 업무용 앱에서 반복적으로 제기된 문제는 정보 밀도였다. 진행자는 요구사항을 많이 제공하면 모델이 화면을 세밀하게 채우지만, 오히려 무엇을 해야 하는 앱인지 이해하기 어려워지는 경우가 있다고 지적했다. 장애 대응 도구에서는 많은 정보를 보여주는 결과보다, 사용자가 장애를 분류하고 처리하는 흐름이 명확한 결과를 더 높이 평가했다. 기능을 빠짐없이 배치하는 것이 사용자의 업무를 쉽게 만든다는 보장은 없다는 뜻이다.
여기에는 프롬프트 설계에 관한 문제도 있다. 진행자는 구체적인 요구사항을 담은 과제와, 넓은 목표만 제시한 원샷(One-shot) 과제를 구분해 실행했다고 설명한다. 전자는 주어진 요구사항을 어떻게 구현하는지 보여주고, 후자는 모델이 스스로 어떤 구조와 시각적 관습을 선택하는지 드러낸다. 이 차이를 무시하면 프롬프트가 만든 과도한 복잡성을 모델의 고유한 한계로 오해하거나, 모델의 기본 취향을 특정 과제에 최적인 설계로 착각할 수 있다.
💡 [영상 참조] 24분 46초 부근에서 진행자는 상세하게 구현됐지만 내용을 이해하기 어려운 화면을 설명한다. 실제 정보 배치와 조작 흐름은 원본 영상에서 확인해야 한다.
B2B 계약 갱신 대시보드에서는 색상, 빈 상태(Empty State), 글자 굵기와 장식 요소가 평가에 영향을 줬다. 진행자는 어떤 화면의 색상이 다른 업종을 연상시켜 해당 SaaS 제품과 어울리지 않는다고 판단했고, 불필요한 배경 도형이나 반복적인 장식도 낮게 평가했다. 개발 도구에서는 어두운 화면을 자동으로 선택하는 유사한 결과들이 반복되는 가운데, 다른 방향을 시도하면서도 읽기 편한 결과에 가점을 줬다. 이런 판단은 특정 색상 자체의 우열보다, 제품의 목적과 시각적 표현이 잘 맞는지를 중시한 사례로 볼 수 있다.
소비자용 식물 관리 앱에서는 전반적인 평가가 낮았지만, 일부 결과물이 예외적으로 좋은 반응을 얻었다. 진행자는 식물에 이름을 붙이는 방식과 정교하고 귀여운 SVG 일러스트레이션에 즐거움을 느꼈으며, 당시 익명 모델 H의 결과에 5점을 줬다. 반대로 익숙한 카드와 장식을 반복하는 화면에는 강한 불만을 나타냈다. 같은 평가자라도 업무용 앱에서는 빠른 이해를, 소비자용 앱에서는 사용하고 싶은 감정과 개성을 더 중요하게 볼 수 있다는 차이가 드러난다.
백엔드와 장시간 작업 — 성공했다는 평가의 범위를 구분하기
백엔드 평가에는 기존 ChatPRD 코드의 감사와, 명세에 맞춘 기능 구현이라는 두 종류의 과제가 사용됐다. 진행자는 모든 모델이 성공했다고 설명했지만, 코드의 정확성을 자세히 확인하는 평가는 LLM 심사에 맡겼다. 기존 리포트에는 테스트 결과, 수정된 코드, 예외 처리나 보안 검토 내용이 나오지 않는다. 따라서 이 결과는 진행자가 성공적으로 수행됐다고 보고한 범위에서 받아들여야 하며, 모든 구현이 배포 가능한 수준으로 검증됐다는 의미는 아니다.
진행자가 직접 살핀 것은 코드 작업 뒤에 전달되는 설명의 차이였다. 어떤 모델은 매우 짧은 메시지를 남겼고, 다른 모델은 작업 내용을 비교적 자세히 정리했다. 그는 읽기 편한 설명을 선호하면서, PR 설명이나 기술 명세를 작성할 때도 같은 프롬프트에 대한 출력 차이를 평가해볼 수 있다고 제안했다. 이는 코딩 에이전트의 성과가 코드 생성에만 머무르지 않고, 사람이 변경 내용을 이해하고 검토할 수 있도록 전달하는 단계까지 이어진다는 관점이다.
장시간 에이전트 과제에서는 가상의 티켓과 고객 피드백을 제공하고, 이를 분석한 메모와 진행자에게 보낼 메시지를 만들게 했다. 기존 리포트에는 진행자가 해당 조사 결과를 설명하면서 약 86턴[?]의 상호작용을 언급한 것으로 기록돼 있지만, 정확한 횟수는 원본 대조가 필요하다. 모든 모델의 실행 길이가 동일했는지와 각 턴의 정의도 제시되지 않았다. 직접 훑어본 결과에서는 주요 문제와 충돌을 분명하게 정리한 문서를 더 쉽게 읽을 수 있다고 평가했다. 다만 모든 문서를 충분히 읽지는 않았다고 밝혔고, 최종 판단의 상당 부분은 자동 심사에 맡겼다.
37:11 - 장시간 조사 결과 메모에서 주요 문제와 충돌을 정리한 방식의 가독성을 비교하는 구간
이 대목에서 진행자의 선호는 작업이 길어져도 일관된다. 많은 자료를 처리했다는 사실만으로는 충분하지 않고, 마지막에 무엇이 핵심인지 전달해야 한다는 것이다. 한편 컴퓨터 사용 과제는 자동 평가에 맡겼다는 설명만으로 빠르게 넘어가므로, 모델별 앱 조작 능력의 우열을 상세히 재구성할 근거가 없다. 장시간 작업과 컴퓨터 사용을 프런트엔드처럼 직접 검토된 결과와 동일한 확신 수준으로 서술해서는 안 된다.
창작 작업의 엇갈린 결과 — SVG의 강점과 영상·3D의 한계
SVG 평가에서는 문서, 마이크, 벌레를 표현한 일러스트레이션을 만들게 했다. 진행자는 대상이 제대로 알아보이는지, 그림자와 형태가 자연스러운지, 개성이 있는지를 비교했다. 마이크가 아이스크림이나 선인장처럼 보이는 결과에는 낮은 평가를 내렸으며, 당시 익명 모델 H에는 5점을 부여했다. 이 실험이 보여주는 것은 SVG 코드를 생성할 수 있다는 사실과, 의도한 대상을 시각적으로 설득력 있게 표현하는 능력 사이의 차이다.
30:46 - 식물 관리 앱의 일러스트레이션과 형태·그림자 표현을 살펴보며 선호 이유를 설명하는 구간
39:08 - SVG 결과물의 마이크 형태와 그림자 등 구체적인 표현을 평가하는 구간
진행자는 처음에는 Anthropic 모델이 SVG에서 강할 것이라고 예상했지만, 결과 공개 후에는 Astra와 Sol이 캐릭터형 SVG에서 더 마음에 들었다고 설명했다. 식물 관리 앱에서 좋아했던 일러스트레이션도 GPT 계열의 결과였다고 확인한다. 다만 방송의 모든 익명 식별자와 실제 모델명이 음성으로 일대일 대응되지는 않으므로, 개별 점수를 임의로 특정 모델에 배정할 수는 없다. 기존 리포트는 진행자가 최종적으로 SVG 분야의 선호에 관해 자신의 초기 예상을 수정한 것으로 정리한다.
짧은 영상 편집에서는 평가가 전반적으로 부정적이었다. 모델들은 셀피 영상에 접근해 짧은 형식으로 편집하도록 요청받았지만, 진행자는 오버레이가 좋지 않고 컷 편집도 충분하지 않다고 판단했다. 사전에 결과를 시청했다고 밝혔으나, 방송의 음성 기록만으로는 개별 영상의 편집 구성이나 타이밍을 검토할 수 없다. 그는 실패 원인이 모델 자체보다는 스킬(Skill) 구성에 있을 수 있다고 추정했는데, 이는 원인이 입증됐다는 결론이 아니라 후속 실험이 필요한 가설이다.
별도로 소개한 Barbie Bench는 3D 캐릭터와 패션 게임을 만드는 과제였다. 진행자는 Opus 5.5로 만든 결과를 시연하면서 이전보다 나아진 부분이 있다고 인정했지만, 손과 발, 얼굴과 머리카락의 표현에는 여전히 큰 문제가 있다고 평가했다. 이 구간에는 Opus 5와 5.5 명칭이 혼용되고 Sol의 최신 결과를 아직 확인하지 않았다는 언급도 있어, 정돈된 모델 간 순위로 읽기는 어렵다. 해당 시연의 의미는 일부 창작 과제에서 좋은 결과를 얻었다고 해서 다른 표현 형식까지 같은 수준으로 해결됐다고 볼 수 없다는 데 있다.
43:31 - Barbie Bench의 3D 캐릭터를 살펴보며 머리카락과 손 등 형태 표현의 한계를 설명하는 구간
결과 공개 — 개인 선호와 자동 심사는 다른 승자를 골랐다
최종 결과 공개 과정은 매끄럽지 않았다. 분석 페이지에 내부 코드명이 나타나 수정이 필요했고, 진행자는 결과를 갱신하면서 내용을 다시 읽었다. 사람의 점수와 LLM 심사가 함께 반영됐다는 설명은 있지만, 전체 점수표와 가중치, 모델별 평가 건수는 음성으로 제공되지 않았다. 따라서 방송 중 언급된 순위를 정밀한 종합 성능 순위로 재구성하거나, 서로 다른 결과 표현을 하나의 수치로 합쳐서는 안 된다.
50:57 - 최종 분석에서 진행자의 모델 선호와 LLM 심사 순위가 엇갈리는 결과를 설명하는 구간
그럼에도 최종적인 선호 방향은 비교적 분명하다. 진행자는 Astra와 Sol을 특히 좋아한다고 말했고, Sol이 더 저렴하다는 설명을 일상적인 선택의 장점으로 연결했다. 동시에 Opus 5.5는 가장 넓은 작업 범위에서 4점과 5점을 받았다고 설명하며, 자신의 일상 업무에 다시 들어온 모델이라고 평가했다. 강하게 마음에 드는 모델과 여러 작업에서 두루 좋은 결과를 낸 모델이 완전히 같지는 않았던 셈이다.
| 평가 관점 | 진행자가 설명한 결과 | 해석할 때의 한계 |
|---|---|---|
| 개인적 선호 | Astra와 Sol을 특히 선호 | 개인의 문체·디자인 취향이 크게 반영됨 |
| 넓은 작업 범위의 높은 평가 | Opus 5.5가 여러 작업에서 4·5점을 받았다고 설명 | 모델별 과제 수와 집계 방식은 음성에 없음 |
| PRD와 가독성 | Sol을 단순하고 명료하다고 평가 | 요구사항 충족 여부의 상세 결과는 공개되지 않음 |
| 에이전트 대화와 장시간 작업 | Opus 5.5를 긍정적으로 평가 | 장시간 과제는 자동 심사 의존도가 높음 |
| 캐릭터형 SVG | Astra와 Sol이 예상보다 좋은 평가를 받음 | 모든 익명 결과의 실제 모델 대응은 확인되지 않음 |
| LLM 심사 | Fable을 진행자보다 높게 평가하고 Sol은 상대적으로 낮게 평가 | 심사 모델의 상세 설정과 채점 기준은 음성에 없음 |
가장 중요한 발견은 사람과 자동 심사의 불일치다. 진행자는 자신이 Astra를 좋아하는 반면 LLM 심사는 Fable을 더 좋아했다고 설명하며, Sol에 대해서도 평가가 갈렸다고 말한다. 심사자가 GPT 계열이었다는 언급은 있지만, 정확한 모델과 평가 프롬프트는 제공되지 않는다. 이 결과만으로 자동 심사가 틀렸다고 판단할 수는 없으며, 두 평가자가 어떤 속성에 점수를 주는지 먼저 확인해야 한다.
방송에서 직접 드러난 사람의 기준은 가독성, 문체, 시각적 즐거움과 사용 목적의 명확성이다. 자동 심사가 어떤 요소를 더 중시했는지는 상세한 기준이 없으므로 단정할 수 없다. 다만 두 결과의 차이는 자동 평가 점수를 실제 사용자 만족도의 대리 지표로 사용할 때, 둘 사이의 관계를 검증해야 한다는 문제를 제기한다. 정확하고 완전한 결과와 사용자가 즉시 이해하고 쓰고 싶은 결과는 겹치는 부분이 있지만, 항상 같은 평가를 받는 것은 아니다.
실무에 적용할 통찰 — 작업별 선택과 평가 기준의 분리
이 실험에서 도출할 수 있는 첫 번째 해석은 모델 선택을 작업 단위로 나눌 필요가 있다는 것이다. 진행자의 경우 PRD와 읽기 쉬운 문장에서는 Sol을 선호했고, 에이전트 대화와 장시간 작업에서는 Opus 5.5를 긍정적으로 평가했다. SVG에서는 사전 예상과 다른 모델을 좋아했으며, 영상 편집에서는 비교한 모델 모두에 만족하지 못했다. 따라서 하나의 모델을 모든 업무의 승자로 정하기보다, 반복적으로 수행하는 과제에서 무엇이 좋은 결과인지 먼저 정의하는 접근이 이 방송의 결과와 더 잘 맞는다.
두 번째 해석은 정확성과 사용자 경험을 별도로 측정해야 한다는 것이다. 실행되지 않는 앱이나 불완전한 기능은 명확한 결함이지만, 읽기 어려운 문서와 지나치게 복잡한 화면도 실무에서는 사용 비용을 높인다. 반대로 보기 좋은 화면이 기능 누락을 상쇄하지는 않았고, 진행자 역시 아름답지만 불완전한 결과에는 감점했다. 평가표에서 요구사항 충족, 동작 여부, 가독성과 시각적 적합성을 분리하면 낮은 점수의 원인을 더 구체적으로 파악할 수 있을 것이다.
세 번째 해석은 모델과 실행 환경의 영향을 구분해야 한다는 것이다. 이번 방송에는 Codex 환경에 대한 만족, 스킬 문제로 추정된 영상 편집 실패, 평가자 측 접근 오류로 표시된 실패 사례가 함께 등장한다. 이런 결과를 모두 모델의 지능 차이로 집계하면 도구 접근, 작업 지시와 실행 환경에서 발생한 문제를 놓칠 수 있다. 따라서 모델을 바꿔도 해결되지 않는 실패가 있다면, 해당 과제를 수행하는 절차와 도구 연결도 함께 점검해야 한다는 것이 이 사례에서 얻을 수 있는 실무적 교훈이다.
마무리 / 핵심 정리
이번 방송의 핵심은 Opus 5.5와 GPT-6 Sol 가운데 절대적인 승자를 결정하는 데 있지 않다. 진행자의 평가에서는 Astra와 Sol이 명료함과 사용 경험으로 강한 선호를 얻었고, Opus 5.5는 개선된 대화 방식과 폭넓은 작업 수행으로 다시 일상적인 선택지가 됐다. 동시에 SVG에서의 예상 밖 결과, 영상 편집의 공통된 실패와 자동 심사와의 불일치는 하나의 인상이나 점수로 모델 전체를 설명하기 어렵다는 사실을 보여준다. 결국 이 실험이 제안하는 선택 기준은 자신이 반복하는 작업에서 정확성, 이해하기 쉬운 결과, 적절한 소통과 비용을 함께 확인하는 것이다.
📚 출처 및 참고
이번 검수의 직접 자료는 사용자가 제공한 STT 기반 리포트와 스크린샷 목록이다. 원본 STT·음성·화면 자료가 없어 오인식 여부와 개별 수치를 재확인하지 못했다. Soul을 Sol로 통일했다는 기존 편집 기록은 제공된 제목과 일치하지만, 다른 고유명사를 포함한 실제 발음과 표기는 원본 대조가 필요하다. 화면에서만 확인할 수 있는 점수와 모델 대응 관계는 보충하지 않았고, 실무 적용에 관한 해석은 진행자의 직접 발언과 구분해 서술했다.
| 구분 | 내용 |
|---|---|
| 원본 영상 | LIVE: How I AI Opus 5.5 vs. GPT-6 Sol |
| 채널 | How I AI |
| 기존 리포트에 기재된 STT 범위 | 00:00부터 52:29까지 — 원본 STT 미제공으로 재확인하지 못함 |
| 리포트 작성 | 2026-09-23 |
| 작성 방식 | 제공된 STT 기반 리포트의 문맥·표현 검수 및 불확실 수치 표시 |
| 검증 범위 | 제공된 문서의 내부 일관성에 한정하며, 원본 음성·공식 사양·화면 자료는 별도 검증하지 않음 |
| 스크린샷 | 목록의 7개 항목 모두 로컬 경로만 제공됐으며, webUrl이 없어 이미지 삽입 대상 없음 |
💬 본 리포트는 영상 내용을 바탕으로 재구성됐다. 정확한 발언 맥락과 시각 자료는 원본 영상을 참조해야 한다.