Cloud Computing On Demand

프로젝트도 만들었고 프로젝트와 어플리케이션의 차이도 살펴보았다. 이번 포스팅에서는 프로젝트 안에 어플리케이션을 생성해 보도록 하자. 딱히 무엇을 만들겠다는 계획이 있는 것은 아니지만, 프로젝트가 큰 개념이고 어플리케이션은 프로젝트 안에 들어가 있는 기능집합의 개념이니, 그 컨셉을 따라가 보자는 것이다. 

어플리케이션의 생성도 프로젝트의 생성과 비슷하다. 사용하는 도구가 약간 달라지는 점에 주의하자. 프로젝트 생성시에는 django-admin 이라는 장고가 제공하는 도구를 사용했다면, 이번에는 프로젝트 안에 생성된 manage.py 를 이용하게 된다. manage.py 는 프로젝트를 브라우저에 한번 띄워볼때 사용했던 바로 그 도구다.

manage.py 를 이용하여
어플리케이션 생성하기

// 별 문제 없이 생성에 성공하면 아무런 메세지도 나오지 않는다. 당황하지 말자.
% python3 manage.py startapp myfirstapp

성공적으로 어플리케이션이 만들어지면 프로젝트 루트 경로에 어플리케이션 이름으로 디렉토리가 생성된 것이 보인다. 디렉토리 안에는 여러가지 장고와 관련된 파이썬 파일들과 디렉토리가 자동으로 생성된 것이 보인다. 각 파일이 무슨 역할을 하는지 알아보아야 하는데 머리가 지끈지끈 아파오는 것 같다.

프로젝트의 settings.py 를 편집하여
어플리케이션을 추가해보자

NoPD 는 친절하기 때문에 다시 한 번 이미지를 첨부했다. 처음 프로젝트를 생성했을때 프로젝트 이름과 동일한 디렉토리가 하위에 하나 더 만들어졌던 것을 기억 할 것이다. 기억이 안나도 기억 난다고 생각하자. 이 경로에 들어가면 settings.py 가 보인다. 대략 자동 생성된 파일들의 위치로 유추해 보건데, (필자 기준으로) nopd 경로 하위에는 프로젝트의 구성요소나 자원에 대한 정보들이 담기고, 각 어플리케이션 하위에는 어플리케이션과 관련된 설정 등이 들어가는 모양이다. (이렇게 자신있게 말하면 안되는데...)

이 파일 안에는 여러가지 설정 값들이 있다. 쉽게 생각하면 장고 웹 프로젝트가 구동되는데 필요한 각종 값들 (경로, 패키지 네임스페이스 등) 을 가지고 있는 파일이다. 새로 추가한 어플리케이션을 프로젝트가 인식하려면 settings.py 에 추가되어야 하는 것이라는 감이 왔을 것이다. 빈 줄과 주석을 모두 제거하면 위와 같은 형태가 되는데, 11행에 있는 <INSTALLED_APPS> 가 우리의 퀘스트다.

INSTALLED_APPS 에는 프로젝트가 사용하는 어플리케이션들이 등록되어 있다. 기본적으로 장고가 제공하는 admin, auth 등 6가지가 추가되어 있는 것이 보인다. 마지막에 한줄을 추가하여 우리의 어플리케이션을 추가해주고 싶은데... 어떤 값을 넣어야 하는 것일까? 다시 우리가 만든 어플리케이션 디렉토리로 이동하여 하위에 생성된 apps.py 를 열면 답이 있다. 

자동으로 생성된 클래스에 name 이 지정되어 있는 것을 볼 수 있다. 이 이름을 가져다가 마지막에 추가해주는 것이 우리의 할일이다. 어렵지 않을테니 들여쓰기에 신경쓰고, 각 아이템을 나누어주는 콤마가 잘 들어갔는지 챙겨주자. 프로젝트의 코드 수정이라니... 뭔가 손에 땀이 나면서 흥미진진하다. 

오늘은 여기까지이다. 아직 갈길이 멀다. 이 프로젝트, 어플리케이션에서 뭘 할지를 정하지 못했기 때문이다 ;;;

장고는 프로젝트에서 데이터베이스를 다룰 수 있도록 Admin 페이지를 제공해준다. php 를 다루어 보았다면 들어보았을, 그리고 크래커들이 기본적으로 외부에 열려 있는지 탐색해보는 phpmyadmin 과 같은 역할을 해준다고 생각하면 된다. 여튼, 뭔가를 하려면 데이터베이스가 꼭 필요한데 우리는 아직 아무런 작업을 하지 않았다. 

