1. “코딩”의 본질이 바뀌었다

카파시는 이 에피소드에서 가장 먼저, 이제 code라는 말 자체가 정확하지 않다고 말해. 예전에는 개발자가 직접 코드를 타이핑하는 사람이었다면, 지금은 여러 에이전트에게 “내 의지”를 전달하고, 그들이 병렬로 일하도록 설계하는 사람이 되어 간다는 거야. 그가 “하루 16시간 동안 에이전트에게 내 의지를 표현한다”고 한 이유도 여기 있고, 특히 12월을 기점으로 자신이 직접 쓰는 코드보다 에이전트에게 위임하는 비중이 더 커졌다고 본다. 그는 이걸 단순 생산성 향상이 아니라 소프트웨어 엔지니어링의 phase shift처럼 느낀다고 설명한다.

2. 새 병목은 모델이 아니라 “사람의 오케스트레이션 실력”이다

이전 병목은 타이핑 속도, 구현 시간, 인간의 집중력이었는데, 이제 카파시는 실패의 원인을 모델 한계보다 “내가 아직 잘 못 시켰기 때문”으로 느낀다고 말해. instruction file이 약했을 수 있고, memory tool이 부실했을 수 있고, task decomposition이 안 좋았을 수 있다는 식이야. 그래서 “everything is skill issue”라는 표현이 나온다. 같은 맥락에서 그는 GPU가 놀고 있으면 불안했던 박사과정 시절처럼, 이제는 subscription과 token throughput이 남아 있으면 불안하다고도 말해. 즉, 코딩의 중심 스킬이 “직접 구현”에서 지시, 분해, 검증, 병렬화로 이동하고 있다는 뜻이야.

3. 다음 단계는 단일 에이전트가 아니라 멀티에이전트 + persistent system이다

카파시가 보는 “숙련”은 좋은 프롬프트 한 번 던지는 수준이 아니야. 여러 에이전트가 동시에 돌아가고, 서로 간섭하지 않는 일을 나눠 맡고, 사람은 그 위에서 macro action 단위로 레포를 조작하는 상태를 말해. 그가 Peter Steinberger 사례를 든 것도 그래서야. 여기서 중요한 게 “claw”인데, 이건 그냥 채팅형 코딩 에이전트보다 더 persistent한 층위야. 계속 살아 있고, 사용자가 보고 있지 않아도 루프를 돌고, memory와 tool을 붙여 장기 실행이 가능해야 한다는 발상이지. OpenClaw 공식 저장소도 실제로 agent workspace에 AGENTS.md, SOUL.md, TOOLS.md를 주입하고, gateway daemon을 설치해 assistant를 always-on으로 유지하는 구조를 설명한다.

4. 에이전트의 성능만큼 “성격과 인터페이스”도 중요하다는 게 그의 포인트다

카파시는 Claude와 Codex를 비교하면서, 단순히 코드 생성 품질만이 아니라 에이전트가 팀메이트처럼 느껴지는가, 내가 뭘 만들고 있는지 이해하는가, 칭찬이나 반응이 얼마나 적절한가까지 중요하다고 말해. 그의 표현대로 Codex는 상대적으로 dry하고, Claude는 teammate-like하게 느껴진다는 거지. 그리고 OpenClaw가 resonant했던 이유로 그는 SOUL.md 같은 personality layer, memory system, 그리고 WhatsApp 같은 단일 포털을 꼽는다. 즉 앞으로의 경쟁력은 “더 똑똑한 모델”만이 아니라 더 인간이 다루기 쉬운 agent persona + persistent UX에도 있다는 거야.

5. Dobby 사례가 보여주는 건 “앱의 시대에서 API의 시대로”의 이동이다

그가 가장 재미있게 든 예시는 집 자동화용 claw인 Dobby야. transcript에 따르면 그는 에이전트에게 집 LAN에서 Sonos 같은 장치를 찾게 했고, 에이전트가 이를 발견해 API를 찾아내고, 조명/HVAC/블라인드/풀/스파/보안까지 하나의 자연어 인터페이스로 엮었다고 설명한다. 그 결과 예전엔 6개 앱을 써야 하던 걸 이제는 WhatsApp을 통해 자연어로 제어하게 됐다는 거야. 여기서 카파시가 끌어낸 더 큰 결론은 강하다. 많은 앱은 사실 존재할 필요가 없고, 하드웨어/서비스는 API만 노출하면 되며, agent가 그 위의 지능 레이어가 된다는 거지. 즉 UX의 중심이 “사람이 배워야 하는 GUI”에서 “에이전트가 호출하는 API”로 이동한다는 주장이다.

6. AutoResearch는 “연구자까지 루프 밖으로 빼자”는 발상이다

