모델이 3개월 6개월마다 바뀔 때 하니스를 어떻게 구현할 것인가?

현대 agent 시스템에서 “지능”이 들어갈 곳은 두 군데:

1. 모델(사전학습+RL 등으로 학습된 능력)
2. 하니스(워크플로, 라우터, 서브에이전트, 도구, 핸드오프, 코드 실행 등)

많은 팀이 “모델이 아직 불안정 → 하니스에 신뢰성을 박자”로 가는데, 이는 장기적으로 “스케일되는 곳(모델)”에서 “스케일 안 되는 곳(맞춤 scaffolding)”로 복잡도를 이동시키는 위험이 있다.

모델 성능이 2배 좋아졌을 때, 하니스가 급격히 단순/저렴/안정**해지는가? 아니면 그래프/규칙/역할이 그대로 남는가?

안티패턴

Workflow Trap (워크플로 함정)

- Anthropic은 “워크플로(사전정의된 경로)”와 “에이전트(모델이 동적으로 도구/과정을 결정)”를 구분하며, 워크플로는 예측 가능하지만 에이전트는 더 유연하다고 정리한다.
- 드래그앤드롭 그래프(“research→summarize→draft”)는 지금의 모델 실패모드에 맞춰 **조직/코드가 고착**되기 쉬워, 모델이 좋아져도 시스템이 덜 복잡해지지 않는다.

Specialized Subagent Illusion (고정 역할 서브에이전트 환상)

- Researcher/Coder/Writer 같은 **고정 역할**은 인간 조직의 제약(인지 한계/커뮤니케이션 비용)을 그대로 수입할 위험이 있다.
- “전문가 구성을 아키텍처에 ‘고정’하지 말라”

단순 루프의 확장 한계

- “LLM+while loop+tools면 충분”은 단기엔 단순하지만, 스케일링 노브가 반복 횟수로 단일화되면 병렬화/구조화/컴퓨트 배분이 어려워 토큰 낭비가 커질 수 있다.
- 태스크 난이도↑에 따라 (a) 평균 iteration 수, (b) 성공률, (c) 비용이 어떻게 스케일되는지—특히 병렬 분기 없이 감당 가능한지.

Bitter Lesson Align인가?

Dynamic Subagent Spawning (동적 서브에이전트 생성)

- Anthropic의 멀티 에이전트 리서치 시스템은 리드 에이전트가 계획을 세우고, 병렬 서브에이전트를 만들어 탐색/수집을 수행하는 구조를 설명한다.
- LangChain의 Deep Agents는 서브에이전트/파일시스템/프롬프트/툴을 조합해 “더 길고 깊은 작업”을 수행하는 패턴을 제시한다.
- 핵심은 “팀 구조를 미리 정해두는 것”이 아니라, 추론-시간(inference-time) 탐색으로 분해를 ‘찾게’ 하여 컴퓨트를 더 좋은 의사결정으로 바꾸는 것.

RLM(Recursive Language Models): 긴 컨텍스트를 ‘환경’으로 보고 재귀적으로 다룸

- RLM 논문은 긴 프롬프트를 외부 환경으로 두고, 모델이 코드/재귀 호출로 필요한 부분을 선택적으로 조사·분해하는 일반 추론 전략을 제안한다.
- Prime Intellect는 RLM을 “2026 패러다임”으로 강조하며 자체 구현/환경을 언급한다.
- 에세이는 RLM을 “워크플로 고정”보다 Bitter Lesson에 더 맞는 예로 본다: 더 많은 컴퓨트가 재귀 깊이/분해 granularity/선택적 읽기 같은 다차원 노브로 연결되기 때문.

https://x.com/buckeyevn/status/2014171253045960803

Claude code - 개발자

claude code for designer 제품들도 계속 나오는중

https://www.pencil.dev/
https://x.com/variantui

Claude code for Marketer
https://hightouch.com/

결국 코드는 언어였고, 언어로 저장된 파일 시스템에 적절한 하니스들을 구축하면 AI Agent들이 일을 알아서 내 입맛에 맞게 해주는 게 가능하다는 게 증명되었으니까. 올해는 Agent for 특정 직군(Marketer, Designer, Doctor, Lawyer etc)가 쏟아져 나올듯.

