당근 PM 인턴 지원서, 개선 아이디어보다 먼저 보여줄 것

당근 PM 인턴 지원서에서 스토리 개선안을 쓴다면, 동네 영상을 본 사람이 어떤 정보를 얻고 다음에 무엇을 하게 되는지부터 살펴보세요. 당근이 숏폼을 통해 어떤 정보를 주고 사람들을 연결하려는지 이해해야, 개선 방향을 정할 수 있습니다. 이 글에서는 제품 방향과 인턴의 업무를 연결하고, 실제 합격 서류를 참고해 개선안과 협업 경험을 지원서에 정리하는 방법을 설명합니다.

분석 대상은 당근마켓으로도 알려진 당근의 숏폼팀 PM 인턴 공고입니다. 해당 공고의 서류 마감은 2026년 9월 8일 23시 59분으로 안내됐습니다. 9월 9일 현재 접수가 마감됐고 상세 페이지도 조회되지 않으므로, 새로운 모집 여부는 당근 채용에서 확인하세요. 아래 직무와 지원 조건은 9월 8일 확인한 공고를 기준으로 합니다.

사례로는 당근 운영개발 PM 인턴 합격 서류를 살펴봅니다. 숏폼팀과는 다른 시기의 채용이지만, 사용자의 불편을 발견하고 개선 방법을 선택한 이유를 서류에 어떻게 설명했는지 참고할 수 있습니다.

당근은 왜 동네 플랫폼에 숏폼을 더했을까요?

당근 스토리의 출발점은 동네 가게와 장소를 더 생생하게 발견하도록 돕는 것이었습니다. 2023년 출시 안내는 사진과 글만으로 전하기 어려운 가게 분위기와 시설을 영상으로 보여주고, 가게를 알리고 싶은 사장님과 가까운 곳의 정보를 찾는 주민을 연결한다고 설명합니다. 당근 스토리 출시 배경

이후 제품 변화도 이 방향과 연결됩니다. 2024년에는 도보 10분 거리의 가게 영상을 모아보는 기능을 선보였고, 2025년에는 앱 안에서 촬영과 편집을 마칠 수 있는 스토리 에디터를 출시했습니다. 이런 변화는 주민이 가까운 곳의 정보를 쉽게 찾고, 직접 찍은 영상도 공유하도록 돕는 방향으로 볼 수 있습니다. ‘걸어서 10분’ 기능, 스토리 에디터 출시

따라서 지원서에서 ‘숏폼이 유행하니 시청시간을 늘려야 한다’고만 쓰면 당근이 다루는 문제를 충분히 설명하기 어렵습니다. 이 영상을 본 사람이 가보고 싶은 동네 장소를 발견했는지, 방문할지 결정하는 데 필요한 정보를 얻었는지, 다음에도 지역 정보를 찾으러 올 이유가 생겼는지까지 생각해보세요.

지역 기반 서비스에서는 같은 영상도 보는 사람의 위치와 목적에 따라 유용성이 달라질 수 있습니다. 오늘 점심을 먹을 곳을 찾는 사람에게는 가까운 가게의 메뉴와 분위기가 중요할 수 있고, 주말 나들이를 계획하는 사람에게는 이동할 만한 가치가 있는 장소인지가 중요할 수 있습니다. 개선안을 제안할 때는 누구의 어떤 이용 상황을 다루는지 먼저 정하세요.

숏폼팀 공고는 PM 인턴에게 어떤 일을 맡겼을까요?

분석한 공고는 당근 스토리가 초기 출시를 거쳐 이용자를 늘리고 서비스를 확장하는 단계라고 설명했습니다. 인턴의 업무에는 제품 분석, 개발팀과의 협업, A/B 테스트, 성장 전략 기획이 포함됐습니다. 시청·업로드·재방문을 늘리는 실험과 수익화 방안도 다뤘습니다. 팀 PM도 인턴이 작은 문제를 직접 확인하고 개선한 뒤 결과까지 살펴보기를 기대한다고 밝혔습니다.

이 업무에 맞춰 지원서에서 보여줄 것은 스토리의 이용 과정에서 문제 하나를 찾아, 무엇을 바꾸고 어떤 결과를 확인할지 설명하는 능력입니다. 아래는 공고의 방향을 실제 서비스 분석에 적용해볼 질문입니다. 팀이 지정한 과제나 당근에서 확인된 문제는 아닙니다.

