올해 US 오픈에서는 카메라를 사용하여 테니스 서브를 관찰하고 점수를 매기는 인공지능 기반 시스템이 있습니다.00:00

그런데, 그렇게 하려면 에이전트 내에 포함될 수 있는 AI 모델이 필요합니다.00:08

자, 이 인공지능 모델은 저희가 API라고 부르는 것과 연결되기도 합니다. 이건 잠시 후에 말씀드릴 굉장히 중요한 요소 중 하나입니다.00:15

왜 이렇게 필요할까요? 지금부터 그 이유를 생각해 보겠습니다.00:23

왜 API를 사용하는 거죠?00:27

AI 모델이 혼자서 테니스 서브 심판 일을 어느 정도까지 해낼 수 있을까요?00:29

음, 예를 들어서 제가 인공지능 모델에게 '제시카 파굴라는 서브가 좋은가?'라고 질문한다고 해 보겠습니다.00:34

이제 모델은 이와 같은 질문에 어느 정도 답을 할 수 있습니다.00:39

하지만 거대 언어 모델은 테니스에 관한 거의 모든 글을 읽었을 가능성이 높습니다.00:43

그것이 우리가 '훈련 데이터'라고 부르는 것입니다.00:48

그리고 이 학습 데이터를 함께 입력하면서요,00:52

그러면 이 API에 연결하여 저에게 다양한 정보를 알려줄 수 있는 기초 모델을 구축할 수 있습니다.00:56

파굴라가 공의 회전과 위치를 고려하여 서브를 다시 구축한 것과 같은 방식으로요.01:03

코트에서 수집되는 모든 데이터는 모델 학습이 완료되기 전부터 이미 존재하는 데이터를 의미합니다.01:08

그러다 보니, 특정 경기에서 특정 선수의 서브가 얼마나 잘 되고 있는지 정확하게 답변하기는 어렵습니다.01:14

만약 현재 그 상황을 평가할 수 있다면, 그렇게 할 수 있는 방법 중 하나는 다음과 같습니다.01:20

현재 경기 기록을 구축하고 불러오기 위해, 여기 나와 있는 기록들을 활용할 수 있습니다.01:25

이러한 기록들은 다음과 같이 활용될 수 있습니다.01:33

통계 관련 정보는 컨텍스트 창에 붙여넣어 AI 모델 자체로 보내질 수 있습니다.01:34

될 수 있습니다.01:41

파굴라의 마지막 서브가 시속 97마일 정도, 그러니까 에이스로 들어갔다고 할 수 있습니다.01:41

이제 모델에게 기본적인 정보와 현재 경기에서 일어난 상황을 제공하여 준비를 마쳤습니다.01:49

지금까지 우리가 확보한 모든 데이터를 활용해서 답변을 내놓는 것이고요, 서브 속도나 에이스 같은 통계 정보들도 포함됩니다.01:55

이런 통계들은 결과에 기반한 지표라서, 서브가 어떤 결과를 냈는지 보여줄 뿐, 어떻게 던져졌는지에 대한 자세한 내용은 잘 나타내지 않습니다.02:02

선수가 실제로 공을 만들 수 있도록 움직였는데, 보기 흉한 동작으로도 에이스를 기록할 수 있습니다.02:09

그리고 믿으세요. 저도 직접 경험해 봤습니다. 보기 흉한 에이스가 나올 수도 있죠. 더 나은 답변을 얻기 위해 인공지능에게 보여주는 건 어떨까요?02:15

모델에게 비디오 클립을 보여주고, 이 비디오 클립은 다른 데이터와 함께 입력될 수 있습니다. 그러면 어느 정도 작동하는 것 같아요.02:22

다른 모든 데이터를 함께 넣어주면, 꽤 괜찮게 작동합니다.02:27

이제 모델은 투수가 던진 공이 조금 높게 보였고, 무릎을 약간 더 구부릴 수도 있다고 보고할 겁니다.02:30

하지만 다시 말씀드리지만, 이는 전문적이지 않은 모델이 파악할 수 있는 것들에 한정된 것입니다. 그리고 이 영상의 몇몇 프레임 내에서만 가능합니다.02:38

비디오 데이터의 경우, 이러한 API가 없으면 모델의 일반적인 지식이 상당히 오래된 정보에 머무르게 됩니다.02:45

문맥 창 내에 붙여넣은 통계는 결과만을 설명하며, 이 영상 일부를 보면 알 수 있습니다.02:51

