이네스 & 소피 — 산업용급 NLP 파이프라인 구축

다음 플랫폼에서 듣기

게스트 소개

이네스와 소피와 연결하기

쇼 노트

다룬 주제

대본

예전에 “내 시스템을 정확도 90%로 만들고 싶어요”라고 말하는 분들이 있었어요. 그래서 우리가 “무엇에 대해 90%인가요?”라고 물으면, 그분들은 “아니요, 그냥 90% 정확도요”라고 하곤 하죠. 하지만 실제로는 당신의 시스템이 무엇을 하느냐가 시스템의 성공을 좌우하고, 그걸 측정해야 하며, 거기에 집중해야 합니다. 이런 관점이 의식하지 않으면 종종 사라지기 쉬워요. 특히 알고리즘 비교가 목표인 연구를 그대로 따라가면 목적이 조금 달라서 그렇습니다.

지금 여러분은 Gradient Dissent를 듣고 있습니다. 이 프로그램은 머신러닝 모델을 현실 세계에서 제대로 작동하게 만드는 방법을 배우는 쇼입니다. 진행자는 저, 루카스 비발드입니다. 오늘은 이네스와 소피와 이야기합니다. 이네스는 AI 기술 도구에 특화된 디지털 스튜디오인 Explosion AI의 공동 창업자입니다. 그녀는 NLP와 Python을 위한 대표적인 오픈 소스 라이브러리인 spaCy의 핵심 개발자이자, 능동 학습으로 구동되는 데이터 주석 도구 Prodigy의 핵심 개발자이기도 합니다. 소피는 Explosion AI의 NLP·머신러닝 엔지니어로, 제약 산업과 식품 산업을 포함해 NLP와 머신러닝 분야에서 12년 이상의 경력을 보유하고 있습니다. 오늘 두 분과 이야기하게 되어 정말 기대됩니다.

안녕하세요, 이네스입니다. Python용 자연어 처리 오픈 소스 라이브러리인 spaCy로 저를 아시는 분들도 있을 거예요. 저희 회사 이름은 Explosion이고, AI와 머신러닝, 특히 NLP를 위한 개발자 도구에 특화되어 있습니다. 꽤 인기 있는 오픈 소스 도구들을 많이 만들어 왔고, 그건 정말 멋진 일이라고 생각해요. 또 Prodigy라는 상용 제품도 있는데, 머신러닝 모델 학습용 데이터를 만들기 위한 주석(라벨링) 도구입니다. 개발자용 도구이고, Python으로 완전히 스크립팅할 수 있어서 직접 커스텀 데이터 파이프라인을 작성하고, 맞춤형 라벨링 레시피를 만들고, 모델을 루프에 넣어 활용할 수 있어요. 이걸로 할 수 있는 멋진 일들이 정말 많습니다. 그게 저희가 하는 일입니다. 현재는 spaCy 버전 3를 개발 중인데, 굉장히 기대하고 있어요. 이번 버전으로 spaCy를 한 단계 끌어올려서, 최신의 최첨단 NLP 기술들을 누구나 활용할 수 있게 하려 합니다. 또한 Prodigy의 SaaS형 확장인 Prodigy Teams도 함께 개발하고 있습니다. 이를 통해 더 큰 규모의 주석 프로젝트를 확장하고, 대규모 주석 팀을 효율적으로 운영할 수 있도록 하면서도, 데이터 프라이버시와 스크립팅 가능성은 절대 타협하지 않으려 합니다.

좋아요. 라이브러리 세부 내용으로 들어가기 전에, 같은 창업가로서 꼭 여쭤보고 싶어요. 어떻게 시작하게 되었는지, 그리고 그 경험이 어땠는지 이야기해 주실 수 있을까요?

그렇죠. 그러니까 spaCy는 제 공동 창업자인 Matt가 학계를 떠나면서 시작됐어요. 그는 NLP 연구를 하고, 논문을 내고 있었는데, 본인이 늘 하는 얘기가 “이제는 연구비 제안서를 써야 하는 단계에 왔다, 그런데 그건 하고 싶지 않았다”는 거예요. 동시에, 사람들이 그의 연구용 코드를 실제 프로덕션의 특수한 환경에서 쓰고 있다는 걸 깨달았죠. 그건 좀 말이 안 되는 일이었어요. 여전히 연구용 코드였으니까요. 그���서 “분명 여기엔 뭔가가 있구나” 싶었고, 그는 학계를 떠나 오픈 소스 라이브러리로서 spaCy를 쓰기 시작했죠. 그 직후 베를린에서 우리가 만나 함께 일하기 시작했고요. 처음에 저는 라이브러리를 위한 시각화 도구들을 주로 만들었는데, 그건 지금도 사람들이 spaCy를 좋아하는 중요한 이유 중 하나예요. 하지만 처음엔 조금 회의적이었어요. 제 전공이 꼭 NLP는 아니었거든요. 프로그래밍은 계속 해왔고, 언어학을 공부하긴 했지만, 제 첫 반응은 “좀 지루할 것 같은데, 내가 이걸 하고 싶은지 잘 모르겠어…”였죠.

정말요?

네, 말 그대로요. 그래서 그가 “이 구문 시각화 도구가 있으면 정말 좋겠어”라고 했고, 저는 “언어학을 아니까 그게 무엇인지 완전히 알아”라고 했지만, 속으로는 “그건 좀… 꼭 내가 하고 싶은 일인지는 모르겠네. 다른 걸 하고 싶은데”라고 생각했죠. 그래도 했고, 잘됐어요.

그리고 지금도 아주 인기 있죠, 이네스?

맞아요. 사람들이 spaCy를 떠올릴 때 구문 시각화 도구를 많이 생각하는 것 같아요. 그래서 그걸 하길 잘했다 싶어요.

네. 제 느낌으로도 그래요. 정말 아름답네요.

그래서 그렇게 모든 것이 시작됐어요. 그러다 어느 순간 “좋아, 이걸 중심으로 회사를 만들자”라고 생각했죠. 하지만 전형적인 스타트업 방식으로 가고 싶지는 않았어요. “봐, 이걸로 충분히 돈을 벌 수 있어. 회사를 우리 방식대로 운영하면 돼. 적자를 감수할 필요도 없고, 초반부터 미친 듯한 규모 확장이 필요하지도 않아. 그냥 만들고, 만들면서 돈을 벌면 돼”라는 걸 알았거든요. 그래서 그런 철학으로 회사를 세웠고, 지금도 완전히 독립적으로 운영하고 있어요. 그게 멋지고, 여러모로 기회를 많이 줍니다. 지금은 소피를 포함해, 아마 여덟 명 정도 되는 작은 팀이고요. 소피는 우리 팀에 합류한 첫 풀타임 NLP 전문가 중 한 명이었던 걸로 기억해요.

좋네요. 그럼 소피, 팀과 함께 일한 지 얼마나 됐나요?

저는 2019년 초에 spaCy에서 일하기 시작했어요. 그러니까 이제 거의 2년이 됐네요.

와. 네,

브뤼셀의 펍에서 이네스를 만났던 것 같아요.

그래요.

NLP 밋업 이후에.

맞아요, 우연히 만난 건 아니에요.

그래서 그날은 확실히 하나의 주제가 있었어요. 그리고 저는 그들의 비전이 정말 마음에 들었어요. 단지 회사를 어떻게 운영할지에 대한 것뿐 아니라, 데이터와 모델을 어떻게 반복적으로 개선해 나가야 하는지, 그리고 산업 현장에서 기계 학습을 어떻게 적용해야 하는지에 대한 매우 실용적인 관점까지요.

아마 이게 제대로 된 사례도 보셨겠지만, 어떤 맥락에서는 꽤 형편없이 이루어진 경우도 보셨을 것 같아요.

네, 맞아요. 제 배경을 말씀드리면, 저는 생의학 NLP로 박사 학위를 받았고 생의학 텍스트를 다뤘어요. 그 뒤로는 빅 파마에서 3년간 일했는데, J&J에서도 일했죠. 기계 학습 모델을 어떻게 적용해야 하는지, 그리고 어떻게 적용하면 안 되는지에 대한 사례가 정말 많습니다. 그래서요. 그리고 저는 늘 오픈 소스에서 일하는 게 가장 좋다고 생각해 왔기 때문에, 일하기 시작하는 데 큰 설득이 필요하진 않았던 것 같아요.

좋네요. 기술적인 세부 사항은 잠시 뒤에 살펴볼 텐데, 먼저 여쭤볼게요. 수익은 어떻게 내시나요? 비즈니스는 어떤 방식으로 운영되나요?

네, 저희는 제품을 판매합니다. 그러니까 우리가 하는 일은 꽤 단순해요. 무언가를 팔고 사람들이 돈을 지불하면, 우리가 버는 돈보다 적게 쓰고, 그러면 이익이 남죠. 농담은 그만하고, Prodigy의 경우에는 그냥 Prodigy를 구매하실 수 있어요. 저희는 Prodigy를 평생 라이선스로 판매하기 때문에 한 번만 결제하시면 됩니다. 소프트웨어 비즈니스의 좋은 점은, 소프트웨어를 한 번 만들어서 팔고, 또다시 팔 수 있다는 거예요.

오픈 소스 모델을 갖고 계시잖아요? 어떤 부분이 오픈 소스이고, 어떤 부분이 유료인가요?

