본 글에서는 엔지니어의 개발 생산성을 향상시킬 수 있는 GitHub Copilot(이하 코파일럿), ChatGPT 외 다양한 AI 툴(AI-assisted Software)의 기능과 활용 방법을 소개하며, 생성형 AI로 인한 개발 방식의 변화, AI의 발전에 따른 우려 사항, 그리고 AI 툴을 바라보는 여러 관점들을 발표자와 실리콘밸리 사례 위주로 설명합니다(참고로 본 글은 지난 3월 사내에서 진행되었던 SK플래닛 기술 세미나(Data & Tech Committee, DTC*)에서 한기용 대표(Upzen)가 발표한 내용을 중심으로 정리하였습니다 - 발표자의 사용 허락을 받아 편집자가 Tech Topic 블로그에 포스팅합니다).이들을 잘 활용할 경우 개발자의 소프트웨어 개발 생산성이 향상된다고 알려져 있는데요, 정말 그러한가 해서 발표자께서는 실리콘밸리 지인 찬스(!)를 사용하셨다고 합니다(물론 발표자님도 써 보셨고요 ^^).지인 중 인도 개발자 출신 스타트업 대표와 인터뷰를 했었는데, 사내 개발자들이 코파일럿 엔터프라이즈 유료 버전을 사용하도록 6개월 정도 지원했더니 확실히 개발자 생산성이 올라간다는 피드백을 받았다고 합니다. 페어 프로그램 느낌도 꽤 나구요. 특히 주니어들의 개발자 생산성이 훨씬 올라간다고 합니다( 그렇다고 주니어를 대체(?)하지는 않겠죠? ). 하나 더 재미있는 사실은 코파일럿 하나만 많이 사용할 경우 피드백 루프가 생기는 것 같아, 다른 AI 툴을 병행해서 사용할 계획이 있다고 들었습니다(예: 툴 1로는 코드 생성, 툴 2로는 유닛 테스트 생성 등). 앞으로는 툴이 발전해서 휴먼이 작성한 코드와 AI 툴이 작성한 코드를 잘 구분해 주면 더욱 좋겠다는 의견도 제시해 주셨습니다.소프트웨어 개발 생산성은 코딩 시간의 단축(남는 시간에 다른 일을 하거나 쉴 수 있음), 코드 퀄리티 향상, DevEx(개발자 경험)의 향상, 코딩 스킬 향상 등 여러 가지로 정의할 수 있으며, GitHub에서 발간한 아래 글을 보시면 AI 툴 관점에서의 개발 생산성을 좀더 잘 이해할 수 있을 것으로 생각합니다(자세한 설명은 생략).DataCamp에서 약 8개월 전에 다양한 생성형 AI 툴을 survey했었는데 아래와 같이 카테고리를 분류하고 있습니다. (https://www.datacamp.com/cheat-sheet/the-generative-ai-tools-landscape)우리는 엔지니어들이 관심이 많은 Coding Application 및 Data Application 중심으로 보도록 하겠습니다.GenAI 기반 Coding Application은 공통적으로 아래의 기능을 사용자에게 제공합니다. IDE 형태 및 Extension을 통해 대부분의 기능을 제공하기도 하며(예: GitHub Copilot), 웹사이트 생성 등 특정 기능에 특화되어 있는 프로그램들도 있습니다(예: locofy.ai, Webflow.ai 등).이 중에서 발표자께서는 웹사이트를 '만들어' 주는 Webflow.ai를 써 봤는데 만족도가 높았다고 합니다. 발표자는 프론트

고작 대학생인 내가 스타트업에서 프론트엔드 혼자서 짧은 시간 내에 0 to 1을 할 수 있었던 이유현재 한 스타트업에 재직하며 2달 반이라는 짧은 시간 내에 앱 버전 2.0.0을 출시해야 했습니다.회사의 BM이 달려있는 유저앱을 담당하는 프론트엔드 개발자는 저 혼자였고,웹 프론트엔드 개발자로써 프로젝트들을 해왔던 저는 빠른 생산성을 위해 웹뷰로 많은 스크린을 구현하기로 결정했습니다.웹뷰로 구현된 부분은 대략 30개(스크린, 바텀시트 등) 이상입니다.웹뷰로 개발하게 되었을 때의 장점은 아래와 같습니다.• None 앱을 배포하지 않아도 웹뷰를 수정하면 반영 가능 => 앱 스토어 심사가 불필요.• None 앱은 최신 버전이 업데이트되면, 사용자들은 사용하고 있는 앱의 버전을 업데이트 해주어야 최근에 배포된 기능들을 사용할 수 있습니다. 이전 버전에 치명적인 버그가 있다고 했을 때, 사용자가 업데이트를 해주지 않는다면 겉잡을 수 없는 상황이 발생할 수 있습니다. 하지만 버전 체크를 통해 앱스토어 링크로 리다이렉트를 시켜준다면, 문제가 발생하지 않겠지만, 잦은 버전 업데이트는 사용자에게 좋지 않은 사용성으로 다가갈 수 있습니다.• None 혹시나 있을 앱 개발 프레임워크의 변경에도 용이하다. 만약 React Native로 개발된 앱이 회사의 사정으로 인해 Flutter로 마이그레이션을 해야한다고 가정했을 때, 웹뷰로 구현된 부분에서의 변경사항은 크게 X.• None 스타트업 입장에서 개발 인력을 구하기가 비교적 어렵지 않습니다. 왜냐하면 앱 개발을 주 스택으로 갖고 계신 분들 보다는, 웹 개발을 주 스택으로 갖고 계신 분이 더 많기 때문.이외에도 많은 장점과 개발 와중에도 혹은 배포 직전에도 계속해서 변경되는 기획 등 현재 제 상황을 고려한 결과, 웹뷰로 많은 부분을 개발하는 것에 점점 마음이 굳혀지게 되었습니다.하지만 main feature는 아무래도 사용자에게 보다 더 좋은 성능으로 보여줘야 했으므로 React Native 코드로 구현했습니다.2달 반동안 제 모든 리소스를 앱 개발에 몰아넣었고, 그 기간 동안 제가 했던 많은 고민을 통해 나온 하이브리드 앱에서의 웹뷰를 관리하는 방법을 공유하고자 합니다.• None React Native에서 각각의 스크린을 라우팅한 방법 & React Native <-> React (앱 <-> 웹뷰) 간 이벤트 처리 방식라이브러리를 활용해서 각각의 웹뷰 스크린을 render 했습니다.이 라이브러리를 활용하면 제가 웹으로 구현했던 부분을 앱 내에서 웹뷰로써 띄울 수 있으며,해당 웹뷰와 앱 간의 이벤트를 주고받아 특정 데이터 처리, 혹은 다른 스크린으로의 이동 등의 액션을 취할 수 있습니다.props로 source에 객체로 uri에 위와 같이 넘기게 되면 해당 페이지가 render됩니다.하지만 웹뷰 특성상 React Native로 구현된 부분에 비해 로딩이 더 발생하게 되죠.그럼 사용자 입장에서 웹뷰가 로드되는 동안, 빈 화면을 봐야하는 상황이 됩니다.이에 있어서 피드백을 제공해 주어야하는데, 이는 라이브러리에서

골프를 좋아하시거나 스포츠 중계 서비스의 미래가 궁금하시다면 이번 포스팅이 아주 흥미로울 거에요.SK텔레콤 '에이닷 골프' 서비스는 AI 기술을 활용하여 골프 중계 서비스에 혁신적인 변화를 선도하고 있습니다.앞으로도 다양한 스포츠 분야에 AI 기술이 적용되어 사용자들에게 더 많은 새로운 경험을 제공할 것으로 기대됩니다.이번 포스팅에서는 '에이닷 골프'의 두 가지 주요 기능인 AI 하이라이트와 AI 캐스터 서비스에 대해 설명해드리려고 합니다.AI 하이라이트 서비스AI 하이라이트 기술은 실시간 중계 영상에서 AI가 선수 정보와 경기 상황 등을 실시간으로 분석하여 선수들의 모든 샷을 자동으로 클립으로 만들어 줍니다.또한, AI가 상황별로 중요한 순간들을 파악하여 선수별 하이라이트, 라운드 하이라이트, 우승 선수 하이라이트 등 다양한 형태의 AI 하이라이트 영상을 만들어 제공합니다.AI 하이라이트 생성 절차• None• None 선수의 어드레스 자세와 선수 자막을 탐지하여 샷 시작 지점을 판단합니다.• None• None 선수 얼굴 클로즈업, 선수 자막, 스코어보드, 중계패턴 및 화면전환 효과 등을 분석하여 샷의 끝 지점을 결정합니다. 이로써 샷의 시작과 끝을 명확히 구분하여 샷 구간 정보를 생성합니다.• None• None 선수 자막으로부터 선수 이름, 홀 번호, 홀 타수, 스코어, 이벤트 등 선수 및 경기 상황 정보를 추출하고, 경기 데이터와 샷 구간 정보를 결합하여 샷 단위 클립을 생성합니다. 이를 통해 메타데이터에 샷의 상세한 정보를 추가한 클립이 만들어 집니다.• None• None 선수별 홀별 샷들을 모아 홀 단위 클립을 생성합니다. 이는 선수별 스코어카드와 연동되어 제공됩니다.• None 샷의 중요도 평가• None 샷 결과, 홀 스코어 등 데이터를 기반으로 샷의 중요도를 평가합니다.• None 하이라이트 생성• None 샷 정보 및 중요도 평가를 기반으로 선수별, 라운드별, 이벤트별, 우승 선수 하이라이트를 생성합니다. 이로써 상황별로 중요한 순간들만 모은 하이라이트 영상을 손쉽게 시청하실 수 있습니다.AWS 기반 AI 하이라이트 시스템시스템 부분에서는 현재 저희 기술 스택 중에 이슈가 있었던 것들 위주로 설명을 드리면서 왜 그런 선택을 하게 되었는지 설명드리려고 합니다.현재 AI 하이라이트 시스템의 모습으로 되기까지 몇 번의 큰 변화가 있었는데, 초기엔 GPU가 있는 on-premise 서버에서 몇 개의 python application으로 시작했습니다.zookeeper를 이용해서 config를 관리하고 DB는 sqlite를 썼습니다.하지만 PoC(Proof of Concept)로 진행하다가 전체 시즌을 안정적으로 운영하기 위해 AWS로 옮기기로 결정하면서 기존 스택을 AWS SaaS로 변경했습니다.AI 하이라이트 시스템에는 여러 엔진 및 모듈들이 있는데 모두 Docker 이미지로 만들어져서 AWS EKS 위에서 동작하고 있습니다.처음 야구 종목으로 시작을 했었는데 점차 골프, 농구 등으로 종목이 확대가 되어감에 따라 스크립트로

Commit Squash가 필요한 이유Git에서 commit을 할 때는 언제나 신중해야 한다.논리적인 작업 단위로 깔끔하게 정리된 commit 이력은 코드 히스토리를 파악하기 쉽게 해주고, 코드 변경 사항을 되돌리고 싶은 경우에도 변경할 시점을 찾기 쉽게 해준다.하지만 이미 commit과 push까지 했음에도 불구하고 사소한 오타나 버그가 발견되어 commit을 다시 하게 되는 경우가 있다.지저분하게 남아 버린 commit 내역들이 있으면 히스토리가 난잡해지고, 코드 이력을 확인할 때의 직관성이 떨어지게 된다.이럴 때 유용한 해결책이 commit squash를 이용하는 것이다.Git의 commit squash는 여러 개의 commit들을 하나의 commit으로 합치는 것을 말한다.이 기능은 불필요하게 작은 단위로 나뉘어진 commit들을 의미 있는 변경 사항을 담은 commit으로 압축해준다.Pull request를 날리는 등의 중요한 작업 전에 commit squash로 불필요한 commit들을 정리해주면 깔끔하게 git repository를 관리할 수 있다.그렇다면 이제 예제와 함께 commit squash 사용법에 대해 알아보자.hello, world! 를 출력하는 bash 스크립트를 다섯 차례로 나누어 commit 한 예시이다.먼저, 명령으로 commit 내역을 확인하고 squash할 commit을 선정한다.두 번째 "hello" commit과 세 번째 ", " commit을 합치고네 번째 "world" commit과 다섯 번째 "!" commit을 합쳐보자.명령어로 최근 4개의 commit 을 대상으로 interactive rebase를 시작한다.수정하려는 commit들은 전부 포함되어야 하지만, 그 이상을 대상으로 해도 무방하다.다음과 같이 interactive rebase 세션이 열린다.참고로 최초의 commit까지 포함하고 싶다면 명령어가 아닌, 명령어를 사용해야 한다.편집기에 보이는 commit 목록에서 squash할 commit을 에서 혹은 로 변경한다.이때 혹은 로 설정한 commit들이 그 직전의 commit과 합쳐진다.이 경우에 ", " commit은 "hello" commit에 합쳐지고, "!" commit은 "world" commit에 합쳐진다.만약 ", " commit, "world" commit, "!" commit 을 로 설정하였다면 이들 세 commit이 "hello" commit과 합쳐진다.squash할 commit들을 표시하였다면 를 입력하여 편집기를 닫는다.이제 commit message를 수정할 수 있는 창이 나온다.원하는 내용으로 수정하고 로 저장 후 닫아준다.", " commit은 "hello" commit에 합치고, "!" commit을 "world" commit에 합치는 두 가지 squash를 동시에 실행했기 때문에 다음 squash에 관한 message 수정 창도 나오게 된다.마찬가지로 원하는 내용으로 수정하고 를 입력하여 저장 후 닫아준다.interactive rebase를 종료하면 아

이 글에서는 서비스에 연결된 서버의 네트워크 상태를 모사하여 간단하게 HTTP로 장애 상황을 테스트할 수 있는 카오스 엔지니어링 도구 중 하나인 Toxiproxy를 소개합니다.카오스 엔지니어링의 필요성네이버 뉴스 서비스는 CDN, 네이버의 분산 저장 플랫폼인 nbase-arc 등 외부에서 관리하는 인프라에 의존하고 있습니다. 이는 직접 관리하지 않아도 된다는 장점이 있지만, 해당 인프라 장비에 직접 장애 상황을 만들어 테스트할 수 없다는 어려움이 있습니다.하지만 장애 상황에서의 영향을 파악하기 위해서는 테스트가 필수입니다. 저희는 주요한 장애 지점이 될 수 있는 nbase-arc를 테스트하고자 했고, 장애 상황을 모사하는 방법으로 Toxiproxy를 사용했습니다.nbase-arc 구성우선, 테스트를 진행하기 위해 nbase-arc가 어떻게 구성되어 있고 관리되는지 알아보겠습니다.nbase-arc는 크게 ZooKeeper와 Redis 클러스터로 나뉩니다.ZooKeeper는 Redis 클러스터의 게이트웨이 주소들을 저장하고 있다가 애플리케이션 실행 시 게이트웨이 주소를 전달해주는 역할을 합니다.Redis 클러스터는 다음 그림과 같은 구조로 구성되어 있습니다. 동일한 파티션 그룹의 프로세스는 다른 서버에 분산됩니다. 그 결과, 각 파티션 그룹 내 하나 이상의 프로세스가 살아있다면 문제없이 서비스할 수 있습니다.Toxiproxynbase-arc의 장애 상황을 모사하기 위해서는 ZooKeeper와 Redis 클러스터의 프로세스들을 다운시켜야 하는데, 다운 후 재실행하려면 해당 플랫폼을 담당하는 팀의 별도 지원이 필요하기 때문에 다양한 테스트를 하기에 불편하고 시간이 오래 걸린다는 문제가 있었습니다.이를 해결하기 위한 카오스 엔지니어링 도구를 찾아보았고, Toxiproxy가 요구 사항에 딱 맞는 도구라는 생각이 들어 도입했습니다.Toxiproxy는 어떤 도구인가Toxiproxy는 애플리케이션 서버와 인프라 장비 등의 서버 사이에 프록시 서버를 만들어 해당 장비들의 장애 상황을 네트워크 상태로 모사하여 테스트할 수 있는 도구입니다. Shopify에서 개발한 오픈소스로, Latency, Server Down, Bandwidth, Slow close, Timeout, Slicer 등의 네트워크 결함(fault)을 제공하며, Go로 작성된 Proxy 서버가 종단 간 사이에 위치에 네트워크 결함을 제어합니다.테스트 환경 구성테스트 환경은 Toxiproxy를 사용하여 다음과 같이 구성했습니다.Toxiproxy 서버로 구성한 프록시 서버에 nbase-arc Redis 게이트웨이를 연결하고 프록시 서버의 주소를 docker의 ZooKeeper에 저장하여 애플리케이션이 프록시 서버의 주소를 받아오게 했습니다.테스트 방법네트워크 결함을 주입하는 방법은 간단합니다. 다음과 같이 HTTP 요청으로 proxy를 추가하고 결함을 주입합니다.# add proxyPOST http://{toxiproxy-server}/proxies { "name": "{proxy nam

아키텍처에 대한 고민은 처음이라: 계층형과 육각형 아키텍처 적용 사례들어가며안녕하세요. 저는 공통 서비스 개발팀에서 소프트웨어 엔지니어로 근무 중인 Walter예요. 공통 서비스 개발팀은 사내 개발자분들의 개발자 경험(Development Experiecne, DX)을 향상시키기 위해 서비스에서 공통으로 사용하는 기능을 하나의 플랫폼으로 만들어 제공해요.저는 작년 1월 당근 인터널 프로덕트팀에 입사하여 사내 구성원분들의 업무 효율성을 높이는 도구를 개발했어요. 인터널 프로덕트팀에선 설계(Design)와 아키텍처(Architecture)를 깊게 고민해 본 적이 없었는데, 올해 4월 이동하게 된 공통 서비스 개발팀에서는 업무 특성으로 인해 고민할 일이 많았죠. 이 글에선 그 경험과 제 인사이트를 공유드리려 해요.기능적 건물과 소프트웨어개발과 건축의 아키텍처는 닮은 점이 많은데요. 본격적으로 개발 이야기를 하기 전에 건물을 한번 생각해 볼까요? 우체국을 떠올려 봅시다.출처: Pixabay건물은 보통 각자의 역할이 있죠? 우체국은 소포를 전달받아 보관하는 역할을 해요. 일반적으로 사람들은 우체국 건물에, 집이 제공하는 거주의 기능(Function)을 기대하지는 않아요. 건물의 아름다움보다도 소포를 잘 보관하고 전달할 수 있는 환경을 설계하는 것을 우선시하죠. 이처럼 어떤 건축물은 정해진 기능에 충실한 것만으로도 소임을 다해요.개발에서도 마찬가지예요. 어떤 소프트웨어는 목표한 기능을 수행하는 걸 최우선 과제로 삼아요. 사내 구성원 계정을 관리하는 시스템을 가정해 볼까요? 해당 시스템은 다음 두 요구 사항을 충족해야 해요. 첫째로 5회 이상 로그인에 실패하면 자동으로 계정이 잠겨야 하고, 둘째로 그 사실을 사내 메신저를 통해서 당사자에게 알려야 하죠. 이 소프트웨어의 아키텍처를 어떻게 구성하면 좋을까요? 간단하게 아래 이미지처럼 구성할 수 있어요.소프트웨어의 목적과 장기적인 방향성을 고려한다면, 사내 계정 시스템과 메신저 시스템 모두 쉽게 변하지 않을 거예요. 두 시스템 모두 변경하려면 많은 비용을 치러야 하니까요. 따라서 해당 알림 소프트웨어는 변하지 않는 인프라 위에서 알림 전송의 기능에만 충실하면 돼요.우체국이 우편물 전달의 기능에만 충실하다면 외관의 아름다움은 크게 중요하지 않듯이, 해당 소프트웨어도 메시지를 전송한다는 기능(Function)에만 충실한다면 설계와 아키텍처 등은 부수적인 논의가 될 수 있다는 의미예요. 조금 더 프로그래밍 이야기를 해보면, 단일 진입점(Entrypoint), 다시 말해 main.py 또는 main.go 같은 파일에 필요한 코드를 모두 작성해도 큰 문제가 없을 거예요.기능적 건물과 소프트웨어의 한계그러나 세상의 모든 건물이 처음 지어진 목적을 쭉 유지할 수 있는 건 아니에요. 경복궁을 한 번 떠올려볼까요?출처: Pixabay조선 왕조의 생활공간이었던 경복궁은 시간이 지나 우리나라의 대표 관광명소가 됐어요. 그리고 그 내부에는 안내소와 같이 기존에는 없던 건물이 들어서기도 했죠. 환경 변화에 맞춰 건물의 역할과

• 쉽고 간단한 Gemini 호출 Query 사용법• Gemini를 BigQuery에서 사용하기 위한 사전 준비• BigQuery에서 Gemini에게 인사하기• 리뷰 데이터로 Gemini 사용해보기• 제품별로 리뷰를 바탕으로 홍보 문구 작성하기• 직접 사용하며 얻은 팁• 응답 형식을 JSON으로 지정하여 결과에 대한 정합성 높이기• 대량의 데이터를 처리하는 방법• RAI(Responsible AI) 기능으로 응답 결과 해석하기안녕하세요, 컬리 데이터서비스개발팀에서 일하고 있는 Data Engineer 김영준, Product Manager 송재현입니다. BigQuery 환경에서 다양한 데이터 분석 업무를 진행하는 컬리에서, 최근 구글의 LLM 모델 Gemini Pro를 BigQuery console 화면에서 호출하여 사용할 수 있다는 소식을 들었습니다. PM과 엔지니어도 모델 구현에 대해 고민하는 시간을 줄일 수 있게 되어, 비용 효율적으로 다양한 분석 결과를 직접 도출할 수 있다는 기대를 갖게 되었습니다. 이번 글에서는 컬리 리뷰 데이터로 진행한 Gemini 분석 활용 예시를 공유합니다.Gemini를 BigQuery에서 사용하기 위한 사전 준비Gemini 모델은 GCP의 Vertex AI에서 제공됩니다. 따라서 BigQuery에서 Gemini 모델을 사용하려면 Vertex AI로 요청을 보낼 수 있도록 아래의 두 가지 설정이 필요합니다.• BigQuery 데이터셋에 사용할 Gemini 모델 (Model) 추가BigQuery에서 Gemini에게 인사하기BigQuery에서 Gemini를 사용하는 것은 SQL을 사용해 본 경험이 있으신 분들이라면 BigQuery에서 Gemini를 사용하는 것은 쉬운 일입니다. BigQuery ML을 사용하기 위해 간단한 설정을 마치고 나면 바로 사용이 가능합니다. 아래 보시는 것과 같이 짧은 SQL문으로 사용이 가능합니다.사용할 Gemini 모델과 서브 쿼리에 선언된 프롬프트를 함수에 사용해서 호출하는 형태입니다. 추가로 Gemini 모델에서 사용할 파라미터를 STRUCT 자료형에 작성하여 호출도 가능합니다.그리고 쿼리를 실행한다면 아래와 같이 결과를 얻을 수 있습니다. LLM 모델인 Gemini로 생성하는 문장은 고정되지 않기 때문에 값은 조금씩 달라질 수 있습니다.BigQuery에 저장되어 있는 많은 데이터를 사용하는 예시로 제품명 (product)과 리뷰 (review)라는 컬럼으로 구성된 테이블의 데이터를 사용하여 Gemini에게 다양한 작업을 시켜보겠습니다.BigQuery의 데이터를 사용하여 요청을 보내려면 프롬프트를 선언하는 서브 쿼리에 Gemini에게 시킬 요청과 BigQuery 테이블의 데이터를 문자열로 합쳐서 프롬프트를 만들어주면 됩니다.위 쿼리를 실행하면 아래와 같이 한 단어로 요약된 결과를 확인할 수 있습니다. 다만 LLM 출력값 형식에는 예측 불가한 변동성이 있다 보니 종종 한 단어로 끝나지 않고 설명을 붙이는 경우도 있는데 이런 경우 프롬프트에 설명을 달지 말라고 요청을 포함하면 도움이

안녕하세요, Tech Data AI검색팀 소속 권순철입니다!AI검색팀은 주로 “고객에게 좋은 쇼핑 경험을 주기 위한 프로덕트 분석”, “많은 상품/셀러를 개인에게 맞게 제공하는 검색/추천 시스템”, “데이터를 활용한 마케팅 최적화”라는 어렵지만 재밌는 주제들을 선정한 후 데이터로 풀고자 시도하고 있습니다.이번 포스팅은 그중에서 “데이터를 활용한 마케팅 최적화”를 위한 여러 시도, 배운 점과 성과, 그리고 개선할 점을 다뤘어요. 마케팅 최적화 관련하여 파편적인 내용을 종합적으로 묶었지만, 수식을 배제한 직관적인 방식으로 공유드려요!🏀 들어가며플랫폼의 본질과 마케팅의 역할은 무엇일까요?현재 우리는 “연결의 시대” 속에서 살아가고 있습니다. 스마트폰이 출시된 이후 상품과 정보의 생산자와 소비자를 연결해 주는 앱 기반의 서비스가 많이 출시되었습니다. 개인의 일상 혹은 사회에서 발생하는 많은 정보를 압축하여 연결해 주는 플랫폼으로 시작한 후 다른 도메인으로 확장 및 변형하는 사례들은 소수지만 파급력과 영향력이 매우 높은 서비스입니다. 반면에 브랜디는 처음부터 ‘패션 커머스 플랫폼’으로 정의한 후 패션과 관련된 여러 버티컬 서비스들을 시장에 선보이고 “이커머스 플랫폼”과 관련된 다양한 문제를 풀고자 노력하고 있는데요.패션 커머스 플랫폼은 앞의 글에서 말씀드린 대로 소비자인 고객’과 생산자인 ‘셀러’를 ‘상품’을 기반으로 연결합니다.고객이 ‘패션 커머스 앱’에 들어오는 이유는 자신이 원하는 상품이 있고, 그 상품들을 편리하게 찾을 수 있으며, 그 상품들로부터 만족감을 얻을 수 있다는 기대감 때문입니다. 마찬가지로 셀러가 자사몰이 아닌 ‘패션 커머스 플랫폼’에 상품을 등록하는 이유는 더 많은 고객에게 심미적 만족감을 줄 수 있는 상품을 보여주고 설득할 수 있다는 자신감 때문입니다.그렇다면 패션 커머스 플랫폼은 무엇에 집중해야 할까요? 패션 커머스 플랫폼은 플랫폼으로서의 본질을 지키면 됩니다.! 상품의 생산자인 셀러가 보유한 상품들을 플랫폼에 등록할 때, 플랫폼은 등록된 데이터를 추출하고 정돈하여 정보로 변환합니다. 좋은 정보로 변환될 수록 고객이 원하는 상품 정보들을 적절한 시점에 제공할 수 있습니다. 고객은 원하는 상품들을 적절한 상황에서 발견하실 때 플랫폼을 방문하십니다. 그리고 고객의 유입 데이터, 리뷰 데이터, 고객 메타 정보, 앱에서의 활동 데이터들을 엮어서 셀러축과 마찬가지로 좋은 정보로 변환해야 합니다. 다시 말해서 패션 커머스 플랫폼은 단순히 ‘상품’을 파는 것이 아니라 플랫폼에서 파생되는 데이터를 기반으로 새로운 정보를 발견한 후 연결해서 셀러와 고객이 불편을 겪는 문제를 풀어주는 역할에 집중합니다. 일반적으로 다수의 이커머스 플랫폼은 다음과 같은 Flow를 가지고 있는데요!이커머스 플랫폼의 최종 목적은 ‘고객의 구매’ 여정을 최적화하는 것입니다. 이커머스 플랫폼은 검색이나 홈 화면처럼 트래픽이 많이 발생하는 페이지부터 보완재 성격의 상품을 추천할 수 있는 장바구니 페이지까지 다양한 페이지들로 구성되어 있습니다. 다만 온사이트 상의

모든 사람이 자신만의 AI Agent를 개발하여 소유하는 시대가 올까요?CrewAI는 여러 AI Agent를 통해 복잡한 작업을 손쉽게 처리할 수 있는 프레임워크입니다.이번 글에서는 CrewAI의 핵심 개념인 Agent, Task, Tool, Process, Crew의 기능과 이들이 어떻게 상호 작용하여 내가 해야 할 일을 대신해 주는지 살펴보겠습니다.• None Agent : 에이전트는 CrewAI에서 작업을 수행하는 주체입니다. 이들은 특정 작업을 수행하도록 프로그래밍된 자율적인 AI입니다. 예를 들어, 데이터 분석 에이전트, 웹 검색 에이전트, 텍스트 요약 에이전트 등이 있습니다. 각 에이전트는 특정한 능력과 역할을 가지고 있으며, 이를 통해 팀의 목표를 달성하는 데 기여합니다. 예시) 데이터 분석 에이전트는 대규모 데이터를 처리하고 통계적 분석을 수행하며, 웹 검색 에이전트는 인터넷에서 필요한 정보를 빠르게 수집합니다.• None Tools: 툴은 에이전트가 태스크를 수행하는 데 사용하는 도구입니다. 이는 소프트웨어, API, 데이터베이스 등 다양한 형태를 가질 수 있습니다. 예를 들어, 웹 검색 에이전트는 검색 엔진을 툴로 사용하고, 데이터 분석 에이전트는 데이터 분석 소프트웨어를 사용할 수 있습니다. 적절한 툴의 선택은 태스크의 효율성과 정확성에 큰 영향을 미칩니다. 예시) 웹 검색 에이전트는 Google API를 사용하며, 데이터 분석 에이전트는 Python의 pandas 라이브러리를 활용합니다.• None Task: 태스크는 에이전트가 수행해야 할 구체적인 과제나 작업입니다. 이는 작업의 세부 사항, 수행 방법, 필요한 도구 등을 포함합니다. 예를 들어, "웹에서 최신 트렌드 정보를 검색하여 요약 보고서 작성하기"라는 태스크는 웹 검색 에이전트와 텍스트 요약 에이전트가 협력하여 수행할 수 있습니다. 예시) 특정 주제에 대한 트렌드 정보를 수집하는 태스크는 웹 검색 에이전트가 다양한 소스에서 데이터를 수집하고, 텍스트 요약 에이전트가 이를 요약하여 보고서를 작성하는 방식으로 진행됩니다.• None Process: 프로세스는 에이전트들이 태스크를 효율적으로 수행할 수 있도록 작업의 흐름을 조정하는 역할을 합니다. 이는 프로젝트 관리와 유사하게 태스크의 우선순위를 정하고, 작업의 순서를 결정하며, 각 단계에서 필요한 조치를 취할 수 있도록 합니다. 예를 들어, 데이터 수집, 분석, 보고서 작성의 순서로 작업을 진행하는 프로세스를 설정할 수 있습니다. 예시) 마케팅 캠페인을 위한 데이터 분석 작업은 먼저 데이터 수집, 그다음 데이터 처리 및 분석, 마지막으로 결과 보고서 작성의 프로세스로 구성됩니다.ChatGPT 통해서 블로그 초안 만들 수 있지만, CrewAI를 활용하면 웹 스크래핑 등 활용하여 조금 더 개선된 결과를 만들 수 있습니다.먼저, CrewAI를 사용하기 위해 초기 설정을 진행해야 합니다.CrewAI 내에서 구현된 추가 도구를 사용하기 위해 crewai[tools]도 설치합니다. LangChain에서 구현된 도구와 함