다음 포스팅에서는 수퍼유저를 만들기 위해 데이터베이스를 초기화하고 기본 테이블을 만들어 보겠다. 그리고 혹시나 myfirstapp 이 무슨일을 할지 재미있는 아이디어가 떠오르게 되면, 구현에 필요한 테이블도 생성해 보도록 <최선을 다하겠다> 

프로젝트를 무사히 만들고 샘플 페이지도 브라우저에 띄워 보았다. 이어서 settings.py 라는 프로젝트에 대한 구조? 속성? 을 담고 있는 파일을 공부해볼까 하다가... 장고에서 사용하는 프로젝트 Project 와 앱 Application 의 개념을 한번 정리하고 넘어가는 것이 좋을 것 같아서 끊기 신공을 한 번 더 사용해볼까 한다.

우리가 이전 포스팅에서 만든것은 프로젝트 Project 이다. PMP 자격 시험을 본 적이 있거나 프로젝트 관리에 대한 수업을 들어 보았다면 프로젝트는 여러개의 서브 프로젝트로 나뉘어 질 수도 있고, 프로젝트들이 모여서 프로그램을 이루고 어쩌고 하는 이야기들을 들어보았을 것이다. 장고에서도 동일한 개념일까? 이럴때에는 가장 좋은 것이 공식 문서를 보는 것!

길다. 하지만 볼드체가 있으니 차근히 살펴보도록 하자. 첫 문장 가라사데, <프로젝트 Project 라는 용어는 장고 웹 어플리케이션을 말해>. 와닿지 않는다. 조금 더 읽어보면, <프로젝트라 불리우는 파이썬 패키지는 settings 모듈로 정의되긴 하지만 다른 것들도 많이 포함하고 있어> 라고 한다. 이후에 이어지는 명령과 생성되는 파일은 우리가 지난 포스팅에서 봤던 것들인데... 요약하면 프로젝트는 하나의 큰 패키지와 같은 것! 이라는 느낌이다. 

세번째 문단에 오니 앱 혹은 어플리케이션에 대한 이야기를 하고 있다. <어플리케이션 Application 이라는 용어는 몇 가지 기능을 제공하는 파이썬 패키지를 말해> 라니... 그 다음 문장에 재활용 가능하다는 것을 보면 <프로젝트를 구성하는 기능의 집합 단위를 어플리케이션이라고 함> 정도가 될 수 있을 것 같다. 

가령 커뮤니티 사이트를 만드는 프로젝트라고 하면, <커뮤니티 사이트> 자체가 프로젝트의 개념이고, 그 안에서 사용되는 <게시판>, <쇼핑몰>, <개인정보관리기능> 같은 것들이 어플리케이션이라고 보면 무난할 것 같다. 그렇다면 우리가 지난 포스팅에서 프로젝트를 만든 이후에 해야할 것은 무엇일까? 바로 어플리케이션을 만드는 것이다. 

그럼 다음 포스팅에서 프로젝트 하위에 어플리케이션을 만드는 것을 해보고, 그 다음에 settings.py 를 살펴보는 것으로 해보자. 순서야 어떻든 우리가 필요한 것을 잘 이해하면 되는 거니까...!!

이어지는 글들 살펴보기

파이썬에서 사용되는 웹 프레임워크 중 널리 사용되는 것이 장고 Django 와 플라스크 Flask 이다. 둘 다 장단점이 있겠지만 대략 어깨너머로 본 것과 바람을 타고온 이야기를 종합해보면 장고가 조금 더 강력하고 무거운 것 같다. 반면 플라스크는 조금 가볍고 빠르게 웹 기반 산출물을 만들기 좋은 듯 하다. 아니라고? 아니어도 어쩔 수 없다. 파이썬도 잘 모르지만 파이썬의 웹 프레임워크도 아직 잘 모른다. ;;

어찌되었건 근래에 다루고 있는 코드가 장고 기반이라 하나하나 부딪혀가며 과제를 진행시키고는 있지만 밑바닥부터 한번 정리하면서 장고에 대한 지식을 정리해 보고자 한다. 이미 장고를 많이 다뤄본 사람이라면 굳이 읽지 않아도 되는 초보자의 공부 이력이니 응원의 하트나 댓글 정도를 남겨주면 좋겠다. :-)

장고 프레임웍의 설치

장고 프레임웍이 로컬 환경에 설치되어 있다는 것을 가정했다...라고 적다가 혹시 모르니 pip 를 이용해서 장고 패키지를 설치하고 확인하는 절차를 정리해 본다. (...라고 적지만 나중에 까먹을까봐 적어둔다. 나이들어봐라, 기억력이 팍팍 감소한다 ㅜㅜ) 

// 장고를 설치한다. jango 가 아니다, django 다
% pip3 install django

