플랫폼 엔지니어링의 패턴과 안티패턴

Source: Dev.to

위에 제공된 텍스트를 번역하려면 실제 번역할 내용이 필요합니다. 번역하고 싶은 전체 텍스트를 알려주시면 한국어로 번역해 드리겠습니다.

플랫폼 엔지니어링 개요

플랫폼 엔지니어링은 한동안 존재해 왔습니다. 최근에는 DevOps와의 관련성 덕분에 관심이 급격히 증가했습니다.

일부에게 플랫폼 엔지니어링은 일반적인 DevOps 토폴로지 문제를 해결합니다: 시간과 경험이 부족한 DevOps 팀에 IT 운영을 내재화하는 것. 이는 Anti‑Type F라고도 알려진 안티패턴입니다.

플랫폼 엔지니어링은 조직을 확장하고 개발자 과부하를 줄이는 데 도움이 될 수 있습니다.

우리의 플랫폼 엔지니어링 의사결정 흐름을 사용하여 이것이 귀하의 문제에 대한 올바른 솔루션인지 확인하십시오. 또한 초기 단계에서 핵심 측정항목을 설정하도록 안내하여 내부 개발자 플랫폼(IDP)의 가치를 추적할 수 있게 합니다.

안티‑패턴 및 긍정 패턴

우리는 아래에서 플랫폼 엔지니어링의 안티‑패턴과 긍정 패턴을 설명합니다. 제안 사항이 있으면 알려 주세요.

Team Topologies에 익숙하다면 흔히 발생하는 플랫폼 엔지니어링 안티‑패턴 중 하나를 사용할 가능성이 낮아집니다. 문제가 발생했을 때 동료에게 상황을 설명하는 데 이 라이브러리가 여전히 도움이 될 수 있습니다.

인지 과부하 감소

IDP는 복잡성을 줄이고 개발자의 인지 과부하를 없애야 합니다. 플랫폼 사용이 너무 어렵다면 중요한 목표에 실패한 것입니다. 플랫폼이 개발자에게 부담을 주는 몇 가지 경우는 다음과 같습니다:

• 개발자에게 익숙하지 않은 구성 파일 형식을 사용한다.
• API가 메서드와 매개변수에 일관된 규칙을 갖추지 못한다.
• 문서가 없다.
• 플랫폼이 개발자의 고통을 줄여주지 않는다.

구성 파일

플랫폼에 구성 파일이 포함된다면 형식에 유연성을 제공하십시오. 다음과 같이 동일한 데이터를 파싱하는 것이 쉬워야 합니다:

• JSON 파일 (웹 개발자)
• YAML 또는 XML 파일 (백엔드 팀)

이를 통해 개발자는 자신에게 익숙한 형식을 사용할 수 있고, 여러분에게 편리한 형식에 얽매이지 않게 됩니다.

API 및 CLI

API 또는 명령줄 인터페이스(CLI)를 만들 때는 다음 항목을 세심하고 일관되게 유지하십시오:

• 메서드 이름
• 매개변수 이름
• 매개변수 순서

이렇게 하면 인터페이스를 더 쉽게 사용할 수 있습니다.

문서

IDP 문서는 간결하고 명확해야 하며, 다음에 초점을 맞춥니다:

• 제공되는 내용
• 사용 방법

거버넌스, 위험 및 컴플라이언스(GRC)

개발자가 GRC 목표를 충족하지 못한다면, 이를 처리하는 플랫폼을 추가하는 것이 개발 팀에 더 큰 부담을 줄 수 있습니다. 먼저 기존 개발자 문제를 해결한 뒤, 외부 요구 사항을 개발자에게 부담을 주지 않도록 다루세요.

전반적인 성공 기준

• IDP는 개발자의 인지 과부하, 복잡성 및 번아웃을 현저히 감소시켜야 합니다.
• 모든 고통을 플랫폼 팀에게 전가해서는 안 됩니다.

올바른 플랫폼 구축

“만들면, 그들이 올 것이다.” – 필드 오브 드림스 (1989)

내부 개발자 플랫폼을 구축할 때도 같은 접근 방식을 취한다면 내부 시장 점유율을 확보하기 어려울 것입니다. 처음부터 개발자를 참여시키고 그들의 구체적인 문제를 해결하는 플랫폼을 만드세요.

정렬되지 않은 플랫폼의 흔한 증상

