[힐링페이퍼] [병원 운영 솔루션] Data Product Owner 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 병원마다 다르게 쓰는 시술명과 수가를 표준 시술로 묶는 시술 데이터 표준화 엔진의 데이터 모델, 마트, 파이프라인을 설계하고 우선순위를 정하며, 구현은 백엔드 엔지니어와 함께하고 매핑 품질과 데이터 정합성은 직접 책임집니다.

  이렇게 볼 수 있어요

  회사 블로그의 KOS 소개 글은 병원(Tenant)마다 물리적으로 분리된 네트워크와 개별 데이터베이스를 쓴다고 소개합니다. 병원별로 따로 쌓인 데이터에서는 같은 시술이 병원마다 다른 이름과 가격으로 나오므로, 표준 시술로 묶는 매핑이 병원 간 비교의 전제입니다. 구현을 함께할 KOS 백엔드 개발자의 공고는 이벤트 소싱과 CQRS 이해를 우대합니다. 그래서 매핑 오류가 났을 때 어느 단계에서 고칠지를 백엔드와 정해 본 경험이 이 업무와 맞습니다.

• 신환과 구환 구분, 선불권 매출 처리, 시술 회차처럼 숫자를 좌우하는 정의를 세우고 지키며, 팀원 누구나 AI로 숫자를 뽑는 환경에서 그 숫자가 맞는지를 보장하는 기준선을 관리합니다.

  이렇게 볼 수 있어요

  선불권은 결제한 날과 시술받는 날이 달라 매출을 결제 시점으로 잡을지 시술 시점으로 잡을지에 따라 같은 달 숫자가 달라집니다. 신환도 처음 내원한 환자로 볼지 일정 기간 내원이 없던 환자로 볼지에 따라 병원별 신환 수가 달라지므로, 이 정의를 문서로 고정하는 일이 AI가 뽑은 숫자의 기준이 됩니다. 정의 하나를 바꿨을 때 과거 숫자가 얼마나 달라지는지 확인한 경험이 이 업무와 같은 종류입니다.

• AI 분석 제품 KOS Insight를 원장님의 비서가 되어 명확하고 신뢰도 있는 데이터를 설명하도록 만들고, KOS에 필요한 데이터를 기반으로 병원에 가치를 전달하는 제품을 만듭니다.

  이렇게 볼 수 있어요

  지표 정의 항목에 따르면 이 팀에는 팀원 누구나 AI로 숫자를 뽑는 사내 환경이 이미 있고, KOS Insight는 같은 AI 방식을 병원 원장님에게 숫자를 설명하는 제품으로 만드는 일로 보입니다. 사내에서는 틀린 숫자가 나와도 팀 안에서 다시 확인할 수 있지만 병원에 전달된 설명은 병원의 운영과 마케팅 판단에 쓰이므로, 지표 정의와 표준 시술 매핑이 이 제품의 정확도를 정하는 입력입니다. AI 답변의 품질을 지표 정의 문서와 함께 관리해 본 경험이 이 업무의 사례로 쓰입니다.

• 대시보드를 넘어 병원의 운영 판단을 데이터가 대신 돕는 구독형 상품을 팀과 함께 설계하고, 강남언니와의 데이터 연계와 외부 파트너 대상 데이터 사업으로 데이터가 매출이 되는 경로를 넓힙니다.

  이렇게 볼 수 있어요

  병원은 이미 강남언니에 광고비를 내는 고객입니다(2025년 감사보고서의 성과형광고 약 593억 원과 배너광고 약 84억 원). KOS를 쓰는 병원이 강남언니 광고주이기도 하면 구독은 같은 병원에게 받는 두 번째 비용이 되므로, 광고로 얻는 것과 구독으로 얻는 것이 어떻게 다른지가 가격 설계에서 먼저 풀어야 할 질문일 가능성이 큽니다. 강남언니의 수요 데이터와 KOS의 병원 운영 데이터를 함께 볼 수 있다는 점은 구독 상품이 다른 병원 SaaS와 달라질 수 있는 지점입니다.

