저는 AI Comm Client 팀에서 에이닷 통화녹음과 에이닷 전화 iOS 개발을 하고 있는 이준영입니다.올해로 2년차 주니어 개발자가 되었는데요, 그간 한 일 중에서 가장 기억 남는 과제는 에이닷 watchOS 앱 개발입니다.Apple Watch는 올해로 출시한 지 10년이 되었습니다.하지만 부족한 하드웨어 스펙 등으로 인해 iPhone에 비해 제공할 수 있는 기능들이 부족해, 앱 개수도 적고 참고할 만한 개발 자료도 다소 적습니다.그렇다보니 개발하면서 여러 어려움을 겪었는데요, 이번 게시글에서는 Notification 관련 기능을 개발하며 겪었던 일들에 대해서 다뤄 보겠습니다.이번 게시글에서는, Apple에서 제공하는 Creating a watchOS app 샘플 프로젝트를 사용합니다.직접 빌드해서 확인해 보고 싶은 분들은, Apple Developer 사이트에서 해당 프로젝트를 다운로드 받으시면 됩니다.그리고 본 게시글은 아래 환경을 기준으로 작성된 내용이므로, 향후 Apple의 OS 업데이트에 따라 동작이 달라질 수 있습니다.마지막으로, 본 게시글을 이해하기 위해서는 SwiftUI에 대한 기본적인 이해가 필요합니다.만약 SwiftUI에 대해 잘 모르신다면, Apple의 Introducing SwiftUI를 먼저 보시는 것을 추천드립니다.Apple 공식 문서에서는, Notification이 iPhone과 Apple Watch 중 어디에 등장하는지에 대해 아래와 같이 설명하고 있습니다.위 설명에서 2번 항목을 보면, Apple Watch가 사용자의 손목에 착용되어 있고 잠금 해제된 경우에 Apple Watch로 알림이 전송된다고 나와 있습니다.시스템은 Apple Watch가 손목에 착용되어 있는 것은 어떻게 알 수 있을까요?iPhone의 Watch 앱을 보면, 손목 인식이라는 설정이 있습니다.설명만 읽어보면 암호 설정이 되어 있을 때 Apple Watch를 잠그는 것과 관련 있는 내용으로 보입니다.하지만 설명과는 다르게, 암호를 사용하지 않더라도 손목 인식 옵션은 켜고 끄는 것이 가능합니다.즉 이 옵션은 시스템이 실시간으로 Apple Watch 착용 여부를 판단하게 해 주는 것입니다.앞서 'Apple Watch가 사용자의 손목에 착용되어 있고 잠금 해제된 경우에 Apple Watch로 알림이 전송된다'고 말씀 드렸습니다.손목 인식이 꺼져 있으면 어떻게 될까요? 정답은 'iPhone과 Apple Watch에 모두 전송된다'입니다.Apple에서 위와 같이 동작하는 지에 대한 설명이 따로 없어, 제가 추론한 내용을 정리했습니다(공식적인 설명이 아니므로, 참고 부탁드립니다).Apple에서 말하는 iPhone의 잠금 상태, 그리고 Apple Watch의 잠금상태/손목 착용 여부는 곧 사용자가 현재 어떤 기기를 사용하고 있는지를 판단하기 위한 기준입니다.Apple Watch는 iPhone과 달리, 화면이 항상 켜져 있는 경우는 잘 없습니다.사용자들은 대부분 Apple Watch를 일반 시계처럼 착용하고 일부 필요한 경우에만 화면을 터치하기 때

