Claude Opus 5.5: Let''s test it live

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude Opus 5.5 라이브 테스트에서는 업무 앱과 게임의 실제 작동이 확인됐지만, 오류·요구사항 준수·운영 안정성에는 추가 검증이 필요했다.

📌 핵심 요점

1. 평가의 중심은 실무 효용이다. 고객 유입, 고객 포털, 사내 지식 허브, 예약·접수를 공통 과제로 삼아 디자인뿐 아니라 엔지니어링과 실제 작동을 살폈다. 적은 입력으로 모델의 판단을 보는 방식이지만, 업무 맥락이 부족하면 결과가 일반적일 수 있다.
2. 업무 앱은 구체적인 사용 흐름을 구현했다. 예약·접수는 시험값 입력부터 완료 화면까지 진행됐다. 지식 허브는 신입 온보딩과 재직자 검색을 나눴고, 고객 포털은 상태 보고·메시지·CRM·프로젝트 관리를 함께 구성했다. 다만 고객별 정보 분리와 저장의 신뢰성까지 검증됐다고 볼 근거는 부족하다.
3. 비밀번호 테스트에서는 안전한 구현 판단을 보였다. 실제 직원 비밀번호를 소스 코드에 평문으로 넣지 않겠다고 답했고, 솔트를 적용한 해시 저장을 확인한 진행자는 통과로 평가했다. 비밀번호 자체를 보내지 말라는 안내는 더 명확했으면 좋겠다는 지적이 남았다.
4. 시각적 결과물은 작동했지만 완성도는 고르지 않았다. 브랜드 사이트의 영상·재생목록은 작동했고, 게임은 후속 수정으로 검은 사각형이 사라지고 보스전 클리어까지 확인됐다. 반면 흰색 깜빡임, 반복적인 맵, 불명확한 종료 동선, 아이콘 불일치가 남았다.
5. 결과의 해석에는 조건을 붙여야 한다. 지식 허브에는 제외 요청과 어긋나는 인사 항목이 나타났고, 랜딩 페이지는 정돈됐지만 평범했다. 후속 요청이 포함됐으므로 전체 결과를 무개입 단일 생성 성과로 보기 어렵고, 가격 비교 수치도 확정되지 않았다.

🧩 배경과 문제 정의

• Claude Opus 5.5의 코딩 능력을 운영체제형 웹사이트, 단일 HTML 테스트, 게임, 업무용 애플리케이션으로 확인한다. 시각적 완성도뿐 아니라 실제 작동과 구현 판단도 평가 대상이다.
• 화려한 데모는 관심을 끌지만 일반 기업의 실무 효용을 충분히 보여주기 어렵다. 이에 라이브는 시각적 실험에, 긴 영상은 기업의 실제 업무 사례에 집중하는 방향을 구상한다.
• 업무용 테스트는 고객 유입, 고객 포털, 사내 지식, 예약·접수의 네 가지다. 입력을 간결하게 유지해 모델의 설계 판단을 살피려 하지만, 업무 맥락 부족으로 결과가 일반적일 수 있다는 한계가 있다.
• 이번 구간은 새 업무 프롬프트를 처음 실행하는 과정이다. 일부 결과는 직접 확인하지만, 여러 작업은 계속 진행 중이어서 전체 성능을 확정하기 어렵다.

🕒 시간순 섹션별 상세정리

1. 운영체제형 웹사이트와 단일 HTML 구현 시험

• 운영체제형 웹사이트를 별도 하위 폴더에 만드는 작업을 시작한다. 전날 한 차례 시험한 결과는 긍정적이었지만, 헤드리스 브라우저 작업 중단을 요구하는 후속 메시지도 있어 추가 확인이 필요하다 [01:06]
• 단일 HTML 파일의 구현 능력을 시험할 별도 폴더를 만들고 테스트를 추가한다 [02:40]

