안녕하세요, 현대자동차그룹의 R&D전략팀에서 오픈이노베이션 및 기술이전/사업화, 투자를 담당하고 있으며 Full Stage Venture Capitalist로 성장하고 있는 윤상원 책임연구원 입니다.지난 글에서는 오픈이노베이션(Open Innovation, 이하 OI로 기재함)의 정의와 진화, 급변하는 시장에서의 현대자동차그룹의 응전에 대해 이야기 해 보았습니다.이번 글에서는 당사의 OI 플랫폼 중 스타트업과 협업하는 프로그램인 '제로원 엑셀러레이터 프로그램, ZER01NE Accelerator Program'의 협업 지원서가 정부지원사업의 사업계획서와 어떻게 다른지를 설명하면서 이 글을 보시는 미래 또는 잠재적 스타트업 대표님들과 이야기 해 보도록 하겠습니다.1. 제로원 엑셀러레이터 프로그램, ZER01NE Accelerator Program | https://zer01ne.zone/zer01ne-accelerator/당사의 OI 플랫폼 중 스타트업(Start-Up)과 협업하는 프로그램인 '제로원 엑셀러레이터 프로그램, ZER01NE Accelerator Program에 대해 다시 한 번 설명드리겠습니다.잘 아시는 것처럼 새로운 시장과 새로운 비즈니스 모델(Business Model)을 만드는 것은 스타트업이 훨씬 유리합니다. 이는 대기업의 경우 스타트업의 속도와 민첩함을 따라갈 수 없고, 시장에서의 테스트(고객 반응)가 필요할 경우, 기존 브랜드 훼손의 이슈도 있기 때문에 쉽게 접근하지 못하기 때문입니다. 이에, 현대자동차그룹은 본 프로그램을 통해 그룹 내부의 문제를 해결하고자 하는 사항을 외부 스타트업과의 협업을 통해 시도하고 필요할 경우 전략적 투자(S.I., )도 진행하고 있습니다.<참고> 전략적 투자와 재무적 투자(F.I., ) 전략적 투자(S.I., Strategy Investment)     미래에 특정 기술을 포함하는 제품을 납품 받기 위한 투자로 주로 제조업 분야에서 많이 진행함 재무적 투자(F.I., Financial Investment)     재무제표상 '영업외수익'을 통한 원활한 기업 운전 자금의 확보를 위한 투자로 센싱 기능 포함함 이하 내용은 개인의 생각으로 현대자동차의 공식적인 입장은 아님을 미리 고지합니다.2. 대기업의 협업 지원서 파헤치기다양한 OI 플랫폼에서 과제를 사전 공유하며 다음과 같은 목차로 구성된 협업 지원서를 많이 요청하고 있습니다*[1, 2]*.       1) 과제를 해결하기 위한 제품 및 솔루션       2) 과제 진행 계획 및 지원 자금 집행 계획       3) 스타트업이 보유하고 있는 기술의 특징 및 증빙       4) (행정서류) 사업자등록증, 법인등기부등본, 재무제표 등"과제를 사전에 공유한다"는 문구에서 눈치가 빠르신 분들은 추측이 가능하신 것처럼 대기업 내부에 관련한 조직이 존재합니다. 여기서 '내부의 조직이 있는데 왜 공모를 진행하죠?' 라고 질문하신다면 그 답을 OI에서 찾으실 수 있습니다.<참고> OI, Open Innovation 정의 [3]"2003년 미국 버클리대학의 헨리 체스브로(Henry Chesbrough)가 그의 저서, Open Innovation에서 제시한 개념으로 외부에 존재하는 기술, 지식, 아이디어를 활용하여 연구개발(R&D)비용을 줄이고, 성공 가능성을 높여 그 효율성을 극대화하는 방식을 지칭함"알고 계신 것처럼 1개의 기능을 구현하기 위한 필요 기술들은 복수 개의 조합이고 이에 대한 그 세부(하부)기술들도 아주 많습니다. 이를 내부의 1개 팀에서 모두 시도해보고 이를 비교해서 최적의 솔루션을 찾는 것은 정말 많은 시간이 소요될 것이기 때문에 공모(전)를 활용해 그 시간과 그에 따른 비용을 절약하고 있습니다(개발자 10명의 1개팀의 연봉을 생각하시면 보다 쉽게 이해되실 것 입니다).그럼, 다시 협업 지원서로 돌아가서 함께 지원자(스타트업 대표님) 입장에서 접근해 보겠습니다. 보다 구체적으로 2024년 하반기 당사의 공모 1개를 확인해 보면 다음과 같습니다.제목 : 음성인식 기반 인캐빈 모니터링 솔루션개요 : AI 음성인식 분석 기반 인캐빈 모니터링 솔루션 개발개발 목적 : 탑승자 이상 상태 파악 및 경고 기능 구현검증 내용 : 차량 탑승자 상태 모니터링 분석 결과 정확도 검증적용 계획 : 차량 옵션 상품화 적용 검토필요 역량 : (스타트업) AI 음성인식을 활용한 탑승자 모니터링 분석 및 피트백 제공 서비스 역량(제가 생각하는) 위의 솔루션을 구성하는 기술과 그에 대한 세부기술의 조합은 다음과 같습니다.음성 인식 기술 - 문장 활용 기술 / 말하기 속도 측정 기술 / 어조 측정 기술영상 인식 기술 (인캐빈 카메라를 활용함) - 몸의 움직임 측정 기술 / 얼굴(표정) 측정 기술 / 눈동자 측정 기술운전자 상황 판별 기술 - 음성(소리)만을 활용하는 기술 / 영상(카메라)만을 활용하는 기술 / 핸들 조작 감지 기술 / 복합 감지 기술운전자 알림 기술 - 실내등 활용 기술 / HUD 활용 기술 / 핸들 연동 기술 / 시트 연동 기술만약, 우리 스타트업(이하 '연구핑[4]'으로 지칭함)이 스마트 팩토리에서 활용되는 머신 비전 시스템*으로 매출을 발생시키고 있고, 사업 영역의 확대를 위해 음성 인식 및 처리 알고리즘을 코딩할 수 있는 개발자를 채용한 상태에서 본 공고를 확인했다면 어떻게 접근하면 가장 좋을까요?<그림> 머신 비전 시스템 / <출처> 비전시스템[5] / 기술정보('22.10/16) 기사 사전 조사를 통해 'AI 음성인식 분석 기반 인캐빈 모니터링 솔루션'의 요소 기술들과 확장 시 필요 기술들을 정리해보니 음성 인식 기술, 영상 인식 기술, 운전자 상황 판별 기술, 운전자 알림 기술 등이 필요한 것으로 확인되었습니다.이에 "연구핑"이 다음과 같은 제안서(협업 지원서)를 작성한다면 '제로원 엑셀러레이터 프로그램'에 선발될 수 있을까요?연구핑의 협업 지원서A. 과제를 해결하기 위한 제품 및 솔루션 : 복합(음성 및 영상) 인식 기반의 인캐빈 모니터링 시스템<그림> 복합 인식 기반의 인캐빈 모니터링 시스템의 요소 기술 / <출처> Napkin.ai / https://app.na