그래서 우리는 이른바 프리미엄 모델이나 오픈 코어 같은 방식을 별로 좋아하지 않았어요. 그런 모델은 질문거리만 잔뜩 만들고, 회사 입장에서도 아주 애매한 위치에 놓이게 하거든요. 우리는 사람들이 우리 도구를 쉽게 쓰길 바랍니다. 문서도 훌륭하길 원하고요. 우리 소프트웨어에 대한 ‘도와주기’를 상품으로 팔고 싶진 않아요. 만약 우리가 spaCy 위에 무언가를 얹어서 파는 컨설팅 모델을 했다면, 늘 이런 딜레마에 빠지게 되죠. “문서가 너무 좋고 라이브러리가 너무 좋으면 아무도 우리에게 돈을 안 준다. 그런데 퀄리티가 형편없으면 아무도 우리 서비스를 원하지 않는다. 어차피 우리 도구를 안 쓸 테니까.” 그래서 그런 방식은 처음부터 원하지 않았어요. 그리고 오픈 소스 라이브러리에는 항상 어려운 이야기가 따르는데, 갑자기 어떤 컴포넌트는 무료가 되어버리면 문제가 복잡해집니다. 그리고 일반적으로, 저는 알고리즘 자체가 팔아야 할 핵심이라고 생각하지 않아요. 진짜 중요한 건 개발자 경험입니다. 그건 기업에 큰 가치를 만들어 주고, 사람들이 기꺼이 돈을 내는 부분이에요. 예를 들어 사람들이 Weights & Biases를 쓰고 비용을 지불하는 큰 이유도 개발자 생산성이죠. 데이터도 마찬가지예요. 데이터를 만드는 일 전반이 진짜 커스터마이제이션이 들어가는 곳이고, 사람들이 가치 있다고 느끼며 시간을 들여 작업하는 부분이에요. 그리고 그런 곳에 제품이 존재할 수 있습니다. 그래서 우리는 별도의 제품을 가지고 있어요. 오픈 소스 도구의 파워 유저라면 아마 흥미를 느낄 만한 것이지만, spaCy와는 분리되어 있습니다. spaCy는 무료이고, 코드는 오픈 소스이며, 우리는 그 위에 추가 제품을 판매합니다.

그리고 그 추가 제품이 Prodigy인가요?

네. 지금은 그게 저희가 보유한 유일한 제품이에요. 하지만 아까 말씀드렸듯이 Prodigy Teams도 개발 중이고, 많은 분들이 기다려 오신 보다 SaaS에 가까운 모델로 선보일 예정입니다.

그렇군요. 그런데 Prodigy는 한 번만 구매해서 쓸 수 있는 소프트웨어인가요?

네. 맞아요. 지금 바로 온라인에 접속해서 스토어에서 구매하고, 다운로드한 뒤에 PIP로 설치해서 사용하실 수 있어요. 그게 저희가 의도한 바이기도 합니다. 개발자가 최대한 쉽게 시작할 수 있도록 경로를 단순화하고, 우리 도구를 쓰기 시작하는 허들을 낮추고 싶었어요. 그러고 나면 그다음에 할 수 있는 일이 훨씬 많아집니다.

그리고 보통 여러분이 판매하는 상대, 그리고 spaCy를 사용하는 사람은 자연어 처리 분야에서 모델을 만들려고 하는 사람들이겠죠. 제가 제대로 이해한 건가요?

아마도 포춘 500 대기업부터 스타트업, 학계와 연구자들까지 다양한 회사의 개발자들이겠죠. 또 요즘에는 전통적인 머신러닝 배경이 없는 사람들이 NLP에 많이 들어오고 있어요. 이를테면 “컴퓨터 과학 박사하고 창업했다” 같은 전형적인 경로가 아니라, 디지털 인문학이나 의료 분야처럼 여러 도메인에서 오는 분들이 많습니다. 이제는 문제를 해결하고자 이 분야에 들어오는 사람들이 정말 많아요. 그리고 저희가 그 점을 특히 흥미롭게 보는 이유는, 그들이 도메인 지식을 가져오고, 해결하고 싶은 문제가 명확하고, 해법에 대한 감도 이미 갖고 있기 때문입니다. 그러고 나서, 좋아요, 머신러닝을 배우는 거죠. 저는 이것이 종종 반대 방향보다 성공으로 가는 더 나은 경로라고 생각해요. 즉, 먼저 머신러닝을 알고 나서 “세상 어느 문제에 이걸 적용할까?”를 고민하는 방식보다요. 이런 접근, 특히 너무 순진하거나 오만한 관점에서 출발한 경우에 끔찍한 제품들이 많이 탄생했다고 봅니다.

그러면 여러분의 라이브러리인 spaCy에 대해 이야기해 볼게요. 새로운 기능들에 앞서, 아직 여러분의 라이브러리를 자세히 접해 보지 못한 분들을 위해, 핵심 구성 요소가 무엇인지, 그리고 어떤 문제를 해결하도록 설계되었는지부터 설명해 주실 수 있을까요?

처음에는 대규모 텍스트를 효율적으로 대량 처리하기 위해 개발됐어요. 예를 들어 인터넷 전체를 처리하고 싶다면, 인터넷이 더 작아지지 않을 거고 컴퓨터가 마법처럼 끝없이 빨라지지도 않잖아요. 그러니 그 일을 해낼 수 있는 효율적인 소프트웨어가 필요하죠. 그리고 시작 단계부터… 또, 물론 항상 프로덕션과 산업 현장에서의 사용을 염두에 두고 설계되었습니다. 우리가 시작하던 당시에는 이런 고려가 그다지 일반적이지 않았어요. 대부분의 코드는 연구 목적에 맞춰 작성되니까요. 그래서 spaCy는 정반대의 접근을 택했죠. “좋아, 텍스트를 처리해서 이것저것 하고 싶지? 우리가 보기엔 가장 좋은 하나의 구현을 줄게. 벤치마크용으로 50개의 파서를 주고 놀아 보라기보다, 가장 잘 작동하는 하나를 드릴게.”라고요. 그게 출발이었습니다. 처음에는 언어에 대해 분석할 수 있는 여러 측면별로 서로 다른 컴포넌트를 제공했어요. 가장 기초적으로 ‘단어가 무엇인가?’ 같은 문제에서 시작해요. 겉으로는 아주 단순해 보이지만 실제로는 훨씬 복잡하죠. 거기서부터 텍스트에 어떤 개념들이 언급되는지, 이 텍스트는 무엇에 관한 것인지, 동사는 무엇이고 명사는 무엇인지, 요소들이 어떻게 연결되는지 등을 다룹니다. 그리고 그 위에 더 많은 것들을 구축할 수 있어요.

현재 공개된 spaCy 버전 2의 주요 기능 중 하나는 다양한 언어에 대한 사전 학습 모델이 매우 많다는 점이라고 생각해요. 그래서 사용자들이 와서 “프랑스어 텍스트를 구문 분석해서 레이블이 무엇인지, 품사 태그가 무엇인지, 텍스트에 나오는 엔티티가 어떤 것인지—예를 들어 사람 같은 엔티티—이런 것들을 알려주는 범용 파서가 필요해요”라고 말할 수 있죠. 하지만 지난 몇 년간 우리가 본 흐름은, 점점 더 많은 사람들이 자신만의 모델을 직접 학습하고 싶어 한다는 거예요. 그러니까 프랑스어 모델이 하나만 있으면 충분하지 않다는 거죠. 텍스트의 유형이 매우 다를 수 있으니까요. 예를 들어 생의학 텍스트는 일반 도메인의 영어 뉴스나 프랑스어 뉴스와는 전혀 다른 파서를 필요로 하게 됩니다. 그래서 버전 3로의 전환도 그 연장선에 있어요. 우리가 모든 것을 훨씬 더 구성 가능하게 만들어서, 사람들이 직접 자신의 모델을 학습할 수 있도록 하는 거죠. 온라인에 올려둘 사전 학습 모델들로 빠르게 시작할 수는 있지만, 거기에만 한정되지 않고 각자 모델을 훨씬 더 강력하게 학습시킬 수 있게 되는 겁니다. ��난 몇 년간 사람들이 NLP를 다루는 방식이 이렇게 바뀌어 왔다는 점을 반영한다고 봅니다.

언어 처리의 큰 변화들을 가장 가까이에서 지켜보신 것 같아요. 제 입장에서는 많은 애플리케이션에서 구문 분석 단계를 아예 건너뛰는 경우도 있는 듯한데, 실제로 그런가요? 어느 정도나 사실인가요?

모든 사용자가 정확히 무엇을 하고 있는지 말하기는 어렵지만, 이런 흐름이 분명히 spaCy 버전 3로의 전환에도 영감을 주었습니다. HuggingFace에서 공개되는 트랜스포머, 즉 NLP에 매우 유용한 방대한 모델 저장소가 spaCy transformers 라이브러리를 통해 spaCy 3 안에서 기본적으로 사용할 수 있게 될 거예요. 그래서 파이프라인에 트랜스포머를 꽂아 넣듯이 간단히 추가해 바로 사용할 수 있습니다. 그리고 그 시점에서 더 이상 특정 파서 모델이 필요 없다고 느낀다면, 물론 그렇게 시도해 볼 수도 있죠. 트랜스포머 출력 위에 여러분만의 모델을 얹어 작성해 보고 성능이 어떤지 바로 확인할 수 있게 될 겁니다.

