플머의 개발 연구소

오늘은 AWS에서 가장 많이 쓰는 EC2의 T계열 인스턴스의 특성을 설명한다.

EC2를 사용할 때 가장 흔하게 t2.micro 프리티어를 사용한다.

처음 사용할 때만 해도 특별한 생각 없이 사용했었는데 cpu 성능을 제공하는 방식이 조금 특별하다.

일반적으로 CPU 성능이 정해져있어서 24시간 같은 성능을 제공할 것이라 생각하지만,

T계열 인스턴스들은 기본 성능을 제공하다가, 유저들이 몰리거나 하는 등 기준 이상의 성능이 필요할 경우 버스트 기능이 동작하게 된다. 물론, 공짜는 아니고 인스턴스 사양마다 제공되는 크레딧이 다르고 그 크레딧이 남아있는 동안 버스트 기능을 사용할 수 있다.

기준 이하 성능 사용을 지속할 경우 크레딧이 쌓이고(한계치 있음), 그 이상의 성능을 사용할 경우 크레딧을 소모시킨다.

크레딧이 다 소모되면, 기준 이상의 성능을 발휘하지 못하고 성능은 급격히 떨어지게 된다.

이러한 특성은 평소에는 CPU사용률 저조하다가 특정 시간대에 높은 사용률을 사용해야 할 경우 매우 효율적이다.

그렇지 않고, 24시간 내내 부하가 존재하는 서버의 경우 m4, m5 계열의 인스턴스를 사용하는 것이 바람직하다.

이 계열의 경우는 T계열처럼 크레딧 개념을 사용하지 않고 항상 같은 성능을 제공해준다.

다만, 가격이 비싸다는 장점이 있기 때문에 자신의 서버가 어느 특성에 적합한지를 판단하여 사양을 결정하는 것이 좋다.

T계열 인스턴스 사용시 크레딧의 상태는 CloudWatch에서 확인할 수 있다.

추가로 무제한 모드라는 것이 존재하는데, 이는 크레딧을 모두 소모하고 난 후에도 기준 이상의 성능을 사용할 때 비용을 추가하여 기준 이상의 성능을 사용할 수 있는 모드이다.

t2 인스턴스는 무제한 모드가 기본으로 꺼져있지만, t3 인스턴스의 경우 무제한 모드가 기본으로 옵션이 켜져있으므로 참고하기 바란다.

프리티어를 쓰는게 아니라면 t2보다는 t3 계열 인스턴스 사용하는 것을 추천하며,(아무래도 성능 향상, 비용 절감 등의 효과가 있다)

t3 계열의 경우 t3와 t3a가 나눠지는데, 두 계열 성능은 크게 다르지 않고 가격은 t3a가 싸다.

t3는 intel cpu, t3a는 amd cpu를 쓰는데, 가성비를 따져보면 t3a가 더 나은 것으로 생각된다.

보통 페이지 이동시 Navigator의 pushNamed 혹은 push를 이용한다. 

반대로 페이지를 종료할 경우 pop 함수를 이용한다.

그런데 이러한 기능을 사용하다가 처음 페이지 혹은 앞의 특정 페이지까지 바로 이동해야 할 경우가 발생할 수 있다.

물론 pop() 함수를 여러번 사용하여 해당 문제를 해결할 수도 있지만,

push된 페이지 수가 많을 경우 그만큼 pop을 호출해야 하므로 매우 비효율적이고,

특정 액션에 따라 페이지를 진입하여 경우에 따라 pop()해야 되는 개수가 달라지는 경우는 pop()함수로 해결이 불가능하다.

이 때, popUntil() 함수를 사용하게 되면 특정 페이지까지 pop()을 호출한 것 같은 효과를 낼 수 있다.

Navigator.popUntil(context, ModalRoute.withName("/"));

위 코드는 첫 홈화면까지 pop()을 진행하는 코드이다.

다만 주의해야 할 것이 있다.

popUntil의 두번째 인수로 사용되는 것이 어떤 것을 의미하는지 알아야 한다.

위 코드에서는 "/"으로 쓰였는데 루트로 이동하는 코드이지만 이것 또한 주의할 것이 있다.

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Demo',
      debugShowCheckedModeBanner: false,
      onGenerateRoute: _routes(),
      home: MainScreen(),
    );
  }
}

위 코드는 가장 메인에 해당하는 코드인데, MaterialApp의 home 속성이 MainScreen()로 지정되어있다.

