이제부터는 구경이 아니라 실전이다
앞 장에서 MCP를 호스트에 붙였다면, 이번 장에서는 진짜로 일을 시켜볼 차례다. 여기서부터 분위기가 달라진다. 전까지는 AI가 똑똑한 설명가처럼 느껴졌다면, 이제는 서류를 찾고, 코드를 읽고, 기록을 정리하고, 숫자까지 뽑아오는 조수처럼 보이기 시작한다.
특히 이 장이 중요한 이유는 하나다. 많은 사람이 이 지점에서 처음으로 AI가 진짜 일을 한다는 감각을 얻기 때문이다. 단순히 답변을 길게 잘하는 것이 아니라, 내 파일을 읽고, 외부 정보를 확인하고, GitHub 상태를 살피고, 데이터베이스에서 근거를 가져와 말하기 시작한다. 말 잘하는 비서가 아니라, 손발이 달린 팀원이 되는 순간이다.
이번 장에서는 가장 많이 쓰는 네 가지를 실습한다. 파일, 검색, GitHub, 데이터베이스다. 설치법 자체는 앞 장에서 익혔으니, 여기서는 무엇을 시키면 좋고 어떤 식으로 요청해야 결과가 안정적인지에 집중하자.
실습 전에 준비할 마음가짐
처음 MCP를 쓸 때 제일 흔한 실수는 욕심이다. 파일도 읽히고, 웹도 뒤지고, 깃허브도 쓰게 하고, 데이터베이스도 건드리게 한 뒤 한 번에 거대한 일을 시키면 멋져 보인다. 대신 어디서 틀렸는지 찾기 어렵다.
그래서 첫 실습은 항상 작게 시작하는 편이 좋다. 파일 서버는 테스트 폴더만 열고, GitHub는 실험용 저장소나 최소 권한 토큰을 쓰고, 데이터베이스는 읽기 전용 계정을 쓰는 식이다. 처음 만난 새 팀원에게 회사 금고 비밀번호까지 바로 알려주지는 않는 것과 같다.
질문도 작고 구체적일수록 좋다. 이 프로젝트 분석해줘보다 README와 package.json을 읽고 실행 방법만 세 문장으로 정리해줘가 훨씬 잘 된다. MCP는 만능 지팡이가 아니라, 잘 연결된 도구 상자에 가깝다. 도구는 연결해 주지만, 일을 명확하게 나누는 것은 여전히 사용자의 몫이다.
실습 1: 파일 서버로 내 폴더를 읽게 하기
파일 시스템 MCP 서버는 가장 단순하고, 그래서 가장 강력한 입문 도구다. 이유는 간단하다. 결과가 눈에 보인다. AI가 무언가를 읽었는지, 못 읽었는지 바로 확인된다.
예를 들어 프로젝트 폴더 하나만 열어 두고 이렇게 시켜볼 수 있다.
이 폴더에서 중요한 파일들을 찾아서 역할을 한 줄씩 설명해줘.잘 연결되어 있다면 AI는 보통 README, package.json, src 폴더, 설정 파일 같은 것들을 먼저 읽고 구조를 설명한다. 여기서 좋은 점은 사용자가 폴더를 일일이 뒤질 필요가 없다는 것이다. 처음 보는 저장소를 열었을 때 특히 빛난다. 누가 이사 오자마자 집 구조를 정리해 주는 느낌이다.
다음 단계로는 조금 더 실무적인 일을 맡겨보자.
README.md를 읽고, 처음 실행하는 사람 기준으로 필요한 준비 과정을 체크리스트로 정리해줘.이 요청은 단순 요약보다 훨씬 유용하다. 문서를 사람 대신 읽고, 실행 순서로 다시 배열해 주기 때문이다. 초보자는 긴 문서보다 정리된 순서를 더 잘 따라간다. AI가 여기서 하는 일은 번역이 아니라 재구성이다.
파일 서버가 특히 빛나는 순간은 여러 문서를 엮을 때다. 예를 들어 회의록 폴더가 있다고 하자. 이때는 이런 요청이 좋다.
이번 달 회의록 파일들을 읽고 반복해서 등장한 이슈 세 가지만 뽑아줘.이제 AI는 파일 하나를 읽는 수준을 넘어, 여러 문서를 비교하고 공통점을 정리한다. 사람이 하면 은근히 귀찮은 일인데, AI는 이런 반복 작업에 꽤 강하다.
파일 서버를 쓸 때 기억할 점도 있다.
너무 넓은 폴더를 열지 말 것
읽기와 쓰기를 처음부터 동시에 허용하지 말 것
생성된 파일은 꼭 사람이 한 번 확인할 것
특히 파일 쓰기까지 허용하면 편리함이 확 올라간다. 예를 들어 요약 결과를 바로 저장하게 할 수 있다.
방금 정리한 내용을 docs/summary.md 파일로 저장해줘.이 한 줄에서 많은 사람이 놀란다. 전에는 AI가 텍스트를 뱉고 끝났다면, 이제는 실제 결과물을 파일로 남기기 때문이다. 바로 이때, AI가 채팅창 밖으로 나온 느낌이 든다.
실습 2: 검색 서버로 외부 정보를 확인하게 하기
파일 서버가 내 방 서랍을 뒤지는 능력이라면, 검색 서버는 도서관 사서 같은 능력이다. 모르는 것을 밖에서 찾아오고, 필요한 것만 요약해 준다.
검색 계열 MCP 서버는 크게 두 가지 감각으로 이해하면 편하다. 하나는 웹 검색형이고, 다른 하나는 특정 URL 내용을 가져오는 가져오기형이다. 검색형은 어디에 정보가 있는지 찾는 데 강하고, 가져오기형은 이미 알고 있는 문서나 페이지를 읽는 데 강하다.
예를 들어 문서를 빠르게 찾아야 할 때는 이렇게 시킬 수 있다.
FastAPI에서 background task를 설명하는 공식 문서를 찾아 핵심만 요약해줘.이 요청이 좋은 이유는 범위가 좁기 때문이다. AI에게 세상 모든 글을 다 읽으라고 하는 대신, 공식 문서를 찾고 핵심만 말하라고 시키는 셈이다. 이러면 잡음이 줄어든다.
이미 URL을 알고 있다면 더 정확해진다.
이 문서를 읽고 우리 팀 초보자에게 필요한 내용만 남겨서 설명해줘.여기서 재미있는 점은, AI가 단순 복붙 기계가 아니라는 것이다. 긴 문서를 읽고도 대상에 맞춰 다시 풀어낼 수 있다. 원문은 개발자용인데, 요약은 초보자용으로 바뀐다. 같은 책을 읽고도 어린이판으로 다시 써 주는 느낌에 가깝다.
검색 서버를 실무에서 유용하게 쓰는 장면도 많다.
공식 문서에서 특정 기능의 사용 예 찾기
여러 기사나 블로그를 읽고 공통 내용만 추리기
제품 비교 자료를 읽고 차이점 표로 정리하기
다만 검색 결과는 늘 정답이 아니다. 최신성이나 출처 품질을 확인해야 한다. 그래서 좋은 질문은 찾아줘에서 끝나지 않고 근거가 되는 링크와 함께 요약해줘까지 간다. MCP가 외부 정보를 가져와도, 최종 판단은 여전히 사람의 영역이다.
실습 3: GitHub 서버로 코드 저장소를 실제로 다루기
GitHub MCP는 개발자에게 가장 강한 체감 변화를 주는 서버 중 하나다. 왜냐하면 GitHub는 단순한 저장 공간이 아니라, 코드, 이슈, PR, 리뷰, 협업 기록이 한데 모여 있는 곳이기 때문이다. 즉, 프로젝트의 현재 상태가 담긴 무대 뒤편이다.
처음에는 읽기 작업부터 시작하는 편이 좋다. 예를 들어 이런 요청이 안전하고 유용하다.
이 저장소의 열린 이슈를 보고 가장 먼저 처리해야 할 것 세 개를 이유와 함께 정리해줘.이 요청에서 AI는 단순 목록 나열이 아니라, 우선순위 판단까지 도와준다. 물론 그 판단이 항상 옳지는 않지만, 사람이 처음 정리하는 수고를 크게 줄여 준다.
다음으로 많이 쓰는 것이 코드 검색이다.
이 저장소에서 console.log가 남아 있는 파일을 찾아줘.이건 아주 작고 현실적인 업무다. 그런데 자주 필요하다. 릴리스 전에 디버그 로그를 정리하거나, 특정 함수 호출 위치를 찾을 때 특히 유용하다. 예전에는 저장소를 열고 검색창을 두드리며 하나씩 확인했다면, 이제는 자연어로 바로 지시할 수 있다.
조금 더 적극적인 작업도 가능하다.
PR 52의 변경 파일을 읽고 잠재적인 버그 가능성이 있는 부분을 리뷰 코멘트 초안으로 정리해줘.이 단계부터는 정말로 개발 보조 느낌이 강해진다. AI가 변경 내용을 읽고, 위험한 부분을 먼저 짚어주기 때문이다. 물론 최종 리뷰는 사람이 해야 한다. 하지만 첫 번째 거름망 역할은 꽤 잘한다.
GitHub 서버가 주는 가장 큰 체감은 연속 작업이다. 예를 들어 이슈를 읽고, 관련 파일을 찾고, 수정 방향을 제안하고, PR 본문 초안까지 만드는 흐름을 한 대화 안에서 이어갈 수 있다. 각각은 작은 일인데, 이어 붙이면 꽤 커다란 업무 흐름이 된다.
다만 GitHub 서버는 권한 관리가 정말 중요하다. 읽기만 할지, 이슈를 쓸지, PR을 만들지에 따라 필요한 권한이 달라진다. 처음에는 읽기 중심으로 시작하고, 쓰기 작업은 꼭 필요한 범위로만 여는 것이 좋다. AI에게도 연습용 열쇠부터 쥐여 주는 편이 안전하다.
실습 4: 데이터베이스 서버로 숫자와 사실을 가져오기
데이터베이스 MCP는 처음엔 조금 무섭게 느껴진다. 잘못 건드리면 큰일 날 것 같기 때문이다. 그 감각은 아주 건강하다. 그래서 더욱 읽기 전용 계정으로 시작해야 한다.
데이터베이스 서버의 첫 질문은 대개 스키마부터 시작하는 편이 좋다. 스키마는 데이터의 구조다. 쉽게 말해 어떤 표가 있고, 열이 무엇인지 보는 일이다.
이 데이터베이스에서 사용자 관련 테이블이 무엇이 있는지 구조부터 설명해줘.이렇게 시작하면 AI가 먼저 테이블 구조를 파악한 뒤, 어디를 어떻게 조회해야 할지 감을 잡는다. 구조도 모르고 바로 매출 합계를 구하라고 시키는 것은, 창고 지도를 안 보고 물건부터 찾으라는 것과 비슷하다.
그다음에는 자연어로 조회를 부탁할 수 있다.
지난 30일 동안 가입한 사용자 수를 날짜별로 정리해줘.이 요청이 좋은 이유는 사람이 SQL을 직접 쓰지 않아도 된다는 점이다. 물론 내부적으로는 서버가 적절한 쿼리를 실행하겠지만, 사용자 입장에서는 질문을 업무 언어로 할 수 있다. 개발자가 아닌 팀원에게 특히 큰 장점이다.
또 다른 실용 예시는 이상 징후 찾기다.
최근 7일 주문 데이터에서 평소보다 급격히 감소한 날이 있으면 알려줘.이런 요청은 단순 조회보다 분석에 가깝다. 숫자를 가져오는 데서 끝나지 않고, 패턴을 읽어내기 때문이다. 사람이 엑셀로 해도 되지만, AI가 초안을 만들어 주면 훨씬 빠르다.
데이터베이스 서버를 쓸 때 꼭 지켜야 할 습관도 있다.
처음에는 읽기 전용 계정 사용
스키마 파악 후 질문하기
큰 범위 조회보다 기간과 조건을 좁혀서 요청하기
특히 전체 데이터 보여줘 같은 요청은 좋지 않다. 느리고, 비싸고, 쓸모없는 경우가 많다. 좋은 질문은 보통 기간, 대상, 기준이 들어 있다. 예를 들면 이번 주, 활성 사용자, 결제 실패 같은 식이다.
네 가지를 연결하면 일이 흐른다
진짜 재미는 여기서부터다. 파일, 검색, GitHub, 데이터베이스를 따로 쓰는 것도 좋지만, 연결하면 업무 흐름이 만들어진다. MCP의 진짜 매력은 바로 이 연결성에 있다.
예를 들어 이런 흐름을 상상해 보자. 먼저 데이터베이스에서 최근 결제 실패율을 확인한다. 그다음 GitHub에서 결제 모듈 관련 최근 PR을 읽는다. 필요한 경우 검색 서버로 외부 문서를 확인한다. 마지막으로 파일 서버를 통해 조사 결과를 보고서로 저장한다.
이건 더 이상 단일 질문이 아니다. 작은 작업들이 이어진 하나의 워크플로다. 사람으로 치면 분석가, 개발자, 문서 작성자가 차례로 움직인 셈인데, MCP를 붙인 AI는 그 사이를 꽤 자연스럽게 이어 간다.
예시로는 이런 요청이 가능하다.
최근 2주 결제 실패율을 확인하고, 같은 기간 결제 관련 PR이나 이슈가 있었는지 GitHub에서 찾아서 원인 후보를 정리해줘. 마지막으로 결과를 payment-investigation.md에 저장해줘.이 한 문장에는 조회, 검색, 정리, 저장이 모두 들어 있다. 바로 이때 사용자는 강하게 느낀다. 아, 이건 챗봇이 아니라 작업기구구나.
잘 되는 질문과 잘 안 되는 질문의 차이
MCP를 잘 쓰는 사람은 대단한 비밀 주문을 외우지 않는다. 대신 질문을 조금 더 일하는 말투로 바꾼다.
잘 안 되는 질문은 보통 너무 넓다.
우리 서비스 문제점 좀 찾아봐.이건 너무 막연하다. 어디를 봐야 하는지, 무엇이 문제인지, 어떤 근거로 판단해야 하는지가 없다. 반면 잘 되는 질문은 범위와 산출물이 분명하다.
지난 7일 결제 실패 로그를 기준으로 가장 자주 발생한 오류 세 가지를 찾고, 관련 코드 위치가 GitHub에 있으면 함께 정리해줘.이 질문에는 기간, 대상, 개수, 후속 행동이 들어 있다. AI가 도구를 선택하기도 쉬워진다. 사용자가 일을 잘게 나누어 지시하면, MCP의 강점이 훨씬 잘 살아난다.
좋은 요청을 만드는 요령은 세 가지다.
범위를 줄인다
기대하는 결과 형식을 말한다
가능하면 근거도 함께 요구한다
예를 들어 표로 정리해줘, 파일로 저장해줘, 근거가 된 이슈 번호도 붙여줘 같은 표현이 도움이 된다. AI는 추상적인 칭찬보다 구체적인 요구사항을 더 잘 따른다.
처음 실무에 써볼 만한 미니 과제
이번 장을 읽고 바로 해볼 수 있는 간단한 과제를 하나 소개하겠다. 파일 서버, GitHub 서버, 검색 서버가 있으면 충분하다.
먼저 프로젝트 README를 읽게 한다. 다음으로 열린 이슈 중 초보자가 이해하기 어려운 것 하나를 고르게 한다. 그리고 필요한 외부 문서를 찾아 배경지식을 보완하게 한다. 마지막으로 onboarding-note.md 같은 파일로 저장하게 한다.
즉, 흐름은 이렇다.
프로젝트 소개 읽기
현재 이슈 이해하기
관련 외부 문서 보강하기
초보자용 안내문으로 저장하기
이 과제가 좋은 이유는 실무에서 정말 자주 필요한 일이기 때문이다. 새 팀원이 들어왔을 때, 프로젝트를 파악하고, 현재 이슈를 이해하고, 필요한 배경지식을 찾는 과정은 늘 반복된다. MCP를 쓰면 이 반복 노동이 꽤 부드럽게 줄어든다.
사용자가 느끼는 진짜 변화
이 장을 지나면 사용자의 시선이 조금 바뀐다. 예전에는 AI에게 설명을 부탁했다면, 이제는 준비 작업을 맡기기 시작한다. 문서를 읽게 하고, 자료를 찾게 하고, 코드를 검색하게 하고, 숫자를 정리하게 한다. 그러다 어느 순간, 사람은 판단과 승인에 집중하고 AI는 탐색과 초안 작성에 집중하는 구조가 생긴다.
이게 바로 MCP의 첫 번째 큰 선물이다. AI를 더 똑똑하게 만드는 것이 아니라, 내 환경과 연결해서 더 쓸모 있게 만드는 것이다.
특히 파일, 검색, GitHub, 데이터베이스 네 가지는 그 출발점으로 아주 좋다. 하나는 내 자료, 하나는 바깥 지식, 하나는 개발 협업, 하나는 사실 데이터다. 이 네 가지가 연결되면 AI는 제법 현실적인 업무 파트너처럼 움직인다.
이 장의 핵심 정리
이번 장에서 꼭 가져가야 할 감각은 복잡하지 않다.
첫째, 파일 서버는 가장 쉬운 입문용이자 가장 자주 쓰는 실무 도구다. 둘째, 검색 서버는 외부 지식을 끌어와 판단의 재료를 만든다. 셋째, GitHub 서버는 코드와 협업 기록을 실제로 다루게 해 준다. 넷째, 데이터베이스 서버는 말이 아니라 숫자와 사실을 근거로 가져오게 만든다.
그리고 가장 중요한 다섯째, MCP의 진짜 힘은 한 서버의 성능이 아니라 여러 서버를 엮어 하나의 업무 흐름을 만드는 데 있다.
이제 당신은 단순히 MCP를 연결한 사람이 아니다. 실제로 일을 시켜본 사람이다. 다음 장에서는 여기서 한 걸음 더 나아가, MCP를 잘 쓰는 사람들은 어떤 질문을 하고 어떤 권한 감각과 워크플로 감각을 갖추는지 살펴보자.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.