고등학생도 이해하는 Transformer (Deep Learning) #1고등학생도 이해하는 Transformer (Deep Learning) #2고등학생도 이해하는 Transformer (Deep Learning) #3자, 이번 시간에는 4차원 이상의 벡터의 내적에 대해 이해 하고 넘어가도록 합시다.되도록 수학연산은 안하도록 하겠습니다 ^^아래 4차원 Basis Vector를 머릿속으로 그려 봅시다.첫번째 Basis Vector는 [ 0.5000, 0.5000, 0.5000, 0.5000 ] 이거 두번째 벡터는 [ 0.6533, 0.2706, -0.2706, -0.6533 ] 세번째.... 네번째 벡터로 구성되어 있습니다.이러한 벡터의 모음을 행렬(Matrix) 라고 하지요4차원 공간을 만들 수없고, 4차원 공간을 만들어 4개의 Vector를 배치하는 것은 상상하기 힘듭니다.게다가 복잡한 소숫점 숫자만 나오니 어떻게 그림처럼 머릿속에 드려야 할 지 막막합니다.자, 그럼 그냥 단순히 그림으로 변환해 보겠습니다.4차원 공간 대신, 각 벡터를 2차원 공간에 그림으로 표시 해보겠습니다. 가로축은 각 벡터의 요소 순서이고, 세로축은 값의 크기 입니다.이 4개의 벡터를 Basis Vector라고 하고, 아래의 벡터를 입력으로 각 Basis Vector와 내적을 계산해 봅시다앞으로 수학공식을 이야기 하지 않는다고 하더니 벌써 계산하라네요.위의 입력 벡터를 내적 계산하기 전에 한번 내적의 의미를 다시 상기시켜 보시죠.계산은 제가 하겠습니다. 내적의 의미는 얼마나 유사한지, 영향을 주는지, 닮았는지를 나타내는 값입니다.자, 위의 입력 벡터를 그림으로 변환해볼까요?오른쪽 아래로 향하는 직선입니다. 그럼 Basis Vector 누구와 가장 유사한가요?제가 보기엔 Basis Vector 2가 가장 유사해 보입니다.역시, 예상대로 가장 유사한 형태인 Basis Vector 2와 가장 큰 값을 가지고 있네요.그림만 보고 정답을 맞추셨다면 내적의 의미를 정확히 이해 하신 것 입니다!!이 내적 값을 확률로 변환해 볼까요?우선 간단하게 아래와 같이 계산해 봅시다아래와 같이 Input_vector와 Basis Vector는 93% 유사하다고 볼 수 있습니다.실제로 Deep Learning 에서는 아래의 수식과 같이 Softmax함수를 이용하여 확률로 변환하는데, 위의 Simple 확률 수식에 지수의 Base를 Exp를 이용한 점만 차이가 있습니다.이러한 방법을 이용하여 어떤 부류를 분류하는 Classification 학습에서 입력 값과 각 카테고리 별 확률을 계산하여 학습하는데 이용 할 수 있습니다.다양한 입력 벡터를 만들어 머릿속으로 어느 Basis Vector 와 가장 내적 값이 클지(유사할지) 예상해보고 내적 계산해 보세요숙제 2 - 4차원을 넘어서 8차원에 도전해보세요아래는 8차원 DCT Matrix입니다. 아무 직선이나 곡선을 아래 DCT Basis Vector와 내적 값이 가장 큰 vector를 찾아 보세요위의 Basis Vector는 영상이나 오디오를 주

