기술 부채의 6가지 유형: 기술 부채는 부담이 아니라, 성공을 위한 전략적 수단

• 기술 부채를 전략적 수단으로 보기 위해 필요한 것
  • 기술 부채에 대한 부정적인 가정을 인식하고 해결하기
  • 기불 부채의 6가지 유형 분류 및 차별 대응
  • 기술 부채 규모 파악
  • 기술 부채의 우선순위를 결정하는 법

How to Not Manage Tech Debt

• 기술 부채를 잘못 관리하게 만드는 4가지 가정들

가정 #1 : 기술 부채 = 나쁜 것

• 모든 기술 부채를 '나쁜' 것으로 분류해서는 안됨
• 각각의 이름을 지정하고 고통의 크기를 측정해서 기술 부채들을 분류하는 것이 훨씬 좋음
• 어떤 기술 부채들은 가지면 좋고, 모든 팀은 기술 부채를 가져야 함
• '좋은 기술 부채를 가졌던' 트위터의 사례 : 공개 스토리지를 사용하다가, 자신들만의 분산 DB인 Manhattan을 개발
• '기술 부채 = 나쁜 것' 이라는 가정에 대응하기 위한 질문들
  • 지금 이 기술 부채를 쌓고, 다음 달에 해결하면 어떤 걸 얻을수 있나요?
  • 어떤 상황이라면 경영진이 이 기술 부채에 관심을 가질까요? CTO가 경영진에게 피치하는데 도움이 되는 정보를 어떻게 전달해야 할까요?
  • 이 이니셔티브가 어떻게 회사의 더 큰 비전이나 전략적 방향으로 이어질 수 있나요?

가정 #2 : 모든 기술 부채 = 복잡한 작업

• 기술 부채뿐 아니라 모든 어려운 작업과 마찬가지로 복잡한 일을 처리하는데에는 여러가지 방법이 있음
• 특히 기술 부채의 경우 Defined/Undefined(정의된/정의되지 않은) 작업에 접근하는 방법이 있음
  • Defined = 작업에 시작과 끝이 있음
  • Undefined = 작업의 시작은 있지만, 끝이 분명하지 않음
• 기술 부채 = 복잡하다는 가정에 대응하려면
  • 당면한 기술 부채가 Defined 인지 Undefined 인지 명확히 할 것
    • Defined의 경우는 작업완료에 걸리는 예상시간을 이해하고 약간의 버퍼시간을 주기
    • Undefined의 경우는 왜 일이 복잡하고 명확한 종료날짜가 없는지 이해할수 있도록 불분명한 부분을 나열하고 이해관계자에게 전달하여 앞으로 나아갈 수 있는 최선의 방법에 대한 의견을 구할 것
  • Undefined 기술 부채를 소화하기 쉬운 작업 부분들로 나눠서 덜 복잡하게 만들기
    • 복잡한 대규모 작업에서 복잡하지만 실행 가능한 작은 작업으로 전환하면, 팀이 스프린트/분기별 정해진 기간 동안 기술 부채의 일부를 해결하기 위해 더 동기부여 받을 수 있음
• '기술 부채 = 복잡한 작업' 이라는 가정에 대응하기 위한 질문들
  • 시스템에 대해서 잘못된 가정들은 ?
  • 이 분야의 경험자나 익숙한 사람을 데려온다면, 꼭 물어봐야할 질문들은?
  • 우리팀에 이 작업을 수행하는데 필요한 적절한 인력과 지식이 있나요? 그렇지 않다면 정보 재배치를 어떻게 고려해야 하며, 언제가 이 문제를 해결하기에 가장 이상적일까?
  • 이 기술 부채의 복잡성을 전혀 이해하지 못하는 사람에게 설명하는 가장 좋은 방법은?

가정 #3 : 기술 부채 ≠ 제품 작업