• 기술 부적합 – 예: 쿠버네티스 관리를 쉽게 만들었지만, 개발자들이 이미 서버리스 함수로 옮겨간 경우.
• 스킬 가정 – 예: 마이크로서비스용 간소화 템플릿을 만들었지만, 개발자들이 이미 마이크로서비스 전문가라서 솔루션을 가치 있게 여기지 않는 경우.
• 선택 강제 – 예: 최신 기술로 플랫폼을 설계했지만, 비즈니스는 안정적이고 검증된 솔루션을 선호하는 경우.

신념만으로 IDP를 설계할 수 없습니다. 여러 팀의 개발자와 대화하여 플랫폼이 제거할 수 있는 공통된 고통 포인트를 찾아보세요. 고립된 상태에서 플랫폼을 만들면 채택률이 낮아지는 것이 보장됩니다.

팀 역학 및 지식 전수

플랫폼 엔지니어링 팀을 만들 때, 플랫폼이 다룰 영역에 가장 경험이 많은 사람들을 추가하게 될 가능성이 높습니다. 이는 다음과 같은 문제를 일으킬 수 있습니다:

• 플랫폼 팀이 개발 팀보다 더 잘 안다고 생각한다.
• 개발 팀이 소프트웨어를 운영하는 데 필요한 지식을 잃는다.
• 개발 팀이 플랫폼으로 마이그레이션할 수 있는 인력을 잃는다.

모범 사례:

1. 후계자 계획 – 개발자들을 플랫폼 팀으로 이동시킬 경우, 강력한 후계자 계획을 수립하고 남은 개발자들이 셀프‑서비스를 할 수 있도록 협업에 중점을 두어 역량을 강화한다.
2. 인지 과부하 방지 – 계획 없이 숙련된 팀원을 제거하지 않는다; 이는 번아웃을 초래할 수 있다.
3. 작게 시작 – 소규모 플랫폼 팀으로 시작하여 다른 팀이 더 자주 릴리즈할 수 있도록 문제를 해결한다.
4. 협업을 위한 채용 – 플랫폼 팀원을 기술 지식뿐 아니라 커뮤니케이션 및 협업 능력을 기준으로 선택한다.

“마그파이” 플랫폼 안티패턴

반짝이는 물건에 끌리는 사람들을 흔히 마그파이(반짝이는 물건을 모으는 까마귀과 새)라고 부른다. 마그파이 플랫폼은 기존 시스템에서 개발자들이 겪는 실제 문제를 해결하기보다 최신 기술에 집중한다.

• 그린필드 프로젝트를 위한 플랫폼을 구축하는 것은 매력적이지만, 기존 운영 소프트웨어를 지원하는 것이 팀에 더 큰 영향을 미친다.
• 개발자들이 어려워하는 지점을 파악한 뒤, 새로운 소프트웨어를 위한 더 나은 플랫폼을 만든다.

개발 팀이 새로운 기술을 도입하면 모든 것에 도움이 필요해 보일 수 있다. 먼저 그들이 지식을 쌓도록 두면 실제 고통 포인트가 드러나고, 새로운 기술에 익숙해지면서 초기의 많은 어려움이 사라진다.

Proving Impact

플랫폼의 영향을 입증해야 하므로, 다른 사람들이 여러분의 측정을 진지하게 받아들이기 위해서는 안정적인 시작점이 필요합니다. 이해관계자는 기술 및 비즈니스 도메인에 팀이 익숙해졌기 때문이라고 생각하면 개선 사항을 무시할 수 있습니다.

Platforms must prove their i (text truncated in source)

이 가이드에 대한 편집이나 추가를 자유롭게 제안해 주세요.

기존 팀 및 기술 스택에 미치는 영향

팀마다 문제를 해결한 방식이 다를 때 기술을 병합할 수 있는 많은 기회가 생깁니다.
새로운 배포 도구나 모니터링 툴을 도입하면 여러 팀의 고통을 한 번에 해소할 수 있습니다. 플랫폼의 이점을 보여줄 수 있는 것이 중요합니다.

장기 투자

조직에 플랫폼을 도입하면, 지속적으로 사용 가능하도록 장기 투자가 필요합니다.

• 플랫폼 팀이 제품을 제공한 뒤 해체되면, 그 플랫폼은 드래그를 추가하는 앵커가 되어 의존하는 모든 사람에게 부담이 될 수 있습니다.
• IDP에 내재된 결정에 이르게 한 상황이 변하면, 팀들은 더 이상 유효하지 않은 오래된 선택에 갇히게 됩니다.
• 플랫폼 사용이 너무 어려워져서 팀들이 작업을 수행하기 위해 이탈해야 할 수도 있습니다.

