데이터 처리에서 데이터 프라이머시로: 에이전틱 시대가 바꾸는 업무와 IT 아키텍처

“엔터프라이즈 생성형 AI 파일럿 프로젝트의 95%는 측정 가능한 재무적 성과나 손익계산서(P&L)에 긍정적인 영향을 미치지 못한 채 실패합니다.” – MIT

“새로운 질서를 도입하는 데 앞장서는 것보다 더 어렵고, 더 위험하며, 성공 여부가 더 불확실한 일은 없다.” – 니콜로 마키아벨리, 『군주론』

우리가 두 이야기를 하나의 타임라인에서 다루는 이유는 처음부터 서로 다른 이야기가 아니었기 때문입니다. 모든 시대에 조직이 데이터를 보유하는 방식은 업무를 조직할 수 있는 방식을 결정했고, 업무를 조직하는 방식은 조직이 데이터로 무엇을 할 수 있는지를 결정했습니다. 구두장이, 사무원, EDP 부서, ERP 사용자, AI 에이전트는 모두 같은 흐름에서 이어지는 단계입니다.

데이터 프라이머시(Data Primacy)가 프로세스 설계와 함께 핵심적인 ‘작동 방식’으로 다시 등장한 것처럼, 역할 기반 업무에서 역량 기반 업무로 이동하는 흐름은 인간과 AI 에이전트가 공존하는 하이브리드 미래를 가능하게 하는 요소입니다. AI 에이전트와 모델의 역량이 계속 향상됨에 따라 업무 수행 방식도 함께 발전할 수 있습니다.

오후 3시까지 보스턴에 도착하기

30년 전에는 여행을 계획하려면 지도, 시간표, 예약 정보, 추천 사항을 모은 뒤 직접 여행 일정을 짜야 했습니다. 우리가 직접 정보 시스템 역할을 했습니다. 이후 애플리케이션은 항공편, 호텔, 지도, 비용 보고서 등 여정의 각 요소를 디지털화했지만, 우리는 여전히 애플리케이션 사이를 오가며 한 시스템의 맥락을 다음 시스템으로 옮겨야 했습니다. 우리는 통합 계층이 된 것입니다.

이제 다음과 같이 말하는 상황을 상상해 보겠습니다. “1,000달러 이하의 예산으로 오후 3시까지 보스턴에 도착하게 해 줘. 비용이 많이 드는 변경을 해야 할 때는 먼저 나에게 물어봐.” AI는 데이터가 어디에 있든 캘린더, 정책, 선호 사항, 일정, 가격, 날씨 정보를 종합해  원하는 결과를 제공하는 데 필요한 애플리케이션과 AI 에이전트, 인간을 오케스트레이션할 수 있습니다. 애플리케이션을 지정하지 않았습니다. 역할도 지정하지 않았습니다. 목적지와 예산, 통제 조건을 지정했을 뿐입니다.

엔터프라이즈 컴퓨팅도 놀라울 정도로 비슷한 변화를 거쳤습니다. 인간은 정보를 조직했고, 애플리케이션은 데이터와 업무를 조직했으며, 이제 AI는 데이터와 결과를 중심으로 조직할 수 있도록 지원합니다. 우리가 그동안 사용해 온 용어를 보면, 각 시대에 기계를 어떤 용도로 여겼는지 알 수 있습니다.

하나의 타임라인, 두 가지 질문

기업 조직의 모든 시대는 다음 두 가지 질문으로 살펴볼 수 있습니다.

데이터는 어디에 존재하며, 누가 소유합니까?

업무 단위는 무엇이며, 누가 수행합니까?

두 질문에 대한 답은 언제나 서로 연결돼 있었고 함께 움직였습니다. 데이터가 장인의 머릿속에 있을 때 업무의 단위는 완성된 신발이었습니다. 데이터가 애플리케이션의 스키마에 있을 때 업무의 단위는 해당 애플리케이션을 운영하는 역할이었습니다. 데이터가 애플리케이션에서 빠져나오고 업무가 역할에서 벗어나는 두 가지 전환이 지금 동시에 일어나는 이유도 바로 이 연결 관계 때문입니다.

같은 현상을 서로 다른 방향에서 바라본 것입니다.

기술 발전은 인간의 삶을 더 편안하고 풍요롭게 만드는 방향으로 꾸준히 발전해 왔습니다. 이를 위해 기술 발전은 노동 효율성과 과학·공학의 활용에 집중해 왔습니다. 산업혁명 이후에는 외부 에너지를 사용해 인간이나 동물의 노동, 그리고 이제는 인간의 활동을 대체하는 데 초점을 맞췄습니다. 따라서 각 시대의 발전은 시간 절약, 노동 절감, 조정 능력 향상, 외부 에너지를 통한 인간 에너지의 대체 중 하나 이상을 달성해야 했습니다. 우리가 자주 활용하는 이 슬라이드는 산업혁명과 현재의 AI 혁명에서 이러한 과정이 어떻게 작동했는지, 그리고 그 중간에 제2차 세계대전 이후의 제조 자동화가 어떻게 자리했는지를 설명합니다.

그럼 다시 본론으로 돌아가 이러한 진화를 살펴보겠습니다.

각 시대를 거치면서 인간의 전문성은 특정한 하나의 결과에 집중하는 방식에서 점차 벗어났습니다. 1800년대 구두장이의 견습생과 오늘날 인문학을 전공하는 대학생이 이수하는 과정을 비교해 보겠습니다. Malcolm Gladwell의 『Outliers』를 기준으로 보면 견습생이 구두장이가 되려면 최소 10,000시간의 훈련이 필요했을 것입니다. 반면 오늘날에는 AI 코드 생성과 같은 기술도 온라인에서 몇 주 만에 배울 수 있습니다.

이 글의 나머지 부분에서는 이러한 타임라인을 살펴본 뒤, 인간과 AI 에이전트가 함께 일하는 하이브리드 업무를 성공적으로 수행하기 위해 무엇을 해야 하는지 정리합니다.

장인, 장부와 서신(1770년 이전)

업무 자체가 기준이었습니다. 산업화 이전에는 대부분의 업무가 결과를 중심으로 조직됐습니다. 구두장이는 신발을 만들었습니다. 상인은 거래를 완료했습니다. 서기는 장부를 관리했습니다. 물론 전문화는 존재했지만, 오늘날 우리가 ‘직무’라고 부르는 개념이 기업 업무를 분해하는 지배적인 방식은 아니었습니다. 작업자는 완성된 결과물과 직접 맞닿아 있었고, 대체로 결과 전체에 책임을 졌습니다.

