2021.03.08

데브옵스 잘하는 조직의 비결··· '내부 개발자 플랫폼’이란?

Scott Carey | InfoWorld
빠르고 안정적인 소프트웨어 릴리즈를 위해 데브옵스 문화를 성공적으로 구축한 조직들은 ‘내부 개발자 플랫폼(Internal Developer Platform; IDP)’을 사용해 코드를 배포한다. 여기서 IDP는 무엇이며, 이를 어떻게 확보할 수 있는가? 

현대적인 애플리케이션 개발에서 클라우드 컴퓨팅, 컨테이너화, 데브옵스, 마이크로서비스 아키텍처가 중요한 구성 요소로 자리 잡으면서 내부 소프트웨어 개발자 팀을 위해 이러한 리소스를 간단하게 관리할 방법이 필요해지고 있다. 
 
ⓒGetty Images

많은 엘리트 엔지니어링 조직(예: 구글, 넷플릭스 아마존 등)에서 내부 개발자 플랫폼은 데브옵스 팀의 운영 부하를 완화해주는 한편 소프트웨어 개발자들이 불필요한 의사결정을 내릴 필요가 없도록 해준다.

美 전 대통령 버락 오바마가 과도한 의사결정으로 인한 피로감을 줄이기 위해 회색 또는 파란색 양복만 입었던 것처럼, 좋은 내부 개발자 플랫폼을 가지고 일하는 개발자들은 코드와 깃 리포지토리에 관해서만 걱정하고 기반 인프라 관리는 플랫폼에 맡길 수 있다.  

IDP란 무엇인가?
‘어떤 눈송이도 똑같이 생긴 것이 없다’라는 말처럼 IDP 역시 동일한 게 없다는 점에서 눈송이 같다. 인프라, 문화, 코드 베이스, 도구 등에 따라 조직마다 내부 플랫폼이 다르기 때문에 공통된 정의를 찾기란 다소 어렵다. 

美 기술 전문 컨설팅 업체 쏘우트웍스(ThoughtWorks)의 엔지니어링 책임자 에반 뵈트허는 한 블로그에 기고한 글에서 “말이 어렵게 보이긴 하지만 ‘플랫폼’은 규모에 맞게 딜리버리 속도와 효율성을 높이는 데 중요한 접근법에 사용할 수 있는 가장 모호한 개념이다”라고 말했다. 

이어서 그는 (비록 ‘내부 플랫폼’보다 ‘디지털 플랫폼’이라는 표현을 선호하긴 했지만) 내부 제품에 따라 셀프-서비스 API, 툴, 서비스, 지식, 지원 등을 제공하는 기반으로 이를 정의했다. 

美 헤지펀드 투 시그마(Two Sigma)의 플랫폼 엔지니어링 부문 책임자 카밀 포니어는 내부 플랫폼은 인프라의 소프트웨어 측면과 연결된다고 밝혔다. 그는 블로그에서 “쿠버네티스, 스토리지 시스템, 소프트웨어 개발 도구, 서비스용 프레임워크 등의 컴퓨팅 플랫폼은 여기서 반드시 갖춰야 할 구성 요소다”라고 언급했다. 

좋은 내부 개발자 플랫폼은 인프라 관련 의사결정을 없애고, 셀프-서비스 환경 구축을 지원하며, 기존 CI/CD 및 배포 프로세스와 통합되고, 역할 기반 액세스 제어를 할당해야 한다. 개발자는 YAML을 배울 필요가 없다. 

구글에서 내부 개발자 플랫폼을 구축했던 경험이 있으며, 현재는 휴머니테크의 CTO인 크리스 스티븐슨은 블로그에서 “효과적인 내부 개발자 플랫폼은 복잡성을 구분한다. 각자 자신이 전문성을 발휘할 수 있는 (복잡성) 영역을 갖고 있다. 나머지는 이를 안심하고 신경 쓰지 않을 수 있다”라고 말했다.

레드몽크(Redmonk)의 수석 애널리스트 스티븐 오그래디는 “지난 한 해 동안 툴 체인에서 필요한 부분들을 가져와 개발자가 참여할 수 있고 그리고 앱을 작성할 수 있는 플랫폼에 통합하는 한편, 기저의 모든 복잡성은 제거하는 트렌드를 확인했다”라고 밝혔다. 

