Astra vs Fable Computer Use 리셋권 걸고 맞다이
📺 원본 영상: Astra vs Fable Computer Use 리셋권 걸고 맞다이
🎙️ 채널: 코드팩토리
📅 정리 일자: 2026-09-09
⚠️ Note: 본 리포트는 STT 기반으로 작성된 제공 리포트를 문맥과 내부 일관성 중심으로 검수했다. 원본 STT와 영상 음성을 직접 대조하지 않았으며, 화면의 실제 그림, 코드, 수식, 슬라이드도 직접 확인하지 않았다. 결과물에 관한 평가는 제공 리포트에 기록된 진행자의 설명을 따른다. 모델과 실행 옵션의 명칭은 입력 자료를 기준으로 사용하며, 공식 사양을 별도로 검증한 것은 아니다.
개요
이 영상은 Astra와 Fable에 데스크톱 애플리케이션을 직접 조작하게 하고, 컴퓨터 사용 능력인 Computer Use의 차이를 비교한다. 진행자는 Krita에서 사진을 따라 그리는 작업, Numbers에서 CSV 데이터를 처리하는 작업, Keynote에서 발표 자료를 만드는 작업을 통해 세밀한 조작 능력과 일상적인 문서 작업 능력을 함께 살폈다. 진행자의 평가에서 Astra는 빠른 조작과 정교한 붓 사용으로 우세했지만, 두 모델 모두 그림의 목표 유사도에는 도달하지 못했으며, 문서 작업에서는 결과물보다 소요 시간과 파일 탐색 과정에서 차이가 두드러졌다.
무엇을 시험했는가 — 화면을 읽고 행동으로 옮기는 능력
진행자가 이번 비교에서 집중한 대상은 텍스트 답변의 품질이 아니라, 화면을 확인하고 적절한 위치를 찾아 실제 조작을 수행하는 능력이었다. 그는 화면을 캡처해 무엇이 어디에 있는지 파악하고, 그 정보를 바탕으로 클릭하는 과정이 Computer Use의 핵심이라고 설명했다. 이러한 능력을 충분히 드러내려면 조작이 많이 필요한 과제가 적합하다고 생각했고, 그 결과 사진을 참고해 그림을 그리는 작업을 선택했다. 진행자의 얼굴과 엄지손가락이 포함된 사진을 재현하는 과제는 단순히 버튼을 누르는 것보다 위치, 색상, 붓의 굵기와 움직임을 지속적으로 판단해야 한다는 점에서 중요한 시험대가 되었다.
그림 도구로는 진행자 자신도 처음 사용한다는 Krita를 골랐다. 처음에는 평소 자주 사용하는 Canva를 고려했지만, 진행자에 따르면 브라우저에서 작업할 때 컴퓨터 사용 기능을 적용하는 데 제약이 있다는 응답을 받았다. 그는 이 문제를 피해 네이티브 데스크톱 애플리케이션으로 실험 환경을 구성했고, 이후 스프레드시트와 발표 자료 작업에도 Numbers와 Keynote를 사용했다. 다만 이 경험만으로 특정 서비스가 브라우저 조작을 일반적으로 지원하지 않는다고 단정할 수는 없으며, 영상에서 확인되는 범위는 해당 실행 환경에서 진행자가 겪은 제약이다.
실험을 읽을 때는 진행자가 과제를 여러 번 조정했다는 사실도 고려해야 한다. 그는 컴퓨터 사용만으로 수행할 수 없는 요구가 프롬프트에 포함되면 실행을 중단하고 해당 요구를 제외한 뒤 다시 진행했다고 설명했다. 이는 실행 가능한 과제로 범위를 맞추려는 조치였지만, 전체 시도 횟수와 각 시행의 조건이 모두 제시된 것은 아니다. 따라서 이번 영상은 실제 사용 과정에서 관찰한 비교 사례로 의미가 있으며, 모든 변수를 통제한 반복 실험으로 해석하기에는 제공된 정보가 제한적이다.
Krita 그림 그리기 — 완성도보다 먼저 드러난 조작 방식의 차이
그림 과제의 요구는 빈 캔버스에서 출발해 참고 사진을 페인트 도구로 재현하는 것이었다. 진행자는 컴퓨터 사용 기능만 활용하고, 모델 스스로 원본과 90% 이상 유사하다고 판단했을 때 멈추도록 지시했다. 작업 환경에는 빈 캔버스와 참고 이미지가 마련되어 있었고, 모델은 둘 사이를 오가며 그림을 진행할 수 있었다. 여기서 90%라는 숫자는 별도의 평가 도구가 산출한 점수가 아니라 프롬프트에 설정된 종료 조건이므로, 결과를 객관적인 이미지 유사도 측정치처럼 받아들여서는 안 된다.
진행자의 설명에 따르면 Astra는 먼저 전체 형태를 잡고, 색과 음영을 덧입히며 결과를 수정하는 방식으로 작업했다. 적합해 보이는 붓을 선택하고 굵기를 바꾸었으며, 이미 칠한 부분이 적절하지 않다고 판단하면 다시 덧칠하거나 삭제하고 주변 색으로 보정했다. 진행자는 특히 작은 점을 반복해서 찍고 명암을 추가하는 모습에서 세밀한 조작이 많이 이루어진다고 느꼈다. 이 관찰에서 주목할 부분은 단순한 클릭의 빈도뿐 아니라, 중간 결과를 보고 도구와 조작 방법을 바꾸는 과정이 반복되었다는 점이다.
Astra는 작업 도중 화면을 확대하고 눈 주변을 보정하기도 했다. 진행자는 확대가 컴퓨터 사용 관점에서 어떤 의미가 있는지 확신하지 못한다고 말했지만, 적어도 설명상으로는 전체 형태를 그리는 단계에서 국소적인 수정 단계로 전환한 행동이었다. 다만 실제 화면의 배율, 캡처 해상도, 수정 전후의 좌표 정확도는 STT만으로 확인할 수 없다. 따라서 확대가 성능 향상에 얼마나 기여했는지는 판단을 유보하고, 세부 영역을 대상으로 작업 방식을 바꾸었다는 관찰에 의미를 두는 편이 적절하다.
💡 [영상 참조] 진행자는 확대된 화면에서 눈을 보정하는 과정을 설명한다. 실제 확대 상태와 붓 움직임은 원본 영상 03:56에서 확인할 수 있다.
Astra의 그림 작업은 진행자에 따르면 49분이 걸렸지만, 설정된 유사도 목표를 충족하지 못한 채 종료되었다. 모델은 더 이상 충분히 개선하기 어렵다고 판단해 진행 불가 상태로 기록했다고 한다. 진행자는 전체적으로 기대만큼 원본과 닮지는 않았다고 평가하면서도, 머리카락의 결이나 색조와 음영 표현에는 긍정적인 반응을 보였다. 즉, 이번 결과는 높은 목표를 끝까지 달성한 성공 사례보다는, 목표에는 미달했지만 세부 조작 능력은 분명하게 드러낸 사례에 가깝다.
Fable의 거친 붓 작업과 추론 강도 조정
Fable의 초기 실행은 진행자의 설명에서 Astra와 상당히 다른 양상을 보였다. 그는 Fable이 큰 브러시로 넓은 영역을 처리했고, 화면을 보며 다음 행동을 고민하는 시간이 상대적으로 길었다고 관찰했다. 같은 16배속 타임랩스에서도 Astra처럼 빈번하게 도구를 바꾸거나 작은 부분을 수정하는 모습은 덜 두드러졌다는 것이다. 최종 그림에 대해서도 진행자는 원본 재현의 정교함이 크게 부족하다고 평가했다.
진행자는 낮은 추론 강도가 원인일 수 있다고 생각해 Fable의 설정을 높여 다시 시도했다. 다만 제공 리포트에는 처음에 미디엄으로 올렸다는 설명이 나오고, 이후에는 하이로 실행했다는 설명이 이어져 정확한 재실행 설정을 하나로 확정하기 어렵다. 제공 자료에서 공통적으로 기술된 내용은 진행자가 초기 실행보다 추론 강도를 높이는 실험을 했으며, 그 결과 디테일이 어느 정도 개선되었다고 느꼈다는 점이다. 그럼에도 엄지 위치와 안경 표현, 전체적인 붓 사용은 여전히 거칠었다는 것이 그의 평가였다.
작업 시간의 차이를 보완하기 위해 진행자는 Fable이 약 16분에 작업을 끝냈을 때와 비슷한 시점의 Astra 진행 상황을 비교했다. 영상에서는 Fable의 16분 25초와 Astra의 16분 41초 시점이 언급되며, 진행자는 이 구간에서도 Astra 쪽 완성도가 훨씬 높다고 판단했다. 특히 참고 사진과 캔버스를 오가면서 색을 추출하고 다시 칠하는 과정이 빠르게 반복된다고 설명했다. 다만 실제 도구 호출 횟수나 성공한 클릭 비율을 집계한 자료는 없으므로, 조작량과 정확도에 관한 비교는 타임랩스를 본 진행자의 정성적 평가다.
💡 [영상 참조] 진행자는 Astra가 참고 이미지에서 색을 확인하고 캔버스에 적용하는 과정을 설명한다. 비슷한 작업 시간대의 결과 비교와 색상 선택 과정은 원본 영상 07:43을 참조하면 된다.
진행자는 이 과제에서 두 모델 모두 목표 달성에는 실패했지만, 컴퓨터 사용의 속도와 정교함에서는 Astra가 크게 앞섰다고 결론 내렸다. 여기에는 세밀한 붓 작업이 인터페이스 이해와 좌표 조작 능력을 보여준다는 그의 해석이 깔려 있다. 다만 그림의 품질에는 시각적 재현 전략이나 작업을 지속하는 방식도 영향을 줄 수 있으므로, 결과 차이를 좌표 정확도 하나만으로 설명하기는 어렵다. 이번 사례에서 진행자의 설명이 뒷받침하는 결론은 Astra가 해당 조건에서 더 촘촘하게 수정 작업을 이어갔고, 진행자가 그 결과를 더 높게 평가했다는 것이다.
Numbers — 같은 계산 결과를 얻어도 실행 경로는 달랐다
Numbers 과제에서는 CSV 파일을 열고, 컴퓨터 사용 기능만으로 계산 수식을 입력하며 데이터를 정리하도록 했다. 진행자가 설명한 결과물에는 월별 매출 추이와 채널별 매출 비교가 포함되어 있었다. Astra는 13분 50초에 작업을 마쳤고, Fable은 약 21분이 걸렸으며 비교 구간에서는 21분 27초라는 시간이 언급되었다. 진행자에 따르면 배치에는 차이가 있었지만, 두 모델의 숫자와 시트 내부 계산 결과는 동일했다.
이 과제에서 가장 눈에 띈 차이는 계산 단계에 도달하기 전의 파일 열기 과정이었다. 진행자는 Astra가 파일을 원활하게 열었다고 설명한 반면, Fable은 파일을 찾고 여는 데 2분이 조금 넘게 걸렸다고 말했다. 그는 이런 문제가 한 번만 나타난 것이 아니라 다른 실행과 Keynote 작업에서도 반복되었다고 덧붙였다. 일부 시도에서는 원하는 파일을 찾지 못해 여러 파일을 여는 행동까지 관찰했다고 하므로, 그의 경험에서는 운영체제 파일 선택 창이 반복적인 장애 구간이었다.
이 관찰은 문서 자동화의 성능을 결과물만으로 평가하기 어렵다는 점을 보여준다. 진행자의 설명처럼 계산 결과가 같더라도, 올바른 파일을 찾는 데 오래 걸리거나 사용자가 중간에 개입해야 한다면 전체 작업 경험은 달라진다. 그는 자신의 시험 환경에서는 Fable에 작업을 맡기기 전에 파일 열기나 저장처럼 시스템 창을 다루는 단계를 사용자가 처리해 두는 편이 낫다고 제안했다. 이는 영상에서 관찰한 실패 지점을 줄이기 위한 실용적인 대응이지만, 모든 환경에서 동일하게 필요한 절차라고 검증된 것은 아니다.
💡 [영상 참조] 진행자는 두 모델이 만든 시트의 숫자와 계산 결과는 같고 배치만 다르다고 설명한다. 실제 수식과 차트의 구성은 원본 영상 10:12에서 확인해야 한다.
진행자는 두 결과물을 완벽하다고 평가했지만, 제공 리포트에는 원본 CSV의 행 수나 구체적인 매출 수치, 셀별 수식이 포함되어 있지 않다. 따라서 이 리포트에서 계산식을 재구성하거나 수치의 정확성을 독립적으로 검증할 수는 없다. 기술적으로 중요한 사실은 진행자가 확인한 범위에서 결과 차이가 없었고, 체감 차이는 주로 실행 속도와 파일 탐색의 안정성에서 발생했다는 점이다. 이는 그림 과제에서 보인 품질 격차가 모든 종류의 업무 결과물에 그대로 나타나지는 않았음을 보여준다.
Keynote — 요구사항 충족은 비슷했고 시작과 조작에서 차이가 났다
Keynote 과제에서는 진행자가 슬라이드별로 들어갈 내용을 정하고, 두 모델에 동일한 숫자와 프롬프트를 제공했다. 그림 과제처럼 유사도 목표를 설정한 별도의 목표 프롬프트는 사용하지 않았다고 설명했다. 작업 과정에는 표와 그래프를 만드는 단계가 포함되어 있었으며, 결과 비교에서는 일곱 번째 슬라이드까지 차례로 검토했다. 진행자는 일부 표현과 순위 정보의 차이는 있었지만, 두 모델 모두 요구한 내용을 잘 구현했다고 평가했다.
소요 시간은 Astra가 16분 3초, Fable이 29분 49초였다. 진행자는 Astra가 시작 후 1분도 되기 전에 필요한 항목을 찾고 작업에 들어갔으며, 눈에 띄는 오클릭 없이 진행했다고 설명했다. 반면 Fable은 여러 방식으로 열기를 시도하고 창 배치를 바꾸는 등 시작 과정에서 더 많은 시행착오를 보였다는 것이다. 다만 오클릭 횟수를 별도로 계수한 자료는 없으므로, 이 차이 역시 진행자의 화면 관찰에 근거한 평가다.
Numbers와 Keynote의 결과를 함께 보면, 진행자가 관찰한 Astra의 장점은 업무 내용의 정확성 차이보다 과제에 진입하고 조작을 이어가는 과정에 있었다. 두 모델 모두 정해진 데이터와 요구사항을 문서로 옮기는 데 성공했지만, Fable은 그 결과에 도달하기까지 더 오래 걸렸다. 따라서 이 두 과제만으로는 한 모델의 계산 능력이나 발표 자료 구성 능력이 본질적으로 더 우수하다고 결론 내리기 어렵다. 진행자의 설명에서 더 분명하게 드러나는 것은 해당 설정에서 최종 산출물은 유사했고, 작업 경로와 완료 시간이 달랐다는 점이다.
💡 [영상 참조] 진행자는 완성된 발표 자료를 페이지별로 비교하며 두 모델 모두 지시를 잘 따랐다고 평가한다. 실제 표, 그래프와 슬라이드 배치는 원본 영상 13:22에서 확인할 수 있다.
Fast 모드 — 관측된 속도와 모델 자체의 성능을 구분해야 하는 이유
진행자는 자신이 항상 Fast 모드를 사용한다는 점을 여러 차례 강조했다. 그는 Astra의 Fast 모드 안내에 두 배 빠르다는 설명이 있다고 언급하면서, 이 조건이 속도 비교에 영향을 줄 수 있다고 인정했다. 그러나 그 설명이 다른 모델의 일반 실행 대비 정확히 두 배의 성능을 의미하는지는 알 수 없다고도 말했다. 따라서 영상의 완료 시간은 해당 실행 옵션을 사용했을 때의 관측 결과이며, 동일한 속도 조건으로 보정한 모델 간 비교 결과는 아니다.
| 과제 | Astra에서 언급된 시간 | Fable에서 언급된 시간 | 진행자가 설명한 결과 |
|---|---|---|---|
| Krita 사진 재현 | 49분 | 추론 강도를 높인 실행에서 약 16분, 비교 시점 16분 25초 | 둘 다 목표 유사도에 미달했으며 Astra의 세부 표현을 더 높게 평가 |
| Numbers 데이터 처리 | 13분 50초 | 약 21분, 비교에서는 21분 27초 언급 | 배치는 다르지만 숫자와 계산 결과는 동일 |
| Keynote 발표 자료 제작 | 16분 3초 | 29분 49초 | 두 모델 모두 슬라이드별 요구사항을 충족 |
이 표에서 그림 작업 시간은 동일한 품질에 도달하기까지 걸린 시간으로 비교할 수 없다. 두 모델 모두 목표를 충족하지 못했고, 작업을 종료한 시점과 진행자가 평가한 완성도도 달랐기 때문이다. 반면 Numbers와 Keynote는 진행자가 결과물을 유사하게 평가했으므로, 영상에서 사용한 조건 아래에서는 완료 시간을 비교할 근거가 상대적으로 분명하다. 그 경우에도 Fast 모드와 추론 강도, 시행별 조건이 충분히 통제되었다고 볼 수는 없다.
진행자는 Astra의 작업 시간을 단순히 두 배로 가정하면 Numbers와 Keynote에서는 오히려 Fable보다 느려질 수 있다고 설명했다. 그러나 이는 일반 모드를 직접 실행해 얻은 측정치가 아니라 Fast 모드의 효과를 가정한 비교다. 전체 작업 시간 중 얼마가 추론, 화면 확인, 애플리케이션 반응 대기, 실제 입력에 쓰였는지 제시되지 않았으므로, 모든 작업의 시간이 일괄적으로 두 배가 된다고 확정할 수 없다. 진행자 역시 일반 모드 비교는 추가로 시험해 볼 요소라고 남겼다.
그의 개인적인 선택 기준은 명확했다. 자신은 Fast 모드만 사용하므로, 그 조건에서 Astra가 더 빨랐다는 사실을 중요하게 본다는 것이다. 반면 Fast 모드를 사용하지 않는 사람에게는 두 모델을 실제 업무에 적용해 비교한 뒤 판단하라고 권했다. 결국 영상의 속도 결론은 모든 사용자에게 동일하게 적용되는 순위라기보다, 진행자가 선택한 실행 설정에서 얻은 사용 경험으로 읽는 것이 정확하다.
기술적 인사이트 — 정형 문서와 자유로운 그리기가 드러낸 서로 다른 난도
진행자는 그림 그리기가 가장 어려운 과제였던 이유를 인터페이스와 행동의 구조에서 찾았다. Numbers와 Keynote 같은 작업에서는 조작 대상이 비교적 명확한 위치에 있고, 사각형 영역으로 구분되어 있어 대상을 파악하고 이동하기 쉽다고 설명했다. 반면 그림에서는 붓의 굵기와 움직임, X·Y 좌표를 함께 판단해야 하므로 더 섬세한 조작이 필요하다고 보았다. 이 설명은 같은 컴퓨터 사용 기능이라도 과제에 따라 요구되는 행동의 정밀도가 크게 달라진다는 해석으로 이어진다.
진행자의 관찰을 종합하면, 정형 문서 작업에서는 올바른 대상을 찾아 정해진 작업을 순서대로 수행하는 능력이 두 모델 모두에서 일정 수준 드러났다. 그림 작업에서는 그에 더해 중간 결과와 참고 이미지를 계속 비교하고, 작은 오차를 수정하는 행동을 장시간 반복해야 했다. Astra의 강점은 진행자의 설명상 이러한 반복 수정과 도구 전환에서 더 분명하게 나타났다. 다만 이는 이번 과제에서 얻은 해석이며, 별도의 좌표 정확도 시험이나 도구 호출 로그로 원인을 분리해 검증한 결과는 아니다.
또 하나의 함의는 높은 추론 강도가 반드시 더 세밀한 행동으로 이어지지는 않았다는 점이다. 진행자는 Fable의 추론 강도를 높인 뒤 일부 개선을 관찰했지만, 기대했던 수준의 정교한 그림은 얻지 못했다. 이는 해당 실행에서 설정 변경만으로 품질 격차가 해소되지 않았음을 뜻한다. 다만 정확한 재실행 설정이 제공 리포트에서 일관되지 않고 더 높은 조건을 충분히 시험하지 못했다고 설명한 만큼, 추론 강도를 높여도 개선될 수 없다는 일반적인 결론까지 확장해서는 안 된다.
이번 비교를 바탕으로 평가 방식을 발전시킨다면, 완료 여부와 결과물의 품질, 소요 시간, 사용자 개입을 서로 구분해 기록하는 것이 유용하다. 이는 진행자가 제시한 공식 평가 체계가 아니라, 영상의 관찰에서 도출한 편집적 제안이다. 그림처럼 목표 달성에 실패한 작업과 문서처럼 결과가 유사한 작업을 같은 시간 지표만으로 평가하면 중요한 차이가 가려지기 때문이다. 비용 역시 진행자가 사용량 부담을 언급했을 뿐 구체적인 금액이나 토큰 수를 제공하지 않았으므로, 이번 자료만으로 비용 대비 효율을 비교할 수는 없다.
마무리 / 핵심 정리
진행자가 이번 실험에서 가장 높이 평가한 것은 Astra의 빠른 인터페이스 조작과 세밀한 붓 작업이었다. Krita에서는 두 모델 모두 설정된 유사도 목표에 도달하지 못했지만, Astra가 작은 수정과 색상 선택을 더 자주 수행하며 높은 완성도를 보였다는 것이 그의 판단이다. Numbers와 Keynote에서는 두 모델의 결과물이 모두 요구사항을 충족했고, Astra는 파일을 찾고 작업을 완료하는 과정에서 더 빠른 모습을 보였다고 설명했다. 따라서 그림에서는 정교함의 차이가, 문서 작업에서는 실행 과정의 차이가 비교의 중심이었다.
이 결론을 적용할 때 가장 중요한 조건은 진행자가 사용한 Fast 모드다. 진행자의 설명에서는 Astra의 조작 속도와 문서 작업 완료 시간에 우위가 나타났지만, 일반 모드에서도 같은 순서가 유지되는지와 비용 대비 효율이 어떤지는 확인되지 않았다. 진행자의 최종 제안도 Fast 모드를 사용하는 자신의 조건에서는 Astra를 선호하되, 그렇지 않다면 실제 수행할 작업에 맞춰 두 모델을 비교하라는 것이었다. 이번 영상의 핵심 가치는 단일한 승자 선언보다, 컴퓨터 사용 에이전트의 능력이 세밀한 조작과 문서 작성, 시스템 창 탐색에서 서로 다르게 드러난다는 점을 구체적인 사례로 보여준 데 있다.
📚 출처 및 참고
이번 검수는 사용자가 제공한 STT 기반 리포트의 문맥과 내부 일관성을 확인하는 범위에서 수행했으며, 외부 문서나 공식 벤치마크 수치를 추가하지 않았다. 원본 STT와 음성이 제공되지 않아 오인식 여부를 직접 재확인하지는 못했다. Astra·Fable 등 고유명사는 입력 자료의 표기를 유지했다. Fable의 재실행 추론 강도처럼 설명이 엇갈리는 부분은 하나의 값으로 확정하지 않았다. 결과물의 정확성과 시각적 품질은 진행자의 평가로 기술했으며, 실제 파일이나 화면을 직접 검증한 것으로 표현하지 않았다.
제공 리포트에는 [?]로 표시된 수치가 없었다. 소요 시간과 배속, 목표 유사도는 원문 수치를 유지했으며, 원본 음성과 대조해 검증한 값은 아니다. ‘약 16분’과 ‘16분 25초’, ‘약 21분’과 ‘21분 27초’는 근삿값과 세부 시간의 병기로 보아 유지했다. 스크린샷 목록의 여섯 항목에는 모두 로컬 경로만 있고 webUrl이 없어 이미지를 삽입하지 않았다.
| 구분 | 내용 |
|---|---|
| 원본 영상 | Astra vs Fable Computer Use 리셋권 걸고 맞다이 |
| 채널 | 코드팩토리 |
| 기존 리포트에 기재된 STT 범위 | 00:00–15:31 |
| 리포트 작성 | 2026-09-09 |
| 작성 방식 | 제공된 STT 기반 리포트의 문맥 교정 및 서술형 에디팅 |
| 검증 범위 | 제공 리포트의 표현, 수치 표기의 내부 일관성, 스크린샷 삽입 조건 확인 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었다. 그림의 실제 유사도, 스프레드시트 수식, 슬라이드의 시각적 구성 등은 원본 영상을 참조해야 한다.