sideproject · 2026-07-29 · 조회수 13
채팅에 묻히는 생활 메모를 꺼내다 — 우리콕 개발기 1
우리콕 개발기 1편이다. 이 글은 문제를 정하고 Flutter 프로젝트의 뼈대와 첫 로컬 프로토타입을 만든 날을 기록한다.
왜 만들기 시작했나
아내와 나는 꼼꼼하게 일정관리 앱을 쓰는 편이 아니다. 장볼 것, 어린이집 준비물, 세금 납부, 여행 준비물처럼 나중에 챙겨야 하는 내용도 대화 중 생각나는 순간 채팅창에 적어둔다.
입력은 빠르지만 대화가 이어지면 중요한 메모가 위로 밀린다. 나중에 다시 찾거나 서로 처리했는지 물어봐야 한다. 별도의 할 일 앱을 쓰면 해결될 것 같지만 제목, 분류, 날짜를 먼저 정하는 순간 입력 자체를 미루게 됐다.
그래서 관리 습관을 새로 요구하는 앱보다 지금의 채팅 메모 습관에서 한 걸음만 옮기면 되는 앱을 만들기로 했다. 한 줄을 바로 저장하고, 상대가 확인하거나 완료할 때까지 보이게 유지하는 2인 공유 생활 인박스다. 처음에는 우리 메모라고 불렀고, 개발 중 이름을 우리콕으로 정했다.
처음 고정한 범위
첫 버전은 기능을 넓히지 않고 부부 두 명의 실제 사용만 검증한다.
- Android와 Windows에서 한 줄 메모 입력
- Android 공유 메뉴에서 텍스트와 URL 가져오기
- 상대가 확인했는지, 실제로 완료했는지 구분
- 누구나 완료하고 바로 실행 취소하거나 다시 열기
- 네트워크가 끊겨도 입력과 상태 변경을 잃지 않기
- Windows에서는 화면 구석의 작은 미니창으로 계속 확인
목록, 날짜, 알림, 검색은 첫 버전에서 빼고 실제 사용 후 필요성을 확인하기로 했다. 채팅, 댓글, 파일 첨부, AI 분류도 현재 범위가 아니다.
Android와 Windows를 모두 Flutter로
Android는 Flutter로 만들기로 했고 Windows도 Flutter Desktop을 사용하기로 했다. 메모 모델, 상태 계산, 서버 통신, 로컬 저장, 동기화 로직을 Dart로 공유할 수 있기 때문이다.
Windows의 트레이, 항상 위, 접이식 미니창 같은 기능은 Flutter 플러그인을 먼저 검토하고 부족한 부분만 네이티브 코드로 분리할 계획이다. Android 화면을 그대로 크게 띄우지 않고 마우스, 키보드, 화면 배율에 맞는 Windows UI를 따로 설계하는 것도 원칙으로 잡았다.
개발 환경 구성
첫날에는 실제 기능보다 두 플랫폼을 함께 개발할 수 있는 환경을 준비했다.
- Flutter 3.44.8 stable
- Dart 3.12.2
- Android SDK 36.0.0
- Android NDK 28.2.13676358
- JDK 21
- Visual Studio Community 2022의 Desktop development with C++
Flutter Doctor의 Android와 Windows 항목이 모두 정상으로 확인됐다. 처음에는 Android 빌드가 특정 NDK 버전을 요구했지만 설치된 SDK에 해당 버전이 없어 Gradle 동기화가 실패했다. Android Studio SDK Manager에서 NDK (Side by side) 28.2.13676358을 추가해 환경을 맞췄다.
프로젝트는 Android와 Windows만 대상으로 생성했다.
프로젝트명: woori_kok
플랫폼: android, windows
조직 식별자 기반: com.woorikok
유지보수를 위한 구조
사이드 프로젝트라도 기능을 한 화면 파일에 계속 붙이면 동기화와 플랫폼 코드가 들어오는 순간 수정하기 어려워진다. 처음부터 Feature-first 구조를 사용하고 기능 내부를 다음 계층으로 나누기로 했다.
feature/
├─ domain
├─ application
├─ data
└─ presentation
도메인은 Flutter UI나 Supabase를 모르고, 화면은 DB를 직접 호출하지 않는다. 서버와 로컬 DB 구현은 Repository 계약 뒤에 두고 Android·Windows 전용 기능도 platform adapter로 격리할 계획이다.
첫 로컬 프로토타입
서버를 연결하기 전에 메모의 핵심 상태와 화면 흐름부터 코드로 옮겼다.
- 한 줄 입력과 즉시 저장
- 새 메모와 확인한 활성 메모 분리
- 완료 처리
- Snackbar 실행 취소
- 완료 목록에서 다시 열기
- Android와 Windows 폭에 대응하는 레이아웃
- 작성자와 사용자별 확인 기록을 이용한 상태 계산
new / seen / done은 하나의 status 문자열로 저장하지 않는다. 완료는 메모의 doneAt, 확인은 사용자별 receipt로 계산한다. 작성자는 자신이 만든 메모를 이미 본 것으로 간주하고, 완료한 메모를 다시 열어도 기존 확인 기록은 유지한다.
현재 화면에는 흐름을 확인하기 위한 메모리 기반 데모 데이터가 들어 있다. Supabase와 로컬 SQLite는 아직 연결하지 않았다.
첫날의 상태 모델을 실제 사용 화면으로 발전시킨 모습. 새 메모는 상대가 아직 확인하지 않은 항목이고, 남은 메모는 확인했지만 완료하지 않은 항목이다.
첫날에는 확인하지 못한 것
첫날 작성한 코드는 아직 다음 검증을 끝내지 못했다.
- Dart 포맷
- Flutter 정적 분석
- 단위·위젯 테스트 실행
- Windows 실제 실행
- Android 에뮬레이터 실제 실행
따라서 지금 단계는 “첫 화면과 상태 구조를 작성한 상태”이며 실행 검증까지 끝난 상태는 아니다.
다음 작업
- 포맷, 정적 분석, 테스트를 실행하고 현재 코드 오류 수정
- Windows와 Android에서 첫 화면 실행
- Android 공유 메뉴의 텍스트·URL 수신 기술 검증
- Windows 미니창, 항상 위, 트레이 기술 검증
- Supabase 최소 스키마와 2인 공간 권한 구성
- 메모 생성부터 확인·완료·다시 열기까지 양 기기 동기화
- Drift와 outbox를 이용한 오프라인 복구
첫 목표는 기능이 많은 앱이 아니라 실제 대화 중에 한 줄을 옮겨 적고, 서로 다시 묻는 일이 줄어드는 앱이다.
댓글