Cloud Computing On Demand

업무에 따라 다르겠지만 개인적으로는 DNS 에 대한 핸들링이 무척 많이 필요합니다. 커맨드라인에서 Shell 스크립트를 이용해서 여러가지를 만들어 사용하고 있긴 하지만, 가능하면 Python 이나 node.js 로 필요한 기능을 만들어 사용하는 것이 좋지 않을까 생각하고 있었습니다.

Python 쪽에서 사용할 수 있는 DNS 패키지가 어떤것이 있는지 살펴보다보니 `dnspython` 이라는 걸출한 물건이 있는 것을 발견했습니다. 패키지 공식 페이지에서 이야기 하는 것처럼 dnspython 은 DNS Toolkit 을 표방하고 있습니다. 정말 많은 기능들을 제공하고 있기 때문에 DNS 관련한 도구 개발에 무척 도움이 될 것 같습니다. 

간단하게는 Resolver 역할을 수행하는 것에서 시작할 수 있고, 좀 멀리 나가면 Zone 에 대한 핸들링도 수행할 수 있는 것 같습니다. 개인적으로 사용해 본 내용이 Resolver 중심이고 도메인 이름에 대한 핸들링 정도여서, 실제 필요한 과제에 맞도록 Research 는 조금 더 해봐야 할 것 같습니다. PyPi 에 패키지가 등록되어 있기 때문에 pip 로 패키지를 설치하면 편리하게 사용해 보실 수 있습니다. 

코로나 바이러스의 두번째 웨이브가 한창입니다. 다행히 오늘(9/3) 기준으로 확진자 수가 200명 밑으로 내려오긴 했지만, 긴장의 끈을 놓기에는 여전히 확진자 수가 많습니다. 많은 기업들이 원격 근무를 진행하고 있고 코로나 바이러스 초기에 각 VPN 회사들이 제공해 주었던 임시 라이센스 등을 잘 활용해 왔습니다. 

비용 지불 여력이 되면 유료 계약으로 라이센스를 추가하는 경우도 있겠지만, 소규모 사업장이나 여력이 되지 않는 곳에서는 다른 옵션을 찾아보는 것도 방법이 되겠습니다. 몇 개의 포스팅으로 나누어 소개할 OpenVPN 은 은근 손이 가긴 하지만 저렴하게 VPN 을 구축하는 방법이 될 수 있습니다.

AWS EC2 - OpenVPN 서버 구축 개요

본 포스팅은 OpenVPN 을 설치하여 사용하는 환경으로 IPv4 와 IPv6 를 모두 제공하는 것을 목표로 합니다. VPN 서버를 어디에 구축하느냐에 따라 달라지는 부분들이 있겠습니다만, 널리 사용되는 AWS 의 EC2 를 OpenVPN 서버로 활용하는 방법을 설명하도록 하겠습니다. 작업 순서는 아래와 같습니다.

1. AWS 환경 준비
   • IPv6 대역을 갖고 있는 신규 VPC 생성
   • VPC 내에 Public Subnet 생성
   • Gateway 구성 : Internet Gateway / Egress Only Gateway
   • Routing Table 조정
   • IPv6 주소를 갖는 EC2 배포
2. OpenVPN 설치 및 구성
3. VPN 접속 시험
4. 기타
   • 라우팅 조정

OpenVPN 을 IPv4 전용으로 사용하는 경우에는 절차가 조금 더 간단합니다. 하지만, 미래 지향적인 작업을 추구하는 동시에 AWS 환경에서 IPv6 를 어떻게 활성화 하는지 공부해 본다는 관점에서 단계를 따라해 주시면 좋겠습니다 ^^

1-1. IPv6 대역을 갖고 있는 신규 VPC 생성

AWS 콘솔에 접속후 VPC 를 먼저 생성하겠습니다. VPC 생성시 몇 가지 옵션 항목이 나오는데 <IPv6 CIDR Block> 의 두번째 옵션인 "Amazon provided IPv6 CIDR block" 을 선택합니다. 

IPv4 와 달리 IPv6 는 AWS 에서 자동으로 할당하는 대역을 이용하게 되며, 공인 IPv6 주소를 할당 받습니다. 이렇게 되는 이유는? 저도 조금 더 공부를 해보고 포스팅으로 정리해 보도록 하겠습니다. (요약 : 아직 잘 모르겠습니다) 

1-2. VPC 내에 Public Subnet 구성

VPC 가 생성되었으니 이번엔 Public Subnet 을 구성하도록 하겠습니다. 서비스에서 쓸 서버들이라면 역할에 맞게 Public, Private Subnet 을 구성해야하지만 OpenVPN 서버는 외부 접근이 필수인 서버이니 Public Subnet 만 구성하도록 하겠습니다.

Sunet 생성시 VPC 가 IPv6 를 활성화 해 둔 VPC 가 맞는지 확인하셔야 하구요, 가장 마지막에 있는 <IPv6 CIDR block> 을 "Custom IPv6" 로 선택하여 해당 Subnet 에 할당할 /64 블럭을 입력해 주어야 한다는 정도만 잘 챙기시면 됩니다. 제 경우에는 00 으로 지정을 했습니다.

Subnet 이 생성되었으면 Subnet 의 속성을 조정해 주어야 합니다. IPv6 를 지원해야 하기 때문에 Subnet 에 생성되는 자원에 IPv6 주소를 자동으로 할당하도록 해보겠습니다. 네, 유심히 보셨다면 아시겠지만 "Public" 이라는 단어가 나오지 않습니다. IPv6 주소 체계는 IPv4 와 묘하게 다른 점들이 있는데, 조금 더 공부하고 포스팅으로...