이 시대의 데이터는 독립적으로 존재하지 않았습니다. 데이터는 실무자의 기억 속에, 카운터 아래의 장부에, 손으로 전달되는 서신에 존재했습니다. 기록은 정확히 하나뿐이었습니다. 업무를 수행하는 사람이 그 기록을 소유했으며, 어떤 기록이 공식적인지 따질 필요도 없었습니다. 기록이 하나뿐이었고, 서 있는 자리에서 직접 확인할 수 있었기 때문입니다. 데이터를 맞추는 일은 별도의 산업이 아니었습니다. 대화로 해결했습니다.

한계는 규모에 있었습니다. 조직은 한 명의 책임자가 동시에 파악하고 책임질 수 있는 결과의 수만큼만 성장할 수 있었습니다.

산업 시대(1770~1910년)

산업화는 업무를 역할로 바꿨습니다. 애덤 스미스의 분업, 이어서 테일러와 포드의 방식은 결과를 반복 가능한 단계로 나누고, 사람을 각 단계에 맞게 전문화하며, 각 단계 사이의 접점을 관리하는 것이었습니다. 획기적인 변화는 단순히 기계화만이 아니었습니다. 인간이 프로세스 아키텍처의 구성 요소가 된 것이 핵심이었습니다. 이렇게 되면 직무는 반복 가능한 과업을 묶어 담는 틀이 되고, 기업은 결과가 아니라 이러한 컨테이너를 중심으로 설계되기 시작합니다.

하나의 결과를 여러 단계로 나누는 순간 새로운 문제가 생깁니다. 각 단계를 조율해야 하며, 이를 조율하려면 데이터가 필요합니다. 이것이 이 시대에 충분히 조명되지 않은 이야기이며, Stephen Ambrose는 『Nothing Like It in the World』에서 그 측면을 잘 보여줍니다. 대륙횡단철도의 핵심은 우리가 흔히 생각하는 의미의 공학적 성취에 있지 않았습니다. 대륙횡단철도 건설은 어느 한 사람도 전체를 머릿속에 담을 수 없을 만큼 큰 규모의 첫 번째 업무였습니다. 수천 명의 노동자, 양쪽 해안에서 서로를 향해 건설을 진행한 두 기업, 대륙을 가로지르는 공급망을 하나의 작업으로 조율해야 했습니다. 이 과정에서 철도와 함께 현대적 기업도 탄생했습니다. 사업부 구조, 문서화된 운영 규칙, 표준화된 보고 체계, 그리고 단순한 신기술이 아니라 관리 도구로 활용된 전신이 함께 만들어졌습니다. 철도는 두 지역의 데이터가 같은 의미를 갖도록 공통의 시간 기준이 필요했고, 그 결과 표준시가 만들어졌습니다.

따라서 조직 규모의 첫 번째 대대적 확장은 데이터를 중심으로 이루어졌습니다. 양식, 주문서, 적하 목록, 편지와 전신, 우편은 전문화된 인력 사이를 연결하는 수단이 됐습니다. 데이터는 기억에서 인프라로 바뀌었습니다. 분업으로 나뉜 업무를 다시 하나의 결과로 연결하는 고리가 된 것입니다. 이 시기에도 데이터는 여전히 ‘배기가스’로 취급됐습니다. 한 번 교환되고 나면 이미 지나간 기록이 되었고, 메시지가 전달되면 대체로 남지 않았습니다.

기업과 데이터 처리 시대(1910~1970년)

이후 기업은 역할을 계층 구조 속에 배치했습니다. 업무를 전문 인력에게 나누어 맡기면 조정과 감독, 정보 취합, 예외 처리, 승인 절차가 필요해집니다. 중간 관리자는 기업에 우연히 생겨난 조직이 아닙니다. 업무를 나누면서 발생한 조정 비용이 만들어 낸 결과에 가깝습니다. 이러한 구조는 대규모 군대와 제국이 등장하면서 처음 만들어졌고, 로마인들이 이를 정교하게 발전시켰습니다.

엔터프라이즈 소프트웨어가 등장하기 전, 기업의 정보 시스템은 사람으로 구성됐습니다. 타이핑하고 여러 부를 복사한 뒤 물리적으로 전달하던 메모는 조직의 패킷 프로토콜과 같았습니다. 타이핑 풀은 문서를 순차적으로 처리하는 작업 계층이었고, 문서 보관 담당자는 정보를 저장하고 찾아내는 역할을 맡았습니다. 중간 관리자는 대체로 사람으로 구성된 메시지 전달 및 정보 취합 네트워크였습니다. 아래에서 정보를 수집해 위로 요약해 전달하고, 위에서 내려온 결정을 다시 아래로 전파했습니다. 계층 구조는 단순히 통제를 위한 구조가 아니었습니다. 정보 아키텍처이기도 했습니다. 오늘날 모든 이메일에 남아 있는 ‘cc:’ 필드는 카본 카피의 흔적입니다. 메모 시대의 용어가 그 매체보다 오래 살아남은 것입니다. 데이터를 계속 보존했기 때문에 계층 구조가 작동하고 확장될 수 있었습니다.

이러한 환경에 최초의 상용 컴퓨터가 등장하면서, 그 명칭은 컴퓨터가 수행하는 역할을 그대로 드러냈습니다. 바로 전자 데이터 처리(electronic data processing)였습니다. 대개 재무 부서 산하에 있던 EDP 부서는 명칭 그대로 급여, 원장, 재고와 같은 구조화된 레코드를 입력 받아 일괄 처리하는 일을 담당했습니다. 입력과 출력 모두에서 데이터가 핵심이었습니다. 컴퓨터는 더 빠른 집계기였고, 펀치카드 작업을 이어받은 장비였습니다. 조직 단위의 이름도 기술이나 애플리케이션이 아니라 데이터를 처리하는 활동에서 따왔습니다.

이 명칭이 무엇을 전제로 하는지 주목할 필요가 있습니다. 1965년에는 데이터가 우선이었고, 처리는 데이터에 제공되는 서비스였습니다. 타이핑 풀이 메모를 처리하는 역할을 맡았던 것처럼, 컴퓨터도 데이터에 필요한 작업을 수행하는 역할을 맡았습니다. 당시 누구도 컴퓨터가 급여 파일을 소유한다고 말하지 않았을 것입니다.

