기업 환경의 제약 속에서 Cursor로 개인 AI 비서 만들기

제가 주의 깊게 볼 부분은 '개인 자격 증명 + 에이전트 스킬'을 단순히 편리한 계층 정도로만 취급하는 것입니다. 기업 환경에서는 사실상 작은 비공식 서비스 계정이 되는 셈이라, 자동화를 더 추가하기 전에 각 워크플로우마다 확실한 경계를 두는 것이 좋겠습니다.

실용적인 구조:

• 워크플로우당 하나의 기능 파일: 사용된 API, 필요한 scope, 읽기/쓰기 수준, 접근하는 데이터 클래스, 최대 실행 빈도, 소유자
• 플랫폼이 허용한다면 도구/워크플로우별로 토큰 분리

정말 훌륭한 보안 모델이네요. 공유해 줘서 고마워요.

지금 저는 주로 이런 툴 연결을 사용해서 컨텍스트를 가져오는 용도로 쓰고 있어요. 대부분 읽기 전용 작업이고, Confluence나 Jira, GitHub에 문서를 작성하는 것 같은 저위험 업데이트 정도만 하고 있습니다.

그렇게 나누는 건 일리가 있네요. 다만 '읽기 전용'과 '저위험 쓰기'를 한 바구니에 넣는 건 피하는 게 좋을 것 같아요.

읽기 전용은 주로 노출 제어에 관한 문제죠:

• 어떤 시스템을 읽을 수 있는지
• 어떤 데이터 클래스가 프롬프트에 허용되는지
• 고객 데이터, 보안 정보, 사내 인사/법무/보안 자료, 내부 사고 기록 등이 제외되었는지
• 답변을 생성하기 위해 어떤 소스를 읽었는지에 대한 기록

저위험 쓰기 작업은 별도의 경계가 필요해요. 왜냐하면 문서가 나중에 권위 있는 자료가 될 수 있거든요. Confluence 페이지는...

이해하려고 물어보는 건데, 승인이라고 할 때 본인 승인을 말하는 거야, 아니면 다른 사람의 승인을 말하는 거야? 내 경우에는 노트북에서 돌아가는 개인 비서라서 (바라건대) 내가 명시적으로 내린 명령만 실행하거든. 그리고 어차피 내가 수동으로 해야 하는 작업들이고. 코드 짜는 거랑 비슷하게, 내가 검토하고 테스트도 거칠 거니까.

네 설정에서 승인은 보통 너 자신을 의미하지, 다른 사람을 의미하는 게 아니야. 내가 구분하고 싶은 건 '누가 승인하느냐'보다는 '정확히 무엇을 승인했느냐'야. 개인 비서라면 저위험 기획이나 초안 작성 정도는 네 명시적인 명령만으로도 충분해. 하지만 에이전트가 외부적인 부작용을 일으킬 때, 예를 들어 Jira 수정, Confluence 페이지 게시, GitHub 푸시, 메시지 전송, 상태 변경, 고객 데이터 접근 같은 작업을 할 때는 2차 승인을 추가할 것 같아. 이유는 '이거 해...'라는 게...