Transcription
이상 >> 설정 하나 바꾸면 클로드 코드가 900배 빨라진다. 토큰도 엄청나게 절약된다. 이런 글이 돌고 있습니다. 30에서 60초 대비 0.05초. 진짜요? 900배 좀 심한 거 아닌가? 그래서 직접 해 봤습니다. 세팅하고 실제 프로젝트에서 돌려보고 진짜 그런지 검증해 봤어요. 결론부터 말하면요. 예상과는 좀 달랐습니다. 그럼 얘가 정말 클러드 코드 기어를 올려 주는 거냐, 패급인 거냐 끝까지 보시면 아실 겁니다.
자, 그래서 이 900배의 정체가 뭐냐면요. 바로 LSP 랭귀지 서버 프로토콜입니다. 이름은 어려운데 우리가 이미 매일 쓰고 있어요. VS 코드에서 함수 위에 마우스 올리면 정보 뜨죠. 그게 LSP고요. 고투 데피니션 누르면 바로 점프하죠. 그것도 LSP고 빨간 밑줄 뜨면서 야 이거 틀렸어 해 주는 거 그것도 LSP입니다. 근데 지금까지 클러드 코드는 이걸 안 쓰고 있었어요. 코드를 그냥 글자로 보고 그래로 찾고 있었던 거죠.
이 LSP를 클러드 코드에서도 켤 수 있다는 겁니다. 근데 숨겨져 있어요. 이스터 에그처럼. 본격적으로 검증하기 전에 지금 클러드 코드가 코드를 어떻게 찾는지 먼저 보여 드릴게요. 클러드 코드한테 이 함수 어디 있어? 물어보면요. 얘는 그램 명령칩니다. 파일 하나하나 다 열어보죠. 여러분이 터미널에서 그램 마이너스 알치는 거랑 똑같아요. 유저 클래스 어디 있냐고 물어보면요. 정의 한 개 찾자고 결과를 수백개 뒤집니다. 변수명, 주석, 임포트, CSS, SQL까지 전부 다 걸려요. 그걸 하나하나 이건 아니고 이것도 아니고 하면서 읽습니다.
자, 한번 보실까요? 프로바이더스. 점겟 타입이 뭐냐고 물었습니다. 그러면 클로드가 찾겠죠? 자, 보시면 서치하면서 파일 하나하나 검색해서 비교합니다. 이러면 읽을 때마다 결과에 따라 쓸데없는 토큰을 많이 먹을 수 있겠죠. 제 MCP 영상 보신 분들은 아실 겁니다. 세레나 MCP라고 이 문제를 해결하려고 나온 프로젝트가 있었거든요. 근데 설치도 복잡하고 메모리도 많이 먹고 솔직히 좀 귀찮았죠. 어, 이제 그럴 필요 없습니다. 클로드 코드에 이미 들어 있거든요. 그냥 꺼져 있었을 뿐이에요.
자, 그러면 이걸 키우고 진짜 빨라지는지 2분 만에 세팅하고 직접 확인해 봅시다. 셋업은 세 단계입니다. 진짜 2분이면 끝나요.
첫 번째 LSP 도구 활성화를 먼저 해야죠. 클로드 세팅스 제이슨 열어서 이걸 추가합니다. 이게 이상하게도 설정이 공식 문서에 없습니다. 기터브 이슈에서 커뮤니티가 찾아낸 히든 플래그예요. 그래서 이스터 에그라고 한 겁니다. 설치 영상으로 바로 볼게요. 자, 이렇게 자기가 편한 에디터나 VS 코드로 여시고요. 저는 후킹 쪽에 이미 깔려 있어서 복잡해 보이죠? 별거 아닙니다. 끝에 이렇게만 추가해 주시면 됩니다. 간단하죠?
두 번째 언어 서버와 클로드 코드 플러그인 설치합니다. 쓰시는 언어에 맞는 언어 서버를 깔아야 합니다. VS 코드에서 쓰는 거랑 똑같은 거예요. 본인 언어에 맞는 것만 깔면 됩니다. 저는 파이썬과 타입 스크립트를 주로 사용합니다.
세 번째 플러그인 설치도 하시면 됩니다. 이러면 세팅 제이슨에 이 내용들이 포함되어 나오게 되고요.
네 번째는 클로드를 한번 시작하거나 재시작해 줍니다. LSP 서버는 시작할 때 초기가 됩니다. 설정 바꾸고 플러그인 깔았으면 반드시 클로드 코드 재시작하세요. 제대로 됐는지 확인하려면요. 그램 명령어로 클로드 코드 디버그로를 보면 됩니다. 여기서 이렇게 나오면 성공입니다. 이분도 안 걸리죠?
자, 이제 진짜 검증입니다. LSP 켜기 전이랑 후를 직접 비교해 보겠습니다. 좀 코드 베이스가 있는 네스트 JS 레포를 클론할게요. 스트 레포를 다 가져오는 거라서 시간이 좀 걸리죠? 다 받아줬네요. 다 받았으면 클로드를 실행시켜 보고요. 첫 번째 테스트를 해 볼게요. 프로바이더스겟의 타입이 뭐야? LSP 없이 찾아봐라고 한번 물어봅니다. 자, 이렇게 찾는게 보이죠? 서치 세 번에 리드까지 하고 찾네요. 어 뭐지? 생각보다 너무 빠르네요. LSP로 하도록 시켜 보겠습니다. 프로바이더스 개세 타입이 뭐야? LSP 써서 찾아. 아 여기 LSP 사용하네요. 호버 한 번에 끝이긴 하네요. 출론된 타입까지 바로 보여 줍니다. 그랩은 이것까진 못 하죠. 생각보다 속도 차이는 없어서 당황스럽긴 한데 레스트 소스도 요즘 컴퓨팅 성능엔 너무 작고 소중한 소스인가 보네요. 아무튼 잘 작동은 하는 거 같고요. 그럼 한번 심볼 찾기도 테스트해 볼게요. 심볼 목록 보여줘. 깔끔하게 한 방에 끝나긴 하긴 하네요. 그랩이었으면 파일 읽고 하싱하고 패턴 매칭하고 토큰도 많이 먹긴 할 텐데 이밖에도 다른 프로젝트와 40만 줄의 타입이 잘 정리가 안 된 프로젝트에서도 테스트해 봤습니다.
근데요. 솔직히 말씀드리면요. 속도는 별 차이는 없는 거 같아요. 오히려 데피션이 제대로 안 된 프로젝트는 그랩이 검색 면에선 났습니다. 클러드 코드가 내부적으로 예전 그랩이 아닌 립 그랩을 씁니다. 이게 미친 듯이 빠른 검색 엔진이에요. 기시근노도 반영해서 알아서 무시하고요. 스트 JS 정도 규모에서는 립그랩으로도 수초면 찾아 버려서 이 정도 규모로는 속도 체감은 안 되고요. 블로그에 900배 빨라진다. 쓰레드엔 혁명이다. 이런 걸 보고 저도 기대를 엄청했거든요. 근데 직접 해 보니까요. 대부분 코드 베이스에서는 내장 립그랩이 충분히 빠릅니다. 속도 면에선 조금은 과장이 있었던 거 같네요.
그러나 벗 근데요 별 쓸모 없냐? 전혀 그건 아닙니다. LSP가 진짜 빛나는 순간이 있어요. 첫 번째 타입 출론. 코드에 타입이 안 적혀 있어도 LSP는 출론된 타입을 바로 알려 줍니다. 그랩은 이거 못 해요. 정의를 따라가서 직접 찾아야 합니다. 두 번째 같은 이름이 수백개일 때 개시라는 메서드가 열 개 클래스에 있으면 그랩은 전부 섞여서 나오는데 LSP는 딱 그 클래스의 갭만 찾아줍니다. 세 번째 리팩토링 할 때 에러 자동 감지. 이건 진짜 좋았어요. 함수 시그니처 바꾸면 호출보 에러를 즉시 잡아 줍니다. 핑퐁 없이 원턴에 끝나요. 이게 킬링 포인트가 아닌가? 생각되네요. 그래도 세팅 2분인데 켜놓고 손해 볼 건 없으니깐요. 속도나 토큰양보다 코드 리팩토링 시 에러 잡을 때 출론을 훨씬 도와줄 것 같습니다. 하나의 도구를 더 네이티브로 지어 주니까요. 확실히 기어 올려 주는 건 맞는 거 같아요.
한 가지 LSP를 켜놔도 클로드가 안 쓸 수 있어요. 왜냐면 클로드 입장에서는 그랩도 있고 글롭도 있고 LSP도 있고 도구가 여러 개인 거예요. 그중에 뭘 쓸지는 클로드가 판단하는데 익숙한 쪽으로 갑니다. 그래로요. 사람이랑 똑같죠. 세도구저도 습관적으로 옛날 거 쓰는 거고요. 해결법은 간단합니다. 클로드 MD의 위상황엔 LSP 먼저 써라고 적어 주면 됩니다. 봐주셔서 감사합니다.