자동 할당 정책들 중 가장 마지막에 있는 <Auto-assign IPv6> 의 체크박스를 체크해 줍니다. 이후 해당 Subnet 에 자원이 생성되면 IPv6 주소를 자동으로 할당 받게 되고, Network ACL, Security Group 에 문제가 없다면 할당된 주소로 Public 에서 접근할 수 있게 됩니다. 

여기까지 문제 없으셨나요? 다음 포스팅에서는 인터넷 구간으로의 통신을 위해 필요한 두가지 Gateway 설정을 해보도록 하겠습니다. 하나는 쉘 접근을 위한 Internet Gateway 이고, 다른 하나는 IPv6 터널링시 외부로의 통신에 필요한 Egress Only Internet Gateway 입니다. 왜 두개를 따로 써야 하는지는 다음 포스팅! 에서 말씀 드리겠습니다.

2020.12.25 - 다음 포스팅이 올라왔습니다. 아래의 링크로 고고!

Stay tuned..!

플러터 Flutter 는 크로스 플랫폼 어플리케이션 개발을 위한 UI 툴킷이다 보니 애플 iOS 와 안드로이드 운영체제를 위한 개발 환경을 각각 구성해야 합니다. 그 중, iOS 개발을 위해서는 아래의 조건이 충족되어야 합니다. 

• Xcode 설치를 위한 MacOS 운영체제
• Xcode 의 완전체 (Full Installation) 설치
• 기타

플러터 의사 선생님의 진단 (Flutter Doctor)

저는 맥북 프로를 쓰고 있었고 Xcode 역시 설치가 되어 있어서 플러터 닥터 Flutter Doctor 가 점검하여 누락된 부분들을 제시된 명령을 이용해서 설치할 수 있었습니다. 이전에 올렸던 플러터 환경 구성 포스팅에서 보았던 플러터 의사 선생님의 진단서를 다시 한 번 인용해 보겠습니다. 

Xcode 의 완전체 설치는 문제가 없었는데 cocoapod 를 설치하는 과정에 문제가 발생했습니다. (참고로, cocoapod 는 Objective-C 나 Swift 를 이용한 개발시 외부 라이브러리에 대한 외부 라이브러리 개발을 위한 종속성 관리 도구 입니다.)

에러 메세지 분석

환경에 따라 나오는 에러의 경로 복잡도(?)는 달라질 수 있습니다. 이게 무슨 에러인가 하고 천천히 읽어보니... 로컬 환경에 설치되어 있는 openssl 을 찾지 못해서 발생하는 것으로 추정되었습니다. `NoMethodError` 라는 메세지 때문에 헷갈렸습니다만, `image not found` 와 `NilClass` 에서 단서를 얻어 "적당한 버전이 설치가 되지 않았거나, 경로가 잘못되었나 보군?" 하는 생각에 도달했습니다. 

$ sudo gem install cocoapods
Password:
ERROR:  Loading command: install (LoadError)
	dlopen(/usr/local/Cellar/ruby/2.4.2_1/lib/ruby/2.4.0/x86_64-darwin16/openssl.bundle, 9): Library not loaded: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
  Referenced from: /usr/local/Cellar/ruby/2.4.2_1/lib/ruby/2.4.0/x86_64-darwin16/openssl.bundle
  Reason: image not found - /usr/local/Cellar/ruby/2.4.2_1/lib/ruby/2.4.0/x86_64-darwin16/openssl.bundle
