1. 서론: 10배 엔지니어 신화의 한계

• 핵심 메시지:
  아무리 빠른 로켓이라도 방향이 틀리면 목표에 도달할 수 없습니다. 제품 개발도 마찬가지예요.
  "로켓이 잘못된 방향을 향하면 아무리 빨라도 목표를 놓치게 됩니다. 제품도, 그 뒤의 팀도 마찬가지입니다."

• 10배 엔지니어란 엄청난 기술력으로 이상화되지만, 잘못된 문제에 집중하면 제품 성공 확률이 10배가 되지 않습니다.

• PostHog에서는 엔지니어가 제품의 방향을 결정합니다.
  "우리는 엔지니어가 로드맵과 목표를 직접 정하고, 이를 끝까지 책임지는 구조입니다."

2. 이번 주제: PostHog이 찾는 제품 엔지니어의 조건

2-1. 빠른 실행과 반복(Iterate) 문화

• 계획만 세우고 다듬기만 하는 것보다, 일단 출시하고 개선하는 걸 선호합니다.
• 엔지니어는 다음에 익숙해야 해요:
  • MVP(최소 기능 제품)와 프로토타입 만들기
  • 준비가 덜 됐더라도 먼저 출시하기
  • 사용자 피드백 받고 문제 해결하기
  • 안 되는 기능은 과감히 버리거나 방향 전환하기

"기능을 완벽하게 다듬기보다, 일단 출시하고 반복적으로 개선하는 것이 더 중요합니다."

• 즉, 제품을 0에서 완성까지 이끌 수 있는 전방위적 역량(인프라, 확장성, 사용성, 디자인 등)이 필요합니다.
• PostHog은 기본적으로 PM(제품 관리자)이나 디자이너가 따로 없기 때문에 엔지니어가 자율적으로 모든 걸 해내야 해요.

실제 사례: Robbie Coomber의 웹 분석 도구

• 처음 버전은 매우 단순했지만,
  "그는 이후 올바른 시각화, 스크롤 깊이 자동 캡처, 사용자 피드백 반영, 쿼리 성능 최적화, 샘플링 테스트 등 다양한 개선을 해냈습니다."

"처음엔 정말 단순했지만, 지금은 베타 단계까지 오기 위해 스택 전반의 역량이 필요했습니다."

• 중요 키워드:
  MVP, 빠른 출시, 사용자 피드백, 전방위 역량, 자율성

2-2. 글쓰기와 비동기 커뮤니케이션 능력

• PostHog은 원격·비동기 회사라서, 대부분의 소통이 글로 이루어집니다.
• 글쓰기의 중요성:
  • 새로운 기능 전 이슈 작성 및 이후 문서화
  • PR(풀 리퀘스트) 설명과 리뷰 코멘트
  • RFC(의견 요청 문서)로 큰 결정 논의
  • 핸드북에 프로세스 기록

"좋은 글쓰기는 명확한 사고를 보여주고, 중요한 내용을 기록하며, 회의를 줄이고, 빠른 속도를 유지하게 해줍니다."

실제 사례: Team Pipeline의 RFC

• Ted는 여러 팀이 관여하는 복잡한 이슈(이벤트 분할, 데이터 품질 개선 등)를 위해
  1,500자 이상의 RFC 2개와 2,000자 이상의 코멘트로 논의를 이끌었습니다.

"이런 복잡한 결정을 내릴 때, 글로 명확하게 소통할 수 있는 사람이 필요합니다."

• 중요 키워드:
  비동기, 글쓰기, 문서화, RFC, 명확한 커뮤니케이션

2-3. 일에 대한 동기: 돈 vs. 미션

• 엔지니어는 크게 두 부류:

  1. 돈을 위해 일하는 사람
  2. 일 자체와 미션에 열정이 있는 사람

• PostHog은 두 번째 유형을 선호합니다.

  • "우리는 운전자를 원하지, 승객을 원하지 않습니다. 스스로 아이디어를 내고 끝까지 실행하는 사람을 찾습니다."
  • "우리의 여정에 동참할 사람, 기회를 잡고자 하는 사람을 원합니다."

• 중요 키워드:
  주도성, 미션 중심, 자기 동기, 사이드 프로젝트, 오픈소스 기여

2-4. 사용자 집착과 문제 발견 능력

• 제품 엔지니어는 일반 엔지니어보다 훨씬 자주 사용자와 소통합니다.
  • 사용자 인터뷰
  • 테스터 모집 및 피드백 수집
  • 고객 지원 및 이슈 대응

