안녕하세요. 여기어때컴퍼니 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 필드를 활용해 최적화된 인덱스를 생성하기 때문입니다. 또한, 사각

이번 토스 피플에서는 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 를

Karpenter 트러블슈팅 — 비용과 안정성 두 마리 토끼 잡기안녕하세요, 저는 당근페이 인프라팀에서 Site Reliability Engineer로 일하고 있는 Yany라고 해요. 저희 팀은 당근페이의 인프라를 안정적으로 관리해요. 개발자들의 프로덕트 개발 속도를 향상하고, 동시에 비용도 최적화하죠.저희는 클러스터 오토스케일링 없이 ASG(AWS EC2 AutoScaling Group)로, 그리고 HorizontalPodAutoscaler 없이 클러스터를 관리하고 있었어요. 여기에는 몇 가지 문제가 있었어요:스케일 아웃 과정에서 네트워크에 여러 병목 지점이 생겼어요.클러스터 업데이트를 진행하면서 ASG마다 AMI를 업데이트해야 했고, 오토스케일링이 원활하지 못했어요.컴플라이언스 이슈로 인해 분리된 노드, 서브넷에서 동작해야 하는 워크로드가 증가하면서 ASG가 늘어나 관리 포인트가 증가하고 있었어요.새벽 시간대에 트래픽이 현저히 적은 것에 비해 리소스를 너무 많이 사용하고 있었어요.당근페이의 거래량과 유저 수가 급격히 증가하면서, 기존의 ASG 기반 인프라 운영 방식으로는 한계가 명확해졌어요. 이에 따라 더 유연하고 자동화된 클러스터 스케일링이 필요했고, 그 해답으로 Karpenter를 도입하게 되었어요.그 여정은 저희가 생각한 것만큼 마냥 쉽지만은 않았는데요. 이번 글에서는 그 트러블슈팅 과정을 구체적으로 소개해드리려고 해요. Karpenter 도입을 고민 중이시거나 더 효율적으로 사용할 방법을 찾고 계신다면, 이 글이 큰 도움이 되길 바라요.Karpenter란?Karpenter는 쿠버네티스 클러스터에서 파드의 수요에 맞춰 노드의 양을 조절하는 Cluster Autoscaling Operator에요. 여러 컴포넌트를 통해 원하는 규격의 노드를 생성하고, 생성된 노드의 생명주기를 관리하도록 도와줘요.출처: [https://karpenter.sh/]대표적인 기능은 아래와 같아요:ProvisioningPending 상태의 파드가 존재하면, 스케줄링을 통해 필요한 노드를 생성하여 해당 파드가 스케줄링될 수 있도록 해요.각 CSP(Cloud Service Provider, 저희의 경우 AWS가 여기에 해당해요.)에서 만든 NodeClass 구현체를 통해 인스턴스의 규격을 정해요.- AWS로 가정했을 때 AMI, Subnet, Storage, Security Group, Userdata 등 EC2 인스턴스 자체와 관련된 설정을 진행할 수 있어요.NodePool을 통해 기존 ASG처럼 목적별로 노드를 생성할 수 있어요.- 여러 타입의 인스턴스를 생성할 수 있어, Cluster Autoscaler (이하 CA)보다 훨씬 효율적으로 스케일링을 진행할 수 있어요.DisruptionDrift: NodeClass, NodePool이 바뀌면 Drift를 통해 노드들을 원하는 상태로 Sync할 수 있어요.Consolidation: 충분히 사용하고 있지 않은 노드를 삭제해서 최적화된 양의 리소스를 사용할 수 있어요.- SingleNodeConsolidation

최근 몇 년간 생성 모델은 인공 지능 분야에서 혁신적인 도구로 부상하며 연구자와 산업 리더들의 큰 관심을 받고 있습니다. 생성 모델은 딥러닝 기술의 발전을 바탕으로 고품질의 이미지와 비디오와 같은 복잡한 데이터 형식을 생성하는 데 있어 전례 없는 능력을 보여주고 있습니다. 특히 생성적 적대 신경망(generative adversarial network, 이하 GAN)과 변분 오토인코더(variational autoencoder, VAE), 확산 모델(diffusion model)과 같은 새로운 아키텍처가 등장하면서 생성 기술은 학문적 탐구를 넘어 실제 산업에서의 응용으로 빠르게 확장되고 있습니다. 이러한 발전은 엔터테인먼트와 광고, 콘텐츠 제작 등의 창의적인 산업에서 새로운 가능성을 열었을 뿐만 아니라, 과학적 시뮬레이션과 가상 환경, 증강 현실과 같은 다양한 분야에서도 중요한 발전을 이끌어 내고 있습니다.그러나 생성 모델은 기존의 머신 러닝 기법과는 달리 생성된 결과물에 대한 정답(ground truth, 이하 GT)을 갖고 있지 않다는 점에서 정량적으로 평가하기가 매우 어렵다는 한계가 있습니다. 결과가 다양한 형태로 생성되고 표현될 수 있기 때문에 꼭 어떤 하나의 정답과 똑같이 생성돼야 한다고 가정할 수 없는 것입니다. 생성 모델의 품질을 평가하기 위해 FID(Fréchet Inception Distance)나 IS(inception score), CLIPScore와 같은 대체적인 평가 지표들이 활용되고 있지만, 이러한 지표 역시 모델 성능의 모든 측면을 충분히 반영하지 못한다는 아쉬움이 있습니다.저희는 이번 글에서 FID나 IS 등 비전(vision) 생성 모델을 통해 생성된 결과물을 평가하는 여러 방법을 자세히 살펴보고, 실제 애플리케이션에 생성 모델을 적용하고자 할 때 어떤 부분을 고려해야 하는지 알아보겠습니다.비전 모델의 성능 평가 방법이란?이미지 생성 모델의 평가 방법을 이야기하기 전에 보다 명확하고 이해하기 쉬운 기준을 설정하기 위해 고전적인 비전 태스크들과 이 태스크를 해결하기 위한 비전 모델의 성능을 평가하는 방법을 먼저 살펴보겠습니다. 이를 통해서 모델의 성능 평가 문제의 맥락을 보다 쉽게 이해할 수 있을 것입니다.비전 모델의 성능을 평가하는 방법은 크게 정성적 방법과 정량적 방법으로 나눌 수 있습니다. 정성적 방법은 사람이 자신의 주관적 기준으로 결과물을 검토해 성능을 표현하는 방법입니다. 이 방법은 사람이 직접 결과물을 평가하기 때문에 정량적 평가가 반영하지 못하는 세부적인 품질 차이까지 반영할 수 있다는 장점이 있지만, 한편으로는 각 사람의 기준에 따라 결과가 다르게 나올 수 있어 일관성을 확보하기 어렵다는 단점이 있습니다. 또한 무엇보다 사람이 직접 확인해야 한다는 점에서 시간과 비용이 많이 소모됩니다.이에 반해 정량적 방법은 일관적인 평가 기준을 만들어 이에 따라 모델의 성능을 객관적인 지표와 수치로 평가하는 방법입니다. 이 방법은 숫자로 표현할 수 없는 부분은 평가 시 고려하기 힘들다는 단점이 있지만, 결과