GPT6 ASTRA 모델 PLUS 사용자는 어떻게 쓰는게 좋을까?

ASTRA를 PLUS에서 쓰다 보면 처음에는 저도 높은 모드부터 눈이 갑니다.
LOW보다 HIGH가 좋고, HIGH보다 MAX가 당연히 더 좋을 것 같으니까요.

그런데 실제로 작업을 나눠서 생각하면 이야기가 조금 달라집니다.
코딩도 계획할 때와 실제 파일을 수정할 때 필요한 사고량이 다르고, 글쓰기도 구조를 잡을 때와 문장을 다듬을 때 필요한 모드가 다릅니다.

PLUS에서 제가 잡는 기준은 간단합니다.
LOW와 MEDIUM을 평소에 쓰고, HIGH는 생각이 필요한 순간에 잠깐 씁니다.
XHIGH와 MAX는 계속 켜두는 모드가 아니라 정말 어려운 문제나 마지막 검증에 꺼내는 쪽이 낫습니다.

이 기준 하나만 잡아도 ASTRA 사용법이 꽤 편해져요.
무조건 높은 모드로 시작했다가 사용량만 빠르게 쓰는 일이 많이 줄어듭니다.

목차

LOW부터 MAX까지, 저는 이렇게 구분합니다 코딩은 계획과 구현 모드를 나누는 게 좋습니다 글쓰기와 번역은 MEDIUM이 의외로 중요합니다 영상·GUI·3D 편집은 높은 모드보다 범위가 중요합니다 리서치와 전략 분석은 MEDIUM → HIGH가 편합니다 PLUS에서는 모드보다 작업 크기가 더 무섭습니다 결국 영역별로 이렇게 쓰고 있습니다

LOW부터 MAX까지, 저는 이렇게 구분합니다

우선 LOW를 성능이 낮아서 못 쓰는 모드라고 생각하지 않는 게 좋습니다.
이미 해야 할 일이 명확하다면 오히려 LOW가 상당히 잘 맞아요.

예를 들어 수정할 파일과 바꿀 내용이 정해진 코딩, 이미 방향이 잡힌 문장 수정, 반복 번역, 정해진 규칙에 맞춘 편집 같은 작업입니다.
생각보다는 실행에 가까운 일들이죠.

모드	제가 주로 맡기는 일	PLUS에서의 느낌
LOW	구현, 반복 수정, 단순 검토, 정해진 작업 실행	생각보다 쓸 곳이 많습니다
MEDIUM	일반 코딩, 글쓰기, 번역, 문서, 분석	사실상 범용 기본값에 가깝습니다
HIGH	설계, 어려운 디버깅, 글의 구조, 핵심 판단	길게 돌리기보다 짧게 생각시킬 때 좋습니다
XHIGH	여러 원인이 얽힌 난문제, 교차검증	HIGH가 막혔을 때 좁은 범위로 씁니다
MAX	중요한 최종 감사, 마지막 판정	일상용이라기보다 최종 검수용입니다

MEDIUM은 가장 애매해 보이는데 실제로는 가장 자주 쓰게 됩니다.
LOW로 맡기기에는 판단할 게 조금 있고, 그렇다고 HIGH까지 올릴 정도는 아닌 작업이 생각보다 정말 많거든요.

반대로 HIGH 이상부터는 사용법이 달라집니다.
높은 모드를 오래 일하게 만드는 것보다 어려운 판단 하나를 맡기고, 답을 얻은 뒤 다시 LOW나 MEDIUM으로 내려오는 게 훨씬 낫습니다.

코딩은 계획과 구현 모드를 나누는 게 좋습니다

코딩에서 가장 잘 맞는 조합을 하나만 고르라면 저는 HIGH로 계획하고 LOW로 구현하는 방식을 먼저 씁니다.

새 기능을 만들 때 어려운 부분은 사실 코드를 타이핑하는 게 아닙니다.
어떤 파일을 건드릴지, 기존 구조를 어떻게 유지할지, 어디까지 수정해야 할지, 무엇을 테스트해야 하는지를 정하는 과정이 더 어렵습니다.

이 부분을 HIGH에서 먼저 정해놓으면 구현 단계에서는 생각할 범위가 크게 줄어요.
그 상태에서 LOW에게 확정된 계획만 주면 굳이 비싼 사고를 계속 시킬 이유가 없습니다.