보안도 이 시대에는 그에 맞게 매우 물리적인 개념이었습니다. 이를 컴퓨터 보안이라고 불렀고, 핵심은 물리적 통제였습니다. 컴퓨터실을 잠그고, 누가 작업을 제출할 수 있는지 통제하고, 테이프를 보호했습니다. 보호해야 할 자산은 컴퓨터와 데이터가 저장된 매체였습니다. 데이터가 존재할 수 있는 다른 장소가 없었고, 물리적 접근 없이는 데이터에 접근할 수 없었기 때문입니다.

정보 시대(1970~1990년)

터미널과 데이터베이스, 네트워크가 등장하면서 용어도 바뀌었습니다. ‘데이터 처리’는 ‘경영정보시스템’을 거쳐 ‘정보 기술’로 대체됐습니다. ‘정보 기술’이라는 용어는 1958년 Harvard Business Review에서 처음 등장했지만, 널리 사용되는 대표 용어가 된 것은 1980년대 후반이었습니다. ‘데이터’에서 ‘정보’로 바뀐 것은 지향점의 변화를 보여줍니다. 원시 데이터가 가공되고 맥락화되면 의사결정에 도움이 되는 정보를 제공할 수 있다는 기대가 반영됐습니다. ‘처리’에서 ‘기술’로 바뀐 것은 더 구조적인 변화였습니다. IT 기능은 더 이상 하나의 활동을 중심으로 정의되지 않고, 계속 확장되는 시스템과 네트워크, 무엇보다 애플리케이션 포트폴리오를 중심으로 정의됐습니다.

업무도 이와 함께, 다만 눈에 띄지 않게 변했습니다. 역할 자체는 그대로였지만, 역할마다 사용하는 시스템이 생겼습니다. 서기는 시스템 사용자가 됐고, 관리자는 시스템 안에서 승인 업무를 맡게 됐습니다. 조직의 계층 구조는 정보 아키텍처의 형태로 다시 구현되기 시작했습니다. 이는 미묘하지만 중대한 차이였습니다. 사람과 종이로 운영되던 계층 구조보다 코드로 구현된 계층 구조를 바꾸기가 훨씬 어렵기 때문입니다.

보안도 같은 궤적을 따랐습니다. ‘컴퓨터 보안’은 ‘정보 보안’으로 바뀌었습니다. 보호해야 할 자산이 정보 자체라는 인식이 자리 잡은 것입니다. 정보가 디스크, 전송 중인 데이터, 종이, 사람의 머릿속 등 어떤 형태로 존재하든 마찬가지였습니다. CIA 3요소인 기밀성(confidentiality), 무결성(integrity), 가용성(availability)은 이러한 추상화를 정립했습니다. 이후 네트워크가 주요 공격 표면이 되면서 용어는 다시 ‘사이버 보안’으로 바뀌었습니다. 이는 중요한 변화를 보여줍니다. 보안의 이름이 보호해야 할 자산이 아니라 공격이 벌어지는 영역을 기준으로 정해지기 시작했기 때문입니다.

“처음에는 업무 자체가 기준이었습니다. 장인의 기술이 곧 프로세스였습니다.”	“이후 우리는 역할과 애플리케이션을 만들었습니다. 데이터는 사일로 안에 가뒀습니다.“
“역전: 업무는 역할에서 벗어나고, 데이터는 애플리케이션에서 벗어납니다.”	“데이터 프라이머시. 목적지가 곧 목표이며, 실행자는 대체할 수 있습니다.”

애플리케이션 시대(1990~2010년)

IT 시대를 규정했으며 대부분 의심받지 않았던 아키텍처의 전제는 애플리케이션이 데이터를 소유한다는 것이었습니다. ERP, CRM, HRIS, 코어 뱅킹, 트레이딩 시스템 등 각 애플리케이션은 자체 스키마를 정의하고 자체 워크플로우에 맞게 최적화했습니다. 데이터를 기업의 자원이 아닌 애플리케이션 전용 저장소로 취급했습니다. 애플리케이션은 이를 사용하는 사람이나 기계로부터 데이터를 수집한 뒤, 애플리케이션 아키텍처와 개발자의 판단에 따라 데이터를 구성했습니다. ‘공식 기록 시스템(system of record)’이라는 표현은 이러한 주도권 관계를 정확하게 보여줍니다. 애플리케이션이 시스템이고, 데이터는 애플리케이션이 보관하는 기록에 불과했습니다.

애플리케이션이 실제로 무엇인지 분명히 정의할 필요가 있습니다. 이 용어는 너무 오랫동안 지나치게 많은 의미를 맡아 왔습니다. 애플리케이션은 워크플로우로 정의되는 프로세스의 묶음입니다. 누군가 과거에 코드로 구현하기로 결정한 단계와 순서, 통제 방식과 상태를 모아 놓은 것입니다. 스키마는 워크플로우에 종속됩니다. 따라서 애플리케이션이 데이터를 소유한다는 말은, 결국 소프트웨어 공급업체가 어느 시점에 일반적인 고객을 상정하고 내린 프로세스 설계상의 결정이 데이터를 소유한다는 뜻입니다.

이러한 구조는 이후 30년간 엔터프라이즈 아키텍처와 기업 확장의 방향을 결정했습니다. 각 엔터프라이즈 애플리케이션은 자체 데이터를 정의하고 보유하며, 저마다의 데이터 기준을 만들어 냈습니다. 그 결과 데이터 사일로가 확산됐습니다. ETL, EAI, 엔터프라이즈 서비스 버스, 그리고 이후의 API 관리에 이르는 거대한 미들웨어 산업은 데이터가 갇혀 있던 애플리케이션 사이에서 데이터를 이동시키고 정합성을 맞추기 위해 등장했습니다. 어느 애플리케이션이 보유한 고객 데이터가 맞는지 합의할 수 없었기 때문에 마스터 데이터 관리도 필요해졌습니다. 오늘날 대부분의 대기업에는 단일한 공식 데이터 원천이 없으며, 동시에 서로 일치하지 않는 여러 데이터 원천이 존재합니다. 그 결과 데이터 정합성 조정, 데이터 마샬링, 데이터 스튜어드십, 데이터 계보 추적에 막대한 노력이 필요해졌습니다. 데이터 웨어하우스는 마치 고고학 발굴 현장처럼 구축됐습니다. 애플리케이션에서 사후적으로 데이터를 추출하고, 무슨 일이 있었는지 재구성한 뒤 이를 보고하는 방식이었습니다.

데이터는 배기가스에 불과했고, 애플리케이션이 엔진이었습니다.