사실 GPT나온 뒤에 이게 쏟아져나왔었는데 당시에 이런 것들이 부족해서 고객에게 와우를 주지 못했는데.

1. 모델 성능(리즈닝 그리고 도구 사용)이 워낙 좋지 않았고
2. Unstructural Data들을 어떤식으로 가공하고 컨텍스트 엔지니어링을 어떻게 해야하는지

그래도 GPT+RAG를 붙여주는 것만으로도 꽤 쓸만함을 느꼈었다. 덕분에 Vertical AI(Legal, Medical, CS)들이 빠르게 컸다.

1. 지금은 모델이 아주 좋아지고 있고
2. 컴퓨팅 비용 더 낮아지고 있고 -> 더 오래 리즈닝하거나 더 많은 agents를 더 싸게
3. 컨텍스트 엔지니어링/하니스 너무 다양해지고 있고
코딩 에이전트가 꽤 좋아져서 위에 세가지가 가속화되고 있어서

물어보고 답변받는 채팅의 시대에서 알아서 내 의도를 파악하고 여러개의 agent끼리 협업하면서 잠도 안자고 내 목적을 알아서 완수해주는 Agent 제품들이 쏟아져나오고 있다.

2년전에 너무 일찍 시작해서 망한 제품/사업들이 지금 모델과 하니스면 꽤 Wow한 경험들을 줄 수 있을 것 같다.

그런 점에서 올해는 AI Agents for Vertical, AI Agents orchestration 제품들이 벌써부터 주목 받는중.

클로드 코드에서 에이전트 5개정도 넘어가면 여러 부서 미팅을 연달아 하는 기분을 받을 수 있는데 이런 distraction을 관리해주는 제품들이 사용자들에게 좋은 피드백을 받는 중.

https://www.conductor.build/

직무 변화는 현실인듯. 이제 PM/디자이너의 비중이 확줄고 개발자들이 PM하는 게 일반화될 것 같네. 스포티파이도 계층 다 없애고 빌더+의사결정권자로 바꿨던데 조직을 AI Agent First로 설계하지 않으면 살아남을수 없다.

—

제품 관리자(PM): 더 이상 정확히 무엇을 만들지 지시하지 않습니다. 대신 고객의 니즈를 가장 높은 수준에서 명확히 하고 "Why(이유)의 수호자" 역할을 합니다. 그들은 직접 프로토타이핑을 하고 엔지니어와 함께 코드를 확인하는 등 실무에 참여해야 합니다.

엔지니어 & 디자이너: 역할이 합쳐지고 있습니다. 모델이 너무 빠르게 진화하기 때문에 엄격한 명세서는 작동하지 않습니다. 제품은 엔지니어, 연구원, PM이 코드 상에서 직접 작업하며 만들어집니다.

디자이너의 경우: 기업들은 엔지니어 대비 디자이너 채용을 줄이고 있습니다. 디자인 시스템이 확립되면 AI가 그 언어를 활용해 작업을 수행할 수 있기 때문입니다. PM/디자이너 대 엔지니어의 비율은 1:3 또는 1:10에서 1:20으로 이동하고 있습니다.

소프트웨어가 "비결정론적(non-deterministic)"이 되고 있다고 언급했습니다. 이것이 제품 관리에 의미하는 바는 무엇입니까?

과거에 소프트웨어는 결정론적이었습니다. 사용자가 X를 하면 Y가 발생했죠. 지금은 사용자가 X를 하면 Y가 발생하지만, 미세한 차이로 인해 완전히 다른 결과가 나올 수도 있습니다. 이로 인해 평가(Evals)가 필요합니다. 다양한 사용 사례에서 소프트웨어의 출력이 합리적인지 누군가 평가해야 합니다. PM은 이제 이러한 평가를 담당하며, 사람이 수동으로 확장할 수 없기 때문에 다른 AI의 결과를 평가하기 위한 AI 스크립트를 직접 작성하기도 합니다.

AI 생성 속도가 빨라짐에 따라, 미래에도 유효한 인간의 기술은 무엇입니까?

판단력(Judgment)입니다. AI 엔진이 무한한 양의 코드("AI slop" - AI가 쏟아내는 저질 코드/부산물)를 생산해낼 때, 중요한 질문은 "이 중 무엇이 중요한가?"가 됩니다.

