The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing
📺 원본 영상: The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-07
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Iris ten Teije는 이 강연에서 지난 수십 년간 소프트웨어 산업을 지탱해 온 배포 파이프라인의 핵심 전제가 더 이상 절대적이지 않다고 주장한다. CI 파이프라인, 패키지 레지스트리, 컨테이너 이미지, 앱스토어 리뷰 같은 인프라는 모두 “한 곳에서 만든 고정된 아티팩트를 다른 곳으로 안전하게 옮긴다”는 문제를 해결하기 위해 만들어졌지만, AI 에이전트가 코드 생성과 실행 환경에 들어오면서 이 전제가 흔들리고 있다는 것이다.
강연의 핵심은 단순히 “AI가 코드를 잘 쓴다”는 이야기가 아니다. 더 중요한 변화는 소프트웨어 변경을 만드는 비용이 급격히 낮아지고, 그 변경이 중앙의 빌드 단계가 아니라 사용자 세션 안에서도 일어날 수 있게 되었다는 점이다. 이 변화는 “모두를 위한 하나의 버전”에서 “각 사용자에게 맞는 최적의 버전”으로 소프트웨어의 기본 형태가 이동할 수 있음을 시사한다.
고정 아티팩트가 만든 20년의 질서
강연자는 먼저 개발자들에게 익숙한 배포 인프라를 하나의 공통된 목적 아래 묶는다. CI 파이프라인, 패키지 레지스트리, 컨테이너 이미지, 앱스토어 리뷰는 서로 다른 도구처럼 보이지만, 사실상 모두 동일한 문제를 해결한다. 개발된 코드를 하나의 고정된 아티팩트로 만들고, 그것을 실행 환경까지 안전하고 재현 가능하게 옮기는 일이다.
이 구조는 임의로 생긴 것이 아니다. 과거에는 올바른 소프트웨어 변경을 만드는 비용이 컸고, 숙련된 개발자가 몇 시간 혹은 며칠에 걸쳐 코드를 작성하고 검토해야 했다. 변경 자체가 비싸고 위험했기 때문에, 조직은 변경을 드물게 수행하고 중앙에서 검증한 뒤 하나의 고정된 산출물로 얼려 배포했다. 그렇게 만들어진 파이프라인은 단순한 관성이 아니라 당시의 경제적 조건에 대한 합리적 응답이었다.
고정 아티팩트는 강력한 장점도 제공했다. 하나의 산출물이 존재하고 배포 이후 바뀌지 않기 때문에 재현성, 리뷰 가능성, 롤백 가능성이 생긴다. 운영 환경에서 우리가 기대하는 많은 안정성 보장은 바로 이 전제 위에 서 있다. 그러나 그 대가로 소프트웨어는 특정 사용자에게 깊이 맞춰지기 어려웠고, 모든 사용자는 본질적으로 같은 버전을 사용해야 했다.
02:30 - 고정 아티팩트가 재현성, 리뷰 가능성, 롤백 가능성의 근거가 된다는 설명
“모두를 위한 하나의 버전”은 선택이 아니라 비용의 결과였다
강연자가 강조하는 중요한 지점은 “하나의 버전”이 제품 철학의 승리로 채택된 것이 아니라는 점이다. 어느 회의실에서 “모두를 위한 하나의 버전”과 “각 사용자를 위한 다른 버전”을 비교한 뒤 전자를 선택한 것이 아니었다. 후자는 애초에 실질적인 선택지가 아니었다.
두 사용자에게 서로 다른 소프트웨어를 제공하려면 코드베이스를 포크하고, 각각을 사람이 직접 유지보수해야 했다. 규모가 커질수록 이 방식은 감당할 수 없었기 때문에, 업계는 자연스럽게 하나의 코드베이스와 하나의 배포 아티팩트에 의존했다. 시간이 지나면서 이 방식은 비용 구조의 산물이 아니라 소프트웨어 자체의 본질처럼 받아들여졌다.
하지만 강연자에 따르면 이 전제는 이제 바뀌고 있다. AI 기반 코드 생성은 이미 많은 사람이 언급한 변화지만, 그녀가 주목하는 것은 그보다 더 구조적인 경제 변화다. 올바르고 범위가 제한된 변경을 만드는 비용이 거의 0에 가까워지고 있으며, 그 변경은 더 이상 중앙 빌드 단계에서만 만들어질 필요가 없다. 서버, 클라이언트, 사용자 세션 등 변경이 가장 의미 있는 위치에서 생성되고 적용될 수 있게 된 것이다.
04:23 - 소프트웨어 변경이 서버, 클라이언트, 사용자 세션 등 실행 위치 가까이에서 일어날 수 있다는 설명
개발과 배포의 경계가 흐려지는 이유
전통적인 파이프라인에서는 개발과 배포가 분리되어 있었다. 소프트웨어를 만드는 일은 비싸고 중앙화된 이벤트였고, 실행하는 일은 상대적으로 저렴했기 때문에 먼저 만들고, 검증하고, 고정하고, 그다음 배포하는 순서가 자연스러웠다. 이때 파이프라인은 한 방향으로 흐르는 공급망에 가까웠다.
그러나 변경을 만드는 비용이 실행 비용에 가까워지고, 변경이 실행되는 장소에서 바로 만들어질 수 있다면 이 분리는 약해진다. 강연자는 “에이전트가 런타임이 될 때” 소프트웨어를 실행하는 존재가 동시에 소프트웨어를 수정할 수 있다고 설명한다. 그렇게 되면 개발과 배포는 더 이상 분리된 두 단계가 아니라 하나의 연속적인 과정이 된다.
이 관점에서 “파이프라인의 죽음”은 CI/CD 도구가 당장 사라진다는 뜻이 아니다. 그것은 고정 아티팩트를 중심으로 소프트웨어를 사고하는 방식의 한계가 드러난다는 뜻에 가깝다. 배포는 더 이상 하나의 완성된 결과물을 모두에게 보내는 행위만이 아니라, 공통의 출발점에서 각 사용자 맥락에 맞게 분기되는 과정이 될 수 있다.
개인화 소프트웨어에 대한 수요는 오래전부터 있었다
강연자는 공급 측면, 즉 코드 생성 비용의 하락만으로 이 변화를 설명하지 않는다. 수요 측면에서도 사람들은 오래전부터 자기에게 맞는 소프트웨어를 원해 왔다고 말한다. 단지 그동안 비용 때문에 대부분의 사용자에게 제공할 수 없었을 뿐이다.
기업용 소프트웨어에서 전문 서비스(Professional Services)와 컨설팅 산업이 존재해 온 것은 대표적인 증거다. Salesforce 같은 대형 엔터프라이즈 소프트웨어를 도입하는 큰 고객은 컨설턴트와 엔지니어의 도움을 받아 자신들의 업무 방식에 맞는 설정과 커스터마이징을 만든다. 작은 고객도 같은 혜택을 원하지만, 경제적으로 맞지 않았기 때문에 그런 수준의 맞춤화를 받을 수 없었다.
개발자들의 dotfiles, editor config, key bindings도 같은 욕구를 보여준다. 개발자는 자신이 쓰는 거의 모든 도구를 손으로 고쳐 자신의 도구로 만든다. Excel 역시 정적인 프로그램이라기보다 수많은 사용자가 그 위에 자신만의 프로그램을 만드는 플랫폼에 가깝다. 강연자는 이 사례들을 통해 개인화 소프트웨어에 대한 욕망이 새로운 것이 아니라, 이제야 소프트웨어 계층에서 대규모로 실현 가능해지고 있다고 해석한다.
Feature Flag와 A/B Testing을 넘어서는 적응형 소프트웨어
기존에도 소프트웨어를 사용자별로 다르게 보이게 하려는 시도는 있었다. Feature Flag, Segmentation, A/B Testing은 모두 하나의 제품 안에서 사용자 경험을 분기시키는 방법이었다. 그러나 이 방식들은 기본적으로 미리 정의된 버킷과 세그먼트에 사용자를 넣는 구조에 가깝다.
강연자는 지금의 변화가 그보다 더 깊다고 본다. 과거에는 사용자를 몇 개의 그룹으로 나누고 각 그룹에 다른 기능을 보여주는 정도였다면, 앞으로는 소프트웨어가 각 사용자의 맥락을 관찰하고 그에 맞춰 실제로 적응할 수 있다. 즉, “사용자 A는 이 플래그가 켜진다”의 문제가 아니라, “사용자 A에게 가장 적합한 소프트웨어 형태가 무엇인지 계속 학습하고 변화한다”의 문제로 이동한다.
Differ가 제안하는 형태는 하나의 canonical stem, 즉 공통의 줄기를 배포하고, 각 사용자가 그 줄기에서 자신만의 divergence를 실행하는 구조다. 이때 모든 사용자는 같은 기원을 공유하지만, 실행되는 형태는 개별적으로 조정된다. 강연자는 이를 “모두를 위한 최소 버전”에서 “누군가에게 가장 좋은 버전”으로 이동하는 변화로 설명한다.
08:16 - Differ가 제안하는 canonical stem과 사용자별 divergence 구조
Stem과 Divergence: 안전한 분기를 위한 아키텍처
이 주장은 인프라 관점에서 즉각적인 불안을 낳는다. 고정 아티팩트는 단지 배포 방식이 아니라 운영 안정성의 기반이었기 때문이다. 강연자는 한 CTO의 반응을 소개하며, 이미 하나의 AI 생성 코드베이스도 추론하기 어려운데 수백만 개의 변형을 운영하자는 것은 문제를 곱하는 것처럼 보일 수 있다고 인정한다.
하지만 그녀는 두 가지를 구분해야 한다고 말한다. 하나는 경계 없는 단일 아티팩트 내부에서 발생하는 관리되지 않은 분기다. 수천 줄짜리 파일 안에서 모든 것이 모든 것에 접근하고, 구조적 경계 없이 AI가 코드를 바꾸는 상황은 당연히 취약하다. 이 취약성은 AI가 만들었기 때문이라기보다, 분리와 격리의 구조가 없기 때문에 생긴다.
Differ의 구상에서 per-user divergence는 그 반대다. 공통 stem이 있고, 각 divergence는 bounded, isolated, reversible해야 한다. 나쁜 변형이 stem을 조용히 오염시키거나 다른 사용자에게 영향을 미치면 안 되며, 변화의 blast radius는 전체 시스템이 아니라 하나의 사용자 맥락으로 제한되어야 한다. 또한 특정 divergence는 별도의 배포 없이 라이브로 롤백될 수 있어야 한다.
개발자가 설정하는 경계와 금지 구역
적응형 소프트웨어가 의미 있게 작동하려면 개발자의 통제도 필요하다. 강연자는 예시로 전환율 개선을 위해 자동으로 조정될 수 있는 폼을 든다. 어떤 필드의 순서나 노출 방식은 사용자 행동에 맞게 바뀔 수 있지만, 개발자는 특정 필드는 절대 제거할 수 없다고 지정할 수 있다.
10:42 - 폼 최적화 예시를 통해 개발자가 적응 가능한 영역과 금지 영역을 설정할 수 있음을 설명
또한 인증(Auth)이나 결제(Payments) 같은 앱의 민감한 영역은 어떤 적응에서도 제외되어야 할 수 있다. 이때 중요한 것은 에이전트에게 무제한의 수정 권한을 주는 것이 아니라, 소프트웨어의 목적과 안전 경계 안에서만 변화가 일어나도록 만드는 것이다. 적응형 시스템은 개발자를 완전히 배제하는 구조가 아니라, 개발자가 설정한 정책과 경계 안에서 사용자별 최적화를 수행하는 구조에 가깝다.
이 접근은 기존 SaaS 제품의 확장 방식에도 변화를 준다. 예를 들어 CRM이 원래 영업 담당자를 중심으로 설계되었더라도, 투자자처럼 다른 업무 맥락을 가진 사용자가 그 제품을 쓸 수 있다. 시스템이 사용자의 반복 행동을 관찰하고, 그 사용자가 중요하게 여기는 필드와 우선순위를 학습한다면, 제품팀이 별도의 대규모 R&D 비용을 들이지 않고도 더 넓은 페르소나를 지원할 수 있다.
CRM 사례가 보여주는 적응의 구체적 모습
강연에서 제시된 CRM 사례는 적응형 소프트웨어의 감각을 구체적으로 보여준다. 한 투자자가 CRM을 사용하면서 창업자 소개를 자주 기록하고, 누가 어떤 딜을 소개했는지 반복해서 입력한다고 하자. 시스템은 이 행동을 관찰한 뒤 “intro path”와 같은 사용자의 실제 업무 흐름에 맞는 구조를 만들 수 있다.
반대로 사용자가 계속 건너뛰는 필드가 있다면, 시스템은 시간이 지나면서 그 필드를 덜 노출하고 사용자가 더 자주 필요로 하는 정보를 앞에 배치할 수 있다. 이는 단순한 UI 개인화가 아니라, 업무의 의미와 우선순위를 반영하는 변화다. 특히 사용자가 기본 시스템의 우선순위와 다른 기준으로 딜이나 창업자를 확인한다면, 시스템은 그 패턴을 학습해 사용자가 중요하게 여기는 정보를 먼저 보여줄 수 있다.
12:04 - CRM 사용자가 반복적으로 건너뛰는 필드를 시스템이 덜 노출하고 중요한 필드를 먼저 보여주는 사례
강연자는 시스템이 관찰만 하는 것이 아니라 사용자의 명시적 요청도 받아들일 수 있다고 본다. 다만 그 요청은 개발자가 설정한 경계 안에 있어야 하며, 원래 소프트웨어가 만들어진 목적과도 어긋나지 않아야 한다. 이 조건이 충족된다면 사용자는 매번 개발팀을 기다리지 않고도 자기 업무에 맞는 변화를 얻을 수 있다.
단일 아티팩트가 사라질 때 생기는 네 가지 난제
강연자는 적응형 소프트웨어가 매력적인 비전이라고 해서 쉬운 문제는 아니라고 선을 긋는다. 가장 먼저 바뀌는 것은 source of truth, 즉 무엇을 소프트웨어의 진실한 상태로 볼 것인가의 문제다. 단일 아티팩트가 없다면 “이 사용자가 무엇을 실행하고 있으며, 왜 그렇게 실행하고 있는가”는 단순한 버전 번호가 아니라 그래프 질의에 가까워진다.
따라서 각 divergence는 immutable, inspectable, attributable해야 한다. 특정 사용자의 버그 리포트는 그 사용자에게만 존재하는 프로그램을 가리킬 수 있기 때문에, 시스템은 어떤 신호가 어떤 추천으로 이어졌고, 어떤 적응이 적용되었는지 추적할 수 있어야 한다. 이 provenance가 없으면 적응형 소프트웨어는 디버깅 불가능한 블랙박스가 된다.
14:22 - 단일 아티팩트가 사라진 뒤 각 divergence가 immutable, inspectable, attributable해야 한다는 설명
두 번째 난제는 correctness다. 변경된 코드가 작동하는지, UI가 올바른지, stem뿐 아니라 가능한 divergence들까지 어떻게 테스트할 것인지가 문제가 된다. 세 번째 난제는 desirability다. 코드가 정확히 동작하더라도 그것이 실제로 좋은 변화인지, 회사가 추구하는 지표를 개선하는지 별도로 판단해야 한다. 어떤 제품에서는 retention이 목표일 수 있고, 어떤 제품에서는 churn 감소나 support ticket 감소가 목표일 수 있기 때문에, 적응의 성공 기준도 제품마다 달라진다.
자율성과 통제 사이의 긴장
적응형 소프트웨어에서 가장 민감한 문제 중 하나는 autonomy versus control이다. 보수적인 접근은 시스템이 직접 바꾸지 않고 추천만 하도록 시작하는 것이다. 강연자는 이 전략이 틀린 것은 아니라고 인정하지만, Differ의 장기적 비전은 거기에 머물지 않는다.
그들이 지향하는 것은 사용자를 충분히 잘 이해해 매번 개발자의 허락을 받지 않고도 행동할 수 있는 시스템이다. 이 경우 문제는 더 많은 통제 장치를 쌓는 것이 아니라, 인간이 한 발 물러서도 된다고 판단할 만큼 시스템을 신뢰 가능하고 읽을 수 있으며 안정적으로 만드는 것이다. 결국 핵심은 human-in-the-loop를 강제로 유지하는 것이 아니라, 인간이 스스로 loop에서 빠져나가도 괜찮다고 느끼게 만드는 수준의 legibility와 reliability를 확보하는 데 있다.
이 지점에서 강연의 낙관론은 단순한 자동화 예찬과 구별된다. 그녀는 어려운 부분이 코드 생성 자체가 아니라, 생성된 변화가 언제 적용되어야 하고, 어떻게 검증되어야 하며, 어떤 목표를 향해 조율되어야 하는지에 있다고 본다. 따라서 적응형 소프트웨어의 핵심 역량은 모델 호출이 아니라 운영 체계와 신뢰 설계에 놓인다.
코드를 병합하지 말고 의도와 결과를 병합하라
마지막 난제는 coordination이다. 모든 사용자가 자기만의 버전을 실행한다면 새로운 업데이트는 어떻게 배포되고, 변화는 수백만 개의 서로 다른 버전에 어떻게 전파될 수 있을까. 전통적인 방식은 같은 commit을 모든 사람에게 배포하는 것이지만, 적응형 소프트웨어에서는 이 모델이 그대로 유지되기 어렵다.
강연자가 제시하는 답은 “코드를 병합하지 말고, 의도와 결과를 병합하라”는 것이다. 모든 사용자가 같은 코드 조각이나 같은 commit을 실행할 필요는 없지만, 각자의 경로를 통해 같은 목표로 수렴할 수는 있다. 이는 소프트웨어 업데이트를 코드 동일성의 문제에서 목적 동일성의 문제로 바꾸는 발상이다.
17:23 - 수많은 사용자별 버전을 조율하기 위해 코드를 병합하는 대신 의도와 결과를 병합해야 한다는 설명
이 관점은 AI 시대 소프트웨어 인프라의 어려운 지점을 잘 드러낸다. 코드 생성은 쉬운 80%가 되었고, 누구나 LLM(Large Language Model)을 호출해 코드를 만들 수 있다. 그러나 관찰 가능성, 검증, 조율, provenance, stem과 divergence를 담는 substrate는 여전히 어려운 20%이며, 강연자는 바로 그 부분이 전체 비즈니스의 핵심이라고 본다.
파이프라인은 실패한 것이 아니라 전제가 사라졌다
강연의 결론은 파이프라인이 더 이상 작동하지 않기 때문에 죽는다는 주장이 아니다. 오히려 파이프라인은 자신이 만들어진 제약 조건 아래에서 매우 잘 작동했다. 문제는 그 제약, 즉 소프트웨어 변경이 비싸고 위험하기 때문에 한 번 얼려서 모두에게 보내야 한다는 전제가 사라지고 있다는 데 있다.
강연자는 핀테크에서 은행 지점이 없는 은행이 처음에는 무모하게 들렸지만 시간이 지나자 지점이 더 이상 당연하지 않게 된 사례를 든다. 마찬가지로 빌드와 CI가 한때 논쟁의 대상이었지만 지금은 기본 인프라가 된 것처럼, 적응형 소프트웨어도 처음에는 불편하고 위험하게 느껴지다가 어느 순간 당연한 형태가 될 수 있다는 것이다.
결국 다음 20년의 과제는 하나의 버전을 모두에게 안전하게 배송하는 능력에서, 각 사용자에게 맞는 버전을 안전하게 제공하는 능력으로 이동한다. 단, 이 변화가 무섭지 않으려면 isolation과 provenance가 반드시 함께 가야 한다. 강연의 진짜 메시지는 파이프라인 이후의 시대가 무질서한 코드 생성의 시대가 아니라, 더 세밀한 경계와 추적 가능성을 갖춘 개인화 실행 환경의 시대가 되어야 한다는 데 있다.
마무리 / 핵심 정리
Iris ten Teije의 강연은 AI가 코드를 생성한다는 익숙한 논의를 넘어, 소프트웨어 배포의 기본 경제학이 바뀌고 있다는 점을 전면에 세운다. 과거의 파이프라인은 변경이 비싸고 중앙화되어야 했던 시대의 합리적 산물이었지만, 변경 비용이 실행 비용에 가까워지고 에이전트가 런타임 안에서 소프트웨어를 수정할 수 있게 되면 개발과 배포의 경계는 더 이상 고정된 선으로 남기 어렵다.
그러나 이 비전은 단순히 사용자마다 다른 코드를 무한히 생성하자는 이야기가 아니다. 강연자가 제안하는 핵심은 하나의 stem과 bounded, isolated, reversible한 divergence를 통해 개인화를 안전하게 다루는 아키텍처다. 앞으로 중요한 경쟁력은 모델에게 코드를 쓰게 하는 능력보다, 변화의 출처를 추적하고, 올바름과 바람직함을 검증하며, 서로 다른 사용자 버전들이 같은 의도와 결과로 수렴하도록 조율하는 능력에 있을 것이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | The Pipeline Is Dead - Iris ten Teije, Sky Valley Ambient Computing |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-07 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.