글. 김지영(Terna) / Platform Design Team Lead부제. 효율적인 디자인 시스템 구축을 위한 프로세스 개선지난 글에서는 디자인 시스템 운영 과정에서 겪은 비효율과 그로 인해 생긴 고민들을 공유드렸는데요. 혹시 공감되거나 비슷한 경험이 떠오르셨나요? 이번 글에서는 그 문제들을 어떻게 해결했는지, 더 나은 시스템을 구축하기 위해 어떤 시도와 개선을 이뤄냈는지 자세히 소개해드릴게요.1. 버전 추적의 어려움을 어떻게 해결했을까?① 명확한 업데이트 규칙과 버전 관리많은 컴포넌트를 앱에 반영하는 것도 중요했지만, 그보다 더 중요한 건 확실하게 검증된 컴포넌트를 만드는 거였어요. 그래야 디자인 라이브러리를 넘어, YDS 컴포넌트는 기능적으로도, 심미적으로도 믿을 수 있다는 신뢰를 쌓을 수 있다고 생각했죠.그래서 먼저 버전 업데이트의 규칙을 새롭게 정의했어요. 체인지로그는 코드 레벨에서 변경점이 있는지를 기준으로 상태값을 명확히 정의해서 작성했구요. 이 체인지로그와 함께 해당 버전의 스펙을 확인할 수 있는 피그마 브랜치 링크를 앱 개발팀에 전달했어요. 프로젝트와 분리된 지라 티켓으로 요청해 시스템 개발이 버전 단위로 진행되도록 했죠.배포 일정이 정해지면 UX Owner분들께 공지해서, 작업 중인 피그마 파일에서 라이브러리 업데이트를 받을 시점을 조율할 수 있도록 했어요. 이렇게 프로세스를 정리하면서 업데이트 흐름을 명확하게 알 수 있게 했고, 개발과 시스템 디자인 간의 연결을 더 견고하게 만들게 되었어요.② YDS 컴포넌트 검수용 샘플앱앱에 아직 적용되지 않은 컴포넌트를 포함해 기존 컴포넌트의 검수가 절실했는데요, 이 부분은 앱개발팀이 먼저 적극적으로 방법을 제안해 주셔서 검수 전용 샘플앱(YDS Stage)을 구축하게 되었어요. 피그마 라이브러리 버전이 업데이트되면, 개발이 진행되는 동안 샘플앱 가이드를 작업하고, 이후 샘플앱 업데이트를 요청드리는 방식으로 검수를 이어가고 있어요. 상용 앱에서는 확인하기 어려운 상태값까지 포함해 Variants 단위로 꼼꼼히 검수가 가능해졌죠.검수가 가능하다는 건 시스템 디자이너 입장에서 정말 큰 의미가 있었어요. 내가 검증한 컴포넌트를 개발자와 UX Owner가 실제로 활용할 거라는 확신이 생기니, 작업에 대한 불안감도 크게 줄어들었거든요. 더불어 샘플앱은 시간이 지날수록 그 중요성이 커질 거라고 생각해요. 앱 내 적용되는 컴포넌트 비율이 늘어날수록, 컴포넌트 변경이 앱 전반에 미치는 영향도 커지기 때문에 검수 과정은 더욱 민감한 사안이 될 거예요. 결국 샘플앱이 시스템의 신뢰를 유지하고, 변경의 리스크를 줄이는 데 필수적인 도구로 자리 잡을 거라고 생각해요.2. A/B 테스트와 실험 UI 관리의 문제은 어떻게 해결했을까?사후 대응과 위닝 패턴 수집업데이트와 버전 관리 규칙이 생긴 덕분에 덕분에 디자인 시스템이 프로젝트 일정에 휘둘리던 문제는 어느 정도 해결됐어요. 시스템 자체를 고도화할 프로세스도 정립되었고요. 그런데 여전히 전체 컴포넌트가 개발되지 않았고, 앱에 충분히 반영되지 않은 상태