제품 측면: 무엇을 만들지 결정하고 결과물의 품질을 평가하는 데 판단력이 필요합니다.
엔지니어링 측면: AI가 작성했더라도 버그와 취약점을 검토하기 위해 판단력이 필요합니다.
디자인 측면: 결과물이 더 넓은 디자인 시스템에 부합하는지 확인하기 위해 판단력이 필요합니다.

무한한 생산성의 시대에, 판단력은 우리가 '무엇에' 생산적이어야 하는지를 결정합니다.

Q: 제품 관리에 대한 당신의 핵심 철학은 무엇입니까?

A: 제품 관리자의 업무는 고객의 니즈와 비즈니스 니즈의 균형을 맞추는 것입니다. 그들은 "Why"의 파수꾼입니다.

왜 이것을 만드는가? (고통의 강도와 깊이)
이것이 회사에 어떻게 가치를 더하는가?
고객은 좋아하지만 비즈니스 가치를 파괴하는 것이나, 비즈니스에는 도움이 되지만(예: 가격 인상) 고객에게 해를 끼치는 것을 만드는 것은 피해야 합니다.

Q: 제품의 성공을 어떻게 정의합니까?
A: 성공은 결과(Outcomes), 구체적으로는 고객 행동(Customer Behavior)으로 정의됩니다. 고객 행동은 비즈니스 성과의 선행 지표입니다. 모든 기능 출시는 행동 변화에 근거한 가설(예: "이것을 출시하면 고객이 X를 하던 것에서 Y를 하는 것으로 바뀔 것이다")을 가지고 있어야 합니다.

Q: 오늘날 창업자들은 새로운 AI 애플리케이션 구축을 어떻게 공략해야 합니까?

깊고 설득력 있는 문제 찾기: 고임금을 받는 사람들이 반복적인 업무를 하는 산업(예: 법률, 건축)을 찾으세요.
고가치 워크플로우 타겟팅: 워크플로우는 깊고 복잡하며 맞춤형 데이터가 필요해야 합니다.
내구성(Durability) 목표: 만약 "가벼운" 것을 만든다면, 파운데이션 모델(Gemini나 ChatGPT 등)이나 수평적 도구들이 당신을 집어삼킬 것입니다. 당신의 솔루션이 상당히 깊지 않다면, CIO들은 자체 엔지니어와 수평적 도구를 사용할 것입니다.

Q: AI 시대에 "내구성" 또는 "접착성(Stickiness)"을 구성하는 요소는 무엇입니까?

A: 넷-뉴(net-new) 소프트웨어를 만드는 마찰이 매우 낮아졌기 때문에 생존하려면 다음과 같은 특정 자산이 필요합니다.

희소 자산 소유: 라이선스, 특정 규제에 대한 통찰력, 또는 독보적인 인재(예: 누구와도 미팅을 잡을 수 있는 Brett Taylor를 보유한 Sierra).
통제 지점(Control Points): 사람들이 돈이나 데이터와 상호작용하는 방식을 통제하는 것.
하드웨어: 교체하기 어려운 것(예: Toast의 POS 기기).
필수 워크플로우: 운영 깊숙이 내재화되는 것.
네트워크 효과: DoorDash(소비자, 식당, 배달원)와 같은 것.

Q: 레거시 "기록 시스템(System of Record)" 기업들(Salesforce, Slack 등)은 AI 스타트업에 어떻게 반응하고 있습니까?

A: 그들은 AI 스타트업이 자신들을 "멍청한 데이터베이스" 취급하는 것을 막기 위해 반격하고 있습니다. 그들은 다음과 같은 조치를 취합니다.
API 접근 차단(예: Slack이 Glean을 차단).
자체 AI 에이전트 무료 번들링 제공.
데이터 접근에 높은 비용 부과.
결과: AI 스타트업은 더 이상 레거시 소프트웨어 위에 "행동 시스템(System of Action)"만 구축할 수 없습니다. 기록 시스템 전체를 대체하는 것을 목표로 해야 합니다.

Q: 레거시 소프트웨어 기업들의 리스크는 무엇입니까?

고위험: 유틸리티/좌석(seat) 기반으로 가격을 책정하는 기업(예: Zendesk). AI 에이전트가 인간 상담원의 필요성을 줄이면 매출이 급감합니다. 그들은 성과 기반 가격 책정으로 전환해야 하는데, 상장 기업으로서 이는 어려운 전환입니다.

