경영진이 기능을 필요로 할 때 기술 부채 관리하기

헤이든 베일리오
맞습니다.

‍

헤이든 베일리오
어디 보자.

‍

헤이든 베일리오
생방송 중이며 여러분을 기다리고 있습니다.

‍

켈빈 델 몬테
여러분, 어서 오세요, 환영합니다.

‍

헤이든 베일리오
네, 모두들 만나기 힘들어요. 채팅에 참여 중이라면 인사해 주세요.

‍

헤이든 베일리오
안녕하세요, 안녕하세요.

나한테 뭘 던지지 마, 알았지?

‍

켈빈 델 몬테
당신

시청하시는 모든 분들께 행복한 수요일입니다. 행복한 혹의 날입니다.

‍

헤이든 베일리오
네, 맞아요.

‍

헤이든 베일리오
이런, 이런, 이런, 여기 있습니다.

‍

헤이든 베일리오
좋아요, 그럼 이제 시작하죠.

‍

켈빈 델 몬테
알았지? 알았어요.

‍

헤이든 베일리오
그냥 전면과 중앙에 있는 걸 확인하려고요. 캘빈이 저와 제 친구 센터로 오셨나요? 아니면 지금 바로 친구인가요?

‍

켈빈 델 몬테
우리 둘 다 똑같이 전면에 나서고 있습니다.

‍

헤이든 베일리오
똑같이 전면과 중앙에 배치한 것이 마음에 듭니다. 우리가 그래야 하는 것처럼 마음에 들어요. 좋아요, 완벽해요.

여러분, 드디어 다 모였습니다. 경영진에게 새로운 기능이 필요할 때 기술 부채를 관리하는 방법에 대해 이야기할 이 멋진 웨비나에 참여해 주셔서 감사합니다. 바로 본론으로 들어가겠습니다. 시간이 30분밖에 없으니 오늘 발표자를 소개하겠습니다. 신사 숙녀 여러분, 기술 분야에서 가장 부드러운 목소리와 기술 부채를 설명할 수 있는 드문 능력을 모두 갖춘 분입니다.

경영진을 울리지 않고도 말이죠. HeroDevs의 솔루션 아키텍트인 그는 레거시 시스템을 최첨단 플랫폼으로 전환하고 기술 부채 문제를 해결하여 사람들이 기술 부채 문제를 해결하도록 돕는 데 경력을 쌓았습니다. 농담입니다. 하지만 수명이 다한 소프트웨어의 수명 주기 관리와 HeroDevs의 역할에 대해 완벽하게 이해하고 있는 사람입니다.

그리고 오늘은 지난 가족 모임에서 접이식 테이블처럼 코드 기반이 무너지지 않고 기능을 출시하는 방법을 보여드리려고 합니다. 기술 부채 관리의 ASMR 목소리를 환영해 주세요. 캘빈 델 몬테입니다. 참여해 주셔서 감사합니다. 캘빈이 가져가세요 다 네 덕분이야 다 당신 덕분이에요

‍

켈빈 델 몬테
감사합니다.

‍

켈빈 델 몬테
감사합니다. 고마워요. 고마워요, 헤이든 좋아요 모두 환영합니다. 와주셔서 감사합니다. 그리고 이 회의는 녹화 중이므로 나중에 시청하실 분들도 이 아름다운 수요일에 오신 것을 환영합니다. 기술 부채에 대해 이야기해 보겠습니다. 시작하기 전에 먼저 제 소개를 하고 싶습니다. 저는 켈빈 델 몬테입니다. 저는 히어로 개발팀의 솔루션 엔지니어입니다. 2008년부터 소프트웨어 엔지니어로 일하고 있습니다.

그리고 이 기간 동안 저는 여러 엔지니어링 팀을 이끌고 관리할 기회도 가졌습니다. 오늘 제가 이야기할 내용은 제 개인적인 경험에서 나온 것이죠? 저는 대기업, 중소기업, 스타트업 등 모든 종류의 조직에서 일했습니다. 그리고 이 과정을 통해 기술 부채와 관련하여 많은 것을 배웠습니다. 그리고 여러분과 공유하고 싶습니다. 먼저 기술 부채란 무엇인가부터 시작해야 할 것 같습니다.

기술적으로 죽은 상태라는 게 이런 거죠? 이런 표현이 유행하는 밈이라는 걸 알고 있는데, 정말 웃기죠? 네, 맞아요.

‍

헤이든 베일리오
켈빈, 켈빈, 미안해요. 아직 프레젠테이션을 공유하지 않은 것 같습니다. 괜찮아요. 테크 그렘린입니다. 이번이 시리즈의 첫 번째 발표입니다.

‍

켈빈 델 몬테
죄송합니다. 고맙습니다. 고마워요 네, 제가 할게요 네, 괜찮아요 이제 보실 수 있을 겁니다.

‍

헤이든 베일리오
여기까지입니다.

‍

켈빈 델 몬테
완벽합니다. 네 그럼, 네, 먼저... 아까는 볼 수 없었던 이 밈을 보여드렸는데, 기술 부채가 어떤 느낌인지 묘사하는 매우 인기 있는 밈입니다. 이런 느낌이지만...

