GPT-6 Astra로 기존 에이전트 작업 시스템을 다시 점검하기

GPT-6 Astra로 무엇부터 해 보면 좋을까요. Shann Holmberg의 게시물은 기존 세션 기록과 프로젝트를 Astra에 맡겨 다시 검토하는 작업을 제안합니다. 이미 쓰고 있는 지침과 작업 절차에서 개선할 부분을 찾고, 확인한 결과를 파일에 반영해 다음 작업에 사용하는 방식입니다.

새 모델에 새 일을 맡기는 것만큼, 지금까지 해 온 일을 다시 점검하는 데 초점을 맞춘 제안입니다. 대화에서 같은 요청을 반복했다면 그 이유를 찾고, 프로젝트에서 테스트나 작업 절차가 멈췄다면 어디서 문제가 생겼는지 살펴보도록 합니다.

이미지: Shann Holmberg의 게시물에 첨부된 작업 흐름.

Astra에 어떤 자료와 작업을 맡기나요

그림에는 Claude·Codex·Hermes의 세션 기록, 회사·프로젝트·연구 자료를 모은 지식 파일, 실제 프로젝트가 검토 대상으로 나옵니다. Astra가 수행할 작업은 네 가지로 표시돼 있습니다.

맡길 작업	그림에 제시된 검토 대상
조사	현재 파일과 과거 작업 기록
테스트	검사 항목과 작업 절차
추적	실패와 작업 중 겪는 불편
계획	구체적인 개선 사항

저자는 여러 에이전트의 세션과 프로젝트 기록을 Astra에 전달하고, 세션마다 반복하는 프롬프트를 찾게 하자고 제안합니다. 여기서 프롬프트는 에이전트에 전달하는 요청이나 지시를 뜻합니다.

이 제안을 적용한다면 대화 기록과 현재 파일을 함께 제공하는 편이 좋습니다. 예전에 요청한 내용이 이미 반영됐는지, 아직 같은 문제가 남아 있는지 비교할 수 있기 때문입니다. 다만 이는 그림을 바탕으로 보충한 적용 방법이며, 저자가 실제로 사용한 명령이나 검증된 실행 결과는 아닙니다.

왜 GPT-6 Astra를 활용하자는 제안인가요

저자는 GPT-6 Astra의 성능 향상을 기존 시스템을 다시 살펴볼 계기로 소개합니다. 첨부 그림에는 AutomationBench에서 Astra가 41.4, Fable 5.1이 31.4를 기록했다는 비교와 약 32%라는 차이가 적혀 있습니다.

저자가 제시한 성능 비교는 공식 평가 자료와 시험 조건을 별도로 확인하지 못했습니다. 여기서는 수치 자체보다, Astra에 기존 기록과 프로젝트를 맡겨 개선할 부분을 찾는 활용 방법에 초점을 맞춥니다.

검토한 내용을 어디에 반영할까요

그림의 마지막 단계는 결과를 다시 파일에 쓰는 작업입니다. 반복 작업은 스킬에, 계획과 테스트는 프로젝트 파일에, 맥락과 결정은 지식 저장소에, 예약 작업은 관련 도구에 반영합니다. 스킬은 에이전트가 반복해서 사용할 수 있도록 정리한 작업 절차입니다.

이렇게 수정한 상태를 다음 작업의 출발점으로 삼습니다. 원문에서 말하는 기준선은 이 출발점으로 이해하면 됩니다. 검토 결과가 대화 안에만 남으면 다음 세션에서 다시 설명해야 할 수 있으므로, 실제 작업에서 읽고 실행하는 파일에 반영하는 데 의미가 있습니다.

파일을 처음부터 많이 만들 필요는 없습니다. 이미 쓰고 있는 지침과 상태 문서가 있다면 필요한 내용을 그곳에 남기는 것부터 시작할 수 있습니다. 한 번만 필요했던 요청과 앞으로도 지켜야 할 규칙은 구분해 두는 편이 좋습니다.

프로젝트에 적용해 보는 작은 예시

가령 여러 세션에서 “변경한 부분의 테스트를 먼저 실행해 주세요”라는 요청을 반복했다고 가정해 보겠습니다. 다음은 이 상황을 Astra에 검토하도록 맡기는 요청 예시입니다. 저자의 원문 인용은 아닙니다.

제공한 세션 기록과 현재 프로젝트 파일을 비교해 주세요. 테스트 실행을 반복해서 요청한 이유를 찾고, 현재 지침에 빠진 내용이 있는지 확인해 주세요. 근거가 되는 기록과 파일을 제시하고, 확인한 사실과 추측을 구분해 주세요. 파일은 아직 수정하지 말고 가장 작은 변경안을 제안해 주세요.

제안을 받으면 테스트 명령이 현재 프로젝트에서 실제로 실행되는지 확인합니다. 성공을 판단할 결과와 실패했을 때 멈출 조건도 함께 점검합니다. 실행할 수 없다면 검증을 완료했다고 기록하지 않고, 실행하지 못한 이유를 남깁니다.

확인한 변경만 지침이나 절차에 반영한 뒤 새 세션에서 같은 작업을 해 봅니다. 이전 대화를 다시 전달하지 않아도 필요한 테스트를 실행하고 결과를 확인하는지 보면, 수정이 실제 작업에 반영됐는지 판단할 수 있습니다.

과거 기록을 전달하기 전에는 비밀키와 개인정보, 다른 사람과의 비공개 대화가 포함됐는지도 확인해야 합니다. 검토할 자료의 범위를 먼저 정하고, 배포나 삭제처럼 영향이 큰 작업의 실행 권한은 따로 둡니다.

다시 검토한 결과를 다음 작업에서 확인하기

Astra에 기존 기록을 맡긴다고 해서 모든 제안을 곧바로 새 규칙으로 채택할 필요는 없습니다. 과거에는 맞았지만 지금은 달라진 판단도 있을 수 있습니다. 읽은 기록의 범위, 확인한 문제, 실제로 수행한 검증을 함께 남기면 다음 작업에서 무엇을 믿고 시작할지 알 수 있습니다.

자주 반복하는 요청 하나를 골라 검토하고, 작은 변경을 확인하는 것부터 시작해도 됩니다. 이 글에서 다룬 Astra 활용의 범위는 기존 작업을 점검하고 개선 결과를 다음 작업에 반영하는 과정입니다.