I Told Claude to "Make it better" 100 Times (It Went Too Far)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude에 ‘더 좋게 만들어라’를 100번 반복하자 초기 개선 뒤에는 기능 과잉과 오류가 나타났고, 개선을 멈출 기준과 사람의 방향 제시가 필요해졌다.

📌 핵심 요점

1. 실험은 형편없는 커피숍 웹사이트에 매번 대담한 변경을 적용하도록 요구했다. 단순히 ‘더 좋게’라고만 한 것이 아니라, 전환율이나 외관을 개선하고 반드시 변경을 내놓도록 강제했다.
2. Sonnet과 Opus는 모두 medium effort로 실행됐으며, 매회 새 세션에서 스킬·메모리·플러그인 없이 작업했다. 발표자에 따르면 두 모델 모두 웹 검색으로 외부 사례를 조사하지 않았다.
3. Sonnet은 주문 인터페이스, 이미지·영상, 주문 양식 등을 점진적으로 추가했다. 주요 이정표는 32회차에서 끝났지만 이후에도 코드가 늘었고, 발표자는 추가 변경의 실익에 의문을 제기했다.
4. Opus는 영상과 주문 양식을 더 이른 회차에 도입했고, QR 주문과 음료 추천처럼 유용하게 평가된 기능도 만들었다. 그러나 100회차에는 과도한 정보와 장식, 불완전한 기능, 기존 기능의 오류가 드러났다.
5. 최종 비교에서 Opus는 약 8시간 30분과 약 21,000줄의 코드, Sonnet은 약 2시간과 3,000줄 미만의 코드를 기록했다. 더 많은 작업량과 산출물이 더 좋은 사용자 경험을 보장하지는 않았다.

🧩 배경과 문제 정의

발표자는 AI에 막연하게 더 예쁘고 더 매끄러운 결과를 요구하는 방식이 어디까지 통하는지 알아보기 위해, 형편없는 커피숍 웹사이트를 두 모델에 주고 개선을 100회 반복했다. 핵심 문제는 변경 횟수가 늘수록 사용자 경험도 계속 좋아지는지, 아니면 어느 순간부터 불필요한 추가와 오류가 쌓이는지다. 이전 시도에서는 약 20~25회에 모델이 개선할 것이 없다고 멈췄기 때문에, 이번에는 매회 대담한 변경을 반드시 내놓도록 요구했다. 따라서 결과는 이런 강제 반복 조건을 전제로 읽어야 한다.

🕒 시간순 섹션별 상세정리

1. 실험의 목표와 강제 반복 조건

• 커피숍 사이트에 개선을 100번 요구하되, 사이트를 먼저 살피고 전환율이나 외관을 개선하는 대담한 변경을 매번 적용하도록 지시했다. 이전에는 모델이 약 20~25회에서 멈춰 이번에는 변경을 강제했다. [00:55]
• 발표자는 막연한 목표만으로는 결과에 한계가 생기며, 더 높은 완성도를 위해 사람이 취향과 혁신 방향을 보태야 한다는 자신의 생각을 실험 배경으로 설명했다. [01:29]
• 두 모델은 medium effort로 실행됐고, 매회 새 세션에서 스킬·설정 문서·플러그인·메모리 없이 자체 지식과 기본 도구로 사이트를 개선했다. 이후 Sonnet과 Opus의 결과를 비교한다. [01:58]

2. Sonnet 초반의 기능 개선과 주요 이정표

• Sonnet의 API 환산 비용은 29.93달러, 생성 자산은 이미지 11개와 영상 2개로 소개됐다. 1회차에는 배경 이미지·JavaScript·모바일 대응, 2회차에는 스크롤에 따라 고정되는 주문 바가 등장했다. [03:08]
• 7회차에는 이미지 관련 이정표가 기록됐고, 24회차에는 첫 AI 영상과 스크롤 효과, 영수증 형태의 주문 표시 등이 추가됐다. 발표자는 전반적으로 작은 개선이 쌓이는 모습으로 평가했다. [04:20]
• 마지막 주요 이정표인 32회차에는 주문 양식이 등장했다. 발표자는 미리 주문하고 수령하는 흐름을 시연하며 사용자 경험이 조금 나아졌다고 평가했다. [04:55]