항상 이런 상황은 아니죠? 집이 이렇게 완전히 엉망인 것도 아니고 상사가 새 창문을 추가할 수 있는지 묻고 있습니다. 집이 이렇게 망가졌는데 어떻게 창문을 추가할 수 있을까요? 하지만 확실히 이런 느낌입니다. 다음 슬라이드에서 이에 대해 조금 더 자세히 설명하겠습니다. 기술 부채가 실제로 무엇인지에 대해 알아보기 전에 먼저 이야기해야 할 것은...

기술 부채라는 용어를 만든 사람이 바로 여기있는이 신사분입니다. 워드 커닝햄 그는 1992 년에 기술 부채라는 용어를 만들었습니다. 저는 3 살이었고 그는 금융 상품을 개발하는 동안이 은유를 사용했지만 금융 상품은 Y 캐쉬라고 불렀습니다.

그는 이 비유를 사용하여 자신의 팀이 이 소프트웨어, 즉 와이캐시 소프트웨어를 계속 개발하면서 겪고 있는 일을 상사에게 설명했습니다. 개발이 진행됨에 따라 시스템에 대한 이해와 구축 중인 시스템과 구축 방식에 대한 나름의 의견이 발전하고 있었습니다.

그래서 처음에는 한 가지 방식으로 구축하기 시작했습니다. 그러다가 시간이 지나면서 새로운 패러다임, 더 유용하다고 생각되는 새로운 패턴을 발견했고, 그것이 자신이 하고 있는 업무 유형에 더 적합하다고 생각했습니다. 즉, 시간이 지남에 따라 코드를 작성하거나 애플리케이션을 설정할 때 그 순간에는 최적의 결정이었지만

‍

켈빈 델 몬테
6개월 후, 1년 후, 그들은 사람으로서, 엔지니어로서 진화했고, 소프트웨어도 진화했으며, 함께 일하는 방식도 진화했습니다. 새로운 툴이 생겼을 수도 있습니다. 이 기간 동안 수많은 일이 일어날 수 있습니다. 그리고 그들은 과거에 만들었던 코드를 다시 살펴봐야 하는 상황에 처했습니다.

그리고 그들은 진화했습니다. 그 코드는 더 이상 현재의 구축 방식으로는 표준이 되지 못했습니다. 소규모 팀으로 구성된 소프트웨어 개발팀이 있었습니다. 코드는 변하지 않았습니다. 그들은 변했습니다. 그들의 의견이 바뀌었죠. 이 때문에 기술 부채라는 용어가 생겼습니다. 그래서 그는 팀이 과거에 작성했던 오래된 코드로 돌아가서 상호 작용하고 있었기 때문이라고 설명했습니다,

이 코드와 상호 작용할 때 속도가 느려지는 것을 경험한 커닝햄 씨는 상사에게 이런 상황을 대출 이자를 내는 것과 같은 느낌이라고 설명했습니다. 이것이 바로 기술 부채의 기원입니다. 이제 잠시 시간을 내어 생각해 볼까요? 최초의 기술 부채인 OG 기술 부채는 무엇이 만들어졌을까요? 그것은 의견이었습니다.

그리고 팀에 대한 이해의 진화를 의미하죠? 기술 부채에 대해 지금 생각해보면 변하지 않았기 때문에 이 점을 고려하는 것이 중요합니다.

강력한 은유로 많은 사람들이 사용하고 있습니다. 30년 후, 33년이 지난 지금도 사람들은 이 단어를 사용하고 있습니다. 우리는 오늘 그것에 대해 이야기하고 있습니다. 정말 강력하죠. 그리고 그것은 많은 의견과 관련이 있습니다. 아시다시피 의견은 변합니다. 그리고 누구나 의견을 가지고 있습니다. 따라서 우리는 그 점을 염두에 두어야 합니다. 기술 부채는 소프트웨어를 구축하는 데 가장 좋은 접근 방식이 무엇인지에 대한 의견을 기반으로 합니다.

‍

켈빈 델 몬테
그렇다면 기술 부채의 원인은 무엇일까요? 기술 부채는 방금 이야기한 것처럼 팀원들의 이해가 진화하는 것입니다. 다음 중 어느 것이든 될 수 있습니다. 더 많은 것을 알게 되면서 이전에 내린 선택이 더 이상 의미가 없거나 지금 내리는 선택보다 덜 합리적일 수 있습니다. 단기적인 결정. 프로젝트를 구축 중인데 시간이 촉박할 수 있습니다. 시간이 부족합니다.

한 치 앞을 내다보거나 미리 계획할 수 있는 방식으로 프로젝트를 계획할 수 없습니다. 따라서 단기적인 결정을 내리게 되고 이러한 결정이 누적됩니다. 그리고 이러한 결정을 내리는 동안 기술 부채가 쌓이게 됩니다. 또한 경험이 부족해서 잘못된 아키텍처를 선택할 수도 있습니다.

