[NAVER] AI 에이전트 프로덕트/서비스 기획 (경력) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 프로덕트 기획 및 전략: 의료진 인터뷰, 현장 관찰, 서비스 데이터를 바탕으로 해결해야 할 핵심 문제를 정의하고, 문제를 바로 실행할 수 있는 액션 단위로 나눠 임팩트와 실행 가능성을 기준으로 우선순위를 결정하며, 중장기 제품 방향과 로드맵 수립을 주도합니다.

  이렇게 볼 수 있어요

  공고는 문제 정의의 입력으로 의료진 인터뷰와 현장 관찰을 서비스 데이터보다 먼저 꼽았습니다. 사용자가 진료 현장에서 근거를 찾고 판단하는 전문직이어서, 어떤 질문에서 답변을 쓰지 못하는지는 로그만으로 알기 어렵습니다. 전문직이나 B2B 사용자를 인터뷰해 문제를 뽑고 액션 단위로 쪼갠 사례가 있다면 쪼갠 과제 수와 함께 우선순위에서 밀려난 과제도 꺼낼 만합니다.

• 프로덕트 기획 및 전략: 기획 의도를 프로토타입으로 빠르게 구체화해 개발 조직에 전달하고 실제 서비스 반영까지 함께 이끌며, 반영 이후 사용 데이터와 로그를 분석해 가설을 검증하고 다음 개선 방향을 결정합니다.

  이렇게 볼 수 있어요

  조직 소개에 '긴 기획서보다 작동하는 프로토타입으로 말하고'라는 문장이 있습니다. 이 업무의 산출물도 문서보다 동작하는 화면 쪽입니다. 서비스 기획 트랙에도 직접 프로토타입을 만드는 업무가 있고 우대 사항에 Claude, Codex 등 AI 도구로 만든 프로토타입이 들어 있습니다. 프로토타입을 만든 도구, 개발에 넘긴 뒤 서비스에 반영되기까지 걸린 기간, 반영 뒤 로그에서 확인한 것을 한 사례로 묶을 수 있습니다.

• 프로덕트 기획 및 전략: AI의 동작 방식과 한계를 고려해 사용자 경험과 기능 요구사항을 설계하고, 의료 규제와 임상 안전성을 고려한 기능 출시 기준을 함께 만듭니다.

  이렇게 볼 수 있어요

  출시 기준을 기획자가 다른 조직과 함께 만드는 업무입니다. 서비스 기획 트랙은 법무, 개인정보, AI 안전성 담당자와 출시 기준을 맞춘다고 따로 적어, 이 서비스의 출시 기준은 기능 완성도뿐 아니라 법무, 개인정보, 안전성 쪽 기준까지 함께 다룹니다. 개인정보나 금융처럼 출시 전 검토 조직이 있는 서비스에서 출시 기준 문서를 쓴 경험, AI 답변이 틀렸을 때 어디까지 허용할지 정한 기준이 가장 가까운 사례입니다.

• 프로덕트 기획 및 전략: 서비스 핵심 지표와 로그 분석 체계를 정의하고 운영하며, AI 응답 품질 평가와 사용자 피드백을 바탕으로 개선을 반복합니다.

  이렇게 볼 수 있어요

  지표가 두 종류로 나뉩니다. 사용 지표(사용자 수, 다시 찾는 비율)는 로그에서 나오고, AI 응답 품질은 별도 평가 기준이 있어야 잴 수 있습니다. 같은 공고의 서비스 기획 트랙은 '좋은 답변'의 평가 기준을 만드는 일을 따로 업무로 적었습니다. 응답 품질 지표를 사용 지표와 따로 정의해 개선 과제로 이어 간 경험이 있다면 두 지표를 어떻게 구분했는지가 사례의 핵심입니다.

• 프로덕트 기획 및 전략: 연구·개발·디자인·임상 자문 조직 간 의견을 조율하고 의사결정을 이끌며, 동료 기획자의 기획안을 리뷰하고 팀에 맞는 기획 프로세스와 산출물 기준을 정립합니다.

  이렇게 볼 수 있어요

  협업 상대에 임상 자문 조직이 들어 있어 의료 전문가 의견과 모델 연구 일정, 개발 일정이 부딪칠 때 기획자가 정리하게 됩니다. 동료 기획안 리뷰와 기획 프로세스 정립은 프로덕트 트랙 업무 소개의 '팀의 기획 수준을 함께 끌어올리는 역할'이 구체적으로 드러난 업무입니다. 네이버웹툰 서비스 기획 Senior PM 공고도 동료 기획안 리뷰를 업무로 적었는데, 그 공고는 경력 7년 이상이고 이 공고의 프로덕트 트랙은 연차를 적지 않았습니다.