카파시가 AutoResearch에서 밀고 있는 건 단순한 ML demo가 아니야. 핵심은 연구 루프를 인간이 계속 이어붙이는 구조 자체를 문제 삼는 것이야. 공식 repo 설명대로 autoresearch는 에이전트가 작은 LLM training setup에서 train.py를 바꾸고, 5분 훈련을 돌리고, val_bpb를 보고, 개선되면 유지하고 아니면 버리는 루프를 자동으로 반복한다. 그리고 사람은 Python 코드를 고치는 대신 program.md라는 markdown instructions를 고친다. 에피소드에서 카파시는 이걸 더 밀어붙여, 결국 연구 조직 전체가 markdown files로 표현될 수 있고, 그 조직 자체도 튜닝 대상이 된다고 말한다. standup을 적게 하는 조직, 더 risk-taking한 조직, 더 보수적인 조직을 전부 “code”로 볼 수 있다는 거지.

7. 그래서 그가 말하는 진짜 게임은 “evaluation이 있는 문제를 닫힌 루프로 바꾸는 것”이다

카파시는 이 패턴이 특히 objective metric이 명확한 문제에 강하다고 본다. 예를 들어 같은 동작을 유지하면서 CUDA kernel을 더 빠르게 만들기, validation metric을 낮추기, unit test 통과 여부로 판정되는 문제는 agent loop와 너무 잘 맞는다는 거야. 반대로 좋은지 나쁜지 평가하기 어려운 문제, 의도 해석, 미묘한 취향, 애매한 소프트한 판단은 아직 훨씬 어렵다고 말한다. 그래서 그의 메시지는 “모든 문제가 자동화된다”가 아니라 “평가 가능하게 정의된 문제부터 자동화가 급속히 먹힌다”에 가깝다.

8. 하지만 그는 동시에 지금 모델들이 여전히 ‘jagged’하다고 본다

이 대화의 밸런스가 좋은 이유는, 카파시가 엄청 흥분하면서도 모델의 이상한 불균일성을 계속 강조하기 때문이야. 그는 현재 모델을 “평생 시스템 프로그래머였던 뛰어난 박사과정생과 10살 아이가 한 몸에 들어 있는 것 같다”고 묘사한다. agentic task에서는 몇 시간씩 산을 옮길 수 있는데, 검증되지 않은 영역이나 soft task에선 엉뚱하게 헤매고, 심지어 농담 하나도 몇 년째 별로 발전이 없다는 예를 든다. 그의 설명은 명확해. RL이 잘 먹는 verifiable domain은 빨리 좋아지지만, 그렇지 않은 부분은 상대적으로 덜 최적화되어 남는다는 것. 그래서 그는 “코드가 좋아지면 모든 지능이 고르게 따라온다”는 강한 일반화 서사에는 회의적이다.

9. 모델의 미래도 “하나의 거대 oracle”보다 점점 분화될 수 있다고 본다

그는 지금의 labs가 하나의 거대한 monoculture model을 만들고 거기에 모든 능력을 밀어 넣으려 하는 것처럼 보인다고 말한다. 하지만 장기적으로는 speciation, 즉 분화가 더 자연스럽다고 본다. 생물계에서 시각 피질이 강한 동물, 특정 niche에 특화된 동물이 있듯이, AI도 모든 것을 다 아는 하나의 oracle보다 작지만 competent한 core를 가진 뒤 특정 작업에 전문화된 모델들이 늘어날 수 있다는 거야. 다만 아직은 fine-tuning으로 특정 능력을 올리면서 다른 능력을 망가뜨리지 않는 기술, 즉 “weights를 만지는 과학”이 충분히 성숙하지 않아 실제 분화가 크게 보이지는 않는다고 본다. 지금은 context window를 조작하는 쪽이 훨씬 쉽고 싸다는 얘기다.

10. 일자리와 산업에 대해서는 “디지털 작업이 먼저 재편된다”는 관점이 강하다

카파시는 jobs data를 보면서 특히 디지털 정보를 다루는 직업군에 주목했다고 말한다. 이유는 간단해. 지금 AI는 물리 세계보다 디지털 세계의 비트를 훨씬 잘 다룬다. 그는 “bits are so much easier”라고 말하고, 그래서 단기적으로는 원자(atom)를 다루는 물리 노동보다 디지털 정보 처리 직업군이 더 빨리 재편될 거라고 본다. 그렇다고 무조건 일자리가 사라진다고 단정하지는 않아. 오히려 그는 software가 그동안 희소하고 비쌌기 때문에, 장벽이 내려가면 Jevons paradox처럼 software 수요가 늘 수 있다고 본다. 그래서 사람들에겐 우선 “두려워하거나 dismiss하지 말고 따라붙어라”는 조언을 한다. 현재 시점에서 AI는 아직은 주로 task bundle을 가속하는 도구라는 거지.

11. 오픈소스와 프런티어 랩에 대해서는 “긴장된 균형”을 선호한다

그는 frontier labs가 비싼 frontier intelligence를 밀어 올리는 역할은 필요하다고 본다. 동시에 모든 지능이 닫혀 있는 구조는 구조적으로 위험하다고 본다. transcript에서 그는 오픈 모델이 frontier보다 몇 달 뒤에 따라오면서, 산업 전체가 접근 가능한 common working space for intelligences 역할을 해주는 구도가 꽤 건강하다고 말한다. 또 frontier lab 안에 있으면 실제 frontier를 보며 판단력을 유지할 수 있지만, 동시에 조직의 인센티브와 압력에서 완전히 자유롭기는 어렵다고도 본다. 그래서 그의 결론은 inside/outside 중 하나가 아니라, 양쪽을 오가며 frontier 감각과 독립성을 동시에 확보하는 것에 가깝다.

