22장. MCP 기본 개념

MCP는 Model Context Protocol의 줄임말이고 AI 에이전트가 바깥 시스템의 자료를 읽고 동작을 시킬 수 있게 하는 공통 규약이다. 파트 1과 2에서 위키는 폴더 안에서 완결되었다. 논문이 들어오고 정리되고 연결되고 산출물이 나오는 순환이 파일 시스템 위에서만 일어났다. 연구책임자의 하루는 그 폴더 밖에서 시작한다. 결정을 요구하는 것들이 메일로 오고 일정은 달력에 있고 학생과의 대화는 메신저에 있고 프로젝트 상태는 팀이 함께 보는 문서에 있고 기관에 낼 서류는 HWP 파일로 온다. 이 자료들을 손으로 위키에 옮겨 적으면 옮긴 그날에만 정확한 사본이 생긴다. 에이전트가 그곳을 직접 읽을 수 있으면 옮겨 적을 필요가 없어지고 위키는 사본 대신 판단을 담는다. 그 연결을 만드는 규약이 MCP다. MCP를 연결하기 전에는 각 시스템에서 무엇을 읽고 어디까지 바꿀 수 있는지를 정해야 한다.

MCP는 에이전트가 데이터베이스, 웹 API, GitHub, Gmail, Slack, 로컬 파일시스템을 공통된 형식으로 호출하게 해 주는 연결 규약이다. 각 연결에서는 읽기와 쓰기의 범위를 따로 정한다.

규약이 연결을 도구에서 떼어 놓는 방식

규약이 있기 전에는 도구마다 연결 방식을 따로 만들어야 했다. 메일을 읽는 기능은 이 도구에만 있고 달력을 읽는 기능은 저 도구에만 있는 식이었고 도구를 바꾸면 연결을 다시 만들어야 했다. 공통 규약이 생기면서 서버가 제공하는 도구와 자료의 표현 방식은 여러 클라이언트가 이해할 수 있게 되었다. 연결한 서버를 다른 에이전트에서 쓰려면 각 클라이언트가 그 MCP 전송 방식과 기능을 지원해야 하고 서버 설정과 인증과 승인 정책도 적용되는 자리에서 갖춰야 한다. Codex의 데스크톱 앱과 명령줄과 편집기 확장은 같은 호스트에서 MCP 설정을 공유하지만 ChatGPT 웹은 플러그인이 제공하는 원격 MCP 도구를 쓰는 별도 경로다. 연결 뒤의 동작은 원자료를 바꾸지 않는 조회와 외부 상태를 바꾸는 쓰기로 나누어 볼 수 있다. 메일함을 검색하는 것은 조회이고 메일을 보내는 것은 쓰기다. 조회와 쓰기의 구분은 13장에서 본 권한의 경계를 바깥 시스템에 그대로 적용한다.

연결이 늘어난다고 위키가 저절로 좋아지지는 않는다. 연결은 자료를 가져올 수 있는 통로일 뿐이고 무엇을 가져와 어디에 둘지는 여전히 사람이 정한다. 통로를 열어 두고 규칙을 정하지 않으면 위키에 그날의 메일 내용과 그날의 일정이 그대로 복사되기 시작한다. 그렇게 만들어진 문서는 만든 날에만 정확하다. 메일은 답장이 오면서 바뀌고 일정은 옮겨지는데 복사본은 그대로 남아 있다가 반년 뒤에 틀린 정보로 읽힌다. 그래서 규칙은 하나로 정해 두었다. 사실은 그 사실을 소유한 자리에 두고 위키는 그곳을 가리킨다. 위키가 담는 것은 지금 이 일이 어디까지 왔고 다음에 무엇이 필요한지에 대한 현재 판단이다. 판단을 뒷받침하는 원자료는 메일함과 달력과 팀 문서에 그대로 두고 링크로 잇는다.

연결하기 전에 정하는 경계

