conduit 딥다이브
— 여러 AI를 잇는 모바일 앱의 내부 설계

1프로젝트 한줄 요약

conduit는 iOS·Android용 AI 채팅 앱입니다. Open WebUI에 로그인해 서버 기능을 이용하거나, Direct 연결로 모델 API에 바로 요청하거나, Hermes 서버의 에이전트와 대화할 수 있습니다. 이 저장소에서 배울 핵심은 서로 다른 AI 서비스를 하나의 모바일 경험으로 묶는 방법입니다.

세 가지 기본 연결 경로

README에는 Apple On-Device와 Apple Private Cloud Compute(PCC)도 Direct 제공자로 소개되어 있습니다. 일반 iOS 설치 조건과 별도로 OS·기기·권한 조건이 붙습니다. 따라서 모든 iPhone에서 오프라인 모델이나 PCC를 쓸 수 있다고 읽으면 안 됩니다.

한 번의 질문에 일어나는 일

1. 선택한 모델과 대화의 저장 위치를 확인합니다.
2. 기존 메시지·첨부·생성 설정으로 요청을 구성합니다.
3. 해당 연결의 전송 방식을 통해 답변 조각이나 실행 이벤트를 받습니다.
4. 공통 상태를 갱신하고 Markdown 등으로 화면에 표시합니다.
5. 저장 정책에 따라 로컬 기록을 보존하고 필요한 서버 동기화를 진행합니다.

이 순서는 이해를 위한 요약입니다. 구현에는 임시 대화, 여러 모델 비교, 중단·재개, 첨부 업로드와 계정 전환 같은 분기가 더 있습니다. 처음부터 모든 분기를 읽기보다 DirectProviderAdapter처럼 작은 경계부터 시작하는 편이 좋습니다.

2왜 주목받는가

2026-10-23 GitHub Trending Dart Monthly #10에 선정되었고, 같은 날 스타는 2,361개입니다. 순위만으로 유입 원인을 확정할 수는 없습니다. 아래는 README와 코드에서 드러나는 관심을 끌 만한 제품적 이유에 대한 해석입니다.

2-1. 셀프호스팅의 불편이 휴대전화에 모인다

데스크톱에서 잘 쓰던 AI 서버라도 모바일에서는 키보드, 사진 첨부, 공유 메뉴, 화면 잠금, 프록시 인증이 문제가 됩니다. README는 이러한 모바일 사용의 빈틈을 출발점으로 설명합니다. 실제로 lib/platform/에는 공유 수신, 홈 위젯, 앱 생명주기, 백그라운드 실행을 담당하는 구현이 따로 있습니다.

모델을 더 똑똑하게 만드는 대신, 이미 있는 모델을 매일 쓰기 편하게 만드는 데 집중한 프로젝트입니다.

2-2. 한 종류의 서버에만 묶이지 않는 연결

Direct의 OpenAiCompatibleAdapter와 OllamaAdapter는 같은 인터페이스를 구현합니다. Open WebUI 계정 없이도 Direct 연결을 구성할 수 있다는 README의 설명과 맞닿아 있습니다. 다만 노트·채널·터미널 같은 서버 기능까지 모든 연결에 똑같이 생기는 것은 아닙니다.

이 표는 설계 방향의 비교입니다. 응답 속도·배터리·장애율의 측정 결과나 개별 경쟁 앱의 기능 순위는 아닙니다.

2-3. “로컬 우선”을 데이터 구조로 구현한다

packages/conduit_core/lib/database/에는 대화·메시지·노트·동기화 작업을 저장하는 테이블이 있습니다. packages/conduit_core/lib/sync/outbox_drainer.dart는 보류한 작업을 다시 처리합니다. 네트워크 요청 함수 하나를 넘어, 이동 중 연결이 불안정해지는 상황을 데이터 모델에 반영한 점이 좋은 학습 재료입니다.

3기술 스택 전체 지도

루트 pubspec.yaml의 앱 버전은 4.2.1+152입니다. Dart SDK 조건은 >=3.13.0 <4.0.0, Flutter 조건은 >=3.47.0입니다. 아래의 “선언”은 pubspec.yaml, “잠금”은 pubspec.lock 기준입니다.

3-1. 프론트엔드: Flutter 화면과 상태 관리

