openAI 에서 astra를 발표한지 일주일쯤 되어 갔다.
친구들과 돈을 모아 pro 를 사용하고 있는 나는 이번 astra 모델이 메모리를 많이 잡아먹는다고 해서 쉽게 사용하지못하고 있었다.
그런데 학교에서 이번에 참여하는 프로젝트에서 개인별 gpt pro 모델을 일정기간동안 대여를 해주어 편히 사용할 수 있는 계정이 하나 생겼다.
GPT-6 Astra 사용 후기 — AI가 코드를 잘 짜는 것을 넘어 일을 하기 시작했다
기존에도 ChatGPT를 코딩, 과제, 프로젝트 기획, 오류 해결 등 여러 작업에 자주 사용했다. GPT-5 계열 모델도 충분히 좋은 성능을 보여줬기 때문에 사실 처음에는 Astra가 얼마나 큰 차이를 보여줄지 크게 기대하지 않았다.
그런데 실제로 사용해보니 단순히 답변의 정확도가 조금 좋아진 정도보다는 AI를 사용하는 방식 자체가 조금 달라졌다는 느낌을 받았다.
예전에는 내가 문제를 잘게 나누고 하나씩 시키는 느낌이었다면, Astra는 어느 정도 목표를 알려주면 스스로 필요한 작업을 판단하면서 진행하려는 모습을 보여줬다.
이번 글에서는 GPT-6 Astra를 사용하면서 느꼈던 점을 정리해보려고 했다.
GPT-6 Astra란?
GPT-6 Astra는 OpenAI가 공개한 최신 모델로, 기존 GPT 모델보다 추론과 복잡한 작업 수행 능력이 강화된 모델이다.
특히 이번 모델에서 개인적으로 가장 관심이 갔던 부분은 단순한 질의응답 능력보다 Agentic Task, 즉 여러 단계를 거치는 작업을 스스로 처리하는 능력이었다.
예를 들어 기존에는
이 코드 오류 찾아줘
→ 수정해줘
→ 테스트 코드 만들어줘
→ 다른 파일에도 문제가 있는지 확인해줘와 같이 작업을 나눠서 요청하는 경우가 많았다.
Astra에서는
현재 프로젝트에서 이 기능에 문제가 있는 것 같다.
관련 코드를 확인하고 원인을 찾아서 수정한 뒤 문제가 없는지도 확인해줘.정도로 요청해도 작업의 범위를 파악하고 접근하려는 모습을 보였다.
단순히 질문에 답하는 AI라기보다는 조금씩 작업을 맡길 수 있는 AI에 가까워지고 있다는 느낌을 받았다.
1. 가장 먼저 느낀 점은 말귀를 잘 알아듣는다는 것이었다
Astra를 사용하면서 가장 먼저 체감했던 부분이었다.
AI를 사용하다 보면 생각보다 자주 발생하는 문제가 있다.
내가 원하는 것은 A인데 AI가 A와 관련된 B, C까지 설명하면서 정작 A는 제대로 해결하지 않는 경우였다.
특히 이전 모델에서는 설명을 굉장히 길게 하거나 필요하지 않은 부분까지 수정하는 경우가 있었다.
Astra에서는 이런 현상이 상대적으로 줄었다고 느꼈다.
내가 원하는 작업이 무엇인지 먼저 파악하고 그 작업을 중심으로 답변하려는 성향이 강했다.
예를 들어 개발 과정에서
현재 구조는 유지하고 이 부분만 수정해줘.라고 요청했을 때 기존에는 프로젝트 구조 자체를 다시 설계하거나 새로운 패턴을 제안하는 경우가 있었다.
Astra는 상대적으로 요청한 범위를 유지하면서 문제를 해결하려는 경향이 강했다.
사소해 보일 수도 있지만 실제 개발할 때는 꽤 중요한 차이라고 생각했다.
AI가 똑똑한 것과 AI와 같이 일하기 편한 것은 다른 문제이기 때문이다.
2. 코딩에서는 단순 코드 생성보다 문제 분석 능력이 인상적이었다
개발하면서 AI를 사용할 때 가장 가치 있다고 느끼는 기능은 코드 생성 자체가 아니다.
사실 CRUD 코드나 간단한 API 정도는 대부분의 최신 AI가 충분히 잘 작성한다.
오히려 실제 프로젝트에서는
왜 이 코드가 동작하지 않는가?
를 찾는 작업이 훨씬 어렵다.
Astra를 사용했을 때 이런 문제 분석 능력이 꽤 좋아졌다고 느꼈다.
단순히 에러 메시지만 보고 코드를 수정하는 것이 아니라 관련된 코드의 흐름을 확인하고 문제의 원인을 찾으려고 했다.
예를 들어 백엔드 프로젝트라면
Controller
↓
Service
↓
Repository
↓
Database전체 흐름을 보고 문제를 찾으려는 방식이었다.
기존 모델에서도 가능한 작업이었지만 Astra에서는 여러 파일이나 여러 조건이 연결된 문제를 조금 더 안정적으로 따라가는 느낌이 있었다.
해외 사용자 후기에서도 비슷한 평가가 있었다. 기존 모델이 오랫동안 복잡하게 만들었던 부분을 Astra가 찾아내거나 구조적인 문제를 발견했다는 평가가 있었다.
다만 이 부분은 뒤에서 설명하겠지만 항상 완벽하지는 않았다.
3. “코드 작성 AI”보다 “코드 리뷰 AI”로 쓸 때 더 좋았다
개인적으로 Astra의 장점을 가장 잘 활용할 수 있는 방법이라고 생각했다.
처음부터
이 프로젝트 만들어줘.라고 하는 것보다는
현재 프로젝트 구조를 분석해줘.
중복 코드
불필요하게 복잡한 구조
잠재적인 버그
예외 처리 부족
테스트가 필요한 부분
을 찾아줘.와 같이 사용하는 방식이 더 효과적이었다.
AI에게 개발 전체를 맡기는 것보다 내가 작성한 코드의 두 번째 개발자 역할을 맡기는 방식이었다.
사람이 혼자 개발하다 보면 자신이 작성한 코드의 문제점을 찾기 어렵다.
특히 프로젝트가 커지면
“일단 동작하니까 넘어가자.”라고 작성했던 코드들이 계속 쌓이게 된다.
Astra에게 전체적인 관점에서 코드를 분석하도록 하면 이런 부분을 다시 확인하기 좋았다.
실제로 Astra 관련 개발자 후기에서도 기존 코드의 문제를 찾아내거나 과도하게 복잡해진 구조를 단순화하는 능력에 대한 긍정적인 평가가 있었다.
4. 긴 작업을 처리하는 방식이 달라졌다
Astra에서 가장 흥미로웠던 부분 중 하나였다.
기존 AI를 사용할 때는 사용자가 프로젝트 매니저 역할을 해야 했다.
1단계 해줘.
2단계 해줘.
3단계 확인해줘.
4단계 수정해줘.계속해서 사람이 다음 작업을 알려줘야 했다.
Astra는 상대적으로 목표 중심으로 움직이는 느낌이 강했다.
예를 들어
이 기능을 구현하는 데 필요한 파일을 확인하고 구현한 다음 테스트까지 진행해줘.라고 하면 단순히 코드 한 조각을 생성하는 것이 아니라 작업 자체를 완료하려고 했다.
이 차이는 앞으로 AI 개발 도구가 어떤 방향으로 발전할지를 보여주는 부분이라고 생각했다.
AI에게
코드를 작성해줘.
라고 하는 시대에서
이 작업을 끝내줘.
라고 하는 시대로 넘어가고 있다는 느낌이었다.
5. 그렇다고 무조건 믿고 맡길 수준은 아니었다
Astra가 확실히 발전한 모델이라고 느꼈지만 사용하면서 가장 중요하다고 생각했던 부분도 있었다.
AI가 더 똑똑해졌다고 해서 검토가 필요 없어지는 것은 아니었다.
오히려 AI가 더 많은 작업을 수행할수록 결과를 검증하는 것이 중요해졌다.
특히 기존 프로젝트에 기능을 추가하는 작업에서는 주의해야 했다.
Astra를 사용한 개발자들의 후기 중에서는 기존 프로젝트에서 이미 사용하고 있는 컴포넌트나 구조가 있는데도 새로운 구조를 만들거나, 공통 영역에 특정 기능의 로직을 넣는 등의 문제가 발생했다는 사례도 있었다.
즉,
코드가 동작한다.와
프로젝트에 적절한 코드다.는 다른 문제였다.
AI는 첫 번째는 굉장히 잘하고 있지만 두 번째는 여전히 사람이 확인해야 한다고 느꼈다.
6. 기존 프로젝트에서는 컨텍스트를 명확하게 줘야 했다
Astra가 아무리 좋은 모델이라고 해도 프로젝트의 모든 의도를 자동으로 알 수는 없었다.
예를 들어 개발자가
우리는 Service Layer에서만 비즈니스 로직을 작성한다.
Controller에서는 DTO 변환만 처리한다.
Entity를 API Response로 직접 반환하지 않는다.
새로운 기능을 만들 때 기존 Util과 Component를 먼저 확인한다.라는 규칙을 가지고 있다고 해도 AI가 이를 자동으로 알고 있는 것은 아니다.
따라서 Astra를 사용할 때도 프로젝트의 규칙을 명확하게 전달하는 것이 중요했다.
예를 들어 단순히
로그인 기능 추가해줘.라고 하는 것보다
현재 프로젝트 구조와 기존 코딩 컨벤션을 먼저 확인해줘.
새로운 구조를 임의로 만들지 말고 기존 Service, Repository,
DTO 패턴을 그대로 사용해서 로그인 기능을 추가해줘.
구현 후 기존 코드와 충돌하는 부분이 없는지도 확인해줘.라고 요청하는 것이 훨씬 안정적이었다.
결국 모델의 성능이 좋아질수록 프롬프트가 필요 없어지는 것이 아니라 프롬프트의 역할이 달라지는 것 같았다.
세부 코드를 설명하는 프롬프트보다 프로젝트의 목적과 제약조건을 설명하는 것이 더 중요해졌다.
7. 가끔은 너무 열심히 일하는 것도 문제였다
재미있게 느꼈던 단점이었다.
Astra에게 어느 정도 자유롭게 작업을 맡기면 생각보다 많은 부분을 건드리려고 했다.
개발자 입장에서는
나는 이 버그 하나만 고치고 싶은데?라는 상황에서도 주변 구조를 개선하거나 다른 문제까지 해결하려는 경우가 발생할 수 있었다.
이런 부분은 AI Agent의 성능이 좋아질수록 오히려 더 중요해질 것 같았다.
그래서 Astra를 사용할 때는 작업의 범위를 명확하게 지정하는 것이 좋았다.
예를 들어
현재 문제와 직접 관련된 코드만 수정해줘.
리팩터링은 하지 마.
새로운 라이브러리는 추가하지 마.
DB 스키마는 변경하지 마.처럼 하지 말아야 할 작업까지 알려주는 방식이 꽤 효과적이었다.
8. 모든 분야에서 압도적이라는 느낌은 아니었다
Astra가 강력한 모델이기는 하지만 모든 작업에서 다른 AI보다 무조건 좋다고 느끼지는 않았다.
특히 UI나 디자인처럼 정답이 명확하지 않은 영역에서는 모델마다 특성이 존재했다.
Astra 관련 해외 후기에서도 논리적인 작업과 개발 작업에서는 좋은 평가를 받는 반면, 시각적인 결과물이나 디자인 감각에서는 다른 모델을 선호한다는 평가가 있었다.
결국 앞으로는
어떤 AI가 가장 좋은가?보다
이 작업에는 어떤 AI가 가장 좋은가?가 더 중요한 질문이 될 것 같았다.
코드 분석, 디버깅, 구조 파악처럼 논리적인 작업에서는 Astra를 사용하고 UI 디자인이나 특정 작업에서는 다른 모델을 사용하는 방식도 충분히 가능해 보였다.
9. 사용량은 생각보다 중요했다
성능이 좋아진 만큼 더 많은 작업을 맡기게 되는 문제가 있었다.
특히 AI가 여러 파일을 읽고 분석하고 테스트까지 수행하는 Agent 형태로 사용하면 단순 질문 몇 개를 하는 것보다 훨씬 많은 컨텍스트를 사용하게 된다.
실제로 Astra 사용자들 사이에서도 코딩 작업에서 사용량이 빠르게 증가한다는 이야기가 나오고 있었다. 반면 문서 분석이나 일반적인 업무처럼 대규모 코드베이스를 계속 읽을 필요가 없는 작업에서는 상대적으로 효율적이라는 반응도 있었다.
그래서 무조건 가장 높은 추론 수준으로 사용하는 것보다는 작업에 따라 모델과 추론 수준을 조절하는 것이 필요해 보였다.
간단한 질문까지 최고 수준의 모델에게 맡기는 것은 조금 아깝다는 생각이 들었다.
10. Astra를 사용하면서 프롬프트 작성 방식도 바뀌었다
예전에는 AI에게 코딩을 시킬 때 꽤 구체적으로 작성했다.
Spring Boot Controller 만들어줘.
POST /users API 만들어줘.
UserService 호출하고 UserRepository를 사용해줘.하지만 모델의 성능이 올라가면서 오히려 이런 방식이 AI의 판단을 제한하는 경우도 있었다.
최근에는 목적을 먼저 알려주는 방식으로 사용하는 것이 더 좋다고 느꼈다.
예를 들면 다음과 같았다.
회원가입 기능이 필요하다.
현재 프로젝트 구조와 기존 회원 관련 코드를 먼저 분석하고
현재 프로젝트의 패턴을 유지한 상태에서 구현해줘.
필요한 validation과 예외 처리도 확인하고
작업이 끝나면 변경한 내용을 정리해줘.구체적인 구현 방법을 전부 지정하는 대신
목표 + 제약조건 + 완료 조건
을 알려주는 방식이었다.
개인적으로 Agent형 AI를 사용할 때 꽤 중요한 프롬프트 구조라고 생각했다.
내가 느낀 Astra의 장점
정리하면 다음과 같은 부분이 좋았다.
1. 사용자의 의도를 파악하는 능력이 좋아졌다
내가 무엇을 원하는지 이전보다 빠르게 파악했다.
2. 여러 단계로 이루어진 작업에 강했다
분석 → 구현 → 확인처럼 이어지는 작업을 하나의 작업으로 처리하려는 능력이 좋아졌다.
3. 코드 리뷰와 디버깅에서 유용했다
코드를 단순히 생성하는 것보다 기존 코드의 문제를 찾는 용도로 사용할 때 만족도가 높았다.
4. 설명이 비교적 직접적이었다
필요 이상으로 긴 설명보다 문제 해결 중심으로 답변하는 경우가 많았다.
5. AI Agent가 어디까지 발전할 수 있는지 보여줬다
단순한 챗봇보다는 실제 작업을 수행하는 도구에 가까워지고 있다는 느낌을 받았다.
아쉬웠던 점
물론 단점도 있었다.
1. 기존 프로젝트 구조를 항상 완벽하게 이해하는 것은 아니었다
큰 프로젝트에서는 잘못된 위치에 코드를 추가하거나 기존 패턴과 다른 코드를 만들 가능성이 있었다.
2. AI가 만든 코드를 그대로 사용할 수는 없었다
결국 개발자가 코드 리뷰를 해야 했다.
3. 작업 범위를 크게 주면 필요 이상으로 수정할 수 있었다
작업 범위를 명확하게 제한하는 것이 중요했다.
4. 사용량이 빠르게 증가할 수 있었다
특히 대규모 코드베이스 분석에서는 여러 파일을 계속 읽기 때문에 사용량을 신경 써야 했다.
5. 모든 분야에서 다른 모델보다 좋은 것은 아니었다
논리적인 작업과 코딩에서는 강했지만 디자인처럼 취향과 시각적인 판단이 중요한 영역에서는 다른 AI가 더 잘 맞을 수도 있었다.
결국 개발자는 필요 없어지는가?
Astra 같은 모델을 사용할 때마다 나오는 이야기다.
직접 사용해본 뒤에는 오히려 반대로 생각하게 됐다.
AI가 코드를 더 많이 작성할수록 개발자가 판단해야 하는 영역이 더 중요해지는 것 같았다.
예전에는 개발자가 직접
코드를 작성하는 능력이 중요했다면 앞으로는
좋은 구조인지 판단하는 능력
AI에게 적절한 작업을 맡기는 능력
AI가 작성한 코드를 검증하는 능력
문제의 범위를 정의하는 능력
전체 시스템을 이해하는 능력이 더 중요해질 것 같았다.
Astra가 코드를 굉장히 잘 작성한다고 해도 어떤 기능을 만들어야 하는지, 어떤 구조가 프로젝트에 적합한지, 현재 구현이 장기적으로 문제가 없는지는 결국 개발자가 결정해야 했다.
AI가 개발자를 없앤다기보다는 개발자가 직접 해야 했던 작업의 범위를 바꾸고 있다고 느꼈다.
마무리
GPT-6 Astra를 사용하면서 가장 크게 느꼈던 것은 단순히
“GPT가 또 조금 더 똑똑해졌다.”
가 아니었다.
AI를 사용하는 방식이 조금씩 바뀌고 있다는 것이었다.
처음 ChatGPT를 사용할 때는 질문을 하면 답을 알려주는 도구였다.
이후에는 코드를 작성해주는 도구가 됐다.
그리고 지금은
목표를 설명하면
필요한 작업을 판단하고
실제로 작업을 수행하는 도구로 발전하고 있었다.
물론 아직 완벽하지 않았다.
기존 프로젝트의 구조를 잘못 이해하기도 했고 필요 이상으로 코드를 수정하기도 했다. 결과물을 사람이 검토해야 한다는 점도 변하지 않았다.
그럼에도 불구하고 Astra를 사용하고 나니 앞으로 개발에서 AI를 어떻게 활용해야 할지 방향이 조금 더 명확해졌다.
AI에게 모든 것을 맡기는 개발자가 되는 것보다, AI에게 일을 잘 시키고 그 결과를 판단할 수 있는 개발자가 되는 것이 중요하다고 생각했다.
개인적으로 Astra에서 가장 인상 깊었던 부분도 결국 이것이었다.
코드를 더 잘 작성하는 AI가 나온 것이 아니라,
조금씩 같이 일할 수 있는 AI가 나오기 시작했다.
