AI 에이전트 시스템은 왜 취약한 진흙덩이가 되는가

태너 콜러(Tanner Kohler)는 AI로 시스템을 쉽게 만들 수 있게 되면서 사용자가 에이전트 시스템을 조금씩 덧붙여 키우고, 결국 구조를 이해하기 어려운 취약한 상태에 빠질 수 있다고 설명한다. 그는 시스템을 재구축할 시점을 판단하려면 맥락(context)의 역할을 구분해 관리해야 한다고 제안한다.

AI 에이전트와 함께 작동하는 시스템을 만드는 일도 소프트웨어 엔지니어링이다. 그러나 기술 배경이 많지 않은 ‘바이브 아키텍트(vibe architect)’가 일상 업무를 돕는 복잡한 시스템과 대규모 맥락 라이브러리를 만들고 있다. 이들을 대상으로 한 최근 연구에서 태너 콜러는 소프트웨어 설계자들이 수십 년 동안 겪어온 문제와 비슷한 양상을 발견했다.

소프트웨어 엔지니어들은 당장의 필요를 맞추려고 이어 붙인 시스템은 취약해지고 유지하기 어려워진다는 점을 오래전부터 알고 있었다. 시스템을 바꿀 때 시간·돈·전문성이 감당할 수 있는 수준을 넘지 않도록 미리 구조를 계획해야 한다. 하지만 AI는 이런 자원이 사실상 무한한 것처럼 느끼게 한다. 우선순위를 정해야 할 압박이 없자 바이브 아키텍트들은 ‘큰 진흙덩이(big ball of mud)’를 만들고 있었다. AI 시대에는 이런 시스템도 놀라울 정도로 잘 작동하지만, 복잡성이 쌓이면 방향을 잡고 문제를 진단하거나 구조를 되살리기 어려워진다.

큰 진흙덩이란 무엇인가

큰 진흙덩이는 장기적인 내구성보다 단기적인 기능을 위해 급히 긁어모아 만든 시스템이다. 브라이언 푸트(Brian Foote)와 조지프 요더(Joseph Yoder)가 1997년 논문에서 사용한 용어로, 당시 실제 소프트웨어 대부분이 그런 모습을 보인다고 지적했다. 이런 시스템은 쓸모가 있을 수 있지만 취약해 유지 비용이 많이 든다. 급히 필요에 따라 지은 빈민가처럼 계속 땜질하고 임시방편을 써야 돌아간다. 계획도시의 기반 시설처럼 오래 버티지는 못한다.

큰 진흙덩이는 대개 자원이 부족한 상황과 현실적인 필요가 만날 때 생긴다. 시간이나 돈, 전문성이 충분하지 않아도 무언가를 만들어야 하기 때문이다. 초기 소프트웨어 팀은 ‘코드 작성과 수정(code-and-fix)’ 방식으로 일했고, 문제가 복잡해지기 전까지는 이 방식으로 버틸 수 있었다. 이후 큰 진흙덩이를 유지하기 어려워지자 성숙한 공학 분야를 본뜬 계획 중심의 ‘폭포수’ 방식이 등장했다. 하지만 모든 필요를 처음부터 예측할 수 없다는 점이 드러나면서 애자일 방식으로 옮겨갔다.

연구 참여자들도 이 역사를 되풀이하고 있었다. 이들은 구조나 내구성을 거의 미리 생각하지 않은 채 코드를 만들고 고쳤으며, 문제가 생기면 시스템을 계속 빚어 맞추려 했다. 달라진 점은 AI가 부족함을 풍요로 바꿨다는 것이다. 만들기 쉬워지자 우선순위를 정하게 하는 요인이 사라졌고, 사람들은 필요 이상으로 많은 것을 만들었다. 한 고급 사용자는 이렇게 말했다.

“AI를 잘 쓴다고 하는 사람들을 보면, 제가 보기에는 과하게 설계된 경우가 많습니다. 번듯한 용어와 눈에 띄는 도구는 많이 쓰지만, 들인 시간만큼 가치를 더 얻지는 못합니다. […] AI 덕분에 무언가를 너무 쉽게 만들 수 있다 보니, 사람들은 생산적인 기분이 들어서 실제로 과잉 구축을 시작합니다.”

대부분의 참여자는 이런 식으로 시스템을 만들었다. 혼자 일하는 경우가 많았고, AI와 X·Reddit 게시물의 안내를 받았다. 구독을 통해 방대한 토큰을 사용할 수 있었다.

시스템이 진흙덩이로 커지는 다섯 가지 양상

