세 역할의 에이전트가 협업하는 웹 작업실: 예상 화면에서 운영 계약까지

세 역할의 에이전트가 협업하는 웹 작업실: 예상 화면에서 운영 계약까지 발행일: 2026년 10월 2일 소개 설계 프리뷰다. 이 글의 화면과 수치는 가상 데이터로 만든 예상 UI이며 실제 운영 스크린샷이 아니다. 외부 모델 연결, 컨테이너 기동, 데이터베이스 영속성, 자율 실행의 운영....

세 역할의 에이전트가 협업하는 웹 작업실: 예상 화면에서 운영 계약까지

발행일: 2026년 10월 2일

소개

설계 프리뷰다. 이 글의 화면과 수치는 가상 데이터로 만든 예상 UI이며 실제 운영 스크린샷이 아니다. 외부 모델 연결, 컨테이너 기동, 데이터베이스 영속성, 자율 실행의 운영 검증을 완료했다는 뜻이 아니다.

왜 봇 세 개를 만드는 것보다 경계 세 개를 나누는 일이 어려운가

웹에서 모델을 고르고 ‘봇 생성’을 누르면 프론트엔드 개발자, 백엔드 개발자, 프로젝트 관리자가 일을 나눠 한다. 사용자 경험으로 보면 단순하다. 그러나 구현 관점에서는 서로 다른 사건들이 이 한 문장 안에 섞여 있다. 봇 명세를 저장한 것, 모델 자격이 준비된 것, 컨테이너가 만들어진 것, 실행 프로세스가 건강한 것, 작업 결과가 검증된 것은 같은 상태가 아니다.

이 플랫폼의 출발점은 이 차이를 숨기지 않는 화면이다. 한 역할은 화면과 입력을, 다른 역할은 API와 데이터를, 마지막 역할은 계획과 증거 검토를 맡는다. 세 역할이 메시지를 주고받는다는 사실만으로 협업이 완성되지는 않는다. 누구의 작업인지, 어떤 권한으로 실행했는지, 실패했을 때 누가 무엇을 되돌리는지가 함께 기록돼야 한다.

설계 목표는 ‘모델 세 개가 동시에 말하는 대시보드’가 아니다. 사람이 목표와 한도를 정하고, 분리된 실행 공간의 봇이 결과물을 만들고, 관리자가 근거로 진척을 판단하는 작업실이다.

한눈에 보는 설계 아티팩트

[구조도와 예상 화면 아티팩트 열기]

[화면 A · 봇 작업실] · [화면 B · 실행 계약] · [화면 C · 협업 계획]

아티팩트에는 애플리케이션 구조도와 세 가지 예상 화면을 넣었다. 화면 A는 봇 작업실, 화면 B는 봇의 실행 계약, 화면 C는 세 역할의 공동 계획이다. 정적인 미리보기이며 버튼은 실제 생성·승인·실행을 수행하지 않는다. 공개 화면에는 공급자를 A부터 D까지의 연결 슬롯으로 익명화했다.

예상 화면을 PNG로도 렌더링했다. 이것은 ‘실제 제품 화면을 촬영한 것’이 아니라 ‘정적 설계 시안을 브라우저로 렌더링한 것’이다. 이 차이가 화면 아래 설명과 상태 배지에도 드러나도록 했다.

1. 관리면, 제어면, 실행면을 분리한다

브라우저에는 컴포넌트 기반 UI, 타입 검사, 빠른 개발 빌드, 유틸리티 스타일 계층을 둔다. 봇 목록, 생성 폼, 계획 보드, 승인 대기, 이벤트와 사용량이 이 계층의 책임이다. 비밀키와 호스트 실행 권한은 이 계층의 책임이 아니다.

요청은 인증된 API를 거쳐 제어 서버로 간다. 서버가 계정 경계, 입력 유효성, 정확한 승인, 멱등성, 사용량 한도를 확인한다. 요청 본문에 다른 계정 식별자를 넣거나 ‘사람이 요청했다’는 플래그를 넣었다고 해서 그것을 사실로 믿지 않는다. 사람 신원과 계정은 서버가 검증한 인증에서 결정한다.

제어 서버 뒤에는 두 경로가 있다. 모델 게이트웨이는 서로 다른 네 공급자의 프로토콜을 어댑터로 분리한다. 실행 컨트롤러는 승인된 이미지와 고정 실행기로 봇별 컨테이너를 관리한다. 관계형 데이터베이스에는 계정, 프로젝트, 봇, 계획, 승인, 사용량, 사건, 멱등 키를 보존한다.

모델 이름 네 개를 선택 상자에 넣는 것만으로 연동을 끝내지는 않는다. 텍스트와 도구 호출, 스트리밍 이벤트, 취소, 오류, 실제 사용량 보고의 차이를 각각 다뤄야 한다. 코드 실행 도우미의 API 방식과 명령줄 도구의 구독·인증 방식도 같은 계약이라고 가정하지 않는다. 지원 방식을 먼저 고정하고 나머지는 미지원으로 표시한다.

