컨텍스트가 이제 제품이다: 소프트웨어가 스스로 만들어지는 시대의 제품 리더십

URL: https://www.youtube.com/watch?v=Zn9NZ-r1-C4 날짜: 2026-09-30 채널: Lenny's Podcast 원문 제목: Context is now the product: Product leadership when software can build itself | Karri Saarinen 발표자: Karri Saarinen (Linear 공동창업자·최고제품책임자)

📌 핵심 질문

==AI가 소프트웨어 실행과 코드 생산을 자동화할수록 제품 조직은 어떻게 고객 맥락(Context)을 잃지 않고 더 나은 판단과 제품을 만들어낼 것인가?==

• 코드와 프로토타입을 더 많이, 더 빨리 생산하는 것과 고객에게 더 큰 가치를 주는 것은 같은 일이 아니다.
• 제품을 만드는 과정은 결과물과 함께 고객·문제·품질·판단에 관한 학습을 만들어왔는데, AI 자동화가 실행과 학습의 연결을 끊을 수 있다.
• 앞으로의 제품 리더십은 반복 작업을 자동화하고, 절약한 시간을 고객 접촉·비평·품질 훈련·추상적 사고·팀 전체의 맥락 공유에 재투자하는 데 있다.

제품의 경쟁력은 코드 자체보다 그 코드를 만드는 사람들이 가진 맥락, 취향(Taste), 판단(Judgment), 고객 이해, 그리고 누적된 학습에서 나온다. 따라서 조직이 관리해야 할 핵심 산출물은 소프트웨어만이 아니라 소프트웨어를 올바르게 만들게 하는 공유 맥락이다.

1. AI를 잠시 끊어도 사라지지 않는 제품의 어려움

1.1. 여름 휴식이 확인한 사실

1. AI 뉴스에서 의도적으로 멀어지기

   1. 여름 동안 최신 모델, 모델이 할 수 있는 일, 새 에이전트, 적용 가능한 기법을 따라가는 일을 멈췄다.
   2. 휴가에서 돌아오면 AI를 따라가지 못해 뒤처졌거나 세상이 크게 바뀌었을 것이라고 예상했다.
   3. 실제로 돌아와 보니 새 모델·새 기법·새 에이전트는 늘었지만 중요한 현실은 크게 달라지지 않았다.

2. 근본적인 제품 난제의 지속

   1. 훌륭한 제품을 만들고, 매출을 늘리고, 사업을 세우는 일은 여전히 어렵다.
   2. 도구는 더 많은 일을 더 빠르고 더 기능적으로 수행하지만, 도구를 썼다고 더 나은 것을 만들었다고 자동으로 말할 수는 없다.
   3. 조직이 확인해야 할 질문은 “새 도구를 사용했는가?”가 아니라 “실제로 더 나은 제품을 만들었는가?”, “팀이 더 나은 팀이 되었는가?”다.

1.2. 가치 생산을 도구 생산과 구별하기

1. 도구에 쏠린 관심

   1. 언제나 시험해 볼 새 도구가 있고, 조직은 무엇을 만들 수 있는지와 어떤 시스템을 붙일지에 상당한 관심을 쏟는다.
   2. 그러나 제품 전문가의 궁극적인 일은 도구·시스템·코드의 양을 늘리는 것이 아니라 누군가에게 가치 있는 것을 만드는 것이다.

2. 제품의 성공 기준

   1. 고객은 코드 줄 수나 조직의 생산량을 구매하지 않는다.
   2. 고객이 필요로 하는 문제 해결과 경험을 얻기 때문에 제품을 선택한다.
   3. 그러므로 생산량이 늘었다는 지표만으로 제품이 좋아졌다고 결론 내릴 수 없다. 실제 고객이 더 좋은 경험을 하는지 확인해야 한다.

2. 소프트웨어 공장과 조직의 정체성

2.1. AI 이전부터 이어진 규모 집착