이 비디오는 폭넓은 인상을 주지만, 우리가 사용할 수 있는 정확한 측정값은 아니고요. 그래서 AI 모델이 놓치고 있는 것은 이 모든 정보와 맥락을 측정하는 시스템과의 연결입니다.02:57

AI 모델이 부족한 점은 이 모든 정보를 측정하고 맥락을 파악하는 시스템과 연결되지 못한다는 것입니다.03:03

동시에, 이걸 API라고 부를 수 있습니다. 자, 이제 이 API가 무엇을 제공하는지 이야기해 보겠습니다.03:09

저희는 가지고 있습니다.03:16

2026년 US 오픈에서 도입된 서브 품질 데이터로, 모든 254개의 단식 경기에서 활용되었습니다.03:17

그리고요.03:24

경기 코트 사이드 카메라가 공과 라켓, 그리고 선수 신체의 21개 관절을 추적합니다.03:25

서브 동작을 촬영하는데요, 이 데이터를 합치면 무려 10억 건이 됩니다. 네, 여러분, 10억 건이죠.03:32

데이터 포인트인데, 굉장히 많은 정보량이 있습니다. 따라서 아무도 그걸 모두 읽고 실제로...03:39

언어 모델조차도 불가능합니다. 대신 전문적인 서비스에서 그 스트림을 두 개로 처리합니다.03:46

다양한 점수들이 있는데, 첫 번째는 효율성입니다. 이 점수는 생체역학에 관한 것으로,03:53

무릎의 구부러짐 정도나 엉덩이와 어깨의 분리 등 다른 기계적인 부분에 대한 것입니다.03:58

그러한 경향성 같은 것들이 있고, 이제 두 번째로 넘어가 보겠습니다. 그 점수는 효율성을 나타냅니다.04:03

이 점수는 결과이며, 이전에 붙여넣은 통계치와 관련됩니다. 예를 들어 속도를 살펴보겠습니다.04:08

공의 위치가 반환하기 정말 어려운 공간을 찾았는지 확인합니다. 이제 이 두 가지를 모두 합치면,04:14

다양한 요소들을 함께 고려하여 품질 점수를 나타내겠습니다.04:21

이것은 저희가 'IBM Bob'이라고 부르는 것을 이용해서 개발되었습니다.04:30

서브에 가장 큰 영향을 미치는 지표들을 식별하고 가중치를 두기 위해 사용했습니다.04:31

그리고 저희가 수행했던 생체역학 및 운동 사슬 연구를 바탕으로, 어떤 동작이 효과적인 서브에 가장 기여하는지 알아내기 위해 개발되었습니다.04:37

이 모든 과정은 꽤나 영리하다고 할 수 있습니다.04:43

그런 것들이죠. 그런데 왜 이런 점수 계산을 이 API 안이나 특화된 서비스 내에서 해야 할까요?04:48

그냥 데이터를 AI 모델에 바로 넘겨줘서 알아서 처리하도록 할 수는 없을까요?04:54

점수를 스스로 매기는 거죠? 생각해 보면, 21개의 추적 지점이 있고, 각 지점에05:00

세 개의 좌표가 있습니다. 그리고 이를 초당 50번 샘플링합니다.05:07

자, 제가 계산해 보면, 이건 총...05:12

매 초마다 3천 개가 넘는 숫자와 수백만 개의 위치 정보입니다.05:15

경기 전체 지속 시간 동안의 값들이 상당히 많습니다. 이건 매우 큰 컨텍스트 창을 의미합니다.05:22

그리고 백만 개 정도의 토큰, 혹은 그 이상을 담고 있습니다.05:27

그러니까 단일 경기에서 나오는 원시 데이터는 들어갈 수도 있을 것 같습니다.05:31

하지만 그렇다 하더라도, 거대 언어 모델은 결국 다음 토큰을 예측하는 데 특화되어 있습니다.05:34

지금 말씀드리는 건, 관절 각도를 구동하는 것처럼 많은 양의 계산을 처리하는 것은요,05:39

좌표 스트림에서 얻어지는 관절 각도를 계산하는 데에는 강점이 있는 편은 아닙니다.05:43

그래서 이 모든 것 뒤에 있는 백엔드 서비스는, API에서 기본적으로 카메라 위치라고 부르는 것을 가져와서...05:47

그 다음 단계로 진행합니다.05:50

관절로 들어가서 생체역학적인 측면으로 변환됩니다.05:57

결국 저희가 '스코어'라고 부르는 결과값을 얻게 됩니다.06:04

데이터가 저희의 대규모 언어 모델에 도달할 때쯤에는,06:09

실제로 단지 몇 킬로바이트 정도의 구조화된 데이터일 뿐이며, 쉽게 메모리에 들어갈 만큼 작습니다.06:12

