LLM Wiki

Building the future of agentic infrastructure

Properties2
descriptionAnthropic 3인 대담 — 매니지드 에이전트, 하네스 박형화, 에이전트 정체성, ROI 프레임워크를 다룬 좌담
tagsai-agents, anthropic, harness, youtube

39 min read

출처 https://youtu.be/ksfm6jeTg3Q · 채널 Claude (Anthropic) · 길이 00:16:33 포맷 Anthropic 3인(진행자 1명 + Claude 플랫폼 담당자 Angela·Caitlyn 2명)이 사무실 탁자에 둘러앉아 나누는 캐주얼 대담. 슬라이드 없이 대화만 진행. 원본 자막: raw/transcripts/2026-07-11-building-the-future-of-agentic-infrastructure.en.srt

한눈에 보는 요약

  • 지난 6개월 사이 Claude 플랫폼의 성격이 바뀌었다. 예전엔 “토큰을 넣고 빼는 추론 API”였다면, 이제는 인프라 문제와 하네스 엔지니어링 문제를 대신 떠안아 팀의 비용을 낮추면서 더 많은 지능을 끌어내는 방향으로 진화했다.
  • 매니지드 에이전트가 가장 뜨거운 피드백 대상. 메모리, 아웃컴(outcome), 드리밍 같은 개념에 개발자들이 특히 반응했고, “추상화 레벨이 마음에 든다”는 옛날식 칭찬도 나왔다.
  • 에이전트 정체성은 결국 서비스 계정처럼 진화한다. 에이전트가 목표를 받으면 “A, B, C, D 접근 권한이 필요하다”고 되묻고, 사람이 D는 제외하는 식으로 권한을 조정 — 그 결과가 감사 가능한(auditable) 자체 정체성이 된다.
  • 모델과 인프라가 동시에 성숙해서 지금이 가능해졌다. 비결정성이 줄고 가드레일 안에서 스스로 다음 단계를 판단할 만큼 모델이 좋아졌고, 에이전트를 워크스페이스에 상주(ambient)시켜 오래 돌릴 인프라도 갖춰졌다.
  • 하네스는 점점 얇아지고, 그 위에 “메타 하네스”가 쌓인다. 복잡한 분기 로직으로 모델을 가두던 방식에서 벗어나는 대신, 경쟁하는 다중 에이전트·적대적 2-에이전트·어드바이저(친구에게 전화) 같은 새로운 전략 조합이 등장했다.
  • ROI는 개인 → 팀 → 회사 순서로 올라가라. 처음부터 120개 레거시 프로세스를 노리지 말고, 한 사람의 속도를 올리는 데서 시작해 팀 생산성, 이후 재무/사용자 지표로 단계적으로 확장하는 게 가장 성공적이다.
  • 엔지니어링 팀의 정의도 바뀐다. 사람 수는 비슷하지만, 티켓을 처리하던 다수 엔지니어 구조에서 전원이 “엔드투엔드 설계 의견”을 가진 사람으로, 그리고 자신의 “클라우드(에이전트 무리)“를 오케스트레이션하는 역할로 이동 중이다.
  • 가장 큰 실패 모드는 하이퍼인디펜던스(hyper-independence). 누구나 프로토타입 10개를 값싸게 찍어낼 수 있게 되면서 개인 단위의 산발적 시도가 늘고, 조율되지 않은 채 흩어지는 위험(sprawl)이 생긴다.
  • 미래는 “보이지 않는 공통 기판(substrate)”. 도구를 일일이 골라 쓰는 대신, 선호를 학습한 에이전트가 팀 단위로 존재하며 선제적으로(“이거 고쳐서 PR 올려놨어요”) 일하는 방향. 클라우드 플랫폼은 여기에 아웃컴 + 예산(budget) 개념으로 다가가고 있다.

장면별 상세 설명

[00:01] 1. 지난 6개월, API에서 플랫폼으로

장면 1 — 사무실 탁자에서 대화를 시작하는 세 사람