새 기능 개발
HIGH 계획 → LOW 구현 → MEDIUM 테스트·수정 → 필요하면 HIGH 최종 리뷰

중간 규모 작업은 처음부터 MEDIUM으로 시작해도 괜찮습니다.
요구사항이 분명하고 프로젝트 구조도 복잡하지 않다면 MEDIUM 하나로 계획과 구현을 어느 정도 같이 처리할 수 있어요.

여기서 중요한 건 HIGH나 MAX가 코드를 더 많이 써준다고 반드시 결과도 좋아지는 건 아니라는 점입니다.
오히려 높은 모드로 단순 기능을 맡겼을 때 필요 없는 추상화나 추가 기능까지 붙으면서 일이 커지는 경우가 있습니다.

그래서 구현 프롬프트에는 한 줄을 자주 붙이는 편입니다.
“요청하지 않은 기능, 의존성, 추상화는 추가하지 말고 가장 작은 충분한 수정으로 끝낼 것.”
이 문장이 의외로 꽤 중요합니다.

디버깅은 조금 다릅니다

버그는 MEDIUM부터 시작하는 편이 편합니다.
간단한 문제라면 여기서 끝나고, 원인이 여러 군데 얽혀 있다면 그때 HIGH를 꺼냅니다.

그리고 HIGH에게 바로 코드를 고치게 하기보다 먼저 원인 분석만 맡기는 방식이 좋았어요.
원인을 좁히고 검증 방법까지 정한 다음 실제 수정은 다시 LOW나 MEDIUM으로 내리는 겁니다.

상황	제가 쓰는 흐름
일반 버그	MEDIUM 조사 → LOW/MEDIUM 수정
두 번 같은 방식으로 실패	HIGH에서 root cause만 분석 → LOW/MEDIUM 수정
여러 시스템이 얽힌 난문제	HIGH → 해결 안 되면 범위를 줄여 XHIGH 1회
놓치면 큰 문제가 되는 최종 검수	HIGH/XHIGH 검토 → 필요한 경우에만 MAX 1회

대형 저장소는 더 조심해야 합니다.
“프로젝트 전체를 읽고 문제를 전부 찾아줘” 같은 요청은 LOW라도 가볍지 않습니다.

저라면 인증, 결제, 스케줄러처럼 영역을 잘라서 봅니다.
모드 한 단계 낮추는 것보다 문제 공간을 절반으로 줄이는 게 PLUS에서는 훨씬 효과가 큽니다.

글쓰기와 번역은 MEDIUM이 의외로 중요합니다

글쓰기라고 무조건 HIGH부터 쓰지는 않습니다.
블로그, 설명문, 일반 문서처럼 방향이 어느 정도 정해진 글은 MEDIUM이 상당히 편합니다.

HIGH의 장점은 처음부터 끝까지 글을 길게 쓰는 것보다 글의 기준을 정하는 데 있습니다.
장편 글이라면 제목, 구성, 목소리, 핵심 문단 하나 정도를 HIGH에서 먼저 잡고 실제 본문은 MEDIUM으로 이어가는 식입니다.

장편·창작 글쓰기
HIGH에서 스타일과 핵심 장면 결정 → MEDIUM으로 본문 생산 → LOW로 문장 수정 → 정말 중요한 장면만 HIGH 재검토

이렇게 하면 매 문단을 HIGH로 생성하지 않아도 처음에 잡아둔 톤을 계속 가져갈 수 있습니다.
HIGH는 좋은 기준을 만드는 데 쓰고, MEDIUM이 그 기준을 따라가게 만드는 방식이죠.

블로그 글은 MEDIUM → HIGH 검수가 편합니다

블로그나 기술 글에서는 MEDIUM으로 초안을 만드는 쪽이 좋습니다.
초안이 나온 뒤 HIGH에게 글 전체를 다시 써달라고 하지 않고 논리만 검사시켜요.

예를 들어 “누락된 전제, 서로 충돌하는 내용, 중복, 설명이 부족한 부분만 찾아라. 새로운 섹션은 만들지 말 것.”처럼 범위를 좁힙니다.
높은 모드는 잘 쓰면 날카로운 검토자가 되지만, 자유롭게 풀어놓으면 원래 없던 이야기를 더 붙이는 쪽으로 갈 때도 있습니다.

번역은 MEDIUM을 기본으로 봅니다

