브라우저 기반 IPFS 네트워크에 관심이 많습니다.웹브라우저만으로 IPFS 네트워크를 구축할 수 있다면, 서버 없는 서비스(웹3 서비스)가 가능해질 것입니다.IPFS 블로그(https://blog.ipfs.tech/)에서 이와 관련된 기사를 엄선하여 요약합니다.• None SPA 또는 MPA 형태로 개발된 Dapp은 IPFS로 쉽게 배포할 수 있다• None Helia는 브라우저를 IPFS 노드로 만들어주는 라이브러리다• None Helia가 브라우저에서 제공하는 기능은 'CID 데이터 관리'와 'CID 데이터에 대한 Verified Retrieval' 2가지다• None CID 데이터 관리: 데이터를 CID 데이터로 만들고 해석하는 기능을 제공한다• None CID 데이터에 대한 Verified Retrieval: CID로 지정된 데이터를 Bitswap 또는 IPFS Gateway를 통해 가져올 수 있다• None 브라우저 IPFS 노드는 보통 수명주기가 짧기 때문에, CID 데이터를 업로드할 때 pinning 서비스를 이용하거나 직접 운영하는 IPFS 노드(서버)를 이용하는 것이 좋다• None IPFS Gateway는 브라우저에서 IPFS 데이터를 가져올 때 특히 유용한 기술이다• None IPFS 데이터에 대한 검증(Verification: IPFS Gateway가 전송한 데이터가 내가 요구한 그 데이터가 맞는가에 대한 검증)을 브라우저가 수행한다면, 브라우저는 IPFS Gateway를 신뢰하지 않더라도 문제 없이 이용할 수 있다 (Trustless Gateway 사용이 가능하다)• None 이를 위해 Interplanetary Shipyard팀(프로토콜랩으로부터 분사한 개발조직)이 @helia/verified-fetch 라이브러리를 개발/배포한다• None Shipyard팀의 다음 목표는 WebRTC와 WebTransport 프로토콜을 이용해서 브라우저에서 직접 Kubo IPFS 노드와 통신하는 것이다• None 우리(Interplanetary Shipyard)가 관심을 갖는 주제는 웹에서 IPFS를 사용하는 것이다• None 다시 말해 웹브라우저에서 다른 IPFS 노드에 연결할 수 있게 만드는 것이다• None 이를 위해 다음과 같은 프로젝트를 진행하고 있다• None Verified Fetch: 브라우저의 fetch API와 유사한 API를 제공, 이를 통해 IPFS 데이터를 검증/수신하는 기능을 제공한다• None Browser Transport: 브라우저에서 사용할 수 있는 WebRTC와 WebTransport 프로토콜을 기반으로 외부 IPFS 노드와 통신하는 기능을 제공한다• None AutoTLS: 브라우저는 보안 통신을 위해 CA 공인 인증서를 요구하나 IPFS 노드는 통상 인증서 없이 운영된다. AutoTLS는 이 갭을 메꾸는 기능을 한다• None Delegated Routing: 브라우저가 IPFS 기능을 호출할 때 이용할 수 있는 https://delegated-ipfs.dev/routing/v1 엔드포인트를

안녕하세요! 카카오엔터테인먼트의 DevRel, Sienna입니다.  2024년 12월, 뜨거운 열정과 즐거움으로 가득했던 ENTERTHON 2024가 성황리에 막을 내렸습니다. 엔터톤에서는 과연 어떤 흥미진진한 일들이 벌어졌을까요? 지금부터 생생한 순간들과 웃음이 넘쳤던 현장 이야기를 공유해 드릴게요.  ENTERTHON(엔터톤)이란? 카카오엔터테인먼트의 사내 해커톤(해킹과 마라톤의 합성어로, 다양한 직군들이 함께 모여 제한된 시간 내 결과물을 만들어내는 행사)으로, 카카오엔터 크루들이 치열하게 개발하고 즐겁게 교류하면서 새로운 아이디어를 제안하고 실행할 수 있는 채널입니다.    올해 엔터톤은 'Entertainment with AI'라는 주제로 열렸어요. 지난 9월에 진행된 사내 테크 컨퍼런스 'ENsighT: Working with AI'와 '4주 챌린지: Playing with AI'에 이어, 2024년 카카오엔터 AI 행사의 대미를 장식하는 하이라이트가 되었습니다. 이번 엔터톤에서는 아래 세 가지 분야 중 하나를 선택해, AI와 함께하는 카카오엔터테인먼트의 새로운 가치를 선보이는 무대로 펼쳐졌어요.  ENTRTHON 2024 : Entertainment with AI • AI로 더하는 엔터테인먼트 경험 (서비스/기능 개선)• AI로 혁신하는 엔터테인먼트 비즈니스 (신사업 발굴)• AI와 함께 일하는 카카오엔터테인먼트 (업무 효율화)  3회째를 맞은 이번 엔터톤은 더욱 특별해요 ⭐️  이번 엔터톤의 본선은 카카오 AI 캠퍼스에서 진행되었어요. 크루들은 이 곳에서 무박 2일 간 함께 모여 열정과 즐거움 속에서 작업에 몰입하였다고 하는데요, 24시간 동안 이어진 뜨거운 순간들을 ENTERTHON 2024 스케치 영상에서 만나보세요!    그럼 이제 엔터톤의 빛나는 순간들을 더 자세히 확인해 볼까요? ✨    카엔터 크루들! 캠퍼스로 모두 모이세요  2024년 12월 5일, 오전 10시. 카카오 AI 캠퍼스는 카카오엔터 크루들을 맞이하기 위해 설렘 가득한 분위기로 문을 열었어요. 바로 잠시 뒤 ENTERTHON 2024의 본선이 이곳에서 펼쳐질 예정이기 때문입니다. 현장은 크루들을 맞이할 완벽한 준비를 마치고 기대감으로 가득 차 있었어요. 현장에 도착한 참가자들을 가장 먼저 반긴 것은 웰컴키트였어요! 엔터톤 굿즈와 파트너사의 후원 상품들로 채워진 토트백을 받아 든 크루들은 설렘 가득한 표정으로 자리에 앉았습니다. 엔터톤 후드집업으로 갈아입은 크루들이 하나둘 늘어나며, 현장은 점점 활기로 채워져 갔어요.  ENTERTHON 2024, 시작합니다!  오전 11시가 되자 크루들의 뜨거운 기대 속에서 오프닝이 시작되었어요! 파트너사 소개를 시작으로, CTO 마커스가 엔터톤의 의미와 목표를 이야기하며, "이번 엔터톤이 엔터테인먼트와 AI 기술을 결합해 카카오엔터만의 차별화된 아이디어를 창출해 낼 수 있는 기회가 되길 바란다"며 크루들에게 응원의 메시지를 전했어요.  이어 37건의 아이디어 중 치열한 예선을 통과해 본선에 올라온 19팀의 

jerry.this 규모가 있는 서비스에서 캐싱 전략에 대한 고민은 꼭 필요한 것 같아요! 그 부분에 대해 너무 이해하기 쉽게 설명해 주셔서 캐싱을 적용해보고자 하는 분들은 꼭 읽어보셨으면 좋겠어요. 🙂geuru.geon 더 빠른 데이터 조회를 위해 캐시 시스템을 구현한 경험을 잘 풀어낸 글입니다. 평소 Spring 애플리케이션의 캐시 도입에 관심 있으셨다면 입문서로 읽어보는 것은 어떨까요?안녕하세요, 플랫폼서비스파티에서 통신중개 플랫폼 서버 개발을 맡고 있는 로이입니다. 통신중개 플랫폼은 사용자와 통신사 사이를 중개하는 서비스입니다. 여러 통신사의 요금제 상품을 나열해 보여주며, 사용자는 자신의 요구에 맞는 요금제를 선택하고 가입할 수 있습니다. 사용자는 요금제 구분, 데이터양, 통화량, 가격, 혜택 등 다양한 선택지를 비교하며 자신에게 맞는 요금제를 선택합니다. 이러한 특성으로 인해 상품, 통신사, 혜택 등에 대해 빈번한 조회 요청이 발생합니다.하지만, 이러한 단순 조회 작업에서 매번 데이터베이스를 호출하는 것은 비효율적일 수 있습니다. 이때 저희가 흔히 사용하는 캐시(Cache)를 조금 더 유용하게 사용하는 방법에 대해 다뤄보려고 합니다. 도입 배경부터 유연한 캐싱 시스템 및 데이터 최신화를 위한 메시지 시스템 구축 방법까지, 실제 구현 코드를 활용해 구체적으로 설명드리겠습니다.본격적으로 캐시 구현 방법을 살펴보기에 앞서 캐시란 무엇인지 정의를 우선 살펴보겠습니다. 캐시는 데이터를 더 빠르게 접근할 수 있는 고속 저장소입니다. 자주 사용하는 데이터나 반복적으로 조회되는 데이터를 캐시에 저장하면, 데이터베이스를 호출하지 않고도 데이터를 빠르게 반환할 수 있습니다. 이를 통해 조회 속도가 빨라지고 데이터베이스 부하가 크게 줄어들어 전체적인 서비스 성능이 향상됩니다.흔히 캐시를 이야기할 때, 우리는 Redis를 자주 언급하곤 합니다. 그렇다면, 왜 웹 애플리케이션 서버에 저장하는 방식의 로컬 캐시가 아닌 글로벌 캐시인 Redis를 먼저 떠올릴까요?근래의 서비스는 고가용성을 위해 Scale-Out 하여 동일한 서버를 2대 이상 운영하는 경우가 많습니다. 이때, 로컬 캐시만을 사용한다면 다음 그림에서 볼 수 있듯이 각 서버 간 데이터 정합성 문제로 인해 서비스 운영에 문제를 일으킬 수 있습니다.글로벌 캐시인 Redis를 사용할 경우, 서버 간 데이터 공유가 가능하므로 두 Client 모두 같은 데이터를 바라봅니다. 하지만 로컬 캐시를 사용할 경우, 서버 간 데이터 공유가 불가능하기 때문에 캐싱된 데이터에 따라 서버 간 데이터 불일치 문제가 발생할 수 있습니다.그럼에도 불구하고, 로컬 캐시는 다음과 같은 장점이 있어 무시할 수 없습니다.• 웹 서버가 조회를 위해 네트워크를 트래픽을 사용하지 않기 때문에 빠른 응답 속도• 외부 서비스의 지연 의존도 감소저희 서비스는 앞서 말씀드린 것처럼 중개 서비스이기 때문에 한번 등록된 통신사 정보나 상품과 같은 자주 변화하지 않는 데이터에 대한 잦은 조회가 발생합니다. 또한, 데이터가 변경되더라도 각 서버

소프트웨어 개발에서 결합도(Coupling)를 낮추고 응집도(Cohesion)를 높이는 것은 유지보수성과 확장성을 향상시키는 핵심 전략입니다.특히 웹 애플리케이션 개발에서 모듈간의 결합도를 낮추면 코드의 재사용성과 테스트 용이성이 크게 향상됩니다.이번 글에서는 FastAPI 프로젝트에서 파일들을 service 구현 그룹과 router 구현 그룹으로 그룹핑하여 결합도를 낮추는 방법을 살펴보겠습니다.결합도를 낮추는 아키텍처의 필요성높은 결합도가 초래하는 위험아키텍처 설계를 소홀히 하거나 결합도를 낮추는 전략을 고려하지 않으면 다음과 같은 문제들이 발생할 수 있습니다:• None 유지보수성 저하: 한 모듈의 변경이 다른 모듈에 연쇄적으로 영향을 미쳐 수정 범위가 넓어집니다.• None 예시: 데이터베이스 스키마 변경 시, 비즈니스 로직과 API 레이어 모두를 수정해야 하는 상황이 발생합니다.• None 확장성 제한: 새로운 기능을 추가하거나 변경하기 어려워집니다.• None 예시: 새로운 API 엔드포인트를 추가하려면 기존 모듈들을 대폭 수정해야 합니다.• None 재사용성 감소: 특정 기능을 다른 프로젝트나 모듈에서 재사용하기 어렵습니다.• None 예시: 다른 프로젝트에서 비슷한 기능이 필요해도 기존 코드를 활용할 수 없습니다.• None 협업 장애: 팀원 간 작업이 겹치거나 충돌하여 생산성이 떨어집니다.• None 예시: 여러 개발자가 동일한 파일을 수정하면서 충돌이 빈번하게 발생합니다.• None 테스트 어려움: 모듈간 의존성이 높아 개별적인 단위 테스트가 어렵습니다.• None 예시: 서비스 레이어를 테스트하려면 데이터베이스와 API 레이어까지 모두 설정해야 합니다.이러한 문제를 해결하기 위해 결합도를 낮추는 아키텍처가 필요합니다.FastAPI는 Python의 최신 기능과 표준을 활용하여 빠르고 효율적인 API를 구축할 수 있게 해주는 프레임워크입니다. 주요 특징은 다음과 같습니다:• None 고성능: 비동기 지원으로 높은 성능을 제공합니다.• None 타입 힌트 기반 개발: Python의 타입 힌트를 활용하여 코드의 가독성과 안정성을 높입니다.• None 자동 문서화: Swagger UI 및 ReDoc을 통한 자동 API 문서 생성을 지원합니다.• None 개발 생산성 향상: 최소한의 코드로 강력한 기능을 구현할 수 있습니다.하지만 이러한 장점을 최대한 활용하려면, 모듈 간 결합도를 낮추고 응집도를 높이는 아키텍처 설계가 필요합니다.역할: 비즈니스 로직과 데이터 처리를 담당하는 핵심 그룹입니다. 데이터베이스와의 상호 작용 및 데이터 가공 로직을 포함합니다.역할: 클라이언트와의 통신을 담당하는 그룹입니다. 클라이언트의 요청을 받아 서비스 그룹의 기능을 호출하여 데이터를 처리하고, 결과를 클라이언트에 응답합니다.결합도를 낮추는 아키텍처의 이점개발자 민수는 비즈니스 로직에 새로운 할인 정책을 적용해야 했습니다.서비스 레이어에서 로직을 수정했지만, router 레이어와 독립적이기 때문에 다른 팀원들이 작업 중인 API 엔드포인트 코드에는

안녕하세요. 토스증권 실시간 데이터팀 송지수입니다.Kafka 데이터센터 이중화 1편에서 소개된 것처럼, 토스증권은 현재 Active-Active 구성으로 Kafka를 운영하고 있습니다. 오늘은 Active-Active를 유지하기 위해 필요한 양방향 데이터 미러링에 대해 소개하려고 합니다.Apache Kafka에서 제공하는 MirrorMaker2(MM2) 등 다양한 오픈소스 데이터 미러링 도구가 있습니다. 이러한 도구들은 클러스터 간 데이터 복제를 손쉽게 구현할 수 있도록 설계되었습니다.MM2는 Kafka Connect 프레임워크 중 Source Connector 기반으로 동작하며, 두 가지 주요 기능을 제공합니다.• None 데이터 전송: Source Cluster(A)에서 발생한 데이터를 Target Cluster(B)로 복제.• None 오프셋 관리: A와 B 간 오프셋 차이를 Source Cluster(A)에 MM2용 내부 토픽으로 저장.MM2를 사용하면, 복제된 토픽 이름에 Source Cluster의 alias(접두사)가 자동으로 추가됩니다. 예를 들어, A 클러스터의 은 B 클러스터에서 로 미러링됩니다.MM2를 이용해서 양방향 미러링 구성이 가능하지만, 토스증권에서는 MM2를 사용하는 데 한계가 있었습니다. 각 Kafka에서 동일한 토픽 이름으로 미러링하여, 서버 개발자 등 Kafka 사용자들이 단일 토픽으로 데이터에 접근할 수 있는 환경을 제공하는 것이 목표였기 때문입니다. 어떤 데이터 센터의 Kafka에 프로듀스/컨슘하더라도 항상 동일한 한 개의 토픽 이름을 사용할 수 있다면, 사용자들이 Kafka 이중화 구성에 대해 인지하거나, 서버가 배포되는 데이터 센터를 신경쓰지 않아도 되기에, 사용자 편의성을 위해 동일한 토픽명으로 이중화 구성으로 하고자 하였습니다.토스증권에서 개발한 양방향 데이터 미러링 도구MM2와 같은 오픈소스는 토스증권 상황에 사용하기엔 한계점이 있어서 직접 만들기로 결정했습니다.토스증권의 환경에 맞춘 데이터 미러링 도구는 Kafka Connect 프레임워크 중 Sink Connector로 구현되었습니다. Sink Connector는 Kafka에서 데이터를 소비한 후, 외부 시스템에 데이터를 저장하는 역할을 수행합니다. 이 외부 시스템을 다른 데이터 센터(DC)의 Kafka로 설정하여, 양방향 데이터 복제를 가능하게 했습니다.저희 팀에서 개발한 양방향 데이터 미러링 도구는 크게 3가지 기능에 집중하였습니다.• None 수 천개의 잡을 모니터링을 위한 메트릭첫 번째 기능인 동일 토픽명으로의 양방향 데이터 미러링은 위 그림에서처럼 실제 사용자로는 DC1에는 message1, 2를 DC2에는 message 3을 전송하였지만, 결과적으로는 각 DC에 모두 message 1,2,3이 존재하도록 만들어야 합니다.즉, DC1으로 들어온 메시지는 DC2로, DC2로 들어온 메시지는 DC1으로 전송하면 됩니다. 그러나 이러한 구조만으로는 무한 루프 문제가 발생할 수 있습니다.• None 파티션 0번에 메시지가 기록됩니다.•

안녕하세요, 현대자동차그룹 통합보안센터 VCS팀 이나연, 장연석 연구원입니다.저희는 지난 2024 암호분석경진대회에 참여하여, 암호 분야의 다양한 문제를 해결해나간 경험을 공유하고자 합니다.이미지 출처 : https://cryptocontest.kr/암호분석경진대회는 정보보호학회가 주관하고 777 사령부가 후원하는 대회로, 암호분야에서의 다양한 문제를 푸는 방식으로 진행됩니다. 대회는 일반부와 고등부로 나뉘어져 진행되며, 이번 대회에서는 다양한 대학과 기관에서 총 65팀이 참여했다고 합니다. 더 자세한 대회 정보는 아래 주소를 참고 부탁드립니다.https://cryptocontest.kr/저희 모두 처음 참여하는 대회이다 보니, 이번에는 경험을 쌓자는 생각이었습니다. 하지만 팀원들과 토론하고 협업하면서 대회를 진행하다보니 어려운 문제들도 잘 풀어낼 수 있었고, 기대 이상의 결과를 얻을 수 있었던 것 같습니다.문제 유형 및 배경 지식문제는 총 6문제가 출제되었으며, 인공지능을 활용한 암호 분석, 부채널 분석, 공개키 암호 등을 포함한 넓은 범위의 암호 분야를 다루고 있습니다. 문제의 풀이를 다 적기엔 글이 너무 깊어질 것 같아, 문제에 대한 간단한 소개와 해결을 위해 필요한 개념들을 간단히 소개하려고 합니다.(문제의 전문은 대회 사이트에서 확인할 수 있고[링크], 혹시 풀이가 궁금하신 분들은 저희에게 연락해주시면 별도로 공유드리겠습니다. )문제 1. 인공지능을 활용한 LFSR 주기성 분석최근 인공지능(AI) 기술이 매우 빠르게 발전하고 있는데요. 암호학 분야에서도 AI를 활용한 암호 분석 기법이 활발히 연구되고 있으며 그 성능의 우수함이 실험적으로 증명되고 있습니다.1번 문제는 이러한 배경을 바탕으로 한 문제로 생각되며, LFSR 구조를 이해하고 DNN 을 활용해 LFSR의 주기성을 분석하는 것을 목표로 하고 있습니다.LFSR이란?LFSR (Linear Finite Shift Register) 은 순환적 비트열을 생성하는 장치로, 난수 생성에 주로 사용됩니다. 초기 상태와 피드백 함수는 LFSR 이 생성하는 시퀀스의 무작위성과 주기성을 결정하는 핵심요소입니다. 주기성을 정확히 파악하면 반복되는 패턴을 통해 시퀀스를 예측할 수 있기 때문에 주기성은 예측하기 어려워야 합니다.LFSR 의 예시 (4비트의 초기상태를 가지는 경우; 출처:wikipedia)DNN을 활용한 LFSR의 주기성 분석LFSR 의 주기성을 분석할 수 있는 방법으로는 대표적으로 Berlekamp-Massey 알고리즘이 있습니다. 특정 LSFR 에 사용된 polynomial 의 최대 degree 가 n 이라고 가정했을 때, 해당 알고리즘을 통해 2n 길이의 output bitstream 만으로도 사용된 최소 다항식을 정확하게 찾아낼 수 있는 방법입니다. 최소 다항식을 찾아내면 주기값은 알고 있는 것과 다름 없습니다. 하지만, 전체 비트스트림에서 오류가 존재하는 경우, 알고리즘의 정확도가 떨어진다는 단점이 있습니다.딥러닝을 활용한 LFSR 의 분석 / 비트 예측의 경우, 선행연구가 존재합니다. 연구자들은 해당 연구를 통해 2n 길이의 output bitstream 이 분석에 필요한 Berlekamp-Massy 알고리즘의 한계점을 극복하는 딥러닝 기반 LFSR의 다음 output steam bit를 예측하는 기법을 제안합니다. 이처럼 딥러닝을 활용한 암호분석 기법을 통해 기존 전통적인 방식의 결정론적 알고리즘이 갖는 한계점을 극복하고 높은 성능을 보여주기도 합니다.저희는 LFSR 데이터 특성을 분석하고 해당 특성에 적합한 네트워크를 선택하였습니다. 그 결과, 하나의 학습된 네트워크와 2n~5n 의 output bitstream 만으로 2~32 degree 에 대해 정확하게 주기를 예측할 수 있는 실험결과를 얻어 문제를 해결하였습니다.문제 2. 부채널 분석을 활용한 AES 키 복구2번 문제는 AES 블록암호의 구조를 이해하고, 부채널 분석을 통해 수학적으로 안전함이 증명된 암호가 동작하는 동안 소비되는 전력 신호를 활용하여 비밀키를 추출하는 것을 목표로 하고 있습니다.AES 란?현대 암호는 크게 대칭키/공개키 암호 시스템으로 나눌 수 있습니다. AES는 대칭키 암호 알고리즘의 하나로, NIST 표준암호로 지정되어 다양한 산업에서 널리 사용되고 있습니다. AES는 128비트, 192비트, 256비트의 키 길이를 지원하며, SubBytes, ShiftRows, MixColumns, AddRoundKey 단계를 반복하면서 암호화/복호화가 이루어집니다. 마지막 라운드에서는 MixColumns 과정이 생략됩니다. AES는 블록 단위로 데이터를 처리하며, 각 라운드마다 키와 데이터를 혼합하여 보안성을 높입니다. 또한, 높은 성능과 효율성을 제공하여 다양한 애플리케이션에서 널리 사용되고 있습니다.부채널 분석과 AES부채널 분석이란 설계자가 의도하지 않은 부가적인 정보(예: 소비 전력, 전자파 신호)를 활용하여 비밀 정보를 유출할 수 있는 분석 기법입니다. AES의 소비전력 기반 부채널 공격에서 가장 기본적인 방식은 S-Box 뒤의 중간값을 추측하는 것입니다. 공격자는 암호화 과정에서 S-Box의 출력을 통해 특정 바이트(또는 비트)의 값을 예측하고, 그 정보를 바탕으로 전력 소비 패턴을 분석하게 됩니다.이 과정에서 통계적 기법을 사용하여 중간값과 소비 전력 신호로부터 유의미한 정보를 추출하고, 이를 바탕으로 비밀 키 값을 추측할 수 있습니다. 암호 시스템을 대상으로 하는 부채널 분석은 여러 연구를 통해 그 강력함이 입증되었으며, 보안 취약점을 드러낼 수 있는 중요한 요소로 작용합니다.따라서 특정 제품에 암호 알고리즘을 적용할 때는 이런 부채널 분석 공격을 막기 위한 방어 메커니즘을 고려해야 합니다. 이렇게 하면 비밀 정보를 보호하고, 더 안전하게 암호를 사용할 수 있습니다.문제는 평문, 1라운드 일부, 2라운드의 전력 파형만으로 AES 알고리즘의 특징을 이용해 키를 유추함으로써 해결하였으며, 이 두 정보를 가지고 키를 찾아낼 수 있었습니다.출처: copilot문제 3. 역공학 기술을 활용한 암호기 분석3번 문제에서는 암호화 프

기술 공유를 넘어 네이버의 미래 비즈니스와 서비스 변화 방향을 제시한 'DAN 24'가 많은 분들의 관심과 참여로 성황리에 종료되었습니다. 개발자뿐만 아니라 다양한 직군의 참가자분이 함께 기술과 서비스와 관련된 이야기를 나누다 보니 열기가 가득했는데요. 함께해 주신 여러분들께 다시 한번 감사드립니다.모든 발표영상이 DAN 24 홈페이지와 PLAY NAVER 유튜브 채널에 공개 되었습니다. DAN 24 오프라인 현장에서 가장 참여율이 높았던 기술 세션들도 정리했으니 많은 관심 부탁드립니다.1. 여러분의 웹서비스에는 꼭 필요한 것만 있나요? 번들사이즈 최소화를 통한 웹 성능 개선 - NAVER FINANCIAL 김용찬 님수년간 운영된 서비스의 번들 사이즈를 최적화하여 성능을 크게 개선한 경험을 공유하고, 매일 여러 개의 PR이 생성되고 병합되는 저장소에서 꼭 필요한 코드만 최소한으로 포함시켜 사용자에게 효율적으로 서비스를 제공하는 방법을 소개합니다.2. 네이버페이 결제 시스템의 성장과 변화 - NAVER FINANCIAL 김진한 님손쉬운 확장을 위한 분산 DB와 EDA 적용, 무중단 결제를 위한 다양한 시도들과 함께 결제 서비스에 특화된 모니터링 및 SRE 활동들까지 네이버페이 성장을 견인하기 위한 기술의 변화와 경험을 공유합니다.3. 사용자 경험을 극대화하는 AI 기반 장소 추천 시스템: LLM과 유저 데이터의 융합 - NAVER 김창회/이준걸 님AI 기반의 장소 추천 시스템을 주제로 LLM을 추천 모델에 적용하는 과정에서 있었던 고민들과 실제 서비스 적용까지의 기술 노하우를 공유하고, 기존의 추천 모델/데이터와 어떻게 시너지를 내고 서비스 경험을 극대화할 수 있었는지를 소개합니다.1. 사람을 대신해야 진짜 AI지?: LLM 기반 임베딩부터 검색 품질 자동 평가 모델까지 - NAVER 권오준님Human 수준의 모델링을 위한 데이터 구축 방법론, 여러 모델의 아키텍처 및 장/단점, 학습 과정에서 발견한 노하우 등을 공유하고, 네이버에서 사용자의 검색 경험 향상을 위해 AI를 어떤 식으로 활용하고 있는지를 공유합니다.2. 벡터 검색의 정점에 오르다: 최적의 뉴럴 검색 엔진으로 업그레이드 하기 - NAVER 현화림/김인근 님ColBERT 및 후속 뉴럴 검색 모델들을 소개하고 각 모델을 자세히 들여다봅니다. 웹 검색에 대한 인하우스 검색 엔진 솔루션(NPP)의 부하 특성을 공유하며, 엔지니어링이 솔루션 성능에 어떤 영향을 미치는지 공유합니다.3. 당신의 PYTHON 모델이 이븐하게 추론하지 못하는 이유 [CPU 추론/모델서빙 PYTHON 딥다이브] - NAVER 김성렬 님Jupyter Notebook 위에서 추론하는 모델이 실 서버 환경에서 1초에 100,000번의 추론을 수행하기 위해 Python, ML Framework, Model Server 관련 어떤 지식이 필요한지를 공유합니다. [DAN 24] DEVIEW 세션 영상 더 보기 >>

bri.ghten Spring Cloud Stream 진입장벽을 낮춰주는 좋은 글입니다. 이 글을 읽고 간단하게 Spring Cloud Stream을 연습 삼아 써 보고 도입할 만한 부분이 있는지 생각해 보는 계기가 되었습니다.dory.m Spring Cloud Stream에 대해 들어보셨나요? KafkaListener의 대안이자 그 너머의 기능까지, 웨이드의 글이 풍부한 가이드가 되어줄 것입니다!wonny.p Spring Cloud Stream을 도입하려는 분에게 좋은 가이드가 되어 줄 문서라 생각합니다.안녕하세요. 카카오페이 정보플랫폼팀 웨이드입니다.정보플랫폼팀에서 카카오페이 내 다양한 서비스 데이터를 조합하여 외부 기관에 제출하는 업무를 맡고 있습니다.다양한 데이터를 쉽게 조합하기 위해서 Spring Cloud Stream, Kotlin을 사용하고 있습니다. 그중에서 Spring Cloud Stream을 활용하여 쉽게 데이터를 조합하고 추출하고 파이프라인으로 데이터를 연결하여 처리하는 방법에 대해서 공유하려고 합니다.Spring Cloud Stream은 메시지 기반 마이크로서비스 애플리케이션을 구축하기 위한 프레임워크입니다. Spring Boot 기반으로 Spring 애플리케이션을 만들고 Spring Integration을 사용하여 메시지 브로커에 대한 연결을 제공합니다.사용 방법은 라이브러리 디펜던시를 추가하면 준비가 완료됩니다. 를 사용하여 기능을 구현합니다. Function 외에 Supplier, Consumer도 가능합니다.다음은 간단한 예입니다.Spring Cloud Stream 구성 요소를 살펴보겠습니다.우리가 개발해야 하는 부분은 Application Core(function)이고 나머지 부분은 설정으로 이루어집니다. Binder를 통해서 Kafka, RabbitMQ 같은 메시지 브로커와 애플리케이션을 연결합니다. Binder는 추상화되어 있어서 쉽게 다른 Binder로 전환이 가능합니다.실제 도입하고 사용하는 방법은 다음 챕터에서 이야기하겠습니다.왜 도입했는가?다양한 데이터를 조합하기 위해서 spring-kafka 대신 Spring Cloud Stream을 선택했습니다.그렇다면 왜 Spring Cloud Stream을 선택하고 활용하게 되었을까요? 일단 요구 사항을 살펴보도록 하겠습니다.• 카카오페이 내 다양한 어드민 api를 활용하여 데이터 추출• 하둡을 비롯하여 다양한 데이터 소스에서 데이터 추출• 추출한 데이터를 바탕으로 데이터를 조합하고 필요하면 다른 어드민 api 호출익숙한 스트리밍 기반 기술 중 하나는 spring-kafka입니다. 아래 예제는 카프카로 메시지를 받아서 다시 메시지로 전송하는 예제입니다.spring-kafka는 low level로 개발하는 거라서 코딩 스타일 강제가 불가능합니다. 데이터 흐름을 코드 베이스로 파악해야 하는 어려움이 있습니다. 또한 잘못 코딩하게 되면 결합도가 높아집니다.Spring Cloud Stream은 데이터 흐름 제어나 코딩 스타일을 어느 정도 규격화 하는 것이 가능하고

안녕하세요, T멤버십서비스팀에서 백엔드 개발을 하고 있는 이연주입니다.studymate라는 좋은 기회로 회사동료분들과 함께 LLM 스터디를 진행하고 있고 스터디명은 딥그라운드입니다.딥그라운드에서 'LLM을 활용한 실전 AI 애플리케이션 개발' 이라는 책을 기준으로 좋은 동료분들과 같이 스터디를 진행하면서 LLM 관련 기본기를 다질 수 있었습니다.더나아가 스터디 시간에 실무에서 어떤 고민을 하시고 어떻게 적용하고 있는지를 공유하며 AI와 더욱 친숙해질 수 있었습니다.이번에 저는 10장, 임베딩 모델을 데이터로 압축하기 를 맡게되어 정리한 내용을 공유드리고자 합니다.AI 분야에서 텍스트를 숫자로 표현하기 위해 다양하게 연구되어 왔습니다.• None 텍스트를 숫자로 표현하는 방식• None 텍스트와 텍스트 의미를 숫자(벡터)로 표현하는 방식• None 텍스트 의미를 포함하여 임베딩 벡터로 변환하여 벡터유사도를 통해 의미상 유사한 문서를 검색할 수 있게 되었습니다. 대표적으로 sentene-transformers 라이브러리를 이용하여 의미 검색을 구현할 수 있습니다. 하지만 직접 문자열을 비교하는 키워드 검색 대비 검색관련도가 떨어지는 한계가 있습니다. 하이브리드 검색은 키워드 검색과 의미 검색을 조합해서 사용하여 이러한 한계를 보완할 수 있습니다.설명하기 앞서 임베딩이란 단어를 정확히 알고 가야합니다.책에서는 데이터의 의미를 압축한 숫자배열(백터) 로 설명하고 있습니다 즉, 고차원의 데이터를 저차원 벡터 공간으로 변환하여 데이터의 의미를 효과적으로 압축하는 기술입니다1. 텍스트를 숫자로 표현하는 방식• None 벡터의 차원은 어휘 크기와 같고 해당 단어의 인덱스만 1이고 나머지는 0• None 범주형 데이터 사이에 관계가 담기는 걸 방지하는 장점이자 단어 사이 관계를 표현할 수 없다는 한계 존재• None 문서를 단어의 출현 횟수로 이루어진 벡터로 표현• None 문서의 특성을 간단하게 나타낼 수 있지만, 단어 순서와 문맥 정보를 잃는 한계• None TF(단어 빈도)와 IDF(역문서 빈도)를 곱하여 계산• None 문서에서 흔한 단어는 가중치를 낮추고, 특정 문서에서 자주 등장하는 단어는 가중치 높임• None 주변 단어들의 분포를 이용해 단어의 의미 학습• None 유사한 의미를 가진 단어들은 벡터 공간에서 가까이 위치하게 됨• None• None 1-1~1-3 앞선 방식들에서 단어의 수만큼 차원이 커지는 한계를 해소하고자 데이터를 압축• None 단어와 단어 사이의 관계를 판단 가능해짐• None• None 두가지 모델은 입력(input)과 출력(output)이 서로 반대되어 있습니다.2. 텍스트와 텍스트 의미를 숫자(벡터)로 표현하는 방식단순히 단어에서 더 나아가 문장, 문단, 더 큰 텍스트 단위의 의미를 파악하고자 하는 방식이 연구되었습니다.문장을 임베딩 벡터로 변환하여 문장 사이 유사도를 계산하여 문장 의미를 확인하게 됩니다.문장 임베딩을 활용하여 전체 문장의 문맥을 고려할 수 있게되어 더 정확한 의미 표현이 가능하게 되었습니다.2

Image created by ChatGPT.안녕하세요 스푼랩스 오디오팀에서 안드로이드 라이브 스트리밍 SDK 개발을 담당하고 있는 Tom입니다. 최근 오디오팀에서 방송 관련 기능들을 테스트하기 위한 용도로 만든 안드로이드 데모앱에 대한 소개와 개발 과정에 대해 얘기해보겠습니다.데모앱 개발을 시작한 배경오디오팀은 다양한 방송 관련 기술을 연구하고 개발하며, 실시간 이슈 대응 및 모니터링을 통해 안정적인 서비스를 유지하는 역할을 담당하고 있습니다. WebRTC, RTMP, SRT 같은 스트리밍 기술은 물론이고, 라이브콜, 목소리 효과 등 고도화된 방송 기능의 개선 및 신규 기능 개발도 중요한 업무 중 하나입니다.“WebRTC 옵션을 조정하면 어떤 변화가 있을까?”“모니터링 기능을 추가하면 어떤 모습일까?”“목소리 효과를 몇 개까지 중첩할 수 있지?”“라이브 방송과 라이브콜 방송을 통합해볼 수 있을까?”이러한 요구사항을 테스트하기 위해 기존에는 스푼앱에 직접 기능을 추가하고 빌드 후 테스트를 진행했습니다. 하지만 스푼앱은 방송 기능 외에도 다양한 기능들을 포함하고 있는 방대한 애플리케이션이기 때문에, 작은 기능 하나를 실험하기 위해서도 많은 시간과 노력이 필요했습니다.• 복잡한 코드베이스: 스푼앱은 많은 기능을 포함하고 있어, 새로운 기능을 테스트할 환경을 추가하는 것 자체가 부담스러웠습니다.• 속도와 효율성 부족: 작은 테스트를 위해도 전체 앱을 빌드하고, 테스트하는 과정이 시간이 많이 걸렸습니다.• 기능 간 간섭 문제: 새로운 기능이 기존의 다른 기능에 영향을 미칠 가능성도 배제할 수 없었습니다.결과적으로, 오디오팀에서 실험하고자 하는 기능을 보다 빠르고 독립적으로 테스트할 수 있는 환경이 필요하다는 결론에 이르렀고, 데모앱 개발을 본격적으로 시작하게 되었습니다.데모앱 개발Image created by ChatGPT.기존에 오디오팀에서는 View 기반으로 작성된 데모앱을 사용하고 있었지만, 시간이 지나면서 유지보수가 어렵고 제대로 작동하지 않는 기능들이 많아졌습니다. 데모앱을 새롭게 개발하기로 결심한 시점에, 저는 안드로이드팀과 함께 Jetpack Compose 스터디를 진행하고 있었습니다. Compose의 간결한 선언형 UI 작성 방식과 XML을 대체할 수 있다는 점에 매료되어, 새로운 데모앱을 Compose로 개발하기로 결정했습니다.Compose Navigation으로 화면 전환Compose Navigation은 Kotlin 코드로 화면 전환을 선언적으로 작성할 수 있도록 도와주는 라이브러리입니다. 데모앱은 스플래시, 로그인, 권한 요청, 홈, 설정, 세부 기능 등으로 화면이 구성되었으며, 화면 전환 간에 필요한 다양한 로직을 Compose Navigation을 통해 간결하게 구현했습니다. 특히, ViewModel과의 자연스러운 통합 덕분에 화면 간 데이터 전달과 상태 관리가 직관적이고 체계적으로 이루어졌습니다.권한 요청과 같은 일회성 화면의 경우, 기존 View 기반 방식처럼 Fragment를 별도로 작성하지 않고 하나의 Compo