오늘의 핵심

1. 유출된 토큰을 파일에서 지우는 일과 그 토큰을 폐기·교체하는 일은 다르다. Git 이력까지 포함한 대응과 자격증명 회전이 함께 필요하다.
2. MCP의 도구 연결은 특허·사내 데이터에 자연어 접근 경로를 만들 수 있지만, 검색 범위·호출 주체·반환 데이터의 경계를 별도로 설계해야 한다.
3. 에이전트가 읽기에서 쓰기로 넘어갈수록 권한·승인·도구 호출·정책 판정·결과를 하나의 추적으로 묶는 감사 기록이 중요해진다.

1. 자격증명 보안: 파일 삭제만으로 Git 이력의 비밀값이 사라지지 않는다

MCP 서버가 SaaS, 코드 저장소, 데이터베이스, 사내 API에 연결될 때 자격증명은 단순 환경 설정이 아니다. 토큰 하나가 가진 권한 범위에 따라 에이전트가 읽을 수 있는 데이터와 실행할 수 있는 작업의 범위도 함께 정해진다. 따라서 개발팀은 “비밀값이 현재 파일에 있는가”만 보지 말고, 어떤 저장소·브랜치·배포 환경·로그·메신저·티켓에 그 값이 남을 수 있는지 함께 점검해야 한다.

GitHub Docs는 유출된 비밀값을 처리할 때 먼저 그 비밀값을 폐기하거나 교체하고, 그다음 저장소 이력에서 민감한 데이터를 제거하는 절차를 설명한다. 이는 파일에서 값을 삭제하거나 새 커밋을 추가하는 조치만으로 과거 커밋의 데이터가 자동으로 사라지지 않는다는 뜻이다. 이미 외부에 노출되었을 가능성이 있는 토큰은 이력 정리의 성공 여부와 별개로 사용 중지 또는 교체 대상이 된다. 한국 개발팀이 Git 기반 협업과 여러 SaaS를 함께 운영한다면, 저장소 정리 작업을 토큰 회전의 대체 수단으로 읽지 않는 것이 중요하다.

원문 · GitHub Docs Remediating a leaked secret in your repository - GitHub Docs 유출된 비밀값의 폐기·교체와 저장소 이력 정리를 구분해 설명하는 공식 문서다. OG 이미지: https://docs.github.com/assets/cb-345/images/social-cards/code-security.png

대응 순서는 단순하지만, 각 단계의 소유자가 분명해야 한다. 첫째, 해당 키·토큰·비밀번호·인증서를 즉시 비활성화하거나 회전한다. 둘째, 그 자격증명으로 접근 가능한 계정과 시스템을 확인한다. 셋째, 저장소 이력과 포크, 배포 산출물, CI 로그, 캐시, 문서화된 예제까지 조사 범위를 넓힌다. 넷째, 새로운 자격증명을 발급하되 이전 키보다 좁은 권한, 짧은 유효 기간, 용도별 분리를 적용할 수 있는지 검토한다. 마지막으로 누가 언제 어떤 키를 바꾸었는지와 후속 확인 결과를 남긴다.

MCP의 인가 규격은 서버가 보호된 리소스에 접근할 때 OAuth 기반 흐름과 권한 위임에 관한 요구사항을 다룬다. 이 문서는 특정 조직의 비밀 관리 제품이나 단일 배포 방식을 강제하지 않는다. 다만 MCP 연결을 만들 때 “클라이언트가 서버에 붙는다”는 편의적 설명만으로는 부족하며, 권한 부여 서버, 리소스 서버, 토큰의 대상과 범위를 구분해야 함을 보여 준다. 사내 서비스 계정 하나를 여러 MCP 서버와 업무에 공유하면 유출 시 영향 범위와 조사 범위가 커진다.

규격 · Model Context Protocol Authorization - Model Context Protocol MCP의 OAuth 기반 인가 흐름과 보호된 리소스 접근을 다루는 규격이다. OG 이미지: https://raw.githubusercontent.com/modelcontextprotocol/docs/2eb6171ddbfeefde349dc3b8d5e2b87414c26250/images/og-image.png