// 설치가 잘 되었는지 확인한다
% python3 -m django --version
2.2.6

물론, Symlink 등이 걸려 있어서 pip3 대신 pip 일수도 있고 python3 대신 python 이나 py 일수도 있다. 각자의 환경에서 동작하는 무언가가 있을테니 잘 찾아서 장고 프레임웍을 설치하면 된다. python3 를 쓰는 것이 좋은데 아마도 새로 시작하면서 2 를 쓰는 경우는 없을거라 생각한다.

프로젝트 생성

장고가 설치되었다면 django-admin.py 혹은 django-admin CLI 도구를 이용하여 프로젝트 생성을 할 수 있다. 물론, 이 도구는 더 많은 것들을 제공하는 장고 관리의 총아이니 앞으로도 종종 이 도구의 명령을 언급하게 될 것인다. 

// 명령도 참 많다. 심지어 Core Command 만 모아서 보여준거라는 친절한 안내가 같이 나와 있다
% django-admin
Type 'django-admin help <subcommand>' for help on a specific subcommand.

Available subcommands:

[django]
    check
    compilemessages
    createcachetable
    dbshell
    diffsettings
    dumpdata
    flush
    inspectdb
    loaddata
    makemessages
    makemigrations
    migrate
    runserver
    sendtestemail
    shell
    showmigrations
    sqlflush
    sqlmigrate
    sqlsequencereset
    squashmigrations
    startapp
    startproject
    test
    testserver
Note that only Django core commands are listed as settings are not properly configured (error: Requested setting INSTALLED_APPS, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings.).

프로젝트를 시작한다를 영어로 표현하면? startproject 이다. 띄어쓰기는 어디갔을까? 라고 태클은 걸지 말자. 위의 코드 블럭에 붙여 놓은 것처럼 startproject 로 붙여 써야 한다. 영어 수업시간이 아니라 장고 수업시간이니 그렇구나 하고 넘어가자! ㅎㅎ 그럼 프로젝트를 만들고 무엇이 생성되는지 확인해 보자

// 현재 경로는 ./dev/django-study 다. 
% django-admin startproject nopd

nopd 라는 폴더가 생성되고 그 안에는 manage.py 가 있고 또 동일한 이름의 폴더 nopd 가 생성되었다. 하위 경로에 생성된 nopd 폴더 하위에는 4개의 python 파일이 생성되었다. 프로젝트에 대한 전반적인 정보를 담고 있는 파일이 settings.py 인데, 프로젝트의 시작은 이 파일에 필요한 내용들을 기술하는 것에서 시작된다고 한다.

폴더명이 동일하게 두개가 생성되는 등 시작부터 뭔가 마음에 들지 않는다. 하지만 먹고 살기 위해서는 장고를 잘 익혀둘 필요가 있으니 절단 신공으로 settings.py 설정에 대한 내용은 다음 포스팅에서 이어가 보도록 하겠다. 다들 알지 않는가? 시작이 반이다. 다만 맨날 시작만 해서 문제지만... 끝까지 함 가보자. 아, 기왕 여기까지 온 김에 실행이라도 한번 해보자!

개발용 웹 서버로
장고 프로젝트 실행하기

// manage.py 를 이용하여 개발 서버를 실행할 수 있다
% python3 manage.py runserver
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).

You have 17 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.

October 30, 2020 - 07:37:06
Django version 2.2.6, using settings 'nopd.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

브라우저를 열고 http://127.0.0.1:8000/ 으로 접근하면 아래와 같은 화면을 볼 수 있다. 이야기 했지 않은가? 시작이 반이라고. 벌써 브라우저에 뭔가가 나오기 시작하는 것이 가슴이 웅장해지는 느낌이 들 것이다. 필자도 그랬다. 그런데 가슴만 웅장해지면 안되지 않겠는가? 우리는 계속 공부를 해나가야 한다. 학창시절에 그랬던 것처럼... 

이어지는 글들...

influxDB 는 시계열 DB (TSDB) 입니다. 일반적인 SQL 문장을 사용할 수 있다보니 종종 TSDB 가 아닌 RDB 로 착각할때가 많습니다. 때문에 일어나는 해프닝이 참 많은데요, <SELECT INTO> 를 이용하여 Measurement 간에 데이터를 옮길 때도 종종 문제가 생기곤 합니다. 

사실 저 역시 infludDB 를 많이 사용해 보지는 못했습니다. 어쩌다 보니 다른 분이 운영하던 Graphite 에 저장하고 있던 데이터가 더 이상 적재되지 않고 있어 어디서부터 손을 대볼까하다 "새롭게 해보자!" 는 마음으로 influxDB 를 구성해서 쓰는 정도이기 때문입니다. 아시겠지만 무언가를 할 때마다 매번 새로운 기분이라...

