Cometflow Do 구축하기: 자연어 요청을 실용적인 유틸리티로 변환하는 방법

저는 Cometflow Do라는 프로젝트를 진행해 왔는데, 이 프로젝트는 간단한 아이디어에서 출발했습니다. 바로 일상 언어를 사용하여 유용한 유틸리티에 쉽게 접근할 수 있도록 하는 것입니다.

때로는 웹사이트를 열고, 도구를 검색하고, 여러 메뉴를 탐색한 다음, 그것을 어떻게 사용하는지 알아내야 할 때가 있습니다. 단지 작업을 설명하기만 하면 됩니다.

예를 들어:

• "이 이미지들을 PDF로 변환해 줘."
• "Lorem Ipsum 500단어를 생성해 줘."
• "이 JSON 데이터를 CSV로 변환해 줘."
• "백분율을 계산해 줘."
• "이 텍스트를 정리해 줘."

만약 단일 명령어 인터페이스가 이러한 요청들을 적절한 유틸리티로 라우팅할 수 있다면 어떨까요?

이것이 바로 Cometflow Do의 아이디어입니다.

아이디어: 하나의 인터페이스, 여러 유틸리티

저는 또 다른 범용 챗봇을 만드는 대신, Cometflow Do가 특정하고 지원되는 작업 실행에 초점을 맞추기를 원합니다.

예상되는 워크플로우는 간단합니다:

1. 사용자가 작업을 설명합니다.
2. 애플리케이션이 관련 유틸리티를 식별합니다.
3. 필요한 정보가 누락된 경우, 해당 정보를 요청합니다.
4. 유틸리티가 입력을 처리합니다.
5. 사용자는 결과를 받습니다.

지원되는 작업을 위해, 모든 요청에 대해 AI API를 요구하기보다는 가능한 한 결정론적인 로컬 처리를 사용하는 것을 목표로 합니다.

예를 들어, 텍스트를 대문자로 변환하는 것은 AI 모델을 필요로 하지 않습니다. 백분율 계산이나 Base64로 문자열을 인코딩하는 것도 마찬가지입니다.

이러한 작업을 결정론적으로 유지하면 예측 가능성이 높아지고, 테스트하기 쉬워지며, 심지어 인터넷 연결 없이도 사용할 수 있게 될 잠재력이 있습니다.

제가 이 접근 방식에 관심을 갖는 이유

이미 유용한 유틸리티가 많이 존재하지만, 그 사이를 전환하는 과정은 작업 흐름을 방해할 수 있습니다.

명령어 기반 인터페이스(command-based interface)는 일반적인 작업을 더 쉽게 발견하고 접근할 수 있게 합니다. 이 인터페이스는 자연어 명령을 받아들이지만, 그 밑단의 도구들은 여전히 집중적이고 예측 가능하게 유지됩니다.

여기에는 중요한 구분이 있습니다. 명령어를 이해하는 것이 모든 가능한 요청을 지원한다는 것과 같지 않다는 것입니다.

만약 사용자가 지원되지 않는 작업을 요청하면, 애플리케이션은 그 제한 사항을 설명해야 하며 임무를 완료하는 척해서는 안 됩니다.

애플리케이션 구축하기

Cometflow Do는 Kotlin과 Jetpack Compose를 사용하여 네이티브 Android 애플리케이션으로 개발되고 있습니다.

기존 프로젝트 구조에는 다음 구성 요소들이 포함되어 있습니다:

• 명령어 및 의도 라우팅(Command and intent routing)
• 유틸리티 실행(Utility execution)
• 대화 기록(Conversation history)
• 로컬 데이터 영속성(Local data persistence)
• 첨부 파일 및 음성 입력(Attachments and speech input)
• 애플리케이션 설정(Application settings)

현재 코드베이스에는 이미지-to-PDF 변환, Lorem Ipsum 생성, 이미지 압축, JSON/CSV 변환, 텍스트 분석, 단위 변환을 포함한 초기 유틸리티 구현도 포함되어 있습니다.

다음 과제는 코드베이스를 유지보수 불가능한 특수 사례들의 집합체로 만들지 않으면서 유틸리티 컬렉션을 확장하는 것입니다.

엔지니어링 과제: 도구 개수보다 신뢰성(reliability over tool count)

애플리케이션이 얼마나 많은 유틸리티를 포함하고 있는지 세는 것으로 진행 상황을 측정하기 쉽습니다. 하지만 긴 버튼 목록이 반드시 유용한 제품을 만든다고 할 수는 없습니다.

각 유틸리티는 명확하게 정의된 입력, 예측 가능한 출력, 오류 처리(error handling), 그리고 테스트가 필요합니다.

예를 들어, JSON-to-CSV 변환기는 잘못된 형식의 JSON을 적절하게 처리해야 합니다. 이미지-to-PDF 유틸리티는 유효하지 않은 파일과 변환 실패에 대비해야 합니다. 비밀번호 생성기는 일반적인 의사 난수 값(pseudo-random values) 대신 암호학적으로 안전한 난수 생성기(cryptographically secure random-number generator)를 사용해야 합니다.

저는 관리 가능한 배치 단위로 유틸리티를 구축하고, 더 확장하기 전에 그 동작을 검증하고자 합니다.

경험의 단순성 유지

인터페이스는 중앙 명령 컴포저(command composer)를 중심으로 설계되었으며, 대화 기록과 지원 탐색 기능은 필요할 때 사용할 수 있습니다.

목표는 중요한 컨트롤을 숨기지 않으면서 불필요한 단계를 줄이는 것입니다. 단순한 인터페이스는 그 뒤에 있는 액션(actions)들이 신뢰성 있게 작동할 때만 유용합니다.

또한 필수적인 작업이 구독이나 의무적인 AI 키에 의존하지 않도록 기본 유틸리티를 유료 API 사용과 독립적으로 유지하는 방법을 탐구하고 있습니다.

다음 단계는 무엇일까요?

다음 단계에는 유틸리티 레지스트리(utility registry) 확장, 인텐트 라우팅(intent routing) 개선, 엣지 케이스 테스트(edge-case tests) 추가, 그리고 안드로이드 빌드(Android build) 검증이 포함됩니다.

장기적으로는 Cometflow Do가 하나의 일관된 인터페이스를 통해 접근할 수 있는 실용적인 작업 지향 유틸리티(task-oriented utilities) 모음이 되기를 바랍니다.

우선순위는 수백 개의 작업에 대한 지원을 준비되기 전에 선언하는 것이 아닙니다. 먼저 각 지원되는 작업이 진정으로 유용하도록 만드는 것입니다.

다른 개발자분들의 의견을 듣고 싶습니다:

만약 사용자가 단일 명령 상자를 통해 유틸리티 작업을 요청할 수 있는 애플리케이션을 구축한다면, 인텐트 라우터(intent router)를 어떻게 설계하시겠습니까?

명시적 규칙(explicit rules)과 결정론적 핸들러(deterministic handlers)로 시작하시겠습니까, 아니면 나중에 작은 로컬 언어 모델(local language model)을 도입하시겠습니까?

저는 특히 시스템이 테스트 가능하고(testable), 가볍고(lightweight), 유지보수 비용이 저렴한 접근 방식에 관심이 많습니다.