Simplicity는 더 나은 사용자 경험을 만들기 위해, 토스가 치열하게 고민해온 과정을 나누는 디자인 컨퍼런스예요. 우리의 실험과 시도들이 사용자 경험을 고민하는 다른 디자이너들에게도 영감이 되기를 바라며 시작했어요.2021년부터 토스 디자인 챕터가 정기적으로 개최하고 있죠. 내용뿐 아니라 메시지를 어떻게 전달할지도 늘 중요하게 여겼기 때문에, 2023년부터는 유튜브 영상이 아닌 웹 기반 인터랙티브 사이트로 전환해 운영하고 있어요.디자인 챕터에게 심플리시티는 거의 종합 예술에 가까운 프로젝트예요. 운영, 디자인, 개발, 대본, 촬영, 녹음, 홍보까지—모든 과정이 고도화된 협업으로 이루어지죠.한 번으로 끝나는 행사가 아니라, 매년 반복되는 시즌제 컨퍼런스이기 때문에 ‘지속 가능성’이 정말 중요한 주제였어요. 매년 퀄리티와 지속 가능성 사이의 균형을 고민해야 했죠. 그 과정에서 많은 부분을 효율적으로 만들어왔지만, 촬영만큼은 늘 어려운 과제였어요.촬영을 하려면 대본이 완성되어야 하는데, 그 과정만 무려 두 달이 넘게 걸려요. 내부 피드백, 법무·보안·개인정보 검토를 거치며 수차례 수정되고, 최종적으로는 발표자 톤에 맞춰 구어체로 다시 다듬어야 하거든요. 대본이 늦어지면 촬영도 늦어지고, 전체 일정이 밀리기도 하죠.그런데 이게 끝이 아니에요. 혹여라도 대본상의 문제를 나중에 발견하게 되면, 다시 촬영을 해야 해야 하거든요. 촬영은 디자인 챕터의 전문 영역이 아니라 항상 외부 전문가나 다른 팀의 도움을 받아야 하는 구조적 제약도 있었죠.더 큰 문제는, 발표 경험이 익숙하지 않은 연사들에게도 부담이 컸다는 거예요. 실제로 워크숍에서 연사자들이 가장 꺼리는 일로 “발표하기, 촬영하기, 녹음하기”를 꼽았을 정도였죠. 컨퍼런스인데, 발표가 가장 하기 싫다니—아이러니하죠?그래서 자연스럽게 이런 질문이 생겼어요AI 아바타가 발표한다면그래서 이번 시즌에는 새로운 방식을 시도했어요. AI 아바타가 발표를 대신해보는 실험이었죠. 혹시 눈치채신 분 계실까요?간단할 거라고 생각했지만, 막상 해보니 쉽지만은 않았어요. AI 서비스들의 한국어 지원이 매끄럽지 않아서, 자연스러운 음성을 만들기가 어려웠거든요. 그래서 여러 번 테스트를 거쳐, 최적의 방법을 찾아냈어요.기존의 방식이라면 연사자는 발표 내용을 자연스럽게 말하기 위해 여러 번 연습하고, 촬영 중간에 한 번이라도 말을 더듬거나 버벅이면 처음부터 다시 찍어야 했어요. 하지만 이번에는 딱 한 번만 찍어도 AI 아바타를 만드는 데 충분했어요.촬영 자체도 훨씬 간편해졌어요. AI 아바타 생성을 위한 학습용 데이터로만 쓰이다 보니, 연사자가 회의실에 들어와서 나갈 때까지 30분이면 촬영이 끝났거든요.덕분에 연사자의 부담은 확 줄었고, 일정도 유연하게 조율할 수 있었어요. 심지어 오픈을 일주일 앞두고도 대본 수정이 가능한 정도였죠.촬영은 어떻게 했냐고요? 아마 들으면 깜짝 놀라실 거예요. 스튜디오도, 전문 장비도 없었어요. 회의실에서, 아이폰 전면 카메라로, 스노우 앱을 켜고 녹화했거든요. 말 그대로 셀카 찍듯 촬영했

