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. 규칙이나 예시 답변보다는 명확한 역할과 상황 부여하기휴리봇처럼 자유도가 높은 답변을 주는 봇의 경우엔 예시 답변을 학습시키기 보다는 명확한 역할과 상황을 부여하는 것이 더 효과적이에요. 휴리봇

제품을 만들다 보면 사용자에게 궁금한 점이 참 많이 생기는데요, 내가 원할 때마다 사용자를 만나 궁금한 점을 물어볼 수 있다면 얼마나 좋을까요?토스에서는 디자이너분들이 더 자주, 빠르게 제품의 사용성을 점검할 수 있게 토스 사용자처럼 학습된 AI ‘휴리봇’을 만들었어요. 휴리봇에게 내가 디자인한 화면을 보여주고 사용성과 관련된 질문을 하면 토스 사용자와 흡사한 의견을 줍니다. 단 몇 초만 에요.혹시 AI 제품을 만들기 위해 그동안 ‘프롬프트 엔지니어링’만 신경 쓰고 계셨다면, 이번 글을 통해 실무에서 AI를 실제로 잘 활용하기 위해 프롬프팅 외에도 필요한 것들을 프롬프팅 전-중-후 단계 별로 알려드릴게요. 이해하기 쉽게 휴리봇을 제품화 하는 과정을 함께 설명해 드리면서요. *프롬프트(prompt)란? 생성형 AI에 특정 작업을 수행하도록 지시하는 자연어 텍스트로, 고품질의 아웃풋을 생성하기 위해 프롬프트를 최적화하는 프로세스를 ‘프롬프트 엔지니어링’이라고 함해결하고자 하는 문제 좁히기프로젝트를 시작할 때 우선으로 해야 하는 일은 해결하고자 하는 문제와 목표를 뚜렷하게 정의하는 것이에요. 어쩌면 당연한 이야기처럼 들릴 수 있지만, 그것이 명확해야 진행 과정에서 다시 처음으로 돌아가거나 막히는 일을 줄일 수 있어요.휴리봇으로 해결하고자 했던 문제는 ‘UT의 스케일업’이었어요. 토스에는 ‘유저 무물데이’ 프로그램이 있어 디자이너가 원할 때면 언제든 사용자를 만나 온라인 UT 할 수 있는 환경이 잘 마련되어 있는데요. *유저무물데이란? 랜덤한 토스 사용자를 대상으로, 원하는 시간에 비대면 UT를 할 수 있는 프로그램 (자세한 내용은 아티클에서 확인할 수 있어요)프로세스가 잘 마련되어있더라도, 디자이너가 UT를 하기 위해서는 UT용 프로토타입이나 질문지 등 필수적으로 준비해야 하는 것들이 있기 때문에 최소 1시간 이상의 준비 시간이 필요하고, 사용자를 만나는 게 심리적인 부담이 되어 더 많은 준비를 하게 될 때도 있어요.아주 중요하거나 복잡한 제품일 경우, 사용자에게 사용성을 검증하는 것이 필수적이라 이 시간이 어쩔 수 없지만, 화면 내에 있는 작은 그래픽 하나, 한 문장, 작은 버튼의 사용성을 확인하기 위해서도 이런 준비 과정이 필요했기 때문에 빠르게 배포해야 하는 제품일 경우 UT를 진행하지 않고 바로 실험하거나, 주변에 있는 다른 직군의 팀원에게 “OO님, 이 문장 무슨 뜻인 것 같아요?”,”OO님, 이 그래픽 어떤 의미로 느껴져요?”라고 물어보며 게릴라 UT로 사용성을 확인하는 경우도 있었어요.현재의 방식으로는 UT의 스케일업이 어렵고, 디자이너가 지금보다 훨씬 자주 가볍게 사용성을 점검하게 하려면 완전히 허들을 낮춘 새로운 UT 방식이 필요하겠다는 판단이 들었어요.문제를 좁혔다면, 이것이 해결되었을 때 어떤 모습이길 기대하는지 목표를 정의해야 해요. 목표가 명확하면 AI 봇으로 만들고자 하는 상이 명확해지고, 그럼 프롬프팅을 훨씬 더 효율적으로 쉽게 할 수 있어요.디자이너가 가벼운 사용성 점검을 자주 하게 하려면, UT를 준비하고 진행하