우선, influxDB 에서 <SELECT INTO> 구문을 사용하기 전에 공식 문서를 한 번 읽어보는 것을 추천드립니다. influxDB 의 공식문서가 마음에 드는 점 중 하나는 설명만 나열하는 것이 아니라 샘플 쿼리와 같은 예시가 중간중간에 소개된다는 점입니다. 설명을 읽는 것도 중요하지만 샘플을 가지고 이해하는 것이 더 좋을떄도 많기 때문이지요!

InfluxDB 공식 문서의 <SELECT INTO> 구문 사용법

# 관련 URL : archive.docs.influxdata.com/influxdb/v1.0/query_language/data_exploration/#the-into-clause

여전히 많은 사람들이 RDB 사고 방식으로 TSDB 를 보고 있나 봅니다. 공식 문서에서도 <Common Issues> 항목으로 <Missing data> 가 있어서 빠르게 해결할 수는 있었습니다. TSDB 에 대한 인식, InfluxDB 의 Tag 에 대한 이해 없이 막 사용하다 보니 발생한 해프닝이겠죠? 사실 이렇게 글을 적고는 있지만 현업에서의 이슈 해결이 급하다 보니 Tag 에 대해 이해할 수 있는 문서들을 더 열람해 보지는 않았습니다. 공부하는대로 다음 포스팅으로 적을 것을 약속합니다 :-)

제 경우의 이슈는 Issue 1 에 설명된 부분이었습니다. RDB 에서 의례 했던 것처럼 아래의 구문으로 특정 값을 가진 데이터를 다른 Measurement 로 옮기려는 것이 제 의도였습니다. 하지만, where 절의 값을 바꾸면서 3회 정도 쿼리를 수행했지만, 목적지의 레코드 갯수는 턱없이 적었습니다. 

SELECT * INTO "new_table" FROM "old_table" WHERE "type"='audio'
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='video'
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='etc'

공식 문서의 Issue 1 에 나온 것처럼 <현재 Measurement 의 태그(tags)를 새로운 Measurement 의 필드(Fields)로 컨버트한다> 는 동작 때문이었습니다. 인지하지 못한 사이에 현재 Measurement 의 "type" 은 태그였던 것입니다. 왜냐구요? 아직 공부하지 못했습니다 ㅜㅜ 여튼 그런연유로 데이터가 계속 겹쳐 써지면서 제대로 이관이 되지 않았던 상황이었습니다.

역시나 문서에 나온것처럼 원래의 태그를 유지하기 위해서는 "GROUP BY *" 구문을 추가하여 사용하여 문제를 해결했습니다. 새로운 데이터베이스에 대한 이해가 부족한 상태에서 필요한 결과물을 빨리 얻으려다보니 생긴 해프닝입니다. 여러분들도 혹시 유사한 문제를 만난다면 구문을 살펴보고 GROUP BY 를 추가해 주면 이슈를 벗어날 수 있을겁니다!

SELECT * INTO "new_table" FROM "old_table" WHERE "type"='audio' GROUP BY *
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='video' GROUP BY *
SELECT * INTO "new_table" FROM "old_table" WHERE "type"='etc' GROUP BY *

지난 포스팅에서 우리는 Firestore 를 Flutter 프로젝트에서 사용하기 위하여 패키지를 추가하는 방법을 살펴보았습니다. Firestore 로부터 데이터를 받아오기 위하여 StreamBuilder 위젯을 통해 Firestore 의 스냅샷을 전달받는 코드를 추가했습니다. 전달된 데이터를 ListTile 위젯에 넣기 위해 DocumentSnapshot 타입을 이용했습니다.

Firestore 를 연동하여 UI 에 저장된 데이터를 표현하는 코드를 모두 추가했으니 이제 실제로 데이터를 넣고 빼는 과정에 필요한 코드를 만들어 보겠습니다. To-Do 앱이기 때문에 1) 할 일 추가, 2) 한 일 삭제, 3) 한 일로 기록 정도의 세가지 동작이 필요할 것 같습니다. 각각 _addTodo, _deleteTodo, _toggleTodo 메서드로 정의하여 _TodoListPageState 클래스에 넣어보겠습니다. (이 예제는 모두 <오준석의 플러터 생존코딩> 에 수록된 예제를 기반으로 합니다)

추가 메서드 만들기