IDP의 이점
퍼핏(Puppet)과 서클CI(CircleCI)가 최근 발표한 ‘데브옵스 현황(State of Devops)’ 보고서에 따르면 성숙한 데브옵스 문화를 갖춘 조직과 그렇지 못한 조직을 구분하는 3가지 핵심 요소는 자동화된 변경 관리, 통합 보안, 그리고 셀프-서비스 내부 플랫폼이다.

--> 2020.11.27 . 데브옵스를 성공적으로 확장하는 기업의 3가지 특징

완벽하게 작동하는 내부 개발자 플랫폼은 현대적인 소프트웨어 시스템의 복잡성 부담을 줄여주며, 소프트웨어 배포 주기를 가속화하고, 더욱더 안정적인 릴리즈를 생성하게끔 해주며, 개발자의 만족도와 생산성을 높이고, 운영 부담을 줄여준다.

누구에게 필요할까?
내부 개발자 플랫폼의 핵심 사용자 그룹은 플랫폼/운영/데브옵스 팀 그리고 개발자 팀이다. 

플랫폼/운영/데브옵스 팀은 플랫폼을 구성하고, 필요한 인프라와 도구에 API 후크를 생성하며, 액세스 및 컴플라이언스 체계를 설정한다. 플랫폼은 일반적으로 개별 제품 소유자 또는 대규모 조직의 경우 전담 내부 플랫폼 팀에 의해 구성된다. 

이러한 팀은 개발자들과 협력해 요구사항을 파악하고 공통된 문제점을 완화하며 필요에 따라 이 절차를 반복한다. 이 모든 것은 핵심 사용자 메트릭스에 따라 이뤄진다. 또한 이들은 내부적으로 플랫폼을 알리는 데도 능숙해야 한다. 

클라우드 컨설팅 업체 엑스퍼트 씽킹(Expert Thinking)의 CTO 제임스 윈은 “이러한 사고방식이 내부 플랫폼 성공의 열쇠다. 그렇지 않으면 반드시 비즈니스 가치를 제공하려는 것이 아니라 그냥 유행어가 멋있기 때문에 여기에 주력하는 일이 생길 수 있다”라고 말했다. 

그다음 개발자는 불필요한 것을 모두 뺀 버전의 플랫폼을 얻게 된다. 바로 인프라와 관련된 의사결정을 없애 배포에만 집중할 수 있는 플랫폼이다. 

휴머니테크의 CEO 카스파 본 그룬버그는 “데브옵스 팀에게는 유연해야 하지만 개발자에게는 유연하면 안 된다”라면서, “모든 사용자 정의 기능은 데브옵스 팀에 있어야 하며, 기반 인프라에 관해 생각하고 싶지 않은 개발자들을 위한 경로도 생성해야 한다”라고 설명했다. 한편 휴머니테크는 지난 2018년 설립돼 기업들의 내부 플랫폼 구축을 지원하고 있다. 

하지만 이렇게 한다면, 그냥 개발과 운영을 분리하면 되지 않을까? 

퍼핏의 현장 부문 CTO 니겔 커스텐에 따르면 내부 플랫폼을 구축하고 소비하는 팀은 깊게 연결돼 있어야 한다. 모든 사람이 같은 방향으로 나아가도록 하기 위해서다. 그는 “개발과 운영을 분리하면 과거처럼 개발과 운영이 별개였던 세상으로 전락해버릴 것”이라고 지적했다. 

IDP vs. PaaS
일반적으로 공급업체가 개발자의 작업 방식을 규정하는 서비스형 플랫폼(Platform as a Service; PaaS)과 달리, 내부 개발자 플랫폼은 개발자 팀이 이미 익숙한 도구 및 프로세스를 기반으로 구축된다. 

지난 2017년 구글의 기술자 켈시 하이타워는 트위터에서 “인프라를 관리하는 대부분의 사람들이 PaaS를 원한다고 확신한다. 그렇지만 유일한 요건은 자신들에 의해 구축돼야 한다는 것”이라고 언급한 바 있다. 

많은 소규모 조직이 PaaS를 사용해 엔지니어링 팀을 신속하게 구성하고 운영한다. 인기 있는 PaaS 제품에는 (세일즈포스가 2010년 인수한) 헤로쿠(Heroku), 오픈시프트(OpenShift), 클라우드 파운드리(Cloud Foundry) 또는 대형 퍼블릭 업체들의 자체 도구 등이 있다. 그러나 이런 제품들은 확장에 필요한 유연성이 부족한 경우가 많다. 