살펴볼 이용 과정	직접 확인해볼 질문	관련 경험에서 보여줄 판단
동네 영상 시청	관심 있는 장소를 발견했을 때, 방문할지 결정하는 데 필요한 정보까지 얻을 수 있었나요?	사용자가 찾는 정보와 실제 화면의 차이를 발견한 경험
영상 촬영·편집·등록	영상을 올려보니 어느 단계에서 시간이 오래 걸렸거나 다시 시도해야 했나요?	참여를 막는 단계를 찾아 절차나 안내를 바꾼 경험
가게에 대한 관심과 재방문	시청 후 가게의 다른 정보를 찾아봤나요? 다음에 스토리를 다시 열 이유는 무엇이었나요?	한 번의 이용과 반복 이용을 구분해 원인과 결과를 살펴본 경험

큰 기능을 새로 제안할 필요는 없습니다. 장소 정보를 보여주는 순서나 등록 과정의 안내처럼 직접 관찰한 불편에 대응하는 작은 변경도 출발점이 됩니다. 다만 무엇을 바꾸든 동네 주민에게 유용한 정보가 늘어나는지, 영상을 올리는 사람에게 불필요한 부담을 주지는 않는지 함께 검토해야 합니다.

수익화 방안을 제안한다면 가게를 운영하는 분과 영상을 보는 주민 모두에게 어떤 변화가 생길지 생각해보세요. 예를 들어 가게 홍보 영상을 더 자주 노출하는 방안이라면, 주민이 유용한 정보를 얻을 수 있는지 살펴보세요. 비슷한 광고가 반복돼 시청을 중단하게 되지는 않을지도 확인해야 합니다.

이제 합격 서류에서 이런 판단을 어떻게 설명했는지 살펴보겠습니다. 숏폼 개발 경험이 아니어도 사용자의 목적을 파악하고, 그 목적에 맞춰 화면이나 요청 방식을 바꾼 경험은 참고할 수 있습니다.

실제 합격 자료에서 본 차이: 예약 내역을 왜 상단에 뒀을까요?

같은 버튼을 추가하더라도 어느 위치에 둬야 하는지 판단한 이유를 설명해보세요. 앞서 소개한 지원자분은 예약 내역을 찾는 경로를 개선하셨습니다. 기존에도 내역을 확인하는 기능은 있었지만, 예약 탭이 새로 생긴 뒤 사용자는 그 탭에서 이전 예약을 찾으려 했습니다. 내역은 여전히 다른 메뉴에 있어 찾기 어렵다는 문의가 나왔습니다.

이분은 예약 내역을 찾는 사용자가 어떤 목적으로 들어오는지에 주목하셨습니다.

예약 탭이 새로 생긴 뒤 예약 내역을 찾기 어렵다는 문의가 나왔습니다. 기존 메뉴에서 조회할 수는 있었지만, 사용자는 예약 탭 안에서 내역을 찾고 있었습니다. 이미 한 예약을 확인하려는 사람은 새 상품을 둘러보려는 사람과 목적이 다르다고 판단했습니다. 그래서 예약 내역을 확인하는 버튼을 상품 목록 아래에 두지 않고, 예약 탭 상단에 따로 배치하도록 설계했습니다. 개선 후에는 내역을 찾기 어렵다는 문의가 줄고, 새 버튼으로 내역을 확인하는 사람이 늘었다는 내부 피드백을 받았습니다.

지원자분께서 작성하신 자료를 바탕으로 재구성한 예문입니다.

이 문단에는 예약 내역을 볼 수는 있지만 찾는 위치가 달랐다는 문제, 탐색보다 확인이 목적인 사용자, 하단 목록에 섞지 않고 상단에 별도로 배치한 선택이 들어 있습니다. 결과도 직접 확인하지 못한 이용률 수치를 만들지 않고, 내부에서 전달받은 변화로 설명했습니다.

본인의 포트폴리오에서도 ‘정보 구조를 개선했다’는 문장을 찾아보세요. 어떤 정보를 어디에서 어디로 옮겼는지, 다른 위치도 가능한데 왜 그곳을 골랐는지 덧붙이면 판단이 보입니다. 화면 캡처에는 바뀐 위치를 표시하고, 본인이 설계한 범위와 다른 직군이 구현한 범위를 구분하면 좋습니다.

설문을 줄일 수 없을 때는 요청하는 시점을 바꿨습니다