1. 효율과 확장을 향한 산업의 오랜 방향

   1. 소프트웨어 업계는 조직의 성능을 확장하고 최적화해 더 많은 결과를 얻는 방법에 오랫동안 집착해 왔다.
   2. AI가 등장하기 전에는 더 많은 사람을 채용하고, 각자 전문화된 역할을 맡기고, 각자의 방식으로 일하게 하는 접근이 중심이었다.

2. 사람이 늘수록 늘어나는 과정

   1. 인원이 많아지면 조정하기 위해 더 많은 프로세스를 만들게 된다.
   2. 사람과 프로세스가 많아지면 각 사람이 무엇을 해야 하는지, 실제로 무엇을 하고 있는지 조직 전체가 알기 어려워진다.
   3. 그래서 실험과 데이터를 통해 무엇이 작동하고 무엇이 작동하지 않는지 확인하며, 조직에서 더 많은 결과를 끌어내려 한다.

2.2. 공장이 되지 말아야 하는 이유

1. 더 많은 결과와 더 나은 결과의 차이

   1. 더 많은 산출물이 더 나은 산출물을 뜻하지는 않는다.
   2. 목표는 조직이 공장처럼 코드와 기능을 계속 찍어내는 것이 아니라 고객 경험을 개선하는 것이다.

2. 소프트웨어 공장의 제한선

   1. 자동화된 “소프트웨어 공장(software factory)”을 구축하는 일 자체는 합리적일 수 있다.
   2. 다만 조직 전체가 모든 작업과 생각을 외부화하고 결과의 효율만 최적화하는 공장이 되어서는 안 된다.
   3. 핵심 경고는 “소프트웨어 공장을 만들 수는 있지만, 조직 자체가 그 공장이 되지는 말라(Don’t become a software factory)”는 것이다.
   4. 실행을 외주화할수록 사람은 왜 만들고 있는지, 고객에게 무엇이 중요한지, 다음 판단에 무엇을 배웠는지 놓치기 쉽다.

3. 제품 개발의 두 산출물: 제품과 학습

3.1. 만들기 자체가 만들어내는 학습

1. 두 가지 결과

   1. 제품을 만드는 과정은 눈에 보이는 제품(Product)과 보이지 않는 학습(Learning)을 동시에 생산한다.
   2. 무엇을 만들지, 어떻게 만들지, 어떤 형태가 될지 고민하면서 문제의 본질과 고객의 바람을 알아간다.

2. 질문을 푸는 여러 경로

   1. 팀이 스스로 답을 가설로 세울 수 있다.
   2. 답이 부족하면 다른 사람에게 이야기하고, 고객에게 직접 물어보며 답을 검증할 수 있다.
   3. 문제를 해결하려고 실제로 기울인 노력 자체가 문제 정의, 고객의 요구, 고객이 그리고 있는 미래에 관한 지식을 남긴다.

3.2. 실행과 학습 사이의 위험한 간격

1. 자동화가 끊을 수 있는 연결

   1. AI로 실행을 더 많이 자동화하고 팀 전체에 AI 사용을 장려할수록 실행(Execution)과 학습(Learning) 사이에 간격이 생길 수 있다.
   2. 자동화 그 자체가 나쁜 것은 아니지만, 자동화가 작업을 수행한 사람이 그 작업에서 배우지 못하게 만들면 문제가 된다.

2. 현장에서 배우지 못할 때의 비용

   1. 일하면서 배우지 않으면 해당 분야나 회사가 갖고 있던 우위를 결국 잃을 수 있다.
   2. 자동화의 효과를 평가할 때 시간 절약만 볼 것이 아니라, 팀이 고객과 문제를 더 잘 이해하게 되었는지도 봐야 한다.

4. 무엇을 자동화하고 무엇을 남길 것인가

4.1. 반복적인 작업은 AI에 맡기기

1. 자동화할 만한 일의 기준

   1. 반복적이고 수행 과정에서 새로운 학습을 거의 만들지 않는 일은 자동화 대상이 될 수 있다.
   2. 자동화의 목적은 사람의 사고를 없애는 것이 아니라, 학습이 더 많이 발생하는 활동에 사람의 시간을 돌려주는 것이다.

