IT 서비스 공룡이 AI에 잠식될 때 정산팀이 읽어야 할 것

인포시스가 팔던 것의 정체

Vishal Sikka가 새 스타트업을 세웠다. SAP CTO, 인포시스 CEO를 거친 그가 이번엔 Mayfield·Aramco Ventures의 자금을 등에 업고 IT 서비스 시장 자체를 겨냥했다. 타깃은 Infosys, Wipro, Accenture — 수십만 명의 컨설턴트를 부려 전 세계 기업 시스템을 구축·유지해온 업체들이다.

그런데 IT 서비스 업계 뉴스가 결제·정산 파이프라인 얘기와 무슨 상관이냐. 뒤집어 보면 금방 연결된다. 저 회사들이 팔아온 핵심 서비스 중 상당수가 정확히 우리가 직접 굴리는 것들이다. 결제사 정산 파일 파싱, 자사 DB 매칭, 예외 건 처리 자동화, ERP 회계 연동. 중견 이커머스 기업이 이 파이프라인 하나를 Infosys에 의뢰하면 컨설턴트 510명, 기간 36개월, 비용 2억~8억 원이 나온다. 우리는 그걸 내부 팀이 직접 만들어 왔다. Sikka가 도전하려는 시장이 사실은 우리가 이미 그 대안으로 살아남고 있는 영역이다.

Sikka가 겨냥하는 구조적 약점

인포시스의 FY2024 기준 임직원 수는 약 31만 7천 명, 매출은 182억 달러다. 이 규모가 가능한 이유는 반복성이다. 비슷한 패턴의 시스템 구현을 수백 개 고객사에 걸쳐 복사하면서 단가를 유지한다. 결제 시스템도 마찬가지 — 파싱 로직은 다르지만 흐름은 똑같다. 수신·매칭·예외처리·정산·보고. 이 반복성이 AI의 먹이다. Sikka는 그걸 정확히 알고 있다. SAP 코어를 손에서 떼어내고 VianAI를 통해 엔터프라이즈 AI 구현을 시험해본 사람이 새 팀에 SAP·Infosys 베테랑을 붙인 건 우연이 아니다.

시장이 이미 반응하고 있다는 신호도 있다. Infosys의 주가는 2021년 고점 대비 여전히 회복이 더디고, 애널리스트들은 매 분기 '헤드카운트 효율화' 압박을 걸고 있다. IT 서비스 산업은 AI를 내부 도구로 쓰면서 사람을 줄이거나, 아니면 AI 네이티브 경쟁자에게 자리를 내주거나 — 두 갈래 앞에 서 있다.

소팀 입장에서 이 흐름이 던지는 두 신호

우리 같은 팀 — 정산 파이프라인을 컨설팅 업체 없이 직접 굴리는 소규모 엔지니어링 조직 — 에게 이 뉴스는 두 가지 신호다.

첫 번째는 우리가 이미 그 방향에 와 있다는 것이다. Infosys에 줄 예산이 없어서 직접 만들어온 것들이 이제 "AI 네이티브 접근"이라는 이름을 달고 트렌드가 됐다. 우리는 시장보다 수년 앞서 이 방식을 강제로 체득했다. 이건 자랑이 아니라 사실 확인이다.

두 번째 신호가 더 중요하다. 엔터프라이즈용으로 개발되던 도구들이 빠르게 내려온다는 점이다. Sikka 같은 팀이 대기업을 위해 만드는 AI 정산 자동화 컴포넌트 — 결제 예외처리 분류기, 정산 파일 범용 파서, 이상 거래 탐지기 — 가 제품화되거나 오픈소스로 나오는 속도가 2010년대와는 차원이 다르다. 우리가 지금 직접 짜고 있는 것들의 완성도 높은 버전이 1~2년 안에 SaaS나 패키지 형태로 나올 가능성이 크다.

정산 파이프라인에서의 진짜 트레이드오프

우리 정산 흐름을 예시로 뜯어보자. PG사 정산 파일 수신 → 주문 DB 매칭 → 미결 건 분류 → 예외 건 수동 검토 → 회계 연동. 이 중 자동화된 구간은 파일 수신, DB 매칭, 룰 기반 1차 분류까지다. 수동 검토와 최종 판단은 여전히 사람이 한다.

