· TongFlow Team · Product  · 읽는 데 약 10분

TongFlow가 자료의 형태에서 출발하는 이유

자료, 기능, 모델의 역할을 나누면 무엇이 달라질까요? 결과를 다음 입력으로 쓰고, 모델을 바꾸면서도 흐름을 유지하며, 목적에 맞는 워크플로를 만들 수 있습니다.

문서 하나가 있습니다. 내용을 추출해 요약하고, 이동 중에 들을 수 있도록 음성으로도 만들고 싶습니다. 파일에서 텍스트로, 다시 음성으로 형태는 바뀌지만 하려는 일은 이어집니다. 같은 정보를 다른 방식으로 쓰려는 것입니다.

TongFlow는 여기서 시작합니다. 지금 어떤 자료가 있고, 무엇을 얻고 싶은지, 그 사이에 어떤 처리가 필요한지부터 생각합니다.

우리는 이 설계를 modality-first라고 부릅니다. 텍스트, 이미지, 음성처럼 정보가 담기는 형태인 모달리티를 중심에 놓습니다. 기능은 이 형태들을 연결하고, 플러그인과 모델은 각 단계의 처리를 맡습니다.

자료, 기능, 모델은 각자 역할이 있습니다

모달리티라는 말은 낯설 수 있지만, 캔버스에서는 구체적인 대상으로 나타납니다. 글 한 단락, 이미지 한 장, 오디오 파일 하나입니다. 각각은 독립된 노드로 놓입니다.

무엇을 연결하느냐에 따라 다음 작업이 달라집니다. 텍스트는 음성 합성이나 이미지 생성에 쓸 수 있습니다. 이미지는 내용을 읽어 내거나, 가공하거나, 영상을 만드는 데 쓸 수 있습니다.

워크플로를 만들 때는 세 가지를 결정합니다.

  • 자료: 이 단계에서 어떤 텍스트, 이미지, 음성을 사용할까?
  • 기능: 추출, 생성, 변환, 결합, 분할 중 어떤 처리를 할까?
  • 구현: 이 기능을 지원하는 어떤 플러그인과 모델로 실행할까?

이렇게 나누면 먼저 ‘이 텍스트를 음성으로 바꾼다’는 단계를 만들고, 그다음 음성 합성에 쓸 구현을 고를 수 있습니다. 모델 선택은 여전히 중요하지만, 처음 고른 모델이 전체 작업의 구조까지 결정할 필요는 없습니다.

결과가 나오면, 거기서 이어 갈 수 있습니다

앞서 말한 문서 작업은 다음과 같이 구성할 수 있습니다.

문서 → 텍스트 추출 → 텍스트
                       ├→ 요약 → 요약문
                       └→ 음성 합성 → 오디오

두 갈래는 같은 추출 결과를 사용하고, 요약문과 오디오를 각각 남깁니다. 나중에 전문 대신 요약문을 읽어 주는 음성이 필요해지면, 음성 합성의 입력을 요약문으로 바꾸면 됩니다.

처리 결과도 다시 쓸 수 있는 자료입니다. 업로드한 이미지와 생성한 이미지 모두 이미지를 받는 다음 작업에 연결할 수 있습니다. 만들어진 음성을 더 가공하거나, 인물 이미지와 결합해 말하는 영상을 만들 수도 있습니다.

처음부터 전체 흐름을 완성해 둘 필요는 없습니다. 한 부분을 만들고 결과를 확인한 뒤, 분기를 추가하거나 다른 결과와 합치면 됩니다. 이미 해 놓은 작업이 다음 시도의 출발점이 됩니다.

콘텐츠도, 일하는 방식도 만들 수 있습니다

이미지와 영상 생성은 이 구조를 쉽게 보여 주는 예입니다. 문서에서 정보 추출하기, 음성 받아쓰기, 내용 파악하기, 자료 정리하기에도 같은 구조를 적용할 수 있습니다.

