• 의존성 주입
• 관련 라이브러리

오늘의 공부 내용 이미지 💫

🤔 의존성 주입이란 (DI)

의존성 주입(Dependency Injection, DI)은 객체 간의 의존성을 외부에서 주입하는 설계 패턴이다. 클래스가 직접 다른 객체를 생성하는 것이 아니라, 외부에서 제공된 객체를 사용하는 것이다.

😲 왜 사용할까

1) 결합도를 낮추기 위해서 객체 내부에서 다른 객체를 직접 생성하면, 그 객체가 바뀔 때마다 내 코드도 수정을 해야 한다. 외부에서 넣어준다면 내부 코드는 바뀔 필요가 없어져서 변화에 유연하다.

2) 테스트가 쉬워지기 위해서 실제 데이터베이스 대신 가짜 데이터(Mock)를 넣어 테스트 하고 싶을 때, DI가 되어 있다면 코드 수정 없이 가짜 데이터를 주입해서 테스트 할 수 있다.

3) 재사용성과 유지보수성 향상 한 번 만들어둔 로직을 여기저기서 필요한 부품만 바꿔 끼우며 다시 사용할 수 있다.

▪️ 코드 예시

class Engine {}

class Car {
  final Engine engine;
  Car(this.engine); // 생성자로 직접 받음
}

// 사용 시
final myCar = Car(Engine());

🥚 수동 DI의 한계

단순 생성자 주입만 사용하면, 부모 위젯에서 아주 먼 자식 위젯으로 데이터를 전달할 때 중간 위젯들이 사용하지도 않는 데이터를 단순히 전달만 해야 하는 Prop Drilling 현상이 발생한다.

🍳 그래서 라이브러리를 활용해서 DI를 사용한다.

▫️ Provider를 활용한 주입

위젯 트리 상단에서 공급하고, 하위 트리에서 context를 통해 찾아 쓰는 방식 -> BuildContext기반으로 위젯 트리 구조에 의존한다.

// 1. 공급 (위젯 트리 상단)
Provider(
  create: (_) => AuthService(),
  child: MyApp(),
)

// 2. 주입 (하위 위젯)
final auth = Provider.of<AuthService>(context);
// 또는 context.read<AuthService>();

▫️ Riverpod을 활용한 주입

전역 변수로 Provider를 선언하고, ref를 통해 안전하게 주입 -> Compile-safe 위젯 트리와 독립적이며 Provider의 단점을 모두 개선함

// 1. 전역 선언
final repositoryProvider = Provider((ref) => Repository());

// 2. 주입 (위젯 내부)
Widget build(BuildContext context, WidgetRef ref) {
  final repo = ref.watch(repositoryProvider); // 주입 완료
  return Text(repo.data);
}

▫️ GetIt을 활용한 패턴

전역적인 '저장소'에 등록해두고 어디서든(위젯 밖에서도) 꺼내 쓰는 방식 -> BuildContext없이 어디서든 접근 가능하며, 테스트 시에 Mock 교체가 쉽다.

final locator = GetIt.instance;

// 1. 등록 (Main함수 등에서)
locator.registerSingleton<ApiService>(ApiService());

// 2. 주입 (어디서든)
final api = locator<ApiService>();

🍇 핵심 요약

🍒 의존성 주입(DI)은 객체가 직접 의존성을 생성하는 것이 아니라, 외부에서 생성된 객체를 전달받는 디자인 패턴으로 이를 사용하는 이유는 객체 간의 결합도를 낮추어 코드의 유연성을 높이고, 특히 단위 테스트 시 가짜 객체를 주입하기 쉬워져 테스트 용이성을 확보할 수 있기 때문이다.!

🍒 Flutter에서 의존성 주입은 객체 간의 결합도를 낮추기 위해 필수적이다. 기본적으로는 생성자 주입 방식을 사용하지만, 앱 규모가 커지면 하위 위젯으로 데이터를 반복 전달해야 하는 Prop Drilling 문제가 발생할 수 있어서 이를 해결하기 위해서는 GetIt이나 Provider, Riverpod 같은 도구를 활용하여 의존성을 관리 할 수 있다.

🍒 결과적으로 코드가 더 깨끗해지고, 단위 테스트 시 Mock 객체를 주입하기 매우 유리한 구조가 되어 유지보수성이 크게 향상한다.

오늘의 공부 내용 이미지 💫

🍔 구조화를 해서 설명하기

크게 컴파일 과정과 렌더링 방식 두가지로 설명

🥔 컴파일 과정

-> 내가 쓴 Dart 언어를 브라우저가 알아듣는 언어로 번역하는 과정

• Dart to JavaScript 브라우저는 Dart 언어를 직접 해석할 수 없다. 따라서 Flutter는 dart2js컴파일러를 사용하여 작성한 Dart 코드를 브라우저가 이해할 수 있는 JavaScript로 변환한다.
• 패키징 앱의 비지니스 로직과 Flutter 프레임워크 자체를 하나의 JS 파일로 묶어 브라우저에서 실행 가능하게 만든다.

🍟 렌더링 계층

-> 번역이 끝났다면 이제 화면에 UI를 그린다.

Flutter Web은 화면을 그릴 때 두 가지 엔진 중 하나를 선택한다.

• HTML 렌더러 (브라우저가 기본적으로 가지고 있는 재료 HTML태그, CSS 효과 들을 조합해서 화면을 만든다.)

  • 기술: HTML 요소, CSS, Canvas 2D 사용
  • 장점: 파일 크기가 작음, 로딩 속도가 빠름
  • 단점: 복잡한 그래픽에서 성능 저하 기능
  • 용도: 텍스트 위주의 웹사이트, 저사양 환경

• CanvasKit 렌더러 (브라우저의 기본 재료를 무시하고, Skia라는 강력한 그래픽 엔진을 웹으로 가져와서 픽셀을 하나씩 그린다.)

  • 기술: WebAssembly(Wasm) + Skia 엔진
  • 장점: 모바일과 100% 동일한 품질, 성능 우수
  • 단점: 엔진 다운로드로 초기 로딩이 길다
  • 용도: 화려한 애니메이션, 복잡한 UI 앱

🍻 브라우저와의 통신

• 입력처리 마우스 클릭, 휠 스크롤, 키보드 입력 등 브라우저 이벤트를 Flutter 포인터 데이터로 변환

• 접근성 Flutter는 화면의 픽셀만 그리는 것이 아니라, 웹 표준에 맞게 Semantics Tree를 생성하여 스크린 리더(시각장애인용 서비스)가 작동하도록 돕는다.

🔹 Flutter Web 장점 단점

🔔 장점

브라우저의 레이아웃 엔진에 의존하지 않고 Flutter가 직접 픽셀을 제어한다. 한번의 작성으로 모든 브라우저에서 동일한 UI를 완벽하게 구현할 수 있다.

🔕 단점

❗️ 지연로딩 초기 로딩 속도가 느릴 수 있다.

❗️ 검색 엔진 최적화의 어려움 구글이나 네이버 같은 검색 엔진 로봇은 HTML 텍스트를 읽어서 정보를 수집하는데 Flutter Web은 화면을 통째로 그리기 때문에 로봇이 내용을 읽기가 매우 어려울 수 있다. 네이버나 구글 검색 결과 상단에 우리 사이트를 노출시키기가 힘들다.

🔷 단점에 대한 해결 방안은?

❗️🔔 지연로딩 활용 앱의 모든 기능을 한 번에 불러오지 않고, 사용자가 클릭할 때만 필요한 코드를 다운로드하게 설정한다. 예를 들어, 관리자 설정 페이지는 사용자가 들어갈 때만 불러오도록 코드를 쪼개는 것이 방법이다. ➕ Asset 최적화를 할 수 있다. 고용량 이미지는 외부 서버나 Firebase Storage에 두고 호출하여 초기 패키지 크기를 줄일 수 있다.

❗️🔔 검색 최적화 문제 극복 검색 노출이 중요한 랜딩 페이지나 블로그는 SEO에 강한 기존 웹 기술(HTML, React..)로 만들고, 실제 복잡한 기능을 수행하는 메인 서비스는 Flutter Web으로 개발하여 연결한다. seo_renderer같은 라이브러리를 사용해 검색 로봇이 읽을 수 있는 최소한의 HTML텍스트를 생성하여 보완할 수 있다.

📝 핵심 요약

Flutter Web은 Dart 코드를 브라우저용 JavaScript를 번역하여 실행된다. 화면을 그릴 때는 성능과 용량 사이의 균형을 맞추기 위햐 표준 웹 기술을 쓰는 HTML 방식과 직접 픽셀을 그리는 CanvasKit 방식 중 최적의 경로를 선택해서 작동한다.

기존 웹 개발은 브라우저마다 CSS 해석 방식이 달라 크로스 브라우징 이슈가 잦았다. 하지만 Flutter Web은 브라우저의 레이아웃 엔진에 의존하지 않고 Flutter가 직접 픽셀을 제어한다. 덕분에 한번의 작성으로 모든 브라우저에서 동일한 UI를 완벽하게 구현할 수 있다는 점이 가장 큰 장점이다.

오늘의 공부 내용 이미지 💫

😟 문제 상황

팀 프로젝트 Healthy bag 진행 중, 외부 API나 Firebase에서 받아오는 데이터 구조 (DTO)와 앱의 핵심 비지니스 로직에서 사용하는 데이터 구조 (Entity)를 하나로 합쳐서 사용할지, 분리해야 할지에 대한 혼란이 발생함. 특히 Comment와 Feed 데이터를 UI에 바인딩하는 과정에서 모델의 역할이 모호해지는 문제

🤯 원인 분석

• 의존성 문제: DTO를 그대로 UI나 UseCase에서 사용하면, 서버 데이터 구조가 변경될 때마다 앱 전체 코드를 수정해야 하는 리스크가 있음
• 클린 아키텍처 원칙: 데이터 계층(Data Layer)과 도메인 계층(Domain Layer)은 엄격히 분리되어야 하며, 각 계층에 맞는 최적화된 모델이 필요함.

🥹 해결 방법

Model(Entity) 정의: Comment와 Feed를 순수한 Dart 객체인 Entity로 정의하여 도메인 계층에 위치시킴. (UI는 오직 이 Entity만 바라보게 함)

DTO 및 Mapper 활용: fromJson, toJson 등을 포함한 DTO를 데이터 계층에 두고, 이를 Entity로 변환해 주는 별도의 로직을 구현.

UI 데이터 바인딩 분리: 기존의 복잡한 홈페이지 UI 코드에서 데이터 로직을 분리하여, 전달받은 Entity를 위젯에 주입하는 방식으로 리팩토링 진행.

오늘의 배운 점 😵‍💫

클린 아키텍처는 처음 설계할 때는 번거롭지만, 프로젝트가 커질수록 유지보수에서 강력한 힘을 발휘한다..!

RAG

