내부 개발자 플랫폼(IDP)은 개발자가 모든 기본 인프라를 직접 관리할 필요 없이 소프트웨어를 더 쉽게 구축, 배포 및 운영할 수 있도록 조직에서 구축하는 중앙 집중식 내부 도구, 서비스 및 워크플로 세트입니다.
각 개발팀이 서버, 네트워크, 보안 프로토콜, 소프트웨어 배포를 각자 직접 설정하는 대신, 이미 회사의 규칙과 모범 사례를 따르는 '골든 패스'를 사용할 수 있습니다. 개발자들은 단순히 경로를 따르기만 하고(예: '새로운 마이크로서비스 구축'이나 '미리보기 환경 프로비저닝'), 나머지는 백그라운드 자동화를 통해 플랫폼이 처리합니다.
IDP는 조직 내 모든 개발 팀이 거의 동일한 규칙을 따르도록 서로 다른 프로세스를 통합하는 방법입니다. 또한 이 시스템은 기본적인 인프라 관련 결정을 처리하므로, 개발자는 코드를 배포하기 위해 인프라에 대한 깊은 전문 지식이 필요하지 않습니다.
IDP는 일반적으로 전담 DevOps, 운영 또는 플랫폼 엔지니어링 팀에서 설계하고 유지 관리하지만 주 사용자는 애플리케이션 개발자입니다. 이 플랫폼은 컨테이너 오케스트레이션, 코드형 인프라(IaC), 지속적 통합/지속적 전달(CI/CD), 관측 가능성 도구와 같은 다양한 툴체인과 기술을 하나의 일관된 에코시스템으로 결합합니다.
Think 뉴스레터를 통해 AI, 자동화, 데이터 등 가장 중요하고 흥미로운 업계 동향에 대한 최신 소식을 받아보세요. IBM 개인정보 보호정책을 참조하세요.
IDP는 조직의 파편화된 소프트웨어 엔지니어링, 제공 및 개발 역량에 질서와 일관성을 제공합니다. 이를 통해 조직은 소프트웨어 개발 환경과 관행의 복잡성을 관리하여 이를 단순화하고 간소화함으로써 많은 이점을 얻을 수 있습니다.
의미 있는 코딩 작업에 집중할 수 있는 조건인 '흐름 상태'에 진입하고 이를 유지하는 엔지니어의 능력은 소프트웨어 분야에서 혁신을 이루고자 하는 조직에 엄청난 가치가 있습니다. 이 상태에서는 주의가 분산되지 않고 진행 상황이 연속적으로 느껴집니다. 엔지니어는 방해받지 않고 시간을 할애할 수 있으므로 더 복잡한 문제를 분석할 수 있습니다.
그러나 흐름 상태는 취약합니다. 때때로 개발자는 한 종류의 문제에서 다른 종류의 문제로 컨텍스트를 전환해야 하는데, 이러한 정신적 전환은 첫 번째 문제의 진도를 방해하여 결국 첫 번째 문제로 돌아갔을 때 다시 0에서 시작해야 할 수도 있습니다. 예를 들어, 버그 보고서에서 발견된 문제인 호텔 예약 유틸리티가 사용자의 시간대에 맞춰 시간과 날짜를 표시하지 않는 이유를 해결하려는 프로그래머를 상상해 보세요. 이는 JavaScript가 근본적인 수준에서 시간을 처리하는 방식과 관련된 까다로운 문제이며, 단순한 서식 문제가 아닙니다. 프로그래머는 타임스탬프가 백엔드와 프론트엔드를 거쳐 UI로 어떻게 이동하는지 추적하고, 로컬 브라우저 설정과 다양한 조건에서 날짜 개체가 작동하는 방식에 대해 고민합니다. 이는 머릿속에 담아두기에는 많은 정보이지만, 프로그래머는 돌파구에 점점 더 가까워집니다.
이제 프로그래머는 편집기를 종료하고 CI/CD 도구를 열고, 서비스에 맞는 파이프라인을 찾고, 이 특정 프로젝트의 배포 방식을 기억해내고, 설정을 수정하고, 파이프라인 실행을 기다리고, 별도의 모니터링 도구를 열어 동작을 확인해야 합니다…
이 과정에서 프로그래머는 문제 추론에서 벗어나 인프라, 도구 및 프로세스를 탐색하는 다른 모드로 전환해야 했습니다. 이후 프로그래머가 버그로 돌아갔을 때, 문제에 대해 쌓은 섬세한 이해는 이미 증발해 버린 상태입니다. 이제 처음부터 다시 시작해야 합니다. 이는 조직에게는 시간 낭비이고, 엔지니어에게는 좌절감을 줍니다. IDP는 3차적인 문제를 처리하여 이러한 낭비를 줄임으로써 출시 시간을 단축하고 개발자의 생산성을 높이며 개발자 경험을 개선합니다.
조직이 성장함에 따라 개발 환경은 점점 더 복잡해지고 있습니다. 어떤 팀은 특정 도구를 채택할 수 있고, 다른 팀은 유사한 작업을 수행하기 위해 다른 경쟁 도구를 선택할 수 있습니다. 팀은 서로 다른 워크플로를 개발하고 인프라, 배포 또는 보안에 대한 결정을 내릴 수 있으며, 이는 사용 사례에는 개별적으로 도움이 되지만 전체적으로는 충돌이나 비효율성을 유발할 수 있습니다. 일관되지 않는 환경에서는 병목 현상이 많습니다. 이러한 불일치는 시간이 지남에 따라 누적되어 시스템을 확장하기가 더 어려워집니다. 반면, IDP는 파편화되고 일관성이 없는 일련의 관행을 응집력 있고 반복 가능한 개발자 워크플로 및 소프트웨어 제공 프로세스로 전환합니다.
명명 규칙, 보안 관행, CI/CD 파이프라인 등의 고려 사항을 IDP는 템플릿을 제공하고 재사용 가능한 스캐폴딩을 통해 일관된 워크플로를 구축하여 변동성을 줄입니다. 이렇게 하면 개발자가 처음부터 시작할 필요 없이 리포지토리를 자동으로 프로비저닝하고 빌드 및 배포 파이프라인을 구성하며 모니터링과 보안을 통합하는 템플릿을 선택할 수 있습니다.
IDP는 보안 및 규정 준수 기능을 워크플로에 직접 임베드합니다. 예를 들어, 모든 서비스에 적절한 인증 메커니즘이 포함되어 있고 승인된 네트워크 구성을 준수하도록 할 수 있습니다. 이렇게 하면 개발자는 특정 접근 방식이 요구 사항을 충족할지 여부를 고민하는 데 시간을 낭비할 필요가 없습니다. 적절한 프로토콜이 준수되는 이유는 제어 기능이 일관되게 적용되기 때문이며, 이러한 제어 기능은 플랫폼 자체에 내장되어 있습니다.
모든 팀이 동일한 패턴을 따르면 개발자가 익숙하지 않은 코드베이스를 이해하고 기여하기가 더 쉬워집니다. 공유 규칙을 사용하면 프로젝트 간에 전환하는 데 필요한 인지 부하가 줄어들고 신규 개발자가 더 빨리 온보딩할 수 있습니다.
일관된 프레임워크가 없으면 조직의 성장은 혼란을 초래할 수 있으며, 각각의 새로운 서비스는 더 많은 다양성과 복잡성을 초래할 수 있습니다. IDP는 확장을 지원하고 리소스 할당을 최적화하는 데 도움이 되는 안정적인 엔터프라이즈급 기반을 제공합니다. 모범 사례는 시스템 전체에 자동으로 전파될 수 있으며, 소규모 플랫폼 엔지니어링 팀이라도 대규모 조직의 개발 관행에 영향을 미칠 수 있습니다.
IDP는 단순한 도구가 아니라 특정 개발자 요구 사항을 해결하고 보다 원활한 개발자 경험을 만들기 위해 함께 작동하는 기능 시스템입니다. 구현 방식은 다양하지만, 가장 일반적인 구성 요소는 다음과 같습니다.
개발자 포털: 내부 개발자 포털이라고도 하며, 개발자가 상호작용하는 기본 인터페이스입니다. 주로 Backstage와 같은 오픈 소스 도구로 구축되며 중앙 대시보드, 서비스 카탈로그, 문서, 템플릿, 플러그인 및 워크플로를 제공합니다. 개발자 포털은 플랫폼의 개발자 셀프 서비스 제어판입니다.
서비스 카탈로그: 서비스 카탈로그는 모든 서비스, 시스템 및 리소스의 구조화된 인벤토리입니다. 소유권, 의존성을 정의하고 여타 메타데이터를 제공하여 누가 무엇을 소유하는지, 서비스가 어떻게 상호작용하는지와 같은 정보를 모두가 알 수 있게 합니다.
스캐폴딩 및 템플릿: 사용자가 GitHub 리포지토리를 신속하게 생성하고, CI/CD 파이프라인을 설정하고, 표준 구성을 적용하고, 로깅 및 모니터링을 통합하는 등의 작업을 수행할 수 있도록 미리 정의된 새로운 서비스 생성용 청사진입니다. 파이프라인은 모범 사례가 반영되어 사전 구성되고 재사용할 수 있으므로 개발자가 처음부터 설계할 필요가 없습니다.
인프라 프로비저닝: 이 계층은 다양한 클라우드 제공업체의 하이브리드 또는 멀티 클라우드 아키텍처에서 환경, 자원, 애플리케이션 워크로드의 생성 및 관리를 처리하며, 종종 GitOps 원칙을 활용해 자동화를 수행합니다.
환경 관리: 많은 조직에서 개발, 스테이징 및 프로덕션 환경은 구성 차이, 불일치하는 종속성 및 일관성 없는 데이터로 인해 시간이 지날수록 서로 분리됩니다. IDP는 환경 균형을 장려하고 모호함을 제거하며 환경을 더 예측 가능하게 만듭니다.
관측 가능성: 시스템 동작에 대한 가시성이 기본적으로 내장되어 있어 로그, 지표 및 추적을 포함한 실시간 인사이트를 제공합니다.
비밀 및 구성 관리 : API 키, 자격 증명 및 환경 변수가 안전하게 처리되어 비밀이 하드코딩되지 않고 액세스가 제어 및 감사 가능하게 됩니다.
거버넌스: 보안 및 준수 정책이 자동으로 시행되며, 스코어카드나 역할 기반 접근 제어(RBAC)와 같은 거버넌스 통제는 누가 배포할 수 있는지, 누가 무엇을 접근할 수 있는지, 그리고 워크플로를 어떻게 승인할지 정의합니다.
문서: 흩어져 있는 문서가 아니라 서비스와 함께 존재하며 포털을 통해 검색할 수 있습니다.
에이전틱 코딩 어시스턴트는 프로덕션 등급의 IDP를 자체적으로 조립하지는 않지만 여러 단계에 걸쳐 적극적으로 계획, 생성 및 반복을 수행하여 플랫폼 부트스트래핑부터 최적의 경로 생성 및 도구 통합에 이르기까지 전체 프로세스를 가속화할 수 있습니다. 아키텍처는 기술만큼이나 조직과 팀 구조가 중요하기 때문에 여전히 사람의 판단이 필요합니다.
에이전틱 코딩 어시스턴트가 구축되면 IDP 내에서 작동하여 정적 포털에서 보다 동적인 작업 중심 환경으로 전환할 수 있습니다. 예를 들어, IBM Bob은 플랫폼 구성 요소와 통합되어 다음과 같은 작업을 지원할 수 있습니다.
에이전트 코딩 어시스턴트는 단순한 챗봇을 뛰어넘어 이 플랫폼의 지능적 인터페이스 역할을 합니다. 개발자는 양식과 워크플로를 수동으로 탐색하는 대신 "새 서비스 생성"과 같은 작업을 요청할 수 있으며, 어시스턴트는 표준, 보호 장치 및 최적의 경로 준수에 필요한 단계를 조율하는 데 도움을 줄 수 있습니다. 잘 정의된 환경에서는 서비스 카탈로그 메타데이터와 컨텍스트를 사용하여 작업을 안내하는 동시에 필요한 경우 사람의 검토를 포함할 수 있습니다.
Watsonx.ai는 애플리케이션 개발 팀이 워크플로에 AI를 원활하게 통합할 수 있도록 지원합니다. 이 포괄적인 툴킷은 모델 생성에서 배포에 이르기까지 전체 AI 라이프사이클를 지원합니다.
x86 하드웨어에서 메인프레임 애플리케이션 개발, 테스트, 데모, 교육을 위한 플랫폼을 사용합니다.
앱을 신속하게 설계하고 프로토타입을 제작하여 시장에 쉽게 출시할 수 있는 IBM의 모바일 앱 개발 플랫폼에 대해 알아보세요.