AI랑 대화 하면서 챗봇이 연결 되고 뿌듯한 마음을 가졌다.
그러나, 자잘한 오류라고 생각해서 2~3일 동안 AI가 해보자는 방향으로 계속 수정했다.
하지만, 결과는 처참했고 해당 건은 연결만 된 모양새를 갖췄을 뿐이지 챗봇이 정상동작을 하지 않았다.
그래서, 회사에 있는 개발자에게 도움을 요청하니 개발자는 요구사항과 쓰려는 방향을 듣고 n8n을 구성해서 줬다.
그것을 AI한테 분석하고 회고 해달라는 내용을 작성해본다.
개발자에게 받은 n8n flow였다.
!표가 뜬 부분은 개발자의 API 및 계정 연결이기에 !표가 뜰 뿐…
그래서 이부분에 대해서 AI에게 회고를 요청했다.(사실 좀 화가 나기도 했다 철썩같이 믿었던 AI에게 배신을 당한 느낌)
1. 설계의 철학 차이: ‘자율형’ vs ‘정해진 길’
처음에는 AI회고를 보고, 화가났지만 시간이 흐른 지금 보니 내가 원하는 방식은 AI가 추천해준 방식이였다.
개발자의 방식은 엑셀, 문서 등 각 문서 하나하나 지칭해놓고 문서가 추가 될 때마다 노드가 추가 되는 방식이였고, 내가 원하는 요구사항은 드라이브 내에서 AI가 자유롭게 검색하고 데이터 안의 연계성을 확인해서 대답하는 방식이였다.
2. 기술적 핵심 차이 분석
- AI의 역할 분담 (Multi-Stage Agent)
: 한 명의 비서에게 “찾고, 읽고, 요약해”라고 다 시킨 것이라면, 개발자의 방식은 역할을 나눴음
– 첫 번째 AI Agent: 질문을 분석해서 어떤 시트를 읽어야 할지 ‘분류’만 함.
– Switch 노드: AI의 분석 결과에 따라0번 길(시트 읽기)등으로 길을 터줌.
– 두 번째 AI Agent1: 앞 단계에서 노드가 직접 긁어온 ‘진짜 데이터’를 받아서 최종 답변만 예쁘게 만듬. - 데이터 수집의 확실성 (
Aggregate노드)
: 개발자 워크플로우 중간에 있는Aggregate노드가 신의 한 수
– 구글 시트에서 가져온 여러 줄의 데이터를 하나로 뭉쳐서 마지막 AI에게 한 번에 떠먹여 줌.
– 제가 제안한 방식은 AI가 시트 도구를 쓰더라도 “한 줄씩” 읽다 보니 전체 내용을 파악하지 못하고 오류가 날 확률이 높음. - 모델의 차이 (Gemini vs Anthropic)
: Gemini 모델의 사용량 제한(429 Error)으로 고생의 난의도가 높았고, 개발자는 Anthropic (Claude) 모델과 Structured Output Parser를 사용해 모델 호출 제한을 피하고, AI가 더 정확한 JSON 값을 내뱉도록 설계.
AI의 회고
“다 시키는 대로 했는데 왜 안 되냐”는 답답함을 드린 이유는, n8n AI Agent의 ‘도구 사용 능력’을 너무 과신했기 때문
* 문제점: AI가 드라이브에서 파일을 찾고(Search), 그 ID를 받아서 다시 시트를 읽는(Get Rows) 연속 동작은 생각보다 성공률이 낮고 타임아웃이 잦습니다.
* 교훈: 데이터가 중요한 워크플로우에서는 AI에게 모든 판단을 맡기기보다, AI는 ‘길찾기(Switch)’만 시키고 실제 데이터는 n8n의 전용 노드로 직접 가져오는 것이 가장 확실한 정답입니다.
나의 회고
AI에게 너무 넓은 자율성을 부여한 요구사항이 화근이었다. 지난 2~3일간의 고충이 AI의 한계 때문이라고 생각했는데, 회고를 진행하며 정작 문제는 나의 불명확한 가이드라인에 있었음을 깨달았다.
개발자는 구현 가능한 경로를 따라 한 땀 한 땀 노드를 설계하지만(업무 프로세스 매칭), AI는 어떻게든 요구사항을 완수하려다 보니 예상치 못한 사이드 이슈를 대거 양산한 것이다. 이론보다 실습 위주로 학습해온 탓에 기본기가 부족했음을 인정하게 된다. 앞으로는 기술적 구현력을 넘어, 실행 가능한 범위를 정확히 정의하는 ‘설계의 기술’을 더 연마해야겠다.
실패 했으나, 기록은 남겨보도록 하겠다.