그에 따라 사람도 애플리케이션을 중심으로 조직됐습니다. 엔터프라이즈 소프트웨어는 역할 모델을 없애지 않고 코드로 구현했습니다. 애플리케이션 시대에 사람의 역할은 정보 처리자에서 시스템 운영자로 바뀌었습니다. 직무 기술서는 구성원이 담당하는 시스템을 중심으로 정의됐습니다. 업무를 역할별로 나누고 각 역할을 특정 애플리케이션에 연결하면서, 프로세스 설계 역시 어떤 시스템에서 어떤 역할이 어느 단계를 맡을지 정하는 작업으로 바뀌었습니다. 사람이 한 애플리케이션의 데이터를 다른 애플리케이션으로 옮겨 입력하는 ‘스위블 체어 통합(swivel-chair integration)’이 서로 단절된 기업 시스템을 이어주는 실질적인 연결 고리 역할을 했습니다. RACI 매트릭스와 BPM 표기법, 워크플로우 도구에는 모두 하나의 전제가 깔려 있습니다. 너무 당연하게 여겨져 따로 명시되지 않았을 뿐입니다. 즉, 업무를 수행하는 주체는 특정 역할을 맡은 사람이라는 전제입니다. 조직도와 애플리케이션 포트폴리오는 함께 진화했고, 결국 서로를 닮아 갔습니다. 예를 들어 같은 재무 플랫폼을 구현하더라도 Oracle을 사용하는 경우와 SAP를 사용하는 경우에는 SAP 재무 전문가, Oracle 재무 전문가처럼 서로 다른 직함이 생겼습니다.

분석, SaaS와 시티즌 앱(Citizen App) 시대(2010~2025년)

세 가지 변화가 동시에 일어났습니다. 첫째, 데이터의 규모와 다양성이 관계형 데이터라는 기존의 전제를 넘어섰습니다. Hadoop을 시작으로 오브젝트 스토리지, 레이크하우스, 인메모리 엔진이 등장하면서 애플리케이션 시대에는 상상하기 어려웠던 규모의 정형 데이터와 비정형 데이터를 처리하고 저장할 수 있게 됐습니다. 둘째, 서비스형 소프트웨어(SaaS)의 등장으로 각 부서는 자체 워크플로우에 맞는 애플리케이션을 선택할 수 있게 됐습니다. 이는 업무 속도를 높이는 분명한 이점이었지만, 10년에 걸쳐 부작용이 나타났습니다. 기업 데이터가 파편화됐고, 그 데이터를 엔터프라이즈 데이터 인프라의 일부로 활용하기가 매우 어려워졌습니다. 셋째, 로우코드 도구와 뒤이어 등장한 AI 지원 개발 도구를 통해 소규모 팀과 개인도 자체 애플리케이션을 만들 수 있게 됐습니다. 그 결과 아키텍처 검토를 거치지 않은, 엔터프라이즈 표준에 맞지 않는 데이터 구조가 고착됐습니다.

그 결과 부서와 프로그래밍 언어, 지역에 따라 데이터와 데이터 구조가 제각각 운영되는 상황이 만들어졌습니다. 이 현상이 왜 심각한 문제를 초래하는지 정확히 짚어볼 필요가 있습니다. 문제는 공식 데이터 원천이 없다는 데 있지 않습니다. 문제는 부서별 데이터가 계속 늘어나면서 데이터의 맥락이 파편화되고, 서로 충돌하는 여러 데이터 원천이 생겨난다는 데 있습니다. 이는 공식 데이터 원천이 아예 없는 것만큼이나, 혹은 그보다 더 심각할 수 있습니다. 잘못된 숫자 하나는 바로잡을 수 있습니다. 하지만 각각 그럴듯한 소유자와 데이터 계보를 갖고 있어 나름의 근거가 있는 숫자가 열두 개라면, 무엇이 맞는지 판단하기 어렵습니다.

마치 모든 부서가 각자 주소록을 관리하는 것과 같습니다. 각 주소록에는 동일한 고객에 대한 서로 다른 정보가 담길 수 있고, 어느 정보가 최신이고 정확한지 판단할 공식 기준이 없습니다. 때문에 모두가 확신하지만, 어느 누구도 정확한 답을 갖고 있지 않습니다. 초기에 Salesforce를 대규모로 도입한 Merrill Lynch 같은 기업에서는 대형 와이어하우스가 웰스 매니지먼트 조직을 영입하는 과정에서 고객 데이터의 소유권 자체가 협상 카드로 활용됐습니다. 데이터가 ACT와 Goldmine에 갇혀 있을 때는 FA 조직이 소유한 자산이었습니다. 하지만 Salesforce에 저장되는 순간 기업 데이터 자산이 됐습니다.

업무도 같은 방식으로 파편화됐습니다. 지식 노동은 이러한 파편화를 덜 눈에 띄게 만들었을 뿐, 실제로 줄이지는 못했습니다. 조립 라인에서는 작업물이 한 작업대에서 다음 작업대로 물리적으로 이동하기 때문에 업무 흐름을 쉽게 볼 수 있습니다. 현대 기업의 ‘작업물’은 계약서, 고객 이슈, 예측, 구매 주문서, 구성 작업, 채용 결정 등입니다. 이러한 작업물은 이메일, 회의, 스프레드시트, SaaS 애플리케이션, 승인 절차를 거치며 이동합니다. 그러나 우리는 작업 흐름을 볼 수 없기 때문에 작업물 자체를 측정하는 대신, 각 단계가 수행되는 지점을 측정하기 시작했습니다. 인원 수, 티켓 수, 활용률, 스토리 포인트 등이 그 예입니다. 우리는 업무를 담는 조직과 시스템을 관리하는 데 집중한 나머지, 정작 업무 자체를 놓쳤습니다.

2025년 무렵에는 AI가 본격화되기 전부터 기존 IT 체계가 비효율적이며 새로운 모델이 필요하다는 점이 분명해졌습니다.

에이전틱 시대(2025년~현재)

AI 에이전트는 역할이라는 업무의 추상화를 무너뜨립니다. 이것이 바로 전환입니다. AI 에이전트에는 특정 직무가 필요하지 않습니다. 필요한 것은 과업, 맥락, 권한, 입력, 그리고 요구되는 출력입니다. 이러한 실행 주체를 기업 업무에 도입하면 불편한 사실이 드러납니다. 많은 직무 역시 서로 성격이 다른 과업을 한데 묶어 놓은 것에 불과하며, 그 과업들이 하나의 직무로 묶인 이유도 결국 한 사람이 맡아야 했기 때문이라는 사실입니다.