material_ui ^1.0.0, cupertino_ui ^1.0.0도 선언되어 있습니다. Material·Cupertino와 네이티브 브리지를 사용하는 앱이지, 웹사이트 전체를 WebView 하나에 넣은 구조는 아닙니다. 다만 Chart.js 등 일부 콘텐츠에는 WebView가 사용됩니다.

3-2. 백엔드와 맞닿는 클라이언트 로직

packages/conduit_core는 Flutter에 의존하지 않는 Dart 패키지입니다. 인증, API, 채팅 상태, DB, 동기화, Direct 연결을 담당합니다. 이름에 core가 붙었다고 서버가 되는 것은 아닙니다. 화면과 분리된 로직도 휴대전화 안에서 실행되는 클라이언트 코드일 수 있습니다.

3-3. 공통 패키지: 재사용의 단위를 따로 만든다

네 패키지의 선언 버전은 모두 0.1.0이고 publish_to: 'none', resolution: workspace를 사용합니다. 루트의 workspace: 목록과 하나의 잠금 파일로 의존성을 함께 해석합니다.

3-4. 인프라·빌드: 서버 배포보다 모바일 배포가 중심

.github/workflows/ci.yml은 Flutter stable을 사용하며 SDK 버전을 고정하지 않습니다. 모바일 분석·테스트, Android 네이티브 테스트, 패키지 검사, 웹 안전성, 번역 검사가 나뉩니다. 모바일 분석은 --no-fatal-warnings --no-fatal-infos이고 공통 패키지는 --fatal-infos입니다. “CI가 있다”에서 멈추지 말고 어떤 진단이 실제 실패 조건인지 읽어야 합니다.

.github/workflows/release.yml은 v* 태그에서 릴리스 노트를 검증하고 Android APK·AAB와 iOS 빌드를 처리합니다. 모델을 올리는 Docker 배포가 이 저장소의 주된 배포 단위는 아닙니다.

4아키텍처 심화 분석

전체 구조: 코드의 경계와 데이터의 이동

도식의 연결은 선택 가능한 경로입니다. 모든 메시지가 Open WebUI를 거쳐 Direct 제공자로 가는 구조가 아닙니다. 또 추론 요청의 목적지와 대화 기록의 동기화 목적지는 서로 다를 수 있습니다.

4-1. 포트와 어댑터: “무엇이 필요한가”와 “어떻게 하는가”

packages/conduit_core/lib/ports/에는 플랫폼 기능의 계약이 있습니다. 예를 들어 DatabaseOpenerPort는 DB 실행기를 여는 역할을 맡고, SecureKeyValueStore는 키·값 읽기와 쓰기 역할을 정의합니다. Flutter 구현은 lib/platform/flutter_database_opener.dart와 lib/platform/flutter_secure_key_value_store.dart에 놓입니다.

lib/main.dart의 main()은 ProviderContainer를 만들 때 실제 구현을 주입합니다. 다음은 그중 DB와 갱신 스케줄러 부분의 발췌입니다.

// lib/main.dart의 ProviderContainer 설정 중 발췌
final providerContainer = ProviderContainer(
  overrides: [
    databaseOpenerProvider.overrideWithValue(
      const FlutterDatabaseOpener(),
    ),
    flushSchedulerProvider.overrideWithValue(
      const FlutterFlushScheduler(),
    ),
  ],
);

로직은 “DB를 열 수 있는 대상”을 요구할 뿐, 앱 문서 디렉토리를 얻는 Flutter 플러그인을 직접 알 필요가 없습니다. 실제 FlutterDatabaseOpener.open()이 driftDatabase()와 getApplicationSupportDirectory를 연결합니다. 테스트에서는 이 계약을 가짜 구현으로 바꿀 수 있습니다.

패키지 주석에는 conduitd나 데스크톱 호스트의 재사용 의도도 등장합니다. 그러나 이 커밋의 루트에는 해당 앱 디렉토리가 없습니다. 확장을 위한 계약이 있다는 사실과 완성된 데스크톱 제품이 있다는 주장은 구분해야 합니다.

4-2. 전략 패턴과 레지스트리: 연결은 달라도 호출 모양은 같다

packages/conduit_core/lib/features/direct_connections/services/direct_provider_adapter.dart의 계약은 작습니다. 아래 코드는 메서드 선언을 그대로 옮기고 주석을 줄인 것입니다.

