Continuous Learning_Startup & Investment

왜 refounding이 필요한가: 느린 쇠퇴는 전문경영인의 전문 분야다 Kaz는 전문경영인이 잘하는 일과 못하는 일을 아주 날카롭게 구분합니다. 그의 표현을 빌리면, 전문경영인은 slow decline을 관리하는 데는 꽤 괜찮다. 하지만 extraordinary outcome을 만드는 exothermic energy는 거기서 잘 안 나온다. 즉 회사가 sideways나 death spiral에 들어가면 pricing tweak, packaging tweak, 조금의 조직개편 같은 부분 개선으로는 안 된다는 겁니다. 그가 말하는 진짜 refounding은 “회사가 죽음의 나선에 들어갔으면, 거의 모든 것을 바꿔야 한다” 는 주장입니다. 그래서 그는 좋은 turnaround의 사례로 Apple, Microsoft를 떠올립니다. 둘 다 단순 효율화가 아니라 회사의 operating logic 자체가 바뀐 순간이 있었기 때문입니다. 그리고 여기서 “founder seat”라는 개념이 나옵니다. 그는 말합니다. 문제는 실제 창업자가 있느냐가 아니라, 회사 안에 founder seat를 누가 차지하고 있느냐입니다. 즉 실제 창업자 본인이 아니어도, 누군가가 결과 책임 장기 방향 급진적 재설계 제품 집착 을 떠맡는다면 그 자리를 점유할 수 있습니다. 주가를 보지 않는 이유: 회사 가치와 주가는 단기적으로 다르다 그는 아주 좋은 비유를 합니다. ESPN을 보는 게 쿼터백을 더 잘하게 만들지 않듯 CNBC를 보는 게 CEO를 더 잘하게 만들지 않는다 즉 그는 주가가 단기적으로는 회사 지능이나 실행력의 정확한 지표가 아니라고 봅니다. 그의 기준은 단순합니다. 사용자의 문제를 풀고 장기적으로 가치를 만들면 결국 회사 가치는 따라온다 이건 “주주 무시”가 아니라 오히려 더 엄격한 장기주의입니다. 쇠퇴를 관리하게 만드는 RSU보다, 결과에 베팅하게 만드는 구조 Kaz는 CEO 보상 구조가 굉장히 중요하다고 봅니다. 왜냐하면 보상이 행동을 만든다고 보기 때문입니다. 그는 이상적으로는 $1 salary options 중심 을 원했다고 말합니다. 즉 자신이 주주와 똑같이 성과가 나야만 돈을 버는 위치에 있고 싶었던 겁니다. 다만 상장회사 제도 때문에 그렇게 단순하게 하긴 어려워서, 실제로는 옵션과 유사한 PSU 구조로 설계했다고 말합니다. Opendoor 관련 보도도 그의 보상 패키지가 주가 성과와 강하게 연결된 공격적인 구조라는 점을 짚었습니다. 그가 RSU를 싫어하는 이유도 분명합니다. RSU는 때때로 경영진에게 “회사를 죽지 않게만 질질 끌어도 돈을 버는 구조”를 만들 수 있습니다. 그는 그걸 아주 싫어합니다. 왜냐하면 자신은 회사의 느린 쇠퇴를 관리할 인센티브가 전혀 없어야 한다고 보기 때문입니다. AI-native 전환: “Default to AI”를 문화가 아니라 평가 항목으로 박아 넣다 Kaz는 Opendoor를 그냥 “AI를 잘 쓰는 회사”로 만들려는 게 아니라, AI-native operating model을 만들려 합니다. 공식 회사 실적 발표에서도 Opendoor는 2025년 이후 AI 기반 수리 판단, title/escrow 자동화 등 여러 AI-driven 운영 변화를 설명했습니다. 그런데 인터뷰의 핵심은 기술 자체보다 조직 설계에 있습니다. 그는 회사 전체 해커톤을 열었고, 집 수리를 관리하던 현장 인력이 직접 소프트웨어를 만들어 자기 일을 자동화한 사례를 말합니다. 즉 AI-native란 소수 엔지니어만 AI를 잘 쓰는 게 아니라 업무를 가진 사람이 자기 일을 자동화하는 것 그래서 인간이 작업자가 아니라 소프트웨어 관리자(manager of software pieces)가 되는 것 입니다. 그리고 진짜 중요한 문장은 이것입니다. “The first line in your job description is: you default to AI.” 즉 AI 사용은 권장사항이 아니라, 사실상 직무 수행의 기본 전제입니다. 더 나아가 그는 성과평가의 첫 질문도 “이 사람이 AI를 기본값으로 쓰는가?”가 될 것이라고 말합니다. 이건 굉장히 강한 방식입니다. AI adoption을 문화 캠페인이 아니라 performance system에 넣어버린 겁니다. Job이 아니라 Career를 살아라 Kaz는 자신이 CEO가 되려고 10년짜리 비밀 계획을 세운 게 아니라고 말합니다. 대신 그는 늘 job이 아니라 career를 산다고 봤습니다. 그의 정의는 매우 깔끔합니다. Job: 남을 위해 돈 벌려고 하는 일 Career: 자기 자신을 위해 매일 구축하는 장기 프로젝트 그래서 그는 “얼마를 받느냐”보다 “나는 어떤 커리어를 쌓고 있느냐”에 훨씬 더 집중했다고 말합니다. 이 부분의 핵심은 단순 워커홀리즘이 아닙니다. 그는 대부분 사람에게는 job도 충분히 괜찮다고 분명히 말합니다. 다만 자신은 다르다는 겁니다. 자신의 삶은 커리어에 최적화돼 있고 아내도 그 커리어에 맞춰 살고 아이들도 그 사명을 같이 살아간다고 말합니다. 이건 일반화할 조언이라기보다, 그가 자신을 얼마나 강하게 “mission-oriented”로 정의하는지를 보여줍니다. Passion보다 Service “Passion을 따라라”는 말에 대해 그는 그다지 신뢰하지 않는 편입니다. 대신 이렇게 묻습니다. “어떻게 세상에 기여할 수 있을까?” 그 이유는 명확합니다. “내가 뭘 얻을까?”를 기준으로 살면 대개 꼬이고 “내가 어디에 보탬이 될까?”를 기준으로 살면 정렬되기 쉽다 그는 이게 커리어뿐 아니라 연애와 인간관계에도 같다고 말합니다. 즉 자기 자신을 주변에 순증(net addition)을 더하는 존재로 보라는 겁니다. 결혼과 아이는 왜 중요한가 그는 결혼이 남성의 건강 부 행복 에 매우 큰 영향을 준다고 봅니다. 그리고 북미 맥락에서 삶이 무너질 확률을 크게 줄여주는 3단계로 고등학교 졸업 직장 경험 30세 이전 결혼 을 제시합니다. 이건 보편적 진리라기보다 통계적으로 유리한 경로라는 식으로 말합니다. 특히 그는 아이를 갖는 것을 과소평가해서는 안 된다고 봅니다. 왜냐하면 CEO 일은 너무 외롭기 때문입니다. 그는 Shopify에서 대규모 해고 관련 1on1을 하루 종일 하고 무너져 울었던 날, 집에 돌아와 아들이 안아줬던 경험을 말합니다. 그 순간 그날의 고통은 사라지지 않았지만 감당 가능해졌다고 말합니다. 이 이야기는 “가족이 중요하다”는 추상론이 아니라, 리더십의 감정적 비용을 버티게 해주는 구조로서의 가족을 설명합니다. Karma, Mission, 그리고 삶의 목적 그는 오히려 사람마다 사명이 있고 그 사명을 찾는 것이 인생의 일이며 더 많은 선을 행할수록 더 많은 선이 돌아온다 고 믿습니다. 물론 이것이 “삶은 쉽다”는 뜻은 아닙니다. 그는 오히려 어려움과 의미가 높은 상관을 가진다고 봅니다. 이 철학이 결국 그의 개인적 사명으로 연결됩니다. “평범한 가정이 좋은 집을 afford할 수 있게 만들고, 좋은 가족을 꾸릴 수 있게 하자.” 즉 주택 소유와 거래의 friction cost complexity 를 줄이는 것이 그가 Opendoor에서 추구하는 깊은 목적입니다. https://youtu.be/9ZlmsA4Bzk0?si=f11F2BYLOzXTB7sM

professional managers care more about process than truth 즉, 전문 경영인은 때때로 무엇이 사실인가보다, 무엇이 그럴듯해 보이는가에 더 묶이기 쉽다는 겁니다. 왜냐하면 그들의 권력 기반은 “관리” 자체이기 때문입니다. 반면 창업자형 CEO는 결과에 책임지고 디테일을 파고들고 불편하더라도 진실을 보려고 합니다. 이 부분을 더 잘 이해하려면 Kaz가 겪은 “executive voice” 일화를 같이 봐야 합니다. 예전에 대기업에서 상사가 “너는 executive voice가 없어서 여기서 임원이 될 수 없다”고 말한 적이 있었다고 합니다. Kaz는 그 말이 매우 아팠다고 말합니다. 왜냐하면 회사는 겉으로는 “bring your whole self to work”라고 하면서, 정작 지나치게 디테일을 따지는 사람 약간 더 비동의적(disagreeable)인 사람 9 to 5를 이상하다고 생각하는 사람 에게는 사실상 “너의 전체 자아를 가져오지 말라”고 하는 셈이었기 때문입니다. 그래서 그에게 founder mode는 업무 스타일 문제가 아니라 “회사에서 배제되던 자기 자신을 결과 책임의 방식으로 다시 정당화한 것”에 가깝습니다. 약점을 고치기보다, 약점을 감싸는 사람을 둬라 약점을 무조건 고치는 게 정답은 아니다. 왜냐하면 어떤 약점은 바로 그 사람의 강점을 만들어내는 원인이기도 하기 때문입니다. 예를 들어 디테일 집착 약간의 공격성 구조에 덜 맞는 방식 지나친 몰입 같은 것은 일반적 managerial feedback으론 “고쳐야 할 약점”처럼 보입니다. 하지만 Kaz는 묻습니다. “내가 이게 약한 게, 내가 다른 데서 강한 이유는 아닐까?” 그래서 그는 평생 자신을 보완하는 사람을 곁에 두었다고 말합니다. Facebook에도 process person이 있었다. Shopify에도 있었다. Opendoor COO인 Jung도 그 연장선이다. 즉 그의 방식은 well-rounded person이 되려 하기보다, well-rounded system을 만드는 것입니다. 모든 CEO는 “사용자 설명서(user manual)”를 써야 한다 이건 제품 만드는 사람에게도 중요한 포인트입니다. Kaz는 자신에 대한 working blueprint, 일종의 **“Kaz 사용설명서”**를 10년 넘게 써왔다고 말합니다. 그는 이 문서를 모든 CEO가 가져야 한다고까지 말합니다. 왜냐하면 founder type 리더는 특히 strong attract, strong repel이기 때문입니다. 즉 나와 잘 맞는 사람은 매우 강하게 끌리고, 안 맞는 사람은 빨리 떨어져 나가야 합니다. 그는 이걸 식당 비유로 설명합니다. 이탈리안 레스토랑에 가서 “스시가 왜 없냐”고 하면 손님 잘못 그런데 간판이 그냥 “restaurant”인데 음식이 별로면 식당 잘못 즉 리더의 책임은 내가 어떤 사람인지 분명하게 알려서, 상대가 opt-in / opt-out 할 수 있게 하는 것입니다. 이건 채용, 팀빌딩, 협업의 마찰을 줄이는 굉장히 강한 철학입니다. “I got your back”의 진짜 뜻: 높은 초기 신뢰, 빠른 고갈 그는 자신이 “같이 일하면 나는 보통 사람보다 더 높은 신뢰에서 시작한다”고 말합니다. 여기서 Toby의 trust battery 개념을 가져옵니다. Toby식 기본형은 이렇습니다. 처음엔 50% 신뢰에서 시작 잘하면 배터리가 차오름 못하면 줄어듦 그런데 Kaz는 자신은 다르게 운영한다고 말합니다. 자신은 보통 75% 신뢰에서 시작 대신 소진(deplete) 속도가 훨씬 빠르다 왜냐하면 그는 사람에게 초반부터 더 큰 위험을 맡기고 싶어 하기 때문입니다. 즉 “I got your back”은 다정한 문장이라기보다 실제로는 “가서 위험을 감수해라. 내가 그 리스크를 underwriting 해주겠다.” 는 뜻입니다. 그런데 신뢰를 빨리 주는 만큼, 그 신뢰가 무너질 때는 조직에서 빨리 정리되기도 합니다. 그는 Opendoor 들어온 뒤 두 분기 사이에 executive team이 거의 다 바뀌었다고 말합니다. 이건 바로 strong attract / strong repel의 실제 작동입니다. Toby에게서 배운 것: 장기 할인율 0, 그리고 “이번 주 vs 10년” Kaz가 Toby Lütke에게서 배운 가장 큰 것은 장기 사고(long-term thinking) 입니다. 그는 금융의 discount rate 개념을 빌려 설명합니다. 대부분의 회사는 5년 뒤 결과 10년 뒤 결과 를 크게 할인해서 봅니다. 즉 먼 미래의 가치를 작게 쳐버립니다. 그런데 Toby는 거의 discount rate가 0인 사람처럼 행동한다고 말합니다. 즉 10년 뒤 결과를 오늘만큼 중요하게 봅니다. 이와 연결된 매우 강한 주장 하나가 더 있습니다. 회사를 운영할 때 유의미한 시간 단위는 “이번 주”와 “10년”이다. 그에 비해 분기(quarter)는 대체로 별 의미가 없다고 합니다. 왜냐하면 1주는 실험하고 shipped하고 학습하기에 충분히 길고 10년은 진짜 전략을 볼 수 있는 시간인데 12주는 그 어느 쪽에도 애매하다는 겁니다. 이건 그의 전반적인 운영관을 잘 보여줍니다. execution은 주 단위 vision은 10년 단위 분기 숫자에 집착하는 것은 중간관리형 사고 Shopify Logistics 철수: 좋은 회사는 “틀린 베팅”을 정직하게 접는다 Shopify가 물류를 직접 하겠다고 나섰을 때는 이유가 있었습니다. 당시에는 소상공인이 쓸 만한 물류 대안이 거의 없었습니다. 사실상 Amazon or bust에 가까웠습니다. 그런데 몇 년이 지나고 판이 바뀝니다. 좋은 물류 회사들이 생기고 Walmart, DHL 같은 플레이어들도 움직이며 Shopify가 직접 “콘크리트를 사서” 물류를 할 필요가 줄어듭니다. 여기서 Kaz의 핵심 철학이 나옵니다. 과거의 베팅이 틀렸다고 해서 과거의 자신을 죄책감으로 몰 필요는 없다. 당시 정보 기준으로는 최선의 선택이었을 수 있다. 하지만 새로운 사실을 배웠다면 새 결정을 해야 한다. 즉 그는 기업 전략을 “과거의 판단을 방어하는 일”이 아니라 “현재의 사실로 현재의 결정을 다시 하는 일”로 봅니다. 그리고 이 결정이 빨랐다는 점도 중요합니다. 인터뷰에 따르면 철수 결정은 대략 3~4주 수준의 짧은 기간 안에 내려졌습니다. 그는 내부적으로 엄청난 정치 싸움이 있었다기보다, Shopify는 “안 되는 걸 발견하고도 스스로에게 정직할 수 있는 회사”라고 설명합니다. 이건 굉장히 좋은 조직 문화 정의입니다. 회사는 리더의 exoskeleton이다 Kaz가 던진 아주 좋은 문장 중 하나가 이것입니다. 좋은 회사는 리더의 exoskeleton이다. 즉 회사는 리더의 가치관, 사고방식, 집착, 불안, 기준, 시간축을 외부 구조로 구현한 것에 가깝다는 뜻입니다. 그래서 그는 Shopify가 결국 Toby의 exoskeleton이라고 말합니다. 이 문장은 리더십 논의에서 꽤 중요합니다. 문화는 슬로건이 아니라 리더의 행동 패턴에서 생기고 회사의 사고방식은 리더의 사고방식이 외연화된 결과물이라는 뜻입니다. Opendoor는 “turnaround”가 아니라 “refounding”이다 비행기에서 심심해서 Opendoor를 파보기 시작 몇 주간 주말마다 회사와 제품을 해부 아내와의 대화가 거의 Opendoor 이야기만 됨 결국 Keith에게 “우리 전 재산을 넣어서라도 Opendoor를 비상장화하자”고 문자 그 계획은 성사되지 않았지만 얼마 뒤 CEO 제안이 와서 2주 반 정도 만에 Opendoor CEO가 됨 여기서 핵심은 단순 승진이 아니라 obsession-driven entry라는 점입니다. 그는 원래 “CEO가 되고 싶다”가 아니라, 이 문제를 꼭 풀고 싶다에서 시작합니다. 그리고 그가 이사회에 요구한 조건도 중요합니다. 기존 공동창업자/핵심 인물이 보드에 있어야 한다 한동안 “겉으로 어떻게 보이는지”는 신경 쓰지 말아야 한다 자신은 caretaker가 아니라 builder다 즉 그는 처음부터 정상화 관리자가 아니라 재창업 CEO로 들어간 것입니다.