예약 내역 사례에서는 사용자가 필요한 정보를 찾기 어려웠습니다. 이분의 다른 프로젝트에서는 반복되는 설문 요청 때문에 사용자가 서비스를 떠나는 문제가 생겼습니다. 개인별 활동을 추천하려면 사용자의 상태를 알아야 했지만, 반복되는 설문을 부담스럽게 느낀 것입니다.

설문을 줄이면 부담을 덜 수 있겠지만, 협업 기관이 정한 문항이라 내용을 줄이거나 바꿀 수 없었습니다. 이분은 문항을 유지하면서 요청 방식을 바꾸셨습니다.

설문을 반복해서 요청한 뒤 부담스럽다는 의견이 늘었고, 요청 후 서비스를 떠나는 사용자도 확인했습니다. 협업 기관이 정한 문항은 바꿀 수 없어, 설문을 짧게 만드는 대신 언제 요청할지를 조정했습니다. 앱에 머무는 시간, 활동을 끝낸 비율, 커뮤니티 반응을 살펴보고, 두 가지 이상의 지표가 정해둔 기준만큼 증가했을 때 설문을 보여주도록 조건을 정했습니다. 날짜가 되면 누구에게나 요청하던 방식에서, 이용 행동의 변화를 보고 요청하는 방식으로 바꾼 것입니다. 변경 후에는 주간 이탈이 줄고 설문 응답이 늘었습니다.

지원자분께서 작성하신 자료를 바탕으로 재구성한 예문입니다.

‘사용자 행동을 분석해 설문을 개선했다’고만 쓰면 어떤 행동을 보고 무엇을 달리했는지가 빠집니다. 이 사례에서는 바꿀 수 없는 문항을 먼저 확인했고, 앱 이용과 활동 참여의 변화를 설문 요청 조건으로 삼았습니다. 포트폴리오에도 바꿀 수 없었던 조건과 그 안에서 본인이 정한 기준을 함께 적어보세요.

숏폼 개선안을 준비할 때도 ‘업로드 안내를 늘리자’에서 멈추지 말고, 어느 사용자에게 언제 안내할지 생각해볼 수 있습니다. 시청 중인 사람에게 매번 요청할지, 직접 게시해보려는 행동이 나타났을 때 안내할지에 따라 이용 경험이 달라질 수 있기 때문입니다. 이는 직접 검토해볼 가설이며, 당근이 실제로 해당 안내를 운영한다는 뜻은 아닙니다.

‘신뢰와 충돌’은 의견이 달랐을 때의 행동으로 보여주세요

당근의 공식 문화 페이지는 제품을 기준으로 솔직하게 반론을 나누고, 결정 후에는 자신의 의견과 달라도 함께 실행하는 태도를 설명합니다. 또한 결정의 이유와 맥락을 공유하고, 작은 변경을 빠르게 검증하는 방식을 강조합니다. 당근이 일하는 방식

지원서에 ‘신뢰와 충돌에 공감합니다’라는 문장만 추가할 필요는 없습니다. 협업 경험에서 다음 네 가지를 찾아보세요.

1. 의견이 갈린 지점: 어떤 기능이나 우선순위를 두고 생각이 달랐나요? 동료는 무엇을 우려했나요?
2. 함께 본 근거: 사용자 의견, 이용 기록, 개발에 필요한 시간 중 무엇을 공유하며 논의했나요?
3. 판단이 바뀐 부분: 동료의 근거를 듣고 수정한 내용은 무엇인가요? 의견을 유지했다면 어떤 이유를 설명했나요?
4. 결정 이후의 실행: 합의한 안에서 본인이 맡은 일과, 결과를 확인해 팀에 공유한 내용은 무엇인가요?

숏폼에서는 업로드 수를 늘리고 싶은 목표와 시청 중인 사용자를 방해하지 않으려는 목표가 부딪힐 수 있습니다. 본인이 비슷한 의견 차이를 겪었다면, 누구의 의견이 채택됐는지에 더해 서로의 우려를 어떤 기준으로 검토했고, 결정 뒤 무엇을 실행했는지 설명해보세요. 실제로 없었던 갈등을 만들 필요는 없습니다.

앞의 합격 자료에도 개발팀과 문제를 공유한 과정이 있습니다. 필요한 로그나 ID 값이 들어오지 않았을 때, 지원자분은 문제가 생긴 화면과 이벤트, 기대한 동작, 실제 상황, 해결 방안을 순서대로 문서화하셨습니다. 담당 개발자와 해결 일정도 확인하셨습니다. 상대가 같은 문제를 이해하고 대응할 수 있도록 정보를 정리한 경험입니다.

