안녕하세요. 플레이라이트 CLI가 무엇인지 보여드릴게요. 플레이라이트 패밀리의 새로운 도구입니다.00:00

이 영상에서는 플레이라이트 CLI가 무엇인지 알아보고, MCP와 비교하며 데모를 보여드리고, 토큰 효율성, 그리고 몇 가지 기능들을 살펴보겠습니다. 부디 이 영상을 통해 앞으로 어떤 도구를 사용해야 할지 더 좋은 판단을 내리시는 데 도움이 되셨으면 좋겠습니다.00:05

시범을 시작하도록 하겠습니다.00:20

이것은 Playwright CLI 기능 시연입니다. 빈 폴더인 Demo CLI에서 시작하며, Playwright CLI를 전역적으로 설치하도록 하겠습니다.00:23

그러면 모든 지역에서 사용 가능하게 된다는 뜻입니다. 그리고 제가 가장 먼저 하는 일은 작업 공간을 초기화하는 것입니다.00:33

Playwright CLI 설치라고 말씀드리는 건, Playwright이라는 빈 폴더를 만드는 것을 의미합니다. 이것만 있으면 돼요.00:38

이걸로 컴퓨터 디스크 안에서 여러 작업 공간을 구분할 수 있습니다.00:45

각 워크스페이스는 사용할 브라우저 세트가 따로 있습니다. 더 자세한 내용은 나중에 말씀드릴게요. 이 워크스페이스에 몇 가지 스킬을 설치하고 싶습니다.00:49

설치 기능을 호출했는데, 제 작업 공간에 클로드를 여러 가지 기능과 함께 설치하고 있습니다.00:58

클로드를 시작해서 작업(task)을 하나 맡겨볼게요. 플레이라이트 개발 도구(Playwright Dev)라는 웹페이지를 열어서, 로케이터(locator)라는 단어를 검색하고, 각 언어별로 문서(doc)가 있는지 확인하는 작업을 시킬 예정입니다.01:04

그리고 언어는 자바스크립트, 파이썬, 자바, 보트넷 등 다양한 언어에 대해 지원하는 것을 의미합니다. 각 언어 문서에 대한 스크린샷을 찍어달라고 요청했으니, 어떻게 실행되는지 한번 살펴봅시다. 우리가 보고 있는 것은01:16

16배속으로 보여주는 작업 과정을 담은 타임랩스입니다. 클로드가 CLI 유틸리티를 사용하여 브라우저와 대화하는 과정이었습니다.01:30

결과를 한번 살펴볼까요.01:38

컨텍스트를 확인해서 사용한 토큰 수를 볼 수 있지만, 여기서는 오래 머무르지 않고 MCP 버전의 동일한 작업을 진행하겠습니다.01:41

제가 시작할게요. 클로드, 여기 MCP 서버가 설치되어 있는 게 보이네요. Playreg MCP가 설치되어 있고, 이 폴더에는 스킬이 설치되어 있지 않아서, 제가 똑같은 작업을 다시 해볼 거예요.01:52

그리고 다시, 16배 타임랩스로 완료되었네요. 여기 컨텍스트 통계를 열어서 토큰을 얼마나 사용했는지 확인해 볼까요.02:05

네, 여기에서 확인되는 것은 이 작업에 114,000 토큰을 사용했는데, 비용이 상당히 많이 듭니다.02:19

CLI로 진행했던 작업과 비교해 보겠습니다. CLI는 26,800 토큰을 사용했습니다.02:29

데모에서 봤듯이 MCP가 더 많은 컨텍스트를 사용한 것을 알 수 있습니다. 그런데 왜 그럴까요? 좀 더 자세히 알아봅시다. MCP가 무엇을 하고 있었는지 확인해 보겠습니다.02:39

자, 이제 이 두 가지 호출을 좀 더 자세히 살펴볼까요? 먼저, 페이지로 이동하려고 시도했었죠. 그리고 Playwright 개발 환경은 DocuSource 페이지입니다. 꽤 큰 편이고, 콘텐츠도 많고, DOM, 컨트롤, 스크립트 등도 많이 포함하고 있습니다.02:49

비록 Playwright MCP가 LLM에 접근성 스냅샷만 전달하는 데 매우 효율적이지만, 그래도 전체 내용을 응답했습니다. 그 모든 정보가 컨텍스트 윈도우에 들어가게 되었고, 여기에서 볼 수 있듯이 결과가 최대 토큰 수를 초과했습니다.02:58

