당신의 첫 AI 에이전트: 최소한으로, 솔직하게 만들기

"AI 에이전트"는 설명하는 것보다 더 많은 것을 약속하는 단어가 되어버렸습니다. 마케팅을 걷어내면 에이전트는 상당히 구체적이고 상당히 만들 만한 것입니다. 루프에 놓인 언어 모델이, 호출할 수 있는 도구 집합을 받아, 스스로 끝났다고 판단할 때까지 목표를 향해 작동하는 것이죠. 그게 아이디어의 전부입니다. 이 글은 그 아이디어의 가장 작은 솔직한 버전을 만들고, 각 조각이 왜 거기 있는지 설명하며, 더 유용하게는 어디서 깨지는지 보여줍니다. 그래서 당신의 첫 에이전트가 복사해 놓고 작동하길 바라는 것이 아니라 실제로 이해하는 것이 되도록 말이죠.

에이전트란 정말 무엇인가

평범한 언어 모델은 한 가지 일을 합니다. 텍스트를 보내면 텍스트를 돌려보내고, 그 주고받음으로 끝납니다. 무언가를 조회하거나, 계산을 실행하거나, 세상에서 행동을 취할 수 없습니다. 에이전트는 그 토대에 세 가지를 더합니다. 모델이 사용하도록 허락된 도구, 한 번 이상 행동하게 해주는 루프, 그리고 도달하려는 목표입니다.

핵심적인 변화는 모델이 더 이상 텍스트 생성기에만 머물지 않고 의사결정자가 된다는 점입니다. 매 턴마다 모델은 선택합니다. 답하기에 충분한가, 아니면 먼저 도구를 호출해야 하는가? 도구를 호출하면 결과를 받고, 다시 고려하고, 다시 선택합니다. 그 순환, 즉 생각하고, 행동하고, 관찰하고, 반복하는 것이 메커니즘의 전부입니다. 더 화려한 모든 것은 이 루프의 변주입니다.

세 가지 재료

도구는 모델에게 노출하는 함수입니다. 웹 검색, 데이터베이스 조회, 산술 계산, 이메일 전송 같은 것이죠. 모델에게 도구란 이름 하나, 무엇을 하는지에 대한 설명, 그리고 어떤 입력을 기대하는지에 대한 설명입니다. 모델은 결코 당신의 코드를 직접 실행하지 않습니다. 호출을 요청하면 당신의 프로그램이 함수를 실행하고, 당신이 결과를 돌려주는 것이죠. 그 경계가 중요하며, 우리는 여기로 다시 돌아올 것입니다.

루프는 에이전트를 단일 도구 호출과 구분 짓는 것입니다. 도구가 결과를 반환한 뒤, 모델은 그 결과를 보고 다음에 무엇을 할지 결정합니다. 또 다른 도구를 호출할 수도, 답할 수도 있죠. 루프가 없으면 도구를 한 번 쓸 수 있는 모델이지만, 루프가 있으면 단계를 엮을 수 있는 모델이 됩니다.

목표는 당신이 주는 과제에, 어떻게 행동할지에 대한 지시사항을 더한 것입니다. 무엇을 위한 것인지, 어떤 도구를 우선할지, 언제 멈출지 같은 것이죠. 명확한 목표가 답으로 수렴하는 에이전트와 헤매는 에이전트의 차이를 만듭니다.

도구 설계하기

에이전트의 품질은 대체로 그 도구가 결정하며, 도구 설계는 초보자가 투자를 가장 적게 하는 곳입니다. 모델은 설명만으로 그 도구가 무엇을 하는지, 언제 손을 뻗어야 하는지 이해할 때에만 도구를 잘 쓸 수 있습니다. 각 도구 설명을 유능하지만 곧이곧대로 받아들이는 독자를 위해 쓴 작은 문서처럼 다루세요.

입력과 출력에 대해 구체적으로 쓰세요. 설명이 "검색합니다"라고만 적힌 search 도구는 그것이 웹을 검색하는지, 당신의 파일을, 아니면 제품 카탈로그를 검색하는지 모델에게 아무것도 알려주지 않습니다. 풀어서 적으세요. 무엇을 검색하는지, 쿼리가 어떻게 생겨야 하는지, 무엇이 돌아오는지. 실패 경우도 명명하세요. 아무것도 찾지 못했을 때 도구가 무엇을 반환하는지 말이죠. 그래야 모델이 결과를 지어내는 대신 분별 있게 반응합니다. 모호한 도구는 엉뚱한 때에 엉뚱한 것을 호출한 뒤 그 혼란 위에서 즉흥적으로 둘러대는 에이전트를 만듭니다.

좋은 규율은 도구를 적게, 그리고 뚜렷이 구별되게 유지하는 것입니다. 명확히 다른 일을 하는 세 개의 도구가 겹치는 열 개보다 모델이 고르기에 더 쉽습니다. 에이전트가 도구 없이 고생하는 것을 지켜본 뒤 언제든 더 추가할 수 있습니다.

루프, 한 단계씩

