AI 아티팩트가 유용했다. 그러다 누군가 계속 사용하고 싶어 했다.

에이전트 세션에서 계산기가 나옵니다. 누군가 그 링크를 동료에게 보냅니다. 동료는 하나의 가정을 변경하고, 시나리오를 저장한 다음, 다음 주에 돌아와 보고 싶어 합니다.

이 지점에서 몇 가지 평범한 앱 결정들이 필요합니다. 현재 버전은 어디에 존재할까요? 변경 사항은 이 브라우저에서만 저장되나요? 누가 저장된 데이터를 볼 수 있나요? 모두가 사용하는 페이지를 즉시 변경하지 않고 계산을 업데이트할 수는 없을까요?

drobek은 이러한 작은 브라우저 앱들이 실행될 공간을 제공합니다.

저는 이전에 [Claude 아티팩트를 변화하는 팀 문서로 활용하는 방법]에 대해 작성한 적이 있습니다. 그 예시에서의 가치는 동료가 작업이 변경됨에 따라 돌아올 수 있는 링크였습니다. 여기서는 앱의 동작이 필요한 브라우저 아티팩트, 즉 입력값(inputs), 저장된 기록(saved records), 그리고 제어된 업데이트를 다루고 싶습니다.

첫 번째 버전은 작게 유지하세요

간단한 계획 계산기를 가져와 봅시다. 이 계산기는 총 근무 시간과 매일 이용 가능한 시간을 바탕으로 작업에 필요한 근무 일수를 추정합니다.

예시로, 24시간을 하루 6시간으로 나누면 4일이 됩니다. 이것들은 프로젝트의 측정치가 아닌 예시적인 입력값입니다. 계산은 우리가 주변 앱을 개발하는 동안 확인할 만큼 작습니다.

첫 번째 버전은 완전히 브라우저에 머무를 수 있습니다:

function estimateDays(totalHours, hoursPerDay) {
  if (!Number.isFinite(totalHours) || totalHours < 0) {
    throw new Error('Enter a non-negative number of hours.');
...

이것은 프로젝트 예측치가 아니라 산술적 추정치입니다. 주말, 의존성, 또는 방해받는 사람들을 모델링하지 않습니다. 페이지는 입력값이 정당화하는 것보다 더 큰 확신을 가지고 표시하기보다는, 그 숫자가 무엇을 의미하는지 설명해야 합니다.

만약 아티팩트가 이미 사용 가능한 HTML이나 React 소스를 가지고 있다면, 그 소스를 코딩 에이전트에게 제공하고 drobek에 맞춰 앱을 조정하도록 요청하세요. 아티팩트 공유 URL이 임포트 형식이라는 것을 가정하거나 플랫폼별 기능이 변경되지 않고 전이된다고 가정하지 마세요.

제한된 요청(A bounded request)이 도움이 됩니다:

이 계산기의 소스를 drobek에 맞게 조정하세요.
계산 및 입력 유효성 검사는 유지합니다.
원본 아티팩트 환경에 대한 의존성을 제거하세요.
...

에이전트는 앱을 생성하고, 파일을 작성하며, 컴파일 피드백을 통해 작업할 수 있습니다. 여전히 실제 페이지를 시도해 보세요. 텍스트 입력이나 오류 메시지 또는 계산은 잘못되었더라도 빌드는 성공할 수 있습니다.

저장할 가치가 있는 것이 있을 때 영속성 추가하기

사람들이 단순히 빠른 계산만 필요하다면 거기서 멈추세요. 저장된 기록 기능은 편의성뿐만 아니라 접근 결정권도 추가합니다.

개인적으로 저장되는 시나리오의 경우, 가능한 디자인 중 하나는 인증(auth) 및 데이터 모듈을 추가하는 것입니다. 로그인한 사용자가 시나리오를 생성하고 나중에 자신의 기록을 검색할 수 있습니다. 데이터 수집 규칙은 다음과 같을 수 있습니다:

{
  "read": "owner|admin",
  "create": "user",
... 
}

이는 구성된 컬렉션의 rules 객체이며, 전체 모듈 구성을 의미하는 것은 아닙니다. 여기서 owner는 기록 소유자를 지칭합니다. admin 역시 접근 권한을 가지므로, 인터페이스가 시나리오를 개인적이라고 호출한다면 이를 솔직하게 설명해야 합니다.

프론트엔드에서는 컬렉션과 인증이 구성된 후, 예시를 저장하는 데 다음 코드를 사용할 수 있습니다:

import { drobek } from 'drobek';

await drobek.data.collection('scenarios').create({
...
});

저장되는 필드에 대한 스키마를 사용하고 페이지에서도 입력을 검증하세요. 데이터 모듈은 서버에서 자체 운영 규칙을 적용합니다. 기록을 렌더링된 목록 밖에 두는 것은 접근 제어(access control)가 아닙니다.

만약 다음 요청이 공유 팀 시나리오라면, 해당 규칙들을 재고해 보세요. 모든 로그인한 사용자를 읽기 전용 사용자(reader)로 만드는 것은 각 사람이 자신의 기록을 볼 수 있도록 하는 것과는 다른 제품 결정입니다. 에이전트는 이 변경 사항이 확정되기 전에 이를 설명해야 합니다.

업데이트를 버전으로 취급하기

다음 변경 사항에서 최대 일일 용량 또는 다른 출력이 추가된다고 가정해 봅시다. 에이전트가 새 버전을 작성하고, 사용자가 미리보기를 검사한 다음, 게시할지 여부를 선택합니다.

운영(production) URL은 사용자가 작업하는 동안 이전에 게시된 코드를 계속 제공할 수 있습니다. 만약 새 코드가 잘못되었다면, 이전 버전을 게시하여 해당 코드를 복원할 수 있습니다.

하지만 앱의 기록은 미리보기(preview)와 운영 환경 간에 공유됩니다. 실제 저장된 시나리오를 수정하는 미리보기 테스트는 실제 데이터를 수정합니다. 코드 롤백(Code rollback)은 이러한 쓰기 작업(writes)을 되돌리지 못합니다. 데이터 격리 실험이 필요한 경우에는 별도의 앱을 사용하십시오.

이미지 또는 기타 바이너리 자산의 경우, drobek에는 별도의 자산 업로드 흐름(asset-upload flow)이 있습니다. 이들은 거대한 base64 문자열로 write_files에 포함되어서는 안 됩니다. 원래 아티팩트가 의존했던 자산을 검토하고 필요한 곳에 대체품을 제공하십시오.

유지보수되는 앱도 소유자가 필요하다

결과를 호스팅한다고 해서 모델의 원래 분석이 정확해지는 것은 아닙니다. 만약 아티팩트에 추정치(estimate), 권장 사항, 또는 데이터 기반 결론이 포함되어 있다면, 그 가정(assumptions)과 출처 날짜를 보이게 유지해야 합니다. UI뿐만 아니라 증거(evidence)도 업데이트하십시오.

그리고 일부 아티팩트는 문서로 남아 있어야 합니다. 주요 목적이 의사결정과 그 추론을 보존하는 것이라면, 리포지토리나 문서 시스템이 더 나은 장소가 될 수 있습니다. 계산기 예제는 사람들이 상호작용하고 지속적인 상태(persistent state)가 필요할 수 있기 때문에 앱으로 분류됩니다.

drobek에서는 에이전트의 수정 사항들이 미리보기로 컴파일되어, 동료들이 사용하는 운영 URL을 변경하기 전에 확인할 수 있습니다. 브라우저 전용 도구로 시작하여 특정 필요가 생길 때 백엔드 모듈을 추가할 수 있습니다. 갤러리에서 제가 구상하는 앱의 규모를 볼 수 있으며, 코어는 오픈 소스입니다.