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

하니스(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