[당근] Software Engineer, Frontend - 로컬 잡스 (레슨/과외 팀) 공고 분석

이 자리가 왜 생겼을까요

1하게 될 업무

• 당근 레슨/과외의 홈·탐색·선생님 프로필·수업 콘텐츠 등 주요 화면의 프론트엔드를 개발합니다.

  이렇게 볼 수 있어요

  선생님을 찾고 비교하는 화면이 업무 목록 첫 항목입니다. 목록과 상세, 프로필처럼 탐색과 비교가 이어지는 화면을 만들어 본 경험이 있다면 맡은 화면 수와 이용 규모를 함께 적을 수 있습니다.

• 당근의 커뮤니티, 모임, 홈피드 등 여러 서비스와 연결되는 진입 경험을 만듭니다.

  이렇게 볼 수 있어요

  팀이 만들고 싶은 경험에 '아직 배울 마음이 뚜렷하지 않은 사람에게 배움의 계기를 만들어주는 경험'이 있고, 당근 모임은 2026년 7월 월간 이용자 1천만 명을 넘었습니다. 다른 서비스의 이용자를 자기 서비스로 데려오는 진입점을 만들고 유입 전환을 재 본 경험이 있다면 이 업무와 바로 이어집니다.

• 지표를 직접 열어 보고, PRD를 쓰고, 유저를 만나는 것을 이 팀 엔지니어의 일하는 방식으로 적었습니다.

  이렇게 볼 수 있어요

  공고의 '팀 동료들의 한마디' 절도 이 팀을 개발자가 지표를 보고 PRD를 작성하고 유저 인터뷰를 하는 것이 당연한 팀으로 소개합니다. 개발자로서 직접 쓴 기획 문서나 참여한 사용자 인터뷰가 있다면 그 결과로 바꾼 화면이나 기능까지 이어서 쓰면 됩니다.

• PM, Designer, Data 파트너와 함께 문제 정의부터 출시, 성과 분석까지 주도적으로 참여합니다.

  이렇게 볼 수 있어요

  같은 팀 Product Designer 공고도 「PM, Engineer, Data 파트너와 함께 문제 정의부터 출시, 성과 분석까지」를 업무로 적었습니다. 이 팀은 직군과 상관없이 같은 범위를 함께 맡습니다. 출시 뒤 지표를 확인하고 후속 작업을 제안한 사례라면 문제 정의, 출시, 분석의 단계마다 엔지니어로서 직접 한 일을 PM·디자이너가 맡은 일과 나눠 말할 수 있어야 합니다.

• 가설을 실험으로 검증하고, 탐색 → 문의 → 수업으로 이어지는 전환 퍼널을 개선해 제품 성장을 만들어 갑니다.

  이렇게 볼 수 있어요

  같은 회사 부동산 Product Designer 공고의 퍼널은 탐색에서 비교를 거쳐 문의에서 끝나지만 이 팀의 퍼널은 문의 뒤 실제 수업까지 갑니다. 문의에서 수업으로 넘어가는 단계는 선생님의 응답처럼 공급자 쪽 행동에 달려 있습니다. 그래서 이 단계의 전환은 우대 사항의 공급·수요 양쪽 설계와 함께 움직입니다. 전환율을 올린 실험이 있다면 어느 단계에서 무엇을 바꿨고 수치가 얼마나 움직였는지를 한 사례로 묶어 주세요.

• 코딩 에이전트가 잘 일할 수 있는 코드베이스와 워크플로우를 만들고, 팀의 일하는 방식으로 정착시킵니다.

  이렇게 볼 수 있어요

  개인이 에이전트를 쓰는 데서 그치지 않고 팀의 방식으로 자리 잡게 하는 일까지 업무에 있습니다. 저장소 규칙이나 문서를 정비해 동료들도 같은 방식으로 에이전트를 쓰게 만든 경험이 있다면 그 과정을 이야기할 수 있습니다.

2자격 요건

• React와 TypeScript로 실제 사용자가 쓰는 제품을 3년 이상 만들고 운영해 본 경험을 요구합니다.

  이렇게 볼 수 있어요

  같은 로컬 잡스 프론트엔드 공고가 React 3년 「또는 그에 준하는 역량」을 적은 것과 달리 이 공고는 TypeScript와 운영을 더하고 준하는 역량 단서를 두지 않았습니다. 운영은 업무의 출시 뒤 성과 분석과 퍼널 개선으로 이어지는 일입니다. 출시한 뒤에도 그 제품을 맡아 고쳐 온 기간이 있다면 운영 경험까지 경력에 드러나도록 쓰는 것이 좋습니다.