이번시간에는 Custom ItemReader와 ItemWriter에 대해서 알아볼 것이다.스프링 배치는 사전에 구현된 내장 ItemReader와 ItemWriter를 가지고 있어서 일반적인 케이스는 모두 수용이 가능하다.그러나 특이 케이스나, 비즈니스 로직에 딱 맞는 배치를 수행하기 위해서 Customize가 필요하다.- 우선 QueryDsl을 이용하여 Paging하여 데이터베이스의 값을 읽어 들이는 QuerydslPagingItemReader를 구현해 볼 것이다.- 그리고 CustomItemWriter를 구현하여 타 서비스를 호출하는 샘플을 만들어 보자.• None Querydsl은 SpringBatch의 공식 ItemReader이 아니다.• None 우리는 AbstractPagingItemReader를 이용하여 Querydsl 을 활용할 수 있도록 ItemReader를 만들 것이다.• None Querydsl 기능 활용: Querydsl의 강력하고 유연한 쿼리 기능을 사용하여 데이터를 효율적으로 읽을 수 있다.• None JPA 엔티티 추상화: JPA 엔티티에 직접 의존하지 않고 추상화된 쿼리를 작성하여 코드 유지 관리성을 높일 수 있다.• None 동적 쿼리 지원: 런타임 시 조건에 따라 동적으로 쿼리를 생성할 수 있다.• None• None 위 선언은 AbstractPagingItemReader 를 상속받았다.• None AbstractPagingItemReader은 어댑터 패턴으로, 상속받는 쪽은 doReadPage만 구현하면 된다.• None• None 위 내용과 같이 우리에게 필요한 부분은 name, entityManagerFactory, querySupplier, chunkSize 이다.• None name: ItemReader를 구분하기 위한 이름이다.• None entityManagerFactory: JPA를 이용하기 위해서 entityManagerFactory 를 전달한다.• None Function: 이는 JPAQuery를 생성하기 위한 Functional Interface 이다.• None 입력 파라미터로 JPAQueryFactory 를 입력으로 전달 받는다.• None 반환값은 JPAQuery 형태의 queryDSL 쿼리가 된다.• None chunkSize: 한번에 페이징 처리할 페이지 크기이다.• None alwaysReadFromZero: 항상 0부터 페이징을 읽을지 여부를 지정한다. 만약 paging 처리된 데이터 자체를 수정하는경우 배치처리 누락이 발생할 수 있으므로 이를 해결하기 위한 방안으로 사용된다.• None• None doClose는 기본적으로 AbstractPagingItemReader를 자체 구현되어 있지만 EntityManager자원을 해제하기 위해서 em.close() 를 수행한다.• None• None 실제로 우리가 구현해야할 추상 메소드이다.• None JPAQueryFactory를 통해서 함수형 인터페이스로 지정된 queryDSL에 적용할 QueryFactory이다.• None 만약

AWS OpenSearch에 의미를 담아보자 (KNN)안녕하세요.스푼랩스 Business Platform Team의 임용근(Whale 🐳)입니다.지난 몇개월동안 회사에 많은 이벤트가 있었는데요.사명이 SpoonRadio에서 SpoonLabs로 변경되었습니다. 👏회사에 경사가 있었고요. (스푼랩스 투자유치) 💰새로운 서비스도 출시했습니다! (Vigloo) 🎬그리고 좋은 기회가 생겨 AWS OpenSearch roadshow 2024에서 발표도 했습니다. 📢(발표 내용 → AWS Opensearch(ES 호환) 한글 뽀개기(초성 추출) )부끄럽네요. 가운데 오버로드 같은게 저입니다. 🤣막연하게 2024년 가기 전에 블로그를 하나 더 쓰고싶은 생각이 들었습니다.의무적으로 쓴다는 느낌보다 평소 관심 있었고 개인적으로 공부해보고 싶었던 내용을 초심자의 마음으로 작성 해 보고싶었습니다.그런데 그냥 관심만 가졌어야 할까요.. 발을 너무 깊이 담근 것 같습니다.다행히 수박 겉핥기라도 가능할 것 같아 맛만 보려 합니다.이번 포스트는 제목처럼 “검색에 의미를 담아보자" 입니다.혹시 KNN(K-최근접 유사항목 = Nearest Neighbor) 검색이라고 들어보셨거나, 접해보신분 계시나요? (kNN이란 무엇인가?)아마도 저보다는 잘 아실거라 생각합니다. 😅저는 예전부터 유사도 검색에 관심이 많았습니다. 구조나 원리따위는 전혀 몰랐지만 그냥 왜인지.. 멋있는 것 같았어요.하지만 ‘어디서부터’, ‘어떻게’, ‘무엇을’ 접근해야할지 모르고 그저 관심만 가지고 있을 뿐이었습니다. (그정도로 무지했죠 ^^;)Model이 뭐지? 이거부터 개발 해야하나?학습이란건 어떻게 시키는거지?수학도 얼마나 알아야 하나?무언가 어마무시한 그래프같은 것들을 그려야 하나?RAG는 또 뭐야? 먹는건가?등의 걱정과 궁금증이 몰려왔습니다.그렇게 궁금증만 쌓이고 있던 때, AWS의 SageMaker와 Bedrock이라는 서비스를 알게 되었고, 이번기회에 각잡고 조금씩 시작 해보려합니다.이 블로그는 AWS OpenSearch를 활용한 Semantic Search를 어떻게 구성했는지에 대한 생초짜의 기록입니다.어렵거나 이해안가시는 부분 있으시면 chatGPT + Google 등을 활용해보시길 적극 추천합니다!!훑어보기유사도 검색관련 공부를 하면서살펴본 내용들 중 도움이 되었던 블로그를 모아봤습니다.Embedding이란 무엇이고, 어떻게 사용하는가? (필독)[NLP] 자연어처리 임베딩 모델 총정리 (word2vec부터 BERT까지)Amazon Bedrock에서 Amazon Titan 텍스트 임베딩 시작하OpenSearch에서 수십억 규모 검색을 위한 적합한 k-NN 알고리즘을 선택하기그래프 기반 벡터 인덱스 HNSWOpenSearch Neural Search Tutorial: How Filtering WorksNeural Search on OpenSearch아마존 개요 Titan 모델Getting started with Amazon Titan Text Embeddings in Amazon Bedr