• 셀프서브 분석 체계가 더 정확하게 돌아가도록 도메인 규칙과 분석 스킬 문서를 정비하고, 타팀의 데이터 요청이 사람을 거치지 않고 체계 안에서 풀리도록 만듭니다.

  이렇게 볼 수 있어요

  같은 채용 사이트의 Analytics Engineer 공고도 누구나 필요한 데이터를 스스로 찾아 쓰는 셀프 서비스 환경을 지향합니다. 그 공고는 전사 데이터 계약과 네이밍 룰을 맡고 이 공고는 KOS 병원 데이터의 도메인 규칙과 분석 스킬 문서를 맡으므로, 두 체계가 같은 지표를 다르게 정의하지 않게 맞추는 일이 따릅니다. AI가 쿼리를 쓰는 환경에서 도메인 규칙 문서를 고쳐 오답이 줄어든 경험이 있다면 오답 유형과 줄어든 비율을 함께 말할 수 있습니다.

2자격 요건

• 데이터 분석, 분석 엔지니어링, 데이터 엔지니어링 등 데이터 직무 경력 3년 이상이 필요합니다.

  이렇게 볼 수 있어요

  공고는 직무 이름을 데이터 분석, 분석 엔지니어링, 데이터 엔지니어링으로 넓게 적었고 업무는 제품 정의까지 뻗어 있습니다. Analytics Engineer 공고도 3년이지만 이 공고에는 제품 오너십이 붙습니다. 분석가였다면 쿼리 결과를 제품 결정으로 연결한 일을, 엔지니어였다면 만든 마트의 사용자가 누구였는지를 함께 말합니다.

• 데이터 모델링, 마트, 파이프라인을 직접 설계하고 운영해 본 경험이 필요하고, 쿼리를 잘 짜는 것을 넘어 어떤 테이블 구조가 맞는지 스스로 판단할 수 있어야 합니다.

  이렇게 볼 수 있어요

  업무의 첫 과제가 표준 시술 데이터 모델이라 이 요건은 쿼리 실력보다 구조 판단을 묻습니다. 병원마다 다른 시술명을 하나로 묶을 때는 원본 이름을 보존하는 테이블과 표준 이름으로 묶은 테이블을 나눌지, 매핑이 바뀔 때 과거 집계를 어떻게 처리할지 같은 선택이 생깁니다. 이런 구조 선택을 한 프로젝트가 있다면 고른 구조와 버린 대안을 함께 말합니다.

• 여러 소스의 데이터를 결합하며 정합성 문제를 찾아내고 다시 생기지 않는 구조로 고쳐 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  KOS는 병원마다 개별 데이터베이스를 쓰고 업무에는 강남언니와의 데이터 연계도 있어 소스마다 키와 단위가 다릅니다. 병원 시스템의 환자 번호와 플랫폼의 유저 ID를 맞추는 것처럼 키가 다른 소스를 결합하다 중복이나 누락을 찾은 일이 있다면, 재발하지 않게 바꾼 규칙까지 설명합니다.

• 조직이 함께 쓰는 핵심 지표를 정의하고 정의가 흔들리지 않도록 문서와 체계로 관리해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  같은 회사 Analytics Engineer 공고는 전사 KPI 정의를 고도화하고 데이터 계약과 네이밍 룰, SLA 기반 반영 주기로 일관성을 지킨다고 적었습니다. 이 공고의 정의 대상은 신환과 구환, 선불권 매출, 시술 회차 같은 병원 지표라서 정의를 지키는 장치도 병원 데이터에 맞춘 것이 따로 필요해 보입니다. 문서로만 남긴 정의는 AI가 쿼리를 쓰는 환경에서 어긋나기 쉽습니다. 문서와 함께 검증 쿼리나 테스트로 정의를 지킨 경험이 있다면 그 장치가 무엇이었는지 함께 적을 수 있습니다.