맞아요. 그런데 그 주제와 관련해서 또 하나 덧붙이고 싶은 점은, 연구 쪽에서는 특히 요즘 정말 흥미롭고 실제로 잘 작동하는 엔드 투 엔드 예측 기법들이 많아졌다는 거예요. 아주 복잡한 과제를 하나의 모델로 끝까지 예측해 내고, 중간에 여러 컴포넌트를 거쳐 이어 붙일 필요가 없는 방식이죠. 그건 정말 흥미진진합니다. 사람들이 그런 접근을 택하기도 하지만, 실제 현업 애플리케이션에서는 여전히 서로 다른 컴포넌트를 조합해 쓰는 게 아주, 아주 유용하다는 것도 많이 봤어요. 특정한 데이터로 각 컴포넌트를 학습할 수 있고, 조정하고 재학습하고 커스터마이즈할 수 있으니까요. 산업 현장과 현실 세계에서 사람들이 풀고자 하는 과제는, 말하자면, 거대한 언어 모델 하나를 던져서 엔드 투 엔드로 쉽게 예측하고 끝낼 수 있는 종류가 아닌 경우가 많기 때문이죠. 만약 그게 가능했다면 애초에 그런 문제들이 큰 가치가 없었을 거고, 기업들도 거기에 많은 돈을 쓰지 않았을 겁니다. 우리가 만들고 싶은 것들 중 가장 흥미롭고 가장 가치 있는 것들은 대개 매우 구체적이에요. 그래서 이런 문제들에는 보통 결합해서 학습할 수 있는 다양한 빌딩 블록이 필요하고, 앞으로도 그런 작업을 더 쉽게 할 수 있도록 만들고 싶습니다.

기업들이 중요하게 생각하지만 학계에서는 상대적으로 덜 연구된 주제들이라면, 그런 사례들을 몇 가지 들어 주실 수 있을까요?

학계에서 연구되지 않았다고까지 말하고 싶진 않아요. 더 정확히 말하면… 그러니까 사람들이 늘 하고 싶어 하는 일 중 하나가 정보 추출이죠. 기업들은 텍스트를 아주 많이 쌓아 왔고, 이제 그 텍스트에서 뭔가를 알아내고 싶어 합니다. 제가 발표에서 가끔 드는 예시로, 스크레이핑한 금융 뉴스가 잔뜩 있고, 거기서 기업 매출을 추출하고, 누가 어느 회사를 얼마에 샀는지, 어느 나라에서 어떤 통화로 거래됐는지 같은 걸 뽑아내고 싶다고 해 봅시다. 이 영역의 작업은 끝이 없고, 실제로 많은 회사들이 그걸 원합니다. 물론 거대한 언어 모델이 있다면 프롬프트를 던져 모델을 조정하는 여러 방법을 시도할 수 있고, 마지막에는 모든 데이터를 담은 구조화된 JSON을 뱉어내게 할 수도 있겠죠. 하지만 대개 그런 방식이 이 문제를 푸는 가장 효율적인 길은 아닙니다. 보통은 “좋아, 우선 회사명을 탐지하자”라고 시작하죠. 그 목적이라면 엔터티 인식기를 학습시켜 GitHub을 회사로, Microsoft를 회사로 예측하게 만들 수 있습니다. 금액도 비슷하게 꽤 잘 됩니다. 다만 실제 환경에는 잡음이 아주 많아요. 먼저 분류를 해서, 애초에 관심 대상인 텍스트인지부터 거르려 할 겁니다. 그리고 무작위로 등장하는 금액 값을 정규화하고 싶겠죠. 여기에 꼭 머신러닝이 필요할까요? 아마 아닐 겁니다. 간단한 알고리즘으로 충분하고, 그걸 다른 것들과 조합하면 됩니다. 다음으로 주식 티커를 조회하고 싶은데, 이건 예측할 문제가 아니죠. 시퀀스 투 시퀀스나 언어 모델링으로 풀고 싶지 않을 겁니다. 그건 데이터베이스나 인터넷에서 조회해서 가져오고, 그렇게 얻은 결과를 모두 합쳐 구조화된 형식으로 만들어 데이터베이스에 넣으면 됩니다. 이게 아주 좋은 예라고 봐요. 정말 흔한 작업입니다. 이걸 엔드 투 엔드로 예측하는 건 연구 주제로는 무척 흥미롭지만 실용적 접근은 아닙니다. 여러 다른 컴포넌트가 필요하고, 그 중엔 일부를 정규식으로 대충 묶어 99% 정확도로 처리해도 충분히 훌륭한 경우가 있어요. 그 이상 무엇을 더 바라겠습니까? 실제로 우리가 보는 많은 NLP는 이렇게 진행됩니다.

네, 제가 경험한 NLP와도 일치하네요. 그래서 전적으로 공감합니다. 그렇다면 그런 작업에서 spaCy가 도와주는 부분은 무엇인가요? 아니면, 연구 중심의 NLP 라이브러리와 비교했을 때 spaCy가 다르게 선택한 결정들은 무엇인지 궁금합니다.

음, 저는 ‘의견이 분명한 접근’이라고 말하고 싶어요. 예를 들면, 하나의… 버전 3에서는 사람들을 좀 더 자유롭게 두는 방향으로 그 입장을 조금씩 완화하고 있어요—

맞아요. Hugging Face처럼 선택지가 아주 많잖아요. 그래서 두 목표 사이의 긴장을 어떻게 조율하시는지 궁금했어요.

맞아요. 그러니까, 전반적으로는 사람들이 가장 잘 작동하는 합리적인 기본값을 쓰도록 하고 싶어요. 그게 좋다고 생각하니까요. 예를 들어, 트랜스폼 통합과 관련해서도 저희가 계속 실험을 돌려 왔고, 실제로 어떤 모델이 특히 잘 작동하는지 살펴봤어요. 그래서 그 부분에 대한 가이던스도 드릴 수 있죠. “효율이 중요하고 그 언어를 쓰고 싶다면, 아마 이 사전 학습 가중치를 쓰는 게 좋습니다” 같은 식으로요. 그런데 더 일반적으로 말하면, 저희는 처음부터 다소 의견이 분명했고, 효율성에 집중해 왔어요. 이건… “당신 연구 결과물이 느리다”고 해서 연구자의 잘못이 아니라는 거죠. 애초에 그게 역할이 아니니까요. 연구의 역할은 벤치마크를 만들어서 알고리즘을 비교할 수 있게 해주는 거예요. 그건 타당하죠. 연구가 가진 문제 설정이 그런 겁니다. 다만 실제로 이런 것들을 쓰고 싶다면, 일을 효율적으로 끝낼 수 있도록 선택을 해야 하고, 그런 모델링 선택을 해야 한다는 거예요. 그러니까…

아, 그렇군요. 그러면 효율적으로 돌아가는 모델을 고르는 것까지 포함되는 거네요.

아키텍처, 예를 들어 파이프라인을 어떻게 구성할지 같은 부분이죠. 많은 모델은 각 작업마다 임베딩을 따로 두는데, 그렇게 하면 어떤 컴포넌트에는 작동할 수 있어도 모델이 꽤 커집니다. 매번 많은 것을 다시 계산하게 되기도 하고요. 그래서 여러 컴포넌트가 일부 자원을 쉽게 공유할 수 있게 하려면 어떻게 해야 할지 고민하고 있어요. 표현을 한 번만 계산해 둘 때 무엇을 공유할 수 있을지 같은 것들이죠. 이런 것들은 우리가 반드시 고민해야 하는 선택들인데, 연구자 입장에선 그다지 중요하지 않을 수도 있어요.

현업에서는 학계보다 더 신경 쓰는 부분이 하나 있는 것 같아요. 학계에서도 다국어 지원을 자주 이야기하긴 하지만, 결국 많은 논문이 영어 코퍼스를 기반으로 쓰이잖아요. 물론 그럴 만한 이유가 있겠지만, 대기업 대부분에게는 다국어 지원이 최우선 과제처럼 보입니다. 여러 언어의 텍스트를 다뤄야 하니까요. 이 부분에 대해 많이 고민해 보셨나요?

맞아요. 미안해요. 잠깐 소피가 답할 줄 알았거든요. 알겠습니다. 네, 물론이죠. 그리고 어떤 언어를 지원한다는 건 그 언어에 대해 대충 사용 가능한 코퍼스로 모델을 한 번 돌리는 것 이상인 경우가 많아요. 예를 들어, 저희가 쓰는 건 기본적으로 자동화된 조직화 알고리즘이긴 하지만, 실제 업무에 쓰이는 산출물을 만들고, 언어학적으로 동기화된 조직화를 지향합니다. 그러면 자연스럽게 “그 언어를 어떻게 다룰 것인가?”, “그 언어에는 어떤 문자 체계가 있는가?”, “그 언어는 보통 어떤 방식으로 작동하는가?” 같은 많은 고려사항이 따라오죠. 이어서 “실제로 쓸모 있는 학습 데이터는 무엇인가?”라는 문제로 이어집니다. 이 부분은 연구와 산업 현장에서 반드시 같지 않기도 하고요. 그런데 네, 물론 다양한 이유가 있고, 연구에서 영어 위주가 되는 것도 이해가 됩니다. 경쟁이 벌어지는 장이 거기다 보니 개별 연구자가 영어 코퍼스로 평가하고 실험을 돌린다고 해서 비난할 수는 없어요. 어쩔 수 없는 부분이죠. 하지만 현실 세계의 시나리오에서는 이야기가 좀 다르죠.

바이오인포매틱스는 영어를 쓰더라도 완전히 다른 도메인이라 중간 지점에 있는 것 같아요. 그 분야에서 일한다면 다른 모델을 쓰라고 권하시나요? 사람들은 그 부분을 어떻게 판단해야 할까요?