안녕하세요. LINE Plus ABC Studio에서 앱 개발을 하고 있는 김종식, 최정연, 박유진입니다. 저희 팀은 Flutter를 활용해 일본에서 운영하는 배달 서비스인 '데마에칸(Demaecan, 出前館)'의 다양한 제품 개발에 참여하고 있는데요. 작년에 YouTube 채널 라인개발실록에 올라간 일본 1위 배달앱, Flutter로 만듭니다 콘텐츠를 작업하면서 협업한 것을 계기로 Future 행사 준비 팀으로부터 컨퍼런스 초대 및 발표 요청을 받았습니다. 이 초청을 계기로 LINE Plus에서 이번 행사를 후원하기도 했는데요. 이 번 글에서는 Future 2024에 참석한 후기를 공유하려고 합니다.Flutter 2024는 Flutter Seoul & Incheon 커뮤니티에서 Flutter 개발자 여러분들을 위해 국내 최대 규모로 준비한 행사로, 2024년 9월 28일 인천 송도에서 10개 세션이 300명 이상의 참가자분들과 함께 진행됐습니다. FFI(foreign function interface)와 WebRTC(web real time clock), Code Push(over the air update, 사용자의 기기에 직접 배포하는 기술), UI 렌더링, 멀티 플랫폼 환경 개발 등 다양한 Flutter 이론과 실제 활용 사례를 오프라인에서 공유하고 공유 받을 수 있었던 귀한 행사였습니다.행사 시작 전 조금 일찍 도착해 행사장 주변과 세미나 실을 한 번 둘러봤는데요. 강연장 규모가 생각보다 커서 조금 부담이 느껴지기도 했습니다. 첫 세션이 시작되기 전에 대부분의 참가자들이 입장을 완료해 주실 만큼 참석률이 높았습니다.입장할 때 받았던 굿즈는 특히 맘에 들어 몇 개 더 받고 싶다는 생각도 들었습니다.매 세션마다 참가자분들의 발표 몰입도는 엄청났고, 발표 후 Q&A도 활발히 진행됐습니다. 최근 Flutter에 대한 관심이 커지고 있다고 느꼈는데요. 강연장에서 그 관심도를 생생하게 체감할 수 있었습니다. 특별히 기억에 남는 것은 발표자 대기실 공간인데요. 다과나 음료가 잘 준비돼 있었고, 행사장에서 진행되는 발표를 별도로 모니터링도 할 수 있도록 준비돼 있어서 준비를 많이 한 행사라고 느꼈습니다.저희 팀에서 준비한 발표 세션을 간략히 소개하겠습니다.저는 현재 머천트 앱 개발에 참여하면서 지속적으로 앱의 사용성을 개선해 나가고 있습니다. 이번 행사에서는 머천트 앱 리뉴얼 중 실제 담당했던 UI 커스터마이징과 스켈레톤 로딩, CustomScrollView 내부에 드롭다운 팝업 표시 등의 UI 요구 사항과 구현 과정을 소개했습니다. 각 요구 사항을 어떻게 해결해 나갔는지 그 과정을 상세히 소개하면서 이미 제공되는 패키지들과 비교하기도 했습니다.또한 내가 이해한 것을 정확하게 표현하기 위해 시각 자료를 그려서 첨부해 명확하게 의사소통을 하는 노하우와, 기획자 및 디자이너와 인식을 정확 히 맞추기 위해 노력하면서 동료에게 신뢰받는 개발자로 성장한 이야기도 공유했습니다.제 발표 전체 내용이 궁금하시다면 아래 링크를 참고하세요.저는 개인적으로 모바

