오늘 개발자 타임라인에서 제일 흥미로운 건 새 모델 점수표가 아니었다. 2026년 4월 10일 오전 기준 Hacker News 상단에 올라온 글은 I still prefer MCP over skills였고, 댓글은 이미 세 자릿수를 넘겼다. 한국 쪽도 비슷했다. GeekNews에서는 Addy Osmani의 agent-skills 정리가 며칠째 회자되고 있고, 같은 날에는 마이리얼트립이 실제 비즈니스 API와 MCP 서버를 같이 공개했다.
이 조합이 왜 중요하냐면, 이제 논쟁의 초점이 “에이전트가 더 똑똑해졌나”가 아니라 “그 똑똑함을 어떤 형식으로 연결할 건가”로 옮겨갔기 때문이다. 내 기준으로 이 흐름은 꽤 선명하다. 팀 내부 규칙과 작업 습관을 주입하는 데는 스킬이 편하다. 반대로 외부 서비스, 인증, 업데이트, 원격 접근까지 걸리는 순간에는 MCP가 훨씬 단단한 선택지가 된다.
오늘 갑자기 이 논쟁이 커진 이유
HN와 GeekNews가 서로 다른 방향에서 같은 질문을 던졌다
Hacker News에서 화제가 된 글은 “스킬이 새 표준처럼 밀리고 있지만, 실제 서비스 연결에는 MCP가 더 낫다”는 주장이다. 반면 GeekNews에서 반응이 큰 agent-skills는 에이전트가 개발 생명주기 전체를 더 잘 따르도록 워크플로우를 패키징하는 방식에 가깝다. 둘은 겉으로 보면 반대처럼 보이지만, 사실 같은 질문을 던진다. 에이전트에게 무엇을 가르칠 것인가, 그리고 무엇을 직접 연결할 것인가.
| 관점 | 지금 더 강한 선택 | 이유 |
|---|---|---|
| 팀 규칙 전달 | Skills | 저장소 안에서 바로 공유하고 수정하기 쉽다 |
| 외부 서비스 연결 | MCP | 인증과 업데이트를 서버 경계 뒤로 숨길 수 있다 |
| 모바일 웹 원격 사용 | MCP | 클라이언트가 달라도 동일한 서버를 재사용할 수 있다 |
| 로컬 작업 습관 표준화 | Skills | 특정 저장소 맥락과 체크리스트를 붙이기 좋다 |
그래서 이 표가 중요한 이유는 어느 쪽이 “더 우월한 만능 해법”인지 가리기 위해서가 아니다. 역할이 다르다는 점을 놓치면 설계가 꼬인다. 최근 몇 주 동안 스킬 열풍이 빠르게 퍼진 건 사실이지만, 그 열기를 곧바로 서비스 통합 방식으로 확대 해석하는 순간 운영비와 보안 비용이 다시 튀어 오른다.
한국 커뮤니티도 이미 연결 문제로 이동했다
마이리얼트립이 GeekNews에 공개한 예시는 상징적이다. 이 팀은 콘텐츠가 아니라 실제 상품 데이터를 API와 MCP 서버로 개방했다. 말하자면 “에이전트에게 더 많은 사용법을 가르치자”가 아니라 “에이전트가 안정적으로 붙을 인터페이스를 내놓자” 쪽에 베팅한 셈이다.
이건 국내 팀들에게도 현실적인 시사점이 크다. 사내 도구, 정산 시스템, CRM, 재고 데이터처럼 살아 있는 시스템은 매주 바뀐다. 이런 세계에서는 길고 친절한 SKILL.md보다 인증과 버전 관리를 포함한 연결점 하나가 더 오래 간다.
스킬이 강한 순간은 분명히 있다
지식을 주입하고 행동 순서를 강제할 때
스킬이 매력적인 이유를 과소평가할 필요는 없다. Anthropic 문서가 설명하듯 스킬은 Claude에 새 작업 절차, 커스텀 명령, 팀 규칙을 붙이는 데 강하다. 예를 들어 “우리 팀은 PR 전에 접근성 체크리스트를 반드시 돌린다” 같은 규칙은 MCP 서버보다 스킬이 더 직접적이다. 저장소 안에 파일로 남고, 코드 리뷰와 함께 바뀌며, 팀원 모두가 같은 습관을 공유할 수 있다.
Addy Osmani의 agent-skills가 반응을 얻은 것도 이 지점 때문이다. 개발자는 종종 모델 품질보다 프로세스 품질에서 더 자주 실패한다. 스펙 없이 바로 코딩하고, 테스트를 미루고, 보안을 마지막에 붙인다. 이런 문제는 API 커넥터보다 체크리스트와 워크플로우 패키징이 더 잘 듣는다.
저장소 로컬 맥락이 핵심일 때
특정 레포지토리의 폴더 구조, 코딩 스타일, 리뷰 문화까지 에이전트가 알아야 한다면 스킬이 확실히 편하다. 실제로 MCP 앱 연동 가이드 같은 글을 다시 읽어보면, 툴 연결과 저장소 작업 방식은 서로 다른 층위라는 점이 더 선명해진다. 연결은 프로토콜 문제이고, 팀 습관은 문맥 문제다.
문제는 여기서 한 걸음 더 나갔을 때 생긴다. 많은 팀이 스킬 하나에 “툴 사용법 설명”, “서비스 인증 방법”, “예외 처리 절차”, “CLI 설치 안내”까지 다 우겨 넣기 시작한다. 그 순간 스킬은 지식 파일이 아니라 문서화가 덜 된 운영 런북이 된다.
서비스 연결은 왜 결국 MCP 쪽으로 기운나
인증과 업데이트를 분리할 수 있기 때문이다
MCP 문서의 핵심 철학은 단순하다. 모델은 무엇을 하고 싶은지만 알고, 실제 연결과 실행은 서버가 맡는다. 이 분리가 주는 체감 이점은 꽤 크다. 원격 MCP 서버는 로컬 설치 없이 붙을 수 있고, 서버가 갱신되면 클라이언트는 새 기능을 바로 가져간다. OAuth 같은 인증 흐름도 클라이언트와 서버 사이에서 정리되기 쉬워진다.
반대로 스킬 기반 통합은 자주 이런 모양이 된다. “먼저 CLI를 설치하고 환경 변수를 넣은 뒤 로그인 토큰을 저장하고 이 명령을 외우세요.” 이 방식이 작은 실험에서는 빨라도, 팀이 커질수록 기기별 차이와 토큰 관리, 버전 드리프트가 문제를 만든다. David Mohl의 글이 지적한 불편도 정확히 여기 있다. 우리는 커넥터가 필요한데, 자꾸 매뉴얼과 CLI 묶음을 통합이라고 부르고 있다.
복붙해서 바로 점검할 수 있는 것은 연결 방식이다
아래 예시는 오늘 GeekNews에 올라온 마이리얼트립 MCP 서버 설정이다.
{
"mcpServers": {
"myrealtrip": {
"url": "https://mcp-servers.myrealtrip.com/mcp"
}
}
}
이 스니펫이 보여주는 건 거창한 철학이 아니다. “어디에 붙는지”가 먼저 드러난다는 점이다. 실무에서는 이게 크다. 누가 봐도 연결 대상이 명확하고, 서버가 바뀌면 중앙에서 갱신할 수 있으며, 여러 클라이언트가 같은 경계를 재사용할 수 있다.
직접 팀 상태를 점검해보고 싶다면 이런 식으로 확인하면 된다.
printf 'skills\\n'; find .claude/skills -name SKILL.md 2>/dev/null
printf '\\npossible mcp config\\n'; rg -n 'mcpServers|transport|url' . ~/.claude 2>/dev/null | head -n 20
첫 줄은 현재 저장소나 홈 디렉터리에서 스킬 자산이 얼마나 쌓였는지 보여주고, 둘째 줄은 실제 연결 설정이 어디에 모여 있는지 훑어보는 용도다.
내 팀이라면 둘을 이렇게 나눈다
스킬은 행동 표준화에만 쓴다
스킬에는 리뷰 기준, 테스트 순서, 릴리스 체크리스트, 우리 팀이 자주 틀리는 규칙만 넣는다. 길어져도 괜찮지만, 외부 서비스 비밀키를 어떻게 발급받는지 같은 운영 문서는 넣지 않는다. 그건 이미 다른 계층의 책임이기 때문이다.
MCP는 살아 있는 시스템 연결에만 쓴다
반대로 Notion, Slack, 사내 백오피스, 파트너 API처럼 데이터가 바뀌고 인증이 필요한 시스템은 가능하면 MCP 경계로 밀어 넣는다. 여기에는 보안과 유지보수 이유가 모두 있다. 모델이 서비스를 “사용”하는 것과 서비스의 내부 절차를 “설명받는” 것은 같은 문제가 아니다.
내 생각에 앞으로 잘하는 팀은 둘 중 하나를 버리는 팀이 아니라, 둘의 책임을 헷갈리지 않는 팀이 될 가능성이 크다. 스킬은 팀의 일하는 법을 패키징하고, MCP는 팀이 붙어야 할 시스템을 패키징한다. 이 선이 흐려지는 순간 에이전트는 똑똑해 보여도 운영은 더 지저분해진다.
이번 싸움이 남긴 한 가지
오늘의 논쟁을 한 줄로 줄이면 이렇다. 스킬은 에이전트의 습관을 바꾸고, MCP는 에이전트의 손이 닿는 세상을 바꾼다. 지금 시장이 다시 MCP 쪽을 쳐다보는 이유도 여기에 있다. 지시문 몇 장보다, 인증과 업데이트를 품은 연결점 하나가 훨씬 오래 버티기 시작했기 때문이다.