같은 사이트를 Claude · Codex · agy 에게 두 번씩 분석시켜 봤다

같은 사이트를 Claude · Codex · agy 에게 두 번씩 분석시켜 봤다

agy(Antigravity CLI)를 Orca 에 붙여 쓰기 시작하면서 궁금한 게 생겼다. 지금 쓰고 있는 코딩 에이전트 셋에게 똑같은 일을 맡기면 결과가 얼마나 다를까. 그래서 이 블로그, socialofpeach.com 을 시험대로 삼았다. 세 에이전트에게 같은 프롬프트로 사이트를 분석시키고, 각각 두 번씩 돌린 뒤, 나온 지적을 하나하나 실제 사이트에서 확인했다.

조건

세 도구 모두 각자의 기본 모델을 그대로 썼는데, 우연히 추론 강도가 전부 medium 이라 조건을 맞추기 쉬웠다.

공정하게 하려고 몇 가지를 정했다.

• 코드는 보지 않는다. 저장소가 아닌 빈 폴더에서 실행해서, 바깥에서 보이는 사이트만 분석하게 했다.
• 같은 프롬프트 한 장. 범위는 SEO · 성능 · 접근성. 공개 페이지만 보고, 로그인이나 쓰기 요청은 하지 않는다.
• 요청은 60회 이하. 사이트 앞단 nginx 에 요청 제한이 있어서, 요청 사이에 간격도 두게 했다.
• 근거가 있는 것만. 지적마다 확인한 URL 과 실제로 본 값(헤더 · 태그 · 수치)을 적게 했다.
• 두 번씩. 한 번만 돌리면 운이 섞인다.

너는 외부 웹 감사자다. 공개 운영 중인 개인 기술 블로그 https://socialofpeach.com 을 분석해서 개선점을 보고한다.

## 범위
- SEO(메타 태그 · canonical · 구조화 데이터 · sitemap · robots · 내부 링크 · 색인 가능성)
- 성능(응답 시간 · 캐시 헤더 · 압축 · 리소스 크기 · 렌더 차단 · 이미지)
- 접근성(대체 텍스트 · 제목 구조 · 랜드마크 · 대비 · 키보드 · lang)

## 규칙
- 공개 페이지만 본다. 로그인 · 관리자 화면 · 폼 제출 · 댓글 작성 · 쓰기 요청은 하지 않는다.
- 사이트에 보내는 요청은 모두 합쳐 60회 이하로 한다. 요청 사이에 간격을 둔다.
- 홈, 글 상세 2개 이상, 태그 페이지, 소개, 실험실(/lab), sitemap.xml, robots.txt, rss.xml 은 꼭 본다.
- 추측이 아니라 직접 관찰한 근거만 쓴다. 근거가 없으면 쓰지 않는다.

## 결과 형식
요약 3줄, 발견 사항 최대 20개(영역 · 심각도 · 근거 · 제안), 확인한 URL, 사용한 방법.

실행은 대화 창 없이 한 번에 결과만 받는 모드로 했다. Claude 는 claude -p, Codex 는 codex exec, agy 는 agy -p 다.

agy 는 첫 시도에서 빈 손으로 돌아왔다

Claude 와 Codex 는 처음부터 잘 돌았는데, agy 는 두 번 모두 1분도 안 돼서 빈 보고서를 내고 끝났다. 로그에는 이렇게 남아 있었다.

명령을 실행하려면 승인이 필요한데, 대화 창이 없으니 물어볼 데가 없어서 자동으로 거부된 것이다. 자동 승인 모드(--mode auto)는 이 계정에서 쓸 수 없다고 나왔다. 결국 빈 작업 폴더 안에서만 권한 확인을 건너뛰는 --dangerously-skip-permissions 로 다시 돌렸다. 이 때문에 agy 는 다른 둘과 동시에 돌지 못하고 따로 돌았다. 걸린 시간을 나란히 비교할 때 감안해야 한다.

결과

사이트에 보낸 요청은 셋 다 30 ~ 46회로 한도 안이었다. 흥미롭게도 셋 다 같은 방식을 골랐다. 브라우저를 띄우지 않고 curl 이나 파이썬 표준 라이브러리로 HTML · 헤더 · CSS 를 받아 직접 뜯어봤다. 그래서 실제 렌더링 시간(LCP · CLS)이나 키보드 동작은 아무도 재지 못했다. Claude 와 Codex 는 이 점을 "측정하지 않았다"고 스스로 밝혔고, agy 는 따로 언급하지 않았다.

