오랜만에 인사드립니다. 이번 포스팅에서 살펴볼 내용은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으로 제한적인 분리만 가능한 등의 한계점이 있었는데요, 이런 어려움 속에서 어떤 점을 고려하