Agent가 스스로 만든 Tool은 캔버스 노드가 아니었습니다

편집자 노트 · B2B 고객 관점

“완료됐다고 하는데, 결과는 어디서 확인하죠?” 업무에 AI를 도입한 고객이라면 한 번쯤 마주할 수 있는 질문입니다. Agent가 필요한 도구를 스스로 만들더라도, 담당자가 무엇이 만들어졌는지 확인하고 다음 업무에서 다시 찾아 쓸 수 없다면 그 능력은 실제 업무의 편의로 이어지기 어렵습니다.

이 글은 도구를 만드는 기능 자체보다, 그 결과를 사용자가 알아보고 활용할 수 있게 만드는 과정을 다룹니다. 고객의 입장에서 “개발자에게 다시 묻지 않고도 결과를 확인하고 다음 행동을 할 수 있는가?”를 떠올리며 읽어보시면, 작은 화면 개선이 업무의 연속성과 신뢰에 어떤 의미를 갖는지 공감하실 수 있을 것입니다.

XGEN Agentic AI Platform의 Geny Agent는 대화 중에 필요한 Tool을 직접 만들지만, 채팅에는 "완료" 표시가 잠깐 지나갈 뿐이라 사용자는 새 Tool이 생겼다는 사실도, 그것이 어디 있는지도 알기 어려웠습니다. 이 문제를 사흘 동안 고치면서 저희가 세운 전제는 세 번 뒤집혔습니다. 만든 Tool은 캔버스에 있지 않았고, 채팅 화면은 하나가 아니었고, 화면이 런타임을 짐작해서는 안 됐습니다.

Agent가 자라는데 사용자는 그걸 볼 수 없었습니다

Geny Agent는 일하다가 필요한 능력이 없으면 스스로 늘립니다. 자기 워크플로 그래프에 노드를 붙이기도 하고, 파이썬 스크립트를 짜서 새 Tool로 등록하기도 합니다. Geny를 소개한 지난 글에서 "필요한 Tool이 없다면 직접 만들 수 있다"고 적은 바로 그 기능입니다.

그런데 실제 채팅 화면에서 이 순간은 거의 드러나지 않았습니다. Tool이 만들어져도 도구 실행이 끝났다는 작은 칩이 잠깐 지나갈 뿐이었습니다. 사용자는 방금 무엇이 생겼는지, 그것을 어디서 다시 볼 수 있는지 알 방법이 없었습니다.

스스로 자라는 Agent에서 이것은 작은 불편이 아닙니다. Agent가 무엇을 바꿨는지 보이지 않으면, 사용자는 그 Agent를 믿고 맡기기 어렵습니다. 9월 9일, 채팅에서 만든 Tool을 보여 주는 작업을 시작했습니다.

처음 떠올린 답은 캔버스였습니다

XGEN Canvas에서는 Agent에 연결된 도구가 노드로 보입니다. 그래서 처음에는 채팅의 링크가 캔버스의 해당 노드로 가면 된다고 생각했습니다.

코드를 따라가 보니 그 전제가 틀렸습니다. 캔버스에 노드로 붙는 것은 Agent가 자기 그래프를 편집해서 추가한 노드뿐이었습니다. 대화 중에 만든 Tool은 서버에 스펙으로 저장되고, 스크립트는 Agent의 Workspace에 놓입니다. 화면에서 그 Tool이 보이는 곳은 Agent 상세 화면의 [도구] 탭 하나였습니다.

링크 대상을 캔버스에서 [도구] 탭으로 바꿨는데, 이번에는 그 탭에 주소가 없었습니다. 상세 화면은 목록에서 카드를 눌러야만 열리고, 항상 기본정보 탭으로 시작했습니다. 그래서 "이 Agent의 상세를 [도구] 탭으로 열어라"는 주소를 새로 만들었습니다.