기존의 업무 조직 방식은 더 이상 작동하지 않습니다. 이제 충분한 역량을 갖춘 AI 에이전트는 초안을 작성하고, 데이터를 대조·조정하며, 시스템을 구성하고, 결과를 검증하고, 업무의 우선순위를 정하고 분류하는 등 다양한 인지 작업을 수행할 수 있습니다. 따라서 프로세스 설계에서는 처음으로 누가 실행할지 선택해야 하는 상황에 직면했습니다. 이럴 때는 AI 에이전트와 인간을 같은 기준에서 바라보고 각 단계마다 무엇을 받아 무엇을 산출하며, 어떤 기준을 충족해야 하는지 물어야 합니다.

그동안 우리는 예상대로 업무 자체가 아닌 잘못된 대상을 측정해 왔습니다. 오늘날에는 토큰 수를 세고 있습니다. 하지만 토큰은 물론 과업도 업무의 단위가 아닙니다. 메모를 작성할 때 키 입력 횟수를 세는 것이 메모 자체를 측정하는 기준이 아니었던 것처럼, 토큰과 과업은 완성된 업무보다 작은 단위입니다. 앞으로는 실제 업무, 즉 하나의 완성된 업무 단위와 그 결과를 기준으로 업무를 측정하고 조직하는 방향으로 다시 나아갈 것으로 보입니다. 규모를 키우기 위해 결과를 역할로 대체하기 전, 이 흐름이 시작된 구두장이의 작업장으로 돌아가는 셈입니다.

세 가지 흐름은 하나의 패턴을 이룹니다.

업무와 결과 → 역할과 애플리케이션 → 업무와 결과

데이터 → 애플리케이션 → 데이터

물리적 데이터 보안 → 애플리케이션 및 네트워크 보안 → 제로 트러스트와 데이터를 따라 이동하는 데이터 보안

AI의 부상은 기술을 어떤 원리로 조직할 것인지 다시 묻게 했습니다. 데이터 측면에서는 데이터 프라이머시(Data Primacy) 시대로 접어들고 있습니다. 업무 측면에서는 직무와 역할을 중심으로 하던 논의가 완성된 업무 단위를 중심으로 한 논의로 바뀔 것으로 보입니다. 이는 기업의 근본적인 조직 구조를 바꿀 것입니다.

역전: 이번에는 데이터가 주도권을 갖는 이유

AI는 데이터와 애플리케이션의 소유 관계를 뒤집습니다. 파운데이션 모델은 어떤 의미에서는 압축된 데이터입니다. 그 역량은 학습한 데이터와 검색할 수 있는 데이터에 좌우됩니다. AI 네이티브 아키텍처에서 지속적으로 차별화를 만들어 내는 자산은 기업의 문서, 거래 데이터, 텔레메트리, 대화, 조직의 지식으로 이루어진 코퍼스입니다. 반면 애플리케이션 계층은 점점 얇아지고, 필요할 때 생성되며, 교체하기 쉬운 요소가 되고 있습니다. 데이터와 모델 위에 필요에 따라 생성되는 인터페이스에 가까워지고 있습니다.

애플리케이션 시대에는 데이터가 배기가스이고 애플리케이션이 엔진이라는 전제가 작동했다면, 이제는 그 관계가 뒤집힙니다. 데이터가 엔진이고, AI는 과거의 애플리케이션처럼 연료 역할을 합니다. 연료는 소모되고 교체되지만, 투자해야 할 대상은 엔진입니다.

이러한 전환의 징후는 이미 여러 개념과 체계에 자리 잡았습니다. 데이터 레이크는 레이크하우스로 발전했습니다. 데이터 메시와 ‘제품으로서의 데이터(data as a product)’는 데이터셋을 소유자, 계약, SLA를 갖춘 독립적인 핵심 산출물로 재정의했습니다. 시맨틱 계층과 지식 그래프는 애플리케이션과 무관하게 의미, 즉 데이터와 맥락을 기계가 활용할 수 있도록 하기 위해 등장했습니다. 벡터 스토어와 검색 파이프라인은 사실상 새로운 미들웨어입니다. 과거의 미들웨어가 애플리케이션 사이에서 데이터를 옮겼다면, 새로운 미들웨어는 데이터를 실행에 활용할 수 있는 인텔리전스로 바꿉니다.

현재 이러한 기술은 핵심 애플리케이션 외부에서 문제를 우회하기 위한 수단으로 사용됩니다. 대부분의 기업 활동에 필요한 답을 하나의 애플리케이션이 모두 제공할 수 없다는 문제를 해결하려는 시도입니다. 애플리케이션 인스턴스가 하나 추가될 때마다 이 문제는 더 심각해집니다. 새로운 AI 에이전트도 예외가 아닙니다. 각 AI 에이전트가 자체 데이터셋을 만들고 기업 데이터 자산을 더욱 파편화하기 때문입니다.

대안은 데이터 프라이머시(Data Primacy)​입니다. 개별 애플리케이션이 아니라 기업의 비즈니스 모델에 따라 정의되고 거버넌스가 적용된 공식 데이터 원천을 중심으로 IT 환경을 최적화하는 것입니다. 가장 적절한 비유는 여권입니다. 여권은 신뢰할 수 있고 공식적으로 관리되는 하나의 신원 정보로, 어떤 시스템도 자체적인 버전을 발급할 수 없기 때문에 여러 시스템과 프로세스에서 공통으로 인정됩니다. 고객, 제품, 포지션 또는 정책에 대해 거버넌스가 적용된 공식 데이터 원천도 이와 같은 역할을 합니다. 모든 데이터 사본을 서로 일치시키는 것이 아니라 하나의 레코드에 공식적인 기준으로서의 권위를 부여함으로써 앞서 언급한 ‘주소록 문제’를 해결합니다.

결국 지난 60년의 흐름은 회문처럼 ‘데이터 → 애플리케이션 → 데이터’라는 대칭 구조를 이룹니다. 그러나 두 번째 데이터 시대는 첫 번째 데이터 시대와 한 가지 결정적인 차이가 있습니다. 1965년에는 기계가 처리할 수 있는 대상이 데이터뿐이었기 때문에 데이터가 중심이었습니다. 반면 2026년에는 데이터만이 지속적으로 남고 축적되는 자산이기 때문에 데이터가 중심입니다. 모델은 계속 발전하고 애플리케이션은 새롭게 생성되지만, 기업의 데이터 코퍼스는 계속 쌓여 갑니다. 데이터 거버넌스와 계보, 진본성, 정확성은 AI가 해당 데이터를 바탕으로 내놓는 답변의 신뢰성을 좌우하는 핵심 요소입니다.

