로그인 화면에 Astra for Law가 보이지만 고객 사건 파일을 바로 올려도 되는지 판단할 수 없습니다.
가장 빠른 해법은 서면 자격과 계약 범위를 확인한 뒤 공개 자료나 저위험 업무부터 시작하고, ZDR·플러그인·Codex·API를 각각 따로 검수하는 것입니다.
이 글은 다음 담당자를 위한 실행 문서입니다.
- 법률 조직의 IT·보안 책임자: 어떤 사건 자료를 넣을 수 있는지와 감사 증거를 정해야 합니다.
- 법률 기술 개발팀: Codex, 플러그인, 향후 API로 법률 에이전트를 만들기 전에 데이터와 실행 경계를 나눠야 합니다.
- 파트너와 혁신 책임자: 제품 성능만 보지 않고 제한적 시범 운영, 대기, 확대 배포를 결정해야 합니다.
마지막 업데이트: 2026년 9월 18일. 공개 범위와 데이터 조건은 Astra for Law 공식 도움말, 기업 데이터 정책, API 데이터 문서를 기준으로 확인했습니다.
OpenAI Astra for Law 고객 비밀은 접근 자격부터 갈립니다
지금 어떤 법률 조직이 사용할 수 있나요?
가장 흔한 오판은 제품이 발표됐다는 사실을 모든 법률 팀이 사용할 수 있다는 의미로 해석하는 것입니다. 공식 안내 기준으로 Astra for Law는 2026년 9월 17일 처음 공개됐고, 초기에는 미국의 일부 법률 조직이 Trusted Access, ChatGPT, Codex를 통해 이용하는 방식입니다. 이는 전면 공개나 모든 계정에 대한 일반 제공을 뜻하지 않습니다.
다음 세 상태를 분리해 기록해야 합니다.
- 제품 설명이 공개됐는가
- 우리 조직이 신청 가능한 자격을 갖췄는가
- 실제 관리자 계정에 해당 기능과 데이터 조건이 활성화됐는가
계정 화면에 기능이 없거나 서면 자격을 받지 못했다면 고객 사건을 넣지 말아야 합니다. 계정 가시성 화면, 계약서의 적용 범위, 관리자 승인 기록을 함께 보관하십시오. GPT-6 Astra Law라는 검색어가 보여도 별도 모델이나 별도 접근 권한으로 간주해서는 안 됩니다.
| 확인 항목 | 통과 증거 | 통과하지 못했을 때 |
|---|---|---|
| 접근 경로 | Trusted Access 또는 관리자 확인 기록 | 공개 자료만 검토 |
| 계약 범위 | 조직·지역·사용 기능이 적힌 문서 | 고객 자료 입력 금지 |
| 계정 상태 | 실제 계정의 기능 표시와 관리자 로그 | 시범 운영 보류 |
| API 상태 | 공식적으로 사용 가능한 엔드포인트 확인 | 인터페이스 설계만 진행 |
ZDR은 보안 조건이지 고객 비밀의 자동 승인서가 아닙니다
고객 파일을 올리면 저장되지 않는다고 볼 수 있나요?
ZDR은 데이터 보존과 사용 조건을 확인하는 중요한 항목입니다. 그러나 고객 동의, 직업상 비밀 보호 의무, 내부 정보 분류, 지역별 이전 제한을 대신하지는 않습니다. OpenAI의 기업 데이터 정책은 기업용 데이터 처리 조건을 설명하지만, 실제 적용 여부는 제품·계약·프로젝트 설정을 함께 확인해야 합니다.
데이터 경로는 적어도 네 갈래로 나눠 보십시오.
| 데이터 경로 | 확인할 내용 | 필요한 증거 |
|---|---|---|
| 모델 학습 사용 | 입력과 출력이 학습에 쓰이는지 | 계약 조항과 정책 화면 |
| 오남용 감시 로그 | 보안 목적의 로그와 보존 조건 | 데이터 제어 문서 |
| 애플리케이션 상태 | 대화, 파일, 작업 상태의 유지 여부 | 프로젝트 설정과 삭제 기록 |
| 자체 저장소 | 문서 관리 시스템과 백업 위치 | 저장·삭제·접근 로그 |
ZDR이 적용된다는 영업 설명만으로는 부족합니다. 실제 요청 경로에 ZDR 조건이 적용되는지, 파일 업로드와 검색 결과에도 같은 조건이 적용되는지 확인해야 합니다. 특히 플러그인이 별도 저장소나 캐시를 사용한다면 Astra for Law의 ZDR을 외부 시스템 데이터까지 자동 확장해서는 안 됩니다.
Astra for Law 도움말의 데이터 조건과 API 엔드포인트별 기본 사용 정책을 계약 담당자와 함께 대조하십시오. 조건을 문서로 증명하지 못하면 고객 비밀 시범 운영은 반려하는 편이 안전합니다.
법률 검색 결과와 납품 가능한 법률 의견은 다릅니다
검색 결과가 그럴듯해도 바로 의견서에 넣을 수 있다는 뜻은 아닙니다. 법률 연구에서는 인용 권위, 관할, 현재 효력, 후속 판결, 불리한 근거를 별도로 확인해야 합니다. 공식 검증 자료의 성능을 특정 사건의 정확성 보장으로 바꾸어 말해서도 안 됩니다.
대표 연구 과제마다 다음 기록을 남기십시오.
- 입력한 질문과 사건의 전제
- 사용한 원문 출처와 인용 문단
- 관할과 기준일
- 담당 변호사의 검토 의견
- 오류, 누락, 수정 이력
| 연구 단계 | 사람이 확인할 질문 | 중단 기준 |
|---|---|---|
| 검색 | 출처가 공식 원문인가 | 출처를 재현할 수 없음 |
| 인용 | 문단이 실제 결론을 지지하는가 | 인용과 결론이 불일치 |
| 최신성 | 후속 판결이나 개정이 있는가 | 기준일을 확인할 수 없음 |
| 검토 | 불리한 근거도 제시됐는가 | 반대 자료가 누락됨 |
팀이 핵심 근거를 독립적으로 검증할 수 없다면 Astra for Law는 연구 보조로만 사용해야 합니다. 최종 법률 의견이나 고객에게 전달되는 판단의 유일한 근거로 배치하지 마십시오.
플러그인은 검색 편의를 늘리지만 사건 경계를 넓힙니다
ChatGPT 작업 공간 권한과 외부 문서 관리·사건 관리·법률 검색 시스템의 권한은 같은 것이 아닙니다. 플러그인이 읽기만 하는지, 파일을 저장하는지, 내용을 수정하는지, 다른 사건을 검색하는지 각각 확인해야 합니다.
Astra for Law의 앱 계정 연결 안내를 기준으로 다음 시험을 분리하십시오.
- 읽기 전용 검색
- 파일 저장
- 문서 내용 수정
- 사건 간 검색
- 권한 철회 후 재접근
- 윤리 장벽과 사건별 접근 제한
권한 철회 뒤에도 캐시나 이전 토큰으로 자료를 읽을 수 있다면 고객 비밀 시범 운영에서 제외해야 합니다. 데이터가 어디에 저장되는지 설명할 수 없거나 사건 권한을 즉시 회수할 수 없는 플러그인은 공개 자료 환경에서만 시험하십시오.
Codex 실행 권한은 답변보다 파일 시스템을 먼저 위험하게 만듭니다
Codex를 Astra for Law의 단순 답변 기능으로 취급하면 안 됩니다. 모델 응답, 코드와 파일 조작, 외부 도구 호출, 운영 체제 권한은 서로 다른 위험 영역입니다. 고객 파일과 일반 개발 작업을 같은 작업 공간에 두지 마십시오.
| 실행 영역 | 확인할 경계 | 검수 방법 |
|---|---|---|
| 작업 디렉터리 | 사건 자료가 어느 폴더에 놓이는가 | 허용 목록 외 경로 차단 |
| 임시 자격 증명 | 토큰과 비밀번호가 어디에 남는가 | 작업 종료 후 폐기 확인 |
| 네트워크 | 외부 전송과 도메인 호출 범위 | 허용 목록과 차단 로그 |
| 승인 | 파일 삭제·수정에 사람이 개입하는가 | 승인 전후 로그 비교 |
| 복구 | 중단과 오류 뒤 상태가 남는가 | 실패 시나리오 재실행 |
배치 문서 처리나 내부 법률 에이전트는 독립 테스트 환경에서 시작해야 합니다. 생성 환경을 정식 사건 파일 시스템과 분리하고, 작업 종료 후 임시 파일과 인증 정보를 지우십시오. Codex 작업 대화를 보관하거나 삭제하는 절차는 Codex 대화 보관·삭제 안내와 실제 관리자 로그를 함께 비교해야 합니다.
API가 열리기 전에는 생산 시스템을 미리 확정하지 않습니다
API가 향후 제공된다는 표현은 오늘 생산 엔드포인트를 사용할 수 있다는 뜻이 아닙니다. 공식 개방 전에는 모델 필드, 할당량, 가격, 출시일, 플러그인 대체 기능을 만들어 내지 마십시오. 이 단계에서 준비할 것은 인터페이스 어댑터, 데이터 등급, 평가 집합, 실패 시 수동 회귀 절차입니다.
API가 실제로 열리면 다음 순서로 다시 검수해야 합니다.
- 조직과 프로젝트의 엔드포인트 자격 확인
- 해당 경로의 ZDR 적용 여부 확인
- 상태 저장과 삭제 방식 확인
- 플러그인 없이 필요한 검색·저장 기능 재설계
- 요청·도구·저장·사람 검토 비용을 합산
- 제한된 비식별 자료로 실패와 철회를 시험
최종 점수는 모델 답변 품질만으로 계산하지 마십시오.
| 평가 축 | 배점 예시 | 합격에 필요한 증거 |
|---|---|---|
| 접근·계약 | 25 | 서면 자격과 적용 범위 |
| 데이터 경로 | 25 | 저장·삭제·로그 확인 |
| 법률 정확성 | 20 | 인용과 변호사 검토 기록 |
| 실행 격리 | 20 | 권한·네트워크·복구 시험 |
| 철회 가능성 | 10 | 계정·토큰·플러그인 회수 기록 |
점수 합계만으로 자동 승인하지 마십시오. 한 축에서 고객 자료의 위치나 철회 방법을 설명하지 못하면 전체 결과를 보류해야 합니다. 결론은 다음 세 단계로 남기면 됩니다.
- 공개 자료 검토만 허용
- 승인된 저위험 고객 업무만 제한적으로 시범 운영
- 데이터·계약·정확성 증거가 부족해 도입 보류
이 판단을 독립된 클라우드 맥 테스트 환경에서 수행하려면 클라우드 맥에서 민감한 문서를 검증하는 배포 방법처럼 실행 공간과 정식 저장소를 나누는 설계부터 확인하십시오. 원격 접속 통제가 필요하다면 원격 맥 연결과 VPN 설정 안내도 함께 검토할 수 있습니다.
시범 운영 승인 전에 남겨야 할 검수 목록
- [ ] 실제 계정의 접근 자격과 관리자 승인 기록을 저장했습니다.
- [ ] 계약서에서 조직, 지역, 기능, 데이터 조건을 확인했습니다.
- [ ] ZDR 적용 범위를 모델, 로그, 앱 상태, 외부 저장소별로 나눴습니다.
- [ ] 고객 파일 업로드와 삭제 결과를 실제 요청 경로에서 확인했습니다.
- [ ] 플러그인의 읽기·쓰기·캐시·권한 철회 동작을 시험했습니다.
- [ ] Codex 작업 디렉터리와 일반 개발 공간을 분리했습니다.
- [ ] 임시 자격 증명, 네트워크 출구, 수동 승인 규칙을 검증했습니다.
- [ ] 법률 검색의 출처·관할·최신성·불리한 근거를 기록했습니다.
- [ ] 오류 수정과 사람의 최종 검토 이력을 보존했습니다.
- [ ] API가 정식 제공되기 전에는 생산 연결을 만들지 않았습니다.
- [ ] 공개 자료 검토, 제한 시범 운영, 보류 중 하나를 문서로 결정했습니다.
현재 사용 중인 일반 ChatGPT나 자체 서버 방식은 빠르게 시작할 수 있지만, 사건별 권한 분리와 플러그인 철회 증거가 약하고, 파일 작업과 개발 작업이 같은 환경에 섞이며, 운영 체제 권한까지 한 번에 관리해야 하는 단점이 있습니다. 반대로 MacPull의 독립 클라우드 맥 환경을 쓰면 법률 에이전트와 정식 사건 시스템을 분리한 시험 공간을 먼저 만들 수 있습니다. 다만 장기간의 고정 부하, 물리 장비 연결, 조직 내부 저장소와의 직접 통합이 필수라면 자체 장비나 전용 인프라가 더 적합할 수 있습니다. 임시 검수나 제한된 테스트 환경이 필요할 때는 MacPull 이용 안내를 확인한 뒤, 계약 조건과 데이터 경계를 먼저 확정하십시오.