왜 이렇게 복잡하게 만드는지 모르겠음
API 키를 요구하고, MCP 서버를 켜고, 클라이언트를 설정해서 마크다운 파일을 실시간으로 가져오게 해야 한다니 이해가 안 됨
그냥 모든 문서를 담은 tar 파일 하나면 충분하지 않음? 몇 MB밖에 안 될 텐데
업데이트를 쉽게 하고 싶다면 git repo로 만들면 됨. 내 에이전트는 새 세션에서 항상 git fetch를 하도록 되어 있음
아직 MCP의 목적을 잘 모르겠음. Codex는 이미 jira, confluence, gitlab, prometheus, SQL 같은 걸 다룰 줄 알고, .netrc 파일만 있으면 됨
MCP 도구들이 조합 가능성이 있는지도 의문임. grep이나 jq 같은 걸 파이프라인으로 연결할 수 있는지, 아니면 단순 CRUD API가 더 강력하고 쉬운지 모르겠음
git이나 tarball조차 필요 없다고 생각함
HTTP/HTML 자체가 이미 마크다운을 제공할 수 있는 “API”를 가지고 있음
nginx를 설정해서 $URL.md를 반환하도록 하면, LLM이 curl --header 'Accept: text/markdown' [https://gwern.net/archiving](https://gwern.net/archiving) 명령으로 최신 문서를 바로 가져올 수 있음. 한 줄 설정이면 끝임
MCP의 핵심은 발견 가능성(discoverability) 임
CRUD 앱은 단순하지만, LLM에게 세부 정보를 전부 알려줘야 함
MCP는 필요한 상황만 컨텍스트에 넣고 바로 호출할 수 있음. 여러 API에 래퍼 스크립트를 붙이면 결국 MCP를 직접 구현하는 셈임
/usr/share/man/ 폴더만 봐도 문서가 52MB 정도임
이미 man, apropos 같은 도구들이 이런 역할을 하고 있음
MCP 서버가 이 서비스를 제공하는 정석적인 방식임
웹페이지는 인간을 위한 것이고, MCP가 제공하는 문서는 에이전트를 위한 것임
결국 에이전트가 curl로 접근할 수 있는 API를 제공하는 게 MCP의 본질임
OAuth 인증을 쓰는 서비스는 어떻게 처리하는지 궁금함
나는 에이전트의 curl 호출을 감싸는 작은 CLI를 만들어 인증을 처리하고 있음
더 가볍고 이식성 있는 방법이 있는지 알고 싶음
Hacker News 의견들
왜 이렇게 복잡하게 만드는지 모르겠음
API 키를 요구하고, MCP 서버를 켜고, 클라이언트를 설정해서 마크다운 파일을 실시간으로 가져오게 해야 한다니 이해가 안 됨
그냥 모든 문서를 담은 tar 파일 하나면 충분하지 않음? 몇 MB밖에 안 될 텐데
업데이트를 쉽게 하고 싶다면 git repo로 만들면 됨. 내 에이전트는 새 세션에서 항상
git fetch를 하도록 되어 있음아직 MCP의 목적을 잘 모르겠음. Codex는 이미 jira, confluence, gitlab, prometheus, SQL 같은 걸 다룰 줄 알고,
.netrc파일만 있으면 됨MCP 도구들이 조합 가능성이 있는지도 의문임. grep이나 jq 같은 걸 파이프라인으로 연결할 수 있는지, 아니면 단순 CRUD API가 더 강력하고 쉬운지 모르겠음
HTTP/HTML 자체가 이미 마크다운을 제공할 수 있는 “API”를 가지고 있음
nginx를 설정해서
$URL.md를 반환하도록 하면, LLM이curl --header 'Accept: text/markdown' [https://gwern.net/archiving](https://gwern.net/archiving)명령으로 최신 문서를 바로 가져올 수 있음. 한 줄 설정이면 끝임CRUD 앱은 단순하지만, LLM에게 세부 정보를 전부 알려줘야 함
MCP는 필요한 상황만 컨텍스트에 넣고 바로 호출할 수 있음. 여러 API에 래퍼 스크립트를 붙이면 결국 MCP를 직접 구현하는 셈임
/usr/share/man/폴더만 봐도 문서가 52MB 정도임이미
man,apropos같은 도구들이 이런 역할을 하고 있음웹페이지는 인간을 위한 것이고, MCP가 제공하는 문서는 에이전트를 위한 것임
결국 에이전트가
curl로 접근할 수 있는 API를 제공하는 게 MCP의 본질임나는 에이전트의
curl호출을 감싸는 작은 CLI를 만들어 인증을 처리하고 있음더 가볍고 이식성 있는 방법이 있는지 알고 싶음
AWS도 자체 MCP 서버를 운영 중임
AWS Documentation MCP Server
문서 속에 묻혀 있는 희귀한 설정이나 기능을 찾을 때 꽤 유용함
Microsoft Learn MCP,
GitHub 저장소,
관련 블로그 글 참고 가능함
Google 전용 공개 문서용 MCP 서버라면, 이미 Context7 같은 서비스가 여러 개 있지 않음?
한번 써보고 싶긴 하지만, 요즘은 Gemini CLI의 토큰 사용량이 너무 많아서 꺼려짐
토큰 단가가 조금 싸도, 프롬프트마다 3배를 쓰면 의미가 없음
Google이 먼저 이 문제를 해결했으면 좋겠음
나도 공감함. Gemini 3은 iOS 26이나 Liquid Glass에 대해 전혀 모름
항상 내가 커스텀 뷰를 만들려는 줄 알고, 이전 세대 API인 ultrathinmaterial로 뭔가를 만들어버림
그냥 AGENTS.md 파일에 관련 기술 문서 링크를 붙이는 게 더 낫지 않음?
물론 하나의 거대한 텍스트 파일로 제공되면 에이전트가 링크 탐색을 반복하지 않아도 되겠지만,
문서 사이트가 이런 식으로 제공하면 충분할 듯함
뭔가 복고적인 감성이 있음
최첨단 기술이지만, 그 위에 얹힌 관료적 절차가 마치 다른 시대에서 온 듯한 느낌임
이건 아마 다운로드 가능한 스킬로도 만들 수 있을 것 같음
하지만 API 호출로 제공하면, 어떤 문서를 코딩 에이전트가 읽는지에 대한 데이터를 더 많이 수집할 수 있음
아마 이것이 gwern이 말한 “AI를 위한 글쓰기”의 예시일 것 같음
그냥 마크다운 파일을 제공하는 HTTP 서버로 충분하지 않음?
LLM이
curl로 파일을 가져오면 끝임