아키텍처를 선택할 때 앱 전체에 큰 기술적 부채가 있는 경우 매우 흔하게 발생합니다. 또한 여기저기 지저분한 코드가 있고, 여러 기여자가 왔다 갔다 하는 패턴만 있을 수 있습니다. 중복, 때로는 테스트가 없는 경우도 있습니다. 이것도 기술 부채입니다. 그리고 기술 부채가 발생합니다. 팀 변경. 아주 크게요.

기술 부채가 발생하는 것을 고려해야 합니다. 따라서 여러분과 함께 일해 온 팀이 있을 수 있습니다. 여러분이 제품 소유자 또는 이해관계자이고 5년 동안 아무런 변화 없이 함께 작업해 온 개발자 팀이 있다고 가정해 보겠습니다. 이들은 프로젝트에 기술적 부채가 없다고 생각할 수 있습니다.

하지만 몇 명의 엔지니어가 떠나고 다른 환경에서 온 다른 엔지니어를 데려오는 경우가 있습니다. 이들에게도 다시 한 번 말하지만, 그것은 매우 의견에 기반한 것입니다. 이들에게는 수많은 기술 부채가 발생하고, 이들은 이를 지적하기 시작합니다. 이 기술 부채는 실제 기술 부채일 수도 있고, 그들의 의견일 수도 있습니다. 그리고 그것은 근거가 없죠? 실제 증거가 없는데, 이에 대해서는 나중에 조금 더 이야기하겠습니다.

‍

켈빈 델 몬테
물론 요구 사항 변경은 매우 흔한 일입니다. 개발자는 기능을 보강하기 위해 동일한 코드를 반복해서 변경하고, 이전 구현을 중단하지 않고 기능을 약간 변경합니다. 그리고 이러한 작업은 이동 중에도 매우 빠르게 이루어집니다. 따라서 이 코드 조각에서 반복이 일어나기 때문에 이 또한 단기적인 의사 결정과 관련이 있습니다. 많은 의사 결정이 이동 중에 이루어집니다.

특정 기능이나 소스 코드의 일부에 대한 기술 부채가 발생하게 됩니다. 기술 부채는 자연스러운 현상입니다. 이미 이에 대해 이야기한 적이 있습니다. 진화하는 것이죠? 따라서 앞으로 나아갈수록 기술 부채가 쌓이게 됩니다. 지구상에 존재하거나 앞으로 존재할 인간이나 인공지능이 만든 프로젝트 중 앞으로 나아가는 과정에서 일종의 기술 부채가 발생하지 않는 프로젝트는 전혀 없습니다.

그렇다면 이것이 여러분에게 어떤 영향을 미칠까요? 기술 부채는 프로젝트, 조직, 제품에 다양한 방식으로 영향을 미칩니다. 보안의 경우, 이 스파게티 코드나 제대로 유지 관리되지 않는 코드 어딘가에 숨어 있기 때문에 알지 못하는 취약점이 여러 개 있을 수 있습니다.

또한 가장 큰 불만 사항 중 하나인 속도 문제도 있습니다. 사실 이 용어는 속도 문제에서 비롯된 것이죠? 커닝햄 씨는 상사에게 우리가 이 오래된 코드와 상호작용할 때마다 속도가 느려진다고 설명했습니다. 그러니까 여러분의 팀은 엔지니어링 팀입니다.

유지 관리 방법을 잘 모르거나 유지 관리가 어렵다고 생각하는 오래된 코드와 상호 작용해야 하기 때문에 속도가 떨어집니다. 그리고 이것은 개발자의 사기를 떨어뜨린다는 다음 요점과 완벽하게 연결됩니다. 저는 애플리케이션 전체가 죽은 것처럼 보이는 환경에 처한 적이 있습니다. 그리고 버그가 발생하여 생산에 차질을 빚어 회사에 손실을 가져올 수 있기 때문에 변경을 두려워하게 됩니다.

‍

켈빈 델 몬테
스트레스를 많이 유발하고 솔직히 인생은 짧기 때문에 좋은 일을하고 싶고 스트레스를 많이 느끼지 않아도되기 때문에 개발자에게 많은 스트레스를주고 직장에서 일상 생활을 해치기 때문에 그런 환경에 갇혀 있기를 원하지 않습니다.

비즈니스 리더는 기술 부채를 단순한 엔지니어링 문제가 아닌 납품 리스크로 인식해야 한다는 말을 인용해 보았습니다. 이는 바이인을 얻는 방법의 일부이며, 향후 슬라이드에서 이에 대해 조금 더 자세히 설명하겠습니다.

‍

헤이든 베일리오
음.

‍

