GPT-6.1 Sol과 Astra 차이: 성능과 사용 한도

Astra를 쓰자니 사용량이 아쉽고, Sol로 바꾸자니 중요한 조건을 놓칠까 걱정됩니다. 어느 쪽을 선택해야 할까요? GPT-6.1 Sol이 Astra에 가까워졌다는 발표는 이 고민을 더 구체적으로 만듭니다. 성능이 비슷하다면 매번 Astra를 고를 이유가 줄어들기 때문입니다.

실제 사용자들도 두 질문을 함께 던집니다. Plus·Pro 사용자가 의견을 구한 글은 벤치마크 비용 감소가 Codex 사용량 증가로 이어지는지, 높은 추론 강도의 Sol이 Astra를 대신할 수 있는지 물었습니다. 답글에는 만족스럽다는 보고와 긴 작업에서 누락·재작업이 늘었다는 보고가 모두 있습니다. 다른 토론에서는 모델을 나눠 쓰는 구성과 그 구성을 관리하는 부담까지 이야기합니다.

그 차이를 해석하려면 공식 평가에서의 성능, 내 업무의 완료 품질, 구독 사용량을 나눠야 합니다. 우선 Sol이 필요한 결과를 만드는지 확인하고, 중요한 누락이 반복될 때 Astra가 무엇을 개선하는지 비교하는 접근이 가능합니다. 단가가 싸다는 이유만으로 Sol을 고정하거나, 중요한 일이라는 이유만으로 Astra를 고정하면 어느 쪽에서 이익을 얻는지 알기 어렵습니다.

Astra와 Sol을 선택하는 화면부터 확인하기

GPT-6 Astra(아스트라)와 GPT-6.1 Sol(솔)은 AI 모델입니다. ChatGPT Work와 Codex는 그 모델에 일을 맡기는 제품입니다. 같은 모델도 제품이 제공하는 파일·앱·도구와 권한에 따라 할 수 있는 작업이 달라집니다.

GPT-6.1 Sol은 ChatGPT Work와 Codex에서 제공되며 일반 Chat 대화에는 아직 제공되지 않습니다. 일반 대화창에서 이름을 찾지 못했다면 먼저 사용 중인 화면을 확인해야 합니다. Work에서는 문서와 앱을 오가는 작업을, Codex에서는 코딩 중심 작업을 맡길 수 있습니다. 모델을 바꿔도 파일 접근 권한이나 연결된 앱의 권한이 추가되지는 않습니다. 공식 모델 안내

Sol의 출시 제공 대상은 Plus·Pro·Business·Enterprise·Edu입니다. Free·Go는 포함되지 않으며, Enterprise·Edu에서는 관리자가 활성화해야 합니다. Astra 접근과 표시되는 추론 설정도 플랜·클라이언트·워크스페이스 조건에 따라 확인해야 합니다. 사용량 표에 모델 이름이 있다는 사실과 내 계정에서 선택할 수 있다는 사실은 구분하는 편이 좋습니다. 모델 제공 조건과 요금제 안내가 각각 접근과 사용량을 설명합니다.

‘Astra에 가까운 성능’이 확인된 범위

OpenAI의 발표는 GPT-6.1 Sol이 복잡한 코딩·컴퓨터 사용·전문 업무의 여러 평가에서 Astra에 근접한다고 설명합니다. 모든 업무에서 같은 답을 내거나, 어떤 요청도 같은 완성도로 끝낸다는 뜻은 아닙니다. 평가마다 성공으로 세는 결과부터 다릅니다.

DeepSWE v1.1은 실제 코드 저장소의 복잡한 수정 과제, GDP.pdf는 표·차트·각주가 있는 문서의 질문을 다룹니다. OpenAI는 두 평가에서 Sol이 Astra와 같거나 가까운 성능을 약 5분의 1의 작업당 비용으로 냈다고 보고했습니다. 화면을 오가는 OSWorld 2.0에서는 최대 추론 강도에서 Astra보다 2.1%포인트 낮고 작업당 비용은 약 7분의 1이라고 설명합니다. 다만 이 점수는 오프라인 과제의 부분 보상 점수여서 전체 업무 완료율과 다릅니다. 공식 출시 평가