• 서비스 기획: AI가 어떤 질문에 어디까지, 어떤 형식으로 답할지 기준을 정하고, 출처를 어떻게 보여줄지와 애매한 질문에 어떻게 답할지도 포함하며, '좋은 답변'을 판단하는 평가 기준을 만들고 의료진 인터뷰와 평가 결과를 바탕으로 고칠 점을 찾습니다.

  이렇게 볼 수 있어요

  기획자가 정하는 대상이 화면이 아니라 답변 정책입니다. 어떤 질문은 답하지 않고 어떤 질문은 출처와 함께 답하는지가 서비스의 신뢰를 정합니다. 평가 기준을 만든 경험에서는 평가 항목, 평가하는 사람, 기준을 바꾼 계기를 꺼냅니다. 콘텐츠 가이드라인이나 상담 응답 기준처럼 답변의 허용 범위를 문서로 정한 경험도 같은 종류입니다.

• 서비스 기획: AI가 자주 틀리는 경우를 모아 유형별로 정리해 개선 과제로 만들고(예: 보험 기준 착오, 의학 약어 오해, 비슷한 약 이름 혼동), AI 연구팀과 함께 개선이 잘 되었는지 확인하고 기준에 반영합니다.

  이렇게 볼 수 있어요

  예시로 든 보험 기준, 의학 약어, 약 이름은 의료 지식이 있어야 틀렸는지 알 수 있는 오류입니다. 그래서 유형을 나누는 기준에 의료진 피드백이 쓰일 수 있습니다. 오류 유형을 몇 개로 나눴는지, 유형마다 어떤 개선 과제가 나왔는지, 연구팀이 개선을 확인한 방법이 무엇이었는지가 이 업무의 사례가 됩니다.

• 서비스 기획: 의료진 인터뷰, 사용성 테스트, 설문을 직접 준비하고 진행해 기획에 반영합니다.

  이렇게 볼 수 있어요

  '직접 준비하고 진행해'라고 적어, 리서치 전담 인력에게 넘기기보다 기획자가 인터뷰와 테스트를 맡는 구조로 보입니다. 사용자가 의사·간호사·약사 등 의료진이라 대상 모집과 진료 시간 사이의 일정 조율까지 준비 일에 들어가기 쉽습니다. 인터뷰한 사람 수와 직군, 결과로 바뀐 기획 항목을 함께 적으면 필수 요건의 인터뷰나 테스트 결과로 기획을 바꾼 경험과 한 사례로 묶입니다.

• 서비스 기획: 사용자가 서비스를 이용하는 흐름을 정리하고, 화면 설계서와 기능 정의서를 작성하며, 직접 프로토타입을 만들어 봅니다. AI 답변 옆에 출처를 보여주는 방식, 처음 쓰는 사람을 위한 안내 화면 등 사용 경험을 설계합니다.

  이렇게 볼 수 있어요

  출처를 답변 옆에 보여주는 방식은 의료진이 근거를 확인하는 동선과 직결됩니다. 조직 소개가 의료진이 진료 현장에서 근거를 찾고 판단하는 과정을 돕는 서비스라고 적었기 때문입니다. 화면 설계서에 출처 표시, 답변을 못 하는 상태, 애매한 질문에 되묻는 화면을 어떻게 그렸는지가 포트폴리오로 보여 줄 부분입니다.

• 서비스 기획: 정식 출시 전 일부 사용자 대상 테스트를 운영하고, 사용자 수, 다시 찾는 비율 같은 지표와 설문 결과를 분석합니다.

  이렇게 볼 수 있어요

  전체 공개 전에 일부 사용자에게 먼저 여는 방식이라 모수가 작고, 재방문 비율은 몇 명만 움직여도 크게 달라집니다. 그래서 지표와 설문을 함께 읽는 일이 중심입니다. 지표가 말하는 행동(다시 찾았는지)과 설문이 말하는 인식(믿을 만했는지)이 어긋났던 사례가 있다면, 어떤 쪽을 따라 기획을 고쳤는지도 함께 씁니다.

• 서비스 기획: 개발, 연구, 법무, 개인정보, AI 안전성 담당자와 함께 출시 기준을 맞추고 서비스를 운영하며, 반복되는 일은 AI 도구로 자동화해 더 효율적으로 일합니다.

  이렇게 볼 수 있어요

  협업 상대 다섯 곳 가운데 법무, 개인정보, AI 안전성 세 곳은 기능이 아니라 규제와 안전 쪽에서 출시 기준을 함께 정하는 담당입니다. 이 서비스에서는 기획자의 일정만으로 출시 시점을 정하기 어려울 수 있어서 검토 조직과 일정을 미리 맞춘 경험이 업무에 가깝습니다. 자동화한 반복 업무가 있다면 업무 이름과 줄어든 시간을 함께 적습니다.