3. Sonnet 후반의 코드 증가와 중단 시점 문제

• 32회차 이후 100회차까지 새 주요 이정표는 없었지만 코드량은 계속 증가했다. 발표자는 코드 추가가 실제 품질 향상으로 이어지는지 의문을 제기했다. [05:24]
• 최종 버전에는 주문 방식 선택, 팝업, 후기, 상품 애니메이션, 대기 상황과 혼잡 시간 표시 등이 추가됐다. 발표자는 어느 회차부터 추가 요소가 불필요해지는지 질문했다. [06:33]
• 중간 버전의 내비게이션이 최종 버전에서는 사라진 사례도 있었다. 발표자는 기능 삭제와 글꼴 교체를 살펴보며, 반드시 무언가를 내놓으라는 조건이 과도한 설계를 유도한다고 해석했다. [07:05]

4. 디자인 스킬 소개와 Opus 초반 결과

• 발표자는 스크롤 애니메이션·레이어·타이포그래피·간격 등을 다루는 무료 디자인 스킬 ScrollCraft를 소개했다. 이는 앞서 스킬 없이 실행했다고 설명한 실험과 구분되는 홍보 구간이다. [07:35]
• Opus는 비용 약 137달러, 이미지 54개, 영상 3개로 소개됐다. 1회차에 이미지·애니메이션·모바일 대응이 등장했고, 첫 영상은 Sonnet보다 빠른 7회차에 추가됐다. [08:29]
• 15회차에는 주문 양식과 QR 코드가 등장했다. QR을 스캔하자 선택한 주문 내용이 문자 작성으로 연결됐고, 발표자는 이 기능을 긍정적으로 평가했다. [08:59]

5. Opus 중간 버전의 유용한 기능과 복잡성

• 32회차의 마지막 주요 이정표는 Canvas 또는 WebGL로 표시됐다. 발표자는 도구로 개념 설명을 확인했지만, 화면의 어떤 기능이 해당 기술을 사용했는지는 확정하지 못했다. [09:43]
• 취향에 따라 음료를 추천하는 인터페이스는 유지할 만한 혁신으로 평가됐다. 반면 발표자는 다른 많은 변경에 대해서는 과도해서 받아들이지 않을 것 같다고 말했다. [10:05]
• 주문 관련 표시, 준비 시간, 좌석 예약, 수령 안내 등이 등장했다. 발표자는 이미 충분히 많은 기능이 있어 여기서 멈출 수도 있겠다고 말했지만, 실험에는 아직 68회가 남아 있었다. [10:35]

6. Opus 최종 버전의 과잉과 기능 오류

• 100회차에는 배경과 장식, 긴 설명, 많은 섹션이 겹쳤다. 호박 조각 기능은 동작이 불안정했고, 발표자는 커피 주문이라는 목적에 비해 구성이 지나치다고 평가했다. [11:17]
• 일부 기존 섹션이 작동하지 않았고, 스페인어 전환도 제대로 적용되지 않았다. 카페인 관련 정보와 음악 등 추가 기능까지 이어지며 정보와 선택지가 과도해졌다. [11:42]
• 발표자는 마음에 드는 후기 게시판도 복잡한 페이지 속에서 묻힌다고 평가했다. 강제로 계속 작업시키면 과도한 설계로 흐를 수 있어 사람의 지침이 필요하다고 정리했다. [11:59]

7. 최종 자원 비교와 실험의 교훈

• 최종 통계에서 Opus는 약 8시간 30분과 약 21,000줄, Sonnet은 약 2시간과 3,000줄 미만으로 소개됐다. 비용은 각각 약 137달러와 약 22달러라고 설명해 Sonnet의 앞선 비용 수치와 차이가 있었으며, 실제 실행은 구독으로 했다고 밝혔다. [12:29]
• 발표자에 따르면 두 모델 모두 참고 사이트를 살피거나 웹 검색으로 영감을 찾지 않았다. 사용할 수 있는 도구가 있어도 혁신 요구만으로 외부 조사를 수행하지 않았다는 점을 의외의 결과로 꼽았다. [13:10]
• 발표자는 모델이 가능한 결과의 범위를 정하고 프롬프트가 방향을 정한다고 요약했다. 비전 없는 혁신은 추가로 흐르고, 전환율 개선 요구는 과도한 업셀과 주문 유도로 이어졌다고 평가한 뒤 영상을 마쳤다. [13:49]