abstract interface class DirectProviderAdapter {
  String get key;

  Future<DirectConnectionProbe> probe(
    DirectConnectionProfile profile,
  );

  Future<List<DirectRemoteModel>> listModels(
    DirectConnectionProfile profile,
  );

  DirectCompletionRun startCompletion(
    DirectConnectionProfile profile,
    DirectCompletionRequest request,
  );
}

OpenAiCompatibleAdapter와 OllamaAdapter는 이 계약을 구현합니다. DirectProviderAdapterRegistry.register()는 문자열 키로 구현을 등록하며, 앞뒤 공백을 제거한 뒤 빈 키·내부 공백이 든 키·기본적으로 중복인 키를 거절합니다. require()는 등록되지 않은 키에 오류를 냅니다.

프로필은 구현 클래스 이름 대신 문자열 키를 저장합니다. 새 어댑터를 등록하는 확장은 프로필 스키마 변경을 줄여 줍니다. 여기서 전략 패턴은 “어떤 방식으로 모델과 통신할지 갈아 끼우는 것”, 레지스트리는 “그 구현을 키로 찾는 명부”입니다.

packages/conduit_core/lib/features/direct_connections/models/direct_completion.dart의 DirectCompletionRequest는 모델 ID, 메시지, 생성 매개변수를 모읍니다. DirectTextPart·DirectImagePart·DirectFilePart처럼 콘텐츠 종류를 타입으로 나누므로, 화면이 공급자마다 다른 JSON을 직접 만들 필요를 줄일 수 있습니다.

4-3. 생산자와 소비자 분리: 네트워크 속도와 화면 속도는 다르다

먼저 packages/conduit_core/lib/services/chat_completion_transport.dart의 ChatCompletionTransport는 httpStream, taskSocket, jsonCompletion을 구분합니다. ChatCompletionSession은 바이트 스트림, 작업 ID, JSON 결과, 중단 함수를 전송 모드에 맞게 담습니다.

이는 README의 “WebSocket 스트리밍”이라는 소개보다 넓은 구현입니다. Open WebUI 응답에 따라 HTTP 스트림이나 JSON 경로도 있으며 Direct에는 별도의 제공자 스트림이 있습니다. 따라서 conduit의 모든 답변이 WebSocket으로 온다고 설명하면 틀립니다.

첫 번째 경계: 네트워크 조각을 완성된 이벤트로

packages/conduit_core/lib/services/sse_frame_scanner.dart의 SseFrameScanner.addChunk()는 문자열 조각을 받아 빈 줄로 끝난 SSE 프레임을 내보냅니다. 여러 data: 줄은 줄바꿈으로 합치며, 조각 사이에서 끊긴 CRLF도 처리합니다. 네트워크 조각 하나와 JSON 하나가 일치한다고 가정하지 않습니다.

// 학습용 예시: 두 번 도착한 조각이 이벤트 하나가 된다
final scanner = SseFrameScanner();
final first = scanner.addChunk('data: {"x":').toList();
final second = scanner.addChunk('1}\n\n').toList();

// first.length == 0
// second.single.data == '{"x":1}'
// 실제 바이트의 UTF-8 해독은 이 스캐너에 들어오기 전의 책임

기본 한도는 한 줄과 한 프레임의 데이터 각각 4 * 1024 * 1024 UTF-16 코드 단위입니다. 바이트 한도라고 읽지 마세요. close()는 빈 줄로 끝나지 않은 마지막 이벤트를 버립니다. 잘린 JSON을 완성된 데이터처럼 넘기지 않기 위한 경계입니다.

두 번째 경계: 이벤트가 올 때마다 전체 화면을 다시 그리지 않기

packages/conduit_core/lib/features/chat/providers/chat_messages_notifier.dart의 _scheduleStreamingContentFrame()은 이미 프레임이 예약되었는지 확인합니다. _flushStreamingContentUpdate()는 버퍼 버전과 마지막으로 반영한 버전을 비교한 뒤 streamingContentProvider를 갱신합니다.

FlutterFlushScheduler.scheduleFlush()는 SchedulerBinding.instance.scheduleFrameCallback()을 씁니다. 프레임 끝의 콜백이 아니라 프레임 시작에 갱신을 붙여 같은 프레임에서 화면 변경을 처리하려는 선택입니다. 백그라운드에서는 보이는 프레임을 기다리지 않고 반영하는 분기도 있습니다.

