오랜만에 인사드립니다. 이번 포스팅에서 살펴볼 내용은Pandas이후에 Python에서 Data처리용으로 곽광받고 있는 패키지인 Polars에 대해서 다룹니다.Polars를 Pandas와 비슷하게 2차원 형태의 Sheet형 데이터 처리에 특화된 라이브러리 입니다.특징으로는• None Pola- . Rust기반으로 작성되어, 빠른 속도로 동작을 보장해 줍니다.• None SIMD를 지원하여 Vectorized 동작을 통해서 빠른 데이터 처리 보장.등의 특징을 볼 수 있습니다.2. 분산처리 라이브러리와 비교pola-rs이전에도 Pandas의 한계를 극복하기 위한 다수의 라이브러리가 있었습니다.하지만 위와같은 라이브러리들의 단점은, 초기 실행을 위해서는 overload가 동반됩니다.• None 매니저를 통해서 데이터를 분산 위치• None 분산된 데이터를 한곳으로 모음의 과정 때문에 PySpark를 사용한 분산처리 속도가 일반적인 Pandas를 사용하는것 대비 느린 경우가 다수 존재하게 됩니다.PySpark뿐만 아니라 다른 패키지들 역시 굉장히 무거운 패키지에 속합니다.Numpy의 경우 Python에서 사용할 수 있는 C언어로 작성된 Low Level 패키지 입니다.그래서 Python패키지임에도 불구하고 C언어에 근접하는 속도로 동작합니다.마찬가지로 Pola-rs의 경우 Pandas와 유사한 환경을 Rust를 사용해서 구현 해 놓은 패키지 입니다.그리고 Rust를 사용해서 GIL에서 해방된 처리환경을 보장합니다.Polars의 경우 Pandas를 개선하기 위해서 나온 만큼Pandas와는 비슷(?)한 방식의 사용 방법을 제공하려 했으나....실제 활용방법은 PySpark의 spark.sql.DataFrame과 비슷한 사용자 경험을 제공합니다.github에서 제공되는 기본적은 예시를 보겠습니다.기본적으로 DataFrame을 만들 때는 Pandas와 동일하게 Dict를 제공하거나단순하게 pl.read_csv()를 사용해서 일반 Pandas를 사용하던 패턴을 사용할 수 있습니다.이 외의 특징으로, scan 접미사가 붙은 read방법을 통해서 lazy execution이 가능하게 해줍니다.뿐만아니라 기존에 만들어진 DataFrame을 Lazy상태로 변경하고, 변경 후 해당하는 DataFrame을 Lazy Execution을 통해서 효율적은 처리를 가능하게 해줍니다.Data처리의 경우 기존 Pandas에 사용했던것과 유사하게이때 Polars를 불변성을 유지해야하는 라이브러리 이기 때문에기존의 DataFrame의 값을 변경하는 것이 아니라,변경된 값을 가지고있는 새로운 DataFrame을 생성하는 방식으로 사용자 경험을 가져갑니다.이런 method chain을 사용하는 방법 이외에LazyFrame에 직접 SQL을 사용해서 조회하는 동작 역시 가능합니다.AI의 도움을 통해서 테스트 코드를 생성합니다.위 코드 같은 경우 아래와 같은 Dataframe을 만들고• None value가 0보다 큰 경우에 대해서만 데이터를 추출• None category별로 데이터를