먼저 UI 로 입력받은 할 일을 Firestore 에 등록하는 추가 메서드를 살펴보겠습니다. 삭제나 토글 메서드는 Firestore 에 이미 등록된 데이터를 다루는 메서드이고 추가 메서드는 새로운 데이터를 등록하는 메서드이기 때문에 메서드의 파라메터가 조금 다릅니다. (라고 적지만 그냥 나누어 봤습니다)

  void _addTodo(Todo todo) {
    // setState(() {
    //   _items.add(todo);
    //   _todoController.text = '';
    // });
    Firestore.instance
        .collection('todo')
        .add({'title': todo.title, 'isDone': todo.isDone});
    _todoController.text = '';
  }
  

Firestore 를 이용할 때와 이용하지 않고 State 만 이용할 때의 차이를 보기 위해 setState 를 호출하는 코드를 주석처리만 해보았습니다. 이미 선언한 Firestore 전역 객체가 있기 때문에 코드에서 보이는 것처럼 데이터를 쓸 콜렉션과 필드 값을 지정하는 것이 코드의 전부입니다. UI 의 위젯에 입력한 title 과 isDone 값을 할당하는 것으로 충분합니다. 

삭제, 토글 메서드 만들기

삭제와 토글 메서드는 추가 메서드와는 달리 메서드의 입력 파라메터로 앞서 이야기 되었던 DocumentSnapshot 타입을 받게 됩니다. 삭제하거나 토글해야 하는 데이터가 Firestore 의 데이터이기 때문입니다. 실제 삭제하거나 업데이트(토글) 할 데이터의 고유한 ID 를 알아야 합니다. Firestore 는 NoSQL DB 이기 때문에 데이터 Row 를 Document 라고 부릅니다. 흔히 NoSQL 을 도큐먼트 DB 라고도 부르는 것을 아마 들어보셨을 겁니다. 

  void _deleteTodo(DocumentSnapshot doc) {
    // setState(() {
    //   _items.remove(todo);
    // });
    Firestore.instance.collection('todo').document(doc.documentID).delete();
  }

  void _toggleTodo(DocumentSnapshot doc) {
    // Parameter : 'todo' variable of 'Todo' type
    // setState(() {
    //   todo.isDone = !todo.isDone;
    // });
    Firestore.instance
        .collection('todo')
        .document(doc.documentID)
        .updateData({'isDone': !doc['isDone']});
  }

이번에도 Firestore 객체가 제공하는 delete(), updateData() 메서드를 이용했습니다. 코드 자체는 무척 간단하죠? 주의해야 할 것은 Firestore 는 이러한 트랜잭션 하나하나를 카운트하고 무료 구간을 넘어가면 과금이 시작됩니다. 큰 규모의 데이터를 가지고 코드를 만들어 보고 있다면 트랜잭션 수가 얼마나 카운트 되었는지 중간중간 체크해 보시는 것이 좋습니다. 

시뮬레이터를 이용하여
실제 앱으로 확인해보기

이제 코드가 준비되었습니다. Xcode 가 제공하는 시뮬레이터를 이용하여 지금까지 만든 코드를 실행해보고 실제로 Firestore 에 데이터가 잘 적재되는지를 살펴보겠습니다. VS Code 에서 F5 를 누르고 <Start iOS Simulator> 를 선택하여 코드를 실행하면 됩니다. 참 쉽죠? 

시뮬레이터의 구동은 늘 시간이 걸리죠. 하지만 무사히 구동이 되었고 미리 등록해 둔 4개의 도큐먼트를 잘 가지고 와서 화면에 리스트로 출력을 해주었습니다. 가만히 보니 버튼 이름에 오타가 들어갔군요? 오타를 코드에서 수정하고 저장하면 Hot Reload 되어 수정된 내용이 바로 반영이 됩니다. Vue 로 Frontend 개발하는 느낌이라 무척 편리하네요!

이번에는 할일을 추가하고 Firestore 에 업데이트가 잘 되는지 확인을 해볼까요? 

UI 에서 입력한 새로운 데이터가 문제 없이 Firestore 에도 업데이트 된 것을 확인할 수 있었습니다. 이렇게 세번의 포스팅을 통해 Mac 환경에서 VS Code 를 이용하여 iOS 시뮬레이터에 배포하여 시험해보는 과정까지를 살펴보았습니다. 이유는 잘 모르겠지만 Flutter 와 관련된 책들이 대부분 안드로이드 환경에 대한 이야기가 중심이 되어 있어 iOS 로 배포해보고싶다는 생각에서 작업을 진행해 보았습니다.

이제 Flutter 를 이용해서 실제로 써먹을만한 앱을 기획해서 마켓에 배포해 볼 시간입니다. 100세 시대, 지속적으로 벌이를 할 수 있는 방법이 필요한 시대입니다! 강력 추천해 드리는 <오준석의 플러터 생존 코딩>은 아래의 링크를 참고하시기 바랍니다! 그 사이에 에이콘에서 번역서가 한 권 더 나온거 같으니 한 번 읽어봐야겠습니다!

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급받을 수 있습니다