저위험: 불변의 데이터를 보유한 기업(예: NetSuite 같은 ERP). CIO가 ERP를 뜯어고치는 것은 커리어에 치명적일 수 있으므로 접착성이 높습니다.

Q: AI 스타트업은 어떻게 Salesforce처럼 접착성 높은 레거시 시스템과 경쟁합니까?

A: 마이그레이션 도구를 구축해야 합니다. 기존 시스템의 데이터를 당신의 시스템으로 매끄럽게 옮기는 스크립트를 만드는 것은 엄청난 노력(종종 1~2년의 엔지니어링)이 듭니다. 고객은 자신의 기록을 남겨두고 떠나야 한다면 움직이지 않을 것입니다.

Q: 리더는 팀과 어떻게 소통해야 합니까?

주간 전체 회의(All-Hands): 작은 팀이라도 문화 형성에 필수적입니다.

주간 CEO 이메일: 이것은 매우 중요합니다. 세 부분으로 구성되어야 합니다.
화두(Top of Mind): 제품, 비즈니스, 팀과 관련해 CEO가 고민하는 것 (이메일의 60-70% 할애).
성과 업데이트: 회사가 어떻게 하고 있는지 투명한 지표 공유.
기타: 팀원 인정, 고객 인용구 등.
조언: 솔직해지세요. 메시지가 스며들기 위해서는 반복이 필요합니다.

Q: 이 새로운 시대에 어떤 유형의 사람이 성공합니까?

A: 실행가(Doers)와 빌더(Builders). 가장 가치 있는 기술은 수많은 AI 에이전트를 지휘할 수 있는 기능 전문가가 되는 것입니다.

기업은 사람 관리만 하는 관리자 채용을 중단해야 합니다.
관리 범위(Span of Control): 관리자는 10명 이상을 관리하거나, 개별 기여자(IC)가 되어야 합니다. 좁은 관리 범위는 비효율적입니다.

Q: 이러한 특성을 어떻게 면접에서 확인합니까?

A: 실무 과제(Work Projects)를 부여하세요(엔지니어뿐만 아니라).
예시: 기업 개발(Corp Dev) 후보자에게 인수할 회사를 식별하고 시너지를 분석하도록 요청하세요.
찾아야 할 것: 주체성(Agency)과 고객의 목소리를 보여주는 후보자.
최고의 답변: 직접 고객과 대화해 보니 그 기능을 원하지 않는다고 말하며, 과제의 전제 자체를 거부하는 후보자.

https://youtu.be/JUsb1FYOstA

AI Agent/LLM 관련 연구를 하거나 제품을 만드는 분들끼리 점심 먹어요!

최근까지 Manus에서 Agent Research/Building을 했던 Ivan Leo (https://ivanleo.com/)이 한국에 머물러서 LLM, AI Agents Research, Engineering하는 분들끼리 소규모로 모일 예정입니다! 행사는 아니고 금요일 점심 먹으면서 각자 연구/개발하는 거 공유해요!

몇자리가 남아서 관심있는 분들 신청해주시면 감사하겠습니다!

https://lnkd.in/gHbX_ZzA

소프트웨어의 신문화: 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) — 각 영역에서 신뢰를 먼저 확보한 자가 수요를 독점한다.

4. 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

전력, 컴퓨터, 데이터, 모델 중에서 모델은 이미 중국에 있는 중국인과 미국에 있는 중국인들이 만드는 것이 되었고 이제 컴퓨터만이 병목이고 전력과 데이터는 중국이 앞서 있다.

중국이 칩까지 만들거나 안정적으로 수급할 수 있다면 과거 일본 자동차가 자동차 시장을 석권했던 것처럼 토큰 x 하드웨어까지 정복할지도 모르겠다.

일본의 자동차 산업과 중국의 AI: '제약'이 만든 경쟁력
1970년대만 해도 일본의 자동차 산업이 승자가 될 것이라 예상하는 사람은 많지 않았습니다. 일본은 자국 내 석유 자원이 거의 없었고, 엔진 기술력 또한 뒤처져 있었기 때문입니다. 하지만 바로 그 자원의 부족이라는 제약 때문에 일본 자동차 제조사들은 단 한 방울의 연료에서도 최대의 효율을 짜내야만 하는 명확한 선택의 기로에 섰습니다.