안녕하세요.현대자동차 제조솔루션본부 E-Forest센터에서 제조 시스템 개발을 담당하고 있는 김정환 매니저입니다.VoC(Voice of Customer, 고객의 소리)는 사용자의 의견, 불만, 개선 요구 등을 수집하여 시스템 개선에 반영하는 과정을 의미합니다. 좋은 시스템을 만들기 위해서는 양질의 VoC를 수집하고 이를 시스템에 적절하게 반영해야, 이전에 코드만 작성하는 업무를 하던 저는 그 과정에서 아래와 같은 2가지 어려움을 겪고 있어  해결 방법론을 정리해보았습니다타당한 VoC 식별하기타당한 VoC 중 개발 우선 순위 정하기1. 모든 VoC가 합리적인 것은 아니다.VoC를 듣다 보면 비현실적인 요청이나 시스템에 대한 이해 부족으로 나오는 의견이 많습니다.예를 들면:AI가 알아서 데이터를 자동으로 정리해주면 좋겠어요.ERP(전사적자원관리) 시스템을 엑셀처럼 자유롭게 수정할 수 있도록 해주세요.모든 데이터를 실시간으로 연동하고, 모든 직원이 접근할 수 있게 해주세요.이런 요청들은 기술적, 보안적, 비용적 한계를 고려하지 않은 비합리적인 요구일 가능성이 높습니다. 하지만 이런 VoC를 무시할 수 없고 객관적인 기준을 마련하여 합리적으로 선별해야 합니다.2. VoC 타당성을 평가하는 4가지 기준1) 기술적 가능성 (Technical Feasibility)해당 VoC가 현재 기술로 구현 가능한가?구현이 가능하더라도 기존 시스템과의 호환성이 유지되는가?현재 인프라(서버, 네트워크, 데이터베이스)에서 처리할 수 있는가?예시 : AI가 알아서 데이터를 자동으로 정리해주면 좋겠어요.대안 : 데이터 정리를 자동화할 수 있는 AI 모델 적용 여부 검토단순히 "불가능합니다"라고 거절하는 것이 아니라, 현재 기술 수준에서 어느 정도까지 가능하고 어떤 한계가 있는지 설명2) 업무 적합성 (Business Relevance)해당 VoC가 회사/시스템/부서의 업무 목표에 부합하는가?비즈니스 가치(생산성 향상, 품질 개선, 비용 절감 등)을 창출할 수 있는가?특정 개인의 요구인지, 다수의 사용자에게도 유용한 기능인지?예시 : ERP 시스템을 엑셀처럼 자유롭게 수정할 수 있게 해주세요.대안 : 사용자 맞춤 설정 기능을 추가하여, 특정 영역에서만 편집 가능하도록 조정ERP 시스템을 엑셀처럼 바꾸면 데이터 무결성이 깨질 위험이 있으므로 보안과 일관성을 유지하는 대안 제시3) 비용 효율성 (Cost-Effectiveness)해당 VoC를 구현하는데 얼마나 많은 비용이 드는가?비용 대비 효과(RoI, Return on Investment)가 충분한가?이미 비슷한 기능이 존재하는데, 추가 개발이 정말 필요한가?예시 : 모든 데이터를 실시간으로 연동해 주세요.대안 : 핵심 데이터만 실시간으로 동기화하고, 나머지는 배치 처리로 리소스 절약모든 데이터를 실시간으로 연동하면 서버 부하와 운영 비용이 기하급수적으로 증가하므로, 비용 대비 효과적인 방안을 검토4) 리스크 관리 (Risk Management)해당 VoC가 보안, 법적 규제, 데이터 무결성에 영향을 미치는가?요구사항이 기존 시스템의 안정성을 해치거나 장애를 유발할 가능성이 있는가?시스템 변경으로 인해 기존 사용자들이 불편을 겪게 될 위험이 있는가?예시 :모든 직원이 데이터를 자유롭게 볼 수 있도록 해주세요.대안 : 권한 관리 시스템을 강화하여, 특정 부사만 필요 데이터를 조회 하도록 조정보안 리스크가 높은 요구사항은 절대 그대로 반영되선 안되며, 대체 가능한 해결책을 찾아야 함3. VoC 우선 순위 선정 방법론시스탬 개발 시 한정된 리소스로 인하여 VoC에 대한 모든 요청을 동일하게 처리할 수 없기 때문에, 여러 상황을 고려하여 우선순위를 정해야 합니다.1) Kano 모델고객(사용자)의 마족도를 기준으로 요구사항을 5가지 범주로 분류하는 방법론으로 기능 추가, UI/UX 개선시 중요도를 판단하는 데 유용합니다.Kano 모델의 5가지 요구사항 유형유형설명예시Must-Be (기본 요구사항, 필수요소)기본적으로 갖춰야 하며, 없으면 불만족이 커지는 요소시스템은 오류 없이 정상적으로 동작해야 한다Performance (성능 요구 사항, 차별화 요소)성능이 향상될수록 만족도가 증가하는 요소데이터 조회 속도가 빠르면 만족스럽다.Excitement (흥미 요소, 기대하지 않았던 기능)없으면 불만은 없지만, 있으면 만족도가 크게 증가하는 요소AI 추천 기능으로 자동으로 부품 대체 옵션을 제안해준다면Indifferent (무관심 요소)있어도 그만, 없어도 그만인 요소시스템 테마 색상을 변경할 수 있도록 한다.Reverse (역효과 요소)일부 사용자에게는 유용하지만, 다른 사용자에게는 불편한 요소ERP를 자유롭게 수정 가능하게 하면 데이터 무결성이 깨질 수 있다.2) Eisenhower Matrix(긴급도-중요도 매트릭스)Eisenhower Matrix는 요구사항을 긴급도와 중요도에 따라 분류하는 방법입니다.긴급도중요도처리 방법예시높음높음즉시 개선 (High Priority)시스템 장애로 생산 데이터 입력 불가낮음높음개선 계획 수립 (Medium Prioriy)데이터 변경 이력 조회 UI가 불편하여 업무 시간이 과다해짐높음낮음단기 개선 (Medium Priority)데이터 조회 속도 개선 요청낮음낮음장기 검토 (Low Priority)사용자별 테마 변경 기능 추가 요청3) WSJF (Weighted shortest Job First, 가중치 기반 우선순위 모델)WSJF 모델은 비즈니스 가치와 개발 시간을 함께 고려하여 가장 적은 노력으로 가장 높은 가치를 얻을 수 있는 요구사항을 식별하는 방법입니다.WSJF = (비즈니스 가치 + 긴급도 + 리스크 감소 효과)/공수비즈니스 가치 : 기능이 업무 효율 또는 수익에 미치는 영향긴급도 : 이 기능이 얼마나 빨리 필요하거나 중요한지리스크 감소 효과 : 기능이 장애 또는 리스크를 얼마나  줄일 수 있는가개발 공수 : 기능을 개발하는 데 필요한 시간과 자원예시: WSJF 점수가 가장 높은 데이터 변경 이력 관리를 가장 먼저 개발한다.기능비즈니스 가치긴급도리스크 감소 효과개발 공수WSJF 점수데이터 변경 이력 관리97637.3데이터