12. 로보틱스는 오겠지만, 그는 여전히 “bits first, atoms later”라고 본다

자율주행 경험을 가진 사람답게 그는 물리 세계 자동화에 훨씬 조심스럽다. 핵심 메시지는 디지털 공간에서의 unhobbling이 먼저 대규모로 일어나고, 물리 세계는 그보다 늦다는 것. 원자를 다루는 건 비트를 다루는 것보다 훨씬 어렵기 때문이야. 다만 그는 중간 단계로 physical–digital interface, 즉 센서와 액추에이터 층을 아주 중요하게 본다. AI가 이미 업로드된 디지털 정보만 다 소화하고 나면 결국 세상에 새 질문을 던지고 답을 받아와야 하니까, 실험장비, 카메라, 데이터 수집 네트워크, 현실 세계 작업을 agent에게 외주 주는 메커니즘 같은 것들이 다음 큰 영역이 된다는 거지.

13. 교육도 “사람에게 직접 설명”에서 “에이전트가 가르치게 설명”으로 이동한다

microGPT 얘기에서 카파시가 말한 건 꽤 근본적이야. 그는 LLM training의 알고리즘적 본질은 사실 200줄 정도의 Python까지 압축 가능하다고 보고, 그 200줄이 자신의 오랜 단순화 집착의 결과라고 말한다. 그런데 더 중요한 건 그다음 결론이야. 예전에는 그걸 사람에게 설명하는 강의나 글을 만들었겠지만, 이제는 에이전트가 이해하도록 설명하면, 에이전트가 인간에게 각자 수준에 맞춰 무한한 인내로 다시 설명할 수 있다는 거야. 그래서 문서도 HTML docs for humans보다 markdown docs for agents로 바뀔 수 있고, “skill”은 결국 agent에게 무엇을 어떤 순서로 가르치게 할지 정의하는 curriculum prompt가 된다. 그의 최종 정리는 더 날카롭다. 에이전트가 아직 못 하는 몇 비트를 만드는 것이 인간의 일이고, 나머지 설명·전달·확장은 점점 에이전트의 일이 된다는 거야.

성공에 더 유리한 마음가짐은 상태 지향(state oriented) 이 아니라 행동 지향(action oriented) 이다.
즉, 지금 내 기분·컨디션·불안에 집중하기보다, 눈앞의 해야 할 일에 바로 집중하고 움직이는 태도가 더 성과를 만든다는 이야기다.

행동 지향 vs 상태 지향

행동 지향:
지금 내가 어떤 기분인지, 몸 상태가 어떤지에 매달리지 않고 해야 할 과업 자체에 집중한다.
상태 지향:
“내가 지금 준비가 됐나?”, “기분이 별로인데?”, “아까 답장 안 온 게 신경 쓰이네”, “목이 좀 칼칼한데”처럼 자기 상태를 계속 의식한다.

왜 중요한가
심리학 연구에 따르면, 행동 지향적 태도를 취할수록 실제로 과제를 끝낼 가능성이 높아진다.
즉, 성공에 필요한 것은 “완벽한 컨디션”이 아니라 일단 행동에 들어가는 것이다.

아놀드 슈워제네거의 예시
글은 아놀드를 행동 지향의 대표 사례로 든다.
그는 아침에 일어나서 “오늘 나는 어떤 기분이지?”, “슬픈가?”를 먼저 묻지 않는다.
대신 생각보다 행동을 우선한다.
그의 태도는 한마디로:
“계속 바쁘게 움직이면 그런 생각에 빠질 시간도 없다. 그냥 앞으로 가라. 움직여라.”

이 글의 메시지
성공하는 사람은 자신의 감정과 상태를 지나치게 점검하지 않는다.
그들은 기분이 좋아야 움직이는 사람이 아니라, 움직이면서 기분과 상태를 넘어서는 사람이다.

한 줄 정리
“내 상태를 점검하느라 멈추지 말고, 일단 해야 할 행동으로 들어가라.”

https://www.linkedin.com/posts/gokulrajaram1_be-action-oriented-not-state-oriented-the-activity-7441321359928074241-giWU?utm_source=share&utm_medium=member_desktop&rcm=ACoAABqmkk8B31-f1cgLX5fNW16TpECDoRf4kWg

에이전트가 에이전트를 만드는 시대

우리는 보통 AI 에이전트를 떠올릴 때, 하나의 똑똑한 조수부터 상상한다. 코드를 짜주고, 문서를 써주고, 테스트를 돌려주는 존재. 하지만 지금 더 중요한 변화는 그보다 한 단계 바깥에서 일어나고 있다. 이제 에이전트는 단지 일을 대신하는 도구가 아니라, 다음 에이전트가 더 잘 일하도록 환경을 만들고 규칙을 세우고 신호를 배치하는 존재가 되어가고 있다. 다시 말해, 이제 중요한 것은 “에이전트가 무엇을 만들 수 있는가”만이 아니라 “에이전트가 어떤 에이전트 조직을 만들어내는가”다.

