스크린샷 API 뒤의 운영을 사업으로 만들다: ScreenshotOne

고객에게 보이지 않은 경보

2025년 7월 17일, ScreenshotOne을 운영하던 드미트로 크라순(Dmytro Krasun)에게 이상한 경보가 울렸다. 실제 브라우저로 웹페이지를 불러와 화면을 캡처하는 점검 작업에서 시간 초과가 발생했다는 알림이었다. 다른 감시 장치에는 문제가 없었고, 고객들의 요청도 평소처럼 처리되고 있었다. 크라순은 고객에게 드러나지 않은 문제를 찾아 며칠 동안 잠을 설쳤다.

그는 요청량과 서버 부하를 확인하고, 최근 수정한 코드를 되돌리고, 네트워크 연결까지 검사했다. 원인을 좁혀 보니 점검 대상으로 사용하던 외부 웹사이트의 접속이 불안정했다. 캡처 대상을 자신의 서비스 소개 페이지로 바꾸자 정상적으로 작동했다. 그는 이 일을 계기로 직접 통제할 수 있는 점검 환경의 필요성을 확인하고 진단 도구를 보완했다.

캡처 한 장 뒤의 처리 작업

크라순이 2022년 5월 출시한 ScreenshotOne은 다른 프로그램이 웹 주소나 HTML을 보내면 스크린샷이나 PDF 같은 결과물을 돌려주는 API였다. 그는 창업 전 10년 넘게 서버와 대규모 요청을 처리하는 시스템을 개발했다. 사람들이 이미 돈을 내고 이용하는 스크린샷 시장을 선택했고, 브라우저 운영과 화면 생성 과정에서 생기는 문제를 자신이 맡기로 했다. 고객은 자신의 제품에 필요한 이미지를 요청하고, 그 뒤에서 벌어지는 작업은 ScreenshotOne에 넘길 수 있었다.

개발자가 직접 스크린샷 기능을 만드는 데 사용할 도구는 이미 있었다. Puppeteer나 Playwright로 브라우저를 자동 조작하면 웹페이지를 열고 이미지를 저장할 수 있었다. 여기에 페이지 전체를 캡처하려고 하면 스크롤한 뒤에 나타나는 이미지를 불러와야 했고, 쿠키 동의창이 본문을 덮으면 이를 처리해야 했다. 화면 크기와 저장 위치까지 고객의 요구에 맞추면서, 처음의 짧은 코드는 여러 조건을 다루는 서비스로 커졌다.

ScreenshotOne은 이런 조건을 처리하는 경험을 제품 안에 쌓았다. 공식 제품 소개에 따르면 쿠키 배너를 정리하는 데 사용하는 규칙과 판별 방식은 5만 개가 넘는다. 고객은 광고나 채팅창을 숨기고, 필요한 경우 페이지의 스타일과 동작을 조정할 수 있다. 개별 개발팀이 비슷한 문제를 각각 해결하는 대신, 전문 서비스가 축적한 처리 방법을 함께 사용하는 구조였다.

협업용 피드백 도구 BugSmash의 사례는 개발팀이 어느 지점에서 비용을 지불하는지 보여준다. 사용자가 검토할 웹사이트 주소를 입력하면 BugSmash는 대시보드와 공유 링크에 사용할 미리보기 이미지를 만들어야 했다. 이 이미지는 사용자에게 바로 보이므로 팝업에 가려지거나 늦게 생성되는 문제가 중요했다. BugSmash는 이 작업에 ScreenshotOne을 사용했다. 반면 별도의 웹사이트 평가 기능에는 Puppeteer를 사용하고 있었는데, 2025년 4월 공개한 사례에서 서버 관리와 여러 캡처의 동시 처리가 부담이라고 설명했다.

BugSmash는 사용자가 의견을 남기는 순간의 화면을 기록할 때에는 또 다른 방법을 썼다. 움직이는 요소의 위치나 열려 있는 팝업까지 담아야 했으므로 사용자 브라우저 안에서 캡처하거나 확장 프로그램을 이용했다. 같은 제품에서도 미리보기 이미지 생성과 사용자의 현재 화면 기록은 요구 조건이 달랐다. ScreenshotOne이 맡은 영역은 서버에서 반복적으로 웹페이지를 열고, 제품에 사용할 이미지를 안정적으로 만들어 주는 일이었다.

