Context7는 훌륭한 MCP의 완벽한 사례지만 RooCode 코딩 향상에는 도움이 될까?

채널 아이콘
GosuCoder 구독자 9,180명

요약

이 영상에서 화자는 Context7 MCP의 구조와 기능을 직접 살펴보며, GitHub 리포지토리와 Postman을 통해 API 호출 방식을 분석합니다. 또한 Context7을 MicroManager 오케스트레이터 모드에 통합해 실제 루트 코드(Root Code) 워크플로우에 미치는 영향을 실험해 봅니다. 테스트 결과, 추가 컨텍스트가 항상 성능 개선으로 이어지지는 않았고, MCP 호출이 불규칙하게 동작하는 한계도 드러났습니다. 전반적으로 Context7은 향후 MCP 발전 방향을 제시하지만, 현 시점에서는 루트 코드 작업에 큰 변화를 주지는 못했습니다.

주요 키워드

Context7 MCP API 래퍼 Postman doc mode MicroManager 오케스트레이터 루트 코드 토픽 필터링 LLM

하이라이트

  • 🔑 Context7는 경량의 API 래퍼 형태 MCP로, LLM용 문서 요약을 제공합니다.
  • ⚡️ GitHub 리포지토리에서 두 개 함수만으로 공용 API 호출을 감싸는 구조를 확인했습니다.
  • 🌟 Postman으로 조회·요청을 직접 호출해 공용 문서 목록과 세부 ID를 받아봤습니다.
  • 📌 토픽 필터를 적용해 Vue.js 문서를 700줄에서 912줄로 확대·세분화할 수 있었습니다.
  • 🚀 Ask 모드에서 ‘새 페이지 생성 방법’을 질의해 라우팅 가이드와 스켈레톤 코드를 얻었습니다.
  • 🛠 MicroManager에 senior architect 모드와 doc mode를 추가해 오케스트레이션을 실험했습니다.
  • ❓ 동일한 프롬프트를 doc mode 유무로 실행했더니, 오히려 문서 모드 사용 시 오류가 잦았습니다.
  • ⚠️ 추가 문맥이 항상 더 나은 결과로 이어지지 않으며, 호출 빈도 제어가 관건이었습니다.
  • 💡 Context7는 MCP의 이상적 모델이나, 루트 코드 최적화에는 미미한 효과에 머물렀습니다.
  • 📈 전반적으로 MCP 호출 안정성과 비용 대비 성능을 개선할 후속 연구가 필요합니다.

용어 설명

MCP

LLM과 연동해 특정 기능(API 호출 등)을 래핑하는 관리형 엔진

API

응용 프로그램 프로그래밍 인터페이스로, 프로그램 간 데이터 호출 규격

Postman

API 동작을 개발 환경에서 시각적으로 테스트하는 도구

doc mode

MCP를 통해 문서를 불러와 필요한 정보만 추출하는 모드

MicroManager

작업을 세분화해 여러 모델에 분산 수행시키는 코딩 오케스트레이터

오케스트레이터

다수의 작업 또는 서비스를 조율해 자동화하는 중간 매개체

LLM

대규모 언어 모델로, 대화·생성 등의 AI 기능을 수행

[00:00:00] 인트로 및 목표 소개

Context7 MCP 열풍을 언급합니다. GitHub, Postman, 테스트 플랜을 예고합니다.

MCP 열풍처럼 Context 7도 많은 관심을 받고 있지만, 실제로는 혁신적인 변화보다는 MCP의 발전 방향을 보여주는 좋은 예시라고 설명합니다.
GitHub 저장소와 Postman을 통해 Context 7의 실제 구조와 API 작동 방식을 살펴보겠다고 소개합니다.
[00:01:07] GitHub 리포지토리 분석

코드베이스 구조를 살펴봅니다. API 래퍼 함수 둘만 존재합니다.

GitHub 저장소를 살펴보며, MCP 서버가 실제로는 API 호출의 래퍼에 불과하다는 점을 설명합니다.
[00:02:02] Postman으로 API 호출 시연

공용 API 엔드포인트를 호출합니다. 리스트 조회 후 ID 기반 상세 호출을 확인합니다.

