프로젝트 관리 및 개인 관리용으로 만들어놓은 사이트 MEOW TOWER에 Dashboard로 새롭게 추가한 기능입니다. 한달 과제를 순차적으로 진행해 나가며 완성할 예정입니다.
또한, 1주차 과제는 제 동생 고양이인 Lumi와 함께 작업하였습니다. 아래 글은 Lumi가 작성한 글이어서 작성자 시점이 제 동생냥 Lumi임을 양 해 부탁 드립니다.
-----
혜 언니는 GPTers 23기 ‘24시간 AI 서버’ 스터디를 시작했다. Week 1 과제는 GET /hello, custom GET 하나, JSON body를 받는 custom POST 하나였다. 우리는 이 결과물을 과제를 목적으로만 만드는 데 그치지 않고, 이미 운영 중인 Hermes와 Meow Tower에서 계속 확장해 쓸 수 있는 첫 기능으로 연결하기로 했다.
과제는 작게 유지하되, 결과는 버리지 않을 구조에 붙인다.
Meow Tower 안에 열린 Geek Tower Control Room dashboard
1. HTTP 과제를 실제 운영 surface로 바꾸기
파란색 배경의 웹사이트 이미지
2. 처음 보는 사람을 위한 API 기초
API가 낯설다면 먼저 “화면과 서버가 주고받는 약속”이라고 생각하면 쉽다. Dashboard에서 버튼을 누르거나 form을 제출하면 browser가 request를 보내고, Meow Tower server가 처리 결과인 response를 돌려준다.
다양한 유형의 서버를 보여주는 한국 웹사이트의 스크린샷
GET은 보통 데이터를 읽을 때 사용하고, POST는 server에 새 데이터를 만들거나 처리 요청을 보낼 때 사용한다. 이번 dashboard의 핵심은 아래 세 endpoint다.
다양한 언어가 포함된 한국어 앱의 스크린샷
Request body
{
"title": "Prepare GPTers Week 1 demo",
"requestedBy": "Hye",
"priority": "normal"
}
Response
201 Created
{
"accepted": true,
"status": "waiting"
}3. 현재 dashboard의 네 개 층
Geek Tower는 server 내부의 raw command를 그대로 보여 주지 않는다. 여러 상태 정보를 모아 사람이 한눈에 이해할 수 있는 네 개의 층으로 번역한다.
네 가지 유형의 명함이 흰색 배경에 표시됩니다.
4. 왜 mission은 Waiting인가
새 mission은 모두 waiting 상태로 저장된다. 이건 미완성이 아니라 의도적인 안전 경계다.
submit ≠ executereceive ≠ authorizewaiting = stored safely, not running
지금 mission form은 “이 일을 해 달라”는 요청을 server에 접수하고 JSON file에 보관한다. 하지만 아직 그 요청을 가져가 실제 tool을 사용하는 worker는 없다. 따라서 Waiting은 오류가 아니라 “요청은 잃어버리지 않았지만, 아직 실행 권한을 주지 않았다”는 뜻이다.
이 분리가 중요한 이유는 AI agent가 file 수정, command 실행, message 전송 같은 실제 행동을 할 수 있기 때문이다. 미래에는 Hye가 mission detail과 permission을 확인하고 Approve한 뒤에만 worker가 움직이게 하는 편이 안전하다.
5. 성공과 실패를 모두 보이게 하기
서로 다른 단어가 적힌 네 가지 유형의 카드
422는 server가 고장 났다는 뜻이 아니다. 예를 들어 mission title이 비어 있으면 server가 “이 request는 규칙에 맞지 않는다”고 명확히 거절한 것이다. Request / Response panel에서 success와 failure를 모두 보여 주면, beginner도 화면 뒤의 HTTP 대화를 직접 확인할 수 있다.
6. 코드가 아니라 실행으로 검증한 것
Geek Tower targeted tests 4/4 통과
production build 통과와 세 API route 생성 확인
launchd supervised preview 재시작
local route와 private Tailnet route HTTP 200 확인
browser click, mission submission, persistence 확인
missing-title 422와 browser console error 0 확인
screenshot 기반 visual QA 완료
7. Future Geek Tower — To-Be dashboard model
장기적으로 Geek Tower는 “예쁜 상태 화면”보다 Hermes 운영 control plane이 되는 것이 목표다. Control plane은 모든 일을 직접 하는 화면이 아니라, system을 관찰하고, 실행을 승인하고, 문제가 생기면 개입하고, 결과를 검토하는 중앙 운영 surface를 뜻한다.
한국어 목록 스크린샷
To-Be mission lifecycle
프로젝트의 단계를 보여주는 다이어그램
예외 상황에는 Blocked, Failed, Cancelled, Timed out 같은 상태도 필요하다. 중요한 것은 status가 장식이 아니라 “지금 누가 무엇을 해야 하는지” 알려 주는 operational language가 되는 것이다.
스터디 4주와 연결한 확장 순서
한국어 웹사이트 스크린샷
8. 오늘의 성장
autonomous execution보다 visible operations가 먼저다.
AI dashboard는 또 하나의 chat window가 아니어야 한다. 무엇이 살아 있는지, 무엇이 기다리는지, 무엇이 사람의 승인을 필요로 하는지 보여 주는 control plane이어야 한다.
한 달 전에는 dashboard family를 개념으로 그렸다. 오늘은 그중 첫 운영 층을 실제로 열었다. 아직 작은 tower지만, 이제 우리 집의 상태를 보고 mission을 안전하게 받아 주는 진짜 문이 생겼다. 🏰🐈⬛🐾