2. 시각적 데모에서 기업 업무 중심 평가로 전환

• 라이브는 게임과 시각적 실험을 유지하고, 긴 영상은 기업의 실용적인 활용 사례에 집중하는 방향을 구상한다. 화려한 썸네일과 화면이 조회수를 얻더라도 도움을 주려는 사업자층의 요구와는 어긋날 수 있다는 판단이다 [04:30]
• 공통 평가 과제로 고객 유입 경로, 고객 포털, 사내 지식 허브, 예약·접수를 선정한다. 예약·접수는 별도 유료 도구 없이 구글 계정과 구글 캘린더로 직접 구성했던 경험에서 출발한다 [05:36]

3. 소닉풍 게임의 시점 전환은 인상적이지만 그래픽·충돌 오류가 남음

• 전날 만든 소닉풍 게임은 횡스크롤 시점과 어깨 너머 전방 시점을 전환하는 시험이다. 캐릭터가 소닉처럼 보이지 않는 이유를 저작권 문제로 추측하지만, 실제 원인은 확인하지 않는다 [08:30]
• 회전 동작과 시각 효과는 긍정적이지만, 최고속도 모드에서는 시점과 무관하게 검은 사각형이 나타난다. 해당 모드를 쓰지 않을 때는 화면이 정상적으로 보인다 [09:25]

4. 비밀번호 처리로 구현 전 판단 능력을 시험

• 부적절한 요구를 알아차리는지 확인하는 ‘판단 함정’ 테스트를 추가한다. 초기 기대는 모델이 문제를 지적하고 그대로 구현하지 않는 것이다 [11:44]
• 모델은 실제 비밀번호가 첨부되지 않았음을 확인하고, 전달받더라도 직원의 실제 비밀번호를 소스 코드에 평문으로 넣지 않겠다고 답한다. 다만 비밀번호 자체를 보내지 말라는 더 명확한 경고가 있었으면 좋겠다는 평가가 따른다 [12:15]

5. 신모델 출시 홍보에 대한 회의와 기술 발전 지지

• 모델 출시 전 관심과 긴장감을 높이고 출시 후 다시 주목을 얻는 패턴을 홍보 전략으로 해석한다. 이는 출시 방식에 대한 개인적 견해다 [14:15]
• 이러한 홍보에 대한 회의와 별개로 더 발전한 모델의 등장은 지지한다 [14:34]

6. 게임 수정 범위를 화면 오류와 보스전으로 확대

• Overdrive 모드에서 시점에 관계없이 검은 사각형이 깜박이는 오류를 수정하도록 요청한다 [14:53]
• 소닉 원작의 지도와 세계를 조사해 처음 확인하는 세 지도를 재현하고, 지도마다 고유한 최종 보스를 추가하도록 요청한다. 이 시점에는 수정 결과가 확인되지 않는다 [15:12]

7. AI를 검색 도구 이상으로 활용해야 한다는 관점

• 일부 선도 AI 연구소의 방식에는 동의하지 않지만 기술 발전과 이용자의 활용 확대는 지지한다. 뉴스와 일부 콘텐츠가 사람들의 두려움을 키운다고 보면서도, 모든 뉴스가 거짓이라고 주장하지는 않는다 [16:49]
• ChatGPT를 검색엔진처럼 쓰는 것도 출발점으로 인정한다. 다만 단순한 챗봇이나 고급 검색 도구로만 취급하는 단계를 넘어 더 폭넓게 활용하기를 기대한다 [17:43]

8. 고객 유입 테스트는 허위 추천 없이 신뢰와 전환을 구현

• 가상의 상업용 냉난방 설비 유지보수 업체를 대상으로 작동하는 고객 유입 경로를 요구한다. 서비스 제안을 설명하고, 가짜 고객 추천 없이 신뢰를 형성하며, 다음 행동을 명확하게 만드는 것이 핵심이다 [19:26]
• 합성 데이터만 사용하되 디자인·구조·구현은 모델이 선택한다. 이 프롬프트를 여러 모델에 적용하고, 중소기업의 실용적인 활용 사례를 긴 영상으로 다룰 계획이다 [19:48]

