MSCP 개발

MCP – Model Context Protocol 이 아닌 MSCP 즉 Multi Site Content Publisher를 바이브코딩으로 만들었다.

1개 이상의 워드프레스 사이트를 운영하고 있는 경우, 컨텐츠 발행을 위해 각 사이트 마다 로그인해서 편집기로 포스트를 작성하고 발행하고.. 그러한 과정이 꽤나 번거롭고 또 생각보다 그리 수월하지 않기에 어느덧 포스트 발행에 소원해지는 경우가 왕왕 있었어서..

하나의 앱에서 관리하는 모든 워드프레스 사이트의 게시물을 간편하게 발행 및 필요한 경우 이력관리를 통해 손쉽게 수정된 내용을 반영하여 재게시 할 수 있으면 좋겠다는 생각도 있었다.

그래서 며칠간 머리속으로 생각하며 아이디어를 모았고 바로 어제 구상 중인 계획을 구현하는 작업에 착수했었다.

---

그 결과물..

워드프레스 포스트 작성 발행은 물론 내가 즐겨쓰는 케이보드 게시판에 글 등록도 작은 브릿지 플러그인을 통해 즉시 게시 가능토록 했다.

저장된 컨텐츠의 갯수 중 발행된 컨텐츠의 파악 및 내용이 변경되었을 경우 업데이트 알림을 표시하게 함으로써 일일이 찾아 다니지 않아도 이 앱 안에서 추적관리 및 재게시가 가능토록 했고.. 결과적으로 만들어 놓고 보니 가장 마음에 흡족한 기능이 되었다.

두번 째로 마음에 드는 기능은 AI 연결을 통해 정서되지 않은 컨텐츠 내용만 타이핑해 입력해 놓으면 AI html생성 기능을 통해 눈에 보기 좋은 웹문서 스타일로 자동으로 만들어 준다는 것. 물론 Ai 지침 등록이나 스킬 등록을 통해 얼마든지 내가 원하는 문서 형태로 출력 지시를 할 수 있음은 물론이다.

이 기능 덕분에 종전처럼 문서 작성에 공을 들이지 않아도 되어 포스트 작성에 걸리는 시간이 대폭 줄었다.

---

엊그제 만들었던 스마트폰 앱 W.Call에 이어 며칠 새에 윈도우즈용 앱까지 만들고 보니.. 나름 뿌듯하고 감회가 새로웠다. 올~ 내가 앱을 만들다니.. 이런 날이 오다니 하고…

근데 스마트폰에 음성전사를 위해 연결한 API가 챗GPT의 gpt transcribe 모델인데.. 통화내용이 전사 된 통화록을 보면 음성인식 실패에 따른 오타도 많고.. 그런데 희한하게도 핵심내용과 요약, 할일 등록은 기가막히게 잘 정리해서 내가 웹서버에 운영중인 CRM 앱 – 할 일 등록에 잘만 등록을 해주고 있다.

신기하다.. 개떡같이 말했는데 찰떡같이 알아듣고 요점 정리를 해주는거 같다고나 할까…

---

오늘.. 서버 필요없는 윈도우즈 테스크탑용 앱 제작을 완료하고 차기 관심 사항인 MCP (Model Context Protocol)에 대해서 공부를 했다. mcp가 뭐야? 부터 시작을 해서…

아무래도 말로 계속 설명을 듣는 것이 이해도를 높이는데 한계가 있다고 느껴지는 순간부터는 ai에게 그러지말고 우리가 직접 MCP 서버를 만들고 하나 하나 실습해 가면서 배우자고 했다.

그렇게 하루 종일 실습을 해가며 배운 결과.. 얻게 된 깨우침 하나.. 아.. AI활용의 꽃은 바로 MCP 활용이구나.. 하는 깨달음을 얻게 되었고.. MCP가 뭐다 라는 걸 어느 정도 깨우치게 된 순간 꽤나 충격적일 만큼 놀라고 말았다.