“지위를 좇지 말고, 기본값을 깨고, 회사를 다시 창업하듯 운영하라” 행복을 쫓지 말고, 맡은 것을 더 낫게 만드는 사람(steward)이 되라. 기본값은 그냥 안 깨진다. 깨려면 끝까지 가야 한다. 창업은 멋져 보여서 하는 게 아니라, 안 하면 못 버텨서 하는 것이다. 좋은 CEO는 프로세스 관리자보다 결과 책임자에 가깝다. 회사는 리더의 exoskeleton이다. 좋은 회사는 잘 안 되는 걸 발견하면 빨리 정직해져야 한다. 회사가 죽음의 나선에 들어갔으면 거의 모든 것을 바꿔야 한다. AI-native 회사는 AI를 “권장”하는 회사가 아니라, AI를 기본값으로 평가하는 회사다. 직업(job)보다 커리어(career)를 살아라. Passion보다 service가 더 오래 간다. 가족은 성공의 장식이 아니라, 외로운 리더십을 감당하게 해주는 구조다. 지속적으로 큰 회사를 만든 건 대부분 코어 비즈니스 그 자체가 아니라, 코어 비즈니스의 first derivative였다. Union Pacific Railway는 철도 운송만으로 큰 게 아니라, 철도가 만들어낸 토지·주택 가치에서 더 큰 돈을 벌었다. Google은 검색이 핵심 기능이지만, 장기적으로 회사를 만든 건 광고라는 파생사업이었다. 즉, 훌륭한 회사는 “우리가 원래 하던 일” 하나만 잘해서 커지는 경우보다, 그 원래 일 때문에 생긴 주변 가치사슬을 흡수하면서 커지는 경우가 많다는 주장입니다. 이 관점은 Shopify 사례와도 연결됩니다. Shopify는 단순 쇼핑몰 SaaS가 아니라, 점점 더 payments, tax, billing, ads, merchant services 쪽으로 확장됐고, Kaz는 이걸 “merchant services company”에 가깝게 봅니다. 즉 “상점을 열어주는 소프트웨어”가 코어였다면, 파생사업은 “상인이 실제로 돈 벌고 운영하는 전 과정”이 된 셈입니다. 좋은 파생사업은 코어와 무관한 신사업이 아니다. 코어를 더 많이 이해할수록 자연스럽게 보이기 시작하는 인접 가치다. 그래서 “핵심을 더 깊게 이해하는 것”과 “파생사업을 찾는 것”이 연결된다. 그가 Shopify Shipping을 맡자마자 미국 우편법(US Postal Service Act)까지 읽은 이유와도 맞닿아 있습니다. 그는 늘 “시스템의 기원과 역사”를 먼저 이해하려고 합니다. 그래야 진짜 코어와 진짜 파생가치가 보인다는 식입니다. Status보다 Stewardship “Optimize for stewardship, not status.” 즉, “무엇이 될 것인가”보다 “무엇을 할 것인가”를 기준으로 살아라는 뜻입니다. 그는 어릴 때 “무엇을 하고 싶냐”는 질문에 늘 직함으로 답했다고 말합니다. 예를 들어 “CEO가 되고 싶다”, “이 직함을 갖고 싶다” 같은 식입니다. 그런데 친구가 “그게 무슨 뜻이냐?”고 되물으면서, 직함은 목표가 아니라 껍데기라는 걸 깨닫게 됩니다. 행복은 직접 목표로 삼으면 잘 안 잡힌다. 행복은 하나의 상태(state) 이기 때문이다. 반면 서비스, 기여, stewardship을 목표로 삼으면 결과적으로 훨씬 더 충만해질 가능성이 높다. CEO는 지위를 가진 사람이 아니라 결과를 떠맡는 사람 즉 stewardship의 가장 큰 형태를 수행하는 사람 Default를 깨려면 반쯤이 아니라 끝까지 가야 한다 그는 “삶에서도 소프트웨어처럼 기본값(default)의 힘이 과소평가된다”고 봅니다. 사람은 대부분 사회가 준 기본값 학교가 준 기본값 가족이 준 기본값 산업이 준 기본값 을 그냥 받아들입니다. 그리고 소프트웨어 사용자도 대부분 기본 설정을 바꾸지 않습니다. 그래서 그는 이렇게 말합니다. 기본값을 바꾸는 일은 우연히 일어나지 않는다. 기본값을 override하려면 의도적으로, 강하게, 끝까지 밀어야 한다. 이걸 설명하는 대표 사례가 PE 회사 11일 퇴사입니다. 그는 경영학을 전공했고 자연스럽게 private equity firm에 갔습니다. 그건 “경영대 학생의 매우 전형적인 default”였습니다. 그런데 11일 만에 그만둡니다. 왜냐하면 너무 빨리 깨달았기 때문입니다. “이건 내가 살고 싶은 삶이 아니다.” 그는 여기서 중요한 말을 합니다. 안전한 선택은 스스로 깨지지 않는다. 강하게 싸워서 벗어나야 한다. 즉, 기본값은 그냥 “조금 수정”하는 정도로는 안 바뀝니다. 기본값을 깨는 순간에는 full force가 필요합니다. 이 논리는 그가 Opendoor CEO가 된 것도 “커리어의 default가 아니었다”는 말과 이어집니다. 제품 관점에서의 보강 이 철학은 그의 제품관과도 연결됩니다. 그는 제품 만드는 사람들에게도 말합니다. 사용자에게 너무 자주 생각을 강요하는 default를 설계하면 사용자는 피곤해지고 결국 그 소프트웨어를 버린다. 즉 좋은 제품은 default 설계가 책임이고, 좋은 인생도 default override가 책임입니다. 개인적 default override: 종교, 기도, 그리고 “잘못된 경쟁”에서 빠져나오기 Kaz가 개인적으로 바꾼 대표 default는 종교 생활입니다. 그는 기술 업계, 특히 자신이 살아온 환경에서는 오히려 비종교적이 되는 것이 default였다고 말합니다. 그런데 그는 의도적으로 매일 성경을 읽고 매주 교회에 가고 기도하는 삶을 택합니다. 그 이유는 아주 실용적입니다. 그게 자신을 더 나은 인간으로 만들어준다고 믿기 때문입니다. 이건 종교적 정체성 자랑이 아니라, 일종의 정신적 operating system에 가깝습니다. 그가 이 부분에서 말하는 가장 중요한 통찰은 이겁니다. 머리가 좋은 사람, 경쟁심이 강한 사람, 성공 가능성이 큰 사람일수록 아무 생각 없이 살면 인생이 rat race가 되기 쉽다. 그러면 비교 대상은 끝이 없다. “항상 나보다 부자인 사람” “항상 더 대단한 사람”과의 경쟁이 시작된다. 그 결과 성공해도 우울해질 수 있다. 그는 “Elon은 항상 당신보다 더 부자일 것”이라고 말하며, 그 경쟁은 애초에 이길 수 없는 게임이라고 봅니다. 그래서 그는 인생에서 어떤 경주는 필요하지만, 잘못된 경주를 선택하면 반드시 불행해진다고 말합니다. 기도의 의미도 여기 있습니다. 내가 모든 걸 통제할 수 없다는 걸 인정하고 하루를 되돌아보고 경쟁과 통제의 착각에서 잠시 벗어나는 것 그는 명상과 기도의 차이를 묻는 질문에도 거의 비슷하다고 답합니다. 다만 자신은 “누군가가 함께 있는 명상”을 하는 셈이라고 표현합니다. 왜 이민자 창업자가 많은가: 리셋보다 “안전망 없음” “이민자는 새 나라에서 삶을 리셋하고 default를 다시 고를 수 있어서 성공하는 거 아니냐” Kaz는 그걸 너무 낭만적인 해석이라고 말합니다. 그의 답은 더 차갑습니다. 성공한 이민자 창업자는 종종 선택지가 없어서 그렇게 된다. 그는 이렇게 말합니다. 부모가 아는 사람이 없었다. 취업할 연결망이 없었다. 학비를 벌어야 했다. 아무도 나를 뽑아주지 않았다. 그래서 웹사이트를 만들고 돈을 버는 게 자연스러운 생존 방식이 됐다. 즉 이민자 창업 서사는 “새로운 자유”보다는 안전망이 없는 환경에서 생존하기 위한 비자발적 entrepreneurialism에 가깝습니다. 여기서 나온 인상적인 조언도 있습니다. 누군가 “나 커서 창업가 되고 싶어요”라고 말하면, Kaz는 오히려 보통 “하지 마라”고 답한다고 합니다. 왜냐하면 진짜 창업가라면 보통 이미 무언가 팔고 있고 이미 무언가 만들고 있고 이미 남이 시키지 않아도 그렇게 살고 있기 때문입니다. 그는 “창업은 멋있어 보여서 선택하면 거의 항상 실패한다”고까지 말합니다. 이유는 간단합니다. 고통스럽고, 외롭고, 생각보다 훨씬 더 아프기 때문입니다. Founder Mode란 무엇인가: 프로세스가 아니라 결과를 떠안는 것 Founder mode = 결과(outcomes)에 대한 책임을 끝까지 자신에게 남겨두는 태도 그는 이렇게 선을 긋습니다. 프로세스를 설계하는 사람은 따로 있을 수 있다. 하지만 결과를 배달(outcome delivery)하는 책임은 CEO에게 있다. 즉 그는 “내 일은 process design이 아니라 outcome delivery”라고 봅니다.