실제 사례: Eric의 데이터 웨어하우스

• Eric은 기능 수나 사용량이 아니라 5명의 레퍼런스 고객 확보를 목표로 삼았습니다.

• "그는 잠재 고객을 직접 찾아가 요구사항을 파악하고, 설문조사로 초기 커넥터(Stripe, Hubspot, Postgres)를 선정했습니다."

• 반대 사례:

  • "정답에 집착하거나, 기존 방식만 고수하는 태도는 지양합니다. 연구와 계획만 하다 출시를 미루는 것도 마찬가지입니다."

"고객 집착은 우리가 진짜 사람들이 원하는 제품을 만들게 해줍니다."

• 중요 키워드:
  사용자 인터뷰, 고객 집착, 문제 발견, 빠른 반복

2-5. 큰 그림을 보는 능력과 데이터 기반 의사결정

• 팀은 자율적으로 로드맵, 목표, 구현 방식을 결정합니다.
• 최선의 결정을 위해 필요한 역량:
  • 피드백, 사용 데이터, 벤치마크 분석
  • 경쟁사 분석(기능, 가격 등)
  • 성공 측정 지표 선정
  • 인프라와 확장성 이해

실제 사례: Manoel과 Paul의 모바일 리플레이

• 경쟁사와 피드백을 조사하고,
  클라이언트 라이프사이클, API 요청, 데이터 구조, rrweb 호환성 등을 포함한 상세 스펙을 작성했습니다.

"큰 그림을 볼 수 있어야 장기적으로 더 나은 결정을 내릴 수 있습니다. 너무 좁게 보면 기회를 놓치거나, 장기적으로 문제가 생길 수 있습니다."

• 중요 키워드:
  데이터 기반, 경쟁사 분석, 전체 시스템 이해, 장기적 시야

2-6. 함께 일하기 쉬운 태도와 긍정적인 에너지

• PostHog은 자율성이 크고, 팀원 간 피드백이 많아
  "일하기 쉬운 사람"이 중요합니다.
• 반대:
  • 자기 PR만 하고, 1년마다 이직하며 이력서만 채우는 사람은 지양합니다.

실제 사례: PR 중심의 협업

• "다른 회사는 일을 남에게 떠넘기지만, 우리는 스스로 해결하고 PR을 올립니다. 틀려도 괜찮아요. PR을 수정하는 게 처음부터 만드는 것보다 훨씬 쉽거든요."

"함께 일하기 어려운 사람은 긴장과 갈등을 만들고, 전체에 큰 악영향을 줄 수 있습니다."

• 중요 키워드:
  협업, 긍정적, 자기주도, 팀워크, 피드백 수용

3. 이런 엔지니어를 찾는 이유와 결과

• 찾기 어렵지만, 가치가 있습니다.

  • "작고 자율적인 팀으로 속도를 최적화할 수 있습니다."
  • "최소한의 계층과 관리로, 모두가 최고의 일에 집중할 수 있습니다."
  • "작년 4배 성장, 신규 인원은 단 3명 추가"

• "우리는 재능이 복리로 성장한다고 믿습니다. 최고의 기술력과 위의 특성을 모두 갖춘 사람을 찾는 게 더 힘들지만, 그만한 가치가 있습니다."

4. 참고할 만한 글

• Andrew Bosworth(페이스북 CTO)의 내가 중요하게 생각하는 특성들:
  소유권, 실행 편향, 확장성 등 PostHog과 겹치는 부분이 많아요.

• Abi Noda의 뛰어난 소프트웨어 엔지니어의 차이점:
  단순히 코딩을 잘하는 것 이상으로, 현재의 가치를 극대화하고, 좋은 결정을 내리며, 지속적으로 배우는 것이 중요하다고 강조합니다.

• Charles Cook의 스타트업 채용 담당자가 실제로 보는 것:
  PostHog에 1년간 9,000명이 지원했고, 어떻게 평가하는지, 차별화 포인트는 무엇인지 설명합니다.

5. 마무리

• PostHog이 찾는 엔지니어는 단순히 '10배 엔지니어'가 아니라,
  • 빠른 실행과 반복,
  • 글쓰기와 커뮤니케이션,
  • 미션에 대한 열정,
  • 사용자 집착,
  • 큰 그림을 보는 시야,
  • 함께 일하기 쉬운 태도
    이 모든 것을 갖춘 사람입니다.

"우리의 문화와 성장 자체가, 이런 사람을 찾는 것이 가치 있다는 증거입니다."

정리: Ian Vanagas(글쓰기를 정말 좋아하는 사람) ✍️