안녕하세요, 현대자동차에서 자율주행 알고리즘의 최적화와 경량화 연구를 진행하고 있는 조재훈 책임연구원입니다. 이번 포스팅에서는 모델 경량화와 최적화의 핵심 기법 중 하나인 Pruning에 대해 알아보겠습니다. Pruning을 적용하여 어떻게 네트워크의 성능을 최대한 유지하면서 불필요한 파라미터를 줄일 수 있는지 설명드리고, 실제 적용 사례를 통해 과정을 살펴보겠습니다. 실무에서 적용중인 네트워크 최적화/경량화 기법들은 이전글을 참고해 주세요: [딥러닝 경량화] 실무에서 적용중인 딥러닝 모델 경량화/최적화 기법은?차량의 객체 인식을 위해 이미지를 받아 빨간색 박스를 그리는 모델이 있다고 가정해보겠습니다(2D object detection). 처음 설계할 때 수많은 파라미터를 가진 큰 모델을 만들 수도 있고, 더 적은 파라미터를 가진 작은 모델을 선택할 수도 있습니다. 일반적으로 많은 파라미터가 있는 모델이 성능이 높을 가능성이 있지만, 그렇다고 해서 모든 파라미터가 다 유의미한 것은 아닙니다. 과연 이 중에서 정말로 필요한 파라미터는 몇 개나 될까요? 바로 이런 질문에서 Pruning의 필요성이 시작됩니다.Pruning: 불필요한 파라미터 가지치기Pruning이란 무엇일까요? 쉽게 설명하자면, Pruning은 학습된 딥러닝 모델의 파라미터 중 중요도가 낮은 것들을 제거하여 모델의 크기를 줄이고 연산을 단순화하는 방법입니다. 이는 마치 나무의 불필요한 가지를 쳐내는 가지치기와 유사한데요, 이런 식으로 일부 파라미터를 제거하면 모델의 크기와 계산량이 줄어들고, 그 결과 추론 속도가 빨라집니다.Pruning 개념도.pngPruning의 효과는 다음과 같습니다.메모리 최적화: 파라미터 수를 줄여 모델이 차지하는 메모리 공간을 줄일 수 있음연산 효율성 향상: 모델의 불필요한 연산이 줄어들어 추론 속도가 개선됨전력 소비 감소: 연산 효율이 높아지면서 전력 소모 또한 감소하여, 배터리 효율이 중요한 환경에서 유용함Pruning 기법의 종류: Structured vs UnstructuredPruning 방법은 크게 두 가지로 나뉩니다: Structured Pruning과 Unstructured Pruning입니다.Structured PruningStructured Pruning은 네트워크 구조 자체를 단순화하는 방법입니다. 대표적으로 Channel Pruning이 있으며, 이는 CNN (Convolutional Neural Network) 에서 필요 없는 채널을 제거하는 방식입니다. 이 방법은 구조 자체를 통째로 제거하기 때문에, PyTorch나 TensorFlow 같은 딥러닝 프레임워크와 잘 호환되어 추론 속도 향상에 유리합니다. 다만, 구조 전체를 없애다 보니, Pruning 비율을 너무 높게 하기 어려운 단점이 있습니다. Unstructured PruningUnstructured Pruning은 구조는 유지하면서 특정 기준에 따라 개별 파라미터를 제거하는 방식입니다. 예를 들어, 특정 임계값 이하의 파라미터를 0으로 설정하는 것이 일반적입니다. 이

