🔎 한눈에 보기
재무 데이터를 다루는 AI 에이전트가 제대로 역할을 하려면 세 가지를 해내야 합니다. 필요한 데이터를 정확히 찾아내고, 그 의미를 회계 기준과 업무 맥락에 맞게 해석한 뒤, 재무팀이 그대로 활용할 수 있는 형태로 결과를 전달하는 일입니다.
데모에서는 이 과정이 막힘없이 흘러갑니다. 시연에 쓰이는 데이터가 이미 정리되고 구조화되어 있기 때문인데요. APAC 마켓플레이스에서 실제로 내려받는 정산 데이터는 사정이 다릅니다. 정제도, 전처리도 되어 있지 않습니다.
그래서 인상적인 데모와 실무에서 신뢰할 수 있는 에이전트를 가르는 요소는 대부분 모델의 성능이 아닙니다. 데이터를 어떻게 구조화했는지가 더 큰 변수입니다. 그 간극을 메우는 것이 원천 데이터 위에 얹히는 온톨로지 런타임입니다.
"우리 4분기 프로모션 비용이 얼마죠?" 재무팀이 던지는 이 질문은 간단해 보입니다. 하지만 원천 Settlement Report 위에서는 그렇지 않습니다.
Settlement Report는 프로모션 할인을 Promotion 행으로 기록합니다. 그런데 그 비용을 아마존이 댔는지 브랜드가 댔는지는 담고 있지 않습니다. 에이전트는 구분할 근거가 없는 데이터를 마치 구분할 수 있는 것처럼 답하게 됩니다.
에이전트가 틀리는 이유는 추론 능력이 부족해서가 아닙니다. 애초에 데이터가 확신할 근거를 주지 않았기 때문입니다.
AI 에이전트는 재무 데이터 위에서 정확히 무엇을 해야 할까요?
검색, 추론, 응답. 이 세 단계입니다.
우선 질문에 해당하는 데이터를 찾아야 합니다. 그다음에는 그 데이터를 회계 기준과 비즈니스 정의에 맞게 해석해야 하고요. 마지막으로 재무팀이 결산이나 보고 업무에 바로 쓸 수 있는 형태로 결과를 돌려줘야 합니다.
세 단계 모두 데이터에 기대고 있습니다. 그런데 대부분의 AI 제품 데모에서는 이 전제가 잘 드러나지 않습니다. 이미 정리된 데이터셋을 기반으로 시연하기 때문입니다.
에이전트의 성능을 좌우하는 것은 모델이 얼마나 똑똑한지가 아닙니다. 검색·추론·응답 각각이 어떤 데이터 위에서 이뤄지는지입니다.
"Q4 프로모션 비용이 얼마야?"라는 질문은 왜 어려울까요?
Settlement Report만으로는 누가 그 비용을 부담했는지 알 수 없기 때문입니다.
아마존 Settlement Report에는 프로모션 할인이 Promotion 행으로 기록됩니다. 하지만 그 비용을 아마존이 댔는지 브랜드가 댔는지는 파일 어디에도 표시되지 않습니다. 라이트닝 딜만 보더라도 전액 아마존 부담일 수도, 전액 브랜드 부담일 수도, 양측이 나눠 부담했을 수도 있습니다.
원천 정산 데이터만 조회하는 에이전트에게 남는 선택지는 셋뿐입니다. 브랜드 부담이라고 가정하거나(틀릴 수 있습니다), 해당 항목을 제외하거나(결과가 불완전해집니다), 애매한 건마다 사람에게 확인을 요청하는 것입니다.
주문이 수백 건이고 정산 주기가 여러 번 겹치는 상황이라면, 세 번째 선택지는 자동화가 아닙니다. 오히려 새로운 확인 업무를 만들어냅니다.
결국 에이전트가 신뢰를 잃는 지점은 추론의 품질이 아닙니다. 데이터 자체가 확신할 근거를 제공하지 못한다는 사실입니다.
데이터 소스를 연결하는 순간 문제는 왜 더 커질까요?
무엇을 기준으로 연결해야 하는지에 대한 정의가 없기 때문입니다.
같은 4분기 프로모션 비용 질문에 제대로 답하려면 에이전트는 내부 캠페인 기록과 Settlement Report를 함께 봐야 합니다. 그런데 프로모션 비용을 어디까지 볼 것인지, 재원은 어떻게 구분할 것인지, 어떤 데이터가 정본인지가 정의돼 있지 않다면 에이전트는 쿼리 시점마다 스키마를 추론하게 됩니다. 컬럼 이름을 해석하고, 필드의 의미를 짐작한 뒤, 실제로 성립할지 확신할 수 없는 조인을 만들어내는 것입니다.
레이어를 혼동하는 문제도 있습니다. 셀러 센트럴 화면에는 주문별 Net Proceeds가 표시됩니다. 하지만 이 화면은 Settlement Report가 아닙니다. 화면 레이어의 값을 가져온 에이전트는 원본이 아니라 요약을 참고하고 있는 셈이고, 그 답은 은행에 실제로 입금된 금액과 맞지 않습니다.
국가별 차이도 무시할 수 없습니다. 쇼피 Income Report는 싱가포르, 베트남, 태국이 서로 다른 구조를 씁니다. 컬럼 이름도 다르고 수수료 항목도 다르게 기록됩니다. 한 국가에서 정확하게 동작하던 에이전트가 다른 국가에서는 데이터를 잘못 해석합니다. 더 곤란한 것은 잘못 읽고 있다는 사실조차 드러나지 않는다는 점입니다.
데이터 소스가 늘어날수록 에이전트가 하는 일은 분석보다 추측에 가까워집니다.
팔란티어는 이 문제를 어떻게 풀었을까요?
원천 데이터와 애플리케이션 사이에 온톨로지라는 런타임 레이어를 두었습니다.
팔란티어가 Foundry를 설계하면서 세운 원칙은 명확합니다. 어떤 애플리케이션도 원천 테이블을 직접 조회하지 않는다는 것입니다. 에이전트는 CSV를 쿼리하지 않습니다. 대신 Order, Fee, RevenueEvent처럼 타입이 정의된 속성과 탐색 가능한 관계를 갖춘 객체 그래프에 질의합니다.
팔란티어가 자사 AI 플랫폼인 AIP를 Foundry의 온톨로지 위에서 동작하도록 설계한 이유도 여기에 있습니다. 에이전트가 안정적으로 판단하려면, 그보다 먼저 의미 체계가 갖춰져 있어야 하기 때문입니다.
온톨로지는 무엇으로 이뤄질까요?
원천 데이터 위에 네 가지를 정의하는 것에서 시작합니다. 객체, 속성, 링크, 그리고 상태입니다.
표를 보면 공통된 특징이 하나 있습니다. 네 가지 모두 쿼리를 실행할 때마다 새로 해석하는 정보가 아니라, 온톨로지 레이어에서 한 번 정의해두는 기준이라는 점입니다.
funded_by는 답을 주지 못하는 컬럼을 억지로 해석해 얻는 값이 아니라 미리 정의된 속성입니다. return_status 역시 자유 텍스트가 아니라 정해진 상태값을 따릅니다. 상태 또한 마켓플레이스마다 제각각인 문자열을 일일이 훑는 대신, 에이전트가 상태 머신에 질의합니다.
기준을 한 번 정의해두면 이후 모든 쿼리가 같은 언어를 씁니다. 검색이 정밀해지는 이유가 여기에 있습니다.
에이전트가 "모른다"고 답하는 것이 왜 더 나을까요?
그 답이야말로 데이터가 뒷받침할 수 있는 가장 정확한 결론이기 때문입니다.
재원을 확인할 수 없는 라이트닝 딜에 funded_by = UNKNOWN을 부여하는 것은 실패가 아닙니다. 지금 확보한 데이터로 알 수 있는 범위를 있는 그대로 표현한 결과입니다.
UNKNOWN을 반환하는 에이전트는 빈칸을 빈칸으로 남겨둡니다. 반대로 그 빈칸을 임의의 값으로 채우는 에이전트는 확신에 찬 잘못된 귀속을 그대로 다음 단계로 흘려보냅니다.
온톨로지는 이런 공백을 숨기지 않고 명시적으로 드러냅니다. 그래서 추론도 더 정직해집니다. 데모에서 그럴듯해 보이는 에이전트와 월말 결산에서 실제로 기댈 수 있는 에이전트는 바로 이 지점에서 갈립니다.
더 좋은 모델보다 먼저 필요한 것은 데이터 구조입니다
데모에서는 잘 동작하던 에이전트가 운영에서 흔들리는 이유는 대부분 모델이 아니라 데이터 인프라에 있습니다. 구조가 잡히지 않은 데이터 위에서는, 성능이 더 뛰어난 모델이 확신에 찬 오답을 더 빠르게 만들어낼 뿐입니다.
에이전트 레이어와 데이터 레이어는 해결해야 하는 문제가 서로 다릅니다. 데이터 구조를 정리하기도 전에 모델부터 교체하는 것은 순서가 바뀐 접근인데요. 기반이 그대로면 결과도 크게 달라지지 않습니다.
포트원은 마켓플레이스 재무 데이터의 출처와 조인 방식, 의미 정의를 캐노니컬 모델에서 처리해 에이전트가 추측이 아니라 사실을 기반으로 답할 수 있는 온톨로지 런타임을 만들고 있습니다. 온톨로지가 왜 필요한지 개념부터 살펴보고 싶다면, 앞서 발행한 온톨로지 아티클도 함께 읽어보세요.
자주 묻는 질문 (FAQ)
Q1. Settlement Report의 Promotion 행만 보면 프로모션 비용을 확인할 수 있지 않나요?
확인할 수 없습니다. Promotion 행은 할인이 있었다는 사실만 기록하고, 그 재원이 어디였는지는 담지 않습니다. 라이트닝 딜 하나만 해도 전액 아마존 부담, 전액 브랜드 부담, 양측 분담이 모두 가능한데 보고서는 이 셋을 구분하지 않습니다.
Q2. 그렇다면 부담 주체는 어떻게 확인하나요?
내부 캠페인 기록을 Settlement Report와 맞대봐야 합니다. 다만 그 전에 프로모션 비용을 어디까지 볼 것인지, 재원은 어떻게 구분할 것인지, 어떤 데이터가 정본인지가 정의돼 있어야 합니다. 이 정의가 없으면 대조 작업 자체가 쿼리 시점의 스키마 추론이 됩니다.
Q3. 셀러 센트럴 화면의 숫자를 그대로 쓰면 안 되나요?
권하지 않습니다. 셀러 센트럴은 주문당 Net Proceeds 하나를 보여주는 요약 화면일 뿐 Settlement Report가 아닙니다. 화면 레이어의 값을 가져오면 원본이 아니라 요약을 보고 있는 셈이고, 그 숫자는 은행에 실제로 정산되는 금액과 맞지 않습니다.
Q4. 에이전트가 UNKNOWN을 반환하면 쓸모없는 답 아닌가요?
오히려 그 반대입니다. 재원을 확인할 수 없는 라이트닝 딜에 UNKNOWN을 부여하는 것은 지금 데이터로 알 수 있는 범위를 정확히 표현한 결과입니다. 빈칸을 임의의 값으로 채운 답이 잘못된 귀속을 다음 단계로 전달하는 것보다 안전합니다.
.png&w=3840&q=75)