주소 하나를 여는 데도 함정이 세 개 있었습니다. 주소를 화면이 그릴 때마다 반영하면 뒤로가기를 눌러도 다시 상세로 튕깁니다. 목록은 24개씩 나뉘어 있어서 그 Agent가 지금 페이지에 없을 수 있습니다. 뒤로가기 뒤에 주소가 남아 있으면 새로고침할 때 다시 상세로 들어갑니다. 화면에 들어올 때 한 번만 읽고, 목록에 없으면 따로 찾아오고, 나올 때 주소를 지우는 것으로 셋을 막았습니다.

채팅에는 Tool을 만든 답변 아래에 "이 대화에서 만든 도구" 카드가 남게 했습니다. 이때 정한 원칙은 하나였습니다. 카드는 Tool이 실제로 만들어졌을 때만 나옵니다. 만드는 중이거나 검증에 실패했거나 이름을 알 수 없으면 그리지 않습니다. 없는 Tool로 가는 링크가 가장 나쁜 경험이라고 봤기 때문입니다.

채팅 화면이 두 개였습니다

첫 작업을 리뷰받던 9월 10일에 더 큰 문제가 보였습니다. XGEN에는 Agent와 대화하는 화면이 두 개 있었습니다. 보관함에서 [실행]을 눌러 들어가는 채팅과, Agent를 새로 만든 직후 이어지는 채팅입니다.

두 화면은 겉모습이 비슷했지만 코드가 완전히 따로였습니다. 그래서 파일 첨부, 도구 실행 칩, 전체 로그 보기가 한쪽에만 있었습니다. 만든 Tool 카드도 한쪽에 넣으면 다른 쪽에는 없는 상태가 됩니다. 화면이 둘이면 기능도 계속 둘로 갈린다는 것을 그때 분명히 알았습니다.

그래서 새로 만든 직후의 채팅 화면을 없앴습니다. Agent 만들기 양식이 끝나면, 보관함에서 [실행]을 누른 것과 똑같은 방식으로 기존 채팅 화면으로 넘어가게 했습니다. 넘어갈 때 넘겨주는 값은 Agent id와 이름 등 몇 칸인데, 한 칸이라도 빠지면 채팅이 "진행 중인 채팅이 없습니다"로 떨어집니다. 그래서 그 모양을 작은 함수 하나로 고정하고 테스트로 못박았습니다.

없앤 화면의 오른쪽 패널에 있던 유용한 것들은 기존 채팅으로 옮겼습니다. Agent 이름과 캔버스 바로가기, 이번 대화에서 스스로 구조를 바꾼 횟수, 지침, 그리고 이 Agent가 쓸 수 있는 Tool입니다. 패널은 대화가 한 번 오갈 때마다, 그리고 Agent가 자기 그래프를 바꿀 때마다 다시 읽습니다. 방금 붙인 능력이 패널에 바로 안 보이면 "스스로 자란다"가 보이지 않기 때문입니다.

화면이 런타임을 짐작하고 있었습니다

두 작업을 하나로 묶어 올리자, 화면이 쓰는 방식이 Agent 런타임의 정식 방식과 어긋난다는 리뷰가 돌아왔습니다. Geny의 런타임과, 데스크톱 앱과 CLI와 VS Code 확장이 함께 쓰는 이벤트 약속은 공개 저장소에 있습니다. 받아서 읽어 보니 어긋난 곳이 세 군데였습니다.

세 가지 모두 화면이 "아마 이렇겠지" 하고 짐작한 자리였습니다. 짐작은 당장은 맞게 돌아갑니다. 하지만 런타임이 입력 모양을 조금만 바꿔도 화면은 오류 없이 조용히 틀린 숫자를 보여 주게 됩니다. 그래서 세 곳 모두 런타임이 공식적으로 알려 주는 값을 받아 그리는 쪽으로 바꿨습니다. Tool 목록도 캔버스에 노드가 하나도 없는 Agent까지 제대로 보이게 됐습니다. 패널의 이 묶음은 며칠 뒤 한 번 더 다듬어져, 지금은 Agent가 직접 만든 Tool과 자가 진화로 붙인 것을 따로 보여 줍니다.