Simplicity는 더 나은 사용자 경험을 만들기 위해, 토스가 치열하게 고민해온 과정을 나누는 디자인 컨퍼런스예요. 우리의 실험과 시도들이 사용자 경험을 고민하는 다른 디자이너들에게도 영감이 되기를 바라며 시작했어요.2021년부터 토스 디자인 챕터가 정기적으로 개최하고 있죠. 내용뿐 아니라 메시지를 어떻게 전달할지도 늘 중요하게 여겼기 때문에, 2023년부터는 유튜브 영상이 아닌 웹 기반 인터랙티브 사이트로 전환해 운영하고 있어요.디자인 챕터에게 심플리시티는 거의 종합 예술에 가까운 프로젝트예요. 운영, 디자인, 개발, 대본, 촬영, 녹음, 홍보까지—모든 과정이 고도화된 협업으로 이루어지죠.한 번으로 끝나는 행사가 아니라, 매년 반복되는 시즌제 컨퍼런스이기 때문에 ‘지속 가능성’이 정말 중요한 주제였어요. 매년 퀄리티와 지속 가능성 사이의 균형을 고민해야 했죠. 그 과정에서 많은 부분을 효율적으로 만들어왔지만, 촬영만큼은 늘 어려운 과제였어요.촬영을 하려면 대본이 완성되어야 하는데, 그 과정만 무려 두 달이 넘게 걸려요. 내부 피드백, 법무·보안·개인정보 검토를 거치며 수차례 수정되고, 최종적으로는 발표자 톤에 맞춰 구어체로 다시 다듬어야 하거든요. 대본이 늦어지면 촬영도 늦어지고, 전체 일정이 밀리기도 하죠.그런데 이게 끝이 아니에요. 혹여라도 대본상의 문제를 나중에 발견하게 되면, 다시 촬영을 해야 해야 하거든요. 촬영은 디자인 챕터의 전문 영역이 아니라 항상 외부 전문가나 다른 팀의 도움을 받아야 하는 구조적 제약도 있었죠.더 큰 문제는, 발표 경험이 익숙하지 않은 연사들에게도 부담이 컸다는 거예요. 실제로 워크숍에서 연사자들이 가장 꺼리는 일로 “발표하기, 촬영하기, 녹음하기”를 꼽았을 정도였죠. 컨퍼런스인데, 발표가 가장 하기 싫다니—아이러니하죠?그래서 자연스럽게 이런 질문이 생겼어요:AI 아바타가 발표한다면그래서 이번 시즌에는 새로운 방식을 시도했어요. AI 아바타가 발표를 대신해보는 실험이었죠. 혹시 눈치채신 분 계실까요?간단할 거라고 생각했지만, 막상 해보니 쉽지만은 않았어요. AI 서비스들의 한국어 지원이 매끄럽지 않아서, 자연스러운 음성을 만들기가 어려웠거든요. 그래서 여러 번 테스트를 거쳐, 최적의 방법을 찾아냈어요.기존의 방식이라면 연사자는 발표 내용을 자연스럽게 말하기 위해 여러 번 연습하고, 촬영 중간에 한 번이라도 말을 더듬거나 버벅이면 처음부터 다시 찍어야 했어요. 하지만 이번에는 딱 한 번만 찍어도 AI 아바타를 만드는 데 충분했어요.촬영 자체도 훨씬 간편해졌어요. AI 아바타 생성을 위한 학습용 데이터로만 쓰이다 보니, 연사자가 회의실에 들어와서 나갈 때까지 30분이면 촬영이 끝났거든요.덕분에 연사자의 부담은 확 줄었고, 일정도 유연하게 조율할 수 있었어요. 심지어 오픈을 일주일 앞두고도 대본 수정이 가능한 정도였죠.촬영은 어떻게 했냐고요? 아마 들으면 깜짝 놀라실 거예요. 스튜디오도, 전문 장비도 없었어요. 회의실에서, 아이폰 전면 카메라로, 스노우 앱을 켜고 녹화했거든요. 말 그대로 셀카 찍듯 촬영