데이터를 빠짐없이 받는 일과 화면을 매번 갱신하는 일은 서로 다른 문제로 설계해야 합니다.

4-4. Outbox 패턴: 먼저 저장하고, 보낼 일을 남긴다

packages/conduit_core/lib/database/tables/outbox.dart의 OutboxOps는 단순 실패 로그가 아닙니다. 작업 종류, 대상 대화, payload, 상태, 시도 횟수, 다음 시각, 마지막 오류를 가진 앱 재시작 후에도 남는 작업 목록입니다. 상태 제약은 pending·inFlight·failed, 시도 횟수 제약은 attempts >= 0입니다.

packages/conduit_core/lib/database/daos/chats_dao.dart의 insertLocalChatWithCreateOp()와 appendMessagesWithUpdateOp()는 데이터 쓰기와 필요한 큐 기록을 같은 트랜잭션에 묶습니다. 둘 중 하나만 남으면 “화면에는 있는데 보낼 일이 없음” 또는 “보낼 일은 있는데 데이터가 없음”이 생기기 때문입니다.

packages/conduit_core/lib/sync/outbox_drainer.dart의 OutboxDrainer는 작업자 풀 크기 2를 사용합니다. requestCompletion은 실패 횟수가 5에 도달하면 실패 상태로 보류해 수동 재시도 대상으로 만듭니다. 오프라인이나 일시 보류(OutboxDeferralException)는 이 실패 횟수를 늘리지 않습니다. 순수 동기화 작업은 같은 횟수 제한을 일괄 적용하지 않습니다.

// packages/conduit_core/lib/sync/backoff.dart의 기본 설정과 재시도 창
baseMs = 2000
capMs  = 300000
window = min(capMs, baseMs * 2^attempt)
delay  = floor(window * jitter)

// attempt 0: 0 이상 2초 미만
// attempt 1: 0 이상 4초 미만
// 상한에 도달하면: 0 이상 5분 미만

위 식은 Dart 코드가 아닌 계산 설명입니다. Backoff.delayMsForAttempt()는 무작위 함수를 주입받아 테스트 가능하게 합니다. 실제 drainer는 지연을 초로 변환하고 최소 1초 뒤로 예약합니다. 지연이 0인 작업을 같은 처리 순환에서 계속 잡는 일을 피합니다.

packages/conduit_core/lib/database/chat_database_repository.dart의 persistNewDirectChat()와 persistDirectMessages()도 읽어 볼 만합니다. Direct 기록을 Open WebUI에 동기화하더라도 requestCompletion을 다시 넣지 않습니다. 이미 모델 제공자가 수행한 생성을 서버에서 중복 실행하지 않기 위해서입니다.

5디렉토리 구조 해부

lib/features/와 packages/conduit_core/lib/features/에 비슷한 기능 이름이 반복됩니다. 중복 기능이라고 바로 판단하지 마세요. 앞쪽은 Flutter 표현을, 뒤쪽은 플랫폼과 분리된 상태·서비스를 찾는 출발점입니다.

줄 수로 보는 학습 범위

커밋 3f95de1에서 Git이 추적하는 실제 파일의 물리적 행 수입니다. 마지막 개행이 없는 행도 한 줄로 셉니다. 빈 줄·주석을 포함하며 테스트도 포함합니다. 서브모듈 내부와 생성 시 생기는 파일은 제외합니다. Swift는 32개·29,655줄, Kotlin은 21개·12,060줄입니다. 줄 수가 곧 기능 수나 품질 점수는 아닙니다.

.gitmodules와 docs/BUILDING.md를 함께 보면 역할 차이가 분명해집니다. Mermaid·KaTeX는 빌드에 필요한 자산이고, openwebui-src·hermes-src는 API 참조용입니다. 참조 저장소를 포함한다고 그 서버가 앱과 함께 실행되거나 배포되는 것은 아닙니다.

6학습 포인트 (기술별)

6-1. Dart: 타입과 비동기를 함께 읽는다

DirectCompletionRequest는 메시지 목록과 매개변수를 수정 불가능한 컬렉션으로 보관하고, 빈 모델 ID를 거절합니다. “누구나 어떤 값이나 넣을 수 있는 Map”보다 잘못된 상태를 줄이는 모델링입니다.