핵심 요점: 플랫폼은 지속적인 개선이 필요합니다—새로운 골든 패스를 추가하고 오래된 패스를 단계적으로 폐지하여 비즈니스 가치를 지속적으로 제공해야 합니다.

투자와 야망 맞추기

You should limit the platform’s ambition to match the long‑term investment levels.

If your organization has a fragmented technology landscape, it can be tempting to solve too many problems with the IDP. Supporting all existing tools and technologies will:

• Stretch the platform too thin to be useful.
• Overload the platform team even more than the developers were.

Avoiding “Stretched” Platforms

A common cause of stretched platforms is measuring the platform team on internal market share.

• Adding more golden pathways can increase market share, but it defeats the goal of encouraging consolidation around good technology choices.
• MONK metrics can help balance market share with developer satisfaction and outcomes, preventing the platform from becoming over‑extended.

비용 관리 및 셀프 서비스

셀프 서비스 옵션을 제공할 때는 비용 추적 및 관리에 대한 강력한 스토리가 필요합니다.

• 모든 개발자가 프로덕션과 유사한 환경을 생성하면 비용이 급격히 증가할 수 있습니다.
• 비용 지출을 쉽게 하는 모든 버튼에는 자동 제한이 포함되어야 합니다(예: 단기간 테스트 환경, 동시 환경 수 제한).
• 이는 플랫폼 팀이 비용 거버넌스에 대해 재무와 협업할 수 있는 기회입니다.

올인원 DevOps 도구 함정

플랫폼 결정이 기술 지식과 멀리서 이루어질 때, 올인원 DevOps 플랫폼을 채택하고 싶은 유혹이 생깁니다.

• 이는 플랫폼 엔지니어링이나 DevOps와 맞지 않습니다.
• 하나의 범용 도구는 플랫폼의 역량과 지속적인 개선 능력을 제한합니다; 도구의 기능이 모든 문제에 대한 해결책을 제약합니다.

더 나은 접근법:

• 플랫폼을 특정 문제점을 해결하는 내부 제품으로 설계합니다.
• 필요에 따라 최고 수준의 도구를 선택하고 재사용 가능한 라이브러리(예: 통합 로깅 및 텔레메트리)를 만듭니다.
• 기억하세요: 골든 패스웨이는 도구가 아니라, 빌드, 배포, 모니터링을 위한 전문 도구 위에 구축되는, 선별되고 반복 가능한 수행 방식입니다.

엣지 케이스 처리

• 플랫폼 팀이 환경을 표준화하려고 해도, 엣지 케이스는 항상 존재합니다.
• 경직된 플랫폼은 팀이 탈퇴하고 대안을 찾도록 강요합니다.
• 팀과 소통하고 엣지 케이스를 청취하면 플랫폼 팀이 이를 대응하고 내부 시장 점유율을 유지할 수 있습니다.

균형:

• 통합 없이 모든 시나리오를 수용하면 플랫폼 팀은 복잡성과 인지 부하에 압도됩니다.
• 최고의 소프트웨어 제품은 명확한 초점을 가지고 모든 것을 시도하지 않습니다.

디자인 팁: 팀이 엣지 케이스를 지원에 반드시 포함시키지 않고 추가할 수 있게 하세요. 엣지 케이스가 사람들을 플랫폼에서 떠나게 하거나 플랫폼의 표면적을 늘려서는 안 됩니다.

시장‑점유율 보고

플랫폼 시장 점유율을 보고할 때는 세 가지 수치를 강조합니다:

1. 전체 시장 규모 – 모든 개발자.
2. 지원되는 시장 규모 – 골든 패스로 지원되는 기술 스택을 사용하는 개발자.
3. 시장 점유율 – 실제로 플랫폼을 사용하는 개발자.

시장‑점유율 차트

• 전체 내부 개발자 시장을 보여줍니다.
• 해당 시장 중 IDP를 사용할 수 있는 비율을 나타냅니다.
• 실제로 그렇게 선택한 인원을 보여줍니다.

차트를 사용하여 새로운 골든 패스웨이에 대한 결정 안내를 하고, 플랫폼이 목표 청중에게 얼마나 매력적인지 추적합니다.

팀 설계 및 상호작용 모드

팀을 만드는 것은 쉽지만, 그들을 성공하게 만드는 상호작용을 구축하는 것은 훨씬 더 많은 작업입니다.

• Team Topologies는 팀과 상호작용 모드의 조합을 사용해 이를 설명합니다.
• 상호작용 설계에 주의를 기울이지 않고 플랫폼 팀을 만들면 실패합니다.

