안녕하세요, KT DevOps엔지니어링팀입니다.  지난 4월 25일에 KT 개발자 워크숍 “Have a Git Day - 코드로 세상을 바꾸는 날”을 개최했습니다. 행사에서 “GitHub Enterprise 정착기-시행착오를 넘어 Copilot과 함께 비상”이란 주제로 최지현님이 발표했던 내용을 바탕으로, KT의 GitHub Enterprise Cloud 도입기를 소개해드리려고 합니다.

KT Before GitHub 

AICT 컴퍼니 전환 속에서의 CI/CD 체계에 대한 고민

  

  최근 KT는 AICT(AI + ICT) 컴퍼니로의 전환을 선언하며, 다양한 기술 분야의 전문가들을 적극 채용하고 있습니다. 변화하는 조직 구조 속에서, 저희는 다음과 같은 과제를 마주하게 되었습니다. 

• 다양한 개발 언어와 프레임워크를 수용할 수 있는 확장성
• 대규모 협업을 가능하게 하는 개방성
• 신규 인력의 빠른 온보딩 환경
• 국내 규제와 보안 요건을 만족하는 인프라 안정성

  또한, 마이크로소프트와의 협업 확대 및 Azure 기반의 AI 서비스 도입 추진은, 새로운 클라우드 개발/배포 체계에 대한 고민을 하게 되었습니다. 

기존 환경의 한계

  

  기존에는 설치형 GitLab 커뮤니티 에디션과 Jenkins 기반 CI/CD 시스템을 운영하며 IDC에 배포하고 있었으며, 아래와 같은 제약이 있었습니다.

• 버전 관리 부담: 오픈소스 기반 도구들의 보안 패치 및 기능 업그레이드에 과도한 리소스 소모
• 분산된 품질/보안 도구: CI, SAST, 테스트 도구가 분리되어 통합적 관리가 어려움
• 설치형 도구의 인프라 부담: 스토리지 관리, 장애 복구 등 운영 리스크 존재

SaaS 기반 DevOps 도구 검토

    

  결과적으로 KT의 개발 환경과 조직 구조에 더 적합하다고 판단되어, GitHub Enterprise Cloud 도입을 결정하게 되었습니다.

도입 타임라인

  

  Though GitHub 이야기를 시작하기에 앞서 GitHub 도입기의 타임라인을 공유드립니다.

• 작년 7월 경 처음 도입 논의를 시작하면서 약 한 달 동안 기능/연동을 검증하여 8월에 도입을 결정하였습니다.
• 사내에 적합한 프로젝트 0건을 선정하여 PoC를 함께 진행했습니다.
• 9월부터 실제 Migration을 시작했고, 12월까지 전체 00개의 프로젝트가 상용 배포를 완료했습니다.
• 이 경험을 기반으로 1월 부터 2차 Migration을 진행하고 있습니다.
  
  

  25년 4월 현재 기준 약 000명의 사용자가 사용을 하고 있으며, 000개의 프로젝트가 Migration을 완료하거나 진행 중입니다. 

KT Through GitHub

도입 시 마주한 도전과 극복의 이야기

  앞서 KT가 왜 GitHub Enterprise Cloud를 선택하게 되었는지 배경을 설명드렸습니다. 이번에는 실제 도입 이후 마주한 여러 이슈들과 이를 어떻게 극복해 나갔는지에 대한 이야기를 공유드리고자 합니다. 일부 이슈는 해결이 완료되었으며, 여전히 개선을 이어가고 있는 부분도 있습니다. 

  GitHub Enterprise Cloud에는 EMU(Enterprise Managed User)라는 개념이 존재합니다. 이는 단순히 사용자의 이메일을 기준으로 계정을 관리하는 방식에서 벗어나, Microsoft의 ID 플랫폼인 Entra ID를 기반으로 사용자 계정을 프로비저닝하는 구조입니다. KT는 이 EMU 방식을 선택함으로써 GitHub과 Azure의 통합된 계정 관리 환경을 구축할 수 있었습니다.  

  도입 이전에는 저희 팀이 자체적으로 오픈소스 인증 플랫폼인 Keycloak을 활용하고, 이를 사내 LDAP과 연동하여 사용자 인증 체계를 직접 운영하고 있었습니다. 이러한 구조는 관리의 유연성은 있었지만, 보안과 컴플라이언스 측면에서 통합된 거버넌스를 갖추기 어려운 한계가 있었습니다. Entra ID 기반 EMU 체계로 전환하면서 보안 조직, 인프라 조직과의 협업이 필수적으로 따라왔고, 이는 GitHub 도입이 단순한 도구 변경을 넘어 조직 차원의 변화임을 실감하게 해준 첫 단추였습니다.

 