안녕하세요. 저는 당근 피드인프라팀에서 Software Engineer로 일하고 있는 Lebron이라고 해요.피드인프라팀은 하루에 수백만 명의 사용자들이 당근 앱을 열었을 때 가장 먼저 마주하게 되는 피드 경험을 담당해요. 각 사용자의 관심사에 맞는 맞춤형 콘텐츠를 적절한 위치에 제공하기 위해 복잡한 피드 시스템을 운영하며, 대규모 트래픽을 안정적으로 처리하기 위한 인프라를 구축하고 있어요.중고차, 부동산 등 다양한 콘텐츠가 있는 피드위 이미지와 같이 당근의 피드에는 다양한 콘텐츠가 존재하며, 이들은 여러 맥락으로 연결되어 서빙돼요.피드인프라팀은 다양한 콘텐츠를 서빙하면서 “어떻게 하면 더 일관성 있게 데이터를 저장하고 활용할 수 있을까?”라는 고민을 여러 번 마주했어요. Feed-Entity는 바로 그 고민에서 시작한 프로젝트예요. Feed-Entity는 단순히 데이터 구조를 표준화하는 것을 넘어서, 당근의 피드 시스템이 더욱 확장 가능하고 유연한 형태로 발전하도록 했어요. 덕분에 피드에 새로운 서비스를 더 빠르게 통합하고, 사용자들에게 더 다양하고 풍부한 콘텐츠를 제공할 수 있었어요.지금부터 Feed-Entity가 어떻게 탄생했는지, 그리고 이를 통해 어떤 문제들을 해결했는지 이야기해 드릴게요.Feed-Entity의 탄생Feed-Entity가 등장하기 전, 피드 시스템은 다소 분산된 형태로 운영되었어요. 당근 내 여러 서비스(중고거래, 중고차, 당근알바 등)가 각자의 콘텐츠를 피드에 노출시키기 위해 독립적인 저장소를 운영하거나, 피드 시스템과의 직접적인 연동을 통해 데이터를 제공했어요.Feed-Entity 등장 이전 피드 시스템예를 들어 중고거래 서비스는 자체 데이터베이스에 상품 정보를 저장하고 있었고, 알바 서비스는 별도의 저장소에 구인구직 정보를 보관했어요. 피드 시스템은 여러 저장소에서 데이터를 가져와 사용자에게 보여주는 역할을 했어요.이런 구조는 초기에는 단순하고 직관적이었어요. 그러나 당근의 서비스가 다양해지고 규모가 커지면서 여러 가지 한계점을 드러내기 시작했어요. 각 서비스마다 데이터 구조와 저장 방식이 달랐고, 새로운 서비스를 피드에 추가할 때마다 많은 통합 작업이 필요했어요.이러한 문제들을 해결하기 위해 우리는 Feed-Entity라는 개념을 도입했어요. Feed-Entity를 통해 이루고자 했던 목표들은 다음과 같아요.데이터 구조의 표준화: 각 서비스마다 달랐던 데이터 구조와 통신 방식을 표준화하여 시스템 간 일관된 인터페이스를 제공하고 싶었어요.시스템 확장성 개선: 새로운 서비스를 피드에 더 쉽고 빠르게 추가할 수 있게 만들고 싶었어요.데이터 일관성 확보: 다양한 콘텐츠를 더 일관성 있게 다루고 싶었어요.통합 관리 시스템 구축: 중고거래, 알바, 중고차, 부동산, 동네생활 등 모든 서비스의 콘텐츠를 한 곳에서 관리하고 싶었어요.사용자 경험 향상: 결과적으로 사용자들에게 더 다양하고 풍부한 콘텐츠를 보여주고 싶었어요.Feed-Entity: Single Source of Truth for Feed SystemFeed-