문화

소프트웨어 전달이 성공하려면 높은 신뢰와 낮은 비난 문화가 필요합니다. 플랫폼 엔지니어링도 마찬가지이며, 문화는 성과를 예측하는 가장 큰 요소 중 하나입니다. (DevOps 문화에 대한 자세한 내용은 별도 참고.)

장기 제품으로서의 플랫폼

• 플랫폼을 구축하는 것은 프로젝트가 아니라 장기 전략이어야 합니다.
• 플랫폼이 보류되면 모든 사용자의 성능이 제한됩니다—플랫폼을 전혀 만들지 않는 것보다 더 나쁩니다.

필요한 것:

• 견고한 팀 설계.
• 명확한 상호 작용 방식.
• 플랫폼에 대한 제품‑마인드셋.

성공의 징후

이제 플랫폼 엔지니어링이 실패할 수 있는 다양한 사례를 살펴보았으니, 성공은 어떤 모습인지 알아보겠습니다.

• Puppet State of Platform Engineering Report에서 **응답자 94 %**가 이 개념이 조직이 DevOps의 이점을 실현하는 데 도움이 되었다고 밝혔습니다.
• DORA Metrics에 대한 높은 성과는 플랫폼 엔지니어링 성공을 예측하는 좋은 지표입니다.

좋은 플랫폼 엔지니어링의 가장 중요한 징후는 … (여기에 성공 기준을 계속 작성하세요).

Source: …

제품으로서의 플랫폼 엔지니어링

개발자가 고객이며, 내부 플랫폼은 그들의 문제를 해결해야 시장 점유율을 확보할 수 있습니다.

1. 플랫폼 팀을 위한 제품‑마인드셋

• 개발자와 정기적인 접촉 – 플랫폼을 사용하는 팀과 피드백 루프를 유지합니다.
• 측정 가능한 성공 기준 – 플랫폼 KPI(예: 도입률, 가치 실현 시간)를 정의하고 추적합니다.
• 프로덕트 매니저 역할
  • 백로그만 관리하지 마세요.
  • 조직 전체에 플랫폼 인식을 높이세요.
  • 다른 부서와 네트워킹하여 그들의 요구를 반영하세요.
  • 개발자가 보안, 거버넌스, 위험 및 규정 준수(SGRC) 요구사항을 만족하도록 돕습니다.

2. 비전, 의사결정 및 문서화

비전

강력하고 영감을 주는 비전은 올바른 결정을 이끌고, 내부 시장 점유율을 위해 잘못된 선택을 지원하는 일을 방지합니다.

의사결정 레지스터

• 모든 주요 아키텍처·제품 결정을 기록합니다.
• 이유를 함께 저장해 결정을 잊거나 나중에 뒤집히지 않게 합니다.

문서화

고품질 문서는 제품 채택에 핵심입니다.

• 최신 상태를 유지합니다.
• 찾기 쉽고 활용하기 편하도록 합니다(예: 검색 가능한 문서, 빠른 시작 가이드).

3. 플랫폼 가치를 높이는 DevOps 역량

“DevOps는 다음 요소들을 결합해 소프트웨어 전달 성능을 향상시킵니다.”

이러한 역량은 가치 있는 플랫폼을 구축할 가능성을 높여줍니다.

4. 작게 시작하고 빠르게 반복하기

• 즉시 “골든 패스”를 목표로 하지 마세요.
• 광범위한 문제 하나를 해결한 뒤, 성공을 향해 반복합니다.

전형적인 “쉬운 승리” 패턴:

1. 공통되고 승인된 기술 스택을 배포합니다.
2. 인프라를 프로비저닝하고 필요 시 환경을 즉시 생성합니다.
3. 텔레메트리, 오류 로그를 수집하고 운영 시스템을 추적합니다.

핵심 원칙: 복잡한 영역을 추상화해 개발자가 세부 사항에 빠지지 않게 하는 것.

• 적합하면 기성 도구를 사용합니다.
• 그렇지 않다면 복잡한 영역을 단순화하는 파사드를 구축합니다.

5. 가장 얇은 실행 가능한 플랫폼

• 가장 큰 영향을 주는 최소 기능부터 시작합니다.
• 한 번에 모든 것을 해결하려 하기보다, 고영향 영역을 우선순위에 두고 천천히 확장합니다.

예시: Unified

(원본 소스에서 내용이 잘려 있습니다; 필요에 따라 계속 작성하세요.)