이메일 정규화 이슈 – 예상치 못한 사용자 충돌

  EMU 구성 과정에서 발생한 대표적인 이슈 중 하나는 이메일 정규화 정책과 관련된 문제였습니다. GitHub은 EMU 사용자 계정을 생성할 때 이메일 주소를 기준으로 정규화 과정을 거치는데, 이 과정에서 특수문자가 포함된 이메일 주소들이 동일한 ID로 처리되어 충돌하는 현상이 발생했습니다.  

  결과적으로 서로 다른 두 사용자가 각기 다른 이메일을 가지고 있음에도 불구하고 GitHub 상에서는 동일한 사용자로 인식되는 문제가 나타났습니다. 이 문제는 단순 설정으로 해결되지 않았고, GitHub 측과 Microsoft Entra 팀 양측과의 협업을 통해 장시간에 걸쳐 원인을 분석하고 대응 방안을 논의해야 했습니다. 현재는 임시 조치로 충돌이 발생하는 사용자의 이메일을 변경하는 방식으로 대응 중이며, 본 이슈는 아직 해결을 진행 중입니다.

 

접근 제어 – 대규모 SaaS 도구의 보안 수용

  GitHub Enterprise Cloud를 사내에 도입하는 데 있어 가장 큰 장벽 중 하나는 바로 도메인 접근 허용 문제였습니다. github.com이라는 방대한 범위의 도메인을 기업 내 네트워크에서 허용하는 것은 보안 및 내부 규정 측면에서 부담이 큰 결정이었습니다.  

  다행히 GitHub에서는 이와 같은 요구사항을 반영해 GitHub Restriction이라는 기능을 도입했습니다. 이 기능은 특정 네트워크에서 GitHub 접근 시, 개인 계정의 리포지토리 접근을 차단하고, Enterprise 계정 또는 오픈소스 리포지토리에만 접근을 허용하도록 제한하는 기능입니다. KT는 이를 활용해 개발자가 오픈소스를 참고해 개발하는 것은 가능하게 하되, 사내 프로젝트 외부 반출은 차단하는 보안 환경을 구성할 수 있었습니다.  

  또한, 외부 네트워크에서 GitHub Enterprise에 접근하는 경우를 고려하여, IP Allow List 기능도 함께 활용하고 있습니다. 이 기능은 특정 IP 혹은 대역에 대해서만 Enterprise 리포지토리 접근을 허용하는 방식이며, 현재는 사내망, VPN과 같이 인가된 네트워크만 GitHub에 접근 가능하도록 제한하고 있습니다. 두 기능의 병행 적용으로 사내 개발자들은 보안적으로 안정된 환경에서 GitHub을 사용할 수 있게 되었습니다.

