플머의 개발 연구소

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일 이내에 나와 같은 현상을 발견할 수 있을 것 같다.

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

오랜만에 안드로이드 스튜디오 프로젝트를 열고 Gradle Sync 도중 위와 같은 오류가 발생하였다.

무언가 해당 Gradle 버전에 종속적인 문제가 발생한 것으로 예측된다.

이 때 간단히 해결할 수 있는 방법으로는 정상적으로 빌드될 수 있는 안정된 Gradle 버전을 찾는 것이다.

우선 내가 사용하고 있는 버전을 확인해보자.

안드로이드 스튜디오에서 File -> Project Structure -> Project 탭을 보면 아래와 같은 창을 확인할 수 있다.

내가 사용하는 플러그인 버전은 3.2.1이고, Gradle 버전은 5.1.1이다.

이 버전을 변경하기 위해서는 플러그인 버전에 따라 필요한 Gradle 버전이 무엇인지를 알아야 한다.

나는 기존 플러그인 버전이 3.4.1이었기 때문에 Gradle 버전을 5.1.1 버전을 사용했었다.

여기서 플러그인 버전을 3.2.1로 설정하고, Gradle 버전을 4.6으로 변경하여 사용할 것이다.

프로젝트 최상단 폴더의 build.gradle 을 열면 플러그인 버전을 변경할 수 있다.

위와 같이 기존 플러그인 버전 대신 3.2.1로 변경하고, 그 다음에는 Gradle 버전을 변경해주어야 한다.

프로젝트 폴더\gradle\wrapper\gradle-wrapper.properties 파일을 열면 버전을 수정할 수 있다.

위와 같이 기존 버전 대신 4.6 버전을 넣어주었다.

이제 위의 Try Again 버튼을 클릭하여 문제가 해결되었는지 확인하면 된다.

정상적으로 빌드까지 마친 것을 확인하였다.

혹시나 위의 버전으로도 오류가 난다면 위 '플러그인과 Gradle 버전 관계표'를 보고 적절한 버전을 찾아가야 할 수도 있다.