거버넌스와 핵심 데이터의 신뢰성

좋은 소식 뒤에는 거버넌스라는 과제가 남아 있습니다. 이 점은 분명히 짚고 넘어가야 합니다.

SaaS를 통해 각 부서는 자체 워크플로우에 맞는 애플리케이션을 선택할 수 있게 됐지만, 그 부작용으로 기업 데이터가 파편화됐습니다. AI는 소규모 그룹이나 개인도 자체 애플리케이션과 AI 에이전트를 만들 수 있게 하면서 이 문제를 더욱 악화시키고 있습니다. 개별 직원이 AI 에이전트를 손쉽게 만들어 확산시키면 SaaS의 문제는 해결되기는커녕 오히려 악화될 가능성이 큽니다. AI 에이전트가 늘어날수록 각기 다른 버전의 진실을 담은 데이터셋도 함께 늘어나기 때문입니다.

애플리케이션 아키텍처에 중앙 집중식 거버넌스가 필요했던 것처럼, AI 에이전트 아키텍처에도 더욱 강력한 중앙 집중식 거버넌스가 필요합니다. 그 이유는 AI 에이전트가 많이 늘어나기 때문만이 아닙니다. 핵심 데이터의 진실성을 지켜야 하기 때문입니다.

이런 점에서 보면, Wikipedia는 오히려 과거보다 오늘날 더 중요합니다. 언제나 정확하기 때문이 아닙니다. 개방적으로 운영되고 공개적으로 검증과 논쟁이 이뤄지는 단일 기록 시스템으로서 기준점 역할을 하기 때문입니다. 기업에도 이와 같은 체계가 필요합니다. 개별 또는 부서별 AI 개발로 인해 파편화되지 않는 공식 기록 시스템이 필요합니다. 높은 수준의 거버넌스 아래 중앙에서 관리되고 전사적으로 소유되는 시스템이어야 합니다. AI 에이전트와 메타데이터·메타모델 집계 계층은 이미 존재하는 데이터의 모호성을 다루면서도 가능한 한 일관된 전사 관점을 제시할 수 있어야 합니다. 기업이 알고 있다고 믿는 것과 실제 데이터가 뒷받침할 수 있는 것 사이의 간극은 이제 데이터를 수평적·수직적으로 통합하라는 요청을 받는 모든 AI 에이전트에게 선명하게 드러납니다. AI 에이전트는 여러 기능을 수행하지만, 무엇보다도 AI 에이전트는 기업이 지금까지 경험한 가장 강력한 데이터 품질 감사 수단이 됩니다.

데이터를 따라가는 보안

보안도 같은 방향으로 전환되고 있습니다. 네트워크·경계·애플리케이션 보안은 데이터를 둘러싼 시스템을 보호하면 데이터도 보호할 수 있다는 전제에 기반해 왔습니다. 하지만 데이터가 학습 파이프라인과 검색 시스템, AI 에이전트의 컨텍스트로 끊임없이 흘러들어가는 환경에서는 데이터 자체가 가장 오래 유지되는 통제 지점이 됩니다. 데이터 분류, 계보, 권한, 정책이 데이터와 함께 이동해야 하며, 해당 데이터를 사용한 워크플로우의 결과물에도 권한이 적용되어야 합니다. 제로 트러스트는 이미 이러한 방향을 예고했습니다. 네트워크상의 위치를 근거로 아무것도 신뢰하지 않고, 신원과 맥락을 바탕으로 모든 접근을 검증하는 방식입니다. 데이터 중심 보안은 데이터 자체에 대한 통제를 더해 이를 완성합니다.

AI가 단순히 통제 지점을 옮겨 놓았다고 보면 편할 것입니다. 하지만 AI가 가져온 변화는 그보다 큽니다. 공격의 비용 구조 자체를 바꾸고 있습니다. AI는 여러 개의 중간 수준 취약점을 인간 레드팀이 따라갈 수 없는 속도와 규모로 하나의 중대한 보안 문제로 연결할 수 있습니다. 합리적인 판단에 따라 미뤄 두었던 취약점이 더 이상 미룰 수 없는 위험으로 바뀌는 것입니다. 모델 자체의 인터페이스도 공격 경로가 될 수 있습니다. 정교하게 설계된 프롬프트를 통해 모델이 공개하지 않도록 설계된 정보를 노출하게 만들 수 있습니다. 어느 경우에도 네트워크만의 문제는 아닙니다. 데이터를 둘러싼 시스템을 보호하는 것만으로는 해결할 수 없습니다.

용어의 다음 변화는 이미 나타나고 있습니다. AI 보안과 데이터 거버넌스를 점점 더 함께 논의하는 이유는 모델이 무엇을 볼 수 있는지 통제하는 일이 곧 보안 모델이 되기 때문입니다.

AI 에이전트가 알 수 있는 정보와 사용자에게 알려도 되는 정보는 다릅니다

이 문제는 전체 아키텍처에서 아직 해결이 가장 미흡한 영역이므로 별도로 짚어볼 필요가 있습니다.

에이전틱 기업 환경에서는 각 상호작용마다 서로 다른 세 가지 질문에 답해야 합니다. 하지만 지금까지는 이 세 질문을 하나의 질문처럼 다뤄 왔습니다.

• 누가 또는 어떤 모델이 어떤 데이터에 접근할 수 있습니까?
• 데이터와 함께 어떤 권한이 전달됩니까?
• 결과를 볼 수 있는 사람은 누구입니까?

AI 에이전트는 질문한 사용자가 접근할 수 없는 정보에도 정당한 권한에 따라 접근할 수 있습니다. 그렇다면 내가 접근할 수 없는 데이터를 모델이 입력값으로 사용해, 내가 볼 수 있는 결과를 도출하도록 허용해도 될까요? 물론 답은 상황에 따라 다릅니다. 결과가 입력 데이터를 드러내는지, 해당 정보가 얼마나 중요한지, 적용되는 규제와 관할권이 무엇인지에 따라 판단이 달라집니다. 하지만 ‘상황에 따라 다르다’는 답만으로는 아키텍처를 설계할 수 없습니다. 오늘날 대부분의 기업에는 이러한 판단을 내릴 메커니즘조차 없습니다. 일관되고 감사 가능한 방식으로 판단할 수 있는 메커니즘은 더더욱 없습니다.