분산 시스템 환경에서 Kafka Consumer 오프셋 이동하기• 아키텍처 확장하기• 3. 다른 기능으로 확장안녕하세요. 컬리 주문플랫폼개발 팀의 이보람입니다.Kafka Consumer를 운영하다 보면 간혹 예기치 못한 문제로 인해, 또는 의도적으로 메시지를 재처리해야 할 때가 있습니다. 이 글에서는 Spring Kafka를 활용하여 오프셋을 이동해 메시지를 재처리하는 방법에 대해 소개하고자 합니다.특히 분산 시스템 환경에서 컨슈머 애플리케이션을 운영할 때, 컨슈머 그룹을 중단하지 않고 오프셋을 이동하는 방법에 대해 소개하겠습니다.컨슈머 리밸런싱 또는 애플리케이션의 갑작스러운 중단 등의 이유로 메시지를 재처리해야 하는 상황이 발생할 수 있습니다. 그 외 다양한 원인과 상황들이 존재하지만 일반적으로 다음의 특징을 가집니다.1주문팀에서는 드물지만 메시지 처리가 누락된 상황을 경험하였고, 최근까지 카프카 CLI의 오프셋 재설정 명령을 사용하여 문제를 해결해왔습니다.하지만 제가 속한 팀의 환경에서는 재처리를 '제한'적으로만 수행할 수 있었는데요. 다음 문단에서 팀의 상황과 경험한 문제에 대해 조금 더 설명드리겠습니다.주문팀은 고객이 구매한 상품의 실시간 배송 정보를 얻기 위해 컬리 물류 조직에서 운영하는 배송 토픽을 구독하고 있습니다.하지만 물류 조직이 운영하는 카프카 클러스터에 대해 따로 관리자 권한을 가지고 있지는 않은데요. 권한이 없기 때문에 오프셋을 이동하려면 물류팀 혹은 카프카 업무를 총괄하는 데이터팀에 반드시 도움을 요청해야 했습니다.이런 상황에서 저희 팀은 오프셋 이동이 팀 내부적으로 수행되어야 하는 일이라고 판단하였습니다. 빠르게 재처리가 필요한 경우 다른 팀에 의존하지 않고 처리를 수행할 수 있어야 했기 때문입니다. 권한 문제로 어쩔 수 없이 다른 팀에 의존적인 상황이었기 때문에 컨슈머 관리자의 입장에서 개선의 필요성을 느꼈습니다.더불어 기존 프로세스는 다른 문제를 동반했습니다. 오프셋을 이동하려면 명령을 수행하기 전 컨슈머를 반드시 중지해야 하는데요. 오프셋 재설정 명령이 컨슈머 그룹이 비활성 상태일 때 수행되기 때문입니다.결국 오프셋을 옮기기 위해서 담당 개발자는 관리자 팀과 소통을 마친 후 컨슈머를 중지하고, 관리자 팀에서 오프셋을 이동하면 그제서야 컨슈머를 재기동하였습니다. 이는 번거로운 과정인 동시에 다소 시간이 소요되는 일이었는데요. 특히 다른 팀과 소통하며 컨슈머를 중지하고 재기동하기까지 다음 문제를 비롯하여 부대 비용을 감수해야 했습니다.이처럼 불필요한 시간과 비용을 초래하는 기존 문제를 해결하기 위해 아래와 같이 요구 사항을 정의할 수 있었습니다.기본적인 요구 사항은 다음과 같습니다.먼저 오프셋을 옮기는 방법이 필요했으므로, 오프셋 이동 방법으로 총 세 가지 대안을 찾아보았고 이들이 각각 요구 사항에 부합하는지 살펴보았습니다.첫 번째 대안은 물류 카프카 클러스터의 권한을 주문팀에서 얻는 것입니다. 이는 가장 쉬운 방법이지만 아쉽게도 아래 두 가지 문제를 야기합니다.• A 조직이 B 조직의 권한을 얻을 수 있다면