이런 경험에 실제 의견 차이가 있었다면 그 논의 과정까지 쓰면 됩니다. 본인의 안을 수정했거나 다른 안으로 결정된 경험도 활용할 수 있습니다. 제품을 더 낫게 만들기 위해 근거를 검토하고, 결정된 일을 책임지고 실행한 태도가 드러나면 됩니다.

당근 스토리 사전 질문은 관찰과 추측을 나눠 쓰세요

분석한 공고의 사전 질문은 당근 스토리를 최소 3일 사용하고 한 번 이상 업로드한 뒤 개선점을 작성하는 것이었습니다. 단순한 서비스 소개나 타사 기능 목록으로는 직접 사용한 경험을 보여주기 어렵습니다.

1. 사용 기록에는 화면과 행동을 함께 적으세요

시청자로서 한 행동과 영상을 올릴 때 한 행동을 나눠 적어보세요. ‘사용하기 불편했다’고만 적으면 나중에 무엇을 고칠지 정하기 어렵습니다. 화면 캡처 옆에 하려던 일, 실제로 한 행동, 그 뒤의 결과를 적으면 개선안을 쓸 근거가 됩니다.

기록할 내용	사용 기록을 정리할 질문
이용 상황	동네 가게나 장소에 관해 무엇을 알고 싶어 스토리를 봤나요? 직접 올릴 때는 어떤 경험을 전하려 했나요?
실제 행동	시청 후 장소의 다른 정보를 찾아봤나요? 업로드할 때는 어느 단계에서 다시 시도했나요?
예상과 달랐던 점	기대했던 정보나 반응은 무엇이고, 실제로는 어땠나요?
이어진 결과	하려던 일을 마쳤나요, 이전 화면으로 돌아갔나요, 중단했나요?
아직 모르는 점	다른 사용자도 같은 어려움을 겪는지는 확인했나요?

서비스를 분석할 때 첫날에는 동네 영상을 보는 목적과 시청 후 한 행동을, 둘째 날에는 직접 영상을 올린 과정을 기록해볼 수 있습니다. 셋째 날에는 다시 스토리를 열게 된 계기와, 앞서 불편했던 작업을 재시도한 결과를 적어보세요. 새 채용에 지원한다면 해당 공고의 이용 조건과 일정을 따로 확인해야 합니다.

2. 개선안은 본인이 관찰한 근거가 있는 것부터 고르세요

사용 기록에서 개선할 점 두 개를 고른 뒤 비교해보세요. 각 문제에 대해 사용자가 하려던 일을 얼마나 방해하는지, 원인을 확인할 단서가 있는지, 작은 수정으로도 효과를 확인할 수 있는지 적습니다. 아직 모르는 부분은 사실처럼 쓰지 말고, 추가로 확인할 질문으로 적어두세요.

앞의 예약 내역 사례에서는 사용자가 찾는 위치와 실제 경로의 차이가 개선 이유였습니다. 설문 사례에서는 문항을 바꾸기 어려워 요청 시점을 조정했습니다. 본인의 개선안도 사용자가 겪은 불편과 실제로 바꿀 수 있는 부분을 함께 설명해야 합니다.

다른 앱에서 본 기능을 추가하고 싶다는 생각만 있다면, 그 기능이 해결할 불편부터 직접 확인해보세요. 새 기능이 필요하다고 판단하기 전에, 안내 문구나 버튼 위치만 바꿔도 불편을 줄일 수 있을지 검토하면 좋습니다.

3. 고른 개선안을 다섯 문장으로 정리해보세요

아래 대괄호 안을 본인의 실제 사용 기록으로 채워보세요. 정해진 제출 양식은 아니며, 생각을 정리한 뒤 지원 화면의 질문과 분량에 맞춰 다듬는 틀입니다.

[어떤 상황]에서 [하려던 행동]을 시도했지만, [직접 겪은 불편] 때문에 [그 뒤에 실제로 한 행동]을 했습니다. [추정하는 원인] 때문일 수 있어, [추가로 확인할 내용]을 살펴보려 합니다. 이 문제로 [동네 정보를 찾거나 영상을 올릴 때 겪는 어려움]이 생길 수 있다고 보아 우선 개선할 문제로 골랐습니다. 먼저 [제안하는 변경]으로 [줄이고 싶은 불편]을 줄일 수 있는지 확인해보고 싶습니다. 효과는 [비교할 행동이나 지표]로 확인하고, [늘어나면 안 되는 사용자 반응]도 함께 점검하겠습니다.