여기서 얻을 수 있는 판단은 Sol을 가벼운 질문에만 한정할 필요가 줄었다는 것입니다. 동시에 과학 연구에서 Astra가 앞섰다는 결과를 모든 번역·문서 작성의 우위로 옮길 수는 없습니다. 읽고 답하는 일, 새로운 결과물을 구성하는 일, 여러 도구를 써서 끝까지 실행하는 일은 겹치는 부분이 있어도 같은 과제는 아닙니다.

평가 환경도 확인해야 합니다. OpenAI는 GPT 평가를 연구 환경이나 API에서 진행했으며, 실제 ChatGPT와 시스템 지침·도구·추론 설정이 다를 수 있다고 명시합니다. 벤치마크는 비교의 출발점이고, 실제 선택은 내가 맡길 자료와 완료 조건에서 다시 확인해야 합니다.

같은 Medium이면 같은 조건일까

모델을 비교할 때는 모델 이름 외에 추론 강도와 속도 모드를 기록해야 합니다. 추론 강도는 문제를 계획하고 검토하는 데 얼마나 힘을 쓸지, 속도 모드는 응답을 얼마나 빠르게 받을지를 조절합니다. 두 설정은 서로 다릅니다. 표시가 모두 Medium이더라도 각 모델에 같은 시간과 토큰 예산을 준 비교는 아닐 수 있습니다.

세 모델을 모두 Medium으로 실행한 로켓 발사 장면 비교가 있습니다. 작성자 digitalml은 브라우저에서 3D 장면을 만드는 도구인 Three.js의 같은 요청을 Sol·Astra·Opus 5.5에 줬다고 적었습니다. 보고한 시간은 Sol 8분 42초, Astra 9분 37초, Opus 38분 54초였습니다. 작성자는 Opus의 연출을 더 좋아했지만, Sol에서는 소리와 화면 이동, Astra에서는 로켓 형태의 문제를 보고했습니다.

댓글에서는 “모두 Medium이어도 같은 시간·토큰 예산을 준 것은 아니다”라는 반론이 나왔습니다. 이 지적은 더 오래 걸린 결과가 더 좋을 수 없다는 뜻이 아닙니다. 각 제품의 Medium으로 한 번 맡겼을 때의 결과와, 같은 시간·비용 안에서 만들 수 있는 최선의 결과는 다른 비교라는 뜻입니다. 작성자 역시 추가 요청으로 Sol·Astra를 개선할 가능성은 인정했지만, 그 재비교 결과를 제시한 것은 아닙니다.

이 게시글은 요청문과 작업 수치를 공개했다는 장점이 있습니다. 그러나 세 모델의 전체 코드·개별 실행 로그·반복 결과를 제공한 통제 실험은 아닙니다. 게시자의 만족도를 보편적인 모델 순위로 바꾸거나, 총 토큰 수를 실제 추론량으로 읽어서는 안 됩니다. 같은 글 안에서도 캐시 입력이 포함된 집계가 사용됐습니다.

OpenAI도 추론 강도가 모델 세대 사이에 정확히 대응하지 않는다고 안내합니다. 따라서 “Sol High 대 Astra High”와 함께 “Sol을 더 높은 강도로 썼을 때 필요한 품질을 얼마의 시간과 사용량으로 충족하는가”를 볼 수 있습니다. 다만 높은 설정의 Sol이 언제나 낮은 설정의 Astra를 대체한다고 보장할 근거는 없습니다. 추론 강도 안내

Max와 Ultra도 구분해야 합니다. Max는 한 작업을 더 오래 추론하는 선택이고, Ultra는 다른 AI 작업자인 서브에이전트에 나눠 맡길 수 있는 실행 방식입니다. 일이 분리되지 않으면 에이전트를 늘리는 이익이 작을 수 있고, 각 에이전트가 별도로 모델과 도구를 사용하므로 토큰 소비도 늘어납니다. Max·Ultra 설명, 서브에이전트 안내