모닥불 10화 특집: 캠프파이어 에피소드 🔥 이번 모닥불은 특별히 시청자 여러분과 함께하는 시간으로 준비했어요."폴더 구조를 설계할 때 꼭 지켜야 할 원칙은?" "컴포넌트 추상화, 어디까지 해야 더 효율적일까요? "함수형 프로그래밍은 언제, 왜 사용하는 게 좋을까요?"사전에 접수된 시청자 여러분의 다양한 사연과 질문 그리고 코드 리뷰까지! 토스 개발자들이 실무 경험에서 얻은 노하우와 인사이트를 아낌없이 공유합니다! 지금 바로 확인해보세요!• None 01:20 첫 번째 사연: 폴더 구조는 어떻게 정리해야 협업이 쉬울까요?• None 06:39 두 번째 질문: 컴포넌트를 어떻게 분리하고, 추상화는 어디까지 해야 할까요?• None 11:20 변경 사항을 예측해 추상화 하는데 어려움을 겪고 있다면• None 15:24 세 번째 질문: 유효성 검사는 에러로 보는 것이 맞을까요?• None 19:57 네 번째 질문: 함수형 프로그래밍이 꼭 필요한가요?다른 모닥불 회차 보러가기 EP.7 개발자 리더로서 성장당한 썰 EP.8 Next.js 그만 쓰세요! 면접관이 진짜 원하는 것!? EP.9 프론트엔드 서비스 최적화? 토스에서는 '이렇게' 합니다!

네이버 검색 FE 시스템 구축 과정에서 저희는 다음과 같은 문제에 직면했습니다.첫째, 유사하지만 영역이 다른 경우 비슷한 작업을 반복하는 경우가 있었습니다.검색의 각 영역은 마이크로서비스 아키텍처(MSA)로 이루어져 있으며 클라이언트 코드 역시 영역별로 관리되고 있었습니다. 이로 인해 영역 간 동일한 유형의 작업을 반복해야 했고, 경험이 축적되기보다는 업무의 성장이 저해되는 결과를 초래했습니다.둘째, 유사한 UI를 매번 새로 개발해야 하는 비효율성이 존재했습니다.코드의 재활용이 어려워서 유사한 패턴의 UI를 구현할 때마다 새로운 코드를 작성해야 했고, 이는 자원의 낭비로 이어졌습니다.셋째, 데이터가 부족해 개선 작업이 어려웠습니다.개선이 이루어져도 이를 측정할 수 있는 데이터가 부족해서 실제 효과를 파악하기 어려웠습니다. 그 결과, 어디부터 개선해야 할지, 문제는 없을지 등을 판단하기가 어려워 개선 작업의 방향성을 설정하기 어려웠습니다.넷째, 피드백 주기가 지나치게 길다는 문제가 있었습니다.디자인이 실제 코드로 구현되어 동작하기까지의 시간이 너무 오래 걸렸고, 이 과정 중에 디자인이 수정되면 재작업이 많아지는 비효율적인 상황이 발생했습니다.이 글에서는 이 문제들을 해결하기 위한 저희의 해결 방안과 현재 고민하고 있는 문제를 공유하겠습니다.해결 방향이러한 문제를 해결하기 위해 저희가 생각한 해결 방향은 다음과 같습니다.첫째, 서버 주도 UI(Server Driven UI) 방식을 도입했습니다.비슷한 작업이 반복되는 문제를 해결하기 위해 UI를 한곳에 모으고 이를 재활용할 필요가 있었습니다. 서버에서는 비즈니스 로직만 구현하고 UI를 생성하는 서버를 별도로 두는 것이 적합하다고 판단하여 서버 주도 UI 방식을 채택했습니다. 이를 통해 클라이언트 측에서 UI를 반복해 개발할 필요 없이 서버에서 다양한 상황에 맞춰 유연하게 UI를 전달할 수 있게 되었습니다. 이는 비슷한 개발 작업을 줄이고 유지 보수의 효율성을 크게 향상시켰습니다.둘째, 디자인 시스템(Design System)을 통한 해결책을 마련했습니다.기존에는 UI가 유사해도 개발자가 달라서 별도로 개발하여 중복이 발생했다면, 이제는 자주 사용되는 UI 요소를 일관된 디자인 시스템으로 구축하여 재사용이 가능하도록 만들었습니다. 이는 개발자와 디자이너 모두에게 큰 도움이 되었으며, UI 개발 시간을 단축시키고 중복된 노력을 최소화할 수 있었습니다.셋째, 데이터 기반의 접근 방식을 도입했습니다.현재 데이터가 부족해 개선 작업이 어렵다는 문제를 해결하기 위해, 더 많은 데이터를 수집하고 이를 바탕으로 피드백 루프를 강화하는 계획을 수립했습니다. 특히 현재 사용되고 있는 UI를 분석하고 그 데이터를 수집하여, 이후 개발 및 운영 과정에 적극적으로 활용하고자 했습니다. 이를 통해 서비스에 많이 사용되는 컴포넌트와 모듈을 수집하고 사용자의 패턴을 파악하며 어떤 UI가 효과적인지에 대한 통찰을 얻어 UI와 UX를 최적화할 수 있게 되었습니다. 더 나아가, 데이터 분석 결과는 새로운 기능 개발뿐만 아니라