일반적인 짧은 번역은 LOW로도 충분합니다.
실제로 게시하거나 제출해야 하는 자연스러운 번역이라면 MEDIUM부터 시작하는 게 마음이 편해요.

HIGH는 전문 용어가 충돌하거나, 한 문장이 두 가지로 해석되거나, 문학적인 뉘앙스를 어디까지 살릴지 결정해야 할 때만 꺼냅니다.
문서 전체를 HIGH나 MAX로 다시 번역하기보다는 문제가 되는 몇 문장만 잘라서 판단시키는 식입니다.

글 작업	추천 흐름
일반 블로그	MEDIUM 초안 → LOW 수정 → 필요하면 HIGH 논리 검수
창작·장편	HIGH 스타일 → MEDIUM 본문 → LOW 다듬기
기술 문서	MEDIUM 구조·초안 → HIGH 논리 감사 → LOW 편집
일반 번역	LOW 샘플 → MEDIUM 본문 → HIGH 난문장만

영상·GUI·3D 편집은 높은 모드보다 범위가 중요합니다

영상 편집이나 GUI 조작은 처음에는 높은 모드를 쓰면 더 완성도가 올라갈 것 같지만, 저는 오히려 작업을 잘게 자르는 쪽을 먼저 봅니다.

예를 들어 영상 전체를 “프로처럼 완성해줘”라고 맡기는 것보다 MEDIUM에서 컷 방향을 정하고, LOW나 MEDIUM에서 컷 편집·자막처럼 반복 작업을 시키는 방식입니다.

영상 편집
MEDIUM 편집 계획 → LOW/MEDIUM 러프컷·자막·반복 작업 → HIGH 문제 구간 해결 → 마지막은 직접 검수

이때 “이번에는 컷과 자막만 건드리고 음악, 색보정, 전환, 타이틀은 수정하지 말 것”처럼 작업 범위를 닫아두는 게 좋습니다.
범위가 열려 있으면 모드가 높을수록 이것저것 더 해보려다 작업이 커질 수 있어요.

Blender나 3D 작업도 비슷합니다.
MEDIUM에서 전체 방향과 구조를 정하고 LOW/MEDIUM으로 반복 조작, HIGH에서 레퍼런스와 형상이 맞는지 QA를 보는 흐름이 편합니다.

GUI 작업은 특히 높은 모드가 화면을 오래 돌아다니게 두는 것보다 “이번 패스에서 끝낼 일 하나”를 명확하게 정해놓는 게 낫습니다.
결국 PLUS에서는 얼마나 똑똑한 모드를 쓰느냐보다 얼마나 작은 작업 단위로 실행시키느냐가 체감 차이를 더 크게 만들 때가 많습니다.

리서치와 전략 분석은 MEDIUM → HIGH가 편합니다

리서치는 처음부터 HIGH나 MAX로 던지는 것보다 MEDIUM에서 자료와 쟁점을 먼저 정리하는 편이 효율적입니다.

시장, 경쟁사, 가격, 사용자 반응, 위험요소처럼 조사 항목을 잘라 MEDIUM으로 각각 처리하고, 마지막에 HIGH에게 서로 충돌하는 부분이나 중요한 맹점을 보게 합니다.

제가 HIGH를 가장 유용하게 보는 순간도 이런 때입니다.
자료를 더 많이 모으는 게 아니라 이미 모은 자료에서 “이 판단이 왜 틀릴 수 있는지”, “무슨 전제를 놓쳤는지”를 물어볼 때예요.

리서치·전략
MEDIUM으로 분야별 탐색 → MEDIUM으로 정리 → HIGH에서 반론·맹점·최종 synthesis → 정말 중요한 판단만 XHIGH

“내 사업 전체를 조사해서 문제를 모두 찾아줘” 같은 요청은 피합니다.
프롬프트가 한 줄이라고 작업도 작은 건 아니니까요.

PLUS에서는 모드보다 작업 크기가 더 무섭습니다

이 부분은 꽤 중요합니다.
LOW를 쓰면 무조건 사용량이 적고 MAX만 조심하면 된다고 생각하기 쉬운데 꼭 그렇지는 않습니다.

긴 대화가 계속 누적된 상태에서 큰 코드베이스를 읽히거나, research와 도구 실행을 자율적으로 오래 시키면 LOW나 MEDIUM도 작업 자체가 무거워집니다.
그래서 모드를 고르는 것만큼 컨텍스트를 정리하는 게 중요해요.

긴 대화 대신 체크포인트를 남깁니다