MCP 연결에서 실제로 보이는 범위는 서비스의 인증 방식, 요청한 OAuth 범위, MCP 서버가 노출한 도구, 조직의 정책에 따라 달라진다. 어떤 메일 연결은 계정의 넓은 범위를 검색할 수 있고 다른 연결은 정해진 기능이나 공유된 자료만 볼 수 있다. 따라서 연결 이름만 보고 받은 편지함 전체나 모든 일정을 읽는다고 단정하지 않고 인증 화면과 실제 도구 목록을 확인한다. 연구책임자의 계정에는 심사 정보, 인사 관련 내용, 미공개 연구 내용, 학생의 개인 사정이 들어 있으므로 넓은 범위가 열렸다면 그 사실을 작업 경계에 반영해야 한다. 연결을 켜기 전에 첫째로 어떤 자료와 동작이 실제로 노출되는지를 기록한다. 둘째로 그중 무엇을 위키에 남겨도 되는지를 정한다. 읽을 수 있다는 것과 남겨도 된다는 것은 다르고 위키는 나중에 공유되거나 논문 초안 작성에 쓰일 수 있다. 조회는 원래 서비스의 상태를 바꾸지 않지만 조회된 정보의 공개와 모델 처리는 되돌릴 수 없으므로 조회 역시 안전을 보장하지 않는다. 외부 상태를 바꾸는 발송, 게시, 일정 변경은 별도의 승인 경계에 둔다.

내보내는 동작의 절차는 지침 파일에 적어 둔다. 메일의 경우 순서가 정해져 있다. 초안을 만들고 파일로 저장하고 사람에게 내용을 보여주고 기다리고 명시적인 승인을 받은 뒤에 발송한다. 답장해 달라거나 리마인드 해 달라는 말은 이 순서의 앞부분을 지시한 것이고 초안을 만들어 보여주고 기다리라는 뜻이다. 초안을 고쳤으면 고친 것을 다시 보여주고 새 승인을 받는데 고친 대목이 수신자거나 첨부거나 약속의 수위일 수 있어서 앞선 승인이 고친 초안에 적용되지 않기 때문이다. 같은 원칙이 일정과 팀 대화에도 적용된다. 남의 달력에 무언가를 넣거나 옮기는 일, 팀 채널에 메시지를 올리는 일은 되돌리는 비용을 상대가 함께 치른다. 읽기는 열어 두고 내보내기는 매번 확인받는 조합이 연구실 운영에서 실제로 쓸 만한 기본값이다.

메일과 일정

메일 연결에서 실제로 값이 큰 일은 답장을 대신 쓰는 것보다 무엇이 결정을 기다리고 있는지 찾아내는 것이다. 받은 편지함에는 읽고 넘길 것과 지금 판단해야 할 것이 섞여 있고 둘을 가르는 일에 매일 시간이 든다. 에이전트에게 시킬 수 있는 것은 지난 며칠의 메일에서 사람의 결정을 요구하는 것만 골라 목록으로 만들고 각 항목마다 무엇을 결정해야 하는지와 언제까지인지를 한 줄로 적게 하는 일이다. 이 목록은 위키에 남길 대상이 아니고 그날의 작업 목록이다. 목록에서 결정이 내려지면 그 결정만 소유 문서에 반영한다. 메일 본문을 위키에 옮기지 않는 이유가 여기서 분명해진다. 결정은 오래 살고 메일 본문은 그다음 답장에서 바뀐다.

달력 연결은 준비의 시점을 알려 주는 데 쓴다. 다음 주에 어떤 미팅이 있는지 알면 그 미팅에 필요한 자료가 무엇인지를 미리 정리할 수 있고 18장에서 본 대로 미팅 전에 자료가 건네지는지가 그 미팅의 결과를 가른다. 여기서 조심할 것은 일정 자체를 위키에 복사하지 않는 것이다. 일정은 자주 바뀌고 복사본은 바뀌지 않는다. 위키에 남기는 것은 그 미팅에서 무엇을 결정했고 다음 조건이 무엇인지이며 언제 어디서 만나는지는 달력이 소유한다. 일정을 만들거나 옮기는 동작은 열지 않는다. 참석자가 여럿인 일정을 옮기면 그 사람들 전부의 하루가 바뀌고 되돌리려면 다시 전부에게 알려야 한다.

팀 대화