데이터 보안과 AI 혁신 사이에서 균형을 찾고 계신가요? 이 백서는 민감한 기업 데이터를 보호하면서 AI 기술을 도입하려는 기업들을 위한 온프레미스 솔루션의 전략적 가치를 제시합니다. 온프레미스 AI의 필요성과 시장 동향, 온프레미스 AI를 도입할 때의 주요 고려사항, 산업별 맞춤형 구현 사례까지, IT 의사결정자들을 위한 실질적인 구현 가이드를 지금 다운로드하세요.현재 AI 기술은 비즈니스 혁신의 핵심 동력으로 자리잡았지만, 많은 기업들이 데이터 보안과 주권 문제라는 현실적인 장벽에 직면하고 있습니다. 특히 민감한 기업 정보와 고객 데이터를 클라우드 환경에서 처리하는 것은 규제 준수와 보안 측면에서 상당한 위험을 수반합니다. 이러한 문제에 대한 해결책으로, 온프레미스 AI 솔루션은 데이터 보안을 우선시하는 기업들에게 필수적인 대안으로 부상하고 있습니다.이 백서는 데이터 보안과 규정 준수가 중요한 산업 환경에서 기업 내부에 AI 인프라를 구축하여 혁신을 가속화하면서도 데이터 주권을 유지할 수 있는 방법과 전략을 제시합니다. 온프레미스 AI의 필요성과 시장 동향, 온프레미스 AI를 도입할 때의 주요 고려사항, 산업별 맞춤형 구현 사례까지, IT 의사결정자들이 실질적으로 참고할 수 있는 구체적인 가이드라인을 제공합니다.• 온프레미스 AI의 전략적 가치와 비즈니스 영향• 기업 환경에 최적화된 온프레미스 AI 주요 고려 사항이 백서를 통해 귀사의 데이터 보안을 유지하면서 AI 혁신을 실현할 수 있는 전략적 인사이트를 얻으실 수 있습니다. 아래 양식을 작성하시면 전체 백서를 즉시 다운로드하실 수 있습니다.

AI는 어느덧 개발자의 일상이 되어, 생산성과 창의성을 높이는 새로운 가능성을 열어주고 있습니다. 글로벌 개발자 생태계의 중심에 있는 GitHub의 CEO인 Thomas Dohmke(이하 Thomas)와 GitHub 리더들이 지난 3월 25일, 카카오판교아지트를 방문하여 카카오의 정규돈 CTO(이하 GD)와 카카오 기술 리더들과 특별한 대화를 나누었습니다.GD는 “카카오는 AI Native Company로서, 코드 생성부터 시스템 모니터링까지 AI를 통한 개발자 워크플로우 전체의 생산성 향상을 목표로 하고 있어요. GitHub의 Copilot은 코드 생성과 리뷰에 꼭 필요한 도구가 되었기에, 이번 자리를 통해 GitHub의 AI 마일스톤을 직접 듣고자 했습니다.”라고 기대를 표현했습니다.이 만남을 통해 얻은 인사이트를 중심으로 AI 시대에 개발자가 가져야 할 역량과 기술 생태계의 변화 방향을 살펴 보겠습니다.“저의 커리어에는 항상 소프트웨어 개발에 대한 열정이 있었어요. 이 열정은 현재의 제가 되기 위한 완벽한 레시피였어요.”라고 Thomas는 말했습니다.Thomas의 어린 시절에는 컴퓨터를 사용하기 어려운 환경이었습니다. 1980년대 말이 되어서야 기본적인 커맨드가 가능한 첫 컴퓨터 Commodore 64를 구매했습니다. 1990년대 당시에는 스택오버플로우 같은 플랫폼이 없었기에, 코딩을 독학하며 해결하지 못한 문제들을 고민하면서 잠들곤 했습니다.고등학생이던 1998년에는 Todosoft라는 회사를 창업했는데요, 보험 소프트웨어를 플로피 디스크에 담아 판매했습니다. 대학 진학 후에는 자동차 회사에서 주행 보조 시스템을 개발했고, 이후 소프트웨어 개발에 대한 열정으로, 프리랜서 개발자로 전향하여 아이폰 앱을 제작했습니다.Thomas는 모바일 개발자를 위한 플랫폼 HockeyApp을 창업했고, 이 회사가 Microsoft에 인수되면서 Microsoft와의 인연이 시작되었습니다. 2018년 Microsoft가 GitHub를 인수하면서 Thomas는 GitHub의 VP(부사장)와 CPO(최고제품책임자)를 거쳐 현재의 CEO(최고경영자)가 되었습니다.어린 시절부터 경영자가 된 지금까지, 기술과 시대는 변화했지만, Thomas는 시대를 관통하여 항상 소프트웨어 개발에 대한 애정과 열정을 가지고 도전해 온 것이 인상적이었습니다. 이런 배경이 있기에 Thomas는 ‘GitHub는 언제나 개발자를 최우선으로 두는 회사’라고 자신 있게 말할 수 있었습니다.AI 에이전트의 현재Thomas는 Copilot의 Second phase로서 2025년의 로드맵을 공유했습니다. 이 새로운 단계는 크게 세 가지 방향성을 갖고 있다고 합니다. ➊ Multiple Model 활용, ➋ AI 에이전트 기능 강화, ➌ AI Native 개발 환경 구축입니다. 이어서 Thomas는 코파일럿의 초기 버전부터 현재까지의 발전 과정을 소개하며, Agent Mode의 데모를 시연했습니다.GD는 Copilot 사용으로 개발자 생산성이 높아졌지만, 역설적으로 코딩 생산성 향상으로 인해

