콘텐츠로 건너뛰기
  • 영향력 없는 PM

    비싼 무용지물 최근 다양한 제품 리더십 역할로 인터뷰를 다녀온 저는 PM에 대한 분위기가 얼마나 많이 변했는지 흥미롭게 느꼈습니다. CxO급 임원이나 이사회 같은 경영진은 PM에게 가장 전략적인 질문에 답변하길 기대하고, 반면 디자인(Design), 엔지니어링(Engineering), 데이터(Data Science) 같은 EPD나 GTM(Go-To-Market) 팀들은 PM이 모든 디테일을 챙기길 원하는 긴장 관계는 항상 있었죠. 하지만 지난 수십 년간 PM 역할은 대체로 가치…

  • 우선순위를 정할 때 쉽게 빠지는 10가지 함정

    요즘 우선순위에 대해 이런저런 생각을 많이 하고 있습니다. 매 초마다 우선순위를 결정해야 하는 느낌의 스타트업에서 일하다 보니, 하루 안에 쓸 수 있는 시간은 턱없이 부족한데 “이건 해야지”와 “이건 반드시 해야 해” 목록은 끝도 없이 늘어나죠. 그래서 스스로에게 계속 상기시키려는 게 하나 있습니다. 지금 중요한 건 완벽한 결정을 내리는 게 아니라, 우리를 앞으로 조금이라도 더 나아가게…

  • 직접 만들지 않는 소프트웨어는 설계할 수 없다

    대형 소프트웨어 시스템을 실제로 작업하는 엔지니어만이 설계 과정에 의미 있게 참여할 수 있다. 그 이유는 시스템의 구체적인 세부 사항을 깊이 이해하지 않고는 제대로 된 소프트웨어 설계를 할 수 없기 때문이다. 즉, 대부분의 실무적인 소프트웨어 설계 문제에서 일반적인 소프트웨어 설계 조언(generic software design advice)은 보통 쓸모가 없다. 일반적인 소프트웨어 설계(Generic software design) 일반적인 소프트웨어 설계란 무엇인가?…

  • 소프트웨어 제품이 실제로 어떻게 돌아가는지는 아무도 모른다

    빠르게 성장하고 움직이는 대형 테크 회사들은, 자기들이 만든 시스템에 대해서조차 늘 일종의 “전쟁터의 안개(fog of war)” 속에서 일하고 있다. “Y 타입 유저가 기능 X를 쓸 수 있나?”, “이 상황에서 액션 Z를 하면 정확히 어떤 일이 벌어지지?”, “우리는 지금 요금제가 몇 가지나 있지?” 같은 아주 단순해 보이는 질문조차, 조직 안에서 겨우 몇 명만 제대로 답을 할…

  • 당신의 제품 아이디어는 대부분 구리다. 그래도 괜찮다

    제품 아이디어 검증 간단 가이드 새로운 제품 아이디어가 떠올랐고, 정말 정말 좋다고 생각한다. 바로 개발에 착수하고 싶어진다. “사람들이 이걸 완전 사랑할 거야!” 이건 함정이다. 많은 창업자들이 처음부터 아주 간단한 걸 확인하지 않아서, 주, 개월(혹은 심지어 몇 년?!)을 쏟아부어 사람들이 원하지 않는 걸 만드는 걸 뼈저리게 배운다. 그들의 아이디어를 검증하는 거다. 이 분야에 대해 우리는 좀…

  • AI 시대의 리텐션, 첫 유저가 가장 핵심 유저다

    AI 시대의 리텐션 규칙 MVP, 이탈, 그리고 옛날 SaaS 전략 전통적인 SaaS에서는 초기 리텐션이 보통 고된 여정이다. 흔한 전략은 기능이 빈약한 MVP를 먼저 출시한 뒤, 유저들이 붙잡아 주길 바라면서 이를 보강하느라 정신없는 작업을 하는 거다. 초기에는 반복적인 개선(iterations)이 예상되기까지 하고, 오히려 장려되기도 한다. 창업자들은 반복 개선이 탈주한 유저들을 되돌리거나 적어도 새는 통(leaky bucket)을 늦추길 빌며…

  • 공개적으로 프로덕트를 만드는 게 두려워도 해야 한다

    BIP(Building in Public) 가 AI 시대의 답이다 대부분의 회사들은 아직도 2012년처럼 운영한다. 모든 걸 숨기고, 조용히 개발하며, 한 번의 화려한 런칭에 모든 걸 쏟아붓는다. 터무니없는 돈을 쓰고 지속적인 효과를 기대하지만, 며칠 만에 다 사라지고 다음 ‘런칭’을 초조하게 기다리기 시작한다. 이런 일이 벌어지는 이유는 회사 리더들이 마케팅 영감을 잘못된 곳에서 찾기 때문이다. 그들은 할리우드가 되고 싶어한다.…

  • 훌륭한 PM은 팀이나 로드맵을 통제하지 않고, 훌륭한 엔지니어는 지시가 필요 없다

    PM과 엔지니어 관계를 어떻게 재정의했는지​ 2020년 Tim과 PostHog를 처음 시작할 때, 나는 절대 제품 관리자(PM)를 뽑지 않겠다고 완강히 주장했다. 엔지니어들이 어려운 제품 문제를 직접 고민하고 풀어내길 바랐다. PM들은 오히려 방해만 될 거라 믿었기 때문이다.​ 4년이 지난 지금, (부분적으로) 내가 틀렸음을 인정한다. PM이 필요하다. 실제로 그들 없이는 8개 이상의 제품을 출시하거나 수익 목표를 달성할 수 없었을…

  • 성공적인 제품을 만들며 배운 50가지 교훈

    PostHog에서 얻은 교훈들 Product for Engineers 뉴스레터의 5만 구독자 달성을 기념해, 성공적인 제품을 만드는 데 배운 50가지 가장 중요한 교훈을 소개한다. 원문: 50 things we’ve learned about building successful products

  • 31개 SaaS의 GEN AI 기능 가격 책정 사례

    오늘날 시장에서 경쟁력을 갖추기 위해 최고의 SaaS 기업들이 가격 전략을 어떻게 업데이트하고 있는지. 지난 봄, a16z Growth(Andreessen Horowitz 그로스 팀)의 동료들과 함께 B2B나 prosumer 제품의 생성형 AI(gen AI) 기능에 대한 가격 책정과 패키징 프레임워크를 발표했습니다. 원문에서 언급한 SaaS 기업들이 지난 약 20개월 동안 가격과 패키징을 어떻게 변경했는지 확인해 보았습니다. 주요 인사이트 몇 가지: 처음에는 프리미엄…

  • 시장 자체가 없는 상황에서 B2B 제품이 살아남는 법

    새로운 카테고리를 만들 때 제품 가격을 정하고 판매하는 방법 앞서 말하지만, 이 가이드는 기본적인 영업 전술이나 막무가내 접근에 관한 게 아니다. 비즈니스 교과서도 아니다. 이건 1) 기술 창업자로서 새로운 시장 카테고리를 창조하는 상황에서 배운 교훈, 그리고 2) 다시 돌아간다면 완전히 다르게 했을 점에 관한 이야기다. 내가 말하는 ‘시장 카테고리 창조’란, Nicira를 시작할 때처럼 개념 자체가…

  • 소프트웨어 엔지니어링에서 ‘좋은 취향’이란 무엇일까?

    기술적 취향은 단순한 기술 능력과는 다릅니다. 기술적으로 뛰어나면서도 취향이 좋지 않을 수 있고, 반대로 기술은 부족하지만 좋은 취향을 가질 수도 있습니다. 일상에서 맛을 구분하는 것처럼, 기술적 취향도 능력이 따라주기 전에 먼저 생겨날 때가 있습니다. 예를 들어 요리를 할 줄 몰라도 맛있는 음식과 그렇지 않은 음식을 구분할 수 있듯이, 만들어본 경험이 없더라도 어떤 소프트웨어를 좋아하는지는 알…

  • 러버블에서 보낸 6개월, 기존의 성장 공식을 완전히 버린 이유

    러버블(Lovable)에서 일한 지 6개월이 됐다. 그런데 실제로는 6년쯤 지난 것 같은 느낌이다. 물론 좋은 의미다. 이렇게 가파른 학습 곡선은, 커리어 초반에 한창 성장하던 때 이후로 처음인 것 같다. 여기서 일의 속도가 미친 듯이 빠른 데엔 두 가지 이유가 있다. 하나는 LLM(대형 언어 모델, Large Language Model) 기술이 제품 로드맵 주기를 끝내기도 전에 더 발전해버린다는 점,…

  • 기술적인 글을 잘 쓰려면 기대치를 낮춰야 합니다

    기술 글쓰기는 소프트웨어 엔지니어 업무의 중요한 부분이며, 경력이 쌓일수록 그 중요성은 더욱 커집니다. 예를 들어, 수석이나 저명한 엔지니어는 오로지 기술 문서만 작성하기도 하지만, 신입 엔지니어라도 커밋 메시지, 코드 주석, PR 설명 및 댓글, 슬랙 대화, 내부 공지, 문서, 운영 매뉴얼 등 다양한 글을 작성해야 합니다. 글을 잘 쓰는 것과 못 쓰는 것은 매우 큰 차이를…

  • 브랜딩은 이제 제품팀의 일일까?

    많은 PM들이 이 말을 좋아하지 않을 거예요. 브랜딩은 더 이상 마케팅만의 일이 아니에요. 이제는 제품팀이 책임져야 할 부분입니다. 많은 제품팀이 이 말을 싫어하는 이유는, 기능 로드맵이나 속도 차트 뒤에 숨어 있을 수 없다는 뜻이기 때문입니다. 이제는 제품이 사용자에게 어떤 감정을 주는지 챙겨야 한다는 뜻이기도 하고요. 맞아요, 감정입니다. 제품 매니저들이 보통은 눈을 굴리며 넘기던 부분이죠. 과거에는…

  • IT 프로덕트는 어떻게 ‘정당한 존재’가 되는가

    스티븐 시노프스키(Steven Sinofsky)가 40년 동안 현장에서 배운 법칙 소프트웨어를 구매하는 전문가들─프리랜서 개발자부터 대기업 고객까지─을 생각해보면, 단순히 제품이 좋고 유용하다는 이유만으로는 충분하지 않다. 잠재 고객에게 당신의 신뢰도와 미래 비전에 대해 납득시켜야 한다. 당신이 택한 기술적 접근법, 수용한 타협점, 그리고 베팅하고 있는 기술 스택이 그들이 함께하고 싶어 하는 방향이어야 한다. 이를 위해 필요한 것은 바로 ‘정당성(legitimacy)’, 즉…

  • 비개발 의사결정자를 위해 기술을 명확하게 설명하는 법

    내가 스태프 엔지니어로서 하는 가장 중요한 임무는 조직에 기술 명확성을 제공하는 것이다. 물론 프로젝트를 진행하고, 코드를 배포하며, PR을 리뷰하는 등 다른 업무들도 수행하지만, 내가 하는 일 중 가장 핵심적인 것은 바로 기술 명확성을 제공하는 것이다. 기술 명확성이란 무엇인가? 조직 내에서 기술 명확성이란 비기술적 의사결정자들이 소프트웨어 시스템에 어떤 변화를 줄 수 있는지에 대해 실질적이고 충분한 이해를…

  • AI를 위한 디자인 – 보이지 않는 기능들

    인공지능(AI)은 이제 우리 일상 속에 자연스럽게 스며들어 더 이상 신기한 존재가 아니다. 진짜 마법은 화면 뒤에서 이루어진다. 최고의 AI 기능은 “AI-Powered” 같은 화려한 배지를 내세우지 않고, 조용히 제품을 더 똑똑하고, 빠르며, 직관적으로 만들어 사용자가 인지하지 못하게 한다. 이처럼 보이지 않는 기능을 가진 제품을 디자인하려면 사고방식의 전환이 필요하다. AI 기능을 자랑하는 것이 아니라, AI가 제품의 자연스러운…

  • 리텐션을 잡기 어려운 진짜 이유 8가지

    그리고 이 교훈들을 최신 AI 앱에 어떻게 적용할 수 있을지에 대해 저는 지난 15년 넘는 시간 동안 리텐션 곡선 데이터를 집요하게 들여다보고 살아왔습니다. 창업자, 프로덕트 매니저를 거쳐 지금은 벤처캐피털리스트로 활동하고 있습니다. Andreessen Horowitz(앤드리슨 호로위츠)에서 매년 수백 개의 스타트업을 만납니다. 그중 상당수는 저희 a16z 스피드런(a16z speedrun program)이라는 프로그램을 통해 접하게 되는데, 여기서는 신생 스타트업에 최대 100만…

  • 프로토타입의 목적: 성공적인 제품을 발견하기

    개요 프로토타입은 정말 오래전부터 사용되어왔으며, INSPIRED라는 책에서는 제품팀에서 활용하는 네 가지 주요 프로토타입 유형을 설명한 바 있습니다. 최근까지도, 여러 프로토타입 유형들의 상대적인 비용과 이점은 수십 년 동안 크게 달라지지 않았습니다. Figma가 왜 이렇게까지 성공했는지 궁금하셨다면, 최근 몇 년간 “유저 프로토타입(user prototypes)”이라는 가장 인기 있는 프로토타입 유형을 만드는 데 있어 Figma가 핵심 툴 역할을 해왔기 때문이라고…

  • 제품을 만들기, 제품을 판매하기 (Build Products, Sell Products)

    [Plaid 내부 메모로 작성되었으나 대부분의 B2B 기업에도 해당되는 내용입니다.] Plaid는 우선 제품 중심(product-driven)[1] 회사이며, 그 다음으로는 유통 중심(distribution-driven)[2] 회사입니다. 우리는 이러한 우선 순위에 따라 의사결정을 합니다. 1. 우리의 가장 중요한 우선 순위는 고객이 실제로 사용하는 제품을 만드는 것입니다. 간단한 문장이지만 실행하기는 어렵습니다. 고객이 원한다고 말하는 것을 듣는 것뿐만 아니라, 그들이 실제로 사용할 제품을 어떻게 제공할지…

  • 전략, 그리고 긴박함(Strategy & Urgency)

    이 글은 전략과 우선순위 설정에 관한 이야기이며, ‘긴박함(urgency)’에 대한 관점을 새롭게 하면 전략적으로 사고하고 더 효과적으로 우선순위를 정할 수 있다는 점을 다룹니다. 긴박함 (Urgency) 긴박함이란 어떤 결정이나 행동을 미루었을 때 그로 인해 장기적인 가치가 얼마나 줄어드는지를 말합니다. 예를 들어, 당신의 회사가 시장을 선점하려고 경쟁하고 있다고 생각해보세요. 첫 번째로 시장점유율 30%를 달성하는 곳이 이후 50%까지 훨씬…

  • 고객이 당신을 진짜 필요로 하는 순간은 언제일까?

    고객이 당신을 필요로 하는 정확한 순간을 찾아내면 리드 생성이 훨씬 쉬워진다. 대부분의 B2B 마케팅팀은 제품이 가져다 줄 큰 ‘결과’에는 잘 집중한다. ✔ 내부 프로세스 간소화✔ 데이터 관리 단순화✔ 협업과 효율성 증대 모두 좋은 말들이다… 그런데 이런 말들로는 이상적인 고객이 스크롤을 멈추거나, 이메일을 열거나, 전화 상담에 응하게 만들지 못한다. 왜일까? 모두 너무 고차원적이고, 개념적이며, 세련된 표현이기…

  • 사용자가 구매자가 아닐 때, 어떻게 팔 것인가

    예시: 개발자(dev)는 사용자, CTO는 구매자(buyer) 최근에 “가장 내 제품의 가치를 높게 평가하는 사람이 바로 이상적인 고객이다”라는 글을 올린 적이 있어요. 그런데 바로 한 비공개 커뮤니티에서 이런 질문이 나왔죠. 만약 내가 이상적인 고객과 대화해야 한다면, 그 사람이 실제로 제품을 써보는 사람이 아니라면 어떻게 접근해야 할까요?제 경우엔 완전히 동의해요. CTO나 엔지니어링 디렉터가 최종 의사결정을 내리는 것 같아요.…

  • 유능한 리더들은 어떤 능력으로 불확실성을 헤쳐나가는가

    복잡하고 어려운 상황을 유연하게 헤쳐 나갈 줄 아는 리더들은 무엇을 알고, 어떻게 다르게 행동할까? 그런 능력이 있는 리더를 본다면 어떤 모습이 보일까? 이 질문은 Innovation Tactics 카드 덱의 저자 톰과 존이 최근 대화에서 던진 화두다. 보통 이런 역량들은 ‘소프트 스킬’이나 ‘문화 적합도’ 같은 포괄적인 개념으로 치부되곤 한다. 그런데 만약 이 능력들을 명확하게 정의한다면 어떨까? 우리는…

  • 13가지 제품 리더십 원칙(Product Leadership Principles)

    최근에 관리자로 막 승진한 PM(Product Manager)과 이런저런 대화를 나누게 됐어요. 채용, 인력 배치, 팀 코칭 같은 결정을 할 때 저는 어떤 기준으로 판단하는지 궁금해하더라고요. 덕분에 그동안 쌓아왔던 제품 리더십 원칙(그리고 제가 가진 고유의 편향)들을 되짚어 보고, 오랜 기간 다듬어온 생각들을 이번 기회에 정리해 공유하려 합니다. 제가 믿는 원칙들은 조직의 동료들에게 때로는 흥미롭게 다가오기도 했고, 때로는…

  • 제품과 제안의 차이점 (Product versus Offering)

    그리고 이것이 당신의 로드맵과 성장 경로에 미치는 영향 도전 과제: 문제와 약속을 일치시키기 대부분 창업자들은 기술 제품 내부의 세부 사항에 많은 고민을 쏟습니다. 제가 이전에 쓴 글에서 기술적 차별점에 기반한 올바른 제품 인사이트를 확보하는 것이 얼마나 중요한지 다루었죠. 하지만, 마법 같은 제품만으로는 충분하지 않습니다. 기술 창업자는 우선 고객이 겪고 있는 절박한 문제를 찾아내야 합니다. 결국…

  • 앤트로픽에서 알려주는 효과적인 에이전트 구축하기 (Building effective agents)

    우리는 다양한 산업 분야에서 LLM 에이전트를 구축하는 수많은 팀들과 협업해 왔습니다. 공통적으로 가장 성공적인 구현 사례들은 복잡한 프레임워크보다는 단순하고 조합 가능한 패턴을 사용하는 경우였습니다. 지난 1년 동안, 우리는 여러 산업 전반에서 대규모 언어 모델(LLM) 기반 에이전트를 개발하는 팀들과 함께 일했습니다. 꾸준히 증명된 사실은, 가장 성공적인 구현이 특수한 라이브러리나 복잡한 프레임워크에 의존하지 않았다는 점입니다. 대신, 단순하면서도…

  • 최고의 기업은 독재자가 이끈다

    모두가 민주주의를 원하지만, 결과물을 보면 생각이 달라진다 창업자는 우리 제품 리뷰 회의실에 들어와서, 우리가 몇 주 동안 공들여 완성한 PRD를 바라본 뒤 그것을 반으로 찢어 버렸다. 그는 화이트보드에 자신이 원하는 것을 그렸다. 세 개의 박스와 몇 개의 화살표를 그리고는 그대로 자리를 떠났다. 회의실은 침묵에 휩싸였다. 선임 엔지니어들은 서로를 바라보았고, 찢긴 종이들은 불편하게 회의 테이블 위에…

  • 바이브 코딩에는 컨텍스트 엔지니어링이 필요하다

    AI와 함께하는 개발의 미래는 단순한 ‘감’이 아니라, 체계적인 구조에 달려 있다. 작성 방법: @NotebookLM을 활용해 유튜브 영상 5개를 요약하고, Dust를 통한 Claude 4 Sonnet에는 제공된 문서를 기반으로 “Vibe Coding에는 Context Engineering이 필요한가?”라는 주제로 에세이를 작성하도록 지시한다. 제안된 구성은 다음과 같다. 먼저, 바이브 코딩의 가능성을 다루고, 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로의 진화 과정을 설명한다. 이후, 컨텍스트 엔지니어링을…

  • Software 3.0: 소프트웨어가 소프트웨어를 집어삼키는 시대

    모델의 융합: 새로운 소프트웨어 스택과 무한히 확장되는 추상화의 여정 방식의 경계를 넘어선 시대: Gemini 2.5 Pro, GPT-4, Claude 4 Sonnet 결과를 바탕으로 “소프트웨어가 소프트웨어를 집어삼키는 진화”라는 주제로, Andrej Karpathy의 Software 1.0, 2.0, 3.0 개념을 중심으로 에세이를 작성하세요. 아울러 현대 AI 제품들이 Software 1.0, 2.0, 3.0 방식을 어떻게 결합·활용하는지에 대한 별도 섹션도 포함하세요. 세 모델(Gemini 2.5…

  • 프로덕트에 적합한 성장 전략 선택하기: 영업 주도 성장 vs. 제품 주도 성장

    적합한 시장 진출(GTM, Go-To-Market) 전략 선택 가이드 제가 창업자들과 가장 즐겨 이야기하는 주제 중 하나는 ‘0에서 1로 가는 Go-To-Market(시장 진출)’ 전략입니다. 각 창업자의 상황은 모두 다르지만, 반복해서 나오는 공통된 질문들이 있습니다: 어떻게 적합한 GTM 전략을 선택할까? 서로 다른 접근법의 균형을 어떻게 맞출까? 전략을 바꿔야 할 적절한 시점은 언제일까? General Catalyst 네트워크의 B2B 그로스 리더들에게 위…

  • 혁신적인 제품은 ‘창조’가 아니라 ‘발견’이다

    몇 년 전, Chris Cox가 영화 제작의 역사를 다룬 다큐멘터리 ‘The Story of Film’을 꼭 보라고 추천해줬다. 돌이켜보면 지금은 당연하게 여기는 영화라는 매체도 불과 100여 년 전에 처음 생겨난 새로운 형식이었다. 여러 세대를 거치며 수많은 영화인들이 모여, 어떻게 해야 이 매체를 효과적으로 활용할 수 있는지 배워나갔다. 그 배움은 지금도 여전히 진행 중이다. 초창기에는 영화가 단지…

  • SuperGoal, 팀을 극적으로 변화시키는 힘

    모든 것이 걸린 중요한 순간, 반드시 극복해야 하는 도전 앞에서 사용할 수 있는 프레임워크 대부분의 훌륭한 팀들은, 크고 야심찬 목표를 실행하는 데 있어서 명확하게 정의되고 잘 전달된 목표만큼 강력한 동력은 없다고 입을 모읍니다. 하지만 때로는, 평소보다 훨씬 더 중대한 상황이 찾아오기도 합니다. 이런 순간에는 목표에 대한 집중력, 실행력, 그리고 명확성이 그 어느 때보다 더 요구됩니다.…

  • 셰프의 칼 vs. 스위스 아미 나이프: 스타트업이 선택해야 할 진짜 경쟁력은?

    특정한 문제를 완벽하게 해결하는 것이, 이것저것 다 갖추는 것보다 왜 더 효과적인 전략이 될 수 있는지 숙련된 셰프가 눈부신 참다랑어 한 덩이를 앞에 두고, 접이식 멀티툴이 아니라 완벽하게 균형 잡힌 칼을 집어 드는 데에는 직감적으로 이해되는 깊은 이유가 있습니다. 셰프의 칼은 오직 한 가지 목적을 위해 수백 년에 걸쳐 다듬어진 도구입니다. 손에 쥐었을 때 무게감이…

  • 급한 불이 여기저기 나도, 무자비하게 우선순위를 정하라

    시간은 제로섬 게임이기 때문에, 우선순위 결정은 선택이 아닌 필수다. 이 글은 다양한 목적에 맞춘 우선순위 프레임워크와, 인생을 최적화하기 위한 통합적인 접근법을 소개한다. 우선순위의 명령 시간은 제로섬 자원이다. 한 가지에 한 시간을 쓰면, 그 시간만큼 다른 모든 가능성에 쓸 수 없다. 매 순간이 선택이고, 그 선택은 곧 다른 무언가를 포기하는 트레이드오프다. 시간에는 분명한 한계가 있다. 우리는…

  • 주도성과 야망, 그 사이에서

    나는 모든 제품 담당자들이 야망도 크고, 스스로 주도적으로 움직일 거라 믿고 싶다. 하지만 최근 들어, 현실은 꼭 그렇지만은 않다는 사실을 깨닫게 됐다. 솔직히 이런 사실을 인정하는 게 마음이 아프다. 처음엔 이런 사람들은 내가 도울 수 있는 대상이 아니라고 생각했다. 하지만 아직까지 이들을 완전히 포기할 마음은 없다. 야망(ambition)이란, 자기 자신뿐만 아니라, 내가 속한 제품팀과 회사 모두에서…

  • 낙관주의가 현실을 만든다

    초고속 실행을 가능하게 하는 방법 이 메모는 2019년에 Scale AI 팀에 보냈던 글입니다. 그때 저는 우리가 정말 믿기지 않을 만큼 빠른 속도로 나아가고 있다는 짜릿한 감정을 생생하게 느꼈고, 그 에너지가 사라지지 않기를 바랐습니다. 이 메모는 그런 초고속 실행을 계속 이어가기 위한 저만의 선언문이기도 했습니다. 세상에 큰 변화를 만들고 싶은 분들에게 이 글이 도움이 되길 바랍니다.…

  • 정보 압축: 왜 잘못된 일이 벌어지는가

    이 글은 2019년에 Scale 팀에 보냈던 메모로, 실제로 회사 내 많은 사람들의 일하는 방식을 크게 바꿔놓았습니다. Scale에 계시지 않은 분들께도 이 글이 마찬가지로 유익하게 다가가길 바랍니다. 조직이 커질수록 효율성이 떨어지는 이유로 흔히 “소통 비용”이 꼽힙니다. 팀 규모가 커지면 서로 소통하는 데 쓰는 시간이 기하급수적으로 늘어나고, 그만큼 효율도 떨어진다는 단순한 논리죠. 이 설명도 일리가 있지만, 저는…

  • 소비자용 AI 시장에서 ‘추진력(Momentum)’이 곧 해자(Moat)다

    소비자용 AI(Consumer AI) 분야에서 어떻게 해자(Moat)를 만들 수 있을까요? 솔직히 말해, 지금 이 순간에는 뚜렷한 해자가 존재하지 않습니다. 시장이 너무 빠르게 변하고 있기 때문입니다. 기본이 되는 AI 모델과 인프라가 매달 바뀌고, 심지어 매주 새로운 업데이트가 쏟아지는 상황에서, 과거 모바일 시대처럼 느긋하게, 혹은 체계적으로 사업을 구축하는 것은 사실상 불가능해졌습니다. 이처럼 역동적으로 변화하는 환경에서는 ‘얼마나 빠르게 제품을…

  • 제품 연옥(Product Purgatory): 모두가 좋아한다고 하지만, 정작 아무도 사지 않는 이유

    대부분의 사람들은 당신이 제품을 소개하면 좋은 말을 해줍니다. “와, 정말 좋아 보이네요! 마음에 드는데, 지금 당장은 구매 계획이 없어요. 올해 말쯤 다시 연락 주시겠어요?” 사실 누군가의 ‘아기’가 못생겼다고 말하는 건 쉽지 않은 일이죠. 이런 반응은 새로운 창업자들에게 함정이 됩니다. 창업자들은 자신의 아이디어에 푹 빠져 있기 마련이고, 그만큼 인정받고 싶어 하죠. 겉으로는 제품에 대한 검증을 원한다고…

  • AI 프로덕트에 빠진 결정적 연결고리(Loop)

    뛰어난 AI 제품은 사용자에게 묻지 않고, 행동을 관찰하며 학습한다 모든 AI 스타트업의 피치 마지막에는 항상 마지막에 이런 약속이 빠지지 않는다. “고객 데이터를 활용해 우리 모델을 미세 조정(fine-tune)하겠습니다.” 하지만 실제로 창업자들에게 그 데이터를 어떻게 확보할 거냐고 물어보면, 대부분 피드백 폼이나 사용자 설문조사 같은 모호한 답변만 내놓는다. 빅테크 기업들은 AI가 대중화되기 훨씬 전부터 암묵적(implicit) 데이터 수집에 능숙했다.…

  • AI 엔지니어링 스택

    AI 스택의 세 가지 계층, AI 엔지니어링이 ML 엔지니어링이나 풀스택 엔지니어링과 어떻게 다른지, 그리고 그 외 다양한 내용을 다룹니다. 이 글은 Chip Huyen의 저서 『AI Engineering』에서 발췌한 내용입니다. 1. AI 엔지니어링 스택의 세 가지 계층 모든 AI 애플리케이션 스택은 세 가지 계층으로 구성됩니다: 애플리케이션 개발, 모델 개발, 그리고 인프라입니다. 실제로 AI 애플리케이션을 개발할 때는 보통…

  • 대형 테크 기업에서 프로젝트를 실제로 ‘출시’하는 법

    지난 10여 년 동안 테크 업계에서 정말 다양한 프로젝트를 실제로 세상에 출시해 왔어요. 중요한 프로젝트를 꼭 성공적으로 완수해야 할 때마다 저에게 리더십을 맡기는 경우가 많은데, 그건 제가 이런 일을 잘 해내기 때문이죠. 대형 테크 기업에서 프로젝트를 ‘출시’하는 역량은 단순히 코드를 잘 짜는 것과는 완전히 다른 능력입니다. 실제로, 코딩 실력이 뛰어난 사람들 중에도 ‘출시’에는 영 소질이…

  • 성과를 만드는 건 어려운 일입니다

    Marty의 말 가장 큰 틀에서 보면, 제품 모델로 전환한다는 건 곧 산출물 중심에서 성과 중심으로 일하는 방식으로 바뀐다는 뜻입니다. 개념적으로는 매우 단순하고, 그 가치 역시 대부분의 사람들이 직관적으로 이해할 수 있습니다. 하지만 실제로 이를 실천하는 것은 결코 쉽지 않습니다. 다행히도, 이제 많은 분들이 실제로 고객이나 비즈니스에 도움이 되지 않는 기능만 단순히 출시하는 것은 큰 의미가…

  • ‘더 적게’라는 말에 숨겨진 잠재력

    제 연구 이야기를 하면, 뭔가를 더 나아지게 만들 때 우리가 ‘빼기(subtract)’라는 방법을 거의 쓰지 않는다는 데에 반박하는 사람은 없습니다. 실제로는 ‘그만둘 일(to-stops)’이 필요한데도 ‘해야 할 일(to-dos)’만 계속 쌓아간다거나, 좋은 행동을 장려하는 인센티브는 만들면서도 그 행동을 방해하는 장애물은 제거하지 않는다는 이야기를 하면, 다들 공감하며 고개를 끄덕입니다. 1950년대에 비해 연방 규정이 17배나 길어졌다는 점이나, 특허 제목에서 ‘additive(더하는)’와…

  • 리드 호프먼의 제품 확산 확산 전략 (Distribution Techniques)

    리드 호프먼은 링크드인의 공동 창업자입니다. 이 글은 그의 저서 『블리츠스케일링(Blitzscaling)』에서 발췌한 내용입니다. 실리콘밸리의 많은 사람들은 고(故) 스티브 잡스가 말한 것처럼 ‘미친 듯이 훌륭한(insanely great)’ 제품을 만드는 데 집중하는 것을 좋아합니다. 훌륭한 제품은 분명 큰 장점이지만, 냉정하고 현실적인 사실은 좋은 제품에 뛰어난 확산 전략이 더해지면, 훌륭한 제품이지만 확산이 부족한 제품을 거의 항상 이긴다는 점입니다. 드롭박스는 훌륭한…

  • 제품이 정말 위대하다면, 굳이 ‘좋을’ 필요가 없다

    이 에세이는 Gmail을 만든 Paul Buchheit가 쓴 글로, 2010년에 블로그에 처음 공개되었습니다. 제품이 정말 위대하다면, 굳이 ‘좋을’ 필요가 없다 이제는 모두가 iPad 얘기에 지겨울 만큼 들었겠지만, iPad에 대한 부정적인 반응들이 전혀 본질을 짚지 못하고 있어서 이 기회를 그냥 넘기는 건 아쉬울 것 같다. 더 흥미로운 건, 2001년 iPod 출시 때도 똑같은 실수가 반복됐다는 점이다. 하지만…