연동 과정도 개발자의 시간을 절약하도록 구성했다. 시작 안내에는 웹 주소와 접근 키를 넣어 요청하는 예제가 나오며, 개발 언어별 연동 코드도 제공된다. 고객은 대시보드의 실험 화면에서 옵션을 바꾸며 결과를 확인할 수 있다. 오류가 발생하면 프로그램이 구분할 수 있는 오류 코드와 사람이 읽을 수 있는 설명을 함께 반환하므로, 고객의 개발팀이 실패 원인을 처리하기도 쉬워진다.

사용량과 비용을 맞추는 인프라

요금은 작은 사용량으로 시작해 실제 필요에 따라 늘릴 수 있게 설계했다. 2026년 9월 기준으로 매월 100회의 무료 캡처를 제공하며, 월 17달러인 기본 요금제에는 2,000회, 월 79달러인 성장 요금제에는 1만 회가 포함된다. 포함된 사용량을 넘기면 요금제별 단가로 추가 비용을 지불한다. 기본 요금제에서도 전체 페이지 캡처, 광고와 쿠키 배너 차단, PDF 생성 같은 기능을 사용할 수 있어, 고객은 필요한 처리량을 중심으로 지출을 결정할 수 있다.

과금 규칙에는 실패와 재사용도 반영했다. 네트워크나 브라우저 오류로 실패한 요청은 사용량에서 차감하지 않으며, 저장된 결과를 그대로 반환하는 캐시 응답도 새 캡처로 계산하지 않는다. 이 구조에서는 실패율을 낮추고 이미 만든 이미지를 재사용하는 작업이 고객의 만족도와 운영자의 비용에 함께 영향을 준다. 크라순은 이 관계를 실제 운영 과정에서 배워야 했다.

초기에는 Cloudflare를 통해 요청을 전달하고, 이미 생성한 스크린샷을 캐시에 저장해 재사용했다. 그런데 저장된 이미지가 캐시에서 사라지면 같은 요청을 처리하기 위해 브라우저를 다시 실행해야 했다. 당시 고객에게 무료로 제공하던 캐시 요청에서 실제 화면 생성 비용이 발생했고, 크라순은 이 때문에 돈을 잃고 있었다고 설명했다. 그는 파일 저장 서비스 R2를 두 번째 저장 계층으로 추가해, 가까운 캐시에 이미지가 없더라도 저장소에서 찾아 반환하도록 바꿨다.

이후 요청을 앞단에서 처리하는 Cloudflare Workers의 역할도 넓어졌다. 잘못된 요청과 유효하지 않은 접근 키를 먼저 확인하고, 허용된 요청량을 넘었는지 검사해 불필요한 작업이 브라우저 서버까지 도달하지 않게 했다. 주 서버가 과부하 상태이거나 화면 생성에 실패하면 다른 데이터센터로 요청을 보냈다. 고객이 웹 주소 하나를 보내는 동안, 서비스 내부에서는 요청을 어디서 처리하고 어떤 결과를 재사용할지 결정하는 작업이 진행됐다.

고객의 업무에 들어간 API

이런 기반 위에서는 같은 고객과의 거래가 여러 해 이어질 수 있었다. 영업용 맞춤 영상을 만드는 RepliQ는 2026년 7월 공개한 사례에서 ScreenshotOne을 약 4년 동안 사용했다고 밝혔다. 잠재 고객의 웹사이트나 프로필을 이미지와 움직이는 GIF로 만들어 영상 배경에 넣는 용도였다. RepliQ는 자체 캡처 시스템을 관리하는 일을 줄이고 영상 개인화 작업에 집중할 수 있었으며, 자사 서비스가 성장하는 동안에도 연동을 유지했다고 설명했다.

크라순은 스크린샷 API를 직접 만드는 방법도 공개했다. 그의 개발 안내에는 요청 검증, 쿠키 배너 처리, 전체 페이지 캡처, 저장소 업로드와 배포까지 들어 있다. 독자는 직접 구현할 수 있는 범위와 추가로 관리해야 할 작업을 함께 보게 된다. 이런 문서는 잠재 고객에게 기술을 설명하는 동시에, 직접 운영할지 전문 서비스에 맡길지 판단할 재료를 제공한다.

