고가용성(HA) 도구에서 Pacemaker는 Keepalived 는 가장 널리 사용되고 있는 구성요소 입니다.저는 2가지 모두 사용하고 있는데요..간단한 TCP Load Balancing에는 Keepalived를 사용하고,복잡한 API 라우팅을 위해 Pacemaker/HAProxy 조합을 사용하고 있습니다.이 둘은 고가용성(HA) 구축 시 항상 비교되는 도구들 인데요...GPT-4o에게 둘의 장단점을 물어보았습니다.Pacemaker와 Keepalived는 고가용성(HA) 클러스터 환경에서 자주 사용되는 두 가지 소프트웨어입니다.각자의 장단점이 있으며, 특정 상황에 따라 적합한 선택이 달라질 수 있습니다. 아래에서 두 솔루션의 주요 장단점을 비교해 보겠습니다.• None 강력한 기능 및 유연성: Pacemaker는 복잡한 HA 환경을 지원하며, 다양한 리소스 유형과 고급 기능을 제공합니다. 이를 통해 복잡한 클러스터링 시나리오를 처리할 수 있습니다.• None 광범위한 리소스 에이전트: 많은 리소스 에이전트를 지원하여 다양한 애플리케이션과 서비스의 HA 구성을 쉽게 설정할 수 있습니다.• None 클러스터 상태 관리: 클러스터의 상태를 세밀하게 관리하고 모니터링할 수 있으며, 문제 발생 시 자동으로 조치를 취합니다.• None 확장성: 여러 노드를 포함한 대규모 클러스터 환경에서 안정적으로 동작합니다.• None 통합된 경고 및 알림 시스템: 문제 발생 시 관리자에게 경고를 보내고, 다양한 통합 옵션을 통해 신속하게 대응할 수 있습니다.• None 설정 복잡성: 설치 및 설정이 복잡하여, 초기 학습 곡선이 가파릅니다.• None 오버헤드: 비교적 무겁고 리소스 소비가 많아, 작은 규모의 클러스터에서는 과할 수 있습니다.• None 의존성: Corosync와 같은 다른 클러스터링 소프트웨어와 함께 사용해야 하는 경우가 많아, 설정과 관리가 복잡해질 수 있습니다.• None 간단한 설정: 설치 및 설정이 상대적으로 간단하며, 빠르게 구성할 수 있습니다.• None 경량화: 비교적 가볍고 리소스 소비가 적어, 작은 규모의 클러스터에 적합합니다.• None Virtual Router Redundancy Protocol (VRRP): 기본적으로 VRRP를 사용하여 IP 페일오버를 처리하는 데 최적화되어 있습니다.• None 빠른 페일오버: 매우 빠른 페일오버 시간을 제공하여, IP 주소를 거의 즉시 다른 노드로 이동할 수 있습니다.• None 네트워크 중심: 주로 네트워크 서비스(예: 로드 밸런싱, 라우팅)의 고가용성에 적합합니다.• None 제한된 기능: Pacemaker에 비해 기능이 제한적이며, 복잡한 HA 시나리오를 지원하는 데 한계가 있습니다.• None 리소스 관리 제한: 주로 네트워크 서비스에 초점이 맞춰져 있어, 애플리케이션 레벨의 HA 설정이 어렵습니다.• None 확장성 한계: 대규모 클러스터 환경에서의 확장성이 제한적입니다.• None 제한된 모니터링 및 경고: 모니터링 및 경고 시스템이 비교적 단순하여, 복잡한 요구 사항을 충족하기 어려울 수 있습니다.Pacemaker와 Keepalived는 각기 다른 장단점을 가지고 있으며, 사용 환경과 요구 사항에 따라 적합한 솔루션이 달라질 수 있습니다.복잡하고 다양한 애플리케이션의 고가용성을 필요로 하는 대규모 클러스터에서는 Pacemaker가 더 적합할 수 있으며,단순하고 빠른 네트워크 서비스의 고가용성을 요구하는 작은 규모의 클러스터에서는 Keepalived가 더 적합할 수 있습니다.와우! 생각보다 잘 정리해줘서 놀랬습니다. 잘했어~ OpenAI !Keepalived는 설정이 너무 간단하고 설치가 쉬워서 구글링 해보면 금방 사용할 수 있다는 것을 알 수 있습니다.반면에 Pacemaker/Corosync 및 HAProxy 의 경우, 설치과정이 복잡하고 설정 과정 역시 많은 경우의 수가 있어 쉽게 다가 가기가 힘듭니다.특히 Pacemaker가 2 버전대로 올라가면서 Resource Failover 설정에도 변경이 생겨서 구글링 해서 나오는 상당 수 글들이 이제 먹히지 않는 경우가 많습니다.이번 글에서는 RHEL/Rocky Linux 9 버전에서 Pacemaker/Corosync 및 HAProxy를 설치하고 사용하는 방법에 대해서 소개합니다.2대를 기준으로 설정합니다. 모두 동일한 하드웨어 스펙(Alder Lake 24 Cores/32GB RAM)을 가지고 있습니다.연결 된 Network 는 2.5Gbps NIC이 연결되어 있습니다.2 노드에서 모두 설정합니다.VIP 바인딩과 패킷 포워딩에 필요한 부분만 설정합니다.참고로, Production 환경에서는 파일 디스크립터/네트워크 성능을 높일 수 있는 추가적인 튜닝을 해야 합니다.최신 버전의 RHEL 9 용 HAProxy를 설치합니다. 2가지 방법이 있습니다.• None• None https://esnl.de 사이트에 방문하면 repo 설정 내용을 확인할 수 있습니다.• None esnl.de_haproxy.repo 를 자신이 원하는 HAProxy 버전에 맞게 /etc/yum.repos.d/ 경로 아래에 추가Rocky/RHEL 9 에서는 최신 버전의 Pacemaker를 설치 할 수 있게 해주는 ${os-release}-addons.repo 가 없거나 있더라도 [highavailability] 섹션이 비활성화 되어 있습니다.이 부분을 먼저 설정해겠습니다.• None• None Rocky 9의 경우 ${os-release}-addons.repo 파일은 있지만 [highavailability] 섹션이 비활성화 되어 있습니다.• None 전체 내용중에 앞 부분에 있는 [highavailability], [highavailability-debug], [highavailability-source] 섹션의 내용을 아래 내용으로 변경 해 줍니다.• None mirrorlist 를 주석처리하고 rocky mirror 사이트 중에 KAIST 서버를 직접적으로 이용하도록 수정했습니다.• None• None SKT TiDC 등에서 배포되는 RHEL 9 에는 ${os-release}-addons