2. Linear의 버그 수정 사례

   1. Linear는 당시 많은 버그 수정 작업을 진행하고 있었다.
   2. Linear Loop를 사용해 오류를 조사하고, DataDog·Sentry 같은 도구와 연결해 관련 신호를 모은다.
   3. 에이전트는 코드베이스를 살펴 오류의 원인을 파악한 다음 수정안을 작성한다.
   4. 엔지니어는 이슈를 처음부터 조사하는 시간을 줄이고 결과를 확인한다.
   5. 결과가 완벽하지 않으면 엔지니어가 작은 조정을 가한다. 자동화는 판단을 없애지 않고 조사에 드는 시간을 줄이는 방식으로 사용된다.

4.2. 절약한 시간을 고객과 문제에 투자하기

1. 고객과 직접 가까워지는 원칙

   1. 회사 초기부터 엔지니어를 포함한 모든 구성원이 고객과 소통하도록 장려했다.
   2. 고객의 Slack 채널과 채팅에 참여하고, 질문에 답하고, 스스로 질문하며, 고객 가까이에서 일하도록 했다.
   3. 이런 접촉은 고객의 문제를 이해하는 직관(Intuition)을 쌓는다.

2. AI 이후의 시간 재배치

   1. AI가 버그 조사 같은 반복 작업을 덜어주면 엔지니어와 다른 전문가에게 약간의 여유 시간이 생긴다.
   2. 그 시간을 더 깊은 고객 참여, 새로운 기회 탐색, 자신의 판단 다듬기, 과거보다 높은 품질의 작업에 쓸 수 있다.
   3. 생산성 향상을 작업량 증가로만 해석하지 않고 고객 이해와 판단력 증가로 전환해야 한다.

5. 제품 조직의 미래는 학습 순환을 유지하는 일

5.1. 맥락의 수집·해석·확산

1. 학습 순환의 핵심 단계

   1. 고객과 문제에서 맥락(Context)을 얻는다.
   2. 맥락에서 의미 있는 신호(Signal)를 추출한다.
   3. 신호와 배움을 팀 전체와 회사 전체에 퍼뜨린다.
   4. 팀이 새로운 기능을 실행하기 전에 그 배움을 이용해 더 좋은 판단을 내리게 한다.

2. AI를 생산 도구가 아니라 맥락 도구로 사용하기

   1. 많은 사람이 AI가 무엇을 할 수 있는지에 집중하지만, AI가 무엇을 가르칠 수 있는지에도 주목해야 한다.
   2. AI는 흩어진 고객 발언을 모으고, 반복되는 신호를 찾아, 구성원이 맥락에 접근하는 시간을 줄이는 데 유용하다.

5.2. Linear의 고객 맥락 축적

1. 여러 접점의 피드백 통합

   1. 영업 통화와 기타 미팅에서 나온 고객 피드백을 자동으로 수집한다.
   2. 지원 이메일과 사내 토론의 내용도 함께 모아 고객 경험을 이해하는 기반을 만든다.
   3. 정보가 한곳에 쌓이면 특정 팀만 고객을 아는 상태에서 벗어나 회사 전체가 고객 맥락을 활용할 수 있다.

2. 요청을 감시하는 에이전트

   1. 규모가 큰 제품 조직에서는 고객 문제와 요청이 너무 많아 모든 이메일과 요청을 직접 읽기 어렵고, 사람이 일상적인 문제에서 멀어지기 쉽다.
   2. 그래서 고객 요청을 모아두고, 흥미로운 내용이 나타날 때 알려주는 “워처(watcher)” 같은 에이전트를 설정했다.
   3. 알림은 모든 내용을 사람이 훑게 하는 대신 중요한 신호가 나타났을 때 다시 고객 문제와 연결해 준다.

