AI 에이전트가 실패하는 이유는 엉망인 아키텍처 때문이다
AI 에이전트는 겉보기에는 강력해 보이지만 실제로는 취약한 경우가 많습니다.
12시간 전, 제 스킬 시스템은 이랬습니다:
- 3개의 서로 다른 디렉토리에 분산된 34개의 스킬.
- 28개의 스킬이 움직인다고 되어 있었지만, 실제로 움직인 것은 2개뿐이었습니다.
- 두 개의 관리 시스템이 서로 통신하지 못했습니다.
- 아무도 모르는 사이에 한 도구가 스킬 내의 코드 100줄을 삭제했습니다.
대부분의 사람들은 거대 언어 모델(LLM)을 찬양합니다. 모델이 곧 힘이라고 생각하죠. 하지만 모델은 단지 뇌일 뿐입니다. 제대로 작동하는 에이전트에는 네 가지가 필요합니다:
- Memory
- Skills
- Hooks
- Extensions
한 부분이라도 실패하면 에이전트 전체가 실패합니다. 제 실수는 버그가 아니었습니다. 바로 파편화였습니다. 경로가 끊겨 있었고 연결 고리가 누락되어 있었습니다.
AI 개발의 위험 요소는 계획 없이 즉시 도구를 사용하는 것입니다. 시간을 아끼기 위해 Firecrawl, Crawl4ai, 그리고 다양한 MCP 서버를 추가합니다. 하지만 서드파티 스킬이 115개에 달하게 되면 세 가지 문제가 발생합니다:
- 이름 충돌(Naming conflicts): 이름이 같은 두 스킬이 시스템을 충돌시킵니다.
- 환경 오염(Environment pollution): 한 스킬이 다른 스킬의 환경을 망가뜨립니다.
- 업데이트 오류(Broken updates): API 업데이트가 체인을 소리 없이 끊어버립니다.
이것이 바로 아키텍처 엔트로피입니다. 시스템이 커질수록 추적하기가 점점 더 어려워집니다.
프로젝트가 안정될 때까지 기다렸다가 정리하려 하지 마세요. 그것은 함정입니다. 저는 시스템을 수정하는 데 12시간을 썼습니다:
- 흩어져 있던 디렉토리들을 두 개의 깔끔한 경로로 통합했습니다.
- 실수로 인한 삭제를 감지하는 게이트를 추가했습니다.
- 시스템 변경 시 제작자에게 알림을 보내는 규칙을 만들었습니다.
- 오래되고 쓸모없는 파일들을 삭제했습니다.
이것은 새로운 기능을 개발하는 것이 아니었습니다. 아키텍처 위생(Hygiene)을 관리하는 것이었습니다. 위생 관리는 복리 투자와 같습니다. 단순한 유지보수 비용이 아닙니다.
AI 에이전트를 구축한다면 이 규칙을 따르세요: 첫날부터 Memory와 Skills에 대한 규칙을 설정하십시오.
다음 질문들을 초기에 던지십시오:
- Memory는 어디에 저장되는가?
- 버전을 어떻게 관리하는가?
- 이름 충돌을 피하기 위해 Skills는 어디에 위치하는가?
- Extensions 간의 의존성을 누가 기록하는가?
- 누가 정기적인 감사를 수행하는가?
이 질문들에 대한 답변이 에이전트가 얼마나 크게 성장할 수 있는지를 결정합니다. AI의 병목 현상은 파라미터 수가 아닙니다. 바로 엉망인 집입니다.
Optional learning community: https://t.me/GyaanSetuAi