MCP-B 기술의 핵심 비전은 다음과 같다고 볼 수 있습니다.
"크롬 확장 프로그램(Extension)이라는 신뢰할 수 있는 매개체를 통해, 브라우저가 이미 안전하게 관리하고 있는 사용자 정보(쿠키, 세션, 인증 등)를 활용하여,
웹페이지에 개발자가 미리 정의해 둔 '도구(Tools)'들을 AI 채팅창에서 자연어 명령으로 호출하고 제어하겠다."
하지만 저는 "확대될 여지가 없어 보인다"고 느끼며, 그 이유는 다음과 같다고 생각합니다.
사용자 저항감: 가장 큰 허들입니다. 사용자들은 자신의 브라우저 정보에 접근하는 확장 프로그램을 설치하는 것에 대해 본능적인 거부감과 보안 우려를 가지고
있습니다. 이 기술이 제공하는 편리함이 그 우려를 넘어설 만큼 압도적이지 않다면, 사용자들은 설치를 주저할 것입니다.
웹 개발자의 부담: 웹사이트 개발자들은 기존의 API를 만드는 것 외에도, MCP-B를 위한 '도구(Tools)'를 별도로 정의하고 관리해야 하는 추가적인 부담을 갖게
됩니다. 이 기술이 널리 채택되어 얻는 이득이 크지 않다면, 개발자들은 굳이 이중의 노력을 들이려 하지 않을 것입니다.
보안 문제의 책임 소지: 만약 이 기술을 통해 보안 사고가 발생했을 때, 책임이 웹사이트 개발자에게 있는지, 확장 프로그램 개발자에게 있는지, 아니면 AI 모델
제공자에게 있는지 불분명해질 수 있습니다. 이런 복잡성은 기업들이 기술을 도입하는 것을 꺼리게 만듭니다.
중앙화된 플랫폼의 부재: 현재로서는 "어떤 웹사이트가 어떤 도구들을 제공하는지" 알려주는 표준화된 디렉토리나 플랫폼이 없습니다. 사용자는 웹사이트에 방문하기전까지는 어떤 AI 기능을 사용할 수 있는지 알기 어렵습니다.
결론적으로,
MCP-B의 아이디어 자체는 기술적으로 매우 흥미롭고 혁신적이지만, 사용자와 개발자 모두에게 "왜 굳이 이 방식을 써야 하는가?"라는 근본적인 질문에 대한 명확한 답을 주지 못할 것 같습니다. 기존의 API 방식에 비해 얻는 이점은 불분명한 반면, 보안 우려와 개발 복잡성이라는 단점은 명확하기 때문입니다.
따라서 현재로서는 이 기술이 일부 매니아나 특정 목적을 가진 개발자들 사이에서 실험적으로 사용될 수는 있겠지만, 웹 생태계 전반으로 확대되기에는 많은 어려움이 있어 보입니다.
이 글의 근본적인 주제 의식에는 공감합니다만, 어떤 부분에서는 좀 고개를 갸우뚱하게 만드는 부분도 있군요.
예를 들어, 저희 회사에서 운영하고 있는 특정 서비스 홍보용 웹 사이트는 바로 이 글에서 찬양하고 있는 것과 같은 단순함을 유지하고 있습니다. 다행히도 이 웹 사이트는 대부분의 요소가 충분히 정적인 편입니다. 프론트엔드의 HTML과 CSS 등의 코드는 아무런 프레임워크 없이 사람이 직접 손으로 작성한 것이고, JS도 jQuery와 구글 애널리틱스 정도만 달려 있습니다. 공지사항이나 게시판 등은 jQuery를 사용한 AJAX로 구현되어 있지만, 그렇게 불합리하거나 과도하게 복잡한 수준이라고는 생각하지 않습니다. 제가 오래 전 기초 웹 개발에 입문했을 때 jQuery 기반으로 구현할 수 있었던 수준이라고 생각하거든요. 제가 알기로 이 사이트는 Internet Explorer 시절부터 운영되던 것이라 제가 직접 만든 것은 아닙니다만, 썩 나쁘지 않다고 생각합니다.
하지만 여기에는 Git 버전 관리와 CI/CD 파이프라인이 붙어 있고, 스테이징 서버와 실제 운영 서버를 분리시켜 놨습니다. Main 브랜치에 Pull Request가 병합되면 파이프라인에서 번들러를 돌린 산출물을 스테이징 서버에 자동으로 배포하고, 담당자가 스테이징 서버를 확인한 뒤 배포를 최종 승인하면 그게 다시 운영 서버에 배포되는 형태로 되어 있습니다. 과거에는 그냥 FTP를 통해 원본 파일을 운영 서버에 바로 덮어씌우는 방식이었는데, 관련 업무가 저희 팀으로 넘어온 뒤에 이렇게 변경하였습니다.
이게 정말 비합리적인 복잡성일까요? 과거에는 그 웹사이트의 제목 태그를 수정하는 것이 FTP 접속을 지원하는 AcroEdit(네, 원래 그 사이트의 HTML을 직접 작성하신 분들은 여전히 이걸 쓰시고 계셨습니다.)로 운영 서버의 HTML 파일에 바로 들어가서 한 줄만 수정하고 저장하면 모든 작업이 끝나는 일이었으니 그 분들은 아마도 그렇게 느낄 수도 있을 것 같습니다.
그러나 제가 생각하기에는 이 정도 복잡성 추가는 충분히 감내할 만한 것이었다고 봅니다. 모든 작업이 오직 제목 태그 하나 수정하는 것과 동일한 정도는 아니지 않습니까. 그리고 예전 코드가 주석 처리되어 덕지덕지 붙어 있던 것을 언제든 되돌릴 수 있으므로 부담없이 완전히 삭제할 수 있다거나, 투명한 변경내용 추적 및 롤백이 가능해진 점이나, 번들러에 의해 필요하다면 조금 더 기본적인 최적화를 추가할 수 있다는 점은 제 생각에는 충분히 장점입니다. 실제 환경에 배포되기 전에 미리보기를 할 수 있는 스테이징 서버 추가도 어떻게 보면 복잡성 아닌가 할 수 있습니다만, 저는 이것이 필요했다고 생각합니다.
저도 각종 웹 사이트 내부 코드 구조가 과도하게 복잡해지고 무거워진 것에는 불만이 많습니다. 요즘 윈도우의 아웃룩 앱은 웹 앱 기반으로 되어 있는데, 근래 들어서 특히나 더 무거워졌습니다. 그저 화면에서 메일 본문을 작성하거나 본문을 전체 선택하는 것만으로 버벅이거나 심지어는 "페이지 응답 없음"이 뜰 지경이니까요. 왜 이러지 싶어 웹 아웃룩에서 개발자 도구를 열어봤다가 깜짝 놀랐습니다. 한번 캐시를 비우고 새로고침을 했더니 1분 뒤에도 무슨 요청이 계속 뜨더라니까요. 브라우저에서 확인해 보니 MS 오피스 사이트 관련으로만 몇 기가바이트의 데이터가 저장되어 있었습니다.
그러나 이 글은 여러 가지가 뒤섞여 있으며, 어떤 부분은 공감합니다만 어떤 부분은 별로 공감이 되지 않습니다. 시맨틱 HTML이나 접근성에 대한 내용은 오히려 과거가 더 끔찍했다고 알고 있습니다. 게다가 개발자 경험 향상이 사용자 경험을 악화시킨다는 건 제가 웹 프론트엔드 개발자가 아니라서 그런지는 몰라도 전혀 공감이 되지 않네요. 심지어 개발자에게 모든 권력과 통제력이 집중되었다는 건 터무니없는 소리처럼 들립니다. 회사에서 권력은 경영진에게 있는 거 아니었습니까? 서양에서는 회사 구조가 한국과는 좀 다르기라도 한 건가요?
언제나 그렇듯 균형과 중용, 단순성과 실용성은 중요한 가치이며 이를 의사결정에서 우선시해야 한다는 점에는 전적으로 동의합니다. 하지만 이 글은 "모든 웹사이트를 소프트웨어 제품처럼 다루는 것"이 마치 전적으로 개발자의 책임인 것처럼 주장하고 있으며, 그 부분이 오히려 근본적인 문제 의식을 흐리게 만든다고 생각합니다. 그리고 체계가 잡혀 있지 않았던 '좋았던 옛날'을 미화하는 것처럼 보이는 부분은 오히려 비판받아야 하지 않나 생각합니다.
이 글의 요지에 동의합니다. 요새 JS를 너무 남발하고 있어서 i9-9900k를 쓰고 있어도 사이트가 버벅이는 경우가 많습니다. 게임용이나 작업용으로써는 애매한 사양이기는 하지만 이보다 사양 떨어지는 사무용 컴퓨터가 넘쳐나는게 현실이죠.
그래서 저는 인터렉티브한 부분이나 인터렉티브한 페이지 네비게비션 같은 JS가 꼭 필요할때만 쓰자는 철학의 프레임워크인 아스트로와 hotwired를 좋아합니다. 서버 사이드에서 렌더링 하자는 서버 사이드 렌더링도 좋아하고요. 반면 CSR(메타 태그만 서버 사이드로 렌더링하고 나머지 부분을 CSR로 처리하는 것도 포함합니다)은 굉장히 싫어합니다. 서버가 해야할 일을 클라이언트가 전가시키는 것으로 보고 있기 때문입니다. 개인적으로 CSR을 사용하는 전통적인 SPA 방식은 일렉트론 같은 앱에서 로컬로 프론트엔드를 실행할때 사용해야 한다고 봅니다. 물론 서버에서 프론트엔드를 로드할 경우에는 SSR을 써야 하지만요.
MCP-B 기술의 핵심 비전은 다음과 같다고 볼 수 있습니다.
"크롬 확장 프로그램(Extension)이라는 신뢰할 수 있는 매개체를 통해, 브라우저가 이미 안전하게 관리하고 있는 사용자 정보(쿠키, 세션, 인증 등)를 활용하여,
웹페이지에 개발자가 미리 정의해 둔 '도구(Tools)'들을 AI 채팅창에서 자연어 명령으로 호출하고 제어하겠다."
하지만 저는 "확대될 여지가 없어 보인다"고 느끼며, 그 이유는 다음과 같다고 생각합니다.
있습니다. 이 기술이 제공하는 편리함이 그 우려를 넘어설 만큼 압도적이지 않다면, 사용자들은 설치를 주저할 것입니다.
됩니다. 이 기술이 널리 채택되어 얻는 이득이 크지 않다면, 개발자들은 굳이 이중의 노력을 들이려 하지 않을 것입니다.
제공자에게 있는지 불분명해질 수 있습니다. 이런 복잡성은 기업들이 기술을 도입하는 것을 꺼리게 만듭니다.
결론적으로,
MCP-B의 아이디어 자체는 기술적으로 매우 흥미롭고 혁신적이지만, 사용자와 개발자 모두에게 "왜 굳이 이 방식을 써야 하는가?"라는 근본적인 질문에 대한 명확한 답을 주지 못할 것 같습니다. 기존의 API 방식에 비해 얻는 이점은 불분명한 반면, 보안 우려와 개발 복잡성이라는 단점은 명확하기 때문입니다.
따라서 현재로서는 이 기술이 일부 매니아나 특정 목적을 가진 개발자들 사이에서 실험적으로 사용될 수는 있겠지만, 웹 생태계 전반으로 확대되기에는 많은 어려움이 있어 보입니다.
이 글의 근본적인 주제 의식에는 공감합니다만, 어떤 부분에서는 좀 고개를 갸우뚱하게 만드는 부분도 있군요.
예를 들어, 저희 회사에서 운영하고 있는 특정 서비스 홍보용 웹 사이트는 바로 이 글에서 찬양하고 있는 것과 같은 단순함을 유지하고 있습니다. 다행히도 이 웹 사이트는 대부분의 요소가 충분히 정적인 편입니다. 프론트엔드의 HTML과 CSS 등의 코드는 아무런 프레임워크 없이 사람이 직접 손으로 작성한 것이고, JS도 jQuery와 구글 애널리틱스 정도만 달려 있습니다. 공지사항이나 게시판 등은 jQuery를 사용한 AJAX로 구현되어 있지만, 그렇게 불합리하거나 과도하게 복잡한 수준이라고는 생각하지 않습니다. 제가 오래 전 기초 웹 개발에 입문했을 때 jQuery 기반으로 구현할 수 있었던 수준이라고 생각하거든요. 제가 알기로 이 사이트는 Internet Explorer 시절부터 운영되던 것이라 제가 직접 만든 것은 아닙니다만, 썩 나쁘지 않다고 생각합니다.
하지만 여기에는 Git 버전 관리와 CI/CD 파이프라인이 붙어 있고, 스테이징 서버와 실제 운영 서버를 분리시켜 놨습니다. Main 브랜치에 Pull Request가 병합되면 파이프라인에서 번들러를 돌린 산출물을 스테이징 서버에 자동으로 배포하고, 담당자가 스테이징 서버를 확인한 뒤 배포를 최종 승인하면 그게 다시 운영 서버에 배포되는 형태로 되어 있습니다. 과거에는 그냥 FTP를 통해 원본 파일을 운영 서버에 바로 덮어씌우는 방식이었는데, 관련 업무가 저희 팀으로 넘어온 뒤에 이렇게 변경하였습니다.
이게 정말 비합리적인 복잡성일까요? 과거에는 그 웹사이트의 제목 태그를 수정하는 것이 FTP 접속을 지원하는 AcroEdit(네, 원래 그 사이트의 HTML을 직접 작성하신 분들은 여전히 이걸 쓰시고 계셨습니다.)로 운영 서버의 HTML 파일에 바로 들어가서 한 줄만 수정하고 저장하면 모든 작업이 끝나는 일이었으니 그 분들은 아마도 그렇게 느낄 수도 있을 것 같습니다.
그러나 제가 생각하기에는 이 정도 복잡성 추가는 충분히 감내할 만한 것이었다고 봅니다. 모든 작업이 오직 제목 태그 하나 수정하는 것과 동일한 정도는 아니지 않습니까. 그리고 예전 코드가 주석 처리되어 덕지덕지 붙어 있던 것을 언제든 되돌릴 수 있으므로 부담없이 완전히 삭제할 수 있다거나, 투명한 변경내용 추적 및 롤백이 가능해진 점이나, 번들러에 의해 필요하다면 조금 더 기본적인 최적화를 추가할 수 있다는 점은 제 생각에는 충분히 장점입니다. 실제 환경에 배포되기 전에 미리보기를 할 수 있는 스테이징 서버 추가도 어떻게 보면 복잡성 아닌가 할 수 있습니다만, 저는 이것이 필요했다고 생각합니다.
저도 각종 웹 사이트 내부 코드 구조가 과도하게 복잡해지고 무거워진 것에는 불만이 많습니다. 요즘 윈도우의 아웃룩 앱은 웹 앱 기반으로 되어 있는데, 근래 들어서 특히나 더 무거워졌습니다. 그저 화면에서 메일 본문을 작성하거나 본문을 전체 선택하는 것만으로 버벅이거나 심지어는 "페이지 응답 없음"이 뜰 지경이니까요. 왜 이러지 싶어 웹 아웃룩에서 개발자 도구를 열어봤다가 깜짝 놀랐습니다. 한번 캐시를 비우고 새로고침을 했더니 1분 뒤에도 무슨 요청이 계속 뜨더라니까요. 브라우저에서 확인해 보니 MS 오피스 사이트 관련으로만 몇 기가바이트의 데이터가 저장되어 있었습니다.
그러나 이 글은 여러 가지가 뒤섞여 있으며, 어떤 부분은 공감합니다만 어떤 부분은 별로 공감이 되지 않습니다. 시맨틱 HTML이나 접근성에 대한 내용은 오히려 과거가 더 끔찍했다고 알고 있습니다. 게다가 개발자 경험 향상이 사용자 경험을 악화시킨다는 건 제가 웹 프론트엔드 개발자가 아니라서 그런지는 몰라도 전혀 공감이 되지 않네요. 심지어 개발자에게 모든 권력과 통제력이 집중되었다는 건 터무니없는 소리처럼 들립니다. 회사에서 권력은 경영진에게 있는 거 아니었습니까? 서양에서는 회사 구조가 한국과는 좀 다르기라도 한 건가요?
언제나 그렇듯 균형과 중용, 단순성과 실용성은 중요한 가치이며 이를 의사결정에서 우선시해야 한다는 점에는 전적으로 동의합니다. 하지만 이 글은 "모든 웹사이트를 소프트웨어 제품처럼 다루는 것"이 마치 전적으로 개발자의 책임인 것처럼 주장하고 있으며, 그 부분이 오히려 근본적인 문제 의식을 흐리게 만든다고 생각합니다. 그리고 체계가 잡혀 있지 않았던 '좋았던 옛날'을 미화하는 것처럼 보이는 부분은 오히려 비판받아야 하지 않나 생각합니다.
지루~한 척…
지금은 다들 검색 서비스 도입해서 빛이 바랬지만 퍼플렉시티는 검색기반으로 답변을 한다는 차별점이 있었죠. 물론 지금 퍼플렉시티는 자체 모델 있습니다.
릴리즈 AI(https://lilys.ai/) 말고는 경쟁력 있는 AI 래퍼 없다고 봅니다. 저도 원래 모델을 이용하는게 났다고 봅니다. 이상하게 AI 래퍼는 원본보다 답을 못하더라고요.
한국은 기승전 자바민국이라 낯설어 하네 ㅋ
타국의 기술 != 타국의 데이터
라고 생각합니다
일단 무료로 풀릴 때까진 안믿음. 그록은 심지어 30달러라 구독하기 겁남...
관심 감사합니다!
ㅋㅋㅋㅋㅋ 갑자기 얻어맞은 대학원생 둥절 ..
Use Rails, Be happy
시도는 응원합니다만...
organization 새로 만들고 1.0은 날려버리는 그런 짓은 안했으면 좋겠네요.
40개 돌파라니 대단합니다!
멋진 프로젝트 입니다
(한국) 회사 생활인가요? ㅋㅋ
솔직히 저는 nano 모델 쓰는 것은, html 통짜 태그를 다 집어넣는게 아니라 정제된 정보에 대해서 추출/요약/카테고리 하는 것은 그냥 무료라고 생각하고 쓰고 있습니덩
해커뉴스 1면에 업데이트 되는 정보량이 많아서 llm 쓰는 것이 조금 걱정되기는 하는데유.
이번에 배포된 gpt-4.1-nano 가 입력 1M 토큰에 0.1$ 라는 미친 가격이라, 요약/번역/ 카테고리화 전부 싸게 가능하긴 할 것 같습니다.
이 가격은 너무나도 말이 안되서 제 블로그에 번역 api 와 4.1-nano 모델의 가격 비교를 올려놌서요.
관심 있으시면 한번 보셔도 좋을 것 같네유 : https://dev-wiki.dev/reading/tech/16
html 상에서 댓글 위치를 특정하기는 쉽나요?
이 부분까지 firecrawl 같은걸 쓰면 돈낭비가 엄청 될것 같긴합니덩.
만약 html 태그를 어떻게 잘 만져서 특정할수만 있다면, 그 이후로는 본문을 가지고 nano 모델써서 하고 싶은 일을 할 수 있을 것 같습니덩
YCD로도 나오면 좋겠어요~
이 글의 요지에 동의합니다. 요새 JS를 너무 남발하고 있어서 i9-9900k를 쓰고 있어도 사이트가 버벅이는 경우가 많습니다. 게임용이나 작업용으로써는 애매한 사양이기는 하지만 이보다 사양 떨어지는 사무용 컴퓨터가 넘쳐나는게 현실이죠.
그래서 저는 인터렉티브한 부분이나 인터렉티브한 페이지 네비게비션 같은 JS가 꼭 필요할때만 쓰자는 철학의 프레임워크인 아스트로와 hotwired를 좋아합니다. 서버 사이드에서 렌더링 하자는 서버 사이드 렌더링도 좋아하고요. 반면 CSR(메타 태그만 서버 사이드로 렌더링하고 나머지 부분을 CSR로 처리하는 것도 포함합니다)은 굉장히 싫어합니다. 서버가 해야할 일을 클라이언트가 전가시키는 것으로 보고 있기 때문입니다. 개인적으로 CSR을 사용하는 전통적인 SPA 방식은 일렉트론 같은 앱에서 로컬로 프론트엔드를 실행할때 사용해야 한다고 봅니다. 물론 서버에서 프론트엔드를 로드할 경우에는 SSR을 써야 하지만요.