한편 무작정 IDP 접근법을 채택한다면 엔지니어에게 자체 플랫폼을 구축할 기회가 주어지면서 쓸데없이 시간을 낭비하는 위험이 발생할 수 있다. 더 심각한 경우는 아마존이나 구글처럼 운영하려고 하는 것이다. 이는 큰 방해와 재앙을 초래할 수 있다. 

포니어는 “이러한 대기업이 자사 솔루션을 오픈소스 소프트웨어로 제공하더라도 사용 가능한 제품의 주변 생태계 그리고 여기서 잘 작동하지 않을 수 있는 제품을 쓰는 엔지니어의 문화와 니즈에 관한 모든 가정을 명시하는 경우가 많다. ‘구글이 이렇게 하기 때문에 우리도 이렇게 해야 한다’라는 건 좋은 제품 관리가 아니다”라고 지적했다.

커스텐도 이와 유사한 관점을 갖고 있다. 그는 “수많은 대기업이 아마존에서는 효과가 있었던 소규모 자율팀 모델을 도입하려 시도했다. 하지만 다른 기업에서 이는 혼란과 조직 부채를 초래했다”라고 말했다. 

IDP의 출발점
모놀리식 배포 프로세스에서 지속적 제공(CD)으로 이동하는 것은 중요한 문화적 변화다. 과소평가돼선 안 된다. 뵈트허는 “개인적으로 ‘내가 구축하고, 내가 운영한다’라는 사고방식을 가진 소규모 조직을 만들어 시작하는 게 그리 어렵지 않다고 본다. 그러나 이런 변화에는 용기와 꾸준한 비전이 필요하다”라고 전했다. 

커스텐은 ‘IDP’가 최신 유행어이기 때문에 그저 단순히 기존 프로세스를 내부 플랫폼(IDP)으로 리브랜딩하려고 하는 기업들을 많이 봤다고 밝혔다. 그는 “가장 큰 문제점은 중앙 IT를 플랫폼 팀으로 이름만 바꾸고, 이에 필요한 기술적, 문화적 변화를 시도하지 않는 것이다. 이 용어가 인기를 끌면 이런 현상이 더 늘어나리라 예상한다”라고 말했다. 

게다가 내부 개발자 플랫폼으로의 전환 아니면 이를 처음부터 구축하는 것을 전사적으로 설득하기가 어려울 수 있다. 경영진을 설득하는 한편 개발자로 하여금 자신이 완전히 통제하지 못하는 새로운 작업 방식을 받아들이도록 만드는 큰 변화가 어렵다는 이야기다. 커스텐은 “사용자를 이해하고 이런 문화적 변화를 시도하는 것은 더 큰 문제이다”라고 전했다.

커스텐을 비롯한 업계 전문가들은 작게 시작하는 게 좋다고 조언한다. 윈은 “가장 먼저 ‘CoE’를 만들고 플랫폼을 개발해 차별화할 수 있는 사용 사례를 식별해야 한다”라면서, “단일 애플리케이션을 대상으로 하는 테스트 환경을 구축하고 여기에서 필요한 API를 구축하는 것만으로도 플랫폼 팀이 올바른 길을 가도록 도움을 줄 수 있다”라고 설명했다. 

‘팀 토폴로지(Team Topologies)’의 저자 중 한 명인 매튜 스켈톤은 지난 2019년에 열린 ‘데브옵스 엔터프라이즈 서밋(Devops Enterprise Summit)’에서 “이에 관해 생각할 수 있는 한 가지 방법은 실행 가능면서도 가장 작은 플랫폼으로 시작하는 것 또는 플랫폼에서 어떤 것이 중요한지 명확하게 하고 그것이 필요 이상으로 커지지 않도록 하는 것이다”라고 언급했다. 

이어서 그는 “무엇을 구축하든 그게 사용하기 쉽고, 적절한 개발자 경험을 갖추도록 해야 하며, 사용자의 니즈를 파악하고 충족할 수 있도록 이들을 대화해야 할 고객이라고 취급해야 한다”라고 덧붙였다. 

폰 그룬버그는 “직접 구축하든 구매하든 동일하다. 풀뿌리 수준에서 시작해야 한다는 말이다. 유능한 엔지니어들로 구성된 작은 그룹에서 시작한다. 이들에게 분리된 툴 체인에서 접착제 역할을 하라고 요청한다. 그다음 팀이 다룰 수 있는 공통 API를 중심으로 중앙화를 시작하고, 이 구조를 비구조화된 도구들에 적용한다”라고 설명했다.
 
ciokr@idg.co.kr
 



