neozest : neo+zest

골든래빗 출판사의 <이게 되네? ... 미친 활용법> 시리즈 중 클로드 MCP 커넥터 활용법 책이 이번에 활용 사례가 몇 가지 추가되어 업데이트되었다길래 읽어보았다. 이 책은 개발자나 엔지니어가 아니라 일반 사용자를 대상으로 적힌 MCP 활용서이다. 이 책에서는 어떤 방식으로 MCP 사용법을 알려주는지 궁금했다.

이 책의 주 독자는 개발자가 아니다. MCP 서버를 직접 만들어 본 입장에서 전체적인 내용은 어렵지 않았기에 앉은 자리에서 빠르게 읽을 수 있었다. 그럼에도 불구하고 이 활용서를 읽은 이유는 분명했다. AI 시대에 기술 자체도 중요하지만, 그 기술을 어떻게 활용해서 어떤 가치를 만들어내느냐가 더 중요해지고 있기 때문이다. AI를 잘 쓴다고 소문난 사람들을 찾아가 그들이 어떻게 활용하는가를 지켜보곤 하는데, 앉은자리에서 여러 활용 사례를 빠르게 훑어볼 수 있다는 점에서 이 책과 미친 활용법 시리즈는 충분히 매력적이다.

책을 읽기 시작하면서 가장 먼저 든 생각은 '왜 클로드를 중심에 두었을까'였다.  MCP는 LLM AI와 도구 사용을 연결해 주는 표준 프로토콜인데, 왜? 클로드로 지정했을까? MCP는 특정 LLM에 묶인 기술이 아니므로 이 책에 소개된 모든 MCP 서버는 당연히 ChatGPT나 제미나이에 연결해서도 사용할 수 있다. 하지만 클로드를 지정한 데에는 B2B 시장에서 클로드가 가진 위상을 보여준다.

MCP를 로컬 환경에서 사용하려면 어느 정도 개발 관련 용어와 마주칠 수 밖에 없다. 적어도 Node나 uv(Python)을 설치해야 하고,  중간중간 개발자에게는 익숙하지만 일반 사용자에겐 낯선 표현도 등장한다. IT업계라면 기술직무가 아니어도 알아들을 수 있는 용어들인데, 타 업계라면 당황할 수도 있겠다는 생각이다. 하지만 지나치게 어렵지는 않다. 저자분도 상자글을 통해 개발 관련된 용어를 좀 더 쉽게 설명한다. AI의 활용의 성과는 결국 관심을 가지고 시도해 보느냐에서 갈리기 시작한다고 믿는다.

회사에서 일상 업무의 생산성을 높이려면  단순히 AI 챗봇에게 물어보는 것보다는 MCP처럼 실제 도구와 연결해서 활용하는 방법이 훨씬 강력할 수 있다. 책에 소개된 여러 사례들 중에서 특히 엑셀 MCP 활용이 실무적으로 유용해 보였다. 윈도 환경에서 사용할 수 있는 방법이 좀 더 많이 소개되어야 한다는 생각은 들었다.

