https://www.youtube.com/watch?v=kAkHfeVg4iI&t=489s 참고했다.
IDP구축시 사용자를 생각하여 구축하는것이 핵심이다.
고려사항
2. 사용자 중심의 서비스 디자인
IDP의 핵심은 사용자의 필요에 맞춘 서비스를 제공하는 것입니다. 예를 들어, AWS의 경우 사용자는 EC2 인스턴스의 크기와 운영 체제를 선택하지만, AWS는 인스턴스의 안정적인 운영을 책임집니다. 이는 각 사용자가 자신의 역할에 집중할 수 있게 하며, 전반적인 효율성을 높입니다.
3. 역할 분담과 책임의 중요성
IDP에서는 서비스 제공자와 사용자 간의 역할 분담이 중요합니다. 서비스 제공자는 시스템의 기술적 측면을 관리하는 반면, 사용자는 제공된 서비스를 효과적으로 활용해야 합니다. 이러한 분담은 명확한 책임 소재와 효율적인 작업 흐름을 보장합니다.
4. 보안과 테스트 전략
보안은 IDP에서 중요한 부분입니다. 서비스 제공자는 시스템의 보안을 유지하는 책임이 있으며, 사용자는 자신의 부분에 대한 보안을 담당합니다. 또한, 효과적인 테스트 전략은 시스템의 안정성을 보장하는 데 중요합니다.
5. 결론: IDP의 성공적인 구축을 위한 전략
IDP의 성공은 사용자 중심의 서비스 디자인과 명확한 역할 분담에 달려 있습니다. 기술적 전문성과 사용자 경험을 모두 고려한 접근 방식이 필요합니다.
1.
예를 들어, 아마존의 배송 옵션에서는 표준 배송이나 특급 배송을 선택하는 단순한 질문과 함께 추가적인 설정으로 배송 시간을 선택할 수 있습니다. 그러나 고객은 배송 방법(트럭, 비행기, 배 등)이나 구체적인 경로 등에 대해 걱정할 필요가 없습니다. 이는 서비스가 중요한 선택사항에 초점을 맞추고, 불필요한 세부사항은 숨김으로써 사용자 경험을 단순화한다는 것을 보여줍니다.
아마존과 고객 간의 계약은 고객이 배송 유형을 선택하고 주소를 확인하는 것에 기반합니다. 아마존은 약속된 목적지와 시간에 패키지를 배달할 책임이 있습니다. 고객은 배송 방법에 대해 걱정할 필요가 없으며, 아마존은 고객이 제공한 정보가 정확하다고 가정합니다. 이는 서비스가 사용자의 필요에 맞춰 구성되어야 함을 보여줍니다.
서비스 제공자가 전문가인 영역에서 추상화를 생성하여 다른 사람들이 쉽게 이용할 수 있도록 해야 한다고 설명합니다. 예를 들어, 어떤 사용자가 쿠버네티스에서 실행되는 애플리케이션의 인스턴스를 생성한다면, 해당 서비스의 역할은 사용자가 만든 추상화 인스턴스로부터 하위 수준의 리소스를 생성하는 것입니다. 이는 애플리케이션, 데이터베이스, 클러스터 등 다양한 서비스에 적용될 수 있습니다.
이 부분에서는 서비스 제공자가 사용자의 필요에 맞춰 설계된 서비스나 추상화를 통해 하위 수준의 리소스를 생성하고 관리하는 방법을 설명합니다. 이러한 방식으로 서비스를 구축하면 소프트웨어 개발 생명주기(SDLC)의 첫 번째 문제가 해결됩니다. 또한, 각자의 역할에 따라 단위 테스트를 수행하는 것이 쉬워집니다. 예를 들어, 서비스 제공자로서 제공하는 서비스가 올바르게 작동하는 것을 보장하는 것이 내 역할이 됩니다.
이 부분에서는 서비스 제공자가 자신이 제공하는 서비스가 예상대로 작동하는지 테스트하는 역할에 대해 설명합니다. 예를 들어 AWS의 경우, EC2 인스턴스 뒤의 하이퍼바이저가 예상대로 작동하는지 확인합니다. 그러나 EC2 인스턴스의 크기 선택 같은 사용자의 구체적인 요구사항은 그들의 책임이 아닙니다. 그들의 역할은 허용된 모든 인스턴스 유형이 생성되고 예상대로 작동하는 것을 보장하는 것입니다. 반면에, 사용자로서 내 역할은 내가 선택한 사양이 내 요구에 맞는지를 확인하는 것입니다.
단위 테스트와 그 결과를 정의하고 관찰하는 것이 추상화의 범위에 제한되기 때문에 쉽다고 설명합니다. 이러한 정보는 Backstage와 같은 UI에 전송되어야 하며, 서비스 제공자가 관리하는 부분은 이미 사용하는 도구들에 의해 커버되고 있습니다. 결과적으로, UI의 범위는 축소되며, 모든 것을 한 곳에서 관리하는 '하나의 창'으로 사용하는 것은 시간 낭비가 될 수 있습니다. 이미 각자가 익숙한 도구들을 사용하고 있기 때문입니다.
UI가 각 전문 분야에 맞춰진 특정 도구가 아니라, 전문 지식이 없는 사람들을 위한 단일 창으로 변모하고 있음을 설명합니다. 예를 들어, 데이터베이스 관리자에게는 특정 데이터베이스 서버를 관리하는 데 도움이 되는 도구들이 있습니다. 새로운 UI는 사용자들에게 그들이 직접적으로 관심을 가질 정보의 일부만을 제공함으로써 가시성을 제공합니다. 이는 아마존 배송 예시로 돌아가 보면, 고객이 배송에 대해 관심을 가지는 부분만을 보여주는 것과 유사합니다.
이 부분에서는 아마존 배송 추적을 예로 들어, 고객이 필요로 하는 정보를 제공하는 방식을 설명합니다. 고객은 패키지가 배송되었는지, 현재 위치가 어디인지만 확인할 수 있습니다. 이는 아마존이 가진 데이터의 일부에 불과합니다. 배송 업체는 패키지의 QR 코드, 운송 방법, 트럭 운전사 등 더 많은 정보를 볼 수 있습니다. 보안 분야에서는 전통적으로 보안 전문가가 애플리케이션 개발자에게 위협 요소를 해결하도록 위임하는 방식이 있었으나, 이는 종종 효과적이지 않았습니다.
많은 보안 문제는 운영 체제나 기본 이미지의 업그레이드, 운영 체제 라이브러리의 변경 등으로 해결될 수 있습니다. 그러나 개발자가 선택하지 않았거나 무작위로 선택한 요소를 수정하는 것은 비현실적입니다. 그러나 서비스를 제공하고 이를 애플리케이션 개발자들이 소비하는 방향으로 나아가면, 누가 어떤 보안 위협을 해결해야 하는지 명확한 구분이 생깁니다.
이 부분에서는 서비스 사용자가 서비스 제공자의 책임 하에 있는 취약점이 있는 데이터베이스 인스턴스를 생성했을 수 있는 상황을 설명합니다. 예를 들어, 이미 알려진 취약점이 있는 PostgreSQL 13 데이터베이스를 사용하는 경우, 데이터베이스 관리자는 그러한 선택을 방지하기 위한 정책을 설정했어야 하며, 대신 안전한 버전(예: PostgreSQL 14)을 사용하도록 권장했어야 합니다. 서비스 제공자는 사용자가 잘못된 선택을 하지 않도록 지원하는 정책을 마련해야 합니다.
이 부분에서는 서비스의 추상화에 포함되지 않는 정보를 최종 사용자에게 노출하는 것은 무의미하다고 설명합니다. 예를 들어, 사용자가 데이터베이스에 할당할 메모리 양을 지정할 수 있다면, 해당 메모리 정보는 최종 사용자에게 제공되는 관찰 가능성 도구의 그래프 중 하나로 제공되어야 합니다. 반면, 메모리 사양이 추상화의 일부가 아니라면, 서비스 자체에서 필요한 만큼의 메모리를 할당하는 것으로 간주하고, 이 정보를 최종 사용자의 관찰 가능성에 추가하는 것은 혼란을 증가시킬 수 있습니다.
이 부분에서는 내부 개발자 플랫폼(IDP)을 구축하는 것이 어렵다고 설명합니다. 단순히 기존 도구와 프로세스 위에 UI를 구축하는 것만으로는 충분하지 않으며, IDP는 핵심 역량을 벗어난 작업을 수행할 수 있도록 최종 사용자를 지원하는 서비스의 집합입니다. IDP는 단일 팀이 아닌, 여러 팀의 협력을 통해 구축되어야 하며, 이는 각 사용자의 필요에 부합하는 서비스를 제공하는 데 중점을 둡니다.
이 부분에서는 내부 개발자 플랫폼(IDP)을 효과적으로 구축하기 위한 전략에 대해 설명합니다. 데이터베이스, 인프라, 애플리케이션 아키텍처 등 특정 분야의 전문가들이 IDP를 구성하는 서비스를 구축합니다. 각 팀이 자동화를 통해 자급자족하고 독립적으로 작동하려면, 그들이 필요한 것을 정의하고 애플리케이션 및 기반 인프라의 상태를 관찰할 수 있어야 합니다. 단순한 자동화만으로는 이러한 목표를 달성할 수 없습니다.