그들은 소배기량 고효율 엔진을 최적화하기 시작했고, 더 가벼운 설계와 정밀한 제조 공정 제어 기술을 도입했습니다. 마침내 1973년 오일쇼크가 발생하고 연료 가격이 폭등하자, 마력만 높은 미국의 대형차들은 가계에 큰 부담이 되었습니다. 반면, 과거 일본이 제약에 떠밀려 어쩔 수 없이 선택했던 효율 지향적 전략은 뜻밖의 강력한 이점이 되었습니다. 그 결과 일본 자동차 산업은 이후 약 50년 동안 눈부신 전성기를 누리게 됩니다.

오늘날 중국의 AI 기업들도 오랫동안 GPU 수급 제한이라는 제약을 겪어왔습니다. 하지만 이러한 제약은 오히려 그들이 모델 경량화에 더 공격적으로 매달리고, 추론 효율성을 최적화하며, 공학적 실행력을 극한까지 끌어올리게 만드는 동력이 되었습니다. 동일한 대화를 처리하더라도 더 적은 컴퓨팅 자원을 사용함으로써 토큰당 비용을 낮춘 것입니다.

향후 전력 인프라와 데이터 센터 구축 측면에서도 중국은 태양광, 철강, 가전 분야에서 그랬던 것처럼 강력한 비용 우위를 점할 가능성이 높습니다. 미래에 중국은 세계 최대의 '토큰(Token) 수출국'이 될지도 모릅니다.

https://x.com/mablejiang/status/2020904698321174864?s=46&t=h5Byg6Wosg8MJb4pbPSDow

요즘 코딩하는 방식이 완전히 달라졌습니다.

주변 개발자들을 보면 지난 10월쯤부터 확 바뀌었어요. CLAUDE.md에 에이전트 행동 규칙을 적어두고, 태스크를 나눠서 여러 에이전트에게 분배하고, 그 결과물도 에이전트가 리뷰하게 하더라고요. 한명이 코딩 Agent 공장을 돌리면서 몇개월 걸릴 일을 몇시간만에 합니다.

직접 코드를 짜는 시간보다 에이전트들이 잘 움직이게 판을 짜는 시간이 훨씬 길어진 거죠. 한 명이 수십 개 에이전트를 돌리면서 소프트웨어를 만드는 게 꽤 일반화됐습니다. 펀치카드로 코딩하던 사람들이 GUI를 처음 봤을 때 이런 기분이었을까 싶어요.

근데 이게 아직은 개발자들만의 이야기거든요.

최근에 OpenClaw 써보신 분들은 아시겠지만, 비개발자분들 반응이 장난 아니었습니다. 채팅으로 AI에게 일을 시키면 여러 웹사이트랑 소프트웨어를 오가면서 결과를 가져오는데, 이걸 보고 "AGI 체감했다"는 말이 나올 정도였어요. 개발자들이 터미널에서 하네스 짜서 겨우 하던 걸, 채팅창 하나로 하니까 그런 반응이 나온 거죠.

OpenClaw를 보면서 느낀 게 있습니다. 사람들이 원하는 건 에이전트 기술 자체가 아니라, 자기가 익숙한 방식으로 에이전트를 부리는 것이더라고요. 터미널이 어려운 사람이 대부분인데, 그 허들만 넘겨줘도 가치를 확 느낍니다.

시장을 보면 흐름이 꽤 선명합니다. Lovable, Bolt, Manus나 Genspark 같은 바이브코딩 도구가 "코드를 대신 짜준다"는 가치를 증명했고 거기서 한 발 더 나아가서 "일을 대신 해준다"는 걸 보여줬습니다. 실제로 연 천억 이상 매출을 만들고 있고요.

다음 스텝이 뭘까 생각해보면, 결국 내 맥락을 깊이 이해하면서 여러 도구를 넘나들며 진짜 내 일을 처리해주는 에이전트인 것 같습니다. "만들어줘"에서 "알아서 해줘"로 넘어가는 거죠. 개인이 여러 AI 에이전트에게 업무도 시키고 상담도 받고 일상의 일들을 맡기는 게 올해 안에 훨씬 보편화될 거라고 봅니다.