MCP를 정교하고 치밀하게 설계만 잘하면 진짜 활용도가 무궁무진한.. 도라에몽의 배주머니 같은 그런 존재다..라는 걸 .. 이제사 알게 되었기에 많이 충격을 먹은 것도 사실이다.

---

기왕에 운영하고 있는 웹서버와 MCP의 결합을 통한 시너지 효과를 극대화 하기 위해 이제부터는 MCP에 들어갈 각종 API 설계에 많은 시간과 공을 들여야 할 것 같다. 다만, 이번 작업은 아무리 열심히 한다해도 하루 이틀에 마감 지을 수 있는 그런 일은 아니기에 장기적인 계획을 세우고 차근차근 MCP 설계를 해보려 한다.

---

생각해 보면 지난 10개월여 간.. 4개 사이트의 테마제작부터 업무용 CRM앱의 개발, 각종 제세 계산앱의 개발, 스마트폰 앱 개발, 테스크탑용 앱 개발에 이르기까지.. 전문 개발자 출신도 아니면서 바이브 코딩을 통해 비록 수박 겉핥기 수준일지라도 정말 많은 유의미한 경험을 많이 해 온 것 같다..

이제 남은 건 앞으로도 꾸준히.. 내가 원하는 그리고 내가 재밌어 하는 앱개발에 열과 성을 다 해보려 한다..
끝으로 Ai들아 고맙다~~

처음에는 “ChatGPT Sites에서 MCP 서버까지 호스팅할 수 있다”는 말을 보고도 정확히 무슨 뜻인지 감이 오지 않았다. 서버가 없어도 된다는 건지, API와 MCP가 같은 것인지, 왜 또 JWT와 권한 설정이 필요한지 하나하나가 따로 놀았다. 그런데 실제 CRM에서 고객 연락처 하나를 꺼내오는 가장 작은 기능을 처음부터 끝까지 직접 연결해보니, MCP가 무엇인지 비로소 손에 잡히기 시작했다.

1. 시작은 “서버가 없어도 된다”는 말이었다

ChatGPT Sites가 MCP 서버와 Plugin을 직접 호스팅할 수 있다는 업데이트를 접했을 때 가장 먼저 든 의문은 단순했다.

결론은 아니었다. 고객·상담·세무자료처럼 실제 업무 데이터를 저장하고, 업무 로직을 수행하는 CRM 서버는 그대로 필요하다. 달라지는 것은 ChatGPT와 CRM 사이에서 MCP 프로토콜을 처리하기 위해 별도의 서버를 또 운영해야 하는 부담이다.

예전에는 MCP 하나를 붙이기 위해 Node 서버를 띄우고, 포트를 열고, nginx를 붙이고, PM2나 systemd로 프로세스를 살리고, HTTPS와 인증서를 관리하는 일까지 생각해야 했다. Sites가 맡아주는 부분은 바로 이 “MCP가 실행될 집”이었다.

2. API와 MCP를 구분하니 그림이 보였다

처음에는 API와 MCP가 비슷한 개념처럼 느껴졌다. 실제로 만들어보니 역할은 명확히 달랐다.

1. CRM 기능이미 존재하는 고객·상담·문서 기능
2. API기능을 JSON으로 호출할 수 있는 통로
3. MCP ToolAI가 이해할 이름·설명·입력 규칙
4. ChatGPT자연어로 Tool을 선택하고 사용

이때 떠오른 가장 쉬운 비유가 있었다.

3. 첫 실습은 일부러 아주 작게 잡았다

처음부터 문서 발송이나 세무 계산 검토 같은 복잡한 기능을 붙이지 않았다. 가장 단순한 읽기 기능 하나만 택했다.

이 선택이 좋았다. 문제가 생겼을 때 API 문제인지, 인증 문제인지, MCP 문제인지, Sites 배포 문제인지 구분할 수 있었기 때문이다.

먼저 CRM API를 만들었다

Node.js/Express 기반 CRM에 읽기 전용 endpoint를 하나 추가했다.

GET /api/mcp/clients/search?q={고객명}

반환 형식은 일부러 최소화했다.