안녕하세요, 카카오의 AI 모델 개발을 담당하는 카나나(Kanana) 조직의 Edwin(강우영), James(이재명) 입니다. 저희 팀에서는 다양한 모달리티 데이터를 처리할 수 있는 멀티모달 언어모델을 중점적으로 개발하고 있습니다.지난해 12월, 이미지를 이해할 수 있는 멀티모달 언어모델인 Kanana-v를 소개해 드린 바 있는데요. 이번 글에서는 텍스트와 오디오를 이해하는 오디오 언어모델인 Kanana-a와 텍스트, 이미지, 오디오 모두를 이해하는 Kanana-o를 소개합니다.Kanana-o는 Kanana-v와 Kanana-a를 모델 병합(Model Merging) 기법으로 결합하여 학습 효율을 극대화했습니다. 또한, 자체 제작한 이미지-오디오 통합 모달리티 데이터를 포함해 지금까지 쌓아온 학습 노하우를 바탕으로, 단기간에 다양한 한국어 및 영어 벤치마크에서 글로벌 경쟁력을 입증했습니다.이번 글에서는 이러한 결과를 만들어내기까지 저희가 마주했던 도전 과제들과, 이를 극복하기 위해 고민하고 노력했던 과정을 자세히 소개하고자 합니다.그림 2. Kanana-o와 글로벌 경쟁모델들의 음성 및 통합 모달리티 벤치마크 성능 비교특히, 아직 소개해드리지 못헀던 Kanana-a에 대해 먼저 자세하게 소개하고, 이를 Kanana-v와 결합하여 Kanana-o를 만든 과정을 설명드리겠습니다. 이어서 성능에 대한 자세한 정량 수치와 다양한 활용 예시들을 보여드리며 글을 마무리하도록 하겠습니다.사람과 기계가 소통하는 가장 자연스러운 방식은 ‘말하기’라고 할 수 있습니다. 음성은 텍스트보다 입력 속도가 빠르고, 시각적 주의를 요구하지 않으며, 몰입감 있는 소통 수단으로서도 강력합니다. 특히 운전 중, 운동 중, AR/VR 기기처럼 손이나 눈이 자유롭지 않은 환경에서는 텍스트보다 훨씬 직관적인 인터페이스가 됩니다.그뿐만 아니라, 음성은 단순한 정보 전달을 넘어 감정과 뉘앙스까지 담을 수 있는 소통의 수단입니다. 우리는 누군가의 말투, 속도, 억양, 리듬, 배경 소리까지 종합해 의미를 해석하고, 그에 맞는 방식으로 반응합니다.반면, 텍스트 중심 LLM은 이 모든 비 언어적 정보(paralinguistic cues)를 인식하지 못하고 단어 그 자체에만 반응합니다. 예를 들어, 떨리는 목소리로 말하는 “괜찮아요”는 문자로는 표현되지 않는 감정을 담고 있으며, 격앙된 고객의 말투에 맞춰 상담사가 말하는 속도를 낮추는 것도 텍스트만으로는 구현하기 어렵습니다.이처럼 실제 상황에서 사람과 사람 사이의 상호작용은 텍스트로 환원되기 어려운 정보들로 가득 차 있습니다.그래서, Audio LLM은 단순한 텍스트 LLM의 확장이 아니라, 인간과 기계 간 소통 방식을 근본적으로 바꾸는 새로운 패러다임이라고 할 수 있습니다. 이 섹션에서는 저희가 Audio LLM을 설계하며 겪은 기술적 고민과 구조적 선택에 대한 내용을 공유드리고자 합니다.Kanana-a의 개발 과정과 전체 구조Kanana-a는 텍스트와 음성을 함께 이해하고 생성할 수 있는 멀티모달 언어모델로, 전체 구조는 세 가지 주요 모듈로 구성됩니다.첫 번째는 오디오 인코딩(audio encoding) 모듈로, 입력된 음성 신호를 멜 스펙트로그램(Mel Spectrogram)으로 변환한 후, 오디오 인코더를 통해 LLM이 처리 가능한 형태의 임베딩 벡터로 압축합니다.두 번째는 LLM 기반 응답 생성 단계입니다. 이 과정에서 모델은 텍스트와 음성 임베딩을 함께 입력받아, 질의에 대한 의미를 통합적으로 이해하고 적절한 응답 시퀀스를 생성합니다.마지막으로, LLM에서 생성된 응답은 오디오 디코딩(audio decoding) 모듈을 통해 사람이 들을 수 있는 실제 음성 파형으로 복원됩니다. 이 단계에서는 LLM의 응답을 참고하여 이산적인 음성 토큰을 만들어낸 뒤 멜 디코더와 보코더가 함께 사용되어 자연스러운 음성 출력을 완성합니다.그림 3. 음성 이해 언어모델인 Kanana-a의 모델 구조. Voice Token LM으로부터 나오는 이산 음성 토큰을 실제 음성 파형으로 변경해주는 token-to-wav 합성 모듈은 그림에서 생략 되어있음.음성 데이터는 텍스트에 비해 입력 길이와 복잡도가 훨씬 높습니다. 예를 들어, “안녕하세요”와 같은 1초 분량의 인사말을 16kHz로 샘플링하면, 16,000개의 연속적인 숫자로 표현됩니다. 이처럼 단 몇 초의 음성도 수만 개의 숫자로 구성되기 때문에, 이를 그대로 대형 언어모델(LLM)에 입력하면 막대한 연산량과 지연(latency) 문제가 발생하게 됩니다.그렇다면 입력으로 주어지는 원본(raw) 음성 신호를 어떻게 하면 더 짧고 효율적인 형태로 바꿔 입력할 수 있을까요? 이 문제에 대한 저희의 고민과 경험을 바로 이어서 공유드리겠습니다.그림 4. 오디오 인코딩 모듈. 입력으로 들어오는 음성 신호가 mel spectrogram으로의 변환을 거쳐 Audio Encoder와 Audio Projector를 순차적으로 통과하며 LLM의 입력 벡터로 변환 됩니다.오디오 인코더: Raw 음성 신호를 LLM 친화적인 표현으로먼저, 입력된 음성 신호는 오디오 인코더(Audio Encoder)를 통해 일정 수준 압축된 피처 벡터(feature vector)로 변환됩니다. 일반적으로 멀티모달 언어모델에서는 각 모달리티에 대해 사전학습된 인코더(pretrained encoder)를 사용합니다.저희는 음성 인식 분야에서 널리 쓰이고 있는 OpenAI의 Whisper[1] 모델을 채택했습니다. Whisper는 96개 언어, 약 68만 시간 규모의 대규모 데이터를 학습한 모델로, MIT 라이선스 하에 공개되어 있어 제품을 개발하는 기업 입장에서도 접근성이 매우 좋은 모델이라고 할 수 있습니다.Whisper 인코더의 특징 중 하나는 높은 압축률인데요, 예를 들어, 초당 16,000개의 샘플로 구성된 음성 데이터를 멜 스펙트로그램으로 변환한 뒤 Whisper 인코더에 통과시키면, 초당 50개의 특징 벡터들만으로 표현할 수 있습니다.더욱 짧게 압축할 순 없을까? - 추가적인 Audio Projector의 설계Whisper 인코딩만으로도 압축률은 상당하지만, 1분

