개발 / 엔지니어링 / 무엇을 개발하고 무엇을 갖다 써야 할까
ref. 1,2 의 이야기를 그저 모아놓았다. 이야기의 결론은 개발자들이 자신들이 직접개발 또는 운영할 것과 그저 사용할 것들을 구분하는 능력이 필요하다. 그리고 조직이 커질수록 좀 더 통일된 툴들, 방법들을 사용해야 한다. 고 정리할 수 있을 듯 하다.
많이 알려져 있는 이야기라 새롭지는 않지만, 이 기사에서 인용한 거대 IT기업의 관련자들이 언급한 말들이 좋은 참고자료가 될 것이라 생각한다.
개발에 의해 생기는 복잡성 관련 이야기
월트 디즈니의 기업 기술 전략 총괄이었으며 현재 컨설턴트인 ‘나이젤 심슨’
- “개발자들이 애플리케이션 개발과 머신러닝을 위한 고차원적 프레임워크를 이용해 더욱 많은 일을 할 수 있게 되었지만, 반대급부가 나타났다. 선택지의 폭발과 개발 속도의 가속화는 개발자가 시대정신을 따라가는 것을 어렵게 만든다. 그러면서 수많은 개발자가 headlight 에 빠진다.”
“It has never been more difficult to be a software developer than it is today,” said Nigel Simpson, a consultant and former director of enterprise technology strategy at Walt Disney. “While we’ve seen an up-leveling of capabilities that enable developers to do more by using high-level frameworks for application development and machine learning, this comes at a cost. The explosion of choice and the pace of development make it challenging for developers to keep up with the zeitgeist, with many developers getting caught in the headlights.”
Essential and accidental complexity
소프트웨어 에이전시인 심플 스레드(Simple Thread)의 공동 설립자인 저스틴 에더리지
- 기본적 및 우발적 복잡성(essential and accidental complexity)을 구분.
- “기본적 복잡성은 사업 영역 안에 있다. 기업의 환경은 극도로 복합적이고 따라서 기업이 해결하려고 하는 문제는 본질적으로 복합적일 수밖에 업다. 그리고 우발적 복잡성이 있다. 이는 우리의 여러 도구와 관련이 있다. 또 우리가 문제를 해결함에 있어 다루는 계층과도 관련이 있다”
클라우드 네이티브 시대는 우발적 복잡성의 가능성이 어느 때보다도 더 높다. 개발자는 이용할 수 있는 툴킷을 최대한 활용하려 하고, 개발자의 상사는 개발자가 고객에게 가치를 전하는 데 전념하기를 원하면서, 서로 충돌한다.
에더리지는 “오늘날의 소프트웨어 개발자 부족 현상을 감안하면, 개발자가 우선적으로 고객에게 가치를 전달하도록 압박할 여지가 별로 없다”면서 “엔지니어가 이런 식으로 생각하도록 만드는 일은 쉽지 않다”라고 말했다.
풍부한 선택의 나쁜점
소규모 독립적 팀이 고객 요구에 대응해 서비스를 제작하려는 움직임
금융서비스업체 투시그마의 플랫폼 엔지니어링 책임자인 카밀 푸르니에(Camille Fournier)
- 인포월드와의 인터뷰에서 “당신은 클라우드 내 사탕가게에 있는 아이와 같다”고 말했다. “하지만 여러분이 성장하고 잘 맞게하려고 노력할 수록, 그 복잡성은 절대적으로 배가됩니다.”
> “But as you grow and try to make things fit together, the complexity absolutely multiplies.”
평균적인 소프트웨어 개발자에게 이러한 선택 수준이 과연 긍정적인가
레드몽크(RedMonk)의 애널리스트인 스티븐 오’그래디
- 2020년 블로그 게시물
- “수많은 서비스를 이용할 수 있다는 사실에 내재된 복잡성은, 특정한 환경에서, 강점이라기 보다는 오히려 부담으로 작용할 수 있다.”
- 증가 중인 복잡성 문제는 여러 조직이 중앙 플랫폼 모델을 도입하도록 유도
- 내부 플랫폼 팀이 엔지니어에게 필요한 툴을 검토하고 템플릿을 제작하고 이들이 실무에 쉽게 유입될 수 있는 골든 패스(golden paths)를 계획하는 일을 담당
- 재무 업무, 보안, 거버넌스 등의 기능을 중앙화해 개발자의 부담을 완화
휴머니텍의 ‘본 그런버그’
- 휴머니텍(Humanitec)의 설립자인 카스파 ‘본 그런버그’
- 휴머니텍은 기업이 자체 개발자 플랫폼을 제작하는 데 도움을 주는 신생 기업
- 우수한 내부 개발자 플랫폼의 핵심
스포티파이 제품 매니저인 ‘니먼’
- How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem : Spotify Engineering
- “6년 정도 전부터 스포티파이는 자율적 팀을 바탕으로 애자일 엔지니어링 문화에 전념했다”면서 “온갖 장점이 있었지만, 복잡성도 발생했다. 예를 들어 개발자 툴링 생태계의 파편화이다. 여기서는 무언가를 하는 방법을 알려면 동료에게 물어보는 수밖에 없었다”라고 말했다.
- 물론 이 방식은 스포티파이의 급속한 성장을 이끌었다. 그러나 이제는 오히려 혁신 속도를 늦추고 있음이 드러났다. 통합과 단순화가 필요했다. 니먼은 “권고된 툴링은 쉽게 발견할 수 있어야 한다. 전체 툴링의 여정은 명확해야 한다. 양질의 이용자 설명서가 있어야 한다. 그리고 일을 하다 막혔을 때 지원받을 곳이 분명해야 한다”라고 말했다.
- “골든 패스(golden path)의 배경이 되는 생각은 엔지니어를 제한하거나 억압하지 않는 것이고, 또는 이를 위해 표준을 정립하지 않는 것이다. 골든 패스가 정착하면 팀은 바퀴를 재발명 할 필요가 없고, 내려야 할 결정의 수가 줄고, 자신의 생산성과 창의성을 고차원적 목적을 위해 사용할 수 있다. 이들은 신속한 움직임으로 돌아갈 수 있다”
‘나이젤 심슨’
- “개발자가 툴을 재발명하고 싶어하는 것”이 문제라면서 “더 나은 쥐덫을 만드는 것만큼 개인적으로 만족스러운 일도 드물다”라고 말했다.
마이크로소프트의 개발자 사업부의 제품 CVP인 ‘아만다 실버’
- “개발자를 억압하려 하는 조직이 있는가 하면 개발자에게 재량권을 주려는 조직이 있게 마련이다. 핵심은 개발자 속도라는 개념이다. 개발자가 자신이 코딩할 수 있는 것만 코딩하고, 전문성이 없는 영역을 배워야 하는 부담을 지거나 산만해지지 않는 체계를 구축하는 것이 좋다”라고 말했다.
아마데우스 인프라 및 클라우드 책임자인 에도드 허빈
- 1987년에 설립된 여행 기술 회사인 아마데우스(Amadeus)
- “개발자들이 회사가 제공하는 핵심 위에서 개발할 수 있어야 한다. 따라서 플랫폼을 사용한 방법으로 이들에게 기능을 제공한다”
- “신기술은 보안과 안정성 때문에 보다 많은 복잡성을 가져온다. 이런 시스템을 가동하는 데는 안정성이 중요하다. 데이터 주도형 애플리케이션의 출현은 우리에게 차원이 다른 복잡성이다. 이는 애플리케이션을 코딩하고 피드백 루프를 구축하는 새로운 방식이다. 이들은 모두 새로운 것이고 복잡성을 가져온다”
- 내부 팀이 솔루션을 설계하거나, 합당한 경우 매니지드 서비스를 이용하며 복잡성을 완화하려 한다.
- 데이터베이스가 한 사례다. 아마데우스는 몽고DB 인스턴스를 자체적으로 운영했지만, 이제 벤더가 관리하는 몽고DB 아틀라스를 이용한다. 회사는 관리형 쿠버네티스에도 비슷한 관점을 취하고 있다.
- 허빈은 “간혹 거부해야 할 때가 있다”면서 “최근 사람들이 새 데이터베이스를 도입하려고 했다. 이들의 생각은 타당했다. 그러나 선택지가 아주 우수한 것이 아니라면 회사가 사용하는 데이터베이스의 수를 통제하는 것이 더 좋다”라고 말했다.
투 시그마(Two Sigma)의 ‘포니어’(Fournier)
- 대형 조직에는 다양한 유형의 엔지니어가 있다. ‘탄력적 시스템을 구축하는 일에 전념하는 엔지니어’, ‘고객에게 신속히 기능을 전달하는 데 전념하는 엔지니어’가 있는가 하면, ’꼭 최신 기술을 쓰려는 애쓰는 엔지니어’(who desperately want to tinker with the latest technology)도 있다. 두 유형 모두 가치가 있지만 이들을 주의 깊게 관리해야 한다
- “새로운것의 내부를 살피고, 이해하는 것을 좋아하는 사람을 원할 것이다.(왜냐하면 베어메탈(bare-metal) 쿠버네티스를 운영할 사람이 있어야 하기 때문이다.) 한편 새로운 것을 살펴보면서 작용 방식을 이해하고, 회사의 어떤 부분에 이것이 유용한지를 판단하고, (프로토타입을 같이하기 좋은 파트너들과 ) 투자할 가치가 있는지를 판단하는 것을 좋아하는 사람도 필요할 것이다.”
어떻게 vendor들이 복잡성과 싸우고 있는지
구글 클라우드의 수석 디벨로퍼 애드보킷인 켈시 하이타워
- 현재 개발자에게 주어진 선택의 풍부함이 ‘선물이자 저주’라고 생각.
- 선물: 거의 무제한적인 수의 기술을 개발에 사용할 수 있다
- 저주: 개발자가 개발자의 워크플로우까지 인프라가 흘러나오는 상황에 빠지고 있다.
deveopers “are being pulled into situations where we leak the infrastructure up into their workflow”
레드몽크(RedMonk)의 애널리스트인 스티븐 오’그래디(O’Grady )
- The Developer Experience Gap – tecosystems
- “물론, 필수적인 조각을 모두 제공할 수 있는 벤더는 없고, 앞으로도 그럴 것이다. 심지어 가장 다양한 애플리케이션 포트폴리오를 보유하고 있고 역사적으로 전례가 없는 배포 속도를 가진 AWS조차 모든 개발자 니즈를 충족시킬 수 없고, 모든 연관 개발자 커뮤니티를 소유할 수 없다”
- Addition By Abstraction – tecosystems
- “우리는 구매자와 개발자를 모두 미로 안으로 보내는 일로부터 탈피하고 있음을 시사하는 증거가 풍부하다. 우리는 이들이 원시적인 것을 선택해 처음부터 조립하도록 하는 작업으로 부담을 주었다. 최초의 클라우드 시대를 원시적인 것으로 정의한다면 이는 끝나가고 있다. 컴퓨팅 산업이 처음부터 그랬던 것처럼, 후속의 클라우드 시대는 우리가 이들 원시적인 것 위에 구축하는 추상화로 정의될 것이다.”
While assembling these primitives into coherent internal platforms has already proved something of a successful workaround for many engineering-led organizations, more traditional enterprises are absolutely going to look to their providers to help them ease this complexity.
기술에 대한 이해는 필요
개발자들이 사용하는 기술들이 추상화돼서 손쉽게 사용할 수 있다고 해도, 그 기술에 대한 이해는 필요하다.
As the legendary British racing driver Jackie Stewart has said, “You don’t have to be an engineer to be a racing driver, but you do have to have mechanical sympathy.” Or, to be truly great, you have to hav
마이크로소프트의 ‘아만다 실버’
여러 개발자 및 그의 팀이 해야 할 일
어디가 자신의 전문성이 가장 가치 있는 분야 이고, 어디가 ’바퀴를 재발명’하면서 낭비되고 있는지를 식별하는 것이다.
The task for many developers and their teams is to identify where their expertise is most valuable and where it is being wasted reinventing the wheel.
소프트웨어 개발자가 이용할 수 있는 선택과 복잡성이 오늘날보다 더 풍부한 적은 없었다. 동시에 추상화의 선택지 또한 이렇게 많은 적이 없었다. 결국 문제는 개발자와 개발자의 조직이 목표를 추구해가면서 어느 정도까지 복잡성을 소화할 수 있는가로 귀결된다.
There has never been more complexity and choice available to software developers than there is today, but there have also have never been more options to abstract it away. It just comes down to how much complexity you and your organization can stomach in the pursuit of your goals.
Reference
- 복잡성이 SW 개발자를 죽인다··· ‘패러다임의 전환’ 올까? - CIO Korea
- Complexity is killing software developers | InfoWorld