헤이든 베일리오
켈빈, 그 인용문 정말 마음에 들어요. 저도 그 말이 마음에 들어요. 저는 이 말을 좋아하는데요, 많은 엔지니어들이 부서 내 비즈니스 리더들과 이야기를 나누면서 소프트웨어 수명이 다해가는 것에 대한 우려를 떨쳐버리는 경우가 많기 때문이죠. 훨씬 더 큰 문제가 발생하면 그때 가서 해결책을 찾아야죠. 이것이 우리를 막고 있습니다. 이 오래된 소프트웨어와 기술 부채가 더 나은 제품이나 경험, 솔루션을 제공하는 데 걸림돌이 되고 있습니다. 그래서 저는 그 말이 정말 마음에 들었습니다. 훌륭하죠. 더 큰 문제입니다. 기술 부채는 엔지니어링 부서만의 문제가 아닙니다. 저는 그 말이 마음에 듭니다.

‍

켈빈 델 몬테
100 % 100 % 때로는 C 레벨 직원이나 경영진이 이해하도록 하는 것이 어렵지만 엔지니어나 제품 소유자 또는 제품 관리자인 PM인 우리뿐만 아니라 그들에게도 이익이 되기 때문에 그들을 이해시켜야 하죠? 우리는 우리를 도우려고 노력하고 있습니다 기본적으로 상황 유형

다음 슬라이드는 제가 가지고 있는 또 다른 밈인데, 이 밈은 개발자의 사기와 관련이 있죠? 기술 부채 때문에 회사를 떠나는 엔지니어들이 있습니다. 저는 이런 일이 반복해서 일어나는 것을 보았습니다. 그리고 때때로 재밌는 것은 그 기술 부채를 만든 사람이

대부분의 기술 부채는 이렇게 발끝으로 집을 빠져나가는 기술 부채인데, 기술 부채는 실제로 남아 있는 팀원 모두를 죽이는 것과 마찬가지입니다. 그리고 이것은 기술 부채가 아니라 기술 부채를 안고 떠나는 일부 직원들과도 관련이 있습니다.

‍

헤이든 베일리오
멋지네요.

‍

켈빈 델 몬테
네, 그럴 수 있습니다. 실제로 일어납니다. 그리고 이로 인해 사람들이 회사, 팀, 특히 엔지니어를 떠나게 됩니다. 그렇다면 어떻게 해야 할까요? 분명한 문제입니다. 회사, 제품, 직원, 팀 전체의 사기를 떨어뜨립니다. 그래서 몇 가지 일반적인 함정을 살펴보고자 합니다. 기본적으로 하지 말아야 할 일부터 시작해야 합니다. 제가 과거에 했던 일들입니다.

그리고 한 가지 주의를 드리고 싶은 것은 이런 일을 시도했다가는 잘못된 길로 접어들 수 있으니 절대 시도하지 말라는 것입니다. 따라서 기술 부채를 사후적으로만 해결하면 안 됩니다. 이는 매우 순진한 접근 방식이며, 팀원들에게도 그렇게 말하게 될 것입니다. 커리어에서 언젠가는 이런 말을 듣게 될 것입니다. 누군가는 이렇게 말할 것입니다.

또는 파일에 있는 부채 중 일부가 여기에 문제가 되는 부채가 포함되어 있는 경우 해당 파일을 수정하세요. 아니요, 이것은 작동하지 않습니다. 범위에 영향을 미치고 많은 문제가 있습니다. 실제로 작업하는 범위에도 영향을 미칩니다.

타임라인을 놓칠 수 있고, 그 다음에는 파일에서 발견한 다른 문제가 걱정되었습니다. 범위가 오염되는 거죠. 그런 일은 절대 원하지 않죠? 애자일 방식을 따를 때는 범위를 엄격하게 유지하고 기술 부채 문제가 발생할 수도 있고 발생하지 않을 수도 있습니다.

파일을 열거나 코드 섹션에서 작업할 때마다 여기에 표시됩니다. 따라서 이것은 여러분이 원하지 않는 일입니다. 사후 대응적인 접근 방식을 취하고 싶지 않으실 겁니다. 먼저 식별하고, 계획을 세우고, 실제로 식별하고, 기록하고, 팀원들의 동의를 얻는 등 사전 예방적인 접근 방식을 취해야 합니다.

‍

켈빈 델 몬테
그리고 절대 반응형으로 하지 않는 것은 나쁜 접근 방식입니다. 그 다음으로는 가시성이 없다는 것인데, 리액트를 사용하는 경우, 반응형으로 사용하는 경우 이것도 문제입니다. 나만, 또는 코드를 검토한 사람만 이 문제가 있었고 수정되었다는 것을 알 수 있는 것처럼 말이죠. 팀원들은 알지 못합니다. 추적할 방법이 없습니다. 따라서 가시성이나 우선 순위가 정해져 있지 않습니다.

이것 또한 여러분이 하고 싶지 않은 일입니다. 그리고 여기 절대 하지 말아야 할 것의 왕이 있습니다. 바로 대규모 리팩터에 과도하게 헌신하는 것입니다. 저도 과거에 이런 일을 해본 적이 있습니다. 특히 경력 초기에 경험이 적고 열정이 넘쳤던 시절에 이런 일을 몇 번 해본 적이 있습니다. 점점 더 순진해졌죠.

