SeSAC AI+ Academy 라는 게 신설됐다. 서울시, 대한상공회의소, 새싹, 빅테크 기업들이 함께 AI 중점 교육을 진행한다.

Oracle 교육과정

교육과정 설명이 원래 길게 나왔는데 모집 종료되면서 자세한 부분은 삭제된 것 같다.

5/10 2차 모집 마감 5/11 서류 합격 발표 5/13 (오전) 면접 5/14 (오후) 최종합격 5/15 등록 마감 5/18~9/10 수업 + 프로젝트 10월 중에 해커톤 예정

사실 빨리 취업을 해야하는데 또 교육에 참여하는 게 맞나 고민했지만, 내 현 상황에서 플랜 B는 필요할 것 같아 참여 의사를 확정했다. 믿습니다 오라클

[장점]
- 기업이 직접 교육 (교육 주관사가 다르지 않음)
- 지원 - 면접 - 수업참여 - 취업지원 일정 매우 빠름
- 취업연계? 취업지원? 제공
- 오라클 자격증 응시비용 제공 + SQLD(5/31) 준비할 때 시너지 날 것 같음
- DB, 클라우드, AI 쪽 지식 확장 + 의료/바이오 쪽 도메인 확장
- 점심 제공, 실습용 노트북 대여

[단점]
- 교육만 너무 많이 듣는 게 오히려 약점이 될수도
- 비개발자도 참여 가능해서 교육 난이도가 애매함, 이미 경험한 내용도 있음
- AI 겉핥기의 효용성? 의료/바이오?

교육 들으면서 자격증도 준비하고 가능하면 TIL을 좀 올려볼 예정

동작캠퍼스 첫 기수라는 듯?? 대방역 서울가족플라자 안에 있다. 다른 새싹 캠퍼스에 비해 규모가 크진 않은 것 같지만 시설은 괜찮다. 다만 주변에 뭐가 없다.. 그래서 식대 대신 도시락 제공해주시는 것 같다.

웰컴키트를 받았다!

hp 게이밍 노트북을 대여받았다. sLLM 돌아가야해서 GPU 달린 걸로 주신 듯 하다. 코덱스 세팅해서 쉬는 시간에 사이드 프젝도 돌려봐야겠다.

• DB = 데이터를 자주 읽고 관리하기 위한 것
• 디스크 저장 = 파일을 보존하거나 내보내기 위한 것

어떻게 저장할거임?

• 머리에 넣어두자 앱 재시작 필요 없음 (일시 상태) → 메모리 상태 간단한 설정값 → SharedPreferences 민감 정보 → flutter_secure_storage 레포트·로그·백업 → 디스크 저장(JSON/PDF) 구조적 데이터(검색·정렬·통계)→ Drift or SQLite 캐시·간단 저장 → Hive or Isar
• 실제로는 혼용해야지 반복적으로 조회·필터링해야 하는 구조적 데이터는 Drift/Hive 레포트/기록성 데이터는 파일 저장(JSON 또는 이진 파일)

1. 모델을 freezed 기반으로 통일

핵심 포인트

• Freezed는 불변성(immutability) 확보
• copyWith, equality, toString 자동 생성
• JSON 직렬화는 json_serializable로 자동 처리
• enum 직렬화는 JsonConverter로 관리

개선 이유

• 모델 필드 변경 시 JSON 변환 코드를 직접 수정해야 하는 문제 해소
• 타입 안정성 확보
• 전체 모델 구조를 일관적으로 유지하기 용이

Freezed 도입 효과

• 생성자 + 직렬화 코드 자동화
• state 관리 안정성 상승
• 유지보수 비용 감소

2. JSON 직렬화 / 역직렬화 흐름 정리

역직렬화(JSON → 객체)

• Dio가 JSON 문자열 → Map 변환
• Retrofit이 응답 타입을 보고 fromJson 호출
• json_serializable이 생성한 _$ModelFromJson 실행
• Freezed 내부의 구현체로 모델 생성
• 최종적으로 Dart 객체로 전달

직렬화(객체 → JSON)

• Dio가 객체에 toJson() 존재 여부 확인
• Freezed + json_serializable이 생성한 _$ModelToJson 실행
• Map → JSON 문자열 변환 후 API 요청

핵심 요약

• Retrofit은 타입 기반으로 자동 직렬화
• Freezed는 모델 구조를 일관적으로 유지
• json_serializable은 실제 변환 로직 담당

3. Repository / DataSource 추상화

문제점

• DataSource가 단일 구현체로 고정
• 테스트용 Mock과 실제 API 교체가 어려움
• Repository가 구현체에 직접 결합됨

개선 방향

• abstract DataSource 정의
• API 구현체, Mock 구현체를 별도 분리
• Repository는 인터페이스에만 의존
• main.dart에서 의존성 주입으로 구현체 교체

구조 요약

Cubit → Repository(인터페이스) → DataSource(인터페이스) → 구현체(API 또는 Mock)

장점

• 테스트 쉬움
• 교체 유연성 확보
• 의존성 역전(DIP) 적용
• 단일 책임(SRP) 유지

단점

• 파일 증가
• 작은 프로젝트에서 과한 구조 가능

4. 전체 아키텍처 레이어 맵

UI
  ↓
Cubit (State 관리)
  ↓
Repository (비즈니스 로직)
  ↓
DataSource (API, Mock)
  ↓
Model (Freezed)

핵심 원칙

• 상태는 불변성 기반
• 비즈니스 로직과 데이터 접근 분리
• 인터페이스 기반 의존
• 자동 코드 생성 활용

진행 예정

1. 앱이 종료돼도 데이터가 유지되게

• 디스크 저장 방식이나 클라이언트 DB(Hive/Drift) 사용 고려
• 클라이언트 DB를 적극적으로 활용하는 앱 사례가 많으며, 우리도 앱 고도화 단계에서 변동성이 낮은 데이터(예: 리포트 등)를 로컬에 캐싱해 전달하는 방식으로 활용 가능

웹페이지 리뉴얼은 참여 안 할수도..?

나중에 reactiveX, 추상화, 디자인 패턴, flutter에서의 상태 관리와 타이밍 이슈 처리 전략 같은 부분을 좀 더 개념적이고 기술적인 부분 위주로 학습해서 포스팅 해야겠다.

11/28주말 조금12/01 진행 내용

진행 상황

1. 상태 관리 구조 개선: Sealed Class → Freezed 전환

상태 관리를 기존의 수동 sealed class 방식에서 Freezed 기반 구조로 정리함. 특히 화면 성격별로 플래그 기반 단일 State와 유니온 타입 State를 구분하여 적용함.

MainScreen: 플래그 기반 단일 State로 정리

메인 화면은 동시에 여러 데이터를 들고 있고, 부분 업데이트가 잦음. 따라서 여러 클래스로 나누기보다 하나의 State 안에 플래그로 묶는 방식이 적합하다고 판단함.

@freezed
class MainScreenState with _$MainScreenState {
  const factory MainScreenState({
    @Default(UserRegistrationData()) UserRegistrationData userData,
    @Default(<Pet>[]) List<Pet> pets,
    @Default(false) bool isLoading,
    String? error,
  }) = _MainScreenState;
}

이 구조는 다음과 같은 장점을 가짐:

• copyWith()로 필요한 부분만 갱신하기 쉬움
• UI는 if (state.isLoading) 같은 단순 조건으로 분기함
• 등록 정보 + 펫 정보처럼 서로 다른 리소스를 동시에 관리하는 화면에 적합함

UserRegistration / PetRegistration: 유니온 타입 유지

등록 플로우는 단계가 명확한 구조라 유니온 타입이 더 자연스러움. 각 단계가 “명시적으로 표현되는” 것이 중요하다고 판단해 Freezed의 union type을 그대로 유지함.

@freezed
class PetRegistrationState with _$PetRegistrationState {
  const factory PetRegistrationState.initial(Pet pet) = PetRegistrationInitial;
  const factory PetRegistrationState.loaded(Pet pet) = PetRegistrationLoaded;
  const factory PetRegistrationState.loading() = PetRegistrationLoading;
  const factory PetRegistrationState.success(Pet pet) = PetRegistrationSuccess;
  const factory PetRegistrationState.failure(String message) = PetRegistrationFailure;
}

유니온 타입의 장점은 다음과 같음:

• when, map으로 모든 상태를 반드시 처리하게 되어 실수 방지
• 각 상태별로 필요한 데이터만 들고 있게 설계 가능함
• 단계가 명확한 “등록/입력 흐름”에 최적화되어 있음

정리:

• 메인 화면 → 플래그 기반 단일 State
• 등록 플로우 → Freezed 유니온 타입 두 방식을 상황에 맞게 병행함.

2. ReactiveX 패턴 적용: BehaviorSubject + switchMap

변경 사항 자동 반영, 요청 버전 관리, 타이밍 문제 해결을 위해 Repository 레이어에 ReactiveX 패턴을 도입함.

BehaviorSubject를 Repository에 추가함

각 Repository에서 BehaviorSubject<String?>를 사용해 “어떤 유저의 데이터가 변경됐는지”를 스트림 형태로 발행함.

final _userUpdateSubject = BehaviorSubject<String?>.seeded(null);

Stream<String?> get userUpdates => _userUpdateSubject.stream;

Future<void> registerUser(String userId, UserRegistrationData data) async {
  await dataSource.registerUser(userId, data);
  _userUpdateSubject.add(userId);
}

BehaviorSubject의 핵심 특징은 다음과 같음:

• “마지막 emit 값”을 기억함
• 새로운 구독자가 붙으면 그 값을 즉시 emit함
• Cubit이 늦게 구독해도 최신 데이터를 놓치지 않음

MainScreenCubit에서 switchMap으로 요청 버전 관리함

MainScreenCubit은 userUpdates 스트림을 구독하며, switchMap을 이용해 이전 API 요청을 취소하고 마지막 요청만 처리하는 방식을 적용함.

