AI로 자동화를 하나쯤 만들어 본 분이라면 비슷한 경험이 있을 겁니다. 예를 들어 블로그에 새 글이 올라오면 요약해서 슬랙으로 보내 주는 자동화를 만들었다고 해 보겠습니다. 처음 테스트한 블로그에서는 아주 잘 돌아갔습니다. 주말을 들여 만든 보람이 있었죠.

문제는 몇 주 뒤에 생깁니다. 다른 블로그 주소를 하나 추가했더니, 슬랙에 요약 대신 "본문 내용이 없어 요약할 수 없습니다"라는 한 줄만 올라옵니다. 코드를 열어 보지만 어디서부터 봐야 할지 감이 오지 않습니다.

이번 강의에서는 이렇게 시간을 들여 만든 프로그램이 왜 중간에 멈추는지 이야기해 보려고 합니다. 소프트웨어를 노드로 나눠 보는 방법과, 노드가 늘어날 때 무엇이 어려워지는지를 차례로 살펴보겠습니다.

요약이 안 됐던 이유는 새 블로그의 본문 위치가 처음 블로그와 달랐기 때문입니다. 그래서 AI에게 "이 블로그는 article 태그 안에서 본문을 찾아 줘"라고 요청했고, 문제는 금방 해결됐습니다.

그다음 블로그는 글이 여러 페이지로 나뉘어 있어서 규칙을 또 하나 추가했습니다. 그다음은 로그인을 해야 글이 보이는 블로그였고요. 이렇게 블로그를 하나 추가할 때마다 그 블로그 전용 규칙이 하나씩 늘어났습니다.

이렇게 깎아 온 자동화는 지금까지 확인한 블로그에서는 잘 돌아갑니다. 하지만 딱 거기까지입니다. 구조가 조금만 다른 블로그가 들어오면 또 멈추고, 우리는 또 규칙을 하나 추가합니다. 문제를 만날 때마다 그 문제만 고치다 보면 자동화는 점점 특정 상황에만 맞게 깎인 워크플로우(Workflow)가 됩니다. 워크플로우는 프로그램이 일을 처리하는 순서와 흐름을 말합니다. 그림 1이 이 상황입니다.

그럼 규칙을 더 꼼꼼하게 붙이면 될까요? 블로그의 구조는 셀 수 없이 다양해서 규칙으로 모든 경우를 따라잡기는 어렵습니다. 그보다 먼저 필요한 것은 이 자동화가 안에서 어떻게 돌아가는지 아는 일입니다.

소프트웨어는 기계입니다. 겉으로는 버튼 하나, 결과 하나만 보이지만 안에서는 여러 부품이 정해진 순서대로 맞물려 돌아갑니다. 이 강의에서는 기계의 부품에 해당하는 것을 노드(Node)라고 부르겠습니다. 노드란 한 가지 일을 맡은 작업 단위로, n8n 같은 자동화 도구에서 그림 속 블록 하나하나를 부르는 이름입니다. 코드에서는 쓰임에 따라 모듈(Module)이나 컴포넌트(Component)라고 부르기도 합니다. 블로그 요약 자동화를 노드로 나눠 보면 다음과 같습니다.

• 새 글 확인: 정해진 시간마다 블로그에 새 글이 있는지 살펴봅니다.
• 본문 가져오기: 글 페이지에서 본문만 골라냅니다.
• 요약 요청: 본문을 AI 모델에 보내 요약을 받습니다.
• 슬랙 전송: 받은 요약을 슬랙 채널에 올립니다.

이렇게 나눠 보면 앞의 문제가 다르게 보입니다. 요약이 안 됐던 건 본문 가져오기 노드가 새 블로그의 구조를 몰랐기 때문입니다. 그런데 우리는 어느 노드의 문제인지 모른 채 결과만 보고 고쳤습니다. 원인이 된 노드를 손보는 대신, 문제가 드러난 블로그를 하나씩 예외로 처리한 셈이죠. 그림 2는 이 차이를 보여 줍니다.

게다가 이렇게 덧붙인 규칙도 결국 노드가 됩니다. 고칠수록 기계 안의 노드가 늘어나고, 노드끼리의 연결도 늘어납니다. 기계가 정교해질수록 겉에서 보고 고치기는 더 어려워집니다.

노드의 정식 이름을 알아 두면 AI에게 일을 맡길 때도 도움이 됩니다. "요약이 이상해"라고 말하는 대신 "본문 가져오기 모듈만 고쳐 줘"라고 범위를 좁혀 지시할 수 있기 때문입니다.

요즘 AI 에이전트는 자연어로 말을 걸어도 알아서 움직입니다. "이 블로그 글 요약해서 슬랙에 올려 줘"라고만 해도 결과가 나오니, 안쪽도 말처럼 느슨하게 돌아갈 것 같습니다. 하지만 기계는 그렇지 않습니다. 말로 시작한 일도 안에서는 어떤 노드가, 어떤 순서로, 무엇을 받아 무엇을 넘기는지가 정해진 대로 돌아갑니다.

여러분이 만드는 에이전트나 스킬도 마찬가지입니다. 겉으로는 대화하듯 쓰지만, 사실상 정해진 입력을 받아 정해진 순서로 처리하는 결정적인 기계입니다. 여기서 결정적(Deterministic)이라는 말은 같은 입력이 들어오면 언제나 같은 길로 처리된다는 뜻입니다. 블로그 요약 자동화라면 새 글이 들어왔을 때 언제나 본문 가져오기가 먼저 돌고, 그 결과가 요약 요청으로 넘어가야 합니다. 이 순서와 연결이 그때그때 달라지면 같은 블로그를 넣어도 결과가 매번 달라지고, 어디가 잘못됐는지 찾을 수도 없습니다.