최신 기술을 사용하고 싶었고, 여러분과 여러분의 동료들을 위해 비용을 지불하고 여러분의 가족, 고객이 사용하는 많은 것들을 보호하는 비즈니스에 대해 크게 생각하지 않고 가능한 한 빨리 하고 싶었습니다. 이것이 중요한 것입니다. 지금 고려하고 있는 것은 대규모 리팩터링이 아닙니다. 따라서 이 대규모 리팩터링이 성공했다고 가정해 보겠습니다.

실패할 확률이 훨씬 더 커집니다. 그리고 여러분이 미래에 할 수 있는 이 거대한 리팩토링을 지지했던 사람들조차도 이 거대한 리팩토링의 중간쯤에서 일상 생활이 정말 싫기 시작하면 여러분을 지지했던 사실을 잊어버릴 것입니다. 그리고 그들이 겪고 있는 모든 고통 때문에 이스라엘이 이집트를 떠났을 때처럼 이집트는 정말 좋았다고 뒤돌아보게 될 것입니다.

물론 사막 한가운데서 거의 죽어가고 있고 물도 찾을 수 없죠. 물론 뒤돌아보면 이집트는 정말 멋진 곳이었죠? 하지만 이런 일이 벌어질 겁니다. 너무 많아요. 조금 지연됩니다. 모든 사람이 이 대규모 리팩터링에 전념하고 있기 때문에 기본적으로 팀의 기능 출시가 중단될 것입니다.

‍

켈빈 델 몬테
모든 확률이 불리하게 작용할 가능성이 높지만, 이 대규모 리팩터링을 일으킨 장본인이 바로 여러분일 가능성이 높습니다. 그리고 그 시기를 놓치더라도 큰 성과입니다. 이틀이나 사흘만 놓치면 됩니다. 모두가 너무 많은 고통을 겪었고 비즈니스가 위험에 처한 것은 모두 당신이나 이 대규모 리팩터를 지원한 사람 때문이었습니다. 그렇게 하면 안 됩니다.

정말입니다. 그리고 혹시라도 이 방법이 팀의 유일한 실행 가능한 방법이라면 분명 그럴 만한 이유가 있을 것입니다. 대부분의 경우 이런 식으로 진행하지 않는 것이 좋습니다. 그리고 이것은 제가 커리어를 통해 배운 것입니다. 지옥으로 가는 길은 좋은 의도로 포장되어 있다는 말을 여기에 인용합니다. 여러분은 이 리팩터링에 대해 좋은 의도를 가지고 있을 수 있습니다.

하지만 이것은 최신 기술을 사용하고자 하는 여러분이나 여러분의 친구에 관한 것이 아닙니다. 여러분의 팀에 관한 이야기입니다. 앞으로 나아가기 전에 합의를 얻어야 합니다. 여러분의 좋은 의도뿐만 아니라 모두가 동의하고 동의할 수 있는 체계적인 방식으로 일을 하고 있는지 확인해야 합니다. 그렇지 않으면 끔찍하고 끔찍한 길로 가게 될 것입니다.

자, 이제 효과가 있는 전술로 넘어가 보겠습니다. 제가 시도해 본 결과 정말 효과가 좋았습니다. 방금 이야기한 것과는 정반대입니다. 자세한 내용은 나중에 설명하겠지만 여기서는 여기까지만 나열해 보겠습니다. 깊이를 추적하고, 부채를 가시적으로 파악하고, 추정하고, 경영진의 동의를 얻은 다음 실행하는 것이 이 글의 개념입니다. 약간 미묘한 실행 방법이지만 잠시 후에 이에 대해 설명하겠습니다.

그리고 필요하다면 외부의 도움을 받아야 할 수도 있습니다. 부끄러워할 일이 아닙니다. 사실 우리 회사 입장에서는 직원들을 위한 일종의 특혜이기도 합니다. 이에 대해서도 잠시 후에 이야기하겠습니다. 좋아요. 부채를 가시적으로 추적합니다. 그래서 제가 여러분을 위해 이 글머리 기호를 여기에 넣었습니다. 따라서 목소리를 높여야 합니다.

‍

켈빈 델 몬테
팀원 전체가 부채에 대해 목소리를 높여야 합니다. 팀에서 해결해야 한다고 생각되는 것이 있다면 무엇이든 이야기해야 합니다. 팀 세션에서 이 문제를 제기하세요. 스탠드업이든, 회고 시간이든, 백로그 정리 시간이든, 이런 이야기를 시작할 수 있습니다. 여기에서 할 수 있는 공간을 찾아보세요...

이러한 사항 중 몇 가지를 팀에 알려야 합니다. 팀과 함께 알고 싶은 것은 처음부터 의견 요소와 관련이 있다는 것입니다. 이 기능이 죽었다는 의견이 있을 수 있지만, 다른 동료가 왜 이것이 죽지 않았는지 설명해 줄 수도 있고, 문서를 읽어보지 않았을 수도 있습니다. 코드의 이 부분과 왜 이런 식으로 작성되었는지 잘 모를 수도 있습니다. 그리고...