과금 구조 – 라이선스와 사용량, 그리고 현실적인 통제

  GitHub Enterprise Cloud는 사용자 수 기반으로 과금되는 GHEC(GitHub Enterprise Cloud)라이선스 외에도, 보안 기능이 포함된 GHAS(GitHub Advanced Security)라이선스, 그리고 Actions, LFS, Packages와 같은 사용량 기반 과금 서비스들이 함께 운영됩니다.  초기에는 각 부서나 프로젝트 팀이 필요에 따라 자율적으로 사용량 기반 기능들을 활용할 수 있도록 운영하려 했습니다. 이를 위해 GitHub 측에서는 각 사용자 또는 조직, 리포지토리와 Azure 구독을 연동하여 사용량을 각 부서별 Azure 비용으로 전가할 수 있는 Cost Center 기능을 추천해주었습니다.  

  하지만 이 기능은 하나의 사용자나 리포지토리가 여러 구독과 연계될 수 있는 N:M 매핑 구조여서, 실제로 어떤 구독에서 과금이 이루어질지 예측하기 어렵다는 단점이 있었습니다. 이로 인해 통제나 예산 관리에 혼선을 초래할 수 있어, 현재는 기존 방식대로 DevOps팀에서 모든 과금과 사용량을 중앙에서 관리하는 체계를 유지하고 있습니다.

GHAS – 보안을 파이프라인에 자연스럽게 녹이다

  GitHub 도입의 결정적인 계기 중 하나는 바로 보안 내재화였습니다. 기존 CI/CD 환경에서는 SAST나 테스트 도구들이 별도로 존재하며, 개발자가 직접 도구를 호출하거나 사후적으로 적용하는 구조였습니다.  반면, GitHub Advanced Security(GHAS)는 GitHub Actions와 완전히 통합되어 있어, 하나의 파이프라인 안에서 다음 세 가지 주요 보안 기능을 제공하고 있습니다.

• Dependabot: 오픈소스 의존성 취약점 자동 점검
• Code Scanning: 코드 레벨의 취약점 정적 분석 (SAST)
• Secret Scanning: 하드코딩된 인증정보, 키, 토큰 탐지
  
  

  이 기능들이 하나의 빌드 플로우 안에서 자동으로 동작하게 되면서, 개발자들이 별도의 작업 없이 코드 품질과 보안을 함께 확보할 수 있는 환경이 자연스럽게 마련되었습니다. 특히 최근 국내외 보안 사고의 상당수가 개발자의 실수나 인지 부족에서 비롯된다는 점에서, GHAS의 도입은 KT의 소프트웨어 생태계 전반에 걸쳐 보안 수준을 한 단계 끌어올리는 계기가 되었습니다.

Actions Runner – KT 인프라에 맞는 CI 실행 환경 확보

  GitHub Actions의 핵심은 CI/CD 작업을 실제로 수행하는 Runner에 있습니다. 기본적으로 GitHub에서는 공용 퍼블릭 러너를 제공하지만, KT는 사내에 Azure 기반의 프라이빗 네트워크를 운영 중이므로, 퍼블릭 네트워크에 접속하는 구조를 그대로 사용할 수는 없었습니다.  이를 해결하기 위한 첫 번째 대안은 GitHub에서 제공하는 Azure Private Networking기능이었습니다. 이는 GitHub의 공용 러너가 사용자의 가상 네트워크(VNet)와 연결되어 마치 사내망에서 실행되는 것처럼 작동하도록 해주는 기능입니다. 다만, 이 기능은 Larger Runner라는 고사양 러너에서만 지원되며, 사용량 기반 과금 구조로 인해 초기 도입에 제약이 있었습니다. 현재는 빌드 시간 및 사용량 데이터를 기반으로 향후 확장 도입 여부를 검토 중입니다.

  두 번째 대안은 보다 현실적인 선택이었던 Self-hosted Runner입니다. 이는 KT가 직접 보유한 VM 혹은 서버에 러너를 설치해 운영하는 방식이며, 네트워크 상에서 GitHub을 주기적으로 Polling하여 작업을 수신합니다. 이 방식은 외부에서 내부망으로 접속하지 않기 때문에 보안적으로도 상대적으로 안전하며, 현재는 약 10대의 VM이 러너 역할을 수행하며 안정적으로 운영되고 있습니다. 이와 같이, GitHub Enterprise Cloud 도입 이후에도 여러 기술적, 정책적 과제가 있었지만, 저희팀은 이를 실무적으로 검토하고 협업하며 하나씩 해결해가고 있습니다. 이러한 경험은 단순히 DevOps 도구의 전환이 아니라, 보안, 인프라, 개발 문화까지 아우르는 진정한 변화의 여정이었습니다.

 