그는 올해 말쯤 많은 사람이 코드를 “텍스트 폭포”로 읽는 대신, 얼굴(face)과 대화하듯 프로그래밍하게 될 것이라고 봅니다. 즉 파워유저는 CLI나 agent cockpit을 쓰겠지만, 대다수는 읽기/조작 부담이 적은 시각적·대화형 UI를 쓰게 된다는 뜻입니다. 그 방향성은 지금도 보입니다. Claude Code 자체는 텍스트 중심이지만, 이미 그 위에 더 시각적인 wrapper/GUI를 올리려는 시도가 있고, Steve 본인도 “better UIs will come”이라고 썼습니다. 콘텐츠와 소프트웨어가 폭증하면, 그걸 만들기보다 찾고 고르고 조합하고 대신 써 주는 층이 커진다 앞으로 모두가 소프트웨어를 만들게 되면, 인터넷 초창기에 검색엔진이 필요해졌듯이, 이제는 AI가 만든 수많은 툴·콘텐츠·경험을 찾아 주는 agent가 필요해진다고 봅니다. Anthropic도 orchestrator-workers가 특히 잘 맞는 예로 여러 소스에서 정보를 모아 분석하는 search tasks를 들고 있고, 즉 “무엇을 만들 것인가” 못지않게 “무엇을 찾아서 쓸 것인가”가 큰 시장이 됩니다. 두 번째 큰 기회: 추천·큐레이션 agent Steve의 논리는 이렇습니다. 창작과 생성 비용이 급락하면, 희소한 것은 “콘텐츠”가 아니라 주의(attention)와 선택(selectivity)가 됩니다. 그래서 앞으로 중요한 건 단순 검색 결과가 아니라, 나를 잘 이해해서 내가 좋아할 것, 내가 필요할 것, 지금 시점에 맞는 것을 먼저 골라 주는 agent입니다. 이건 전통적 추천 시스템보다 더 넓습니다. 소프트웨어 추천, 워크플로 추천, 콘텐츠 추천, 개인화된 경험 라우팅까지 포함합니다. 결국 agent는 “답변 생성기”보다 개인화된 선택 엔진이 됩니다. 개인 software agent 이게 Steve가 보는 가장 파괴적인 변화입니다. 지금까지 bespoke software는 엔지니어의 특권이었는데, 앞으로는 비개발자도 자기용 앱과 워크플로를 만들게 됩니다. 그는 공개적으로 “everyone will want bespoke software”라고 보고 있고, OpenAI도 에이전트는 API가 있는 시스템은 API로, API가 없는 레거시는 computer-use로 UI를 직접 다루며 작업할 수 있다고 설명합니다. 이 말은 곧, 기존 SaaS가 제공하는 획일적 UI를 사람이 직접 클릭하는 대신, 내 agent가 나 대신 낡은 SaaS와 상호작용하는 시대가 열린다는 뜻입니다. agent용 빌딩블록 그는 앞으로 비개발자와 에이전트가 뭔가를 만들려면, 그 위에 신뢰 가능한 building blocks가 필요하다고 봅니다. 저장소, 상태관리, 권한, 결제, 검색, 로그, 규정 준수, 유지보수 API 같은 것들입니다. 실제 공식 가이드들도 agents는 결국 도구와 API 위에서 작동한다고 설명하고, observability/eval/guardrail 같은 인프라도 빠르게 기본 스택이 되어 가고 있습니다. 그래서 “agent app”만 기회가 아니라, agent가 좋아하는 infra도 큰 기회입니다. https://youtu.be/aFsAOu2bgFk?si=bsvwTmf4fRmGEond

개발에 진심이었던 사람중에 AI 발전을 보고 개발자의 정체성이 바뀜을 인정하고 Agentic coding에서 흥미로운 실험(Gas town-클로드 코드 팀 에잉전트에 영감을 줬다고)을 하고 있는 Yolo 빌더 Steve. 올해 말 상당히 많은 부분이 실현될듯. 왜 AI 생산성이 바로 제품 결과로 안 보이냐? 첫 번째 이유: 기업은 “비결정성”을 정말 싫어한다 AI는 본질적으로 비결정적이라 같은 목표를 줘도 매번 똑같이 움직이지 않고, 그래서 기업은 AI를 기존 고객-facing 시스템이나 핵심 운영 시스템에 바로 꽂아 넣기를 꺼린다는 겁니다. 사람도 틀리지만, 기업은 “사람이 틀리는 것”과 “소프트웨어가 틀리는 것”을 다르게 받아들입니다. 그래서 개인은 이미 체감상 엄청 빨라졌는데, 조직 차원의 제품 변화는 훨씬 천천히 드러납니다. 이 해석은 최근 엔터프라이즈 AI 운영 문서들과도 맞닿아 있습니다. OpenAI는 “모든 엔터프라이즈가 AI를 도입하고 싶지만 동시에 잘못 배포할까 두려워한다”고 쓰고, Anthropic은 에이전트는 유용한 만큼 평가가 어려워서, 평가 체계가 없으면 문제를 프로덕션에서 뒤늦게 잡는 “reactive loop”에 빠진다고 설명합니다. 두 번째 이유: 생산성 증가는 먼저 “내부 효율”로 나타나고, “새 제품”으로는 늦게 나타난다 Steve는 바깥에서 “왜 앱이 갑자기 10배 좋아지지 않았지?”라고 느끼는 이유가, 기업 안에서 생긴 AI 효과가 먼저 마진, 내부 운영 속도, 지원 업무, 반복 업무에 숨어 들어가기 때문이라고 봅니다. 실제 조사도 비슷합니다. Deloitte는 현재 기업들이 AI로 가장 많이 얻는 효과가 생산성과 효율 향상(66%)이라고 보고하지만, 제품/서비스 개선과 혁신(20%), 매출 증가(20%)는 훨씬 낮다고 봅니다. McKinsey도 AI 사용은 넓게 퍼졌지만, 아직 기업 전체 EBIT 영향을 봤다고 답한 비율은 **39%**에 그쳤고, 대부분 조직은 여전히 실험·파일럿에서 스케일 단계로 넘어가는 중이라고 봤습니다. 세 번째 이유: 큰 회사는 AI 생산성을 “흡수”하지 못한다 문제가 모델 성능이 아니라, 조직이 그 생산성을 삼켜서 제품으로 바꾸는 능력이라는 겁니다. 엔지니어는 빨라졌는데, downstream에서 디자인 리뷰, 보안, 법무, 컴플라이언스, 승인, 릴리즈 프로세스가 병목이 되면 바깥에서 보이는 제품 속도는 거의 안 바뀝니다. 그래서 그는 “우리가 큰 회사들을 보면서 왜 아무 것도 안 나오지? 하고 있는데, 사실은 이미 죽어 있는 회사들을 보고 있는 것일 수도 있다”고 말합니다. TeamDay의 요약도 같은 포인트를 짚는데, 큰 회사는 엔지니어가 덜 생산적인 게 아니라 조직이 그 출력(output)을 흡수하지 못한다는 해석입니다. McKinsey 역시 고성과 조직과 아닌 조직을 가르는 요소로 workflow redesign과 human validation process를 꼽았습니다. 네 번째 이유: 그래서 큰 회사 안에서는 “정체”, 바깥에서는 “폭발”이 동시에 일어난다 큰 회사는 AI 생산성이 올라가도 제품 변화가 안 보이고, 반대로 2명, 5명, 20명짜리 AI-native 팀은 그 생산성을 거의 바로 제품에 반영합니다. 그래서 혁신은 내부에서 균등하게 퍼지기보다 가장자리(edge)에서 먼저 폭발합니다. 그래서 “기업의 비결정성을 해결하는 솔루션”이 유망하냐? 제 답은 예스인데, framing이 중요합니다. 정확히 말하면 유망한 건 “비결정성을 없애는 솔루션”이 아니라, “비결정성을 통제 가능한 운영 문제로 바꾸는 솔루션”입니다. 즉 엔터프라이즈는 “AI를 deterministic하게 만들어 주세요”를 사는 게 아니라, 아래를 삽니다. 어떤 입력/출력/툴 사용이 허용되는지 정하는 guardrails 에이전트가 실제로 잘 작동하는지 점검하는 evals 어느 단계에서 왜 잘못됐는지 보여주는 tracing / observability 사람이 어디에서 승인하고 개입해야 하는지 정하는 human-in-the-loop 나중에 감사 가능한 audit trail / policy / validation 개인 개발자의 “코딩 공장”이 기업을 바꿀까? 이것도 예스입니다. 다만 다른 시간축의 이야기입니다. 단기(가까운 돈): 엔터프라이즈의 두려움을 줄여 주는 control/governance/evals 계층 중기~장기(더 큰 upside): 작은 AI-native 팀이 기존 SaaS/기존 내부툴을 바깥에서부터 갈아엎는 것 저는 둘 중 하나만 맞는 게 아니라, 둘 다 맞고 순서가 다르다고 봅니다. 엔터프라이즈는 내부적으로는 guardrails·evals·audit 없이 못 갑니다. 하지만 시장 전체는 결국 작은 팀들이 더 빠르게 제품을 만들어 외부 경쟁 압력으로 큰 회사를 바꾸게 될 가능성이 큽니다. “향후 새로운 IDE”는 정확히 어떤 모습인가? 2-1. 코드 편집기에서 “에이전트 관제실”로 바뀐다 Gas Town은 “2026년 IDE의 새로운 형태”이고, 여러 Claude Code 인스턴스를 돌릴 때 “누가 뭘 하고 있는지 추적하기 어려운” 문제를 대신 처리해 준다고 말합니다. 즉 새 IDE의 핵심은 텍스트 편집이 아니라 에이전트 상태 관리입니다. 1번 축: 대화형 인터페이스 새 IDE는 code-first가 아니라 conversation-first입니다. Steve의 단계 구분에서도 초반엔 IDE 안 사이드바 에이전트, 이후엔 에이전트가 화면을 점점 더 차지하고, 나중에는 아예 CLI/멀티에이전트로 넘어갑니다. 즉 코드는 점점 “직접 쓰는 것”이 아니라 diff를 확인하거나, 정말 필요할 때만 내려가 보는 결과물이 됩니다. 그의 글에서도 “당신은 Product Manager이고, Gas Town은 Idea Compiler”라고까지 표현합니다. 2번 축: 에이전트 모니터링과 스티어링 새 IDE에서 인간의 역할은 “타이핑”보다 모니터링하고 방향을 틀어 주는 것에 가깝습니다. Anthropic의 Claude Code agent teams 문서를 보면, 한 세션이 team lead가 되어 작업을 나누고, 각 teammate는 독립 context에서 일하며, 사용자는 중간에 각 에이전트와 직접 상호작용할 수 있습니다. 문서도 “monitor and steer”를 best practice로 강조합니다. Steve가 말한 미래 IDE는 정확히 이런 류의 fleet management UI에 가깝습니다. 3번 축: 작업 orchestration Anthropic은 병렬화(parallelization)와 orchestrator-workers 패턴을 공식적으로 설명하면서, 복잡한 코딩 변경이나 멀티소스 검색은 중앙 orchestrator가 태스크를 쪼개서 worker에게 맡기고 합치는 방식이 잘 맞는다고 적습니다. OpenAI도 manager-agent와 decentralized multi-agent 패턴을 공식 가이드에 넣었습니다. 즉 새 IDE는 단일 에디터가 아니라 작업 분해, 위임, 합성, 품질 게이트가 들어간 운영체제가 됩니다. Steve의 맥락을 최대한 풀어 쓰면, 미래 IDE는 대략 이런 모습입니다. 가운데에는 대화창이 있고 옆에는 에이전트 목록이 있으며 각 에이전트가 지금 어느 파일/태스크를 만지는지 보이고 충돌, 중복 작업, 막힌 태스크를 사람이 개입해서 재지시하고 마지막에 코드 diff를 보는 건 “주 작업”이 아니라 “최종 확인”이 됩니다. 여기에 더해 실전에서는 아래 기능이 붙을 가능성이 높습니다. trace / eval / replay merge queue policy / quality gates context compaction / summarization file ownership / conflict avoidance token burn / cost view 일반 사용자용 최종 형태는 더 “사람 같은 인터페이스”일 수 있다