3. AI 워크플로 일일 보고서

   1. 고객이 AI 워크플로를 어떻게 사용하는지 보여주는 일일 보고서를 만든다.
   2. 고객들이 AI 워크플로에 대해 무엇을 말하는지, 도구에서 무엇을 원하는지, Linear가 어떻게 더 잘 도울 수 있는지 파악하려는 목적이다.
   3. 회사마다 AI 도구를 쓰는 방식이 매우 달라 아직 분명한 모범 사례(Best Practice)가 없으므로, 실제 사용 패턴을 계속 배우는 과정이 필요하다.
   4. 보고서는 대개 몇 개의 요약문으로 구성되어 하루 중 많은 시간을 요구하지 않는다. 짧은 보고서를 매일 읽는 것만으로도 새로운 고객 신호를 놓치지 않는다.

6. AI 시대의 품질은 함께 훈련해야 한다

6.1. 에이전트와의 고립이 만드는 학습 손실

1. 각자 따로 일하는 현상

   1. AI와 에이전트를 많이 사용할수록 사람들이 혼자 에이전트와 작업하는 경향이 커진다.
   2. 개인이 자신의 결과물을 빠르게 만드는 데는 효과적이지만, 동료에게서 배우는 양은 줄어든다.
   3. 각자의 에이전트 작업이 서로 공유되지 않으면 팀의 품질 기준과 판단 기준도 분리된다.

2. 공유 품질 환경의 필요

   1. Linear는 신규 채용이 계속되면서 모든 사람이 동일한 기준이나 품질 이해를 갖고 있지 않다는 점을 발견했다.
   2. 그래서 “품질 환경(quality environment)”이라는 실천을 만들었다. 품질은 문서 한 장으로 주입하는 것이 아니라 반복적인 공동 관찰로 훈련한다.

6.2. 주간 품질 점검

1. 작은 결함 하나를 고치는 규칙

   1. 모든 구성원이 매주 제품을 직접 사용한다.
   2. 제품에서 품질 결함 하나를 찾아 직접 고친다.
   3. 결함은 이상한 호버 상태, 어색한 애니메이션, 잘못된 문구처럼 아주 작아도 된다.
   4. 거대한 프로젝트나 대규모 리팩터링일 필요 없이 5분 만에 끝나는 수정도 충분하다.

2. 진짜 산출물은 훈련된 눈

   1. 작은 수정의 직접 효과도 있지만, 더 큰 효과는 팀 전체가 작은 문제를 알아보는 눈을 훈련한다는 데 있다.
   2. 발견과 수정 과정을 회의에서 공유하면 구성원은 다른 사람이 문제를 어떻게 찾아내는지 관찰한다.
   3. 품질은 특정 QA 담당자만 책임지는 속성이 아니라, 제품을 사용하는 모든 사람이 함께 기르는 감각이 된다.

6.3. 새 기능에 대한 공개 비평

1. 기능 리뷰(Function Review)의 운영

   1. 새 기능을 만들 때는 품질 점검과 비슷하지만 성격이 다른 “기능 리뷰(function review)”를 연다.
   2. 선택 참여 방식이며 회사의 누구나 참여할 수 있다.
   3. 기능을 만든 팀이 자리를 마련하고, 참석자에게 기능 전체를 비평해 달라고 요청한다.

2. 비평의 규칙

   1. 참석자는 까다롭거나, 혼란스럽거나, 사소하다고 느끼는 점을 자유롭게 말할 수 있다.
   2. 피드백은 개인에 대한 공격이 아니라 “나는 이렇게 보인다(This is how I see it)”라는 관점의 공유로 취급한다.
   3. 기능을 만든 팀은 이해되지 않는 부분을 질문하고, 참석자의 관점을 확인한다.

3. 사용자 관점의 조기 시뮬레이션

   1. 회사의 많은 사람에게 기능 리뷰는 해당 기능을 처음 접하는 순간이다.
   2. 동료가 혼란스러워한다면 실제 사용자도 혼란스러울 가능성이 높다.
   3. 리드는 피드백을 요약하고 묶어 구체적인 작업으로 바꾼 뒤 수정한다.
   4. 함께 비평하는 과정은 무엇이 중요한지, 회사가 어떤 품질을 중시하는지 가르치는 교육이기도 하다.