2자격 요건

• 프로덕트 기획 및 전략: LLM 등 AI 기반 서비스를 직접 기획하고 출시해 본 End-to-End 경험을 보유해야 합니다.

  이렇게 볼 수 있어요

  이 팀은 조직 소개에서 '모델의 한계와 리스크를 솔직하게 다루고'라고 밝혔습니다. AI 서비스를 기획해 출시한 End-to-End 경험 가운데 AI 기능이 틀리는 순간의 화면과 정책을 직접 정한 부분이 이 팀에서 특히 쓰입니다. 같은 공고가 서비스 기획 업무의 오류 예시로 든 보험 기준 착오, 의학 약어 오해, 비슷한 약 이름 혼동은 모두 틀린 답이 의료진의 판단에 쓰일 수 있는 종류입니다. LLM 서비스가 아니더라도 추천, 검색, 자동 분류처럼 결과가 틀릴 수 있는 AI 기능을 출시했다면, 틀렸을 때의 처리를 어떻게 정했는지가 이 팀이 볼 부분입니다.

• 프로덕트 기획 및 전략: 복잡하고 모호한 문제를 구조화해 요구사항과 기능 명세로 풀어낸 경험이 필요하고, 완벽한 정보가 갖춰지기 전에도 가설을 세우고 빠르게 확인하며 방향을 조정해 나갈 수 있어야 합니다.

  이렇게 볼 수 있어요

  조직 소개가 '아이디어가 실제 서비스에 반영되고 사용자 반응으로 돌아오기까지의 거리가 짧은 팀'이라고 적었습니다. 이 주기에서는 정보가 다 모이기를 기다리지 않고 결정합니다. 가설 하나를 골라 확인에 쓴 방법과 기간, 그 결과로 방향을 바꾼 결정을 한 사례로 묶습니다.

• 프로덕트 기획 및 전략: 사용자 리서치와 데이터를 근거로 제품 결정을 내려 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  업무에서 리서치와 데이터는 두 번 쓰입니다. 문제를 정의할 때는 의료진 인터뷰, 현장 관찰, 서비스 데이터가 입력이고, 서비스에 반영한 뒤에는 사용 데이터와 로그로 가설을 검증합니다. 리서치 결과와 로그 데이터가 서로 다른 방향을 가리켰을 때 어느 쪽을 따랐고 이후 로그에서 무엇이 확인됐는지 적으면 두 단계가 한 사례에 담깁니다.

• 프로덕트 기획 및 전략: 연구자·엔지니어 등 서로 다른 언어를 쓰는 사람들 사이에서 합의를 만들어 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  조직 소개는 기획, 개발, 연구가 한 팀처럼 붙어 일한다고 적었고 서비스 기획 트랙도 개발자와 연구원에게 원하는 바를 명확하게 설명하는 능력을 요구합니다. 모델 쪽 제약과 기획 요구가 달랐던 안건에서 어떤 문서나 시연으로 합의했는지가 사례가 됩니다.

• 서비스 기획: 서비스 기획 경력 5년 미만이어야 합니다.

  이렇게 볼 수 있어요

  같은 공고의 프로덕트 기획 및 전략 트랙은 연차를 적지 않았고 업무에 로드맵 수립 주도와 동료 기획자 리뷰가 있습니다. 서비스 기획 트랙은 5년 미만에 화면 설계서와 기능 정의서를 직접 쓰는 업무를 적어 두 트랙의 업무 범위가 다릅니다. NAVER 헬스케어 서비스 기획(리더급) 공고는 10년차 이상에 리더 경력 3년 이상을 요구했습니다. 이 트랙의 5년 미만은 그 공고와 반대쪽 끝에 있는 연차입니다.

• 서비스 기획: AI 답변 품질을 평가해 봤거나, 콘텐츠·운영 기준을 직접 만들어 보신 경험이 필요합니다.

  이렇게 볼 수 있어요

  AI 답변 평가 경험과 콘텐츠·운영 기준 작성 경험은 이 조건에 함께 적을 수 있습니다. 이 트랙의 업무는 '좋은 답변'의 평가 기준을 만드는 데서 시작해 의료진 인터뷰와 평가 결과에서 고칠 점을 찾고, AI 연구팀과 개선을 확인해 기준에 반영하는 데까지 한 바퀴로 이어집니다. 가이드라인을 쓴 뒤 그 기준으로 결과물을 점검하고 기준을 고친 경험이라면 이 한 바퀴를 처음부터 끝까지 다뤄 본 사례입니다.