진행자가 농담처럼 “우리가 API 너드라서 에이전트끼리도 API로 대화해야 한다고 말하는 것”이라며 대화를 연다. 6개월 전만 해도 Claude 플랫폼은 사실상 “추론에 접근해 토큰을 주고받는 API”였고, 비용을 낮추거나 속도를 높이는 부가 도구 정도가 있었을 뿐이다. 최근엔 인프라 문제와 하네스 엔지니어링 문제 자체를 대신 떠안아, 팀이 더 낮은 비용으로 더 많은 지능을 뽑아낼 수 있게 하는 “정말 풍부한 기능”들을 플랫폼 안에 넣기 시작했다는 게 이번 대담의 출발점이다.

[00:51] 2. 가장 흥미로운 고객 피드백 — 매니지드 에이전트

진행자가 Angela에게 최근 가장 인상적인 고객 피드백 패턴을 묻는다. Angela는 자신이 프로덕트를 담당한 매니지드 에이전트에 대한 반응이 가장 뜨거웠다고 답한다. 특히 메모리, 아웃컴, 드리밍 같은 개념에 대한 피드백이 좋았고, 개인적으로 제일 마음에 들었던 건 한 개발자가 “그냥 추상화 레벨이 마음에 든다”고 한 다소 올드스쿨한 코멘트였다고 전한다.

[01:24] 3. 에이전트 정체성 — 서비스 계정으로 수렴한다

워크플로우가 계속 진화하는 와중에도 “에이전트 정체성(agent identity)“이라는 개념은 남는다는 질문이 이어진다. 답변자는 에이전트 정체성이 결국 거의 독립된 자기 정체성을 갖는 방향으로 갈 것이라 본다. 아직은 초기 단계라 사람들이 유스케이스를 탐색 중이고 에이전트에게 줘야 할 신뢰의 양도 많지만, 점점 에이전트가 “원하는 아웃컴”을 듣고 나서 “이걸 이루려면 A, B, C, D에 대한 접근이 필요합니다”라고 되묻는 모델로 수렴할 것이라 예상한다. 사람이 “A, B, C는 괜찮지만 D는 건드리지 마”라고 답하면, 에이전트는 그 범위 안에서 사실상 자기 자신을 위한 서비스 계정을 만들어내는 셈이 되고, 그 결과 감사(audit)가 가능해진다. 이게 정체성 레이어가 향하는 운영 모델에 가깝다는 진단이다.

[02:16] 4. 에이전트가 에이전트에게 말을 건다

에이전트끼리 대화하는 흥미로운 지점은, 어떤 에이전트를 만들고 API나 어떤 메커니즘을 노출하면 —사람이 그 에이전트와 상호작용하듯— 다른 에이전트도 똑같이 그걸 호출할 수 있다는 데 있다. 실제로 사용자들이 클라우드 매니지드 에이전트 위에 얇은 MCP 서버를 세워 노출해두면, 다른 에이전트가 “이 에이전트를 어떻게 호출하는지”를 정확히 알고 접근하는 창의적인 사례들이 나오고 있다고 소개한다.

[02:54] 5. 왜 지금 가능해졌나 — 모델과 인프라의 동시 성숙

이런 워크플로우가 왜 이제야 “정당성”을 갖게 됐는지, 모델과 인프라 레벨에서 무엇이 바뀌었는지를 묻는다. 답은 먼저 모델 자체가 좋아졌다는 것 — 예전엔 “이 단계 다음엔 이 단계”라는 표준 절차를 스캐폴딩으로 일일이 짜줘야 했지만, 지금은 모델이 합리적인 가드레일 안에서 스스로 다음에 뭘 해야 할지 판단할 만큼 비결정성 문제가 줄었다. 두 번째는 인프라의 진화 — 에이전트가 워크스페이스에 상주(ambient)하다가 무언가에 의해 트리거되면 스스로 워크플로우를 돌리고 준비됐을 때 돌아오는 구조를 지탱할 인프라가 갖춰졌다. 모델의 진화와 인프라·에이전트 구축 방식의 진화가 함께 일어난 결과라는 정리다.

[03:57] 6. 하네스 레이어가 얇아지고 있다

