MCP를 잘 쓰는 사람의 습관: 질문법, 권한 관리, 워크플로 설계

MCP를 잘 쓰는 사람의 습관: 질문법, 권한 관리, 워크플로 설계

MCP를 처음 연결했을 때의 기분은 대체로 비슷합니다. "오, 이제 AI가 진짜 일을 하겠는데?" 실제로 맞는 말입니다. 파일도 읽고, 검색도 하고, GitHub도 보고, 데이터베이스도 만질 수 있으니까요. 그런데 여기서 많은 사람이 한 번 더 놀랍니다. 붙였다고 끝이 아니라는 것입니다.

같은 MCP를 연결해도 어떤 사람에게는 AI가 '똑똑한 비서'처럼 움직이고, 어떤 사람에게는 '눈치 없는 인턴'처럼 굴기도 합니다. 차이는 모델의 지능보다, 쓰는 사람의 습관에서 더 크게 벌어집니다.

MCP는 도구를 붙여 주지만, 일을 잘 굴러가게 만드는 것은 결국 사람의 설계입니다. 무엇을 먼저 하게 할지, 어디까지 허용할지, 결과를 어떤 형태로 받을지 정해야 합니다. 이 장에서는 바로 그 차이를 만드는 세 가지를 다룹니다. 질문법, 권한 관리, 그리고 반복 가능한 워크플로 설계입니다.

왜 습관이 성능을 바꿀까

MCP를 연결한 AI는 갑자기 손이 많아진 상태와 비슷합니다. 검색도 할 수 있고, 문서도 읽을 수 있고, 외부 시스템과도 상호작용할 수 있습니다. 하지만 손이 많다고 일을 잘하는 건 아닙니다. 오히려 아무 지시 없이 손만 많아지면 여기저기 건드리다가 어수선해지기 쉽습니다.

사람에게도 비슷한 일이 벌어집니다. 회사에서 누군가에게 "알아서 정리해 주세요"라고 말하면, 운이 좋으면 깔끔하게 끝나지만 운이 나쁘면 정리 기준이 달라져서 더 복잡해집니다. MCP를 쓰는 AI도 마찬가지입니다. 목표, 범위, 금지선, 출력 형식이 분명할수록 잘 움직입니다.

즉, MCP를 잘 쓰는 사람은 단순히 서버를 많이 연결한 사람이 아닙니다. 연결된 능력을 안정적으로 꺼내 쓰는 사람입니다.

질문법의 핵심: 대화가 아니라 업무 지시처럼 말하기

MCP를 잘 쓰는 사람은 AI에게 말을 걸 때 친절하면서도 분명합니다. 막연한 부탁보다, 바로 행동으로 옮길 수 있는 지시를 줍니다.

좋은 요청에는 대체로 다섯 가지가 들어갑니다.

• 목표: 무엇을 끝내고 싶은가

• 범위: 어디까지 볼 것인가, 무엇은 건드리면 안 되는가

• 입력 맥락: 어떤 폴더, 어떤 저장소, 어떤 기간을 다루는가

• 출력 형식: 표, 요약, 초안, 체크리스트 중 무엇이 필요한가

• 성공 기준: 어떤 상태가 되면 잘된 것인가

예를 들어, 이런 요청은 애매합니다.

GitHub 좀 정리해줘.

이 말에는 질문을 던진 사람의 머릿속 계획은 들어 있지만, AI가 실행할 수 있는 정보는 거의 없습니다. 이슈를 정리하라는 건지, PR을 보라는 건지, README를 고치라는 건지 알 수 없습니다.

반면 아래 요청은 훨씬 낫습니다.

지난 7일 동안 열린 GitHub 이슈를 읽기 전용으로 확인해줘.
버그, 문서, 기능 요청으로 분류해서 표로 정리하고,
중복 가능성이 높은 항목은 따로 표시해줘.
아직 어떤 변경도 하지 말고 요약만 보여줘.

이 요청은 목표도 있고, 범위도 있고, 결과 형식도 있습니다. 무엇보다 중요한 건 아직 변경하지 말라는 선이 분명하다는 점입니다. 이 한 줄이 괜한 사고를 많이 막아줍니다.