이 부분에서 판단이 가장 크게 바뀌었습니다. 처음에는 "화면에 무엇을 보여 줄까"를 먼저 생각했는데, 이제는 "런타임은 이것을 어떻게 알려 주는가"를 먼저 찾아봅니다. 같은 이벤트를 데스크톱 앱과 CLI도 받기 때문에, 웹 화면만 다른 기준으로 세면 같은 Agent가 화면마다 다른 숫자를 말하게 됩니다.

넘어진 자리와 배운 점

9월 11일에 반영하고 9월 15일에 개발 서버에서 전부 확인했는데, 한 번에 되지는 않았습니다. 처음 배포에서는 만든 Tool 카드와 칩이 붙지 않았습니다. Geny의 Tool 이벤트 중에 실행 id가 빠진 경우가 있었는데, 화면이 그 id로 이벤트를 답변에 짝지우고 있었던 것입니다. 도구 이벤트를 실행 id와 상관없이 답변별로 모으도록 화면을 한 번 더 고치고 나서야 카드가 제자리에 나왔습니다. 코드 검사와 단위 테스트는 모두 통과한 상태였고, 개발 서버에서 실제 Agent와 대화해 보고서야 드러난 문제였습니다.

자동 검사에서도 두 번 걸렸습니다. XGEN 프런트엔드는 화면에 새로 생긴 요소와 문구를 계약 파일에 등록해야 통과하는데, 검사기가 코드 주석 속 따옴표 한글까지 화면 문구로 읽었습니다. 귀찮은 규칙처럼 보였지만, 화면 요소가 계약 한 곳에 모여 있어서 없앤 화면의 요소 8개와 사용 시나리오도 거기서 빠짐없이 함께 정리할 수 있었습니다.

돌아보면 배운 것은 세 가지입니다.

첫째, 스스로 자라는 Agent일수록 자란 흔적을 사용자 눈앞에 남겨야 합니다. 능력이 늘어나는 것보다, 늘어난 것을 사용자가 확인할 수 있는 것이 신뢰를 만듭니다.

둘째, 같은 일을 하는 화면이 둘이면 기능은 계속 둘로 갈립니다. 새 기능을 한쪽에 붙이기 전에 화면을 하나로 합치는 것이 결국 빨랐습니다.

셋째, 화면은 런타임을 짐작하지 말고 런타임이 정식으로 알려 주는 것을 받아야 합니다. 짐작한 코드는 틀려도 오류를 내지 않아서 더 늦게 발견됩니다.

스스로 Tool을 만드는 Agent를 제품에 넣으려는 팀이라면, Agent의 능력만큼 "그 능력이 생긴 순간을 사용자가 어떻게 보게 할지"도 함께 설계해 보시길 권합니다. 저희도 이번에 그 순서를 거꾸로 밟으며 배웠습니다.

편집자 의견 · 도입 판단과 운영 합의

고객이 확인하고 싶은 것은 “도구 생성 기능이 있다”는 설명을 넘어, 실제 업무 요청이 쓸 수 있는 결과로 이어지는 경험입니다. PoC에서는 고객의 업무 사례로 ‘도구 생성 요청 → 성공·실패 확인 → 결과 열람 → 다시 찾아 활용’까지 이어서 검증해 보면 좋겠습니다. 다른 화면으로 들어가도 같은 결과를 찾을 수 있는지, 실패한 작업이 완료된 것처럼 보이지 않는지도 함께 확인할 필요가 있습니다.

다만 결과가 잘 보인다는 것과 생성된 도구를 안심하고 실행할 수 있다는 것은 별개의 문제입니다. 생성된 코드와 도구를 누가 검증하고, 누가 사용할 수 있으며, 변경이나 문제 발생 시 누가 관리할지는 고객 환경에 맞게 별도로 합의해야 합니다. 이 글의 개선이 그 모든 운영 요건을 충족했다는 뜻은 아닙니다. 고객에게 의미 있는 출발점은, 담당자가 “무엇이 만들어졌고 어디서 확인할 수 있는지”를 이해하고 다음 업무를 이어갈 수 있도록 만드는 데 있습니다.