메신저 연결은 연구실 운영에서 성격이 조금 다르다. 메일과 달리 대화가 흐르고 대부분의 메시지는 기록으로 남길 가치가 없으며 그중 일부만 결정이나 약속이다. 그래서 이 연결에서 하는 일은 읽어서 요약하는 것보다 골라내는 것이다. 어느 논의가 결론 없이 늘어지고 있는지, 어떤 요청이 답을 받지 못한 채 지나갔는지, 어느 채널에서 결정이 내려졌는데 그것이 어디에도 기록되지 않았는지를 찾는다. 세 가지 모두 사람이 매일 훑어서는 잘 보이지 않는다. 찾아낸 것 가운데 결정과 약속만 소유 문서로 옮기고 나머지는 그대로 둔다. 대화 전체를 위키로 가져오면 위키가 검색되는 대화 기록이 되고 1장에서 본 문제로 되돌아간다. 메시지를 올리는 동작은 사람이 확인한다. 27장과 28장에서 이 연결을 실제 운영에 붙이고 개인 작업 공간과 연구실 공간을 나눈다.

프로젝트 문서

팀이 함께 보는 문서 도구는 위키가 하지 못하는 일 하나를 한다. 접근권을 사람 단위로 나누는 일이다. 파일 시스템 위의 위키는 그 폴더를 가진 사람만 볼 수 있고 공동연구자에게 그중 일부만 보이게 하는 방법이 마땅치 않다. 프로젝트 문서 도구는 페이지마다 누가 볼 수 있는지를 정할 수 있으므로 밖으로 나가는 자료를 그쪽에 두고 안에서 쓰는 판단은 위키에 둔다. 두 층을 나누는 기준은 수명이다. 공유 페이지는 그 프로젝트가 끝나면 접근권과 함께 닫히고 지식 저장소는 그보다 오래 산다. 같은 논문을 두 곳에 올리게 되는 것처럼 보이지만 실제로 두 번 읽는 일은 없고 두 번 쓰는 일만 있다. 한 번은 몇 해 뒤에 다른 주제를 파는 사람을 위해 쓰고 한 번은 이번 분기에 결정을 내려야 하는 사람을 위해 쓴다. 25장이 이 연결을 프로젝트 관리에 실제로 붙이는 방법을 다룬다.

HWP 양식을 다루는 연결

국내 기관에 내는 서류는 대부분 HWP 파일로 온다. 연구비 신청서, 실적 보고서 각종 동의서와 확인서가 이 형식으로 배포되고 제출도 같은 형식으로 받는다. HWP 계열은 일반적인 문서 도구로 열리지 않고 .docx로 바꿔서 작업하면 표 구조와 서식이 무너져 반려된다. 그래서 이 형식을 직접 다루는 연결이 필요하다. 그 자리는 kordoc이 맡고 저장소가 공개되어 있다. 다루는 형식은 2020년 이후의 HWPX와 예전 이진 형식인 HWP 5.x, 그보다 오래된 HWP 3.x, 그리고 XML 기반의 HWPML까지이며 PDF와 표 계산 파일과 .docx도 함께 읽는다. 이 도구가 하는 일은 크게 셋이다. 문서를 읽어 구조가 살아 있는 형태로 바꾸는 일, 양식의 칸을 원래 서식을 유지한 채 채우는 일, 그리고 결과를 눈으로 확인할 수 있게 그려 주는 일이다.

세부 기능 가운데 실제 작업에서 값이 큰 것 몇 가지를 짚어 둔다. 표의 병합된 칸을 그대로 살려 읽는다는 점이 첫째인데, 행정 양식은 병합 칸이 많고 그것이 무너지면 어느 값이 어느 항목의 것인지 알 수 없게 된다. 둘째는 서식을 유지한 채 양식을 채우는 기능이다. 새로 만드는 것과 원래 문서를 열어 값만 넣는 것은 결과가 다르고 기관은 원본 서식을 바꾸면 반려한다. 셋째는 문서 두 개를 비교해 무엇이 달라졌는지 보여 주는 기능으로, 작업 사본이 원본과 어디가 달라졌는지 확인할 때 쓴다. 넷째는 결과를 그림으로 그려 주는 기능이다. 서명을 붙이거나 칸을 채운 뒤에 파일 구조만 검사하면 서명이 옆 칸의 글자를 덮었는지 알 수 없고 그려 봐야 알 수 있다. 스캔된 PDF에서 한국어 글자를 읽어 내는 기능과 개인정보를 가리는 기능도 함께 있다. 이 도구는 명령줄과 MCP 연결에서 모두 쓸 수 있다.

