7. 제품 기반과 운영 비용

고객의 업무를 자동화하는 방법은 많아졌다. 기존 SaaS에서 데이터를 읽고, 에이전트가 내용을 판단하고, 다른 시스템에 결과를 기록할 수 있다. 필요한 화면도 빠르게 만들 수 있다. 첫 시연에서는 사람이 여러 화면을 오가던 일이 한 번에 처리된다.

그다음부터 새로운 일이 생긴다. 연결한 서비스의 인증이 만료되고, 고객의 승인 규칙이 바뀌고, 작업이 중간에 멈춘다. 담당자가 퇴사하면 새 담당자에게 사용법과 예외 처리 방법을 가르쳐야 한다. 이런 변경을 맡을 곳이 없다면 최초 개발자가 계속 운영자가 된다.

FDE가 고객별로 무엇을 만들 수 있는지와, 만든 시스템을 계속 유지할 수 있는지는 함께 검토해야 한다. 여러 프로젝트가 공유할 기반이 없으면 고객이 늘어날 때마다 관리할 코드와 업무 절차도 늘어난다. 중심 제품이 없는 조직에서 FDE를 운영할 때 가장 먼저 부딪히는 문제다.

공통 제품의 역할

팔란티어의 FDE를 이해하려면 고객 가까이에서 일하는 엔지니어뿐 아니라 그 엔지니어가 사용하는 플랫폼도 보아야 한다. 팔란티어는 AIP를 Foundry와 Apollo에 연결해 설명한다. 데이터 통합, 업무 객체와 관계를 표현하는 Ontology, 실행 권한과 소프트웨어 배포를 같은 플랫폼 안에서 다룬다. Palantir 플랫폼 설명

이 구조에서는 고객별 업무를 개발하더라도 데이터 연결이나 권한 관리, 배포 도구를 처음부터 모두 만들 필요는 없다. 공통 기반 위에 고객의 데이터와 업무 규칙을 반영하는 데 개발을 집중할 수 있다. 같은 플랫폼을 사용하는 엔지니어 사이에서는 작업을 설명하고 인수하는 방법도 공유하기 쉽다.

그렇다고 플랫폼이 고객의 업무를 자동으로 이해하거나 모든 비용을 없애는 것은 아니다. 데이터의 뜻을 맞추고, 권한을 설정하고, 사용자를 교육하는 일은 남는다. 플랫폼 사용료와 학습 비용, 특정 기술에 대한 의존도 함께 고려해야 한다. 공통 제품의 가치는 이런 비용을 부담하면서도 고객별로 다시 만들고 관리할 부분을 얼마나 줄일 수 있는지에 있다.

자체 플랫폼이 없어도 같은 원리를 적용할 수 있다. 고객이 이미 쓰는 시스템이 인증, 권한, 업무 기록과 관리 화면을 제공한다면 그 위에 필요한 기능을 붙일 수 있다. 작은 조직이 모든 기반을 직접 개발해야 하는 것은 아니다. 다만 어느 기능을 기존 제품에 맡기고 어느 부분을 자신이 유지할지는 분명해야 한다.

SaaS 조합의 운영 부담

다음은 가상의 주문 처리 자동화 사례다. 고객은 CRM에 들어온 요청을 확인하고, 결제 서비스에서 처리한 뒤, 담당자에게 결과를 알리는 일을 자동화하고 싶어 한다. 구축팀은 에이전트와 워크플로 서비스를 연결하고, 처리 현황을 보여주는 관리자 화면을 만든다.

정상적인 요청은 잘 처리된다. 그런데 결제는 성공했지만 CRM에 결과를 기록하는 단계가 실패했다고 하자. 관리자 화면에는 작업이 미완료로 보인다. 담당자가 다시 실행하면 결제를 중복 처리할 수 있다. 이를 막으려면 어느 단계까지 완료됐는지 보관하고, 외부 서비스의 실제 상태를 확인하고, 안전하게 이어서 실행할 방법이 필요하다.

각 SaaS가 자기 기능을 정상적으로 제공해도 연결한 전체 업무에는 별도의 설계가 필요하다. 에이전트가 오류 메시지를 읽고 재시도할 수 있다는 것만으로는 중복 처리나 잘못된 변경을 막기 어렵다. 이미 실행된 작업과 다시 실행해도 되는 작업을 구분하는 규칙이 있어야 한다.

비싼 SaaS를 쓴다는 사실만으로 비효율적이라고 판단할 수는 없다. 안정적인 운영 기능을 구매해 직접 개발할 일을 줄일 수도 있다. 하지만 구독료를 지불하면서 별도 화면에 같은 기능을 다시 만들고, 연결한 시스템 전체의 지원까지 맡는다면 비용 절감 효과가 작아질 수 있다. 각 서비스가 대신 맡아주는 일과 여전히 구축팀에 남는 일을 나눠 보아야 한다.

