[1화] 파이썬 배포 자동화: 전체 프로세스(내부/외부 형상 기반)

[1화] 파이썬 배포 자동화: 전체 프로세스 (내부/외부 형상 기반)

[1화] 파이썬 배포 자동화: 전체 프로세스 (내부/외부 형상 기반)

 

오랜만에 인사드립니다. 이번 포스팅에서는 파이썬 스크립트로 배포 자동화 환경을 구축한 과정과 시행착오를 공유드리려 합니다. 최근 동료와 배포 자동화에 대해 많은 이야기를 나누었습니다. 협업을 하다 보면 배포에 많은 시간과 공수가 들고, 반복 작업도 많습니다. 업무 효율성을 높이기 위해서 자동화에 대한 요구가 많았습니다. 그래서 이번 기회에 자동화를 한 번 실제로 적용해보기로 의견을 모았습니다.

 

 내부에서 관리하는 형상에서 배포에 필요한 파일만 골라 고객 형상에 반영해야 합니다. 그 과정에서 파일을 선별하고 반영하는 방법을 어떻게 표준화할지 고민하게 되었습니다. 앞으로 여러 편에 걸쳐 내용을 쉽게 풀어 소개해드릴 예정이며, 이번 1화에서는 전체 구성과 개요를 먼저 정리해보겠습니다.

 

 내부와 외부의 형상은 명확하게 분리하여 관리하고 있습니다. 내부 형상은 내부 개발자들이 작업하는 개발 환경에 해당합니다. 즉, 개발자들이 개발하고 검증한 코드 및 관련된 데이터들이 포함되어 있습니다. 외부 형상은 고객과 공유하는 데이터라고 보시면 됩니다. 즉, 내부 형상에서 공유가 필요한 파일들만 선별하여 고객사에 전달하게 됩니다. 아마도, 현업에서 소스 코드 배포를 하는 많은 개발자 분들께서는 이와 같은 형태로 내부/외부 형상을 분리하여 운영하고 있을 것입니다.

 

그림 1.  내부 ,  외부 고객 형상 관계

 

 

 위의 그림을 보면, 내부 고객(개발자)과 외부 고객(고객사) 간의 관계 및 형상 흐름이 나타나 있습니다. 내부에서는 CI/CD 환경을 통해 자동으로 배포가 이뤄지도록 시스템을 구축해 두었으나, 간혹 시스템 문제로 인해 수동 배포가 필요한 경우도 발생해 왔습니다. 이러한 경우 배포를 진행하는 인원은 수작업으로 배포를 진행했고, 그 횟수가 매우 잦아서 이제는 별도의 시스템이 필요한 상황이었습니다. 수동으로 배포하는 과정에서의 많은 이슈들이 있었습니다. 예를 들면, 고객사에 전달되면 안 되는 개발자 검증 환경 및 테스트 코드들이 고객사에 전달되는 경우도 있었습니다. 또한 특정 포함되어야 할 파일이 누락되는 경우도 있었습니다. 이 부분은, 결국 소프트웨어의 품질 문제로 인식될 수 있습니다. 그래서, 최악의 상황에서도 문제가 없게 배포할 수 있는 시스템을 만드는 것이 이번 시리즈의 핵심입니다.

 

배포 자동화 환경을 효과적으로 구축하기 위해서는 체계적인 절차가 중요하다고 생각합니다. 먼저, 배포를 진행하기 전부터 배포가 완료될 때까지의 전체 과정을 단계별로 정리해보았습니다. 각 단계는 다음과 같이 구성되어 있습니다.

1.       배포 대상 파일 선별

2.       내부 형상 최신화

3.       외부 형상 최신화

4.       배포 대상 파일 복사 및 배포

 

이처럼 단계별로 세분화된 절차를 통해 배포 자동화 환경을 구축할 예정입니다. 그리고 각 과정에 대해서는 상세하게 별도의 포스팅을 통해서 설명을 진행할 예정입니다.

 

1.     배포될 파일 선별

배포 자동화를 준비하면서 가장 먼저 떠올린 방법은 내부 형상에서 외부 형상으로 필요한 파일만 복사하는 방식이었습니다. 이를 위해서는 우선 복사 대상 파일을 어떻게 선별할 것인지 기준을 명확히 정하는 것이 중요합니다.

제가 고민한 기준은 다음과 같습니다.

 

l   특정 폴더 내에서 변경된 파일을 선별하는 방법

l   고객 형상에 포함된 파일 목록을 기준으로 선별하는 방법

 

두 가지 방법 모두 장단점이 있기 때문에 각각 구현해볼 예정이지만, 개인적으로는 두 번째 방법인 ‘고객 형상에 포함된 파일 목록’을 기준으로 선별하는 방식을 더 선호합니다. 이 방법을 사용하면 배포에 필요한 파일만 정확히 복사할 수 있어 불필요한 파일의 유출을 막을 수 있기 때문입니다.

그림 2.  외부 형상에서의 파일리스트 추출

 

또한, 복사 대상 파일 목록을 어떻게 관리할지도 중요한 고민거리였습니다. 설정 정보를 코드에 하드 코딩할지, 아니면 별도의 설정 파일(예: JSON 파일)로 관리할지에 대해서 고민을 하였습니다. 확장성과 유지보수의 편의성을 고려하여 JSON 파일 형태로 파일 목록과 경로 정보를 관리하기로 결정했습니다.

 