9. 고객 포털은 고객별 정보 분리와 변경사항 저장까지 요구

• 고객 포털의 범위가 피상적일 수 있다는 우려를 다시 검토한다. 대상은 연 매출 2,000만 규모의 가상 컨설팅 회사이며, 자막에는 통화 단위가 제시되지 않는다 [20:04]
• 고객이 계약·업무 관계를 이해하고, 진행 상황과 관련 정보를 확인하며, 서비스팀과 조율할 수 있어야 한다. 핵심 업무 흐름을 끝까지 구현하고 고객별 정보를 분리하며 변경사항을 저장하는 작동 가능한 앱을 요구한다 [20:26]

10. 사내 지식과 예약·접수를 별도 업무 과제로 구체화

• 직원 100명 규모의 가상 기업에 하나의 공통 지식 기반을 두고, 신규 입사자 온보딩과 기존 직원의 내부 지식·표준운영절차 접근을 구분한다. 사용자가 입장 시 필요한 경험을 선택하고, 각 대상에 맞게 정보를 구성하도록 요구한다 [20:52]
• 지식 허브에는 현실감 있는 합성 콘텐츠를 사용하고 디자인과 기술은 모델이 선택한다. 예약·접수 앱은 기업 운영 관리 서비스를 판매하는 가상의 AI 컨설턴트를 대상으로 한다 [21:22]

11. Hermes 학습 루프 재현은 검증되지 않은 아이디어

• Hermes에서 착안한 학습 루프를 메모리에 적용하려는 문제에 대해, 저장소에서 관련 구현 단서를 찾을 수 있으리라고 추정한다 [21:48]
• Astra의 컴퓨터 사용 기능으로 Hermes의 기능과 기본 프로필 동작을 살펴보고, 조작 과정을 통해 역공학하는 방법을 제안한다. 유용할 수도 있고 아닐 수도 있다는 불확실성을 명시한다 [22:19]

12. 입력을 줄여 모델 판단을 보는 평가와 업무 맥락 부족의 충돌

• 고객 유입 성과에는 마케팅 문구가 중요하며, 적절한 지식 기반이 없으면 일반적인 결과가 나온다는 지적이 제기된다. 테스트에서는 모델이 스스로 어떤 결정을 내리는지 보기 위해 정보를 많이 제공하지 않는 방식을 택한다 [22:42]
• 이번이 해당 프롬프트들의 첫 실행이며, 약 20개 후보를 네 개로 좁혔다. 일부 요구가 피상적이거나 덜 구체적이라는 우려가 있어도 당장은 유지한다 [23:10]

13. 상호작용형 행성 시각화는 호평, 지리적 정확성은 미확인

• 완성된 결과를 여는 과정에서 브라우저 미리보기 대신 코드가 표시되어 직접 결과물을 찾아 확인한다. 시각화의 완성도를 긍정적으로 평가하고, 요청하지 않은 추가 요소도 발견한다 [24:29]
• 태양 반사와 어두운 면의 표현은 좋은 평가를 받는다. 다만 지형이 실제 지구를 나타내는지, 보이는 부분이 북미와 남미인지 확신하지 못한다 [25:16]

14. 제품 모방 비판과 자동 스킬 개선 아이디어

• 다른 개발자들의 온라인 논쟁을 언급하며 특정 제품이 독창적인 변형보다 직접적인 복제에 가깝다는 개인적 평가를 내린다. 독립적으로 검증된 사실이 아니라 유사성에 대한 비판이다 [26:30]
• OpenAI 워크숍과 Hermes의 자동 스킬 사이에 있는 형태가 유용할 수 있다는 아이디어와 함께 스킬 업데이트가 언급되지만, 구체적인 구현이나 효과는 확인되지 않는다 [26:40]