_userUpdateSubscription = userRegistrationRepository.userUpdates
    .where((userId) => userId != null && _currentUserId == userId)
    .switchMap(
      (userId) => Stream.fromFuture(
        userRegistrationRepository.getUserDataByUserId(userId!),
      ),
    )
    .listen(
      (userData) {
        emit(state.copyWith(
          userData: userData ?? state.userData,
          error: null,
        ));
      },
    );

이 방식의 장점은 다음과 같음:

• 연속으로 빠르게 업데이트가 들어와도 마지막 이벤트만 유효
• 오래 걸린 응답이 늦게 도착해 UI를 덮어쓰는 문제 방지
• BehaviorSubject와 조합하면 “초기 로딩 + 자동 새로고침”이 자연스럽게 연결됨

요약하면, BehaviorSubject는 최신 이벤트 보장, switchMap은 요청 버전 관리 이 두 가지가 결합해 타이밍 이슈 전반이 해결됨.

3. FastAPI 로컬 서버 구축

FastAPI로 직접 로컬 서버를 구축해 실제 API 구조와 더 유사한 환경을 구성함.

인메모리 DB 구조 설계

• Python 딕셔너리로 users, pets 저장
• user_id_counter, pet_id_counter로 ID 자동 증가
• login ID와 내부 시스템 ID를 별도로 관리

이 구조로 Flutter 측의 loginUserId와 서버 내부 primary key를 명확히 분리할 수 있었음.

환경 구성

FastAPI에서 CORS 설정 후 Flutter에서 바로 호출하도록 구성했고, Flutter 앱에서는 환경 변수를 다음과 같이 주입하는 방식으로 관리함.

flutter run --dart-define=API_BASE_URL=http://192.168.0.2:3000

환경별 서버 주소를 유연하게 바꿀 수 있는 구조로 개선함.

4. Retrofit + Dio로 Flutter API 클라이언트 정리

FastAPI와 통신하는 Flutter 클라이언트를 Retrofit + Dio 기반으로 재구성함.

• @RestApi(), @GET, @POST로 인터페이스만 작성
• JSON 직렬화와 실제 HTTP 요청은 자동 생성됨
• build_runner로 *.g.dart, *.freezed.dart 파일 생성

일관된 API 모델과 상태 모델을 유지할 수 있고, 404 응답을 에러가 아닌 “데이터 없음”으로 처리하는 식의 흐름 제어가 용이함.

if (e is DioException && e.response?.statusCode == 404) {
  return null;
}

등록 정보가 없을 때는 비정상 상황이 아니므로 이렇게 처리함.

5. 로그인 및 초기 로딩 처리 개선

listenWhen으로 불필요한 listener 호출 차단

listenWhen: (previous, current) {
  return previous.user?.id != current.user?.id;
},

• user.id가 실제로 바뀔 때만 listener가 실행되도록 구성함
• 로딩 플래그 변화나 사소한 state 변경에는 반응하지 않도록 최적화함

초기 진입 시 데이터가 비어 보이는 문제 해결

BlocListener는 첫 빌드 때 동작하지 않기 때문에, 필요한 경우 addPostFrameCallback으로 초기 loadData를 강제 실행하도록 구성함.

if (!state.isLoading &&
    state.userData.nickname == null &&
    state.pets.isEmpty &&
    loginState.loginUserId != null) {
  WidgetsBinding.instance.addPostFrameCallback((_) {
    context.read<MainScreenCubit>().loadData(loginState.loginUserId!);
  });
}

BehaviorSubject의 캐싱과 결합되면서 “초기 진입 / 로그인 변경 / 등록 완료 후 복귀 등 모든 타이밍에서 최신 상태 유지”가 가능해짐.

여기서부터 팀장님 피드백

진행 예정

1. Repository–DataSource 추상화

현재 DataSource가 단일 구현체라 Repository가 구체 클래스에 직접 결합된 구조. 테스트용 목업과 실제 API를 동일한 흐름으로 교체하려면 DataSource를 인터페이스로 추상화하는 구조가 필요.

개선 방향 요약

• abstract UserRegistrationDataSource 정의
• Mock / API 구현체 분리
• Repository는 인터페이스만 의존
• 저장 방식 변경 시에도 앱 흐름 유지

2. Freezed State를 Flag 기반으로 통일

MainScreen은 flag 기반 단일 state인데, UserRegistration / PetRegistration은 union type 구성.

등록 플로우는 단계가 많지 않고 전이가 단순하므로, MainScreen과 동일하게 단일 state + flag 기반이 더 적합한 구조.

예시 형태

@freezed
class PetRegistrationState with _$PetRegistrationState {
  const factory PetRegistrationState({
    @Default(Pet.empty()) Pet pet,
    @Default(false) bool isLoading,
    String? error,
  }) = _PetRegistrationState;
}

핵심 개념 Freezed는 상태 변경 지점을 제한하는 목적. state는 불변이며, 모든 변경은 copyWith 기반으로만 생성. 상태 추적, 디버깅, 변경 히스토리 파악이 쉬운 구조.

3. 모델(UserRegistrationData / Pet)을 Freezed로 전환

현재 모델은

• 직접 작성한 fromJson / toJson
• Equatable 기반 비교 형태로 구성.

필드 추가·변경 시 JSON 변환 코드도 매번 직접 수정해야 하는 구조라 유지보수 비용 증가.

개선 방향 모델을 Freezed + json_serializable 기반으로 재구성.

기대 효과 요약

• JSON 직렬화 자동화
• copyWith, equality, 불변성 자동 생성
• 타입 구조 일관성 확보
• 코드량 감소

이번 리팩까지 하고나면 플러터 학습 마무리하고 앱 실제 구조 살펴볼 예정

서비스 리뉴얼 참여(약 1주)해서 프레임워크 안쓰고 순수 웹 3대장으로 UI 고치고 배포하는 과정에서 병목 등의 문제 해결..?

제발 java랑 javascript 공부 좀 하자.. C python 해서 뭐할래 객체지향 프로그래밍도 더 깊게 공부해야 할 것 같다.

일에 바로 투입되지는 못하고.. 공부만 하고 있는 게 좀 죄송했다. 모두가 엄청 바쁘게 일 하는 상황에서 나만 1인분을 못하고 있었기 때문이다. '로그인-앱 등록-펫 등록' 이 짧은 흐름 하나를 구현해놓고 피드백을 받아가며 여러 방식으로 고쳐나갔는데 뭘 하고 있는 건지 티도 안났다.

근데? 오늘 처음 구현했던 코드를 보고 지금 코드를 보니 실무 바로 들어가서 AI 써재꼈으면 진짜 큰일났겠다 싶었다!

일단 하루 30분 할애해서 코드 보면서 피드백 해주시고.. 어떤 식으로 생각해야 하는지, 어떤 패키지들을 적용해볼 수 있는지 하나하나 짚어주시는 게 사실 자원을 엄청 쓰고 있다는 걸 알고 있어서 공부를 열심히 하려곤 했다. 근데 베이스가 너무 부족해서 힘들고 학습이 되긴 하는 건지 몰랐는데 좋은 코드가 어떤 건지 보는 눈과 짜임새 있게 코드를 구성하는 사고력이 생겨가는 것 같다.

물론 지금도 코드 쓰는 걸 버벅이고 생각의 흐름이 매끄럽지 못해 AI에게 많이 배우고 있지만.. 진짜 뭣도 모르면서 AI에게 거의 모든 걸 맡겼던 내가 얼마나 잘못된 방식을 선택했는지 깨닫는다.

주니어 개발자 내 자신 화이팅...

오늘 한 내용

1. 레이어 구조 정리

• 전체 구조를 UI → Cubit → Repository → DataSource 로 명확히 분리
• UI에서 Repository를 직접 호출하던 부분 제거
• Cubit이 비즈니스 로직과 데이터 접근을 전담하도록 구조 개선 → 상태관리·의존성·테스트 용이성이 크게 향상됨

2. 상태 클래스 개선

• 모든 상태 클래스를 sealed class + final class로 재구성
• switch 표현식 사용 가능
• 모든 상태 분기를 컴파일 타임에 강제할 수 있어 안정성 확보

3. GoRouter 실험

• pageBuilder 방식: 부모 페이지(Page)가 실제로 생성되는 구조
• redirect 방식: 부모 페이지 없이 자식 경로로 곧바로 이동
• AI는 redirect 방식이 URL 구조·뒤로가기 스택에 유리하다는데 뭐가 더 좋은지는..

4. MainScreen 구조 정비

• 메인 화면을 StatefulWidget → StatelessWidget 으로 변경
• 상태·데이터 로드를 담당하는 MainScreenCubit 신설
• 로그인 상태 변화에 따라 Cubit이 사용자·펫 데이터를 자동 재로딩 → UI는 “상태만 읽는 구조”로 단순화됨

5. 자동 새로고침 로직 정비

1) 수동 refresh 방식 사용해봄

• 등록 완료 후 UI 쪽에서 refreshUser / refreshPets 직접 호출
• print 디버깅으로 호출 시점·rebuild 문제 확인

2) Stream 기반 자동 동기화 사용해봄

• Repository에 StreamController.broadcast() 추가
• 데이터 변경 시 stream.add(userId)로 이벤트 발행
• MainScreenCubit이 stream을 listen()하여 같은 userId일 때 자동으로 refreshUser / refreshPets 실행
• 구독은 StreamSubscription으로 관리, Cubit close에서 취소 → 수동 refresh 불필요, 화면 자동 동기화 완성

6. 사용자 정보 수정 플로우

• 메인 화면에 유저 정보 수정 버튼 추가
• 기존 등록 플로우(닉네임 등 입력 화면)를 수정 모드로 재사용
• 기존 데이터가 TextField에 자동 세팅
• 수정 완료 시 stream 이벤트 → 메인 자동 새로고침

7. 디버깅 및 개념 정리

