{"title":"Apps After Agents: 에이전트 이후에도 앱이 남는 이유","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/apps-after-agents/","section":"posts","date":"2026-07-08T23:50:25+09:00","lastmod":"2026-07-08T23:50:25+09:00","description":"Kyle Mathews의 Apps After Agents를 바탕으로, 에이전트가 지식 노동을 자동화해도 앱이 사라지지 않는 이유를 기반층, 카메라/엔진 모드, 자동화 실패 패턴 관점에서 다룬다.","summary":"Kyle Mathews의 Apps After Agents는 \u0026ldquo;에이전트가 모든 앱을 대체할 것인가?\u0026ldquo;라는 질문에 반대편에서 답한다. 결론은 단순하다. 에이전트는 많은 일을 자동화하겠지만, 앱은 사라지지 않는다. 다만 앱의 의미가 바뀐다.\nTL;DR 핵심 정리 모델보다 기반층: 모델 성능은 빠르게 평준화된다. 오래 남는 자산은 테스트, 문서, 예외 기록, 의사결정 이력처럼 조직의 판단이 쌓이는 기반층이다. 엔진 영역과 카메라 영역: 에이전트는 검증이 싸고 반복 가능한 일에 강하다. 반대로 무엇을 봐야 하는지, 전제가 틀렸는지, 예외가 생겼는지 알아차리는 일은 계속 탐색이 필요하다. 자동화는 책임을 없애지 않는다: 자동화가 좋아질수록 사람은 감시 루프에서 빠지기 쉽다. 그래서 권한 제한, 체크리스트, 테스트, 승인 흐름 같은 안전장치가 더 중요해진다. 앱은 프롬프트보다 낫다: 사용자는 매번 질문을 잘 쓰고 싶어 하지 않는다. 좋은 앱은 사용자의 의도를 미리 구조화하고, 필요한 선택지를 화면에 드러낸다. 핵심 주장: 소프트웨어는 죽지 않고 층위가 바뀐다 원문은 \u0026ldquo;소프트웨어가 죽었다\u0026quot;는 주장에 선을 긋는다. 이유는 두 가지다.\n","content":"Kyle Mathews의 Apps After Agents는 \u0026ldquo;에이전트가 모든 앱을 대체할 것인가?\u0026ldquo;라는 질문에 반대편에서 답한다. 결론은 단순하다. 에이전트는 많은 일을 자동화하겠지만, 앱은 사라지지 않는다. 다만 앱의 의미가 바뀐다.\nTL;DR 핵심 정리 모델보다 기반층: 모델 성능은 빠르게 평준화된다. 오래 남는 자산은 테스트, 문서, 예외 기록, 의사결정 이력처럼 조직의 판단이 쌓이는 기반층이다. 엔진 영역과 카메라 영역: 에이전트는 검증이 싸고 반복 가능한 일에 강하다. 반대로 무엇을 봐야 하는지, 전제가 틀렸는지, 예외가 생겼는지 알아차리는 일은 계속 탐색이 필요하다. 자동화는 책임을 없애지 않는다: 자동화가 좋아질수록 사람은 감시 루프에서 빠지기 쉽다. 그래서 권한 제한, 체크리스트, 테스트, 승인 흐름 같은 안전장치가 더 중요해진다. 앱은 프롬프트보다 낫다: 사용자는 매번 질문을 잘 쓰고 싶어 하지 않는다. 좋은 앱은 사용자의 의도를 미리 구조화하고, 필요한 선택지를 화면에 드러낸다. 핵심 주장: 소프트웨어는 죽지 않고 층위가 바뀐다 원문은 \u0026ldquo;소프트웨어가 죽었다\u0026quot;는 주장에 선을 긋는다. 이유는 두 가지다.\n첫째, 에이전트는 모든 일을 자동화하지 못한다. 반복적이고 검증 가능한 작업은 빠르게 흡수되지만, 애초에 어떤 문제인지 정의하고, 어디에 위험이 숨어 있는지 찾고, 틀린 프레임을 고치는 일은 계속 남는다.\n둘째, 에이전트가 어떤 일을 처리할 수 있더라도 사용자는 늘 채팅창으로 일하고 싶어 하지 않는다. 프롬프트는 CLI처럼 강력하지만, 사용자에게 시스템의 구조를 머릿속에 들고 있으라고 요구한다. 반면 좋은 앱은 가능한 행동, 상태, 제약, 다음 선택지를 화면에 배치해 인지 부담을 줄인다.\n그래서 미래의 앱은 \u0026ldquo;모델을 감싼 UI\u0026quot;가 아니다. 앱은 조직과 사용자가 축적한 판단에 접근하는 인터페이스가 된다.\n기반층: 모델이 아니라 판단이 쌓이는 곳 원문에서 중요한 개념은 substrate다. 여기서는 기반층이라고 부를 수 있다.\n기반층은 단순한 데이터베이스가 아니다. CRM은 고객 정보를 담고, ERP는 운영 정보를 담고, Git은 코드를 담는다. 기반층은 여기에 더해 다음 같은 것을 담는다.\n왜 이 결정을 했는가 예전에 시도했지만 실패한 방법은 무엇인가 어떤 예외 케이스를 조심해야 하는가 이 조직만의 업무 방식과 품질 기준은 무엇인가 자동화가 어디까지 해도 되고, 어디서 멈춰야 하는가 모델은 갈아 끼울 수 있다. 하지만 이런 판단의 흔적이 사라지면 조직은 매번 처음부터 다시 배운다. 반대로 기반층이 잘 쌓이면 에이전트는 새 모델로 바뀌어도 \u0026ldquo;회사 베테랑\u0026quot;처럼 행동할 수 있다.\n이 관점에서는 경쟁력이 모델 선택에서 나오지 않는다. 우리만의 판단이 어디에, 얼마나 명시적으로, 얼마나 재사용 가능하게 쌓이는가가 더 중요하다.\n카메라 모드와 엔진 모드 원문은 에이전트 작업을 두 모드로 나눈다.\n엔진 모드는 실행이다. 구조가 이미 정해져 있고, 검증 방법도 있으며, 실패해도 되돌릴 수 있는 작업에 맞다. 예를 들면 기존 패턴에 맞춰 기능을 추가하거나, 타입 오류를 고치거나, 반복 변환을 수행하는 일이다.\n카메라 모드는 탐색이다. 파일을 읽고, 맥락을 모으고, 이상한 디테일을 발견하고, 질문을 다시 세우는 일이다. 이 모드는 느려 보이지만 현실을 더 많이 본다.\n문제는 엔진 모드가 카메라 모드가 필요한 영역으로 밀고 들어갈 때 생긴다. 에이전트가 코드베이스의 숨은 불변식을 모른 채 대규모 리팩터링을 끝내고, 테스트는 통과했지만 몇 주 뒤 운영에서 장애가 나는 식이다.\n따라서 에이전트 활용의 고급 기술은 \u0026ldquo;더 많이 자동화하기\u0026quot;만이 아니다. 더 중요한 기술은 지금 이 일이 엔진 영역인지, 카메라 영역인지 구분하는 것이다.\n자동화의 오래된 실패 패턴 에이전트는 지식 노동을 위한 자동화다. 그러면 과거 자동화가 겪은 문제도 다시 나타난다.\n자동화는 반복 업무를 흡수한다. 농업 기계는 농업 인력을 줄였고, ATM은 은행원의 반복 업무를 줄였다. 하지만 남은 일은 사라진 일과 같지 않았다. 농업에는 작물 계획, 병충해 판단, 장비 의사결정이 남았고, 은행에는 관계 관리, 사기 탐지, 문제 해결이 더 중요해졌다.\n지식 노동도 비슷하다. 에이전트가 반복 업무를 처리할수록 인간에게 남는 일은 더 모호하고, 더 예외적이고, 더 판단 중심적인 일이 된다.\n여기서 Bainbridge paradox가 중요해진다. 자동화가 좋아질수록 사람은 감시에서 빠진다. 그런데 자동화가 자신의 한계를 벗어났을 때는 바로 그 사람의 판단이 필요하다. 즉, 자동화는 사람의 개입을 줄이지만, 실패 순간에는 더 높은 품질의 개입을 요구한다.\n그래서 기반층은 단지 지식 저장소가 아니라 안전장치다. 코드에서는 테스트, 타입, rate limit, 권한 제한이 된다. 조직에서는 승인 흐름, 사고 기록, 체크리스트, 예외 처리 규칙이 된다.\n왜 앱은 계속 필요한가 사용자는 \u0026ldquo;기계에게 일을 시키는 법\u0026quot;을 배우고 싶은 것이 아니다. 일을 끝내고 싶을 뿐이다.\n채팅 기반 에이전트는 사용자가 먼저 질문을 떠올리고, 맥락을 설명하고, 원하는 결과를 언어로 구성해야 한다. 이는 강력하지만 피곤하다. 좋은 앱은 반대로 사용자가 해야 할 일을 줄인다. 현재 상태를 보여주고, 가능한 조작을 제한하고, 필요한 정보를 적절한 위치에 놓고, 다음 행동을 예측한다.\n그래서 에이전트 이후의 앱은 사라지는 것이 아니라 더 깊어진다.\n화면 위에는 여전히 버튼, 목록, 상태, 승인, 편집 도구가 있다. 화면 아래에는 에이전트가 자료를 찾고, 초안을 만들고, 예외를 감지하고, 반복 업무를 처리한다. 그 사이에는 기반층이 있어 에이전트가 조직의 판단을 읽고 다시 기록한다. 앱은 에이전트를 숨기는 포장지가 아니다. 앱은 사용자가 기반층과 상호작용하는 안정적인 표면이다.\nBuild vs Buy 기준의 변화 예전의 build vs buy 판단은 주로 비용과 시간의 문제였다. 개발이 비싸고 느리면 SaaS를 샀다. 특별한 요구가 있거나 시장에 없는 기능이면 직접 만들었다.\nAI가 코딩 비용을 낮추면 질문이 바뀐다. 이제 핵심은 \u0026ldquo;만드는 데 얼마나 드는가?\u0026ldquo;보다 **\u0026ldquo;어떤 판단을 우리 안에 쌓아야 하는가?\u0026rdquo;**다.\n모두가 비슷하게 하는 일은 SaaS가 맞다. 이메일, 캘린더, 기본 생산성 도구처럼 범용 베스트 프랙티스가 중요한 영역에서는 외부 제품의 집계 학습을 쓰는 편이 낫다.\n반대로 경쟁 우위와 연결된 프로세스는 내부에 남겨야 한다. 고객을 이해하는 방식, 운영의 예외 처리, 품질 기준, 의사결정 흔적이 차별화라면 그 기반층은 남의 SaaS 안에서만 자라게 두면 안 된다.\n질문은 \u0026ldquo;SaaS가 내 데이터를 가져가는가?\u0026ldquo;에서 멈추면 부족하다. 더 날카로운 질문은 이것이다.\n내게 중요한 결정들이 어디에서 복리로 쌓이고 있는가?\n실무적으로 가져갈 것 이 글을 에이전트 제품이나 내부 도구 설계에 적용하면 몇 가지 기준이 나온다.\n에이전트에게 맡길 일과 사람이 계속 봐야 할 일을 구분한다. 자동화 결과만 저장하지 말고, 판단의 이유와 예외를 같이 남긴다. 프롬프트 입력창을 기본 UI로 두지 말고, 사용자의 반복 의사결정을 화면 구조로 흡수한다. 모델 교체 후에도 유지되어야 하는 지식을 코드, 테스트, 문서, 워크플로에 남긴다. 자동화가 실패할 때 피해를 줄이는 권한 경계와 승인 흐름을 둔다. 에이전트 시대의 앱 설계는 \u0026ldquo;얼마나 똑똑한 모델을 붙였는가\u0026quot;가 아니라 \u0026ldquo;얼마나 좋은 판단 축적 시스템을 만들었는가\u0026quot;로 평가될 가능성이 크다.\n결론 및 시사점 한 줄 결론: 에이전트 이후에도 앱은 남는다. 다만 앱은 기능 묶음이 아니라, 조직의 축적된 판단과 에이전트 실행을 연결하는 인터페이스가 된다.\nApps After Agents가 던지는 메시지는 낙관과 회의 사이에 있다. 에이전트는 실제로 많은 일을 자동화한다. 하지만 자동화가 커질수록 경계 판단, 예외 기록, 사용자 경험, 안전장치의 중요성도 같이 커진다.\n결국 소프트웨어의 방어력은 모델 호출 그 자체가 아니라, 그 호출이 기대고 있는 기반층에서 나온다. 어떤 조직은 모델을 쓰고도 매번 새로 시작할 것이고, 어떤 조직은 모델이 바뀌어도 판단이 계속 쌓이는 시스템을 갖게 될 것이다. 그 차이가 에이전트 이후의 앱 경쟁력을 만든다.\n","wordCount":960,"tags":["AI","에이전트","앱","자동화","소프트웨어","Substrate"],"categories":["AI"],"frameworks":["Camera/Engine Mode","Automation Boundary","Substrate"],"mental_models":["Bainbridge Paradox","Frame Problem","Build vs Buy"],"philosophy_type":"engineering-strategy","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["모델은 점점 교체 가능한 입력이 되고, 조직이 축적한 판단과 예외 기록이 진짜 방어력이 된다.","에이전트는 반복 가능한 엔진 영역을 잘 처리하지만, 무엇을 볼지 정하는 카메라 영역은 계속 인간의 판단을 요구한다.","앱은 프롬프트 입력창으로 대체되는 것이 아니라, 축적된 판단에 접근하는 설계된 인터페이스로 남는다.","SaaS와 내부 구축의 기준은 비용이 아니라, 어떤 결정이 우리 조직 안에서 복리로 쌓여야 하는가로 바뀐다."],"related":["posts/loop-engineering.md","posts/ai-agents-future-context-gap.md","posts/todays-harness-is-tomorrows-prompt.md"]}