하지만 화면이 API를 호출하고 데이터를 표시하며 공유 링크를 갖는 순간, 그것은 더 이상 “대화 결과”가 아닙니다. 권한, 데이터 보존, 변경 이력, 폐기 책임이 생기는 임시 내부도구입니다. 이 글은 10월 30일 개발 뉴스의 생성형 캔버스 맥락, 에이전트 툴 오류 계약, 위임 권한과 execution receipt, 툴 권한 manifest와 runtime attestation을 바탕으로, 속도를 잃지 않는 운영 경계를 제안합니다.

이 글에서 얻는 것

• 생성형 캔버스 결과물을 채팅, 읽기 전용 내부도구, 쓰기 가능한 workflow로 나누는 기준을 얻습니다.
• 사용자 broad token을 재사용하지 않고 좁은 capability와 tool manifest로 권한을 설계하는 방법을 배웁니다.
• 소유자·만료일·데이터 등급·실행 근거를 최소 metadata로 남겨 고아 화면을 줄일 수 있습니다.
• 팀 규모에 맞는 2주 파일럿과 승격·폐기 기준을 수치로 정할 수 있습니다.

핵심 개념/이슈

1) 생성된 UI의 위험은 코드 크기가 아니라 실행 표면에서 나온다

“SQL 한 번을 보기 좋게 그린 대시보드”와 “고객 상태를 수정하고 메일을 보내는 화면”은 모두 생성형 캔버스에서 나올 수 있지만, 같은 승인 절차를 적용할 이유는 없습니다. 위험을 가르는 질문은 코드가 AI가 썼는지, 화면이 예쁜지가 아닙니다. 비신뢰 입력을 받는가, 개인·고객 데이터를 읽는가, 외부 write를 하는가, 다른 사람이 링크로 접근할 수 있는가, 실패 뒤 상태를 확인할 수 있는가입니다.

첫 분류는 세 단계면 충분합니다.

T2를 허용한다고 생성된 화면에 사용자의 cloud token이나 브라우저 세션을 넘겨도 된다는 뜻은 아닙니다. “내가 할 수 있는 모든 것”을 위임하는 토큰은 프롬프트 오류, 링크 공유, UI 변경 하나로 권한 경계가 사라지게 합니다. tool 호출은 resource, action, tenant, expiry, rate_limit을 가진 작은 capability로 한정하고, 서버가 manifest 밖의 호출을 거부해야 합니다.

2) 프롬프트는 요구사항 초안일 뿐, 정책은 실행 전에 고정한다

“지난주 장애를 요약해 줘”라는 요청은 처음에는 단순해 보입니다. 그러나 어떤 incident 저장소를 읽을지, 고객 이름을 보여도 되는지, 집계 기준은 무엇인지, 결과를 어디에 저장할지 정하지 않으면 캔버스는 자연어의 빈칸을 임의로 채우게 됩니다. 이때 필요한 것은 긴 사전 승인 문서보다 실행 전 읽을 수 있는 작은 manifest입니다.

tool_surface: incident-summary-canvas
owner: platform-oncall
expires_at: 2026-11-07T10:06:00+09:00
data_class: internal_aggregated
tools:
  - name: query_incident_metrics
    action: read
    fields: [severity, started_at, duration_minutes, service]
    tenant_scope: platform
storage:
  output_ttl_days: 7
  external_sharing: denied
write_actions: []

manifest의 핵심은 예쁜 YAML이 아니라 서버 검증입니다. UI가 query_incident_metrics 대신 raw SQL 도구를 호출하거나 허용 필드 밖의 attribute를 요청하면 거부돼야 합니다. 모델이 “이번만 예외로”라고 설명해도 policy가 바뀌지 않게 하는 장치입니다. 정책 예외 ledger처럼 예외가 필요하면 별도 request와 만료를 남기고, 성공한 우회가 기본 동작으로 굳지 않게 합니다.

3) 임시라는 말에는 자동 폐기와 재인증이 포함돼야 한다

빠르게 만든 내부 화면의 가장 큰 위험은 초기에 실패하는 것이 아니라, 유용해서 계속 쓰이는데 owner와 전제가 사라지는 것입니다. data source가 바뀌고 API scope가 넓어지고 공유 링크가 전달되면, 3개월 전의 실험은 조용한 production dependency가 됩니다. “임시”를 선언했다면 생성 시점부터 만료 이후의 행동을 정해야 합니다.

T0는 14일, T1은 7일, T2는 24시간처럼 기본 TTL을 짧게 두고, 연장은 owner 재확인·manifest 재검증·최근 실행 목적 확인을 통과할 때만 허용합니다. 30일 동안 실행이 없거나 owner가 퇴사·팀 이동으로 비활성화되면 자동 disable하고 기록만 남깁니다. 연장이 잦은 도구는 폐기 실패가 아니라 승격 후보입니다. 사용 빈도, 영향도, 실패율, 변경 이력을 보고 정식 서비스의 repository·test·on-call로 옮기는 것이 맞습니다.

실무 적용

1) 2주 파일럿은 한 업무·한 데이터 등급·한 종료 경로로 좁힌다

처음부터 “누구나 무엇이든 만드는 플랫폼”을 열지 마세요. 최근 2주 안에 반복됐고, 사람이 수동으로 30분 이상 쓰며, 읽기 전용으로도 가치가 나는 업무 하나를 고릅니다. 예를 들어 on-call의 주간 incident 요약, billing 팀의 집계 조회, 고객 지원의 정책 문서 탐색이 후보입니다. 고객 원문, production write, secret 직접 접근은 첫 파일럿에서 제외합니다.

