Cloud Computing On Demand

안드로이드 운영체제와 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

AWS 를 사용하면서 만나는 Global 서비스들이 여럿 있습니다. CDN 제품인 CloudFront 가 가장 대표적인 Global 서비스이고 CF 에서 사용할 수 있는 WAF (Web Application Firewall) 역시 Global 서비스 입니다. 이런 제품들의 특징은 사용자에게 가까운 곳에서 동작해야 효과가 좋다(?)는 점이죠.

최근 WAF 는 Version 2 를 출시하면서 기존의 WAF 는 WAF Classic 으로 부르기 시작했습니다. 몇 가지 변화들이 있지만 그 이야기를 하려는 것은 아니구요, 새로운 버전이 출시되면서 IAM Policy 에도 WAF v2 에 대응하는 부분이 추가되었고 Console 접근을 하려다 보니 생겼던 에피소드를 IAM Policy 를 살펴보면서 간단히 이야기 해볼까 합니다. 

IAM 에서 미리 정의하여 제공되는 Policy 중 WAF 와 관련된 것은 두가지가 있습니다. 하나는 AWSWAFFullAccess 이고 다른 하나는 AWSWAFConsoleFullAccess 입니다. 이들 Policy 를 사용하여 권한을 부여해 두었다면 Action 항목에 "wafv2:*" 가 자동으로 추가, 적용이 되었고 WAFv2 의 사용에 문제가 없어야 합니다. 개별 정책을 JSON 으로 정의했다면 명시적으로 "wafv2" 를 넣어줘야 합니다. 

# Policy : AWSWAFFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "waf:*",
        "waf-regional:*",
        "wafv2:*",
        "elasticloadbalancing:SetWebACL",
        "apigateway:SetWebACL"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

문제는 기존 WAF Classic 은 화면 진입은 잘 되면서 에러 메세지가 눈에 안 띄는 곳에 나오면서 콘솔 진입시 위 정책이 충분치 않다는 것을 인지하기가 조금 어려웠습니다. 그런데 WAF v2 에서는 Unauthorized 메세지가 대박 크게 나오면서 마치 wafv2 정책이 제대로 들어가지 않은 것처럼 보이는 제보가 들어왔던 것이지요. 결론을 먼저 말하면 위 정책으로는 WAF Classic 이든 WAFv2 든 제대로 동작하지 않는게 정상입니다. 

# Policy : AWSWAFConsoleFullAccess

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "apigateway:GET",
        "apigateway:SetWebACL",
        "cloudfront:ListDistributions",
        "cloudfront:ListDistributionsByWebACLId",
        "cloudfront:UpdateDistribution",
        "cloudwatch:GetMetricData",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:ListMetrics",
        "ec2:DescribeRegions",
        "elasticloadbalancing:DescribeLoadBalancers",
        "elasticloadbalancing:SetWebACL",
        "waf-regional:*",
        "waf:*",
        "wafv2:*"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

AWSWAFConsoleFullAccess 정책을 살펴보면 AWSWAFFullAccess 에 있는 정책들이 모두 들어가 있습니다. 추가로 WAF 적용의 주된 대상이 되는 API Gateway, CloudFront, ELB 관련한 항목들이 추가된 것이 보이는데요, 이들 정책이 있어야 AWS Console 화면 구성에 필요한 정보들을 가져올 수 있고 화면 접근시 Authorization 에러가 발생하지 않게 되는 것으로 생각됩니다. 한참을 헤메다 요 정책을 그룹에 추가해 주고나서 문제를 해소할 수 있었습니다. 

AWS 를 쓰다보면 IAM 에서 적절하고 충분한 권한을 주는 문제에 종종 부딪히게 됩니다. 적용된 정책을 확인하는 페이지도 제공하고 있긴 하지만 실제로 사용자들이 API 호출이나 Console 액세스시에 겪게 되는 문제와 연결고리를 찾기 힘든 경우도 종종 생깁니다. 결국은 경험치가 있어야 하는 것인가 하는 고민에 빠지게 되는 5월의 어느날입니다. 

[ AWS 자격증을 준비하신다면 - 3만명이 수강한 강의 추천드립니다! ]

[ WAF Classic 과 WAF v2 의 비교는 아래 블로그가 깔끔합니다! ]

본 포스팅은 소정의 수수료를 받을 수 있습니다.