2021.03.08

데브옵스 잘하는 조직의 비결··· '내부 개발자 플랫폼’이란?

Scott Carey | InfoWorld
빠르고 안정적인 소프트웨어 릴리즈를 위해 데브옵스 문화를 성공적으로 구축한 조직들은 ‘내부 개발자 플랫폼(Internal Developer Platform; IDP)’을 사용해 코드를 배포한다. 여기서 IDP는 무엇이며, 이를 어떻게 확보할 수 있는가? 

현대적인 애플리케이션 개발에서 클라우드 컴퓨팅, 컨테이너화, 데브옵스, 마이크로서비스 아키텍처가 중요한 구성 요소로 자리 잡으면서 내부 소프트웨어 개발자 팀을 위해 이러한 리소스를 간단하게 관리할 방법이 필요해지고 있다. 
 
ⓒGetty Images

많은 엘리트 엔지니어링 조직(예: 구글, 넷플릭스 아마존 등)에서 내부 개발자 플랫폼은 데브옵스 팀의 운영 부하를 완화해주는 한편 소프트웨어 개발자들이 불필요한 의사결정을 내릴 필요가 없도록 해준다.

美 전 대통령 버락 오바마가 과도한 의사결정으로 인한 피로감을 줄이기 위해 회색 또는 파란색 양복만 입었던 것처럼, 좋은 내부 개발자 플랫폼을 가지고 일하는 개발자들은 코드와 깃 리포지토리에 관해서만 걱정하고 기반 인프라 관리는 플랫폼에 맡길 수 있다.  

IDP란 무엇인가?
‘어떤 눈송이도 똑같이 생긴 것이 없다’라는 말처럼 IDP 역시 동일한 게 없다는 점에서 눈송이 같다. 인프라, 문화, 코드 베이스, 도구 등에 따라 조직마다 내부 플랫폼이 다르기 때문에 공통된 정의를 찾기란 다소 어렵다. 

美 기술 전문 컨설팅 업체 쏘우트웍스(ThoughtWorks)의 엔지니어링 책임자 에반 뵈트허는 한 블로그에 기고한 글에서 “말이 어렵게 보이긴 하지만 ‘플랫폼’은 규모에 맞게 딜리버리 속도와 효율성을 높이는 데 중요한 접근법에 사용할 수 있는 가장 모호한 개념이다”라고 말했다. 

이어서 그는 (비록 ‘내부 플랫폼’보다 ‘디지털 플랫폼’이라는 표현을 선호하긴 했지만) 내부 제품에 따라 셀프-서비스 API, 툴, 서비스, 지식, 지원 등을 제공하는 기반으로 이를 정의했다. 

美 헤지펀드 투 시그마(Two Sigma)의 플랫폼 엔지니어링 부문 책임자 카밀 포니어는 내부 플랫폼은 인프라의 소프트웨어 측면과 연결된다고 밝혔다. 그는 블로그에서 “쿠버네티스, 스토리지 시스템, 소프트웨어 개발 도구, 서비스용 프레임워크 등의 컴퓨팅 플랫폼은 여기서 반드시 갖춰야 할 구성 요소다”라고 언급했다. 

좋은 내부 개발자 플랫폼은 인프라 관련 의사결정을 없애고, 셀프-서비스 환경 구축을 지원하며, 기존 CI/CD 및 배포 프로세스와 통합되고, 역할 기반 액세스 제어를 할당해야 한다. 개발자는 YAML을 배울 필요가 없다. 

구글에서 내부 개발자 플랫폼을 구축했던 경험이 있으며, 현재는 휴머니테크의 CTO인 크리스 스티븐슨은 블로그에서 “효과적인 내부 개발자 플랫폼은 복잡성을 구분한다. 각자 자신이 전문성을 발휘할 수 있는 (복잡성) 영역을 갖고 있다. 나머지는 이를 안심하고 신경 쓰지 않을 수 있다”라고 말했다.

레드몽크(Redmonk)의 수석 애널리스트 스티븐 오그래디는 “지난 한 해 동안 툴 체인에서 필요한 부분들을 가져와 개발자가 참여할 수 있고 그리고 앱을 작성할 수 있는 플랫폼에 통합하는 한편, 기저의 모든 복잡성은 제거하는 트렌드를 확인했다”라고 밝혔다. 

