Boris Tane 저는 회사를 능동적인 에이전트에 걸었습니다
Explore with AI
에이전트는 요청하는 거의 모든 것을 할 수 있고, 바로 그것이 문제입니다. 여전히 요청해야 합니다.
사람들이 에이전트를 “디지털 동료”라고 부르는 것을 계속 듣습니다. 그 표현은 틀렸습니다. 완벽하게 범위가 정해진 작업을 건네주기 전까지 조용히 앉아 있다가, 그것을 끝내고, 다시 기다리는 동료는 동료가 아닙니다. 여러분이 써 본 모든 에이전트가 정확히 이렇게 동작합니다. 모델은 더 똑똑해졌고, 하네스는 더 좋아졌고, 실행은 더 길어졌지만, 인터페이스는 한 번도 바뀌지 않았습니다. 일은 여러분이 가져오고, 에이전트는 노동을 제공합니다.
그리고 대부분은 이를 눈치채지 못했습니다. 프롬프트 상자가 우리 머릿속에서 조용히 AI 그 자체가 되어 버렸기 때문입니다.
모든 인터페이스는 여전히 프롬프트 상자입니다
입력 상자는 이 시대 전체가 시작된 방식입니다. ChatGPT가 모델 위에 하나를 올려 역사상 가장 빠르게 성장한 제품이 되었고, 우리 모두 그것을 따라 했습니다. 그 이후의 모든 AI 제품은 같은 상호작용의 변형입니다. 사람이 입력하고, 기계가 응답하고, 기계가 기다립니다.
Claude Code가 다음 진화였습니다. 에이전트가 터미널로 들어와 파일, 셸, git 이력을 집어 들고, 일에 대해 말하는 대신 실제 일을 시작했습니다. 에이전트가 할 수 있는 일은 바뀌었지만, 시작하는 방식은 바뀌지 않았습니다. 여러분이 입력하고, 에이전트가 일하고, 멈추고, 여러분이 다시 입력하기를 기다립니다.
그다음 에이전트는 클라우드로 옮겨 갔습니다. Codex, Devin, 웹의 Claude Code. 몇 분이 아니라 몇 시간을 돌고, 서브 에이전트를 띄워 일을 병렬화하고, 노트북을 닫아도 죽지 않습니다. 점심 전에 작업을 하나 건네면 풀 리퀘스트를 들고 돌아옵니다.
![graph TD
A[You write the task] --> B[Cloud agent]
B --> C[Sub-agent]
B --> D[Sub-agent]
B --> E[Sub-agent]
C --> F[Pull request]
D --> F
E --> F
style F fill:#d1fae5,stroke:#6ee7b7,color:#065f46](/diagrams/1a98d6cb.svg)
프롬프트는 키보드로만 하는 것도 아니게 되었습니다. 백그라운드 에이전트는 경보나 웹훅으로 시작될 수 있고, 대부분의 에이전트 플랫폼이 이제 자동화를 제공합니다. 이 이벤트가 발생하거나 이 크론이 울리면, 이 지침으로 에이전트를 실행하라.
- When
- a Sentry alert fires
- Do
- investigate, open an incident if it's real
- Then
- post the findings to #incidents
하지만 자동화란 무엇일까요? 여러분이 미리 써 둔 프롬프트입니다. 실패 모드를 예측하고, 이벤트를 고르고, 무엇을 할지 적어 두었습니다. 트리거가 에이전트를 실행하지만, 그 안의 판단은 설정 시점에 얼어붙은 여러분의 것입니다. 자동화는 정확히 여러분이 예상한 것만 잡고, 그 외에는 아무것도 잡지 못합니다.
스케줄러는 여러분입니다
도구를 걷어 내면 분업은 3년 동안 움직이지 않았습니다. 에이전트가 일을 합니다. 일이 무엇인지 정하는 것은 여전히 여러분의 몫입니다.
여러분이 대시보드를 읽고, 사용자의 말을 듣고, 무엇이 중요한지 알아내고, 배운 모든 것을 프롬프트로 압축합니다. 키보드 앞에서 실시간으로든, 트리거에 미리든. 에이전트는 훌륭하게 실행하지만, 시스템의 모든 판단은 여러분에게서 비롯됩니다.
![graph TD
A[Dashboards] --> D[You]
B[Alerts] --> D
C[User complaints] --> D
D --> E[The prompt you type today]
D --> F[The automation you configured last month]
E --> G[Agent]
F --> G
style D fill:#fee2e2,stroke:#fca5a5,color:#991b1b](/diagrams/b6e95276.svg)
다음 진화: 일을 찾아내는 에이전트
저는 다음 진화가 해야 할 일을 스스로 찾아내는 에이전트라고 봅니다. 프롬프트도, 설정할 트리거도, 미리 써 둔 지침도 없습니다. 스택을 연결하면 에이전트가 스스로 일을 찾습니다. 여러분이 보는 것과 같은 신호를 지켜보고, 이상한 점을 알아채고, 중요한지 판단하고, 자율적으로 작업을 시작합니다.
말하기는 쉽고 만들기는 지독하게 어렵습니다. 능동성은 세 가지 문제가 겹겹이 쌓인 것이고, 그중 하나라도 건너뛰면 입력 상자 뒤의 에이전트보다 나쁜 것이 나오기 때문입니다.
컨텍스트. 당연히 에이전트에게는 프롬프트 시점에 컨텍스트 윈도우에 붙여 넣은 스냅숏이 아니라, 자신이 동작하는 세계의 살아 있는 모델이 필요합니다. 컨텍스트가 나쁜 반응형 에이전트는 나쁜 답을 줍니다. 컨텍스트가 나쁜 능동적 에이전트는 스테이징이라고 생각해서 프로덕션 데이터베이스를 삭제합니다.
판단. 이것이 저를 가장 애먹인 부분입니다. 어느 순간에나 프로덕션 시스템에서는 수천 가지가 조금씩 어긋나 있습니다. 그 전부를 표시하는 에이전트는 노이즈 기계이고, 노이즈 기계는 무음 처리되고, 무음 처리된 에이전트는 죽은 에이전트입니다. 능동성의 가치 전체는 “무언가 바뀌었다”와 “무언가 중요하다” 사이의 간격에 있습니다.
[
{
"signal": "memory up 3% on checkout-edge",
"verdict": "no anomaly",
"reasoning": "within the seasonal range for this hour on this worker"
},
{
"signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
"verdict": "incident",
"reasoning": "error class never seen on this worker, tightly correlated with a deploy"
}
]행동. 행동 없이 알아채기만 하는 것은 조금 더 똑똑한 경보일 뿐이고, 경보는 제가 없애려는 바로 그것입니다. 에이전트는 자율성을 안전하게 하는 경계 안에서 일을 끝내야 합니다. 되돌릴 수 있는 행동, 모든 것에 대한 증거, 그리고 되돌릴 수 없는 일이 일어나기 전의 단단한 게이트.
이 셋 중 어느 것도 에이전트가 좋은 상태가 무엇인지 정하는 일을 포함하지 않습니다. 에이전트는 무엇이 어긋났는지, 그것이 중요한지, 무엇을 할지 정하며, 그것이 목록의 전부입니다. 프로덕션에서는 누구도 좋은 상태를 정의할 필요가 없기 때문입니다. 에러는 0, 지연 시간은 기준선, 큐는 비어 있고, 인증서는 유효한 상태. 바람직한 상태는 영역에 딸려 옵니다.
즉 진짜 변화는 “여러분이 프롬프트한다”에서 “에이전트가 스스로 프롬프트한다”로의 이동이 아닙니다. 명령형 운영에서 선언형 운영으로의 이동입니다. 자동화는 명령형입니다. 실패 모드를 미리 열거하고 각각에 대한 대응을 스크립트로 짭니다. 능동적 에이전트는 조정 루프입니다. 지금 있는 시스템을 있어야 할 시스템에 비추어 보고, 그 간격을 메우려 일합니다. Kubernetes는 10년 전에 인프라에 대해 이것을 했습니다. 레플리카 셋을 적어 두면 컨트롤러가 레플리카 셋을 살려 두기 위해 무엇이든 합니다. 소프트웨어 운영 자체에 대해서는 아무도 하지 않았습니다. 그리고 여기서는 쓸 YAML도 없습니다. 바람직한 상태는 이미 알려져 있으니까요. 바로 동작합니다.
저는 운영에서 시작했습니다
능동적 에이전트에게 제품 로드맵을 고르라고 하면 의견만 많은 인턴을 얻게 됩니다. 제품 방향은 취향의 문제이기 때문입니다. 프로덕션은 그렇지 않습니다. 세 가지 문제가 모두 오늘 풀 수 있는 유일한 영역입니다.
일이 스스로를 알립니다. 에러율이 오르고, 배포가 잘못되고, 인증서가 만료되고, 큐가 쌓입니다. 일은 이미 텔레메트리 안에 앉아 누군가 알아채기를 기다리고 있습니다. 그리고 취향이 이끄는 영역과 달리 정답이 존재합니다. 에러율은 급증했거나 하지 않았고, 롤백은 기준선을 복원했거나 하지 않았으므로, 에이전트의 판단은 시스템 자체에 의해 지속적으로, 느낌이 끼어들 틈 없이 채점됩니다.
무엇보다 우리는 이미 이 일을 사람으로 채우고 있습니다. 우리는 그것을 온콜이라고 부릅니다. 한 기계가 다른 기계가 불행하다고 말하기를 기다리며 전화기 옆에서 자는 사람. 저는 관측성 분야에서 여러 해를 보냈고, 관측성 회사를 창업해 Cloudflare에 인수되었고, 답이 쿼리 하나 거리에 있도록 텔레메트리를 구조화하는 것에 대한 선언문을 통째로 썼습니다. 그 논지가 이 회사가 존재하는 이유입니다. 2026년에는 아무도 온콜을 서지 않아야 합니다.
지난 10년의 관측성에 대한 불편한 진실은, 우리가 새벽 3시에 사람이 시스템을 심문하기 쉽게 만들어 놓고는, 여전히 사람이 깨어나는 동안 승리를 선언했다는 것입니다. 대시보드는 더 예뻐졌고 호출기는 침대 옆에 그대로 남았습니다. 행동 없는 관측성은 비싼 저장소일 뿐입니다.
어떤 모습인가
이것이 Polylane이 하는 일입니다. 구체적인 어느 화요일입니다.
![graph TD
A["02:14 — checkout p99 jumps from 180ms to 2.1s"] --> B["02:15 — agent flags it: new error pattern, right after the 01:52 deploy"]
B --> C["02:16 — incident opens, 3 hypotheses investigated in parallel"]
C --> D["02:31 — verdict: connection pool exhausted by a new N+1 query"]
D --> R["02:33 — the 01:52 deploy is rolled back, p99 back to 180ms. The incident is over."]
R --> E["02:38 — PR opened with the fix and the evidence attached"]
E --> F["08:30 — you wake up, read the investigation, merge"]
style A fill:#fee2e2,stroke:#fca5a5,color:#991b1b
style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style E fill:#d1fae5,stroke:#6ee7b7,color:#065f46](/diagrams/ff5bb4b7.svg)
누구도 이 실패 모드에 대한 검사를 설정하지 않았습니다. 쓸 규칙도, 조정할 임계값도 없습니다. 에이전트가 연결된 모든 리소스를 지속적인 주기로 평가하고, 기존 대시보드와 저장된 쿼리가 그들의 체크리스트가 됩니다. 판단은 제가 가장 엄격한 부분입니다. 기본 판정은 이상 없음입니다. 노이즈 때문에 누군가를 깨우는 것보다 경계선의 이슈를 놓치는 쪽이 훨씬 낫기 때문입니다. “배포가 버그를 들여올 수 있다”는 모든 배포에 대해 참이며, 누군가를 호출할 근거가 될 수 없습니다.
무언가 진짜일 때, 조사는 경쟁하는 여러 가설을 병렬로 실행하며, 각 에이전트의 일은 자기 가설을 확인하는 것이 아니라 반증하는 것입니다. 그래서 상관관계가 원인으로 가장할 수 없습니다. 확인된 근본 원인이 코드 변경이면, 수정은 조사가 첨부된 풀 리퀘스트로 도착합니다.
coreplane/checkout-edge Opened by Polylane · gated on review and CI
능동적이라는 것은 감독 없음이 아닙니다
자율성은 알아채기, 트리아지, 새벽 3시의 고고학, 그리고 완화에 있습니다. 알려진 정상 상태를 복원하는 일이라면 에이전트가 스스로 합니다. 잘못된 배포를 롤백하고, 플래그를 다시 끕니다. 그 행동들은 구조적으로 되돌릴 수 있고, 실제로 호출기를 잠재우는 것들입니다. 게이트 뒤에 남는 것은 새로운 상태를 만드는 모든 것입니다. 코드 변경은 여러분의 리뷰와 CI를 통해 출시되며, 절대 우회하지 않습니다.
경계는 사람 대 에이전트가 아닙니다. 되돌릴 수 있는가, 없는가입니다. 그리고 그것이 여러분이 몰래 여전히 온콜인 것이 아닌 이유입니다. 롤백이 02:33에 인시던트를 끝냈고, 그것은 여러분이 풀 리퀘스트를 병합하기 여섯 시간 전입니다. PR은 출혈을 멈춘 것이 아니었습니다. PR은 같은 일이 다시 일어나지 않게 하는 것이고, 그것은 커피 마실 때까지 기다릴 수 있습니다.
그리고 게이트는 여러분이 위임할 수 있습니다. 코드 리뷰 에이전트는 이미 리포지토리의 모든 풀 리퀘스트를 읽습니다. 여기서 멀지 않은 세상에서는 리뷰 에이전트가 02:41에 수정을 읽고, 조사에 비추어 확인하고, 승인하고, 여러분이 깨기 전에 CI가 프로덕션에 배포합니다. 승인 버튼을 누가 쥐는지 외에는 루프의 아무것도 바뀌지 않습니다. 이것이 끝나는 곳입니다. 스스로 고치는 소프트웨어, 여러분은 병합을 클릭하는 대신 정책을 씁니다.
![graph TD
A[Signals] --> B[Detection]
B --> C[Investigation]
C --> R[Rollback, on its own]
C --> D[Pull request]
D --> E[You or your agent review, it merges]
R --> F[Memory]
E --> F
F --> B
style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style D fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style F fill:#dbeafe,stroke:#93c5fd,color:#1e40af](/diagrams/b1056731.svg)
그 루프에서 빠진 것을 보세요.
프롬프트 상자는 이런 시스템을 신뢰하는 법을 배우는 훌륭한 방법이었고, 프로덕션을 운영하는 데는 끔찍한 방법입니다. 에이전트는 모든 서비스의 모든 배포, 모든 로그 라인, 모든 메트릭을 동시에 보았습니다. 그것을 프롬프트 뒤에 두는 것은, 팀에서 가장 많이 아는 구성원이 말을 걸 때만 말하게 하는 것입니다.
2026년에는 아무도 온콜을 서지 않아야 합니다.