context7
기억으로 API를 짜지 않고, 문서를 읽고 짠다.
무엇인가
라이브러리 공식 문서를 그 자리에서 읽어오는 MCP 서버다. 에이전트가 useEffect 대신 뭘 써야 하는지, 이 옵션 이름이 뭐였는지를 기억에서 꺼내지 않고 문서에서 찾는다.
Playwright가 화면을 보는 눈이라면, 이건 문서를 보는 눈이다. 둘 다 같은 문제를 푼다. 모델이 아는 척하는 걸 막는 것.
왜 필요한가
모델은 학습이 끝난 시점까지의 세상만 안다. 그런데 라이브러리는 그 뒤로도 계속 바뀐다.
문제는 모델이 모른다고 말하지 않는다는 데 있다. 옛 API를 그럴듯한 문법으로 써낸다. 실행하면 그때 터진다. 심지어 안 터지기도 한다. deprecated인 채로 잘 돌다가 다음 메이저 버전에서 사라진다.
이건 프롬프트로 못 막는다. "최신 문법으로 써줘"라고 부탁해도, 모델이 아는 최신은 학습 시점의 최신이다. 본인이 낡았다는 걸 모르는 상태라 스스로 의심할 수도 없다.
언제 쓰고 언제 안 쓰나
이 도구는 전부 다 쓰면 오히려 손해다. 문서를 끌어오면 컨텍스트를 먹고, 매번 조회하면 느려진다.
쓰는 게 맞을 때는 대체로 이렇다.
- 버전에 민감한 API를 쓸 때. 특히 메이저 버전이 최근에 올라간 라이브러리
- 설정 파일의 옵션 이름처럼, 틀리면 조용히 무시되는 것
- 마이그레이션. 뭐가 없어졌는지는 기억으로 답하면 안 된다
- 처음 쓰는 라이브러리. 아는 척할 재료 자체가 없을 때
반대로 안 써도 되는 자리도 분명하다. 언어 기본 문법, 몇 년째 안 바뀐 안정적인 API, 그리고 이미 이 저장소 안에 같은 패턴이 있는 경우. 마지막이 중요한데, 내 코드베이스에 답이 있으면 그걸 읽는 게 문서보다 정확하다. 우리 프로젝트의 관례까지 같이 따라오기 때문이다.
같은 라이브러리를 이 저장소에서 이미 쓰고 있다면, 문서를 조회하기 전에 그 코드를 먼저 본다.
공식 문서는 일반적인 사용법을 알려주지만, 이 프로젝트가 그 라이브러리를 어떻게 감싸 쓰는지는 모른다. 문서대로 짜면 동작은 하는데 주변 코드와 결이 다른 것이 생긴다.
그라운딩이라는 같은 패턴
이 도구를 따로 놓고 보면 "문서 조회기"지만, 다른 것들과 같이 놓으면 하나의 패턴이 보인다.
- RAG는 내 데이터에서 찾은 근거 위에 답을 세운다
- Playwright는 화면을 직접 봐서 지금 상태를 확인한다
- context7은 공식 문서를 읽어 API를 확인한다
- 동향 파이프라인은 수집한 원본만 읽게 해서 출처를 지어낼 재료를 없앤다
전부 같은 말이다. 모델에게 "지어내지 마"라고 부탁하는 대신, 확인할 것을 손에 쥐여준다. 앞은 지켜지길 바라는 것이고 뒤는 구조다.
정직한 한계
문서가 최신이라고 해서 그 문서가 맞다는 보장은 없다. 공식 문서도 틀리고, 예제가 실제 동작과 다른 경우도 있다.
그리고 조회한 문서를 모델이 제대로 읽었는지는 별개 문제다. 가져온 것과 이해한 것 사이에는 여전히 틈이 있다. 결국 돌려봐야 안다.