RAG (Retrieval-Augmented Generation, 검색 증강 생성) 는 LLM(거대 언어 모델)이 학습하지 않은 외부 데이터를 참조하여 답변의 정확성을 높이는 기술입니다. 기존 LLM의 한계인 할루시네이션(거짓 답변)을 줄이고, 최신 정보나 비공개 데이터(기업 내부 문서 등)를 활용하여 답변할 수 있게 해줍니다.

RAG의 핵심 프로세스

RAG는 크게 세 단계로 작동한다.

• 검색 (Retrieval): 사용자의 질문과 관련된 문서를 외부 데이터베이스(벡터 DB 등)에서 찾아낸다.

• 증강 (Augmentation): 찾아낸 관련 정보를 사용자의 원래 질문과 합쳐서 모델에게 전달할 '맥락(Context)'을 만든다.

• 생성 (Generation): 모델이 제공된 맥락을 바탕으로 최종 답변을 작성한다.

왜 RAG가 필요한가?

학습된 데이터에만 의존하는 기존 LLM의 한계를 다음과 같이 보완한다.

• 환각(Hallucination) 방지: 모델이 모르는 것을 지어내지 않고, 제공된 근거 데이터를 기반으로 답변하게 유도한다

• 최신 정보 반영: 모델을 매번 새로 학습(Fine-tuning)시키지 않아도, 외부 데이터베이스만 업데이트하면 실시간 정보나 최신 뉴스를 답변에 반영할 수 있다

• 보안 및 전문성: 기업 내부 문서나 특정 분야의 전문 데이터를 연동하여 보안을 유지하면서도 고도로 전문적인 답변을 생성할 수 있다

Firebase 기반 RAG 아키텍처

RAG의 핵심은 "질문에 맞는 데이터를 찾아(Search), 질문과 함께 AI에게 전달(Prompt)"하는 것

단계별 구현 방법

Step 1: 지식 베이스 구축 (Vector Search 설정)

일반적인 텍스트 검색과 달리, AI는 단어의 의미를 수치화한 '벡터(Vector)'를 비교해 검색합니다.

1) Firebase 확장 프로그램 설치: Firebase Console에서 "Vector Search with Firestore" 확장을 설치합니다.

2) 데이터 임베딩(Embedding): PDF나 텍스트 문서를 작은 조각(Chunk)으로 나눈 뒤, Google의 text-embedding-004 모델 등을 사용해 벡터 데이터로 변환하여 Firestore에 저장합니다.

이 확장을 쓰면 특정 컬렉션에 문서를 넣을 때 자동으로 벡터 값을 생성해 줍니다.

Step 2: Flutter 앱 설정

Flutter 프로젝트에 필요한 패키지들을 추가하기

dependencies:
  firebase_core: ^3.0.0
  cloud_firestore: ^5.0.0
  firebase_vertex_ai: ^1.0.0 # Firebase용 Gemini SDK

Step 3: 질문에 맞는 데이터 찾기 (Retrieval)

사용자가 질문을 던지면, 그 질문 역시 벡터로 변환하여 Firestore에서 가장 유사한 문서를 찾아오기

// 예시: 유사한 문서 3개 가져오기
final querySnapshot = await FirebaseFirestore.instance
    .collection('knowledge_base')
    .findNearest(
      vectorField: 'embedding',
      queryVector: userQueryVector, // 사용자 질문의 벡터값
      distanceMeasure: DistanceMeasure.cosine,
      limit: 3,
    )
    .get();

Step 4: AI에게 맥락과 함께 질문하기

final model = FirebaseVertexAI.instance.generativeModel(model: 'gemini-1.5-flash');

// 검색된 데이터를 맥락(Context)으로 결합
String context = querySnapshot.docs.map((doc) => doc['text']).join('\n');
String fullPrompt = "다음 정보를 바탕으로 답변해줘:\n$context\n\n질문: ${userController.text}";

final response = await model.generateContent([Content.text(fullPrompt)]);
print(response.text); // 증강된 답변 출력

🎛 프로그램, 프로세스, 스레드의 정의

프로그램 (Program)

정의: 실행 가능한 코드의 집합 (파일) 상태: 멈춰 있음 (정적) 비유하자면 일한 내용이 담긴 창고?

프로세스 (Process)

정의: 실행 중인 프로그램의 인스턴스 상태: 살아있음 (동적) 비유해보면?? 시키고 있는 감독관

스레드 (Thread)

정의: 프로세스 내에서 실행되는 흐름의 단위 상태: 일하고 있음 (동적) 비유하자면 시키는대로 일하는 노동꾼 느낌

핵심 차이점

• 자원 공유: 프로세스는 각각 독립된 메모리 공간을 가진다. 반면, 한 프로세스 내부의 스레드들은 메모리를 서로 공유하고 있다.
• 영향도: 스레드 하나가 오류로 종료되면 같은 프로세스 내의 다른 스레드들도 영향을 받을 수 있다. 하지만 프로세스 간에는 서로 영향을 주지 않는다.

🔧 Dart의 Isolate란?

일반적인 언어의 스레드와 달리, Dart는 Isolate 라는 개념을 사용한다. 이름되로 '격리된' 실행 단위를 뜻한다.

Isolate 특징

• 독립된 메모리 각 Isolate는 자신만의 메모리를 가진다. 스레드와 달리 메모리를 공유하지 않는다.
• 싱글 스레드 기반 기본적으로 Flutter 앱은 하나의 Main Isolate에서 실행된다. 이 안에서 이벤트 루프가 돌아가며 UI를 그리고 사용자의 입력을 처리한다.
• 통신 방식 메모리를 공유하지 않기 때문에, 서로 데이터를 주고받으려면 메시지 패싱 방식을 사용해야 한다.

⚒ 왜 스레드 대신 Isolate를 쓸까?

일반적인 멀티 스레드 환경에서는 여러 스레드가 동시에 같은 메모리에 접근할 때 발생하는 데이터 충돌을 막기 위해 Lock을 거는 복잡한 과정이 필요하다. 하지만 Isolate는 메모리를 아예 분리해버림으로써 이런 복잡함을 없애고 성능 최적화를 이룬다.

📭 대칭키 암호화

• 암호화와 복호화에 동일한 키를 사용하는 방식
• 방식: 송신자와 수신자가 동일한 하나의 비밀키를 공유한다.
• 장점: 속도가 빠르다.
• 단점: 키를 안전하게 전달하기 어렵다. / 사용자가 늘어날수록 관리해야 할 키의 개수가 기하급수적으로 늘어난다.

📫 비대칭키 암호화

• 암호화와 복호화에 서로 다른 키를 사용하는 방식
• 방식: 모든 사용자는 공개키와 개인키 한 쌍을 가진다.
  • 공개키: 누구나 알 수 있는 키
  • 개인키: 본인만 알고 있는 키
• 장점: 키를 안전하게 전달하기 쉽다.
• 단점: 속도가 느리다.

🗂 장단점 비교

📚 HTTPS와 암호화의 결합

HTTPS는 대칭키의 속도와 비대칭키의 안전한 키 전달이라는 장점만을 결합한 '하이브리드 암호화' 방식을 사용한다.

🖇 연결 과정 (SSL/TLS)

1. 공개키 전달

서버는 자신의 비대칭키(공개키)가 담긴 인증서를 클라이언트에게 보낸다.

2. 대칭키 생성 및 암호화

클라이언트는 데이터를 빠르게 암호화할 때 쓸 대칭키(세션키)를 무작위로 생성한다. 이 대칭키를 서버의 공개키로 암호화하여 서버에 보낸다

3. 키 복호화

서버는 오직 자신만 가진 비대칭키(개인키) 로 암호화된 대칭키를 복호화하여 안전하게 꺼낸다.

4. 데이터 통신

이제 서버와 클라이언트는 서로 공유된 동일한 대칭키를 사용하여 실제 데이터를 암호화/복호화하며 빠르게 통신한다.

요약

비대칭키는 대칭키를 안전하게 공유하기 위한 수단으로 쓰이고, 실제 데이터 통신은 대칭키가 담당한다.

◾️ 대칭키 암호화 알고리즘

대칭키는 금고와 하나의 열쇠 넣을 때(암호화)와 열 때 (복호화) 같은 열쇠를 쓴다.

AES (Advanced Encryption Standard)

• 특징: 현재 전 세계에ㅔ서 가장 많이 쓰이는 알고리즘 정교하고 튼튼한 최신형 도어락 같은 느낌
• 장점: 매우 빠르고, 보안성도 강력하다. 컴퓨터 CPU 안에 AES 처리를 돕는 부품이 따로 있을 정도라서 대용량 파일(영화, 게임 등)을 암호화 할 때 필수이다
• 단점 : 열쇠(비밀키)를 상대방에게 전달하다가 중간에 도둑맞으면.. ㄲ끝.이다

DES / 3DES (Data Encryption Standard)

• 특징: 과거의 표준으로 많이 사용했으나 지금은 보안이 취약해져서 잘 쓰이지 않음

◽️ 비대칭키 암호화 알고리즘

비대칭키는 '자물쇠(공개키)와 열쇠(개인키)' 세트이다. 누구나 내 자물쇠를 가져가서 상자를 잠글 수는 있으나 열 수 있는 열쇠는 오직 나만 가지고 있다.

RSA (Rivest-Shamir-Adleman)

• 특징: 공개키 암호화에서 가장 유명한 알고리즘이다. 아주 큰 숫자를 소인수분해하는 것이 어렵다는 수학적인 원리를 이용한다. ($15 = 3 \times 5$ 는 쉽지만, 수백 자리 숫자를 소인수분해하려면 슈퍼컴퓨터로도 오래 걸린다.)
• 용도: 주로 아주 작은 데이터(대칭키를 암호화할 때)나 디지털 서명에 사용된다.

ECC (Ellipptic Curve Cryptography)

• 특징: 타원곡선 그래프를 이용한 최신 알고리즘 RSA보다 훨씬 작고 가벼우면서 보안력은 더 강한 '스마트한 열쇠'
• 장점: RSA보다 키의 길이가 훨씬 짧다. 스마트폰처럼 리소스가 제한된 기기에서 웹사이트 접속할 때 성능을 높여주기 때문에 최근 HTTPS에서 아주 선호된다.

HTTP와 HTTPS의 차이점은 무엇인가?

HTTP란?

HTTP는 Hyper Text Transfer Protocol의 약자로, 암호화 과정 없이 데이터를 인터넷으로 전송하는 프로토콜입니다. 누구나 쉽게 볼 수 있는 상태

HTTPS란?

HTTPS는 Hyper Text Transfer Protocol Secure의 약자로, HTTP 프로토콜에 보안 기능을 추가한 것 HTTPS를 사용하면 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화 된다. 기존의 HTTP 프로토콜에 SSL/TLS 프로토콜을 더해 데이터 전송의 보안을 강화한 통신이다.