여섯 번 모두 찾은 것

여섯 번의 실행이 하나도 빠짐없이 찾은 문제가 여섯 개 있었다. 확인해 보니 전부 사실이다.

1. 2페이지의 canonical 이 홈을 가리킨다. /?page=2 의 <link rel="canonical"> 이 https://socialofpeach.com 이고 제목도 홈과 같다. 검색엔진이 2페이지를 홈의 중복으로 볼 수 있다.
2. 글 상세와 소개 페이지에 <main> 이 없다. 홈 · 태그 · 실험실에는 있는데 이 두 화면만 빠졌다.
3. 본문 바로가기 링크가 없다. 키보드로 이동하면 매번 사이드바를 다 지나야 본문에 닿는다.
4. HTML 응답이 no-store 다. Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate 라서 브라우저가 페이지를 전혀 캐시하지 못하고, 뒤로 가기 캐시도 쓸 수 없다.
5. 본문 이미지에 width · height · loading="lazy" 가 없다. 이미지가 늦게 뜨면 아래 글이 밀려 내려간다.
6. /tags 의 제목이 h1 에서 h3 로 건너뛴다.

세 에이전트가 모두 독립적으로 같은 결론을 냈다는 건, 이 여섯 개가 "누가 봐도 보이는" 문제라는 뜻이다. 고칠 순서를 정한다면 여기부터다.

셋의 성격이 달랐다

세 보고서의 지적을 합치니 31개가 됐다. 어느 실행이 무엇을 찾았는지 한 장에 펼쳐 보면 성격 차이가 바로 보인다.

두 번의 실행을 도구별로 합쳐서 세면 이렇다. 유효한 지적 27개 중 10개는 셋 모두 찾았고, Claude 와 agy 가 겹친 것도 6개나 된다. Codex 가 찾은 12개는 모두 다른 도구와 겹쳤다.

Claude — 가장 넓게 봤고, 틀린 게 없었다

20개를 꽉 채웠고, 두 번의 결과가 거의 같았다. 혼자만 찾은 것도 많았다.

• 아이폰 비교 글의 본문 이미지 5개가 모두 alt="image" 다. 스크린리더 사용자에게는 "image" 다섯 번으로만 들린다. 실제로 가장 쓸모 있는 지적이었다.
• Accept-Encoding: br 을 보내도 gzip 으로만 응답한다(brotli 미사용).
• 404 페이지의 제목이 사이트 이름뿐이고 h1 이 없다.
• 소개 페이지 메타 설명이 "블로그 운영자 소개" 한 마디다.
• 메타 설명이 본문 앞부분을 기계적으로 잘라서, 부제와 본문 첫 문장이 붙어 버린다.

"문제없어서 뺀 것"도 따로 적어 준 게 좋았다. 본문 글자 대비, lang="ko", 1편짜리 태그의 noindex 처리는 확인했지만 정상이라 넣지 않았다고 했다.

Codex — 적게, 정확하게

9개만 냈지만 전부 맞았고, "높음"은 하나도 붙이지 않았다. 대신 "브라우저 렌더링, 실제 키보드 동작, 화면 대비는 측정하지 않았으므로 해당 결함을 단정하지 않는다"처럼 스스로 확인하지 못한 범위를 분명히 선을 그었다. 가장 빨랐다. 아쉬운 점은 Codex 만 찾아낸 지적이 없었다는 것이다. 찾은 건 모두 다른 둘도 찾았다.

agy — 깊이 판 곳도, 헛짚은 곳도 있었다

agy 는 다른 둘이 그냥 지나친 곳을 숫자로 파고들었다. CSS 의 색 값을 꺼내 대비를 직접 계산했고, 실험실의 흐린 보조 숫자(opacity-70)가 약 3.3:1 로 기준 4.5:1 에 못 미친다는 걸 혼자 찾았다.

글 상세의 og:image 크기 메타가 없다는 것, 구조화 데이터에 publisher 가 없다는 것도 agy 만 짚었다.

하지만 틀린 지적이 두 번 다 있었고(1회 3개, 2회 2개), 그중 둘은 "높음"이었다.

F5. 색인 허용(index, follow)된 개별 태그 상세 페이지 71개가 sitemap.xml 에서 전량 누락됨 — 심각도: 높음