15. 후속 작업은 계속 진행되며 최종 결과 확인이 지연

• 일부 작업에는 여전히 주의가 필요하고, 후속 알림을 확인한 뒤에도 작업이 계속 실행 중인 상태다 [27:35]
• 작업 중인 결과를 직접 플레이하려 하지만 해당 결과가 로드되지 않는다. 제공된 자막의 마지막까지 후속 수정의 완성도와 정상 작동 여부는 확인되지 않는다 [29:37]

16. 세션 사용량과 데스크톱 앱의 자원 부담

• 사용량 설정에서 지금까지의 프롬프트로 세션의 약 20%를 소모한 것을 확인한다. [31:21]
• 기존 M1 기기에서 여러 앱을 실행 중이며, Claude 데스크톱 앱은 Codex나 ChatGPT보다 자원을 많이 소비한다는 경험 때문에 평소 사용을 피한다. 끊김이 앱 실행 직후 시작됐을 가능성을 의심하며 앱을 종료한다. [32:08]

17. 장비 교체의 조건은 메모리와 휴대성

• 128GB 메모리를 갖춘 M4 또는 M5라면 현재의 자원 부족 문제가 사라질 것으로 예상하지만, 실제 확인한 결과는 아니다. [33:29]
• Apple 리퍼비시 매장에서 원하는 128GB 모델을 기다리고 있다. 최근 본 제품은 16인치였으나, 여행에 더 적합하다고 느끼는 14인치를 선호한다. [34:13]

18. 에이전트의 구매 권한과 개인 비서 활용 범위

• 에이전트에는 예산과 카드 한도를 두며, 6,000~8,000달러 수준의 구매는 맡기지 않는다. 실수 가능성 때문에 직접 구매하고 새 상품이 나오면 알림을 받는 방식을 택한다. [35:08]
• 개인 에이전트는 중요한 생일을 알려주고 KLM의 Flying Blue 마일리지 프로모션을 지속적으로 확인한다. 때로는 일반적인 이코노미 보너스 항공권에 해당하는 마일리지로 비즈니스석을 구할 수 있지만, 정확한 필요 마일리지는 기억하지 못한다. [35:51]

19. 저렴한 M4 Max 매물과 구매 조건 비교

• 30일 무료 반품이 가능한 M4 Max 매물을 발견한다. 메모리 128GB, 저장 공간 8TB 구성이며, 기억하는 가격보다 약 2,000달러 낮아 저렴한 이유를 의심한다. [37:38]
• 매물의 은색은 원하는 스페이스 블랙과 다르다. 세금·배송비를 포함한 가격을 지인의 직원 할인으로 M5를 구매하는 경우와 비교하고, 할인율을 25%로 가정하면 최종 가격이 같다고 계산한다. [42:13]

20. 브랜드 사이트 빌드 도중 접근 권한 문제 발생

• 브랜드 운영체제 형태의 사이트가 빌드 도중 일부만 설치된 상태로 보인다. 이미 데스크톱 접근을 허용했는데도 작업이 중간에 멈춰 재시도를 요청한다. [45:26]
• 보안·개인정보 설정을 확인하지만 T3 Code에 전체 디스크 접근 권한까지 주고 싶지는 않으며, 데스크톱 폴더를 허용하는 선택지도 보이지 않는다. [46:00]

21. 초기 생성 성과와 T3 Code 접근 복구

• 설명이 충분하지 않았던 어린 시절의 게임 재현은 첫 시도에 성공했고, 현재는 개선 작업을 진행한다. 실용적인 비즈니스 사례와 브라우저 운영체제 형태의 브랜드 사이트도 함께 시험한다. [48:48]
• T3 Code를 종료하고 다시 열자 접근이 복구된다. 이번 접근 장애는 T3의 작은 버그로 판단한다. [49:23]

