osFoundry / Platform
컨테이너 컴퓨트
지속적인 프로세스가 필요한가요? 런타임을 컨테이너로 전환하세요. 동일한 앱, 다른 모드.
개요
컨테이너 컴퓨트는 osFoundry에서 만든 앱을 위한 런타임 모드입니다. 대부분의 앱은 요청이 오면 뜨고, 응답하고, 내려가는 단명 프로세스로도 충분히 잘 돌아갑니다. 하지만 어떤 워크로드는 계속 살아 있어야 합니다. 연결을 열어 두는 WebSocket 서버, 큐를 비워 나가는 백그라운드 워커, 자기 시계로 째깍이는 스케줄러, 요청 사이에도 메모리에 따뜻한 상태를 유지하는 백엔드 같은 것들입니다. 이런 경우 런타임을 컨테이너로 바꾸면, 같은 앱이 매번 새로 시작하는 대신 장시간 실행되는 프로세스로 계속 돌아갑니다.
핵심은 같은 앱이라는 점입니다. 다시 짜지도, 포크하지도, 다른 서비스로 옮기지도 않습니다. 코드와 라우트, 연결은 그대로 두고, 실행되는 방식만 바꿉니다. 그래서 컨테이너 모드는 어떤 기능이 요구할 때 내리는 결정이지, 처음부터 짊어지는 아키텍처가 아닙니다. 앱을 가볍고 단명한 모드로 시작했다가, 반드시 유지되어야 하는 부분을 더하는 순간 컨테이너로 전환하면 됩니다.
이는 채팅, 에이전트, 앱, 코드, 데이터를 별도의 호스팅 계정에 흩어 놓지 않고 하나의 워크스페이스에 모아 두는 osFoundry의 방식과 맞닿아 있습니다. osFoundry는 BYOK이자 로컬 우선이므로, 좌석당 과금하는 SaaS 껍데기 없이 자신의 앱을 자신의 방식대로 실행합니다. 컨테이너 컴퓨트는 이를 백엔드까지 넓힙니다. 앱이 상태 없는 도우미에서 계속 돌아가야 하는 무언가로 성장할 때, 워크스페이스에는 그것이 머물 자리가 이미 마련되어 있습니다.
주요 기능
- 코드를 바꾸지 않고도 어떤 osFoundry 앱이든 단명 런타임과 컨테이너 런타임 사이를 전환
- 장시간 실행 프로세스 구동: WebSocket 서버, 백그라운드 워커, 스케줄러, 데몬
- 호출마다 콜드 스타트하는 대신 요청 사이에 메모리에 따뜻한 상태를 유지
- 런타임을 앱별로 선택해, 기능이 필요로 하는 곳에서만 상시 구동 프로세스에 비용 지불
- 백엔드는 채팅, 에이전트, 코드, 데이터와 같은 워크스페이스 안에서 구동
활용 사례
- 개발자: 실시간 업데이트를 위해 WebSocket 기능을 추가한 앱을 연결을 열어 두도록 컨테이너로 전환
- 자동화 제작자: 작업 큐를 비우고 스케줄에 따라 도는 백그라운드 워커에는 결코 잠들지 않는 프로세스가 필요
- 팀 리드: 상태 없이 시작한 프로토타입이 따뜻한 캐시와 상시 구동 백엔드가 필요해지자 재빌드 없이 컨테이너 모드로 이전
자주 묻는 질문
기본 런타임 대신 앱을 컨테이너 컴퓨트로 전환해야 할 때는 언제인가요?
요청 사이에 무언가를 살려 둬야 할 때 전환하세요. 열린 연결(WebSocket 등), 백그라운드 또는 예약 워커, 데몬 프로세스, 매 호출마다 잃고 싶지 않은 메모리 상태 같은 것입니다. 앱이 요청에 답하고 내려가기만 한다면, 더 가벼운 단명 런타임이 더 잘 맞습니다.
컨테이너로 실행하려면 앱을 다시 짜야 하나요?
아니요. 모드만 다른 같은 앱입니다. 런타임 설정을 전환하면 기존 코드가 상시 구동 프로세스로 돌아갑니다. 바로 그것이 핵심이라, 앱을 단순하게 시작했다가 어떤 기능이 실제로 요구할 때에만 컨테이너로 옮기면 됩니다.
이것은 osFoundry가 BYOK이자 로컬 우선이라는 점과 어떻게 연결되나요?
컨테이너 컴퓨트는 앱 백엔드가 어디서 도는가에 관한 것이라, osFoundry의 나머지와 나란히 놓입니다. 키와 모델, 데이터는 당신의 통제 아래 남고, 앱 백엔드는 별도의 호스팅 계정이 아니라 채팅, 에이전트, 코드, 데이터와 같은 워크스페이스 안에서 구동됩니다.