• Repository stream과 흐름 이해
• Repository를 전역 Provider로 두는 이유:
  • 의존성 주입
  • Stream 공유
  • 테스트 및 Mock 용이

피드백 받은 내용 한 번에 정리

1. 로딩/실패 상태 처리

• 새 데이터가 도착했을 때 Cubit이 로딩 중이거나 실패 상태라면 기존 데이터를 어떻게 유지/대체할지 타이밍을 고민해야 함

2. ReactiveX/Subject 개념

• 기본 Stream 외에 BehaviorSubject 같은 RX 개념도 존재. 마지막 emit 값을 캐싱해 두고 새 구독자가 즉시 현재 상태를 알 수 있어 UI 초기화에 유리

3. sealed class 대안

• sealed class를 쓰지 않고 MainState.loading, MainState.success처럼 상태를 한 객체 안에 묶는 패턴도 있음
• 더 immutable하게 만들고 싶다면 freezed 같은 코드 생성 패키지를 검토

4. 실제 API 콜 테스트

• 실제 REST API를 호출하는 플로우도 한번 테스트해 보자
• 간단한 서버를 띄우거나, 테스트용 HTTP 서비스를 이용해 보고, Retrofit 같은 REST 클라이언트도 경험해 보라고 권장

• 한 것 go router 사용 라우트 관리, cubit provider 주입 시점 조절, repo provider 사용

• 못 한 것 provider 내부 동작 살펴보기, sealed class 사용
• 과제는 아니었지만 이상하게 만들어서 수정이 시급한 것 레이어 분리 제대로(UI가 레포 호출 바로 못하게 - cubit이 처리)

어찌저찌했는데 머리에 다 들어온 건 아닌 듯

여기서부터 팀장님 피드백

Cubit 분리 전략

Cubit을 따로 만들지 않는 경우

등록 플로우 Cubit과 전역 리스트 Cubit을 분리하지 않고 하나로 운용할 때 두 방식 중 선택

방식 1: 파라미터 + 리프레시 호출

• 업데이트가 필요한 화면으로 파라미터 전달
• 변경 시 리프레시 신호를 보내서 해당 화면이 데이터 다시 로드
• 장점: 구조 단순
• 단점: 수동 리프레시 필요, 여러 화면 동기화 어렵다
• 사용 시기: 단순 플로우

방식 2: Repository 스트림 구독

• Repository에 스트림을 두고 데이터 변경 시 이벤트 발행
• Cubit 등이 스트림을 구독해 자동으로 상태 갱신
• 장점: 자동 동기화, 화면 여러 개여도 일관성 유지
• 단점: 구조 복잡
• 사용 시기: 데이터 공유가 많고 흐름이 복잡할 때

선택 기준

• 단순: 방식 1
• 복잡·다중 화면: 방식 2

디버깅 습관

의식의 흐름을 제대로

1. 갱신이 필요한 위치 확인
2. 갱신을 호출하는 코드 위치 확인
3. 호출은 되었는지, 수신은 되었는지, 수행은 되었는지 로그로 확인

이런게 자연스럽게 이뤄져야 함

로그 활용 잘하기

에러 떴으면 뭐라 떴는 지 좀 잘 보기

go_router 메서드 요약

context.go(path)

• 스택 전체 대체
• 뒤로가기 불가
• 로그인 성공 후 메인 이동 등

context.push(path)

• 스택에 화면 추가
• 뒤로가기 가능
• pop 결과값(Future) 받을 수 있음

context.pop([result])

• 현재 화면 제거
• push로 온 화면에서만 가능
• 이전 화면으로 결과 전달 가능

context.replace(path)

• 현재 화면만 교체
• 아래 스택 유지
• 뒤로가기 가능

context.canPop()

• pop 가능 여부 확인

context.goNamed(name, …)

• 라우트 이름 기반 go
• 동작은 go와 동일

context.pushNamed(name, …)

• 라우트 이름 기반 push
• 동작은 push와 동일

context.replaceNamed(name, …)

• 라우트 이름 기반 replace
• 동작은 replace와 동일

UI → Repository 직접 호출 금지

레이어는 제대로 짜놓고 왜 ui가 cubit 부르는거랑 repo 부르는 걸 섞어놨니..

잘못된 구조 (UI → Repository 직접 호출)

onPressed: () async {
  await context.read<PetRepository>().registerPet(userId, pet);
}

올바른 구조 (UI → Cubit → Repository)

onPressed: () {
  context.read<PetListCubit>().addPet(userId, pet);
}

class PetListCubit extends Cubit<PetListState> {
  Future<void> addPet(String userId, Pet pet) async {
    await repository.registerPet(userId, pet);
    emit(PetListLoaded([...pets, pet]));
  }
}

이유

• 비즈니스 로직은 Cubit에 집중
• UI는 “상태와 이벤트”만 알고 Repository는 Cubit만 알도록 분리
• 테스트 용이성
• 상태 흐름 일관성 유지

핵심: UI는 Cubit만 호출, Cubit이 Repository를 호출하는 구조

GoRoute : redirect / builder / pageBuilder 정리

redirect

• 라우팅 직전에 실행되어 경로만 변경하는 함수
• UI나 페이지를 만들지 않고 단순히 이동만 처리
• 인증 체크, 초기 플로우 분기 같은 상황에서 사용
• 부모 페이지 없이 바로 다른 경로로 이동하는 구조

builder

• child 라우트를 부모 위젯으로 감싸는 방식
• 반환값이 Widget이기 때문에 Navigator 스택에는 올라가지 않음
• 공통 Scaffold, AppBar, BlocProvider 같은 “레이아웃 래핑”에 사용
• 화면 구조는 부모 위젯이 존재하지만 “페이지 단위”는 아님

pageBuilder

• Navigator가 사용하는 실제 Page(MaterialPage 등)를 생성
• 부모 Page가 스택에 올라가고, 그 안에서 child가 보여지는 구조
• 뒤로가기 히스토리에도 부모 페이지가 포함됨
• 페이지 단위 공통 레이아웃이 필요할 때 사용

요약

• redirect: 경로만 변경, UI 없음
• builder: 부모 위젯 생성, Page는 아님
• pageBuilder: 부모 Page 생성, 스택에 올라감

• 레이어 제대로 고치고 디버깅 제대로 해서 내가 못고쳤던 문제 해결해보기

• go_route에서 리다이렉트말고 페이지 빌더 사용해보기
• 스트림 구독 vs 리프레시 주기

• Bloc 라이브러리에서 제공하는 단순 상태관리 클래스
• 메서드를 통해 상태 변경 → emit() 호출
• UI는 Cubit의 상태 스트림을 구독해 화면을 갱신함

Cubit 기본 구조

• State: 불변 객체, 여러 상태 클래스로 표현
• Cubit 클래스: 초기 상태 설정 → 메서드에서 emit() 호출
• 비동기/동기 모두 가능

UI와 Cubit 연결

• UI → Cubit: context.read<Cubit>().method()
• Cubit → UI: 상태 스트림 전달
• BlocBuilder: 상태 기반으로 UI 빌드
• BlocListener: 네비게이션·팝업 등 부수 효과 처리
• BlocConsumer: builder + listener 동시 사용

read / watch / select

• read(): Cubit 인스턴스 가져오기 (액션 호출용), 리빌드 없음
• watch(): Cubit 상태 전체 구독, 리빌드 발생
• select(): 특정 필드만 구독, 리빌드 최적화

Cubit 동작 원리

• 단방향 흐름: UI → Cubit → State → UI
• emit(): 새 상태를 스트림으로 내보냄
• 상태는 반드시 새로운 객체로 생성될 것

Cubit vs Bloc

• 공통: 단방향 데이터 흐름, 상태 기반 UI, 테스트 용이

• 차이점

  • Cubit: 메서드 → emit, 코드량 적음, 단순 로직에 적합
  • Bloc: Event → Handler → emit, 복잡한 로직·플로우에 적합

언제 어떤 걸 쓰는가

• Cubit: 단일 화면, API 호출 + 로딩/성공 구조 등 대부분의 케이스
• Bloc: 상태 흐름 복잡, 다단계 이벤트, 상태머신이 필요한 기능

여기부터는 팀장님 피드백 받은 내용들

context.read / watch / select

• flutter_bloc이 BuildContext에 추가한 확장 함수

• read() context.read<T>()

  • Cubit/Bloc 인스턴스를 가져오기만 함
  • 상태 변화와 무관, 리빌드 없음
  • 버튼 클릭처럼 Cubit 메서드 실행할 때 사용

• watch() context.watch<T>()

  • Cubit 상태를 구독해 상태가 바뀔 때마다 위젯 리빌드
  • 작은 위젯은 context.watch<Cubit>().state로 간단하게 사용

• select() context.select<T, R>(selector)

  • 상태의 특정 필드만 구독
  • selector 값이 바뀌지 않는 한 리빌드 없음 → 퍼포먼스 최적화

BlocBuilder vs watch

• BlocBuilder: 어떤 Cubit을 구독하는지 명시적, 리빌드 범위 제어에 유리
• watch: 간단하게 상태를 읽고 싶을 때 편함
• 둘 다 Cubit 상태에 따라 UI를 다시 그림

Repository를 Provider로 주입하자

• Repository를 Cubit 내부에서 직접 생성하는 대신 상위 위젯에서 Repository 인스턴스를 Provider로 만들어 하위에서 context.read<Repository>()로 가져와 사용

• 장점

  • 재사용성 증가
  • mock 교체 쉬워 테스트 편함
  • 여러 Cubit이 동일한 Repository 공유 가능
  • 의존성 주입 구조가 명확해짐

abstract class 대신 sealed class

• Dart 3에서 제공하는 sealed class는
  • 같은 파일 내부에서만 하위 타입 생성 가능
  • switch/case 문에서 누락된 상태가 있으면 컴파일러가 잡아줌
  • default 없이도 모든 상태를 안전하게 처리 가능