디자이너로서 커리어를 시작할 때, 특히 경력이 부족하다면 고민이 많을 수밖에 없죠. “내가 과연 준비가 됐을까?”, “경험도 없는데 이런 회사에 도전해도 될까?” 같은 걱정이 앞서기 마련인데요. 그런 고민 속에서 도전했던 두 디자이너 세린님과 수빈님의 이야기를 들어봤어요.두 분이 경험한 토스 인턴십은 단순히 보조 업무나 과제 중심의 경험이 아니라, 1인 디자이너로서 제품을 주도적으로 맡을 수 있었던 기회였다고 해요. 4개월이라는 시간 동안 압축적으로 성장하며 과거의 자신을 뛰어넘을 수 있었던 그 이야기, 지금 시작할게요.Q. 토스 인턴십에는 어떤 분들이 지원하시는지 궁금해요. 두 분은 지원 당시 어떤 상황이셨나요?세린 : UX 디자인에 흥미를 느껴 공부하던 학생이었어요. 하지만 제 실력으로는 디자이너로 시작하기에 부족하다고 느껴서 고민이 많았죠. 그러다 토스 PD 인턴십 공고를 보고 ‘이건 꼭 도전해야 한다’는 생각이 들었어요. 토스는 제가 꼭 경험해보고 싶었던 회사였거든요. 아직 졸업 전이었지만, 지금 아니면 안 될 것 같다는 마음으로 지원했어요.수빈 : 저는 원래 산업디자인을 전공했어요. 코로나 이후 제 적성을 고민하다 UX 디자인으로 눈을 돌리게 됐죠. 다른 회사에서 프로덕트 디자이너로 인턴을 하긴 했지만, 주도적으로 문제를 해결하는 경험이 부족하다는 아쉬움이 남았어요. 그래서 더 적극적으로 일할 수 있는 환경을 찾아보다 토스에 지원하게 됐어요.Q. 경력이 많지 않았던 만큼 걱정도 많으셨을 것 같아요. 어떤 점이 가장 고민이었나요?세린 : 걱정이 많았죠. UX 실무 경험은 없었고 PM 인턴 경험만 있었거든요. 하지만 입사 전형을 겪으며 토스가 “경력보다 잠재력을 본다”는 걸 느꼈어요. 얼마나 많은 디자인을 해봤는지가 아니라, 문제를 해결하려는 태도와 제품을 바라보는 관점이 훨씬 중요했어요. “경력이 없다면 우리가 만들어 줄게!”라는 느낌이 강했달까요.수빈 : 저도 비슷했어요. 포트폴리오도 완벽하지 않았고, UI 디자인 경험도 부족했거든요. ‘내가 이 정도로 가능할까?’라는 생각이 들었지만, 면접 과정에서 제게 필요한 질문들을 많이 받으면서 생각이 바뀌었어요. ‘왜 이런 디자인을 선택했는지’, ‘이 문제를 어떻게 풀려고 했는지’를 묻는 질문들 덕분에 제 사고 과정을 돌아볼 수 있었고, 자신감도 얻었어요.또 저의 경험과 태도를 보여주는 것에 집중했어요. 예를 들어, 제가 사이드 프로젝트를 할 때 발로 뛰며 사용자 인터뷰를 했던 경험이나, 꽃 사진 촬영을 위해 꽃을 직접 사고 팝업으로 판매까지 했던 이야기들을 담았어요.결국, 토스가 원하는 건 현재 스킬보다도 그런 적극적인 태도와 문제를 해결하려는 자세가 아니었을까 싶어요.Q. 실제로 토스에서 인턴십을 하며 어떤 경험을 하셨나요?세린 : 대부분의 인턴십은 보조 업무 위주로 진행된다는 인식이 있잖아요. 그런데 토스는 달랐어요. 사일로에 소속된 1인 디자이너로서 제품의 모든 과정을 주도적으로 맡을 수 있었어요. 제가 제안한 디자인이 실제로 제품에 반영되고, 유저 반응을 확인하는 경험은 정말

