〈오피스〉와 〈러브레터〉에 담은 진심, 왓챠팀의 덕업일치 프로젝트 Part 1매달 셋째 주 수요일은 왓챠파티@무비랜드!2025년 2월 19일 수요일, 열한 번째 테마를 마지막으로 왓챠파티@무비랜드의 여정이 막을 내렸습니다.2024년 초, 왓챠는 성수동에 오픈을 앞둔 무비랜드에서 1년간 오프라인 왓챠파티를 진행하기로 결심합니다. 무비랜드는 30석 규모의 소극장으로, 매달 다른 큐레이터가 선정한 영화를 상영하며 이야기를 이어가는 공간이고, 왓챠파티는 왓챠 구독자라면 누구나 참여할 수 있는 다중 동시 감상 서비스로, 영화를 감상하며 실시간 채팅으로 이야기를 나눌 수 있는 기능인데요. 각자의 방법으로 ‘이야기’에 주목하는 무비랜드와 왓챠파티가 만나면 뭔가 흥미로운 일이 일어나지 않을까? 왓챠는 그렇게 첫 장기 오프라인 프로젝트를 통해 사용자와 조금 더 가까이, 더 길게 호흡할 수 있는 기회를 만들기로 합니다.이 회고는 지난 1년 동안 왓챠파티@무비랜드를 기획하고 준비하며 경험한, 현장 사진으로는 남기기 어려웠던 비하인드 스토리를 중심으로 구성되었습니다. 왓챠 무비랜드TF 구성원의 시점에서 전하는 이 이야기의 첫 편은, 콘텐츠를 향한 진심이 고스란히 담긴 테마들을 소개하는 것으로 시작합니다. 깨물면 안 아픈 손가락은 없지만, 열한 개의 테마 중 특히 애정이 깊었던 〈오피스〉와 〈러브레터〉를 중심으로 전해드립니다.-직장인이라면 5월의 시작은 살짝 더 즐겁다. 근로자의 날, 근로자의 노고를 위로하고 근무의욕을 높이기 위한 제정된 휴일로 시작되기 때문. 역시 회사는 안 가는 편이 더 좋지 않나? 그런데, 여기 출근을 더 좋아할 것 같은 사람들이 있다. 이런 직장이 있다고? 이런 동료가 존재한다고? 오피스 속 던더 미플린 스크랜턴점은 얼핏 회사보다 놀이터에 가깝다. — 〈오피스〉 테마 소개 중5월, 노동절! 오피스화창했던 5월의 셋째 주 수요일, 상영작은 〈The Office〉였습니다. 오프라인 왓챠파티 기획 초기부터 만장일치로 정해졌던 ‘확신의 테마’로 마치 정규음반의 타이틀곡처럼, 세 번째 트랙으로 준비하게 되었습니다. 콘텐츠를 향한 우리의 진심을 보여줄 차례라며, 유난히 의욕에 넘쳤던 순간들이 떠오릅니다.흥분한 덕후들의 잘 해보자 슬랙 캡쳐“상영되게 하라” — 시리즈 에피소드 엮기시리즈물의 극장 상영을 현실로 만들기 위해서는 고민이 필요했습니다. 2005년부터 2013년까지, 무려 8년의 세월에 걸쳐 방영된 아홉 개의 시즌, 총 186개의 에피소드로 이뤄진 미드 〈오피스〉를 어떻게 상영할 것인가?1회차 상영에는 몇 편을 엮을까? 어떤 에피소드를 선정해야 할까? 어떤 주제로 묶어야 팬들이 공감하는 파티를 할 수 있을까? 한 달 간격으로 새로운 테마의 상영 이벤트를 준비하는 건 매번 어렵고 시간에 쫓기는 일이었습니다. 특히나 극장 상영을 한 적 없는 오피스의 경우, 그 이상의 촘촘한 계획과 노력 그리고 확인 절차가 필요했어요.팀 내 〈오피스〉 덕후를 자처한 3명 — 알리아, 마일즈, 제인 — 을 중축으로 3시간에 가까운 첫 회의를 가졌습니다. 이야기를