즉, 이 상황에서 여러 push가 이루어지고, Navigator.popUntil(context, ModalRoute.withName("/")); 코드가 실행되면, MainScreen() 화면까지 pop()이 이루어지게 된다.

그 다음 또 간과할 수 있는 문제가 있다.

홈화면이 스플래시 화면이거나 로그인 화면 등의 경우 해당 화면 액션 처리 후 pushReplacement() 를 통해 Back으로 돌아와도 해당 화면으로 돌아가지 않게 조치하는 경우가 있다.

Navigator.of(context).pushReplacement(MaterialPageRoute(builder: (context) => SecondScreen());

위의 코드를 사용하여 첫 홈화면 MainScreen()에서 SecondScreen()로 바뀌었다고 가정하자.

이 때 여러 push로 다른 화면들을 띄워놓고 Navigator.popUntil(context, ModalRoute.withName("/")); 코드를 실행하면 어떻게 될까?

첫 페이지는 SecondScreen()로 바뀌었으니 해당 화면까지 pop()이 되어야 할 것 같지만 SecondScreen()에 대한 라우팅 정보가 없으므로 제대로 홈까지 찾아가지 못하고 모두 pop() 처리를 해버릴 것이다.

Navigator.of(context).pushReplacement(MaterialPageRoute(builder: (context) => SecondScreen(), settings: RouteSettings(name: "/")));

위와 같이 settings 속성으로 SecondScreen() 화면이 "/" 라우팅을 가진 스크린이라는 것을 알려준다.

그렇다면 이 때부터는 popUntil로 "/"를 지정하더라도 SecondScreen()까지만 pop()을 정상적으로 처리할 것이다.

정리하면, popUntil을 정상적으로 사용하기 위해 어떤 페이지든 이동할 때 Routesettings 속성을 반드시 지정하도록 하자.

매우 자주 사용하는 위젯 중 하나인데, 사용하면서 한가지 문제를 발견했다.

ListView에 담긴 내용에는 텍스트, 여러 사진들, 구글 지도 등이 포함되어 있었다.

그런데 문제는 예를 들어, 사진이 보이지 않는 곳까지 스크롤을 했다가 다시 돌아오면 사진이 다시 로딩되는 경우가 발생한다.

지도의 경우도 지도가 안보이는 영역까지 스크롤했다가 빠르게 돌아오면 지도가 다시 로딩되는 경우가 발생한다.

일단 이것의 원인은 리스트뷰 위젯이 메모리 관리를 위해 보이는 부분과 일부 주변 영역에 대해서만 불러오고 표시하기 때문이다.(캐싱을 하지 않는 것이다.)

그래서 느리게 천천히 스크롤하면 해당 문제가 없는 것처럼 보인다.

이 문제를 해결하기 위해 스크롤 하여 안보이는 곳으로 이동한다해도 그 공간의 내용들을 캐싱해놓는 것이다.

다행히도 ListView에 cacheExtent라는 속성이 존재한다. 이것은 보이는 영역으로부터 얼마만큼의 주변 영역까지 캐싱해놓을지 지정하는 속성이다.

픽셀 값이므로 자신이 필요한 만큼 지정해서 사용하면 된다. 무조건 크게 해놓으면 해당 문제는 발생하지 않겠지만 메모리 관련하여 문제가 발생할 수 있으므로 상황에 맞게 적용하는 것이 좋을 것 같다.

EC2를 처음 세팅하고 SSH로 접속하여 date 명령을 실행해보면 시간이 한국 시간과 다르게 표시되어있다.

UTC라고 하는 세계 표준 시간을 사용하기 때문인데 한국 시간에서 9시간을 빼주면 해당 시간이 된다.

좀 더 편하게 시간을 관리하기 위해 시간을 바꾸는데, 보통 여기서 실수를 많이 할 것 같다.

sudo date -s "2021-04-07 20:10:36" 

위와 같이 date명령을 이용해서 날짜와 시간을 변경할 수 있지만 위와 같이 한국 시간으로 바로 변경하면 문제가 된다.

EC2 타임존이 기본적으로 UTC(세계 표준시)로 지정되어있으니, 시간 기준은 세계 표준시로 되어있고 날짜와 시간 값만 한국 시간으로 바뀌게 되는 것이다. 이렇게 되면 다른 서비스와 시간 동기를 맞출 경우 시간이 다르다고 판단하여 인증 등의 문제가 발생할 수 있다.

즉, 제대로 변경하기 위해서는 타임존을 한국 시간으로 변경하면 별도의 시간을 지정하지 않아도 된다.

sudo cat /etc/localtime

위 명령어로 읽어보면 UTC0라는 텍스트가 보일 것이며 이것이 UTC 기준으로 시간이 지정된다는 의미이다.

sudo rm /etc/localtime

sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime

위 두 명령을 차례로 입력해준다.

기존의 UTC기준 타임존 세팅 파일을 제거하고, 서울 기준 타임존 세팅 파일을 적용하는 것이다.

sudo cat /etc/localtime 명령으로 확인해보면 KST-9라는 문구가 확인이 된다.

date 명령으로 바로 날짜와 시간을 확인해보면 한국 시간 기준으로 변경된 것을 확인할 수 있다.

Error: Credential implementation provided to initializeApp() via the "credential" property failed to fetch a valid Google OAuth2 access token with the following error: "Error fetching access token: invalid_grant (Invalid JWT: Token must be a short-lived token (60 minutes) and in a reasonable timeframe. Check your iat and exp values in the JWT claim.)". There are two likely causes: (1) your server time is not properly synced or (2) your certificate key file has been revoked. To solve (1), re-sync the time on your server. To solve (2), make sure the key ID for your key file is still present at https://console.firebase.google.com/iam-admin/serviceaccounts/project. If not, generate a new key file at console.firebase.google.com/project/_/settings/serviceaccounts/adminsdk.  

AWS EC2에 노드JS 서버를 올려서 푸시 서비스를 사용하고 있는데 어느 순간 푸시를 보낼 때마다 위와 같은 메세지가 뜨면서 푸시 서비스가 제대로 작동하지 않았다. 위에 의심되는 원인이 나열되어있듯이 나의 문제는 (1)번에 해당했다. 

내가 서버의 시간을 실수로 전혀 다른 시간으로 변경하면서, 푸시를 위해 파이어베이스 인증하는 과정에서 OAUTH 토큰의 유효 시간 체크에 대한 문제가 발생한 것이었다. 이 문제는 다시 서버의 시간을 정상적으로 돌리면서 해결되었다.

위와 같은 문제가 발생했을 때 서버의 시간을 확인하여 실제 시간과 오차가 많이 발생하지 않는지 확인해보도록 한다.

IOS 앱 배포를 위해 XCODE를 통해 업로드 하던 중 다음과 같은 오류가 발생했다.

Error ITMS-90717: "Invalid App Store Icon. The App Store Icon in the asset catalog in 'YourApp.app' can't be transparent nor contain an alpha channel."

앱 아이콘에 알파 채널이 존재하니 알파 채널을 없애라는 의미이다.

먼저 XCode의 프로젝트 폴더에서 Runner를 선택한다.

그럼 변경된 화면에서, TARGETS -> Runner -> General 탭 -> App Icons Source 우측의 화살표 모양을 클릭한다.

그럼 앱에 사용되는 아이콘 목록이 뜨는데 그 아이콘 목록 중에 1024x1024에 해당하는 이미지 파일을 파인더로 연다.

그 후 내보내기를 알파를 제거하고 진행할 수 있다.

위와 같이 알파 해제 후 저장을 하여 저장된 파일을 기존 1024x1024 파일에 덮어씌우고,

다시 앱 배포를 진행하면 정상적으로 업로드가 된다.

플러터로 개발하면서 안드로이드쪽은 그리 문제된 적이 없는데 IOS쪽은 종종 문제가 생기곤 했다.

IOS 빌드 에러가 한두가지는 아니지만 그 중 속 썩였던 에러가 있었다.

하나는

Xcode's output:

ld: framework not found Flutter clang: error: linker command failed with exit code 1 (use -v to see invocation) note: Using new build systemnote: Planning buildnote: Constructing build description

하나는

Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_FlutterMethodChannel", referenced from: objc-class-ref in FLTPackageInfoPlugin.o "_FlutterMethodNotImplemented", referenced from: -[FLTPackageInfoPlugin handleMethodCall:result:] in FLTPackageInfoPlugin.o

물론 위 에러가 해결 방법은 상황에 따라 다를 수 있다.

대부분 자료를 찾아보면 아래처럼 클린 후 빌드하는 것으로 해결을 한다.

flutter clean

flutter run

그런데 나는 이것으로 해결되지 않았고

flutter pub cache repair라던지,

Runner.xcworkspace를 실행하여 XCode에서 빌드하는 방법 등 거의 3일간을 삽질한 것 같다.

물론 위의 방법으로 해결되는 것이 가장 좋다.

최후의 방법은 플러터 프로젝트에 있는 Build 폴더를 삭제하고, ios 폴더 자체도 삭제를 한다.

(단, ios폴더에 미리 세팅해놓은 코드나 Info.plist, PodFile 파일 등은 백업해놓도록 한다.)

모두 삭제를 했다면 아래 명령을 실행한다.

flutter create . 

이는 현재 상태에서 누락되어있는 파일들을 새로 만들어준다. 즉, ios폴더가 새로 만들어진다.

그럼 이전에 세팅했던 Info.plist , PodFile등을 상황에 맞게 세팅한 후 다시 빌드를 해주면 된다.

생각보다 매우 간단하지만, ios 빌드에서 애를 먹고 있다면 굳이 다른 것을 찾을 필요없이

깔끔하게 다시 시작하는게 최고인 것 같다.

무언가 빌드하면서 꼬이기 시작하면서 알 수 없는 에러들을 뱉어내는데 이 때는 flutter clean만으로도 

완전히 클린이 되지 않으므로 위와 같은 방법을 써야만 할 것이다.

플러터에서는 PODO(Plain Old Dart Object)라고 부르는 다트 객체를 모델을 관리하기 위해 사용한다.

흔히 자바에서 DTO라고 부르는 객체와 동일한 역할을 하는 녀석이라고 보면 된다.

어쨌든 백엔드 서버와의 통신을 이러한 객체 단위로 주로 하게 될테고, 이 객체의 내용은 보통 DB 스키마에 맞추어 사용하게 된다. 그런데 몽고DB의 경우 _id라는 기본적인 필드가 존재한다. (물론 안쓸 수도 있지만 RDB의 Primary Key를 가진 필드와 비슷한 역할을 하는 중요한 필드이므로 안쓰는 경우는 드물다.)

여기서 문제는 하필 필드 이름이 _id 라는 것이다. id 라면 좋았을 것을...

다음과 같이 몽고에서 임시로 컬렉션을 만들고 도큐먼트를 생성해보았다.

조회해보면 _id 필드가 자동으로 생성된다. 이 필드는 인덱스가 기본적으로 붙어있어서 검색시에 빠른 성능을 제공한다.

이제 플러터에서 이에 대한 다트 객체를 만들어보겠다.

일반적으로 만드는 방식대로 다트 객체를 만들어보았다.

빨간줄이 보인다. 매우 거슬린다.

선택적 매개변수의 첫 글자에 _(언더바)가 들어갈 수 없다는 내용이다.

다트에서 지원하지 않으니 몽고DB의 모든 _id를 사용하지 않고 다른 것으로 바꾸고 인덱스를 씌워야 하나?

다행히 해결 방법이 존재한다.

JsonKey라는 어노테이션(Annotation)을 쓰면 된다.

(어노테이션이라는 것은 @기호를 앞에 사용하는 메타데이터라고 보면 된다.)

바로 적용해보도록 하겠다.

두 줄만 추가하면 된다.

json_annotation 를 import 시켜주고 JsonKey annotation을 적용해주기만 하면 된다.

@JsonKey(name: '_id')

이 코드가 핵심인데 실제 키 이름은 _id를 사용한다는 의미이다.

그리고나서 밑에서는 String id 로 선언하여 _id를 사용하지 않고도 _id를 사용하는 것처럼 쓸 수 있다.

보통 서버와 클라이언트의 주고 받는 필드는 일치시켜주는 것이 혼동을 줄이는 일인데,

특히 몽고DB의 경우는 거의 필수적으로 사용될 내용인 것 같다.

_id만 해당되는 것이 아니라 lowerCamelCase를 써야 하는 경우면 다 해당된다고 보면 된다.

그리고 코드 상단에 json_annotation을 import하였는데, 패키지를 찾을 수 없는 경우 json_annotation 패키지를 설치하면 된다. (https://pub.dev/packages/json_annotation)

나는 별도로 설치하지는 않았는데 Dart 버전에 따라 내장되어있는 것 같기도 하다.

MongoDB를 사용할 때 기본이라고 할 수 있는 데이타베이스와 컬렉션에 대해서 알아보고 만들어볼 것이다.

Database라는 것은 MongoDB에서 사용하는 데이타베이스의 가장 큰 단위이다.

Collection은 Database의 하위에 속하는 개념이다.

Field는 모여서 하나의 컬렉션을 구성하게 된다.

Document는 위의 항목으로 구성된 데이타베이스의 실제 데이타이다.

예를 들어서 설명해보겠다.

내가 쇼핑몰을 만들기 위해 DB를 구축해야 하는 상황이고, 쇼핑몰 이름은 신사 쇼핑몰이다.

신사 쇼핑몰 내에서 관리되어야 할 DB에는 유저 정보, 상품 정보, 결제 정보, 문의 내용 등 여러가지가 있다.

여기서 신사 쇼핑몰 이 자체가 데이타베이스가 되고, 유저정보, 상품 정보 등의 내용은 컬렉션이 된다.

그리고 유저 정보 내의 이름, 생년월일, 전화번호 등의 정보는 필드가 된다.

유저정보에 이름, 생년월일, 전화번호 등의 모든 필드를 채운 완성된 하나의 정보가 들어가면 도큐먼트가 된다.

한가지 더 예를 들어서 학원을 운영하는 프로그램을 개발하는데 여기에 구축해야 될 DB를 만든다고 하면,

학원은 데이타베이스가 되고, 학원 내에 필요한 정보들인 선생님 정보, 학생 정보, 과목 정보 등이 컬렉션이 된다.

여기서도 선생님 정보를 예로 들면 선생님 이름, 가르치는 과목 등의 정보가 필드가 된다.

이 필드들이 모두 채워진 하나 이상의 데이타를 도큐먼트라 한다.

위의 예로 어느정도 개념은 잡혔으리라 생각한다.

MySQL과 같은 RDB를 사용해본 개발자라면 ,

MySQL의 Database = MongoDB의 Database

MySQL의 Table = MongoDB의 Collection,

MySQL의 Column = MongoDB의 Field,

MySQL의 Row = MongoDB의 Document로 보면 된다.

이제 각 항목들을 만들어보고 지워보는 등의 작업을 해볼 것이다.

1. Database 생성

> use shinsa

  shinsa 라는 이름으로 DB를 생성한다.

2. Collection 생성 (대소문자 구분에 주의한다.)

> db.createCollection("users");

  users 라는 이름으로 컬렉션을 생성한다. 

  위에서 shinsa라는 DB 생성 과정을 거쳤으므로 shinsa DB 내에 users 컬렉션이 생성되는 것이다.

3. Collection 생성 확인

> show collections;

4. Database 생성 확인

> show databases;

위와 같이 users 컬렉션과 shinsa 데이타베이스가 생성된 것을 확인할 수 있다.

5. users 컬렉션에 유저 도큐먼트를 생성한다.

> db.users.insert({"name": "홍길동", "age": 20, "gender": "man"});

  name 필드, age 필드, gender 필드로 구성된 users 컬렉션에 해당 도큐먼트를 생성하는 명령이다.

6. users 컬렉션의 생성한 데이타를 확인한다.

> db.users.find();

위와 같이 도큐먼트가 추가된 것을 확인할 수 있다.

여기까지가 데이타베이스를 구성하고 조회하는 가장 기본적인 내용이다.

실제로 MongoDB를 실무에서 사용하게 될 때 이런 식으로 DB를 구성하게 될 것이다.

(물론 이 외에 다양한 고급 기능들이 존재하지만 그것은 나중에 다루도록 한다.)

7. 만들어진 컬렉션을 삭제한다.

> db.users.drop(); 

  show collections; 명령으로 users 컬렉션이 삭제된 것을 확인할 수 있다.

8. 만들어진 데이타베이스를 삭제한다.

> use shinsa;

> db.dropDatabase();

  db.dropDatabase() 명령만 사용하여 바로 제거해도 되지만, 실수로 다른 DB를 선택해놓고 삭제하는 것을 방지 하기 위해 use 데이타베이스 명령으로 확실히 데이타베이스를 설정해주고 삭제하도록 하는 것이 좋다.

  이제 show databases; 명령으로 shinsa 데이타베이스가 삭제된 것을 확인할 수 있다.

얼마 전 황당한 일을 겪었다.

로컬 PC에 몽고 데몬을 올려놓고 해당 DB를 연동하여 테스트 서버로 쓰고 있었는데,

갑자기 잘 되던 테스트 페이지에 로그인이 안되며 계정이 없다는 오류를 띄우는 것이었다.

바로 로컬 몽고DB에 접속하여 DB를 확인해보았다.

데이타베이스 목록을 확인해보니, 내가 만들어놓은 데이타베이스는 없어지고 웬 이상한 DB가 들어있었다.

느낌이 불길했다.

해당 DB를 들어가서 컬렉션 목록을 확인했다.

읽어보라고 떡하니 'README'라는 컬렉션이 만들어져 있었고 바로 내용을 확인해보았다.

"All your data is a backed up. You must pay 0.04 BTC to 1FYqD4YtPpcnHyyMiFFigG53s51dcb6xx1 48 hours for recover it. After 48 hours expiration we will leaked and exposed all your data. In case of refusal to pay. we will contact the General Data Protection Regulation, GDPR and notify them that you store user data in an open form and is not safe. Under the rules of the law, you face a heavy fine or arrest and your base dump will be dropped from our server! You can bitcoin here, does not take much time to buy https://localbitcoins.comwith this guide https://localbitcoins.com/guides/how-to-buy-bitcoins After paying write to me in the mail with your DB IP: recoverbase@cock.li and you will receive a link to download your database dump."

아뿔싸... 내가 그 말로만 듣던 랜섬웨어를 당했다니... 분하기도 하고 치욕스럽기까지 했다.

내용은 대충 이렇다. 0.04 비트코인을 지불하면 잃어버린 데이타를 복구해주겠다는 것이고, 

이것을 무시하면 GDPR에 신고하여 법적인 책임을 물게 하겠다는 것이다.

개인정보보호정책에 의해 개인의 정보는 안전하게 관리되어야 하므로 이를 허술하게 관리한 대가로 책임을 묻게 될 수 있는 것이다.

일단 날아간 데이타는 없으면 귀찮아지기는 하겠지만, 크리티컬한 수준은 아니었으므로 버리기로 결심했다.

저런 놈들에게 10원이라도 내어주는건 용납할 수도 없기 때문이다.

(참고로 중요한 데이타라고 하더라도 비용 지불한 후에 돌려받는다는 보장은 없다.)

원인은 매우 간단하다. (그렇기에 더 어이가 없었던 것)

계정 인증이 되어있지 않았기 때문인데 mysql 이나 다른 DB는 설치시 기본적으로 계정 설정에 대한 정보를 물었던 것으로 기억한다.

몽고DB의 경우 설치시 디폴트로 계정 설정이 되지 않고 계정 없이 몽고DB에 어드민 권한으로 접근할 수 있게 된다.

여기에 네트웍 망이 public이라면 '내 데이타를 가져가주세요' 광고하는 꼴이다.

사실 그동안은 네트워크가 내부망으로 구성이 되어있기 때문에 외부에서 DB를 접속할 수 없었고,

계정 설정이 안되어 있어도 크게 문제는 없었을 것이다.

나는 외부 미팅으로 로컬 DB를 잠깐 접근할 필요가 있어서 공유기 포트포워딩 세팅으로 외부망 접근을 열어놓았다.

이 때 몽고DB 내부 접근 계정이라도 만들어 놓았어야 했는데 그걸 하지 않았기에 이 사단이 난 듯 하다.

보안은 아무리 로컬에 구성한다해도 이처럼 어떤 경우가 발생할지 모르므로 계정 인증 설정은 항시 해놓는 것이 문제를 일으키지 않을 것 같다. 설정할 때 비밀번호를 허술하게 해놓는다면 설정하지 않는 것과 비슷할 수 있다.

브루트 포스 공격(Brute force attack)이라는 흔한 암호 해독 공격 방식이 있는데 이는 문자열의 경우의 수를 다 대입하여 적용해보는 것이다. 그러니 비밀번호가 너무 단순하다면 인증 설정이 되어있어도 해킹에 노출될 수 있다. 꼭 복잡한 암호를 설정하길 바란다.

아마 해커들은 현재도 전세계 피씨를 가리지 않고 아이피를 스캔하여 계정 인증 없이 노출된 서버들을 찾아다니고 있을 것이다. 궁금하다면 몽고DB에 그럴싸한 데이타를 올려놓고 계정 인증 없이 외부망으로 노출시키면 3일 이내에 나와 같은 현상을 발견할 수 있을 것 같다.

여러분도 항상 보안에 신경써서 이런 자질구레한 일들이 벌어지지 않길 바란다.