*** 이 이미지들은 예시이다. 이미지가 담고있는 내용은 일반론적이거나(목차) 또는 원본 문서와 완전히 다르게 조정되었다.
*** 블록체인 관련 서비스를 위한 개발 환경을 구축하였기 때문에 그에 적합한 목차와 내용을 예로 사용하였다.
개발환경 및 운영 초기에는 온프레미스 환경에서 서비스를 운영할 예정이었다. 기존 모회사에서는 VMware ESXi를 라이센스 하여 사용하고 있었으나, 계약 만료로 인해 새로운 솔루션이 필요한 상황이었다. 개인적으로는 AWS를 활용하고 싶었으나 예산상의 제약이 있었다. 블록체인 노드 4대와 DB, Storage 등의 지속적인 확장이 필요한 환경에서, 스타트업이 클라우드 비용을 감당하기는 현실적으로 어려웠다. 다행히 과거 정부과제 수행 과정에서 확보한 고사양 유휴 장비들이 있어 이를 활용할 수 있었다.
초기에는 Docker와 Kubernetes를 기반으로 환경을 구성하려 했다. 그러나 팀 내에서 Docker 경험이 있는 인력이 나 외에는 없었고, 영업/기획 인원 중에는 완전히 격리된 환경을 요구하는 사람도 있었다. 이러한 상태에서 Docker를 도입할 경우, 모든 서버 관리 업무가 Docker 경험자에게 집중되는 문제가 예상되었다. 따라서 컨테이너 방식 대신 하이퍼바이저를 활용해 VM을 생성하고, 필요한 경우에만 개별 VM 위에 Docker를 구동하는 방식을 채택했다.
당시에는 이러한 접근이 기술적으로 뒤쳐진 선택이라고 생각했으나, 후에 합류한 블록체인 개발자들의 조언에서 그 가치를 재확인할 수 있었다. 현대 솔루션에는 Docker가 기본적으로 포함되는 경우가 많은데, 환경 자체가 Docker 컨테이너라면 docker-in-docker 구조가 되어 문제 발생 시 트러블슈팅이 복잡해질 수 있다는 점이었다. 이를 통해 주어진 조건에서 합리적인 결정을 내렸다는 확신을 갖게 되었다.
Proxmox는 데비안 기반의 VM 운영에 특화된 GUI 운영체제로 설명할 수 있다. VirtualBox나 VMware와 유사하지만, 이들이 별도의 OS 위에서 동작하는 것과 달리 Proxmox는 그 자체가 베어메탈 머신에 설치되는 OS이다. 개인 환경에서는 Proxmox를 활용한 가상 환경 구축이 비교적 간단하나, 기업 환경에서는 사내 네트워크 구성 파악과 관련 행정 절차 등 추가적인 복잡성이 존재했다.
가장 도전적이었던 부분은 GUI와 CLI 설정 간의 일관성을 유지하며 환경을 구성하는 것이었다. 신입 시절 서버 구축 경험이 있어 동료 웹 개발자들보다는 유리했으나, 네트워크 설정 외의 영역에서는 전문성이 부족했다. 따라서 Proxmox가 제공하는 GUI에 상당 부분 의존할 수밖에 없었다. GUI 기반 설정이라는 특성상, 의도한 구성과 실제 적용 사항의 일치 여부를 확인하는 과정에서 여러 시행착오가 있었다. 다행히 초기 설정 완료 후에는 GUI 덕분에 운영 관리가 용이했다.
운영 환경 역시 동일한 온프레미스 구성을 계획했으나, 기술적/비기술적 문제와 운영 중 발생할 수 있는 장애 대응의 어려움을 고려해 최종적으로는 상용 클라우드 환경에서 구축했다. 이후 개발 환경에 Jenkins와 Docker Registry를 추가로 구성했으나, 실제 활용도는 낮았고 나 역시 프론트엔드 개발로 업무가 전환되며 이 환경은 점차 방치되었다. 오픈소스 기반의 파일 서버 구축 요청도 있었으나, 일정과 우선순위 조정 과정에서 무산되었다.
파일 서버 구축 경험을 쌓지 못한 것은 아쉬움으로 남는다. 이 경험이 있었다면 개인 블로그 사이트 구축 시 Supabase 대신 자체 스토리지 솔루션을 적용해볼 수 있었을 것이다. 장기적으로 이 사이트를 운영한다면 데이터의 자체 관리 필요성을 느끼고 있지만, 이 접근법의 타당성은 계속해서 평가해볼 필요가 있다.
아래는 내가 개발환경을 구축하면서 작성한 문서를 가상으로 재구성한 것이다. 내가 수행했던 업무를 기준으로 구성했기에 목차는 실제 개발 문서와 유사하지만, 구성도의 정보는 완전히 가상의 데이터로 대체하고 보다 일반적인 구조로 재구성했다.