• 조직들이 제품 작업이 어떻게 회사 메트릭을 향상시킬지에 대해 명확함
• 보통 여기에 기술 부채에 대해서는 누락되어 있음
• 적시에 기술 부채를 해결하는 것은 즉시 정량화 하지 못하더라도, 회사의 성장을 촉진하는데 중요할 수 있음
• 기술 부채 ≠ 제품 작업 이라는 가정에 대응하려면
  • 기술 부채의 특정 영역이 메트릭과 직접 연결되지 않더라도, 어떤 사용자/제품 경험에 도움이 될 수 있는지 광범위하게 생각할 것
  • 기술적 이점을 강조하는 대신 사용자와 제품에 주는 이점을 동등하게 강조하면, 다른 사람들에게 팀이 왜 이 작업에 관심을 가져야 하는지를 쉽게 이해할 수 있음
  • 비즈니스 리드와 기술 리드가 같은 것을 이해하고 있는지(on the same page) 확인하는데 시간을 할애할 것
• '기술 부채 ≠ 제품 작업' 이라는 가정에 대응하기 위한 질문들
  • 지금 작업을 진행해야 하는 가장 중요한 한가지 이유는 ?
  • 이 일의 임팩트를 이해해야 하는 사람은 누구? 왜 그들이 이것에 관심을 가져야 할까?
  • 내가 말하고자 하는 것은? 이게 이해관계자가 듣고 싶어하는 내용과 일치 하나? 만약 그렇지 않다면 그들의 문제를 어떻게 해결할수 있을까?
  • 나 또는 팀에서 합리적 vs. 훌륭한 결과라고 생각하는 것은 ?
  • 예상 결과에 대해서 지나치게 약속하고 있는걸까? 결과에 대해서 훌륭한 것과 좋은 것으로 나눠서 기대수준을 레벨링 할수 있을까 ?

가정 #4 : 개인의 고통 = 조직의 고통

• 기술부채와 가까운 엔지니어들은, 기술 부채를 처리하는게 개인적으로 고통스럽다고 정기적으로 반복해서 이야기함
• 직원은 마치 세상의 끝인 것 처럼 느끼겠지만, 조직의 나머지 사람들을 같은 고통을 느끼지 못함
• 경력 초기단계의 사람들에게 일반적이고, 보통은 더 넓은 전략적 콘텍스트에 대한 부족으로 생기는 것
• 개인의 고통 = 조직의 고통 이라는 가정에 대응하려면
  • 기술 부채중 우선 순위가 높은 영역에 닿으면, 이게 개인 또는 조직 수준의 페인포인트 인지 잠시 살펴 볼 것
    일반적으로 조직 수준의 문제점은 어떤 식으로든 고객이나 비즈니스에 직접적인 영향을 줌
  • 당신보다 더 많은 조직 컨텍스트를 가진 사람의 시각으로 생각해 볼 것. 다른 팀의 누군가에게 설명하는 것도 가능
• 개인의 고통 = 조직의 고통 이라는 가정에 대응하기 위한 질문들
  • 이 기술 부채를 분류하고 해결함으로써 얼마나 많은 팀들이 이익을 받습니까 ?
  • 회사가 기술부채 작업을 맡은 사람을 언제 인정하거나 보상해줬나요? 어떤 유형의 기술 부채였고 그 당시에 왜 필요했나요? 그 사람이 그 작업을 어떻게 포지셔닝했는지 얘기해볼 수 있나요?
  • 내 엔지니어링 매니저가 기술 부채 작업의 가치를 이해하고 있습니까? 그가 퍼포먼스 리뷰중에 이 작업에 대한 나의 기여를 advocate 해 줄까요?

기술 부채의 6가지 유형

• Maintenance dept(유지 관리 부채)
  • 팀이 기술에 대한 업데이트를 따라가지 못할 때
  • 실험 시작 / 피처 롤아웃 / 배포 취소 등 이후에 데드코드를 삭제하지 않는 것이나, 라이브러리 업데이트, 컨텍스트 코드에 대한 주석달기, 구현 결정에 대한 문서화 등을 업데이트 하지 않는 것도 포함됨
  • 예) 'log in with Spotify' 기능을 실험하다가, 취소했 때 해당 코드를 삭제하지 않음