Future<T>는 나중에 한 번 얻을 결과, Stream<T>은 여러 번 들어오는 값의 흐름입니다. 모델 목록은 전자에, 연속 답변 조각은 후자에 어울립니다. async*·yield·await for를 packages/conduit_core/lib/features/direct_connections/services/ollama_stream_parser.dart에서 함께 찾아보세요.

작은 연습: 텍스트와 이미지만 받는 메시지 모델을 설계해 보세요. 이미지 URL을 일반 문자열에 섞는 설계와 DirectImagePart로 분리한 설계를 비교하면 검증 위치가 달라집니다.

6-2. Riverpod: 상태 관리와 의존성 주입을 한 그래프로

ref.watch()는 의존하는 값의 변화를 구독하고, ref.read()는 해당 시점의 값을 읽는 데 사용됩니다. conduit에서는 화면 상태뿐 아니라 DB 열기·워커·생명주기 같은 기능도 제공자로 연결합니다. 관련 개념은 Riverpod 공식 시작 문서에서 확인할 수 있습니다.

lib/main.dart에서 “무엇을 어떤 구현으로 바꾸는가”를 표로 적어 보세요. databaseOpenerProvider와 flushSchedulerProvider 두 개만 따라가도 앱 시작과 테스트 대체의 관계가 보입니다.

작은 연습: 실제 프레임 대신 콜백 목록을 저장하는 가짜 FlushScheduler를 구상하세요. 콜백 실행 전에는 상태가 유지되고, 실행 뒤에만 갱신되는지 설명할 수 있으면 의존성 주입의 이점을 이해한 것입니다.

6-3. 네트워크: “HTTP 성공” 다음에도 계약이 있다

SSE는 빈 줄로 프레임을 나누고 Ollama의 전용 스트림은 줄 단위 JSON을 처리합니다. 두 방식 모두 네트워크의 수신 조각과 논리적 데이터의 경계가 다릅니다. SseFrameScanner와 parseOllamaNdjson()을 비교해 경계가 어디서 확정되는지 찾아보세요.

packages/conduit_core/lib/services/streaming_response_controller.dart의 StreamingResponseController.cancel()은 중복 취소를 막고 구독을 해제합니다. 반면 서버 작업 중단은 packages/conduit_core/lib/features/chat/services/chat_transport_dispatch.dart의 stopActiveTransport()가 전송 메타데이터를 보고 HTTP 취소와 작업 중단 경로를 선택합니다.

작은 연습: “화면이 더 이상 구독하지 않음”과 “서버가 생성을 멈춤”을 각각 화살표로 그려 보세요. 이 둘을 한 동작으로 가정하면 화면을 닫아도 서버 비용이 계속 생기는 상황을 놓칠 수 있습니다.

6-4. Drift·SQLite: 캐시를 넘어 상태의 근거로

AppDatabase.schemaVersion은 10입니다. 같은 파일의 설명 주석 일부에는 버전 8이 남아 있습니다. 실제 마이그레이션 분기는 9·10까지 이어지므로, 현재 동작을 읽을 때는 실행되는 getter와 분기를 우선 확인합니다.

packages/conduit_core/lib/database/fts/fts_query.dart의 toFtsMatchQuery()는 사용자의 검색어를 공백 단위로 나누고 따옴표로 감싼 접두 검색어로 바꿉니다. 검색 문자열을 SQL 매개변수로 넘기는 일과 FTS 검색 문법을 안전하게 구성하는 일은 별개입니다.

// toFtsMatchQuery()의 결과를 이해하는 예시
입력:  flutter stream
출력:  "flutter"* "stream"*

입력:  AND
출력:  "AND"*

// 빈 입력은 빈 문자열. 호출자는 검색을 생략해야 한다.

이것은 전용 한국어 형태소 분석기라는 뜻이 아닙니다. packages/conduit_core/lib/database/fts/fts_ddl.dart의 토크나이저는 unicode61 remove_diacritics 2입니다. 한글의 조사·띄어쓰기까지 기대한 대로 찾는지는 별도의 검색 사례로 검토해야 합니다.