• TLS : Transport Layer Security의 약자로, SSL의 후속 프로토콜
• SSL : Secure Sockets Layer의 약자로, HTTPS를 구현하기 위한 프로토콜

  SSL/TLS는 HTTPS를 사용하기 위한 안전한 보안 채널을 생성해주는 포로토콜

HTTP와 HTTPS

HTTP는 암호화가 없어 보안에 취약한 반면, HTTPS는 안전하게 데이터를 주고 받을 수 있다. 하지만 암호화/복호화 과정이 필요하기 때문에 HTTP보다 속도가 느리다. 인증서 발급하고 유지하기 위한 추가 비용이 발생한다. 개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 노출이 되어도 괜찮은 단순한 정보 조회 등 만을 처리하고 있다면 HTTP를 이용하면 된다.

HTTPS의 특징

데이터 암호화

HTTPS는 전송되는 데이터를 암호화해서 제3자가 내용을 보더라도 내용을 알 수 없음

• 공개키 암호화 (비대칭키): 연결 초기 단계에서 대칭키를 안전하게 교환하기 위해 사용

• 대칭키 암호화: 실제 데이터 전송 시 사용, 속도가 빠름

  데이터 무결성

  전송 중에 데이터가 변조되었는지 확인하는 기능. 누군가 수정했다면 수신 측에서 감지하고 해당 데이터 폐기

  서버 인증

  클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 확인

TCP 3-Way Handshake

핸드셰이크로 보장하는 것

• 양쪽 모두 통신 가능 확인
• 데이터 순서 보장
• 손실 시 재전송 가능
• 신뢰성 있는 연결 수립

HTTP - 80포트 사용 HTTPS - 443포트 사용

통신 과정

1. 사용자가 로그인 정보 입력 (로그인 요청)
2. 서버 검증하고 인증서 생성
3. CA의 비밀키로 인증서 서명
4. 서버에 서명된 인증서 발급
5. 웹 브라우저에 CA의 공개키 전달
6. 서버(웹사이트) 접속 요청
7. 발급받은 인증서 전달
8. CA의 공개키로 인증서 검증
9. 서버 공개키로 대칭키 암호화
10. 서버로 암호화한 대칭키 전송
11. 서버 비밀키로 대칭키 복호화
12. 대칭키를 이용하여 암호화된 정보를 주고받는다

피드백

• 네이버로 HTTP/HTTPS 통신을 했을 때 어떻게 데이터 통신이 되는지 (암호화 되는지) 사용자/서버 예시로 들어서 naver에 로그인하는 과정을 설명해보기
• 공개키/개인키 암호화 방식에 대해 자세하게 공부해보기

정렬 알고리즘에 대해 자세하게 공부해보자! 어제 공부한 내용 다시 한번 공부하면서 더 잘 이해할 수 있도록 그래프를 그려보며 공부해봤다

🚥 정렬 알고리즘

정렬 알고리즘 무작위로 나열된 데이터 집합을 특정 기준(오른차순 또는 내림차순)에 따라 일정한 순서로 재배열하는 일련의 과정을 의미한다.

데이터의 형태에 따라 숫자 크기순, 문자 사전순 등으로 정렬할 수 있으며, 효율적인 정렬은 이후의 데이터 처리 속도를 결정짓는 핵심적인 선행 단계이다.

📄 정렬 알고리즘을 사용하는 핵심 이유

단순히 보기 좋게 나열하는 것을 넘어, 정렬은 시스템의 전반적인 성능 최적화를 위해 필수적이다.

📕 탐색 성능의 극대화

데이터가 정렬되어 있지 않으면 특정 값을 찾기 위해 처음부터 끝까지 확인하는 선형 탐색을 해야한다. 하지만 정렬된 데이터에서는 이진탐색을 사용할 수 있어 탐색 속도가 빨라진다.

• 미정렬 상태 : $O(n)$
• 정렬 상태 : $O(\log n)$

📗 데이터 처리 효율성 향상

• 중복 제거 : 정렬된 데이터에서는 인접한 요소끼리 비교하여 중복된 항목을 쉽게 찾아낼 수 있다.
• 그룹화: 특정 기준에 따라 데이터를 모아서 분석하거나 통계를 낼 때 정렬이 되어 있으면 처리가 간결해진다.

📘 다른 알고리즘의 기반 기술

많은 효율적인 알고리즘들이 데이터가 정렬되어 있음을 전제로 작동한다. 예를 들어, 두 데이터 집합의 교집합을 구한거나 최솟값/최댓값을 빠르게 추출해야 하는 로직에서 정렬은 필수적인 전처리 과정이다.

정렬 알고리즘을 선택할 때는 단순히 속도뿐만 아니라, 시간 복잡도($O(n \log n)$ vs $O(n^2)$)와 공간 복잡도, 그리고 동일한 값의 상대적 순서가 유지되는지 여부인 안정성(Stability)을 종합적으로 고려해야 한다!

📚 정렬의 기준에 따라 정리해보자

📕 안정성 기준

값이 같은 데이터가 있을 때, 정렬 전의 순서가 유지되는가?

• 안정 정렬: 병합 정렬, 삽입 정렬
  • 안정 정렬을 쓴다면 가격이 같은 상품들끼리 여전히 주문 일자순을 유지할 수 있다.
• 불안정 정렬 : 퀵정렬, 힙 정렬
  • 불안정 정렬을 쓴다면 가격이 같은 상품들의 주문 일자 순서가 뒤죽박죽 섞일 수 있다.

📗 제자리 정렬

데이터 정렬을 위해 추가적인 메모리 공간이 얼마나 필요한가?

• 제자리 정렬 : 퀵정렬, 힙 정렬, 선택 정렬
• 제자리 정렬이 아닌 것 : 병합 정렬

아주 작은 센서 장치에서는 추가적인 메모리를 사용하는 병합 정렬보다는 기존 배열 내에서 위치만 바꾸는 제자리 정렬 방식이 훨씬 유리하다.

📘시간 복잡도 기준

데이터 양이 많아질 때 얼마나 정체되는가?

• 단순한 정렬 $O(n^2)$ : 거품 정렬, 선택 정렬
• 효율적인 정렬 $O(n \log n)$ : 퀵 정렬, 병합 정렬

데이터가 적을 때 : 알고리즘이 복잡한 퀵 정렬보다 오히려 단순한 삽입 정렬이 더 빠를 수 있다. 실제로 많은 표준 라이브러리들이 데이터가 적을 땐 삽입 정렬을 섞어서 사용한다고 한다..!

데이터가 많다면? 반드시 $O(n \log n)$의 효율을 가진 정렬을 써야 시스템이 멈추지 않느다!

📙데이터의 성격 기준

데이터를 서로 비교하는가? 아니면 값의 특성을 이용하는가?

• 비교 정렬: 우리가 흔히 아는 대부분의 정렬 (퀵, 병합 등)
• 비비교 정렬 : 계수 정렬, 기수 정렬

수능 성적표를 처리할 때, 점수는 0점에서 100점 사이로 범위가 정해져 있다. 이럴 때는 숫자를 하나하나 비교하는 것보다 0점부터 100점까지의 칸을 미리 만들어두고 점수별로 개수를 세는 계수 정렬을 쓰면 $O(n)$이라는 압도적인 속도로 정렬이 끝난다.

$O(n)$ 상향 그래프

$O(n \log n)$ 상향 그래프

다음에는 시간 복잡도와 공간 복잡도에 따른 그래프를 그려봐야겠다..!

📶 정렬 알고리즘

정렬(Sorting)은 흩어져 있는 데이터를 정해진 기준에 따라 차례대로 나열하는 것이다. 예를 들어, [3, 1, 4, 2]라는 무작위 리스트를 1, 2, 3, 4 또는 4, 3, 2, 1로 만드는 과정이다.

어디에 사용되는가?

일상에서 사용되는 거의 모든 디지털 서비스에는 정렬 알고리즘을 사용하고 있다. 예를 들어서 쇼핑몰, SNS, 금융/은행, 내비게이션 등

낮은 가격순, 리뷰많은 순 최신 등록순 필터링 타임라인에 게시물을 최신순으로 나열하거나 좋아요가 많은 인기순으로 노출 거래 내역을 날짜별로 정리하거나 계좌 잔액 기준 정렬 등

🫧 버블 정렬

큰 원소가 뒤로 거품처럼 밀려 올라가는 모습에서 유래되었다. 인접한 두 원소를 비교하여 조건에 맞지 않으면 자리를 바꾸는 방식!

동작방식

1. 첫번째 원소와 두 번째 원소를 비교한다.
2. 앞의 원소가 더 크면 자리를 바꾼다.
3. 위의 행동을 마지막 원소까지 반복하면 가장 큰 원소가 맨 뒤로 고정된다.
4. 과정된 원소를 제외하고 다시 반복한다.

void bubbleSort(List<int> list) {
  int n = list.length;
  for (int i = 0; i < n - 1; i++) {
    for (int j = 0; j < n - i - 1; j++) {
      if (list[j] > list[j + 1]) {
        // 데이터 위치 교환
        int temp = list[j];
        list[j] = list[j + 1];
        list[j + 1] = temp;
      }
    }
  }
}

📌 선택 정렬

전체 원소 중 최솟값을 찾아 맨 앞에 있는 원소와 교체하는 방식이다

동작 방식

1. 주어진 리스트에서 최솟값을 찾는다.
2. 그 값을 맨 앞에 있는 값과 교체한다.
3. 맨 앞을 제외한 나머지 리스트에서 다시 최솟값을 찾아 두 번째 위치와 교체한다.
4. 이 과정을 리스트의 끝까지 반복한다

void selectionSort(List<int> list) {
  int n = list.length;
  for (int i = 0; i < n - 1; i++) {
    int minIndex = i;
    for (int j = i + 1; j < n; j++) {
      if (list[j] < list[minIndex]) {
        minIndex = j;
      }
    }
    // 최솟값을 현재 위치로 교환
    int temp = list[minIndex];
    list[minIndex] = list[i];
    list[i] = temp;
  }
}

🔖 삽입 정렬

두번째 원소부터 시작하여 그 앞의 정렬된 부분과 비교해서 자신의 위치를 찾아 삽입하는 방식이다. 손 안의 카드를 정렬하는 방식과 유사하다

작동 방식

1. 두 번째 원소를 'Key'로 잡고 이전 원소들과 비교한다.
2. Key가 이전 원소보다 작으면 이전 원소를 뒤로 밀어낸다
3. /Key가 들어갈 적절한 위치를 찾으면 그 자리에 삽입
4. 마지막 원소까지 반복

void insertionSort(List<int> list) {
  int n = list.length;
  for (int i = 1; i < n; i++) {
    int key = list[i];
    int j = i - 1;

    // key보다 큰 원소들을 오른쪽으로 한 칸씩 이동
    while (j >= 0 && list[j] > key) {
      list[j + 1] = list[j];
      j--;
    }
    list[j + 1] = key;
  }
}

