글래스룸에 필요한 다음 화면: AI 작업 승인 큐

글래스룸은 AI 에이전트 팀을 한눈에 보는 데스크톱 대시보드로 시작했어요. 어떤 작업이 돌고 있는지, 비용은 얼마나 쓰는지, 어디서 막혔는지를 보는 화면이 먼저 필요했거든요.

그런데 24시간 돌리는 구조를 만들다 보니, 다음 화면이 분명해졌어요. 바로 승인 큐예요.

자동화가 멈춰야 하는 순간

AI 에이전트가 모든 일을 끝까지 자동으로 처리하면 편할 것 같지만, 실제로는 그렇지 않아요. 어떤 작업은 자동으로 계속 가면 안 됩니다.

• 같은 provider가 만들고 같은 provider가 평가한 결과
• 공개 발행 직전의 글
• 메일 전송 초안
• 결제나 계정 설정 변경
• 검증이 실패했지만 사람이 보면 살릴 수 있는 작업

이런 작업은 실패도 아니고 완료도 아니에요. "사람이 봐야 하는 상태"에 가깝습니다. 그래서 대시보드에는 단순한 빨간불보다 승인 큐가 필요해요.

승인 큐가 보여줘야 하는 것

승인 큐는 예쁘게 보이는 리스트가 아니라, 사람이 빠르게 판단할 수 있는 작업대여야 합니다.

제가 생각하는 최소 정보는 이래요.

• 작업 이름
• 왜 사람 검토가 필요한지
• 생성한 provider
• 검증 결과
• 관련 파일 또는 결과물 링크
• 승인하면 어떤 일이 일어나는지
• 거절하면 어디로 격리되는지

이 정보가 없으면 승인 버튼은 위험해져요. 사람이 맥락 없이 "통과"만 누르게 되니까요.

Slack 알림만으로는 부족해요

지금도 Slack이나 Telegram으로 알림을 받을 수 있어요. 하지만 메신저 알림은 흐릅니다. 몇 시간이 지나면 묻히고, 어떤 작업이 아직 대기 중인지 한눈에 보기 어렵습니다.

승인 큐는 흘러가는 알림이 아니라 쌓이는 업무함이어야 해요. 오늘 처리할 것, 내일까지 미뤄도 되는 것, 지금 막아야 하는 것을 구분할 수 있어야 합니다.

그래서 글래스룸의 승인 큐는 이런 방식이 좋다고 봐요.

• 기본 정렬은 위험도와 최신순
• 공개 발행, 메일 전송, 삭제 작업은 상단 고정
• 승인 전 diff 또는 preview 보기
• 승인/보류/거절을 명확히 나누기

1인 회사에서 승인 큐가 중요한 이유

팀이 크면 누군가가 리뷰를 맡을 수 있어요. 혼자면 그 사람이 나예요. 문제는 내가 매번 터미널을 볼 수 없다는 점입니다. 그래서 AI가 멈춘 지점을 한 화면에 모아야 해요.

승인 큐는 자동화를 더 많이 하기 위한 장치가 아니라, 자동화를 덜 위험하게 하기 위한 장치예요.

저는 글래스룸을 "AI 팀을 감시하는 화면"보다 "사람이 개입해야 할 순간을 놓치지 않는 화면"으로 보고 있어요. 모든 로그를 보여주는 것보다, 지금 결정해야 하는 것만 정확히 보여주는 쪽이 더 중요합니다.

다음에 만들 것

다음 단계는 단순합니다.

1. work-cell의 needs-review, eval-error, needs-build 같은 상태를 승인 큐로 모읍니다.
2. 블로그 검토 대기 초안도 같은 큐에서 보이게 합니다.
3. 승인하면 기존 스크립트를 호출하되, 직접 provider를 새로 스폰하지 않습니다.

새로운 권한을 만들기보다, 이미 검증한 스크립트를 UI에서 호출하는 방식이 더 안전해요. 글래스룸은 에이전트를 직접 풀어놓는 도구가 아니라, 이미 있는 안전 경계를 보기 좋게 다루는 도구여야 합니다.

혼자 만드는 회사일수록 자동 실행보다 승인 흐름이 먼저입니다. 제가 지금 만들고 싶은 화면도 결국 그쪽에 가까워요.