• Developer efficiency debt(개발자 효율성 부채)
  • 회사가 제품에 대한 적절한 테스트, 모니터링, 경고 시스템이 없는 경우
  • 엔지니어링 워크플로우가 매우 비효율적이고, 배포/빌드에 몇시간/몇일씩 걸리고, 개발자가 프로덕션에 들어가기전에 기술적 문제를 감지하지 못하는 일반적인 유형의 부채
  • 예) 조직이 1년간 15명에서 50명으로 증가하면서, 너무 많은 실험들이 진행됨. 프로덕션에 발견한 버그 수정 릴리즈가 2-3개 밀려있음. 구매 경험을 위한 새로운 테스트는 그 뒤로 뒤쳐지게 됨
• Stability debt(안정성 부채)
  • 조직에 다양한 유형의 기술적 부채가 쌓이면서 인프라의 안정성에 영향을 미칠 때
  • 온콜을 사전에 관리하는 게 아니라, 문제 발생시에 해당 전문가를 사후에 불러오거나, 팀 전체가 온콜하게 되는 시나리오가 발생
  • 이는 엔지니어와 온콜 로테이션 팀에는 큰 골칫거리지만, 회사의 나머지 사람들은 문제를 파악하고 설명하는 것 자체가 불가능
  • 안정성 부채는 제품의 신뢰성에도 영향을 미쳐서, 고객이 직면하게 되는 문제를 발생시키기도 함
  • 예) 모바일 팀에 iOS 개발자가 더 많아서 Android 앱도다 iOS를 우선시. 결과적으로 Android 앱에는 비즈니스에 중요한 흐름에 대한 제품 가이드라인이 부족하고, 써드파티가 초기에 개발했던 약점(Kryptonite) 코드도 존재. 이로 인해 Android 사용자가 예전 기능을 접근할때 크래쉬가 나면서 구글 플레이 평가가 안좋아짐
• Security debt(보안 부채)
  • 무차별 암호 대입, 데이터 유출 등 보안 취약성이 있는 기술 스택을 사용하는 경우
  • 사람은 발생 가능한(또는 발생하지 않을) 일들을 계획하고 평가하는게 어렵기 때문에 많은 조직에 보안 부채가 발생
  • 예) 회사 내부 프로세스 문제로 업데이트를 제때 하지 못해서 알려진 취약점을 패치하지 못해 고객 개인 데이터 유출 (작은 회사부터 1.4억명이 영향받은 Equifax 같은 회사까지)
• Technical product debt(기술 제품 부채)
  • 제품에 부정적인 영향이 눈에 띄게 나타날 때
  • 가장 쉽고 해결하기에 좋은 부채로 사용자에게도 영향이 있고, 조직내의 모든팀이 판매/매출에 영향을 주는게 보임
  • 예) 사용자가 제품내에서 특정 작업을 하는데 몇초씩 걸림. 이는 다양한 부채로 발생가능 하지만, 사용자의 핵심 제품 경험에 영향을 미침
• Decision debt(의사 결정 부채)
  • 이전의 기술적 결정이 X% 틀렸거나, 범쉬, 시간, 자원 면에서 절충했기 때문에 그 결정에 대한 비용을 지불 하는 것
  • 기술 부채의 가장 일반적인 형태
  • 예) 웹사이트에서 특정 실험을 위해 써드파티를 사용. 몇년간 엄청 성장하면서 이제 수백만명의 사용자가 방문함. 결과로 기술팀, 데이터팀, 제품팀 모두가 복잡한 실험을 할때 마다 고난을 겪는 중.
    이 것은 팀이 써드파티와 자체 개발 중에서 트레이드 오프 결정을 내렸기 때문에 의사 결정 부채가 발생. 당시에는 올바른 것이었겠지만 이제는 영향을 받게 됨

