온디바이스(On-device) 음성인식은 음성 데이터를 로컬에서 처리함으로써 효율성을 극대화하는 기술입니다.특히, 에이닷 통화 요약 서비스에서 온디바이스 음성인식이 도입될 경우, 기존 서버 기반 처리 방식의 지연 시간과 연산 비용 문제를 극복할 수 있는 중요한 전환점이 될 것입니다.이번 글에서는 현재의 음성인식 처리 방식과 온디바이스 음성인식이 제공할 수 있는 개선점, 그리고 이를 위한 개발 과정을 다룹니다.에이닷 통화 요약 서비스는 사용자와의 통화 내용을 텍스트로 변환하여 요약을 제공하는 과정에서 빠른 응답성과 높은 처리 효율을 동시에 충족해야 하는 도전 과제를 안고 있습니다.현재 서버 기반 음성인식 구조는 높은 정확성을 제공하지만, 지연시간과 연산 비용 측면에서 한계를 가지고 있습니다.이러한 문제를 해결하기 위해 온디바이스 음성인식 기술이 도입되고 있으며, 이는 서비스의 근본적인 변화를 예고합니다.현재 에이닷 통화 요약 서비스는 위의 그림에서 볼 수 있듯이, 서버 기반 음성인식 구조를 따르고 있습니다. 이 과정은 다음과 같이 진행됩니다:• None 통화 녹음 파일 생성: 사용자 단말에서 통화가 종료되면, 통화 녹음 파일이 생성됩니다.• None 에이닷 전화 서버로 업로드: 생성된 녹음 파일은 에이닷 전화 서버로 업로드됩니다.• None 음성인식 서버로 전달: 업로드된 파일은 음성인식 서버로 전달되어 텍스트로 변환됩니다.• None 결과 반환 및 파일 삭제: 변환된 텍스트 결과는 에이닷 전화 서버로 다시 전달되고, 원본 녹음 파일은 즉시 삭제됩니다.이러한 구조는 안정적인 운영을 위해 설계되었지만, 지연 시간 문제를 발생 시킬 수 있습니다.통화가 종료된 이후에 멀티미디어 파일이 네트워크를 통해 업로드되고, 이후 음성인식이 진행되기 때문에 파일이 일정 이상의 지연은 불가피합니다.특히 긴 통화의 경우에는 사용자가 느끼게되는 지연 시간은 더 길어 질 수 있습니다.온디바이스 음성인식 기술이 도입되면, 기존의 서버 기반 구조는 위 그림처럼 다음과 같이 변화 합니다:• None 로컬 음성인식 수행: 통화 녹음 파일이 생성되지 않고, 사용자 단말에서 바로 음성을 텍스트로 변환합니다.• None 텍스트만 서버로 전송: 음성인식 결과 텍스트만 에이닷 전화 서버로 전송되며, 음성 파일 자체는 단말을 벗어나지 않습니다.또 다른 면으로 연산 비용 문제 해결도 중요합니다. 현재 에이닷 통화 요약 서비스는 하루 1,000만 건의 통화와 피크 시간대 120만 건의 통화를 처리하고 있습니다.이런 많은 양의 음성을 끊김 없이 처리하기 위해서 대규모 GPU 리소스가 필요하며, 이는 상당한 연산 비용을 초래합니다.온디바이스 음성인식은 이러한 비용을 줄일 대안으로도 검토되고 있습니다.On-device ASR SDK는 EPD(End Point Detector), FSA(Finite State Automata), ASR로 구성되어 있습니다.각 모듈들은 유기적으로 연결되어 최적화 되어 있기 때문에 별도의 추가 작업 없이 통합된 형태를 개발자가 바로 사용할 수 있습니다.• Non

