똑같은 혼란 속에서, 이제는 스스로 말할 수 있게 되다
요약
본 글은 AI 엔지니어링 과정에서 에이전트(agentic) 시스템과 RAG 구현을 경험하며 얻은 통찰을 공유합니다. 모델에게 도구 선택 및 사용 능력을 부여하는 '에이전트 도구 오케스트레이션'의 개념부터, 여러 에이전트가 상호작용하는 '다중 에이전트 시스템'의 복잡성까지 다룹니다. 나아가 RAG에서 발생하는 권한(permission) 문제와 모델 간 의존성 변경 시 발생할 수 있는 차이점들을 심도 있게 탐구합니다.
핵심 포인트
- 에이전트 도구 오케스트레이션은 모델에게 도구를 선택하고 인수를 제공하는 능력을 부여하며, 이는 'if' 조건문을 아웃소싱한 것과 같습니다.
- 다중 에이전트 시스템은 여러 에이전트가 역할을 맡고 상호작용하며 의견 차이를 보일 수 있습니다. 이 과정에서 설득력 있는 설명 생성이 가능합니다.
- RAG는 모델에게 검색 기능을 부여하지만, 단순히 의미적 관련성 외에 권한, 최신성 등 추가적인 기준(rubric)이 필요합니다.
- 모델 간 의존성을 변경할 때 발생하는 행동의 차이를 포착하고 검증하는 것이 중요한 연구 주제가 됩니다.
저는 AI 엔지니어링 과정을 들으면서 자신이 바보라고 느끼고 싶었습니다. 발밑이 무너지는 느낌, 제 예전 본능으로는 도달할 수 없는 문제에 직면했을 때의 기분 좋은 충격을 원했죠. 첫 번째 과정은 'Scope AI Solutions'이라는 이름이었습니다. 저는 어떤 부분이 새로운지 아직 파악하려 애쓰고 있었는데, 에이전트(agentic) 실험실에서 API 키를 요청했습니다. 프로젝트에는 크레딧이 없었기에 제가 일부를 추가했습니다. 지정된 모델은 곧바로 일일 50회 요청 한도에 도달했고, 나머지 작업은 다른 모델을 사용해야 했습니다. 저는 오후 시간을 생소한 시스템 내부에서 보내리라 예상했지만, 대신 공급업체 계정을 문제 해결하는 작업을 하게 되었고, 이것이 제가 소프트웨어 엔지니어링의 세계로 돌아왔음을 알게 해주었습니다.
그 작업에 훨씬 더 나은 이름이 붙여졌습니다: '에이전트 도구 오케스트레이션(agentic tool orchestration)'. 모델이 도구를 선택하고, 인수를 제공하며, 결과를 읽고, 어쩌면 또 다른 것을 선택합니다. 모델에게 그 선택을 하게 하는 것은 정말 새로운 일입니다. 우리는 if 조건문을 아웃소싱한 셈이죠. 저는 여전히 그것이 무엇을 호출할 수 있는지, 어떤 인수를 전달할 수 있는지, 얼마나 오래 기다릴지, 그리고 중간에 멈췄을 때 무엇을 기록해야 할지를 결정해야 합니다. 모델은 흥미로운 연구 문제가 됩니다. 반면에 else는 잠옷 차림으로 새벽 2시에 있는 저 자신이며, 왜 소파를 환불했는지 설명하려 애쓰고 있습니다.
이 워크플로우에 또 다른 모델을 추가하면 '다중 에이전트 시스템(multi-agent system)'이 됩니다. 이제 이 시스템에는 동료들, 역할, 그리고 인계 과정이 생깁니다. 두 구성 요소는 누가 이메일을 보냈는지에 대해 의견이 다를 수 있으며, 이는 이전에도 가능했던 일입니다. 개선된 점은 각각 상대방이 왜 그것을 보냈는지 설득력 있는 설명을 작성할 수 있다는 것입니다. 만약 그들이 서로를 인용한다면, 매우 자신감 넘치는 사고 보고서의 시작점이 될 뿐이고 여전히 이메일은 없습니다. 하지만 그들은
모델을 변경하는 것이 제한(cap) 때문에 발생한 문제였지만, 이는 제가 더 많은 시간을 할애하고 싶었던 질문을 제기했습니다. 대체 모델은 다른 도구를 선택하거나 동일한 프롬프트에 대해 다른 답변을 줄 수도 있습니다. 시스템의 나머지 부분은 여전히 유효한 응답을 받게 될 것입니다. 컴파일러는 불평하지 않을 것입니다. 저는 시스템 평가 중간에 의존성을 변경했는데, 이 의존성이 결정을 내리는 부분이었습니다. 인간 팀에서는 결정권자를 교체하는 것이 적어도 인수인계를 요구할 것입니다. 여기서는 그것이 매개변수였습니다. 한 모델은 환불을 발행하기 전에 물어볼 수도 있습니다. 다른 모델은 두 번 발행하고 멋진 사과문까지 쓸 수도 있습니다. 무엇이 동등한 행동으로 간주될까요? 어떤 검사가 그 차이를 포착할 수 있을까요? 저는 이 문제에 대해 더 오래 생각하고 싶었고, 그것을 우회하는 또 다른 이름은 원하지 않았습니다.
그런 다음 검색(retrieval) 연습은 저를 권한(permissions) 문제로 되돌아오게 했습니다. 검색 증강 생성(Retrieval-augmented generation, RAG)은 모델에게 연구 조교: 즉, 검색 기능을 부여합니다. 이전에는 세 개의 링크를 건네주고 제가 스스로 잘못된 결정을 내리도록 두었습니다. 만약 그것이 오래된 구절, 정확한 구절, 그리고 다른 사람의 세금 보고서를 찾아낸다고 상상해 보세요. 모델은 이 세 가지 모두를 바탕으로 하나의 멋진 단락을 작성합니다. 인덱스는 이것들을 의미적으로 관련성이 높다고 판단하며 완전히 맞습니다. 하지만 개인정보 보호팀은 다른 기준(rubric)을 가지고 있습니다. 관련성이 권한, 최신성, 또는 진실성을 의미하지는 않습니다. 검색 기능에 이제 입이 생겼기 때문에, 우리의 환상적인 현재에는 권한 버그가 일어나서 방 전체에 자신이 무엇을 찾았는지 말할 수 있게 되었습니다.
RAG 연구소에서는 11개 중 8개의 검사가 통과했고 평가 오류는 없다고 돌아왔습니다. 8개가 통과하고, 3개가 실패했으며, 평가자 자체도 작동했습니다. 저는 그 구분을 높이 평가했습니다. 모델의 답변은 회의를 주재한 것처럼 들리면서 틀릴 수 있으며, 이를 포착하기 위해서는 예시와 기준이 필요합니다. 테스트가 실제로 일을 하고 있었습니다. 다만 우리가 그것들이 테스트라는 사실을 인정할 수 있다면 좋을 텐데 말입니다. 제 오래된 테스트가 실패했을 때는 FAIL이라고 말하고 저에게 논쟁하도록 내버려 두었습니다. 이제 모델은 반박하며 토큰 단위로 비용을 청구합니다.
나는 'Agentic Observability: 누가 데모 후의 혼란을 소유할 것인가?'라는 고급 경로를 계속 찾아보았다. 나는 그 과정을 두 번이나 거쳤을 것이다. 그 최종 실습은 아무도 승인하지 않은 환불, 중요한 부분이 누락된 추적 기록, 그리고 녹색 대시보드를 가리키는 세 부서의 책임을 나에게 전가했을 것이다. 완수를 하면 목걸이 끈(lanyard)을 얻게 될 것이고, 그 목걸이 끈은 로그에 접근할 수 있게 해줄 터인데, 나는 그렇지 못했다.
나는 다섯 개의 배지(badge)가 붙은 채로 채용 공고를 다시 살펴보았다. 걱정해야 할 새로운 실패 모드들은 생겼지만, 새로운 엔지니어링 본능은 없었다. 한 곳에서는 'LLM 통합 및 에이전트 오케스트레이션' 경험을 원했다. 나는 정확히 그와 정반대의 역할을 하는 else였던 한 주를 보냈다. 알고 보니 여전히 똑같은 오래된 혼란일 뿐인데, 단지 옷만 깔끔하게 입고 이제는 말을 할 수 있게 되었을 뿐이었다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기