저는 에이닷 서비스 내 활용되는 디자인 시스템을 개발 및 관리하고 있습니다.이번에 신규 디자인 시스템을 구축하면서 많은 기술적 고민들이 있었는데요.이런 고민들을 해결했던 저만의 방법들을 공유드리기 위해 포스팅을 진행하려고 합니다.두번째 주제는 SwiftUI를 활용한 BottomSheet 제작기 입니다.일반적으로 iOS 앱에서 Bottom Sheet란 화면의 하단에서 슬라이드로 나타나는 패널을 지칭합니다.이 패널을 사용하여 사용자에게 추가적인 정보를 제공하거나 특정 작업을 수행하도록 유도합니다.보통 Action Sheet나 Modal과 비슷한 역할을 하지만, 화면 전체 차지하지 않고 필요에 따라 크기를 조절할 수 있습니다.사용자가 스와이프로 쉽게 닫거나, 원하는 만큼 드래그하여 더 많은 내용이나 옵션을 확인할 수도 있습니다.이러한 Bottom Sheet를 SwfitUI로 구현하려다보니 종종 곤란한 경우들이 있었는데요.이 글을 통해 SwiftUI에서 제공하는 옵션들과 여러 제약사항들을 소개드릴 예정입니다. 앞으로 커스텀 Bottom Sheet를 개발하려는 분들께 제 포스팅이 도움이 되었으면 좋겠습니다.포스팅은 다음과 같은 순서로 진행될 예정입니다.• None 에이닷에 적용된 BottomSheet• None Apple에서 제공하는 sheet, presentationDetent 옵션에이닷에 적용된 BottomSheet현재 에이닷 서비스에 적용된 바텀시트 입니다.이번 포스팅에서는 시트의 디자인이 아닌, 적용된 인터렉션에 초점을 맞춰 진행 할 예정입니다.이번 BottomSheet를 구현하면서 중점적으로 살펴봤던 요건들은 다음과 같습니다.• None 시트 내부 뷰의 높이에 맞춰 동적으로 시트의 높이가 결정되어야 합니다.• None 시트 전체 영역에서 드래그 제스쳐로 시트를 닫을 수 있어야 합니다.• None (내부 컨텐츠 사이즈가 큰 경우) 시트를 위로 스와이프 했을 때 확장형 시트가 제공되어야 합니다.• None 시트 내부 백그라운드에 커스텀 컬러가 적용되어야 합니다.Apple에서 제공하는 sheet, presentationDetent 옵션기존 bottomSheet의 경우, OS에서 제공하는 sheet modifier를 사용하지 않았습니다.살펴보니 별도의 커스텀 뷰와 네비게이터를 활용하여 구현이 되어 있었고, SwiftUI에서 제공하는 옵션은 사용되지 않았습니다.이번에 새롭게 bottomSheet를 리팩토링하면서, OS에서 제공되는 sheet modifier를 활용하는 것이 효율적이라고 판단했습니다.• None 드래그 제스쳐 & 확장형 시트를 옵션으로 제공합니다.• None 커스텀 네비게이터에 비해 자연스러운 애니메이션을 제공합니다.• None 하단에서 시트가 올라올 때 필요한 공간들을 OS차원에서 관리합니다. (ex. 키보드, safeArea 등)• None PresentationDetent 라는 옵션을 활용할 경우, 동적 높이 대응이 가능합니다.이런 점들을 고려하여, sheet modifier를 활용한 커스텀 bottomSheet를 제작하게 되

토스의 프론트엔드 리드(F-Lead)들은 어떻게 리더로서 성장했을까요?토스의 프론트엔드 리드(F-Lead) 노경모, 최경철 님이 전하는 조직의 성장과 함께 리더로서 성장 당한(?) 이야기그리고 시작된 고민과 경험들까지, 함께 들어보시죠!