네, 맞아요. 확실히 다른 모델이 필요합니다. 생물의학 텍스트에서는 문법도 다르고 쓰이는 엔터티와 어휘 자체가 크게 달라요. 그런 식의 도메인이 꽤 많다고 봅니다. 예를 들어 금융이나 바이오메디컬 같은 분야요. 전부 매우 다른 도메인이라 해당 도메인에 맞춰 모델을 학습시키는 게 정말 중요합니다. 그리고 저희가 보아 온 건 언어 차원에서만이 아니라 커뮤니티의 큰 지원이 있었다는 점이에요. 예를 들면, 제가 기억하기로는 이네스, 일본어 모델의 경우에도 커뮤니티에서 많은—

아, 맞아요. 중국어도요. 그래요, 맞아요.

일본어와 중국어 지원도요. 커뮤니티의 큰 도움이 있었어요. 언어학적으로 견고하게 만들려고 하면, 열 명도 안 되는 인원으로 그렇게 다양한 언어를 모두 지원하기가 당연히 어렵거든요. 그리고 바이오메디컬 도메인에 대해서는, 사실 플러그인도 있어요. 저희가 spaCy Universe라고 부르는 플러그인 목록이 있는데, 사람들이 spaCy에 연결되는 각종 패키지를 만들어서 올리고, 그 안에는 바이오메디컬 도메인에 특화된 모델을 학습해 둔 것들도 있어요. 그런 종류의 텍스트를 처리한다면, 그걸 바로 가져다 쓰거나 최소한 거기서부터 시작할 수 있죠. 그래서 저는 spaCy가 꽤 괜찮다고 생각하고, 그 주변에 큰 커뮤니티가 형성되어 있다는 점도 좋다고 봅니다.

그러니까 방금 말씀하신 1단계가 바로 sciSpaCy라고 부르는 겁니다.

sciSpaCy

그건 Allen AI의 Mark가 개발한 거예요. 그리고 법률 도메인에 대해 같은 일을 하는 Blackstone이라는 프로젝트도 있어요. 두 프로젝트 모두 훌륭한 예라고 생각하는데, 구현된 컴포넌트를 보면 그 컴포넌트가 무엇을 해야 하고 해당 도메인에 무엇이 적절한지에 대해 많은 고민이 담겨 있다는 걸 알 수 있거든요. 예를 들어, 법률 문서를 문장 단위로 제대로 분할하려면 무엇을 다르게 해야 할까 같은 질문이죠. 이걸 잘하려면 법률 문서와 그 문서들이 어떻게 작성되는지 이해해야 해요. 어떤 문제가 있는지 파악하고요. 좋아요, 그러면 이렇게 해볼 수도 있겠네요… 예컨대 법원 판결문에서는 두문자어를 풀어 쓰는 컴포넌트가 필요할 수 있어요. 특정 알고리즘을 쓰는 컴포넌트가 있는데, 꽤 기본적이긴 하지만 spaCy로 구현할 수 있고 그냥 잘 돌아갑니다. 즉, 기존에 있는 걸 확장하는 작업인 셈이죠. 하지만 그런 프로젝트들을 보면, 특정 모델을 만드는 데 그 분야에 대한 지식과 통찰이 정말 많이 들어갔다는 게 확 느껴져서 아주 흥미로워요. 네, 그래서 또다시 망치와 못 비유로 돌아오게 되는 것 같네요.

아까 그 얘기를 하셨으니까 좀 더 깊게 들어가 보고 싶어요. 우리가 새로 나온 spaCy 라이브러리에 대해 이야기하면서, 거기서 할 수 있는 것들을 보여 주셨잖아요. 여러 컴포넌트에 정말 많은 고민이 들어간 것처럼 보였어요. 제가 특히 공감한 부분이, 이 문제로 씨름해 본 입장에서 봤을 때 구성 시스템이 정말 멋지더라고요. 중첩된 config 구조도 그렇고, 그 안에 실제 로직을 넣을 수 있는 방식도 그렇고요. 그 부분에 대해 조금 더 이야기해 주실 수 있을까요? 이 문제를 직접 겪어 보지 않은 사람들은 구성 설정을 제대로 갖추는 일이 얼마나 복잡한지 잘 체감하지 못할 것 같거든요.

네, 저도 동의해요. 개인적으로는 이번에 나올 새 릴리스의 가장 큰 강점 중 하나라고 생각해요. spaCy 버전 3에는 이런 구성 파일이 꼭 필요해요. 그전에는 라이브러리 전반에 기본값이 흩어져 있어서, 그걸 제대로 찾아 바꾸기가 어려웠거든요. 그런데 이제는 이 구성 시스템을 통해 NLP 파이프라인의 서로 다른 컴포넌트를 전부 명시적으로 정의할 수 있어서, 무엇이 들어 있고 무엇이 아닌지 정확히 알 수 있고, 각 컴포넌트의 다양한 파라미터를 세밀하게 튜닝할 수 있게 됐어요. 그리고 이 구성 시스템의 백엔드 쪽은 Ines가 가장 많이 작업한 걸로 알아요. 기본값 자동 채우기나 검증 같은 것들을 포함해, 제대로 동작하게 만드는 일을요. 그리고 저희도 한동안 이 문제로 꽤 씨름했는데, 지금은 정말 견고해졌다고 느껴요. 며칠 전에도 제가 config를 작성하다가, 예를 들어 False를 맨 앞글자만 대문자로 쓴다든지 그런 실수를 했더니 시스템이 자동으로 “이건 맞지 않아요. 문자열을 뜻하셨나요? 이것은 불리언인가요? 무엇을 원하시나요?” 하고 바로 알려 주더라고요. 그러면 즉시 실패하도록 되어 있어요. 개인적으로는 이런 점이 작업할 때 꽤 재미있다고 생각해요. 실험을 아주 초기에, 아주 쉽게 걸러 주거든요. 이 설정이 유효한 구성인지 아닌지에 대한 피드백을 바로 받아서, 계속 진행할 수 있는지 판단할 수 있으니까요.

버그는 어차피 생길 수밖에 없고, 일이 틀어질 수도 있다는 사실을 그냥 받아들여야 한다고 생각해요. 특히 ���신러닝은 정말 어렵고 복잡하죠. 기본적으로 수백 차원의 초추상적인 배열 같은 것들을 함수에서 함수로 넘기면서 연산을 해요. 그걸 또 계속 뒤로 전달하다 보면 언젠가 뭔가가 결과로 나오길 바라는 거고요. 이건 그냥 본질적으로 복잡한 작업이에요. 아마 이걸 듣는 분들 대부분이 공감할 텐데, 디버깅하다 보면 브로드캐스트가 안 된다느니, 텐서의 모양이 안 맞는다느니 하는 문제에 계속 부딪히죠. 그러다 보면 “젠장, 어딘가에 버그가 있구나” 싶은 순간이 오고, 이런 일은 정말 자주 벌어져요. 예를 들면 여기서는 hidden width를 뭐라고 설정해 놨는데, 왜 내 모델은 학습이 안 되지? 왜 다 망가질까? 같은 상황이요. 그럴 땐 저쪽에서도 같은 width를 설정해 줘야 하는데, 안 했던 거죠. 키워드 인자의 기본값이 −1로 되어 있어서 그대로 쓰였을 수도 있고요. 이런 일은 계속 반복돼요. 그래서 우리는 “아, 이거 진짜 별로다”라는 생각을 했죠. 실수도 생기고 문제도 생길 거예요. 게다가 시스템이 덜 복잡해지지도 않을 거고요. 그리고 복잡성을 추상화로 싸서 가려 버린다고 해서 문제가 해결되는 것도 아니에요. 또 하나, 구성 파일을 보면 모든 파라미터가 전부 정의돼 있어서 “와, 엄청 복잡하네. 이게 어떻게 쉬운 거지?”라는 생각이 들 수도 있죠. 하지만 쉬움이 항상 “설정 없이 바로 된다”는 뜻은 아니에요. 중요한 건 문제를 제대로 해결하는 거예요. 그리고 그건 복잡성을 가려 버리는 게 아니라, 더 나은 개발자 경험을 제공함으로써 할 수 있는 일이기도 하죠.

맞아요, 완전히 동의해요. 그리고 저는… 아, 먼저 하세요.

맞아요. 그냥 한마디 덧붙이자면, 우리가 이 구성들을 언제부터 적용하기 시작했는지 정확하진 않지만 아마 1월쯤이었던 것 같아요. 그러니까 우리도 벌써 반년 넘게 직접 써 온 셈이죠. 그동안 문제들이 무엇인지, 그리고 겉으로 드러나지 않는 부분들까지 다 보게 됐어요. 예를 들면, 이쪽 구성의 어떤 파라미터는 저쪽에 중첩된 파라미터와 동일해야 한다든가 하는 것들이요. 그래서 그런 걸 해결하려고 참조 메커니즘 같은 걸 다양하게 넣었고요. 이제는 어느 정도 실전 검증이 되어 있어서, 흔한 오류들은 예전만큼 잘 안 튀어나오지 않을까 싶어요. 네, 전반적으로 꽤 기분이 좋아요.

맞아요. 늘 참 뿌듯하죠. 뭔가를 만들고 실제로 써 보니까, 오, 진짜 잘 돌아가네 싶은 순간이 와요. 뭐, 안 그럴 거라 생각한 건 아니지만요. Weights & Biases를 쓰기 시작했을 때도 비슷한 경험을 했어요. “그럼 이 구성 전체를 그냥 로깅해 보자”라고 했다가, “와, 이제 이 모든 값들이 서로 어떻게 연관되는지 실제로 보이네”라고 감탄했죠. 그냥 제대로 작동하고, 말이 되는 거예요. 그게 정말 만족스러웠어요.