ERROR:  While executing gem ... (NoMethodError)
    undefined method `invoke_with_build_args' for nil:NilClass

에러 메세지에 나온참조 경로를 일단 찾아보기로 했습니다. "Libbrary not loaded" 메세지 뒤에 나온 경로의 libsll.1.0.0.dylib 파일이 존재하는지를 확인해 보았습니다. 네, 예상대로 파일이 존재하지 않았습니다. 

$ ls /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
ls: /usr/local/opt/openssl/lib/libssl.1.0.0.dylib: No such file or directory

이 파일은 openssl 의 하위 구성 파일이니 MacOS 의 패키지 매니저인 brew 를 이용해서 설치된 openssl 의 정보를 확인해 보기로 했습니다. `brew list [패키지명]` 을 이용해서 아래와 같이 경로를 확인할 수 있었습니다. 

$ brew list openssl
/usr/local/Cellar/openssl/1.0.2s/.bottle/etc/ (8 files)
/usr/local/Cellar/openssl/1.0.2s/bin/c_rehash
/usr/local/Cellar/openssl/1.0.2s/bin/openssl
/usr/local/Cellar/openssl/1.0.2s/include/openssl/ (75 files)
/usr/local/Cellar/openssl/1.0.2s/lib/libcrypto.1.0.0.dylib
/usr/local/Cellar/openssl/1.0.2s/lib/libssl.1.0.0.dylib
/usr/local/Cellar/openssl/1.0.2s/lib/engines/ (12 files)
/usr/local/Cellar/openssl/1.0.2s/lib/pkgconfig/ (3 files)
/usr/local/Cellar/openssl/1.0.2s/lib/ (4 other files)
/usr/local/Cellar/openssl/1.0.2s/share/man/ (1683 files)

gem install 명령에서는 /openssl/lib/... 경로를 참고하고 있었지만 실제 설치된 openssl 라이브러리는 /openssl/1.0.2s/lib/... 경로였습니다. 아마도 개별적으로 HTTP2 지원 등을 위해서 별도로 설치했던 것이 Symlink 변경이나 특정한 환경변수? 에 업데이트가 되지 않은 것인가 하는 의심이 들었습니다.

잘못된 경로의 수정

결국은 brew 가 관리하는 패키지이니 일단 brew 에서 패키지에 대한 경로를 바꿔줄 수 있도록 `brew switch [패키지명] [버전]` 명령을 이용해서 경로를 재수정 해주었습니다. 

$ brew switch openssl 1.0.2s
Cleaning /usr/local/Cellar/openssl/1.0.2s
Opt link created for /usr/local/Cellar/openssl/1.0.2s

이제 잘 되었을까요? 플러터 의사 선생님이 알려준 명령을 이용하여 cocoapods 를 다시 설치해 보았습니다. 이번에는 문제 없이 잘 설치가 되는 것을 확인할 수 있었습니다. 

$ sudo gem install cocoapods
Password:
Fetching: concurrent-ruby-1.1.7.gem (100%)
Successfully installed concurrent-ruby-1.1.7
Fetching: i18n-0.9.5.gem (100%)
Successfully installed i18n-0.9.5
Fetching: thread_safe-0.3.6.gem (100%)
Successfully installed thread_safe-0.3.6
Fetching: tzinfo-1.2.7.gem (100%)
...
...
...
Parsing documentation for cocoapods-1.9.3
Installing ri documentation for cocoapods-1.9.3
Done installing documentation for concurrent-ruby, i18n, thread_safe, tzinfo, activesupport, nap, fuzzy_match, httpclient, algoliasearch, ffi, ethon, typhoeus, netrc, cocoapods-core, claide, cocoapods-deintegrate, cocoapods-downloader, cocoapods-plugins, cocoapods-search, cocoapods-stats, cocoapods-trunk, cocoapods-try, molinillo, atomos, CFPropertyList, colored2, nanaimo, xcodeproj, escape, fourflusher, gh_inspector, ruby-macho, cocoapods after 63 seconds
33 gems installed

플러터 환경 구성 뿐만 아니라 Xcode 개발 환경을 구성하는데 있어서 cocoapods 설치 문제가 발생한다면 위의 방법으로 경로 정보 수정을 해보시기 바랍니다. 

인터넷을 구성하는 많은 요소들 중 도메인 Domain 은 가장 널리 사용되는 것 중 하나입니다. 도메인은 기억하기 어려운 IP 주소를 사람에게 친숙한 방식으로 제공해주는 기술이지요. 안전한 데이터 교환을 위해 사용되는 HTTPS 와 SSL 인증서 역시 도메인 이름을 적극 사용하고 있습니다. 

도메인 이름에는 보통 알파벳과 숫자, 그리고 몇 가지 기호가 사용되는데요, 오늘은 그 중 알파벳에 대한 이야기를 하고자 합니다. 알파벳은 잘 아시는 것처럼 대문자 Uppercase 와 소문자 Lowercase 로 구분됩니다. 도메인 이름의 규격은 알파벳의 대문자와 소문자 중 어떤 것을 사용하도록 하고 있을까요?

도메인 이름에 관한 규격, RFC 1034

도메인 이름에 대한 규격은 RFC 1034 문서에 기술되어 있습니다. 문서의 제목은 `DOMAIN NAMES - CONCEPTS AND FACILITIES` 로 도메인, 그리고 도메인을 다루는 시스템을 설계할 때 따라야 하는 규격들에 대한 이야기를 하고 있는 문서입니다. 

문서의 초두에 나오는 목적 Goal 절을 읽어보면 도메인 이름의 규격이 왜, 어떻게 정해졌는지를 가늠할 수 있는 내용들이 나옵니다. 그 중에서도 가장 눈에 띄는 것은 역시 영어는 두괄식이다라는 것을 느끼게 해줍니다. 첫번째 문단에 나온 내용은 아래와 같습니다. 

The primary goal is a consistent name space which will be used for referring to resources. (RFC 1034, p2)

DNS 와 도메인을 사용하는 이유는 명확합니다. 네트워크에 연결되어 있는 자원들 중 내가 필요로 하는 리소스를 쉽게, 일관성 있게 찾을 수 있도록 해주기 위함입니다. 이를 위해서 일관된 규칙을 갖는 네임스페이스를 만드는 것이 설계의 목적입니다.

대문자와 소문자를 허용하는 것, 그리고 실제로 그것이 어떤 리소스를 지칭하도록 해야 하는가? 에 대한 답은 이미 여기서 나왔다고 생각합니다. 미국 뉴욕의 엠파이어 스테이트 빌딩을 이야기 할 때, EMPIRE STATE BUILDING 이든 empire state building 이든 상관이 없어야겠죠? (문법적으로 고유명사는.... 과 같은 이야기는 일단 자치합시다!)

대소문자 모두 사용할 수는 있지만 둘은 동일하다!

우리가 궁금해 하는 대소문자 사용에 대한 이야기는 문서의 10 페이지에 언급됩니다. 3.5 절의 뒷 부분에 가면 Note that 으로 시작하는 문장이 나옵니다. 여기서 문서는 도메인을 다루는 시스템에서 도메인 이름은 대소문자를 모두 사용할 수 있다고 이야기 하고 있습니다. 

하지만 중요한 것은 이어지는 문장입니다. "No significance is attached to the case" 대소문자 구분은 별로 의미 없다는 말입니다. 그리고 혹시나 오해가 생길까봐 That is 로 한번 더 확인사살을 해주고 있습니다. 

Two names with the same spelling but different case are to be trated as if identical. (RFC 1034, p10)

즉, 대소문자를 자유롭게 사용할 수 있긴 하지만 동일한 것으로 취급해야 한다는 결론입니다. Stack Overflow 등에 올라오는 글들을 보다 보면 특정한 제품군 등에서는 대소문자를 구분하는 경우도 있고, 브라우저들이 어떻게 핸들링 하는가에 대한 이슈도 있긴 한 것 같습니다. 그렇지만 일단 규격이 이야기 하는 것은 대소문자에 관계 없이 동일한 것으로 취급해야 한다라는 점, 기억해 두시기 바랍니다!

Flutter 를 이용하면서 Firebase 를 이용하는 방법을 살펴보겠습니다. 둘 다 구글에서 만든 것이라 그런지 연동하는 것이 어렵지 않습니다. 다만 손이 좀 가게되고 처음 다루는 경우에 조금 헤멜 수 있습니다. 참고로, iOS 용으로 프로젝트를 구성하는 방법을 다루고 있습니다. Android OS 는 별도로 설명해 보도록 하겠습니다. 순서는 아래와 같습니다. 

• Firebase / Firebase 에 새로운 Project 등록하기
• Project Code / Firebase SDK 를 개발중인 Project Code 에 추가하기
• Firebase / Cloud Firestore 에 새로운 Database 생성
• Project Code / Cloud Firestore 의존성을 Project Code 에 추가하기 

Firebase 에 새로운 Project 등록하기

Firebase 는 구글이 제공하는 PaaS 플랫폼입니다. 모바일 앱이나 웹 어플리케이션 등을 개발할 때 필요한 다양한 구성요소와 분석도구를 플랫폼으로 제공하고 있어 별도의 환경을 구성하는 어려움과 번거로움을 줄여주기 때문에 (돈만 잘 내면) 무척 편리합니다.  http://firebase.google.com/로 접근하여 구글 계정으로 로그인한 후 <Create a project> 로 새로운 프로젝트를 생성해 보겠습니다. 

Firebase 는 Project 를 만드는 것에서 부터 시작됩니다. Project 별로 서비스 구성요소나 분석도구 등을 사용할지 결정하고 이용하는 구조입니다. 간단하게 식별할 수 있는 Project 이름과 Project ID 를 취향껏 지정하도록 하겠습니다. 

구글 애널리틱스는 사용자들의 행동 정보를 수집하는데 무척 유용한 도구입니다. 요즘은 웹 어플리케이션 뿐만 아니라 모바일 앱에서도 구글 애널리틱스를 이용하여 사용자 정보를 수집하는 경우가 많습니다. 이 포스팅은 Firebase 를 사용하기 위한 기본적인 설정 방법과 Cloud Firestore 의 셋업에 촛점을 맞추고 있으니 Enable 하지 않고 프로젝트를 생성해 보겠습니다. 

어이쿠! 클릭 몇 번하고 키보드로 몇 가지를 입력하니 금방 프로젝트가 생성되었습니다. 

Firebase SDK 를 개발중인 Project Code 에 추가하기

프로젝트가 생성되고 <Continue> 버튼을 누르면 프로젝트의 첫 화면으로 이동하게 됩니다. 이제 우리가 할 일은 Firebase 공통 SDK 의 설치를 통해 앱 또는 웹 어플리케이션이 Firebase 를 사용할 수 있는 기본 환경을 갖도록 하는 것입니다. 이후 어떤 기능, 제품을 쓰느냐에 따라 라이브러리 의존성 등 필요한 셋팅을 해주면 됩니다. 이 포스팅에서는 <iOS> 환경에 대해 이야기 하고 있기 떄문에 화면의 동그란 아이콘들 중 <iOS> 라고 적힌 버튼을 눌러보도록 하겠습니다. 

앱에서 Firebase 를 사용하기 위한 첫번째 절차는 사용할 앱의 정보를 등록하는 것입니다. iOS Bundle ID 와 닉네임, 앱스토어 ID 등의 정보를 입력해야 합니다. VS Code 를 이용해서 Flutter 를 사용하는 중인데요 VS Code 의 Explorer 에서 Shift + Command + F 를 눌러 PRODUCT_BUNDLE_IDENTIFIER 를 검색하면 Flutter 가 미리 만들어 준 iOS Bundle ID 를 찾을 수 있습니다. ID 값을 복사하여 Firebase 의 등록 화면에 입력해 줍니다. 

Bundle ID 를 넣고 나면 이제 Firebase SDK Config 파일을 다운로드 받을 수 있는 화면으로 이동합니다. Download 버튼을 눌러 GoogleService-Info.plist 파일을 다운로드 받아 Project Code 에 추가해 주어야 합니다. 추가 작업을 위해서는 Xcode 가 필요하니 잠시 Xcode 를 실행해서 VS Code 에서 만들고 있는 Flutter 프로젝트를 열도록 하겠습니다.

Xcode 에서 Runner/Runner 위치에 GoogleService-Info.plist 파일을 추가해 줍니다. 이유는 확인해 보지 못했습니다만 VS Code 에서 해당 파일을 Runner 하위에 넣어주었을 때는 프로젝트 빌드후 실행시 앱이 실행되지 못하고 크래시 되는 문제가 발생했습니다.

Xcode 에서 파일을 추가해 준 경우 동일한 위치에 파일이 생성되긴 하는데... 혹시 이유를 아시는 분은 댓글 부탁드립니다! 여튼, Xcode 에서 파일을 잘 추가했다면 저장후 종료하고 VS Code 로 돌아오면 되겠습니다. 

Firebase 를 위한 환경 설정 파일을 추가했으니 SDK 가 잘 설치되도록 하기 위한 CocoaPod 관련한 확인을 해봐야합니다. Firebase 는 CocoaPod 를 이용해서 의존성 관리를 하고 있기 때문에 CocoaPod 가 잘 동작하고 있어야 합니다. VS Code 에서 Flutter 프로젝트를 생성한 경우 이미 .xcworkspace 파일이 추가되어 있습니다. 따라서 아래 내용은 참고만 하셔도 무방합니다. 

아래의 내용은 Swift 나 Ojective-C 를 이용하는 경우 Firebase 를 초기화 하는 코드의 예제입니다. 우리는 Flutter 를 쓰고 있기 때문에 아래의 코드 역시 무시하고 넘어가셔도 무방합니다. Next 버튼 고고씽!

마지막으로 iOS 에서 Firebase 를 사용하기 위한 가이드 문서 안내가 나옵니다. 시간이 되시는 분들은 한번 문서를 열람해 보셔도 좋습니다. 추후 필요할 때 내용을 찾아보는 정도로 충분하니, 가이드가 존재하는 구나 정도를 인지하고 넘어가도 좋습니다. 

Cloud Firestore 에 새로운 Database 생성

이제 Firebase 사용을 위한 기본적인 준비가 끝났습니다. 이 포스팅에서는 Firebase 가 제공하는 Cloud Firestore 를 쓰기 위해 해주어야 하는 작업을 이야기하고 있기 때문에 Firestore 에 Database 를 생성하는 과정도 살펴보도록 하겠습니다. 앱의 기본적인 설정이 끝났다면 아래와 같은 화면에 도착했을겁니다. 우측의 오렌지색 <Cloud Firestore> 이미지를 눌러 DB 생성을 해보겠습니다.

네, 거침 없이 <Create database> 버튼을 누르겠습니다. 이제 거의 고지에 도달했으니 조금만 더 힘내서 가보겠습니다. 영차, 영차!

Cloud Firestore 는 Production 과 Test 모드를 제공합니다. 연습을 해볼때는 Test 모드로도 충분하겠습니다만 실전에서는 Production 모드를 이용해야겠죠? Test 모드를 선택하고 Next 버튼을 누릅니다. 

Firebase 도 여느 클라우드 서비스와 마찬가지로 여러 리전 Region 을 운영하고 있습니다. 실제 서비스에서는 응답 속도를 감안해야 하기 때문에 주요 사용자가 있는 국가, 장소를 감안하여 리전을 선택해야 하지만 지금은 어떤 것을 선택해도 크게 문제는 없으니... 임의로 선택하시고 Done 버튼을 누르겠습니다. 

Cloud Firestore 는 NoSQL DB 입니다. 다양한 형태의 문서 Document 들의 집합을 취급하게 되고 각각의 Document 집합은 Collection 이라 부르고 있습니다. Collection 을 하나 만들고 샘플 데이터를 넣어보도록 하겠습니다. 

Collection 의 이름을 임의로 지정하고 Next 버튼을 누릅니다. Unique Key 로 사용할 Document ID 는 자동으로 생성할 수 있습니다. Auto-ID 버튼을 활용하시기 바랍니다. NoSQL 이기 때문에 정해진 Scheme 이 없습니다. 원하는 필드를 정의하고 샘플 데이터를 자유롭게 넣어보시기 바랍니다. 

Cloud Firestore 의존성을 Project Code 에 추가하기 

이제 대장정의 끝에 <거의> 도달했습니다. 우리는 지금까지 Firebase 사용을 위한 설정 파일을 생성, 프로젝트 코드에 추가했고 Cloud Firestore DB 를 생성해 보았습니다. Firestore 를 사용하기 위해서 Flutter 프로젝트의 pubspec.yaml 파일에 의존성 정보를 추가해 주어야 합니다. 

Firebase 는 개별 제품, 기능 별로 별도의 패키지를 사용합니다. Cloud Firestore 는 cloud_firestore 라는 이름의 패키지를 추가해야 합니다. Flutter 프로젝트 루트의 pubspec.yaml 에서 dependencies 노드를 찾아 cloud_firestore 를 추가하면 이제 작업 끝입니다. 

다음 포스팅에서는 이렇게 추가된 Cloud Firestore 를 이용하는 방법을 정리해 보도록 하겠습니다. 참고로 다음 포스팅에서 사용할 코드는 오준석님이 쓰신 <오준석의 플러터 생존코딩> 의 Todo 앱 입니다. 해당 책에서는 Android OS 에서 연동 방법만 나와 있어서 조금 아쉬웠는데 이렇게 포스팅으로 정리해 보니 그렇게 어렵지 않다는 느낌입니다 :-) 플러터 입문자를 위한 훌륭한 기본서이니 한번 구매해서 읽어보시죠!

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

안드로이드 운영체제와 iOS 운영체제를 위한 어플리케이션 뿐만 아니라 웹 앱, 데스크탑 어플리케이션까지 단일 코드로 만들 수 있다면 얼마나 편리할까요? 구글이 내놓은 UI 툴킷 플러터 Flutter 가 지향하는 바도 동일합니다. 그래서 다시 한 번 어플리케이션 개발의 로망을 갖고 플러터를 공부해 보기로 했습니다 :-)

플러터 SDK 설치하기

플러터 공식 홈페이지의 설치 가이드 : https://flutter.dev/docs/get-started/install

플러터로 개발을 하기 위해서는 어떤 환경을 대상으로 개발 작업을 할 것이냐에 따라 달라질 수 있습니다. 무모하게도 저는 안드로이드, iOS, 웹 뿐만 아니라 데스크탑 어플리케이션까지 한 번 목표로 해보도록 하겠습니다. 참고로, iOS 어플리케이션으로 배포를 하기 위해서는 맥 기기와 X code 가 필요합니다. 

플러터 SDK 설치는 두가지 방법이 있습니다. 하나는 플러터 공식 웹사이트에서 ZIP 으로 압축하여 배포하는 SDK 를 다운로드 받아 임의의 경로에 풀어서 사용하는 것이고, 다른 하나는 플러터 Git 에 릴리즈된 코드를 Clone 하여 사용하는 것입니다. 저는 후자의 방법을 택하여 로컬 환경을 준비해 보기로 했습니다. 

플러터 Github : https://github.com/flutter/flutter

플러터 Github 리포지토리에서 초록색 Code 버튼을 눌러 주소를 복사합니다. 로컬 환경에 Git 이 설치되어 있지 않다면 여기서 <Download ZIP> 을 눌러서 코드를 받는 것도 가능합니다. 복사한 주소를 `git clone https://github.com/flutter/flutter` 명령으로 로컬 환경에 복제합니다. 용량이 꽤 크기 때문에 시간이 좀 걸릴 수 있습니다. 