글. 황다원(Shasha) / UX Designer부제. Design Ops여기어때는 20명이 넘는 UX 디자이너가 있어요. 각 디자이너들은 앱, 웹, 파트너센터, 디자인 시스템, 비주얼, 브랜딩 등 다양한 도메인을 담당하고 있는데요.각기 다른 작업을 하고 있는 디자이너들이 일관성 있는 디자인을 지속해 나가는 게 쉬운 일이 아니라는 걸 디자이너 분들은 많이들 공감하실 것 같아요. 특히 프로젝트마다 업무 프로세스도 조금씩 달라, 종종 제대로 맞춰 놓은 듯싶어도 어느새 방향이 달라져 있는 상황에 부딪히곤 해요.저희는 이러한 문제를 지속적으로 발견하였고, 써머(Head of UX)는 Design Ops TF를 꾸려 이 문제를 다 함께 해결해 보자는 제안을 하셨고, 이를 계기로 벌써 1년째 운영 중에 있어요.Design Ops가 무엇인가요?Design Ops는 디자인 운영(Design Operations)의 약어로, 디자인 팀이 효과적이고 효율적으로 작업할 수 있도록 지원하는 일련의 프로세스와 도구를 말해요. 비교적 최근에 생긴 개념이지만 많은 디자인 조직들이 이미 이 역할을 중요하게 여기고 있어요. 또 , 2022년 Config(출처. ‘Inayaili León의 ‘DesignOps: The API of design teams') 에서도 소개가 되었었어요.여기어때 UX center도 이런 취지에서 자체적으로 Design Ops TF를 구성해 운영하고 있어요. 각 팀에서 1~2명 디자이너가 참여해서 5~6명 정도가 함께하며 현재 3기까지 진행 중이고, 저는 2기 리드로 활동했었어요.그간 저희가 어떤 문제를 어떻게 개선하고, 프로세스를 고도화해 왔는지, 그리고 업무를 하면서 Design Ops를 어떻게 병행했는지 1기와 2기를 나눠서 공유해볼게요.1기 : 업무 개선참여자: 써머(Head of UX), 네이썬(Core UX Lead), 제티(UXW), 테나(UXD), 픽시(UXD), 지니(UXD)피그잼에서 진행한 아이데이션1기 멤버들은 ‘업무 개선’을 메인 주제로 삼아 현재 실무에서 느끼는 불편함을 파악하고 우선순위를 정했어요. 아이디어를 모으고 그룹화하여 가장 시급히 개선이 필요한 부분들을 찾아냈죠.다양한 의견들이 나왔지만 아래 두 가지로 주제를 좁혔어요.1. 피그마 파일 관리 개선2. 진행 중인 프로젝트 한눈에 확인하기 (대시보드 구축)가장 먼저 진행한 프로젝트는 피그마에서 작업하면서 겪는 문제점을 해결하는 것이었어요. 많은 디자이너들이 피그마 내에서 각자 파일을 다르게 관리하다 보니, 다른 프로젝트의 작업 파일을 찾기 어려웠고, 담당자가 링크를 주지 않으면 헤매는 일이 많았죠.저희는 이런 문제를 해결하기 위해 피그마 타이틀 규칙 및 커버 디자인을 통일시켰고, UX 대시보드를 구축해 프로젝트 진행 상황을 쉽게 확인할 수 있도록 했어요.저희는 이런 문제를 해결하기 위해 피그마 타이틀 규칙 및 커버 디자인을 통일시켰고, UX 대시보드를 구축해 프로젝트 진행 상황을 쉽게 확인할 수 있도록 했어요.도메인별 피그마 커버 템플릿대시보드 템플릿 예시이를 통

6월 13일에 진행한 제6회 Kakao Tech Meet의 발표 영상과 발표자 이야기를 공유합니다.#AI #LLM #SpamDetection #TextClassification #TextGeneration발표자 zoey(조혜연님) 인터뷰Q. 발표 주제를 선정한 과정에 대해서 이야기해주세요. 주제를 선택한 이유와 고려 요소가 있을까요?발표 주제는 스팸 콘텐츠 대응을 위한 LLM 도입 사례인대요. 주제를 선정한 과정에 대해 말씀드리면 저는 스팸이라 부르는 유해 콘텐츠를 차단하는 조직에서 일하고 있어요. 스팸 콘텐츠 대응을 하면서, 저희 조직의 스팸 분류 작업이 어떤 고민을 필요로 하는지 공유하고 싶었어요. LLM을 통해 문장 생성뿐만 아니라 분류 문제도 해결할 수 있다는 점과 LLM의 장점을 활용해 분류 결과를 문장으로 재생성함으로써 스팸을 모니터링하는 운영자들에게 실질적인 도움을 제공하고 있습니다. 이런 과정을 통해 LLM의 다양한 활용 가능성과 사람에게 설명가능한 AI에 대해 전달하고자 이 주제를 선택하게 되었습니다.Q. 발표를 준비하면서 가장 많은 시간을 고민한 부분은 무엇인가요?참석자들의 LLM에 대한 이해도가 어느 정도인지를 몰라 어떻게 쉽게 설명할지 고민했어요. 또한 스팸 분야 자체가 흔하지 않아 발표 내용을 어떻게 청자들에게 잘 전달할지 고민하며 예시를 많이 사용했습니다. 이런 저의 고민이 청자들에게 잘 전달되었으면 좋겠습니다.Q. 테크밋을 마무리하신 소감을 들려주세요. 인상적이었던 부분이 있나요?카카오에서 기술적인 이야기를 주제로 발표하는 것은 처음이었는데, 떨리기도 했지만 재미있었습니다. 집중해서 경청해주시는 참석자들의 모습을 보며 더 열심히 발표 내용을 전달해야겠다고 생각했습니다. 발표한 내용이 잘 전달됐는지 궁금했는데, 패널 토의를 통해 추가적인 내용을 전달할 수 있어서 좋았습니다. 상호작용하는 느낌이 정말 좋았어요.Q. 못다 한 이야기가 있다면?현장에서 들어온 질문 중 하나가 '데이터의 개수가 얼마나 되어야 하나요?'였는대요. 사내 프로젝트를 외부에 발표하다보니 구체적인 수치를 물어보는 질문에 명쾌한 답변을 드리지 못하기도 했지만 사실, 이 질문에는 정답이 없어요. 왜냐하면 우리가 어떤 목표를 가지고 모델을 만들고자 하는지, 어떤 결과를 기대하는지에 따라 필요한 데이터의 양이 달라지기 때문이죠. 이에 대한 해답은 상황에 따라 다를 수밖에 없습니다.예를 들어, 만약 특정 상황에 모델을 편향시키고 싶다면 그 상황에 맞는 데이터를 더 많이 수집할 수 있고, 반대로 모델이 다양한 상황을 잘 이해하도록 하고 싶다면 가능한 한 많은 데이터를 활용해 다양한 패턴을 학습시키는 것이 좋습니다.'이런 상황에서 어떻게 판단해야 하나요?'라는 질문에 대한 답변도 비슷합니다. 모델러는 모델을 학습할 때 어떤 기준을 세워서 데이터를 수집하고 라벨링합니다. 이 과정에서 '이런 상황 이라는 것이 어느 정도 가이드라인으로 정리될거에요. 예를 들어, 'apple 이라는 단어를 분류할 때 해결하려는 도메인이 주식과 관련 되었다면 '회사 로, 음식이라면 '과일 로 라벨링을 해야할거에요.이처럼 데이터와 모델을 활용해 문제를 해결하는 과정은 매우 주관적이고, 상황에 따라 다양한 접근이 가능합니다. 이럴 때 명확한 규칙이 있으면 좋겠지만, 실제로는 해당 도메인을 깊이 이해하고, 데이터의 특성을 정밀하게 분석하고 이해하는 과정이 훨씬 중요하다고 이야기드리고 싶어요.발표 영상은 카카오테크 유튜브 채널(재생목록)에서도 시청하실 수 있습니다. 관련 글 목록:카카오의 스팸 메일 대응 전략: 문자열 변형 CASE STUDY / 제6회 Kakao Tech Meet이미지 기반 스팸 대응을 위한 카카오의 AI 기술 활용 / 제6회 Kakao Tech Meet스팸 콘텐츠 대응을 위한 카카오의 대규모 언어 모델(LLM) 도입 사례 / 제6회 Kakao Tech Meet

6월 13일에 진행한 제6회 Kakao Tech Meet의 발표 영상과 발표자 이야기를 공유합니다.#웹뷰 #디버깅 #ChromeDevTools #websocket발표자 herschel(오창화님) 인터뷰Q. 발표를 통해 어떤 이야기를 해주고 싶으셨나요?이미지 분류 모델, 특히 성인 이미지 분류 모델 등의 경험기는 외부에 공개된 노하우들이 매우 적습니다. 그런 부분에 단초를 제공하고 싶었습니다.그리고 저는 외부에 딥러닝 발표를 할 때 가장 이야기 하고 싶은 것은 바로, 머신러닝/딥러닝에서 중요한 것은 수학적 지식도 개발적 테크닉도 아닌 끊임없이 생각하고 시도하고 도전하는 것 입니다.너무 어려워하지말고 기초가 없어서 힘들다 생각말고 도전했으면 좋겠습니다.Q. 앞으로의 테크밋에 기대하는 것은 무엇인가요?카카오 와서 아쉽다는 생각을 하던거는 우리 회사가 외부 많은 개발자분들과 이야기 나누는 자리를 만들지 않는다는 것이 아쉬웠습니다. 테크밋은 그 아쉬움을 끊어낼 수 있는 좋은 자리라 생각합니다.여러 개발 경험에 대한 이야기도 나누고 더 나아가 발표자의 경험을 공유하는것도 좋지만 참여자들과 많은 이야기를 나눌 수 있는 시간이 있으면 좋겠어요.Q. 패널토의에 참여하신 후기가 궁금해요!외부 발표를 꽤 했던 편인데도 이런 방식은 처음 경험해봐서 매우 신선했습니다.특히나 궁금하셨던 질문들을 시간 관계상 현장에서 모두 답변드리긴 어려운데 좋아요 기반으로 많은 분들이 궁금해하시는 부분 위주로 답변이 가능하다보니 저도 청중들은 제 발표에 이런걸 궁금해 했구나 라는것을 알 수 있어서 좋았어요.또한 같이 발표한 크루들과 한 자리 에서 모여서 이야기 하는것도 든든한 동료가 옆에 있어 긴장도 덜 수 있었습니다.발표 영상은 카카오테크 유튜브 채널(재생목록)에서도 시청하실 수 있습니다. 관련 글 목록:카카오의 스팸 메일 대응 전략: 문자열 변형 CASE STUDY / 제6회 Kakao Tech Meet이미지 기반 스팸 대응을 위한 카카오의 AI 기술 활용 / 제6회 Kakao Tech Meet스팸 콘텐츠 대응을 위한 카카오의 대규모 언어 모델(LLM) 도입 사례 / 제6회 Kakao Tech Meet

6월 13일에 진행한 제5회 Kakao Tech Meet의 발표 영상과 발표자 이야기를 공유합니다.#MAIL #Text #Encoding발표자 laura(이소민님) 인터뷰Q. 테크밋에 참여하게 된 계기가 있나요?실제 케이스를 보면서 이야기할 수 있는 자리를 만들어보고 싶었습니다.이에 대한 아이디어와 대응 과정을 따라가면서 스스로 회고도 하고, 외부개발자의 시선에서 어떤 생각들을 하실지가 궁금했었어요.이러한 생각에 맞춰서 발표준비에 임했던것 같습니다.Q. 연단에서 참가자분들을 바라볼 때 어땠나요?떨리기도 하고 진중한 태도로 경청해주셔서 감사했습니다.개인적으로 스팸메일에 큰 관심이 있을까 싶기도 했었는데 생각보다 많은분들이 관심을 갖고 봐주셔서 의외라 생각했었어요.Q. 개인적으로 앞으로 도전해보고 싶으신 것이 있나요?과거 IFKAKAO를 통해서 메일 카테고리 분류모델 개발에 대해 말씀드린적이 있는데요,카테고리 뿐 아니라 스팸 도메인에서도 모델을 개발중에 있는데, 외부에 알릴 기회가 생기면 좋겠습니다발표 영상은 카카오테크 유튜브 채널(재생목록)에서도 시청하실 수 있습니다. 관련 글 목록:카카오의 스팸 메일 대응 전략: 문자열 변형 CASE STUDY / 제6회 Kakao Tech Meet이미지 기반 스팸 대응을 위한 카카오의 AI 기술 활용 / 제6회 Kakao Tech Meet스팸 콘텐츠 대응을 위한 카카오의 대규모 언어 모델(LLM) 도입 사례 / 제6회 Kakao Tech Meet

고객 행동의 원인은...!?저는 SK텔레콤에서 주로 고객 행동 데이터를(Customer Behavior Data) 분석합니다.무선 회선에서 나오는 다양한 고객 데이터를 들여다 본 뒤에, 인사이트를 도출하거나 고객 행동을 예측하거나 마케팅/프로모션이 잘(?) 되었는지 판단하지요.가장 어려운 질문은 고객 행동의 원인을 묻는 것입니다. "이 고객은 왜 이탈 했을까", "요금 상품을 변경한 이유가 뭐지?", "SK텔레콤을 계속 이용하는 이유는?" 등.이런 인과관계 물음에 대답하기 위한 여러 분석 방법론들이 있지만(RCT, Casual Graph, DID 등), 정교한 실험 설계는 현실적으로 어려울 수 있고,현재 쌓아놓은 데이터에는 생존 편향 등의 Bias가 이미 있는 경우가 많기에 모두가 원하는 명쾌한 해답을 말하기에는 껄끄러운 부분이 있습니다.고객에게 직접 물어보자! --> FGD가장 깔끔한 해답은 직접 고객에게 물어보는 것입니다. 고객 설문은 문항을 구성하여 설문조사를 하기도 하고, 직접 고객을 초대하여 인터뷰하는 방식도 있습니다.직접 인터뷰하는 방식을 FGI 혹은 FGD(Focus Group Interview/Discussion)이라고 부르는데, SK텔레콤에서도 고객에 대한 다양한 궁금증에 대해 FGD를 진행하고 있습니다.FGD는 특히 최근의 트렌드나 솔직한 감정/뉘앙스를 들여다봐야 할 때 도움이 됩니다.이번에 하게 된 분석도 위와 같은 흐름이었습니다. 쿠팡, 해외직구 등을 통한 자급제 단말 구매(OMD) 증가 추세의 이유와 SKT 유지/해지의 관련성을 찾는 것이었지요.이를 위해 먼저, DB에 있는 고객 행동 데이터로 OMD 고객에 대해 대략적인 그림을 그려본 뒤에(프로파일링),좀 더 직접적으로 고객의 행동을 유추하기 위해 고객 설문을 진행하고, 그동안 진행했던 FGD 중에 관련 있는 조사도 찾아 보았습니다.넵, 맞습니다. 여기까진 순조로웠지요~문제는 읽어야 할 FGD 문서가 너무 많다는 것이었습니다. FGD 문서는 word 파일로, 사회자와 고객간의 대화가 모두 STT(Speech to Text)로 정리 되어 있었고,대략 60 페이지의 word 파일이 12개가 있었습니다. 하나씩 읽으면서 정리하자니 시간 낭비 같았고, '대 AI' 시대에 어울리는 업무 방식도 아니지요.'그래 이런 업무 시키라고 GPT씨가 있는 것 아니곘어!?'라고 생각하며,가장 쉽게 할 수 있는 방법인 chatGPT-GPTS에 word 파일들을 올리고, 간단한 description을 작성한 이후 대화를 해봤습니다.12개 중 하나의 문서는 확인을 위해 제가 직접 읽었고, 이 문서에 대해 GPTS에 여러 질문을 해보면서 정확도를 확인하였습니다.FGD 문서에 등장하는 고객의 수와 진행자의 질문 리스트 등을 물어보니 나쁘지 않은 요약 능력에 '됐다! 쉽게 해결할 수 있겠다'고 생각했으나....문서 뒤에 있는 내용으로 갈수록 전혀 대답하지 못함을 알게 되었습니다.또한 "평상시에 통신사 멤버십 혜택을 얼마나 자주 이용하고 계신가요?" 같은 명시적인 질문에는 쉽게 요약을 하지만,"멤버십 사용에 대한 각 고객의 의견을 요약해줘" 같이 전체 요약에 대해서도 전혀 다른 이야기를 생성하는 등 할루시네이션 현상이 나타났습니다.이런 현상에 대한 이유는 아마도 모델의 토큰 제한 떄문으로 보입니다. 하나의 문서에만 36,200의 토큰이 포함되어 있으니까요.GPTS에 활용되는 GPT 버전이 무엇인지는 정확히 모르겠지만, 아마 문서의 토큰 개수가 context window의 범위 이상이지 않을까 싶어요.여러 문서들을 LLM이 잘 이해하게 할 수는 없을까? --> RAG"이래선 안되겠다!!" 라고 외치며(속으로), 다른 방법을 찾아 보았고 RAG(Retrieval Augmented Generation)을 활용하기로 하였습니다.RAG은 주로 LLM이 학습하지 못한 최신 정보나 특정 분야에 대한 세부적인 내용을 생성하고자 할 때 활용하는 기술로,2020년 Meta의 논문("Retrieval-Augmented Geneartion for Knowledge-Intensive NLP Tasks")에서 발표된 이후 여러 LLM 프로젝트에서 활용 되고 있습니다.RAG에 대해 찾아보니 고급 방법론이 많더군요. Naive RAG, Advanced RAG, Modular RAG 등 패러다임이 빠르게 변하는 것 같은데,제게 필요한건 word 문서들을 잘 이해하여 답변하는 LLM. 서비스를 위한 Production Level이나 실시간으로 변하는 정보에 대한 고민은 필요하지 않으니, 최대한 간결하게 구현해보았습니다.기본적인 RAG을 구현하기 위해 우선 여러 word 파일들을 합쳐주고, 간단한 전처리를 해줍니다.만들어 놓은 텍스트를 더 작은 조각으로(chunk) 나누는 chunking 작업을 해야 됩니다.이유는 언어 모델은 처리할 수 있는 맥락의 양에 한계가 있기 때문에 작은 텍스트 단위인 chunk를 생성하는 것이 필요합니다.어떤 방법을(spliter) 선택하고 적절한 chunk size/overlap 찾는 것이 필요한데, 저는 Recursive Chunk 방법을 선택했고, chunk size는 200, chunk overlap은 10으로 지정했습니다.여러가지 방법을 시도해보고 결정한 것은 아니고, 인터뷰 문서 특성상 모든 질문에 동일한 길이의 답변이 있는 것이 아니라서 Recursive 방법론이 유용하다고 생각했습니다.이제 chunk로 나뉜 텍스트 뭉치들을 임베딩 모델을 통과시키고, 결과물(임베딩 벡터)을 vector DB에 저장할 차례입니다.여기서도 선택의 순간들이 기다리고 있습니다.(네, 인생은 선택의 연속입니다) 어떤 임베딩 모델을 쓸지, vector DB는 무엇을 쓸지 정해야 됩니다.임베딩 모델은 다양한 언어를 처리할 수 있는 'text-embedding-3-large' 를, vector DB는 langchain에서 활용 가능하고 무료인 chroma DB를 사용했습니다.자, 여기까지 기본적인 RAG의 설정은 다 되었습니다. 이제 답변을 생성할 LLM 모델을 결정하고 langchain을 활용해 prompt를 작성하면 됩니다.결과를 호가인하면 아래와

우리는 Material Design에서 제공하는 Switch를 이용하여 UI를 개발할 수 있습니다. 그러나 브랜딩을 따르기 위해 Custom Switch의 개발이 필요한 경우도 발생합니다. 제가 소속된 팀 또한 Jetpack Compose를 활용하여 Custom Switch를 개발했습니다. 하지만 Layout Inspector를 활용하여 Custom Switch의 Recomposition 횟수를 확인해 보니, 예상치 못한 Recomposition이 다수 발생함을 확인할 수 있습니다.아래 코드에서 Custom Switch의 check 상태가 변경될 때마다, 50회 이상의 Recomposition이 발생하는 것을 확인할 수 있습니다.@Composablefun Screen( modifier: Modifier = Modifier) { var check by remember { mutableStateOf(false) } Box( modifier = modifier.fillMaxSize(), contentAlignment = Alignment.Center ) { CustomSwitch( check = check, onClick = { isActive = !isActive} ) }}@Composableprivate fun CustomSwitch( check: Boolean, modifier: Modifier = Modifier, onClick: () -> Unit) { val state by animateDpAsState( targetValue = if (check) 150.dp else 0.dp, animationSpec = tween(durationMillis = 1000), label = "custom_switch" ) Box( modifier = modifier .size(width = 200.dp, height = 50.dp) .background(Color.LightGray) .clickable(onClick = onClick) ) { Box( modifier = Modifier .offset(state) .size(50.dp) .background(Color.Blue) ) }}Custom Switch의 check 상태가 변경될 때마다, 50회 이상의 Recomposition 발생반면, Material Design에서 제공하는 Switch의 경우, check 상태가 변경될 때마다 1회 Recomposition이 발생하는 것을 확인할 수 있습니다.@Composablefun Screen( modifier: Modifier = Modifier) { var check by remember { mutableStateOf(false) } Box( modifier = modifier.fillMaxSize(), contentAlignment = Alignment.Center ) { Switch( checked = check, onCheckedChange = { isActive = it } ) }}Material3 Switch의 check 상태가 변경될 때마다, 1회 Recomposition 발생동일한 Switch이지만 어떠한 차이로 인해 Recomposition 횟수의 차이가 발생하는 걸까요? 오늘은 Custom Switch를 개발하는 데 있어 애니메이션을 최적화하는 방법에 대해 알아보겠습니다.01. Material3 Switch와 Custom Switch의 차이점 분석 Material3 Switch와 Custom Switch는 다양한 차이점이 있습니다. 이번 포스팅에서는 Switch thumb의 위치 변경 을 중심으로 이야기하려 합니다.먼저 Material3 Switch의 구현을 확인해 보겠습니다. checked가 변경될 때마다, targetValue가 변경되고, 이는 offset(Animatable)까지 변경되는 것을 확인할 수 있습니다. 해당 offset(Animatable)은 State 상태로 변경되어, SwitchImpl의 thumbValue 인자의 값으로 할당됩니다.@Composable@Suppress("ComposableLambdaParameterNaming", "ComposableLambdaParameterPosition")fun Switch( checked: Boolean, onCheckedChange: ((Boolean) -> Unit)?, modifier: Modifier = Modifier, thumbContent: (@Composable () -> Unit)? = null, enabled: Boolean = true, colors: SwitchColors = SwitchDefaults.colors(), interactionSource: MutableInteractionSource = remember { MutableInteractionSource() },) { ... val thumbPaddingStart = (SwitchHeight - uncheckedThumbDiameter) / 2 val minBound = with(LocalDensity.current) { thumbPaddingStart.toPx() } val maxBound = with(LocalDensity.current) { ThumbPathLength.toPx() } val valueToOffset = remember<(Boolean) -> Float>(minBound, maxBound) { { value -> if (value) maxBound else minBound } } val targetValue = valueToOffset(checked) val offset = remember { Animatable(targetValue) } val scope = rememberCoroutineScope( ... Box( ... ) { SwitchImpl( ... thumbValue = offset.asState(), ... ) }}SwitchImpl의 thumbValue로 전달된 상태 값은 thumbsOffset에 할당되며, Modifier.offset(offset: Density.() IntOffs

안녕하세요. SpoonRadio Buisiness Platform 팀에서 Billing 도메인 관련 백엔드 업무를 담당하고 있는 Eunice(손 윤)입니다. AWS Summit Seoul 2024에 참석할 수 있는 기회가 주어졌습니다.AWS Summit에 처음 참여라 설레는 마음으로 참가하게되었습니다. 참가 등록 데스크를 거쳐서 기조연설을 시작으로, 미리 들으려고 표시해 두었던 강연을 들으러 바쁘게 움직였습니다.가장 인상깊었던 강연은 채널톡 스타트업 기술 성장기: RDBMS에서 NoSQL로의 전환 이었습니다. 해당 강연의 내용을 소개해 드리고자 합니다.RDBS에서 NoSQL로의 마이그레이션을 하게 된 동기와 원인DynamoDB와 SQS의 장점과 활용 방안배경 설명채널코퍼레이션는 서비스 성장에 따라 트래픽 증가는 필연적으로 예전보다 더 많은 트래픽을 유발할 거라고 판단하였습니다. 간단한 대응 방법으로 RDS인스턴스 타입 스케일업(Scale-up)을 생각하였으나, 결과적으로 NoSQL을 도입하기로 합니다. 그에 따라, 아래 네 가지의 문제 해결이 필요했습니다.오버 프로비저닝으로 인한 비용 비효율 문제: 스파이크 트래픽의 피크(peak) 트래픽에 맞춰 RDS 인스턴스 사이즈를 선택해야 하기 때문에 비용 비효율이 예측됨.테이블 간 부하 전파 문제: 특정 테이블들의 부하가 RDS 인스턴스 전체에 영향을 끼쳐 전체 서비스에 장애를 우려함.NoSQL로의 오퍼레이션 대체 가능 여부: 특히 여러 채팅 방의 안 읽은 메시지 개수 합을 구하는 문제와 같은 특수한 작업.PostgreSQL에서 DynamoDB로의 데이터 마이그레이션 전략.DynamoDB를 선택한 이유위의 네 가지 문제 해결과 동시에 다음 세 가지 주요 이유로 DynamoDB를 선택했습니다.이벤트 소싱: 데이터베이스의 변경 사항을 쉽게 다른 서비스로 이벤트 소싱할 수 있어야 함.AWS 서비스들과의 연동: 기존 AWS 서비스들과의 풍부한 연동.ACID 트랜잭션 지원: 트랜잭션 지원 필요.이러한 요구 사항을 고려했을 때, AWS DynamoDB는 규모에 상관없이 빠르고 유연한 완전 관리형 NoSQL 데이터베이스 서비스로 적합Spike 트래픽 처리스파이크 트래픽 비용 비효율 문제 같은 경우에는 이전 처리량이 동일한 30분 이내에 2배에 해당하는 피크 트래픽을 동시에 수용할 수 있는 온디맨드 모드가 있고, 평소에는 내가 설정한 만큼 사용하다가 오토 스케일링에 의해서 유연하게 처리량을 조절해 주는 프로비저닝 모드가 있는데, 이 두 가지 모드 중에 적절하게 선택하여 DynamoDB를 선택한 것만으로 간단히 해결할 수 있었다고 합니다.1. 온디맨드온디맨드 용량 모드를 사용하는 DynamoDB 테이블은 애플리케이션의 트래픽 볼륨에 따라 자동으로 조정됩니다. 온디맨드 용량 모드의 테이블은 이전 피크 트래픽의 최대 2배 용량을 즉시 수용합니다.2. 프로비저닝애플리케이션 트래픽이 예측 가능한 경우트래픽이 일관되거나 점진적으로 변화하는 애플리케이션을 실행할 경우 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. Auto Scaling을 사용하여 트래픽 변경에 따라 테이블의 프로비저닝된 용량을 자동으로 조정할 수 있습니다.온디맨드 모드의 기존 테이블은 언제든지 프로비저닝된 용량 모드로 전환할 수 있습니다. 하지만 온디맨드로의 전환을 나타내는 마지막 타임스탬프가 발생한 지 24시간이 지난 후에야 다시 온디맨드 모드로 전환할 수 있습니다.Spike 트래픽과 SQS채널톡은 외부로부터의 여러 서비스 요청에 대한 로그를 기록하고 있다고 합니다. 이 로그를 DynamoDB에 기록한다면, 갑자기 많은 로그 record를 추가되어 DynamoDB의 ProvisionedThroughput을 넘어서 문제가 발생이 있었습니다. 따라서, Spike 트래픽이 발생할 경우 Amazon SQS를 이용해서 서비스 요청 로그를 버퍼링하고, Amazon SQS에서 일정한 속도로 로그를 읽어서 DynamoDB나 RDS와 같은 저장소에 저장하는 아키텍처를 설계하였다고 합니다.채널톡의 Amazon SQS를 이용한 효율적인 Spike 트래픽 처리 방법PostgreSQL 오페레이션을 DynamoDB로 처리 과정이 외에도 기존 PostgreSQL을 통한 안읽음 표시 오페레이션을 DynamoDB를 통해 어떻게 처리했는 지 등에 대한 내용들 또한 공유해주었습니다.설명을 돕기위한 채널톡 채팅의 주요 요소기존에는 PostgreSQL을 사용했기 때문에 ChatBadge는 원자적 연산을 사용했고, ManagerBadge는 ChatBadge들의 합을 구하면 됐었습니다. 하지만 DynamoDB에서 기존과 같은 방식으로 구현한다면 채팅 방이 많은 사용자는 ManagerBadge를 계산하는 속도가 점점 느려질 것으로 예측하였습니다. 이 문제를 해결하기 위해 DynamoDB 트랜잭션을 통해 어떻게 핸들링하였는 지 공유해 주셨습니다.DynamoDB table 예시특정 채팅 방에서 메시지가 작성되면, 작성자를 제외한 각 참여자에겐 다음과 같은 오퍼레이션이 수행됩니다.참여자의 ChatBadge를 증가시키는 UpdateItem을 생성합니다.참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.이를 통해, ChatBadge들의 합은 ManagerBadge가 됨을 보장하였고, 또한, 동시에 다량의 메시지가 발생하여아래 그림에서 보시는 바와 같이 충돌이 발생했을 때는 exponential backoff retry 전략을 활용하며, DynamoDB 트랜잭션은 ClientRequestToken 파라메터를 사용하는 경우 멱등성을 지원하기 때문에 연결 시간 초과 등의 문제로 동일 요청이 여러 번 제출된 경우에도 10분 이내라면 정확하게 ChatBadge와 ManagerBadge를 관리하였습니다.참여자의 ManagerBadge를 증가시키는 UpdateItem을 생성합니다.두 개의 UpdateItem 오퍼레이션을 TransactWriteItems API를 사용해 처리합니다.이를 통해, ChatBadg

안녕하세요 웹 프론트엔드 개발자 Felix입니다.웹 프론트엔드 성능 측정 방법 및 Tips에 대한 내용으로 두번째 글을 쓰려고 합니다.위 글에서는 웹 성능 측정 도구들과 웹 성능을 측정하는 방법 중 Chrome 브라우저의 Lighthouse를 사용하는 방법에 대해 소개해드렸고, 분석 방법에 대해서도 간단히 설명드렸습니다.Lighthouse는 로컬 개발시에 많이 활용했던 방법입니다.물론 Lighthouse로도 실제 운영 환경 서비스에서도 측정은 가능하지만 정확하지는 않아서 Page Speed Insights나 Web pagetest를 사용하는데요.이번 글에서는 WebPageTest에 대해 소개해드리고, WebPageTest의 특징, 측정 방법에 대해서 설명해드리려고 합니다.구글에서 사용하는 측정 도구들은 이전 블로그에서 언급 드렸던 Web Core Vital이라는 성능 지표를 기반으로 웹 사이트의 성능을 측정합니다.이번에 소개드릴 WebPageTest도 구글의 성능 측정 지표를 기반으로 성능을 측정합니다. Page Speed Insights도 좋지만, 개인적으로는 Google Page Speed보다 WebPageTest만이 가질 수 있는 장점이 많다고 생각합니다.이번 글을 읽어보시면 WebPageTest의 전반적인 사용법에 대해서 알 수 있습니다.WebPageTest는 오픈소스 도구로써, 웹사이트를 모니터링하고 웹 성능 최적화하는데 도움을 주는 온라인 도구입니다.웹 사이트의 로딩 시간, 렌더링 속도, 네트워크 트래픽을 포함한 내용들을 보기 좋게 제공한다.2008년에 출시되었고, 오픈소스이며, 유료로 과금한다면 사용할 수 있는 API도 제공되기도 합니다.WebPageTest가 실제 운영 사이트를 측정하는 Page Speed Insight, PingDom 등과 비교한 WebPageTest에 대한 장점을 나열해보았습니다.첫 번째, 글로벌 웹사이트에 대해 웹 성능 측정하기에 적합한 측정 도구입니다. 다양한 환경에서 테스트가 가능합니다.아래처럼, 정해진 모바일, 데스크톱뿐만 아니라, 3G, 4G 등 여러 환경에서 측정할 수 있습니다.테스트 지역별로 다양한 지역을 선택해서 테스트 할 수 있습니다.크롬, 파이어폭스 등 브라우저 종류를 선택하여 테스트 할 수도 있습니다.다양한 네트워크 환경에 대해 가정하여 테스트 할 수가 있습니다.Cable, 3G Slow, 3G, 4G 등 여러가지 옵션 중 설정이 가능합니다.추가적으로 Number of Tests to Run 항목에서 설정 가능한데 테스트를 몇 번 시뮬레이션 할 지 설정도 가능합니다.두 번째, WebPageTest에서 웹 성능 측정시 결과를 보기가 깔끔합니다.크롬 브라우저에 탑재된 Lighthouse의 경우도 측정이 가능하지만 같은 지표들에 대해서도 WebPageTest가 가독성이 더 좋다고 생각합니다.세 번째, 심층적인 결과 리포트가 잘 제공됩니다.위에 결과 화면처럼, 실제 데이터 결과를 기반으로 측정해서 사용자들의 지표에 대한 결과 확인도 가능합니다.위에는 실제 리포트인데요. FCP, LCP, CLS, FID, INP 모두 Good이라는 좋은 성능 수치를 기록함을 확인할 수 있습니다.TTFB 수치는 다른 것들에 비해 상대적으로 개선이 필요할 수 있겠습니다.한번의 측정만으로 아래처럼 다양한 정보 확인이 가능합니다.마지막으로, WebPagetest는 웹 프론트엔드 성능 측정에 강력한 무료 측정도구 입니다.유료버전이 있지만, 많은 경우에 무료 버전으로도 사용이 충분하다고 생각합니다.아래를 보면 무료버전과 유료버전의 차이를 확인 할 수가 있습니다.무료 계정이여도 매달 300번 테스트를 할 수 있고, 테스트 갯수가 모자르면 계정을 하나 더 만들면 됩니다.그리고 기존 테스트한 내용에 대한 히스토리 저장도 가능한 점이 좋다고 생각합니다.실제 운영 중인 사이트에 대해 웹 성능 측정 기록들을 축적하여 확인할 수가 있습니다.WebPageTest를 이용한 웹 사이트 성능 측정은 매우 간단합니다.WebPageTest (https://www.webpagetest.org/) 사이트에 접속하여 측정하고자 하는 url을 넣고 테스트를 실행하면 됩니다.url 입력 후 아래 노란색 버튼의 ‘Start Test’를 클릭하면 됩니다.웹 성능 측정 시작을 알리는 노란 버튼을 클릭하면 실시간으로 테스트가 됨을 확인할 수 있습니다.보통 1분 내로 아래와 같이 측정하고자 하는 사이트의 웹 성능 측정에 대한 결과를 확인할 수가 있습니다.웹 사이트에 대한 개발도 중요하지만, 사용자에게 좋은 웹사이트를 제공하려면 지속적인 성능 측정을 통해 웹 사이트 성능 최적화에 힘써야 합니다.필자가 다양한 성능 측정도구를 사용해봤지만, 실제 운영 중인 웹사이트의 성능을 측정할 때는, WebPageTest를 추천드립니다.구글의 PageSpeed Insights를 많이 사용하지만 WebPageTest가 다양한 옵션과 상황에서 테스트 할 수 있고, 결과에 대한 UI/UX도 좋아서 해석도 하기에 용이합니다.이번시간에는 WebPageTest의 간단한 사용법과 특징에 대해 알아봤습니다.다음번에는 WebPageTest 분석 방법에 대해 작성하도록 하겠습니다.그리고 필자가 많이 사용했던 도구 사용법에 대해서도 공유하고자 합니다.

안녕하세요. 맵비전플랫폼개발의 Zayden(이동진)입니다.제가 속한 조직은 카카오맵의 지도 데이터를 고도화하거나 카카오맵에서 활용할 수 있는 비전 시스템을 개발하고 있는데요. 오늘은 이러한 업무를 수행하는 저희 조직에서 진행했던 프로젝트인, 카카오맵의 리뷰 이미지를 분류하는 이미지 분류 모델의 개발 과정을 독자분들께 공유하고자 합니다.현재 이미지 분류 기술은 딥러닝 분야에서 비교적 간단한 작업으로 간주되며, 다양한 구현 예제를 쉽게 찾아볼 수 있습니다. 이번 글에서는 다양한 예제들 중, Zero-shot 분류를 사용하여 가공한 선분류 데이터셋을 통해 모델 개발 기간을 단축하고, OOD(Out-of-Distribution) 필터링을 이용하여 정의되지 않은 카테고리를 분류해 내는 방법을 중점으로 소개하겠습니다.이미지 분류 모델 선정딥러닝 모델을 개발하려면 먼저 수많은 모델 중에서 어떤 모델을 선택할지 결정하는 과정이 필요합니다. 딥러닝 기술이 급속히 발전하던 시기에는 해마다 공개되는 모델 간의 성능 차이가 컸기 때문에, 더 나은 모델을 찾기 위해 수많은 실험을 해야 했습니다. 그러나 현재는 딥러닝 기술이 상당히 성숙한 상황이며, 모델의 종류보다는 개발자가 학습에 사용할 데이터에 초점을 맞추는 것이 더 현명합니다. 이는 모델의 종류보다는 학습 데이터의 양과 품질이 모델의 성능에 더 큰 영향을 끼치기 때문입니다.당시 진행 중이었던 리뷰 이미지 분류 프로젝트의 요구사항은 실내 , 장소 외관 , 야외 , 음식 , 메뉴판 및 스팸 의 총 6개의 카테고리를 분류해야 하는 비교적 간단한 작업이었습니다. 따라서, 가볍고 단순하면서도 성능이 좋은 모델을 선택해야 했습니다.이 조건들을 고려하여, 많은 모델들 중에서도 CVPR 2022에서 공개된 ConvNext[1]라는 순수 컨볼루션 신경망(Convnet) 모델을 선정했습니다. ConvNext 논문의 저자는 컨볼루션 신경망도 최적화 과정을 통해 최신 트랜스포머 모델의 성능을 능가할 수 있다고 주장하기도 했었습니다. 이후, 논문의 실제 결과가 이 주장을 뒷받침하며 ConvNext 모델은 좋은 성능뿐만 아니라 단순한 구조로 경량화되어 효율성 또한 높다는 것이 확인되었습니다.이러한 이유들로 프로젝트의 주 모델을 ConvNext로 선택하게 되었습니다.학습 및 평가 데이터 구축학습 및 평가 데이터를 구축하기 위해서는 먼저 퍼블릭 데이터셋을 찾아보는 것이 좋습니다. 학습 데이터를 구축하는 데 걸리는 시간을 단축할 수 있기 때문입니다. 이번 프로젝트에서 필요한 실내 , 장소 외관 , 야외 등의 데이터는 평범한 이미지기 때문에 공개된 퍼블릭 데이터가 많을 것이라 기대했지만, 원하는 조건의 데이터를 찾는 것은 쉽지 않았습니다. 예를 들어, 실내 이미지는 음식점, 카페, 전시장 등에서 분위기와 공간감이 충분히 나타나는 이미지여야 했고, 장소 외관 의 경우 특정 장소의 간판 등을 포함한 외관의 특징을 갖추어야 하는 조건이 있었습니다.이처럼 좋은 모델을 만들기 위한 기반이 되는 고품질의 데이터셋은 분류 기준을 충족해야 하며, 최대한 최종 사용자의 데이터와 유사한 분포를 가져야 합니다. 예를 들어, 서양 가정집의 실내 이미지로만 학습 데이터를 구축하면, 해당 모델은 한국 카페의 실내 를 제대로 분류하기 어려울 수 있습니다.이러한 이유로, 저희 조직에서는 카카오에서 수집한 이미지 데이터를 분류하여 학습 및 평가 데이터를 구축하기로 했습니다.그렇게 약 20만 장의 이미지 데이터를 수집하였으며, 이 이미지들을 분류 기준에 따라 분류해야 했습니다. 물론 요청 시 사내 레이블링 작업자분들이 작업을 진행해 주실 수도 있었겠지만, 20만 장의 이미지를 분류하는 데는 상당한 시간이 소요됩니다. 그 시간 동안 저희 조직에서는 다음 작업을 진행할 수 없는 상황이 되는 것이죠.학습 데이터 선분류그래서 저희는 이미 잘 학습된 AI 모델을 활용해 수집한 학습 데이터의 일부를 선분류하기로 했습니다. CLIP[2]과 같은 멀티 모달 모델에 이미지와 텍스트 쿼리를 입력하여, 이미지와 각 텍스트 간의 상관관계를 추출하는 Zero-shot 분류가 가능합니다. 예를 들어, 강아지 이미지와 강아지 , 고양이 및 자동차 와 같은 텍스트 쿼리를 입력하면 강아지 텍스트에 가장 높은 스코어를 출력해 주는 형식입니다.이와 같은 방식으로, 20만 장의 이미지와 [ 실내 , 장소 외관 , 야외 , 음식 , 메뉴판 , 스팸 ]이라는 텍스트 쿼리를 CLIP 모델에 입력하여 모든 이미지의 의사 라벨(Pseudo label)을 얻을 수 있습니다. 물론 이렇게 단순하게 처리하면 레이블에 상당히 노이즈가 섞이게 되어 데이터셋의 품질이 떨어질 수 있습니다. 따라서 텍스트 쿼리를 구체화하고 일부 샘플 데이터를 테스트하여 텍스트별 정확도를 측정한 후, 정확도가 높은 텍스트만 신뢰하는 방식을 사용했습니다. 또한, 모델의 출력에는 이미지와 텍스트 간의 유사도가 포함되기 때문에, 특정 Threshold 이상의 유사도를 가진 이미지들만 선분류 데이터로 사용했습니다.결과적으로 음식, 음료, 야외, 자동차 및 동물에 대한 구체적인 텍스트 쿼리에서는 높은 정확도를 얻을 수 있었습니다. 그러나 실내, 건물 외관, 광고 및 웹캡처와 같은 추상적인 개념을 가진 텍스트에서는 정확도가 높지 않았습니다. 그래서 조금 더 구체적인 텍스트 쿼리를 사용했습니다. 예를 들어, 실내의 경우 대부분 의자와 테이블이 포함된 경우가 많기 때문에 의자와 테이블 이라는 쿼리를 추가하는 방식입니다.결국, CLIP 모델도 이미지와 텍스트 쌍을 활용하여 학습된 모델이기 때문에, 학습에 사용된 이미지와 텍스트와 유사한 경우에만 높은 신뢰도를 가지는 결과를 보여주게 됩니다.이렇게 선분류한 이미지들도 정확한 데이터는 아니기 때문에, 카테고리별로 폴더에 정리한 후 대략적인 검수 작업을 진행했습니다. 오분류가 많은 일부 클래스는 선분류 데이터로 사용하지 않았으며, 이러한 과정을 거쳐 최종적으로 전체 학습 데이터셋의 약 40%에 해당하는 선분류 데이터를 얻을 수 있었습니다.이러한 과정을 통해 짧은 시간 안에 상당한 양의 학습 및 평가 데이터를 확보할 수 있었습니다. 이후 레이블링 작