내 웹사이트에는 이제 두 개의 타겟 오디언스가 있습니다. 하지만 나는 그중 하나만을 위해 구축했습니다.

누가 당신의 웹사이트를 읽는가에 대한 논의가 변화하고 있습니다. 이제 에이전트 (Agents)가 그 흐름의 일부가 되었습니다. ChatGPT는 URL을 가져옵니다. Perplexity는 콘텐츠를 읽습니다. 쇼핑 에이전트 (Shopping agents)는 구매를 완료하려고 시도합니다. 코딩 에이전트 (Coding agents)는 당신의 API를 호출합니다. 이러한 제품 대부분은 인간을 위해 만들어졌고, 인간을 대상으로 테스트되었습니다. 에이전트들은 나중에 조용히 등장했습니다. 에이전트들은 무언가를 파악할 수 없을 때 불평하지 않습니다. 그저 떠나버릴 뿐입니다.

저는 you.com이 호스트 중 하나였던 해커톤에서 "두 번째 오디언스 (second audience)"라는 문구를 들었습니다. 그 말이 머릿속에 남았습니다. 그것이 바로 에이전트입니다. 웹이 설계되지 않았고, 측정 기준조차 마련되지 않은 두 번째 오디언스 말입니다.

이제 저는 이에 관한 무언가를 만들고 싶습니다. AI 에이전트가 당신의 웹사이트나 API를 사용하려고 할 때 무엇을 경험하는지 알려주는 스캐너입니다. 내부 명칭은 Perseus Clew이며, 공개 제품명은 Agentis Lux입니다. 이 구분은 의도적입니다. Perseus Clew는 엔진 이름이자 AI 빌더 도구 제품군의 일부이며, Agentis Lux는 에이전트 사용자가 보게 될 기능을 설명하는 제품 중심 명칭(라틴어로 "에이전트의 빛"이라는 뜻)입니다.

이것은 출시 게시물이 아닙니다. 저는 방금 문서화 단계를 마쳤고, 이제 코드를 작성하려 합니다. 코드를 작성하기 전에, 이 내용을 dev.to의 빌더들에게 보여주고 제가 놓치고 있는 것이 무엇인지 알고 싶습니다.

기능 설명

세 가지 레이어:

결정론적 스캐닝 (Deterministic scanning). 12가지 체크 카테고리 — 프론트엔드용 6개, API용 6개 — 를 통해 HTML, ARIA, 구조화된 데이터 (structured data), OpenAPI 명세 (OpenAPI specs), 에러 응답 (error responses), 멱등성 패턴 (idempotency patterns)을 살펴봅니다. 동일한 입력에는 매번 동일한 점수가 부여됩니다. 방법론은 공개될 것이며, 가중치 (weights) 또한 공개되어 누구나 감사 (audit)할 수 있습니다. AI 준비도 점수 산정 도구들은 수치를 부풀리고 방법론을 숨긴다는 평판이 있으므로, 모든 것을 검사 가능하게 만드는 것이 신뢰의 기초가 될 것입니다. 그것이 나머지 기능들이 구축될 토대입니다.

AI가 작성한 판결 (An AI-written verdict). 점수가 나온 후, Bedrock 호출을 통해 주요 발견 사항을 읽고 에이전트(Agent)가 무엇을 경험하는지에 대해 한 문장을 작성합니다. 예를 들면 다음과 같습니다: "이 페이지를 방문하는 에이전트는 제품 설명을 읽을 수 있지만, 어떤 버튼이 결제를 시작하는지 알 수 없으므로 스스로 구매를 완료할 수 없습니다." 이 문장은 사람이 가장 먼저 읽게 되는 내용입니다. 숫자는 그 아래에 뒷받침되는 증거입니다.

에이전트 시뮬레이션 (An agent simulation). Bedrock은 스캔된 콘텐츠를 대상으로 구조화된 작업(Structured tasks)을 실행하고 다음과 같이 보고합니다: 에이전트가 할 수 있는 것은 이것이고, 할 수 없는 것은 이것입니다. 발견 사항을 스프레드시트가 아닌 하나의 이야기로 변환합니다.

점수는 결정론적 (Deterministic)입니다. 설명은 AI가 생성하며 그렇게 표시되고, 시뮬레이션은 그 위에 얹어진 서사 계층 (Narrative layer)입니다. 각 계층은 자신의 역할에 걸맞은 가치를 얻습니다: 일관성이 중요한 곳에는 수학을, 판단이 도움이 되는 곳에는 AI를, 에이전트가 실제 작업을 완료할 수 있는지 알아야 하는 곳에는 시뮬레이션을 사용합니다.

구현 모습

결과 보기 화면입니다 — 가상의 데이터이며, 실제 디자인입니다. 고정된 팔레트는 Lance Wyman에서 영감을 받은 크림색, 딥 틸 (Deep teal), 시에나 (Sienna) 색상입니다. 타이포그래피는 Archivo Black과 AI 문구를 위한 Instrument Serif 이탤릭체를 조합했습니다. 점수는 왼쪽에 하나의 단위로 표시됩니다.

[

]

"AI 작성 (AI written)" 태그는 의도적인 것입니다. 독자가 어떤 부분이 모델에서 왔고 어떤 부분이 수학에서 왔는지 볼 수 있기를 바랍니다.