비결정성이 하네스 레이어를 어떻게 바꿨는지에 대한 질문에 Angela가 답한다. 불과 몇 달 전만 해도 사람들은 “A 단계를 반드시 거쳐야 B로 갈 수 있다”는 식의 아주 복잡한 비즈니스 프로세스 박스를 만들어 모델을 그 안에 가두려 했고, 이는 매우 취약했다. 모델이 더 똑똑해지고 도구 호출과 추론 자체가 깊어지면서, 이제는 하네스의 그 제약적인 부분들을 하나씩 지워도 되는 지점에 도달하고 있다. 그래서 하네스는 시간이 갈수록 점점 얇아지는 추세로 보인다.

[04:42] 7. 메타 하네스 — 경쟁·적대·어드바이저 전략

장면 7 — 하네스 전략을 설명하는 장면

하네스가 얇아지는 동시에 그 위에 일종의 “메타 하네스”(뭐라 불러야 할지 아직 명확하지 않지만, 이를테면 “안장” 같은 것)가 생기고 있다고 Angela는 말한다. 이 메타 하네스는 여러 전략을 조합하는 경향이 있다 — 예를 들어 다중 에이전트가 하나의 문제를 놓고 경쟁하며 풀게 하거나, 두 에이전트를 띄워 한쪽은 아이디어를 내고 다른 쪽은 그것에 적대적으로 반박하게 하는 구조도 있다. 최근엔 어드바이저 전략도 시도했는데, 모델이 스스로 다음에 뭘 해야 할지 모를 때 “친구에게 전화를 걸어” 더 똑똑한 다른 모델의 도움을 구하는 방식이다. 이런 하네스 혁신이 늘어나며, 확장적인(expansive) 아키텍처를 통해 에이전트가 점점 더 복잡한 문제를 풀 수 있게 될 것이라 전망한다. Caitlyn은 이를 “여러 복합 전략을 시간이 갈수록 하이브리드화하는 과정”으로 요약한다 — 처음엔 best-of-N식 확장적 접근으로 시작해, 맞는 프레임워크가 정해지면 그 단일 프레임워크를 반복 개선하는 흐름이다.

각 전략을 보여주는 대표 외부 사례(영상 자체는 URL을 명시하지 않음):

[05:53] 8. 복잡한 문제의 사례 — 공장의 은퇴하는 전문가를 대체하다

장면 8 — 세 사람이 함께 이야기를 나누는 장면

최근 영감을 준 복잡한 문제 사례를 묻자, 한 해커톤 우승작(이름은 아마 “Aria”)이 소개된다. 여러 제조 공장에는 기계를 정말로 이해하는 전문가가 필요한데, 특정 부품이 올라가거나 내려가는지를 모니터링하고 관련 매뉴얼을 읽어야 한다. 전통적으로 이런 일은 공장에서 101520년을 일하며 노하우를 쌓은 단 한 명이 해왔고, 그가 은퇴하면 그 전문성은 사라진다. 이 해커톤 팀은 표준 운영 절차를 업로드하고 공장 곳곳의 신호를 모니터링에 끌어들여, 에이전트가 그 사람의 판단을 흉내 내도록 만들었다. 결국 은퇴로 사라질 뻔한 전문성 상당 부분을 “회사가 의지할 수 있는 축적된 공장 지식”으로 에이전트 시스템에 재현해낸 사례다.

[07:06] 9. Caitlyn의 사례 — 엔드투엔드 개발 에이전트, Shopify의 River

이어 Caitlyn에게 같은 질문이 던져진다. 엔지니어링·개발 팀에서 일어나는 흥미로운 변화는, 사람들이 “코드만 잘 짜주는 것”을 넘어선 에이전트를 만들고 있다는 점이다. Claude Code 같은 훌륭한 제품들이 코드 작성을 잘 해주는 건 이미 당연해졌고, 이제는 프로젝트 시작 단계부터 — 개발 환경을 어떻게 구성해 코드를 테스트할지, PRD(요구사항 문서)를 어떻게 앞단에서 작성할지, QA까지 어떻게 검증할지 — 전 과정을 아우르는 에이전틱 시스템·플랫폼을 회사들이 구축하고 있다. 좋은 예로 Shopify가 최근 공개한 River 라는 엔드투엔드 개발 자동화 사례를 언급하며, 이는 에이전트 역량의 진화가 만들어낸 새로운 국면이라고 짚는다.