사업개발, 영업으로 커리어를 시작해서 풀스택, 프론트엔드, 서버 개발까지 다 해보신 지민님의 이야기를 들려드립니다. 끝 없는 도전과 변화, 지민님은 매 순간 어떤 태도로 커리어를 대했을까요? 토스 피플 글을 통해 알아보세요.토스에서 하고 계신 일을 간략히 소개해주세요.토스증권 마진 트레이딩 사일로에서 서버 개발자로 일하고 있어요. 저희 사일로는 외상 거래(미수 거래) 와 같은 레버리지를 사용하는 서비스들을 만들고 있어요. 돈이 없어도 레버리지를 사용해서 주식 투자를 할 수 있는 거죠. 주식에서 얻은 수익으로 빌린 돈을 갚고요. 최근에는 주식 담보 대출이라는 새로운 기능도 준비하고 있어요.어떻게 처음 커리어를 시작했나요?학부에서 경제학과 심리학을 전공했었는데요. 처음에는 대학원을 가려고 진로를 정해두고, 공군 학사 장교로 군복무를 시작했어요. 근데 가보니까 제가 큰 조직이랑 안 맞는 사람이라는 걸 깨달았어요. 저는 계속 더 나은 방식으로 일을 하고, 무언가를 발전시키고 싶었는데 큰 조직에서는 안전하고 해오던 방식을 선택하는 게 미덕이더라고요.그러다 하고 싶은 걸 생각해봤을 때 쥐뿔도 없이 시작할 수 있는 IT 창업을 꿈꿨어요(웃음). 일단 개발은 모르니까 친구랑 창업자 쫓아다니고, 해외 밋업도 가보고, 아이템도 선정해보고… 많은 일을 했죠. 근데 그렇다고할 제품은 결국 하나도 안 나오고 엎어졌어요. 결국 “스타트업에 가서 IT 창업에 대해서 배우자”라는 선택을 했어요.어떤 스타트업에 들어갔나요?IoT 가 뜨고 있을 때라 관련된 스타트업에 들어가서 “뭐든지 해봐야겠다” 싶어서 사업개발을 담당했어요. 거기서 열심히 개발자랑 디자이너랑 친해져서 사이드 프로젝트도 다양하게 해봤어요. ‘오모’라는 알림 서비스도 만들었고요. 이 회사에서 많이 배웠지만, IoT 라는 기술에 대한 한계가 보였고, 새로운 환경에서 더 많은 성장을 하고 싶어서 이직을 했어요.결혼 준비 플랫폼에 영업 직군으로 이직했는데요. 강남을 돌아다니면서 셀프 웨딩 촬영 스튜디오, 드레스샵, 웨딩홀 같은 곳을 영업했죠. 새로운 도메인을 알게 되, 매출이 없던 곳에서 매출을 만들어내는 게 재미있었어요. 저도 이 회사를 다니면서 결혼 준비를 했고요.근데 곰곰히 생각해보니 회사가 어려워지면 제가 제일 먼저 잘릴 거 같았어요(웃음). 전문성이 쌓이고 있다는 생각이 들지 않았고, 제가 커리어를 발전시키고 있다는 생각도 안 들었어요. 반면 옆에서 지켜본 개발자들은 어떤 기술을 써본 것만으로도 커리어가 쌓이고 성장에 후퇴가 없다는 느낌이 들어서 부러웠어요.그래서 개발을 배우기로 결심했나요?네. 신혼여행 가서 고민하다가 개발을 해봐야겠다는 마음을 먹었어요. 제가 레스토랑을 열고 싶으면 요리를 기본적으로 알아야 되듯이, 나중에 창업을 하고 싶으면 개발을 알아야 된다는 생각도 들었고요. 그래서 국비 개발 학원을 6개월 동안 열심히 다녔죠. 이때 제가 서른이었어요. 늦었다는 생각도 들었지만 개발자가 되면 커리어를 차근차근 쌓아갈 수 있다는 것도 알고 있었고, 성장이 돈으로 보상된다는 것도 알고 있어서 으쌰

