이 글의 장단점 평가 부분(특히 자동 업데이트의 부작용, 국내 벤더 대비 지원 속도 관련 내용)은 공식 자료로 확인되지 않는 필자 개인의 실무 경험과 의견입니다. 아폴로의 구조·기능 설명은 팔란티어 공식 문서를 기준으로 작성했습니다.
아폴로가 하는 일
Palantir Apollo는 팔란티어 소프트웨어(Foundry, AIP 등)를 여러 환경에 걸쳐 자동으로 배포·관리하는 지속적 배포(CD) 플랫폼입니다. 클라우드, 온프레미스, 에어갭(air-gapped, 인터넷과 완전히 분리된) 환경까지 포괄하며, 공식 문서는 이를 “인프라 계층 위에서 이기종 환경을 아우르는 제약 기반(constraint-based) 자율 배포 플랫폼”으로 설명합니다.[1]
원래는 팔란티어가 자기 자신의 소프트웨어 500개 이상의 마이크로서비스를 300개 이상의 환경에 배포하기 위해 만든 내부 도구였고,[2] 지금은 고객사가 자신의 환경에서 팔란티어 소프트웨어(그리고 그 위에서 도는 자체 애플리케이션)를 관리하는 데도 쓰입니다.
Hub와 Spoke — 중앙이 지시하는 게 아니라, 각 환경이 끌어온다
아폴로의 핵심 구조는 Hub(허브)와 Spoke(스포크) 두 종류의 환경으로 나뉩니다.[3]
- Hub: 제품 정의, 배포 설정, 보안·거버넌스 정책, 릴리스 승격 규칙을 저장하는 중앙 저장소.
- Spoke: 실제 소프트웨어가 돌아가는 대상 환경(쿠버네티스 클러스터, 엣지 하드웨어 등). 각 Spoke는 로컬 오케스트레이션 에이전트를 돌리며 Hub에 상태를 보고합니다.
여기서 중요한 설계 포인트는 Push가 아니라 Pull 방식이라는 점입니다.[3] 전통적인 CI/CD처럼 중앙에서 “지금 배포해”라고 밀어넣는 게 아니라, 각 Spoke의 로컬 에이전트가 현재 환경 상태를 스키마 버전·서비스 간 의존성 같은 제약 조건과 계속 대조하면서, 조건이 맞으면 스스로 업그레이드를 요청하고 적용합니다. 하나의 Hub가 여러 Spoke를 관리할 수 있고, Hub가 자기 자신을 관리하는 구조도 가능합니다.
릴리스 채널 — 모든 환경이 같은 속도로 업데이트되지 않는다
아폴로는 릴리스를 곧바로 전체에 뿌리지 않고, 릴리스 채널(Release Channel)이라는 단계를 거쳐 승격시킵니다.[4] 제품 담당팀이 채널 간 승격 기준을 정의하고, 각 환경은 자신의 안정성 요구 수준에 맞는 채널을 구독합니다 — 테스트 클러스터는 더 이른 채널을, 운영 클러스터는 검증이 끝난 채널을 구독하는 식입니다.
승격은 정해진 일정이 아니라 제약 조건 충족 여부로 결정됩니다.[1][4]
- 서비스 간·스키마 의존성 요구사항이 만족되는가
- 정해진 안정화 기간(soak time)과 헬스체크·SLO를 통과했는가
- 환경별 유지보수 시간대와 컴플라이언스 승인 규칙에 맞는가
모니터링 도구(Prometheus, Datadog 등)와 연동해 실제 에러율이 임계치를 넘으면 승격 자체를 자동으로 멈추거나 배포를 차단하는 기능도 있습니다.[1]
문제가 생기면? — 리콜과 롤백
자동 배포 시스템에서 가장 중요한 질문은 “잘못된 버전이 나갔을 때 어떻게 되돌리는가”입니다. 아폴로는 이를 리콜(Recall)이라는 절차로 처리합니다.[5]
리콜은 세 가지 방식으로 발동될 수 있습니다.
- 엔지니어가 수동으로 발동
- 지속적인 취약점 스캔(CVE 탐지) 등을 통해 자동으로 발동
- 외부 서비스가 API로 프로그래밍 방식으로 발동
리콜이 걸리면 아폴로는 해당 릴리스의 추가 확산을 멈추고, 다음 중 하나의 롤오프 전략(Roll-off strategy)으로 영향받은 환경을 조치합니다.[6]
- Roll Forward: 모든 제약 조건을 만족하는, 문제없는 상위 버전으로 올림
- Allow Downgrade(롤백): 상위 버전으로 못 올라가면 지정한 최소 버전 이상의 안전한 이전 버전으로 되돌림
- Freeze All Version Changes: 지정한 만료일 또는 수동 해제 전까지 현재 버전에서 동결
- Test Roll-off on Specific Environments: 롤오프·롤백을 특정 테스트 환경에만 먼저 적용해본 뒤 전체로 확산
즉 “리콜”과 “롤오프 전략”이라는 절차가 공식적으로 존재한다는 것 자체가, 자동 배포된 릴리스가 문제를 일으키는 경우가 실제로 있고, 팔란티어도 이를 전제로 시스템을 설계했다는 뜻입니다.
자동 업데이트가 막힐 때도 있다 — “Blocked Update”
아폴로 문서에는 자동 업데이트가 실패하는 구체적인 사례도 명시되어 있습니다. 예를 들어 새 모듈(Module) 버전에 기본값이 없는 새 변수가 추가되면, 아폴로는 해당 설치를 자동으로 업데이트하지 못하고 “Blocked Update”로 표시하며 이유를 보여줍니다.[7] 이 경우 환경 편집 권한이 있는 사람이 모듈 정의를 고쳐 하위 호환성 문제를 해결하거나, 설치를 수동으로 업데이트해야 합니다.
이건 팔란티어가 숨기는 내용이 아니라 공식 문서에 나오는 정상적인 동작입니다 — 자동화가 모든 경우를 알아서 처리하는 게 아니라, 처리할 수 없는 경우를 감지해서 사람에게 넘긴다는 뜻이기도 합니다.
여기서부터는 개인 의견입니다
지금까지는 공식 문서 기준 사실이었고, 여기부터는 실무에서 아폴로 같은 자동 배포 체계를 다뤄본 개인적인 소감입니다.
좋은 점: 패치와 신기술 반영이 계속 최신 상태로 유지된다는 점은 분명한 장점입니다. 담당자가 일일이 버전을 추적하고 수동으로 업그레이드 일정을 잡을 필요가 없고, 보안 취약점 대응도 리콜 메커니즘 덕분에 빠르게 이뤄질 수 있습니다.
문제가 되는 지점: 그런데 이게 전부 자동으로 돌아가다 보니, 어제까지 잘 되던 기능이 오늘 갑자기 안 되는 경우가 생깁니다. 위에서 본 “Blocked Update”처럼 시스템이 스스로 멈추고 알려주는 경우는 그나마 낫습니다. 문제는 조용히 동작 방식이 바뀌어서 원인 파악에 시간이 걸리는 경우입니다.
그리고 이때 국내 벤더사에서 기대할 수 있는 것 같은 빠른 대면 조치나 즉각적인 서비스 대응을 기대하기는 어렵다고 느꼈습니다. 이건 팔란티어의 지원 체계가 나쁘다는 뜻이 아니라, 글로벌 SaaS 벤더의 지원 모델 자체가 국내 SI·솔루션 벤더의 “일단 사람부터 보낸다”는 방식과 다르게 설계되어 있다는 의미에 가깝습니다. 자동화로 얻는 이득과, 문제가 생겼을 때 즉시 사람이 붙어서 해결해주는 대응성 사이에는 트레이드오프가 있다고 보는 게 현실적인 것 같습니다.
정리
- 아폴로는 팔란티어 소프트웨어를 여러 환경에 자동으로 배포·관리하는 Pull 기반 CD 플랫폼이다.
- Hub가 정책을 갖고 있고, 각 Spoke가 스스로 조건을 확인해 업그레이드를 끌어온다.
- 릴리스 채널과 제약 조건 승격 방식 덕분에 모든 환경이 같은 속도로 업데이트되지 않는다.
- 리콜·롤오프 전략이 공식적으로 존재한다는 것 자체가 “자동 배포도 실패할 수 있다”는 전제를 깔고 있다는 뜻이다.
- (개인 의견) 최신 상태 유지라는 장점과, 자동화로 인한 예상 밖의 변화·상대적으로 느린 대면 대응이라는 단점은 함께 따라온다.
참고자료
[1] Palantir, Introduction • Apollo, Apollo 공식 문서.
[2] Palantir Blog, Palantir Apollo: Powering SaaS where no SaaS has gone before, Palantir 공식 블로그.
[3] Palantir, Apollo • Getting Started, Apollo 공식 문서.
[4] Palantir, Overview • Core • Apollo, Apollo 공식 문서.
[5] Palantir, Recalling Releases • Overview, Apollo 공식 문서.
[6] Palantir, Recalling Releases • Roll-off strategies, Apollo 공식 문서.
[7] Palantir, Managing Modules • Update a Module installation, Apollo 공식 문서.