IDP의 이점
퍼핏(Puppet)과 서클CI(CircleCI)가 최근 발표한 ‘데브옵스 현황(State of Devops)’ 보고서에 따르면 성숙한 데브옵스 문화를 갖춘 조직과 그렇지 못한 조직을 구분하는 3가지 핵심 요소는 자동화된 변경 관리, 통합 보안, 그리고 셀프-서비스 내부 플랫폼이다.

--> 2020.11.27 . 데브옵스를 성공적으로 확장하는 기업의 3가지 특징

완벽하게 작동하는 내부 개발자 플랫폼은 현대적인 소프트웨어 시스템의 복잡성 부담을 줄여주며, 소프트웨어 배포 주기를 가속화하고, 더욱더 안정적인 릴리즈를 생성하게끔 해주며, 개발자의 만족도와 생산성을 높이고, 운영 부담을 줄여준다.

누구에게 필요할까?
내부 개발자 플랫폼의 핵심 사용자 그룹은 플랫폼/운영/데브옵스 팀 그리고 개발자 팀이다. 

플랫폼/운영/데브옵스 팀은 플랫폼을 구성하고, 필요한 인프라와 도구에 API 후크를 생성하며, 액세스 및 컴플라이언스 체계를 설정한다. 플랫폼은 일반적으로 개별 제품 소유자 또는 대규모 조직의 경우 전담 내부 플랫폼 팀에 의해 구성된다. 

이러한 팀은 개발자들과 협력해 요구사항을 파악하고 공통된 문제점을 완화하며 필요에 따라 이 절차를 반복한다. 이 모든 것은 핵심 사용자 메트릭스에 따라 이뤄진다. 또한 이들은 내부적으로 플랫폼을 알리는 데도 능숙해야 한다. 

클라우드 컨설팅 업체 엑스퍼트 씽킹(Expert Thinking)의 CTO 제임스 윈은 “이러한 사고방식이 내부 플랫폼 성공의 열쇠다. 그렇지 않으면 반드시 비즈니스 가치를 제공하려는 것이 아니라 그냥 유행어가 멋있기 때문에 여기에 주력하는 일이 생길 수 있다”라고 말했다. 

그다음 개발자는 불필요한 것을 모두 뺀 버전의 플랫폼을 얻게 된다. 바로 인프라와 관련된 의사결정을 없애 배포에만 집중할 수 있는 플랫폼이다. 

휴머니테크의 CEO 카스파 본 그룬버그는 “데브옵스 팀에게는 유연해야 하지만 개발자에게는 유연하면 안 된다”라면서, “모든 사용자 정의 기능은 데브옵스 팀에 있어야 하며, 기반 인프라에 관해 생각하고 싶지 않은 개발자들을 위한 경로도 생성해야 한다”라고 설명했다. 한편 휴머니테크는 지난 2018년 설립돼 기업들의 내부 플랫폼 구축을 지원하고 있다. 

하지만 이렇게 한다면, 그냥 개발과 운영을 분리하면 되지 않을까? 

퍼핏의 현장 부문 CTO 니겔 커스텐에 따르면 내부 플랫폼을 구축하고 소비하는 팀은 깊게 연결돼 있어야 한다. 모든 사람이 같은 방향으로 나아가도록 하기 위해서다. 그는 “개발과 운영을 분리하면 과거처럼 개발과 운영이 별개였던 세상으로 전락해버릴 것”이라고 지적했다. 

IDP vs. PaaS
일반적으로 공급업체가 개발자의 작업 방식을 규정하는 서비스형 플랫폼(Platform as a Service; PaaS)과 달리, 내부 개발자 플랫폼은 개발자 팀이 이미 익숙한 도구 및 프로세스를 기반으로 구축된다. 

지난 2017년 구글의 기술자 켈시 하이타워는 트위터에서 “인프라를 관리하는 대부분의 사람들이 PaaS를 원한다고 확신한다. 그렇지만 유일한 요건은 자신들에 의해 구축돼야 한다는 것”이라고 언급한 바 있다. 

많은 소규모 조직이 PaaS를 사용해 엔지니어링 팀을 신속하게 구성하고 운영한다. 인기 있는 PaaS 제품에는 (세일즈포스가 2010년 인수한) 헤로쿠(Heroku), 오픈시프트(OpenShift), 클라우드 파운드리(Cloud Foundry) 또는 대형 퍼블릭 업체들의 자체 도구 등이 있다. 그러나 이런 제품들은 확장에 필요한 유연성이 부족한 경우가 많다. 