복제가 완료되면 X code, 안드로이드 스튜디오, VS Code 등 개발, 빌드 도구가 플러터에 쉽게 접근할 수 있도록 PATH 환경 변수에 경로를 추가해 주어야 합니다. ZIP 으로 다운로드 받아 압축을 푼 경우에도 동일하게 환경변수를 추가해 주면 됩니다. 

//
// flutter 의 최신 릴리즈를 Clone
//
$ git clone https://github.com/flutter/flutter
Cloning into 'flutter'...
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 252325 (delta 0), reused 0 (delta 0), pack-reused 252324
Receiving objects: 100% (252325/252325), 107.44 MiB | 2.17 MiB/s, done.
Resolving deltas: 100% (193972/193972), done.
Checking out files: 100% (4917/4917), done.

//
// PATH 환경변수에 Flutter Bin 경로를 추가
// .bash_profile 이나 .bash_rc 에 추가하는 것을 권장
//
$ export PATH="$PATH:/Users/nopd/dev/flutter/bin"

//
// 환경변수가 잘 셋업 되었는지 which 명령으로 확인
//
$ which flutter dart
/Users/nopd/dev/flutter/bin/flutter
/Users/nopd/dev/flutter/bin/dart

플러터 개발환경 점검하기

플러터는 Doctor 라는 도구를 제공합니다. 터미널에서 `flutter docter -v` 명령을 입력하면 플러터 툴이 추가로 다운로드되어 설치되고, 설치가 완료된 이후 개발 환경 점검을 진행하게 됩니다. 이 도구를 이용하여 개발, 빌드 환경에 필요한 도구가 설치되었는지 확인할 수 있고, 설치된 도구가 플러터를 이해하기 위해 추가로 필요한 플러그인 등이 준비되었는지 확인해 줍니다. 