프로젝트를 오래 진행한다면 이전 대화를 전부 끌고 가기보다 중간 상태를 짧은 문서로 남겨두는 편이 좋습니다.

checkpoint 예시
목표: 무엇을 완성하는지
현재 상태: 어디까지 끝났는지
확정된 결정: 이미 결정한 내용
수정한 파일: 변경 범위
통과한 테스트: 확인된 부분
남은 문제: 해결하지 못한 부분
다음 작업: 다음에 할 일 하나
변경 금지: 건드리면 안 되는 부분

다음 작업에서는 이 체크포인트와 필요한 파일만 주는 식입니다.
HIGH가 매번 처음부터 프로젝트를 다시 읽고 생각하게 만들지 않는 거죠.

이상한 방향으로 가면 그냥 끊습니다

계획도 없이 파일을 계속 열거나, 부탁하지 않은 리팩터링을 시작하거나, 같은 테스트를 반복하고 있다면 끝까지 기다리지 않습니다.
이런 상태에서 모드를 한 단계 더 올리는 것도 좋은 해결책은 아니더라고요.

문제가 생긴 이유	다음에 할 일
요구사항을 잘못 이해함	HIGH로 올리지 말고 프롬프트부터 수정
필요한 문맥이 빠짐	파일·용어·예시를 추가
작업 범위가 너무 큼	모드보다 먼저 작업을 분할
여러 원인이 얽힌 문제	HIGH에서 원인 분석
HIGH에서도 가설이 충돌함	범위를 좁힌 뒤 XHIGH
최종 검수에서 놓치면 피해가 큼	MAX를 감사용으로 한 번 사용

같은 질문을 LOW, MEDIUM, HIGH, XHIGH, MAX 순서대로 계속 다시 돌리는 방식이 PLUS에서는 제일 아깝습니다.
왜 실패했는지부터 보고 모드를 올릴 이유가 있을 때만 올리는 편이 낫습니다.

결국 영역별로 이렇게 쓰고 있습니다

영역	처음	주 작업	어려울 때	마지막
새 기능 코딩	HIGH 계획	LOW 구현	MEDIUM/HIGH	HIGH 리뷰
소규모 코딩	MEDIUM	LOW/MEDIUM	HIGH	MEDIUM
번역	LOW 샘플	MEDIUM	HIGH 난문장	MEDIUM
창작 글쓰기	HIGH 스타일	MEDIUM 본문	HIGH 핵심 장면	LOW 다듬기
기술 문서·블로그	MEDIUM	MEDIUM/LOW	HIGH 검증	LOW 편집
영상·GUI	MEDIUM 계획	LOW/MEDIUM	HIGH	직접 검수
Blender·3D	MEDIUM 계획	LOW/MEDIUM	HIGH QA	직접 검수
리서치·전략	MEDIUM	MEDIUM	HIGH	필요할 때 XHIGH
중요한 최종 감사	HIGH	필요시 XHIGH	MAX 1회	종료

표로 놓고 보면 패턴이 꽤 분명합니다.
PLUS에서 좋은 사용법은 LOW에서 시작해서 MEDIUM, HIGH, XHIGH, MAX까지 한 칸씩 올라가는 계단식이 아닙니다.

오히려 HIGH → LOW → HIGH, MEDIUM → LOW → HIGH → LOW처럼 오르내리는 방식이 더 잘 맞습니다.
생각이 필요할 때만 올리고, 실행 단계에서는 다시 내리는 겁니다.

MAX도 마찬가지예요.
“가장 좋은 결과가 필요하니까 MAX”가 아니라 “범위가 이미 충분히 좁고, 그래도 마지막 한 번 더 깊게 확인할 가치가 있을 때 MAX” 정도로 보는 게 맞습니다.

ASTRA를 PLUS에서 오래 쓰려면 결국 높은 모드를 얼마나 자주 켜느냐보다 높은 모드에게 어떤 판단 하나를 맡길지를 정하는 게 더 중요합니다.

저는 그래서 평소에는 LOW와 MEDIUM을 중심으로 두고, HIGH는 계획·원인 분석·핵심 검수에 짧게 씁니다.
XHIGH와 MAX가 필요할 정도라면 그 전에 작업 범위부터 한 번 더 줄여봅니다.
PLUS에서는 이 정도가 성능도 챙기면서 사용량까지 관리하기 가장 편한 방식입니다.