From 69b5aa873b3159ef21ae36c489e5667a1fe44c3e Mon Sep 17 00:00:00 2001 From: Geun-Oh Date: Sun, 4 Feb 2024 07:21:33 +0900 Subject: [PATCH] feat: add Plarform Engineer, Infrastructure feat: add dev.to configuration feat: translated 'internal developer platform vs internal developer portal' fix: applied markdown lint errors fix: fix title caption fix: let id to be allocate automatic fix: add self service translation fix: remove idp tag docs(readme): guide contributions chore: fix typo chore: fix typo articles: update Frontmatter [skip ci] feat: add author information feat: unified infrastructure translation articles(jjangga0214/talk-about-platforms): init (#4) * articles(jjangga0214/talk-about-platforms): init * articles: update Frontmatter [skip ci] * glossary: add "Agile" * articles: rm ambiguous sentences * articles: fix inconsistent usage of "Delivery" * articles: add translator's footnotes * articles: add a word * articles: fix typo * articles: simplify Co-authored-by: Hansuk Hong(Hans) * articles: specify "drag" Co-authored-by: Hansuk Hong(Hans) * articles: specify 'accountability' * articles: rm duplicated eng --------- Co-authored-by: github-actions[bot] Co-authored-by: Hansuk Hong(Hans) articles(jjangga0214/demo): rm articles: update Frontmatter [skip ci] --- .github/workflows/main.yaml | 2 + README.md | 23 ++ ...r_platform_vs_internal_developer_portal.md | 87 +++++++ articles/config.schema.json | 2 +- articles/config.yaml | 12 + articles/contributions/.gitkeep | 0 .../jjangga0214/0001-talk-about-platforms.md | 229 ++++++++++++++++++ articles/jjangga0214/demo.md | 18 -- glossary.csv | 20 ++ haetae.config.ts | 19 +- 10 files changed, 390 insertions(+), 22 deletions(-) create mode 100644 articles/Geun-Oh/internal_developer_platform_vs_internal_developer_portal.md create mode 100644 articles/contributions/.gitkeep create mode 100644 articles/jjangga0214/0001-talk-about-platforms.md delete mode 100644 articles/jjangga0214/demo.md diff --git a/.github/workflows/main.yaml b/.github/workflows/main.yaml index f58e6d6..e51c35e 100644 --- a/.github/workflows/main.yaml +++ b/.github/workflows/main.yaml @@ -75,3 +75,5 @@ jobs: env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} JJANGGA0214_DEVTO_API_KEY: ${{ secrets.JJANGGA0214_DEVTO_API_KEY }} + PINETREE2_DEVTO_API_KEY: ${{ secrets.PINETREE2_DEVTO_API_KEY }} + GEUNOH_DEVTO_API_KEY: ${{ secrets.GEUNOH_DEVTO_API_KEY }} \ No newline at end of file diff --git a/README.md b/README.md index 89e3613..8810f30 100644 --- a/README.md +++ b/README.md @@ -123,6 +123,7 @@ description: {{ Platform Engineering }}과 관련해 효과적인 디지털 플 # comma-separated values 형식의 태그입니다. # Lowercase 와 숫자만 지원합니다. +# 최대 4개의 태그만 가능합니다. tags: platformengineering,platform # 글의 커버이미지입니다. @@ -186,6 +187,28 @@ dev.to 에 배포한 예시는 다음과 같습니다. ![Frontmatter 반영 예시](./docs/images/devto-frontmatter.png) +### 작성한 글을 기여하시는 경우 (Contributor) + +해외의 글이나 영상을 번역하거나, 또는 직접 작성한 컨텐츠를 기여해주시는 것을 환영합니다! + +다음과 같이 *`articles/contributions`* 디렉토리에 작성하여 PR을 주시면 감사하겠습니다. + +```diff + platform-engineering-glossary + ├── articles + │   └── contributions ++ │   └── new-article-foo-bar.md + └── glossary.csv +``` + +만약 작업하시다가 용어집을 추가하신다면 *`glossary.csv`* 를 동일 PR 에서 같이 편집해주시면 됩니다. + +아티클의 경우, PR 이 merge 되면 [Platform Engineering Korea](https://dev.to/platform-engineering-korea) 에 publish 됩니다. +[dev.to](https://dev.to) 내에선 Contribution 전용 계정으로 배포됩니다. +글의 내용(서두나 말미)에 기여해주신 작성자(Contributor)의 신원(GitHub 계정, LinkedIn, SNS 등)을 명시하셔도 좋습니다(권장)! + +### Maintainer/Collaborator 의 경우 + 배포가 이루어지려면 처음 dev.to 에서 API Key 를 발급받어야 합니다. ![dev.to API Key 발급](./docs/images/devto-api-key.png) diff --git a/articles/Geun-Oh/internal_developer_platform_vs_internal_developer_portal.md b/articles/Geun-Oh/internal_developer_platform_vs_internal_developer_portal.md new file mode 100644 index 0000000..e7d72d1 --- /dev/null +++ b/articles/Geun-Oh/internal_developer_platform_vs_internal_developer_portal.md @@ -0,0 +1,87 @@ +--- +platform: dev.to +title: {{ Internal Developer Platform }} vs {{ Internal Developer Portal }} +description: {{ Internal Developer Platform }}과 {{ Internal Developer Portal }}의 차이와 시너지 효과. +tags: platformengineering,platform,internaldeveloperplatform,internaldeveloperportal +cover_image: https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F93c4c8fe-87ed-4bc2-9077-6cc57bdea089_4042x2705.png +published: false +organization_id: 8203 +ci: true +slug: internal-developer-platform-vs-internal-developer-portal +id: 1758825 +--- + +--- + +**알림**: \*이 글은 Substack.com의 [Romaric Philogene](https://substack.com/@rophilogene)님께서 작성하신 [**_Internal Developer Platform vs. Internal Developer Portal_**](https://romaricphilogene.substack.com/p/platform-engineering-7-internal-developer) 을 번역(의역)한 것입니다.\* + +--- + +# {{ Platform Engineering }} #7: {{ Internal Developer Platform }}(Internal Developer Platform) vs. {{ Internal Developer Portal }}(Internal Developer Portal) + +여러분 안녕하세요 👋, + +저는 [Qovery](https://www.qovery.com/)({{ Internal Developer Platform }})의 CEO이자 공동창업자인 Romaric Philogene 이고, 이 글은 제가 Substack에 올리는 7번째 글이네요. 제 이전 글에서, 저는 2024년의 {{ Platform Engineering }}에 대한 예상들을 공유했었죠. + +오늘 저는 {{ Internal Developer Platform }}(Internal Developer Platform)과 {{ Internal Developer Portal }}(Internal Developer Portal)이 무엇이고, 이 두 플랫폼이 어떻게 {{ Platform Engineer }}(Platform Engineer)들에 의해 사용되어 그들의 운영(operation)과는 별개 관점으로 어떻게 그들의 개발자들에게 {{ Self-Service }}(Self-Service)를 제공하고자 하는 공동 목적을 달성하는지 명확히 하고자 합니다. + +![Internal Developer Platform vs. Internal Developer Portal](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F93c4c8fe-87ed-4bc2-9077-6cc57bdea089_4042x2705.png) + +요약(TLDR;) + +> {{ Internal Developer Portal }}은 직관적인 인터페이스(interface)를 제공하지만, {{ Internal Developer Platform }}은 엔진으로서 자동화(automation)와 통합(integration)을 목적으로 동작합니다. + +- **{{ Internal Developer Platform }}**: 개발자들이 전반적인 소프트웨어 개발 수명 주기(SDLC)를 자동적으로 관리할 수 있도록 하는 종합적인 도구와 프로세스(process)의 모음이다. 이는 다양한 개발(development), 운영(deployment), 모니터링(monitoring) 도구들을 하나의 결합된 시스템에 통합했으며, {{ DevOps }}(DevOps)사례들을 가속화합니다. + +- **{{Internal Developer Portal }}**: 개발자들이 필요로 하는 도구, 자원, 문서 등을 쉽게 접근할 수 있도록 하는 사용자 친화적인 인터페이스입니다. 이는 기저에 있는 {{ Internal Developer Platform }}과 타 IT 자원들과의 상호작용을 간편하게 만들어줍니다. + +- **{{ Synergistic Use }}**: {{ Internal Developer Platform }} 과 {{ Internal Developer Portal }}을 함께 사용하는 것은 {{ Self-Service }} 경험을 향상시킵니다. {{ Internal Developer Portal }}이 개발자들이 {{ Internal Developer Platform }}을 효율적으로 활용할 수 있도록 하는 유연하고(streamline) 접근이 용이한 프론트엔드(front-end) 인터페이스을 제공하고, {{ Internal Developer Platform }}이 프로세스 자동화, 통합, 함수화(functionalization) 등의 핵심적인 백엔드(back-end) 동작을 제공합니다. + +## {{ Internal Developer Platform }}이란 무엇인가? + +{{ Internal Developer Platform }}은 개발자들이 개발에서 배포까지의 전체 애플리케이션(application) 생명 주기를 자동으로 관리할 수 있도록 하는 환경입니다. 이는 애플리케이션 개발 및 관리에 있어 IT와 {{ DevOps }}에 크게 의존하고 있기에 나타나는 비효율성과 상호의존성에 대한 해답으로써 나타났습니다. + +![Dialog of key features](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F8e3d90c0-e73f-4d77-94de-284bfbc09ae9_1612x410.jpeg) + +종합적인 도구와 서비스를 제공함으로써, {{ Internal Developer Platform }}은 개발자들이 독립적으로 애플리케이션을 구성, 배포, 관리할 수 있도록하여 효율성과 생산성을 향상시켰습니다. + +![Role of Internal Developer Platform](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F828b65b3-bfad-49e5-9669-cc208f116a12_2708x1148.jpeg) + +## 어떻게 구성하나요? + +{{ Internal Developer Platform }}의 발달 이전에, 소프트웨어 개발 프로세스는 지연과 비효율성에 의해 종종 속도가 저하되고는 했습니다. 개발자들은 자신들의 작업 흐름에 중요한 외부 팀(IT 부서 / {{ DevOps }} 엔지니어 / SRE 등 조직에 따라 다릅니다. 이에 대한 추가적인 얘기를 하지는 않겠습니다.)들에 의존하면서 개발 속도가 저하되고, 환경에 대한 일관성을 잃으며, 자율성이 제한되었습니다. + +![Common Challenge of Software Development 1/2](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4d343fa9-5938-4b9a-978f-6b0b82cbbe57_1551x873.jpeg) + +이것이 유연하고 통합된 환경을 제공하여 의존성을 최소화하고 {{ Agile }}(Agile)하고 즉각적인 개발 프로세스를 조성하도록 도와주는 {{ Internal Developer Platform }}이 작용하는 곳입니다. + +![Common Challenge of Software Development 2/2](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ffa82095a-5940-4c80-89e0-05d0988ffaa8_1549x873.jpeg) + +{{ Internal Developer Platform }}은 유연하게 기존의 {{ DevOps }}와 기술 스택(stack)들에 통합되고, 기존의 프로세스를 유연하게 하고 강화하는 통합 계층으로써 동작합니다. 이는 소프트웨어 개발, 배포, 관리 등에 사용되는 다양한 도구와 서비스가 융합되는 중앙 집중화된 플랫폼을 제공함으로써 생태계에 부합합니다. 이러한 통합은 더욱 효율적인 워크플로우, 더 나은 자원 관리, 개발에서 배포로의 더 부드러운 전이를 가능하게 합니다. 코딩, 테스팅, 배포, 그리고 {{ Infrastructure }}(Infrastructure) 관리를 통해, {{ Internal Developer Platform }}은 기존 스택의 효용을 향상시켜 보다 응집력 있고 {{ Agile }}하며 개발자 친화적입니다. + +{{ Internal Developer Platform }}이 소프트웨어 개발자들의 문제의 일부를 해결하는 것은 맞지만, 모든 것을 해결하지는 않는다. 이곳이 {{ Internal Developer Portal }}이 필요한 지점입니다. + +## {{ Internal Developer Portal }}이 무엇인가? + +{{ Internal Developer Portal }}은 IT 자원들에 대한 출입문입니다. 이것은 개발자들이 도구, 애플리케이션, API, 문서, 그리고 지원 사항에 대해 접근할 수 있도록 하는 사용자 인터페이스입니다. 이는 접근성과 사용성에 초점을 두어 디자인되는데, 당신의 IT {{ Infrastructure }}의 '얼굴'을 생각하면 이해하기 어렵지 않습니다. + +![Spotify Backstage UI - open-source Internal Developer Portal](https://substackcdn.com/image/fetch/w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5ffd1c9a-41a4-4d96-83b8-d1671164b764_1600x930.png) + +잘 디자인된 {{ Internal Developer Portal }} 새로운 도구와 기술에 대한 학습 곡선을 상당히 줄입니다. 이는 자원, 기능 통합에 대한 접근을 유연하게 만들고, 때로는 API 목록, 문서 라이브러리, 그리고 토론회 등의 기능을 포함할 수도 있습니다. + +## 향상된 {{ Self-Service }}를 위한 시너지 효과 + +진짜 마법은 {{ Internal Developer Platform }}과 {{ Internal Developer Portal }}이 함께 사용될 때 발생합니다. {{ Internal Developer Platform }}은 강력한 백엔드 인프라와 자동화 기능을 제공하는 반면, {{ Internal Developer Portal }}은 사용자 친화적인 프론트엔드 인터페이스을 제공합니다. 이러한 시너지 효과는 개발자들에게 {{ Self-Service }} 경험을 다음과 같은 몇 가지 방법으로 향상시킵니다. + +1. **간편화된 접근**: {{ Internal Developer Portal }}은 개발자들이 복잡한 기능성을 가지는 {{ Internal Developer Platform }}의 복잡함을 파헤치지 않고서도 조작하기 쉽도록 만들어줍니다. + 다 + +2. **향상된 생산성**: 포털을 통해 접근하는 {{ Internal Developer Platform }}의 자동화된 프로세스는 수작업을 줄이고 개발 워크플로우를 유연하게 만듭니다. + +3. **향상된 공동작업**: 포털을 통해 공유된 자원과 도구는 개발자, QA, 그리고 다른 운영 조직들 간의 공동 작업을 용이하게 만듭니다. + +4. **더 나은 자원 관리**: 포털은 {{ Internal Developer Platform }}에 대한 통찰과 분석을 제공하고, 조직이 자원의 사용과 성능을 최적화하는 것을 돕습니다. + +## 그래서 어떻게 선택하죠? + +{{ Internal Developer Platform }}과 {{ Internal Developer Portal }}은 별개의 목적을 수행하지만, 이들을 통합하여 사용하면 개발자들에게 {{ Self-Service }} 경험을 크게 향상시킬 수 있습니다. {{ Internal Developer Platform }}은 엔진 역할을 하며 자동화와 통합을 주도하는 반면, {{ Internal Developer Portal }}은 직관적인 인터페이스를 제공하여 이러한 강력한 기능에 쉽게 접근할 수 있도록 합니다. 플랫폼 엔지니어에게 이 두 가지 도구의 장점을 이해하고 활용하는 것은 보다 효율적이고 자율적이며 개발자 친화적인 환경을 구축하는 데 핵심적입니다. diff --git a/articles/config.schema.json b/articles/config.schema.json index c00227c..e5c634d 100644 --- a/articles/config.schema.json +++ b/articles/config.schema.json @@ -5,7 +5,7 @@ "type": "object", "additionalProperties": false, "patternProperties": { - "^(jjangga0214|Ryu-Hanjin|sudosubin|milkyKim|Eeap|kmus1232|Han-Joon-Hyeok|da-head0|pinetree2|Geun-Oh)$": { + "^(jjangga0214|Ryu-Hanjin|sudosubin|milkyKim|Eeap|kmus1232|Han-Joon-Hyeok|da-head0|pinetree2|Geun-Oh|contributions)$": { "type": "object", "additionalProperties": false, "properties": { diff --git a/articles/config.yaml b/articles/config.yaml index 070285e..b815ef4 100644 --- a/articles/config.yaml +++ b/articles/config.yaml @@ -1,3 +1,15 @@ jjangga0214: dev.to: apiKey: JJANGGA0214_DEVTO_API_KEY + +pinetree2: + dev.to: + apiKey: PINETREE2_DEVTO_API_KEY + +Geun-Oh: + dev.to: + apiKey: GEUNOH_DEVTO_API_KEY + +contributions: + dev.to: + apiKey: CONTRIBUTIONS_DEVTO_API_KEY diff --git a/articles/contributions/.gitkeep b/articles/contributions/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/articles/jjangga0214/0001-talk-about-platforms.md b/articles/jjangga0214/0001-talk-about-platforms.md new file mode 100644 index 0000000..741dd5a --- /dev/null +++ b/articles/jjangga0214/0001-talk-about-platforms.md @@ -0,0 +1,229 @@ +--- +title: 내가 플랫폼에 대해 말할 때 짚는 것들 +description: 효과적인 {{ Digital Platform }}이 제공 규모를 확장하는 데 도움이 되는 이유, 플랫폼에 포함되어야 하는 내용, 플랫폼 구축을 시작하는 방법. +tags: platformengineering,platform,idp,thoughtworks +cover_image: https://martinfowler.com/articles/talk-about-platforms/meta.png +published: true +organization_id: 8203 +ci: true +slug: talk-about-platforms +platform: dev.to +id: 1746685 +--- + +--- + +**알림**: *이 글은 martinfowler.com 의 [***What I Talk About When I Talk About Platforms***](https://martinfowler.com/articles/talk-about-platforms.html) 을 번역(의역)한 것입니다.* + +--- + +**효과적인 {{ Digital Platform }}이 제공 규모를 확장하는 데 도움이 되는 이유, 플랫폼에 포함되어야 하는 내용, 플랫폼 구축을 시작하는 방법에 대해 알아봅니다.** + +요즘엔 모두가 디지털 프로덕트(Digital Product) 를 대규모로 빠르게 제공하기 위해 '플랫폼'을 구축하고 있죠. + +반면에, 일부 조직은 조직 구조와 운영 모델을 먼저 다루지 않고, 기존의 공유 서비스를 기반으로 구축하려고 시도하면서 어려움을 겪고 있어요. + +그렇다면 무엇이 효과적인 {{ Digital Platform }}을 만들까요? 같이 알아봅시다. + +## 어쨌든 '플랫폼'은 무엇일까요? + +'플랫폼'이란 단어를 처음 들었을 때 모호하게 느껴질 수 있어요. 굳이 설명하자면 규모에 따른 전달 속도와 효율성을 높이는 데 매우 중요한 접근 방식에 대한 추상적 개념이죠. 그래서 이 모호함을 해결하기 위해 글을 쓰게 되었습니다. 제가 업계에서 지금껏 일하며 이야기해 온 내용들을 정리해보았습니다. + +비유하자면 우리가 대부분 잘 아는 '소프트웨어 및 하드웨어 플랫폼'에 대한 이해는 대체로 다음과 같을 거에요. 일반적으로 응용 프로그램이 실행될 수 있고, 파일 시스템 및 보안과 같은 재사용 가능한 기능을 제공하는 운영 환경을 말하죠. + +'{{ Digital Platform }}' 은 이보다는 생소한 개념이겠지만, 조직 수준에서 확대하면 위와 유사한 특성을 가져요. 운영 환경이 제공하는 재사용 가능한 기능들을 통해 개발팀이 프로덕트(Product)를 보다 신속하게 제공할 수 있게 해주죠. + +**{{ Digital Platform }}(Digital Platform)**은 {{ Self-Service }}(Self-Service) API, 도구, 서비스, 지식 및 지원(Support) 등을 제공하는 기반이에요. 강력한 내부 프로덕트죠. 내부 팀은 플랫폼을 활용하여 공동 작업을 줄일 수 있어요. 즉, 다른 역할의 팀과 협업하며 나타나는 의존성과 소통에 소비되는 시간 지연을 피할 수 있죠. 따라서 더 빠른 속도로 제품을 지속적으로, 자율적으로 배포할 수 있습니다. + +[Thoughtworks](https://www.thoughtworks.com)에서는 플랫폼 기능의 5가지 핵심 요소([링크 1](https://www.thoughtworks.com/what-we-do/enterprise-modernization-platforms-cloud/digital-platform-strategy), [링크 2](https://www.thoughtworks.com/insights/blog/art-platform-thinking))를 정의하는 모델을 개발했습니다. Delivery Infrastructure, Architecture and API Remediation, Self-Service Data, Experiment Infrastructure and Telemetry, 및 Customer Touchpoint Technology 가 포함됩니다. 우리는 글로벌한 경험을 통해 이 요소들이 디지털 기업이 되기 위한 가장 중요한 공유 역량이라는 것을 배웠어요. + +이 글은 플랫폼의 기능들 중, 저희가 {{ Delivery Infrastructure }}(Delivery Infrastructure) 로 정의한 것에 초점을 맞추고 있어요. 클라우드 호스팅 및 {{ DevOps }}(DevOps) 도구를 포함하는 영역이죠. (다만 위에서 언급한 5요소 중, {{ Delivery Infrastructure }} 이외의 플랫폼 기능들에도, 이 글에서 소개된 것과 동일한 특성들이 적용될 수 있습니다.) + +## 첫째, 비(非)플랫폼 + +몇년 전, 저는 호주의 대규모 금융 서비스 기관(이하 *BigCo*)에 대해 컨설팅 업무를 맡았습니다. + +현장에 도착하고 바로 첫 번째 목표를 세웠어요. 애플리케이션 인프라, 호스팅 및 운영 영역에서 무슨 일이 일어나고 있는지 알아보는 일이었죠. 해결해야 할 과제가 어디에 있는지 제대로 이해하는 것이 중요했어요. 우리는 작업 시스템을 통해 실제 변화를 추적하고 작업이 어떻게 수행되는지 살펴보기로 결정했습니다. + +*BigCo* 는 클라우드 및 자동화에 대해 대규모로 투자하고 있었습니다. 하지만 그럼에도 불구하고 인프라 및 운영 영역에서 전통적인 팀을 유지하고 있었어요. 이 '전통적인 팀'은 주된 기술 역량에 따라 구성되어 있었죠. 우리는 몇 가지 일반적인 변경 사항이 회사에서 어떻게 수행되는지 그 전 과정을 따라가 보았습니다. 각 변경 사항에는 여러 팀이 참여했습니다. 애플리케이션 서버 구성에 변경해야 할 사항이 있던 이슈는 우선 '미들웨어(Middleware) 팀'이 담당했습니다. 그런데 미들웨어 팀은 곧 기본 운영체제의 시스템 설정을 변경해야 할 상황을 맞닥뜨렸죠. 하지만 이는 미들웨어 팀이 아니라 '미드레인지(Midrange) 팀'의 고유 권한이었습니다. 미들웨어 팀은 도중에 미드레인지 팀에게 작업의 일부를 부탁해야 했죠. 운영체제 설정 뿐 아니라 다른 분야도 마찬가지였습니다. 데이터베이스에 대한 것은 '데이터베이스 관리자(DBA) 팀'에게, 네트워크에 대한 것은 '네트워크 팀'에게 부탁해야 했습니다. {{ Orchestration }}(Orchestration)을 주로 처리하는 운영 자동화 팀은 물론이고, 엔터프라이즈 모니터링, 보안, 변경 및 릴리스 관리를 처리하는 팀도 따로 있었습니다. 더해서 로드 밸런서나 방화벽에 대한 변경은 회사가 직접 할 수 없었는데, 각기 다른 {{ Managed Service Provider }}(Managed Service Provider)를 통해서 해결해야 했습니다. + +![그림 1](https://martinfowler.com/articles/talk-about-platforms/silos.png) + +*(그림 1: 고도로 전문화된 인프라 및 운영팀 분리)* + +사내의 각 팀은 독립적이었습니다. 각자의 기술 영역에서는 높은 효율성을 지녔고, 전문화되었죠. 차별화되지 않는 기능은 아웃소싱했고, 거버넌스를 적용했어요. 비용도 절감했죠. 그러나 이 모든 것은 각자의 영역에서였을 뿐, 고객에게 기능을 엔드 투 엔드로 제공하는 효율성을 측정하지는 않았습니다. + +이런 이유로 인프라와 관련된 작은 변경일지라도 수행되기까지 느릴 수밖에 없었습니다. 몇 주에서 몇 달이 걸리며 고객 대응에 큰 영향을 미쳤죠. 간단하지 않은 변경이라면 더더욱 느려짐은 말할 필요도 없었습니다. 이로 인해 엔지니어와 관리자는 꼭 필요한 것이 아니면 가능한 한 변경 횟수를 최소화하려는 경향을 띄게 되고 말았죠. + +![그림 2:](https://martinfowler.com/articles/talk-about-platforms/silos-impact.png) + +*(그림 2: 애플리케이션 제공 팀에서 요구하는 변경 작업에는 몇 주 또는 몇 달이 소요됩니다.)* + +*BigCo* 에서는 이로 인해 애플리케이션과 인프라의 내부 품질이 점진적으로 저하되었습니다. 환경 및 구성 설정에 약간의 불일치가 여기저기 발생하기도 했죠. 꼭 필요한 변경이 아니면 꺼려하다보니 작고 사소한 개선들이 이루어지지 않고 있었어요. 품질과 일관성을 위한 리팩토링이 잘 진행되고 있지 않았다는 이야기죠. + +그런데 이러한 성향은 실제로 스스로 강화되는 경향이 있습니다. 이렇게 각 팀이 서로 영향을 주고 받는 환경에서 누군가 실수하지 않기 위해서는 예측 가능성이 중요하다고 느꼈을 겁니다. 사내 인원들 스스로 예측 가능성을 중시하게 되면서, 무언가 개선하고 바꾸는 일은 갈수록 보수적으로 검토되게 되었죠. 어떤 부분을 변경하면 지금까지와는 다른 행동양식을 띄게 되어 예측 가능성이 줄어들 수 있으니까요. + +요약하면 *BigCo* 에서 인프라와 호스팅을 다루는 것은 느리고 어려웠습니다. + +## "{{ Backlog Coupling }}(Backlog Coupling)" 의 영향 + +민첩한 소프트웨어 제공을 위해 손쉽게 얻을 수 있는 성과는 항상 디지털 채널에 있었습니다. 비즈니스 리더는 고객의 요구 사항을 식별하고 있고, 소규모 자율 팀은 그들과 긴밀히 협력하여 이를 충족하는 기능을 구축하죠. 그러나 디지털 프로덕트 팀이 더 기민하게 대응할 수록, 외적인 제약사항은 더욱 커집니다 + +일반적으로 디지털 팀을 괴롭히는 세 가지 주요 영역이 있죠. 굼뜨게 움직이는 핵심 트랜잭션 기록 시스템, 고품질 데이터 및 분석에 대한 액세스, 공유 인프라 및 운영입니다. + +저는 '{{ Backlog Coupling }}(Backlog Coupling)'이라는 용어를 사용합니다. 여기서 백로그는 {{ Agile }}(Agile) 딜리버리(Delivery) 팀에서 자주 사용하는 계획 도구입니다. + +![그림 3](https://martinfowler.com/articles/talk-about-platforms/backlog-coupling.png) + +*(그림 3: 변경 사항이 여러 팀의 백로그(작업 대기열)에 걸쳐 종속성을 가질 때 {{ Backlog Coupling }}이 발생합니다.)* + +이는 간단한 개념이에요. 어떤 팀이 백로그를 만들었다고 해보죠. 만약 그중 많은 항목이 다른 팀에서 또 다른 백로그를 만들게 유도한다면 어떨까요? 또 그렇게 했을때 비슷한 연쇄 효과가 연달아 일어난다면요? 이러면 생산성과 대응력이 엄청나게 저하됩니다. 이 백로그들은 조직 전체에 걸쳐 서로 연결되긴 하지만, 각자 서로 다른 작업 체계에 따라 우선순위가 지정됩니다. 최종적으로 일을 해결하기까지의 과정이 복잡해진다는 소리죠. 아마 이런 상황에서 칸반(Kanban)을 보면 해당 작업에는 'blocked' 라는 ​​큰 빨간색 스티커가 붙여있지 않을까요? 이해관계자는 한숨을 쉬고 있겠죠. 여러 팀이 공유하는 서비스를 담당하고 있는 쪽에선 각 팀의 서로 다른 요구사항에 대응하려고 이리저리 분주할 겁니다. 뭐, 그래봤자 가장 큰 목소리를 가진 팀에 우선 반응해주는 게 최선일 테지만요. + +{{ Backlog Coupling }}이 구체적으로 대략 얼마나 나쁠까요? 호주의 한 통신 회사에서 제 동료들이 수치적으로 연구한 이야기를 들려드릴게요. 그들은 Delivery 단계를 통과하는 수백 가지 작업에 대해 살펴보았습니다. 일부 작업은 종속성 없이, 다른 팀 구성원과의 협업 없이 단일 팀에서 완료할 수 있었어요. 반면 다른 팀을 기다려야 하는 작업의 경과는 대개 10 ~ 12배 정도 더 느렸죠. 종속성은 실제로 지대한 영향을 미친다는 것을 정량적으로 알 수 있었습니다. + +이건 여러 면에서 우리에게 해를 끼쳐요. 우선 순수한 업무 처리량과 고객 요구에 대한 대응력에 부정적인 영향을 미치는 게 자명하죠. 그리고 우리는 종속성을 보다 효율적으로 관리하기 위한 보다 장기적인 계획을 세우도록 유도"당합니다". 이런 문화는, 어떤 결과던 '하나의 단일 팀이 주된 책임을 지도록 하는 지향성'(accountability)을 저하시키고, 많은 팀의 동기 부여를 죽이는 것을 목격했어요. 팀들은 쉽게 서로 책임을 전가하고 지속적인 개선 추구를 중단하게 될 수도 있습니다. + +그리고 사내의 여러 팀에게 공유되는 서비스를 맡는 팀에도 과부하가 걸리죠. 그런 팀에 일하면서 여기 저기 휘둘리는 건 그리 재미있는 일이 아닙니다. + +최근 '{{ Scaling Agile }}'(Scaling Agile)의 전통은 이 문제를 한 가지 방식으로 해결하려고 합니다. 여러 팀에 걸쳐 우선순위를 조정하는 세레머니(Ceremony)를 도입하는 방법입니다. {{ Backlog Coupling }}을 생성되는대로 두지 않고, 연쇄적인 우선순위를 세부 조정하는 겁니다. 이 방법은 문제 해결에 도움이 되기는 하지만 치러야 할 대가가 있죠. 전반적으로 각 팀의 자율성과, 변화에 자체 대응하는 능력이 줄어듭니다. 저는 이것이 우리가 택해야 할 유일한 방법이라 말하고 싶지 않군요. + +따라서 좋은 '플랫폼'의 우선적인 특징은 가능한 최대로 {{ Backlog Coupling }}의 양을 줄이는 것이어야 해요. 플랫폼은 티켓을 제기하고 작업을 할당할 필요가 없는 서비스를 제공해야 합니다. {{ Self-Service }}(Self-Service) 는 좋은 플랫폼의 주요 특징을 정의합니다. + +플랫폼은 팀에게 {{ Self-Service }} 접근(Self-Service Access), {{ Self-Service }} 프로비저닝(Self-Service Provisioning), {{ Self-Service }} 구성(Self-Service Configuration), {{ Self-Service }} 관리(Self-Service Management), {{ Self-Service }} 운영(Self-Service Operation) 을 허용해야 합니다. + +## ~~허술한~~ 피상적인 프라이빗 클라우드 + +자, *BigCo* 는 {{ Self-Service }}(Self-Service)의 필요성을 인식했습니다. 그러나 지금껏 일해 오며 익숙해진 사고 방식과 이미 확립된 레거시(Legacy) 인프라로 인해서 어떻게 해야 좋을지 판단하는 데 어려움을 겪었죠. 중앙 집중식 자동화 도구에 대한 투자는 이미 있었기 때문에, 첫 번째 노력은 애플리케이션 딜리버리(Delivery) 팀이 인프라를 셀프 프로비저닝(Self-Provisioning) 할 수 있는 {{ Self-Service }} 기능을 만드는 것이었습니다. + +우선 {{ Self-Service }} 도구(Self-Service tool)는 딜리버리(Delivery) 팀이 매우 고정된 템플릿을 사용해 온디맨드로 컴퓨팅 인스턴스를 요청할 수 있도록 구축되었어요. 프로비저닝된 가상 머신 인스턴스는 구성이 고정되었으며 보안적으로 안전하게 잠겨 중앙 미드레인지(midrange) 팀이 전체 인스턴스들을 한번에 제어할 수 있도록 했습니다. 다만 이는 딜리버리(Delivery) 팀이 스스로 인스턴스에 추가적인 작업을 할 수는 없다는 것을 의미해요. 예를 들면 패키지 설치, 네트워크 연결, 스토리지 연결, 로드 밸런서 프로비저닝, 모니터링 도구 구성 등 딜리버리(Delivery) 팀 입장에서 인스턴스에 유용할 것으로 기대되는 어떤 작업을 수행하려면 미드레인지(midrange) 팀에게 티켓을 생성해야 합니다. 딜리버리(Delivery) 팀 입장에선 전과 같이 여전히 답답하게 느껴질 만한 제약 사항이죠. + +![그림 4](https://martinfowler.com/articles/talk-about-platforms/superficial-private-cloud.png) + +*(그림 4: BigCo 는 애플리케이션과 인프라 실행 방식의 기본 사항을 변경하지 않고 기본적인 {{ Self-Service }} API 를 구축했습니다. 결과적으로 제공(Delivery) 속도에는 큰 변화가 없었습니다.)* + +음 혹자는 일단 이 제약을 비판하기에는 이르다고 생각할 수도 있습니다. 이건 단지 첫번째 이터레이션(Iteration)이었을 뿐이니까요. 첫술에 배부르랴? 맞는 말입니다. 하지만 여기에는 *BigCo* 의 인프라 및 운영 팀의 의도가 담겨있었습니다. 우선 인프라 및 운영 팀은 당시 자체 조직 사일로를 무너뜨리고 중요한 책임(결과적으로 접근 권한)을 딜리버리(Delivery) 팀에 넘길 준비가 되어있지 않았어요. 또한, 제약을 없애고 {{ Self-Service }}를 온전히 가능하게 할 API를 충분히 구축하는 데 필요한 노력이 적어도 당장은 실행 가능하지 않다고 판단하고 있었습니다. + +우리는 이러한 유형의 접근 방식을 '{{ Superficial Private Cloud }}'(Superficial Private Cloud)라고 부릅니다. 즉, 중앙에서 제어하는 양은 줄이지 않고 매우 제한된 방식으로 딜리버리(Delivery) 팀이 사용할 수 있도록 하려는 접근방식입니다. 기존에 사용하던 가상화 플랫폼을 크게 바꾸지 않고 포장만 그럴듯하게 하는 것이라 할 수 있죠. + +한편 *BigCo* 에서는 병행된 노력으로 딜리버리(Delivery) 팀이 AWS 를 직접 사용할 수 있도록 기능을 잠금 해제했습니다. 선례가 확립되자 많은 다른 프로덕트의 딜리버리(Delivery) 팀들이 AWS를 사용하기 위해 몰려들었습니다. + +AWS 는 딜리버리(Delivery) 팀이 직접 사용할 수 있는 강력한 플랫폼입니다. 완전한 {{ Self-Service }}라고 할 수 있고, 책임의 경계가 명확하죠. 말 그대로 *"You build it, you run it"* 입니다. AWS 은 플랫폼의 {{ Availability }}(Availability)을 보장하고, 충분한 수준의 API 를 제공합니다. 애플리케이션 딜리버리(Delivery) 팀은 그 위에서 애플리케이션을 구축(build), 구성(configure) 및 실행(run)할 수 있죠. + +--- + +(**역주**: *"You build it, you run it"* 은 {{ DevOps }} 세계에서 아주 유명한 어구입니다. 2006년 Amazon 의 CTO 였던 [Werner Vogels](https://www.linkedin.com/in/wernervogels/)가 처음 언급했고, {{ DevOps }} 시대의 서막을 알리는 말이 되었습니다. 말 그대로 소프트웨어를 개발하는 사람(팀)이 실행 및 운영까지 수행한다는 의미입니다.) + +--- + +근데 설마 이게 이야기의 끝일까요? + +## 자율성은 시장 출시 시간을 단축하고 혁신을 강화합니다. + +제가 만난 대부분의 조직에는 '재사용을 위한 구축'(build for re-use)이라는 기본 철학이 있었습니다. 즉, 미래를 염두에 두고 기능들을 중앙에 집중화하여 만들어 두면, 나중에 재사용하여 비용을 절감하면서도 이미 검증된 기능으로 위험을 회피할 수 있다는 것입니다. + +![그림 5](https://martinfowler.com/articles/talk-about-platforms/autonomy-vs-centralised.png) + +*(그림 5: 대부분의 조직은 기본적으로 비용 효율성을 얻기 위해 중앙에서 기술을 선택 및 강제합니다.)* + +지난 몇 년 동안 저는 운이 좋게도 호주의 주요 테크 회사에서 기술 리더십 팀의 일원이 되었습니다. 수백 명의 엔지니어를 보유하고 있는 글로벌 회사이기도 했고 온라인으로도 큰 영향력을 발휘하는 곳이었죠. + +이번엔 이 곳을 편의상 *WebBiz* 라고 명칭해볼게요. 아주 큰 조직은 아니었지만 딱 *BigCo* 와 동일한 종류의 과제에 직면할 만큼의 규모는 있던 곳이었습니다. 인프라, 애플리케이션 및 데이터 측면에서도 적지 않은 레거시(Legacy)를 보유하고 있었죠. 그러나 이미 말했듯 거대한 회사는 아니었기에 비교적 빠르게 개선해 볼 수 있을 만큼은 작았습니다. + +처음 *WebBiz* 는 임대 데이터 센터의 가상화 플랫폼(Virtualized Platform)을 사용하고 있었습니다. 이후 AWS로 다년간의 마이그레이션을 시작했죠. 그러면서 동시에 애플리케이션과 인프라의 빌드와 실행에 대한 책임도 조정했습니다. 중앙화된 운영 팀만이 가지던 권한을 개별 프로덕트 팀들이 자율적으로 수행하도록 한 것이죠. 제가 목격한 전통적인 중앙 운영에서 {{ DevOps }}(DevOps)으로의 가장 완전한 전환이었습니다. 저는 *"You build it, you run it"* 이라는 사고방식으로 소규모 조직을 시작하는 것이 실제로 그리 어렵지 않다고 생각해요. 그러나 반대로 기존의 전통적인 방식으로 해오던 규모 있는 조직을 새로 전환하기 위해서는 용기와 비전의 연속성이 필요합니다. *WebBiz* 는 그 점에서 매우 좋은 성과를 거두었습니다. + +마이그레이션의 일환으로, *WebBiz* 의 프로덕트 팀에는 스택의 모든 부분을 구성하고 실행하는 방법에 대한 완전한 자율권이 부여되었어요. 이 접근 방식은 '{{ Team-Managed Infrastructure }}'(Team-Managed Infrastructure)로 명명되었습니다. 초기에 몇 가지 (중앙화 된) 고정값이 설정되어 있었지만, 각 팀은 중앙의 개입을 거의 받지 않고 스택의 모든 부분에 대해 자체적으로 결정을 내렸습니다. + +*WebBiz* 는 기존 조직의 일반적인 편견을 성공적으로 뒤집었죠. 결과적으로 각 팀마다 다른 기술은 조직의 다양화를 불러왔어요. 또한 필요만 있다면 새로운 기술을 만드는 것(invention)을 선호하는 분위기도 정착되었죠. 새로운 기술들이 창조되었고, 각 엔지니어는 기술 스택에 대해 더 깊은 경험을 쌓을 수 있었습니다. 배포된 항목에 대한 책임 수준도 전과 달리 신속하게 설정되었죠. 팀 의존성은 크게 제거되었습니다. 말인즉슨, 전반적으로 모든 직원이 스스로 정해 직접적으로 참여하는 일의 비중이 높아졌다고 봐야죠. 이건 채용에도 유리했습니다. 자신이 원하는 기술을 선택하고, 자율적으로 어려운 비즈니스 및 기술 문제에 도전해 일을 처리하며, 스스로 책임을 지는 문화는 많은 인재들에게 매력적으로 어필되었거든요. + +## 기술 다양화로 항력(drag) 증가 + +그러나 모든 이점에도 불구하고 완전한 자율성으로 전환하려면 확실한 비용이 필요합니다. AWS 를 플랫폼으로 채택함으로써 중앙 집중식 인프라 팀에 대한 {{ Backlog Coupling }}(Backlog Coupling)을 제거하는데 유의미한 도움을 받았습니다. 그러나 AWS 만으로 인프라에 대한 모든 해결책이 될까요? 아닙니다. 그 외에도 선택할 것은 많죠. 여전히 모든 팀은 인프라 구축 및 운영의 모든 측면에 대해 또 다른 영역에서 일련의 결정을 내려야 합니다. + +![그림 6](https://martinfowler.com/articles/talk-about-platforms/cncf.png) + +*(그림 6: {{ Cloud Native Landscape }}(Cloud Native Landscape) [출처: www.cncf.io])* + +위는 CNCF(Cloud Native Computing Foundation) 가 제공하는 {{ Cloud Native Landscape }}(Cloud Native Landscape) 의 최신 버전입니다. 클라우드 네이티브 아키텍처 구축 시 관심 영역별로 그룹화된 몇 가지 일반적인 오픈 소스 및 제품 제공을 포착하려는 시도라고 할 수 있죠. 생태계에서 가장 잘 확립된 지도라고 할 수 있는데, 이런 저런 기술로 꽤나 붐비는군요. 이 많은 기술들 중에서, 각 팀은 요구 사항에 가장 적합한 제품을 선택할 수 있어야 합니다. 그리고 해당 제품을 통합하고 운영하는 방법을 배워야 하겠죠. + +--- + +**역주**: 저자가 {{ Cloud Native Landscape }}(Cloud Native Landscape) 를 최신 버전이라고 했지만, 이는 2018년 초까지의 기준입니다. 해당 이미지는 v1.0 이고, v2.0이 2018년 3월 릴리즈되었습니다. 번역을 하는 2024년의 지금은 위의 이미지보다 "훨씬" 많은 기술이 {{ Cloud Native Landscape }}에 포함되어 있습니다. 하지만 특정 기술의 분포와 관계없이, 2018년이던 2024년이던 저자가 말하고자 하는 바는 달라지지 않습니다. 회사가 중앙에서 스택을 통제하지 않기로 했으니, 각 팀이 자율적으로 선택 가능한 수많은 기술들이 있습니다. {{ Cloud Native Landscape }}는 그것을 직관적으로 보여주는 대표적인 예시일 뿐입니다. 저자는 그저 AWS 와 같은 클라우드 서비스 제공자(Cloud Service Provider; CSP)에 대한 권한을 각 팀에게 부여하는 것만으로는 부족하다고 말하고 있습니다. 사내에서 만든 '플랫폼'이 클라우드 서비스 제공자는 물론, {{ Cloud Native Landscape }}와 같은 별개의 기술 및 서비스도 같이 유기적으로 품을 수 있어야 한다는 것입니다. 즉, 쉽게 비유해서 애플리케이션 팀이 {{ Cloud Native Landscape }}를 들여다보면서 수많은 기술들에 대해서 시류를 살피고 공부하며 인프라에 관한 세부 설치 및 구성을 직접 하도록 두기 보단, 플랫폼 팀이 이를 대신해 플랫폼으로서 기능을 제공하자는 의미입니다. 물론 플랫폼 팀이 {{ Cloud Native Landscape }}의 수많은 기술에 대한 사전 설정을 모두 제공해줄 수는 없습니다. 대신, 사내에서 대다수의 수요를 커버할 수 있을 정도 만큼의 다양성만 사전 제공하면 된다는 것입니다. '파레토 법칙'을 생각하면 됩니다. 풀어 말하자면 생태계에 10개의 기술이 있을때, 회사에서 집중적으로 쓰일 2개만 플랫폼으로 제공해도, 80% 의 사내 수요를 감당할 수 있습니다. 나머지 20% 는 아마 나머지 8개 기술에 대한 수요로 흩어져 있어서 플랫폼으로 제공하기에는 노력 대비 효과가 적을 겁니다. 이 이율배반은 다음 섹션인 "내부 제품(Internal Product)으로서의 플랫폼" 에서 자연스레 이어지는 흐름으로 다루어집니다. 파레토 법칙에서 20% 에 속하는 소수 케이스의 경우, 즉 플랫폼이 제공해주기 어려운 수요의 경우, '{{ Paved Road }}'(Paved Road) 가 아니라 자체적인 대안(스스로 개척한 도로)을 허용한다는 Netflix 의 사례도 그러한 맥락으로 언급되는 것입니다. 대신 그런 팀은 지원되지 않는 기술과 방법을 택한 이유에 대해 스스로 좋은 결과로서 책임 져야 합니다. + +--- + +기술은 빠르게 발전합니다. 보다시피 선택할 옵션도 많죠. 그런데 이 모든 기술에 전문가인 사람은 아마 거의 없을 겁니다. 따라서 각 팀이 인프라에 대한 선택 사항을 지속적으로 조사하고 평가해야 하는 오버헤드는 분명 있다고 할 수 있습니다. 또 서로 다른 팀 사이에 기술 또는 팀원을 이전하는 경우, 마찰(friction)도 발생할 수 있죠. + +이 문제는 어떻게 해결할까요? + +그 답으로 *WebBiz* 는 이제 보다 명확하게 정의된 딜리버리 인프라 플랫폼(Delivery Infrastructure Platform)을 구축하기 시작했습니다. 여러 기본값(default)들이 사전에 정의된 세트로 주어진다고도 볼 수 있는데요. 덕분에 프로덕트 팀 입장에서는 부담이 줄어들고 (인프라가 아닌 애플리케이션 자체에 집중함으로서) 생산성을 높이는 도움을 받을 수 있었습니다. + +하지만 이렇게 함으로서 혹시 역으로 자율성이 가져온 이점을 잃을 위험이 있지는 않을까요? + +## 내부 제품(Internal Product)으로서의 플랫폼 + +우리는 항상 트레이드 오프에 마주칩니다. 자율적인 다양화(Autonomous Diversification)와 의무적 통합(Mandated Consolidation)도 그렇죠. 그 사이에서 올바른 균형을 찾아가는 것은 금방 되는 일이 아니에요. 사전에 스위트 스팟(Sweet Spot)을 예측하기는 훨씬 더 어렵습니다. 이러한 균형을 찾아가는 데 성공하기 위한 핵심 요소는 플랫폼이 사용자 입장에서 매력적이어야 한다는 것입니다. + +플랫폼을 설득력있게 만드는 것은 무엇일까요? + +다음은 몇 가지 아이디어입니다. + +- 플랫폼은 사내에서 요구되는 (전부는 아니지만) 대다수의 사용 사례(Use Case)를 커버할 수 있는 {{ Self-Service }}(Self-Service)입니다. +- 플랫폼은 구성(조합) 가능하며, 독립적으로 사용할 수 있는 개별 서비스를 포함합니다. +- 플랫폼은 딜리버리(Delivery) 팀에게 융통성 없이 딱딱한 작업 방식을 강요하지 않습니다. +- 플랫폼은 쉬운 진입로(예: 빠른 시작 가이드, 문서, 코드 샘플)를 통해 빠르고 저렴하게 사용을 시작할 수 있습니다. +- 플랫폼에는 공유를 위한 풍부한 내부 사용자 커뮤니티가 있습니다. +- 플랫폼은 기본적으로 안전하고 규정을 준수합니다. +- 플랫폼은 최신의 상태입니다. + +예를 들자면 위의 항목에 많이 해당할수록 사용자 입장에서 합리적인 플랫폼이라 느낄 겁니다. 궁극적으로 정리하면 딜리버리 인프라 플랫폼(Delivery Infrastructure Platform)은 각 팀이 편리하게 플랫폼 기능을 사용할 수 있도록 해야 합니다. 그냥 손쉽게 플랫폼을 이용하는 것이 별도로 자신만의(각 팀만의) 것을 구축하고 유지하는 것보다 유익하다고 생각될 때 비로소 플랫폼의 역할이 의미있어집니다. + +이것과 관련해서, Netflix 는 중앙 집중식 도구(Centralised Tooling)를 '{{ Paved Road }}'(Paved Road)라고 설명합니다. 우선 각 팀이 꼭 이러한 중앙화된 도구나 플랫폼을 사용하도록 강제되지는 않아요. 만약 어떤 팀이 회사에서 이미 잘 닦아놓은 '포장된 도로'가 아니라 비탈길을 스스로 개척하면서 도로를 만들어간다면 그것도 충분히 용인됩니다. 단, 해당 팀은 스스로 자체적인 대안(스스로 개척한 도로)을 유지하는 데 드는 모든 비용과 결과를 책임져야 합니다. + +--- + +(**역주**: 플랫폼 엔지니어링의 영역에서는 '{{ Golden Path }}'(Golden Path)라는 용어도 종종 사용됩니다. '{{ Paved Road }}'(Paved Road) 와 둘다 "길"로 비유한다는 점은 공통점이지만, 서로 다른 개념입니다. 전자는 공통적인 관심사에 대한 템플릿에 가깝고, 후자는 중앙화되면서 검증된 도구를 의미합니다.) + +--- + +문단을 종합적으로 짧게 정리하자면, 플랫폼은 단순한 소프트웨어나 API 그 이상이어야 합니다. 즉, 문서화, 컨설팅, 지원 및 {{ Evangelism }}(Evangelism), 템플릿 및 지침을 포괄하는 개념이 되어야 합니다. + +## 잠깐만요, 이거 '{{ DevOps }}(DevOps) 팀' 아닌가...요? + +나쁘게 끝났나요? +어쩜, 그럴 수도요. + +{% embed %} + +(저는 아직 {{ DevOps }}(DevOps) 논쟁에서 패배를 인정할 준비가 되지 않았습니다. 만약 독자님의 회사에 'DevOps' 라는 팀이 있다면, 제가 의미하는 DevOps 와 다른 의미일 겁니다.) + +--- + +(**역주**: {{ DevOps }} 개념이 등장했을 때에는 특정한 협의(狹義)가 아니라, 문화 그 자체이자 철학으로 정의하는 입장이 많았습니다. 그러나 시간이 지나며 반대로 특수성을 띈 역할이나 팀, 도구와 같이 특정한 개념을 지칭하는 사례도 생겼습니다. 또는 기존의 운영팀을 거의 그대로 이름만 {{ DevOps }} 팀으로 바꾸는 경우도 있었습니다. 이를 보고 {{ DevOps }}라는 개념을 잘못 언급하지 말자며 지적하는 분위기도 생겼습니다. 그러나 오히려 반대로 {{ DevOps }}의 정의가 현실적으로 문제가 있다는 등 이를 비판하는 목소리도 존재했습니다. 반면 {{ DevOps }}의 구체성이 모호하여 서로 다른 개념과 사례를 같은 단어인 {{ DevOps }}로 지칭하게 되어 대화할수록 오해가 쌓인다던가 하는 의견도 있었습니다. 저자는 {{ DevOps }} 개념이 처음 등장했을 때부터 지금까지 동일하게 순수한 입장을 고수하고 있다는 의미입니다.) + +--- + +딜리버리 인프라 플랫폼(Delivery Infrastructure Platform)을 구축(build)하고 운영(operate)하기 위해 팀을 구성할 수도 있습니다. 대부분 이것이 처음 시작하는 가장 좋은 방법이 될 것이라고 생각하고요. 그렇다면 '플랫폼 팀'과 '고객'의 책임 범위를 매우 명확하게 해야 합니다. 아 여기서 '고객' 이라 함은, 플랫폼의 내부 사용자입니다. 명확성을 위해 이를 구체적으로 '애플리케이션 팀'이라고 지칭해볼게요. + +애플리케이션 팀은 애플리케이션을 구축(bulid), 배포(deploy)하고 모니터링(monitoring)을 수행합니다. 그리고 플랫폼에서 프로비저닝하고 배포하는 애플리케이션 구성 요소(component)와 애플리케이션 인프라에 대해 직접 작업하고 실시간 운영해야 합니다. + +플랫폼 팀은 마찬가지로 플랫폼을 구축(build), 배포(deploy)하고 모니터링(monitoring)을 수행해야 하죠. 역시 플랫폼 구성 요소와 플랫폼 인프라에 대해 직접 작업하고 실시간 운영해야 합니다. + +플랫폼 팀은 이상적으로는 플랫폼에서 어떤 애플리케이션이 실행되고 있는지조차 몰라도 괜찮아야 합니다. 오직 플랫폼 자체의 {{ Availability }}(Availability)만 책임지면 됩니다. + +이러한 방식으로 애플리케이션 팀과 플랫폼 팀 모두 자체 제품의 빌드 및 실행에 대한 책임을 집니다. 애플리케이션 팀의 프로덕트는 애플리케이션이고, 플랫폼 팀의 프로덕트는 플랫폼입니다. *"You build it, you run it"* 이라는 말은 여전히 ​​적용됩니다. + +## 어디서부터 시작해야 해요? + +딜리버리 플랫폼(Delivery Platform) 구축에 성공하기 위해서는 몇 가지 사전조건이 있어요. + +첫째, 당신이 이미 ['프로젝트'에서 벗어나는](https://martinfowler.com/articles/products-over-projects.html) 여정을 이미 시작했어야 해요. 플랫폼은 프로덕트(Product)입니다. 플랫폼을 제품으로 취급하기 위해서 구축(build)와 실행(run)을 모두 담당하는 장기적이고 안정적인 제품 팀이 필요해요. + +둘째, 애플리케이션 실행 책임의 일부 또는 전부를 중앙 집중식 운영(Centralised Operation)에서 벗어나 애플리케이션 팀으로 기꺼이 전환해야 합니다. 대신 플랫폼은 애플리케이션 팀이 자신이 구축한 것에 대해 책임을 질 수 있도록 도구와 서비스를 제공하죠. 중앙에서 일방향적으로 세부 지원(support)을 하는 경우에는 이런 일이 일어나지 않으니, 그러지 말고 애플리케이션 팀이 플랫폼을 통해 '스스로를 지원하도록' 하세요. + +셋째, 사내의 엄격한 일관성과 애플리케이션 팀에 부여하는 자율성(자유+책임) 사이의 이율배반 관계에서 적절한 균형점을 찾아나갈 준비가 되어 있어야 합니다. 플랫폼 자체가 그 최적점으로 수렴하도록 맞추어가세요! + +자, 마지막으로, 몇 가지 유의사항을 꼭 기억해주세요. + +- 당신의 플랫폼은 당신이 설치할 수 있는 인프라, 도구 및 API 뿐만이 아닙니다. 우선 딜리버리(Delivery) 팀이 독립적으로 어느 정도 범위까지 선택하는 것이 좋을지 vs 또는 플랫폼 팀은 어느 정도 범위까지 합리적인 기본값(Sensible Defaults)(또는 제약)을 제공해야 할지에 대해 차차 정해 가야 해요. 또한, 딜리버리(Delivery) 팀이 (원하는) 새로운(다양한) 기능들을 가능한 빠르게 도입하는 것과 vs 플랫폼 팀이 지속적으로 유지 보수를 해낼 수 있는 정도의 상태를 지속하는 방법에 대해서도 답해 나가야 하죠. 이를 위해서는 내부 컨설팅 스킬과 트레이닝 및 {{ Evangelism }}(Evangelism)이 필요할 거에요. +- 처음엔 최종적으로 어떤 플랫폼 기능이 필요하게 될지 모를 수 있어요. 그러니 실제로 명료하게 확실한 요구 사항을 중심으로 소규모로 시작해보세요. 우선 애플리케이션 팀 내부에서 이미 효과가 검증된 솔루션을 검토하는 것이 좋아요. 그리고 플랫폼 팀과 그 고객이 될 팀(애플리케이션 팀)이 서로 합작해서 초기 기능을 만들고 테스트 해 보는 것 역시 추천합니다. +- '플랫폼' 이란 단어를 사용하는데 신중하세요! 이미 사내에서 전통적으로 보유하고 있는 제한된 가상화 호스팅(Limited Virtualized Hosting) 이나 제약된 중앙 관리 도구(Locked-Down Centrally-Managed Tooling)과 크게 다르지 않은 개념에 '플랫폼' 이란 이름을 붙이지 않도록 주의하세요. diff --git a/articles/jjangga0214/demo.md b/articles/jjangga0214/demo.md deleted file mode 100644 index 365a6c5..0000000 --- a/articles/jjangga0214/demo.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -platform: dev.to -title: 내가 플랫폼에 대해 말할 때 짚는 것들 -description: 효과적인 디지털 플랫폼이 제공 규모를 확장하는 데 도움이 되는 이유, 플랫폼에 포함되어야 하는 내용, 플랫폼 구축을 시작하는 방법. -tags: platformengineering,platform -cover_image: https://martinfowler.com/articles/talk-about-platforms/meta.png -published: true -organization_id: 8203 -ci: true -slug: about-platforms -id: 1732681 ---- - -# {{ Platform Engineering }}을 소개합니다 - -{{ Platform Engineering }}에 대해 다루어볼까요? - -감사합니다~! diff --git a/glossary.csv b/glossary.csv index fbaed19..d577dae 100644 --- a/glossary.csv +++ b/glossary.csv @@ -2,3 +2,23 @@ en,ko Platform Engineering,플랫폼 엔지니어링 Internal Developer Platform,내부 개발자 플랫폼 Internal Developer Portal,내부 개발자 포털 +Product,프로덕트 +Self-Service,셀프 서비스 +Digital Platform,디지털 플랫폼 +Delivery Infrastructure,딜리버리 인프라 +Delivery Infrastructure Platform,딜리버리 인프라 플랫폼 +DevOps,데브옵스 +Orchestration,오케스트레이션 +Managed Service Provider,관리형 서비스 공급자 +Backlog Coupling,백로그 결합 +Agile,애자일 +Scaling Agile,애자일 확장 +Superficial Private Cloud,피상적 프라이빗 클라우드 +Team-Managed Infrastructure,팀 관리 인프라 +Paved Road,포장된 도로 +Availability,가용성 +Evangelism,에반젤리즘 +Cloud Native Landscape,클라우드 네이티브 랜드스케이프 +Golden Path,골든 패스 +Platform Engineer,플랫폼 엔지니어 +Infrastructure,인프라 diff --git a/haetae.config.ts b/haetae.config.ts index e44982d..1a9af43 100644 --- a/haetae.config.ts +++ b/haetae.config.ts @@ -1,6 +1,6 @@ import type { Rec } from '@haetae/common' import assert from 'node:assert/strict' -import { $, configure, utils } from 'haetae' +import { $, configure, utils, core } from 'haetae' import { extensions } from './workflows/render.js' import { detectSideEffects, publishArticles } from './workflows/publish.js' import { @@ -10,13 +10,26 @@ import { prNumber, } from './workflows/github.js' +function handleErr( + func: (options: A) => Promise, +): (options: A) => Promise { + return async (options: A) => { + try { + return await func(options) + } catch (error) { + console.error(error) + throw error + } + } +} + export default configure({ commands: { publish: { env: () => { assert(isPr() || isPushToMain(), 'Only push to main or PR is allowed.') }, - run: async ({ store }) => { + run: handleErr(async ({ store }) => { interface RecordData extends Rec { [pr: number]: { hasSideEffects?: boolean @@ -89,7 +102,7 @@ export default configure({ }, } } - }, + }), }, }, }) as unknown