물론 AI 모델이 쓰는 요약 문장 자체는 매번 조금씩 다를 수 있습니다. 그래서 더더욱 그 문장을 어디서 받아 어디로 넘기는지는 흔들리지 않게 정해 둬야 합니다. 연결이 정해져 있지 않으면 좋은 모델을 써도 답이 엉뚱한 노드로 넘어갈 수 있습니다.

복잡성이 커진다는 게 실제로 어떤 모습인지 직접 보겠습니다. 아래 그림 3은 두 자동화를 n8n 같은 노드 그림으로, 같은 축척에 맞춰 그린 것입니다. A는 아침마다 날씨를 알려 주는 자동화이고, B는 고객 문의 메일에 자동으로 답장하는 자동화입니다.

노드를 하나 눌러 보세요. 누른 노드가 고장 나고, 그 때문에 함께 멈추는 노드가 빨간색으로 표시됩니다. B에서는 주문 DB 조회를 눌러 보세요.

그림 3. 같은 축척으로 그린 두 자동화. A는 노드 3개, B는 노드 12개입니다.

A는 노드 세 개가 한 줄로 이어져 있습니다. 어디가 고장 나든 그 뒤만 멈추니 원인을 찾기도 쉽습니다.

B는 사정이 다릅니다. 노드가 열두 개이고, 처리 경로가 여러 갈래로 나뉩니다. 특히 배송 문의와 환불 문의는 주문 DB 조회라는 노드를 함께 씁니다. 환불 쪽 문제를 고치려고 이 노드를 건드리면 배송 쪽 답장까지 영향을 받습니다. 어떤 노드가 어디에 연결돼 있는지 모르면, 하나를 고칠 때마다 다른 하나가 망가지는 일이 반복됩니다.

에이전트를 만들다 보면 어느 순간 막히는 느낌이 듭니다. 처음에는 요청하는 대로 척척 붙던 기능이, 어느 순간부터 하나를 고치면 다른 하나가 어긋나고, 무엇을 더 요청해야 할지 감이 오지 않습니다. 이 막히는 느낌의 정체가 바로 내가 다룰 수 있는 복잡성의 크기입니다. 프로그램이 그 크기를 넘어선 순간부터 우리는 안을 보지 못한 채 겉에서만 고치게 됩니다.

그림 3의 A는 처음 만들어 보는 사람도 충분히 관리할 수 있습니다. 반면 B를 관리하려면 노드마다 맡은 일, 데이터가 지나가는 경로, 중간에 실패했을 때의 처리 방법을 알고 있어야 합니다. AI 덕분에 이제는 B 같은 프로그램도 하루 만에 만들 수 있지만, 만드는 속도가 빨라진 만큼 이해하는 속도까지 빨라지지는 않았습니다.

복잡성의 크기를 키우는 법

그럼 이 크기는 어떻게 키울 수 있을까요? 같은 현상을 두고 "이거 고쳐 줘"를 반복하는 것으로는 커지지 않습니다. 고쳐 달라는 요청은 결과만 바꿀 뿐, 안에서 무엇이 어떻게 돌아가는지는 여전히 모르는 채로 남기 때문입니다. 내부를 모르면 그 위에 무엇을 더 얹을 수 있는지도 알 수 없습니다.

크기를 키우려면 기계의 안을 직접 다뤄 봐야 합니다. 방법은 두 가지입니다.

1. 보이게 만들기: 그림 3처럼 내 프로그램을 노드와 화살표로 그려 봅니다. 그려 보면 어떤 노드를 여러 곳에서 함께 쓰는지, 데이터가 어디서 갈라지는지가 드러납니다.
2. 직접 조립하기: AI에게 결과를 맡기기 전에, 어떤 노드를 어떤 순서로 이을지 내가 먼저 구상합니다. 레고를 조립하듯 블록마다 맡을 일을 정하고 끼울 자리를 고른 뒤, 그 설계대로 만들어 달라고 요청합니다.

여기서 중요한 건 머리가 좋고 나쁨이 아닙니다. 레고를 높이 쌓는 사람은 아래층 블록이 어떻게 맞물려 있는지 아는 사람입니다. 소프트웨어도 같아서, 내부를 잘 파악할수록 더 높이 쌓을 수 있습니다.

마치며

문제를 만날 때마다 그 경우만 고치면 자동화는 확인한 상황에서만 돌아가게 됩니다. 소프트웨어는 자연어로 움직이더라도 안에서는 정해진 노드가 정해진 순서로 돌아가는 기계인데, 우리가 그 노드를 모른 채 결과만 보고 고치기 때문입니다. 에이전트를 만들다 막히는 느낌이 든다면, 그곳이 지금 내가 다룰 수 있는 복잡성의 끝입니다.

그 끝은 현상을 고쳐 달라는 요청을 반복해서는 넓어지지 않습니다. 노드를 그려 보고 조립 순서를 직접 구상하면서 안쪽을 알아 갈수록 더 높이 쌓을 수 있습니다. 그래서 이 커리큘럼은 노드 하나하나가 무슨 일을 하는지부터 시작합니다. 다음 강의에서는 이 노드들이 애초에 어떤 문제를 풀려고 만들어졌는지 살펴보겠습니다.

이 Lesson의 용어

• 노드 (Node): 한 가지 일을 맡은 작업 단위. 코드에서는 모듈(Module), 컴포넌트(Component)라고도 부른다
• 워크플로우 (Workflow): 프로그램이 일을 처리하는 순서와 흐름
• 결정적 (Deterministic): 같은 입력이 들어오면 언제나 같은 순서와 같은 경로로 처리되는 성질
• 복잡성: 노드의 수, 노드끼리의 연결, 경로의 갈래가 늘어나 한눈에 파악하기 어려워진 정도