웹 4가 아닙니다. 우리는 이미 훨씬 더 앞서 있습니다

AI 요약

글쓴이는 최근 GitHub에서 한동안 활동이 뜸했던 계정이 완성도 높은 저장소와 CI, 테스트, 컨테이너 설정, 문서를 짧은 기간에 쏟아내는 모습을 봤다고 말합니다. 이를 모두가 갑자기 프로그래머가 된 현상으로 보지는 않습니다. 코딩 에이전트가 코드베이스를 읽고 여러 파일을 수정하며, 명령을 실행하고 오류를 고쳐 테스트와 배포까지 맡으면서 아이디어를 운영 가능한 소프트웨어로 만드는 문턱이 낮아진 결과라고 봅니다.

결과물과 이해의 분리

과거에는 복잡한 시스템을 만들었다면 그 과정에서 상당한 기술 지식을 익혔으리라 추정하기 쉬웠습니다. 이제는 저장소 구조가 그럴듯하고 테스트와 CI가 통과해도, 제작자가 시스템의 내부 동작을 충분히 이해한다고 단정하기 어렵습니다. 모델이 작업을 깔끔한 설명으로 정리해도 실제로는 잘못된 가설을 세우고 도구의 신호에 따라 여러 차례 수정했을 수 있습니다. 결과가 맞더라도 사용자의 이해 수준까지 같은 것은 아닙니다.

글쓴이가 특히 우려하는 점은 환각보다 세부 맥락의 손실입니다. 앞서 내린 결정이나 이미 틀린 전제, 사소해 보이는 의미 차이, 구성 요소 사이의 의존성이 빠지면 시스템 전체의 의미가 달라질 수 있습니다. 그래서 사람은 결정의 이유를 기억하고, 테스트가 실제로 무엇을 입증하는지 확인하며, 프로젝트가 처음 의도에서 벗어나는지 살피는 연속성의 역할을 맡습니다. 단순히 컨텍스트 창을 늘리는 대신, 시스템이 수개월이나 수년 동안 상태와 인과관계, 결정 이력, 폐기된 정보, 가정과 모순을 보존하는 단계가 오면 에이전트는 작업을 수행하는 도구를 넘어 작업의 방향을 유지하는 시스템이 된다고 전망합니다.

사람이 아니라 기계도 행위자가 되는 웹

에이전트가 발전하면 프로그래밍이 희소한 자원에서 벗어날 수 있습니다. 글쓴이는 모두가 프로그래머가 된다는 뜻이 아니라, 더 많은 사람이 소프트웨어 생산을 일으킬 수 있다는 뜻이라고 구분합니다. 개인은 특정 문제만 해결할 도구를 만들고, 기업은 내부용 앱을 직접 만들며, 연구자는 실험 하나에 쓰고 버릴 프로그램을 만들 수 있습니다. 소프트웨어는 오랫동안 유지되는 제품뿐 아니라 필요에 따라 생겼다가 사라지는 임시 도구가 될 수 있습니다.

변화는 코딩에 그치지 않습니다. 한 사람의 요청 뒤에서 에이전트 여러 개가 검색하고 API를 호출하며 임시 프로그램을 만들고 테스트와 배포를 수행할 수 있습니다. 겉으로는 프롬프트 하나지만 그 아래에는 수십 번의 검색과 API 호출, 다수의 테스트와 에이전트가 움직일 수 있습니다. 따라서 네트워크의 활동량은 사람 수보다 훨씬 빠르게 늘어날 수 있습니다. 글쓴이가 ‘Web 50’이라고 부르는 것은 새로운 웹 세대의 공식 번호가 아니라 변화 속도와 규모를 비유한 표현입니다. 에이전트가 디지털 산출물을 만들고 다른 에이전트가 이를 소비해 새 산출물을 만드는 순환이 생기면, 사람만이 아니라 기계도 기계를 위한 인터넷을 확장합니다. 에이전트용 API, 기계 간 신원과 결제, 모델이 읽기 좋은 문서처럼 사람이 직접 방문하지 않는 서비스도 늘어날 수 있다고 봅니다.

자율성을 실행 경로 안에서 통제하기

이런 환경에서는 에이전트의 능력을 높이는 문제뿐 아니라 성공한 에이전트를 어떻게 통제할지 살펴야 합니다. 에이전트가 짧은 시간 안에 판단과 API 호출, 코드 수정, 배포, 다른 에이전트 호출을 잇는다면 사후 로그 점검만으로는 늦을 수 있습니다. 계정과 권한을 확인하는 기존 보안 체계만으로도 충분하지 않습니다. 에이전트가 올바른 권한을 갖고 있어도 오래되거나 불완전한 세계 모델을 바탕으로 잘못된 판단을 내릴 수 있기 때문입니다.