고등학생도 이해하는 Transformer (Deep Learning) #1고등학생도 이해하는 Transformer (Deep Learning) #2원래 계획으로는 그래픽스 (Affine) Transform / Rotation / Reflection을 원리를 설명하고 다음을 진행하려고 하였으나,너무 그래픽스에 내용이 나오는 것 같아서 자제하는 것이 좋을 것 같아 간단히 설명하고 Transformer로 넘어가도록 하겠습니다.아래 그림을 보면 관점(카메라)의 이동과 객체의 이동과 회전에 대해 설명하고 있습니다.실제로는 매트릭스 연산, 즉 벡터의 내적들의 모음으로 되어 있고, 각 객체, 위치, 픽셀별로 계산을 수행해야 하기 때문에 내적연산이 빠르게 많이 일어나야 합니다.따라서 GPU는 이러한 그래픽스 연산 특화를 위해 병렬 내적 연산을 빠르게 수행 할 수 있게 설계가 되었습니다.아래 그림과 같이 RGB 컬러 스페이스(각 Basis Vector가 Red, Green, Blue를 나타냄)를 YUV, CMYK, HSI등 다른 컬러 스페이스로 변환할때도변환 메트릭스로 내적 연산을 이용해서 Basis Vector를 해당 컬러 스페이스로 변환하는데도 이용할 수 있습니다.필자는 과게에 YUV를 RGB로 컬러 스페이스 변환을 빠르게 하기 위해 OpenGL 쉐이더를 이용하여 빠르게 변환한 적이 있습니다.이는 GPU를 이용하여 빠르게 내적연산을 수행한것이고, 동일 연산을 CPU를 이용할 경우 모든 Pixel을 일일이 연산해야 하기에 성능이슈가 발생하였습니다.Deep Learning도 내적을 이용하여 많은 파라메터를 연산하므로 GPGPU(General Pupose GPU)를 이용하면 효율을 높일 수 있습니다.그래픽스는 3차원 공간이므로 머릿속으로 연산및 상상이 가능하기에 짧게만 이야기 하고 넘어가도록 하겠습니다.중요한것은 계속 강조 드리지만 내적의 의미 입니다.내적의 의미는 얼마나 유사한지, 영향을 주는지, 닮았는지는 나타냅니다.이것만 기억 이해 부탁드립니다,사실 앞으로 설명드릴 내용에서는 4차원 이상의 공간이여서 머릿속으로 이해하려면 조금 다른 접근 방법이 필요합니다.지금까지 3차원 공간에서 설명한것은 현실세계와 동일하지만 내적의 의미만 충분히 이해 한다면 쉽게 다차원도 이해 됩니다.앞으로는 왠만하면 수학 공식이 없으므로 기대 하셔도 됩니다 ^^

주요내용24년의 11월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.ViteConf 2024 ReplayViteConf 2024 에서 Evan You는 통합 툴체인 개발을 위한 회사 VoidZero를 발표했습니다. 이외에 인기있는 영상을 소개합니다.Next.js Conf24Next.js Conf24에서 Guillermo Rauch는 지난 1년 동안의 발전에 대해 커뮤니티의 공헌에 감사하는 마음을 전했습니다. 또 Next.js의 발전방향을 제시했습니다.Bundling Past, Present, and FutureAdobe에서 내부적으로 공유된 번들러의 과거, 현재, 미래에 대한 영상을 소개합니다. Node vs Bun: no backend performance differenceBack-End 사용에 있어 Node.js와 Bun의 벤치마크 테스트를 통해 확인 합니다. Back-End에서도 Bun이 빠를지 확인해 보실 수 있습니다.>> FE News 24년 11월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다.매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다.▷ 구독하기