삶을 더 편하게 만들어줄 문서가 있습니다. 아직 죽지 않았을 수도 있습니다. 따라서 먼저 팀에서 죽은 것으로 판단하고 죽은 것으로 표시할 수 있는 공식 부채인지에 대한 합의를 얻어야 하겠죠?

이러한 가시성을 확보하고 개선하려면 생각해 보세요. 그것은 여러분의 보드에 있어야 합니다. 백로그 어딘가에 있어야 합니다. 백로그 정리 세션에서 논의되지 않으면 잊혀질 것입니다. 엔지니어로서, PM으로서, 프로젝트 관리자이든 프로그램 관리자이든, 여러 프로젝트에 시간을 할애하고 있을 수도 있습니다.

사용하거나 제품 소유자, 예를 들어 제 생각에는 모든 사람, 심지어 일부 경영진까지 백로그 도구나 프로젝트 관리 도구가 무엇이든 살펴보고 있습니다. Jira, Santa, Trello, Monday 등 어떤 도구든 상관없습니다.

‍

켈빈 델 몬테
가시성이 높습니다. 기술, 미안하지만 기술 부채는 반드시 여기에 기록해야 하고 실행 가능한 방식으로 기록해야 합니다. 따라서 실제로 부채가 무엇인지 문서화할 때는 프로젝트 관리자나 기술 리드와 협력해야 합니다.

아니면 본인이 직접 하는 경우 PM과 협력하여 이러한 것들을 기록하고 실제로 실행 가능한 모든 정보를 입력해야 하겠죠?

한 번에 끝낼 필요는 없지만 백로그 그루밍이 바로 이 작업을 위한 것입니다. 세부 사항을 입력한 다음 진행하면서 그루밍하세요. 에픽을 만들어서 실행 가능한 것으로 만들고 분리하세요. 저는 과거에 JIRA나 다른 도구에서 에픽을 만드는 작업을 해본 적이 있습니다. 그리고 그것은 영원히 실행되는 에픽이 아닌, 알다시피 에픽이 있는 에픽입니다. 한 가지 문제를 해결할 수 있는 제한된 양의 작업이 포함된 에픽이죠.

그렇게 취급할 수 있습니다. 따라서 이전에 레이블을 사용했던 다른 환경, 즉 JIRA 레이블을 많이 사용하는 매우 레이블이 많은 환경에서는 어떤 방식으로든 정리해 두어야 합니다. 전에도 사용해 본 적이 있습니다. 어떤 방식으로 정리하든, 정리된 내용이 팀원들에게 잘 보이고 팀 세션에 표시되는지 확인하세요. 가시성이 떨어집니다.

를 실제로 우선순위를 정하고 작업할 수 있는 것으로 바꾸세요. 보이지 않는 것은 고칠 수 없습니다. 눈에 보이지 않는 것은 마음에서도 사라집니다.

‍

켈빈 델 몬테
좋아요, 먼저 비용 추정에 대해 이야기해 보겠습니다. 이미 부채가 어느 정도 보이고, 팀에서 이에 대해 이야기하고 있으며, 백로그 정리 세션에 시간을 투자하고 있다는 것을 알고 있습니다.

스토리 포인트를 작성하거나 다른 종류의 추정을 할 수도 있지만 모든 것이 일종의 비용으로 귀결되죠? 따라서 이를 통해 팀의 속도를 늦추고 있다고 생각되는 중요한 작업을 수행 할 수 있으며,이를 만들고 싶고 경영진에게 발표하고 싶을 때 다음에 이야기 할 내용입니다. 경영진이 중요하게 생각하는 것은 다음과 같습니다.

하고자 하는 일을 실행하는 것이 얼마나 실현 가능한가요? 그리고 그들은 숫자로 생각하기를 원합니다. 이 부채에 대해 어떤 조치를 취하는 것이 합당한지 따져보고 싶어 합니다.

아니면 미래로 미룰 수 있는 일인지도 고려해야 합니다. 따라서 제때 또는 경영진이 이해할 수 있는 추정치를 통해 해당 비용을 제공해야 합니다. 팀과 협력하고 프로젝트 관리자와 협력하여 이러한 기술 부채 사례를 정리하고 일종의 추정치를 제시해야 합니다.

물론 이 과정을 거치면 경영진에게 발표할 수 있는 멋진 기술 부채 서사시 또는 몇 가지 서사시를 작성할 수 있습니다. 그런 다음 실제로 작업을 시작할 수 있는 승인과 이 작업을 언제 어떻게 시작할 수 있는지에 대한 일종의 지침인 바이 인을 얻을 수 있습니다. 여기에 제가 제시한 몇 가지 예는 다음과 같습니다.

‍

켈빈 델 몬테
이 버그가 존재하는 이유는 과거에 저에게 이런 일이 발생했을 때 '왜 이런 버그가 발생했을까'라는 생각이 들었던 적이 있었기 때문입니다. 여기에는 단위 테스트가 없었기 때문에 버그가 발생했습니다. 우리가 계속 요청해왔던 인텐트 테스트 커버리지가 없었기 때문입니다. 그러니 그 문제를 제기하세요. 이것이 바로 기술 부채, 기술 부채가 여러분과 여러분의 수익에 영향을 미치는 이유입니다. 장담하건대, 그들은 기술 부채를 훨씬 더 심각하게 받아들일 것입니다.

