개발하는남자

[ 플러터 개발 환경설정 ] 내 컴퓨터 이름 한글 사용자명으로 인한 Windows 개발 환경 설정 문제 해결법

수달e — Sun, 22 Sep 2024 17:19:00 +0900

안녕하세요 개발하는남자 개남입니다.

오늘은 개발하는남자의 핸즈온 플러터에서 개발환경설정 파트에서 언급하고 싶은 부분이 있어서 이렇게 준비하게 되었습니다. 개발자로 일하시는 분들중 앱 개발자분들 중에는 맥에서 개발을 하는 경우가 많습니다. 이유는 iOS 대응 때문입니다. 저 역시 맥에서만 개발을 하다보니 윈도우 환경에서의 발생될 수 있는 문제에 대해서 크게 인지를 하지 못했었습니다. 그래서 책에도 개발환경 설정에 대한 가이드만 있었고 이슈에 대한 내용은 추가하지 못했습니다. 하지만 윈도우로 개발환경 설정하는 분들중 많은 분들이 윈도우 PC를 사용하시면서 사용자 이름을 한글로 설정하시는 분들이 많다는 것을 느꼈습니다. 그런경우 개발공부를 호기롭게 시작했는데 시작하기도전에 개발환경 세팅하면서 진을 다 빼시는 분들에게 이 포스팅이 도움이 되었으면 좋겠습니다.

Q : PC에 한글을 사용한 경우 왜 개발에서 문제가 발생될까?

A : 여러 가지 IDE나 개발 sdk의 경우 대부분이 영문 기반으로 설계되어 있어서 비 ASCII 문제들이 경로에 있을 경우 해석하는 데에 문제가 발생되곤 합니다. 특히 Android SDK나 Gradle과 같은 Java 기반의 툴들은 비 ASCII 문자가 있는 경우 파일을 찾지 못하는 문제가 있습니다

해결방안

PC 포멧 후 재 설치
PC에 사용자이름을 영문으로 변경하여 처리하는 방법
개발환경의 위치를 한글이 포함되지 않는 경로로 새로 세팅하는 방법

이 포스팅에서는 해결방안 3번째 방식으로 문제를 풀어가보겠습니다.

개발 환경 설정 시 마주할 수 있는 오류를 해결하기 위한 절차

Flutter SDK 설치 경로
안드로이드 스튜디오 설치시 sdk 위치
vsCode 설치 위치
Flutter doctor 명령 실행시 android sdk 찾을 수 없는 문제
안드로이드 애뮬레이터 문제

1. Flutter SDK 설치 경로

1. 플러터 SDK 다운로드 받기 [링크]

2. zip파일 압축 풀기

3. 압축푼 파일 C:\ 경로의 sdk 폴더를 생성하고 그곳에 위치 하도록 합니다.

4. flutter 명령실행파일의 경로를 환경변수에 등록합니다.

C:\\경로의 sdk 폴더 하위로 위치 시켰다면 다음과 같은 경로를 환경변수에 등록하면 됩니다.

경로 복사 : C:\\sdk\\flutter\\bin

5. terminal 을 열어 flutter —version 명령어를 실행합니다.

플러터 버전이 정상적으로 표시되는 것을 확인할 수 있습니다.

2. 안드로이드 스튜디오 설치

1. 안드로이드 스튜디오 설치 프로그램 다운로드 받습니다. [링크]

2. 안드로이드 슈튜디오 설치를 진행합니다.

별도의 설정없이 Next버튼으로 설치를 완료합니다.

3. 안드로이드 스튜디오 위저드 설정 창이 활성화가 자동으로 되며 Next버튼으로 설치를 이어서 진행합니다.

Android SDK 설치 위치를 설정하는 창에서 오류가 발생하게 됩니다.

이유는 Android에서 기본적으로 default SDK 설치 위치를
C:\Users\[컴퓨터 사용자이름]\AppData\Local\Android\Sdk
로 설정되어있기 때문입니다. 이때 컴퓨터의 설정한 사용자 이름을 한글로 지정한 경우 ASCII 문자오류로 인해 설치를 할 수 없다고 오류를 발생시키고 있는 것입니다.

해결방법

android sdk 설치 경로를 C:\하위에 sdk 폴더를 플러터 sdk 설치했던 대로 위치를 변경해주면 됩니다.

3-1. Android SDK Location 경로 우측 폴더 아이콘 클릭

3-2. C:\의 sdk 폴더를 선택한 뒤 상단의 폴더 생성 아이콘 클릭합니다.

3-3. 폴더 생성창에 android 라는 이름을 입력하고 OK버튼을 눌러줍니다.

3-4. 생성된 android폴더가 C:\sdk\ 폴더 내부에 생성되었는지 확인하고 android 폴더를 선택하고 OK 버튼을 눌러줍니다.

3-5. 이전과 달리 새로운 경로에는 한글이 포함되어있지 않아 오류가 없어진 모습을 확인할 수 있습니다.

4. 라이선스 동의

5. 설치가 진행됩니다.

설치가 완료 되고 나면 안드로이드 스튜디오가 실행되며 안드로이드 스튜디오가 설치가 완료 된 것입니다.

3. vsCode 설치

1. vsCode 사이트에 접속하여 다운로드 파일을 받아줍니다. [링크]

2. 설치 프로그램 실행하여 약관동의 후 설치를 진행합니다.

3. 설치 경로에 한글이 포함되어있어서 우측 찾아보기 메뉴를 통해 경로를 변경해줍니다.

4. 다른 sdk 경로와 마찬가지로 C:\의 sdk 폴더를 선택해주고 확인 버튼눌러줍니다.

5. 다음과 같이 경로가 설정되었다면 다음버튼틀 통해 설치를 진행합니다.

6. 설치가 정상적으로 되는 것을 확인합니다.

4 . Flutter Doctor 이슈 대응

안드로이드 SDK를 찾을 수 없는 문제

flutter에서 android sdk를 통해 명령실행을 수행하게 되는데 기본적으로 flutter에서 android sdk 위치를 C:\\Users\\[컴퓨터 사용자 이름] 하위에서 sdk를 찾기 때문에 발생되는 문제로 우리는 한글 폴더가 포함되어있어서 android sdk의 설치 위치를 변경해줬기 때문에 flutter에서는 찾을 수 없는 현상입니다.

친절하게 android-sdk 경로를 새로 지정하는 방법에대해서 가이드를 해주고 있습니다.

flutter config —android-sdk 명령어를 사용하라고 flutter doctor가 알려주고 있습니다.

android sdk를 C:\\sdk\\android 위치로 설정한 사실을 기억하기 때문에 위 명령어를 다음과 같이 실행하면 문제가 해결이됩니다.

flutter config —android-sdk="C:\\sdk\\android"
실행 이후 다시 flutter doctor를 사용하면 android sdk 경로를 찾지 못한다는 경고 메세지는 없어진것을 확인 할 수 있습니다.

flutter doctor라고 입력하시면 다음과 같이 문제가 해결된 것을 확인 할 수 있습니다.

물론 다른 문제가 있다고 가이드 하고 있지만 그것은 오류가 아닌 경고로 해결하지 않아도 되지만 해결하는 방법은 간단합니다. 그 방법은 제 책[개발하는남자 핸즈온 플러터] 64페이지 ~ 67페이지 를 참조 하시면 문제를 쉽게 해결할 수 있습니다.

5 . Android 애뮬레이터 이슈

1. 안드로이드 애뮬레이터를 설치를 하기 위해 안드로이드 스튜디오를 실행합니다.

more Actions 메뉴 클릭

Virtual Device Manager 실행합니다.

2. Device Manager 창에서 좌측 상단 + 버튼을 통해 생성단계로 진행합니다.

원하는 디바이스를 선택해서 Next 진행합니다.

애뮬레이터 이름을 설정하거나 별도의 애뮬레이터의 설정을 진행하고 Finish 버튼을 눌러줍니다.

3. Device Manager 창에 방금전에 만들었던 애뮬레이터가 리스트에 추가된 것을 확인 할 수 있습니다.우측 Play 아이콘 버튼을 눌러 애뮬레이터를 실행해보겠습니다.

실행이 되려다 다음과 같은 알 수 없는 오류가 발생되고 있음을 확인 할 수 있습니다.

문제 요인

이번 역시 애뮬레이터 설치 경로에 한글이 포함되어있어서 발생된 문제 입니다. 그 이유를 살펴보겠습니다.

안드로이드 sdk 설치 위치는 변경했지만 애뮬레이터 설치 위치는 바꿔주지 않아서 디폴트 위치인 C:\\사용자\\[컴퓨터 사용자 이름] 하위로 .android 라는 폴더가 생성되어 있는 것을 확인 할 수 있습니다.

아래와 같이 .android 폴더 내부에 avd 폴더가 있으며 해당 폴더 내부에는 좀 전에 만들어줬던 애뮬레이터 이름으로 폴더가 생성되어있는 것을 확이 할 수 있습니다.

환경변수 설정

환경 변수를 추가 하기 위해서 환경변수 설정창을 실행합니다.

환경변수 창에서 하단 시스템 변수(S) 영역의 새로만들기 메뉴를 선택해 줍니다.

새 시스템 변수에 변수 이름과 변수 값을 입력합니다.

변수 이름 : ANDROID_HOME 이라고 입력합니다.

변수 값 : 새로 설정한 경로 C:\\sdk 입력

확인 버튼 후 다시 새로 만들기 버튼을 눌러 하나의 변수와 값을 입력합니다.

변수 이름 : ANDROID_SDK_HOME 이라고 입력합니다.

변수 값 : 새로 설정한 경로 C:\\sdk 입력

이제 다시 애뮬레이터 생성부터 실행과정을 새로 진행해주면 정상적으로 실행되는 것을 확인 할 수 있습니다.

이것으로 안드로이드에서 한글 경로가 포함되어있어서 발생될 수 있는 이슈들을 해결하는 방법에 대해서 알아보았습니다

[개발하는남자의 핸즈온 플러터] 플러터 최신 버전 소스코드 android build.gradle migration 책의 잘못 표기된 내용 정정 및 소통 채널 공지

수달e — Sun, 25 Aug 2024 23:10:25 +0900

내 여러분 안녕하세요 개발하는남자 개남입니다. 핸즈온 플러터 책이 출간된 지 어느덧 한 달이라는 시간이 흘렀습니다.

(시간이 참 빠른것 같습니다.)

한 달이라는 시간이 흐르는 동안 독자분들의 문의 이메일도 주시고 계시는데 생각해 보니 소통 채널이 있으면 좋겠다 싶어서 관련 내용도 공유드릴 겸 책에 잘못 기재된 내용에 대한 정정 사항도 안내해 드리고 그리고 무엇보다 중요한 당근마켓 클론코딩을 위한 플러터 버전 최신화 대응 방안에 대해서 가이드를 드려야 할 것 같아 이렇게 포스팅을 쓰게 되었습니다.

책에 잘못 표기된 내용 (타입추론) 기본 개념

우선 타입추론에 대해서 간단하게 설명드리고 잘못된 내용에 대해서 공유 드리겠습니다.

예를 들어 다음과 같이 변수를 선언 시 명시적으로 타입을 정의하는 것과 타입추론을 사용하는 것의 차이입니다.

String data = "개발하는남자";
var dataTypeInference = "개발하는남자";

컴파일러는 둘 다 String 타입으로 인식하여 프로세스를 처리하게 됩니다. 하지만 위의 경우 String타입이 아닌 다른 타입으로 변경해야 하는 요구사항이 생겨서 수정을 하게 된다면 명시적 타입을 사용한 경우는 오류를 범하지만 아래의 타입추론으로 사용한 경우는 오류가 생기지 않습니다.

String data = {"name": "개발하는남자"}; // type 오류
var dataTypeInference = {"name": "개발하는남자"};

위의 변수 data의 경우 Type 오류가 발생하는 반면 아래 dataTypeInference의 경우 자동적으로 Map타입으로 인식하고 정상적으로 프로세스를 진행할 수 있음을 확인할 수 있습니다.