22. 모델 가격 비교에 남은 수치 불확실성

• 가격을 처음에는 ‘4와 20’으로 기억하다가 문서를 찾는 과정에서 ‘입력 10, 출력 50’을 언급하고 Fable 대비 절반 이하라는 평가도 한다. 비교 대상과 수치의 대응은 이 대목에서 명확하게 정리되지 않는다. [49:34]
• Grok과 SpaceX가 저렴한 제품을 통해 가격을 낮추기를 기대한다. 실제 가격 인하가 확인됐다는 의미는 아니다. [51:57]

23. 상담 랜딩 페이지의 첫인상과 브라우저 조작

• 페이지 상단의 작은 움직임과 상호작용 요소가 눈에 띈다. ‘자동화하기 전에 감사하라’는 문구는 발음하기 어렵다고 느끼며 수정할 대상으로 본다. [53:09]
• 에이전트의 브라우저 제어가 이전보다 나아 보인다. 두 부분으로 구성된 요청으로 랜딩 페이지와 접수 화면을 만들었으며, 접수 폼을 직접 검증하기 전의 외관은 단순하지만 전문적이고 정돈됐다고 평가한다. [53:35]

24. 상담 예약과 접수 폼의 실제 동작

• 감사 세션 예약 과정에서 스크롤이 필요하다는 점을 불편하게 여기지만, 이어지는 소개 통화 화면의 고정 요소는 그 불편을 일부 보완한다. [54:10]
• 상세 접수 폼에 시험용 값을 입력하며 기능을 확인한다. [54:47]

25. 지식 허브의 역할별 진입 구조

• Kestrel Outdoor 지식 허브는 일하는 방식, 업무 내용, 문의할 사람을 한곳에 모은 ‘필드 가이드’ 형태다. 이용자는 현재 상황에 맞는 경로를 고르고 나중에 바꿀 수 있다. [56:27]
• ‘처음 왔다’ 경로에는 상단 이미지와 환영 안내가 있으며, 신입 구성원을 위한 온보딩의 첫인상이 좋다. [56:47]

26. 신입 온보딩의 구체적인 실행 단계

• 환영 안내에서 첫날 알아야 할 내용으로 이동하고, 다시 자신의 경로로 돌아갈 수 있다. [57:06]
• 도구 활성화와 기본 설정, 첫날 관리자 만나기 등 단계가 구체적으로 구성돼 있다. 절차가 직관적이며, 가볍게 살펴본 수준에서는 안내 문구를 바꿀 필요도 크게 느끼지 않는다. [57:22]

27. 재직자 검색 경로와 인사 업무 제외 조건 위반

• 재직자 경로에서는 원하던 검색 기능을 확인한다. 그러나 휴가·유급휴가 항목이 나타나면서 ‘인사 관련 내용은 제외한다’는 요청이 지켜졌는지 의문이 생긴다. [57:58]
• 재직자가 표준 운영 절차를 찾는 진입점도 제공된다. [58:22]

28. 검색은 유용하지만 화면 고정 동작은 불일치

• 스크롤 중에도 고정되기를 원하는 두 영역이 해당 화면에서는 고정되지 않는다. 다른 부분에는 이미 적용된 동작이어서 일관성 문제이며, 빠르게 수정할 수 있다고 본다. [58:40]
• 검색 기능은 마음에 들지만, 고객 서비스 사고 대응 등의 내용을 탐색하면서 한 페이지는 고정되고 다른 페이지는 고정되지 않는 차이를 다시 확인한다. [58:52]

29. 용어집 탐색 개선과 제한된 맥락에서의 최종 평가

• 용어집에서는 검색과 글자별 탐색을 스크롤 중에도 계속 사용할 수 있도록 보조 탐색 메뉴를 고정하고 싶어 한다. [59:35]
• 팀·제품·디자인별 탐색과 제품 제작 방식에 관한 내용도 확인한다. 완벽하지는 않지만 전반적으로 잘 만들어졌고, 고객 관리와 관련해 적은 맥락만 제공한 것에 비하면 기대보다 좋은 결과라고 평가한다. [1:00:00]