4. 반복되는 학습의 기억

   1. 회의에서 들은 동료의 관심사를 기억하면 다음 작업에서 그 기준을 선제적으로 확인하게 된다.
   2. 예를 들어 어떤 동료가 온보딩을 항상 주의 깊게 본다는 것을 알면 다음 기능에서 온보딩을 더 꼼꼼히 확인한다.
   3. 어떤 사람이 애니메이션을 세밀하게 검토한다는 것을 알면 자신의 기능에서도 같은 문제를 미리 찾는다.

7. 효율 다음에 와야 할 추상적 사고

7.1. 생산량 최적화에서 학습 시간 최적화로

1. AI가 시간을 돌려줄 때의 선택

   1. AI가 모든 일을 더 효율적으로 만들고 생산량을 높여준다는 발상만 따르면 절약한 시간도 다시 실행 작업으로 채워진다.
   2. 그 시간은 고객 연구, 동료의 비평, 품질 개선, 우리가 하는 일을 다시 생각하는 데 사용할 수 있다.

2. 제품 조직의 활동 변화

   1. 앞으로 제품 조직은 실행에 쓰는 시간은 줄이고, 활동 자체와 팀·조직을 더 나아지게 하는 방법을 생각하는 추상적 사고에 더 많은 시간을 쓰게 될 수 있다.
   2. 새로운 기능의 양보다 팀이 더 정확한 질문을 만들고, 더 나은 판단을 반복해서 내리는 능력이 중요해진다.

7.2. 사람과 에이전트를 위한 공유 지식 공간

1. 조직의 누적 지식 보존

   1. 회사는 자신이 다루는 문제와 업무에 대한 이해를 시간이 지나며 축적한다.
   2. 고객 맥락, 제품의 작동 방식, 지금까지의 결정과 시도, 중요하게 여기는 기준을 누구나 접근 가능한 곳에 저장해야 한다.
   3. 공유 공간은 새로 합류한 사람이 배우는 장소이면서 기존 팀이 과거의 판단을 다시 확인하는 장소다.

2. 에이전트도 맥락을 읽어야 한다

   1. 공유 맥락은 사람만을 위한 지식 저장소가 아니다.
   2. 에이전트에게 고객이 특정 문제에 대해 무엇을 말했는지, 실제로 무엇을 하고 있는지, 팀이 어떻게 반응했는지를 질문하려면 에이전트가 읽을 수 있는 맥락이 있어야 한다.
   3. 에이전트가 코드만 보고 기능을 만드는 상태와 고객·제품·팀의 맥락까지 읽고 제안하는 상태 사이에는 큰 품질 차이가 생긴다.

8. 직관은 신비한 감이 아니라 훈련된 맥락이다

8.1. 실험보다 중요한 제품 판단

1. Linear의 직관 중심 접근

   1. Linear는 모든 결정을 실험으로 검증하는 방식에 실제로 의존하지 않는다.
   2. 구성원에게 직관을 믿으라고 말하지만, 직관을 근거 없는 감이나 마법으로 취급하지 않는다.

2. 직관의 구성 요소

   1. 직관은 일을 하며, 고객의 말을 들으며, 문제의 맥락을 반복해 접하며 뇌를 훈련한 결과다.
   2. 더 많이 배우고, 더 많이 듣고, 더 많은 맥락을 보면 개인의 이해가 깊어진다.
   3. 개인의 이해가 팀에 공유되면 팀 전체의 판단 수준도 올라간다.

8.2. 채용의 목적은 생산성 증가를 넘어선다

1. 좋은 제품의 첫 단계로서 채용

   1. Linear에서는 좋은 제품을 만드는 첫 단계가 좋은 사람을 채용하는 일이라고 믿는다.
   2. 단순히 “이 사람이 어떤 업무를 맡아 생산성을 얼마나 높일까?”만 물어서는 안 된다.