운영 환경에서는 항상 고객 형상에서 필요한 정보를 직접 읽어오는 것이 가능하지만, 이러한 방식은 특정 프로젝트에만 국한되어 적용될 수 있다는 한계가 있습니다. 따라서, 다양한 프로젝트나 배포 환경에서 범용적으로 활용할 수 있는 시스템을 구축하는 것이 더욱 중요하다고 판단했습니다. 이러한 이유로, 배포 자동화 환경을 설계할 때 외부 형상 정보를 최초 또는 필요에 따라 한 번만 가져오고, 그 이후에는 별도로 관리되는 JSON 파일을 기반으로 배포 작업을 진행하도록 방향을 잡았습니다. 이렇게 하면 각 프로젝트마다 배포 방식이 달라지더라도 공통적으로 활용할 수 있는 구조를 마련할 수 있으며, 유지보수와 확장성 면에서도 매우 큰 장점이 있습니다. 또한, JSON 파일에 파일 목록과 경로 정보가 체계적으로 정리되어 있으므로, 배포 과정에서 불필요한 파일이 포함되는 것을 예방할 수 있고, 배포가 필요한 파일만 정확하게 관리할 수 있습니다. 이처럼 내부 형상과 외부 형상 간의 정보 관리 방식을 통일함으로써, 배포 자동화 환경의 효율성과 안정성을 더욱 높일 수 있다고 생각합니다.

 

2. 내부 형상 최신화 / 3. 외부 형상 최신화

배포 자동화 환경을 구축하기 위해서는 무엇보다 먼저 내부와 외부 형상의 최신화가 반드시 선행되어야 합니다. 내부 형상 최신화란, 각 개발자들이 개별적으로 개발한 내용을 하나의 메인 브랜치에 병합(merge)된 상태 즉, 형상 상의 최신 상태로 유지되는 과정을 의미합니다. 이 과정이 제대로 진행되어야만 정상적인 배포가 가능합니다. 만약 최신화가 되지 않는다면 특정 개발 항목들이 누락되는 상황들이 발생합니다. 이후 진행되는 배포 작업에서 예기치 않은 충돌이나 누락 문제가 발생할 수 있습니다. 

 

그림 3.  내부 외부 형상 최신화

 

외부 형상 최신화는 고객사와 협업하는 과정에서 공유된 부분, 즉 고객사가 우리에게 전달하거나 우리가 고객사와 협의한 변경 사항을 반영하는 단계입니다. 이를 통해 외부 환경에서 이루어진 모든 변경 사항이 우리 시스템에도 동일하게 적용되어, 내부와 외부 모두가 동일한 기준에서 작업을 진행할 수 있게 됩니다.

 

이러한 형상 최신화 작업은 흔히 사용하는 Git을 예로 들면, 'pull' 명령어를 통해 최신 소스 코드를 받아오고, HEAD 포인터를 가장 최근 병합된 커밋에 맞추는 것과 동일합니다. 이처럼 내부와 외부의 형상을 항상 최신 상태로 유지하는 것은 매우 중요합니다. 최신화가 제대로 이루어지지 않으면, 이후 단계에서 불필요한 오류가 발생할 수 있으며, 배포 자동화의 신뢰성 또한 크게 저하될 수 있습니다.

 

따라서 내부와 외부 형상의 최신화는 배포 자동화에서 반드시 진행되어야 할 필수 단계라고 할 수 있습니다. 이러한 과정이 성공적으로 마무리된 후, 비로소 다음 단계의 작업으로 안전하게 넘어갈 수 있습니다.

 

4.     배포 대상 파일 복사 및 배포

앞서 내부와 외부 형상의 최신화 단계를 성공적으로 마친 이후에는, 최신 상태로 관리된 내부 형상의 변경 사항을 외부 형상에 적용하는 작업이 이어집니다. 이 단계에서는 이전에 JSON 파일로 체계적으로 추출한 파일 리스트를 활용하여, 복사해야 할 파일들을 정확하게 선별합니다. 이렇게 선정된 파일들은 외부 형상과 관련된 특정 폴더로 복사되며, 이미 동일한 이름의 파일이 존재할 경우에는 덮어쓰기를 통해 최신 버전으로 교체하게 됩니다.

 

파일 복사가 완료되면, 복사된 모든 파일을 전체 Stage에 올린 후, Commit 단계를 진행합니다. 이러한 과정은 배포 자동화의 핵심으로, 불필요한 파일의 혼입을 방지하고 필요한 파일만을 신속하게 반영할 수 있도록 합니다.

그림 4. 배포 대상 파일 복사

 

여기서 한 가지 주목할 점은, 외부 형상에 변경 사항을 반영하는 방식에 따라 작업 흐름에 차이가 있을 수 있다는 점입니다. 첫 번째 방식은 외부 형상에서 새로운 브랜치를 별도로 생성한 후, 해당 브랜치에 변경 사항을 Commit하고, 모든 검토가 끝나면 최종적으로 Master 또는 Main 브랜치로 Merge하는 절차입니다. 이 방법은 여러 개발자나 협업자가 동시에 작업할 때 충돌을 최소화하면서 안정적으로 변경 사항을 관리할 수 있다는 장점이 있습니다.

 

다른 방식으로는, 별도의 브랜치 생성 없이 바로 Master 또는 Main 브랜치에 Commit을 진행하는 방법이 있습니다. 이 경우에는 변경 사항이 즉각적으로 반영되어 빠른 배포가 가능하지만, 협업이나 코드 검토 절차가 필요한 경우에는 신중하게 선택해야 합니다. 프로젝트의 규모나 팀의 협업 환경에 따라 적합한 방식을 선택하는 것이 중요합니다.

 

이처럼 내부에서 최신화된 내용을 외부 형상에 안전하게 반영하는 과정은, 배포 자동화의 신뢰성과 효율성을 높여주는 중추적인 역할을 하며, 각 단계별로 체계적인 절차와 관리가 중요합니다.

 

이번 포스팅에서는 전체 프로세스의 개요만 정리했습니다. 다음 글에서는 각 단계별 파이썬 코드 구조와 아키텍처를 자세히 다뤄보겠습니다.