재밌네요. 타입 관련해서 말씀하신 내용이나 아까 빠르게 실행되도록 하고 싶다고 하신 걸 듣고 보니, 전반적으로 Python에 대해 어떻게 생각하시는지 궁금해졌어요. 실제로 저희가 이야기 나눠 본 여러 ML 연구자들마다 의견이 꽤 강하게 갈리더라고요. 그래서 유명한 Python 라이브러리의 저자로서는 어떻게 보시는지 특히 궁금합니다. 이 언어에 대해 어떻게 생각하세요?

그러니까, 제 말은… Python이 뭐라고 부르든 간에 머신러닝 분야에서 승기를 잡은 건 사실이죠. 그리고 그건 분명, Python이 적절한 시기에 적절한 자리에 있었기 때문이라고 생각해요. 충분히 빨랐고, C 확장도 지원했고, 동시에 범용 언어였죠. 이건 제가 늘 강조하고 싶은 부분이에요. Python이 인기 있고, 우리가 하는 일 같은 데에도 잘 맞는 이유는 Python으로 온갖 일을 다 할 수 있기 때문이에요. 대규모로 머신러닝이 뜨기 전에도 Python은 웹 개발 쪽에서 이미 크게 쓰였거든요. 그 말은 곧, 다른 일을 하다가도 배워서 진입할 수 있는 범용 언어라는 뜻이죠. 그래서 ‘AI 전용 언어’ 같은 건 사실상 제대로 떠오른 적이 없어요. 잘 안 맞거든요. 우리는 그걸 작성하는 데 범용 언어를 원해요. 그래서 Python이 그렇게 인기 있는 거고, 저도 그래서 Python을 좋아해요. 물론, 빠르게 만들기 위해서는 손을 좀 봐야 하죠. 실제로 spaCy는 Syphon으로 작성되어 있어요. Python 문법으로 C를 쓸 수 있게 해 주는, Python의 방언 같은 거죠. spaCy 하면 “오, Syphon”으로 꽤 알려져 있고요. 왜인지 Matt도 “오, Syphon으로 구현한다”로 알려진 면이 있어서, 아직도 약간 위압적으로 느끼는 분들이 있긴 해요. 그런데 글쎄요, 소피, 당신은 Syphon을 배웠잖아요. 해 보니까 어땠나요? 글쎄요, 해 보니 어땠나요? 소피, 당신이 Syphon을 배웠으니까요.

있어 보이는 것보다 더 무섭게 말하는 것 같아요, 이네스.

아, 정말요.

왜냐하면 spaCy 전체가 당연히 Cython으로 구현된 건 아니고, 성능 면에서 정말 중요한 부분들만 그렇게 되어 있으니까요. 그래서… 이건 굉장히 흥미로운 질문이라고 생각해요. 제 경우에는 자바 배경에서 왔거든요. 물론 꽤 다르죠. 개인적으로는 Python과 타입 시스템의 조합이 아주 마음에 들어요. 두 세계의 장점을 조금씩 얻을 수 있으니까요. 솔직히 말해 Python은 자바보다 훨씬 손쉽게 프로그램을 작성할 수 있고, 오버헤드도 훨씬 적잖아요. 점점 더 좋아지더라고요. 그리고 타입에 대해서도 정말 좋아합니다. 특히 직접 머신러닝 모델을 작성할 때, 혹은 우리 오픈 소스 머신러닝 라이브러리들에 타입이 다 통합되어 있어서, 호환되지 않는 입력·출력 타입의 레이어를 조합하려고 하면 바로 알려주거든요. 잘못된 차원을 가진 의미 없는 배열을 그냥 전파시키다가 중간 어딘가에서 터지게 놔두지 않고, 미리 알려줘요. 그게 정말 큰 도움이 되고, 그 지점에서 타입 시스템이 제대로 작동한다고 생각합니다.

맞아요. 생태계에서 흥미로운 일들이 정말 많이 벌어지고 있다고 생각해요. 아직 꽤 젊은 편이죠. 정적 타입 체크나 mypy 같은 것도 Python 자체와 마찬가지로 아주 활발하게 개발되고 있고요. 그런데 이런 것들이 실제로 잘 작동하는 걸 보는 게 정말 멋져요. 요즘 에디터를 쓰다 보면 밑줄이 딱 그어지고, “아, 이 함수에 잘못된 값을 넘겼구나” 하고 바로 깨닫게 되죠. 문자열을 넘겼는데 사실 리스트여야 했고, 문자열도 이터러블이라서 그런 실수를 찾는 데 한참 걸릴 수도 있었잖아요. 그런데 그런 걸 바로 잡아 주니까요.

아, 네.

누구나 공감할 수 있는 그런 종류의 버그들이죠, 그게 꽤 멋진 점이라고 생각해요. 그리고 그 시스템에 연결하고, mypy 같은 정적 타입 체크를 통해서 자신의 라이브러리와 사용 사례에 맞는 플러그인을 직접 구현할 수 있다는 점도요. 이 생태계가 성숙해지면서 앞으로 몇 년 사이에 이런 흐름을 훨씬 더 많이 보게 될 거라고 생각합니다. 맞아요.

다른 언어에 대한 수요도 보이나요?

프로그래밍 언어에서나 사용 시처럼—

네, 사람들이 “자바도 지원해 줄 수 있나요?” 하고 묻는 경우가 있나요?

음, 그러니까 여전히 Python 라이브러리이긴 해요. 다만 R로 작성된 아주 인기 있는 래퍼가 있고, R도 여전히 매우 인기 있는 언어죠. 굳이 말하자면, 저희가 활동하는 영역에서 사람들이 주로 쓰는 또 다른 주요 언어가 R이라고 할 수 있을 것 같아요. 물론 이건 편향일 수도 있어요. Java로 일하는 분들이 뭘 하는지 저는 잘 모를 수밖에 없거든요. 그분들은 분명 Python을 쓰지 않으니까요. 그러니까, “Java로 일하는 사람들 얘기는 전혀 못 들어요.”라고 하면, “네, 그분들은 우리의 도구를 안 쓰니까요.”가 되는 거죠. 그건 그럴 수 있고, 괜찮습니다. 하지만 R과 Python이 꽤 잘 통합된다는 점도 있어요. 사실상 얇은 래퍼 레이어만 있으면 되고, 디지털 인문학이나 사회과학 쪽에서 일하시는 분들과도 잘 맞아요. 실제로 그 분야는 R 중심인 경우가 많지만, 분석해야 할 텍스트가 정말 많거든요. 그래서 R을 통해 spaCy를 자주 사용합니다. 맞아요.

알겠습니다. 혹시 다른 점도 있을까요? 그러니까, 여러분의 라이브러리와 설정 시스템을 떠올리면 재현 가능성을 위한 노력이 떠오르거든요. 특히 다양한 분들과 일하시다 보면, 학계는 물론이고 산업 현장에서도 결과를 재현 가능하게 만드는 게 정말 중요하다고 생각해요. 그 부분을 더 명확하고 재현 가능하게 만들기 위해 추가로 하고 계신 일이 있을까요?

맞아요. 그리고 그게 바로 설정을 지금처럼 두는 가장 큰 이유 중 하나라고 생각해요. 기본적으로 모든 것을 거기에 정의해 두고, 난수 생성기의 시드도 설정할 수 있어서, 기계 학습 모델을 포함해 거의 동일한 방식으로 결과를 재현할 수 있게 하려는 거죠. 그 부분은 저희가 정말 중요하게 생각하는 지점이기도 합니다. 네.

그리고 물론 또 다른 중요한 부분은, 우리가 학습하는 게 모델만이 아니라는 점이에요. 항상 여러 구성 요소가 함께 움직이죠. 내려받아 로드해야 하는 데이터가 있고, 전처리를 위한 별도의 스크립트가 필요할 때도 있고요. 그래서 spaCy 3의 또 다른 기능이 바로 우리가 spaCy 프로젝트 또는 프로젝트 템플릿이라고 부르는 것입니다. 보다 엔드투엔드 워크플로로 작업할 수 있게 해 주는 CLI 인터페이스예요. 왜냐하면 보통은 명령 하나만 돌리는 게 아니라, 전처리를 하고, 무언가를 내려받고, 그다음에 학습하고, 또 평가를 하잖아요. 어떤 때는 데이터가 바뀌었거나 다른 무언가가 바뀌었거나 결과가 달라졌을 때에만 학습을 다시 돌리고 싶을 수도 있어요. 이렇게 상호 의존성이 많고, 내부적으로도 이런 걸 빠르게 처리하는 게 꽤 어렵다고 느꼈죠. 그래서 이런 아이디어가 나왔습니다. 파이프라인이나 Travis 같은 걸 설정해 본 적이 있다면 CI 설정과 비슷하다고 생각하시면 돼요. 설정해 본 적이 없다면, 음, CI랑 씨름할 일이 없어서 운이 좋으신 거죠. 저는 이런 것들을 너무 많이 알고 있는 타입이라서요, 하하. 어떤 시스템이든 기본적으로 일련의 단계를 정의합니다. 그걸 파일로 적어둘 수 있고요. 필요한 데이터나 가중치 등을 내려받게 할 수 있어요. 그런 다음 그걸 GitHub 리포지토리에 올릴 수도 있죠. 우리가 복제해서 쓸 수 있는 템플릿을 많이 제공할 거라, 시작하기도 아주 쉬워집니다. 벤치마크처럼 기본적인 작업도 마찬가지예요. 지금도 우리가 만든 것들을 모두 테스트해야 하니까 벤치마크를 돌리고 있고, 숫자 없이 출시하고 싶지는 않거든요. 이렇게 하면 아주 좋아요. 단계가 정의되어 있고, 사용할 데이터가 정의되어 있고, 로드되고, 처리 스크립트도 정해져 있어요. 랜덤 시드까지 모두 설정하니, 누구든 그걸 실행하면 재현이 가능하죠. 그래서 “좋아요, 이 벤치마크를 돌려보고 싶어요.”라고 하면, spaCy project clone으로 벤치마크 템플릿을 받아서, 자산을 준비하고, 이름 붙인 워크플로를 실행하면 그냥 돌아갑니다. 그리고 특정 단계를 다시 실행하고 싶으면, 실제로 무언가가 바뀐 경우에만 그 단계가 다시 실행돼요. 이런 시스템은 다른 라이브러리와 통합하기도 매우 쉽습니다. 예를 들어 Weights & Biases와 아주 구체적으로 연동하려는 스크립트를 만들어서, 설정과 연결해 쓸 수 있죠. 또 한 프로젝트에서는 FastAPI를 사용해 모델을 서빙하는 단계를 쉽게 넣는 방법을 보여줍니다. 아마 가장 인기 있는 도구 중 하나일 거예요. 개발자가 우리 팀에 있기도 하고요. 그래서 사람들이 FastAPI에서 spaCy를 늘 사용해 왔고, 통합에 대해 자주 물어보셨어요. 우리는 “그냥 됩니다.”라고 답하곤 했죠. 실제로 그 예시를 보면 알 수 있을 거예요. “이게 통합이긴 한가요? 그냥 작동하니까요.” Streamlit 시각화도 꽤 멋져요. 단계를 돌려서 학습하고, 산출물과 아티팩트를 얻은 다음, visualize를 실행하면 앱이 바로 떠요. 게다가 수많은… 글쎄요, 사람들이 뭘 만들어낼지 저도 다는 모르겠어요. 정말 기대됩니다. 네, 그런 것도 포함돼요.

