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년짜리 계약을 하더라도 제품이 고정되는 게 아니라 계속 진화할 것이라는 믿음을 가져야 한다고 봅니다.