마지막 수정
OpenAI Presence에서 본 AI 에이전트 권한과 승인 구조
OpenAI Presence 발표를 Daejin Lab의 수동 발행 흐름과 대조해, 운영형 AI 에이전트에 필요한 최소 권한·승인 작업·평가·사람 인계 기준을 정리했습니다.

결론 먼저
운영형 AI 에이전트에는 좁은 업무 범위, 최소 권한, 고위험 작업 승인과 사람 인계 기준이 필요합니다.
- 실험 환경
- 2026년 7월 22일 공개된 OpenAI Presence 공식 발표와 Daejin Lab의 Astro·Git 기반 수동 발행 흐름을 대조했습니다. Presence를 직접 사용하거나 성능을 독립 검증한 글은 아닙니다.
- 누구에게 유용한가
- AI 에이전트를 고객지원, 사내 업무 또는 콘텐츠 운영에 연결하려는 사람과 자동화의 권한·승인 경계를 먼저 정하고 싶은 운영자
확인한 자료와 한계
- OpenAI Presence 공식 발표
- Daejin Lab 수동 발행 게이트와 공개 전 검증 기록
- Daejin Lab 운영 원칙과 자동 발행 정책
Presence는 일부 기업 대상의 제한된 일반 제공 프로그램이며 셀프서비스 제품이 아닙니다. 공개된 설명만으로 비용, 구축 기간, 실제 정확도와 장애 대응 수준을 판단할 수 없습니다.
이 글에서 다루는 핵심 3가지
OpenAI Presence 발표는 모델 성능표보다 운영 규칙을 앞에 놓았습니다. 특정 업무만 맡기고, 필요한 정보와 시스템만 열어주고, 승인할 작업과 사람에게 넘길 시점을 미리 정한다는 방식입니다.
이 설명을 읽다가 Daejin Lab의 글 발행 흐름이 떠올랐습니다. 규모와 위험은 비교할 수 없지만, 자동화가 실제 행동으로 넘어가기 전에 멈추는 지점이 필요하다는 생각은 같았습니다.
이 글은 Presence 사용 후기가 아닙니다. 공식 발표에서 확인할 수 있는 운영 장치를 뽑아 Daejin Lab에서 쓰는 수동 승인 흐름과 대조했습니다.
10초 요약
- OpenAI Presence는 음성과 채팅 기반 업무 에이전트를 기업 환경에 배치하기 위한 제품입니다.
- 모델 하나를 판매하는 셀프서비스 도구가 아니라 정책, 권한, 평가, 승인 작업, 사람 인계와 개선 절차를 함께 제공합니다.
- 현재는 자격을 갖춘 기업을 대상으로 제한적으로 제공되며 OpenAI 인력과 지정 파트너가 구축에 참여합니다.
- OpenAI는 자사 영어 전화 지원에서 문의의 75%를 사람 개입 없이 처리하고, 10일 동안 사람 인계를 15%포인트 줄였다고 밝혔습니다. 독립 평가 결과는 아닙니다.
- Daejin Lab도 초안 작성과 자동 검사는 도구가 돕지만, 공개 상태 변경과 Git push는 별도 승인으로 남겨두고 있습니다.
- 작은 조직에서는 Presence를 그대로 도입하기보다 업무 범위, 최소 권한, 승인 작업, 평가 기준, 사람 인계 다섯 가지를 먼저 가져오는 편이 현실적입니다.
OpenAI Presence는 무엇인가
OpenAI는 Presence를 기업이 고객지원이나 사내 업무에 AI 에이전트를 배치하도록 돕는 제품으로 소개했습니다. 현재 지원하는 영역은 실시간 음성과 채팅입니다.
예로 든 업무는 결제 문제 처리, 보험 청구 지원, 사내 IT 요청입니다. 질문에 답하는 데서 끝나지 않고 본인 확인, 계정 조회, 회사 정책 적용과 승인된 작업까지 이어집니다.
운영 경계를 가르는 말은 승인된 작업입니다. 에이전트가 연결된 시스템에서 할 수 있는 모든 일을 자유롭게 실행하는 구조가 아닙니다.
Presence의 구성을 정리하면 다음과 같습니다.
| 구성 | 맡는 역할 |
|---|---|
| 업무 정의 | 에이전트가 해결할 한 가지 일을 정함 |
| 지식과 시스템 접근 | 해당 업무에 필요한 범위만 연결 |
| 정책과 표준 절차 | 해도 되는 행동과 금지된 행동을 정의 |
| 승인 작업 | 실행 전 사람이 확인해야 할 행동을 분리 |
| 시뮬레이션과 평가 | 일반 요청과 예외 상황을 배포 전에 시험 |
| 사람 인계 | 확신이 낮거나 위험한 상황을 담당자에게 넘김 |
| 운영 후 개선 | 실제 세션과 인계 기록에서 부족한 부분을 찾음 |
Codex는 운영 기록을 보고 수정안을 제안하는 역할을 맡습니다. 제안이 바로 운영 환경에 반영되는 것은 아닙니다. 팀이 기존 버전과 비교해 시험하고 승인한 뒤 통제된 방식으로 적용한다고 설명합니다.
숫자는 회사 발표와 독립 검증을 나눠 봐야 한다
OpenAI는 Presence가 자사 영어 전화 지원에서 문의의 75%를 사람 도움 없이 해결한다고 밝혔습니다. 개선 과정에서는 사람 인계 비율을 10일 동안 15%포인트 낮췄다고 설명했습니다.
눈에 띄는 숫자지만 해석에는 빈칸이 있습니다.
어떤 유형의 문의가 대상이었는가
해결로 판정한 기준은 무엇인가
고객 만족도와 재문의율은 어땠는가
잘못 처리한 작업은 몇 건이었는가
초기 구축과 지속 운영에 사람이 얼마나 투입됐는가
공식 글에는 이 항목을 모두 판단할 자료가 없습니다. 75%를 모든 고객지원 환경에 적용할 수 있는 성능으로 보면 안 됩니다. 현재 확인할 수 있는 것은 OpenAI가 모델 응답률보다 업무 완료, 정책 준수, 도구 사용과 사람 인계를 운영 지표로 삼았다는 점입니다.
Daejin Lab 흐름과 대조해 본 이유
Daejin Lab은 고객지원 시스템이 아닙니다. 개인 기술 블로그이고, 공개 작업의 위험도도 훨씬 작습니다.
글 발행도 자동화가 실제 행동으로 넘어가는 과정입니다. 확인하지 않은 경험, 민감한 경로 또는 출처가 불분명한 이미지가 공개되면 검색엔진과 외부 캐시에 남을 수 있습니다. Git push 이후에는 배포까지 이어집니다.
그래서 현재 흐름을 Presence의 운영 요소와 나란히 놓아봤습니다.
| Presence의 기준 | Daejin Lab에서 대응하는 기준 |
|---|---|
| 특정 업무부터 시작 | 한 번에 한 글 또는 한 수정 범위만 다룸 |
| 필요한 시스템만 연결 | 요청받은 글과 이미지 파일만 변경 |
| 정책과 절차 설정 | frontmatter, 출처, 개인정보, 이미지 권리 확인 |
| 승인 작업 분리 | 초안 작성과 공개 상태 변경을 별도 작업으로 취급 |
| 배포 전 평가 | 빌드, publish gate, SEO·UX 검사 |
| 사람 인계 | 사실이 불명확하거나 외부 작업이면 사람이 결정 |
| 통제된 배포 | 명시적으로 승인된 파일만 커밋하고 push |
비교 대상은 제품 규모가 아니라 공개 전 경계입니다. 큰 기업용 에이전트에서 요구되는 운영 원칙이 작은 콘텐츠 자동화에서도 비슷한 질문으로 나타나는지 확인했습니다.
1. 에이전트보다 먼저 업무를 좁힌다
“고객지원을 자동화한다”는 범위는 너무 넓습니다. 계정 조회, 결제 변경, 환불, 불만 접수와 장애 대응은 필요한 정보도 다르고 실패 비용도 다릅니다.
Presence는 배포마다 구체적인 업무 하나에서 시작한다고 설명합니다. Daejin Lab도 같은 이유로 “블로그를 운영해줘”라는 요청보다 작업 단위를 나눕니다.
글감 조사
비공개 초안 작성
문장과 출처 검수
발행 가능 상태 확인
공개 상태 변경
커밋과 원격 저장소 반영
앞 단계가 끝났다고 다음 단계의 권한이 자동으로 생기지는 않습니다. 초안이 완성돼도 공개 승인이 없으면 draft: true를 유지합니다. 글 발행과 Git push도 각각 명시적인 요청이 있어야 진행합니다.
이 구분이 번거로워 보여도 실패 원인을 찾기 쉬워집니다. 초안의 사실 문제가 배포 문제로 섞이지 않고, 빌드 성공이 곧 공개 승인이라는 오해도 줄어듭니다.
2. 필요한 정보와 도구만 열어준다
에이전트가 일을 잘하려면 접근 권한이 많아야 한다는 생각은 위험합니다. 권한이 많으면 편한 작업도 있지만, 잘못된 판단 하나가 영향을 주는 범위도 커집니다.
Presence는 에이전트가 맡은 업무에 필요한 지식과 시스템만 받는다고 설명합니다. 개인 프로젝트에서는 다음처럼 바꿔 적용할 수 있습니다.
전체 저장소 대신 요청받은 프로젝트만 연다
수정 대상 파일을 먼저 정한다
운영 비밀값은 글 작성 문맥에서 분리한다
외부 전송이 필요한 작업은 별도로 승인한다
삭제보다 보관과 복구가 가능한 방식을 우선한다
Daejin Lab 관리자 화면도 현재는 게시물 상태를 읽는 단계에 가깝습니다. 수정과 발행을 자유롭게 수행하는 공개 CMS로 운영하고 있지 않습니다. 인증, 세션, CSRF 방어와 저장 방식이 준비되지 않은 상태에서 쓰기 기능부터 외부에 열면 편의보다 위험이 커집니다.
3. 작업을 자동 실행과 승인 대상으로 나눈다
모든 작업에 사람이 끼어들면 자동화의 의미가 줄어듭니다. 반대로 모든 작업을 자동 실행하면 작은 오류가 공개 사고로 바뀔 수 있습니다.
판단 기준은 작업의 되돌리기 비용입니다.
| 자동 실행하기 쉬운 작업 | 사람이 승인할 작업 |
|---|---|
| 문서 형식 검사 | 공개 상태 변경 |
| 깨진 내부 링크 탐색 | 외부 계정에 데이터 전송 |
| 빌드와 테스트 | Git push와 실제 배포 |
| 중복 제목 후보 찾기 | 파일 삭제와 대량 변경 |
| 메타데이터 누락 확인 | 개인정보·광고·법률 관련 판단 |
왼쪽은 결과가 명확하고 다시 실행하기 쉽습니다. 오른쪽은 외부에 영향을 주거나 잘못됐을 때 흔적과 비용이 남습니다.
이 경계는 모델이 좋아져도 없어지지 않습니다. 반복 실행이 늘수록 드문 오류도 실제 작업에서 만나게 됩니다. 모델 평균 점수와 함께 오류가 발생했을 때 어디까지 진행할 수 있는지 봐야 합니다.
4. 배포 전에 정상 요청과 실패 상황을 같이 시험한다
정상 질문 몇 개에 답했다고 운영 준비가 끝난 것은 아닙니다.
Presence는 일반적인 요청뿐 아니라 예외 상황과 고위험 시나리오를 시뮬레이션하고, 결과·정책 준수·도구 사용·인계 판단을 평가한다고 설명합니다.
블로그 발행에서는 아래 항목이 비슷한 역할을 합니다.
모든 indexable 페이지에 H1이 한 개인가
canonical이 실제 공개 도메인을 가리키는가
초안과 비공개 검토 페이지가 sitemap에서 빠지는가
민감한 로컬 경로와 비밀값이 포함되지 않았는가
모바일에서 표와 제목이 가로로 넘치지 않는가
404와 정책 페이지에 광고 코드가 들어가지 않는가
현재 Daejin Lab에서는 npm run verify:publish로 콘텐츠 검사, 정적 빌드, 관리자·UX 검사와 디자인·SEO 점검을 묶어 확인합니다. 이후에도 실제 글을 모바일 크기로 열어 제목, 이미지, canonical과 색인 상태를 봅니다.
자동 검사는 통과 여부를 빠르게 알려줍니다. 사람이 보는 검토는 문장이 과장됐는지, 조사와 경험이 섞이지 않았는지 확인합니다. 둘 중 하나만으로는 부족했습니다.
5. 사람 인계는 실패가 아니라 정상 경로다
운영형 에이전트가 모든 요청을 혼자 끝내야 한다고 보면 사람 인계가 낮을수록 좋다고 생각하기 쉽습니다.
하지만 환불, 계정 정지, 개인정보 또는 공개 배포처럼 되돌리기 어려운 작업에서는 일찍 넘기는 편이 맞을 수 있습니다. 인계가 필요한 상황을 미리 정하지 않으면 모델이 자신 없는 상태에서도 답을 만들어내거나 작업을 계속할 수 있습니다.
Daejin Lab에서는 아래 상황을 중단 신호로 봅니다.
공식 자료와 실제 화면이 다르다
직접 실행하지 않은 결과를 경험처럼 써야 한다
이미지의 사용 권리를 확인할 수 없다
외부 서비스 상태를 바꾸는 작업이 필요하다
요청 범위 밖의 파일을 수정해야 한다
발행 후 되돌리기 어려운 판단이 남아 있다
이때 필요한 결과는 억지로 완성한 답이 아닙니다. 확인되지 않은 부분을 표시하고 다음 판단을 사람에게 넘기는 것입니다.
작은 팀이 먼저 가져올 수 있는 구조
Presence는 일부 기업을 위한 제한된 프로그램이고, OpenAI의 현장 엔지니어와 지정 파트너가 구축에 참여합니다. 개인 개발자가 가입해 바로 켜는 제품은 아닙니다.
그래도 운영 구조는 작은 프로젝트에도 적용할 수 있습니다.
업무 카드
맡길 일:
필요한 입력:
허용할 도구:
금지할 행동:
성공 기준:
사람에게 넘길 조건:
기록할 로그:
작업 등급
| 등급 | 예시 | 기본 처리 |
|---|---|---|
| 낮음 | 분류, 요약, 형식 검사 | 자동 실행 후 기록 |
| 중간 | 초안 작성, 파일 수정 | 변경점 검토 후 반영 |
| 높음 | 공개, 전송, 삭제, 결제 | 사람 승인 전 중단 |
배포 전 질문
에이전트가 맡은 일이 한 문장으로 설명되는가
접근하지 않아도 되는 정보가 연결돼 있지 않은가
승인이 필요한 행동을 코드 수준에서 막았는가
정상 입력보다 실패 입력을 더 많이 시험했는가
중단과 사람 인계가 실제로 동작하는가
운영 후 문제를 재현할 로그가 남는가
이 정도만 정해도 “어떤 모델을 쓸까”보다 먼저 해결해야 할 문제가 보입니다.
지금 가져갈 결론
OpenAI Presence 발표에서 눈에 들어온 것은 모델 밖의 운영 장치였습니다. 실제 업무에 연결하려면 권한과 승인, 평가와 사람 인계가 먼저 정해져야 했습니다.
특정 업무, 최소 접근, 승인된 행동, 배포 전 평가, 사람 인계와 운영 후 개선이 함께 있어야 실제 업무에 연결할 수 있습니다. 운영 장치가 없는 에이전트는 권한만 큰 자동 실행 도구가 되기 쉽습니다.
Daejin Lab도 같은 선을 유지하려고 합니다. 초안과 반복 검사는 더 자동화할 수 있습니다. 공개 상태 변경과 외부 반영은 사람이 확인합니다. 이 절차는 잘못된 공개를 줄이고 자동화를 오래 쓰기 위한 조건입니다.
같이 읽을 글
- 발행 버튼을 자동화하지 않기로 한 이유
- Daejin Lab 운영 원칙을 먼저 정했습니다
- 프롬프트보다 중요한 작업 분해 방식
- 외부 AI 에이전트 repo를 설치하기 전에 보는 안전 체크리스트
참고 자료
기준일은 2026년 7월 23일입니다. Presence의 제공 범위와 기능은 바뀔 수 있습니다. 실제 도입을 검토할 때는 공식 발표와 계약 조건을 다시 확인해야 합니다.