먹고 살기 바쁘다 보니 첫 포스팅을 올리고 두달여만에 후속 포스팅을 올립니다. 그 사이에 생성해 둔 Firebase 의 Firestore 가 보안 정책 만료가 되었네요. 스스로 적어둔 지난번 포스팅을 다시 참고해 가면서 Firebase 에 Firestore NoSQL DB 를 사용 가능하도록 변경하고 글을 시작하도록 하겠습니다. 지난번 글은 아래의 링크입니다! (블로그가 역시 이렇게 좋습니다 ㅎㅎ)

Firestore 정책 업데이트 하기 

Firebase 의 Firestore 는 최초 생성시 30일간 인증 없이 접근할 수 있는 Rule을 제공합니다. Firestore 콘솔의 <Rules> 탭에서 확인할 수 있습니다. 아마도 8월 14일에 DB 를 생성했고 그 시점으로부터 +1m 시점이 만료 시점으로 잡힌 것 같네요. 불필요한 비용 발생을 막기 위해서 들어가는 코드라고 생각하면 괜찮다는 생각이 듭니다.

물론 실제로 상용 서비스에서 Firestore 를 사용하는 경우에는 날짜 단위의 정책이 아니라 인증을 받은 경우 액세스가 가능하도록 변경하는 것이 좋을 것 같습니다. 자세한 내용은 Firestore 의 Rule 관련한 가이드를 살펴보시기 바랍니다! (이 글이 Firestore 를 위한 글은 아니라서라고 변명해 봅니다)

Firestore 사용을 위한 패키지 Import

지난 포스팅을 잘 따라오셨다면 Firestore 사용을 위한 준비가 끝났습니다. main.dart 파일을 열어서 추가한 Firestore 패키지를 코드에서 사용할 수 있도록 해보겠습니다. dart_todo 앱의 전체 코드 구조는 아래와 같습니다. 

2행에 추가된 것처럼 cloud_firestore.dart 를 import 해주셔야 합니다. 간단한 프로젝트이기 때문에 코드의 구조도 간단합니다. Firestore 를 다루는 코드는 당연히 가장 마지막에 있는 _TodoListPageState 클래스에 기술되어 있습니다. 8행에서 시작되는 Todo 클래스는 Firestore 에 저장할 객체를 들고 있을 코드상의 객체를 위한 클래스 입니다. Firestore 에 생성한 컬럼과 동일한 구조, 자료타입으로 만들어 두었습니다. 

StatelessWidget 으로 선언된 MyApp 은 기본 스캐폴딩을 통해 생성된 코드로 타이틀의 설정, 진입점을 TodoListPage 클래스로 지정해 준 정도의 변경사항만 가지고 있습니다. 코드는 아래와 같습니다

class Todo {
  bool isDone = false;
  String title;

  Todo(this.title, {this.isDone = false});
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: '할 일 관리',
      theme: ThemeData(
        primarySwatch: Colors.red,
      ),
      home: TodoListPage(),
    );
  }
}

_TodoListPageState 클래스 살펴보기

Todo 앱은 ListTile 위젯으로 할일 하나하나를 표현하고 ListTile 은 ListView 의 Child 가 됩니다. ListView 는 다시 Expanded 위젯으로 감싸여 화면에 보여지게 됩니다. Expanded 위젯은 다시 StreamBuilder 위젯으로 감싸 스트림으로 Firestore 의 변경사항과 UI 의 변경이 이루어지도록 코드를 만들었습니다 (네, 제가 한건 아니고 <오준석의 플러터 생존코딩> 책의 내용입니다!)

위젯을 빌드하는 코드를 살펴보겠습니다. 위젯을 또 위젯이 감싸고 또 감싸고... 하는 연속이다 보니 복잡해 보이네요. UI 코드 보다는 StreamBuilder 위젯의 내용을 중점적으로 보시면 됩니다. 

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('남은 할 일'),
      ),
      body: Padding(
        padding: const EdgeInsets.all(8.0),
        child: Column(
          children: <Widget>[
            Row(
              children: <Widget>[
                Expanded(
                  child: TextField(controller: _todoController),
                ),
                RaisedButton(
                  child: Text('추 가'),
                  onPressed: () => _addTodo(Todo(_todoController.text)),
                ),
              ],
            ),
            StreamBuilder<QuerySnapshot>(
              stream: Firestore.instance.collection('todo').snapshots(),
              builder: (context, snapshot) {
                if (!snapshot.hasData) {
                  return CircularProgressIndicator();
                }

                final documents = snapshot.data.documents;
                return Expanded(
                  child: ListView(
                    children: documents
                        .map((todo) => _buildItemWidget(todo))
                        .toList(),
                  ),
                );
              },
            ),
          ],
        ),
      ),
    );
  }

