교보문고 MCP를 만들기 시작한 이유
사내에서 책 한 권을 골라 서로 의견을 나누는 방식으로 스터디를 진행 중인데, ebook으로 진행하다 보니 공부하는 과정에서 요약하고 싶은 부분이 자주 생긴다. 그래서 지금은 그 부분을 캡처해서 GPT에 물어보며 스터디를 하고 있다. (다만, 이게 저작권에 문제가 없는지는 따로 확인이 필요할 것 같다.)
그런데 시간이 지날수록 요약할 부분을 직접 캡처해서 올리는 일이 점점 번거로워졌다. 그래서 "이 과정을 Agent가 대신 해주면 좋겠다"는 생각이 들어 MCP를 만들기 시작했다. (교보문고 측이 직접 만들어주면 좋겠다..)
내가 생각한 교보문고 MCP의 기능
- 내가 구매한 서적들 좀 알려줘
- 내가 구매한 서적들 중 A란 이름을 가진 책이 있을까?
- A의 100페이지부터 150페이지까지 요약해줘
- 오늘 책 추천 좀 해줘

교보문고 MCP 구조
일단 내가 교보문고 직원이 아니기도하고, 교보문고 측에서 open api를 제공하지 않기 때문에 크롤링을 통해 해결해야한다.
그래서 크롤링 도구인 puppetter 또는 playwright를 사용해 데이터를 추출하기로 했다.
MCP를 본격적으로 만들기 전에 전체 프로세스가 정상적으로 동작하는지 확인하기 위해, 아래와 같은 흐름으로 PoC를 설계했다.
- Puppeteer 또는 Playwright 등을 사용해 교보문고 로그인
- 내 책 목록 페이지로 이동
- 특정 책을 선택해 웹 eBook 접속
- 현재 페이지 캡처
- 페이지 이동 후 다시 캡처
문제 발생
하지만 개발 과정에서 1단계부터 막히는 문제가 발생했다.
- Puppeteer를 Chrome에 연결하는 순간, 교보문고 로그인 웹 페이지에서 request block이 발생
- 설령 block이 뜨지 않더라도 "개발자 도구를 사용할 수 없다"라는 alert 문구가 무한 반복

시도해본 해결 방법
- Playwright 사용 ->동일하게 차단
- Puppeteer Stealth Plugin 사용 (마치 Puppeteer가 아닌 것처럼 위장) -> 동일한 결과
여기서 뭘 더할 수 있을까 고민했고, puppeteer를 한 번 분석해보기로 했다. (분석해보면 뭐라도 답이 나오겠지~ 라는 생각에 ㅎ..)
알아보니 Puppeteer 내부에서 CDP(Chrome Devtools Protocol)란 걸 사용하고 있었다.
CDP (Chrome Devtools Protocol) 이란
크롬을 디버깅할 수 있는 도구로써, 세밀하게 크롬을 조작하거나 조사하고 싶을 때 사용한다.
쿠키를 얻거나, DOM 구조 파악, console 창을 열지 않아도 CDP를 통해 script를 실행할 수 있다.
우리가 흔히 보는 개발자창(Chrom Devtools) 또한 이 CDP를 통해 만들어졌다고 한다.

.

puppeteer와 playwrigh에 비해 굉장히 복잡한 인터페이스를 가지고 있어 CDP 측에서도 자동화 도구를 위해선 puppeteer와 playwright를 사용하라고 권하고 있다.

구세주 CDP
CDP로 내가 구현하고자 하는 기능들에 한해 크롬 조작 기능을 최소한으로 사용한다면 교보문고의 자동화 도구 탐지를 회피..할 수 있지 않을까 싶어 적용해보았다.
결과적으로
- 교보문고 로그인 오픈 V
- 내 책 목록 페이지로 이동 V
- 특정 책을 선택해 웹 eBook 접속 V
- 현재 페이지 캡처 V
- 페이지 이동 후 다시 캡처 V
모든 기능을 테스트할 수 있었다.
다만, CDP의 기능을 잘못 사용하면 바로 Request block이 뜬다는점.. 이 있다.. 아슬아슬하게 줄타고 있는 느낌..?
교보문고 MCP 개발
간단한 poc를 통해 교보문고 MCP의 가능성을 보았고, 이를 기반으로 개발을 했다.
MCP 도구 정의
MCP 도구 기능 정의를 Readme.md에 정리하였다.
- login – 교보문고 로그인
- get_my_book_list – 내가 구매한 서적 목록 조회
- reading_book – 선택한 책을 바로보기로 열기
- next_page – 다음 페이지로 이동
- prev_page – 이전 페이지로 이동
- move_page – 지정한 수 만큼 페이지 이동
- get_pages_screenshot – 여러 페이지를 한 번에 스크린샷으로 저장
- get_current_page_info – 현재 페이지 정보(진행률, 페이지 번호) 확인
- close_browser – 브라우저 종료
개발 결과
커서(Cursor)를 활용해 위 기능들을 단계별로 구현한 끝에, 완성할 수 있었고 MCP를 통해
`네트워크 최적화 서적 180~200`페이지를 요약 요청을 했으며 정상적으로 작동한 것을 확인할 수 있었다.






요즘 MCP에 대해 알아보는 사람들이 부쩍 많아진 것 같다. 나 역시 자연스럽게 관심을 갖게 되었고 직접 삶에서 필요한 도구를 만들어보았다. 이는 꽤 즐거운 경험이었으며 MCP가 왜 요즘 그렇게 주목받는지 체감할 수 있었다.
무엇보다도 AI에게 여러 도구를 쥐어주면 AI가 어떤 새로운 일을 해낼 수 있을까라는 호기심이 생겼다. 또한 MCP의 각 tool이 연속적으로 실행될 수 있는지 아니면 독립적으로 실행되는지를 구분하는 것이 중요하다는 점을 깨달았다.
예를 들어, next_page는 혼자서는 실행할 수 없는 도구이며 반드시 reading_book이 선행되어야만 의미가 있다. 이런 식으로 도구 간의 관계를 명확히 정의한다면 단순히 명령어 하나로 여러 도구를 연속 실행시키거나 MCP 서버의 상태에 따라 도구의 동작을 유연하게 변화시키는 구조를 만들 수 있다. 각 도구의 동작의 특성을 고려하여 개발한다면 효율적인 MCP 서버를 구축할 수 있을 것이라고 생각한다. (교보문고 MCP 서버를 좀 더 개선해봐야겠다)
'개발' 카테고리의 다른 글
| [번역] 소프트웨어 엔지니어링에서 좋은 취향은 뭘까? (0) | 2025.11.09 |
|---|---|
| [번역] 심층 분석: Microtasks와 Javascript 실행 환경 (0) | 2025.10.26 |
| React StrictMode에서 log가 왜 두 번 안나오지..!? (0) | 2025.09.27 |
| redis clustering, tunneling을 통해 접근하는 방법 with Node.js (2) | 2025.08.09 |
| AI와 함께 라이브러리를 만들어봤다. (0) | 2025.06.05 |