이 점에서 Ramp의 사례는 매우 상징적이다. 그들은 처음에 QA 에이전트를 밤마다 돌렸다. 핵심 기능을 점검하고, 최근 머지된 PR을 스트레스 테스트하고, 잠재 버그를 탐색하게 했다. 그리고 실제로 꽤 잘 작동했다. 매일 여러 프로덕션 버그를 잡았고, 문제를 확인하면 원인까지 추적해 수정 PR을 올리도록 만들었다. 여기까지만 보면, 이 시스템은 “AI가 디버깅을 잘한다”는 익숙한 이야기처럼 보인다.

하지만 진짜 전환점은 그 다음 단계에 있었다. 그들은 에이전트가 직접 Datadog 모니터를 생성하게 만들었고, 그 모니터가 다시 새로운 에이전트를 호출하게 만들었다. PR이 머지되면 새 코드에 맞는 감시 장치를 만들고, 에러율이나 지연이나 이상 로그가 감지되면, 그 신호를 받은 에이전트가 샌드박스 환경에서 실제로 재현하고 수정안을 제시한다. 여기서 중요한 것은 에이전트가 더 이상 단순히 “문제를 푸는 존재”가 아니라는 점이다. 에이전트는 이제 무엇이 문제인지 정의하는 장치까지 만들고 있다. 문제 해결이 아니라 문제 정의의 자동화가 시작된 것이다.

이 변화는 생각보다 훨씬 크다. 어떤 조직이 무엇을 중요하게 보는지는, 결국 무엇을 측정하고 무엇을 경보로 올리는지에 달려 있다. 만약 에이전트가 그 경보 체계를 만든다면, 조직은 점점 “실제 고객의 고통”보다 “에이전트가 잘 처리할 수 있는 고통”에 더 민감해질 수 있다. 재현 가능한 문제, 로그에 남는 문제, 신호로 표준화할 수 있는 문제는 점점 더 빨리 해결될 것이다. 반대로 사용자는 불편하지만 계측하기 어렵고, 모델이 우선순위를 잡기 어려운 문제는 시야 밖으로 밀릴 수 있다. AI 조직의 첫 번째 위험은 성능 부족이 아니라, 현실 인식의 편향일지도 모른다.

Oh my claude code/codex를 만드는 벨만의 여러 “가제”의 이야기는 이 문제를 한 단계 더 확장한다. 그가 공유해준 내용은 AI를 좋은 도구처럼 쓰는 법이 아니라, AI를 팀처럼 운영하는 법에 있었다. 개발 에이전트가 OMC와 OMX를 사용해 다시 OMC와 OMX를 개선하고, 그 업데이트가 다시 에이전트의 생산성을 높이는 식의 재귀적 루프. 여기서 에이전트는 더 이상 결과물을 생산하는 노동력이 아니다. 에이전트는 자신이 속한 운영체제 자체를 개조하는 공동 관리자에 가깝다.

그래서 이 세계에서는 메모리조차 단순한 저장소가 아니다. 발표에서 흥미로웠던 대목은 기억을 임베딩이나 백과사전처럼 다루지 않고, doctrine, operating rule, 즉 운영 교리로 다룬다는 점이다. 이것은 매우 중요한 전환이다. 검색 가능한 기억보다 강제 가능한 규칙이 더 중요해지는 순간, 시스템은 학습 조직이라기보다 규율 조직에 가까워진다. 무엇을 기억할 것인가보다 무엇을 규칙으로 승격할 것인가가 더 중요해진다. 그리고 그때부터 핵심 질문은 “무엇을 배웠는가”가 아니라 “누가 규칙을 고칠 권한을 갖는가”가 된다.

결국 agents building agents의 핵심은 코드 생성이 아니다. 더 본질적인 것은 오케스트레이션이다. 어떤 이벤트가 누구를 호출하는지, 어떤 상태 보고가 실패로 간주되는지, 실행과 보고는 어떤 리듬으로 연결되는지, 중간 상태에서 멈추는 행동을 어떻게 금지하는지, 노이즈는 어디서 잘라내는지. 이 층위는 겉으로 보기에는 부수적이지만, 실제로는 시스템 전체의 지능을 결정한다. 훌륭한 모델보다 훌륭한 배선이 더 중요한 순간이 오고 있는 것이다.

이때 특히 흥미로운 것은 triage의 부상이다. 우리는 AI 시대에도 여전히 “코딩을 얼마나 잘하느냐”를 중심 능력으로 생각하지만, 두 사례를 합치면 오히려 더 희소한 능력은 triage처럼 보인다. 무엇이 진짜 문제인지, 무엇이 노이즈인지, 어디에 사람을 깨워야 하고 어디서 에이전트를 멈춰야 하는지, 어떤 신호가 수정으로 이어져야 하고 어떤 신호는 버려져야 하는지. 코드를 생성하는 능력은 점점 보편화되겠지만, 문제를 분류하고 우선순위를 정하는 능력은 오히려 더 전략적인 자원이 될 가능성이 크다. 미래의 강한 AI 조직은 좋은 코더를 가진 조직이 아니라, 좋은 triage 구조를 가진 조직일 수 있다.