30. 직원 지식 허브의 문서 관리와 인물 검색

• 지식 허브에는 다른 가이드로 이어지는 링크와 요약 표시가 있으며, 오래된 글과 작성·게시 시점을 팀에 알리는 기능도 있다. [1:00:43]
• 사람별 프로필과 검색은 규모가 큰 조직에서 담당자를 찾는 데 유용하다. 다른 부서의 신입 직원이 전자상거래 담당자처럼 아직 모르는 동료를 확인하는 용도로 읽힌다. [1:01:17]

31. 사라진 랜딩 페이지 세션의 복구 시도

• 앞서 만든 홈페이지 세션이 목록에서 보이지 않는다. 실수로 보관 처리했을 가능성을 확인하지만, 해당 폴더의 보관 항목만으로는 찾지 못한다. [1:03:00]
• T3 Code에서 사라진 세션을 이어가기 위해 상위 폴더의 잠재고객 확보용 테스트·리드 마그넷 관련 디렉터리를 확인하도록 요청한다. [1:04:28]

32. 고객 포털에 통합된 상태 보고와 협업 기능

• 고객 화면에는 데모 계정과 로그인 요소가 있으며, 작은 표시 오류가 눈에 띄지만 상태 보고의 시각적 구성은 긍정적으로 평가된다. [1:07:38]
• 상태 보고를 열면 발송 이력을 확인하고 Markdown 파일을 미리 볼 수 있다. 대기 항목, 신규 요청, 메시지 영역도 포함된다. [1:08:31]

33. 맞춤형 고객 포털의 활용 가능성과 역할별 화면의 한계

• 포털은 맞춤형 Zendesk 대안처럼 보이지만, 기존 제품의 많은 기능은 빠져 있을 것으로 예상된다. 일부 구성은 실제 고객 포털에 옮겨 활용하고 싶은 대상으로 꼽힌다. [1:09:56]
• 일정 표현은 처음에는 재설계가 필요한 결함처럼 보이지만, 서로 다른 세 개의 타임라인을 나타내는 구성일 수 있다는 해석으로 수정된다. [1:10:26]

34. 복구된 랜딩 페이지의 안정적인 구조와 평범한 디자인

• 잠재고객 확보용 테스트 데모를 찾아 다시 연다. 페이지는 거의 완성된 상태이며, 단순하고 직관적인 구조가 후속 수정의 여지를 제공한다. [1:11:56]
• 회사 로고, 번갈아 쓰는 배경 이미지, 격자 아래의 은은한 도면 같은 배경을 더하면 과장하지 않으면서 시각적 생동감을 높일 수 있다. [1:12:39]

35. 브랜드 자료의 부재가 디자인 판단에 미친 영향

• 원하는 브랜드 미감을 얻으려면 회사 로고나 기존 웹사이트를 제공해 스타일과 글꼴의 참고 기준을 만들어야 한다. [1:13:57]
• 이번 결과에서 Claude는 가상의 냉난방·환기 업체라는 설정 외에 별도 참고 자료 없이 디자인을 결정했다. [1:14:15]

36. 브랜드 사이트의 외부 연결과 영상 기능

• 브랜드 사이트에는 온보딩 요소, 작은 애니메이션, Maddy 채팅 상자가 있다. 전반적인 완성도는 좋지만 지금까지 본 최고의 결과라는 평가는 아니다. [1:16:14]
• 공식 사이트에 직접 공개하지 않고 별도 랜딩 페이지를 통해 제공하던 Discord 링크까지 가져온 점이 눈에 띈다. 점무늬 배경 재구성도 선호하는 요소로 꼽힌다. [1:16:51]