운영 표에는 최소한 자격증명 이름, 소유 팀, 연결 대상, 권한 범위, 발급일, 만료·회전 기준, 저장 위치, 비상 폐기 절차를 넣을 수 있다. “개발용”처럼 넓은 이름보다 “특허검색-읽기전용-개발”, “CRM-고객수정-승인형”처럼 목적과 권한을 드러내는 이름이 조사와 교체를 쉽게 만든다. 코드에는 실제 비밀값 대신 참조 이름만 두고, 배포 환경에서 비밀 관리 저장소 또는 승인된 주입 경로를 통해 값을 제공하는 구조가 더 적합하다.

중요한 점은 Git 이력 삭제를 만능 복구로 취급하지 않는 것이다. 이력 재작성은 협업 저장소의 기존 복제본과 작업 흐름에 영향을 줄 수 있다. 반면 자격증명 폐기와 교체는 이미 노출된 값의 후속 사용을 차단하기 위한 별도 조치다. 대응 문서에는 이 두 작업을 같은 체크리스트 안에 두되, 완료 조건은 따로 둬야 한다. “저장소에서 문자열이 보이지 않는다”가 아니라 “기존 자격증명이 더 이상 유효하지 않고, 새 자격증명은 필요한 범위로만 동작한다”가 보안 대응의 핵심 확인점이다.

2. 사내·특허 데이터 연결: 자연어 접근 경로와 데이터 경계를 함께 설계한다

MCP는 모델과 외부 도구·데이터 원천을 연결하기 위한 프로토콜이다. 이 연결은 사내 문서 검색, 고객 지원 이력 조회, 연구 자료 탐색, 특허 선행기술 검토처럼 여러 화면과 검색식에 흩어진 업무를 하나의 대화 흐름으로 가져올 수 있다. 그러나 “연결 가능”은 “모든 데이터에 접근 가능”을 뜻하지 않는다. 특히 특허와 산업재산권 정보는 공개 데이터, 계약 기반 데이터, 유료 분석 결과, 고객별 프로젝트 산출물이 섞일 수 있으므로 데이터 출처와 이용 조건을 구분하는 설계가 필요하다.

WIPS 홈페이지는 2026년 9월 22일 자 언론보도 항목으로 “챗GPT에 특허DB 바로 연결”과 WIPS MCP 공개를 언급한다. 이는 특허 데이터 접근을 MCP 맥락에서 다루는 국내 사업자의 공개 신호다. 다만 홈페이지의 보도 제목만으로 특정 기능의 전체 범위, 이용 가능 지역, 고객별 권한, 데이터 정확도나 상업적 이용 조건까지 단정할 수는 없다. 도입 검토에서는 공개 발표와 실제 계약·제품 문서·테넌트별 설정을 분리해 확인해야 한다.

원문 · WIPS WIPS 홈페이지의 2026년 9월 22일 언론보도 목록은 WIPS MCP 공개와 특허 DB 연결을 언급한다. OG 이미지: https://www.wipscorp.com/images/common/og-img.png

국내 특허 데이터 연결을 설계할 때는 데이터 자체와 조회 권한을 같은 것으로 취급하지 않아야 한다. KIPRIS Plus는 지식재산정보 활용 서비스를 제공하며 Open API, 벌크 데이터, 국내·해외 IP 데이터 등의 메뉴를 공개한다. 이 사실은 특허·지식재산 데이터가 검색 화면만이 아니라 API와 데이터 활용 형태로도 제공될 수 있음을 보여 준다. 하지만 특정 API 호출이 가능한지, 어떤 인증·신청·이용 조건이 필요한지, MCP 서버가 반환할 수 있는 필드가 무엇인지는 해당 서비스의 이용 절차와 계약 조건으로 다시 확인해야 한다.

