AI로 쉽게 지은 업무 시스템, 만든 사람도 모르는 진흙덩이가 된다

주말 동안 AI에게 부탁해 메일 요약, 할 일 정리, 고객 문의 분류를 한 번에 해 주는 작은 업무 시스템을 만들었습니다. 몇 주는 마법 같았습니다. 그런데 어느 날 요약이 엉뚱한 자료를 끌어오기 시작했고, 고치려고 폴더를 열어 보니 어떤 파일이 무슨 일을 하는지 만든 본인도 설명하지 못합니다. 결국 “어디가 문제인지 찾아서 고쳐 줘”라고 다시 AI에게 맡깁니다.

코딩을 모르는 사람도 이제 ‘시스템 설계자’가 되었습니다

사용성 연구 기관 닐슨 노먼 그룹(NN/g)은 개발자가 아닌데도 Claude Code나 Claude Cowork 같은 에이전트 도구로 복잡한 업무 시스템을 짓는 사람들을 ‘바이브 아키텍트’라고 부르며 관찰 연구를 했습니다. 연구진이 찾아낸 참가자는 기술 배경이 없는 7명이었습니다. 팀을 위해 자동화 흐름을 만들고 웹 앱을 띄우는 운영 담당자, 퇴근 후와 주말에 개인용 도구를 만드는 금융사 디자이너, 여러 에이전트가 알아서 제안하고 협업하는 시스템을 돌리는 마케팅 스타트업 창업자, 팀 전체의 회의와 정보 공유를 Claude 기반 ‘운영 체제’로 바꾼 제품 책임자 같은 사람들입니다.

이들이 들인 시간은 상당했습니다. 한 참가자는 하루 8시간, 일주일에 6–7일을 AI 대화 창 안에서 보냈다고 했고, 다른 참가자는 여러 도구를 합쳐 하루 4–5시간을 쓴다고 했습니다. 그런데 연구진의 결론은 의외였습니다. 수백 시간을 써도 시스템이 투명하게 이해되는 순간은 오지 않았다는 것입니다. 한 참가자의 에이전트는 전날 밤 $200 결제를 시도했는데, 어떻게 이런 일을 막느냐는 질문에 그는 자기 파일을 뒤지다 보안 지침이 담긴 파일을 찾아냈고, 그 내용을 보고 스스로 놀랐습니다. 그 파일은 그가 쓴 것이 아니라 Claude가 만들고 관리해 온 것이었습니다.

표본이 작고 대부분 IT 업계 사람이라는 점은 연구진도 인정합니다. 모든 사용자의 모습이라기보다, 혼자서 AI로 업무 도구를 만들어 쓰는 사람이 어떤 길을 밟는지 보여 주는 관찰에 가깝습니다. 다만 그 길이 온라인 사업을 혼자 꾸리는 사람의 길과 많이 닮았습니다.

만들기가 공짜가 되자 ‘진흙덩이’가 더 빨리 쌓입니다

같은 연구를 바탕으로 쓴 후속 글에서 NN/g는 소프트웨어 공학의 오래된 개념 하나를 꺼냅니다. 브라이언 푸트와 조지프 요더가 1997년 발표한 논문의 ‘빅 볼 오브 머드(big ball of mud)’, 즉 큰 진흙덩이입니다. 두 저자는 이를 “haphazardly structured, sprawling, sloppy”한 시스템, 설계보다 당장의 편의가 구조를 정한 시스템이라고 정의했습니다. 흥미로운 점은 이들이 진흙덩이를 무작정 비난하지 않았다는 것입니다. 시간과 돈과 전문성이 모자란 현실에서 무언가는 돌아가야 하니, 진흙덩이는 실제로 가장 널리 쓰이는 구조였고 나름의 효과가 있다고 보았습니다.

옛날 진흙덩이는 자원이 부족해서 생겼습니다. 지금은 반대입니다. NN/g는 AI가 부족을 풍요로 바꾸었고, 만드는 비용이 싸니 무엇을 먼저 할지 고르게 만드는 압력이 사라져 사람들이 과하게 짓는다고 봅니다. 한 숙련 참가자는 AI를 잘 쓴다는 사람들의 시스템을 두고 화려한 도구는 많은데 들인 시간만큼 가치는 크지 않다며, 만들기가 쉬우니 만드는 일 자체가 생산적으로 느껴진다고 말했습니다.

쓰다 버릴 코드가 업무의 뼈대가 되는 과정은 옛 소프트웨어와 똑같습니다