• 같은 질문에 다른 숫자가 나오는 상황을 원인까지 파고들어 하나의 기준으로 정리해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  선불권 매출처럼 결제 시점과 시술 시점이 다른 항목은 두 부서가 같은 질문에 다른 숫자를 내기 쉬운 곳입니다. 원인을 정의 차이, 집계 시점, 데이터 누락 가운데 어디서 찾았는지 구분해 적으면 하나의 기준으로 정리한 과정이 드러납니다. Analytics Engineer 공고도 전사 KPI 정의를 업무로 적어 이 경험은 두 공고에 모두 쓰입니다.

• 데이터 기반 기능, 대시보드, 리포트를 문제 정의부터 출시와 개선까지 끌고 가 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  경험 항목은 내가 정의한 숫자가 병원의 운영, 마케팅, 상담 결정에 쓰이는 것을 직접 확인한다고 적었습니다. 팀 소개에 따르면 KOS는 분석 시점에 데이터를 병원이 비용을 내고 쓰는 제품으로 만드는 단계에 있습니다. KOS Insight처럼 병원에 전달하는 데이터 제품은 가치가 숫자의 정확성에 달려 있어, 출시는 화면을 내는 데서 끝나지 않습니다. 대시보드나 리포트를 낸 뒤 사용 로그로 병원이 어느 지표를 보고 어느 화면에서 떠나는지 확인해 다음 버전을 바꾼 과정이 이 요건과 맞습니다.

• '이 데이터로 고객에게 어떤 가치를 줄 수 있는가'를 스스로 묻고 그 답을 실제 산출물로 만든 경험이 필요합니다.

  이렇게 볼 수 있어요

  이 팀에서 고객은 병원이고 데이터는 병원의 시술, 매출, 고객 정보입니다. 질문을 던진 데서 멈추지 않고 병원 원장님이 쓰는 산출물(리포트, 알림, 상품)로 낸 경험을 그 산출물이 병원의 어떤 결정을 바꿨는지와 함께 쓰면 요건이 말한 '실제 산출물'까지 간 과정을 보여 줍니다.

• 엔지니어, 디자이너, 사업 조직과 우선순위를 조율하며 맡은 일을 끝까지 완수해 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  KOS 팀은 개발자, PO, 디자이너가 하나의 제품에 몰입하는 ONE 팀이고 구현은 백엔드 엔지니어와 함께합니다(KOS 백엔드 개발자 공고). 우선순위가 부딪힐 때 데이터 표준화처럼 눈에 안 보이는 작업과 기능 개발 사이에서 시간을 어떻게 나눴는지, 끝까지 마친 일과 접은 일을 구분해 쓰면 완수 경험이 분명해집니다.

3우대 사항

• 외부 고객이 비용을 내고 쓰는 데이터 제품을 운영하고 그 숫자의 정확성에 책임져 봤으면 우대합니다.

  이렇게 볼 수 있어요

  이 공고의 업무는 병원이 비용을 내고 쓰는 제품을 만드는 일이라 숫자가 틀리면 사내 문의가 아니라 고객의 항의로 돌아옵니다. 사내 대시보드와 달리 외부 고객이 비용을 낸 데이터 제품에서 숫자 오류를 겪은 일이 있다면 어떻게 알았고 고객에게 어떻게 알렸는지를 우대 경험으로 들 수 있습니다.

• 데이터를 기반으로 구독 상품이나 가격 모델을 설계해 봤으면 우대합니다.

  이렇게 볼 수 있어요

  업무에 구독형 상품 설계가 있고 구독 고객인 병원은 강남언니에 광고비도 내는 고객입니다(2025년 감사보고서). 사용량 기반이나 기능 단계별 같은 가격 모델을 데이터로 검증한 경험이 있다면 어떤 지표로 가격 구간을 나눴는지 설명합니다.