2. 사람이 만들어낼 궤적

   1. 그 사람이 회사에 어떤 궤적(Trajectory)을 만들어낼지 생각해야 한다.
   2. 어떤 아이디어를 갖고 있는지, 건전한 판단과 취향이 있는지, 그것을 조직 안에서 어떻게 활용할지 살펴야 한다.
   3. 맥락을 읽고 판단하는 사람을 채용하는 일은 코드 생산량을 늘리는 일보다 제품의 방향과 품질에 더 장기적인 영향을 준다.

9. “맥락이 곧 제품”이라는 결론

9.1. 결과물 뒤에 있는 사람과 결정

1. 소프트웨어만 바라보는 시선의 전환

   1. 조직은 결과물인 소프트웨어와 코드에 집착하기 쉽다.
   2. 더 근본적인 질문은 “이 소프트웨어를 실제로 만들어낸 것은 무엇인가?”, “누가 결정을 내렸는가?”다.
   3. 결국 소프트웨어를 만드는 것은 사람이며, 사람의 맥락과 이해가 의사결정의 질을 좌우한다.

2. 맥락이 품질을 결정하는 경로

   1. 고객과 문제를 더 잘 이해하는 사람은 무엇을 만들어야 하는지 더 잘 판단한다.
   2. 판단과 취향이 더 나은 팀은 같은 도구를 사용해도 더 나은 결과를 만든다.
   3. 따라서 더 좋은 제품을 만들려면 코드 생성 능력뿐 아니라 팀이 가진 공유 맥락을 개선해야 한다.

9.2. 자동화 시대의 제품 리더십 원칙

1. 자동화의 우선순위

   1. 반복적이고 중요도가 낮으며 학습이 거의 발생하지 않는 작업부터 자동화한다.
   2. 자동화 결과는 사람이 확인하고 필요하면 작은 조정을 하도록 한다.

2. 사람에게 되돌릴 활동

   1. 고객의 문제를 직접 듣고 새로운 기회를 탐색하는 시간을 보장한다.
   2. 팀이 서로의 결과를 비평하고 품질 기준을 학습하는 장치를 만든다.
   3. 고객 정보와 제품 역사를 공유 공간에 보존하고 사람과 에이전트 모두가 접근하게 한다.
   4. 조직의 성공을 산출물 수가 아니라 학습 순환의 속도와 판단의 질로도 평가한다.

주요 발언 모음

“More results do not mean better.”

“You can build software factories, automate things, and that all makes sense, but as an organization, don’t become that factory.”

“Creating products produces two outcomes: the product itself and learning.”

“The real danger now for the product organization is that the more we automate things with AI, the more of a gap is created between execution and learning.”

“Intuition is not some magical force like in Star Wars that just appears out of nowhere.”

“It’s something you learned while working on something, listening to customers or something like that.”

“Context becomes the product.”

핵심 데이터 & 수치

• 영상 길이: 약 17분 22초(1,042초) 분량의 라이브 발표다.
• 발표 시점: Lenny and Friends Summit에서 2026년 9월 10일 샌프란시스코에서 녹화됐다.
• AI 휴식 기간: 여름 동안 AI 뉴스·모델·에이전트·기법 추적을 중단하고 복귀 후 변화의 본질을 점검했다.
• 주간 품질 규칙: 모든 구성원이 매주 제품을 사용하고 결함 하나를 찾아 수정한다.
• 수정의 크기: 이상한 호버 상태, 어색한 애니메이션, 잘못된 문구처럼 5분 만에 고칠 수 있는 결함도 대상이다.
• 고객 맥락 보고서: 고객의 AI 워크플로 발언을 모은 일일 보고서는 대개 몇 개의 요약문으로 구성된다.
• 제품 개발의 이중 산출물: 제품 결과물과 학습 결과물이다.
• 고객 접점: 영업 통화·기타 미팅·지원 이메일·사내 논의에서 고객 정보를 수집한다.
• 품질 리뷰 참여: 새 기능 리뷰는 회사 구성원 누구나 참여할 수 있는 선택형 회의다.