책을 읽다가 Pandoc(https://pandoc.org/) 프로젝트도 알게 되었다. 그동안은  개별 문서 라이브러리를 사용하는 편이었는데,  다양한 문서 형식을 한 번에 처리할 수 있는 Pandoc(판독??)을 활용하는 편이 효율적이라는 생각이 들었다.

한 가지 더 확장해볼만한 지점도 있었다.  84쪽에 소개된 Claude in Chrome 사례도 흥미롭지만, 최근 크롬에 내장된 'Ask To Gemini' 기능과 비교해 보았다면 브라우저 기반 AI 활용의 차이점이 더 명확해졌을 것이다. 아마도 시리즈의 다른 책에 소개되어 있지 않을까 싶다. 

전체적으로 큰 어려움없이 쉽게 읽히는 MCP 활용 사례집이었다. 개발자를 위한 MCP 구현서는 아니지만, AI를 조금 더 업무에 활용해 보고 싶은 비기술 직군 독자에게 어울리는 책이다. 기술직군 독자라면  구현 방법을 배우기 위한 책으로는 적절하지 않고, 실제 사용자들이 어떻게 활용할 것인지, 어떤 업무 영역에서 MCP로 연결하면 AI가 조직의 생산성과 역량을 높일 수 있을지에 대한 아이디어를 얻는 용도로 읽어볼 만하다.

관점은 세계를 만들고, 세계와 세계가 만나는 곳에는 경계가 생긴다. 정보는 그 경계를 통해 이동하고, 많은 동작은 바로 그 접점에서 일어난다. 그 세계가 우리가 만든 세계였던 때도 있고, 전혀 알지 못했던 세계를 만나게 되는 때도 있었다. 개발자들은 이렇게 살아 움직이는 경계를 API라고 부른다. 이번에 읽은 책, 책만 출판사에서 나온 <모던 API 아키텍처 설계 전략>을 읽은 후 처음 머리에 떠오른 생각이다.

책의 원제는 Mastering API architecture인데, 제목처럼 API를 중심에 두고, 개발자(생산자/소비자)의 관점, 인프라 엔지니어의 관점, 운영의 관점, 보안의 관점, 아키텍처의 관점으로 나눠서 이야기를 풀고 있다. 자신의 주된 역할을 중점적으로 읽되, 다른 역할의 이야기를 훑어가면서 다른 입장도 이해할 수 있는 계기가 되어 좋았다.

API는 결국 우리가 만들려는 세계(시스템/서비스)의 추상화가 표현된 방식이라 생각한다. 그래서 오히려 다양한 API 설계 방식을 통해 어떤 식으로 바라본 세계인지, 어떤 것이 자주 변하고 어떤 것이 덜 바뀌는지에 따라 생각의 흐름이 달라졌음을 역으로 생각하게 되었다. 예를 들어 리소스를 중심으로 바라보는 관점이 REST를 낳고, 같은 언어(스키마)로 생각을 나눠야 한다는 관점에서 gRPC가 등장했다.한편으로는 수레바퀴의 끊임없는 재발명처럼 여겨지기도 했지만...

이런 API의 지속적인 변화는 어쩔 수 없이 존재하는데, 이런 변화를 만드는 동력이 기술뿐만 아니라 비즈니스 요구사항과 규제 등도 있다는 점을 저자가 이야기하는 게 좋았다. 사실 하나의 관점으로 변화를 설명하기엔 참 어렵다는 생각이 든다.

책 내용은 괜찮은데, 부분 부분 글 표현이 좀 더 매끄러웠으면 좋았겠다는 아쉬움은 있었다.

예를 들어 p.57에서 "기존의 레거시 시스템 상위에 그래프QL을 적용해 복잡도를 제거할 수 있는 퍼사드로 사용하는 것도 가능하지만, 잘 설계된 API 상위에 그래프QL을 적용한다는 것은 퍼사드를 쉽게 구현하고 유지할 수 있음을 의미한다. 그래프QL은 보완적인 기술로 생각하여 API를 설계하고 구현할 때 함께 고려해야 한다. 또한 전체 API 생태계를 구현하는 완전한 방법으로 바라봐도 무방하다."라는 문단이 있다. 내가 이해한 바로는, 이 문단은 기존의 레거시 시스템 위에 그래프QL을 적용하는 퍼사드 구조로 복잡도를 감출 수 있는데, 잘 설계된 API라면 그 위에 그래프QL을 적용하여 퍼사드를 구현하고 유지하는 것이 쉬운 경우가 많다는 점, 그리고  API를 설계하고 구현할 때 그래프QL을 보완적인 기술로 생각할 수도 있지만, 전체 API 생태계를 구현하기 위한 완전한 관점으로 볼 수 있다는 점으로 이해했다. 다만 한 번에 이렇게 이해되지 않아서 조금 고민의 시간을 가졌다.

배포(deployment)와 릴리즈(release)를 따로 구분하자는 소트웍스의 주장을 자세히 설명해 준 섹션에서 CI/CD에 대해 또 다른 관점을 얻었다. 배포와 릴리즈의 관점에 따라 배포 및 기능 릴리즈의 프로세스와 구조, 방식에 차이가 날 수밖에 없겠다. 두 개념을 나눠서 프로세스를 설계하는 것이 맞겠다는 깨달음을 얻었다.

결국 API 아키텍처는 단순한 엔드포인트를 나누는 문제가 아니라 구축하는 시스템이 외부 세계와 어떤 방식으로 관계를 맺을 것인지를 설계하는 일이다. 이 책은 그 관계를 개발, 운영, 인프라, 보안, 비즈니스 변화의 관점에서 훑어보는 그런 책이다.