37. 브랜드 사이트의 아이콘 오류와 조직 정보 재현

• 창 닫기 버튼에 일반적인 닫기 기호 대신 X의 브랜드 로고가 쓰였다. 소셜 링크는 상단에 배치하는 편이 낫겠다는 개선 의견도 나온다. [1:18:18]
• 일부 아이콘은 파란 배경 위 흰 테두리처럼 시각적 처리가 어색하고 서로 일관되지 않다. 반면 등장 애니메이션은 매력적이며, 확인한 기능은 대체로 정상 작동한다. [1:18:46]

38. 소닉풍 게임의 그래픽 오류 수정 확인

• 최고 속도 버튼을 누를 때 나타나던 검은 사각형은 사라졌지만, 약한 흰색 깜빡임은 남아 있다. 수정 효과와 잔여 오류가 함께 확인된다. [1:20:19]
• 1인칭 시점으로 전환한 뒤에도 화면은 괜찮아 보이며, 구간 끝까지 이동해 다음 동작을 확인한다. [1:20:40]

39. 등대 보스의 공격 조건과 실제 클리어

• 구간 끝에는 등대 형태의 보스가 등장하며, 옆으로 기울어진 상태에서 피해를 줄 수 있다는 공격 조건을 파악한다. [1:21:12]
• 체력 상태를 찾는 데 혼란이 있고 첫 시도는 사망으로 끝나지만, 최종 보스의 발상 자체는 창의적이고 재미있다는 평가를 받는다. [1:21:47]

40. 용암 구간의 환경 효과와 가시성 문제

• 다음 구간에는 작은 화염 분출과 잘 보이지 않는 게 형태의 적이 등장한다. 용암 효과는 긍정적으로 평가되지만 진행은 어렵다. [1:25:25]
• 화면이 지나치게 어둡게 보이는 문제에는 교체 예정인 모니터의 영향이 있다고 보여준다. 시청자에게 보이는 화면과 자신의 화면이 다를 수 있어, 이를 게임 자체의 밝기 문제로 단정하지 않는다. [1:25:57]

41. 명확한 종료 버튼 부재와 반복적인 맵 구성

• 게임에는 눈에 띄는 종료 버튼이 없어 다른 구간으로 이동하는 방법이 직관적이지 않다. [1:27:10]
• 맵은 이전 구간과 비슷해 보여 구조적 독창성이 부족하다는 평가를 받는다. 세 번째 구간으로 넘어가기 위해 남은 목숨을 모두 소진하는 방식을 택한다. [1:27:29]

42. Prism Heights의 시각적 특징과 보스 공격 규칙

• 세 번째 구간의 이름은 Prism Heights이며, 시각적 분위기는 트론을 재현한 것처럼 느껴진다. [1:27:59]
• 상대가 아래에 있을 때 공격해야 한다는 조건을 파악하지만, 연속된 시도에서는 타격에 실패한다. [1:28:47]

43. 작동하는 결과물과 남아 있는 완성도 문제

• 결과물은 실제로 작동하고 전반적으로 좋은 평가를 받지만, 일부 오류가 있으며 배경에 더 많은 세부 표현이 있으면 좋겠다는 개선점이 남는다. 배경의 추가 디테일은 처음부터 요청했던 사항은 아니다. [1:31:00]
• 한 번의 생성으로 얻은 결과라는 평가와 함께 후속 요청을 했다는 설명도 등장하므로, 전체 결과를 후속 개입이 전혀 없는 성과로 단정하기는 어렵다. [1:31:17]

44. 공통 실무 과제로 모델 비교를 확대하고 평가 사례를 개선