• 복잡한 비즈니스 요구사항을 빠르게 이해하고 구현하기 위한 적절한 기술적 의사결정을 하는 사람을 찾습니다.

  이렇게 볼 수 있어요

  우대 사항이 꼽은 공급·수요 양쪽 마켓플레이스와 결제·구독은 화면마다 상태와 예외 규칙이 많은 영역입니다. 선생님과 학생처럼 양쪽 이용자가 같은 문의를 서로 다른 화면에서 보는 구조라면 상태를 어떻게 모델링하느냐가 구현 속도를 좌우합니다. 규칙이 많은 기능을 맡아 구조를 정한 사례라면 상태와 예외를 TypeScript 타입으로 어떻게 표현했는지와 왜 그 방식을 골랐는지 설명할 준비가 필요합니다.

• 스스로 문제를 찾아 정의하고 해결까지 밀고 나가 본 경험을 요구합니다.

  이렇게 볼 수 있어요

  이 팀은 엔지니어가 지표를 직접 열어 보고 유저를 만나는 것을 일하는 방식으로 소개합니다. 문제를 찾는 출발점도 지표와 유저입니다. 당근 인재상 유저 임팩트의 예문도 「사용자 로그를 직접 들여다보고, 말하지 않는 불편까지 찾아요」입니다. 누가 맡기지 않은 문제를 지표나 로그에서 발견한 계기와 해결 뒤 달라진 지표를 한 사례 안에 함께 담아 보세요.

• 맡은 자리에서 동료가 믿을 수 있는 결과를 먼저 만들고, 필요할 때 그 범위를 넓혀 본 사람을 찾습니다.

  이렇게 볼 수 있어요

  업무에는 레슨/과외 화면 말고도 커뮤니티, 모임, 홈피드에서 들어오는 진입 경험이 포함됩니다. 넓히는 범위가 다른 서비스의 지면까지 갑니다. 당근 채용 페이지도 직무 경계를 「누가 하던 일인지보다 어떻게 빠르게 풀 수 있는지가 중요합니다」라고 설명했습니다. 담당 화면을 안정시킨 뒤 인접한 영역까지 맡게 된 과정이 있다면 안정시킨 방법과 넓힌 범위를 나눠 적으세요.

• 정답이 정해지지 않은 문제에서 첫 구조를 잡고 기술적 의사결정을 주도해 본 경험을 요구합니다.

  이렇게 볼 수 있어요

  업무에는 코딩 에이전트가 잘 일할 수 있는 코드베이스를 만드는 일도 포함됩니다. 처음 잡는 구조는 사람뿐 아니라 에이전트가 따라 쓰는 패턴으로 남습니다. 새 기능이나 새 서비스의 초기 구조를 정한 경험이 여기에 맞습니다. 처음 정한 구조가 이후 요구 변화를 어떻게 받아들였는지까지 말할 수 있으면 의사결정의 근거가 분명해집니다.

• 데이터를 바탕으로 가설을 세우고 실험과 개선을 주도해 본 경험을 요구합니다.

  이렇게 볼 수 있어요

  탐색 → 문의 → 수업으로 이어지는 전환 퍼널을 실험으로 개선하는 것이 이 팀의 주요 업무입니다. 실험 설계와 결과 해석 가운데 직접 맡은 부분을 나눠 적습니다.

• 사용자 경험과 비즈니스 임팩트를 함께 고민하고, 제품 완성도에 높은 기준을 가진 사람을 찾습니다.

  이렇게 볼 수 있어요

  같은 팀 Product Designer 공고는 디자인 시스템과 제품 품질 기준을 업무로 적었습니다. 이 요건의 완성도 기준도 그쪽과 함께 가는 것으로 보입니다. 당근의 디자인 시스템 SEED는 iOS, Android, Web에서 일관되게 동작하도록 토큰과 컴포넌트를 설계합니다. 사업 쪽 기준은 업무의 전환 퍼널 개선입니다. 사용성 개선이 문의나 결제 같은 전환으로 이어진 사례가 있다면 개선 내용과 전환 수치를 나란히 적는 편이 낫습니다.

3우대 사항

• 0 to 1을 만드는 초기 제품이나 창업을 경험해 본 사람을 우대합니다.

  이렇게 볼 수 있어요

  공고의 '팀 동료들의 한마디' 절은 큰 회사의 안정감보다 작은 시장을 0에서 키우는 일에 더 끌리는 사람과 함께하고 싶다고 적었습니다. 처음부터 만든 제품이 있다면 첫 출시까지의 기간과 첫 사용자 규모를 밝힐 수 있습니다.

• 공급과 수요 양쪽을 함께 설계하는 마켓플레이스, 그리고 결제·구독처럼 사용자가 직접 비용을 지불하는 제품을 만들어 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  공고가 이 팀에서 할 수 있다고 소개한 경험에도 문의부터 일정 조율, 결제까지 끊기지 않고 이어지는 흐름이 있습니다. 양쪽 이용자를 함께 다뤘거나 결제 화면을 맡은 적이 있다면 두 경험을 각각 드러낼 수 있습니다.