물론 이런 시스템은 효율만큼이나 위험도 키운다. 발표에서는 noisy한 junior agent를 걷어내고 더 강한 소수의 에이전트 중심으로 수렴하는 모습이 보인다. 합리적인 선택이다. 약한 에이전트가 만들어내는 잡음은 실제 팀 생산성을 갉아먹기 쉽다. 그러나 동시에 여기엔 다른 위험이 있다. 다양성이 줄어들면 효율은 좋아지지만, 세계를 보는 방식도 좁아진다. 정상 상태에선 슈퍼 에이전트 하나가 더 강할 수 있다. 하지만 분포가 바뀌고 예외가 쏟아질 때는, 비효율적이지만 다양한 시도들이 오히려 조직을 살릴 수도 있다. 인간 조직에서 주니어와 변두리 실험이 쓸모없는 낭비만은 아니었던 것처럼, 에이전트 조직에서도 약한 다수는 단지 품질이 낮은 리소스가 아닐 수 있다.

그리고 마지막으로 남는 질문은 책임이다. 에이전트가 모니터를 만들고, 경보를 받고, 재현하고, 수정안을 올리고, 사람은 머지 전 승인만 하는 구조에서, 인간은 정말 최종 결정자인가. 아니면 이미 시스템이 만든 결론에 서명만 하는 존재가 되는가. 이 차이는 작지 않다. 자동화의 깊이가 깊어질수록, 책임은 개인의 판단에서 시스템의 규칙으로 이동한다. 앞으로 중요한 것은 “누가 실수했는가”보다 “어떤 운영 규칙이 잘못 설계되었는가”가 될 가능성이 크다. 속도를 얻는 대신, 우리는 점점 판단의 주체를 잃어갈 수도 있다.

그래서 agents building agents는 단순한 기술 트렌드가 아니다. 이것은 새로운 소프트웨어 조직의 탄생에 가깝다. 이 조직에서는 에이전트가 코드를 쓰고, 모니터를 만들고, 메모리를 교리로 바꾸고, 다른 에이전트를 호출하고, 스스로의 작업 환경을 다시 최적화한다. 인간은 점점 더 직접 실행하는 사람이라기보다, 이 재귀적 시스템의 헌법을 설계하고 수정하는 사람에 가까워진다. 앞으로 경쟁력은 더 좋은 모델 하나를 갖는 데서 오지 않을 것이다. 어떤 조직은 AI를 잘 쓸 것이고, 어떤 조직은 AI가 서로를 더 잘 쓰게 만드는 구조를 만들 것이다. 그리고 아마 후자가 더 오래 남을 것이다.

챗(Chat)이 첫 번째 AI 물결의 "UI"였다면, 에이전트(Agents)는 다음 물결의 "UX"입니다.

"질문해 보세요"에서 → "이것 좀 처리해 줘"로의 변화.

이 변화의 의미는 생각보다 훨씬 큽니다. 에이전트가 주요 인터페이스로 자리 잡는 순간 다음과 같은 일이 일어납니다:

앱(App)은 에이전트를 위한 도구가 됩니다.

워크플로우는 프로그래밍이 가능해집니다.

사람들의 관심은 화면을 보는 것에서 '결과물' 자체로 이동합니다.

다시 말해, 이제 승부처는 '더 나은 답변'을 찾는 것이 아닙니다. '더 나은 실행력'을 갖추는 것입니다.

수십억 명의 사용자들은 단순히 AI와 상호작용하는 데 그치지 않고… 에이전트에게 업무를 '위임(delegate)'하게 될 것입니다.

https://www.linkedin.com/posts/dharmesh_breaking-news-meta-buys-dreamer-boy-that-activity-7441942541605711873-owME?utm_source=share&utm_medium=member_desktop&rcm=ACoAABqmkk8B31-f1cgLX5fNW16TpECDoRf4kWg

AI는 아이디어와 실행 사이의 거리를 단축시킵니다. 하지만 좋은 판단과 나쁜 판단 사이의 거리를 좁혀주지는 않습니다. AI는 당신이 겨냥하는 것이 무엇이든 그것을 증폭시킬 뿐입니다. 명확한 전략을 가진 강력한 팀은 더 빨라지고 중요한 일에 더욱 집중하게 될 것입니다. 반면 모호한 전략을 가진 약한 팀은 더 소란스러워지고 주의력만 더 산만해질 것입니다. 명확한 사고는 복리로 쌓여 단단해지지만, 혼란스러운 사고는 쉽게 허물어집니다. 이 격차는 좁혀지지 않습니다. 오히려 더 벌어집니다.