푸트와 요더는 큰 진흙덩이가 형성되고 유지되는 양상을 설명했다. 연구진은 세션에서 그중 다섯 가지를 관찰했다. 이는 엄격한 단계가 아니다. 사용자가 땜질하고 문제를 덮는 동안 시스템은 조금씩 자라지만, 대체로 아래 순서로 나타난다.

1. 임시로 만든 코드

사용자가 AI에 쓸모 있어 보이는 개념 증명을 만들게 하면서 시작한다. 예를 들어 에이전트가 성가시거나 문제가 되는 행동을 하지 않도록 rules.md 파일을 만든다. 이 파일은 계획하거나 충분히 시험한 것이 아니라 첫 초안이다. 사용자는 곧 다른 일로 넘어가지만 AI는 지시받은 대로 새 맥락을 계속 참조한다. 얼마 지나지 않아 사용자의 업무 흐름도 그 파일에 의존하게 된다.

한 참여자는 이메일, 작업, 회의록을 요약해 그날의 우선순위를 정하는 일일 자동화 도구를 설명했다.

“구조를 제가 직접 쓴 건 아니에요. […] Claude와 함께 구조를 만들었는데, […] 구조 자체를 만들도록 했죠. […] 이제는 그 작동 방식에 어느 정도 갇힌 것 같아요. 처음부터 다시 검토해서 개선할 시간을 낸 적이 없어요.”

이런 임시 결과물은 쓸모가 없는 경우가 드물어 그대로 남는다. 참여자들이 AI에 다시 만들라고 하지 않은 이유는 대체로 시간이 부족하거나 기존에 얻던 가치를 깨뜨릴까 두려워서였다. 시스템은 낡은 신발과 같았다. 계속 신을 수는 있지만 편한 것은 아니다. 새 신발이 더 불편하거나 잘 맞지 않을 위험을 감수하고 새로 마련하는 대신, 참여자들은 낡은 신발을 계속 신었다. 결국 신발이 닳아 재구축이 필요해졌지만, 사용자는 가능한 한 그 투자와 위험을 미뤘다.

2. 조금씩 덧붙이는 성장

새로운 필요가 생기면 사용자는 계속 붙들고 있는 원래 시스템에 기능을 더한다. 한 참여자의 도구는 세 단계를 거쳤다.

• 1단계: 참여자는 팀이 Asana에서 추적하는 업무를 충분히 파악하지 못한다고 느꼈다. 그래서 이해관계자가 50개가 넘는 작업을 일일이 살펴보지 않아도 각 프로젝트 상태를 확인할 수 있도록 AI로 Asana 위젯을 만들었다.
• 2단계: 위젯을 쓰던 이해관계자들은 Asana의 작업 다수가 제대로 완료 표시되지 않아 프로젝트가 멈춘 것으로 여겼다. 참여자는 AI에 대시보드 구성요소를 추가해 더 세부적인 정보를 보여주게 했다.
• 3단계: 참여자는 조직 전체가 모든 프로젝트의 진행 상황을 더 잘 파악할 수 있다고 봤다. 기존 위젯과 새 대시보드를 하나의 도구로 합치고, 시각화와 완료일 예측을 위한 가중 알고리즘, 재무팀을 위한 시간 추적 기능을 추가했다.

이 참여자는 코드를 쓸 수 없었다. 하지만 AI가 제약을 없애자 작은 임시 위젯이 여러 부서가 사용하는 대시보드로 커졌다. 이것이 조금씩 덧붙이는 성장이다.

참여자들은 자신이 만든 것을 자랑스러워했고, 그럴 만했다. 문제는 시스템을 확장할 방법이 계속 생긴다는 점이다. 다른 사람도 의견을 내기 시작하면 확장 가능성은 더 커진다. 여러 참여자는 AI에 개선점을 제안해 달라고 정기적으로 요청했지만, 계획된 출시 주기에 따라 작업한 사람은 없었다. 이들에게는 잠시라도 ‘완성’된 상태가 없었고, 이때 시스템은 큰 진흙덩이로 변하기 시작했다.

연구에서 가장 숙련된 사용자 중 한 명은 다음과 같은 경고를 들었다고 설명했다.

“Claude는 제가 사전 매출 단계의 인프라 작업에만 계속 매달린다고 늘 지적해요. 결국 시스템을 계속 다듬기만 하고 실제로 나가서 쓰지는 않는다는 거죠.”

