안티봇 우회를 벤치마크로 내세우는 건 꽤 비윤리적으로 보임. 안티봇의 목적은 원치 않는 봇을 막는 것인데, 이런 서비스는 결국 웹을 더 사람에게 불친절하고 비싸게 만듦
사이트들은 자동화 접근을 계속 막으려 할 것이고, 콘텐츠 접근 장벽은 더 늘어날 것임. 웹에서 신원 확인 요구가 커지는 이유도 나이 제한이나 “아이들 보호”만이 아니라 봇 방어와 광고 수익 보호까지 포함된 상위 효과로 보임

웹사이트 변경 감지에 이런 도구를 씀. 좋아하는 작가들 중 RSS가 없는 경우가 있고, 큰 가전 같은 고가 물건은 가격 변화를 보려고 항상 가격 모니터링을 설정함
API가 없는 사이트에서는 스크레이퍼도 쓰고, 구매 내역 전체를 데이터베이스에 색인해 분석할 수 있게 해 둠. 멍청한 봇 탐지를 우회하는 데 더 많은 시간을 쓰고 싶진 않으며, 다른 방법으로 접근할 수 없는 데이터라면 기꺼이 비용을 낼 의향도 있음. 어차피 스크레이퍼가 이길 수밖에 없는 고양이와 쥐 게임에 자원을 태우는 셈임

공개 웹사이트 스크레이핑이 비윤리적인지는 논쟁의 여지가 있음. 어떤 경우에는 사이트가 기술적 장벽을 세우거나 중지 요구서를 보내도 법원이 합법이라고 본 적도 있음
다만 주거용 프록시를 제공하는 건 비윤리적일 가능성이 큼. 그런 프록시의 주거 회선 제공자들은 자신이 그런 서비스에 편입됐다는 사실을 모르는 경우가 많음

남이 원하지 않는 일을 한다는 이유만으로 비윤리적이라고 보긴 어려움. 이유와 의도가 중요함
어떤 공연 티켓을 얻으려고 24시간 컴퓨터 앞에 앉아 있을 수 없을 때, 좋아하는 밴드 티켓을 사기 위해 개인 봇을 쓰는 게 비윤리적이라고 보긴 어려움. 반대로 암표상 목적이라면 비윤리적이라는 데 동의함. 안티봇의 안티봇은 남들이 자동화되면 안 된다고 보는 일을 가능하게 하려는 것이고, Hacker News 독자 중 꽤 많은 사람이 한 번쯤은 이런 일을 해봤을 것 같음. 순전히 이익 목적이면 별로지만, 암표상과 맞설 기회를 얻기 위한 용도라면 괜찮아 보임

웹으로만 접근 가능하고 API 지원이 부실하거나 없는 소프트웨어를 자동화하는 회사들을 알고 있음. 보통 꽤 큰돈을 내고 쓰는 소프트웨어인데, 로그인 보호용 캡차가 내장돼 있음
여러 SaaS 테넌트 중 하나일 뿐이라 캡차 제거를 요구할 만큼 큰 고객도 아니어서, 그냥 그 제약을 우회함

자기 헤드리스 브라우저가 차단되지 않기를 원하는 사람들이 씀

여기서 빠진 부분은 일반 EC2 인스턴스의 중첩 가상화가 올해 2월부터 가능해졌다는 점임. 그 전에는 Firecracker VM을 실행하려면 metal EC2 인스턴스를 써야 했음

꽤 새로운 기능이고, 공식적으로는 아직 권장되지 않지만 지금까지는 아주 잘 동작함. 드디어 베어메탈을 돌리지 않아도 됨

metal 인스턴스는 시작과 중지가 엄청 느림

이 정도까지 해놓고도 여전히 Chromium을 고수한 게 조금 놀라움
우리의 web-access MCP 서버[0]는 훨씬 단순한 구성으로 브라우저 인스턴스를 하위 프로세스로 띄우는데, 안정성·CPU·메모리 사용량에서 가장 큰 개선은 Chrome에서 Lightpanda[1]로 바꿨을 때였음. 글 끝의 말처럼 더 빨리 뜨는 브라우저는 애초에 메모리를 덜 할당하는 브라우저일 수도 있음
[0]: https://github.com/EratoLab/web-access-mcp
[1]: https://lightpanda.io

스텔스 목적 때문에 Chromium을 엔진으로 유지하기로 했음
LightPanda 같은 브라우저는 스텔스가 전혀 없고 탐지가 아주 쉬움. 필요 없는 것을 제거하면 Chromium도 더 빠르게 만들 방법이 있음. 처음부터 엔진 전체를 새로 만들지 않고도, 최우선순위인 스텔스를 잃지 않으면서 Chromium이 그 성능에 도달할 수 있다고 봄. 언어가 문제는 아니며 C++도 Zig만큼 성능이 좋지만, Chromium의 비대함은 크다는 데 동의함