• Bloc/Cubit의 상태(State) 선언에 가장 안전한 방식

Repository를 직접 new 하지 말고 context.read()로 주입하는 이유

• Repository를 Cubit 안에서 직접 new 하면 Cubit이 특정 구현체에 묶여 결합도가 높아짐
• 테스트에서 Mock Repository로 교체하기 어렵고, 화면·플로우마다 다른 Repository를 쓰는 것도 불가능해짐
• Provider는 위젯 트리 상단에서 Repository 인스턴스를 한 번만 만들어 두고, 하위에서는 context.read<Repository>()로 받아서 사용
• Cubit은 생성 방식이나 구현체를 몰라도 되고, “필요한 의존성을 주입받아 쓰는” 구조가 됨
• 의존성 관리가 깔끔해지고 교체·모킹·재사용·라이프사이클 제어가 쉬워짐
• 결론적으로 Repository는 Provider가 만들고, Cubit은 read로 받아 쓰는 구조가 정석임

go_router와 Provider 주입 시점 조절

• go_router는 라우트 단위로 화면을 구성하는 패키지
• 특정 플로우(회원가입, 결제 등)에서만 필요한 Cubit은 해당 라우트 내부에서 Provider로 생성
• 장점
  • 플로우 종료 시 Cubit이 자동 dispose
  • 메모리 관리 깔끔
  • 라우트 단위로 상태 수명 주기를 통제할 수 있음

Flutter에서는 화면을 구성하는 모든 요소가 위젯이며, 위젯들은 부모-자식 관계로 이루어진 트리 구조를 형성한다. 위젯은 불변이기 때문에, UI가 변경될 때는 기존 위젯을 수정하는 대신 새로운 위젯을 다시 그려주는 방식으로 동작한다.

StatelessWidget과 StatefulWidget

공통점

두 위젯 모두 build(BuildContext) 메서드 안에서 “이 위젯이 어떤 UI인지”를 선언한다.

StatelessWidget

• 내부에 변경되는 상태가 없다.
• Text, Icon, Padding 같은 정적인 UI에 사용된다.
• 동일한 입력이 주어지면 항상 동일한 결과를 반환하며, 부모 위젯이 재빌드될 때만 다시 그려진다.

StatefulWidget

• 변경 가능한 상태를 가진다.
• StatefulWidget과 실제 상태를 보관하는 State 객체가 쌍으로 동작한다.
• setState()를 호출하면 해당 위젯만 다시 빌드되어 동적 UI를 만들 수 있다.
• 사용자 입력, 값 변화, 애니메이션 등 시간이 지나며 변하는 UI에 사용한다.

상태(State)의 개념

상태는 UI를 그리기 위해 필요한 데이터나 리소스를 의미한다. Flutter에서는 상태를 크게 두 가지로 나눈다.

Ephemeral State (지역 상태)

• 한 위젯 내부에서만 잠시 필요한 상태
• 예: 체크박스 선택 여부, 특정 화면의 입력값
• State + setState()로 관리한다.

App State (전역/공유 상태)

• 여러 화면 또는 여러 위젯에서 함께 사용하는 상태
• 예: 로그인 정보, 장바구니, 앱 설정 값
• InheritedWidget, Provider 등 상태관리 도구를 사용해 관리한다.

주요 상태관리 방식 요약

StatefulWidget + setState

• 간단한 로컬 상태에 적합
• 추가 패키지 없이 사용할 수 있고 이해하기 쉽다
• 하지만 공유 상태가 많아질수록 구조가 복잡해진다

InheritedWidget 계열 (InheritedNotifier / InheritedModel)

• 트리 상단에서 하위 위젯들에게 상태를 전달하는 Flutter 기본 메커니즘
• 직접 활용하면 코드가 복잡해 주로 기반 개념으로만 사용된다

ChangeNotifier + Provider

• Flutter 공식이 초보자에게 추천하는 방식
• ChangeNotifier 안에 상태를 보관하고 notifyListeners()로 변경을 알린다
• Provider는 이 변경을 구독하고 필요한 위젯만 다시 빌드한다
• 전역 상태를 깔끔하게 관리할 수 있고, MultiProvider로 여러 상태를 함께 관리할 수 있다
• 상태가 커지면 ChangeNotifier가 비대해지는 단점이 있다

기타 상태 관리 패키지 (Bloc, Riverpod 등)

• 팀 규모나 프로젝트 복잡도에 따라 선택
• 구조적이고 테스트하기 쉬운 상태관리 패턴 제공
• 보일러플레이트가 줄거나, 더 명확한 아키텍처를 만들 수 있다
• 러닝 커브가 존재하고 패키지 의존성이 추가된다

Flutter 상태관리와 Provider, 그리고 Repository 아키텍처 정리

Flutter에서 화면은 모두 위젯으로 이루어져 있으며, UI는 위젯 트리 형태로 그려진다. 위젯은 불변이기 때문에 상태가 변경되면 기존 위젯을 수정하는 것이 아니라 새로운 위젯을 다시 생성하는 방식으로 갱신된다. 이로 인해 상태가 필요 없는 UI는 StatelessWidget, 상태가 필요한 UI는 StatefulWidget으로 나뉘게 된다.

StatefulWidget은 특정 위젯 내부에서만 유효한 “지역 상태(ephemeral state)”를 관리하기에는 충분하지만, 앱의 여러 화면에서 공유해야 하는 전역 상태를 관리하기에는 한계가 있다. setState는 오직 자신의 위젯 내부만 업데이트하기 때문에, 상태를 다른 화면에 전달하려면 각 단계마다 파라미터로 넘겨야 하고, 구조가 빠르게 복잡해진다.

이 문제를 해결하기 위해 Flutter에서 널리 사용하는 방식이 Provider다. Provider는 ChangeNotifier 기반으로 상태를 객체 하나에 모아두고, notifyListeners()를 호출했을 때 해당 객체를 구독하는 Consumer만 다시 빌드된다. 이 덕분에 부모 위젯이 데이터를 일일이 전달하지 않아도 되고, 화면 어디에서든 동일한 상태를 쉽게 접근하고 변경할 수 있다.

나는 provider로 전역적으로 상태관리가 가능하도록 해서 학습을 하고 있었는데, 팀장님께서 실무에서 쓰는 상황들을 더 설명해주셨다. 아래 내용은 설명해주신걸 기억하기 위해 정리해둔 글이다.

Provider의 범위(Scope)와 라이프사이클

Provider는 흔히 “전역 상태관리 도구”로 오해되지만, 실제로는 상태를 원하는 범위의 서브트리에만 주입할 수 있는 도구다. 즉, Provider는 반드시 루트에만 두라는 규칙이 없다.

예를 들어 앱 구조가 다음과 같다고 하자.

MultiProvider
  └── App
        ├── Route A
        └── Route B

Provider는 다음과 같은 범위 중 어디든 주입할 수 있다.

• App 위 (전역)
• App 아래
• Route A 트리 내부
• Route B의 하위 위젯에서만 사용

Provider는 자신이 주입된 위치에 따라 lifespan(생명주기)이 결정된다. Provider가 트리에 붙어 있는 동안만 살아 있고, 해당 트리가 사라지면 Provider도 자동으로 dispose된다.

이 특징 때문에 실무에서는 다음과 같이 나누는 패턴이 일반적이다.

• 앱 전체에서 필요한 상태

  • 예: 로그인한 User 정보, 현재 재생 중인 음악, 설정 값
  • → 루트(MultiProvider) 또는 최상단에 주입

• 특정 플로우 안에서만 필요한 상태

  • 예: 회원가입 단계별 입력값, 특정 페이지에서만 쓰는 임시 필터 값
  • → 해당 Route 또는 해당 화면 트리에만 Provider 주입

이렇게 하면 “전역에 올릴 필요 없는 상태”를 전역에 올려서 메모리를 낭비하거나 잔존 데이터를 남기는 문제를 피할 수 있다.

Provider Shadowing: 가장 가까운 Provider를 읽는다

같은 타입의 Provider가 여러 레벨에 있을 수도 있다. 이 경우 Consumer<T> 또는 context.watch<T>()는 트리 아래에서 위로 올라가며 가장 가까운 Provider를 읽는다.

즉,

• Consumer는 “이 값이 어디서 왔는지” 모른다.
• 단지 “내 트리에서 가장 가까운 Provider”를 구독할 뿐이다.

이 특징을 이용하면 다음과 같은 패턴도 가능하다.

• 플레이어 상태는 전역 Provider에 두고
• 추천 페이지에서만 필요한 추천 알고리즘 상태는 추천 페이지 트리에 Provider를 두고
• 페이지를 벗어나면 추천 상태만 자연스럽게 dispose됨
• 하지만 전역 Provider에 있는 플레이어 상태는 유지됨

실무에서 화면별 상태와 전역 상태를 자연스럽게 분리하는 데 매우 유용한 방식이다.

Flutter에서도 Repository 레이어가 필요한 이유

상태관리와 별개로, Flutter의 아키텍처에서도 자바/Spring과 동일한 방식으로 Repository 패턴을 사용할 수 있다.

Repository의 목적은 명확하다. ** “UI나 비즈니스 로직이 데이터가 어디서, 어떻게 오는지 모르게 한다."**

Dart에는 interface 키워드는 없지만, abstract class를 통해 인터페이스와 동일한 역할을 만들 수 있다. Cubit/Bloc은 Repository의 인터페이스만 의존하고, API/캐시/Mock 구현체는 뒤에서 교체 가능하다.

레이어 구조

여러 디자인 패턴들이 있지만 다 비슷비슷하다. 중요한건 인터페이스를 잘 만드는 것이다. 내가 참여할 파트의 구조는 이런 식으로 되어있다.

Screen → Cubit/Bloc → Repository(인터페이스) → 구현체(API/캐시/Local)