글. 남정연(Cleo) / UX Designer부제. 가격혜택 개선기여행 전 숙소를 고를 때, 합리적인 소비를 위해 가격과 혜택을 꼼꼼히 비교해보신 경험 다들 있지 않으신가요? 실제로 여기어때 UX 리서치팀의 고객 설문에서도 모텔, 호텔, 펜션 등 카테고리와 관계없이 가격이 최우선 탐색 조건이라는 결과가 나왔어요.이처럼 고객에게 가격 경쟁력을 잘 소구하여 구매 결정에 도움을 주려면, 탐색 과정 전반에 걸친 효과적인 가격 커뮤니케이션이 핵심이에요. 특가나 쿠폰을 제공하는 제휴점 입장에서도 혜택이 잘 드러나는 것이 매출과 직결되는 만큼, 그 중요성은 더욱 크다고 볼 수 있죠.오늘은 이토록 중요한 가격 혜택 커뮤니케이션을 어떻게 개선하고 실험했는지, 그 과정에서 고객과 제휴점 모두의 니즈(Needs)를 어떻게 반영했는지, 또 실험 결과를 분석해 어떤 추가 개선을 도출했는지에 대한 이야기를 담아보려해요.문제 인식: 우리는 가격 혜택 커뮤니케이션을 잘하고 있을까?당시 여기어때는 고객에게 더 경쟁력 있는 가격으로 상품을 제공하고, 구매 전환을 높이는 방법을 고민하고 있었습니다. 이를 위해 제휴점이 특가를 더 활발히 설정하도록 유도하는 ‘특가 활성화 프로젝트’도 준비 중이었죠.하지만 제휴점이 특가를 제공하더라도, 고객이 이를 명확히 인지하지 못하면 구매로 이어지기 어렵고, 곧 제휴점의 특가 제공 동기마저 떨어뜨릴 수 있어요. 제휴점 대상 설문에서도, ‘특가를 제공했음에도 고객에게 충분히 노출되지 않아 효과가 아쉽다’는 의견이 많았어요. 이는 자연스럽게 ‘지금 고객에게 제공되는 가격 혜택이 과연 잘 전달되고 있는가?’ 하는 질문으로 이어졌죠.이 질문에 대한 답을 얻기 위해 실제 고객을 대상으로 UT(Usability Test)를 진행했어요. 숙소 탐색부터 구매 직전까지의 과정을 관찰하며, 현재 제공되는 혜택을 고객이 얼마나 잘 인지하고 체감하는지 검증했죠.그 결과, 다음과 같은 주요 인사이트를 얻을 수 있었어요.AS IS UT 결과혜택 정보는 ‘최종 가격’을 중심으로 인지된다고객은 빠르게 탐색하며 최종 가격과 직결된 정보에만 주목했어요. 특히, 가격과 시각적으로 분리되어있는 특가 정보는 거의 인지하지 못했어요.특가 유형보다 ‘할인 여부’와 ‘혜택 크기’에 집중한다‘반짝특가’, ‘타임특가’ 등 특가 유형을 세분화해서 보여주고 있었지만, 고객에게는 큰 의미를 주지 못했어요. 고객은 단순히 ‘특가가 적용되었는지’와 ‘얼마나 할인되는지’에만 관심을 가졌어요.현재 제공되는 쿠폰 정보는 소구력이 약하다쿠폰 혜택이 잘 드러나지 않아, 고객은 실제보다 혜택이 없거나 적다고 느끼기 쉬운 구조였습니다.이렇게 정의된 문제를 바탕으로, 가격 혜택을 어떻게 더 직관적이고 강하게 커뮤니케이션할 수 있을지 고민하게 되었어요.가설 수립과 솔루션 제안: 최종가에 혜택과 할인율을 강조하면 어떨까?“적용된 혜택과 할인율을 시각적으로 강조하고 최종가 근처에서 명확히 보여준다면, 고객은 가격 혜택을 더 쉽게 인지하고 이해할 수 있을 것이다.”라는 가설을 기반으로, 두 가지 주요 솔루션을 