앞의 예약 내역 사례에 비춰 본인의 초안을 읽어보세요. ‘사용자가 불편하다’에는 어느 화면에서 무엇을 찾지 못했는지, ‘접근성을 높인다’에는 무엇을 어디에 배치할지가 더 필요합니다. ‘성과를 확인한다’에는 문의의 변화나 사용자가 하려던 일을 마쳤는지처럼 무엇을 확인할지가 들어가야 합니다.

서비스를 직접 써본 경험만 있다면 회사 내부의 문의나 이용 데이터를 아는 것처럼 쓰지 않아도 됩니다. 본인이 어느 화면에서 멈췄고 어떤 정보를 찾았는지부터 적은 뒤, 다른 사용자도 같은 어려움을 겪는지는 확인할 질문으로 구분하세요. 한 사람이 겪은 불편을 모든 사용자의 문제로 단정하지 않는 것이 중요합니다.

지표가 개선됐어도 무엇을 비교했는지 설명해야 합니다

수치를 읽고 다음 결정을 내린 과정까지 보여주세요. 앞의 설문 사례처럼 변경 후 이탈이 줄었다면 성과로 설명할 수 있습니다. 다만 그 기간에 새로 들어온 사용자의 특성이 달라졌는지, 다른 개선도 함께 적용했는지 확인해야 합니다. 전후 수치가 달라졌다는 사실만으로 한 기능의 효과를 분리해 증명한 것은 아닙니다.

당근의 공식 실험 문화 글도 전후 비교의 한계와 함께, 주요 지표 외에 사용자 경험을 해치지 않았는지 확인하는 지표를 설명합니다. 실험 결과가 좋지 않으면 배포하지 않는 결정도 다룹니다. 당근의 실험 문화

지원서에는 본인이 실제로 데이터를 확인한 방법과 해석한 내용을 쓰면 됩니다. 서로 다른 안을 비교했다면 대상과 기간, 성공 기준을 설명하고, 단순 전후 비교였다면 그 범위를 정확히 적습니다. 데이터를 직접 추출하지 않았다면 SQL로 분석했다고 쓰지 말고, 전달받은 자료에서 본인이 무엇을 해석했는지 보여주세요.

예를 들어 지역 정보를 더 쉽게 찾도록 화면을 바꾸자는 제안이라면, 시청시간뿐 아니라 관심 있는 장소의 정보를 확인하는 행동이 늘었는지도 검토할 수 있습니다. 업로드 안내를 바꾸자는 제안이라면 등록을 마친 비율과 함께, 안내 때문에 시청을 중단하는 사람이 늘지 않았는지 살펴볼 수 있습니다. 이는 검증할 지표의 예시입니다. 실제 행동을 측정할 수 있는지부터 확인하고, 그 결과에 따라 무엇을 유지하거나 수정할지 설명하세요.

당근 PM 지원서와 포트폴리오 제출 전 확인할 것

• 개선안이 동네 정보를 발견하거나 영상을 공유하는 데 어떤 도움이 되는지 설명했나요?
• 프로젝트마다 사용자가 겪은 문제를 한 문장으로 설명할 수 있나요?
• 사용자를 관찰한 사실과 본인의 추측을 구분했나요?
• 여러 개선안 중 그 방법을 먼저 선택한 이유가 있나요?
• 협업 중 다른 의견의 근거를 검토한 과정과, 결정 후 본인이 실행한 일을 적었나요?
• 직접 설계한 일과 다른 직군이 구현한 일을 구분했나요?
• 제안만 한 기능을 실제 출시한 기능처럼 쓰지 않았나요?
• 지표의 측정 기준과 비교 조건을 설명할 수 있나요?
• 지원 공고의 서비스 이용 조건과 제출 형식, 마감일을 확인했나요?

포트폴리오를 읽고도 본인이 어떤 결정을 내렸는지 알기 어렵다면 페이지를 더 늘리기 전에 프로젝트 한 개를 고쳐보세요. 예약 내역 사례처럼 사용자가 하려던 행동을 설명하고, 막힌 이유와 본인의 선택을 이어 쓰는 것부터 시작하면 됩니다. 이력서의 경력을 구체적으로 설명하는 방법과 수치 없이 행동을 보여주는 방법도 함께 참고할 수 있습니다.

프로젝트가 여러 개라 어떤 경험을 먼저 보여줄지 정하기 어렵다면 지원 직무에 맞춰 이력서 경험을 정리하는 방법에서 함께 검토할 수 있습니다.