이처럼 타입추론을 활용하면 코드를 유연성 있게 대응할 수 있다는 장점이 있습니다.

핸즈온 플러터에서 타입추론 잘못 표기된 내용 공유

핸즈온 플러터 96페이지에 기록된 Map 타입의 타입추론 관련 잘못 표기된 내용이 있습니다.

위 글에서 var blankUserInfo = {};라고 변수를 선언하면 타입추론으로 자동적으로 Map으로 처리하게 됩니다.

하지만 글에서는 Map이 아닌 Set타입으로 선언된다고 잘못 기재되어있습니다.

만일 Set타입을 타입추론으로 하기원 할 때는 다음과 같이 사용해야 합니다.

var setTypeInference = <String>{};

관련된 내용은 93페이지에서 이미 다루고 있는 내용입니다.

다시 한번 혼란을 드려서 죄송합니다. 이 부분은 만약 다음 2판 인쇄를 할 수 있게 된다면 정정해서 올리도록 하겠습니다.

당근마켓 클론코딩 플러터 3.24.0 버전 대응

책을 집필할 당시 플러터 버전은 3.13.x 버전대였던 것으로 기억합니다. 플러터의 버전이 3.16.x 버전부터 안드로이드 build.gradle 방식이 변경되었습니다.

To build a Flutter app for Android, Flutter's Gradle plugins must be applied. Historically, this was done imperatively with Gradle's legacy, imperative apply script method.

In Flutter 3.16, support was added for applying these plugins with Gradle's declarative plugins {} block (also called the Plugin DSL) and it is now the recommended approach. Since Flutter 3.16, projects generated with flutter create use the Plugin DSL to apply Gradle plugins. Projects created with versions of Flutter prior to 3.16 need to be migrated manually.

한마디로 3.16 버전이전에 생성된 플러터 프로젝트와 그 이후의 플러터 프로젝트는 Gradle처리방식이 변경되었다고 보시면 됩니다. 그래서 제가 제공드리는 플러터 프로젝트는 이전 버전이기 때문에 마이그레이션을 수동으로 해줘야 하는 상황이 발생하게 되었습니다. 관련해서 플러터 공식문서에서 자세하게 다루고 있기 때문에 해당 내용을 따라서 수행하시면 큰 문제없이 migration을 할 수 있을 것입니다.

개발하는 남자 Github에 제공된 당근마켓 클론 코딩 소스코드에 flutter-version/3.24.0 브런치로 최신 버전 대응된 소스코드를 공유드렸으니 필요하신 분들은 그 소스코들 참조하시면 됩니다.

Android Build Gradle 마이그레이션 하는 방법

1️⃣ `/android/settings.gradle` 대응

<app-src>/android/settings.gradle 파일을 다음과 같이 수정합니다.

pluginManagement {
    def flutterSdkPath = {
        def properties = new Properties()
        file("local.properties").withInputStream { properties.load(it) }
        def flutterSdkPath = properties.getProperty("flutter.sdk")
        assert flutterSdkPath != null, "flutter.sdk not set in local.properties"
        return flutterSdkPath
    }()

    includeBuild("$flutterSdkPath/packages/flutter_tools/gradle")

    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

plugins {
    id "dev.flutter.flutter-plugin-loader" version "1.0.0"
    id "com.android.application" version "{agpVersion}" apply false
    id "org.jetbrains.kotlin.android" version "{kotlinVersion}" apply false
}

include ":app"

여기서 중요한 점은

id "com.android.application" version "{agpVersion}" apply false
id "org.jetbrains.kotlin.android" version "{kotlinVersion}" apply false

{agpVersion} 과 {kotlinVersion} 이 부분을 그대로 두는 게 아닌 해당하는 버전을 넣어줘야 합니다. {agpVersion} 과 {kotlinVersion} 두 개의 버전을 어디서 참조해서 넣어야 하는지는 <app-src>/android/build.gradle 파일을 열어보면 나와있습니다.

buildscript {
    **ext.kotlin_version = '1.7.10'
    repositories {
        google()
        mavenCentral()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:**7.3.0'
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.buildDir = '../build'
subprojects {
    project.buildDir = "${rootProject.buildDir}/${project.name}"
}
subprojects {
    project.evaluationDependsOn(':app')
}

tasks.register("clean", Delete) {
    delete rootProject.buildDir
}

붉은색 코드의 버전이 각각 {agpVersion} 과 {kotlinVersion} 에 해당되는 버전입니다.

{kotlinVersion}이 1.7.10 이며 {agpVersion}이 7.3.0으로 적용하면 되겠습니다.

그리고 당근마켓 클론코딩 프로젝트에서는 google-services 플러그인도 사용하고 있기 때문에

다음과 같이 <app-src>/android/settings.gradle 파일을 수정하면 되겠습니다.

pluginManagement {
    def flutterSdkPath = {
        def properties = new Properties()
        file("local.properties").withInputStream { properties.load(it) }
        def flutterSdkPath = properties.getProperty("flutter.sdk")
        assert flutterSdkPath != null, "flutter.sdk not set in local.properties"
        return flutterSdkPath
    }()

    includeBuild("$flutterSdkPath/packages/flutter_tools/gradle")

    repositories {
        google()
        mavenCentral()
        gradlePluginPortal()
    }
}

plugins {
    id "dev.flutter.flutter-plugin-loader" version "1.0.0"
    id "com.android.application" version "7.3.0" apply false
    id "org.jetbrains.kotlin.android" version "1.7.10" apply false
    id "com.google.gms.google-services" version "4.3.14" apply false
}

include ":app"

2️⃣ 기존 `/android/build.gradle` 소스코드 수정

해당 파일에서 대응하던 `buildscript` 이부분이 `/android/settings.gradle` 이곳으로 옮겨져서 관리 되고 있기 때문에 `/android/build.gradle` 파일의 `buildscript` 부분을 제거합니다.

allprojects {
    repositories {
        google()
        mavenCentral()
    }
}

rootProject.buildDir = '../build'
subprojects {
    project.buildDir = "${rootProject.buildDir}/${project.name}"
}
subprojects {
    project.evaluationDependsOn(':app')
}

tasks.register("clean", Delete) {
    delete rootProject.buildDir
}

3️⃣ `/android/app/build.gradle` 소스코드 수정

그리고 가장 최상단에 다음과 같이 소스코드를 추가하라고 소개하고 있습니다.

plugins {
    id "com.android.application"
    id "kotlin-android"
    id "dev.flutter.flutter-gradle-plugin"
}

<app-src>/android/app/build.gradle

plugins {
    id "com.android.application"
    id "kotlin-android"
    id "dev.flutter.flutter-gradle-plugin"
    id "com.google.gms.google-services"
}

def localProperties = new Properties()
def localPropertiesFile = rootProject.file('local.properties')
if (localPropertiesFile.exists()) {
    localPropertiesFile.withReader('UTF-8') { reader ->
        localProperties.load(reader)
    }
}

def flutterVersionCode = localProperties.getProperty('flutter.versionCode')
if (flutterVersionCode == null) {
    flutterVersionCode = '1'
}

def flutterVersionName = localProperties.getProperty('flutter.versionName')
if (flutterVersionName == null) {
    flutterVersionName = '1.0'
}

android {
    namespace "com.devman.cloneapp.bamtol_market_app"
    compileSdkVersion flutter.compileSdkVersion
    ndkVersion flutter.ndkVersion

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }

    kotlinOptions {
        jvmTarget = '1.8'
    }

    sourceSets {
        main.java.srcDirs += 'src/main/kotlin'
    }

    defaultConfig {
        // TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html).
        applicationId "com.devman.cloneapp.bamtol_market_app"
        // You can update the following values to match your application needs.
        // For more information, see: https://docs.flutter.dev/deployment/android#reviewing-the-gradle-build-configuration.
        minSdkVersion 23
        targetSdkVersion flutter.targetSdkVersion
        versionCode flutterVersionCode.toInteger()
        versionName flutterVersionName
    }

    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
        }
    }
}

flutter {
    source '../..'
}

dependencies {
}

이것으로 안드로이드 마이그레이션은 끝이 납니다.

그리고 프로젝트의 라이브러리를 최신 버전으로 올려줘야 합니다. 특히 파이어베이스 관련 라이브러리는 최신 버전으로 반드시 올려줘야 문제없이 사용이 가능합니다.

다음은 flutter pubspec.yaml 파일에 사용된 최신버전 라이브러리 목록입니다.

  cupertino_icons: ^1.0.2
  get: ^4.6.5
  flutter_svg: ^2.0.7
  equatable: ^2.0.5
  google_fonts: ^4.0.4
  firebase_core: ^3.3.0
  firebase_auth: ^5.1.4
  cloud_firestore: ^5.2.1
  firebase_storage: ^12.1.3
  shared_preferences: ^2.1.2
  google_sign_in: ^6.2.1
  sign_in_with_apple: ^6.1.1
  crypto: ^3.0.3
  photo_manager: ^3.2.3
  flutter_map: ^5.0.0
  geolocator: ^9.0.2
  latlong2: ^0.9.0
  uuid: ^3.0.7
  carousel_slider: ^5.0.0
  cached_network_image: ^3.2.3
  timeago: ^3.5.0
  flutter_keyboard_visibility: ^5.4.1

모든 라이브러리를 최신버전화 하지 않았습니다. 문제가 되는 라이브러리들만 버전을 최신화했으며 문제없는 라이브러리는 그대로 유지하였습니다. 이것으로 플러터 최신버전 대응에 대한 내용을 가이드해드렸습니다. 따라 하시다 문제가 생기셨다고 한다면 github에 flutter-version/3.24.0 브런치를 참조해주시면 되겠습니다.

소통 채널 소개

마지막으로 유튜브 구독자들이나 책을 읽으면서 공부하시는 독자분들 모두 소통채널이 있으면 좋겠다고 생각이 되었습니다. 지금까지는 별도의 채널이 없었어서 메일로 문의하시는 분들에 한에서 답변을 드리고 있었는데 공부하시는 분들끼리도 서로 소통하면서 문제를 해결할 수 있지 않을까?라는 생각으로 소통채널을 만들었습니다. 물론 라이브 방송을통해 직접적인 소통도 하고 싶긴한데 아직 둘째가 어려서 아이가 통잠을 자기 시작하면 늦은 밤에는 가능하지 않을까? 라는 생각도 들기도 하고요 그것은 차차 계획해 보도록 하고 소통채널 디스코드를 만들었습니다. 참여는 자유고 함께 공부하면서 궁금한 사항들에 대해서 서로 공유하고 같이 문제를 해결해 나가는 취지로다가 만든 것이니 부담 없이 자유롭게 소통하면 좋을 것 같습니다.

사실 채널이 활성화될지도 의문이고 참여자가 있을지도 의문이긴 한데 제가 성실하게 답변을 드릴 수 있을지도 솔직히 의문입니다. 제가 유튜브 채널만 운영한다면 가능하겠지만 제가 회사를 다니고 있다 보니 주중 업무시간에는 답변드릴 수 없다는 것과 퇴근 후에는 육아를 하게 되기 때문에 늦은 시간에만 답변을 드릴 수 있어서 과연 어느 정도 운영이 될지 모르겠지만 그래도 고민만 하기보다는 시도해 보는 게 좋겠다는 생각이 들어서 만들게 되었습니다.

디스코드 주소 : https://discord.gg/Xd7W7WTM

개발하는남자 Discord 서버에 가입하세요!

Discord에서 개발하는남자 커뮤니티를 확인하세요. 3명과 어울리며 무료 음성 및 텍스트 채팅을 즐기세요.

discord.com

[플러터 책] 개발하는남자의 핸즈온 플러터 출시되었습니다. , 책소개 , 이벤트

수달e — Wed, 24 Jul 2024 19:07:32 +0900

내 여러분 안녕하세요 개발하는남자 개남입니다.