들어가며안녕하세요, 인포테인먼트CCS개발팀에서 프론트엔드 개발을 하고 있는 이민재 연구원입니다.개발을 하면서 개발자들이 가장 보편적으로 쓰는 형상관리 툴인 Git은 개발자가 어떤 Feature를 개발했는지, 어떤 수정사항을 진행했는지 편리하게 알 수 있습니다. Git의 commit message를 통해서 우리는 어떤 것이 바뀌었는지 알 수 있고, 이를 통해서 이력 관리를 할 수 있습니다.하지만, commit 메세지를 한 눈에 파악하는 것은 약간의 노력이 수반될 수 있습니다. Github에 있는 대표적인 오픈소스인 react 프로젝트를 예시로 들어보겠습니다.한 눈에 어떤 변경점이 개선이 되었는지, 그리고 버전별로 변경사항을 한 눈에 파악하기는 힘들지 않나요? 그렇다고 이 commit message를 한 눈에 보기 위해서 프로젝트를 pull 받고, git hash를 찾아서 어떤 변경점이 있었는지 찾는 것은 생산성 저하의 우려가 있을 수 있습니다. 그래서 대부분의 Open Source 라이브러리들을 이력을 CHANGELOG.md를 통해서 관리합니다.체인지로그(changelog, 변경 기록)는 웹 사이트나 프로그램을 제작하는 것 같은 어떤 프로젝트를 진행할 때에 변경 사항에 대한 기록입니다. 많은 오픈소스 프로젝트에서는 체인지로그 파일을 가장 상위에 포함해서 배포합니다. (출처: https://ko.wikipedia.org/wiki/%EC%B2%B4%EC%9D%B8%EC%A7%80%EB%A1%9C%EA%B7%B8)Frontend에서 Design System 제작에 많이 사용되는 Storybook의 CHANGELOG를 같이 한 번 보겠습니다.대규모 Open Source이다 보니, 모든 변경사항에 대해 자세하게 적어주지는 않았지만, Release Note와 같이 몇 버전에서는 어떠한 사항이 변경 및 수정이 되었는지 확인이 가능합니다.개발에 집중하여 코드를 작성하고, 버그 개선 및 코드 수정을 하는 것도 개발자에게 필수적인 역량이라고 생각이 되지만, 내가 쓴 코드를 같이 협업을 하는 동료들이 본다고 했을 때, 동료들에게 내가 어떤 부분을 수정했고 반영을 했는지 알려주는 "문서화" 작업도 협업에 있어서 필요한 역량이라고 생각합니다. 단순히 구두로 "연구원님~ *** 관련한 feature 추가 했으니 확인해보세요~" 라고 하는 것은 정확한 정보 전달을 해친다고 생각이 됩니다.Node 환경에서는 commit 메세지 기반의 변경 사항을 자동화 해주는 라이브러리가 있습니다. 물론 Java(Spring)에도 자동으로 commit 메세지 기반의 CHANGELOG를 만들어 주는 tool이 있지만, 본 포스팅에서는 Node 환경에서 사용할 수 있는 방법에 대해서 소개해드리겠습니다.conventional-commit rule"standard-version", "conventional-changelog", "release-please" 등의 여러가지 라이브러리들을 사용할 수 있는데요, "conventional-changelog"에 대해 소개합니다. "standard-version", "release-please" 들이 내부적으로 "conventional-changelog"를 dependency로 사용하고 있기 때문에 모든 원형에 대해서 소개하는 것이 더 적절하다고 생각했습니다들어가기에 앞서, conventional-commit rule에 대해서 소개합니다. https://www.conventionalcommits.org/en/v1.0.0/이름에서도 볼 수 있듯이, 공통적인 commit rule에 대해서 정의를 하는 프로젝트 입니다. 짧게 요약을 해보면 아래의 형식에 맞추어 commit 메세지를 작성을 하라는 의미입니다.하지만, 인포테인먼트CCS개발팀에는 내부적인 commit rule이 존재했습니다. conventional-commit rule과 크게 다르지 않지만, commit 메세지의 맨 앞에 들어가는 type에 대괄호를 붙이는 것 입니다. 아래와 같이 말이죠.conventional-changelog이러한 배경을 가지고 conventional-changelog에 대한 사용법을 공유하겠습니다. 이 라이브러리의 사용법 자체는 크게 어렵지 않습니다.이렇게 하면 CHANGELOG.md 파일이 생기면서, git log를 끌고와 CHANGELOG.md 파일을 생성해줍니다.하지만, 제가 직면한 문제는 바로 커스텀한 commit 메세지 rule이 있었다는 것입니다. conventional-changelog를 내부적으로 뜯어보면 commit message를 parsing하는 parser가 존재합니다. 그 파서는 아래와 같이 commit message를 파싱하고, 앞서서 간략하게 언급한 conventional-commit rule을 따르고 있었습니다.headerPattern을 보시면 당팀에서 사용하는 commit 메세지의 header의 대괄호에 대해서는 conventional-changelog의 parser가 제대로 파싱하지 못하고 있었습니다. 그래서, 위의 conventional-changelog 명령어를 수행하면 CHANGELOG.md에 빈 파일이 생성이 되었습니다.custom parser이 문제를 어떻게 하면 해결할 수 있을지 고민하다가, 명령어를 조금 더 주의깊게 살펴보았는데요 cli에서 -p, -i, -s 등 어떠한 옵션을 가지고 명령어가 동작하지 않을까 생각이 들었습니다. 라이브러리를 조금 더 공부하고, 깊게 들어가본 결과 cli 명령어를 수행할 때 넣을 수 있는 옵션들이 있다는 것을 알았습니다.(출처: https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog/src/cli/index.ts)여기에서 특히 집중했던 부분은 -p(--preset) 옵션이었습니다.기본적으로 제공해주는 cli 명령어는 angular 옵션으로 실행이 되고 있지 않을까 생각이 되어 이 부분을 custom한 parser로 대체하면 되지 않을까 생각했었습니다. 그래서 프로젝트 root directory

여기어때 컬처 라운지 ep. 6어느덧 옷차림이 가벼워지고 따스한 봄기운이 느껴지는 4월 말입니다. 봄은 겨우내 쌓인 먼지를 털어내고 새로운 마음으로 재정비하기도 참 좋은 계절이죠? 봄을 맞이해 여기어때는 몸과 마음, 일하는 공간까지 산뜻하게 리프레시할 수 있는 시간을 가졌어요.✨ 공간을 청소하며 몸과 마음도 리프레시이번 봄맞이 대청소 행사 또한 Culture TF에서 기획하고 진행했어요. TF는 항상 ‘어떻게 하면 구성원들이 여기어때에서 더 즐겁고 행복하게 일할 수 있을까?’ 고민하는데요. 우리가 매일 많은 시간을 보내는 업무 공간을 깨끗하고 쾌적하게 만들면 몸과 마음도 함께 리프레시할 수 있을 것이라고 생각했어요. 쾌적한 업무 환경은 업무 효율뿐 아니라 마음의 안정에도 긍정적인 영향을 주니까요 :)‘청소’라고 하면 조금은 귀찮고 힘든 일처럼 느껴질 수도 있겠죠? Culture TF는 어떻게 하면 이 시간을 조금 더 즐겁고 의미 있게 만들 수 있을지 여러 아이디어를 모았습니다. 몇 가지를 소개해 드릴게요.🎁 첫 번째, 정성 가득 개인 청소 키트처음엔 층별로 공용 청소 물품을 구비해두려고 했어요. 그런데 혹시나 자율좌석을 이용하시는 구성원분들은 어색해서 선뜻 청소를 시작하지 못할까 걱정이 되더라고요. 그래서 결국, 누구나 편하게 참여하실 수 있도록 개인별 청소 키트로 준비하게 되었답니다. 오전부터 박스들과 씨름한 끝에 300개 키트를 준비했고, 점심시간에 라운지에서 Culture TF 멤버들이 직접 포장한 키트를 나눠 드렸어요. 혹시 부족할 경우를 대비해 각 층별 공용 청소 물품도 비치 완료!개인별 청소 키트키트는 소독 티슈, 정전기 청소포, 섬유 향수, 마스크, 그리고 행사 로고 스티커까지! 개인의 책상과 주변 공간을 산뜻하게 청소하는 데 꼭 필요한 물품들로 알차게 구성했어요. 작은 물건 하나하나에도 ‘구성원들이 기분 좋게 청소를 시작하셨으면 좋겠다’는 Culture TF의 마음이 담겨있어요.❣️✅ 두 번째, 막막하지 않도록! 친절한 체크리스트“어디서부터 청소를 시작해야 할까?”, “뭘 중점적으로 닦아야 하지?” 막막함을 느낄 구성원들을 위해 친절한 청소 체크리스트를 제작했어요. 개인 업무 공간 청소 시 확인하면 좋을 항목들과, 여러 사람이 함께 사용하는 회의실 청소 시 체크할 항목들을 구분했어요. 이 체크리스트는 청소의 가이드라인이 되어주면서 동시에, 앞으로 ‘이 공간을 이렇게 깨끗하게 유지하자’는 약속의 의미도 담았어요.청소 체크리스트🙌 세 번째, 회의실 청소 지원개인 업무 공간뿐만 아니라, 모두가 함께 쓰는 회의실도 깨끗해져야겠죠? 각 층별 회의실은 청소 지원자를 선착순으로 모집했어요. 체크리스트와 함께 어떤 회의실을 청소해야 하는지 안내해 드렸습니다. 자발적으로 나서서 청소해 주신 감사한 분들을 위해, 청소 후 체크리스트를 가져오시면 예쁜 청소 아이템을 리워드로 드렸어요. 작지만 소소한 선물이 회의실을 더 깨끗하게 만드는 힘이 되었겠죠?자발적인 회의실 청소 후기 & 소소한 청소 선물🎉 네 번째, 함께 나누고 즐겨요내 자리만 청소하