이름이 비슷한 Ultrafast는 빠른 응답을 위한 속도 모드입니다. Ultra를 고르는 이유는 일을 나눌 필요가 있는지에 있고, Ultrafast를 고르는 이유는 응답 대기를 줄일 가치가 있는지에 있습니다. 사용할 수 있는 선택지는 계정과 화면에서 확인해야 합니다.

같은 모델에 대한 평가는 왜 갈릴까

문서를 대조하는 일과 새 장면을 구성하는 일

앞의 Plus·Pro 질문 글에서 한 사용자는 같은 High로 여러 문서를 검색해 답변에 연결하는 RAG 시스템의 구조를 점검했을 때 두 모델이 대체로 비슷했고, Sol이 일부 운영 세부사항을 더 찾아냈다고 보고했습니다. 월 100달러 플랜의 다른 사용자는 High끼리 결과 차이를 크게 느끼지 못하면서 사용량이 더 천천히 줄었다고 적었습니다.

반면 3D 콘텐츠를 만드는 Unity(유니티)에서 반복되지 않는 방과 공간을 구성하던 사용자는 Sol이 단조로운 결과를 만들고 조건을 놓쳐 재지시가 필요했다고 보고했습니다. 후속 댓글에서는 Sol로 생성한 뒤 Astra로 검토·수정하는 방식으로 바꿨다고 설명했습니다. 높은 설정을 써 봐도 만족스러운 개선이 크지 않았다는 경험도 함께 남겼습니다.

이들은 입력·출력·채점표를 모두 공개한 실험이 아닙니다. 문서에서는 Sol, 공간 작업에서는 Astra가 항상 이긴다고 결론 내릴 수 없습니다. 다만 이미 있는 내용을 대조하는 과제와 여러 조건을 새 결과물에 계속 유지하는 과제를 따로 비교할 이유는 보여 줍니다. 게임에서도 고양이와 간식을 화면에 그리는 일과, 손가락으로 움직여 점수를 얻고 장애물에 닿으면 끝나게 만드는 일은 다른 완료 조건입니다.

연구 작업의 댓글도 비슷한 구분을 합니다. 뇌파와 신호처리를 다룬다는 사용자는 코드와 검증 가능한 결과를 만드는 도움, 여러 논문의 해석을 유지하며 글의 논지를 만드는 도움을 나눠 설명했습니다. 후자에서는 Astra를 더 선호한다고 했습니다. 이것은 연구 전반의 성능 순위가 아니라, 같은 사람이 업무의 종류에 따라 다른 모델을 선호한 사례입니다.

미완료와 과잉 구현은 다른 실패입니다

Sol이 중간에 멈춘다는 글의 작성자는 진단과 수정을 요청했는데 진단 설명에서 끝나는 경험을 보고했습니다. 반대로 다른 댓글은 많은 기능을 덧붙이면서 정작 요청한 핵심 작업을 빠뜨리는 문제를 지적했습니다. 적게 만들고 멈추는 것과 범위 밖에 많이 만들면서 핵심을 놓치는 것은 다른 실패입니다.

게임을 부탁했는데 첫 화면만 만들고 플레이할 수 없으면 미완료입니다. 배경과 음악을 잔뜩 넣었어도 장애물에 닿은 뒤 계속 점수가 오르거나 다시 시작 버튼이 먹히지 않는다면 마찬가지입니다. 더 긴 답이나 더 많은 기능이 필요한 동작의 누락을 보상하지는 않습니다.