좋은 질문은 한 번에 많이 시키지 않는다

초보 사용자가 자주 하는 실수는 한 문장에 너무 많은 일을 넣는 것입니다.

문서 찾아서 요약하고, 이상한 부분은 수정하고, 팀 채널에도 올려줘.

이 문장은 사람에게도 부담스럽고, AI에게도 부담스럽습니다. 찾기, 읽기, 판단, 수정, 전송이 한꺼번에 들어 있습니다. 단계가 섞이면 실수도 같이 섞입니다.

MCP를 잘 쓰는 사람은 일을 보통 세 덩어리로 나눕니다.

첫째는 탐색입니다. 무엇이 있는지 보고, 관련 자료를 모읍니다.

관련 문서와 파일만 찾아서 핵심 내용을 요약해줘. 수정은 하지 마.

둘째는 계획입니다. 무엇을 바꾸면 좋을지 제안받습니다.

수정이 필요해 보이는 부분을 3개만 뽑고,
왜 수정이 필요한지와 예상 영향을 설명해줘.

셋째는 실행입니다. 승인된 것만 실제로 반영하게 합니다.

방금 제안한 항목 중 내가 승인한 2개만 수정하고,
무엇이 바뀌었는지 마지막에 diff 형식으로 요약해줘.

이 흐름은 단순하지만 강력합니다. MCP를 단발성 장난감이 아니라, 실제 업무 도구로 쓰게 만들어 주기 때문입니다.

질문할 때 특히 잘 먹히는 표현들

MCP를 쓰는 AI는 생각보다 이런 표현에 아주 잘 반응합니다.

• 먼저 조사만 해줘

• 읽기 전용으로 확인해줘

• 실행 전에 계획부터 보여줘

• 내가 승인하면 그때 변경해줘

• 결과를 표로 정리해줘

• 변경 내용만 요약해줘

• 위험한 작업은 따로 표시해줘

이 표현들은 단순한 예의가 아니라, 작업을 안전한 순서로 묶는 신호입니다. AI가 멋대로 돌진하지 않도록 속도 제한 표지판을 세우는 셈입니다.

반대로 위험한 표현도 있습니다.

• 알아서 해줘

• 전부 정리해줘

• 필요하면 수정해줘

• 다 끝내고 보고해줘

이 표현들은 자유도가 너무 높습니다. 사람에겐 시원한 말처럼 들릴 수 있지만, AI에게는 빈칸이 너무 많은 시험지입니다. 빈칸이 많으면 추측이 늘고, 추측이 늘면 실수가 생깁니다.

권한 관리는 귀찮음이 아니라 실력이다

MCP를 쓰다 보면 권한 허용 창이 자주 나타납니다. 처음에는 성가시게 느껴질 수 있습니다. 하지만 이 귀찮음은 여러분의 파일, 코드, 데이터, 심지어 회사 시스템을 지키는 안전장치입니다.

좋은 사용자는 권한을 한 번에 크게 열지 않습니다. 꼭 필요한 만큼만, 필요한 순간에만 엽니다. 이게 바로 최소 권한 원칙입니다. 말이 조금 딱딱하지만 뜻은 단순합니다. 필요한 열쇠만 잠깐 빌려주라는 뜻입니다.

예를 들어 파일 시스템 MCP를 붙였다고 해서 곧바로 전체 디스크 접근 권한을 줄 필요는 없습니다. 작업 폴더만 허용해도 충분한 경우가 많습니다. GitHub MCP를 쓴다고 해서 곧바로 쓰기 권한까지 줄 필요도 없습니다. 먼저 읽기 권한으로 이슈와 PR을 살펴보는 것만으로도 할 수 있는 일이 많습니다.

권한은 보통 세 층으로 생각하면 이해하기 쉽습니다.

• 읽기 권한: 보기, 검색, 조회

• 쓰기 권한: 수정, 생성, 상태 변경

• 위험 권한: 삭제, 배포, 외부 발송, 운영 반영

MCP를 잘 쓰는 사람은 거의 항상 읽기부터 시작합니다. 그리고 정말 필요할 때만 쓰기로 올라갑니다. 삭제나 운영 배포처럼 되돌리기 어려운 작업은 한 단계 더 신중하게 다룹니다.