한편 무작정 IDP 접근법을 채택한다면 엔지니어에게 자체 플랫폼을 구축할 기회가 주어지면서 쓸데없이 시간을 낭비하는 위험이 발생할 수 있다. 더 심각한 경우는 아마존이나 구글처럼 운영하려고 하는 것이다. 이는 큰 방해와 재앙을 초래할 수 있다. 

포니어는 “이러한 대기업이 자사 솔루션을 오픈소스 소프트웨어로 제공하더라도 사용 가능한 제품의 주변 생태계 그리고 여기서 잘 작동하지 않을 수 있는 제품을 쓰는 엔지니어의 문화와 니즈에 관한 모든 가정을 명시하는 경우가 많다. ‘구글이 이렇게 하기 때문에 우리도 이렇게 해야 한다’라는 건 좋은 제품 관리가 아니다”라고 지적했다.

커스텐도 이와 유사한 관점을 갖고 있다. 그는 “수많은 대기업이 아마존에서는 효과가 있었던 소규모 자율팀 모델을 도입하려 시도했다. 하지만 다른 기업에서 이는 혼란과 조직 부채를 초래했다”라고 말했다. 

IDP의 출발점
모놀리식 배포 프로세스에서 지속적 제공(CD)으로 이동하는 것은 중요한 문화적 변화다. 과소평가돼선 안 된다. 뵈트허는 “개인적으로 ‘내가 구축하고, 내가 운영한다’라는 사고방식을 가진 소규모 조직을 만들어 시작하는 게 그리 어렵지 않다고 본다. 그러나 이런 변화에는 용기와 꾸준한 비전이 필요하다”라고 전했다. 

커스텐은 ‘IDP’가 최신 유행어이기 때문에 그저 단순히 기존 프로세스를 내부 플랫폼(IDP)으로 리브랜딩하려고 하는 기업들을 많이 봤다고 밝혔다. 그는 “가장 큰 문제점은 중앙 IT를 플랫폼 팀으로 이름만 바꾸고, 이에 필요한 기술적, 문화적 변화를 시도하지 않는 것이다. 이 용어가 인기를 끌면 이런 현상이 더 늘어나리라 예상한다”라고 말했다. 

게다가 내부 개발자 플랫폼으로의 전환 아니면 이를 처음부터 구축하는 것을 전사적으로 설득하기가 어려울 수 있다. 경영진을 설득하는 한편 개발자로 하여금 자신이 완전히 통제하지 못하는 새로운 작업 방식을 받아들이도록 만드는 큰 변화가 어렵다는 이야기다. 커스텐은 “사용자를 이해하고 이런 문화적 변화를 시도하는 것은 더 큰 문제이다”라고 전했다.

커스텐을 비롯한 업계 전문가들은 작게 시작하는 게 좋다고 조언한다. 윈은 “가장 먼저 ‘CoE’를 만들고 플랫폼을 개발해 차별화할 수 있는 사용 사례를 식별해야 한다”라면서, “단일 애플리케이션을 대상으로 하는 테스트 환경을 구축하고 여기에서 필요한 API를 구축하는 것만으로도 플랫폼 팀이 올바른 길을 가도록 도움을 줄 수 있다”라고 설명했다. 

‘팀 토폴로지(Team Topologies)’의 저자 중 한 명인 매튜 스켈톤은 지난 2019년에 열린 ‘데브옵스 엔터프라이즈 서밋(Devops Enterprise Summit)’에서 “이에 관해 생각할 수 있는 한 가지 방법은 실행 가능면서도 가장 작은 플랫폼으로 시작하는 것 또는 플랫폼에서 어떤 것이 중요한지 명확하게 하고 그것이 필요 이상으로 커지지 않도록 하는 것이다”라고 언급했다. 

이어서 그는 “무엇을 구축하든 그게 사용하기 쉽고, 적절한 개발자 경험을 갖추도록 해야 하며, 사용자의 니즈를 파악하고 충족할 수 있도록 이들을 대화해야 할 고객이라고 취급해야 한다”라고 덧붙였다. 

폰 그룬버그는 “직접 구축하든 구매하든 동일하다. 풀뿌리 수준에서 시작해야 한다는 말이다. 유능한 엔지니어들로 구성된 작은 그룹에서 시작한다. 이들에게 분리된 툴 체인에서 접착제 역할을 하라고 요청한다. 그다음 팀이 다룰 수 있는 공통 API를 중심으로 중앙화를 시작하고, 이 구조를 비구조화된 도구들에 적용한다”라고 설명했다.
 
ciokr@idg.co.kr
 

X