알고리즘 비교 및 사용 이유

Flutter test 종류 3

1. 단위 테스트 (Unit tests)

단위 테스트는 메서드나 클래스의 동작을 확인, 특정 코드 단위를 분리하고 테스트 하기 때문에 다른 부분의 영향을 받지 않고 테스트할 수 있고 잘 작동하는지 확인 가능 목적: 특정 코드 단위의 동작을 확인해서 코드의 품질을 개선하고 버그를 방지

2. 위젯 테스트 (Widget tests)

위젯 테스트는 UI 요소의 개별 동작을 테스트, 버튼이 제대로 클릭되는지 텍스트 필드에 입력이 제대로 반영되는지 등을 확인함. 주로 위젯의 렌더링, 상태변화, 사용자 입력 등을 테스트

3. 통합 테스트 (Integration tests)

통합 테스트는 애플리케이션의 여러 부분을 통합하여 전체 애플리케이션의 동작을 테스트함. 여러 위젯이나 화면 간의 상호 작용 및 전환, 데이트 흐름 등을 테스트함. 실제 디바이스나 시뮬레이터를 실행해서 앱의 실제 환경에서 테스트를 진행함.

리펙토링한 테스트 코드

1. ui / home / home_screen_test.dart

-> HomeScreen 위젯이 날씨 데이터 로딩 상태에 따라 사용자가 보는 화면 (ui)가 잘 그려지는지 확인하기 위한 테스트 코드

• MockWeatherRepository 클래스는 WeatherRepository를 흉내 내는 가짜 클래스

• 테스트에서 사용할 가짜 저장소를 선언합니다. late는 나중에(setUp에서) 초기화하겠다는 의미

• setUp -> 각 테스트 케이스가 실행되기 전 항상 실행되는 블록! 매 테스트마다 새로운 객체를 생성해 테스트 간 간섭을 방지

• 테스트 할 위젯을 감싸서 반환하는 헬퍼 함수

• 여기서 Rivderpod의 핵심 기능인데요, 실제 Provider가 mockRepositoryfmf 바라보도록 덮어씌움

테스트 전용 주요 메서드

when(... ~ .thenAnswer)

만약 이 함수가 ~ 실행되면, 이렇게 대답해. 행동 정의 메서드 사용 방법은 when(.thenAnwser)

any()

어떤 인자 값이 들어오든 상관없이 매칭하겠다 라는 의미

tester.pubWidget()

주어진 위젯을 테스트 환경의 가상 화면에 렌더링

tester.pumpAndSettle()

애니메이션이나 연속적인 프레임 변화가 모두 멈출 때까지 반복해서 새로고침

2. ui / home / home_view_model_test.dart

-> 위에 살펴본 코드가 화면이 어떻게 보이는가를 확인하는 위젯 테스트였다면 이번 코드는 화면 없이 데이터 로직이 정확히 계산되고 상태를 잘 바꾸는가를 확인하는 단위 테스트

테스트 전용 주요 메서드

ProviderContainer

UI 없이 Provider의 상태를 관리하는 엔진. 단위 테스트의 핵심 도구임

addTearDown

테스트가 성공하든 실패하든 마지막에 꼭 실행해야 할 정리 작업을 등록

container.listen

상태가 변할 때마다 특정 동작을 수행하게 합니다. UI의 ref.listen과 비슷

verify(...).called(n)

"이 함수가 정말 n번 실행됐어?"라고 확인하는 감사(Audit) 기능

Mocking (가짜 객체 사용)의 이점

• 격리성: 실제 API 서버가 점검 중잉거나 인터넷이 안 되어도 테스트를 수행 할 수 있다.
• 속도 : 실제 네트워크 통신을 기다리지 않으므로 테스트 속도가 빠르다
• 통제 가능: 에러 상황이나 로딩 중인 상황 등 현실에서 재현하기 어려운 시나리오를 강제로 만들어서 테스트 할 수 있다.

Riverpod overrides의 이점

• 코드 수정 최소화: UI 코드 (HomeScreen)을 전혀 수정하지 않고, 테스트 코드에서만 데이터를 바꿔치기 할 수 있어 깔끔한 아키텍처를 유지해줍니다.

상태별 분리 테스트 이점

로딩 -> 성공 -> 에러 이어지는 사용자 경험(UX)의 모든 흐름을 코드로 확인할 수 있다. 나중에 UI 를 수정하더라도 테스트만 통과하면 기능은 여전히 잘 작동한다 라는 홗신을 가질 수 있다.

ProviderContainer 사용의 이점

• 순수 로직 집중: 화면 렌더링(버튼, 텍스트 등)에 신경 쓰지 않고 오직 데이터가 Loading -> Data 또는 Loading -> Error로 잘 변하는지만 확인할 수 있습니다. 리소스 절약: 위젯 테스트보다 훨씬 빠르고 가볍게 실행됩니다.

addTearDown의 이점

테스트마다 깨끗한 환경을 보장합니다. 이전 테스트에서 썼던 데이터가 다음 테스트에 영향을 주지 않도록 막아줍니다.

Flutter 테스트 작성 5단계 프로세스

① 테스트 목적 정의 (test 함수)

무엇을 테스트할지 명확한 문장으로 적어보기

② 환경 설정 및 가짜 객체 주입 (Arrange)

Mock(가짜) 객체를 만들고, 필요한 데이터를 미리 심어두기

사용 도구: Mocktail, Mockito, ProviderContainer

③ 동작 수행 (Act)

테스트 대상이 되는 기능을 실행하기

Unit Test: 함수 실행 (calculator.add(1, 2))

Widget Test: 위젯 렌더링 및 클릭 (tester.pumpWidget(), tester.tap())

④ 결과 확인 (Assert)

expect 함수를 사용해 실제 값(Actual)과 기대 값(Matcher)을 비교 expect(결과값, 3); expect(find.text('성공'), findsOneWidget);

⑤ 정리 (TearDown)

테스트가 끝난 후 사용한 리소스를 해제해주기 addTearDown(() => container.dispose());

반드시 해야 하는 경우: ProviderContainer, StreamController, TextEditingController, AnimationController 등을 생성했을 때.

안 해도 되는 경우: 단순히 숫자나 문자열을 계산하는 순수 함수(Pure Function) 테스트일 때.

초보자를 위한 작성 팁 💡

한 번에 하나만 테스트 하나의 test 블록 안에서 너무 많은 것을 검증하려고 하면, 실패했을 때 원인을 찾기 힘들다

실패하는 케이스도 테스트해보기 "정상 작동"뿐만 아니라 "에러가 났을 때 화면에 에러 메시지가 잘 뜨는지" 확인하는 것이 더 중요한 경우가 많다

테스트 가능한 코드(Testable Code)를 만들기 코드를 짤 때부터 "이걸 나중에 어떻게 테스트하지?"라고 고민하면 자연스럽게 의존성이 분리된 깨끗한 코드(Clean Code)가 나오게 되어있따~

Go Router Path Parameter

🏃‍➡️ 문제 상황

GoRouter 를 사용하여 상세 페이지(DetailPage)로 이동하는 라우팅을 설정하던 중, URL 파라미터인 id값을 int.parse()를 이용해 숫자로 변환하려고 시도했다. 하지만 시뮬레이터 화면에 FormatException: Invalid radix-10 number라는 레드 스크린(에러 화면)이 출력되었다..

📝 [원인 분석]

이때까지만 해도 git graph를 확인 시에 바꾼 것이 GoRouter 기능 추가한 것 밖에 없는데 id 값을 만져서 일어난 문제 같아서 id 값을 바꾼 곳을 유심히 살펴보았다. 🤔

그리고 에러를 확인해보니, state.pathParameters['id']를 통해 들어온 값이 "nHy0mO..."와 같은 문자열 String 형태였다.

int.parse() 함수는 숫자로 바꿀 수 없는 문자(알파벳 등)가 포함되어 있으면 즉시 에러를 발생시키며 앱의 흐름을 끊겨버린다.

📝 중간 검증: 왜 에러 페이지가 안 떴을까?

그리고 의문,,🤔 처음에는 에러가 발생했을 때 설정한 errorBuilder의 ErrorPage 가 보이지 않고 시스템 에러 화면이 떴댜.? 자세히 보니, 이유는 라우팅 자체의 실패가 아니라, builder 내부의 로직(Dart 코드)에서 예외가 발생했기 때문인 것으로 확인되었다.

혹시 몰라서 이것을 확인하기 위해 코드를 수정해보았다.

final id = int.tryParse(state.pathParameters['id'] ?? '');
if (id == null) {
  return ErrorPage();
}

int.tryParse()의 역할: 문자열을 숫자로 바꿀 수 없더라도 에러를 내지 않고 null을 반환

결과: 숫자가 아닌 값이 들어왔을 때 id가 null이 되어, 명시적으로 ErrorPage()를 리턴하게 되는 것을 확인.! 이 과정을 통해 "현재 들어오는 데이터가 숫자가 아니어서 발생하는 문제"임을 정확히 확신할 수 있었다

최종 해결: 데이터 타입의 유연한 활용

id 값을 굳이 int로 변환할 필요가 있는지 다시 검토해봤다 ,,🤔 DetailPage에서 해당 id를 단순히 식별자나 텍스트로만 사용한다면, 굳이 위험하게 형변환(Parsing)을 할 필요가 없는 것 같아서 String 타입으로 변환 받기로 하고 다시 수정했더니 에러 해결!

[최종 수정 코드]

GoRoute(
  path: 'detail/:id',
  builder: (context, state) {
    // 문자열 그대로 전달하여 에러 발생 가능성을 원천 차단
    final id = state.pathParameters['id'] ?? '';
    return DetailPage(todoId: id);
  },
),

🌟 해결 로직:pathParameters에서 받은 데이터를 그대로 String타입으로 사용. 🌟 결과: 복잡한 문자열로 된 ID 값도 정상적으로 전달되어 상세 페이지가 에러 없이 출력 확인.

💡 오늘의 교훈

데이터 타입의 엄격함 Dart는 정적 타입 언어이므로 String을 int로 바꿀 때는 항상 데이터의 형식을 확인하자

parse 보다는 tryParse 입력값이 확실한 숫자가 아니라면, 앱이 멈추는 것을 방지하기 위해 tryParse를 사용하는 것이 안전하다!

불필요한 형변환 지양 전달받은 데이터를 그대로 사용할 수 있다면, 가급적 원래의 타입(String)을 유지하는 것이 코드의 안정성을 높인다.

클린 아키텍처 마스터를 위해 기존에 MVVM 형식의 만들어진 날씨 앱을 클린 아키텍처를 사용해서 리펙토링 해보았다..! master..🌟

강의에 나온 이 그림을 보고 리팩토링을 시작했다 🌟

☔️ 리팩토링 작업 순서

1. DTO 분리

data/dto/weather_dto.dart 서버 데이터(JSON) 형식을 그대로 담는 객체