작은 연습: 빈 검색어, 따옴표가 든 검색어, AND만 있는 검색어의 예상 결과를 적어 보세요. 관련 DB 개념은 Drift 공식 문서의 테이블·트랜잭션·마이그레이션 순서로 읽으면 좋습니다.

6-5. 인증: 저장 장소와 전송 범위를 따로 지킨다

packages/conduit_core/lib/auth/api_auth_interceptor.dart의 ApiAuthInterceptor.onRequest()는 대상이 선택한 서버와 같은 origin이거나 같은 호스트의 HTTP:80 → HTTPS:443 전환인지 확인하고, 이 조건을 벗어나면 서버 자격 증명을 제거합니다. 보안 저장소에 넣었다는 사실만으로 다른 서버에 잘못 전송하는 문제까지 해결되지는 않습니다.

DirectConnectionProfile.secureUpdate()는 origin이 바뀌고 새 비밀 값의 확인이 없으면 withoutSecrets()로 비밀 값을 지웁니다. DirectConnectionProfileStore.upsert()는 변경을 직렬화하며, expectedPrevious를 전달한 경우 저장된 값과 비교해 동시 편집 충돌을 감지합니다.

6-6. 렌더링·국제화·테스트: UI 바깥의 품질

lib/shared/widgets/markdown/markdown_compile_service.dart에는 동기 컴파일 임계값 384, 전처리 임계값 768(둘 다 문자열 길이의 UTF-16 코드 단위), 워커 유휴 정리 시간 30초가 있습니다. MarkdownCompileService.handleMemoryPressure()는 캐시를 비우고 유휴 워커 정리를 요청합니다. 이 수치를 모든 앱의 정답으로 외우기보다 작은 입력과 긴 입력을 다르게 다루는 이유를 배웁니다.

l10n.yaml은 영어 ARB를 템플릿으로 두고 한국어 ko를 포함한 14개 로케일을 나열합니다. lib/l10n/app_ko.arb는 번역 입력입니다. 생성된 Dart를 손으로 수정하는 대신 ARB와 자리표시자 계약을 관리합니다.

좋은 학습 단위는 파일 전체가 아니라 입력·출력·실패 조건을 함께 설명할 수 있는 작은 계약입니다.

작은 연습: packages/conduit_core/test/services/sse_frame_scanner_test.dart를 읽고 각 테스트를 “상황 → 기대 결과” 한 줄로 번역해 보세요. 테스트 개수나 줄 수만으로 커버리지가 충분하다고 단정하지는 않습니다.

7하드웨어 / 시스템 요구사항

7-1. 앱을 쓰는 기기

7-2. Apple 모델은 별도 조건

README와 docs/BUILDING.md 기준으로 On-Device는 iOS 26과 Apple Intelligence 지원 기기가 필요하며, 개발에는 Xcode 26을 요구합니다. 로컬 모델 문맥 창은 4K로 설명되어 있고 이미지·추론 제어·도구 호출은 지원하지 않는다고 적혀 있습니다.

같은 문서에서 PCC는 iOS 27, Xcode 27, Apple Intelligence와 Apple의 관리형 PCC entitlement를 추가 조건으로 제시합니다. 오래된 SDK에서는 PCC를 컴파일에서 제외하면서 기본 배포 대상은 iOS 16으로 유지한다고 설명합니다. 이 조건은 저장소의 기능 안내이며 기기별 실제 사용 가능 여부나 권한 발급을 보장하지 않습니다.

7-3. 소스 빌드에 필요한 환경

docs/BUILDING.md는 build_runner를 필수 단계로 설명합니다. Pigeon 생성기는 분석기 버전 범위가 달라 tool/pigeon_codegen/에 별도 도구 의존성을 둡니다. 누락된 생성 파일 오류를 실제 구현 버그로 오해하지 않는 것도 빌드 학습의 일부입니다.

7-4. 모델을 돌리는 서버와 네트워크

Direct Ollama 연결에서 모델은 보통 Ollama가 실행 중인 기기에서 돌아갑니다. 그 기기의 RAM·VRAM은 모델 크기, 양자화, 문맥 길이, 동시 요청 수에 좌우됩니다. conduit 자체의 요구사항으로 “GPU 몇 GB”를 일괄 지정할 근거는 없습니다.