실패를 모두 낮은 추론 강도 탓으로 돌리는 것도 성급합니다. 게임 제작 실패를 다룬 글의 작성자는 처음 Medium으로 실행했고, 높은 설정에서도 비슷했다고 보고했습니다. Ultra와 Blender로 다시 시도한 결과도 소개했지만, 그 후속 글만으로 실패나 해결을 확정할 수는 없습니다. 같은 스레드의 다른 사용자는 반복 업무의 지침을 담은 스킬 파일의 설정을 보고 명시 호출이 필요했을 수 있다고 자신의 기대를 수정했습니다. 명시 호출 뒤 첫 검토·수정은 진행했으나 재검토 누락은 남았다고 했습니다.

어느 사례도 모든 실패의 원인을 입증하지는 않습니다. 모델을 바꾸기 전에 필요한 자료·도구 접근·현재 지침을 확인할 이유가 있고, 그 조건을 맞춘 뒤에도 누락이 남는지 비교할 이유도 있습니다. 실패를 전부 사용자 탓으로 돌리거나, 전부 모델 능력의 문제로 확정하면 바꿔야 할 지점을 놓칩니다.

조건을 공개한 24개 코딩 과제 비교

Stet 개발자 Ben Redmond의 24개 과제 비교는 자신의 비공개 Go·TypeScript 코드 저장소에서 이미 반영한 변경을 다시 구현하게 했습니다. 같은 자료·요청, Codex Medium, 과제당 1회이며 검증용 테스트는 숨겼습니다.

GPT-6 Sol과 GPT-6.1 Sol의 비교이며 Astra는 없습니다. 테스트·기존 수정과의 동등성 53%, 체크리스트·코드 리뷰 47%를 합친 평가에서 6.1 Sol은 9승·10무·5패였습니다. 체크리스트·리뷰에는 AI 심사도 쓰였습니다. 정확성 항목의 점수만 보면 22개에서 같았고 2개에서는 6.1 Sol이 낮았습니다. 승패를 테스트 통과율로 읽어서는 안 됩니다.

비용은 22개 과제에서 낮았고, 과제별 상대 비용의 중간값은 0.56배였습니다. 당시 Standard API 단가로 환산한 값이며 심사 비용은 제외됐습니다. Codex 포함 사용량 소비가 0.56배가 됐다는 측정은 아닙니다. 원문은 요청·패치 일부를 공개하지만 전체 과제와 숨긴 테스트는 비공개입니다.

추가·삭제한 줄 수 합계의 중간값도 303줄로 이전 Sol의 197줄보다 컸습니다. 테스트 코드가 늘었으므로 전부 낭비라고 볼 수는 없습니다. 댓글에서는 검토 부담을 지적했지만, 실제 사람의 검토 시간은 측정하지 않았습니다.

비용이 낮아도 남은 오류와 검토 부담까지 확인해야 합니다. 이 실험을 Astra와 같다는 증명이나 모든 팀의 교체 근거로 가져오기는 어렵습니다.

Plus·Pro 사용 한도와 API 가격을 나누어 읽기

앞서 나온 “비용이 68.8% 줄면 약 3.2배 더 쓸 수 있나?”라는 질문에서 68.8%는 작성자가 인용한 벤치마크 실행 비용의 감소입니다. 같은 예산으로 같은 단위의 비용을 지불한다면 배수 계산을 할 수 있지만, 벤치마크 비용과 구독 사용 한도가 같은 단위라는 전제가 없습니다. 질문을 실제로 3.2배 더 썼다는 결과로 읽으면 안 됩니다.

공식 안내의 Sol 15–160, Astra 5–45는 Plus·Standard Business의 5시간당 로컬 메시지 추정 범위입니다. 고정 질문 횟수나 보장된 작업 수가 아닙니다. 모델·작업의 크기·맥락·추론·도구 사용·캐시에 따라 소비량이 달라지고, 클라우드 작업은 더 많이 소모할 수 있습니다. 공식 사용량 안내

Plus·Standard Business의 5시간당 로컬 메시지 추정치. 모델 접근 권한을 보장하는 목록이나 Pro의 한도는 아닙니다.