{
"clients": [
{
"id": "123",
"name": "홍길동",
"phone": "010-0000-0000",
"email": "example@example.com"
}
]
}

여기서 중요한 것은 “MCP를 먼저 만들지 않았다”는 점이다. CRM API 자체를 먼저 만들고, curl과 테스트 코드로 API만 단독 검증했다.

• 인증 없는 요청 → 401로 차단되는지 확인
• 존재하는 고객 → 200과 네 필드만 반환되는지 확인
• 없는 고객 → 오류가 아니라 빈 배열을 반환하는지 확인
• 검색어 없음 → 400으로 처리되는지 확인

기존 CRM의 고객 조회 서비스와 인증 middleware를 재사용했고, Master는 전체 고객, Staff는 담당 고객만 조회할 수 있도록 기존 권한정책도 그대로 유지했다.

4. “API 주소가 있으면 누구나 조회할 수 있는 것 아닌가?”

여기서 바로 보안에 대한 의문이 생겼다. 외부에서 접근 가능한 API라면 아무나 URL을 입력해서 고객정보를 보는 것은 아닐까?

정답은 주소는 외부에서 닿아도 되지만 문은 잠겨 있어야 한다였다.

1. 요청
2. 인증 확인
3. 권한 확인
4. 허용된 경우에만 고객정보 반환

실습 API는 기존 CRM의 requireAuth를 그대로 사용했다. 인증되지 않은 요청은 401, 권한 없는 요청은 차단되도록 만들었다. 또한 주민번호, 계좌번호, 주소, 상담내용 등 MCP에 필요하지 않은 데이터는 애초에 응답에서 제외했다.

5. 이제 API 위에 MCP Tool 하나를 얹었다

API가 정상 동작한 뒤에야 MCP를 만들었다. Tool 이름은 search_client_contact로 정했다.

search_client_contact({
"query": "홍길동"
})

MCP의 역할은 단순했다.

1. 사용자가 자연어로 고객 연락처를 요청한다.
2. ChatGPT가 search_client_contact Tool을 선택한다.
3. MCP가 CRM API에 GET 요청을 보낸다.
4. CRM이 인증·권한을 확인한 뒤 JSON을 반환한다.
5. MCP가 정해진 필드만 ChatGPT에 돌려준다.

이때 만들어진 프로젝트에는 Tool 정의 파일, Worker, 테스트, 빌드 스크립트, .openai/hosting.json 등이 들어갔다. 중요한 점은 이 MCP 코드를 CRM 운영 서버에 올리지 않았다는 것이다. 이 코드는 ChatGPT Sites에서 실행하도록 준비했다.

6. Sites에 올리면서 “MCP 서버 호스팅”의 뜻이 명확해졌다

로컬 MCP 프로젝트를 Sites용 프로젝트로 등록하고 버전을 저장했다. 일반 홈페이지 UI는 만들지 않았다. 목적은 Site를 웹사이트로 쓰는 것이 아니라 MCP 서버 실행환경으로 쓰는 것이었다.

saesol-mcp/
├─ src/
│  ├─ contact.mjs
│  └─ worker.mjs
├─ tests/
├─ .openai/
│  └─ hosting.json
├─ package.json
└─ README.md

여기서 “Sites”라는 이름 때문에 잠시 혼란이 있었다. 브라우저에서 접속했을 때 예쁜 웹페이지가 나올 것처럼 느껴졌기 때문이다. 하지만 실제로는 루트 경로 /가 Not Found를 반환해도 문제가 없었다. 우리가 만든 Site는 일반 웹페이지가 아니라 MCP endpoint가 핵심이었기 때문이다.

POST /mcp    ← 실제 MCP endpoint
GET /whoami  ← POC용 사용자 식별 확인 경로
GET /        ← 일반 웹페이지 없음, Not Found 가능

여기서 감이 왔다. Sites는 “웹페이지 만드는 서비스”이기도 하지만, 이 실습에서는 사실상 MCP가 돌아가는 관리형 실행환경으로 사용했다.

7. 예상보다 어려웠던 부분은 MCP가 아니라 인증이었다