즉 소프트웨어 벤더가 파는 것은 단순한 코드 덩어리가 아니다. 그들은 제품만 파는 것이 아니라, 배포, 신뢰, 표준화, 지원, 구매 가능성, 운영 안정성을 함께 판다. 그래서 구현의 병목이 약해지는 것과, 소프트웨어 회사의 경쟁우위가 모두 사라지는 것은 같은 말이 아니다. 더 정확히 말하면 이렇다. 일부 카테고리에선 확실히 압박이 커질 수 있다 특히 좁고 독립적이며 커스터마이즈가 쉬운 워크플로에선 대체가 빨라질 수 있다 하지만 시스템 오브 레코드, 규제 산업, 하드웨어 결합형 소프트웨어, 강한 배포력을 가진 제품군은 훨씬 더 오래 방어될 수 있다 즉 지금은 “소프트웨어의 종말”이라기보다, 어떤 소프트웨어는 약해지고 어떤 control point는 오히려 더 강해지는 재편의 시기에 가깝다. 6. 데모와 실제 운영 가능한 소프트웨어는 다르다 지금 시장의 또 다른 착시는, 인상적인 데모와 실제 운영 가능한 제품을 혼동하는 것이다. 짧은 데모는 놀랍다. 실제로 AI는 이제 너무 쉽게 무언가를 “되는 것처럼” 보이게 만든다. 하지만 데모가 된다는 것과, 복잡한 조직 안에서 안정적으로 유지되고 지원되며 책임질 수 있는 시스템이라는 것은 전혀 다르다. 이 간극을 무시하면, 현재의 가능성을 미래의 확정으로 오해하게 된다. 그래서 지금 필요한 태도는 두 극단을 모두 피하는 것이다. “별거 아니다”도 틀리고 “이미 다 끝났다”도 틀리다 지금은 실제 변화가 크지만, 동시에 과장도 큰 시기다. 미래를 너무 빨리 현재 완료형으로 말하면 안 된다. 7. 기술은 사람 전체를 바로 대체하기보다, 일의 구성 요소를 재배치한다 그래서 나는 “개발자는 사라질까?” 같은 질문보다 이런 질문이 더 낫다고 본다. 어떤 하위 업무가 자동화되는가 어떤 판단이 더 중요해지는가 어떤 수준의 사람에게 레버리지가 몰리는가 어떤 역할은 사라지기보다 더 상위의 책임으로 이동하는가 기술은 대체로 사람을 통째로 없애기보다, 업무를 재배치하는 방식으로 작동한다. AI도 그럴 가능성이 크다. 다만 여기에는 경제적 변화뿐 아니라 정체성의 변화도 있다. 어떤 엔지니어에게 코드는 단지 수단이 아니라 craft이고, 미학이고, 자부심이다. 반면 어떤 사람에겐 코드는 제품을 만들기 위한 utility다. AI가 구현의 상당 부분을 흡수할수록, 이 둘의 체감은 크게 달라질 수 있다. 그래서 변화의 충격은 단지 생산성 문제만이 아니다. 일의 의미, 숙련의 의미, 엔지니어링 정체성 자체가 재조정되는 시기일 수도 있다. 8. 결국 앞으로 더 중요해질 것은 무엇인가 정리하면, 내가 지금 가장 중요하게 보는 건 세 가지다. 첫째, AI는 코드를 더 빨리 쓰는 도구인 동시에, 가치가 이동하는 방향을 바꾸는 기술일 수 있다. 구현의 일부가 싸질수록 가치의 중심은 설계, 검증, 유통, 신뢰, 데이터, 사용자 관계 쪽으로 이동한다. 둘째, 생산성 혁명은 모델 성능만으로 오지 않는다. 인간-에이전트-조직의 작업 구조를 다시 설계해야 한다. 스펙, 검토, 승인, 책임, 운영이 같이 바뀌어야 한다. 셋째, 공급이 폭증할수록 희소해지는 것은 attention이다. 시장에서의 attention, distribution, trust뿐 아니라 조직 내부에서의 review, understanding, ownership attention도 핵심 병목이 된다. 그래서 앞으로의 중요한 질문은 더 이상 단순히 “AI가 코드를 얼마나 빨리 써주나?”가 아니다. 오히려 이 질문들이 더 중요해진다. 어떤 문제를 풀 가치가 있는가 어떤 흐름으로 인간과 에이전트를 나눌 것인가 누가 결과를 검증하고 책임질 것인가 어떻게 코드베이스의 이해 가능성을 유지할 것인가 어떻게 유통과 신뢰를 쌓을 것인가 어떤 control point를 가질 것인가 내 결론은 이렇다. AI 시대에 중요한 것은 누가 더 빨리 코드를 뽑느냐가 아니라, 누가 더 좋은 문제를 고르고, 더 나은 구조로 인간과 에이전트를 조직하고, 더 강한 검증·유통·신뢰의 레이어를 쌓느냐일 가능성이 크다. 코드의 가격이 내려갈수록, 오히려 그 위와 아래 레이어의 가치가 커진다. 그리고 지금 진짜로 시작되고 있는 변화는, 아마 바로 그 지점에 있다. https://x.com/jiayuan_jy/status/2030346105607823792

AI 시대, 정말 바뀌는 것은 “코드를 더 빨리 쓰는 일”이 아니라 가치와 병목의 위치다 요즘 AI를 둘러싼 이야기에는 유난히 극단적인 문장이 많다. “코딩은 끝났다.” “이제 누구나 소프트웨어를 만든다.” “SaaS는 죽는다.” “5명이서 대기업을 이긴다.” 이런 말들에는 분명 진실의 조각이 있다. 실제로 AI는 이미 소프트웨어 생산 방식을 크게 바꾸고 있다. 최전선에 있는 사람들 중 일부는 몇 달 전과 지금의 작업 방식이 완전히 다르다고 느낄 정도다. 하지만 동시에, 지금 시장에는 과장도 많다. 특히 소규모 기술팀의 행동을 전체 산업, 더 나아가 대기업 현실에 그대로 투영하는 경우가 많다. 그래서 지금 중요한 질문은 “AI가 코딩을 얼마나 더 빨리 해주나?”가 아니다. 더 중요한 질문은 이것이다. 핵심 기술의 가격이 급락할 때, 가치가 어디로 이동하는가? 그리고 생산이 풍부해질 때, 병목은 어디로 옮겨가는가? 내가 보기엔 지금 일어나는 변화는 이 두 질문으로 보는 것이 가장 정확하다. 1. 핵심 기술이 싸지면, 가치가 사라지는 게 아니라 다른 레이어로 이동한다 이 패턴은 AI만의 이야기가 아니다. 역사적으로 반복되어 온 구조다. 가장 익숙한 사례는 인쇄술이다. 인쇄기가 등장하면서 지식을 복제하는 비용은 급격히 떨어졌다. 책의 수는 폭증했고 가격은 내려갔다. 하지만 진짜 중요한 변화는 단순히 책이 많아진 것이 아니었다. 더 중요한 건 가치의 중심이 이동했다는 점이다. 손으로 베끼는 능력 자체는 훨씬 덜 중요해졌고, 대신 저작, 편집, 출판, 유통, 큐레이션 같은 레이어가 더 중요해졌다. 인쇄술은 단순한 비용 절감 기술이 아니라, 지식과 권력, 유통 구조 전체를 재편한 기술이었다. 그리고 그 결과는 처음부터 모두 예측 가능하지도 않았다. 종교개혁, 과학 지식의 확산, 지역 언어 기반 정체성의 강화 같은 변화는 “책을 더 싸게 찍을 수 있다”는 수준의 설명으로는 충분히 포착되지 않는다. AI 코딩도 비슷한 시선으로 볼 필요가 있다. 코드를 쓰는 행위 자체가 점점 싸지고 쉬워질수록, 가치의 중심은 자연스럽게 코드 작성 그 자체에서 다른 곳으로 이동한다. 예를 들어: 어떤 문제를 풀지 선택하는 능력 시스템을 어떻게 설계할지 판단하는 능력 결과물을 어떻게 검증할지 설계하는 능력 배포와 운영을 안정적으로 굴리는 능력 사용자 신뢰를 얻고 유지하는 능력 데이터와 사용자 관계를 쌓는 능력 이런 레이어들이 상대적으로 더 중요해진다. 중요한 건 여기서 “코드가 싸졌다”와 “소프트웨어 비즈니스가 쉬워졌다”는 전혀 같은 말이 아니라는 것이다. 구현 비용이 떨어질 수는 있다. 하지만 사업을 만드는 난도는 사라지지 않는다. 오히려 가치가 이동할 뿐이다. 그래서 AI 시대를 보는 더 정확한 표현은 이쪽에 가깝다. 코딩의 일부는 빠르게 상품화될 수 있다. 하지만 그 위와 아래 레이어의 중요성은 오히려 더 커질 수 있다. 2. 새 기술은 기존 일을 조금 더 빨리 만드는 수준에선 생산성 혁명을 만들지 못한다 이 지점은 전기 비유가 아주 잘 설명해준다. 전기가 공장에 들어왔다고 해서 생산성이 곧바로 폭발한 것은 아니었다. 초기에는 많은 공장이 그저 증기기관을 전기모터로 바꿨을 뿐, 공장 구조와 작업 방식은 그대로 유지했다. 그래서 생산성 향상은 제한적이었다. 이후 기계별 모터, 단층형 공장, 작업 흐름 중심의 재배치처럼 조직과 프로세스를 전기의 특성에 맞게 다시 설계했을 때 더 큰 변화가 나타났다. AI도 마찬가지다. 지금 많은 조직의 AI 활용은 여전히 이 단계에 머물러 있다. 문서 초안을 더 빨리 쓴다 요약을 더 빨리 만든다 코드를 더 빨리 짠다 리서치를 더 빨리 한다 이건 분명 유용하다. 하지만 이것만으로는 구조 변화가 아니다. 기존 프로세스 위에 빠른 도구를 얹는 것에 가깝다. 실제로 의미 있는 성과는 워크플로 자체를 다시 짤 때 더 잘 나온다. 누가 스펙을 정의하는지, 누가 에이전트 산출물을 검토하는지, 어떤 단계는 자동화하고 어떤 단계엔 인간 승인 게이트를 두는지, 실패했을 때 누가 책임을 지는지, 코드베이스 소유권과 이해를 어떻게 유지할지까지 다시 설계해야 한다. 즉 AI의 진짜 효과는 단순한 속도 향상이 아니라, 인간-에이전트-조직 간 역할 분배를 새로 짜는 것에서 나온다. 그래서 지금 가장 중요한 배움 중 하나는 이것이다. 도구 성능이 좋아졌다고 곧바로 생산성 혁명이 오는 것은 아니다. 조직, 프로세스, 검증 방식이 함께 바뀌어야 한다. 3. 공급이 폭증하면 희소해지는 것은 생산능력이 아니라 attention이다 AI 시대를 보며 많은 사람이 아직도 “무엇을 만들 수 있나?”에 초점을 둔다. 하지만 공급이 폭증하는 시기에 더 중요한 질문은 따로 있다. 누가 그것을 발견하는가? 누가 그것을 이해하는가? 누가 그것을 믿는가? 누가 그것을 계속 쓰는가? 인쇄술 이후에도 그랬고, 클라우드 이후에도 그랬다. 만들기가 쉬워지면 공급은 늘어난다. 공급이 늘어나면 희소한 것은 생산 그 자체가 아니라 attention, distribution, trust가 된다. 이건 시장 바깥에서만 일어나는 일이 아니다. AI 시대에는 이 attention scarcity가 조직 내부의 엔지니어링에서도 발생한다. 예전엔 코드 생산이 병목이었다면, 이제는 다른 병목이 생긴다. 생성된 코드를 누가 읽는가 누가 전체 맥락을 이해하는가 누가 품질을 보증하는가 누가 ownership을 가지는가 누가 나중에 이 시스템을 고칠 수 있는가 이 문제가 생각보다 훨씬 크다. 에이전트가 엄청난 양의 코드를 만들어내는데, 아무도 깊게 읽지 않고, 누구도 코드베이스 전체를 이해하지 못한다면 생산성 향상과 동시에 취약성도 함께 커질 수 있다. 흔히 말하는 “slop” 문제가 더 이상 랜딩페이지나 장난감 앱에서만 생기는 게 아니라, 실제 프로덕션 코드베이스 안으로 들어오는 것이다. 그래서 앞으로의 핵심 병목은 단지 “더 많은 코드를 생성하는 능력”이 아닐 수 있다. 오히려 더 중요한 문제는: 폭증하는 코드와 에이전트 산출물을 인간이 어떻게 감독하고, 이해하고, 관리할 것인가 에 가까워질 가능성이 크다. 이건 단순한 개발 생산성 문제가 아니라 attention to engineering, 즉 인간의 주의력과 이해 가능성의 문제다. 4. 그래서 진짜 기회는 코드 생성보다 “엔지니어링 관리 레이어”에 있을 수 있다 이 관점에서 보면, 앞으로 열릴 큰 카테고리는 단순한 코드 생성 툴만이 아닐 수 있다. 오히려 더 큰 기회는 이런 문제를 푸는 곳에 있을 수 있다. AI-native code review change-risk analysis ownership mapping test orchestration formal verification layer code provenance / lineage tracking agent-first engineering management large codebase understanding and memory 즉 “더 많은 코드를 뽑아주는 도구”보다, 그 코드의 품질, 이해, 책임, 리스크를 관리하는 도구가 중요해질 수 있다는 뜻이다. 이건 지금의 AI 열풍에서 종종 과소평가되는 지점이다. 사람들은 대체로 “얼마나 많이 만들 수 있나”에 집중하지만, 실제 조직의 고통은 종종 “이걸 누가 이해하고 책임지나”에서 생긴다. 5. 그렇다고 SaaS가 곧바로 다 죽는다는 뜻은 아니다 여기서 꼭 균형을 잡아야 한다. 지금 시장에는 일종의 “SaaS apocalypse” 서사가 있다. 5인 팀이 내부 툴을 빠르게 만든 사례를 보고, 곧 모든 엔터프라이즈 소프트웨어가 무너질 것처럼 말하는 식이다. 하지만 이건 지나치게 빠른 일반화일 가능성이 크다. 작은 기술 스타트업이 자기들만을 위한 bespoke internal tool을 빠르게 만드는 것과, 포춘 100 기업이 핵심 시스템을 통째로 교체하는 것은 완전히 다른 문제다. 대기업 현실에는 여전히 이런 것들이 있다. change management security and compliance procurement training support integration with existing systems accountability and auditability organizational consensus