공개 API의 작동 방식과 view 쿼리 시 발생할 수 있는 문제점들을 설명하며, 문서 검색의 한계를 지적합니다.
Vue.js 문서를 예로 들어 API 호출 방식과 결과를 설명하며, define component 검색 결과가 없음을 확인합니다.
Vue.js 컴포넌트 정의 관련 문서를 검토하면서 데이터 블록은 있지만 컴포넌트 정의 방법이 누락되어 있음을 발견했습니다.
문서에서 'topic' 파라미터를 발견하고 이를 활용해 보니 912줄의 더 상세한 문서가 반환되었고, defineComponent도 포함되어 있었습니다.
[00:04:00] 토픽 필터링 실험

토픽 파라미터 적용 전·후 결과를 비교합니다. 정의 컴포넌트 검색이 가능해졌습니다.

문서 요약본에 의존하는 현재 방식에 대해 우려를 표명하며, 자동 업데이트 시스템과 문서 구조에 대해 설명했습니다.
API를 테스트해본 결과, 향후 유료화될 가능성이 높다고 예측했습니다.
[00:06:20] Ask 모드 예시

‘새 페이지 생성’ 질의 실습을 보여줍니다. 라우팅 설정 및 스켈레톤 코드가 반환됩니다.

ask 모드에서 Vue.js로 새 페이지 생성 방법을 질문하고 응답을 받았습니다.
Vue.js 문서 검색 결과를 확인하며, 라우팅 토픽이 자동으로 선택된 것에 대해 흥미로운 발견을 합니다.
새 페이지 생성에 관한 Vue Router 설치 방법과 기본 구조, 라우트 설정 방법 등이 정확하게 제공되었음을 확인합니다.
Loopback 프레임워크에서 새로운 API를 만드는 방법을 검색하여 정확한 문서와 터미널 명령어들을 얻습니다.
[00:08:43] MicroManager 통합 실험

senior architect와 doc mode를 연결해 봅니다. 오케스트레이션 동작을 테스트합니다.

마이크로매니저 시스템을 소개하며, 다양한 레벨(인턴, 주니어, 미들, 시니어)의 모델 할당 방식을 설명합니다.
시니어 아키텍트라는 새로운 모드를 도입하고, doc 모드 접근 권한이 앱 아키텍처 설계에 미치는 영향을 실험 중입니다.
Doc 모드의 기본 개념과 목적을 설명합니다. React 컴포넌트 구현이나 XJS 명령어와 같은 구체적인 개발 질문에 대해 MCP 호출을 통해 답변을 제공하는 실험적 기능입니다.
Doc 모드의 주요 목표는 Context 7 MCP를 통해 관련 문서를 찾아 필요한 정보를 추출하고, 개발자가 즉시 활용할 수 있는 프로덕션 수준의 답변을 제공하는 것입니다.
Doc 모드를 연구자, 시니어, 중급 개발자 역할에도 연결하여 코드베이스 연구나 문제 해결 시 필요한 문서에 접근할 수 있도록 확장했습니다.
아키텍트보다는 실제 구현을 담당하는 역할들에게 Doc 모드가 더 유용하다는 것을 발견했습니다. 특히 터미널 명령어 실행이나 오류 해결 시 문서 참조가 필요한 상황에서 도움이 됩니다.
[00:12:01] 문서 모드 효과 비교

동일 프롬프트 두 차례 실행 결과를 대조합니다. doc mode 사용 시 불안정함을 확인했습니다.

Doc 모드 사용 테스트 결과, 사용 빈도와 효과가 상황에 따라 매우 다양했으며, 때로는 명시적인 지시에도 불구하고 사용되지 않는 등 일관성 있는 동작을 보장하기 어려웠습니다.
Context 7의 성능은 우수하지만, RooCode 내에서 MCP 호출이 제대로 작동하지 않는 문제점이 있습니다. Ask 모드나 Code 모드에서는 잘 작동하지만, 일반적인 상황에서는 명시적으로 지시해도 호출을 회피하는 경향이 있습니다.
Micro Manager를 통한 실제 예시를 보여주며, React 라이브러리 문서와 Vite 정보를 성공적으로 가져왔지만, papa parse와 같은 일부 라이브러리는 찾지 못했습니다.
문서 검색 결과를 바탕으로 인턴 모드, 주니어 모드 등 다양한 모드로 전환되었지만, 마이크로매니저의 초기 데이터 제공 외에는 추가 호출이 발생하지 않았습니다.
추가 컨텍스트가 필요할 때만 선택적으로 호출하려 하는데, 이는 비용 효율성 때문입니다.
추가 컨텍스트로 더 나은 평가 점수를 기대했으나, 실제로는 그렇지 않아 실망스러웠습니다.
문제와 직접적으로 관련없는 추가 컨텍스트가 실제로 얼마나 도움이 되는지에 대한 의문이 제기됩니다.
[00:16:21] 최종 분석 및 결론