MCP 코드 자체는 생각보다 단순했다. 복잡해진 부분은 “누가 이 도구를 사용할 수 있는가”와 “Sites의 MCP가 CRM에 어떤 권한으로 접속할 것인가”였다.

이번 POC에서는 세 가지 환경값을 사용했다.

CRM 주소가 localhost여서는 안 됐다. Sites에서 실행되는 MCP에게 localhost는 내 PC가 아니라 Sites 실행환경 자신을 뜻하기 때문이다. 따라서 실제 외부 HTTPS CRM 주소가 필요했다.

Site-scoped 사용자 ID는 어떻게 알았나

처음에는 “사용자 ID라면 이메일 주소를 넣으면 되나?”라고 생각했다. 하지만 Sites가 주입하는 인증 사용자 식별값은 이메일과 다른 별도의 값이었다.

문제는 이 값을 바로 보여주는 UI가 없었다는 점이었다. 그래서 POC용으로 /whoami 경로를 하나 만들었다.

GET /whoami

- 인증된 요청이면 Site-scoped user ID만 반환
- 인증되지 않은 요청이면 401
- CRM은 호출하지 않음
- Cache-Control: no-store

처음에는 Site 소유 계정과 실제 시험할 계정이 달라 접근이 막혔다. Site 공유 설정에서 시험 계정을 Viewer로 추가하고 다시 로그인한 뒤 /whoami를 호출하자 긴 Site-scoped 사용자 ID가 정상적으로 나타났다. 그 값을 MCP_ALLOWED_USER_IDS에 등록했다.

8. CRM 인증용 JWT도 직접 연결해봤다

CRM 로그인 JWT의 기본 만료시간을 확인하니 7일이었다. 이번 POC에는 충분한 시간이었다.

비밀번호를 채팅에 넘기지 않고, 터미널에서 직접 비밀번호를 입력해 정상 로그인한 뒤 발급된 JWT만 Sites의 Secret 값에 저장했다.

CRM_JWT = ********
Secret = ON

여기서도 중요한 원칙은 간단했다.

• 비밀번호는 채팅이나 코드에 적지 않는다.
• JWT는 소스코드나 Git에 넣지 않는다.
• Secret으로 저장한다.
• 로그에도 Authorization 헤더나 JWT를 출력하지 않는다.

장기 운영이라면 고정 JWT보다 사용자별 OAuth나 서비스 전용 인증 구조가 더 적절할 수 있다. 이번에는 어디까지나 “끝까지 한 번 연결해보는 POC”라는 점을 분명히 했다.

9. 운영 CRM에도 API를 실제 배포했다

로컬에서만 API가 존재하면 Sites의 MCP가 호출할 수 없다. 따라서 고객 연락처 조회 API만 운영 CRM에 최소한으로 배포했다.

배포 후 외부 HTTPS에서 다시 검증했다.

반환 필드는 계속 id, name, phone, email 네 개만 유지했다. 운영 로그에서도 JWT나 연락처 정보가 불필요하게 기록되지 않는지 확인했다.

10. 드디어 Plugin을 설치했다

Site가 배포되고 환경변수까지 설정된 뒤, 배포된 Site의 MCP endpoint를 기반으로 Plugin을 만들고 설치했다.

1. ChatGPT사용자의 자연어 요청
2. Plugin설치된 새솔 업무 도구
3. Sites MCPsearch_client_contact 실행
4. CRM API실제 고객 데이터 조회

그리고 실제 채팅에서 업체명을 지정해 대표자 연락처 정보를 요청했다. 전화번호와 이메일이 CRM에서 정상적으로 조회되어 답변에 나타났다. 대표자 이름은 처음 API에 포함하지 않았기 때문에 조회되지 않았다.

오히려 이 결과가 MCP 구조를 아주 잘 보여줬다. AI가 모르는 것이 아니라, 우리가 Tool에 허용하지 않은 데이터는 AI도 가져올 수 없었다.

11. 실습 과정에서 겪은 시행착오도 중요했다