예를 들어 영상을 여러 클립으로 나누고, 각 클립에서 음성을 추출해 텍스트로 옮길 수 있습니다. 그 텍스트는 다시 정리하거나 다른 생성 단계에 쓸 수 있습니다. 하나의 입력을 여러 출력으로 나누는 작업과 정보의 형태를 바꾸는 작업을 한 워크플로에 담는 것입니다.

TongFlow에서 만드는 것은 이미지나 영상에만 머물지 않습니다. 정보를 처리하는 방법, 반복해서 사용할 작업 절차도 직접 만들 수 있습니다. 워크플로가 어떤 일을 할지는 사용자의 목적에 따라 정해집니다.

추가, 변환, 결합, 분할, 일괄 처리. 각각의 기능을 연결하면 한 단계만으로는 할 수 없던 일을 할 수 있습니다.

모델을 바꿔도, 만들어 둔 흐름은 활용할 수 있습니다

워크플로 중간에 이미지를 생성하는 단계가 있다고 해 보겠습니다. 처음에는 플러그인 A를 쓰다가, 같은 기능을 지원하는 다른 구현을 시험해 보고 싶어졌습니다.

TongFlow는 그 단계가 수행하는 기능과 실행을 맡는 플러그인을 따로 기록합니다. 새 구현이 같은 입출력 규격을 지원한다면, 앞뒤 연결을 유지하면서 해당 단계의 플러그인을 바꿀 수 있습니다. 설정과 인증 정보, 실제 출력 결과는 새 구현에 맞게 확인해야 합니다.

코드에서는 기능별 입출력 정의와 노드 레지스트리가 이 구분을 뒷받침합니다. 무엇을 받고 무엇을 반환하는지 정의하고, 어떤 플러그인으로 실행할지는 워크플로에서 지정합니다. 모델 선택이 달라져도, 목적에 맞게 구성한 작업 흐름은 계속 활용할 수 있습니다.

연결하려면, 입력과 출력이 명확해야 합니다

음성을 받는 작업에는 음성을 전달해야 합니다. 이미지와 목소리를 결합하는 작업이라면 둘 다 필요합니다. 모달리티를 중심에 두는 설계는 이런 연결 규칙을 바탕으로 합니다.

실제로 실행할 수 있는 작업은 제공되는 기능, 설치한 호환 플러그인, 필요한 설정에 따라 달라집니다. 새로운 모달리티나 기능을 추가할 때도 정의와 구현이 필요합니다.

호환되는 기능이 하나 늘어나면 기존 자료를 활용할 방법이 늘어납니다. 이미 있는 작업과 연결할 수도 있습니다. 우리가 modality-first를 중요하게 생각하는 이유가 여기에 있습니다.

사람과 에이전트가 같은 워크플로를 편집합니다

캔버스에서는 흐름을 보면서 작업을 구성할 수 있습니다. 그 구조는 코드로도 다룰 수 있습니다. TongFlow의 캔버스, 연결 검사, 내보내기 기능은 같은 노드 레지스트리를 사용합니다.

DSH 연동에서는 에이전트가 워크플로 파일을 만들고, 사용자가 이를 캔버스에서 열어 확인하고 수정할 수 있습니다. 결과와 함께 그 결과를 만든 과정도 전달되는 셈입니다. 입력이나 기능, 플러그인을 바꾸고 싶다면 해당 단계를 수정하면 됩니다.

서로 다른 형태의 자료를 하나의 워크플로로 연결하고, 그 결과에서 다음 작업을 이어 갑니다. TongFlow는 그렇게 계속 만들어 갈 수 있는 도구가 되고자 합니다.

TongFlow를 열고 가지고 있는 텍스트나 파일로 시작해 보세요. 구현이 궁금하다면 소스 코드, 기능 레지스트리, DSH 연동을 살펴볼 수 있습니다.

Why TongFlow starts with modalities

Materials, capabilities and models have different jobs. Keeping them separate lets you build workflows around your task, reuse their results and change implementations as you go.

TongFlow がモダリティから考える理由

データ、処理、モデル。それぞれの役割を分けると、得られた結果を次に使い、モデルを変えながら、自分の目的に合うワークフローを組み立てられます。