플러터 개발에 필요한 도구들은 대략 아래와 같습니다. 

• Flutter SDK : 지금 막 설치 완료한 Flutter 개발을 위한 툴킷
• X code : Flutter 로 개발한 Dart 코드를 iOS 환경의 바이너리로 빌드할 때 사용 (Mac Only)
• Android Studio : Flutter 로 개발한 Dart 코드를 안드로이드 환경의 바이너리로 빌드할 때 사용 (Mac / Windows)
• VS Code : Flutter 의 Dart 언어로 코드를 개발할 때 사용할 코드 에디터 (단, 다른 도구를 써도 무방)

//
// Flutter Doctor 를 설치
// (Doctor 는 개발 환경에 문제가 있는지를 점검해 주는 도구)
//
$ flutter doctor -v
Downloading Dart SDK from Flutter engine 280bbfc763cf1154e7fef04eda1565122254bcdc...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  258M  100  258M    0     0  1791k      0  0:02:27  0:02:27 --:--:-- 4955k
Building flutter tool...
...
...
// 설치가 끝나면 점검 작업을 시작
...
...

플러터 Doctor 가 환경 점검을 마치면 아래와 같은 결과 리포트를 출력해 줍니다. 운영체제별 빌드 환경은 코드를 실제 배포하기 위한 준비를 하면서 체크해 보기로 하고 일단은 VS Code 에 대하여 요청된 플러터 익스텐션 Flutter Extension 을 설치해 보도록 하겠습니다. 설치 이후에는 Doctor 를 한번 더 이용하여 잘 설치되었는지 확인해 보겠습니다. 