정말 멋지네요. Prodigy와 데이터에 대해 몇 가지 질문을 드릴 시간을 조금이라도 확보하고 싶어요. 예전에 그쪽 일을 했거든요. 그래서 양질의 학습 데이터를 확보하는 데에도 엄청 열정이 있습니다. Prodigy가 어떻게 작동하는지 조금 설명해 주실 수 있을까요? 그리고 spaCy와는 어떤 특별한 방식으로 통합되나요?

맞아요. 우리가 spaCy를 개발했기 때문에 NLP 기능과 워크플로에 대해 의견도 많고 아이디어도 많았죠. 그래서 spaCy를 사용하는 워크플로가 아주 많이 있습니다. 그런데 이 아이디어의 일부는 우리가 모델을 만들고 이것저것 작업을 하면서, 우리만의 데이터를 만들고 싶다고 생각했을 때 시작됐어요. 그 무렵 우리는 이렇게 깨달았죠. 이제는 엄청나게 큰 데이터가 꼭 필요하지 않다는 것. 수십억 개의 라벨 예시가 없어도 된다는 것. 물론 그렇게 할 수도 있지만, 실제로 필요한 건 자신이 하는 일에 매우, 매우 특화된 데이터인 경우가 많고, 그걸 직접 만들고 많이 만들어야 한다는 겁니다. 회의 열고, 외주 주고, 다시 받아봤더니 “왜 이렇게 형편없지?” 하게 되는 상황을 원치 않잖아요. 당연하죠. 사람한테 “모든 사람(person)을 라벨링해 주세요.”라고만 부탁하고, 정확히 무엇을 원하는지 말해주지 않았다면 그럴 수밖에요. 그런데 왜 놀라시나요? 게다가 시간당 2달러만 주고요. 그런 식으로 데이터 수집 과정을 다루면, 애플리케이션의 핵심이 형편없어지는 건 “놀랍지도 않은” 일이죠. 어쨌든, 우리는 그런 사례를 정말 많이 봤어요. 실제로 회사 초기에 약 6개월 정도 컨설팅을 하기도 했는데, 우리는 그걸 “클라이언트 라운드”를 돌았다고 불러요. 자금을 좀 확보하기도 하고, 사람들이 현장에서 실제로 무엇을 하는지 보려는 목적이었죠. 그런데 어느 프로젝트를 가도 데이터 수집 문제가 빠지지 않았습니다. 그리고 이걸 반복 개선하는 게 매우 어렵다는 것도 드러났어요. 사람들이 스프레드시트로 하곤 했거든요. 그러면 우리가 종종 “이런 라벨 스킴을 시도해 보는 게 어때요?”, “이 부분을 조금 바꿔보면 어떨까요?”, “어쩌면 다른 것을 예측하는 편이 더 유용할지도 몰라요.”라고 제안하곤 했죠. 이 지점은 다시 한 번 “산업 vs. 연구”의 차이로 돌아가게 합니다. 사람들이 자주 잊는 부분이 있어요. 연구가 아니라 산업이라면, 문제를 얼마나 쉽게 만들지 선택할 수 있다는 겁니다. 연구를 한다면 그럴 수 없죠. “저 작업은 별로네, 다른 작업할래.”라고 할 수 없잖아요. 하지만 실제 문제를 해결하는 입장이라면, 문제를 더 쉽게도, 더 어렵게도 만들 수 있습니다. 그리고 그건 대개 시행착오가 필요하고, 여러 가지를 직접 시도해 봐야 하죠. 그런 배경에서 Prodigy가 탄생했습니다. “우리는 개발 도구가 필요하다.”고 생각했거든요. 데이터 라벨링은 개발 프로세스의 일부가 되어야 합니다. 최소한 규모를 키우기 전 초기 단계에서는, 이런 워크플로를 구축해야 하죠. 그리고 그걸 직접 스크립트로 작성하고, 현장에서 돌리고 싶을 겁니다. 모델을 로드하고, 이미 가진 모델이 있다면 모델이 “정답일 가능성이 높은” 후보를 제시하게 해서, 사람이 “네, 아니요, 예, 아니오.” 식으로 빠르게 판단할 수 있게 하죠. 아주 빠릅니다. 혹은 모델이 한 출력을 사람이 바로잡을 수도 있고, 완전히 처음부터 시작할 수도 있어요. 엔티티 라벨링, 텍스트 분류 등등 다양한 작업을 할 수 있습니다. 이게 바로 그 도구를 만들게 된 실제 동기였어요. 실무에서는 이런 식으로 씁니다. 기존 스택과 함께 설치하는 Python 라이브러리고, CLI를 통해 웹 서버를 띄울 수 있어요. 그러면 현대적인 웹 앱 인터페이스가 나오는데, 한 번에 하나의 작업에 집중해 가능한 한 효율적으로 처리하도록 설계되어 있습니다. 데이터를 빠르게 훑거나 라벨링할 수 있죠. 흐름이 잘 타면, 예시 하나당 몇 초 만에도 처리할 수 있어요. 그래서 “한 시간 정도 투자해서 수백 개 주석이 달린 데이터셋을 만들었다.”라고 말하는 게 충분히 현실적입니다. 요즘은 그 정도만 있어도 최소한 가설을 검증하기엔 충분하죠. “이걸 텍스트 분류로 예측해 보면 어떨까?”라는 아이디어가 떠오르면, “이게 과연 먹히나?”라는 의문이 들겠지만, 모르는 일입니다. 직접 해봐야 하죠. 그게 머신러닝이니까요. 저도 모릅니다. 그렇죠.

맞아요. 또 흥미로운 점은 우리가 NLP 개발자를 대상으로 한다는 점인데, 산업 현장에서 spaCy를 쓰는 분들과 이야기해 보면, Prodigy로 스스로 데이터를 조금이라도 직접 주석 달아 보는 게 인상적이라는 거예요. 자신만의 레시피를 스크립트로 짜서 데이터를 조금 주석 달아 보면, 도메인을 더 잘 이해하는 데 도움이 되죠. 그러면 당연히 문제를 더 잘 모델링할 수 있고요. 결국 “데이터를 어떻게 주석 달면 좋을까?”, “내 머신러닝 문제에서 무엇이 합리적일까?”를 빠르게 반복 실험하는 과정인 셈입니다. 그리고 데이터를 그저 외주로 ‘담 넘어’ 던져 놓고, 나중에 머신러닝 전문가가 그걸 해석해 보려 애쓰는 방식보다, 두 세계를 조금씩이라도 직접 아는 편이 훨씬 낫습니다. 그런 식은 잘 작동하지 않거든요. 그래서, 네.

그리고 또 하나의 차이점은, 실제 현장에서, 특히 NLP에서는 모델을 학습시키고 나면 특정 방식으로 데이터를 조금 더 모으고, 다시 모델링을 학습시키는 이런 반복 루프가 계속된다는 점이라고 생각해요. 그런 프로세스를 당신들의 도구는 어떻게 지원하나요? 그 부분에 대해 많이 고민하셨을 거라고 확신합니다.