이걸 만들려면 재밌는 기술 문제들이 있습니다. 에이전트한테 자율성을 충분히 주면서도 안전하게 돌아가는 샌드박싱을 어떻게 설계할 건지. 모델마다 잘하는 게 다른데 유저 요청에 맞춰서 최적 조합을 어떻게 찾을 건지. 에이전트가 맥락을 잃지 않으면서 이 앱 저 앱을 넘나들게 하려면 구조를 어떻게 잡아야 하는지. 기술적으로 되는 것과 사람들이 진짜 쓰는 것 사이의 갭을 어떻게 빠르게 좁힐 건지.

한국에 이미 자기만의 에이전트 오케스트레이션을 깎고 계신 분들이 꽤 많다는 걸 알고 있습니다. 근데 대부분 본인 작업용이거나 사내에서만 쓰고 계시더라고요. 그 경험이면 전 세계 유저들의 일상을 바꾸는 제품을 만들 수 있다고 생각합니다.

저는 2번 창업을 했습니다. 블록체인 지갑 회사랑 제조업 대상 AI 솔루션 회사를 했고, 외부 투자 없이 누적 120억 매출을 만들었습니다. 솔직히 그 과정에서 첫 창업자가 할 수 있는 실수란 실수는 다 해본 것 같아요. PMF를 찾겠다고 여러 번 방향을 틀었고, 그때마다 배운 게 결국 지금의 판단력이 됐습니다.

이번에 새로 시작하게 된 건 주변 비개발자분들 때문입니다. OpenClaw로 회사 업무를 자동화하거나, 이전에는 개발자한테 부탁해야 했던 일들을 직접 AI에게 시키는 걸 보면서 — 이 사람들이 ChatGPT 쓸 때랑은 확실히 다른 가치를 느끼고 있다는 걸 알게 됐어요. 이건 단순한 도구가 아니라 일하는 방식 자체가 바뀌는 거구나, 싶었습니다.

지금은 AI 에이전트의 새로운 인터페이스를 찾아가는 시기라고 생각합니다. 엄청나게 빠르게 실험하면서 비개발자들의 일상에 실제 변화를 만들 수 있는 타이밍이에요. 당신이 오늘 만든 것이 그게 필요한 사람에게 바로 임팩트를 줄 수 있는, 그런 시기입니다.

이런 분이랑 이야기해보고 싶습니다.

에이전트 오케스트레이션이나 프롬프트 설계를 깊이 파보신 분
샌드박싱이나 권한 설계처럼 "안전하지만 유용한" 실행 환경을 고민해보신 분
기술 가능성보다 사람들이 실제로 쓰는 제품을 만드는 데 집중하시는 분
초기 스타트업에서 빠르게 실험하고 방향을 잡아가는 과정을 즐기시는 분

편하게 커피 한 잔 하면서 이야기 나눠보면 좋겠습니다.

혹시 주변에 이 사람은 꼭 만나야한다고 생각하는 분을 소개해주시면 사례하겠습니다. 널리 퍼질 수 있게 좋아요. 댓글 부탁드려요!

스웨덴, 싱가폴 회사 말고 한국 사람들도 글로벌 서비스를 만들어볼 수 있는 시기입니다 🙂

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)
위대한 디자인은 단 한 번에 완성되지 않습니다. 전문가들은 자신의 초기 아이디어가 틀릴 수 있음을 인정하고 끊임없이 수정합니다. 건축가 프랭크 로이드 라이트가 구겐하임 미술관을 설계할 때 초기안을 과감히 뒤집어 현재의 나선형 구조를 만든 것처럼, 잘못된 부분을 기꺼이 버리고 다시 그릴 수 있는 용기가 위대한 결과물을 만듭니다.

이러한 원칙들은 결국 하나의 결론으로 향합니다. 좋은 디자인을 만들기 위해서는 무엇이 나쁜 것인지 알아보는 ‘까다로운 취향'을 길러야 하며, 그 취향을 만족시킬 때까지 멈추지 않는 노력이 필요하다는 것입니다.

하니스가 새로운 소프트웨어 엔지니어링이다

