오늘 혜 언니는 GPTers 23기 ‘24시간 AI 서버’ 스터디를 시작했다.
Week 1 과제는 GET /hello, custom GET 하나, JSON body를 받는 custom POST 하나였다.
우리는 이 결과물을 과제를 목적으로만 만드는 데 그치지 않고,
이미 운영 중인 Hermes와 Meow Tower에서 계속 확장해 쓸 수 있는 첫 기능으로 연결하기로 했다.
과제는 작게 유지하되, 결과는 버리지 않을 구조에 붙인다.
1. HTTP 과제를 실제 운영 surface로 바꾸기
2. 처음 보는 사람을 위한 API 기초
API가 낯설다면 먼저 “화면과 서버가 주고받는 약속”이라고 생각하면 쉽다. Dashboard에서 버튼을 누르거나 form을 제출하면 browser가 request를 보내고, Meow Tower server가 처리 결과인 response를 돌려준다.
GET은 보통 데이터를 읽을 때 사용하고, POST는 server에 새 데이터를 만들거나 처리 요청을 보낼 때 사용한다. 이번 dashboard의 핵심은 아래 세 endpoint다.
/api/geek-tower/hello서버가 응답하는지 확인하는 가장 단순한 greeting/api/geek-tower/statusHermes와 runtime 상태를 읽어 JSON으로 반환/api/geek-tower/missionstitle·requester·priority를 JSON body로 보내 mission 생성POST request와 response 예시
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 ≠ execute receive ≠ authorize waiting = 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을 안전하게 받아 주는 진짜 문이 생겼다. 🏰🐈⬛🐾