휴대전화에서 localhost를 입력하면 개발 PC가 아니라 그 휴대전화 자신을 가리킵니다. 실기기에서 PC의 모델 서버를 사용하려면 접근 가능한 주소, 서버의 수신 설정, 방화벽과 네트워크 경로를 함께 확인해야 합니다.

Open WebUI 스트리밍 문제에 대해 빌드 안내는 서버의 ENABLE_WEBSOCKET_SUPPORT="true" 설정을 확인하도록 안내합니다. 프록시도 인증 쿠키·헤더와 지속 연결을 전달해야 합니다. 앱이 여러 전송 방식을 처리한다는 사실이 서버 설정 오류까지 없애 주지는 않습니다.

8직접 해볼 수 있는 실습 과제

아래 과제는 실제 계정이나 유료 모델 없이도 설계하고 검증할 수 있습니다. 원본 코드와 테스트를 읽은 뒤, 네트워크 입력은 가짜 데이터로 대체해 보세요. 각 과제의 완료 기준을 충족한 다음 범위를 넓히면 좋습니다.

// 과제 2의 판별 입력. 역슬래시 표기는 실제 제어 문자를 뜻한다.
A: 'data: hello\n\n'                // 1개, hello
B: 'event: ping\n\n'                // 0개
C: 'data:\n\n'                     // 1개, 빈 문자열
D: 'data: {"unfinished":' + EOF     // 0개

실습의 목표는 기능을 많이 붙이는 것이 아니라 실패해도 지켜야 할 조건을 말과 코드로 표현하는 것입니다.

9관련 기술 심화 학습 로드맵

아래는 기초 문법을 조금 아는 독자를 위한 6주 순서입니다. 시간은 개인차가 크므로 주차보다 완료 기준을 우선하세요. 첫 주부터 앱 전체를 빌드하는 것보다 순수 Dart 함수의 계약을 읽는 편이 범위를 잡기 쉽습니다.

공식 문서와 코드를 왕복하는 순서

1. Dart 비동기 문서로 한 번의 결과와 연속된 값의 차이를 익힌 뒤 SSE 스캐너를 읽습니다.
2. Flutter 앱 아키텍처 문서에서 의존성 주입·테스트 가능성을 공부하고 플랫폼 포트와 비교합니다.
3. Riverpod 시작 문서를 읽고 ProviderContainer의 overrides를 추적합니다.
4. Drift 문서에서 트랜잭션을 익힌 뒤 데이터와 Outbox를 함께 쓰는 이유를 설명합니다.
5. Ollama API 문서로 서버와 클라이언트의 책임을 확인한 뒤 전용 어댑터와 비교합니다.

10핵심 키워드 사전

11참고 링크

공식 저장소와 프로젝트 문서

• cogwheel0/conduit 공식 저장소 — 프로젝트 소개와 배포 안내
• v4.2.1 릴리스 — 2026-10-16 배포 버전
• 빌드 안내 — 환경, 서브모듈, 코드 생성, 검증 절차
• 개인정보 처리 안내 — Direct 요청과 기록 동기화의 차이
• LICENSE — GPL-3.0 라이선스 전문
• Open WebUI · Ollama · Hermes Agent — 연결 상대 프로젝트

핵심 소스 바로 가기 — 커밋 3f95de1 기준

• pubspec.yaml · pubspec.lock — 선언 범위와 잠금 버전
• lib/main.dart — 플랫폼 구현 주입
• direct_provider_adapter.dart — 공통 계약·레지스트리
• sse_frame_scanner.dart — 증분 이벤트 파싱
• chat_messages_notifier.dart — 스트리밍 버퍼·화면 갱신
• app_database.dart · chat_database_repository.dart — 스키마·저장 위치·Direct 기록 처리
• outbox_drainer.dart · backoff.dart — 지속 작업·재시도
• api_auth_interceptor.dart — 인증 정보의 전송 범위
• ci.yml · check_package_boundaries.dart — 검사 조건과 패키지 경계

관련 기술의 공식 문서

• Dart 비동기 프로그래밍 — Future·Stream의 출발점
• Flutter 앱 아키텍처 — 구조·의존성 주입·테스트 가능성
• Riverpod — 제공자와 컨테이너를 익히는 시작 문서
• Drift — 테이블·질의·트랜잭션·마이그레이션
• Ollama API — 모델 서버의 HTTP 인터페이스

현재 상태 (2026-10-23 확인)