AI VIDEO BRIEFING
적응형 소프트웨어: 에이전트가 런타임이 될 때 배포 파이프라인이 사라지는 이유
소프트웨어를 만드는 비용이 0에 수렴하면서 '모두에게 하나의 버전'이라는 전제가 무너진다. 사용자마다 다른 버전을 안전하게 운영하는 스템·분기 구조를 다룬 강연 정리.

핵심 메시지
쉽게 이해하기
AI Engineer 무대에 오른 Differ의 공동창업자 Iris ten Teije는, 우리가 오래 써온 소프트웨어 배포 방식을 다시 보자고 제안한다. CI 파이프라인, 패키저, 레지스트리, 컨테이너 이미지, 앱스토어 심사로 이어지는 거대한 스택은 결국 하나의 문제를 푼다. 빌드된 기계에서 실행되는 기계로 '고정된 산출물'을 안전하고 재현 가능하게 한 번 옮기는 일이다. 그 밑에는 '모두에게 하나의 버전'이라는, 너무 오래돼 선택이라는 사실조차 잊힌 전제가 깔려 있다.
이 전제는 임의로 정해진 것이 아니라 비용의 결과였다. 올바른 변경을 만드는 데 숙련된 사람의 시간이 오래 들었기 때문에 소프트웨어 제작은 드물고 중대한 사건이었고, 그래서 한 번 검증해 고정한 뒤 모두에게 배포했다. 고정된 산출물은 재현성·미리보기·롤백이라는 이점을 주지만, 대신 소프트웨어가 특정한 누군가를 위한 것이 될 수는 없었다. 사용자별로 다른 소프트웨어를 주려면 코드베이스를 갈라 손으로 관리해야 했기에 애초에 선택지가 아니었을 뿐이다.
그런데 그 비용이 바뀌었다. 발표자는 AI 코딩 자체보다, 올바르고 범위가 좁은 변경을 만드는 비용이 0을 향해 무너지고 있다는 점, 그리고 그 제작이 더 이상 실행 전에 한 곳에서 미리 끝날 필요가 없다는 점을 강조한다. 일부는 서버에서, 일부는 클라이언트에서, 일부는 사용자의 실시간 세션에서 만들어질 수 있게 되면 개발과 배포를 분리할 이유가 녹아 없어진다.
수요 측면에서도 개인화된 소프트웨어에 대한 요구는 늘 있었다. 대형 고객의 슬랙 채널에 상주하는 포워드 배포 엔지니어와 전문 서비스, 개발자가 기기마다 다시 세팅하는 설정 파일과 키 바인딩, 그리고 수백만 명이 그 위에 자기만의 프로그램을 쌓아 올리는 엑셀이 그 증거다. 피처 플래그·세그먼트·A/B 테스트는 그 예고편이었지만, 미리 선언한 버킷이라는 틀에 갇혀 있었다. 이제는 소프트웨어가 진짜로 적응할 수 있다.
Differ의 베팅은 '에이전트가 런타임이 되는' 순간 개발과 배포의 경계가 사라진다는 것이다. 하나의 표준 스템을 배포하고 사용자마다 같은 기원에서 갈라진 개별 분기를 실시간으로 돌린다. 한 CTO의 '수백만 개의 AI 코드베이스를 운영하라는 건 악몽'이라는 반박에 대해, 발표자는 취약함의 정체가 경계 없는 하나의 뒤엉킨 산출물이지 AI 생성 자체가 아니라고 답한다. 스템 위의 분기들은 경계가 있고 격리되며 되돌릴 수 있어, 한 변경의 파급 범위는 한 사용자의 맥락으로 제한되고 배포 없이 즉시 롤백된다. 개발자는 폼의 특정 필드나 결제·인증처럼 절대 바꿀 수 없는 영역을 지정할 수 있다.
주요 인사이트
- 고정된 산출물이 주던 재현성·롤백·미리보기는 '하나의 변하지 않는 산출물'이라는 사실에서 나왔다. 그 전제를 지우면 신뢰 구조를 다시 세워야 한다.
- 취약함은 AI가 코드를 짜서가 아니라 경계가 없어서 생긴다. 스템+격리된 분기 구조는 파급 범위를 한 맥락으로 좁혀 오히려 안전을 높인다.
- 예시로 든 CRM은 영업사원 기준으로 만들어졌지만, 투자자 사용자가 자주 쓰는 소개 경로를 관찰해 살리고 안 쓰는 필드를 감춰 개인에 맞게 적응한다.
- 어려운 부분은 생성이 아니다. 진실의 출처(스템+불변 분기), 정확성 검증, 바람직함(실제 개선이었는가), 자율성 대 통제, 조율이 진짜 사업의 핵심이다.
- 조율의 답은 '코드를 합치지 말고 의도와 결과를 합치라'는 것. 모두가 같은 커밋을 돌리지 않아도 각자의 경로로 같은 목표에 수렴하게 한다.
자주 묻는 질문
왜 '하나의 버전을 모두에게'가 지금까지 유지됐나?
소프트웨어를 올바르게 만드는 일이 비싸고 드물었기 때문이다. 사용자별로 다른 버전을 주려면 코드베이스를 갈라 손으로 관리해야 했으므로, 애초에 현실적인 선택지가 아니었다.
수백만 개의 사용자별 버전을 운영하면 관리가 불가능해지지 않나?
발표자는 취약함이 경계 없는 하나의 뒤엉킨 산출물에서 온다고 본다. 스템 위의 분기는 경계가 있고 격리·되돌리기가 가능해 파급 범위가 한 사용자 맥락으로 제한되고 배포 없이 롤백된다.
적응형 소프트웨어에서 가장 어려운 문제는 무엇인가?
코드 생성이 아니라 관측 가능성, 검증, 조율이다. 진실의 출처를 스템과 불변 분기로 정의하고, 변경이 실제 개선인지 측정하며, 코드가 아니라 의도와 결과를 합치는 것이 핵심 과제다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