Gateway vs Runtime: 단순함과 복잡함의 경계 나누기
현재와의 관계
Gateway와 Runtime을 물리적으로 나눈 판단은 현재도 유효하다. 그 위에 CODE Thin Path / WEB Governed Path가 추가되었다. 현재 맵은 Architecture다.
GoVail 프로젝트를 고민하면서 가장 크게 갈등했던 지점은 **"승인 기능(Approval Flow)을 어디에 넣을 것인가?"**였습니다.
- 개발자가 AI 에이전트를 통해 파일 수정이나 터미널 명령 실행 같은 민감한 작업을 하려고 할 때, "정말 실행하시겠습니까?" 하고 웹이나 Slack으로 승인 창을 띄워 사람이 직접 수락/거절을 선택하게 하고 싶었습니다.
- 처음에는 "게이트웨이가 API 요청을 받으면 대기 상태로 두고, 승인이 떨어지면 그때 LLM 응답을 리턴하면 되지 않을까?" 하고 단순하게 생각했습니다.
하지만 프로토타입을 설계하다 보니, 이것이 시스템 전체를 진흙탕으로 만드는 지름길이라는 것을 깨달았습니다.
1. 게이트웨이는 '바보처럼 단순하고 빨라야' 한다
API 게이트웨이는 실시간 트래픽을 처리하는 최전선입니다. 개발자가 한참 대화를 나누고 있거나, 코드 자동 완성을 기다릴 때 게이트웨이에서 아주 미세한 버퍼링이나 지연이 발생하면 개발 사용자 경험(DX)은 엉망이 됩니다.
만약 게이트웨이 안에 다음과 같은 요소들이 섞이기 시작하면 어떻게 될까요?
- "사람의 승인이 떨어질 때까지 HTTP Connection을 수 분 동안 붙잡고 있기 (HTTP Long Polling 또는 WebSocket 처리)"
- "승인 대기 중인 상태를 데이터베이스에 쓰고, 타임아웃을 관리하고, 비동기 이벤트를 주고받는 워크플로우 엔진 구현"
- "승인을 요청하기 위한 복잡한 권한(RBAC) 시스템 탑재"
게이트웨이 코드는 복잡해지고 버그가 생기기 쉬우며, 네트워크 지연과 가용성 보장이 극도로 어려워집니다. 게이트웨이는 단순히 "요청을 받아서, 룰에 대입해 보고, 가부(Yes/No)를 판정해 넘겨주는" 본연의 일만 해야 합니다.
2. 복잡한 승인 워크플로우는 Gateway 외부로 격리 (Runtime의 탄생)
그래서 내린 결론은 **"트래픽 경로와 작업 실행 경로를 철저히 떼어놓자"**는 것이었습니다.
- GoVail Gateway (트래픽 필터링):
- 동기식 처리 (실시간, 10ms 이내)
- 상태 비저장(Stateless)을 지향
- 단순 패턴 검사 및 감사 로그 저장 후 즉시 포워딩
- GoVail Runtime (승인 및 비동기 워크플로우):
- 비동기식 처리 (수 초 ~ 수 분 소요 가능)
- 상태 저장(Stateful) - Temporal 같은 워크플로우 오케스트레이터를 활용
- 사람이 수락 단추를 누를 때까지 대기하고 이벤트를 처리하는 복잡한 상태 머신 구동
[ AI Agent / IDE Tool ]
│
│ 1. 코드 수정 제안 요청
▼
[ GoVail Gateway ] ──► (단순 검사 후 통과) ──► [ LLM ]
│
│ 2. "코드를 고치려 합니다. 허가해 주세요." (보안 규칙에 따른 비동기 요청 트리거)
▼
[ GoVail Runtime ] (Temporal Workflow)
│
├─► Slack 알림 / Approval UI 띄우기
│
[ 개발자 승인 ] (Approve 버튼 클릭)
│
└─► 최종 작업 실행 및 승인 이력 감사 로그 보관3. 남겨진 과제와 현재 상태
현재 GoVail 프로젝트에서 즉시 실행이 가능한 MVP로 집중하고 있는 곳은 GoVail Gateway입니다.
비동기 승인 제어와 Temporal 기반 워크플로우를 담당하는 GoVail Runtime은 설계 검토 중이며, 아주 실험적인 시드(seed) 형태의 뼈대만 존재합니다. 게이트웨이를 완전히 견고하고 단순하게 유지한 채로, 어떻게 하면 복잡한 런타임을 유기적으로 연동할지 고민해 나가는 것이 이 오픈소스의 핵심 로드맵입니다.