The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing

한 줄 핵심

소프트웨어를 한 번 빌드해 모두에게 같은 아티팩트로 배포하던 파이프라인은, 이제 실행 중에 사용자별로 적응하는 소프트웨어가 가능해지면서 더 이상 필수 전제가 아니게 되었다.

시간별 요약

1. 0:00
   기존 CI 파이프라인과 배포 인프라는 ‘한 번 만든 고정 아티팩트를 안전하고 재현 가능하게 전달한다’는 전제를 해결해 왔다. 하지만 이 전제는 소프트웨어 제작이 비싸고 위험하던 시대의 산물이며, 그 결과 한 버전을 모두에게 배포하는 구조가 기본값이 되었다.
2. 3:01
   지금 바뀌는 핵심은 코드를 바꾸는 비용이 급격히 낮아져, 변경이 빌드 시점의 중앙 이벤트가 아니라 실행 중의 실시간 결정이 되고 있다는 점이다. 사용자들은 오래전부터 개인화된 소프트웨어를 원해 왔고, feature flags나 AB testing은 그 수요의 일부만 흉내 냈을 뿐이다.
3. 8:02
   새 구조는 하나의 canonical stem 위에 사용자별 divergence를 얹는 방식이며, 각 divergence는 bounded, isolated, reversible 해야 한다. 이렇게 하면 ‘AI가 만든 코드베이스는 통제 불능일 것’이라는 우려에 대해, 무질서한 하나의 아티팩트가 아니라 경계가 있는 사용자별 변형으로 blast radius를 한 context로 제한할 수 있다.
4. 11:01
   적응형 소프트웨어는 행동 관찰과 사용자 요청을 바탕으로 개인별 UI와 흐름을 재구성한다. CRM 예시처럼 특정 입력값을 숨기거나 자주 쓰는 필드를 앞에 두는 식으로, 개발자는 수정 가능한 범위와 절대 건드리면 안 되는 영역을 정해 두고 더 넓은 사용자 세그먼트를 R&D 증가 없이 지원할 수 있다.
5. 13:00
   이 아키텍처의 핵심 난점은 소스 오브 트루스, correctness, desirability, autonomy vs control, coordination이다. 즉, 중요한 것은 코드를 생성하는 일이 아니라 각 divergence의 provenance와 검증, 목표 지표에 대한 개선 여부, 그리고 수많은 버전이 결국 같은 intent와 outcome으로 수렴하도록 관리하는 일이다.
6. 18:01
   이 발표의 결론은 파이프라인이 망가졌다는 뜻이 아니라, 파이프라인이 해결하던 비용 구조가 사라졌다는 뜻이다. 앞으로의 경쟁력은 하나의 버전을 모두에게 안전하게 배포하는 능력보다, 올바른 버전을 각 사용자에게 격리와 추적 가능성을 유지한 채 제공하는 능력에 있다.

실무 인사이트

• 개인화는 기능 추가가 아니라 배포 단위의 재설계 문제로 봐야 하며, stem과 divergence를 분리해 blast radius를 제어하는 구조가 먼저 필요하다.
• AI 코드 생성 자체보다 provenance, validation, observability를 설계하는 일이 더 중요하므로, 운영 지표와 감사 가능성을 처음부터 제품 요구사항에 포함해야 한다.
• feature flags를 더 촘촘히 만드는 접근보다, 사용자별로 실제로 다른 결과를 허용하는 실행 모델을 검토해야 장기적으로 개인화와 자동화를 동시에 달성할 수 있다.