VS Code 플러터 확장 설치

VS Code 는 마이크로소프트가 만든 오픈소스 통합 개발 환경입니다. 제 경우에는 파이썬 Python 개발과 Node.js 개발, 그리고 Vue.js 를 이용한 UI 개발에 VS Code 를 활용하고 있습니다. 플러터를 개발할 수 있는 코드 편집기는 개인 취향으로 선택할 수 있습니다만 기왕이면 익숙한 툴을 사용하는 것이 좋다고 생각되어 VS Code 를 써보려는 중입니다.

VS Code 는 특정 언어나 환경에 종속되어 있지 않기 때문에 개발하려는 언어, 환경에 따라 필요한 플러그인 혹은 확장 Extension 을 설치해 주어야 합니다. VS Code 를 먼저 실행하고 왼쪽 툴바의 다섯번째에 위치한 확장 기능을 선택하여 플러터 확장을 검색, 설치해보겠습니다. 검색어에 Flutter 를 입력하면 플러터 개발/디버그 확장이 첫번째 결과로 출력됩니다. 

검색 결과의 `Install` 버튼을 누르면 확장이 설치됩니다. 잠시 기다리면 설치가 완료되고 버튼이 `Uninstall` 로 바뀐 것을 보실 수 있습니다. 이제 설치가 완료되었으니 Doctor 에게 다시 한 번 진료를 요청해 보도록 하겠습니다. 다행히 이번에는 모든 점검을 통과하여 그린 라이트가 켜진 결과를 받아볼 수 있었네요! 이제 개발할 준비가 되었으니 본격적으로 코드를 만들어 보도록 하겠습니다. 