하니스(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 — 어떤 조합이 맞는지 아직 아무도 모른다. 하니스의 가장 불안정한 레이어다.

긴 브라우저 세션과 도구 사용도 한계가 분명하다. 에이전트가 일정시간 넘게 웹을 탐색하면 맥락이 흐려지고, 도구 사용의 정확도가 떨어진다.

오케스트레이션은 더 어렵다. 리드 에이전트가 서브태스크를 나누고 자식 에이전트를 스포닝하는 것. 서로 다른 전문성의 에이전트 팀이 하나의 목표를 향해 협업하는 것. Beads, Gas Town, Claude Agent teams 같은 프로젝트가 이 공간을 탐색 중이다. 아직 초기 단계지만, 이것이 풀리면 하니스의 레버리지는 한 차원 더 올라간다.

하지만 이 미해결 과제들은 동시에 거대한 기회이기도 하다. 에이전트가 만드는 코드의 양이 폭발적으로 늘어나면서 "인간의 엔지니어링 주의력"을 확장하는 문제가 새로운 시장이 된다. AI 네이티브 테스팅, 형식 검증(formal verification), 자동 코드 리뷰 — 에이전트 출력의 품질을 보장하는 시스템의 가치가 함께 올라간다.

하니스는 인간의 판단력과 AI의 실행력이 만나는 인터페이스다.

인지 부하는 줄지 않는다. 코드를 읽는 부하가 하니스를 설계하는 부하로 바뀔 뿐이다. 다만 레버리지가 완전히 다르다. 코드 한 줄은 한 줄의 가치. 하니스 설계 한 시간은 수천 줄의 코드 품질을 결정한다.

문제를 명확히 정의하고, 그것을 풀기 위한 하니스를 설계하고, 자신만의 taste로 품질 기준을 세우는 것. 이 세 가지의 조합이 제품이 되는 시대다.

Manus가 라스트마일을 잡은 건 모델이 좋아서가 아니다. Claude Code가 개발자의 선택이 된 건 Opus가 강력해서가 아니다. Ramp이 30% PR을 달성한 건 코드 생성 능력 때문이 아니다. 전부 하니스 때문이다.

소프트웨어 엔지니어링의 세 번째 패러다임 전환. 천공카드에서 키보드로, 에디터에서 클라우드로, 그리고 이제 — 코드에서 하니스로.

하니스가 새로운 소프트웨어 엔지니어링이다.

클로드 코드를 쓰시건 안쓰시건 그냥 보세요!! 그리고 모르면 에이아이한테 물어보면서 이해하고 경험하세요!

https://youtu.be/EQ-Rnx-k-Ec?si=mceSOPHt6KmzRj5o

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

https://x.com/andrewchen

어느 학교를 나왔는지 어떤 회사를 다녔는지

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

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

“세계적 수준의 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

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차는 그 시스템으로만 가능한 새로운 시장을 만드는 사람이다.

지금 많은 전통 기업은 아직 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를 둘러싼 이야기에는 유난히 극단적인 문장이 많다.
“코딩은 끝났다.”
“이제 누구나 소프트웨어를 만든다.”
“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

즉 소프트웨어 벤더가 파는 것은 단순한 코드 덩어리가 아니다.
그들은 제품만 파는 것이 아니라, 배포, 신뢰, 표준화, 지원, 구매 가능성, 운영 안정성을 함께 판다.

그래서 구현의 병목이 약해지는 것과, 소프트웨어 회사의 경쟁우위가 모두 사라지는 것은 같은 말이 아니다.

더 정확히 말하면 이렇다.

일부 카테고리에선 확실히 압박이 커질 수 있다

특히 좁고 독립적이며 커스터마이즈가 쉬운 워크플로에선 대체가 빨라질 수 있다

하지만 시스템 오브 레코드, 규제 산업, 하드웨어 결합형 소프트웨어, 강한 배포력을 가진 제품군은 훨씬 더 오래 방어될 수 있다

즉 지금은 “소프트웨어의 종말”이라기보다,
어떤 소프트웨어는 약해지고 어떤 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 발전을 보고 개발자의 정체성이 바뀜을 인정. 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

일반 사용자용 최종 형태는 더 “사람 같은 인터페이스”일 수 있다

그는 올해 말쯤 많은 사람이 코드를 “텍스트 폭포”로 읽는 대신, 얼굴(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