김민지(Jadie) / UX Designer부제. 새로운 지역 탐색 경험의 탄생서비스를 개선하기 위해 기존 기능을 강화하거나 새로운 아이디어를 제안하는 일은 흔합니다. 이번 글은 선행으로 시작한 프로젝트를 정규 프로젝트로 전환시켰던 ‘카테고리 홈 개선기’를 공유해보려 해요.왜 카테고리 홈에 검색 기능이 추가되었을까?서비스 퀄리티를 관리하기 위해 주기적으로 UT를 진행하고 있어요. 여러 UT를 진행하면서 발견한 주요 문제 중 하나는 바로 카테고리 홈에서 지역 탐색이 어렵다는 점이었어요.고객은 특정 지역만 선택하고 싶어 하지만, 제공되고 있는 지역 그룹 구조상 원하는 지역을 고를 수 없었어요. 또, 명소 기준으로 검색하고 싶어도 행정 구역에 익숙하지 않아 탐색에 불편함을 느낄 수 밖에 없었죠. 예를 들어, “가로수길이 신사동인지 논현동인지 헷갈린다”거나 “여수가 어떤 상위 지역에 속하는지 몰라 어렵다” 그리고 “홍대 지역만 보고 싶은데 선택이 안 된다”는 피드백이 대표적이었죠.카테고리 홈이란?여기어때 홈에서 호텔, 모텔 등 '숙소 유형'을 선택하면 나오는 페이지예요. 이하 '카홈'으로 지칭합니다.개편 전 카테고리홈이 문제는 서로 연관성이 낮은 지역들을 하나의 그룹으로 묶어 제공하는 방식에서 비롯되었지만, 내부 비즈니스 제약으로 인해 지역의 상/하위 체계를 즉시 개선하기는 어려웠어요. 이에 따라, 기존 지역 그룹 구조를 유지한 상태에서 카홈의 UX를 개선하는 방안이 필요했죠.또한, 기존 카홈에서는 지역 탐색 기능이 여러 위치에 흩어져 있었고, 카테고리별로 제공되는 탐색 도구도 일관성이 부족했어요. 예를 들어, 지하철 검색 기능은 모텔 카테고리에서만 지원되는 등 사용자가 탐색 과정에서 불편을 겪고 있었죠. 이러한 복합적인 문제를 해결하기 위해 카홈에 검색 기능을 추가하는 방안을 제안하게 되었어요.선택의 폭을 좁혀주는 차별화된 검색 결과결론적으로 모든 카홈에서 “지역명/명소/지하철역/숙소명” 키워드를 활용한 탐색이 가능해졌어요. 이 검색 기능은 기존 통합 검색(하단 네비게이션)과 차별점이 있어요. 통합 검색은 모든 카테고리를 아우르는 결과를 제공하는 반면, 카테고리 홈의 검색은 선택한 카테고리 내에서만 결과를 보여주는 방식이에요. 예를 들어, 펜션 카테고리 홈에서는 펜션과 관련된 결과만을 보여주어 고객이 원하는 조건 안에서 더 집중적으로 탐색할 수 있도록 설계했죠.이 차별화는 소소해 보일 수 있지만, 분산된 기능을 한곳으로 집중시켜 더 빠르고 좁은 검색 결과로 도달하게 함으로써 탐색 경험을 개선할 수 있을 거라 기대했어요.카테고리 내에서만 결과 노출Casual UT를 통한 초기 검증하기모텔 카테고리에서 첫 실험을 진행했어요. 모텔에서 기능 검증을 마친 후 다른 카테고리로 확장할 계획이었고, 동시에 ‘내 위치 기반 주변 추천 숙소’ 모텔 모듈의 기능 검증도 필요했어요. 이를 위해 기존 페이지에 검색 기능을 추가하여 큰 디펜던시 없이 모듈을 유지하는 방안을 고려했어요.이를 캐주얼 UT를 통해 사용성을 검증했는데, 예상하지 못한 문제들이 나타났어요.1