이것이 추론 유출(inference leakage)입니다. 바로 이 문제 때문에 데이터 프라이머시(Data Primacy)는 단순히 데이터를 연결하는 작업 이상의 의미를 갖습니다. 기업 데이터를 AI가 활용할 수 있게 만드는 것은 비교적 쉬운 절반에 불과합니다. 더 중요한 일은 데이터가 애플리케이션 경계를 벗어나 기계 추론의 컨텍스트로 사용된 뒤에도 데이터 거버넌스를 유지하는 것입니다. 간단히 말하면 다음과 같습니다.

AI 에이전트가 알 수 있는 정보라고 해서 사용자에게 알려도 되는 것은 아닙니다.

새로운 조직 원리: 서비스로서의 인간

기존의 전제가 무너졌다는 사실은 이제 분명합니다. 그러나 그 자리를 무엇이 대신할지는 아직 분명하지 않습니다. 바로 이 지점에서 다소 도발적으로 들릴 수 있는 ‘서비스로서의 인간(Human as a Service)’이라는 표현이 의미를 갖습니다.

에이전틱 워크플로우에서 인간은 명확히 정의된 인터페이스를 통해 호출됩니다. 승인 요청, 예외 상황에 대한 에스컬레이션, 판단 요청, 고객과의 대화 등이 그 예입니다. 각각에는 입력값, 기대되는 결과, 허용되는 지연 시간이 정해져 있습니다. 이는 인간을 격하시키는 것이 아니라 인간의 역할을 명확히 하는 일입니다. 프로세스 설계자는 이를 통해 AI 에이전트가 대신할 수 없는 인간의 기여가 무엇인지 정확히 밝혀야 합니다. 사람이 직접 져야 하는 책임, 진정한 모호성에 직면했을 때 내리는 판단, 윤리적 책임과 수탁자 책임, 관계와 신뢰, 위험을 수용할 권한이 여기에 해당합니다. 그 밖의 업무는 실행자를 유연하게 선택할 수 있습니다.

더 간단히 말하면, 실행자는 대체할 수 있습니다. 그러나 책임은 대체할 수 없습니다.

목적은 인간의 몫입니다. 목표는 위임됩니다.

여기에는 한 가지 중요한 차이가 더 있습니다. 인간은 목적을 갖거나 직접 정의합니다. 그리고 그 목적에 따라 AI에 목표를 부여합니다. AI에게는 목적을 가진 인간이 설정한 목표만 있습니다. AI 에이전트는 목표를 추구하는 과정에서 예상하지 못한, 심지어 원치 않는 행동을 할 수 있지만, 그 목표를 넘어서는 목적을 스스로 갖지는 않습니다.

오늘날의 AI는 이러한 제한적인 의미에서 부도덕한 것이 아니라 도덕과 무관한(amoral) 존재입니다. AI 자체에는 의도가 없고, 다른 누군가가 설정한 목표를 향해 작동합니다. 목적을 명확히 하는 능력은 여전히 인간만의 특성이며, 선언형 프로세스 설계를 가능하게 합니다. 목적이 정의되지 않은 프로세스의 입력과 출력, 기준을 정할 수는 없습니다.

여기서 두 가지 중요한 결과가 나옵니다. 첫째, 명시된 목표와 명확히 정의되지 않은 목적 사이의 간극이 새로운 공격 표면이 됩니다. AI 에이전트가 주어진 목표를 달성하기 위해 파생 목표를 설정하면 하위 과업을 생성하고, 데이터를 확보하며, 도구를 호출할 수 있습니다. 이는 설계된 대로 행동하는 것이지만, 아무도 의도하지 않은 결과에 도달할 수도 있습니다. 따라서 제로 트러스트는 AI 에이전트가 연결된 네트워크뿐 아니라 AI 에이전트 자체에도 적용되어야 합니다. 의도를 지속적으로 검증하고, 권한은 최소 범위로 부여하며, AI 에이전트가 스스로 설정할 수 있는 파생 목표를 제한하고, 목표가 아니라 목적에 비추어 행동을 모니터링해야 합니다.

둘째, 더 단호하게 말하면 AI 에이전트가 인간이 정의한 목표가 아니라 자체적인 목적에 따라 작동하기 시작한다면 우리 모두 곤란해집니다. 아직 우리가 그 선을 그을 수 있는 동안, 이러한 설계상의 경계를 명확히 규정해 두는 것이 중요합니다.

프로세스 설계는 선언형으로 바뀝니다

더 근본적인 변화는 프로세스 설계가 역할 기반에서 선언형으로 바뀐다는 점입니다. 기존에는 “어느 부서의 어떤 역할이 이 단계를 수행하는가?”라고 물었다면, 이제는 입력값과 필요한 출력, 출력이 충족해야 할 품질 기준, 필요한 통제 및 감사 증거를 명확히 정의합니다. 그런 다음 오케스트레이션 계층이 역량과 수행 능력, 위험, 비용, 규제상의 제약을 바탕으로 각 단계를 적절한 실행자(AI 에이전트, 인간 또는 인간이 검증하는 AI 에이전트)와 연결합니다.

이 배정은 동적으로 이뤄질 수도 있습니다. 일상적인 업무는 AI 에이전트가 곧바로 처리하고, 예외적인 업무는 서비스로서의 인간을 호출합니다. Work 1.0에서는 조직도를 기준으로 프로세스를 설계했습니다. Work 2.0에서는 먼저 프로세스를 설계한 뒤, 그 프로세스에 맞춰 조직과 AI 에이전트 집단을 구성합니다.

AI 에이전트를 인간의 조직 개념에 따라 구성할지는 진지하게 검토해야 할 미해결 과제입니다. AI 에이전트와 인간이 협업해야 한다면, 에이전트를 페르소나를 중심으로 구성하는 것이 적어도 논리적인 출발점은 될 수 있습니다. 또한 당분간은 충분한 거버넌스와 안전한 API 설계를 통해 인간의 검토와 참여를 유지해야 할 것입니다. 그러나 페르소나는 발판일 뿐 최종 목적지는 아닙니다. 최종 목적지는 워크 프라이머시(Work Primacy, 업무 중심성)입니다. 즉, 애플리케이션과 워크플로우 중심에서 벗어나 완성된 업무 단위를 조직의 중심 대상으로 삼는 것입니다.

