이전에 소개해드린 대로 진화된 음향 서비스에서 운전할 때 티맵이 친구처럼 말벗이 되어주는 AUTO 이야기를 꺼내 보려고 합니다.AUTO에서는 차량기능을 제어하거나 네비게이션 기능을 넘어서 실시간 대화를 하는 방식들로 전환되고 있습니다.이러한 기능을 사용하기 위해서 운전자는 핸들에서 손을 떼지 않고 음성을 통해 제어하게 됩니다.따라서 AUTO와 대화를 하기 위해서는 차량 마이크로 들어가는 음성의 품질이 중요합니다.오늘은 국내 AI 차량 서비스 선두주자의 역할을 하는 AUTO에서 음성 품질을 확보하고 판단하기 위해 어떠한 음향기술 요소가 쓰이는지 알아보겠습니다.일전에 휴대폰에서 언급했듯이 음성이 뭉개어지고 왜곡되고 지저분해 지는 거슬림의 요인들을 제거해야 좋은 음성 품질을 확보할 수 있습니다.거슬림의 요인들은 차량에서도 마찬가지로 발생하는데 특별히 차량에서만 발생하는 부분들이 어떤 것이 있을까요?내연기관은 연료를 연소시켜 동력을 생성하는 엔진으로 이 과정에서 발생하는 엔진(시동) 잡음이 있고,또한 그린하우스의 헤드라이너, 썬바이저, 오버헤드 콘솔 및 대시보드 등의 마이크 위치에 차량크기, 마감상태, 외부요인 등에 따라 잡음의 양상이 다르게 나타납니다.이외에도 다양한 요인들이 있고 이러한 요인들이 결합되어 거슬림의 요인을 형성하게 됩니다.아래는 내연기관이 다른 차량별 엔진 잡음의 예시입니다.차량을 시승해보면 어떤 차는 시동을 걸면 정차중이더라도 덜덜 거리면서 잡음이 느껴지는가 하면 어떤 차는 고요하듯이 조용한 차가 있음을 경험해 보셨을 것입니다.이는 차량별로 엔진 잡음의 특성 차이가 있기 때문입니다. 차량의 잡음은 대부분 1kHz 이하의 신호에 에너지를 가지고 있고 차량별로 그 크기와 특성이 달라지게 됩니다.그렇다면 주행을 하게 되면 어떻게 될까요?정차와 유사한 잡음 특성을 유지하면서 그 에너지가 더 커지게 되고 음성신호의 주요 대역이 마스킹 되는 효과를 보입니다.주행 속도가 증가할수록 잡음의 특성은 유지되지만 잡음의 크기는 더욱 증가합니다.차량의 고유 잡음특성과 함께 거슬림의 주요 요인인 더 낮은 SNR 상황을 나타나게 합니다.마감이 제대로 되지 않는 차량 상태에서는 어떨까요?주행 중에 정숙하지 않다고 느끼는 차량의 경우 필러 사이로 풍절음의 유입의 영향을 보입니다.일반적으로 바람을 등지고 운행할 때보다 바람을 맞으며 달릴 때 풍절음의 유입은 더 커지게 되고 이는 차량 마이크 위치에 따라서도 달라지게 됩니다.마이크가 가려지고 숨어 있다면 어떨까요?음성이 마이크로 도달하는 경로가 차단되고 왜곡되어 음성의 품질이 저하되고 주변 잡음이 더 많이 유입되게 됩니다.이처럼 고유의 차량잡음 특성과 함께 차량 상태나 마이크 상태, 외부요인에 의한 거슬림 요인들이 더해지게 됩니다.AUTO에서는 당사의 우수한 내재화 전처리 기술과 함께 이러한 거슬림 요인을 사전에 체크하고 제거하는 부분을 음향 기술 요소 중에 “음향 측정과 분석”을 통해 진행하고 있습니다.거슬림 요인들을 하나씩 제거하고 음성 신호에 영향을 주는지 여부를 판단해야 하는데, 실차에서의 측정은 고