왜 B2B인가

무료 익명 스캔은 입구 역할을 합니다. 진정한 가치는 로그인 계층에 있습니다: 시간이 지남에 따라 점수를 추적하고, 변경 사항을 배포한 후의 변화량 (Delta)을 확인하며, 궁극적으로 CI에서 실행하여 모든 PR (Pull Request)이 병합되기 전에 Agentis Lux를 거치도록 만드는 것입니다.

저는 H0 해커톤 (hackathon) B2B 트랙에 참여 중이며 (마감일 6월 29일), 과정을 함께 지켜보고 싶으시다면 h01.devpost.com에서 제출물을 확인하실 수 있습니다.

스택 (Stack)

Vercel 기반의 Next.js를 사용합니다. API 라우트 (API routes)가 스캔 시작과 DynamoDB 직접 읽기를 처리합니다. 스캔 엔진에는 AWS Lambda를 사용하며, AI 부분에는 Bedrock을 사용합니다. 벤치마크 데이터에는 DynamoDB를 사용하며, 공유 가능한 링크가 작동하도록 24시간 TTL (Time To Live)이 적용된 휘발성 결과 데이터도 함께 저장합니다. 월간 벤치마크 갱신에는 EventBridge를 사용합니다. AWS 측 구성에는 TypeScript 기반의 CDK (Cloud Development Kit)를 사용하며, 로컬에서 모두 실행할 수 있도록 Docker를 사용합니다.

설계상 두 개의 DynamoDB 테이블을 사용합니다. 하나는 타겟 사이트에 과도한 부하를 주지 않기 위한 15분 단위의 URL 해시 캐시 (URL-hash cache)이고, 다른 하나는 공유 가능한 링크를 위한 24시간 유효한 불투명 ID (opaque-id) 결과 저장소입니다. 서로 다른 키, 다른 수명, 다른 목적을 가집니다. 이 둘을 하나로 합칠지 고민을 많이 했지만, 수명이 일치하지 않기 때문에 분리하는 방향으로 결정했습니다.

Kiro로 구축되었습니다.

불확실한 부분 — 그리고 도움이 필요한 부분

제가 모르는 세 가지가 있습니다:

인증 스텁 (auth stub)의 범위가 적절한가, 아니면 너무 많이 혹은 너무 적게 배포하고 있는가? 저는 인증 (이메일 매직 링크), 가입 시 생성되는 사용자 테이블, 그리고 빈 상태 (empty state)로 렌더링되는 스캔 이력 뷰를 구축하고 있지만, 추세 차트 (trend charts)와 시간에 따른 점수 (score-over-time) 기능은 제외했습니다. 이는 두 가지 깔끔한 대안의 중간 지점에 위치합니다. 더 작은 버전은 인증을 완전히 건너뛰고, 조회를 위한 스캔당 이메일 링크를 생성하는 것입니다. 더 큰 버전은 인증을 배포한다면, 실제 반복적인 가치 (recurring value)인 추세 차트까지 함께 배포하는 것입니다. 저는 추세 추적을 MVP (Minimum Viable Product)에 포함시키지 않으면서도 "단 한 번의 스캔에 관심을 갖는 사람이 누구인가"라는 질문에 답할 수 있다고 생각하여 중간 지점을 선택했습니다.
시간에 따른 점수 추적을 위해 비용을 지불하시겠습니까? 익명의 일회성 스캔은 쉽습니다. 비즈니스적인 질문은 반복적인 가치 (recurring value)입니다. 솔직해져 봅시다. 당신이 현재 만들고 있는 것을 만들면서, 개인적으로 에이전트 준비도 (agent-readiness)에 대해 추세 추적을 원할 만큼 충분히 관심을 두고 있습니까?
결과만 보여주고, 해결책은 제안하지 않음. 현재 제품은 에이전트가 보는 것을 드러냅니다 — "에이전트는 당신의 버튼이 버튼인지 알 수 없습니다" — 하지만 그에 대해 무엇을 해야 하는지는 알려주지 않습니다. 왜냐하면 그것은 당신의 코드베이스 (codebase)를 알아야 한다는 것을 의미하기 때문입니다. 저는 이것이 해결 방법을 지시받지 않으면서도 가시성 (visibility)을 원하는 빌더 (builders)들을 위한 기능이라고 생각합니다. 또한 이것은 좌절한 사용자가 탭을 닫게 만드는 요인이 될 수도 있습니다. 어느 쪽일까요?

다음 단계

이번 주에 Block 0가 시작됩니다. 첫 번째 엔드 투 엔드 (end-to-end) 배포는 다음과 같습니다: Vercel 기반의 Next.js, AWS 기반의 스캔 Lambda, 모의 데이터 (mock data)로 렌더링되는 결과 히어로 (result hero), 그리고 스텁 (stub) 처리된 DynamoDB 쓰기 접점 (write seam). 실제 URL을 대상으로 첫 번째 실제 스캔이 실행되면 다시 게시하겠습니다.

만약 유사한 것을 구축하고 있거나, 카테고리로서의 에이전트 준비도 (agent-readiness)에 대한 의견이 있다면, 여러분의 이야기를 듣고 싶습니다.

AI 보조. 인간 승인. NLP 기반.

H0 Hackathon을 위해 제작됨. #H0Hackathon