남이 갖지 못한 데이터가 있으면 유리할 수 있다. 다만 그 데이터로 어떤 결과가 좋아지는지 설명할 수 있어야 한다. 자료가 많다는 사실만으로 고객이 더 좋은 서비스를 받거나 경쟁사의 진입이 어려워지는 것은 아니다.
추가 데이터의 효과는 일정하지 않다
a16z의 2019년 글은 데이터 축적이 자동으로 지속적인 경쟁우위로 이어진다는 가정을 비판했다. 데이터가 늘 때 성능 개선 폭이 줄거나 드문 사례를 확보하는 비용이 커질 수 있다는 것이다.
원문에 제시된 특정 사례의 수치를 모든 제품의 한계로 적용해서는 안 된다. 예를 들어 “데이터의 효과는 40%에서 멈춘다”는 보편적인 법칙은 없다. 어떤 요청을 얼마나 더 해결하는지, 그 개선에 얼마가 드는지를 실제로 측정해야 한다.
같은 정보를 중복해서 모으는 것과 드물지만 중요한 사례를 확보하는 것은 효과가 다르다. 데이터의 출처, 정확성, 갱신 주기도 양만큼 중요하다.
제품을 쓰면서 생기는 수정 기록
고객이 결과를 수정하거나 반려한 기록은 개선에 도움이 될 수 있다. 모델이 어떤 조건을 놓쳤는지, 어느 표현을 잘못 이해했는지 알 수 있기 때문이다.
하지만 수정 기록이라고 모두 정답은 아니다. 고객의 취향 변화, 입력 실수, 상황에 따른 예외도 섞인다. 누가 무엇을 왜 고쳤는지, 그 수정이 다음 작업에도 적용되는지 구분해야 한다.
이 기록을 다음 평가와 제품 개선에 연결하면 사용 과정에서 학습할 수 있다. 데이터를 모으는 기능만 있고 실제 개선 과정이 없다면 기록은 늘어도 제품의 차이는 커지지 않을 수 있다.
사용 권한과 데이터 구조가 필요하다
고객이 제공한 자료를 보관할 수 있다는 것과 모델 학습에 활용할 수 있다는 것은 다를 수 있다. 계약과 동의 범위에 맞게 사용하고, 고객이 떠났을 때 보관·삭제할 범위도 확인해야 한다.
기술적으로는 수정 기록이 어떤 고객, 요청, 문서 버전과 연결되는지 알아야 한다. 단순한 텍스트 로그만으로는 같은 오류를 다시 찾기 어려울 수 있다. 일관된 식별자와 변경 이력이 있으면 원인을 분석하고 수정 전후를 비교하기 쉬워진다.
작은 팀이 먼저 확인할 것
보유 자료를 기준으로, 공개 모델만 사용할 때보다 실제 결과가 좋아지는 요청을 찾아본다. 그 차이가 고객에게 중요한지도 확인한다. 데이터를 유지하는 비용이 개선 효과보다 크다면 다른 접근을 검토할 수 있다.
독점 데이터의 가치는 수집량 하나로 정해지지 않는다. 필요한 정보를 적법하게 확보하고, 잘못된 내용을 고치고, 그 결과를 제품에 반영할 수 있을 때 경쟁력으로 이어질 가능성이 커진다.