160을 45로 나눠 “항상 약 3.6배 쓸 수 있다”고 계산할 수도 없습니다. 두 범위는 같은 작업을 각각 몇 번 실행했다는 쌍이 아닙니다. 로컬은 자신의 기기 환경에서 진행하는 작업과 관련되고 클라우드는 원격 환경에서 진행합니다. 앱에서 클라우드 작업도 시작할 수 있으므로, 앱을 썼다는 사실만으로 로컬 메시지 추정치를 적용해서는 안 됩니다. 작업 환경 안내

Pro에는 현재 5시간 제한이 없다고 안내돼 있지만 주간 한도 등이 적용될 수 있습니다. Work와 Codex는 사용량을 공유합니다. 다른 모델이나 연결된 기능을 함께 썼다면 감소분을 이번 한 작업에만 돌리기 어려워집니다. 비교 전에 자신의 플랜·남은 사용량·리셋 시점을 같은 사용량 화면에서 확인하는 편이 좋습니다.

사용자가 적은 “주간 사용량 1%”도 플랜이 다른 사람끼리 같은 양은 아닙니다. 로켓 비교 글의 작성자는 서로 다른 가격의 Claude와 ChatGPT 구독을 썼습니다. Sol 작업 뒤 표시가 움직이지 않았다는 보고도 소비량이 0이거나 무제한이라는 근거가 되지는 않습니다. 표시 변화만으로 정확한 토큰 수나 비용을 역산하지 않는 편이 맞습니다.

사용량에 대한 반대 경험도 있습니다. 게임 AI를 구현한 사용자는 Astra를 연속으로 쓰면 자기 한도가 약 12시간 정도 간다고 추정하며, 자기 작업에서는 6.1 Sol보다 훨씬 많이 소비한다고 적었습니다. 반면 다른 사용자는 pi라는 별도 에이전트 도구에서 Astra의 높은 추론 설정을 쓰고도 월 100달러 플랜을 소진하지 않았다고 답했습니다. 같은 작업을 같은 기간 수행한 비교가 아니고, 소비량의 측정 방법과 전체 로그도 없습니다. 한 사람의 배수를 예상 질문 횟수로 옮기기보다 어떤 도구에서 얼마나 오래, 어떤 결과까지 맡겼는지를 함께 읽어야 합니다.

API는 별도의 과금 방식입니다. 개발자가 서비스·자동화에서 모델을 호출할 때 처리한 토큰 등에 따라 비용을 냅니다. 토큰은 AI가 문장 등을 나누어 처리하는 단위로, 글자 수나 질문 횟수와 같지 않습니다. 기본 Standard 단가는 다음과 같습니다. Sol API 가격, Astra API 가격

100만 토큰당 주요 Standard API 토큰 단가. 272K 이하 입력 요청의 기본 요율이며 구독 사용량 표와 다릅니다.

일반 입력·출력 단가는 각각 5분의 1, 캐시 입력 단가는 10분의 1입니다. 캐시 입력은 저장한 맥락을 재사용해 읽는 요율이며, 캐시 쓰기에는 별도 요율이 있습니다. 입력 토큰을 모두 일반 입력 단가로 계산하면 실제 과금과 어긋날 수 있습니다. 두 모델 모두 한 요청의 입력이 272K 토큰을 넘으면 그 요청 전체의 입력·캐시 요율은 2배, 출력은 1.5배가 됩니다. 속도 모드와 도구 비용도 별도 조건입니다.

실제 작업당 비용은 토큰 수·캐시·재시도에 따라 달라집니다. 입력·출력 단가가 5분의 1이어도 같은 일을 끝내는 비용이 늘 정확히 5분의 1은 아닙니다. API 비용을 계산하려는 독자는 Astra와 이전 Sol의 비용·성과를 나눠 보는 글을 이어서 읽을 수 있습니다.

느린 응답과 오래 걸리는 업무는 다릅니다