프로젝트에 React Native를 도입할 때 크게 두 가지 방식이 있습니다.• None 프로젝트를 처음부터 React Native 로 개발한다.• None 현재 프로젝트에 부분적으로 React Native 를 도입한다.베트남의 토스앱을 개발하던 때는 운영되는 서비스를 잠시 멈추고 React Native로 새로 개발했었습니다. 그 시점에 앱의 기능이 그렇게 많지 않았기 때문에 가능했었습니다. 하지만 한국에서 서비스 하고 있는 토스앱은 그렇지 않았습니다.토스앱은 사실 크로스 플랫폼을 활용하기 위해 React Native를 도입했던 것은 아니었어요. 2021년 코로나가 극심할 때 식당이나 카페등 가게에 출입하기 위해 QR인증을 했는데요. 그때 QR인증을 위해 나라에서 지정한 업체의 SDK를 사용해야 했습니다. 그런데 그 업체가 React Native로 된 SDK를 전달해주었고, 그렇게 토스앱에 React Native가 포함되었습니다.이후 토스 내부에서도 웹서비스의 화면들을 더 빠르게 로드해야 한다는 요구사항과 겹쳐서 React를 다루는 Frontend 개발자들이 앱에 포함되어 있는 React Native를 살려 크로스 플랫폼 도구로 사용하게 되었습니다.토스와 비슷하게 많은 회사들이 각자 다른 이유로 운영 중인 서비스를 크로스 플랫폼으로 확장하고자 React Native를 도입하려고 할 거예요. 이런 경우에 CocoaPods를 사용하지 않고 React Native를 도입하는 방법을 알려드릴게요.React Native와 의존성 관리 도구운영되는 앱에 React Native를 도입하기로 결정했을 때 iOS 개발자의 입장을 생각해봅시다. React Native는 기본적으로 CocoaPods로 설치되도록 되어 있어요. 현재 운영하고 있는 서비스가 CocoaPods를 의존성 관리 도구로 사용하고 있다면, 큰 어려움 없이 React Native를 도입할 수 있습니다.하지만 iOS 개발 환경에는 CocoaPods 외에도 여러 가지의 의존성 관리 도구가 있습니다. 애플의 First Party인 Swift Package Manager 나, Carthage, Rome, 등등이 있습니다. 의존성 관리 도구는 아니지만 프로젝트 설정 관리 도구인 Tuist도 있습니다.그럼 CocoaPods 외에 다른 의존성 관리 도구를 사용하고 있다면 어떻게 React Native를 도입할 수 있을까요? 사용 중인 의존성 관리 도구와 CocoaPods를 함께 사용해야 합니다. CocoaPods를 사용하고 있지 않다면 CocoaPods를 추가하면 되고, CocoaPods를 이미 병행으로 사용하고 있다면 해당 Podfile에 React Native 관련 의존성을 추가하면 됩니다.하지만 이렇게 의존성 관리 도구를 병행하는 것은 좋은 방법이 아닙니다.왜 의존성 관리 도구를 하나만 써야 할까?두 가지 이상의 의존성 관리 도구를 사용한다면 각각의 의존성 관리 도구는 각자가 관리하는 의존성들만 Resolve할 뿐, 서로가 관리하고 있는 의존성을 알 수 없습니다. 즉 CocoaPods에서 A라는

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2024(10월)에서 발표되었던 세션을 공개합니다. 발표 내용네이버 홈피드의 컨텐츠들을 AI 를 활용해 좀 더 예쁘게 변경하여 CTR 을 높일 수 있도록 하는 것을 목표로 합니다.해당 과제를 완수하기 위해, 단일 AI 모델이 아닌 굉장히 다양한 AI 모델들이 접목되었으며 특히 HyperCLOVA-X 의 Visual Language Model 이라는 최신 기술을 접목하여 굉장히 높은 성능을 달성할 수 있었습니다.또한, 예쁘고 매력적인 썸네일을 만들기 위해 기술 적용 뿐만이 아니라, 어떠한 썸네일이 예쁜지? 등에 대한 기획적 분석 내용을 포함하고 있습니다.목차홈피드 썸네일을 이쁘게 만들기썸네일 개선 파이프라인 소개Vision Language Model 을 학습하고 서빙해보자LLM을 이용한 서비스 성능 평가 및 개선대상LLM & VLM 기술을 서비스에 접목해보고자 하는 기술 개발 분들홈피드가 어떠한 방식으로 개선되었으며, 어떻게 CTR 을 높이는 방향으로 기획되었는지 궁금하신 분들◎ NAVER ENGINEERING DAY란?NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2024(10월)의 일부 세션을 공개합니다.