• Screen UI 렌더링, 사용자 입력을 Cubit/Bloc에게 전달
• Cubit/Bloc 화면 상태/비즈니스 로직 담당. Repository 인터페이스만 호출
• Repository (abstract class) 앱 관점의 “데이터 가져오기 API” 정의
• 구현체(Impl) 실제 HTTP 요청, 로컬 DB, 캐시 등 상세한 데이터 접근 로직

이 구조가 가지는 가장 큰 장점은 UI가 데이터 출처를 전혀 모른다는 점이다. UI 입장에서는 단지 getUser()를 호출하는 것뿐이며, 그 뒤에서 실제 요청이 어떤 방식으로 이루어지는지는 Repository가 책임진다.

인터페이스를 잘 만드는 것이 핵심

Repository 패턴의 가치는 단순히 “코드 나누기”가 아니라, UI가 비즈니스 의미만 이해하고 구현 세부 사항을 모르게 만드는 데 있다.

Bad 예시:

Future<Response> get(String url);

Good 예시:

abstract class MusicRepository {
  Future<List<Music>> getRecommended();
}

이렇게 Repository 이름과 메서드가 “도메인 용어”를 표현해야 UI와 Cubit/Bloc이 데이터 구조 변경에 영향을 받지 않는다.

왜 Repository 패턴을 써야 하냐?

• API 변경에도 UI 로직 수정 없음
• 테스트 시 Mock Repository로 손쉽게 대체 가능
• 로컬 캐시 + API + DB 같은 복합 데이터 소스 구성에 적합
• 화면 로직(Cubit/Bloc)이 깔끔해지고 유지보수성 증가
• 실무 앱 대부분이 이 방식으로 성장함

즉, Flutter에서도 Repository 레이어는 데이터 로직을 독립시키고 UI·상태 로직을 깨끗하게 유지하는 핵심 아키텍처다.

이제 cubit을 이용한 걸로 다시 한번 로그인-회원가입-ㅁㅁ 등록 흐름을 만들어볼거다. Event → State 식으로 하면 복잡해지는 부분이? 있기 때문에 cubit만을 사용할 것 같다. 지금 일단 알려주신 단축키들 잘 활용해보자. cmd + . : 전구기능 실행 / option + shift + F : 줄맞춤 / Snippet + tap : 자동 완성

실무 배정을 앱 쪽으로 받게 되면서 flutter를 공부하게 됐다. 학습을 좀 깊게 해야할 듯

개발환경 세팅은 코딩 셰프의 mac 세팅 영상을 따라하다가, 공식 문서보고 그냥 좀 더 쉬운 방식으로 했다. 막히는 건 GPT로 해결.. 경로 중간에 한글이 포함되지 않도록 미리 주의합시다

코드팩토리의 플러터 프로그래밍 책을 기반으로 개념을 학습하고 있다.

Dart 언어의 장점

• 일관된 개발 경험: 모바일·웹·데스크톱을 하나의 언어로 개발
• 빠른 개발 사이클: Hot Reload 지원
• 타입 안정성: Null-safety 기반
• 성능 최적화 용이: VM + AOT 조합으로 런타임 성능 확보
• UI 지향 언어 디자인: 비동기 처리·상태 관리에 자연스러운 문법

Dart의 컴파일 방식(JIT / AOT)

JIT (Just-In-Time)

• 개발 단계용
• 코드를 실행 중에 바로 컴파일, Hot Reload 가능, 초기 실행은 느리지만 반복 개발 속도가 빠름

AOT (Ahead-Of-Time)

• 배포용
• 실행 전에 네이티브 코드로 미리 컴파일, 앱 시작 속도 빠르고 실행 성능 높음, 최종 빌드 시 용량은 커질 수 있음

Dart 기본 문법

• 변수 선언

  • var: 타입 추론 후 고정
  • dynamic: 어떤 타입도 허용, 런타임에 타입 결정
  • final: 런타임에 값 확정
  • const: 컴파일 타임 상수, 불변 + 컴파일 최적화

• 기본 타입

  • String, int, double, bool

• 컬렉션 타입

  • List: 순서 기반, 인덱스로 접근
  • Map: key–value 구조
  • Set: 중복 없음
  • enum: 값 집합 정이

• 제어문

  • if / else, switch
  • for, for-in, while, do-while

• 함수 문법

  • 반환값 + 매개변수
  • 익명 함수 & 람다 (args) => expr

• typedef

  • 함수 타입에 별칭 부여

• try / catch / finally

  • try: 실행
  • catch(e): 예외 처리
  • on SomeException: 특정 예외 처리
  • finally: 무조건 실행

• 비동기 문법

  • async, await 사용
  • Future: 1회성 비동기 결과
  • Stream: 지속적으로 여러 값을 방출
  • 

객체지향 개념 정리

클래스 (Class)

• 데이터(필드)와 동작(메서드)을 하나로 묶는 기본 단위
• 실제 앱 구조는 거의 전부 “클래스 기반”으로 설계됨
• Flutter 위젯도 모두 클래스 → Widget 이해 = Class 이해

인스턴스 (Instance) & 멤버 (Member)

• 클래스가 설계도라면 인스턴스는 그 설계도로 만든 실제 객체 (붕어빵틀과 붕어빵)
• 인스턴스화는 클래스를 실제 객체로 생성하는 과정
• 생성된 인스턴스는 각각 독립된 상태를 가짐. 인스턴스 멤버(필드/메서드)가 객체마다 독립적으로 존재
• 클래스를 인스턴스화 하면 클래스의 인스턴스를 변수로 저장 가능

생성자 (Constructor)

• 객체 생성 시 초기값을 정의
• 기본 생성자 + named constructor 모두 지원
• 생성자 오버로딩 대신 named constructor 방식 사용

게터 (Getter) / 세터 (Setter)

• 게터는 객체의 내부 값을 읽기 위한 접근자
• 세터는 객체의 내부 값을 변경하기 위한 설정자
• 최근 변수의 값을 불변성(인스턴스화 후 변경할 수 없는) 특성으로 사용해서 세터는 잘 안씀

상속 (extends)

• 부모 클래스의 기능을 그대로 물려받음
• 하나의 클래스만 상속 가능(단일 상속)
• 재사용성과 일관성을 유지할 때 유용
• Flutter에서 공통 UI/로직 구조를 만들 때 자주 등장

인터페이스 (implements)

• 클래스가 반드시 가져야 할 기능 “목록”
• Dart에서는 모든 클래스가 자동으로 인터페이스 역할 가능
• implements는 반드시 모든 메서드를 재정의해야 함
• 명확한 규약/프로토콜을 만들 때 효과적

추상 클래스 (abstract)

• 인스턴스를 만들 수 없음
• 공통 동작의 뼈대를 정의하는 용도
• “기능의 템플릿” 역할
• UI · 데이터 모델 계층에 자주 사용됨

오버라이드 (override)

• 상속받은 메서드/필드를 자식 클래스에서 재정의
• 클래스 간 동작을 상황에 맞게 다르게 표현
• @override 애노테이션을 사용해 의도를 명확히 표시함

믹스인 (Mixin)

• 상속과 달리 “기능만” 주입하는 방식
• 여러 클래스에 공통 기능을 공유하고 싶을 때 사용
• 다중 상속이 없는 Dart에서 재사용성을 강화하는 핵심 기능

제네릭 (Generics)

• 타입을 외부에서 주입해 재사용성과 안정성을 높임
• 클래스/함수/컬렉션 모두 제네릭을 사용 가능
• <> 안에 타입을 명시 List<int>, Map<String, dynamic>

스태틱 (Static)

• 클래스에 직접 귀속되는 값/메서드
• 인스턴스마다 복사되지 않고 모두가 공유
• 상태 보관용으로 남용은 위험 → 설정/상수에 적합

캐스케이드 연산자 (Cascade Operator)

• 하나의 인스턴스에 대해 연속적으로 필드·메서드를 호출하는 문법
• 인스턴스 초기화나 설정 코드를 간결하게 작성할 때 유용

플러터 구조와 통신

플러터 구조(Framework → Engine → Embedder)

• Framework(Dart): Material/Cupertino, Widgets, Rendering 등 UI 계층. 개발자가 직접 사용하는 부분
• Engine(C/C++): 렌더링, 텍스트 레이아웃, Dart VM, 이벤트 처리 등 핵심 런타임
• Embedder(Platform-specific): iOS/Android/웹 등 플랫폼에 맞게 화면, 스레드, 플러그인, 이벤트 루프를 설정

개발자가 Dart로 작성한 UI 코드는 Engine에서 처리되어 플랫폼 Embedder 위에서 실행되는 구조

플러터 vs 리액트 네이티브 플랫폼 통신 구조

• Flutter: Dart 코드가 직접 Engine을 통해 위젯을 렌더링 플랫폼 기능은 메서드 채널로 호출해 Native 서비스와 통신 → 브릿지 비용이 적고 렌더링을 엔진이 직접 수행하므로 성능 이점이 있음
• React Native: JavaScript ↔ Bridge ↔ Native 위젯 구조 → 브릿지를 거쳐 OEM UI를 렌더링하므로 통신 비용이 크고 Flutter보다 오버헤드가 큼

Flutter는 브릿지 없이 자체 엔진으로 UI를 그림, RN은 네이티브 UI를 호출하는 중간 브릿지가 필요

플러터에서의 위젯 (Widget)

모든 것이 위젯이다

위젯 (Widget)

• 플러터에서 화면을 구성하는 모든 요소의 최소 단위
• 텍스트, 버튼, 아이콘 같은 눈에 보이는 UI뿐만 아니라 레이아웃, 패딩, 정렬, 애니메이션 같은 보이지 않는 요소도 모두 위젯
• 플러터는 위젯 트리(widget tree) 구조로 화면을 구성 → 부모 위젯 안에 자식 위젯이 포함되며, 전체 화면이 트리처럼 표현

child와 children의 차이