그리고 나서 스크린샷을 찍었는데요. 그런데 MCP가 스크린샷을 찍을 때, LLM이 그렇게 하라고 요청하기 때문에, 그 바이트들을 LLM에게 그대로 전달하고 있습니다. 다시 한번 말씀드리지만, 이미지 토큰들이 컨텍스트에 들어가게 됩니다. 그리고 이번 경우에는 그게 목표가 아니었습니다.03:14

스크린샷을 캡처해서 디스크에 저장하는 것뿐이었어요. CLI가 무엇을 하고 있었는지 비교해 봅시다.03:28

CLI에서 위치로 이동하겠다는 요청을 받았는데, 스냅샷을 캡처하거나 디스크에 생성된 스냅샷 파일을 읽는 과정 없이 바로 스크린샷을 찍어 해당 파일을 저장했습니다.03:33

그 결과, 문맥이 보존되었습니다. 이러한 토큰들은 LLM이 실제로 필요로 하지 않기 때문에 포함되지 않았습니다. 따라서 CLI가 내보내는 모든 데이터는 파일에 저장됩니다.03:44

그리고 나서 코딩 에이전트는 LLM에 접속해야 하는지 여부를 결정하게 됩니다.03:56

기능에 대해 이야기해 봐요. 저희는 MCP가 어떻게 작동하는지 봤는데, MCP는 단지 몇십 개의 명령어만 사용했다는 것을 알게 될 거예요. 그리고 저희가 그런 명령어를 가지고 있지 않아서 그런 게 아니에요.04:01

저희는 그걸 가지고 있습니다. 사실, 모든 CLI 기능이 MCP를 통해서도 제공되고 있습니다. 다만, 컨텍스트를 소모하기 때문에 기본적으로 활성화하지 않습니다.04:10

반면에 CLI에서는 그러한 제약이 없습니다. 그래서 이러한 명령어들을 전부다 더 많이도 노출할 수 있습니다. 네.04:18

토큰 사용량도 살펴봤고, 기능에 대해서도 이야기했으니, 이제는 당연한 선택이겠죠. CLI를 사용해야 하는 거 아닌가요? 조금 더 자세히 알아봅시다.04:25

CLI가 새로운 도구이고, 그 점이 훌륭합니다. 거기서 효율적으로 사용할 수 있습니다.04:36

저희는 그 스냅샷들을 캡처해서 디스크에 저장하고, 스크린샷을 디스크에 저장한 다음, 코딩 에이전트가 전체를 읽을지, 아니면 LLM으로 전체를 보낼지 결정하도록 할 수 있습니다. 그렇게 하면 토큰을 효율적으로 사용할 수 있습니다. 따라서 CLI는 효율적이기 위해서는 코딩 에이전트가 필요합니다.04:51

그 외에는 기술 기반이며, Playwright와 작업 시나리오에 대한 지식을 기술에 추가할 수 있습니다. 그래서 다른 기술 기반 도구와도 호환되게 사용할 수 있습니다.05:04

기본적으로 헤드리스 상태로 설정되어 있는데, 코딩 에이전트 내에서 많은 백그라운드 에이전트를 실행할 것이라고 가정하기 때문입니다. 반면에 MCP는 어떤 제너릭 에이전트와도 함께 작동할 수 있습니다.05:12

매우 엄격한 기준이며, 기존 도구들은 어떤 결과를 기대해야 하고, 이러한 MCP 도구를 어떻게 불러야 하는지 알고 있습니다. 하지만 이번 경우에는 모든 것이 LLM의 판단에 달려 있으므로, 답변 역시 대부분 LLM에 의해 결정될 가능성이 높습니다.05:23

LLM으로 다시 돌아가서 컨텍스트를 압도할 가능성이 있습니다. MCP에서는 여러 브라우저를 문제없이 사용할 수 있으며, MCP의 효율성을 구성하여 어떤 도구를 허용하거나 차단할 수 있습니다.05:34

그 점에서는 조금 더 수동적으로 진행될 수 있습니다. 또한, MCP는 기본적으로 그렇게 설정되어 왔습니다.05:49

요약하자면, 코딩 에이전트를 사용하시거나, 작업이 코딩 및 테스트와 관련된 경우, 클라우드, 깃허브, 코파일럿 등을 사용하신다면 CLI를 사용하는 것이 좋습니다. 반면에, 에이전트 루프를 작성하시는 경우에는요.05:53

특정 시나리오 작업을 수행할 때는 MTP가 여전히 최선입니다. 이것으로 충분합니다. 즐겁게 테스트하세요.06:05