여러분 안녕하세요. 2021년에도 잘 해내시길 바랍니다. 여러분 모두 이미 목표를 달성했거나 달성할 방법을 생각하고 계실 겁니다. 여러분의 목표 중 하나가 코딩을 배우거나 2010년에 웹 개발자가 되는 것이라면 오늘 여러분과 공유할 좋은 것이 있습니다. 바로 2021년을 위한 웹 개발자 로드맵입니다.
이는 2021년 웹 개발자가 되는 방법에 대한 좋은 예시이며 2021년에 웹 개발을 배우고 마스터하는 방법을 안내합니다.
웹 개발자가 알아야 할 프런트엔드, 백엔드 및 그 회의 모든 것을 학습하기 위한 다양한 경로를 모아두었습니다. 웹 개발뿐 아니라 모든 종류의 프로그래머와 소프트웨어 개발자에게 중요한 필수적인 프로그래밍에 대해 알 수 있게 될 겁니다.
또한 로드맵은 3개의 섹션으로 나뉘어 있습니다. 첫 번째 섹션은 모든 웹 개발자가 알아야 하는 공통적인 기술에 대한 것이고 두 번째와 세 번째 섹션은 웹 개발의 두 가지 주요한 영역인 프런트엔드와 백엔드 개발에 관한 것입니다.
선택에 따라서 프런트엔드와 백엔드 모두 다 배울 수 있습니다. 풀 스택 개발자가 되고 싶다면 프런트엔드와 백엔드를 모두 배워야 합니다.
프런트엔드에서는 리액트, 앵귤러, 뷰 js와 같이 원하는 프레임 워크를 선택해 배울 수 있습니다. 모두 배울 필요는 없으며 여러분이 원하는 것을 배우면 됩니다. 제 추천은 2021년에 뷰 js가 더 나은 선택이지만 리액트가 아직 더 많이 사용되고 있습니다.
그건 그렇고 여러분은 전에 이 로드맵을 보았을 수도 있습니다. 웹 개발자가 되기 위한 이 멋진 시각적인 가이드는 Kamranahmedse가 작성하였으며 GitHub 저장소에 게시되었습니다. 제가 가장 좋아하는 저장 소중 하나이며 다시 방문하기 위해 북마크에 추가해 두었습니다.
작년에 인터넷을 둘러보다가 이 훌륭한 페이지를 우연히 발견하게 되었습니다. DevOps LoadMap을 처음 발견했고 바로 Kamran Ahmed의 팬이 되었습니다. 사실 전 이 로드맵을 정기적으로 참고할 수 있도록 인쇄하여 책상에 붙여두었습니다.
이 로드맵은 무엇을 배워야 하는지 알려주지만 학습 방법과 해당 기술을 어디서 배울 수 있는지는 알려주지 않습니다. 저는 이 로드맵의 웹 개발자가 되기 위해 필요한 기술과 프로그래밍 언어, 프레임워크와 라이브러리를 배울 수 있는 몇 가지 유용한 과정과 책의 링크를 제공해 이 부분을 보완하고자 했습니다.
2021년 모든 개발자를 위한 되는 시각적 가이드
어쨌든 여기부터 시작할 것입니다. 앞서 말했듯이 여러분의 관심사에 따라 프런트엔드 또는 백엔드의 경로를 선택할 수 있습니다. 어떤 경로를 선택하든 간에 배워야 하는 노란 권장사항들이 있습니다. 이는 모든 프로그래머가 알아야 할 일반적인 내용입니다.
가장 널리 사용되는 버전 관리 시스템 중 하나입니다. Git 없이는 더 이상 살 수 없을 정도입니다. Udemy에서 Git Comlete Guide를 확인해 Git을 시작할 수 있습니다.
2. SSH
모든 웹 개발자가 알아야 하는 또 다른 인기 있는 네트워킹 개념인 SSH는 다른 호스트에 대한 로그인을 제거할 수 있도록 해줍니다.
3. HTTP와 HTTPS
HTTP 프로토콜은 웹의 중심이며 HTTP와 HTTPS에 대한 충분한 지식은 웹 개발자에게 필수적입니다.
4. 기본 터미널 사용 법 및 리눅스 CLI 기초.
웹 개발자뿐 아니라 모든 프로그래머에게 리눅스 CLI는 매우 중요하므로 시간을 내 배우는 것이 좋습니다. Udemy의 리눅스 CLI 기본 과정은 새로 시작하기 좋은 장소이며 만약 마음에 든다면 무료 리눅스 강의를 통해 리눅스를 배울 수 있습니다.
5. 자료 구조 및 알고리즘
모든 프로그램의 기초이며 자료 구조와 알고리즘에 대한 더 나은 지식은 다음 작업과 현재 작업을 더 잘 수행하는 데 있어서 중요합니다. 자료 구조와 알고리즘을 배우는데 관심이 있다면 여러분이 이해하고 있는 프로그래밍 언어로 된 과정을 선택하는 것이 좋습니다. 예를 들어 자바 개발자의 경우 "Data Structures and Algorithms: Deep Dive Using Java"가 시작하기 좋으며 자바 개발자와 마찬가지로 자바스크립트 개발자는 Colt Steele의 "JavaScript Algorithms and Data Structures Masterclass"가, 파이썬을 이용하는 경우에는 "Algorithms and Data Structures in Python"이 좋습니다. 또한 여러분이 리소스에서 배우는 것을 꺼리지 않는다면 이 무료 알고리즘 과정 리스트를 사용해 시작할 수도 있습니다.
7. 문자 인코딩
전 세계의 다양한 언어로 정보를 표시하는 글로벌 애플리케이션을 개발해야 한다면 문자 인코딩에 대한 시직이 있어야 합니다. 문자 인코딩은 기본적으로 브라우저에 데이터를 표시하는 방법을 알려줍니다.
8. GitHub
모든 프로그래머는 버전 제어와 코드 저장소 측면에서 표준인 Git과 GitHub를 알아야 합니다. Git 및 GitHub을 배우고 마스터하려면 이 무료 Git 과정을 확인하세요.
이번에 C++로 AWS SDK를 사용할 일이 생겼습니다. 매우 오래된 구식 프로그램이라 AWS SDK를 지원하지 않아 VC100에서 먼저 업그레이드해야 할 상황이 닥쳤습니다. 한참을 끙끙대며 업그레이드하고 나니 C#과는 달리 C++에서는 직접 소스를 빌드해 SDK를 사용해야 한답니다. C#처럼 Nuget을 이용할 수 있을 줄 알았는데... 아무튼 이번 글에서는 C++에서 AWS SDK를 사용할 수 있는 방법에 대해 알아보도록 하겠습니다.
Nuget 패키지 관리자로 검색해보면 AWSSDKCPP라는 이름의 패키지가 존재하긴 합니다. 하지만 글 쓸 당시 aws-sdk-cpp GitHub에서는 1.8 버전이 릴리즈 되었지만 Nuget에서는 1.6 버전이 최신이었습니다. 따라서 이 글에선 CMake를 이용해 C++용 AWS SDK를 직접 빌드해 사용하는 방법에 대해 알아보도록 하겠습니다.
0. 요구사항.
C++용 AWS SDK를 사용하기 위한 요구사항은 다음과 같습니다.
VisualStudio 2015 또는 그 이상.
GNU Compiler Collection(GCC) 4.9 또는 그 이상.
CLang 3.3 또는 그 이상
4GB의 메모리(큰 규모의 클라이언트 구축을 위해서 필요합니다. 메모리 부족으로 인해 SDK 빌드가 실패할 수도 있습니다.)
사전 요구사항을 확인한 후 빌드를 준비합니다.
1. CMake 준비
프로젝트 빌드를 위해 CMake를 미리 설치해야 합니다. CMake 페이지로 이동해 빌드할 플랫폼에 맞는 CMake를 설치해 준비합니다.
Github 페이지 우측 상단에 Zip으로 다운로드하기가 있습니다. 원하는 버전의 전체 소스코드를 다운로드하여 압축을 풀어 주세요. 전 1.8.118 버전을 다운로드하여 D:\Dev\aws-sdk-cpp-1.8.118 폴더에 압축을 풀어주었습니다.
3. 솔루션 및 프로젝트 생성
이제 CMake를 실행시켜 프로젝트를 만들어줍니다. BrowseSource 버튼을 클릭해 코드가 위치한 폴더를 선택합니다. BrowseBuild 버튼을 클릭해 CMake 결과물이 위치할 폴더를 선택합니다.
전 위와 같이 설정해 줬습니다. 폴더를 설정해 준 뒤 Configure 버튼을 클릭합니다. CMake가 선택한 Source폴더를 확인해 자동으로 설정을 구성합니다. Configure 버튼을 클릭하면 생성될 프로젝트를 설정할 수 있는 창이 보입니다. 원하는 대로 선택해 줍니다.
원하는 대로 설정 후 Finish 버튼을 클릭하면 구성을 시작합니다. 아래의 텍스트 박스에 진행상황에 대한 로그가 같이 남습니다. 느긋이 기다려 주도록 합니다.
작업이 완료되면 가운데 구성 설정 목록이 나타납니다. 또한 앞서 설정한 빌드 폴더로 가보면 프로젝트 생성에 필요한 파일이 복사되어 있는 것을 확인할 수 있습니다.
원하는 설정이 있다면 여기서 변경해 주시면 됩니다. 일단 CMake가 생성한 기본값을 갖고 솔루션과 프로젝트를 생성해 보도록 하겠습니다. 설정이 끝나면 Generate 버튼을 클릭해 주세요.
잠시 기다리면 "Generating done" 메시지와 함께 솔루션 및 프로젝트 생성이 종료됩니다. 이후 앞서 설정한 binaries 폴더인 Build 폴더에 들어가면 C++ 솔루션이 생성되어 있습니다. 이제 솔루션으로 프로젝트를 빌드 해 AWS SDK를 사용할 수 있습니다.
큰 규모의 리액트 앱을 폴더와 파일로 구성하는 방법은 서로 다른 의견이 많은 주제입니다. 정답이 존재하지 않는 주제이기 때문에 이 주제에 대해 글을 쓰는 한동안 고생했습니다. 하지만 매주 사람들이 내게 자신의 리액트 프로젝트를 어떻게 구성해야 하는지 물어봅니다. 폴더 구조는 작은 규모의 리액트 프로젝트뿐 아니라 확장 가능한 리액트 애플리케이션에서 더 중요합니다. 수년간 개인 프로젝트, 고객의 프로젝트의 리액트 애플리케이션을 구현했고 이러한 문제에 내가 어떻게 접근했는지 설명하도록 하겠습니다. 5개의 단계만 거치면 여러분에게 의미가 있는 게 어떤 것인지 정할 수 있고 어느 정도까지 원하는지 알 수 있습니다. 그럼 시작해 보도록 하겠습니다.
"난 내가 좋다고 느껴질 때까지 파일을 옮깁니다"라고 말하는 사람은 아마 혼자 개발하는 사람이나 소규모 팀에서는 괜찮을 수도 있습니다. 하지만 한 기능을 4명이 개발하고 5개의 팀이 있는 회사에서 실제로 수행할 수 있을까요? 더 큰 규모의 팀에서는 "명확한 비전 없이 그냥 파일을 이동하는 것"은 더 까다롭습니다. 게다가 고객이 내게 이 문제에 대해 물어봤을 때 말할 수 있는 내용이 아닙니다. 따라서 이 연습은 좀 더 명확한 것을 찾는 모든 이들을 위한 참조 가이드입니다.
2. 단일 리액트 파일.
첫 번째 단계는 다음 규칙을 따릅니다: 하나의 파일로 모두를 규정짓습니다. 대부분의 리액트 프로젝트는 src 폴더와 App 컴포넌트가 있는 하나의 src/App.js 파일로 시작합니다. creatr-react-app을 사용했을 때 얻을 수 있는 최소한의 것입니다. 이 App 함수형 컴포넌트는 다음과 같은 것을 렌더링 합니다:
새로운 리액트 프로젝트를 시작할 때마다 한 파일에 여러 컴포넌트를 포함시키는 것이 괜찮다고 말합니다. 심지어 큰 규모의 프로젝트에서 한 컴포넌트가 다른 컴포넌트에 긴밀히 묶이는 것도 괜찮습니다. 하지만 이 시나리오에서는 결국 리액트 프로젝트에서 한 파일만으로는 더 이상 충분하지 않습니다. 이제 2단계로 전환을 해야 할 때입니다.
3. 여러 리액트 파일.
두 번째 단계는 다음 규칙을 따릅니다: 여러 파일로 모두를 규정짓습니다. List와 ListItem 컴포넌트를 갖는 이전 App 컴포넌트를 예시로 들어보겠습니다. 모든 것을 가진 하나의 src/App.js 파일 대신 컴포넌트들을 여러 개의 파일로 분리할 수 있습니다. 여기서 여러분이 얼마나 멀리 갈지 정합니다. 예를 들어 전 다음 폴더구조 까지만 갈 겁니다:
- src/
--- App.js
--- List.js
src/List.js에는 List와 ListItem 컴포넌트의 자세한 구현을 갖고 있을 수도 있지만 List 컴포넌트를 분리해 공용 API로 다음과 같은 파일로 내보냅니다.
만약 더 나아가길 원한다면 ListItem 컴포넌트도 별도 파일로 추출하고 List 컴포넌트가 ListItem 컴포넌트를 import 하도록 할 수 있습니다.
- src/
--- App.js
--- List.js
--- ListItem.js
하지만 앞서 말한 것처럼 ListItem 컴포넌트는 List 컴포넌트와 강하게 묶여 있기 때문에 좀 더 멀리 가야 할 수도 있습니다. 그래서 ListItem을 src/List.js 파일에 남겨두는 것도 괜찮습니다. 저는 리액트 컴포넌트가 재사용 가능한 리액트 컴포넌트가 될 때마다 다른 리액트 컴포넌트에서 액세스 할 수 있도록 마치 앞서 List 컴포넌트에서 했던 것처럼 독립적인 파일로 나누는 경험의 법칙을 따릅니다.
4. 리액트 파일에서 리액트 폴더로.
여기부터 더 흥미로워지고 의견이 다양해집니다. 모든 리액트 컴포넌트는 결국 복잡해집니다. 더 많은 조건부 렌더링이나 리액트 훅과 같은 더 많은 로직이 더해지고 스타일링과 테스트 같은 더 많은 기술적 고려사항 해문입니다. 별다른 지식이 필요하지 않은 접근 방식은 리액트 컴포넌트 옆에 더 많은 파일을 추가하는 것입니다. 예를 들어 모든 리액트 컴포넌트에 테스트와 스타일 파일이 있다고 가정해 봅시다.
이 파일들의 네이밍은 여러분에게 달려있습니다. 예를 들어 index.js, component.js, test.js, spec.js가 될 수 있습니다. 게다가 만약 여러분이 CSS를 사용하지 않고 Styled Components와 같은 것을 사용하고 싶다면 파일 확장자도 style.css에서 style.js가 될 수 있습니다. 여러분들의 네이밍 규칙에 익숙해졌다면 IDE에서 "List index" 혹은 "App test"를 검색해 파일을 열 수도 있습니다. 컴포넌트의 폴더를 모두 축소하면 여러분은 매우 간결하고 명확한 폴더 구조를 볼 수 있습니다.
- src/
--- App/
--- List/
예를 들어 특정 컴포넌트에 대한 커스컴 훅을 파일로 추출해야 하는 것과 같이 컴포넌트에 기술적으로 고려해야 할 점이 많다면 컴포넌트 폴더 내에서 수평적으로 확장하는 방법으로 접근할 수 있습니다.
중요한 점은 여기부터 컴포넌트가 서로 너무 깊게 중첩되지 않도록 신경 써야 합니다. 제 경험에 따라 저는 컴포넌트가 두 레벨 이상 중첩되지 않도록 합니다. 따라서 List 폴더 내 ListItem 폴더는 괜찮지만 ListItem 폴더에 다른 중첩된 폴더가 있어서는 안 됩니다.
중간 사이즈의 리액트 프로젝트 규모를 넘어설 것이 아니라면 이것이 여러분의 리액트 컴포넌트를 구조화하는 방법이라고 생각합니다. 하지만 제가 언급했듯이 이는 이견이 있을 수 있고 모든 이들의 입맛에 맞지는 않을 수 있습니다.
5. 기술적인 폴더를 분리.
다음 단계는 중대형 이상 규모의 리액트 애플리케이션을 구조화하는데 도움이 될 것입니다. 여러 컴포넌트에서 사용하는 기능을 컴포넌트로부터 분리합니다. 다음 폴더 구조에서 예를 들어보도록 하겠습니다.
이전 리액트 컴포넌트를 새로운 component 폴더로 그룹화합니다. 이것은 다른 카테고리 폴더를 생성하기 위한 수직적 레이어를 제공해 줍니다. 예를 들어 어느 시점에 여러 컴포넌트에서 사용할 수 있는 리액트 훅이 있을 수도 있습니다. 이 훅을 컴포넌트에 강하게 결합하는 대신 모든 컴포넌트에서 사용할 수 있도록 전용 폴더에 훅의 구현을 위치시킬 수 있습니다.
여기에 컴포넌트와 훅에 접근이 필요한 다른 유틸리티가 있을 수도 있습니다. 다양한 유틸리티의 경우 저는 주로 service 폴더를 생성합니다. 이름을 여러분에게 달려있지만 이 기술적인 분리를 이끄는 것은 우리 프로젝트의 다른 코드에서 로직을 사용할 수 있도록 한다는 원칙입니다.
다행히도 자바스크립트의 Intl API는 날짜 변환을 위한 훌륭한 도구들을 제공합니다. 하지만 리액트 컴포넌트에서 API를 직접적으로 사용하는 것 대신에 서비스를 제공하는 방식이 더 좋습니다. 이 방식을 사용하면 내 컴포넌트에 애플리케이션에서 사용할 수 있는 날짜 형식 옵션을 보장할 수 있기 때문입니다. 그렇지 않으면 애플리케이션이 커가면서 많은 다른 날짜 포맷이 있을 겁니다.
PaymentForm이 Button이나 Input에 액세스 해야 하는 경우 재사용 가능한 UI 컴포넌트 폴더에서 가져와 사용하면 됩니다. MessageList 컴포넌트에 추상 List 컴포넌트가 필요하면 List 컴포넌트를 가져와 사용하면 됩니다. 더 나아가 이전 단계의 서비스가 도메인에 강하게 결합되어 있으면 서비스를 특정 도메인 폴더로 이동시킵니다. 앞서 기술적으로 분리된 폴더에도 동일하게 적용될 수 있습니다.
각 도메인 폴더에 중간중간 services 폴더가 필요한지 여부는 여러분에게 달려있습니다. services 폴더를 제외하고 ErrorTracking폴더의 내용을 Error폴더에 직접 넣을 수도 있습니다만 ErrorTracking은 리액트 컴포넌트가 아닌 서비스로 표시되어야 하기 때문에 혼란스러울 수도 있습니다. 대안으로 ErrorTracking대신 error-tracking처럼 PascalCase보다 kebab-case를 사용해 명명할 수 있습니다.
여기에는 개인적인 공간이 존재합니다. 경국 이 단계는 도메인을 하나로 모아 회사의 여러 팀이 프로젝트 전체에서 특정 도메인에서 작업할 수 있도록 하는 것입니다.
7. 맺는 글
모든 글이 끝났습니다. 여러분 또는 다른 팀이 리액트 프로젝트를 구성하는데 도움이 되기를 바랍니다. 표시된 접근 방식 중 어느 것도 바꾸기 어렵거나 불가능한 것이 아닙니다. 오히려 전 여러분들이 이것들을 개인에 맞게 적용해 사용하기를 바랍니다. 모든 리액트 프로젝트는 시간이 지남에 따라 규모가 커지므로 대부분의 폴더 구조도 그에 맞게 자연스레 변합니다. 따라서 이 5단계의 과정은 문제가 발생할 경우 몇 가지 지침을 제공하는 가이드일 뿐입니다.
그리고 다시 push를 해봅니다. 사실 이 방법으로 해결되면 이 글을 읽고 있지 않을 겁니다. 다른 원인에 대해 생각해 봅시다.
3. Nginx 문제
제 경우에 해당하는 원인이었습니다. 전 Harbor를 Private registy로 사용하고 있으며 해당 서버에 Nginx를 이용해 proxy_pass를 설정해 둔 상태입니다.
또한 push명령을 직접 치기 귀찮아서 Harbor의 Repository에서 알려주는 Push Command를 복사해서 사용했습니다. 문제는 여기서 발생했습니다.
예를 들어 Harbor의 HTTPS 기본 포트를 변경해 사용하고 있다고 가정합시다. 443에서 1443으로 변경한 뒤 prepare를 통해 harbor.yml을 생성하게 되면 docker-compose.yml은 자동적으로 포트를 1443:8443으로 설정하게 됩니다. 또한 이런 식으로 설치된 Harbor는 Push command에 default port가 변경되었으므로 자동으로 1443 포트를 추가하게 됩니다.
대부분의 사람들은 데이터베이스를 생각할 때 행(row)과 열(column)로 구성된 테이블을 포함하는 전통적인 관계형 데이터베이스 모델을 생각합니다. RDBMS는 여전히 인터넷에서 가장 많은 데이터를 처리하지만 개발자들은 관계형 모델의 한계에 대한 해결방법을 찾으려 노력함에 따라 최근 몇 년간 관계형 모델을 대체할 수 있는 데이터 모델이 좀 더 보편화되었습니다. 이러한 비 관계형 데이터 베이스 모델은 NoSQL이라 불리며 각각의 고유한 장점, 단점, 사용 사례를 확인해 보도록 하겠습니다.
이 글에서는 좀 더 일반적으로 사용되는 몇 가지 NoSQL 데이터베이스 모델을 소개합니다. 장점과 단점 중 일부를 평가하고 데이터베이스 관리 시스템의 몇 가지 예시와 각각에 대한 잠재적 사용 사례를 제공합니다.
2. Document 기반 데이터베이스.
문서 기반(Document-oriented) 데이터베이스 또는 문서 저장소는 데이터를 문서 형태로 저장하는 NoSQL 데이터베이스입니다. 문서 저장소는 Key-Value 저장소의 한 유형입니다. 각 문서에는 고유한 식별자(Key)가 있으며 문서 자체가 값(Value)의 역할을 합니다.
이 두 모델의 차이점은 Key-Value 데이터베이스에서 데이터가 불투명하게 처리되고 데이터베이스가 그 안에 보관된 데이터를 알거나 신경 쓰지 않습니다. 어떤 데이터가 저장되는지 이해해야 하는 것은 애플리케이션에 달려있습니다. 하지만 문서 기반 데이터베이스에서는 각 문서에 일정 수준의 구조를 제공하는 일종의 메타 데이터가 포함되어 있습니다. 문서 기반 데이터베이스는 사용자가 문서에 포함된 메타 데이터 기반으로 검색할 수 있는 API 또는 쿼리 언어를 제공합니다. 또한 문서 내에 다른 문서를 중첩할 수 있으므로 복잡한 데이터 구조도 표현할 수 있습니다.
주어진 객체의 데이터가 여러 테이블이나 다른 데이터베이스에 분산될 수도 있는 관계형 데이터베이스와는 달리 문서 기반 데이터베이스는 주어진 객체의 모든 데이터를 단일 문서에 저장할 수 있습니다. 문서 기반 데이터베이스는 일반적으로 데이터를 JSON, BSON, XML, YAML로 저장하고 일부는 PDF 같은 이진 형식으로 저장할 수도 있습니다. 일부는 데이터 검색에 SQL 변형, 전체 텍스트, 고유한 쿼리 언어를 사용하고 일부는 다른 둘 이상의 쿼리 메서드를 사용하기도 합니다.
먼저 기반 데이터베이스는 최근 몇 년 사이에 인기가 매우 증가하였습니다. 유연한 스키마 덕분에 전자상거래, 블로그, 분석 플랫폼, 콘텐츠 관리 시스템에서 사용되었습니다. 문서 기반 데이터베이스는 확장성이 높은 것으로 여겨지며 일반적인 수평 확장 전력은 샤딩(Sharding)입니다. 구조가 다르고 복잡한 정보를 보관하는데 탁월합니다.
인기 있는 오픈소스 문서 기반 데이터베이스는 다음과 같습니다:
MongoDB: 이 글이 쓰였을 땐 이 범용 분산 문서 기반 데이터 베이스인 MongoDB가 세계에서 가장 널리 사용되던 문서 기반 데이터베이스였습니다.
Couchbase: 원래 Merbase로 알려졌으며 JSON 기반의 Memcached와 호환되는 문서 기반 데이터베이스로 알려졌습니다. 다중 모델 데이터베이스인 Couchbase는 Key-Value 데이터베이스로도 동작할 수 있습니다.
Apache CouchDB: Apache SW Foundation의 프로젝트인 CouchDB는 데이터를 JSON문서로 저장하고 JS를 쿼리 언어로 사용하는 문서 기반 데이터베이스입니다.
3. Graph 데이터베이스.
그래프 데이터베이스는 문서에 데이터를 저장하고 데이터가 미리 정의된 스키마를 따르지 않는다는 점에서 문서 기반 데이터 모델의 하위 범주로 생각할 수 있습니다. 하지만 그래프 데이터베이스는 개별 문서 간의 관계를 강조해 문서 모델에 별도의 레이어가 추가된다는 점이 다릅니다.
그래프 데이터베이스의 개념을 더 잘 이해하기 위해선 다음 용어를 이해해야 합니다:
Node: 노드. 노드는 그래프 데이터베이스에서 추적하는 개별 엔티티의 표현입니다. 관계형 데이터베이스의 레코드, 행(row) 문서 기반 데이터베이스의 문서 개념과 거의 같습니다. 예를 들어 음악을 녹음하는 아티스트의 그래프 데이터베이스에서 노드는 연주자나 밴드가 될 수 있습니다.
Property: 속성. 속성은 개별 노드와 관련된 정보입니다. 위의 예를 다시 사용하면 보컬리스트, 재즈, 플래티넘 인증 음악가 등이 될 수 있습니다.
Edge: 그래프 또는 관계(Relationship)로 알려진 에지는 두 노드가 어떻게 관련되어 있는지를 나타내며 RDBMS와 문서 기반 데이터베이스와 구별되는 그래프 데이터베이스의 핵심 개념입니다. 에지는 방향이 지정되거나 지정되지 않을 수도 있습니다.
Undirected: 무방향성. 방향성이 없는 그래프에서 에지는 노드 간의 연결을 표시하기 위해 존재합니다. 이 경우 에지는 양방향의 관계로 생각할 수 있습니다. 한 노드가 다른 노드와 어떻게 관련이 있는지에는 암시적인 차이점이 없습니다.
Directed: 방향성. 방향성 그래프에서 에지는 관계가 시작된 방향에 따라 다른 의미를 가질 수 있습니다. 이 경우 에지는 단방향의 관계로 생각할 수 있습니다. 예를 들어 방향성 그래프에서 Sammy가 그룹을 위해 앨범을 제작한 경우 Sammy와 Seaweeds의 관계를 방향성을 통해 지정할 수 있지만 Seaweeds에서 Sammy로의 방향성의 의미는 앞의 경우와 동등하지 않습니다.
특정 작업은 관련 정보를 연결하고 그룹화하는 방식 때문에 그래프 데이터베이스를 사용하는 것이 훨씬 간단합니다. 이러한 데이터베이스는 일반적으로 데이터 포인트 간의 관계에서 무언가를 얻어야 하거나 엔드 유저가 사용할 수 있는 정보가 소셜 네트워크처럼 다른 사람과 연결에 의해 정해지는 경우에 사용됩니다. 주로 사기 감지, 추천 엔진, ID 및 액세스 관리 애플리케이션에서 사용됩니다.
인기 있는 오픈 소스 그래프 데이터베이스는 다음과 같습니다:
Neo4j: 네이티브 그래프 저장 및 처리 기능을 갖춘 ACID 호환 DBMS입니다. 이 글이 작성될 때 Neo4j는 세계에서 가장 인기 있는 그래프 데이터베이스였습니다.
ArangoDB: ArangoDB는 그래프, 문서 기반, Key-Value 데이터 모델을 하나의 DBMS로 통합하는 다중 모델 데이터 베이스이며 배타적인 그래프 데이터베이스가 아닙니다. SQL과 유사한 쿼리 언어인 AQL, 전체 텍스트 검색, 랭킹 엔진이 특징입니다.
OrientDB: OrientDB는 그래프, 문서 기반, Key-Value, 객체 모델을 지원하며 또 다른 다중 모델 데이터베이스입니다. SQL 쿼리, ACID 트랜잭션을 지원합니다.
4. 마침.
지금까지의 글에서 현재 사용 중인 NoSQL 데이터 모델 중 몇 가지를 살펴보았습니다. 객체 기반 데이터베이스와 같은 일부 NoSQL 모델은 수년간 다양한 수준의 사용 사례를 보였지만 일부에서는 관계형 모델에 대한 사용 가능한 대안 수준으로만 남았습니다. 객체 관계형(Object-Relational) 데이터베이스나 시계열(Time-Series) 데이터베이스 등 다른 것들은 관계형과 NoSQL의 데이터 모델을 혼합하여 일종의 DB 스펙트럼의 두 끝점 사이의 중간 지대를 형성합니다.
데이터베이스의 NoSQL 범주는 매우 광범위하며 지금도 계속 발전하고 있습니다. NoSQL DBMS 및 그 개념에 대해 좀 더 자세히 알아보려면 NoSQL에 관련된 콘텐츠 라이브러리를 확인해 보는 것이 좋습니다.
대부분의 사람들은 데이터베이스를 생각할 때 행(row)과 열(column)로 구성된 테이블을 포함하는 전통적인 관계형 데이터베이스 모델을 생각합니다. RDBMS는 여전히 인터넷에서 가장 많은 데이터를 처리하지만 개발자들은 관계형 모델의 한계에 대한 해결방법을 찾으려 노력함에 따라 최근 몇 년간 관계형 모델을 대체할 수 있는 데이터 모델이 좀 더 보편화되었습니다. 이러한 비 관계형 데이터 베이스 모델은 NoSQL이라 불리며 각각의 고유한 장점, 단점, 사용 사례를 확인해 보도록 하겠습니다.
이 글에서는 좀 더 일반적으로 사용되는 몇 가지 NoSQL 데이터베이스 모델을 소개합니다. 장점과 단점 중 일부를 평가하고 데이터베이스 관리 시스템의 몇 가지 예시와 각각에 대한 잠재적 사용 사례를 제공합니다.
2. Key-Value 데이터베이스.
Key-Value 저장소라고도 불리는 Key-Value 데이터베이스는 연관 배열(Associative Array)을 관리하고 저장함으로써 동작합니다. Dictionary 또는 해시 테이블이라고도 하는 연관 배열은 키가 키에 연관된 값을 검색하기 위한 고유 식별자 역할을 하며 이 키와 값을 한쌍으로 이 쌍들의 모음으로 구성됩니다. 값은 정수 또는 문자열과 같은 간단한 개체부터 JSON구조와 같은 복잡한 개체 이르기까지 다양합니다.
사전 정의된 데이터 타입이 있는 행과 열의 테이블로 구성된 데이터 구조를 정의하는 관계형 데이터베이스와 달리 Key-Value 데이터베이스는 구조나 관계(Relation) 없이 데이터를 단일 컬렉션으로 저장합니다. 애플리케이션은 데이터베이스 서버에 연결한 후 키(예를 들면 the_meaning_of_life)를 정의하고 나중에 키로 검색할 수 있는 값(예를 들어 42)을 제공할 수 있습니다. Key-Value 데이터베이스는 내부에 보관된 모든 데이터를 불투명한 Blob로 처리합니다. 그 구조를 어떻게 이해하는지는 애플리케이션에 달려있습니다.
Key-Value 데이터베이스는 주로 성능이 뛰어나고 효율적이며 확장 가능하다고 설명됩니다. Key-Value 데이터베이스의 일반적인 사용 사례는 캐싱, 메시지 대기열(Queuing), 세션 관리 등입니다.
인기 있는 오픈소스 Key-Value 데이터 저장소는 다음과 같습니다:
Redis: 데이터베이스, 캐시, 메시지 브로커로 사용되는 인메모리 저장소. 문자열, 비트맵, 스트림, 공간 인덱스까지 다양한 데이터 구조를 지원합니다.
Memcached: 메모리에 데이터와 개체를 캐싱하여 데이터 기반의 웹사이트와 애플리케이션의 속도를 높이는데 자주 사용되는 범용 메모리 개체 캐싱 시스템.
Riak: 고급 로컬 및 다중 클러스터 복제 기능이 있는 분산 Key-Value 데이터 베이스.
3. Columnar 데이터베이스.
Colimn orianted 데이터 베이스라고도 불리는 Colimnar(열 기반) 데이터베이스는 열(Column)에 데이터를 저장하는 데이터베이스 시스템입니다. 이는 기존의 관계형 데이터베이스와 비슷해 보일 수 있지만 열을 테이블로 그룹화하는 대신 각각의 열은 시스템 저장소의 별도의 파일 또는 영역에 저장됩니다.
열 기반 데이터베이스에 저장된 데이터는 레코드 순서로 나타납니다. 즉 한 열의 첫 번째 항목이 다른 열의 첫 번째 항목과 관련됩니다. 이 디자인을 사용하면 쿼리가 테이블의 모든 행을 읽고 메모리에 저장된 후 불필요한 데이터를 삭제할 필요 없이 필요한 열만 읽도록 할 수 있습니다.
각 열의 데이터는 동일한 유형이므로 다양한 저장 및 읽기 최적화 전략을 사용할 수 있습니다. 특히 많은 열 기반 데이터베이스 관리자는 하나의 열이 차지하는 공간을 최소화하기 위해 연속 길이 부호화(run-length encoding)와 같은 압축 전략을 구현합니다. 이는 쿼리가 더 적은 행(rows)을 이동하게 하므로 읽기 속도를 높일 수 있습니다. 그러나 열 기반 데이터베이스의 한 가지 단점은 각 열을 개별적으로 작성해야 하고 데이터가 종종 압축된 상태로 유지되기 때문에 성능이 좋지 않은 경향이 있다는 것입니다. 특히 증분(Incremental) 로드와 개별 레코드 읽기는 성능 측면에서 많은 비용이 들 수 있습니다.
열 기반 데이터베이스는 1960년대부터 사용되었습니다. 그러나 2000년대 중반 이후 열 기반 데이터 모델이 빠른 쿼리 처리에 적합하기 때문에 열 기반 데이터베이스가 데이터 분석에 널리 사용되기 시작했습니다. 또한 애플리케이션이 열에서 데이터 평균 또는 합계를 찾는 것과 같은 집계 기능을 자주 수행해야 하는 경우에도 열 기반 데이터베이스가 유리합니다. 일부 열 기반 데이터베이스 관리 시스템은 SQL 쿼리를 사용할 수도 있습니다.
인기 있는 오픈소스 열 기반 데이터베이스는 다음과 같습니다.
Apache Cassandra: 확장성, 가용성, 성능을 극대화하도록 설계된 열 기반 저장소입니다.
Apache HBase: 대용량 데이터에 대해 구조화된 스토리지를 지원하고 Hadoop과 함께 동작하도록 설계된 분산 데이터베이스입니다.
ClickHouse: 분석 데이터 및 SQL 쿼리의 실시간 생성을 지원하는 내결함성(Fault tolerant) DBMS입니다.
4. 마침.
NoSQL 데이터베이스 중 Key-Value 데이터베이스와 열 기반 데이터베이스에 대해 알아보고 그중 일부의 예시를 들어보았습니다. 다음 글에선 문서 기반(Document oriented) 데이터베이스와 그래프 데이터베이스에 대해 알아보도록 하겠습니다.