여기 최소한의 루프를 의사코드로 적었습니다. 천천히 읽을 가치가 있습니다. 다른 모든 것은 이 위의 장식이기 때문입니다:

messages = [system_instructions, user_goal]
loop:
    response = model(messages, tools)
    if response asks to call a tool:
        result = run_the_tool(response.tool, response.inputs)
        append the model's request and the result to messages
        continue          # back to the model with new information
    else:
        return response   # the model is done; answer the user

무슨 일이 일어나는지 읽어보세요. 당신은 대화에 사용 가능한 도구를 더해 보냅니다. 모델은 도구를 요청하거나 최종 답을 줍니다. 도구를 요청하면 당신이 그것을 실행하고, 요청과 결과를 둘 다 진행 중인 대화에 덧붙인 뒤, 모델을 다시 호출합니다. 이제 조금 전보다 더 많은 정보를 가지고서요. 모델은 답하기에 충분해질 때까지 계속 정보를 얻습니다. 루프는 마법이 아닙니다. 그저 "모델이 요청한 것을 주고 다시 물어본다"일 뿐입니다.

건너뛸 수 없는 가드레일

위의 루프에는 모든 실제 에이전트가 반드시 막아야 할 구멍이 있습니다. 영원히 도는 것을 막는 것이 아무것도 없다는 점이죠. 모델은 같은 도구를 반복 호출하며 막힐 수도, 영영 도달하지 못할 목표를 쫓을 수도 있습니다. 그래서 천장, 즉 최대 단계 수를 두어, 그 이후에는 불완전하더라도 에이전트가 멈추고 가진 것을 보고하게 합니다. "허락된 단계 안에 끝내지 못했다"고 인정하는 에이전트가 무한히 돌거나, 더 나쁘게는 한도 없는 비용을 쌓는 에이전트보다 훨씬 안전합니다.

두 번째 가드레일은 결정과 실행 사이의 그 경계에 관한 것입니다. 모델은 도구를 호출하기로 결정하지만, 그것을 실행하는 건 당신의 코드입니다. 그리고 모델은 틀릴 수도, 조종당할 수도, 그저 혼란스러울 수도 있습니다. 어떤 도구가 되돌릴 수 없는 일(데이터 삭제, 돈 지출, 실제 사람에게 메시지 전송)을 할 수 있다면, 첫 빌드에서는 루프가 감독 없이 그것을 작동시키게 두지 마세요. 초기 도구는 읽기 전용으로 유지하거나, 결과가 따르는 어떤 행동에든 사람의 확인을 요구하세요. 모델은 주도성을 가진 신입 동료입니다. 유용하고, 가끔 실수하며, 당신이 되돌릴 수 없는 것의 열쇠를 아직 넘겨받을 수는 없는 존재죠.

첫 에이전트가 잘못되는 곳

몇몇 실패는 너무 신뢰성 있게 나타나서 미리 명명할 가치가 있습니다. 첫 번째는 도구 혼동입니다. 모델이 엉뚱한 도구를 고르거나 잘못된 형식의 입력을 주는 것인데, 거의 항상 도구 설명이 모호했기 때문입니다. 모델을 탓하기 전에 설명을 고치세요. 두 번째는 루핑입니다. 도구가 도움 안 되는 무언가를 계속 반환하고 모델이 같은 해결책을 계속 시도하면서 에이전트가 한 단계를 반복하는 것이죠. 당신의 단계 천장이 이를 잡고, 기록을 읽으면 왜 일어났는지 알려줍니다. 세 번째는 실패한 도구 호출 이후의 과신입니다. 검색이 아무것도 반환하지 않았는데 모델이 무언가를 찾은 것처럼 답을 이어가는 것이죠. 치료법은 어디서나 통하는 바로 그것입니다. 도구가 비어서 돌아왔을 때 무엇을 할지 모델에게 명시적으로 말하는 것이죠.

이 셋을 잇는 실은, 에이전트를 디버깅하려면 그 추적(trace)을 읽어야 한다는 것입니다. 생각, 도구 호출, 결과의 연속은 에이전트 추론의 기록입니다. 무언가 잘못되면 답은 거의 항상 그 로그 안에 앉아 있으며, 들여다볼 수 없는 에이전트는 개선할 수 없는 에이전트입니다.

정리

에이전트란 목표를 향해 겨눠진, 도구와 함께 루프에 놓인 모델입니다. 그 최소 버전을 먼저 만드세요. 뚜렷이 설명된 몇 개의 도구, 결과를 모델에게 되먹이는 루프, 단계에 대한 단단한 천장, 그리고 되돌릴 수 없는 어떤 것 전에 사람의 확인. 추적을 읽으며 작동을 지켜보면 도구를 혼동하거나 제자리를 도는 곳이 정확히 보입니다. 화려한 멀티 에이전트 시스템도 같은 루프를 규모만 키운 것입니다. 작고 솔직한 버전을 완전히 이해하면, 나머지는 미스터리가 아니라 부연 설명입니다.