• 실무 활용 사례에 대한 의견을 받아 이를 각 모델의 공통 테스트 과제로 사용할 생각이다. Opus 55, Six Soul, Six Luna에 같은 사례를 적용해 차이를 확인하고, Grock 47도 추가로 테스트할 가능성이 있다. [1:32:06]
• 라이브 방송은 재미와 시각적 요소를 유지할 계획이다. 실무 평가 사례는 현재 형태도 좋은 출발점으로 보며, 피드백을 반영해 점진적으로 수정할 예정이다. [1:32:42]

🧾 결론

• 이번 사례는 Claude Opus 5.5가 적은 맥락에서도 작동하는 업무용 시제품을 만들 수 있음을 보여준다. 실제 서비스에 필요한 검증이 모두 끝났다는 의미는 아니다.
• 좋은 첫인상과 요구사항 충족은 별도로 평가해야 한다. 역할별 화면, 제외 조건, 데이터 처리, 탐색 동작에서 추가 확인할 지점이 드러났다.
• 후속 수정은 효과가 있었다. 다만 수정 횟수와 사람의 개입을 함께 기록해야 생성 능력과 최종 완성도를 구분할 수 있다.
• 공통 업무 과제를 다른 모델에도 적용하겠다는 계획은 비교의 출발점이며, 이번 방송만으로 모델 간 우열을 확정할 수는 없다.

📈 투자·시사 포인트

• 기업 도입 관점에서는 시각적 데모의 인상보다 예약 완료, 문서 검색, 고객 상태 공유처럼 실제 업무 흐름이 이어지는지를 평가 기준으로 삼을 만하다.
• 맞춤형 고객 포털은 기존 도구의 일부 기능을 직접 구성할 가능성을 보여준다. 다만 진행자도 기존 제품의 많은 기능이 빠졌을 것으로 예상했으므로 완전한 대체로 해석하기는 이르다.
• 브랜드 자료와 업무 지식의 제공 여부가 결과 품질을 평가할 때 중요한 조건이다. 최소 입력 테스트와 실제 도입용 테스트를 구분필요가 있다.
• 세션 사용량 약 20%라는 관찰만으로 업무당 비용을 산정할 수 없다. 혼동된 모델 가격과 기기 자원 부담을 확인한 뒤 비용 대비 효용을 판단해야 한다.

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

• 예약 완료 화면은 확인됐지만 실제 캘린더 반영, 중복 예약 방지, 고객별 접근 통제와 데이터 영속성까지 검증됐는지는 제시되지 않는다.
• 모델 가격은 ‘4와 20’, ‘입력 10, 출력 50’ 등의 언급이 혼재하며 비교 대상과 할인율도 불명확하다. 확정 가격이나 비용 우위의 근거로 사용할 수 없다.
• 결과물에는 후속 수정이 포함된다. 초기 생성과 수정 이후 성과를 분리하지 않으면 단일 프롬프트의 성능을 과대평가할 수 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 네 가지 업무 과제에 완료 기준을 붙인다. 예약은 실제 반영, 포털은 고객별 정보 분리와 저장, 지식 허브는 검색과 제외 조건, 고객 유입은 다음 행동까지 확인한다.
• 같은 프롬프트와 합성 데이터로 모델을 비교하고, 최초 결과·후속 요청·수정 시간·사용량을 따로 기록한다.
• 최소 맥락으로 만든 결과와 회사 로고·기존 사이트·업무 지식을 제공한 결과를 비교해 입력 자료의 효과를 확인한다.
• 평문 비밀번호 거부와 솔트 해시 적용을 구분해 점검하고, 실제 비밀번호를 입력하지 않도록 안내하는지도 확인한다.

❓ 열린 질문

• 동일한 네 가지 업무 과제를 다른 모델에 적용하면 기능 완성도와 수정 부담에서 어떤 차이가 나타날까?
• 브랜드 자료와 실제 업무 맥락을 충분히 제공하면 평범했던 디자인과 문구가 얼마나 개선될까?
• 화면에서 작동한 예약·포털 기능은 실제 데이터와 여러 사용자가 있는 환경에서도 안정적으로 유지될까?