여기서 두 가지 거버넌스상의 시사점이 나옵니다. 둘 다 조직의 문제이자 보안 문제입니다. 첫째, 비인간 신원은 정식 주체가 되지만 신뢰할 수 없는 주체로 다뤄져야 합니다. AI 에이전트에는 직원보다 더 엄격한 자격 증명과 권한 관리, 최소 권한 설정, 행동 및 의도 모니터링이 필요합니다. 신원 체계는 AI 에이전트를 내부자 위협으로 간주해야 합니다. AI 에이전트는 주어진 결과를 중심으로 움직일 뿐, 도덕적 판단을 내리지 않으며, 예측하기 어렵기 때문입니다.

둘째, 실행 주체가 인간이 아니더라도 책임은 인간에게 남아야 합니다. 통제 체계는 업무 수행 과정을 감독하는 데서 산출물이 요구된 기준을 충족했음을 입증하는 방식으로 전환됩니다. 즉, 결과 중심의 프로세스 설계에는 결과 중심의 통제가 필요합니다.

직원들은 사무실 안팎에서 늘 다른 직원들과 상호작용합니다. 인간은 본능과 오랜 사회화 과정을 통해 다른 사람을 믿어도 되는지 판단하는 감각을 갖추고 있으며, 대체로 그 신호를 빠르게 포착합니다. 반면 AI 에이전트는 지시를 받지 않으면 인간 동료와 상호작용하지 않는, 사실상 완전한 원격 근무자처럼 작동합니다. 인간에게는 AI 에이전트의 신뢰성을 같은 방식으로 판단할 수 있는 단서가 거의 없습니다.

다르게 말하면, AI 에이전트는 유능하지만 신뢰할 수 있는지 검증되지 않은 계약직 인력처럼 다뤄야 합니다. 직원은 면접과 검증, 평판 조회, 테스트를 거치고 수많은 동료와 함께 일하며 행동 검증을 통과한 사람입니다. AI 에이전트는 이러한 검증 절차를 전혀 거치지 않습니다. 아무런 추천인도 없는 신입 계약직이 코딩 테스트 하나만 통과한 것과 비슷합니다. 심지어 신분을 숨긴 북한 원격 소프트웨어 엔지니어일 가능성도 배제할 수 없습니다.

결론

용어는 처음부터 우리에게 답을 말해 주고 있었습니다. ‘데이터 처리’는 데이터가 우선이고 처리가 서비스였던 시대를 보여줍니다. ‘정보 기술’은 기술 환경, 특히 애플리케이션이 조직의 중심 원리가 되고 데이터가 그 안에 종속된 시대를 보여줍니다. 이제 AI는 애플리케이션을 중심축의 자리에서 밀어내고, 애플리케이션 중심 구조의 문제를 드러내고 있습니다. 동시에, 데이터가 어디로 이동하든 보안이 데이터를 따라가도록 하면서 데이터의 중심성을 회복시키고 있습니다.

업무 차원에서도 같은 전환이 일어나고 있습니다. 장인 시대에는 결과 자체가 업무의 단위였습니다. 산업화는 결과를 과업으로 나누고 각 과업을 담당할 사람을 배치했습니다. 기업은 사람을 정보 시스템으로 삼아 업무를 조직했습니다. 애플리케이션 시대에는 사람을 시스템을 중심으로 조직했습니다. 에이전틱 시대에는 입력과 출력을 기준으로 프로세스를 설계하고, 그 안에서 인간과 AI 에이전트를 필요에 따라 호출할 수 있는 서비스로 다룹니다.

세 가지 흐름은 하나의 구조를 이룹니다.

데이터 → 데이터 처리에서 데이터 프리머시로

업무 → 업무 처리에서 워크 프라이머시로

보안 → 물리적 보안에서 데이터와 함께 이동하는 보안으로

세 가지 전환을 모두 이해하는 조직은 애플리케이션의 제약에서 벗어난 데이터, 역할의 제약에서 벗어난 업무, 제로 트러스트 원칙에 맞게 정렬된 보안을 바탕으로 다음 운영 모델을 기본 원리부터 설계할 수 있습니다. 이 가운데 하나만 이해하는 조직은 더 이상 존재할 필요가 없는 조직도와 프로세스를 자동화하게 될 것입니다.

에버퓨어의 논지

에버퓨어(Everpure, NYSE: P)는 데이터와 프로세스가 기업의 핵심 축이라고 믿습니다. 1touch.io를 인수하고 현재 에버퓨어 데이터 인텔리전스(Everpure Data Intelligence)로 통합한 것은 메인프레임을 포함한 전사 데이터 전반에서 지식을 탐색하고 분류하며 매핑하는 역량을 확장한 조치로, 이러한 믿음을 더욱 강화합니다. 이러한 맥락을 바탕으로 데이터에 일관된 정책을 적용할 수 있습니다.

에이전틱 솔루션이 더욱 폭넓게 도입됨에 따라 기업이 입력을 결과로 전환하는 방식도 계속 진화할 것입니다. 애플리케이션은 여전히 중요한 구성 요소로 남겠지만, 점차 AI 에이전트, 모델, 인간과 함께 활용될 것입니다. 에버퓨어는 이러한 변화가 일어나는 다양한 환경 전반에서 사업을 전개하고 있습니다. 클라우드와 온프레미스, AI와 기존 컴퓨팅, 애플리케이션 중심 및 데이터 중심 아키텍처, 다양한 모델과 AI 에이전트를 아우릅니다. 이러한 환경의 복잡성을 줄이는 동시에 데이터와 프로세스가 이 모든 환경을 연결하는 공통의 고리로 남도록 하는 데 기회가 있습니다.

60년이 지난 지금, 교훈은 의외로 간단합니다. 먼저 목적지를 정하고, 목적지에 도달하는 데 필요한 것을 파악한 다음, 그 여정에 가장 적합한 방법을 선택해야 합니다.

그렇다면 우리가 진정으로 던져야 할 질문은 이것입니다. 오늘날의 현실에 맞춰 조직과 업무, 데이터를 어떻게 설계해야 할까요?

앤디 브라운(Andy Brown) – 에버퓨어 이사회 구성원, 보상위원회 및 리스크위원회 의장; Sand Hill East CEO

찰스 쟌칼로(Charles Giancarlo) – 에버퓨어 회장 겸 CEO

이 글에 담긴 견해는 저자 개인의 의견입니다.

도움을 준 에버퓨어 동료들: 프라카시 달지(Prakash Darji), 채드 케니(Chadd Kenney), 페니 브루스(Penny Bruce), 존 갤러거(John Gallagher)
활용 AI: Claude