StreamBuilder 위젯의 가장 안쪽 코드에 _buildItemWidget 위젯은 할 일 하나하나를 ListTile 위젯으로 리턴하는게 목표인 위젯입니다. 유의할 점은 Firestore 에서 가져온 NoSQL Document 는 DocumentSnapshot 타입을 이용해야 한다는 점입니다. 코드 한번 보시고 가겠습니다. 

  Widget _buildItemWidget(DocumentSnapshot doc) {
    final todo = Todo(doc['title'], isDone: doc['isDone']);
    return ListTile(
      onTap: () => _toggleTodo(doc),
      title: Text(
        todo.title,
        style: todo.isDone
            ? TextStyle(
                decoration: TextDecoration.lineThrough,
                fontStyle: FontStyle.italic,
              )
            : null,
      ),
      trailing: IconButton(
          icon: Icon(Icons.delete_forever), onPressed: () => _deleteTodo(doc)),
    );
  }

네, 이렇게 UI 에서 Firestore 에 있는 정보를 연동할 준비가 되었습니다. 중간 중간에 보이는 _addTodo(doc), _deleteTodo(doc) 그리고 _toggleTodo(doc) 가 실제 비즈니스로직(?)이 들어간 메서드들이 되겠습니다. 절단 신공을 이용하여 이 세가지 메서드는 다음 포스팅에서 확인해 보도록 하겠습니다!

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급 받을 수 있습니다

HTTPS 통신을 위해서는 SSL/TLS 인증서가 필요합니다. 서버측에 Private Key 와 Public key 를 설치하고, 웹 브라우저로 대표되는 User-Agent 는 Public Key 를 전달받아 통신 구간의 암호화에 사용하게 됩니다. 이러한 인증서에는 여러가지 정보들이 담겨 있는데요 가장 대표적인 것으로 도메인 정보를 담고 있는 CN (Common Name) 입니다. 

 CN 이외에도 인증서에는 인증서와 관련한 여러가지 정보를 담기 위한 필드들이 존재합니다. 위의 네이버 인증서 정보에 나오는 주/도, 소재지, 조직 등의 모든 정보들이 인증서의 Public Key 에 포함되어 사용자에게 전달되는 값 들입니다. 네, 당연히 전송되는 용량에 포함되는 값들입니다. openssl 명령으로 이 인증서를 조금 더 자세히 살펴보면...

...인증서의 발급 체계에 따라 서버 인증서, 중간 인증서, 루트 인증서의 정보를 확인할 수 있습니다. 서버 인증서에 있는 C, ST, L, O 등의 값이 브라우저에 표시되었던 정보임을 알 수 있습니다. 가장 위에 있는 루트 인증서를 보면 OU Organization Unit 라는 값이 있는데요 여기에 www.digicert.com  이라는 인증서 발급사의 도메인 정보가 들어가 있는 것을 볼 수 있습니다.

OU 를 직역하면 조직 단위 내지는 부서명 정도가 될 것 같은데 좀 엉뚱한 정보가 들어가 있는 느낌이죠? 회사에서 사용하는 LDAP 정보를 살펴봐도 보통 OU 에는 부서 혹은 조직 단위에 따른 편제 정보가 들어가 있곤 합니다. SSL/TLS 인증서 세계(?)에서는 이 필드를 원래의 목적과 다르게 사용하는 경우가 많았고, 이로 인해 불필요한 바이트의 전송이 관례적으로 있어 왔다는 것을 짐작할 수 있겠습니다 (=우리의 소중한 데이터를 소모해 왔다는 것도...)

이 필드에 대한 논란이 있어온 이래 저렴한 인증서의 대명사였던 Sectigo (과거 COMODO 였죠) 는 진작에 필드를 제거했습니다. Sectigo 쪽에서는 SSL/TLS 인증서의 제품 정보를 표현하는 것과 같은 용도로 쓰이고 있었던 것 같습니다. 역시나 제정되었던 표준, 약속과는 다른 방향이었습니다.

Digicert 는 대한민국발 인증서 사태이후 시만텍의 인증서 사업을 인수해서 운영하고 있는 가장 큰 CA 중 하나입니다. 이제 Digicert 가 OU 필드를 인증서 발급에 사용하지 않고 인증서 정보에도 포함시키지 않을 것이라고 하니, OU 필드는 퇴출이 확정된 거라 봐도 무방할 것 같습니다. 아울러 사용자들은 자신의 인터넷 회선, 모바일 플랜에서 불필요한 전송 비용을 줄일 수 있게 된 것이기도 합니다. 