...To be continued...

깃허브 Github 에 공개되어 있는 코드를 개량할 때, 회사의 Git 에 등록된 과제의 기능을 개발할 때 우리는 포크 Fork 를 통해 원격 저장소의 코드를 내 저장소로 옮긴후 작업을 하게 됩니다. 

내 저장소에 옮겨진 코드는 필요에 따라 여러개의 브랜치 Branch 로 나뉘어지고, 개별 브랜치들은 내 저장소의 마스터 Master 브랜치와 머지 Merge 후 원격 저장소에 병합 요청을 하거나, 개별적으로 머지 요청을 하게 됩니다.

보통은 이런 절차를 따르기만 하면 문제가 없습니다. 하지만, 내가 포크한 소스코드의 원본 소스코드가 다른 사람에 의해 변경이 진행되고 원격 저장소에 병합된 내용이 등록되었다면 변경된 코드를 내 저장소로 동기화 할 필요가 있습니다.

지금부터 아래의 4단계를 통해 동기화를 진행해 보도록 하겠습니다.

1단계 - 원본 저장소 등록하기 : 업데이트된 파일을 가져오기 위해서 원본 저장소를 로컬 환경에 원격 저장소로 등록합니다

2단계 - 원본 저장소 변경분 로컬로 가져오기 : 업데이트된 파일을 가져오는 방법을 설명합니다

3단계 - 로컬 환경에서 원본 저장소와 포크한 저장소 병합하기 : 두 브랜치를 하나로 합칩니다

4단계 - 포크한 저장소를 원격의 git 에 업데이트 : 변경된 내역을 Push 합니다

1단계 - 원본 저장소 등록하기

우선 작업중인 환경에 원본 저장소를 원격 저장소 Remote Repository 로 등록해야 합니다.

아래의 예는 SSH 로 저장소의 주소를 등재한 경우입니다만, https 로 시작하는 주소를 쓰는 경우도 방법은 다르지 않습니다. 

// 등록된 저장소 확인
$ git remote -v
origin  git@git.mycompany.com:nopd/AwesomeApp.git (fetch)
origin  git@git.mycompany.com:nopd/AwesomeApp.git (push)

// 원격 저장소를 Upstream 으로 등록
$ git remote add upstream git@git.mycompany.com:SAJANGNIM/King.git
...
$ git remote -v
origin  git@git.mycompany.com:nopd/AwesomeApp.git (fetch)
origin  git@git.mycompany.com:nopd/AwesomeApp.git (push)
upstream  git@git.mycompany.com:SAJANGNIM/King.git (fetch)
upstream  git@git.mycompany.com:SAJANGNIM/King.git (push)

2단계 - 원본 저장소 변경분 로컬로 가져오기

원격 저장소를 등록했으면 이제 원본 저장소의 변경된 내용을 로컬로 가져올 차례입니다. 변경된 내용을 가져오기 위해서 우리는 git fetch 명령을 사용할 예정입니다.

아래 명령을 수행하면 원격 저장소, 즉 upstream 저장소의 파일이 로컬에 적재됩니다. 

// 원본 저장소를 upstream 으로 저장했으니 아래와 같이 호출합니다. 
// 파일은 upstream 의 master 브랜치에 저장되었습니다. 
//
$ git fetch upstream master
Enter passphrase for key '/blahblah/.ssh/id_rsa': 
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 9 (delta 7), reused 0 (delta 0)
Unpacking objects: 100% (9/9), done.
From git.mycompany.com:SAJANGNIM/King.git
 * [new branch]      master     -> upstream/master
 
 

3단계 - 로컬 환경에서 원본 저장소와 포크한 저장소 병합하기

2단계 까지 마쳤으면 1) 포크한 저장소 (origin) 의 로컬 환경 파일들과 2) 원본 저장소의 파일들이 로컬 환경에 준비가 된 것입니다.

이제 로컬 환경에서 변경된 파일을 합쳐주면 되겠죠? 포크한 저장소로 브랜치를 변경하고 git merge 명령으로 로컬 환경의 두 저장소 파일을 합치겠습니다.