간단한 문구에 깊은 철학을 담아낸 가 지난 11월, 뜨거운 관심과 호응 속에 성황리에 막을 열었어요. 21년 처음 시작된 토스의 디자인 컨퍼런스 는 올해로 3회를 맞이했는데요. 최신 디자인 트렌드와 실무 경험을 공유하는 것을 넘어, 디자이너들의 고민과 질문에 새로운 시각과 해결의 실마리를 제공하는 자리로 자리매김하고 있어요.이번 아티클을 통해 의 취지와 숨겨진 비하인드 스토리를 들려드리고자 해요!질문은 모든 성공의 시작이번 를 관통하는 핵심 메시지로, 디자인의 본질을 다시 생각하게 만드는 말이에요. 디자인의 본질은 문제를 해결하는 데 있으며, 그 시작은 작고 사소한 질문에서 비롯될 수 있다는 점을 강조하고 싶었다고 해요. 이번 컨퍼런스 기획을 주도한 Product Designer(Tools) 챕터에서는 이 메시지의 의도에 대해 이렇게 설명을 덧붙였어요.“디자이너가 이런 질문을 던졌기에 더 다양한 시도와 과정을 거칠 수 있었고, 결국 의미 있는 결론에 도달할 수 있었다고 생각해요. 이번 같은 질문들이 다뤄졌는데요. 이러한 사례를 공유하며, 청자 분들께서 이미 떠올려본 질문에 공감하거나, 앞으로 이런 질문을 던져볼 계기가 되길 바라는 마음이에요.” ” 그리고 그렇게 된다면, 메시지가 잘 전달되었다고 느낄 수 있을 것 같아요B2B SaaS 제품을 만드는 디자이너들은 업계 특성 상 참고할 수 있는 공식이나 환경이 부족해 고민을 해결하기 어려운 경우가 많은데요. 이번 에서 다뤄진 토스 Product Designer(Tools) 의 경험이 이러한 디자이너에게 실무적인 참고 자료로 활용되는 동시에, 혼자서 고민하던 문제들에 공감할 수 있는 장이 되길 기대해요.디테일은 메시지를 담는 그릇컨퍼런스를 준비하는 과정은 작은 질문에서 시작된다는 철학과 닮아 있었어요. 모든 요소의 디테일을 통해 청자에게 더 나은 경험을 전달하기 위해 설계되었거든요.“처음 맥북 내부를 열었을 때를 잊을 수 없어요. 보이지 않는 내부를 이렇게 아름답게 만들다니. 토스도 이와 같은 정신을 가지고 있다고 생각해요. 겉으로 드러나는 부분 뿐 아니라, 보이지 않는 내부까지도 치열하게 고민하며 디자인 Product Designer (Tools) 이다윗 님토스 서비스 또는 내부 효율화 제품도 이러한 철학이 깃든 결과물이에요. 이번 컨퍼런스를 통해 이 같은 디테일의 중요성을 보여주고, 업계 디자이너들에게도 공감과 동기를 제공하고자 했어요. 특히, 보이지 않는 곳에서 노력하는 디자이너들이 더욱 인정받고 공감 받는 계기가 되었으면 하는 바람도 담겨 있어요.이번 는 단순히 사례를 공유하는 것을 넘어, 청자 들이 더욱 편리하고 몰입감있게 컨퍼런스를 경험할 수 있도록 디테일까지 세심하게 신경 썼어요.특히, 작년에 진행된 에서 받은 피드백이 이번 컨퍼런스 설계에 큰 영향을 미쳤는데요. 피드백을 철저히 반영해 홈페이지의 무거운 동작을 최적화하고, 자막 이동을 더욱 직관적으로 개선했어요. 작은 참고 이미지는 크고 선명하게 보이도록 업데이트 했어요.이러한 노력은 단순한 기능 개선을 넘어, 청자에게