다니엘 카네만(@kahneman_daniel)은 불확실성 속에서 인간이 어떻게 결정을 내리는지 수십 년간 연구했으며, 그의 가장 중요한 발견 중 하나는 우리를 가장 겸손하게 만드는 것이기도 합니다. 우리는 우리 자신의 판단의 질을 일관되게 과신합니다. 유창함(매끄러움)을 정확성과 혼동합니다. 단순히 무언가를 하는 '활동(activity)'을 진정한 '진전(progress)'으로 착각합니다. 그저 바쁠 뿐인데도 생산적이라고 느낍니다. AI가 모든 사람을 더 생산적으로 만드는 세상에서, 이러한 진전에 대한 환상은 더욱 매력적인 유혹이 됩니다. 우리는 더 많이 출시하고, 더 많이 구축하고, 더 많이 배포하면서 그 '양(volume)'을 '가치(value)'로 착각합니다.

이에 대한 해결책은 속도를 늦추는 것이 아닙니다. 우리가 측정하는 기준의 방향을 바꾸는 것입니다. 활동을 측정하는 것을 멈추고 '배움(학습)'을 측정하기 시작하십시오. 시간이 지남에 따라 판단력을 날카롭게 해주는 피드백 루프에 최적화하십시오. 그저 결정을 빨리 내리는 사람이 아니라, 지속적으로 더 나은 결정을 내리는 사람에게 투자하십시오. 결정 속도를 높이는 것과 동시에 결정의 질을 향상시키는 시스템과 문화를 구축하십시오. 단순히 무언가를 출시했는지 여부가 아니라, 출시한 결과물로부터 무엇을 배웠는지에 집중하십시오.

GTC(NVIDIA 개발자 컨퍼런스)에서 젠슨 황의 비전에 대한 월스트리트의 반응은 엇갈렸습니다. 투자자들은 1조 달러 규모의 수요 전망과 함께 AI 버블의 가능성을 저울질했습니다. "AI가 소프트웨어 기업을 돕는다"는 내러티브가 "AI가 사용자당 과금(per-seat) 비즈니스 모델을 위협한다"로 바뀌면서, 소프트웨어 섹터의 가치 평가는 계속해서 재조정되고 있습니다. 칩에서부터 모델, 오케스트레이션(조정), 가격 책정, 조달에 이르기까지 전체 스택이 실시간으로 재평가되고 있습니다. 모든 층위에서 지각변동이 일어나고 있습니다. 발밑의 땅이 흔들리고 있을 때, 누구나 AI에 적응하고 도입해야 한다는 절박함을 느낍니다.

하지만 판단력이 결여된 절박함은 이름만 그럴듯하게 포장한 '패닉(공황)'에 불과합니다. 누구나 AI를 도입할 것입니다. 누구나 더 많이 만들고, 더 빨리 출시하며, (AI) 에이전트를 배포할 것입니다. 그것은 이제 기본적인 필수 조건(table stakes)입니다. 승리하는 창업자는 '더 나은 선택'을 하는 사람들일 것입니다. 진짜 중요한 질문은 당신이 AI를 얼마나 많이 사용하고 있는가가 아닙니다. AI가 당신의 판단력을 향상시키고 있는가, 아니면 당신의 실수를 가속화하고 있는가 하는 것입니다. 이 둘의 차이를 아는 것이 바로 당신만의 AI 경쟁력을 갖추는 핵심입니다.

https://x.com/Alfred_Lin/status/2036433182774727105

Q7. 여기서 말하는 agent-native product란?
Dan의 정의를 Mike도 사실상 받아들이는데, 핵심은 사용자가 할 수 있는 일을 agent도 할 수 있어야 한다는 점입니다. 동시에 진입은 쉬워야 하지만, 커스터마이즈 가능하고 유연하며 확장 가능해야 하고, 디자이너가 미리 상상하지 못한 일도 해낼 수 있어야 합니다.

Q8. Mike가 보는 agent-native의 본질은?
그에게 agent-native는 단순히 “AI를 넣은 더 강한 앱”이 아닙니다. 오히려 예전엔 복잡한 CLI 명령이나 숨은 절차 때문에 접근하기 어려웠던 컴퓨터 기능이, 이제는 Claude 같은 agent 덕분에 원래 그렇게 되어야 했던 방식으로 작동하기 시작했다는 쪽에 가깝습니다. 한마디로 “컴퓨터가 드디어 같이 일하는 도구처럼 느껴진다”는 관점입니다.

Q9. Claude Code와 Claude.ai를 비교하며 무슨 말을 했나?
Mike는 Claude Code는 이 방향을 잘 보여주지만, Claude.ai는 아직 더 진화해야 한다고 말합니다. 예로, 사용자가 artifact나 문서를 만든 뒤 “이걸 project knowledge에 넣어줘”라고 했을 때, Claude가 직접 처리하지 않고 방법만 설명했다는 사례를 듭니다. agent-native라면 그런 primitive를 agent가 바로 다룰 수 있어야 한다는 뜻입니다.