를 가져와야 합니다. 이 시점에서는 비용과 관련된 작업 스택을 완전히 실행할 수 있게 되므로 기능 출시를 요청하는 동안 필요한 경영진의 동의를 얻기가 훨씬 쉬워집니다. 여러분의 고충, 엔지니어링의 고충, 프로젝트 관리의 고충을 경영진이 이해할 수 있는 것으로 바꿔야 합니다. 회사에 수익을 창출하는 기능을 출시하는 데 따르는 속도, 위험, 리스크, 알기, 위험.

마지막으로, 이제 승인을 받았으니 실제로 어떻게 실행하고 앞으로 나아가야 하나요? 경영진으로부터 앞으로 나아갈 수 있도록 승인을 받았습니다. 이제 승인을 받았으니 경영진의 승인이 느슨해졌을 수도 있습니다. 그들은 당신에게 어떤 지침도 주지 않았고 당신이 원하는 대로 하도록 허용했습니다. 이것은 절대적으로 해야 할 일과 하지 말아야 할 일과 관련이 있습니다.

대규모 리팩터링은 하지 마세요. 이렇게 하세요, 작가 여러분. 고등학교 때 미국 정부나 의회에는 통과를 앞둔 큰 법안에 첨부되거나 많은 작업이 들어간 작은 법안을 작성하는 작가라는 개념이 있다는 것을 배웠습니다.

그리고 그들은 때때로 첨부된 큰 청구서와는 아무 관련이 없는 작은 청구서를 첨부합니다. 따라서 기술 부채도 이러한 방식으로 접근하면 각 스프린트마다 몇 개의 주기를 예약하는 것입니다. 이렇게 하면 기능을 계속 제공하면서 동시에 기술 부채를 줄일 수 있습니다. 가끔은 이렇게 할 수 없는 경우도 있다는 것을 알고 있습니다. 이렇게 할 수 없을 수도 있지만 이것이 최적의 접근 방식이어야 합니다.

‍

켈빈 델 몬테
작은 단위로 조금씩 지속적으로 개선하세요. 시간이 지남에 따라 100%의 효과가 나타날 것입니다. 6개월이든 1년이든 시간이 지나면 그 차이를 느낄 수 있을 것입니다. 계속해서 기능을 출시하는 동안 앱은 훨씬 더 건강해질 것입니다. 그리고 모두가 행복해집니다. 리드인 여러분은 행복할 것입니다. 리더로서 실제로 조치를 취하고 있거나 팀으로서 조치를 취하고 있기 때문에 팀원들도 행복합니다.

기능을 출시하기 때문에 이해 관계자가 만족할 것입니다.

그래서 마지막 제안을 드리자면, 필요한 경우 외부의 도움을 받는 것입니다. 저희 개발팀에서는 이것이 가장 중요한 일입니다. 다음 슬라이드에서 정확히 어떤 일을 하고 있는지 말씀드리겠지만, 이것이 저희의 주요 업무입니다. 따라서 저희 같은 회사에 기술 부채에 대한 도움을 요청할 수 있습니다.

팀이 기능을 출시하는 동안 저희는 그 부분에 집중할 것입니다. 이는 대규모 업그레이드나 지원 종속성 지옥에 빠져 있거나 다른 기술이나 다른 언어로 심층적인 재작업을 해야 하는 경우에 매우 유용합니다. 저희가 도와드릴 수 있으며 외부의 도움을 받을 수도 있습니다. 이는 회사에서 제공하는 혜택과도 같기 때문에 개발자의 사기를 높여줍니다. 여러분은 엔지니어입니다. 개발자는 계속 기능을 출시할 수 있습니다.

회사가 그다지 흥미롭지 않은 일을 외부의 도움을 받아 처리하는 것, 즉 기술 부채를 해결하는 것이죠. 따라서 전문가를 영입할 때는 항상 이 점을 고려하는 것이 매우 중요합니다. 저희 히어로 데브즈에 대해 조금 말씀드리고 싶습니다. 저희는 2018년부터 시작되었습니다.

‍

켈빈 델 몬테
저희는 포춘지 선정 500대 기업, 포춘지 선정 100대 기업 등 800개 이상의 고객을 보유하고 있습니다. 저희는 수명이 다한 소프트웨어를 다양한 역량으로 지원하는 아웃오브지원을 전문으로 합니다. 저희는 정말 훌륭한 팀을 보유하고 있습니다. 우리는 오랫동안 이 일을 해왔습니다. 다음은 우리와 함께 일하는 몇 가지 회사입니다. 이것은...

제 동료들이 말하는 기분 좋은 슬라이드는 우리가 사업을 하고 있다는 것을 보여줍니다. 저희는 이 모든 회사들과 함께 일하며 마이그레이션을 도왔습니다. 또한 NES, 즉 네버엔딩 서포트를 통해 이러한 회사를 지원하는 또 다른 방법이 있습니다.