행정 문서를 다룰 때 지키는 경계는 두 가지다. 원본 양식은 덮어쓰지 않고 작업 사본을 따로 만들며 제출본은 이름으로 구분되게 둔다. 그리고 서명을 배치하는 일과 그 배치를 서명 행위로 인정하는 일을 나눈다. 배치는 도구가 하고 그 파일을 제출해도 되는지는 사람이 열어 보고 정한다. 29장이 이 절차를 서류 종류별로 다룬다.

따라해보기

아래 블록은 AI 도구의 채팅창에 그대로 붙여 넣는 프롬프트다. 연결을 켠 뒤에 처음 시킬 것은 읽기만 하는 요청이다. 무엇이 보이는지 확인한 다음에 범위를 정하는 편이 낫다.

지난 일주일의 메일 가운데 내 결정을 기다리는 것만 골라 달라.
각 항목마다 다음을 한 줄씩 적어 달라.
- 누가 무엇을 요청했는지
- 내가 결정해야 하는 것이 무엇인지
- 언제까지인지

메일 본문을 옮겨 적지 말고 답장 초안도 만들지 말아 달라.
목록만 보여 달라.

마지막 두 줄이 이 요청의 핵심이다. 초안을 만들지 말라고 적지 않으면 에이전트는 도움이 되려고 답장을 함께 만들어 오고 만들어진 초안이 있으면 읽어 보게 되고 읽다 보면 보내게 된다. 결정 목록을 보는 일과 답장을 쓰는 일은 다른 작업이고 섞으면 무엇을 결정할지 정하기 전에 답장의 문장을 다듬고 있게 된다.

확인하는 순서를 지침 파일에 적기

연결이 여러 개면 무엇부터 읽을지가 문제가 된다. 순서를 정해 두지 않으면 세션마다 다른 곳부터 읽고 그날 처음 읽은 자리의 정보가 답의 뼈대가 된다. 그래서 지침 파일에 확인 순서를 적어 둔다. 아침에 오늘 할 일을 물었을 때 무엇부터 보는지, 어떤 프로젝트의 상태를 물었을 때 어느 문서를 먼저 여는지를 정해 놓는 식이다. 순서를 정하는 기준은 소유다. 소유 문서를 먼저 읽고 그다음에 그 문서가 가리키는 원자료를 본다. 반대로 원자료부터 읽으면 지금까지 내린 판단을 모르는 상태에서 자료를 해석하게 되고 이미 결론이 난 것을 다시 논의하게 된다.

순서를 적어 두면 답의 형태도 안정된다. 같은 질문에 어제와 오늘의 답이 달라지는 원인은 흔히 읽은 순서에 있다. 순서가 고정되면 답이 달라졌을 때 그 차이가 자료의 변화에서 왔다고 볼 수 있다. 이 순서는 위키의 지침 파일과 한곳에 둔다. 연결마다 따로 적으면 새 연결을 켤 때마다 순서가 하나씩 늘어나고 늘어난 순서들이 서로 어긋난다.

연결을 고르고 검증하는 일

MCP 서버는 누구나 만들 수 있고 공개된 것이 많다. 연결을 켜면 그 서버가 에이전트와 외부 서비스 사이에서 자료나 동작을 중개하므로 무엇을 켤지는 보안 판단이 된다. 확인할 것은 배포자의 신원, 소스와 업데이트 경로, 요청하는 인증 범위, 서버가 호출하는 외부 주소, 보관 정책이다. 서비스를 만든 회사가 직접 배포했다는 사실은 배포자의 신원을 확인하기 쉽게 하지만 최소 권한이나 안전을 자동으로 보장하지는 않는다. 소스가 공개되어 있어도 실제 설치한 판본과 실행 중인 설정이 같은지 확인하지 않으면 충분한 검증이 되지 않는다. Codex가 지원하는 로컬 STDIO 서버는 컴퓨터에서 프로세스로 시작되고 원격 서버는 주소를 통해 접속한다. 이 구분만으로 자료가 컴퓨터 밖으로 나가는지를 판정할 수는 없다. 로컬 프로세스도 외부 API를 호출할 수 있고 도구의 결과는 에이전트가 판단할 수 있도록 클라이언트와 모델 처리 경로로 전달된다. 반대로 조직이 관리하는 원격 서버는 접근 범위와 보관 정책이 명시되어 있을 수 있다. 연구 자료와 학생 정보와 심사 정보를 다룰 때는 로컬이라는 이름 대신 실제 데이터 흐름과 적용되는 서비스 정책을 확인해야 한다.