안녕하세요, 카카오 기술 블로그 독자 여러분!두 번째 글로 다시 만나게 되어 정말 반가워요. 첫 번째 글인 AI야, 문서 좀 대신 써 줘 - 1. 일단 시작!에서 제가 Technical Writing(TW) 에이전트를 만들기 시작했다는 소식을 전해드렸죠.TW 에이전트의 핵심 요소, AI 모델TW 에이전트는 사용자가 제공한 자료를 읽고, 기술 문서를 대신 작성하거나 다듬어주는 AI 도구입니다. 사용자가 대상 독자나 문서 목적 같은 요구사항을 알려주고 필요한 자료를 전달하면, AI가 아래 과정을 척척 해결해 주는 게 목표죠.• 템플릿과 스타일 가이드 지키기사실, 이 과정은 테크니컬 라이터가 기술 문서를 작성할 때 따르는 흐름과 거의 같아요. 기술 문서는 작성 과정과 내용이 체계적이고 정형화된 경우가 많아서, AI에게 맡기기가 훨씬 수월하답니다.TW 에이전트가 일하는 과정을 예상해 보면 아래와 같아요.• 사용자가 TW 에이전트에게 문서 작성 요청• TW 에이전트가 AI 모델에게 기술 문서 작성 요청• AI 모델이 기술 문서 작성 후 TW 에이전트에게 전달즉, 사용자가 TW 에이전트에게 기술 문서 작성을 요청하면, 실제로 기술 문서를 작성하는 건 AI 모델이에요.그러니 어떤 AI 모델을 사용해야 할지부터 결정해야겠죠!그럼, 이 일을 잘 해낼 수 있는 AI 모델은 어떤 걸 골라야 할까요? TW 에이전트가 필요로 하는 아래 능력들을 기준으로 AI 모델을 선택해야 했어요.• 다양한 기술 정보를 분석하고 분류하는 능력• 복잡한 기술 정보를 이해하고 명확하게 설명하는 능력• 필요한 정보를 스스로 찾아서 사용하는 능력이 기준을 바탕으로, 추론에 강한 최신 AI 모델들을 후보로 골랐어요. AI 기술이 워낙 빠르게 발전하다 보니 아무리 최신 모델을 쓰더라도 금방 구식이 되더라고요.TW 에이전트 후보로 선택한 모델은 아래 세 가지입니다.이제, 후보 AI 모델들의 기술 문서 이해 능력을 시험해 볼 차례입니다! TW 에이전트는 복잡한 기술 문서를 제대로 읽고, 핵심을 잘 정리할 수 있어야 하니까요.그래서 ‘카카오 로그인’ 서비스의 기술 문서를 파일로 주고, 관련 질문에 답하는 일종의 '쪽지 시험’을 치르게 했어요. 성능을 평가하는 방법은 많지만, 기술 문서 이해력을 알아보는 데는 이런 방식이 딱이라고 생각했거든요.총 20문항의 문제지는 GPT-4o가 만들고 제가 검토했어요. AI 모델이 문제 내용에만 집중할 수 있도록 문제지는 XML 형식으로 준비했고, 각 AI 모델에게 문제를 풀어달라고 요청했어요.제가 사용한 제시어(Prompt)와 문제 예시는 이렇게 생겼어요.AI 모델들은 순식간에 답안지를 작성해 냈어요. 카카오 로그인은 OAuth 2.0에 대한 이해가 필요하고 다양한 기능이 있는 서비스인데도, 허무할 정도로 빠르게 시험이 끝났습니다.답안 채점도 AI에게 맡겼어요. AI가 자기 성능을 평가할 때 생길 수 있는 자기 편향(Self bias) 문제를 피하기 위해 GPT-4.5, Gemini 2.0, Claude 3.5 Haiku 세 가지를 채점자로 썼고, 채점 과