Firebase가 최근 UI 테스트 자동화를 위한 신규 기능 App Testing Agent를 공개했습니다.에이닷 클라이언트 개발팀에서도 UI 테스트를 활발히 진행하고 있던 터라 자연스럽게 눈길이 끌렸습니다.궁금증을 못 참고 바로 몇 가지 시나리오를 실행해 보며 기능을 체험했고 동시에 백그라운드에서 무슨 일이 벌어지는지도 슬쩍 들여다봤습니다.이 글에서는 그 과정에서 얻은 실제 테스트 결과와 내부 로직을 추측해 본 이야기를 가볍게 풀어 보려 합니다.Firebase App Testing Agent는 Gemini in Firebase가 구동하는 AI 기반 UI 테스트 자동화 에이전트입니다.“로그인 플로우를 검증해 줘”처럼 자연어로 목표만 입력하면 에이전트가 앱 화면을 해석하고 버튼, 제스처 등 사용자 행동을 시뮬레이션해 테스트 시나리오를 생성하고 실행합니다.완료 후에는 각 단계의 스크린샷과 로그가 포함된 리포트를 제공해 문제 지점을 한눈에 파악할 수 있도록 돕습니다.두 가지의 테스트 실행 방식을 제공하며 이 글에서는 'AI 가이드 테스트'에 초점을 맞춰 보려고 합니다.• None 에이전트는 자연어로 작성한 테스트 목표를 해석해 앱의 UI 트리를 탐색하고, 실제 사용자 동작을 모사해 시나리오를 자동 실행합니다.• None 테스트는 단계별 시퀀스로 구성되며, 각 단계마다 목표(Goal), 힌트(Hint), 성공 판정 기준(Success Criteria)을 가이드할 수 있습니다.• None 이 글을 작성하는 2025년 4월 25일 현재, 테스트 실행에는 Gemini-2.0-Flash-001 모델이 사용되고 있습니다.현재 에이닷 클라이언트 팀에서 진행하고 있는 것과 동일한 수준의 테스트 시나리오를 작성하고 실행해보면서 App Testing Agent의 가능성과 한계에 대해서 알아보겠습니다.로그인 후 대화방에 진입했을 때 임의의 새 메시지가 정상적으로 노출되는지를 확인하는 간단한 테스트 케이스를 작성하고,이를 실행한 뒤 결과를 확인해보겠습니다.Firebase Console의 App Distribution 메뉴에서 ‘테스트 사례’ 탭으로 이동하면, 테스트를 생성하거나 실행할 수 있는 화면에 진입하게 됩니다.화면에 진입한 뒤 '새 테스트 사례' 버튼을 클릭하면 새로운 테스트 항목을 직접 등록할 수 있습니다.테스트 제목을 지정할 수 있으며 목표가 하나인 경우 비워두면 목표가 테스트 제목으로 사용됩니다.에이전트로 수행할 작업은 가급적 한 문장 이내로 간단히 작성하는 것이 좋습니다. 복잡한 동작일 경우 단계를 나누어 작성하면 오작동 가능성을 줄일 수 있습니다.Gemini가 앱을 이해하고 탐색하는 데 도움이 되는 추가 정보를 제공합니다.예를 들면, '온보딩 화면을 지나 이동합니다. 팝업을 모두 닫습니다. 로그인하지 않습니다.'와 같은 정보입니다.테스트 목표를 달성하는 데 필요한 예상 동작 또는 앱 상태를 설명합니다.예를 들면, '기본 앱 홈 페이지가 화면에 표시되고 모든 이미지가 로드되었으며 오류가 표시되지 않습니다.'와 같은 내용입니다.인트로 화면에서 '바로 시작하기' 버튼을 클릭해서 로그인 선택 화면으로 진입할 수 있도록 목표를 설정했습니다.T ID로 로그인 화면으로 진입하도록 목표를 설정했습니다. Step2에서는 목표를 통해 버튼을 누르도록 지시하지 않고 의도한 행동을 할 수 있도록 힌트를 제공했습니다.아이디랑 비밀번호 입력 후, 로그인 버튼을 누르도록 했습니다.버튼의 일부분만 보이는 경우 클릭을 하지 않는 경우가 있어서 버튼 전체가 보일 때까지 스크롤을 하도록 힌트를 제공했습니다.대화방 진입 후 임의의 메시지가 출력되는지 확인하도록 목표를 설정 했습니다.테스트 사례 화면에서 '테스트 실행' 버튼을 누르면, 테스트 실행에 필요한 설정을 진행할 수 있는 화면으로 전환됩니다.테스트 실행 시 제공되는 두 가지 유형인 'AI 가이드 테스트'와 '무작위 크롤링 테스트' 중 하나를 선택해 테스트를 수행할 수 있습니다.테스트 실행 시 사용할 기기를 선택할 수 있으며, 약 80개의 실제 기기와 에뮬레이터가 준비되어 있어 다양한 환경에서 테스트가 가능합니다.로그인이 필요한 앱이라면 테스트 실행 시 사용할 아이디와 비밀번호를 사전에 입력해둘 수 있습니다.테스트를 실행한 뒤에는 App Distribution의 해당 릴리스 버전에서 ‘앱 테스트 에이전트’ 탭을 통해 테스트 진행 상황과 결과를 실시간으로 확인할 수 있습니다.App Testing Agent는 목표대로 인트로 화면에서 ‘바로 시작하기’ 버튼을 클릭한 후 로딩 완료를 위해 10초 동안 대기했습니다.App Testing Agent는 로그인 선택 화면에서 ‘T ID로 로그인하기’ 버튼을 클릭해 T ID 로그인 화면으로 이동했으며, 해당 화면 진입 여부를 기준으로 테스트 결과를 Pass로 판단했습니다.App Testing Agent는 테스트 시작 시 설정한 아이디와 비밀번호를 입력해 로그인을 진행했습니다.이후, 에이닷 타이틀이 표시된 메인 화면에 정상적으로 진입한 것을 확인하고 이를 성공 기준으로 판단하여 테스트 결과를 Pass로 처리했습니다.다소 인상적이었던 점은 사전에 존재 여부를 명시하지 않았던 권한 팝업이 표시되었음에도 불구하고App Testing Agent가 이를 자동으로 인식하고 확인 버튼을 눌러 정상적으로 목표를 달성했다는 점입니다. 🤩일반적인 UI 테스트에서는 예상되지 않은 팝업이나 UI 변화로 인해 다음 단계로 진행하지 못하고 테스트가 실패하는 경우가 많습니다.임의의 메시지가 출력될 때까지 10초간 대기하도록 가이드했기 때문에 App Testing Agent는 해당 시간 동안 대기합니다.테스트 중 예상치 못한 돌발 상황으로 위치 서비스 관련 시스템 팝업이 노출되었지만 App Testing Agent는 ‘아니오’ 버튼을 스스로 인식하고 클릭하여 팝업을 정상적으로 닫았습니다.테스트 목표였던 임의의 메시지 출력을 감지하고 그 텍스트 내용을 정확히 확인한 후 Pass로 처리하는 과정을 보면, App Testing Agent의 UI 분석 능력이 상당히 정교하다는 점을 알 수 있습니다.‘에이전트 뷰 표시’를 켜면 테스트 중 에이전트가 접근성 정보를