23년 초 제 스스로 새로운 도전을 시작하게 되었습니다. 바로 책을 집필해 보는 것이었습니다. 책을 집필해 보면서 많은 과정이 있었고 많은 분들이 책 한 권을 펴내는데 수고하신다는 것 또한 알게 되었습니다. 마침내 준비해 오던 책이 드디어 출간되어 책에 대한 내용은 간단하게 기록하고자 합니다.

이 책에 대한 간단한 소개를 드릴텐데 그것만 있으면 아쉬우니 출판사로부터 책을 여럿 받았습니다. 그래서 이벤트를 통해 책을 발송드리고자 합니다. 이 글을 읽으시는 시점이 24년 7월 29일 이전이라면 이벤트를 참여하실 수 있습니다. 관련 내용은 유튜브 영상을 참고해 주세요

https://www.youtube.com/watch?v=DGyIv7Lgr94

이 책의 구성

이 책은 총 2파트로 나뉘어져있습니다.

첫 번째 파트

첫 번째 파트는 초심자들도 쉽게 보실 수 있도록 dart 기본 문법부터 dart 3.0에서 새롭게 생긴 record나 패턴매칭 등 신규 기능들도 정리해 놓고 있으며 상태관리 bloc과 getx에 대해서 심도 있게 다루고 있습니다. 그리고 API의 기본 개념부터 직접 간단한 API를 사용해서 화면을 그려보는 것을 통해 API를 설명하고 있으며 파이어베이스 연동까지 다루고 있습니다. 1부의 마지막은 앱을 배포하는 과정을 android / iOS 모두 소개하고 있습니다.

두 번째 파트

두 번째 파트는 앞에서 다루고 학습을 토대로 응용앱을 만들어 보는 과정을 다루고 있는데 쉬운 앱들을 만들어보는 과정으로 할지 아니면 클론코딩을 할지 고민을 했는데 클론코딩을 통해 현업에서 서비스되는 기능을 구현해 보면서 노하우들을 같이 설명하는 것이 좋을 것 같다고 생각했습니다 그래서 제 유튜브 채널 중에 가장 많은 조회수를 기록하고 지금도 시청하고 계시는 분들이 계셔서 당근마켓 클론코딩을 만들어가는 과정을 담게 되었습니다.

아마 제 채널에 구독중이신부들은 한번 정도는 보셨을 것 같은데 아마 공감하실 부분이 영상이 오래되었다는 것입니다.

개발하는남자[ Flutter / 플러터 ] 당근마켓 홈 화면을 플러터로 만들어보자 #1

24년 기준으로 3년 된 영상이고 플러터 버전도 지금은 3이지만 그 당시의 버전은 1로 만들어지다 보니 따라서 학습하기에 다소 어려움이 있었으리라 생각됩니다. 그래서 책에서는 플러터 버전 3으로 개발을 할 수 있도록 최신화를 했으며 당근마켓의 클론코딩인 만큼 UI 역시 최신 버전으로 새롭게 대응하여 공부할 수 있도록 정리하였습니다.

다음은 이번 책에서 다루려고 하는 당근마켓 기능명세입니다.

앱소개 및 초기 시스템 로드를 위한 스플레시 페이지 기능
SNS 로그인(구글/apple) 회원 인증 기능
상품을 등록하기 위한 이미지 업로드 기능
거래 희망지역을 설정할 수 있는 지도 연동 기능
상품이 마음에 들어 관심상품으로 관리하기 위한 좋아요 기능
상품 판매자와의 거래 조율을 위한 채팅 기능

다음은 이번 책에서 개발될 화면 결과물입니다.

솔직히 말씀드리자면 2부 당근마켓 파트는 초심자 분들에겐 다소 어려운 파트일 것입니다. 왜냐하면 현업에서 유지보수를 목적으로 파일관리라던지 의존성분리라던지 여러 가지 많은 기능들을 고려해 설계된 프로젝트라서 따라오기 어려울 수 있습니다만 최대한 문제없이 책에 기술하려고 노력했으니 도전해 보시는 것도 좋은 공부 방법이 될 것입니다.

이렇게 총 2개의 파트로 나눠 구성을 했습니다. 많은 내용을 자세히 다루고 싶다 보니 초기에 출판사 측과 500page를 계획하였지만 어쩔 수 없이 800page이상으로 가야 할 것 같다고 협의하여 책의 분량이 다소 길다는 점 참고해 주세요 ㅎㅎ

개발하는 남자의 핸즈온 플러터 책으로 재미있게 공부하길 기원하며…

감사합니다.

교보문고 : https://bit.ly/3WjeEEC

예스 24 : https://bit.ly/3Wz4UaU

[영성온도] 말씀묵상 기록 앱 만들기

수달e — Tue, 2 Jul 2024 19:00:56 +0900

다들 묵상을 어떤 식으로 하시나요?

대부분은 말씀을 읽고 느낀부분을 깊이 묵상하고 기도하고 삶에 적용하는 방식으로 묵상을 하실 것이라 생각됩니다.

몇몇 분은 자신만의 다이어리에 말씀 묵상 중 느낀 점을 기록하시는 분들도 있을지 모르겠습니다.

저의 경우 말씀묵상을 기록하는 편입니다. 기록한 부분을 언젠가 읽어볼때가 있었는데 그 당시의 힘든점이 무었이었고 그때의 나의 신앙의 상태를 기억할 수 있었던 것이 좋았습니다. 그러던 중 주일 설교말씀에 말씀 묵상을 기록하는것이 좋으며 그 기록이 언젠가 다시 꺼내서 읽게 되었을때 그당시의 나만의 신앙의 역사를 알 수 있을 것이라는 목사님의 설교말씀에 내가 경험하고 추구 하는 부분이 괜찮은 말씀 묵상 방법이라는 것을 알게 되었습니다. 그러면서 그런 방식의 묵상을 도와주는 앱을 만들어서 많은 사람들에게 전하고 싶다는 생각이 들었습니다.

영성온도

| 온도시스템

말씀묵상하는것에 가장 어려운부분은 꾸준함이 아닐까 생각했습니다. 저 부터가 매일같이 묵상하기란 쉽지 않았기 때문에 꾸준하게 말씀묵상을 하게 할 수 있는 원동력이 있다면 좋겠다고 생각했으며 그것을 주님과의 친밀감을 온도로 표현해서 영성의 온도를 시각적으로 노출시켜 동기부여를 하면 좋을 것 같다는 생각을 했습니다.

| 나만의 묵상집

기록앱답게 언제기록했는지 히스토리를 리스트 별 혹은 달력뷰로 한눈에 확인 할 수 있도록 제작하였습니다. 그리고 아직 계획일 뿐이지만 연말에 희망하시는 분을 받아서 책으로 만들어 발송을 드릴 예정입니다. 1년간 묵상한 내용을 책으로 받아볼 수 있다니 정말 기대되지 않나요??

| 그룹나눔

처음에는 개인 묵상으로만 개발 방향성을 잡고 개발을 했는데 와이프와의 공통된 말씀 구절로 각자의 주신 말씀이 무엇일지 서로 나누면 좋을 것 같다는 생각에 그룹 나눔기능을 할 수 있도록 개발을 하게 되었습니다. 그룹 나눔역시 참여율에 따라 그룹의 온도역시 올라가도록 설계 하여 공통된 동기를 주고자 했습니다. 최대 3개의 그룹을 만들거나 참여 할 수 있도록 개발되었습니다.

저의 묵상 앱 개발 여정은 개인적인 영적 성장과 다른 사람들과의 나눔을 도모하는 소중한 경험이었습니다. 말씀 묵상을 통해 나만의 신앙 역사를 기록하고, 영성의 온도를 시각화하여 꾸준한 묵상을 도울 수 있기를 바랍니다. 또한, 그룹 나눔을 통해 서로의 신앙을 나누며 함께 성장하는 기회를 제공하고자 합니다.

이 앱이 많은 분들에게 말씀 묵상의 기쁨과 주님과의 친밀감을 더욱 깊게 느끼게 해줄 수 있기를 바랍니다. 함께 주님의 말씀을 나누고, 기록하며, 성장해가는 아름다운 여정을 함께 만들어 나가길 소망합니다. 여러분의 묵상이 풍성해지기를 기도합니다. 감사합니다.

다운로드 경로

iOS : https://apps.apple.com/kr/app/%EC%98%81%EC%84%B1%EC%98%A8%EB%8F%84/id6479955038

‎영성온도

‎영성 온도는 주님의 말씀을 묵상하며 신앙생활의 깊이를 새롭게 탐색하고자 하는 기독교인들을 위한 앱입니다. 매일매일의 묵상을 기록하고, 그 과정에서 하나님과의 친밀도를 온도 형태로

apps.apple.com

android : https://play.google.com/store/apps/details?id=com.sudarlife.spirituality_temperature_diary&hl=ko&gl=US

영성온도 : 매일 성경 말씀 묵상 기록 - Google Play 앱

주님과의 친밀도를 온도로 확인하며 매일의 묵상을 기록하고 성장하세요.

play.google.com

[플러터 Bloc 마스터] 왜 Bloc을 사용하는가?

수달e — Wed, 1 Feb 2023 22:52:24 +0900

내 여러분 안녕하세요 개발하는 남자 개남입니다.

왜 Bloc을 사용해야 하는가? 에 대해서정리해보겠습니다.

모든 내용은 Bloc 공식 문서를 바탕으로 정리한 내용입니다.

Bloc State Management Library

Official documentation for the bloc state management library. Support for Dart, Flutter, and AngularDart. Includes examples and tutorials.

bloclibrary.dev

Bloc은 플러터의 상태관리를 도와주는 패키지로써 Bloc 외에도 Getx, Riverpod, Provider 등 각자의 방식으로 개발자들에게 상태관리를 도와주고 있습니다. 이 시점에서 상태관리를 왜 사용해야 하는지 모르시는 분들의 경우 제가 정리한 영상 오랜 영상이긴 하지만 내용을 들어보시면 도움이 되실 것입니다. 한번 보고 오시는 것을 추천드리겠습니다.

Bloc을 사용해야 하는 이유 5가지

1. 뷰 영역과 비즈니스 영역을 쉽게 구분할 수 있다.

여기서 뷰의 영역은 화면 UI부분을 뜻하며 사용자의 액션( 터치, 버튼버튼 클릭, 텍스트 필드 입력 등)을 받아 이벤트 을 발생시키는 영역을말합니다. 비즈니스영역은 사용자의 입력에 따라여러 가지 기능(검색,회원가입, 글 등록, 상품 좋아요 등)을 수행하게 되는데 사용자들은 대부분 어떤 과정을 통해 기능을 수행하는지 알 필요가 없고 관심도 없습니다. 단지 빠른시간 내에 응답을받고 원하는 데이터를 보기를 원할 뿐이죠. 그러한 사용자의 요청을 빠르게 수행하기 위해 로직을 작성하게작성하게 되는 부분을 비즈니스영역이라고 말합니다.

뷰와 비즈니스 영역은 서로 상호작용되어 결과를도출해 주는 집합체가하나의 서비스가 되는 것이죠.

그럼 뷰와비즈니스가한대뷰와 비즈니스가 한대 어우러져서 개발하는 것이 편하지편하지 않을까? 사용자의 버튼 입력을 받고 바로 해당되는 로직을 수행하면 관리도 편하고 좋은데 왜 뷰와비즈니스영역을 쉽게구분하는 것이 장점이되는 것일까요? 물론 개발을할 때 빠르게개발할 수 있기도 하고 복잡성도 덜할 수 있습니다. 하지만 그런 코드의 경우 유지보수가 매우어려워지게됩니다매우 어려워지게 됩니다. 화면을화면을 수정해야 하는데 비즈니스로직이 함께버무려져있다 보니 가독성도어렵고 압박적인라인수로 인해화면 수정에 시간이 길어지게 되는 문제가 발생할 수 있습니다. 그래서 이를 해결하기 위해 mvc 나 mvvm 패턴이패턴이 나온 것이죠. bloc이나 다른 상태관리 라이브러리들도 기본적으로 뷰/비즈니스 영역을 구분하는 것이 기본 베이스가 아닐까 생각이 됩니다. 물론 아직 riverpod는 잘 모르겠지만 말이죠. 뷰에 문제가 있으면 뷰에 집중할 수 있고 로직에 문제가 있으면 로직 부분만 집중해서 작업할 수 있어서 아주 좋은 방식이라고 볼 수 있습니다.