KT After GitHub

KT의 Azure환경 CI/CD체계

  KT는 Azure 클라우드를 기반으로 개발 인프라를 운영하고 있으며, GitHub Enterprise Cloud의 도입과 함께 새로운 CI/CD 체계를 구축했습니다. 전체 흐름은 다음과 같이 구성됩니다.

• GitHub Enterprise Cloud에서 소스코드를 관리하고,
• GitHub Actions를 통해 CI 작업을 수행하며,
• 생성된 아티팩트는 **Azure Container Registry(ACR)**나 파일 저장소로 배포됩니다.
• 이후, 각 서비스 특성에 따라 Jenkins 혹은 ArgoCD를 통해 VM 혹은 Kubernetes에 최종적으로 배포됩니다.

  이 구조는 소스 커밋부터 배포까지의 전 과정을 하나의 흐름으로 통합했으며, 특히 GitHub Actions와 GHAS(GitHub Advanced Security)의 결합으로 인해 보안 점검이 자연스럽게 포함된 CI 프로세스가 완성되었습니다.  GitHub, Runner 환경은 DevOps 팀에서 중앙 관리하며, 배포 도구는 각 프로젝트의 특성과 인프라 환경에 맞게 선택적으로 제공됩니다. 이로 인해 효율적이면서도 일관성 있는 DevOps 환경이 구현되었습니다.

개발자 온보딩 속도 향상

  GitHub 도입 이후 가장 즉각적으로 체감된 변화 중 하나는 신규 인력의 온보딩 속도였습니다.  최근 저희 부문에는 매주 새로운 구성원이 합류하고 있습니다. 과거에는 개발 환경을 셋업하거나 기존 도구 사용법을 익히는 데 다소 시간이 소요되었으나, GitHub 기반의 표준화된 개발환경 덕분에 신입 개발자들이 별다른 장벽 없이 업무에 빠르게 투입될 수 있게 되었습니다.  물론 사내망 기반 개발 환경 특성상 초기 가이드는 여전히 필요하지만, 기존 대비 온보딩 속도는 눈에 띄게 개선되었습니다.

 

사용자 관리 및 운영 편의성 개선

  GitHub Enterprise는 관리 측면에서도 많은 이점을 제공합니다. 대표적으로는Audit Log 및 Insights 기능이 있는데, 이를 통해 관리자는 다음과 같은 정보를 실시간으로 파악할 수 있습니다.

• 사용자별 접근 이력
• 레포지토리 사용량
• Actions 실행 현황
• 조직 및 리포지토리 단위 통계
  
  

  이러한 데이터는 기술 지원이나 정책 수립 시 매우 유용하며, 현재도 지속적으로 개선되고 있습니다. 특히 Action 실행 관련 메트릭은 사용량 추이와 프로젝트 활성도를 파악하는 데 유용하게 활용되고 있습니다.

Actions Marketplace를 통한 확장성과 표준화

  기존에는 새로운 언어나 프레임워크가 등장할 때마다 DevOps 엔지니어링팀이 각 프로젝트에 맞춰 CI 스크립트를 일일이 가이드해야 했습니다. 이는 전사 규모에서는 큰 부담이었으며, 표준화된 대응이 어렵다는 한계도 존재했습니다.  GitHub Actions 도입 이후, 프로젝트 팀은 Marketplace에 등록된 다양한 액션을 직접 선택하고 조합하여 자신의 워크플로우를 구성할 수 있게 되었습니다. 덕분에 전사적으로 자율성과 표준화라는 두 가지 가치가 공존할 수 있는 환경이 마련되었습니다.  또한, 잘 구성된 액션이나 워크플로우를 신규 구성원과 공유하는 문화가 생기면서, KT 내부의 개발 문화도 협업 중심으로 진화하고 있습니다.