안녕하세요. LINE Plus ABC Studio 기획자 한영주입니다. 저는 일본 최대 규모의 배달 서비스인 데마에칸(Demaecan, 出前館) 앱을 기획하고 있습니다.한국의 배달 서비스와 마찬가지로 현재 데마에칸의 주요 수입원도 주문 수수료와 배달 수수료입니다. 저희는 신규 수익원을 창출하기 위해 고민했고, 데마에칸이 하루 평균 수십만 건 이상의 주문이 발생하는 대규모 트래픽을 보유한 서비스라는 장점을 활용해 광고를 도입하는 것이 가장 좋은 후보라고 판단했습 니다.그동안 데마에칸은 가맹점(예: 음식점) 광고만 진행하고 있었는데요. 위 결정에 따라 음악이나 VOD, 건강 보조 식품, 부동산 광고 등과 같은 가맹점과 무관한 광고를 확보하기 위해 외부 광고 플랫폼 회사와 협력해 광고 상품을 출시했습니다.그런데 이런 광고를 어디에 어떻게 표시해야 배달 서비스와 전혀 관련 없는 광고가 나오더라도 사용자들이 거부감 없이 받아들일 수 있을까요? 또한 요즘의 인터넷 광고는 무작위로 아무에게나 아무 광고나 보여주는 것이 아니라 사용자의 개인 정보와 행동 패턴에 기반해 적절한 광고를 골라 제시하는 방법을 사용하는데요. 이와 같은 타겟팅 광고가 과연 얼마나 효과가 있는 것일까요?광고 표시 형식은 프로덕트에 광고를 추가해야 하는 기획자라면 누구나 고민하게 되는 주제입니다. 사용성과 광고 매출 둘 다 매우 중요하지만 일반적으로 둘은 반비례 관계에 있기 때문입니다.예를 들어, 팝업 형식의 광고를 넣으면 눈에 잘 띄어 클릭률은 높아지겠지만, 서비스의 본 기능을 사용하는 데 불편함을 초래할 수 있습니다. 반면, 배너 형식의 광고는 팝업 광고에 비해 클릭률은 떨어지지만 사용자의 거부감은 덜합니다. 이와 관련해 광고 회사의 주장에 따르면, 팝업 형식이 배너 형식에 비해 eCPM(effective Cost Per Mille; 광고 1000번 노출에 해당하는 금액으로, 광고 단가를 의미)이 2~3배 이상 높다고 합니다.저 또한 높은 광고 매출 달성에 욕심이 있었지만 사용성을 저해하면서까지 광고를 보여주는 것은 원치 않았습니다. 광고 거부감으로 인한 서비스 이탈이 더 큰 손해라고 생각했기 때문인데요. 고민 끝에 배 너 형식이지만 광고 지면을 늘려 충분한 광고 노출 수를 확보한다면 목표 매출을 달성할 수 있겠다는 결론에 도달했습니다.광고를 어디에 노출하는 것이 좋을까?데마에칸 서비스의 사용 흐름은 아래 그림과 같습니다. 저희는 아래와 같이 데마에칸의 다양한 서비스 화면 중 어디에 광고를 노출할지 광고 위치를 선정하기 위해 고민했습니다.광고 노출 위치를 선정하는 과정에서 가장 고민한 부분은 주문 동선을 방해하지 않는 것이었습니다. 광고 매출도 중요하지만, 데마에칸 서비스의 목적인 음식 주문에 방해가 되어서는 안 되기 때문입니다.그래서 가장 먼저 선택한 화면은 주문 완료 화면입니다. 기존에는 주문 완료 화면에서 다른 가맹점을 추천하고 있었는데 효과는 거의 없었습니다. 생각해 보면 당연한 결과입니다. 방금 짜장면을 주문한 사람이 초밥을 보고 또 주문하는 경우는 거의 없기 때문입니