• 구분	child	children
  수용 가능한 자식 수	1개	여러 개
  타입	Widget	List
  사용 목적	꾸미기, 감싸기, 위치 조정	레이아웃 배치, 리스트 구조
  사용 가능 예	Container, SizedBox	Row, Column, ListView

콜백 함수, 웹뷰 위젯, StatelessWidget vs StatefulWidget, setState

콜백 함수

• 특정 시점에 실행되도록 함수를 인자로 전달하는 구조
• 버튼 이벤트, 제스처, WebView 이벤트 등에서 사용
• UI가 이벤트 기반으로 동작하기 때문에 필수 개념

WebView 위젯

• 앱 내부에서 웹 페이지를 렌더링하는 위젯
• 결제 화면, 약관, 외부 링크 구현에 사용
• URL 로딩, 뒤로가기, JavaScript 통신 지원

StatelessWidget

• 내부 상태가 없는 위젯
• 부모가 전달한 값(생성자 매개변수)이 변경될 때만 build가 다시 실행됨
• 단순 UI 요소에 적합

StatefulWidget

• 상태(State)를 가지고 UI를 갱신하는 위젯
• 실제 상태는 State 객체에 저장됨
• 상태 변화에 따라 build가 재실행됨
• 입력값 변화, 애니메이션, 화면 갱신에 사용
• (사진 참고) 상태 변경이 없는 생명 주기 / StatefulWidget 생성자의 매개변수가 변경됐을 때의 생명 주기 / State 자체적으로 build()를 재실행할 때 생명주기

setState 함수

• StatefulWidget에서 UI를 다시 그릴 때 사용하는 함수
• setState 내부에서 상태 값을 변경하면 해당 위젯만 다시 build됨
• 전체 앱이 다시 그려지는 것이 아니라 필요한 위젯 트리만 갱신됨

디자인 패턴 비교 (MVC / MVP / MVVM / MVI)

아키텍처 패턴 비교표

왜 이런 디자인 패턴들이 중요한가?

1) 화면이 커질수록 코드가 복잡해지기 때문

• 버튼 하나 눌러도 다양한 로직이 필요한데, 이를 한 파일에서 처리하면 금방 “스파게티 코드”가 됨
  • UI 업데이트 / 데이터 갱신 / API 요청 / 라우팅 처리

2) UI와 비즈니스 로직을 분리하면 유지보수성이 올라감

• UI 변경 시 로직 영향 없음
• 로직 변경 시 UI 영향 없음
• 테스트가 쉬워짐

3) 플러터는 선언형 UI이기 때문에 “상태(State)” 설계가 핵심

• UI를 직접 수정하는 것이 아니라 상태를 바꾸면 UI가 자동 업데이트되는 구조 → 즉, “상태 중심 아키텍처"가 중요
• 그래서 MVC처럼 View와 Controller가 얽힌 구조는 잘 안 맞음 → MVVM 또는 MVI 계열이 적합

플러터는 어떤 아키텍처 패턴과 잘 맞는가? -> MVVM 또는 MVI 계열

• 선언형 UI 방식(Build를 계속 다시 그리는 구조)
• 상태 중심(State-driven) 아키텍처
• Provider, Riverpod, Bloc, Cubit 등 생태계 도구들이 모두 MVVM/MVI 구조를 지원

“MVC나 MVP처럼 View가 직접 로직을 호출하는 구조”보다 “ViewModel/Bloc 같은 상태 제공자를 구독해 UI를 만든다” 자연스러움

• 참고 : 플러터 아키텍쳐 패턴 - 플러터가 MVVM과 잘 맞는이유

플러터에서 자주 사용하는 상태관리 도구들

만약 팀에서 Bloc을 사용한다면?

MVI(Model–View–Intent) 기반 단방향 상태관리 아키텍처를 사용한다는 의미 View → Event → Bloc → 새로운 State → View rebuild

• 전통적인 MVVM은 ViewModel이 상태를 가지고 있고, View는 상태만 읽음(양방향 바인딩도 가능)

• Bloç을 쓴다면(MVI) MVVM보다 더 엄격한 단방향 흐름을 가짐 → 코드가 늘어나는 대신, 예측 가능성 + 테스트 용이성 + 유지보수성이 뛰어나 회사들이 선호함

  • View는 Event만 Bloc에게 전달
  • Bloc은 Event + 현재 State로 새로운 State를 생성
  • View는 이 State를 구독

백준 1644. 소수의 연속합 - python

문제 링크

문제 설명

하나 이상의 연속된 소수의 합으로 나타낼 수 있는 자연수들이 있다. 몇 가지 자연수의 예를 들어 보면 다음과 같다.

• 3 : 3 (한 가지)
• 41 : 2+3+5+7+11+13 = 11+13+17 = 41 (세 가지)
• 53 : 5+7+11+13+17 = 53 (두 가지)

하지만 연속된 소수의 합으로 나타낼 수 없는 자연수들도 있는데, 20이 그 예이다. 7+13을 계산하면 20이 되기는 하나 7과 13이 연속이 아니기에 적합한 표현이 아니다. 또한 한 소수는 반드시 한 번만 덧셈에 사용될 수 있기 때문에, 3+5+5+7과 같은 표현도 적합하지 않다.

자연수가 주어졌을 때, 이 자연수를 연속된 소수의 합으로 나타낼 수 있는 경우의 수를 구하는 프로그램을 작성하시오.

입력

첫째 줄에 자연수 N이 주어진다. (1 ≤ N ≤ 4,000,000)

출력

첫째 줄에 자연수 N을 연속된 소수의 합으로 나타낼 수 있는 경우의 수를 출력한다.

내 풀이

뭔가 굉장히 별로인 방법인걸 알지만 슬라이딩 윈도우 구현 방식이 기억이 안나 꾸역꾸역 풀었다. 당연히 시공간 자원 많이 씀.. 범위 설정을 자꾸 틀려서 연습을 많이 해야할 것 같다. 에라토스 뭐시기는 소수 구할 때 써야한다는 건 기억나는데 방법이 기억 안나서 나무위키 잠깐 봤음

# 백준 1644번 소수의 연속합

N = int(input())
answer = 0

# 예외 처리: 2 미만이면 만들 수 있는 연속 소수 합 없음
if N < 2:
    print(0)
    exit()

# 에라토스테네스의 체 (i*i부터 지우기)
temp_list = [i for i in range(N + 1)]
temp_list[0] = 0
temp_list[1] = 0

limit = int(N ** 0.5)
for i in range(2, limit + 1):
    if temp_list[i] != 0:
        start = i * i
        step = i
        for m in range(start, N + 1, step):
            temp_list[m] = 0

prime_list = [v for v in temp_list if v > 0]

# 두 포인터로 연속합 세기 (오른쪽 늘리고, N 이상이면 왼쪽 줄이기)
left = 0
right = 0
temp_sum = 0

while True:
    if temp_sum >= N:
        if temp_sum == N:
            answer += 1
        temp_sum -= prime_list[left]
        left += 1
    else:
        if right == len(prime_list):
            break
        temp_sum += prime_list[right]
        right += 1

print(answer)

아래는 gpt와 함께 코드를 효율적으로 다듬은 거다.

# 백준 1644번 소수의 연속합

N = int(input())
answer = 0

# 예외 처리: 2 미만이면 만들 수 있는 연속 소수 합 없음
if N < 2:
    print(0)
    exit()

# 에라토스테네스의 체 (i*i부터 지우기)
temp_list = [i for i in range(N + 1)]
temp_list[0] = 0
temp_list[1] = 0

limit = int(N ** 0.5)
for i in range(2, limit + 1):
    if temp_list[i] != 0:
        start = i * i
        step = i
        for m in range(start, N + 1, step):
            temp_list[m] = 0

prime_list = [v for v in temp_list if v > 0]

# 두 포인터로 연속합 세기 (오른쪽 늘리고, N 이상이면 왼쪽 줄이기)

left = 0
right = 0
temp_sum = 0

while True:
    if temp_sum >= N:
        if temp_sum == N:
            answer += 1
        temp_sum -= prime_list[left]
        left += 1
    else:
        if right == len(prime_list):
            break
        temp_sum += prime_list[right]
        right += 1

print(answer)

사실 오늘 스터디에서 두 문제를 풀어야 했지만 한 문제는 포기

https://supabase.com/docs/guides/functions/schedule-functions https://supabase.com/docs/guides/database/vault

수퍼베이스에서 기본 제공하는 스케줄러를 사용해서 예약 30분 전 슬랙 알림을 보내는 기능을 구현했다.

service_role_key를 헤더에 하드코딩하는 미친짓을 해보기도 하고 anon, publishable 키들을 사용해 보기도 하고 cron secret이라는 임시키를 만들어서 헤더에도 넣어보고 바디에도 넣어보았지만 401 에러만 뱉고 로그를 찍지도 않는 상황이 반복됐다.

• vault로 DB에 비밀 키 저장해봐라. edge function에는 env에 키 넣어두고 비교하게 하면 헤더에 하드코딩할 필요가 없다.
• 대부분 서비스가 JWT 토큰 검증할 텐데 이것도 그런 거 아니냐?

등의 조언을 들으면서 로그를 찍어보다가, 일단 edge function이 JWT 토큰 형식으로 Authorization 헤더 검사를 하는 것 같다는 결론에 도달했다. 공식 문서에서도 anon 키를 쓰라고 되어 있어서, 쓸데없이 하던 거 다 갖다 버리고 공식 문서대로 하되 anon 키를 vault에 저장해두고 불러 쓰는 식으로 바꾸니까 됐다.

-- **실행한 sql문 정리**

-- vault에 anon key 넣기

SELECT vault.create_secret(
  'eyJ...',  -- Dashboard의 실제 anon key (JWT 형식)
  'publishable_key'
);

-- pg_cron job 업데이트 (Authorization 헤더 포함)