Claude나 ChatGPT를 정산 SQL 작성에 활용해본 팀이라면 알겠지만, 속도 차이는 실감 난다. "이 정산 파일 컬럼 구조에서 중복 거래 건 추출하는 쿼리 짜줘"라고 넣으면 2~3분 안에 동작하는 쿼리가 나온다. 전에는 개발자가 한 시간 붙잡고 있던 작업이다. 이런 챗GPT 활용 팁이 정산 현장에서 실제로 쓸모 있는 건 단순한 코드 생성 때문이 아니다. 도메인 케이스를 자연어로 서술하면 코드로 바꿔주는 속도가 의사결정 사이클을 줄여준다는 게 핵심이다.

그런데 함정이 있다. 95%는 잘 돌아간다. 나머지 5%에서 조용히 틀린다. 타임존 불일치, PG사 정산 지연 케이스, 카드사별 수수료 계산 방식 차이. 이런 엣지케이스에서 모니터링이 없으면 오류를 모른다. IT 서비스 업체 비용이 비싼 이유 중 하나가 바로 그 5%를 잡아내는 감리 구조와 경험치였다. 우리가 AI로 속도를 얻는 대신 포기하는 건 그 경험치의 두께다. 오류의 성격이 바뀐다 — 명시적으로 깨지는 게 아니라 조용히 틀린 숫자가 쌓인다.

우리 팀이라면 이렇게 접근한다

실제 시나리오 하나. 결제사를 새로 추가할 때마다 정산 파일 포맷이 다르다. 이전엔 개발자가 파서 코드를 처음부터 짰다. 이제라면 이렇게 한다. 파일 샘플을 Claude에 붙이고 파서 초안을 받는다. 그 코드에 실제 정산 파일 200~300건으로 검증 테스트를 돌린다. 통과하면 배포하되 — 반드시 이상 탐지 알림을 건다. "전일 대비 정산 총액 5% 이상 차이"나 "미매칭 건수 임계값 초과" 같은 것. 이 흐름이 IT 서비스 업체에게 3개월짜리 프로젝트였던 걸 2주 안으로 압축한다.

예외처리 분류 로직도 같은 방식으로 접근할 수 있다. 결제 실패 코드가 수십 종류다. 이를 재시도 가능·불가·고객 이관·내부 에스컬레이션으로 나누는 룰을 예전엔 문서로만 관리했다. 지금은 실제 케이스를 프롬프트에 넣어 분류기 초안을 만들고, 과거 오류 이력을 기반으로 엣지케이스를 추가하며 정교화한다. 도메인 지식은 우리가 갖고 있고, AI는 코드화 속도를 올리는 역할이다. 이 역할 분담이 명확할 때 AI는 실제로 쓸모 있다. 판단을 AI에 맡기려 할 때 문제가 생긴다.

지금 바로 써먹을 수 있는 것

Sikka의 스타트업이 Infosys를 얼마나 흔들지는 3~5년 뒤에 알 수 있다. 그전에 지금 할 수 있는 게 더 실용적이다.

먼저 정산 파이프라인의 수동 구간을 목록으로 뽑아라. "사람이 엑셀 열어서 눈으로 확인하는" 구간, "슬랙 알림 보고 직접 DB 쿼리 치는" 구간이 어디인지 항목화한다. 거기서 두 기준으로 우선순위를 정한다. 반복 빈도가 높은 것, 그리고 놓쳤을 때 파급이 큰 것. 이 두 조건이 겹치는 지점이 AI 보조 자동화를 먼저 투자해야 할 곳이다.

자동화를 배포할 때는 이상 탐지 알림을 세트로 묶어라. 정산 총액 편차, 미매칭 건수 임계값, 처리 지연 시간 — 이 세 가지만 모니터링해도 AI가 조용히 내는 오류를 잡을 수 있다. Sikka가 겨냥하는 대기업 시장에서 가장 비싼 부분이 이 감리 구조인데, 소팀은 단순한 알림 몇 개로 그 역할의 70~80%를 커버할 수 있다.

마지막으로 — 지금 직접 짜고 있는 파서, 분류기, 매칭 로직을 단순 스크립트가 아니라 파라미터화된 컴포넌트로 만들어두는 습관이 필요하다. 1~2년 안에 같은 기능을 하는 SaaS 도구가 나올 때, 교체 비용이 낮을수록 빠르게 올라탈 수 있다. 우리가 직접 만든 것에 집착하다 전환 기회를 놓치는 게 소팀의 전형적인 실수다. Sikka의 도전이 시장에 성공하든 실패하든, 그 파급으로 나오는 도구들은 우리가 쓸 수 있다.

원문: AI News & Artificial Intelligence | TechCrunch