기술 부채 규모 결정하기 : Acute vs Systemic

• 기술 부채의 종류를 이해하고 나면, 얻게될 것과 비교할 수 있게 비용 규모를 결정해야 함
• 팀이 '기술부채에 대해 작업할 시간이 언제 생길까요?' 라고 질문했을 때 시간, 생각, 노력 관점에서 그게 작은지 큰지 알기 어려움
• Acute(급성) 기술 부채
  • 상대적으로 작은 기술 부채
  • 예) 새로운 기능 제공을 위해, 사용규모가 작은 플랫폼/브라우저를 위한 작업은 건너뛰었음. 다른 일이 없다면 1일내에 쉽게 추가 가능
• Systemic(쳬계적) 기술 부채
  • 큰 것부터 거대한 규모의 기술 부채
  • 예) CTO/창업자가 5년전에 제품(간접적으로 기술)에 대한 결정을 내렸고, 그 기반으로 노력했음. 이것을 바꾸면 다양한 것들에 영향을 주게 됨.
    이 기술 부채는 쉽게 해결 불가능하고, 변경하는데에 몇달에서 몇년이 걸릴 수 있음

전략적으로 기술 부채의 우선순위 지정하기

• 유연하게 고려하고 평가하는 방법
  • Confidence : 이게 중대한 문제로 이어질 가능성이 높은가? 낮음/높음
  • Time : 언제 이게 문제가 될까 ? 급하지 않음/급함
  • Impact to User : 이걸 하지 않으면 사용자 경험을 해치는 속도/품질 문제가 발생하게 될까 ? 낮음/높음
  • Sequence : 이게 중요한 마일스톤에 도달하는 것을 방해하는가? 작은 영향/블록
  • Accumulated debt : 얼마나 많은 부채를 이미 축적하기로 결정했는가? 작음/많음

회사 성장 단계에 따른 전략적 기술 부채 포트폴리오

• Traction :
  • Product-Market fit 이전
  • 정확성,안정성,프로세스 보다 속도에 대한 엔지니어링 결정을 내려야함. 큰 규모의 개발자 효율성 부채
  • 일반적으로 Django, Rails, PHP 등 풀 스택 프레임워크를 선택해서 빠르게 개발하는 것을 의미
• Inflection :
  • PMF 의 징후가 있고, 제품이 확장 가능한 루프로 전환되는 시점
  • 팀이 일부 프로세스가 필요하다는 것을 깨닫고(개발자 효율성 부채가 해결되기 시작), 아직 내부 프로세스와 사용자 경험사이에서 균형을 조절하고 있으므로 기술 제품 부채가 증가함
• Scale :
  • 기업의 초성장기(hyper-growth)
  • 내부의 프랙티스및 프로세스 와 사용자경험 사이의 균형을 찾아가면서, 기술 제품 부채와 개발자 효율성 부채가 감소하고 안정화 되기 시작
  • 매우 빠른 성장의 결과로 보안 부채, 유지 관리 부채, 의사 결정 부채들이 증가
  • 테스트 자동화, 배포 시스템, 모니터링 및 경고, 로깅 및 인스트루먼테이션, 테스트 및 스테이징, ETL 등에 많은 변화와 수정이 일어남
• Expansion :
  • Saturation 의 시작. 비즈니스가 더 성숙해짐
  • 많은 양의 오래된 코드와 결정들로 인해서 유지 관리 부채 및 의사 결쟁 부채가 계속 늘어남
  • 팀이 성장을 위한 새로운 기회를 모색하면서, 개발자 효율성 부채가 다시 증가하기 시작
  • 기술 제품 부채, 보안 부채, 안정성 부채들은 이전 기간 이후에 밸런스가 잡혀가는 중

기술 부채 포트폴리오 관리를 위한 팁