차량 내에서도 에이닷 서비스를 더욱 편리하게 경험할 수 있는 시대가 다가오고 있습니다.이를 실현하기 위해 다양한 OEM 차량에서 에이닷 서비스를 제공하는 것이 무엇보다 중요했습니다.그러나 많은 OEM 차량에서는 저희가 개발한 SDK를 직접 탑재할 수 없는 한계가 있었습니다.이 문제를 해결하기 위해, SDK가 없는 차량에도 에이닷 서비스를 제공할 수 있는 방법을 고민한 끝에 서버 대 서버(Server-to-Server) 방식의 연동을 도입하게 되었습니다.이에 따라 OEM 서버와 에이닷 플랫폼 간의 원활한 차량 서비스 연동을 지원하는 Auto Proxy 서버를 개발하게 되었고 그 과정을 공유드립니다.• None 대형 메인프레임 컴퓨터가 주를 이뤘습니다. 이 거대한 기계들은 모든 기능을 단일 시스템 내에서 처리했고, 외부와의 통신 필요성이 거의 없었습니다. 데이터 교환은 주로 테이프나 카드와 같은 물리적 매체를 통해 이루어졌기 때문에, 현재와 같은 복잡한 네트워크 통신의 필요성이 크지 않았습니다.• None 기술 발전으로 PC, 워크스테이션, 소형 서버 등이 등장하면서, 컴퓨팅 환경이 크게 변화했습니다. 고가의 메인프레임의 기능을 여러 소형 서버로 분산시키고 네트워크로 연결하는 방식이 도입되었습니다. 이는 서버와 클라이언트 간의 통신을 기반으로 하는 새로운 모델을 탄생시켰고, 네트워크 기술의 중요성이 부각되었습니다.• None 프로세스 간 정보 교환이 활성화되면서 IPC(Inter Process Communication) 기술이 발전했습니다. 다양한 IPC 방식 중에서 소켓(Socket)은 네트워크를 통해 프로세스 간 통신을 가능하게 하는 중요한 수단이 되었습니다. 이를 통해 컴퓨터 간의 더욱 효율적인 통신이 가능해졌습니다.• None 소켓은 유용했지만 서비스가 확장하면서 더욱 다양한 데이터 종류를 송수신하게 되며 이를 매핑하는 과정이 복잡해졌습니다. 이러한 한계를 극복하기 위해 RPC 기술이 등장했습니다. RPC는 네트워크로 연결된 서버의 함수를 마치 로컬 함수처럼 호출할 수 있게 해주어 데이터 교환 방식을 단순화했습니다.gRPC와 REST: 현대 API 설계의 두 가지 접근법API 설계에 있어 REST와 gRPC는 각각 고유한 장점을 가진 두 가지 주요 접근 방식입니다. 이들의 특징을 비교해보면 다음과 같습니다.REST(Representational State Transfer)는 널리 사용되는 API 설계 방식으로, 몇 가지 주목할 만한 장점이 있습니다.• None REST는 단순성과 사용 용이성이 뛰어납니다. HTTP 메서드와 URL을 이용한 직관적인 설계로 개발자들이 빠르게 이해하고 구현할 수 있습니다.• None REST는 가독성과 디버깅이 용이합니다. JSON이나 XML 같은 사람이 읽을 수 있는 형식을 사용하기 때문입니다.• None REST의 stateless 특성과 HTTP 프로토콜 사용으로 캐싱 메커니즘을 쉽게 구현할 수 있어, 성능 향상과 서버 부하 감소에 도움이 됩니다.이러한 특징으로 REST는 개발자와 외부 사용자 모두

UV는 정말 빠를까? 그리고 얼마나 실용적일까?기존 프로젝트에서는 poetry를 패키지 매니저로 도입해 사용하고 있었지만, uv가 “빠르다”는 이야기를 듣고 테스트해보지 않을 이유가 없었습니다.실제로 성능 차이를 체감할 수 있을지 궁금했기 때문입니다.FastAPI는 정말 Flask보다 빠를까?잠깐 주제를 벗어나지만, 속도에 대한 이야기를 하다 보면 예전에 경험했던 FastAPI 도입 사례를 빼놓을 수 없습니다.과거 저희 팀은 백엔드에 큰 트래픽이 없는 구조였기 때문에 초기에는 Flask로 REST API 서버를 구성했습니다.그러다 FastAPI가 “속도가 빠르다”는 장점으로 각광받기 시작하면서 관심을 가지게 되었고, 실제로 FastAPI로의 전환을 시도해보았습니다.물론, 단순히 “빠르다”는 이유만으로 프레임워크를 바꾸는 건 위험하다고 판단해 간단한 벤치마크 테스트를 진행했는데요.테스트 결과, FastAPI가 약간 더 빠른 듯 보이긴 했지만, 기대만큼의 큰 차이는 아니었습니다.특히 실제 운영 환경에서 기존 Flask API를 FastAPI로 마이그레이션해보면서 그 차이는 더욱 미미하게 느껴졌습니다.대부분의 API가 DB에 접근하는 구조였기 때문에 IO가 병목이 되는 상황에서는 FastAPI든 Flask든 성능 차이가 거의 없었습니다.이러한 의문은 저만의 생각은 아니었고, 커뮤니티에서도 비슷한 피드백들이 많았습니다.FastAPI가 처음에는 “가장 빠른 프레임워크”로 소개되었지만, 현재는 슬쩍 “빠른 프레임워크 중 하나”라는 표현으로 바뀐 것도 인상 깊은 변화였습니다.그럼에도 불구하고 FastAPI는 pydantic과의 연계로 명확한 파라미터 검증을 제공하고, 문서화가 자동으로 이루어지는 등 속도 외에도 많은 장점을 가진 프레임워크라는 점은 분명합니다.이런 경험이 있었기 때문에, uv에 대해서도 단순히 “빠르다”는 인상만으로는 판단하지 않고 실제로 테스트를 해보기로 했습니다.UV는 실제로 얼마나 빠를까?간단한 실험으로 numpy, beautifulsoup4 두 개의 패키지를 설치하는 데 걸리는 시간을 비교해 보았습니다.격리된 환경에서의 공정한 비교를 위해 Docker를 활용하였으며, 사전 준비로 패키지 매니저(pip, poetry, pdm, uv)는 미리 설치해둔 상태에서 진행했습니다.참고: pyenv만 사용할 경우 캐싱 이슈가 발생할 수 있어 Docker 컨테이너 내에서 테스트를 수행했습니다.위 결과에서 알 수 있듯, uv가 다른 툴들보다 다소 빠르긴 했지만 “극적인 차이”까지는 아니었습니다.이는 패키지 자체의 빌드 지연 등 외부 요인에 영향을 받은 결과로 보입니다.만약 수십 개의 패키지를 설치하거나 복잡한 의존성 그래프가 있는 경우에는 uv의 장점이 더 뚜렷하게 드러날 수 있을 것으로 예상됩니다.다만 유의할 점은, uv 측의 주장처럼 10~100배 빠르다는 수치는 특정 조건에서의 최대 성능 기준이지, 항상 그런 건 아니라는 점입니다.결국 도구의 도입 여부는 실제 사용 환경에서의 유의미한 개선이 있는지를 중심으로 판단해야 합니다.기존에 po