성공 지표도 생성 수가 아니라 운영 효용으로 둡니다. 두 주 동안 10회 이상 실제 사용, 수동 준비 시간 30% 이상 감소, 권한 거부·데이터 노출·무설명 오류 0건, 만료·폐기 작업 100% 완료를 시작 기준으로 잡을 수 있습니다. 화면이 멋져도 10번 중 7번 사람이 데이터를 다시 확인해야 한다면 제품 승격보다 입력 계약과 원천 데이터 품질을 고치는 편이 낫습니다.

2) 실행 결과는 자연어 성공 메시지가 아니라 receipt로 남긴다

“요약을 만들었습니다”라는 문장만으로는 어떤 데이터 시점, 어떤 filter, 어떤 도구 호출이 결과를 만들었는지 알 수 없습니다. 특히 T2 workflow에서는 성공·실패·부분 완료를 같은 성공 문구로 덮으면 재실행이 중복 외부 효과를 만들 수 있습니다. 에이전트 툴 오류 계약의 원칙처럼 실행 결과는 상태와 다음 행동을 구조화합니다.

run_id: canvasrun_01JQ8...
canvas_version: 12
manifest_version: 4
input_hash: sha256:...
tool_calls: 3
result: completed
data_snapshot_at: 2026-10-31T09:55:00+09:00
output_ref: artifact://canvas/...
expires_at: 2026-11-07T10:06:00+09:00

receipt에는 원문 prompt·access token·고객 데이터 전문을 넣지 않습니다. hash, version, 안전한 artifact reference로 충분합니다. write가 있는 경우에는 target fingerprint, idempotency key, 승인 reference, rollback 방법을 추가하고 started_unknown 같은 불확실한 상태를 표현해야 합니다. receipt가 없으면 T2는 성공으로 닫지 않는다는 규칙이 재실행 사고를 크게 줄입니다.

3) 승격 기준을 미리 정해 shadow product를 방치하지 않는다

생성형 캔버스가 30일에 20회 이상 사용되고, 3명 이상이 의존하며, T1 이상의 capability가 지속적으로 필요하면 더 이상 개인 실험으로 취급하지 마세요. 다음 세 가지 중 하나를 선택합니다.

1. 승격: repository, test fixture, owner rotation, on-call, 정식 auth를 갖춘 내부 제품으로 옮긴다.
2. 축소: aggregate-only data와 T0/T1 read scope로 줄여 임시도구로 계속 운용한다.
3. 폐기: 더 안전한 기존 대시보드·workflow 링크를 남기고 capability와 artifact를 만료한다.

특히 승격은 UI 코드를 복사하는 작업만이 아닙니다. manifest가 실제 backend authorization에 강제됐는지, 오류 code가 사용자 재시도 규칙을 설명하는지, source data의 freshness와 retention을 계약으로 옮겼는지 확인해야 합니다. 그 과정을 건너뛰면 생성형 속도로 만든 shadow product가 정식 운영의 사각지대가 됩니다.

트레이드오프/주의점

모든 캔버스에 정식 서비스와 같은 설계 검토를 요구하면 가장 유용한 작은 개선도 사라집니다. 반대로 “내부용”이라는 이름으로 broad credential, 영구 링크, 무기한 보관을 허용하면 내부도구는 가장 빠른 데이터 유출·권한 오남용 경로가 됩니다. 균형점은 위험도에 비례한 기본값입니다. T0는 빠르게 만들고 빨리 지우며, T1은 읽기 범위와 보존을 좁히고, T2는 사람이 결과와 rollback을 확인합니다.

또한 generated UI가 복잡한 의사결정을 자동화한다고 착각하면 안 됩니다. 데이터 정합성, 정책 예외, 고객 영향 판단은 화면보다 원천 계약과 책임자가 결정합니다. 캔버스가 답을 만들었다는 사실보다 입력 데이터의 snapshot 시각, 누락 필드, 권한 범위, 실행 실패가 사용자에게 드러나는지가 신뢰도를 좌우합니다.

체크리스트 또는 연습

• 캔버스마다 owner, 데이터 등급, tool manifest, 만료일, 공유 정책이 있다.
• broad user token 대신 대상·action·tenant·만료가 좁은 capability를 사용한다.
• T1 이상은 조회·도구 호출·산출물 수명에 대한 receipt를 남긴다.
• T2 write는 승인 reference, idempotency, 상태 조회, rollback 경로를 갖는다.
• 7~14일 기본 만료 뒤 연장은 owner 재확인과 manifest 재검증을 요구한다.
• 30일 미사용 또는 owner 부재 캔버스는 자동 disable하고 artifact 보존 정책을 적용한다.
• 반복 사용 도구는 정식 제품으로 승격·축소·폐기 중 하나를 선택한다.

연습으로 팀에서 매주 반복하는 읽기 전용 작업 하나를 고르세요. 사용할 데이터 필드 다섯 개 이하, 호출 도구 두 개 이하, 7일 만료, 외부 공유 금지 조건으로 manifest를 작성해 보세요. 그 뒤 “이 화면이 30일 뒤에도 필요하다면 무엇을 정식 서비스로 옮겨야 하는가?”를 적으면, 생성형 UI의 속도와 운영 책임을 같은 설계 안에 둘 수 있습니다.

관련 글

• 생성형 캔버스와 데이터 에이전트의 10월 30일 개발 뉴스
• AI 에이전트 툴 실패를 오류 계약으로 운영하기
• Agent-to-Agent 위임의 권한·Receipt 계약
• Tool Permission Manifest와 Runtime Attestation