주요내용24년의 12월 소식에서는 다음과 같은 유용한 정보들을 만나보실 수 있습니다.State of Frontend 2024The Software House에서 발표한 프런트엔드 개발 설문 보고서입니다. 사용 기술, 개발 경험, 트렌드 등을 다루며, 중간중간 설문 결과에 대한 업계 전문가들의 인사이트가 정리되어 있어 흥미롭게 읽을 수 있습니다.Web AI: Client Side Machine Learning구글은 2024년 10월 18일, 웹 브라우저에서 클라이언트 측 기계학습 모델을 활용하는 개발자들을 위한 첫 번째 Web AI Summit을 개최했습니다Vercel Makes Changes to Next.js To Simplify Self-Hosting지난 10월 열렸던 Next.js 콘퍼런스에서, Next.js 15는 self-hosting을 위한 새로운 핵심 지원과 문서를 제공하며, 새로운 캐시 API도 곧 출시될 예정임을 밝혔고, Vercel의 프로덕트 VP인 Lee Robinson은 이에 맞춰 Self-Hosting Next.js라는 튜토리얼 영상을 공개했습니다.2024 당근 테크 밋업지난 10월 7일 열렸던 당근 테크 밋업의 모든 세션들이 공개 되었습니다.>> FE News 24년 12월 소식 보러가기 ◎ FE News란? 네이버 FE 엔지니어들이 엄선한 양질의 FE 및 주요한 기술 소식들을 큐레이션해 공유하는 것을 목표로 하며, 이를 통해 국내 개발자들에게 지식 공유에 대한 가치 인식과 성장에 도움을 주고자 하는 기술소식 공유 프로젝트 입니다.매월 첫째 주 수요일, 월 1회 발행 되고 있으니 많은 관심 부탁드립니다.▷ 구독하기

카카오는 내부 로그 수집 시스템으로 kemi-log를 운영하고 있습니다. kemi-log는 여러 가지 오픈 소스를 이용하여 구축되었으며, 특히 Fluentd를 메인 컴포넌트로 활용하여 수년간 운영해온 플랫폼입니다. 이 글에서는 Fluentd를 대체하기 위한 마이그레이션 프로젝트를 소개하고자 합니다. 구체적으로는 이러한 프로젝트를 진행하게 된 배경과 개발 과정, 그리고 실제 도입 후 달성한 성과에 대해 설명하고자 합니다.kemi-log는 현재는 발전하여 아래와 같은 구조를 가지고 있습니다.2개 레이어로 구성된 시스템 아키텍처의 log aggregator 영역은 2개의 레이어로 분리되어 있습니다. 1 layer는 사용자로부터 직접 로그 데이터를 수신하게 되고 2 layer는 1 layer로부터 데이터를 넘겨받아 각각의 스토리지로 데이터를 전송하는 역할을 맡고 있습니다.2개의 layer로 분리하게 된 이유는 스토리지 쪽으로 데이터를 보내는 기능이 시스템 자원을 많이 차지하고 운영상 이슈가 발생하는 경우가 있기 때문이었습니다. aggregator가 하나라면 특정 스토리지 전송 쪽 이슈가 발생했을 때 모든 aggregator가 영향을 받게 됩니다. 그래서 2개의 layer로 분리해서 1 layer에서는 일단 로그를 받아서 버퍼링을 하고 있고 2 layer를 통해서 받은 로그를 스토리지에 저장하도록 하고 있습니다. 2 layer도 스토리지 별로 여러 개로 그룹핑되어 있습니다. 특정 서비스의 로그 트래픽이 많은 경우 분리해서 관리하기 위한 용도와 스토리지 쪽 장애가 발생했을 때 그 때문에 다른 스토리지로의 적재에 영향을 미치지 않도록 하기 위해서 구분하는 용도입니다.Fluentd는 설정을 파일로 기록하고 관리합니다. 신규 로그 데이터를 받거나 기존의 설정을 변경하려면 설정 파일을 변경하고 업데이트해야 합니다. 이런 설정 작업이 자주 있습니다. 운영 초기에는 Ansible을 통해서 이런 변경사항을 반영하고 Fluentd를 재시작했었습니다. 운영경험이 쌓여 나가면서 작업 실수를 줄이기 위해서 여러 대의 Fluentd를 모아서 클러스터화 하고 그걸 통합해서 관리할 수 있는 tug라는 시스템을 만들어서 사용했습니다.tug는 중앙에서 전체 Fluentd들을 관리하는 역할을 하는 tug-server와 Fluentd와 같은 서버에 있으면서 tug-server로부터 Fluentd 설정을 받아서 반영하는 tug-agent로 구성되어 있습니다.직접 tug라는 Fluentd 설정 관리 시스템을 만들고, 필요한 경우는 오픈 소스인 Fluentd에 코드 기여를 하면서 운영해 왔지만 Fluentd의 구조상 한계에 부딪히게 되었습니다.Fluentd의 구조적 한계를 극복하기 위해 대체 Logriver라는 새로운 로그수집기를 자체 개발하게 되었습니다.Fluentd의 대안을 생각하면서 그동안 새롭게 나온 여러 가지 오픈 소스들을 대안으로 생각해 보았습니다. 하지만 이미 사내에서는 Fluentd를 통한 로그 수집이 표준화되어 있었기 때문에 카카오 내부의 수만 대의 서버에 Fluent

