SAP CTO 인터뷰 정리: 2만 개 API가 만드는 규모의 문제와 평가 데이터, 표 데이터 예측 모델

핵심 메시지

• 기업 AI의 난이도는 모델이 아니라 규모에 있다. 문서 10건짜리 시연은 쉽지만 문서 수천 건, API 2만 개 환경에서 같은 방식은 통하지 않는다.
• 코딩 에이전트가 잘 작동하는 이유는 컴파일과 테스트로 결과를 검증할 수 있기 때문이다. 재무 같은 업무에 같은 신뢰도를 얻으려면 입력과 정답을 짝지은 평가 데이터가 먼저 필요하다.
• 시스템에 기록되지 않고 사람 머릿속이나 대화에만 있던 암묵지를 에이전트가 되묻고 그 기록을 축적하면, 다시 평가 데이터가 되는 선순환이 만들어진다.
• 수요 예측이나 대금 회수 지연 예측처럼 표 형태 데이터를 다루는 일은 언어 모델이 잘하지 못해, SAP는 관계형 데이터를 위한 별도 사전학습 모델을 연구해 공개했다.
• AI 도입은 기술 전환인 동시에 사업 모델 전환이라, 좌석 기반 과금에서 소비량 기반, 나아가 성과 기반으로 이동하는 흐름이 이미 시작됐다.

쉽게 이해하기

노 프라이어스 팟캐스트에 SAP 최고기술책임자 필립 헤르치히가 출연했다. SAP는 40만 곳의 기업 고객이 재무와 인사, 공급망, 제조 실행, 물류, 판매와 조달까지 돌리는 소프트웨어를 만든다. 그는 이를 두고 단순한 소프트웨어가 아니라 '회사의 운영체제'라고 표현했다. 메인프레임에서 클라이언트-서버로, 인터넷과 모바일을 거쳐 AI까지 여러 전환을 지나오면서도 회사가 살아남은 이유로는 고객이 원하는 것이 기술이 아니라 성과와 투자 회수였다는 점을 들었다.

그는 AI가 소프트웨어를 세 층에서 바꾸고 있다고 정리했다. 첫째는 화면이다. 사용자가 클릭으로 일을 처리하도록 가르치는 인터페이스를 설계하던 시대는 끝났고, 질문에 따라 화면이 생성되며 시스템이 밤새 돌다가 아침에 먼저 문제를 알려 주는 방향으로 간다. 둘째는 업무 프로세스다. 주문에서 대금 회수까지 비교적 경직됐던 절차에 에이전트가 들어오면서 정형과 비정형 데이터를 섞어 처리할 수 있게 됐다. 셋째는 데이터 계층으로, 총계정원장과 재고 같은 사내 데이터를 외부 데이터와 묶어 하나의 의미론적 관점으로 정리하는 작업이다. 그는 AI의 성능은 결국 데이터만큼이라고 못 박았다.

가장 큰 기술적 난제로는 'AI를 규모에서 제대로 학습시키는 일'을 꼽았다. 2년 전에는 문서 10건짜리 챗봇 시연으로 경영진을 놀라게 하기 쉬웠지만, 문서가 1000건이 되면 본격적인 엔지니어링 문제가 된다는 것이다. 사내 도우미에게 출장 규정을 물어도 미국 직원과 독일 직원에게 서로 다른 답이 나가야 하므로 근무지와 급여 체계, 세제 같은 마스터 데이터와 연결해야 한다. MCP 서버도 마찬가지다. API 10개는 쉽고 100개는 컨텍스트가 넘치기 시작하는데, SAP가 다루는 API는 2만 개다.

그는 코딩 에이전트가 유독 잘 작동하는 이유가 컴파일 여부와 단위 테스트로 결과를 검증할 수 있기 때문이라고 봤다. 재무 업무에서 같은 수준의 신뢰를 얻으려면 '이 입력에는 이 출력'이라고 말해 주는 데이터, 즉 평가 세트가 필요하다. 이 대목에서 그는 테스트 주도 개발이 돌아오고 있다고 농담을 던졌다. 예전에는 요구사항이 지저분해 테스트를 먼저 쓰기 어려웠고 코드를 쓰는 편이 재미있었지만, 코드 작성이 자동화된 지금은 원하는 결과를 정확히 기술하는 일이 개발자의 핵심 업무가 됐다는 것이다. 나아가 에이전트가 사람에게 되묻는 과정에서 슬랙이나 통화에만 남아 있던 암묵지가 기록으로 쌓이고, 그 기록이 다시 평가 데이터와 표준 업무 절차 개선으로 이어지는 데이터 선순환을 그렸다.

덜 알려진 대목은 예측 모델에 대한 견해다. 수요 예측, 현금 흐름 예측, 고객이 결제 기한을 넘길지와 얼마나 늦출지 같은 문제는 분류와 회귀에 해당하는데 언어 모델은 토큰을 차례로 생성하는 구조라 여기에 맞지 않는다. 그렇다고 기존 방식으로 돌아가면 90개국에서 사업하는 제약사 한 곳에 180개의 모델을 따로 만들어야 하는 식으로 확장되지 않는다. SAP는 비정형 데이터에서 통한 사전학습 발상을 표 형태의 관계형 데이터에 적용하는 연구를 2년간 진행해 논문을 발표하고 모델을 공개했다고 밝혔다. 과금에 대해서는 지금이 좌석 기반과 소비량 기반이 섞인 하이브리드이며, 검증 가능성이 높아지면 성과 기반으로 옮겨갈 수 있지만 고객이 비용 예측 가능성을 원하기 때문에 단계적으로 갈 수밖에 없다고 설명했다.

주요 인사이트

• 시연과 운영 사이의 간극이 기업 AI의 핵심 난제라는 진단은, 성공적인 파일럿이 곧 도입 성공을 뜻하지 않는 이유를 설명한다. 규모가 커지면 문제의 성격 자체가 바뀐다.
• 검증 가능성이 곧 자동화 가능성이라는 논리는 어떤 업무에 에이전트를 먼저 투입할지 판단하는 실용적 기준이 된다. 정답을 확인할 수단이 없으면 개선 루프도 돌지 않는다.
• 테스트 주도 개발이 돌아온다는 관찰은 개발자의 역할 이동을 압축한다. 코드를 쓰는 대신 원하는 결과와 경계 조건을 정확히 기술하는 일이 남는다.
• 표 형태 데이터를 위한 전용 모델이 필요하다는 주장은, 모든 문제를 언어 모델로 풀려는 접근의 한계를 기업 현장의 구체적 사례로 보여준다.
• 성과 기반 과금으로 곧장 갈 수 없는 이유가 기술이 아니라 고객의 비용 예측 가능성 요구라는 설명은, 사업 모델 전환이 검증 가능성 확보와 함께 움직인다는 점을 시사한다.

자주 묻는 질문

관련 AI 소식