실무 설계의 출발점은 “에이전트가 무엇을 찾아야 하는가”보다 “이 연결이 어떤 질문에만 답해야 하는가”를 정하는 일이다. 예를 들어 연구개발 부서는 출원번호, 공개번호, 분류, 인용 관계, 법적 상태 같은 검색 결과가 필요할 수 있다. 반면 고객 프로젝트 메모, 분석가의 사내 의견, 미공개 전략 문서는 같은 도구 호출에서 자동으로 섞여 나와서는 안 될 수 있다. 데이터 원천별로 읽기 전용 여부, 반환 가능한 필드, 검색 필터, 다운로드 가능 여부, 재배포 가능 여부를 표로 나누면 자연어 질의가 넓은 권한 우회 경로가 되는 일을 줄일 수 있다.

사내 데이터에도 같은 원칙이 적용된다. 인사·재무·계약·고객관리 시스템을 MCP 도구로 연결할 때는 팀의 일반적인 문서 접근 권한을 그대로 복제하기보다, 업무 흐름별 최소 데이터 묶음을 먼저 정하는 편이 낫다. 특허 조사 에이전트에 필요한 정보가 전체 계약 저장소라면, 도구 정의가 너무 넓을 가능성을 먼저 의심할 수 있다. 검색 결과에는 문서 원문 대신 문서 식별자와 접근 요청 경로를 반환하고, 원문 열람은 기존 권한 시스템에서 다시 판단하게 만드는 방식도 가능하다.

국내 금융·공공·지식재산 API를 함께 다루는 팀은 호출 기록도 데이터 거버넌스의 일부로 보아야 한다. 누가 어떤 주체로 어떤 검색 조건을 요청했는지, 어떤 데이터 원천이 선택됐는지, 결과가 외부 모델 문맥으로 전달됐는지, 결과가 후속 쓰기 작업에 사용됐는지를 연결해 남긴다. 로그에 질의 원문과 결과 원문을 모두 보관해야 한다는 뜻은 아니다. 민감하거나 계약상 제한된 값은 마스킹·참조값·보존 기간·접근 통제를 별도로 적용한다. 핵심은 문제 발생 뒤 “어떤 데이터가 어느 경로를 거쳤는가”를 재구성할 수 있어야 한다는 점이다.

3. 실행 권한과 감사 로그: 대화형 에이전트를 실행형 시스템으로 다룬다

에이전트의 위험은 답변 문장보다 도구 호출에서 현실화된다. 문서 검색은 비교적 낮은 영향의 읽기 작업일 수 있지만, 티켓 변경, 이메일 발송, 고객 계정 수정, 파일 삭제, 구매 요청 생성은 시스템 상태나 외부 관계를 바꾼다. 따라서 도구를 “연결돼 있다” 또는 “연결돼 있지 않다”로만 관리하면 부족하다. 읽기·쓰기·외부 전송·대량 변경·되돌릴 수 없는 작업처럼 행동의 성격에 따라 서로 다른 권한과 승인 경로를 설계해야 한다.

MCP 도구 규격은 사용자에게 서버 호출 전 검토 기회를 제공하고, 도구 호출에 사람이 개입해 거부할 수 있어야 한다고 설명한다. 또한 애플리케이션이 노출되는 도구를 명확히 보여 주고, 도구 호출 시 시각적 표시와 확인 절차를 제공할 것을 권고한다. 이 내용은 모든 호출에 같은 승인 화면을 강제하는 규칙은 아니다. 그러나 사람이 이해하고 중단할 수 없는 실행 경로를 기본값으로 두지 말라는 설계 원칙으로 읽을 수 있다.

규격 · Model Context Protocol Tools - Model Context Protocol 도구 호출에 대한 사용자 검토, 인간의 거부 가능성, 도구 사용 감사 기록을 다루는 MCP 규격이다. OG 이미지: https://raw.githubusercontent.com/modelcontextprotocol/docs/2eb6171ddbfeefde349dc3b8d5e2b87414c26250/images/og-image.png