[ 참고 링크들 ]

https://knowledge.digicert.com/alerts/ou-removal.html

https://www.xolphin.com/news/Change_in_use_of_OU-fields_in_Sectigo_certificates

코딩이라는 용어는 더 이상 해당 분야 종사자만의 용어가 아닙니다. 아이들도 할 수 있고 비전공자도 할 수 있는 모두에게 열린 영역이 된지 오래인 것 같습니다. 비전공자 분들 중에서도 전공자나 업계 종사자보다 더 뛰어난 코딩 실력을 가진 분들도 종종 뵙게 되어, 늘 반성하는 삶을 살고 있습니다 ^^;;

학교 정규 교육 과정에서 블럭코딩은 이미 편제된지 오래입니다. 집에서 아이들이 엔트리나 스크래치로 만드는 블럭 코드의 양을 보면 실무에서 만드는 코드 이상으로 복잡하고 방대한 경우도 많습니다. 아이들이 논리적인 생각을 블럭으로 쉽게 표현할 수 있는 것이 쉬운 접근을 위한 좋은 방법이 되었다고 생각합니다.

그럼에도 막상 코딩의 세계에 뛰어들고 싶은데 어디서부터 시작하면 좋을지 모르겠다는 이야기도 많이 들립니다. 시중에 책도 너무 많고 어떤 것이 내 수준에 맞는지 찾는 것도 만만치 않죠. 책 가격도 저렴하지 않아 시행착오로 이것 저것 잔뜩 사서 보는 건 현실적으로 좀 어렵습니다. 그나마 부담을 덜어주던 도서관도 비대면 예약, 드라이빙 스루 책 수령이라 쉽지 않습니다.

코드잇 Code It (www.codeit.kr/) 은 바로 그런 고민에서 출발한 것 같은 코딩 강의 서비스입니다. 개인적으로 인프런 Inflearn 에서 여러 강의를 들어 보았고, 유데미 Udemy 같은 곳에서 유료 강의도 듣고 도움도 받고 있지만 개별 강의 단위의 결재 방식이라 <시작지점>을 찾기 어려운 분들에게 -물론 무료 강의도 있으나...- 난이도가 조금 있다는 느낌입니다.

반면 코드잇은 일단 -현재까지는!- 쉬운 시작지점을 제시하며 코스형으로 성장하는 모델을 제안하고 있습니다. 사실 조금 더 심화된 내용을 다루는 강의가 아직은 부족한 느낌입니다만, 처음 시작하는 사람들이 <방향을 설정>하고 강의를 듣기 시작하는데에는 적당합니다. 결정적으로 이를 뒷받침 해주기 위해 월/연간 단위의 무제한 구독권을 제공하고 있기 때문에 강의 선택 실패의 리스크를 줄일 수도 있습니다.

한달 무제한 구독권으로 나와 잘 맞는 강의 서비스인지 확인을 해보면서 다양한 영역의 강의를 들어보고, 잘 맞다는 판단이 든다면 연간 구독권으로 코딩 공부의 세계에 푹 빠져보는 것이 방법이겠죠? 파이썬 강의를 중심으로 프론트엔드와 웹 퍼블리싱, 알고리즘과 컴퓨터 공학 개론까지 입문자를 위한 여러가지 영역을 제안하고 있습니다. 

<코드잇 Codeit, 자세히 살펴보기 [바로가기]>

요즘 느끼는 것이지만 코딩은 결국 <매일매일 조금씩이라도 코드를 다루고 있는가?>가 핵심인 것 같습니다. 간헐적으로 필요할 때만 열심히 구글링해서 돌아가는 코드를 만드는 것도 의미 있지만 내 것으로 만들기는 어렵습니다. 부담 없는 무제한 구독권 방식의 코딩 강의 서비스 코드잇은 스스로 얼마나 듣느냐에 따라 구독권 비용 뽕을 뽑을 수 있으니 모티베이션으로도 넉넉하다는 느낌이네요!

다가오는 긴~~ 추석 연휴. 코로나 바이러스 때문에 놀러가기도 쉽지 않은 요즈음! 코딩 인강에 푹~ 빠져보시는 건 어떨까요? 추석 연휴동안 코딩 실력을 늘려봅시다. 저는 밀린 유데미 강의를 꼭 털어보도록 하겠습니다... 하아... 코세라는 또 어쩔... 

본 포스팅은 제휴마케팅을 통해 일정 수수료를 지급받을 수 있습니다