데브시스터즈에서 마주하고 있는 기술적인 문제를 공유하고 어떻게 풀어가고 있는지 경험을 나누는 행사 ‘데브시스터즈 엔지니어링 데이’를 소개합니다.안녕하세요. 데브시스터즈 기술본부에서 조직문화, 개발문화를 가꾸고 있는 전경아입니다. 이번 글에서는 2025년 2월 13일에 진행했던 데브시스터즈 엔지니어링 데이 - Infra/SRE에 대해 소개해드리고, 발표 영상도 공유하고자 합니다.데브시스터즈에서 서비스중인 게임은 유저 여러분들께서 많은 사랑을 보내주시는 만큼 매일 대규모 트래픽이 발생하고 있습니다. 그 속에서 견고히 서비스를 지탱해나가는 Infra/SRE 분야에서 마주치는 기술적인 문제를 어떻게 해결해나가고 있는지 소개해 드리고자 이번 데브시스터즈 엔지니어링 데이 - Infra/SRE 행사를 기획하였습니다.데브시스터즈와 같은 게임업계부터 하드웨어 제조사까지 다양한 업계에서 관심있는 분들이 모여 적극적으로 소통해주셔서 저희도 준비한 행사를 잘 진행할 수 있었습니다.우리가 생각하는 ‘ 서비스 장애’란 무엇인지부터, 많은 수의 게임을 운영하는 데브시스터즈의 모든 개발팀에 통용되는 장애 대응 원칙을 크게 장애 대응 원칙과 방법, 알람 티어링 권장 체계, 효과적인 장애 대응 방법 세 부분으로 나누어서 데브시스터즈에서 발생했던 실제 사례와 함께 자세히 소개해주셨습니다.발표에서 QR 코드로 소개해주셨던 기술블로그 포스팅도 함께 공유 드립니다.발표 2 - Dalgona: 쿠버네티스 인프라 표준화의 여정데브시스터즈는 다양한 게임을 많은 수의 쿠버네티스 클러스터에서 관리하고 있습니다. 그러나 클러스터 수가 점차 증가하면서 쿠버네티스 레벨에서의 권한 관리가 어려워지거나 클러스터 유지보수 비용이 증가하는 문제가 있었습니다. 또한, 중앙 인프라 조직은 초기에 AWS 에서 로드 밸런서로 Classic Load Balancer(ELB)를 사용하다가 점차 Global Accelerator(GA)와 Network Load Balancer(NLB)로 전환했습니다. 그러나 이러한 최신 기술과 노하우가 조직 전체에 효과적으로 공유되지 않아, 게임 라이브팀은 여전히 기능이 제한적인 ELB를 계속 사용하는 등 노하우가 제대로 전파되지 않는 등의 상황도 발생하였습니다. 이런 현상을 해결하고 중앙 인프라 조직이 전사 쿠버네티스 클러스터를 효율적으로 관리하기 위해 인프라 형상을 표준화한 이야기와 함께 그 과정에서 어떤 고민을 하였는지, 데브시스터즈의 플랫폼 엔지니어링은 앞으로 어떤 계획이 있는지 소개해주셨습니다.발표 3 - 게임팀을 위한 궁극의 배포 시스템 만들기Argo Workflow로 기획자와 서버 개발자 모두 중앙 인프라 조직의 도움을 받지 않고 사용할 수 있는 배포 시스템을 개발한 과정을 소개해주셨습니다. 기존 배포 툴은 도커 이미지 태그 형태가 고정되고 서버팀에서 환경 변수 수정이 직접 불가능하여 중앙 인프라 조직의 개입이 필수였고, 차트 설치 한 단계로 모든 배포를 해야 하여 Hook으로 제한적인 분리만 가능한 등의 한계점이 있었는데요, 이런 어려움 속에서 어떤 점을 고려하

