목록 보기
사내 데이터 플랫폼 개발, 처음이라면?
기타

사내 데이터 플랫폼 개발, 처음이라면?

네이버 DnA
네이버 DnA
2023년 10월 12일

협업이 낯선 데이터 분석/사이언티스트와 엔지니어를 위한가이드 데이터 엔지니어 및 소프트웨어 엔지니어, 그리고 데이터 분석/사이언티스트의 협업은 역사가 길지 않아서 Best Practice 라고 여겨질 만한 방법론이나 사례가 없는 듯합니다. 오늘은 네이버 검색 Data&Analytics(DnA)의 팀원으로서 함께 했던 데이터 플랫폼 개발 협업 프로세스에 대해 글을 작성해봅니다. 네이버 검색에서는 일상 업무에서 활용하는 다양한 플랫폼들이 있어요. 검색에서 자체 개발한 플랫폼 뿐 아니라, DnA 팀에서 자체 개발한 플랫폼들이 주된 데이터 추출 및 분석 업무 환경을 구성하고있습니다. 2023년 1분기부터 DnA 팀 내에서 신규 데이터 분석 플랫폼 개발 PM을 맡았습니다. DnA 팀은 다양한 서비스 팀과 협업하는데, 서비스 팀의 반복되고 확장되는 분석 요구 사항을 플랫폼으로 해소하자는취지였습니다. 요구 사항은 있지만, Zero-to-one으로 맞춤형 플랫폼을 개발해야 하는 상황이었어요. 하지만 유사 경험, 팀 내 전례, 다른 기업 사례 글 마저없었습니다. 당시에 어떤 절차로 일을 이끌어가야 하나 막막 했던 마음이 떠올라 협업이 낯선 데이터 직무 분들에게 도움이 되길 바라며, 지난 프로세스를 정리하는 글을남깁니다. 목차 ✔️ 자체 개발 데이터 플랫폼이 필요할 때 ✔️ 데이터 분석 플랫폼 개발에 필요한 역할 ✔️ 데이터 분석 플랫폼 개발 프로세스 ✔️ 시행착오를 통해 깨달은 것들 자체 개발 데이터 플랫폼이 필요할때 데이터 플랫폼이 필요한 경우는 다양합니다. 주로 큰 양의 데이터를 효과적으로 관리, 분석, 활용하고자 할 때 필요한데요. 데이터 플랫폼의 5가지 계층을 나눠본다면, 이번 사례는 아래 이미지 4단계의 BI/User Access 와 관련이있습니다. 데이터 플랫폼의 5계층 (출처: What is a Data Platform? And How to Build An AwesomeOne) 사내 다양한 팀에서 반복되고 패턴의 분석 및 추출 요청이 있었고, 단기/ 장기적으로도 중요한 분석이었습니다. DnA 팀에서 해당 분석을 중앙 집권화 하기에는 다른 업무도 이미 너무 많고, 무엇보다 도메인 지식이 많은 서비스 팀에서 직접 분석했을 때 더 깊이 있는 인사이트를 찾기에 좋은구조였어요. 반복되는 요청에 대한 효율화가 필요했고, Self-service Analytics 를 늘리려는 팀의 방향성이 있었기에 데이터 분석 플랫폼이필요했어요. 플랫폼이 필요하다고 판단이 되었을 때, 이번 사례는 자체 개발을 할 수 밖에 없었는데요. 그 이유는 엄격한 데이터 보안 정책, 비용 효율 문제도 있지만 무엇보다 네이버 검색 서비스 모델에 맞는 맞춤형 플랫폼이 필요했기때문입니다. ️ 어떤 데이터 플랫폼을만들었나 질의셋 데이터 분석 플랫폼을 개발했습니다. (질의는 검색어를의미함) QIP(Query Insight Platform, 큅)은 개선 및 모니터링 대상 질의셋을 등록하고 그 품질과 볼륨 지표를 모니터링할 수 있는플랫폼입니다. QIP을 통해 질의셋 뿐 아니라, 개별 질의 단위의 품질 및 사용자 행동 패턴 등의 다양한 정보를 한눈에 확인할 수있습니다. 이번 글에서는 플랫폼의 구조가 아닌 플랫폼 개발 프로세스를 다루려고합니다. ✔ 자체 개발 플랫폼이 필요한상황 1. 특수한 요구 사항이 있는 경우: 이번 사례✔️ 특정 업종이나 사업 모델에 맞춘 맞춤형 플랫폼이 필요할때. 기존 상용 플랫폼이 만족시키지 못하는 특수한 기능이나 성능 요구 사항이 있을때. 2. 데이터 보안 및 개인정보보호: 엄격한 데이터 보안 및 개인정보 보호 정책을 준수해야 하는경우. 데이터의 주권을 사내에 유지하고 싶은경우. 3. 비용효율: 장기적으로 봤을 때 자체 개발이 상용 플랫폼 사용에 비해 비용 효율적인경우. 4. 기술 통합 및커스터마이징: 다양한 사내 시스템과의 통합이 필요한경우. 특정 비즈니스 프로세스에 최적화된 플랫폼을 구축하고 싶은경우. 5. 자체 기술 역량확보: 데이터 플랫폼에 대한 이해와 기술 역량을 사내에 확보하고 싶은경우. 6. 데이터 관리 및거버넌스: 데이터의 품질, 관리, 거버넌스를 사내 정책에 따라 수행하고 싶은경우. 데이터 분석 플랫폼 개발에 필요한역할 데이터 플랫폼 도입 또는 개발은 앞서 살펴본 데이터 플랫폼 5계층에서 Storage, Ingestion, Transformation 단계에서 먼저 선행되는 편이라, 데이터 엔지니어 및 소프트웨어 엔지니어 만으로 진행되는 경우가많은데요. 이번 사례처럼 사내 다양한 팀에서 반복되고 패턴의 분석 및 추출 요청을 분석 플랫폼화하는 경우는 다릅니다. 사용자 타겟층과 해소하고자 하는 니즈가 명확할 때에는 사용자와 비즈니스 요구 사항에 대한 이해도가중요합니다. 1인 다역만이살길이다 ChatGPT에게 데이터 분석 플랫폼 개발에 필요한 역할을 물어봤더니, 정말 다양한 역할을알려주네요. 이처럼 최대한 다양한 전문가를 모셔서 함께할 수 있다면 이상적 이겠지만, 1인 다역을 훌륭하게 하실 수 있는 팀원 분들과 함께할 수 있어 수월하게 진행할 수있었습니다. 역할이 항상 개인에게 1:1 대응되어 깔끔히 떨어지는 것은 아니라 Gray Area가 있기는 한데요. 위 ChatGPT의 답변을 이번 DnA 사례에 빗대어본다면, 데이터 분석/사이언티스트 분들이 추가적으로 프로젝트 관리, 비즈니스 애널리스트, UI/UX 디자인 역할을맡았습니다. 데이터 엔지니어 분들이 추가적으로 데이터 아키텍트, 소프트웨어 개발, 인프라 관리 역할을맡았습니다. 다 함께 품질 관리, 문서화 및 지원을도왔습니다. 데이터 분석 플랫폼 개발프로세스 DnA 팀에서 진행했던 이번 프로세스를 돌아보며, 아래 프로덕트 개발 프로세스의 큰 6단계를 참고하여설명합니다. 출처: New Product Development Process Step 1.Ideation (1) 팀 외부 요구사항수렴 팀 리더, Tech Lead와 충분한 1:1 대화를 기반으로 요구사항 이해도향상 플랫폼 Scope를 프로젝트 Phase에 맞게분배함 목표 일정 관련 얼라인맞춤 (2) 팀 내부 요구사항수렴 지난 요청들을 구조에 맞게 최대한 정리, 선행된 타 플랫폼을 통해 대응된 요구 사항인지분류 다양한 요청들 및 내부에서 출발한 분석들을 기반으로 플랫폼의 요구사항을정리함 뿐 아니라 팀 내에 공유하여 검토받거나 함께 요구사항을 받을 수 있도록함 (3) 팀 외부/ 내부 사용자인터뷰 요구 사항 수렴 후 구체적인 기획 단계에서 사용자인터뷰 상세한 기능의 우선순위를 설정하는 데에 도움을얻음 당시 진행하지 못했지만 회고하며 추가한단계 Step 2. Product Definition (1) Milestone 설정 전 단계에서 정의된 Scope들을 각 Milestone으로 쪼개고 필요한 Task를 예상하여작성 Milestone의 진행 현황과 담당 파트를 배치하고 PM은 팀 내 리뷰, 틈틈이 잘 나아가고 있는지 확인하며업데이트함 (2) 역할 분담, 이슈 관리시작 프로젝트에 메인으로 참여하는 인원을확정함 업무 이슈들을 모아 팔로업할 수 있는 대단위 이슈 생성관리 (3) 화면 기획 및 스펙작성 플랫폼의 화면을 기획하고, 실제 구현을 한다고 가정했을 때 미리 정의되어야 할 상세한 요소(메뉴, 페이지 별 상세 기능 작동 방식)들을정리함 정리한 이후 공유 미팅을 진행해야 함, 문서로만 소통되면 문서를 아무리 친절하게 쓰더라도 싱크가 안 맞을 수있음. 디자인 하나도 모르는데 화면 기획해야 할때 *파워포인트 도형으로 만들어도 충분하다. 할 수 있는 선에서 하자! *구현하고 싶은 화면을 더 섬세하게 표현하고 싶다면, Figma Community에 있는 컴포넌트 가져다 쓰면 편하다. *사내 Design System이나 Figma에서 쓰이는 아이콘이나 색상을참고해보자. (4) 구현 방법서베이(리서치) UX 및 화면 기획이 진행되고 있을 때, 동시에 기술적 구현 방법에 대한 서베이를 병행함(엔지니어) (5) 데이터 파이프라인 스펙정의 어떤 스키마로 데이터 파이프라인이 생성되어야하며 사용자 요구사항에 따라 Backfill 정책은 어떻게 가져갈것인지 보안 정책에 맞게 어떻게 사용자에게 제한을 걸 것인지등 가능한 모든 케이스들을 나열하고 논의할 필요가있음 Step 3. Prototyping (1) 프론트, 서버개발 서베이(리서치)한 내용과 작성된 화면 기획 및 스펙 기반으로 Dev 버전개발 (2) 데이터 파이프라인 샘플 데이터로 화면 프로토타입개발 데이터 분석 플랫폼 특성상 데이터 시각화 화면이있음 데이터 파이프라인을 개발하는 동안 프론트/ 분석 기능 구현 작업을 병행하기 위해, Mockup 데이터 또는 샘플을 미리 개발해전달함 샘플 데이터를 기반으로 플랫폼에 분석 기능이 어떤 형태로 그려지고 작동할지 Prototype을 만들고 팀 내 공유, 피드백 받아개선함 Step 4. DetailedDesign (1) 프론트, 서버개발 프로토타입 단계에서 피드백 받아 개선하며 Production 버전개발 (2) 데이터 파이프라인개발 샘플 데이터에 대한 피드백을 받아 설계한 대로 데이터 파이프라인개발 (3) 실제 파이프라인 데이터로 화면개발 데이터 분석 플랫폼 특성상 데이터 시각화 화면이있음 프로토타입 단계에서 만들어 둔 틀을 활용하되, 데이터만 갈아끼워서 실제 파이프라인의 데이터가 연동된 화면을만듬 Step 5. Validation /Testing (1) 팀 내부 QA 및개선 프론트, 데이터 파이프라인 관련하여 PM이 검토하고피드백 개선 사항 도출하여반영함 (2) 팀 외부 User Testing 및개선 첫 시도해본단계 향후 사용자가 될 수 있는 분들을 1:1 컨택하여 UT진행 개선 사항 도출하여 우선순위 높은 것들 위주로반영함 사용자에게 어떤 질문을했었나 *기존 분석 상황 및 니즈 파악 *플랫폼 사용 화면 공유 (태스크 있게, 없게도 해봄 e.g. 처음 플랫폼을 보는 사람이라고 생각하고 가장 먼저 어떤 것들을 눌러보실 것 같나요?) -> 옆에서 사용 양상을 지켜보며 얻은 개선 포인트정리 (3) 팀 내부 Final QA 및Testing (좌) Dogfooding 개념을 팀에 소개하면서 처음 도전해본 절차 (우) 개선 사항리스트 기능적 완성도를 높인후 플랫폼 팀 내에서 태스크를 설정하여 미팅 시간에 각자 진행하고공유 개선 사항 도출하여 우선순위 높은 것들 위주로반영함 Step 6. Commercialization (1) 사용자 가이드작성 문서화에 힘을 쏟음 (생각보다 사람들은 교육 영상을 잘 보지 않음, 업무에 필요할 때 그 때 그 때 문서찾아봄) 가이드 문서에 유용하게 썼던툴 *스크린샷 깔끔하게 뜨고 번호 매길 수 있는(유료 결제함) 크롬 익스텐션 *크롬에서 gif 뜨는 크롬 익스텐션(유료 결제해야 화질좋아짐) (2) 런칭 소식공지 플랫폼의 주 사용자가 될 만한 구성원 분들이 모여있는 미팅을 활용해서 런칭 소식을공지함 이 때 플랫폼을 기존 업무 프로세스에 어떻게 / 왜 녹여내야 하는지 위주를 추가하여 소개함 (아래 목차에서 활용시나리오) 런칭 공지에 활용했던 슬라이드목차 (3) 사용자 교육진행 교육 Video 중 일부캡쳐 런칭 소식을 공지할 때, 교육 참석 희망자를받음 채널이나 이메일 통해공지함 (4) 운영 방식정립 플랫폼 개발 이후 어떤 식으로 요청에 대응하고 운영할 것인지 논의하여설정함 어떤 미팅, 채널에서 소통할 것인지 논의하여 정해둠 시행착오를 통해 깨달은것들 플랫폼 런칭을 마친 후, 팀원 분들과 회고를 진행했는데요. 회고 후 주요한 배움들을 정리하며, 크게 두 가지 키워드가 가장 중요하다고여겨졌습니다. 사용자, 그리고상용화 더 자세한 배움들은 아래와같습니다. 플랫폼 개발의 목표는 런칭이 아닌 상용화(Commercialization), 사용자 교육과 가이드의 중요성에 대한 공감대가필요하다. 내부 사용자 의견을 적극적으로 청취하고 피드백을 내부 팀/ 엔지니어에 공유하는 것이 동기부여에 도움이된다. 여건이 된다면 사용자 요구사항 수렴을 위한 인터뷰를 기획 단계, 개발 이후 UT 단계에서 모두 진행하는게 좋을 것 같다. (*자꾸 개발하는 입장에서 플랫폼을 어렵게 설계하게됨) 데이터 플랫폼의 경우, 기획 단계에서 데이터 파이프라인 생성 및 백필 관련 가능한 케이스들을 최대한 나열하고, 케이스들을 최대한 대응할 수 있는 구조로 웹 화면 및 세부적인 옵션들을 설계할 필요가있다. 데이터 파이프라인 개발 이전, 초기 Mockup 데이터 또는 간단한 템플릿으로 전체 모습을 미리 그려보는 것이 큰 도움이된다. 서로의 역할 범위를 넘어서더라도, 프로젝트 전체적으로 효율적으로 나아가는 것인지의 관점에서 판단하는 게좋다. 정리하며 본 글은 PM 입장이었던 제가 작성한 글이라 기술적 부분은 생략되었습니다. 협업 문화 및 프로세스를 다루는 콘텐츠를 남겨보고 싶기도했고요. 최선의 협업 프로세스는 어떤 플랫폼을 개발하는지, 어떤 구성원과 함께 하는지, 주어진 시간이 어느 정도인지 등 상황마다 달라질것입니다. 여러 변수로 인해 정답은 없으니 본 글에서 각자 상황에 맞게 필요한 부분들을 참고하시면좋겠습니다. 더 이야기 나누고 싶은 분들은 링크드인으로 메세지주세요! 사내 데이터 플랫폼 개발, 처음이라면? was originally published in Naver Search Data&Analytics Tech Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

댓글 0

댓글을 작성하려면 로그인이 필요합니다.

댓글을 불러오는 중...