안녕하세요. 리디 서비스백엔드팀 강규입니다.지난 글에서 Transactional Outbox 패턴을 사용해 메시지 발행을 보장하는 message-relay를 리디에서 어떻게 운영하고 있는지 소개했습니다.오늘은 message-relay를 운영하면서 겪은 다음 이슈를 개선한 내용을 소개하겠습니다.• 많은 양의 메시지가 message 테이블에 입력되는 상황에서 처리된 메시지의 삭제가 지연되었을 때 select 쿼리의 latency가 저하되는 문제• message 테이블에 대한 select for update 쿼리와 delete 쿼리의 latency가 간헐적으로 치솟는 문제기존에 message-relay는 처리할 메시지가 기록된 테이블로부터 메시지를 읽어서 kafka에 발행하고 테이블에 처리된 메시지 id를 기록하는 방식으로 동작했습니다. 이러한 구조에서는 message-relay가 처리할 메시지를 가져올 때, 아래의 쿼리가 사용됩니다.를 이용해서 쿼리 실행 계획을 확인해 봤습니다.nested loop anti join 방식으로 조회하면서, driving 테이블은 , driven 테이블은 테이블로 결정된 것을 알 수 있습니다. 테이블 row를 하나씩 읽어가면서 조건으로 테이블 row를 찾고 조건에 해당하는지 확인합니다.anti join이기 때문에 해당 조건을 만족하지 않는 row가 많을수록 실행 시간이 늘어날 것을 짐작할 수 있습니다. 테이블에 있는 처리된 메시지 삭제가 비동기로 동작했기 때문에 처리된 메시지의 삭제 속도가 메시지가 새로 쌓이는 속도보다 느려질 수 있었습니다.즉, 많은 양의 메시지가 테이블에 쌓여서 조건을 만족하는 row가 늘어나면 위 select 쿼리의 성능이 악화될 수 있었습니다.nested loop join으로 인해 성능 저하될 수 있는 것을 개선하기 위해서 left join을 제거하고 테이블 하나만 사용하도록 수정이 필요했고, 아래의 방법을 검토했습니다.• 처리된 메시지가 다시 처리되지 않도록 테이블에 column을 추가해서 메시지의 처리 상태를 변경해 두고 비동기적으로 삭제하는 방법• 처리가 완료된 메시지를 동기적으로 곧바로 삭제하는 방법처리가 완료된 메시지를 유지할 필요가 없기도 하고, 곧바로 삭제해도 delete 쿼리의 lock wait 문제가 발생하지 않도록 개선할 수 있게 되어 후자를 선택했습니다. delete 쿼리의 lock wait 개선과 관련된 내용은 이번 글에서 소개됩니다.결과적으로 테이블 하나만 사용하게 되면서 테이블 row의 개수에 영향을 받지 않고 일관된 select 쿼리 성능을 유지할 수 있었습니다. 또한 처리된 메시지의 삭제를 동기로 실행하게 되면서 전반적인 코드도 간결해졌습니다.가용성을 위해 message-relay node를 2대 운영하고 있기 때문에 테이블 row에 적절하게 lock을 설정해서 동일한 메시지에 대해서 중복으로 처리되지 않도록 하는 것이 중요합니다. 기존에는 MySQL record lock 용도로 분리된 테이블(이하 테이블)에 exclusive lock을 설정해서 동시성을 제어

슬슬 LLM 의 시대가 Multimodal LLM 의 시대로 넘어가고 있기 때문에, follow-up 이 필요한 시점이라고 생각합니다.• None Multimodal LLM architecture 들에는 어떤 것들이 있는지,• None 사용성을 위한 instruction tuning 은 어떻게 진행되는지,• None chatGPT hype 을 촉발한 RLHF 는 어떻게 적용되는지정리해보면서 어떤 기술들이 있는지, 어떤 데이터 셋들이 있는지, 어떤 방법론들이 있는지 알아보도록 하겠습니다.• None Multi-stage training / Freezing module / Architecture 등에서 차이• None Image grounded task 의 경우 bounding box (or free-form) 정보를 지원하는 방식• None 전부 Hallucination 을 줄이기 위한 방법으로 alignment method 들이 사용됨• None 전부 LLaVA 기반의 모델 사용 (다른 architecture 를 사용하지 않는 이유가 engineering 이슈 때문인지 LLaVA 의 성능이 압도적이어서 그런 것인지 알 수 없음)• None LoRA finetuning 이 일반적으로 사용됨