[08:23] 10. 조직마다 온도차가 나는 이유 — 보안·컴플라이언스·이밸류에이션

일부 조직은 문제 해결의 “천장”이 크게 올라가는 걸 체감하지만 모든 조직이 그런 건 아니라는 지적에, 진짜 걸림돌이 무엇인지가 논의된다. 첫 번째로 꼽힌 건 사람들이 에이전트에게 일을 맡기려면 갖춰야 하는 보안·컴플라이언스 가드레일 같은 실질적 장벽이고, 두 번째는 기술에서 최대치를 뽑아내기 위한 이밸류에이션(eval) 이다. 보안·컴플라이언스가 특히 큰 이유는, 많은 팀이 20년 전에 통했던 보안 가정 위에서 운영하고 있는데 에이전트가 근본적으로 모든 걸 바꾸고 있기 때문이다. “안전한 에이전트”와 강력한 가드레일이 무엇인지에 대한 기본 개념은 있지만, 그 개념을 언덕 위로 밀어 올리고 체크리스트를 계속 개정하는 일 자체가 하나의 여정이었다고 말한다.

[09:15] 11. 에이전트 ROI — 개인에서 시작해 팀, 회사로

장면 11 — 웃으며 대화하는 장면

기업이 에이전트의 ROI를 어떻게 관리해야 하는지에 대한 질문에 상세한 답이 이어진다. 많은 조직이 곧바로 “우리 회사에 120개쯤 있는 거대한 레거시 프로세스를 어떻게 자동화할까”로 뛰어들고 싶어 하지만, 그건 범위가 너무 넓어 다루기 어렵다. 오히려 ROI 관점에서는 **개인**에서 출발하는 편이 쉽다 — 한 사람이 얼마나 더 빨라지는지에 집중하는 것이다. 단순해 보이지만, 한 사람의 속도를 실제로 끌어올리는 데 성공하면 그걸 **팀 단위**로 확장할 수 있고, 팀 레벨에서 생성되는 속도를 체감하게 된다. 그다음, 그리고 오직 그다음에야 “이 팀을 더 빠르게 만들 수 있다면, 회사 전체의 프로세스로 확장할 수 있을까”를 고민해야 한다 — 실제 프로세스는 표준 운영 절차도, 전문성도 공유하지 않는 여러 팀과 개인이 얽혀 있어 원래 “테이프로 이것저것 붙여놓은” 형태이기 때문이다. 개인 → 팀 → 회사 순서로 속도와 생산성을 쌓아가면, 결국 회사가 원하던 120개짜리 워크플로우 목록을 하나씩 밝혀낼 수 있게 된다. ROI 계산은 재무 지표나 사용자 지표보다 속도(speed)를 먼저 보는 게 훨씬 선행 지표로서 유효하며, 그 흐름이 회사 안에서 무르익은 뒤에야 재무·사용자 지표 같은 후행 지표로 무게 중심을 옮기는 게 순서라고 정리한다.

[11:38] 12. 엔지니어링 팀이란 무엇인가

Caitlyn이 계속 “엔지니어링 팀”이라는 표현을 쓰는 것에 대해, 진행자가 “요즘 엔지니어링 팀이란 대체 뭐냐”고 파고든다. Caitlyn의 답은 — 사람 구성 자체는 6개월 전, 12개월 전과 크게 다르지 않다는 것이다. 시스템을 이해하고, 운영법을 알고, 문제가 생기면 온콜을 서는 사람들이 여전히 필요하지만, 각각의 사람이 에이전트 덕분에 엄청나게 터보차지된다. 변화는 “시스템 설계에 의견을 가진 테크리드 한 명 + 티켓을 받아 처리하는 다수 엔지니어” 구조에서, 거의 모든 사람이 제품·시스템을 엔드투엔드로 어떻게 만들지에 대한 강한 의견을 가진 사람으로 옮겨가고 있다는 점이다. 그리고 그들은 각자 자신의 “클라우드”(에이전트 무리)를 오케스트레이션해 일을 해낸다. 팀의 외형은 비슷해 보여도, 예전보다 압도적으로 더 많은 일을 해낼 수 있게 됐다는 것이다.

