책임 없는 코드 — 에이전트가 다시 묻는 질문

지금으로부터 약 3,800년 전, 바빌론의 왕 함무라비는 검은 돌기둥에 법을 새겼다. 그 가운데 한 조항은 건축가를 향한다. 건축가가 집을 지었는데 견고하게 짓지 못하여 집이 무너지고 그 집의 주인이 죽으면, 그 건축가를 사형에 처한다는 것이다. 집주인의 아들이 죽으면 건축가의 아들을 죽이라는 조항도 뒤를 잇는다. 잔혹하게 들리지만 그 안에는 단순하고 강력한 원칙이 들어 있다. 무언가를 만든 자는 그 결과에 책임을 진다는 원칙이다.
이 원칙은 인류 문명의 거의 모든 시대를 관통했다. 다리를 놓은 기술자, 배를 만든 장인, 건물을 세운 시공사는 자신이 만든 것이 무너질 때 이름을 내놓아야 했다. 소프트웨어의 시대에 들어와서도 마찬가지였다. 코드의 끝에는 언제나 그것을 작성한 사람의 이름과 커밋 기록이 남았고, 장애가 발생하면 누가 어디서 무엇을 잘못했는지 추적할 수 있었다. 책임의 사슬은 길어지고 복잡해졌을지언정 끊긴 적은 없었다.
그런데 지금, 그 4천 년의 원칙에 처음으로 균열이 생기고 있다. 인공지능이 코드를 쓰기 시작하면서다. 새로운 종류의 건축가가 등장했는데, 이 건축가는 어떤 서명도 남기지 않는다. 그리고 그 건축가를 부린 사람의 입에서 전에 없던 문장이 흘러나온다. 내가 쓴 것이 아니다, AI가 생성한 것이다, 그러니 오류가 나도 내 책임이 아니다. 함무라비가 돌에 새긴 원칙이 조용히 흔들리는 소리다.
오픈소스 에이전트의 폭발적 확산은 이 균열을 가장 선명하게 보여주는 현장이다. 베타라는 말로도 가릴 수 없는 오류투성이 코드가 매일같이 세상에 풀려나오고, 그것을 배포한 누구도 끝까지 책임지지 않는다. 코드를 만든 자가 사라진 시대에, 우리는 무엇으로 신뢰를 다시 세울 것인가?
만든 자가 사라진 코드
오류가 난 코드 앞에서 책임의 화살은 갈 곳을 잃는다. 코드를 생성한 인공지능의 잘못인가, 아니면 생성하라고 지시한 사람의 잘못인가? 인공지능에게는 처벌할 인격도, 배상할 자산도, 부끄러워할 양심도 없다. 그렇다고 지시한 사람을 탓하기도 애매하다. 그는 단지 자연어로 요구사항을 말했을 뿐, 한 줄 한 줄을 직접 타이핑하지 않았기 때문이다. 책임은 인공지능과 인간 사이의 빈틈으로 미끄러져 사라진다. 이것이 에이전트 시대가 만들어낸 도덕적 공백이다.
이 공백은 단순한 철학적 사변이 아니다. 그것은 실제 제품의 안정성과 직결된다. 누구도 끝까지 책임지지 않는 코드는 끝까지 다듬어지지 않는다. 무너지면 다시 생성하면 그만이라는 태도 앞에서, 견고함이라는 덕목은 설 자리를 잃는다. 4천 년 전 바빌론의 건축가가 자기 목숨을 걸고 기초를 다졌던 이유는, 무너졌을 때 도망칠 곳이 없었기 때문이다. 도망칠 곳이 무한히 열려 있는 곳에서 견고함을 기대하는 것은 무리다.
흥미로운 점은, 이 책임의 공백이 인공지능 코딩을 둘러싼 막연한 두려움과는 결이 다르다는 사실이다. 사람들은 흔히 인공지능이 인간이 이해할 수 없는 기괴한 코드를 써내고, 그 안에 알 수 없는 논리가 숨어 있어 사고가 난다고 상상한다. 현실은 그렇게 극적이지 않다. 인공지능이 생성한 코드의 상당수는 그 자체로는 충분히 작동한다. 문제는 코드가 홀로 존재하지 않는다는 데 있다. 모든 코드는 기존의 환경 설정, 데이터 구조, 의존성, 그리고 오랜 시간 쌓여온 약속들 위에 놓인다.
오류는 새로 짠 코드의 한복판이 아니라 옛것과 새것이 만나는 이음매에서 자란다. 기존 시스템에는 누군가 오래전에 정해둔 설정값이 있고, 특정한 형식으로 저장된 데이터가 있으며, 암묵적으로 지켜져 온 전제들이 있다. 인공지능이 그 위에 새 기능을 올리거나 버전을 끌어올릴 때, 이전 데이터를 새 구조로 옮기는 마이그레이션이나 바뀐 조건에 대한 대응이 미흡하면 시스템은 거기서 무너진다. 코드 한 줄 한 줄은 멀쩡한데 전체가 작동하지 않는 상황이 벌어진다. 이것이 에이전트가 만든 결과물에서 가장 빈번하게 관찰되는 고장의 형태다.
이런 고장이 잘 잡히지 않는 데에는 구조적인 이유가 있다. 인공지능은 인간이 평생 작성할 분량의 코드를 하루에 쏟아낸다. 그 방대한 산출물을 사람이 한 줄씩 읽고, 의도를 검증하고, 모든 경우의 수를 테스트하는 것은 물리적으로 불가능하다. 과거의 개발이 적은 양의 코드를 깊이 들여다보는 일이었다면, 지금의 개발은 엄청난 양의 코드를 어떻게 신뢰할 것인가의 문제로 바뀌었다. 한 사람이 검증할 수 있는 코드의 양은 그대로인데, 생성되는 양만 수십 배로 늘었다. 검증되지 않은 코드의 거대한 더미가 매일 쌓여간다.
여기까지는 어느 정도 이해할 수 있는 영역이다. 새로운 생산 방식이 도입되면 검증 방식이 그 속도를 따라잡기까지 시차가 생기는 것은 자연스럽다. 문제는 이 시차를 방치할 때 벌어진다. 개인의 취미 프로젝트라면 무너져도 그만이지만, 수익을 내고 고객을 받는 상용 애플리케이션에서는 사정이 다르다. 검증되지 않은 코드가 결제 시스템을, 의료 기록을, 기업의 핵심 데이터를 다룬다면, 작은 이음매의 균열 하나가 감당하기 어려운 손해와 소송으로 번질 수 있다. 만든 자가 사라진 코드는, 결국 그 코드를 쓴 사용자에게 모든 위험을 떠넘긴다.
진짜 전선은 QA에 있다
인공지능 코딩의 시대에 가장 중요한 것은 무엇인가? 많은 이들이 더 똑똑한 모델, 더 빠른 생성 속도, 더 화려한 기능을 답으로 떠올린다. 그러나 본질은 다른 곳에 있다. 진짜 전선은 품질 보증, 곧 QA에 있다. 코드를 얼마나 잘 만드느냐가 아니라 만들어진 코드를 얼마나 잘 검증하느냐가 제품의 운명을 가른다.
이는 직관에 반하는 주장처럼 들린다. 생성이 자동화되었으니 사람은 검증에 더 집중하면 되지 않느냐고 반문할 수도 있다. 그러나 앞서 보았듯 인간의 검증 능력은 생성의 폭증을 따라가지 못한다. 사람의 눈으로 하는 검증을 늘리는 방식으로는 결코 균형을 맞출 수 없다. 생성이 자동화된 만큼 검증도 자동화되어야 한다. 인공지능이 코드를 쏟아내는 속도에 맞먹는 속도로 그 코드를 시험하고, 회귀를 잡아내고, 이음매의 결함을 찾아내는 자동화된 체계가 없다면, 생성의 가속은 곧 고장의 가속이 된다.
그러므로 앞으로 제품의 성패는 QA를 얼마나 자동화하느냐에 달려 있다. 코드를 생성하는 능력은 이미 보편화되어 누구나 가질 수 있는 것이 되었다. 차별화의 지점은 그다음 단계로 옮겨갔다. 생성된 코드가 기존 시스템과 충돌하지 않는지, 버전을 올렸을 때 데이터가 안전하게 이전되는지, 바뀐 조건에서도 예전 기능이 그대로 작동하는지를 사람의 개입 없이 끊임없이 확인하는 능력, 그것이 새로운 경쟁력이다. 코드를 만드는 인공지능 위에, 그 코드를 의심하고 검증하는 또 다른 자동화 계층을 얹을 수 있는가가 관건이다.
이 지점에서 한 가지 구체적인 해법이 떠오른다. 자동 피드백 시스템이라 이름 붙여 설계하고 운영해온 구조가 그 한 형태다. 사용자가 앱을 쓰다가 마주친 오류나 불편을 그 자리에서 남기면, 그 피드백이 자동으로 이슈로 등록된다. 여기까지는 새로울 것이 없다. 달라지는 것은 그다음이다. AI 코딩 에이전트가 주기적으로 이슈를 확인해 원인을 분석하고, 코드를 고치고, 테스트를 돌린 뒤, 수정안을 담은 변경 요청을 스스로 만들어낸다. 사람은 그 결과를 검토하고 승인하기만 하면 된다. 피드백 한 줄이 코드 수정과 배포로 이어지기까지, 사람의 손이 거의 닿지 않는다.
중요한 것은 이 구조가 생성만 자동화한 것이 아니라 검증과 수정까지 한 바퀴로 닫았다는 점이다. 코드를 한 방향으로 쏟아내기만 하는 도구와 달리, 사용자의 실제 행동이 곧 가장 정직한 시험이 되어 이음매에서 자라는 고장을 끊임없이 드러내고, 그 신호가 다시 코드를 고치는 입력으로 되돌아온다. 검증이 제품 바깥의 사후 점검이 아니라 제품의 작동 그 자체에 녹아드는 것이다. 그리고 부수적으로 하나가 더 회복된다. 어떤 피드백이 어떤 수정으로 이어졌는지가 빠짐없이 기록으로 남기 때문에, 만든 자가 사라지며 끊겼던 책임의 사슬이 비로소 다시 이어진다. 안정성을 향한 길은 결국 이런 방향으로 수렴할 수밖에 없다.
안정성을 가볍게 보아서는 안 되는 이유는 사용자의 마음이 냉정하기 때문이다. 아무리 혁신적이고 매력적인 서비스라 해도 자주 멈추고 데이터를 잃고 예측할 수 없게 작동한다면, 사용자는 미련 없이 떠난다. 기술의 역사는 더 뛰어난 기술이 아니라 더 믿을 만한 기술이 시장을 차지해온 역사이기도 하다. 화려한 시연으로 박수를 받은 제품이 일상의 신뢰를 얻지 못해 사라진 사례는 셀 수 없이 많다. 혁신은 사용자를 끌어들이지만, 안정성은 사용자를 머무르게 한다.
그래서 인공지능 코딩의 도입에서 정작 승부가 갈리는 곳은 모델의 성능이 아니라 그 모델이 만든 결과물을 신뢰할 수 있게 만드는 공정이다. 똑똑한 생성기를 가진 자가 아니라, 그 생성기의 산출물을 끝까지 책임지고 다듬을 체계를 가진 자가 시장을 가져간다. 함무라비의 건축가가 견고함으로 생존을 보장받았듯, 에이전트 시대의 제품은 검증된 안정성으로 사용자의 신뢰를 보장받는다. 이것은 선택의 문제가 아니라 생존의 조건이다.
오픈클로의 균열이 보여준 것
추상적인 논의를 구체적인 사건이 단숨에 명료하게 만들 때가 있다. 2026년 봄, 오픈소스 에이전트 진영에서 벌어진 일련의 사건이 그러했다. 그 중심에는 오픈클로라는 이름의 도구가 있었다.
오픈클로는 오스트리아 출신 개발자 페터 슈타인베르거가 만든 오픈소스 에이전트다. 그는 과거 애플과 드롭박스, SAP 같은 기업이 채택한 PDF 프레임워크 PSPDFKit을 만든 베테랑 개발자였다. 오픈클로는 처음 클로드봇이라는 이름으로 2025년 11월에 등장했다가 상표 문제로 이름을 바꾸었고, 사용자의 컴퓨터에서 직접 돌아가며 메신저 앱과 인공지능 모델을 연결하는 로컬 우선 구조로 폭발적인 인기를 얻었다. 깃허브에서 역사상 가장 빠르게 별을 모은 오픈소스 프로젝트 가운데 하나로 떠오르며, 단숨에 가장 주목받는 개인용 에이전트가 되었다.
그러나 인기의 이면에는 취약함이 도사리고 있었다. 빠르게 성장하는 만큼 보안과 안정성의 토대는 충분히 다져지지 않았다. 2026년 1월 말에는 악의적인 링크 하나만으로 사용자의 인증 토큰을 탈취하고 기기를 원격으로 장악할 수 있는 심각한 결함이 공개되었고, 패치가 나온 뒤에도 2만여 대에 이르는 오픈클로 인스턴스가 보호 장치 없이 인터넷에 노출되어 있다는 조사 결과가 나왔다. 강력한 권한을 가진 에이전트가 충분한 책임 구조 없이 풀려났을 때 어떤 위험이 따르는지를 보여주는 사례였다.
이어진 사건은 이 도구의 토대가 얼마나 한 사람에게 기대고 있었는지를 드러냈다. 창시자 슈타인베르거는 2026년 2월 경쟁사인 오픈에이아이에 합류했다. 그리고 4월 4일, 앤트로픽은 자사의 클로드 구독 요금제가 오픈클로를 비롯한 서드파티 도구의 사용을 더 이상 포함하지 않는다고 공지했다. 구독으로 쓰던 사용자들은 사용량에 따라 비용을 따로 내는 종량제 방식으로 옮겨가야 했다. 며칠 뒤인 4월 10일에는 슈타인베르거 본인의 앤트로픽 계정이 의심스러운 활동을 이유로 일시 정지되었다가 몇 시간 만에 복구되는 소동까지 벌어졌다. 한 회사의 정책 변경 하나로 인기 도구의 사용 환경이 흔들리고, 창시자가 떠난 자리에 미래에 대한 불확실성이 내려앉았다. 세 사건은 따로 떨어진 우연이 아니다. 도구의 생사가 창시자 한 사람과 모델 공급사 한 곳의 처분에 매여 있었다는 단일한 사실이, 세 가지 얼굴로 드러난 것일 뿐이다.
여기서 주목해야 할 것은 사건의 시시비비가 아니라 구조의 취약함이다. 오픈클로의 운명은 한 명의 창시자와 한 회사의 정책에 지나치게 의존하고 있었다. 창시자가 다른 진영으로 떠나고, 모델을 제공하던 회사가 문을 좁히자, 그 위에 쌓아 올린 모든 것이 동시에 흔들렸다. 누구도 끝까지 책임지지 않는 구조의 약점이, 빠른 성장의 이면에 정확히 그 모습대로 드러난 것이다.
이 빈자리를 두고 헤르메스라는 이름의 에이전트가 대안으로 거론되기 시작했다. 헤르메스는 누스 리서치라는 연구 조직이 개발하고 유지하는 오픈소스 에이전트다. 사용해본 입장에서 보면 오픈클로와 헤르메스가 추구하는 방향에 약간의 차이는 있다. 그러나 그것은 작은 차이일 뿐, 비서의 역할과 에이전트 본연의 임무라는 점에서 둘은 사실상 같은 목적을 향한다. 결정적인 차이는 기능이 아니라 토대에 있다. 헤르메스는 한 명의 영웅이 아니라 조직이 개발을 이끌고 있어, 한 개인의 거취에 운명이 좌우되지 않는 연속성을 갖는다. 명시적인 보안 경계와 권한 통제의 설계를 갖추고 있어, 무엇이 허용되고 무엇이 막히는지를 들여다보고 관리하기가 더 수월하다.
물론 헤르메스라고 해서 모든 위험에서 자유로운 것은 아니다. 도구에 접근하고 명령을 실행할 수 있는 모든 에이전트는 그 권한만큼의 위험을 안는다. 그러나 이 둘을 나란히 놓고 보면 한 가지 흐름이 또렷해진다. 한 사람의 천재성과 속도에 기댄 도구는 빠르게 타올랐다가 그 사람과 함께 흔들렸고, 조직과 책임 구조를 갖춘 도구는 화려함은 덜할지언정 더 단단한 연속성을 보였다. 에이전트 생태계가 어디로 향하는지를 이 대비가 말해준다. 누가 만들었는가만큼이나, 누가 끝까지 책임지는가가 도구의 생명을 결정하기 시작한 것이다.
앱스토어가 이미 걸어간 길
지금 에이전트 생태계가 겪는 혼란은 사실 처음 보는 풍경이 아니다. 정확히 같은 길을 십수 년 전에 걸어간 시장이 있다. 스마트폰 앱스토어다.
2008년 애플이 앱스토어의 문을 열었을 때, 그것은 거대한 골드러시의 시작이었다. 누구나 앱을 만들어 전 세계에 팔 수 있다는 약속 앞에 1인 개발자들이 몰려들었다. 2010년대 초의 앱 시장은 가능성과 무질서가 뒤섞인 거친 개척지였다. 방귀 소리를 내는 앱, 손전등 앱, 하루 만에 만들어 올린 조악한 게임이 넘쳐났다. 혁신적인 발상이 매일 쏟아졌지만, 그만큼 자주 멈추고 충돌하고 사라지는 앱도 많았다. 만든 사람의 이름조차 알 수 없는, 책임지지 않는 결과물의 바다였다.
그 무질서를 정리한 것은 두 가지 힘이었다. 하나는 애플과 구글이라는 플랫폼 사업자의 통제였다. 그들은 심사를 강화하고 기준을 높이며, 일정 수준에 미치지 못하는 앱을 걸러내기 시작했다. 다른 하나는 기업의 진입이었다. 앱 시장의 수익이 더 이상 개인 용돈벌이 수준이 아니라는 것을 깨달은 기업들이 본격적으로 뛰어들면서, 검증되지 않고 품질이 낮던 앱들은 안정성과 완성도를 갖춘 제품에 자리를 내주었다. 통제와 책임이 들어오자, 시장은 무질서한 개척지에서 신뢰할 수 있는 상점으로 성숙해갔다.
오늘의 에이전트 생태계는 그 초창기 앱스토어를 거의 그대로 닮았다. 누구나 에이전트를 만들고 서비스를 띄울 수 있는 자유가 열렸고, 그 자유 속에서 혁신과 오류가 한꺼번에 쏟아진다. 오픈클로의 부상과 혼란, 헤르메스를 비롯한 대안의 등장은 이 시장이 아직 개척지의 단계에 있음을 보여준다. 그리고 앱스토어의 역사가 알려주듯, 다음 단계는 정해져 있다. 인공지능 코딩이 만들어내는 결과물의 품질을 안정화하는 일, 그것이 이 시장이 풀어야 할 과제다.
이 변화의 본질은 두 종류의 시장 사이의 이동이다. 한쪽에는 무작위로 모인 여러 사람이 책임을 지지 않은 채 빠르게 일하며 혁신을 쏟아내는 시장이 있다. 다른 한쪽에는 느릴지언정 이미 검증된 것을 안정화하고 수익으로 연결하는 시장이 있다. 개척지의 거친 활력은 분명 가치가 있다. 새로운 발상의 대부분은 그 무질서 속에서 태어난다. 그러나 그 발상이 수많은 사람의 일상을 떠받치는 서비스가 되려면, 어느 시점에는 반드시 책임과 검증의 단계를 통과해야 한다. 앱스토어가 그러했듯, 에이전트도 그 문을 통과하는 중이다.
그러므로 인공지능 코딩이 위험하니 멈춰야 한다는 결론은 성급하다. 정확한 진단은 그 반대다. 인공지능 코딩은 안 되는 것이 아니라, 기업을 통한 책임과 적극적인 QA를 통한 안정화라는 두 기둥을 세웠을 때 비로소 제대로 되는 것이다. 함무라비가 건축가에게 요구한 것은 집을 짓지 말라는 것이 아니라, 무너지지 않게 지으라는 것이었다. 에이전트 시대에 우리가 요구해야 할 것도 코드를 생성하지 말라는 것이 아니라, 무너졌을 때 책임질 자가 있고 무너지지 않도록 검증할 체계가 있는 코드를 만들라는 것이다.
이제는 누구나 애플리케이션을 만들고 서비스를 띄울 수 있다. 그것은 분명한 진보이고, 되돌릴 수 없는 흐름이다. 그러나 거기에 수익성을 얹고, 오래 유지하며, 안정적으로 운영하는 일은 전혀 다른 차원의 능력을 요구한다. 그리고 그 능력은 결국 비슷한 일을 수없이 겪으며 경험을 축적해온 집단에게서 나올 수밖에 없다. 만들 줄 아는 사람은 많아졌지만, 만든 것을 끝까지 책임질 줄 아는 사람은 여전히 드물다. 4천 년 전 바빌론의 돌기둥이 던진 질문은 형태를 바꾸어 우리 앞에 다시 놓였다. 코드를 만든 자가 사라진 시대에, 무너지지 않는 것을 세우는 자는 누구인가?