권한 표는 역할 이름만 적는 문서가 아니라 실행 단위의 계약에 가깝다. 각 도구에 대해 호출 주체, 허용된 대상 시스템, 읽기·쓰기 범위, 허용되는 인자 범위, 시간·횟수 제한, 추가 승인 조건, 중단 방법을 명시한다. 예를 들어 “CRM 접근 가능”보다 “고객 지원 티켓 조회 가능, 고객 등급 변경은 승인 대기열 필요, 내보내기 금지”처럼 쓰는 편이 실제 정책과 테스트에 쓸모가 있다. 서비스 계정도 사람 계정처럼 광범위하게 부여하기보다 업무별로 분리하고, 불필요해진 연결은 제거한다.

WorkOS는 에이전트 감사 로그가 일반 애플리케이션 로그와 다른 이유로, 누가 작업을 시작했는지, 어떤 권한에 따라 행동했는지, 세션의 예상 범위 안에서 실행됐는지, 사람 승인이 있었는지 같은 질문을 제시한다. 이 글은 특정 규제의 법적 준수 기준이 아니라 에이전트 기록 설계에 관한 기술적 해설이다. 다만 에이전트가 위임된 권한과 여러 도구 호출을 사용한다면, HTTP 상태 코드나 오류 메시지 중심의 기존 로그만으로 행동 경위를 충분히 설명하기 어려울 수 있다는 지적은 운영에 직접적인 시사점을 준다.

해설 · WorkOS Why AI agent audit logs are different from application logs — WorkOS 에이전트 실행에서 시작 주체, 권한, 세션 범위, 사람 승인까지 추적해야 하는 이유를 설명한다. OG 이미지: https://images.workoscdn.com/images/8ba7a56c-994b-4436-ab5b-45e423219a38.png?auto=format&fit=clip&q=80

감사 기록의 최소 단위는 하나의 답변이 아니라 하나의 실행 추적이다. 요청 식별자, 사용자 또는 서비스 주체, 에이전트와 모델 구성 버전, 선택된 도구, 호출 인자에서 마스킹한 요약, 적용된 정책, 승인·거부·수정 결과, 실행 시각, 반환 상태, 후속 작업의 연결 관계를 함께 남긴다. 이때 프롬프트와 원문 데이터를 무제한으로 저장하면 로그가 또 다른 민감 데이터 저장소가 될 수 있다. 필요한 증거와 불필요한 원문을 분리하고, 로그 자체에 대한 열람 권한과 보존·삭제 기준도 정해야 한다.

승인은 고정된 버튼 하나가 아니라 위험에 따른 경로가 될 수 있다. 사내 공개 문서 검색은 제한된 자동 실행을 허용할 수 있고, 고객 정보 수정은 담당자 승인, 외부 이메일 발송은 수신자·첨부·최종 본문 확인, 대량 삭제·지급·계정 권한 변경은 별도 분리 승인으로 설계할 수 있다. 승인자는 모델이 제안한 자연어 설명만 보는 것이 아니라 대상 시스템, 실제 변경 항목, 영향 범위, 되돌림 가능 여부를 확인할 수 있어야 한다. 에이전트가 실행 전에 멈출 수 있는 구조가 있어야 로그도 사후 해명 이상의 통제가 된다.

국내 업무 자동화 환경에서는 기술팀만으로 이 표를 완성하기 어렵다. 현업 소유자는 실제 예외와 승인 기준을 알고, 보안팀은 계정·비밀값·로그 보존 경계를 알고, 플랫폼팀은 도구 호출과 장애 복구 경로를 안다. 세 팀이 함께 “이 도구가 틀린 대상에 쓰이면 무엇이 바뀌는가”, “누가 중단할 수 있는가”, “사후에 무엇을 확인할 수 있는가”를 점검해야 한다. 결과물은 거창한 정책 선언보다 도구별 권한 표, 승인 규칙, 로그 스키마, 분기별 복구 시험 목록이면 충분하다.