Intro: 수능은 누군가의 업무이기도..한국에서 11월은 공휴일이 하나도 없는 달이지만, 11월 둘쨰주 목요일은 특별합니다.특히 수험생이 있는 대부분의 가정에서 이 수능날이 지니는 무게는 여느 하루 이상일 것입니다.수험생/가족들만 11월에 초점을 맞추고 있는 건 아닙니다. 많은 기업들이 수능 관련 이벤트/프로모션을 준비하면서어떻게든 수험생들의 자유와 새로운 시작을 함께하고자 합니다.SKT도 마찬가지로, 매년 수험생을 위한 프로모션을 준비하고 있습니다.수험생의 마음을 사로잡는 프로모션을 기획하기 위해서는 그들의 행동 해턴을 파악하는 것이 중요한데, 이를 위한 방법 중 하나는 역시 데이터를 분석하는 것이겠지요.이번 글에서는 수능 이후 수험생분들이 어떤 행동을 보이는 지를 데이터를 통해 확인해보겠습니다.1. 데이터 분석을 위한 재료 준비: 가설 수립 및 데이터 정리데이터 분석은 질문에서 시작됩니다. 알고 싶은 것을 명확히 하지 않으면, 사내에 있는 수많은 데이터만 뒤적이다 끝날 가능성이 높습니다. (넵, 제가 많이 그랬습니다 😅😓😭)위와 같이 '알고 싶은 것'을 정리하고, 이것을 알기 위한 데이터가 사내에 있는지. 있다면, 어디에 어떻게 적재되고 있는지를 확인 합니다.이미 알고 있는 데이터들이라면 여기서 헤매지는 않겠지만, 처음 봐야하는 데이터가 있다면 이 단계에서 생각보다 지체되는 경우를 많이 보고 경험했습니다.데이터가 아예 사내에 없다면, 가설을 수정하거나 반드시 확인이 필요한 가설이라면 고객 데이터를 수집합니다.고객 데이터는 설문조사를 기획하거나 포커스 그룹 인터뷰를 진행하는 등 외부에서 수집할 수 있도록 계획을 변경할 필요가 있습니다.이번 수능 프로모션은 다행히 알고 싶은 것들에 대한 데이터가 사내에 적재되고 있었고, 제가 잘 알고 있는 DB였습니다.이런 사전 작업이 끝나면, 보통은 분석에 계속 쓰일 것 같은 정보를 모아 마스터 DB(혹은 테이블)를 만들어 놓는 것이 편합니다.수능 프로모션은 분석모수를 수험생으로 한정해야 될 필요가 있어서. 아래와 같이 수험생 모수를 특정한 테이블을 만들었습니다.이렇게 대략적인 작업 준비는 마쳤습니다.(TMI.) 테이블 이름은 업무와 연관성을 갖도록 짓는 네이밍 컨벤션(Naming Convention)이 필요한데, 생각해보니 수능을 영어로 뭐라고 하는지 모르겠더군요.찾아보니, College Scholastic Ability Test가 수능이라고 하네요. 그래서 csat_xx1, xx2등등으로 만들어두었습니다.2. 수능 이후 수험생들은 무엇에 관심이 있을까??먼저, 수능일(11.14) 이전/이후의 관심사 변화를 확인하였습니다.예상 혹은 상식과 크게 다르지 않은 분석 결과 입니다.조금 특이한 점이 있다면, 의료에 대한 관심인데 더 확인해보진 않았지만,아마도 성형 관련 앱과 성형 외과 방문이 영향을 줬을 가능성이 있습니다.아직까지는 '유레카'할만한 것이 없기는 한데,특별한/특이한 패턴을 찾지 못했다고 실망할 필요는 없습니다.가설을 숫자로 확인해보는 것 자체가 의미 있습니다.그리고, 세부적으로 나눠보면 새로