안녕하세요. 여기어때컴퍼니 QA1팀 루시안입니다. 앞서 같은 팀 요셉이 QA팀에 도입하게 된 Robot Framework를 통한 테스트 자동화에 대해 소개했었습니다.(Robot Framework와 QA팀 동행기: 시작과 도전(1))이번엔 Robot Framework를 통해 여기닷컴(http://www.yeogi.com)에 적용한 웹 테스트 자동화에 대해 소개하겠습니다.웹 테스트 자동화의 장점 파악웹 테스트 자동화를 시작하면서 먼저 진행한 것은 장점 파악이었습니다. 웹 테스트 자동화에 대한 장점을 먼저 파악 후, 이 부분들을 최대한 살리면서 자동화를 진행 해보려고 했습니다. 저희는 아래의 장점들로 여기닷컴에 먼저 웹 테스트 자동화를 적용했습니다.첫째, 다양한 플랫폼에서 테스트가 가능합니다.웹은 크로스 플랫폼을 지원하기에 윈도우, 맥, 리눅스 등 다양한 운영체제에서 동일한 브라우저 기반 테스트가 가능합니다. 그로인해 웹에서는 동일한 테스트 스크립트를 여러 플랫폼에서 쉽게 실행할 수 있습니다. 또한, PC, 태블릿, 스마트폰에서 동일한 인터페이스로 접근할 수 있어, 다양한 기기와 해상도를 고려한 테스트 자동화를 실행할 수 있습니다.이번에 웹 테스트 자동화를 진행하는 인원들이 윈도우, 맥과 같은 다른 운영체제에서 각각 스크립트를 작성하였지만 모두 동일한 브라우저 기반 테스트가 가능한 점도 이 부분 때문이었습니다. 그리고 현재 여기닷컴은 반응형 웹으로써 태블릿과 스마트폰 해상도를 지원하고 있습니다. 해상도 변경을 통해 다양한 해상도에서 자동화 테스트가 가능합니다.둘째, 브라우저 호환성 테스트에 활용할 수 있습니다.웹 테스트 자동화는 하나의 스크립트로 여러 브라우저(크롬, 파이어폭스, 사파리 등)에서 호환성 테스트를 쉽게 수행할 수 있습니다. 브라우저 호환성 테스트가 쉽다는 건 동일 시간내 이전보다 테스트를 더 많이 수행 할 수 있고, 더 많은 브라우저, 더 많은 버전에 대한 테스트가 가능해져 원하는 만큼의 브라우저별/버전별 호환성 확인이 가능하다는 걸 의미합니다.현재 구축 해놓은 웹 테스트 자동화 스크립트는 위의 장점을 활용해 하나의 스크립트로 크롬, 파이어폭스, 사파리 브라우저 환경만 변경 해서 테스트 할 수 있도록 구성해 두었습니다.셋째, 브라우저의 개발자 도구를 활용할 수 있습니다.웹 테스트 자동화는 브라우저 개발자 도구를 통해 네트워크 요청, 콘솔 로그, 성능 측정 등의 추가적인 디버깅 정보를 쉽게 얻을 수 있고 스크립트 작성을 위한 Locator의 정보도 얻어낼 수 있습니다. 그리하여 테스트 스크립트를 작성하면서 각 Element에 대한 Locator 값을 얻어낼 수 있었습니다. 이 Locator값을 유니크한 값으로 축약시킨 후, 브라우저 개발자 도구에서 DOM 검색을 통해 축약한 Locator값이 맞는지 확인 또한 가능했습니다. 축약한 Locator값을 적용함으로써 테스트 코드에 대한 가독성을 증가시킬 수 있었고 유지보수가 쉬워졌습니다. 그리고 팀 협업 시 표준화 효과 또한 얻을 수 있었습니다.넷째, 리소스 소비를 줄인 경량화 테스트가

안녕하세요! 여기어때 검색플랫폼개발팀의 레미입니다.Elasticsearch에서 같은 사각형 영역을 검색할 때, Box 방식과 Polygon 방식의 성능은 어떻게 다를까요? 공간 검색은 위치 기반 서비스를 구현할 때 매우 중요한 기능입니다. 특히, 검색 영역이 사각형인 경우, Box와 Polygon 두 가지 접근법 중 어떤 것이 효율적인지 판단하는 것은 검색 속도와 효율성을 높이는 데 큰 영향을 미칠 수 있습니다.이번 글에서는 두 방식을 비교 분석하고, 그 결과를 여러분과 공유하려 합니다. 🚀1. 테스트 개요📌 목적동일한 검색 영역에 대해 Polygon 방식과 Box 방식의 성능을 비교하여 최적의 검색 방식을 선정하기 위함입니다. 특히, 박스 방식은 좌표 두 개(좌상단, 우하단)를 사용하고, 폴리곤 방식은 사각형의 네 꼭짓점을 모두 명시하기 때문에 이 차이가 성능에 어떤 영향을 미치는지 알아보았습니다.📝 테스트 환경테스트 데이터: 10만 개의 좌표 데이터검색 영역: 동일한 사각형 영역 적용색인 방식: geo_point검색 엔진: Elasticsearch검색 쿼리 방식2개 좌표 검색: GeoBoundingBoxQuery 사용4개 좌표 검색: GeoPolygonQuery 사용📊 측정 항목🕒 Mean_Test_Time(ms): 평균 응답 시간 (낮을수록 우수)⚡ TPS (Transaction Per Second): 초당 처리 건수 (높을수록 우수)📦 Mean_response_length: 평균 응답 데이터 크기이제 본격적으로 두 방식의 성능을 비교해볼까요? 🤔2. 테스트 결과 요약📊 특이사항:두 방식 모두 평균 응답 시간(MTT)과 TPS에서 큰 차이 없이 유사한 성능을 보였습니다.특정 구간에서는 박스 및 폴리곤 방식 모두 다소 변동이 있었으나, 전반적으로 비슷한 성능을 유지했습니다.평균 응답 길이(Mean_response_length)는 두 방식에서 완전히 동일하게 측정되었습니다.📌사실, 테스트 전에는 박스 방식이 더 단순한 구조를 가지므로 성능이 더 좋을 것이라고 예상했지만, 결과는 다소 의외였습니다. 예상 외로 두 방식 모두 비슷한 응답 속도를 보여주었기 때문입니다. 이는 Elasticsearch 내부의 공간 필터링 처리 방식이 매우 최적화되어 있다는 것을 보여주는 사례입니다.3. 분석 결과3.1 📌이론적 성능 예상🟦 박스 방식:단순 사각형 경계 검색 방식으로, 계산량이 적고 더 빠를 것으로 예상했습니다.박스는 좌상단(top_left)과 우하단(bottom_right) 두 개의 좌표만을 사용해 검색 영역을 정의하므로, 불필요한 계산이 적습니다.2. 🔺 폴리곤 방식:비정형 다각형 검색 방식으로, 사각형 영역을 포함한 4개의 꼭짓점 좌표를 사용합니다.따라서, 추가적인 계산 비용이 발생할 것으로 보았습니다.3.2 🔍 실제 테스트 결과 차이 원인 분석하지만 실제 결과는 예상과 다르게 두 방식의 성능 차이가 거의 없었습니다. 🧐 그 이유는 Elasticsearch가 geo_point 필드를 활용해 최적화된 인덱스를 생성하기 때문입니다. 또한, 사각

어플리케이션을 운영하다 보면, 트래픽 증가나 사용자 경험 개선, 비용 절감 등 다양한 요인으로 인한 성능 개선 요구가 꾸준히 제기됩니다. 저희 팀에서 운영하고 있는 Flink 어플리케이션도 비즈니스 요구사항을 만족시키기 위한 지속적인 성능 튜닝이 필요했습니다. 하이퍼커넥트의 대표 Product인 Azar의 핵심이 되는 1:1 매칭 서비스는 Flink 어플리케이션으로 구현되어 있는데, 특히 스와이프 직후 매칭이 이뤄져야 하는 Azar의 특성상, end-to-end latency는 사용자 만족도와 직결되므로 매우 중요합니다. 이에 따라 성능상 병목 구간을 정확히 찾아내고, 찾아낸 문제를 해결하는 과정이 지속적으로 필요했습니다. 이 글에서는 이러한 Flink 어플리케이션의 end-to-end latency를 낮추기 위해 병목을 진단하고 개선 포인트를 도출해나가는 과정을 소개하고자 합니다.Flink 어플리케이션의 end-to-end latency 개선 포인트를 찾아내는 과정은 크게 두 단계로 나눌 수 있습니다.• Application level: 전체 어플리케이션에 걸쳐 Flink operator 단위로 지표를 상세하게 수집하고 관찰하여 비정상적으로 느린 부분을 찾아냅니다.• Operator level: 찾아낸 Flink operator에 대한 프로파일링을 진행하고, 이후 코드 레벨의 inspection을 수행합니다.지금부터 각 단계에 대해 상세히 다뤄보겠습니다.End-to-end latency를 개선하기 위해서는 먼저 Flink의 각 operator 별로 처리에 소요되는 시간을 정확히 파악해야 할 필요가 있습니다. 이렇게 파악만 하더라도 기대와 다르게 느린 지점을 단번에 찾아낼 가능성이 있습니다.이를 위해서 Flink 어플리케이션의 각 operator에 2종류의 히스토그램 지표를 추가하는 작업이 필요합니다.• 처리 시간: , 와 같은 어플리케이션 코드가 input을 처리해서 output을 생성하기까지 걸리는 시간• 처리 외 시간: 처리 시간 밖의 모든 시간. Flink에서 데이터를 de/serialize하거나 네트워크 I/O를 하는 시간 등이 포함됩니다.지표를 처리 시간과 처리 외 시간의 두 종류로 분리하였는데, 이는 둘 중 어느 곳이 병목이냐에 따라 해결 방식이 완전히 달라지게 되기 때문입니다. 만약 처리 시간이 병목이라면 어플리케이션의 로직을 점검하거나, DB I/O 시간 등을 확인해야 할 수 있습니다. 반대로 처리 외 시간이 병목이라면 네트워크 I/O와 관련된 트러블슈팅을 진행하거나 Flink 내부 코드와 관련된 작업을 해야 할 것입니다.그림 1. 처리 시간과 처리 외 시간 지표가 각각 커버하는 구간의 예시코드 작업을 통해 지표를 추가하고, 운영 환경에 배포하여 각 operator의 처리 시간과 처리 외 시간을 다음과 같이 수집할 수 있습니다. (이 글 끝에 부록으로 지표 추가 코드의 예시를 실어 놓았습니다)그림 2. 위 예시에서 수집한 지표를 모아 파이 차트로 나타낸 것 처리 시간은 Operator 1, 처리 외 시간은 Operator

이번 토스 피플에서는 Product Designer 이지윤 님의 인터뷰를 공유드려요. 지윤님은 여러 도메인의 회사들을 거쳐 토스에 입사하셨고, 토스 안에서도 총 10 개 내외의 팀을 거치며 다양한 경험을 쌓으셨어요. 토스에서 했던 주요 프로젝트는 함께 토스 켜기, 전체 탭 및 홈 탭 개선 등이 있고, 지금은 새로운 서비스에 유저를 끌어오는 그로스 일을 하고 계세요.Q. 지윤님은 토스에 오시기 전에 4개의 회사에 다니셨다고 들었어요. 가장 기억에 남는 곳은 어디인가요?아무래도 A회사였죠. 당시 학교에 다니고 있었을 땐데, 펠로우십 공고를 보고 반드시 지원해야겠다고 생각했어요. 제 전공이 산업 디자인이었는데, 제품 디자인은 진짜 장인 정신과 디테일이 중요한 분야더라고요. 저는 디테일에 강한 타입이 아니라는 걸 스스로 알고 있었고, UX/UI는 학점이 괜찮았어서 이 쪽으로 가야겠다고 생각하고 있었어요. 너무 하고 싶어서, 다른 분들이 이 공고를 못 봤으면 좋겠다고 바랄 정도였죠.감사하게도 참여할 기회를 얻게 됐는데, 졸업 전시를 준비하면서 매주 펠로우십 과제를 하는 일정이었거든요. 재미도 있었지만 너무 힘들었어요. 인턴과 정규직 전환 등의 기회가 있었는데, 모두에게 기회가 주어지지 않았기 때문에 분위기가 조금 경쟁적이기도 했고요. 마지막엔 완전히 지쳐서, 결국 정규직에 전환되지 못했었어요.Q. 졸업 전시에 과제, 경쟁까지… 듣기만 해도 진이 빠지네요. 토스에는 어떻게 오게 되셨나요?인턴 기간이 끝나고, 대기업 준비하는 것보다 작은 회사에 들어가서라도 빨리 경험을 쌓아야 겠다는 생각을 했었어요. 실제로 큰 기업들에 합격하기도 했는데, 뭔가 제가 거기에 다닌다는 게 잘 상상이 안되더라고요. 그래서 서류 합격했는데 더 진행하지 않았었어요. 이후에 두 곳 정도의 스타트업에 다니다가 퇴사하게 됐는데, 우연히 토스에 다니고 있던 디자이너 분께 연락을 받아서 지원하게 됐었죠.솔직히 처음에는 ‘내가 감히?’라는 생각도 했었어요. 왜냐면 제 경력이 2년도 채 되지 않을 때였고, 토스가 워낙 유명했었으니까요. 실제로 와보니 굉장히 힘들었던 것도 맞는데, 도파민이 장난 아니긴 했었죠. 바로 옆에 승건 님이 일하고 계시고, 저도 제 제품에 욕심이 많았거든요.Q. 2년 차 되었을 때는 점수가 엄청 떨어졌네요.네… 저희끼리는 2년 병이라는 말도 하는데요. 허니문 기간 동안 폭발적인 성장을 하고, 끝나고 나서 점점 떨어졌어요. 당시 토스는 인원이 적기도 하고 직급이 뚜렷하게 나뉘어져있던 때가 아니어서, 영향력이 엄청 중요했거든요. 그런데 저는 주니어라 경험도 부족했고, 그러다보니 어쩔 수 없이 제가 다룰 수 없는 영역들이 있다고 생각했던 것 같아요.그러다가 유저 그로스할 때 엄청 올라갔던 것 같아요. 그때 PO가 승건 님이었거든요. 바로 옆에서 승건 님이 일하시는 걸 보면서 엄청 압축적으로 배울 수 있었죠. 가장 충격적이었던 건 승건님은 전체 회사의 대표임에도 완전히 디테일하고 집요하게 사용자에게 집착한다는 점이었어요. 멀리서 보았을 땐 아무래도 대표라는 자리이니 큰

주변에서는 AI 시대가 온다고(이미 와 있지만) 하고 있고, 회사에서도 사내 챗봇을 도입하는 등 많은 변화가 느껴지고 있습니다.하지만 이 모든 일은 남의 일이려니 하는 생각 이었죠..😅몇 일전 우연히 Cursor 라는 VS Code 기반의 코드 편집기를 봤는데, 사용자가 입력한 말 몇 마디로 프로그램을 짜 주는 모습을 보고 정말 놀라움을 느끼게 됐습니다.Chat GPT로 보고서를 요약하고, Cursor 로 코드를 만들고 디버깅 및 실행까지 해주는 이런 일상들이 앞으로 가속화 될 것 같다는 생각에 늦었지만 AI 에 대한 학습을 시작해 보려고 이 글을 작성하게 됐습니다.여러 전문가분들이 많으시지만 AI 에 대한 관심만 있고 실제 어떻게 사용하는지 모르는 분들과 함께 공부하는 마음으로 시작해 보려고 합니다.2. LLM(Large Language Model) 이란 무엇이고 Lang Chain은 도대체 어떤 걸까?AI에 대해 전혀 경험이 없고, 모르다보니 LLM 이라는 단어는 많이 들어봤는데 도대체 LLM 은 뭐고, Lang Chain 은 어떤 것인지 먼저 알아 보기로 했습니다.AI 에 대해서 잘 모르시는 분들도 챗 GPT 에 대해서는 아실 거에요. 저도 개인적으로 Chat GPT 유료구독(Chat GPT Plus)를 $20 에 월 구독해서 사용하고 있습니다.이걸로 영어공부도 하고, 해외 여행가서 번역으로도 사용하고 회사에서도 아주 유용하게 잘 사용을 하고 있어요.ChatGPT 는 사용자와 대화를 하면서 정보를 주는 아주 훈련이 잘 된(fine-tuning) 채팅용으로 개발한 서비스이고 실제 ChatGPT는 GPT-4, GPT3.5 등 언어 모델을 가지고 있습니다.이 GPT4, GPT3.5 등이 아주 많은 데이터를 바탕으로 학습을 한 모델이라고 보면 되고, 이 모델을 대화형으로 사용하기 위한 서비스가 ChatGPT 라고 보면 될것 같아요.GPT4, GPT3.5 등을 LLM(Large Language Model) 이라고 합니다. OpenAI 라는 회사에서 만들었고 이 외에도 다양한 LLM Model 등이 있습니다.아래 이미지는 Chat GPT 에게 물어본 주요 LLM 모델 들이에요.LLM은 방대한 정보를 가지고 있지만 한계가 있습니다.먼저 기억력이 없는 건데요.. Chat GPT 랑 얘기하다보면 문맥을 계속 이어서 대화할 수 있지만 LLM 은 기억력이 없기 때문에 앞에서 한 대화내용을 뒤에서 이어가지를 못 합니다.그리고 인터넷 검색을 하지 못하는(옵션을 키면 된다고 들었습니다) 한계가 있기 때문에 말은 그럴싸하게 대답하지만 그 정보가 엉터리 일 수가 있어요.(환각 이라고도 합니다)오직 텍스트 처리만 가능하기 때문에 문서나 다른 백앤드 정보를 가져오지 못하는 등의 한계점이 있습니다.그래서 Lang Chain 이라는 프레임워크가 만들어지게 되었고, LLM 을 정말 사람처럼 대화도 하고 실시간 정보 검색도 하고 외부 도우 사용도 가능하게 하는 기능을 제공하게 됩니다.쉽게 말하면 GPT3.5 를 Lang Chain 을 사용해서 개발해서 Chat GPT 를