맞아요. 그러니까 지속적인… 먼저 사람들이 꼭 알아야 할 핵심부터 짚었어요. “모델을 한 번 학습시키고 끝나는 게 아니다. 모델은 절대 끝나지 않는다.” 성능을 계속 개선해 가는 과정을 계획해야 합니다. 그리고 가능하면 어느 시점엔가 모델을 루프 안에 넣어 두는 게 좋아요. “내가 실제로 그럴듯한 결과를 만들고 있나?”를 확인해야 하니까요. 그건 여러 방식으로 할 수 있어요. 예를 들어 모델이 제안안을 보여주게 하고, 사람이 그걸 주석 달고 피드백을 주면서 그 방식으로 모델을 평가할 수도 있죠. 또 우리가 생각했던 워크플로 중 하나는 아주 기본적인 불확실성 샘플링에 집중하는 겁니다. 이를테면 “점수가 0.5에 가장 가까운 텍스트 카테고리를 보자.”처럼 아주 단순한 방법도 있어요. 그건 어느 쪽으로든 갈 수 있다는 뜻이고, 어떻게 고치든 항상 업데이트할 그라디언트가 생기며, 가운데에 있기 때문에 어느 방향으로든 가장 큰 그라디언트를 얻을 수 있죠. 그러니 항상 배울 것이 있고, 그게 또 다른 접근이 됩니다. 그리고 사람들이 이런 실험을 빠르게 띄울 수 있게 하고, 모델을 업데이트할 때마다 온갖 관료적인 절차를 밟지 않아도 되게 하는 것이 중요합니다. 현실에서는 그게 종종 발목을 잡거든요. 개발자는 개발하고 싶어요. 모델을 시작하기 전에 회의를 다섯 번 하고 싶지 않죠. 그냥 코드를 쓰고 싶습니다. 그런 점을 사람들이 확실히 좋아해요. “좋아, 이제 바로 일할 수 있겠네.” 하고요.

그래요.

회의를 잡을 필요가 없어요.

그 말이 맞네요.

그래요.

그래서 저희는 항상 두 가지 개방형 질문으로 마무리하는데, 두 분 모두 답할 기회를 드리고 싶습니다. 첫 번째 질문은 이것입니다. 프로덕션을 포함한 머신러닝 전반을 볼 때, 사람들이 지금보다 더 많이 고민해야 한다고 생각하는 주제가 있을까요?

저는 개인적으로, 그리고 NLP 분야에서 저를 아는 분들은 다 아시겠지만, 아마 정규화나 엔터티 링크잉이라고 생각해요. 제가 spaCy에서 작업했던 모델 중 하나이기도 하고요. 기본적으로, 텍스트가 있고 그 안에서 어떤 항목이 사람인지, 장소인지, 조직인지 등을 이미 주석으로 표시할 수 있다면 그건 좋고 흥미롭습니다. 하지만 거기서 더 나아가 그것이 정확히 무엇인지도 알아야 해요. 가능하면 어딘가의 데이터베이스나 지식 원천에서 고유한 식별자를 부여할 수 있어야 하죠. 제게 이것은 NLP에서 정말로 핵심 단계예요. 왜냐하면 많은 다른 단계들은 텍스트 그 자체에만 기반하지만, 이 단계는 텍스트 기반 분석을 바깥 세계, 즉 외부 지식 베이스와 연결해 주기 때문입니다. 다시 말해 많은 다른 단계들은 텍스트 자체에만 의존합니다. 엔터티 링크잉은 그 텍스트를 외부 세계와 외부 지식 베이스에 연결해 주고, 그걸 통해 데이터베이스의 다른 정보와 텍스트 지식을 통합할 수 있게 해줍니다. 예를 들어 제 BioNLP 배경을 떠올려 보면, 데이터베이스에는 단백질 상호작용 같은 상호작용 정보가 많이 구조화된 형태로 기록되어 있어요. 그런데 또 다른 한편으로는 논문에만 서술된 상호작용들도 있습니다. 두 집합 간의 겹침이 얼마나 적은지 놀라실 거예요. 그래서 두 정보원을 통합하고 결합할 수 있어야 합니다. 그런 의미에서, 엔터티 링크잉 또는 정규화는 매우 어려운 과제이고, spaCy에서도 아직 분명히 완전히 해결하지 못했으며, 일반적으로도 아직 해결되지 않았죠. 그럼에도 저는 이것이 NLP에서 극도로 흥미롭고, 심지어 결정적으로 중요한 단계라고 생각합니다.

네, 그리고 그런 종류의 작업을 더 쉽게 만들고, 사람들이 실제로 해볼 수 있도록 지원하고 싶다는 점도 확실해요. 자, 제 차례인가요? 조금 기본적으로 들릴지 모르지만, 그냥 앉아서 지금 내가 대체 뭘 하고 있는지 제대로 이성적으로 따져 보는 그 생각 자체요. 사람들이 생각을 안 한다는 말이 아니라, 그런 식의 사고가 종종 꽤 신선하게 느껴질 때가 많거든요. 저는 사람들이 일을 지나치게 복잡하게 만들거나, 머신러닝이라는 것 전체에 겁을 먹는 경우를 자주 봤어요. 그래서 “좋아, 너는 뭘 풀려고 하는 거지? 뭘 하려고 하는 거지? 뭐가 말이 되지? 컴퓨터가 할 수 있는 건 뭐고, 할 수 없는 건 뭐지? 뭐가 논리적이지?” 같은 질문을 던져보라는 거예요. 그리고는… 추론하는 게 왜 그렇게 우스운 일인가요?

잘 모르겠어요, 그냥… 너무 좋아요.

음, 분명 충분히 논의되지 않고 있어요.

앉아서 제대로 이성적으로 따져 보기. 우리 모두 그런 걸 더 많이 할 필요가 있다고 생각해요.

훌륭한 슬로건이네요.

NLP에만 국한되지 않아요.

네, 사실 인생 전반에서도요.

좋은 인생 조언이네요, 맞아요.

그냥 이런저런 걸 생각해 보세요. 하지만 저는 이런 부분들이 우리가 일을 하는 방식, 그리고 회사를 운영하는 방식을 정의한다고도 생각해요. 사람들은 종종 데이터를 들여다보면서 말이 안 되는 결론을 억지로 끌어내느라 너무 많은 시간을 쓰곤 하죠. 사실 그냥 앉아서 곰곰이 생각해 보면 훨씬 깔끔하게 해결될 일들이 많아요. 무엇이 말이 되는가? 내가 이걸 해야 할까? 이렇게 묻는 거죠. “데이터를 모아 보니 이걸 해야 한다고 나와요.”라고만 하지 말고요. 그건 정말 여러 의미로 해석될 수 있으니까요. 논리적인가요? 아니면 아닌가요? 아니면, 하지 마세요.

멋지네요.

그리고 그런 지점에 도달하고 나면, 말씀드렸듯이 정말 상쾌하게 느껴질 수 있어요. 갑자기 모든 것이 말이 되기 시작하죠. 갑자기 할 수 있는 일들이 분명해지고, 문제들도 풀 수 있게 돼요. 이상한 기술적 함정에 갇혀 있는 게 아니라, 실제로 무엇을 해야 하는지에 대해 생각하고 있으니까요.

지금 떠올리고 있는 구체적인 사례가 있나요? 우리와 공유하고 싶은 고객과의 상호작용 같은 게 있을까요?

과거에는 “내 시스템이 정확도 90%였으면 좋겠어요”라고 말하는 분들이 있었어요. 그러면 우리는 “무엇에 대해 90%인가요?”라고 묻죠. 그런데도 “아니요, 그냥 90% 정확도요”라고 해요. 사실 시스템으로 무엇을 하느냐가 그 시스템의 성공을 좌우하고, 바로 그것을 측정하고 집중해야 합니다. 이런 관점이 생각에서 빠지면 종종 놓치기 쉬워요. 특히 알고리즘을 비교하는, 목적이 조금 다른 연구만 따라가다 보면 더더욱 그렇죠.

그렇죠. 그러니까… 어떻게 보면, 큰 그림을 생각할 때가 훨씬 명확하게 사고하기 쉬운 것 같아요. 그런데 그걸 하위 문제로 내려가서 “좋아, 여기서는 정확도를 최적화해야지”라고 하면, 개인 입장에서는 정확도만 최적화하려다 쉽게 길을 잃기 마련이죠. 게다가 조직에서는 머릿속에서만 사고 실험을 돌릴 수 없고 실제로 사람들과 대화를 해야 하니까, 오히려 그런 최적화, 마이크로 최적화의 길로 더 쉽게 빠져들고, 거기서 스스로 빠져나오는 건 아주 어렵다고 생각해요.

맞아요. 그리고 사실 그게 재미있는 부분이기도 하죠. 바닥에는 데이터가 있고, 그 위에 코드가 있고, 그 다음에 하이퍼파라미터가 있는 피라미드 같은 구조에서, 사람들은 “오, 하이퍼파라미터 튜닝 빨리 해보고 싶다”라고 하곤 해요.

그렇죠. 그래도 새로운 spaCy 라이브러리는 하이퍼파라미터 튜닝을 꽤 잘 지원하잖아요, 그렇지 않나요?

네, 저희가 그런 기능을 제공하긴 하지만, 동시에 말씀드려야 할 점이 있어요. 사실… 이것도 산업 현장에서 더 안정적으로 쓸 수 있게 최적화한 부분 중 하나인데, 저희가 구현한 모델들에서는 하이퍼파라미터가 그동안 그렇게까지 중요하지 않았습니다. 물론 지금은 트랜스포머처럼 그 부분에 더 민감한 모델들이 생기면서 예전보다 영향이 있긴 해요. 그래도 저희는 예전부터 설계를 할 때, 거기에 너무 의존하지 않도록—즉, 거기에 앉혀둔 아주 취약한 난수에 좌우되지 않도록—하려고 했습니다. “0.01? 그게 안 되는 게 당연하죠. 0.001이어야 했어요.” 같은 식이라면 생산적이지 않잖아요. 그런 건 애초에 없어야 하는 문제라고 봅니다.

제 말은, 그래도 그게 아직도 정말 재미있잖아요, 이네스.

응, 그러니까 그냥…

나는 내 0.001 가지고 노는 걸 정말 좋아해.