① ChatGPT Project와 로컬 폴더 Project를 혼동했다

웹에서 “프로젝트 만들기”를 누르면 로컬 폴더를 선택할 수 있을 것이라 생각했다. 하지만 일반 ChatGPT Project와 로컬 코드 프로젝트는 다른 개념이었다. 결국 데스크톱 앱에서 기존 MCP 폴더를 작업공간으로 열어 Sites 등록을 진행했다.

② Site 루트의 Not Found를 오류라고 생각했다

배포 URL의 루트 /에서 {“error”:”Not Found”}가 보여 잠시 실패한 줄 알았다. 그러나 일반 웹 UI를 만들지 않았으므로 당연한 결과였다. 핵심은 /mcp가 정상 동작하는지 여부였다.

③ Site 소유 계정과 실제 사용자 계정이 달랐다

Site를 만든 계정과 실제 MCP를 사용할 계정이 달라 처음에는 접근이 거부됐다. Viewer 공유를 추가한 뒤에야 실제 사용자로 인증되어 /whoami가 정상 동작했다.

④ 사용자 ID를 이메일이라고 생각했다

실제 접근제어에 사용한 것은 이메일이 아니라 Site-scoped 사용자 ID였다. 이 값을 확인하기 위해 임시 /whoami 경로를 추가했다.

⑤ 5분짜리 JWT와 실제 Sites용 JWT를 구분했다

운영 API 스모크 테스트에는 5분짜리 검증용 JWT가 적당했다. 하지만 Sites에서 실제 호출하려면 더 긴 유효기간이 필요했다. CRM의 정상 로그인 토큰이 7일이라는 것을 확인한 뒤 그 토큰을 Secret으로 사용했다.

12. 여기까지 하고 나니 MCP 활용 범위가 갑자기 커 보였다

처음에는 고객 전화번호 하나 가져오는 기능에 불과했다. 하지만 구조를 이해하고 나니 같은 패턴으로 무엇을 할 수 있을지가 눈에 들어왔다.

예: “지난달 부가세 신고서 찾아줘”

search_sent_documents({
"client": "아무개",
"document_type": "부가세 신고서",
"period": "지난달"
})

그리고 이어서 “그걸 등록된 이메일로 보내줘”라고 하면 별도의 send_document_email Tool을 호출할 수 있다.

다만 조회와 발송은 성격이 다르다. 조회는 자동으로 해도 되지만 외부 발송, 삭제, 신고 제출 같은 Action은 최종 확인을 한 번 더 받는 구조가 안전하다.

예: “양도소득세 계산내역 관련 법적 리스크 검토해줘”

이 요청도 가능하다. MCP는 CRM에서 사건 자료와 계산 입력값을 꺼내주고, AI는 그 자료를 바탕으로 취득가액, 필요경비, 장기보유특별공제, 비과세 요건, 중과 여부, 특수관계인 거래, 증빙 누락 등 검토 포인트를 분석할 수 있다.

여기서 역할을 다시 나누면 명확하다.

13. “자비스 같다”는 느낌이 든 이유

보통 ChatGPT는 질문을 하면 답을 해주는 프로그램으로 생각하기 쉽다. 하지만 MCP를 붙이는 순간 성격이 달라진다.

ChatGPT가 단순히 외부 정보를 설명하는 것이 아니라, 내 CRM을 검색하고, 내 문서를 찾고, 내 업무의 다음 단계를 실행할 수 있게 된다.

1. “지난달 부가세 신고 중 매출 급변 업체 찾아줘”↓ CRM 조회
2. “그 업체들 최근 상담내용 같이 봐”↓ 상담기록 조회
3. “세무 리스크 있는 곳만 정리해줘”↓ AI 분석
4. “고객에게 보낼 안내문 초안 작성해줘”↓ 문서 생성
5. “내가 승인하면 이메일로 보내”↓ 최종 승인 후 Action 실행

이쯤 되면 ChatGPT는 단순한 챗봇이 아니라 업무 시스템을 자연어로 조작하는 인터페이스에 가까워진다. 아이언맨의 자비스가 떠오르는 이유도 바로 이 지점이었다.

