실제 GitHub 이슈는 항상 친절한 텍스트로 설명되지 않습니다.

"모바일에서 버튼이 이렇게 보여요"
+ screenshot.png

혹은 디자인 mockup과 현재 화면을 비교해서 수정해야 할 수도 있습니다.

이런 현실을 평가하기 위해 나온 것이 SWE-bench Multimodal입니다.

기존 SWE-bench와 무엇이 다른가

기존 SWE-bench는 실제 GitHub issue와 repository를 기반으로 모델이 code patch를 만들어 문제를 해결하는 능력을 봅니다.

Multimodal 버전에는 여기에 시각 정보가 들어갑니다.

  • 버그 스크린샷
  • UI issue 이미지
  • design mockup / wireframe
  • 원하는 동작을 설명하는 diagram
  • 화면에 표시된 error information

즉 agent는 글만 읽는 것이 아니라 이미지를 해석한 뒤 코드로 연결해야 합니다.

v2에서는 480개 task가 남았습니다

2026년 9월 1일 공개된 SWE-bench Multimodal v2는 재현 가능한 평가를 위해 480개 task를 유지합니다. flaky하거나 제대로 채점하기 어려운 테스트는 제거됐고, test split과 evaluation tooling도 오픈소스로 공개됐습니다.

이 변화가 중요한 이유는 단순히 문제 수가 줄어서가 아닙니다.

모델의 시각 이해 + repository 탐색 + 코드 수정 + 테스트 통과를 하나의 workflow로 봅니다.

CodeBridge Mini Lab: 스크린샷 하나로 시작하는 UI 수정

큰 benchmark를 직접 돌리지 않아도 작은 실험을 만들 수 있습니다.

준비:

1. 작은 웹 프로젝트
2. 현재 UI screenshot
3. 원하는 UI mockup
4. Playwright 또는 기존 UI test

Agent에게 다음처럼 요청합니다.

현재 화면과 target mockup을 비교하세요.
차이를 설명한 뒤 필요한 파일만 수정하세요.
수정 후 테스트를 실행하고 결과를 보고하세요.

관찰할 항목:

- 잘못된 visual difference를 찾았는가?
- CSS만 고치면 되는 문제를 JS까지 건드렸는가?
- screenshot에 없는 기능을 임의로 추가했는가?
- 기존 breakpoint를 망가뜨렸는가?

이 네 가지가 실제 multimodal coding agent의 품질을 꽤 잘 보여줍니다.

이미지 이해를 잘한다고 코드도 잘 고치는 것은 아닙니다

여기서 능력을 분리해서 보는 것이 중요합니다.

Vision
→ 무엇이 다른지 인식

Repository reasoning
→ 어디를 수정할지 찾기

Coding
→ 패치 생성

Verification
→ 실제로 고쳐졌는지 확인

첫 단계만 잘해도 task는 실패할 수 있습니다. 그래서 multimodal benchmark는 단순 vision benchmark와 다릅니다.

UI 개발에서 Agent Harness가 중요한 이유

스크린샷 기반 task는 feedback loop가 특히 중요합니다.

Screenshot
→ Analyze
→ Edit
→ Run app
→ Capture again
→ Compare

한 번 코드를 생성하고 끝내는 방식보다 결과 화면을 다시 확인하는 loop가 훨씬 자연스럽습니다.

그래서 multimodal coding의 발전은 모델의 vision 능력뿐 아니라 browser/computer tool과 harness 발전과도 연결됩니다.

결론: 앞으로 코딩 AI는 '코드만 읽는 개발자'가 아닙니다

현실의 소프트웨어 개발에는 로그, 터미널, 문서, 브라우저, 이미지가 함께 있습니다.

SWE-bench Multimodal v2는 그중 시각 정보가 포함된 실제 소프트웨어 이슈를 평가한다는 점에서 의미가 있습니다.

AI coding agent를 직접 비교한다면 코드 생성 문제뿐 아니라 이런 task도 하나 넣어보세요.

스크린샷을 보고 원인을 찾고, 수정하고, 다시 화면으로 검증할 수 있는가?

함께 읽으면 좋은 글

참고 자료