결론 및 시사점

1. AI가 코드와 실행을 빠르게 만들수록 사람이 고객과 문제를 직접 접하며 얻는 학습을 보호해야 한다.
2. 자동화 대상은 반복적이고 학습 가치가 낮은 작업이어야 하며, 자동화로 확보한 시간은 고객 연구·비평·품질 훈련으로 재투자해야 한다.
3. 고객 피드백을 영업·지원·회의 등 여러 접점에서 모으고 에이전트가 중요한 신호를 알려주는 구조를 만들면 리더도 고객 맥락에서 멀어지지 않는다.
4. 매주 작은 결함을 고치고 새 기능을 공개적으로 비평하는 습관은 결과물뿐 아니라 팀의 품질 감각을 함께 높인다.
5. 제품 조직의 핵심 자산은 코드 생산량이 아니라 고객 맥락을 축적하고 팀의 판단으로 전환하는 능력이다.
6. 직관은 신비한 감이 아니라 고객을 듣고 문제를 해결하며 얻은 반복 학습의 압축된 형태다.
7. AI 시대의 제품 리더는 더 많은 산출물을 요구하는 사람을 넘어, 더 나은 이해와 학습이 계속 발생하는 환경을 설계해야 한다.

핵심 요약 (20줄)

AI 도구가 더 빠르고 기능적으로 발전해도 훌륭한 제품과 사업을 만드는 일은 여전히 어렵다. 더 많은 코드와 결과물을 생산하는 일은 고객에게 더 나은 가치를 제공하는 일과 다르다. 제품을 만드는 과정은 제품 결과물과 함께 고객·문제·판단에 관한 학습을 만든다. AI 자동화가 실행과 학습 사이의 연결을 끊으면 팀은 장기적인 경쟁 우위를 잃을 수 있다. 반복적이고 학습 가치가 낮은 작업은 자동화하고 학습이 필요한 일은 사람에게 남겨야 한다. Linear는 Linear Loop와 DataDog·Sentry를 연결해 버그 원인 조사와 수정안 작성을 자동화한다. 엔지니어는 절약한 시간을 고객과 직접 대화하고 새로운 기회를 탐색하는 데 사용할 수 있다. 모든 구성원이 고객의 Slack 채널과 대화에 참여하면 문제를 이해하는 직관이 쌓인다. 고객 피드백은 영업 통화·미팅·지원 이메일·사내 논의에서 모아 공유 맥락으로 만든다. 워처 에이전트는 수많은 고객 요청 중 흥미로운 신호가 나타날 때 리더에게 알려준다. 고객의 AI 워크플로를 요약한 일일 보고서는 아직 정립되지 않은 사용 패턴을 학습하게 한다. AI 에이전트와 혼자 일하는 방식은 효율적이지만 동료에게서 배우는 기회를 줄일 수 있다. 품질 환경은 모든 구성원이 매주 제품에서 결함 하나를 찾아 고치게 하는 실천이다. 5분 만에 끝나는 호버·애니메이션·문구 수정도 팀의 품질 감각을 훈련한다. 새 기능 리뷰는 회사 누구나 기능을 까다롭고 솔직하게 비평할 수 있는 공개 학습 공간이다. 동료가 기능을 이해하지 못하면 실제 사용자도 혼란스러울 가능성이 높다. 절약한 실행 시간은 고객 연구·비평·품질 개선·제품 조직에 대한 추상적 사고로 돌려야 한다. 직관은 스타워즈의 마법 같은 힘이 아니라 고객을 듣고 일하며 훈련한 뇌의 판단이다. 좋은 채용은 업무 생산성보다 사람이 회사에 만들어낼 아이디어·판단·취향의 궤적을 고려한다. 소프트웨어를 만드는 사람들의 맥락이 좋아질수록 제품도 좋아지므로 맥락이 곧 제품이 된다.