모델이 곧 제품은 아닙니다. 진짜 제품은 따로 있습니다.
저는 AI를 출시하는 엔지니어들과 소통하고 제품을 만드는 데 시간을 보냅니다. 데모와 실제 프로덕션 시스템 사이에는 간극이 존재합니다. 많은 이들이 이 간극에 대해 솔직하지 않습니다.
누구나 모든 것을 에이전트(agent)라고 부릅니다. 루프가 포함된 스크립트도 에이전트이고, 메모리 기능이 있는 챗봇도 에이전트입니다. 이는 엔지니어링 실수를 유발합니다. 단순한 작업에는 과도한 설계를 하고, 복잡한 작업에는 설계를 소홀히 하게 됩니다.
에이전트에게는 목표가 필요합니다. 단순히 지시를 따르는 것이 아닙니다. 에이전트는 다음에 무엇을 할지 스스로 결정합니다. 실패를 처리하며, 언제 작업이 끝났는지 인지합니다.
- 사람이 시스템에 모든 단계를 일일이 알려준다면, 그것은 채팅 인터페이스입니다.
- 시스템이 실패한 도구 호출(tool call)로부터 복구할 수 있다면, 당신은 에이전트를 만들고 있는 것입니다.
- 시스템이 목표를 하위 작업(subtasks)으로 분해한다면, 그것은 진짜 에이전트입니다.
실제 에이전트 배포 사례는 범위가 좁습니다. 문서 추출이나 코드 리뷰처럼 한 가지 일을 제대로 수행합니다. 성공적인 팀은 새로운 모델을 쫓지 않습니다. 대신 다음 세 가지 영역에 집중합니다.
- 도구 설계(Tool design): 인터페이스가 얼마나 깔끔한가?
- 실패 처리(Failure handling): 도구가 아무것도 반환하지 않을 때 어떤 일이 발생하는가?
- 관측 가능성(Observability): 에이전트가 왜 그런 결정을 내렸는지 추적할 수 있는가?
LangChain이나 CrewAI 같은 프레임워크보다 패턴이 더 중요합니다. 프레임워크는 비계(scaffolding)일 뿐이며, 아키텍처가 곧 건물입니다.
다음 패턴을 사용하세요:
- 계획 후 실행(Plan then execute). 계획을 위한 단계와 실행을 위한 단계를 분리하세요.
- 검색과 추론의 분리(Separate retrieval from reasoning). 컨텍스트를 가져오는 것과 컨텍스트를 사용하는 것은 서로 다른 작업입니다.
- 명시적 핸드오프(Explicit handoffs). 한 에이전트가 다른 에이전트에게 작업을 넘길 때 그 과정을 구조화하세요.
RAG는 표준이지만, 청킹(chunking)이 잘못되는 경우가 많습니다. 문서를 제대로 나누지 않으면 모델은 컨텍스트를 잃고 환각(hallucination)을 일으킵니다. RAG 결과가 쓸모없다면 청킹과 메타데이터를 수정하세요. 임베딩 모델을 탓하지 마세요.
모델은 점점 좋아질 것입니다. 컨텍스트 창은 커질 것이고, 비용은 낮아질 것입니다. 그렇다고 엔지니어링 과제가 변하는 것은 아닙니다. 당신이 지켜보고 있지 않을 때도 신뢰할 수 있는 시스템을 구축해야 합니다.
거버넌스, 관측 가능성, 그리고 도구 사용에 집중하세요. 진정으로 중요한 엔지니어는 단순히 프롬프트 엔지니어링을 하는 사람이 아니라, 시스템 설계를 마스터하는 사람이 될 것입니다.
출처: https://dev.to/aibughunter/the-model-is-not-the-product-heres-what-actually-is-52b5