2. 테스트하기 쉽고(TDD), 재사용을 가능하게 해 준다.

TDD를 중점적으로 활용하는 개발자의 경우 장점이 될 수 있습니다. bloc_test 라이브러리를 제공해주고 있어서비즈니스로직을 직접 UI로 확인하여테스트하는것보다 훨씬 빠르게 체크를 할 수 있으며 다양한 상황을 사전에테스트해볼수 있어서 개발에 큰 도움이 되는 부분이기도 합니다. 예를 들어 회원가입에 관한비즈니스로직을작업했는데 이를테스트하기위해서이를 테스트하기 위해서. TDD가 없다면 직접 화면에여러 가지 입력값을넣고 하나하나 다양한 예외 상황을 고려하여 직접 수행을 통해 버그등을 찾아 수정해야 하는 작업이 있습니다. 이러한 작업은 번거롭고 시간도 많이 소요되기도 하고 구멍도 발생할 수 있습니다. 하지만 TDD를 통한 여러 상황의 시나리오를 세우고기댓값을설정해 놓으면 초반 설정만으로 앞으로 회원가입의 로직에 대해문제 있는지는 원클릭으로확인이 가능해지는 아주 큰 장점이 있습니다. 이러한이러한 좋은 것을 bloc을 사용한다면 손쉽게 가능하다는 강점이 있는 것입니다.

코드 재사용의 경우는 동일 프로젝트 내의 코드 재사용도 중요하지만 다른 프로젝트에서도 필요한 기능을 가져다가 사용할 수도 있습니다. 그렇다면 개발기간을 단축할 수 있기 때문에 아주 큰 장점이라고 할 수 있습니다. 대신 코드 재사용을잘하기위해서는 기능을 잘 나누고 정말 필요한 부분끼리만 의존성을 맺게해 주는 게 중요합니다.개발 편의만을 생각하고 기능을 이곳저곳에서 연결해서 사용한다면 나중에 코드 재사용을 할 수 없게 되는 상황이 발생하게 됩니다. 이러한 강점이 있는 것이 Bloc입니다.

3. 이벤트 트레킹을 통합적으로 관리할 수 있다.

BlocObserver라는 게 있어서 이를 통하여 이벤트 트레킹을 통합적으로 관리할 수 있게 됩니다. 다른 상태관리의 경우는 어떤지 모르겠지만 Getx의 경우는 통합적인 이벤트 확인 할 수 있는 기능은 없었던 걸로 기억하고그런 것을 구현하기위해서는 추가적인 개발을 해야 가능한 부분입니다. Bloc은 정말 간단하게 BlocObserver를 등록해주기만 하면 처리가 됩니다.

4. 통일된 코드 베이스로 일할 수 있다.

Bloc은 룰이 정해져 있기 때문에 개발자들끼리 따로 규칙을 정하지 않고도 동일한 개발 패턴을 따르게 되게 되어있습니다. 그러한 장점은 바로 업무의 효율로 드러나게 되죠. 대신 자유롭게 개발하는 사람들에게는 룰을 따르는 것이 귀찮게 다가올 수 있는 부분입니다.

5. Github에서 가장 높은 Star 수

이 부분은 Bloc을 사용해야 할 이유라고 보기는 어려울 수 있지만 많은 개발자분들이 Star를 많이 줬다는 것은 그만큼 신뢰와 장점이 있다는 것으로생각해 볼 수있는 부분입니다. pub.dev에서의 like 수는 상태관리 중 getx가 가장 높지만 github의 Star수로는 Bloc이 가장 높습니다.

이렇게 Bloc을 사용하는 이유에 대한 5가지 이유를 알아봤습니다. 다음번 포스팅에서는 Bloc의 기본이 되는 Stream에 대해서 정리해 보겠습니다.

[플러터] 2022년 12월 현시점의 Getx는 어떤가...

수달e — Fri, 2 Dec 2022 00:12:12 +0900

네 여러분 안녕하세요 개발하는남자 개남입니다.

오늘 다뤄볼 주제는 현 시점의 Getx라는 주제 입니다.

다들 플러터 개발에 빠질 수 없는 것 중에 하나가 상태관리 라이브러리일텐데요

플러터에는 다양한 상태관리가 있습니다.

그중에 대표적으로 getx를 포함해서 provider bloc riverbed 등이 있습니다 이 외에도 여러가지가 더 있는 걸로 알고 있는데 가장 많이 사용하는 것으로 정리해보니 이렇게 4가지로 추려졌습니다. Pub.dev 에서 검색하여 좋아요 수 와 언제 출시 되었는지를 정리 해보았습니다 단연 getx가 가장 많은 사랑을 받고 있습니다. 저 역시 Getx로 대부분의 프로젝트에서 사용하고 있습니다만 어딜가도 인기가 있는 사람이나 제품의 경우 반드시 그 반대편에 서는 사람들이 있기 마련입니다. 인기가 없을때는 사람들이 관심을 두지 않기때문에 반기를 드는 쪽이 없는 것이죠.

Getx도 마찮가지입니다. 많은 사랑을 받는 다는 것은 반대편에 서는 사람이 생길 수 밖에 없습니다. 그렇다고 반대 편에 있는 사람이 잘못되었다는것은 아니고 그들의 시각에서 보면 어느정도 납득이 되는 타당한 근거가 있다는 것입니다.

자 그럼 그들의 시각에서 보는 Getx의 문제점들을 한번 같이 살펴 보도록 하겠습니다.

첫 번째. 도큐먼트가 불편하다

이 부분은저 역시 공감하는 바 입니다. 요즘 도큐먼트들은 친절하고 가독성이 좋게 잘 정리 되어 많은 개발자들이 학습하기 편리하게 되어있습니다. 좋은 가이드를 제시하면서 말이죠, 그에 비해 Getx는 구리다고 볼 수 있습니다. 아마 공감하시는 분들이 계실 것이라 생각됩니다.

개발자 중에는도큐먼트를 보고 개발하는 사람들이 많은데 Getx의 document를 보면 학습하고 싶지 않아 질 수 있겠다 싶습니다.

저 역시 처음 Getx가 좋다고 하니까 한번 학습해볼까 싶어 도큐먼트를 열어봤는데 쉽게 읽혀지지 않더라고요 ;;

두 번째. 이슈가 많고 대응이 느리다

Github만 가서 봐도 이슈가 다른 라이브러리에 비해 상당히 많다고 볼 수 있습니다. 이부분은 사실 많은 관심을 받고 있고 많이들 사용하기 때문일 수 있는데요. 등록된 이슈를 다 살펴 볼 수 없어 추측하겠지만, 크리티컬 이슈도 있겠고, 사용방법을 잘 몰라 질문을 남기거나 , 개발자 개개인의 개발철학이 맞지 않아 개선하고 싶은 마음에 요청을 하는 분들도 있을 것입니다.

Getx를 만든게 회사나 팀이 아닌 개인으로 알고 있는데, 아무래도 많은 개발자분들의 이슈를 대응하기란 쉽지 않겠다는 생각이 듭니다.

그리고 jonataslaw 이분은 변호사 이자 개발자라고 github에서 소개하고 있습니다. 물론 지금은 아이리스 개발 부사장으로 있다고 합니다. Getx는 메인 업무가 아닐 수 있기때문에 이슈대응이 느릴 수 밖에 없는 것이죠 그런점에서 큰 단점이라고 볼 수 있겠습니다.

세 번째. Getx가 상태 관리 외에 많은 부분을 담당하고 있다

이 부분은공감되는 부분이지만 한편으로는 공감하지 않는 부분이기도 합니다.

Getx를 상태관리 라이브러리라고 생각한다면 문제가 됩니다. 하지만 Getx는 상태관리 라이브러리가 아닙니다.

Getx is an extra-light and powerful solution for Flutter
- Github 소개 중.

즉, Getx는 플러터개발을 위한 매우 경량화된 강력한 솔루션이라는 것이죠. 그런 점에서 본다면 많은 부분을 담당하는것이 당연한 부분입니다. 실제로도 기존 flutter 코드에 비해 경량 하면서도 편리한 유틸도 존재하지요. 근데 Getx를 단순히 상태관리를 하는 라이브러리라고 생각하는 분들에게는 이 부분도 단점으로 생각될 수 있습니다.

네 번째. 특정 패턴 없이 자유롭게 개발이 가능하다

빠른 개발을 위해서는 손쉽고 빠르게 접근할 수 있는게 최고라고 볼 수 있습니다. 하지만, 그것은 어디까지나 프로토 타입을 만들때의 상황일 수 있습니다. 지속적으로 관리를 해야 하고 규모가 큰 프로젝트에서는 자유롭게 개발이 가능한 것은 다양한 방식이 산재되어 유지보수가 어렵게 되는 상황을 만들어낼 수 있습니다. 그래서 어렵지만 개발 패턴이 존재하는 것이고 그 룰 베이스로 개발되면 장기적으로 관리하는 측면으로도 좋다고 볼 수 있습니다. 그런점에서 Getx는 공식적인 규칙? 패턴이 존재하지 않아서 Getx를 사용하는 사람마다 저마다의 방식으로 Getx를 사용하고 있을 것입니다. 이부분은 장점이자 단점이 되는 부분입니다.

개발하는 남자가 생각하는 Getx

상태 관리 라이브러리를 Getx 외에 하나 정도는 더 알아두는 게 좋을 것 같습니다. 대표적으로 bloc이라던지 요즘 뜨고 있는 riverpod 등 프로젝트에 맞게 적절하게 사용하면 좋을 것 같다는 생각이 듭니다. Getx는 정말 강력한 것은 빠르고 경량화하게 개발을 할 수 있다는 점에서 정말 강점이 있고 유지보스 측면에서는 bloc이나 타 라이브러리가 좋을 수 있습니다. 프로젝트의 성격에 맞게 설정하여 대응하면 좋을 것 같다는 생각이 듭니다.

여러분들은 어떻게 생각하시나요?

댓글로 알려주세요 ~!

[ Flutter / 플러터 ] SQFlite 문서 정리 및 예제로 마스터해보자.

수달e — Thu, 13 Oct 2022 12:30:34 +0900

네 여러분 안녕하세요 개발하는남자 개남입니다.

오늘 다뤄 볼 내용은 SQFlite에 대해 정리해보려고 합니다. pub.dev에 문서가 정리되어있지만 sqflite사용에 필수적인 내용만을 추려서 간략하게 정리하면 좋을 것 같다는 생각에 이렇게 포스팅하게 되었습니다.

살펴볼 내용

sqflite란?
sqflite 장점 / 단점
sqflite 사용 + 열고 / 닫고
sqflite 테이블 생성 스키마
sqflite 테이블 버전 관리
sqflite CRUD 사용
sqflite transaction 관리
sqflite batch
sqflite 지원되는 Type종류

SQFlite란?

SQFlite는 SQlite를 플러터에서도 사용할 수 있도록 지원하는 플러그인입니다.

SQLite는 MySQL이나 PostgreSQL과 같은 관계형 데이터베이스 관리 시스템입니다. 하지만 다른 것이 있다면 서버용이 아닌 클라이언트 사이드 데이터 관리 시스템입니다. 클라이언트 사이드 시스템이기 때문에 비교적 가벼운 형태로 관리되고 있습니다.
<위키백과>

지원되는 플렛폼은 Android , iOS , MacOS만 지원되고 있으며 Linux와 Window의 경우 SQflite_common_ffi 라이브러리를 통해 지원되고 있다고 합니다. Web의 경우 아쉽지만 지원되지 않습니다.

SQFlite 장점/단점

장점

- 로컬 파일 기반 DB로 네트워크 사용이 필요없이 개발이 가능하기 때문에 서버 비용이나 네트워크 비용을 걱정할 필요가 없다.