SELECT cron.alter_job(
  (SELECT jobid FROM cron.job WHERE command LIKE '%check-reminders%' LIMIT 1),
  command := $$
  SELECT
    net.http_post(
      url := 'https://프로젝트.supabase.co/functions/v1/check-reminders',
      headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'Authorization', 'Bearer ' || (
          SELECT decrypted_secret 
          FROM vault.decrypted_secrets 
          WHERE name = 'publishable_key'
        )
      ),
      body := '{}'::jsonb
    ) AS request_id;
  $$
);


-- 업데이트된 job 확인 (Authorization과 Bearer 포함 여부 확인용)
SELECT command 
FROM cron.job 
WHERE command LIKE '%check-reminders%';


-- 수동으로 함수 호출 테스트

SELECT
  net.http_post(
    url := 'https://프로젝트.supabase.co/functions/v1/check-reminders',
    headers := jsonb_build_object(
      'Content-Type', 'application/json',
      'Authorization', 'Bearer ' || (
        SELECT decrypted_secret 
        FROM vault.decrypted_secrets 
        WHERE name = 'publishable_key'
      )
    ),
    body := '{}'::jsonb
  ) AS request_id;

해결된 이유는... supabase key에 대한 깃허브 토론과 공식 문서에서 실마리를 찾을 수 있었다. 이런거 많이 봐야지 개발실력이 는다는 유튜브 영상을 봤는데, 트러블 슈팅할 때는 무조건 이것들부터 보는 습관을 길러야 할 것 같다.. API key가 있는 페이지만 봐서는 절대 이해 불가

https://supabase.com/docs/guides/api/api-keys https://github.com/orgs/supabase/discussions/29260

최근 Supabase는 보안 강화를 위해 anon / service_role 키 대신 publishable / secret 키 체계를 새로 도입했는데, 이 새 키들(욕 아님)은 JWT 형식이 아니다. 그래서 Authorization 헤더에 Bearer sb_publishable_... 형태로 넣으면 Edge Function이 “JWT가 아님”이라며 무조건 401을 반환한다.

반면에 기존의 anon 키는 여전히 JWT 기반이어서 기본적으로 JWT 검증이 걸려 있는 Edge Function에서도 정상적으로 인증이 통과된다. 즉, publishable 키로는 안 되고 anon 키로는 되는 이유가 바로 이 구조 차이 때문이다.

edge function에 자동으로 들어가있는 anon key는 로그 찍어보면 publishable형식이다. 그래서 DB에서 edge function 호출할 때 publishable 키를 써야 할 줄 알았지만? 요청 헤더에 JWT(= 레거시 anon 키)를 보내줘야 통과되는 구조라는 거임... 껄껄

기본 설정 그대로라면 Authorization 헤더 + JWT가 있어야 하는데, 헤더 검증을 안하게 하려면 배포 시 --no-verify-jwt 옵션을 사용했거나, 함수 설정에서JWT 검증 해 상태여야 한다고 한다. cli 가 익숙하지 않아서 edge funtion을 수동으로 배포한 사람은... 배포한 함수 페이지 -> details -> funciton configuration에서 끄면 되는 것 같다. 사이트가 많이 개편되어서인지 제대로 경로를 적어놓은 곳이 별로 없다.

AI는 anon key만 쓰거나 jwt 인증을 아예 꺼버리면 보안 쪽 문제가 있으니 cron_secret 같은 임시 키를 만들어서 요청 헤더나 body에 같이 넣고 Edge Function에서 직접 비교해서 외부 무단 접근 막으라는데 일단은 생략..

추후 변경 결국 jwt 검증 아예 끄고 랜덤값 생성한거 DB엔 valut로, edge funtion엔 환경변수로 넣음 헤더에서의 검증에서는 이 값을 사용하는걸로 바꿨음

1. DB 함수 / 프로시저

• Supabase(PostgreSQL)에서는 DB 함수가 곧 프로시저처럼 쓰임 데이터를 조회하거나 수정하는 로직을 DB 내부에 저장해두고 실행하는 코드 블록
• 실행 위치: 데이터베이스 내부
• 역할: 여러 SQL을 하나로 묶어 재사용·트랜잭션 처리에 사용
• 장점: 빠르고 일관성 있음
• 단점: DB 종속이고, 형상관리 어려움

2. 트리거 (Trigger)