지금 많은 전통 기업은 아직 1차에 있다. 각 직무에 copilot을 붙였지만, 구조는 그대로다. 그래서 헤드카운트는 계속 늘고, 성과 지표는 기대만큼 움직이지 않는다. 반면 AI-native 팀은 2차, 3차, 4차를 동시에 밟는다. 사람을 더 채용하기보다 compute와 token에 더 많은 비용을 쓰며, 문제 해결 루프 자체를 짧게 만든다. Shopify의 Tobi Lütke가 “더 많은 headcount를 요청하기 전에 왜 AI로 해결할 수 없는지 먼저 보여달라”고 요구한 것은 이 방향을 상징적으로 보여준다. 그는 AI 사용을 회사의 기본 기대치로 올리고, “자율형 AI 에이전트가 이미 팀의 일부라면 이 영역은 어떻게 달라질까?”를 묻도록 했다. 물론 여기서 흔한 반론도 있다. “앱 하나 빨리 만드는 것과, 실제 사용자 환경에서 유지·운영하는 것은 다르지 않나?” 맞는 말이다. AI가 아이디어에서 첫 구현까지의 거리를 거의 0에 가깝게 만들고 있는 것은 사실이지만, 취향, 우선순위, 리스크 판단, 책임은 여전히 남아 있다. 그래서 결론은 “전문가가 사라진다”가 아니라, 전문가의 역할이 바뀐다에 가깝다. 지능은 점점 commodity가 되지만, judgement와 accountability의 프리미엄은 오히려 더 커질 수 있다. Sequoia도 “오늘의 judgement는 내일의 intelligence가 된다”고 보지만, 그 사이를 건너는 데 필요한 것은 결국 데이터와 운영 경험이다. 먼저 autopilot으로 시장에 들어가 실제 운영 데이터를 쌓은 회사가 장기적으로 더 유리해지는 이유다. 결국 지금 우리가 보고 있는 변화는 단순한 툴 교체가 아니다. AI 시대의 큰 회사는 SaaS 회사처럼 보이는 회사가 아니라, 소프트웨어를 무기로 고객 대신 실제 일을 수행하는 회사가 될 가능성이 높다. 그리고 그 회사를 만드는 핵심 인재는, 한 박스 안의 전문가가 아니라 문제를 끝까지 소유하는 사람일 가능성이 높다. 그래서 이제 회사가 물어야 할 질문도, 개인이 물어야 할 질문도 달라진다. 회사는 “모든 팀에 AI를 붙였는가?”보다 “우리의 handoff를 얼마나 없앴는가?”를 물어야 한다. 개인은 “내 직무 스킬이 더 정교해졌는가?”보다 “나는 AI를 활용해 어디까지 직접 끝낼 수 있는가?”를 물어야 한다. 시장은 “어떤 툴이 더 똑똑한가?”보다 “누가 툴이 아니라 결과를 파는가?”를 보게 될 것이다. 포드의 조립라인은 1913년에는 천재적인 해법이었다. 역할 사이의 저항이 실제로 존재했기 때문이다. 하지만 그 저항은 빠르게 사라지고 있다. 그리고 그 사실을 조직도에 반영하지 못한 회사의 낭비가, 누군가에게는 가장 큰 기회가 된다.

AI 시대, 회사는 더 이상 ‘직무’를 채용하지 않는다 툴의 시대에서 결과의 시대로, 전문가의 시대에서 오너의 시대로 한동안 우리는 AI를 “개인의 생산성을 높여주는 도구”로 이해해왔다. 개발자는 코드를 더 빨리 쓰고, 디자이너는 시안을 더 빨리 만들고, 마케터는 카피를 더 빨리 뽑는다. 이 관점은 틀리진 않다. 다만 이제는 너무 약하다. 지금 벌어지는 변화의 본질은, 사람이 조금 더 빨라지는 데 있지 않다. 회사가 일을 나누는 방식 자체가 무너지고 있다는 데 있다. 예전의 조직 구조는 포드의 조립라인처럼 설계됐다. 한 사람은 기획하고, 다른 사람은 디자인하고, 또 다른 사람은 구현하고, 마지막 사람이 테스트한다. 이 구조는 한때 매우 합리적이었다. 역할 사이를 넘는 비용이 실제로 컸기 때문이다. 디자이너가 바로 제품을 만들 수 없었고, 엔지니어가 바로 마케팅을 집행할 수 없었다. 그래서 조직은 전문성을 기준으로 분업됐고, 회사는 수많은 handoff 위에 세워졌다. 소프트웨어 회사들도 크게 다르지 않았다. PM이 spec을 쓰고, 디자이너가 화면을 만들고, 엔지니어가 구현하고, QA가 검수하고, 마케팅이 런칭했다. Agile은 waterfall을 sprint로 바꿨지만, handoff 자체를 없애진 못했다. 속도는 조금 빨라졌지만, 구조는 그대로였다. 그런데 AI가 이 전제를 흔들고 있다. 역할 사이의 기술적 간극이 몇 달 사이 급격히 줄어들었다. 이제 고객과 대화한 사람이 직접 프로토타입을 만들고, 필요한 랜딩 페이지를 만들고, AI를 이용해 코드를 짜고, 배포까지 밀어붙이는 일이 더 이상 예외가 아니다. Anthropic은 2026년 에이전트형 코딩 트렌드 보고서에서 비개발 직군이 엔지니어링 도움 없이 툴을 만들고, 문제를 가장 잘 이해하는 도메인 전문가가 직접 해결을 시작하는 흐름을 짚었다. 문제는 기술은 바뀌었는데, 조직도는 그대로라는 점이다. 많은 기업이 AI 도입에 성공했다고 말한다. 팀마다 copilot을 붙였고, 대시보드로 활용률도 추적한다. 하지만 조직 구조가 그대로라면 바뀌는 것은 각자의 국소 생산성뿐이다. PM과 디자인 사이의 의존성도 그대로, 디자인과 엔지니어링 사이의 리뷰 루프도 그대로, “모두가 컨텍스트를 갖기 위해” 여덟 명이 들어가는 회의도 그대로다. 바뀐 것은 도구이지, 운영 체계가 아니다. 그래서 지금의 핵심 질문은 “누가 AI를 잘 쓰는가?”가 아니라, “누가 AI를 전제로 조직과 업무를 다시 설계하는가?”가 된다. Copilot은 툴을 팔고, autopilot은 일을 판다. 그리고 소프트웨어 엔지니어링은 “intelligence work”의 비중이 높기 때문에 자동화의 임계점을 가장 먼저 넘었다고 본다. 실제로 Sequoia는 소프트웨어 엔지니어링이 직군 전반의 AI 툴 사용에서 절반을 넘는 비중을 차지한다고 설명했고, Anthropic 역시 공개 API 툴 호출의 거의 50%가 소프트웨어 엔지니어링에 집중돼 있다고 밝혔다. 다른 영역은 아직 몇 퍼센트 수준에 머문다. 이 데이터가 말하는 것은 단순히 “개발자가 AI를 많이 쓴다”가 아니다. 지능 중심의 업무가 먼저 자동화되고 있고, 그다음 기회는 아직 덜 건드려진 다른 산업에 있다는 뜻이다. 이 맥락에서 “대부분의 일은 intelligence와 judgement로 나뉜다”는 구분이 중요해진다. intelligence는 복잡해도 결국 규칙 기반으로 풀 수 있는 영역이다. 스펙을 코드로 옮기고, 테스트하고, 디버깅하고, 문서를 작성하고, 양식을 채우는 일들이 여기에 가깝다. 반면 judgement는 경험, 맥락, 취향, 책임을 요구한다. 무엇을 먼저 만들지, 언제 출시할지, 어떤 리스크를 감수할지 같은 결정이 여기 속한다. Sequoia의 주장은 AI가 intelligence를 빠르게 흡수하고, judgement는 그 뒤를 따라온다는 것이다. 여기서 아주 큰 사업적 함의가 나온다. 만약 AI가 intelligence 영역을 먼저 대체한다면, 초기 승자는 “전문가를 더 생산적으로 만드는 도구”보다 고객이 원하는 결과를 직접 납품하는 서비스일 가능성이 높다. 회계팀용 AI 툴보다 “우리가 결산을 마무리 해드립니다”가 더 강력할 수 있고, 법무팀용 문서 도구보다 “우리가 NDA를 작성해드립니다”가 더 강할 수 있다. Sequoia는 이를 설명하며, 기업이 소프트웨어보다 실제 서비스와 노동에 훨씬 더 큰 예산을 쓴다고 지적한다. 그래서 copilot은 소프트웨어 예산을 차지하지만, autopilot은 서비스 예산 전체를 먹을 수 있다. 즉 AI의 다음 큰 파도는 더 좋은 SaaS 기능 몇 개가 아니라, 서비스업을 소프트웨어처럼 재편하는 것일 수 있다. 이때 가장 좋은 wedge는 어디일까. 정답은 대개 이미 외주화된 업무다. 고객이 이미 외부 업체에 맡겨도 된다고 받아들이고 있고, 대체 가능한 예산 라인이 존재하며, 애초에 툴이 아니라 deliverable을 사는 시장이기 때문이다. 그래서 “사람을 대체하겠다”보다 “원래 외주 주던 일을 더 빠르고 싸고 안정적으로 해주겠다”가 훨씬 마찰이 적다. 이건 지금 AI-native 서비스가 들어가기 좋은 진입점이기도 하다. 하지만 이 변화를 이해하려면 제품 전략만이 아니라, 인재상과 조직 구조도 함께 봐야 한다. 이제 많은 빠른 스타트업은 “PM만”, “마케터만”, “기획만” 뽑지 않는다. 그들은 tinkerer를 원한다. 아침에 고객과 얘기하고, 점심 전에 해결책을 만들고, 저녁 전에 배포할 수 있는 사람. 중요한 것은 직무의 이름이 아니라 문제를 시작부터 끝까지 쥘 수 있는가다. 이 변화는 단순한 감상이 아니다. 사람의 역할이 직접 일을 수행하는 것에서, 에이전트를 만들고 위임하고 관리하는 쪽으로 이동한다는 것이다. Microsoft는 이미 관리자들의 28%가 사람과 에이전트가 섞인 팀을 이끌 “AI workforce managers” 채용을 고려하고 있고, 32%는 에이전트를 설계·개발·최적화하는 specialists를 채용할 계획이라고 밝혔다. 또 향후 5년 안에 기업들이 business process redesign, multi-agent system 구축, agent training, agent management에 더 많이 관여할 것으로 예상했다. 이 지점에서 커리어의 축도 바뀐다. 과거에는 “나는 백엔드 개발자”, “나는 PM”, “나는 마케터” 같은 정체성이 커리어의 중심이었다. 앞으로는 더 본질적인 질문이 남는다. 이 사람은 문제를 직접 해결하는가, 아니면 handoff를 기다리는가? generalist vs specialist라는 오래된 논쟁도 사실 정확한 질문이 아니었다. 더 중요한 것은 ownership vs dependency다. 직무 경계 안에서만 움직이는 사람인지, 아니면 문제가 보이면 AI와 도구를 총동원해 직접 해결하는 사람인지가 훨씬 중요해졌다. 그래서 이제 높은 가치를 갖는 사람은 단순히 코드를 예쁘게 짜는 사람이 아니다. 컨텍스트를 오래 붙들고, 필요한 툴과 모델과 에이전트를 연결해, 실제 결과를 만드는 사람이다. Anthropic이 공개한 소프트웨어 개발 분석에서도 Claude Code는 일반 챗 인터페이스보다 훨씬 높은 자동화 성향을 보였다. Claude Code 대화의 79%가 자동화와 관련됐고, 최소 상호작용으로 작업을 위임하는 “directive” 패턴이나, 환경 피드백을 받아 자율 수행하는 “feedback loop” 패턴이 일반 대화형 사용보다 훨씬 높았다. 이건 AI 시대의 노동을 더 높은 추상화 단계로 올려보면 더 선명해진다. 전통적인 업무는 사람이 직접 수행한다. 그다음 단계는 AI를 활용해 업무를 수행하는 것이다. 그다음은 AI에게 업무를 가르쳐 대신 수행하게 하는 것이다. 그다음은 그렇게 일하는 AI를 관리하는 것이다. 그다음은 업무를 운영하는 AI 시스템 자체를 설계하는 것이다. 그리고 마지막은 AI 팀만이 할 수 있는 새로운 종류의 일을 만드는 것이다. 이걸 0차부터 5차까지의 이동이라고 볼 수 있다. 0차는 노동 제공자다. 1차는 AI를 잘 쓰는 개인이다. 2차는 AI에게 일을 위임하는 사람이다. 3차는 에이전트 팀을 관리하는 사람이다. 4차는 에이전트 시스템을 설계하는 사람이다. 5차는 그 시스템으로만 가능한 새로운 시장을 만드는 사람이다.