다른 참여자들은 연구진 앞에서 시스템이 의존하는 중요한 파일을 찾지 못했다. AI에게 파일을 찾아 내용까지 설명해 달라고 해야 했다. 시스템이 조금씩 커지면서 파일이 어디에 있는지, AI가 어떻게 사용하는지, 그 안에 무엇이 있는지 정확히 알지 못하게 된 것이다. 시스템을 다시 만들어야 한다면 아마 그렇게 하지 못했을 것이다.

3. 계속 작동하게 만들기

시간이 지나면 시스템은 고장 나거나 원래 의도에서 벗어나거나 낡는다. 사용자는 이를 고치거나 버리거나 전면 개편해야 한다. 참여자들은 시스템에 의존하고 있었기 때문에 대부분 고치는 쪽을 택했다. 한 스타트업 창업자는 이렇게 말했다.

“어쩌면 제가 의존하고 있을 수도 있어요. […] 조금이라도 어려운 일이 생기면 […] 스스로 적극적으로 생각하기보다 도와 달라고 하죠. […] 도구를 쓸 수 없게 되면 분명 답답할 거예요.”

한 참여자의 AI 데스크톱 애플리케이션이 충돌해 대화 기록을 삭제하자, 그는 휴지통에서 파일을 되찾아 다운로드 폴더에 넣고 이후 모든 세션을 그 폴더에서 실행하기 시작했다. 큰 진흙덩이가 어떤 모습인지 보여주는 사례다.

시스템은 다른 방식으로도 실패한다. 한 참여자는 주로 AI와 작업하던 터미널에 할 일 앱 Todoist를 연결했지만, 연결이 자주 끊겼다. 그는 할 일 앱을 바꾸거나 시스템을 다시 설정하는 대신 매번 손으로 다시 연결했다.

다행히 AI는 시스템을 바꾸는 데 필요한 문턱을 크게 낮춘다. 에이전트가 사용하는 맥락 파일이 제대로 작동하지 않으면 프롬프트 한 번으로 빠르게 고칠 수도 있다. 참여자들은 변경 사항을 설명하고 AI가 적절하다고 판단한 파일을 고치도록 하는 방식으로 시스템을 유지했다. 쉽기는 하지만 정보가 시스템 어디에 있는지 사용자가 이해하기 어려워질 수 있다. 사용자는 AI가 정보를 찾아 이해하고 갱신하는 데 의존하게 된다. 장기적인 명확성과 내구성보다 단기적인 수정에 더 집중하는 셈이다.

4. 문제를 덮어두기

사용자가 엉망인 부분을 정리할 수 없거나 정리하지 않으려 하면, 나머지 시스템을 깔끔하게 유지하기 위해 문제를 한곳에 모은다. 에이전트 시스템에서 그 ‘깔개’는 잡동사니 서랍에 가깝다. 사용자는 그 안의 자료를 계속 필요로 하지만 무엇이 어디 있는지 AI만 찾을 수 있다.

한 참여자는 하루 동안 본 기사와 링크를 AI가 모으도록 자신에게 이메일로 보냈다. 자료가 너무 많아 처리하지 못하자 이름 규칙도 없는 to be synthesized 폴더에 쌓아뒀다. 나중에 프로젝트와 관련된 자료를 그 폴더에서 찾아 달라고 AI에 요청했지만, AI는 엉뚱한 기사를 가져왔다. 그는 실제 업무를 하는 대신 지시를 고치는 데 45분을 썼다.

또 다른 참여자는 Claude가 만든 파일을 Google Docs로 저장해 Drive의 최상위 폴더에 두도록 했다. Claude는 요청만 받았다면 파일을 어디든 정리할 수 있었지만, 그는 한 번도 그렇게 요청하지 않았다. 두 사례 모두 폴더가 잡동사니 서랍 역할을 했다. AI가 모으거나 만든 자료는 모두 들어갔고, 아무것도 분류되지 않았다.

이 양상은 해리 포터가 그린고트 은행을 방문하는 장면과 비슷하다. 해리는 금고가 있다는 것과 대략 무엇이 들어 있는지는 알지만, 도깨비의 안내 없이는 금고를 찾거나 이용할 수 없다. 연구 참여자들은 엉망인 시스템을 AI가 탐색하도록 맡겼고, AI는 놀라울 정도로 잘 해냈다. 그래서 더 많은 것을 계속 덮어두고 싶은 유혹이 생겼다. 더미가 커져도 AI가 계속 보완할 수 있을지는 아직 알 수 없다. 잘못된 파일을 찾아 45분을 낭비한 사례는 그 능력에도 한계가 있음을 보여준다.

5. 재구축

