저는 Octomind를 구매하지 않았습니다. 대신 0유로로 직접 만들었습니다. 왜 이것이 더 나은지 알려드립니다.

저는 개발자가 아닙니다. 저는 네덜란드의 헬스 AI 플랫폼인 Longevity AI를 운영하고 있습니다. 유료 사용자, 컴플라이언스 게이트 (compliance gate), 3개의 언어, 그리고 매주 계속해서 성장하는 코드베이스를 보유하고 있습니다.

그리고 지난달 저는 Octomind를 발견했습니다. 이는 Playwright 테스트를 자동으로 생성하고 스스로 치유(self-heals)하는 AI 기반의 e2e (end-to-end) 테스트 플랫폼입니다. 제안 내용은 매력적이었지만, 가격은 그렇지 않았습니다. 월 200~500유로 이상이었습니다.

그래서 저는 직접 만들었습니다.

저는 이것을 Muraqib (مراقب)라고 불렀습니다. 아랍어로 "관찰자"라는 뜻입니다. 이것은 매일 밤 실행됩니다. 스스로를 수정합니다. 그리고 비용은 0유로입니다.

이것이 왜 옳은 결정이었는지 그 이유를 말씀드리겠습니다.

Octomind가 하는 일 (그리고 잘하는 일)

공정하게 말하자면, Octomind는 진정으로 인상적입니다. URL을 입력하면 사이트를 크롤링(crawl)하고, Playwright 테스트를 자동으로 생성하며, UI가 변경될 때 설정 파일을 건드리지 않고도 깨진 셀렉터(selector)를 치유합니다. 대시보드에서는 모든 테스트 실행의 비디오 녹화본을 보여줍니다. GitHub와 10분 만에 통합됩니다.

팀 단위라면 아마 그만한 가치가 있을 것입니다. 테스트 유지보수에서 절약되는 시간만으로도 규모가 커지면 비용을 정당화할 수 있습니다.

하지만 저는 팀이 아닙니다. 저는 규제 산업에서 SaaS를 운영하는 1인 기업입니다. Octomind가 실제로 제공하는 것과 제가 실제로 필요로 하는 것을 비교해 보았을 때, 계산이 맞지 않았습니다.

범용 QA 도구의 문제점

범용 도구가 제 사이트에 대해 알지 못하는 점은 다음과 같습니다:

제 블로그는 클라이언트 사이드 라우팅 (client-side routing)을 위해 Wouter를 사용합니다. 모든 블로그 기사는 <a href> 링크가 아니라 onClick 핸들러가 포함된 <article> 요소입니다. 범용 크롤러는 a[href*="/blog/"]와 같은 셀렉터를 생성할 것이고, 이는 첫날부터 실패할 것입니다. 기능이 고장 나서가 아니라, 도구가 페이지가 실제로 어떻게 작동하는지 이해하지 못하기 때문입니다.

저의 welzijnscheck 퍼널은 두 개의 서로 다른 페이지로 구성되어 있습니다. /welzijnscheck에 있는 랜딩 페이지(landing page)와 /welzijnscheck/:code에 있는 실제 설문지(questionnaire)입니다. 랜딩 페이지에서 양식(form)을 찾는 테스트는 매번 실패할 것입니다. 이는 버그가 아닙니다. 단지 도구가 문맥(context)을 파악하지 못하는 아키텍처(architecture) 때문입니다.

이것들은 예외적인 사례(edge cases)가 아닙니다. 맞춤형으로 구축된 SaaS의 일반적인 상태입니다. 범용 도구(Generic tools)는 범용적인 테스트를 생성합니다. 범용적인 테스트는 범용적이지 않은 코드베이스(codebases)에서 실패합니다.

Muraqib이 다르게 작동하는 방식

Muraqib은 제 코드베이스를 알고 있습니다. 왜냐하면 코드베이스로부터 구축되었기 때문입니다.

모든 테스트 스펙(test spec)의 모든 셀렉터(selector)는 크롤러(crawler)가 작동한다고 가정하는 방식이 아니라, 제 애플리케이션이 실제로 작동하는 방식을 반영합니다. welzijnscheck 흐름을 위해 테스트가 작성될 때, Muraqib은 /welzijnscheck가 CTA 버튼이 있는 랜딩 페이지라는 것과 양식이 완전히 다른 경로(route)에 있다는 것을 알고 있습니다. 그 지식은 크롤링(crawling)에서 오는 것이 아닙니다. 소스 코드(source)를 읽는 것에서 옵니다.

자가 치유(self-healing) 기능도 동일한 방식으로 작동합니다. 테스트가 실패하면, Claude Code가 실패 내용을 읽고, 관련 스펙을 읽고, 프로덕션 코드(production code)를 읽습니다. 제안하는 수정 사항은 패턴 매칭(pattern-matched)을 통한 셀렉터 교체가 아니라, 전체 문맥(full context)을 이해하는 것에 기반합니다.

그것이 바로 당신의 URL을 아는 도구와 당신의 코드베이스를 아는 도구의 차이입니다.

수치

	Octomind	Muraqib
월간 비용 (Monthly cost)	€200-500+	€0
...

€0이 핵심이 아닙니다. 핵심은 **코드베이스 인지 능력(codebase awareness)**입니다.

주간 이메일

제가 내린 설계 결정 중 다른 곳에서는 본 적 없는 것이 하나 있습니다. Muraqib은 저에게 일주일에 이메일을 딱 한 통 보냅니다. 실패할 때마다 보내는 것도 아니고, 테스트를 실행할 때마다 보내는 것도 아닙니다. 딱 한 통입니다.