안녕하세요. 커뮤니케이션 앱 LINE의 모바일 클라이언트를 개발하고 있는 Ishikawa입니다. 저희 회사는 높은 개발 생산성을 유지하기 위해 코드 품질 및 개발 문화 개선에 힘쓰고 있습니다. 이를 위해 다양한 노력을 하고 있는데요. 그 중 하나가 Review Committee 활동입니다.Review Committee에서는 머지된 코드를 다시 리뷰해 리뷰어와 작성자에게 피드백을 주고, 리뷰하면서 얻은 지식과 인사이트를 Weekly Report라는 이름으로 매주 공유하고 있습니다. Weekly Report에는 Android나 iOS 같은 특정 플랫폼이나 Kotlin, Swift 같은 특정 언어에 한정되는 내용도 있지만, 대부분 프로그래밍 전반에 적용할 수 있는 주제로 작성해 공유하고 있습니다(단, 설명을 위해 사용하는 코드는 Kotlin을 사용하는 경우가 많습니다).이번에 블로그로 공유할 Weekly Report의 제목은 '한 번 엎지른 는 다시 주워 담지 못한다'입니다.한 번 엎지른 는 다시 주워 담지 못한다다음은 라는 함수로 로 시작하는 문자열에서 1~6자리 정수를 조회하는 함수입니다.이 코드의 문제점은 무엇일까요?에러를 전파하는 방법은 호출자가 해당 에러를 어떻게 처리하는지에 따라 달라집니다. 위 예시 코드는 두 가지 에러를 전파하고 있습니다.• 인수로 입력된 문자열의 형식이 잘못됨일반적으로 '호출자가 제공한 인수는 신뢰할 수 없다'고 생각해야 더 견고한 코드를 작성할 수 있습니다. 해당 인수는 사용자가 입력하거나 외부 시스템에서 제공 받은 것일 수도 있기 때문입니다. '잘못된 인수가 입력되는 것은 흔한 일이다'라고 전제하고 에러 처리를 구현해야 합니다. 한편, 정규 표현식 구현 실수는 함수에 국한된 에러입니다. 호출자는 이 에러를 신경 쓸 필요가 없으며, '복구할 수 없는' 에러여야 합니다.위 사실을 염두에 두고 각 에러의 표현 방법을 확인해 봅시다. 인수 형식 에러는 으로 표현하고 있으며, 정규 표현식 구현 실수는 클래스의 객체로 표현하고 있습니다. 과 같은 로직 에러는 대부분의 경우 해서는 안됩니다. 로직 자체를 수정해야 합니다. 반면, 정규 표현식 실수는 실제로는 로직 에러이지만 클래스를 사용해서 호출자가 처리하도록 강제하고 있습니다. 즉, 현재 에러를 처리하는 방법과 에러를 표현하는 방법이 서로 맞지 않습니다.프로그래밍 언어와 처리 시스템에 따라 다르지만 에러를 표현하는 방법은 매우 다양합니다. 그중 어떤 표 현을 사용할지는 해당 에러가 어느 정도로 복구할 수 있는 것인지를 참고하면 좋습니다.기본값은 호출자가 에러 발생 여부를 파악하지 않아도 되는 경우에 사용합니다.단순 도메인 에러는 에러가 발생했다는 사실은 알아야 하지만 에러의 내용까지는 알 필요가 없을 때 사용합니다. 대표적인 예로 조기 반환을 적용하는 경우가 있습니다.만약 정상적인 상태에서는 반환값이 없는 경우라면 에러 발생 여부를 나타내는 진위값을 반환값으로 자주 사용하며, 이때 대부분의 경우 가 에러 발생을 나타냅니다(단, C 언어에서는 이 정상 상태를 나타내는 경

LY Corporation의 개발 조직에서는 높은 개발 생산성을 유지하기 위해 코드 품질과 개발 문화 개선에 힘쓰고 있으며, 이와 관련된 다양한 활동 중 하나가 Review Committe 활동입니다. Review Committe 활동은 머지된 코드를 다시 한 번 리뷰하면서 리뷰어와 코드 작성자에게 피드백을 제공하는 활동이며, 리뷰하면서 얻은 지식과 인사이트를 매주 사내에 Weekly Report라는 이름으로 공유하고 있습니다.Weekly Report로 공유되는 주제로는 Kotlin이나 Swift와 같은 특정 언어에 국한되거나 Android나 iOS와 같은 특정 플랫폼에 국한되는 내용도 있지만, 대부분은 언어나 플랫폼에 상관없이 프로그래밍 전반에 적용할 수 있는 주제를 다루는데요. 이와 같이 일반적으로 널리 적용할 수 있는 주제를 골라 이 블로그에 '코드 품질 개선 기법' 시리즈를 연재합니다(단, 설명하기 위해 작성한 코드는 Kotlin으로 작성한 경우가 많습니다).코드 품질과 개발 문화 개선을 위해 저희가 어떤 노력을 하고 있는지 궁금하시다면 DroidKaigi 2021에서 발표한 '오래가는 코드 베이스의 '품질' 문제를 마주하다(일본어)'를 참고하시기 바랍니다.아래는 그동안 발행된 '코드 품질 개선 기법' 시리즈의 목록입니다.• 1편: 한 번 엎지른 는 다시 주워 담지 못한다

2023년 OpenAI dev day. 회사 소속으로 참여하려 했지만 OpenAI 측에서 사람이 너무 많이 지원했다며 짤렸던 슬픈 기억이 있다.올해에는 SF 이외에도 런던과 싱가폴에서도 개최되었고, 싱가폴에 포닥가있는 친구도 만날 겸 2024 OpenAI dev day 에 참석했다.내돈내산으로 갔다와서 그런지 더 뜻깊은 경험이었던 것 같기도 해서 후기를 남겨본다.2024 OpenAI dev day 는 Pan pacific hotel 에서 열렸다.이렇게 생긴 곳이었는데, 싱가폴에는 특이하게 구멍을 뻥뻥 뚫어놓고 식물을 잔뜩 심어놓은 호텔이 많다.11시에 호텔에 도착했는데 로비에서부터 OpenAI 직원분들이 반갑게 맞아주었다.싱가폴에서 열린 dev day 는 OpenAI 싱가폴 유닛의 오픈 행사를 겸한다고 한다.19층인가에서 행사가 열렸고, 들어가자마자 질문있으면 적어서 넣으라고 통이 준비되어 있었다.질문은 따로 안적었지만 종이는 하나 챙겼다.행사는 12시반에 시작되고, 11시~12시반까지는 데모 부스를 구경하거나 networking zone 에서 간단한 점심을 먹으면서 기다리는 시간이 있었다.데모는 총 6가지로 비디오 생성 모델인 Sora, 이미지 생성 모델인 Dall-e, audio 모드의 gpt-4o 그리고 chatGPT API 관련 distillation, evaluation, reasoning and coding ability 그리고 realtime api 를 시연했다.chatGPT 관련된 부분들은 이후 speech 에서도 발표되는 내용들이었고, 궁금한 점들을 이것저것 물어봤다.Sora 는 비디오 생성 모델로 https://openai.com/index/sora/ 에 가면 자세히 나와 있다.실제 홈페이지에 올라온 영상들을 그냥 틀어주는 데모였다. 가서 이거 대체 모델 사이즈가 어떻게 되냐고 물어봤는데,라고 대답해줬다. 암튼 sora 는 API 로 풀리지도 않았고, 아주 자세히 들여다보면 디테일이 조금 무너지는 부분들이 있다.아마도 체리픽 해서 홈페이지에 올려놓은 거 같고, API 공개 시점까지 더 발전시킬 계획이 아닐까 싶다.이건 뭐...이제는 평범한 기술이 되어버린 것 같다. 그냥 간단한 이미지 생성과, gpt-4o 로 농담이랑 하이쿠 생성하는 데모였는데, 재밌는건 데모 하드웨어에 힘을 빡 줬다.이렇게까지 만들 일인가?? ㅋㅋㅋ Joke 라는 버튼을 누르면 농담을 생성한다. 굳이...??Distillation 과 Evaluation 은 이번에 출시된 기능들이다.Distillation 의 경우 큰 모델을 이용해 작은 모델을 학습하는 기능으로 prompt 로만 구성된 데이터로 학습이 가능하다는 장점이 있다.Evaluation 의 경우 fine-tune 된 모델의 성능 파악을 위한 데이터셋을 업로드하고 metric 을 선택하거나 직접 작성하면, 평가까지 해주는 기능이다.사실 LLM 지식이 좀 있으면 굳이 없어도 되는 기능이다. fine-tune API 만 있어도 충분하니까. 다만 노코드로 학습 및 평가까지 가능하게 만들어 줬다는 것에는

안녕하세요. 저는 토스 팀원들이 더 쉽고, 효율적으로 유저 리서치를 할 수 있는 환경을 만드는 일을 하고 있어요.유저 무물데이를 어떤 분들이 어떻게 활용하고 있는지 살펴보니, PD (Product Designer)분들이 제품 출시 전, 프로토타입 테스트 용도로만 주로 활용하고 있는 것을 발견했어요.프로토타입 테스트뿐 아니라 제품 배포 후 실제 앱에서 사용자들이 어떻게 쓰는지 보는 것 또한 프로토타입 테스트만큼 중요한데, 라이브 환경에서 사용성 테스트 (UT)는 많이 하고 있지 않다는 것을 데이터로 확인했어요.그래서 몇몇 PD분들을 만나 그 이유를 여쭤봤어요. 제품 배포 후에는 데이터가 쌓이니 지표나 다양한 채널로 들어오는 cs나 voc를 통해 문제를 파악하거나 A/B 테스트로 검증할 수 있어 굳이 리소스를 들여 사용자를 만나 정성조사를 할 필요를 못 느끼는 분들도 있었고, 라이브 UT에서 문제가 나와도 당장 사일로에서는 매출, 유저 수, 리텐션 등 지표와 관련 있는 다음 실험을 준비하기 때문에 우선순위에 밀려 제품 개선이 이루어지기 쉽지 않다고 이야기해 주시는 분들도 있었어요.PD분들은 사용성에 문제가 있다는 것을 인지하고 있더라도, 제품은 팀원들 다 같이 만들다 보니 제품을 변경하려면 공감대 형성이 필수적이었는데 혼자서는 라이브 UT를 진행하는 것부터 진행 후 문제 개선을 설득하기 쉽지 않았던 것이죠.각 팀에서는 매출, 전환율 등 팀의 목표 달성이 중요하다 보니, 전체 제품의 정성적 사용성에 대해서는 우선순위가 밀릴 수밖에 없었어요. 이 문제를 중요하게 생각하는 팀원이 있다고 해도, 나머지 팀원들과 공감대를 형성하려면 논의가 길어져서 시간이 오래 걸리는 문제도 있었죠. 사용성을 중요하게 생각하는 프로덕트 디자이너는 어떤 디자인이 사용성이 좋고, 좋지 않은지 알고 있지만 다른 팀원들은 사용자의 경험을 직접 본 적이 없기 때문에 공감하기 어려워하는 상황이 발생했어요.그래서 PD 분들뿐만 아니라 사일로 구성원 모두 비슷한 유저 감수성을 갖는 것이 중요하겠다 생각했어요. 우리는 토스 앱을 매일 보니 너무나 쉽고 당연하게 이용하는 것도, 유저는 못 보고 지나치거나, 이해하지 못하고, 이용하기 어려워한다는 것을 말로 설명하는 것보다 직접 보여 드려야겠다고 생각했죠.게다가 PD, PO (Product Owner), PM(Product Manager), 이 외의 개발자, DA(Data Analyst) 등 다른 직군들은 열심히 제품은 만들고 계시지만, 실제로 유저가 어떻게 쓰는지 볼 기회가 없었어요. 이러한 기회를 만들어 주는 것이 필요하겠다고 생각했어요.어떻게 중요성을 효과적으로 알릴 수 있을까?사일로 팀원들이 뚜렷한 목적이나 준비를 하지 않더라도 사용자 인터뷰에 참여해 생생한 유저의 목소리를 듣는다면, 유저에 대한 공감대가 높아지고 유저 리서치의 중요성과 필요성을 체감할 것이라고 생각했어요.유저의 생생한 목소리를 듣도록 하려면, 듣는 것 이 외의 모든 준비 과정이나 허들을 없애야 한다고 생각했어요. 그리고 실제로 아무 준비 없이 몸만 와도 괜찮다고

저번 아티클에서는 실무에서 AI를 실제로 잘 활용하기 위해 필요한 것들을 소개해 드렸어요. 이번 글에서는 사용자 처럼 말하는 휴리봇을 만들며 얻은 AI 프롬프팅 팁을 공유해보려 해요.여러분은 프롬프트 엔지니어링 경험이 있으신가요?봇을 만들기 위한 프롬프팅은 쉽게 말해 페르소나를 만드는 과정이라고 생각하시면 돼요. ‘너는 OOO한 역할이고, OO상황에서 OO라고 이야기하고…’ 이런 식으로 내가 원하는 상을 AI에게 주입 시키는 거죠.*프롬프트(prompt)란? 생성형 AI에 특정 작업을 수행하도록 지시하는 자연어 텍스트로, 고품질의 아웃풋을 생성하기 위해 프롬프트를 최적화하는 프로세스를 ‘프롬프트 엔지니어링’이라고 함한 번이라도 프롬프팅을 시도해 보셨다면, 어디서부터 시작해야 할지 막막했던 경험이 있으실 거예요. AI가 하는 답변이 너무 당연하거나 추상적일 때도 있어서 진짜 똑똑한 게 맞는지 의심이 들 때도 있었을 것 같고요.효율적으로 프롬프팅을 하기 위해서는 우선 AI를 이해하는 것이 중요해요. AI는 어떻게 질문하는지에 따라 천차만별의 결과를 뱉는데, AI를 잘 이해하고 있어야 그들이 잘 이해할 수 있는 질문을 던질 수 있어요.저 역시도 휴리봇을 만들기 전까지는 챗GPT도 거의 써본 적이 없을 정도로 AI와는 거리가 먼 사람이었는데요. 그런 저의 입장에서, 휴리봇처럼 ‘사람처럼 말하는 봇’을 만들고 싶으신 분이라면 쉽게 이해하실 수 있게 설명해 드릴게요.내가 해결하고자 하는 문제, AI로 해결하기에 적합할까?프롬프팅을 시작하기 전, 지금 해결하고자 하는 문제가 AI로 해결하기에 적합한 문제인지부터 생각해 봐야 해요. AI에 학습시킬 수 있는 데이터가 아주 방대하고 정확한 경우가 아니라면 AI는 정해진 답변보다는 창의성 있는 답변이 필요한 경우에 더 적합할 수 있어요.가장 큰 이유는 생성형 AI에서는 종종 발생하는 할루시네이션 현상 때문인데요, 정확한 정보를 기반으로 답변을 줘야 하는 봇을 만드는 상황에서는 거짓된 정보를 주는 이 현상이 치명적일 수 있어요. *할루시네이션(Hallucination)이란? AI 환각 현상. 생성형 AI가 실제로 존재하지 않거나 사실이 아닌 정보를 사실인 것처럼 말하는 현상실제로 팀 내에서 채널에 오는 반복 문의에 대응하는 데에 많은 리소스가 드는 문제가 있었고, 이 문의에 대신 답변해 주는 CS 봇을 만들었던 경험이 있어요. 오랜 시간 많은 데이터를 학습시켰지만, 가끔 뜬금없는 소리를 하거나 틀린 답변을 그럴싸하게 하기도 해서 문의하시는 분들에게 혼란을 주는 문제가 있었고, 잘못된 답변을 정정하느라 오히려 더 많은 리소스가 들게 되어 결국 없애게 되었어요. 혹시 여러분도 위와 같은 형태의 문제를 고민 중이시라면, AI가 아닌 다른 해결책을 더 고민해 보시는 것도 추천해 드려요.사람처럼 말하는 봇 프롬프트 쓰는 팁1. 규칙이나 예시 답변보다는 명확한 역할과 상황 부여하기휴리봇처럼 자유도가 높은 답변을 주는 봇의 경우엔 예시 답변을 학습시키기 보다는 명확한 역할과 상황을 부여하는 것이 더 효과적이에요. 휴리봇