결국 AI 중심이든 아니든 많은 시스템은 재구축되거나 버려진다. 연구진은 에이전트 AI 시스템을 다시 만들게 되는 계기 세 가지를 관찰했다.

시스템이 필요에 맞지 않게 됨

전통적인 소프트웨어에서는 변경 비용이 커서 수정이 미뤄졌기 때문에 이런 계기가 더 일찍 찾아왔다. 신중한 바이브 아키텍트라면 필요가 바뀔 때 AI로 업데이트해 재구축 시점을 늦출 수 있다.

하지만 사용자가 성장해 시스템을 넘어서는 경우에도 시스템과 사용자의 궁합은 끝날 수 있다. 사용자는 AI가 할 수 있는 일을 배우면서 일하는 방식도 바꾼다. 어느 순간에는 계속 수정하는 것보다 새로 만드는 편이 쉬워진다. 한 참여자는 이제 모든 세션을 어떻게 진행하고 싶은지 흐름도를 그렸다. 의도를 명확히 하고, 맥락을 모으고, 모델을 조율하고, 결과를 확인하는 순서였다. 기존 시스템은 이 흐름을 지원하지 않았다. 그는 처음 시스템을 조금씩 만든 것과 달리 이번에는 계획을 세웠다. 흐름도를 AI에 올리고 구현을 요청했다.

다른 사람을 위해 만든 시스템도 사용자에게 맞지 않을 수 있다. 한 참여자는 관리자로부터 에이전트 업무 흐름과 맥락 라이브러리를 물려받았다. 시간이 지나자 그 시스템이 자신의 업무 방식과 완전히 맞지 않는다는 사실을 깨닫고 개인화했다. 기존 설계의 구멍을 메우는 것이 아니라 시스템을 개조한 것이다. 그는 이런 차이가 다른 사람과 에이전트 업무 흐름을 공유할 때 가장 어려운 부분이라고 했다.

아무도 시스템을 이해하지 못하게 됨

시스템이 조금씩 커지면 만든 사람도 구성 요소가 어떻게 연결되는지 놓칠 수 있다. 한 제품 책임자는 팀 전체가 사용해야 하는 맥락 라이브러리를 만들었다. 연구진을 만났을 때 그는 이미 한 차례 재구축한 뒤 다시 재구축하고 있었다.

“12월쯤 어느 시점에 이게 제가 머릿속에 담아둘 수 있는 수준을 넘어섰어요. 그래서 다시 관리할 수 있도록 전부 손봐야 했죠.”

시스템을 만든 적 없는 사람에게 넘겼을 때도 같은 일이 생길 수 있다. 다른 사람이 만든 큰 진흙덩이는 어떻게 구성됐는지에 관한 심적 모델이 없어서 이해하기 어렵다. AI가 새 사용자에게 구조를 익히도록 도울 수는 있지만, 새 사용자는 시스템을 개조하고 싶어 할 가능성이 높다.

더 나은 업무 방식이 생김

시스템이 잘 작동하더라도 같은 일을 더 잘하는 방법을 발견할 수 있다. 한 참여자는 두 가지 방식으로 시스템을 바꿨다. 소셜 미디어에서 새 기술과 방법을 익힐 때마다 시스템에 적용했다. 또 AI에 자신이 AI와 일하는 방식을 정기적으로 검토하고 개선점을 제안해 달라고 요청했다. 대개는 제안한 내용을 AI가 적절하다고 판단한 위치에 구현하도록 했다.

재구축이 필요한지 판단하는 법

큰 진흙덩이가 만들어지는 과정은 실수라기보다 AI가 이전보다 쉽게 실행할 수 있게 만든 정당한 전략이다. 그렇다면 언제 재구축해야 하며, 바이브 아키텍트는 이에 어떻게 대비할 수 있을까?

간단한 질문부터 시작하면 된다. 시스템 작동 방식을 바꾸고 싶을 때, 모델이 의존하는 맥락 라이브러리에서 무엇을 바꿔야 할지 알고 있는가? 맥락 라이브러리에는 서로 다른 역할을 하는 세 가지 맥락 유형이 있다.

• 전역 맥락: 시스템 전반에 적용되는 지침이나 지식
• 국소 맥락: 특정 작업, 프로젝트 또는 업무 흐름에 관한 정보와 지침
• 주변 맥락: 이메일, Slack, 회의 기록처럼 AI가 이용할 수 있지만 지속적인 맥락으로 의도적으로 관리되지는 않는 정보의 흐름