Q10. agent-native 제품을 만들려면 모델에 무엇을 심어야 하나?
좋은 패턴, 템플릿, skill, 그리고 자기 자신에 대한 이해입니다. Mike는 Claude API 자체에 대한 skill만 있어도 새 모델 이름을 둘러싼 쓸데없는 오류를 줄일 수 있었다고 말하고, Every의 agent-native writeup을 skill로 패키징해 Claude Code가 그 원칙을 제품 설계에 반영하게 한 예도 이야기합니다.

Q11. 왜 agent-native 제품은 테스트 방식도 달라져야 하나?
예측 불가능성이 커지기 때문입니다. Mike는 agent-native iOS 앱에서 Claude가 앱 안 채팅 기능으로 자기 자신과 대화하는 모습을 본 사례를 말하면서, 이런 emergent behavior는 기존 unit test나 단순 e2e test만으로는 잡기 어렵다고 설명합니다. 그래서 더 실제적인 harness와 높은 fidelity의 verification이 필요하다고 봅니다.

Q12. 결국 2026년 software design의 핵심은 뭐라고 하나?
표면은 agent가 자유롭게 흔들 수 있어야 하지만, 아래 primitive와 구조는 아주 튼튼해야 한다는 것입니다. Mike는 이를 “유연하지만 모래 위에 지은 느낌이 아니어야 한다”는 식으로 말하며, 이 균형이 2026년 소프트웨어 설계의 예술이자 과학이라고 봅니다.

3) Robustness, 리뷰, 채용, 팀 구조

Q13. AI 시대의 PR/review 기준은 어떻게 달라지나?
단순히 “코드가 생겼다”가 아니라, 정말 작동한다는 증거와 왜 그렇게 만들었는지에 대한 생각이 필요합니다. Mike는 Claude에게도 “PR 전에 네가 직접 이 기능을 검증했다는 걸 보여줘”라고 요구하고, 사람에게는 proof of work보다 proof of thoughtfulness를 본다고 말합니다.

Q14. vibe-coded codebase를 운영할 때 생기는 문제는?
만든 사람 자신도 구조를 완전히 설명하지 못하는 경우가 생긴다는 점입니다. Dan은 Proof가 빠르게 성장했지만 자주 다운되자 내부 지원 인력을 온보딩하면서, 모델과 왕복하며 아키텍처를 설명할 언어를 만들어야 했다고 말합니다. 즉, 너무 빨리 만들어진 코드베이스는 가정의 탑이 쌓여 있고 지식이 암묵적이어서 운영 전환이 어렵습니다.

Q15. Mike가 말하는 robust product의 기준은?
사용자가 “한 번 잘못 클릭하면 다 무너질 것 같다”는 느낌을 받지 않아야 합니다. 그는 Instagram DM V1은 메시지가 갔는지조차 믿기 어려웠지만, V2는 적어도 로드·전송 상태가 신뢰 가능하도록 만들려고 집요하게 다듬었다고 말합니다. agent-native 제품도 마찬가지로, 위에서 흔들어도 아래 데이터와 상태는 안전해야 한다는 얘기입니다.

Q16. 그럼 AI 시대에 어떤 사람을 채용해야 하나?
오히려 systems/architecture 감각이 더 중요해졌다고 봅니다. Mike는 distributed systems 경험이 여전히 매우 유효하다고 말하고, 동시에 product-oriented GM처럼 프롬프트를 덧칠하기보다 도구 구조 자체를 다시 설계할 수 있는 사람도 중요하다고 설명합니다.

Q17. prompt patching은 왜 위험한가?
문제가 생길 때마다 프롬프트에 지시를 더 얹으면, 결국 새 직원 첫날에 지시 100개를 주는 것 같은 상태가 되기 때문입니다. Mike는 이런 경우 보통 문제는 더 많은 instruction이 아니라 툴 분해가 잘못됐거나 agent를 둘로 나눠야 하는 상황일 수 있다고 봅니다.

Q18. UI/flow/polish는 누가 맡고 있나?
Labs에서는 웹의 polish에 강한 사람들이 프로토타입에 성격을 불어넣고, 디자이너들도 상당수 code를 직접 쓰는 designer-builder 역할로 움직입니다. Mike는 일부 프로젝트를 사실상 “아이디어를 민 디자이너 + 뒤에서 길을 닦는 엔지니어”의 cofounder 모델로 운영한다고 설명합니다.

Q19. 새 프로젝트를 시작할 때 가장 중요한 신호는?
문제 공간에 대해 벽을 뚫고서라도 끝까지 확인하겠다는 수준의 확신을 가진 사람이 있는가입니다. 아이디어 디테일에 대한 고집이 아니라, 이 질문을 끝까지 밀어붙일 사람인지가 핵심이고, 그런 사람이 없으면 프로젝트는 “그럴듯하네” 수준에서 죽는다고 말합니다.

Q20. 팀은 왜 작게 유지해야 하나?
아이디어가 아직 한 사람 머릿속에 들어갈 정도면 사람을 더 붙일수록 coordination cost가 더 커지기 때문입니다. Mike는 Instagram과 Artifact 경험을 예로 들며, product-market fit 이전에는 팀을 너무 빨리 키우면 정렬 회의만 늘어난다고 말합니다. AI 시대엔 제품을 3~6개월마다 크게 갈아엎을 수도 있어서 이 문제가 더 심해집니다.