안녕하세요. SK텔레콤 AI Comm개발본부 소속 고유경입니다. 저희 본부에서는 에이닷전화 서비스의 지속적인 발전을 위해 다양한 기술을 개발하고 있습니다.최근 생성형 AI와 LLM의 발전이 주목받고 있지만, 모든 NLP 작업에서 LLM이 항상 최선의 선택이 되는 것은 아닙니다. 특히, 사용자 프라이버시 보호가 중요한 서비스나 인터넷 연결이 원활하지 않은 환경에서는 서버를 거치지 않고 단말기에서 직접 추론할 수 있는 온디바이스 모델이 현실적인 대안이 됩니다. 또한, 텍스트 분류와 같이 비교적 명확한 태스크를 수행하는 경우, LLM을 단말에서 실행하는 것은 과도한 자원 소모를 초래할 수 있습니다. 이에 반해 BERT 계열의 경량화된 모델은 상대적으로 적은 연산 비용으로도 충분한 성능을 발휘할 수 있어 온디바이스 AI 서비스에 적합한 솔루션이 될 수 있습니다.이번 포스팅에서는 한국어 모델 중 KoBERT를 경량화한 DistilKoBERT를 이용하여 스팸 문자를 분류하는 모델을 만들고, 이를 TensorFlow Lite로 변환한 뒤 안드로이드 단말에서 실행하기까지의 과정을 살펴보겠습니다.스팸 문자 분류 모델 학습 및 평가를 위해 저희 본부에서 자체 확보/생성한 정상 문자 3,718건과 한국인터넷진흥원의 휴대전화 스팸트랩 문자 데이터에서 샘플링한 스팸 문자 3,718건을 결합하여 총 7,436건의 데이터셋을 구축하였습니다.표 1에서 확인할 수 있듯이, 정상 문자는 일반적인 대화나 서비스 안내 메시지로 구성되어 있으며, 스팸 문자는 광고·사기 문구 및 URL 링크가 포함된 경우가 많습니다.전체 데이터를 각각 4,758/1,190/1,488건으로 분절하여 학습, 검증, 평가용 데이터셋을 구성하겠습니다. 문자 메시지를 토크나이징하고 HuggingFace Datasets 라이브러리를 활용해 모델 학습에 적합한 형태로 전처리합니다. 토크나이저는 이후 설명할 DistilKoBERT 모델의 토크나이저를 사용합니다.스팸 분류 모델로는 SKT의 KoBERT를 경량화한 DistilKoBERT를 활용하고자 합니다. DistilKoBERT는 지식 증류(Knowledge Distillation) 기법을 적용해 KoBERT 모델 대비 약 2배 작고 빠른 경량 모델로, 성능 저하를 최소화하면서도 추론 속도를 향상시킨 장점이 있습니다. (참고로 원조 DistilBERT는 BERT 대비 모델 크기를 40% 줄이고 속도를 60% 향상시키면서도 성능을 97% 이상 유지한 것으로 보고된 바 있습니다.)Hugging Face의 Transformers 라이브러리를 활용해 학습과 평가를 진행하겠습니다. monologg/distilkobert 모델을 불러와 출력층에 2개 클래스(정상/스팸)를 구분하는 classification head를 추가하여 분류 태스크에 맞게 파인튜닝합니다.학습 과정에서는 정확도(Accuracy)를 주요 지표로 모니터링하며 총 10 epoch 학습을 진행합니다. 실제 학습 결과, epoch이 진행될수록 Valid(검증) 정확도가 향상되다가 일정 시점 이후 성능이 약

2025년 1월 9일, Software Freedom Conservancy (SFC)는 독일의 네트워크 장비 제조업체 AVM을 상대로 제기한 소송이 마무리되었다고 발표했습니다.이 소송의 핵심은 GNU Lesser General Public License (LGPL) 버전 2.1에 명시된 사용자의 권리, 특히 설치 정보 제공 의무에 관한 것이었습니다.Sebastian Steck이라는 독일의 소프트웨어 개발자가 2021년 5월 AVM의 라우터를 구매한 후, AVM이 제공한 소스 코드로는 수정된 소프트웨어를 라우터에 재설치할 수 없다는 사실을 발견했습니다.Steck은 AVM에게 “uClibc, libblkid, libexif 및 libosip2 라이브러리의 완전한 소스 코드와 컴파일 및 설치 스크립트 제공"을 요구했습니다.AVM이 이를 시정하지 않자 Steck은 2023년 7월 베를린 법원에 소송을 제기했습니다.소송 결과, 독일 법원은 AVM에게 Steck의 변호사 비용을 지불하도록 결정했습니다. AVM은 이 결정에 대해 항소하지 않기로 결정했습니다.결정문은 소송 비용 부담을 명시하고 있으며, 이는 오픈소스 라이선스 준수 문제의 경제적 가치와 중요성을 반영합니다.2. 소송의 배경과 경과독일의 소프트웨어 개발자 Sebastian Steck은 2021년 5월, AVM사의 인기 제품인 Fritz!Box 4020 라우터를 구입했습니다.Steck은 이 라우터의 펌웨어에 사용된 소스 코드를 요청했는데, 여기서 문제가 발생했습니다.AVM이 제공한 소스 코드로는 라우터에 수정된 소프트웨어를 다시 설치할 수 없었던 것입니다.이 소송의 중요한 특징은 Sebastian Steck이 LGPL-2.1 소프트웨어의 저작권자가 아님에도 불구하고 소송을 제기할 수 있었다는 점입니다.이는 LGPL-2.1 라이선스가 제3자를 위한 계약의 성격을 가지고 있기 때문입니다. 소장에 따르면 사용자도 LGPL-2.1에 따라 소스 코드를 받을 권리를 갖게 됩니다:이러한 법적 근거는 오픈소스 소프트웨어 사용자의 권리를 크게 강화합니다. 제조업체가 라이선스 의무를 제대로 이행하지 않을 경우, 저작권자뿐만 아니라 일반 사용자도 법적 조치를 취할 수 있게 되었습니다.• None 2021년 5월 7일: Steck이 AVM에 Fritz!Box 4020의 펌웨어 버전 6.83 소스 코드를 요청• None 2021년 5월 11일: AVM 자회사가 소스 코드 다운로드 링크 제공• None 2021년 5월 14일: Steck이 제공된 소스 코드의 불완전성을 지적하고 시정 요구• None 2023년 1월 12일: Steck의 변호인이 AVM에 법적 상황을 설명하고 소스 코드 시정 요구• None 2023년 3월 9일: Steck이 펌웨어 버전 7.02의 소스 코드도 추가로 요청• None 2023년 7월 27일: Steck이 베를린 지방법원에 소송 제기• None 소송 제기 수개월 후: AVM이 Steck에게 요청받은 모든 소스 코드를 제공. “라이브러리 설치를 제어하는 스크립트"도 포함• None 20

주요내용25년 4월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.A Categorical Archive of ChatGPT FailuresChatGPT와 같은 대형 언어 모델의 한계를 분석한 내용이다. 논리는 크게 11개의 실패 유형으로 구분되며, 논리적 추론, 수학적 계산, 사실 오류, 편견 및 차별, 코딩 오류 등 다양한 영역에서 제한이 발견된다.프롬프트 엔지니어링 가이드프롬프트 엔지니어링은 다양한 애플리케이션과 연구 주제에 언어 모델(LMs)을 효율적으로 사용하기 위해 프롬프트를 개발하고 최적화하는 비교적 새로운 분야이다.Vibe Coding Is The Future최근 개발자들 사이에서 가장 뜨거운 이슈 중 하나로 꼽히는 Vibe Coding은, 인공지능에 의존하는 새로운 프로그래밍 기법으로 Wikipedia에서 소개되고 있다.Vanilla Web: You Don't Need that Library새로운 웹 라이브러리가 끊임없이 등장하여 이전의 코딩 딜레마를 해결해 줄 것을 약속한다. 하지만 기본을 다시 살펴본다면 어떨까?>> FE News 25년 4월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다.매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다.▷ 구독하기