사실이 아니다. 이 사이트는 발행 글이 2편 이상인 태그만 색인하고 사이트맵에 싣는다. 1편짜리 태그는 글 상세와 내용이 겹치는 얇은 페이지라 일부러 noindex 를 붙여 둔 것이다. 실제로 /tags/AI 를 비롯한 8개는 사이트맵에 있다. 두 번째 실행에서도 "태그 62개 누락"으로 같은 실수를 했다. 태그 개수와 사이트맵 개수만 세고, 빠진 페이지의 robots 메타는 확인하지 않은 것이다.

다른 하나도 "높음"이었다. 코드 블록 주석 색(#565f89)이 배경(#1a1b26) 위에서 2.76:1 이라는 지적이다. 계산 자체는 맞다. 하지만 그 색은 코드 하이라이트 테마의 기본값이고, 이 사이트는 본문 코드 블록에서 주석 색을 #8a93c4(5.74:1)로 덮어써 두었다. agy 는 같은 CSS 파일 안에 있는 덮어쓰기 규칙을 보지 못했다. 사이트맵 오탐과 같은 모양이다. 숫자는 정확한데, 그 숫자가 실제로 적용되는지는 확인하지 않았다.

나머지는 비슷한 종류다. "RSS 에 글 27건 중 18건만 실렸다"고 했는데, 공개 글은 원래 18편이다. 27은 사이트맵의 <lastmod> 개수(글 18 + 태그 9)를 글 수로 잘못 읽은 것이었다. 두 번째 실행에서는 글 상세에 발행일 메타가 없다고 했는데, article:published_time 은 멀쩡히 있었다.

agy 는 매번 "높음"을 여섯 개씩 붙였다. Claude 는 두 개, Codex 는 0개였다. 같은 문제에 붙는 심각도가 도구마다 이렇게 다르니, 심각도 표시를 그대로 우선순위로 쓰면 안 된다.

어떻게 채점했나

세 보고서의 지적을 합쳐 하나씩 확인했다. 운영 사이트에 직접 요청을 보내 헤더와 HTML 을 다시 받아 봤고, 대비는 색 값으로 다시 계산하고, 그 색을 덮어쓰는 규칙이 있는지 저장소 CSS 와 대조했다. 사이트의 의도와 엇갈리는 지적(태그 사이트맵처럼)은 백엔드 코드까지 열어 대조했다.

실제로 채점하다 한 번 틀렸다. 코드 주석 대비는 처음에 agy 가 인용한 색으로 대비만 다시 계산해서 "agy 만 찾은 유효한 지적"으로 셌다. 고칠 목록을 만들려고 저장소의 CSS 를 열어 보고서야 이미 덮어쓴 색이 있다는 걸 알았다. agy 와 똑같은 실수를 채점하는 쪽에서도 한 셈이다.

몇 가지는 판정을 미뤘다. Claude 의 "홈이 JS 약 147KB 를 받는다"는 직접 다시 재 보지 않았다. agy 의 "푸터가 없다", "홈 canonical 에 끝 슬래시가 없다" 같은 지적은 사실이긴 하지만 실제 문제라고 보기 어려워 틀린 지적에도, 유효한 지적에도 넣지 않았다.

돌아보며

이번 비교는 모델만의 실력이 아니라 도구와 모델을 합친 실력을 본 것이다. 같은 모델이라도 어떤 도구에 넣어 어떤 권한을 주느냐에 따라 결과가 달라진다. 실행도 두 번씩뿐이라 결론을 일반화할 생각은 없다. 그래도 내 사이트를 놓고 보니 쓰는 법은 분명해졌다.

• 여럿이 공통으로 찾은 것부터 고친다. 여섯 번 모두 나온 여섯 개는 의심할 필요가 없었다.
• 혼자만 찾은 것은 반드시 확인한다. 가장 쓸모 있는 지적(alt="image")도, 가장 크게 틀린 지적(태그 사이트맵 · 코드 주석 대비)도 모두 "혼자만 찾은 것"에서 나왔다.
• 심각도는 도구가 아니라 내가 매긴다. "높음"의 개수는 도구의 성향이지 문제의 크기가 아니었다.
• 역할을 나누면 셋 다 쓸모가 있다. 넓게 훑는 건 Claude, 확실한 것만 빠르게 추리는 건 Codex, 수치를 파고드는 건 agy. 다만 agy 의 결론은 사이트의 의도와 맞는지, 그 값이 실제로 적용되는지 한 번 더 봐야 한다.

다음 할 일은 정해졌다. 여섯 개의 공통 지적과 alt="image" 부터 이 사이트를 고친다.