안녕하세요, 여기어때컴퍼니 iOS개발팀의 엔비입니다.오늘은 여기어때가 MFA(Micro Feature Architecture)를 도입하게 된 배경과 실제 활용 사례에 대해 소개해드리려고 합니다.1. MFA의 도입배경여기어때는 국내숙소만을 제공하는 서비스에서 해외숙소, 레저 티켓, 공간대여 등 더 다양한 서비스들을 제공하는 앱으로 성장하였습니다. 그에 맞추어 최근 몇 년간 저희 iOS 개발팀의 인원 또한 늘어나게 되었습니다.점점 커지는 앱의 규모와 점점 복잡해지는 앱의 코드로 인해 여러 문제점들이 발생하기 시작했습니다. 그 중 대표적인 문제점들은 빌드 시간의 증가, 코드 간의 의존성증가로 인한 유지보수의 난이도 증가, 여러 팀원들이 동시에 작업할 때 코드 충돌이 잦아지고 사이드 이펙트가 발생하는 이슈입니다.여기어때의 모듈화 여정이러한 문제들을 해결하기 위해 저희 팀은 모듈화의 필요성을 느꼈고, MFA(Micro-Feature-Architecture) 아키텍처를 도입하기로 결정했습니다. 지난 글에서 iOS개발팀이 어떻게 모듈화를 진행했는지 소개해드렸는데요, 이번에는 MFA를 도입한 후 실제 이를 어떻게 활용하고 있는지 소개해드리려고 합니다.여기어때의 개발은 크게 두 가지로 나뉩니다. 앱의 코어 로직을 리팩토링하고 유지보수하는 작업과, 비즈니스 요구사항에 따른 피처 개발로 구분됩니다. 피처 개발의 경우, 담당자가 해당 프로젝트의 오너십을 가지고 특정 버전 배포를 목표로 프로젝트를 리드하며 개발을 진행하게 됩니다.iOS 앱개발 인원이 1 ~2명이었던 시절에는 소수의 개발자가 모든 작업을 담당했기에 외부 피처의 작업 상황을 크게 신경 쓸 필요가 없었고, 대부분의 피처를 담당하고 있었습니다. 그러다 보니 사이드 이펙트가 어느 곳에서 발생할지 예측 가능한 상황에서 개발할 수 있었습니다. 하지만 팀원이 늘어나고 동시에 진행되는 피처가 많아지면서, 동일 타겟 버전의 피처들 간에 코드 의존성과 사이드 이펙트 이슈가 발생하게 되었습니다. 그래서 버전을 출시할 때마다 이러한 이슈들을 해결하는 것이 항상 큰 과제였습니다.하지만 MFA 아키텍처를 도입한 후 iOS개발팀의 상황은 많이 달라졌습니다. 피처개발자는 더 이상 자신의 개발 피처 외에 다른 피처의 개발진행 상황을 신경쓰지 않게 되었습니다. 다만 기존의 작업과는 조금 다른 방식으로 개발하게 되었습니다. 이번에 출시된 찜 개편 프로젝트에서 MFA를 사용한 개발방식이 어떻게 사용되어 개발시간을 단축시키고, 피처간의 사이드이펙트를 줄이게 되었는지 이야기드려보겠습니다.2. 찜 개편 프로젝트에서 활용된 MFA의 장점들2.1 협업하기 좋은 환경이번에 진행한 찜 개편의 한 화면입니다. 찜 폴더안의 상품 PLP(Product List Page)에서 지도보기 페이지로 이동하는 개발이 필요하고, 지도보기 페이지에서 날짜를 변경했을 때 상품PLP에도 같은 날짜로 적용하는 개발이 필요합니다. 이 때, 지도보기 페이지 개발자와 상품 PLP 개발자가 협업을 한다고 가정해보겠습니다.2.1.1 모놀리틱 구조에서 개발하는 방식먼저 두 명

안녕하세요. 카카오페이증권 DevOps 팀의 테라입니다.본 글은 사내 지식저장소를 구축하기 위해 Amazon Bedrock과 슬랙봇을 통합하고 고도화한 경험을 공유하기 위해 작성되었습니다.본 프로젝트는 ‘siri’ 라는 이름으로 (Apple의 siri가 모티브인 것 맞습니다.), 카카오페이증권의 산재된 내부 정보들을 검색증강생성(RAG)으로 구현하여 LLM을 통해 쉽게 조회하고자 기획되었습니다. 또한 보안상 ChatGPT 등의 외부 AI 도구들을 사내에서 사용할 수 없었는데요, 그 대체를 만들고 싶기도 했습니다.그러다가 좀 더 카카오스럽고 귀엽게, 춘식이를 곁들여 ‘춘시리’ 라는 이름으로 발전하게 되었습니다.춘시리에게 원하는 것초기 목표는 다음과 같았습니다.• AI 봇에게 내부 문서(Confluence)를 학습시킨다.• AI 봇은 학습된 내부 정보를 바탕으로 내 질문에 대답해 준다.• 필요한 경우, AI 봇은 내부 정보가 아닌 일반 LLM 답변도 제공한다. (ChatGPT 대체)추가로 다음 기능까지 구현하고자 하였습니다.• 수동으로 추가 정보를 학습시키기• 지라 티켓을 분석하고 요약해 주간 리포트, 장애 리포트 등을 자동으로 작성해 주기또한 카카오 사내 커뮤니케이션 툴인 아지트(Agit)에 저장된 내용들도 학습하고 취합할 수 있기를 기대하였습니다.저희는 그전까지 AI를 활용한 개발 경험이 없기에, LLM, RAG, Embedding 개념 등을 처음으로 공부해 가며 시작하였습니다. 따라서 본격적으로 춘시리 아키텍처를 설명하기 전에, 춘시리를 구성하는 AI 관련 컴포넌트들에 대해 가볍게 설명하고 넘어가도록 하겠습니다.먼저 LM(Language Model, 언어 모델) 이란, 인간의 언어를 이해하고 생성하도록 훈련된 인공지능 모델입니다. 그리고 LLM(Large Language Model, 거대 언어 모델) 은 방대한 양의 데이터로 사전 학습된 초대형 딥러닝 언어 모델입니다.설명만 들어도 느끼셨겠지만, LLM을 직접 개발하기 위해서는 상당히 많은 자원(인적 자원, 컴퓨팅 자원 등)과 전문 지식이 필요합니다. 저희는 데이터 사이언티스트가 아니고, AI 관련 지식이 부족하기 때문에 외부 상용 LLM 모델을 사용해야 합니다. 상용 LLM 모델의 대표적인 예로는 OpenAI의 GPT 시리즈와 Meta의 Llama 시리즈가 있습니다.Amazon Bedrock(이하 베드락) 은 다양한 LLM 모델을 호스팅해주고, 쉽게 다른 서비스와 연동할 수 있는 API를 지원하는 AWS의 매니지드 서비스입니다. 즉, 베드락을 사용하는 경우 AWS API를 사용해 다양한 외부 LLM을 사용할 수 있으며, 모델을 직접 호스팅하고 관리할 필요가 없습니다. 게다가 AWS를 이미 사용하고 있는 경우, AWS 비용으로 같이 청구되므로 추가적인 빌링 프로세스가 생길 필요 또한 없습니다.저희는 내부적으로 이미 AWS를 사용하고 있고, AI관련 지식도 부족하므로 매니지드 서비스인 베드락을 통해 다양한 LLM 모델을 사용해 보기로 결정하였습니다. 다만 아직 서울 리전에서는 베드락으로