14. MCP 활용의 진짜 난도는 코딩보다 설계에 있었다

직접 해보니 MCP 코드를 만드는 것 자체보다 더 어려운 것은 어떤 기능을 어떤 단위의 Tool로 열어줄 것인지 결정하는 일이었다.

• 어떤 데이터까지 AI에게 보여줄 것인가?
• 누가 이 Tool을 사용할 수 있는가?
• 읽기와 쓰기를 어디서 나눌 것인가?
• 어떤 행동은 자동으로 하고, 어떤 행동은 반드시 사람이 승인할 것인가?
• 감사로그는 어디에 남길 것인가?
• 사용자별 권한을 어떻게 유지할 것인가?
• AI가 필요 이상으로 많은 데이터를 가져가지 않게 어떻게 제한할 것인가?

결국 MCP 활용의 수준을 결정하는 것은 Tool 개수보다 업무 프로세스를 AI가 안전하게 사용할 수 있는 형태로 구조화하는 능력이라는 생각이 들었다.

15. 이번 POC를 다시 한 줄로 정리하면

1. 1. APICRM에 고객조회 통로 하나 추가
2. 2. MCPAPI를 AI Tool로 감싸기
3. 3. SitesMCP 서버를 별도 서버 없이 호스팅
4. 4. PluginChatGPT에서 자연어로 실제 호출

그리고 마지막에 실제 CRM의 고객정보가 ChatGPT 답변으로 돌아오는 것을 확인했다. 그 순간 추상적으로 들리던 MCP가 아주 구체적인 개념으로 바뀌었다.

16. 처음 시작하는 사람이라면 이렇게 해보는 것이 좋다

이번 경험을 그대로 입문 실습으로 바꾼다면 순서는 이렇다.

1. 읽기 전용 기능 하나만 고른다. 예: 고객 이름 검색.
2. 그 기능의 API를 먼저 만들고 단독 테스트한다.
3. 인증 없는 접근이 확실히 차단되는지 확인한다.
4. 반환 데이터는 꼭 필요한 필드만 남긴다.
5. API 하나에 대응하는 MCP Tool 하나를 만든다.
6. 로컬에서 MCP → API 통합 테스트를 한다.
7. Sites에 MCP 프로젝트를 등록하고 비공개로 배포한다.
8. 환경변수와 Secret을 설정한다.
9. 필요하면 /whoami 같은 임시 진단 경로로 사용자 식별을 확인한다.
10. Plugin을 설치하고 ChatGPT에서 실제 자연어 요청을 해본다.
11. 성공한 뒤에만 두 번째 Tool을 추가한다.

처음부터 “문서 검색 + 이메일 발송 + 고객수정 + 세무계산 + 블로그 발행”을 한꺼번에 만들지 않는 편이 좋다. 하나의 읽기 전용 Tool을 끝까지 성공시키면 API, 인증, MCP, Sites, Plugin의 경계가 한 번에 이해된다.

17. 마치며

처음에는 MCP가 개발자들만 이해하는 복잡한 프로토콜처럼 보였다. 실제로 설정 과정도 결코 단순하지 않았다. API를 만들고, 인증을 확인하고, 외부 HTTPS 주소를 준비하고, Sites에 환경변수를 넣고, 사용자 ID를 확인하고, JWT를 Secret으로 저장하고, 버전을 저장하고, 다시 배포하고, Plugin까지 설치해야 했다.

하지만 그 과정을 한 번 끝까지 통과하고 나니 왜 MCP가 AI 활용에서 중요한 위치를 차지하는지 알 것 같았다.

AI가 아무리 똑똑해도 내 CRM의 데이터와 기능에 접근할 방법이 없다면 결국 “옆에서 조언해주는 사람”에 머문다. 반대로 잘 설계된 API와 MCP Tool이 연결되면 AI는 내 업무 시스템 안에서 실제 정보를 찾고, 분석하고, 다음 행동을 준비하는 존재가 된다.