읽기와 쓰기를 분리하면 사고가 줄어든다

많은 실수는 기술이 부족해서가 아니라, 읽기 작업과 쓰기 작업을 같은 흐름에 섞어서 생깁니다.

예를 들어 이런 식입니다.

프로젝트 문서를 확인하고 낡은 내용은 최신 상태로 바꿔줘.

겉으로는 자연스럽지만, 실제로는 꽤 위험합니다. 확인과 변경이 한 문장에 붙어 있기 때문입니다. 무엇이 낡았는지 판단하는 기준이 모호하면 AI는 지나치게 적극적으로 수정할 수 있습니다.

더 안전한 방식은 이렇게 나누는 것입니다.

1단계: 프로젝트 문서를 읽고 낡았을 가능성이 있는 내용을 표시해줘.
2단계: 수정 제안을 항목별로 작성해줘.
3단계: 내가 승인한 항목만 반영해줘.

이 습관 하나만으로도 MCP는 훨씬 믿을 만한 동료가 됩니다.

테스트 환경은 선택이 아니라 필수다

MCP를 잘 쓰는 사람은 운영 환경에서 용감하지 않습니다. 오히려 겁이 많습니다. 그리고 그 겁이 실력을 만듭니다.

처음 붙인 데이터베이스, 처음 시도하는 자동화, 처음 만드는 브랜치 정리 작업은 테스트 환경에서 먼저 돌려봐야 합니다. 샘플 폴더, 복제된 데이터, 실험용 브랜치, 개발용 워크스페이스가 필요한 이유가 여기에 있습니다.

운영 환경은 실수의 비용이 큽니다. 반면 테스트 환경은 실수의 비용이 학습비 정도로 끝납니다. MCP는 빠르게 시도하고 빠르게 바꾸기 좋은 도구이기 때문에, 더더욱 테스트 공간이 중요합니다.

특히 다음 작업은 테스트를 먼저 거치는 편이 좋습니다.

• 대량 파일 이동 또는 이름 변경

• 데이터베이스 UPDATE, DELETE

• PR 자동 생성이나 자동 병합

• 슬랙, 이메일, 외부 시스템 발송

• 문서 일괄 수정

한 번에 많이 바꾸는 작업일수록, 테스트의 가치는 기하급수적으로 커집니다.

결과를 꼭 보고받는 습관

권한을 잘 관리하는 사람은 실행 자체보다 실행 후 보고를 중요하게 생각합니다. AI가 무엇을 했는지 모르면, 잘됐는지 나빴는지 판단할 수 없기 때문입니다.

그래서 MCP를 잘 쓰는 사람은 요청 끝에 이런 문장을 자주 붙입니다.

• 마지막에 변경 사항만 요약해줘

• 어떤 파일을 건드렸는지 목록으로 보여줘

• 실행한 쿼리와 영향 범위를 설명해줘

• 삭제하거나 수정한 항목 수를 알려줘

• 확신이 낮았던 부분은 따로 표시해줘

이 보고 습관은 단순히 보기 좋으라고 있는 것이 아닙니다. 재현 가능성을 높이기 위해서입니다. 나중에 같은 작업을 다시 할 때도 큰 도움이 됩니다.

워크플로 설계: 잘 쓰는 사람은 흐름을 만든다

MCP를 단순 연결로만 쓰면, 매번 비슷한 요청을 매번 새로 해야 합니다. 이때부터 귀찮음이 쌓입니다. 반면 잘 쓰는 사람은 자주 하는 일을 흐름으로 만듭니다. 즉, 워크플로를 설계합니다.

워크플로란 거창한 자동화 시스템만 뜻하는 게 아닙니다. 반복되는 일을 일정한 순서로 실행하도록 만든 습관도 훌륭한 워크플로입니다.

예를 들어 매일 아침 하는 일이 이렇다고 해봅시다.

1. GitHub 이슈 확인

2. 우선순위 분류

3. 관련 문서 읽기

4. 오늘 할 일 초안 만들기

5. 슬랙에 공유