🧾 결론

• 이 사례에서 반복 개선은 초반의 뚜렷한 개선을 이끌었지만, 변경을 계속 강제하자 필요성이 약한 기능과 장식도 늘어났다.
• 발표자가 강조한 역할 분담은 모델이 가능한 결과의 범위를 만들고, 프롬프트와 사람의 판단이 방향을 정한다는 것이다. 구체적인 비전이 없는 혁신 요구는 기능 추가로 흘렀다.
• ‘매번 변경하기’보다 무엇을 개선할지, 어떤 변경을 유지할지, 언제 멈출지를 판단하는 과정이 중요하다. 다만 이 영상에는 전환율이나 사용자 만족도를 직접 측정한 결과가 없다.

📈 투자·시사 포인트

• AI 개발 비용을 평가할 때 코드량이나 생성 이미지 수뿐 아니라, 실제로 유지할 만한 개선과 작업 시간을 함께 볼 필요가 있다. 이 실험에서 Opus는 더 많은 자원을 사용했지만 최종 결과에 과잉과 오류가 나타났다.
• 발표자는 실제 구독으로 실행했고 비용을 API 환산 관점에서 설명했다. 특히 Sonnet 비용은 영상 안에서 서로 다르게 제시돼, 해당 수치를 그대로 예산 기준으로 쓰기 어렵다.
• AI 개발 도구를 도입하는 조직에는 요구사항 설정, 변경 검토, 기능 검증에 드는 사람의 작업도 중요하다. 이 사례는 자율 반복 횟수만 늘리는 방식의 한계를 보여준다.
• 특정 기업의 투자 매력이나 모델 전반의 우열을 판단할 근거는 부족하다. 영상이 제공하는 시사점은 한 웹사이트 실험에서 관찰된 비용·복잡성·사용성의 관계다.

⚠️ 불확실하거나 확인이 필요한 부분

• Sonnet의 API 환산 비용은 앞부분에서 29.93달러, 마지막 통계 설명에서는 약 22달러로 제시된다. 실제 구독 지출과도 구분해야 하며, 영상만으로 차이의 원인을 확인할 수 없다.
• 전사에는 모델명이 ‘sonet 5.5’, ‘obus 5.5’ 등으로 기록돼 있다. 이후 Sonnet·Opus라는 명칭은 반복되지만, 정확한 버전 표기는 별도 확인이 필요하다.
• 실제 방문자 대상 전환율, 주문 완료율, 성능, 접근성, 사용자 만족도 측정치는 제시되지 않는다. ‘개선’이나 ‘과잉’에 관한 평가는 주로 발표자의 시연과 판단에 기반한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복 작업 전에 사이트의 핵심 목적을 메뉴 확인과 주문 등 구체적인 사용자 행동으로 정리한다.
• ‘매번 기능 추가’ 대신 변경의 목적과 기대 효과를 설명하게 하고, 유지할 가치가 없으면 중단할 수 있는 기준을 둔다.
• 주문, QR 문자 연결, 추천, 언어 전환 등 핵심 기능을 회차별로 직접 확인하고 기존 기능의 오류도 점검한다.
• 초기·중간·최종 버전을 비교해 유용한 변경만 유지하고, 불필요한 기능과 장식은 제거한다.

❓ 열린 질문

• 반드시 변경해야 한다는 조건을 없애고 중단을 허용했다면, 두 모델은 어느 회차에서 멈췄을까?
• 발표자가 선호한 중간 버전이 실제 사용자에게도 최종 버전보다 높은 주문 완료율과 만족도를 보였을까?
• 참고 사이트와 디자인 기준, 스킬을 제공했다면 과잉 기능을 줄이면서 더 나은 결과를 얻었을까?