- 휘발성 데이터가 아니기 때문에 서비스 중단/종료가 되더라도 데이터 손실 없이 불러올 수 있다.

- 트랜잭션/배치를 지원하기 때문에 데이터 무결성에 탁월하다.

- 관계형 데이터 베이스로 통일성 있는 데이터를 관리 할 수 있다.

- 쿼리를 지원하여 좀더 복잡한 데이터를 조회 sort 등을 할 수 있다.

단점

- 다른 로컬 기반의 데이터 저장 라이브러리에 비해 속도가 떨어진다.( Hive , Shared Preference ... )

- Schema , rawQuery 사용시 문자 형태로 작성해야 하는 불편함이 있다. (오탈자 조심)

sqflite 사용 + 열고 / 닫고

* sqflite는 Android / iOS에 별도의 환경설정이 필요 없이 바로 라이브러리만 Import 만 해주면 사용할 수 있습니다.

플러터 cli 명령어로 sqflite 라이브러리 설치

$ flutter pub add sqflite

또는 특정 버전을 pubspec.yaml 파일의 dependencies 항목에 추가하셔도 상관없습니다.

dependencies:
  flutter:
    sdk: flutter

  sqflite: ^2.0.3+1

Database 열기

sqflite는 파일 기반의 데이터베이스이기 때문에 데이터 베이스 파일을 만들어야 합니다.

파일이 존재하지 않아도 괜찮습니다. 없으면 자동으로 만들어줍니다.

var db = await openDatabase('my_db.db');

Database 닫기

공식문서에 따르면 열린 Database를 닫을 필요는 없다고 합니다. 이유는 앱이 종료되는 시점에 같이 종료되기 때문이라고 합니다.

그럼에도 데이터 접근을 해제하려고 한다면 close함수를 통해 해제할 수 있습니다.

await db.close();

존재하는 DB를 사용하고 싶을 때

DB초기화 시점에 존재하는 DB가 있다면 해당 db파일로 초기화를 진행할 수 있습니다.

1. assets폴더 하위로 원하는 위치에 db파일을 위치시킨다.

assets/examples.db
또는
assets/dbs/examples.db

2. pubspec.yaml파일에 assets 사용할 수 있도록 경로 설정

flutter:
  assets:
    - assets/example.db
    또는
    - assets/dbs/example.db

3. database 위치시킬 경로 확인

var databasesPath = await getDatabasesPath();
var path = join(databasesPath, "demo_asset_example.db");

4. database 파일이 존재 여부 확인 후 존재하지 않는 최초 초기화 시점에서만 assets에 위치시킨 db파일을 카피한다.

var exists = await databaseExists(path);

if (!exists) {
	try {
        await Directory(dirname(path)).create(recursive: true);
	} catch (_) {}
    ByteData data = await rootBundle.load(join("assets", "example.db"));
    List<int> bytes = data.buffer.asUint8List(data.offsetInBytes, data.lengthInBytes);
    await File(path).writeAsBytes(bytes, flush: true);
}

5. database 열기

var db = await openDatabase(path, readOnly: true);

sqflite 테이블 생성 스키마

openDatabase를 할 때에 option값으로 onCreate 함수를 사용할 수 있습니다. onCreate 함수 외에도 version, onConfigure, onUpgrade, onDowngrade를 사용할 수 있습니다. (version 관리 항목에서 살펴보겠습니다.)

openDatabase시 데이터베이스가 존재하지 않으면 onCreate함수가 호출됩니다. 이때에 원하는 DB table들을 만들어주면 됩니다.

var databasesPath = await getDatabasesPath();
String path = join(databasesPath, 'sample.db');
var db = await openDatabase(path,
  version: 1,
  onCreate: _onCreate);
  
_onCreate(Database db, int version) async {
  await db.execute(
    "CREATE TABLE Sample (id INTEGER PRIMARY KEY AUTOINCREMENT, value TEXT NOT NULL)");
}