“세계적 수준의 Agentic Engineer가 되는 방법” • 좋은 결과를 내기 위해 최신 에이전트 툴링 스택이 꼭 필요한 것은 아니다. 최소한의 견고한 셋업과 강한 작업 프로세스부터 시작하라. • 사람들이 성과가 낮은 이유: 너무 많은 플러그인, 라이브러리, 시스템이 컨텍스트를 비대하게 만든다. 에이전트는 관련 없는 컨텍스트에 쉽게 주의를 빼앗겨 성능이 떨어질 수 있다. • 핵심 운영 원칙: 지시는 명확하고 구체적으로 작성하라. “인증 시스템을 만들어라” → 너무 광범위하며 불필요한 리서치 비용이 발생한다. “JWT 인증 + bcrypt-12 + refresh token rotation(7일)” → 범위를 좁히고 결과 품질을 높인다. 리서치와 구현 단계를 분리하라. 하나의 에이전트/작업에서 옵션을 조사하고 평가한다. 그 다음 새로운 컨텍스트에서 구현을 진행한다. 프롬프트에서 **아첨 편향(sycophancy bias)**을 피하라. 결과를 유도하는 프롬프트보다 중립적인 프롬프트가 더 잘 작동한다. • 예:“버그를 찾아라” vs “버그가 있다고 가정하지 말고 검토 후 발견 사항을 보고하라.” 더 좋은 검증 방법: 서로 다른 목표를 가진 여러 에이전트를 사용하라. 예:버그 탐지 에이전트 반증을 시도하는 adversarial 에이전트 판정하는 referee 에이전트 그리고 그들의 결과를 점수화하여 평가한다. • 완료 기준(completion criteria)은 반드시 명시적이어야 한다. 테스트 검증 아티팩트 (스크린샷, 체크 결과 등) 이를 {TASK}_CONTRACT.md 같은 문서에 정의하라. “완료됨(done)”이 주관적이어서는 안 된다. • 툴링에 대한 철학: 정말 가치 있는 기능은 결국 foundation 플랫폼에 흡수된다. (예: skills, memory, planning hooks 등) 따라서 모든 “새로운 것”을 쫓아다닐 필요는 없다. • 긴 세션은 컨텍스트 오염(context contamination) 때문에 방향이 흐트러질 수 있다. 그래서 다음을 선호하라: • 짧은 세션 • 명확한 계약 범위를 가진 작업 • 규칙과 스킬을 주기적으로 단순화하고 정리 https://x.com/systematicls/status/2028814227004395561?s=46&t=h5Byg6Wosg8MJb4pbPSDow

OpenClaw에서 얻은 두 가지 교훈: 1. 차별화된 AI 제품에 대한 소비자/프로슈머의 수요가 엄청나다. 2. 뛰어난 제품 감각과 탄탄한 엔지니어링 역량을 갖춘 소규모 팀은 원시 모델 지능 위에 빠르게 마법 같은 경험을 창출할 수 있다. 더욱 흥미로운 점은 원시 역량 곡선도 동시에 빠르게 상승하고 있다는 사실이다. 이는 제품 팀이 타고 있는 파도가 계속 커지고 있음을 의미한다. https://www.linkedin.com/posts/saurabh-gupta-1a54b15_two-takeaways-from-openclaw-1-theres-share-7435070163135275008-rom5?utm_source=share&utm_medium=member_ios&rcm=ACoAABqmkk8B31-f1cgLX5fNW16TpECDoRf4kWg

어느 학교를 나왔는지 어떤 회사를 다녔는지 -> 어떤 모델을 얼만큼 쓰고 있는지, 다루고 있는 AI Agent 숫자는 몇개인지, AI를 사용하는지, AI System을 설계하는지? 모델/ AI Agent를 고도화할 수 있는지, 기존에 사람들이 못 푼 문제를 AI로 풀 수 있는지?

일반적인 전통적 업무: 직접 일을 수행한다 1차 미분: AI를 활용해 업무를 수행한다 2차 미분: AI에게 업무를 가르쳐 대신 수행하게 한다 3차 미분: 업무를 수행하는 AI를 관리한다 4차 미분: 업무를 운영하는 AI 시스템을 설계한다 5차 미분: AI 팀만이 수행할 수 있는 새로운 업무를 창출한다 https://x.com/andrewchen

클로드 코드를 쓰시건 안쓰시건 그냥 보세요!! 그리고 모르면 에이아이한테 물어보면서 이해하고 경험하세요! https://youtu.be/EQ-Rnx-k-Ec?si=mceSOPHt6KmzRj5o

오케스트레이션은 더 어렵다. 리드 에이전트가 서브태스크를 나누고 자식 에이전트를 스포닝하는 것. 서로 다른 전문성의 에이전트 팀이 하나의 목표를 향해 협업하는 것. Beads, Gas Town, Claude Agent teams 같은 프로젝트가 이 공간을 탐색 중이다. 아직 초기 단계지만, 이것이 풀리면 하니스의 레버리지는 한 차원 더 올라간다. 하지만 이 미해결 과제들은 동시에 거대한 기회이기도 하다. 에이전트가 만드는 코드의 양이 폭발적으로 늘어나면서 "인간의 엔지니어링 주의력"을 확장하는 문제가 새로운 시장이 된다. AI 네이티브 테스팅, 형식 검증(formal verification), 자동 코드 리뷰 — 에이전트 출력의 품질을 보장하는 시스템의 가치가 함께 올라간다. 하니스는 인간의 판단력과 AI의 실행력이 만나는 인터페이스다. 인지 부하는 줄지 않는다. 코드를 읽는 부하가 하니스를 설계하는 부하로 바뀔 뿐이다. 다만 레버리지가 완전히 다르다. 코드 한 줄은 한 줄의 가치. 하니스 설계 한 시간은 수천 줄의 코드 품질을 결정한다. 문제를 명확히 정의하고, 그것을 풀기 위한 하니스를 설계하고, 자신만의 taste로 품질 기준을 세우는 것. 이 세 가지의 조합이 제품이 되는 시대다. Manus가 라스트마일을 잡은 건 모델이 좋아서가 아니다. Claude Code가 개발자의 선택이 된 건 Opus가 강력해서가 아니다. Ramp이 30% PR을 달성한 건 코드 생성 능력 때문이 아니다. 전부 하니스 때문이다. 소프트웨어 엔지니어링의 세 번째 패러다임 전환. 천공카드에서 키보드로, 에디터에서 클라우드로, 그리고 이제 — 코드에서 하니스로. 하니스가 새로운 소프트웨어 엔지니어링이다.

하니스가 새로운 소프트웨어 엔지니어링이다 하니스(Harness). AI 에이전트가 올바르게 작동하도록 제어하는 모든 시스템의 총합이다. 지시 문서, 검증 루프, 외부 통합, 스코어링, 지식 축적, 격리 환경, 메모리, 권한 설정 — 에이전트 출력의 품질을 결정하는 모든 것. 하니스가 왜 중요한가. Gemini 모델을 Claude Code의 하니스 위에서 돌리면 성능이 올라간다. 같은 Opus라도 하니스 없이 돌리면 성능이 떨어진다. 모델은 같은데 결과가 다르다. 모델이 아니라 하니스가 결과를 결정한다. 소프트웨어 엔지니어링의 세 번째 패러다임 전환이 진행 중이다. 천공카드에서 키보드로 — 물리적 제약에서 벗어났다. 로컬 에디터에서 클라우드로 — 배포와 확장의 혁명. 그리고 지금, 코드 작성에서 의미 전달로. 인간이 "무엇을" 정의하면 에이전트가 "어떻게"를 실행한다. 이 전환의 핵심에 하니스가 있다. 빌더에서 설계자로 이 전환은 엔지니어의 역할을 근본적으로 바꾼다. 코드를 직접 짜는 빌더에서, 시스템을 설계하는 설계자로. 두 가지 활동이 중심이 된다. Planning — 하고자 하는 바를 구체화하는 과정이다. 어떤 스펙으로 만들지, 어떤 가이드라인을 줄지. 구체적으로 작성할수록 AI와의 alignment가 명확해진다. "좋은 코드 짜줘"는 아무 의미 없다. 어떤 아키텍처 패턴으로, 어떤 에러 핸들링 전략으로, 어떤 수준의 테스트 커버리지로, 어떤 네이밍 컨벤션으로 — 이 수준의 구체성이 결과를 가른다. CLAUDE.md에 프로젝트의 원칙을 쓰고, 스펙 문서로 각 기능의 요구사항을 명시하고, 아키텍처 문서로 시스템의 경계를 정의하는 것. 이것이 새로운 "코딩"이다. Review — 결과물의 달성도를 평가하는 과정이다. 원하는 결과가 구체적일수록 스코어링 기준을 세울 수 있고, 체크리스트로 품질을 올릴 수 있다. 핵심은 이 과정에서 나의 감도, 암묵지, 평가 방식이 명시화된다는 것이다. 에이전트는 이 기준으로 품질을 개선한다. 내 머릿속에만 있던 "이건 아닌데"가 문서화되는 순간, 에이전트의 출력이 달라진다. "에러 메시지가 유저 친화적이지 않다"는 피드백을 "에러 메시지는 기술 용어 없이, 유저가 취할 수 있는 다음 행동을 반드시 포함해야 한다"로 바꾸는 것 — 이것이 암묵지의 명시화다. 결국 이 전체 과정이 하는 일은 두 가지다. 업무를 수행할 에이전트들의 스킬과 협업 방식을 구체화하고, 결과물에 대한 내 taste를 기준으로 만들어 에이전트가 학습하게 하는 것. 시간 배분이 뒤집힌다. 코드 작성 20%, 계획과 리뷰 80%. Dan Shipper(Every)의 말처럼 — "Plans are the new code." 왜 이렇게 되는가. 코드의 가치가 0에 수렴하기 때문이다. 에이전트가 만드는 코드의 양을 보라. Lablup은 50개 에이전트로 40일 만에 100만 줄을 생성했다. "코드를 잘 짜는 것"의 시장 가치는 빠르게 떨어지고 있다. 남는 건 무엇을 만들지 결정하는 능력, 그리고 그것을 올바르게 만드는 시스템을 설계하는 능력이다. 하지만 볼륨이 커질수록 위험도 커진다. AI Slop — 아무도 읽지 않고, 아무도 이해하지 못하는 코드가 코드베이스에 쌓이는 현상. 에이전트가 만든 코드를 사람이 검증하지 않으면 코드베이스는 빠르게 취약해진다. Planning과 Review가 중요한 이유가 여기에 있다. Planning으로 에이전트가 만들 코드의 방향을 통제하고, Review로 출력의 품질을 검증한다. 이 두 활동이 AI slop의 해독제다. 하니스의 구성요소 하니스는 단일 도구가 아니다. 시스템의 집합이다. 기본 요소들이 있다. 지시 문서(CLAUDE.md, Soul Documents) — 에이전트의 "헌법". 프로젝트의 원칙, 코딩 컨벤션, 금지 사항을 정의한다. 검증 루프(테스트, 린터, pre-commit hooks) — 에이전트가 스스로를 검증하는 메커니즘. 외부 통합(Sentry, Datadog, LaunchDarkly) — 에이전트가 개발자와 동일한 맥락을 이해하고 같은 제품을 사용할 수 있는 환경. 스코어링 체계 — 에이전트 출력의 품질을 정량화한다. 지식 축적(solutions DB, YAML 프론트매터) — 해결된 문제의 교훈이 축적되어 다음 사이클을 더 빠르게 만든다. 격리 환경(샌드박스, Docker) — 에이전트가 안전하게 실험할 수 있는 공간. 그리고 아직 확장 중인 영역이 있다. 메모리 관리(세션 간 맥락 유지), 권한과 환경 설정(에이전트에게 어디까지 허용할 것인가), 도구 사용 가이드(어떤 도구를 어떤 순서로, 어떤 상황에서 사용하게 할 것인가), 오케스트레이션(서브에이전트 스포닝, 에이전트 팀 위임과 검증). 이 요소들의 조합이 하니스의 품질을 결정하고, 하니스의 품질이 에이전트 출력의 품질을 결정한다. 제품들이 보여주는 하니스 철학 하니스 관점에서 보면, 지금 나오는 제품들은 각자 다른 철학으로 같은 문제를 풀고 있다. Manus는 긴 작업의 라스트마일 품질에 집중했다. 딥리서치, 엑셀 데이터 분석, PPT 작성 — 사람이 시작하면 지루하고, AI에게 맡기면 80%까지는 금방이지만 마지막 20%에서 무너지는 작업들. 대부분의 AI 도구가 "80%까지 빠르게"에 집중할 때, Manus의 하니스는 나머지 20%를 고객이 실제로 제출할 수 있는 수준까지 끌어올리는 데 맞춰져 있다. 이 라스트마일이 진짜 어렵고, 여기서 하니스의 차이가 드러난다. Claude Code는 로컬 퍼스트를 선택했다. 유저의 환경에서 시작하고, 길을 찾아주고, 선택지를 준다. 에이전트가 모든 걸 대신하는 게 아니라 인간과 함께 진화한다. CLAUDE.md, hooks, slash commands — 하니스 도구를 유저가 직접 설계하게 한 것이 핵심이다. 로컬에서 시작한 초기 결정이 탁월했다. 유저의 코드, 유저의 환경, 유저의 맥락 위에서 작동하기 때문에 하니스의 커스터마이징이 자연스럽다. Codex는 정반대다. "내가 다 알아서 할게." 완전 자율 지향. 인간의 개입을 최소화하고 에이전트가 독립적으로 작업을 완수한다. 하니스의 주도권이 유저가 아닌 시스템에 있다. OpenClaw는 개인 비서의 가능성을 보여줬다. 로컬에서, 가장 편한 인터페이스에서, 여러 앱을 실행해주는 경험. 코딩만이 아니라 일상 업무 전반을 에이전트가 처리할 수 있다. 올해 더 많은 사람들이 에이전트로 일상을 처리하면서 기존 앱을 직접 여는 시간이 줄어들 것이다. 기업들도 각자의 하니스를 설계했다. Ramp은 에이전트에게 자기 검증 능력을 줬다 — Sentry, Datadog, LaunchDarkly를 직접 연결한 closed-loop으로 PR이 인간에게 도달하기 전에 검증을 완료한다. PR의 30%가 에이전트에서 나온다. Uber는 생성 모델(Claude Sonnet)과 평가 모델(o4-mini)을 분리했다. 만드는 AI와 채점하는 AI가 다르다 — 자기 평가 편향을 구조적으로 차단. 주간 1,500시간 절약, 수정 반영률 65%로 인간 리뷰어(51%)를 넘었다. Every는 매 사이클의 교훈이 CLAUDE.md에 자동 축적되는 복리 구조를 만들었다 — 1인 팀이 5개 프로덕트를 운영한다. 사이클을 돌릴수록 시스템이 똑똑해진다. Lablup은 50개 에이전트로 40일 만에 100만 줄, 764 PR을 자동 처리했다. AI가 인간에게 "이 기술을 공부하세요"라고 학습 과제를 제시하는 역방향 지식 전이가 특히 인상적이다. 아직 풀리지 않은 과제들 솔직히 아직 부족한 게 많다. 메모리가 가장 큰 난제다. OpenClaw는 append-only markdown으로 메모리를 관리하는데, 세션이 길어지면 맥락을 잊는다. Manus는 세션 내 메모리가 뛰어나지만 세션 간 기억이 없다. Claude Code도 마찬가지. Hyperspell, Letta, Mem0, qmd, Supermemory — 수많은 팀이 이 문제를 풀고 있다. Markdown, SQLite, 벡터 DB, 그래프 DB — 어떤 조합이 맞는지 아직 아무도 모른다. 하니스의 가장 불안정한 레이어다. 긴 브라우저 세션과 도구 사용도 한계가 분명하다. 에이전트가 일정시간 넘게 웹을 탐색하면 맥락이 흐려지고, 도구 사용의 정확도가 떨어진다.