[12:46] 13. 실패 모드 — 하이퍼인디펜던스와 산발화

조직에서 에이전트 의존이 만드는 잠재적 실패 모드에 대한 질문에는, “하이퍼인디펜던스(hyper-independence)“라는 개념이 제시된다. 이제 누구나 빌더가 될 수 있다는 감각이 생기고, 예전 같으면 여러 옵션 중 어느 게 최선인지 고민했을 일도 이제는 “이거 싸니까 그냥 10개 다 만들어보고 이긴 걸 고르자”는 식으로 접근이 바뀐다. 이건 모든 개인에게 일종의 하이퍼인디펜던스를 부여하지만, 원래는 더 체계적이고 총체적인 조율에서 나오던 품질이 오히려 조율하기 어려워지는 경향이 생긴다. 모두에게 독립성을 주되 하나의 방향으로 조직화하지 않으면, 산발적으로 흩어지는(sprawl) 결과가 나올 수 있고, 이런 실패 모드는 분명히 존재한다고 짚는다.

[13:39] 14. 퍽(puck)이 향하는 곳 — 보이지 않는 공통 기판

에이전틱 개발의 미래가 어디로 가는지에 대한 질문에는, “조직 안에 너무 깊이 embedded돼서 지금처럼 도구를 뚜렷하게 의식하며 쓰는 방식이 아니게 될 것”이라는 전망이 나온다. 지금은 이 에이전틱 도구, 저 에이전틱 도구를 각각의 장점에 맞춰 골라 쓰지만, 미래에는 모두가 공유하는 공통 기판(substrate) 에 가까워져 익숙한 인터페이스로 에이전트를 태그해 켜고 끄는 정도로 단순해지고, 보이지 않는 곳에서 알아서 많은 일을 해낼 것이다. 심지어 에이전트가 선제적으로 다가와 “이거 다운됐길래 파봤더니 원인을 찾아서 고쳤고 여기 PR 올려놨어요, 검토해보실래요?”라고 먼저 말을 걸 수도 있다. 사람이 미리 “이 정도 사소한 건 그냥 알아서 배포해”라고 알려줄 수도 있다. 이런 세계에서는 사람마다 팀 지향적인 에이전트를 갖게 되지만 그게 “또 다른 동료” 같은 존재라기보다는, 두 사람이 공유하는 워크플로우의 팀 지향성 자체에 대응하는 에이전트에 가깝다 — 세 명이 모이면 또 조금 다른 선호를 이해하는 팀 기반 에이전트가 생기는 식이다. 여전히 공통 인터페이스는 유지되지만, 특정 도구를 능동적으로 찾아 쓰기보다는 하나의 운영체제처럼 느껴질 것이라는 그림이다.

[15:16] 15. 클라우드 플랫폼이 그 비전에 다가가는 법 — 아웃컴과 예산

장면 15 — 대담을 마무리하는 세 사람

클라우드 플랫폼이 이 비전에 어떻게 다가가고 있는지 묻자, 최근 밀어붙이고 있는 핵심 개념 중 하나로 아웃컴(outcomes) 이 소개된다. 클라우드 매니지드 에이전트에 이미 탑재된 이 개념은, “이게 좋은 결과다”라는 루브릭을 클로드에게 주고, 성공적으로 그 결과를 얻어낼 때까지 몇 번이나 반복 시도할 수 있는지를 함께 정해주는 방식이다. 이 개념이 계속 발전하면, 결국 클로드에게 “이런 결과를 원해, 예산은 이 정도야, 가서 해와”라고만 말하고 더 이상 깊이 생각할 필요가 없는 세계에 가까워질 것이라 본다. 예를 들어 “매일 인터뷰 노트를 요약해서 피드백 패킷을 만들어야 한다”면, “노트는 이렇게 좋아야 하고, 이 정도 예산을 쓸 수 있어, 가”라고만 말하면 원하는 결과를 받아볼 수 있게 만드는 것 — 그렇게 애써 생각하지 않아도 되게 만드는 것이 플랫폼이 메우려는 간극이라고 마무리한다. 진행자는 “에이전트의 미래를 이야기하는 게 정말 즐거웠다”며 대담을 마친다.

