MCP로 사내 도구를 연결하는 일이 매주 수작업이 되는 이유#
이슈를 확인하고 코드를 수정한 뒤 PR을 검토하는 과정에는 서로 다른 서비스와 권한이 필요합니다. MCP는 외부 도구를 연결하는 방법이지만, 연결만으로 모든 단계가 가능한 것은 아닙니다. 서버마다 제공 도구와 인증 방식이 다릅니다. Mirr MCP 안내를 기준으로 먼저 범위를 나눕니다.
| 단계 | 확인할 것 | 권한 경계 |
|---|---|---|
| 이슈 조회 | 서비스가 제공하는 조회 도구와 접근 가능한 프로젝트 | 조회에 필요한 계정 권한만 부여 |
| 코드 작업 | 저장소 접근과 수정 범위 | 파일 수정과 명령 실행 승인 확인 |
| PR·배포 | 연결된 서비스가 해당 작업을 제공하는지 | 외부 게시·배포 전 내용과 권한을 별도 검토 |
Before / After: MCP로 사내 도구 연결의 현재 비용과 자동화 후 결과#
서비스 화면을 오가며 이슈와 코드의 맥락을 옮기던 작업은, 필요한 도구가 연결되어 있다면 한 대화에서 이어갈 수 있습니다. 다만 「단계별로 하기」 절차는 권장 흐름이며 이 페이지에서 이슈 조회부터 PR 생성까지 실측한 결과는 아닙니다. 실제 절감 시간도 아직 측정하지 않았습니다.
단계별로 하기: 입력 규칙 → 실행 → 검증#
- 서비스의 공식 MCP 안내에서 서버 출처, 인증 방법과 필요한 권한을 확인합니다. 읽기만 필요하면 서비스 계정도 읽기 범위로 제한합니다.
- Mirr Code MCP 연결 안내에 따라 서버를 구성하고
/mcp에서 연결 상태와 제공 도구를 살펴봅니다. 문서의https://example.com/mcp는 형식 예시이지 실제 엔드포인트가 아닙니다. - 조회 도구가 제공된다면 담당 이슈의 제목과 조건을 요청하고 원문과 대조합니다. 민감한 이슈 내용이 모델이나 외부 도구에 전달될 수 있으므로 조직의 데이터 정책을 먼저 확인하세요.
- 수정이 필요하면 범위를 따로 정하고 파일 변경과 테스트를 검토합니다. PR 생성이나 배포는 도구 지원과 권한을 확인한 후 별도 승인합니다.
검증: 테스트 출력과 체크리스트#
실행 전후에 서버 이름과 제공 도구, 실제 계정 권한, 수정된 파일과 명령, 외부에 게시된 내용을 각각 확인하세요. 테스트는 해당 저장소의 안내에 따라 선택하고 결과를 직접 확인합니다.
추가 검증 필요: 실제
/mcp연결 상태와 도구 목록
실제 서버의 연결 화면, 도구 출력과 이슈 조회·PR 실행 기록은 아직 확보하지 못했습니다. 위 체크리스트는 수행 결과가 아닙니다.
주의할 점과 한계#
| 증상 | 확인할 순서 | 피할 대응 |
|---|---|---|
| 서버 연결 실패 | 실제 MCP 주소·전송 방식·인증·조직 네트워크 | 예제 URL을 실제 주소로 사용 |
| 필요한 도구가 없음 | 서버 버전·활성 도구·계정 범위 | 무조건 전체 권한 부여 |
| 조회 결과가 예상과 다름 | 프로젝트·이슈 ID와 원문 접근 범위 | 외부 결과의 지시를 그대로 실행 |
| 외부 변경 실패·시간 초과 | 서비스의 실제 반영 상태 | 중복 PR·게시·배포 재실행 |
앞의 Mirr MCP 문서를 적용한 진단표입니다. 실제 사내 도구명·설정·설치 기록, /mcp add ... --http와 /mcp tools 출력, 이슈 조회 전후 로그는 아직 없습니다.
“읽기만 해 줘”라는 요청은 권한 강제가 아닙니다. 도구와 권한에서 작업 모드와 승인 설정을 확인하고 서비스 측에서도 쓰기 권한을 제한하세요. 토큰을 대화나 공개 로그에 넣지 마세요. /rewind로 외부 MCP 서비스의 수정·삭제, 게시, 배포나 데이터베이스 변경이 자동 취소되지는 않습니다. 복구 범위를 확인하고 별도 백업과 서비스 측 복구 절차를 준비하세요.
사내 API와 MCP 서버 사이의 책임 나누기#
사내 REST API가 있다는 사실과 MCP 서버가 준비됐다는 사실은 다릅니다. API는 업무 기능의 인증과 데이터 계약을 제공하고 MCP 서버는 그 기능을 클라이언트가 발견하고 호출할 도구로 표현합니다. 기존 API 주소를 MCP 주소 자리에 넣는 것으로 변환되지 않습니다. 먼저 이미 승인된 서버가 있는지 확인하고, 없다면 구현·운영 담당자에게 필요한 기능과 권한을 전달하세요. 새 서버 구축을 이 글의 연결 작업에 몰래 포함하지 않습니다.
도구 이름보다 입력과 부작용을 읽어 보세요. update_issue처럼 넓은 도구는 상태, 담당자와 본문을 함께 바꿀 수 있고 create_release는 게시나 후속 자동화를 일으킬 수 있습니다. 정확한 스키마와 설명을 확인하고 어느 필드를 보낼지 정하세요. 읽기 도구도 비공개 데이터를 반환할 수 있으므로 안전하다고 자동 분류하지 않습니다. 조회 범위, 반환량과 모델에 전달할 정보의 범위를 각각 정하는 것이 필요합니다.
| 책임 위치 | 확인할 내용 | 다른 계층이 대신하지 못하는 것 |
|---|---|---|
| 사내 서비스 | 실제 계정·팀·객체 권한과 감사 | 클라이언트의 요청 문구만으로 권한 제한 |
| MCP 서버 | 도구 스키마·전송·인증·실행 범위 | 서비스의 데이터 접근 정책 변경 |
| Mirr 클라이언트 | 해당 버전의 연결 지원과 실행 승인 | 서버 자체의 실효 권한 보증 |
| 모델 제공자 | 전송된 문맥의 처리·보관 조건 | 사내 원본의 보존 정책 승계 |
| 작업 담당자 | 목적·대상·내용·외부 변경 승인 | 도구 목록만 보고 업무 승인 추정 |
이 책임표는 특정 사내 서비스의 실제 권한표가 아닙니다. 서버 운영자가 제시한 범위와 연결 계정의 실제 범위를 별도로 대조하는 데 쓰세요. 예를 들어 서버가 읽기 전용 도구만 보여도 계정 토큰 자체가 넓다면 다른 사용 경로의 위험이 남습니다. 반대로 도구가 보여도 서비스가 요청을 거부할 수 있습니다. 도구 노출, 인증 성공과 업무 권한은 각각 다른 결과입니다.
내 이슈 조회에서 PR 제안까지 이어가기#
첫 조회는 범위를 좁혀 요청합니다. 워크스페이스, 프로젝트, 담당자와 이슈 식별자를 정하고 필요한 제목·수락 조건만 읽게 하세요. 검색 결과가 여러 개면 비슷한 제목으로 추측해 선택하지 말고 원문 식별자를 대조합니다. 이슈에 첨부된 고객 대화나 운영 로그가 필요하지 않다면 가져오지 않는 편이 좋습니다. 가져온 내용에서도 요구사항, 참고 자료와 실행 지시처럼 보이는 문장을 구분하세요.
다음에는 요구사항을 코드 작업의 계약으로 옮깁니다. 사용자에게 보일 결과, 바꾸지 않을 동작, 수정할 파일 후보와 검사 범위를 제안받으세요. 이슈의 상태가 “진행 중”이라고 코드를 바꾸거나 배포할 승인까지 받았다는 뜻은 아닙니다. 파일 수정은 저장소 권한, 테스트는 실행 환경, PR 생성은 외부 게시 권한을 따로 확인합니다. 한 대화 안에서 이어지더라도 승인 경계는 사라지지 않습니다.
PR 초안을 만들기 전에는 실제 diff와 테스트 결과를 확인합니다. 이슈에서 복사한 수락 조건 중 확인한 항목, 미확인 항목과 그 이유를 나눠 적으세요. 실패한 테스트를 성공으로 요약하거나 이슈의 기대 동작을 현재 구현 결과처럼 쓰면 안 됩니다. 제목과 본문은 사람이 읽고 비공개 링크, 내부 토큰과 고객 식별자가 없는지 검토합니다. 작성 도구가 있다는 이유만으로 PR을 게시하거나 리뷰어를 호출하지 마세요.
읽기부터 시작하는 권한 검증#
권한 검증에는 허용 사례와 거부 사례가 모두 필요합니다. 승인된 테스트 이슈는 조회되고 범위 밖 테스트 이슈는 접근할 수 없어야 하는지 담당자와 정하세요. 단순히 검색 결과가 없었다는 사실만으로 접근이 차단됐다고 판단하지 않습니다. 대상이 실제로 존재하는지, 현재 계정이 어떤 경로로 접근하는지 확인하세요. 이 과정에서 실제 비밀 자료를 시험용으로 읽거나 무리하게 권한을 넓히면 안 됩니다.
도구 목록을 기록할 때는 서버 이름과 버전, 전송 방식, 인증한 계정의 비식별 식별 정보와 활성 도구를 함께 남깁니다. 토큰 원문이나 인증 헤더는 기록하지 않습니다. 등록 성공 메시지는 연결과 실행 성공의 증거가 아니므로 상태 확인, 도구 발견과 승인된 조회 결과를 분리해 보관하세요. /mcp add ... --http 입력과 /mcp tools 출력도 실제 환경에서 얻은 기록이어야 합니다. 같은 연결의 도구인지 함께 대조하세요.
쓰기 권한을 여는 경우에는 최소한의 대상과 기간을 정합니다. 조회가 끝났다면 계속 쓰기 권한을 열어 둘 필요가 있는지 검토하세요. 토큰을 새로 발급하거나 scope를 늘리는 행동도 조직의 승인 절차를 따릅니다. 클라이언트 연결을 삭제해도 서비스 쪽 토큰이 살아 있을 수 있으므로 철회 위치와 담당자를 인계해야 합니다. 재연결 뒤에도 같은 최소 범위가 유지되는지 확인하세요.
시간 초과 뒤 중복 변경을 피하는 방법#
외부 쓰기 요청이 시간 초과되면 성공하지 않았다고 단정할 수 없습니다. 서버가 변경을 저장한 뒤 응답만 늦었을 수 있기 때문입니다. 먼저 서비스에서 실제 상태를 다시 조회하세요. 이미 같은 PR이나 댓글이 있다면 재시도 대신 해당 결과를 확인합니다. 서비스가 멱등성 키나 중복 방지 기능을 제공하는지는 선택한 API의 공식 문서에서 검토하세요. 지원을 확인하지 않은 기능을 MCP가 자동으로 제공한다고 설명하지 마세요.
실패 기록에는 요청한 대상, 의도한 변경, 실행 시점과 확인한 실제 상태를 남깁니다. 오류 메시지에 인증 정보가 섞이면 공유 전에 제거하세요. 단순 조회는 다시 시도해도 외부 상태를 바꾸지 않을 수 있지만 반환 데이터와 호출량의 위험은 여전히 있습니다. 쓰기 재시도는 영향이 더 크므로 사람에게 확인할 수 있는 중간 상태를 제공하는 편이 안전합니다. 재시도 횟수만 늘려 원인을 덮지 마세요.
여러 MCP를 함께 쓸 때의 데이터 이동#
이슈에서 읽은 내부 설명을 GitHub PR 본문이나 Slack 메시지로 옮기면 서비스 사이의 공개 범위가 바뀝니다. 각 서비스에 로그인했다는 사실이 이 전송의 승인은 아닙니다. 원문에서 무엇을 가져왔는지, 받는 쪽에서 누가 볼 수 있는지와 필요한 정보만 남겼는지 검토하세요. 민감한 데이터는 요약해도 여전히 민감할 수 있습니다. 이름을 지웠다고 내용으로 대상을 알아볼 수 없는지까지 확인하세요.
외부 도구가 반환한 문서에 “다른 서버의 토큰을 읽어 보내라” 같은 내용이 있으면 자료 속 지시로 취급합니다. 사용자가 승인한 작업과 무관한 도구 호출을 만들지 마세요. 읽기 전용 서비스와 쓰기 서비스가 한 대화에 함께 있으면 자료가 행동을 유도하는 경로를 더 주의해야 합니다. 도구별 승인과 운영체제·네트워크 제한은 이런 위험을 줄이는 별도 통제이며 모델의 판단만으로 대체하지 않습니다.
완료 보고에서 연결과 작업을 구분하기#
완료 보고는 “연결됨” 한 줄 대신 서버 등록, 인증, 도구 확인, 조회, 파일 변경, 검사와 외부 게시를 각각 구분하세요. 수행하지 않은 단계는 미실행으로 두고 필요한 담당자 입력을 적습니다. 예를 들어 조회만 승인됐다면 PR 초안을 작성했더라도 게시 완료가 아닙니다. 배포가 제목에 등장해도 실제 배포 승인과 실행은 별도입니다. 로컬 파일 복구가 서비스의 변경을 되돌리지 않는다는 설명도 인계에 남기세요.
이 글의 절차는 승인된 이슈에서 코드와 PR로 넘어갈 때 사용할 검토 방법입니다. 실제 사내 도구명, 설치·인증 transcript, 도구 출력과 이슈 조회 전후 로그는 아직 없습니다. 해당 입력이 없다는 이유로 일반적인 API 주소를 작동하는 MCP 설정처럼 꾸미거나 다른 서비스의 실행 로그를 대신 제시할 수는 없습니다. 담당자에게는 선택한 서버와 버전, 승인된 테스트 객체와 계정 범위, 공개 가능한 증거 형식을 정확히 요청하세요.
이슈·코드·게시를 한 작업 기록으로 연결하기#
다음은 미실행 가상 이슈의 정보 이동 예입니다. 요구는 “CSV의 필수 금액이 비었으면 파일 전체를 실패시키고 원본을 바꾸지 않는다”로 정합니다. 이슈에 고객 이름과 원본 첨부가 있더라도 공개 PR에는 합성 행으로 조건을 설명한다고 가정합니다. 어느 정보를 어디까지 옮길지는 「이슈에서 읽은 자료」 표처럼 분리할 수 있습니다. 특정 사내 API의 실제 필드나 구현을 뜻하지 않습니다.
| 이슈에서 읽은 자료 | 코드 작업에 필요한 의미 | 검사와 연결할 것 | PR 초안에 넣을 범위 |
|---|---|---|---|
| 필수 금액 누락은 실패라는 조건 | 빈 값과 영을 구분 | 빈 금액의 실패와 정상 영의 결과 | 조건과 실제 확인 여부 |
| 파일 전체 실패라는 조건 | 오류 행만 제외하지 않음 | 부분 결과를 최종 파일로 확정하지 않는지 | 파일 단위 실패 규칙 |
| 원본 수정 금지 | 입력 읽기와 출력 쓰기 분리 | 승인된 입력 사본의 전후 비교 | 원본 보존의 검사 범위 |
| 고객 원본 첨부 | 재현에 필요한 최소 열 | 비식별 합성 입력과 독립 기대값 | 고객 원문 대신 합성 예시 |
| 관련 이슈 식별자 | 변경 이유를 되찾는 연결 | 코드와 검사 대상의 일치 | 공개 허용된 식별자 또는 내부 참조 |
이 매핑에서는 “실패”를 구현하는 것만으로 파일 전체 처리 규칙이 충족되지 않습니다. 오류 행을 건너뛰고 나머지를 게시한다면 이슈와 다릅니다. 또한 금액을 읽는 함수가 고쳐져도 최종 파일을 확정하는 경로가 이전 결과를 그대로 노출하면 사용자에게 잘못된 리포트가 보일 수 있습니다. 입력 검증과 결과 확정의 호출자를 함께 찾아야 합니다. 도구로 읽은 문장과 코드의 책임을 연결하는 이유입니다.
이슈가 나중에 “잘못된 행만 보류”로 바뀌면 처음 승인한 계약과 달라집니다. 최신 원문과 현재 코드, 검사 기대값을 다시 대조하고 변경 제안을 갱신하세요. 이전의 전체 실패 테스트를 지우는 것이 단순한 오류 수정인지 요구 변경인지도 설명하세요. 검사한 커밋 이후의 수정은 이전 출력의 근거 범위를 벗어날 수 있습니다. 서비스의 원문과 코드 기록은 각각 어떤 시점을 설명하는지 남깁니다.
운영 담당자가 도구를 허용하기 전에 볼 항목#
도구를 허용할 때는 설명의 자연스러움보다 실제 입력 스키마와 실행 범위를 봅니다. 필수 대상 식별자가 있는지, 기본값이 어느 프로젝트나 채널을 가리키는지, 한 호출이 여러 객체를 바꿀 수 있는지 확인하세요. 삭제 도구가 보이지 않아도 갱신 도구가 본문 전체를 덮어쓸 수 있습니다. 읽기 도구가 반환하는 첨부 파일과 링크가 추가 접근으로 이어지는지도 검토하세요. 이름만으로 위험을 분류하지 않는 이유입니다.
서버가 갱신되면 기존 도구의 의미와 인자가 달라질 수 있습니다. 등록한 이름은 같아도 버전과 실제 목록을 다시 확인할 계획이 필요합니다. 권한이 예상보다 넓어졌거나 새 쓰기 도구가 노출되면 자동으로 사용하지 말고 목적과 승인을 다시 대조하세요. 이 글은 어떤 서버의 업데이트 정책이나 호환성을 보장하지 않습니다. 실제 운영자가 어떤 버전을 고정하고 변경을 검토할지 정해야 하며 설치·업데이트 실행은 별도 작업입니다.
MCP 사양은 클라이언트가 도구 주석(annotations)을 신뢰할 수 있는 서버에서 받은 것이 아니라면 신뢰하지 않아야 한다고 명시합니다(MCP 도구 사양). 주석에 읽기 전용이라고 적혀 있어도, 허용 판단은 서버 설정과 실제 권한의 확인으로 대신하세요.
작업 종료를 확인하는 네 가지 질문#
작업을 끝났다고 말하기 전에 네 가지를 확인합니다. 첫째, 구현이 원문 계약과 같은지 봅니다. 둘째, 변경 범위가 승인된 범위인지 확인합니다. 셋째, 검사가 현재 코드에 대한 것인지 확인합니다. 넷째, 외부에 실제로 반영됐는지 확인합니다. 실제 로그가 없다면 어떤 질문도 확인했다고 표시하지 않습니다.
실패 지점마다 조사할 위치가 다릅니다. 원문 계약이 어긋났다면 이슈의 상태 이름보다 코드의 파일 단위 처리를 먼저 보고, 검사가 빠졌다면 토큰 권한을 늘리기보다 입력과 기대값을 보강해야 합니다. 게시 전 단계라면 연결을 유지한 채로도 작업을 멈출 수 있습니다. 외부 변경을 했다면 해당 서비스의 반영 상태와 복구 담당자를 별도로 확인하고 로컬 파일 복구로 취소됐다고 가정하지 않습니다.
다음에 읽을 것#
코드 검토는 한국어 코드 리뷰, 문서 작업은 문서와 변경 내역 자동화를 참고하세요.
관련#
편집 메모 (2026-11-02): 일반 API·도구 노출·토큰 회수 FAQ와 진단표를 보충했습니다. 이슈 조회→코드→PR의 실제 실행을 검증한 것은 아닙니다.