4) 삭제, 리라이트, enterprise tension

Q21. 왜 삭제가 product discipline이 됐다고 보나?
만드는 비용이 급격히 내려갔기 때문에, 이제 진짜 경쟁력은 무엇을 없앨지 아는 능력으로 이동했기 때문입니다. Mike는 Claude Code 팀이 “안 되면 지워라”를 거의 원칙처럼 다루고, 새로운 기능이 기존 기능의 상당 부분을 대체하면 과감히 deprecated/replaced 해야 한다고 말합니다.

Q22. enterprise 고객이 붙으면 왜 삭제가 더 어려워지나?
고객은 현재 UI와 기능 위에 교육 자료, 운영 습관, 내부 규칙을 쌓기 때문입니다. Mike는 Claude.ai 대규모 리디자인 후 어떤 고객이 20시간짜리 enablement 콘텐츠를 다시 찍어야 했다고 항의한 사례를 들고, Styles 기능도 사용자는 적지만 몇몇 회사에는 매우 핵심적이라 쉽게 없애지 못한다고 말합니다.

Q23. 그 문제를 장기적으로 어떻게 풀려 하나?
feature를 core product에서 빼내고 plugins/skills 같은 형태로 이동시키는 방향입니다. 그러면 특정 기능을 좋아하는 사용자는 계속 쓸 수 있지만, 신규 사용자에게는 기본 복잡성을 얹지 않아도 됩니다.

Q24. enterprise 고객을 상대하면서도 속도를 유지하려면 어떻게 해야 하나?
Mike의 답은 “core는 계속 움직이고, enterprise에는 toggle과 rollout 배려를 제공하라”입니다. Cowork는 처음부터 직원에게 비활성화할 수 있는 관리 옵션이 있었고, 고객은 1년짜리 계약을 하더라도 제품이 고정되는 게 아니라 계속 진화할 것이라는 믿음을 가져야 한다고 봅니다.

Q25. 그럼 enterprise-facing startup은 어떤 운영 리듬을 가져야 하나?
연 단위가 아니라 월 단위로 생각해야 한다는 것입니다. Mike는 예전엔 “작년 제품 vs 올해 제품”이었다면 지금은 “3개월 전 제품 vs 오늘 제품” 수준으로 압축됐다고 말하며, V3/V4 수준의 큰 리라이트도 감수하지 않으면 처음부터 다시 생각한 회사에 밀릴 수 있다고 봅니다.

5) OpenClaw, 개인 에이전트, 2026년의 질문

Q26. Mike는 OpenClaw를 어떻게 보나?
이미 가능했던 capability를 사람들이 실제로 만져보게 해준 좋은 packaging으로 봅니다. 코딩도 원래 가능했지만 Replit, Lovable 같은 도구가 대중적 직관을 만들어줬듯, OpenClaw도 “모델에게 툴을 주고 돌리면 어떤 일이 생기는지”를 직접 체감하게 해준 사례라는 평가입니다. 동시에 잠재력과 위험을 한 번에 보여줬다고 말합니다.

Q27. Mike가 꼽는 2026년의 핵심 product question은?
지나치게 제한된 현재 제품과 OpenClaw 같은 넓은 autonomy 사이에 어떤 중간 제품 형태가 존재하느냐입니다. 충분히 강력해서 유용하지만, 연락처 전체에 메일을 보내버리는 식으로 폭주하지는 않는 경계를 어떻게 설계할지가 앞으로 몇 달간 가장 재미있는 문제라고 봅니다.

Q28. 왜 personal agent는 사람들에게 ‘내 것’처럼 느껴지나?
이름을 붙이고, 시간이 지나며 지식과 신뢰가 축적되고, 셋업에 공을 들인 만큼 소유감이 생기기 때문입니다. Mike는 이를 IKEA effect와 연결하고, OpenClaw처럼 설정이 아직 쉽지 않을수록 “내가 이걸 만들었다”는 감각이 강해진다고 설명합니다.

Q29. single agent vs multi-agent에 대한 Mike의 생각은?
그는 앞단에는 하나의 이름 있는 coordinator agent가 있고, 뒤에서는 subagents에 일을 위임하는 구조를 선호하는 쪽입니다. 이유는 run loop를 열어 둬서 사용자가 계속 대화하고 개입할 수 있어야, 도구라기보다 함께 일하는 존재처럼 느껴지기 때문입니다.

Q30. 조직 차원에서는 어떤 변화가 생기나?
Dan은 각 사람의 Claude가 그 사람의 전문성을 닮아 가면서, 조직 안에 shadow org chart가 생긴다고 말합니다. Mike는 여기에 동의하면서, 동시에 “내 agent가 나에 대해 무엇을 알고 있고, 무엇을 다른 사람에게 드러내는가”라는 프라이버시와 지식 이전 문제가 중요한 연구 주제가 될 것이라고 봅니다.