• 만들어지는 기술 부채를 줄이기 위한 프로세스
  • 기술 부채를 축적하는게 전략적이긴 하지만, 초기부터 프로세스 구현을 통해 기술부채가 생성되지 않도록 하는게 맞을 때도 있음
  • 더 많은 엔지니어가 합류하면서 개발자 효율성 부채가 감소해야 하는 Inflection 및 Scale 단계가 특히 그러함
  • 개발자 효율성 부채가 감소하면 의사 결정 부채 및 유지 관리 부채가 늘어나는 것으로 대체 가능
  • 이런 프로세스 예 : 코드/PR 리뷰, 모니터링 표준, QA 승인 및 기술/설계 검토
• 특정 유형의 부채 형성을 방지하는 도구들
  • 기본 도구에 투자하면 일부 유형의 부채가 형성되지 않을 수 있음
  • Scale 단계에서 보안 문제(보안 부채), 사용자 경험에 영향을 주는 버그 방지(기술 제품 부채), 코드 일관성(개발자 효율성 부채) 을 위해 특히 중요
  • 이런 도구의 예 : Linter 및 CI/CD 파이프라인
• Reactive & Acute 기술 부채를 위한 스프린트 작업
  • 조직이 온콜이 필요한 규모에 도달하면, 온콜 스프린트는 현재 불을 끄는 것 또는 기술 부채에 관련된 대응 작업에 소비되어야 함
  • 조직은 이를 통해서 급한 기술 부채 아이템을 처리하고, 온콜 팀을 통해서 현재/과거의 문제들에 대해서 실제 조치하는게 가능
  • 대응 작업에 온콜을 가능하게 하는 것은 성장의 Scale/Expansion 단계에서 특히 중요함. 급한 기술 부채를 처리하는 것은 다른 팀이 새로운 기능/제품을 만들어서 추가 부채를 처리할 수 있게 되기 때문
• 능동적이고 체계적인 기술 부채를 위한 로드맵 작업
  • 기술 부채를 로드맵에 넣는 것은 많은 팀들간의 정렬 작업이 필요
  • 기술 부채를 로드맵에 넣는 예 : 대규모 재작성, 고객이 주료 사용하는 기능의 데이터 시스템 재조정, 주요 경로에 대한 알림 정의 및 구현, 결재시스템 전환등

기술 부채를 부담에서 전략적 수단으로 전환하는 방법

• 축적된 기술 부채를 통해서 팀은 어떤 이니셔티브를 수행할지에 대해 전체적인 전략적 결정을 내릴 수 있음
• 팀이 겪게 될 공통적인 기술 부채 가정을 생각해보기. "기술 부채 = 나쁜 것" 이나 "기술 부채 ≠ 제품 작업" 에 반대하는가? "개인의 고통 = 조직의 고통" 이라고 생각하는 동료의 말을 듣고 있는가?
• "기술 부채" 라는 포괄적 용어를 사용하지 말기. 유지 관리 부채, 개발자 효율성 부채, 안정성 부채, 보안 부채, 기술 제품 부채, 의사 결정 부채 라고 이름 붙이기
• 덜 모호하게 만들기 위해 기술 부채의 규모를 결정하기. Acute 인가 Systemic 인가 ?
• 다른 회사의 영역들과 비교해 전략적으로 기술 부채의 우선순위 정하기. 신뢰도, 시간, 사용자에 대한 영향등과 같은 벡터를 기반으로 우선순위 지정
• 회사 성장에 따른 변화 및 요구에 대해 기술 부채 포트폴리오를 진화하고 균형을 유지할 것

[roxie]

가장 기본적이고도 중요한 내용은 "이게 당신의 고통"이라는 것을 명확하게 알려주는 것이라고 생각합니다. 그게 숫자든 뭐든.

그걸 못한다면 사실, 어쩌면, 기술부채가 아니었다는 결론에도 도달할 수 있을 것 같아요.

[composite]

한국에서는 #1 에서부터 이미 불가능하죠... '물경력'이란 용어가 괜히 나왔겠습니까...
게다가 SI 같은 외주나 프리랜서 경력은 같은 업계 아니면 어디가서 인정 안해주죠.