안녕하세요! 전시개발팀 티모입니다!오늘은 리팩토링 여정 시리즈의 마지막으로, 우리가 어떻게 이 항해를 헤쳐나갔는지와 팀원들의 후기를 공유드리려고 해요.그 전에 저희 팀이 리팩토링을 결심하게 된 이유와 과정이 궁금하시다면, “리팩토링 여정, 더 나은 코드로의 항해 part 1. 리팩토링 계기와 문제 진단"과 “리팩토링 여정, 더 나은 코드로의 항해 part 2. 새로운 구조로 나아가는 길"을 먼저 봐주세요. ️️☺️전시 파트는 약 1년 전부터 지금의 체제로 운영되고 있어요. 구성원들마다 전시 업무 경험이 다 달라 처음에는 팀워크를 맞추는 데 조금 어려움이 있었지만, 지금은 서로의 강점과 특징을 잘 이해하며 함께 성장해 나가고 있습니다. 이번 리팩토링도 그런 팀워크 덕분에 가능했던 작업이었어요.데일리 미팅: 서로의 발맞춤 👣리팩토링은 단기간에 끝나는 작업이 아니죠. 특히 저희는 운영 업무와 프로젝트 업무가 동시에 쏟아지는 환경에서 일하고 있어요. 그래서 팀원 간의 이해도를 높이고, 꾸준히 발맞춰 나가기 위해 데일리 미팅을 시작했답니다.매일 오전 10시 10분, 텐텐미팅이라는 이름으로 각자 오늘 할 일을 간단히 공유하는 시간을 가지기 시작했어요. 처음엔 다들 조금 어색하고 딱딱한 분위기였지만, 금방 팀 고유의 색깔을 찾았습니다. 😊특히 기분점수를 도입한 것이 데일리를 더 특별하게 만들어줬어요. 기분 점수는 0~10점 사이로 본인의 기분을 숫자로 표현하고, 그 이유를 간단히 공유하는 건데요. “오늘 기분은 4점이에요! 어제 잠을 설쳤거든요.”라든지, “10점입니다! 이유는 없어요!” 같은 이야기들이 자연스럽게 오가며 팀원들 간의 이해도가 높아졌습니다.이 점수는 단순히 분위기를 부드럽게 만드는 것뿐만 아니라, 서로의 업무 스타일을 파악하는 데도 큰 도움이 됐어요. 아침에 집중력이 높은 사람, 오후에 더 능률이 오르는 사람, 혹은 꾸준히 “10점”을 외치는 팀원 덕분에 웃음이 끊이지 않았답니다. 😆스터디: 함께 배우며 성장하기 📖데일리 미팅으로 분위기가 한층 부드러워졌다면 리팩토링 스터디는 팀의 기술적 이해도를 맞추는 데 중요한 역할을 했어요. 저희는 마틴 파울러의 《리팩터링 2판》을 함께 읽으며 전시 파트의 특성에 맞는 실질적인 방안을 논의했어요.매일 30페이지씩 읽고, 정해진 시간에 모여 “우리 프로젝트에 어떻게 적용할 수 있을까?”를 고민했죠. 책 속의 예제 코드와 원칙들은 저희의 상황과 꼭 맞지는 않았지만, 그런 한계를 인정하면서도 “우리가 가져갈 것”과 “그냥 참고만 할 것”을 명확히 구분할 수 있었어요. 스터디를 진행하며 나온 아이디어들은 리팩토링 설계의 기반이 되었고, 팀원 간의 기술적 이해도 차이를 줄이는 데 큰 도움이 되었답니다.Mob Programming: 모두가 하나로 🤲저희 팀은 기존에도 페어 프로그래밍을 자주 활용했지만, 이번 리팩토링에서는 팀 전체가 참여하는 Mob Programming 방식을 도입했어요. Mob Programming을 도입한 이유는 단순했습니다. 기존 프로젝트 구조가 복잡하고 리팩토링 범위가 넓다 보니 한