이 글에서는 이번에 출시한 'T멤버십 영화예매 에이전트'를 개발하면서 겪었던 경험들을 공유하려고 합니다.영화예매 에이전트는 'T멤버십 영화예매' 서비스에 LLM을 적용하여 대화로 쉽고 편리하게 영화를 예매할 수 있도록 도와주는 에이전트입니다.질문 이해와 답변을 생성하는 기존의 에이전트에서 나아가 실제로 Action('영화 예매')으로 이어질 수 있는 Actionable AI 에이전트로서 기존 서비스에 AI를 조금 더 직접적으로 도입하고자 하였습니다.본문에서는 개발시작 단계부터 부족했다고 느꼈던 점으로 시작하여, 이를 해결 하기 위해서 LLM Workflow를 도입했고, 이를 통해서 얻은 효과가 어떤 것인지를 예시와 함께 자세히 설명하겠습니다.처음에는 영화예매에 필요한 기본적인 '영화 조회', '극장 검색', '스케쥴 조회', '날짜 조회' 등의 함수를 정의하고 해당함수를 호출해서,그 함수의 결과값 기반으로 응답을 생성해준다면 말로 하는 영화예매의 프로세스를 만들 수 있을 것이라고 기대 했습니다.아래 그림은 실제로 프로젝트 초반에 간단하게 프로토타입했던 것을 도식화한 그림입니다.하지만 상용화의 문턱은 생각보다 높았습니다. 빠르고 정확한 응답은 기본이었고, 자연스러운 멀티턴 대화 관리가 필요했습니다.사용자의 개인 정보와 컨텍스트를 적절히 반영하면서도, 긴 대화에서 중요한 정보를 놓치지 않고 추적해야 했습니다.또한 영화 제목이나 극장명 같은 핵심 엔티티를 정확히 인식하는 것도 중요했습니다.이 모든 과정에서 여러 AI 모델들을 효과적으로 조합해 최적의 결과를 도출해야 했죠.이러한 복잡한 요구사항들을 통합적으로 관리하고 해결하기 위해, 체계적이고 유연한 LLM Workflow의 설계가 필수적이었습니다.이를 통해 단순한 프로토타입을 넘어, 실제 사용자들에게 가치 있는 서비스를 제공할 수 있는 기반을 마련하고자 했습니다.우선 크게 두가지를 중점적으로 고려하고자 하였습니다.• None 상태 관리(State management): 영화예매를 하기 위해서 꼭 필요한 정보인 "어떤 영화를", "언제", "어디서(or 어느 극장에서) 볼지" 를 발화에서 개체(entity)로 추출하고 앞으로 이어질 대화에 반영• None 주말에 용산 cgv에서 여자친구랑 영화 볼려고 이번 주말 베놈의 상영 시간표는 다음과 같습니다. 언제 관람하시겠어요? 아 그냥 코엑스 메박에서 내일 봐야겠다.• None 기대 결과: 내일 코엑스 메가박스에서 2명이서 베놈 영화 예매하기 위한 시간표 조회.• None 개인화 Context 반영: 더 나은 사용자 경험을 위해, 유저의 사전정보(최근 방문한 영화관, 선호극장)를 대화 흐름에 반영• None (홍대 CGV를 자주 찾는 유저) 영화 보고 싶어 "즐겨찾는 극장인 홍대 CGV에서 보실 수 있는 영화는 ‘베테랑2’, ‘조커’ 등이 있습니다. 어떤 영화를 보시겠어요?"최종적으로 위 두 꼭지를 LLM Flow에 이를 반영하기 위해 전체 LLM의 Action plan generation 을 수행하는 모델을 2가지로 나누었습니다.• None Ent