• 특정 테이블에 INSERT, UPDATE, DELETE가 일어날 때 자동으로 DB 함수(프로시저)를 실행시키는 메커니즘
• 실행 위치: 데이터베이스 내부 (함수 호출자 역할
• 역할: 데이터 변경 감지 → 후속 처리 (예: 로그 기록, 알림 호출)
• 트리거 자체는 로직이 아니라 “언제 함수를 실행할지 정의한 연결 장치”

3. RPC (Remote Procedure Call)

• 정의: 클라이언트가 Supabase에 정의된 DB 함수를 원격으로 호출
• 실행 위치: Supabase API 게이트웨이를 통해 전달되어 DB 내부 함수가 실행
• 역할: REST API 없이도 데이터베이스 내부 로직(DB 함수)을 직접 호출할 수 있게 함
• 특징:
  • supabase.rpc('function_name') 형태로 호출
  • 네트워크 요청처럼 보이지만, 실제 연산은 DB 내부에서 수행되어 지연이 적음
  • DB 함수가 API처럼 동작하므로 백엔드 서버 없이도 비즈니스 로직 노출 가능

4. RLS (Row Level Security) 와 Policy

• RLS는 데이터베이스의 행 단위 접근 제어 기능, Policy는 그 RLS 위에서 구체적인 접근 조건을 정의하는 규칙
• 로그인된 사용자 정보(auth.uid())를 기준으로, 각 사용자가 자신에게 허용된 행만 조회·수정할 수 있도록 제한
• 실행 위치: DB 내부 (쿼리 실행 시점)
• 역할: “누가 어떤 조건에서 어떤 데이터에 접근 가능한가”를 정의하는 보안 레이어

5. Edge Function

• DB 밖에서 동작하는 서버리스 함수
• 실행 위치: Supabase의 Edge 네트워크 (Deno 기반 서버)
• 역할: 외부 API 호출, Slack 알림, 비즈니스 로직 등 DB에 넣기 애매한 서버 역할을 담당
• 장점: 서버 따로 안 두고 로직 추가 가능
• 단점: 형상관리·테스트 제약이 있어서 팀 규모 커지면 일반 서버 코드로 대체하는 경우 많음

DB 함수(=프로시저) 는 로직의 본체, 트리거는 그걸 자동으로 실행하는 장치, RPC는 DB 함수를 외부에서 API처럼 호출하는 통로, RLS는 접근을 제한하는 보안 규칙, Edge Function은 DB 밖에서 돌아가는 확장 로직이다.

supabase에 slack bot 연동하기

https://api.slack.com/apps/ create new app -> from a manifest -> select a workspace 해서 새 app 생성 app home -> Your App’s Presence in Slack에서 이름 바꿀 수 있음 OAuth & Permissions -> scope에서 chat:write 권한 추가, OAuth Tokens에서 install to 워크스페이스 이러면 Bot User OAuth Token 보일거임

supabase에서 bot token 사용해서 알림 보내는 트리거 함수를 edge function에 등록 settings -> edge functions -> secres에서 bot token 등록 (로컬에서 테스트할 땐 환경변수에 저장)

후술하지만 다른 방식도 있습니다

slack oicd 연동해뒀으면 Authentication에 Sign In / Providers 쪽에 slack oicd가 enabled되어 있을텐데... 봇을 쓴다고 해서 client id랑 client secret을 전부 바꿀 필요는 없는듯? 워크스페이스가 다를 때만 의미가 있는 것 같음

supabase에서 스케줄러 사용하기

문제 상황

• 30분 전 알림은 주기적 실행이 필요
• Docker 사내망 배포 환경
• 별도 스케줄러 인프라 구축 부담

해결 방법 비교

더 자세히 보면

Edge Function + pg_cron 선택 이유

1. 인프라 설정 불필요
   • 별도 서버/스케줄러 없음
   • pg_cron만 설정하면 자동 실행
2. 형상관리 가능
   • Edge Function 코드를 Git에 포함
   • 이전 Edge Function은 코드베이스에 없어 관리 어려움
3. 간단한 설정
   • SQL 한 번 실행으로 완료
   • Dashboard에서 환경 변수만 설정
4. 자동 실행
   • Supabase가 스케줄링 처리
   • 모니터링/로그 확인 용이

DB Function과 Edge Funciton -> 요즘은 안쓴다?

형상 관리가 어려워서 좀 복잡해지는 한이 있더라도 codebase로 옮기는 추세 slack 알림 연동 기능을 처음엔 edge function으로 작성했으나 코드로 마이그레이션 했음 gemini 코드 리뷰에서 원자성 보장을 위해 db function쓰는거 생각해보라 했지만 최대한 서버액션으로 처리하는걸로 결정

그러나... 주기적 알림을 추가 인프라를 만지지 않고 구현하려다보니 pg_cron을 사용하게 되면서 edge function을 다시 쓰게 되긴 했다

supabase cli로 edge function 배포하기

직접 사이트에서 edge function을 deploy해왔었는데 구글링하다가 발견.. 공식 문서를 잘 읽읍시다 https://supabase.com/docs/guides/functions/deploy post 401 에러에 마주쳤는데 이건 jwt 인증 끄고 해결..? https://github.com/orgs/supabase/discussions/33194 이건 좀 위험하다해서 cron secret을 헤더에 추가해서 검증...? 사실 이해가 좀 덜 되긴 했다. sql문 지금까지 실행하면서 policy / db함수 / edge function 만든 거 다시봐야될 것 같다.

SELECT cron.schedule(
  'check-reminders',
  '*/5 * * * *',  -- 매 5분마다
  $$
  SELECT
    net.http_post(
      url := 'https://프로젝트코드.supabase.co/functions/v1/함수이름',
      headers := jsonb_build_object(
        'Content-Type', 'application/json',
        'x-cron-secret', '임의의 값' 
      ),
      body := '{}'::jsonb
    ) AS request_id;
  $$
);

지금 당장 해야할 일들이 많이 쌓여있지만 너무 집중이 안되니까 기록이라도 하나 남겨놓으려고 오랜만에 블로그에 방문했다. 사실 그냥 조잘조잘 떠들 공간이 필요했답니다

출근 첫날엔 전반적인 회사생활에 대한 온보딩 교육, 앞으로 진행할 프로젝트에 대한 온보딩 교육을 들었다. 배정받은 장비로 작업 환경을 세팅했는데, 처음으로 맥북을 사용하게 돼서 적응하는게 쉽지 않았다. (요즘은 조금 적응했는데, 회사에서는 macOS 쓰고 집에서는 window 쓰니까 자꾸 키가 헷갈려서 킹받는다. 지금도 한영키 대신 caps lock, ctrl대신 fn 키 눌러대는 중)

업무 적응을 위해 일주일 간 토이 프로젝트를 진행하게 됐다. 회사에서 사용하고 있는 그룹웨어에서 좀 불편하게 되어 있는 기능이 하나 있는데, 그걸 확실히 개선한 시스템을 만들어서 사내망에 배포할 예정이다. 하루만에 프로젝트 범위 잡고 ERD, flow chart 작성 후, 수~금 3일간 개발을 진행했다. 처음에는 간단해보였지만, 생각보다 쉽지 않다. express, prisma, supabase, adminjs, react // potainer, nginx proxy manager, github action

이해가 안되는 게 많아도 어떻게든 기간안에 뭘 만드려고 바이브 코딩을 해댔는데, 회사에서 지원해준 cursor 팀 플랜에서 기본제공 20달러 + 청구형 50달러 사용을 달성했다. 금요일 퇴근할 때 쯤에 팀장님께서 언질주셔서 확인해보게 됐는데 ㄹㅇ 대충격 먹음 비싼 모델 막 쓴 게 문제가 된 것 같은데, 3일만에 70달러는 좀 아니잖아 징짜 cursor pro 결제해서 썼을때는 auto로 놓고 썼고 추가비용 들일도 없어서 너무 안일했다. 월급에서 깐다고 농을 하셨는데 눈치가 엄청 보였다. AI를 보조도구로만 사용해야하는 이유가 금액적인 부분에도 있는 듯 실제 프로젝트 투입되면 spring 사용할 것 같던데 더 걱정이다.

내 개발 실력을 키우는 것이 해결방안임이 자명함에도.... 일단 인턴 생활 중이니 업무 투입됐을 때 도움이 되어야 한다는 생각과 생산성 측면에서 AI를 안쓰는 건 불가능하다는 생각때문에 claude code, cursor 유료 플랜들을 막 찾아봤다. 개인적으로 이용중이던 chatGPT, cursor의 20$ 플랜 결제 중단하고 조만간 claude code의 100$ 플랜을 결제하게 될 것 같다^.^ 개비싸 진짜 IDE가 편하다고 머무르려고 하지 말고 더 성능좋고 가성비 좋은 걸 사용하자.. 회사의 지원이 어렵다면, 많은 걸 경험하고 배우는 입장이니 혼자서라도 사서 여러 방면에 사용해보자... 프롬프트 효율적으로 작성하는 법이랑 비용 아끼는 법들도 있으니 많이 찾아보자....

회사는 위치나 업무환경이 너무 좋고, 사람들도 좋다. 데일리 스크럼 참여하면서 뭐라도 한마디 내뱉는 게 아직은 어색하지만 개발팀 일원이 된 것 같아 기분이 미묘하다. 일이 많을 것 같긴 하지만, 바로 주요 업무에 투입되면서 배우는 부분이 엄청 많을 것 같다. 다만 어리벙벙한 나 때문에 동기가 고통받을 것 같아 미리 죄송함

공부를 계속하면서도 느끼는건데 개발자들은 정말 대단하다 저도 업계에서 살아남고 싶어요 흑흑 열심히 해볼게요

스프링 핵심 개념 4가지

• IoC (제어의 역전): 객체 생성과 제어 권한을 개발자 대신 스프링이 맡는 구조.
• DI (의존성 주입): 필요한 객체를 직접 만들지 않고, 스프링이 대신 넣어주는 방식.
• AOP (관점 지향 프로그래밍): 핵심 로직과 공통 기능(로깅, 보안 등)을 깔끔히 분리하는 기법.
• PSA (서비스 추상화): 다양한 기술(JDBC, JMS 등)을 추상화해 구현체가 바뀌어도 코드 변경을 최소화함.

애너테이션(Annotation)

코드에 붙이는 메타데이터(정보)로, 스프링이 그걸 보고 자동으로 동작을 설정함.

🔹 자주 쓰는 애너테이션 요약

스프링 부트 3 구조

웹 개발 팀을 꾸리기 전, 역량 개발을 위한 일주일이 주어졌다. 파이썬과 C는 해봤지만 Java는 처음이라 두렵다.. 짧은 시간 안에 흐름과 기술 기초를 익혀둬야 나중에 팀에 도움이 될 수 있으니 열심히 해보자.

오늘은 계획 짜고 개발 환경 세팅했다. 싹다 경험해보자 그냥...

IDE - cursor, intelij, vs code AI - chatGPT, copilot, gemini, claude front - HTML, CSS, JavaScript / React.js back - Java / Spring Boot / MySQL 도구 - GitHub, Docker, AWS, Figma(+makereal tldraw)

주요 기술

🖥️ 프론트엔드

⚙️ 백엔드

인프라 / 배포 등 기타 기술

• CI/CD: Jenkins, GitHub Actions — 빌드 & 배포 자동화
• 컨테이너화: Docker — 환경 일관성 적용
• 오케스트레이션: Kubernetes — 대규모 서비스 운영
• 클라우드 플랫폼: AWS, GCP, Azure — 확장성 있는 서비스 배포
• 디자인/협업 툴: Figma — UI/UX 협업에 유용

요약

• 프론트엔드는 HTML/CSS/JS 기반 위에 React, Vue 같은 프레임워크와 스타일링 도구를 쓰면 UI 구성에 빠르고 편리하다.
• 백엔드는 Java(Spring)나 Node.js(Express/Nest) 환경에서 ORM과 DB를 연결해 API 형태로 기능을 제공한다.
• 인프라나 CI/CD, 컨테이너 관련 도구는 실제 서비스 운영/배포 단계에서 도움을 준다.

📅 개인 과제 개요 및 계획

[기능 요구사항] 회원가입/로그인 게시물 작성 게시물 목록보기 게시물 읽기 댓글 작성

[개발범위] 프론트: 게시판 UI를 구현 백엔드: 게시판 Server API 구현 추가적 구현 가능 (기술적 챌린지 요소)

[인원구성 (다음중 한가지 선택)] 혼자 fullstack 개발 가능 프론트 UI만 구현할 경우 게시판 데이터는 브라우저상에서만 존재하도록 구성 또는 postman mock server를 구성해서 사용 백엔드 ServerAPI만 구현한 경우 postman등으로 요청을 직접 보내서 시연
또는 원하는 사람과 2인팀을 구성하고, 프론트/백엔드를 나누어서 개발

📍 Day 1 - Java & 객체지향 기초 다지기

• Java 기본 문법 학습 (변수, 조건문, 반복문 등)
• 객체지향 개념 정리 (클래스, 상속, 다형성, 캡슐화 등)
• IntelliJ 셋업 및 사용법 익히기
• 콘솔 게시판 간단 구현 (객체지향 감 잡기용)

📍 Day 2 - Spring Boot로 게시판 백엔드 뼈대 만들기

• Spring Boot 프로젝트 생성 (Spring Initializr)
• 기본적인 REST API 구현 (회원가입, 게시글 등록 등)
• H2 DB 연결 및 JPA 사용해보기
• Postman으로 API 테스트
• MVC 구조 익히기 (Controller, Service, Repository)
• 핵심 개념: REST API, MVC, 의존성 주입

📍 Day 3 - React 기본 학습 & 프론트 구조 잡기

• React 앱 생성 (Vite)
• JSX, 컴포넌트 구조, props, useState 등 기본기 익히기
• 게시판 UI 구성 시작 (게시글 목록, 작성 폼 등)
• Axios로 백엔드 API 연동 테스트
• 핵심 개념: 컴포넌트 분리, 상태 관리, 이벤트 처리

📍 Day 4 - 프론트-백 연동 & 주요 기능 완성

• 로그인 / 회원가입 기능 연결
• 게시글 작성 / 조회 / 상세보기 구현
• 댓글 등록 기능 구현
• 전체 기능 연동 테스트
• 중점 포인트: API 연결 흐름 이해, CORS 설정, 에러 처리

📍 Day 5 - 디버깅 & 마무리

• 기능별 예외 처리 추가
• 프론트 간단한 CSS 정리
• GitHub 업로드 및 README 작성
• 선택: 로컬 배포 or GitHub Pages/Render 사용

• 지금 쓰긴 귀찮아서 내일 수정 예정

CPU Scheduling 알고리즘

FCFS (First Come First Served)
SJF (Shortest Job First)
SRTF (Shortest Remaining Time First)
Round Robin
Multilevel Queue Scheduling

Semaphore와 Mutex Race Condition Deadlock Context Switching Multi-Level Feedback Queue Scheduler (MLFQS)

Project 1

Chapter 3. Machine-Level Representation of Programs
Chapter 12. Concurrent Programming

클라이언트-서버 모델 웹페이지

소켓(socket, bind, listen, accept, connect, close)웹페이지

파일 디스크립터 웹페이지

Datagram Socket vs Stream Socket웹페이지

CGI / WebServer / MIME Type웹페이지

HTTP (요청/응답, 헤더, 메소드, 상태코드, HEAD 메소드)웹페이지

Proxy

BSD소켓, IP, TCP, HTTP, file descriptor, DNS