Kaeso 재정의

발행: (2026년 3월 9일 AM 02:15 GMT+9)
5 분 소요
원문: Dev.to

Source: Dev.to

Introduction

Kaeso는 잘못 정의된 것이 아니다. 때때로 제품이 바뀌는 이유는 아이디어가 틀렸기 때문이 아니라, 문제 해결 영역에서 일하다 보면 자연스럽게 바꾸고 싶은 것들이 더 많이 발견되기 때문이다. 아직 시작도 하지 않았으니, 비용이 크게 들지 않는 한 방향을 바꾸는 것이 합리적이다.

Motivation

시작할 때 나는 구체적인 목표를 잡고 있지는 않았다. 오히려 이 프로젝트를 진행하고 AI와 관련된 환경에 들어가게 할 동기, 즉 결속력 있는 이유가 필요했다.

시장이 무엇을 원하는지는 이미 알고 있었다. 현재 AI와 관련된 거의 모든 발명은 하나의 큰 주제, AI 에이전트를 중심으로 이루어진다. 통신 회사의 지원 에이전트이든, 코딩 에이전트이든, 혹은 다른 어떤 형태이든 모두가 에이전트를 생각하고 있다.

The Idea

나는 대기업이 만든 다양한 모델을 활용해 워크플로우와 여러 도구·통합을 실행할 수 있는 플랫폼을 만들면서 이 아이디어를 중앙화하고자 했다. 에이전트에게는 데이터가 필요하다는 것도 이미 알고 있었다. 건설 노동자는 당신이 제공한 설계도 없이는 원하는 일을 할 수 없고, 변호사는 사건을 알지 못하면 당신을 대변할 수 없다.

이 플랫폼을 만들면서 깨달은 점은, 에이전트가 사용해야 할 작은 연결 하나하나를 위해 도구를 만드는 것이 매우 번거롭다는 것이다. 에이전트는 데이터와만 작업하며, 많은 개발자·디자이너·크리에이터가 따르는 설계 원칙이 있다: “사용자는 어리석다.” 에이전트는 바보도 못 쓰게 설계돼야 한다.

The Core Question

사용자가 매번 직접 데이터를 제공하지 않아도 에이전트가 데이터를 얻으려면 어떻게 해야 할까?

Solution

해답은 간단하다: 에이전트가 스스로 할 수 있어야 한다. 이것이 사용자가 기대하는 바이며, OpenClaw (ClawdBot) 같은 프로젝트가 인기를 끈 이유이기도 하다. 에이전트를 커넥터에 연결하면 에이전트가 필요한 데이터를 스스로 가져온다.

평균적인 사람은 게으르다. 대부분은 에이전트가 데이터를 접근하도록 단일 게이트웨이조차 설정하고 싶어 하지 않는다. 여러 서비스를 동시에 연결하려면 각각 로그인, 이메일, 비밀번호, 2단계 인증 등이 필요하고, 사람들은 복잡성을 무시하면서도 프라이버시를 기대한다.

Kaeso’s Approach

Kaeso는 통합 API 게이트웨이를 만들어 문제를 해결한다. 에이전트는 한 번만 연결하면 되고, 잘 문서화되고 구조화된 API를 통해 권한을 한 번 정의하면 어떤 API 키가 어떤 서비스에 접근할 수 있는지 제어할 수 있다. 또한 서비스당 여러 계정을 허용해 에이전트가 스스로는 접근하기 어려운 훨씬 많은 데이터를 활용할 수 있게 만든다.

Kaeso v1

그래서 이것이 Kaeso v1이다.

  • 커넥터 연결 중단
  • 원래는 kaeso.ai에 공개됨
0 조회
Back to Blog

관련 글

더 보기 »