Sol이 4.6배 느리다는 게시글은 작성자의 Extra High 측정에서 이전 5.6 Sol이 초당 102.6토큰, 6.1 Sol이 22.3토큰, 6.1 Sol의 Fast가 64.2토큰이었다고 보고했습니다. 그러나 프롬프트·출력 길이·반복 횟수·측정 시간대·클라이언트 버전은 충분히 공개하지 않았습니다. 이 수치로 모든 사용자에게 같은 지연을 예상시키거나, 회사가 의도적으로 속도를 제한했다고 결론 내릴 수는 없습니다.

초당 토큰은 답변을 생성하는 속도입니다. 자료를 찾고, 파일을 열고, 도구를 실행하고, 잘못된 결과를 고쳐 최종 전달하는 시간과는 다릅니다. 빠르게 답한 뒤 세 번 고치는 작업이 처음에는 느려도 한 번에 필요한 결과를 내는 작업보다 오래 걸릴 수 있습니다.

앞의 Stet 비교에서도 6.1 Sol과 6 Sol의 완료 시간 중간값은 각각 11.0분·12.7분이었지만, 6.1 Sol이 먼저 끝난 과제는 24개 중 11개였습니다. 이 비용 이점이 모든 과제의 시간 이점을 뜻하지 않았습니다. 속도 후기와도 모델 버전·과제가 다르므로 두 결과를 같은 대조 실험처럼 합치면 안 됩니다.

장시간 실행도 완성의 증거는 아닙니다. 곡면을 다루는 NURBS 모델링 작업을 비교한 사용자는 Astra와 Opus 5.5에 같은 시작 저장소·작업 명세·테스트를 줬다고 설명했습니다. 작성자의 보고에 따르면 요구사항과 테스트가 충돌할 때 Opus는 잘못됐다고 판단한 테스트를 고쳤고, Astra는 기존 테스트에 맞추려 했습니다. 느린 테스트를 몇 번 실행했는지가 전체 시간에도 큰 영향을 줬으며, 두 결과 모두 아직 완성되지 않았습니다. 6.1 Sol의 직접 비교는 아니지만, 응답 속도나 실행 시간 하나로 실제 완료를 판단하기 어려운 이유를 보여 줍니다.

이 사례만으로 어느 쪽의 판단이 옳았는지는 확인할 수 없습니다. 비공개 작업의 요구사항과 테스트가 실제로 충돌했는지도 작성자의 설명에 의존합니다. 다만 테스트 통과만 목표로 두면 원래 요구가 밀릴 수 있고, 요구사항을 따르겠다며 테스트를 임의로 바꾸는 것도 위험합니다. 게임의 점수 계산 검사를 통과해도 정작 휴대폰에서 고양이를 움직일 수 없다면 사용자가 원한 결과는 아닙니다. 완료 기준에는 계산·테스트뿐 아니라 그 검사가 원래 목적을 지키는지도 들어가야 합니다.

즉시 답을 기다려야 하는 회의 준비와 밤에 맡겨 두는 자료 정리는 기다림의 가치가 다릅니다. 속도 게시글의 댓글에서도 대기를 줄이는 일이 중요하다는 의견과, 비동기 작업에서는 시간보다 완료 결과·작업당 비용이 중요하다는 의견이 함께 나왔습니다. 내 업무가 어느 쪽인지부터 정해야 속도 모드의 추가 사용량을 판단할 수 있습니다.

Fast·Ultrafast는 같은 모델의 Standard 대비 포함 구독 사용량을 각각 2.5배·8배의 요율로 소모합니다. 구매한 크레딧에는 2배·6배가 적용돼 포함 사용량과도 다릅니다. Ultrafast는 Pro 500달러 플랜과 지원되는 Enterprise·Edu에서 제공됩니다. API 키로 쓰면 구독 계수 대신 API 단가를 적용합니다. 공식 속도 안내

예를 들어 응답 대기를 줄이는 이익이 크다면 Fast를 비교할 수 있습니다. 하지만 2.5배의 사용 요율이 모든 업무를 2.5배 빨리 끝낸다는 뜻은 아닙니다. 파일 읽기나 외부 도구가 느린 작업이라면 모델의 응답 속도만 올려도 전체 시간이 기대만큼 줄지 않을 수 있습니다.

