Docker 컨테이너 데이터 유실 방지와 보안 강화 전략 (Bind Mount & Non-root)

1. 왜 지금 '인프라 리팩토링'인가?

IT 스타트업의 성장은 단순히 기능을 빨리 만드는 것에만 있지 않습니다. 서비스가 수십억 명의 사용자에게 확장 가능한가?라는 질문에 답하려면, 초기부터 단단한 인프라 설계가 필수적입니다. 오늘 저는 제 서비스의 초기 인프라를 점검하며, 단순한 구동을 넘어 '운영'과 '보안' 관점에서 필수적인 두 가지 패치를 진행했습니다.

---

2. DB 유실 방지: Bind Mount 도입과 영속성(Persistence) 전략

도커 컨테이너는 기본적으로 '휘발성'입니다. 컨테이너가 내려가면 그 안의 데이터도 함께 사라질 위험이 있죠. 이를 해결하기 위해 로컬 호스트의 특정 폴더와 DB 컨테이너를 연결하는 Bind Mount를 적용했습니다.

 

[Technial Note: 왜 Named Volume이 아닌가?] 물론 프로덕션 환경의 정석은 Docker가 관리하는 named volume입니다. 호스트 결합도가 낮고 권한 관리가 깔끔하기 때문이죠. 하지만 초기 스타트업 단계인 지금은 '빠른 개발 속도(DX)'가 최우선이기에, 데이터 파일의 물리적 접근과 관리(백업·초기화)가 직관적인 Bind Mount를 의도적으로 선택했습니다. (추후 배포 시점에는 Named Volume + S3 백업 전략으로 고도화할 예정입니다.)

• 해결 방법: docker-compose.yml에서 ./postgres_data 폴더를 마운트하여 데이터 가시성 확보
• 비즈니스 가치: 컨테이너가 삭제되더라도 고객 데이터는 로컬에 안전하게 보존됩니다. 이는 데이터 복구의 복잡도를 낮추어 운영 리스크를 최소화합니다.

 

---

3. 보안 강화: Non-root 유저 전환 (Least Privilege)

대부분의 도커 이미지는 기본적으로 root 권한으로 실행됩니다. 하지만 실제 서비스 환경에서 이는 해커에게 '마스터키'를 쥐여주는 것과 같습니다.

• 보안 패치: Dockerfile에 USER spring과 chown 명령어를 추가하여 실행 권한을 최소화했습니다.
• 퍼스트 프린시플: "침입을 100% 막을 수 없다면, 침입 후의 피해 범위를 0으로 만든다"는 원칙을 적용했습니다.
• 기술적 배경 (Why?): 도커 컨테이너는 호스트의 리눅스 커널을 공유합니다. 만약 컨테이너 내부에서 Root 권한을 탈취당하면, 이는 곧 호스트 서버 전체가 뚫릴 수 있는 '컨테이너 탈출(Container Breakout)'의 위협으로 이어집니다. 이를 막기 위해 어플리케이션 계정을 별도로 격리했습니다.

---

4. 개발자가 '인프라'에 집착해야 하는 이유 (비즈니스 임팩트)

이러한 디테일은 단순한 자기만족이 아닙니다. 코드가 서비스로 전환되는 과정에서 발생하는 '기술 부채'를 선제적으로 갚는 행위입니다.

• 리스크 비용의 최소화: 보안 사고나 데이터 유실은 스타트업에게 치명적입니다. 단 몇 줄의 설정(User node, Bind Mount)으로 수억 원의 잠재적 복구 비용과 브랜드 신뢰도 하락을 막는 것이야말로 가장 효율적인 투자입니다.
• 엔지니어링 문화의 척도: "돌아가기만 하면 된다"는 타협 대신 "안전하고 견고하게 만든다"는 원칙을 세웠습니다. 이는 향후 합류할 동료들에게 우리 팀이 지향하는 품질의 기준(Standard)을 보여주는 강력한 메시지가 될 것입니다.

---

5. 마치며: 지속 가능한 개발을 위하여

 결국 기술적 완성도는 '심리적 안정감'으로 이어집니다. 인프라가 불안하면 퇴근 후에도 슬랙 알림 소리에 가슴이 철렁하지만, 탄탄한 보안과 데이터 보존 전략은 개발자에게 '온전히 로그아웃할 수 있는 권리'를 줍니다.

 " '지속 가능한 삶이 혁신적인 코드를 만든다'는 믿음으로, 오늘 마련한 이 단단한 기반 위에서 내일은 더 과감한 기능을 구현해 보겠습니다."