2. Entity 정의

domain/entity/weather.dart 앱 UI와 로직에서 실제로 사용할 순수 데이터 모델을 정리

3. Data Layer 작업

data/data_source/weather_data_source.dart data/data_source/weather_data_source_impl.dart 외부 API 통신 인터페이스 및 실제 구현체(http.Client 사용)

4. Repository 정의

domain/repository/weather_repository.dart 파일에서 도메인이 필요로 하는 데이터 기능을 인터페이스로 선언

5. Repository 구현

data/repository/weather_repository_impl.dart 파일에서 Data Source를 사용해 DTO를 받고, 이를 Entity로 변환하여 반환

6. Use Case

domain/use_case/fetch_weather_usecase.dart 파일에서 사용자의 핵심 동작(날씨 조회)을 단일 책임 클래스로 만들기

7. Provider 정의

main.dart 등 앱 전체의 각 레이어의 의존성을 주입하기 위한 Riverpod 설정 데이터 소스 Provider, 레포지토리 Provider, 유스케이스 Provider

8. ViewModel 연결

presentation/home/home_view_model.dart 파일에서 Use Case를 호출하여 UI 상태를 관리

9. UI 바인딩

presentation/ui/home_screen.dart 파일에서 ViewModel의 상태를 감시(watch)하여 화면에 렌더링

UI에 뿌려주기까지 성공..!

🌦 단계별 구현

▶️ 데이터의 구분 (DTO vs Entity)

서버에서 주는 데이터(DTO)와 내가 만드는 앱이 실제로 쓰고 싶은 데이터(Entity)를 분리한다.

DTO (Data Transfer Object) : 서버의 입맛 (JSON 구조와 동일)

class WeatherDto {
  final double temperature;
  final double windspeed;
  final double winddirection;
  final int weathercode;
  final int isDay;
  final String time;

  const WeatherDto({
    required this.temperature,
    required this.windspeed,
    required this.winddirection,
    required this.weathercode,
    required this.isDay,
    required this.time,
  });
  factory WeatherDto.fromJson(Map<String, dynamic> json) {
    return WeatherDto(
      temperature: (json['temperature'] as num).toDouble(),
      windspeed: (json['windspeed'] as num).toDouble(),
      winddirection: (json['winddirection'] as num).toDouble(),
      weathercode: json['weathercode'] as int,
      isDay: json['is_day'] as int,
      time: json['time'] as String,
    );
  }

  Map<String, dynamic> toJson() {
    return {
      'temperature': temperature,
      'windspeed': windspeed,
      'winddirection': winddirection,
      'weathercode': weathercode,
      'is_day': isDay,
      'time': time,
    };
  }
}

Entity : 앱의 입맛 (비지니스 로직에 최적화)

class Weather {
  final double latitude;
  final double longitude;
  final double temperature;
  final double windSpeed; 
  final int weatherCode;
  final bool isDay; 
  final String time;

  const Weather({
    required this.latitude,
    required this.longitude,
    required this.temperature,
    required this.windSpeed,
    required this.weatherCode,
    required this.isDay,
    required this.time,
  });
}

▶️ Data Source 레이어

외부 세계(API)와 직접 통신하는 계층

data/data_source/weather_data_source.dart

Interface

abstract interface class WeatherDataSource {
  Future<CurrentWeatherDto> fetchWeather(double lat, double lng);
}

data/data_source/weather_data_source_impl.dart

Implementation

class WeatherDataSourceImpl implements WeatherDataSource {
  final http.Client _client;

  WeatherDataSourceImpl([http.Client? client])
    : _client = client ?? http.Client();