이 과정을 매일 말로 다시 설명하면 피곤합니다. 대신 작업 흐름을 정해두면 됩니다. 잘 쓰는 사람은 AI에게 단순 명령이 아니라 반복 가능한 절차를 가르칩니다.

가장 실용적인 기본 워크플로: 조사 → 계획 → 실행 → 검토

MCP 활용에서 가장 무난하고 강력한 흐름은 네 단계입니다.

조사

먼저 자료를 모으고 상태를 파악합니다. 이 단계에서는 읽기 전용이 기본입니다.

프로젝트 루트에서 배포 설정 파일과 최근 변경된 문서를 찾아서,
현재 배포 흐름을 이해하는 데 필요한 핵심만 요약해줘.
아직 수정은 하지 마.

계획

다음으로 무엇을 바꿔야 할지, 어떤 순서가 좋은지 제안받습니다.

문제 원인을 추정하고,
가장 가능성 높은 수정안 2개를 장단점과 함께 제시해줘.

실행

승인된 범위만 실제로 반영합니다.

첫 번째 수정안만 적용해줘.
나머지는 건드리지 말고, 변경 파일을 알려줘.

검토

무엇이 바뀌었고, 아직 남은 위험이 무엇인지 확인합니다.

이번 변경의 영향 범위를 요약하고,
추가로 확인해야 할 테스트 항목을 체크리스트로 정리해줘.

이 네 단계는 개발, 문서 정리, 데이터 분석, 업무 자동화 어디에나 잘 들어맞습니다. 흐름이 단순해서 기억하기 쉽고, 안전장치도 많습니다.

도구를 많이 붙인다고 좋은 워크플로가 되지는 않는다

MCP를 배우다 보면 도구 수집 욕심이 생깁니다. 파일 시스템, 브라우저, GitHub, 노션, 슬랙, DB, 캘린더, 검색, 자동화 플랫폼까지 다 붙여 보고 싶어집니다. 물론 재밌습니다. 문제는, 도구가 많아질수록 AI가 선택해야 할 가지 수가 늘어난다는 점입니다.

도구가 너무 많으면 AI가 괜히 멋을 부립니다. 검색만 하면 될 일을 브라우저까지 열고, 읽기만 하면 될 일을 문서 수정까지 시도할 수 있습니다. 그래서 잘 쓰는 사람은 모든 도구를 항상 다 열어두지 않습니다. 그날의 작업에 필요한 도구만 가까이 둡니다.

예를 들어 문서 정리 세션이라면 파일 시스템과 검색 정도면 충분할 수 있습니다. 개발 디버깅이라면 파일 시스템, GitHub, 브라우저 테스트 도구 정도가 핵심일 수 있습니다. 회의 준비라면 캘린더, 문서, 메신저가 더 중요합니다.

즉, 좋은 워크플로는 도구 백화점이 아니라, 상황별 공구함에 가깝습니다.

자주 쓰는 사용자 관점 워크플로 예시

아침 업무 정리 워크플로

하루를 시작할 때 가장 유용한 흐름입니다.

• GitHub 이슈와 PR 요약

• 슬랙 또는 메신저에서 중요한 메시지 정리

• 캘린더 일정 확인

• 오늘 할 일 초안 작성

예시 요청은 이렇게 만들 수 있습니다.

오늘 아침 업무 브리핑을 만들어줘.
GitHub의 내 관련 PR과 이슈를 요약하고,
오늘 일정과 겹치는 급한 항목이 있으면 표시해줘.
마지막에는 오늘 할 일 5개를 우선순위 순으로 정리해줘.
수정이나 발송은 하지 마.

문서 업데이트 워크플로

문서 관리에서 특히 강력합니다.

• 관련 문서 탐색

• 최신 정보와 불일치 항목 표시

• 수정 제안 작성

• 승인 후 반영

예시 요청은 이렇습니다.

온보딩 문서를 읽고,
현재 프로젝트 구조와 맞지 않을 가능성이 있는 내용을 찾아줘.
수정 제안을 먼저 작성한 뒤,
내가 승인하면 문서를 고쳐줘.

버그 조사 워크플로

코드, 로그, 이슈를 연결해서 보는 흐름입니다.