핵심 개념·용어 메모

  • 에이전트 정체성 → 서비스 계정 모델 — 에이전트가 아웃컴을 받으면 필요한 접근 권한(A·B·C·D)을 스스로 요청하고, 사람이 승인 범위를 좁혀주면 감사 가능한 자체 서비스 계정처럼 동작.
  • 하네스 박형화(thinning) + 메타 하네스 — 복잡한 분기 로직으로 모델을 가두던 방식에서 벗어나는 대신, 경쟁 다중 에이전트·적대적 2-에이전트·어드바이저(친구에게 전화) 같은 전략을 조합하는 상위 레이어가 생김.
  • ROI 프레임워크: 개인 → 팀 → 회사 — 120개 레거시 프로세스로 바로 뛰어들지 말고 개인 속도 개선에서 시작 → 팀 생산성 → 회사 프로세스 순으로 확장. 속도가 재무·사용자 지표보다 선행 지표.
  • 하이퍼인디펜던스 — 프로토타입을 값싸게 여러 개 찍어낼 수 있게 되면서 개인 단위 산발적 시도가 늘고, 조율 없이 흩어지는(sprawl) 실패 모드. → 개념 상세: hyper-independence
  • 아웃컴(outcomes) + 예산(budget) — 클라우드 매니지드 에이전트에 “좋은 결과”의 루브릭과 반복 시도 한도를 주는 개념. 향후 “결과 + 예산”만 말하면 되는 방향으로 발전 전망.
  • 공통 기판(substrate) / 운영체제 비유 — 미래의 에이전틱 개발은 개별 도구 선택이 아니라, 팀 선호를 학습해 선제적으로 일하는 보이지 않는 공통 레이어에 가까워질 것이라는 전망.

등장한 사람·조직·키워드

Anthropic(Claude 플랫폼), Angela(매니지드 에이전트 프로덕트 담당), Caitlyn(엔지니어링/개발 워크플로우 담당), Shopify(River — 엔드투엔드 개발 에이전트 시스템), 해커톤 프로젝트 Aria(제조 공장 전문가 대체 사례), MCP 서버, 매니지드 에이전트, 하네스 엔지니어링.

원문 인용 모음

  • [00:01] “You can tell we’re API nerds because we’re saying agents should talk to each other through API.”
  • [01:00] “I think the most exciting ones have been around managed agents… especially around concepts like memory and concepts like outcomes and dreaming.”
  • [01:24] “I think agent identity will actually probably need to be almost somewhat separate… it’s able to kind of almost create a service account for itself.”
  • [03:57] “Models have obviously just gotten better… the non-determinism of the model used to be a lot more problematic than it is today.”
  • [04:42] “I see harnesses actually getting thinner and thinner over time… multiple agents actually compete to go try and solve a problem together.”
  • [05:53] “This person was actually able to take all of these types of pieces… have agents try to mimic that human judgment.”
  • [07:06] “Shopify recently talked about doing this… with I think they called it River.”
  • [08:23] “Security and compliance guard rails… eval is a big one too in order to actually get the most out of the technology.”
  • [09:15] “I do think that for an ROI point of view, it’s easier to almost start from the individual… you can move from that to then a team.”
  • [12:46] “I do think it does create a sense of like hyperindependence in a way that is maybe slightly false.”
  • [13:39] “It might even actually be proactive. Maybe it’s the one coming to you and saying, ‘Hey, you know, we noticed this thing went down.’”
  • [15:16] “You tell claude like here’s what good looks like, give it a rubric… making that so easy… is the gap that we’re trying to fill.”

이 영상에서 얻을 수 있는 것