관리자 화면과 교육

관리자 화면은 처음에는 처리 결과를 보여주는 목록으로 시작할 수 있다. 사용자가 늘면 부서별 권한이 필요하고, 승인자를 지정해야 하며, 누가 무엇을 바꿨는지 확인할 이력도 필요해진다. 실패한 작업을 고치는 기능까지 추가되면 별도의 업무용 제품을 운영하는 것과 비슷해진다.

화면을 만드는 시간보다 화면이 표현하는 업무 상태를 일관되게 유지하는 일이 더 어려울 수 있다. CRM과 결제 서비스의 상태가 다를 때 어느 값을 보여줄지, 운영자가 직접 수정해도 되는지, 수정 후 다른 시스템에 어떻게 반영할지 정해야 한다. 고객별 화면이 늘어날수록 이런 결정을 이해하고 유지할 사람도 필요하다.

교육도 버튼 사용법에서 끝나지 않는다. 사용자는 자동화가 처리하는 범위와 사람이 확인해야 할 상황을 알아야 한다. 운영자는 실패를 발견하고 재처리하는 절차를 배워야 한다. 개발을 인수할 사람은 데이터 흐름과 외부 서비스의 제약까지 이해해야 한다. 같은 시스템이라도 역할에 따라 필요한 교육이 다르다.

기존 업무 화면 안에서 결과를 확인하고 승인할 수 있다면 사용자가 새로 배울 부분을 줄일 수 있다. 별도 화면이 필요하더라도 고객마다 로그인, 오류 표시와 재처리 방식을 새로 설계하지 않는 편이 운영에 도움이 된다. 다만 화면을 통일했다고 고객별 업무 교육까지 없어지는 것은 아니다.

구축비와 유지비

프로젝트의 총비용에는 초기 개발 외에 구독료, 실행 비용, 변경 대응, 평가, 장애 처리와 교육이 들어간다. 첫 구축이 빨라졌다는 사실만으로 이후 비용까지 줄었다고 볼 수는 없다. AI로 코드를 빨리 생성해도 유지해야 할 시스템과 외부 의존성이 늘어나면 관리 업무는 커질 수 있다.

공급사와 고객이 부담하는 비용도 구분해야 한다. 고객이 SaaS 구독료를 직접 내더라도 구축업체에는 기술 지원 시간이 남는다. 구축업체가 지원을 하지 않는 계약이라면 그 부담은 고객의 운영팀으로 넘어간다. 견적에서 빠진 일이 실제 업무에서 사라지는 것은 아니다.

공통 모듈을 만드는 데에도 비용이 든다. 여러 고객 환경에서 쓸 수 있도록 인터페이스와 테스트를 마련하고, 버전을 관리하고, 기존 고객에게 변경을 적용해야 한다. 고객별 코드를 복사한 뒤 각각 수정하기 시작하면 처음의 개발 시간은 줄어도 유지할 갈래는 계속 늘어난다. 재사용의 효과는 첫 복사보다 이후의 수정과 배포에서 확인된다.

최근 기업 사례

OpenAI는 2026년 10월 공개한 FDE 사례에서 초기 맞춤 애플리케이션을 다른 팀으로 확장하는 데 통합 부담이 컸다고 설명했다. 이후 Codex 중심의 공통 구조로 옮기고, 개별 인터페이스를 없애고, 기능을 플러그인과 스킬로 정리했다고 보고했다. 회사가 공개한 사례이므로 일반적인 절감 효과로 단정할 수는 없지만, 운영에 들어간 맞춤 구현도 다시 공통 제품 위로 정리하는 과정이 필요했다는 점을 보여준다. OpenAI FDE 사례

OpenAI의 Frontier 소개에는 공유 업무 정보, 에이전트 실행, 평가와 권한 관리가 함께 등장한다. Anthropic의 FDE 관리자 공고에도 공통 저장소, 연동 템플릿과 반복 가능한 작업 절차를 만드는 책임이 포함된다. 제품을 통한 통합과 팀 내부 자산의 표준화라는 차이는 있지만, 프로젝트마다 모든 것을 새로 만들지 않으려는 방향을 읽을 수 있다. Frontier 소개, Anthropic FDE 관리자 공고

이런 사례에서 참고할 것은 사용한 도구의 목록뿐 아니라 기존 구현을 어떻게 줄이고 다음 프로젝트에 무엇을 남겼는지다. 겉으로 보이는 자동화만 따라 만들면 그 뒤에서 비용을 줄이는 공통 기반과 운영 조직을 놓치기 쉽다.