안녕하세요. 무신사 추천프로덕트팀 PM 김지윤입니다. 추천 프로덕트팀은 무신사 고객에게 최적화된 쇼핑 경험을 제공하기 위해 개인화된 상품 추천을 기획하고 운영합니다.우리 모두 한 번쯤은 옷장에 열어보며 “왜 입을 옷이 하나도 없지?”라고 생각하며 쇼핑 앱에 들어갔지만, 원하는 옷을 찾지 못해 빈손으로 앱을 닫은 경험 있지 않으신가요?무신사 추천프로덕트팀과 데이터프로덕트팀에서는 여러분이 “좋아하는 스타일의 옷”과 “이맘때 살 만한 옷”을 쉽고 빠르게 탐색할 수 있도록 2가지 추천 서비스를 오픈했습니다. 파트 1 글에 소개된 무신사 패션 택소노미를 추천에 활용한 과정을 공유해 보려 합니다.1. 고객 맞춤 스타일 옷 추천무신사에 다양한 상품과 브랜드가 입점하면서 “제 취향에 맞는 옷을 찾기 힘들어요”라는 고객의 의견이 증가했습니다. 이를 해결하기 위해 가장 먼저 “옷 취향”을 정의했습니다.취향이란?누군가 “너의 옷 취향은 뭐야?”라고 묻는다면, 여러분은 어떻게 대답하실 건가요? 저희 팀 내에서는 “깔끔하고 걸리쉬한 스타일이요”, “그냥 뭐.. 무난한거요”, “놈코어를 표방하면서 스트릿을 가미한거요”, “뉴진스요” 등 다양한 답변이 나왔습니다. 이처럼 취향은 주관적이고 감성적인 영역이죠. 하지만, 파트 1 글에 소개된 스트릿, 미니멀, 걸리시와 같은 감성적 속성인 ‘스타일’은 상품의 객관적인 특징과 감성적인 무드를 함께 반영하기 때문에 취향의 많은 부분을 설명해줍니다. 실제로 “제 스타일 옷 추천해주세요”처럼 스타일과 취향을 혼용한 고객의 의견도 많았습니다. 따라서, 이번 프로젝트에서는 고객이 말하는 취향을 스타일로 정의했습니다.무엇이 문제일까?왜 고객은 관심 있는 스타일의 옷을 찾기 힘들어할까요? 지난 글에서 VoC 수집 과정을 공유해주신 제품경험분석팀의 리서치 결과를 참고하여 2가지 문제점을 도출했습니다.문제 1. 상품이 특정 스타일로 집중 분류되어 있어 고객이 다양한 스타일을 탐색하기 어렵다.리서치에 따르면 무신사는 캐주얼과 스트릿 중심의 “힙한” 스타일을 추구하는 플랫폼으로 인식되고 있으며, 로맨틱과 걸리시 패션 스타일을 추구하는 사람들은 무신사의 패션스타일과 본인의 스타일이 일치한다는 응답이 현저히 적었습니다.무신사의 기존 상품 시스템 체계에서는 상품을 총 5가지 스타일로 분류하고, 고객이 최근 본 상품과 동일한 스타일의 상품을 추천하고 있었습니다. 하지만, 전체 상품의 80%는 캐주얼과 스트릿 스타일이 차지했고, 세분화되지 않은 분류로 인해 고객이 다른 스타일의 상품을 보더라도 주로 캐주얼 스타일의 인기 상품이 추천되는 현상이 발생했습니다. 이로 인해 고객이 원하는 스타일의 상품을 찾기 어려워한다고 판단했습니다.문제 2. 고객이 본 상품 1개의 스타일이 고객이 관심 있는 스타일을 대표하지는 않는다.기존 추천 서비스에서는 고객의 최근 행동에 초점을 맞추어 최근 본 상품 1개를 기준으로 상품을 추천하고 있었는데요. 나를 위한 추천이 아닌 “기계적인 최근 본 상품 추천” 같아 아쉽다는 의견이 종종 있었습니다. 또한, 최근 본 상품에는 “어