NN/g는 푸트와 요더가 정리한 패턴 가운데 5가지를 관찰 세션에서 그대로 보았다고 합니다. 시작은 ‘쓰고 버릴 코드’입니다. 에이전트가 거슬리는 행동을 하지 않도록 규칙 파일 하나를 대충 만들어 두면, 사람은 다른 일로 넘어가도 AI는 그 파일을 성실하게 계속 참고하고, 어느새 업무 흐름이 그 파일에 기대게 됩니다. 한 참가자는 메일과 할 일과 회의록을 묶어 그날의 우선순위를 뽑는 자동화를 Claude와 함께 만들었는데, 이제는 그 방식에 갇혀 처음부터 다시 만들 시간을 내지 못한다고 털어놓았습니다.

다음은 ‘조금씩 덧붙이기’입니다. 코딩을 못하는 한 참가자는 팀이 Asana에 흩어진 50개가 넘는 작업을 일일이 보지 않도록 프로젝트 상태 위젯을 만들었고, 오해가 생기자 대시보드를 붙였고, 결국 둘을 합쳐 완료일 예측과 재무용 시간 기록까지 하는 전사 도구로 키웠습니다. 자랑할 만한 결과지만, 정해진 출시 주기 없이 늘 확장 중인 시스템에는 ‘완성’ 상태가 없습니다. 몇몇 참가자는 자기 시스템이 쓰는 중요한 파일이 어디 있는지 연구진 앞에서 찾지 못해 AI에게 찾아 달라고 했습니다.

그 뒤로 ‘일단 돌아가게 두기’와 ‘양탄자 밑에 쓸어 넣기’가 이어집니다. 연결이 자주 끊기면 구조를 바꾸는 대신 매번 손으로 다시 잇고, 정리하지 못한 자료는 이름 규칙 없는 폴더 하나에 몰아넣습니다. 한 참가자는 하루 종일 기사와 링크를 그런 폴더에 쌓아 두었다가 AI에게 관련 자료를 뽑아 달라고 했는데, 엉뚱한 글이 나와 지시문을 고치는 데 45분을 썼습니다. AI가 어질러진 서랍을 놀랍도록 잘 뒤져 주기 때문에 더 많이 쓸어 넣고 싶어지지만, 그 45분은 한계가 있다는 신호라고 연구진은 해석합니다.

다시 지을 때를 고를 수 있는 사람은 맥락을 나눠 둔 사람입니다

마지막 패턴은 ‘다시 짓기’입니다. 시스템이 더 이상 일에 맞지 않을 때, 아무도 구조를 이해하지 못할 때, 더 나은 일하는 방식을 알게 되었을 때 사람들은 다시 지었습니다. 팀 전체가 쓰는 맥락 라이브러리를 만든 한 제품 책임자는 이미 한 번 다시 지었고 또다시 짓는 중이었는데, 어느 순간 머릿속에 담을 수 없을 만큼 커졌기 때문이라고 했습니다. 같은 일은 남이 만든 시스템을 물려받을 때도 생깁니다. 직원에게 자동화를 넘겨줄 생각이라면 특히 새겨들을 부분입니다.

NN/g가 제안하는 판단 기준은 질문 하나입니다. 시스템이 일하는 방식을 바꾸고 싶을 때, AI가 참고하는 맥락 중 어디를 바꿔야 하는지 아는가. 연구진은 맥락 라이브러리가 3가지 맥락으로 이루어진다고 봅니다. 모든 일에 적용되는 전역 맥락, 특정 작업이나 프로젝트에만 쓰는 지역 맥락, 그리고 메일이나 메신저, 회의록처럼 AI가 뒤질 수는 있지만 일부러 관리하지 않는 주변 맥락입니다. 이 구분이 머릿속에 살아 있으면 작은 보수로 오래 버틸 수 있고, 구분이 흐려지면 AI만 길을 아는 상태가 됩니다.

그래서 권하는 습관도 거창하지 않습니다. 전역 규칙과 특정 작업 지시를 한 파일에 섞지 않고, 무언가를 고칠 때 “알아서 고쳐 줘” 대신 “전역 규칙의 이 부분을 바꿔 줘”처럼 어느 층을 바꾸는지 말하고, 전역 맥락은 한자리에서 처음부터 끝까지 다시 읽을 수 있을 만큼 짧게 유지하는 것입니다. 상세페이지 문구 생성, 고객 응대 초안, 주간 매출 요약을 AI에게 맡기고 있다면, 브랜드 말투 같은 공통 규칙과 각 작업 지시가 어디에 따로 있는지부터 확인해 보는 식입니다. 연구진의 말대로 AI로 짠 시스템은 다시 짓는 것 자체는 빠르고 싸며, 어려운 것은 새 시스템이 무엇이어야 하는지 아는 일입니다.

AI가 대신 길을 찾아 줄 수 있는 동안은 진흙도 견딜 만하지만, 다시 지을 때는 그 길을 내가 알고 있어야 합니다.