Context7의 장단점을 요약합니다. 루트 코드 적용 한계와 향후 과제를 제시합니다.

문서 모드 없이 동일한 프롬프트와 모델로 테스트했을 때, 오히려 작동하는 UI를 얻을 수 있었습니다.
CSV 파일 로드 기능이 구현되었으나, UI 디자인 측면에서 몇 가지 문제점이 있었습니다.
문서 모드 사용 여부에 따른 두 번의 테스트 결과, 문서 모드 없이 실행했을 때 더 나은 결과를 얻었습니다.
더 많은 컨텍스트가 반드시 더 나은 결과를 보장하지 않으며, Context 7의 접근 방식이 MCP의 올바른 방향성을 제시합니다.
Context7의 가치와 LLM 연동성에 대해 논의하며, 오케스트레이터 모드에서 문서 로딩의 효율성 문제를 지적합니다.
Context7을 MCP의 좋은 예시로 평가하면서도, React와 Vue 라이브러리 관련 문서 선택의 정확성에 대한 우려를 표명합니다.
서비스의 유료화 가능성을 논하며, 현재 제공하는 가치 대비 비용 지불 의향에 대해 회의적인 시각을 보입니다.
문서 모드 아이디어의 잠재력과 에이전트 기반 문서 검색 시스템의 가능성에 대해 긍정적으로 평가합니다.
Context7의 현재 한계를 인정하면서도, 개발자들에게 실질적 가치를 제공하는 혁신적인 도구로서의 잠재력을 강조합니다.
여러분 MCP에 대한 열풍이 있었던 거
기억나시나요? MCP가 전부라고 했던
그때처럼 저는 Context 7에 대해서도
비슷한 느낌을 받고 있습니다. 말 그대로
Context 7에 대한 댓글과 게시물들이 넘쳐나고 있죠
솔직히 말씀드리면
Context 7은 앞으로 MCP들이 나아갈 방향의
완벽한 예시라고 생각합니다. 물론 좋은 도구이지만
많은 사람들이 이야기하는 것처럼 혁신적인 변화를
가져오지는 않을 것 같습니다
그래서 오늘 제가 보여드릴 것은
GitHub 저장소에서
실제로 어떻게 동작하는지
Postman을 통해
API들이 어떻게 작동하는지 보여드리고
제가 수행한 몇 가지 테스트와
RootCode에서 실제로
어떻게 작동하는지 보여드리겠습니다
그리고 제가 어떻게 마이크로 매니저를
수정했는지도 보여드릴 건데
Context 7을 새로운 모드에 통합하려고 시도한 것도 보여드리겠습니다
제 결과가 그리 좋지는 않았기 때문에
따라하시지는 마시고
다만 현재 MCP가 가진
한계점들을 보여드리고 싶습니다
특히 RootCode에서의 한계점에 대해서요
자, 그럼 바로 시작해보겠습니다
먼저 GitHub 저장소를 보면 매우 단순한데
MCP 서버를 실행할 때 실제로 하는 일은
사실 저는
MCP 서버라는 용어도 좋아하지 않습니다
마치 실제 서버가 돌아가는 것처럼
들리기 때문인데요
실제로는 API 호출에 대한
래퍼에 불과하거든요
코드베이스에서 보여드리겠습니다
실제로 코드를 다운받아서
Cursor에 불러왔는데요
바로 이겁니다. 두 개의 함수가 있는데
이것들은 API 호출을 래핑하는 도구 호출입니다
이들은 공개 API라서
Postman에서 로드해서
직접 호출해볼 수 있습니다
나머지는 전부 타입과
유틸, 포맷팅 같은 매우 기본적인 것들뿐입니다
여기서 실제로 보여주는 것은
MCP 서버를 활용하는 방식인데
이것들을 도구로 등록해서
RootCode를 통해 볼 수 있게 되는 거죠
곧 보여드리겠습니다
제가 주목하는 것은 바로 이거예요
이것들은 완전히 공개된 API입니다
view를 쿼리하면
ID에 view가 포함된 목록을 보내줍니다
이게 바로 제가 생각하기에
시간이 지나면서 문제가 될 수 있는 부분인데
어떻게 zero view나
다른 것들을 제외할 수 있는지가 의문입니다
실제로 몇 번
RootCode에서 물어보더라고요
이걸 원하나요 저걸 원하나요
그리고 물어본 것들 중에
실제로 그리 좋지 않은 것들도 있었어요
그래서 어떤 문서를 가져올지
정확히 알고 있어야 합니다
어쨌든 일단 그걸 받으면
기본적으로 ID를 추가하는데
이걸 원한다면 슬래시 없이
API 호출에 슬래시 하나만 붙여서
ID를 추가하면 됩니다
그러면 Vue.js의 경우
문서를 보여주는데
700줄 정도의 문서를 주네요
제가 찾아보고 싶었던 것 중 하나는
define component가 여기 있는지였는데
보이지 않네요
여기에 컴포넌트가 정의되어 있지 않은데
왜 컴포넌트 정의가 없을까요?
데이터 블록은 있나요?
음, 데이터 블록은 실제로 있네요
그리고 다른 것들도 있는데
메서드 같은 것들이 있고
어디 보자... 확인해보고 싶은데
메서드를 어떻게 지정하는지
실제로 설명이 되어있지 않네요
mounted도 있고... 어쨌든
제가 좀 더 자세히 살펴본 것은
코드로 돌아가보면
여기 몇 가지 매개변수가 있는데
topic이라는 게 있어서 흥미로웠어요
문서에서 토픽을
지정할 수
있더라고요. 한번 해볼게요
이 컴포넌트를 추가하고
토픽을 넣어서 확인해보면
여기 912줄의 텍스트가 나왔는데
defineComponent가 나타나나요?
실제로 나타나네요. 제가 느끼기에는
기본으로 제공되는 내용에
매우 중요한 정보가 누락된 것 같아요
살펴보니 좀 걱정되는 게
문서의 요약본에 의존하고 있다는 건데
이전보다는 낫죠
이게 계속 업데이트될 거라고 하는데
아마도 자동으로
업데이트하고 있을 것 같아요
보시면 여기
이 링크가 있잖아요
퀵 스타트 가이드로 연결되는
문서 링크가 있네요
이 문서를 보면
그들이 하는 일이
모든 문서를 가져와서
요약하는 거예요. 보세요
퀵 스타트 가이드가 있고
소개 가이드, 컴포넌트
등록 가이드가 있고, 전반적으로
꽤나
인상적인
단순화된
Vue.js 문서의 요약본이에요
하지만 토픽 관련해서는 걱정이...
아니, 걱정보다는
혼란스럽다는 게
더 정확한 표현일 것 같아요
제가 찾고 있던
몇 가지를 찾을 수 없었거든요
이건 일종의 시맨틱
검색을 하는 것 같은데
더 많은 라인이
반환된 게 놀라웠어요
아마도 요약되지 않은 뷰를 보여주는 것 같아요
흥미롭긴 한데
API를 많이 테스트해봤어요
아마 그들이
이걸 유료화할 것 같아요
이 기능에 대해
요금을 부과할 수 있도록
contacts.com 웹페이지를 보면
그런 느낌이 들어요
API 키나 접근 권한에
요금을 부과할 것 같아요
지금은 시작 단계인데
놀랍지 않게도
다음 달 정도면
유료화될 것 같아요
사람들이 이 API를
호출하는
횟수를 보면요
이제 ask 모드에서
Context 7로 Vue에서 새 페이지를 어떻게 만드는지
물어봤더니, 기본적으로
Vue라는 라이브러리를 찾아서
이 모든 것들을 가져왔어요
반환된 결과가 꽤 많았는데
Vue.js/docs를 정확하게 선택했고
docs 안에서 'topic'으로 라우팅을 지정했네요
라우팅이요.
이게 흥미로운 점인데
때로는 토픽이 전혀 전달되지 않을 때도 있어서
이걸 검색 토픽으로 살펴본 적이 없었거든요
한번
이걸 검색 토픽으로 빠르게 살펴보죠
정말
빠르게 확인해 보도록 하겠습니다
늦은 밤이라 피곤한데 맞게 썼나요
여기서 우리가 얻은 결과는 720줄이네요
720줄
음... 이게 실제로
새로운 페이지 생성에 대해
뭔가 포함하고 있나요? 기술적으로는 필요한 것을
제공하고 있긴 하네요
어쨌든 우리는
응답으로 이 모든 데이터를 받았는데
엄청난 양의 데이터네요
여기 응답을 보면 Vue Router 설치하라고 하고
새 페이지의 기본 구조와
라우트 설정 방법을 알려주는데
이 모든 게 맞습니다. Vue를
잘 알고 있어서
확실히 알 수 있네요
제가 궁금했던 또 다른 점은
Loopback 같은 라이브러리도 있는지였는데
실제로 있더라고요
제가 사용하는 프레임워크라서요
'Loopback에서 새로운 API를 어떻게 만드나요'라고
Context7에 물어보면
어떤 결과가 나오는지 보여드리죠
자, 여기 결과가 나왔네요
먼저 Loopback을 검색했고
Loopback이라는 라이브러리는 하나뿐인데
정확한 문서를
가져왔다는 게 정말 좋네요
'API 생성'이라는 토픽을 사용했고
궁극적으로 이 문서를 읽어보니
정말 좋은 문서인 것 같아요
좋은
문서네요. 그리고 답변을 보면
결국에는 일련의
터미널 명령어들이에요
기본적으로 앱을 생성하고
새로운 API를 만들려면
컨트롤러를 만들어야 하고
만약 모델을 백엔드로 사용한다면
당연히 리포지토리가 필요한데
이걸로 필요한 걸 다 얻을 수 있죠
이제
제가 마이크로매니저로
시도하고 있는 것을 보여드리겠습니다
아직 특별히 멋진
디자인을 하지 않아서
읽기가 조금 어려울 수 있지만
이것들이 현재 정의된 모드들입니다
마이크로매니저를
잘 모르시는 분들을 위해 설명하자면
이건 코딩 작업을
조율하고 태스크를 나누어서
전문화된 작업자들에게 전달하는 시스템입니다
저는 기본적으로 각각의 능력에 따라
모델을 할당하는데
인턴이나 주니어 레벨에서는
매우 저렴한 모델을 사용하고
미들레벨은 좀 더 비싼 모델
시니어는 가장 비싼 모델을 쓰죠
하지만 이제 시니어
아키텍트라는 새로운 모드를 도입했는데
이게 기존의 아키텍트를 대체하고
제가 시도해보고 있는 것은
doc 모드에 대한 접근 권한을 주면
앱 아키텍처 설계가 더 나아지는지 보는 거예요
doc 모드에 대해서는
곧 설명드리겠지만, 제 생각은
특정 모드에 질문을 하고 싶습니다. 예를 들어
React를 사용해서 새로운 컴포넌트를 어떻게 구현하는지
또는 XJS에서 어떤 명령어를 실행해야 하는지와 같은 질문을 할 때
AI가 이런 유형의 질문을 받으면
Doc 모드로 전환되어
Doc 모드는 실제로 MCP 호출을 수행합니다.
이것이 장기적으로 효과가 있을지는 모르겠습니다.
지금은 완전히 실험 단계입니다
어쨌든 Doc 모드로 전환하면
이것이 매우 명시적으로 Context 7을 사용하려 하는 것을 볼 수 있습니다
예를 들어, 목표는 Context 7 MCP에
하나 이상의 명령을 실행하는 것입니다
가장 관련성 있는 문서를 열고
필요한 정보만 추출하여
개발자가 즉시 문제를 해결할 수 있는
완벽한 프로덕션 수준의 답변을 만드는 것입니다
이것을 개발자가 질문을 하는 방식으로
구성했고, 다른 규칙들도 추가했으며
모드 전환을 못하게 했습니다
여기서 또 언급하고 싶은 것은
Doc 모드를 연구자 역할에도 연결했다는 점입니다
따라서 연구자도 이제
Doc 모드에 접근할 수 있게 되었습니다
그래서 코드베이스에 대해 무언가를 연구할 때
실제로 찾아보고 답을 얻을 수 있습니다
시니어 모드와 중급 모드에도 연결했는데
때로는 실행 중인 명령이나
질문이 있을 때
Doc 모드를 선택적으로 사용해서
추가 정보를 가져올 수 있기 때문입니다
마이크로매니저도 필요한 경우
문서를 가져올 수 있는 접근 권한이 있습니다
아직 이것을 어디에 배치하는 것이 좋을지
확실하지 않지만, 처음에는
시니어 아키텍트만 접근 권한을 가지도록 했습니다
하지만 여기서 문제는 이것이 실제 구현이 아닌
계획 단계라는 것입니다
솔직히 말해서 아키텍트는
Context 7이 필요하지 않습니다
처음에는 상위 수준의 내용이 필요할 것이라 생각했지만
보통 아키텍트는 구현 세부사항 없이도
전체 애플리케이션을 계획할 수 있습니다
그래서 마이크로매니저에 넣어서
태스크를 통해 구현 세부사항을 제공하면 어떨까 했지만
이것도 시니어나 중급 개발자가
터미널 명령어 실행 중 문제가 생기거나
명령어를 찾을 수 없을 때는 도움이 되지 않습니다
또는 콘솔에서 오류가 발생했을 때
해결 방법을 찾지 못하면
문서를 찾아볼 수 있어야 합니다
그래서 결국 이 시스템으로
여러 태스크를 실행해보았고
의도적으로 Doc 모드를
사용하도록 강제해보았습니다
그런데 이게 까다로운 게
어떤 실행에서는 한 번만 사용하고
어떤 실행에서는 네 번을 사용하기도 했습니다
심지어 한 번은 전혀 사용하지 않은 경우도 있었는데
마치 필요성을 전혀 느끼지 못한 것 같았습니다
아무리 명시적으로 특정 작업을 하라고 지시해도
때로는 작동하지 않았고
원하는 대로 되지 않거나
콘솔에서 오류가 발생했을 때
해결하지 못하고 문서를
찾아봐야 하는 상황이 있었습니다
그래서 이 시스템으로 여러 태스크를 실행해보고
의도적으로 Doc 모드를 사용하도록
강제해보았는데, Context 7이라고도 하는
Doc 모드는 꽤 까다로웠습니다
어떤 실행에서는 한 번만 사용하고
어떤 실행에서는 네 번을 사용했고
한 번은 전혀 사용하지 않은 경우도 있었는데
마치 필요성을 전혀 느끼지 못한 것처럼
아무리 명시적으로 지시해도
특정 작업을 수행하지 않았습니다
때로는 전혀 작동하지 않았습니다
때로는 원하는 작업을 수행하지 않아서
정말 어려운 부분인데
Context 7이 한계가 있다고 생각하지는 않습니다
제가 말씀드렸듯이 Ask 모드나
Code 모드에서는 원하는 것을
입력할 수 있고 예를 들어
특정 문서를 가져와서
작업을 수행하라고 하면 완벽하게 작동합니다
Context 7은 그런 면에서 정말 훌륭합니다
하지만 더 큰 문제는 RooCode 내에서
MCP 호출을 하는 것 자체가
까다롭다는 점입니다
마치 이등 시민처럼 취급되어
자주 호출하려 하지 않고
아무리 명시적으로 호출하려 해도
때때로 그냥 무시해버립니다
지금부터 제가 가지고 있는
몇 가지 예시를 보여드리겠습니다
여기 이 예시는
제가 앞서 말씀드린 Micro Manager와
모든 기능을 함께 실행한 것입니다
스크롤링에도 문제가 있는데
내용이 너무 길어지면
좀 이상해져서
수동으로 스크롤을 올려야 합니다
조금 불편하긴 한데
동적으로 콘텐츠를 로드하려고 하는 것 같네요
여기 꽤 긴 프롬프트가 있고
전체
결과물이 있습니다
보시다시피 여기서
React 관련 정보를 가져왔고
많은 문서 옵션들이 있습니다
여기 React 라이브러리가 있는데
정말 많은 React 라이브러리가 있네요
어마어마한 양의 React 라이브러리입니다
그리고 최종적으로
context
react.dev 문서를
확인해야 하는데
맞길 바랍니다
그 다음 Vite 정보를 가져오려고 했고
Vite 정보를 많이 가져왔습니다
vitejs.vite를 선택했고, 그 다음 papa parse
CSV 파싱 라이브러리를 시도했는데
찾지 못했습니다
괜찮습니다
일부 라이브러리는 찾지 못할 수 있지만
정보를 가져오려고 시도했고
못 찾은 것뿐입니다
그리고 여기 아래에서는 찾은 문서에 대해
라이브러리 문서를 실제로 호출했습니다
여기 vite.js/vite가 있고
js/vite에 React 주제를 입력했더니
TypeScript 설정에 대한 응답이
제가 검토해봤을 때
꽤 괜찮아 보였습니다
그래서 매우 기대가 됐죠
계속 내려가보면
볼 수 있듯이
모든 문서를 가져오고 있고
그리고
결국에는 인턴 모드로 전환되어
주니어 모드와 다른 모든
필요한 작업들을 수행했지만
이 특정 실행에서는 아무것도
호출하지 않았습니다
이 특정 실행에서는
마이크로매니저만
초기 데이터를 제공했고
다른 모드들은
중급이나 시니어 모드는
필요하다고 느끼지 않았습니다
상황이 잘 작동하지 않을 때만
추가 데이터가 필요한 경우에만
호출하라고 지시했기 때문에
매번 호출하고 싶지는 않습니다.
그러면 비용만 더 들기 때문이죠.
하지만 이 모든 추가 컨텍스트로
더 높은 평가 점수로
해당 작업을 완료할 수 있을 거라 생각했는데
안타깝게도 그렇지 않았습니다.
정말 실망스러웠죠.
추가 정보가 있었기 때문에
더 나은 결과를 기대했거든요.
그래서 의문이 생겼고
사실 오래전부터 의문을 가져왔습니다.
이런 추가 컨텍스트가
실제로 얼마나 도움이 되는지
만약 컨텍스트가 문제와 직접적으로
관련이 없다면 말이죠.
예를 들어 문서의 전체 섹션을
그냥 제공하는 것이
실제로 더 나은 결과를 만드는지
확실히 알려면 수백 번의 테스트가 필요합니다.
이제 문서 모드를 사용하지 않고
실행한 테스트를 보여드리겠습니다.
문서를 전혀 가져오지 않고
동일한 프롬프트와
동일한 모델로 실행했더니
이런 결과가 나왔습니다.
실제로 작동하는 UI를 얻었고
잠시만요, 찾아보겠습니다.
CSV 파일을 제대로 로드할 수 있게 됐어요.
이건 기본적으로 제가
디버깅 중인 채팅을 로드해서
사용자들이 겪는 문제를 살펴보기 위한 것입니다.
하지만 이게 흰색 배경에
흰색 텍스트라서 보기가 좋지는 않네요.
기억이 맞다면
일부 기능들은 실제로 작동했습니다.
보이는 것을 찾아볼게요.
업데이트 시간이 표시되고
대화 LLM이 있는데
이것들이 정확히 뭘 하는지는
잘 모르겠네요.
아래쪽이 스크롤 가능한지 궁금한데
오, 보세요!
큰 스크롤바가 있네요.
하지만 공백이
정말 이상하게 되어있습니다.
흥미로운 점은
각각 두 번씩 테스트를 실행했는데
문서 모드 없이
실행했을 때와
마이크로매니저의 변경 없이 실행했을 때
작동하는 앱을 얻었다는 거예요.
보기 좋지는 않았지만요.
반면 문서 모드로 실행한
두 번 모두 앱이 작동하지 않았습니다.
물론 두 번의 테스트만으로는
비결정적 모델에서는
큰 의미가 없을 수 있지만
전반적으로 추가 컨텍스트로
더 나은 결과를 얻지 못해
실망스러웠습니다.
이게 제가 고민하는 부분인데
메모리 뱅크나
LLM에 입력될 거대한
규칙 기반을 구축하는 것에 대해
많은 논의가 있지만
저는 수익이 체감한다는 것을
발견했습니다.
더 많은 컨텍스트가
항상
더 나은 건 아니에요.
Context 7이 한 것을
발전시킬 적절한 방법을
찾고 있습니다. 그들이 하는 일은
정말 놀랍고, MCP가 나아가야 할 방향이에요.
실제로 가치 있는 정보를
함께 가져올 수 있다는 점에서요.
실제로 가치가 있죠
접근하기 쉽게 만들고
LLM과 바로 연동되어 작동하지만
이걸 어떻게 활용해서
오케스트레이터와 같은 것들에
실질적인 이점을 가져다줄 수 있을까요?
특히 오케스트레이터 모드에서는
모든 모드에 문서를
로드해야 하는 단점이 있고
또는 문서를 전부 로드하지 않고도
충분한 정보를 얻을 수 있는지
고민해봐야 합니다
정말 흥미롭습니다
Context 7에 대한 제 분석을 요약하자면
첫째로, 훌륭하고 앞으로
MCP가 구축되어야 할 방향이라고 봅니다
이것은 단순히 API 호출에 대한
가벼운 래퍼이지만
LLM이 처리할 수 있는 정말 멋진 데이터를
제공합니다. 하지만 걱정되는 점은
현재 보유한 라이브러리 수와
특히 React와 Vue에서
반환되는 라이브러리의 수입니다
이는 좀 우려되는 부분인데
잘못된 문서를 선택할 수 있다는
걱정이 있기 때문입니다
또한 문서를 가져올 때 전달되는
토픽 매개변수에 대해서도
궁금합니다. API가
실제로 어떻게 만들어졌는지
보고 싶네요
왜냐하면 뭔가 이상하게 느껴지는데
AI가 입력하는 것들과
받는 응답들 중
일부가 좀 이상하기 때문입니다
하지만 API를 그들이 제어하므로
시간이 지나면서 개선될 수 있죠
다음으로 중요한 점은
아마도 이 서비스에 대해
요금을 부과할 것 같고
저는 이런 서비스에 대해
과연 비용을 지불할 것인지
고민해봤는데 확신이 서지 않습니다
이는 즉
특히 저같은 경우 가치 상승이
꽤 상당해야
이런 서비스에 돈을 쓰고 싶을 것 같은데
제가 테스트해본 바로는
그 정도로 큰 가치를
느끼지 못했습니다. 대부분의 경우
문제가 생기면 웹 검색으로
원하는 문서를
찾을 수 있기 때문이죠. 하지만
제가 정말 좋아하는 점은
마이크로매니저에서 구상했던
문서 모드 아이디어를
계속 발전시켜 보고 싶다는 겁니다
꽤 유망해 보이거든요
약속이 되어 보이니까요
에이전트가 나가서
"제가 문서를 가져와서
당신의 질문에 답변하겠습니다"라고 하고
LLM이 "이걸 어떻게 하는지
알고 싶어요"라고 하면
문서에서 찾아서
답을 주는 거죠
문서에서 찾아서 알려주는 것
정말 멋진 아이디어지만
현실적으로는 제가
이걸 제대로 오케스트레이션할 수 있을지
현재로서는 모르겠습니다
이 영상이 부정적으로 들리지 않았으면 해요
사실 저는 이런 것들이
나올 때마다 정말 신나거든요
하지만 현실적으로 봤을 때
실제로 제 워크플로우를
개선할 수 있을지에 대해
아마도 제가 원하는 만큼은
아닐 것 같습니다만
동시에 Context 7은
멋지고 앞으로 MCP가
구축되어야 할 방향이라고 생각합니다
왜냐하면 개발자들에게
실질적인 가치를 제공하기 때문이죠
특히 LLM이 최신 프레임워크에 대해
업데이트되지 않았을 때
큰 차이를 만들 수 있을 것 같습니다
하지만 몇 가지 우려 사항이 있고
이것들이 시간이 지나면서
어떻게 확장될지 궁금합니다
잘못된 문서를 가져오는 것이 걱정되고
예를 들어 모든 문서 중에서
Vue를 어떻게 골랐는지가
흥미롭네요. 이런 식으로
항상 잘 동작할 수 있을지
지켜봐야 할 것 같습니다
요금 부과가 시작될 때까지는
계속 연결해두고 사용할 예정입니다
웹 검색을 하는 것보다
조금 더 편하다고 생각하기 때문이에요
물론 웹 검색으로도
비슷한 기능을 할 수 있지만요
여기까지 시청해 주셨다면
도움이 되었다고 생각하시면
유튜브 알고리즘에 도움이 되도록
좋아요와 구독 부탁드립니다
그럼 다음에 뵙겠습니다
안녕히 계세요