접근성 - 선택이 아닌 의무스마트폰을 눈을 감고 사용해본 적이 있으십니까? 혹은 한 손만으로 모든 기능을 사용해보셨습니까? 우리가 당연하게 여기는 앱 사용 경험이 누군가에게는 매일의 도전일 수 있습니다.한국에는 약 260만 명의 장애인과 빠르게 증가하는 고령 사용자들이 있습니다. 이들도 우리와 동일하게 음식을 주문하고, 택시를 부르고, 친구와 대화하기 위해 앱을 사용합니다.그러나 많은 앱들이 이들을 위한 기본적인 접근성조차 갖추지 못하고 있는 실정입니다.「장애인차별금지 및 권리구제 등에 관한 법률」에 따라 모바일 앱 개발에서 접근성은 선택이 아닌 필수입니다. 하지만 오늘 이야기하려는 것은 복잡한 법적 기준이나 깊은 기술적 내용이 아닙니다.모든 사용자가 앱을 편리하게 사용할 수 있도록 하는 것은 개발자의 책임이자 기회이기도 합니다.이 글에서는 개발자나 디자이너가 쉽게 놓칠 수 있는 접근성 요소들을 살펴보고, 간단한 변화만으로도 어떻게 더 많은 사용자에게 더 나은 경험을 제공할 수 있는지 알아보려 합니다.그럼 어렵지 않은 몇 가지 고려사항들이 어떻게 앱의 사용성을 향상시킬 수 있는지, 함께 알아보도록 하겠습니다.Jetpack Compose에서는 수정자가 접근성 구현의 핵심입니다. 이 수정자를 통해 UI 요소의 접근성 속성을 세밀하게 제어할 수 있습니다.복잡한 UI 컴포넌트에서는 여러 요소가 하나의 논리적 단위로 작동해야 하는 경우가 많습니다.mergeDescendants 속성을 사용하면 불필요한 포커스 이동을 줄여 사용자 경험을 개선할 수 있습니다:복잡한 컴포넌트의 경우, 각 하위 요소마다 TalkBack이 포커스를 이동하면 사용자 경험이 저하될 수 있습니다.mergeDescendants=true를 설정하면 여러 요소를 하나의 접근성 노드로 병합하여 사용자 경험을 크게 개선할 수 있습니다.제스쳐에 의해 동작되는 액션은 시각적 사용자에게는 직관적이지만, 스크린 리더 사용자에게는 어려울 수 있습니다.아래 예제는 스와이프로 삭제를 하는 동작에 대한 대체 접근성 액션을 제공하는 방법을 보여줍니다:스와이프 제스처와 같은 복잡한 인터랙션은 장애가 있는 사용자가 사용하기 어려울 수 있습니다.위와 같이 Custom Action을 제공함으로써 TalkBack 사용자도 해당 기능을 쉽게 이용할 수 있게 됩니다.화면에 표시되는 텍스트와 스크린 리더가 읽어야 할 텍스트가 다른 경우가 있습니다.특히 통화, 기호, 약어 등에서 이런 차이가 발생합니다:이처럼 화면에는 기호로 표시하더라도, 스크린 리더 사용자에게는 더 명확하게 읽히도록 할 수 있습니다.요소 유형 정의와 특수 의미론:UI 요소의 역할과 상태를 명확히 정의하면 스크린 리더 사용자가 컨텍스트를 더 잘 이해할 수 있습니다:이렇게 요소의 역할(Role)과 상태를 명시적으로 정의하면 스크린 리더가 더 정확한 정보를 사용자에게 전달할 수 있습니다.때로는 UI 상태가 변경될 때 접근성 포커스를 프로그래밍 방식으로 제어해야 할 필요가 있습니다.특히 다이얼로그가 표시되거나 동적 콘텐츠가 로드될 때 유용합니다:다이얼로그와 같은 중요한 UI 요소가 나타날 때 자동으로 포커스를 이동시키면 스크린 리더 사용자의 방향성을 크게 개선할 수 있습니다.동적으로 변하는 콘텐츠는 시각적 사용자에게는 명확하지만, 스크린 리더 사용자에게는 인지하기 어려울 수 있습니다.이런 변화를 명시적으로 알리는 것이 중요합니다:TalkBack은 안드로이드의 스크린 리더로, 사용자의 접근성 경험을 결정짓는 핵심 요소입니다.응답성과 사용성을 향상시키기 위한 추가적인 최적화 Tip 들을 알아보겠습니다.접근성 포커스를 효과적으로 관리하는 것은 TalkBack 사용자 경험의 핵심입니다:시각장애인에게는 논리적으로 예상되는 곳으로 편하게 포커스가 이동되는 것이 무엇보다 중요한 부분입니다.장식적 요소는 접근성 포커스에서 제외하고, 중요한 컨트롤에 포커스를 집중시켜 사용자 경험을 효율적으로 만들 수 있습니다.traversalIndex 속성을 사용하면 레이아웃과 상관없이 논리적인 탐색 순서를 정의할 수 있습니다.이는 레이아웃 순서와 접근성 순서가 다를 때 특히 유용합니다.스크린 리더가 정확하고 의미 있는 정보를 전달하도록 발화 품질을 최적화하는 것이 중요합니다:약어나 특수 기호는 스크린 리더가 제대로 발음하지 못할 수 있습니다. contentDescription이나 text 속성을 사용해 올바른 발음을 유도할 수 있습니다.또한 liveRegion 속성을 통해 동적 콘텐츠에 대한 발화 우선순위를 설정할 수 있습니다.데이터가 비동기적으로 로드될 때 접근성 이벤트 발생을 동기화하는 것이 중요할때도 있습니다.비동기 로딩 상황에서는 데이터가 준비된 후 사용자에게 명시적으로 알려주는 것이 중요합니다.이를 통해 스크린 리더 사용자도 콘텐츠 변화를 놓치지 않을 수 있습니다.접근성은 더 이상 선택이 아닌 필수 요소입니다.뛰어난 접근성 구현은 장애가 있는 사용자뿐만 아니라, 모든 사용자의 경험을 향상시킵니다.명확한 포커스 관리, 의미 있는 콘텐츠 설명, 논리적인 탐색 순서 등은 보편적 사용성의 원칙과도 일치합니다.이 글에서는 Jetpack Compose에서 접근성을 구현하는 방법부터, TalkBack 최적화까지 기술적 접근성에 대해 다루었습니다.접근성은 단순한 기능 추가를 넘어, 깊이 있는 엔지니어링이 요구되는 영역입니다.성능과 접근성 사이의 균형을 맞추는 작업은 지속적인 도전이지만, 올바른 기법과 전략적 접근을 통해 모든 사용자에게 최적의 경험을 제공할 수 있습니다.접근성은 특별한 기능이 아니라, 좋은 앱 설계의 기본입니다.개발 과정 전반에 걸쳐 접근성을 고려하고, 이 문서에서 소개한 기법들을 적극적으로 활용한다면 Jetpack Compose 애플리케이션의 접근성을 체계적으로 높일 수 있을 것입니다.

