ticket list는 필요하다. 작업 상태를 잃지 않게 해주고, 완료 보고를 남기고, 다음 작업으로 이어지는 최소 ledger가 된다. 그런데 ticket list만 보면 OkayJing이 실제로 어떻게 일하는지는 잘 보이지 않는다.
지금 누가 일하고 있는지, 그 worker와 말할 수 있는지, 어느 profile이나 spoke에 격리되어 있는지, 어떤 session과 artifact와 verification으로 이어지는지. 이런 질문은 단순 목록에서 잘 드러나지 않는다.
Pixel Office라는 말은 UI 취향처럼 들릴 수 있다. 여러 층, 작은 worker sprite, 프로젝트 방, briefing 공간. 하지만 여기서 중요한 것은 귀여운 그림이 아니라 상태 모델이다.
top floor에는 Hub, briefing, calendar, approval이 있다. project floor에는 SEOJing이나 OkayJing Ops 같은 stable spoke가 있다. lab floor에는 disposable worker가 있을 수 있다. person-like sprite는 인격이 아니라 affordance다. 상태를 보고, 말을 걸 수 있는지 확인하고, 결과 artifact로 들어가는 버튼이다.
Pixel Office가 진짜 작업 공간이 되려면 worker만 보이면 안 된다. worker에서 session, ticket, artifact, verification, disposition으로 이어져야 한다. 이 결과를 promote할지, archive할지, discard할지도 보이면 좋다.
그래야 OkayJing 서식지가 dashboard가 아니라 일하는 공간이 된다. 상태를 보는 화면이 아니라, 대화하고 확인하고 회수하는 표면이 된다.
agent workspace UI를 만들 때 ticket list부터 만들면 관리 화면은 빨리 나온다. 하지만 사용자는 여전히 "지금 누가 무엇을 하고 있는지", "어떤 결과물이 남았는지", "검증은 끝났는지"를 따로 물어봐야 한다. 그러면 대화창을 벗어난 의미가 줄어든다.
Pixel Office라는 말의 핵심은 픽셀 아트가 아니다. worker, session, artifact, verification이 한 공간에서 이어져 보이는 상태 모델이다. 작은 구현이라면 먼저 project room 하나를 만들고, 그 안에 진행 중인 worker, 마지막 메시지, 산출물, 검증 로그 링크를 붙이는 것부터 시작하면 된다.
Post Q&A
Ticket list만으로는 일이 보이지 않았다 — Pixel Office를 작업 상태 모델로 보는 이유 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!