복잡한 인프라 환경을 단 한 줄로 띄우다 (feat. Docker Compose)

1. 들어가며: 아키텍처가 발전할수록 커지는 '운영의 고통'

1편과 2편을 거치며 가상 자산 거래소 프로젝트는 꽤나 견고한 아키텍처를 갖추게 되었습니다. 데이터 정합성을 위한 Redis, 대용량 비동기 처리를 위한 Kafka, 그리고 메인 데이터베이스인 MySQL까지.

성능과 안정성은 눈부시게 향상되었지만, 개발을 진행할수록 제 로컬 PC의 환경은 점점 지옥으로 변해갔습니다.

2. 문제 상황: "아 맞다, 카프카 안 켰다"

프로젝트를 켜서 코드를 테스트하려면 매번 아래와 같은 막노동을 거쳐야 했습니다.

1. MySQL 서버 켜기
2. Redis 서버 켜기
3. Kafka를 띄우기 위해 Zookeeper 실행하기
4. Kafka 서버 실행하기
5. Spring Boot 애플리케이션 실행하기

만약 랩탑을 바꾸거나, 다른 팀원과 협업을 하거나, 클라우드(AWS)에 배포라도 하려고 하면 이 모든 프로그램을 버전까지 맞춰서 일일이 다시 설치해야 했습니다. 전형적인 "내 컴퓨터에선 되는데 거기선 왜 안 되지?" 상황에 직면할 위기였습니다.

3. 해결 방안 탐색: 컨테이너 기술, Docker의 도입

애플리케이션을 실행하기 위한 환경(OS, 라이브러리, 인프라 등) 자체를 통째로 포장해서 어디서든 똑같이 돌아가게 만들 방법이 필요했습니다.

무거운 OS를 통째로 가상화하는 가상 머신(VM) 대신, 호스트 OS의 커널을 공유하며 격리된 프로세스 단위로 가볍게 띄울 수 있는 Docker(도커) 컨테이너 기술을 도입하기로 결정했습니다.

하지만 Docker만으로는 부족했습니다. MySQL, Redis, Zookeeper, Kafka 컨테이너들을 각각 docker run 명령어로 띄우고, 서로 통신할 수 있도록 네트워크를 연결해 주는 과정 역시 번거롭기 때문입니다.

결론: 인프라 오케스트레이션의 시작, Docker Compose 이 복잡한 다중 컨테이너 환경을 하나의 파일로 정의하고, 단 한 번의 명령어로 관리할 수 있도록 해주는 Docker Compose를 최종 도입했습니다.

4. 적용 과정: docker-compose.yml 하나로 모든 것을 통제하다

프로젝트 최상단에 docker-compose.yml 파일을 작성하여 필요한 인프라 스펙을 명시했습니다.

 

핵심 포인트:

• 포트 포워딩(Port Forwarding): 로컬 PC의 포트와 컨테이너 내부 포트를 매핑하여 Spring Boot가 접근할 수 있도록 구성했습니다.
• 네트워크(Network): 동일한 Docker Network로 묶어 컨테이너끼리 서로의 이름(Service Name)으로 통신할 수 있도록 설정했습니다. (예: Kafka가 Zookeeper를 찾을 때 IP가 아닌 서비스 명으로 접근)
• 볼륨(Volume) 마운트: 컨테이너가 삭제되더라도 MySQL의 데이터나 Redis의 캐시가 날아가지 않도록 로컬 디렉토리와 마운트하여 영속성(Persistence)을 보장했습니다.

5. 결과 검증: 단 한 줄의 마법, docker-compose up -d

이제 더 이상 프로그램을 일일이 켜고 끌 필요가 없어졌습니다. 터미널을 열고 아래 명령어 한 줄만 입력하면 끝입니다.

Bash

 

$ docker-compose up -d

 

단 10초 만에 가상 자산 거래소를 위한 완벽한 인프라 환경이 뚝딱 만들어집니다. 종료할 때는 docker-compose down 한 줄이면 모든 인프라가 깔끔하게 정리됩니다.

이로써 인프라 환경 구축에 낭비되는 시간을 획기적으로 줄이고, 개발 자체에만 몰입할 수 있는 강력한 생산성을 얻게 되었습니다. 나중에 AWS EC2 등에 배포할 때도 이 파일 하나만 들고 가면 똑같은 환경이 구성되므로 확장성(Scalability)의 기반까지 다지게 되었습니다.

6. 3부작 시리즈를 마치며

가상 자산 거래소 프로젝트를 진행하며 데이터 정합성(Redis) ➡ 대용량 비동기 처리(Kafka) ➡ 인프라 일관성 유지(Docker) 라는 굵직한 아키텍처 진화를 직접 경험했습니다.

처음에는 단순히 "요즘 핫한 기술이니까 써봐야지"라는 마음으로 접근하기도 했지만, 직접 트래픽을 쏴보고 병목 현상을 마주하면서 **"왜 이 기술이 필요한가?"**에 대한 본질적인 답을 찾아가는 짜릿한 여정이었습니다.

앞으로도 끊임없이 "왜?"라는 질문을 던지며, 코드 한 줄과 인프라 한 요소에 명확한 근거를 가지는 백엔드 개발자로 성장해 나가겠습니다.