AI 시대에 디자이너는 어떤 모습일까요?한번 쯤 이런 생각 해보지 않으셨나요? UI가 더 이상 필요 없어지거나, 로봇이 모든 일을 대신하는 날이 오면, 디자이너는 어떤 역할을 하게 될까?저도 같은 고민을 하다가 반대로 생각해 보기로 했어요. 언젠가 사라질 운명이라면, 차라리 그 미래를 앞당겨서 직접 경험해보기로요. “미래를 예측하는 가장 좋은 방법은 미래를 만드는 것이다”라는 말도 있잖아요.제가 팀에서 빠지더라도 아무 문제 없이 돌아가는 시스템을 만들어보는 실험이었어요.하나, 반복되는 작업을 '규칙'으로 정의하기저는 제휴를 맺은 회사들과 돈을 주고받는 정산 업무를 맡고 있는 팀에 있었어요. 문제는, 회사마다 수수료 계산 방식이 모두 달라서 매번 비슷한 일을 반복해야 했다는 거예요. 팀 인원이 아무리 많아도 일손이 부족한 구조였어요.그래서 생각했죠. "매번 다른 방법으로 하지 말고, 공통된 규칙을 찾아보면 어떨까?"예를 들어, 어떤 제휴사는 사용자가 토스를 통해 대출을 많이 받으면 더 많은 수수료를 지급하고, 덜 이용하면 적은 수수료를 주는 구조였어요. 이런 유사한 계약들을 묶어 ‘구간별 수수료율’이라는 하나의 규칙으로 정리했더니, 여러 회사의 정산을 모두 같은 방식으로 처리할 수 있게 됐어요.이런 식으로 복잡한 계약들을 표 하나로 정리하면서, 매번 새로 디자인하지 않아도 되는 구조 가 만들어졌어요. 이 시스템이 없었다면 지금도 저는 비슷한 화면 수백 장을 계속 만들고 있었을지도 몰라요.규칙을 만든지 반년쯤 지난 어느 날, 신기한 광경을 목격했어요. 프론트엔드 개발자가 저 없이도 UI를 만들고 있는 거예요. 디자인에 관심이 있는 개발자이기도 했지만, 디자이너 없이 돌아가는 시스템을 만들었다는 작은 성공의 신호였던 것 같아요. 물론 제가 디자인하는 시간도 매우 줄어들었고요.제가 생각한 다음 단계는 스펙을 작성하는 것조차 없애는 것이었어요. 보통 디자인하기 전에 제품의 요구조건 문서를 만들잖아요. 이것도 시스템화 할 수 있을 것 같았어요. 정산 서비스를 요청하는 임직원이 몇 가지 설문에만 답하면 그 정보를 토대로 UI가 자동 생성되도록 매핑 시스템을 만들었죠. 완전히 자동화되진 않았지만, 어시스턴트 디자이너 혼자 작업할 수 있을 만큼은 되더라고요.이쯤 되니 진짜로 ‘디자이너를 없앤다’는 실험이 현실이 되어가고 있다는 느낌이 들었어요.누구나 디자인할 수 시스템을 갖추고 나니, ‘이 시스템을 돌리는 주체가 꼭 사람이어야 할까?’ 라는 생각이 들었어요. 지금은 AI가 MCP(Model Context Protocol - AI와 제품이 소통할 수 있는 표준화된 소통 체계)를 통해 디자인 툴을 다루는 시대잖아요. 게다가 토스에서는 직접 디자인툴을 만들어 사용하기 때문에 어떠한 제약도 없이 다양한 시도를 해볼 수 있어요.아직은 바로 사용할 만한 수준의 화면을 만들지는 못하지만, 괜찮은 시스템이 정의되어 있다면 AI는 꽤 준수한 결과물을 만들어내더라고요. 그래서 앞으로 사람은 모두 시스템을 만들고, AI가 그 시스템을 활용해 제품을 만들게 되는 날이 올 것

wade.hong DB를 다룰 때 기반 기술이 되는 PreparedStatement을 내부 구현 탐구를 통해서 어떻게 동작하는지 잘 표현한 글입니다.jaden.jacky 속 보이는 분석을 통해, 우리가 무심코 사용하는 추상화된 기술들 간의 관계와 내부 동작을 이해하는데 도움이 되는 좋은 글입니다.안녕하세요. 카카오페이에서 서버 개발을 하고 있는 cdragon입니다. 저는 주로 Java, Kotlin 같은 JVM 기반 언어를 사용하고, 데이터베이스 연동에는 ORM인 Hibernate를 이용하고 있습니다. 최근 MySQL 성능 관련 스터디를 진행했는데, MySQL에서 제공하고 있는 PREPARE에 대해 다시 한번 살펴보는 계기가 됐습니다.PREPARE는 MySQL에서 prepared statement를 생성하는 커맨드인데요. 프레임워크 없이 순수 JDBC 구현체를 이용해서 데이터베이스 연동 코드를 작성해 본 경험이 있다면 PreparedStatement 인터페이스를 통해 많이들 접해보셨을 것 같습니다. 저 역시 데이터베이스의 기능으로 보다는 JDBC의 Statement, PreparedStatement로 먼저 접했습니다.위에서 언급한 대로 저희는 애플리케이션에서 데이터베이스 연동 시 Hibernate를 사용하고 있는데요. 애플리케이션에서 데이터베이스까지 가는 길에는 Hibernate뿐만 아니라 Connection Pool, JDBC를 거쳐야 합니다. MySQL에 대한 스터디를 진행하다 보니 문득 우리가 사용하는 추상화된 기술들 안에서 PreparedStatement가 어떻게 동작하고 있을지 궁금해졌습니다.예측한 대로 MySQL에 PREPARE를 실행하고 있는지도 궁금했고, 그에 대한 설정들은 어디서, 어떻게 제어하고 있는지도 궁금해졌습니다. 그리고 추상화 계층을 한 꺼풀씩 벗겨가며 확인해 보기로 했습니다. 이번 글에서는 그 과정과 결과를 공유하고자 합니다.이 글에서는 아래와 같은 내용을 다룹니다.• JDBC Statement와 PreparedStatement 인터페이스의 개념과 차이점을 다룹니다.• MySQL PREPARE의 동작방식을 살펴봅니다.• Hibernate, HikariCP, MySQL Connector/J에서 PreparedStatement 관련 설정은 어떻게 이루어지며, 내부 구현은 어떻게 되어있는지 분석합니다.• 마지막으로 PreparedStatement 관련 설정에 따른 성능 테스트와 함께 고려해야 할 사항들을 공유합니다.다만 이 글에서 다음 내용은 다루지 않습니다.이 글을 통해 다양한 추상화 계층에서 JDBC를 어떻게 활용하는지 이해하고, 효과적으로 활용하는데 도움이 되기를 바랍니다.이 글에서 다룰 코드 예제, 테스트 기술들의 상세 스펙은 아래와 같습니다.테스트로 활용할 간단한 테이블의 스키마는 아래와 같습니다.JDBC Driver를 직접 사용해서 DB에 쿼리를 실행하는 고전적인 코드를 살펴보겠습니다.DB Connection을 획득하고, createStatement() 메서드를 호출해 Statement 객체를 얻어 쿼리를

