OS kim 님이 2026년 10월 4일에 정리한 FDE 프레임
프로필에 Samsung Electronics AX PM, FDE Leader로 표시된 OS kim 님이 2026년 10월 4일(한국 시각) LinkedIn에 DX, AX, RX를 하나의 흐름으로 정리한 글을 올렸습니다. 이 글에서는 그 게시물을 바탕으로, 에이전트에게 맡기는 일의 범위와 검증 시점이 단계마다 어떻게 달라지는지 읽어 봅니다. 저자의 주장과 예상은 "저자는"으로 시작하는 문장으로 구분했고, 제 해석은 "제가 보기에는"으로 따로 표시했습니다.
저자는 Transformation을 새 기술 도입으로 보지 않습니다. 고객이 일하는 방식이 바뀌고, 그 방식이 운영에 정착해 성과로 확인되어야 Transformation이라고 봅니다. 저자는 데모가 작동하는 것과 현장에서 매일 쓰이는 것은 다른 문제라고 덧붙였습니다. 어느 단계든 FDE가 하는 일은 같다고 봅니다. 고객 현장의 문제를 정의하고, 동작하는 것을 만들고, 운영까지 넘긴다고 설명합니다. 대신 단계에 따라 시스템이 닿는 범위가 달라지며, 저자는 DX는 데이터와 화면, AX는 판단과 업무 흐름, RX(Robot Transformation)는 물리 세계까지 닿는다고 구분했습니다.
저자는 이 순서를 반드시 따를 필요는 없다고 단서를 달았습니다. 로봇 도입이 먼저인 고객도 있을 수 있어서 하나의 프레임으로 본다고 했습니다. 이 글에서도 DX·AX·RX를 정해진 로드맵으로 읽지 않고, 맡기는 범위를 비교하는 틀로 씁니다.
단계마다 달라지는 질문과 틀렸을 때의 비용
저자는 단계마다 다른 질문을 붙였습니다. DX에서는 "데이터가 모이고 흐르는가"를 묻습니다. 흩어진 기존 시스템의 데이터를 이어서 뒤 단계에서 쓸 수 있는 품질로 만드는 일이 중심이고, 저자는 이 단계의 실수는 되돌리기 쉽다고 봅니다. AX에서는 "AI가 믿을 만하게 판단하는가"를 묻습니다. 에이전트가 맡을 업무와 사람이 끼어들 위치를 먼저 정하고, 평가셋으로 확인한 다음 운영에 넘긴다고 설명합니다. 여기서 틀리면 잘못된 판단이 나오고 신뢰가 떨어진다고 했습니다.
RX에서는 "로봇이 현장에서 안정적으로 버티는가"를 묻습니다. 저자는 현장의 동작·대상물·환경을 로봇이 풀 수 있는 문제로 바꾸고, 시뮬레이션 검증과 실제 장비 검증을 따로 진행해 sim-to-real 격차(시뮬레이션과 실제 현장의 차이)를 관리해야 한다고 봅니다. 이 단계의 실패는 설비 손상, 안전 사고, 라인 정지로 이어진다고 했습니다.
아래 도식에는 저자가 쓴 단계별 질문과 실패 비용을 계단 모양으로 놓고, 맨 아래 줄에 에이전트에게 맡기는 방식에 대한 제 해석을 붙였습니다.
검증이 무거워지고 이전 단계 자산은 계속 쓰입니다
저자는 단계가 올라갈수록 달라지는 점도 정리했습니다. 먼저 검증이 무거워집니다. 저자에 따르면 DX는 배포한 뒤에 고쳐도 되지만, RX는 "현장 투입 전 검증이 거의 전부"입니다. 만나야 할 고객 쪽 담당자도 IT 부서에서 현업, 설비, 안전 담당으로 넓어지고, 로봇 하드웨어·모델·통합 파트너와 조율하는 일이 커져 혼자 끝낼 수 없다고 했습니다. RX 현장에도 데이터 연동, 운영 자동화, 모니터링이 필요하므로 이전 단계의 자산이 계속 쓰인다고 봤습니다.
제가 보기에는 이 변화가 에이전트 업무를 설계할 때도 그대로 적용됩니다. 결과를 쉽게 되돌릴 수 있는 일은 에이전트에게 넓게 맡기고, 실행한 뒤에 고쳐도 됩니다. 판단이 들어가는 일은 맡기기 전에 사람이 개입할 위치와 평가 기준을 정해야 합니다. 되돌릴 수 없는 결과를 내는 일은 실행 전에 확인을 끝내야 합니다. 실무에서는 단계 이름보다 "틀렸을 때 되돌릴 수 있는가"를 기준으로 맡길 범위를 정하는 편이 쓰기 쉽습니다.
개인 에이전트에 대입해 보면
저자는 이 프레임에서 가장 흥미로운 주제로 개인 에이전트를 꼽았습니다. 저자는 9월에 Meta가 Muse를, OpenAI가 dots를 공개했고, 둘 다 전용 클라우드 컴퓨터에서 계속 작동하며 사용자를 대신해 일을 처리하는 에이전트라고 소개했습니다. Muse는 저자의 소개로만 두고, 아래에서는 OpenAI 공식 발표로 확인한 dots를 살펴봅니다.
OpenAI는 2026년 9월 29일 dots를 발표했습니다. 발표문에 따르면 dot은 자체 클라우드 컴퓨터를 갖추고 사용자의 목표를 향해 24시간 일할 수 있습니다. 발표 당일부터 지원 지역의 Pro 및 Business Premium 사용자에게 ChatGPT에서 순차 제공하고, Enterprise 사용자(Edu 및 Healthcare 포함)는 워크스페이스 관리자가 베타 기능을 켜면 쓸 수 있다고 했습니다. 발표문은 맞춤 규칙으로 특정 행동을 허용하거나, 승인을 요구하거나, 차단할 수 있다고 설명합니다.
같은 날 공개된 OpenAI의 안전 설명 글은 기본 규칙을 더 자세히 적었습니다. 메시지를 보내거나 파일을 공유할 때는 공유할 정보와 수신자 유형에 대한 허가를 받도록 했고, 데이터를 영구 삭제하거나 알 수 없는 출처의 소프트웨어를 설치·실행하거나 보안에 민감한 새 접근 권한을 주는 행동은 매번 사용자의 확인이 필요합니다. 비밀번호 변경이나 금융 계좌 간 송금은 dot이 관련 작업을 돕더라도 그 단계 자체는 사용자가 직접 해야 합니다.
저자는 개인 에이전트 다음도 예상했습니다. 이런 에이전트가 몸을 얻으면 개인화된 로봇이 될 것이라고 봤고, 공식 발표된 계획은 아니며 어디까지나 자신의 예상이라고 밝혔습니다. 공장 로봇은 공정 하나를 풀면 되지만 개인 로봇은 집과 물건, 습관이 사람마다 달라 환경의 다양성이 핵심 문제가 된다고 보고, 저자는 이 영역을 기회가 많은 블루오션으로 봤습니다.
제가 보기에는 dots의 허용·승인 요구·차단 규칙이 저자가 AX 단계에서 말한 "사람은 어디서 개입할지"를 제품 설정으로 옮겨 놓았습니다. 다만 이 규칙은 화면 안에서 일어나는 행동을 다룹니다. 저자의 예상대로 에이전트가 물리 세계로 나간다면, RX 단계의 투입 전 검증이 같은 규칙 위에 더해져야 한다고 봅니다.
권한·승인·안전 설계를 처음부터 함께 가져가야 한다는 견해
저자는 개인 에이전트를 기회로 보면서도 조건을 달았습니다. 화면 안의 에이전트가 실수하면 정보가 새지만, 몸이 있는 에이전트가 실수하면 물건이 부서지고 사람이 다칠 수 있다고 했습니다. 그래서 "권한, 승인, 안전 설계가 처음부터 같이 가야 합니다"라고 썼습니다.
아래 표는 이 견해를 화면 안의 에이전트에 먼저 적용해 본 예시입니다. 3행과 4행의 규칙은 OpenAI 안전 설명 글에 적힌 dots 기본 규칙이고, 1행과 2행의 분류와 오른쪽 검증 시점은 제 판단입니다.
| 행동 예시 | 틀렸을 때 | 규칙 | 검증 시점 |
|---|---|---|---|
| 자료 읽기, 초안 작성 | 고쳐 쓰면 됨 | 허용 | 결과를 받은 뒤 검토 |
| 메일 발송, 파일 공유 | 받는 사람이 생김 | 승인 요구 | 보내기 전 수신자와 내용 확인 |
| 데이터 영구 삭제, 보안 권한 부여 | 되돌리기 어려움 | 매번 사용자 확인(OpenAI 기본 규칙) | 실행 전 확인 |
| 비밀번호 변경, 계좌 간 송금 | 민감한 단계 | 사용자가 직접(OpenAI 기본 규칙) | 에이전트는 준비까지만 |
이번 주에 해 볼 첫 단계
에이전트에게 맡기려는 업무 1건을 골라, 그 업무에 들어 있는 행동을 모두 적어 보십시오. 행동마다 틀렸을 때 되돌릴 수 있는지, 영향을 받는 사람이 누구인지 적고, 허용·승인 요구·차단 가운데 하나를 정합니다. 승인이나 차단으로 정한 행동은 실제 업무에서 나온 사례 10건으로 작은 평가셋을 만들어, 에이전트에게 넘기기 전에 결과를 확인하십시오.