AI로 생산성이 향상되는 만큼 올바른 문제를 정의하고 가치를 줄 수 있는 취향이 중요해진다. 취향이 새로운 도구인 시대가 되었다. 폴그라함 아저씨가 20년 전 남긴 포스팅에 있는 디자인 원칙. https://x.com/paulg/status/2022604692178522562?s=46&t=h5Byg6Wosg8MJb4pbPSDow 취향: 세상을 만드는 이들의 실질적인 도구 많은 이들이 "취향은 주관적"이라고 말합니다. 어릴 적 형제와 싸울 때 부모님이 해주시던 "사람마다 좋아하는 게 다른 법이야"라는 말은 갈등을 멈추기엔 좋지만, 진실은 아닙니다. 어른들은 취향이 개인의 선택일 뿐이라고 가르치면서도, 동시에 박물관에 데려가 레오나르도 다 빈치가 왜 위대한 예술가인지 공부하라고 말하는 모순을 보입니다. 무언가를 설계하고 만드는 이들에게 취향(Taste)은 추상적인 개념이 아닙니다. MIT의 한 교수가 "단순히 기술이 좋은 학생이 아니라, 기술을 사용해 아름다운 것을 디자인할 수 있는 취향을 가진 학생"을 원하는 것처럼, 취향은 곧 '무엇이 좋은 것인지 알아보는 능력'입니다. 아름다움이 실재한다면 우리는 그것을 인식할 수 있어야 하며, 좋은 것을 만들기 위해서는 반드시 좋은 취향을 가져야 합니다. 즉, 취향은 "어떻게 하면 좋은 물건을 만들 수 있는가?"라는 질문에 답하기 위한 매우 실용적인 도구입니다. 🎨 좋은 디자인을 정의하는 10가지 원칙 1. 단순함 (Simple) 좋은 디자인은 무엇보다 단순합니다. 이는 단순히 장식을 없애는 것이 아니라 본질적인 구조에 집중하는 것을 의미합니다. 수학에서 가장 우아한 증명은 가장 짧은 증명인 경우가 많으며, 글쓰기에서도 하고 싶은 말을 군더더기 없이 짧게 표현할 때 가장 강력한 힘을 발휘합니다. 불필요한 장식은 대개 내용의 빈약함을 감추기 위한 수단으로 사용될 뿐입니다. 2. 시대를 초월함 (Timeless) 유행에 민감한 것은 곧 유행이 지나면 촌스러워질 것임을 예고하는 것과 같습니다. 시간을 이겨내는 디자인을 만들고 싶다면 과거의 거장들에게도 인정받을 수 있을 만한 본질을 추구해야 합니다. 예를 들어 독일의 예술가 뒤러(Dürer)의 판화는 수백 년이 지난 지금도 완벽한 가치를 인정받고 있습니다. 미래 세대에게 영감을 주고 싶다면, 지금 이 순간의 패션보다는 영원히 변하지 않을 미적 기준을 지향해야 합니다. 3. 올바른 문제 해결 (Solves the Right Problem) 아무리 아름다워도 문제를 해결하지 못하는 디자인은 실패한 것입니다. 스토브의 화구는 사각형으로 배치되어 있는데 조절 다이얼만 일렬로 늘어놓는다면, 사용자는 매번 어떤 다이얼이 어떤 화구를 켜는지 고민해야 합니다. 다이얼을 화구의 위치와 똑같이 사각형으로 배치하는 것처럼, 인간의 직관에 맞게 문제를 정의하고 해결하는 것이 좋은 디자인의 핵심입니다. 4. 암시적임 (Suggestive) 모든 것을 일일이 설명하기보다 사용자가 상상하고 개입할 여지를 남겨두는 디자인이 더 매력적입니다. 제인 오스틴의 소설은 인물의 외모를 길게 묘사하지 않음으로써 독자가 각자의 머릿속에서 가장 완벽한 인물을 그리게 만듭니다. 소프트웨어 역시 사용자가 마치 레고(Lego) 블록처럼 기본 요소를 조합해 원하는 결과를 만들어낼 수 있도록 유연한 가능성을 열어주어야 합니다. 5. 약간의 유머 (Slightly Funny) 위대한 디자인에는 종종 지적인 유머가 섞여 있습니다. 이는 창작자가 자신이 다루는 대상보다 우위에 있다는 자신감의 표현이기도 합니다. 괴델의 '불완전성 정리'가 수학자들에게 지적인 장난처럼 느껴지는 쾌감을 주는 것이나, 포르쉐 911의 독특하고 약간은 기묘한 뒷모습이 시대를 넘어 사랑받는 것은 디자인 속에 깃든 이러한 여유 덕분입니다. 6. 어려움 (Hard) 어려운 도전은 디자인을 정교하게 만듭니다. 나무를 그릴 때는 가지가 조금 휘어도 아무도 모르지만, 인간의 얼굴을 그릴 때는 눈동자의 위치가 조금만 어긋나도 사람들은 금방 알아챕니다. 이처럼 엄격한 기준이 요구되는 어려운 문제에 직면할 때, 창작자는 한 치의 오차도 허용하지 않는 우아한 해결책을 강요받게 됩니다. 야생 동물이 아름다운 이유도 생존이라는 지극히 어려운 문제를 해결하기 위해 모든 군더더기를 깎아냈기 때문입니다. 7. 쉬워 보임 (Looks Easy) 최고의 결과물은 마치 아무런 노력 없이 단번에 만들어진 것처럼 자연스럽습니다. 하지만 그 '쉬워 보이는 상태'는 수많은 훈련의 산물입니다. 레오나르도 다 빈치의 드로잉이 단 몇 개의 선으로 완벽한 초상을 구현하는 것은, 그가 수만 번의 연습을 통해 가장 정확한 위치에 선을 긋는 능력을 몸에 익혔기에 가능한 일입니다. 숙련된 거장의 손끝에서 나오는 디자인은 복잡한 고민의 흔적을 지우고 명쾌함만을 남깁니다. 8. 대칭과 재귀 (Symmetry & Recursion) 대칭은 단순함을 구현하는 강력한 방법이며, 자연계에서 가장 흔히 발견되는 아름다움의 법칙입니다. 특히 큰 구조 안에 작은 구조가 반복되는 재귀적 형태는 디자인에 논리적 안정감을 줍니다. 에펠탑이 거대한 탑 안에 작은 탑의 형상을 품고 있는 모습이나, 프로그래밍에서 재귀 알고리즘을 통해 복잡한 문제를 한 줄의 코드로 해결하는 것은 대칭이 주는 구조적 승리의 사례입니다. 9. 자연을 닮음 (Resembling Nature) 자연은 수억 년 동안 '최적화'라는 과제를 수행해 온 위대한 설계자입니다. 우리의 설계가 자연의 방식과 닮아간다면 그것은 올바른 방향으로 가고 있다는 신호입니다. 배의 골격이 물고기의 척추를 닮고, 비행기의 날개가 새의 원리를 따르는 것처럼 자연의 검증된 패턴을 차용하는 것은 가장 지능적인 설계 전략입니다. 10. 재설계 (Redesign) 위대한 디자인은 단 한 번에 완성되지 않습니다. 전문가들은 자신의 초기 아이디어가 틀릴 수 있음을 인정하고 끊임없이 수정합니다. 건축가 프랭크 로이드 라이트가 구겐하임 미술관을 설계할 때 초기안을 과감히 뒤집어 현재의 나선형 구조를 만든 것처럼, 잘못된 부분을 기꺼이 버리고 다시 그릴 수 있는 용기가 위대한 결과물을 만듭니다. 이러한 원칙들은 결국 하나의 결론으로 향합니다. 좋은 디자인을 만들기 위해서는 무엇이 나쁜 것인지 알아보는 ‘까다로운 취향'을 길러야 하며, 그 취향을 만족시킬 때까지 멈추지 않는 노력이 필요하다는 것입니다.

요즘 코딩하는 방식이 완전히 달라졌습니다. 주변 개발자들을 보면 지난 10월쯤부터 확 바뀌었어요. CLAUDE.md에 에이전트 행동 규칙을 적어두고, 태스크를 나눠서 여러 에이전트에게 분배하고, 그 결과물도 에이전트가 리뷰하게 하더라고요. 한명이 코딩 Agent 공장을 돌리면서 몇개월 걸릴 일을 몇시간만에 합니다. 직접 코드를 짜는 시간보다 에이전트들이 잘 움직이게 판을 짜는 시간이 훨씬 길어진 거죠. 한 명이 수십 개 에이전트를 돌리면서 소프트웨어를 만드는 게 꽤 일반화됐습니다. 펀치카드로 코딩하던 사람들이 GUI를 처음 봤을 때 이런 기분이었을까 싶어요. 근데 이게 아직은 개발자들만의 이야기거든요. 최근에 OpenClaw 써보신 분들은 아시겠지만, 비개발자분들 반응이 장난 아니었습니다. 채팅으로 AI에게 일을 시키면 여러 웹사이트랑 소프트웨어를 오가면서 결과를 가져오는데, 이걸 보고 "AGI 체감했다"는 말이 나올 정도였어요. 개발자들이 터미널에서 하네스 짜서 겨우 하던 걸, 채팅창 하나로 하니까 그런 반응이 나온 거죠. OpenClaw를 보면서 느낀 게 있습니다. 사람들이 원하는 건 에이전트 기술 자체가 아니라, 자기가 익숙한 방식으로 에이전트를 부리는 것이더라고요. 터미널이 어려운 사람이 대부분인데, 그 허들만 넘겨줘도 가치를 확 느낍니다. 시장을 보면 흐름이 꽤 선명합니다. Lovable, Bolt, Manus나 Genspark 같은 바이브코딩 도구가 "코드를 대신 짜준다"는 가치를 증명했고 거기서 한 발 더 나아가서 "일을 대신 해준다"는 걸 보여줬습니다. 실제로 연 천억 이상 매출을 만들고 있고요. 다음 스텝이 뭘까 생각해보면, 결국 내 맥락을 깊이 이해하면서 여러 도구를 넘나들며 진짜 내 일을 처리해주는 에이전트인 것 같습니다. "만들어줘"에서 "알아서 해줘"로 넘어가는 거죠. 개인이 여러 AI 에이전트에게 업무도 시키고 상담도 받고 일상의 일들을 맡기는 게 올해 안에 훨씬 보편화될 거라고 봅니다. 이걸 만들려면 재밌는 기술 문제들이 있습니다. 에이전트한테 자율성을 충분히 주면서도 안전하게 돌아가는 샌드박싱을 어떻게 설계할 건지. 모델마다 잘하는 게 다른데 유저 요청에 맞춰서 최적 조합을 어떻게 찾을 건지. 에이전트가 맥락을 잃지 않으면서 이 앱 저 앱을 넘나들게 하려면 구조를 어떻게 잡아야 하는지. 기술적으로 되는 것과 사람들이 진짜 쓰는 것 사이의 갭을 어떻게 빠르게 좁힐 건지. 한국에 이미 자기만의 에이전트 오케스트레이션을 깎고 계신 분들이 꽤 많다는 걸 알고 있습니다. 근데 대부분 본인 작업용이거나 사내에서만 쓰고 계시더라고요. 그 경험이면 전 세계 유저들의 일상을 바꾸는 제품을 만들 수 있다고 생각합니다. 저는 2번 창업을 했습니다. 블록체인 지갑 회사랑 제조업 대상 AI 솔루션 회사를 했고, 외부 투자 없이 누적 120억 매출을 만들었습니다. 솔직히 그 과정에서 첫 창업자가 할 수 있는 실수란 실수는 다 해본 것 같아요. PMF를 찾겠다고 여러 번 방향을 틀었고, 그때마다 배운 게 결국 지금의 판단력이 됐습니다. 이번에 새로 시작하게 된 건 주변 비개발자분들 때문입니다. OpenClaw로 회사 업무를 자동화하거나, 이전에는 개발자한테 부탁해야 했던 일들을 직접 AI에게 시키는 걸 보면서 — 이 사람들이 ChatGPT 쓸 때랑은 확실히 다른 가치를 느끼고 있다는 걸 알게 됐어요. 이건 단순한 도구가 아니라 일하는 방식 자체가 바뀌는 거구나, 싶었습니다. 지금은 AI 에이전트의 새로운 인터페이스를 찾아가는 시기라고 생각합니다. 엄청나게 빠르게 실험하면서 비개발자들의 일상에 실제 변화를 만들 수 있는 타이밍이에요. 당신이 오늘 만든 것이 그게 필요한 사람에게 바로 임팩트를 줄 수 있는, 그런 시기입니다. 이런 분이랑 이야기해보고 싶습니다. 에이전트 오케스트레이션이나 프롬프트 설계를 깊이 파보신 분 샌드박싱이나 권한 설계처럼 "안전하지만 유용한" 실행 환경을 고민해보신 분 기술 가능성보다 사람들이 실제로 쓰는 제품을 만드는 데 집중하시는 분 초기 스타트업에서 빠르게 실험하고 방향을 잡아가는 과정을 즐기시는 분 편하게 커피 한 잔 하면서 이야기 나눠보면 좋겠습니다. 혹시 주변에 이 사람은 꼭 만나야한다고 생각하는 분을 소개해주시면 사례하겠습니다. 널리 퍼질 수 있게 좋아요. 댓글 부탁드려요! 스웨덴, 싱가폴 회사 말고 한국 사람들도 글로벌 서비스를 만들어볼 수 있는 시기입니다 🙂