ApiFlash라는 스크린샷 API를 운영하는데, EC2의 Firecracker 대신 AWS Lambda 컨테이너 이미지에 Chromium을 패키징해서 씀
AWS Lambda는 격리와 자동 확장을 공짜로 제공하므로 스크린샷처럼 부하가 튀는 무상태 작업에 이상적임. browser-use 솔루션과 거의 같은 이점을 얻으면서 아키텍처는 훨씬 단순하다고 봄. 트레이드오프는 AWS Lambda 콜드 스타트지만, 실제로는 연속 호출에서 뜨거운 함수를 재사용함. 충분한 호출량이 있으면 피크가 완화되고 콜드 스타트도 그리 자주 일어나지 않음

우리가 만든 기능이 모든 사용 사례에 필요한 건 아님
Lambda에서 겪은 문제는 실행 시간 제한이 15분이라는 점, 가격, 스냅샷 메커니즘 부재, 실행 호스트에 대한 저수준 제어 부족이었음. 우리는 최대 4시간을 지원하고 필요하면 더 길게도 실행 가능함. 그래도 대부분의 일반적인 웹 자동화 사용 사례에는 Lambda면 충분하고도 남음

그 솔루션은 꽤 비싸 보임

“다음: Chromium 시작 건너뛰기”라고 했는데, 이미 실행 중인 브라우저 묶음을 웜 풀로 유지해 들어오는 요청에 할당하면 안 되나 싶음
사용자 입장에서는 지연 시간이 거의 0에 가까울 것임. 트래픽 패턴에 따라 웜 풀을 늘리거나 줄이는 예측 로직은 필요하겠지만, 가장 쉬운 해결책처럼 보임

웜 풀은 동작하지만, 목표는 그것 자체를 대체하는 것임
웜 풀은 좋지만 결국 리소스를 소비하고, 풀을 항상 따뜻하게 유지하며 균형을 맞추기 위해 브라우저를 계속 시작해야 함. 앞으로의 변경으로 Chromium 시작을 유지하면서 VM이 50ms 안에 준비되게 만들어 웜 풀을 완전히 이길 계획임. 일부 고객은 특수 파라미터와 기능을 필요로 해서 웜 풀 복잡도가 커짐. 일반 경로는 빠르겠지만 예외 경로는 매우 느려질 수 있는데, 요청한 브라우저에 어떤 기능이 필요하든 빠른 속도를 보장하고 싶음

Firecracker는 훌륭한 기술임. 코딩 인터뷰와 개인 작업공간용 격리 런타임을 실행하는 면접 스타트업에서 쓰고 있는데, 매우 안정적이고 놀라울 만큼 가벼움
Go SDK로 연동하는 것도 아주 쉬웠음

userfaultfd가 더 많이 쓰이는 걸 보니 멋짐. 페이지 폴트가 발생할 때 메모리를 어떻게, 어디서 불러올지 완전히 제어할 수 있어서 정말 강력한 API임

일반 EC2도 이미 VM이라는 점은 맞지만, 하이퍼바이저 접근을 제공해서 Firecracker도 가능한 특정 EC2가 있는 것으로 알고 있음. 틀렸다면 정정 바람

꽤 큰 머신, 즉 AWS metal 인스턴스가 필요했을 때 metal과 같은 크기의 VM 사이에서 CPU 중심 작업 성능 차이가 10~20% 정도였음

Firecracker가 왜 필요한지 궁금함. 그냥 컨테이너에서 직접 실행하면 안 되나? 격리 우려는 이해하지만, 브라우저와 컨테이너 탈출 조합이면 10억 달러짜리 CVE 아닌가?

성숙하거나 보안 의식이 높은 제공자 대부분은 컨테이너를 안전한 격리 경계로 보지 않음. Microsoft는 예외로 보이지만, 내부 정책 실패인지 정책 집행 역량 부족인지는 불분명함
컨테이너는 VM보다 훨씬 넓은 공격 표면을 제공하고, 업계 표준상 안전하다고 보지 않기 때문에 컨테이너 탈출 CVE 관리에 투입되는 자원도 VM 탈출보다 적을 가능성이 큼

커널 메일링 리스트를 보면 컨테이너 탈출 익스플로잇은 요즘 거의 매주 나옴

마이크로VM은 스냅샷을 찍고 롤백할 수 있음. 컨테이너에서 이렇게 한다는 건 들어본 적이 없음

이걸 .metal이 아닌 인스턴스에서 하려면 커널 패치가 필요하지 않나? PVM 패치가 필요한 것 같음