게임·앱을 만들 때 비교할 것

“게임 하나 만들어 줘”라고 맡겼을 때 궁금한 것은 첫 답변의 길이보다 내가 해 보고 싶은 것이 실제로 만들어졌는가입니다. 다음은 두 모델에 줄 수 있는 가상 요청과 확인 기준입니다. 어느 모델이 성공했다는 결과를 가정하지 않고, 같은 작업에서 차이를 찾는 방법을 보여 줍니다.

고양이 간식 게임: 화면을 보는 데서 한 판 해 보기로

휴대폰 브라우저에서 손가락으로 고양이를 움직여 떨어지는 간식을 받고, 장애물을 피하는 작은 게임을 만든다고 해 보겠습니다. 로그인이나 온라인 순위표까지 넓히기보다 먼저 한 판을 시작하고 끝낼 수 있는 범위를 정합니다.

휴대폰 브라우저에서 바로 하는 고양이 간식 게임을 만들어 주세요. 손가락을 좌우로 움직이면 고양이가 따라오고, 간식을 받을 때마다 1점씩 올라가게 해 주세요. 장애물에 닿으면 게임을 끝내고 최종 점수와 다시 시작 버튼을 보여 주세요. 다시 시작하면 현재 점수는 0점으로 돌아가되 최고점은 유지해 주세요. 같은 브라우저에서 새로고침해도 최고점이 남아야 합니다. 컴퓨터에서도 방향키로 조작할 수 있게 하고, 실행 방법과 제가 눌러 볼 확인 순서를 알려 주세요.

크게 보기

×확대 이미지 닫기

두 모델에는 같은 요청과 같은 시작 파일을 각각 새 작업에서 전달합니다. 한쪽만 완성된 코드를 참고하게 하거나, 한쪽에만 앞선 오류 설명을 남겨 두면 다른 작업이 됩니다. 추론 강도·속도 모드도 기록하고, 먼저 나온 화면은 같은 기기에서 직접 움직여 봅니다.

흥미로운 차이는 다음 요청에서 더 드러날 수 있습니다. “간식과 장애물의 낙하 속도를 조금 낮추고 시작 전에 조작 안내를 보여 주세요. 점수·충돌·재시작·최고점 저장은 그대로 유지해 주세요”라고 두 모델에 똑같이 수정 요청을 합니다. 새 안내가 생겼는지만 보지 말고 한 판을 끝낸 뒤 다시 시작하고 새로고침해 봅니다.

Sol이 원하는 모양과 동작을 적은 수정으로 충족한다면 그 게임에 Astra를 계속 쓸 이유는 작아집니다. 반대로 같은 핵심 동작을 반복해서 빠뜨리거나 하나를 고칠 때마다 다른 기능이 깨진다면, 추론 강도를 바꾸거나 Astra에 같은 시작점과 요청을 주고 비교할 이유가 생깁니다. 첫 시안의 인상과 플레이·수정까지 끝낸 품질을 따로 기록하는 것이 핵심입니다.

습관 기록 앱: 체크 표시보다 다시 열었을 때

게임보다 앱을 만들고 싶다면 “물 마시기·걷기·독서를 매일 체크하는 개인 앱”으로 바꿔도 됩니다. 여기서는 오늘의 세 항목을 체크하고 취소할 수 있으며, 같은 브라우저에서 새로고침한 뒤에도 선택이 남는 것을 첫 완료 조건으로 잡습니다. 여러 기기의 동기화나 다른 사람과의 공유는 별도 기능입니다.

크게 보기

×확대 이미지 닫기

체크할 때 잠깐 색만 바뀌고 다시 열면 모두 사라진다면, 보기 좋은 화면은 만들었어도 요청한 저장은 빠진 것입니다. “메모 기능을 추가해 주세요. 기존 체크 기록은 보존해 주세요”라고 수정했을 때도 같은 항목을 다시 확인합니다. 두 모델에 모든 앱을 통째로 만들어 보라고 하기보다, 내가 자주 쓸 작은 기능 하나가 끝까지 작동하는지부터 비교하면 실패와 개선을 알아보기 쉽습니다.