• GraphQL 클라이언트(Relay, Apollo, urql 등)로 제품을 만들어 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  같은 로컬 잡스 프론트엔드 공고도 Relay, Apollo, urql을 그대로 우대합니다. 부동산 백엔드 공고는 GraphQL 활용 경험을 우대합니다. 세 클라이언트는 캐시 방식이 다릅니다. Relay는 컴포넌트마다 fragment로 필요한 데이터를 선언하고 Apollo는 정규화 캐시를, urql은 기본으로 문서 단위 캐시를 씁니다. 써 본 클라이언트가 있다면 이름과 함께 캐시나 데이터 요청을 어떻게 다뤘는지 설명할 수 있으면 좋습니다.

• 인앱 웹뷰 환경(권한, 버전 호환, 네이티브 연동)을 다뤄 보거나 브릿지를 직접 설계해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  웹뷰 안의 권한과 버전 호환, 네이티브 연동이 괄호에 구체적으로 나옵니다. 앱 버전마다 다른 동작을 맞춰 본 경험이나 브릿지 인터페이스를 정한 경험이 이 항목의 사례입니다.

• 프론트엔드에 머무르지 않고 서버, 데이터, 운영 도구까지 손을 뻗어 제품을 완성해 본 경험과, A/B 테스트를 설계하고 분석 결과를 근거로 프로덕트를 개선해 본 경험을 우대합니다.

  이렇게 볼 수 있어요

  당근 데이터 가치화팀이 2026년 8월 기술 블로그에 쓴 글에 따르면 사내 실험플랫폼에서 월 290여 개 실험이 진행되고 각 팀이 직접 지표를 만들게 됐습니다. 그래서 이 우대의 A/B 테스트는 프론트엔드 엔지니어가 실험을 직접 설계하고 지표를 정하는 일까지 갈 수 있습니다. 직접 만든 서버 API나 운영 도구, 결과를 근거로 고친 A/B 테스트가 있다면 각각 무엇을 맡았는지 나눠 적으면 두 우대 사항에 함께 답합니다.

• 먼저 의견을 제시하고 주도적으로 일하기를 즐기는 사람을 우대합니다.

  이렇게 볼 수 있어요

  같은 팀 Product Designer 공고는 이 문장을 자격 요건으로 둡니다. 레슨/과외 팀은 직군과 상관없이 이 태도를 바랍니다. 당근 인재상의 '신뢰와 충돌'은 필요한 충돌을 피하지 않되 결정이 나면 자기 의견과 달라도 한 방향으로 실행한다는 항목입니다. 회의에서 먼저 낸 제안이 실제 작업으로 이어진 사례가 이 우대에 대한 답이 됩니다. 제안이 받아들여지지 않았을 때 어떻게 실행했는지도 면접에서 이야기할 거리입니다.

4기타 사항

• 게시일 : 2026년 9월 21일
• 고용형태 : 정규직(수습 3개월)
• 근무지 : 서울특별시 서초구 강남대로 465, 교보강남타워 11층 (추정)
• 경력 조건 : 경력 3년 이상
• 학력 조건 : 해당 내용은 원본 공고에서 확인되지 않습니다.

쓰는 기술

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

• React
• TypeScript
• GraphQL
• Relay
• Apollo
• urql

전형과 지원

채용 FAQ가 밝힌 정규직 기준 일반적인 전형은 여섯 단계이고 단계마다 결과 통보에 걸리는 기간까지 공개돼 있습니다. 포지션에 따라 절차가 달라 공고마다 확인해야 합니다. 재지원 규칙이 단계마다 달라서 지원 순서를 정할 때 먼저 볼 부분입니다.

지원 전 준비할 것

1. 1

   지표와 PRD를 다룬 개발 경험 모으기

   공고는 이 팀 엔지니어가 지표를 직접 보고 PRD를 쓰고 유저를 만난다고 적었습니다. 개발자로서 직접 쓴 문서나 참여한 사용자 인터뷰, 그 뒤 바꾼 화면을 한 묶음으로 준비해 둡니다.

2. 2

   전환 실험 한 건의 전후 수치 준비하기

   탐색 → 문의 → 수업 퍼널 개선이 업무에 있습니다. 직접 설계했거나 구현한 실험 하나를 골라 가설, 바꾼 화면, 전후 전환율을 정리합니다.

3. 3

   레슨/과외 서비스 직접 써 보기

   공고가 이 팀에서 할 수 있다고 소개한 일에는 동네 선생님을 탐색하고 고르는 과정, 문의부터 일정 조율과 결제까지 이어지는 흐름, 처음 만나는 순간까지 안심할 수 있는 신뢰 경험이 있습니다. 당근 앱에서 서비스를 써 보며 단계마다 고치고 싶은 점을 메모해 두면 직무 면접에서 꺼낼 이야기가 됩니다.

4. 4

   컬처핏 면접 사례 미리 고르기

   전형은 서류 전형, 화상 면접, 직무 면접, 컬처핏 면접 및 레퍼런스 체크, 최종 합격 및 입사 순입니다. 당근 채용 FAQ에 따르면 컬처핏 단계 이후에는 모든 공고에 1년간 지원할 수 없으므로 인재상 다섯 가지 각각에 맞는 경험을 미리 골라 두세요.