02. 개인 프로젝트인데 도커 왜 써?

일단 MySQL은 가장 보편적인 데이터베이스다. 그리고 운영체제에 맞춰 직접 설치해 사용하면 된다. 그럼에도 불구하고 도커를 사용하는 이유는, 그만큼 시스템 환경에 종속되어 다른 개발자와 동일한 환경을 맞추기 어렵기 때문이다.

 

..라고 지금까지는 얘기해 왔다. 그런데 한 가지 따져볼 게 있다. 그저 평범한 개인 프로젝트에 불과한데, 타 개발자와 공유할 일이 있을까? 있긴 한가? 없다면 왜 쓰지?

 

사실 도커를 사용하는 이유는 단순히 다른 개발자가 나와 환경을 맞추기 위해서가 아니다. 도커는 오직 나 혼자 개발하더라도, 내가 편하기 위해서 채택하는 것이다. 그리고 그 이유는 환경 관리에 있다.

 

1. 만약 A 프로젝트는 MySQL 8.0이 필요한데, B 프로젝트는 MySQL 5.7이 필요하다면?
2. 만약 C 프로젝트도 MySQL 8.0을 필요로 하는데, MySQL 설정이 A 프로젝트에 맞게 수정된다면?

 

1번 상황 먼저 얘기해 보자. 가장 간단한 방법은 프로젝트마다 MySQL 기존 버전을 삭제하고, 필요로 하는 새 버전으로 설치하는 것이다. 하지만 이 방법은 간단해 보이지만 과정이 반복될수록 엄청난 피로도를 가져올 것이다.

 

그렇다면 두 가지 버전을 동시에 설치하면 되지 않을까? 이론적으로 충분히 가능하다. 단, 보통의 데이터베이스들은 기본적으로 한 번에 한 버전만 시스템 서비스로 실행되도록 설계되어 있다. 따라서, 두 버전을 동시에 설치하고 실행하려면 포트 충돌을 피하기 위한 설정이 요구된다. 아마 시스템 서비스 등록 방식도 변경해야 할 것이다. 마찬가지로, 요구되는 버전이 늘어날 수록 쉽지는 않아 보인다.

 

만약 도커를 사용했다면 각 프로젝트의 도커 컴포즈 파일에 'image: mysql:8.0', 'image: mysql:5.7' 이런 식으로 정의했을 것이다. 프로젝트 작업 시 각 프로젝트 폴더에서 'docker compose up'을 실행하면 그만이다. 도커가 각 프로젝트에 필요한 독립된 MySQL 컨테이너를 알아서 생성하고 관리해주니, 특별한 번거로움이 없다.

 

2번 상황은 생각보다 더 심각하다. 초보 개발자 입장에서 "MySQL 8.0은 그냥 8.0 아니야?"라고 할 수 있는데, 사실 버전 자체는 고정되어 있지만 내부적으로는 수많은 설정들이 존재한다. 그리고 이러한 설정들은 애플리케이션의 요구사항이나 성능 최적화를 위해 변경될 수 있다.

 

예를 들어 A 프로젝트에서는 대규모 트래픽을 처리해야 해서 쿼리 캐시나 InnoDB 버퍼 풀 크기를 매우 크게 설정해야 한다고 치자. 그렇다면 'innodb_buffer_pool_size = 4G' 이런 식일 것이다. 반면, C 프로젝트에서는 작은 규모의 개인 프로젝트라 캐시를 최소화하거나 아예 비활성화하는 것이 리소스 효율적이라고 가정하자. 그렇다면 'innodb_buffer_pool_size = 128mb' 이런 식일 것이다.

 

그런데 트래픽 상황과 관련한 이러한 가정 또한 사실 억지스러운 면이 있다. 고작 취업준비생의 개인 프로젝트인데 웬 대규모 트래픽? 맞는 말이다. 그렇다면 문자 인코딩을 가정해 보자. A 프로젝트는 국제화를 위해 'utf8mb4' 문자 인코딩을 엄격히 적용해야 하는데, C 프로젝트는 한글만 지원해서 utf8을 기본으로 사용한다면?

 

뿐만 인가. A 프로젝트는 문제 진단 목적으로 슬로우 쿼리 로그나 제너럴 로그를 상세하게 남기도록 설정하고자 하는데, C 프로젝트는 로그를 최소화하여 디스크 공간을 절약하고 싶다면? 각 프로젝트 특성에 따라 연결 타임아웃이라던가 최대 연결 수 같은 DB 연결과 관련된 설정 값들이 달라진다면?

 

벌써 머리가 굉장히 아프다. 이것저것 과한 가정일 수 있지만, 개인 프로젝트라고 해서 절대 안 쓸거라는 보장이 있나? 그것 또한 아니라고 생각한다. MySQL 서버의 cnf 파일, 또는 ini 파일을 직접 수정해 가며 서버를 재시작하는 것을 상상해 보자. 결국 이 모든 건 하나의 물리적인 MySQL 서버를 여러 프로젝트가 공유하면서 파생되는 일들이다.

 

1번 상황과 마찬가지로, 단순히 도커를 사용하면 해결되는 일이다. 도커 컴포즈 파일에 cnf 파일을 볼륨 마운트로 연결하면 그만이기 때문이다. 심지어 C 프로젝트에서는 기본 설정과 같다면 그대로 사용하면 된다.

---

환경 관리가 필요할 정도로 프로젝트가 다양하지 않은데?

그래도 할 말은 있다. 만약 1년 뒤에 프로젝트를 다시 열었는데 도커 컴포즈 파일이 있다고 하자. 그때 사용했던 정확한 버전의 MySQL과 API 환경을 단 한 줄의 명령으로 다시 재현할 수 있다. 근데 도커를 사용하지 않았다면? 프로젝트 환경을 재현하는 것 또한 오랜 노력이 필요할지도 모른다.

 

게다가 지금 당장은 MySQL 하나만 띄우지만, 프로젝트가 커지면서 Redis 같은 캐시 서버나 Nginx 같은 웹 서버를 추가로 띄운다면? 다중 서비스 관리 측면에서 도커 컴포즈는 더 중요하게 작용한다.

 

솔직히 이런 거 다 제쳐두더라도, 현대 개발 및 운영 환경에서 도커는 사실상 필수 역량이다. 대부분의 기업이 애플리케이션 배포와 관리에 있어서 이미 컨테이너 기술을 사용하고 있으니 말이다. (Docker, Kubernetes 등)

 

따라서 도커를 사용하며 컨테이너의 개념을 익히고, 이미지 빌드와 컨테이너 간 통신을 익혀두면 나중에 실무에 가서도 적응하기 용이할 것이다. 물론, 도커 자체가 익히는데 상당한 노력을 필요로 하기 때문에 초기 학습 비용이 적은 편은 아니다. 하지만 그렇기 때문에 미리 공부해 보는 것도 나쁘지 않다는 생각이다.

---

자, 그러면 또 몇 가지 의문점이 생긴다.

 

• 도커에 대해 찾아보면 항상 '이미지'라는 말이 나오는데, 도대체 이미지란 무엇을 말하는 걸까?
• 도커 파일은 뭐고, 도커 컴포즈는 또 뭘까? 둘은 어떤 차이가 있을까?

 

이것들에 대해서는 다음 포스트에서 직접 도커 파일과 도커 컴포즈를 생성해 보며 이야기하도록 하겠다.