바로 써먹을 실무 프레임워크

  • ROI는 개인 → 팀 → 회사 순서로 쌓는다. 회사의 거대한 레거시 프로세스부터 노리지 말고, 한 사람의 속도 향상에서 출발해 팀 생산성, 그다음에야 회사 프로세스로 확장한다.
  • 속도(speed)를 선행 지표로 본다. 재무·사용자 지표는 후행 지표다. 개인·팀 단위 속도가 회사 안에서 무르익은 뒤에 재무·사용자 지표로 무게 중심을 옮긴다.

에이전트 설계·아키텍처 관점

  • 하네스는 얇게 만든다. 복잡한 분기 로직으로 모델을 가두는 방식은 취약하다. 모델이 좋아진 만큼 제약을 하나씩 걷어낸다.
  • 대신 메타 하네스 전략을 조합한다. 경쟁 다중 에이전트, 적대적 2-에이전트, 어드바이저(“친구에게 전화”). best-of-N으로 시작해 맞는 프레임워크가 정해지면 그것을 반복 개선한다.
  • 에이전트 정체성은 서비스 계정처럼 설계한다. 에이전트가 필요한 접근 권한을 스스로 요청하고, 사람이 범위를 좁혀 감사 가능하게 만든다.

조직·리스크 대비

  • 최대 실패 모드는 하이퍼인디펜던스다. 프로토타입을 값싸게 대량 생산하면서 개인 단위 산발화(sprawl)가 커진다. 독립성은 주되 하나의 방향으로 조율한다.
  • 진짜 걸림돌은 보안·컴플라이언스와 eval이다. 20년 전 보안 가정 위에서 도는 조직은 도입에서 막힌다.
  • 엔지니어링 팀을 재정의한다. 티켓 처리형에서 “전원이 엔드투엔드 설계 의견을 갖고 자기 에이전트 무리를 오케스트레이션하는” 구조로 이동한다.

방향성(참고할 미래 그림)

  • 아웃컴 + 예산만 지정하면 되는 방향 — “이런 결과를 원해, 예산은 이만큼, 가서 해와”.
  • 보이지 않는 공통 기판(substrate) — 도구를 골라 쓰는 대신 선호를 학습한 에이전트가 선제적으로 일하는 OS 같은 세계.

고찰할 내용

  • 하네스를 얇게 vs. 통제 가능성. “제약을 걷어내면 모델이 알아서 한다”는 전제는 모델이 충분히 좋을 때만 성립한다. 우리 도메인의 비결정성이 아직 크다면, 어디까지 얇게 하고 어디는 굳이 가둬둘 것인가? 얇은 하네스의 실패를 무엇으로 조기에 감지할 것인가?
  • 개인 → 팀 → 회사 ROI의 함정. 개인 속도는 측정이 쉬워 과대평가되기 쉽다. 개인 단위 성과가 팀·회사로 정말 합산되는지(아니면 하이퍼인디펜던스로 흩어지는지)를 어떻게 구분해 측정할 것인가?
  • 하이퍼인디펜던스는 조직 설계 문제다. “프로토타입 10개 찍고 이긴 걸 고른다”가 값싸질수록, 조율·표준·선택의 비용은 오히려 오른다. 독립성을 주면서도 한 방향으로 모으는 거버넌스는 도구가 아니라 무엇으로 만드는가?
  • 에이전트 정체성 = 서비스 계정의 리스크. 에이전트가 스스로 권한을 요청·축적하면 감사는 가능해지지만 권한 크리프(creep)도 쉬워진다. “감사 가능”이 곧 “안전”은 아니다 — 누가, 언제, 무엇을 회수하는가?
  • 아웃컴 + 예산의 전제. “좋은 결과”의 루브릭을 명확히 쓸 수 있는 일에만 적용 가능하다. 루브릭화가 어려운 판단 업무는 이 모델 밖에 남는다 — 그 경계를 어디에 그을 것인가?
  • 선제적 에이전트와 신뢰. “고쳐서 PR 올려놨어요”가 편의가 되려면 사람의 검토 대역폭이 병목이 된다. 선제성이 늘수록 검토는 형식화되기 쉽다 — 자동화가 만드는 새로운 병목을 어떻게 관리할 것인가?

관련 노트

백링크