규칙을 수십 개씩 줘야 하는 작업에서는, 예전엔 자세히 적을수록 AI가 더 자주 무너졌다고 말한다. 그런데 Opus 4.8로 바꾼 뒤에는 같은 규칙, 더 빡빡한 조건에서도 에러 없이 한 번에 돌아갔고, 그 변화가 기분 탓인지 데이터와 실제 작업으로 같이 확인해 본다.
flowchart LR A[규칙이 많을수록 AI가 망가지던 문제] --> B[Remotion으로 영상을 코드로 짜며 수십 개 규칙을 써야 하는 작업] B --> C[Opus 4.8의 환각 감소와 규칙 준수 변화를 점검] C --> D[빡빡한 규칙 문서가 다시 재사용 가능한 자산이 됨]
핵심 요약
- 발표자는 Remotion으로 자막이 몇 초에 뜨는지, 화면이 어떻게 넘어가는지까지 코드로 짜기 때문에 AI에게 규칙을 수십 개씩 준다고 설명한다.
- 예전 모델들은 규칙이 많아질수록 A를 지키려다 B를 어기고, B를 고치려다 C를 깨는 식으로 오히려 더 헷갈려 했다고 말한다.
- Opus 4.8은 여러 시험에서 오답률이 낮았고, 그 방식도 억지로 더 많이 맞히는 게 아니라 모르는 건 모르겠다고 보류하는 쪽에 가깝다고 짚는다.
- 자기가 짠 코드에 결함이 있을 때 아무 말 없이 넘어가는 경우가 이전보다 약 네 배 줄었다는 자료를 함께 언급한다.
- 가장 크게 체감한 변화는 규칙 준수로, 예전엔 절반쯤 무시되던 빡빡한 규칙이 이제는 에러 없이 한 번에 지켜진다고 말한다.
왜 지금 중요한가
이 영상은 점수 몇 점 올랐다는 얘기보다, 실제로 규칙 문서를 길게 써야 하는 작업 방식이 어떻게 바뀌는지를 다룬다. 특히 개발자나 PM처럼 제약조건, 예외 처리, 리뷰 비용이 큰 사람에게는 “모르면 보류”와 “규칙을 설명하며 지킨다”는 변화가 바로 시간 절약으로 이어진다는 맥락이 또렷하다.
주요 내용
1. Remotion처럼 자유도가 높은 작업에서는 규칙 문서가 길어질 수밖에 없다
발표자는 Remotion을 “영상을 코드로 짜는 도구”라고 소개한다. 자막이 몇 초에 뜨는지, 화면 전환이 어떻게 되는지까지 전부 코드로 다루기 때문에 자유도가 높고, 그만큼 규칙도 엄청나게 많이 박아둬야 한다고 말한다. 문제는 예전 AI들이 이런 환경에서 자세히 알려줄수록 더 못했다는 점이다. 규칙 A를 지키려다 B를 어기고, B를 고치려다 C를 깨면서 결과가 불안정해졌고, 그래서 한동안은 핵심만 던지고 나머지는 사람이 고치는 쪽이 낫다고 느꼈다고 한다.
2. 첫 번째 변화는 환각 감소, 정확히는 모르면 보류하는 태도다
영상은 환각을 “모르는 걸 아는 척 지어내는 것”이라고 풀어 설명한다. 특히 틀린 걸 당당하게 말하면 사용자가 그냥 믿어 버릴 수 있어서 더 위험하다고 본다. Opus 4.8은 여러 시험에서 오답률이 가장 낮게 나왔는데, 발표자가 흥미롭게 본 지점은 이 수치가 무리해서 더 많이 맞혀서 나온 결과가 아니라는 점이다. “모르는 건 그냥 모르겠다고 보류”하고, “확실하지 않으면 답을 안” 하며, “추측을 안 하는” 방식으로 낮춘 것이라고 설명한다. 여기에 더해 자기가 짠 코드에 결함이 있을 때 아무 말 없이 넘어가는 경우가 이전보다 약 네 배 줄었다는 자료도 함께 언급한다.
3. 실무 체감은 규칙 준수에서 더 크게 온다
발표자가 가장 크게 느낀 변화는 환각보다도 규칙 준수다. 예전에는 수십 개 규칙 중 절반이 무시당했는데, Opus 4.8은 “그 빡빡한 규칙을 정확하게 지키면서 돌아가요. 에러 없이 한 번에”라는 표현으로 정리한다. 더 어려운 조건을 줬는데 결과가 오히려 더 깨끗하게 나온다는 점에서 놀랐다고 말한다. 데이터 쪽에서도 “마땅히 했어야 할 일을 건너뛰는 경우가 줄었”다고 하고, 어떤 방법이 안 먹히면 예전처럼 슬그머니 딴길로 새는 대신 “이게 이래서 안 되네요. 그래서 이렇게 바꿀게요.”라고 이유를 설명하고 방향을 튼다고 설명한다. 이 차이 덕분에 사용자는 중간에 “그건 그렇게 하지 마” 하고 바로 끼어들 수 있고, 영상은 이걸 협업이라고 부른다.
4. 그래서 사용법도 바뀐다: 핵심만 던지는 시대에서, 규칙을 자세히 적는 시대로
발표자는 이 변화가 갑자기 4.8에서만 튀어나온 건 아니라고 덧붙인다. 바로 전 버전인 4.7도 이미 환각률이 낮았고, Anthropic 계열 모델의 설계 철학 자체가 “추측하느니 거부하라”, “모르면 답을 안 하도록 일부러 보정을 걸어 둔 것”에 가깝다고 설명한다. 물론 단점도 있다. 추측을 안 하니 답을 적게 할 수 있고, 다른 모델보다 “그건 잘 모르겠어요”가 많아질 수 있다. 하지만 코드 작업처럼 규칙을 지켜야 하고 실수하면 안 되는 일에서는 그 편이 훨씬 낫다고 본다. 그래서 이제는 “알아서 잘해 줘”라고 던지지 말고, 규칙과 제약, 하지 말아야 할 것을 최대한 자세히 적으라고 권한다. 예전엔 사치 같았던 긴 규칙 문서가 이제는 “계속 써 먹는 자산”이 됐다는 말이 여기서 나온다.
원문 발화 하이라이트
- “예전에는요. 규칙을 빡빡하게 줄수록 AI가 더 망가졌었어요.”
- “모르는 건 그냥 모르겠다고 보류하는 식으로 낮춘 거예요.”
- “자기가 짠 코드에 결함이 있을 때 그걸 아무 말 없이 넘어가는 경우가 이전보다 약 네배 줄었다.”
- “오퍼스 4.8은요. 그 빡빡한 규칙을 정확하게 지키면서 돌아가요. 에러 없이 한 번에.”
- “알아서 잘해 줘. 하지 마세요.”
바로 실행해 보기
- 지금 쓰는 프롬프트에서 막연한 요청 한 줄 대신, 영상에서 말한 방식대로 규칙·제약·하지 말아야 할 것을 따로 적어 본다. 특히 코드 작업이나 문서 생성처럼 검수 비용이 큰 작업부터 적용해 본다.
- AI가 답을 주저하거나 “확실하지 않은데 확인해 주실래요” 식으로 물어볼 때, 바로 성능이 떨어졌다고 보지 말고 그 질문에 답해 본다. 영상은 이 과정이 자신 있게 틀린 결과를 디버깅하는 것보다 시간을 덜 잡아먹는다고 말한다.
- 반복 작업이 있다면 한 번 쓴 규칙 문서를 버리지 말고 저장해 둔다. 발표자 표현대로 예전엔 반쯤 무시되던 문서였지만, 이제는 그대로 지켜지는 “계속 써 먹는 자산”이 될 수 있다는 관점으로 운영해 볼 수 있다.
참고
영상 메타
- 채널: 메이커 에반 | Maker Evan
- 제목: Opus 4.8 리뷰 — 규칙 수십 개 무시하던 AI, 이제 100% 지켜집니다
- 게시 시각(원문): 2026-05-31T00:00:08+00:00
- 영상: https://www.youtube.com/watch?v=iMmxBTz-Yk0
- 썸네일: https://i2.ytimg.com/vi/iMmxBTz-Yk0/hqdefault.jpg
수집 품질
- 자막 세그먼트: 165개
- 자막 문자수: 2929자
- 챕터 추출: 10개
- 콘텐츠 생성: Subagent 기반
AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.