GHAS 기반의 보안 내재화

  저희 팀은 보안 조직과의 협업을 통해 CI/CD 전반에 걸쳐 보안 점검을 내재화하였으며, 이 과정에서 핵심적인 역할을 한 기능이 바로 GitHub Advanced Security(GHAS)입니다. GHAS는 개발자가 코드를 커밋하고 빌드하는 과정에서 자동으로 보안 취약점을 탐지하고 경고해주는 기능으로, 기존의 사후 점검 체계를 사전 예방적 구조로 전환하는 데 크게 기여했습니다.  GHAS는 크게 세 가지 구성요소로 이루어져 있습니다:

• Dependabot: 오픈소스 라이브러리의 취약점 및 버전 이슈를 자동으로 감지 및 알림
• Code Scanning: 정적 분석 기반 SAST 도구로 코드 내 보안 취약점 탐지
• Secret Scanning: 커밋에 포함된 인증정보(토큰, 키 등) 노출 탐지
  
  

  이 기능들은 GitHub Actions와 유기적으로 통합되어, 별도의 추가 구성 없이 CI 파이프라인 내에서 자동으로 실행되며, 개발자들은 일상적인 개발 과정 속에서 자연스럽게 보안 검사를 수행할 수 있게 되었습니다.  도입 이후 실제 운영 수치를 통해 KT의 대응 현황을 살펴보면, 그 효과는 매우 뚜렷하게 나타납니다.

  이 수치는 과거에는 전혀 인지하지 못했을 소스코드 레벨의 실제 위협 요소들이 GHAS를 통해 명확히 드러나고, 실시간으로 조치되고 있음을 보여줍니다. 특히, 상용 서비스 배포 전 단계에서 모든 보안 취약점이 해결되어야만 배포가 가능하도록 정책을 수립하고 실행하고 있어, KT 내 소프트웨어 배포는 더욱 신뢰할 수 있는 방식으로 이뤄지고 있습니다. 

  과거에는 배포 직전에야 진행되던 보안 점검이, 이제는 코드 작성 → 커밋 → 빌드 → 배포의 모든 단계에 자연스럽게 내재화되면서, 업무 일정에 영향을 주지 않으면서도 보안 수준을 꾸준히 유지할 수 있게 되었습니다. GHAS 기반의 보안 체계를 통해, 개발과 보안의 균형을 실현하고 있으며, 개발자들이 안심하고 빠르게 코드를 배포할 수 있는 환경을 만드는 데 성공하고 있습니다.

KT Beyond GitHub

확장, 표준화, 그리고 플랫폼 엔지니어링으로의 도약

  GitHub Enterprise Cloud를 도입한 이후 KT의 개발 환경은 한층 체계화되고 안정적인 흐름을 갖추게 되었습니다. 하지만 이는 끝이 아니라 시작이었습니다. 저희는 개발 생산성과 보안 수준을 더욱 향상시키기 위한 다음 단계의 여정에 올라 있으며, 이를 "KT Beyond GitHub"라는 주제로 나누고자 합니다.

Actions Runner Controller 도입 및 오토스케일링를 활용한 확장 구성

  현재 KT는 000개 이상의 다양한 서비스를 운영하고 있으며, 이 중 다수는 Azure 클라우드 기반으로 재구성될 예정입니다. 이러한 서비스에 안정적이고 확장 가능한 CI/CD 체계를 제공하기 위해, 저희팀은 빌드 자원의 자동 확장(Auto Scaling)도입을 본격적으로 추진하고 있습니다.  그 첫 번째 단계로 도입 중인 것이 바로 Kubernetes 기반의 Actions Runner Controller(ARC)입니다. ARC는 GitHub Actions Runner를 K8s 클러스터 내에서 자동으로 생성/회수할 수 있는 컨트롤러로, 다음과 같은 장점을 제공합니다:

• 요청 기반의 동적 Runner 배치: 빌드 요청이 들어오면 자동으로 Runner가 생성되고, 사용 후에는 자원이 회수됨
• 정기 배포 피크 시간 대응: 많은 서비스가 특정 요일이나 시간대에 일괄 배포되는 구조인데, 이때도 안정적으로 자원을 공급 가능
• 퍼블릭 클라우드의 유연성 극대화: 과잉 자원 유지 없이도 수요에 맞춘 자원 할당
  
  

  이러한 ARC 기반 구조는 현재 순차적으로 기존 Runner 구성에서 이관 중이며, 신규 프로젝트는 초기부터 ARC를 활용해 안정적 빌드 환경을 제공받도록 설계하고 있습니다.

표준/보안이 고려된 GitHub Actions Workflow 템플릿 제공

  

  저희팀은 단순히 Runner 자원을 제공하는 것에서 나아가, 전사 개발조직에 보안과 품질을 고려한 표준 워크플로우(Workflow)를 제공하는 방향으로 확장을 고려하고 있습니다.그동안은 CI 스크립트 가이드를 문서 형태로 제공하고, 각 개발팀이 이를 참고해 자체적으로 스크립트를 작성하는 방식이었습니다. 하지만 이 과정에서 팀별 편차가 발생하면서 다음과 같은 문제가 확인되었습니다:

• 보안 설정이 누락되거나, 필수 액션이 생략되는 사례
• 워크플로우 수정 시 중앙에서 일괄 관리가 어려움
• 오류 발생 시 공통 트러블슈팅이 어려움

 
  이를 개선하기 위해 GitHub Actions Workflow를 템플릿 형태로 제공하는 체계로 전환하고 있습니다. 개발팀은 이 템플릿을 프로젝트에 Import하여 바로 활용할 수 있으며, 중앙에서는 템플릿을 일괄적으로 유지보수할 수 있어 다음과 같은 효과를 기대하고 있습니다:

• 보안 이슈에 대한 빠른 전사 대응
• 워크플로우의 일관성 확보 및 검증 가능성 향상
• 개발팀 운영 부담 감소 및 생산성 증대

  이는 단순한 운영 편의성을 넘어, 전사 DevSecOps 체계의 기반을 다지는 중요한 변화입니다.

KT향 Platform Engineering

  이러한 문제를 해결하고, KT에 최적화된 개발 플랫폼 경험을 제공하기 위해 DevOps 팀은 현재 GitHub을 포함한 다양한 개발 도구들을 통합하는 KT향 IDP(Internal Developer Platform)를 설계하고 있습니다.  KT형 IDP는 다음을 목표로 합니다:

• GitHub, Azure, Jenkins, ArgoCD 등 분산된 DevOps 도구들을 통합된 사용자 경험으로 제공
• 계정, 권한, 프로젝트 등록, 빌드/배포 연계 등 전주기 관리 자동화
• 조직 내 개발팀의 온보딩부터 운영까지의 기술 허들을 최소화

  이를 위해 국내외 다양한 플랫폼 엔지니어링 사례를 벤치마킹하고 있으며, KT에 적합한 아키텍처와 운영 방식을 정립해가고 있습니다. 궁극적으로는 ‘누구나 쉽게 개발하고 안전하게 배포할 수 있는 KT 개발 플랫폼’을 완성하는 것이 이 여정의 끝 목표입니다.  DevOps 엔지니어링팀이 주도적으로 이 IDP 구축을 이끌고 있으며, 내부적으로 성과가 가시화되는 시점에 다시 한 번 이를 주제로 한 워크숍을 개최할 계획도 가지고 있습니다.

마치며

  KT의 GitHub Enterprise Cloud 도입기는 단순한 도구 전환이 아닌, 개발 문화의 변화, 보안 내재화, 운영 효율화로 이어지는 여정이었습니다. 시행착오도 많았지만, 그 과정에서 얻은 교훈과 노하우를 앞으로 더 많은 구성원들과 공유하고자 합니다. 지속적인 개선과 확장을 통해, 개발자 경험(Developer Experience) 을 고려하는 조직으로 성장해나가겠습니다. 감사합니다.