개발 과정을 꾸준히 공개해 온 일은 제품 채택에도 영향을 줬다. AI 작업 자동화 서비스 Toolhouse의 공동창업자 올랜도 칼로사카스는 초기부터 X와 Indie Hackers에서 크라순의 활동을 지켜봤다. 그는 웹페이지 캡처 기능이 필요해졌을 때 ScreenshotOne이 가장 먼저 떠올랐으며, 다른 서비스를 비교할 필요도 거의 느끼지 않았다고 말했다. 당장 구매할 이유가 없던 사람이 제품의 변화를 지켜보다가, 자신의 업무에 필요해진 시점에 선택한 사례였다.

Toolhouse의 연동 과정에서는 문서와 실험 화면이 다시 역할을 했다. 칼로사카스는 ScreenshotOne의 문서를 AI 도구에 제공해 구현 절차를 정리하고, 대시보드에서 옵션을 시험했다. 연동 후에는 Toolhouse 사용자가 자신의 ScreenshotOne 접근 키를 연결해 AI 작업자에게 웹페이지를 캡처하고 분석하게 할 수 있었다. 기존의 화면 생성 기능이 AI 서비스에 시각 자료를 공급하는 용도로 확장된 것이다.

혼자 운영할 범위를 정하다

크라순은 돈을 내겠다는 요청이 들어와도 제품의 범위를 따져 보았다. 시간에 따른 스크린샷 비교 기능은 여러 차례 시험했지만, 의미 없는 차이를 변화로 판단하는 오류를 줄이기 어렵고 별도의 제품에 가깝다고 보았다. 웹사이트 전체를 돌아다니며 보관하는 기능도 고객의 요구와 운영 방식이 달라진다는 이유로 추가하지 않았다. 그는 기존 기능이 제대로 작동하도록 집중하는 쪽을 선택했다고 설명했다.

판매 과정에서는 고객을 이해하는 데 예상보다 오래 걸렸다. 2026년 인터뷰에서 크라순은 자신이 누구에게 제품을 팔고 있는지 파악하는 데 2년이 걸렸고, 그 이해가 홍보 문구와 콘텐츠, 개발 항목, 가격에 영향을 줬다고 말했다. 이후에는 방문자가 가입하고, 가입자가 유료 고객이 되는 과정을 유입 경로별로 살폈다. 방문자가 부족한 경우와 방문자는 있지만 가입하지 않는 경우를 구분하고, 문제가 생기는 단계부터 수정하는 일이 매출 성장에 도움이 됐다고 설명했다.

운영을 계속하려면 크라순 본인의 일상적인 개입도 줄여야 했다. 그는 2024년 3월 사업 비용 전용 카드를 마련하고, 정산금이 그 카드의 결제 계좌로 자동 입금되도록 설정했다고 공개했다. 요청량에 따라 서버를 늘리는 환경을 구성하고, 다른 클라우드에 예비 실행 환경도 준비했다. 비용 결제와 서버 증설처럼 반복적으로 필요한 일을 자동화해, 자신이 잠시 자리를 비워도 서비스가 돌아가도록 만드는 작업이었다.

필요한 전문 작업에는 외부의 도움도 활용했다. 현재 공식 소개에서 크라순은 제품을 직접 개발하고 운영하면서 특정 프로젝트에 전문가들과 협업한다고 설명한다. 제품 방향과 고객과의 관계는 자신이 맡고, 필요한 작업에는 다른 사람의 역량을 더하는 창업자 중심의 운영 방식이다.

2026년 3월 인터뷰 당시 ScreenshotOne의 유료 고객은 800명을 넘었고, 월 반복매출(MRR)은 2만 5,000달러 이상이었다. 이후 출시 4주년을 맞아 공개한 수치는 유료 고객 1,000명 이상, 월 반복매출 3만 3,000달러였다. 누적 API 호출도 1억 건을 넘었다. 웹페이지를 이미지로 바꾸는 기능이 여러 제품의 일상적인 작업에 포함되면서, 고객의 반복 사용이 구독 사업을 지탱했다.

크라순은 4주년 회고에서 아이들의 중요한 행사를 거의 놓치지 않았다는 점을 자신의 성과로 꼽았다. 그해 인터뷰에서는 인터넷에 접속하지 않고 일주일 동안 등산을 다녀올 수 있을 만큼 운영을 자동화하고 싶다는 목표도 밝혔다. 다른 개발팀이 캡처 시스템에 쓰던 시간을 돌려준 사업에서, 이제는 자신의 시간을 더 확보하는 일이 다음 과제로 남아 있었다.