참고로 브랜치 단위로 머지가 되는 것이니 포크한 저장소의 master 브랜치가 아닌 다른 브랜치를 upstream 의 브랜치와 합쳐도 무방합니다. 필요에 따라 선택해 주면 되는 부분입니다. 

// 포크한 저장소의 로컬 브랜치로 환경을 변경합니다
// 아래 명령에서 master 는 origin/master 브랜치입니다
//
$ git checkout master
Switched to branch 'master'

// 현재 브랜치 (origin/master) 에 원본 브랜치 (upstream/master) 의 변경분을 합칩니다
//
$ git merge upstream/master
Merge made by the 'recursive' strategy.
 apps/modal/Request.vue | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

4단계 - 포크한 저장소를 원격의 git 에 업데이트

이제 로컬 환경은 원본 저장소의 최신 변경 내역이 반영된 따끈따끈한 저장소가 되었습니다.

로컬 환경이 원래의 집이 아니기 때문에 그 어디엔가에 있을 github 혹은 사내의 git 서버에 변경내용을 업데이트 해주어야 하겠죠?

git push 명령으로 소스코드를 원격 서버로 업데이트 해보겠습니다. 

// 손에 너무나도 익은 명령어를 입력해 봅니다
//
$ git push origin master

개발자가 아니고 git 보다는 SVN 이 더 익숙하다보니 여러가지로 시행착오를 많이 겪고 있습니다.

사실 개발자 직군도 아닌지라 필요한 순간에만 git 을 쓰다보니 분명 주요한 명령, 패턴에 대한 한계가 있는 것 같습니다.

비슷한 어려움을 겪는 분들에게 이 글이 도움이 되길 기원해 봅니다. 

혼자 사용하는 서버는 환경 설정을 자유롭게 할 수 있습니다. 자주 사용하는 경로의 지정이나 무언가를 설치했을 때 경로까지 익숙함을 바탕으로 찾아내는데 어려움이 없을 겁니다. 하지만, 서버의 운영체제 버전이 조금 다르다던가 계정 정책의 차이 등으로 패키지가 어디에 설치되었는지 헤메는 경우가 종종 생깁니다.

서버 환경으로 CentOS 를 자주 사용하다보니 패키지 설치는 거의 yum 을 사용합니다. 간혹 커스텀한 구성이 필요하여 직접 빌드하는 경우를 제외하면 관리가 편하기 때문에 yum 을 쓰는 편이죠. 오늘 아침, 자주 안들어가던 서버에서 mtr 패키지가 필요해서 yum 으로 설치했으나 실행이 되지 않는 문제가 있어서 패키지 설치 디렉토리를 찾느라 잠시 헤프닝이 있었습니다. 

// yum 은 패키지는 잘 설치해 주지만, 설치된 위치를 알려주진 않습니다
$ sudo yum install mtr
Loaded plugins: fastestmirror, security
Setting up Install Process
Loading mirror speeds from cached hostfile
 * centos-sclo-rh: mirrors.aliyun.com
 * epel: xxxx.xxxx.xxx
Resolving Dependencies
--> Running transaction check
---> Package mtr.x86_64 2:0.75-5.el6 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================
 Package                 Arch                       Version                            Repository                Size
======================================================================================================================
Installing:
 mtr                     x86_64                     2:0.75-5.el6                       base                      54 k

Transaction Summary
======================================================================================================================
Install       1 Package(s)

Total download size: 54 k
Installed size: 96 k
Is this ok [y/N]: y
Downloading Packages:
mtr-0.75-5.el6.x86_64.rpm                                                                      |  54 kB     00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : 2:mtr-0.75-5.el6.x86_64                                                                            1/1
  Verifying  : 2:mtr-0.75-5.el6.x86_64                                                                            1/1

Installed:
  mtr.x86_64 2:0.75-5.el6

설치는 잘 되었으나 Shell 환경에 지정된 Path 에 잡혀있지 않은지 실행이 되지 않았습니다. 패키지가 설치된 경로를 찾아야 할 때는 rpm 을 사용하면 좋습니다. rpm 과 grep 으로 패키지가 설치되어 있는지 찾아보거나 rpm 에 옵션을 지정하여 패키지 설치 경로를 확인할 수 있습니다. 

// 설치된 패키지의 이름을 확인
$ rpm -qa | grep mtr
mtr-0.75-5.el6.x86_64

// 설치된 패키지의 경로를 확인
$ rpm -ql mtr
/usr/sbin/mtr

일반적인 설치 경로인데 왜 실행이 안되었을까요? 그건 리눅스의 환경 변수중 명령어를 실행할 수 있는 경로의 집합을 나타내는 $PATH 에 경로가 빠져 있기 때문입니다. 한 번 확인해 보고 누락된 경우 추가를 해보도록 하겠습니다. 매번 전체 경로를 넣고 실행하기는 좀 번거롭겠죠? 실제로는 profile 설정 등에서 추가해 주어야 다음번 로그인시에도 경로가 추가된다는 점 잊지 마시구요.

// 꼴랑 두개 들어가 있네요
$ echo $PATH
/bin:/usr/bin

// 기존 $PATH 값에 콜론으로 연결하여 경로를 지정합니다
// 잘 들어갔는지 절대 알려주지 않으니 echo 로 다시 확인을...
$ PATH=$PATH:/usr/sbin
$ echo $PATH
/bin:/usr/bin:/usr/sbin