글쓴이는 에이전트와 실제 실행 사이에 통제 계층(Control Plane)을 두는 구상을 제안합니다. 이 계층은 에이전트의 권한과 정보 출처, 맥락의 유효성, 전제, 지켜야 할 불변 조건, 행동의 되돌릴 수 있는 정도와 오류의 영향 범위를 확인합니다. 실행 전에는 독립 검증기가 모순을 찾고 맥락이 낡았는지 확인하며, 제안된 판단을 반증하려고 시도합니다. 실행 뒤에는 실제 결과가 예상한 사후 조건(Post-condition)과 일치하는지 검증합니다. 목적은 에이전트의 행동을 모두 막는 데 있지 않고, 자율적인 행동을 검증 가능한 절차로 만드는 데 있습니다.

따라서 기록해야 할 내용도 ‘어떤 에이전트가 API를 호출했나’에 그치지 않습니다. 어떤 정보와 근거가 호출을 옳다고 판단하게 했는지, 정보가 얼마나 최신이고 신뢰할 만했는지, 어떤 가정과 반대 증거가 있었는지까지 연결해야 합니다. 글쓴이는 이를 정책 문서 차원의 AI 거버넌스가 아니라 실행 시점의 자율성 거버넌스(Runtime Governance)로 설명합니다.

모델이 좋아질수록 커지는 기반 시설

글쓴이는 대형 연구소와 모델 성능 경쟁을 벌이는 대신, 모델이 좋아질수록 더 필요해지는 기반 시설을 만들자는 전략을 제시합니다. 메모리나 브라우저 자동화 같은 현재의 약점을 해결하는 제품은 해당 기능이 모델이나 하네스에 통합되면 대체될 위험이 있습니다. 반면 에이전트가 더 자율적으로 오래 일하고 더 많은 권한을 얻으며 서로 협력할수록 통제와 검증의 필요는 커집니다. 글의 마지막 질문은 시스템이 얼마나 똑똑한지가 아니라, 그 시스템이 무엇을 해도 되는지 누가 관리하느냐입니다.

dev.to 반응

• @rishita_sharma_b0aa1ff81a — 결과물을 만드는 능력과 이해하는 능력의 차이는 AI 보조 시스템을 출시하는 팀에 특히 중요하게 느껴집니다. 저는 출처와 가정, 사후 조건을 담은 간단한 결정 기록이 프롬프트를 한 겹 더 다듬는 것보다 유지보수에 더 도움이 된다고 느꼈습니다. 검토자는 구체적인 기록을 두고 이의를 제기할 수 있고, 에이전트에는 범위가 정해진 맥락을 제공할 수 있습니다. 통제 계층이라는 구상은 거버넌스를 정책 문서로만 다루지 않고 일상적인 엔지니어링과 연결하는 유용한 방식입니다.
  • @danielecangi — 맞습니다. 최종 결과물만이 아니라 결정 자체를 살펴볼 수 있는 산출물로 만드는 일입니다. 출처와 가정, 사후 조건은 긴 대화 기록보다 사람과 에이전트 모두에게 훨씬 안정적인 기준을 줍니다. 그런데 이 방식이 가벼운 엔지니어링 관행을 넘어, 행동이 실행되기 전에 이의를 제기하거나 차단할 수 있는 실제 실행 절차가 되면 어떨까요? 바로 그 지점에서 거버넌스는 정책이 아니라 기반 시설에 가까워집니다.
• @mikachu — 첫 문단은 안타깝게도 제 이야기네요. 제 GitHub 계정은 10년이 넘었지만, 기술 분야로 돌아온 시기가 AI로 만든 프로젝트가 늘고 코드를 내놓기 쉬워진 때와 겹쳤습니다. 제 프로필도 글에서 묘사한 모습처럼 보일 겁니다. 수년간 조용하다가 갑자기 완성된 저장소가 잔뜩 생겼으니까요. ‘결과물과 이해’에 관한 대목을 읽고 프로필만으로는 둘을 구별할 수 없다는 점을 깨달았습니다. 깔끔한 저장소가 한꺼번에 늘어나도 제작자가 모든 결정을 설명할 수 있는지 드러나지 않습니다. 제가 출시한 내용을 방어할 수 있는지, 왜 그런 구조로 만들었는지, 무엇을 바꾸고 싶은지, 아직 무엇을 신뢰하지 않는지 설명하는 게 실질적인 확인 방법입니다. 늘 좋은 글 감사합니다. <3
  • @danielecangi — 하하, 제가 말한 상황을 보여주는 완벽한 예네요. 밖에서 보면 저장소를 실제로 어떻게 만들었는지 더는 확실히 알기 어렵습니다. 완성도 높은 저장소가 갑자기 늘어난 모습은 더 많은 경험과 좋은 도구를 갖고 기술 분야에 복귀한 사람일 수도 있고, 에이전트의 도움을 받으며 배우는 사람일 수도 있고, 자신이 거의 이해하지 못하는 결과물을 내놓는 사람일 수도 있습니다. ‘내가 출시한 것을 방어할 수 있는가?’라는 기준이 정말 좋습니다. 솔직히 에이전트가 워낙 빠르게 작업하기 때문에 모든 것을 이해했다고 주장하는 것조차 무리일 수 있습니다. 칭찬도 감사합니다.

원문: dev.to / 번역·요약: Trawling