• Snowflake 기반 데이터 모델링 경험과 Metabase 등 BI 툴로 대시보드 체계를 운영한 경험이 있으면 우대합니다.

  이렇게 볼 수 있어요

  Snowflake는 같은 채용 사이트의 Analytics Engineer 공고와 AI Foundation 백엔드 공고도 적은 데이터 도구라 이 회사 안에서 여러 팀이 씁니다. Metabase 외의 BI 툴을 운영했다면 대시보드 권한과 지표 정의를 어떻게 관리했는지를 도구 이름과 분리해 적을 수 있습니다.

• AI 도구로 분석 체계를 만들어 본인보다 팀의 산출량을 키워 본 경험이 있으면 우대합니다.

  이렇게 볼 수 있어요

  업무에 팀원 누구나 AI로 숫자를 뽑는 환경이 적혀 있고 이 공고의 지원 패키지에는 AI 서비스 이용 비용 지원이 있습니다. 내 분석 속도가 빨라진 경험보다 도메인 규칙 문서나 질의 템플릿을 만들어 다른 사람이 같은 품질로 분석하게 한 경험이 '본인보다 팀의 산출량'이라는 문구에 가깝습니다.

• B2B SaaS 또는 의료/헬스케어 도메인 경험이 있으면 우대합니다.

  이렇게 볼 수 있어요

  KOS는 병원을 고객으로 둔 B2B SaaS이고 병원 데이터에는 시술, 매출, 고객 정보가 함께 있어 개인정보와 민감한 정보가 섞입니다. 의료 데이터를 다뤘다면 환자 식별 정보를 어떻게 분리하고 접근 권한을 어떻게 나눴는지로 설명하는 쪽이 이 팀의 데이터 다루는 방식과 같은 방향입니다.

• AARRR, 코호트, 세그먼트 등 분석 프레임워크를 설계하고 실무에 적용해 봤으면 우대합니다.

  이렇게 볼 수 있어요

  강남언니는 정보 탐색에서 상담신청, 예약, 내원, 후기까지 단계가 길어 AARRR 같은 퍼널 틀이 자연스럽게 쓰이는 서비스입니다. 병원 쪽에서는 신환과 구환이 코호트의 출발점이 되므로 구환의 재방문 코호트처럼 이 팀의 정의와 이어지는 틀을 적으면 우대 항목과 업무가 연결됩니다.

4기타 사항

• 게시일 : 2026년 10월 16일
• 고용형태 : 정규직
• 근무지 : 서울특별시 강남구 테헤란로 142 아크플레이스 15층
• 경력 조건 : 경력 3년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

공고 본문에 적힌 기술만 모은 목록입니다.

• Snowflake
• Metabase

전형과 지원

힐링페이퍼 경력 공고는 대부분 서류지원, 직무 인터뷰(온라인), 협업 인터뷰(오프라인), 바레이저 인터뷰(오프라인), 평판조회, 최종합격 순서를 적었습니다. 개발 직군은 공고에 따라 사전 테스트가 붙고, 디자인·마케팅·에디터 공고는 대부분 포트폴리오가 필수입니다(소셜미디어 에디터 공고는 인스타그램 채널 계정).

지원 전 준비할 것

1. 1

   시술 매핑 사례

   서로 다른 이름의 항목을 표준 항목으로 묶은 경험 하나를 골라 매핑 규칙, 품질을 잰 방법, 매핑이 틀렸을 때 고친 절차를 정리합니다.

2. 2

   지표 정의서 한 장

   신환과 구환, 선불권 매출, 시술 회차와 가까운 지표(재방문, 선결제 매출 등)를 내 경험에서 하나 골라 정의를 바꿨을 때 과거 숫자가 얼마나 달라졌는지 정리합니다.

3. 3

   데이터 상품화 사례

   데이터나 리포트를 외부 고객에게 팔거나 구독으로 제공한 경험이 있으면 가격 구간, 고객 반응, 숫자 정확성을 지킨 방법을 순서대로 적습니다.