연결을 켠 뒤에 무엇을 할 수 있는지도 실제로 확인해 두는 편이 낫다. 설명에 적힌 기능과 실제로 노출되는 동작이 다른 경우가 있고 읽기만 한다고 적혀 있는데 쓰기 동작이 함께 들어 있는 경우도 있다. 처음 켠 세션에서 그 연결이 제공하는 동작의 목록을 뽑아 보고, 그중 되돌릴 수 없는 것이 무엇인지 확인한다. 확인한 결과는 적어 둔다. 13장에서 지금 어떤 권한이 열려 있는지를 파일에 적어 두라고 한 것과 같은 이유이고 연결은 그보다 더 잊기 쉽다. 도구를 갱신하면 연결이 제공하는 동작이 늘어나는 경우가 있으므로 갱신 뒤에 한 번 다시 본다.

연결이 늘어날 때 생기는 문제

연결을 여러 개 켜면 같은 정보가 여러 곳에서 보이기 시작한다. 어떤 미팅은 메일에도 있고 달력에도 있고 팀 대화에도 있으며 세 곳의 내용이 조금씩 다르다. 누가 무엇을 소유하는지 정해 두지 않으면 에이전트가 세 곳을 다 읽고 그때그때 다른 답을 준다. 그래서 정보의 종류마다 소유하는 자리를 하나로 정한다. 일정의 시각은 달력이 소유하고 무엇을 하기로 했는지는 팀 문서나 위키가 소유하고 그 결정이 오간 경위는 메일이 소유한다. 소유 자리가 정해지면 확인하는 순서도 정해진다. 지침 파일에 그 순서를 적어 두면 다음 세션의 에이전트가 같은 순서로 확인한다. 순서가 없으면 세션마다 다른 곳부터 읽고 다른 곳부터 읽으면 다른 답이 나온다.

두 번째 문제는 연결이 실제로 살아 있는지가 조용히 달라진다는 것이다. 인증이 만료되거나 도구의 판이 올라가면서 연결이 끊기면, 에이전트는 그곳을 읽지 못한 채로 답을 만든다. 읽지 못했다는 사실이 답에 나타나지 않으면 사람은 그 답을 전체를 본 결과로 읽는다. 그래서 확인하지 못한 것을 이상 없음으로 적지 않는다는 규칙이 여기에도 적용된다. 어느 자리를 읽었고 어느 자리를 읽지 못했는지를 답에 함께 적게 한다. 세 번째는 권한이 넓어지는 방향으로만 움직인다는 것이다. 한 번 열어 준 범위는 좁히기 번거로워서 그대로 남고 몇 달이 지나면 처음에 정한 경계가 무엇이었는지 기억나지 않는다. 지금 어떤 연결이 켜져 있고 각각이 무엇을 할 수 있는지를 목록으로 적어 두고 주기적으로 실제 설정과 대조한다. 27장에서 예약 작업 목록을 같은 방식으로 관리하는데 이유도 같다.

네 번째는 비용이다. 연결마다 요금 체계가 다르고 어떤 것은 계정 자체가 유료이며 어떤 것은 무료 등급에서 조회 횟수가 제한된다. 연구실 규모에서는 큰 금액이 아니지만 자동화를 붙여 매일 돌리기 시작하면 사람이 쓰던 것과 다른 규모로 호출이 일어난다. 예약 작업이 매일 아침 여러 연결을 훑는 구성이라면 그 횟수를 한 번 세어 보고 시작하는 편이 낫다. 교육 기관 할인이 있는 서비스도 있어서 실제 부담이 크게 줄어드는 경우가 있다. 요금과 등급은 공급자의 현재 안내에서 확인하고 자동화를 켜기 전에는 예상 호출 횟수를 세어 본다.