제품 라인입니다. 줄여서 NES라고 부릅니다. 따라서 이것은 다른 방식으로 기술 부채를 해결합니다. 예를 들어 AngularJS Twangular 마이그레이션을 예로 들어보겠습니다. 많은 팀들이 2010년에 앱을 개발했다고 가정해 보겠습니다,

2011년에는 아마도 AngularJS 사용하고 있었을 것입니다. 하지만 제품을 완성했을 때는 이미 Angular 전환한 후였을 것입니다. 따라서 Angular 마이그레이션할 리소스가 없었을 수도 있습니다. 그래서 어떻게 해야 할까요? 이제 지원을 받을 수 없게 되었습니다. 네버엔딩 서포트는 마이그레이션을 도와드릴 수 있지만 실제로 마이그레이션할 필요는 없습니다.

여기에 표시된 라이브러리를 비롯한 많은 라이브러리에 대한 지원을 확대할 예정입니다. 문의해 주시면 더 많은 지원을 제공할 수 있습니다. 그리고 사용 중인 소프트웨어나 라이브러리의 수명이 다한 후에도 지원을 계속 받을 수 있도록 도와드릴 수 있습니다. 이렇게 하면 사용 중인 기술이 지원되지 않는 강제적인 기술 부채도 확실히 해소할 수 있습니다. 따라서 일종의 부채가 생기는 셈이죠. 그래서 네, 저희는...

‍

켈빈 델 몬테
지속적으로 제품을 확장하고 있으며, 네, 헤이든은 작년에 몇 개의 제품을 출시했나요?

‍

헤이든 베일리오
작년에 저희는 20개가 넘는 새로운 NES 제품을 출시했습니다. 그 중 많은 부분이 고객에 의해 주도되었고, 이미 Interlife 라이브러리를 통해 도움을 받고 있는 사람들이 우리에게 찾아와서 우리도 지원이 필요하다고 말하는 것을 보고 정말 멋졌다고 생각합니다. 여러분도 그렇게 해주실 수 있나요? 그래서 현재 고객들이 주도하는 비즈니스나 신제품 개발이 많이 이루어지고 있습니다.

네, 새로운 요구사항에 대해 항상 귀를 열어두고 있습니다. 물론이죠.

‍

켈빈 델 몬테
네, 많은 분들이 관심을 가져주시고 물론 제가 히어로 데브즈를 고객으로 이용하고 있는데 대규모 마이그레이션을 진행해야 하는 상황이라면 정말 큰 도움이 될 것입니다. 실제로 아무것도 할 필요가 없으니까요. 서비스 수명이 종료되더라도 기능을 계속 출시할 수 있습니다. NES를 구매한 시점에 더 이상 수명이 다한 소프트웨어가 아니기 때문에 수명이 다한 소프트웨어를 유지 관리하는 동안에도 말이죠.

마지막으로 팁과 요점을 알려드리겠습니다. 작게 시작하여 기술 부채를 가시화하세요. 가능한 한 많은 것을 제공하세요. 필요한 경우 외부의 도움을 받습니다. 그리고 부채 제로를 쫓지 마세요. 이것은 정상입니다. 이는 소프트웨어를 구축하는 과정에서 자연스럽게 발생하는 부분입니다. 항상 존재할 것입니다. 관리만 잘하면 됩니다. 시간 내주셔서 감사드리며, 헤이든에게 마무리 질문을 넘기겠습니다.

‍

헤이든 베일리오
네, 정말 감사합니다, 켈빈. 개요를 설명해 주셔서 감사합니다. 기술 부채는 확실히 우리가 이야기한 모든 사람들이 겪고 있는 문제이며 모든 곳에 만연해 있죠? 기술 부채에서 벗어날 수는 없습니다. 오픈소스를 도입하면 기술 부채를 도입하는 것과 같다는 말이 있듯이, 기술 부채를 도입하면 오픈소스를 도입하는 것과 같다고 생각합니다. 바로 그런 것이죠. 미래의 기술 부채를 받아들이는 것이죠. 그리고 훌륭한 실제 인사이트를 제공해주신 것 같습니다. 녹취록은 조만간 YouTube에 게시할 예정입니다. 참여해주신 모든 분들께 감사드립니다.

7분 정도 남았으니 질문이 있으신 분들은 이 웨비나에 초대해 주신 분들에게 연락하시거나 켈빈에게 직접 연락해 주세요. 켈빈, 사람들이 이에 대해 궁금한 점이 있을 때 연락하기 좋은 곳이 어디인가요?

‍

켈빈 델 몬테
이제 저에게 이메일(kelvin.herodevs.com)을 보내주세요. 기꺼이 답변해드리고 연락드리겠습니다.

‍

헤이든 베일리오
헤로도토스닷컴의 켈빈. 참여해 주신 모든 분들께 감사드립니다. 보안을 유지하면서 기술 부채를 어떻게 처리할지 계획을 세워보세요. 평안하세요, 영웅 여러분.