매주 월요일 08:00에 저는 요약본을 받습니다. 이번 주 실행 횟수, 통과율(pass rate), 무엇이 실패했는지, Claude가 무엇을 수정했는지, 그리고 제가 검토해야 할 어떤 PR(Pull Request)들이 열려 있는지 말입니다.

그게 전부입니다. 그 외의 모든 일은 저 없이도 진행됩니다.

대부분의 모니터링 도구들은 가시성 (Visibility)을 최적화합니다. 더 많은 대시보드, 더 많은 알림, 더 많은 인사이트를 제공하죠. 저는 침묵 (Silence)을 최적화했습니다. 저는 Muraqib이 문제를 해결하려고 시도한 이후에만 그 문제에 대해 알고 싶습니다.

자가 치유 루프 (The Self-Healing Loop)

새벽 3시에 테스트가 실패하면 다음과 같은 일이 일어납니다:

1. GitHub Actions가 전체 실패 컨텍스트 (Failure context)를 포함한 이슈 (Issue)를 생성합니다.
2. 해당 이슈가 @claude를 태그합니다 — 그러면 Claude Code GitHub App이 이를 감지합니다.
3. Claude가 실패한 테스트, 에러 메시지, 그리고 관련 프로덕션 코드 (Production code)를 읽습니다.
4. Claude가 수정 제안이 담긴 풀 리퀘스트 (Pull Request)를 엽니다.
5. 저는 월요일 아침에 이를 검토하고, 30초 만에 머지 (Merge)합니다.

이것은 마법이 아닙니다. 그저 잘 연결된 파이프라인 (Pipeline)일 뿐입니다. 하지만 그 결과로 저의 테스트 스위트 (Test suite)는 장애 알림의 빈도가 아니라, 저의 검토 역량에 맞춘 주기에 따라 스스로 치유됩니다.

제가 포기한 것들

트레이드오프 (Trade-offs)에 대해 솔직해지고 싶습니다.

저는 아름다운 UI를 포기했습니다. Octomind는 통과/실패 이력, 시각적 차이 (Visual diffs), 그리고 모든 테스트 실행 영상이 포함된 제대로 된 대시보드를 갖추고 있습니다. 저의 "대시보드"는 GitHub Actions 로그와 월요일 아침에 오는 이메일입니다. 일주일에 한 번 상태를 확인하는 1인 창업자에게는 괜찮습니다. 하지만 매일 배포를 수행하는 팀에게는 그렇지 않을 것입니다.

저는 자동 테스트 생성 기능을 포기했습니다. Octomind는 사이트를 크롤링하여 테스트를 작성합니다. 저는 (Claude를 사용하여) 직접 수동으로 작성했습니다. 이는 초기에 몇 시간의 작업이 필요했습니다. 그 대가로 모든 테스트는 제가 테스트하고자 하는 의도를 정확히 반영하며, 어떠한 가정 (Assumptions)도 포함하지 않습니다.

저는 즉각적인 실패 알림을 포기했습니다. Octomind는 몇 분 내에 알림을 보낼 수 있습니다. 저는 일주일에 한 번 확인합니다. 이 방식이 작동하는 이유는 Claude가 제 주의가 필요하기 전에 문제를 해결하려고 시도하기 때문입니다. 만약 귀하의 비즈니스 모델이 즉각적인 장애 대응 (Incident response)을 요구한다면, 이 접근 방식은 귀하에게 맞지 않습니다.

소유권 (Ownership)이 중요한 이유

하지만 제가 놓쳤을 수도 있는 부분은 다음과 같습니다:

제가 블로그 라우팅 (routing)을 앵커 태그 (anchor tags)에서 wouter의 setLocation() 핸들러 (handler)로 업데이트했을 때, 제 테스트 (tests)들은 깨졌을 것입니다. Octomind를 사용했다면 지원 티켓 (support ticket)을 제출하거나 자가 치유 (self-healing) 기능이 따라잡을 때까지 기다려야 했을 것입니다. Muraqib의 경우, Claude가 직접 변경 사항을 만들었기 때문에 라우팅 변경 사항을 이미 알고 있었습니다. 수정 사항은 동일한 PR (Pull Request) 안에 있었습니다.

이것이 바로 소유권 (ownership)이 갖는 복리 효과 (compounding advantage)입니다. 기능을 구축한 도구가 바로 그 기능을 테스트하고, 고장 났을 때 수정하는 동일한 도구가 되는 것입니다. 코드가 수행하는 작업과 테스트가 기대하는 작업 사이에 번역 계층 (translation layer)이 존재하지 않습니다.

이름 (The Name)

Muraqib (مراقب)는 아랍어로 "관찰자 (the observer)" 또는 "감독자 (the supervisor)"를 뜻합니다. 신성한 이름이 아니라, 그저 무게감이 있는 단어일 뿐입니다. 이는 도구가 수행하는 역할과 일치합니다: 조용히 지켜보다가, 무언가 잘못되었을 때만 행동하는 것.

"그는 당신이 보지 못하는 것을 봅니다. 그는 당신이 잊어버린 것을 알아차립니다. 그는 소리 지르는 경비원이 아닙니다. 그는 고치는 경비원입니다."

Longevity AI는 longevityai.nl에서 운영됩니다. 규제 산업에서 헬스 SaaS (health SaaS)를 구축하고 있으며 의견을 나누고 싶다면, 사이트를 통해 연락하실 수 있습니다.

이 기사는 원래 Longevity AI에 게시되었습니다. 전체 맥락, 참조 및 토론을 확인하려면 출처를 방문하세요.