맞아요. 그리고 흔히들 하는 얘기들 있잖아요. “드롭���웃은 뭘 쓰죠?” “0.2?” 왜요? “모르겠어요, 되니까요.” 그런데 이런 얘기도 같이 하는 게 좋다고 생각해요. 지금은 외부에서 이 분야를 보는 사람도 많잖아요. 정말로 복잡하고 추상적이며 어려운 부분이 많긴 하지만, 겉보기만큼 깊지 않은 것들도 많거든요. 우리가 모든 답을 아는 건 아니고, 때로는 그냥 숫자를 바꿔 보다가 마음에 드는 결과가 나오면 거기서 멈출 때도 있습니다.

여러분이 클라이언트와 일하면서 쌓은 경험, 그리고 스스로 “이걸 만들고 싶다”에서 시작해 모델을 만들고, 알겠어, 이제 프로덕션에 배포되어 사람이나 프로세스를 실제로 돕는 단계까지 가져가는 경험을 돌아보면, 예상치 못하게 어려워지는 지점은 어디인가요? 사람들은 대체로 하이퍼파라미터 튜닝을 조금 해야 한다고 생각하지만, 방금 말씀하신 걸 들으면 그게 우리가 생각했던 만큼 중요하지 않을 수도 있겠네요. 그리고 실제로 ML 실무자가 매일 하는 일을 들여다보면, 전부가 모델 학습은 아니잖아요, 그래서—

데이터 정제.

... 또 뭐가 있을까요? 그러니까, 여러분이 보시기에 어떤 문제가 있었나요?

데이터 정제, OCR 같은 것들이요. 네, 모든 게 실제 평문 텍스트로 깔끔하게 있으면 좋겠지만, 실제로는 10년 전에 누가 스캔한 PDF를 받는 경우가 많죠. 그냥 모든 것들을 계속 붙잡아 두는 게 필요해요. 소프트웨어란 게 원래 어렵고, 움직이는 부품들이 너무 많거든요. 생태계 안에서도 서로 의존하는 구성 요소들이 잔뜩 있어요. DevOps나 인프라 관련된 것들도 그렇고요. 저는 그런 쪽에 특별히 관심이 있었던 것도 아니고, 당신도 그랬던 적은 없는 것 같아요. 우리 팀이 강한 부분은… 그러니까, 뭔가 실패하는 걸 보기 위해 끝없이 기다려야 하는 그 모든 잡일들이요. 뭔가를 실행하고 기다렸다가, 30분 뒤에 실패한 걸 확인하고, 또 다른 걸 시도하고 다시 돌리고. 그리고 이틀이 지나도 여전히 디버깅하고 있는 자신을 보게 되죠.

그래요.

저에게 큰 어려움 중 하나는, 시작할 때 예상하지 못했던 부분이에요. 우리는 spaCy의 이슈 트래커를 계속 살피면서 사람들이 어떤 문제에 부딪히는지 보거든요. 그런데 막상 보면, 가끔 사람들은 예를 들어 개체명 인식 같은 태스크를 세금 분류 파이프라인 같은 걸로 풀려고 하기도 해요. 사실 NLP 문제는 서로 다른 방식으로 재정의해서 다른 방법으로 풀 수 있는 경우가 많거든요. 그래서 앞으로 나아가는 데 가장 이상적인 접근이 무엇인지, 혹은 왜 이 방법을 쓰면 안 되는지 설명하는 일이 때로는 어렵다고 느껴요. 어떤 경우에는 규칙 기반 시스템이 더 적합할 수도 있고, 그렇게 하면 굳이 모든 ML 학습이 필요하지 않을 수도 있거든요.

그리고 그게 spaCy에도 약간의 도전 과제라고 생각해요. 선택지와 가능성이 굉장히 많거든요. 규칙 기반 컴포넌트도 있고, 머신러닝 학습도 꽤 깊게 들어가 있고요. 그런데 각자가 처한 과제에 맞는 올바른 도구를 어떻게 써야 하는지 알아야 해요. 그리고 우리는 모든 사용자마다 정확히 어떤 과제를 갖고 있는지 알 수 없죠. 그래서 이 부분이 사람들을 안내하기에 매우 어렵다고 생각해요.

사실 그건 우리가 문제를 다루는 방식에 대한 논의로 다시 연결돼요. 발표에서 가끔 드는 예로, 경찰 보고서에서 피해자에 대한 정보, 범죄 발생 장소, 그리고 그 주변의 다른 세부사항들을 추출하려 한다고 상상해 보죠. 이걸 모델링하는 방법은 여러 가지가 있어요. 가장 직관적인 한 가지는 엔드 투 엔드로 하는 거예요. 어떤 이름을 피해자로 라벨링하고, 다른 항목을 범죄 장소로 라벨링하는 식이죠. 아마 그게 잘 먹힐 수도 있어요. 충분히 큰 언어 모델이 있다면 실제로 그걸 학습할 수도 있고요. 하지만 종종 그게 반드시 잘 작동하진 않아요. 그래서 이 문제를 다른 방식으로 어떻게 분해할 수 있을지 생각해야 해요. 먼저 이 텍스트가 범죄에 관한 것인지부터 예측할 수도 있겠죠. 그다음 그 안에서 장소를 예측하고, 텍스트에 대한 다른 정보를 활용해 그게 진짜 장소인지, 그리고 그게 범죄 장소인지 판별할 수 있어요. 이때 구문 분석기가 유용할 수 있는데, 특히 영어 같은 언어에서는 어떤 내용을 표현하는 방식이 그리 다양하지 않거든요. 쓰이는 동사도 한정적이에요. 가장 흔한 동사들만 커버해도 발생할 법한 문장 구성의 95%는 덮을 수 있어요. 아마 어떤 도시는 항상 잘못 인식되는 걸로 드러날 수도 있어요. 그 엔티티가 많이 언급된 데이터로 모델을 학습하지 않았기 때문일 수 있죠. 물론 재학습할 수는 있어요. 하지만 답을 이미 알고 있다면, 정규식을 하나 넣어서 그 항목이 항상 인식되도록 만드는 편이 나을 수도 있어요. 이런 식으로 잘못된 길로 갈 수 있는 방법은 정말 많습니다. 그리고 사람들은 여전히 인터넷에서 뭔가를 다운로드하면 자신이 떠올린 복잡하고 특수한 문제에도 마법처럼 잘 동작하길 기대하죠. 많은 언어 모델의 경우 한 번만 학습해 두고 다운로드한 뒤 미세 조정하거나 재사용하길 원하겠지만, 원칙적으로는 모델을 학습하고자 하는 의지가 있어야 합니다. 질문은 “모델을 꼭 학습해야 하나요?”가 아니에요. “지금은 모델을 학습할 수 있다”가 핵심이죠. 그게 훌륭하고, 잘 작동하고, 여러분의 일을 훨씬 쉽게 만들어 줄 거예요. 예측하고 싶은 대상이 있다면 모델을 학습하고자 해야 합니다. 그게 아니라면 아마 하지 않는 편이 낫겠죠. 우리는 종종 “이건 머신러닝을 쓰고 싶지 않으실 거예요”라고 말씀드립니다. 그러면 다들 놀라죠. 예전에 실제로 어떤 분이 숫자에 대한 NER을 구현하고 싶다고 묻더라고요. 그래서 “잠깐만요, 텍스트에 있는 숫자 시퀀스요? 그걸 왜 예측하려 하세요? 정규식으로 매칭하면 되잖아요”라고 했죠. 그분이 “맞아요, 그런데 제 상사는 머신러닝을 쓰라고 해요”라고 하더군요.

와.

진짜 미안하지만, 그런 일도 정말 자주 일어나요. 모델링할 필요가 없는 걸 굳이 모델링하려 드는 경우처럼요.

재밌는 건, 한 15년 전쯤 제가 라벨링 회사를 시작할 때만 해도 사람들은 머신러닝을 무섭고 하고 싶지 않은 과학 프로젝트쯤으로 생각했어요. 그런데 지금은 말도 안 될 정도로 쉬운 규칙 기반 작업에도 굳이 머신러닝을 붙이려 하죠. 세상이 이렇게 변한 게 참 웃겨요.

맞아요, 하지만 결국 사람들이 돈을 받는 일이라 그런 것 같아요. 가끔은 정말 이해가 안 될 때가 있어요. 인터넷에서 비협조적인 태도를 보이는 사람들이, 정작 머신러닝으로 큰돈을 받을 법한 일을 하면서 아주 기본적인 것들로 우리를 들볶을 때�� 있거든요. 모두가 머신러닝 분야에서 일하고 싶어 하는 건 이해해요. 아마 좋은 직업일 테니까요. 그렇다고 해서 그곳에서 하는 일이 늘 특별히 훌륭하다는 뜻은 아니지만요.

좋습니다. 시간 내주셔서 정말 감사합니다. 쇼 노트에 새로 나온 spaCy 라이브러리 링크를 넣어둘게요. 또, 원하시는 분들이 바로 시작해 볼 수 있도록 입문 튜토리얼도 함께 올려두겠습니다.

응, 좋아.

정확도가 높은 숫자 인식기를 학습하세요.

하이퍼파라미터 튜닝을 잊지 마세요.

응, 광범위한 하이퍼파라미터 탐색을 잊지 마.

맞아.

그렇죠. 운이 좋으면 95%까지도 갈 수 있어요. 그 정도면 어떤 머신러닝 과제에서도 꽤 좋은 편이라고 할 수 있죠.

멋져요. 정말 감사합니다.

불러 주셔서 감사합니다.

감사합니다.