안녕하세요 상용개발센터 CV AI LAB 조재흥 연구원입니다. CV(Commercial Vehicle)  AI LAB은 AI,LLM 기술의 PoC(Proof Of Concept)를 in-house로 개발 및 검증하는 그룹입니다. 이번 포스팅에서는 자연어 처리(NLP) 모델에서 핵심적으로 사용되는 토크나이저(Tokenizer)에 대해 살펴보고, 특히 BPE(Byte Pair Encoding) 기반의 언어모델(LLM)에서 한국어를 처리할 때 발생할 수 있는 문제와 해결 방안을 다뤄보겠습니다.토크나이저란 무엇인가요?토크나이저는 자연어 처리 과정에서 텍스트를 의미를 가진 최소 단위인 토큰(Token) 으로 나누는 전처리 과정입니다. 토큰은 상황에 따라 단어나 형태소 등 다양한 단위로 설정할 수 있으며, 이는 모델 성능에 직접적인 영향을 미칩니다.토크나이저의 종류 및 예시대표적으로 사용되는 토크나이저의 종류를 살펴보겠습니다.Whitespace공백을 기준으로 단어를 구분합니다.영어 등 공백 기반 언어에 적합합니다.["I", "love", "natural", "language", "process", "using", "transformer."]WordPiece단어를 하위 단위(Subword)로 분할하여 사용합니다.자주 등장하는 부분을 서브워드로 병합하여 활용합니다.["I", "love", "natural", "language", "process", "using", "transform", "##er", "."]SentencePiece언어에 구애받지 않고 원본 텍스트에서 직접 토큰을 추출합니다.다국어 모델 구축에 매우 적합합니다.[" I", " love", " natural", " language", " process", " using", " transform", "er", "."]BPE(Byte Pair Encoding)자주 등장하는 문자 쌍을 병합하여 점차적으로 토큰을 형성합니다.유연성이 높으며, 특히 많은 언어와 도메인에서 범용적으로 활용됩니다.["I", "love", "natural", "language", "pro", "cess", "using", "transform", "er", "."]좋은 토크나이저란?좋은 토크나이저를 선정하기 위해서는 다음의 기준을 고려해야 합니다.OOV(Out of Vocabulary) 최소화: 모르는 단어의 발생을 최소화해야 합니다.어휘집(Vocabulary) 크기 최적화: 어휘집의 크기가 커질수록 표현력이 증가하지만, 연산량과 비용도 증가합니다.다국어, 다도메인 지원: 다양한 언어 및 전문 분야에 적용 가능해야 합니다.속도와 구현의 편의성: 성능 최적화를 위해 HuggingFace Tokenizers 등 고성능 라이브러리를 선택하거나 CUDA 기반의 직접 구현 방식을 사용할 수 있습니다.특히 OOV(Out of Vocabulary) 최소화와 어휘집(Vocabulary) 크기 최적화는 토크나이저 선정 시 가장 중요한 기준입니다. 이 두 기준은 언어모델의 성능과 연산 효율성에 직접적인 영향을 주기 때문인데, 언어모델의 동작 방식과 토크나이저의 연관성을 이해하며 자세히 살펴보겠습니다.1) 언어모델의 학습 및 예측 과정 소개언어모델은 입력된 자연어를 기반으로 통계적으로 가장 적절한 출력을 예측하는 모델입니다. 모델의 입력과 출력은 토큰(Token)이라는 최소 의미 단위를 통해 이뤄지며, 각각의 토큰은 고유한 인덱스를 가지고 있습니다.예를 들어, Vocab 크기(vocab_size)가 3이고 최대 시퀀스 길이(max_sequence_length)가 3일 때를 가정해보겠습니다. 여기에서는 설명을 단순화하기 위해 시작 토큰(start token)이나 종료 토큰(end token)과 같은 특수 토큰은 제외하고 순수한 문자 토큰만 고려합니다.토큰 사전(Vocab) 예시"다" 0"라" 1"마" 2모델의 출력은 각 토큰에 대한 확률을 나타내는 텐서(tensor) 형태로 나타납니다. 예시로 모델이 아래와 같은 확률값을 출력했다고 가정해 보겠습니다.모델의 예측 확률(예시):[[0.1, 0.8, 0.1], [0.15, 0.6, 0.25], [0.05, 0.75, 0.1]]실제 목표(Target)로 설정한 문장이 "라라라"라면, 이를 토큰 ID로 변환하면 [1, 1, 1]이 됩니다. 학습 과정에서는 이 목표값과 모델 출력 사이의 차이인 손실(loss)을 계산하여 평균을 내고, 이 손실을 최소화하는 방향으로 학습합니다.학습 후 실제 사용할 때는 모델이 출력한 텐서에서 확률이 가장 높은 값을 선택하여, 다시 토큰에서 문자로 디코딩(decoding)하여 최종 문장을 얻습니다. 위의 예시에서 결과는 [1, 1, 1]이 되고, 이를 다시 문자로 디코딩하면 "라라라"라는 결과를 얻게 됩니다.2) 어휘집(Vocab) 크기와 연산량의 관계위의 예시는 어휘집(Vocab)의 크기를 단순화하여 토큰이 3개("다", "라", "마")인 경우를 다뤘습니다. 이렇게 어휘집 크기가 작으면 모델은 적은 선택지(3개) 중에서만 다음 글자를 예측하면 되기 때문에 예측 작업이 비교적 쉽고 연산량도 적습니다.그러나 실제 자연어 처리에서는 더 많은 다양한 단어와 문자를 표현할 필요가 있습니다. 예를 들어, 실제 한국어 데이터에서는 수천 개에서 수만 개 이상의 단어나 글자 토큰을 포함한 어휘집을 사용하게 됩니다. 이렇게 어휘집의 크기(vocab_size)가 커진다는 것은 모델이 계산해야하는 토큰의 수가 증가한다는 의미입니다.어휘집의 크기가 커지면 모델의 출력 텐서 크기도 커지게 됩니다. 위의 예시처럼 토큰이 3개일 때는 각 시점(time step)에서 3개의 확률값만 출력하지만, 어휘집이 10,000개라면 각 시점마다 10,000개의 확률값을 출력하고, 그중에서 가장 확률이 높은 토큰을 선택하는 작업을 수행해야 합니다.어휘집(Vocab) 크기가 크면:언어모델이 더욱 다양한 표현과 단어를 이해하고 생성할 수 있습니다.어휘집에서 찾을 수 없는 단어(OOV, Out of Vocabulary)가 발생할 가능성을 최소화합니다.단점:어휘집의 크기가 커질수록 모델의 연산량과 메모리 사용량이 늘어나며, 학습과 추론에 더 많은 시