coco.nut Apache Pinot 클러스터 구성부터 상용 서비스까지 어디에도 쉽게 찾을 수 없는 엔지니어의 실전 노하우를 담았습니다.yol.yoli 카카오페이가 직접 부딪히며 얻은 Apache Pinot 운영 경험을 생생한 이야기로 들려드립니다.안녕하세요. 하둡플랫폼파트에서 하둡플랫폼을 운영하고 있는 sunny라고 합니다. 저희 파트에서는 다양한 목적에 맞춰 여러 클러스터를 구축하고 운영하며, 전사 사용자들에게 빅데이터 플랫폼을 제공하고 있습니다.이 글의 주제인 Apache Pinot는 대용량 데이터 스트림을 실시간으로 수집하고 분석할 수 있는 분산형 OLAP 데이터 저장소예요. 실시간 데이터뿐만 아니라 배치 데이터도 처리하고, 이 둘을 결합하여 분석할 수도 있습니다. Druid나 ClickHouse와 자주 비교되기도 합니다.실시간 업데이트(Upsert) 기능을 활용하여 지속적으로 변경되는 데이터를 즉시 반영하는 용도로 Pinot를 도입했습니다.Pinot 도입 초기에는 참고할만한 운영 사례가 부족하고 현재 버전에 비해 안정성이 다소 미흡해서 고생을 많이 했었는데요. 이 글에서는 오픈소스인 Apache Pinot를 도입하고 운영하면서 얻은 경험과 노하우를 공유하고자 합니다. Pinot 운영이 복잡할 수 있지만, 이 글에서 운영 노하우를 숙지하시면 실시간 데이터 분석을 활용하시는 데 도움이 될 거라 생각합니다. (본 내용은 Pinot 1.2.0 버전 기준으로 작성하였습니다.)이 글은 이런 분들에게 추천해요.• 실시간 OLAP에 관심 많은 엔지니어• Pinot 도입을 고려 중이거나 운영 중인 엔지니어이 글을 통해 다음과 같은 것들을 얻어가실 수 있어요.• 운영 경험에서 얻은 이슈 해결 케이스• 서비스 안정성을 높이는 클러스터 구성 Tip• 실시간 업데이트 테이블 성능을 높이는 방법이 글은 Pinot를 운영하면서 얻은 유용한 노하우를 전달하는 게 목적이므로 Pinot 개념은 간단하게 짚고 넘어가겠습니다.Pinot는 링크드인(LinkedIn)에서 공개한 실시간 OLAP 오픈소스 솔루션입니다. 링크드인 외에도 Uber, Stripe 등 다양한 기업에서도 Pinot를 활용하여 실시간 대시보드, 실시간 분석 애플리케이션 등 다양한 서비스를 제공하고 있습니다.• Stripe: 실시간 결제 대시보드, 판매자를 위한 실시간/배치 데이터 집계데이터 제공Pinot의 핵심적인 특징은 대용량 데이터를 빠르게 쿼리할 수 있도록 설계된 분산 시스템이라는 점입니다. 데이터를 세그먼트(Segment)로 분할하여 여러 서버에 분산 저장하고, 병렬 처리 방식으로 빠른 쿼리가 가능합니다. Pinot는 실시간 스트리밍 데이터와 배치 데이터를 수집하여 즉시 쿼리할 수 있습니다.Pinot 클러스터는 다음과 같은 주요 컴포넌트로 구성됩니다.• 브로커(Broker): 클라이언트로부터 쿼리 요청을 받아 서버로 라우팅하고, 여러 서버에서 받은 결과를 취합하여 최종 결과를 클라이언트에 전달함.• 서버(Server): 세그먼트 데이터를 저장하고 쿼리 요청을 처리함.• 컨트롤러(Contr

개발 시 사용자의 브라우저나 기기 환경에 따라 적절한 기능을 제공해야 하는 경우가 빈번하게 있습니다.해상도에 따라 반응형 디자인을 변경하거나, 모바일 / 폴드 / 태블릿 / 데스크탑 등 UX를 변경하는 경우는 많이 구현을 하곤 합니다.하지만 사용자 디바이스 / 접속 환경에 따라 기능을 변경하거나, UX를 향상시키기 위해 다르게 구현해야 한다면 어떨까요?이를 위해 두 가지 대표적인 방법인 'User-Agent Sniffing'과 'Feature Detection'에 대해 조사한 내용을 공유해 보고자 합니다.User-Agent Sniffing은 브라우저가 제공하는 User-Agent 문자열을 분석하여 기기나 브라우저를 식별하는 방식입니다.예를 들어, 특정 안드로이드 기기나 iOS 브라우저에서만 발생하는 문제를 해결하기 위해 사용할 수 있습니다.위 문자열에서 는 갤럭시 S8+ 모델을 나타냅니다(미국버전). 이를 통해 기기 모델을 특정할 수 있습니다.파싱을 통해 사용하는 것이 좋아 보이는데, 라이브러리로 나오는 것이 있어 아래에서 예제를 공유하겠습니다.하지만, User-Agent Sniffing은 약간의 단점이 있습니다:• None 새로운 브라우저나 기기가 등장하면 유지보수가 어려워집니다.• None 브라우저 업데이트로 인해 형식이 변경될 수 있습니다.• None 개인정보 보호 강화로 User-Agent 정보가 점점 제한되고 있습니다.실제로 크롬은 User-Agent Client Hints API를 도입하여 기존 User-Agent 문자열을 단순화하고 있습니다:Feature Detection은 브라우저가 특정 기능을 지원하는지 직접 검사하는 방식입니다.특정 API를 사용하기 전에 해당 API가 브라우저에 존재하는지 확인하고 조건적으로 코드를 실행하는 방식으로 체크합니다.간단한 예시로는 브라우저가 'fetch' API를 지원하는지 검사하는 코드입니다:이 접근법은 브라우저나 기기의 종류와 상관없이 기능이 지원되면 코드가 동작하고, 그렇지 않으면 fallback을 제공할 수 있어 훨씬 안전합니다.터치를 감지하거나, 웹 워커를 사용 가능한지, 로컬 스토리지에서 등을 유지 가능한지 사용 가능한지도 확인해야 합니다.두 방식을 구현한 라이브러리와 서비스도 있습니다.Modernizr (modernizr.com)는 Feature Detection을 쉽게 구현할 수 있게 도와주는 라이브러리입니다.사용자가 직접 API 지원 여부를 확인할 필요 없어 간편합니다.또한 Modernizr는 빌드 시 필요한 기능만 선택하여 파일 크기를 최적화할 수 있어서 꽤 유용합니다.이와 같이 필요한 기능들만 선택해서 build한 후 사용이 가능합니다.Sniffr (github.com/amoilanen/sniffr)는 User-Agent Sniffing을 구현한 라이브러리입니다.실제 써 봤는데, 따로 파싱을 구현할 필요가 없어 유용할 듯합니다.• None Android: User-Agent 문자열로 기기 모델까지 특정 가능합니다. 제조사별로 패턴이 다릅니다.• None iOS: 기기 종류(iPhone, iPad)는 구분 가능하나 정확한 모델 특정은 제한적입니다. iOS 13부터는 iPadOS가 데스크톱 모드로 동작할 때 Mac으로 인식될 수 있습니다.• None Web (MacOS/Windows): OS 버전은 알 수 있으나, 정확한 모델 특정은 불가능합니다.그 navigator 객체를 활용해 사용자 접속 정보를 가져오는 외 다른 방법들도 소개해보겠습니다.이런 것들을 항상 확인하고 구현하진 않겠지만, '아주 가끔씩' 필요한 경우가 있으니 이러한 함수가 있다는 것도 알면 좋을 것 같습니다.이렇게 두 방식을 혼합하여 사용자의 환경을 더욱 날카롭게 특정할 수도 있을 것 같습니다.이전에 말한 것처럼, 구글은 User-Agent 문자열의 정보를 점진적으로 줄이고 있습니다. 이제는 User-Agent Client Hints API를 활용해야 합니다:결론적으로, User-Agent Sniffing을 반드시 필요할 때만 제한적으로 사용하고, 기본적으로는 Feature Detection을 사용하는 것이 좋을 것 같습니다.또한 미래를 대비해 User-Agent Client Hints API와 같은 미래의 표준을 적용하는 것도 좋은 대안이 될 것 같습니다.간단히 userAgentData의 활용 형식에 대해서만 살펴보겠습니다.architecture, bitness, brands, ... 등이 있고, 버전, 브랜드(W3C User-Agent Client Hints에서 브랜드에 대해 확인할 수 있습니다.) 등도 확인이 가능합니다.네이버 D2 블로그 - User-Agent Client Hints의 도입, UA 프리징을 대비하라모더나이저(Feature detection 라이브러리)

이번에 포스팅에서는 GPT라는게 어떻게 구성이 되어있고현재 많이 쓰이는 ChatGPT의 동작을 LLAMA모델을 통해서 대략적으로 알아봅니다.전체적인 문맥을 만드는 일은 굉장히 어렵지만현재 단어를 보고, 다음에 올 단어를 예측해보는일은 어느정도 가능한 일 입니다.위 문장만 주어질 경우 다음 단어가 무엇이 나와야 할지 맞추기 어렵지만까지 주어지면, 앞에있는 단어들을 통해서 해당하는 문장의 다음 단어가 일것이라고 대략적으로 예상해 볼 수 있습니다.(물론 도 맞지만요!)이처럼 문장이 주어지고, 그 문장 다음에 어떤 단어가 나올지를 맞추는게 GPT의 알파이자 오메가 라고 할 수 있습니다.이때 문장을 주고, 해당하는 문장에 따른 다음 문자를 예측하면 되는것이기 때문에기존 머신러닝의 : 과같은 형태의 데이터가 없더라도인터넷에 존재하는 모든 텍스트가 이런 의 데이터로 활용이 가능해 집니다.GPT는 이제는 유명해진 General Pretrained Transformer의 약자 입니다.full name에서 추론해 볼 수 있지만, 블라블라 인것을 알 수 있습니다.는 google의 attention is all you need에서 처음 등장한것으로 알고있습니다.그리고, 이 Transformer를 설명할 때 항상 아래그림이 등장하죠근데, 저만 그런가요?사실 이렇게 주어지고, 이해하라고하면 저는 잘 모르겠더라구요.그래서 조금더 설명을 추가해 봤습니다.조금은 설명을 추가해 봤습니다.• None 아니 데이터가 도대체 어디서 어디로 흐르는 것이냐아아ㅏ위 두가지를 반영 해봤는데요• None (왼쪽 남색부분)Inputs를 통해서 들어간 문자열은 Vector로 변환됩니다.• None (보라색 부분)1️⃣에서 처리가 완료된 Vector를 사용해서 뭔지 모르겠지만 Encoding 동작을 하면, 그 결과로 Input한 Text의 특성을 보유한 가 생성됩니다.• None (오른쪽 남색부분) 를 사용해서 이제 새로운 무언가를 출력해 내야합니다. 이때 가장먼저 이 들어갑니다. 이 역시 단어의 일종이어서, Vector로 변환됩니다.• None (초록색 부분) 를 의 특성을 뽑아내는 중간에 끼어넣고, 출력해야하는 Text의 특성을 뽑아냅니다.• None (주황색 부분)4️⃣에서 얻어진 출력 Text의 특성을 활용해서, 다음에 올 문자를 추측합니다.• None 5️⃣에서 얻어진 단어(Ex. Hello)와 을 합쳐서 를 만들고, 이 문자를 다시 3️⃣에다가 넣어줍니다.• None 이 나올때까지 3~6을 반복해 줍니다.여기서 없이 오른쪽 부분이 바로 인 것을 알 수 있고,는 다음단어는 예측할 때 입력문장의 정보까지 참고해서 예측한다고 할 수 있습니다.Transformer의 경우 입력된 값이있고, 입력된 값에 따른 적당한 출력값이 필요합니다.그래서 와 같이 단순하게 학습시킬 수 없고입력된 문장에 대응되는 적당한 결과문장이 필요합니다.여기서 이제 아이디어를 내는게그러면 그냥 입력 문장의 특성추출부분 없이, 바로 예측해버리면 되는거 아냐?그래서, 최신 GPT계열의 모델들의 경우 이 대세를 이루고 있습니다.그래서 입력문장의 특성추출을 별도로 분리하지않고입력문장을 그대로 출력문장의 단어예측에 집어넣는 방식이 바로 Decoder Only Model입니다.가 들어갈 경우 이라는 문자가 출력되게 모델의 가중치를 학습시키면 되고문장은 온라인 상에 넘쳐나기 때문에, 학습에 어려움이 없습니다.huggingface에 올라온 LLaMa2 모델을 살펴보면Decoder Only Transformer의 모습을 보여주는것을 확인할 수가 있습니다.이러한 Decoder Only Transformer에 천문학적인 문서를 통해서 다음 문자를 예측하게 만든 상태를또는 이라고 부릅니다.하지만 지금까지 본 내용 만으로는어떻게 GPT가 유저와 이 가능한지 예상하기 어렵습니다.GPT가 어떻게 유저와 이 가능한다는 다음 포스팅에서 다룹니다.

생성형 AI 모델로 이미지 생성은 쉽죠, 그런데 '좋은 이미지' 생성도 쉬웠으면 좋겠어요!저희 회사에는 고유한 비율로 최소한의 디테일만 유지한 채 인체와 개체를 정의하는 이미지 스타일인 'LINE 스타일'이 존재합니다(참고). 저희 팀에서는 생성형 AI를 이용해 이 스타일이 적용된 이미지를 프롬프트만으로 생성하는 텍스트 투 이미지(text-to-image) 모델을 만드는 프로젝트를 진행했습니다.이 프로젝트는 사내 디자이너분들의 반복적인 이미지 생성 업무를 최소화하기 위해 시작했습니다. 사내 디자인 업무 중에는 상황에 맞게 이미지를 조금씩 다른 이미지를 그리는 업무가 있는데요. 이 작업을 자동화할 수 있다면 디자이너 분들이 보다 창의성을 요하는 업무에 집중할 수 있는 환경이 조성될 것이라고 믿었습니다.아래 이미지는 LINE 스타일에 따라 제작된 이미지로, 저희가 원하는 최종 결과물의 스타일과 수준을 보여줍니다.늘 그렇듯 생성형 AI 모델이 항상 좋은 이미지를 생성하도록 만드는 것은 쉽지 않았습니다. 예를 들어 아래 예시와 같이 'hold the LINE'이라는 피켓을 들고 있는 여성의 이미지를 생성하는 일을 생각해 보겠습니다. LINE 스타일과 유사한 이미지가 생성될 수도 있겠으나, 그렇지 않은 이미지들도 자주 생성될 것입니다. 실제로 아래 두 이미지 생성에 사용한 모델은 동일한 모델입니다. 단지 이미지 생성 시 설정한 하이퍼파라미터만 다를 뿐입니다(하이퍼파라미터에 대해서는 뒤에서 자세히 설명하겠습니다).* 이미지를 우클릭해서 새로운 탭이나 창에서 열면 이미지를 원본 크기로 확인하실 수 있습니다.좋은 이미지를 생성하기 위해 먼저 살펴볼 것이 글에서는 먼저 AI를 이용해 이미지를 생성하는 방법부터 살펴보겠습니다. 디퓨전(Diffusion) 모델로 시작해 스테이블 디퓨전(Stable Diffusion) 계열의 모델을 중점적으로 살펴보고자 하며, 스테이블 디퓨전 모델로 이미지 생성 시 널리 사용되는 여러 하이퍼파라미터와 각각의 기능도 함께 소개하겠습니다.좋은 이미지를 생성하는 방법을 알아내기 위해서는 이미지를 여러 번 생성해 봐야 하기 때문에 보통 몇 가지 하이퍼파라미터를 선정해 수치를 조정해 가며 이미지를 하나씩 생성해 보게 되는데요. 특정 범위 안에서 여러 값을 바꿔가며 이미지를 생성하는 일은 엄청난 수고가 필요한 일입니다. 따라서 자동화할 수 있다면 좋겠죠. 이런 작업을 자동화하려면 우선 '좋은 이미지'라는 게 무엇인지 수치화해 평가할 수 있어야 합니다. 이에 저희는 앞서 설명했던 이미지 평가 방법(참고: AI로 생성한 이미지는 어떻게 평가할까요? (기본편)) 중 일부를 소개하고, 이것을 활용한 하이퍼파라미터 탐색 방법을 소개하려고 합니다. 이미지를 수치화해서 평가하는 방법 외에도 프롬프트를 활용한 하이퍼파라미터 평가 방법도 소개할 예정이니 많은 관심 부탁드리며 본격적으로 시작해 보겠습니다.AI가 이미지를 생성하는 방법우선 생성 모델이 어떻게 이미지를 생성하는지 디퓨전 모델과 스테이블 디퓨전 모델을 중심으로 간략히 살펴보겠습니다(이후 설명은 스테이블 디퓨전 모델이 기준입니다).디퓨전 모델은 이미지 생성 분야에서 널리 사용하는 접근 방식 중 하나인 디퓨전 프로세스로 이미지를 학습 및 생성하는 모델입니다. 디퓨전 프로세스는 이미지의 노이즈를 점진적으로 제거(denoise)해 고품질의 이미지를 생성하는 방식입니다.• 전방향 디퓨전 프로세스: 디퓨전 프로세스는 원본 이미지에 점진적으로 노이즈를 추가해 이미지를 완전히 무작위한 상태로 변환하 는 과정입니다. 각 단계에서 일정량의 가우스 잡음(Gaussian noise)을 추가하는데요. 노이즈를 추가하는 방식은 마르코프 체인(Markov chain)으로 모델링되며, 각 단계는 이전 단계의 결과에 의존하지 않고 독립적으로 진행됩니다.• 역방향 노이즈 제거 프로세스: 노이즈 제거 프로세스는 노이즈가 추가된 이미지로부터 원본 이미지를 복원하는 과정입니다. 노이즈는 학습된 모델을 이용해 제거하는데요. 한 번에 제거하는 것이 아니라 점진적으로 제거해 초기 노이즈가 원본 이미지에 가까운 상태가 되도록 복원해 나갑니다. 이를 위해 모델은 현재 상태의 노이즈 이미지와 각 단계별로 노이즈를 제거할 확률 분포를 학습합니다. 즉, 제거할 노이즈 예측 값은 확률적(stochastic)으로 결정됩니다.이미지는 샘플링된 랜덤 가우스 잡음에 역방향 노이즈 제거 프로세스를 적용하는 형태로 생성됩니다.스테이블 디퓨전(이하 SD)은 디퓨전 모델의 한 구현체입니다. SD의 특징을 간략히 살펴보겠습니다.기존 디퓨전 모델은 앞서 살펴본 디퓨전 프로세스를 '픽셀 공간(pixel space)'에서 적용합니다. 따라서 큰 이미지(예: 1024x1024 픽셀)를 생성할 때에는 매우 많은 연산량이 필요합니다.이런 단점을 개선하기 위해 픽셀 공간이 아닌 '잠재 공간(latent space)'에서 디퓨전 프로세스를 적용하는 SD 모델이 제안됐습니다. 즉 기존 디퓨전 모델이 이미지 자체에서 노이즈를 줄이는 개념이라면, SD 모델은 이미지의 '잠재 벡터(latent vector)'에서 노이즈를 줄이는 개념입니다. 여기서 잠재 벡터는 잠재 공간에서의 위치이기 때문에 임베딩이라고 생각해도 무방합니다. 이 잠재 벡터는 이미지를 변분오토인코더(variational autoencoder, 이하 VAE)로 인코드해 생성하고, 이미지는 이 잠재 벡터를 VAE로 디코드해 생성합니다.이미지 생성 방식 중 텍스트를 추가 정보로 제공하는 텍스트 투 이미지 방식에서는 이미지를 생성할 때 노이즈 제거 과정에서 텍스트 임베딩 생성에 어텐션(attention) 메커니즘을 활용하며, 이미지 생성 모델을 파인튜닝할 때는 주로 노이즈 제거기(denoiser)인 U-Net을 파인튜닝합니다.저희 실험에서는 SD의 초기 버전인 SD1을 쓰지 않고 SDXL(SD-xlarge)과 SD3.5을 사용했습니다. 이 두 모델은 초기 버전의 SD 모델의 파라미터 수 증가에 따라 개량된 모델입니다(참고로 이 글에 첨부된 이미지는 대부분 SD3.5로 생성했습니다).SDXL의 구조는 SD와 큰 차이는 없습니다. 다만 텍스트 인코더(CLIP

이번에는 슬랙과 지라의 반복 업무를 자동화한 AI 슬랙봇 ‘도비’의 개발 여정을 소개합니다. 별도 인프라나 복잡한 코딩 없이, GPT와 협업해 단순 명령으로 티켓을 생성하고 업무 시간을 크게 절약한 실전 사례입니다.쌓여가는 슬랙 쓰레드와 누락되는 지라 티켓업무를 위한 필수 도구인 슬랙과 지라! 하지만 이런 경험 다들 있으시죠? 회의 다녀온 사이 기하급수적으로 늘어난 쓰레드 댓글들, 급한 업무 처리하다 깜빡한 지라 티켓 생성까지. 이런 반복적인 업무는 생각보다 많은, 그리고 소중한 시간을 소모하게 만들어요.“회의를 갔다 오니까 갑자기 쓰레드 댓글이 엄청나게 쌓여있거나 아니면 중간에 멘션 된 경우 다들 있으시죠? 저는 이 긴 내용을 파악을 하다 보면 생각보다 시간을 꽤 사용하게 되더라고요.”‘도비' 는 플랫폼 PM 혜연님의 이런 일상적인 고민에서 시작됐어요. 특히 주문 관련 에러나 요청이 들어왔을 때 대응하느라 정신없이 일하다 보면 지라 티켓 생성을 자주 깜빡하게 되고, 이는 결국 중요한 이슈나 업무 트래킹 누락으로 이어지는 문제가 있었죠. 작년 체크아웃 운영 티켓만 280건, 티켓 생성에만 약 840분(14시간)이 소요된다는 계산이 나왔어요. 많은 직원들이 이런 반복 작업의 비효율성을 인지하고 있었지만, 주문 개발팀의 규원님 말씀처럼 현실은 달랐습니다.“운영 업무에 치여 아무것도 할 여유가 없었어요. 하지만 짧은 시간에도 AI 를 활용해 문제를 해결할 수 있을거라는 확신이 생겼고, 미뤄뒀던 일을 이제는 AI를 활용해 빠르게 해결해보려고 했어요.”현업에 치여 실천으로 옮기지 못하는 상황, 여러분들도 공감하실 거예요. 이런 상황에서규원님과 혜연님은 AI를 활용한 실질적인 해결책을 모색하기 시작했습니다.슬랙봇 ‘도비'GPT와 함께 시작한 슬랙봇 ‘도비’ 개발 여정규원님은 개발팀 매니저로서 반복적인 업무를 AI로 자동화할 방법을 오랫동안 고민해왔어요. 하지만 생각만으로는 아무것도 변하지 않았죠.규원님과 혜연님은 슬랙봇 개발이라는 공통의 목표를 세웠어요. 이 봇의 이름은 ‘도비’! 도비는 두 가지 핵심 기능을 제공합니다: 첫째, 슬랙 쓰레드를 한 방에 요약하는 ‘요약 도비’, 둘째, 내용을 요약해 지라 티켓까지 자동으로 생성하는 ‘지라 도비’예요. 개발 과정은 ChatGPT에게 물어보는 것으로 시작됐습니다. 규원님은 슬랙봇을 빠르게 만드는 방법부터 서버와의 연결, 쓰레드 내용 수집 방법까지 단계별로 GPT에게 질문했어요.도비의 주요 기능“슬랙에 특정 명령을 호출해서 해당 스레드에 있는 내용을 정리하는 것이 제 첫번째 요구사항이었어요.”이 과정에서 규원님은 몇 가지 원칙을 세웠는데요, 직접 많은 양의 코드를 생산하거나 DB, 인프라를 다루지 않고 에너지를 최소한으로 쓰겠다는 것이었습니다.“제가 코딩을 뭔가 주도적으로 하지 않는다가 첫 번째였고요. DB를 안 쓰는 게 두 번째였고 그리고 인프라도 안 쓰는 게 목적이었어요. 그러니까 여기에 내가 뭔가 다른 거를 하겠다는 에너지를 안 쓰려는 게 목적이었고…”이처럼 최소한의 개발 노력으로 최대한의 효과를 내