이전글[디지털 트윈 기술 #1] 현대오토에버 디지털 트윈 소개인사말안녕하세요, 현대오토에버에서 Software Defined Factory 분야의 소프트웨어 개발 업무를 하고 있는 우정우입니다.오늘은 현대/기아 자동차 공장에 디지털 트윈 기술을 적용하면서 사용한 일부 기술에 관한 흥미로운 소식을 공유 드리고자 해요.이 기술들 덕분에 생산 공정을 더욱 효율적으로 관리하고, 실시간으로 데이터를 활용해 의사 결정을 할 수 있게 되었습니다.그 중 WebRTC 기술을 적용하면서 공간의 제약이 사라지고 실시간으로 즉각적인 피드백을 주고받을 수 있게 되었어요. 덕분에 생산 라인의 모니터링과 유지보수가 훨씬 더 원활해질 것으로 기대하고 있습니다.그래서 오늘은 WebRTC에 대해서 말씀드리겠습니다.WebRTC란?WebRTC(Web Real-Time Communication)는 특별한 플러그인이나 프로그램을 설치할 필요 없이, 웹 브라우저만 있으면 누구나 간편하게 실시간으로 음성, 영상, 데이터를 주고받을 수 있는 혁신적인 오픈소스 기술이에요. 구글이 주도하여 개발했으며, 현재는 W3C와 IETF의 표준으로 자리잡았죠.또한 WebRTC는 데이터 전송 시 SRTP(Secure Real-time Transport Protocol)와 와 DTLS(Datagram Transport Layer Security) 같은 보안 프로토콜을 사용할 수 있어, 여러분의 정보가 안전하게 보호된다는 것도 큰 장점이에요.이 기술은 원격 회의, 고객 서비스, 실시간 협업 등 다양한 상황에서 유용하게 쓰이고 있습니다. 세상이 더 나은 소통과 경험을 만들어가는데 기여하고 있어요.WebRTC와 디지털 트윈 적용 예시기아 광명 EVO Plant 일부 공정에서는 공간의 제약 없이 3D로 현황을 실시간으로 파악할 수 있도록 디지털 트윈 기술이 적용되었어요.또한 웹 브라우저를 통해 다양한 환경에서 서비스를 경험할 수 있답니다.그림. WebRTC 웹사이트 및 공장 상황 확인그림. WebRTC 사용 사례WebRTC를 디지털 트윈 구현에 적용한 이유스마트 팩토리에서 디지털 트윈 기술은 제조 현장을 정확하게 모사한 가상 공장 환경을 구축하여 생산 공정을 최적화하고 효율적으로 운영, 관리 및 빠른 의사 결정에 도움을 주기 위해서에요. 하지만 이를 위해서는 고사양의 3D 그래픽을 계산할 수 있는 장비와 전용 어플리케이션이 필요합니다. 이는 구축 및 운영 비용이 많이 들어가며, 사용자마다 별도의 설치와 관리가 요구되는 문제가 있어요.WebRTC는 이러한 과제를 해결할 수 있는 대안으로 볼 수 있습니다. WebRTC를 활용하면 다음과 같은 장점을 얻을 수 있습니다.장비 의존도를 낮춤: GPU 서버에서 가상 공장 어플리케이션을 실행하고 사용자는 장비의 사양에 관계 없이 웹 브라우저만 있으면 가상 공장 환경을 제공받을 수 있어요.설치 및 배포 용이: 웹 브라우저만 있으면 별도의 애플리케이션 설치 없이 디지털 트윈 플랫폼에 접근할 수 있습니다. 이를 통해 사용자 경험을 크게 향상시킬 수 있어요.실시간 협업 지원: