7월 15일, 한 Midjourney 사용자가 불쾌한 현상을 발견했습니다. 인터페이스에서는 V8.1이 선택되어 있었으나, 실행된 작업(jobs)은 V7로 표시되었습니다. 이 특정 사례의 원인은 Omni Reference를 삭제한 후에 밝혀졌습니다. 이것이 V8.1이 시스템적으로 "더 나쁘다"는 증거는 아니지만, 확인 순서를 변경해야 할 충분한 근거가 됩니다.

만약 팀이 일련의 비주얼 작업을 위해 Midjourney 신경망을 선택한다면, 진단 오류는 단지 몇 개의 실패한 프레임 이상의 대가를 치르게 합니다. 서로 다른 버전의 결과를 비교하고 있음에도 불구하고, 몇 주 동안 프롬프트 (prompts)를 다시 작성하거나, 해부학적 품질에 대해 논쟁하고, 워크플로 (workflow)를 변경할 수도 있습니다. 미적 판결을 내리기 전에 더 단순한 사실을 확정해야 합니다: 어떤 버전이 실제로 작업을 수행했는가 하는 점입니다.

V8.1은 4월 30일에 출시되었으며 2026년 6월 10일부터 기본 버전 (default version)이 되었습니다. 하지만 "기본 버전", 선택된 버전, 그리고 완료된 작업 (job)에 표시된 버전은 서로 다른 질문에 답합니다. 비교를 위해 적합한 것은 바로 마지막 답변입니다.

드롭다운 (dropdown)이 대조군과 같지 않은 이유

7월 15일의 토론에서 참가자들은 V7로의 전환을 지원되지 않는 Omni Reference와 연관 지었습니다. 이 파라미터 (parameter)를 삭제한 후 저자의 관찰 결과는 사라졌습니다. 이는 유용한 진단 사례이지, 레퍼런스 (reference)가 포함된 모든 요청의 동작을 설명하는 것은 아닙니다.

사용자들은 또한 호환되지 않는 요청이 명확한 오류와 함께 중단되지 않고, 다른 버전의 결과를 반환할 수 있다고 언급했습니다. 이는 커뮤니티의 관찰일 뿐, 공식적인 호환성 계약 (compatibility contract)은 아닙니다. 따라서 이를 통해 폴백 (fallback) 빈도나 모든 호환되지 않는 조합 목록을 도출할 수는 없습니다.

별도의 함정도 있습니다: --preview. Midjourney는 프리뷰 (preview) 테스트가 초기 버전과 관련이 있으며, 결과가 미완성일 수 있고, 시간이 지남에 따라 작업 (jobs)이 변경될 수 있다고 경고했습니다. 이러한 출력값 (output)을 안정적인 버전과 동일한 조건으로 비교해서는 안 됩니다.

Схема проверки фактической версии и условий генерации

"퇴보 (regression)"라고 말하기 전 최소한의 감사 (audit)

수많은 시도를 반복하며 시간을 낭비하지 말고, 짧고 제한적인 테스트를 수행하십시오.

1. 선택한 버전과 각 완료된 작업(job)에 표시된 버전을 기록하십시오.
2. --preview를 비활성화하십시오.
3. 나머지 프롬프트(prompt)를 변경하지 않은 상태에서 Omni Reference, Image Reference, Style Reference를 하나씩 제거하십시오.
4. 확인된 버전에 대해 동일한 작은 배치(batch)를 실행하십시오.
5. 그 후에야 해부학적 구조(anatomy), 프롬프트 준수 여부(prompt following), 그리고 적절한 결과를 얻기 위한 비용을 비교하십시오.

이러한 순서는 세 가지 서로 다른 가설을 구분해 줍니다. 첫 번째: 계획했던 버전이 아닌 다른 버전이 요청을 수행했을 가능성. 두 번째: 가변적인 프리뷰(preview)를 테스트했을 가능성. 세 번째: 확인된 버전과 동일한 조건에서도 실제로 결과가 악화되었을 가능성입니다.

마지막 가설은 여전히 가능성이 있습니다. 최근 사용자들의 메시지에는 불필요한 팔다리가 생기거나 프롬프트 준수 능력이 떨어진다는 불만과 함께, 성공적인 결과가 나온 반례(counter-examples)들이 공존하고 있습니다. 이는 본인의 작업을 테스트해 볼 근거는 되지만, Midjourney의 전반적인 성능 저하(degradation)를 선언할 근거는 되지 않습니다.

'V8.1 고장'이라는 초기 버전의 관점이 바뀌는 지점

신중한 접근 방식에 반대하는 가장 강력한 논거는 합리적으로 들립니다. 사용자는 내부 버전이 아니라 결과물을 구매하는 것이기 때문입니다. 필요한 레퍼런스(reference)를 사용했음에도 워크플로(workflow)가 예상치 못한 출력값(output)을 내놓는다면, 모델의 명칭과 상관없이 실질적인 문제는 실재하는 것입니다.

그것은 맞습니다. 하지만 해결책은 원인에 따라 달라집니다. 사이런트 폴백(silent fallback)이 발생하는 경우, 프롬프트의 새로운 문구 작성만으로는 폴백의 원인을 제거할 수 없으며 호환성을 확인하기 전까지는 V8.1을 제대로 평가할 수 없습니다. 먼저 충돌하는 제어 요소를 제거하거나 다른 호환 가능한 경로를 선택해야 합니다. 프리뷰(preview)가 불안정한 상황에서는 그 출력 결과를 일반 생성(generation)으로 옮겨서는 안 됩니다. 오직 확인된 버전, 반복 가능한 프롬프트 배치(prompt batch), 그리고 일관된 차이가 확인되었을 때에만 버전을 변경하거나 워크플로 전체를 변경하는 것이 의미가 있습니다.

참조 정체성(reference identity)이 중요한 작업의 경우, 저장된 입력 데이터와 출력값(outputs)을 사용하여 버전 고정(version-pinned) 비교를 수행하는 것이 유용합니다. 모델 간의 이러한 대조 테스트를 provod.ai에서 구성할 수 있지만, 이것이 Midjourney의 내부 라우팅(routing)을 수정해 주는 것은 아닙니다. 이 도구의 역할은 비교 조건이 흐트러지지 않도록 유지하는 것입니다.

퇴보(Regression)를 증명할 필요가 없는 경우

만약 V7의 동작 방식이 이미 재현 가능한 프로세스에 내장되어 있고, V8.1로의 전환이 귀하의 짧은 테스트를 통과하지 못했다면 그대로 V7을 유지하십시오. 만약 작업(job)의 실제 버전이 확인되었고, 문제가 되는 참조(references)들을 개별적으로 검증했으며, 결과가 귀하의 작업을 더 잘 해결한다면 V8.1로 전환하십시오. 만약 테스트 과정에서 미리보기(preview), 서로 다른 파라미터(parameters), 그리고 서로 다른 버전들이 뒤섞였다면 어느 쪽도 선택하지 마십시오. 그 테스트는 아직 비교할 가치가 없습니다.

Карточка version-pinned теста

provod.ai — 제품을 재설계하지 않고 AI 통합을 이전하기

애플리케이션이 OpenAI 호환 API를 사용하는 경우, 많은 경우 base_url과 API 키만 변경하면 됩니다: 비즈니스 로직, 시나리오 및 팀의 익숙한 도구들은 그대로 유지됩니다.

하나의 카탈로그에서 텍스트 및 미디어용 최신 모델을 제공합니다: OpenAI의 GPT, Anthropic의 Claude, Google의 Gemini, xAI의 Grok, DeepSeek, Qwen, GLM, Kimi 및 MiniMax가 포함됩니다. 이미지의 경우 Nano Banana 2 Pro 및 GPT Image를, 비디오의 경우 Seedance, Kling, Veo 및 Google Omni의 최신 버전을 사용할 수 있습니다. 또한 추론(reasoning), 검색, 문서, 임베딩(embeddings), 음악 및 오디오를 위한 모델도 사용할 수 있습니다.

마이그레이션 후에도 라우터 때문에 모델 비용이 높아지지 않습니다: provod.ai는 제공업체의 공식 요율을 1:1로 유지하며 자체적인 추가 마진을 붙이지 않습니다.

통합 호환성을 확인하세요: OpenAI SDK 마이그레이션 (migration with OpenAI SDK) · 등록 양식 (registration form) · 모델 가격 (model pricing) · 152-FZ에 따른 데이터 보호 (data protection under 152-FZ)

레퍼런스(reference)가 매우 중요한 작업의 경우, 예측 가능한 V7에 머무르시겠습니까, 아니면 V8.1을 위한 검증된 배치(batch) 작업에 시간을 할애하시겠습니까?