db.excute 함수로 String 작성한 Schema로 테이블이 생성되며, sql Schema작성법을 따르면 됩니다. (대문자 소문자 상관은 없지만 대게 Schema작성 시 대문자로 사용합니다. 단, 테이블명과 칼럼 명의 경우 원하는 방식으로 작성하셔도 됩니다.

앱이 정상적으로 실행되면 문제없이 테이블 세팅이 되었다고 생각하면 되지만 직접 눈으로 확인하고 싶을 때는 만들어진 db파일을 직접 열어보는 것입니다.

- 에뮬레이터 사용한 경우 db파일 체크 하기 @developerelen 님 블로그 참조

[Flutter] sqflite database file 찾기

sqflite 라이브러리를 사용하여 database를 CRUD 한 후, 터미널로 .db 파일을 읽어서 정말 파일에 저장이 되었는지 확인하는 방법입니다.openDatabase 메소드로 DB를 오픈할 때 사용한 주소를 로그에 찍습

velog.io

- 물리 디바이스를 사용한 경우 db파일 체크 하기 @developerelen 님 블로그 참조

[Flutter] 앱에서 다운받은 파일 adb로 복사하기

adb(Android Debug Bridge)는 기기와 통신할 수 있는 다목적 명령줄 도구입니다. adb 명령어는 앱의 설치 및 디버깅과 같은 다양한 기기 작업에 도움이 되며, 기기에서 다양한 명령어를 실행하는 데 사용

velog.io

sqflite 테이블 버전 관리

버전 관리가 필요한 이유는 서버를 통해 데이터를 받는 방식이 아닌 로컬 파일 기반의 데이터이기 때문에 앱의 버전에 따라 데이터 구조가 변화될 텐데 그럴 때 DB Schema도 업그래드가 필요합니다. 때로는 다운그래드도 필요할테고요, 그럴때 사용하는 것이 버전입니다. 버전에 따라 onUpgrade 또는 onDowngrade가 호출되게 됩니다.

var db = await openDatabase(
	path, 
    version: 1, 
    onCreate: _onCreate ,
    onUpgrade: _onUpgrade , 
    onDowngrade: _onDowngrade
);

현 version 숫자가 이전 버전보다 높으면 onUpgrade가 호출되고

현 version 숫자가 이전 버전보다 낮으면 onDowngrade가 호출됩니다.

공식 문서에 따르면 웬만하면, 버전을 높이면서 작업하라고 합니다. 즉, downgrade는 웬만해서 사용하지 말아야 한다는 뜻으로 이해했습니다.

테이블 버전 관리 테스트를 위해 시나리오를 준비했습니다.

User 정보를 저장할 table을 만들어줍니다. 유저에 정보로는 처음에는 이름과, 나이, id 이 정도만 저장합니다.
앱을 실행하여 임의의 User정보를 저장합니다.
시간이 지났다고 가정하고, User정보에 닉네임 데이터를 추가적으로 넣는 것으로 기획이 변경되었습니다.
onUpgrade 함수를 사용하지 않고 데이터를 넣으려고 했을 때 어떤 현상이 발생되는지 확인.
onUpgrade 함수를 추가했지만 version을 변경하지 않고 사용한 경우
onUpgrade 함수를 통해 Schema 업데이트 후 데이터를 넣었을 때 현상 확인.

var databasesPath = await getDatabasesPath();
String path = join(databasesPath, 'user.db');
var db = await openDatabase(path, version: 1, onCreate: _onCreate);
  
  
_onCreate(Database db, int version) async {
  await db.execute('''
  	CREATE TABLE user (
    	id INTEGER PRIMARY KEY AUTOINCREMENT, 
    	name TEXT NOT NULL UNIQUE, 
        age INTEGER NOT NULL)
    '''
  );
}

name에 unique 옵션을 넣어 실행할 때마다 중복 저장되지 않도록 테이블을 생성했습니다.

  await Future.delayed(const Duration(milliseconds: 3000));
  var id = await db.insert('user', {'name': '김성덕', 'age': 19});

딜레이 3초 후에 사용자를 insert 해줬습니다. 정상적으로 앱이 실행이 되었고 , Unique 가 정상적으로 되는지 확인하기 위해

일부로 동일 데이터를 insert 해봤습니다. 다음과 같은 오류 메시지를 받았습니다.

[ERROR:flutter/lib/ui/ui_dart_state.cc(198)] Unhandled Exception: DatabaseException(UNIQUE constraint failed: user.name (code 2067 SQLITE_CONSTRAINT_UNIQUE[2067])) sql 'INSERT INTO user (name, age) VALUES (?, ?)' args [김성덕, 19]

await Future.delayed(const Duration(milliseconds: 3000));
// var id = await db.insert('user', {'name': '김성덕', 'age': 19});
var id = await db.update(
    'user',
    {'nickname': '개발하는남자'},
    where: 'name = ?',
    whereArgs: ['김성덕'],
);
print(id);

insert문을 주석처리하고 update 문으로 변경했습니다. 이때, 아직 Schema 변경 전으로 sql db에는 nickname 칼럼이 존재하지 않는 상태입니다.

no such column: nickname (code 1 SQLITE_ERROR[1]

실행결과 no such column 오류로 인해 데이터 업데이트가 실패되었습니다. (원하는 결과를 얻었습니다.)

var db = await openDatabase(
    path,
    version: 1,
    onCreate: _onCreate,
    onUpgrade: _onUpgrade,
);
  
  
_onUpgrade(Database db, int oldVersion, int newVersion) async {
  var batch = db.batch();
  if (oldVersion == 1) {
    batch.execute('ALTER TABLE user ADD nickname TEXT');
  }
  await batch.commit();
}

업그래드함수를 추가했지만 버전이 바꾸지 않았습니다 결과는 4번과 같이 오류 메시지를 받았습니다.

  var db = await openDatabase(
    path,
    version: 2,
    onCreate: _onCreate,
    onUpgrade: _onUpgrade,
  );

결과는 이상 없이 업데이트됨을 확인하였습니다.

좀 더 디테일한 version관리 예제는 링크를 통해서 확인해보세요.

sqflite CRUD 사용

간단 sqflite CRUD이며 별도의 ui와 model 설계 없이 사용방법만 정리하겠습니다.

model과 ui를 통해 crud를 활용하는 것은 제 유튜브에 [Flutter] 로컬 데이터 관리 sqflite로 손쉽게 처리 하자 영상을 참고해주세요.

- Create

// var <생성후 ID값> = await db.insert( <테이블명> , <저장시킬 데이터 (Map<String,Object> 타입)> );
// 방식 1
var id = await db.insert('user', {'name': '김성덕', 'age': 19});

// 방식 2
var rawId = await db.rawInsert(
      'INSERT INTO user(name, age, nickname) VALUES("개남", 22, "개발하는사람")'
);

// 방식 3
var rawId1 = await db.rawInsert(
      'INSERT INTO user(name, age, nickname) VALUES(?,?,?)',
      ["개남1", 24, "개발하는사람2"]
);

- Read

// var <조회된 데이터> = await db.query(<테이블명> , where : <조건식> , whereArgs : <조건식에 비교할 값(Array)>)
// 방식 1
var user = await db.query('user', where: 'name = ?', whereArgs: ['김성덕']);

// 방식 2
var rawUser = await db.rawQuery('SELECT * FROM user WHERE name="개남"');

// 방식 3
var rawUser1 = await db.rawQuery('SELECT * FROM user WHERE name=?', ['개남1']);

- Update

// 방식 1
var id = await db.update(
    'user',
    {'nickname': '개발하는남자'},
    where: 'name = ?',
    whereArgs: ['김성덕'],
);

// 방식 2
var updateID = await db.rawUpdate(
      'UPDATE user SET name = "개남개남", age = 34 WHERE name = "개남"'
);

// 방식 3
var updateID = await db.rawUpdate(
      'UPDATE user SET name = ?, age = ? WHERE name = ?', ['개남개남', 34, '개남']
);

- Delete

// 방식 1
var isDeleted = await db.delete('user', where: 'name = ?', whereArgs: ['개남개남']);

// 방식 2
var isDeleted1 = await db.rawDelete('DELETE FROM user WHERE name = "김성덕"');

// 방식 3
var isDeleted2 = await db.rawDelete('DELETE FROM user WHERE name = ?', ['김성덕']);

삭제 완료 시 return으로 1 값을 값이 없어 삭제가 안되거나 삭제될 수 없을 때 0 값을 return 합니다.

sqflite transaction 관리

Transaction 은 sql 데이터 베이스뿐 아니라 모든 데이터를 관리하는 시스템에서는 transaction 관리를 해줘야 합니다.

Transaction 은 쉽게 말해 정합성이 깨지는 것을 방지하기 위한 방법? 기능?이라고 생각하면 됩니다.

예를 들어 사용자가 가입 시 포인트를 지급하는 로직이 있다고 가정한다면 사용자 가입과 포인트 등록이라는 두 가지 테이블에 저장을 시켜야 합니다. 사용자 저장 후 포인트 등록을 하려는데 포인트 등록에서 문제가 발생하여 오류가 발생했다고 가정한다면 사용자 가입이 되지 말아야 합니다(물론 이 부분은 서비스의 규칙이 어떠한지에 따라 다르겠지만 여기에서는 가정하겠습니다.) 이럴 때 필요한 것이 Transaction입니다.

시나리오

회원 가입으로 데이터 insert
1초 정도 Delay를 주고 조금 전 저장한 데이터가 잘 들어가 있는지 확인
강제로 오류를 발생시킴 ( name 값은 unique 값이기 때문에 일부로 동일한 값을 insert 시켜 오류를 발생시킴 )
오류 후에 2. 번에서 했던 것처럼 조회하여 트렌젝션 처리가 잘 되었는지 확인.

  try {
    await db.transaction((txn) async {
      await txn.insert('user', {'name': '개남', 'age': 22, 'nickname': '개발하는남자'});
      await Future.delayed(const Duration(milliseconds: 1000));
      var data = await txn.query('user', where: 'name = ?', whereArgs: ['개남']);
      print(data); // 1번 print
      await txn.insert('user', {'name': '개남', 'age': 25, 'nickname': '개남형'});
    });
  } catch (e) {
    print(e);
  }
  var user = await db.query('user', where: 'name = ?', whereArgs: ['개남']);
  print(user); // 2번 print

위 시나리오처럼 진행 시 1번 print에서는 저장된 '개남' 사용자를 찾을 수 있었지만 2번 print에서는 트렌젝션의 결과로 '개남' 사용자를 찾을 수 없었습니다. 정상적으로 처리됨을 확인했습니다.

sqflite batch 사용

Batch는 여러 가지 작업들을 그룹화시켜 한 번에 실행 시켜주는 기능을 말합니다. insert / update / delete 등등 한번에 실행하고 싶을때 사용할 수 있으며 commit 과정중 오류가 발생하면 성공된 데이터까지 원복 시켜버립니다. 위에서 다뤄본 transaction과도 유사하다고 볼 수 있는데 다른점이 있다면 transaction의 경우 같은 transaction 영역 안에서는 insert후 조회 및 별도의 작업등을 수행할 수 있는 반면 batch의 경우 작업목록을 정의만 할뿐 commit 전에 데이터를 조회하여 어떤 작업을 하거나 데이터를 변경하거나 할 수 없습니다. 말그대로 Queue와 같이 작업을 쌓아놓고 한번에 처리하되 순차적으로 작업되는 것을 확인하였습니다.

  var batch = db.batch();
  batch.insert('user', {'name': '배치작업자', 'age': 31, 'nickname': 'batchwWrker'}); //1번
  batch.insert('user', {'name': '배치', 'age': 22, 'nickname': 'batch'});//2번
  batch.delete('user', where: 'name =?', whereArgs: ['배치']);//3번
  batch.update('user', {'name': '배치'}, where: 'name =?', whereArgs: ['배치작업자']);//4번
  await batch.commit();//5번
  
  var rawUser = await db.rawQuery('SELECT * FROM user WHERE name=?', ['배치']);
  print(rawUser);//6번

batch가 순차적 실행이라는 것을 확인하기 위해 위 와 같은 시나리오를 만들어봤습니다.

시나리오

'1번'과 '2번'으로 사용자 두 명을 저장시킵니다.
'4번' 작업을 실행하면 배치 작업자 > 배치로 변경되기 때문에 동일 name이 발생하여 오류가 발생될 것입니다. 그 오류를 방지하고자 '3번'작업을 통해 원래 '배치'유저를 제거시켰습니다.
'5번'작업이 완료되는 시점에 오류가 발생되지 않음을 확인합니다.
'6번'작업으로 조회된 '배치'사용자가 기존 '배치 작업자' user임을 확인합니다.

작업 결과는 예상했던 결과를 얻을 수 있었으며 추가적으로 시나리오 2번의 오류 방지 부분을 빼고 작업할 시 update에서 오류가 발생됨을 확인하였습니다. 즉, 순차적 실행임을 알 수 있었습니다.

sqflite 지원되는 Type종류

sqflite의 경우 지원되는 종류를 알아보기 전에 Table과 Column의 이름으로 사용하면 안 되는 이름을 살펴보겠습니다.

[
	"add","all","alter","and","as",
    "autoincrement","between","case",
    "check","collate","commit","constraint",
    "create","default","deferrable","delete",
    "distinct","drop","else","escape","except",
    "exists","foreign","from","group","having",
    "if","in","index","insert","intersect","into",
    "is","isnull","join","limit","not","notnull",
    "null","on","or","order","primary","references",
    "select","set","table","then","to","transaction",
    "union","unique","update","using","values","when","where"
]

위의 이름으로 테이블명이나 칼럼명을 사용하게 될 경우 문제가 발생할 수 있습니다. 하여 이름을 작명하실 때에 위 사항을 유의하시기 바랍니다.

Sqflite 지원되는 Type

Integer (dart : int), Real(dart : num) , Text(dart : String ), Blob (dart : Unit8List ) 이렇게 지원이 되고 있습니다.

추가적으로 DateTime과 , bool 타입의 경우 형변환을 통해 저장시킬 수 있습니다. (우회하는 방안)

DateTime의 경우 millisSinceEpoch (int) 형태로 저장시킬 수 있고 추가적으로 String 값으로도 저장할 수 있습니다.

bool의 경우 true를 1로 false를 0으로 저장하여 관리할 수 있습니다.

DateTime의 경우는 많은 상황에서 쿼리 질의를 사용하기 때문에 DateTime을 조건으로 쿼리 질의를 사용해 보겠습니다.

millisSinceEpoch을 사용해 int로 저장도 하고 String으로 저장해서 둘 다 쿼리 질의가 되는지 확인해 보겠습니다.

  var batch = db.batch();
  List.generate(
      100,
      (index) => batch.insert('user', {
            'name': '배치작업자$index',
            'age': index,
            'createdAt': DateTime(2022, 10, 01, 10, 20)
                .add(Duration(days: index))
                .millisecondsSinceEpoch,
            'updatedAt': DateTime(2022, 10, 01, 10, 20)
                .add(Duration(days: index))
                .toIso8601String(),
          }));

  await batch.commit();

2022년 10월 1일부터 하루에 한 명씩 가입한 데이터를 저장시켰습니다. 위 batch로 얻은 결과 데이터는 아래와 같습니다.

  var users = await db.query('user',
      where: 'createdAt > ?',
      whereArgs: [DateTime(2023, 01, 01, 0, 0).millisecondsSinceEpoch]);
  for (var user in users) {
    print(user);
  }

  var updateUsers = await db
      .query('user', where: 'updatedAt > ? and updatedAt < ?', whereArgs: [
    DateTime(2023, 01, 01, 0, 0).toIso8601String(),
    DateTime(2023, 01, 04, 0, 0).toIso8601String()
  ]);
  for (var user in updateUsers) {
    print(user);
  }

실행해본 결과 아래와 같이 잘 출력되는 것을 확인할 수 있었습니다.

이것으로 플러터의 Sqflite에 대한 전반적인 기능을 예제로 살펴보면서 문서를 정리해보았습니다.

도움이 되셨길 바라면서 도움이 되셨다면? 좋아요 / 구독 부탁드리고 앞으로도 좋은 포스팅을 공유하도록 노력하겠습니다~!

감사합니다.

[개발생각] 개발강좌나 클론코딩 많이 봐도 실력이 빨리 늘지 않아요... 무엇이 문제일까..

수달e — Tue, 11 Oct 2022 09:29:10 +0900

내 여러분 안녕하세요 개발하는남자 개남입니다.
오늘 다뤄볼 주제는 개발언어에 대해서 이야기해보려고 합니다.

몇몇 분들과 1:1로 대화를 해보거나 문의 메일을 받았는데요 공통적인 고민이 있더라고요 그래서 그 부분을 공유해보면 좋을 것 같다고 생각되어 이렇게 포스팅을 하게 되었습니다.

고민 요약

1. 강의 영상을 보다보면 이해가 되고 내 것이 된 것 같은데 직접 만들고 싶은 프로젝트를 시작하면 막막해진다.
2. 어떻게 하면 실력을 빨리 성장할 수 있는가?

<강의 영상을 보다보면 이해가 되고 내 것이 된 것 같은데 직접 만들고 싶은 프로젝트를 시작하면 막막해진다>

위 고민에 대한 제 생각은 2가시 유형의 사람으로 나눠질 것 같습니다.

- 첫번째 유형의 사람

강의 내용을 이해하고 개발까지 할 수 있는 능력을 갖췄지만 내가 만들고 싶은 프로젝트를 시작하면 아무것도 할 수 없는 사람.

- 두번째 유형의 사람

강의 내용을 모두 보긴 했지만 개발을 착수할 만큼의 실력이 아직 쌓이지 않은 상태에서 내가 만들고 싶은 프로젝트를 시작한 사람.

첫 번째 유형의 사람의 경우는 경험이 부족하여 발생되는 현상일 수 있습니다.

서비스를 만든다는 것은 단순히 개발만 할 수 있다고 해서 만들 수 있는 것은 아닙니다.

프로젝트를 생성부터 서비스 출시까지는 많은 과정을 거쳐서 얻어내는 결과물인데 그 결과물을 만들기 위해

기획 , 디자인 , 개발 , QA 등등 많은 사람들이 필요로 하게 됩니다. (물론 혼자서도 가능하긴 하겠지만)

즉, 개발에 투입되기 위해서는 기획과 디자인이 어느 정도 잡혀야 수월하게 작업할 수 있게 됩니다.

위와 같은 경험이 부족한 경우 기획 및 디자인이 없는 상태에서 개발에 들어가려고 하니 어느 범위 수준으로 개발을 해야 할지 모르게 되어 막막해지는 것입니다.

해결 방안

매우 매우 작은 단위의 기능을 갖는 서비스를 기획하여 결과물을 만들어 보자입니다.

처음부터 너무 과도하게 큰 프로젝트를 하게 되면 아마 대부분 중도 포기하게 되거나 시작도 못하게 될 가능성이 있습니다.

그럼 시작부터 실패의 쓴맛을 보고 시작하게 되는 것이니 좋은 선택이 아닙니다.

그렇기에 매우 작은 단위의 서비스를 기획해서 결과물을 만들어보면 자신감도 생기고 신기하기도 하고 재미를 느낄 수 있습니다. 그것을 밑거름이 되어 좀 더 큰 프로젝트를 도전해보는 방식을 추천드립니다.

그리고 작은 단위라도 서비스 흐름도나 UI 디자인 정도는 어느 정도 잡아두고 개발에 투입되어야 개발을 바로 할 수 있게 됩니다.

두 번째 유형의 경우 정말 열심히 학습은 했지만 개발 학습이 부족한 경우

열심히 반복해서 봐도 개발 실력이 늘지 않는다면 자신을 돌아봐야 합니다. 영상을 집중해서 보는지 , 그리고 가장 중요한 영상을 시청하면서 직접 따라 작성해보는지, 처음에는 따라 작성했을 수는 있습니다. 하지만 두번째 볼 때부터는 이미 한번 해본 내용이기 때문에 눈으로만 보고 넘길 가능성이 있습니다. 심지어 새로 배우는 부분에서도 직접 작성해보는 게 아닌 강좌에서 제공되는 소스를 받아서 돌려보는 식으로 학습했을 가능 성이 있습니다.

아무리 많이 보고 다양한 기능들을 지속해서 본다고 해도 직접 작성해보고 삽질도 해보지 않으면 내 것이 되지 못합니다.

제가 개발 입문 당시에 이런 경험을 한 적이 있습니다.

선임 개발자가 말하길

모르는 것이 있어도 물어보지 말고 혼자 해결하라고 그리고 찾다 찾다 정... 못 찾겠으면 그때 도움을 청해라

그 당시 아무것도 모르는데 문제 해결을 위해 몇 날을 붙잡고 낑낑거리면서 삽질의 삽질을 하고 있을 때 선임 개발자가 그제야 아직도 못했냐면서 문제를 풀 수 있는 힌트를 줬습니다. 그 힌트 덕분에 바로 문제를 해결할 수 있었는데요 처음부터 물어봐서 해결했으면 고생도 덜하고 스트레스도 덜했을 텐데... 그 당시엔 선임 개발자분이 왜 그랬을지... 원망 아닌 원망을 한적도 있고, 바빠서 그랬겠지.. 하면서 넘겼는데요.
지금 생각해보면 그 선임 개발자는 제가 성장할 수 있도록 도와준 것이었습니다.
모르는 것이 있을 때 바로 문제를 해결해주는 사람이 있으면 편할지 몰라도 직접 삽질이나 노력 없이 얻은 기능의 경우 그때는 알고 넘어갈지 몰라도 시간이 지나면 잊게 됩니다. 하지만 혼자 낑낑거리고 삽질을 통해 얻게 된 기능의 경우 시간이 지나도 잊지 못합니다. 머리는 잊어도 몸이 기억해서 문제를 해결할 수는 있게 되죠

해결 방안
개발 강좌의 경우는 쉽게 얻을 수 있는 것들입니다. 눈으로 보고 여러 번 반복해서 보더라도 시간이 지나면 잊어버리게 될 수 있습니다. 그래서 직접 영상을 보면서 작성해보는 것, 그것보다 더 좋은 것은 응용을 해보는 것입니다. 그런 방법이 일종의 노력이고 그 노력이 여러 번 반복된다면 장기 기억으로 남게 될 것입니다.

<빨리 개발실력을 향상하기 위해서는 어떻게 해야 하나요?>

빨리 실력을 향상하려는 마음을 내려두고 개발의 흥미를 느낄만한 나만의 방법을 찾아서 포기하지 않고 지속적인 공부만이 방법입니다.

너무 식상한 말이죠? 키포인트는 '빨리'라는 조급함을 버려야 한다입니다.
빨리라는 조급함이 오히려 자신에게 독이 되어 개발을 포기하게 만들 수 있습니다.
개발은 컴퓨터 언어를 학습하는 것은 영어를 학습하는 것과 같다고 저는 생각합니다.

우리가 영어를 빨리 향상할 수가 있던가요?

물론, 몇몇 분들은, 나는 빨리 늘었는데 하는 분들이 있을 수는 있지만 그분은 언어 습득에 탁월한 이해도가 있어서 가능했을 수 있습니다.

아무튼, 영어는 수학이나 역사를 학습하는 것과 같은 암기의 영역이 아닙니다. 운동을 학습하는 것과 같은 영역이라고 하는데 개발도 마찬가지라고 생각합니다. 빨리 향상하는 방법은 없다고 생각합니다.
빨리라는 조급함을 버리고 나만의 개발 방식을 찾는 것이 개발 실력을 향상하는데 도움을 줄 것입니다.

영어도 다양한 공부방법이 있잖아요? 미드를 본다거나, 1:1 원어민과 통화 수업을 한다거나, 학원을 다닌다거나, 독학을 한다거나 등등, 성공사례가 정말 다양하죠 , 하지만 나에게 맞는 공부 방식을 찾지 못한다면 금방 지쳐서 포기하게 되죠,

나만의 공부방식이 있다면 포기하지 않고 재미있게 영어를 학습하게 되고 그 꾸준함의 결과로 새로운 언어를 학습에 성공하게 되는 것처럼 개발도 다양한 방식의 학습방법이 있습니다. 책을 보고 학습하거나, 온라인 강좌를 본다거나, 1:1 과외를 받는다거나, 독학을 한다거나 다양한 방법이 있을 것입니다.

다양하게 경험해보시고 나에게 맞는 개발 학습 방법을 찾는 게 도움이 될 거라고 생각합니다.

개발 학습에 재미를 느꼈다면 꾸준하게 지속하십시오 그럼 분명 어느 순간 개발언어를 이해하게 되고 바로 그 언어를 통해 개발을 할 수 있는 날이 도레 할 것입니다.

자 오늘은 이렇게 개발언어 학습 대해 제 생각을 공유해보았습니다.
제 생각이 100% 정답이라고 할 수 없지만 짧지 않은 시간 동안 개발을 해오며 느낀 부분을 정리해봤습니다.

아무튼 이번 영상에 공감이 되거나 도움이 되신다면 좋아요 부탁드리고 각자의 의견이 있다면 댓글로 알려주시면 서로 소통하고 좋을 것 같습니다.

감사합니다

[개발 생각] 개발하는데 꼭 디자인 패턴이 필요할까?

수달e — Sat, 23 Jul 2022 12:20:18 +0900

내 여러분 안녕하세요 개발하는남자 개남입니다.
오늘 다뤄볼 주제는 개발하는데 꼭 디자인 패턴이 필요할까? 에 대해서 포스팅하려고 합니다.

디자인 패턴이란?

디자인 (설계하다,디자인하다) + 패턴 (되풀이되는 사건이나 물체의 형태를 가리킨다.)
되풀이되는 사건이나 형태를 설계하는 것을 디자인 패턴이라고 할 수 있겠습니다.
개발 쪽으로 적용하여 정의를 내리자면? 반복되는 소스코드 혹은 반복되는 구조등을 설계하여 정의 내린 것을 디자인 패턴이라고 할 수 있겠습니다.

디자인 패턴 이름부터가 어려워...

디자인 패턴 하면 뭔가 거창한 것 같고 듣기만 해도 어려운 것처럼 느껴질 수 있습니다. 하지만 어려울 것이 하나도 없습니다 왜냐면 디자인 패턴은 말그대로 누군가 정의 내린 개발 방식일 뿐입니다. 유명한 디자인 패턴 말고도 우리들도 어찌보면 자신만의 혹은 팀 간의 디자인 패턴을 지속적으로 사용하고 있을 수도 있습니다.

예를 들어 디자인 패턴을 하나도 모르는 A씨가 있습니다. A 씨는 회원 가입 기능을 담당하게 되었고 요구 사항에 맞게 기능을 만들었다고 가정하겠습니다.

처음에는 문제가 너무 많아 문제를 해결하기위해 소스코드를 지속적으로 수정을 했을 것입니다. 문제를 점차 해결해 나아가면서 결국 기능 개발이 완료되었습니다. 해당 회원가입 기능을 라이브로 배포하여 사용자들이 이상 없이 회원가입을 하게 되었습니다. 그럼 A 씨에게는 회원가입 기능을 하는 소스코드를 만들었고 사용자들이 이상 없이 사용을 하기 때문에 자신의 소스가 검증된 소스라고 생각하게 됩니다.

시간이 지나 A씨는 다른 프로젝트에서 동일한 회원가입 기능을 만들어야 하는 상황이 되었습니다. 자신이 지난번 만들었던 회원가입 기능하는 소스코드를 가져와 적용해봅니다. 하지만 그 기능은 이전 프로젝트에 너무 많은 의존성으로 당장 바로 사용하지 못하게 되었습니다. 소스코드를 이번 프로젝트에서도 사용 가능하도록 수정을 하게 됩니다. 그러면서 확장성을 고려하여 다시 수정을 하게 됩니다.

이번에도 해당 소스코드가 정상동작을 하게 되었기에 검증이 된 것이라고 생각하게 됩니다.

또다시 시간이 지나 다른 프로젝트에서 동일한 회원가입을 또 만들어야 하는 상황이 생겼습니다. 지난번에 확장성을 고려해 설계를 했던 소스코드를 가져와 적용해보니 딱히 건들 부분이 많이 줄어들어 몇 가지만 손보고 바로 적용할 수 있었습니다. A 개발자는 1번째 프로젝트 때와 2번째 프로젝트 때와 달리 지금 프로젝트에서 회원가입 기능을 만드는데 시간을 많이 단축시킬 수 있게 되었습니다.

이러한 경험을 바탕으로 앞으로 만들어질 회원 가입에 사용할 소스코드를 자신의 소스 코드를 넣으면 개발시간을 단축할 수 있겠구나 하는 예상을 하게 되고 이것을 혼자만 알기보다 회원가입 기능을 만들어야 하는 많은 개발자들에게 알려주게 되어 많은 사람들이 해당 소스 코드 혹은 짜는 방식을 고대로 차용해 사용하게 됩니다.

그럼 많은 사람들의 입소문을 통해 회원가입기능을 만들 때는 A개발자가 만든 회원가입 코드를 사용하면 매우 좋더라 가 되게 됩니다. 이것이 바로 디자인 패턴이 만들어지고 전파되는 과정이 아닐까? 생각됩니다. 물론 이해를 돕기 위해 제가 만들어낸 예시의 경우는 디자인 패턴보다 기능 단위의 모듈을 전파하는 것에 더 가까울 수 있으나 디자인 패턴도 이와 같은 이유(개발 시간 단축, 유지보수 편의성)에서 만들어지고 입소문(도서 등..)을 통해 전파해 나가는 것이라 생각합니다.

그럼 왜 패턴을 학습하는데 어려움을 느낄까?

아마 이런 경험을 한적이 있을 것입니다. 내가 짠 소스코드는 읽기 쉬운데 남이 짜 놓은 소스는 눈에 들어오지 않고 해석하는데 오랜 시간이 걸려본 경험. 나는 분명 내 소스는 사용하기 편리해서 소개했는데 다른 개발자는 왜 그렇게 어렵게 하냐는 말을 들어본 경험.

저마다 개발 실력이 다를 뿐 아니라 사람들은 저마다 자신의 스타일, 또는 철학이 존재하기 때문에 자신의 스타일이 아닌 소스코드를 보게 되면 자신의 스타일로 소스 코드를 해석하려고 하게 됩니다. 자신의 스타일대로 작성된 소스코드라면 손쉽게 읽힐 것이고 그게 아닌 소스코드라면 이해하는데 어려움을 느끼게 됩니다. 여러움을 해소하기 위해서는 새로운 스타일을 배워야 합니다.

이처럼 디자인 패턴의 경우 수십년에 걸쳐진 검증된 소스 코드라 할지라도 그 개발자의 개발 철학이나 스타일에 익숙하지 않기 때문에 학습에 어려움을 느끼게 되는 것입니다.

그럼 왜 나와 다른 스타일의 디자인 패턴을 배워서 사용해야 할까요?

그것은 이미 수십년에 시간이 흐르면서 수행 착오를 거쳐 만들어져 온 검증된 패턴이기에 이 패턴을 익히면 익힌 사람들끼리의 커뮤니케이션이나 이 패턴을 익힌 사람의 소스코드를 이해하는 데에 쉬워지기 때문입니다. 물론 필수는 아닙니다. 위에 예를 들어 소개했던 개발자A씨처럼 하나부터 열까지 자신이 개발하고 만들 수 있습니다. 전혀 상관이 없죠. 왜냐면 기능만 동작되면 되기 때문입니다. 하지만 그렇게 되면 수행 착오를 많이 거칠 수밖에 없게 됩니다. 어디서 어떤 버그가 발생할지.. 혹은 보안상 괜찮을지 그리고 유지보수에 유리할지 등.. 많은 시간이 필요하게 되죠.

하지만 이 역시 쉽지는 않습니다.

간단한 패턴도 있지만 정확하게 이해와 경험을 바탕으로 사용해야 하는 패턴도 있습니다. 디자인패턴에 목숨 걸고 이 패턴 저 패턴 적용하려고 하게 되면 오히려 독이 될 수 있습니다. 패턴이 필요한 부분에 적용하고 간단히 처리할 수 있는 부분은 그냥 개발하는 편이 오히려 좋을 수 있습니다.

자 그럼 간단히 정리 하고 결론을 내보도록 하겠습니다.

패턴 사용의 장점

개발 속도가 빨라진다.
새로 접하는 소스코드라 하더라도 내가 알고 있는 패턴대로 설계되어있다면 소스 구조를 쉽게 파악할 수 있다.
이미 검증된 방식이라 믿고 사용할 수 있다.
개발자들 간의 커뮤니케이션이 쉬워질 수 있다.

패턴 사용의 단점

학습 시간이 필요하다.
잘못된 이해로 작성된 패턴은 오히려 좋지 못한 소스코드를 야기할 수 있다.

자 이제 디자인 패턴이 꼭 개발에 필요한지에 대해 제가 생각하는 부분을 이야기하고 마무리하겠습니다.

개발은 경험이 중요한 것 같습니다. 경험 없이 디자인 패턴만 배워 적용하려고 하면 분명 어려움을 느끼게 됩니다. 어느 때에 이 패턴을 사용해야 하는지 모르기 때문입니다.

만일 자신이 속한 회사 소스 코드에 디자인 패턴이 사용되었다면 그 디자인 패턴을 학습하고 익혀 사용하는 것은 좋다고 생각합니다. 하지만 자신이 속한 회사 소스코드에 디자인 패턴이 없거나 혹은 나 혼자 개발하는 상황이라면 디자인 패턴에 시간을 쓰기보다 개발을 먼저 해서 경험을 쌓는 것을 추천드립니다.

물론 무슨 소리냐! 디자인 패턴을 선행으로 학습하고 보다 좋은 소스코드를 짜는 것이 좋은 것이 아니냐 할 수 있는데 잠깐 말했듯 어떤 패턴을 어느 때에 사용해야 하는지 그리고 이 패턴을 써서 얻는 이점이 무엇인지 모른 채 그냥 패턴을 사용하는 것은 좋지 못하다고 생각합니다. 게다가 시간이 지나 내가 짠 소스코드를 이해하지 못하는 경험을 하게 될 수 있습니다. 그렇게 되면 유지 보수가 더 어려워지는 상황이 발생할 수 있다는 것입니다. 디자인 패턴에 대해 관심을 갖고 공부하는 것은 좋지만 소스코드 적용에는 신중하게 하자 필요함을 느낄 때에 적용하자가 제 생각입니다.

여러분들의 생각은 어떠신가요?
각자의 생각을 댓글로 공유해주신다면 개발 공부하는 분들이나 제게도 큰 도움이 될 것 같습니다 ^^

감사합니다.

기가막힌 아이디어를 개발부터 서비스 출시까지 필요한 기술은?

수달e — Mon, 11 Jul 2022 22:50:45 +0900

우리는 살면서 불편을 경험할 때가 있습니다.

그런 불편을 느낄 때 나타날 수 있는 반응으로 크게 3가지 가 있을 것 같습니다.

첫 번째 유형 아무 생각이 없다.

두 번째 유형 불평불만하며 누가 이런 거 편리하게 만들어주면 안 될까?라는 불평불만을 토로하는 유형

세 번째 유형 불편한 것을 해소시면 많은 사람들이 사용하겠지? 기회 포착형

여러분은 어떤 유형인가요?

여기서 만일 당신이 세 번째 유형에 속하신 분이라면

아이디어를 서비스로 만들기 위해 각자의 방식으로 만들어 갈 텐데

만들어가는 방법으로도 크게 3가지가 있을 수 있습니다.

첫 번째 난 돈이 많으니까 그냥 외주 돌려서 만들면 돼 유형

두 번째 뜻이 맞는 사람들 불러 모아 만들어내는 유형

세 번째 인생은 독고다이야 내가 처음부터 끝까지 다해야지 유형

일반적으로 이런 상황에 있다면 어떤 유형에 속하는지 살펴보겠습니다.

첫 번째의 경우 아주 심플하고 손쉽게 아이디어를 서비스로 만들 수 있는 방법이라 할 수 있습니다

하지만 적지 않는 비용이 발생할 수 있고 여유가 없다면... 패스…

두 번째의 경우 인맥과 리더십이 필요합니다. (리더십 혹은 커뮤니케이션 능력이라고 할 수 있겠네요)

하지만 우리들에게 믿을만한 인맥이 개발과 디자인을 할 수 있는 능력자 일 확률은 매우 희박할 수 있으니 패스…

그렇다면 세 번째만 남았죠

사실 세번째 방법이 현실적일 수 있다고 생각할 수 있습니다.

나 혼자 하니까 돈들 일도 없고, 그리고 혼자 개발하니까 커뮤니케이션 능력 또한 필요가 없을 테니

스스로 공부해서 출시해보자 하시는 의지의 사나이분들 계실 것입니다.

과연… 현실적으로 가능할지 ~ 지금부터 개발부터 서비스 출시까지 필요한 기술들을 한번 정리해 보도록 하겠습니다.

서비스는 다양한 형태로 사용자들에게 제공됩니다.

모든 형태에 대한 서비스를 제가 다 알 수 있는 것이 아니기에

제가 경험했던 웹 서비스 분야와 앱 서비스 분야만을 살펴보도록 하겠습니다.

또한 간단한 유틸성 서비스 말고 회원관리가 필요한 서비스 기준으로 정리해보겠습니다.

사용자가 서비스를 사용하는 과정으로 하나하나 파 들어가면서 필요한 기술들을 살펴보는 것으로 설명드리겠습니다.

사용자가 웹 사이트에 접속을 했습니다.

웹 사이트 페이지가 뜨는군요

여기서 보이는 화면에 모든 시각적인 것들을 웹 디자이너가 디자인을 하게 됩니다.

photoshop 제플린 피그마 등등 디자인 툴을 통해 원하는 디자인을 만들고 가이드를 만들어 냅니다.

해당 디자인의 가이드라인에 맞춰 html/css를 활용해 화면을 퍼블리싱합니다.

이 부분에서 html 마크업 할 수 있어야 하며 css를 통해 원하는 위치에 배치해야 합니다

또한 사용자 환경이 전부 다르기 때문에 반응형을 고려해서 코딩해야 합니다.

사용자가 회원가입 버튼을 통해 회원 가입을 시도합니다.

여기서 사용자의 입력에 따른 이벤트를 시각적으로 가이드해줘야 하며

사용자의 입력이 서버에 전달되기 전 필요한 항목들이 올바르게 작성되었는지

체크 등의 여러 이벤트들을 제어하게 됩니다.

이 부분에서 javascript 를 통해 사용자의 액션 및 여러 이벤트들을 개발하게 됩니다.

javascript로 개발이 되는데 dom을 직접 작업하는 형태보다는 framework를 사용해 개발합니다.

(vuejs , react, angularjs 등이 있습니다,)

사용자가 입력한 회원 정보를 서버로 전달됩니다.

이 부분에서 frontend와 backend의 http/https 통신을 통해 데이터를 전달하게 됩니다.

frontend에서는 보통 axios 나 fetch를 사용하여 서버로 데이터를 전송합니다. 예전에는 ajax를 사용했습니다.

backend에서는 Rest API 서버라고 불러우며 (java , nodejs, php , python 등등 언어로 서버를 구축할 수 있습니다.)

java의 경우 spring 프레임워크가 있으며 nodejs의 경우 express 나 nestjs 가 있습니다.

Php와 파이선의 경우는 제가 다뤄 보지 않아서 잘 모르겠습니다.

서버로부터 전달받은 데이터를 데이터베이스에 저장합니다.

데이터 베이스에 저장하기 전 frontend에서 유효성 검사를 했지만 서버에서도 유효성 검사를 해준 뒤 이상 없는 데이터만

데이터베이스에 저장시킵니다.

여기서 데이터 베이스를 어떤 것으로 할지도 필요합니다.

관계형 데이터 베이스로(Sql DB) 할지 비 관계형 데이터 베이스로(noSql DB) 할지

관계형 데이터베이스로 대표적으로 오라클 , mysql 이 있습니다

noSql로 대표적으로는 mongodb, firebase database , elasticsearch 가 있습니다.

결정된 db에 따라 Rest API Server에 맞는 라이브러리를 사용해야 합니다.

대표적인 라이브러리는 Java Spring의 JPA , nodejs typeorm , 나 mongodb의 경우 mongoose가 있습니다.

일련의 과정이 서버 로그로 저장됩니다.

서버 인프라의 경우 Rest Server와 DB서버가 있을 수 있으며 초기에는 한대의 서버에서 관리해도 무관합니다.

서버의 경우 물리 서버를 이용하거나 클라우드 서버를 이용할 수 있습니다.

물리서버를 임대해서 사용할 경우 월 사용료를 지불하는 방식이지만 클라우드 서버의 경우 사용한 양만큼 지불하는 방식입니다.

클라우드 서버가 구성만 잘하면 정말 안전하고 많은 트래픽에 두려워할 필요 없이 서비스를 운영할 수 있겠지만

비용이 생각보다 많이 발생될 수 있습니다.

그렇다고 물리 서버를 임대해서 진행하게 될 때에는 항시 모니터링을 통해 서버 상태를 체크해줘야 하며 사용자의 몰려 서버 장애에 대한 대응이 늦을 수 있습니다.

인프라를 물리 서버로 하던 클라우드 서버로 하던 서버 구축에 필요한 기술로는 단연 docker 가 있습니다.

Docker swarm이나 쿠버네티스를 통해 자동적으로 클러스터링을 도와주는 툴도 알아야 합니다.

혹은 aws 만 잘 학습하면 인프라 구축 및 운영은 걱정 없을 것입니다.

앱의 경우

Step2 만 다르고 나머지는 동일하다고 생각하시면 됩니다.

Native app으로 개발할지 크로스 플랫폼 GUI 애플리케이션 프레임워크로 개발할지

Native app 으로 개발할 경우 안드로이드 : Java 나 Kotlin을 알아야 하며

iOS : Objective-c 나 Swift를 알아야 합니다.

크로스 플랫폼 프레임워크로 개발할 경우

reactive native를 사용하거나

Flutter를 사용하거나 합니다.

이렇게 해서 서비스를 만들기 위해 필요한 기술 스펙에 대해 살펴봤는데요

심플하게 한 표로 정리해보자면 다음과 같습니다.

백엔드와 프론트엔트로 구분되어 정리하였습니다.

대략적으로 이 내용을 알고 계시는 분들도 계시겠지만

생각보다 많은 부분을 고려해야 하고 학습해야 하는구나 하면서 아이디어를 서비스로 만들지 못하겠구나…

라고 좌절하시는 분들이 계실 수 도 있을 것 같은데요. 걱정은 노노입니다.

제가 열거한 기술 스펙의 경우는 서비스 규모가 있거나 팀 단위 혹은 회사에서 진행되는 프로젝트에서의 상태를 말씀드린 것이고 만일 1인 개발자가 진행하게 된다면??

클라우드 서버를 추천드립니다. AWS 나 파이어 베이스를 추천드리겠습니다.

AWS , 파이어 베이스의 경우 프론트앤드 개발자들을 위해 고안하여 만들어진 서비스로

어렵지 않게 사용이 가능합니다. 물론…. AWS는 어렵긴 합니다만 파이어 베이스는 손쉽게 사용할 수 있습니다.

파이어 베이스를 사용하게 된다면 server세팅이 필요 없고 디비 세팅이 필요 없을 뿐 아니라 인프라 구축 또한 필요 없습니다. Step1 과 Step2 만 고려하시면 서비스를 만들 수 있습니다.

이상으로 서비스가 만들어지기 위해 알아야 하는 기술에 대해서 정리해봤습니다.