전력, 컴퓨터, 데이터, 모델 중에서 모델은 이미 중국에 있는 중국인과 미국에 있는 중국인들이 만드는 것이 되었고 이제 컴퓨터만이 병목이고 전력과 데이터는 중국이 앞서 있다. 중국이 칩까지 만들거나 안정적으로 수급할 수 있다면 과거 일본 자동차가 자동차 시장을 석권했던 것처럼 토큰 x 하드웨어까지 정복할지도 모르겠다. 일본의 자동차 산업과 중국의 AI: '제약'이 만든 경쟁력 1970년대만 해도 일본의 자동차 산업이 승자가 될 것이라 예상하는 사람은 많지 않았습니다. 일본은 자국 내 석유 자원이 거의 없었고, 엔진 기술력 또한 뒤처져 있었기 때문입니다. 하지만 바로 그 자원의 부족이라는 제약 때문에 일본 자동차 제조사들은 단 한 방울의 연료에서도 최대의 효율을 짜내야만 하는 명확한 선택의 기로에 섰습니다. 그들은 소배기량 고효율 엔진을 최적화하기 시작했고, 더 가벼운 설계와 정밀한 제조 공정 제어 기술을 도입했습니다. 마침내 1973년 오일쇼크가 발생하고 연료 가격이 폭등하자, 마력만 높은 미국의 대형차들은 가계에 큰 부담이 되었습니다. 반면, 과거 일본이 제약에 떠밀려 어쩔 수 없이 선택했던 효율 지향적 전략은 뜻밖의 강력한 이점이 되었습니다. 그 결과 일본 자동차 산업은 이후 약 50년 동안 눈부신 전성기를 누리게 됩니다. 오늘날 중국의 AI 기업들도 오랫동안 GPU 수급 제한이라는 제약을 겪어왔습니다. 하지만 이러한 제약은 오히려 그들이 모델 경량화에 더 공격적으로 매달리고, 추론 효율성을 최적화하며, 공학적 실행력을 극한까지 끌어올리게 만드는 동력이 되었습니다. 동일한 대화를 처리하더라도 더 적은 컴퓨팅 자원을 사용함으로써 토큰당 비용을 낮춘 것입니다. 향후 전력 인프라와 데이터 센터 구축 측면에서도 중국은 태양광, 철강, 가전 분야에서 그랬던 것처럼 강력한 비용 우위를 점할 가능성이 높습니다. 미래에 중국은 세계 최대의 '토큰(Token) 수출국'이 될지도 모릅니다. https://x.com/mablejiang/status/2020904698321174864?s=46&t=h5Byg6Wosg8MJb4pbPSDow

소프트웨어의 신문화: Aggregation Theory 2.0과 가치 이동 신문과 SaaS — 같은 구조, 다른 시대 신문 산업과 SaaS 산업은 놀라울 만큼 같은 궤적을 따르고 있다. 신문의 경제학은 지리적 희소성 위에 세워졌다. 한 도시에서 인쇄기와 배달망을 가진 자가 독점적 수익을 거둘 수 있었다. 고성장 → 지역 통합 → 과점적 수익성. 그러나 TV, 라디오, 그리고 인터넷이라는 환경 변화가 이 구조를 무너뜨렸다. 배포(distribution) 비용이 0에 수렴하면서, 누구나 퍼블리셔가 될 수 있게 되었다. 개별 퍼블리셔에게는 기회였지만, 집단적으로는 경제적 파괴였다. SaaS의 경제학은 코드의 희소성 위에 세워져 있다. 소프트웨어를 만들 수 있는 엔지니어가 희소하기 때문에, 잘 만든 소프트웨어는 per-seat 구독료를 받을 수 있었다. 그런데 지금, AI가 코드 생성 비용(cost of code)을 구조적으로 0에 수렴시키고 있다. 누구나 소프트웨어를 만들 수 있는 시대. SaaS의 경쟁 환경이 "희소"에서 "풍요(abundance)"로 재편되고 있다. 핵심 투입 요소가 희소 → 풍요로 바뀌는 순간, 가치(수익 풀)는 반드시 '다른 희소'로 이동한다. 이번엔 다르다: Interface 자체가 사라진다 신문이 무너질 때, 새로운 인터페이스가 등장해서 가치를 흡수했다. 웹사이트, 앱, 뉴스피드. 이것이 Aggregation Theory 1.0이다. Google은 검색으로, Facebook은 피드로, Uber는 모바일 앱으로 — 인터넷 위에서 공급자를 모으고, 더 나은 UX로 수요를 장악했다. 공급자가 많아질수록 사용자에게 가치가 커지는 네트워크 효과가 핵심 해자였다. 이번엔 인터페이스 자체가 통합되고 있다. 사용자가 앱을 열고, 키워드를 입력하고, 결과를 비교하는 행위가 — 음성 또는 자연어로 AI Agent에게 의도를 말하면, 뒷단에 연결된 여러 앱, 문서, 서비스를 알아서 처리하는 행위로 바뀐다. 이것이 Aggregation Theory 2.0이다. 1.0이 인터넷 위에서 UX(검색/피드/앱)로 공급자를 모았다면, 2.0은 자연어와 음성으로 애플리케이션 소프트웨어 자체를 모아서, 고객에게 결과만 가져다준다. 해자도 바뀐다. 1.0의 해자가 네트워크 효과와 UX였다면, 2.0의 해자는 고객의 개인 맥락을 얼마나 깊이 이해하는가, 그리고 신뢰할 만한 결과물을 가져다주는가이다. 새로운 희소: 가치는 어디로 이동하는가 코드가 풍요로워지면, 경쟁은 "기능 수"에서 다른 곳으로 이동한다. 토큰, 컴퓨트, 지연시간, 신뢰성, 보안 — 실행 제약이 새로운 병목이 된다. 유지보수, 보안 패치, 컴플라이언스, 시스템 통합, 고객 지원 같은 제품의 전체 수명주기를 책임지는 레이어에 가치가 집중된다. 코딩이 아무리 빨라져도, 누군가는 결제에 책임을 져야 하고, 규제를 준수해야 하고, 자금을 조달해야 하고, 자산을 평가해야 하고, 대출을 실행해야 한다. 이런 것들을 쥐고 있는 비즈니스는 AI 때문에 위축되는 것이 아니라, AI 덕분에 더 효율적으로 확장할 수 있다. Vertical AI의 생존 조건: 3가지 질문 Nihar Bobba가 제시한 프레임워크가 여기서 핵심이 된다. Foundation model 회사들(Anthropic, OpenAI, Google)이 빠르게 수직 확장하고 있는 지금, Vertical AI 회사가 살아남으려면 아래 세 질문에 모두 "우리"라고 답할 수 있어야 한다: 1. 누가 주체(principal)인가? — 고객의 도구인가, 결과의 책임자인가? 2. 누가 liability를 소유하는가? — 일이 잘못되면 누구의 문제인가? 3. 누가 규제 기관과의 관계를 갖고 있는가? — 감사관이 전화할 곳은 어디인가? 셋 다 "고객"이라면, foundation model이 당신을 대체할 수 있다. 셋 다 "우리"라면, 당신이 가진 것은 AI로 복제할 수 없는 구조적 방어력이다. Frontier lab과 경쟁하지 말고, 그들의 고객이 되어라. 변호사를 위한 AI 도구가 아니라, AI-native 로펌을 만들어라. 세무사를 위한 소프트웨어가 아니라, 세금을 대신 신고하고 감사를 대신 받는 서비스를 만들어라. 고성장이 나올 4가지 영역 1. Outcome-as-a-Service: 도구가 아닌 결과를 파는 기업 세금/법률/회계 소프트웨어는 commodity가 된다. 세금/법률/회계 대행 — AI Agent가 업무를 수행하고, 결과에 대한 보장료를 청구하는 모델 — 은 프리미엄을 받는다. Per-seat 구독료에서 insurance pricing으로의 전환. 고객은 소프트웨어가 아니라 확실성(certainty)에 돈을 낸다. 2. Agent Infrastructure: 에이전트 시대의 인프라 개인과 기업이 수백에서 수천 개의 Agent를 운용하는 세상에서, 현재의 인프라는 여전히 인간이 소프트웨어를 조작하는 구조로 되어 있다. Agent 간 통신(MCP/A2A), Agent 관리, Agent 보안, Agent 과금 — 이 모든 인프라가 새로 필요하다. 결제(Stripe), 물류(Amazon), 컴퓨팅(AWS/Azure) 같은 기존 인프라 위에, Agent-native 계층이 쌓인다. 3. Trust Layer: 신뢰가 새로운 해자 AI Agent에게 금융, 의료, 법적 결정을 위임하려면 신뢰가 필요하다. 신뢰할 만한 사람을 찾듯, 신뢰할 만한 Agent에 고객 수요가 몰린다. 이 신뢰를 구축하는 데는 시간이 걸리고, 한번 깨지면 복구가 어렵다. 디바이스 레벨(Apple의 on-device privacy), 금융 레벨(규제 라이선스, 자본시장 관계), 의료 레벨(FDA/HIPAA compliance) — 각 영역에서 신뢰를 먼저 확보한 자가 수요를 독점한다. 3. Physical World Coordination: 디지털 바깥의 자산 DoorDash의 레스토랑 네트워크와 배달원, Opendoor의 부동산 매물과 현장 방문 데이터, Amazon의 물류 창고. 디지털 세상 바깥에 존재하는 자산과 관계는 AI Agent가 코드로 복제할 수 없다. 이 물리적 실행력을 가진 기업은 AI로 운영 비용을 줄이면서도, 그 해자 오히려 강화된다. 결론: 코드가 무료가 되는 것이지, 결과가 무료가 되는 것이 아니다 인간의 눈을 위한 정보 시스템 — SEO, per-seat SaaS, 디스플레이 광고, 마케팅 카피 생성 도구, 기본적 소프트웨어 도구 — 은 사라진다. 살아남는 것은 현실 세계의 결과와 연결된 것뿐이다. 지금까지 고품질 서비스를 보장하는 비즈니스는 대부분 확장이 어려웠다. 변호사, 세무사, 의사의 시간은 유한했기 때문이다. 그러나 AI Agent 덕분에, 결과를 보장하는 서비스가 처음으로 소프트웨어처럼 확장 가능해지고 있다. 신뢰를 스케일시킬 수 있는 시대가 열린 것이다. 신문이 무너졌을 때 배포가 무료가 되었지, 저널리즘이 무료가 된 것은 아니었다. SaaS가 무너지는 지금, 코드가 무료가 되는 것이지, 결과가 무료가 되는 것이 아니다. https://csunerd.substack.com/p/software-as-a-newspaper https://stratechery.com/2026/microsoft-and-software-survival/ https://m.blog.naver.com/mynameisdj/224178076111 https://stratechery.com/aggregation-theory/ https://x.com/nbobba/status/2020200100300009797