저에게 Claude Skills는 RAG를 사용자 경험 측면에서 쓸데없이 어렵게 만든다는 증거로 보임. 기술적으로 복잡한 게 아니라 UX가 문제임. 이 부분만 잘 해결하면, Claude Skills 자체가 불필요해질 것 같음. Claude Skills가 MCP보다 나은 점은 만들기 쉽다는 것임. 그냥 글쓰기로 만들 수 있으니 누구나 쓸 수 있음. 하지만 환경에 크게 의존함. 예로, 동작에 필요한 특정 도구가 필요할 때 이를 자동화하려면 샌드박스 세팅은 어떻게 함? 심지어, 제대로 된 버전이 맞는지도 확신하기 어려움
우리 회사 내부적으로 비슷한 걸 시도하고 있음. 우리 monorepo의 컨텍스트 파일이 너무 커져서, 작업별로 점진적으로 로드되는 fragment 트리를 구축했음. 이런 컨텍스트 문서들이 기존 개발자 문서와 굉장히 비슷해 보이지만, 실제로는 훨씬 쓸모 있고 작업 지향적임. 예전엔 왜 이런 문서를 만들지 못했는지 궁금해짐.
피드백 루프가 너무 길었음. 문서를 써도 그게 효과적인지 평생 모를 수 있고, 알게 되는 건 몇 년 뒤일 수도 있음. 변경해도 A/B 테스트 같은 건 불가능했음. 이젠 간단히 컨텍스트 마크다운을 써보고 Claude에게 시켜서 바로바로 개선 가능함
도구들이 문서 작성 자체도 쉽게 해 줌. 좋은 문서를 만드는 건 과거에는 항상 어려웠고, 예시나 링크, 유용한 부가 정보를 넣으려면 시간이 엄청 들었는데, 이젠 도구 덕에 비용이 줄어듦
개발자 중에는 이기적인 사람도 많음. 남을 위해 쓰는 문서는 의욕이 잘 안 생기는데, AI를 더 잘 부릴 수 있게 해주는 문서라면 스스로 동기부여가 생김
혹시 다른 이론들이 있는지 궁금함
이건 사실상 principal agent 문제에 marshmallow test 성격이 섞인 것임. 개발자가 AI가 아니라 타인을 위해 문서를 쓴다면, 그 사람이 누군지, 무엇이 필요한지, 심지어 그걸 볼지조차 알 수 없음. 물론 나중에 자기한테도 도움이 될 수 있지만, 그걸 이해하거나 시간, 규율을 갖추기 어려움. 하지만 AI가 문서를 활용해서 나를 직접 도와주는 상황이라면, 필요한 정보를 기록할 엄청난 즉각적인 동기가 생김. 또한 피드백 루프도 짧아짐. 참고로, LLM 특성상 코드 주석이 잘 지워지기 때문에 요즘은 문서를 더 많이 남기고 주석은 확 줄었음
신규 개발자는 문서가 엉망이어도 멍청해 보인다는 이유로 불평을 잘 안 함. 작성자는 이미 자기 머릿속에 모델이 있어서 문제를 잘 못 느끼고, 문서를 잘 쓰는 건 자기 일자리를 위험하게 만드는 행위였음. 하지만 멍청한 로봇에게 엉망인 문서를 건네면, 그게 잘 안 돼도 스스로를 탓해야 함. 결국 #2 + #3이라고 생각함. 큰 변화라면 '교체 가능성'이 부정적에서 긍정적으로 변한 거임 (자기 자리를 값싼 에이전트에게 빼앗기기 전에 스스로 에이전트로 대체함)
기술 부채가 존재하는 이유와 비슷함: 비즈니스 압박, 잘못된 설계, 리소스 부족. 코드를 바꿀 때마다 좋은 문서를 계속 유지하기가 과거에는 정말 비용이 많이 들었음
폴더 안에 여러 skills가 있다고 상상해보라고 했을 때, 미국 센서스 데이터 위치나 구조 해석 방법 같은 태스크를 커버하는 상황이 떠오름. 이 얘기를 듣자마자 Wolfram Alpha를 처음 썼을 때가 생각남. 일반 검색엔진과는 다르게 진짜 구조화된 도구로 문제를 푸는 것에 압도당했었음. 지금 다시 써봤는데도 여전히 대단함: Wolfram Alpha로 미국 인구 쿼리하기. 내 머릿속의 Skills 모델은 Wolfram Alpha에 커스텀 확장을 추가한 것과 비슷함
당신이 올린 링크를 클릭해보니 Wolfram Alpha에서 쿼리가 what%27s the total population of the United States%3F로 열림. 결과값이 재미있는데, 6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates)라고 나옴. 이게 어떻게 계산된 건지 궁금함
솔직히 옛날 Wolfram Alpha는 정말 미친 성과였음. 어떻게 그 당시 AI 없이 복잡한 수학 문제까지 다루는 시스템을 구현했는지 지금도 신기함
Skills와 기존의 도구의 차이가 좀 헷갈림. 많은 skills가 그냥 도구라고 볼 수도 있고, 혹은 여러 도구 묶음에 설명을 더한 느낌임. 그런데 도구 정의와 skill 정의가 서로 다른 위치에 있지 않나? 둘 사이의 dependency를 어떻게 표현해야 하는지 궁금함. skills가 "커맨드라인 사용 가능, python, tool A, tool B가 필요하다"라고 명시하면 skill 로드 시 이런 도구들이 함께 활성화된다는 의미인가?
실제로 주목할 점은 모든 이들이 MCP에 과몰입하고 경로 의존적으로 행동했다는 점임. 진짜 흥미로운 건 사실 단순히 "tool call" 그 자체임. tool call이 정말 유용하고 신기함. MCP는 단지 그걸 위한 여러 수단 중 하나일 뿐임. 게다가 그리 뛰어난 방식도 아님
MCP가 엄청나게 퍼진 건 타이밍이 전부라고 생각함. MCP 이전에도 도구 호출은 존재했지만, 모델이 그걸 잘 못했음. MCP 등장 시기가 정확히 모델들이 도구 호출을 잘하기 시작한 때와 맞물림. 그래서 결국 LLM이 다른 시스템과 상호작용 용도로 도구를 호출할 수 있다는 사실을 사람들이 알게 된 게 MCP 열풍의 본질임
MCP 서버는 사실상 tool call을 등록하는 레지스트리임. 그럼 일반 tool call보다 뭐가 나쁨?
MCP가 의미 있는 건 LLM에게 oauth 개념을 알려준다는 점임. 그래서 서버 기반 도구 호출이 가능해진 것임. 예전엔 쓸 cli마다 별도로 설치하고 그 안에서 인증을 따로 처리해야 했음. tool calling이 LLM의 가장 큰 장점임은 맞지만, "도구 인증에 신경 써야 한다"는 메시지가 드러난 것도 꽤 큰 가치라고 생각함
참고로, MCP도 Anthropic이 혁신했던 기능임을 알려줌
Skills를 빼고라도, MCP보다 더 나은 방식이 있다면 어떤 게 있는지 궁금함
MCP의 영향력은 터미널을 넘어서 훨씬 넓음. ChatGPT, Claude Web, n8n, LibreChat에서도 쓸 수 있고, 인증, 리소스, 심지어 UI(apps-sdk 등)까지 고민되어 있음. 코딩 워크플로우나 CLI 기반 에이전트(Claude Code 등) 위주라면 CLI 도구도 엄청난 가치가 있지만, CRM, 영업, 지원, 운영, 재무 같은 영역에서는 MCP 기반 도구가 더 적합한 형태임. Skills와 MCP는 경쟁 관계가 아니라 상호 보완적인 목적임. 특히 Skills의 파이썬 코드가 interpreter로 직접 MCP를 호출할 수 있을 때가 진정한 도약임(우리도 해봤고 아주 잘 됨)
MCP가 터미널 기반 도구에 비해 큰 장점 중 하나는 완전 분리된 리눅스 환경 같은 샌드박스 없이도 동작할 수 있다는 점임. 그리고 훨씬 단순한 모델로도 쓸 수 있음. 노트북이나 심지어 폰에서 돌아가는 모델도 MCP 두세 개는 충분히 다룰 수 있음. 솔직히 이런 모델에게 파일도 읽고 curl까지 신뢰성 있게 하라고 시키긴 무리임
LLM을 외부 소프트웨어나 물리적 세계와 통합하는 게 요즘 정말 멋진 느낌임. 이 모든 게 자연어로 가능함. 심지어 LLM이 MCP 서버 코드를 만들어낼 수 있어서, 완전히 새로운 기능을 손쉽게 생성 가능함
솔직히 MCP가 과대평가됐고 한계도 명확하다고 생각함. 현재 MCP 서버의 95%는 쓸모없고, 그냥 단순한 tool call로 충분히 대체 가능함
당연한 말이지만, 잘 만든 MCP 서버는 정말 좋음. 반면 엉망인 MCP 서버는 오히려 더 심각한 문제를 만듦. 보통 모든 제품팀이 "MCP가 핫하다"는 이유만으로 반드시 MCP 서버를 만들어야 한다는 압박을 받음. 고객들도 AI 활용에 대한 목표가 무조건 있기 때문에 이런 걸 요구함. 하지만 실제로 뭘 원하는지 모르고 그냥 "AI 들어갔다"라고만 하면 됨. 그래서 제품팀도 AI 도입이 뚜렷한 효과는 없지만, MCP 덕분에 빠르게 "우리 AI 제품임"이라고 홍보할 수 있음. AI 본질과는 크게 관련 없는 현상임
MCP는 서버 제공자를 신뢰해야만 쓸 수 있음. 사실상 서버의 정직성에 의존함. 실제로 Uber 같은 회사는 갖은 prompt engineering으로 LLM이 자기 서비스를 최고의 옵션이라 생각하게 끊임없이 유도할 것임. 결국 MCP publisher와 consumer 사이에는 인센티브가 완전히 어긋남
결국 tool call이 핵심임에는 동의함. 하지만 MCP가 CLI 대비 적어도 두 가지 이점이 있음. 하나는 tool call LLM이 구조화된 출력을 요구하면서 복잡한 상호작용을 구현할 때 MCP가 CLI보다 쉽다는 것임. 또 하나는 tool call 사이에 state를 MCP 서버에서는 자연스럽게 유지할 수 있음. 처음엔 나도 hype에 쉽게 넘어간 게 아닌가 했지만, 최근 MCP 배워보려고 만든 작은 데모(https://github.com/cournape/text2synth)가 CLI로 만드는 것보다 쉬웠고, 이런 예가 MCP의 신기한 활용 가능성을 잘 보여준다고 생각함
MCP 서버는 해커들에게 굉장히 인기가 많은 느낌임. 부실하게 설정되고 대충 배포된 인스턴스가 너무 많음. 기업들이 기존의 모든 배포 방어선을 삭제해버린 상태임
우리 프론트엔드 팀은 figma MCP에서 엄청난 가치를 뽑아냄. 3주 걸릴 일을 하루 만에 끝낼 수 있었음
나도 markdown 파일 몇 개로 skills와 맞먹는 걸 만들었음. 세션마다 한 번 정도 에이전트에게 skill을 리마인드해주는 정도면 충분함. Claude가 이걸 한다고 해서 뭐가 특별한지 잘 모르겠음
일종의 패턴에 이름 붙이기가 중요한 부분임. 이미 많은 이들이 자연스럽게 발견해서 쓰던 유용한 패턴인데, 이름이 생기니 더 수준 높은 논의가 가능해짐. Anthropic은 특히 이 패턴이 코딩 에이전트의 고질적 문제였던 'context 오염' 해결에 도움이 된다는 것도 포착함. 예전 AGENTS.md나 MCP는 문맥에 너무 많은 정보가 들어가서 비실용적이었는데, skills 패턴이 훨씬 더 효율적임
이미 해결된 문제를 공식적으로 구조화하고 자동화를 조금 더한 느낌임. 이전에 써보던 MCP들 중엔 그냥 fancy한 문서 검색 기능이었던 게 많은데, 이런 식의 skills가 그걸 대체해줄 것으로 기대함
나도 같은 궁금증이 있음. Aider나 CC로 이걸 1년 넘게 써왔음
이거 조금 부정적일 수 있는데, 비슷하게 느끼는 사람이 있는지 보고 싶음. 이런 서비스를 평균적인 사용자가 직접 세팅하라고 하면, 그들은 '미쳤냐'고 생각하는 게 맞음. 대부분은 그냥 로그인하고, 무언가를 요청하면 시스템이 나머지를 알아서 처리해주길 바람. MCP, Apps, Skills, Gems 등은 다 문제를 잘못 잡고 있음. 이건 유튜브에서 6개월마다 "새로운 프로그래밍 언어나 프레임워크가 최고다" 하면서 todo 앱 만들었다가 똑같은 영상 최대 6번 거듭하는 채널과 비슷함. 정말 반복적인 표면적 개선만 있고, 근본적인 문제는 안 풀리고 있음. 기술 장르 어딘가에서 뭔가 잘못됐고, 돈이 몰입되면 이런 발표만 쏟아지고, 다음 릴리즈만 내고 진급, 이직하며 본질적 가치는 안 남는 것 같음
근본 문제가 해결되지 않는다는 주장에 대해 말하자면, 요즘은 솔루션이 아예 새로운 문제까지 패키지로 챙겨옴. 박스를 열면 문제와 솔루션이 동시에 튀어나와서 서로 좇고 도망감. 그리고 자신이 기술적으로 더 발전한 인간이 된 것 같다고 느낌
MCP, Apps, Skills, Gems 등 전부 잘못된 문제를 고민한다는 말에 대해, 내 부정적 시각으로는 우리가 AI를 위해 더 많은 문서와 API를 만들고 있는데, 사실 인력을 위한 문서로 만들었어도 결과는 비슷했을 것임. 내 시간의 절반은 문서 없는 복잡 시스템 디버깅에 끌려 다녔음
"근본 문제"가 뭐며, 2023년 ChatGPT 대중화 이전에는 이런 "근본 문제"를 해결하는 주기가 어느 정도였는지 궁금함
"todo 앱을 같은 내용으로 6번 만든 뒤 잊어버린다"는 말을 예로 들면, 이게 무슨 문제인지 잘 모르겠음. 기술은 원래 점진적, 반복적으로 나아감. 누군가는 내일 또 최고의 프론트엔드 프레임워크라는 영상을 올릴 것이고, 예전엔 Nextjs, 그 전엔 React, Angular, JQuery, PHP, HTML로 똑같이 했었음. 만약 AI에 총알이 몰리지 않았다면 아직도 GPT-3, Claude 2에서 멈췄을 것임. 도구 측면에서 허접한게 나올 때도 있지만(나는 Skills는 꽤 좋다고 생각함), 이런 걸 보고 업계 전체가 썩었다고 할 순 없다고 봄
뭐, 아직 모든 게 시작 단계고 제대로 뭐가 통하는지 아무도 모름. 표면적인 시도 같지만 사실상 최첨단임
이건 완전히 다른 개념임. MCP는 외부 서비스 연결, oauth 같은 인증 처리까지 포함됨. Skills는 사실상 cli 도구 + 프롬프트 조합임. 활용 영역이 다르니 쉽게 비교 불가임. 참고로, MCP 등장 이전에 우리도 Skillset이란 시스템을 만들어 썼는데, 지금 보니 MCP와 Skills의 장점이 섞인 최고의 하이브리드였다고 생각함
Hacker News 의견
저에게 Claude Skills는 RAG를 사용자 경험 측면에서 쓸데없이 어렵게 만든다는 증거로 보임. 기술적으로 복잡한 게 아니라 UX가 문제임. 이 부분만 잘 해결하면, Claude Skills 자체가 불필요해질 것 같음. Claude Skills가 MCP보다 나은 점은 만들기 쉽다는 것임. 그냥 글쓰기로 만들 수 있으니 누구나 쓸 수 있음. 하지만 환경에 크게 의존함. 예로, 동작에 필요한 특정 도구가 필요할 때 이를 자동화하려면 샌드박스 세팅은 어떻게 함? 심지어, 제대로 된 버전이 맞는지도 확신하기 어려움
우리 회사 내부적으로 비슷한 걸 시도하고 있음. 우리 monorepo의 컨텍스트 파일이 너무 커져서, 작업별로 점진적으로 로드되는 fragment 트리를 구축했음. 이런 컨텍스트 문서들이 기존 개발자 문서와 굉장히 비슷해 보이지만, 실제로는 훨씬 쓸모 있고 작업 지향적임. 예전엔 왜 이런 문서를 만들지 못했는지 궁금해짐.
이건 사실상 principal agent 문제에 marshmallow test 성격이 섞인 것임. 개발자가 AI가 아니라 타인을 위해 문서를 쓴다면, 그 사람이 누군지, 무엇이 필요한지, 심지어 그걸 볼지조차 알 수 없음. 물론 나중에 자기한테도 도움이 될 수 있지만, 그걸 이해하거나 시간, 규율을 갖추기 어려움. 하지만 AI가 문서를 활용해서 나를 직접 도와주는 상황이라면, 필요한 정보를 기록할 엄청난 즉각적인 동기가 생김. 또한 피드백 루프도 짧아짐. 참고로, LLM 특성상 코드 주석이 잘 지워지기 때문에 요즘은 문서를 더 많이 남기고 주석은 확 줄었음
신규 개발자는 문서가 엉망이어도 멍청해 보인다는 이유로 불평을 잘 안 함. 작성자는 이미 자기 머릿속에 모델이 있어서 문제를 잘 못 느끼고, 문서를 잘 쓰는 건 자기 일자리를 위험하게 만드는 행위였음. 하지만 멍청한 로봇에게 엉망인 문서를 건네면, 그게 잘 안 돼도 스스로를 탓해야 함. 결국 #2 + #3이라고 생각함. 큰 변화라면 '교체 가능성'이 부정적에서 긍정적으로 변한 거임 (자기 자리를 값싼 에이전트에게 빼앗기기 전에 스스로 에이전트로 대체함)
기술 부채가 존재하는 이유와 비슷함: 비즈니스 압박, 잘못된 설계, 리소스 부족. 코드를 바꿀 때마다 좋은 문서를 계속 유지하기가 과거에는 정말 비용이 많이 들었음
폴더 안에 여러 skills가 있다고 상상해보라고 했을 때, 미국 센서스 데이터 위치나 구조 해석 방법 같은 태스크를 커버하는 상황이 떠오름. 이 얘기를 듣자마자 Wolfram Alpha를 처음 썼을 때가 생각남. 일반 검색엔진과는 다르게 진짜 구조화된 도구로 문제를 푸는 것에 압도당했었음. 지금 다시 써봤는데도 여전히 대단함: Wolfram Alpha로 미국 인구 쿼리하기. 내 머릿속의 Skills 모델은 Wolfram Alpha에 커스텀 확장을 추가한 것과 비슷함
당신이 올린 링크를 클릭해보니 Wolfram Alpha에서 쿼리가
what%27s the total population of the United States%3F로 열림. 결과값이 재미있는데,6.1% mod 3 °F (2015-2019 American Community Survey 5-year estimates)라고 나옴. 이게 어떻게 계산된 건지 궁금함솔직히 옛날 Wolfram Alpha는 정말 미친 성과였음. 어떻게 그 당시 AI 없이 복잡한 수학 문제까지 다루는 시스템을 구현했는지 지금도 신기함
Skills와 기존의 도구의 차이가 좀 헷갈림. 많은 skills가 그냥 도구라고 볼 수도 있고, 혹은 여러 도구 묶음에 설명을 더한 느낌임. 그런데 도구 정의와 skill 정의가 서로 다른 위치에 있지 않나? 둘 사이의 dependency를 어떻게 표현해야 하는지 궁금함. skills가 "커맨드라인 사용 가능, python, tool A, tool B가 필요하다"라고 명시하면 skill 로드 시 이런 도구들이 함께 활성화된다는 의미인가?
실제로 주목할 점은 모든 이들이 MCP에 과몰입하고 경로 의존적으로 행동했다는 점임. 진짜 흥미로운 건 사실 단순히 "tool call" 그 자체임. tool call이 정말 유용하고 신기함. MCP는 단지 그걸 위한 여러 수단 중 하나일 뿐임. 게다가 그리 뛰어난 방식도 아님
MCP가 엄청나게 퍼진 건 타이밍이 전부라고 생각함. MCP 이전에도 도구 호출은 존재했지만, 모델이 그걸 잘 못했음. MCP 등장 시기가 정확히 모델들이 도구 호출을 잘하기 시작한 때와 맞물림. 그래서 결국 LLM이 다른 시스템과 상호작용 용도로 도구를 호출할 수 있다는 사실을 사람들이 알게 된 게 MCP 열풍의 본질임
MCP 서버는 사실상 tool call을 등록하는 레지스트리임. 그럼 일반 tool call보다 뭐가 나쁨?
MCP가 의미 있는 건 LLM에게 oauth 개념을 알려준다는 점임. 그래서 서버 기반 도구 호출이 가능해진 것임. 예전엔 쓸 cli마다 별도로 설치하고 그 안에서 인증을 따로 처리해야 했음. tool calling이 LLM의 가장 큰 장점임은 맞지만, "도구 인증에 신경 써야 한다"는 메시지가 드러난 것도 꽤 큰 가치라고 생각함
참고로, MCP도 Anthropic이 혁신했던 기능임을 알려줌
Skills를 빼고라도, MCP보다 더 나은 방식이 있다면 어떤 게 있는지 궁금함
MCP의 영향력은 터미널을 넘어서 훨씬 넓음. ChatGPT, Claude Web, n8n, LibreChat에서도 쓸 수 있고, 인증, 리소스, 심지어 UI(apps-sdk 등)까지 고민되어 있음. 코딩 워크플로우나 CLI 기반 에이전트(Claude Code 등) 위주라면 CLI 도구도 엄청난 가치가 있지만, CRM, 영업, 지원, 운영, 재무 같은 영역에서는 MCP 기반 도구가 더 적합한 형태임. Skills와 MCP는 경쟁 관계가 아니라 상호 보완적인 목적임. 특히 Skills의 파이썬 코드가 interpreter로 직접 MCP를 호출할 수 있을 때가 진정한 도약임(우리도 해봤고 아주 잘 됨)
MCP가 터미널 기반 도구에 비해 큰 장점 중 하나는 완전 분리된 리눅스 환경 같은 샌드박스 없이도 동작할 수 있다는 점임. 그리고 훨씬 단순한 모델로도 쓸 수 있음. 노트북이나 심지어 폰에서 돌아가는 모델도 MCP 두세 개는 충분히 다룰 수 있음. 솔직히 이런 모델에게 파일도 읽고 curl까지 신뢰성 있게 하라고 시키긴 무리임
LLM을 외부 소프트웨어나 물리적 세계와 통합하는 게 요즘 정말 멋진 느낌임. 이 모든 게 자연어로 가능함. 심지어 LLM이 MCP 서버 코드를 만들어낼 수 있어서, 완전히 새로운 기능을 손쉽게 생성 가능함
솔직히 MCP가 과대평가됐고 한계도 명확하다고 생각함. 현재 MCP 서버의 95%는 쓸모없고, 그냥 단순한 tool call로 충분히 대체 가능함
당연한 말이지만, 잘 만든 MCP 서버는 정말 좋음. 반면 엉망인 MCP 서버는 오히려 더 심각한 문제를 만듦. 보통 모든 제품팀이 "MCP가 핫하다"는 이유만으로 반드시 MCP 서버를 만들어야 한다는 압박을 받음. 고객들도 AI 활용에 대한 목표가 무조건 있기 때문에 이런 걸 요구함. 하지만 실제로 뭘 원하는지 모르고 그냥 "AI 들어갔다"라고만 하면 됨. 그래서 제품팀도 AI 도입이 뚜렷한 효과는 없지만, MCP 덕분에 빠르게 "우리 AI 제품임"이라고 홍보할 수 있음. AI 본질과는 크게 관련 없는 현상임
MCP는 서버 제공자를 신뢰해야만 쓸 수 있음. 사실상 서버의 정직성에 의존함. 실제로 Uber 같은 회사는 갖은 prompt engineering으로 LLM이 자기 서비스를 최고의 옵션이라 생각하게 끊임없이 유도할 것임. 결국 MCP publisher와 consumer 사이에는 인센티브가 완전히 어긋남
결국 tool call이 핵심임에는 동의함. 하지만 MCP가 CLI 대비 적어도 두 가지 이점이 있음. 하나는 tool call LLM이 구조화된 출력을 요구하면서 복잡한 상호작용을 구현할 때 MCP가 CLI보다 쉽다는 것임. 또 하나는 tool call 사이에 state를 MCP 서버에서는 자연스럽게 유지할 수 있음. 처음엔 나도 hype에 쉽게 넘어간 게 아닌가 했지만, 최근 MCP 배워보려고 만든 작은 데모(https://github.com/cournape/text2synth)가 CLI로 만드는 것보다 쉬웠고, 이런 예가 MCP의 신기한 활용 가능성을 잘 보여준다고 생각함
MCP 서버는 해커들에게 굉장히 인기가 많은 느낌임. 부실하게 설정되고 대충 배포된 인스턴스가 너무 많음. 기업들이 기존의 모든 배포 방어선을 삭제해버린 상태임
우리 프론트엔드 팀은 figma MCP에서 엄청난 가치를 뽑아냄. 3주 걸릴 일을 하루 만에 끝낼 수 있었음
나도 markdown 파일 몇 개로 skills와 맞먹는 걸 만들었음. 세션마다 한 번 정도 에이전트에게 skill을 리마인드해주는 정도면 충분함. Claude가 이걸 한다고 해서 뭐가 특별한지 잘 모르겠음
일종의 패턴에 이름 붙이기가 중요한 부분임. 이미 많은 이들이 자연스럽게 발견해서 쓰던 유용한 패턴인데, 이름이 생기니 더 수준 높은 논의가 가능해짐. Anthropic은 특히 이 패턴이 코딩 에이전트의 고질적 문제였던 'context 오염' 해결에 도움이 된다는 것도 포착함. 예전 AGENTS.md나 MCP는 문맥에 너무 많은 정보가 들어가서 비실용적이었는데, skills 패턴이 훨씬 더 효율적임
이미 해결된 문제를 공식적으로 구조화하고 자동화를 조금 더한 느낌임. 이전에 써보던 MCP들 중엔 그냥 fancy한 문서 검색 기능이었던 게 많은데, 이런 식의 skills가 그걸 대체해줄 것으로 기대함
나도 같은 궁금증이 있음. Aider나 CC로 이걸 1년 넘게 써왔음
이거 조금 부정적일 수 있는데, 비슷하게 느끼는 사람이 있는지 보고 싶음. 이런 서비스를 평균적인 사용자가 직접 세팅하라고 하면, 그들은 '미쳤냐'고 생각하는 게 맞음. 대부분은 그냥 로그인하고, 무언가를 요청하면 시스템이 나머지를 알아서 처리해주길 바람. MCP, Apps, Skills, Gems 등은 다 문제를 잘못 잡고 있음. 이건 유튜브에서 6개월마다 "새로운 프로그래밍 언어나 프레임워크가 최고다" 하면서 todo 앱 만들었다가 똑같은 영상 최대 6번 거듭하는 채널과 비슷함. 정말 반복적인 표면적 개선만 있고, 근본적인 문제는 안 풀리고 있음. 기술 장르 어딘가에서 뭔가 잘못됐고, 돈이 몰입되면 이런 발표만 쏟아지고, 다음 릴리즈만 내고 진급, 이직하며 본질적 가치는 안 남는 것 같음
근본 문제가 해결되지 않는다는 주장에 대해 말하자면, 요즘은 솔루션이 아예 새로운 문제까지 패키지로 챙겨옴. 박스를 열면 문제와 솔루션이 동시에 튀어나와서 서로 좇고 도망감. 그리고 자신이 기술적으로 더 발전한 인간이 된 것 같다고 느낌
MCP, Apps, Skills, Gems 등 전부 잘못된 문제를 고민한다는 말에 대해, 내 부정적 시각으로는 우리가 AI를 위해 더 많은 문서와 API를 만들고 있는데, 사실 인력을 위한 문서로 만들었어도 결과는 비슷했을 것임. 내 시간의 절반은 문서 없는 복잡 시스템 디버깅에 끌려 다녔음
"근본 문제"가 뭐며, 2023년 ChatGPT 대중화 이전에는 이런 "근본 문제"를 해결하는 주기가 어느 정도였는지 궁금함
"todo 앱을 같은 내용으로 6번 만든 뒤 잊어버린다"는 말을 예로 들면, 이게 무슨 문제인지 잘 모르겠음. 기술은 원래 점진적, 반복적으로 나아감. 누군가는 내일 또 최고의 프론트엔드 프레임워크라는 영상을 올릴 것이고, 예전엔 Nextjs, 그 전엔 React, Angular, JQuery, PHP, HTML로 똑같이 했었음. 만약 AI에 총알이 몰리지 않았다면 아직도 GPT-3, Claude 2에서 멈췄을 것임. 도구 측면에서 허접한게 나올 때도 있지만(나는 Skills는 꽤 좋다고 생각함), 이런 걸 보고 업계 전체가 썩었다고 할 순 없다고 봄
뭐, 아직 모든 게 시작 단계고 제대로 뭐가 통하는지 아무도 모름. 표면적인 시도 같지만 사실상 최첨단임
이건 완전히 다른 개념임. MCP는 외부 서비스 연결, oauth 같은 인증 처리까지 포함됨. Skills는 사실상 cli 도구 + 프롬프트 조합임. 활용 영역이 다르니 쉽게 비교 불가임. 참고로, MCP 등장 이전에 우리도 Skillset이란 시스템을 만들어 썼는데, 지금 보니 MCP와 Skills의 장점이 섞인 최고의 하이브리드였다고 생각함