• 오류 재현 정보 수집

• 관련 코드와 최근 변경 사항 확인

• 원인 후보 정리

• 수정안 제안

• 승인 후 수정

예시 요청은 이렇습니다.

로그인 오류 관련 이슈와 최근 커밋을 읽고,
가능한 원인 3개를 우선순위로 정리해줘.
바로 수정하지 말고,
가장 가능성 높은 수정 방향을 먼저 제안해줘.

정보 수집 워크플로

검색 MCP나 브라우저 자동화 도구가 있을 때 특히 유용합니다.

• 주제별 정보 수집

• 중복 제거

• 신뢰도 비교

• 요약 정리

• 공유용 초안 작성

예시 요청은 이렇게 할 수 있습니다.

MCP 관련 최신 활용 사례를 조사해줘.
개발 생산성, 업무 자동화, 보안 관점으로 나누어 요약하고,
중복되는 내용은 합쳐서 정리해줘.
마지막엔 팀 공유용 10줄 요약도 만들어줘.

프롬프트를 템플릿처럼 재사용하라

MCP를 잘 쓰는 사람은 매번 처음부터 새로 말하지 않습니다. 자주 쓰는 요청은 템플릿으로 다듬어서 재사용합니다.

예를 들어 이런 식입니다.

[목표]
무엇을 끝내고 싶은지

[대상]
어떤 폴더 / 저장소 / 기간 / 문서를 다루는지

[제한]
읽기 전용인지, 수정 가능인지, 건드리면 안 되는 것은 무엇인지

[출력]
표 / 체크리스트 / 요약 / 초안 / diff 중 어떤 형식이 필요한지

[절차]
조사 → 계획 → 실행 → 검토 중 어디까지 할지

이 틀만 있어도 요청 품질이 눈에 띄게 올라갑니다. 사람마다 자신만의 템플릿이 생기기 시작하면, 그때부터 MCP 활용은 꽤 안정권에 들어갑니다.

실패를 줄이는 마지막 습관: 항상 작은 단위로 시작하기

MCP를 잘 쓰는 사람은 처음부터 거대한 자동화를 만들지 않습니다. 작은 성공을 쌓아 올립니다. 파일 1개, 이슈 5개, 샘플 데이터 10건처럼 작게 시작합니다. 그러고 나서 잘되면 범위를 넓힙니다.

이 습관이 중요한 이유는 간단합니다. 작은 단위에서는 실수가 보여도 고치기 쉽기 때문입니다. 반면 처음부터 전체 폴더 정리, 전체 이슈 라벨링, 전체 문서 업데이트처럼 크게 들어가면, 잘못된 기준이 순식간에 넓게 퍼집니다.

그래서 처음 실행할 때는 이런 말이 특히 좋습니다.

• 먼저 샘플 3개만 해줘

• 상위 5개 항목만 대상으로 해줘

• 테스트 브랜치에서만 시도해줘

• 초안만 만들고 적용은 하지 마

• 결과가 괜찮으면 그다음 범위를 넓히자

이건 소심한 태도가 아니라, 아주 실무적인 태도입니다.

결국 MCP를 잘 쓴다는 것은 일을 설계할 줄 안다는 뜻이다

MCP는 대단한 기술처럼 보이지만, 사용자의 입장에서 보면 결국 이런 질문으로 돌아옵니다.

"무엇을 시킬 것인가?" "어디까지 허용할 것인가?" "어떤 순서로 굴릴 것인가?"

이 세 질문에 답할 수 있으면, MCP는 훌륭한 비서가 됩니다. 반대로 이 답이 흐리면, 아무리 좋은 서버를 많이 붙여도 결과가 들쭉날쭉해집니다.

이 장의 핵심을 한 줄로 정리하면 이렇습니다.

MCP를 잘 쓰는 사람은 도구를 많이 가진 사람이 아니라, 도구가 잘 움직이게 만드는 사람이다.

질문은 구체적으로, 권한은 작게, 워크플로는 반복 가능하게. 이 세 가지만 몸에 익혀도 MCP는 단순한 연결을 넘어, 여러분의 일을 함께 굴리는 진짜 작업 파트너가 됩니다.