Sol로 만들고, 막히는 문제와 계획은 Astra에

가성비를 중심에 두고 쓴다면 평소 구현과 수정은 Sol로 진행하고, 잘 풀리지 않는 문제나 중요한 초기 계획에 Astra를 투입하는 방식을 출발점으로 권할 만합니다.

고양이 게임의 첫 버전과 화면 수정은 Sol에 맡겨 볼 수 있습니다. 그런데 최고점 저장 오류를 고쳐 달라고 해도 같은 문제가 되풀이되거나, 충돌 처리를 고칠 때마다 재시작이 깨진다면 Astra에 현재 파일과 실패 상황을 넘겨 원인 분석과 수정을 맡겨 볼 수 있습니다. 문제가 해결되면 나머지 기능 추가와 반복 수정은 다시 Sol로 이어 갑니다. 같은 문제를 고쳐 달라는 요청에 더는 진전이 없다면 역할을 바꿔 볼 지점입니다.

만들기 전에 방향부터 분명히 하고 싶을 때도 Astra를 활용할 수 있습니다. 어떤 화면이 필요한지, 게임 규칙과 저장은 어떻게 이어지는지, 무엇부터 만들고 어떤 기능은 뒤로 미룰지 먼저 계획하게 합니다. 예를 들어 “고양이 게임의 규칙·조작·저장·완료 조건을 정리하고, 첫 버전을 만들 순서를 세워 주세요”라고 요청한 뒤 계획을 확인해 Sol에 구현을 넘기는 방식입니다. 습관 앱도 오늘의 체크와 기록 보존부터 만들지, 날짜별 기록까지 필요한지 이 단계에서 정할 수 있습니다.

실제 사용자들의 역할 분담도 이 방향을 참고할 근거가 됩니다. Unity 장면 제작자는 Sol로 만든 뒤 Astra로 검토·수정했고, 다른 사용자는 Astra에 조율·최종 확인을, Sol에 구현을 맡겼다고 설명했습니다. 계획·구현·검토를 나눈 사용자 역시 Astra로 계획하고 Sol로 구현하는 구성을 썼지만, 구성을 계속 관리하는 번거로움도 이야기합니다. 이 댓글은 Sol의 세부 버전을 밝히지 않았으므로 6.1 Sol의 비용 절감 효과를 측정한 결과로 볼 수는 없습니다.

인수인계는 길게 늘이기보다 필요한 내용을 모아 주는 편이 좋습니다. Astra에 문제를 넘길 때는 현재 파일, 원했던 동작, 실제로 일어나는 현상, 이미 해 본 수정을 함께 전달합니다. Sol로 작업을 돌려줄 때도 합의한 계획이나 Astra가 수정한 내용, 유지할 기능을 같이 넘깁니다. 같은 사용자의 후속 답변도 검토할 범위를 정한 자료 묶음을 전달하는 방식으로 바꿨다고 설명합니다.

이때 볼 것은 원하는 기능이 완성됐는지, 같은 문제를 다시 설명하는 횟수가 줄었는지, 전체 사용량과 수정 시간이 감당할 만한지입니다. 공식 모델 선택 안내도 품질·시간·비용을 함께 비교하도록 권합니다. 역할을 나누는 데 드는 전달과 재확인 시간까지 포함해 자신의 작업에서 이익이 나는지 보면 됩니다.

가성비를 생각한다면 Sol로 작업을 이어 가다가 잘 풀리지 않는 부분에 Astra를 쓰는 방식부터 시작해 보세요. 처음 계획을 탄탄하게 잡고 싶은 작업이라면 Astra로 방향을 정하고 Sol로 구현하면 됩니다. Astra의 사용량을 모든 단계에 쓰기보다, 문제를 풀거나 방향을 정하는 데 도움이 필요한 순간에 집중하는 활용법입니다.