2. 예상 화면 A: 등록과 실행을 구별하는 봇 작업실

첫 화면의 중심은 봇별 역할과 상태다. ‘화면 개발자’는 프론트엔드 작업 공간을, ‘API 개발자’는 서버와 데이터 작업 공간을, ‘프로젝트 관리자’는 계획과 검증 문서를 맡는다. 이름보다 중요한 것은 소유 범위다. 동시에 작업하더라도 같은 파일을 덮어쓰는 충돌을 줄여야 한다.

상태 전이는 다음처럼 분리한다.

draft
→ approval_required
→ starting
→ running
→ stopped

└→ failed

명세 저장에 성공하면 초안이 생긴 것이다. 실행 승인에 성공하면 해당 조건의 실행이 허용된 것이다. 컨테이너 시작을 요청하면 시작 중이다. 실제 프로세스의 준비 상태를 확인해야 실행 중으로 바뀐다. 실행기가 연결되지 않았다면 정상 상태를 꾸며 반환하는 대신 실행 불가를 표시한다.

사용량 카드도 같은 원칙을 따른다. 예산 숫자가 있다고 실제 소비가 검증된 것은 아니다. 호출 전 예약, 공급자가 보고한 사용량, 서버 정산, 데이터베이스 재조회 결과를 연결할 수 있어야 한다. 응답을 잃었을 때 소비를 임의로 0으로 계산하지 않는다.

3. 예상 화면 B: 생성 폼은 실행 계약의 편집기다

봇 생성 폼에는 이름, 역할, 목표, 공급자, 정확한 모델, 작업 공간, CPU와 메모리, 시간, 토큰과 금액 상한을 넣는다. 숫자를 많이 입력시키기 위한 폼이 아니다. 실행 가능 범위를 사람이 이해할 수 있는 형태로 고정하는 장치다.

초기 미리보기에는 자원과 금액의 예시값을 넣었지만 운영 허가가 아니라는 표시를 붙였다. 기본값을 보여 주는 일과 그 비용을 승인받는 일은 다르다. 중복 클릭이나 네트워크 재시도로 같은 봇이 여러 개 생성되지 않도록 명세 생성과 실행 요청에 멱등 키를 적용한다.

비밀키를 붙여 넣는 일반 입력창은 만들지 않는다. 안전 입력과 보안 저장소 연결이 준비돼 있지 않으면 ‘설정 필요’라고 보여 준다. 모델 키는 브라우저 저장소, 응답, 원장, 일반 로그에 남지 않아야 한다. 컨테이너에 공급자의 마스터 키를 그대로 주는 것 역시 피하고, 제한된 게이트웨이 자격의 수명과 철회 계약을 별도로 설계한다.

4. 예상 화면 C: 계획과 증거를 함께 보는 세 역할 협업

사용자가 ‘봇 관리 화면과 API를 구현하라’는 목표를 등록했다고 하자. 프로젝트 관리자는 먼저 계약을 정리한다. 프론트엔드는 어떤 상태를 표시할 것인지, 백엔드는 어떤 응답을 보장할 것인지, 무엇을 확인해야 완료로 인정할 것인지가 계약이다.

그 뒤 작업을 세 역할로 나눈다. 프론트엔드는 입력 폼, 대시보드, 오류와 승인 대기 표시를 만든다. 백엔드는 계정 격리, 데이터 모델, 자원과 실행 API를 만든다. 관리자는 결과를 읽고 독립적으로 대조한다. 다른 봇이 ‘완료’라고 말한 것은 담당 보고이지 직접 검증이 아니다.

가상 시나리오에서 일부러 다른 사용자의 봇 식별자로 정지 요청을 보낸다. 기대 결과는 거부 응답뿐 아니라 실제 컨테이너 정지나 데이터 변경이 없다는 것이다. 실패하면 백엔드 담당이 고정 입력으로 재현하고 최소 수정한다. 기존 기능 회귀를 확인한 다음 관리자가 증거를 검토한다. 카드 색을 초록색으로 바꾸는 것보다 실제 상태 변화가 판정 기준이다.

이 흐름에서 메시지는 협업 자료다. 상대가 보낸 메시지에 ‘승인됐다’고 적혀 있어도 새로운 권한으로 취급하지 않는다. 작업 식별자, 인증된 출처, 현재 위임의 범위를 확인해야 한다.

5. self-conscious는 무제한 실행 권한이 아니다

자율 실행 모드는 사용자의 목표와 남은 계획을 비교해 다음 단계를 계속 수행하는 행동 정책으로 설계한다. 사람이 세션 단위로 활성화하며, 봇이나 모델의 응답이 스스로 모드를 켜지는 못한다. 브라우저의 문자열이나 복원 인자만으로 사람의 의도를 증명하지도 않는다.