  @override
  Future<CurrentWeatherDto> fetchWeather(double lat, double lng) async {
    final url = Uri.parse(
    ...생략

▶️ Repository 레이어

domain/repository/weather_repository.dart

abstract interface class WeatherRepository {
  Future<Weather> fetchWeather(double lat, double lng);
}

data/repository/weather_repository_impl.dart

class WeatherRepositoryImpl implements WeatherRepository {
  final WeatherDataSource _dataSource;

  WeatherRepositoryImpl(this._dataSource);

  @override
  Future<Weather> fetchWeather(double lat, double lng) async {
    final dto = await _dataSource.fetchWeather(lat, lng);
    return Weather(
 (... 생략)
     };
   }
 }

▶️ Use Case & Provider (실행 및 조립)

앱의 핵심 기능을 클래스화하고 의존성을 주입하기 domain/use_case/fetch_weather_usecase.dart

class FetchWeatherUsecase {
  final WeatherRepository _repository;

  FetchWeatherUsecase(this._repository);

  Future<Weather> call(double lat, double lng) {
    return _repository.fetchWeather(lat, lng);
  }
}

main.dart (Provider 정의)
// 데이터 소스 Provider
final weatherDataSourceProvider = Provider<WeatherDataSource>((ref) {
  return WeatherDataSourceImpl();
});

// 레포지토리 Provider
final weatherRepositoryProvider = Provider<WeatherRepository>((ref) {
  return WeatherRepositoryImpl(ref.read(weatherDataSourceProvider));
});

// 유스케이스 Provider
final fetchWeatherUsecaseProvider = Provider<FetchWeatherUsecase>((ref) {
  return FetchWeatherUsecase(ref.read(weatherRepositoryProvider));
});

▶️ Presentation Layer

presentation/home/home_view_model.dart

final homeViewModelProvider = AsyncNotifierProvider<HomeViewModel, Weather>(HomeViewModel.new);

class HomeViewModel extends AsyncNotifier<Weather> {
  @override
  Future<Weather> build() {
    return _fetchWeather();
  }

  Future<Weather> _fetchWeather() {
    final useCase = ref.read(fetchWeatherUsecaseProvider);
    return useCase.call(37.57, 126.98);
  }

  Future<void> fetchWeather() async {
    state = const AsyncValue.loading();
    state = await AsyncValue.guard(() => _fetchWeather());
  }
}

presentation/ui/home_screen.dart

Widget build(BuildContext context, WidgetRef ref) {
  final weatherState = ref.watch(homeViewModelProvider);

  return Scaffold(
    body: weatherState.when(
      data: (weather) => Text('기온: ${weather?.temperature}'),
      loading: () => CircularProgressIndicator(),
      error: (e, st) => Text('에러 발생'),
    ),
  );
}

🌤 레이어 작업을 하는 이유

• Data Layer 데이터를 어떻게 가져올 것인가? (네트워크, 로컬 DB 등)
• Domain Layer 우리 앱은 어떤 일을 하는가? (가장 중요하며 순수해야 함)
• Presentation Layer 사용자에게 어떻게 보여줄 것인가? (UI, 상태 관리 등)

처음에는 파일 개수도 많아지고 구조가 복잡해 보여서 과연 이게 효율적인가 라는 의문이 들었지만 작업을 마치고, TIL 작성 하려고 다시 보니 각 클래스가 자신의 일만 명확하게 수행하는 모습을 확인할 수 있었다아

🌞 왜 클린 아키텍처인가?

⚡️ 도메인 중심 설계 (Domain-Centric)

외부 환경(API, DB, UI)이 어떻게 변하든 앱의 핵심 로직(날씨를 가져온다)은 변하지 않아야 할 것..! 모든 데이터 흐름은 정해진 통로 (Repository -> UseCase)를 거쳐야 되니까 코드가 예측 가능할 거 같ㅌ다. 도메인을 가장 안쪽에 보호함으로써 외부의 변화가 내부로 침투할 수 없는 구조를 만들었다.

⚡️ 의존성 역전 (Dependency Inversion)

인터페이스를 통해 "무엇을 할지"만 정의하고, "어떻게 할지"는 외부에서 주입한다. 덕분에 테스트가 쉬워지고 코드 간의 결합도가 낮아진다.

🌟 아직 테스트 작업을 못 해봤다.. 테스트에 용이한 클린 아키텍처지만 파일 분리하고 layer 작업 후 바로 에러 잡기 급급했던 거 같다. 다음에는 테스트도 함께 사용해서 클린 아키텍처 마스터를.. 해 ㅂ

오늘의 공부 내용 이미지 💫

⛄️ SOLID 원칙이란?

❄️ SRP: 단일 책임 원칙 (Single Responsibility Principle)

클래스가 너무 많은 일을 하면 버그가 발생했을 때 수정하기 어렵고, 코드의 가독성이 떨어지기 때문에 하나의 클래스에 하나의 책임만 부여한다

🛵 배달 앱으로 이해하는 SOLID 원칙

1. SRP (단일 책임) "요리사는 요리만, 라이더는 배달만"

직원이라는 클래스가 요리도 하고, 배달도 하고, 결제도 다 하는 상황에 배달 방식이 오토바이에서 자전거로 바뀌었는데, 갑자기 요리하는 코드까지 건드려야 하는 상황이 생겼을 경우,

해결: 요리사 클래스, 라이더 클래스, 결제원 클래스로 각각 나누자. 자기 할 일만 잘하면 된다!

2. OCP (개방-폐쇄) "메뉴 추가는 자유롭게, 주문 시스템은 그대로"

새로운 메뉴로 '마라탕'이 추가가 되었는데, 메뉴가 추가될 때마다 주문 앱의 전체 코드를 다시 짜야 한다면..?

해결: 메뉴라는 큰 틀(인터페이스)을 만들다. 치킨이든 마라탕이든 메뉴라는 틀만 지키면 주문 시스템은 수정 없이 그대로 새 메뉴를 받아들일 수 있다..!

3. LSP (리스코프 치환) "어떤 탈것이든 배달은 가능해야 한다"

배달 수단이라는 부모가 있고, 자식으로 오토바이와 자전거가 있을 경우, "오토바이는 되는데 자전거는 배달을 못 해!"라고 프로그램이 멈춰버리면 안 된다.

해결: 부모인 배달 수단 자리에 자전거를 넣어도 배달 로직은 정상적으로 '이동'하고 '도착'해야 한다.

4. ISP (인터페이스 분리) "손님 화면에 '주문 수락' 버튼을 넣지 마라"

배달 앱 인터페이스 하나에 '주문하기', '리뷰쓰기', '주문 수락하기', '음식 완료 알림' 버튼을 다 넣었을 경우, 손님은 '주문 수락' 기능을 전혀 안 쓰는데 이 버튼 때문에 화면이 복잡해졌다. 이럴 때 해결은?

해결: 손님용 인터페이스(주문, 리뷰)와 사장님용 인터페이스(수락, 알림)를 따로 분리해보자

5. DIP (의존성 역전) "결제 방식은 언제든 갈아 끼울 수 있어야 한다"

앱이 '네이버페이' 결제 시스템에 직접 납땜(직접 연결)되어 있었을 경우, 갑자기 '카카오페이'로 바꿔야 하면 앱을 거의 새로 만들어야 하는 상황이 생긴다. 이럴 때?

해결: 중간에 결제 시스템이라는 플러그(어댑터)를 둡니다. 앱은 플러그에만 연결하고, 거기에 네이버페이를 꽂든 카카오페이를 꽂든 앱은 상관없게 만드는 것 이다!

❄️ 클린 아키텍처와 연결하기

클린 아키텍처는 이 SOLID 원칙들을 층층이 쌓아 올린 것과 같다. 가장 중요한 것은 비즈니스 로직(배달 주문)을 가운데 보호하는 것이 핵심!!

결제 시스템 (DIP 원칙 적용)

// 1. 추상화 (DIP: 플러그 만들기)
// 어떤 결제 수단이든 이 규칙을 따라야 함
abstract class PaymentGateway {
  void pay(int amount);
}

// 2. 저수준 모듈 (실제 구현체: 플러그에 꽂을 제품들)
class KakaoPay implements PaymentGateway {
  @override
  void pay(int amount) => print("카카오페이로 $amount원 결제");
}

class TossPay implements PaymentGateway {
  @override
  void pay(int amount) => print("토스페이로 $amount원 결제");
}

// 3. 고수준 모듈 (Clean Architecture의 UseCase: 배달 주문 로직)
// SRP: 주문하는 일만 책임짐
class OrderUseCase {
  final PaymentGateway paymentMethod; // DIP: 구체적인 페이가 아닌 '플러그'에 의존

  OrderUseCase(this.paymentMethod);

  void completeOrder(int price) {
    // 주문 완료 로직...
    paymentMethod.pay(price);
  }
}

왜 이렇게 쓸까?

변경에 강함 내일 당장 사장님이 "우리 이제 토스페이만 쓰자!"라고 해도 OrderUseCase 코드는 한 줄도 고칠 필요가 없다. (OCP)

테스트하기 좋음 실제 결제를 안 일으키고 가짜 결제(Mock) 플러그를 꽂아서 주문 로직이 잘 작동하는지 테스트할 수 있다.

오늘의 공부 내용 이미지 💫

🛸 클린 아키텍처

소프트웨어의 핵심 로직을 UI, 데이터베이스, 프레임워크와 같은 외부 요소로부터 완전히 분리하여 어떤 환경에서도 독립적으로 동작 가능하고 테스트가 가능한 구조로 만드는 것이 핵심이다 🌟

🔹 핵심 구조

핵심 구조는 전에 팀프로젝트로 진행한 DoranDoran APP으로 기억하기 쉽도록 정리해봤다

1. Entities : 순수 데이터 본질

가장 안쪽 계층이고 앱의 핵심 데이터 구조

• 예시 : ChatMessage 클래스
• 내용 : 메시지 보낸 내용, 보낸 사람 ID, 전송 시간 등 아주 기본적인 정보만 담는 곳
• 특징 : 이 코드는 Firebase를 쓰든 내 서버를 쓰든 절대 변하지 않는 순수한 Dart 클래스

class ChatMessage {
  ChatMessage ({
   required this.id,
   required this.text,
   required this.creatAt,
   });

   final String id;
   final String text;
   final DateTime creatAt;
   }

2. Use Case : 구체적인 기능 로직

사용자가 하려는 '행동' 그 자체 정의하는 것

• 예시 : SendMessage
• 내용 : 사용자가 앱에서 수행하려는 구체적인 행위(비지니스 로직)를 정의한다.
• 특징 : 데이터를 어떻게 가져오는지 모르고, 단지 저장하라는 명령만 내린다. 엔티티를 사용해서 앱의 기능을 수행하며 데이터가 어떻게 흐를지 결정한다.

class SendMessage {
  SendMessage(this.repository);

  final ChatRepository repository;

  Future<void> execute(String text) async {
    if (text.isEmpty) return;
    await repository.saveMessage(text);
    }
  }

3. Interface Adapters : MVVM의 ViewModel

내부(Use Case)와 외부(UI/DB)를 연결해주는 통역사

• 예시 : ChatViewModel
• 내용 : 사용자가 화면에서 버튼을 누르면 유즈케이스를 실행시키고, 결과가 오면 화면에 보여줄 '상태'를 바꾼다
• 기존 MVVM과 연결 : 이 계층이 MVVM의 ViewModel과 Repository 인터페이스가 위치하는 곳
• 주로 사용 및 역할 : Riverpod, Provider, 등 여기서 상태 관리를 담당함. 외부 데이터(JSON 등)를 내부에서 사용하기 좋은 엔티티 형태로 바꾸거나 그 반대의 역할을 수행한다.

4. Frameworks & Drivers : 실제 기술 도구

가장 바깥 쪽으로 실제 화면을 그리고 데이터를 전송하는 도구

• 예시 : ChatView(UI), FirebaseChatRepository (구체적인 DB 구현), HTTP 클라이언트 등 실제 도구들이 위치함
• 내용 : Flutter의 ListView로 채팅창을 그리거나, Firebase SDK를 사용해 데이터를 실제로 날리는 코드가 위치한다.
• 특징 : 언제든 교체될 수 있는 영역이다.

🛩 MVVM과 클린 아키텍처 🛸

기존의 MVVM은 주로 화면(UI)를 어떻게 깔끔하게 관리할까에 집중했다면, 클린 아키텍처는 앱 전체의 코드가 Framework에 오염되지 않고 어떻게 깔끔하게 격리할까? 에 집중한다.

🔸 ViewModel의 일거리

기존 MVVM에서는 ViewModel이 API를 호출하고, 데이터를 가공하고, 에러를 처리하는 등 너무 많은 일을 했다면 클린 아키텍처를 통해 이 복잡한 로직을 Use Case가 가져간다.

• 기존 : ViewModel ->API 호출 -> 데이터 변환 -> 화면 갱신
• 이후 : ViewModel -> Use Case 실행 -> 결과 받아서 화면 갱신

🔸 기존 MVVM 방식 (ViewModel이 모든 일을 할 때)

기존에는 ViewModel이 화면 상태 관리 + 데이터 로직 + 외부 서버 통신을 모두 진행했음, 코드가 한 곳에 모여 있어서 편했지만, 기능이 늘어날수록 ViewModel이 커진다는 문제점이 있다.

class ChatViewModel extends StateNotifier<ChatState> {
  final FirebaseFirestore _firestore = FirebaseFirestore.instance; // 직접 외부에 의존

  // 메시지 전송 로직이 ViewModel 안에 직접 들어있음
  Future<void> sendMessage(String text, String userId) async {
    if (text.isEmpty) return; // 비즈니스 로직 1 (빈 메시지 체크)

    try {
      // 비즈니스 로직 2 (데이터 구조 생성 및 저장)
      await _firestore.collection('messages').add({
        'text': text,
        'senderId': userId,
        'createdAt': DateTime.now(),
      });
    } catch (e) {
      state = state.copyWith(errorMessage: "전송 실패!");
    }
  }
}

예시) Firebase가 아닌 다른 DB로 바꾼다면?... ChatViewModel의 코드를 통째로 고쳐야함

🔸 클린 아키텍처 + MVVM (역할을 분담할 때)

클린아키텍처를 적용하면 코드가 세 덩어리로 쪼개진다. 무엇을(Entity), 어떻게(Use Case), 어디에(Repository)로 분리하는 것이 핵심!!

① Domain 계층 (가장 안 쪽: 순수로직)

// 1. Entity: 메시지의 본질
class Message {
Message({
required this.text, 
required this.senderId, 
required this.time
});
  final String text;
  final String senderId;
  final DateTime time;

}

// 2. Use Case: 메시지 전송이라는 '행위' 그 자체
class SendMessageUseCase {
  final ChatRepository repository; // '도구'가 아닌 '기능'의 이름에 의존
  SendMessageUseCase(this.repository);

  Future<void> execute(String text, String userId) async {
    if (text.isEmpty) return; // 비즈니스 로직은 여기서 처리!
    final message = Message(text: text, senderId: userId, time: DateTime.now());
    await repository.saveMessage(message);
  }
}

② Data 계층 (바깥쪽: 실제 기술)

Firebase를 쓰든 로컬 DB로 쓰든 여기서 구현한다

// 3. Repository Implementation: 실제 Firebase로 저장하는 상세 방법
class FirebaseChatRepository implements ChatRepository {
  @override
  Future<void> saveMessage(Message msg) async {
    await FirebaseFirestore.instance.collection('messages').add({
      'text': msg.text,
      'senderId': msg.senderId,
      'time': msg.time,
    });
  }
}

③ Presentation 계층 (바깥쪽: MVVM의 ViewModel)

이제 ViewModel은 유즈케이스를 호출만하고 화면에 보여줄 상태만 관리한다.

// 4. ViewModel: 많이 깔끔해짐
class ChatViewModel extends StateNotifier<ChatState> {
  final SendMessageUseCase _sendMessageUseCase; // 유즈케이스를 주입받음

  ChatViewModel(this._sendMessageUseCase) : super(ChatState());

  Future<void> onSendPressed(String text, String userId) async {
    // ViewModel은 "전송해줘!"라고 시키기만 함
    await _sendMessageUseCase.execute(text, userId);
  }
}

▪️정리하자면?

MVVM은 View를 위한 모델을 만드는 것, 클린 아키텍처는 도메인을 중심으로 모든 것을 분리하는 시스템이다!

REST API

오늘의 공부 이미지 💫

👉🏼👈🏼 REST API ?

REST API는 HTTP 프로토콜의 장점을 최대한 활용하여, 서버에 있는 자원(Resource)에 접근하는 방식을 정의한다.

• 자원(Resource): 서버에 저장된 데이터(예: 사용자 정보, 게시글, 이미지 등)를 의미한다.
• 행위(Verb): HTTP 메서드(GET, POST 등)를 통해 자원에 무엇을 할지 결정한다.
• 표현(Representation): 자원의 상태를 JSON 같은 형태로 전달한다.

💾 주요 구성 요소 (HTTP 메서드)

▪️ GET 데이터 조회: 서버에서 정보를 가져올 때 사용함 ▪️ POST 데이터 생성: 서버에 새로운 정보를 등록할 때 사용함 ▪️ PUT 데이터 전체 수정: 기존 정보를 새로운 정보로 완전히 교체할 때 사용함 ▪️ PATCH 데이터 일부 수정: 기존 정보 중 특정 부분만 바꿀 때 사용함 ▪️ DELETE 데이터 삭제: 서버의 특정 정보를 삭제할 때 사용함

💾 REST API 왜 사용할까?

• 독립성: 클라이언트(앱)와 서버가 서로 어떻게 구현되어 있는지 몰라도 상관없다 API 명세만 맞으면 통신이 가능하기 때문!
• 범용성: HTTP를 사용하기 때문에 웹이나 모바일 기기 등 어디서나 사용 가능하다
• 확장성: 서버 구조를 변경해도 API 주소만 유지된다면 클라이언트는 영향받지 않는다

💾 REST API 언제 사용할까?

• Flutter 앱에서 서버에 저장된 사용자 프로필 정보를 가져올 때
• 쇼핑몰 앱에서 상품 목록을 불러오거나 주문을 전송할 때
• 기상청 서버로부터 실시간 날씨 데이터를 받아올 때

🕹 사용방법

// 1. 서버 주소(URL) 정의
var url = Uri.parse('https://api.example.com/users/1');

// 2. GET 요청 보내기
var response = await http.get(url);

// 3. 응답 처리
if (response.statusCode == 200) {
  // 성공 (200 OK)
  print('데이터: ${response.body}');
} else {
  // 실패
  print('에러 발생: ${response.statusCode}');
}

⌨️ 주요 상태 코드

• 200 - OK 요청 성공.
• 201 - Created 요청 성공. 새로운 리소스가 생성되었을 때
• 400 - Bad Request 요청 실패. 클라이언트가 요청 Body에 잘못된 데이터 줬을때
• 401 - Unauthorized 인증되지 않음. 로그인 안되었을때.(로그인 후 Header에 정보 넣어줘야함)
• 403 - Forbidden 리소스 접근 금지됨. 로그인 했지만 접근할 권한 없을때. 예를들어 다른 회원의 블로그글 수정하려할 때
• 404 - Not Found 리소스 없음. URL이 잘못되었거나 URL은 정상이지만 서버 내 데이터가 없을 때
• 405 - Method Not Allowed 메소드 잘못 보냈을때
• 409 - Conflict 요청 수행 시 서버에서 충돌 날 때. 예를들어 회원가입 시 id에 중복된 아이디로 회원가입 시도할 경우
• 500 - Internal Server Error 서버에서 에러 났을때

이번 주 학습 요약

이번 주는 MVVM 패턴 기반으로 Riverpod과 Firebase를 연동해서 실시간 채팅 기능까지 구현해봤다. 데이터 흐름을 이해하고 UI와 로직을 분리하는 과정에서 발생한 다양한 트러블슈팅을 통해 설계의 중요성을 배웠다

• 프로젝트: 위치 기반 채팅 앱 '도란도란'
• 내가 맡은 주요 기능: 실시간 채팅 시스템 구축
• 사용 기술: Flutter, Dart, Riverpod(State Management), Firebase Firestore(NoSQL)
• 핵심 키워드: MVVM 패턴, Stream, AsyncValue, 모델링(Data Modeling)

Trouble Shooting

AsyncValue.when 매개변수 누락 문제

[문제 상황]

chatRoomsAsync.when을 사용하여 실시간 채팅방 목록을 불러오려 했으나, 컴파일 에러가 발생했다

에러 메시지: The named parameter 'error' is required, but there's no corresponding argument.

[원인 분석]

Riverpod의 AsyncValue는 비동기 데이터를 처리할 때 Data(데이터 로드 성공), Error(에러 발생), Loading(로딩 중)이라는 세 가지 상태를 반드시 모두 처리해주어야 했다. 스크린샷에서는 data 부분만 작성되어 있어 나머지 필수 상태가 누락된 것이 원인으로ㅓ 확인했다

[해결 방법]

error와 loading 콜백을 추가하여 모든 상태에 대응하도록 코드를 수정해서 해결 완료!

body: chatRoomsAsync.when(
  data: (rooms) => _buildRoomList(rooms),
  error: (err, stack) => Center(child: Text('에러 발생: $err')), // 에러 상태 추가
  loading: () => Center(child: CircularProgressIndicator()), // 로딩 상태 추가
),

Widget/Function 매개변수 개수 불일치

[문제 상황]

ListView 내에서 개별 아이템을 렌더링하기 위해 item(context, room)을 호출했으나 에러가 발생했다

에러 메시지: Too many positional arguments: 1 expected, but 2 found.

[원인 분석]

작성된 item 위젯(또는 함수)은 매개변수를 1개만 받도록 설계되어 있었으나, 실제 호출 시에는 context와 room 2개를 전달하고 있었던 걸로 확인되었다

[해결 방법]

item 함수의 정의 부분을 확인하여 매개변수를 (context, room) 두 개를 받도록 수정하거나, 호출부에서 불필요한 인자를 제거하여 일치시켰다ㅣ

Model과 Firestore 데이터 불일치 (Required Parameter)

[문제 상황]

Firestore에서 데이터를 가져와 ChatRoomModel 객체로 변환하는 fromMap 팩토리 생성자에서 에러가 발생했었다

에러 메시지: The named parameter 'des' is required, but there's no corresponding argument.

[원인 분석]

ChatRoomModel 정의부에서 des(설명) 필드를 required로 설정했지만, fromMap 함수 내에서 해당 값을 할당해주지 않았다. 데이터베이스(Entity) 구조와 앱 내부 모델(Model) 구조 사이의 차이를 간과한 결과였던 걸로 확인했다

[해결 방법]

fromMap 생성자에서 des 값을 맵 데이터로부터 할당하거나, 기본값을 제공하도록 수정해서 해결했다!

factory ChatRoomModel.fromMap(Map<String, dynamic> map, String id) {
  return ChatRoomModel(
    roomId: id,
    title: map['title'] ?? '',
    des: map['des'] ?? '설명 없음', // 누락된 필드 추가
    // ... 나머지 필드들
  );
}

새롭게 깨달은 점

• Entity vs Model 데이터베이스에 저장되는 형태(Entity)와 UI에서 사용되는 형태(Model)를 분리하여 관리하는 이유를 이해했다. 이는 데이터 구조가 변경되어도 UI 로직에 미치는 영향을 최소화할 수 있다.

• 실시간 데이터 처리 Stream과 snapshots()를 활용해 Firestore의 데이터 변화를 실시간으로 감지하고 UI를 자동 갱신하는 Riverpod의 강력함을 경험했다.

• 꼼꼼한 에러 체크 Dart 컴파일러의 에러 메시지는 매우 정확합니다. "Required"라는 단어가 보이면 누락된 값이 없는지 모델 클래스부터 확인하는 습관을 갖게 되었다!

오늘은 정말 정신없이 chatPage UI 구현하느라고 TIL 작성을 못 했다... 그래도 오늘 작업한 내용은 사진으로 남겨보려고 한다..

이제 파일 정리가 안 되면 벌써 짜증난다... 어디어디어디어디로

내일은.. 더....

이번 한 주도 마찬가지로 빠르게 지나갔다. 벌써 1월의 반을 달려왔다... 🏃🏻‍♀️‍➡️ 하루하루 눈 깜짝하면 점심 먹을시간.. 눈 깜짝하면 저녁 먹을 시간.. 이렇게 하루가 지나간다 🥱 소듕한 시간.. 이번 한 주 배운 내용 간단하게 정리! 새로 시작한 팀프로젝트를 정리하는 시간을 가져보자!

이번 주의 공부 내용 이미지 💫

이번 주의 공부한 내용을 제미나이한테 그려달라고 해보았다

간단하게 정리해보자

🧤 디자인 패턴과 아키텍처 도입 (MVVM & Singleton)

학습 내용

유지보수가 쉬운 앱을 만들기 위한 MVVM 아키텍처와 싱글톤(Singleton) 패턴

주요 포인트

MVVM UI(View), 비즈니스 로직(ViewModel), 데이터(Model)를 분리하여 코드의 유지보수, 독립적으로 관리하여 사용

Singleton

앱 전역에서 단 하나의 인스턴스만 공유하여 데이터 일관성 유지.

배우면서..

단순한 기능 구현을 넘어, 큰 프로젝트에서 구조적인 설계와 깔끔한 코드에 대해서 생각해 볼 수 있었다.

🧣 보안 및 인증 메커니즘 (OAuth 2.0 & 암호화)

학습 내용

사용자 데이터를 안전하게 보호하기 위한 보안 기초와 OAuth 2.0 인증 방식

포인트

대칭키/비대칭키 암호화: 데이터 전송 시 보안을 강화하는 핵심 기술! OAuth 2.0: 소셜 로그인 등 외부 서비스와의 안전한 데이터 공유 프로세스 이해.

느낀 점

내가 여태 쓰던 모든 로그인 방식이잖아..? 인증하라고 할 때마다 철수와 영희가 생각 날 듯 싶다..! 우체국에 가지 않고, 공개키와 비공개키로 인해 박스를 열어보자

🧦 클라우드 데이터베이스 연동 (Firebase & Firestore)

학습 내용

백엔드 구축 없이 데이터를 관리할 수 있는 Firebase와 실시간 DB인 Firestore를 연동 배우기

포인트

Firebase 프로젝트 설정 및 Flutter 패키지 연결. Firestore를 통한 데이터의 CRUD(생성, 읽기, 수정, 삭제) 로직 구현.

배우면서

아직도 익숙하지는 않다. 파일 왔다 갔다.. 조금 더 많이 만져봐야한다

👖 상태 관리 (Riverpod & Freezed)

학습 내용

Flutter의 강력한 상태 관리 라이브러리인 Riverpod과 불변 객체 생성을 돕는 Freezed를 학습

포인트

StateNotifier를 활용한 반응형 프로그래밍.

Freezed를 사용해 데이터 모델의 불변성을 배우고 코드 생성 기능을 통한 코드의 생산성을 높여봤다 과제 프로젝트였던 메모 앱과 ToDo 앱에 이 스택을 적용하여 코드의 안정성을 높였ㄷ다!

Team Project 🧍🏼🧍🏼🧍🏼🧍🏼‍♀️

Doran Doran 도란도란앱 🧑‍🧑‍🧒

우리 앱은 모임 어플이다. 요즘 경찰과 도둑, 러닝 모임, 독서 모임 등 사람들과 함께 취미와 운동을 즐길 수 있는 앱을 만들어볼 것이다..!! 도란도란 모여서 같이 취미하자~!!

금일 작업 내용

• 디자인 기획 및 브랜딩 작업
• 대시보드 작성
• 와이어 프레임 작성
• Git 연동
• firebase 연동 등등..

생각보다 팀원들과 손발이 척척 잘 맞게 프로젝트를 시작했다. 나의 가장 큰 걱정은 나의 담당 페이지..ㅎㅎ 나의 임무는 채팅페이지와 지도페이지... 쉽진 않지만 어렵지 않은 임무라고 하는데 ㅎㅎ 잘 해내고 싶다. Je peux faire.. vraiment

[트러블슈팅] ToDo 삭제 기능의 UI-데이터베이스 불일치 해결

1️⃣. 문제 상황 (Problem)

새로운 ToDo 항목을 추가한 직후, 삭제 버튼을 눌렀을 때 다음과 같은 문제가 발생했다.

▪️ 현상 1

UI상에서는 해당 항목이 즉시 사라지지만, Firebase Firestore 실제 데이터는 삭제되지 않음.

▪️ 현상 2

앱을 새로고침하면 삭제했던 항목이 다시 나타남 (데이터가 살아있음).

▪️ 현상 3

터미널에 Invalid argument(s): A document path must be a non-empty string 에러 발생.

▪️ 특이사항

앱을 재시작한 후 방금 추가한 항목은 삭제가 되지만, 기존 데이터는 삭제가 안 되는 상황

2️⃣. 원인 분석 (Analysis)

문제의 핵심은 ID 값의 부재 및 불일치였다..!

▪️ 2.1 초기 코드의 흐름

UI/ViewModel

새로운 ToDo를 만들 때 id : '' (빈 문자열)로 설정하여 Repository로 전달.

Repository

Firebase에 저장할 때 문서 ID를 자동으로 생성하도록 처리.

결과

Firebase에는 고유 ID(예: tJjtv...)가 생성되어 저장되지만, 앱 내의 현재 상태(State)에 들어있는 데이터의 ID는 여전히 빈 문자열('')임.

▪️ 2.2 왜 삭제가 실패했을까?

삭제 함수(deleteToDo)를 호출할 때 리스트에 있는 ToDo의 id를 넘겨주는데, 방금 추가된 데이터는 ID가 빈 값이었다 Firebase는 "어떤 문서를 삭제할지 경로(ID)를 알려줘야 하는데 왜 빈 값을 주느냐" 하고 기존의 내용은 삭제 불가, 새로 추가한 항목만 삭제를 할 수 있게 되어버렸었다.. 새로고침하면 기존 삭제했던 항목도 다시 뜸..

에러 로그 확인: 삭제 요청 아이디: 뒤에 아무것도 없거나 빈 값이 전달되어 Invalid argument 에러가 발생하는 것

3️⃣. 해결 방법 (Solution)

데이터가 생성되는 시점에 Firebase가 사용할 ID를 미리 생성하여 UI 상태와 DB를 일치시키는 방식으로 해결했다.

▪️ 해결 순서 1.

ViewModel에서 ID 미리 생성하기1! 추가할 데이터를 만들기 전, Firestore에서 제공하는 .doc().id를 사용하여 고유 ID를 미리 발급받는다

코드

// HomeViewModel.dart 수정
final docId = FirebaseFirestore.instance.collection('todos').doc().id; // ID 선제적 생성

final ToDoEntity newtodo = ToDoEntity(
  id: docId, // 위에서 만든 ID를 주입
  title: title,
  description: description,
  isFavorite: isFavorite,
  isDone: false,
);

▪️ 해결 순서 2.

Repository 저장 로직 동기화 Repository의 insert 함수에서 전달받은 엔티티의 ID를 그대로 Firebase의 문서 ID로 사용하도록 아이디값 바꿔치기

코드

// TodoRepository.dart 수정
Future<void> insert({required ToDoEntity todo}) async {
  final collectionRef = firestore.collection('todos');
  // todo.id(이미 발급된 ID)를 문서 경로로 지정하여 저장
  await collectionRef.doc(todo.id).set(todo.toJson());
}

▪️ 해결 순서 3 [결과 확인]

이렇게 수정하면 state = [newtodo, ...state]를 통해 UI에 반영되는 데이터도 이미 정확한 ID를 가지고 있게 되었다. 새로고침 후에 삭제를 눌러도 정확한 ID 경로를 찾아가 삭제가 될 수 있었다..! 😯

4️⃣. 학습 포인트 및 회고 (Retrospective)

▪️ ID 동기화의 중요성

App의 상태 데이터와 서버(Firebase)의 데이터는 언제나 같은 식별자(ID)를 공유해야 한다! ⚡️

▪️ 업데이트(Optimistic Update)의 주의점

UI에 먼저 반영할 때는 해당 데이터가 서버에 저장될 때와 완전히 동일한 형태를 갖추고 있어야 오류를 방지할 수 있다 ⚡️

▪️ 해결

서버에서 ID가 생성되기를 기다렸다가 UI를 갱신하는 방법도 있지만, 이번처럼 앱에서 ID를 미리 생성 하여 주입하는 방식으로 새로운 방법을 알았다..! ⚡️

오늘의 공부 이미지 💫

내가 설명을 제대로 안 해서 그런가.. 요즘 좀 대충 그려주는 듯 Gemini.....

🗓 할 일 완료, ⭐️ 즐겨찾기 구현 완료

ToDo App의 할 일 완료, 즐겨찾기가 실제 데이터 베이스에 반영되는 것을 마지막으로 과제가 마무리가 되었다.!! 오늘 작업한 내용을 TIL로 작성해보려고 한다 🌞

🎢 UI - ViewModel - Repository 흐름 분석하기

📎 전체적인 흐름과 분석

사용자가 클릭 시에 실제 데이터 베이스에 반영될 때의 경로는? View (UI) -> ViewModel (State) -> Repository -> Firestore

개발자 입장에서의 코드를 짤 때 경로는? Repository 구현 -> ViewModel 구현 -> View (UI) 작업

📎 기능별 상세 진행 순서

나는 코드를 짰으니, 내가 짠 코드대로 정리해본당

1. Repository [할 일 완료 기능]

Future<void> updateToDo({required ToDoEntity todo}) async {
    FirebaseFirestore firestore = FirebaseFirestore.instance;
    final collectionRef = firestore.collection('todos');
    final docRef = collectionRef.doc(todo.id);
    await docRef.update(todo.toJson());
  }

[즐겨찾기 기능]

Future<void> toggleFavorite({required ToDoEntity todo}) async {
    FirebaseFirestore firestore = FirebaseFirestore.instance;
    final collectionRef = firestore.collection('todos');
    final docRef = collectionRef.doc(todo.id);
    await docRef.update({'isFavorite': todo.isFavorite});
  }

• 할 일 완료 이벤트 발생 시에 업데이트 되게 할 Insert 구현해주기

2. ViewModel [할 일 완료 기능]

Future<void> toggleDone({required bool isDone, required String id}) async {
    final newTodo = state.firstWhere((todo) => todo.id == id);
    final updateTodo = newTodo.copyWith(isDone: isDone);
    await todoRepo.updateToDo(todo: updateTodo);
    state = state.map((todo) => todo.id == id ? updateTodo : todo).toList();
  }

[즐겨찾기 기능]

Future<void> toggleFavorite({required bool isFavorite, required String id}) async {
    final newTodo = state.firstWhere((todo) => todo.id == id);
    final leFavoriteTodo = newTodo.copyWith(isFavorite: isFavorite);
    await todoRepo.toggleFavorite(todo: leFavoriteTodo);
    state = state.map((todo) => todo.id == id? leFavoriteTodo : todo).toList();
  }

• state.firstWhere을 사용해서 해당 ID를 가진 객체를 찾을 수 있게 한다.
• copyWith를 사용해서 받아온 ID만newTodo`로 바꿔서 기존 객체는 그대로, 상태를 복사한다.
• Repository의 updateTodo를 비동기로 호출

3. UI (ListView) [할 일 완료 기능]

class TodoListView extends ConsumerWidget {
  @override
  Widget build(BuildContext context, WidgetRef ref) {
  final vm = ref.read(homeViewModelProvider.notifier);
    final todos = ref.watch(homeViewModelProvider);

 (... 생략 ...)

// [할 일 완료]
IconButton( 
 onPressed: () {
  vm.toggleDone(isDone: !item.isDone, id: item.id,);
  },
   icon: Icon(
    item.isDone
    ? Icons.check_circle
    : Icons.radio_button_unchecked,
     color: item.isDone 
     ? Colors.green 
     : Colors.grey,
 ),
),

// [즐겨찾기]
IconButton(
 onPressed: () {
  vm.toggleFavorite(isFavorite: !item.isFavorite, id: item.id);
  },
   icon: Icon(
    item.isFavorite 
    ? Icons.star 
    : Icons.star_border,
     color: item.isFavorite 
     ? Colors.amber 
     : Colors.grey,
    ),
   ),

• ConsumerWidget 확인
• vm 함수 만들기
• IconButton의 onPressed 발생 시에 현재 item.isDone / item.isFavorite상태를 !item.isDone / !item.isFavorite으로 반전시켜서 vm.toggleDone 함수로 전달하기

🏗 작업 내용

1단계: Data Model (Entity) 설계

가장 먼저 할 일은 내가 다룰 데이터는 어떻게 생겼는가 정의하기 TodoEntity 클래스를 생성한다.

• 데이터 구조가 결정되어야 Repository에서 저장할 형식을 알 수 있고, ViewModel에서 어떤 값을 관리할 지 결정할 수 있다.
• 핵심은 id ,title, isDone, isFavorite 등의 필드를 정의하고, Firestore와 통신ㄴ하기 위한 fromJson / toJson 메서드를 만든다 ⭐️

2단계: Repositoty 구현

데이터 (FireStore)와 통신하는 통로를 만든다

• TodoRepository를 만들고 각 insert update 등등 구현할 함수를 만든다
• 실제 데이터가 잘 들어가고 나가는지 확인 필요, UI가 없어도 print해보기!

3단계: ViewModel 구현

데이터를 UI가 쓰기 좋은 형태로 가공하고 상태를 관리하기

• Riverpod의 Notifier 등을 사용ㅎ해서 HomeViewModel을 작성한다
• Repository에서 가져온 리스트 형태나 필터링하는 로직을 미리 준비한다

4단계: View 결합 (UI)

마지막으로 사용자에게 보여줄 화면을 그리고, ViewModel에 연결하기

• TodoLisiView, IconButton 등을 만들고, ref.watch를 통해 ViewModel의 상태를 구독한다

📲 구현 완료~!

+ 🌞 추가 모닝스터디 정리

과제 하면서 추가적으로 모닝스터디때 도움이 되었던 내용을 정리해보려고오오 한닷

.map() 이란?

.map()은 리스트 안에 있는 모든 데이터를 하나하나 꺼내서, 내가 정한 규칙에 따라 새로운 형태로 바꾸어 주는 역할을 한다!

⭐️ 중요한 점은! 원본 리스트는 건드리지 않고! 변형된 데이터들로 이루어진 새로운 묶음으로 만들어준다

예를 들어서 Repository에서 객체로 바꿔줘야 할 때, .map()을 사용해서 코드를 간단하게 만들 수 있다!

리스트 안에 있는 내용을 하나씩 돌면서 확인 후 원하는 데이터만 바꿔야 한다면?

원래라면 for문을 사용했을거다..! [for문]

List<Matzip> matzipList = [];
    for (var i = 0; i < box.length; i++) { 
      Map<String, dynamic> e = box[i];
      Matzip m = convertMatzip(e);
      matzipList.add(m);
    }

하지만 간결하게 만들고 싶다면? [.map() 메서드]

List<Matzip> matzipList2 = box.map((e) {
      return Matzip.fromJson(e);
    },).toList ();

=> 요렇게 바꿔줄 수 있다. ⛔️ 주의 사항은? .map() 의 결과값은 리스트가 아니라, Iterable 이라는 형태이다. 그래서 꼭!! .toList()를 붙여서 다시 리스트로 만들어줘야한다!!