어떤 유형의 맥락을 바꿔야 하는지 알고 있다면 전면 재구축이 필요한 시점은 아직 멀었을 가능성이 높다. 작은 개조를 할 만큼 시스템을 이해하고 있기 때문이다. 반대로 답을 모른다면 서로 다른 맥락 유형이 뒤섞였다는 뜻이다. 반드시 무언가 고장 난 것은 아니지만, 시스템을 안내하는 주체가 AI뿐이고 사용자는 시스템이 망가지지 않기를 바라는 상태일 가능성이 크다.

에이전트 시스템의 온전함을 유지하려면 각 맥락 유형을 따로 살펴야 한다. 각각을 독립적으로 관리하면 필요에 따라 일부를 천천히 유지·교체하면서 전면 재구축을 오랫동안 피할 수 있다. 오래된 건물의 각 부분을 차례로 관리하는 방식과 같다. 맥락 유형이 뒤섞일수록 시스템을 버리고 다시 만드는 시점이 빨라진다. 그때 사용자는 정확히 무엇을 바꿔야 할지 알기 어렵고, 작동하는 부분을 살리고 새 시스템을 만드는 과정에서 AI의 이해에 크게 의존하게 된다. 재구축을 정확히 이끌기도 어려워진다.

맥락을 살핀다는 것은 시스템을 전부 외우라는 뜻이 아니다. 다음과 같은 작은 습관을 들이면 된다.

• 맥락 유형을 분리한다. 하나의 마크다운 파일에 전역 맥락과 국소 맥락을 함께 넣으면 경계가 흐려져 시스템의 각 부분이 무슨 역할을 하는지 파악하기 어렵다.
• 변경을 지시할 때 맥락 유형을 말한다. 각 파일의 위치나 내용을 전부 몰라도, 맥락 유형별 역할을 알면 “필요하다고 보는 곳에서 고쳐”라고 하기보다 “전역 맥락에서 XYZ를 업데이트해”라고 요청할 수 있다. 그러면 변경의 영향을 계속 파악할 수 있다.
• 전역 맥락을 가끔 처음부터 끝까지 살펴본다. 전역 맥락은 시스템의 모든 동작에 영향을 주므로 한 번에 읽을 수 있을 만큼 짧아야 한다. 그렇지 않다면 모든 상황에 적용되지 않는 지침이 섞여 들어왔을 가능성이 있다. 그런 지침은 삭제하거나 국소 맥락으로 옮긴다.
• 결과물이 나빠지면 국소 맥락을 갱신한다. 국소 맥락은 특정 목적에 맞춰야 하므로 그 목적을 달성하지 못하면 적절히 수정해야 한다.

이런 작업은 재구축이 아니라 개조다. 재구축을 비상 상황이 아니라 선택으로 만드는 방법이다. 물론 업무 방식이 발전해 사용자가 원한다면 재구축할 수 있다. 각 맥락 유형의 역할을 설명할 수 있다면 준비가 된 것이다. 목표는 재구축을 피하는 것이 아니라, 재구축을 주도할 수 있는 상태를 유지하는 것이다.

연구 세션에서는 가장 숙련된 참여자에게서도 큰 진흙덩이가 관찰됐다. 푸트와 요더는 진흙덩이가 제약에 대응하는 실용적인 방법인 경우가 많다고 봤다. AI로 많은 제약이 사라졌지만, 새 구성 요소의 유지 비용이 그만한 가치가 있는지 묻거나 시스템 구조를 신중히 계획하도록 만드는 요인이 없기 때문에 진흙덩이는 여전히 생긴다.

전통적인 소프트웨어와 달리 에이전트 시스템은 AI를 이용해 빠르고 저렴하게 재구축할 수 있다. 어려운 일은 새 시스템이 어떤 모습이어야 하는지 아는 것이다. 연구에서 가장 잘 대비된 듯 보인 참여자들은 시스템의 한계를 설명하고 무엇을 바꾸고 싶은지 말할 수 있었다. 중요한 습관은 폴더를 더 깔끔하게 정리하는 데 그치지 않는다. 각 구성 요소가 무슨 일을 하는지, 여전히 쓰이는지, 처음부터 다시 만든다면 무엇을 바꿀지 주기적으로 돌아보는 일이다. AI가 시스템을 탐색할 수 있는 동안에는 진흙덩이를 감당할 수 있다. 재구축은 AI가 더는 길을 찾지 못하기 전에 해야 한다.

참고 문헌: 브라이언 푸트와 조지프 요더, 1999, “Big Ball of Mud”, *Pattern Languages of Program Design 4*, Addison-Wesley, 보스턴, 653~692쪽.