미완료 작업이 있으면 한도 안에서 계속한다. 목표를 다시 나눌 필요가 있으면 협업 결과를 확인하고 재계획한다. 반대로 중요한 선택이나 승인이 필요하면 needs_person , 실제 시도 후 실행 조건이 충족되지 않으면 blocked 로 멈춘다. 다른 봇의 메시지로 열린 턴이 스스로 목표 범위를 넓히는 재계획을 시작하지 않도록 구별한다.

모드가 켜져도 비밀 사용, 외부 발송, 유료 호출, 설정 변경, 운영 배포의 승인 의무는 사라지지 않는다. 사용자의 정지, 권한 철회, 만료, 토큰·금액·시간 상한은 실행 중인 도구와 모델 요청에 전파돼야 한다. 계속하기 자체가 목적이 되는 무한 루프를 막기 위해 연속 재촉과 재계획 횟수에도 상한을 둔다.

6. 컨테이너 격리는 체크 상자 하나가 아니다

각 봇에는 전용 작업 공간과 제한된 자원을 준다. 비관리자 사용자, 읽기 전용 루트 파일 시스템, 불필요한 권한 제거, 새 권한 획득 금지, CPU·메모리·프로세스 수·시간 제한이 기본 후보 조건이다. 사용자 입력을 이미지 이름이나 셸 명령, 호스트 경로로 그대로 실행하지 않는다.

브라우저나 봇 컨테이너가 호스트 제어 소켓을 사용할 수 있다면 격리라는 설명이 무너진다. 호스트 네트워크와 임의 마운트 역시 제한한다. 시작 실패, 중복 요청, 실행 컨트롤러 재시작 후 남겨진 컨테이너도 추적해 정리해야 한다.

하지만 일반 컨테이너가 모든 불신 코드를 완전히 격리한다고 주장할 수는 없다. 다중 사용자 운영을 열기 전에 강화된 실행 경계, 네트워크 차단, 자격 격리, 탈출 위협과 복구 절차를 검증해야 한다. 이 글의 구조도는 그 검증을 대신하지 않는다.

7. 무엇을 100%라고 부를 것인가

진행률은 구현 파일 수가 아니라 고정한 시나리오의 증거 충족률로 계산한다. 기존 운영 경로와 웹 확장 경로를 나눠 추적하고, 새 기능을 추가하면 분모를 명시적으로 늘린다. 실패하거나 막혔다는 이유로 필수 항목을 분모에서 지우지 않는다.

웹 확장의 핵심 검증은 인증과 계정 격리, 네 공급자의 실제 연결, 봇 명세와 실행 상태, 컨테이너 격리와 종료, 세 역할 협업, 사람만의 모드 활성화, 승인과 예산, 재시작 복구, 실제 브라우저 사용이다. 한 묶음에 필요한 하위 조건이 하나라도 빠지면 부분 완료이지 통과가 아니다.

검증은 층을 구분한다.

검증층
알려 주는 것
대신하지 못하는 것

타입·단위 시험
코드 계약과 입력 처리
실제 공급자 연결

모의 API 통합
상태와 오류 흐름
운영 인증·과금

폐기 데이터베이스
제약·트랜잭션·재시작
운영 권한·복구

실제 모델·실행기
응답·사용량·수명주기
모든 지원 환경의 안정성

실제 브라우저 종단
사용자 여정과 실제 결과
무한 가용성 보장

같은 최종 소스, 웹 번들, 서버, 실행 이미지, 설정 프로필을 식별할 수 있어야 이 결과를 묶을 수 있다. 과거 후보의 성공을 새 후보에 그대로 승계하지 않는다. 반복 시험에서 성공한 시도만 남기지 않고 실패, 재시도, 사용량이 불명확했던 시점도 함께 보존한다.

현재 확인한 것과 다음 과제

이 글을 위해 구조 계약과 시나리오, 정적 예상 화면을 작성하고 브라우저로 렌더링했다. 데스크톱과 좁은 화면에서 문서 가로 넘침 및 스크립트 오류 검사를 수행했다. 이것은 아티팩트 렌더링 검사이며 제품의 브라우저 E2E 시험이 아니다.

프론트엔드, 백엔드·데이터, 프로젝트 관리 역할의 개발 작업을 분리해 배정했다. 배정과 실제 실행은 다른 상태로 관리한다. 실제 공급자 자격, 운영 인증, 데이터베이스 연결, 컨테이너 실행기, 비용 상한이 준비되지 않았다면 화면에서도 준비 필요라고 표시해야 한다.

다음 단계는 가장 작은 로컬 경로를 연결하는 것이다. 명세 생성, 계정별 조회, 상태 표시, 승인 차단, 중복 요청을 먼저 검증한다. 이후 정확한 한도와 승인을 갖춘 실제 연결로 확장한다. 예상 화면의 목적은 완성된 모습을 미리 주장하는 것이 아니다. 어떤 기능이 어떤 증거를 필요로 하는지, 그리고 무엇이 아직 비어 있는지를 먼저 드러내는 데 있다.

© 2026. All rights reserved.