• 서비스 기획: 실제 출시했거나 실사용자 테스트까지 간 서비스에서 기획을 직접 맡아 봤어야 하고, 사용자 인터뷰나 테스트 결과를 보고 기획을 바꿔 본 경험이 필요합니다.

  이렇게 볼 수 있어요

  출시까지 가지 못한 서비스라도 베타처럼 일부 사용자에게 연 단계까지 갔다면 연 대상, 사용자 수, 기간을 적어 실사용자 테스트 경험으로 보여 줄 수 있습니다. 사내 시범은 사용자가 직원이라 외부 사용자 테스트와 다르므로, 직원이 실제 업무에 쓴 서비스였는지를 함께 적습니다. 업무가 정식 출시 전 일부 사용자 테스트를 운영하고 사용자 수, 다시 찾는 비율, 설문을 분석하는 일이어서, 테스트 단계에서 이 지표를 직접 보고 기획을 바꾼 경험이 가장 가깝습니다. 바뀐 기획 항목은 계기가 된 테스트 결과와 함께 적습니다.

• 서비스 기획: 화면 설계서, 기능 정의서 같은 기획 문서를 직접 쓸 수 있고, 개발자·연구원에게 원하는 바를 명확하게 설명할 수 있어야 합니다.

  이렇게 볼 수 있어요

  화면 설계서와 기능 정의서는 개발자에게 구현 범위를, 연구원에게는 AI에게 바라는 동작(어떤 질문에 답하고 어떤 질문에 답하지 않는지 같은 답변 기준)을 전달하는 문서입니다. 업무에 프로토타입 제작도 함께 적혀 있어 문서와 프로토타입 가운데 어느 쪽으로 설명했는지가 사례의 구성이 됩니다. 공개할 수 있는 화면 설계서 일부에서 예외 상태를 어떻게 적었는지 골라 보여 줍니다.

3우대 사항

• 프로덕트 기획 및 전략: 서비스 기획 업무에서 PM·PO 경험과 0→1 서비스 출시 또는 파트·프로젝트 리드 경험을 우대합니다.

  이렇게 볼 수 있어요

  PM·PO 경험은 업무의 중장기 제품 방향과 로드맵 수립 주도에, 파트·프로젝트 리드 경험은 연구·개발·디자인·임상 자문 조직 사이 의사결정을 이끄는 업무에 각각 쓰입니다. 0→1 서비스 출시 경험과 파트·프로젝트 리드 경험은 이 조건에 함께 적을 수 있습니다. 0→1 서비스라면 출시 전 가설과 출시 뒤 지표의 차이를, 리드 경험이라면 이끈 사람 수와 정한 결정 범위를 적습니다.

• 프로덕트 기획 및 전략: 헬스케어 서비스 기획 경험(EMR/EHR, 건강관리 앱, 임상 의사결정 지원 등)을 우대합니다.

  이렇게 볼 수 있어요

  EMR/EHR은 병원의 전자의무기록 시스템이고 임상 의사결정 지원은 진료 중 근거나 경고를 의료진에게 보여 주는 기능입니다. 이 팀의 서비스도 의료진이 진료 현장에서 근거를 찾고 판단하는 과정을 돕는 AI 서비스여서, 의료진의 판단 흐름 안에서 쓰이는 도구를 기획한 경험이 이 우대와 가깝습니다. 의료 분야가 아니어도 전문직이 쓰는 도구를 기획했다면 사용자가 누구였고 어떤 판단을 돕는 기능이었는지로 적습니다.

• 서비스 기획: 의사, 교사, 변호사 등 전문가가 쓰는 서비스를 만들어 봤거나 개인정보, 의료처럼 규제가 있는 분야에서 서비스 출시와 운영을 해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  전문가용 서비스의 사용자는 결과가 틀렸을 때 알아보는 사람들이라 답변 품질의 기준이 높아집니다. 규제 분야 경험은 업무의 출시 기준을 법무, 개인정보 담당자와 맞추는 일과 같은 종류입니다. 전문가용 서비스 경험은 사용자 쪽을, 규제 분야 경험은 출시 절차 쪽을 보여 줍니다.