네이버 사내 기술 교류 행사인 NAVER ENGINEERING DAY 2024(10월)에서 발표되었던 세션을 공개합니다. 발표 내용타입시스템으로 도메인을 모델링하는 기법을 소개하고, 복잡한 도메인에서 보이지 않는 오류를 막을 수 있는 방법을 소개합니다.목차커피 주문도메인과 도메인 모델대수적 데이터 타입(Algebraic Data Type)현금 영수증 발급 수단안전성과 비용관계안전성의 의미원시타입에 대한 집착런타임 안전성 vs 컴파일 타임 안전성실전 도메인: 주문서 결제수단정리◎ NAVER ENGINEERING DAY란?NAVER에서는 사내 개발 경험과 기술 트렌드를 교류를 할 수 있는 프로그램이 많이 있습니다. 그중 매회 평균 70개 이상의 발표가 이루어지는 NAVER ENGINEERING DAY를 빼놓을 수 없는데요. 2016년부터 시작된 ENGINEERING DAY는 실무에서의 기술 개발 경험과 새로운 기술과 플랫폼 도입 시 유용하게 활용될 수 있는 팁 등을 공유하며 서로 배우고 성장하는 네이버의 대표적인 사내 개발자 행사입니다. 올해 진행된 NAVER ENGINEERING DAY 2024(10월)의 일부 세션을 공개합니다.

