1. 서론
입사 후 마주한 회사의 내부 서비스 인프라 환경에서 표준화되지 않은 배포 방식은 유지보수를 어렵게 만들고 있었습니다. 히스토리는 관리되지 않았고, 어떤 수정사항이 호스트 서버에서 직접 발생되었는지 관리가 되지 못했습니다.
기존 문제는 크게 3가지 였습니다.
1. 표준화되지 않은 배포 방법: 쉘 스크립트로 베이스 이미지를 사용해 컨테이너를 띄우고 git pull로 코드를 가져옴
2. 방치된 환경: 더이상 유지보수가 안될 정도의 오래된 베이스 이미지 사용
3. 의존성 문제: 매우 오래되거나, 문제있는 플러그인을 사용하며 플러그인 버전이 관리되지 않음. 호스트 서버에 특정 디렉토리에 강하게 커플링을 시켜놔 옮기기도 어려움.
위와 같은 문제점 말고도 각각의 서비스 종류만큼의 각각의 문제점이 매우 많았습니다.
이러한 환경을 개선하기 위해서 저는 사내 서비스 약 70개를 Docker Image로 표준화하는 마이그레이션을 진행했습니다.
서비스마다 환경이 가지각색이라서 어떤 건 1시간만에 끝나고, 어떤 것은 하루종일 해도 안끝나는 작업이었습니다. 이 과정을 저는 단순한 컨테이너화 작업이 아니라, "업무 프로세스를 만들어 책임의 분리를 만들자." 라는 목표라고 생각했습니다.
일단 이것에 대해 말해보려면 기존 방식의 문제점에 대해서 말해야 하는데요.
2. 기존 방식의 문제점:
- 서비스 장애(핫픽스) 시 개발자가 호스트 서버에 직접 접속해 코드를 수정
- 이로 인해 배포 이력이 남지 않고, 히스토리 관리가 되지 않음.
3. 개선된 방식
- 이미지 기반 배포: 개발자는 로컬/개발 서버에서 문제를 해결하고 릴리즈 버전을 통해서 새로운 이미지를 기반을 만듭니다.
- 인프라 관리 중앙화: 모든 서비스 호스트 위치, 실행 방법, 브랜치, 버전 정보를 구글 시트를 통해 공유하고 시각화해 관리합니다.
- 인프라 역할 부여: 인프라 관리자는 개발자가 만든 이미지를 통해 배포합니다.
결과적으로 개발자는 개발을 인프라 관리자는 운영에만 집중할 수 있는 업무 환경을 만들었습니다. 이러한 개선을 통해서 인프라 자체의 문제가 아니라면, 관리자는 서비스 코드를 모르더라도 서비스를 재가동시킬 수 있게 되었습니다.
4. 오케스트레이션으로 왜 안 바꾸었을까..?
이미지화 작업을 하고, 자연스레 오케스트레이션을 도입할 수 있지 않을까? 라고 생각했지만, 저는 현실과 제약에 대해서 고민했습니다.
현실적으로 우리는 DevOps 엔지니어, 인프라 관리 인력이 전적으로 없는 상황입니다. 오케스트레이션 인프라는 위와 같은 서비스 배포에서 발생할 수 있는 문제를 해결해 줄 수 있겠지만 관리할 인력자체가 없으면 이것은 해결책이 아니라 또 기술부채로 남을 것 같았습니다.
5. 기술 도입의 기준에 대해 고민
저는 이번 기회에 조직이 감당하고 활용할 수 있는 기술인가? 를 고민하고 생각하는 시간이 많았던 것 같습니다. JD에 명시된 역할과 책임을 다하고, 무조건 최신! 좋아보이는! 기술을 도입하는 것이 아니라 현재의 인력, 리소스, 상황 내에서 가장 효율적이고 지속 가능한 방법을 찾아내는 것을 깨달았습니다.
결론적으로 우리팀은 컨테이너 오케스트레이션 도입이 아니라 문서화와 책임 분배, 자동화를 통해서 이 문제를 해결했습니다. 이러한 방식이 옳바르지 않은 방식이라고 생각할 수 있습니다. 하지만 우리 조직의 현 상황에 맞는 운영 효율을 개선하려 노력했다고 생각합니다. 완벽한 문제 해결 방법은 없습니다. 항상 TradeOff에 대해 고민해야 하며 현 상황에 맞는 최적의 솔루션을 만들어내는 것이 개발자의 역할이라고 생각합니다.
인턴 생활 동안 이 프로젝트를 진행하며 항상 느끼는 사실이인데요. AI의 대 시대가 도입하며 구현 능력이 중요한 것이 아니라 현재 상황을 큰그림에서 판단하고 목표를 향해 실행하는 능력은 아직까지는 AI가 대체할 수 없다고 생각합니다. 이러한 점을 중점으로 노력하면 언젠가는 빛을 바라지 않을까요? 오늘도 화이팅입니다.