맥락을 이해하고 추론할 수 있을 만큼 의미 있는 데이터가 됩니다.06:18

그리고 이 데이터를 바탕으로 LLM이 활용되는 부분입니다.06:21

제가 질문하고 모델에 요청할 수 있는 어떤 질문과 같이요,06:28

예를 들어 파골라의 파도 품질은 이 세트에서 더 많이 상승했는데, 이는 더욱 일관성 있는 정보를 제공하는 데 도움이 되었기 때문입니다.06:33

공을 던지는 부분입니다. 이제 모델이 실제로 정말 잘하는 부분을 처리하게 되는데, 그건 다양한 측정값을 사람이 읽기 쉬운 문장으로 바꾸는 것입니다.06:38

사람이 이해할 수 있는 문장으로 변환하는 것이죠.06:44

사용자의 질문을 명확하게 해결해 주는 것이 하나의 매우 구체적인 파이프라인이고, API 호출이 발생합니다.06:49

이번 US 오픈 예시에서 팬이 토너먼트 앱에 질문을 했을 때요.06:56

그 질문은 파굴라가 오늘 몇 게임을 서브했는지와 같은 내용일 수 있습니다.07:03

그래서 에이전트가 그런 종류의 질문에 답하기 위해 사용됩니다.07:05

질문이 무엇이고, 다음 단계에서는 모델에게 도구 목록이 전달됩니다.07:12

이제 이 도구들… 이 도구들은 컨텍스트 내에서 정의를 가지고 있습니다.07:20

각 도구는 이름, 설명, 그리고 필요한 매개변수를 가지고 있습니다.07:23

그런 다음 '서브 퀄리티 API'가 이러한 도구 중 하나로 나타납니다.07:28

모델이 데이터가 필요하다고 판단되면요07:33

구조화된 요청을 출력하는데, 저희는 이걸 '하니스'라고 부릅니다.07:36

이 하니스는 결국 API로 요청을 보내게 되며, 그러면 이 품질 서비스 요소일 수 있습니다.07:44

이 품질 서빙 엘리먼트가 될 것입니다.07:51

그리고 호출이 완료되면, API가 데이터를 컨텍스트로 반환할 수 있습니다.07:54

모델이 모든 정보를 바탕으로 추론할 수 있도록 데이터를 컨텍스트에 전달합니다.07:58

가지고 있습니다. 이제 이것은 연속적인 루프로 실행될 수 있습니다.08:06

그래서 모델이 무엇에 대해 추론할 수 있습니다.08:10

정보가 부족할 수도 있으니, 다른 도구를 요청하고 결과를 읽은 다음 결정해야 합니다. 답변을 할 만큼 충분한 정보가 있는지요.08:13

아직 아니라면 에이전트 루프를 다시 돌게 될 텐데, 어쩌면 그럴 수도 있습니다.08:19

이번에는 다른 API를 호출하고, 심지어는 다른 도구를 선택할 수도 있습니다. 충분한 정보를 얻었을 때08:26

답변을 작성합니다. 모델과 도구, 그리고 목표가 함께 작동하는 방식이라고 보시면 됩니다.08:31

이 에이전트의 정의에 대해 말씀드리겠습니다. 테니스에 대해 많이 이야기했지만, AI 에이전트와 API 접근을 결합하는 동일한 워크플로우가08:38

곳곳에서 나타납니다.08:45

에이전트가 문제 해결을 위해 패턴을 따르는 것과 같아요.08:50

예를 들어, 프로덕션 장애를 조사할 때 모니터링 API와 로그 API에서 정보를 가져올 수 있습니다.08:53

지금은 전문적인 시스템이 모든 복잡한 작업과 처리 과정을 담당하고, API는 그 연결 고리 역할을 합니다.08:58

특화된 시스템이 대부분의 무거운 작업을 하고, 처리도 맡아서 API가 바로...08:59

모델로 전달하는 과정이 정말 중요합니다. 그럼 왜 아예 API를 사용하는 걸까요?09:06

글쎄요, 그건 모두...09:11

전문적인 서비스는 데이터를 측정하고 정보를 계산하여, 대규모 언어 모델이 자체적으로 처리하기 어려운 부분을 분담합니다.09:13

그리고 모델은 추론을 수행합니다.09:18

결과를 분석해서 사람이 실제로 활용할 수 있는 형태로 만들죠. 그게 어떤 분야든, 예를 들어 테니스 팬이든지,09:25

혹은 응급 상황에 대처해야 하는 엔지니어든지 간에요.09:30