OpenAI는 개발자들이 자신만의 AI 어시스턴트를 애플리케이션에 통합할 수 있도록 지원하는 Assistant API를 새롭게 선보였습니다.이 API는 명확한 지침, 모델, 도구, 파일 등을 활용하여 사용자 요청에 대한 지능적이고 맞춤형 응답을 제공합니다.Assistant API는 현재 다음과 같은 주요 기능을 지원합니다: Code Interpreter, File Search, Function Calling.다음 그림은 Assistant API를 설명하는 그림입니다.정의: 특정 목적에 맞게 설계된 AI로, OpenAI의 모델과 다양한 도구를 호출합니다.역할: Assistant는 특정한 기능(예: 개인 금융 관리)을 수행하도록 미리 설정된 지침과 도구를 사용하여 사용자 요청에 응답합니다.정의: Assistant와 사용자 간의 대화 세션을 나타냅니다.역할: Thread는 Message를 저장하고, 대화가 모델의 컨텍스트 길이를 초과하지 않도록 자동으로 잘라냅니다.• None 예: "은퇴 계획에 대한 대화"라는 주제로 Thread가 생성됩니다.*정의: Assistant 또는 사용자가 생성한 텍스트, 이미지, 파일 등의 콘텐츠입니다.역할: 메시지는 Thread에 저장되며, 대화의 흐름을 기록합니다.• None 예: 사용자의 메시지: "내 은퇴 계획에 얼마나 기여해야 하나요?" Assistant의 메시지: "매년 $478를 기여하는 것이 적합합니다."*정의: 특정 스레드에서 Assistant가 도구와 모델을 호출하여 작업을 수행하는 인스턴스.역할: Assistant가 실행 중 모델을 호출하거나 도구를 사용하는 일련의 과정입니다.• None 예: "코드 인터프리터를 사용하여 사용자의 질문을 처리하고 메시지를 생성."정의: Run의 일부로, Assistant가 작업을 수행하는 세부 단계.역할: Assistant가 도구를 호출하거나 메시지를 생성하는 등의 구체적인 작업을 보여줍니다. Run Step을 통해 Assistant 작업 과정을 자세히 확인할 수 있습니다.다음으로는 Assistant API의 개념과 주요 기능, 그리고 실질적인 활용 방법에 대해 살펴보겠습니다.Assistant API는 OpenAI 모델을 활용하여 맞춤형 AI Assistant를 구축할 수 있는 도구입니다.Assistant는 특정 목적에 따라 사용자 요청에 응답하며, 다양한 도구와 외부 데이터를 활용해 복잡한 작업을 수행할 수 있습니다.맞춤형 지침 제공: Assistant의 성격과 기능을 특정 지침에 맞게 조정할 수 있습니다.다양한 도구 지원: OpenAI가 제공하는 기본 도구(Code Interpreter, File Search)와 사용자가 직접 만든 도구(Function Calling)를 병렬로 활용할 수 있습니다.Persistent Threads: Assistant와 사용자가 대화 내역을 저장하고 관리할 수 있는 영구 스레드를 제공합니다. 스레드는 대화 기록을 보존하고 Context 길이를 초과하지 않도록 자동으로 관리합니다.파일 관리 및 생성: 다양한 형식의 파일(PDF,

LLM은 인터넷 상의 다양한 텍스트 데이터를 수집한 대용량의 텍스트로 사전 학습 수행사전 학습 동안에는 LLM이 특정한 형태로 응답하거나 사용자의 요청에 따라 응답 하기를 기대하기는 어렵고,LLM이 언어에 대한 전체적인 이해도가 높아지고 바로 다음에 올 단어를 잘 예측하게 하기 위한 단계• None Llama-2: 10TB 분량의 코드, 블로그, 기사, 광고 등의 다양한 글이 섞인 텍스트 사용LLM이 사용자의 요청에 적절히 응답하기 위해 요청의 형식을 해석, 응답의 형태를 작성하여 요청과 응답이 잘 연결 및 정렬(aligment)되도록 추가 학습하는 것• None 지도(supervised): 학습 데이터에 정답(label)이 포함되어 있다는 의미• None 지시 데이터셋(instruction dataset): 지도 미세 조정에 사용하는 데이터셋. 사용자의 지시에 맞춰 응답한 데이터셋이라는 의미• None 지시사항(instruction): 사용자의 요구사항을 표현한 문장• None 입력(input): 답변을 하는데 필요한 데이터• None 출력(output): 지시사항과 입력을 바탕으로 한 정답 응답• None 텍스트(text): 지시사항, 입력, 출력을 정해진 포맷으로 하나로 묶은 데이터지시사항이 다양한 형태로 되어 있고 응답 데이터의 품질이 높을수록, 즉, 지시 데이터셋 품질이 높을수록 정렬한 모델의 답변 품질이 높아짐• None Less is More for Alignment(정렬을 위해서는 적은 것이 더 낫다): 메타, 2023. Llama 모델을 정렬하는데 선별한 1,000개 정도의 지시 데이터셋 이용• None Textbooks are All You Need(텍스트북이면 충분하다): 마이크로소프트, 2023. 파이썬 코드 생성 모델 파이(Phi)의 파라미터는 13억개사람이 더 선호하는 데이터를 선택한 데이터셋• None ChatGPT: 선호 데이터(chosen data)에 비선호 데이터(rejected data)보다 높은 점수를 주어 생성된 답변의 점수를 평가하는 리워드 모델(reward model) 만듦강화 학습에서 에이전트가 학습하는 방식에이전트(agent)가 환경(environment)에서 행동(action)을 하고, 행동에 따라 환경의 상태(state)가 바뀌고 행동에 대한 보상(reward) 부여에이전트가 연속적으로 수행하는 행동의 모음을 에피소드(episode)라고 지칭언어모델이 RLHF를 통해 학습하는 과정을 대입하면 다음 단어를 예측하는 토큰을 하나씩 생성(action)하는데,언어 모델이 텍스트를 모두 생성하면 리워드 모델(environment)이 텍스트를 평가하고 점수를 매김(reward)생성한 문장의 점수가 높아지는 방향으로 학습(episode)이 때, 보상을 높게 받는 데에만 집중하는 보상 해킹(reward haching)이 발생할 수 있음지도 미세 조정 모델을 기준으로 학습하는 모델이 가까운 범위에서 리워드 모델의 높은 점수를 찾도록 한다는 의미지도 미세 조정 모델을 기준으로 거리를 측정하므로 이를 참고 모

안녕하세요. 무신사에서 주문을 담당하는 백엔드 엔지니어 박준호입니다.이번 글에서는 무신사의 주문 시스템이 수많은 변화에 대응하며 대규모 트래픽과 이벤트 시즌에도 안정적인 서비스를 유지하기 위해 어떤 방식으로 변화해왔는지, 그 여정을 공유하고자 합니다.왜 개선이 필요한가?무신사와 같은 커머스 플랫폼에서 주문 시스템은 핵심적인 역할을 담당합니다. 주문 처리 속도와 안정성은 고객 경험에 직접적인 영향을 미치며, 주문 데이터를 신뢰할 수 있어야 모든 비즈니스가 원활하게 운영될 수 있기 때문입니다.무신사는 블랙프라이데이(이하 무진장) 시즌마다 최고 매출과 주문 수를 경신하며 놀라운 성장세를 이어가고 있습니다. 이처럼 가파른 성장을 뒷받침하기 위해 주문 시스템도 지속적인 발전이 필요합니다.하지만, 주문 도메인은 복잡한 비즈니스 로직을 포함하기 때문에 보수적으로 개발되는 면이 있습니다. 버그나 장애가 발생할 경우 장애 정도나 발생 시간과 관계없이 치명적인 결과로 이어질 수 있기 때문입니다.예를 들어 무신사의 경우 2023년 겨울 무진장 기준으로 시간당 평균 주문액이 10억 원 이상으로, 15분의 장애를 가정했을 때 약 2억 5천만 원 이상의 손실이 발생한다는 계산을 할 수 있습니다.따라서 주문 도메인을 다룰 때는 안정성과 신뢰성을 유지하면서도 변화와 개선을 추구하는 것이 매우 중요한 과제이고, 이를 위해 강한 책임감을 가지고 시스템을 관리하는 자세가 필요합니다.무신사 2.0 주문서여정의 시작, 모놀리식 아키텍처와 그 한계초창기 무신사 스토어는 모놀리식 아키텍처 (Monolithic Architecture) 로 구성되어 있었습니다. 하나의 데이터베이스를 공유하며 매거진을 제외한 모든 도메인이 하나의 리포지토리로 관리되어 있었습니다.주문 외에도 결제, 재고, 상품, 회원, 쿠폰, 적립금 등 모든 주요 도메인이 하나의 어플리케이션 내에 통합되어 있었기 때문에 매우 복잡하고 유지보수하기 어려운 구조였습니다. 특히 주문 시스템은 스파게티 코드처럼 복잡하게 얽혀 있었고, 콜 스택이 지나치게 깊어 분석이 어려웠습니다. 이러한 복잡성은 새로운 기능 추가나 버그 수정 시 높은 리스크를 동반하게 만들었습니다.모놀리식 아키텍처 무신사 스토어이 시스템은 DB 의존도가 높은 구조로 모든 요청이 데이터베이스를 통해 처리되었기 때문에 성능 문제가 빈번히 발생했습니다. 특히 무진장과 같은 대규모 이벤트 시 요청이 데이터베이스로 몰리면서 사이트가 다운되는 일이 잦았는데, 서버 다운타임과 성능 저하는 매출에 직접적인 영향을 미치는 민감한 문제이므로 이벤트 시즌에는 안정적인 시스템 운영이 필수적이었습니다.매년 서버를 증설하고 시스템을 튜닝했지만, 가파르게 증가하는 트래픽을 따라잡지 못해 한계에 도달하기 일쑤였습니다. 최적화되지 않은 코드들이 성능적 한계를 보이면서 근본적인 아키텍처 변화의 필요성이 대두되었습니다.변화의 시작, 리팩토링성능 개선과 유지보수의 용이성, 그리고 개발 생산성 향상은 매우 중요한 개선의 시작이였습니다.이를 해결하기 위해 리팩토링을 시작했고, 첫 단계로 시스템의