제품사와 구축업체

제품사의 FDE는 고객 프로젝트를 통해 제품의 부족한 부분을 발견하고 개선할 수 있다. 그 개선이 다른 고객에게도 적용되면 한 프로젝트의 경험이 제품 전체에 영향을 준다. 고객의 사용 확대 역시 제품사의 사업과 연결될 수 있다.

독립 구축업체는 같은 방식으로 비용을 회수한다고 가정하기 어렵다. 외부 SaaS의 사용량을 늘려도 그 구독 매출이 구축업체에 돌아오는 것은 아니다. 별도 계약이 없다면 고객의 도입을 돕는 데 들어간 비용은 구축 대금과 유지보수 대금 등 자신의 수입으로 충당해야 한다. 제품사에 유효한 전략이 작은 구축업체에도 같은 경제성을 갖는지는 따로 계산해야 한다.

맞춤 개발과 운영을 사업으로 하는 선택은 가능하다. 고객별 변경과 지원에 필요한 인력을 가격과 계약에 반영하면 된다. 다만 고객마다 다른 시스템을 계속 관리하면서 공통 SaaS처럼 고객 수만 늘릴 수 있다고 기대하면 인력 계획이 어긋난다. 장기 지원까지 낮은 고정 요금에 포함하려면 업무 범위와 변경 조건이 그 요금 안에서 유지될 수 있어야 한다.

중심 제품이 없는 조직의 선택

가장 먼저 검토할 방법은 고객의 기존 기반을 활용하는 것이다. 고객이 이미 운영하는 CRM이나 ERP, 인증 체계와 관리 화면에 기능을 붙이면 새로 유지할 부분을 줄일 수 있다. 대신 고객의 기술 조직이 연동과 변경을 받아들일 수 있어야 한다. 기존 시스템이 있다는 사실만으로 이 조건이 충족되지는 않는다.

두 번째는 업종과 업무를 좁히는 방법이다. 비슷한 고객의 같은 업무를 반복해서 해결하면 공통 데이터 구조와 연동, 평가 사례와 운영 도구를 축적할 가능성이 커진다. 어느 부분이 정말 반복되는지 알아보기 전에 큰 플랫폼부터 만들면 쓰이지 않는 기능의 비용을 떠안을 수 있으므로 실제 프로젝트에서 공통점을 확인하며 범위를 넓혀야 한다.

세 번째는 고객별 구축·운영을 명시적으로 제공하는 방법이다. 재사용보다 개별 요구의 가치가 크다면 그에 맞는 개발과 지원을 판매할 수 있다. 이 경우 고객이 늘 때 필요한 운영 인력도 함께 계획해야 한다.

이 선택들은 함께 사용할 수 있다. 고객의 기존 시스템을 활용하면서 특정 업무의 연동과 평가 도구만 공통으로 관리할 수도 있다. 중요한 것은 고객별로 남는 업무를 숨기지 않고, 누가 어떤 비용으로 이어갈지 정하는 것이다.

확장 가능성

두 번째 고객을 맡을 때 첫 번째 프로젝트의 무엇을 그대로 사용할 수 있는지 살펴보면 사업의 구조가 드러난다. 같은 코드와 운영 도구를 쓰고, 새 담당자가 같은 절차로 배포할 수 있다면 경험이 축적되고 있는 것이다. 반대로 화면과 예외 규칙이 매번 갈라지고 최초 개발자만 수정할 수 있다면 고객 수만큼 지원 부담이 늘어날 수 있다.

공통화 자체도 성과로 단정할 수는 없다. 하나의 변경을 모든 고객에게 적용하기 위해 과도한 테스트와 조율이 필요하다면 고객별 차이를 잘못 묶었을 수 있다. 어느 범위를 함께 유지할 때 비용이 줄어드는지 실제 변경과 지원 기록으로 판단해야 한다.

프로젝트가 늘어날수록 새 개발에 쓸 시간, 기존 고객을 지원하는 시간, 공통 자산을 관리하는 시간을 함께 살펴야 한다. 개발은 빨라졌는데 운영 부담이 더 빠르게 늘어난다면 자동화의 수보다 사업 범위와 유지 방식을 먼저 조정할 필요가 있다.

핵심 요약

자체 플랫폼이 없어도 FDE 방식으로 일할 수 있다. 다만 여러 프로젝트가 함께 사용할 기반과 유지 책임은 필요하다. SaaS·에이전트·관리자 화면을 조합한 시스템의 비용에는 연결 이후의 변경, 장애, 교육과 인수인계가 포함된다. 고객이 늘수록 재사용할 부분과 새로 떠안을 운영 부담이 어떻게 달라지는지가 지속 가능성을 결정한다.