• 프로덕트 기획 및 전략: LLM·RAG·AI Agent 기반 서비스를 설계하거나 평가해 본 경험을 우대합니다. 서비스 기획: LLM 기반 서비스에서 답변/평가 기준과 가이드에 따라 수행하며 개선 의견이나 시도를 해 봤거나, AI가 틀린 사례를 모아 유형별로 나누고 개선 과제로 만들어 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  프로덕트 트랙 우대의 RAG는 문서를 검색해 그 내용을 근거로 답하게 하는 구조입니다. RAG 설계는 서비스 기획 업무의 '출처를 어떻게 보여줄지'와 함께 정해야 합니다. 프로덕트 트랙은 AI 서비스를 설계하거나 평가한 경험을, 서비스 기획 트랙은 평가 기준과 가이드에 따라 일하며 개선 의견을 낸 경험까지 우대합니다. 평가자로 일하며 기준의 빈틈을 발견해 제안한 사례는 서비스 기획 트랙 쪽 우대에 쓰입니다.

• 프로덕트 기획 및 전략: Claude, Codex 등 AI 도구로 직접 프로토타입을 만들어 기획을 구체화해 본 경험을 우대합니다. 서비스 기획: Claude, Codex 등 AI 도구로 직접 프로토타입을 만들거나 반복 업무를 자동화해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  Claude, Codex는 코드까지 만들 수 있는 AI 도구입니다. 조직 소개도 '작동하는 프로토타입'을 말하므로 이 우대의 프로토타입은 그림보다 동작하는 화면 쪽입니다. 프로덕트 트랙은 프로토타입 쪽만, 서비스 기획 트랙은 프로토타입과 반복 업무 자동화 양쪽을 적었습니다. 프로토타입을 만든 도구와 입력한 지시, 개발 조직에 넘긴 결과물을 보여 주고, 자동화는 대상 업무와 줄어든 시간을 적습니다.

• 프로덕트 기획 및 전략: SQL 등을 활용해 직접 데이터를 분석해 본 경험과 영어로 스펙 문서를 작성하고 글로벌 파트너와 협의할 수 있는 역량을 우대합니다. 서비스 기획: 테스트 결과를 지표와 설문으로 분석해 이를 근거로 개선 포인트를 도출해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  SQL로 로그를 직접 조회하면 업무의 '서비스 핵심 지표와 로그 분석 체계를 정의하고 운영'에서 데이터 추출을 다른 사람에게 요청하지 않고 기획자가 바로 확인합니다. 서비스 기획 트랙의 우대는 소규모 테스트의 지표와 설문을 함께 분석해 개선점을 낸 경험으로, 테스트 결과를 분석하는 업무와 같은 방향입니다. 쿼리를 직접 짠 경험은 쿼리가 답한 질문과 그 결과로 바뀐 결정을, 테스트 분석 경험은 지표와 설문에서 나온 개선 포인트를 적습니다.

4기타 사항

• 게시일 : 2026년 11월 3일
• 고용형태 : 정규직
• 근무지 : 경기도 성남시 분당구 정자일로 95 (NAVER 1784 사옥) (추정)
• 경력 조건 : 서비스 기획 경력 5년 미만(AI 에이전트 서비스 기획 트랙)
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

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

• LLM
• RAG
• AI Agent
• SQL
• Claude
• Codex

전형과 지원

같은 채용 사이트에서 지원해도 법인마다 전형 단계가 다릅니다. 모든 계열 공고에 공통으로 들어 있는 것은 기업문화 적합도 검사와 마감일입니다.

지원 전 준비할 것

1. 1

   지원할 트랙을 하나로

   프로덕트 기획 및 전략은 연차 조건이 없고 로드맵 수립과 팀의 기획 수준 향상까지 맡습니다. 서비스 기획은 경력 5년 미만에 답변 기준, 화면 설계서, 사용성 테스트를 직접 합니다. 가까운 쪽 하나를 고르고 그 트랙의 필수 항목마다 사례를 하나씩 정리하세요.

2. 2

   의료나 법률 AI 서비스의 출처 표시 관찰

   틀리면 곤란한 영역의 AI 서비스를 하나 골라 출처가 어디에 어떻게 보이는지, 애매한 질문에 어떻게 답하는지 화면을 캡처해 바꾸고 싶은 점과 함께 정리합니다. 서비스 기획 트랙의 답변 기준과 화면 설계 업무가 묻는 것과 같은 질문입니다.

3. 3

   작동하는 프로토타입 하나

   조직 소개가 '긴 기획서보다 작동하는 프로토타입으로 말하고'라고 적었습니다. Claude나 Codex 같은 도구로 기획 의도를 동작하는 화면으로 만들고, 만든 과정과 개발에 넘길 요구사항을 함께 정리해 가면 우대 사항과 인터뷰 질문 양쪽에 내놓을 자료가 됩니다.