제조 현장의 불량 검수를 AI로 하고 있다면, 성능이 나아지지 않는 AI에 불만족하다면, 이 튜토리얼이 도움이 되실 것입니다. 카메라를 활용한 데이터 수집부터 슈퍼브에이아이 플랫폼으로 데이터 선별, 라벨링, 모델 학습 및 실시간 배포까지 전체 과정을 단계별로 알아봅니다. 생산 라인에서 자동화된 품질 관리 시스템을 구축하는 실용적인 워크플로우를 제공합니다.필자: 슈퍼브에이아이 솔루션 엔지니어 ​Sam Mardirosian고성능 컴퓨터 비전 모델을 개발하려면 효과적인 모델 학습 파이프라인을 구축하는 것이 필수적입니다. 파이프라인을 잘 구축하면 데이터를 효율적으로 수집하고, 똑똑하게 선별하고, 정확하게 라벨링하고, 효과적으로 모델을 학습시켜 현실 시나리오에도 우수한 일반화 성능을 보이도록 만들 수 있습니다. 또한 파이프라인의 각 단계를 최적화하면 강건한 AI 시스템을 개발하는데 필요한 시간, 비용, 노력을 절감할 수 있습니다.이번 튜토리얼에서는 데이터 수집, 선별부터 모델 학습 및 배포에 이르는 전체적인 모델 개발 및 배포 파이프라인을 단계별로 살펴보겠습니다. 또, 어떻게 슈퍼브에이아이의 올인원 AI 플랫폼을 통해 이 과정을 자동화하고 효율화하여 성능과 효율성이라는 두 마리 토끼를 잡을 수 있는지 보여드리고자 합니다.산업 현장에 적용할 일반적인 실시간 결함 탐지 모델을 개발해 보겠습니다. 이번에는 Lucid Vision Labs의 표준 카메라를 사용할 예정이지만, 이 워크플로우는 보안 카메라(예: RTSP CCTV)나 웹캠과 같은 다른 카메라 종류에도 적용할 수 있습니다. Lucid Vision Labs 카메라로 이미지 데이터를 취득하고, 슈퍼브 큐레이트와 슈퍼브 라벨을 이용해 데이터를 선별 및 라벨링하고, 슈퍼브 모델로 AI 모델을 학습시킨 뒤 최종적으로 배포하여 실시간 결함 모니터링을 진행할 예정입니다. 이 방법은 보안, 안전, 장비 모니터링 및 규제 컴플라이언스와 같은 다른 객체 탐지 사례에도 충분히 적용할 수 있습니다.이 튜토리얼이 마무리될 때 쯤에는 다양한 유즈 케이스에 적용해 볼 수 있는 실용적인 파이프라인을 구축하실 수 있을 것입니다. 이를 통해 적절하게 선별된 고품질의 데이터로 여러분의 컴퓨터 비전 모델을 학습시키고 실제 환경에 배포할 준비를 마쳐보세요.컴퓨터 비전 모델 학습의 시작이자 끝은 바로 데이터 수집이라고 할 수 있습니다. 첫 단계이지만, 가장 중요한 단계이기도 합니다. 정확하고 신뢰할 수 있는 모델 성능을 유지하기 위해서는 품질과 다양성이 모두 확보된 데이터셋을 준비하는 것이 가장 중요하기 때문입니다. 필요한 데이터의 양은 모델이 수행하려는 작업이 얼마나 복잡한지에 따라 달라집니다. 간단한 작업을 처리하는 것이라면 상대적으로 적은 이미지로도 충분하지만, 보다 어렵고 예외적인 데이터, 즉 엣지 케이스가 많이 발생하는 시나리오를 처리하려면 더 많고 더 다양한 데이터가 필요합니다.이번 튜토리얼에서는 여러분이 학습용 데이터 수집 및 모델 배포에 Lucid Vision Labs 카메라를 활용하며 Lucid Arena SDK를